Electronic apparatus and method for managing session

Abstract

According to one embodiment, a radio unit (RU) comprises: a transceiver; a memory for storing instructions; and a processor. The instructions, when executed by the processor, cause the RU to establish a first session and a second session with a client server including at least one of a distributed unit (DU) or a service management and orchestration (SMO). The instructions, when executed by the processor, cause the RU to transmit or receive at least one first message for an operation for supervision to or from the client server through the first session. The instructions, when executed by the processor, cause the RU to transmit or receive, to or from the client server through the second session, at least one second message for an operation for a management plane between the DU and the RU while the at least one first message is transmitted or received through the first session.

Description

Electronic devices and methods for managing sessions

[0001] The present disclosure relates to an electronic device and method for managing a session.

[0002] As transmission capacity increases in wireless communication systems, functional splitting, which functionally separates base stations, is being implemented. Through functional splitting, base stations can be divided into distributed units (DUs) and radio units (RUs). A fronthaul interface is defined for communication between DUs and RUs.

[0003] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

[0004] According to one embodiment, a radio unit (RU) may include a transceiver, a memory storing instructions, and a processor. The instructions, when executed by the processor, may cause the RU to establish a first session and a second session distinct from the first session with a client server including at least one of a distributed unit (DU) or a service management and orchestration (SMO). The instructions, when executed by the processor, may cause the RU to transmit to or receive from the client server at least one first message for supervision operations through the first session. The instructions, when executed by the processor, may cause the RU to transmit to or receive from the client server, via the second session, at least one second message for operation on a management plane (M-plane) between the DU and the RU, while the at least one first message is transmitted or received via the first session.

[0005] According to one embodiment, a method performed in a radio unit (RU) may include establishing a first session and a second session distinct from the first session with a client server including at least one of a distributed unit (DU) or a service management and orchestration (SMO). The method may include transmitting to or receiving from the client server, through the first session, at least one first message for an operation for supervision. The method may include transmitting to or receiving from the client server, through the second session, at least one second message for an operation for a management plane (M-plane) between the DU and the RU, while the at least one first message is transmitted or received through the first session.

[0006] According to one embodiment, a client server may include a transceiver, a memory storing instructions, and a processor. The instructions, when executed by the processor, may cause the client server to establish a first session with a radio unit (RU) and a second session distinct from the first session. The instructions, when executed by the processor, may cause the client server to transmit to or receive from the RU, through the first session, at least one first message for operation on supervision. The instructions, when executed by the processor, may cause the client server to transmit to or receive from the RU, through the second session, at least one second message for operation on a management plane (M-plane) between a distributed unit (DU) and the RU, while the at least one first message is transmitted or received through the first session.

[0007] According to one embodiment, a method performed on a client server may include establishing a first session with a radio unit (RU) and a second session distinct from the first session. The method may include transmitting to or receiving from the RU, through the first session, at least one first message for an operation for supervision. The method may include transmitting to or receiving from the RU, through the second session, at least one second message for an operation for a management plane (M-plane) between a distributed unit (DU) and the RU, while the at least one first message is transmitted or received through the first session.

[0008] Figure 1 illustrates a wireless communication system.

[0009] Figure 2a illustrates a front-hole interface.

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

[0011] Figure 3a illustrates the functional configuration of a distributed unit (DU).

[0012] Figure 3b illustrates the functional configuration of a RU (radio unit).

[0013] Figure 4 illustrates an example of function split between DU and RU.

[0014] Figure 5 illustrates an example of an architecture for functional separation between DU and RU.

[0015] Figure 6a illustrates an example of a management plane configured based on a hierarchical model.

[0016] Figure 6b illustrates an example of a management plane configured based on a hybrid model.

[0017] Figure 7 illustrates examples of management plane interfaces.

[0018] Figure 8 illustrates an example of the operation for a "start up" installation.

[0019] Figure 9 illustrates an example of an operation related to “call home.”

[0020] Figure 10 illustrates an example of an operation for monitoring a NETCONF connection.

[0021] Figure 11a illustrates an example of a session for operations on the supervisory and management planes.

[0022] Figure 11b illustrates an example of operations performed on the supervisory and management planes in one session.

[0023] Figure 12a illustrates an example of the operation of a NETCONF server and a NETCONF client establishing two NETCONF sessions.

[0024] Figure 12b illustrates an example of the operation of a NETCONF server and a NETCONF client establishing two NETCONF sessions.

[0025] Figure 13a illustrates an example of a session for supervision and a session for operation on the management plane.

[0026] Figure 13b illustrates an example of operations performed on the supervisory and management planes in two sessions.

[0027] Figure 14 shows a flowchart regarding the operation of RU.

[0028] Figure 15 illustrates a flowchart regarding the operation of a client server.

[0029] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0030] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0031] In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms for operational 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 components of devices, etc. are examples for convenience of description. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0032] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}.

[0033] Although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0034] Figure 1 illustrates a wireless communication system.

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

[0036] The base station (110) is a network infrastructure that provides wireless access to the terminal (120). The base station (110) has coverage defined based on the distance at which a signal can be transmitted. In addition to the base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5th generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having equivalent technical meanings.

[0037] The terminal (120) is a device used by a user and communicates with the 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). In addition, although not shown in FIG. 1, the terminal (120) and another terminal may 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 the involvement of a user. According to one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. Additionally, according to one embodiment, the terminal (120) may be an NB (narrowband)-IoT (internet of things) device.

[0038] The terminal (120) may be referred to as a terminal, or other terms such 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 equivalent technical meanings.

[0039] The base station (110) and the terminal (120) can perform beamforming. 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). In addition, 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), 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, the beamforming can include transmission beamforming and reception beamforming. The base station (110) and the terminal (120) can impart directionality to the transmitted or 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 resources that have a QCL relationship with the resource that transmitted the serving beams.

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

[0041] Although both the base station (110) and the terminal (120) are described as performing beamforming in FIG. 1, the embodiments of the present disclosure are not necessarily limited thereto. In some embodiments, the terminal may or may not perform beamforming. Furthermore, the base station may or may not perform beamforming. That is, either only one of the base station and the terminal may perform beamforming, or neither the base station nor the terminal may perform beamforming.

[0042] In the present disclosure, a beam refers to a spatial flow of a signal in a wireless channel, and is formed by one or more antennas (or antenna elements), and this forming process may be referred to as beamforming. Beamforming may include at least one of analog beamforming and digital beamforming (e.g., precoding). Reference signals 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), and a sounding reference signal (SRS). In addition, as a configuration for each reference signal, an IE such as a CSI-RS resource or an SRS-resource may be used, and this configuration may include information associated with the beam. Information associated with a beam may mean whether the configuration (e.g., a CSI-RS resource) uses the same spatial domain filter as another configuration (e.g., another CSI-RS resource within the same CSI-RS resource set) or a different spatial domain filter, or whether it is quasi-co-located (QCL) with a reference signal, and if so, what type it is (e.g., QCL type A, B, C, D).

[0043] In the past, in communication systems with relatively large cell radius of base stations, each base station was installed to include the functions of a digital processing unit (or distributed unit (DU)) and a radio frequency (RF) processing unit (or radio unit (RU)). However, as higher frequency bands are used in 4G (4th generation) and / or subsequent communication systems (e.g., 5G) and the cell coverage of base stations decreases, the number of base stations to cover a specific area has increased. The installation costs for operators to install base stations have also increased. In order to minimize the installation costs of base stations, a structure has been proposed in which the DU and RU of a base station are separated, one or more RUs are connected to one DU via a wired network, and one or more RUs are geographically distributed to cover a specific area. Hereinafter, the deployment structure and expanded examples of base stations according to various embodiments of the present disclosure are described through FIGS. 2A and 2B.

[0044] FIG. 2A illustrates a fronthaul interface. Unlike the backhaul between a base station and a core network, fronthaul refers to the connection between entities between a wireless LAN and a base station. FIG. 2A illustrates an example of a fronthaul structure between a DU (210) and one RU (220), but this is merely for convenience of explanation and the present disclosure is not limited thereto. In other words, embodiments of the present disclosure can also be applied to a fronthaul structure between one DU and multiple RUs. For example, embodiments of the present disclosure can be applied to a fronthaul structure between one DU and two RUs. Furthermore, embodiments of the present disclosure can also be applied to a fronthaul structure between one DU and three RUs.

[0045] Referring to FIG. 2A, a base station (110) may include a DU (210) and an RU (220). A fronthaul (215) between the DU (210) and the RU (220) may be operated via an FX interface. For operation of the fronthaul (215), an interface such as an enhanced common public radio interface (eCPRI) or radio over ethernet (ROE) may be used, for example.

[0046] As communications technology advances, mobile data traffic increases, significantly increasing the bandwidth requirements for the fronthaul between the digital unit and the radio unit. In deployments such as C-RAN (centralized / cloud radio access network), the DU performs functions for the packet data convergence protocol (PDCP), radio link control (RLC), media access control (MAC), and physical layer (PHY), while the RU can be implemented to perform additional functions for the PHY layer in addition to its radio frequency (RF) functions.

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

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

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

