Method, device and electronic equipment for network registration
Patent Information
- Application Number
- CN202611047692.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-14
- Publication Date
- 2026-09-15
Smart Images

Figure CN122765633A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of satellite communication technology, and more specifically, to a method, apparatus, and electronic device for network registration. Background Technology
[0002] In satellite communication scenarios, terminal movement triggers beam switching prediction, while circuit-switched domain registration can only be initiated on a new beam after the current beam task is completed. In related technologies, beam switching prediction and circuit-switched domain registration are independent; the terminal only initiates circuit-switched domain registration for the new beam after beam switching is complete. If the satellite channel quality of the new beam is low (e.g., due to obstruction in mountainous areas), the registration process is prone to interruption and requires repeated retries, severely impacting the transmission of critical information in emergency communication scenarios.
[0003] There is currently no effective solution to the above problems. Summary of the Invention
[0004] This application provides a method, apparatus, and electronic device for network registration, which at least solves the technical problem in the related art that terminals only initiate circuit-switched domain registration for a new beam after beam switching is completed, resulting in low registration efficiency during beam switching.
[0005] According to one aspect of the embodiments of this application, a network registration method is provided, comprising: when a terminal device moves to the coverage boundary area of a first beam, determining a beam switching prediction state of the terminal device; when the beam switching prediction state indicates that the terminal device will switch from the first beam to a second beam within a predicted switching duration, determining a coordination factor based on the predicted switching duration and the first channel quality of the second beam, wherein the coordination factor is used to quantify the matching relationship between the first channel quality and the urgency of beam switching; when the coordination factor is less than a preset threshold, performing a pre-registration process, wherein the pre-registration process is used to obtain a registration context corresponding to the second beam before beam switching; and after the terminal device switches to the second beam, performing network registration using the registration context.
[0006] In some embodiments of this application, the method further includes: acquiring handover information from the first beam to the second beam in historical data; determining a historical prediction deviation rate based on the handover information, wherein the historical prediction deviation rate is used to quantify the degree of difference between the historical predicted handover duration and the historical actual handover duration; determining a correction coefficient based on the historical prediction deviation rate, wherein the correction coefficient is used to adjust the duration of the pre-registration process; and correcting the predicted handover duration using the correction coefficient to obtain the corrected handover duration.
[0007] In some embodiments of this application, when the collaboration factor is less than a preset threshold, a pre-registration process is executed, including: when the collaboration factor is less than or equal to a first preset threshold, the pre-registration process is executed immediately; when the collaboration factor is greater than the first preset threshold but not greater than a second preset threshold, the pre-registration process is executed after a preset delay period, wherein the first preset threshold is less than the second preset threshold.
[0008] In some embodiments of this application, the method further includes: when the coordination factor is greater than a second preset threshold, rejecting the pre-registration process and executing the original registration process of the second beam after the beam switching is completed.
[0009] In some embodiments of this application, the pre-registration process includes: initiating a pre-registration resource request to the network side of the second beam, wherein the pre-registration resource request carries the identifier of the second beam and the correction handover duration; receiving response information returned by the network side, wherein the response information includes an acknowledgment response and a rejection response; when the response information is an acknowledgment response, interacting with the network side based on the resource identifier in the acknowledgment response to complete authentication and resource confirmation, and obtaining the registration context.
[0010] In some embodiments of this application, after the terminal device switches to the second beam, network registration is performed using a registration context, including: after the terminal device switches to the second beam, obtaining the second channel quality of the second beam; when the second channel quality is greater than or equal to a connection threshold, performing network registration using a registration context, wherein the connection threshold is used to determine whether the channel quality of the second beam is sufficient to support the completion of the pre-registration connection process.
[0011] In some embodiments of this application, the method further includes: when the quality of the second channel is less than the connection threshold, releasing the pre-registration resources and initiating the original registration process of the second beam.
[0012] In some embodiments of this application, the method further includes: determining pre-registration parameters based on the first channel quality of the second beam before performing the pre-registration process, wherein the pre-registration parameters include at least one of the following: pre-registration signaling transmission power level, number of pre-registration retries, and pre-registration timeout.
[0013] In some embodiments of this application, determining the correction coefficient based on the historical prediction deviation rate includes: when the historical prediction deviation rate is less than or equal to a first deviation rate, determining the first coefficient as the correction coefficient, wherein the first coefficient is used to extend the prediction handover duration; when the historical prediction deviation rate is greater than the first deviation rate but not greater than a second deviation rate, determining the second coefficient as the correction coefficient, wherein the second deviation rate is greater than the first deviation rate and the second coefficient is less than the first coefficient; when the historical prediction deviation rate is greater than the second deviation rate, determining the third coefficient as the correction coefficient, wherein the third coefficient is less than the second coefficient and the third coefficient is used to shorten the prediction handover duration.
[0014] In some embodiments of this application, the method further includes: determining a pre-registration validity period based on the modified switching duration, wherein the pre-registration validity period is used to determine the duration for which the registration context remains in a valid state after beam switching is completed.
[0015] In some embodiments of this application, the method further includes: determining the pre-registration success rate corresponding to different channel quality intervals based on historical data; determining a first channel quality interval where the pre-registration success rate is less than a first success rate, and increasing the corresponding pre-registration signaling transmission power level when the pre-registration process is triggered in the first channel quality interval; determining a second channel quality interval where the pre-registration success rate is greater than a second success rate, and reducing the corresponding pre-registration retries when the pre-registration process is triggered in the second channel quality interval, wherein the second success rate is greater than the first success rate.
[0016] According to another aspect of the embodiments of this application, another network registration method is also provided, including: when a terminal device moves to the coverage boundary area of a first beam and determines that it will switch from the first beam to a second beam within a predicted handover duration, receiving a pre-registration request sent by the terminal device, wherein the pre-registration request is triggered when a coordination factor is less than a preset threshold, the coordination factor is determined based on the predicted handover duration and the channel quality of the second beam, and the coordination factor is used to quantify the matching relationship between channel quality and beam switching urgency; in response to the pre-registration request, interacting with the terminal device to complete the pre-registration process, wherein the pre-registration process is used for the terminal device to obtain the registration context corresponding to the second beam before beam switching; and after the terminal device switches to the second beam, performing network registration based on the registration context sent by the terminal device.
[0017] In some embodiments of this application, in response to a pre-registration request, an interaction with a terminal device is performed to complete the pre-registration process, including: in response to the pre-registration request, determining the remaining capacity of the pre-registration resource pool, wherein the basic capacity of the pre-registration resource pool is determined based on the number of historically switched terminals; when the remaining capacity is greater than a preset capacity, returning confirmation response information to the terminal device, wherein the confirmation response information includes a resource identifier allocated to the terminal device; and interacting with the terminal device based on the resource identifier to complete authentication and resource confirmation.
[0018] In some embodiments of this application, the method further includes: when multiple terminal devices to be registered simultaneously initiate pre-registration with the third beam, determining the target coordination factor corresponding to each of the multiple terminal devices to be registered; determining the priority corresponding to each of the multiple terminal devices to be registered based on the target coordination factor; allocating pre-registration resources to the multiple terminal devices to be registered based on the priority, wherein the terminal devices to be registered that have not been allocated pre-registration resources enter the queuing queue according to their priority, and the validity period of the queuing queue is determined based on the corrected predicted switching time of the terminal devices to be registered.
[0019] According to another aspect of the embodiments of this application, a network registration apparatus is also provided, comprising: a first determining module, configured to determine a beam switching prediction state of the terminal device when the terminal device moves to the coverage boundary area of a first beam; a second determining module, configured to determine a coordination factor based on the prediction switching duration and the first channel quality of the second beam when the beam switching prediction state indicates that the terminal device will switch from the first beam to the second beam within a prediction switching duration, wherein the coordination factor is used to quantify the matching relationship between the first channel quality and the urgency of beam switching; an execution module, configured to execute a pre-registration process when the coordination factor is less than a preset threshold, wherein the pre-registration process is used to obtain a registration context corresponding to the second beam before beam switching; and a first registration module, configured to perform network registration using the registration context after the terminal device switches to the second beam.
[0020] According to another aspect of the embodiments of this application, another network registration apparatus is also provided, comprising: a receiving module, configured to receive a pre-registration request sent by the terminal device when the terminal device moves to the coverage boundary area of the first beam it is located in and determines that it will switch from the first beam to the second beam within a predicted handover duration, wherein the pre-registration request is triggered when the coordination factor is less than a preset threshold, the coordination factor is determined based on the predicted handover duration and the channel quality of the second beam, and the coordination factor is used to quantify the matching relationship between the channel quality and the urgency of beam switching; a response module, configured to interact with the terminal device to complete the pre-registration process in response to the pre-registration request, wherein the pre-registration process is used for the terminal device to obtain the registration context corresponding to the second beam before beam switching; and a second registration module, configured to perform network registration based on the registration context sent by the terminal device after the terminal device switches to the second beam.
[0021] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the above-described network registration method.
[0022] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described network registration method by running the computer program.
[0023] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described network registration method.
[0024] In this embodiment, when the terminal device moves to the coverage boundary of the first beam, the beam switching prediction state is detected. When it is predicted that the device will switch to the second beam, a coordination factor is determined based on the predicted switching duration and the channel quality of the second beam to quantify the matching relationship between the two. When the coordination factor is less than a preset threshold, a pre-registration process to obtain the registration context of the second beam is executed in advance. After the switch is completed, the network registration is performed using this context. This reduces the risk of registration interruption during beam switching, thereby achieving the technical effect of improving the registration processing efficiency during beam switching while ensuring communication continuity. This solves the technical problem in related technologies where the terminal only initiates circuit-switched domain registration for the new beam after the beam switch is completed, resulting in low registration efficiency during beam switching. Attached Figure Description
[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0026] Figure 1 This is a hardware structure block diagram of a computer terminal for a network registration method according to an embodiment of this application;
[0027] Figure 2 This is a flowchart of a network registration method according to an embodiment of this application;
[0028] Figure 3 This is a flowchart of another network registration method according to an embodiment of this application;
[0029] Figure 4 This is a schematic diagram of a network registration device according to an embodiment of this application;
[0030] Figure 5 This is a schematic diagram of another network registration device according to an embodiment of this application. Detailed Implementation
[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0033] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:
[0034] Circuit-Switched Domain (CS Domain): In wireless communication, the CS domain provides end-to-end circuit connections and mainly carries services with high real-time requirements, such as voice calls, SMS, and location updates. In satellite communication systems, it is responsible for updating the location information of terminals when they move to ensure that the network correctly routes calls. In this embodiment, the CS domain is the core service domain targeted by pre-registration optimization. By optimizing the registration process of this domain, the communication continuity during the handover process is guaranteed.
[0035] Registration Status Code (stat): A numerical identifier (value 0-8) returned by the terminal through instructions to identify the registration status, where 1 / 5 indicates success, 6 / 7 / 8 indicates an error, and 0 / 2 / 3 / 4 indicates not registered or in the process of registration. In this embodiment, the registration status code is used by the terminal to monitor and judge the registration progress and result of the current CS domain in real time, and serves as the basis for triggering pre-registration or regular retry strategies.
[0036] Satellite Channel Quality Factor (SCQF): A comprehensive parameter quantifying the characteristics of a satellite channel (range 0-10), calculated from signal strength (RSSI), Doppler frequency offset, and signal-to-noise ratio (SNR). A higher value indicates better channel quality. In this embodiment, SCQF is used as a core decision variable, and is used in conjunction with BHP state to calculate a coordination factor, which is used to dynamically determine the triggering timing of pre-registration, configure signaling transmission parameters (such as power and number of retries), and determine the handover strategy after handover.
[0037] Beam Handover Prediction (BHP): A mechanism in satellite communication for anticipating when a terminal is about to enter the coverage area of a new beam. By analyzing ephemeris data and combining it with the moving speed and direction, the handover time is predicted. When it is predicted that the terminal will enter the new beam within 5 seconds, the BHP flag is triggered. In the embodiments of this application, BHP provides advance information on the handover (original predicted handover duration) as a time reference for starting the pre-registration process, and is combined with SCQF to solve the problem of the disconnect between prediction and registration in traditional schemes.
[0038] Historical Registration Database (HRD): A structured database that stores historical data related to terminal CS domain registration (such as registration results, retry intervals, power levels, etc. under different channel environments). In this embodiment, the HRD is used to store the deviation data between historical handover duration and predicted duration, calculate the BHP prediction correction coefficient, thereby dynamically correcting the handover duration prediction result and improving the accuracy of the pre-registration start timing.
[0039] Multi-stage Retry Strategy (MRS): This is a progressive retry mechanism that divides the registration retry process into three stages: basic, enhanced, and dormant. By dynamically adjusting the retry interval and power level, it balances the registration success rate and terminal power consumption. In this embodiment, MRS serves as an alternative to the conventional registration process. When pre-registration fails due to reasons such as low SCQF, insufficient resources, or timeout, the terminal automatically downgrades and starts MRS to perform conventional CS domain registration, ensuring the final establishment of the connection.
[0040] AT Commands (Attention Commands): A set of commands starting with "AT" used to control the configuration, status query, and operation control of a modem. In this embodiment, AT commands are the control interface for interaction between the terminal application processor (AP) and the baseband module (BP). This solution expands the AT command set (such as AT+QBHP?, AT+QPREREG series) to realize BHP status query, pre-registration resource application, process connection, and exception handling, thereby achieving software-level functional upgrades.
[0041] Channel Multiplexing (CMUX) is a technology used to multiplex multiple logical channels on a single physical link to achieve concurrent data transmission and improve channel utilization. In this embodiment, CMUX provides underlying channel support for the transmission of BHP prediction information, SCQF measurement data, pre-registration signaling, and regular registration signaling between the terminal and the network side, ensuring low latency and high reliability transmission of various control signaling during the beam switching transition period.
[0042] Application Processor (AP): The main control processor responsible for running upper-layer applications and processing business logic. In this embodiment, the AP is the execution entity of this solution. It is responsible for collecting BHP status and SCQF data, calculating the coordination factor, querying the HRD database, calculating the correction coefficient, configuring pre-registration parameters, and controlling the baseband module to execute the pre-registration process and subsequent resource scheduling management through extended AT commands.
[0043] Baseband Module (BP): A core component in communication equipment responsible for handling physical layer and link layer functions such as wireless signal modulation and demodulation, encoding and decoding. In the embodiments of this application, the BP executes the AT commands issued by the AP, and actually completes the physical operations of radio frequency signal transmission and reception, beam switching, and the underlying transmission and reception of CS domain registration signaling. It is the hardware execution end for realizing pre-registration resource requests and authentication interaction.
[0044] In related technologies, BHP and CS domain registration are independent of each other, resulting in significant defects in the beam switching process:
[0045] (1) High risk of registration interruption after switching: The terminal only initiates CS domain registration of the new beam after the beam switching is completed. If the SCQF of the new beam is at a low level (such as the influence of mountainous areas), the registration process is easily interrupted and repeated retries are required, which seriously affects the transmission of key information in emergency communication scenarios.
[0046] (2) BHP prediction does not correlate with channel quality, and pre-registration is missing: The BHP used in related technologies can only predict the handover time and does not combine SCQF to judge the channel adaptability of the target beam. If the target beam has a low SCQF, even if the handover is known in advance, registration cannot be prepared in advance. If the target beam has a high SCQF, channel resources will be wasted because registration preparation has not been started in advance, and the registration time after the handover is long, which makes it difficult to meet the low latency requirements.
[0047] (3) Switching registration resource conflict: New beam registration requires network signaling resources. When multiple terminals (such as ship formation navigation scenarios) switch to the same beam at the same time, resource contention is likely to occur, leading to an increase in the registration failure rate. At the same time, the lack of a dedicated resource reservation mechanism means that pre-registration has no feasible landing path, further exacerbating the resource conflict problem.
[0048] (4) Insufficient BHP prediction accuracy affects registration adaptation: The BHP used in the relevant technologies only predicts the switching time based on ephemeris and motion parameters, without introducing historical data for deviation correction, resulting in a large deviation in the prediction of switching time, which in turn causes registration preparation to be too early (pre-registration failure) or too late (preparation cannot be completed and regular registration is still required).
[0049] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.
[0050] The network registration method embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a network registration method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0051] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).
[0052] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the network registration method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned network registration method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0053] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.
[0054] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.
[0055] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.
[0056] In the above operating environment, this application provides an embodiment of a network registration method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0057] Figure 2 This is a flowchart of a network registration method according to an embodiment of this application, such as... Figure 2As shown, the execution entity is the terminal side, and the method includes the following steps:
[0058] Step S202: When the terminal device moves to the coverage boundary area of the first beam it is in, determine the beam switching prediction state of the terminal device.
[0059] In step S202 above, the coverage boundary area refers to the edge of the spatial coverage range of the serving beam currently being used by the terminal equipment in the satellite communication system. In a satellite communication system scenario, as the terminal equipment moves, when the equipment enters this area, it indicates that the signal coverage of the current beam will gradually weaken and will soon be unable to meet communication needs, necessitating a switch to a nearby beam to maintain the connection.
[0060] The beam switching prediction status refers to the time window and confidence index of an upcoming beam switching calculated and output by the terminal device through its built-in beam switching prediction mechanism. This status includes not only a binary judgment of "whether a switch is about to occur", but also specific prediction switch duration parameters.
[0061] It should be noted that terminal equipment refers to handheld or vehicle-mounted mobile terminals with satellite communication system capabilities, which contain an application processor and a baseband module.
[0062] In some embodiments of this application, the terminal AP periodically sends an AT command (AT+QBHP?) to query the BHP flag. If the flag returns "1" (indicating that a beam switching is predicted to occur in a short time), the original predicted switching duration output by the BHP is read; if the flag returns "0" (no switching prediction), the existing conventional registration process is maintained, and the pre-registration operation is not initiated to ensure that resources are not redundantly occupied.
[0063] Taking Tiantong satellite as an example, in some embodiments of this application, new AT commands can be added based on the Tiantong protocol standard specification to achieve pre-registration control while ensuring compatibility with existing terminals. Specifically, four extended commands are added based on the Tiantong satellite terminal standard AT command set, as shown in Table 1.
[0064] Table 1: Parameters and Return Results of Extended AT Commands for Pre-registration Control of Tiantong Satellite Terminal
[0065]
[0066] It should be noted that for older terminals that do not support extended commands, the system automatically disables the pre-registration function, maintains the existing regular registration process, avoids functional conflicts, and ensures compatibility with all terminals across all scenarios.
[0067] Step S204: When the beam switching prediction state indicates that the terminal device will switch from the first beam to the second beam within the predicted switching time, a coordination factor is determined based on the predicted switching time and the first channel quality of the second beam. The coordination factor is used to quantify the matching relationship between the first channel quality and the beam switching urgency.
[0068] In step S204 above, the predicted handover duration refers to the estimated time required from the current moment to the completion of the upcoming beam switching action, calculated by the terminal device through the beam switching prediction mechanism. In satellite communication systems, this duration is calculated in real time by the baseband module based on ephemeris data, terminal movement speed, and direction vector. The predicted handover duration determines the time window for initiating the pre-registration process. The shorter the duration, the higher the urgency of the handover, requiring earlier or more proactive initiation of pre-registration preparation; the longer the duration, the more ample the time allowed.
[0069] The first channel quality of the second beam refers to the current signal transmission quality of the target beam (i.e., the second beam) that the terminal equipment anticipates will switch to. It can be reflected as the satellite channel quality factor, which integrates multiple physical layer indicators such as signal strength, Doppler frequency offset, and signal-to-noise ratio. The higher the value, the better the channel condition.
[0070] The coordination factor is a dimensionless numerical index used to quantify the matching relationship or fit between the target beam channel quality and the urgency of beam switching. Its calculation logic is negatively correlated with the predicted switching time and the quality of the first channel. That is, the more urgent the switching and the better the channel, the smaller the coordination factor, indicating that the pre-registration initiation is more appropriate; conversely, if the switching is not urgent or the channel is poor, the larger the coordination factor, indicating that the necessity of pre-registration initiation is reduced.
[0071] In some embodiments of this application, a coordination factor calculation model is constructed based on the BHP-predicted handover duration (denoted as T_bhp) and the SCQF value of the current target beam. The core design logic of this factor is: the higher the SCQF value (better channel quality) and the shorter the BHP-predicted handover duration (more urgent handover), the smaller the coordination factor, representing a higher "fitness" for pre-registration initiation. For example, coordination factor = (normalized T_bhp) / (T ... 0.5) + ((1-normalized SCQF) The factor of 0.5 can quantify the matching relationship between channel quality and handover urgency, providing an objective basis for pre-registration triggering.
[0072] In some embodiments of this application, the following steps may also be performed: obtaining handover information from the first beam to the second beam in historical data; determining the historical prediction deviation rate based on the handover information, wherein the historical prediction deviation rate is used to quantify the degree of difference between the historical predicted handover duration and the historical actual handover duration; determining a correction coefficient based on the historical prediction deviation rate, wherein the correction coefficient is used to adjust the duration of the pre-registration process; and correcting the predicted handover duration using the correction coefficient to obtain the corrected handover duration.
[0073] It should be noted that historical data refers to a collection of detailed records about the terminal's past handover processes between different beams, stored in the historical registration database on the local device or network side. These records include, but are not limited to, structured data such as historical predicted handover duration, historical actual handover duration, satellite channel quality factor at the time, pre-registration results, and time consumption.
[0074] In some embodiments of this application, the existing Historical Registration Database (HRD) is upgraded in the application processor (AP) or baseband module (BP) of the terminal device by adding the following four key fields to each beam switching record in the HRD table:
[0075] (1) Original BHP prediction duration: The theoretical remaining switching time calculated by the beam switching prediction (BHP) module when the terminal initiates pre-registration.
[0076] (2) Actual handover time: Record the actual time consumed from the time the terminal issues the handover command to the actual establishment of the physical link of the new beam.
[0077] (3) Pre-registration result: Record the final status of the pre-registration process, including "success", "failure" or "timeout".
[0078] (4) Pre-registration time: Record the time elapsed from initiating the pre-registration request to receiving the "Pre-registration complete" response (PREREG DONE).
[0079] For newly added fields, fixed-length storage or compressed encoding methods are adopted (for example, the duration is stored as an integer value with millisecond precision, and the result status is represented by a bitmap). The number of bytes occupied by each record is strictly controlled (for example, each record is limited to no more than 20 bytes) to prevent the HRD from expanding indefinitely with the increase of usage time and to ensure the stable use of local storage resources on the terminal.
[0080] Furthermore, the historical switching records of specific beam pairs (such as "current beam A -> target beam B") in the HRD are periodically scanned to perform deviation analysis. Specifically, based on a preset record accumulation threshold (e.g., the cumulative number of records reaches N, where N is a preset positive integer), it is determined whether the recalculation condition is met: if the threshold is not reached, the current correction coefficient remains unchanged; if the threshold is reached or exceeded, the iterative calculation process is triggered.
[0081] The iterative calculation process is as follows: extract the set of historical records that meet the conditions and calculate the historical prediction deviation rate. Based on the calculated historical deviation rate, dynamically generate or update the correction coefficients used to correct the BHP prediction results. When the terminal subsequently performs beam switching prediction, apply the correction coefficients to obtain a switching duration that is more in line with reality.
[0082] The historical prediction deviation rate is a percentage value used to quantify the difference between the historically predicted handover duration and the historically actual handover duration, reflecting the accuracy of the current beam handover prediction algorithm. A higher deviation rate indicates a larger error between the current ephemeris calculation or motion velocity estimation and the actual physical handover process; a lower deviation rate indicates a more reliable prediction result.
[0083] The correction factor directly affects the original predicted handover duration, generating a more realistic corrected handover duration. Its purpose is to calibrate the effective time window of the pre-registration: if the predicted long-term handover duration is too short, the validity period is extended through the correction factor to prevent the pre-registration from expiring before the handover is completed; if the predicted long-term handover duration is too long, the validity period is shortened to avoid long-term resource idleness.
[0084] In some embodiments of this application, the correction coefficient can be determined in the following ways: when the historical prediction deviation rate is less than or equal to the first deviation rate, the first coefficient is determined as the correction coefficient, wherein the first coefficient is used to extend the prediction switching time; when the historical prediction deviation rate is greater than the first deviation rate but not greater than the second deviation rate, the second coefficient is determined as the correction coefficient, wherein the second deviation rate is greater than the first deviation rate and the second coefficient is less than the first coefficient; when the historical prediction deviation rate is greater than the second deviation rate, the third coefficient is determined as the correction coefficient, wherein the third coefficient is less than the second coefficient and the third coefficient is used to shorten the prediction switching time.
[0085] Specifically, the AP queries the HRD (historical record data) for recent valid handover records of "current beam -> target beam" (i.e., first beam -> second beam), and calculates the historical prediction deviation rate using a statistical formula (deviation rate = sum of deviations between actual historical handover duration and predicted duration / (predicted duration)). (Number of records) 100%). Adjustment coefficients are configured based on the deviation rate:
[0086] (1) Deviation rate less than or equal to the set low threshold: The correction coefficient is set to a higher value. At this time, the prediction result is more reliable. The prediction time after correction is appropriately extended (T_bhp'=T_bhp). (Correction factor) to prevent pre-registration from expiring due to an excessively short validity period.
[0087] (2) Deviation rate is between low and high threshold: The correction coefficient is set as the benchmark value to maintain the predicted duration basically stable and ensure that it matches the actual switching rhythm.
[0088] (3) Deviation rate is greater than the set high threshold: the correction coefficient is set to a lower value to shorten the prediction time after correction, and prevent the registration preparation from being delayed due to excessive prediction time, which would prevent the connection of the switching process.
[0089] In some embodiments of this application, the pre-registration validity period is determined based on the modified handover duration, wherein the pre-registration validity period is used to determine the duration for which the registration context remains in a valid state after beam switching is completed.
[0090] The pre-registration validity period refers to the length of time from the start of the pre-registration process until the pre-registration resource and its associated registration context (such as temporary authentication token, base station ID, time slot information, etc.) simultaneously expire on both the network side and the terminal side. It defines the time window during which the terminal can legally occupy the pre-registration dedicated resources (such as dedicated signaling time slots and temporary authentication channels) in the target beam. If the beam switching is completed and the registration connection is executed within this period, there is no need to re-initiate the complete registration process; if the connection is not completed within the time limit, the resources will be automatically reclaimed.
[0091] Registration context refers to the set of key data exchanged and stored between the terminal and the network side during the pre-registration process for quickly completing subsequent CS domain registration, including but not limited to temporary authentication tokens, target beam identifiers, allocated signaling time slot information, base station IDs, etc.
[0092] Specifically, after calculating the corrected switching duration, the application processor of the terminal device determines the pre-registration validity period based on a preset multiple relationship or a fixed offset. The pre-registration validity period can be set as a fixed multiple of the corrected predicted duration (e.g., 1.2 times the corrected predicted duration or a specific ratio), or it can be set as the corrected predicted duration plus a certain safety margin time. For example, if the corrected switching duration is 5 seconds, the system may set the pre-registration validity period to 6 seconds or 7 seconds.
[0093] By dynamically determining the pre-registration validity period based on high-precision correction handover duration, the resource lifecycle is accurately synchronized with actual business needs. This ensures that pre-registered resources (including authentication tokens and signaling time slots) remain valid for a short period after beam handover, providing the necessary conditions for rapid registration and connection. At the same time, it avoids the invalid occupation of network signaling resources due to excessively long validity periods.
[0094] Step S206: When the coordination factor is less than a preset threshold, a pre-registration process is executed, wherein the pre-registration process is used to obtain the registration context corresponding to the second beam before beam switching.
[0095] In step S206 above, the pre-registration process refers to a series of signaling interactions initiated by the terminal device to the target beam network side before beam switching occurs. This process aims to complete authentication, resource reservation, and registration context acquisition in advance. This process includes, but is not limited to, applying for pre-registration resources, sending authentication requests, obtaining temporary authentication tokens, and confirming resource occupancy. It should be noted that the purpose of the pre-registration process is to establish a logical connection with the target beam in advance before the terminal moves to the second beam. This allows the terminal to directly call the acquired registration context to quickly complete the remaining registration steps after the physical beam switching is completed, thereby significantly shortening the switching delay and reducing the risk of registration interruption.
[0096] In some embodiments of this application, after calculating the coordination factor, the application processor of the terminal device compares it with a preset low threshold. If the coordination factor is less than or equal to the preset low threshold (indicating good coordination, i.e., high channel quality and urgent handover), the application processor determines that the immediate triggering condition is met and then starts the pre-registration process.
[0097] As an example, the pre-registration process may include: the application processor initiating a resource request to the network side via extended AT commands, the commands carrying the target second beam identifier and the corrected predicted duration. The network side checks the capacity of the pre-registration resource pool; if the capacity is sufficient, it allocates a temporary authentication channel and a dedicated signaling time slot, and returns a confirmation response containing the resource ID and validity period. After receiving the response, the terminal sends an authentication request carrying the terminal's International Mobile Subscriber Identity (IMSI) and the resource ID to the authentication server of the target beam network. After successful verification, the authentication server returns a temporary authentication token. The terminal receives and stores this token, and simultaneously sends a resource reservation confirmation command to lock the signaling time slot. Finally, the terminal receives the pre-registration completion response returned by the network side and locally stores the registration context containing key data such as the base station ID and time slot information.
[0098] In some embodiments of this application, when the collaboration factor is less than a preset threshold, a pre-registration process is executed. Specifically: when the collaboration factor is less than or equal to a first preset threshold, the pre-registration process is executed immediately; when the collaboration factor is greater than the first preset threshold but not greater than a second preset threshold, the pre-registration process is executed after a preset delay period, wherein the first preset threshold is less than the second preset threshold.
[0099] Specifically, when the coordination factor is greater than the second preset threshold, the pre-registration process is rejected, and the original registration process of the second beam is executed after the beam switching is completed.
[0100] Specifically, three trigger levels are defined based on the collaborative factors to adapt to different scenario requirements:
[0101] (1) If the coordination factor is less than or equal to the set low threshold (i.e., the first preset threshold, with good coordination, such as when the SCQF is at a high level and handover is about to occur): pre-registration is triggered immediately. At this time, the channel stability is strong, and early activation can make full use of the high-quality channel to complete the registration preparation, avoiding registration interruption due to channel deterioration after handover.
[0102] (2) When the coordination factor is between the low threshold and the medium threshold (i.e., the second preset threshold) (moderate coordination, such as when the SCQF is at a medium level and there is still a buffer time for handover): pre-registration is triggered after a short delay. The delay design can avoid the impact of instantaneous channel fluctuations, while ensuring that basic registration preparation is completed before handover, balancing timeliness and stability.
[0103] (3) If the coordination factor is greater than the set threshold (poor coordination, such as SCQF at a low level): pre-registration is not triggered. At this time, the channel quality is insufficient to support a stable registration process, and forcibly starting the process will lead to a waste of resources. Therefore, regular registration is started after the handover is completed to reduce the risk of failure.
[0104] In some embodiments of this application, the pre-registration process can be performed through the following steps: initiating a pre-registration resource request to the network side of the second beam, wherein the pre-registration resource request carries the identifier of the second beam and the correction handover duration; receiving response information returned by the network side, wherein the response information includes an acknowledgment response and a rejection response; when the response information is an acknowledgment response, interacting with the network side based on the resource identifier in the acknowledgment response to complete authentication and resource confirmation, and obtaining the registration context.
[0105] Specifically, (1) Resource pool application:
[0106] After the terminal triggers pre-registration, it initiates a resource request to the target beam network via an extended AT command (AT+QPREREG=REQ,<target beam ID>,<corrected predicted duration>). The command carries the target beam ID and the corrected predicted duration to facilitate network identification of the terminal's needs. Upon receiving the request, the network side first checks the remaining capacity of the pre-registration resource pool.
[0107] If there is sufficient remaining capacity: allocate a temporary authentication channel and a dedicated signaling time slot to the terminal, and return an acknowledgment response (PREREG ACK, <Resource ID>, <Validity Period>). The Resource ID is used for identification in subsequent processes.
[0108] If the remaining capacity is insufficient: a PREREG NACK response is returned, the terminal immediately terminates the pre-registration, and starts regular registration after the beam switching is completed, to avoid resource contention and overall efficiency degradation.
[0109] (2) Execution of the pre-registration process:
[0110] After obtaining the resource ID, the terminal performs pre-registration according to standardized procedures to ensure that the process is traceable and verifiable.
[0111] The terminal sends an authentication request to the target beam network authentication server, carrying the terminal's IMSI (International Mobile Subscriber Identity) and temporary resource ID to ensure the legitimacy of its identity.
[0112] After the authentication server verifies the authentication, it returns an authentication success response to the terminal, and the terminal stores a temporary authentication token (the validity period is the same as the pre-registration validity period).
[0113] The terminal sends a resource reservation confirmation instruction to specify the allocated signaling time slots and prevent network side errors from reclaiming resources.
[0114] After the network side confirms resource occupancy, it returns a pre-registration completion response (PREREG DONE). The terminal locally stores the target beam registration context (including key data such as base station ID and timeslot information) to prepare for rapid handover.
[0115] In some embodiments of this application, before performing the pre-registration process, pre-registration parameters are determined based on the first channel quality of the second beam, wherein the pre-registration parameters include at least one of the following: pre-registration signaling transmission power level, number of pre-registration retries, and pre-registration timeout.
[0116] Specifically, the AP dynamically adjusts the pre-registration signaling transmission power level, retry count, and timeout time based on the target beam SCQF value, achieving precise matching of parameters and channel quality.
[0117] As an example, the pre-registration parameters can be configured as shown in Table 2.
[0118] Table 2: Pre-registration parameter configuration table based on SCQF values.
[0119]
[0120] In some embodiments of this application, the following steps may also be performed: determining the pre-registration success rate corresponding to different channel quality intervals based on historical data; determining a first channel quality interval where the pre-registration success rate is less than a first success rate, and increasing the corresponding pre-registration signaling transmission power level when the pre-registration process is triggered in the first channel quality interval; determining a second channel quality interval where the pre-registration success rate is greater than a second success rate, and reducing the corresponding pre-registration retries when the pre-registration process is triggered in the second channel quality interval, wherein the second success rate is greater than the first success rate.
[0121] It should be noted that a channel quality interval refers to dividing continuous satellite channel quality factor values into several discrete intervals (such as high, medium, and low levels, or even finer-grained intervals), each interval corresponding to specific channel environment characteristics. The pre-registration success rate refers to the proportion of pre-registration processes that are ultimately successfully completed and obtain a valid registration context within a specific channel quality interval.
[0122] Specifically, the application processor of the terminal device periodically scans the historical registration database and extracts all completed pre-registration records. The application processor maps the satellite channel quality factor (SCQF) in each record to a predefined channel quality interval (e.g., SCQF>=8 for the high interval, 4<=SCQF<8 for the medium interval, and SCQF<4 for the low interval). For each interval, it calculates the total number of pre-registration attempts and the number of successful attempts within that interval. By calculating "number of successful attempts / total number of attempts," the current pre-registration success rate for that interval is obtained.
[0123] Furthermore, the application processor compares the calculated pre-registration success rate for each interval with a preset first success rate threshold (e.g., 50%). If the success rate of a certain channel quality interval is lower than the first success rate, that interval is marked as a "low success rate interval" (i.e., the first channel quality interval). When the terminal device subsequently detects that the current satellite channel quality factor falls into this low success rate interval and triggers the pre-registration process, the application processor automatically queries the parameter configuration table and adjusts the originally default "balanced efficiency and power consumption level" to "enhanced signal stability level" (i.e., increased signaling transmission power).
[0124] Furthermore, the application processor compares the pre-registration success rate of each interval with a preset second success rate threshold (e.g., 90%, and 90% > 50%). If the success rate of a certain channel quality interval is higher than the second success rate, that interval is marked as a "high success rate interval" (i.e., the second channel quality interval). When the terminal device subsequently detects that the current satellite channel quality factor falls into this high success rate interval and triggers the pre-registration process, the application processor will adjust the originally configured higher number of retries (e.g., 2 times) to a lower number of retries (e.g., 1 time, or even 0 times, i.e., no retries, depending on the specific implementation).
[0125] The above steps, by introducing a historical learning module based on historical data, achieve closed-loop adaptive optimization of pre-registration parameters. For the low success rate range, signal robustness is enhanced by increasing transmission power, thereby improving registration reliability. For the high success rate range, power consumption and signaling overhead are reduced by decreasing the number of retries, thereby improving registration efficiency.
[0126] Step S208: After the terminal device switches to the second beam, network registration is performed using the registration context.
[0127] In step S208 above, the terminal device switching to the second beam refers to the process in which the physical connection of the terminal device is disconnected from the current first beam (source beam) and a physical link connection is successfully established with the target second beam (target beam) during the movement of the terminal device.
[0128] Network registration: refers to the process by which a terminal device sends a location update request to the circuit-switched domain (CS domain) access server of a satellite communication system in order to update its current location information and obtain communication permissions.
[0129] In some embodiments of this application, after the terminal device switches to the second beam, network registration can be performed in the following manner: after the terminal device switches to the second beam, the second channel quality of the second beam is obtained; when the second channel quality is greater than or equal to the connection threshold, network registration is performed using the registration context, wherein the connection threshold is used to determine whether the channel quality of the second beam is sufficient to support the completion of the pre-registration connection process.
[0130] Specifically, when the quality of the second channel is less than the connection threshold, the pre-registration resources are released and the original registration process of the second beam is initiated.
[0131] Specifically, the terminal queries the current beam ID in real time via AT commands. If the query result matches the target beam ID, the beam switching is considered complete, and the registration and connection process is immediately initiated. After the switch is completed, the terminal immediately collects the new beam SCQF value (i.e., the second channel quality) and, in conjunction with a preset connection threshold, determines subsequent operations.
[0132] (1) If SCQF >= switching & registration connection threshold:
[0133] The terminal sends an extended AT command (AT+QPREREG=CONT,<resource ID>,<temporary authentication token>) to call the pre-registration context stored locally, quickly completing the remaining registration steps (such as location update and signaling synchronization), significantly reducing connection time.
[0134] (2) If SCQF < handover & registration connection threshold:
[0135] The terminal sends a resource release command (AT+QPREREG=CANCEL,<resource ID>) to actively release the pre-registered resources, and at the same time starts the regular registration process (executed according to the original mobility management policy) to ensure registration reliability.
[0136] In some embodiments of this application, exception handling strategies are also provided, including but not limited to:
[0137] Pre-registration timeout (PREREG DONE not received within the pre-registration timeout period): Pre-registration will be retried once only if SCQF >= the set low threshold; if the retry still fails, pre-registration will be abandoned to avoid continuous resource occupation.
[0138] If the pre-registered resources expire after the switch (exceeding the pre-registration validity period): The terminal will automatically release the allocated resources and start regular registration to prevent registration failure due to the use of expired information.
[0139] Network-side resource recycling: For pre-registered resources that have not been fully connected or have expired, the network side initiates a timed recycling mechanism to automatically release resources and update the resource pool capacity, ensuring resource recycling.
[0140] Through the above steps S202 to S208, when the terminal device moves to the coverage boundary of the first beam, the beam switching prediction state is detected. When it is predicted that the device will switch to the second beam, a coordination factor is determined based on the predicted switching duration and the channel quality of the second beam to quantify the matching relationship between the two. When the coordination factor is less than a preset threshold, a pre-registration process to obtain the registration context of the second beam is executed in advance. After the switch is completed, the network registration is performed using this context. This achieves the goal of reducing the risk of registration interruption during beam switching, thereby achieving the technical effect of improving the registration processing efficiency during beam switching while ensuring communication continuity. This solves the technical problem in related technologies where the terminal only initiates circuit-switched domain registration for the new beam after the beam switch is completed, resulting in low registration efficiency during beam switching.
[0141] Figure 3 This is a flowchart of another network registration method according to an embodiment of this application, such as... Figure 3 As shown, the execution entity is the network side, and the method includes:
[0142] Step S302: When the terminal device moves to the coverage boundary area of the first beam it is in and determines that it will switch from the first beam to the second beam within the predicted handover time, a pre-registration request sent by the terminal device is received. The pre-registration request is triggered when the coordination factor is less than a preset threshold. The coordination factor is determined based on the predicted handover time and the channel quality of the second beam. The coordination factor is used to quantify the matching relationship between channel quality and beam switching urgency.
[0143] In step S302 above, the pre-registration request refers to the signaling message sent by the terminal device to the network side after determining that the pre-registration triggering conditions are met. The purpose is to apply for pre-registration resources in the target beam and establish a pre-registration session. The request may carry key parameters such as the target beam identifier and the corrected predicted handover duration.
[0144] Step S304: In response to the pre-registration request, interact with the terminal device to complete the pre-registration process, wherein the pre-registration process is used by the terminal device to obtain the registration context corresponding to the second beam before beam switching.
[0145] In step S304 above, the pre-registration process refers to a series of signaling interactions between the network side and the terminal device after receiving the pre-registration request from the terminal device. This process includes, but is not limited to, resource pool checks, temporary authentication channel allocation, signaling time slot reservation, authentication verification, and temporary authentication token generation.
[0146] In some embodiments of this application, the pre-registration process can be completed by interacting with the terminal device through the following steps: in response to the pre-registration request, the remaining capacity of the pre-registration resource pool is determined, wherein the basic capacity of the pre-registration resource pool is determined based on the number of historically switched terminals; when the remaining capacity is greater than the preset capacity, a confirmation response information is returned to the terminal device, wherein the confirmation response information includes a resource identifier allocated to the terminal device; authentication and resource confirmation are completed by interacting with the terminal device based on the resource identifier.
[0147] It should be noted that the pre-registration resource pool refers to a set of signaling resources specifically allocated by the network side to support the pre-registration operation during beam switching. This resource pool includes logical resources such as temporary authentication channels and dedicated signaling time slots, which are used to reserve necessary network access resources for the terminal in advance before the physical handover is completed.
[0148] The confirmation response message refers to the signaling message returned by the network side to the terminal device after verifying that the pre-registered resource pool has sufficient capacity. The resource identifier refers to the unique identifier generated by the network side and returned to the terminal device after successfully allocating pre-registered resources. This identifier is used to refer to a specific pre-registered session and resource instance in subsequent authentication, resource confirmation, and registration connection processes.
[0149] Specifically, the network-side system first calculates the average number of hands-on terminals for the target beam within a specific time window (e.g., the past hour) based on historical statistics. Based on this average, the system sets the base capacity of the pre-registration resource pool, for example, by adding a certain redundancy ratio (e.g., 20%) to cope with short-term traffic fluctuations. When a pre-registration request from a terminal device is received, the network side queries the current status of the pre-registration resource pool in real time and calculates the remaining capacity.
[0150] Furthermore, the network side compares the calculated remaining capacity with a preset capacity threshold. If the remaining capacity is greater than the preset threshold (indicating sufficient resources), the network side performs a resource allocation operation, allocating a temporary authentication channel and a dedicated signaling time slot to the terminal, and generating a unique resource identifier (e.g., resource ID). Subsequently, the network side sends a confirmation response to the terminal device, which explicitly includes the allocated resource identifier and the resource's validity period (e.g., set based on the modified predicted handover duration in the terminal request). If the remaining capacity is insufficient, the network side returns a rejection response, terminating the pre-registration process.
[0151] Furthermore, after receiving the confirmation response information containing the resource identifier, the terminal device uses the resource identifier to construct an authentication request signaling and sends a request to the authentication server on the network side, simultaneously carrying the terminal's International Mobile Subscriber Identity (IMSI). After successful verification, the authentication server generates a temporary authentication token and returns it to the terminal. Upon receiving the token, the terminal sends a resource reservation confirmation instruction to the network side, explicitly declaring the reserved signaling time slot, and again carrying the resource identifier in the instruction. Upon receiving the confirmation, the network side verifies that the resource corresponding to the resource identifier is available and finally returns a pre-registration complete response (PREREG DONE). This completes the authentication and resource confirmation interaction, and the pre-registration process is logically finished.
[0152] In some embodiments of this application, the pre-registration resource pool can be managed through the following mechanisms:
[0153] (1) Capacity calculation: The basic capacity of the resource pool is combined with the average number of switching terminals per hour of the current beam, and a certain amount of redundancy is reserved to ensure that the basic resources can cover the regular switching needs, while also dealing with short-term traffic fluctuations.
[0154] (2) Real-time adjustment: The resource pool occupancy rate (number of occupied resources / total capacity) is statistically analyzed at fixed intervals to dynamically adapt to changes in demand: When the occupancy rate is too high, the capacity is increased appropriately (not exceeding the upper limit of the basic capacity) to avoid multiple terminals competing for resources; when the occupancy rate is too low, the capacity is reduced appropriately (not lower than the lower limit of the basic capacity) to prevent idle and wasted resources.
[0155] (3) Resource recycling: Differentiated recycling rules are set for different scenarios: Resources that have not been connected after the pre-registration validity period expires are immediately recycled and redistributed. After the terminal actively sends a cancellation command, the resource recycling is completed within a short period of time. Resources that have not been connected after the terminal switches are automatically recycled after a fixed delay, taking into account the needs of temporary connection.
[0156] Step S306: After the terminal device switches to the second beam, network registration is performed based on the registration context sent by the terminal device.
[0157] In step S306 above, network registration refers to the process by which the terminal device actively sends a signaling request containing registration context information to the network side after beam switching is completed, so as to quickly complete the location update and communication permission acquisition process by utilizing the trust relationship and resource reservation established in the pre-registration stage.
[0158] In some embodiments of this application, the following steps may also be performed: when multiple terminal devices to be registered simultaneously initiate pre-registration with the third beam, determine the target coordination factor corresponding to each of the multiple terminal devices to be registered; determine the priority corresponding to each of the multiple terminal devices to be registered based on the target coordination factor; allocate pre-registration resources to the multiple terminal devices to be registered based on the priority, wherein the terminal devices to be registered that have not been allocated pre-registration resources enter the queuing queue according to their priority, and the validity period of the queuing queue is determined based on the corrected predicted switching time of the terminal devices to be registered.
[0159] Specifically, when multiple terminals simultaneously initiate pre-registration to the same target beam, the network first calculates the coordination factor of each terminal and sorts them in ascending order of factor value (the smaller the factor, the higher the pre-registration adaptability and the higher the priority). Resources are allocated preferentially to high-priority terminals to ensure that terminals with good channel quality and urgent handover needs can quickly complete pre-registration. If resources are insufficient, low-priority terminals (with coordination factors exceeding a set threshold) enter a queuing queue. The queue validity period is associated with the terminal's revised predicted duration; if resources are not allocated within the timeout period, pre-registration is abandoned to avoid prolonged queue occupation. During the queuing period, terminals periodically query the resource pool status; if resources are released, they are allocated according to the queuing order to improve resource utilization.
[0160] It should be noted that, Figure 3 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 The corresponding solutions in the illustrated embodiments will not be described in detail here.
[0161] This application's embodiments overcome the limitations of existing independent operation of BHP and CS domain registration, proposing a coordination factor to quantify their correlation. Pre-registration is initiated through a tiered triggering logic: when the channel quality and handover urgency match well (low coordination factor), pre-registration is triggered promptly; when the match is moderate, triggering is delayed to balance stability; and when the match is low (poor channel quality), triggering is not initiated to avoid resource waste. Furthermore, the coordination factor calculation model is tailored to the characteristics of the Tiantong satellite scenario, combining BHP prediction duration with dynamic adjustment of SCQF; simultaneously, HRD is introduced to correct the BHP prediction results, further improving the accuracy of pre-registration initiation timing, distinguishing it from general wireless communication schemes.
[0162] This application's embodiments design a dedicated resource pool for target beam pre-registration, dynamically adjusting its capacity according to the principle of "real-time demand + redundancy": a basic capacity is set based on the historical number of handover terminals, and elastically increased or decreased according to real-time occupancy rates to avoid resource idleness or insufficiency. Simultaneously, for scenarios with multiple terminals handover simultaneously, a collaborative factor priority scheduling mechanism is adopted: resources are allocated according to collaborative factor ranking, with highly adaptable terminals receiving priority; when resources are insufficient, low-priority terminals enter a time-limited queuing queue, balancing scheduling fairness and efficiency, and resolving the resource contention problem in traditional solutions.
[0163] To facilitate understanding of the above network registration process, the following explanation will be provided in conjunction with some specific embodiments.
[0164] Step 1: BHP state detection and synergy factor calculation.
[0165] When the ship terminal moves to the coverage boundary of beam A, the terminal AP periodically sends the AT+QBHP? command to query the BHP status. The returned result shows that a beam switch is about to occur (BHP indicates the switch status, including the original predicted switch duration).
[0166] The AP synchronously sends a command to obtain the SCQF value of the current target beam B, and calculates the coordination factor based on the original predicted handover duration of the BHP. If the coordination factor is determined to be in the medium range (between the low and medium thresholds), the pre-registration process is triggered after a short delay according to the rules.
[0167] Step 2: BHP prediction correction and parameter configuration.
[0168] AP queries the historical switching records of "beam A -> beam B" in the historical data (HRD), obtains the historical deviation rate through statistical analysis, determines the correction coefficient based on this, calculates the predicted duration after correction, and sets the pre-registration validity period based on this duration.
[0169] Based on the current SCQF value range (medium level), the system automatically configures the pre-registration parameters: adopts a power level to enhance signal stability, reserves a small number of retries (to deal with possible transient interference), and sets the timeout time to a base multiple of the corrected predicted duration, balancing process speed and reliability.
[0170] Step 3: Pre-register resource application and process execution.
[0171] The AP initiates a pre-registration resource request to the beam B network via the extended command AT+QPREREG=REQ, carrying the target beam identifier and the corrected predicted duration.
[0172] The Beam B network side checks the status of the pre-registered resource pool. After confirming that there is sufficient remaining capacity, it allocates temporary resources (including resource ID and validity period) to the terminal and returns a confirmation response.
[0173] After receiving the response, the terminal performs pre-registration according to the procedure: sending an authentication request carrying the terminal identity identifier (such as IMSI) and resource ID; receiving a temporary authentication token returned by the network side (the validity period is consistent with the pre-registration validity period); sending a resource reservation confirmation instruction to confirm the occupied and allocated signaling resources; after receiving the pre-registration completion response returned by the network side, the terminal locally stores the registration context of beam B (including key data such as base station identifier and timeslot information).
[0174] Step 4: Switching & Registration Connection and Completion.
[0175] The terminal monitors the beam status in real time using the AT+QBEAM command. When it detects that the current beam ID has been updated to the identifier of the target beam B, it determines that the handover is complete.
[0176] Immediately after the switch, the SCQF value of beam B is collected. If the value is found to be higher than the preset connection threshold, the terminal sends the extended command AT+QPREREG=CONT, carrying the resource ID and temporary authentication token, and calls the pre-registration context stored locally.
[0177] After verifying the validity of the resources on the network side, the remaining registration steps (such as location update and signaling synchronization) are completed quickly. Finally, the terminal queries the registration status and displays success, completing the entire registration process.
[0178] Step 5: Handling abnormal scenarios (taking the case where the SCQF value is lower than the connection threshold after the handover as an example).
[0179] If the beam B SCQF value collected after the handover is lower than the connection threshold, the terminal immediately sends the extended command AT+QPREREG=CANCEL, carrying the resource ID to request cancellation of pre-registration and release of resources.
[0180] Upon receiving the instruction, the network side reclaims the resource and updates the resource pool capacity. The terminal automatically switches to the regular registration process and performs registration according to the original MRS, ensuring that registration can still be completed even under poor channel quality.
[0181] First, this application constructs a collaborative triggering mechanism between BHP and SCQF to achieve precise initiation of CS domain pre-registration. Addressing the issues in related technologies where independent operation of BHP and SCQF leads to inaccurate pre-registration timing and easy registration interruption after handover, this application dynamically determines the pre-registration initiation node by real-time acquisition of SCQF data from the target beam and combining it with the handover prediction signal output by BHP. When the SCQF meets the registration adaptation threshold and handover is imminent, the pre-registration process is automatically triggered, fundamentally reducing the risk of registration interruption after beam handover. This is particularly important for ensuring communication continuity in critical scenarios such as emergency communications and maritime navigation, avoiding delays in critical information transmission due to registration interruptions.
[0182] Secondly, this application's embodiments design a pre-registration resource pool and handover & registration connection logic to resolve resource conflicts and excessive time consumption issues. Considering the signaling resource contention that easily occurs when multiple terminals switch simultaneously (such as ship formations or mountainous mobile terminal clusters), a dedicated pre-registration resource pool is built to reserve signaling resources for terminals to be switched in advance. At the same time, the handover and registration connection logic is optimized to simultaneously complete the verification, storage, and transmission of pre-registration information during beam switching, reducing the number of steps in the registration process after handover, thereby significantly shortening the registration time and meeting the actual low-latency requirements of Tiantong satellite communication.
[0183] Furthermore, this application's embodiments introduce a BHP prediction correction coefficient, combining it with HRD historical data to optimize prediction accuracy. Addressing the issue in related technologies where BHP relies solely on ephemeris and movement parameters, neglecting the reference value of historical data and resulting in significant prediction deviations, this application establishes a prediction deviation correction model based on historical handover duration data for different beam coverage areas and different terminal movement speeds in HRD (Historical Record Data). The correction coefficient dynamically adjusts the handover duration prediction result output by BHP, ensuring a precise match between the registration preparation timing and the actual handover process. This avoids pre-registration failures caused by premature preparation and also prevents delays that hinder rapid registration.
[0184] Furthermore, the embodiments of this application can achieve compatibility with existing Tiantong satellite terminal modules, reducing technical deployment costs. To avoid the high investment and promotional resistance caused by large-scale hardware modifications, the existing terminal's AT command set is extended. Without changing the terminal's hardware structure and core modules, new AT commands such as pre-registration start, pause, and status query are added, enabling the terminal to interact with the satellite system through the original interface to complete pre-registration control. This minimizes the difficulty of terminal-side modifications and user deployment costs, ensuring the rapid implementation and large-scale application of the technical solution.
[0185] Figure 4 This is a structural diagram of a network registration device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:
[0186] The first determining module 402 is used to determine the beam switching prediction state of the terminal device when the terminal device moves to the coverage boundary area of the first beam it is in.
[0187] The second determining module 404 is used to determine a coordination factor based on the predicted switching duration and the first channel quality of the second beam when the beam switching prediction state indicates that the terminal device will switch from the first beam to the second beam within the predicted switching duration. The coordination factor is used to quantify the matching relationship between the first channel quality and the beam switching urgency.
[0188] The execution module 406 is used to execute a pre-registration process when the coordination factor is less than a preset threshold. The pre-registration process is used to obtain the registration context corresponding to the second beam before beam switching.
[0189] The first registration module 408 is used to perform network registration using the registration context after the terminal device switches to the second beam.
[0190] It should be noted that, Figure 4 The network registration device shown is used to perform Figure 2 The network registration method shown, therefore Figure 2 The explanations and instructions regarding the online registration method also apply to... Figure 4 The network registration device shown will not be described in detail here.
[0191] Figure 5 This is a structural diagram of another network registration device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:
[0192] The receiving module 502 is used to receive a pre-registration request sent by the terminal device when the terminal device moves to the coverage boundary area of the first beam it is in and determines that it will switch from the first beam to the second beam within the predicted handover time. The pre-registration request is triggered when the coordination factor is less than a preset threshold. The coordination factor is determined based on the predicted handover time and the channel quality of the second beam. The coordination factor is used to quantify the matching relationship between the channel quality and the urgency of beam switching.
[0193] The response module 504 is used to respond to the pre-registration request and interact with the terminal device to complete the pre-registration process. The pre-registration process is used by the terminal device to obtain the registration context corresponding to the second beam before beam switching.
[0194] The second registration module 506 is used to perform network registration based on the registration context sent by the terminal device after the terminal device switches to the second beam.
[0195] It should be noted that, Figure 5 Another network registration device shown is used to perform Figure 3 The network registration method shown, therefore Figure 3 The explanations and instructions regarding the online registration method also apply to Figure 5 The network registration device is not described in detail here.
[0196] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the steps of implementing the network registration method in various embodiments of this application.
[0197] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the steps of the network registration method in various embodiments of this application by running the computer program.
[0198] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the network registration method in various embodiments of this application.
[0199] This application also provides a computer program that, when executed by a processor, implements the steps of the network registration method in various embodiments of this application.
[0200] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0201] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0202] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0203] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0204] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0205] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0206] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A network registration method characterized by comprising: include: When the terminal device moves to the coverage boundary area of the first beam it is in, the beam switching prediction state of the terminal device is determined; When the beam switching prediction state indicates that the terminal device will switch from the first beam to the second beam within the predicted switching duration, a coordination factor is determined based on the predicted switching duration and the first channel quality of the second beam, wherein the coordination factor is used to quantify the matching relationship between the first channel quality and the beam switching urgency; When the coordination factor is less than a preset threshold, a pre-registration process is executed, wherein the pre-registration process is used to obtain the registration context corresponding to the second beam before beam switching; After the terminal device switches to the second beam, it performs network registration using the registration context.
2. The method according to claim 1, characterized in that, The method further includes: Obtain the switching information from the first beam to the second beam from the historical data; Based on the switching information, a historical prediction deviation rate is determined, wherein the historical prediction deviation rate is used to quantify the degree of difference between the historical predicted switching duration and the historical actual switching duration. A correction coefficient is determined based on the historical prediction deviation rate, wherein the correction coefficient is used to adjust the duration of the pre-registration process; The predicted switching duration is corrected using the correction coefficient to obtain the corrected switching duration.
3. The method according to claim 1, characterized in that, When the collaboration factor is less than a preset threshold, a pre-registration process is executed, including: When the collaboration factor is less than or equal to a first preset threshold, the pre-registration process is executed immediately; When the collaboration factor is greater than the first preset threshold and not greater than the second preset threshold, the pre-registration process is executed after a preset delay period, wherein the first preset threshold is less than the second preset threshold.
4. The method according to claim 3, characterized in that, The method further includes: when the coordination factor is greater than the second preset threshold, refusing to execute the pre-registration process, and executing the original registration process of the second beam after the beam switching is completed.
5. The method according to claim 2, characterized in that, Perform the pre-registration process, including: A pre-registration resource request is initiated to the network side of the second beam, wherein the pre-registration resource request carries the identifier of the second beam and the corrected handover duration; Receive response information returned by the network side, wherein the response information includes an acknowledgment response and a rejection response; When the response information is the confirmation response, authentication and resource confirmation are completed by interacting with the network side based on the resource identifier in the confirmation response, and the registration context is obtained.
6. The method according to claim 1, characterized in that, After the terminal device switches to the second beam, network registration is performed using the registration context, including: After the terminal device switches to the second beam, the second channel quality of the second beam is obtained; When the second channel quality is greater than or equal to the connection threshold, network registration is performed using the registration context, wherein the connection threshold is used to determine whether the channel quality of the second beam is sufficient to support the completion of the pre-registration connection process.
7. The method according to claim 6, characterized in that, The method further includes: when the quality of the second channel is less than the connection threshold, releasing the pre-registration resources and initiating the original registration process of the second beam.
8. The method according to claim 1, characterized in that, The method further includes: determining pre-registration parameters based on the first channel quality of the second beam before performing the pre-registration process, wherein the pre-registration parameters include at least one of the following: pre-registration signaling transmission power level, pre-registration retry count, and pre-registration timeout.
9. The method according to claim 2, characterized in that, The correction coefficient is determined based on the historical prediction deviation rate, including: When the historical prediction deviation rate is less than or equal to the first deviation rate, the first coefficient is determined as the correction coefficient, wherein the first coefficient is used to extend the prediction switching time. When the historical prediction deviation rate is greater than the first deviation rate but not greater than the second deviation rate, the second coefficient is determined as the correction coefficient, wherein the second deviation rate is greater than the first deviation rate and the second coefficient is less than the first coefficient; When the historical prediction deviation rate is greater than the second deviation rate, a third coefficient is determined as the correction coefficient, wherein the third coefficient is less than the second coefficient, and the third coefficient is used to shorten the prediction switching time.
10. The method according to claim 2, characterized in that, The method further includes: determining a pre-registration validity period based on the modified switching duration, wherein the pre-registration validity period is used to determine the duration for which the registration context remains in a valid state after beam switching is completed.
11. The method according to claim 8, characterized in that, The method further includes: Determine the pre-registration success rate for different channel quality ranges based on historical data; A first channel quality interval is determined where the pre-registration success rate is less than the first success rate, and when the pre-registration process is triggered in the first channel quality interval, the corresponding pre-registration signaling transmission power level is increased; A second channel quality interval is determined where the pre-registration success rate is greater than the second success rate. When the pre-registration process is triggered in the second channel quality interval, the corresponding number of pre-registration retries is reduced, wherein the second success rate is greater than the first success rate.
12. A network registration method, characterized in that, include: When a terminal device moves to the coverage boundary area of the first beam it is in and determines that it will switch from the first beam to the second beam within the predicted handover time, a pre-registration request sent by the terminal device is received. The pre-registration request is triggered when the coordination factor is less than a preset threshold. The coordination factor is determined based on the predicted handover time and the channel quality of the second beam. The coordination factor is used to quantify the matching relationship between the channel quality and the urgency of beam switching. In response to the pre-registration request, the terminal device is interacted with to complete the pre-registration process, wherein the pre-registration process is used by the terminal device to obtain the registration context corresponding to the second beam before beam switching; After the terminal device switches to the second beam, network registration is performed based on the registration context sent by the terminal device.
13. The method according to claim 12, characterized in that, In response to the pre-registration request, the pre-registration process is completed by interacting with the terminal device, including: In response to the pre-registration request, the remaining capacity of the pre-registration resource pool is determined, wherein the basic capacity of the pre-registration resource pool is determined based on the number of historically switched terminals; When the remaining capacity is greater than the preset capacity, a confirmation response is returned to the terminal device, wherein the confirmation response includes a resource identifier allocated to the terminal device; Authentication and resource confirmation are completed by interacting with the terminal device based on the resource identifier.
14. The method according to claim 12, characterized in that, The method further includes: When multiple terminal devices to be registered simultaneously initiate pre-registration with the third beam, the target coordination factor corresponding to each of the multiple terminal devices to be registered is determined. The priority of the plurality of terminal devices to be registered is determined based on the target coordination factor. Based on the priority, pre-registration resources are allocated to the plurality of terminal devices to be registered. Among them, terminal devices to be registered that have not been allocated pre-registration resources enter the queuing queue according to the priority. The validity period of the queuing queue is determined based on the modified predicted switching time of the terminal devices to be registered.
15. A device for network registration, characterized in that, include: The first determining module is used to determine the beam switching prediction state of the terminal device when the terminal device moves to the coverage boundary area of the first beam it is in. The second determining module is used to determine a coordination factor based on the predicted switching duration and the first channel quality of the second beam when the beam switching prediction state indicates that the terminal device will switch from the first beam to the second beam within the predicted switching duration. The coordination factor is used to quantify the matching relationship between the first channel quality and the beam switching urgency. An execution module is used to execute a pre-registration process when the coordination factor is less than a preset threshold, wherein the pre-registration process is used to obtain the registration context corresponding to the second beam before beam switching; The first registration module is used to perform network registration using the registration context after the terminal device switches to the second beam.
16. A device for network registration, characterized in that, include: A receiving module is configured to receive a pre-registration request sent by a terminal device when the terminal device moves to the coverage boundary area of the first beam it is in and determines that it will switch from the first beam to the second beam within a predicted handover duration. The pre-registration request is triggered when the coordination factor is less than a preset threshold. The coordination factor is determined based on the predicted handover duration and the channel quality of the second beam. The coordination factor is used to quantify the matching relationship between the channel quality and the urgency of beam switching. A response module is used to respond to the pre-registration request and interact with the terminal device to complete the pre-registration process, wherein the pre-registration process is used by the terminal device to obtain the registration context corresponding to the second beam before beam switching; The second registration module is used to perform network registration based on the registration context sent by the terminal device after the terminal device switches to the second beam.
17. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the network registration method according to any one of claims 1 to 11, or to execute the network registration method according to any one of claims 12 to 14.