Apparatus and method for installing infrastructure by using template information

Abstract

According to one embodiment, an apparatus for service management and orchestration (SMO) may comprise: a memory including instructions and one or more storage media; and at least one processor including processing circuitry. When executed individually or collectively by the at least one processor, the instructions can instruct the apparatus to: on the basis of template information stored in the memory, perform, via an open radio access network-cloud (O-cloud), installation of an infrastructure including a platform related to a plurality of network functions including a central unit (CU) and a distributed unit (DU); on the basis of the template information stored in the memory, perform, via the O-cloud, deployment of the plurality of network functions; and perform cell configuration related to the DU on the basis of the deployment of the plurality of network functions.

Description

Device and method for installing infrastructure using template information

[0001] The present disclosure relates to an apparatus and method for installing infrastructure using template information.

[0002] Network devices implemented in hardware can be implemented to be installed or removed from a server in the form of software. Network devices can be implemented in the form of software on a server through various network entities.

[0003] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure.

[0004] According to one embodiment, a device for service management and orchestration (SMO) may include a memory comprising instructions and one or more storage media, and at least one processor comprising a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the device may perform the installation of an infrastructure comprising a platform related to a plurality of network functions, including a central unit (CU) and a distributed unit (DU), via an open radio access network-cloud (O-cloud) based on template information stored in the memory, perform the deployment of the plurality of network functions via the O-cloud based on the template information stored in the memory, and perform cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0005] According to one embodiment, a method performed by a device for service management and orchestration (SMO) may include: an operation of performing an installation of an infrastructure including a platform related to a plurality of network functions including a central unit (CU) and a distributed unit (DU) via an open radio access network-cloud based on template information stored in the memory of the device; an operation of performing a deployment of the plurality of network functions via the open radio access network-cloud based on the template information stored in the memory; and an operation of performing a cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0006] According to one embodiment, a non-transient computer-readable storage medium may store one or more programs. The one or more programs may include instructions that, when executed by at least one processor of a device for service management and orchestration (SMO), cause the device to perform the installation of an infrastructure including a platform associated with a plurality of network functions, including a central unit (CU) and a distributed unit (DU), via an open radio access network-cloud (O-cloud) based on template information, perform the deployment of the plurality of network functions via the O-cloud based on the template information, and perform cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0007] Figure 1 illustrates a wireless communication system.

[0008] Figure 2a illustrates the interface between an upper network node and a lower network node.

[0009] Figure 2b illustrates the fronthall interface of an O(open)-RAN(radio access network).

[0010] Figure 3a illustrates the functional configuration of an upper network node.

[0011] Figure 3b illustrates the functional configuration of a sub-network node.

[0012] Figure 4 illustrates an example of function splitting between DU and RU.

[0013] Figure 5 shows an example of an architecture for SMO (service management orchestration).

[0014] Figure 6 illustrates an example of an interface between SMO, O-cloud (open radio access network-cloud), and SMO and O-cloud.

[0015] Figure 7 illustrates an example of the operation of SMO and O-Cloud regarding template information.

[0016] Figure 8 illustrates an example of a container infrastructure service (CIS) cluster structure and a descriptor for deploying the CIS.

[0017] Figure 9 illustrates an example of the configuration of a cluster template.

[0018] Figure 10 illustrates an example of the operation of an SMO for cluster installation.

[0019] Figure 11 illustrates an example of the operation of an SMO for CNF placement.

[0020] FIG. 12 illustrates an example of the operation of an SMO for infrastructure installation.

[0021] Figure 13 illustrates an example of the operation of an SMO for CNF placement.

[0022] FIG. 14 illustrates an example of the operation of an SMO for cell configuration.

[0023] FIG. 15 illustrates a flowchart regarding the operation of a device for SMO.

[0024] Figure 16a illustrates an example of the NFV (network function virtualization)-MANO (management and orchestration) architecture framework of the 3GPP (3rd generation partnership project).

[0025] FIG. 16b illustrates an example of the NFV-MANO architecture framework of the European Telecommunications Standards Institute (ETSI) according to embodiments.

[0026] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0027] In the various embodiments of the present disclosure described below, a hardware-based approach is described as an example. However, since the various embodiments of the present disclosure include techniques using both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0028] Terms used in the following description to refer to signals (e.g., signal, information, message, signaling), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occasion), terms for operation states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities, terms referring to device components, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0029] Additionally, in this disclosure, expressions of "greater than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled; however, this is merely for the purpose of expressing an example and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" may be replaced with "less than," and conditions described as "greater than and less than" may be replaced with "greater than and less than." Furthermore, "A" to "B" below refer to at least one of elements from A (including A) to B (including B). Below, "C" and / or "D" refers to including at least one of "C" or "D," i.e., {"C", "D", "C" and "D"}.

[0030] This disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project), xRAN (extensible radio access network), O-RAN (open-radio access network), but these are merely illustrative examples. Various embodiments of this disclosure can be easily modified and applied to other communication systems.

[0031] Figure 1 illustrates a wireless communication system.

[0032] Referring to FIG. 1, FIG. 1 illustrates a base station (110) and a terminal (120) as part of nodes using a wireless channel in a wireless communication system. FIG. 1 illustrates only one base station, but the wireless communication system may include other base stations identical or similar to the base station (110).

[0033] A base station (110) is a network infrastructure that provides wireless access to a terminal (120). The base station (110) has coverage defined based on the distance over which it can transmit signals. In addition to the base station, the base station (110) includes an 'access point (AP)', an 'eNodeB (eNB)', and a '5G node (5 th It may be referred to as 'generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having an equivalent technical meaning.

[0034] A terminal (120) is a device used by a user and communicates with a base station (110) via a wireless channel. The link from the base station (110) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (110) is referred to as an uplink (UL). Additionally, although not shown in FIG. 1, the terminal (120) and another terminal can communicate with each other via a wireless channel. In this case, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without user involvement. According to one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. In addition, according to one embodiment, the terminal (120) may be a narrowband (NB)-Internet of Things (IoT) device.

[0035] The terminal (120) may be referred to as 'user equipment (UE)', 'customer premises equipment (CPE)', 'mobile station', 'subscriber station', 'remote terminal', 'wireless terminal', 'electronic device', or 'user device' or other terms having an equivalent technical meaning.

[0036] The base station (110) can perform beamforming with the terminal (120). The base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). Additionally, the base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or FR 2-1, FR 2-2, FR 2-3), FR 3) of NR) and a millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). To improve channel gain, the base station (110) and the terminal (120) can perform beamforming. Here, beamforming may include transmit beamforming and receive beamforming. The base station (110) and the terminal (120) can impart directivity to the transmitted signal or the received signal. To this end, the base station (110) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through a resource that has a QCL relationship with the resource that transmitted the serving beams.

[0037] If large-scale characteristics of the channel transmitting the symbol on the first antenna port can be inferred from the channel transmitting the symbol on the second antenna port, the first antenna port and the second antenna port may be evaluated to have a QCL relationship. For example, the large-scale characteristics may include at least one of a delay spread, a Doppler spread, a Doppler shift, an average gain, an average delay, and a spatial receiver parameter.

[0038] In FIG. 1, it is described that both the base station (110) and the terminal (120) perform beamforming, but the embodiments of the present disclosure are not necessarily limited thereto. In some embodiments, the terminal may or may not perform beamforming. Also, the base station may or may not perform beamforming. That is, either the base station or the terminal may perform beamforming, or neither the base station nor the terminal may perform beamforming.

[0039] In the present disclosure, a beam refers to a spatial flow of a signal in a wireless channel, formed by one or more antennas (or antenna elements), and this formation process may be referred to as beamforming. Beamforming may include at least one of analog beamforming or digital beamforming (e.g., precoding). A reference signal transmitted based on beamforming may include, for example, a demodulation-reference signal (DM-RS), a channel state information-reference signal (CSI-RS), a synchronization signal / physical broadcast channel (SS / PBCH), or a sounding reference signal (SRS). Additionally, an IE such as a CSI-RS resource or an SRS-resource may be used as a configuration for each reference signal, and such a configuration may include information associated with the beam. Information associated with a beam may refer to whether the configuration (e.g., CSI-RS resource) uses the same spatial domain filter as other configurations (e.g., other CSI-RS resources within the same CSI-RS resource set) or a different spatial domain filter, or which reference signal it is quasi-colocated with, and if so, what type (e.g., QCL type A, B, C, D).

[0040] Conventionally, in communication systems with a relatively large cell radius of base stations, each base station was installed to include the functions of a digital processing unit (or DU (digital unit / distributed unit)) and an RF (radio frequency) processing unit (RF processing unit, or RU (radio unit)). However, 4G (4 th As high frequency bands are used in communication systems (e.g., 5G) and / or thereafter, and cell coverage of base stations decreases, the number of base stations required to cover a specific area has increased. Consequently, the burden of installation costs for operators to install base stations has also increased. To minimize the installation costs of base stations, a structure has been proposed in which the upper network node (e.g., DU) and lower network node (e.g., RU) of a base station are separated, one or more lower network nodes are connected to a single upper network node via a wired network, and one or more geographically distributed lower network nodes are deployed to cover a specific area. Below, base station deployment structures and extension examples according to various embodiments of the present disclosure are described through FIGS. 2a and 2b.

[0041] FIG. 2a illustrates an interface between an upper network node and a lower network node. The interface between the upper network node and the lower network node may include a fronthaul interface. Fronthaul refers to the space between entities between a wireless LAN and a base station, unlike backhaul between a base station and a core network. FIG. 2a illustrates an example of a fronthaul structure between an upper network node (210) and one lower network node (220), but this is merely for convenience of explanation and the present disclosure is not limited thereto. In other words, an embodiment of the present disclosure may also be applied to a fronthaul structure between one upper network node and a plurality of lower network nodes. For example, an embodiment of the present disclosure may be applied to a fronthaul structure between one upper network node and two lower network nodes. Additionally, an embodiment of the present disclosure may also be applied to a fronthaul structure between one upper network node and three lower network nodes.

[0042] For example, an upper network node may include a DU (digital unit / distributed unit). An upper network node may be referred to as a DU. A lower network node may include a RU (radio unit) or an MMU (massive MIMO unit). A lower network node may be referred to as a RU or an MMU.

[0043] Referring to FIG. 2a, the base station (110) may include an upper network node (210) and a lower network node (220). The fronthole (215) between the upper network node (210) and the lower network node (220) may be operated via an Fx interface. For the operation of the fronthole (215), an interface such as eCPRI (enhanced common public radio interface) or ROE (radio over ethernet) may be used.

[0044] As communication technology develops, mobile data traffic increases, and consequently, the bandwidth requirements for the fronthaul between the digital unit and the wireless unit have increased significantly. In a deployment such as a C-RAN (centralized / cloud radio access network), the upper network node (210) performs functions for PDCP (packet data convergence protocol), RLC (radio link control), MAC (media access control), and PHY (physical), and the lower network node (220) can be implemented to perform functions for the PHY layer in addition to RF (radio frequency) functions.

[0045] The upper network node (210) may be responsible for upper layer functions of the wireless network. For example, the upper network node (210) may perform functions of the MAC layer and parts of the PHY layer. Here, parts of the PHY layer are functions of the PHY layer that are performed at a higher level, and may include, for example, channel encoding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). According to one embodiment, if the upper network node (210) conforms to the O-RAN standard, it may be referred to as an O-DU (O-RAN DU) (or DU). The upper network node (210) may be replaced and represented as a first network entity or DU for a base station (e.g., gNB) in the embodiments of the present disclosure as necessary.

