Communication method, device, and system in non-terrestrial network

Abstract

An NTN communication system based on O-RAN according to an embodiment of the present disclosure may comprise: a first satellite equipped with a first function based on the O-RAN; a second satellite equipped with a second function based on the O-RAN; and an NTN gateway connected to the second satellite through a satellite radio interface (SRI), wherein the first satellite and the second satellite may communicate on the basis of an ISL, and the first satellite and the second satellite may be included in one group and travel in formation so as to maintain a predetermined distance.

Description

Communication method and device and system in a non-terrestrial network

[0001] The present disclosure relates to communication technology in a non-terrestrial network (NTN), and more particularly, to communication technology based on an open RAN (open radio access network) in a non-terrestrial network.

[0002] 3GPP (3rd Generation Partnership Project) performs standardization in wireless communication systems rd The Third Generation Partnership Project (3GPP) has been developing standards for long-term evolution (LTE) systems, new radio (NR)-based standards, and 5G Advanced. 3GPP has also recently begun discussions on 6G technology.

[0003] In 3GPP wireless communication systems, standardization is underway for both terrestrial networks (TNs) and non-terrestrial networks (NTNs). Current NTN standards define two architectures: transparent satellite-based NTN architectures and regenerative satellite-based NTN architectures.

[0004] Meanwhile, the Open RAN (O-RAN) Alliance is developing O-RAN standards consisting of an O-RAN central unit (O-CU), an O-RAN distributed unit (O-DU), an O-RAN radio unit (O-RU), a non-real-time RAN intelligent controller (RIC), and a near-real-time RIC. The O-RAN standards define technical specifications that enable compatibility between equipment from various vendors, enable efficient use of resources through a centralized RAN (C-RAN) architecture, and significantly reduce the cost of building mobile communication networks.

[0005] Currently, wireless communication standardization organizations such as 3GPP are actively developing RANs based on the Open Radio Access Network (O-RAN) standard for TN. Furthermore, the NTN technology being discussed within wireless communication standardization organizations is being developed by extending TN communication technology to satellites. Therefore, NTN must also be developed based on the O-RAN standard to ensure interoperability with TN. However, O-RAN-based NTN technology currently lacks any. Therefore, O-RAN-based NTN technology is in demand.

[0006] The purpose of the present disclosure to address the above-mentioned needs is to provide an O-RAN based NTN communication method and device.

[0007] According to one embodiment of the disclosure for achieving the above-described purpose, an open RAN (O-RAN)-based non-terrestrial network (NTN) communication system may include a first satellite equipped with a first function based on the O-RAN; a second satellite equipped with a second function based on the O-RAN; and an NTN gateway connected to the second satellite via a satellite radio interface (SRI).

[0008] The first satellite and the second satellite communicate based on an inter-satellite link (ISL), and the first satellite and the second satellite can fly in formation to maintain a certain distance while being included in one group.

[0009] The first function may be an O-RAN radio unit (O-RU) function, the second function may be an O-RAN distributed unit (O-DU) function, a fronthaul interface between the first satellite and the second satellite may be based on the ISL, an O-RAN central unit (O-RAN control unit (O-CU)) may be located on the ground connected to the NTN gateway, and the O-DU and the O-CU connected to the NTN gateway may be wirelessly connected with an F1 interface, and the F1 interface may support one of an F1 interface resume or an F1 interface reset operation.

[0010] The method may further include: a non-real time RAN intelligent controller (RIC) connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); a near real time RIC connected to the NTN gateway and performing radio resource management for the O-DU function and the O-CU function in near real time using the machine learning model received from the non-real time RIC; and a service management and orchestration (SMO) connected to the NTN gateway and managing each separated function of the O-RAN.

[0011] The second satellite may further include a local xApp that enables near real-time control directly from the second satellite when a radio resource related event for the second function occurs, and an extended E2 interface or a first control interface may be used between the second satellite and the near real-time RIC, and the extended E2 interface or the first control interface may transmit one or a combination of a control policy, channel prediction data, weather prediction data, or a machine learning model required for satellite communication control.

[0012] The local xApp of the second satellite may control in near real time one or a combination of channel information updates for multiple-input multiple-output (MIMO) or beamforming, handover optimization, wireless link monitoring, wireless resource management, mobility management, load balancing, slicing policy updates, traffic steering, interference management, or security operations on the second satellite.

[0013] The first function may be an O-RAN radio unit (O-RU) function, and the second function may be an O-RAN distributed unit (O-DU) function and an O-RAN central unit (O-RAN control unit, O-CU).

[0014] The fronthaul interface between the first function and the second function may be based on the ISL.

[0015] The interface between the NTN gateway and the second satellite may use an NG interface via the SRI, and the NG interface may support either an NG interface resume operation or an NG interface reset operation.

[0016] A non-real time RAN intelligent controller (RIC) connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and a service management and orchestration (SMO) connected to the NTN gateway and managing each separated function of the O-RAN may be further included.

[0017] The second satellite may further include a real-time RIC that performs real-time radio resource management for the O-DU function and the O-CU function using the machine learning model received from the non-real-time RIC.

[0018] The first function may be an O-RAN radio unit (O-RU) function and an O-RAN distributed unit (O-DU) function, and the second function may be an O-RAN central unit (O-RAN control unit, O-CU).

[0019] The fronthaul interface between the first function and the second function may be based on the ISL.

[0020] A non-real time RAN intelligent controller (RIC) connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and a service management and orchestration (SMO) connected to the NTN gateway and managing each separated function of the O-RAN may be further included.

[0021] The second satellite may further include a real-time RIC that performs real-time radio resource management for the O-CU function and the O-DU function using the machine learning model received from the non-real-time RIC.

[0022] According to one embodiment of the disclosure for achieving the above-described purpose, an open RAN (O-RAN)-based non-terrestrial network (NTN) communication system may include a first satellite group including two or more satellites; a second satellite group including two or more satellites; and an NTN gateway connected to at least one satellite among the satellites belonging to the first satellite group or the satellites belonging to the second satellite group via a satellite radio interface (SRI).

[0023] The satellites included in each of the first satellite group and the second satellite group may include one or more first satellites including a first function and a second satellite including a second function, and the first satellite and the second satellite may communicate based on an inter-satellite link (ISL), and the satellites within the first satellite group may fly in formation to maintain a constant distance from each other, and the satellites within the second satellite group may fly in formation to maintain a constant distance from each other.

[0024] The first function may be an O-RAN radio unit (O-RU) function, and the second function may be an O-RAN distributed unit (O-DU) function.

[0025] Satellite A equipped with the O-DU function within the first satellite group and satellite B equipped with the O-DU function within the second satellite group fly in the same orbital plane so that the connection between the two satellite groups can be continuously maintained.

[0026] The first function may be an O-RAN radio unit (O-RU) function, and the second function may be an O-RAN distributed unit (O-DU) function and an O-RAN central unit (O-RAN control unit, O-CU).

[0027] A non-real time RAN intelligent controller (RIC) connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and a service management and orchestration (SMO) connected to the NTN gateway and managing each separated function of the O-RAN may be further included.

[0028] The second satellite may further include a real-time RIC that performs real-time radio resource management for the first function and the second function using the machine learning model received from the non-real-time RIC, and when the NTN gateway does not exist within the communication range of the second satellite having the second function belonging to the second satellite group, the second satellite having the second function belonging to the second satellite group may connect to the SMO through the second satellite having the second function of the first satellite group and the NTN gateway connected to the second satellite.

[0029] According to one embodiment of the present disclosure, a method for performing O-RAN-based communication in a mobile communication environment supporting a non-terrestrial network (NTN) in a 5G Advanced, 6G, or later communication system can be provided. By applying an O-RAN function partitioning method, the complexity of a satellite can be reduced. If a master (or leader) satellite among multiple satellites constituting a satellite cluster (or satellite group) is also equipped with an O-RU function, NTN coverage can be expanded. Satellites belonging to a satellite cluster can cooperate with each other through formation flight and can communicate based on free space optics (FSO), which has the advantage of meeting LLS-based capacity requirements.

[0030] Figure 1 is a conceptual diagram illustrating one embodiment of a communication system.

[0031] Figure 2 is a block diagram illustrating one embodiment of a communication node constituting a communication system.

[0032] FIG. 3 is a block diagram illustrating a first embodiment of entities constituting a non-terrestrial network.

[0033] FIG. 4a is a conceptual diagram illustrating a first embodiment of a transparent satellite-based NG-RAN architecture that is currently being standardized in 3GPP.

[0034] Figure 4b is a conceptual diagram illustrating an embodiment of NG-RAN in which all base stations in NTN are included in satellites.

[0035] Figure 4c is a conceptual diagram illustrating an embodiment of an NG-RAN in which a satellite in an NTN includes a gNB-DU and a gNB-CU base station on the ground.

[0036] FIG. 5 is a block diagram illustrating a first embodiment of a lower layer split (LLS)-based base station.

[0037] Figure 6 is a conceptual diagram of the O-RAN architecture defined by the O-RAN Alliance.

[0038] FIG. 7a is a conceptual diagram of an open LAN-based system in an NTN having a transparent satellite according to one embodiment of the present disclosure.

[0039] FIG. 7b is a conceptual diagram including the configuration of RIC and SMO of O-RAN in NTN having transparent satellite according to one embodiment of the present disclosure.

[0040] FIG. 8a is a conceptual diagram of a case where O-RAN is applied to NTN using both upper layer partitioning and lower layer partitioning according to the first embodiment of the present disclosure.

[0041] FIG. 8b is a conceptual diagram including the configuration of RIC and SMO in an O-RAN architecture in which both upper layer partitioning and lower layer partitioning are used in NTN according to the first embodiment of the present disclosure.

[0042] FIG. 9a is a conceptual diagram of a case where functions are divided into an O-CU / O-DU-equipped satellite and an O-RU-equipped satellite in NTN according to the second embodiment of the present disclosure.

[0043] FIG. 9b is a conceptual diagram illustrating the configuration of an NTN gateway and an RIC and SMO of an O-RAN connected to a satellite in an NTN according to a second embodiment of the present disclosure.

[0044] FIG. 9c is a conceptual diagram of a case where functions are divided into O-CU / O-DU-equipped satellites and O-RU-equipped satellites in an NTN according to a second embodiment of the present disclosure, and a user plane function as part of a core network is added.

[0045] Figure 10a is a conceptual diagram of a case where satellites are functionally divided according to a third embodiment that is a mixture of the first and second embodiments in NTN.

[0046] FIG. 10b is a conceptual diagram illustrating the configuration of an NTN gateway and an RIC and SMO of an O-RAN connected to a satellite in an NTN according to a third embodiment of the present disclosure.

[0047] FIG. 10c is a conceptual diagram of a third embodiment in which the first and second embodiments are combined in an NTN, with satellites having their functions divided and a user plane function as part of the core network added.

[0048] FIG. 11a is a conceptual diagram of a case where only the upper layer division of O-RAN is used in NTN according to the fourth embodiment of the present disclosure.

[0049] FIG. 11b is a conceptual diagram illustrating the configuration of an NTN gateway and an O-RAN RIC and SMO when only the upper layer division of an O-RAN is used in an NTN according to the fourth embodiment of the present disclosure.

[0050] FIG. 11c is a conceptual diagram of a case where only the upper layer division of O-RAN is used in NTN according to the fourth embodiment of the present disclosure and user plane functions as part of the core network are added to O-CUs.

[0051] FIG. 12a is a conceptual diagram of a case in which upper layer division of O-RAN is applied in NTN according to the fifth embodiment of the present disclosure and a satellite group without an O-CU-equipped satellite is present.

[0052] FIG. 12b is a conceptual diagram illustrating the configuration of an NTN gateway and an O-RAN RIC and an SMO when an upper layer partition of an O-RAN is applied in an NTN according to a fifth embodiment of the present disclosure and there is a satellite group without an O-CU-equipped satellite.

[0053] FIG. 12c is a conceptual diagram of a case where, according to the fifth embodiment of the present disclosure, upper layer division of O-RAN is applied in NTN, and a UFP, which is part of a CN, is added to an O-CU-equipped satellite when there is a satellite group without an O-CU-equipped satellite and a satellite group with an O-CU-equipped satellite.

[0054] Figure 13a is a conceptual diagram illustrating a fronthaul connection method via an ISL link in NTN.

[0055] Figure 13b is a conceptual diagram of a case where a circular cluster is formed using formation flight based on a circular orbit projected from NTN.

[0056] Figure 13c is a conceptual diagram of a case where a linear cluster is formed using track-based formation flight in NTN.

[0057] Figure 14a is a conceptual diagram according to a first embodiment for configuring a satellite cluster.

[0058] FIG. 14b is a conceptual diagram illustrating a case in which satellites according to a first embodiment of a satellite cluster are formed and the satellites communicate with UEs.

[0059] Figure 15a is a conceptual diagram according to a second embodiment for configuring a satellite cluster.

[0060] FIG. 15b is a conceptual diagram illustrating a second embodiment of satellites forming a satellite cluster and a case in which the satellites communicate with UEs.

[0061] Figure 15c is a conceptual diagram illustrating a case in which a UPF is mounted on a master satellite among satellites forming a satellite cluster according to a second embodiment.

[0062] Figure 16a is a conceptual diagram according to a third embodiment for configuring a satellite cluster.

[0063] FIG. 16b is a conceptual diagram illustrating a case in which satellites and the satellites communicate with UEs according to a third embodiment of a satellite cluster.

[0064] Figure 16c is a conceptual diagram illustrating a case in which a UPF is mounted on a master satellite among satellites forming a satellite cluster according to a third embodiment.

[0065] This disclosure may be subject to various modifications and various embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the disclosure to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the disclosure.

[0066] While terms such as "first" and "second" may be used to describe various components, these components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a "second component," and similarly, a second component could also be referred to as a "first component." The term "and / or" includes a combination of multiple related items described herein or any of multiple related items described herein.

[0067] In embodiments of the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.” Furthermore, in embodiments of the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.”

[0068] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0069] The terminology used in this disclosure is only used to describe specific embodiments and is not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this disclosure, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0070] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this disclosure pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0071] Hereinafter, preferred embodiments of the present disclosure will be described in more detail with reference to the attached drawings. In order to facilitate an overall understanding in describing the present disclosure, identical reference numerals are used for identical components in the drawings, and redundant descriptions of identical components are omitted.

[0072] A communication network to which embodiments according to the present disclosure are applied will be described. The communication system may be a non-terrestrial network (NTN), a 4th Generation (4G) communication network (e.g., a long-term evolution (LTE) communication network), a 5th Generation (5G) communication network (e.g., a new radio (NR) communication network), a 6th Generation (6G) communication network, etc. The 4G communication network, the 5G communication network, and the 6G communication network may be classified as terrestrial networks (TN) networks.

[0073] The non-terrestrial network may operate based on LTE technology, NR technology, and / or 6G technology. The non-terrestrial network may support communication in frequency bands above 6 GHz as well as below 6 GHz. 4G communication networks may support communication in frequency bands below 6 GHz. 5G communication networks may support communication in frequency bands above 6 GHz as well as below 6 GHz. The communication networks to which embodiments according to the present disclosure are applied are not limited to those described below, and the embodiments according to the present disclosure may be applied to various communication networks. Here, the term "communication network" may be used interchangeably with the term "communication system."

[0074] Figure 1 is a conceptual diagram illustrating a first embodiment of a non-terrestrial network.

[0075] Referring to FIG. 1, the non-terrestrial network may include a satellite (110), a communication node (120), a gateway (130), a data network (140), etc. The non-terrestrial network illustrated in FIG. 1 may be a transparent payload-based non-terrestrial network. The satellite (110) may be a LEO (low earth orbit, altitude 300 to 1,500 km) satellite, a MEO (medium earth orbit, altitude 7,000 to 25,000 km) satellite, a GEO (geostationary earth orbit, altitude approximately 35,786 km) satellite, a HEO (high elliptical orbit) satellite, or a UAS (unmanned aircraft system) platform. The UAS platform may include a HAPS (high altitude platform station).

[0076] The communication node (120) may include a communication node located on the ground (e.g., a user equipment (UE), a terminal) and a communication node located off the ground (e.g., an airplane, a drone). A service link may be established between the satellite (110) and the communication node (120), and the service link may be a radio link. The satellite (110) may provide a communication service to the communication node (120) using one or more beams. The shape of the reception range (footprint) of the beam of the satellite (110) may be elliptical.

[0077] The communication node (120) can perform communication (e.g., downlink communication, uplink communication) with the satellite (110) using LTE technology, NR technology, and / or 6G technology. Communication between the satellite (110) and the communication node (120) can be performed using an NR-Uu interface. When DC (dual connectivity) is supported, the communication node (120) can be connected to not only the satellite (110) but also other base stations (e.g., base stations supporting LTE and / or NR functions), and can perform DC operations based on technologies defined in LTE, NR, and / or 6G standards.

[0078] The gateway (130) may be located on the ground, and a feeder link may be established between the satellite (110) and the gateway (130). The feeder link may be a wireless link. The gateway (130) may be referred to as a "non-terrestrial network (NTN) gateway." Communication between the satellite (110) and the gateway (130) may be performed based on a NR-Uu interface or a satellite radio interface (SRI). The gateway (130) may be connected to a data network (140). A "core network" may exist between the gateway (130) and the data network (140). In this case, the gateway (130) may be connected to the core network, and the core network may be connected to the data network (140). The core network may support NR technology. For example, the core network may include an access and mobility management function (AMF), a user plane function (UPF), a session management function (SMF), etc. Communication between the gateway (130) and the core network may be performed based on the NG-C / U interface.

[0079] Alternatively, a base station and a core network may exist between the gateway (130) and the data network (140). In this case, the gateway (130) may be connected to the base station, the base station may be connected to the core network, and the core network may be connected to the data network (140). The base station and the core network may support NR technology and / or 6G technology. Communication between the gateway (130) and the base station may be performed based on an NR-Uu interface and / or a 6G interface, and communication between the base station and the core network (e.g., AMF, UPF, SMF) may be performed based on an NG-C / U interface and / or a 6G interface.

[0080] Figure 2 is a conceptual diagram illustrating a second embodiment of a non-terrestrial network.

[0081] Referring to FIG. 2, the non-terrestrial network may include satellite #1 (211), satellite #2 (212), a communication node (220), a gateway (230), a data network (240), etc. The non-terrestrial network illustrated in FIG. 2 may be a regenerative payload-based non-terrestrial network. For example, each of satellites #1-2 (211, 212) may perform a regenerative operation (e.g., a demodulation operation, a decoding operation, a re-encoding operation, a re-modulation operation, and / or a filtering operation) on a payload received from another entity constituting the non-terrestrial network (e.g., a communication node (220), a gateway (230)) and transmit the regenerated payload.

[0082] Each of satellites #1-2 (211, 212) may be a LEO satellite, MEO satellite, GEO satellite, HEO satellite, or UAS platform. The UAS platform may include HAPS. Satellite #1 (211) may be connected to satellite #2 (212), and an inter-satellite link (ISL) may be established between satellite #1 (211) and satellite #2 (212). The ISL may operate in a radio frequency (RF) frequency or an optical band. The ISL may be configured optionally. The communication node (220) may include a communication node located on the ground (e.g., a UE, terminal) and a communication node located off the ground (e.g., an airplane, a drone). A service link (e.g., a wireless link) may be established between satellite #1 (211) and the communication node (220). Satellite #1 (211) can provide communication services to a communication node (220) using one or more beams.

