Fronthaul delay management for non-terrestrial network systems

Abstract

A system and a method for calculating a time delay in a non-terrestrial network (NTN) fronthaul (FH) includes defining a transport delay range including lower bound (Tmin) and an upper bound (Tmax) for the NTN FH, the transport delay including a downlink transport delay and an uplink transport delay, the transport delay range encompasses only a time when a bit leaves a sender until the bit is received by a receiver, and the transport delay values changes with the motion of a satellite.

Description

FRONTHAUL DELAY MANAGEMENT FOR NON-TERRESTRIAL NETWORK SYSTEMS DESCRIPTION OF RELATED TECHNOLOGY a. Field of the Disclosure

[0001] The present disclosure relates to systems and methods for radioaccess networks. The present disclosure focuses on the design of operation, administration and management of various network elements of 4G and 5G based mobile networks. The present disclosure is related to Front-Haul (FH) delay management in Non-Terrestrial Network (NTN) systems. b. Description of the Related Technology

[0002] Front-haul delay management in Terrestrial Network

[0003] The Intra-PHY lower layer fronthaul split demands stringent latencyand bandwidth requirements. FIG.1 shows Reference Points for delay management for FH delay. For a terrestrial case, the model is based on eCPRI reference points as adopted by ORAN WG4. The reference points defined for eCPRI are: O-DU: R1 / R4 – Transmit / Receive interface at O-DU O-RU: R2 / R3 – Receive / Transmit interface at O-RU Ra: Antenna interface at RaTable 1: eCPRI O-DU / O-RU delay model latency parameters

[0004] Architecture for Non-Terrestrial Network

[0005] FIG.2 shows a system architecture of an NTN System. In particular,FIG.2 shows an example of split-8 supported NTN system. A problem with this architectural method is that the model is not based on eCPRI reference point model, which is already adopted in O-RAN WG4 and hence hinders the adoption of other split options which are extensively used in existing ORAN Terrestrial networks. In addition, the bandwidth requirement of the feeder link 119 would be higher with the above-described method, which would play a major factor in the adoption of method as it would impact the total CAPEX cost for the operator. FIG.3 shows fronthaul bitrates across functional splits. SUMMARY

[0006] Described are various embodiments of a system, a method, and acomputer program product including program memory including instructions which, when executed by a processor, executes the method described above and herein.

[0007] Described is a service profile based on eCPRI model for NTN basedOpen RAN system. To describe the service profile, additional Delay Parameters are introduced and their usages in NTN fronthaul network employed to characterize FH latency. These additional delay parameters consider the satellite movement for FH delay estimation. Further, Transmission Window and Reception Window duration is modeled based on additional delay parameters for O-DU and Satellite (O-RU 153 on satellite) for Uplink and Downlink. A method is disclosed for Delay measurements tocater Timing adjustment requirements due to variations in Feeder link delay value due to satellite mobility. BRIEF DESCRIPTION OF THE FIGURES

[0008] FIG.1 shows Reference Points for delay management.

[0009] FIG. 2 shows a system architecture of an NTN System.

[0010] FIG.3 shows fronthaul bitrates across functional splits.

[0011] FIG.4 shows a definition of reference points for delay management inNTN Systems.

[0012] FIG.5 shows timing relations per symbol IQ in DL direction (U-planeand C-plane).

[0013] FIG. 6 shows timing relations per symbol IQ in UL direction (U-planeand C-plane).

[0014] FIG. 7 shows an exemplary Hybrid Transport.

[0015] FIG. 8 shows an NTN Measured Transport.

[0016] FIG. 9 illustrates an NG-RAN architecture.

[0017] FIG.10 shows an example of a User Plane Stack.

[0018] FIG. 11 shows an example of a Control Plane Stack.

[0019] FIG.12A shows an example of high-level NG-RAN including a gNB CUand DU.

[0020] FIG.12B shows an example of a Separation of CU-CP and CU-UP in a5G gNB.

[0021] FIG.12C shows an example of a Separation of CU-CP and CU-UP in a4G ng-eNB.

[0022] FIG.13A shows an example of an O-RAN architecture.

[0023] FIG. 13B shows an example of an O-RAN OAM architecture.

[0024] FIG. 14 illustrates an E-UTRAN network architecture.

[0025] FIG.15. illustrates an E-UTRA-NR Dual Connectivity networkarchitecture.

[0026] FIG. 16 is a block diagram of an NTN for an NR system.DETAILED DESCRIPTION

[0027] The present disclosure describes implementations for variouswireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other networks. A CDMA network can implement a radio technology such as universal terrestrial radio access (UTRA), cdma2000, and the like. UTRA includes wideband CDMA (WCDMA), time division synchronous CDMA (TD-SCDMA), and other variants of CDMA. A TDMA network can implement a radio technology such as global system for mobile communications (GSM). An OFDMA network can implement a radio technology such as evolved UTRA (E-UTRA), ultra mobile broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash- OFDM®, etc. UTRA and E-UTRA are part of universal mobile telecommunication system (UMTS). UTRA, E-UTRA, UMTS, LTE, LTE-A and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). NR (e.g., 5G radio access) includes an evolving set of enhancements to the 3GPP 3G LTE mobile standard. Implementations as described herein can be employed for radio technologies and wireless networks as described above and herein as well as other wireless networks and radio technologies.

[0028] Reference is made to Third Generation Partnership Project (3GPP)and the Internet Engineering Task Force (IETF) in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions.3GPP and IETF technical specifications (TS), standards (including proposed standards), technical reports (TR) and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.

[0029] O-RAN.WG4.MP.0-R003-v13.00

[0030] 3GPP TS 23.501 V 18.1.02023-04-05

[0031] 3GPP TS 38.300 V 17.4.003-28-2023