[0046] The lower network node (220) can be responsible for lower layer functions of the wireless network. For example, the lower network node (220) can perform RF functions, which are part of the PHY layer. Here, part of the PHY layer refers to functions of the PHY layer that are performed at a relatively lower level than the upper network node (210), and may include, for example, iFFT transformation (or FFT transformation), CP (cyclic prefix) insertion (CP removal), and digital beamforming. Examples of such specific functional separation are described in detail in FIG. 4. The lower network node (220) may be referred to as an 'access unit (AU)', 'access point (AP)', 'transmission / reception point (TRP)', 'remote radio head (RRH)', 'radio unit (RU)', or other terms having an equivalent technical meaning. According to one embodiment, if the sub-network node (220) conforms to the O-RAN standard, it may be referred to as an O-RU (O-RAN RU) (or RU). The sub-network node (220) may be replaced with a second network entity or RU for a base station (e.g., gNB) in the embodiments of the present disclosure as needed.

[0047] In the above example, it is described that the upper network node (210) includes a DU and the lower network node (220) includes an RU, but the embodiments of the present disclosure are not limited thereto. A base station according to the embodiments may be implemented in a distributed deployment according to a centralized unit (CU) configured to perform the functions of the upper layers of the access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform the functions of the lower layers. In this case, the distributed unit (DU) may include a digital unit (DU) and a radio unit (RU). Between a core network (e.g., 5G core or next generation core (NGC)) and a radio network (RAN), the base station may be implemented in a structure in which the CU, DU, and RU are arranged in that order. The interface between the CU and the distributed unit (DU) may be referred to as the F1 interface.

[0048] For example, a centralized unit (CU) can be connected to one or more DUs and perform functions at a higher layer than the DUs. For instance, the CU can perform functions at the radio resource control (RRC) and packet data convergence protocol (PDCP) layers, while the DU and RU can perform functions at lower layers. The DU can perform radio link control (RLC), media access control (MAC), and some functions of the physical (PHY) layer (high PHY), while the RU can perform the remaining functions of the PHY layer (low PHY). Additionally, as an example, a digital unit (DU) can be included in a distributed unit (DU) depending on the distributed deployment implementation of the base station. The following description describes the operations of DU and RU unless otherwise defined, but various embodiments of the present disclosure may be applied to both base station deployments including CU and deployments where DU is directly connected to the core network (i.e., implemented by integrating CU and DU into a single entity base station (e.g., NG-RAN node)).

[0049] FIG. 2b illustrates a fronthall interface of an O(open)-RAN(radio access network). An eNB or gNB is exemplified as a base station (110) according to distributed deployment.

[0050] Referring to FIG. 2b, the base station (110) may include an O-DU (251) and O-RUs (253-1, …, 253-n). For convenience of explanation, the operation and function of the O-RU (253-1) may be understood as an explanation for each of the other O-RUs (e.g., O-RU (253-n)).

[0051] The O-DU (251) is a logical node containing functions among the functions of the base station (e.g., eNB, gNB) according to FIG. 4 described below, excluding those exclusively allocated to the O-RU (253-1). The O-DU (251) can control the operation of the O-RUs (253-1, …, 253-n). The O-DU (251) may be referred to as an LLS (lower layer split) CU (central unit). The O-RU (253-1) is a logical node containing a subset of the functions of the base station (e.g., eNB, gNB) according to FIG. 4 described below. Real-time aspects of control plane (C-plane) communication and user plane (U-plane) communication with the O-RU (253-1) can be controlled by the O-DU (251).

[0052] O-DU (251) can communicate with O-RU (253-1) through an LLS interface. The LLS interface corresponds to a fronthall interface. The LLS interface refers to a logical interface between O-DU (251) and O-RU (253-1) utilizing lower layer functional split (i.e., intra-PHY based functional split). LLS-C between O-DU (251) and O-RU (253-1) provides a C-plane through the LLS interface. LLS-U between O-DU (251) and O-RU (253-1) provides a U-plane through the LLS interface.

[0053] In FIG. 2b, to explain the O-RAN, the entities of the base station (110) are described as O-DU and O-RU. However, these designations are not to be interpreted as limiting the embodiments of the present disclosure. In the embodiments described below, it is understood that the operations of the upper network node (210) may be performed by the O-DU (251). The description of the upper network node (210) may be applied to the O-DU (251). Likewise, in the embodiments described below, it is understood that the operations of the lower network node (220) may be performed by the O-RU (253-1). The description of the lower network node (220) may be applied to the O-DU (253-1).

[0054] FIG. 3a illustrates the functional configuration of an upper network node. The configuration exemplified in FIG. 3a can be understood as the configuration of the upper network node (210) of FIG. 2a (or the O-DU (250) of FIG. 2b) as part of a base station. Terms such as '...part', '...unit' used below refer to a unit that processes at least one function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

[0055] Referring to FIG. 3a, the upper network node (210) may include a transceiver (310), memory (320), and a processor (330). The upper network node (210) may include a digital unit / distributed unit (DU). The upper network node may be referred to as a DU.

[0056] The transceiver (310) can perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (310) may include a wired interface for controlling a direct connection between devices through a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (310) can transmit an electrical signal to another device through a copper wire or perform conversion between an electrical signal and an optical signal. An upper network node (210) can communicate with a lower network node (220) through the transceiver (310). In an example, though not limited to, if the upper network node (210) is a DU, the upper network node (210) can be connected to a core network or a centralized node of a distributed deployment (e.g., CU) through the transceiver (310).

[0057] The transceiver (310) may perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (310) may perform conversion functions between baseband signals and bit sequences according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (310) generates complex symbols by encoding and modulating the transmitted bit sequence. Also, when receiving data, the transceiver (310) restores the received bit sequence by demodulating and decoding the baseband signal. Additionally, the transceiver (310) may include multiple transmission and reception paths. Also, according to one embodiment, the transceiver (310) may be connected to a core network or to other nodes (e.g., an integrated access backhaul).

[0058] The transceiver (310) can transmit and receive signals. For example, the transceiver (310) can transmit a management plane (M-plane) message. For example, the transceiver (310) can transmit a synchronization plane (S-plane) message. For example, the transceiver (310) can transmit a control plane (C-plane) message. For example, the transceiver (310) can transmit a user plane (U-plane) message. For example, the transceiver (310) can receive a user plane message. Although only the transceiver (310) is shown in FIG. 3a, according to other implementation examples, the upper network node (210) may include two or more transceivers.

[0059] The transceiver (310) transmits and receives signals as described above. Accordingly, all or part of the transceiver (310) may be referred to as a 'communication unit', 'transmitter unit', 'receiver unit', or 'transmitter / receiver unit'. Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the transceiver (310).

[0060] Although not illustrated in FIG. 3a, the transceiver (310) may further include a backhaul transceiver for connecting to a core network or another base station. The backhaul transceiver provides an interface for communicating with other nodes within the network. That is, the backhaul transceiver converts a sequence of bits transmitted from a base station to another node, e.g., another access node, another base station, an upper node, a core network, etc., into a physical signal, and converts a physical signal received from another node into a sequence of bits.

[0061] The memory (320) stores data such as basic programs, applications, and configuration information for the operation of the upper network node (210). The memory (320) may be referred to as a storage unit. The memory (320) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Additionally, the memory (320) provides the stored data upon the request of the processor (330).

[0062] The processor (330) controls the overall operations of the upper network node (210). The processor (380) may be referred to as the control unit. For example, the processor (330) transmits and receives signals through the transceiver (310) (or through the backhaul communication unit). Additionally, the processor (330) writes and reads data to and from memory (320). Furthermore, the processor (330) can perform the functions of the protocol stack required by the communication standard. Although only the processor (330) is shown in FIG. 3a, according to other implementation examples, the upper network node (210) may include two or more processors.

[0063] The configuration of the upper network node (210) shown in FIG. 3a is merely an example, and the examples of upper network nodes performing embodiments of the present disclosure are not limited to the configuration shown in FIG. 3a. In some embodiments, some configurations may be added, deleted, or changed.

[0064] FIG. 3b illustrates the functional configuration of a sub-network node. The configuration exemplified in FIG. 3b can be understood as the configuration of the sub-network node (220) of FIG. 2b (or the O-RU (253-1)) of FIG. 2b as part of a base station. Terms such as '...part', '...unit' used below refer to a unit that processes at least one function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

[0065] Referring to FIG. 3b, the sub-network node (220) may include an RF transceiver (360), a fronthole transceiver (365), a memory (370), and a processor (380). For example, the RF transceiver (360) may be referred to as a wireless transceiver. The fronthole transceiver (365) may be referred to as an optical transceiver.

[0066] The RF transceiver (360) performs functions for transmitting and receiving signals through a wireless channel. For example, the RF transceiver (360) upconverts a baseband signal into an RF band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal. For example, the RF transceiver (360) may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc.