[0083] The communication node (220) can perform communication (e.g., downlink communication, uplink communication) with satellite #1 (211) using LTE technology and / or NR technology. Communication between satellite #1 (211) and the communication node (220) can be performed using an NR-Uu interface. If DC is supported, the communication node (220) can be connected to not only satellite #1 (211) but also other base stations (e.g., base stations supporting LTE and / or NR functions), and can perform DC operations based on technologies defined in the LTE and / or NR standards.

[0084] The gateway (230) may be located on the ground, and a feeder link may be established between satellite #1 (211) and the gateway (230), and a feeder link may be established between satellite #2 (212) and the gateway (230). The feeder link may be a wireless link. If an ISL is not established between satellite #1 (211) and satellite #2 (212), a feeder link between satellite #1 (211) and the gateway (230) may be established mandatorily.

[0085] Communication between each of satellites #1-2 (211, 2122) and the gateway (230) may be performed based on the NR-Uu interface or SRI. The gateway (230) may be connected to a data network (240). A "core network" may exist between the gateway (230) and the data network (240). In this case, the gateway (230) may be connected to the core network, and the core network may be connected to the data network (240). The core network may support NR technology. For example, the core network may include AMF, UPF, SMF, etc. Communication between the gateway (230) and the core network may be performed based on the NG-C / U interface.

[0086] Alternatively, a base station and a core network may exist between the gateway (230) and the data network (240). In this case, the gateway (230) may be connected to the base station, the base station may be connected to the core network, and the core network may be connected to the data network (240). The base station and the core network may support NR technology. Communication between the gateway (230) and the base station may be performed based on the NR-Uu interface, and communication between the base station and the core network (e.g., AMF, UPF, SMF) may be performed based on the NG-C / U interface.

[0087] Meanwhile, entities (e.g., satellites, communication nodes, gateways, etc.) constituting the non-terrestrial network illustrated in FIGS. 1 and 2 can be configured as follows.

[0088] FIG. 3 is a block diagram illustrating a first embodiment of entities constituting a non-terrestrial network.

[0089] Referring to FIG. 3, an entity (300) may include at least one processor (310), a memory (320), and a transmission / reception device (330) that is connected to a network and performs communication. In addition, the entity (300) may further include an input interface device (340), an output interface device (350), a storage device (360), etc. Each component included in the entity (300) may be connected by a bus (370) and communicate with each other.

[0090] However, each component included in the entity (300) may be connected through an individual interface or individual bus centered around the processor (310), rather than a common bus (370). For example, the processor (310) may be connected to at least one of a memory (320), a transmission / reception device (330), an input interface device (340), an output interface device (350), and a storage device (360) through a dedicated interface.

[0091] The processor (310) can execute program commands stored in at least one of the memory (320) and the storage device (360). The processor (310) may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor in which methods according to embodiments of the present disclosure are performed. Each of the memory (320) and the storage device (360) may be configured with at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory (320) may be configured with at least one of a read-only memory (ROM) and a random access memory (RAM).

[0092] Meanwhile, in non-terrestrial networks, scenarios can be defined as shown in Table 1 below.

[0093] NTN shown in Fig. 1 NTNGEO shown in Fig. 2 Scenario A Scenario BLEO (steerable beam) Scenario C1 Scenario D1 LEO (beam moving with satellite) Scenario C2 Scenario D2

[0094] In the non-terrestrial network illustrated in FIG. 1, if the satellite (110) is a GEO satellite (e.g., a GEO satellite supporting a transparent function), this may be referred to as “Scenario A.” In the non-terrestrial network illustrated in FIG. 2, if the satellites #1-2 (211, 212) are GEO satellites (e.g., a GEO supporting a regenerative function), this may be referred to as “Scenario B.”

[0095] In the non-terrestrial network illustrated in FIG. 1, if the satellite (110) is a LEO satellite having steerable beams, this may be referred to as "Scenario C1." In the non-terrestrial network illustrated in FIG. 1, if the satellite (110) is a LEO satellite having beams move with the satellite, this may be referred to as "Scenario C2." In the non-terrestrial network illustrated in FIG. 2, if satellites #1-2 (211, 212) are LEO satellites having steerable beams, this may be referred to as "Scenario D1." In the non-terrestrial network illustrated in FIG. 2, if satellites #1-2 (211, 212) are LEO satellites having beams move with the satellite, this may be referred to as "Scenario D2." Parameters for the scenarios defined in Table 1 may be defined as shown in Table 2 below.

[0096] Scenario A and B Scenario C and D Altitude 35,786 km 600 km 1,200 km Spectrum (service link) < 6 GHz (e.g. 2 GHz) > 6 GHz (e.g. DL 200 GHz, UL 30 GHz) Maximum channel bandwidth capability (service link) 30 MHz for band < 6 GHz 1 GHz for band > 6 GHz Maximum distance between satellite and communication node (e.g., UE) at minimum elevation angle 40,581 km 1,932 km (600 km altitude) 3,131 km (1,200 km altitude) Maximum round trip delay (RTD) (propagation delay only) Scenario A: 541.46 ms (service and feeder links) Scenario B: 270.73 ms (service link only) Scenario C: (Transparent payload: service and feeder links) - 5.77 ms (600 km) Scenario D: (Regenerated payload: only service link) - 12.89ms (600km altitude) - 20.89ms (1200km altitude) Maximum delay variation within a beam 16ms 4.44ms (600km altitude) 6.44ms (1200km altitude) Maximum differential delay within a cell 10.3ms 3.12ms (600km altitude) 3.18ms (1200km altitude) Service link NR defined in 3GPP Feeder link Radio interface defined in 3GPP or non-3GPP

[0097] Additionally, in the scenarios defined in Table 1, the delay constraint can be defined as shown in Table 3 below.

[0098] Scenario A Scenario B Scenario C Scenario D Satellite altitude 35,786 km 600 km Maximum RTD on the air interface between the base station and the UE 541.75 ms (worst case) 270.57 ms 28.41 ms 12.88 ms Minimum RTD on the air interface between the base station and the UE 477.14 ms 238.57 ms 8 ms 4 ms

[0099] Meanwhile, 3GPP has been standardizing 5G NR-based NTN since 2017.

[0100] The 3GPP NTN architecture can be broadly divided into two configurations. First, the 3GPP NTN architecture can have an NTN structure of a transparent satellite-based NG-RAN architecture. Second, the 3GPP NTN architecture can have an NG-RAN architecture equipped with regenerative satellites based on base station-distributed units (gNB-DUs) or full base stations (gNBs).

[0101] The transparent satellite-based NG-RAN architecture may have a similar form to that illustrated in Figure 1 above. A more detailed configuration will be examined with reference to the attached drawings.

[0102] FIG. 4a is a conceptual diagram illustrating a first embodiment of a transparent satellite-based NG-RAN architecture that is currently being standardized in 3GPP.

[0103] Referring to FIG. 4A, the transparent satellite-based NG-RAN architecture may include a user equipment (UE) (401), an NG-RAN (410), a core network (420), and a data network (430). In addition, the NG-RAN (410) may include a transparent satellite (412), an NTN gateway (413), and a base station (414). The base station (414) may be configured to connect the NTN gateway (413) and the core network (420). Here, the core network (420) may be, for example, a core network of a 5G NR system.

[0104] The transparent satellite (412) only functions as a radio frequency (RF) amplifier and can perform frequency conversion. In other words, the transparent satellite (412) can function as an analog radio repeater. The NTN gateway (413) can provide a function for forwarding signals of the NR-Uu interface of 3GPP. Therefore, the transparent satellite (412) can forward signals and / or data transmitted using the NR-Uu radio interface in the feeder link and the service link. In other words, both the service link and the feeder link can use the NR-Uu interface. Therefore, the transparent satellite (412) and the NTN gateway (413) can be viewed as a remote radio unit (RRU) (411) for the 5G NR base station (gNB) (414) from a logical perspective.

[0105] Each of the links from the base station (414) to the UE (401) may use the NR Uu interface, as illustrated in FIG. 4A. Additionally, the NG protocol may be used between the base station (414) and the core network (420), and the N6 interface may be used between the core network (420) and the data network (430).

[0106] Meanwhile, standardization of the NTN architecture for regenerative satellites is underway starting in 2024. In an NTN architecture with regenerative satellites, the satellite payload can regenerate signals received from the ground and transmit them to the UE. An NTN architecture with regenerative satellites can fall into one of the two scenarios below.

[0107] First, the entire gNB may be located on a satellite. Second, the gNB may be divided into a central unit (CU) and a distributed unit (DU), with the gNB's CU (gNB-CU) located on the ground and the gNB's DU (gNB-DU) located on a regenerative satellite. NTN structures with regenerative satellites are further described with reference to the attached drawings.

[0108] Figure 4b is a conceptual diagram illustrating an embodiment of NG-RAN in which all base stations in NTN are included in satellites.

[0109] Referring to FIG. 4b, it may include UEs (401a, 401b), NG-RAN (440), core networks (420a, 420b), and data networks (430a, 430b). In addition, the NG-RAN (410) may include regenerative satellites (441a, 441b) and NTN gateways (442a, 442b). Unlike FIG. 4a, in FIG. 4b, the NTN gateways (442a, 442b) may be directly connected to the core network (420a, 420b). As another example, although not shown in FIG. 4b, each of the NTN gateways (442a, 442b) may be connected through base stations (not shown in FIG. 4b) for connection between the corresponding gateways (442a, 442b) and the core network (420a, 420b). Here, the core networks (420a, 420b) may be, for example, core networks of a 5G NR system, may be the same core network, or may be different core networks.

[0110] Data networks (430a, 430b) may be the same data network. The reason data networks (430a, 430b) are illustrated differently in the example of FIG. 4b is to illustrate that UEs (401a, 401b) are connected via different satellites. Core networks (420a, 420b) may also be understood as a single core network or as different communication service providers.

[0111] In the embodiment of FIG. 4b, the regenerative satellites (441a, 441b) may perform the functions of a full gNB. In other words, each of the satellites (441a, 441b) may perform all operations of the gNB. The service link between the regenerative satellites (441a, 441b) and the UEs (401a, 401b) may use the NR-Uu interface.

[0112] Communication (443a, 443b) between regenerative satellites (441a, 441b) and NTN gateways (442a, 442b) may use the NG (over NG) protocol via the Satellite Radio Interface (SRI). The SRI may be a transport link between the NTN gateways (442a, 442b) and the regenerative satellites (441a, 441b). In other words, the service link may use the NR-Uu interface, and the feeder link may use the NG protocol via the SRI. The feeder link between the NTN gateways (442a, 442b) and the regenerative satellites (441a, 441b) may transport the NG protocol via the SRI.

[0113] An inter-satellite link (ISL) (445) may be used between the regenerative satellites (441a, 441b). The ISL (445) may be a transport link between the satellites (441a, 441b), and a radio interface or an optical interface (e.g., laser, etc.) may be used for the ISL (445). In a structure in which the entire base station is included in the satellite, the Xn interface used when communication between base stations (e.g., gNBs) such as handover of a UE is required may be used for the ISL (445). In other words, signals and / or data may be transported between satellites (e.g., gNBs) using the ISL (445).

[0114] Each of the NTN gateways (442a, 442b) illustrated in Fig. 4b is a Transport Network Layer (TNL) node and can use a transport protocol.

[0115] Figure 4c is a conceptual diagram illustrating an embodiment of an NG-RAN in which a satellite in an NTN includes a gNB-DU and a gNB-CU base station on the ground.

[0116] Referring to FIG. 4C, it may include a UE (401), an NG-RAN (450), a core network (420), and a data network (430). In addition, the NG-RAN (450) may include a regenerative satellite (451), an NTN gateway (452), and a base station (454). The regenerative satellite (451) may include a gNB-DU, and the base station (454) may be configured with a gNB-CU. In addition, the base station (454) may connect the NTN gateway (452) and the core network (420). Here, the core network (420) may be, for example, a core network of a 5G NR system and / or a core network of a 6G system.

[0117] The service link between the regenerated satellite (451) and the UE (401) may use the NR-Uu interface as described above. Additionally, the feeder link between the regenerated satellite (451) and the NTN gateway (452) may use the F1 over SRI protocol. The F1 protocol may be a protocol used between the gNB-CU and the gNB-DU. In the feeder link between the regenerated satellite (451) and the NTN gateway (452), the SRI may transport the F1 protocol.

[0118] Although only one satellite is illustrated in the example of FIG. 4c, satellite payloads may be transmitted between two or more satellites via ISL, as previously described in FIG. 2 . In this case, both satellites may be equipped with a DU (performing the DU function). Satellites performing the DU function may communicate using ISL. All two or more satellites equipped with a DU may be connected to a single gNB-CU (454) illustrated in FIG. 4c . The NTN gateway (452) is a TNL node and may utilize a transport protocol.

[0119] The satellites in the NTN illustrated in FIGS. 4A through 4C described above are described. The satellites may be any of LEO satellites, MEO satellites, GEO satellites, or HEO satellites, as described in FIGS. 1 and 2 . As another example, the satellites may include aerial vehicles of UAS platforms including HAPS. Accordingly, the satellites described in this disclosure may include not only the various high-altitude satellites exemplified above, but also HASPS.

[0120] Next, Open RAN (O-RAN) is explained.

[0121] The centralized RAN (C-RAN) architecture used in one of the current wireless communication standards, 4G (e.g., LTE and / or LTE-A specified by the 3GPP standards organization), can be configured based on the functional partitioning option 8 that divides the physical layer (PHY) and RF, and in the C-RAN architecture, a fronthaul interface based on the Common Public Radio Interface (CPRI) is widely used between the PHY and RF. Compared to 4G technology, 5G technology has significantly improved data transmission rates due to support for wider bandwidth, millimeter waves (mmWave), and massive multiple-input multiple-output (Massive MIMO). In order to provide 5G services using the existing C-RAN architecture based on functional partitioning option 8 in 5G technology, transmission rates of hundreds of Gbps are required on the CPRI-based fronthaul interface.

[0122] When utilizing 5G networks, a RAN architecture based on a higher-level functional partitioning option, rather than the existing functional partitioning option 8, should be considered to mitigate the high data rate requirements for fronthaul interfaces required for 5G services. Furthermore, the Common Radio Access Protocol (CPRI) standard used in 4G networks includes numerous vendor-specific options, leading to interoperability issues between vendors. Therefore, an open fronthaul technology is needed to address these issues.

[0123] To meet these requirements, 3GPP has been discussing various functional split options (functional split options 1 to 8), and the O-RAN Alliance is developing a new open fronthaul interface standard based on option 7-2x, one of the intra-PHY functional split options.

[0124] 3GPP has been discussing various functional partitioning options to alleviate the high data rate requirements for 5G fronthaul interfaces, ranging from the highest partitioning option, Functional Partition Option 1, to the lowest partitioning option, Option 8, which is used in the RAN architecture based on the CPRI interface used in 4G networks.

[0125] In 3GPP, each of the functional partitioning options can be categorized according to the partitioning between specific layers or within specific layers.

[0126] Functional partitioning option 1 may be partitioning between the radio resource control (RRC) layer and the packet data convergence protocol (PDCP) layer. Functional partitioning option 2 may be partitioning between the PDCP layer and a high-radio link control (High-RLC) layer (i.e., partitioning between PDCP and RLC). Functional partitioning option 3 may be partitioning within the RLC layer. More specifically, functional partitioning option 3 may be partitioning between High-RLC and Low-RLC (intra-RLC partitioning). Functional partitioning option 4 may be partitioning between Low-RLC and a high medium access control (High-MAC) layer. In other words, functional partitioning option 4 may be partitioning between the RLC layer and the MAC layer. Functional partitioning option 5 may be partitioning within the MAC layer. More specifically, functional partitioning option 5 may be partitioning between High-MAC and Low-MAC (intra-MAC partitioning). Functional partitioning option 6 can be partitioning between the Low-MAC and the high-physical layer (High-PHY) (i.e., partitioning between the MAC layer and the PHY layer). Functional partitioning option 7 can be partitioning within the physical layer. More specifically, functional partitioning option 7 can be partitioning between the High-PHY and Low-PHY (i.e., intra-PHY partitioning). Finally, functional partitioning option 8 can be partitioning between the Low-PHY and RF (i.e., partitioning between the PHY and RF).

[0127] Among the functional partitioning options described above, partitioning the upper layers can alleviate bandwidth requirements for the fronthaul. However, partitioning the upper layers increases overhead for control signaling, increases the implementation complexity of the radio unit (RU), increases the processing burden on the RU, and requires upgrading not only the distributed unit (DU) but also the RU when adding or expanding new features. These issues make functional expansion relatively difficult with higher-layer partitioning compared to lower-layer partitioning.

[0128] 3GPP decided to select Functional Partitioning Option 2 for upper layer partitioning. 3GPP defined the F1 interface to apply Functional Partitioning Option 2 to upper layer partitioning. The F1 interface is specifically specified in 3GPP specifications TS 38.470 to TS 38.475. The F1 interface can be the interface between the central unit (CU) and the DU. In other words, the F1 interface can correspond to a midhaul interface.

[0129] There are three sub-layer partitioning options: Functional Partitioning Option 6, Functional Partitioning Option 7, and Functional Partitioning Option 8. Functional Partitioning Option 7 can be further subdivided into Functional Partitioning Option 7-1, Functional Partitioning Option 7-2, and Functional Partitioning Option 7-3, depending on the level of partitioning within the physical layer (PHY). Currently, 3GPP has not decided which option among Functional Partitioning Option 6, Functional Partitioning Option 7, and Functional Partitioning Option 8 to select.