[0050] A centralized unit (CU) can be connected to one or more DUs and can be responsible for functions at a higher layer than the DU. For example, the CU can be responsible for functions at the RRC (radio resource control) and PDCP (packet data convergence protocol) layers, while the DU and RU can be responsible for functions at lower layers. The DU can perform some functions (high PHY) of the RLC (radio link control), MAC (media access control), and PHY (physical) layers, while the RU can be responsible for the remaining functions (low PHY) of the PHY layer. In addition, for example, a digital unit (DU) can be included in a distributed unit (DU) depending on the implementation of a distributed deployment of the base station. Hereinafter, unless otherwise defined, the operations of DU (digital unit) and RU are described, but various embodiments of the present disclosure can be applied to both a base station deployment including CU and a deployment in which DU is directly connected to the core network (i.e., a base station in which CU and DU are integrated as a single entity (e.g., NG-RAN node)).

[0051] Figure 2b illustrates the fronthaul interface of an open RAN (radio access network). A base station (110) according to a distributed deployment is exemplified as an eNB or gNB.

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

[0053] The O-DU (251) is a logical node that includes functions, excluding functions exclusively assigned to the O-RU (253-1), among the functions of a base station (e.g., eNB, gNB) according to FIG. 4 described below. 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 that includes a subset of the functions of a 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).

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

[0055] In FIG. 2B, to explain the O-RAN, entities of the base station (110) are described as O-DU and O-RU. However, these names are not to be construed as limiting the embodiments of the present disclosure. In the embodiments described below, it is obvious that the operations of the DU (210) can be performed by the O-DU (251). The description of the DU (210) can be applied to the O-DU (251). Similarly, in the embodiments described below, it is obvious that the operations of the RU (220) can be performed by the O-RU (253-1). The description of the RU (220) can be applied to the O-DU (253-1).

[0056] Fig. 3a illustrates the functional configuration of a DU (distributed unit). The configuration illustrated in Fig. 3a can be understood as the configuration of the DU (210) of Fig. 2a (or the O-DU (250) of Fig. 2b) as part of a base station. Terms such as "...unit" and "...unit" used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0057] Referring to FIG. 3a, DU (210) includes a transceiver (310), memory (320), and processor (330).

[0058] The transceiver (310) can perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (310) can include a wired interface for controlling direct connections between devices via a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (310) can transmit electrical signals to other devices via copper wire, or perform conversion between electrical signals and optical signals. The DU (210) can communicate with a radio unit (RU) via the transceiver (310). The DU (210) can be connected to a core network or a CU in a distributed arrangement via the transceiver (310).

[0059] The transceiver (310) may perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (310) may perform a conversion function between a baseband signal and a bit stream 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 stream. In addition, when receiving data, the transceiver (310) restores the received bit stream by demodulating and decoding the baseband signal. In addition, the transceiver (310) may include multiple transmission and reception paths. Furthermore, according to one embodiment, the transceiver (310) may be connected to the core network or other nodes (e.g., an integrated access backhaul (IAB).

[0060] 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 management 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 illustrated in FIG. 3A, in other implementations, the DU (210) may include two or more transceivers.

[0061] 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," a "transmitter," a "receiver," or a "transmitter-receiver unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that the transceiver (310) performs the processing described above.

[0062] Although not illustrated in FIG. 3A, the transceiver (310) may further include a backhaul transceiver for connection to the core network or other base stations. The backhaul transceiver provides an interface for communicating with other nodes within the network. That is, the backhaul transceiver converts a bit stream transmitted from the base station to other nodes, such as other access nodes, other base stations, upper nodes, the core network, etc., into a physical signal, and converts a physical signal received from other nodes into a bit stream.

[0063] The memory (320) stores data such as basic programs, application programs, and setting information for the operation of the DU (210). The memory (320) may be referred to as a storage unit. The memory (320) may be composed of volatile memory, nonvolatile memory, or a combination of volatile memory and nonvolatile memory. In addition, the memory (320) provides stored data upon request from the processor (330).

[0064] The processor (330) controls the overall operations of the DU (210). The processor (380) may be referred to as a control unit. For example, the processor (330) transmits and receives signals through the transceiver (310) (or through the backhaul communication unit). In addition, the processor (330) records and reads data from the memory (320). In addition, the processor (330) may perform the functions of the protocol stack required by the communication standard. Although only the processor (330) is illustrated in FIG. 3A, the DU (210) may include two or more processors according to other implementation examples.

[0065] The configuration of DU (210) illustrated in FIG. 3A is merely an example, and examples of DUs performing embodiments of the present disclosure are not limited to the configuration illustrated in FIG. 3A. In some embodiments, some configurations may be added, deleted, or changed.

[0066] Fig. 3b illustrates the functional configuration of a radio unit (RU). The configuration illustrated in Fig. 3b can be understood as a configuration of the RU (220) of Fig. 2b or the O-RU (253-1) of Fig. 2b as part of a base station. Terms such as "...unit" and "...unit" used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0067] Referring to FIG. 3b, the RU (220) includes an RF transceiver (360), a fronthaul transceiver (365), a memory (370), and a processor (380).

[0068] The RF transceiver (360) performs functions for transmitting and receiving signals via a wireless channel. For example, the RF transceiver (360) upconverts a baseband signal into an RF band signal and transmits it via an antenna, and downconverts an RF band signal received via 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, and the like.

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

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

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

[0072] The fronthaul transceiver (365) can transmit and receive signals. According to one embodiment, the fronthaul transceiver (365) can transmit and receive signals on the fronthaul interface. For example, the fronthaul transceiver (365) can receive a management plane (M-plane) message. For example, the fronthaul transceiver (365) can receive a management plane (S-plane) message. For example, the fronthaul transceiver (365) can receive a control plane (C-plane) message. For example, the fronthaul transceiver (365) can transmit a user plane (U-plane) message. For example, the fronthaul transceiver (365) can receive a user plane message. Although only the fronthaul transceiver (365) is shown in FIG. 3b, according to other implementation examples, the RU (220) may include two or more fronthaul transceivers.

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

[0074] The memory (370) stores data such as basic programs, application programs, and setting information for the operation of the RU (220). The memory (370) may be referred to as a storage unit. The memory (370) may be configured as volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. In addition, the memory (370) provides the stored data according to a request from the processor (380). According to one embodiment, the memory (370) may include a memory for conditions, commands, or setting values ​​related to the SRS transmission method.