[0032] 3GPP TS 38.401 V 17.4.02023-04-03

[0033] Abbreviations:CU Control Unit DU Distributed Unit 3GPP: 3rdGeneration Partnership Project 5GC: 5G Core API: Application Programing Interface DU: Distributed Unit DL: Downlink eNB: evolved Node B EN-DC: E-UTRAN New Radio – Dual Connectivity E-UTRA: Evolved Universal Terrestrial Radio Access E-UTRAN: Evolved Universal Terrestrial Radio Access Network FFT: Fast Fourier Transform FH: Fronthaul C-plane: Control Plane U-plane: User PlaneS-plane: Synchronization plane FM: Fault Management gNB: next generation Node B GEO: Geostationary Earth Orbit GBBF: Ground based Beam Former HARQ: Hybrid automatic repeat request LTE: Long Term Evolution LEO: Low Earth Orbit MAC: Media Access Control ML: Machine Learning MEO: Medium Earth Orbit NTN - Non-Terrestrial Network NR: 5G New Radio PDCP: Packet Data Convergence Protocol PHY: Physical layer PM: Performance Management PNF: Physical Network Function PRACH: Physical Random Access Channel RAN: Radio Access Network RAT: Radio Access Technology RF: Radio Frequency RLC: Radio Link Control RRC: Radio Resource Control RRH: Remote Radio Head RRM: Radio Resource Management RRU: Remote Radio Unit RU: Radio Unit SDAP: Service Data Adaptation Protocol SMO: Service Management and Orchestration TRP: Transmission and Reception Point UE: User Equipment UL: UplinkVNF: Virtualized Network Function xApp: Near-RT RIC Application xNF: Any Network Function

[0034] Definitions

[0035] Dual Connectivity: a mode of operation of a UE in“RRC_CONNECTED”, configured with a Master Cell Group and a Secondary Cell Group.

[0036] En-gNB: a node providing NR user plane and control plane protocolterminations towards the UE and acting as a Secondary Node in EN-DC.

[0037] gNB: a node providing NR user plane and control plane protocolterminations towards the UE and connected via the NG interface to the 5GC.

[0038] gNB Central Unit (gNB-CU): a logical node hosting RRC, SDAP andPDCP protocols of the gNB 106 or RRC and PDCP protocols of the en-gNB 106 that controls the operation of one or more gNB-DUs. The gNB-CU 151 terminates the F1 interface connected with the gNB-DU.

[0039] gNB Distributed Unit (gNB-DU): a logical node hosting RLC, MAC andPHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-DU supports one or multiple cells. One cell is supported by only one gNB- DU. The gNB-DU 152 terminates the F1 interface connected with the gNB-CU.

[0040] gNB-CU-Control Plane (gNB-CU-CP): a logical node hosting the RRCand the control plane part of the PDCP protocol of the gNB-CU 151 for an en-gNB or a gNB. The gNB-CU-CP terminates the E1 interface connected with the gNB-CU-UP and the F1-C interface connected with the gNB-DU.

[0041] gNB-CU-User Plane (gNB-CU-UP): a logical node hosting the userplane part of the PDCP protocol of the gNB-CU 151 for an en-gNB, and the user plane part of the PDCP protocol and the SDAP protocol of the gNB-CU 151 for a gNB. ThegNB-CU-UP terminates the E1 interface connected with the gNB-CU-CP and the F1-U interface connected with the gNB-DU.

[0042] As noted herein, the Intra-PHY lower layer fronthaul split demandsstringent latency and bandwidth requirements. Therefore, a “Fronthaul Service Profile” for a transport network is defined and disclosed herein.

[0043] FIG.4 shows a definition of reference points for delay management inNTN Systems. In case of NTN FH Delay Management, the reference points defined for eCPRI are:

[0044] O-DU : R1 / R4 – Transmit / Receive interface at DU

[0045] GBBF : R5 / R6 – Receive / Transmit interface at GBBF

[0046] Rb : Antenna Interface at Gateway

[0047] O-RU : R2 / R3 – Receive / Transmit interface at RU

[0048] Ra : Antenna Interface at RU (satellite)

[0049] The complete transmission delay encompasses only the time fromwhen a bit leaves the sender (R1 / Rb / R3 / R6) until it is received at the receiver (R5 / R2 / Rb / R4). Tb2 and T3b are the feeder link 119 (OTA) delay whose values change with the motion of satellite 156. Also, in an ethernet transport network, the delays may not be constant due to switching delays (i.e.: PDV). To account for this, transport delay is considered as a range with upper and lower bounds: Downlink transport delay : T12max / T12min Uplink transport delay : T34max / T34min

[0050] Fixed Timing at Ra and Rb are required and hence Ra and Rb are usedfor delay management in the eCPRI model and transmission and reception at reference points are measured relative to Ra and Rb.Relative to Ra:-Relative to Rb:-

[0051] The relative time error of the S-plane measurement signals betweenthe O-DU 152 and O-RU 153, for the purposes of latency requirements management, can be within a limit of 3 s (±1.5 s).

[0052] The upper bound on the absolute time error requirement at the O-DU152 S-Plane is dictated by the O-RU’s 153 receive window, O-DU’s 152 internaldelays, GBBF 154 and Gateway’s 117 internal delay, Feeder Link delay variation, and the delay and PDV in the transport network.

[0053] Timing Parameter Relationship:

[0054] This transmission time can be affected by several factors including(but not limited to) transport media rate, air interface bandwidth, and amount of data compression.

[0055] The maximum amount of time allowed for the transmitter to send alldata for an interval (Transmission Window) is defined by T1amax – T1amin. This is the allowed time, based on transport, GBBF 154, Gateway 117, and O-RU 153 on satellite characteristics.

