The blogger has not authorized any person or organization to reprint any original articles of the blogger, thank you for your support for the original!
blogger link
I work for an internationally renowned terminal manufacturer and am responsible for the research and development of modem chips.
In the early days of 5G, he was responsible for the development of the terminal data service layer and the core network. Currently, he is leading the research on technical standards for 6G computing power networks.
The content of the blog mainly revolves around:
5G/6G protocol explanation
computing power network explanation (cloud computing, edge computing, end computing)
advanced C language explanation
Rust language explanation
5G NTN (Non-Terrestrial Networking) Introduction
1. Introduction to the concept of NTN
NTN: Non-Terrestrial Networks
NTN has become the general term for any network involving non-terrestrial flying objects
NTN includes 卫星通信网络, 高空平台系统(HAPS, high altitude platform systems) and 空对地网络, as shown in the figure below.
1.1 Satellite Communication System
The satellite communication network includes low-orbit ( LEO, low Earth orbiting) satellites, medium-orbit ( MEO, medium Earth orbiting) satellites and geosynchronous orbit ( GEO, geosynchronous Earth orbiting) satellites, including satellite platforms . Over the past few years, there has been renewed interest in broadband services provided by LEO NTNs using large satellite constellations such as Starlink, Kuiper and OneWeb.
1.2 HAPS
High Altitude Platform Systems (HAPS) are aerial platforms including aircraft, balloons and airships. In 3GPP's NTN work, the focus is on high-altitude platform stations, the International Mobile Communications Base Station (HIBS). The HIBS system uses the same frequency band as the terrestrial mobile network to provide mobile services.
1.3 Air-to-ground network
The air-to-ground network aims to use ground stations to provide aircraft with in-flight connections. The ground stations play a role similar to base stations in the ground mobile network , but the antennas of the ground stations are tilted upwards, and the distance between stations is much larger than that of the ground mobile network .
So far, the focus of 3GPP's NTN work has been on satellite communication networks, and it is also compatible with supporting HIBS systems and air-to-ground networks. It’s worth noting that 3GPP has also been working on mobile low-altitude unmanned aerial vehicles (UAVs, aka drones), which in a broad sense can be considered part of the NTN family. This blog mainly introduces the satellite communication network.
2. 3GPP standard support for NTN
2.1 R15 version supports NTN
3GPP's work on NR NTN began in 2017, and R15 research focuses on deployment scenarios and channel models. The research is documented in 3GPP TR 38.811 .
The first major goal of the study is to select some reference deployment scenarios for NTN and to agree on key parameters such as architecture, orbital altitude, frequency band, etc. Key scenarios and models include:
- Two frequency ranges, s-band and Ka-band;
- GEO satellites, LEO satellites, and HAPS;
- Beams fixed on the ground (that is, beams that are directed towards a certain area of the earth for as long as possible) and mobile beams (that is, beams that move on the surface of the earth with the movement of satellites);
- Typical footprint sizes and minimum elevation angles for GEO, LEO and HAPS deployments;
- Two types of NTN terminals: handheld terminals and small aperture terminals (VSAT) (equipped with parabolic antennas, usually mounted on buildings or vehicles);
- Antenna models for satellite and HAPS antennas;
The second main goal of the research is to establish the NTN channel model based on the terrestrial 3GPP channel model.
2.2 R16 version supports NTN
3GPP studies how to adapt NR and NTN in R16. The main objective is to determine the minimum set of necessary functions that NR can provide support to NTN (especially satellite communication network) . This includes architectural, higher-level protocol and physical layer aspects. The results of the study are documented in 3GPP TR 38.821 .
NG-RAN supports splitting 5G base station (gNB) into CU (central unit) and DU (distributed unit). Various NTN-based NG-RAN architectures are explored. The conclusion is that no architectural options stand out in particular.
The NR upper layer protocol stack is divided into a user plane (user plane, UP) and a control plane (control plane, CP). The former is responsible for data transmission, and the latter is responsible for signaling. For UP, the main impact comes from the long propagation delay of NTN . On this basis, the impact of long delay on the performance of MAC, RLC, PDCP and SDAP protocols is studied. The conclusion is that MAC needs to enhance Random Access (RA), Discontinuous Reception (DRX), Scheduling Request (SR) and Hybrid Automatic Repeat Request (HARQ) functions . It is recommended to focus on status reporting and sequence numbers at the RLC layer , and Service Data Unit (SDU) discards and sequence numbers at the PDCP layer . For SDAP, it was found that no modifications need to be introduced to support NTN.
For CP, the focus of the study is the mobility management procedure , because of the movement of NTN platforms, especially the movement of low-orbit satellites. For idle mode, NTN-specific system information needs to be introduced . A way of fixing the tracking area can be adopted to avoid frequent updating of the tracking area (TA). It may be beneficial to define additional assistance information for cell selection and cell reselection. For the connection mode, the handover enhancement technology is discussed to solve the frequent handover problem caused by the fast movement of satellites.
From a physical layer perspective, extensive link-layer and system-layer evaluations were performed for S-band and Ka-band. According to the evaluation results, with a suitable satellite beam layout, LEO and GEO can provide handheld user equipment (UE) services in the s-band , and other UEs with high transmit and receive antenna gain (such as VSAT and UEs equipped with appropriate phased array antennas) can be used in the s-band The s-band and ka-band provide both LEO and GEO services. **The conclusion of the study is that R15 and R16 NR functions provide a good foundation to support NTN despite the problems of long propagation delay, Doppler shift and cell mobility in NTN. Enhancements in time relationships, uplink time and frequency synchronization, and HARQ are considered necessary .
2.3 R17 version supports NTN
According to the R16 research results, 3GPP decided to start a work project on NTN in NR R17. The goal is to provide necessary enhancements to NTN-based LEO and GEO networks, while also implicitly supporting HAPS and air-ground networks. This involves physical layer aspects, protocols and architectures, as well as radio resource management (RRM), radio frequency requirements and frequency bands to be used . The point is to haveTransparent Payload Architecture for Earth-fixed Tracking Area and Frequency Division Duplex (FDD) Systems, where all UEs are assumed to be Global Navigation Satellite System (GNSS) capable .
The figure above shows the NTN architecture with transparent payload. The 5G core network is connected to the gNB through the NG interface. The gNB is located on the ground, connected to the NTN Gateway (GateWay), and connected to the NTN Payload (a network node carried on a satellite or HAPS) through a feeder link (Feeder link). NTN Payload is connected to UE through Uu interface and service link (Service link).
In terrestrial NR, the uplink timing depends on the downlink received timing, whose propagation time is usually much smaller than the transmission slot, while in NTN, the propagation time is much longer than the transmission slot.
A GNSS-capable UE can calculate the relative velocity between the UE and the satellite , and the round-trip time (RTT) between the UE and the satellite based on its location and the NTN ephemeris . The UE can calculate and pre-compensate the Doppler frequency from the relative velocity to ensure that its uplink signal is at the desired frequency of the satellite or gNB. gNB provides public TA signal for UE, and sends RTT signal between satellite and gNB . The UE adds the RTT between the UE and the satellite with the common TA to obtain the complete TA . The full TA is used as the offset between the downlink timing received by the terminal and the uplink transmission timing. For example, if downlink slot n starts at time t1, then uplink slot n starts at time t1 minus the full TA. This enables the UE to send uplink transmissions with accurate timing received from the gNB for random access and data transmission in connected mode.
The transmission in NR R16 is based on the continuous transmission of up to 16 stop-and-wait HARQ processes. A HARQ process cannot be used for a new transmission until feedback from a previous transmission has been received . With long RTTs and stop-and-wait protocol, when all HARQ processes are waiting for feedback, the transmission will stop, reducing the communication throughput. To alleviate the stall problem, the number of HARQ processes is increased to 32, which can cover some air-to-ground scenarios . However, 32 HARQ processes are not enough to cover the RTT of NTN-based LEO and GEO . Since it is not desirable to further increase the number of HARQ processes, a scheme of reusing the same HARQ process until a full RTT has elapsed must be employed to avoid pauses . Before multiplexing the HARQ process for downlink transmission after a full RTT, HARQ feedback becomes unnecessary and is therefore disabled. For the uplink without HARQ feedback, the gNB can dynamically decide whether to reuse the HARQ process by sending a new data grant or a retransmission grant (or wait until the uplink transmission is decoded before deciding to send a retransmission grant) before a full RTT has passed.
For the HARQ process with feedback disabled, in order to save power, the UE may not monitor the retransmission allocation after a period of time. When HARQ is not used for retransmissions, link adaptation can target a lower block error rate, but to achieve robustness, higher RLC retransmissions and more RLC status reports are required .
To cover long RTTs in NTN, some MAC and RLC timers are extended . As satellites move, the UE needs to (re)select new satellites, which are based on existing criteria and may also include new criteria, such as when a satellite stops covering the area where the UE is located. Conditional switching has been improved based on the terminal location and the time at which satellites cover the terminal location . The measurement process is enhanced with location-based triggering .
3. Some challenges of NTN
3.1 Latency
The distance between the ground station or terminal and the satellite is very long. Therefore, it takes a considerable time for the radio waves to reach the user equipment. Of course, this delay depends largely on the altitude of the satellite. If the satellite is deployed in geostationary orbit, the delay will be huge. If deployed in LEO, the latency will be very low (in some cases, the latency is even shorter than WiFi provided through terrestrial connections), but with a low-orbit solution like StarLink, it will cost a lot to cover a wide area.
3.2 Ground Station Requirements
Although we can put the radio part (such as gNB, relay, etc.) in space, the core network is on the ground. This means that the satellite or aerial platform should be connected with the ground station at some point. The question is how far away it can connect to ground stations . Obviously, there is a limit to how far a satellite can reach a ground station. Therefore, if we want to cover a larger area, we need a large number of ground stations and satellites. In some cases, setting up a ground station will be very challenging. For example, if we need a satellite to cover Oceania, how do we set up a ground station to interface with those satellites? A possible solution for this situation is to have some satellites gain indirect access to the core network via another satellite rather than a ground station. In order to do this, we need to build a relay network or mesh network between the satellites. Of course, this is theoretically possible and most satcom systems are designed with this in mind. But it is not easy to implement in reality (note that this is also one of the challenges Starlink faced in the early stages).
3.3 Radio Frequency and Antenna Technology
Antenna technology will be a key component of such communication systems. First, how small can we make it? We can live with the necessity of using large dish antennas (large size compared to mobile phone antennas), but everyone would like to have a small dish antenna. Secondly, how to change the radiation direction of the antenna pointing to the satellite? Two options were considered for this. The first option is to put some mechanical components so it can mechanically change the orientation of the plate (like the one used in the Starlink system). But it is difficult to quickly change the direction of the antenna to deal with the movement. The second option is to use a phased array antenna, through which we can electronically change the radiation direction. Technically, this is much better than a mechanical method, but cost will be a big issue.
3.4 Large Doppler Shift
Satellites and spaceborne platforms are usually moving fast, while most terminals are stationary or slowly moving. This means that there will be a huge difference in the relative speed between the satellite and the user terminal. In turn, this means that the receiver experiences a large Doppler shift.
3.4 Large Propagation Delay
The physical distance between the transmitter and receiver is often very large (eg, from a few hundred kilometers (LEO) to 36,000 kilometers (GEO)). This will cause a large propagation delay.
3.4.1 Latency requirements
根据22.261 (R18) - Table 7.4.1-1: UE to satellite propagation delay
Even the smallest propagation delaysmore than theThe maximum delay that RAR's TA can cover. (RAR TA covers about 2ms at SCS 15Khz and 1ms at SCS 30Khz).
4. 3GPP NTN performance requirements
根据22.261 (R18) - Table 7.4.2-1: Performance requirements for satellite access
5. What updates did 3GPP make to solve the above problems
In order to solve the above problems and meet the above requirements, 3GPP R17 has introduced some new features. These new features can be summarized as follows:
- Handle timing offsets with long delays: Added additional timing address information element (
ta-Info-r17) in SIB19; - Handle long HARQ delays due to long distances between UE and gNB: add a new information element (`DL-DataToUL-ACK-v1700) to specify a sufficiently long K1 value;
- Indication of satellite position and motion: A new information element (ephemerisInfo-r17) was added and broadcast in SIB19.