[0075] The processor (380) controls the overall operations of the RU (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 fronthaul transceiver (365). In addition, the processor (380) records and reads data in the memory (370). In addition, the processor (380) may perform functions of a protocol stack required by a communication standard. Although only the processor (380) is illustrated in FIG. 3B, the RU (220) may include two or more processors according to other implementation examples. The processor (380) may be a set of instructions or codes stored in the memory (370), or may be a storage space that stores instructions / codes or instructions / codes that are at least temporarily residing in the processor (380), or may be a part of the circuitry that constitutes the processor (380). Additionally, the processor (380) may include various modules for performing communication. The processor (380) may control the RU (220) to perform operations according to the embodiments described below.

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

[0077] Figure 4 illustrates an example of function split between DUs and RUs. As wireless communication technologies advance (e.g., the introduction of 5G (5th generation) communication systems (or NR (new radio) communication systems), the frequency bands used have increased further. As the cell radius of a base station has become significantly smaller, the number of RUs required for installation has also increased further. Furthermore, in 5G communication systems, the amount of data transmitted has increased by a factor of up to ten, significantly increasing the transmission capacity of the wired network transmitted to the fronthaul. Due to the factors described above, the installation cost of the wired network in the 5G communication system may increase significantly. Therefore, in order to lower the transmission capacity of the wired network and reduce the installation cost of the wired network, 'function split' can be utilized, which transfers some of the functions of the modem of the DU to the RU to lower the transmission capacity of the fronthaul.

[0078] To reduce the burden on the DU, the role of the RU, which is traditionally solely responsible for RF functions, can be expanded to include some physical layer functions. As the RU performs higher-layer functions, its throughput increases, which can increase transmission bandwidth in the fronthaul while reducing latency requirements due to response processing. However, as the RU performs higher-layer functions, virtualization gains decrease, and the RU's size, weight, and cost increase. Considering the trade-offs between the advantages and disadvantages described above, implementing an optimal functional separation is required.

[0079] Referring to Figure 4, the functional separation in the physical layer below the MAC layer is illustrated. For the downlink (DL) that transmits a signal to a terminal through a wireless network, the base station can sequentially perform channel encoding / scrambling, modulation, layer mapping, antenna mapping, RE mapping, digital beamforming (e.g., precoding), iFFT transform / CP insertion, and RF transform. For the uplink (UL) that receives a signal from a terminal through a wireless network, the base station can sequentially perform RF transform, FFT transform / CP removal, digital beamforming (pre-combining), RE demapping, channel estimation, layer demapping, demodulation, and decoding / descrambling. The separation of uplink and downlink functions can be defined in various types depending on the needs of vendors, discussions in standards, etc., according to the above-mentioned trade-offs.

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

[0081] In one embodiment, when a large amount of signal processing is expected, such as in the FR 1 MMU, functional separation at a relatively high layer (e.g., the fourth functional separation (420b)) may be required to reduce fronthaul capacity. In addition, functional separation at too high a layer (e.g., the sixth functional separation (430)) may complicate the control interface and cause a burden on the implementation of the RU due to the inclusion of a large number of PHY processing blocks within the RU. Therefore, appropriate functional separation may be required depending on the arrangement and implementation method of the DU and the RU.

[0082] In one embodiment, if the precoding of data received from the DU cannot be processed (i.e., if the precoding capability of the RU is limited), the third functional separation (420a) or a lower functional separation (e.g., the second functional separation (410)) may be applied. Conversely, if the DU has the capability to process the precoding of data received from the DU, the fourth functional separation (420b) or a higher functional separation (e.g., the sixth functional separation (430)) may be applied.

[0083] Hereinafter, embodiments in the present disclosure are described based on the third functional separation (420a) (which may be referred to as category A (CAT-A)) or the fourth functional separation (420b) (which may be referred to as category B (CAT-B)) for performing beamforming processing in an RU unless otherwise specified. The O-RAN standard distinguishes the types of O-RUs depending on whether the precoding function is located at the interface of the O-DU or the O-RU interface. An O-RU that does not perform precoding (i.e., has low complexity) may be referred to as a CAT-A O-RU. An O-RU that performs precoding may be referred to as a CAT-B O-RU.

[0084] Hereinafter, the term "upper-PHY" refers to physical layer processing handled in the DU of the fronthaul 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 handled in the RU of the fronthaul 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.

[0085] Embodiments of the present disclosure exemplarily describe the standards of eCPRI and O-RAN as fronthaul interfaces when transmitting messages between a DU (e.g., DU (210) of FIG. 2a) and an RU (e.g., RU (220) of FIG. 2a). 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 standard terms of eCPRI or O-RAN, but other expressions having equivalent meanings to each term may be used instead in various embodiments of the present disclosure. Hereinafter, various embodiments of the present disclosure are described using standard terms of eCPRI or O-RAN, but are not limited thereto. For example, in various embodiments of the present disclosure, the CPRI standard may be used as the fronthaul interface.

[0086] The fronthaul transport protocol can use Ethernet and eCPRI, which are easy to share with networks. The Ethernet payload can include an eCPRI header and an O-RAN header. The eCPRI header can be located at the beginning of the Ethernet payload. The contents of the eCPRI header are as follows.

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

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

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

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

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

[0092] 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.

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

[0094] 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'). The bit allocation of the eAxC ID can be distinguished as follows.

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

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

[0097] 3) CC_ID: CC_ID identifies the carrier component supported by the O-RU.

[0098] 4) RU_port ID: The RU_port ID specifies logical flows such as data layer or spatial streams, and signaling channels that require separate numerologies (e.g. PRACH) or special antenna allocation such as SRS.

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

[0100] The control plane may be configured to provide scheduling information and beamforming information via control messages. The control plane refers to real-time control between DUs and RUs. The user plane may include IQ sample data transmitted between DUs and RUs. The user plane may include user downlink data (IQ data or SSB / RS), uplink data (IQ data or SRS / RS), or PRACH data. A weight vector of the beamforming information described above may be multiplied by the user's data. The synchronization plane generally refers to traffic between DUs and RUs for a synchronization controller (e.g., IEEE grand master). The synchronization plane may be related to timing and synchronization. The management plane refers to non-real-time control between DUs and RUs. The management plane may be related to initial setup, non-realtime reset or reset, and non-realtime report.

[0101] Control plane messages, or C-plane messages, can be encapsulated based on a two-layer header approach. The first layer can consist of the eCPRI common header or the IEEE 1914.3 common header, which contains fields used to indicate the message type. The second layer is the application layer, which contains 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 following section types are supported within the C-plane:

[0102] Section Type can indicate the purpose of control messages transmitted on the control plane. For example, the purposes of each Section Type are as follows.

[0103] 1) sectionType=0: Used to indicate resource blocks or symbols not used in DL or UL.

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

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

[0106] 4) sectionType=3: PRACH and mixed-numerology channels. Channels that require a time or frequency offset or differ from the nominal SCS value(s).

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

[0108] 6) sectionType=5: UE scheduling information. Transmits UE scheduling information so that the RU can perform real-time BF weight calculations (O-RAN optional BF method).

[0109] 7) sectionType=6: Transmits UE-specific channel information. Periodically transmits UE channel information to enable the RU to perform real-time BF weight calculations (O-RAN optional BF method).

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

[0111] In the following specification, a NETCONF (network configuration protocol) client (or client server) (e.g., DU (210) of FIGS. 2A to 3B) can be configured to manage a NETCONF server. The NETCONF client and the NETCONF server can configure a session for performing supervision and a session for performing operations on a management plane (M-plane). The session for performing supervision and the session for performing operations on the management plane can be distinguished. In the following, technical features for configuring a session for performing supervision and a session for performing operations on the management plane will be described.

[0112] Figure 5 illustrates an example of an architecture for functional separation between DU and RU.

[0113] Referring to FIG. 5, the architecture (500) may correspond to the fronthaul interface illustrated in FIG. 2b. The architecture (500) may include a base station (110) and a management system (520). The DU (210) may correspond to the O-DU (251) of FIG. 2b. The RU (220) may correspond to the O-RU (253-1) of FIG. 2b.

[0114] For example, the LLS-M (lower-layer split M-plane) interface between the DU (210) and the RU (220) can provide a management plane (M-plane) through the LLS interface. The LLS-M can perform operations related to initialization, configuration, and management of the RU (220) to support the above-described functional division.

[0115] For example, the management plane (M-plane) can be configured based on the YANG (yet another next generation) model. Unlike the MIB (management information base) used in the existing SNMP (simple network management protocol), the YANG model used in NETCONF is in the form of a tree and can contain lists within lists. Therefore, the YANG model can express hierarchical relationships. The YANG model can change multiple list values ​​in a single command. When multiple lists are included in a single command, if an error occurs while changing the settings with multiple commands to change the service status, the problem of the service being affected due to the process being stopped in a state where the progress and restoration are impossible can be prevented.

[0116] For example, the management system (520) may be included in at least one of the DU (210), the service management and orchestration (SMO), and / or the network management system (NMS). The management system (520) may be configured to manage the operation of the RU (220).

[0117] For example, a management plane built on the NETCONF and YANG models can be used to support management features including "start-up" installation, software management, configuration management, performance management, fault management, and file management.

[0118] According to one embodiment, the management plane can support two architectural models. The two architectural models will be described below in FIGS. 6A and 6B.

[0119] Figure 6a illustrates an example of a management plane configured based on a hierarchical model.

[0120] Figure 6b illustrates an example of a management plane configured based on a hybrid model.

[0121] Referring to Fig. 6a, the management plane (M-plane) may be configured based on a hierarchical model. Within the management plane configured based on the hierarchical model, the RU (220) may be managed by one or more DUs using a NETCONF-based management plane interface. For example, an interface may be configured between the SMO (610) (or NMS) and the DU (210). However, the interface between the SMO (610) and the RU (220) may not be configured. The SMO (610) may not directly manage the RU (220). The SMO (610) may be an example of the management system (520) of Fig. 5.

[0122] Referring to FIG. 6b, the management plane (M-plane) may be configured based on a hybrid model. Within the management plane configured based on the hybrid model, in addition to the logical interface between the DU (210) and the RU (220), one or more direct logical interfaces may be configured between the SMO (610) and the RU (220). For example, an interface may be configured between the SMO (610) (or NMS) and the DU (210). In addition, an interface may also be configured between the SMO (610) and the RU (220). The SMO (610) may directly manage the RU (220).

[0123] According to an embodiment, the SMO (610) may have end-to-end IP (internet protocol) layer connectivity with the RU (220) within a management plane configured based on a hybrid model for the RU (220). From a physical network perspective, the connection between the SMO (610) and the RU (220) may be established through the DU (210). The DU (210) may act as an IP / Ethernet packet forwarder. The DU (210) may forward packets between the RU (220) and the SMO (610). Direct logical communication between the RU (220) and the SMO (610) can be enabled through the RU (220) being assigned routable IPs or local private IPs (IPs) resolved by a network address translation (NAT) function within the network (or implemented by the DU (210)).

[0124] Referring to Figures 6a and 6b, there may be no explicit signaling indicating that RU (220) operates based on a hierarchical model or a hybrid model. A NETCONF server may support multiple NETCONF sessions. All RUs may support hierarchical deployment and hybrid deployment.