[0067] The RF transceiver (360) may include a plurality of transmission and reception paths. Furthermore, the RF transceiver (360) may include an antenna section. The RF transceiver (360) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the RF transceiver (360) may be composed of a digital circuit and an analog circuit (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuit and the analog circuit may be implemented in a single package. Additionally, the RF transceiver (360) may include a plurality of RF chains. The RF transceiver (360) may perform beamforming. The RF transceiver (360) may apply beamforming weights to a signal to give directionality to the signal to be transmitted and received according to the settings of the processor (380). According to one embodiment, the RF transceiver (360) may include an RF (radio frequency) block (or RF section).

[0068] According to one embodiment, the RF transceiver (360) can transmit and receive signals over a radio access network. For example, the RF transceiver (360) can transmit a downlink signal. The downlink signal may include a synchronization signal (SS), a reference signal (RS) (e.g., CRS (cell-specific reference signal), DM (demodulation)-RS), system information (e.g., MIB, SIB, RMSI (remaining system information), OSI (other system information)), a configuration message, control information, or downlink data. Additionally, for example, the RF transceiver (360) can receive an uplink signal. The uplink signal may include random access-related signals (e.g., random access preamble (RAP) (or Msg1 (message 1)), Msg3 (message 3)), reference signals (e.g., sounding reference signal (SRS), DM-RS), or power headroom report (PHR). Although only an RF transceiver (360) is shown in FIG. 3b, according to other embodiments, the sub-network node (220) may include two or more RF transceivers.

[0069] According to the embodiments, the RF transceiver (460) may transmit RIM-RS. The RF transceiver (460) may transmit a first type of RIM-RS (e.g., 3GPP RIM-RS type 1) to indicate the detection of distant interference. The RF transceiver (460) may transmit a second type of RIM-RS (e.g., 3GPP RIM-RS type 2) to indicate the presence or absence of distant interference.

[0070] The fronthall transceiver (365) can transmit and receive signals. According to one embodiment, the fronthall transceiver (365) can transmit and receive signals on the fronthall interface. For example, the fronthall transceiver (365) can receive management plane (M-plane) messages. For example, the fronthall transceiver (365) can receive synchronization plane (S-plane) messages. For example, the fronthall transceiver (365) can receive control plane (C-plane) messages. For example, the fronthall transceiver (365) can transmit user plane (U-plane) messages. For example, the fronthall transceiver (365) can receive user plane messages. Although only the fronthole transceiver (365) is shown in FIG. 3b, according to other implementation examples, the lower network node (220) may include two or more fronthole transceivers.

[0071] The RF transceiver (360) and the fronthall transceiver (365) transmit and receive signals as described above. Accordingly, all or part of the RF transceiver (360) and the fronthall transceiver (365) may be referred to as a 'communication unit', 'transmitter unit', 'receiver unit', or 'transmitter unit'. Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the RF transceiver (360). In the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the RF transceiver (360).

[0072] Memory (370) stores data such as basic programs, applications, and configuration information for the operation of the sub-network node (220). Memory (370) may be referred to as a storage unit. Memory (370) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Additionally, memory (370) provides stored data upon request from the processor (380). According to one embodiment, memory (370) may include memory for conditions, commands, or configuration values ​​related to the SRS transmission method.

[0073] The processor (380) controls the overall operations of the sub-network node (220). The processor (380) may be referred to as a control unit. For example, the processor (380) transmits and receives signals through the RF transceiver (360) or the fronthall transceiver (365). Additionally, the processor (380) writes and reads data to and from the memory (370). Furthermore, the processor (380) can perform the functions of the protocol stack required by the communication standard. Although only the processor (380) is shown in FIG. 3b, according to other implementation examples, the sub-network node (220) may include two or more processors. The processor (380) may be a set of instructions or code stored in the memory (370), or a storage space storing instructions / code or instructions / code that are at least temporarily resided in the processor (380), or may be part of the circuitry constituting the processor (380). Additionally, the processor (380) may include various modules for performing communication. The processor (380) may control the lower network node (220) to perform operations according to the embodiments described below.

[0074] The configuration of the sub-network node (220) shown in FIG. 3b is merely an example, and the examples of RUs performing embodiments of the present disclosure are not limited to the configuration shown in FIG. 3b. In some embodiments, some configurations may be added, deleted, or changed.

[0075] FIG. 4 illustrates an example of a function split between a DU and an RU. The DU may be an example of an upper network node (210) of FIG. 2a and FIG. 3a. The RU may be an example of a lower network node (220) of FIG. 2a and FIG. 3b.

[0076] As wireless communication technology advances (e.g., 5G(5 thWith the introduction of generation (or NR (new radio)) communication systems, the frequency band used has increased even further. As the cell radius of base stations has become very small, the number of RUs required for installation has increased even further. In addition, in 5G communication systems, the amount of data transmitted has increased by more than 10 times, so the transmission capacity of the wired network transmitted to the fronthaul has increased significantly. Due to the factors described above, the installation cost of the wired network in 5G communication systems can increase significantly. Therefore, to reduce the transmission capacity of the wired network and lower the installation cost of the wired network, 'function splitting' can be utilized to reduce the transmission capacity of the fronthaul by transferring some functions of the DU's modem to the RU.

[0077] To reduce the burden on the DU, the role of the RU, which is traditionally responsible only for RF functions, can be extended to include some physical layer functions. As the RU performs higher-layer functions, its throughput increases, which can increase transmission bandwidth in the fronthall while simultaneously lowering latency requirements due to response processing. On the other hand, as the RU performs higher-layer functions, virtualization benefits decrease, and the size, weight, and cost of the RU increase. Considering the trade-offs between the aforementioned advantages and disadvantages, it is required to implement optimal functional separation.

[0078] Referring to FIG. 4, functional separations at the physical layer below the MAC layer are illustrated. For the downlink (DL) that transmits a signal to a terminal via a wireless network, the base station may sequentially perform channel encoding / scrambling, modulation, layer mapping, antenna mapping, RE mapping, digital beamforming (e.g., precoding), iFFT transformation / CP insertion, and RF conversion. For the uplink (UL) that receives a signal from a terminal via a wireless network, the base station may sequentially perform RF conversion, FFT transformation / CP removal, digital beamforming (pre-combining), RE demapping, channel estimation, layer demapping, demodulation, and decoding / scrambling. The separation of uplink functions and downlink functions may be defined in various types based on the needs of vendors, discussions in specifications, etc., according to the trade-offs described above.

[0079] In the first function separation (405), the RU performs RF functions and the DU performs PHY functions. The first function separation is substantially such that no PHY functions are implemented within the RU, and may be referred to as Option 8, for example. In the second function separation (410), the RU performs iFFT transform / CP insertion in the DL of the PHY functions and FFT transform / CP removal in the UL, and the DU performs the remaining PHY functions. For example, the second function separation (410) may be referred to as Option 7-1. In the third function separation (420a), the RU performs iFFT transform / CP insertion in the DL of the PHY functions and FFT transform / CP removal and digital beamforming in the UL, and the DU performs the remaining PHY functions. For example, the third function separation (420a) may be referred to as Option 7-2x Category A. In the fourth function separation (420b), the RU performs digital beamforming in both the DL and UL, and the DU performs higher PHY functions after digital beamforming. For example, the fourth function separation (420b) may be referred to as Option 7-2x Category B. In the fifth function separation (425), the RU performs RE mapping (or RE demapping) in both the DL and UL, and the DU performs higher PHY functions after RE mapping (or RE demapping). For example, the fifth function separation (425) may be referred to as Option 7-2. In the sixth function separation (430), the RU performs modulation (or demodulation) in both the DL and UL, and the DU performs higher PHY functions after modulation (or demodulation). For example, the sixth function separation (430) may be referred to as Option 7-3. In the seventh function separation (440), the RU performs encoding / scrambling (or decoding / scrambling) in both the DL and UL, and the DU performs subsequent upper PHY functions up to modulation (or demodulation). For example, the seventh function separation (440) may be referred to as Option 6.

[0080] According to one embodiment, when high-volume signal processing is expected, such as with an FR 1 MMU, functional separation at a relatively high level (e.g., fourth functional separation (420b)) may be required to reduce fronthall capacity. Additionally, functional separation at too high a level (e.g., sixth functional separation (430)) may result in a complex control interface and may cause a burden on the implementation of the RU due to the inclusion of multiple PHY processing blocks within the RU; therefore, appropriate functional separation may be required depending on the arrangement and implementation method of the DU and RU.

[0081] According to one embodiment, if the precoding of data received from the DU cannot be processed (i.e., if there is a limit to the RU's precoding capability), a third function separation (420a) or a lower function separation (e.g., a second function separation (410)) may be applied. Conversely, if there is a capability to process the precoding of data received from the DU, a fourth function separation (420b) or a higher function separation (e.g., a sixth function separation (430)) may be applied.

[0082] In the following disclosure, unless otherwise limited, embodiments are described based on a third function separation (420a) (which may be referred to as Category A (category A, CAT-A)) or a fourth function separation (420b) (which may be referred to as Category B (category B, CAT-B)) for performing beamforming processing in the RU. The O-RAN specification distinguishes types of O-RUs based on whether the precoding function is located at the interface of the O-DU or at the interface of the O-RU. An O-RU in which precoding is not performed (i.e., low complexity) may be referred to as a CAT-A O-RU. An O-RU in which precoding is performed may be referred to as a CAT-B O-RU.

[0083] Hereinafter, the term "upper-PHY" refers to physical layer processing performed in the DU of the fronthall interface. For example, the upper-PHY may include FEC encoding / decoding, scrambling, and modulation / demodulation. Hereinafter, the term "lower-PHY" refers to physical layer processing performed in the RU of the fronthall interface. For example, the lower-PHY may include FFT / iFFT, digital beamforming, PRACH (physical random access channel) extraction, and filtering. However, the above-described criteria do not exclude embodiments through other functional separations. The functional configuration, signaling, or operation of the embodiments described below may be applied not only to the third functional separation (420a) or the fourth functional separation (420b) but also to other functional separations.

[0084] In the embodiments of the present disclosure, eCPRI and O-RAN specifications are exemplarily described as fronthall interfaces when transmitting messages between a DU, which is an example of an upper network node (210) of FIG. 2A, and a RU, which is an example of a lower network node (220). The Ethernet payload of the message may include an eCPRI header, an O-RAN header, and additional fields. Hereinafter, various embodiments of the present disclosure are described using the eCPRI or O-RAN specification terms, but other expressions having equivalent meanings to each term may be used as substitutes in the various embodiments of the present disclosure. Hereinafter, various embodiments of the present disclosure are described using the eCPRI or O-RAN specification terms, but are not limited thereto. For example, in the various embodiments of the present disclosure, the CPRI specification may be used as a fronthall interface.

[0085] For the fronthaul transport protocol, Ethernet and eCPRI can be used as they are easily shared with the network. The eCPRI header and the O-RAN header may be included within the Ethernet payload. The eCPRI header may be located at the beginning of the Ethernet payload. The contents of the eCPRI header are as follows.

[0086] 1) ecpriVersion (4 bits): This parameter indicates the eCPRI protocol version.

[0087] 2) ecpriReserved (3 bits): This parameter is reserved for further use of eCPRI.

[0088] 3) ecpriConcatenation (1 bit): This parameter indicates when eCPRI concatenation is in use.

[0089] 4) ecpriMessage (1 byte): This parameter indicates the type of service carried by the message type. For example, the parameter represents an IQ data message, a real-time control data message, or a transmission network delay measurement message.

[0090] 5) ecpriPayload (2 bytes): This parameter indicates the byte size of the payload portion of the eCPRI message.

[0091] 6) ecpriRtcid / ecpriPcid (2 bytes): This parameter is the eAxC (extended Antenna-carrier) identifier (eAxC ID) and identifies a specific data flow associated with each C-plane (ecpriRtcid) or U-plane (ecpriPcid) message.

[0092] 7) ecpriSeqid (2 bytes): This parameter provides unique message identification and ordering at two levels. The first octet of this parameter is the sequence ID used to identify the order of messages within the eAxC message stream, and the sequence ID is used to verify that all messages have been received and to reorder out-of-order messages. The second octet of this parameter is the sub-sequence ID. The sub-sequence ID is used to verify ordering and implement reordering when radio-transport-level fragmentation (eCPRI or IEEE-1914.3) occurs.

[0093] The eAxC identifier (ID) includes a band and sector identifier ('BandSector_ID'), a component carrier identifier ('CC_ID'), a spatial stream identifier ('RU_Port_ID'), and a distributed unit identifier ('DU_Port_ID'). Bit allocation of the eAxC ID can be distinguished as follows.

[0094] 1) DU_port ID: To distinguish processing units in the O-DU (e.g., different baseband cards), the DU_port ID is used. The O-DU allocates bits for the DU_port ID, and the O-RU is expected to attach the same value to UL U-plane messages carrying the same sectionId data.

[0095] 2) BandSector_ID: Aggregated cell identifier (band and sector distinction supported by O-RU).

[0096] 3) CC_ID: CC_ID distinguishes the carrier components supported by the O-RU.

[0097] 4) RU_port ID: RU_port ID specifies logical flows such as data layers or spatial streams, and logical flows such as signal channels that require separate numerologies (e.g., PRACH) or special antenna assignments such as SRS.

[0098] The application protocol of the fronthall may include a control plane (C-plane), a user plane (U-plane), a synchronization plane (S-plane), and a management plane (M-plane).

[0099] The control plane may be configured to provide scheduling and beamforming information via control messages. The control plane refers to real-time control between the DU and the RU. The user plane may include IQ sample data transmitted between the DU and the RU. The user plane may include user downlink data (IQ data or SSB / RS), uplink data (IQ data or SRS / RS), or PRACH data. The weight vector of the beamforming information described above may be multiplied by the user data. The synchronization plane generally refers to traffic between the DU and the RU to a synchronization controller (e.g., IEEE Grand Master). The synchronization plane may relate to timing and synchronization. The management plane refers to non-real-time control between the DU and the RU. The management plane may relate to initial setup, non-real-time reset or reset, and non-real-time reporting.

[0100] Control plane messages, i.e., C-plane messages, can be encapsulated based on a two-layer header approach. The first layer may consist of an eCPRI common header or an IEEE 1914.3 common header, which includes fields used to indicate the message type. The second layer is the application layer, which includes fields necessary for control and synchronization. Within the application layer, sections define the characteristics of U-plane data transmitted or received on a beam with a single pattern ID. The section types supported within the C-plane are as follows.

[0101] Section Type can indicate the purpose of control messages transmitted in the control plane. For example, the uses by Section Type are as follows.

[0102] 1) sectionType=0: Used to point to resource blocks or symbols that are not used in the DL or UL.

[0103] 2) sectionType=1: Used for most DL / UL radio channels. Here, "most" refers to channels that do not require a time or frequency offset, such as those required for mixed numerology channels.

[0104] 3) sectionType=2: reserved for further use

[0105] 4) sectionType=3: PRACH and mixed-numerology channels. Channels requiring a time or frequency offset, or different from the nominal SCS value(s).

[0106] 5) sectionType=4: reserved for further use

[0107] 6) sectionType=5: UE scheduling information. Transmit UE scheduling information so that the RU can calculate real-time BF weights (O-RAN optional BF method)

