A Link Switching Method for High and Low Earth Orbit Satellite Hybrid Networks

Abstract

The present invention provides a link switching method for a hybrid network of high and low orbit satellites, including the following steps: Step 1: Specify the UE; Step 2: Determine whether there is a handover task. If so, proceed to the next step; otherwise, continue to execute Step 2; Step 3: Determine whether Source sNB ∈ LEO holds. If so, execute Step 4; otherwise, execute Step a; Step 4: Determine whether the optional LEO sNBs are in an overloaded state. If so, proceed to the next step; otherwise, perform the processing of sNB selection and related algorithm application, and then execute Step d; Step 5: GEO realizes load balancing; Step 6: Determine whether the service type is an online voice / video service. If so, proceed to the next step; otherwise, perform a hard handover based on NIOL and end; Step 7. The beneficial effect of the present invention is that the present invention can improve the success probability of GEO-LEO handover and the user satisfaction of the service area.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular, to a link switching method for a hybrid network of high and low orbit satellites. Background Art

[0002] In recent years, with the increasing rise of geostationary orbit (GEO) satellites and a new generation of large low earth orbit (LEO) satellite constellations globally, the concept of domestic GEO-LEO heterogeneous satellite network integration (HSNI) networking has further fermented. In addition, applications related to 5G technology have become increasingly mature, while the construction of a hybrid network of high and low orbit satellites is still in the stage of theoretical design and laboratory research on single experimental satellites. Therefore, it is of great research significance to apply ground communication system architectures such as 4G long term evolution (LTE), 5G new radio (NR) and other standard architectures to satellite communication systems.

[0003] In the research on HSNI, handover is one of the keys to ensuring the quality of service (QoS) of the system. There are currently many related works on studying the specific handover process based on the LEO satellite communication system. However, there is a lack of related work focusing on the design of the specific handover process of GEO-LEO satellite links. Summary of the Invention

[0004] The present invention provides a link switching method for a hybrid network of high and low orbit satellites, including the following steps:

[0005] Step 1: Specify the UE; Step 2: Determine whether there is a handover task. If so, proceed to the next step; otherwise, continue to execute Step 2; Step 3: Determine whether Source sNB ∈ LEO holds. If yes, then execute Step 4; otherwise, execute Step a; Step 4: Determine whether the optional LEO sNBs are in an overloaded state. If so, enter Step 5; otherwise, perform the processing of sNB selection and related algorithm application, and then execute Step d with the LEO satellite as the Source sNB and the Target sNB; Step 5: GEO realizes load balancing; Step 6: Determine whether the service type is an online voice / video service. If so, proceed to the next step; otherwise, perform a hard handover based on NIOL from the LEO satellite to the GEO satellite and end; Step 7: Perform a soft handover based on NIOL from the LEO satellite to the GEO satellite and end; Step a: Source sNB ∈ GEO, and then execute Step b; Step b: Determine whether the selectable LEO sNBs are not in an overloaded state. If so, execute Step c; if not, continue to execute Step b; Step c: Return to the LEO sNB link, with the GEO satellite as the Source sNB and the LEO satellite as the Target sNB, and then execute Step d; Step d: Perform a soft handover based on IOL and then end.

[0006] As a further improvement of the present invention, in the said Step d, when the Source sNB is a GEO satellite and the Target sNB is a LEO satellite, the soft handover based on IOL includes:

[0007] Step A1, handover preparation phase, including:

[0008] Step HP001, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss.

[0009] Step HP002, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to perform relevant measurement operations according to the indication of the measurement control information at the physical layer.

[0010] Step HP003: The UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information on relevant RSRP and RSRQ. The Source sNB directly decides to initiate a handover operation request based on the situation of the measurement report. The triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover. The measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met.

[0011] Step A2, handover execution phase, including:

[0012] Step HE001: The Source sNB judges the data radio bearer configuration and initiates a DAPS handover, and conveys the handover request to the Target sNB.

[0013] Step HE002 and Step HE003: After the Target sNB prepares the resources, it directly returns an acknowledgment response to the Source sNB. The Source sNB notifies the UE side through the RRC reconfiguration message that it can initiate a handover at this time;

[0014] Step HE004: While executing Step HE003, the Source sNB performs an early state transfer through the Xn-AP interface to convey the downlink count of the first user data unit of the PDCP layer to the Target sNB. However, the uplink data transmission of the user plane still continues through the Source sNB. For the downlink data of the user plane, the downlink data forwarding tunnel between the Source sNB and the Target sNB is completely established. A part of the downlink user data can be changed from the original GW-Source sNB-UE path to be directly transmitted through GW-Source sNB-Target sNB and cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. Another part of the downlink data still transmits through the radio link of the Source sNB.

[0015] In steps HE005, HE006, and HE007, the UE uses a contention-free random access method based on the RACH preamble to access the Target sNB. After the access to the new node is completed, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored, and the user plane data on the GW side is still transmitted to the Source sNB, which is directly transmitted to the Target sNB through the Xn interface data forwarding tunnel. The moment of accessing the Target sNB in the DAPS handover occurs before the UE detaches from the Source sNB. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user level can be completed via the Target sNB link.

[0016] In steps HE008 and HE009, after the UE successfully accesses the Target sNB, the Target sNB notifies the Source sNB that the handover has been successful. The Source sNB transmits the downlink count of the last user data unit through the sNB Status, and then performs the detachment process with the UE side. The relevant links for user data transmission via the Source sNB are completely interrupted here.

[0017] In steps HE010 and HE011, the Target sNB completes the conversion task of the GW downlink data bearer via GCC. After this stage, the downlink data transmission is directly completed through the Target sNB and is no longer indirectly completed by the forwarding tunnel.

[0018] Step A3, the resource release phase, includes:

[0019] Step RR001, the Target sNB notifies the Source sNB via the Xn-AP interface to release all relevant resources and UE context allocated for the handover operation before, and disassembles the data forwarding tunnel between the two.

[0020] Step RR002, the Source sNB returns a response after completing the relevant work.

[0021] As a further improvement of the present invention, in step 6, the hard handover based on NIOL includes:

[0022] Step B1, the handover preparation stage: perform handover measurements and submit the relevant measurement results to the Source sNB. The Source sNB decides whether to initiate a handover based on the measurement results.

[0023] Step B2, Switching Execution Phase: The Source sNB and the Target sNB indirectly convey signaling transmission through the intermediate medium GCC.

[0024] Step B3, Resource Release Phase: Complete the final work of the handover operation, and release relevant channel resources on the Source sNB side and the GW side.

[0025] As a further improvement of the present invention, in the said Step B1, it includes:

[0026] Step HP1, The Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss.

[0027] Step HP2, After receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to perform relevant measurement operations according to the measurement control information indicating the physical layer.

[0028] Step HP3, The UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information about relevant RSRP and RSRQ. The Source sNB then directly decides to initiate a handover operation request according to the situation of the report; The triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover; The measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell every once in a while, and the latter only reports when the required conditions are met.

[0029] As a further improvement of the present invention, in the said Step B2, it further includes:

[0030] Step HE1, The Source sNB sends a handover request message to the GCC through the NG-AP interface, and attaches the base station ID of the Target sNB.

[0031] Step HE2, After receiving the handover request and obtaining the base station ID of the Target sNB therefrom, the GCC informs the Target sNB to make relevant resource reservation work through the NG-AP interface.

[0032] Step HE3, After the Target sNB finishes preparing the resources, it returns a handover confirmation response. The response message contains the random access channel preamble allocated by the Target sNB for the UE, the GTP-U interface IP address and tunnel endpoint identifier allocated for the GW, and the transport layer IP address and TEID allocated for the forward data forwarding of the Source sNB.

[0033] Step HE4: After GCC receives the response from the Target sNB, it notifies the GW of the relevant message through the GTP-C interface.

[0034] Step HE5: After the GW completes the allocation of relevant resources, it returns a response to GCC.

[0035] Step HE6: After GCC confirms the establishment of the downlink data indirect forwarding tunnel, it notifies the Source sNB through the NG-AP interface that the reservation and allocation of relevant resources have been completed, and initiates a handover command.

[0036] Step HE7: After receiving the message, the Source sNB encapsulates the ID of the Target sNB and the RACH preamble allocated by the Target sNB for the UE in the RRC reconfiguration message and sends it to the UE side at the RRC layer.

[0037] Steps HE8 and HE9: While the Source sNB is executing Step HE7, it sends a status transfer message to the Target sNB indirectly through GCC on the NG-AP interface, which contains the sequence number record of the user data packet transmission process; at this time, for the downlink data of the user plane, the downlink data forwarding tunnel of Source sNB-GW-Target sNB has been fully established, and the downlink user plane data is changed from the original GW-Source sNB-UE path to GW-Source sNB-GW-Target sNB for transmission, and is cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established; for the uplink data of the user plane, it still transmits along the path of UE-Source sNB-GW, but when the UE receives the RRC reconfiguration message in Step HE7 and parses the handover execution command, it immediately disconnects the RRC layer connection with the Source sNB and enters the RRC Idle state. At this time, the uplink transmission path of the user plane data UE-Source sNB-GW is forced to be interrupted.

