Apparatus and method for managing interface between base stations in wireless communication system
The method addresses the inefficiencies in managing inter-satellite links in non-terrestrial networks by integrating wireless link characteristics into XnAP procedures, ensuring efficient and reliable connectivity through status checks and link resets, thereby improving link management in regenerative satellite payloads.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- AJOU UNIV IND ACADEMIC COOP FOUND
- Filing Date
- 2025-10-28
- Publication Date
- 2026-05-07
AI Technical Summary
Existing XnAP procedures for managing inter-satellite links in non-terrestrial networks with regenerative satellite payloads are inadequate due to dynamic link changes and lack of provisions for checking connection status and removing links in wireless optical communication environments.
A method for dynamically managing inter-satellite interfaces by incorporating wireless link characteristics into XnAP procedures, using a non-contention-based RACH mechanism for initial link establishment, and implementing status check and link reset procedures to ensure efficient and reliable connectivity.
Enhances the reliability and efficiency of managing dynamic inter-satellite links in non-terrestrial networks by providing rapid connection setup and stable link management, reducing latency and signaling overhead.
Smart Images

Figure KR2025017255_07052026_PF_FP_ABST
Abstract
Description
Device and method for managing interfaces between base stations in a wireless communication system
[0001] The present disclosure relates to a wireless communication system, and in particular to an apparatus and method for managing an interface between base stations in a wireless communication system.
[0002]
[0003] With the advancement of mobile communication services, Non-Terrestrial Networks (NTNs), which are free from spatial constraints, are attracting attention, and low-orbit satellites, in particular, are expected to play a major role. Accordingly, 3GPP (3 rd The Generation Partnership Project is proceeding with standardization for non-terrestrial networks without spatial constraints to provide effective communication services.
[0004]
[0005] The present disclosure is intended to provide an apparatus and method for effectively managing interfaces between base stations in a wireless communication system.
[0006] The present disclosure is for managing interfaces between base stations based on status request messages.
[0007] The present disclosure is for managing interfaces between base stations based on a status check procedure.
[0008] The present disclosure is intended to remove an existing link based on a status check procedure.
[0009] The present disclosure is for establishing a new link based on a status check procedure.
[0010]
[0011] According to one aspect of the present disclosure, a method of operation of a first base station in a wireless communication system is disclosed. The method may include the steps of transmitting a synchronization signal to a second base station, receiving a response message for the synchronization signal from the second base station, transmitting an acknowledgment message for the response message to the second base station, transmitting a status request message to the second base station, and receiving a status response message from the second base station.
[0012] According to another aspect of the present disclosure, a first base station is disclosed in a wireless communication system. The first base station comprises a transceiver and a processor connected to the transceiver, and the processor can control to transmit a synchronization signal to a second base station, receive a response message for the synchronization signal from the second base station, transmit an acknowledgment message for the response message to the second base station, transmit a status request message to the second base station, transmit a status request message to the second base station, and receive a status response message from the second base station.
[0013] According to another aspect of the present disclosure, a method of operation of a second base station in a wireless communication system is disclosed. The method may include the steps of receiving a synchronization signal from a first base station, transmitting a response message for the synchronization signal to the first base station, receiving an acknowledgment message for the response message from the first base station, receiving a status request message from the first base station, and transmitting a status response message to the first base station.
[0014] According to another aspect of the present disclosure, a second base station is disclosed in a wireless communication system. The second base station includes a transceiver and a processor connected to the transceiver, and the processor can control receiving a synchronization signal from a first base station, transmitting a response message for the synchronization signal to the first base station, receiving an acknowledgment message for the response message from the first base station, receiving a status request message from the second base station, and transmitting a status response message to the second base station.
[0015]
[0016] According to embodiments of the present disclosure, an interface between base stations in a wireless communication system can be effectively managed.
[0017]
[0018] FIG. 1 illustrates an example of a network according to one embodiment of the present disclosure.
[0019] FIG. 2 illustrates another example of a network according to one embodiment of the present disclosure.
[0020] FIG. 3 illustrates the configuration of a device in a wireless communication system according to one embodiment of the present disclosure.
[0021] FIG. 4 illustrates an example of a transparent satellite-based network according to one embodiment of the present disclosure.
[0022] FIG. 5 illustrates an example of a regenerative satellite-based network according to one embodiment of the present disclosure.
[0023] FIG. 6 illustrates an example of a procedure for establishing an inter-satellite link (ISL) according to one embodiment of the present disclosure.
[0024] FIG. 7 illustrates an example of a state verification procedure according to one embodiment of the present disclosure.
[0025] FIG. 8 illustrates an example of a procedure for removing or resetting a link based on a state check procedure according to one embodiment of the present disclosure.
[0026] FIG. 9 illustrates an example of a procedure for resetting a link based on a state check procedure according to one embodiment of the present disclosure.
[0027] FIG. 10 illustrates an example of a procedure to remove a link based on a state check procedure according to one embodiment of the present disclosure.
[0028] FIG. 11 illustrates an example of a state checking procedure according to one embodiment of the present disclosure.
[0029] FIG. 12 illustrates an example of a procedure for removing or resetting a link based on a state check procedure according to one embodiment of the present disclosure.
[0030] FIG. 13 illustrates an example of a procedure for resetting a link based on a status check procedure according to one embodiment of the present disclosure.
[0031] FIG. 14 illustrates an example of a procedure to remove a link based on a state check procedure according to one embodiment of the present disclosure.
[0032] FIG. 15 illustrates an example of a status check procedure according to another embodiment of the present disclosure.
[0033] FIG. 16 illustrates an example of a procedure to remove a link based on a state check procedure according to another embodiment of the present disclosure.
[0034] FIG. 17 illustrates an example of a procedure for resetting a link at a third base station based on a status check procedure, according to another embodiment of the present disclosure.
[0035] FIG. 18 illustrates an example of a procedure for resetting a link based on a status check procedure according to another embodiment of the present disclosure.
[0036]
[0037] The terms used in these embodiments have been selected to be as widely used and general as possible, taking into account the functions within these embodiments; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, the applicant has arbitrarily selected terms, and in such cases, their meanings will be described in detail in the relevant sections. Therefore, the terms used in these embodiments should be defined not merely by their names, but based on their meanings and the content throughout these embodiments.
[0038] The embodiments are subject to various modifications and may take various forms; therefore, some embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the embodiments to the specific disclosed forms, and it should be understood that the embodiments include all modifications, equivalents, and substitutions that fall within the spirit and scope of the embodiments. The terms used herein are for the description of the embodiments only and are not intended to limit the embodiments.
[0039] Unless otherwise defined, the terms used in these embodiments have the same meaning as generally understood by those skilled in the art to which these embodiments pertain. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in these embodiments.
[0040]
[0041] Recently, Non-Terrestrial Networks (NTN) technology, which provides global communication services through NG-RAN (Next Generation-Radio Access Network) utilizing Low Earth Orbit (LEO) satellites as base stations, is being actively researched. In the case of existing transparent payloads, satellites can operate in the same way as the relay structure of existing ground base stations, including frequency filtering, conversion, and signal amplification. Therefore, satellites with a bentpipe structure necessarily require a connection structure with ground base stations. That is, for satellites with a bentpipe structure, inter-satellite connection is not essential, and for example, the Xn interface of the ground network can be used for message exchange between base stations. However, recently, link management through direct communication between satellites rather than the Xn interface is required. Accordingly, this disclosure proposes a method for managing inter-satellite links (ISL).
[0042]
[0043] FIG. 1 illustrates an example of a network according to one embodiment of the present disclosure.
[0044] Referring to FIG. 1, the network may include a non-terrestrial network and a terrestrial network (TN), and may include a terminal (110), satellites (120-1, 120-2), a gateway (130), and a base station. The terminal (110) is a user device equipped with hardware and software that receives cellular data from a satellite (120-1), and may be a mobile or fixed device. For example, the terminal (110) may include a mobile phone, a smartphone, a wearable device, or a UE (User Equipment). Furthermore, the terminal (110) is not limited to the examples described above, and may include any electronic device capable of cellular communication, such as a laptop or tablet PC. The terminal (110) is not limited to the examples described above. Although the network in FIG. 1 is depicted as including only a single terminal (110), this is merely an exemplary embodiment and is not limited thereto, and it is obvious that it may include multiple terminals (110).
[0045] Specifically, the terminal (110) can support communication protocols defined in 3GPP (3rd generation partnership project) standards (e.g., LTE communication protocol, LTE-A communication protocol, NR communication protocol, etc.). Multiple communication nodes (110 to 130) can support CDMA (code division multiple access) technology, WCDMA (wideband CDMA) technology, TDMA (time division multiple access) technology, FDMA (frequency division multiple access) technology, OFDM (orthogonal frequency division multiplexing) technology, Filtered OFDM technology, CP (cyclic prefix)-OFDM technology, DFT-s-OFDM (discrete Fourier transform-spread-OFDM) technology, OFDMA (orthogonal frequency division multiple access) technology, SC (single carrier)-FDMA technology, NOMA (non-orthogonal multiple access) technology, GFDM (generalized frequency division multiplexing) technology, FBMC (filter bank multi-carrier) technology, UFMC (universal filtered multi-carrier) technology, SDMA (space division multiple access) technology, etc.
[0046] Satellites (120-1, 120-2) fly in a fixed orbit and can provide a cell with coverage of a certain size by forming a beam toward the ground. In relation to the present disclosure, satellite (120-1) may refer to a serving satellite and satellite (120-2) may refer to a target satellite. Additionally, the serving satellite and the target satellite may be referred to as a serving cell and a target cell, respectively, and may be used interchangeably. Furthermore, in the present disclosure, satellites (120-1, 120-2) may be collectively referred to as non-ground cells. A gateway (130) provides the satellites (120-1, 120-2) with a link to connect to a network. A base station (140) may refer to a terrestrial base station or a wireless communication device fixed at a specific location and can provide a cell with coverage of a certain size. In connection with the present disclosure, satellites (120-1, 120-2) and base station (140) may be referred to as gNB (gNodeB) or cell. Additionally, in the present disclosure, the last cell to which the terminal (110) was previously connected may be mentioned, and said last cell may be referred to as last gNB, Last Serving gNB, source cell, etc.
[0047] The link between the terminal (110) and the satellite (120-1) is called a service link and may be based on NR standards defined by 3GPP. The link between the satellites (120-1, 120-2) and the gateway (130) is called a feeder link and may be based on a 3GPP or non-3GPP wireless interface. The link between satellites may be used mainly for regenerative satellites.
[0048] For transparent satellites based on an NR-RAN architecture, the satellite radio interfaces of the feeder link and service link may be NR-Uu. For transparent satellites, the satellite performs radio frequency filtering, frequency conversion, and amplification functions. For regenerative satellites, onboard functions are built into the satellite, and accordingly, the satellite can perform radio frequency filtering, frequency conversion, and amplification, as well as some or all of the base station functions such as switching and routing, coding and modulation, and decoding and demodulation.
[0049]
[0050] FIG. 2 illustrates another example of a network according to one embodiment of the present disclosure. FIG. 3 illustrates an example of an NTN providing non-terrestrial access to a UE (210) using an NTN payload (220) and an NTN gateway (230). Here, the UE (210) may be substantially the same configuration as the terminal (110) described in FIG. 1. Referring to FIG. 2, the link between the NTN payload (220) and the UE (210) is a service link and may be based on a Uu interface. The link between the NTN payload (220) and the NTN gateway (230) is a feeder link. The link between the NTN gateway (230) and the AMF / UPF (240) may be based on an NG interface. The NTN payload (220) can transparently forward wireless protocols received from the UE (210) to the NTN gateway (230) via the service link. Similarly, the NTN payload (220) can transparently forward wireless protocols received from the NTN gateway (230) via a feeder link to the UE (210).
[0051] To this end, the following connectivity may be supported by the NTN payload (220). A base station may service multiple NTN payloads. An NTN payload may be serviced by multiple base stations.
[0052] The NTN payload (220) can change the carrier frequency before retransmitting data on the service link. That is, the NTN payload (220) can use different carrier frequencies on the service link and the feed link. For the NTN, at least one of the following may be used as a network identifier: AMF name, NCGI (NR cell global identifier), CgNB ID (identifier), global gNB ID, TAI (tracking area identity), S-NSSAI (Single Network Slice Selection Assistance information), NSAG (Network Slice AS Group), NID (Network Identifier), CAG (Closed Access Group) ID, and local NG-RAN node ID (identifier). Additionally, a mapped cell ID may be used. Here, the tracking area may correspond to a fixed geographical area.
[0053] Non-geosynchronous orbits (NGSO) include a low Earth orbit at an altitude of about 300 km to 1500 km and a medium Earth orbit at an altitude of about 7000 km to 25000 km.
[0054] Service links can be classified into the following three types: earth-fixed, quasi-earth-fixed, and earth-moving. The earth-fixed type provides beam(s) that continuously cover the same geographical area at all times. For example, a satellite in a geosynchronous orbit (GSO) can provide an earth-fixed type service link. The quasi-earth-fixed type provides beam(s) that continuously cover the same geographical area for a limited period and beams that cover different geographical areas during different periods. For example, a satellite in a non-earth-synchronous orbit can provide a quasi-earth-fixed type service link using steerable beams. The earth-moving type provides beams where the coverage area slides across the Earth's surface. For example, a satellite with a non-Earth-synchronous orbit can provide an Earth-moving type service link using fixed or steerable beams.
[0055] By using a satellite with a non-Earth-synchronous orbit, the base station can provide quasi-Earth-fixed cell coverage or Earth-mobile cell coverage. By using a satellite with an Earth-synchronous orbit, the base station can provide Earth-fixed cell coverage. In the case of a non-Earth-synchronous orbit, a switch of the service link may be referred to a change of the serving satellite (120-1).
[0056]
[0057] FIG. 3 illustrates the configuration of a device in a wireless communication system according to one embodiment of the present disclosure. The device of FIG. 3 may be understood as a part of the structure of any one of the devices described with reference to FIG. 1, for example, a terminal (110), satellites (120-1, 120-2), a gateway (130), and a base station (140).
[0058] Referring to FIG. 3, the device may include a processor (310), a communication unit (320), and a memory (330).
[0059] The processor (310) can control the overall function and operation of the device. The processor (310) may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices.
[0060] The communication unit (320) is connected to the processor (310) to transmit and receive wireless signals. The communication unit (320) may include a baseband circuit for processing wireless signals. For example, the communication unit (320) may include a short-range communication unit, a mobile communication unit, and a broadcast reception unit. In one embodiment, the communication unit (320) may transmit and receive data to and from other devices, such as a base station, a satellite, etc.
[0061] Memory (330) is hardware that stores various data processed by the processor (310). For example, the memory (330) may store SIR values for the transmission target terminals of the transmitting terminals, information regarding transmission target terminal groups for each transmitting terminal, etc. Additionally, the memory (330) may store applications, drivers, etc. to be driven by the processor (310). The memory (330) may include RAM (random access memory) such as DRAM (dynamic random access memory) and SRAM (static random access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), CD-ROM, Blu-ray or other optical disc storage, HDD (hard disk drive), SSD (solid state drive), or flash memory.
[0062] The structure of FIG. 3 can be understood as at least part of a terminal, base station, satellite, or gateway. If the structure of FIG. 3 is part of a satellite, the satellite may include other hardware devices necessary for orbiting in addition to the components illustrated in FIG. 3.
[0063]
[0064] FIG. 4 illustrates an example of a transparent satellite-based network according to one embodiment of the present disclosure. Through FIG. 4, a communication method of a transparent satellite-based network is described.
[0065] Referring to FIG. 4, the terminal can be configured to communicate with a transparent satellite through a wireless interface, NR-Uu. Here, the transparent satellite has a transparent payload structure and can relay the received wireless signal to a ground station.
[0066] The transparent satellite is linked to the NTN gateway, and the NTN gateway can transmit NR Uu interface signals received from the transparent satellite to the terrestrial network. The NTN gateway is connected to a terrestrial base station, and the terrestrial base station can communicate with the 5G Core Network (5G CN) through the NG interface.
[0067] The 5G core network can be configured to receive data from ground base stations via the NG interface and to interact with an external data network via the N6 interface. Meanwhile, the transparent satellite and the NTN gateway can operate as part of a remote radio unit.
[0068]
[0069] FIG. 5 illustrates an example of a regenerative satellite-based network according to an embodiment of the present disclosure. A communication method of a regenerative satellite-based network is described through FIG. 4. Since 3GPP Release 19, standardization has been proceeding with the regenerative satellite payload as the main architecture, which is a structure in which base stations are mounted on satellites. Unlike conventional satellites that are merely relays, regenerative satellites operate in a structure in which they communicate with each other through links between satellites as they perform the role of base stations, and exchange data through Xn interfaces between base stations. The regenerative satellite-based network environment is described as the NG-RAN architecture structure of 3GPP TR 38.821, as shown in FIG. 5 below.
[0070] Referring to FIG. 5, the terminal can be configured to communicate with a regenerative satellite through a wireless interface, NR-Uu. Here, the regenerative satellite has a regenerative payload structure, and a base station is implemented to perform demodulation or coding processing on a signal received from the terminal.
[0071] Regeneration satellites can implement inter-satellite links through the Xn interface. In other words, regeneration satellites can perform inter-satellite message exchange and resource control via the Xn interface without passing through a separate terrestrial network. Additionally, regeneration satellites can be connected to NTN gateways via the Satellite Radio Interface (SRI).
[0072] The regenerative satellite can communicate directly with the 5G Core Network (5G CN) through the NG interface. The 5G Core Network can be configured to receive data from the regenerative satellite through the NG interface and to interact with an external data network through the N6 interface.
[0073]
[0074] When a network is constructed using regenerative satellite payloads, the Application Protocol (hereinafter XnAP) can be utilized via the Xn interface between satellites, just as in existing terrestrial networks. With the regenerative satellite payload structure currently being standardized in 3GPP Release 19, extending XnAP to suit non-terrestrial network environments is essential. Meanwhile, in non-terrestrial network environments where regenerative satellite payloads are applied, XnAP operates via a wireless optical network rather than a wired network; consequently, the following technical challenges exist for applying existing XnAP procedures.
[0075] Conventional XnAP is designed based on wired network connections between fixed ground base stations and is currently defined in the 3GPP TS 38.423 document. According to existing procedures, the process of establishing Xn interface connections is managed through Xn Setup and Xn Removal procedures, respectively. However, since satellites in a regenerative satellite payload environment move at high speeds, inter-satellite links—i.e., Xn interface connections—change dynamically, and link disconnections occur frequently. In such an environment, there are limitations to applying conventional XnAP procedures directly to a regenerative satellite payload environment. In particular, conventional standards do not define procedures for checking the connection status of dynamic wireless links in advance or for removing the corresponding link in the event of a disconnection. This implies that since inter-satellite links consist of wireless optical communication between satellites, unlike existing ground wired networks, the characteristics of wireless links must be reflected in XnAP as well.
[0076] In addition, in a non-terrestrial network environment, a user terminal needs to acquire system information (e.g., SIB19) regarding not only the serving satellite but also a number of adjacent surrounding satellites in order to perform a smooth handover. According to the prior art, the terminal receives a Master Information Block (MIB) via a Primary / Secondary Synchronization Signal (PSS / SSS) and can receive a System Information Block Type 1 (SIB1) via the MIB. SIB1 contains si-SchedulingInfo, through which the terminal can check scheduling information regarding whether other system information (Other System Information, OSI, e.g., SIB2 or higher) is broadcast. This information is the minimum information that the terminal can receive without performing a Random Access Channel (RACH) procedure.
[0077] Meanwhile, as defined in 3GPP TS 38.331, if a terminal fails to verify other necessary system information from si-SchedulingInfo, the terminal may transmit a SystemInfoRequest message to request On-Demand SI using the Common Control Channel (CCCH). However, the SystemInfoRequest message is transmitted only when the terminal is in the RRC_IDLE or RRC_INACTIVE state. This is because a terminal in the RRC_CONNECTED state is uplink synchronized only with the serving cell, and the RACH procedure must be performed for SystemInfoRequest. Therefore, a terminal in the RRC_CONNECTED state can request system information only from the serving satellite and cannot directly obtain system information from surrounding satellites where no RRC connection exists. If the terminal attempts to individually connect with surrounding satellites to request information, problems may arise that result in massive latency, signaling overhead, and resource waste.
[0078] Furthermore, in a satellite network environment, position and time information included in SIB19 can be utilized for distance-based handover and Timing Advance (TA) correction. However, when a terminal receives position information from multiple nearby satellites, including a serving satellite, such information may not have been measured at the same point in time, which can cause errors during handover determination. For example, under the condition condEventD2, a handover is performed based on the change in distance (referenceLocation) between the cell center and the terminal. However, if referenceLocation information measured at different points in time is used, errors may accumulate, leading to abnormal handovers. Additionally, if a terminal simultaneously receives time-synchronized system information from multiple satellites, there is a possibility of excessive signaling overhead.
[0079] Accordingly, the present disclosure proposes a method for dynamically managing inter-satellite interfaces to solve the aforementioned problems. Furthermore, the present disclosure proposes a method for stably managing the connectivity of Xn interfaces by incorporating the characteristics of Xn interfaces connected via wireless optical communication between satellites in a dynamic non-terrestrial network environment into existing XnAP procedures. In addition, the present disclosure aims to provide a method that enables a terminal in the RRC_CONNECTED state to efficiently acquire system information regarding nearby satellites.
[0080]
[0081] The present disclosure proposes a procedure that can verify the connectivity of an Xn interface in advance and reliably configure and unconfigure it by reflecting the dynamic characteristics of inter-satellite wireless links. Specifically, the present invention introduces a novel XnAP procedure for verifying Xn Status and aims to improve the conventional Xn configuration and Xn removal procedures defined in 3GPP TS 38.423. Through this, the present disclosure aims to improve the efficiency of managing dynamic inter-satellite links in non-terrestrial network environments.
[0082] The present disclosure includes an initial connection procedure for a wireless link between satellites, and is based on the premise that a stable physical L1 layer and data link L2 layer connection between two satellite base stations must precede the exchange of upper-layer XnAP messages (e.g., Xn Status Request). The present disclosure may utilize a non-contention-based RACH (Contention-Free Random Access, CFRA) model mechanism among RACHs of 5G NR for initial link establishment.
[0083] For example, two satellites are aware of each other's presence and orbital information in advance through a ground control station, and can predict when a link reset is necessary based on ephemeris information. Accordingly, the link setup proposed in this disclosure can be designed as a concept that guarantees rapid connection without collision by having the network allocate dedicated resources to a specific node, such as in contention-based RACH, rather than a form in which an unspecified number of terminals access it competitively. For example, Satellite B can pre-define dedicated physical resources (e.g., specific time, frequency, and unique preamble sequence) to be used by the other satellite A. Dedicated physical resources can be pre-configured in the ground network. Additionally, dedicated physical resources can be independently derived by both satellites through a deterministic algorithm based on input values such as the identifiers (IDs) of both satellites and GNSS (Global Navigation Satellite System) times. Consequently, this disclosure can provide the effect of improving the reliability and connection efficiency of the inter-satellite link by providing a dynamic Xn interface management procedure that considers wireless link characteristics in a non-ground network environment based on regenerated satellite payloads.
[0084]
[0085] FIG. 6 illustrates an example of a procedure for establishing an inter-satellite link (ISL) according to one embodiment of the present disclosure. The first base station (600) of FIG. 6 may be a non-ground cell that is a serving cell and a regeneration satellite. Additionally, the second base station (602) may be a target cell and a non-ground cell that is a regeneration satellite. Base stations mentioned in the following disclosure may be referred to as nodes and RAN nodes, etc.
[0086] Referring to FIG. 6, in step S601, the first base station (600) transmits a first message containing a synchronization signal to the second base station (602). The first base station (600) can predict and pre-compensate for propagation delay and Doppler shift with the second base station by using position and velocity information and pre-acquired ephemeral information of the second base station (602). Based on the pre-compensated propagation delay and Doppler shift, the first base station (600) can transmit a first message containing an inter-satellite link preamble (ISL-Preamble) which is a synchronization signal, using designated dedicated physical resources (e.g., specific time, frequency, unique preamble sequence). At this time, the dedicated physical resources may be pre-set by a ground control station or independently calculated by a deterministic algorithm that takes the identifiers and GNSS time information of both satellites as input.
[0087] In step S603, the second base station (602) transmits a second message containing a response message to the first base station (600). The second base station (602) waits for reception of the first message from the first base station (600) within a search window set based on ephemeral information and can detect a preamble from the first message. If the preamble is successfully detected, the second base station (602) can measure the actual reception time and the residual error between the frequency and the predicted value. The second base station (602) transmits a response message to the first base station (600) containing information for correcting the residual error (e.g., a fine timing advance (TA) command, fine frequency correction information, etc.) and initial link resource allocation information. The response message may be referred to as an ISL-Response.
[0088] In step S605, the first base station (600) transmits a third message containing a confirmation message to the second base station (602). The first base station (600) corrects the error based on information for correcting the residual error included in the second message and performs L1 synchronization. When L1 synchronization is completed, the first base station (600) generates a confirmation message confirming that L1 and L2 links have been established using allocated initial resources, and transmits a third message containing the confirmation message to the second base station (602). When the second base station (602) receives the third message, the physical link establishment of both base stations (600, 602) is completed, and a status check procedure for the upper layer, L3, can be initiated.
[0089]
[0090] FIG. 7 illustrates an example of a state verification procedure according to one embodiment of the present disclosure.
[0091] Referring to FIG. 7, in step S701, the first base station (700) transmits a status request message to the second base station (7002). The first base station (700) may transmit the status request message based on a predetermined period to check the link connection status with the second base station (702). For example, the first base station (700) uses a preset timer ( Based on ), a status request message can be transmitted to the second base station (702). That is, the first base station (700) can transmit the status request message again when the preset timer expires. Meanwhile, the first base station (700) transmits the status request message a preset number of times ( ...can be transmitted repeatedly. Specifically, if the first base station (700) does not receive a response to the transmission of the status request message, it can retransmit the status request message up to a maximum preset number of times. As a result, the first base station (700) can periodically check the link status between the two base stations (700, 702) by periodically transmitting the status request message to the second base station (702).
[0092] In step S703, the first base station (700) receives a status response message from the second base station (702). When the first base station (700) receives the status response message, it determines that the link with the second base station (702) is valid and maintains the existing interface settings.
[0093] That is, the first base station (700) can periodically check the connection status of the Xn interface through a status check procedure for dynamic link management at the upper layer XnAP level after the physical layer link is established. The first base station (700) can perform a link status check procedure for initial connection, connection reset, or Xn-C signaling through the Xn interface, and can trigger an Xn removal or setup procedure if necessary.
[0094]
[0095] A status request message is a control message transmitted from a serving satellite to a target satellite to verify the connection status of the Xn interface between satellites, and may include informational elements to determine the validity of the Xn interface connection. That is, the status request message may include mandatory and optional informational elements to check the connectivity of the inter-satellite link and to evaluate link latency and time synchronization accuracy. Table 1 below describes an example of the informational elements included in a status request message.
[0096]
[0097] IE / Group Name Presence Description Assigned Criticality Message Type Mandatory (Required) Specifies the message type Reject Global NG-RAN Node IDM Mandatory (Required) Base station identifier Reject > Source NG-RAN Node IDM Mandatory (Required) Global identifier of the source satellite (NG-RAN Node) sending the request Reject > Target NG-RAN Node IDM Mandatory (Required) Global identifier of the target satellite (NG-RAN Node) receiving the request Reject Request Timestamp Mandatory (Required) Message transmission time (UTC / GNSS) Ignore Request Sequence Number Mandatory (Required) Sequence number of the current status check request, used for retransmission management Ignore Status Check Cause Optional (Optional) Cause that triggered the status check (periodic check, quality degradation, etc.) Ignore CHOICE ISL Information Optional (Optional) Container containing ISL-related information Ignore > ISL Signal Quality Conditional (Conditional) Current transmission signal quality indicator of the ISL -> ISL RTT Information Conditional (Conditional) Expected RTT or propagation delay information of ISL measured by the source satellite -> Link Type Conditional (Conditional) Type of link (ISL, Terrestrial Xn link)
[0098] Specifically, the status request message may include information regarding a message type as an essential information element that identifies the status request message as a message requesting the status of the Xn interface. Additionally, the status request message may include identification information of the sending entity (e.g., Source NG-RAN Node ID) and identification information of the receiving target (e.g., Target NG-RAN Node ID). Furthermore, the status request message may include timestamp and sequence information used to evaluate link delay and time synchronization error. For example, the status request message may include a Request Timestamp containing the time of message transmission and a Request Sequence Number containing whether the status request message corresponds to a pre-set number of messages. Meanwhile, the status request message may include information regarding the link and trigger elements of the status check procedure as optional information elements. Specifically, the status request message may include a Status Check Cause including periodicity and quality degradation, which are causes triggering the status check procedure. Additionally, the status request message may include a group of information regarding the inter-satellite link (e.g., CHOICE ISL Information). For example, a link information group may include link information such as signal quality indicators indicating the status of the inter-satellite link (e.g., ISL Signal Quality), the estimated round-trip time of a message (e.g., ISL RTT Information), and the type of link to be checked (e.g., Link Type).
[0099]
[0100] In addition, message types according to the present disclosure may include the types presented in Tables 2 and 3 below.
[0101] 9.2.3 General IE definitions
[0102] 9.2.3.1 Message Type
[0103] The Message Type IE uniquely identifies the message being sent. It is mandatory for all messages.
[0104] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionProcedure CodeMINTEGER (0..255)Type of MessageMCHOICE (Initiating Message, Successful Outcome, Unsuccessful Outcome,…)
[0105] 9.2.2.3 Global NG-RAN Node ID (Source / Target NG-RAN Node ID)This IE is used to globally identify an NG-RAN node (see TS 38.300 [9]).
[0106] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCHOICE NG-RAN nodeM>gNB>>Global gNB IDM9.2.2.1
[0107] The message type is an essential component for identifying the type of message and can be included in all XnAP messages. For example, the message type may include a Procedure Code (an integer value in the range of 0 to 255) and a Type of Message (CHOICE) field. The Type of Message (CHOICE) field may define the procedure type of the message, such as Initiating Message, Successful Outcome, and Unsuccessful Outcome. Additionally, the Global NG-RAN Node ID (Source / Target NG-RAN Node ID) information element is information for globally identifying each base station on the Xn interface and may optionally include a Global gNB ID or a Global ng-eNB ID.
[0108]
[0109] A status response message is a control message transmitted by a target satellite in response to a status request message. Specifically, the status response message may include the Xn interface status and link information of the target satellite that received the request. The status response message may include the result of determining the connectivity of the link and may include mandatory and optional information elements. Table 4 below describes an example of the information elements included in a status response message.
[0110]
[0111] IE / Group Name Presence Description Assigned Criticality Message Type Mandatory (Required) Specifies the message type Reject Global NG-RAN Node IDM Mandatory (Required) Base station identifier Reject Source NG-RAN Node IDM Mandatory (Required) Global identifier of the source satellite (NG-RAN Node) sending the request Reject Target NG-RAN Node IDM Mandatory (Required) Global identifier of the target satellite (NG-RAN Node) receiving the request Reject Rx Sequence No. Mandatory (Required) Received Xn STATUS REQUEST message number Reject Reception Timestamp Mandatory (Required) Time the request message was received (UTC / GNSS) Ignore Response Timestamp Mandatory (Required) Time the response message was generated / transmitted (UTC / GNSS) Ignore Link Status Mandatory (Required) Link status of the Xn-C Interface (N / D) *Based on specific criteria Ignore CHOICE ISL InformationOptional (Optional) Container containing ISL-related information Ignore> ISL Signal QualityConditional (Conditional) Current transmission signal quality indicator of the ISL -> ISL RTT InformationConditional (Conditional) Estimated RTT or propagation delay information of the ISL measured by the source satellite -> Link TypeConditional (Conditional) Type of link (ISL, Terrestrial Xn link)-
[0112] Specifically, the status response message may include information regarding a message type that identifies the status response message as a response message to the status of the Xn interface, as an essential information element. Additionally, the status response message may include identification information regarding the sender of the status request message (e.g., Source NG-RAN Node ID) and identification information regarding the sender of the status response message (e.g., Target NG-RAN Node ID). Furthermore, the status response message may include a timestamp of when the status response message was transmitted (e.g., Response Timestamp) and a timestamp of when the status request message was received (e.g., Reception Timestamp). The source satellite may calculate the Round Trip Time (RTT) on the link based on the timestamps included in the status response message. Additionally, the status response message may include information that returns the sequence number of the status request message corresponding to the status response message. The said sequence number is a preset number of times ( It refers to xn of ). Additionally, the status response message may include the status of the Xn-C interface (e.g., Normal, Degraded). The status of the Xn-C interface may be determined by the target satellite based on link failure criteria indicators such as signal strength, satellite distance, and connection time. Furthermore, the status response message may include optional information corresponding to the optional information elements of the status request message. For example, the status response message may include a CHOICE ISL Information group containing signal quality indicators (e.g., ISL Signal Quality) and the estimated round-trip time of the message (e.g., ISL RTT Information). In addition, the status response message may include an Operation Hint containing information such as recommended actions for the source satellite (e.g., Setup Renewal Suggested). That is, the status response message can induce the source satellite to proactively respond to dynamic link status.
[0113]
[0114] FIG. 8 illustrates an example of a procedure for removing or resetting a link based on a state check procedure according to one embodiment of the present disclosure.
[0115] Referring to FIG. 8, in step S801, the first base station (800) transmits a status request message to the second base station (802). The first base station (800) may transmit the status request message based on a predetermined period to check the link connection status with the second base station (802). For example, the first base station (800) uses a preset timer ( Based on ), a status request message can be transmitted to the second base station (802). That is, the first base station (800) can transmit the status request message again when the preset timer expires. Meanwhile, the first base station (800) transmits the status request message a preset number of times ( It can be transmitted repeatedly up to ). Specifically, if the first base station (800) does not receive a response to the transmission of the status request message, it can retransmit the status request message up to a maximum preset number of times.
[0116] In step S803, the first base station (800) performs link removal. Specifically, the first base station (800) may determine that a failure has occurred in the inter-satellite link if it does not receive a response message to a status request message until a preset number of times expires. Accordingly, the first base station (800) may perform a link removal procedure to remove the Xn interface with the second base station (802).
[0117] In step S805, the first base station (800) may perform a link reset. For example, the first base station (800) may perform a link reset for the second base station (802). For another example, if a new third base station is identified, the first base station (800) may perform a link reset for the third base station.
[0118]
[0119] FIG. 9 illustrates an example of a procedure for resetting a link based on a state check procedure according to one embodiment of the present disclosure.
[0120] Referring to FIG. 9, in step S901, the first base station (900) transmits a status request message to the second base station (902). Specifically, the first base station (900) may transmit a status request message to the second base station (902) when the status check procedure with the previously linked base station fails or when the second base station (902) is newly detected. That is, if the status check procedure fails or a new base station is detected, the first base station (900) determines that a reset is required and may initiate a status check procedure with the new base station. The first base station (900) may transmit a status request message based on a predetermined period to check the link connection status with the second base station (902), just as it did with the existing base station. For example, the first base station (900) uses a preset timer ( Based on ), a status request message can be transmitted to the second base station (902). That is, the first base station (900) can transmit the status request message again when the preset timer expires. Meanwhile, the first base station (900) transmits the status request message a preset number of times ( ...can be transmitted repeatedly. Specifically, if the first base station (900) does not receive a response to the transmission of the status request message, it can retransmit the status request message up to a maximum preset number of times.
[0121] In step S903, the first base station (900) receives a status response message from the second base station (902). When the first base station (900) receives the status response message, it determines that the link with the second base station (902) is valid and establishes the link with the second base station (902). As another example, when the first base station (900) does not receive the status response message, it determines that the second base station (902) is invalid and does not establish the link.
[0122] In step S905, the first base station (900) transmits a link setup request message to the second base station (902). Specifically, the first base station (900) transmits a link setup request message including an Xn setup request (Xn SETUP REQUEST) to set up an Xn interface with the second base station (902), and can perform link setup.
[0123] In step S907, the first base station (900) receives a link setup response message from the second base station (902). For example, the first base station (900) can perform link setup via a satellite link by receiving a link setup response message containing an Xn setup response (Xn SETUP RESPONSE) from the second base station (902). For another example, if the first base station (900) receives a link setup response message containing an Xn setup failure (Xn SETUP FAILURE) from the second base station (902), it is determined that the link setup has failed.
[0124]
[0125] FIG. 10 illustrates an example of a procedure for removing a link based on a status check procedure according to one embodiment of the present disclosure. Specifically, FIG. 10 illustrates a link removal procedure that can be performed in parallel with link establishment to actively respond to dynamic topology changes between base stations.
[0126] Referring to FIG. 10, in step S1001, the first base station (1000) transmits a status request message to the second base station (1002). The first base station (1000) may transmit the status request message based on a predetermined period to check the link connection status with the second base station (1002). For example, the first base station (1000) uses a preset timer ( Based on ), a status request message can be transmitted to the second base station (1002). That is, the first base station (1000) can transmit the status request message again when a preset timer expires. Meanwhile, the first base station (1000) transmits the status request message a preset number of times ( ...can be transmitted repeatedly. Specifically, if the first base station (1000) does not receive a response to the transmission of the status request message, it can retransmit the status request message up to a maximum preset number of times. As a result, the first base station (1000) can periodically check the link status between the two base stations (1000, 1002) by periodically transmitting the status request message to the second base station (1002). Below, for the purpose of explaining the link removal procedure, the above-described status check procedure will be explained under the premise that it has failed.
[0127] In step S1003, the first base station (1000) transmits a link removal request message to the second base station (1002). For example, if the first base station (1000) does not receive a status response message from the second base station (1002), it determines that the status verification procedure has failed and transmits a link removal request message. For another example, if the first base station (1000) receives a status response message from the second base station (1002) but a degradation of the link's functionality is identified based on the status response message, it may transmit a link removal request message to the second base station (1002).
[0128] A link removal request message may include a threshold for determining the functionality of the link. For example, the threshold may include indicators capable of determining the functionality of the inter-satellite link, such as angular velocity, distance between satellites, and signal quality. It should be noted that the thresholds included in this disclosure are not limited to the examples described above.
[0129] In step S1005, the first base station (1000) receives a link removal response message from the second base station (1002). Specifically, the second base station (1002) may transmit a link removal response message based on a link removal request message. According to an embodiment, the second base station (1002) may determine link function degradation based on the link removal request message. For example, the second base station (1002) may perform a status check by comparing a threshold included in the link removal request message with a link function calculated by the second base station (1002) itself. Here, the link function may be referred to as the Xn link benefit value. If the link function calculated by the second base station (1002) is below the threshold, the second base station (1002) may determine that link function degradation has occurred. If link function degradation is identified, the second base station (1002) may transmit a link removal response message. On the other hand, if the link function calculated by the second base station (1002) exceeds a threshold, it determines that it is necessary to maintain the link and can transmit a link removal failure message to the first base station (1000). The link removal failure message may include grounds for maintaining the link and information rejecting the link removal.
[0130]
[0131] FIG. 11 illustrates an example of a status check procedure according to one embodiment of the present disclosure. The operating entity of FIG. 11 is described as a device, but according to the embodiment, it may be a serving satellite. The serving satellite may be referred to as a first base station.
[0132] Referring to FIG. 11, in step S1101, the device performs a link establishment procedure between the second base station and the physical layer satellite. The second base station is the target satellite, and the device can perform the link establishment procedure with the second base station based on a synchronization signal. For example, the device can transmit a synchronization signal to the second base station. The synchronization signal can be pre-compensated using the device's position and velocity information and the ephemeral information of the second base station obtained in advance. Based on the pre-compensated propagation delay and Doppler shift, the device can transmit an Inter-Satellite Link Preamble (ISL-Preamble), which is the synchronization signal, to the second base station using designated dedicated physical resources (e.g., specific time, frequency, unique preamble sequence). Based on the detection of the preamble by the second base station, the device can perform L1 synchronization by receiving a response message from the second base station and transmitting an acknowledgment message. When L1 synchronization is completed, the device generates an acknowledgment message confirming that L1 and L2 links have been established using allocated initial resources, and transmits a third message containing the acknowledgment message to the second base station. When the second base station receives the third message, the physical link setup is completed, and the status check procedure of the upper layer, L3, can be initiated.
[0133] In step S1103, the device transmits a status request message to the second base station. The device may transmit the status request message based on a predetermined period to check the link connection status with the second base station. For example, the device uses a set timer ( Based on ), a status request message can be transmitted to the second base station. That is, the device can retransmit the status request message when a preset timer expires. Meanwhile, the device transmits the status request message a preset number of times ( It can be transmitted repeatedly up to ). Specifically, if the device does not receive a response to the transmission of a status request message, it can retransmit the status request message up to a maximum preset number of times.
[0134] In step S1105, the device receives a status response message from the second base station. When the status response message is received, the device determines that the link with the second base station is valid and can maintain the existing interface settings.
[0135]
[0136] FIG. 12 illustrates an example of a procedure for removing or resetting a link based on a status check procedure according to one embodiment of the present disclosure. The operating entity of FIG. 12 is described as a device, but according to the embodiment, it may be a serving satellite. The serving satellite may be referred to as a first base station.
[0137] Referring to FIG. 12, in step S1201, the device transmits a status request message to the second base station. The device may transmit the status request message based on a predetermined period to check the link connection status with the second base station. For example, the device uses a preset timer ( Based on ), a status request message can be transmitted to the second base station. That is, the device can retransmit the status request message when a preset timer expires. Meanwhile, the device transmits the status request message a preset number of times ( It can be transmitted repeatedly up to ). Specifically, if the device does not receive a response to the transmission of a status request message, it can retransmit the status request message up to a maximum preset number of times.
[0138] In step S1203, the device determines whether it has received a status response message from the second base station. For example, the device may determine that it has not received a status response message if it does not receive a response message to a status request message until a preset number of times expires. For another example, the device may determine that it has not received a status response message even if it receives a status response message after exceeding a preset timer. That is, the device may determine that a failure has occurred in the inter-satellite link based on the reception of the status response message. If the device receives a status response message from the second base station, it maintains the inter-satellite link.
[0139] In step S1205, the device may remove the link with the second base station. Specifically, if the device does not receive a status response message from the second base station, it may perform a procedure to remove the link with the second base station.
[0140] In step S1207, the device may perform a link reset with the third base station. Specifically, if a new third base station is identified, the device may perform a link reset for the third base station. As another example, the device may perform a link reset for the second base station.
[0141]
[0142] FIG. 13 illustrates an example of a procedure for resetting a link based on a status check procedure according to one embodiment of the present disclosure. The operating entity of FIG. 13 is described as a device, but according to the embodiment, it may be a serving satellite. The serving satellite may be referred to as a first base station.
[0143] In step S1301, the device identifies a failure to receive a status response message from a second base station or identifies a third base station. For example, the device may determine that a status response message was not received if it does not receive a response message to a status request message until a preset number of times expires. For another example, the device may determine that a status response message was not received even if it receives a status response message after exceeding a preset timer. The device may identify a third base station. The identification of the third base station may be performed based on at least one of the device's location, link status, measurement information of a surrounding base station, or configuration information received from a network.
[0144] In step S1303, the device transmits a status request message to the third base station. Specifically, the device transmits a status request message to the third base station based on the identification of the third base station. The device may transmit the status request message based on a predetermined period to check the link connection status with the third base station. As an example, the device uses a preset timer ( Based on ), a status request message can be transmitted to a third base station. In addition, the device transmits the status request message a preset number of times ( It can be repeatedly transmitted to the third base station up to ).
[0145] In step S1305, the device determines whether it has received a status response message from the third base station. For example, the device may determine that it has not received a status response message if it does not receive a response message to a status request message until a preset number of times expires. For another example, the device may determine that it has not received a status response message even if it receives a status response message after exceeding a preset timer. If the device does not receive a status response message from the third base station, it does not perform the link establishment procedure.
[0146] In step S1307, the device transmits a link setup request message to the third base station. Specifically, the device may transmit a link setup request message to the third base station when it receives a status response message from the third base station. Specifically, the device may transmit a link setup request message including an Xn setup request to establish an Xn interface with the third base station and perform a link setup.
[0147] In step S1309, the device receives a link establishment response message from the third base station. For example, the device can perform link establishment via the inter-satellite link by receiving a link establishment response message from the third base station that includes an Xn establishment response. For another example, if the device receives a link establishment response message from the third base station that includes an Xn establishment failure, it determines that the link establishment has failed.
[0148]
[0149] FIG. 14 illustrates an example of a procedure for removing a link based on a status check procedure according to one embodiment of the present disclosure. The operating entity of FIG. 14 is described as a device, but according to the embodiment, it may be a serving satellite. The serving satellite may be referred to as a first base station.
[0150] Referring to FIG. 14, in step S1401, the device identifies a failure to receive a status response message from the second base station or a degradation of the link function with the second base station. For example, the device may determine that a status response message was not received if it does not receive a response message to a status request message until a preset number of times expires. For another example, the device may determine that a status response message was not received even if it receives a status response message after exceeding a preset timer. Additionally, if a status response message is received, the device may identify a degradation of the link function based on the status response message.
[0151] In step S1403, the device transmits a link removal request message to the second base station. For example, if the device does not receive a status response message from the second base station, it determines that the status check procedure has failed and transmits the link removal request message. For another example, if the device receives a status response message from the second base station but a deterioration in the link's functionality is identified based on the status response message, the device may transmit the link removal request message to the second base station.
[0152] In step S1405, the device receives a link removal response message from the second base station. Specifically, according to an embodiment, the device may receive the link removal response message based on the second base station's determination of link function degradation. If link function degradation is identified, the device may receive the link removal response message. Conversely, if link function degradation is not identified and it is determined that the link needs to be maintained, the device may receive a link removal failure message. The link removal failure message may include grounds for maintaining the link and information regarding the refusal of link removal.
[0153]
[0154] FIG. 15 illustrates an example of a status check procedure according to another embodiment of the present disclosure. The operating entity of FIG. 15 is described as a device, but according to the embodiment, it may be a target satellite. The serving satellite may be referred to as a second base station.
[0155] Referring to FIG. 15, in step S1501, the device performs a link establishment procedure between the first base station and the physical layer satellite. The device may perform the link establishment procedure with the first base station based on a synchronization signal. For example, the device may receive a synchronization signal from the first base station. The synchronization signal may be pre-compensated using the device's position and velocity information and the ephemeral information of the first base station obtained in advance. Based on the pre-compensated propagation delay and Doppler shift, the device may receive an inter-satellite link preamble (ISL-Preamble), which is the synchronization signal, through designated dedicated physical resources (e.g., a specific time, frequency, and unique preamble sequence). The device may perform L1 synchronization by detecting the preamble, transmitting a response message to the first base station, and receiving an acknowledgment message. When L1 synchronization is completed, the device may receive an acknowledgment message confirming that L1 and L2 links have been established using allocated initial resources, and may receive a third message containing the acknowledgment message. When the device receives the third message, the physical link establishment is completed, and a status check procedure for the upper layer, L3, may be initiated.
[0156] In step S1503, the device receives a status request message from the first base station. The device may receive the status request message based on a predetermined period to check the link connection status with the first base station. For example, the device has a set timer ( Based on ), the device can receive status request messages. In addition, the device receives status request messages a preset number of times ( Can receive up to ).
[0157] In step S1505, the device transmits a status response message to the first base station. Specifically, the device may transmit a status response message based on the reception of a status request message.
[0158]
[0159] FIG. 16 illustrates an example of a procedure to remove a link based on a status check procedure according to another embodiment of the present disclosure. The operating entity of FIG. 16 is described as a device, but according to the embodiment, it may be a target satellite. The target satellite may be referred to as a second base station.
[0160] Referring to FIG. 16, in step S1601, the device determines that there has been a failure to transmit a status response message to the first base station. For example, the device may determine that it has failed to transmit a status response message if it does not receive a status request message until a preset number of times expires or a preset timer is exceeded. That is, from the perspective of the device, if a status request message is not received, it may determine that the transmission of the status response message has failed. Meanwhile, if the device receives a status request message from the first base station, it determines that the transmission of the status response message has been successful and maintains the inter-satellite link.
[0161] In step S1603, the device removes the link with the first base station. Specifically, if the device does not receive a status request message from the first base station, it determines that the transmission of a status response message has failed and may perform a procedure to remove the link with the first base station.
[0162]
[0163] FIG. 17 illustrates an example of a procedure for resetting a link at a third base station based on a status check procedure, according to another embodiment of the present disclosure. The operating entity of FIG. 17 is described as a device, but according to the embodiment, it may be a target satellite. The target satellite may be referred to as a third base station.
[0164] Referring to FIG. 17, in step S1701, the device receives a status request message from the first base station. Specifically, the device may receive the status request message based on a predetermined period to check the link connection status with the first base station. As an example, the device uses a set timer ( Based on ), the device can receive status request messages. In addition, the device receives status request messages a preset number of times ( Can receive up to ).
[0165] In step S1703, the device transmits a status response message to the first base station. The device may transmit a status response message based on the reception of a status request message.
[0166] In step S1705, the device receives a link setup request message from the first base station. Specifically, the device receives a link setup request message including an Xn setup request to set up an Xn interface with the first base station, and can perform a link setup.
[0167] In step S1707, the device transmits a link establishment response message to the first base station. For example, the device may perform link establishment via a satellite link by transmitting a link establishment response message containing an Xn establishment response to the first base station. For another example, if link performance degradation is identified, the device may transmit a link establishment response message containing an Xn establishment failure to the first base station.
[0168]
[0169] FIG. 18 illustrates an example of a procedure for resetting a link based on a status check procedure according to another embodiment of the present disclosure. The operating entity of FIG. 18 is described as a device, but according to the embodiment, it may be a target satellite. The target satellite may be referred to as a second base station.
[0170] Referring to FIG. 18, in step S1801, the device identifies a failure to transmit a status response message to the first base station or a degradation of the link function with the second base station. For example, the device may determine that it failed to transmit a status response message if it does not receive a status request message until a preset number of times expires or a preset timer is exceeded. That is, from the perspective of the device, if a status request message is not received, it may determine that the transmission of the status response message has failed. As another example, the device may have received a status request message but may independently identify a degradation of the link function with the first base station. In this case, the device may transmit a status response message to the first base station that includes information indicating that a degradation of the link function has been identified.
[0171] In step S1803, the device receives a link removal request message from the first base station. The link removal request message may include a threshold for determining the function of the link. For example, the threshold may include indicators that can determine the function of the inter-satellite link, such as angular velocity, inter-satellite distance, and signal quality.
[0172] In step S1805, the device can determine whether the link function exceeds a threshold. For example, the device can perform a status check by comparing the threshold included in the link removal request message with the link function calculated by the device itself. If the link function calculated by the device itself is below the threshold, the device can determine that a degradation of the link function has occurred.
[0173] In step S1807, if a link function degradation is identified, the device may transmit a link removal response message to the first base station.
[0174] In step S1809, if the device determines that no link function degradation has occurred, it transmits a link removal failure message to the first base station. Specifically, if the link function calculated by the device exceeds a threshold, the device determines that it is necessary to maintain the link and transmits a link removal failure message to the first base station. The link removal failure message may include grounds for maintaining the link and information rejecting the link removal.
[0175]
[0176] Meanwhile, those skilled in the art related to the present embodiment will understand that it may be implemented in modified forms without departing from the essential characteristics of the above description. Therefore, the disclosed methods should be considered in an illustrative rather than a restrictive sense. The scope of the present disclosure is defined by the claims, not by the foregoing description, and all variations within the scope of equivalence should be interpreted as being included in the present disclosure.
[0177]
[0178] The present disclosure relates to a wireless communication system, and in particular, can be used in a device for managing an interface between base stations in a wireless communication system.
Claims
1. In a method of operating a first base station in a wireless communication system, A step of transmitting a synchronization signal to a second base station; A step of receiving a response message for the synchronization signal from the second base station; A step of transmitting a confirmation message for the response message to the second base station; The step of transmitting a status request message to the second base station; and A method comprising the step of receiving a status response message from the second base station.
2. In Paragraph 1, The step of transmitting the above status request message is, A method comprising the step of transmitting the above status request message based on a preset timer.
3. In Paragraph 1, The step of transmitting the above status request message is, A method comprising the step of transmitting the above status request message based on a preset number of times.
4. In Paragraph 1, The step of receiving the above status response message is, If the reception of the above status response message fails, the step of removing the link with the second base station; and A method comprising the step of resetting the link with a third base station.
5. In Paragraph 4, The step of resetting the link with the third base station is, A step of transmitting the status request message to the third base station based on the identification of the third base station; and A method comprising the step of transmitting a link establishment request message to the third base station.
6. In Paragraph 4, The step of removing the link with the second base station is, A method comprising the step of transmitting a link removal request message to the second base station based on the identification of a degradation of the link function with the second base station.
7. In Paragraph 1, The above status response message is, A method comprising at least one of a time stamp for transmitting the status response message and information for returning the sequence number of the status request message corresponding to the status response message.
8. In a first base station of a wireless communication system, Transmitter / receiver; and It includes a processor connected to the above-mentioned transmitter and receiver, The above processor is, Transmit a synchronization signal to the second base station, and Receive a response message for the synchronization signal from the second base station, Transmit a confirmation message for the response message to the second base station, and Transmit a status request message to the above-mentioned second base station, and A first base station that controls receiving a status response message from the second base station.
9. In a method of operating a second base station in a wireless communication system, A step of receiving a synchronization signal from a first base station; A step of transmitting a response message for the synchronization signal to the first base station; A step of receiving a confirmation message for the response message from the first base station; A step of receiving a status request message from the first base station; and A method comprising the step of transmitting a status response message to the first base station.
10. In Paragraph 1, The step of receiving the above status request message is, A method comprising the step of receiving the above status request message based on a preset timer.
11. In Paragraph 1, The step of receiving the above status request message is, A method comprising the step of receiving the above status request message based on a preset number of times.
12. In Paragraph 1, The step of transmitting the above status response message is, A method comprising the step of removing the link with the first base station when the transmission of the above status response message fails.
13. In Paragraph 12, The step of removing the link with the first base station is, A method comprising the step of receiving a link removal request message to the first base station based on the identification of a degradation of the link function with the first base station.
14. In Paragraph 1, The above status response message is, A method comprising at least one of a time stamp for transmitting the status response message and information for returning the sequence number of the status request message corresponding to the status response message.
15. In a second base station of a wireless communication system, Transmitter / receiver; and It includes a processor connected to the above-mentioned transmitter and receiver, The above processor is, Receive a synchronization signal from the first base station, Transmitting a response message for the synchronization signal to the first base station, Receive a confirmation message for the response message from the first base station, and Receive a status request message from the second base station, and A second base station that controls the transmission of a status response message to the second base station.
Citation Information
Patent Citations
Distributed routing method and device for satellite network and storage medium
CN114158106A
Methods for performing handover and Apparatuses thereof
KR1020170114258A
Discarding data corresponding to a conditional handover
US20210176671A1