[0130] In 3GPP, the terms lower layer split central unit (LLS-CU) and lower layer split distributed unit (LLS-DU) are used for lower layer split, which can correspond to CU / DU and RU, respectively. In O-RAN, the terms O-RAN central unit (O-RAN control unit (O-CU), O-RAN distributed unit (O-DU), and O-RAN radio unit (O-RU) are used, which can correspond to CU, DU, and RU, respectively.

[0131] The interface between the DU and the RU is also called the 'Fx interface', and can be the interface between the LLS-CU and the LLS-DU in the lower layer division of 3GPP. The interface between the LLS-CU and the LLS-DU can correspond to the fronthaul interface.

[0132] Functional partitioning option 6, which is a lower layer partitioning, can be a partitioning between the MAC layer and the PHY layer as described above, where the PHY and RF can be located in the LLS-DU, and upper layer functions such as the MAC layer, RLC layer, PDCP layer, etc. can be located in the LLS-CU.

[0133] Among the sublayer partitioning, the intra-PHY partitioning options can be further subdivided into functional partitioning option 7-1, functional partitioning option 7-2, and functional partitioning option 7-3 as described above.

[0134] Functional partitioning option 7-3, which is a lower layer partitioning, may be an option applicable only to the downlink, and among the PHY layer functions, functions such as coding, rate matching, and scrambling may be located in the LLS-CU, and the remaining lower PHY functions may be located in the LLS-DU.

[0135] In downlink operation in the lower layer partitioning function partitioning option 7-2, lower layer PHY functions such as inverse fast Fourier transform (IFFT), cyclic prefix (CP) addition, resource mapping, and precoding can be located in the LLS-DU, and the remaining upper layer PHY functions can be located in the LLS-CU. In uplink operation in the lower layer partitioning function partitioning option 7-2, lower layer PHY functions such as fast Fourier transform (FFT), CP removal, and resource demapping can be located in the LLS-DU, and the remaining upper layer PHY functions can be located in the LLS-CU.

[0136] In the lower layer partitioning function partitioning option 7-1, when operating in the downlink, lower PHY functions such as IFFT and CP addition can be located in the LLS-DU, and the remaining upper PHY functions can be located in the LLS-CU. In the lower layer partitioning function partitioning option 7-1, when operating in the uplink, lower PHY functions such as FFT and CP removal can be located in the LLS-DU, and the remaining upper PHY functions can be located in the LLS-CU.

[0137] FIG. 5 is a block diagram illustrating a first embodiment of a lower layer split (LLS)-based base station.

[0138] Referring to FIG. 5, the base station (500) is illustrated as having two O-RUs (521, 522) connected to an O-DU (510). However, the number of RUs constituting one base station (500) may be one or three or more. As described above, the O-DU (510) may be understood as an LLS-CU in 3GPP, and each of the O-RUs (521, 522) may be understood as an LLS-DU in 3GPP.

[0139] The configuration of each of the O-DU (510) and O-RUs (521, 522) may vary depending on any one of the functional partitioning option 6, functional partitioning option 7-1, functional partitioning option 7-2, or functional partitioning option 7-3 described above.

[0140] The O-DU (510) can control one or more O-RUs and can be a logical node including an RLC layer, a MAC layer, and a High-PHY layer. Each of the O-RUs (521, 522) can be a logical node including a Low-PHY layer and an RF processing function. Each of the O-RUs (521, 522) can transmit / receive real-time control information and / or user plane data to / from the O-DU (510).

[0141] The O-DU (510) can correspond to an LLS-CU as illustrated in FIG. 5, and each of the O-RUs (521, 522) can correspond to an LLS-DU. The fronthaul interface between the O-DU (510) and the O-RUs (521, 522) can provide a control plane (C-plane) and a user plane (U-plane). In other words, data of the control plane between the O-DU (510) and the O-RUs (521, 522) can be transmitted through the fronthaul interface as illustrated in FIG. 5, and data of the user plane between the O-DU (510) and the O-RUs (521, 522) can be transmitted through the fronthaul interface as illustrated in FIG. 5, LLS-U.

[0142] The O-RAN fronthaul interface may be based on intra-PHY splitting, and Option 7-2x, a variant of 3GPP lower layer functional splitting Option 7-2, may be used.

[0143] In the functional split option 7-2x, functions such as OFDM phase compensation, IFFT and CP addition, and digital beamforming during downlink transmission may be included in each of the O-RUs (521, 522), and the remaining PHY layer functions of the downlink (e.g., resource element mapping, layer mapping, modulation, scrambling, rate matching, and coding) may be included in the O-DU. User plane data may be transmitted through the fronthaul interface based on resource elements (REs) and / or physical resource blocks (PRBs). IQ compression may also be optionally applied when transmitting data through the fronthaul interface.

[0144] Depending on whether the precoding function in the downlink is performed in the O-RUs (521, 522), it can be divided into Category A and Category B. Category A may be the case where precoding is not performed in the O-RUs (521, 522) (Option 7-2a), and Category B may be the case where precoding is not performed in the O-DU (510) but is performed in each of the O-RUs (521, 522) (Option 7-2b).

[0145] OFDM phase compensation, FFT and CP removal, and digital beamforming functions in the uplink may be included in each of the O-RUs (521, 522), and the remaining PHY layer functions in the uplink (e.g., resource element demapping, equalization, demodulation, descrambling, rate dematching, and decoding) may be included in the O-DU (510).

[0146] In addition to the O-CU, O-DU, and O-RU, the O-RAN architecture may include a non-real time RAN intelligent controller (RIC) and a near-real time RIC, and various interfaces may exist between them. The O-CU may be configured as an O-CU user plane (O-CU-UP) and an O-CU control plane (O-CU-CP) by separating the user plane and the control plane.

[0147] The O-RAN Alliance aims to develop open, intelligent, virtualized, and fully interoperable RAN technology standards. The resulting O-RAN architecture is described below.

[0148] Figure 6 is a conceptual diagram of the O-RAN architecture defined by the O-RAN Alliance.

[0149] In an open RAN architecture, the RIC, as an intelligent RAN controller, can manage radio resources more efficiently based on artificial intelligence / machine learning (AI / ML). The RIC can be divided into a non-real-time RIC (611) and a near-real-time RIC (621).

[0150] Referring to FIG. 6, a service management and orchestration framework (SMO) (610) may include a non-real-time RIC (611) within it. The SMO (610) may support a management interface (O1) for O-RAN components, an interface (A1) for the non-real-time RIC (611), and an O-Cloud management interface (O2). In addition, the SMO (610) may directly manage the O-RU without going through the O-DU using the Open Fronthaul M-Plane interface. The O-DU may also manage the O-RU using the Open Fronthaul M-Plane interface.

[0151] The non-real-time RIC (611) included in the SMO (610) can perform RAN policy management and RAN analysis. The non-real-time RIC (621) can provide policy information and machine learning training model information to the near-real-time RIC (621) via the A1 interface. The control loop time required for the non-real-time RIC (611) may be 1 second or longer.

[0152] The non-real-time RIC (611) can be extended through applications based on an open standard application programming interface (API) as a RAN Intelligent Controller application (rAPP). The Non-real-time RIC (611) is being developed by the Non-real-time RAN Intelligent Controller and A1 Interface Workgroup (WG2).

[0153] The near real-time RIC (621) can perform near real-time enhanced radio resource management based on policies and training models provided from the non-real-time RIC (611) through the A1 interface. The near real-time RIC (621) can perform measurement data collection and control from an O-eNB (631), which is a 4G base station, and / or a functionally partitioned 5G base station through the E2 interface. As described above, the 5G base station may include an O-CU-CP (641), an O-CU-UP (642), and / or an O-DU (651). The control loop requirement time of the near real-time RIC (621) may be 10 ms or more and less than 1 second. The near real-time RIC (621) is responsible for developing specifications in the Near-real-time RIC and E2 Interface Workgroup (WG3). The functionality of the near-real-time RIC (611) can be extended through an open standard API-based application called an eXtended application (xApp). The xApp can control the control operations of the near-real-time RIC (611), such as handover optimization, wireless link monitoring, wireless resource management, mobility management, load balancing, slicing policy updates, traffic steering, interference management, and security.

[0154] The O-CU can be separated into a control plane (O-CU-CP (641)) including the RRC layer and PDCP-C functions and a user plane (O-CU-UP (642)) including the SDAP layer and PDCP-U functions, and can be connected to each other via an E1 interface. The interface related to the O-CU is being developed as a multi-vendor profile specification by the Open F1, W1, E1, X2, Xn Interface Workgroup (Open F1 / W1 / E1 / X2 / Xn Interface Workgroup, WG5).

[0155] The O-DU (651) may include RLC, MAC, and High-PHY functions, and the O-RU (652) may include Low-PHY and RF functions. The control loop requirement time of the O-DU (651) may be, for example, less than 10 ms, but may not be limited thereto. The Open Fronthaul Interfaces Workgroup (WG4) is developing specifications for the Open Fronthaul CUS-Plane and M-Plane, which are fronthaul interface specifications between the O-DU (651) and the O-RU (652).

[0156] In an open RAN architecture, RAN virtualization can be supported through the open RAN cloud (O-Cloud) (653). RAN hardware and software for the near-real-time RIC (621), O-CU, and O-DU (651) can be supplied separately from different vendors.

[0157] The interfaces between each function of the O-RAN are illustrated in the example of FIG. 6. Since these interfaces are defined by the O-RAN Alliance, it should be noted that a detailed description of each interface is omitted in this disclosure. Furthermore, reference numeral 660 may be an example illustrating the division of the O-RU (652) and its upper section from the perspective of base station division.

[0158] Currently, open-LAN-based NTN technology is non-existent. The present disclosure, described below, describes an open-LAN-based NTN communication network structure and communication method that efficiently perform open-LAN-based communications in NTN. Specifically, a regenerative satellite-based NTN architecture will be described, in which all or part of the base station functions are mounted on a satellite.

[0159] In a regenerative satellite-based NTN architecture, when all or part of the base station functions are mounted on a satellite, communication between RAN components must be achieved using a wireless interface. However, the interfaces of each component of the current O-RAN Alliance are based on the use of wired networks in the TN. This makes it difficult to directly apply current O-RAN technologies to the NTN environment. In particular, when applying LLS to NTN, LLS-based fronthaul requires high fronthaul capacity, low latency, constant visibility of the satellite O-DU and O-RU, and minimal latency variation in the fronthaul link. For these reasons, an efficient wireless implementation method is needed in NTN. Furthermore, a method is needed to configure and connect non-real-time RICs, near-real-time RICs, and other O-RAN interfaces to non-terrestrial networks using wireless links.

[0160] The present disclosure described below provides a method and device for enabling communication based on an open LAN in a mobile communication environment supporting 5G Advanced, 6G or later NTN.

[0161] [How to configure an O-RAN system in an NTN with transparent satellites]

[0162] FIG. 7a is a conceptual diagram of an open LAN-based system in an NTN having a transparent satellite according to one embodiment of the present disclosure.

[0163] Referring to FIG. 7A, terminals (711, 712) and a satellite (720) may be connected via a Uu interface. The satellite (720) may be a transparent satellite. The satellite (720) may perform a forwarding function for signals transmitted from the NTN gateway. In other words, the satellite (720) may perform a repeater function for the Uu interface between the feeder link (the link between the NTN gateway and the satellite) and the service link (the link between the satellite and the UE). In order for the satellite (720) to perform the repeater function, the satellite (720) may perform an amplification and / or frequency conversion operation.

[0164] A ground base station (e.g., gNB) including O-RAN functional division may have a structure divided into an O-RU (731), an O-DU (732), and an O-CU (733) as described above. In the case of a transparent satellite structure, the O-RU (731), the O-DU (732), and the O-CU (733) may all be located on the ground. Since each of the O-RU (731), the O-DU (732), and the O-CU (733) are all located on the ground, an open RAN (O-RAN) interface may be applied. More specifically, an F1 interface may be applied between the O-CU (733) and the O-DU (732), and an O-RAN Option 7-2x based fronthaul interface may be used between the O-DU (732) and the O-RU (731). Since each of the O-RU (731), O-DU (732), and O-CU (733) is located on the ground, the interfaces between the O-RU (731), O-DU (732), and O-CU (733) can all be wired interfaces. In other words, since each of the O-RU (731), O-DU (732), and O-CU (733) is located on the ground, it can have an open LAN structure as described above in FIGS. 5 and 6.

[0165] FIG. 7b is a conceptual diagram including the configuration of RIC and SMO of O-RAN in NTN having transparent satellite according to one embodiment of the present disclosure.

[0166] It should be noted that the satellite (720) and terminals (711, 712) of FIG. 7A, previously described in FIG. 7B, are identical to those of FIG. 7A and are therefore omitted from the drawing. Referring to FIG. 7B, a non-real-time RIC (751) and a near-real-time RIC (752) and their interfaces may be further considered in a transparent satellite-based NTN. The non-real-time RIC (751) may be included in the SMO as previously described in FIG. 6. However, for the convenience of explanation, in FIG. 7B, the non-real-time RIC and the SMO will be described by assigning a single reference numeral to each other.

[0167] The non-real-time RIC (751) can perform RAN policy management, RAN analysis, and other functions. The non-real-time RIC (751) can generate (or acquire) a machine learning training model and provide it to the near-real-time RIC (752) via the A1 interface. The machine learning training model can be a policy and training model. The near-real-time RIC (752) can perform real-time (or near-real-time) radio resource management based on the policy and training model provided from the non-real-time RIC (751) via the A1 interface. The near-real-time RIC (752) can perform measurement data collection and control functions via the E2 interface. The near-real-time RIC (752) can control the O-DU (732) and the O-CU (733) using the E2 interface.

[0168] The O-Cloud can support RAN virtualization. The non-real-time RIC (751), near-real-time RIC (752), O-DU (732), O-CU (733), and other components can be supplied by different vendors in a form of separate hardware and software. The O-RU (731) is generally implemented in hardware and may not use the O-Cloud, but the software portion of the O-RU (731) may be virtualized through the O-Cloud. The configuration of the O-RU (731) is provided as an example only to help understand the present disclosure and is not limited thereto.

[0169] The SMO (751) can manage the near real-time RIC (752), O-CU (733), O-DU (732), O-RU (731) and other O-RAN components using the management interface (O1). The SMO (751) can manage the O-Cloud via the O2 interface. Components implemented to support virtualization, such as the non-real-time RIC (751), near real-time RIC (752), O-CU (733) and O-DU (732), can use the O-Cloud as a virtualization environment. In other words, the SMO (751) can control and manage components used in the virtualization environment via the O2 interface.

[0170] Each component of the open LAN-based transparent satellite system described above, such as O-CU (7330, O-DU (752), O-RU (751), near real-time RIC (752), SMO (751) including non-real-time RIC, etc., can all be located on the ground in the transparent satellite system structure. Therefore, the operations between components of the existing terrestrial network can be applied as is to the interfaces between the components of the open LAN, such as the A1 interface, E2 interface, O1 interface, O2 interface, F1 interface, and fronthaul interface. In other words, the same interface as described in FIG. 6 can be applied.

[0171] [How to configure an O-RAN system in an NTN with regenerative satellites]

[0172] OpenLAN-based regenerative satellite-based NTN can have the following advantages:

[0173] First, since it is possible to use satellites equipped with only O-DUs or only O-RUs instead of installing full gNBs on all satellites, the complexity and development cost of the satellite payload can be reduced.

[0174] Second, the advantages of the C-RAN architecture, which enables resource pooling, can be applied to NTNs, enabling efficient use of satellite resources. In particular, by ensuring that only O-RUs are mounted on a satellite, satellite power consumption can be reduced.

[0175] Third, satellite coverage can be further improved. In other words, satellite communications coverage can be expanded by using multiple satellites with separate functions instead of a single base station satellite. Furthermore, by connecting multiple satellites via inter-satellite links (ISLs), satellite communications services can be provided to areas without ground gateways.

[0176] In the description below, information (or data) may include various forms of information provided to a specific node. For example, it may include one or more of the following: parameters to be provided to a specific node, data, information for controlling a specific node (or satellite), information for managing a specific node (or satellite), commands for control, instructions for control, or commands (or instructions) requesting the provision of specific information. Furthermore, information may be provided through a specific interface, and if a specific interface is used, it may be processed in a format consistent with the format provided by that interface.

[0177] A first embodiment of configuring an O-RAN system in an NTN having a regenerative satellite is described with reference to the attached FIGS. 8a and 8b.

[0178] FIG. 8a is a conceptual diagram of a case where O-RAN is applied to NTN using both upper layer partitioning and lower layer partitioning according to the first embodiment of the present disclosure.

[0179] Referring to Fig. 8a, two groups, Satellite Group A (820) and Satellite Group B (830), are illustrated. The two groups (820, 830) illustrated in Fig. 8a are merely examples to aid understanding of the satellite configuration and are not limited thereto. In other words, the number of groups illustrated in Fig. 8a may be one or three or more.

[0180] Satellite group A (820) may include an O-DU-equipped satellite (821) and O-RU-equipped satellites (822, 823) according to one embodiment of the present disclosure, and satellite group B (830) may include an O-DU-equipped satellite (831) and O-RU-equipped satellites (832, 833) according to one embodiment of the present disclosure. In other words, each of the O-DUs (831, 831) and the O-RUs (822, 823, 832, 833) may be located on a non-terrestrial basis based on a satellite. Since one group has a structure composed of an O-DU-equipped satellite and an O-RU-equipped satellite(s) as illustrated in FIG. 8A, the satellites may have a low-layer split (LLS) structure. The number of satellites included in one satellite group in the present disclosure illustrated in FIG. 8A is only one example to help understanding and is not limited thereto. In other words, a satellite group can be composed of two or more satellites, as the satellites must have a structure in which they are connected by an LLS.

[0181] O-RU-equipped satellites (822, 823) of satellite group A (820) can communicate with UEs (801, 802, 803) using the NR Uu interface, and O-RU-equipped satellites (832, 833) of satellite group B (830) can communicate directly or indirectly with UEs (804, 805, 806) using the NR Uu interface. As illustrated in FIG. 8A, one group may be composed of one satellite performing O-DU operation and one or more satellite(s) performing O-RU operation.

[0182] The O-CU (840) may be located on the ground and may communicate with at least one of the O-DUs (831, 831) of the O-DU-equipped satellites via an NTN gateway using an F1 over SRI (F1 over SRI) interface. As illustrated in FIG. 8A, since the O-CU (840) and the O-DUs (831, 831) are functionally divided, the O-CU (840) and the O-DUs (831, 831) may have a high-layer split (HLS) structure.

[0183] According to the example in Fig. 8a, an O-DU (831) belonging to satellite group B (830) can communicate with an O-CU (840) located on the ground using an F1 interface via SRI, and an O-DU (821) of satellite group A (820) can communicate with an O-DU (831) belonging to satellite group B (830) using an F1 over ISL interface or a new interface via ISL.

[0184] According to the overall structure illustrated in FIG. 8a, the HLS structure may be applied between the O-CU (840) located on the ground and the O-DU (831) mounted on the satellite, and the LLS structure may be applied between the O-DU-mounted satellites (831, 831) and the corresponding O-RU-mounted satellites (821, 822, 823, 824) when the LLS structure is applied on the non-ground.

[0185] An ISL-based fronthaul interface may be used between O-DU-equipped satellites (831, 831) and O-RU-equipped satellites (821, 822, 823, 824). An O-RAN-based 7-2x fronthaul interface may be used for the ISL-based fronthaul interface between O-DU-equipped satellites (831, 831) and O-RU-equipped satellites (821, 822, 823, 824). As another example, the ISL-based fronthaul interface between O-DU-equipped satellites (831, 831) and O-RU-equipped satellites (821, 822, 823, 824) may apply LLS partitioning using Option 7-2, Option 7-3, Option 6 or other options, or a higher-order functional partitioning such as Option 5, 4, 3 may be applied.

[0186] In other words, a single complex satellite function can be divided into one O-DU-equipped satellite and one or more O-RU-equipped satellites for each satellite group, so that both HLS and LLS structures can be applied.

[0187] A satellite group as exemplified in Fig. 8a can be understood as a "satellite cluster." In a satellite group, one O-DU-equipped satellite can be a master satellite (or leader satellite), and one or more O-RU-equipped satellite(s) connected to the master satellite can be slave satellites (or follower satellites). A satellite group as exemplified in Fig. 8a can function as a base station based on cooperation among satellites within the satellite group. Since the satellites within the satellite group must cooperate to perform the base station function, multiple satellites within the satellite group must always move together.

[0188] The F1 interface is an extended interface that can support wireless backhaul in the integrated access backhaul (IAB) standard, and can support wireless connections. When an O-DU satellite (831) belonging to satellite group B (830) connected to a ground O-CU (840) via the F1 interface becomes distant from the NTN gateway and loses connection, and another O-DU satellite belonging to a different satellite group enters the communication range that allows connection with the NTN gateway connected to the O-CU (840), the O-CU (840) can perform F1 interface reconnection with the O-DU satellite that has newly entered the communication range. The ground-based O-CU (840) can also communicate with an O-DU (821) that is more than two hops away from the O-CU (840) via the F1 interface. In other words, the F1 interface can support multi-hops.

[0189] Meanwhile, since the standardized O-RAN fronthaul interface to date is wired-based, if the O-RU satellite connected to an O-DU-equipped satellite changes, the fronthaul operation may temporarily stop, or it may take a long time for the O-DU-equipped satellite to establish a connection with the new O-RU-equipped satellite. To solve this problem, the O-DU-equipped satellite and the O-RU-equipped satellite must move in a group (or cluster) so that they are always visible to each other. In addition, the distance between the O-DU-equipped satellite and the O-RU-equipped satellite must be small.

[0190] In satellite communications, it may be more efficient to use multiple, simple, small satellites, configured as a satellite cluster (or satellite group), to perform a single mission, rather than using a single, complex satellite. The satellites described in the present disclosure, as described below, may include aerial vehicles. Aerial vehicles corresponding to satellites may include unmanned aerial vehicles (UAVs), drones, HAPS (high-altitude and pressure platforms), aircraft, and other aerial objects. The aerial objects should not be construed as being limited to a specific form.

[0191] Satellites (or aerial vehicles) within a satellite cluster (or satellite group) can fly in formation, communicate within and outside the cluster, and coordinate with each other within and outside the satellite cluster. When operating cooperatively in a satellite cluster manner, the satellites within the satellite group can fly in formation so that the distance between them is kept constant. This allows the O-DU and O-RU satellites within a satellite to always be within the line of sight of each other, and the distance between an O-DU satellite and multiple O-RU satellites is small, so that continuous connection can be maintained when communicating with each other, and also easy synchronization between an O-DU satellite and multiple O-RU satellites can be achieved. Each O-RU satellite within a satellite cluster can act as a transmission point (TP), and a cooperative transmission method using multiple transmission points (Multi-TRP) on the ground can also be performed in satellite communications using the satellite cluster. In cooperative transmission, synchronization between TPs is very important, and the feature that allows easy synchronization between O-DU-equipped satellites and multiple O-RU-equipped satellites as shown above is a very advantageous advantage for satellite cooperative communications.

[0192] When using a satellite cluster method, satellites within the same satellite cluster operate as a single satellite, and by applying an appropriate formation flight technique, they can always move together, and also keep the distance between O-DU and O-RU satellites close, so that latency can be reduced when communicating with each other. In LLS, it is very important to satisfy the low latency requirements between O-DU and O-RU and the synchronization requirements between O-DU and O-RU, and through satellite cluster operation with the above formation flight technique applied, LLS can be applied between O-DU-equipped satellites and multiple O-RU-equipped satellites within a satellite group. This has the advantage of always being visible between O-RU(s) and O-DUs within the cluster, so communication links are not interrupted.

[0193] Communication between each satellite group can be performed via O-DU-equipped satellites (821, 831). The F1 over ISL interface can be used for communication between O-DU-equipped satellites (821, 831). As another example, a new communication interface can be defined and used for communication between O-DU-equipped satellites (821, 831). Since the F1 interface can support multi-hop as described above, when the F1 interface is used for communication between O-DU-equipped satellites (821, 831), the O-DU-equipped satellite (821) of satellite group A (820) can be connected to the ground O-CU (840) via the F1 interface via the O-DU-equipped satellite (831) of satellite group B (830). In other words, the O-DU-equipped satellite (821) of satellite group A (820) can communicate with the ground O-CU (840) in multi-hop via the F1 interface. When cooperation between satellite groups (or between O-DU-equipped satellites) is required, the O-DU-equipped satellite (821) of satellite group A (820) and the O-DU-equipped satellite (831) of satellite group B (830) can cooperate through information exchange between different satellite groups (or between O-DU-equipped satellites) while being controlled by the ground O-CU (840) via the F1 interface.

[0194] For example, when one of the UEs (811, 812, 813, 814, 815, 816) performs a handover to another satellite group (i.e., another O-DU-equipped satellite), information may need to be exchanged between the source O-DU-equipped satellite and the target O-DU-equipped satellite, and the source O-DU-equipped satellite and the target O-DU-equipped satellite can exchange such handover-related information and perform the handover under the control of the ground O-CU (840) via the F1 interface.

[0195] NTN requires the use of the F1 interface over SRI, a wireless link. Terrestrial NTN gateways and O-DU-equipped satellites are wirelessly connected via SRI. Because LEO satellites are constantly moving, the O-DU-equipped satellites that wirelessly connect to a specific terrestrial NTN gateway constantly change. Therefore, to enable wireless F1 interface reconnection with a new O-DU-equipped satellite even when the O-DU-equipped satellite changes, an F1 interface resume or reset function can be added to the current F1 interface.

[0196] When a source O-DU-equipped satellite and a target O-DU-equipped satellite perform information exchange under the control of a ground O-CU (840) through the F1 interface, there may be an O-DU-equipped satellite that must communicate with the ground CU (840) through multiple hops as described above. In this case, a very large delay may occur in the communication between the O-DU-equipped satellite and the ground O-CU (840). To prevent this delay, a new interface that performs direct information transfer between O-DU-equipped satellites (821, 831) without going through the O-CU (840) may be considered. In other words, the O-DU-equipped satellites (821, 831) can perform direct information transfer through the ISL between the O-DU-equipped satellites (821, 831) without going through the O-CU (840), thereby enabling handovers and other information transfers requiring cooperation between the O-DU-equipped satellites to be performed more quickly.

[0197] A satellite that performs a master role within a satellite group may be equipped with only the O-DU function, or it may be equipped with both the O-DU function and the O-RU function. In the present disclosure, a satellite equipped with both the O-DU function and the O-RU function is described as an "O-DU satellite equipped with a local O-RU." The O-DU satellite equipped with a local O-RU is merely a designation to aid understanding of the present disclosure and should not be understood as being limited to that designation. If the satellite that performs a master role within a satellite group is an "O-DU satellite equipped with a local O-RU" equipped with both the O-DU function and the O-RU function, the master satellite can also communicate with ground UEs, and based on this, the ground coverage of the satellite cluster can be further expanded.

[0198] Inter-satellite ISL can use RF or free-space optics (FSO) ISL, which utilizes lasers. Laser-based ISL in space can be approximately 50% faster than terrestrial fiber optic cables, allowing terrestrial LSL methods to be used in space as well, using FSO.

[0199] When the O-CU (840) is located in the TN and the O-DU to the NTN, the complexity of the satellite can be reduced compared to when all components from the O-CU to the O-RU are located in the NTN. This is because the satellite can be implemented to include only the O-DU or the O-RU. However, when performing satellite communication, the UE must perform the RRC protocol with the base station, and since the RRC protocol is performed in the O-CU (840) on the base station side, the UE needs to communicate to the O-CU (840) located on the ground via the satellite when performing the RRC protocol. Since the O-CU (840) is located on the ground, there is a disadvantage in that the delay of the RRC protocol increases due to the communication delay between the non-ground and ground.

[0200] When comparing the structure of FIG. 8a with the case where a single satellite has full base station function, the structure of FIG. 8a, which provides function split by using multiple small satellites in NTN, can provide additional coverage because multiple O-RUs perform the role of multiple TPs, and thus can provide wider coverage than the case where a single satellite with full base station function is used. In addition, since the F1 interface used between O-DU-equipped satellites can provide multi-hop, the O-CU (840) located on the ground can communicate with the O-DU-equipped satellite that is separated by multiple hops. Therefore, the O-CU (840) located on the ground can also connect to the O-DU-equipped satellite that is located outside the communication range of the ground NTN gateway. In other words, in FIG. 8a, the O-DU-equipped satellite (821) of satellite group A (820) can communicate with the ground O-CU (840) through the O-DU-equipped satellite (831) of satellite group B (830) even in a location where direct connection with the NTN gateway is not possible.

[0201] FIG. 8b is a conceptual diagram including the configuration of RIC and SMO in an O-RAN architecture in which both upper layer partitioning and lower layer partitioning are used in NTN according to the first embodiment of the present disclosure.

[0202] In Fig. 8b, the NTN gateway and O-CU (840) may be the same nodes as the NTN gateway and O-CU (840) described in Fig. 8a above. It should be noted that the O-DU-equipped satellites (821, 831) and O-RU-equipped satellites (822, 823, 832, 833) included in each of the satellite groups (820, 830) illustrated in Fig. 8a are omitted in Fig. 8b. In other words, LLS may be used between the O-DU-equipped satellites (831, 832) and the O-RU-equipped satellites (821, 822, 823, 824) in Fig. 8b. It should be noted that Figs. 8a and 8b may be connected drawings, and are configured separately as Figs. 8a and 8b due to limitations of the drawings.

[0203] Figure 8b illustrates the SMO and non-real-time RIC (862) and near-real-time RIC (861) of O-RAN, and illustrates interfaces between each node. Figure 8b first describes the operation of O-RAN nodes in NTN and the interfaces between each node.

[0204] The non-real-time RIC (862) can perform RAN policy management and RAN analysis, and can generate (or obtain) a machine learning training model and provide it to the near-real-time RIC (861) via the A1 interface. The machine learning training model that the non-real-time RIC (862) provides to the near-real-time RIC (861) may be a policy and training model. The near-real-time RIC (861) can perform radio resource management functions in real-time (or close to real-time) based on the policy and training models provided from the non-real-time RIC (862) via the A1 interface. The near-real-time RIC (861) can perform measurement data collection and control functions via the E2 interface (872). The near-real-time RIC (861) can control the O-DU-mounted satellites (831, 832) and the O-CU (840) using the E2 interface (872). Since the O-DU is mounted on the satellite in the embodiments of FIGS. 8a and 8b, the E2 interface (872) between the near real-time RIC (861) and the O-DU-mounted satellites (831, 832) can be transported to the O-DU-mounted satellites via the NTN gateway and SRI (using E2 over SRI).

[0205] For an O-DU-equipped satellite (821) of satellite group A (820) outside the NTN gateway communication range, a near real-time RIC (861) on the ground can control the O-DU-equipped satellite (831) of satellite group A (820) by transporting the E2 interface in multi-hop via an O-DU-equipped satellite (832) of satellite group B (830). In this case, the E2 interface can be transferred using ISL between the two O-DU-equipped satellites (831, 832) (E2 over ISL).

[0206] The control loop time requirement of the near-real-time RIC (861) can be between 10 ms and 1 second. This control loop time requirement of the near-real-time RIC (861) may be difficult to meet when passing through a ground-to-non-ground link. To address this, a "Local xApp" can be installed on the O-DU-mounted satellite.

[0207] Typically, an xApp is installed inside a near-real-time RIC (861) to intelligently manage O-CUs and O-DUs. To address the latency issue of ground-to-ground links, an xApp that performs resource management for an O-DU-equipped satellite may be installed on an O-DU-equipped satellite rather than inside a near-real-time RIC (861) on the ground. This is referred to as a "local xApp" in the present disclosure. The local xApp may be a concept in which some of the xApps of the near-real-time RIC are forward-deployed on a satellite. The local xApp can receive control policies, channel prediction data, weather prediction data, etc. required for satellite communication control in advance from the near-real-time RIC located on the ground through an extended E2 interface (or a newly defined control interface for the local xApp). Thereafter, when an event related to satellite communication occurs, the local xApp can process control in near real time locally (such as an O-DU within a specific satellite cluster). Since the satellite communication environment is a line-of-sight (LOS) communication environment, and channel changes are relatively small, and it is easy to predict channel changes from satellite orbit information, ground UE position information, and weather forecast information, a ground non-real-time RIC or near-real-time RIC can be configured to predict channel information using this information and transmit it to the local xApp through the extended E2 interface (or a newly defined control interface for the local xApp). The local xApp that receives the above information can control the satellite O-DU in near real time by combining the local satellite information collected by the local xApp and the previously received forecast information based on the received pre-prediction information.Additionally, if a non-real-time RIC or near-real-time RIC additionally transmits a machine learning model related to the satellite through the extended E2 interface (or a newly defined control interface for the local xApp), the xApp can perform near-real-time control of the satellite cluster more intelligently by applying AI / ML learning models to the received control policies, channel prediction data, and weather prediction data.

[0208] In other words, instead of having to directly control the local O-DU through the RIC every time an event occurs within the satellite cluster, the local xApp can manage the local O-DU directly within the satellite cluster based on predictive information received from the RIC in advance. In this way, the local xApp can control operations such as channel information updates for MIMO or beamforming, handover optimization, wireless link monitoring, wireless resource management, mobility management, load balancing, slicing policy updates, traffic steering, interference management, and security in real-time (or near real-time) on the O-DU-equipped satellite.

[0209] In this way, when the local xApp is installed on the O-DU-equipped satellite rather than inside the near-real-time RIC (861), the local O-DU can be managed directly on the satellite through the local xApp without going through the near-real-time RIC (861) located on the ground. When the local xApp is installed on the O-DU-equipped satellite, it can be more suitable for GEO satellites with a large ground-to-ground delay time, for example. In addition, the local xApp can be installed on the O-DU-equipped satellite for LEO or MEO satellites to further reduce the control loop time of the near-real-time RIC.

[0210] The SMO (862) can manage the near real-time RIC (861), O-CU, O-DU, O-RU and other O-RAN components using the management interface (O1) (871). When the SMO (862) manages the O-RU, the M-Plane interface (871) of the Open Fronthaul can be used instead of the O1 (871) interface. Since FIG. 8a and FIG. 8b show a case where the O-DU and O-RU are mounted on a satellite, the O1 interface (871) can be used to transport to the O-DU-mounted satellite and the O-RU-mounted satellite using the NTN gateway and SRI (using O1 over SRI). Additionally, if SMO (862) directly manages O-RU, it can transport Open Fronthaul's M-Plane interface (871) to O-RU via NTN gateway, SRI and O-DU in a similar manner to the O1 (871) interface above (using Open Fronthaul M-Plane over SRI).

[0211] For the O-DU-equipped satellite (821) and O-RU-equipped satellites (822, 823) of satellite group A (820) outside the NTN gateway communication range, the ground SMO (862) can transport the O1 interface or the M-Plane interface (871) of the Open Fronthaul to the O-DU-equipped satellite (821) and O-RU-equipped satellites (822, 823) of satellite group A (820) via the O-DU-equipped satellite (831) of satellite group B (830) in a multi-hop manner. In this case, the O1 interface or the M-Plane interface (871) of the Open Fronthaul can be transported between the two O-DU-equipped satellites (821, 831) and between the O-DU and O-RU within the same satellite group via the O1 interface using ISL (using O1 over ISL or a similar form of Open Fronthaul M-Plane over ISL).

[0212] If the SMO (862) does not directly manage the O-RU, the O-DU function (or the device performing the O-DU function) of the O-DU-equipped satellite may directly manage the O-RU satellite using Open Fronthaul M-Plane over ISL.

[0213] Additionally, when supporting RAN virtualization via O-Cloud, RAN hardware and software can be separated for the near real-time RIC (862), O-CU, O-DU, and other components within the open RAN architecture, and the RAN hardware and software can be supplied and used from different companies (vendors). Most O-RUs are implemented in hardware and do not usually use O-Cloud, but the software portion of the O-RU can also be virtualized via O-Cloud.

[0214] When O-DU, local xApp, and O-RU, etc. are implemented (mounted) on a satellite, components implemented to support virtualization on the satellite, such as software implemented parts of local xApp, O-DU, and O-RU, can use the satellite's O-cloud as a virtualization environment, and the SMO (862) can manage the satellite's O-cloud through the O2 interface (871).

[0215] When an O-DU, a local xApp, and an O-RU are mounted on a satellite, the SMO (862) can transport an O2 interface (871) (O2 over SRI) to the O-DU-mounted satellite and the O-RU-mounted satellite via the NTN gateway and SRI. In addition, for the O-DU-mounted satellite (821) and the O-RU-mounted satellites (822, 823) of satellite group A (820) that are outside the communication range of the NTN gateway, the ground-located SMO (862) can transport the O2 interface to the O-DU-mounted satellite (821) and the O-RU-mounted satellites (822, 823) of satellite group A (820) in a multi-hop manner via the O-DU-mounted satellite (831) of satellite group B (830). In this case, information transmitted between O-DU-equipped satellites (821, 831) and between O-DU and O-RU within the same satellite group can use the O2 interface via ISL (O2 over ISL).

[0216] Meanwhile, user data transmitted by at least one UE using NTN can be transmitted to CN (850) via gateway and O-CU (840), and user data transmitted from CN (850) to UE can be transmitted to the corresponding satellite of NTN via O-CU (840) and gateway and delivered to UE.

[0217] Next, a second embodiment of configuring an O-RAN system in an NTN having a regenerative satellite is described with reference to the attached FIGS. 9a and 9b.

[0218] FIG. 9a is a conceptual diagram of a case where functions are divided into an O-CU / O-DU-equipped satellite and an O-RU-equipped satellite in NTN according to the second embodiment of the present disclosure.

[0219] Referring to FIG. 9A, each of satellite group A (920) and satellite group B (930) may include two or more satellites. More specifically, satellite group A (920) may include one O-CU / O-DU equipped satellite (921) and one or more O-RU equipped satellite(s). In the example of FIG. 9A, satellite group A (920) is exemplified as including two O-RU equipped satellites (922, 923). Satellite group B (930) may also include one O-CU / O-DU equipped satellite (931) and one or more O-RU equipped satellite(s). In the example of FIG. 9A, satellite group B (930) is exemplified as including two O-RU equipped satellites (932, 933). However, the number of O-RU-equipped satellites included in each satellite group is only an example to help understanding of the present disclosure, and the number of O-RU-equipped satellites included in one satellite group is not limited to two.

[0220] The O-CU / O-DU equipped satellite (921) within satellite group A (920) and the O-CU / O-DU equipped satellite (931) within satellite group B (930) may be master satellites (or leader satellites) of each of the satellite groups (920, 930), and a plurality of O-RU equipped satellites (922, 923, 932, 933) connected to the O-CU / O-DU equipped satellites (921, 931) may be slave satellites (or follower satellites). Each of satellite group A (920) and satellite group B (930) may be understood as a satellite cluster as described above. One satellite group may perform the role of one base station through cooperation of satellites within the satellite group, and for this purpose, the satellites within the satellite group may be enabled to move together.

[0221] Each of the satellite groups illustrated in FIG. 9A may be a case where the NTN is configured with satellites equipped with O-CU / O-DUs and satellites equipped with only O-RUs using LLS. In other words, it may be an O-RAN-based structure where LLS is used in the NTN. For each of the O-CU / O-DU-equipped satellites (921, 931), an NG interface (NG over SRI) through the NTN gateway of the TN may be used. An ISL-based fronthaul interface may be used between the satellites equipped with O-CU / O-DUs and the satellites equipped with only O-RUs. The fronthaul interface between satellites in the NTN may be an O-RAN-based 7-2x fronthaul interface, or LLS may be applied based on other options such as Option 7-2, Option 7-3, Option 6, Option 5, Option 4, and Option 3.

[0222] In TN, the NG interface uses a wired interface, but in NTN, the NG interface via SRI, a wireless link, must be used. The terrestrial NTN gateway and the O-CU / O-DU-equipped satellite are wirelessly connected via SRI. Since LEO satellites are constantly moving, the O-CU / O-DU-equipped satellite that is wirelessly connected to a specific terrestrial NTN gateway is constantly changing. Therefore, even if the O-CU / O-DU-equipped satellite changes, the NG interface resume or NG interface reset function can be added to the existing NG interface to enable wireless NG interface reconnection with the changed O-CU / O-DU-equipped satellite.

[0223] Since the NG interface does not support multi-hop, an O-CU / O-DU-equipped satellite that is more than 2 hops away must be connected to another NTN gateway within the range that can connect to the satellite. Based on this restriction, a distant O-CU / O-DU-equipped satellite can connect to an NTN gateway that is within its communication range. In other words, an NTN gateway (941) that is connected to an O-CU / O-DU-equipped satellite (921) within satellite group A (920) may be different from an NTN gateway (942) that is connected to an O-CU / O-DU-equipped satellite (931) within satellite group B (930).

[0224] If the NG interface is extended to support multi-hop, even if there is no NTN gateway within the communication range of an O-CU / O-DU-equipped satellite (921) belonging to satellite group A (920), communication with the TN may be possible by connecting to the NTN gateway (942) of satellite group B (930) via multi-hop. If the NG interface is extended to support multi-hop, an NG interface via ISL may be used between O-CU / O-DU-equipped satellites (931, 932), thereby enabling multi-hop connection.

[0225] Currently, the O-RAN fronthaul interface specified by the O-RAN Alliance is wired-based, and the interface between an O-RU-only satellite and an O-CU / O-DU-equipped satellite is wireless-based. Therefore, when an O-RU-only satellite connected to an O-CU / O-DU-equipped satellite is changed, the fronthaul operation may temporarily stop, or it may take a long time for an O-CU / O-DU-equipped satellite to establish a connection with another O-RU satellite. Therefore, it is recommended that O-CU / O-DU-equipped satellites and O-RU-only satellites move in groups so that they are visible to each other, and the change in the distance between the satellites should be small.

[0226] In satellite communications, rather than using a single, complex satellite, a satellite cluster can be implemented, utilizing multiple, simple, small satellites to perform a single mission. Satellites within a satellite cluster can fly in formation, communicate with nodes within and outside the cluster, and cooperate with each other. Using this cluster approach, satellites within the same satellite group (or cluster) can operate as a single satellite, and satellites (or nodes) within a satellite group can move together.

[0227] When using satellite groups, LLS may be possible between satellites carrying O-CU / O-DU and satellites carrying only O-RU. Communication between satellite groups can be achieved through communication between satellites carrying O-CU / O-DU, and the Xn interface via ISL can be used. When using the Xn interface via ISL, direct communication between two O-CU / O-DU satellites can be performed without ground communication for communication for cooperation between two satellite groups.

[0228] For example, when at least one of the ground UEs (901, 902, 903, 904, 905, 906) performs a handover to another satellite group, i.e., a satellite group including another O-CU / O-DU-equipped satellite, information exchange between the source O-CU / O-DU-equipped satellite and the target O-CU / O-DU-equipped satellite may be required. When communicating (transmitting / receiving information and / or data) between O-CU / O-DU-equipped satellites, handover can be performed without separate communication with the TN through the Xn interface via the ISL.

[0229] Meanwhile, a case may be considered where the O-CU / O-DU satellite performing the master role is further equipped with O-RU functions, and this is referred to as an "O-CU / DU satellite equipped with a local O-RU" in the following description. If the O-CU / O-DU satellite performing the master role is configured as an "O-CU / DU satellite equipped with a local O-RU" that includes a local O-RU, the master satellite can also communicate with ground UEs, and thus the coverage of the NTN can be further expanded.

[0230] Inter-satellite ISL can use RF or laser-based FSO. Laser-based ISL can be approximately 50% faster in space than TN optical cables, and can be adapted to TN LLS methods for space applications.

[0231] The NTN configuration illustrated in Fig. 9a is a structure in which the O-CU is mounted on the master (or leader) satellite, so the complexity of the satellite may increase compared to the structure in which the O-CU is located on the ground (Figs. 8a and 8b). However, when the UE performs an RRC protocol with the base station, communication may be required up to the O-CU. According to the example of Fig. 9a, since the O-CU is located on the satellite, the RRC delay may be shorter than the structure in which the O-CU is located on the ground (Figs. 8a and 8b). In addition, since the satellites are configured into a single cluster using LLS as illustrated in Fig. 9a, compared to the case in which a single satellite includes the entire base station, the satellite cluster can provide functional separation in the NTN by using small satellites that can perform multiple TP roles. The structure illustrated in FIG. 9a can provide additional coverage based on multiple O-RU-equipped satellites (including O-CU / DU satellites carrying local O-RUs), and can provide wider coverage than when the entire base station is contained in a single satellite.

[0232] FIG. 9b is a conceptual diagram illustrating the configuration of an NTN gateway and an RIC and SMO of an O-RAN connected to a satellite in an NTN according to a second embodiment of the present disclosure.

[0233] As illustrated in FIG. 9a above, the near real-time RIC in the present disclosure may be included in satellites equipped with O-CU / O-DU (921, 931). The near real-time RIC may control the O-CU and O-DU, and since the control loop requirement time of the near real-time RIC is short, from 10 ms to less than 1 second, it may be more efficient to include the near real-time RIC in the satellite equipped with O-CU / O-DU than to place the near real-time RIC separately on the ground, because it is easier to satisfy the control loop requirement time. It should be noted that FIGS. 9a and 9b may be connected drawings, and are configured separately as FIGS. 9a and 9b due to limitations of the drawings.

[0234] The non-real-time RIC (960) included in the SMO can perform RAN policy management, RAN analysis, etc., and provide a machine learning training model to the near-real-time RIC through the A1 interface. Since the near-real-time RIC is mounted on a satellite, the non-real-time RIC (960) can provide information (or data) provided (or received) to the near-real-time RIC to a satellite equipped with the near-real-time RIC (in the case of FIG. 9A, satellites equipped with O-CU / O-DU (921, 931)) through the NTN gateway (942), as shown by reference numeral 972. The information (or data) provided (or received) to the near-real-time RIC is transmitted through the A1 interface, and the non-real-time RIC (960) can transport the A1 interface to the satellite equipped with O-CU / O-DU through the NTN gateway and SRI (using A1 over SRI).

[0235] The near real-time RIC mounted on the O-CU / O-DU-equipped satellite (921) of satellite group A (920) and the near real-time RIC mounted on the O-CU / O-DU-equipped satellite (931) of satellite group B (930) can each be connected to different NTN gateways (NTN gateway (941) and NTN gateway (942) as illustrated in FIG. 9a). If the A1 interface is extended to support multi-hop so that A1 interface transport via ISL between satellites is supported, and there is no NTN gateway within the communication range of satellite group A (920), the O-CU / O-DU-equipped satellite (921) of satellite group A (920) can also be connected to the non-real-time RIC (960) located on the ground in multi-hop via the O-CU / O-DU-equipped satellite (931) of satellite group B (930).

[0236] As previously described, the O-CU / O-DU equipped satellite (921) and the O-CU / O-DU equipped satellite (931) may further be equipped with a near-real-time RIC. The near-real-time RIC may perform real-time or near-real-time radio resource management functions based on policies and training models received from the non-real-time RIC (960) via the A1 interface, and may control the O-CU / O-DU of the satellite.

[0237] The SMO (960) can manage near-real-time RICs, O-CUs, O-DUs, O-RUs, etc. using the management interface (O1) for managing O-RAN components. The near-real-time RICs, O-CUs, O-DUs, and O-RUs can be mounted on a satellite as described in Fig. 9a. When the SMO (960) manages O-RUs, the M-Plane interface (871) of the Open Fronthaul can be used instead of the O1 interface. When near real-time RIC, O-CU, O-DU, and O-RU are mounted on a satellite, the SMO (960) transmits information (or data) for management to the O-CU, O-DU, and near real-time RIC mounted on the O-CU / O-DU mounted satellite (921) and the O-CU / O-DU mounted satellite (931) via the NTN gateway (942), and can also transmit the information (or data) to the O-RU mounted satellites (922, 923, 932, 933). The information (or data) for management transmitted from the SMO (960) via the NTN gateway (942) can utilize the O1 interface as indicated by reference numeral 971, and the O1 interface can be transported to the O-CU / O-DU satellite and the O-RU satellite via the NTN gateway (942) and the SRI.

[0238] Additionally, when the SMO (960) directly manages the O-RU, the management plane (M-Plane) interface (971) of the open fronthaul can be transported to the O-RU via the NTN gateway, SRI, and O-DU in a similar manner to the O1 interface (971) above (using Open Fronthaul M-Plane over SRI).

[0239] Each of satellite group A (920) and satellite group B (930) can be connected to different NTN gateways (941, 942) as illustrated in FIG. 9A, and can be connected to a ground SMO (960) via different NTN gateways (941, 942) (using O1 over SRI). If the O1 interface is extended to support multi-hop and the O1 interface is supported via ISL between satellite groups, then if there is no NTN gateway within the communication range of the O-CU / O-DU-equipped satellite (921) of satellite group A (920), the O-CU / O-DU-equipped satellite (921) can also be connected to a ground SMO (960) via multi-hops via the O-CU / O-DU-equipped satellite (931) of satellite group B (930). In addition, each of the O-CU / O-DU-equipped satellites (921, 931) within the same satellite group can transmit information (or data) between the O-RUs (922, 923, 932, 933) within each satellite group using the O1 interface over ISL (O1 over ISL). When the SMO (960) directly manages the O-RU, the management plane (M-Plane) interface (971) of the open fronthaul can be transported to the O-RU via the NTN gateway, SRI, and O-DU in a similar manner to the O1 interface (971) above (using Open Fronthaul M-Plane over SRI). The M-Plane interface (971) of the Open Fronthaul transported to the O-CU / O-DU satellite using the Open Fronthaul M-Plane over SRI can be transported from the O-CU / O-DU satellite to the O-RU satellite using the ISL (Open Fronthaul M-Plane over ISL). If the SMO (960) does not directly manage the O-RU, the O-DU of the O-CU / O-DU satellite can also directly manage the O-RU satellite using the Open Fronthaul M-Plane over ISL.

[0240] RAN virtualization can be supported via O-Cloud. With RAN virtualization, RAN hardware and software for near-real-time RICs, O-CUs, and O-DUs can be separated, and each can be provided by different vendors (e.g., different companies). While O-RUs are mostly implemented in hardware and typically do not utilize O-Cloud, the software portion of the O-RU can be virtualized via O-Cloud.

[0241] When the satellite is configured to include O-CU / O-DU, near real-time RIC, O-RU, etc., components implemented to support virtualization in the satellite (e.g., O-CU / O-DU, near real-time RIC, O-RU, etc.) can use the satellite's O-cloud as a virtualization environment. When the satellite is configured to include O-CU / O-DU, near real-time RIC, O-RU, etc., and the satellite supports virtualization, the SMO (960) can manage the O-cloud through the O2 interface. More specifically, when O-CU / O-DU, O-RU, and near real-time RIC are mounted on a satellite, SMO (960) can transmit information (or data) to be provided to O-CU / O-DU, O-RU, and near real-time RIC through O2 interface, and SMO (960) can transport O2 interface to O-CU / O-DU mounted satellite and O-RU mounted satellite through NTN gateway and SRI (using O2 over SRI).

[0242] Since satellite group A (920) and satellite group B (930) can each be connected to different NTN gateways, they can be connected to the ground SMO through different gateways (using O2 over SRI). If the O2 interface is extended to support multi-hop and the O2 interface is supported using ISL between satellite groups, the O-CU / O-DU-equipped satellite (921) of satellite group A (920) can also be connected to the ground SMO through multi-hop via the O-CU / O-DU-equipped satellite (931) of satellite group B (930) even if there is no NTN gateway within its communication range. The O2 interface can be delivered between the O-CU / O-DU and O-RU within the same satellite group using ISL (O2 over ISL).

[0243] Meanwhile, user data transmitted by at least one UE using NTN can be transmitted to CN (950) via gateway (942), and user data transmitted from CN (950) to UE can be transmitted to the corresponding satellite of NTN via gateway (942) and delivered to UE.

[0244] FIG. 9c is a conceptual diagram of a case where functions are divided into O-CU / O-DU-equipped satellites and O-RU-equipped satellites in an NTN according to a second embodiment of the present disclosure, and a user plane function as part of a core network is added.

[0245] Fig. 9c may be a configuration in which a user plane function (UPF), which is part of a core network (CN), is further added to the structure of Fig. 9a described above, to the O-CU / O-DU satellite. Accordingly, Fig. 9c and Fig. 9b may be connected drawings, but it should be noted that they are configured separately as Fig. 9c and Fig. 9b due to drawing limitations.

[0246] The UPF processes user plane data received from the O-CU in the CN, and in the TN, the CN's UPF is connected to the O-CU-UP (the user plane of the O-CU) via the N3 interface.

[0247] In FIG. 9c, if each of the O-CU / O-DU-equipped satellites (921, 931) is equipped with a UPF and application server, user data can be processed by the satellite's UPF and application server even if it is not transmitted to the ground, thereby reducing user data processing time. In other words, satellite multi-edge computing (MEC) becomes possible.

[0248] In FIG. 9c, if the application server is not installed on each of the O-CU / O-DU-equipped satellites (921, 931), even if the UPF is on the satellite, the UPF must be connected to the ground data network for user data to be processed, and the data must be processed by the application server located on the ground. However, if the O-CU / O-DU-equipped satellites (921, 931) are each equipped with a UPF, even if the satellite is disconnected from the NTN gateway, the UE's data can be temporarily stored in the UPF, and then sent to the ground for processing when the satellite is reconnected to the NTN gateway. In other words, a store and forward type service becomes possible, and the service can be continued even if the connection with the TN is lost.

[0249] In the TN, the UPF is connected to the data network (DN) via the N6 interface and transmits user-plane data. Furthermore, the UPF is connected to the CN's session management function (SFM) via the N4 interface and is subject to control, including session establishment, modification, and QoS control.

[0250] In the case where each of the O-CU / O-DU-equipped satellites (921, 931) is equipped with a UPF, user data transmitted from the ground DN must be transmitted to the satellite UPF via the N6 interface, and the N6 interface can be transported via the NTN gateway and SRI (N6 over SRI).

[0251] Additionally, the N4 interface for ground SMF to control satellite UPF can also be transported to the satellite UPF via NTN gateway and SRI (N4 over SRI).

[0252] Each of the UPFs mounted on the O-CU / O-DU-mounted satellite (921) of satellite group A (920) and the UPFs mounted on the O-CU / O-DU-mounted satellite (931) of satellite group B (930) can be connected to different NTN gateways (941, 942).

[0253] When an O-CU / O-DU-equipped satellite loses connection with the NTN gateway, the UPF of the O-CU / O-DU-equipped satellite stores data transmitted and received with the UE, and when it reconnects with the NTN gateway, it can transmit the data to the DN on the ground.

[0254] If the N4, N6 interfaces are extended to support multi-hop, and N4, N6 interface transport via ISL between satellites is supported (N4 over ISL, N6 over ISL), and there is no NTN gateway within the communication range of satellite group A (920), the UPF of the O-CU / O-DU-equipped satellite (921) of satellite group A (920) can be connected to the ground-based data network via multi-hop through the UPF of the O-CU / O-DU-equipped satellite (931) of satellite group B (930), and can continuously provide services to the UE without store and forward operation.

[0255] Figure 10a is a conceptual diagram of a case where satellites are functionally divided according to a third embodiment that is a mixture of the first and second embodiments in NTN.

[0256] Referring to FIG. 10a, satellite group A (1020) and satellite group B (1030) are illustrated as examples. Satellite group A (1020) may include an O-DU-equipped satellite (1021) and O-RU-equipped satellites (1022, 1023), and satellite group B (1030) may include an O-CU / O-DU-equipped satellite (1031) and O-RU-equipped satellites (1032, 1033). In the example of FIG. 10a, as in FIGS. 8a and 9a described above, satellite group A (1020) is illustrated as including two O-RU-equipped satellites (1022, 1023), and satellite group B (1030) is also illustrated as including two O-RU-equipped satellites (1032, 1033). However, the number of O-RU-equipped satellites included in each satellite group is only an example to help understanding of the present disclosure, and the number of O-RU-equipped satellites included in one satellite group is not limited to two.

[0257] O-RU-equipped satellites (1022, 1023) included in satellite group A (1020) can perform wireless communication with UEs (1001, 1002, 1003) via an NR Uu interface, and O-RU-equipped satellites (1032, 1033) included in satellite group B (1030) can also perform wireless communication with UEs (1004, 1005, 1006) via an NR Uu interface.

[0258] Satellite group A (1020) having an O-DU-equipped satellite (1021) and O-RU-equipped satellites (1022, 1023) may be in the form described above in FIG. 8a, and satellite group B (1030) including an O-CU / O-DU-equipped satellite (1031) and O-RU-equipped satellites (1032, 1033) may be in the form described above in FIG. 9a.

[0259] As illustrated in FIG. 10a, an O-DU-equipped satellite (1021) of satellite group A (1020) can be connected to the TN through an O-CU / O-DU-equipped satellite (1031) of satellite group B (1030) via the F1 interface (F1 over ISL) even at a location where it cannot be directly connected to the NTN gateway.

[0260] In the embodiment of Fig. 10a, one satellite group may be composed of satellites equipped with O-DU and satellites equipped with only O-RU, and another satellite group may be composed of satellites equipped with O-CU / O-DU and satellites equipped with O-RU. In other words, satellite group A (1020) may be a case where LLS is applied between an O-DU satellite (1021) and O-RU satellites (1022, 1023), and satellite group B (1030) may be a case where LLS is applied between an O-CU / O-DU satellite (1031) and O-RU satellites (1032, 1033).

[0261] The O-DU-equipped satellite (1021) of satellite group A (1020) can be controlled by the near real-time RIC of satellite group B (1030) using the E2 interface via ISL. If faster control is required, the O-DU-equipped satellite (1021) of satellite group A (1020) can be configured to be equipped with a local xApp. When the O-DU-equipped satellite (1021) of satellite group A (1020) is configured to be equipped with a local xApp, the local xApp can control operations such as channel information updates for MIMO or beamforming, handover optimization, wireless link monitoring, wireless resource management, mobility management, load balancing, slicing policy updates, traffic steering, interference management, and security in real time (or near real time) on the O-DU-equipped satellite (1021). Each of the O-RUs (1022, 1023) included in satellite group A (1020) can be connected to an O-DU (1021) via an ISL and can communicate with at least one of the UEs (1001, 1002, 1003) via an NR Uu interface. The O-DU-equipped satellite (1021) of satellite group A (1020) can be connected to a ground-based NTN gateway (1042) via an O-CU / O-DU-equipped satellite (1031) of satellite group B (1030).

[0262] The O-CU / O-DU-equipped satellite (1031) of satellite group B (1030) can be connected to the NTN gateway (1042) via SRI. The O-CU / O-DU-equipped satellite (1031) can be connected to O-RUs (1032, 1033) using ISL, and each of the O-RUs (1032, 1033) can communicate with at least one of the UEs (1004, 1005, 1006) via the NR Uu interface.

[0263] FIG. 10b is a conceptual diagram illustrating the configuration of an NTN gateway and an RIC and SMO of an O-RAN connected to a satellite in an NTN according to a third embodiment of the present disclosure.

[0264] It should be noted that FIGS. 10A and 10B may be connected drawings, and are configured separately as FIGS. 10A and 10B due to limitations of the drawings. In the example of FIG. 10A, the near-real-time RIC may be mounted on an O-CU / O-DU-equipped satellite (1031) within satellite group B (1030), and an O-DU-equipped satellite (1021) within satellite group A (1020) may be controlled by the near-real-time RIC via the O-CU / O-DU-equipped satellite (1031), or may be equipped with a local xApp for control operations.

[0265] For the same reason, the ground in Figure 10b may not include a near-real-time RIC. Additional near-real-time RICs may be included on the ground to accommodate cases where a particular satellite group has difficulty connecting via ISL or has a delay greater than that of a ground-based RIC.

[0266] Referring to FIG. 10B, a gateway (1042) may be connected to an SMO (1060) including a non-real-time RIC. The non-real-time RIC may perform RAN policy management, RAN analysis, etc. as described above, and may provide a machine learning training model to the near-real-time RIC via the A1 interface. Since the near-real-time RIC is mounted on an O-CU / O-DU-equipped satellite (1031) of satellite group B (1030), the non-real-time RIC (1060) may transmit information (or data) to the O-CU / O-DU-equipped satellite (1031) via the A1 interface via the NTN gateway (1042) (A1 over SRI).

[0267] The SMO (1060) can manage near real-time RIC, O-CU, O-DU, O-RU, etc. using the management interface (O1) for managing O-RAN components. The near real-time RIC, O-CU, O-DU, O-RU can be mounted on a satellite as described in Fig. 9a. When the near real-time RIC, O-CU, O-DU, O-RU are mounted on a satellite, the SMO (1060) can transmit information (or data) for management to the O-CU / O-DU-mounted satellite (1031) and the O-DU-mounted satellite (1021) via the NTN gateway (1042) (O1 over SRI).

[0268] Additionally, if the SMO (1060) directly manages the O-RU, it can transport the M-Plane interface of Open Fronthaul to the O-RU via the NTN gateway, SRI, and O-DU in a similar manner to the O1 interface above (using Open Fronthaul M-Plane over SRI).

[0269] Meanwhile, user data transmitted by at least one UE using NTN can be transmitted to CN (1050) through a gateway, and user data transmitted from CN (1050) to UE can be transmitted to the corresponding satellite of NTN through the gateway and delivered to UE.

[0270] FIG. 10c is a conceptual diagram of a third embodiment in which the first and second embodiments are combined in an NTN, with satellites having their functions divided and a user plane function as part of the core network added.

[0271] Fig. 10c may be a configuration in which a UPF, which is part of the CN, is added to the O-CU / O-DU satellite in the structure of Fig. 10a described above. Therefore, Fig. 10c and Fig. 10b may be connected drawings, but it should be noted that they are configured separately as Fig. 10c and Fig. 10b due to drawing limitations.

[0272] Referring to FIG. 10c, a satellite (1031) equipped with an O-CU / O-DU of a satellite cluster (1030) is equipped with a UPF, and the specific details of the satellite cluster (1030) are the same as those of one satellite cluster of FIG. 9a, so a description thereof is omitted.

[0273] In FIG. 10c, when the O-DU satellite (1021) of the satellite cluster (1020) cannot be connected to the ground gateway, the O-DU satellite (1021) of the satellite cluster (1020) can be connected to a device performing an O-CU function mounted on the O-CU / O-DU satellite (1031) of the satellite cluster (1030) via the F1 interface, and the UPF mounted on the O-CU / O-DU satellite (1031) can perform an operation for an MEC service or a store-and-forward service.

[0274] FIG. 11a is a conceptual diagram of a case where only the upper layer division of O-RAN is used in NTN according to the fourth embodiment of the present disclosure.

[0275] Before referring to FIG. 11a, if only high-layer split (HLS) is used in O-RAN, it can be split into O-CU and O-DU / O-RU. In other words, since LLS is not used, O-DU / O-RU may not be split. If HLS is applied to NTN, it can be composed of O-CU-equipped satellites and O-DU / O-RU-equipped satellites. Since LLS is not used between satellites, HLS has the advantage of easing fronthaul capacity requirements, delay requirements, and visibility requirements compared to when LLS is used. However, since most satellites must be composed of O-DU / O-RU-equipped satellites when only HLS is used, compared to the case where most satellites are composed of O-RU-equipped satellites when LLS is used, this may result in increased satellite payload development costs, increased satellite complexity, and increased satellite power consumption.

[0276] Referring to FIG. 11a, each of satellite group A (1120) and satellite group B (1130) may include two or more satellites. More specifically, satellite group A (1120) may include one O-CU-equipped satellite (1021) and one or more O-DU / O-RU-equipped satellite(s). In the example of FIG. 11a, satellite group A (1020) is exemplified as including two O-DU / O-RU-equipped satellites (1122, 1123). Satellite group B (1130) may also include one O-CU-equipped satellite (1131) and one or more O-DU / O-RU-equipped satellite(s). In the example of FIG. 11a, satellite group B (1130) is exemplified as including two O-DU / O-RU-equipped satellites (1132, 1133). However, the number of O-DU / O-RU-equipped satellites included in each satellite group is only an example to help understanding of the present disclosure, and the number of O-DU / O-RU-equipped satellites included in one satellite group is not limited to two.

[0277] The interface between the ground network and the O-CU-equipped satellite (1121 or 1131) can use NG over SRI. The example of Fig. 11a shows that HLS is applied in NTN, and the F1 interface on the ISL can be used between the O-CU-equipped satellites (1121, 1131) and the O-DU / O-RU-equipped satellites (1122, 1123, 1132, 1133). In other words, it can be a structure in which HLS is applied to divide a complex satellite function into an O-CU-equipped satellite and multiple O-DU / O-RU-equipped satellites.

[0278] Each of the O-CU-equipped satellites (1121, 1131) in each of the satellite groups can be viewed as a master satellite (or leader satellite), and multiple O-DU / O-RU-equipped satellites (1122, 1123, 1232, 1234) connected to each of the O-CU-equipped satellites (1121, 1131) can be viewed as slave satellites (or follower satellites). Each of the O-CU-equipped satellite and the one or more O-DU / O-RU-equipped satellite(s) connected to the O-CU-equipped satellite can be viewed as a satellite group (or satellite cluster). Since a satellite group cooperates to perform the role of a base station, the satellites within a satellite group must always move together.

[0279] The NG interface using SRI (NG over SRI) originally uses a wired interface, but an NG interface resume or NT interface reset function can be added to the NG interface so that the NG interface can be reconnected even if the O-CU satellite connected to the ground NTN gateway (1141, 1142) in the wireless link is changed.

[0280] Since the NG interface does not support multi-hop, an O-CU-equipped satellite that is more than two hops away must connect to another NTN gateway within its own communication range. In other words, as illustrated in FIG. 11a, satellite groups A (1120) and B satellites (1130) must each connect to different NTN gateways (1141, 1142) within their communication range. If the NG interface is extended to support multi-hop and there is no NTN gateway within the communication range of the O-CU-equipped satellite (1121) of satellite group A (1120), the O-CU-equipped satellite (1121) can communicate with the TN by connecting to the NTN gateway (1142) via the O-CU-equipped satellite (1131) of satellite group B (1130). When an O-CU-equipped satellite (1121) communicates with a TN by connecting to an NTN gateway (1142) in a multi-hop manner through an O-CU-equipped satellite (1131) of satellite group B (1130), a multi-hop connection between different O-CU satellites can be established using the NG interface (NG over ISL) through the newly defined ISL.

[0281] Connections between O-CU-equipped satellites and O-DU / O-RU-equipped satellites can be made via the F1 interface (F1 over ISL). Since the F1 interface can support wireless connections, it can support inter-satellite connections using ISL.

[0282] In current satellite communications, the trend is toward satellite clusters, which utilize multiple, simple, small satellites to perform a single mission, rather than a single, complex satellite. This trend allows satellites within a satellite cluster to fly in formation, communicate with other satellites outside the cluster, and coordinate with each other within the cluster.

[0283] When a satellite clustering method is used, satellites within the same satellite group (or cluster) operate as a single satellite and can always move together. As illustrated in Fig. 11a, communication efficiency can be improved when using HLS between O-CU-equipped satellites (1121, 1131) and O-DU / O-RU-equipped satellites (1122, 1123, 1132, 1133) within each satellite group.

[0284] Communication between satellite groups can be achieved through a communication link between O-CU-equipped satellites (1121, 1131). In other words, communication between satellite groups can use the Xn interface over ISL (Xn over ISL). When the Xn interface over ISL is used, direct communication between O-CU-equipped satellites belonging to two different groups can be achieved without communication with the ground when communicating for cooperation between the two satellite groups. For example, when a ground UE hands over to another satellite group (i.e., another O-CU-equipped satellite), information exchange between the source O-CU-equipped satellite and the target O-CU-equipped satellite may be required. When the UE hands over between different satellite groups, information exchange for the handover of the UE between the source O-CU-equipped satellite and the target O-CU-equipped satellite can be performed through the Xn interface over ISL (Xn over ISL). In other words, information exchange for UE handover can be performed only through communication between a source O-CU-equipped satellite and a target O-CU-equipped satellite without separate communication via TN.

[0285] Each of the O-CU-equipped satellites (1121, 1131) that serve as a master may be equipped with only the O-CU function, or may be equipped with not only the O-CU but also the O-DU / O-RU. If each of the O-CU-equipped satellites (1121, 1131) that serve as a master is equipped with the O-DU / O-RU, the following description refers to a satellite having a local O-DU / O-RU. A satellite having a local O-DU / O-RU performs the master role and includes the O-DU / O-RU function, so it can provide specific ground coverage. Since the local O-DU / O-RU can provide ground coverage, it can have the effect of expanding satellite coverage.

[0286] The fourth embodiment illustrated in Fig. 11a uses a satellite equipped with an O-CU, and thus, compared to the first embodiment where the O-CU is on the ground, the complexity of the satellite may increase. However, when performing the RRC protocol between the satellite and the UE, the first embodiment has the problem of increased RRC delay because communication must be made from the satellite to the O-CU located in the TN. On the other hand, the fourth embodiment illustrated in Fig. 11a has the advantage of a shorter RRC delay because the O-CU is mounted on the satellite.

[0287] In contrast to the fourth embodiment, where each satellite carries a complex full base station (full gNB), the satellite structure of the fourth embodiment, which uses multiple small satellites to divide functions in the NTN, has the advantage of expanding the coverage per base station compared to a single satellite carrying a full gNB, because one or more O-DU / O-RU-mounted satellites provide additional coverage.

[0288] Meanwhile, referring to FIG. 11a, each of the O-CU-equipped satellites (1121, 1131) may further include a near-real-time RIC. The near-real-time RIC mounted on each of the O-CU-equipped satellites (1121, 1131) may control the O-DU and the O-CU. Since the control loop time requirement of the near-real-time RIC may be 10 ms or more and less than 1 second, mounting the near-real-time RIC on the O-CU-equipped satellite may be more efficient than positioning it on the ground.

[0289] FIG. 11b is a conceptual diagram illustrating the configuration of an NTN gateway and an O-RAN RIC and SMO when only the upper layer division of an O-RAN is used in an NTN according to the fourth embodiment of the present disclosure.

[0290] It should be noted that FIGS. 11A and 11B may be connected drawings, and are configured separately as FIGS. 11A and 11B due to limitations of the drawings. Referring to FIG. 11B, a gateway (1142) may be connected to an SMO (1160) including a non-real-time RIC. The non-real-time RIC may perform RAN policy management, RAN analysis, etc. as described above, and may provide a machine learning training model to the near-real-time RIC via the A1 interface. Since the near-real-time RIC is mounted on each of the O-CU-equipped satellite (1131) of satellite group B (1130) and the O-CU-equipped satellite (1121) of satellite group A (1120), the non-real-time RIC (1160) may transport the A1 interface to the near-real-time RIC using the NTN gateway (1142) and the SRI (A1 over SRI).

[0291] The near real-time RIC mounted on an O-CU-equipped satellite (1121) within satellite group A (1121) and the near real-time RIC mounted on an O-CU-equipped satellite (1131) within satellite group B (1131) may be connected to different NTN gateways (1141, 1142), respectively. Each of the different NTN gateways (1141, 1142) may be connected to a non-real-time RIC (1160) on the ground. If the A1 interface is extended to support multi-hop and the A1 interface (A1 over ISL) is supported over ISL between satellites, and there is no NTN gateway within the communication range of satellite group A (1120), the near real-time RIC mounted on an O-CU-equipped satellite (1121) in satellite group A (1121) may be connected to a terrestrial non-real-time RIC (1160) in multi-hop via an O-CU-equipped satellite (1131) in satellite group B (1130).

[0292] The near real-time RIC can perform real-time (or near real-time) radio resource management functions based on policies and training models received from the non-real-time RIC via the A1 interface, and control the O-CU-equipped satellites and O-DU / O-RU-equipped satellites.

[0293] Each of the O-CU / Near Real-Time RIC-equipped satellites (1121, 1131) can transmit and receive information (or data) to the O-DU / O-RU-equipped satellites (1122, 1123, 1132, 1134) within the same satellite group using the E2 interface over ISL, thereby allowing the O-DU / O-RU-equipped satellites (1122, 1123, 1132, 1134) to be managed by the Near Real-Time RIC.

[0294] The SMO (1160) can manage near real-time RIC, O-CU, O-DU, O-RU, etc. using the management interface (O1) for managing O-RAN components. The near real-time RIC, O-CU, O-DU, O-RU can be mounted on a satellite as described in FIG. 11a. When the near real-time RIC, O-CU, O-DU, and O-RU are mounted on a satellite, the SMO (1160) transmits information (or data) for management to the O-CU, O-DU, and near real-time RIC mounted on the O-CU-mounted satellite and the O-DU / R-DU-mounted satellites using the O1 interface, and can also transmit it to the O-RU-mounted satellites. The O1 interface can be transported to the O-CU satellite and the O-DU / O-RU satellite through the NTN gateway and the SRI (O1 over SRI).

[0295] Additionally, if SMO (1160) directly manages O-RU, it can transport the M-Plane interface of Open Fronthaul to O-DU / O-RU satellite via NTN gateway and SRI in a similar manner to the O1 interface above (using Open Fronthaul M-Plane over SRI).

[0296] Satellite group A (1120) and satellite group B (1130) can be connected to different NTN gateways, and can be connected to the ground SMO (1160) through different gateways (using O1 over SRI). If the O1 interface is extended to support multi-hop and can support the O1 interface (O1 over ISL) through the ISL between satellite groups, if there is no NTN gateway within the communication range of the O-CU-equipped satellite (1121) of satellite group A (1120), the O-CU-equipped satellite (1121) can also be connected to the ground SMO (1160) through multi-hops through the O-CU-equipped satellite (1131) of satellite group B (1130). The O1 interface can be transferred between O-CU-equipped satellites and O-DU / O-RU-equipped satellites within the same satellite group using ISL (O1 over ISL).

[0297] When supporting RAN virtualization via the O-Cloud, RAN hardware and software can be separated for near-real-time RICs, O-CUs, O-DUs / O-RUs, and other components within the open RAN architecture. Each of these separated RAN hardware and software components can be sourced and used from different vendors. While O-RUs are mostly implemented in hardware and typically do not utilize the O-Cloud, the software portion of the O-RU can be configured to support virtualization via the O-Cloud.

[0298] Satellites support virtualization, and components mounted on the satellite, such as O-CU, O-DU / O-RU, near real-time RIC, and O-RU, can use the satellite's O-cloud as a virtualization environment. The SMO (1160) can manage the O-cloud through the O2 interface. When the O-CU, O-DU / O-RU, and near real-time RIC are mounted on the satellite, the SMO (1160) can transmit information (or data) for management using the O2 interface, and the SMO (1160) can transport the O2 interface to the O-CU-mounted satellite and the O-DU / O-RU-mounted satellite through the NTN gateway and SRI (using O2 over SRI).

[0299] The satellites included in each of satellite group A (1120) and satellite group B (1130) can be connected to different NTN gateways (1141, 1142) for each group, and can be connected to the ground SMO (1160) through the different NTN gateways (1141, 1142) (using O2 over SRI). If the O2 interface is extended to support multi-hop and the O2 interface between satellite groups is supported to be transmitted through ISL (O2 over ISL), even if there is no NTN gateway within the communication range of the O-CU-equipped satellite (1121) of satellite group A (1120), it can be connected to the ground SMO (1160) through multi-hops through the O-CU-equipped satellite (1131) of satellite group B (1130). O2 interface can be transmitted between O-CU-equipped satellites and O-DU / O-RU-equipped satellites within the same satellite group using ISL (O2 over ISL).

[0300] Meanwhile, user data transmitted by at least one UE using NTN can be transmitted to CN (1050) through a gateway, and user data transmitted from CN (1050) to UE can be transmitted to the corresponding satellite of NTN through the gateway and delivered to UE.

[0301] FIG. 11c is a conceptual diagram of a case where only the upper layer division of O-RAN is used in NTN according to the fourth embodiment of the present disclosure and user plane functions as part of the core network are added to O-CUs.

[0302] Figure 11c may be a configuration that further adds a UPF, which is part of the CN, to the structure of Figure 11a described above, to the O-CU satellite. Therefore, Figures 11ca and 11b may be connected drawings, but it should be noted that Figures 11a and 11b were separated due to drawing limitations.

[0303] Referring to Fig. 11c, each of the satellites (1121, 1131) equipped with an O-CU may be equipped with a UPF. In the case where each of the satellites (1121, 1131) equipped with an O-CU in Fig. 11c is equipped with a UPF and an application server, even if the user data is not transmitted to the ground, the satellite's UPF and application server can process it, thereby reducing the user data processing time. In other words, the satellite's MEC may become possible.

[0304] If the application server is not installed on each of the satellites (1121, 1131) equipped with the O-CU, even if the UPF is on the satellite, the UPF must be connected to the ground data network for user data to be processed, and the data must be processed by the application server located on the ground. However, if the UPF is mounted on the satellite, even if the satellite is disconnected from the NTN gateway, the UE data can be temporarily stored in the UPF and then sent to the ground for processing when the NTN gateway is reconnected. In other words, a store-and-forward service becomes possible, and the service can be continued even if the connection with the ground is lost.

[0305] In the case of Fig. 9c, the UPF is mounted on the O-CU / O-DU satellite, and in the case of Fig. 11c, the UPF is mounted on the O-CU satellite. The details are similar to those of Fig. 9c, so a detailed description is omitted.

[0306] Even in the case of Fig. 11c, the UPF mounted on the O-CU satellite (1121, 1131) can perform operations for MEC service or store-and-forward service.

[0307] FIG. 12a is a conceptual diagram of a case in which upper layer division of O-RAN is applied in NTN according to the fifth embodiment of the present disclosure and a satellite group without an O-CU-equipped satellite is present.

[0308] Referring to FIG. 12a, two satellite groups are illustrated. Satellite group A (1220) may include an O-DU-equipped satellite (1221) and O-DU / O-RU-equipped satellites (1222, 1223), and satellite group B (1230) may include an O-CU-equipped satellite (1231) and O-DU / O-RU-equipped satellites (1232, 1233). In the example of FIG. 12a, satellite group A (1220) is illustrated as including two O-DU / O-RU-equipped satellites (1222, 1223), and satellite group B (1230) is illustrated as including two O-DU / O-RU-equipped satellites (1232, 1233). The number of O-DU / O-RU-equipped satellites included in each of the satellite groups illustrated in FIG. 12a is merely an example to help understanding of the present disclosure, and the number of O-RU-equipped satellites included in one satellite group is not limited to two.

[0309] O-DU / O-RU-equipped satellites (1222, 1223) included in satellite group A (1220) can perform wireless communication with UEs (1201, 1202, 1203) via an NR Uu interface, and O-DU / O-RU-equipped satellites (1232, 1233) included in satellite group B (1230) can also perform wireless communication with UEs (1204, 1205, 1206) via an NR Uu interface.

[0310] Satellites included in satellite group A (1220) may not be equipped with an O-CU. The master satellite (1221) of satellite group A (1220) may be a satellite equipped with only an O-DU or a satellite equipped with an O-DU / O-RU. Other satellites (1222, 1222) included in satellite group A (1220) may be slave satellites equipped with an O-DU / O-RU.

[0311] Among the satellites included in satellite group B (1230), the master satellite (1231) may be an O-CU-equipped satellite, and other satellites (1232, 1233) included in satellite group B (1230) may be slave satellites including O-DU / O-RU. The satellites included in satellite group B (1230) may have the same configuration as one of the satellite groups (1120, 1130) described in the fourth embodiment above.

[0312] As illustrated in Figure 12a, communication between master satellites in satellite groups can utilize the F1 interface over ISL. Furthermore, communication between satellites within a satellite group can also utilize the F1 interface over ISL.

[0313] The NTN structure illustrated in Fig. 12a may be a structure that uses only HLS. Since satellite group A (1220) does not have a separate O-CU-equipped satellite, the O-DU-equipped satellite (1221), which is the master satellite of satellite group A (1220), can be connected to the O-CU-equipped satellite (1231) of satellite group B (1230) via the F1 interface (F1 over ISL) through the ISL. The O-DU-equipped satellite (1221) of satellite group A (1220) can be connected to the TN through the NTN gateway (1242) to which the O-CU-equipped satellite (1231) of satellite group B (1230) can connect via the F1 interface over the ISL. Therefore, it is possible to avoid having multiple O-CU-equipped satellites, and NTN coverage expansion can be facilitated.

[0314] FIG. 12b is a conceptual diagram illustrating the configuration of an NTN gateway and an O-RAN RIC and an SMO when an upper layer partition of an O-RAN is applied in an NTN according to a fifth embodiment of the present disclosure and there is a satellite group without an O-CU-equipped satellite.

[0315] It should be noted that FIGS. 12A and 12B may be connected drawings, and are configured separately as FIGS. 12A and 12B due to limitations of the drawings. Referring to FIG. 12B, a gateway (1242) may be connected to an SMO (1260) including a non-real-time RIC. The non-real-time RIC may perform RAN policy management, RAN analysis, etc. as described above, and may provide a machine learning training model to the near-real-time RIC via the A1 interface. The near-real-time RIC may be mounted on an O-CU-equipped satellite (1231) of satellite group B (1230). Additionally, as described in FIG. 12A, an O-DU-equipped satellite (1221) of satellite group A (1120) may be equipped with a local xApp and run instead of a near-real-time RIC.

[0316] The non-real-time RIC (1260) can transmit control information through the A1 interface (1271), and the A1 interface (1271) can be transported to the near-real-time RIC of the O-CU-equipped satellite (1231) through the NTN gateway (1242) and SRI (A1 over SRI).

[0317] The SMO (1260) can manage near real-time RIC, O-CU, O-DU, O-RU, etc. using the management interface (O1) for managing O-RAN components. The near real-time RIC, O-CU, O-DU, O-RU can be mounted on a satellite as described in FIG. 12a. When the SMO (1260) manages the O-RU, the M-Plane interface of the Open Fronthaul can be used instead of the O1 interface. When the near real-time RIC, O-CU, O-DU, O-RU are mounted on a satellite, the SMO (1260) can transmit information (or data) for management to the O-CU-mounted satellite (1131) and the O-CU-mounted satellite (1121) using the O1 interface (1272) (O1 over SRI). The O1 interface (1272) can be used for transport to O-CU-equipped satellites and O-DU / O-RU-equipped satellites via the NTN gateway (1242) and SRI.

[0318] In addition, when the SMO (1260) directly manages the O-RU, the M-Plane interface (1272) of the Open Fronthaul can be transported to the O-DU / O-RU satellite via the NTN gateway, SRI, and O-CU in a similar form to the O1 (1272) interface above (using Open Fronthaul M-Plane over SRI and Open Fronthaul over ISL within the satellite cluster). Virtualization is supported on the satellite, and components mounted on the satellite, such as the O-CU, O-DU, O-RU, and near real-time RIC, can use the satellite's O-cloud as a virtualization environment. The SMO (1260) can manage the O-cloud through the O2 interface (1271). When an O-CU, O-DU, O-RU, or near-real-time RIC is mounted on a satellite, the SMO (1260) can transmit information (or data) for management using the O2 interface, and the SMO (1260) can transport the O2 interface to an O-CU-mounted satellite (1231) and O-DU / O-RU-mounted satellites (1221, 1222, 1223, 1232, 1233) via the NTN gateway and SRI (using O2 over SRI). The transported O2 interface is delivered to each O-CU, O-DU, O-RU, or near-real-time RIC mounted on the satellite.

[0319] Meanwhile, user data transmitted by at least one UE using NTN can be transmitted to CN (1050) through a gateway, and user data transmitted from CN (1050) to UE can be transmitted to the corresponding satellite of NTN through the gateway and delivered to UE.

[0320] The O-DU-equipped satellites (1221, 1222, 1223) of satellite group A (1220) described above in FIG. 12a can be controlled by the near-real-time RIC mounted on the O-CU-equipped satellite (1231) of satellite group B (1230). The near-real-time RIC mounted on the O-CU-equipped satellite (1231) can transport the E2 interface (E2 over ISL) to the O-DU-equipped satellites (1221, 1222, 1223) via the ISL. If faster control is required for the O-DU-equipped satellites (1221, 1222, 1223) of satellite group A (1220), a local xAPP may be mounted on the O-DU-equipped satellite (1221), which is the master satellite of satellite group A (1221), and / or on all O-DU-equipped satellites (1221, 1222, 1223). The local xApp may control the O-DU-equipped satellites (1221, 1222, 1223) of satellite group A (1221) in real time (or close to real time).

[0321] FIG. 12c is a conceptual diagram of a case where, according to the fifth embodiment of the present disclosure, upper layer division of O-RAN is applied in NTN, and a UFP, which is part of a CN, is added to an O-CU-equipped satellite when there is a satellite group without an O-CU-equipped satellite and a satellite group with an O-CU-equipped satellite.

[0322] Figure 12c may be a configuration that further adds a UPF, which is part of the CN, to the O-CU satellite structure of Figure 12a described above. Therefore, Figures 12c and 12b may be connected drawings, but it should be noted that Figures 12c and 12b were separated due to drawing limitations.

[0323] Referring to FIG. 12c, it may be the case that an O-CU-equipped satellite (1231) of satellite group B (1230) is further equipped with a UPF. If the O-CU-equipped satellite (1231) is equipped with a UPF, MEC and store and forward operations may become possible for the corresponding cluster (e.g., satellite group B1230).

[0324] In the case of Fig. 10c described above, the O-CU / O-DU satellite may be equipped with a UPF, and in the case of Fig. 12c, the O-CU satellite may be equipped with a UPF. The details of Fig. 12c are similar to those of Fig. 10c described above, so a detailed description is omitted.

[0325] When the O-DU satellite (1221) of the satellite cluster (1220) cannot be connected to the ground gateway, the O-DU satellite (1221) of the satellite cluster (1220) can be connected to the O-CU satellite (1231) of the satellite cluster (1230) via the F1 interface, and can receive the MEC service or the store-and-forward service using the UPF mounted on the O-CU satellite (1231) of the satellite cluster (1230).

[0326] [Method for supporting LLS on satellites using ISL]

[0327] When supporting LLS, the fronthaul must be capable of supporting 50 to 80 Gbps. To utilize fronthaul in NTN, a wireless interface must be used. Since typical radio frequency (RF) interfaces cannot support fronthaul capacity, wireless interfaces can only support HLS.

[0328] In this disclosure, laser-based FSO ISL can be used for inter-satellite fronthaul in NTN. Laser-based ISL is expected to support up to 100 Gbps, enabling the capacity needed to support LLS. As previously explained, data transmission rates using lasers in the vacuum of space are approximately 50% faster than those of optical cables. Therefore, achieving lower latency than fronthaul using optical cables on the ground is possible.

[0329] The biggest challenge for using fronthaul in NTN may be ISL connectivity. In O-RAN, fronthaul assumes a wired cable connection, which does not support mobility between the O-DU and O-RU. Conversely, the O-DU and O-RU satellites must always be visible to each other to maintain the ISL link. If the ISL link is lost, it can take several seconds to reestablish the ISL link, potentially leading to problems with the fronthaul connection. To address this issue, the O-DU and O-RU satellites that make up a satellite cluster may need to move in the same or adjacent orbital planes to maintain the ISL link.

[0330] The present disclosure described below describes a method for satisfying the conditions for an ISL link to be maintained continuously.

[0331] Figure 13a is a conceptual diagram illustrating a fronthaul connection method via an ISL link in NTN.

[0332] Referring to FIG. 13a, reference numeral 1300 may be an example of a drawing showing satellites orbiting the Earth in an orbit having a certain altitude from the Earth's surface as dots, and reference numeral 1301 may be a drawing showing an enlarged portion of the Earth and satellites orbiting in an orbit having a certain altitude from the Earth's surface.

[0333] The first satellite (1311) can orbit in an upward-facing diagonal direction (1321) at a constant altitude from the Earth's surface. The second satellite (1312) and the third satellite (1313), which have the same orbital plane as the first satellite (1311), can have the same altitude as the first satellite (1311). Reference numerals 1322 and 1323 can be directions of satellites orbiting in the same direction as the upward-facing diagonal direction (1321) of the first satellite (1311) to the third satellite (1313). More specifically, the upward-slanting direction of reference number 1322 may be the closest orbit among satellites having an orbit closer to the North Pole than the orbit of the first satellite (1311) based on the northern half of the Earth, and the upward-slanting direction of reference number 1323 may be the closest orbit among satellites having an orbit closer to the equator than the orbit of the first satellite (1311) based on the northern half of the Earth.

[0334] The distance between the second satellite (1312) and the third satellite (1313), which orbit in the same orbital plane as the first satellite (1311), may be constant. In addition, satellites on other parallel oblique lines (1322, 1323) adjacent to the upward-facing oblique direction (1321) may orbit on the Earth while orbiting in adjacent orbital planes. Therefore, the first satellite (1311) may easily maintain an ISL link connection with satellites on other adjacent parallel oblique lines (1322, 1323).

[0335] Meanwhile, the satellite (1330) whose orbit is opposite to that of the first satellite (1311) or whose orbit is diagonally upward to the left cannot be grouped as a single satellite group because the ISL link is temporarily connected and disconnected. It should be noted that in Fig. 13, satellites orbiting the Earth in an upward to the left direction are not hatched, while satellites orbiting the Earth in an upward to the right direction are hatched to enable their identification.

[0336] In order to support the LLS functional division structure in a satellite according to the present disclosure, satellites orbiting the Earth in the same direction within reference numeral 1310 may be configured as one satellite group. In other words, a first satellite (1311), a second satellite (1312), a third satellite (1313), a fourth satellite (1314), and a fifth satellite (1315) may configure one satellite group (1310). The first satellite (1311) may form an ISL with satellites (1312, 1313) immediately preceding and following it in the same orbital plane, and may form an ISL with two satellites (1314, 1350) in adjacent orbital planes.

[0337] Among the satellites within a satellite group (1310), the first satellite (1311) may be a master satellite (O-DU satellite), and the satellites (1312, 1313, 1314, 1315) in the same or adjacent orbital planes may be slave satellites (O-RU satellites). From the perspective of the first satellite (1311), the adjacent satellites (1312, 1313, 1314, 1315) are always visible, so that the fronthaul operation can continue while maintaining the ISL.

[0338] As previously described, satellite clusters (or satellite groups) that perform a single mission using multiple, low-cost, small satellites instead of complex, expensive, large satellites may be suitable for an O-RAN-based NTN architecture. A satellite cluster may include multiple small satellites, which can operate as a single, large satellite. Inter-satellite Link (ISL) can be used for communication between satellites within a cluster or between clusters. Multiple satellites within a cluster can transmit and receive signals as if they were a single satellite. A satellite cluster may consist of a single, high-performance, complex satellite (i.e., a master satellite) and multiple, simple slave satellites. In a satellite cluster architecture, the distance between satellites is typically several kilometers to several hundred kilometers, much closer than in typical satellite communication environments, which can satisfy fronthaul capacity and latency requirements.

[0339] As illustrated in Figure 13a, satellites within a cluster always move together (at the same speed and in the same direction), and the close distance between satellites ensures accurate laser ISL beam pointing. The NTN architecture, which utilizes O-RAN, can be applied directly to satellite clusters.

[0340] Figure 13b is a conceptual diagram of a case where a circular cluster is formed using formation flight based on a circular orbit projected from NTN.

[0341] As illustrated in Fig. 13b, a cluster configuration using formation flying based on a projected circular orbit (PCO) of satellites may be one method for efficiently supporting a satellite cluster.

[0342] The method illustrated in FIG. 13b is a method of configuring the orbit of the follower satellite (1342) using the orbit of the leader satellite (1341) as a reference orbit. The orbit of the follower satellite (1342) is set to have a slightly different orbital inclination and eccentricity from the orbit of the leader satellite (1341). In this case, when the orbits of the leader satellite (1341) and the follower satellite (1342) orbiting the Earth are projected onto the Earth's surface, it appears as if the follower satellite (1342) is orbiting the leader satellite (1341) in a circular shape, as shown by reference numeral 1343. This orbit is referred to as 'PCO'. The orbital inclination described above refers to the angle that the orbital plane of the satellite makes with the Earth's equatorial plane, and the eccentricity refers to a value indicating how much the elliptical shape of the orbit is distorted.

[0343] The form illustrated on the left in Fig. 13b is a conceptual diagram for a case where one leader satellite (1341) and one follower satellite (1342) form a cluster. In the case where there are multiple follower satellites (1352a, 1352b, 1352c, 1352d) with orbital inclinations and eccentricities slightly different from those of the leader satellite (1351), a circular cluster can be formed with multiple follower satellites (1352a, 1352b, 1352c, 1352d) as shown on the right in Fig. 13b.

[0344] As illustrated in Fig. 13b, when forming a cluster based on PCO formation flight, the distance between the leader satellite and the follower satellites can be reduced from several kilometers to several hundred kilometers, which helps reduce fronthaul delay. Furthermore, the ISL distance between the leader satellite and each follower satellite can be maintained at a nearly identical level, which facilitates transmission time synchronization between satellites during cooperative transmission using multiple satellites. Compared to the linear cluster of Fig. 13c described below, Fig. 13b has the advantage of increasing the number of satellites with the same ISL distance around the master satellite.

[0345] Figure 13c is a conceptual diagram of a case where a linear cluster is formed using track-based formation flight in NTN.

[0346] Referring to FIG. 13c below, a case of forming a cluster using along-track orbit (ATO) based formation flight is described.

[0347] In the method of forming a cluster using ATO-based formation flight as shown in FIG. 13c, a linear cluster is created by placing follower satellites (1362) at a constant distance from the leader satellite (1361) on the same orbital plane as the leader satellite (1361) using the orbit of the leader satellite (1361) as a reference orbit. In the method of FIG. 13c, there is no need to set the orbital inclination or eccentricity of the follower satellite (1362) differently, so orbit design is easy. However, since the follower satellites are arranged in a train shape around the leader satellite (1361) as exemplified by reference numeral 1370, the distance between the leader satellite (1361) and the follower satellites (1362) is not constant, so transmission time synchronization between satellites is difficult compared to a linear cluster, and it is difficult to place a large number of follower satellites at a close distance from the leader satellite (1361). On the right side of Fig. 13c, train-shaped follower satellites (1372a, 1372b, 1372c, 1372d) centered around the leader satellite (1371) are illustrated. In Fig. 13c, when the orbits of the leader satellite (1361) and the follower satellite (1362) at reference point 1 with respect to the Earth, the leader satellite (1361) and the follower satellite (1362) at reference point 2 with respect to the Earth, the leader satellite (1361) and the follower satellite (1362) at reference point 3 with respect to the Earth, and the leader satellite (1361) and the follower satellite (1362) at reference point 4 with respect to the Earth are projected onto the Earth's surface, they may have a linear arrangement shape as indicated by reference numeral 1363.

[0348] Examples such as FIGS. 13a, 13b, and 13c are examples of how to configure one cluster, and each cluster configured as in FIGS. 13a, 13b, and 13c can be connected to an inter-cluster link using an ISL to form a multi-cluster structure.

[0349] When the leader satellite and follower satellite are configured as in any one of FIGS. 13a, 13b, or 13c, the inter-cluster link is a link between satellites equipped with only O-DUs (i.e., a link between satellites equipped with HLS rather than LLS) or a link between satellites equipped with full base stations without functional division, so the capacity requirements between clusters are not as high as in the case of LLS. In addition, the delay time and synchronization requirements can be significantly relaxed compared to LLS. Therefore, a laser link (FSO) can be used for the inter-cluster link, but RF-based ISL using terahertz, millimeter waves, etc. can also be used.

[0350] To maintain connectivity between clusters, it is recommended that the leader satellites of each cluster fly in the same orbital plane. In other words, ensuring that the master satellites (e.g., O-DU satellites or O-CU / O-DU satellites) within the first and second satellite groups fly in the same orbital plane will prevent loss of connectivity between the two satellite clusters.

[0351] [How to configure a satellite cluster]

[0352] Figure 14a is a conceptual diagram according to a first embodiment for configuring a satellite cluster.

[0353] Referring to FIG. 14A, the first satellite cluster (1420A), the second satellite cluster (1420B), and the third satellite cluster (1420C) can each communicate with each other using an inter-cluster link (ICL). More specifically, the first satellite cluster (1420A) and the second satellite cluster (1420B) can communicate with each other through an ICL (1461), and the second satellite cluster (1420B) and the third satellite cluster (1420C) can also communicate with each other through an ICL (1461). The ICL connecting between clusters can apply an F1 interface (F1 over ISL) through an ISL. As another example, the ICL connecting between clusters can be a new interface defined and used for direct connection between satellites equipped with O-DUs that operate as cluster leaders.

[0354] In FIG. 14A, the satellites included in each of the satellite clusters (1420A, 1420B, and 1420C) may be low Earth orbit (LEO) satellites. In FIG. 14A, the master satellite of the second satellite cluster (1420B) may be connected to the NTN gateway via an F1 interface (F1 over SRI).

[0355] In Fig. 14a, a satellite (1425) that does not form a cluster may be a geostationary Earth orbit (GEO) satellite or a high elliptical orbit (HEO) satellite. For convenience of explanation, the following description assumes that the satellite (1425) that does not form a cluster is a GEO satellite. However, this is for convenience of explanation and should not be construed as being limited thereto. The GEO satellite (1425) may be a satellite equipped with an O-DU / O-RU and may be connected to an NTN gateway via an F1 interface (F1 over SRI) through an SRI. The NTN gateway located on the ground may be connected to an O-CU (1430). The O-CU (1430) may be connected to a CN (1440) via an NG interface. In other words, the O-CU (1430) of the satellite clusters (1420A, 1420B, 1420C) illustrated in FIG. 14A may be located on the ground, and the O-CU (1430) and the GEO satellite (1425) may be connected via an F1 interface (F1 over SRI).

[0356] UEs (1401, 1402) can communicate with at least one LEO satellite or GEO satellite (1425) belonging to satellite clusters (1420A, 1420B, 1420C) via an NR Uu interface.

[0357] FIG. 14b is a conceptual diagram illustrating a case in which satellites according to a first embodiment of a satellite cluster are formed and the satellites communicate with UEs.

[0358] Referring to FIG. 14b, a satellite cluster may include an O-DU-equipped satellite (1421) operating as a master (or leader) and O-RU-equipped satellites (1422, 1423, 1424) operating as slaves (or followers). The satellite cluster illustrated in FIG. 14b may be configured according to one embodiment of the satellite clusters (1420A, 1420B, 1420C) illustrated in FIG. 14a described above. Accordingly, the O-CUs (1430) of the satellites constituting the satellite cluster illustrated in FIG. 14b may be located on the ground.

[0359] In Fig. 14b, only three O-RU satellites (1422, 1423, 1424) are illustrated within a single satellite cluster. However, this is merely for the sake of illustration and convenience of explanation, and the number of O-RU-equipped satellites may be four, as illustrated in Fig. 13, or two, as previously described. As another extreme example, a single satellite cluster may consist of only one O-RU-equipped satellite and one O-DU-equipped satellite. In other words, the number of satellites within a satellite cluster should not be understood as being limited to four.

[0360] Each of the O-RU-equipped satellites (1422, 1423, 1424) can be connected to the O-DU-equipped satellite (1421) via an ISL through a fronthaul (FH) interface. As described above, the O-DU-equipped satellite (1421) operating as a master and the O-RU-equipped satellites (1422, 1423, 1424) operating as slaves can be formed into a single cluster and operate as a single base station. The configuration of the satellite cluster illustrated in FIG. 14b can be applied to each of the first satellite cluster (1420A), the second satellite cluster (1420B), and the third satellite cluster (1420C) illustrated in FIG. 14a.

[0361] UEs (1403, 1404, 1405, 1406) can communicate with at least one satellite belonging to O-RU-equipped LEO satellites (1422, 1423, 1424) within the satellite cluster via an NR Uu interface.

[0362] Figure 15a is a conceptual diagram according to a second embodiment for configuring a satellite cluster.

[0363] Referring to FIG. 15A, a first satellite cluster (1520A), a second satellite cluster (1520B), and a third satellite cluster (1520C) can each communicate with each other using an inter-cluster link (ICL). More specifically, the first satellite cluster (1520A) and the second satellite cluster (1520B) can communicate with each other through an ICL (1561), and the second satellite cluster (1520B) and the third satellite cluster (1520C) can also communicate with each other through an ICL (1561). The ICL connected between clusters can apply an Xn interface through ISL (Xn over ISL). As another example, a new interface for direct connection between satellites equipped with O-CU / O-DUs operating as cluster leaders can be defined and used for the ICL connected between clusters.

[0364] In FIG. 15A, the satellites included in each of the satellite clusters (1520A, 1520B, 1520C) may be LEO satellites. In FIG. 15A, the master satellite of the second satellite cluster (1520B) may be connected to the NTN gateway via an NG interface (NG over SRI).

[0365] In Fig. 15a, a satellite (1525) that does not form a cluster may be a GEO satellite or a HEO satellite. For convenience of explanation, the following description assumes that the satellite (1525) that does not form a cluster is a GEO satellite. However, this is for convenience of explanation and should not be understood as being limited thereto. The GEO satellite (1525) may be a satellite equipped with an O-CU / O-DU / O-RU and may be connected to an NTN gateway via an NG interface (NG over SRI) through an SRI. UEs (1501, 1502) may communicate with at least one LEO satellite or GEO satellite (1525) belonging to satellite clusters (1520A, 1520B, 1520C) via an NR Uu interface. Therefore, the cluster structure illustrated in Fig. 15a may be a case in which there is no O-CU on the ground.

[0366] FIG. 15b is a conceptual diagram illustrating a second embodiment of satellites forming a satellite cluster and a case in which the satellites communicate with UEs.

[0367] Referring to FIG. 15b, the satellite cluster may include an O-CU / O-DU-equipped satellite (1521) operating as a master (or leader) and O-RU-equipped satellites (1522, 1523, 1524) operating as slaves (or followers). The satellite cluster illustrated in FIG. 15b may be configured according to one embodiment of the satellite clusters (1520A, 1520B, 1520C) illustrated in FIG. 15a described above.

[0368] In Fig. 15b, only three O-RU-equipped satellites (1522, 1523, 1524) are illustrated within a single satellite cluster. However, this is merely for the sake of illustration and convenience of explanation, and the number of O-RU-equipped satellites may be four, as described in Fig. 13, or two, as described previously. As another extreme example, a single satellite cluster may consist of only one O-RU-equipped satellite and one O-CU / O-DU-equipped satellite. In other words, the number of satellites within a satellite cluster should not be understood as being limited to four.

[0369] Each of the O-RU-equipped satellites (1522, 1523, 1524) can be connected to the O-CU / O-DU-equipped satellite (1521) via an ISL through a fronthaul (FH) interface. As described above, the O-CU / O-DU-equipped satellite (1521) operating as a master and the O-RU-equipped satellites (1522, 1523, 1524) operating as slaves can be formed into a single cluster and operate as a single base station. The configuration of the satellite cluster illustrated in FIG. 15b can be applied to each of the first satellite cluster (1520A), the second satellite cluster (1520B), and the third satellite cluster (1520C) illustrated in FIG. 15a.

[0370] UEs (1503, 1504, 1505, 1506) can communicate with at least one satellite belonging to O-RU-equipped LEO satellites (1522, 1523, 1524) within the satellite cluster via an NR Uu interface.

[0371] Figure 15c is a conceptual diagram illustrating a case in which a UPF is mounted on a master satellite among satellites forming a satellite cluster according to a second embodiment.

[0372] Referring to FIG. 15c, an example is provided in which a UPF is mounted on a satellite (1521) equipped with an O-CU / O-DU operating as a master as described above in FIG. 15b.

[0373] As illustrated in Fig. 15c, when a satellite (1521) equipped with an O-CU / O-DU is equipped with a UPF and an application server, user data can be processed by the satellite's UPF and application server without being transmitted to the ground, thereby reducing the user data processing time. In other words, satellite MEC becomes possible.

[0374] If the O-CU / O-DU satellite (1521) does not have an application server, that is, if only the UPF is mounted on the O-CU / O-DU satellite (1521), the UPF must be connected to the ground data network for user data to be processed, and the data must be processed by the application server located on the ground. However, if the UPF is mounted on the satellite, even if the satellite is disconnected from the NTN gateway, the UE data can be temporarily stored in the UPF and then transmitted to the ground for processing when the satellite is reconnected to the NTN gateway. In other words, a store and forward type service becomes possible, and the service can be continued even if the connection with the ground is lost.

[0375] The detailed information corresponding to the form illustrated in FIG. 15c described above has been described in FIG. 9c, so a duplicate description is omitted. In the case of FIG. 15c, a GEO satellite (1525 in FIG. 15a) can be equipped with not only an O-CU / O-DU but also a UPF, just like a LEO satellite cluster, and an N6 interface (N6 over SRI) can be used through SRI or an N4 interface (N4 over SRI) can be used through SRI between the GEO satellite (1525) and the ground gateway (1530). The satellite cluster illustrated in FIG. 15c described above may be a configuration according to one embodiment of the satellite clusters (1520A, 1520B, 1520C) illustrated in FIG. 15a described above.

[0376] Figure 16a is a conceptual diagram according to a third embodiment for configuring a satellite cluster.

[0377] Referring to FIG. 16A, a first satellite cluster (1620A), a second satellite cluster (1620B), and a third satellite cluster (1620C) can each communicate with each other using an inter-cluster link (ICL). More specifically, the first satellite cluster (1620A) and the second satellite cluster (1620B) can communicate with each other through an ICL (1661), and the second satellite cluster (1620B) and the third satellite cluster (1620C) can also communicate with each other through an ICL (1661). The ICL connected between clusters can apply an Xn interface through ISL (Xn over ISL). As another example, a new interface for direct connection between satellites equipped with an O-CU operating as a cluster leader can be defined and used for the ICL connected between clusters.

[0378] In FIG. 16A, the satellites included in each of the satellite clusters (1620A, 1620B, 1620C) may be LEO satellites. In FIG. 16A, the master satellite of the second satellite cluster (1620B) may be connected to the NTN gateway via an NG interface (NG over SRI).

[0379] In Fig. 16a, a satellite (1625) that does not form a cluster may be a GEO satellite or a HEO satellite. For convenience of explanation, the following description assumes that the satellite (1625) that does not form a cluster is a GEO satellite. However, this is for convenience of explanation and should not be understood as being limited thereto. The GEO satellite (1625) may be a satellite equipped with an O-CU / O-DU / O-RU and may be connected to an NTN gateway via an NG interface (NG over SRI) through an SRI. UEs (1601, 1602) may communicate with at least one LEO satellite or GEO satellite (1625) belonging to satellite clusters (1620A, 1620B, 1620C) via an NR Uu interface. Therefore, the cluster structure illustrated in Fig. 16a may be a case in which there is no O-CU on the ground.

[0380] FIG. 16b is a conceptual diagram illustrating a case in which satellites and the satellites communicate with UEs according to a third embodiment of a satellite cluster.

[0381] Referring to FIG. 16b, the satellite cluster may include an O-CU-equipped satellite (1621) operating as a master (or leader) and O-DU / O-RU-equipped satellites (1622, 1623, 1624) operating as slaves (or followers). The satellite cluster illustrated in FIG. 16b may be configured according to one embodiment of the satellite clusters (1620A, 1620B, 1620C) illustrated in FIG. 16a described above.

[0382] In Fig. 16b, only three O-DU / O-RU satellites (1622, 1623, 1624) are illustrated within a single satellite cluster. However, this is merely for the sake of convenience of illustration and illustration, and the number of O-DU / O-RU satellites may be four, as described in Fig. 13, or two, as described previously. As another extreme example, a single satellite cluster may consist of only one O-DU / O-RU satellite and one O-CU satellite. In other words, the number of satellites within a satellite cluster should not be understood as being limited to four.

[0383] In this case, the master satellite (1621) and the slave satellites (1622, 1623, 1624) each have their functions divided into HLS, and each of the O-DU / O-RU-equipped satellites (1622, 1623, 1624) can be connected to the O-CU-equipped satellite (1621) through the F1 interface via the ISL. As described above, the O-CU-equipped satellite (1621) operating as a master and the O-DU / O-RU-equipped satellites (1622, 1623, 1624) operating as slaves can be formed into one cluster and operate like one base station. The configuration of the satellite cluster illustrated in FIG. 16b can be applied to each of the first satellite cluster (1620A), the second satellite cluster (1620B), and the third satellite cluster (1620C) illustrated in FIG. 16a.

[0384] UEs (1603, 1604, 1605, 1606) can communicate with at least one satellite belonging to O-DU / O-RU equipped LEO satellites (1622, 1623, 1624) within the satellite cluster via an NR Uu interface.

[0385] Figure 16c is a conceptual diagram illustrating a case in which a UPF is mounted on a master satellite among satellites forming a satellite cluster according to a third embodiment.

[0386] Referring to Fig. 16c, an example is provided in which a UPF is mounted on a satellite (1621) equipped with an O-CU operating as a master in Fig. 16b.

[0387] As illustrated in Fig. 16c, when a UPF and application server are installed on an O-CU-equipped satellite (1621), user data can be processed by the satellite's UPF and application server without being transmitted to the ground, thereby reducing user data processing time. In other words, satellite MEC becomes possible.

[0388] If the O-CU-equipped satellite (1621) does not have an application server, even if the UPF is on the satellite, the UPF must be connected to a ground data network for user data to be processed, and the data must be processed by an application server located on the ground. However, if the UPF is on the satellite, even if the satellite loses connection with the NTN gateway, the UE data can be temporarily stored in the UPF and then transmitted to the ground for processing when the satellite reconnects to the NTN gateway. In other words, a store-and-forward service becomes possible, and the service can be continued even if the connection to the ground is lost.

[0389] The detailed information corresponding to the form illustrated in Fig. 16c described above has been described in Fig. 11c, so a duplicate description is omitted. In the case of Fig. 16c, a GEO satellite (1625 in Fig. 16a) can be equipped with not only an O-CU but also a UPF, just like a LEO satellite cluster, and an N6 interface (N6 over SRI) via SRI or an N4 interface (N4 over SRI) via SRI can be used between the GEO satellite (1625) and the ground gateway (1640).

[0390] The satellite cluster illustrated in FIG. 16c described above may be configured according to one embodiment of the satellite clusters (1520A, 1520B, 1520C) illustrated in FIG. 15a described above.

[0391] The operations of the method according to the embodiments of the present disclosure can be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes any type of recording device that stores information readable by a computer system. Furthermore, a computer-readable recording medium can be distributed across network-connected computer systems, allowing the computer-readable program or code to be stored and executed in a distributed manner.

[0392] Additionally, the computer-readable recording medium may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine language codes produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0393] While some aspects of the present disclosure have been described in the context of a device, they may also represent a description of a corresponding method, wherein a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method may also be described as a corresponding block or item or a feature of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps may be performed by such a device.

[0394] In embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In embodiments, the field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

[0395] Although the present disclosure has been described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various modifications and changes may be made to the present disclosure without departing from the spirit and scope of the present disclosure as set forth in the claims below.

Claims

1. In a non-terrestrial network (NTN) communication system based on open RAN (O-RAN), A first satellite equipped with a first function based on the above O-RAN; A second satellite equipped with a second function based on the above O-RAN; and Includes an NTN gateway connected to the second satellite and a satellite radio interface (SRI), The first satellite and the second satellite communicate based on an inter-satellite link (ISL), and the first satellite and the second satellite fly in formation to maintain a certain distance as part of a group. O-RAN based NTN communication system.

2. In claim 1, The first function is an O-RAN radio unit (O-RU) function, and the second function is an O-RAN distributed unit (O-DU) function. The fronthaul interface between the first satellite and the second satellite is based on the ISL, The O-RAN central unit (O-RAN control unit, O-CU) is located on the ground connected to the NTN gateway. The O-DU and the O-CU connected to the NTN gateway are connected wirelessly via the F1 interface. The above F1 interface supports either the F1 interface resume or F1 interface reset operation. O-RAN based NTN communication system.

3. In claim 2, A non-real time RIC connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); A near real-time RIC that is connected to the NTN gateway and performs near real-time wireless resource management for the O-DU function and the O-CU function using the machine learning model received from the non-real-time RIC; and Further comprising a service management and orchestration (SMO) that is connected to the NTN gateway and manages each separated function of the O-RAN. O-RAN based NTN communication system.