[0056] To account for transport variation and transmission time, the receiverimplements a reception window. This allows packets containing samples for a specific symbol to be received within the window and still be transmitted at Ra at the required time.

[0057] The size of the Reception Window accounts for both the maximumtransmission time at the sender and the transport variation through the fronthaul network.

[0058] Reception Window (Transmission Window + Transport Variation)Table 1: eCPRI Delay Window

[0059] For guaranteed reception of packets sent from O-DU 152 to RU onsatellite within the O-RU 153 reception window, the following relationships are met.Table 2: O-DU Downlink Transmission and Uplink Reception Window

[0060] The U-Plane O-DU 152 transmission window (T1amax – T1amin) isdefined by the relationships above based on the O-RU 153 reception window and maximum transport variation. It does not define the exact timing of transmission from the O-DU 152. Rather, it defines the boundaries that the U-Plane O-DU 152 transmission operates within. The window merely represents the mathematical boundaries imposed on the O-DU 152 because of the O-RU 153 and Transport constraints

[0061] The window resulting from the relationships is greater than or equalto the actual maximum time required by the O-DU 152 to transmit all data for a symbol (TXmaxO-DU). That is, the window is at least large enough that the O-DU 152 can transmit in the worst case within the window.

[0062] U-Plane / C-Plane Timing

[0063] The C-Plane is available to process the corresponding U-Plane packets.To support coordination of C-Plane and U-Plane timing, the fronthaul interface specifies that C-Plane messages arrive at the O-RU 153 some amount of time in advance (Tcp_adv_dl) of the latest possible time the first corresponding U-Plane messages can arrive. Table 4: Delay Management Model Parameter

[0064] Table 5: Downlink Delay Relationship

[0065] Table 6: Uplink Delay Relationship

[0066] FIG.5 shows timing relations per symbol IQ in DL direction (U-planeand C-plane).

[0067] FIG.6 shows timing relations per symbol IQ in UL direction (U-planeand C-plane).

[0068] Fronthaul Latency Calculations

[0069] For the fronthaul interface to operate properly, the transmit andreceive windows at the O-DU 152 shall be properly aligned. The O-RU 153 window alignment is always based on Ra.

[0070] As shown in FIG. 2, Fronthaul Delay for NTN depends on followingthree characteristics: oTransport Delay characteristics between O-DU 152 and GBBF 154 (T15 / T64)o Propagation latency characteristics between GBBF 154 and Gateway 117 (T5b / Tb6). oFeeder Link Delay characteristics (Tb2 / T3b)

[0071] The Delay between O-DU 152 -- GBBF 154, and GBBF 154 -- Gateway117 are fixed numbers and does not require any change after the initial calibration, but the Feeder link Delay value keeps on changing over the period because of the continuous motion of satellite 156 and hence poses a major challenge in maintaining the fronthaul S-plane requirements which are already adopted in ORAN standards.Two methods are disclosed to address this issue and meet the S-plane fronthaul requirement with O-RU 153 present at satellite 156.

[0072] Timing adjustments need to be done to compensate for the Feederlink variations occurring due to satellite 156 movement, and hence the transmit and receive windows at the O-DU 152 are adjusted to meet the Fronthaul requirement. In the following section, two methods are disclosed which can be used to meet Fronthaul requirements for NTN systems with O-RU 153 present at satellite 156.

[0073] Hybrid Transport Method

[0074] FIG. 7 shows an exemplary Hybrid Transport. In conventionalterrestrial networks, Fronthaul delay is computed and updated at the O-DU 152 based on O-RU 153 and transport delay characteristics. For NTN, because of continuous orbital motion of satellite 156, transport delay characteristics continuously alter over time. To resolve this challenge, a Hybrid Transport method is disclosed which is a combination of Measured Transport method with recurrent update based on orbital motion of satellite 156.

[0075] In this method, the O-DU 152 has the information for the orbitalmotion of the satellite 156. In the first stage, O-DU 152 transmit and receive windows are determined based on delay characteristics of O-RU 153, GBBF 154 and Gateway 117, and the measured transport delay between all O-DU 152 ports and O- RU 153 ports in time domain. Subsequently, the O-DU 152 transmit and receive windows are adjusted based on the information of satellite 156 motion.

[0076] Steps to compute Fronthaul Delay (T12): -T12 = T15 + T5b + Tb2 where T15 is the fronthaul latency between O-DU 152 and GBBF 154, T5b is the GBBF 154 processing delay, and Tb2 is feeder link delay.

[0077] Step 1. At time instance t1 as shown in above FIG. 7, O-DU 152 triggersthe measured transport method to compute T12. 12 = 15 + 5 + 2( )

[0078] Step 2. At time instance t2, because of the motion of satellite 156, thefeeder link delay Tb2 will get varied and thus require an update for the overall Fronthaul delay value (T12). 12 = 15 + 5 + 2( )

[0079] Step 3. As the orbital motion of the satellite 156 is known to the O-DU152, O-DU 152 infers at time instance t2 and updates the overall fronthaul value (T12).

[0080] Step 4: Based on updated T12 value, O-DU 152 adjusts its DLTransmission and Uplink Reception window as tabulated in Table 2

[0081] NTN Measured Transport Method

[0082] FIG.8 shows an NTN Measured Transport. eCPRI specifications definetwo methods for measuring one way delay (a 1-step method and a 2-step method). In order to tackle the delay variations in fronthaul, that is, Feeder link delay variations because of satellite 156 movement, the O-DU 152 initiates the measured transport method more frequently in order to align the transmit and receive windows. The frequency of this initiation depends on the type (Low Earth Orbit (LEO), a Medium Earth Orbit (MEO) and a Geosynchronous Earth Orbit (GEO)) and the altitude of the satellite 156.

