CN117411535A

CN117411535A - Layered ultra-dense giant star network lightweight mobility management method and system

Info

Publication number: CN117411535A
Application number: CN202311339493.7A
Authority: CN
Inventors: 周海波; 秦小寒; 马婷; 王一蕾; 刘晓宇
Original assignee: Nanjing University
Current assignee: Nanjing University
Priority date: 2023-10-17
Filing date: 2023-10-17
Publication date: 2024-01-16

Abstract

The invention discloses a layered MEO/LEO ultra-dense giant star network lightweight mobility management method and system, which are used for realizing seamless switching and service continuity in an ultra-dense low-orbit giant constellation network. The invention firstly introduces a mobility management architecture supporting double-layer grouping cluster of the joint management of the middle-orbit satellite and the low-orbit satellite, and reduces the management complexity of the network while supporting flexible function configuration; the method comprises the steps of combining a satellite motion rule to establish an in-orbit switching model and an out-of-orbit switching model of an ultra-dense low-orbit giant-star network; the common track switching considers user aggregation, so that a fast and uniform switching decision can be realized; according to the positions of the satellites before and after switching, the out-of-orbit switching is further divided into intra-cluster switching, inter-cluster switching and inter-group switching; on the basis, light-weight switching flows under different scenes are designed; compared with the existing low-orbit satellite network mobility management method, the method has better performance in the aspects of switching delay and signaling overhead.

Description

Layered ultra-dense giant star network lightweight mobility management method and system

Technical Field

The invention relates to the field of mobility management of ultra-dense low-orbit giant star networks, in particular to a layered MEO/LEO ultra-dense giant star network lightweight mobility management method and system.

Background

With the explosive growth of global communication demands, the 6G system is expected to provide ubiquitous coverage and ultra-wide area seamless broadband access at any time and any place so as to support novel technologies and applications such as industrial Internet of things, remote area coverage, emergency communication, aviation and navigation monitoring, digital twinning and the like. The rapid development and continuous updating of ultra-dense low-rail giant star base networks bring new prospects for future 6G coverage expansion, can realize global signal seamless coverage, provide ubiquitous user terminal services, and are considered as important support technologies of future 6G wireless network architectures. Meanwhile, industry and commerce at home and abroad are actively striving to lay out huge low-orbit satellite constellations, and companies such as OneWeb, spaceX, amazon and the like announce or are implementing various constellation project planning, and hope to build low-orbit satellite Internet with huge scale and global coverage. According to the latest report, the Starlink project plan proposed by SpaceX transmits 1.2 ten thousand low-orbit satellites, and realizes high-speed Internet access for billions of users worldwide. As basic and critical problems in ultra-dense low-orbit giant-star networks, mobility management is management on the aspects of mobile terminal position information, security and service continuity, so as to ensure the optimal connection state between mobile users and satellites in a dynamic network environment and provide guarantee for various application service requirements. In order to ensure that the service is not interrupted during the user call, a handoff process is required during the satellite and user movement. Currently, international standardization organizations such as 3GPP, IETF, ITU actively conduct research and study on the direction of satellite network mobility management.

However, due to the ultra-dense deployment of ultra-large constellations and the high dynamic nature of low-orbit satellites, ultra-dense low-orbit giant-star networks face many challenges in supporting seamless handoff mobility management. Considering the massive switching requirements and the complicated mobile scenes, the computing and processing capabilities of the mobility management functional entity face huge pressure; in the face of diversification of handover options and frequent successive handovers, mobility management schemes need to make more appropriate decisions in as short a time as possible. Therefore, designing a flexible distributed mobility management architecture to adapt to the high dynamic and large scale characteristics of the ultra-dense low-orbit giant star network, and developing a lightweight mobility management flow to ensure service continuity and improve user service quality is a critical hotspot problem in the current satellite network research.

Through the search of the existing literature, zhu Hongtao et al published an article entitled "research on dynamic virtualized distributed mobility management method for low-orbit satellite networks" in 9 of 2020. The article provides a dynamic virtualization distributed mobility management scheme aiming at the characteristics of dynamic topology of a low-orbit satellite network, ground station establishment influenced by geopolitical factors and the like. The scheme utilizes satellite groups to construct virtual gateways, and combines with a distributed ground gateway to adopt a network-based mobility support method. The result shows that the scheme not only solves the problems of suboptimal routing, single point failure and the like of the traditional mobility management, enhances the expandability and the robustness of the network, but also reduces the requirements of the network on the positions and the number of the ground stations, and improves the mobility management performances such as signaling overhead, position inquiry time delay, transmission time delay and the like.

Through a search of the existing literature, xie Yanhui et al published an article entitled "UDN mobility management algorithm based on SDN and NFV fusion" in month 8 of 2020. Aiming at the problem of signaling redundancy caused by excessive signaling interaction of the traditional switching flow under the ultra-dense network, the article provides an ultra-dense network mobility management algorithm based on software defined network and network function virtualization fusion. The algorithm gives a network architecture model which combines software defined network and network function virtualization and is suitable for the ultra-dense network, and an optimized switching signaling flow is provided on the basis. The result shows that the architecture and the algorithm can effectively reduce the signaling cost and the total time delay of switching under different parameters and scenes, and enhance the user experience.