4. In claim 3, The second satellite further includes a local xApp that enables near real-time control directly from the second satellite when a wireless resource-related event for the second function occurs. An extended E2 interface or a first control interface is used between the second satellite and the near real-time RIC, The above extended E2 interface or the above first control interface transmits one or a combination of control policies, channel prediction data, weather prediction data, or machine learning models required for satellite communication control. O-RAN based NTN communication system.

5. In claim 4, The local xApp of the second satellite controls in near real time one or a combination of channel information updates for multiple-input multiple-output (MIMO) or beamforming, handover optimization, wireless link monitoring, wireless resource management, mobility management, load balancing, slicing policy updates, traffic steering, interference management, or security operations on the second satellite. O-RAN based NTN communication system.

6. In claim 1, The first function is an O-RAN radio unit (O-RU) function, and the second function is an O-RAN distributed unit (O-DU) function and an O-RAN central unit (O-RAN control unit, O-CU). O-RAN based NTN communication system.

7. In claim 6, The fronthaul interface between the first function and the second function is based on the ISL. O-RAN based NTN communication system.

8. In claim 6, The interface between the NTN gateway and the second satellite uses the NG interface via the SRI, The above NG interface supports either an NG interface resume operation or an NG interface reset operation. O-RAN based NTN communication system.