[0038] In step HE10, step HE11 and step HE12, the UE initiates a non-contention random access request to the Target sNB to avoid collision and reduce latency by using the RACH preamble code specially allocated to it by the Target sNB obtained in step HE7. The Target sNB receives the access request and adjusts the reserved uplink resources to form a RACH response. Then the UE returns an RRC reconfiguration completion message, completes uplink synchronization with the Target sNB, and enters the RRC Connected state from the RRC Idle state. After completing the access of the new node, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE is also successfully opened. At this time, the user data service is successfully restored. However, at this time, the user plane data on the GW side is still transmitted to the Source sNB, and then the Source sNB indirectly transmits it to the Target sNB through the GW via the data forwarding tunnel.

[0039] In step HE13, the Target sNB informs the GCC through the NG-AP that the handover command is executed.

[0040] In steps HE14 and HE15, after the GCC learns that the switching task is completed, it requests the GW to adjust the user data bearer through the GTP-C interface, and changes the downlink user data path from GW-Source sNB to GW-Target sNB. After receiving the request message, the GW immediately adjusts the data bearer, transfers all data from the GTP-U interface facing the Source sNB to the GTP-U interface facing the Target sNB for transmission, and returns a bearer adjustment response. At this time, the downlink user data path is successfully adjusted to GW-Target sNB-UE.

[0041] As a further improvement of the present invention, in step B3, it further includes:

[0042] In step RR1, the GCC notifies the Source sNB via the NG-AP interface to release all related resources and UE contexts previously allocated to complete the handover operation.

[0043] Step RR2: After completing the related release work, Source sNB returns a release completion response via the NG-AP interface.

[0044] In step RR3, the GCC notifies the GW via the GTP-C interface to dismantle the data forwarding tunnel and release all related resources previously allocated to achieve data forwarding from the Source sNB to the Target sNB.

[0045] Step RR4: After completing the related release work, GW returns a release completion response via the GTP-C interface.

[0046] As a further improvement of the present invention, in the said step 7, the soft handover based on NIOL includes:

[0047] Step C1, handover preparation stage, including:

[0048] Step HP0001, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss.

[0049] Step HP0002, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to execute relevant measurement operations at the physical layer according to the indication of the measurement control information.

[0050] Step HP0003, the UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information about relevant RSRP and RSRQ. The Source sNB then directly decides to initiate a handover operation request according to the situation of the measurement report; the triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover; the measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met.

[0051] Step C2, handover execution stage, including:

[0052] Step HE0001 and Step HE0002, the Source sNB judges the DRB configuration and initiates a DAPS handover, and indirectly conveys the handover request to the Target sNB through GCC.

[0053] Step HE0003, after the Target sNB finishes preparing resources, it returns a confirmation response to GCC.

[0054] Step HE0004 and Step HE0005, GCC notifies the Source sNB, and then the Source sNB notifies the UE that the current state can perform the handover operation.

[0055] In Steps HE0006 and HE0007, while the Source sNB is executing Step HE0005, it performs an early state transfer to the Target sNB indirectly through GCC via the NG-AP interface to convey the downlink count of the first user data unit at the PDCP layer to the Target sNB. At this time, the uplink data transmission of the user plane still continues via the Source sNB. For the downlink data of the user plane, an indirect data forwarding tunnel of Source sNB-GW-Target sNB is successfully created. A part of the user plane downlink data can be transmitted indirectly via GW-Source sNB-GW-Target sNB instead of the original GW-Source sNB-UE path and is cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. Another part of the downlink data still is transmitted via the radio link of the Source sNB.

[0056] In Steps HE0008, HE0009 and HE0010, the UE accesses the Target sNB using a contention-free random access method based on the RACH preamble. After the access to the new node is completed, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored. At this time, the user plane data on the GW side still is transmitted to the Source sNB, and the Source sNB directly transmits it to the Target sNB via the data forwarding tunnel of the Xn interface. The moment of accessing the Target sNB under DAPS handover occurs before the UE detaches from the Source sNB. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user layer can be completed via the Target sNB link.

[0057] In Steps HE0011, HE0012, HE0013 and HE0014, after the UE side successfully accesses the Target sNB, the Target sNB indirectly notifies the Source sNB that the handover is successful through GCC. The Source sNB then indirectly transmits the downlink count of the last user data unit to the Target sNB via GCC, and then performs the detachment process with the UE side. The relevant links for user data transmission via the Source sNB are completely interrupted here.

[0058] In Steps HE0015 and HE0016, the conversion task of the GW downlink data bearer is achieved. After this stage, the downlink data transmission is directly completed via the Target sNB.

[0059] Step C3, the resource release phase, includes:

[0060] Step RR0001 and Step RR0002, which implement the release of the UE-side context and destroy the indirect data forwarding tunnels mentioned in Step HE0006 and Step HE0007.

[0061] The beneficial effects of the present invention are as follows: 1. The link switching method of the present invention can improve the success probability of GEO-LEO handover and the user satisfaction in the service area; 2. The link switching method of the present invention provides a reference for the high-low orbit satellite network and greatly supports the flexibility of future network technologies. Description of the Drawings

[0062] Figure 1 is the network architecture diagram of the high-low orbit satellite hybrid network of the present invention;

[0063] Figure 2 is the flowchart of the high-low orbit satellite link hard handover based on NIOL of the present invention;

[0064] Figure 3 is the schematic diagram of the A3 event trigger period report of the present invention;

[0065] Figure 4 is the virtualized core network structure of the high-low orbit satellite hybrid network of the present invention;

[0066] Figure 5 is the flowchart of the high-low orbit satellite link hard handover based on NFV+IOL of the present invention;

[0067] Figure 6 is the dual-connection schematic diagram of the DAPS-UE seamless handover of the present invention;

[0068] Figure 7 is the high-low orbit satellite link seamless handover process of NFV+IOL+DAPS of the present invention;

[0069] Figure 8 is the flowchart of the HE phase of the DAPS seamless handover of the present invention;

[0070] Figure 9 is the high-low orbit satellite link seamless handover process of NFV+NIOL+DAPS of the present invention;

[0071] Figure 10 is the handover strategy flowchart of the GEO-LEO satellite hybrid network of the present invention;

[0072] Figure 11 is the structural diagram of the high-low orbit satellite hybrid network based on the SDN architecture of the present invention;

[0073] Figure 12It is the flowchart of the HJ stage under the SDSN architecture of the present invention. Detailed implementation manners

[0074] A link switching method for a high and low earth orbit satellite hybrid network disclosed by the present invention is based on the network background of the high and low earth orbit satellite hybrid, and the following specific work is carried out around link switching:

[0075] The specific process of GEO-LEO satellite link switching in the high and low earth orbit satellite hybrid network is designed. Combining the relevant 3GPP protocol standards of the ground cellular communication network architecture, taking the two types of handovers of the ground radio link (S1 / NR handover and X2 / Xn handover) as the starting point, the present invention considers the selection situation of the Inter Orbit Link (IOL), and theoretically improves and analyzes the process by combining Network Functions Virtualization (NFV) and Software Define Network (SDN) technologies. Subsequently, aiming at the problem of high Handover Interruption Time (HIT) in the scenario of LEO satellite switching to GEO satellite due to load balancing in the background of real-time voice and video services, a seamless handover mechanism under multi-antenna bearing devices is added to optimize the current situation of HIT, and an effective strategy for GEO-LEO satellite link switching is given theoretically.

[0076] The present invention mainly consists of the following three parts:

[0077] I. Design and analysis of the hard handover process of GEO-LEO satellite link

[0078] II. Design and analysis of the seamless handover process of GEO-LEO satellite link

[0079] III. Design of the high and low earth orbit satellite link switching strategy based on I and II

[0080] ● Design and analysis of the hard handover process of GEO-LEO satellite link

[0081] This part is further divided into two sub-parts. First is the design and analysis of the hard handover process based on Non Inter Orbit Link (NIOL).

[0082] The network architecture of the high and low earth orbit satellite hybrid network is as Figure 1As shown in the figure. The access network part under this hybrid satellite network architecture is jointly composed of GEO satellites and LEO satellites. The Ground Control Center (GCC) can be analogous to the Mobile Management Entity (MME) in the 4G LTE network architecture and the Access and Mobility Management Function (AMF) in the 5G NR network architecture. Together with the Ground Gateway (GW) part, it constitutes the core network of the satellite network.

[0083] Based on the mature terrestrial LTE S1 handover and 5G NR wireless communication network architectures, without considering the Inter Orbit Link (IOL) between GEO satellite base stations and LEO satellite base stations, and integrating satellite base stations as base station components into the cellular communication ecosystem, a hard handover process for high and low orbit satellite links based on NIOL (hereinafter referred to as hard handover based on NIOL) as shown in Figure 2 the figure can be designed. The overall process shown can be divided into three stages: the Handover Preparation (HP) stage, the Handover Execution (HE) stage, and the Resources Release (RR) stage. The Source satellite eNodeB (Source sNB) is the intelligent entity in the handover process, and it directly determines whether to initiate the handover.