[0108] 7) sectionType=6: Transmission of UE-specific channel information. Periodically transmits UE channel information to enable the RU to calculate real-time BF weights (O-RAN optional BF method)

[0109] 8) sectionType=7: Used for LAA support

[0110] Figure 5 shows an example of an architecture for SMO (service management orchestration).

[0111] Referring to FIG. 5, the logical architecture of O-RAN may include SMO (service management orchestration) (500), O-eNB (505), O-RU (510), O-DU (520), O-CU-CP (531), O-CU-UP (532), Near-RT (real time) RIC (540), and Non-RT RIC (550).

[0112] According to one embodiment, the SMO (500) may be configured to manage network functions. The SMO (500) may include a non-RT RIC (550). The SMO (500) may perform configuration, alert, performance, and / or security management using an O1 interface. The O1 interface may include an interface between the SMO (500) and the near-RT RIC (540). For example, the SMO (500) may be responsible for RAN management among various management domains (e.g., RAN management, core management, transport management, end-to-end (E2E) slice management) in the service provider's network. For RAN management, the SMO (500) may provide RAN optimization using an FCAPS (fault, configuration, accounting, performance, security) interface and a Non-RT RIC (550).

[0113] For example, a non-RT RIC (550) can manage the placement, configuration, and / or data regarding a RAN node (e.g., O-CU-UP (532), O-CU-CP (531), O-DU (520), or O-eNB (580)). The non-RT RIC (550) can handle services that have delay requirements exceeding a specified time (e.g., 1 second).

[0114] For example, the A1 interface may include an interface between a non-RT RIC (550) and a near-RT RIC (540). The non-RT RIC (550) may communicate with the near-RT RIC (540) through the A1 interface. The non-RT RIC (550) may provide policy and / or enrichment information to the near-RT RIC (540) using the A1 interface. Policy management services, enrichment information services, and machine learning (ML) model management services may be provided through the A1 interface. The non-RT RIC (550) may execute content delivered through the A1 interface. For example, the non-RT RIC (550) may provide policy and / or enrichment information to the near-RT RIC (540) through an A1 policy message.

[0115] For example, a Near-RT RIC (540) is a logical node for customizing RAN functionality for new services or regional resource optimization. A Near-RT RIC (540) can provide functions such as network intelligence (e.g., policy enforcement, handover optimization), resource assurance (e.g., radio-link management, advanced self-organized-network), and resource control (e.g., load balancing, slicing policy). A Near-RT RIC (540) can be connected to an O-eNB (505), O-CU-CP (531), O-CU-UP (532), and / or an O-DU (520). The Near-RT RIC (540) can communicate with the O-eNB (505), O-CU-CP (531), O-CU-UP (532), and / or O-DU (520). The Near-RT RIC (540) can be connected to each node via the E2 interface. Additionally, the interface between the O-CU-CP (531) and the O-DU (520) may be referred to as the F1-c interface. The interface between the O-CU-UP (532) and the O-DU (520) may be referred to as the F1-u interface.

[0116] For example, the O-eNB (580) may be a node that provides an access network in an LTE communication system. For the O-eNB (580), the descriptions of the base station (110) in FIG. 1 may be referenced. The O-RU (510), O-DU (520), O-CU-CP (531), and O-CU-UP (532) may be network entities (or nodes) that provide an access network in an NR communication system.

[0117] For example, O-Cloud (560) is a cloud computing platform consisting of a set of physical infrastructure nodes that meet O-RAN requirements for hosting related O-RAN functions (e.g., Near-RT RIC (540), O-CU-CP (531), O-CU-UP (532), and O-DU (520)), supporting software components (e.g., operating system, virtual machine monitor, container runtime, etc.), and / or appropriate management and orchestration functions.

[0118] In FIG. 5, O-CU-CP (531) and O-CU-UP (532) are illustrated separately according to the separation of the control plane and the user plane, but embodiments of the present disclosure are not limited thereto. As a non-limiting example, O-CU-CP (531) and O-CU-UP (532) may be understood as a single O-CU (530). Additionally, while FIG. 5 illustrates a single Near-RT RIC (540), according to various embodiments, multiple Near-RT RICs may exist for the O-RAN architecture. Multiple Near-RT RICs may be implemented as multiple hardware located at the same physical location or through virtualization using a single hardware.

[0119] Figure 6 illustrates an example of an interface between SMO, O-cloud (open radio access network-cloud), and SMO and O-cloud.

[0120] Referring to FIG. 6, the SMO (500) may be configured to perform RAN domain management. For example, the SMO (500) may provide an FCAPS interface for network functions. The SMO (500) may include a Non-RT RIC (550) for RAN optimization. The SMO (500) may perform O-Cloud (560) management. The SMO (500) may provide an A1 interface between the Non-RT RIC (550) and the near-RT RIC (540) for RAN optimization. The SMO (500) may provide an O1 interface for FCAPS support for network functions. The SMO (500) may provide an O2 interface for providing platform resource and workload management.

[0121] According to one embodiment, the SMO (500) can perform orchestration and workflow management. For example, the SMO (500) can perform discovery and management of resources in the O-Cloud (560). For example, the SMO (500) can perform management of the scale-in / scale-out of the O-Cloud (560). For example, the SMO (500) can perform management regarding FACPS of the O-Cloud (560) (e.g., PM (performance management), CM (configuration management), FM (fault management), or communication monitor). For example, the SMO (500) can perform the creation / deletion of deployments and the management of resources in the O-Cloud (560) allocated for this purpose. For example, the SMO (500) can perform the scale-in / scale-out of deployments and the management of resources in the O-Cloud (560) allocated for this purpose. For example, SMO (500) can perform management regarding FCAPS of the deployment and the resources of O-Cloud (560) allocated for it. For example, SMO (500) can perform management of the deployment software.

[0122] According to one embodiment, the SMO (500) may include a service orchestration (501), a RAN NF CM (radio access network network function configuration management) (502), a SME (service management and exposure) (503), a FOCOM (federated O-cloud orchestration and management) (504), and an NFO (network function orchestrator) (505). For example, the service orchestration (501), the RAN NF CM (502), the SME (503), the FOCOM (504), and the NFO (505) may each be composed of a function block (or circuit).

[0123] For example, service orchestration (501) may be configured to perform the installation of an infrastructure including a platform associated with multiple network functions on a server (or CaaS (containers-as-a-service)).

[0124] For example, the RAN NF CM (502) may be configured to perform management of multiple network functions. For example, the multiple network functions may include at least one of an O-RU (510), an O-DU (520), an O-CU-CP (531), an O-CU-UP (532), a Near-RT RIC (540), and / or a Non-RT RIC (550).

[0125] For example, FOCOM (504) may be configured to manage the distribution of software in O-Cloud (560). FOCOM (504) may be configured to provide orchestration for the lifecycle processes of O-Cloud (560). For example, SMO (500) may treat a collection of O-Cloud (560) as a single federated cloud. For example, FOCOM (504) may be configured to perform accounting and asset management for resources in the cloud (e.g., O-Cloud (560)). FOCOM (504) may include information regarding the management of O-Cloud (560) resources. FOCOM (504) may identify (or verify) whether a service is within or outside the operator domain.

[0126] For example, the NFO (505) may be configured to manage deployment lifecycle events, open loop and closed loop operation procedures. The NFO (505) may be configured to orchestrate the assembly of network functions as a composition of network function deployments within the O-Cloud (560).

[0127] According to one embodiment, O-Cloud (560) may be associated with a cloud computing platform consisting of physical infrastructure for hosting multiple network functions. O-Cloud (560) may include supporting software components including an operating system, a virtual machine monitor, and a container runtime. O-Cloud (560) may be configured to perform management and orchestration functions.

[0128] For example, the O-Cloud platform (or O-Cloud (560), a platform configured in O-Cloud (560)) may correspond to a set of hardware and software components for providing O-Cloud capabilities and services for executing multiple network functions.

[0129] For example, hardware for the O-Cloud platform may include components for computing, networking, and storage. The O-Cloud platform may include acceleration technologies required by multiple network functions to meet performance objectives.

[0130] For example, software related to the O-Cloud platform may provide an application programming interface (API) for coordinating and managing the lifecycle of network function deployments. For example, software related to the O-Cloud platform may be separated from the hardware related to the O-Cloud platform.

[0131] O-Cloud (560) may include IMS (561) and DMS (562). For example, IMS (561) may manage the resources of all DMSs of O-Cloud (560) and resources not assigned to any DMS. IMS (561) may be tailored (or configured) for the management and provisioning of resources available in SMO (500) through FOCOM (504) over O2ims. For example, IMS (561) may be associated with logical services provided in O-Cloud (560) to provide an interface that orchestrates the lifecycle processes of O-Cloud (560) along with network functions and other operational procedures that may be hosted. For example, O-Cloud (560) can be provisioned (or leased) as an O-Cloud node cluster managed in an O-Cloud resource pool with allocated operating systems and cluster software.

[0132] For example, the DMS (562) may be associated with a logical service provided by O-Cloud (560) to manage the lifecycle of a deployment using cloud resources. For example, O-Cloud (560) may include multiple DMSs. The DMS (562) may be configured to manage leased resources from multiple resource pools. The DMS (562) may be dynamically created via O2ims for the deployment placement and deployment management of network function deployments of an O-Cloud node cluster available in SMO (500) via NFO (505) over O2dms.

[0133] According to one embodiment, the interface between SMO (500) and O-Cloud (560) may be referred to as the O2 interface. For example, the O2 interface may be configured to provide platform resources and workload management.

[0134] According to one embodiment, the O2 interface may be configured for resource management of the O-Cloud infrastructure. For example, the O2 interface may be configured for discovery and management of the O-Cloud infrastructure. For example, the O2 interface may be configured for scale-in / scale-out of the O-Cloud infrastructure. For example, the O2 interface may be configured for management of FACPS of the O-Cloud infrastructure (e.g., performance management (PM), configuration management (CM), fault management (FM), or communication monitor). For example, the O2 interface may be configured for management of software regarding the O-Cloud (or O-Cloud infrastructure) platform.

[0135] According to one embodiment, the O2 interface may be configured for abstracted resource and DMS management. For example, the O2 interface may be configured for the management of resources of an abstracted O-Cloud infrastructure for creation and scale-in / scale-out allocation. For example, the O2 interface may be configured for the management of resources of an abstracted O-Cloud infrastructure for deployment FCAPS (e.g., PM or FM). For example, the O2 interface may be configured for deployment DMS (e.g., creation, deletion, and lease of O-Cloud infrastructure).

[0136] According to one embodiment, the O2 interface may be configured for network function and service deployment orchestration. For example, the O2 interface may be configured for deployment software management. The O2 interface may be configured for deployment / termination / scaling / healing of network function and service deployment resources. For example, the O2 interface may be configured for FCAPS (e.g., PM or FM) for network function and service deployment resources.

[0137] Figure 7 illustrates an example of the operation of SMO and O-Cloud regarding template information.

[0138] Referring to FIG. 7, the template information (hereinafter, cluster template) can enable the iterative creation and / or updating of an O-Cloud Node cluster by applying a declarative target configuration of an O-Cloud Node cluster representing a set of known characteristics to the SMO (500).

[0139] For example, SMO (500) can select a cluster template instance representing a desired set of attributes for an O-Cloud node cluster. SMO (500) can request O-Cloud (560) to create or update an O-Cloud node cluster based on the cluster template instance.

[0140] For example, O-Cloud (560) may apply a cluster template artifact corresponding to the cluster template instance. The cluster template artifact may include the configuration, topology, and structure of O-Cloud (560)'s internal resources and software. The cluster template artifact may provide O-Cloud specific information and files necessary for building an O-Cloud node cluster. Subsequently, the O-Cloud node cluster can be built and reconciled in O-Cloud (560). An O-Cloud node cluster can be configured based on the selected cluster template instance.