9. In claim 6, A non-real time RIC connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and Further comprising a service management and orchestration (SMO) that is connected to the NTN gateway and manages each separated function of the O-RAN. O-RAN based NTN communication system.

10. In claim 9, The second satellite further includes a real-time RIC that performs real-time radio resource management for the O-DU function and the O-CU function using the machine learning model received from the non-real-time RIC. O-RAN based NTN communication system.

11. In claim 1, The first function is an O-RAN radio unit (O-RU) function and an O-RAN distributed unit (O-DU) function, and the second function is an O-RAN central unit (O-RAN control unit, O-CU). O-RAN based NTN communication system.

12. In claim 11, The fronthaul interface between the first function and the second function is based on the ISL. O-RAN based NTN communication system.

13. In claim 11, A non-real time RIC connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and Further comprising a service management and orchestration (SMO) that is connected to the NTN gateway and manages each separated function of the O-RAN. O-RAN based NTN communication system.

14. In claim 13, The second satellite further includes a real-time RIC that performs real-time radio resource management for the O-CU function and the O-DU function using the machine learning model received from the non-real-time RIC. O-RAN based NTN communication system.

15. In a non-terrestrial network (NTN) communication system based on open RAN (O-RAN), A first satellite group comprising two or more satellites; a second satellite group comprising two or more satellites; and An NTN gateway connected to at least one satellite among the satellites belonging to the first satellite group or the satellites belonging to the second satellite group via a satellite radio interface (SRI), The satellites included in each of the first satellite group and the second satellite group include at least one first satellite including a first function and a second satellite including a second function, The first satellite and the second satellite communicate based on an inter-satellite link (ISL), The satellites within the first satellite group fly in formation to maintain a constant distance from each other, and the satellites within the second satellite group fly in formation to maintain a constant distance from each other. O-RAN based NTN communication system.