Despite the wide attention of academia and industry in mobility management in satellite networks, most of the related work is mainly focused on the design of handover strategies and algorithms. However, in practical applications, especially in a new ultra-dense low-rail giant-star network that is completely different from the traditional terrestrial network, architecture design and signaling flow optimization of mobility management are also indispensable. The mobility management architecture and flow design of the existing satellite network mainly refer to standard protocols and solutions of the ground network. Considering the limitation of satellite ground station deployment, multiple satellite access selection, low-orbit satellite high-speed motion, massive switching requests and the like, the methods are not suitable for ultra-dense low-orbit giant-star networks. Therefore, there is an urgent need to study a flexible mobility management architecture and design a lightweight handover procedure to ensure service continuity and user quality of service requirements of an ultra-dense low-orbit giant-star network.

Disclosure of Invention

The invention aims to: considering the high dynamic and large scale characteristics of ultra-dense low-orbit giant-star networks and the limitations of existing ground-based network management methods, it is important to provide seamless handover mobility management. The invention aims to design a flexible layered ultra-dense huge-star network lightweight mobility management method and system, thereby reducing network management complexity, ensuring service continuity and meeting various service requirements.

The technical scheme is as follows: in order to achieve the above purpose, the invention adopts the following technical scheme: a layered ultra-dense giant star network lightweight mobility management method constructs a mobility management architecture of a double-layer grouping cluster, divides switching into same-track switching and different-track switching, and designs a same-track switching flow based on user gathering switching; in the mobility management architecture of the double-layer grouping cluster, low-orbit LEO satellites are grouped, and each medium-orbit MEO satellite manages a group of LEO satellites; clustering is further carried out in each group, and each cluster head CH LEO manages cluster member CM LEO satellites in the cluster; the CM LEO satellite is used as an access point to provide connection for a user terminal UT in the coverage area of the CM LEO satellite, and is responsible for forwarding data messages and making the decision of the same orbit switching of the UT; the CH LEO satellite is used as a local controller to calculate a routing strategy for the CM LEO satellite in the cluster and is responsible for processing the movement logic in the cluster; the MEO satellite is used as a global controller and is responsible for calculating routing strategies among clusters or satellite groups and processing movement logic among the clusters or satellite groups;

In the same orbit switching flow based on user gathering switching, all users accessing the same satellite are taken as a user group, firstly, a user which detects the signal of the next satellite and meets the switching condition is taken as a first user, and the first user performs pre-switching for other users in the user group; the first user switching process comprises the following steps: the user terminal UT sends a report to the current access satellite p-AS, wherein the report comprises the identity information of the UT and the received satellite signal intensity; if the report contains adjacent satellite information of the same orbit, the p-AS sends a group switching request GHI message to the adjacent satellite n-AS; after obtaining GHI message, n-AS allocates resource space for upcoming UT, and replies group switching confirmation GHACK message to p-AS, and p-AS sends cached data of UT to n-AS; after receiving GHAck, p-AS sends a route discovery RD message to UT to inform UT of satellite to be accessed; after the UT is accessed to the n-AS, carrying out a routing request and updating user binding information on a CH LEO satellite; when other users within the group of users trigger an on-track handoff, the GHI and GHAck message process is not repeated.

Further, in the method, the initial registration procedure of the user terminal UT includes:

When UT enters the coverage area of access satellite AS, sending route request RS message to AS; the AS generates a Proxy Binding Update (PBU) message containing a UT identifier and a routing address and sends the message to a cluster head CH LEO satellite of a cluster where the PBU message is located, the CH LEO satellite maintains registration information of the UT, and generates a Proxy Binding Acknowledgement (PBA) message containing an address prefix and sends the message to the AS; the AS sends a request response RA message containing an address prefix to the UT.

Further, the user end-to-end communication flow in the method comprises the following steps:

when the UT performs end-to-end communication, a data packet is sent to an access satellite AS; if the AS cannot find the matched routing table item in the routing table, requesting an optimal path from the CH LEO satellite of the cluster; when the destination address is in other clusters or other satellite groups, the CH LEO satellite requests an optimal path from the MEO satellite; if the satellites related to the optimal path are in the same cluster, the CH LEO sends a flow configuration FlowMod message to update a routing table of the satellites in the cluster; if the satellite involved in the optimal path passes through different clusters or different satellite groups, the MEO satellite coordinates CH LEO satellite to update the routing table of the satellite in the cluster.

Further, when the inter-track switching is switched to intra-inter-track cluster switching in the method, the switching flow includes:

The user terminal UT sends a report to the current access satellite p-AS, wherein the report comprises the identity information of the UT and the received satellite signal intensity;

when the report does not contain adjacent satellite information of the same orbit or UT has higher QoS requirement, the p-AS requests the next access satellite n-AS to the CH LEO of the cluster where the p-AS is located;

after the CH LEO selects n-AS, updating binding information of UT, and sending flow configuration FlowMod message to satellite related to route between p-AS and n-AS;

after receiving the FlowMod, the p-AS sends a route discovery RD message to the UT to inform a switching decision;