[0125] For example, NETCONF can be used as a network element management protocol. YANG can be used as a data modeling language. By using a standardized framework and a common modeling language, integration between DU (210) and RU (220) as well as operator network integration can be simplified for elements that share a common set of capabilities. The framework can support integration of products with differing capabilities by the disclosed data model. NETCONF can support an architecture based on a hybrid model so that multiple clients can subscribe to and receive information generated by a NETCONF server.

[0126] According to one embodiment, various modes of network connectivity may be established between the DU (210), the RU (220), and the SMO (610) based on the transport topology. A basic requirement for the management plane may be to have an end-to-end IP connection between the RU (220) and the elements for managing the RU (220). The elements for managing the RU (220) may include the DU (210) or the SMO (610). The elements for managing the RU (220) may be referred to as RU controllers. The RU (220) may support IPv4 or IPv6, and optionally may support dual stack (IPv4 and IPv6).

[0127] Figure 7 illustrates examples of management plane interfaces.

[0128] Referring to FIG. 7, a management plane interface can be defined between the RU controller and the RU (220). A protocol stack (700) of the management plane interface can be illustrated in FIG. 7.

[0129] For example, according to the protocol stack (700), the first layer may be configured as a physical layer. The second layer may be configured as an Ethernet MAC layer. The third layer may be configured as an IP layer based on IPv4 or IPv6. The fourth layer may be configured as a TCP layer. The security layer may be configured as an SSH layer or a TLS layer.

[0130] For example, a transport network layer built on IP transport, SSH / TCP (secure shell / transmission control protocol), and TLS (transport layer security) can be used to transmit management plane messages between an RU controller (e.g., DU (210) or SMO (610)) and an RU (220). In some embodiments, the RU (220) can support a function to support asynchronous notifications transmitted using HTTPS (hypertext transfer protocol over secure socket layer). When the RU controller corresponds to an SMO (610) operating with a non-persistent NETCONF session to the RU (220), the function can enable system optimization.

[0131] According to one embodiment, the management plane may provide various functions to the RU (220). The functions provided by the management plane may be implemented using functions provided by NETCONF.

[0132] For example, the management plane may provide a "start up" installation function. During the "start up", the RU (220) may statically or dynamically obtain network layer parameters via DHCP (dynamic host configuration protocol) or DHCPv6 (DHCP version 6). During the "start up", the RU (220) may obtain the IP address of at least one RU controller (e.g., DU (210) or SMO (610)), and the RU (220) may establish a NETCONF connection using the "call home" function. When the RU (220) operates within an environment that includes the SMO (610), the RU (220) may obtain the IP address of the event controller, and the RU (220) may perform a "pnfRegistration" procedure that triggers the SMO (610) to establish a NETCONF connection using the information recovered in the "pnfRegistration" procedure.

[0133] For example, the management plane may provide software management functions upon request from an RU controller (e.g., DU (210) or SMO (610)). The management plane may be used to download, install, verify, and activate new software. Software downloads may be triggered by NETCONF remote procedure call (RPC) operations. The actual software download may be performed using sFTP (SSH file transfer protocol) over SSH (sFTP with SSH) or FTPES (file transfer protocol explicit-mode secure) over TLS (FTPES with TLS).

[0134] For example, the management plane may provide configuration management capabilities. Configuration management may include various scenarios such as retrieving resource states, modifying resource states, modifying parameters, and retrieving parameters. NETCONF "get-config" and "edit-config RPCs" may be used to retrieve and update configuration parameters in the RU (220).

[0135] For example, the management plane may perform performance management. Performance management may include measurements and counters used to collect data regarding the operations of the RU (220). Performance management may be performed to optimize the operation of the RU (220). Measurement results may be reported using two options. Measurement results may be reported via YANG notifications or file uploads. For example, for reporting via YANG notifications, statistical definitions of the YANG model per measurement group may be used. For example, measurement results may be reported based on a file upload procedure. Measurement results may be periodically stored in a data file.

[0136] For example, the management plane can perform fault management. Fault management can be used to send alarm notifications to NETCONF clients. Through fault management, alarm notifications (or alarm subscriptions) can be enabled or disabled.

[0137] For example, the management plane can perform file management. Through file management, an RU controller (e.g., DU (210) or SMO (610)) can trigger the RU (220) to upload files stored in the RU (220) to the RU controller. The RU (220) can provide various types of files, and the retrieved files can be used for various purposes. Simultaneous multiple file upload operations can be supported on the same SFTP or FTPES connection between the RU (220) and the DU (210) / SMO (610).

[0138] Figure 8 illustrates an example of the operation for a "start up" installation.

[0139] Referring to FIG. 8, the NETCONF server (811) and the NETCONF client (812) may perform operations related to a "start up" installation. Operations 801 to 806 may represent operations related to supervision of NETCONF connections among the operations related to the "start up" installation. The NETCONF server (811) may include an RU (220). The NETCONF client (812) may include a DU (210) and / or an SMO (610). The NETCONF server (811) may be referred to as an RU (220). The NETCONF client (812) may be referred to as a DU (210) and / or an SMO (610).

[0140] In operation 801, the NETCONF server (811) and the NETCONF client (812) may perform transport layer initialization. For example, the NETCONF server (811) may perform a management plane transport layer resolution (e.g., DHCP, MAC, VLAN, or IP) operation. The NETCONF server (811) may recover the IP address of the NETCONF client (812) and / or the pnfRegistration event collector.

[0141] In operation 802, the NETCONF server (811) may perform synchronization of the NETCONF server (811) to a primary reference clock. Depending on the embodiment, operation 802 may be performed concurrently with operation 801.

[0142] In operation 803, the NETCONF server (811) may perform a "NETCONF call home" to discover the NETCONF client (812). For example, the NETCONF server (811) may send a "NETCONF call home" to the NETCONF client (812).

[0143] At operation 804, the NETCONF client (812) may establish an SSH or TLS connection. For example, the NETCONF client (812) may establish an SSH session or TLS session connection with the NETCONF server (811).

[0144] At operation 805, the NETCONF server (811) and the NETCONF client (812) can perform NETCONF function discovery.

[0145] At operation 806, the NETCONF server (811) and the NETCONF client (812) can perform supervision of the NETCONF connection.

[0146] Figure 9 illustrates an example of an operation related to “call home.”

[0147] Referring to FIG. 9, at operation 901, the NETCONF server (811) (e.g., RU (220)) may start a call home timer.

[0148] At operation 902, the NETCONF server (811) may initiate a TCP connection to a NETCONF client (812). When the NETCONF server (811) performs a call home for NETCONF clients within the "client-info" container, the NETCONF server (811) may use a signaled port or a manually configured port. When the NETCONF server (811) performs a call home for NETCONF clients within the "configured-client-info" container, the NETCONF server (811) (e.g., RU (220)) may use a port configured by another NETCONF client. If the port is not signaled, is not manually configured within the "client-info" container, or is not configured within the "configured-client-info" container, the NETCONF server (811) may use the port configured in "call-home-ssh-port" to indicate that the NETCONF server (811) secures the NETCONF connection using SSHv2. The NETCONF server (811) may use the port configured in "call-home-tls-port" to indicate that the NETCONF server (811) secures the NETCONF connection using TLS.

[0149] For example, if "call-home-ssh-port" does not exist, the NETCONF server (811) can use port 4334 to indicate that the NETCONF server (811) secures the NETCONF connection using SSHv2. If "call-home-tls-port" does not exist, the NETCONF server (811) can use port 4334 to indicate that the NETCONF server (811) secures the NETCONF connection using TLS.

[0150] At operation 903, if the NETCONF client (812) accepts a TCP connection on the assigned port, the NETCONF client (812) may initiate an SSH session and / or a TLS connection.

[0151] In steps 904 and 905, the NETCONF client (812) may initiate a NETCONF session connection using an SSH session and / or a TLS connection. For example, the NETCONF client (812) may send a hello message to the NETCONF server (811) that includes information about the capabilities of the NETCONF client (812). The NETCONF server (811) may send a hello message to the NETCONF client (812) that includes information about the capabilities of the NETCONF server (811).

[0152] At action 906, the NETCONF server (811) may terminate the call home timer.

[0153] Based on operations 901 to 906, operations related to call home can be performed. The NETCONF server (811) and the NETCONF client (812) can establish a NETCONF session connection based on the operations related to call home.

[0154] Figure 10 illustrates an example of an operation for monitoring a NETCONF connection.

[0155] Referring to FIG. 10, when a NETCONF server (811) (e.g., RU (220)) has a session with a NETCONF client (812) (e.g., DU (210) or SMO (610)) that has subscribed to receive "supervision-notification", the NETCONF server (811) may operate watchdog timers (e.g., supervision timer and notification timer) to ensure that the session for the NETCONF client (812) continues. The NETCONF server (811) may provide a NETCONF notification to notify a remote system that the management system is operating.

