Definition
BBU (Baseband Unit, baseband processing unit) is responsible for baseband signal processing, channel coding, modulation and demodulation, protocol stack (RRC, RLC, MAC, PDCP), scheduling algorithms, etc., and connects with RRU via CPRI/eCPRI fronthaul interface. In the 5G era, BBU can be split into CU (Central Unit) and DU (Distributed Unit), supporting centralized deployment (C-RAN) and cloudification. BBU is the core of base station intelligence and capacity.
Functional Modules
- Baseband processing: FFT/IFFT, OFDM modulation, channel coding (LDPC, Polar), MIMO precoding
- Protocol stack and scheduling: RRC connection management, RLC segmentation/reassembly, MAC scheduling and HARQ, PDCP encryption and compression
- Interfaces: S1/X2 (4G) or NG/Xn (5G) with core network and neighboring cells; CPRI/eCPRI with RRU
5G CU/DU separation
CU handles non-real-time functions such as RRC and PDCP and can be centrally deployed; DU handles real-time functions like RLC, MAC, PHY, deployed close to the RRU. CU-DU separation supports flexible splitting (e.g., Option 2, Option 7-2), reduces fronthaul bandwidth requirements, and facilitates dense networking and cloudification.
Typical Use Cases
Distributed base stations, C-RAN, 5G CU/DU separation architecture. SimtoLink's IoT SIM cards connect through operator base stations, and the BBU's scheduling and coverage directly affect device access quality and speed.
The BBU is the core of the base station's intelligence, managing data scheduling between IoT devices and the base station. SimtoLink's IoT SIM cards connect through the operator's base station network, and the BBU's coverage and capacity directly impact connection quality. SimtoLink can provide customers with coverage optimization recommendations to help IoT devices maintain stable connections in high-density deployment scenarios.
How fronthaul bandwidth limits how many radio units can hang on
What runs between the baseband unit and the radio unit is fronthaul, not service IP. Fronthaul carries quantized time-domain or frequency-domain samples. Bandwidth grows with antenna count, sample rate, and quantization width, and it has little to do with how many bytes users actually sent. When one fronthaul link is already filled by the sample stream, adding more IoT devices only queues them in baseband scheduling. The radio side does not gain extra air-interface resources. To find the expansion point, see whether fronthaul utilization is already near line rate, not only the core-network exit.
Compression and a functional split can lower fronthaul traffic, but they limit where signal processing may sit. If compression is too aggressive, error on high-order modulation shows up first on edge users, as a rising block error rate while radio power has not fallen. Before changing the fronthaul optical module, check that the sample parameters and the compression match, so a larger optical port is not used to hide a configuration error.
Move the split point and the delay budget moves with it
The central unit handles non-real-time radio resource control and packet-data convergence. The distributed unit handles scheduling and the parts of the link layer and physical layer that must meet a time bound. The closer the split sits to the physical layer, the larger the fronthaul bandwidth and the more coordination the central unit can do. Move the split upward and fronthaul gets easier, while the room for joint scheduling shrinks. If IoT traffic must arrive uplink on time, the delay between the distributed unit and the radio has to stay inside the hybrid automatic repeat budget. Cloud delay on the central-unit side cannot be counted inside that budget.
In a pooled deployment, many radios share one baseband group. If one baseband board is overloaded, every cell on it shows scheduling delay together, and devices that are not neighbors geographically slow down at the same time. That correlation is the signature of a baseband pool: the failure domain groups by board, not by a single sector. While locating the fault, ask first whether these devices hang on the same baseband pool, then decide whether it is coverage or processing capacity.
Why small packets are easier to starve in the baseband scheduler
The scheduler sits on the baseband side. It decides who gets resource blocks first from priority, channel quality, and buffer occupancy. A video buffer keeps requesting resources. A periodic IoT packet with low priority may miss several scheduling cycles in a row. An application timeout does not mean the radio link is down. The packet can still be in the base-station buffer. The condition is: the device is still connected, buffer occupancy is not empty, and grants are rare. Raise the bearer priority or cut meaningless time in the connected state, rather than increasing application retransmission.
SimtoLink cards and modules do not replace the operator baseband unit, but whether a device is scheduled shows up directly in online delay and failed retransmission. If a batch of cards on the same site slows down together and the signal level is normal, put the suspicion on that site’s baseband load and fronthaul, not on reactivating cards one by one. When selecting a module, confirm that the buffer status and priority parameters it reports can be used by the network. Otherwise a high-priority subscription still never enters the scheduling queue.
The cell name can look unchanged when a baseband board switches over
A pooled baseband unit can move a cell from one board to another. After the move the cell identity is still the original one, and the radio unit has not moved, but the scheduling process, the hybrid automatic repeat state in the buffer, and the unfinished ciphering context are a new running instance. The device may have to re-establish the radio connection. The application sees a short break and then recovery, while the signal level stays normal the whole time. If you judge only by the cell identity that “the base station never changed,” this break is recorded as the device restarting itself. Compare the baseband-board switchover record with the device re-establishment time and see whether they coincide.
If fronthaul drops briefly during the switchover, every cell on that board re-establishes together, and devices spread across geography fail in the same second. That is the failure domain of the baseband pool, not of one card. If the SimtoLink platform can align re-establishment time by cell, it can separate “cards on the same baseband board” from “one card that dropped by chance.” If only one device still fails after that alignment, go back to the module and check the capability report and priority, rather than asking the operator to replace the whole site.