after the UT accesses the n-AS, it sends a route request RS message to the n-AS, and after obtaining a response RA message, the data packet buffered by the n-AS can be forwarded to the UT, and the UT can re-communicate data.

Further, when the inter-track switching is changed into inter-track cluster switching in the method, the switching flow comprises:

when the information of all satellites in the cluster where the p-AS is located is not contained in the report or does not meet the QoS requirement of the UT, the p-AS sends a cancel proxy binding update message to the p-CH of the CH LEO satellite, and the p-CH sends a cancel proxy binding update message to the MEO of the group where the p-AS is located to request a switching decision;

After the MEO selects the next access satellite n-AS, a flow configuration FlowMod message is sent to a CH LEO satellite n-CH of a cluster where the p-CH and the n-AS are located so AS to update binding information of the UT; the p-CH and the n-CH respectively send flow configuration FlowMod messages to satellites involved in the clusters according to routes between the p-AS and the n-AS calculated by the MEO so AS to update a routing table;

after receiving the FlowMod, the p-AS sends a route discovery RD message to the UT to inform the switching decision;

the route request RS/route response RA is then used for the access/response procedure between UT and n-AS.

Further, when the different track is switched to the different track group switching in the method, the switching flow comprises:

when the information of all satellites in the group where the p-AS is located is not contained in the report or QoS requirements are difficult to meet, the p-AS sends a proxy binding cancellation update message to the p-CH of the CH LEO satellite, and the p-CH sends a proxy binding cancellation update message to the p-MEO of the MEO satellite in the group where the p-AS is located; after the p-MEO finds that the satellites in the group cannot meet the requirement, the p-MEO communicates with other MEOs to globally observe network information and make a switching decision; meanwhile, the p-MEO sends a switching request HReq message to the new MEO satellite n-MEO;

After receiving the HReq message, the n-MEO replies a handover confirmation HAck message to the p-MEO; meanwhile, the n-MEO sends a flow configuration FlowMod message to the n-CH to update the user binding information;

after receiving the HAck message, the p-MEO sends a flow configuration FlowMod message to the p-CH to delete the binding information of the related user;

after receiving the FlowMod message, the p-CH and the n-CH send the FlowMod message to the satellite related in the cluster according to the route between the p-AS and the n-AS so AS to update the routing table;

after receiving the FlowMod, the p-AS sends a route discovery RD message to the UT to inform the switching satellite; then, the UT and the n-AS perform access/response process through the routing request RS/routing response RA signaling.

Further, in the same track switching flow based on user aggregation switching, when the user group size exceeds the maximum access amount which can be served by n-AS, the aggregated users are truncated, and the truncated users participate in the next aggregation switching flow.

Based on the same inventive concept, the invention provides a layered ultra-dense giant constellation network lightweight mobility management system, which comprises an architecture configuration module and a switching processing module; the architecture configuration module is used for grouping low-orbit LEO satellites based on a mobility management architecture of a double-layer grouping cluster, and each medium-orbit MEO satellite manages a group of LEO satellites; clustering is further carried out in each group, and each cluster head CH LEO manages cluster member CM LEO satellites in the cluster; the CM LEO satellite is used as an access point to provide connection for a user terminal UT in the coverage area of the CM LEO satellite, and is responsible for forwarding data messages and making the decision of the same orbit switching of the UT; the CH LEO satellite is used as a local controller to calculate a routing strategy for the CM LEO satellite in the cluster and is responsible for processing the movement logic in the cluster; the MEO satellite is used as a global controller and is responsible for calculating routing strategies among clusters or satellite groups and processing movement logic among the clusters or satellite groups;

The switching processing module divides switching into same-track switching and different-track switching, and realizes a same-track switching flow based on user gathering switching; in the same orbit switching flow based on user gathering switching, all users accessing the same satellite are taken as a user group, firstly, a user which detects the signal of the next satellite and meets the switching condition is taken as a first user, and the first user performs pre-switching for other users in the user group; the first user switching process comprises the following steps: the user terminal UT sends a report to the current access satellite p-AS, wherein the report comprises the identity information of the UT and the received satellite signal intensity; if the report contains adjacent satellite information of the same orbit, the p-AS sends a group switching request GHI message to the adjacent satellite n-AS; after obtaining GHI message, n-AS allocates resource space for upcoming UT, and replies group switching confirmation GHACK message to p-AS, and p-AS sends cached data of UT to n-AS; after receiving GHAck, p-AS sends a route discovery RD message to UT to inform UT of satellite to be accessed; after the UT is accessed to the n-AS, carrying out a routing request and updating user binding information on a CH LEO satellite; when other users within the group of users trigger an on-track handoff, the GHI and GHAck message process is not repeated.

The beneficial effects are that: the invention provides a layered MEO/LEO ultra-dense giant-star network lightweight mobility management architecture, which realizes lightweight switching flow and flexible network function configuration, namely, different functional entities are responsible for switching decisions in different switching flows. In order to reduce the management complexity of the ultra-dense network, the invention designs a mobility management model based on clustering, which supports the joint management of medium-orbit satellites and low-orbit satellites. Under the framework, in combination with the satellite motion law, the invention provides a switching model of an ultra-dense low-orbit giant-star network, which comprises same-orbit switching and different-orbit switching, and light switching flows are respectively designed for different mobile scenes on the basis. The same orbit switching realizes fast and unified decision through user aggregation, and different orbit switching is further divided into intra-cluster switching, inter-cluster switching and inter-group switching according to the difference of the areas of the front satellite and the rear satellite. The mobility management mechanism has better switching performance, and can effectively reduce switching time delay and signaling overhead.