[0141] For example, a cluster template instance can represent an O-Cloud node cluster with known characteristics regarding the workload placements (e.g., network function (NF) placements) that the O-Cloud node cluster can perform.

[0142] For example, to create a cluster template instance, available O-Cloud (560) resources, internal connectivity, software, and configuration parameters, as well as requirements that can be deployed to an O-Cloud node cluster, may be considered.

[0143] According to one embodiment, a cluster template instance is created for O-Cloud (560), and when it is ready to be used in O-Cloud (560), it can be stored in the template catalog along with the cluster template artifact.

[0144] According to one embodiment, the O-Cloud template catalog can expose cluster template instances to SMO (500) using IMS (561) through the O2ims interface. When SMO (500) requests a new O-Cloud node cluster or an updated O-Cloud node cluster, the desired cluster template can be referenced in the O2ims request. The O-Cloud node cluster can be coordinated to a declarative target provided by the referenced cluster template instance. The O-Cloud node cluster, constituent O-Cloud resources, and topology can be reflected through the O2ims inventory.

[0145] Figure 8 illustrates an example of a container infrastructure service (CIS) cluster structure and a descriptor for deploying the CIS.

[0146] Referring to Fig. 8, a container infrastructure service (CIS) structure and a descriptor for the deployment of the CIS can be defined to efficiently utilize the RAN in a container environment.

[0147] For example, a CCD (CIS cluster descriptor) (801) can be used to describe the characteristics of the cluster. A CCD (801) with specified cluster characteristics can be used for the initial installation of the CIS. A MCCO (Managed CIS Cluster Object) Declarative Descriptor (805) can be utilized for configuration during operation.

[0148] The CCD (801) may refer to a CCND (CIS cluster node descriptor) (802) that specifies the characteristics of the CIS cluster node. The CCND (802) may be referenced from the CCD (801). The CCND (802) may contain information necessary for the basic creation of the CIS cluster.

[0149] For example, CCND (802) may refer to CCNRD (CIS cluster node resource descriptor) (803). CCNRD (803) may describe resource characteristics of a CIS cluster node. In CCNRD (803), virtual machine / bare metal server, resource characteristics of a CIS cluster node, and / or resource requirements may be defined.

[0150] Template information in which requirements for infrastructure installation are data-modeled can be provided through CCNRD (803). For example, CCNRD (803) can be configured as shown in the table below.

[0151] CCNRD- Common metadata:Unique identification of the descriptor.- Information characteristics of the CIS cluster node:Machine typeCPU requirementsMemory and local disk requirementsRequirements for network interfacesAdditional resource capabilities

[0152] For example, template information modeled with basic characteristics of the infrastructure, including the infrastructure's CPU, memory, and NIC, may be provided.

[0153] According to one embodiment, in O-RAN, modeling can be performed based on an information model representing the meanings and / or relationships of abstract concepts regarding a domain and a data model representing the attributes of actual data. For example, properties for defining an information model may be configured as shown in the table below.

[0154] PropertiesThings (Modeled as Classes) with DefinitionsClass Properties (Attributes); Class RelationshipsAssociation Types (Simple Association, Aggregation, Composition, Inheritance)Multiplicity and DirectionOperations / Behaviors (optional)Represented on a Collection of Class DiagramsImplementation IndependentInterfaces - Operations, Attributes (in, out, return)

[0155] For example, entities for O-RAN-based modeling can be configured as shown in the table below.

[0156]

[0157] Referring to Table 3, additional information is required for the installation of the infrastructure (or cluster). Therefore, the following specification will describe template information for the installation of the infrastructure (or cluster).

[0158] Figure 9 illustrates an example of the configuration of a cluster template.

[0159] Referring to FIG. 9, the cluster template (900) can be modeled as a structure illustrated in FIG. 9. For example, the cluster template (900) may include server profile information, provision profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, cluster information, host information, K8s (Kubernetes) parameter information, network function information, and network function package information. For example, the information included in the cluster template (900) may be configured as shown in FIG. 9. The cluster template (900) may be referred to as template information. For example, the cluster template (900) may be an example of the template information described above.

[0160] According to one embodiment, server profile information may include hardware and software information for server installation and configuration. For example, server profile information may include information according to the table below.

[0161]

[0162] According to one embodiment, flavor profile information may include information for providing various parameter combinations to provide specific functions and network configurations. Flavor profile information may be changed and / or deleted depending on the CaaS platform type.

[0163] According to one embodiment, provisioning profile information may be configured based on a combination of software versions to be installed. For example, provisioning profile information may include information according to the table below.

[0164] Provision ProfileAttributeQualifierCardinalityContentprovision_profile_nameM1A name composed of a combination of software necessary for hardware installation.caas_verM1CaaS version to be installed.caas_patch_verM1CaaS patch version to be installed.cnf_package_versionM1CNF package version to be installed.platform_vendorM1A name of CaaS platform.

[0165] According to one embodiment, the CaaS platform profile information may include hardware information required to install the CaaS platform. The CaaS platform profile information may be changed and / or deleted depending on the CaaS platform type. For example, the CaaS platform profile information may include information according to the table below.

[0166] CaaS Platform ProfileAttributeQualifierCardinalityContentwrcp_fixed_info_nameM1WRCP fixed info name registered in FOCOM. It includes the information required for infrastructure deployment and it is different for each server model.server_modelM1Server model.oam_interfaceM1OAM interface name of the target server model.management_interfaceM1Management interface name of the target server model.cluster_host_interfaceM1Cluster-Host interface name of the target server model.cpu_numberM1Number of CPU cores of the target server model.

[0167] According to one embodiment, site information may include data regarding the site and detailed information for OAM (operation, administration, maintenance) access. For example, site information may include information according to the table below.

[0168] SiteAttributeQualifierCardinalityContentsite_nameM1The name of location to deploy to. (WRCP cluster group that defined by the customer) location1O1Location to deploy.location2O1Location to deploy.customerO1Target customer.oam_ipaddrM1Target OAM's IP address.oam_portM1Target OAM's Port number.

[0169] According to one embodiment, central cloud information may include information related to the central cloud that must be linked with FOCOM (504) and sub-clouds (or clusters). Central cloud information may be changed and / or deleted depending on the CaaS platform type. For example, central cloud information may include information according to the table below.

[0170] Central CloudAttributeQualifierCardinalityContentcentral_cloud_nameM1WRCP central cloud name to register in FOCOM. It must be unique.provision_profile_nameM1Chosen provision profile name to refer platform info.system_controller_gatewayM1system controller gateway IP address for sub cloud to access central cloudsystem_controller_subnetM1Central cloud's management network subnet.ssh_addressM1SSH address and subnet to access central cloud (CIDR)admin_usernameO1SSH username. Central cloud and its all sub-clouds use this value.admin_passwordM1SSH password. Central cloud and its all sub-clouds use this value.additional_local_registry_images_listO1,2,3,… .,nRegistry image list which can be obtained from central cloud when WRCP is installed on central cloud.

[0171] According to one embodiment, registry information may include detailed information regarding Docker images and registry access information. For example, registry information may include information according to the table below.

[0172] RegistryAttributeQualifierCardinalityContentregistry_nameM1Registry nameauthorityM1Platform type (PUSH_ENABLED / PUSH_DISABLED / HARBOR / ETC.)project_nameM1Project name. It will be used to push or pull image.registy_addressM1IP address of the registry.api_server_portM1Registry API server port.protocolM1Protocol for interface (HTTP / HTTPS)idO1Registry account ID. It is required to input just in case credential is required.passwordO1Registry account password. It is required to input just in case credential is required.

[0173] According to one embodiment, the cluster information may include initial cluster configuration information including interface and / or network configuration information for the target cluster to be installed. The cluster information may be changed and / or deleted depending on the CaaS platform type. For example, the cluster information may include information according to the table below.

[0174] ClusterAttributeQualifierCardinalityContentcluster_full_nameM1WRCP cluster full name. Cluster name must be unique.provision_profile_nameM1Chosen provision profile name to refer platform info .license_nameO1A name of a registered license file to install sub clouds.License file should be registered before installing.cluster_typeO1Cluster type to install. Select one of AIO-SX and AIO-DX.dns_serversM1DNS address list.dnsmasq_url_listM1,2,3,…,nDNS masque URL list.dnsmasq_ip_listO1,2,3,…,nDNS masque IP list.oam_floating_addressO1OAM floating (=virtual) address of cluster.If cluster type is AIO-SX, it is an OAM network IP of controller-0. If cluster type is AIO-DX, it is a virtual IP of controller nodes.oam_node0_addressM1[AIO-DX only]AN OAM network IP address of controller-0oam_node1_addressC1[AIO-DX only]An OAM network IP address of controller-1oam_gatewayC1OAM network gateway IP addressoam_subnetM1OAM network subnet with CIDR formatoam_vlanM1OAM interface VLAN ID

[0175] ClusterAttributeQualifierCardinalityContentmanagement_gatewayM1Management network gateway IP addressmanagement_subnetM1Management network subnet IP address with CIDR formatmanagement_start_addressM1Start IP address of management subnetmanagement_end_addressM1End IP address of management subnetmanagement_vlanM1Management interface VLAN IDcluster_host_subnetM1Cluster host subnet with CIDR formatcluster_host_start_addressM1Start IP address of cluster host subnetcluster_host_end_addressM1End IP address of cluster host subnetcluster_host_vlanM1Cluster host interface VLAN IDpxeboot_subnetC1[AIO-DX only] Pxeboot subnetpxeboot_start_addressC1[AIO-DX only] Start IP address of PXE subnetpxeboot_end_addressC1[AIO-DX only] End IP address of PXE subnetapi_server_portM1Cluster API server portmaster_node_idO1Cluster master node's ssh account IDmaster_node_passwordO1Cluster master node's ssh account passwordregistry_nameM1Name of the registered Registryhost_addressM1Address that worker nodes in thecluster should use to pull image from the registry

[0176] According to one embodiment, host information may include a baseboard management controller (BMC) address, access details, and information about the cluster to which it belongs. Host information may be changed and / or deleted depending on the CaaS platform type. For example, host information may include information according to the table below.

[0177] HostsAttributeQualifierCardinalityContenthost_full_nameM1WRCP host full name with {central cloud name}.{cluster name}.{host name} format. Host name must be unique for each cluster and must be one of controller-0, controller-1, and worker-X(X: 0~4)hw_profile_nameM1HW profile name to apply for each host. It contains various predefined configurations to setup bare metals- BMC firmware, BIOS firmware, BIOS settings,- SW version and its host type (CU, DU, else)* HW profiles should be created before installing.wrcp_fixed_info_nameM1CaaS platform profile name(wrcp_fixed_info_name) has information to install a CaaS platform on a host.CaaS platform profile has various information to install CaaS.- storage pci path- Interface names- HW inventory info.* CaaS platform profiles should be created before installing.flavor_profile_nameM1Flavor profile name has information to create network interface, to set PTP / GPS, and to set vDU prerequisites on a host.* Flavor profiles should be created before installing.bmc_addressM1BMC address of a bare metal. It must be registered in URL format.bmc_usernameO1BMC username to access.bmc_passwordM1BMC password to access.pxeboot_mac_addressC1[AIO-DX only] All hosts needs to be ready for PXE boot and provides a mac address of PXE activated NIC excepting a controller-0.bmc_auto_discoveryO1Enable or disable a feature to discover a BMC interface and set an IP address to it with [bmc_address] automatically.bmc_auto_discovery_mac_addressO1MAC address of BMC interface NIC. If bmc_auto_discovery is enabled, it must be registered.data_networksO1,2,3,…,nData network configuration including interface, IP address, subnet and etc.

[0178] According to one embodiment, the k8s parameter information may include a Helm chart (e.g., global value) for deploying network functions (or cloud-native network functions (CNF)) (e.g., O-CU-CP (531), O-CU-UP (532), and / or O-DU (520)). The k8s parameter information may include a Pre-chart for network configuration tasks after cluster installation. For example, the k8s parameter information may include information according to the table below.