[0084] (1) Stage HP corresponds to Figure 2 steps HP1 to HP3 in the figure. The main task of this stage is to perform handover measurements and deliver the relevant measurement results to the Source sNB, and the Source sNB decides whether to initiate a handover based on the measurement results.

[0085] Step HP1: The Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The control information mainly includes the Reference Signal Receiving Power (RSRP), the Reference Signal Receiving Quantity (RSRQ), and the path loss, etc.

[0086] HP2: After receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to perform relevant measurement operations at the physical layer according to the indication of the measurement control information.

[0087] HP3: The UE continuously measures and uploads a measurement report (MR) to the Source sNB when a certain trigger event (TE) is satisfied. The report contains relevant information such as RSRP and RSRQ. The Source sNB directly decides to initiate a handover operation request based on the report. The TE is divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover. Specifically, there are events A1 - A5 and B1 - B2; The MR is divided into periodic MR and triggered MR according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when a certain condition is met.

[0088] For the satellite - to - ground link situation of high - and low - orbit satellite networks, a triggered - periodic reporting method combining triggered and periodic types is designed and selected, and the A3 trigger event that takes into account the load - balancing requirements is studied. This event is shown in Equation (1.1):

[0089] M n +O fn +O cn -H ys >M s +O fs +O cs +O ff (1.1)

[0090] Where, M n and M s are the RSRP or RSRQ measurement results of the UE's physical layer for the target satellite node (Target satellite eNodeB, Target sNB) and the Source sNB; O fn and O fs are the frequency - specific biases of the Target sNB and the Source sNB; O cn and O cs is also a bias, but this bias is determined by the measurement control information sent by the Source sNB in HP1. The Source sNB can rewrite it temporarily according to the load situation and is used to trigger the load - balancing handover; H ys represents the hysteresis parameter; O ff represents the bias of event A3. The larger the value, the greater the difficulty of triggering, and the purpose of delaying the handover can be achieved. The schematic diagram of the triggered - periodic reporting triggered by event A3 is as Figure 3 shown.

[0091] Generally speaking, the trigger formula for event A3 can be shown as Equation (1.2):

[0092] M n +Offset all >Ms (1.2)

[0093] Among them, Offset all represents the sum of the offsets affected by all the offsets that trigger the handover condition, and satisfies Offset all = O fn + O cn - H ys - O fs - O cs - O ff , Offset all The larger the value, the earlier the trigger moment is entered, and the smaller the difficulty of handover. The setting of the trigger time (Time To Triger, TTT) can, to a certain extent, avoid the ping-pong effect and reduce unnecessary handovers. Therefore, when the RSRP or RSRQ of the Target sNB is higher than that of the Source sNB and lasts for more than TTT, the UE can form a measurement report and perform periodic reporting.

[0094] (2) Phase HE corresponds to steps HE1 to HE15 in the figure. Since there is no IOL between the Source sNB and the Target sNB, the signaling transmission between the two must be indirectly conveyed through the intermediate medium GCC.

[0095] Step HE1: The Source sNB sends a handover request message to the GCC through the NG-AP interface, and attaches the base station ID of the Target sNB.

[0096] Step HE2: After receiving the handover request and obtaining the base station ID of the Target sNB from it, the GCC informs the Target sNB to make relevant resource reservations through the NG-AP interface.

[0097] Step HE3: After the Target sNB finishes preparing the resources, it returns a handover confirmation response, and the response message contains the random access channel (Random Access Channel Preamble, RACH) preamble allocated by the Target sNB for the UE, the GTP-U interface IP address and tunnel endpoint identifier (Tunnel Endpoint Identifier, TEID) allocated for the GW, and the transport layer IP address and TEID allocated for the forward data forwarding of the Source sNB.

[0098] Steps HE4 - HE5: After receiving the response from the Target sNB, the GCC informs the GW of the relevant message through the GTP-C interface. After the GW completes the allocation of relevant resources, it returns a response to the GCC.

[0099] Step HE6: After GCC confirms the establishment of the downlink data indirect forwarding tunnel, it notifies the Source sNB via the NG-AP interface that the reservation and allocation of relevant resources have been completed, and the handover command can be initiated.

[0100] Step HE7: After receiving the message, the Source sNB encapsulates relevant information such as the ID of the Target sNB and the RACH preamble allocated by the Target sNB for the UE in the RRC reconfiguration message and sends it to the UE side at the RRC layer.

[0101] Steps HE8-HE9: While the Source sNB is executing Step HE7, it indirectly sends a Status Transfer (ST) message to the Target sNB via GCC on the NG-AP interface, which contains the record of the sequence number (SN) during the user data packet transmission process. This information can ensure the correct continuity of user-plane data before and after the handover. At this time, for the downlink data of the user plane, the downlink data forwarding tunnel of Source sNB-GW-Target sNB has been fully established. The downlink user data is transferred from the original GW-Source sNB-UE path to GW-Source sNB-GW-Target sNB and is cached in the Target sNB until the downlink data channel is established between the Target sNB and the UE. For the uplink data of the user plane, it still travels along the UE-Source sNB-GW path. However, when the UE receives the RRC reconfiguration message in HE7 and parses the handover execution command, it immediately disconnects from the Source sNB at the RRC layer and enters the RRC Idle state. At this time, the uplink transmission path of the user-plane data UE-Source sNB-GW is forced to be interrupted. It should be noted that before the moment when the control signaling in Step HE7 reaches the UE side, the UE can still receive the last user data packet sent by the Source-sNB before the data interruption, and after that moment, the UE performs the interruption operation of the uplink user data channel. Therefore, the moment between the UE receiving the control signaling and performing the interruption operation is the moment of user data service interruption.

[0102] Steps HE10-HE12: The UE initiates a non-contention random access request to the Target sNB to avoid collision and reduce latency, instead of an ordinary contention-based random access request, by means of the RACH preamble code obtained in step HE7 and specially allocated by the Target sNB. The Target sNB receives the access request and adjusts the reserved uplink resources to form a RACH response. The UE then transmits back the RRC reconfiguration completion message, completes uplink synchronization with the Target sNB, and enters the RRC Connected state from the RRC Idle state. It should be noted that steps HE10-12 are mainly a concise description of the specific process of the UE accessing the Target sNB at the RRC layer. The actual signaling is more than the three signalings shown in the figure. After completing the access to the new node, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE is also successfully opened. At this time, the user data service is successfully restored. However, at this time, the user plane data on the GW side is still transmitted to the Source sNB, and then the Source sNB is indirectly transmitted to the Target sNB through the GW via the data forwarding tunnel.

[0103] Step HE13: The Target sNB informs the GCC through the NG-AP that the handover command has been executed.

[0104] Steps HE14-HE15: After the GCC learns that the handover task is completed, it requests the GW to adjust the user data bearer through the GTP-C interface, and changes the downlink user data path from GW-Source sNB to GW-Target sNB. After receiving the request message, the GW immediately adjusts the data bearer, transfers all data from the GTP-U interface facing the Source sNB to the GTP-U interface facing the Target sNB, and returns a bearer adjustment response. At this time, the downlink user data path is successfully adjusted to GW-Target sNB-UE.

[0105] (3) Phase RR corresponds to steps RR1 to RR4 in the figure. The main task of this phase is to complete the handover operation and release the relevant channel resources on the Source sNB side and the GW side.

[0106] Steps RR1-RR2: GCC notifies Source sNB via the NG-AP interface to release all related resources and UE contexts previously allocated to complete the handover operation. After completing the related release work, Source sNB returns a response indicating that the release is completed.

[0107] Steps RR3-RR4: GCC notifies GW via the GTP-C interface to dismantle the data forwarding tunnel and release all related resources previously allocated to achieve data forwarding from Source sNB to Target sNB. After completing the related release work, GW returns a response indicating that the release is completed.

[0108] In step RR4, the GCC receiving the GW response indicates that the NIOL-based hard handover process is completely completed.

[0109] like Figure 2 As shown in the figure, the handover timer starts counting from the moment when the Source sNB triggers the handover and decides to send the handover request signaling to the GCC through the NG-AP interface, until the completion of step RR4 marks the complete end of the handover, and the timer stops counting. The whole period of time is the handover delay (HL) of the handover operation. The service interruption time (HIT) in the handover can be defined as the duration from the moment when the UE interrupts the data transmission with the Source sNB to the moment when the UE resumes the data transmission with the Target sNB. More specifically, HIT actually refers to the time interval between the last user data packet received by the UE at the Source sNB and the first user data packet received at the Target sNB. In the link switching of wireless networks, HL and HIT are two very important performance evaluation indicators. The larger the former, the longer it takes to complete the switching operation, and the lower the probability of successful switching. The latter directly affects user satisfaction. The 3GPP TS 22.278 protocol proposes a recommendation on the interruption time of voice service continuity in the requirements for EPS core network services. The recommendation points out that the interruption time should not exceed 300ms, otherwise the user will clearly feel the interruption of the call.

