Handover challenges in disaggregated open RAN for LEO Satellites: tradeoff between handover delay and onboard processing

Given the advancements in next-generation low Earth orbit (LEO) satellites, there is an expected shift from transparent architectures (acting as radio repeaters) to regenerative architectures (hosting a part or all of the gNodeB (gNB) onboard). Such regenerative architectures enable disaggregation and distribution of radio access network (RAN) functions between the ground and space. Open RAN is a promising approach for non-terrestrial networks and offers flexible function placement through open interfaces. The present study examines three open RAN-based regenerative architectures, namely, Split 7.2× (low-layer physical functions onboard), Split 2 (Layers 1 and 2 onboard), and a gNB onboard the satellite. Handover (HO) management becomes increasingly complex in this disaggregated RAN, particularly for LEO satellites, where the part of the gNB is constantly in motion. The choice of regenerative architecture and its dynamic topology influence the additional HO control signals required between the satellite and ground stations. Using a realistic dynamic LEO constellation model, we analyze the interplay among conditional handover (CHO) delay, computational complexity, and control signaling overhead under different network architectures. Our findings reveal that transitioning from a transparent architecture to Split 7.2× does not reduce CHO delay despite the introduction of additional onboard processing. The gNB onboard the satellite minimizes cumulative CHO delay but demands 55%–70% more computational resources than the Split 7.2× architecture. Conversely, although Split 7.2× is computationally more efficient, it increases the cumulative CHO delay by 25%–30%. Additionally, we observed that under limited onboard processing conditions, only the transparent and Split 7.2× architectures supported delay-sensitive services up to 100 ms. In contrast, under ample processing conditions, gNB was suitable for stringent 50 ms requirements, while Split 2 best supported delay-tolerant services with 200 ms requirements.