Drawings

Fig. 1 is a hierarchical MEO/LEO ultra-dense megasocket network lightweight mobility management scenario diagram in an embodiment of the invention.

Fig. 2 is a schematic diagram of an on-track switching process according to an embodiment of the present invention.

Fig. 3 is a schematic diagram of an intra-cluster-out-of-track switching flow provided in an embodiment of the present invention.

Fig. 4 is a schematic diagram of an inter-track cluster handover procedure according to an embodiment of the present invention.

Fig. 5 is a schematic diagram of an inter-track group handover procedure according to an embodiment of the present invention.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, the following detailed description of the embodiments of the present invention is given with reference to the accompanying drawings: the embodiment is implemented on the premise of the technical scheme of the invention, and detailed implementation modes and specific operation processes are given. It should be understood that the specific examples described herein are for illustrative purposes only and that the scope of the present invention is not limited to the following examples.

In the ultra-dense low-orbit giant-star network scene, the embodiment combines the satellite motion law and the user aggregation to provide a layered MEO/LEO ultra-dense giant-star network lightweight mobility management method. Considering first the unique features of Ultra dense low-orbit giant star networks (Ultra-dense LEO satellite networks, UD-LSN), mobility management faces challenges: double mobility of Low Earth Orbit satellites (LEO) and ground User Terminals (UT), high overlapping of service coverage areas under ultra-dense satellite deployment, switching requirements of massive users and ground-based mobility management; the unique characteristics of the ultra-dense low-rail giant star network also bring opportunities to mobility management: regularity of network movement, advantages of non-ground management and user aggregation switching; the invention introduces the regularity of network movement and provides a motion model and a switching model in UD-LSNs; non-terrestrial management includes management architecture for packet clustering of large-scale networks, global management of medium orbit satellites (Medium Earth Orbit, MEOs), local management of LEOs, etc.; user aggregation includes range size partitioning, first user selection, handoff trigger conditions, and the like.

Aiming at the opportunities and challenges of mobility management in an ultra-dense low-orbit giant-star network, MEO satellites and LEO satellites are introduced, and a mobility management architecture of double-layer grouping clusters is provided in UD-LSNs, wherein the mobility management architecture comprises an MEO network segment, an LEO network segment and a ground UT segment; aiming at a mobile scene in UD-LSNs, an initial registration process and handover management are provided; the method is characterized in that the method is used for introducing user aggregation switching to the mass switching requirement, and the same-track switching flow is designed, wherein the flow comprises user grouping, pre-switching and aggregation switching processes; and designing an out-of-orbit switching process according to different switching scenes, and further dividing the out-of-orbit switching into intra-cluster switching, inter-cluster switching and inter-group switching according to different areas where the front and rear access satellites of the user terminal are located. The on-track switching flow of the UD-LSNs is specifically designed, and comprises switching triggering, route discovery, cache data transmission, switching decision, binding update and the like. Aggregation handoffs are considered in on-track handoffs, including aggregation packets, aggregation handoff commands, and the like. In the different track switching of UD-LSNs, an intra-cluster switching flow is designed, which comprises switching triggering, switching preparation, buffer data transmission, switching decision, switching execution and the like; the intra-group inter-cluster switching flow comprises switching triggering, switching preparation, buffer data transmission, switching decision, switching execution and the like; and the inter-group switching flow comprises switching triggering, switching preparation, buffer data transmission, switching decision, switching execution and the like.

In particular, in UD-LSNs, mobility management faces some new challenges, different from traditional terrestrial networks, in view of the high dynamics and large scale nature of LEO satellites, including the drawbacks of dual mobility, massive handoff requests, highly overlapping coverage, and existing terrestrial-based mobility management:

1) Dual mobility: traditional terrestrial networks primarily initiate mobility handoffs by user terminal movement, whereas in LEO satellite networks the triggering of mobility handoffs is bi-directional. From the terminal side, the position movement of the UT is included; from the network side, including the high-speed earth-orbiting motion of LEO satellites, the network is still subject to frequent handovers even when the ground user is stationary. Further, the complexity of terminal side traffic and mobile scenarios in future networks may also exacerbate the difficulty of mobility management in UD-LSNs.

2) Mass switching request: UD-LSN aims at satisfying the ever-increasing massive and ubiquitous service demands of users, and compared with the traditional ground network, the switching demands of UD-LSN are exponentially increased, which puts higher demands on the computing processing capacity of the mobility management entity, and needs to make as many decisions as possible in as short a time as possible.

3) Coverage of high overlap: with the massive and ultra-dense deployment of LEO satellites, UTs in the same area may be simultaneously within service range of multiple satellites in view, facing the problem of selecting multiple service access points. When the switching condition is selected improperly, frequent switching and ping-pong effect are brought, so that switching delay, signal overhead and decision burden are increased.