[0156] For a NETCONF server (811) that supports the "SUPERVISION-WITH-SESSION-ID" feature, the "supervision-notification" message may indicate the NETCONF session ID associated with the subscription to event notifications. When a NETCONF client (812) subscribes to receive supervision notifications, the NETCONF server (811) may use its session ID in the subscription filter criteria to indicate which "supervision-notification" events the NETCONF server (811) should forward to the NETCONF client (812). The session ID may be provided to the NETCONF client (812) by the NETCONF server (811) in the initial Hello message exchange.

[0157] A NETCONF client (812) (e.g. RU controller, DU (210) or SMO (610)) that has subscribed to "supervision-notification" <supervision-watchdog-reset>A NETCONF client (812) can use RPC to notify the NETCONF server (811) that it is running.

[0158] The NETCONF server (811) can support the operation of individual supervision watchdog timers for each NETCONF client that has subscribed to "supervision-notification".

[0159] An authorized NETCONF client (812) can activate watchdog timers by creating a "supervision-notification" subscription. Once the watchdog timers are activated, the timers can be considered running.

[0160] The NETCONF server (811) (e.g., RU (220)) can support bidirectional monitoring of NETCONF connections using two timers referred to as watchdog timers. For example, the two timers can include a notification timer and a supervision timer.

[0161] The value of the notification timer can be set to a value corresponding to "supervision-notification-interval". The default value of the notification timer can be set to 60 seconds. The NETCONF server (811) can send a "supervision-notification" to a NETCONF client (812) that has subscribed to receive the "supervision-notification". The NETCONF server (811) can send the "supervision-notification" based on the expiration of the notification timer. The NETCONF client (812) (or RU controller, DU (210), or SMO (610)) can determine whether the NETCONF connection to the NETCONF server (811) is working based on the received "supervision-notification".

[0162] The value of the supervision timer can be set to the sum of the value corresponding to the "supervision-notification-interval" and the "guard-timer-overhead". The default value of the "supervision-notification-interval" can be set to 60 seconds. The default value of the "guard-timer-overhead" can be set to 10 seconds. The NETCONF server (811) can identify a supervision failure operation based on the expiration of the supervision timer. To prevent the expiration of the supervision timer, the NETCONF client (812) subscribed to receive the "supervision-notification" can repeatedly reset the supervision timer. The reset of the supervision timer can be regarded as confirmation by the NETCONF server (811) that the NETCONF connection with the NETCONF client (812) is operating.

[0163] In operation 1001, the NETCONF client (812) can subscribe to receive "supervision-notification". The NETCONF client (812) can send a message to the NETCONF server (811) to create a subscription.

[0164] At action 1002, the NETCONF server (811) may start a notification timer set to a default value.

[0165] In action 1003, you can start the supervisor timer set to default.

[0166] At operation 1004, the NETCONF server (811) may send a message to the NETCONF client (812) for subscription confirmation.

[0167] Actions 1005, 1006 and 1008 may relate to actions for supervision.

[0168] Operation 1005 may relate to an operation for changing the default value of a timer. The NETCONF client (812) may transmit a message to the NETCONF server (811) for resetting watchdog timers. The message may include information for setting a "supervision-notification-interval" and information for setting a "guard-timer-overhead." The NETCONF server (811) may reset the notification timer and the supervision timer for the NETCONF session. The NETCONF server (811) may reset the notification timer and the supervision timer based on the information for setting the "supervision-notification-interval" and the information for setting the "guard-timer-overhead." The NETCONF server (811) may transmit a message indicating that the notification timer and the supervision timer have been reset to the NETCONF client (812). The NETCONF server (811) may use the watchdog timers set to the changed values.

[0169] Action 1006 may relate to an action for transmitting a supervision message. For example, the NETCONF server (811) may identify that a notification timer has expired. The NETCONF server (811) may transmit a "supervision-notification" to the NETCONF client (812). The "supervision-notification" may be transmitted to indicate that the NETCONF server (811) is operating without problems.

[0170] The NETCONF client (812) can identify (or confirm) that the management system of the NETCONF server (811) is operating. The NETCONF client (812) can identify (or confirm) that the NETCONF server (811) is operating without a problem. The NETCONF client (812) can send a message to the NETCONF server (811) for resetting watchdog timers. The NETCONF server (811) can reset watchdog timers for the NETCONF session. The NETCONF server (811) can send a message to the NETCONF client (812) indicating that the notification timer and the supervision timer have been reset. The NETCONF server (811) can identify (or confirm) that the peer management system is operating. According to an embodiment, when the supervision timer expires, operation 1007 can be performed. The NETCONF server (811) may not receive a message for resetting the watchdog timers sent by the NETCONF client (812), and the supervision timer may expire. The NETCONF server (811) may handle the supervision failure.

[0171] Action 1008 may relate to an action for terminating a supervision procedure by the NETCONF client (812).

[0172] When closing a NETCONF session, operation 1009 may be performed. In operation 1009, the NETCONF client (812) may send a message to the NETCONF server (811) to close the NETCONF session.

[0173] When killing a NETCONF session, operation 1010 may be performed. In operation 1010, the NETCONF client (812) may send a message to the NETCONF server (811) to kill the NETCONF session.

[0174] When the subscription stop time has been reached, action 1011 may be performed. In action 1011, the NETCONF server (811) may identify that the subscription stop time has been reached.

[0175] After one of actions 1009 to 1011 is performed, the NETCONF server (811) can process supervision termination.

[0176] When supervision for a NETCONF session is executed, the NETCONF server (811) can monitor the NETCONF session through the above-described operations 1001 to 1011.

[0177] In the following specification, the operation of the NETCONF server (811) and the NETCONF client (812) for supervision of NETCONF sessions will be described.

[0178] Figure 11a illustrates an example of a session for operations on the supervisory and management planes.

[0179] Figure 11b illustrates an example of operations performed on the supervisory and management planes in one session.

[0180] Referring to FIG. 11A, a NETCONF server (811) and a NETCONF client (812) can configure a single NETCONF session. For example, the NETCONF server (811) can configure (or establish) a single connected NETCONF session based on a NETCONF call home. For example, operations related to the supervision and management plane can be performed based on a single session.

[0181] Referring to Figure 11b, NETCONF <rpc>The response procedure for a request follows the NETCONF standard (i.e., RFC (request for comments) 6241). NETCONF <rpc>The procedure for responding to a request follows the rules shown in the table below.

[0182] NETCONF <rpc>requests MUST be processed serially by the managed device. Additional <rpc>requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.

[0183] According to Table 1, the NETCONF server (811) (e.g., RU (220)) receives the NETCONF message sent by the NETCONF client (812). <rpc>Responses to requests must be sent sequentially to the NETCONF client (812).

[0184] Therefore, when a NETCONF server (811) and a NETCONF client (812) perform operations on a management plane distinct from supervision using a single NETCONF session, the NETCONF received by the NETCONF server (811) <rpc>In order of <rpc-reply>must be sent to the NETCONF client (812).

[0185] In operation 1101, the NETCONF server (811) may send a first message with a "message-id" of "AAA" to the NETCONF client (812). The NETCONF server (811) may perform an action regarding the first message. The time of performing the action regarding the first message may be referred to as a time interval (1110).

[0186] At operation 1102, while the operation regarding the first message is being performed, the NETCONF server (811) <supervision-notification>can be transmitted to the NETCONF client (812). For example, the NETCONF server (811) may identify that the notification timer has expired, <supervision-notification>can be transmitted to the NETCONF client (812). For example, the NETCONF server (811) may transmit the data based on a specified time interval (e.g., 60 seconds). <supervision-notification>can be transmitted to the NETCONF client (812). The specified time interval can be changed to a value requested by the NETCONF client (812).

[0187] At operation 1103, the NETCONF client (812) may send a second message with "message-id" of "BBB". The second message is <supervision-notification>It may be a response message to. For example, the NETCONF client (812) may identify (or confirm) that the management system of the NETCONF server (811) is operating. The NETCONF client (812) may send a second message to the NETCONF server (811) for resetting the watchdog timers.

[0188] In operation 1104, the NETCONF server (811) may transmit a third message, which is a response message to the first message, to the NETCONF client (812) after a time interval (1110), which is the execution time of the operation regarding the first message, has elapsed. The NETCONF server (811) may transmit the third message, which is a response message to the first message received first, to the NETCONF client (812) according to Table 1.

[0189] In operation 1105, the NETCONF server (811) may transmit a third message, which is a response message to the first message, and then transmit a fourth message, which is a response message to the second message, to the NETCONF client (812). For example, the NETCONF server (811) may transmit the fourth message, which indicates that the notification timer and the supervision timer have been reset, to the NETCONF client (812). Operations 1102, 1103, and 1105 may correspond to at least a portion of operation 1006 of FIG. 10. The time interval (1120) may be a time interval between the time at which the second message is received and the time at which the fourth message is transmitted.