[0110] For the ground wireless communication network architecture, the interface between UE and base station is an air interface, and the propagation speed of electromagnetic waves in the air is nearly 3×10 8 m / s. The transmission speed of optical fiber wired connection is also 2×10 8m / s. Therefore, compared with the processing delay of control signaling between entities on the ground, its propagation delay can generally be ignored. For the high and low earth orbit satellite communication network architecture, since the interfaces between the satellite base station and the UE side and the GCC side are all air interfaces, considering the influence of the Van Allen belt, the minimum distance between the LEO satellite and the ground is limited to between 200 - 1600 km. However, the minimum distance from the GEO satellite to the ground reaches 35768 km. Compared with the processing delay, the propagation delay cannot be ignored at this time, and for the signaling process related to the GEO satellite, its propagation delay dominates the total delay. Based on this, considering the propagation delay as the main consideration for optimizing the signaling in the handover process, the total and As shown in Equations (1.3) and (1.4):

[0111]

[0112]

[0113] Each term in the formula represents the propagation delay between a certain node and other nodes.

[0114] There has been a lot of research work on the handover of LEO satellite network links. In the high and low earth orbit satellite hybrid network, when resources are sufficient, it is generally preferred to use LEO satellites for communication. For the general scenario of handover from a GEO satellite to a LEO satellite, the LEO satellite will be used as the Target sNB. In steps HE10 - 13, the UE's access to the Target sNB will involve more than 3 control signaling. However, due to the propagation of light, the one-way propagation delay caused by the propagation between the LEO satellite and the ground will not exceed 15 ms at most. Therefore, from the user's perspective, it is still acceptable. Due to the requirement of multi-service and large capacity for future satellite Internet, considering the current large load of wireless transmission services and the urgent need for GEO satellites to assist LEO satellites in achieving load balancing, the trigger for handover from LEO satellites to GEO satellites is likely to occur. At this time, the GEO satellite is used as the Target sNB. Even considering the minimum distance of 35786 km between the GEO satellite and the ground, the one-way propagation delay of a signaling will increase by at least 110 ms, which will greatly increase the values of the performance indicators HL and HIT, resulting in a higher handover failure probability and lower user satisfaction.

[0115] For the overall signaling process of compression handover operations, to reduce the propagation delay of the overall handover process of GEO-LEO satellites and take into account the signaling load resources consumed to complete the handover operation, in the second subpart, considering the application of NFV technology, one of the key technologies in current 5G commercial use, and combining with the IOL technology already implemented in the current Starlink program, a theoretical improvement is made to the handover process based on NIOL to further improve the success probability of GEO-LEO handover and the user satisfaction in the service area.

[0116] NFV is a network architecture concept based on the complete decoupling technology of software and hardware. It can realize software-based operations on almost all network function nodes based on general-purpose hardware and utilize the hardware device resources of all network entities. More specifically, it can enable network entities traditionally implemented through proprietary hardware to be replaced by virtual machines (VMs). Multiple VMs can share the shared resources on a single physical machine, and the software can run on the VMs to provide the same functions. NFV technology can break many limitations of network dedicated hardware, not only greatly improving the resource utilization rate of hardware but also significantly reducing the capital expenditures (CAPEX) and operating expenditures (OPEX) of network operators in aspects such as network construction and equipment maintenance. In addition, adopting NFV technology in the network can also conveniently and effectively expand and modify the network, with lower complexity and greater network elasticity compared to traditional networks. The industry consensus is that the 5G network currently being built must be a highly automated intelligent network. NFV technology has already become the main arena for 5G. Although the virtualization level of the network architecture function nodes of current large-scale operators has not reached 100%, NFV technology is also constantly developing and progressing.

[0117] For the network entities GW and GCC in the context of the high-low orbit hybrid network discussed in the present invention, NFV technology can also be used to provide an optimized control plane and data plane through virtualization, replace the corresponding nodes with different virtual machines on a single physical machine, realize the integration of network function nodes, minimize the transactions occurring on the physical network, reduce network control traffic, and thus optimize the link handover process based on NIOL, reducing costs, power consumption, and network complexity to a certain extent. Therefore, in view of the trend of virtualization of terrestrial mobile networks, the terrestrial core network of the high-low orbit satellite hybrid network based on NFV technology can be virtualized as Figure 4As shown in the figure. On the left side of the figure is the traditional core network architecture with a distributed hardware organization, and on the right side is the virtualized core network (VCN) architecture designed based on Elastic Compute Service (ECS), that is, cloud servers.

[0118] The functions of each node in the traditional core network are all implemented based on proprietary hardware. Data is transmitted between nodes through wired connections. The nodes shown are only the main parts in the real core network, and there are many functional nodes actually involved. Therefore, the proprietary devices in the core network are also very complex. VCN is completely based on general server hardware, breaking the limitations of proprietary hardware, and can flexibly allocate virtual hardware resources. Each node can coordinate the release and expansion of resources according to its own resource requirements. When it comes to large-volume data service transmission, increasing resources in the user plane as much as possible can bring higher transmission rates, thereby further improving user satisfaction. And due to the aggregation of VCN network nodes in cloud servers, the propagation delay between the original ground nodes can no longer be considered. HL represented by Equation (1.3) can be optimized as shown in Equation (1.5):

[0119]

[0120] Compared with the traditional core network architecture, due to the aggregation of GCC and GW, there is almost no wired link connection propagation between GCC and GW. Therefore, the VCN architecture can Figure 4 delete steps HE4-HE5, steps HE14-HE15, and steps RR3-RR4 from the perspective of propagation delay on the basis of, effectively reducing the traffic load at the control signaling level and achieving the best theoretical optimization of the propagation delay between ground segment network nodes. However, for satellite communication networks, the communication between the satellite and the ground still needs to be mainly considered in terms of propagation delay.

[0121] Referring to the LTE X2 handover and NR Xn handover of the mature ground network architecture, considering that there is an available IOL between GEO satellites and LEO satellites, on the basis of the virtualized core network, the hard handover process of high and low orbit satellite links based on NFV and IOL (referred to as hard handover based on IOL) as shown in Figure 5 can be improved.

[0122] Compared with Figure 2 , considering the IOL means that a direct link can be established between Source sNB and Target sNB to transmit data. The hard handover of the link based on IOL has the following key features:

[0123] · Considering that both the Source sNB and the Target sNB are served by the same GCC, the entire handover process is basically directly executed by the two sNBs;

[0124] · GCC only participates in the user downlink path exchange from the GW side to the Target sNB side, is responsible for forwarding the signaling related to the exchange path, and there will be no direct signaling communication with the Source sNB;

[0125] · The tunnel requirement for indirect forwarding of downlink data at the user level no longer exists, and the release of resources of the Source sNB after the handover is completed no longer passes through the control of GCC. The triggering and execution of relevant signaling transmissions are entirely entrusted to the Target sNB.

[0126] During the handover process, the Source sNB is still the handover intelligent entity, and the decision to initiate the handover directly depends on it. The overall handover process changes little except for the HE stage.

[0127] (1) In the HP stage, there is no change, corresponding to steps HP01 to HP03 in the figure.

[0128] (2) The HE stage corresponds to steps HE01 to HE09 in the figure. Considering the IOL between the Source sNB and the Target sNB, the signaling transmission between the two no longer needs to be indirectly conveyed through the intermediate medium GCC, and the downlink data forwarding tunnel can be directly established and data transmission caching can be performed.

[0129] Step HE01: The Source sNB directly sends a handover request message to the Target sNB through the Xn-AP interface, notifying it to make relevant resource reservations.

[0130] Step HE02: After the Target sNB finishes preparing the resources, it directly returns an acknowledgment response to the Source sNB. The response message contains the RACH Preamble allocated for the UE, informing the Source sNB that the relevant resource reservation and allocation work has been completed and the UE can be notified to perform relevant handover operations.

[0131] Step HE03: After receiving the message, the Source sNB encapsulates the information related to the ID of the Target sNB and the RACH preamble allocated for the UE by the Target sNB in the RRC reconfiguration message and sends it to the UE side at the RRC layer.

[0132] Step HE04: While executing HE3, Source sNB directly sends the ST message to Target sNB through the Xn-AP interface, which contains the sequence number SN record of the user data packet transmission process. In addition, different from before, for the downlink data of the user plane, the downlink data forwarding tunnel between Source sNB and Target sNB is completely established, and the downlink user data can be directly transmitted from the original GW-Source sNB-UE path to GW-Source sNB-Target sNB, and is cached in Target sNB until the downlink data channel between Target sNB and UE is established.

[0133] Steps HE05 - Step 07: UE also uses the contention-free random access method based on RACH preambles to access Target sNB. After the access to the new node is completed, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from Target sNB to UE is also successfully established, and at this time the user data service is successfully restored. However, at this time, the user plane data on the GW side is still transmitted to Source sNB, and Source sNB directly transmits it to Target sNB through the data forwarding tunnel of the Xn interface.

[0134] Steps HE08 - Step 09: Target sNB completes the task of path bearer switching with GCC through the NG-AP interface.

[0135] (3) Phase RR corresponds to steps RR1 to RR2 in the figure. Since there is no need for a downlink data indirect forwarding tunnel, there is no need to disassemble this channel in this phase.