[0179] K8s parameterAttributeQualifierCardinalityContentvalues_nameM1Logical name to identify value.yaml file.ne_typeM1A model name of installation target server.global_valueM1Global values ​​for CNF installation.prechartM1Pre helm chart values ​​to install SW package. It is used to create a service account, and configure default NADs

[0180] According to one embodiment, network function information may include configuration information required for the NFO (505) to deploy the CNF and mapping details between the cluster and the NF. For example, network function information may include information according to the table below.

[0181] Network FunctionAttributeQualifierCardinalityContentsite_nameM1A name of site that target NE will be located.provision_profile_nameM1Indicator for combination of SW will deploy.flavor_idM1A flavor profile name to apply for a host.cluster_full_nameM1WRCP cluster full name that target NE will be located.ne_idM1NE ID information .ne_typeM1Type of CNF that will need to deploy. (CU-CP / CU-UP / DU / etc.)ne_nameM1NE name.cnf_nameM1CNF name.release_node_idM1Release node ID in CNFD.namespaceO1Namespace for release.Leave it blank, If you want to use a default namespace.values_nameM1Values name to use.cnf_package_file_nameM1Target package file name.registry_key_listM1,2,3,…,nRegistry key defined in CNFD. It will be used to registry mapping for onboarding.registry_name_listM1,2,3,…,nRegistered registry name in NFO. It will be used to registry mapping for onboarding.ne_config_repository_nameM1Repository name to find location of NE configuration files.ne_config_file_nameM1NE configuration file name

[0182] According to one embodiment, network function package information may include details regarding repository access information and file locations required for the NFO (505) to download the CNF package. For example, network function package information may include information according to the table below.

[0183] Network Function PackageAttributeQualifierCardinalityContentcnf_package_file_nameM1A CNF package file name to be installed.pkg_repository_nameM1A name of repository that package is placed.file_pathO1Target package file path.If this field is empty, file path will be set to root path.

[0184] According to one embodiment, cluster IPSec information may include the location of a certification file repository for IPsec configuration and mapping information between the file and NF. For example, cluster IPSec information may include information according to the table below.

[0185] Cluster IPSecAttributeQualifierCardinalityContentipsec_cert_repo_nameO1Ipsec certificate repository name.ip_addrO1IP address to access repository.file_pathO1File path where a certificate is located.ne_ids_listO1NE_IDs to use as a argument of a installing tool.file_names_listO1Certificate file names. This values ​​should be paired with each ne_ids in the value of ne_ids_list.protocolO1sftp / http / https.idO1ID to access repository.passwordO1password to access repository.

[0186] According to one embodiment, the relationships of the information included in the cluster template (900) may be configured as shown in FIG. 9. For example, the cluster information may be related to cluster IPSec information. One cluster component according to the cluster information may be related to one cluster IPSec component according to the cluster IPSec information. For example, the cluster information may be related to central cloud information. One or more cluster components according to the cluster information may be related to one central cloud component according to the central cloud information. For example, the cluster information may be related to network function information. One cluster component according to the cluster information may be related to one or more network functions according to the network function information.

[0187] Figure 10 illustrates an example of the operation of an SMO for cluster installation.

[0188] Referring to FIG. 10, an operator (or user) of the SMO (500) can upload template information (e.g., cluster template (900) of FIG. 9) to an external server (1020) (or external repository). The service orchestration (501) can obtain (or download, receive) the template information from the external server (1020) using the SME (503). For example, the SME (503) can store location information where the template information is stored. The service orchestration (501) can query the SME (503) for the location where the template information is stored. The service orchestration (501) can obtain information regarding the location where the template information is stored from the SME (503). Based on the information regarding the location where the template information is stored, the service orchestration (501) can obtain (or download, receive) the template information.

[0189] According to one embodiment, an operator of the SMO (500) can trigger an end-to-end (E2E) installation workflow. The operator of the SMO (500) can request the end-to-end (E2E) installation workflow from the SMO (500) (or service orchestration (501)). The SMO (500) (or service orchestration (501)) can receive a request for the end-to-end (E2E) installation workflow from the operator.

[0190] Service orchestration (501) can perform the installation of an infrastructure including a platform associated with multiple network functions using FOCOM (504) and NFO (505) based on a trigger of an end-to-end (E2E) installation workflow. Service orchestration (501) can perform the deployment of multiple network functions through O-Cloud (560) based on template information. Based on the deployment of multiple network functions, multiple network functions for the RAN (1010) can be configured. The multiple network functions may include at least one of O-RU (510), O-DU (520), O-CU-CP (531), O-CU-UP (532), Near-RT RIC (540), and / or Non-RT RIC (550). Service orchestration (501) can perform cell configuration regarding O-DU (520) based on the arrangement of multiple network functions.

[0191] In FIGS. 11 to 14 below, the specific operation of the SMO (500) according to the above-described embodiment will be described later.

[0192] FIG. 11 illustrates an example of the operation of an SMO for CNF placement. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0193] Referring to FIG. 11, in operation 1101, the operator may request the SMO (500) (or service orchestration (501)) to perform an operation for CNF placement. Operation 1101 may be referred to as a Click Run operation. The operator may perform an operation for CNF placement.

[0194] In operation 1102, the service orchestration (501) may request FOCOM (504) to check the readiness status. The service orchestration (501) may request FOCOM (504) to check the readiness status for the installation of the infrastructure. Operation 1102 may be referred to as the readiness check operation.

[0195] In operation 1103, FOCOM (504) can perform verification of an infrastructure package. An infrastructure package can be used for the installation of infrastructure. Operation 1103 can be referred to as an infra PKG (package) normality check.

[0196] In operation 1104, FOCOM (504) and O-Cloud (560) (e.g., IMS (561) of O-Cloud (560)) can perform a central cloud normality check.

[0197] In operation 1105, FOCOM (504) may send a response to service orchestration (501) indicating that the installation of the infrastructure is ready. Depending on the embodiment, operation 1105 may be omitted.

[0198] In operation 1106, FOCOM (504) can perform infrastructure installation. The specific operation of operation 1106 will be described later in FIG. 12.

[0199] In operation 1107, the service orchestration (501) may request the NFO (505) to check the readiness status for CNF deployment. Operation 1107 may be referred to as the readiness check operation.

[0200] In operation 1108, the NFO (505) can perform CNF package validation. The CNF package can be used for the deployment of CNF. Operation 1108 can be referred to as CNF PKG (package) validation.

[0201] In operation 1109, the NFO (505) may send a response to the service orchestration (501) indicating that the CNF batch is ready. Depending on the embodiment, operation 1109 may be omitted.

[0202] In operation 1110, the NFO (505) can perform CNF placement. The specific operation of operation 1110 will be described later in FIG. 13.

[0203] FIG. 12 illustrates an example of an operation of an SMO for infrastructure installation. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0204] Referring to FIG. 12, operations 1211 through 1222 may be related to operation 1106 of FIG. 11. In operation 1211, the service orchestration (501) may request the FOCOM (504) to create an infrastructure. For example, the service orchestration (501) may transmit (or provide, deliver) a first information among the template information to the FOCOM (504) along with the request. The first information among the template information may be used for the installation of the infrastructure.

[0205] For example, the first information may include at least one of server profile information, provisioning profile information, flavor profile information, CaaS platform profile information, site information, central cloud information, cluster information, host information cluster IPSec information, and host information.

[0206] Service orchestration (501) can transmit (or provide, deliver) at least one of server profile information, provisioning profile information, flavor profile information, CaaS platform profile information, site information, central cloud information, cluster information, host information cluster IPSec information, and host information to FOCOM (504).

[0207] In operation 1212, FOCOM (504) and the server (1201) may perform a normality check. The server (1201) may correspond to a device on which the infrastructure is installed. FOCOM (504) may perform a normality check to install (or create) the infrastructure on the server (1201). Depending on the embodiment, operation 1212 may be performed repeatedly on candidate hosts.

[0208] Operation 1230, including operations 1213 and 1214, may be referred to as a firmware update operation. FOCOM (504) and the server (1201) may perform a firmware update operation.

[0209] For example, in operation 1213, FOCOM (504) may request the server (1201) to create infrastructure. For example, FOCOM (504) may request the server (1201) to create infrastructure regarding firmware and / or BIOS (basic input / output system) settings.

[0210] For example, in operation 1214, the server (1201) may send a response to operation 1213 to FOCOM (504). The server (1201) may send a response to FOCOM (504) indicating that the firmware and / or BIOS (basic input / output system) settings are complete. Depending on the embodiment, operation 1214 may be omitted.

[0211] Operation 1240, including operations 1215 through 1217, may be referred to as an operating system (OS) / containers-as-a-service (CaaS) installation operation. FOCOM (504), a server (1201), a platform (1202), and O-Cloud (560) may perform the OS / CaaS installation operation.

[0212] For example, in operation 1215, FOCOM (504) may request O-Cloud (560) to create infrastructure. For example, FOCOM (504) may request O-Cloud (560) to create infrastructure including an OS and / or platform.

[0213] For example, in operation 1216, O-Cloud (560) can create an infrastructure including a platform (1202) and perform infrastructure installation on a server (1201).

[0214] For example, in operation 1217, FOCOM (504) may send a response to service orchestration (501) indicating that OS installation and / or platform creation is complete.

[0215] Operation 1240, including operations 1218 through 1220, may be referred to as a CaaS configuration operation. Service orchestration (501), FOCOM (504), and platform (1202) may perform a CaaS configuration operation.

[0216] For example, in operation 1218, FOCOM (504) may request the platform (1202) to create infrastructure. FOCOM (504) may request the platform (1202) to perform a post-installation operation.

[0217] For example, in operation 1219, the platform (1202) may transmit a response to the request according to operation 1218. After the post installation operation is performed, the platform (1202) may transmit a response to the request according to operation 1218. Depending on the embodiment, operation 1219 may be omitted.

[0218] For example, in operation 1220, FOCOM (504) may send a response to service orchestration (501) indicating that the post-installation operation is complete. Depending on the embodiment, operation 1220 may be omitted.

[0219] In operation 1221, FOCOM (504) may send a response to service orchestration (501) indicating that the installation of the infrastructure is complete. Depending on the embodiment, operation 1221 may be omitted.

[0220] In operation 1222, upon completion of the installation of the infrastructure, the service orchestration (501) may provide the operator with an update on the progress. Depending on the embodiment, operation 1222 may be omitted.

[0221] FIG. 13 illustrates an example of the operation of an SMO for CNF placement. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0222] Referring to FIG. 13, operations 1301 through 1311 may be related to operation 1110 of FIG. 11. In operation 1301, the service orchestration (501) may request the NFO (505) to generate a CNF. For example, the service orchestration (501) may transmit (or provide, deliver) a second information among the template information to the NFO (505) along with the request. The second information among the template information may be used for generating a CNF.

[0223] For example, the second information among the template information may include at least one of flavor profile information, site information, registry information, K8s parameter information, cluster information, network function information, and network function package information.

[0224] The service orchestration (501) can transmit (or provide, deliver) at least one of flavor profile information, site information, registry information, K8s parameter information, cluster information, network function information, and network function package information to the NFO (505).

[0225] In operation 1302, the NFO (505) can perform registration of clusters and registries. The NFO (505) can perform registration of clusters and registries based on the second information among the template information.

[0226] In operation 1303, the NFO (505) can onboard container images onto the platform (1202). The container images can be used for the deployment of the CNF.

[0227] In operation 1304, the NFO (505) may transmit (or transmit, provide) a response to the service orchestration (501) indicating that preparation for CNF placement is complete. Depending on the embodiment, operation 1304 may be omitted.

[0228] Operation 1320, including operations 1305 through 1310, may be referred to as a CNS pod installation operation. For example, service orchestration (501), NFO (505), RAN NF CM (502), platform (1202), and O-Cloud (560) may perform a CNS pod installation operation.