[0190] According to one embodiment, when the time interval (1110) increases according to the action for the first message, the time interval (1120) may also increase. As the time interval (1120) increases, the NETCONF client (812) may receive the fourth message, which is a response message to the second message, late. If the time interval (1120) becomes greater than a timeout value managed by the NETCONF server (811) and / or the NETCONF client (812), the NETCONF session may be determined to be abnormal. For example, if the supervision timer expires before transmitting the fourth message, the NETCONF server (811) may identify a supervision failure. If the supervision timer expires before transmitting the fourth message, the NETCONF server (811) may perform an action according to the supervision failure. If the NETCONF server (811) identifies a supervision failure, the NETCONF session may be closed. As in the example described above, even if the NETCONF session between the actual NETCONF server (811) and the NETCONF client (812) is normal, an abnormal situation may occur in which the NETCONF session is determined to be abnormal. In FIG. 11b, the first to fourth messages are illustrated as examples, but the present invention is not limited thereto. Depending on various messages (or NETCONF rpc), the time interval (1120) may increase, and the NETCONF session may be determined to be abnormal in the NETCONF server (811) and / or the NETCONF client (812).

[0191] According to one embodiment, if a NETCONF session for supervision and a NETCONF session for operations on the management plane are distinguished, an abnormal situation in which a NETCONF session is judged to be abnormal even when the NETCONF session is normal can be prevented. Therefore, in the following specification, technical features of distinguishing a NETCONF session for supervision and a NETCONF session for operations on the management plane will be described.

[0192] Figure 12a illustrates an example of the operation of a NETCONF server and a NETCONF client establishing two NETCONF sessions.

[0193] Figure 12b illustrates an example of the operation of a NETCONF server and a NETCONF client establishing two NETCONF sessions.

[0194] Referring to FIGS. 12A and 12B , two sessions can be established to configure a NETCONF session for supervision and a NETCONF session for operations on the management plane. In one embodiment, a NETCONF server (811) (e.g., RU (220)) and a NETCONF client (812) (e.g., RU controller, DU (210) or SMO (610)) can establish two sessions based on operations 1211 to 1214 illustrated in FIG. 12A . In one embodiment, a NETCONF server (811) and a NETCONF client (812) can establish two sessions based on operations 1221 to 1224 illustrated in FIG. 12B .

[0195] Referring to FIG. 12A, in operation 1211, the NETCONF server (811) may perform a call home procedure for the NETCONF client (812) using a first port (e.g., port 4334). For example, the NETCONF server (811) may transmit a call home to the NETCONF client (812).

[0196] At operation 1212, the NETCONF server (811) and the NETCONF client (812) may establish a first NETCONF session based on the call home procedure according to operation 1211.

[0197] In operation 1213, after the first NETCONF session is established, the NETCONF client (812) can perform a call home procedure to the NETCONF server (811) using a second port (e.g., port 830). For example, the NETCONF client (812) can send a call home to the NETCONF server (811). In operation 1211, the NETCONF server (811) performed the call home procedure to the NETCONF client (812), but in operation 1213, the NETCONF client (812) can perform the call home procedure to the NETCONF server (811).

[0198] In operation 1214, the NETCONF server (811) and the NETCONF client (812) can establish a second NETCONF session based on the call home procedure according to operation 1213. The NETCONF client (812) can establish the second NETCONF session based on the IP connected to the NETCONF server (811).

[0199] Referring to FIG. 12b, in operation 1221, the NETCONF server (811) may perform a call home procedure for the NETCONF client (812) using a first port (e.g., port 4334). For example, the NETCONF server (811) may transmit a call home to the NETCONF client (812).

[0200] At operation 1222, the NETCONF server (811) and the NETCONF client (812) may establish a first NETCONF session based on the call home procedure according to operation 1221.

[0201] In operation 1223, after the first NETCONF session is established, the NETCONF server (811) may perform a call home procedure for the NETCONF client (812) using the first port (e.g., port 4334). For example, the NETCONF server (811) may send a call home to the NETCONF client (812).

[0202] At operation 1224, the NETCONF server (811) and the NETCONF client (812) may establish a second NETCONF session based on the call home procedure according to operation 1223. The NETCONF server (811) may establish a second NETCONF session distinct from the first NETCONF session based on transmitting a new call home to the NETCONF client (812). The first NETCONF session and the second NETCONF session may be established through the same port (e.g., the first port).

[0203] Although FIGS. 12A and 12B illustrate examples in which two sessions are configured, the present invention is not limited thereto. Multiple sessions may be configured between the NETCONF server (811) and the NETCONF client (812).

[0204] Figure 13a illustrates an example of a session for supervision and a session for operation on the management plane.

[0205] Figure 13b illustrates an example of operations performed on the supervisory and management planes in two sessions.

[0206] Referring to FIG. 13A, a NETCONF server (811) and a NETCONF client (812) can configure two NETCONF sessions. For example, the NETCONF server (811) can configure (or establish) two NETCONF sessions by performing one of the operations of FIG. 12A and FIG. 12B. The two sessions can include a first NETCONF session (1311) and a second NETCONF session (1312).

[0207] For example, both the first NETCONF session (1311) and the second NETCONF session (1312) may be established (or configured) based on SSH. For example, the first NETCONF session (1311) may be established (or configured) based on SSH, and the second NETCONF session (1312) may be established (or configured) based on TLS. For example, the first NETCONF session (1311) may be established (or configured) based on TLS, and the second NETCONF session (1312) may be established (or configured) based on SSH. For example, both the first NETCONF session (1311) and the second NETCONF session (1312) may be established (or configured) based on TLS.

[0208] Referring to FIG. 13b, one of the first NETCONF session (1311) and the second NETCONF session (1312) may be set as a NETCONF session for supervision. The other of the first NETCONF session (1311) and the second NETCONF session (1312) may be set as a NETCONF session for operation of the management plane.

[0209] The NETCONF server (811) and the NETCONF client (812) can perform one of operations 1320 and 1330.

[0210] Action 1320 may include actions 1321 and 1322.

[0211] At operation 1321, the NETCONF client (812) initiates a first NETCONF session (1311) for supervision notification. <create-subscription>(or <create-subscription>RPC) can be transmitted to the NETCONF server (811). The NETCONF server (811) can receive the data from the NETCONF client (812). <create-subscription>Based on receiving the NETCONF server (811), watchdog timers (e.g., supervisory timer and notification timer) can be activated. <create-subscription>Based on receiving the notification timer, the NETCONF server (811) can activate a notification timer. After the notification timer expires, the NETCONF server (811) can send a supervision notification to the NETCONF client (812). According to operation 1321, the NETCONF client (812) can send a supervision notification only for the "supervision-notification" in the first NETCONF session (1311). <create-subscription>can be performed.

[0212] At operation 1322, the NETCONF client (812) initiates a second NETCONF session (1312) for all notifications regarding operations on the management plane. <create-subscription>(or <create-subscription>RPC) to the NETCONF server (811). According to operation 1321, the NETCONF client (812) sends, in the second NETCONF session (1312), all notifications regarding operations on the management plane. <create-subscription>can perform. The NETCONF client (812) performs "supervision-notification" in the second NETCONF session (1312). <create-subscription>may not be performed.

[0213] Action 1330 may include actions 1331 and 1332.

[0214] At operation 1331, the NETCONF client (812) initiates a first NETCONF session (1311) for an operation on the management plane (e.g., all notifications). <create-subscription>(or <create-subscription>RPC) to the NETCONF server (811). According to operation 1331, the NETCONF client (812) may, in the first NETCONF session (1311), send all notifications regarding operations on the management plane. <create-subscription>can be performed. The NETCONF client (812) performs "supervision-notification" in the first NETCONF session (1311). <create-subscription>may not be performed.

[0215] At action 1332, the NETCONF client (812) initiates a second NETCONF session (1312) for supervision notification. <create-subscription>(or <create-subscription>RPC) can be transmitted to the NETCONF server (811). The NETCONF server (811) can receive the data from the NETCONF client (812). <create-subscription>Based on receiving the NETCONF server (811), watchdog timers (e.g., supervisory timer and notification timer) can be activated. <create-subscription>Based on receiving the notification timer, the NETCONF server (811) can activate a notification timer. After the notification timer expires, the NETCONF server (811) can send a supervision notification to the NETCONF client (812). According to operation 1331, the NETCONF client (812) can send a supervision notification only for the "supervision-notification" in the second NETCONF session (1312). <create-subscription>can be performed.

[0216] As described above, in one of the first NETCONF session (1311) and the second NETCONF session (1312), only operations related to "supervision-notification" can be performed. In the other of the first NETCONF session (1311) and the second NETCONF session (1312), operations related to the management plane other than "supervision-notification" can be performed.

[0217] Although FIGS. 13A and 13B illustrate examples of two sessions being configured, the present invention is not limited thereto. Multiple sessions may also be configured between the NETCONF server (811) and the NETCONF client (812). One of the multiple sessions may be used to perform operations (or notifications) related to supervision. Another of the multiple sessions may be used to perform operations (or notifications) related to the management plane.

[0218] Figure 14 illustrates a flowchart of the RU's operations. In the following embodiments, the operations may be performed sequentially, but are not necessarily sequential. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0219] Referring to FIG. 14, the RU (220) described below may be an example of the NETCONF server (811) described above.