4) Ground mobility management defects: in satellite networks, the functional entities of existing mobility management methods are typically placed on satellite ground stations (Satellite Earth Station, SES). However, SES is often not deployed worldwide for geographic and political reasons. In this case, a large number of mobility management signals need to be sent to fixed, limited ground stations, which would lead to severe network congestion, unacceptable management delays and a large amount of signalling overhead.

In view of the above challenges, the characteristics of UD-LTIN are considered, and unique opportunities are provided for mobility management design, including advantages of non-terrestrial management, satellite motion rules and user aggregation handover.

1) Non-ground management: compared with a ground management node, the MEO satellite has the characteristics of wide coverage, large capacity and the like, and is very suitable for being used as the management node of the LEO satellite network. Meanwhile, as the processing capacity of the LEO satellite increases, part of the management functions may also be placed on the LEO satellite. In addition, in view of the huge scale of UD-LSNs, network management is very complex, and a method of grouping clusters can be adopted to reduce the complexity of management. Under the architecture, the mobility management in UD-LSNs is discussed in case, so that the management efficiency can be greatly improved.

2) Satellite motion law: the movements of the UT can be divided into active movements and passive movements. On the ground, it comes entirely from active motion, i.e. self-driving. Whereas in UD-LTN, passive motion, i.e. satellite driving, is mainly coming from. It is counted that UT movement is negligible compared to the high speed motion of LEO satellites. For example, the LEO satellites have a speed of about 27000 km/h, about 300 times the speed of the vehicle, and 5400 times the speed of the pedestrian. Thus, the handover of the UD-LTN is mainly triggered by satellite movement. Satellite motion is characterized as continuous, global, and regular, as compared to the intermittence, locality, and randomness of user motion. Thus, the regularity of satellite motion may be utilized to simplify the handover decision of UD-LTN.

3) User aggregation: based on the law of motion in UD-LSNs, the user may be considered relatively stationary compared to LEO satellites. That is, the next satellite to which most users under the same satellite switch will be the same, all the switching processes being similar, the only difference being the specific switch trigger time. Therefore, users under the same satellite can be gathered together, and the switching process is simplified by sharing the switching flow, so that the cost is reduced and the signaling cost is lowered.

According to the satellite motion law in UD-LSNs, the embodiment of the invention establishes a switching model as follows: for a UT, its serving satellite may need to be handed over during a session, mainly consisting of two types, the process of switching from the current serving satellite to an adjacent satellite in the same orbit is called in-orbit handoff, while the other case is out-of-orbit handoff. With the concept of relative motion, the satellite network is considered stationary, and the UT motion speed is equal to the sum of its own speed and the reverse satellite speed. Because the LEO satellite and UT movement speeds differ significantly, the UT speed is in most cases equal to the reverse satellite speed, so the user-occurring handoff in UD-LSNs is always an in-orbit handoff. Assuming that the probability of occurrence of the co-track switching from UT is p, the probability of the off-track switching is 1-p. The regularity of the passive movement and the intensity of the active movement will influence the magnitude of p. According to the above analysis, the probability of an on-track switch is much greater than that of an off-track switch, with p > 1-p.

Based on the analysis, MEO satellites and LEO satellites are introduced, and a mobility management architecture of MEO/LEO double-layer packet clusters is proposed in UD-LSNs, wherein the mobility management architecture comprises a network model and initial registration.

1) Network model: as shown in fig. 1, a dual-layer distributed mobility management architecture (Hierarchical Distributed Mobility Management, HDMMA) is proposed, taking advantage of the unique features of UD-LSN. The HDMMA adopts a double-layer MEO/LEO joint network management mechanism and is based on a network management architecture of grouping clusters. Specifically, LEO satellites are grouped, with each MEO managing a set of LEO satellites; further clustering is carried out in each group, and Cluster Members (CM) LEOs in the Cluster are managed by each Cluster Head (CH) LEO; within a cluster, only CH LEO satellites communicate with group management MEO satellites. In this way, inter-Satellite Link (ISL) between MEO and LEO is greatly reduced, while efficient mobility management can be achieved. HDMMA mainly includes a terrestrial segment, an LEO satellite network segment, and a MEO satellite network segment.

1-1) ground section: the terrestrial segment contains the B5G/6G core network, satellite management centers (satellite ground stations) and services with different quality of service requirements (Quality of Service, qoS). There are a large number of UTs in the same area, and a plurality of satellites in view are faced for a certain UT. Considering the relative movement rule of the user and the satellite, the user under the same satellite can switch in an aggregation mode so as to share the switching cost.

1-2) LEO satellite network segment: within a cluster, CM LEO satellites act as access points providing connectivity for UTs within its coverage area; meanwhile, as a switch, one or more routing tables are maintained to process the incoming data packets and take charge of forwarding the data packets. In addition, in HDMMA, CM LEO is also responsible for some simple mobility logic, such as can handle UT on-track handover decisions. The CH LEO satellite is used as a local controller and is responsible for calculating a routing strategy for CM LEOs in the cluster; and is responsible for handling the mobility logic within the cluster and tracking registration information of UTs within the cluster using binding cache entries (Binding Cache Entry, BCE).