[0083] In another example, the orbital motion of satellite 156 is not known atthe O-DU 152. In this case the O-DU 152 triggers measured transport method frequently in order to capture the variations in feeder link delay. The frequency of trigger depends on the altitude of the satellite 156 and the elevation angle of the GBBF 154 and Gateway 117 on the earth station.

[0084] NTN measured transport method depends on the type of satellite 156(i.e.: LEO / MEO / GEO) because for the different modes of satellites 156, the altitude from ground station is different and hence the variation in feeder link are different.

[0085] Steps to compute Fronthaul Delay (T12):T12 = T15 + T5b + Tb2 where T15 is the fronthaul latency between O-DU 152 and GBBF 154, T5b is the GBBF 154 processing delay, and Tb2 is feeder link delay and variation in Tb2 depends on type of satellite 156 as depicted in the FIG.8.

[0086] The feeder link delay for LEO, MEO and GEO satellites 156 are, , and the variations in these feeder link delay be represented as, respectively so that:> >Based on this, O-DU 152 triggers measured transport method and calculates T12 value, and correspondingly adjust its DL Transmission and Uplink Reception window as tabulated in Table 2.

[0087] Other implementation environments for the embodiments describedherein include NR-NTN, NBIOT-NTN, and eMTC-NTN.

[0088] Accordingly, this disclosure includes the following features:Existing Terrestrial network based Fronthaul Delay profile defined in O-RAN specification are modified for the non-terrestrial network. Additional Delay parameters are introduced to capture the satellite 156 movement affect, and Fronthaul latency formulas are updated accordingly. By considering the newly added parameters for the characterization of the Non-Terrestrial network, the Lower and Upper bound of the Downlink and Uplink transport delay are derived.Further, the upper bound of relative time error of the S-plane measurement signals between the O-DU 152 and O-RU 153 are derived. The relationship between the timing parameters associated with C-Plane and U-Plane for the Downlink / Uplink transmission are derived.

[0089] Exemplary Implementation Environment

[0090] FIG. 9 is a block diagram of a system 100. System 100 includes a NRUE 101, a NR gNB 106. The NR UE and NR gNB 106 are communicatively coupled via a Uu interface 120.

[0091] NR UE 101 includes electronic circuitry, namely circuitry 102, thatperforms operations on behalf of NR UE 101 to execute methods described herein. Circuity 102 can be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 102A.

[0092] NR gNB 106 includes electronic circuitry, namely circuitry 107, thatperforms operations on behalf of NR gNB 106 to execute methods described herein. Circuity 107 can be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 107A.

[0093] Programmable circuit 107A, which is an implementation of circuitry107, includes a processor 108 and a memory 109. Processor 108 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 109 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 109 stores data and instructions, i.e., program code, that are readable and executable by processor 108 for controlling operations of processor 108. Memory 109 can be implemented in a random-access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One of the components of memory 109 is a program module, namely module 110. Module 110 contains instructions for controlling processor 108 to execute operations described herein on behalf of NR gNB 106.

[0094] The term "module" is used herein to denote a functional operationthat can be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, each of module 105 and 110 can be implemented as a single module or as a plurality of modules that operate in cooperation with one another.

[0095] While modules 110 are indicated as being already loaded intomemories 109, and module 110 can be configured on a storage device 130 for subsequent loading into their memories 109. Storage device 130 is a tangible, non- transitory, computer-readable storage device that stores module 110 thereon. Examples of storage device 130 include (a) a compact disk, (b) a magnetic tape, (c) a read only memory, (d) an optical storage medium, (e) a hard drive, (f) a memory unit comprising multiple parallel hard drives, (g) a universal serial bus (USB) flash drive, (h) a random-access memory, and (i) an electronic storage device coupled to NR gNB 106 via a data communications network.

[0096] Uu Interface (120) is the radio link between the NR UE and NR gNB,which is compliant to the 5G NR specification.