[0220] In operation 1410, the RU (220) (or the processor (380) of the RU (220), the electronic device executed by the RU (220)) may establish a first session and a second session with the client server. For example, the second session may be distinguished from the first session. For example, an example of the client server may be the NETCONF client (812). The client server may include at least one of the DU (210) or the SMO (610).

[0221] According to one embodiment, the RU (220) may transmit a message to the client server for performing a call home for the client server using a first port (e.g., port 4334). The RU (220) may establish a first session based on transmitting the message to the client server for performing a call home for the client server. The RU (220) may transmit another message to the client server for performing a call home for the client server using the first port. The RU (220) may establish a second session based on transmitting another message to the client server for performing a call home for the client server. For example, the RU (220) may establish a first session based on transmitting a message to the client server for performing a call home using the first port, and may establish a second session based on transmitting another message to the client server for performing a call home using the same first port. For example, the operation of establishing a first session may correspond to operations 1221 and 1222 of FIG. 12B. For example, the operation of establishing a second session may correspond to operations 1223 and 1224 of FIG. 12B.

[0222] According to one embodiment, the RU (220) can transmit a message to the client server for performing a call home for the client server using a first port (e.g., port 4334). The RU (220) can establish a first session based on transmitting the message to the client server for performing a call home for the client server. The RU (220) can receive another message from the client server for performing a call home for the RU (220) using a second port (e.g., port 830) distinct from the first port. The RU (220) can establish a second session based on receiving another message from the client server for performing a call home for the RU (220). For example, RU (220) can establish a first session based on transmitting a message for performing a call home to the client server using a first port, and can establish a second session based on receiving another message for performing a call home from the client server using a second port that is distinct from the first port. For example, the operation for establishing the first session may correspond to operations 1211 and 1212 of FIG. 12A. For example, the operation for establishing the second session may correspond to operations 1213 and 1214 of FIG. 12A.

[0223] For example, each of the first and second sessions may be established based on either SSH or TLS. The first session may be established based on either SSH or TLS. The second session may be established based on either SSH or TLS.

[0224] In operation 1420, the RU (220) may transmit to or receive from the client server at least one first message for an operation for supervision through the first session.

[0225] For example, at least one first message may include a third message for requesting supervision notification and a fourth message for supervision notification. The third message may include: <create-subscription>may include. The fourth message is <supervision-notification>may include.

[0226] RU (220) may receive a third message from the client server. Based on the third message, RU (220) may transmit a fourth message to the client server indicating that management by the client server is being performed. Based on the third message, RU (220) may activate a first timer and a second timer. The first timer may include a notification timer. The second timer may include a supervision timer.

[0227] Based on the expiration of the first timer, the RU (220) can transmit a fourth message to the client server. The default value of the first timer can be set to 60 seconds. The value of the first timer can be changed by the client server. Based on transmitting the fourth message, the RU (220) can receive a fifth message from the client server to reset the first timer and the second timer before the second timer expires. Based on the fifth message, the RU (220) can reset the first timer and the second timer.

[0228] In an embodiment, the RU (220) may identify that a fifth message for resetting the first and second timers is not received until the second timer expires based on transmitting the fourth message. The RU (220) may not receive the fifth message from the client server until the second timer expires. The RU (220) may identify a failure of the supervision operation based on identifying that the fifth message is not received until the second timer expires. For example, the default value of the second timer may be set to 70 seconds. The value of the second timer may be changed by the client server.

[0229] At operation 1430, the RU (220) may transmit or receive, to the client server, at least one second message for operation on the management plane, via the second session. For example, the RU (220) may transmit or receive, to the client server, at least one second message for operation on the management plane between the DU (210) and the RU (220), via the second session, while the at least one first message is transmitted or received via the first session.

[0230] The RU (220) can exchange at least one first message for supervision with the client server through a first session. The RU (220) can exchange at least one second message for operations on the management plane with the client server through a second session.

[0231] Figure 15 illustrates a flowchart of the client-server operation. In the following embodiments, the operations may be performed sequentially, but are not necessarily sequential. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0232] Referring to FIG. 15, the RU (220) described below may be an example of the NETCONF server (811) described above.

[0233] In operation 1510, the client server (or the processor of the client server, or an electronic device executed by the client server) may establish a first session and a second session with the RU (220). For example, the second session may be distinguished from the first session. For example, an example of the client server may be a NETCONF client (812). The client server may include at least one of the DU (210) or the SMO (610).

[0234] In one embodiment, the client server may receive a message from the RU (220) for performing a call home for the client server using a first port (e.g., port 4334). The client server may establish a first session based on receiving the message from the RU (220) for performing a call home for the client server. The client server may receive another message from the RU (220) for performing a call home for the client server using the first port. The client server may establish a second session based on receiving the other message from the RU (220) for performing a call home for the client server. For example, the client server may establish a first session based on receiving a message from the RU (220) for performing a call home using the first port, and may establish a second session based on receiving another message from the RU (220) for performing a call home using the same first port. For example, the operation of establishing a first session may correspond to operations 1221 and 1222 of FIG. 12B. For example, the operation of establishing a second session may correspond to operations 1223 and 1224 of FIG. 12B.

[0235] In one embodiment, the client server may receive a message from the RU (220) for performing a call home for the client server using a first port (e.g., port 4334). The client server may establish a first session based on receiving the message from the RU (220) for performing a call home for the client server. The client server may transmit another message to the RU (220) for performing a call home for the RU (220) using a second port (e.g., port 830) distinct from the first port. The client server may establish a second session based on transmitting the other message to the RU (220) for performing a call home for the RU (220). For example, the client server may establish a first session based on receiving a message for performing a call home from the RU (220) using a first port, and may establish a second session based on transmitting another message for performing a call home to the RU (220) using a second port that is distinct from the first port. For example, the operation for establishing the first session may correspond to operations 1211 and 1212 of FIG. 12A. For example, the operation for establishing the second session may correspond to operations 1213 and 1214 of FIG. 12A.

[0236] For example, each of the first and second sessions may be established based on either SSH or TLS. The first session may be established based on either SSH or TLS. The second session may be established based on either SSH or TLS.

[0237] At operation 1520, the client server may transmit to or receive from the RU (220) at least one first message for an operation for supervision through the first session.

[0238] For example, at least one first message may include a third message for requesting supervision notification and a fourth message for supervision notification. The third message may include: <create-subscription>may include. The fourth message is <supervision-notification>may include.

[0239] The client server may transmit a third message to the RU (220). Based on the third message, the client server may receive a fourth message from the RU (220) indicating that management by the client server is being performed. Based on the third message, the client server may activate the first timer and the second timer of the RU (220). The first timer may include a notification timer. The second timer may include a supervision timer.

[0240] The client server may receive a fourth message from the RU (220) based on the expiration of the first timer. The default value of the first timer may be set to 60 seconds. The value of the first timer may be changed by the client server. Based on receiving the fourth message, the client server may transmit a fifth message to the RU (220) to reset the first timer and the second timer before the second timer expires. The RU (220) may reset the first timer and the second timer based on the fifth message.

[0241] In some embodiments, the client server may not transmit the fifth message to reset the first and second timers until the second timer expires. The RU (220) may not receive the fifth message from the client server until the second timer expires. The RU (220) may identify a failure in the supervision operation based on the identification that the fifth message is not received until the second timer expires. For example, the default value of the second timer may be set to 70 seconds. The value of the second timer may be changed by the client server.

[0242] At operation 1530, the client server may transmit or receive, to or from the RU (220), at least one second message for operation on the management plane, via the second session. For example, the client server may transmit or receive, to or from the RU (220), at least one second message for operation on the management plane between the DU (210) and the RU (220), via the second session, while at least one first message is transmitted or received via the first session.

[0243] The client server can exchange at least one first message for supervision with the RU (220) through a first session. The client server can exchange at least one second message for operations on the management plane with the RU (220) through a second session.

[0244] According to one embodiment, a radio unit (RU) (e.g., RU (220)) may include a transceiver, a memory storing instructions and including one or more storage media, and at least one processor including a processing circuit. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to establish a first session and a second session distinct from the first session with a client server including at least one of a distributed unit (DU) or a service management and orchestration (SMO). The instructions, when individually or collectively executed by the at least one processor, may cause the RU to transmit to or receive from the client server at least one first message for an action for supervision over the first session. The instructions, when executed individually or collectively by the at least one processor, may cause the RU to transmit to or receive from the client server, via the second session, at least one second message for operation on a management plane (M-plane) between the DU and the RU while the at least one first message is transmitted or received via the first session.

[0245] According to one embodiment, each of the first session and the second session may be established based on one of SSH (secure shell / transmission control protocol) and TLS (transport layer security).

[0246] In one embodiment, the at least one first message may include a third message for requesting a supervision notification and a fourth message for the supervision notification. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to receive the third message from the client server. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to transmit the fourth message to the client server, based on the third message, indicating that the RU is operating normally.

[0247] According to one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to activate a first timer and a second timer based on the third message.