16. In claim 15, The first function is an O-RAN radio unit (O-RU) function, and the second function is an O-RAN distributed unit (O-DU) function. O-RAN based NTN communication system.

17. In claim 16, Satellite A equipped with the O-DU function within the first satellite group and satellite B equipped with the O-DU function within the second satellite group fly in the same orbital plane so that the connection between the two satellite groups is continuously maintained. O-RAN based NTN communication system.

18. In claim 15, The first function is an O-RAN radio unit (O-RU) function, and the second function is an O-RAN distributed unit (O-DU) function and an O-RAN central unit (O-RAN control unit, O-CU). O-RAN based NTN communication system.

19. In claim 18, A non-real time RIC connected to the NTN gateway and providing a machine learning model for policy management of the O-RAN and analysis of the O-RAN to a near real time RAN intelligent controller (RIC); and Further comprising a service management and orchestration (SMO) that is connected to the NTN gateway and manages each separated function of the O-RAN. O-RAN based NTN communication system.

20. In claim 19, The second satellite further includes a real-time RIC that performs real-time radio resource management for the first function and the second function using the machine learning model received from the non-real-time RIC, If the NTN gateway does not exist within the communication range of the second satellite having the second function belonging to the second satellite group, the second satellite having the second function belonging to the second satellite group connects to the SMO through the second satellite having the second function of the first satellite group and the NTN gateway connected to the second satellite. O-RAN based NTN communication system.

Images