[0229] For example, in operation 1305, the service orchestration (501) may request the NFO (505) to perform an operation for the instantiation of the CNF.

[0230] For example, in operation 1306, NFO (505) can deploy K8s resources for CNF. For example, NFO (505) can deploy at least one pod (or resources for at least one pod) for CNF.

[0231] For example, in operation 1307, the platform (1202) and O-Cloud (560) can create at least one pod for CNF (e.g., vDU, O-DU (520)).

[0232] For example, in operation 1308, the platform (1202) may send (or provide, deliver) a response to the NFO (505) indicating that at least one pod for the CNF (e.g., vDU, O-DU (520)) has been created. Depending on the embodiment, operation 1308 may be omitted.

[0233] For example, in operation 1309, O-Cloud (560) may transmit (or provide, deliver) information to RAN NF CM (502) instructing RAN NF CM (502) to trigger a CNF registration event. For example, a CNF (e.g., vDU, O-DU (520)) may announce its presence within O-Cloud (560) and register its location on the network. Through CNF registration, the CNF can perform operations with other network functions.

[0234] For example, in operation 1310, the NFO (505) and service orchestration (501) can complete the instantiation of the CNF.

[0235] In operation 1311, upon completion of the instantiation of the CNF, the service orchestration (501) may provide the operator with an update on the progress. Depending on the embodiment, operation 1311 may be omitted.

[0236] FIG. 14 illustrates an example of the operation of an SMO for cell configuration. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0237] Referring to FIG. 14, in operation 1411, the service orchestration (501) may request the RAN NF CM (502) to create an NE and / or cell (or configure a cell). For example, the service orchestration (501) may transmit (or provide, deliver) a third information among the template information to the RAN NF CM (502) along with the request. The third information among the template information may be used for creating an NE and / or cell (or configure a cell).

[0238] For example, the third information among the template information may include at least one of site information and network function information. The service orchestration (501) may transmit (or provide, deliver) at least one of the site information and network function information to the RAN NF CM (502).

[0239] In operation 1412, the RAN NF CM (502) may request a vDU (1401) (or O-DU (520)) to perform an NE / cell grow. The vDU (1401) may perform the NE / cell grow using network resources, depending on the request. The NE / cell grow may be performed for NE and / or cell configuration.

[0240] In operation 1413, the vDU (1401) may send a response to the RAN NF CM (502) indicating the completion of the NE / cell grow. Depending on the embodiment, operation 1413 may be omitted.

[0241] In operation 1414, the RAN NF CM (502) may transmit (or provide, deliver) a response to the service orchestration (501) indicating that an NE / cell has been created. Depending on the embodiment, operation 1414 may be omitted.

[0242] In operation 1415, the service orchestration (501) can request the RAN NF CM (502) to configure the NE.

[0243] In operation 1416, the RAN NF CM (502) may request the vDU (1401) to perform an operation for NE configuration (e.g., GPL (general public license)) (or cell configuration). The vDU (1401) may perform an operation for NE configuration (or cell configuration) based on the request.

[0244] In operation 1417, the vDU (1401) may transmit (or provide, deliver) a response to the RAN NF CM (502) regarding the completion of the NE configuration (or cell configuration). Depending on the embodiment, operation 1417 may be omitted.

[0245] In operation 1418, the RAN NF CM (502) may transmit (or provide, deliver) a response to the service orchestration (501) regarding the completion of the NE configuration (or cell configuration). Depending on the embodiment, operation 1418 may be omitted.

[0246] Operation 1420, including the above-described operations 1411 to 1418, may be referred to as a virtualized RAN (vRAN) configuration operation. Operation 1420 may be performed for the installation of other network functions (or CNFs) as well as vDU (1401).

[0247] In operation 1419, upon completion of the NE / cell configuration, the service orchestration (501) may provide the operator with an update on the progress. Depending on the embodiment, operation 1419 may be omitted.

[0248] FIG. 15 illustrates a flowchart regarding the operation of a device for SMO. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0249] Referring to FIG. 15, in operation 1501, a device for SMO (500) (hereinafter SMO (500)) can perform the installation of an infrastructure including a platform related to multiple network functions. For example, SMO (500) can perform the installation of an infrastructure including a platform related to multiple functions through O-Cloud (560) based on template information. For example, SMO (500) can perform the installation of an infrastructure including a platform related to multiple functions on a server or CaaS. For example, operation 1501 may be related to operations 1211 to 1222 of FIG. 12.

[0250] According to one embodiment, a plurality of network functions may include at least one of O-RU (510), O-DU (520), O-CU-CP (531), O-CU-UP (532), Near-RT RIC (540), and / or Non-RT RIC (550).

[0251] According to one embodiment, the SMO (500) can obtain template information by receiving template information from an external server (e.g., the external server (1020) of FIG. 10). Template

[0252] According to one embodiment, SMO (500) can perform the installation of infrastructure based on the first information among the template information through the IMS (561) of O-Cloud (560).

[0253] For example, template information may include server profile information, provision profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, K8s parameter information, cluster information, host information, network function information, and network function package information.

[0254] For example, template information can be configured based on server profile information, provision profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, K8s parameter information, cluster information, host information, network function information, and network function package information.

[0255] For example, the first information among the template information may include at least one of server profile information, provisioning profile information, flavor profile information, site information, central cloud information, cluster information, cluster IPSec (internet protocol security) information, and host information.

[0256] For example, the cluster template (900) of FIG. 9 may be an example of template information. The relationships of the information included in the template information may be configured as in the cluster template (900) of FIG. 9. For example, the cluster information may be related to cluster IPSec information. One cluster component according to the cluster information may be related to one cluster IPSec component according to the cluster IPSec information. For example, the cluster information may be related to central cloud information. One or more cluster components according to the cluster information may be related to one central cloud component according to the central cloud information. For example, the cluster information may be related to network function information. One cluster component according to the cluster information may be related to one or more network functions according to the network function information.

[0257] In operation 1502, SMO (500) can perform the deployment of multiple network functions. For example, SMO (500) can perform the deployment of multiple network functions through O-Cloud (560) based on template information. For example, multiple network functions can be instantiate based on the deployment of multiple network functions. For example, operation 1502 may be related to operations 1301 through 1311 of FIG. 13.

[0258] According to one embodiment, SMO (500) can perform the deployment of multiple network functions through DMS (562) of O-Cloud (560). For example, SMO (500) can perform the deployment of multiple network functions through DMS (562) of O-Cloud (560) based on second information among template information.

[0259] For example, the second information among the template information may include at least one of flavor profile information, site information, registry information, K8s parameter information, cluster information, network function information, and the network function package information.

[0260] In operation 1503, the SMO (500) can perform cell configuration regarding the DU (e.g., the O-DU (520) of FIG. 5 or the vDU (1401) of FIG. 14). For example, the SMO (500) can perform cell configuration regarding the DU based on the arrangement of multiple network functions.

[0261] According to one embodiment, the SMO (500) can perform cell configuration regarding the DU based on third information among the template information. For example, the SMO (500) can perform cell configuration regarding the DU based on third information among the template information by using a DU arranged according to the arrangement of a plurality of network functions. For example, the third information among the template information may include at least one of site information and network function information.

[0262] According to one embodiment, SMO (500) may include at least one of service orchestration (501) (or a function block for service orchestration), SMO (500) (or a function block for SME), FOCOM (504) (or a function block for FOCOM), RAN NF CM (502) (or a function block for RAN NF CM), and / or NFO (505) (or a function block for NFO).

[0263] Figure 16a illustrates an example of the NFV (network function virtualization)-MANO (management and orchestration) architecture framework of the 3GPP (3rd generation partnership project).

[0264] FIG. 16b illustrates an example of the NFV-MANO architecture framework of the European Telecommunications Standards Institute (ETSI) according to embodiments.

[0265] Referring to Figures 16a and 16b, 3GPP and ETSI define the same network elements and the same reference points for the NFV-MANO architecture framework. The same names (e.g., VNFM (virtualized network function manager), VIM (virtualized infrastructure manager), NFVO (NFV orchestrator)) and the same reference points (e.g., Ve-VNFM-em, Ve-Vnfm-vnf) refer to the same interface.

[0266] Physical mobile network management can primarily rely on the interface Itf-N. ​​With the introduction of NFV, mobile network management can specify virtualized network function management. Mobile network management may involve not only a single interface Itf-N but also interactions with NFV-MANOs performed through defined reference points. A mobile network can be composed of physical network elements and virtual network elements. Application-related aspects of virtual network functions (VNFs) and physical network functions (PNFs) corresponding to physical NEs can be managed by the 3GPP management system.

[0267] To extend management capabilities for virtualized networks and VNFs, Network Managers (NMs), Network Managers (NMs), and Element Managers (EMs) may be defined in the 3GPP management system. An NM is one of the roles of an Operating Support System (OSS) / BSS and is a consumer of the reference point OS-MA-NFVO. According to 3GPP specifications, an NM can perform one of the roles of an OSS / BSS. A Network Manager (DM) can provide element management and domain management functions for subnetworks. Interconnected domain managers can provide multi-vendor and multi-technology network management functions. An EM can provide end-user function packages for managing sets of closely related types of network elements. An EM can support element management and subnetwork management functions. If an EM supports extension functions, it can manage at least one of a PNF or a VNF.

[0268] An NFV-MANO may include an NFV orchestrator (NFV orchestrator), a VNFM (VNF manager), and a VIM (virtualized infrastructure manager). The NFVO is a functional block designed to ensure the optimized allocation of necessary resources and connectivity by managing the network service lifecycle and coordinating the management of the NS lifecycle, VNF lifecycle (supported by VNFM), and NFVI resources (supported by VIM). The VNFM is a functional block responsible for managing the VNF lifecycle. The VIM is a functional block that typically controls and manages NFVI computing, storage, and network resources within an operator's infrastructure domain (e.g., NFVI).

[0269] According to one embodiment, Os-Ma-nfvo can be used for NS lifecycle management, NS performance management, NS failure management, NSD management, and VNF package management generated by NFVO. According to one embodiment, Ve-VNFM-em and Ve-Vnfm-vnf can be used primarily for VNF lifecycle management, VNF and VR failure information transmission, or performance measurement information and virtualization configuration, etc.

[0270] The MANO of a VNF may include fault management, configuration management, accounting management, performance management, and security management (FCAPS). Furthermore, due to the separation of network functions from the physical infrastructure used, a new set of management functions focused on the creation and lifecycle management of virtualized resources required for the VNF can be acquired. This set of management functions may be referred to as VNF management. VNF management includes the following tasks and can be responsible for the lifecycle management of the VNF.

[0271] 1) Instantiation of a VNF (Creating a VNF using VNF on-boarding artifacts).

[0272] 2) VNF scaling (increase or decrease VNF capacity).

[0273] 3) Updates and / or upgrades to the VNF (support for changes to VNF software and / or configurations of varying complexity).

[0274] 4) Termination of VNF (releases VNF-related NFVI resources and returns to the NFVI resource pool).

[0275] NFV-MANO consists of NFVO, VNFM, and VIM; while the roles of each component differ slightly, all components share the common goal of VNF lifecycle management. NFV-MANO can be responsible for overall VNF management from the time a VNF is created until it is deleted. As described above, VNF lifecycle management can include various functions. For example, VNF lifecycle management may include functions to create (i.e., instantiate) and delete (i.e., terminate) VNFs. Additionally, VNF lifecycle management may include scale-out / in functions to increase or decrease the number of VNF components (VNFCs) within a VNF, and functions to upgrade the VNF's software. For example, the operations for lifecycle management are defined in the ETSI GR NFV-MAN specification as follows.