[0097] UEs 101 can be dispersed throughout wireless communicationnetwork , and each UE can be stationary or mobile. A UE includes: an access terminal, a terminal, a mobile station, a subscriber unit, a station, etc. A UE can also include be a cellular phone (e.g., a smart phone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a drone, a robot / robotic device, a netbook, a smartbook, an ultrabook, a medical device, medical equipment, a healthcare device, a biometric sensor / device, a wearable device such as a smart watch, smart clothing, smart glasses, a smart wristband, and / or smart jewelry (e.g., a smart ring, a smart bracelet, and the like), an entertainment device (e.g., a music device, a video device, a satellite 156 radio, and the like), industrial manufacturing equipment, a global positioning system (GPS) device, or any other suitable device configured tocommunicate via a wireless or wired medium. UEs can include UEs considered as machine-type communication (MTC) UEs or enhanced / evolved MTC (eMTC) UEs. MTC / eMTC UEs that can be implemented as IoT UEs. IoT UEs include, for example, robots / robotic devices, drones, remote devices, sensors, meters, monitors, cameras, location tags, etc., that can communicate with a BS, another device (e.g., remote device), or some other entity. A wireless node can provide, for example, connectivity for or to a network (e.g., a wide area network such as Internet or a cellular network) via a wired or wireless communication link.

[0098] One or more UEs 101 in the wireless communication network (e.g., anLTE network) can be a narrowband bandwidth UE. As used herein, devices with limited communication resources, e.g. smaller bandwidth, are considered as narrowband UEs. Similarly, legacy devices, such as legacy and / or advanced UEs (e.g., in LTE) can be considered as wideband UEs. Wideband UEs are generally understood as devices that use greater amounts of bandwidth than narrowband UEs.

[0099] The UEs 101 are configured to connect, for example, communicativelycouple, with an or RAN. In embodiments, the RAN can be an NG RAN or a 5G RAN, an E-UTRAN, an MF RAN, or a legacy RAN, such as a UTRAN or GERAN. The term “NG RAN” or the like refers to a RAN 110 that operates in an NR or 5G system, the term “E-UTRAN” or the like refers to a RAN that operates in an LTE or 4G system, and the term “MF RAN” or the like refers to a RAN that operates in an MF system 100. The UEs 101 utilize connections (or channels), respectively, each of which comprises a physical communications interface or layer. The connections can comprise several different physical DL channels and several different physical UL channels. As examples, the physical DL channels include the PDSCH, PMCH, PDCCH, EPDCCH, MPDCCH, R-PDCCH, SPDCCH, PBCH, PCFICH, PHICH, NPBCH, NPDCCH, NPDSCH, and / or any other physical DL channels mentioned herein. As examples, the physical UL channels include the PRACH, PUSCH, PUCCH, SPUCCH, NPRACH, NPUSCH, and / or any other physical UL channels mentioned herein.

[0100] The RAN can include one or more AN nodes or RAN nodes. Theseaccess nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, MF- APs, TRxPs or TRPs, and so forth, and comprise ground stations (e.g., terrestrial access points) or satellite 156 stations providing coverage within a geographic area (e.g., a cell). The term “NG RAN node” or the like refers to a RAN node that operates in an NR or 5G system (e.g., a gNB), and the term “E-UTRAN node” or the like refers to a RAN node that operates in an LTE or 4G system (e.g., an eNB). According to various embodiments, the RAN nodes can be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0101] In some embodiments, all or parts of the RAN nodes can beimplemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a CRAN and / or a vBBU. In these embodiments, the CRAN or vBBU can implement a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN / vBBU and other L2 protocol entities are operated by individual RAN nodes; a MAC / PHY split wherein RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBU and the PHY layer is operated by individual RAN nodes; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN / vBBU and lower portions of the PHY layer are operated by individual RAN nodes. This virtualized framework allows the freed-up processor cores of the RAN nodes to perform other virtualized applications. In some implementations, an individual RAN node can represent individual gNB-DUs that are connected to a gNB- CU 151 via individual F1 interfaces. In these implementations, the gNB-DUs can include one or more remote radio heads (RRH), and the gNB-CU 151 can be operated by a server that is located in the RAN or by a server pool in a similar manner as the CRAN / vBBU. One or more of the RAN nodes can be next generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs 101, and are connected to a 5GC via anNG interface. In MF implementations, the MF-APs are entities that provide MultiFire radio services, and may be similar to eNBs in an 3GPP architecture.

[0102] In some implementations, access to a wireless interface can bescheduled, wherein a scheduling entity (e.g.: BS, gNB, and the like) allocates bandwidth resources for devices and equipment within its service area or cell. As scheduling entity can be configured to schedule, assign, reconfigure, and release resources for one or more subordinate entities. In some examples, a UE 101 (or other device) can function as master node scheduling entity, scheduling resources for one or more secondary node subordinate entities (e.g., one or more other UEs 101). Thus, in a wireless communication network with a scheduled access to time—frequency resources and having a cellular configuration, a P2P configuration, and a mesh configuration, a scheduling entity and one or more subordinate entities can communicate utilizing the scheduled resources.

[0103] BS or gNB 106 can be equipped with T antennas and UE 101 can beequipped with R antennas, where in general T 1 and R 1. At BS, a transmitprocessor is configured to receive data from a data source for one or more UEs 101 and select one or more modulation and coding schemes (MCS) for each UE based on channel quality indicators (CQIs) received from the UE 101. The BS is configured to process (e.g., encode and modulate) the data for each UE 101 based on the MCS(s) selected for the UE 101, and provide data symbols for all UEs. A transmit processor is also configured to process system information (e.g., for static resource partitioning information (SRPI), and the like) and control information (e.g., CQI requests, grants, upper layer signaling, and the like) and can provide overhead symbols and control symbols. Processor 108 can also generate reference symbols for reference signals (e.g., the cell-specific reference signal (CRS)) and synchronization signals (e.g., the primary synchronization signal (PSS) and the secondary synchronization signal (SSS)). A transmit (TX) multiple-input multiple- output (MIMO) processor can be configured perform spatial processing (e.g., precoding) on the data symbols, the control symbols, the overhead symbols, and / orthe reference symbols, if applicable, and can be configured to provide T output symbol streams to T modulators (MODs). Each modulator can be configured to process a respective output symbol stream (e.g., for OFDM, and the like) to obtain an output sample stream. Each modulator can further be configured to process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. T downlink signals from modulators can be transmitted via T antennas.

[0104] An overview of 5G NR Stacks is as follows. 5G NR (New Radio) userand control plane functions with monolithic gNB 106 are shown in the figures below. For the user plane, PHY (physical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers are terminated in the gNB 106 on the network side. For the control plane, RRC (Radio Resource Control), PDCP, RLC, MAC and PHY sublayers are terminated in the gNB 106 on the network side and NAS (Non-Access Stratum) is terminated in the AMF (Access Mobility Function) on the network side. FIG.10 shows an example of a User Plane Stack as descried in 3GPP TS 38.300. FIG. 11 shows an example of a Control Plane Stack as described in 3GPP TS 38.300.

[0105] An NG-RAN (NG-Radio Access Network) architecture from 3GPP TS38.401 is described below. F1 is the interface between gNB-CU 151 (gNB – Centralized Unit) and gNB-DU 152 (gNB – Distributed Unit), NG is the interface between gNB-CU 151 (or gNB) and 5GC (5G Core), E1 is the interface between CU- CP (CU-Control Plane) and CU-UP (CU-User Plane), and Xn is interface between gNBs.

[0106] A gNB 106 can comprise a gNB-CU-CP, multiple gNB-CU-UPs andmultiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU 152 through the F1- C interface and to the gNB-CU-UP through the E1 interface. The gNB-CU-UP is connected to the gNB-DU 152 through the F1-U interface and to the gNB-CU-CP through the E1 interface. One gNB-DU 152 is connected to only one gNB-CU-CP and one gNB-CU-UP is connected to only one gNB-CU-CP. FIG.12A shows an example ofan NG-RAN Architecture as described in 3GPP TS 38.501. FIG.12B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) as described in 3GPP TS 38.401. FIG.12C shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 4G system.