[0248] According to one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to transmit the fourth message to the client server based on expiration of the first timer.

[0249] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to receive a fifth message for resetting the first timer and the second timer before the second timer expires based on transmitting the fourth message. The instructions, when executed individually or collectively by the at least one processor, may cause the RU to reset the first timer and the second timer based on the fifth message.

[0250] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to identify that a fifth message for resetting the first timer and the second timer is not received until the second timer expires based on transmitting the fourth message. The instructions, when executed individually or collectively by the at least one processor, may cause the RU to identify a failure of an operation for the supervision based on identifying that the fifth message is not received until the second timer expires.

[0251] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to establish the first session based on transmitting a message to the client server using the first port for performing a call home to the client server. The instructions, when executed individually or collectively by the at least one processor, may cause the RU to establish the second session based on transmitting another message to the client server using the first port for performing a call home to the client server.

[0252] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the RU to establish the first session based on transmitting a message to the client server, using a first port, for performing a call home for the client server. The instructions, when executed individually or collectively by the at least one processor, may cause the RU to establish the second session based on receiving another message from the client server, using a second port distinct from the first port, for performing a call home for the RU.

[0253] According to one embodiment, a method performed in a radio unit (RU) (e.g., RU (220)) may include establishing a first session and a second session distinct from the first session with a client server including at least one of a distributed unit (DU) or a service management and orchestration (SMO). The method may include transmitting to or receiving from the client server, through the first session, at least one first message for an operation for supervision. The method may include transmitting to or receiving from the client server, through the second session, at least one second message for an operation for a management plane (M-plane) between the DU and the RU, while the at least one first message is transmitted or received through the first session.

[0254] According to one embodiment, a client server (e.g., DU (210) or SMO (610)) may include at least one processor comprising a memory storing instructions and one or more storage media, and a processing circuit. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to establish a first session with a radio unit (RU) and a second session distinct from the first session. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to transmit to or receive from the RU at least one first message for an action for supervision over the first session. The instructions, when executed individually or collectively by the at least one processor, may cause the client server to transmit to or receive from the RU, via the second session, at least one second message for operation on a management plane (M-plane) between a distributed unit (DU) and the RU, while the at least one first message is transmitted or received via the first session.

[0255] According to one embodiment, each of the first session and the second session may be established based on one of SSH (secure shell / transmission control protocol) and TLS (transport layer security).

[0256] According to one embodiment, the at least one first message may include a third message for requesting a supervision notification and a fourth message for the supervision notification. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to transmit the third message to the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to receive, based on the third message, the fourth message from the RU, indicating that the RU is operating normally.

[0257] According to one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the client server to activate a first timer and a second timer for the RU based on transmitting the third message.

[0258] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the client server to receive the fourth message from the RU based on expiration of the first timer.

[0259] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the client server to transmit a fifth message to reset the first timer and the second timer before the second timer expires, based on receiving the fourth message.

[0260] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the client server to establish the first session based on receiving, from the RU, a message for performing a call home to the client server using the first port. The instructions, when executed individually or collectively by the at least one processor, may cause the client server to establish the second session based on receiving, from the RU, another message for performing a call home to the client server using the first port.

[0261] In one embodiment, the instructions, when executed individually or collectively by the at least one processor, may cause the client server to establish the first session based on receiving a message from the RU, using a first port, for performing a call home to the client server. The instructions, when executed individually or collectively by the at least one processor, may cause the client server to establish the second session based on transmitting another message to the RU, using a second port distinct from the first port, for performing a call home to the RU.

[0262] According to one embodiment, the client server may include at least one of a distributed unit (DU) or a service management and orchestration (SMO).

[0263] According to one embodiment, a method performed in a client server (e.g., DU (210) or SMO (610)) may include establishing a first session with a radio unit (RU) and a second session distinct from the first session. The method may include transmitting to or receiving from the RU, through the first session, at least one first message for an operation for supervision. The method may include transmitting to or receiving from the RU, through the second session, at least one second message for an operation for a management plane (M-plane) between the distributed unit (DU) and the RU, while the at least one first message is transmitted or received through the first session.

[0264] In one embodiment, multiple sessions may be established between an RU (e.g., RU (220)) and a client server (e.g., DU (210)). One of the multiple sessions may be used to perform a supervisory operation. Another of the multiple sessions may be used to perform operations related to the management plane other than the supervisory operation. For example, supervisory operations of the management plane and other operations distinct from the supervisory operation may be managed as separate sessions. Accordingly, supervisory operations can be performed without violating the rules according to the RFC 6241 standard (or the rules in Table 1). Accordingly, the problem of a normally operating session being judged as abnormal can be solved.

[0265] The 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.

[0266] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured to be executed by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present 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 commodity. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0267] These 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, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

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

[0269] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0270] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the 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.

[0271] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure. < / rpc> < / rpc> < / rpc> < / rpc> < / rpc> < / rpc>

Claims

1. In the RU (radio unit), Transmitter and receiver; A memory storing instructions and including one or more storage media; and comprising at least one processor including a processing circuit; The above instructions, when individually or collectively executed by the at least one processor, cause the RU to: Establishing a first session and a second session distinct from the first session, with a client server including at least one of a DU (distributed unit) or an SMO (service management and orchestration), Through said first session, at least one first message for operation for supervision is transmitted to or received from said client server, While the at least one first message is transmitted or received through the first session, causing the client server to transmit or receive from the client server at least one second message for operation on a management plane (M-plane) between the DU and the RU through the second session. RU.

2. In the first paragraph, each of the first session and the second session, Established based on either SSH (secure shell / transmission control protocol) or TLS (transport layer security), RU.

3. In the first paragraph, at least one first message, Contains a third message for requesting supervision notification and a fourth message for supervision notification; The above instructions, when individually or collectively executed by the at least one processor, cause the RU to: Receiving the above third message from the client server, Based on the third message, further causing the client server to transmit the fourth message indicating that the RU is operating normally. RU.

4. In the third paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: Based on the third message above, further causing the first timer and the second timer to be activated, RU.

5. In the fourth paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: further causing the client server to transmit the fourth message based on the expiration of the first timer; RU.

6. In the fifth paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: Based on transmitting the fourth message, before the second timer expires, a fifth message is received for resetting the first timer and the second timer, Based on the fifth message, further causing the first timer and the second timer to be reset, RU.

7. In the fifth paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: Based on transmitting the fourth message, it is identified that a fifth message for resetting the first timer and the second timer is not received until the second timer expires, further causing a failure of the operation for said supervision to be identified based on identifying that said fifth message is not received until said second timer expires; RU.

8. In the first paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: Establishing the first session based on transmitting a message to the client server to perform a call home to the client server using the first port, further causing the second session to be established based on sending another message to the client server for performing a call home to the client server using the first port; RU.

9. In the first paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the RU to: Establishing the first session based on transmitting a message to the client server to perform a call home for the client server using the first port, Further causing the second session to be established based on receiving another message from the client server for performing a call home for the RU using a second port distinct from the first port. RU. In a method performed in 10.RU (radio unit), An operation of establishing a first session and a second session distinct from the first session, the first session comprising at least one of a DU (distributed unit) or an SMO (service management and orchestration); Through said first session, an operation of transmitting to or receiving from said client server at least one first message for an operation for supervision; and An operation comprising transmitting to or receiving from the client server, through the second session, at least one second message for operation on a management plane (M-plane) between the DU and the RU, while the at least one first message is transmitted or received through the first session. method.

11. On the client server, Transmitter and receiver; A memory storing instructions and including one or more storage media; and comprising at least one processor including a processing circuit; The above instructions, when executed individually or collectively by the at least one processor, cause the client server to: Establishing a first session and a second session distinct from the first session with the RU (radio unit), Through said first session, at least one first message for operation for supervision is transmitted to or received from said RU, While at least one first message is transmitted or received through the first session, causing at least one second message to be transmitted to or received from the RU for operation on a management plane (M-plane) between a distributed unit (DU) and the RU through the second session. Client server.

12. In the 11th paragraph, each of the first session and the second session, Established based on either SSH (secure shell / transmission control protocol) or TLS (transport layer security), Client server.

13. In paragraph 11, at least one first message, Contains a third message for requesting supervision notification and a fourth message for supervision notification; The above instructions, when executed individually or collectively by the at least one processor, cause the client server to: Transmit the above third message to the RU, Based on the third message, further causing the RU to receive a fourth message indicating that the RU is operating normally. Client server.

14. In the 13th paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the client server to: Based on transmitting the third message, further causing the first timer and the second timer to be activated for the RU. Client server.

15. In a method performed on a client server, An operation of establishing a first session and a second session distinct from the first session with a RU (radio unit); An operation of transmitting to or receiving from the RU at least one first message for an action for supervision through the first session; An operation comprising: transmitting to or receiving from the RU, through the second session, at least one second message for operation on a management plane (M-plane) between a DU (distributed unit) and the RU, while the at least one first message is transmitted or received through the first session; method.

Images