Electronic device and method for establishing session

Abstract

According to one embodiment, a method performed by a client server comprises an operation of establishing a first session with an RU by using first connection information, which is connection information of the client server. The method comprises the operations of: changing the connection information of the client server from the first connection information to second connection information while the first session is established; transmitting the second connection information to the RU so that connection information of the RU is changed from the first connection information to the second connection information; receiving, from the RU, a message for performing a call home for the client server; determining whether a reset process of the RU has been identified; and determining whether to use the second connection information in order to establish a second session with the RU according to whether a reset process of the RU has been identified.

Description

Electronic device and method for establishing a session

[0001] The present disclosure relates to an electronic device and method for establishing 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 client server may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and may include a memory for storing instructions. 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) using first connection information, which is connection information of the client server. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to change the connection information of the client server from the first connection information to second connection information while the first session is established. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to transmit the second connection information to the RU, such that the connection information of the RU is changed from the first connection information to the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to receive a message from the RU for performing a call home for the client server based on transmitting the second connection information to the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the client server, in response to receiving the message, to determine whether a reset process of the RU has been identified.The instructions, when individually or collectively executed by the at least one processor, may cause the client server to determine whether to use the second connection information to establish a second session with the RU, depending on whether a reset process of the RU has been identified.

[0005] According to one embodiment, a radio unit (RU) may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and may include a memory for storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to establish a first session with the client server using first connection information, which is connection information of the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to receive second connection information from the client server while the first session is established. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to change the connection information of the RU from the first connection information to the second connection information based on receiving the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to perform a reset process in response to identifying an anomaly of the RU after the connection information of the RU has changed from the first connection information to the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to, after the reset process is performed, transmit a message to the client server for performing a call home for the client server configured based on the first connection information.

[0006] According to one embodiment, a method performed on a client server may include an operation of establishing a first session with an RU using first connection information, which is connection information of the client server. The method may include an operation of changing the connection information of the client server from the first connection information to second connection information while the first session is established. The method may include an operation of transmitting the second connection information to the RU, such that the connection information of the RU is changed from the first connection information to the second connection information. The method may include an operation of receiving, from the RU, a message for performing a call home for the client server based on transmitting the second connection information to the RU. The method may include an operation of determining, in response to receiving the message, whether a reset process of the RU has been identified. The method may include an operation of determining, based on whether a reset process of the RU has been identified, whether to use the second connection information to establish a second session with the RU.

[0007] According to one embodiment, a method performed in a radio unit (RU) may include an operation of establishing a first session with the client server using first connection information, which is connection information of the RU. The method may include an operation of receiving second connection information from the client server while the first session is established. The method may include an operation of changing the connection information of the RU from the first connection information to the second connection information based on receiving the second connection information. The method may include an operation of performing a reset process in response to identifying an anomaly of the RU after the connection information of the RU is changed from the first connection information to the second connection information. The method may include an operation of transmitting, to the client server after the reset process is performed, a message for performing a call home for the client server configured based on the first connection information.