[0136] Steps RR1 - RR2: Target sNB notifies Source sNB through the Xn-AP interface to release all relevant resources and UE context allocated for the handover operation before, and disassemble the data forwarding tunnel between the two. After Source sNB completes the relevant work, it returns a response.

[0137] When Target sNB receives the response from Source sNB in step RR2, it marks that the handover process has been completely completed.

[0138] Figure 5 The handover process considering the existence of IOL has significantly optimized the number of handover signaling, that is, the traffic load of the control signaling to a certain extent. However, the improvement effect of its overall propagation delay needs to be judged according to different handover scenarios of high and low orbit satellites. Equation (1.5) after optimization is shown as Equation (1.6):

[0139]

[0140] The spatial scenario considers that GCC is located at a certain place in the Guangdong-Hong Kong-Macao region of China, with a vertical straight-line distance of about 2,500 km from the equator. Referring to the orbital altitude of 1,200 km of the first LEO broadband satellite launched by China in 2020, taking the geostationary orbit (GSO) satellite closest to a ship terminal at the Pearl River Estuary as an example, considering the difference in the space-ground distance between it and the LEO satellite directly above the ship, the angular deviation between it and the LEO satellite, UE, and GCC can be ignored. By applying simple mathematical operations, the space-ground distance of the GEO satellite is about 35,800 km. For the convenience of calculation, it is considered that the space-ground distance of the GEO satellite is 36,000 km, and the space-ground distance of the LEO satellite is 1,200 km. The difference between the two distances is used as the distance between the two satellites. The optimization effects of different handover scenarios in this spatial scenario are shown in Table 1. In the table, diff T represents the time difference, and diff D represents the distance difference, and e reflects the theoretical optimization effect.

[0141] Table 1 Optimization effect of GEO(LEO) to LEO(GEO) handover based on NFV combined with IOL

[0142]

[0143] For the handover scenario of switching from a GEO satellite to a LEO satellite, in the context of the above spatial scenario, the propagation delay can be reduced by about 260 ms. For the handover scenario of switching from a LEO satellite to a GEO satellite due to load balancing requirements, although the signaling traffic load of the overall network has been significantly reduced, the propagation delay has increased by about 320 ms. This is directly caused by the huge difference in the space-ground distance between the high and low orbit satellites in the high-low orbit satellite hybrid network. Based on this, from the perspective of optimizing HL, for the link hard handover design of the high-low orbit satellite hybrid network, consider preferentially adopting the handover strategy based on IOL when switching from a GEO satellite to a LEO satellite, and preferentially adopting the handover strategy based on NIOL when switching from a LEO satellite to a GEO satellite.

[0144] ● Design and analysis of the seamless handover process of the GEO-LEO satellite link

[0145] In the context of real-time voice and video services, for the scenario of switching from a LEO satellite to a GEO satellite, considering the "break before make" characteristic of hard handover and the current situation that the above-mentioned design and improvement of link hard handover cannot optimize HIT, and in view of the extreme characteristic of the space-ground distance of the GEO satellite, consider adding the design of "make before break" soft handover, that is, seamless handover mode, in this network architecture.

[0146] The seamless handover mode is exactly the opposite of the hard handover mode. It enables the UE to continue maintaining data transmission on the link with the Source sNB during the handover process. Only after the UE establishes stable communication with the Target sNB is the link transmission between the UE and the Source sNB interrupted. Therefore, the UE under the seamless handover mechanism has a need for dual connectivity, requires hardware support, should have at least two antennas on the device, and in terms of the user protocol stack, the UE side generally should also have the characteristics of a Dual Active Antenna Stack (DPAS).

[0147] In terrestrial communication networks, the handover mechanisms adopted by 4G LTE and early 5G NR are both hard handover mechanisms. The UE must first release the link from the source cell before it can perform the operation of establishing a link and accessing the target cell. Therefore, before the UE accesses the target cell after releasing the link of the source cell, the communication between the user layer and the base station will inevitably cause a certain degree of interruption, and this interruption at the user layer is very fatal for use cases of 5G Ultra Reliable Low Latency Communication (URLCC). Therefore, 3GPP proposed the DAPS technology in Release 16. This technology enables the UE to always remain in the connected transmission state with the source cell. After the UE successfully establishes a stable link transmission with the target cell, the link release between the UE and the source cell is then performed.

[0148] Therefore, for the real-time voice and video services in the hybrid network of high and low orbit satellites, for the high HIT situation scenario of LEO satellite handover to GEO satellite, considering adopting the DAPS technology on the UE side, the schematic diagram of the UE with dual protocol stacks and its dual connectivity communication is as Figure 6 shown.

[0149] Among them, RLC_S represents the RLC layer between the UE and the Source sNB, and RLC_T represents the RLC layer between the UE and the Target sNB. The same applies to others. Since the UE needs to receive user layer data from both the Source sNB and the Target sNB during the handover process, the PDCP layer of the UE with dual protocol stacks is reconfigured into a common PDCP entity, and by strictly maintaining the continuity of the PDCP sequence number, i.e., SN, during the handover process, it can ensure that the transmission of user data strictly follows the established order.

[0150] Based on the idea of DAPS, considering that the UE side has dual protocol stacks, it can be designed as Figure 7The theoretical HIT seamless handover process shown is 0 ms. Compared with hard handover, seamless handover poses requirements for dual antennas at the hardware level, increasing a certain level of complexity and cost. It also poses resource requirements for simultaneously occupying two channels at the resource level, enhancing the intensity of channel resource occupation.

[0151] Compared with Figure 5 , considering that the UE has DAPS means that the UE can establish links with both the Source sNB and the Target sNB simultaneously and perform data transmission. The specific process changes still focus on the HE stage. The more detailed DAPS-based link seamless handover process (abbreviated as IOL-based soft handover) is as follows:

[0152] Step HE001: The Source sNB determines the Data Radio Bearer (DRB) configuration and initiates a DAPS handover, conveying the handover request to the Source sNB.

[0153] Steps HE002 - HE003: After the Target sNB finishes preparing the resources, it directly returns an acknowledgment response to the Source sNB. The Source sNB notifies the UE side through an RRC reconfiguration message that it can initiate the handover at this time.

[0154] Step HE004: While the Source sNB is executing Step HE003, it performs an early state transfer through the Xn-AP interface to convey the downlink count of the first user data unit at the PDCP layer to the Target sNB. In addition, different from before, the uplink data transmission of the user plane still continues through the Source sNB; for the downlink data of the user plane, the downlink data forwarding tunnel between the Source sNB and the Target sNB is fully established. Part of the downlink user data can be changed from the original GW-Source sNB-UE path to be directly transmitted through GW-Source sNB-Target sNB and cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established, while the other part of the downlink data still passes through the radio link of the Source sNB for transmission.

[0155] Steps HE005 - HE007: There is basically no change compared with the corresponding content before. The only difference is that the moment of accessing the Target sNB in DAPS handover occurs before the UE detaches from the Source sNB, rather than after detachment. This is also the direct manifestation of DAPS achieving seamless handover. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user level can be completed through the Target sNB link.

[0156] Step HE008 - HE009: After the UE successfully accesses the Target sNB, the Target sNB notifies the Source sNB that the handover has been successful. The Source sNB transmits the downlink count of the last user data unit through the sNB Status, and then executes the detachment process with the UE side. The relevant link for user data transmission via the Source sNB is completely interrupted here.

[0157] Step HE010 - HE011: This step also realizes the conversion task of the GW downlink data bearer by the Target sNB via GCC. After this stage, the downlink data transmission is directly completed through the Target sNB and is no longer indirectly completed by the forwarding tunnel.

[0158] Its HE phase is as Figure 8 shown.

[0159] As can be seen from the figure, the key features of the link seamless handover based on DAPS can be summarized as follows:

[0160] · There are additional requirements at the hardware level. The UE side needs to have the basic configuration of dual antennas and dual protocol stacks;

[0161] · There are also additional requirements for the channel resources required for the handover. Compared with the link hard handover, the link seamless handover requires more channel resources, and the complexity of the control signaling layer, as well as the system cost and load, are all increased;

[0162] · Since there is no interruption in the user - level data transmission, the theoretical HIT is 0 ms.

[0163] Therefore, for the high HIT problem existing in the handover from LEO satellites to GEO satellites in the hard handover mode, in order to avoid the obvious call interruption felt by the user level and thus directly reduce the user satisfaction, we can preferentially adopt the seamless handover mode based on DAPS.

[0164] Finally, combining the analysis conclusions in the first part, for the real - time voice and video services discussed above, when the LEO satellite switches to the GEO satellite, the present invention adopts the handover strategy based on NIOL. Thus, according to Figure 7 the seamless handover process based on IOL, combined with the content of the first part, the seamless handover process of the high - and low - orbit satellite link based on NFV + NIOL + DAPS (abbreviated as the soft handover based on NIOL) can be designed as Figure 9 shown, and the more detailed HE phase can be easily deduced from Figure 8 this.

[0165] The soft handover based on NIOL includes:

[0166] Step C1, handover preparation phase, including:

[0167] Step HP0001, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information mainly includes Reference Signal Receiving Power (RSRP), Reference Signal Receiving Quantity (RSRQ), and path loss.