[0107] A Layer 2 (L2) of 5G NR is split into the following sublayers isdescribed in 3GPP TS 38.300):

[0108] Medium Access Control (MAC): The MAC sublayer offers LogicalChannels (LCs) to the RLC sublayer. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers).

[0109] Radio Link Control (RLC): The RLC sublayer offers RLC channels tothe PDCP sublayer. The RLC sublayer supports three transmission modes: RLC- Transparent Mode (RLC-TM), RLC-Unacknowledged Mode (RLC-UM) and RLC- Acknowledgement Mode (RLC-AM). RLC configuration is per logical channel. It hosts ARQ (Automatic Repeat Request) protocol for RLC-AM mode.

[0110] Packet Data Convergence Protocol (PDCP): The PDCP sublayer offersRadio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane.

[0111] Service Data Adaptation Protocol (SDAP): The SDAP offers QoS Flowsto the 5GC (5G Core). This sublayer provides mapping between a QoS flow and a DRB. It marks QoS Flow Id in DL (downlink) as well as UL (uplink packets).

[0112] O-RAN, which is based on disaggregated components and connectedthrough open and standardized interfaces is based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN (CU, DU, and RU), near-real-time RIC and non-real- time RIC is shown in the figure below. Here, DU (Distributed Unit) and CU (Centralized Unit) are typically implemented using COTS (Commercial off-the-shelf) hardware.

[0113] Figures 13A-13B show an example of an O-RAN architecture. In Figure13A, the CU and the DU are connected using the F1 interface (with F1-C for control plane and F1-U for user plane traffic) over the midhaul (MH) path. One DU could host multiple cells (for example, one DU could host 24 cells) and each cell can support many users. For example, one cell can support 600 RRC Connected users and out of these 600, there may be 200 Active users (i.e.; users which have data to send at a given point of time).

[0114] A cell site can comprise multiple sectors and each sector can supportmultiple cells. For example, one site can comprise of three sectors and each sector could support 8 cells (with 8 cells in each sector on different frequency bands). One CU-CP could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1000 cells and around 100,000 UEs. Each UE could support multiple DRBs and there could be multiple instances of CU-UP to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs) can be served by five CU-UP instances (and one CU-CP instance).

[0115] DU can be located in a private data center or it could be located at acell-site too. CU can also be located in a private data center or even hosted on a public cloud system. DU and CU can be tens of kilometers away. CU can communicate with 5G core system which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider). RU (Radio Unit) is located at cell-site and communicated with DU via a fronthaul (FH) interface.

[0116] The E2 nodes (CU and DU) are connected to the near-real-time RIC155 using the E2 interface. The E2 interface is used to send data (e.g., user, cell, slice KPMs) from the RAN, and deploy control actions and policies to the RAN at near- real-time RIC 155. The application or service at the near-real-time RIC 155 that deploys the control actions and policies to the RAN are called xApps. The near-real- time RIC 155 is connected to the non-real-time RIC 161 using the A1 interface.

[0117] SMO 167 manages multiple regional networks, and O-RAN NFs (O-CUs151, Near-RT RIC 155, O-DUs 152) can be deployed in a regional data center that is connected to multiple cell sites or in cell site which is close to localized O-RU 153 according to network requirements. Since SMO 167 Functions and O-RAN NFs are micro services and deployment-independent logical functions, SMO 167 Functions and O-RAN NFs can be composed of multiple deployment instances deployed in the same O-Cloud or in a different O-Cloud in regional data center, or in cell site according to network requirements (ex. capacity, latency, security, and so on) if the secure connection among SMO167 Functions and O-RAN NFs are available.

[0118] As shown in FIG. 13B, an O-RAN compliant SMO 167 defines TE&IV163, RAN NF OAM 164, Non-RT RIC 161, and NFO165, FOCOM services 166. SMO 167 interacts with O-RAN NFs with O1 interface. SMO interacts with O-RU 153 with Open FH M-Plane interface and interacts O-Cloud via the O2 interface. O-RAN NF OAM 164 manages O-RAN NF CM, FM, PM and creates O-RAN NF inventory and topology in TE&IV 163. FOCOM / NFO 166 manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE&IV 163. Analytics / rApp in Non-RT RIC 161 can subscribe O-RAN NFs PM / FM, O-Cloud PM / FM data based on O-RAN NF OAM and FOCOM 166 / NFO 165. Analytics / rApp in Non-RT RIC 161 can retrieve the O-RAN NF and O-Cloud resource inventory and topology.