1-3) MEO satellite network segment: the MEO satellite is used as a global controller and is responsible for calculating the routing strategy among clusters or groups, and can process some more complex mobile logics among clusters or groups and the like, and decision and control release are realized by exchanging signaling information with CH LEO. The MEOs have a global view of the network through the exchange of information between the MEOs.

2) Initial registration: when the UT enters the coverage area of a certain Satellite (AS), the UT determines that it has moved to the service area of a new Satellite by receiving the router advertisement information of the Satellite. At this point, the UT will send a router solicitation (Router Solicitation, RS) information to the new satellite. When the new satellite receives the RS containing the UT identifier and finds that it is a new UT, a PBU (Proxy Binding Update) message containing the UT identifier and routing address is generated and sent to the CH LEO satellite. When the CH LEO satellite receives the PBU information and discovers that it is a new UT registration, a BCE is created to maintain registration information for the UT. The location management anchor (Local Mobility Anchor, LMA) then assigns an address prefix to the UT and populates it with PBA information, which the CH LEO satellite then transmits to the access satellite for responding to the PBU information. After receiving the PBA information, the access satellite sends RA information containing its address prefix to the UT for responding to the RS information. Through this process, the UT can obtain internet services from the AS. When a UT wants to communicate end-to-end with other UTs, it starts sending the first packet to its AS. After the AS obtains the destination address of the data packet, if the AS finds that the matched routing table item cannot be found in the routing table, the AS sends a request to the CH LEO satellite, and the CH LEO satellite calculates the optimal path of the data packet for the request. When the destination address is located in another cluster or other group, the CH LEO satellite will send a request to the MEO satellite, since each MEO has a network view of the whole group as a group manager, and even the whole network view can be acquired through the east-west interface, and thus a path for data communication can be calculated for it. If the satellites related to the optimal path are in the same cluster, the CH LEO sends flow configuration (FLOWMOD) information to update a routing table of the satellites in the cluster; if these satellites traverse different clusters or different groups, the corresponding CH LEOs are coordinated by the MEO or associated MEO satellites. After receiving the FLOWMOD information, the intra-cluster satellites update their own routing tables, so that UTs start end-to-end data communication.

When a user leaves his current access satellite (p-AS) coverage, a handoff procedure will be triggered to ensure traffic continuity. Based on the switching model, the unique characteristics of the ultra-dense low-orbit giant star network are fully utilized, and the same-orbit switching and different-orbit switching processes are respectively designed to support seamless switching in various mobile scenes. In which, user aggregation switching is introduced for massive switching requirements, as shown in fig. 2, a same-track switching flow is designed, including switching triggering, user grouping and aggregation switching processes.

1) And (3) switching the flow: according to the switching model in UD-LSNs, in most cases, the user always performs in-orbit switching, and the current access satellite (p-AS) switches to an adjacent satellite (n-AS) in the same orbit, at this time, the switching decision can be borne by the access satellite without uploading to a local or global controller (CH LEO or MEO), and at the same time, the switching process is simplified, so AS to reduce the control overhead and the time delay. When the UT detects a handover indication (e.g., the received signal strength from the p-AS is below a certain threshold), a handover procedure is triggered. The whole switching process is divided into two parts, wherein the first part is a Route Discovery (Route Discovery) process, and the first part comprises switching decision, informing a new satellite (p-AS) to be accessed by the UT and handover of cache data; the second part is a Binding Update procedure, which updates the Binding information in the controller and the UT accesses the p-AS. Specifically, the method comprises the following steps:

1-1) firstly, a UT sends a report to a p-AS, and L2 report containing the identity information of the UT, the received satellite signal strength and other information can be sent by referring to the switching flow design of classical MIPv 6;

1-2) if the L2 report contains adjacent satellite information of the same orbit, the p-AS sends a Handover request (HI) message to the adjacent satellite n-AS;

1-3) after obtaining the HI message, the n-AS allocates resource space for the upcoming UT and replies to the p-AS with handover acknowledgement (Handover Acknowledge, HAck) information; meanwhile, the p-AS can send the cached data of the UT to the n-AS, so that the data packet cached in the p-AS is prevented from being lost;

1-4) after receiving the HAck, the p-AS sends a Route Discovery (RD) message to the UT to inform the UT of the satellite it is about to access;

1-5) the UT, after having accessed the n-AS, will send a routing request (Router Solicitation, RS) information to the n-AS;

1-6) then the n-AS encapsulates the PBU message with the received RS message and sends the PBU message to the CH LEO of the cluster; at this time, if the p-AS and the n-AS are located in different clusters, after detecting the user separation information, the p-AS will also send PBU information to the CH LEO (controller) of the cluster in which the p-AS is located, so AS to update the user binding information on the controller;

1-7) after the controller receives the PBU information, updating binding information of the UT in the BCE, and replying n-AS by using the PBA information;

1-8) after receiving the PBA message, the n-AS sends RA information to the UT to complete the switching process; in this way, the data packets buffered by the n-AS can be forwarded to the UT, restarting the data communication.