[0168] Step HP0002, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to instruct the physical layer to perform relevant measurement operations according to the measurement control information.

[0169] Step HP0003, the UE continuously measures. When a certain trigger event (TE) is satisfied, it uploads a measurement report (MR) to the Source sNB. The Source sNB then directly decides to initiate a handover operation request based on the situation of the measurement report. The measurement report contains relevant information such as RSRP and RSRQ. The trigger event TE is divided into two categories: A and B. The former is used for intra-system handover, and the latter is used for inter-system handover. Specifically, there are events A1 - A5 and B1 - B2. The MR is divided into periodic MR and triggered MR according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met.

[0170] Step C2, handover execution phase, including:

[0171] Step HE0001 and Step HE0002, the Source sNB judges the DRB configuration and initiates a DAPS handover, and indirectly conveys the handover request to the Target sNB through GCC.

[0172] Step HE0003, after the Target sNB finishes preparing the resources, it returns an acknowledgement response to the GCC.

[0173] Step HE0004 and Step HE0005, the GCC notifies the Source sNB, and then the Source sNB notifies the UE that the current state allows the handover operation to be performed.

[0174] Steps HE0006 and HE0007: While the Source sNB is performing step HE0005, it indirectly transfers the status in advance to the Target sNB through GCC via the NG-AP interface, thereby conveying the downlink count of the first user data unit of the PDCP layer to the Target sNB. At this time, the uplink data transmission of the user plane still continues via the Source sNB. For the downlink data of the user plane, an indirect data forwarding tunnel of Source sNB-GW-Target sNB is successfully created. A part of the downlink user data can be transferred indirectly from the original GW-Source sNB-UE path to GW-Source sNB-GW-Target sNB, and is cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. Another part of the downlink data still travels through the radio link of the Source sNB.

[0175] Steps HE0008, HE0009, and HE0010: The UE accesses the Target sNB using a contention-free random access method based on the RACH preamble. After the access to the new node is completed, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored. At this time, the user plane data on the GW side still travels to the Source sNB, and the Source sNB directly transfers it to the Target sNB via the data forwarding tunnel of the Xn interface. The moment of accessing the Target sNB under DAPS handover occurs before the UE detaches from the Source sNB. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user layer can be completed via the Target sNB link.

[0176] Steps HE0011, HE0012, HE0013, and HE0014: After the UE side successfully accesses the Target sNB, the Target sNB indirectly notifies the Source sNB through GCC that the handover is successful. The Source sNB then indirectly transfers the downlink count of the last user data unit to the Target sNB via GCC, and then performs the detachment process with the UE side. The relevant links for user data transmission via the Source sNB are completely interrupted here.

[0177] Steps HE0015 and HE0016: The task of converting the GW downlink data bearer is achieved. After this stage, the downlink data transmission is directly completed via the Target sNB.

[0178] Step C3, the resource release phase, includes: Step RR0001 and Step RR0002, which implement the release of the UE-side context and destroy the indirect data forwarding tunnels mentioned in Step HE0006 and Step HE0007. There are basically no changes in Phase RR. However, due to the creation of the downlink data indirect forwarding tunnel previously, this phase also needs to perform disassembly work on this channel.

[0179] ● Design of the high and low orbit satellite link handover strategy based on one and two

[0180] In summary, combining the content of the first part and the second part, the effective strategies for the high and low orbit satellite hybrid network can be summarized as Figure 10 shown in the flowchart.

[0181] In addition, considering that there are still the following difficulties in building a satellite hybrid network completely using existing terrestrial Internet technologies:

[0182] (1) The overall resources of satellite nodes are relatively limited; (2) The satellite network is closed, and there are great costs and challenges in maintenance, upgrade and expansion; (3) Due to the relative mobility of LEO satellites, the topology of the hybrid network changes dynamically, and there are also many technical problems in maintaining the stability of the satellite network.

[0183] To address the problems of high maintenance difficulty, strong closure, strong dynamics, and limited resources inherent in the high and low orbit satellite hybrid network, consider combining SDN technology. SDN technology is an advanced network system that provides flexible traffic control for a specific network by programming and configuring forwarding rules. It allows network operators and service providers to directly adjust the logical control strategy through the SDN controller. Through the southbound interface, that is, the dedicated control link between the SDN controller and the data forwarding unit, the SDN controller often uses the OpenFlow protocol to forward and adjust signaling and directly act on each user data forwarding unit, thereby changing the forwarding rules of the user data plane and realizing the dynamic optimization of network traffic load. Under the SDN architecture, it is required that the data plane and the control plane of each LEO satellite be decoupled, and the control layer be aggregated into an additional GEO satellite. Although it increases the cost related to the additional GEO satellite, it also provides efficient and precise control for the satellite network and greatly supports the flexibility of future network technologies.

[0184] Meanwhile, the separation of the network control plane and the data forwarding plane by SDN facilitates the introduction and rapid testing of new protocols and new ideas. The network abstraction it provides enables flexible network control, configuration, and rapid innovation, bringing us closer to the ultimate goal of a dynamic network. Looking ahead, the introduction of prediction-based algorithms such as neural networks to automatically sense changes in the entire network may enable the realization of a truly intelligent network. Combining the foregoing, considering the introduction of the SDN regime in the context of a hybrid high- and low-earth orbit satellite network, the theoretical architecture of the Software Defined Satellite Network (SDSN) designed is as Figure 11 shown.

[0185] Under the SDSN architecture, the control layers of each satellite node are stripped and centralized on the ground controller deployed on the ECS. Any event in this network architecture that triggers changes in the upper-layer policy, such as the load balancing action of GEO satellites on LEO satellites and the satellite selection problem involved in the link switching between LEO satellites, is fully controlled and processed by the SDSN controller. The SDSN controller needs to dynamically adjust the routing policy according to the current status of the space-ground network and the instant information obtained, transmit relevant signaling to the satellite forwarding device through the OpenFlow channel, and update its flow table. It should be added that in addition to acting as a device for forwarding user data like LEO satellites, GEO satellites in this envisioned architecture also need to act as relay devices for the SDSN controller to transmit policy signaling to LEO satellites.

[0186] In addition, for Figure 11 the existing discussions on the LEO satellite selection problem shown in, since previous handover process studies have defaulted that the target satellite is a neighboring satellite, but with the continuous expansion of the scale of LEO satellites, there may be multiple LEO satellites within the visible range of the UE at a certain time. At this time, a handover judgment (HJ) stage needs to be considered between the HP stage and the HE stage. In this stage, the source satellite needs to execute a satellite selection algorithm to make a decision on the target satellite. The algorithm used for satellite decision-making is also related to the overall performance of the system. Therefore, this is also one of the research focuses in the handover process study and is often studied and analyzed independently of other stages. Based on Figure 11 , a simplified schematic diagram of the HJ stage under the SDSN architecture is as Figure 12 shown. Among them, the upper part is Figure 10The load balancing situation shown in [Figure] where the LEO satellite users are carrying heavy loads. At this time, the LEO satellite adaptively selects some users and hands them over to the GEO satellite for traffic balancing, resulting in a handover situation of the link from the LEO satellite to the GEO satellite. The lower part represents the optimal strategy problem. At this time, a certain user enters the normal handover process due to the mobility of the LEO satellite, but there are multiple accessible LEO satellites within the link range, thus generating a satellite selection problem. After abstracting the mathematical programming problem and formulating the planning indicators, various optimization algorithms can be adopted to optimize the corresponding indicators.

[0187] Considering the expansion of the satellite scale and the integration of the SDN architecture, between step A1 and step A2 of the soft handover based on IOL, there is also a handover decision stage, which includes:

[0188] Step HJ001, the Source sNB uploads a status report of the load balancing type to the GEO satellite that serves as both the Target sNB and the relay satellite through the Xn-AP interface.

[0189] Step HJ002, the Target sNB transfers the status report to the ground SDSN controller through the NG-AP interface.

[0190] Step HJ003, the ground SDSN controller responds to the Target sNB and transmits relevant signaling to the Target sNB through the OpenFlow channel to update its flow table.

[0191] Step HJ004, the Target sNB that takes into account the role of the relay satellite transfers relevant self-information to the Source sNB through the Xn-AP interface and simultaneously updates the flow tables of itself and other relevant sNBs.

[0192] When performing step d with the LEO satellite as the Source sNB and the Target sNB in step 4, considering the expansion of the satellite scale and the integration of the SDN architecture, the handover decision stage of the soft handover based on IOL includes:

[0193] Step HJ00001, the Source sNB uploads a status report of the optimal strategy type to the GEO satellite that only serves as the relay satellite through the Xn-AP interface;

[0194] Step HJ00002, the controller relay GEO satellite transfers the status report to the ground SDSN controller through the NG-AP interface.

[0195] Step HJ00003, the ground SDSN controller responds to the relay and forwards the latest flow table status to it;

[0196] Step HJ00004: The relay satellite GEO satellite transmits the Target sNB parameter information to the Source sNB through the Xn-AP interface, and updates the flow table for it and other candidate sNBs at the same time.

[0197] Challenges of SDSN architecture and prospects of its solutions:

[0198] (1) Reliability: In traditional networks, when one or more network devices fail, network traffic can be routed and forwarded through other nearby node devices to maintain reliable traffic transmission. However, in the SDSN architecture, if there is no backup controller, when the central controller fails, the entire network may collapse. Multi-controller deployment is one of the more mainstream solutions at present.

[0199] (2) Scalability: As the number of satellite nodes in the network continues to grow, more requests are queued in the controller, but the processing capacity of the controller is limited. Therefore, the controller may become a key bottleneck.

[0200] (3) Controller deployment problem: The controller deployment problem affects all aspects of the decoupled control plane, from traffic setting delay to network reliability, to fault tolerance, and to performance indicators. Therefore, finding the optimal controller deployment is one of the hot topics in SDN research, especially for the deployment of multiple controllers in large-scale networks;

[0201] (4) Satellite node delay problem: Compared with the ground network, the delay characteristics of satellite nodes in the SDSN architecture will bring more challenges to the robust transmission of the signaling layer. For challenges a) and b), a certain mitigation effect can be achieved by adding GEO satellites and ground controller deployment points, although this will increase certain additional costs. For challenges c) and d), MEO satellites can be preset to partially replace GEO satellites. Although the relative mobility of MEO satellites will increase the complexity of the model and its algorithm, the satellite movement path is predictable and the benefits of model optimization can be expected.

[0202] The beneficial effects of the present invention are: 1. The link switching method of the present invention can improve the success probability of GEO-LEO switching and the user satisfaction in the service area; 2. The link switching method of the present invention provides a reference for high and low orbit satellite networks, and has great support for the flexibility of future network technology.

[0203] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A link switching method for a hybrid network of high and low orbit satellites, characterized in that, it includes the following steps: Step 1: Specify the UE; Step 2: Determine whether there is a handover task. If so, proceed to the next step; otherwise, continue to execute Step 2; Step 3: Determine whether Source sNB ∈ LEO holds. If so, execute Step 4; otherwise, execute Step a; Step 4: Determine whether the optional LEO sNBs are in an overloaded state. If so, enter Step 5; otherwise, perform the processing of sNB selection and related algorithms, and then execute Step d with the LEO satellite as the Source sNB and the Target sNB; Step 5: GEO realizes load balancing; Step 6: Determine whether the service type is an online voice / video service. If so, proceed to the next step; otherwise, perform a hard handover from the LEO satellite to the GEO satellite based on a non-inter-orbit link, and end; Step 7: Perform a soft handover from the LEO satellite to the GEO satellite based on a non-inter-orbit link, and end; Step a: Source sNB ∈ GEO, and then execute Step b; Step b: Determine whether the selectable LEO sNBs are not in an overloaded state. If so, execute Step c; if not, continue to execute Step b; Step c: Return to the LEO sNB link, with the GEO satellite as the Source sNB and the LEO satellite as the Target sNB, and then execute Step d; Step d: Soft handover based on the inter-orbit link, and then end.

2. The link switching method according to claim 1, characterized in that, in the said Step d, when the Source sNB is a GEO satellite and the Target sNB is a LEO satellite, the soft handover based on IOL includes: Step A1, the handover preparation stage, includes: Step HP001, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss; Step HP002, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to execute relevant measurement operations at the physical layer according to the measurement control information; Step HP003, the UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information on relevant RSRP and RSRQ. The Source sNB then directly decides to initiate a handover operation request based on the situation of the measurement report; the triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover; the measurement report is divided into a periodic measurement report and a triggered measurement report according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met; Step A2, the handover execution stage, includes: Step HE001: The Source sNB determines the data radio bearer configuration and initiates a DAPS handover, and conveys the handover request to the Target sNB. Steps HE002 and HE003: After the Target sNB finishes preparing the resources, it directly returns an acknowledgement response to the Source sNB. The Source sNB notifies the UE side via an RRC reconfiguration message that it can initiate the handover at this time. Step HE004: While executing Step HE003, the Source sNB performs an early state transfer via the Xn-AP interface to convey the downlink count of the first user data unit at the PDCP layer to the Target sNB. However, the uplink data transmission of the user plane still continues via the Source sNB. For the downlink data of the user plane, the downlink data forwarding tunnel between the Source sNB and the Target sNB is fully established. Part of the downlink user data can be directly transmitted from the original GW-Source sNB-UE path to GW-Source sNB-Target sNB and is cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. The other part of the downlink data still travels through the radio link of the Source sNB. Steps HE005, HE006, and HE007: The UE uses a contention-free random access method based on a RACH preamble to access the Target sNB. After completing the access to the new node, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored. At this time, the user plane data on the GW side still transmits to the Source sNB, and the Source sNB directly transmits it to the Target sNB via the Xn interface data forwarding tunnel. The moment of accessing the Target sNB under DAPS handover occurs before the UE detaches from the Source sNB. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user level can be completed via the Target sNB link. Steps HE008 and HE009: After the UE side successfully accesses the Target sNB, the Target sNB notifies the Source sNB that the handover is successful. The Source sNB transmits the downlink count of the last user data unit via sNB Status and then executes the detachment process with the UE side. The relevant links for user data transmission via the Source sNB are completely interrupted here. Steps HE010 and HE011: The Target sNB completes the conversion task of the GW downlink data bearer via GCC. After this stage, the downlink data transmission is directly completed via the Target sNB and is no longer indirectly completed via the forwarding tunnel. Step A3, resource release phase, including: Step RR001, the Target sNB notifies the Source sNB via the Xn-AP interface to release all relevant resources and UE context allocated previously for the handover operation, and disassemble the data forwarding tunnel between the two; Step RR002, after the Source sNB completes the relevant work, it returns a response.

3. The link handover method according to claim 1, characterized in that in the said step 6, the hard handover based on NIOL includes: Step B1, handover preparation phase: perform handover measurements and deliver the relevant measurement results to the Source sNB, and the Source sNB decides whether to initiate a handover according to the measurement results; Step B2, handover execution phase: the signaling transmission is indirectly conveyed between the Source sNB and the Target sNB through the intermediate medium GCC; Step B3, resource release phase: complete the final work of the handover operation, and release the relevant channel resources on the Source sNB side and the GW side.

4. The link handover method according to claim 3, characterized in that in the said step B1, it includes: Step HP1, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer, and the measurement control information includes reference signal received power, reference signal received quality, and path loss; Step HP2, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to execute relevant measurement operations according to the measurement control information at the physical layer; Step HP3, the UE continuously measures, and when a certain trigger event is satisfied, it uploads a measurement report to the Source sNB, and the report contains information about relevant RSRP and RSRQ. The Source sNB then directly decides to initiate a handover operation request according to the situation of the report; the trigger events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover; the measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met.

5. The link handover method according to claim 3, characterized in that in the said step B2, it further includes: Step HE1, the Source sNB sends a handover request message to the GCC through the NG-AP interface, and attaches the base station ID of the Target sNB; Step HE2, after receiving the handover request and obtaining the base station ID of the Target sNB therefrom, the GCC notifies the Target sNB to reserve relevant resources through the NG-AP interface; Step HE3: After the Target sNB finishes preparing the resources, it returns a handover confirmation response. The response message contains the random access channel preamble allocated by the Target sNB for the UE, the GTP-U interface IP address and tunnel endpoint identifier allocated for the GW, and the transport layer IP address and TEID allocated for the forward data forwarding of the Source sNB; Step HE4: After receiving the response from the Target sNB, the GCC notifies the GW of the relevant message through the GTP-C interface; Step HE5: After the GW finishes allocating the relevant resources, it returns a response to the GCC; Step HE6: After the GCC confirms the establishment of the downlink data indirect forwarding tunnel, it notifies the Source sNB through the NG-AP interface that the reservation and allocation of the relevant resources have been completed and initiates a handover command; Step HE7: After receiving the message, the Source sNB encapsulates the ID of the Target sNB and the RACH preamble allocated by the Target sNB for the UE in an RRC reconfiguration message and sends it to the UE side at the RRC layer; Steps HE8 and HE9: While executing Step HE7, the Source sNB indirectly sends a status transfer message to the Target sNB through the GCC on the NG-AP interface, which contains the sequence number record of the user data packet transmission process; At this time, for the downlink data of the user plane, the downlink data forwarding tunnel of Source sNB-GW-Target sNB has been fully established, and the downlink user plane data is changed from the original GW-Source sNB-UE path to GW-Source sNB-GW-Target sNB for transmission, and is cached in the Target sNB until the downlink data channel is established between the Target sNB and the UE; For the uplink data of the user plane, it still transmits along the UE-Source sNB-GW path, but when the UE side receives the RRC reconfiguration message in Step HE7 and parses out the handover execution command, it immediately disconnects the RRC layer connection with the Source sNB and enters the RRC Idle state. At this time, the uplink transmission path of the user plane data UE-Source sNB-GW is forced to be interrupted; Steps HE10, HE11, and HE12: The UE initiates a contention-free random access request to avoid collisions and reduce latency to the Target sNB using the RACH preamble specifically allocated for it by the Target sNB obtained in step HE7. The Target sNB receives the access request and adjusts the reserved uplink resources to form a RACH response. Subsequently, the UE transmits an RRC reconfiguration complete message to complete the uplink synchronization with the Target sNB and enters the RRC Connected state from the RRC Idle state. After the access to the new node is completed, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE is also successfully established. At this time, the user data service is successfully restored. However, at this time, the user plane data on the GW side is still transmitted to the Source sNB, and then the Source sNB indirectly transmits it to the Target sNB through the data forwarding tunnel via the GW; Step HE13: The Target sNB notifies the GCC through the NG-AP that the handover command execution is complete; Steps HE14 and HE15: After learning that the handover task is completed, the GCC requests the GW to adjust the user data bearer through the GTP-C interface, changing the downlink user data path from GW-Source sNB to GW-Target sNB. After receiving the request message, the GW immediately adjusts the data bearer, transfers all the data from the GTP-U interface facing the Source sNB to the GTP-U interface facing the Target sNB for transmission, and returns a bearer adjustment response. At this time, the downlink user data path is successfully adjusted to GW-Target sNB-UE.