[0119] An E-UTRAN architecture is illustrated in FIG. 14. The E-UTRANcomprises of eNBs, providing the E-UTRA U-plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway (S-GW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.

[0120] E-UTRAN also supports MR-DC via E-UTRA-NR Dual Connectivity (EN-DC), in which a UE is connected to one eNB that acts as a MN and one en-gNB 106 that acts as a SN. An EN-DC architecture is illustrated in FIG 15. The eNB is connected to the EPC via the S1 interface and to the en-gNB 106 via the X2 interface. The en-gNB 106 might also be connected to the EPC via the S1-U interface and other en-gNBs via the X2-U interface. In EN-DC, and en-gNB 106 comprises gNB-CU 151 and gNB-DU(s) 152.

[0121] E-UTRAN also supports and NG-RAN architecture. An NG-RAN node iseither: a gNB, providing NR user plane and control plane protocol terminations towards the UE; or an ng-eNB, providing E-UTRA user plane and control plane protocol terminations towards the UE. (3GPP TS 38.30017.3.0.)

[0122] As shown in FIGS. 14-15, the gNBs and ng-eNBs are interconnectedwith each other by means of the Xn interface. The gNBs and ng-eNBs are also connected by means of the NG interfaces to the 5GC, more specifically to the AMF (Access and Mobility Management Function) by means of the NG-C interface and to the UPF (User Plane Function) by means of the NG-U interface. The gNB 106 and ng- eNB host functions for Radio Resource Management such as: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling), connection setup and release; session Management; QoS Flow management and mapping to data radio bearers; Dual Connectivity. Tight interworking between NR and E-UTRA. NB-IoT UE is supported by ng-eNB.

[0123] The gNB 106 and ng-eNB host functions such as functions for RadioResource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling), connection setup and release; session Management; QoSFlow management and mapping to data radio bearers; Dual Connectivity; Tight interworking between NR and E-UTRA. NB-IoT UE is supported by ng-eNB.

[0124] In an example, control information (e.g., scheduling information) canbe provided for broadcast and / or multicast operation. The UE can monitor different bundle sizes for the control channel depending on the maximum number of repetitions.

[0125] FIG.16 illustrates an example implementation of a Non-TerrestrialNetwork for a transparent NTN payload: the gNB 106 can be subdivided into non- NTN infrastructure 111 gNB functions and the NTN Service Link provisioning System 115. The NTN infrastructure 112 can be subdivided into the NTN Service Link provisioning System 115 and the NTN Control function 114. The NTN Service Link provisioning System 115 can comprise of one or more NTN payloads 116 and NTN Gateways 117.

[0126] The NTN payload 116 is embarked on a spaceborne (or airborne)vehicle, providing a structure, power, commanding, telemetry, attitude control for the satellite 156 (resp. HAPS) and possibly an appropriate thermal environment, radiation shielding.

[0127] The NTN Service Link provisioning System 115 maps the NR-Uu 120radio protocol over radio resources of the NTN infrastructure 112 (e.g. beams, channels, Tx power).

[0128] The NTN control function 114 controls the spaceborne (or airborne)vehicles as well as the radio resources of the NTN infrastructure 112 (NTN payload(s) 116 and NTN Gateway(s) 117). It provides control data, such as ephemeris, to the non-NTN infrastructure gNB functions 111 of the gNB 106.