[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 11 illustrates an example of the operation of a NETCONF client and a NETCONF server for establishing a session when connection information has changed.

[0022] Figure 12a illustrates an example of the operation of a NETCONF client and a NETCONF server when a reset process is performed on the NETCONF server after connection information has been changed.

[0023] Figure 12b illustrates an example of the operation of a NETCONF client and a NETCONF server when an abnormality occurs in the second connection information on the NETCONF server after the connection information has been changed.

[0024] Figure 13 is a flowchart regarding the operation of the NETCONF client when connection information is changed.

[0025] Figure 14 is a flowchart regarding the operation of the NETCONF server when connection information is changed.

[0026] Figure 15 is a flowchart regarding the operation of a client server when connection information is changed.

[0027] Figure 16 is a flowchart regarding the operation of RU when connection information is changed.

[0028] Figure 17 is a flowchart regarding the operation of RU when connection information is changed.

[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] The present disclosure relates to some communication standards (e.g., 3GPP (3 rdAlthough various embodiments are described using terms used in the Generation Partnership Project, xRAN (extensible radio access network), and O-RAN (open-radio access network), these are merely examples for illustrative purposes. 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 terminals (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) includes an 'access point (AP)', an 'eNodeB (eNB)', and a '5G node (5 th It may be referred to as 'next generation node (gNB)', 'wireless point', 'transmission / reception point (TRP)' or other terms having equivalent technical meaning.

[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 DU (distributed unit)) and an RF (radio frequency) processing unit (or RU (radio unit)). However, in 4G (4 th As higher frequency bands are used in the 5G 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 cost burden on operators to install base stations has also increased. In order to minimize the installation cost of base stations, a structure has been proposed in which the DU and RU of the 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 expansion 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 illustrated 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 DU and RU. As wireless communication technology advances (e.g., 5G (5 th With the introduction of 5G communication systems (or NR (new radio) communication systems), the frequency bands used have increased further. As the cell radius of the base station has become significantly smaller, the number of RUs required for installation has also increased further. Furthermore, in the 5G communication system, 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, thereby lowering 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)) may be configured to manage a NETCONF server (e.g., RU (220) of FIGS. 2A to 3B). The NETCONF client may establish a session with the NETCONF server to perform operations on a management plane (M-plane). In the following, the operations of the NETCONF client and the NETCONF server 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 local private IPs (IPs) resolved by routable IPs (IPs) or 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] According to one embodiment, the NETCONF client (812) can set (or change) connection information for establishing a session. For example, the NETCONF client (812) can establish a session with the NETCONF server (811) using the connection information of the NETCONF client (812) (or connection information stored in the memory of the NETCONF client). If the connection information of the NETCONF client (812) and the connection information of the NETCONF server (811) are the same, a session can be established. According to an embodiment, the NETCONF client (812) can change the connection information of the NETCONF client (812) and send a message to the NETCONF server for changing the connection information of the NETCONF server (811). Below, an example of the operation of the NETCONF client (812) and the NETCONF server (811) for establishing a session when a reset process is performed on the NETCONF server (811) after the connection information of the NETCONF server (811) is changed will be described.

[0178] Figure 11 illustrates an example of the operation of a NETCONF client and a NETCONF server for establishing a session when connection information has changed.

[0179] Referring to FIG. 11, in operation 1101, the NETCONF server (811) and the NETCONF client (812) can establish a first NETCONF session using the first connection information. For example, the first connection information can be set by default in the NETCONF server (811) and the NETCONF client (812). For example, when the NETCONF server (811) is connected to the NETCONF client (812) for the first time, the NETCONF server (811) and the NETCONF client (812) can establish a first NETCONF session using the first connection information.

[0180] According to one embodiment, the NETCONF server (811) can store connection information for establishing a session. The connection information stored in the NETCONF server (811) can be referenced as connection information of the NETCONF server (811). The NETCONF client (812) can store connection information for establishing a session. The connection information stored in the NETCONF client (812) can be referenced as connection information of the NETCONF client (812).

[0181] For example, the connection information of the NETCONF server (811) may be set as the first connection information. The connection information of the NETCONF client (812) may be set as the first connection information. When the connection information of the NETCONF server (811) and the connection information of the NETCONF client (812) are set to be the same, a session between the NETCONF server (811) and the NETCONF client (812) may be established. For example, the NETCONF server (811) may transmit a message to the NETCONF client (812) to perform a 'call home' configured using the first connection information. The NETCONF server (811) may use the message to request the NETCONF client (812) to establish a session. According to an embodiment, the NETCONF client (812) may send a message to the NETCONF server (811) to perform a 'call home' configured using the first connection information. The NETCONF client (812) may use the message to request the NETCONF server (811) to establish a session.

[0182] The NETCONF client (812) and the NETCONF server (811) can establish a first NETCONF session using a message (or first connection information) to perform a 'call home' configured using the first connection information.

[0183] In operation 1102, the NETCONF client (812) may change the connection information of the NETCONF client (812) from the first connection information to the second connection information. For example, the NETCONF client (812) may change the connection information of the NETCONF client (812) from the first connection information to the second connection information while the first NETCONF session is established.

[0184] For example, the NETCONF client (812) can change the connection information of the NETCONF client (812) from the first connection information to the second connection information in order to change the connection settings for the NETCONF session.

[0185] In operation 1103, the NETCONF client (812) may transmit second connection information to the NETCONF server (811) to change the connection information of the NETCONF server (811) from the first connection information to the second connection information. For example, the NETCONF server (811) may receive the second connection information from the NETCONF client (812).

[0186] In operation 1104, in response to receiving the second connection information, the NETCONF server (811) may change the connection information of the NETCONF server (811) from the first connection information to the second connection information.

[0187] For example, the first NETCONF session may be terminated based on the connection information of the NETCONF server (811) being changed (or set) to the second connection information. For example, the NETCONF server (811) may deactivate the first connection information after the connection information of the NETCONF server (811) is changed. The NETCONF server (811) may activate only the second connection information.

[0188] In operation 1105, the NETCONF server (811) can send a message to the NETCONF client (812) to perform a 'call home' configured using the second connection information. Since the connection information of the NETCONF server (811) is set as the second connection information, the NETCONF server (811) can configure a message to perform a 'call home' using the second connection information. The NETCONF server (811) can send a message to the NETCONF client (812) to perform a 'call home' in order to establish a second NETCONF session.

[0189] In operation 1106, the NETCONF server (811) and the NETCONF client (812) may establish a second NETCONF session using the second connection information. For example, the NETCONF client (812) and the NETCONF server (811) may establish a second NETCONF session using a message (or the second connection information) for performing a 'call home' configured using the second connection information.

[0190] According to one embodiment, the first connection information and the second connection information may be related to at least one of information about a user account of the NETCONF client (812) and the NETCONF server (811), information about an SSH (secure shell) port for 'call home', information about an SSH server port, information about a TSL (transport layer security) port for 'call home', or information about a TLS server port.

[0191] For example, information about user accounts of the NETCONF client (812) and the NETCONF server (811) can be configured as shown in Tables 1 and 2 below.

[0192]

[0193]

[0194] Referring to Table 1 and Table 2, information about the user account of the NETCONF client (812) and the NETCONF server (811) may include information about the account name, information about the account type, information about the account password, information about whether the account is activated, and / or information about whether the NETCONF server (811) (e.g., RU (220)) is connected to multiple NETCONF clients.

[0195] For example, the first connection information may be information set by default in the NETCONF client (812) and the NETCONF server (811). The second connection information may be information changed in the NETCONF client (812).

[0196] For example, when the initial system is initialized, the account name for the account type of PASSWORD may be set to 'oranuser'. The first connection information may include information about the account name set to 'oranuser'. When the initial system is initialized, the password for the account type of PASSWORD may be 'o-ran-password'. The first connection information may include information about the account password set to 'o-ran-password'. The above examples are exemplary, and the first connection information may be changed depending on the NETCONF client (812) and the NETCONF server (811).

[0197] For example, information about the SSH port for 'call home' and information about the SSH server port can be configured as shown in Table 3 below.

[0198]

[0199] Referring to Table 3, information about the SSH port for 'call home' ('call-home-ssh-port') may include information about the default port of the SSH port for 'call home'. Port 4334 may be set as the default port of the SSH port for 'call home'. The first connection information may include information about the default port of the SSH port for 'call home', which is set to port 4334. Information about the SSH server port ('server-ssh-port') may include information about the default port of the SSH server port. Port 830 may be set as the default port of the SSH server port. The first connection information may include information about the default port of the SSH server port, which is set to port 830.

[0200] For example, information about the TSL (transport layer security) port for 'call home' and information about the TLS server port can be configured as shown in Table 4 below.

[0201]

[0202] Referring to Table 4, information about the TLS port for 'call home' ('call-home-tls-port') may include information about the default port of the TLS port for 'call home'. Port 4335 may be set as the default port of the TLS port for 'call home'. The first connection information may include information about the default port of the TLS port for 'call home', which is set to port 4334. Information about the TLS server port ('server-tls-port') may include information about the default port of the TLS server port. Port 6513 may be set as the default port of the TLS server port. The first connection information may include information about the default port of the TLS server port, which is set to port 6513.

[0203] According to one embodiment, the NETCONF client (812) can change the connection information of the NETCONF client (812) and the connection information of the NETCONF server (811). The NETCONF client (812) can change the connection information of the NETCONF server (811) through the first NETCONF session and close the first NETCONF session. The NETCONF client (812) and the NETCONF server (811) can establish a second NETCONF session using the changed connection information (i.e., the second connection information).

[0204] Figure 12a illustrates an example of the operation of a NETCONF client and a NETCONF server when a reset process is performed on the NETCONF server after connection information has been changed.

[0205] Referring to FIG. 12A, in operation 1201, the NETCONF server (811) and the NETCONF client (812) may establish a first NETCONF session using the first connection information. For example, the first connection information may be set by default in the NETCONF server (811) and the NETCONF client (812). For example, when the NETCONF server (811) is connected to the NETCONF client (812) for the first time, the NETCONF server (811) and the NETCONF client (812) may establish a first NETCONF session using the first connection information. Operation 1201 may correspond to operation 1101 of FIG. 11.

[0206] In operation 1202, the NETCONF client (812) may change the connection information of the NETCONF client (812) from the first connection information to the second connection information. Operation 1202 may correspond to operation 1102 of FIG. 11.

[0207] In operation 1203, the NETCONF client (812) may transmit second connection information to the NETCONF server (811) to change the connection information of the NETCONF server (811) from first connection information to second connection information. Operation 1203 may correspond to operation 1103 of FIG. 11.

[0208] In operation 1204, in response to receiving the second connection information, the NETCONF server (811) may change the connection information of the NETCONF server (811) from the first connection information to the second connection information. Operation 1204 may correspond to operation 1104 of FIG. 11.

[0209] In operation 1205, the NETCONF server (811) may perform a reset process. For example, the reset process may mean a process for initializing configuration information of the NETCONF server (811).

[0210] According to one embodiment, the NETCONF client (812) can instruct the NETCONF server (811) to perform a reset process. For example, the NETCONF client (812) can send a message to the NETCONF server (811) to instruct it to perform a reset process. The NETCONF server (811) can perform the reset process based on the received message. When the NETCONF server (811) performs the reset process through the message received from the NETCONF client (812), the NETCONF client (812) can identify that the reset process is performed on the NETCONF server (811).

[0211] According to one embodiment, the NETCONF server (811) can identify an anomaly of the NETCONF server (811). The NETCONF server (811) can perform a reset process based on the anomaly of the NETCONF server (811). If the NETCONF server (811) identifies an anomaly, the NETCONF server (811) can perform the reset process on its own. If the NETCONF server (811) performs the reset process on its own, the NETCONF client (812) may not be able to identify that the reset process is performed on the NETCONF server (811).

[0212] According to one embodiment, the NETCONF server (811) may initialize the connection information of the NETCONF server (811) based on performing the reset process. The NETCONF server (811) may deactivate the second connection information. The NETCONF server (811) may set the connection information of the NETCONF server (811) as the first connection information. For example, the first connection information may be stored in the persistent memory of the NETCONF server (811). The NETCONF server (811) may set the connection information of the NETCONF server (811) using the first connection information stored in the persistent memory of the NETCONF server (811) based on performing the reset process.

[0213] In operation 1206, the NETCONF server (811) may transmit a message to the NETCONF client (812) for performing a call home configured using the first connection information. For example, the NETCONF server (811) may transmit a message to the NETCONF client (812) for performing a call home in order to establish a second NETCONF session with the NETCONF client (812). Since the connection information of the NETCONF server (811) is set as the first connection information, the NETCONF server (811) may configure a message to perform a call home using the first connection information.

[0214] The NETCONF client (812) can receive a message for performing a call home configured using the first connection information. Although the connection information of the NETCONF client (812) is set to the second connection information, the NETCONF client (812) can support the first connection information. Therefore, even if the connection information of the NETCONF client (812) is set to the second connection information, if the connection information of the NETCONF server (811) is changed to the first connection information according to the reset process, the NETCONF client (812) can perform a call home procedure with the NETCONF server (811) using the first connection information.

[0215] In operation 1207, if a reset process is performed on the NETCONF server (811), the NETCONF server (811) and the NETCONF client (812) can establish a second NETCONF session using the first connection information. For example, if a reset process is performed on the NETCONF server (811), the connection information of the NETCONF server (811) can be set as the first connection information. The NETCONF server (811) and the NETCONF client (812) can establish a second NETCONF session using the first connection information. For example, the NETCONF client (812) and the NETCONF server (811) can establish a second NETCONF session using a message (or the first connection information) for performing a 'call home' configured using the first connection information.

[0216] Figure 12b illustrates an example of the operation of a NETCONF client and a NETCONF server when an abnormality occurs in the second connection information on the NETCONF server after the connection information has been changed.

[0217] Referring to FIG. 12b, in operation 1211, the NETCONF server (811) and the NETCONF client (812) may establish a first NETCONF session using the first connection information. For example, operation 1211 may correspond to operation 1201 of FIG. 12a.

[0218] In operation 1212, the NETCONF client (812) may change the connection information of the NETCONF client (812) from the first connection information to the second connection information. Operation 1212 may correspond to operation 1202 of FIG. 12A.

[0219] In operation 1213, the NETCONF client (812) may send second connection information to the NETCONF server (811) to change the connection information of the NETCONF server (811) from first connection information to second connection information. Operation 1213 may correspond to operation 1203 of FIG. 12A.

[0220] In operation 1214, in response to receiving the second connection information, the NETCONF server (811) may change the connection information of the NETCONF server (811) from the first connection information to the second connection information. Operation 1214 may correspond to operation 1204 of FIG. 12A.

[0221] In operation 1215, the NETCONF server (811) may identify that an abnormality has occurred in the second connection information. For example, the NETCONF server (811) may identify that a loss of the second connection information has occurred. For example, the NETCONF server (811) may identify that a call home is not performed using the second connection information. For example, the loss of the second connection information may occur due to an error in the NETCONF server (811). The NETCONF server (811) may identify that an abnormality has occurred in the second connection information based on the occurrence of the loss of the second connection information. For example, the NETCONF server (811) may not be able to use the second connection information. The NETCONF server (811) may identify that an abnormality has occurred in the second connection information based on the inability to use the second connection information. For example, a bug may occur in the NETCONF server (811). The NETCONF server (811) may initialize some of its functions due to a bug. As the NETCONF server (811) initializes some of its functions, an abnormality in the second connection information may occur.

[0222] In operation 1216, the NETCONF server (811) may transmit a message to the NETCONF client (812) for performing a call home configured using the first connection information. Since an error has occurred in the second connection information, the NETCONF server (811) may not be able to configure a message to perform a call home using the second connection information. Accordingly, the NETCONF server (811) may transmit a message to the NETCONF client (812) for performing a call home configured using the first connection information. Operation 1216 may correspond to operation 1206 of FIG. 12A.

[0223] In operation 1217, if a reset process is performed on the NETCONF server (811), the NETCONF server (811) and the NETCONF client (812) may establish a second NETCONF session using the first connection information. Operation 1217 may correspond to operation 1207 of FIG. 12A.

[0224] Figure 13 is a flowchart regarding the operation of the NETCONF client when connection information is changed.

[0225] Referring to FIG. 13, in operation 1301, a NETCONF client (812) can establish a first NETCONF session with a NETCONF server (811) using first connection information.

[0226] For example, the connection information of the NETCONF client (812) may be set as the first connection information. The first connection information may be the default connection information of the NETCONF client (812). The connection information of the NETCONF server (811) may also be set as the first connection information. The first connection information may be the default connection information of the NETCONF server (811). When the connection information of the NETCONF client (812) and the connection information of the NETCONF server (811) are set to be the same as the first connection information, the NETCONF client (812) and the NETCONF server (811) may establish a first NETCONF session using the first connection information.

[0227] The first connection information may be related to at least one of information about a user account of the NETCONF client (812) and the NETCONF server (811), information about an SSH (secure shell) port for 'call home', information about an SSH server port, information about a TSL (transport layer security) port for 'call home', or information about a TLS server port. For example, the first connection information may be set according to at least one of Tables 1 to 4.

[0228] In operation 1302, the NETCONF client (812) can change the connection information of the NETCONF client (812) from the first connection information to the second connection information.

[0229] For example, the second connection information may be related to at least one of information about a user account of the NETCONF client (812) and the NETCONF server (811), information about an SSH (secure shell) port for 'call home', information about an SSH server port, information about a TSL (transport layer security) port for 'call home', or information about a TLS server port. As an example, the second connection information may be managed in the NETCONF client (812).

[0230] For example, the NETCONF client (812) can change the name of a user account. For example, the NETCONF client (812) can change the password of a user account. The NETCONF client (812) can change the SSH port for 'call home'. The NETCONF client (812) can change the SSH server port. The NETCONF client (812) can change the TLS port for 'call home'. The NETCONF client (812) can change the TLS server port.

[0231] In operation 1302, the NETCONF client (812) may transmit second connection information to the NETCONF server (811). For example, the NETCONF client (812) may transmit the second connection information to the NETCONF server (811) via the first NETCONF session. Since the NETCONF client (812) manages the NETCONF server (811), the second connection information may be transmitted to the NETCONF server (811) in order to change the connection information of the NETCONF server (811). The NETCONF client (812) may transmit the second connection information to the NETCONF server (811) so that a session may be established with the NETCONF server (811) using the second connection information.

[0232] According to one embodiment, based on the second connection information being transmitted, the NETCONF client (812) may close the first NETCONF session. The NETCONF client (812) may close the first NETCONF session based on a change in the connection information of the NETCONF client (812).

[0233] In operation 1304, the NETCONF client (812) can identify whether a reset process has been performed on the NETCONF server (811). For example, after the second connection information is transmitted, the NETCONF server (811) can perform a reset process. The reset process may be performed according to an instruction of the NETCONF client (812) or according to an anomaly of the NETCONF server (811). If the reset process is performed on the NETCONF server (811), the connection information of the NETCONF server (811) may be set as the first connection information. The first connection information may be stored in a persistent memory of the NETCONF server (811). If the reset process is performed on the NETCONF server (811), the first connection information may be set as the connection information of the NETCONF server (811).

[0234] In operation 1305, if a reset process is performed on the NETCONF server (811), the NETCONF client (812) can establish a second NETCONF session with the NETCONF server (811) using the first connection information.

[0235] For example, if a reset process is performed on the NETCONF server (811), the NETCONF client (812) can receive a message for 'call home' configured using the first connection information from the NETCONF server (811). The NETCONF client (812) can establish a second NETCONF session based on the received message.

[0236] For example, if a reset process is performed on the NETCONF server (811), the NETCONF client (812) can send a message for 'call home' configured using the first connection information to the NETCONF server (811). The NETCONF client (812) can establish a second NETCONF session based on the sent message.

[0237] In operation 1306, if the reset process is not performed on the NETCONF server (811), the NETCONF client (812) can establish a second NETCONF session with the NETCONF server (811) using the second connection information.

[0238] For example, if a reset process is not performed on the NETCONF server (811), the NETCONF client (812) may receive a message for 'call home' configured using the second connection information from the NETCONF server (811). The NETCONF client (812) may establish a second NETCONF session based on the received message.

[0239] According to the above-described operations 1301 to 1306, the NETCONF client (812) can support both the first connection information and the second connection information. If the reset process is performed in the NETCONF server (811), the NETCONF client (812) can establish a second NETCONF session connection with the NETCONF server (811) using the first connection information. If the reset process is not performed in the NETCONF server (811), the NETCONF client (812) can establish a second NETCONF session connection with the NETCONF server (811) using the second connection information.

[0240] Figure 14 is a flowchart regarding the operation of the NETCONF server when connection information is changed.

[0241] Referring to FIG. 14, in operation 1401, the NETCONF server (811) can establish a first NETCONF session with the NETCONF client (812) using the first connection information.

[0242] For example, the connection information of the NETCONF server (811) may be set as the first connection information. The first connection information may be the default connection information of the NETCONF server (811). The connection information of the NETCONF client (812) may be set as the first connection information. The first connection information may be the default connection information of the NETCONF client (812). When the connection information of the NETCONF client (812) and the connection information of the NETCONF server (811) are set to be the same as the first connection information, the NETCONF client (812) and the NETCONF server (811) may establish a first NETCONF session using the first connection information.

[0243] The first connection information may be related to at least one of information about a user account of the NETCONF client (812) and the NETCONF server (811), information about an SSH (secure shell) port for 'call home', information about an SSH server port, information about a TSL (transport layer security) port for 'call home', or information about a TLS server port. For example, the first connection information may be set according to at least one of Tables 1 to 4.

[0244] In operation 1402, the NETCONF server (811) may receive second connection information from the NETCONF client (812). For example, the NETCONF server (811) may receive second connection information from the NETCONF client (812) via the first NETCONF session.

[0245] For example, the second connection information may be related to at least one of information about a user account of the NETCONF client (812) and the NETCONF server (811), information about an SSH (secure shell) port for 'call home', information about an SSH server port, information about a TSL (transport layer security) port for 'call home', or information about a TLS server port. As an example, the second connection information may be managed in the NETCONF client (812).

[0246] In operation 1403, the NETCONF server (811) may change the connection information of the NETCONF server from the first connection information to the second connection information. For example, in response to receiving the second connection information from the NETCONF client (812), the NETCONF server (811) may change the connection information of the NETCONF server (811) from the first connection information to the second connection information.

[0247] For example, the NETCONF server (811) can change the name of a user account. For example, the NETCONF server (811) can change the password of a user account. The NETCONF server (811) can change the SSH port for 'call home'. The NETCONF server (811) can change the SSH server port. The NETCONF server (811) can change the TLS port for 'call home'. The NETCONF server (811) can change the TLS server port.

[0248] According to one embodiment, the NETCONF server (811) may close the first NETCONF session based on changing the connection information of the NETCONF server (811) from the first connection information to the second connection information. The NETCONF server (811) may close the first NETCONF session based on the change in the connection information of the NETCONF server (811). The NETCONF server (811) may deactivate the first connection information after the connection information of the NETCONF server (811) is changed. The NETCONF server (811) may activate only the second connection information.

[0249] In operation 1404, the NETCONF server (811) can identify whether a reset process has been performed. For example, after the connection information of the NETCONF server (811) has been changed from the first connection information to the second connection information, it can identify whether a reset process has been performed.

[0250] According to one embodiment, the NETCONF server (811) may receive a message from the NETCONF client (812) instructing it to perform a reset process. The NETCONF server (811) may perform the reset process based on the received message.

[0251] According to one embodiment, the NETCONF server (811) can identify an anomaly of the NETCONF server (811). The NETCONF server (811) can perform a reset process based on the anomaly of the NETCONF server (811). If the NETCONF server (811) identifies an anomaly, the NETCONF server (811) can perform a reset process on its own.

[0252] In operation 1405, if a reset process is performed in the NETCONF server (811), the NETCONF server (811) may establish a second NETCONF session with the NETCONF client (812) using the first connection information. According to one embodiment, if the reset process is performed, the NETCONF server (811) may initialize the connection information of the NETCONF server (811). If the reset process is performed in the NETCONF server (811), the connection information of the NETCONF server (811) may be set as the first connection information. The first connection information may be stored in a persistent memory of the NETCONF server (811). If the reset process is performed in the NETCONF server (811), the first connection information may be set as the connection information of the NETCONF server (811).

[0253] For example, when a reset process is performed on the NETCONF server (811), the NETCONF server (811) can receive a message for 'call home' configured using the first connection information from the NETCONF client (812). The NETCONF server (811) can establish a second NETCONF session based on the received message.

[0254] For example, when a reset process is performed on the NETCONF server (811), the NETCONF server (811) can send a message for 'call home' configured using the first connection information to the NETCONF client (812). The NETCONF server (811) can establish a second NETCONF session based on the sent message.

[0255] In operation 1406, if the reset process is not performed on the NETCONF server (811), the NETCONF server (811) may establish a second NETCONF session with the NETCONF client (812) using the second connection information. For example, if the reset process is not performed on the NETCONF server (811), the connection information of the NETCONF server (811) may be maintained as the second connection information. The NETCONF server (811) may establish a second NETCONF session with the NETCONF client (812) using the second connection information. For example, the NETCONF client (812) and the NETCONF server (811) may establish a second NETCONF session using a message (or the second connection information) for performing a 'call home' configured using the second connection information. The NETCONF server (811) can perform a call home procedure with the NETCONF client (812) using the second connection information.

[0256] Figure 15 is a flowchart regarding the operation of a client server when connection information is changed.

[0257] Referring to FIG. 15, the client server described below may be an example of the NETCONF client (812) described above. For example, the client server may include at least one of the DU (210) or the SMO (610). The RU (220) described below may be an example of the NETCONF server (811) described above.

[0258] In operation 1501, the client server (or the processor of the client server, or the electronic device executed by the client server) may establish a first session (e.g., a first NETCONF session) with the RU (220) using the first connection information. For example, the client server may establish a first session with the RU (220) using the first connection information, which is the connection information of the client server. Operation 1501 may correspond to operation 1301 of FIG. 13.

[0259] In operation 1502, the client server may change its connection information from the first connection information to the second connection information. For example, while the first session is established, the client server may change its connection information from the first connection information to the second connection information. Operation 1502 may correspond to operation 1302 of FIG. 13.

[0260] For example, the first connection information and the second connection information may be related to at least one of information about a user account of the client server and RU (220), information about an SSH (secure shell) port for call home, information about an SSH server port, information about a TLS (transport layer security) port for call home, or information about a TLS server port.

[0261] In operation 1503, the client server may transmit second connection information to the RU (220). For example, the client server may transmit the second connection information to the RU (220) so that the connection information of the RU (220) is changed from the first connection information to the second connection information. Operation 1503 may correspond to operation 1303 of FIG. 13.

[0262] In operation 1504, the client server may receive a message from the RU (220) to perform a call home for the client server. For example, the client server may receive a message from the RU (220) to perform a call home for the client server based on transmitting second connection information to the RU (220).

[0263] According to one embodiment, a message for performing a call home to a client server may be configured based on one of the first connection information and the second connection information. For example, information for configuring a message for performing a call home to a client server may be determined based on whether a reset process has been performed in the RU (220). Accordingly, the client server can identify whether a reset process has been performed in the RU (220) at operation 1505.

[0264] In operation 1505, the client server may determine whether a reset process for the RU (220) has been identified. For example, in response to receiving the message, the client server may determine whether a reset process for the RU (220) has been identified. Depending on whether a reset process has been identified, the client server may determine whether to use the second connection information to establish a second session.

[0265] In operation 1508, if the reset process of the RU (220) is not identified, the client server may perform a second session connection procedure with the RU (220) using the second connection information. For example, based on the fact that the reset process of the RU (220) is not identified, the client server may perform a second session connection procedure with the RU (220) using the second connection information. The second session connection procedure may be performed using the second connection information.

[0266] In one embodiment, the client server may not identify the reset process of the RU (220) even though the reset process has been performed in the RU (220). The client server may fail the second session connection procedure. For example, the reset process of the RU (220) may be performed based on an anomaly of the RU (220). The reset process performed based on the anomaly of the RU (220) may not be identified by the client server. Based on the failure of the second session connection procedure, the client server may perform operation 1506.

[0267] Although not shown, the client server may not have identified the reset process of the RU (220), and the reset process may not have been performed in the RU (220). In this case, the connection information of the RU (220) may be maintained as the second connection information. The client server may succeed in the second session connection procedure. The client server may establish a second session with the RU (220) based on the second session connection procedure. The client server may receive a message for performing a call home for the client server through the session connection procedure. The message may be configured based on the second connection information. The client server may establish a second session with the RU (220) using the second connection information.

[0268] In operation 1506, if the reset process of RU (220) is identified or the second session connection procedure fails, the client server can perform the first session connection procedure with RU (220) using the first connection information.

[0269] According to one embodiment, the client server may transmit a message instructing the RU (220) to perform a reset process. The RU (220) may perform the reset process based on the message. When the client server transmits the message instructing the RU (220) to perform the reset process, the client server may identify the reset process of the RU (220). When the client server identifies the reset process of the RU (220), the client server may perform a first session connection procedure with the RU (220) using the first connection information. For example, the client server may identify that the received message is configured based on the first connection information. The client server may perform the first session connection procedure based on the received message.

[0270] At step 1507, the client server may establish a second session (e.g., a second NETCONF session) with the RU (220) using the first connection information. The client server may establish a second session with the RU (220) based on the success of the first session connection procedure. For example, the client server may perform step 1507 based on receiving a message for performing a call home for the client server. The message may be configured based on the first connection information.

[0271] Figure 16 is a flowchart regarding the operation of RU when connection information is changed.

[0272] Referring to FIG. 16, the client server described below may be an example of the NETCONF client (812) described above. For example, the client server may include at least one of the DU (210) or the SMO (610). The RU (220) described below may be an example of the NETCONF server (811) described above.

[0273] In operation 1601, the RU (220) (or the processor of the RU (220), the electronic device executed by the RU (220)) may establish a first session with the client server using the first connection information. The RU (220) may establish a first session with the client server using the first connection information, which is the connection information of the RU (220). Operation 1601 may correspond to operation 1401 of FIG. 14.

[0274] In operation 1602, RU (220) may receive second connection information from the client server. For example, RU (220) may receive second connection information from the client server while the first session is established. Operation 1602 may correspond to operation 1402 of FIG. 14.

[0275] For example, the first connection information and the second connection information may be related to at least one of information about a user account of the client server and RU (220), information about an SSH (secure shell) port for call home, information about an SSH server port, information about a TLS (transport layer security) port for call home, or information about a TLS server port.

[0276] In operation 1603, the RU (220) may change the connection information of the RU (220) from the first connection information to the second connection information. For example, based on receiving the second connection information, the RU (220) may change the connection information of the RU (220) from the first connection information to the second connection information. For example, based on receiving the second connection information from the client server, the RU (220) may change the connection information of the RU (220) to the second connection information and store it. Operation 1603 may correspond to operation 1403 of FIG. 14.

[0277] At operation 1604, the RU (220) may determine whether an anomaly has been identified. For example, the RU (220) may determine whether an anomaly has been identified to determine whether a reset process should be performed.

[0278] In operation 1605, if an abnormality of the RU (220) is identified, the RU (220) may perform a reset process. For example, by performing the reset process of the RU (220), the configuration information of the RU (220) may be initialized. Based on performing the reset process, the RU (220) may set the connection information of the RU (220) as the first connection information. The RU (220) may use the first connection information stored in the persistent memory of the RU (220) to set the connection information of the RU (220) as the first connection information.

[0279] In operation 1606, the RU (220) may transmit a message to the client server for performing a call home, configured based on the first connection information. Since the connection information of the RU (220) has been set to the first connection information through the reset process, the RU (220) may configure a message for performing a call home to the client server based on the first connection information. The RU (220) may transmit the message to the client server.

[0280] In operation 1607, RU (220) may establish a second session with the client server using the first connection information. For example, RU (220) may perform the first session connection procedure by sending a message to the client server for performing a call home for the client server, which is configured based on the first connection information. RU (220) may establish a second session with the client server based on the success of the first session connection procedure. Operation 1607 may correspond to operation 1405 of FIG. 14 .

[0281] In operation 1608, if an abnormality in RU (220) is not identified, RU (220) may transmit a message to the client server for performing a call home, configured based on the second connection information. For example, if an abnormality in RU (220) is not identified, the reset process may not be performed. The connection information of RU (220) may be maintained as the second connection information.

[0282] For example, since the connection information of RU (220) is maintained as the second connection information, RU (220) can construct a message for performing a call home to the client server based on the second connection information. RU (220) can transmit the message to the client server.

[0283] In operation 1609, RU (220) may establish a second session with the client server using the second connection information. For example, RU (220) may perform a second session connection procedure by sending a message to the client server for performing a call home for the client server, which is configured based on the second connection information. RU (220) may establish a second session with the client server based on the success of the second session connection procedure. Operation 1609 may correspond to operation 1406 of FIG. 14 .

[0284] Figure 17 is a flowchart regarding the operation of RU when connection information is changed.

[0285] Referring to FIG. 17, the client server described below may be an example of the NETCONF client (812) described above. For example, the client server may include at least one of the DU (210) or the SMO (610). The RU (220) described below may be an example of the NETCONF server (811) described above.

[0286] Referring to FIG. 17, in operation 1701, the RU (220) (or the processor of the RU (220), the electronic device executed by the RU (220)) may establish a first session with the client server using the first connection information. FIG. 17 may correspond to operation 1401 of FIG. 14 or operation 1601 of FIG. 16.

[0287] In operation 1702, RU (220) may receive second connection information from the client server. Operation 1702 may correspond to operation 1402 of FIG. 14 or operation 1602 of FIG. 16.

[0288] In operation 1703, the RU (220) may change the connection information of the RU (220) from the first connection information to the second connection information. Operation 1703 may correspond to operation 1403 of FIG. 14 or operation 1603 of FIG. 16.

[0289] In operation 1704, the RU (220) can identify (or determine) whether an abnormality has occurred in the second connection information. For example, the NETCONF server (811) can identify whether a loss of the second connection information has occurred. For example, the NETCONF server (811) can identify that a call home is not performed using the second connection information. For example, the NETCONF server (811) can identify whether the second connection information cannot be used for session connection. For example, the NETCONF server (811) can identify whether an abnormality has occurred in the second connection information due to a bug occurring in the NETCONF server (811). The NETCONF server (811) can identify whether an abnormality has occurred in the second connection information as it initializes some of the functions of the NETCONF server (811) due to the bug.

[0290] In operation 1705, if an error occurs in the second connection information, the RU (220) may transmit a message configured based on the first connection information to the client server for performing a call home to the client server. Based on identifying that an error occurs in the second connection information, the RU (220) may transmit a message configured based on the first connection information to the client server for performing a call home to the client server. Operation 1705 may correspond to operation 1606 of FIG. 16.

[0291] In operation 1706, RU (220) may establish a second session with the client server using the first connection information. Operation 1706 may correspond to operation 1405 of FIG. 14 or operation 1607 of FIG. 16.

[0292] In operation 1707, if there is no abnormality in the second connection information, the RU (220) may transmit a message configured based on the second connection information to the client server for performing a call home to the client server. Based on identifying that there is no abnormality in the second connection information, the RU (220) may transmit a message configured based on the second connection information to the client server for performing a call home to the client server. Operation 1707 may correspond to operation 1608 of FIG. 16.

[0293] In operation 1708, the RU (220) may establish a second session with the client server using the second connection information. Operation 1708 may correspond to operation 1406 of FIG. 14 or operation 1609 of FIG. 16.

[0294] According to one embodiment, a client server may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and may include a memory for storing instructions. 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) using first connection information, which is connection information of the client server. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to change the connection information of the client server from the first connection information to second connection information while the first session is established. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to transmit the second connection information to the RU, such that the connection information of the RU is changed from the first connection information to the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to receive a message from the RU for performing a call home for the client server based on transmitting the second connection information to the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the client server, in response to receiving the message, to determine whether a reset process of the RU has been identified.The instructions, when individually or collectively executed by the at least one processor, may cause the client server to determine whether to use the second connection information to establish a second session with the RU, depending on whether a reset process of the RU has been identified.

[0295] According to one embodiment, the message for performing the call home for the client server may be configured based on the first connection information.

[0296] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the client server to perform a first session connection procedure with the RU using the first connection information based on the identification of the reset process of the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to establish the second session with the RU based on the success of the first session connection procedure with the RU.

[0297] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the client server to perform a second session connection procedure with the RU using the second connection information based on the reset process of the RU not being identified. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to perform a first session connection procedure with the RU using the first connection information based on a failure of the second session connection procedure with the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the client server to establish the second session with the RU based on a success of the first session connection procedure.

[0298] According to one embodiment, the first connection information and the second connection information may be related to at least one of information about a user account of the client server and the RU, information about an SSH (secure shell) port for call home, information about an SSH server port, information about a TLS (transport layer security) port for call home, or information about a TLS server port.

[0299] According to one embodiment, the message for performing the call home to the client server may be configured based on the second connection information.

[0300] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the client server to establish the second session with the RU using the second connection information.

[0301] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the client server to identify the reset process of the RU based on sending a message instructing the RU to perform the reset process.

[0302] According to one embodiment, the reset process of the RU may be performed based on an anomaly of the RU. The reset process of the RU performed based on the anomaly of the RU may not be identified by the client server.

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

[0304] According to one embodiment, a radio unit (RU) may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and may include a memory for storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to establish a first session with the client server using first connection information, which is connection information of the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to receive second connection information from the client server while the first session is established. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to change the connection information of the RU from the first connection information to the second connection information based on receiving the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to perform a reset process in response to identifying an anomaly of the RU after the connection information of the RU has changed from the first connection information to the second connection information. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to, after the reset process is performed, transmit a message to the client server for performing a call home for the client server configured based on the first connection information.

[0305] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the RU to establish a second session with the client server based on sending the message to the client server.

[0306] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the RU to change the connection information of the RU to the second connection information and store it based on receiving the second connection information from the client server. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to set the connection information of the RU to the first connection information based on performing the reset process.

[0307] According to one embodiment, the first connection information and the second connection information may be related to at least one of information about a user account of the client server and the RU, information about an SSH (secure shell) port for call home, information about an SSH server port, information about a TLS (transport layer security) port for call home, or information about a TLS server port.

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

[0309] According to one embodiment, a method performed by a client server may include establishing a first session with an RU using first connection information, which is connection information of the client server. The method may include changing the connection information of the client server from the first connection information to second connection information while the first session is established. The method may include transmitting the second connection information to the RU, such that the connection information of the RU is changed from the first connection information to the second connection information. The method may include receiving a message from the RU for performing a call home for the client server based on transmitting the second connection information to the RU. The method may include determining, in response to receiving the message, whether a reset process of the RU has been identified. The method may include determining, based on whether a reset process of the RU has been identified, whether to use the second connection information to establish a second session with the RU.

[0310] According to one embodiment, the message for performing the call home for the client server may be configured based on the first connection information.

[0311] According to one embodiment, the method may include performing a first session connection procedure with the RU using the first connection information based on the identification of the reset process of the RU. The method may include establishing the second session with the RU based on the success of the first session connection procedure with the RU.

[0312] According to one embodiment, the first connection information and the second connection information may be related to at least one of information about a user account of the client server and the RU, information about an SSH (secure shell) port for call home, information about an SSH server port, information about a TLS (transport layer security) port for call home, or information about a TLS server port.

[0313] According to one embodiment, a method performed by a radio unit (RU) may include an operation of establishing a first session with the client server using first connection information, which is connection information of the RU. The method may include an operation of receiving second connection information from the client server while the first session is established. The method may include an operation of changing the connection information of the RU from the first connection information to the second connection information based on receiving the second connection information. The method may include an operation of performing a reset process in response to identifying an anomaly of the RU after the connection information of the RU is changed from the first connection information to the second connection information. The method may include an operation of transmitting, to the client server after the reset process is performed, a message for performing a call home for the client server configured based on the first connection information.

[0314] According to the above-described embodiment, even if the connection information of the client server (e.g., SMO (610) or DU (210)) and the connection information of the RU are different, a session connection between the client server and the RU can be automatically performed. Even if the connection information of the client server (e.g., SMO (610) or DU (210)) and the connection information of the RU are different, a session can be established without any artificial intervention of the user. The client server can always support the first connection information. Even if the connection information of the client server is set to the second connection information, the client server can establish a session with the RU using the first connection information.

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

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

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

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

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

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

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

Claims

1. On the client server, Transmitter and receiver; At least one processor comprising processing circuitry; and comprising one or more storage media, and including a memory storing instructions; The above instructions, when individually or collectively executed by the at least one processor, Using the first connection information, which is the connection information of the above client server, a first session is established with the RU (radio unit), While the first session is established, the connection information of the client server is changed from the first connection information to the second connection information, Transmitting the second connection information to the RU so that the connection information of the RU is changed from the first connection information to the second connection information, Based on transmitting the second connection information to the RU, a message for performing a call home for the client server is received from the RU, In response to receiving the above message, determine whether a reset process for the RU has been identified, Causing the client server to determine whether to use the second connection information to establish a second session with the RU, depending on whether the reset process of the RU has been identified. Client server.

2. In the first paragraph, the message for performing the call home to the client server is, Based on the above first connection information, Client server.

3. In the second paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the above reset process of the above RU being identified, a first session connection procedure is performed with the above RU using the first connection information, Further causing the client server to establish the second session with the RU based on the success of the first session connection procedure with the RU. Client server.

4. In the third paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the above reset process of the above RU not being identified, a second session connection procedure with the above RU is performed using the second connection information, Based on the failure of the second session connection procedure with the RU, the first session connection procedure with the RU is performed using the first connection information, Further causing the client server to establish the second session with the RU based on the success of the first session connection procedure. Client server.

5. In the first paragraph, the first connection information and the second connection information, At least one of information about the user account of the client server and the RU, information about the SSH (secure shell) port for call home, information about the SSH server port, information about the TLS (transport layer security) port for call home, or information about the TLS server port, Client server.

6. In the first paragraph, the message for performing the call home to the client server is, Based on the above second connection information, Client server.

7. In the sixth paragraph, when the instructions are individually or collectively executed by the at least one processor, Further causing the client server to establish the second session with the RU using the second connection information. Client server.

8. In the first paragraph, when the instructions are individually or collectively executed by the at least one processor, Further causing the client server to identify the reset process of the RU based on sending a message instructing the RU to perform the reset process. Client server.

9. In the first paragraph, the reset process of the RU, It is performed based on the anomaly of the above RU, The above reset process of the above RU performed based on the above RU ideal is, Not identified by the above client server, Client server.

10. In the first paragraph, the client server, Contains at least one of a DU (distributed unit) or SMO (service management and orchestration). Client server. In 11.RU(radio unit), Transmitter and receiver; At least one processor comprising processing circuitry; and comprising one or more storage media, and including a memory storing instructions; The above instructions, when individually or collectively executed by the at least one processor, Using the first connection information, which is the connection information of the above RU, a first session is established with the client server, While the above first session is established, second connection information is received from the client server, Based on receiving the second connection information, the connection information of the RU is changed from the first connection information to the second connection information, In response to identifying an anomaly of the RU after the connection information of the RU is changed from the first connection information to the second connection information, a reset process is performed, After the above reset process is performed, causing the RU to send a message to the client server to perform a call home for the client server configured based on the first connection information. RU.

12. In the 11th paragraph, the instructions, when individually or collectively executed by the at least one processor, further causing the RU to establish a second session with the client server based on sending the above message to the client server; RU.

13. In the 11th paragraph, the instructions, when individually or collectively executed by the at least one processor, Based on receiving the second connection information from the client server, the connection information of the RU is changed to the second connection information and stored, Based on performing the above reset process, further causing the RU to set the connection information of the RU to the first connection information. RU.

14. In a method performed by a client server, An operation of establishing a first session with RU using the first connection information, which is the connection information of the above client server; An action of changing the connection information of the client server from the first connection information to the second connection information while the first session is established; An operation of transmitting the second connection information to the RU so that the connection information of the RU is changed from the first connection information to the second connection information; An action of receiving a message from the RU for performing a call home for the client server based on transmitting the second connection information to the RU; In response to receiving said message, the operation of determining whether a reset process of said RU has been identified; and Including an operation of determining whether to use the second connection information to establish a second session with the RU, depending on whether the reset process of the RU is identified. method. In a method performed by 15.RU (radio unit), An operation of establishing a first session with the client server using the first connection information, which is the connection information of the above RU; An action of receiving second connection information from the client server while the first session is established; An operation of changing the connection information of the RU from the first connection information to the second connection information based on receiving the second connection information; An operation of performing a reset process in response to identifying an anomaly of the RU after the connection information of the RU is changed from the first connection information to the second connection information; and After the above reset process is performed, the method comprises the action of transmitting a message to the client server for performing a call home for the client server configured based on the first connection information. method.

Images