6. The link handover method according to claim 3, characterized in that, in the step B3, it further includes: Step RR1: The GCC notifies the Source sNB through the NG-AP interface to release all relevant resources and UE context previously allocated for the handover operation; Step RR2: After the Source sNB completes the relevant release work, it returns a release completed response through the NG-AP interface; Step RR3: The GCC notifies the GW through the GTP-C interface to tear down the data forwarding tunnel and release all relevant resources previously allocated for the data forwarding from the Source sNB to the Target sNB; Step RR4: After the GW completes the relevant release work, it returns a release completed response through the GTP-C interface.

7. The link handover method according to claim 1, characterized in that, in the step 7, the soft handover based on NIOL includes: Step C1, handover preparation stage, including: Step HP0001: The Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss; Step HP0002: After the UE receives the measurement control information at the RRC layer, it returns an RRC reconfiguration complete response to the SourcesNB and starts to perform relevant measurement operations at the physical layer according to the indication of the measurement control information; Step HP0003: The UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information on relevant RSRP and RSRQ. The Source sNB directly decides to initiate a handover operation request based on the situation of the measurement report. The triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover. The measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met; Step C2: The handover execution phase, including: Steps HE0001 and HE0002: The Source sNB judges the DRB configuration and initiates a DAPS handover, and indirectly conveys the handover request to the Target sNB through the GCC; Step HE0003: After the Target sNB prepares the resources, it returns an acknowledgement response to the GCC; Steps HE0004 and HE0005: The GCC notifies the Source sNB, and then the Source sNB notifies the UE that the current state allows the handover operation to be performed; Steps HE0006 and HE0007: While executing Step HE0005, the Source sNB performs an early state transfer to the Target sNB indirectly through the NG-AP interface via the GCC to convey the downlink count of the first user data unit at the PDCP layer. At this time, the uplink data transmission of the user plane still continues through the Source sNB. For the downlink data of the user plane, an indirect data forwarding tunnel of Source sNB-GW-Target sNB is successfully created. A part of the downlink data of the user plane can be changed from the original GW-Source sNB-UE path to be indirectly transmitted via GW-Source sNB-GW-Target sNB and cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. Another part of the downlink data still passes through the radio link of the Source sNB for transmission; In steps HE0008, HE0009, and HE0010, the UE accesses the Target sNB using a contention-free random access method based on the RACH preamble. After completing the access to the new node, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored, and the user plane data on the GW side is still transmitted to the Source sNB, which is directly transmitted to the Target sNB through the Xn interface data forwarding tunnel. The moment of accessing the Target sNB under DAPS handover occurs before the UE detaches from the Source sNB. The UE's successful random access to the Target sNB means that part of the uplink and downlink data transmission at the user level can be completed via the Target sNB link; In steps HE0011, HE0012, HE0013, and HE0014, after the UE side successfully accesses the Target sNB, the Target sNB indirectly notifies the Source sNB that the handover is successful through GCC. The Source sNB then indirectly transmits the downlink count of the last user data unit to the Target sNB through GCC, and then executes the detachment process with the UE side. The relevant links for user data transmission through the Source sNB are completely interrupted here; In steps HE0015 and HE0016, the task of converting the GW downlink data bearer is achieved. After this stage, the downlink data transmission is directly completed through the Target sNB; Step C3, the resource release stage, includes: Steps RR0001 and RR0002, to release the UE side context and destroy the indirect data forwarding tunnels mentioned in steps HE0006 and HE0007.

8. The link switching method according to claim 1, wherein, the link switching method also involves the design of hard handover based on IOL, and the hard handover based on IOL includes: Step D1, the handover preparation stage, includes: Step HP01, the Source sNB sends measurement control information to the UE through an RRC reconfiguration message at the RRC layer. The measurement control information includes reference signal received power, reference signal received quality, and path loss; Step HP02, after receiving the measurement control information at the RRC layer, the UE returns an RRC reconfiguration complete response to the Source sNB and starts to perform relevant measurement operations at the physical layer according to the indication of the measurement control information; Step HP03: The UE continuously measures. When a certain triggering event is satisfied, it uploads a measurement report to the Source sNB. The report contains information on relevant RSRP and RSRQ. The Source sNB directly decides to initiate a handover operation request based on the report. The triggering events are divided into two categories, A and B. The former is used for intra-system handover, and the latter is used for inter-system handover. The measurement reports are divided into periodic measurement reports and triggered measurement reports according to the upload method. The former reports the strongest cell at regular intervals, and the latter only reports when the required conditions are met. Step D2: During the handover execution phase, a direct downlink data forwarding tunnel is established between the Source sNB and the Target sNB for data transmission buffering. Step HE01: The Source sNB directly sends a handover request message to the Target sNB through the Xn-AP interface, notifying it to reserve relevant resources. Step HE02: After the Target sNB prepares the resources, it directly returns an acknowledgment response to the Source sNB. The response message contains the RACH preamble allocated to the UE, informing the Source sNB that the reservation and allocation of relevant resources have been completed and the UE can be notified to perform the relevant handover operation. Step HE03: After receiving the message, the Source sNB encapsulates information including the ID of the Target sNB and the RACH preamble allocated to the UE by the Target sNB in the RRC reconfiguration message and sends it to the UE side at the RRC layer. Step HE04: While executing Step HE03, the Source sNB directly sends the ST message to the Target sNB through the Xn-AP interface, which contains the sequence number SN record of the user data packet transmission process. In addition, for the downlink data of the user plane, the downlink data forwarding tunnel between the Source sNB and the Target sNB is fully established. The downlink user data of the user plane can be directly transmitted from the original GW-Source sNB-UE path to GW-Source sNB-Target sNB and is cached in the Target sNB until the downlink data channel between the Target sNB and the UE is established. Steps HE05, HE06, and HE07: The UE uses a contention-free random access method based on the RACH preamble to access the Target sNB. After completing the access to the new node, the uplink user data channel is restored to the UE-Target sNB-GW path, and the downlink user data channel from the Target sNB to the UE side is also successfully established. At this time, the user data service is successfully restored, but the user plane data on the GW side is still transmitted to the Source sNB and then directly transmitted to the Target sNB through the Xn interface data forwarding tunnel. In steps HE08 and HE09, the Target sNB completes the task of path bearer handover with the GCC through the NG-AP interface; Step D3, the resource release phase, includes: In steps RR01 and RR02, the Target sNB notifies the Source sNB via the Xn-AP interface to release all relevant resources and UE context allocated previously for the handover operation, and disassemble the data forwarding tunnel between them. After the Source sNB completes the relevant work, it returns a response.

9. The link handover method according to claim 2, wherein, considering the expansion of satellite scale and the integration of SDN architecture, between step A1 and step A2 of the soft handover based on IOL, there is also a handover decision phase, and the handover decision phase includes: Step HJ001, the Source sNB uploads a status report of the load balancing type to the GEO satellite that serves as both the Target sNB and the relay satellite via the Xn-AP interface; Step HJ002, the Target sNB transfers the status report to the ground SDSN controller via the NG-AP interface; Step HJ003, the ground SDSN controller responds to the Target sNB and transmits relevant signaling to the Target sNB through the OpenFlow channel to update its flow table; Step HJ004, the Target sNB that takes into account the role of the relay satellite transmits relevant self-information to the Source sNB via the Xn-AP interface, and at the same time updates the flow tables of itself and other relevant sNBs.

10. The link handover method according to claim 9, wherein, when performing step d with the LEO satellite as the Source sNB and the Target sNB in step 4, considering the expansion of satellite scale and the integration of SDN architecture, the handover decision phase of the soft handover based on IOL includes: Step HJ00001, the Source sNB uploads a status report of the optimal policy type to the GEO satellite that only serves as the relay satellite via the Xn-AP interface; Step HJ00002, the controller relay GEO satellite transfers the status report to the ground SDSN controller via the NG-AP interface; Step HJ00003, the ground SDSN controller responds to the relay and forwards the latest flow table status to it; Step HJ00004, the relay satellite GEO satellite transmits the Target sNB parameter information to the Source sNB via the Xn-AP interface, and at the same time updates the flow tables of itself and other candidate sNBs.

Images