[0276] OperationsDescriptionNotesInstantiate VNFThis operation allows creating a VNF instance.Query VNFThis operation allows retrieving VNF instance state and attributes.Attributes returned can include for example number and location of VMs allocated to the VNF instance.Scale VNFThis operation allows scaling (out / in, up / down) a VNF instance.Check VNF instantiation feasibilityThis operation allows verifying if the VNF instantiation is possible.No VNF instance is created as a result of the operation.Heal VNFThis operation is used to request appropriate correction actions in reaction to a failure.This assumes operational behaviour for healing actions by VNFM has been described in the VNFD. An example could be switching between active and standby mode.Update VNF softwareThis operation allows applying a minor / limited software update (e.g. patch) to a VNF instance.The software update implies no structural changes (e.g. in configuration, topology, behaviour, redundancy model).The goal is to not require termination / re-instantiation, or at least not for the entire VNF.This operation is only required if the software update procedure requires a change in the VNF infrastructure e.g. changing an image. Software updates that can be performed using solely pre-existing functional blocks (e.g. EM) could not invoke this operation.Modify VNFThis operation allows making structural changes (e.g. configuration, topology,behaviour, redundancy model) to a VNF instance.This could be expected to be designed as a transaction, rather than an atomic operation.Depending on the "modification plan", it could involve multiple catalogue Management and VNF lifecycle management atomic operations, and could involve multiple VNFM managers. It is possible that this transaction cannot be exposed as an operation by the VNFM, and only offered as an extension when exposed by the NFVO.Upgrade VNF softwareThis operation allows deploying a new software release to a VNF instance.This could be expected to be designed as a transaction, rather than an atomic operation.Depending on the "software upgrade plan", it could involvemultiple catalogue Management and VNF lifecycle management atomic operations, and could involve multiple VNFM managers. It is possible that this transaction cannot be exposed as an operation by the VNFM, and only offered as an extension when exposed by the NFVO. This operation is only required if the software upgrade procedure requires a change in the VNF infrastructure e.g. changing an image. Software upgrades that can beperformed using solely pre-existing functional blocks(e.g. EM) could not invoke this operation.Terminate VNFThis operation allows terminating gracefully or forcefully a previously created VNF instance.

[0277] A VNF (or EMS, NE) instantiately created through a MANO system can receive 'LCM (lifecycle management) change notifications' from the MANO system. By receiving 'LCM Change notifications' from the MANO system, the VNF (or EMS, NE) can receive reports on how its lifecycle is being managed by the MANO system (or infra system) that manages it (i.e., the VNF). To receive 'LCM Change notifications', the VNF must be subscribed to the corresponding MANO system. For example, the VNF can request a subscription from a VNFM within the MANO system. The VNFM can register the said VNF in a subscription list it manages. After registering the said VNF in the subscription list, the VNFM can send a notification to the VNF when a change occurs regarding the lifecycle related to the said VNF.

[0278] According to one embodiment, a device for service management and orchestration (SMO) may include a memory comprising instructions and one or more storage media, and at least one processor comprising a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the device may perform the installation of an infrastructure comprising a platform related to a plurality of network functions, including a central unit (CU) and a distributed unit (DU), via an open radio access network-cloud (O-cloud) based on template information stored in the memory, perform the deployment of the plurality of network functions via the O-cloud based on the template information stored in the memory, and perform cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0279] For example, the above template information may include server profile information, provision profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, cluster information, host information, network function information, and network function package information.

[0280] For example, when the above instructions are executed individually or collectively by the at least one processor, they may cause the device to perform the installation of the infrastructure through the infrastructure management services (IMS) of the O-cloud.

[0281] For example, when the above instructions are executed individually or collectively by the at least one processor, the device may be caused to perform the installation of the infrastructure based on the first information among the template information through the infrastructure management service of the O-cloud. The first information among the template information may include at least one of the server profile information, the provisioning profile information, the flavor profile information, the site information, the central cloud information, the cluster information, the cluster IPSec (internet protocol security) information, and the host information.

[0282] For example, when the above instructions are executed individually or collectively by the at least one processor, the device may cause the deployment of the plurality of network functions through the deployment management services (DMS) of the O-cloud.

[0283] For example, when the above instructions are executed individually or collectively by the at least one processor, the device may be caused to perform the deployment of the plurality of network functions based on the second information among the template information through the deployment management service of the O-cloud. The second information among the template information may include at least one of the flavor profile information, the site information, the registry information, the cluster information, the network function information, and the network function package information.

[0284] For example, when the above instructions are executed individually or collectively by the at least one processor, the device may be caused to perform the cell configuration regarding the DU based on the third information among the template information. The third information among the template information may include at least one of the site information and the network function information.

[0285] For example, the above instructions may cause the device to receive the template information from an external server when executed individually or collectively by the at least one processor.

[0286] For example, the above SMO may include at least one of a function block for service orchestration, a function block for service management and exposure (SME), a function block for federated O-cloud orchestration and management (FOCOM), a function block for radio access network network function configuration management (RAN NF CM), and a function block for network function orchestrator (NFO).

[0287] For example, the plurality of network functions may be instantiate based on the arrangement of the plurality of network functions.

[0288] According to one embodiment, a method performed by a device for service management and orchestration (SMO) may include: an operation of performing an installation of an infrastructure including a platform related to a plurality of network functions including a central unit (CU) and a distributed unit (DU) via an open radio access network-cloud based on template information stored in the memory of the device; an operation of performing a deployment of the plurality of network functions via the open radio access network-cloud based on the template information stored in the memory; and an operation of performing a cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0289] For example, the above template information may include server profile information, provisioning profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, cluster information, host information, network function information, and network function package information.

[0290] For example, the above method may include the operation of performing the installation of the infrastructure through the infrastructure management services (IMS) of the O-cloud.

[0291] For example, the above method may include an operation of performing the installation of the infrastructure based on the first information among the template information through the infrastructure management service of the O-cloud. The first information among the template information may include at least one of the server profile information, the provisioning profile information, the flavor profile information, the site information, the central cloud information, the cluster IPSec (internet protocol security) information, and the host information.

[0292] For example, the above method may include an operation of performing the deployment of the plurality of network functions through the deployment management services (DMS) of the O-cloud.

[0293] For example, the above method may include an operation of performing the deployment of the plurality of network functions based on the second information among the template information through the deployment management service of the O-cloud. The second information among the template information may include at least one of the flavor profile information, the site information, the registry information, the cluster information, the network function information, and the network function package information.

[0294] For example, the above method may include an operation to perform the cell configuration regarding the DU based on the third information among the template information. The third information among the template information may include at least one of the site information and the network function information.

[0295] For example, the above method may include the operation of receiving the template information from an external server.

[0296] For example, the above SMO may include at least one of a function block for service orchestration, a function block for service management and exposure (SME), a function block for federated O-cloud orchestration and management (FOCOM), a function block for radio access network network function configuration management (RAN NF CM), and a function block for network function orchestrator (NFO).

[0297] According to one embodiment, a non-transient computer-readable storage medium may store one or more programs. The one or more programs may include instructions that, when executed by at least one processor of a device for service management and orchestration (SMO), cause the device to perform the installation of an infrastructure including a platform associated with a plurality of network functions, including a central unit (CU) and a distributed unit (DU), via an open radio access network-cloud (O-cloud) based on template information, perform the deployment of the plurality of network functions via the O-cloud based on the template information, and perform cell configuration regarding the DU based on the deployment of the plurality of network functions.

[0298] Methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0299] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of this disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store (e.g., Play Store) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0300] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0301] Additionally, the program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, LAN (local area network), WAN (wide area network), or SAN (storage area network), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present disclosure.

[0302] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0303] According to embodiments, one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added. Generally or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components in the same or similar manner as those performed by the corresponding component among the plurality of components prior to integration. According to embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0304] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure.

Claims

1. In a device for service management and orchestration (SMO), Memory comprising instructions and one or more storage media; At least one processor including a processing circuit; and When the above instructions are executed individually or collectively by the at least one processor, Based on the template information stored in the memory above, the installation of an infrastructure including a platform related to a plurality of network functions, including a central unit (CU) and a distributed unit (DU), is performed via the O-cloud (open radio access network-cloud), and Based on the template information stored in the memory, the deployment of the plurality of network functions is performed through the O-cloud, and Causing the device to perform cell configuration regarding the DU based on the arrangement of the plurality of network functions above, device.

2. In claim 1, the template information is, Including server profile information, provision profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, cluster information, host information, network function information, and network function package information, device.

3. In claim 2, when the instructions are executed individually or collectively by the at least one processor, Causing the device to perform the installation of the infrastructure through the infrastructure management services (IMS) of the above O-Cloud, device.

4. In claim 3, when the instructions are executed individually or collectively by the at least one processor, The device is induced to perform the installation of the infrastructure based on the first information among the template information through the infrastructure management service of the above O-Cloud, and Among the above template information, the above first information is, at least one of the above server profile information, the above provisioning profile information, the above flavor profile information, the above site information, the above central cloud information, the above cluster information, the above cluster IPSec (internet protocol security) information, and the above host information, device.

5. In claim 2, when the instructions are executed individually or collectively by the at least one processor, Causing the device to perform the deployment of the plurality of network functions through the deployment management services (DMS) of the above O-Cloud, device.

6. In claim 5, when the instructions are executed individually or collectively by the at least one processor, The device is caused to perform the deployment of the plurality of network functions based on the second information among the template information through the deployment management service of the above O-cloud, and Among the above template information, the above second information is, at least one of the above flavor profile information, above site information, above registry information, above cluster information, above network function information, and above network function package information, device.

7. In claim 2, when the instructions are executed individually or collectively by the at least one processor, Based on the third information among the above template information, the device is caused to perform the cell configuration regarding the DU, and The third information among the above template information is, at least one of the above site information and the above network function information, device.

8. In claim 2, when the instructions are executed individually or collectively by the at least one processor, Causing the device to receive the above template information from an external server, device.

9. In claim 1, the above SMO is, A function block comprising at least one of a function block for service orchestration, a function block for SME (service management and exposure), a function block for FOCOM (federated O-cloud orchestration and management), a function block for RAN NF CM (radio access network network function configuration management), and a function block for NFO (network function orchestrator). device.

10. In claim 1, the plurality of network functions are instantiates based on the arrangement of the plurality of network functions, device.

11. A method performed by a device for service management and orchestration (SMO), An operation of performing the installation of an infrastructure including a platform related to a plurality of network functions, including a central unit (CU) and a distributed unit (DU), via an O-cloud (open radio access network-cloud), based on template information stored in the memory of the above device; An operation to perform the deployment of the plurality of network functions through the O-cloud based on the template information stored in the memory; and Based on the arrangement of the plurality of network functions, the operation of performing cell configuration regarding the DU method.

12. In claim 11, the template information is, Including server profile information, provisioning profile information, flavor profile information, site information, central cloud information, cluster IPSec (internet protocol security) information, registry information, cluster information, host information, network function information, and network function package information, method.

13. In claim 12, the above method is, The operation of performing the installation of the infrastructure through the infrastructure management services (IMS) of the above O-Cloud, method.

14. In claim 13, the above method is, The method includes an operation of performing the installation of the infrastructure based on the first information among the template information through the infrastructure management service of the above O-Cloud, and Among the above template information, the above first information is, at least one of the above server profile information, the above provisioning profile information, the above flavor profile information, the above site information, the above central cloud information, the above cluster IPSec (internet protocol security) information, and the above host information, method.

15. In a non-transient computer-readable storage medium storing one or more programs, said one or more programs, when executed by at least one processor of a device for service management and orchestration (SMO), Based on template information, perform the installation of an infrastructure including a platform related to multiple network functions, including a central unit (CU) and a distributed unit (DU), via the O-cloud (open radio access network-cloud), and Based on the above template information, the deployment of the plurality of network functions is performed through the above O-Cloud, and Based on the arrangement of the plurality of network functions, the device includes instructions that cause the device to perform cell configuration regarding the DU. Non-transient computer-readable storage media.

Images