[0129] At least the following NTN related parameters can be provided by Oand M 118 to the gNB 106 for its operation: a) Earth fixed beams: for each beam provided by a given NTN-payload 116:- The Cell identifier (NG and Uu) mapped to the beam; - The Cell's reference location (e.g. cell's center and range). b) Quasi Earth fixed beams: for each beam provided by a given NTN-payload: - The Cell identifier (NG and Uu) and time window mapped to a beam; - The Cell's / beam's reference location (e.g. cell's center and range); - The time window of the successive switch overs (feeder link 119, service link 113); - The identifier and time window of all serving satellites 156 and NTN- Gateways. c) Earth moving beams: for each beam provided by a given NTN-payload: - The Uu Cell identifier mapped to a beam and mapping information to fixed geographical areas reported on NG, including information about the beams direction and motion of the beam's foot print on Earth; - Its elevation with respect to NTN-payload; - Schedule of successive serving NTN-Gateways / gNBs; - Schedule of successive switch overs (feeder link 119, service link 113).

[0130] In some implementations, access to a wireless interface can bescheduled, wherein a scheduling entity (e.g.: BS) allocates bandwidth resources for devices and equipment within its service area or cell. As scheduling entity can be configured to schedule, assign, reconfigure, and release resources for one or more subordinate entities. BSs are not the only entities that can function as a scheduling entity. In some examples, a UE 101 (or other device) can function as master node scheduling entity, scheduling resources for one or more secondary nodesubordinate entities (e.g., one or more other UEs 120). Thus, in a wireless communication network with a scheduled access to time—frequency resources and having a cellular configuration, a P2P configuration, and a mesh configuration, a scheduling entity and one or more subordinate entities can communicate utilizing the scheduled resources.

[0131] It will be understood that implementations and embodiments can beimplemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

[0132] Accordingly, blocks of the flowchart illustration support combinationsof means for performing the specified actions, combinations of steps for performing the specified actions and program instruction means for performing the specified actions. The foregoing examples should not be construed as limiting and / or exhaustive, but rather, an illustrative use case to show an implementation of at least one of the various embodiments.

Claims

CLAIMS 1. A method comprising: defining a transport delay range including lower bound (Tmin) and an upper bound (Tmax) for a non-terrestrial network (NTN) fronthaul (FH), the transport delay comprising a downlink transport delay and an uplink transport delay, wherein the transport delay range encompasses only a time when a bit leaves a sender until the bit is received by a receiver, and wherein the transport delay values change with the motion of a satellite.

2. The method of claim 1, further comprising: a maximum amount of time allowed for the transmitter to send all data for a Transmission Window is defined by Tmax – Tmin.

3. The method of claim 2, further comprising: implementing a Reception Window at a receiver configured to allow packets containing samples for a specific symbol to be received in the reception window and still be transmitted by a Radio Unit (RU) at the satellite at a required time.

4. The method of claim 3, wherein the Reception Window has a size that is configured for the maximum amount of time and a transport variation through the fronthaul network.

5. The method of claim 4, wherein the Transmission Window (Tmax – Tmin) is defined by the Reception Window and a maximum for the transport variation.

6. The method of claim 5, wherein the Reception Window has a range that is greater than or equal to the Reception Window and maximum time for the transport variation.

7. A method comprising: determining a transmit window and a receive window for aDistributed Unit (DU) based a transport delay characteristic of a Radio Unit (RU) at a satellite, a Ground based Beam Former (GBBF) and Gateway; and determining a measured transport delay between all DU ports and all RU ports in a time domain; and adjusting the transmit window and receive window based on motion information of the satellite.

8. The method of claim 7, comprising: at a time instance t1, computing a Fronthaul Delay value (T12) 12 = 15 + 5 + 2( )where T15 is a fronthaul latency between DU and GBBF, T5b is a GBBF processing delay, and Tb2 is a feeder link delay; at time instance t2, based on the motion of satellite, varying the feeder link delay Tb2 for an update for the overall Fronthaul Delay value (T12) 12 = 15 + 5 + 2( );inferring at the DU at time instance t2 and updating the overall Fronthaul Delay value (T12) based on the motion of the satellite; and adjusting the DU transmit window and receive window based of the Fronthaul Delay value (T12).

9. The method of claim 7, further comprising: triggering, at a DU, a non-terrestrial network (NTN) measuredtransport method in order to capture the variations in feeder link delay, wherein the triggering has a frequency that is a function of an altitude of the satellite and an elevation angle of the GBBF and Gateway on an Earth station, and wherein the NTN measured transport is a function of a type of the satellite.

10. The method of claim 9, comprising: computing a Fronthaul Delay (T12) as T12 = T15 + T5b + Tb2 where T15 is a fronthaul latency between the DU and the GBBF, T5b is a GBBF processing delay, and Tb2 is a feeder link delay, wherein Tb2 has a variation that depends on the type of the satellite.

11. The method of claim 10, wherein the type of the satellite include a Low Earth Orbit (LEO), a Medium Earth Orbit (MEO) and a Geosynchronous Earth Orbit (GEO), the method further comprising; the feeder link delay for LEO, MEO and GEO satellites beingrespectively. and the variations in the feeder link delay being ,respectively, the variation includes >>whereby the DU triggers the NTN measured transport method and calculates T12 value, and correspondingly adjusts the transmit Window and the receive Window.

12. An non terrestrial network (NTN) system configured for NTN Fronthaul (FH) delay management comprising: a Direct Unit (DU) comprising a Transmit / Receive interface R1 / R4; a Ground based Beam Former (GBBF) comprising a Receive / Transmit interface R5 / R6; a Gateway comprising an Antenna Interface Rb; and a Radio Unit (RU) at a satellite, the RU comprising a Receive / Transmit interface R2 / R3a and an Antenna Interface Ra, wherein the NTN FH is configured for a transport delay range including a lower bound (Tmin) and an upper bound (Tmax), the transport delaycomprising a downlink transport delay and an uplink transport delay, wherein the transport delay range encompasses only a time when a bit leaves a sender (R1 / Rb / R3 / R6) until the bit is received by a receiver (R5 / R2 / Rb / R4), and wherein the transport delay values comprises a feeder link over-the- air delay values that change with the motion of a satellite.

13. The system of claim 12, further comprising a maximum amount of time for a Transmission Window interval that is defined by Tmax – Tmin.

14. The system of claim 13, wherein: the DU is configured with the Reception Window so that the DU allows packets including samples for a specific symbol to be received in the Reception Window and still be transmitted by the RU at the satellite at a required time.

15. The system of claim 14, wherein the Reception Window has a size that is configured for the maximum amount of time and a transport variation through the fronthaul network.

16. The system of claim 15, wherein the Reception Window has a range that is greater than or equal to the reception window and a maximum time for the transport variation.

17. The system of claim 12, wherein the system is configured to at least: determine a transmit window and a receive window for the DU based a transport delay characteristic of the RU, the GBBF and Gateway; and determine a measured transport delay between all DU ports and all RU ports in a time domain; and adjust the transmit window and receive window based on the motion of the satellite.

18. The system of claim 17, wherein the system is configured to at least:at a time instance t1, compute a Fronthaul Delay value (T12) 12 = 15 + 5 + 2( )where T15 is a fronthaul latency between DU and GBBF, T5b is a GBBF processing delay, and Tb2 is a feeder link delay; at time instance t2, based on the motion of satellite, vary the feeder link delay Tb2 for an update for the overall Fronthaul Delay value (T12) 12 = 15 + 5 + 2( );infer at the DU at time instance t2 and updating the overall Fronthaul Delay value (T12) based on the motion of the satellite; and adjust the DU transmit window and receive window based of the Fronthaul Delay value (T12).

19. The system of claim 17, wherein the system is configured to at least: trigger, at a DU, an NTN measured transport method in order to capture the variations in feeder link delay, wherein the triggering has a frequency that is a function of an altitude of the satellite and an elevation angle of the GBBF and Gateway on an Earth station, and wherein the NTN measured transport is a function of a type of the satellite.

20. The system of claim 19, wherein the system is configured to at least: compute a FH Delay (T12) as T12 = T15 + T5b + Tb2 where T15 is a fronthaul latency between the DU and the GBBF, T5b is a GBBF processing delay, and Tb2 is a feeder link delay, wherein a variation of Tb2 depends on the type of the satellite.

21. The system of claim 19, wherein the type of the satellite includes a Low Earth Orbit (LEO), a Medium Earth Orbit (MEO) and a Geosynchronous Earth Orbit (GEO),and wherein the feeder link delay for LEO, MEO and GEO satellites are , ,respectively. and the variations in the feeder link delay are ,respectively, the variation includes the system is configured to at least have the DU trigger the NTN measured transport method and calculate T12 value, and correspondingly adjust the transmit Window and the receive Window.

Images