2) Grouping users: in UD-LSNs, the user always switches to adjacent satellites in the same orbit in most cases, according to the motion model and the switching model; at the same time, most users under the same satellite will transfer to the same satellite either early or late. To simplify signaling overhead and reduce handover latency, group aggregated handover is employed to split handover costs. In particular, all user nodes that are under the same satellite are grouped into a group, wherein the user that is handed over first will pre-hand over to other users within the group. In the L2 report of the user, the user who first detects the signal of the next satellite and satisfies the handover condition is the first user.

3) Aggregation handover: in group aggregated handoff, for the first user, group handoff initialization and group handoff acknowledgement (GHI/GHAck) are used instead of HI/HAck. Thus, there is no need to repeat the HI/Hack procedure when other users within the group trigger a handover. Because it is assumed that all users will move to the same satellite without distinguishing between anomalies. Since the p-AS knows all user IDs currently accessed, all users to be handed over can be inferred therefrom and included in the GHI/GHAck information. After receiving GHI/GHAck, n-AS allocates requested resources to accessed UTs to the greatest extent according to self-load condition. When the group size exceeds the maximum access amount which can be served by the n-AS, the aggregated users are truncated according to the probability of about to be switched. The handover probability refers to the probability of occurrence of a UT handover from the current satellite to the n-AS. The longer the UT is connected to the p-AS, the greater the probability of handoff, and users not in the current group can participate in the next aggregated handoff. In this case, the group aggregation switch (GHI/GHAck) is only needed once to complete the switch initialization and confirmation of all users in the group, thereby greatly reducing the signaling overhead.

In reality, there are still some cases of off-track switching even though their occurrence probability is small. In order to provide seamless service to users in various mobile scenarios, it is also necessary to design a handover procedure for off-track handover. Common reasons for out-of-orbit handoff include high mobility of UTs (e.g., aeroplane), high priority of UTs, long movement of UTs or being at the edge of satellite coverage, and UTs being unsatisfactory for the QoS provided by the current AS or requiring a better handoff strategy. In general, off-track handover decisions are relatively complex, especially in certain special cases where targeted discussions are required. Thus, CM LEO is typically unable to make handover decisions and needs to be handled by the controller. Different off-track switching flows are designed according to different switching scenes, and the off-track switching is further divided into intra-cluster switching, inter-cluster switching and inter-group switching according to different areas where the user terminal is accessed to the satellite before and after.

1) Intra-cluster switching: AS shown in fig. 3, intra-cluster switching occurs when the p-AS and the n-AS are in the same cluster, AS follows:

1-1) first, the UT sends an L2 report to the p-AS, containing information such AS ut_id and received satellite signal strength.

1-2) when the L2 report does not contain neighboring satellite information of the same orbit or UTs have higher QoS requirements, the p-AS sends Dereg PBU information to the CH LEO of the cluster in which it is located to request a handover decision.

1-3) CH LEO grasps information of all LEO satellites in the cluster, and can select a more proper next AS for UT in the LEO in the cluster. It is noted that the particular handover strategy and algorithm is not an important aspect of the present invention. After making the decision, CH LEO updates the binding information of the UT in BCE. Meanwhile, the controller calculates the route between the p-AS and the n-AS, and sends a FlowMod message to the satellite related to the route, so that the data packet cached on the p-AS can be forwarded to the n-AS.

1-4) the p-AS, upon receipt of the FlowMod, sends a RD message to the UT informing the MN of the handoff decision.

1-5) upon access to the n-AS, the UT will send an RS message to the n-AS, which will immediately respond to the RA message; the n-AS buffered data packets may then be forwarded to the UT and the UT may resume data communication.

2) Inter-cluster handover: AS shown in fig. 4, when the p-AS and the n-AS are in different clusters but within the same group, intra-group inter-cluster handoff occurs AS follows:

2-1) first, the UT sends an L2 report to the p-AS.

2-2) when the information of all satellites in the cluster where the p-AS is located is not contained in the report or does not meet the QoS requirement of the UT, the p-AS and its CH LEO (p-CH) will not be able to make a handover decision, at which point the p-AS sends Dereg PBU information to the p-CH, and then the p-CH sends Dereg pbu_c information to the MEO of its group to request a handover decision.

2-3) the group controller MEO has knowledge of all satellites in the group and can switch to the more appropriate next AS for the UT in the LEO in the group. It is noted that the particular handover strategy and algorithm is not of interest. After making the decision, the MEO sends a FlowMod message to the CH LEO (n-CH) of the cluster where the p-CH and n-AS are located, to update the binding information about the UT in its BCE. Meanwhile, the p-CH and the n-CH respectively send FlowMod messages to the satellites involved in the clusters according to the routes between the p-AS and the n-AS calculated by the MEO so AS to update the routing table. In this way, packets buffered on the p-AS can be forwarded to the n-AS.

2-4) p-AS, upon receipt of FlowMod, sends a RD message to the UT informing it of the handover decision.

2-5) the RS/RA is used for the access/response procedure between UT and n-AS. Thus, the UT receives the buffered packets and restarts the communication.

3) Inter-group handover: AS shown in fig. 5, when the p-AS and the n-AS are in different groups, an inter-group handover will occur, AS follows:

3-1) first, the UT sends an L2 report to the p-AS.

3-2) when the information of all satellites in the group where the p-AS is located is not contained in the L2 report or it is difficult to meet QoS requirements, the p-AS transmits Dereg PBU information to its CH LEO (p-CH), and the p-CH transmits Dereg pbu_c information to the controller (p-MEO) of the group where it is located. After the p-MEO finds that the satellites in its group cannot meet the requirements, it communicates with other MEOs through east/west interfaces to globally observe network information and make handover decisions. Meanwhile, the p-MEO sends a handover request (HReq) message to the new controller n-MEO.

3-3) the n-MEO replies a handover acknowledgement (HAck) message to the p-MEO after receiving the HReq message. Meanwhile, the n-MEO sends a FlowMod message to the n-CH to update the binding information in its BCE.

3-4) after receiving the HAck information, the p-MEO sends a FlowMod message to the p-CH to delete the binding information about the UT in its BCE table.

3-5) after receiving the FlowMod message, the p-CH and the n-CH send the FlowMod message to the satellite involved in the cluster according to the route between the p-AS and the n-AS calculated by the MEO to update the routing table. In this way, packets buffered on the p-AS can be forwarded to the n-AS.

3-6) p-AS, upon receipt of FlowMod, sends a RD message to the UT to inform the handoff satellite.

3-7), an access/response procedure is performed between UT and n-AS through RS/RA signaling. The n-AS buffered data packets may then be forwarded to the UT and the UT may restart the communication through the optimal route.

Based on the same inventive concept, the embodiment of the invention discloses a layered ultra-dense giant constellation network lightweight mobility management system, which comprises a framework configuration module and a switching processing module; the architecture configuration module is used for a mobility management architecture based on double-layer clustering; the switching processing module divides switching into same-track switching and different-track switching, and realizes the same-track switching flow and various different-track switching flow based on user gathering switching. The implementation of each module refers to the foregoing method, and will not be repeated.

The foregoing is only a preferred embodiment of the invention, it being noted that: it will be apparent to those skilled in the art that various modifications and adaptations can be made without departing from the principles of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the invention.

Claims

1. A layered ultra-dense giant star network lightweight mobility management method is characterized in that a mobility management framework of double-layer packet clustering is constructed, switching is divided into same-track switching and different-track switching, and a same-track switching flow based on user gathering switching is designed; in the mobility management architecture of the double-layer grouping cluster, low-orbit LEO satellites are grouped, and each medium-orbit MEO satellite manages a group of LEO satellites; clustering is further carried out in each group, and each cluster head CH LEO manages cluster member CM LEO satellites in the cluster; the CM LEO satellite is used as an access point to provide connection for a user terminal UT in the coverage area of the CM LEO satellite, and is responsible for forwarding data messages and making the decision of the same orbit switching of the UT; the CH LEO satellite is used as a local controller to calculate a routing strategy for the CM LEO satellite in the cluster and is responsible for processing the movement logic in the cluster; the MEO satellite is used as a global controller and is responsible for calculating routing strategies among clusters or satellite groups and processing movement logic among the clusters or satellite groups;

2. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein the initial registration procedure of the user terminal UT comprises:

3. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein the user end-to-end communication flow in the method comprises:

4. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein when an off-track switch is an intra-off-track cluster switch, a switching process comprises:

5. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein when an off-track switch is an inter-off-track cluster switch, a switching process comprises:

6. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein when the inter-track switching is performed in the method, the switching flow comprises:

7. The method for managing lightweight mobility of a hierarchical ultra-dense giant-star network according to claim 1, wherein in an on-track switching process based on user aggregation switching, when a user group size exceeds a maximum access amount that can be served by n-AS, aggregated users are truncated, and the truncated users participate in a next aggregation switching process.

8. The hierarchical ultra-dense giant constellation network lightweight mobility management system is characterized by comprising an architecture configuration module and a switching processing module; the architecture configuration module is used for grouping low-orbit LEO satellites based on a mobility management architecture of a double-layer grouping cluster, and each medium-orbit MEO satellite manages a group of LEO satellites; clustering is further carried out in each group, and each cluster head CH LEO manages cluster member CM LEO satellites in the cluster; the CM LEO satellite is used as an access point to provide connection for a user terminal UT in the coverage area of the CM LEO satellite, and is responsible for forwarding data messages and making the decision of the same orbit switching of the UT; the CH LEO satellite is used as a local controller to calculate a routing strategy for the CM LEO satellite in the cluster and is responsible for processing the movement logic in the cluster; the MEO satellite is used as a global controller and is responsible for calculating routing strategies among clusters or satellite groups and processing movement logic among the clusters or satellite groups;

9. The hierarchical ultra-dense giant constellation network lightweight mobility management system of claim 8, wherein said off-track handovers include intra-cluster handovers, inter-cluster handovers, and inter-group handovers.

10. The system of claim 8, wherein in the on-track handoff procedure based on user aggregation handoff, when the user group size exceeds the maximum access amount that can be served by the n-AS, the aggregated users are truncated, and the truncated users participate in the next aggregation handoff procedure.