Method and apparatus for verifying performance of a communication node in a communication system

Abstract

According to one embodiment of the present invention, a method performed by a middle node includes receiving a configuration message from a north node, the configuration message including information regarding messages to be combined in a shared cell; receiving user plane messages from a plurality of south nodes included in the shared cell, respectively; identifying packets to combine from packets included in each of the received user plane messages based on the information regarding the messages to be combined in the shared cell; and counting the identified packets to combine to determine an uplink counter value for each of the plurality of south nodes.

Description

[Technical Field]

[0001] The present invention relates to a method and apparatus for verifying the performance of a communication node in a communication system. [Background technology]

[0002] As wireless communication systems develop and evolve into 4G communication systems, 5G communication systems, etc., various functions and specifications are required. Various methods have been introduced to meet these functions and specifications, one of which is a method of implementing a network infrastructure structure by functionally separating it. In a representative configuration of the functional separation method, a base station can be represented by a centralized unit (CU), a distributed unit (DU), and a radio unit (RU) depending on its function, and the interfaces of each unit are defined by organizations such as 3GPP and the O-RAN Alliance. Summary of the Invention [Problem to be solved by the invention]

[0003] One problem that the present invention aims to solve is ,one The object of the present invention is to confirm communication performance in the fronthaul in a method for configuring one or more shared cells.

[0004] Yet another problem to be solved by the present invention is to check the communication status while saving resources in the O-RAN in a method for configuring a shared cell. [Means for solving the problem]

[0005] According to one embodiment of the present invention, from the North Node: managementreceiving information about a first interval or a second interval for counter reporting via a plane message; and transmitting an uplink counter value and an uplink combined counter value for each of the plurality of south nodes to the north node for each of the first interval. knowledge and storing the uplink counter value and the uplink combined counter value for each of the plurality of south nodes in a file format in a memory or a storage server of the north node at each of the second intervals. Upload The method may further include the step of:

[0006] According to one embodiment, the information regarding the messages to be combined in the shared cell includes information regarding the transport flow and eAxC (extended antenna-carrier) ID (identifier) ​​of the messages to be combined among the uplink messages transmitted from the multiple south nodes, and the information regarding the transport flow may include a source MAC (media access control) or IP (Internet Protocol) address and a destination MAC or IP (MAC / IP) address of the messages to be combined.

[0007] According to one embodiment, identifying packets to be combined from packets included in each of the received user plane messages based on information on messages to be combined in the shared cell includes identifying the transmission flow and the eAxC ID of packets included in each of the user plane messages; transmitting the at least one first packet to the north node without combining if a destination MAC / IP address of at least one first packet among the packets included in each of the user plane messages is not the middle node MAC / IP address; dropping the at least one second packet among the packets included in each of the user plane messages if a destination MAC / IP address of at least one second packet among the packets included in each of the user plane messages is the middle node MAC / IP address and the eAxC ID is different from the eAxC ID included in the information on messages to be combined in the shared cell; If there is a match between the IDs, identifying the at least one third packet as the packet to be combined.

[0008] According to one embodiment, the method may further include determining that no packets are missing in user plane messages received from each of the plurality of south nodes if the values ​​of the uplink combining counters for each of the plurality of south nodes are all equal, or determining that an equal number of packets are missing in user plane messages received from each of the plurality of south nodes.

[0009] According to one embodiment, the method may further include determining that messages received from a first south node are persistently missing when a difference between an uplink counter value for a first south node among the plurality of south nodes and an uplink combined counter value for the first south node gradually increases.

[0010] According to one embodiment, the method may further include determining that if the values ​​of the uplink combining counters for each of the plurality of south nodes are different, some messages are missing or different numbers of messages are received at a particular time.

[0011] According to one embodiment, the middle node includes a fronthaul-multiplexer or a cascade radio unit, and the north node is a different node from the middle node. Another The south nodes may include a middle node, a distributed unit, a radio unit controller, or a service management and orchestration (SMO), and the south nodes may further include other middle nodes or radio units.

[0012] According to one embodiment, the method further includes receiving from the north node configuration information about an uplink counter and an uplink combined counter for each of the plurality of south nodes, wherein the configuration information about the uplink counter and the uplink combined counter may include information indicating a measurement interval for the counter, information indicating an entity for measuring the counter, and information about a notification interval or a file upload interval for reporting the counter value.

[0013] According to another embodiment of the present invention, a middle node in a communication system may include a transceiver, a memory, and at least one processor electrically coupled to the transceiver and the memory, wherein the at least one processor is configured to receive a configuration message from a north node, the configuration message including information regarding messages to be combined in a shared cell; receive user plane messages from a plurality of south nodes included in the shared cell, respectively; identify packets to be combined from packets included in each of the received user plane messages based on the information regarding the messages to be combined in the shared cell; and count the identified packets to be combined to determine an uplink counter value for each of the plurality of south nodes. [Effects of the Invention]

[0014] According to an embodiment of the present invention, a south node included in a shared cell with a middle node Transmission flow by If a problem occurs, you can identify the problem.

[0015] According to an embodiment of the present invention, the performance of copying or merging at a middle node can be checked based on a counter.

[0016] The effects of the technical idea of ​​the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. [Brief explanation of the drawings]

[0017] [Figure 1A] 1 illustrates a wireless communication system in accordance with various embodiments of the present invention. [Figure 1B] 1 illustrates an example of a fronthaul structure based on functional separation of a base station according to various embodiments of the present invention. [Figure 2] FIG. 1 is a diagram of an O-RAN network system according to one embodiment of the present invention. [Figure 3] FIG. 1 is a diagram illustrating the structure of an O-RAN wireless communication system according to an embodiment of the present invention. [Figure 4] FIG. 2 illustrates the structure of an Ethernet message according to one embodiment of the present invention. [Figure 5A] FIG. 10 illustrates an example of a C-plane message according to one embodiment of the present invention. [Figure 5B] FIG. 10 illustrates an example of a C-plane message according to one embodiment of the present invention. [Figure 6] FIG. 1 illustrates the structure of an O-RAN base station including a middle node according to an embodiment of the present invention. [Figure 7] FIG. 1 illustrates a system including a counter on the uplink in accordance with an exemplary embodiment of the present invention. [Figure 8] FIG. 10 illustrates a message flow for performing a join at a middle node according to one embodiment of the present invention. [Figure 9] FIG. 1 illustrates a system including a counter in the downlink according to one embodiment of the present invention. [Figure 10] FIG. 10 illustrates a message flow for copying at a middle node according to one embodiment of the present invention. [Figure 11] 1 is a flowchart illustrating a method for determining and reporting performance counters according to one embodiment of the present invention. [Figure 12] FIG. 1 illustrates a performance management portion of the Yang model according to an embodiment of the present invention. [Figure 13] 1 is a diagram illustrating a configuration of a north node according to an embodiment of the present invention. [Figure 14] 1 is a diagram illustrating the configuration of a middle node according to an embodiment of the present invention. [Figure 15] 1 is a diagram illustrating a configuration of a south node according to an embodiment of the present invention. [Figure 16] 1 is a flowchart illustrating a method for performance measurement and reporting according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0018] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0019] When describing embodiments of the present invention, if a detailed description of a related function or configuration is deemed to unnecessarily obscure the gist of the present invention, the detailed description will be omitted. Furthermore, the terms used below are defined in consideration of the functions of the present invention, and may vary depending on the intentions or practices of users or operators. Therefore, the definitions should be based on the overall content of this specification.

[0020] For the same reason, in the accompanying drawings, some components may be exaggerated, omitted, or shown in a schematic manner, and the size of each component may not directly reflect the actual size. In each drawing, the same or corresponding components are given the same reference numerals.

[0021] The advantages and features of the present invention, as well as methods for achieving them, will become apparent from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be embodied in various different forms. The embodiments are provided to fully explain the present invention and to fully convey the scope of the invention to those skilled in the art to which the embodiments of the present invention pertain, and the scope of the present invention is defined only by the scope of the claims.

[0022] It will be understood that each block of the process flowchart, and combinations of process flowcharts, can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that the instructions, when executed by the processor of the computer or other programmable data processing device, create means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in computer-usable or computer-readable memory that can direct the computer or other programmable data processing device to implement the functions in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory can produce an article of manufacture that embodies the instruction means for performing the functions described in the flowchart blocks. The computer program instructions may be embodied on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device to generate a computer-implemented process, and the instructions for the computer or other programmable data processing device may provide steps for performing the functions described in the flowchart blocks.

[0023] Also, each block represents a module, segment, or portion of code that includes one or more executable instructions for performing a specified logical function. Also, it should be noted that in some alternative implementations, the functions described in the blocks may occur out of order. For example, two blocks shown in succession may actually be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order according to their functions.

[0024] The term "unit" or "part" used herein refers to software or hardware components such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and a "unit" may be configured to perform a specific role. However, the term "unit" is not limited to software or hardware. A "unit" may be configured to reside on an addressable storage medium and to execute on one or more processors. Thus, by way of example, a "unit" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within a unit and a "unit" may be combined into fewer units and units or further separated into additional units and units. Furthermore, a unit and a "unit" may be embodied to implement one or more CPUs within a device or a secure multimedia card. Also, in the embodiments, a "unit" includes one or more processors and / or devices.

[0025] In some embodiments, the techniques described herein and systems and devices for implementing the same support communication between networks (or systems) using radio access technologies such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), LTE, GSM (registered trademark), 5G NR, as well as other radio access technologies such as WiFi or WiMax (registered trademark).

[0026] Various other embodiments and features according to the technical concepts of the present invention are further described below. It should be apparent that the teachings of the present application may be embodied in a wide variety of forms, and that any specific structure, function, or both disclosed herein are exemplary and not limiting. Based on the teachings of the present application, those skilled in the art will recognize that the aspects disclosed herein may be implemented independently of any other aspects, or that two or more of these aspects may be combined in various ways. For example, an apparatus may be embodied or a method may be practiced using any number of the aspects presented herein. Such an apparatus may be embodied or a method may be practiced using one or more of the aspects described herein together, or using the structure, functionality, or structure and functionality of other aspects. For example, a method may be embodied as a system, device, apparatus, and / or a piece of instructions stored on a computer-readable medium for execution by a processor or computer. An aspect may also include at least one element of a claim.

[0027] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the same components are denoted by the same reference numerals in the accompanying drawings, and detailed descriptions of known functions and configurations that may obscure the gist of the present invention will be omitted.

[0028] In describing the embodiments in this specification, technical details that are well known in the technical field to which the present invention pertains and are not directly related to the present invention will be omitted in order to more clearly convey the gist of the present invention without obscuring it.

[0029] Hereinafter, a base station is an entity that allocates resources to a terminal, and is at least one of a Node B, a Base Station (BS), an eNode B (eNB), a gNode B (gNB), a radio access unit, a base station controller, or a node on a network. A terminal includes a User Equipment (UE), a Mobile Station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions. Furthermore, embodiments of the present invention may be applied to other communication systems having similar technical backgrounds or channel configurations to the embodiments of the present invention described below. Furthermore, the embodiments of the present invention may be applied to other communication systems with some modifications within the scope of the present invention, as determined by those skilled in the art.

[0030] In the following description, terms for identifying an access node, terms for indicating a network entity or a network function (NF), terms for indicating a message, terms for indicating an interface between network objects, terms for indicating various identification information, etc. are provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms for indicating objects having equivalent technical meanings may be used.

[0031] For the sake of convenience, some of the terms and names defined in the 3GPP (3rd Generation Partnership Project Long Term Evolution), IETF (Internet Engineering Task Force) and IEEE 802 Project standards may be used below. However, the present invention is not limited to these terms and names and may be similarly applied to systems based on other standards.

[0032] Hereinafter, various embodiments according to the technical concept of the present invention will be described in detail.

[0033] The O-RAN Distributed Unit (O-DU) is a part of the O-RAN system that is generally implemented in software. More specifically, the O-DU is a logical node that hosts the RLC / MACI High-PHY layer based on the lower layer functional division. The O-RAN Radio Unit (O-RU) is a logical node that hosts the RF processing and Low-PHY layer based on the lower layer functional division. It can transmit and receive radio signals, which is the most important feature of the 3GPP "TRP" or "RRH."

[0034] User Equipment (UE) is a device, such as a mobile phone, that allows a user to access network services.

[0035] The uplink (UL) refers to the flow of traffic from the UE to the network and from the O-RU to the O-DU through different network elements. The interface from the UE to the O-RU is wireless, while the UL traffic from the O-RU to the O-DU can take various forms, such as wireless or wired (e.g., Ethernet connection).

[0036] The downlink (DL) refers to the flow of traffic through network elements from the O-DU to the O-RU and from the network to the UE. The fronthaul interface from the O-DU to the O-RU can take various forms, such as wired or wireless (e.g., Ethernet), while the interface from the O-RU to the UE is a wireless interface.

[0037] The O-RAN specification has four planes: the user plane (U-plane), the control plane (C-plane), the synchronization plane (S-plane), and the management plane (M-plane).

[0038] The user plane (U-plane) is a concept that includes the IQ sample data transmitted between the O-DU and the O-RU.

[0039] The control plane (C-plane) is a concept that particularly refers to scheduling information, beamforming information transmission, and other real-time controls between the O-DU and O-RU, and is distinct from the UE control plane.

[0040] The synchronization plane (S-plane) generally includes the configuration and exchange of information for time and frequency synchronization schemes, and may include other network elements in addition to the O-DU and O-RU.

[0041] The management plane (M-plane) is a concept that represents non-real-time management operations for the O-RU. Such non-real-time management operations are performed bidirectionally by the O-RU and the O-RU controller, which may reside in the O-DU or the service management and orchestration system (SMO) or exist as a separate device.

[0042] The M-plane interface is the link between the O-RU controller and the O-RU for sending and receiving non-real-time management information.

[0043] The section type is a delimiter in the C-plane message format and consists of different data fields depending on the purpose, such as the scheduling format, the beamforming information configuration format, the ACK / NACK indication response, and the LAA information exchange.

[0044] Section extension data is optional additional information attached to the end of section data in C-plane messages that mainly flow from O-DU to O-RU. It can convey additional real-time control information to support purposes or achieve optimization that cannot be achieved in general configuration formats.

[0045] A shared cell refers to a scheme in which multiple O-RUs operate within the same cell with one or more component carriers.

[0046] Depending on the number of network elements of O-DU and O-RU and the link (or data flow), it can be classified as shown in Table 1 below.

[0047] [Table 1] Classification of cell types according to the number and configuration of DUs and RUs [Table 1]

[0048] Starting from the premise of an acceptable configuration without additional implementation or major changes of the UE, the UE basically recognizes existing cells without distinguishing between shared and non-shared cells. Therefore, the cell identity is maintained as a single cell regardless of the cell type. When a cell is composed of multiple O-RUs, there is an advantage that interference between radio signals can be minimized in broadcasting channels such as System Information Block (SIB) 1 and control channels such as group common PDCCH, which are provided as a single layer within the cell, thereby providing an excellent radio environment.

[0049] However, in a shared cell, some signals, such as a synchronization signal (SS) / physical broadcast channel (PBCH) and a channel state information-reference signal (CSI-RS), can be assigned to individual or groups of O-RUs to support positioning and selective operation. Therefore, individual O-RUs in a shared cell are not always intended to operate in the same way.

[0050] From the perspective of the O-DU, cell type 2A (shared cell) has essentially the same operating principle as cell type 1. However, due to the configuration of multiple O-RUs, there are differences in the expected cell performance and cell configuration requirements. From the perspective of radio signal quality, there is an increase in noise power in the uplink signal (UL signal) in proportion to the number of O-RUs. From the perspective of message handling, to process all network entities as a single message like cell type 1, the link intermediate process between the O-DU and O-RU requires the function of copying downlink directional messages and combining uplink directional messages. Here, combining is a concept that includes expressions such as sum, aggregate, and add. In O-RAN, the network node responsible for this function is defined as a fronthaul multiplexer (FHM) or cascade O-RU.

[0051] In the FHM mode, a shared cell can be configured such that an FHM function is located between at least one O-DU and multiple O-RUs. The FHM function performs copy and combining functions and supports LLS fronthaul like a general O-RU. Here, combining includes expressions such as combine, sum, aggregate, and add. Multiple O-RUs connected to the FHM can all share one cell or can be designed to be divided into multiple cells and shared by groups.

[0052] An example of cascade mode is an O-RU directly connected to an O-DU. (Including FHM) is one, and this O-RU has other O-RUs. (Including FHM) may be configured to be connected to each other in a serial connection form.

[0053] 1A illustrates a wireless communication system according to various embodiments of the present invention. Fig. 1A illustrates some of the nodes that use wireless channels in the wireless communication system, including a base station 110, a first terminal 120, and a second terminal 130. Although Fig. 1A illustrates only one base station, one or more other base stations identical to or similar to base station 110 may also be included.

[0054] The base station 110 is a network infrastructure that provides wireless connectivity to the terminals 120 and 130. The base station 110 has coverage, which is defined as a certain geographical area based on the distance over which signals can be transmitted. The base station 110 may also be called an "access point (AP)," "eNode B (eNB)," "5G node (5th generation node)," "gNB (next generation Node B, gNB)," "wireless point," "transmission / reception point (TRP)," or other terms with equivalent technical meanings, in addition to a base station.

[0055] Each of the terminals 120 and 130 is a device used by a user and communicates with the base station 110 via a wireless channel. A link from the base station 110 to the first terminal 120 or the second terminal 130 is called a downlink (DL), and a link from the first terminal 120 or the second terminal 130 to the base station 110 is called an uplink (UL). The first terminal 120 and the second terminal 130 can communicate with each other via a wireless channel. In some cases, at least one of the first terminal 120 and the second terminal 130 may be operated without the involvement of the user. That is, at least one of the first terminal 120 and the second terminal 130 is a device that performs machine type communication (MTC) and does not need to be carried by the user. Each of the first terminal 120 and the second terminal 130 may be referred to as "user equipment (UE)," "customer premises equipment (CPE)," "mobile station," "subscriber station," "remote terminal," "wireless terminal," "electronic device," "user device," or other terms having equivalent technical meanings.

[0056] In conventional communication systems with relatively large base station cell radii, each base station was installed to include a digital processing unit (DU) and a radio frequency (RF) processing unit (RU). However, as higher frequency bands are used in 4th generation (4G) and / or later communication systems and base station cell radii become smaller, the number of base stations required to cover a specific area increases, increasing the installation costs for operators to install the increased number of base stations. To minimize base station installation costs, a structure has been proposed in which the DU and RU of a base station are separated, one or more RUs are connected to one DU via a wired network, and one or more RUs are distributed geographically to cover a specific area.

[0057] 1B shows an example of a fronthaul structure based on functional separation of a base station according to various embodiments of the present invention. The fronthaul refers to an entity between a wireless LAN and a base station, unlike a backhaul between a base station and a core network.

[0058] 1B, the base station 110 includes a DU 160 and an RU 180. A fronthaul 170 between the DU 160 and the RU 180 is operated via an Fx interface. For operation of the fronthaul 170, an interface such as an enhanced common public radio interface (eCPRI) or radio over Ethernet (ROE) may be used.

[0059] As communication technology advances, mobile data traffic increases, which significantly increases the bandwidth requirements for the fronthaul between the DU and RU. In deployments such as C-RAN (centralized / cloud radio access network), the DU 、RThe RU performs radio link control (LC), media access control (MAC), and physical (PHY) functions, and the RU is configured to perform functions related to the PHY layer in addition to the radio frequency (RF) function.

[0060] DU 160 is a wireless access The DU 160 is responsible for higher layer functions of the network. For example, the DU 160 can perform functions of the MAC layer and part of the PHY layer. Here, the part of the PHY layer refers to functions of the PHY layer that are performed at a higher level, and examples include channel coding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). According to an embodiment, if the DU 160 complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU). The DU 160 may be substituted for and expressed as a first network entity for a base station (e.g., a gNB) in embodiments of the present invention, as needed.

[0061] The RU 180 is responsible for lower layer functions of the radio network. For example, the RU 180 can perform part of the PHY layer and RF functions. Here, part of the PHY layer refers to functions of the PHY layer that are performed at a relatively lower level than the DU 160, including, for example, IFFT (or FFT) transformation, CP insertion (CP removal), and digital beamforming. A specific example of such functional separation is described in detail in FIG. 4. The RU 180 may also be referred to as an "access unit (AU)," "access point (AP)," "transmission / reception point (TRP)," "remote radio head (RRH)," "radio unit (RU)," or other terms having equivalent technical meanings. In one embodiment, if the DU 180 complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU). The RU 180 may be replaced with a second network entity (e.g., another FHM) for a base station (e.g., gNB) in embodiments of the present invention, as needed.

[0062] In fronthaul communication between the DU 160 and the RU 180, the RU 180 must continuously perform radio transmission and reception as specified in the 3GPP TS within error limits (e.g., frequency time error, time alignment error, etc.) defined for time and frequency resources. To this end, timing and latency must be managed for each network element in the network infrastructure. In particular, strict timing control and high accuracy are required for the DU and RU that process physical layer signal processing. Functional split option 7 performs signal processing based on each symbol, so IQ data corresponding to each symbol and its processing information must be transmitted between the DU 160 and the RU 180 within a certain latency. The message arrival time is determined by the transmission time and delay time and is expressed by the following equation:

[0063] Sending time (window) + delay time ≦ Arrival time (window)

[0064] Transmit window+transport delay≦receive window

[0065] Typically, there is a DU fixed timing processing method that ensures sufficient margin for transmission delay based on the timing of the RU 180, and a DU dynamic timing processing method that takes advantage of the time secured by varying the message transmission and reception time for fronthaul transmission delay. This is determined by the DU 160 as it depends on the message timing management capability of the DU 160. Since it is generally advantageous for the RU 180 to process messages in the shortest time possible using optimal resources, the RU 180 provides a delay profile according to certain criteria. These criteria include subcarrier spacing, bandwidth, fronthaul line rate, buffer depth, and transport flow. Because there are so many parameters between the DU 160 and RU 180 for message delay management, optimization based on vendor consultations according to use cases is generally expected rather than a convergence process based on general requirements and relationships. Even if the DU 160 dynamic timing processing method is used, this means dynamic changes depending on the use case and deployment, but does not mean dynamic changes to delays that change dynamically in already configured cells. Of course, the method can be extended to support semi-static with degradation of service, but there is currently no significant advantage.

[0066] O-RAN message timing is managed so that DU 160 and RU 180 can smoothly send and receive messages in relation to the transport delay. The uplink combining function of U-plane messages for FHM and Cascade O-RU is as follows: For each symbol It operates based on ta3-prime-max, which is based on the current reference timing t(ul)=0. Ta3-prime-max is D U's Ta4-max and To DUIt is determined taking into account the fronthaul transmission delay (FH transport delay).

[0067] Figure 2 is a diagram of an O-RAN network system according to an embodiment of the present invention. According to Figure 2, the O-RAN network is a network in which the functions of eNB and gNB in ​​existing 4G and 5G systems are logically separated. O-RAN-related standards define a non-real-time (NRT)-RIC (RAN intelligent controller) 210, a RIC 220 in an O-RAN base station 200, an O-CU-CP 230, an O-CU-UP 240, an O-DU 250, and an O-RU 260. The NRT-RIC 210 is a logical node that enables non-real-time control and optimization of RAN elements and resources, model training and updates, etc. The RIC 220 is a logical node that has a centralized server located in one physical location and enables near-real-time control and optimization of RAN elements and resources based on data collected from the O-DU 250, the O-CU-CP 230, the O-CU-UP 240, etc. via an E2 interface. The O-CU, including the O-CU-CP 230 and O-CU-UP 240, is a logical node that provides the functions of the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocols. The O-CU-CP 230 is a logical node that provides the C-plane functions of RRC and PDCP, and the O-CU-UP 240 is a logical node that provides the U-plane functions of SDAP and PDCP. The O-CU-CP 230 is connected to the access and mobility management function (AMF) included in the 5G network (5G core) via the NGAP interface. The O-DU 250 is a logical node that provides RLC, MAC, and high-PHY functions. The O-RU 260 connected to the O-DU 250 is a logical node that provides low-PHY functions and RF processing.In FIG. 2, each logical node is shown singular, but each logical node may be connected in multiple numbers. For example, one O-DU 250 may be connected to multiple O-RUs 260, and one O-CU-UP 240 may be connected to multiple O-DUs 250.

[0068] The present invention is not limited by the names of the nodes described above, and the configuration of the present invention can be applied to logical nodes or entities that perform the functions described above. Furthermore, the logical nodes may be located in the same physical location or in other locations, and their functions may be provided by the same physical device (e.g., a processor, a controller, etc.) or by other physical devices. For example, the functions of at least one of the logical nodes described above may be provided by virtualization in one physical device. Hereinafter, O-DU and O-RU may be referred to interchangeably as DU and RU, respectively.

[0069] 3 is a diagram showing the structure of an O-RAN wireless communication system according to an embodiment of the present invention. The wireless communication system includes a base station 305 and at least one UE 330a, 330b, ..., 330f. The base station includes a CU 310, at least one DU 315a and 315b, an FHM 320, and at least one RU 325a, 325b, ..., 325f. Here, the CU, DU, FHM, and RU are all included within a base station or exist as entities with separate functions.

[0070] In one embodiment, the wireless communication system is a radio access network (RAN), such as an open-RAN. Generally, a RAN includes a network including base stations and a connection between UEs. An O-RAN includes all functions and components within a RAN and can interoperate with other functions or components. Like a traditional RAN structure, an O-RAN also includes a CU / DU. and / or low rise A split architecture can be used. The RU generally provides the functionality to transmit, receive, amplify, and digitize radio frequency signals. In one embodiment, the RU includes an antenna orThe CU 310 is located near the DU. The CU is located closer to the core network. The FHM acts as an interface between the RU and the DU and can multiplex or demultiplex information received from the RU before providing the information to the DU. The CU 310, DU, FHM, and RU may be referred to as the O-CU, O-DU, O-FHM, and O-RU, respectively.

[0071] In O-RAN architecture, the shared cell structure includes an RU that combines incoming I / Q samples before transmitting them from the RU to the DU. In O-RAN architectures that utilize CU / DU splitting, the structure can be defined in two modes:

[0072] The first mode is the FHM mode, in which the FHM 320 can retrieve compressed information along with I / Q samples from all O-RUs 325a, 325b, and 325c connected to it via signaling. O- An RU associates with or communicates wirelessly with one or more UEs.

[0073] The second mode is defined as the cascade mode (or cascade O-RU mode). Cascade O-RUs 325d and 325e can retrieve the compressed information along with the I / Q samples by messaging with the Southbound node O-RU (e.g., the trailing O-RU, downstream O-RU). The upstream O-RU can O- Combining can be performed to deliver I / Q samples to either the RU or the DU.

[0074] 4 illustrates the structure of an Ethernet message according to an embodiment of the present invention. The destination MAC (medium access control) address 400 in the header of the Ethernet message indicates the public address of the RU in the DL case, and indicates the public address of a specific port of the DU's channel card in the UL case (which performs the MAC layer operations responsible for scheduling, the high-PHY operations, and the operation of converting data formats via the interface between the RU and DU). The source MAC address 410 indicates the RU in the UL case, and indicates the public address of a specific port of the DU's channel card in the DL case.

[0075] The VLAN (virtual LAN) tag 420 has a size of 4 bytes and enables C-plane, U-plane, or S-plane messages to be mapped and managed to different VLAN tags. The tag protocol identifier (TPID) included in the VLAN tag 420 is set to 16 bits and can be set to 0x8100 to identify the frame as an IEEE 802.1Q tagged frame. This field is located in the same position as the Ethertype / Length field in untagged frames and can be used to distinguish untagged frames from general frames. Similarly, the tag control information (TCI) included in the VLAN tag is set to 16 bits and includes the following three fields: The priority code point (PCP) is 3 bits and represents the frame priority. The drop eligible indicator (DEI) is set to 1 bit and can be used separately or in combination with the PCP to distinguish frames that should be dropped when traffic is congested. The VLAN identifier (VID) is set to 12 bits and is a field that indicates which VLAN the frame belongs to. All values ​​except the reserved values ​​0x000 and 0xFFF are used as VLAN identifiers, allowing up to 4,094 VLANs. The reserved value 0x000 indicates that the frame does not belong to any VLAN; in this case, 802.1Q specifies only the priority, which can be referred to as the priority tag. The Type / Length (Ethertype) is set to a fixed value of 0xAEFE for CPRI.

[0076] Payload 440 may include a message in each plain format including an eCPRI header, as shown in Fig. 4. Not all fields or information contents of the Ethernet message described with reference to Fig. 4 necessarily need to be included, and the present invention may be implemented by omitting or / and adding other fields as needed.

[0077] 5A and 5B are diagrams illustrating an example of a C-plane message according to an embodiment of the present invention, where FIG. 5A illustrates a C-plane structure for section type 1, and FIG. 5B illustrates a C-plane structure for section type 3.

[0078] First, to explain each field in Figure 5A, the transport header 501 contains information according to the eCPRI header shown in Figure 4 or IEEE-1914.3. The dataDirection 502 indicates the direction of the U-Plane message, with 0 indicating UL and 1 indicating DL. The filterIndex 504 indicates the channel filter of the RU and is set to 0x1. The frameId 506 indicates a specific frame in 10 ms units. The subframeId 508 indicates a specific subframe within the frame in 1 ms units. The slotId 510 indicates a specific slot within the frame.

[0079] The numberOfsections 514 indicates the number of sections indicated by the message. The SectionType 516 indicates only one section type for a C-plane message. In this example, it indicates section type 1. The udCompHdr 518 indicates the IQ bit width and compression method for the IQ data of all sections of the message. Specifically, the upper 4 bits are iqWidth, which indicates 1 to 16 bits, and the lower 4 bits are compMeth, which indicates the compression method. The above-mentioned 502 to 518 are application headers 540 that can be commonly applied to the message and can be included in all C-plane messages with a similar structure.

[0080] A C-plane message of section type 1 includes information about a given section. SectionID 522 indicates the section ID, which can be used to match the C-plane message with the U-plane mesh. rb 524 indicates which PRB is used, with 0 indicating all PRBs are used and 1 indicating every other PRB is used. StartPrbc 526 is used to indicate the first PRB of the section, and numPrbc 528 indicates the number of PRBs in the section. reMask 530 is a bit pattern that indicates the RE (or subcarrier) corresponding to a specific beam in the PRB, and different beams can be applied within one PRB through reMask. numSymbol 532 indicates the number of symbols corresponding to the section. The above fields are referred to as a section header 542 for each section.

[0081] The C-plane message also includes a section extension, and whether or not the section extension is included is indicated by ef 520. The contents of each field or information described with reference to Fig. 5A do not necessarily include all fields, and the present invention can be carried out by omitting or / and adding other fields as necessary.

[0082] Referring to Figure 5B, the fields from the transport header to the section type are the same as those in Figure 5A, but there are differences in the following fields. Timeoffset 550, framestructure 552, cpLength 554, and udCompHdr 556 are fields that can be identified in the C-plane of section type 3. Timeoffset 550 defines the time offset from the start of the slot to the start of the cyclic prefix (CP). Framestructure 552 defines the frame structure, with the first four bits defining the size of the FFT / iFFT used to process all IQ data related to the C-plane message, and the remaining four bits defining the subcarrier spacing (SPS), the number of slots per 1 ms subframe. cpLength 554 indicates the length of the cyclic prefix. udCompHdr 556 defines the compression method and IQ (in-phase, quadrature) bit width for the user data in the data section. Most of the other fields are similar to those in Figure 5A, so their description will be omitted.

[0083] FIG. 6 is a diagram illustrating the structure of an O-RAN base station including a middle node according to an embodiment of the present invention.

[0084] Referring to FIG. 6, an O-RAN base station (or network) 600 includes at least one O-DU 610a and 610b, middle nodes 620a and 620b, at least one O-RU 630a, 630b, . . . , 640f, and a controller 650.

[0085] Here, at least one of O-DUs 610a and 610b is also referred to as a northbound node with first middle node 620a at the center, and middle nodes 620a and 620b may be used in combination with FHM 620a, Cascade FHM (not shown), or Cascade O-RU 620b, and at least one of O-RUs 630a, 630b, ..., 640f may be used in combination with a southbound node with first middle node 620a at the center. The controller 650 may be included in the O-DUs 610a and 610b, or may exist as a separate device.

[0086] 6, a controller 650 can directly communicate with at least one O-DU 610a and 610b, middle nodes 620a and 620b, and at least one O-RU 630a, 630b, ..., 640f. The controller 650 communicates M-plane messages with at least one O-DU 610a and 610b. The controller 650 communicates M-plane messages with middle nodes 620a and 620b. At least one O-DU 610a and 610b communicates C / U-Plane messages with the middle node 620a. At least one O-DU 610a and 610b communicates C / U-Plane messages directly with at least one O-RU 630a, 630b, ..., 640f. The middle node 620a can communicate with at least one O-RU included in at least one cell (cell #0 and cell #1) 630a and 630b. The first middle node 620a transmits M-plane and C / U-plane messages received from at least one O-DU 610a and 610b or the controller 650 to at least one O-RU 630a, 630b, ..., 640f. In this case, the first middle node 620a can copy and transmit the same message to each O-RU included in the same cell. For example, the same message is copied by the first middle node 620a and transmitted to O-RU #1 630a and O-RU #2 630b included in cell #0 630a. Also, different messages are transmitted from the first middle node 620a to cell #0 630a and cell #1 630b. According to one embodiment, a second middle node 620b may be included within cell 630b. In this case, the second middle node 620b may include an O-RU located southbound from the second middle node 620b and may copy and transmit messages received from the upper level to the O-RU. For example, cell #1 630b includes a second middle node 620b, which copies and transmits data received from the first middle node 620a to O-RU #5 640e and O-RU #6 640f located southbound.

[0087] Referring to FIG. 6, at least one O-RU 630a, 630b, ..., 640f may transmit a U-plane message to a first middle node 620a based on data received from a terminal. The first middle node 620a combines messages received from at least one O-RU 630a, 630b, ..., 640f. Here, "combine" includes expressions such as "combine," "sum," "aggregate," and "add." The first middle node 620a may combine messages received from at least one O-RU 630a, 630b, ..., 640f and transmit the combined messages to at least one O-DU 610a and 610b. In this case, the first middle node 620a may perform combining on data received from O-DUs included in the same cell. According to an embodiment, a middle node 620b may be included within a cell 630b. In this case, the second middle node 620b includes an O-RU located south of the second middle node 620 and can combine messages received from the O-RUs and transmit them to the upper level. For example, in cell #1 630b, the second middle node 620b combines data received from O-RU #5 640e and O-RU #6 640f located in the lower level using a cascade structure, and transmits the combined data to the first middle node 620a located in the upper level. Here, the combination includes expressions such as combine, sum, aggregate, and add. The first middle node 620a combines the data received from the second middle node 620b with the data received from O-RU #3 640c and O-RU #4 640d included in cell #1 630b, and transmits the combined data to the O-DUs 610a and 620b.

[0088] In the present invention, the north node is a concept that includes the DU, O-DU, O-RU controller, SMO (service management and orchestration), and other middle nodes (e.g., FHM or cascade RU connected to FHM or cascade RU), and may be a single entity that logically or physically includes all functions, or an entity that is separated into each function. The south node is a concept that includes the RU, O-RU, and other middle nodes (e.g., FHM or cascade RU connected to FHM or cascade RU), and may be a single entity that logically or physically includes all functions, or an entity that is separated into each function.

[0089] In the technical field of O-RAN, there was a problem that some messages were missing during actual message transmission. This was due to the delay in transmission at the transmitting entity and the large transmission delay caused by the long optical fiber distance, and timing-related settings were not configured properly. by mistake If yes, user plane message Transmission flow If the Rx-window is configured incorrectly, it can cause network congestion, which is a bottleneck. Therefore, a method has been proposed to identify such issues by defining a receive window (Rx-window) and using a corresponding counter. However, the receive window counter has the problem that it is not suitable for FHM in shared cells because it is based on radio delay parameters. Since FHM does not have radio and delay parameters for copying or combining are undefined or insufficient, calculations for various ports become complicated. In particular, shared cells may include various extended topologies such as multiple O-DUs, multiple entities, and cascaded FHM, which can further increase the complexity. Therefore, to solve these issues, we propose a counter that can identify performance that can be utilized in middle nodes.

[0090] FIG. 7 illustrates a system including a counter on the uplink in accordance with an exemplary embodiment of the present invention.

[0091] The north node (north node or northbound node) 710 in Figure 7 may be the same as or similar to the controller 650, the DUs 315a and 315b, or the O-DUs 610a and 610b in Figures 1A to 6. The middle node (FHM / Cascade O-RU) 720 may be the same as or similar to the FHM 320, the RUs 325d and 325e, or the middle nodes 620a and 620b in Figures 1A to 6. The south nodes (southbound nodes) 730a and 730n may be the same as or similar to the RUs 325a, 325b, 325c, 325d, 325e, and 325f or the O-RUs 640a, 640b, ..., and 640f in Figures 1A to 6.

[0092] The middle node 720 in FIG. or Cascade FHM 7 illustrates the process by which middle node 720 receives uplink messages from south nodes 730a and 730n, combines the uplink packets, and transmits the combined message to north node 710 in an uplink situation.

[0093] Referring to Figure 7, the first south node 730a transmits an uplink message to the middle node 720. Here, the uplink message includes an uplink control plane message or a user plane message. The nth south node 730n also transmits an uplink message to the middle node 720. When the middle node 720 receives an uplink message from the south nodes 730a and 730n, it can identify the source media access control (MAC) or Internet protocol (IP) (hereinafter referred to as MAC / IP) address, destination MAC / IP address, and extended antenna-carrier (eAxC) ID (identifier) ​​from the packet included in the received message. Here, sauce A MAC / IP address and a destination MAC / IP address can be referred to as a transport flow.

[0094] The middle node 720 identifies packets whose destination MAC / IP address is the middle node 720 from the received packets. Here, packets whose destination MAC / IP address is not the middle node 720 are transmitted to the north node 710 without undergoing a combining process in the middle node 720.

[0095] The middle node 720 determines whether the eAxC ID of a packet whose destination MAC / IP address is the middle node 720 is the same as the eAxC ID included in the predetermined information. Here, the predetermined information is included in the M-plane message received from the north node 710. The north node 710 transmits an M-plane message including predetermined information for specifying packets to be combined to the middle node 720. For example, the predetermined information may be expressed as "shared-cell-combine-entities" in the M-plane message. The "shared-cell-combine-entities" includes the source MAC / IP address, destination MAC / IP address, and eAxC ID of the packets to be combined. The middle node 720 checks for packets whose destination MAC / IP address is the middle node 720 and whose eAxC ID is the same as the predetermined information, and stores the packets in memories 725a and 725b. The middle node 720 drops packets whose destination MAC / IP address is the middle node 720 and whose eAxC ID is different from the predetermined information.

[0096] The middle node 720 determines and counts the number of packets whose destination MAC / IP address is the middle node 720 and whose eAxC ID is the same as the predetermined information. At this time, the values ​​of the uplink counters 740a and 740n can be determined based on the count. For example, the uplink counters 740a and 740n are identified as "RX_UP_UL" counters. In one embodiment, the value of the uplink counter is determined per transmission flow (e.g., south node MAC / IP address). The uplink counter indicates the number of user plane packets received in the uplink data direction corresponding to the processing elements and eAxC ID configured in the shared cell. For example, if the number of packets whose destination MAC / IP address is the middle node 720 and whose eAxC ID is the same as the predetermined information is five in an uplink message received from the first south node 730a, the middle node 720 determines the first uplink counter 740a to be five. The middle node 720 sets the nth uplink counter 740n to 3 when the number of packets whose destination MAC / IP address is the same as the middle node 720 and whose eAxC ID is the same as the predetermined information is three among the packets in the uplink message received from the nth south node 730n. The middle node 720 sets the nth uplink counter 740n to 3. The middle node 720 sets the uplink counter and stores the received packets that are not dropped in the memories 725a and 725b. For example, the middle node 720 sets the uplink counter for the message received from the first south node 730a and stores the received packets that are not dropped in the first memory 725a. The middle node 720 sets the uplink counter for the message received from the nth south node 730n and stores the received packets that are not dropped in the second memory 725b. Here, the first memory 725a and the second memory 725b may be a single memory or may exist as separate memories.

[0097] The middle node 720 checks the packet timing when storing a packet in memory (step 735a). The middle node 720 determines a predetermined timing to check the arrival time of the packet. The middle node 720 drops a packet if it arrives too early or too late. In one embodiment, the middle node 720 stores all received packets in memory and drops packets that arrive too early or too late from the memory according to a predetermined period.

[0098] The middle node 720 retrieves packets to be combined into the combining timing from the memory to the combiner 760. For example, the middle node 720 retrieves packets corresponding to symbols to be combined into the combining timing from the packets stored in the first memory 725a. The middle node 720 may determine an uplink combining counter by counting the number of packets for the symbols retrieved at the T-waiting timing from the retrieved packets. Here, the uplink combining counter may be identified as an "RX_UP_UL_COMBINED" counter. In one embodiment, the value of the uplink combining counter is determined per transmission flow (e.g., south node MAC / IP address). Alternatively, the value may be determined in finer units, such as per eAxC-ID. The uplink combining counter indicates the "RX_UP_UL" user plane message that is processed by a combining function to generate a combined message for the processing elements configured in the shared cell and the north node corresponding to the eAxC ID. The uplink combining counter indicates the number of uplink user plane messages delivered to the combiner to generate a combined message to be transmitted to the north node. For example, the middle node 720 may retrieve packets for combining with symbol #0 from packets stored in the first memory 725a among packets received from the first south node 730a. If the number of packets is three, the middle node 720 sets the first uplink combining counter 750a to 3. For example, the middle node 720 may retrieve packets for combining with symbol #0 from packets stored in the second memory 725b among packets received from the nth south node 730n. If the number of packets is two, the middle node 720 sets the nth uplink combining counter 750n to 2. In one embodiment, if the value of the uplink counter 740a and the value of the uplink combining counter 750a are equal, it is interpreted that all uplink user plane messages have been combined. However, the value of the uplink counter 740a and the value of the uplink combining counter 750a may differ depending on the calculation timing.Such a difference occurs due to the time from storage to processing and the difference in the reference timing for measuring each packet counter. Interval Reference Timing (e.g. T-waiting timing) Set the counters to synchronize and consider the timing offset It is possible.

[0099] The middle node 720 retrieves packets received from the first south node 730a and the nth south node 730n that have the same symbols as the packets to be combined, and combines them in a combiner 760. After combining, the middle node 720 transmits a message including the combined packets to the north node 710.

[0100] According to one embodiment, the north node or middle node can determine that messages of a particular transmission flow for uplink combining are persistently missing (or received but not processed by the combiner) because the size difference between the nth uplink counter 740n and the nth uplink combining counter 750n gradually increases.

[0101] According to one embodiment, the north node or middle node may determine whether some messages for uplink combining are missing when all south nodes 730a and 730n transmit the same number of user plane messages per control plane message.

[0102] According to one embodiment, a north node or middle node may interpret or determine that if the first uplink combined counter 750a through the nth uplink combined counter 750n are all equal, this indicates that no messages are missing from all transmission flows, or that the same number of messages are missing from all of them.

[0103] According to one embodiment, a north node or middle node can determine that if the uplink combining counters are different, some messages are missing at a particular time and other messages arrive on time and are combined.

[0104] According to one embodiment, if the first uplink combining counter 750a and the nth uplink combining counter 750n are equal, the same number of packets may be combined. In this case, the north node or middle node determines that if combining is successful on one port, combining is also successful on all other ports. However, the number of user plane packets may differ. For example, this may be due to the operation of a selective beam-id function or different vendors' user plane responses to the same control plane packet.

[0105] FIG. 8 is a diagram illustrating message flow for performing a join at a middle node according to one embodiment of the present invention.

[0106] The north node (not shown) in Figure 8 may be the same as or similar to the controller 650, the DUs 315a and 315b, the O-DUs 610a and 610b, or the north node 710 in Figures 1A to 7. The middle node (FHM / Cascade O-RU) 800 may be the same as or similar to the FHM 320, the RUs 325d and 325e, the middle nodes 620a and 620b, or the middle node 720 in Figures 1A to 7. The south node (not shown) may be the same as or similar to the RUs 325a, 325b, 325c, 325d, 325e, and 325f, the O-RUs 640a, 640b, ..., 640f, or the south nodes 730a and 730n in Figures 1A to 7.

[0107] FIG. 8 may illustrate an example of message and packet flow in a system including a counter on the uplink as described in FIG.

[0108] 8, a middle node 800 receives uplink user plane messages from multiple south nodes (not shown). First, the middle node 800 receives a first uplink user plane message (hereinafter, a first uplink message) 805a from a first south node at a first port 810. For example, the first uplink message 805a includes six packets, 91, 92, 93, 94, 01, and 02.

[0109] The middle node 800 previously receives information 825 indicating packets to be combined in a shared cell from a north node (not shown) via a management plane message. The information indicating packets to be combined in a shared cell includes the transmission flow and eAxC ID of the packets to be combined. For example, the information indicating packets to be combined in a shared cell is identified as "shared-cell-combine-entities." Here, the transmission flow includes a source MAC / IP address and a destination MAC / IP address. The middle node 800 identifies the transmission flow and eAxC ID in the received first uplink message 805a.

[0110] The middle node 800 determines whether the destination MAC / IP address of a packet included in the received first uplink message 805a is the middle node 800 based on information 825 indicating packets to be combined in the shared cell. The middle node 800 transmits a packet 817 whose destination MAC / IP address is not the middle node 800 to the north node without storing it separately. For example, packet 94 of the first port 810 corresponds to a packet 817 whose destination MAC / IP address is not the middle node 800.

[0111] When the middle node 800 determines a packet whose destination MAC / IP address is the middle node 800, it checks whether the eAxC ID of the packet whose destination MAC / IP address is the middle node 800 corresponds to a predetermined eAxC ID in the information indicating packets to be combined in the shared cell. If the eAxC ID of the packet does not correspond to the predetermined eAxC ID, the middle node 800 drops the packet. If the eAxC ID of the packet whose destination MAC / IP address is the middle node 800 corresponds to the predetermined eAxC ID, the middle node 800 counts the number of packets and determines an uplink counter value. Here, the uplink counter may be identified as an "RX_UP_UL" counter. For example, the uplink counter value in the first uplink message 805a is determined to be 5 815a, based on a total of five packets, 91, 92, 93, 01, and 02.

[0112] If the eAxC ID of a packet whose destination MAC / IP address is the middle node 800 corresponds to a predetermined eAxC ID, the middle node 800 stores the packet in memory 830. For example, the first port 810 stores packets 91, 92, 93, 01, and 02 in memory 830.

[0113] Additionally, the middle node 800 receives a second uplink user plane message (hereinafter, the second uplink message) 805b from the second south node at a second port 820. For example, the second uplink message 805b includes a total of five packets, 91, 92, 93, 01, and 02. However, in FIG. 8, it may be the case that only two packets, 91 and 92, are received by the middle node 800 within the T-waiting timing, and packets 93, 01, and 02 are not received by the middle node 800 within the timing.

[0114] The middle node 800 previously receives information 825 indicating packets to be combined in a shared cell from a north node (not shown) via a management plane message. The middle node 800 identifies the transmission flow and eAxC ID in the received second uplink message 805b. For packets included in the received second uplink message 805b, the middle node 800 determines whether the destination MAC / IP address is the middle node 800 based on information 825 indicating packets to be combined in a shared cell. The middle node 800 transmits packets whose destination MAC / IP address is not the middle node 800 to the north node without separately storing them. For example, there are no packets currently being transmitted to the north node at the second port 820.

[0115] If the eAxC ID of a packet whose destination MAC / IP address is the middle node 800 corresponds to a predetermined eAxC ID, the middle node 800 counts the number of packets and determines the uplink counter value. For example, the uplink counter for the second uplink message 805b is determined to be 2 815b, based on the total of two packets 91 and 92.

[0116] If the eAxC ID of a packet whose destination MAC address is the middle node 800 corresponds to a predetermined eAxC ID, the middle node 800 stores the packet in memory 830. For example, the second port 820 stores packets 91 and 92 in memory 830.

[0117] The middle node 800 retrieves packets 832 and 834 to be combined from memory 830 in accordance with the combining timing for each symbol, and sends them to combiner 840. For example, to combine into symbol #9, the middle node 800 retrieves packets 832 (91, 92, 93) received and stored from the first uplink message 805a, and retrieves packets 834 (91, 92) received and stored from the second uplink message 805b, and sends them to combiner 840.

[0118] The middle node 800 counts packets retrieved for combining by symbol and determines uplink combining counters 835a and 835b. Here, the uplink combining counter may be identified as "RX_UP_UL_COMBINED." For example, since the middle node 800 retrieves a total of three packets, 91, 92, and 93, received and stored from the first uplink message 805a, the first uplink combining counter 835a is set to 3 at the T-waiting timing. Also, since the middle node 800 retrieves a total of two packets, 91 and 92, received and stored from the second uplink message 805b, the second uplink combining counter 835b is set to 2 at the T-waiting timing. At this time, packets 01 and 02 received at the same time from the first uplink message 805a may be stored in the memory.

[0119] The middle node 800 combines the called packets in a combiner 840, includes the combined packet 845 in a third uplink message 805c, and transmits the combined packet 845 to the north node in a timely manner. At this time, uncombined packets may also be included in the third uplink message 805c and transmitted.

[0120] FIG. 9 illustrates a system including a counter in the downlink according to one embodiment of the present invention.

[0121] The north node 910 in Figure 9 may be the same as or similar to the controller 650, the DUs 315a and 315b, the O-DUs 610a and 610b, or the north node 710 in Figure 1A or 8. The middle node (e.g., FHM / Cascade O-RU) 920 may be the same as or similar to the FHM 320, the RUs 325d and 325e, or the middle nodes 620a, 620b, 720, and 800 in Figure 1A or 8. The south nodes 930a and 930n may be the same as or similar to the RUs 325a, 325b, 325c, 325d, 325e, and 325f, the O-RUs 640a, 640b, ..., and 640f, or the south nodes 730a and 730n in Figure 1A or 8.

[0122] The middle node 920 in Figure 9 can act as either an FHM or a Cascade O-RU. Figure 9 illustrates the process by which the middle node 920 receives a downlink message from the north node 910, copies the downlink packet, and transmits the copied message to the south nodes 930a and 930n in a downlink situation.

[0123] 9, a north node 910 transmits a downlink message to a middle node 920. Here, the downlink message includes a downlink control plane message or a user plane message. When the middle node 920 receives the downlink message from the north node 910, it can identify the source MAC / IP address, destination MAC / IP address, and eAxC ID from the packet included in the received message. Here, the source MAC / IP address and destination MAC / IP address can be referred to as a transport flow.

[0124] The middle node 920 identifies packets whose destination MAC / IP address is the middle node 920 from the received packets. Packets whose destination MAC / IP address is not the middle node 920 are transmitted to the south nodes 930a and 930n without undergoing a combining process in the middle node 920.

[0125] The middle node 920 determines whether the eAxC ID of a packet whose destination MAC / IP address is the middle node 920 is the same as the eAxC ID included in the predetermined information. Here, the predetermined information is included in the M-plane message received from the north node 910. The north node 910 transmits an M-plane message including predetermined information for specifying packets to be copied to the middle node 920. For example, the predetermined information may be expressed as "shared-cell-copy-entities" in the M-plane message. The "shared-cell-copy-entities" includes the source MAC / IP address, destination MAC / IP address, and eAxC ID of the packet to be copied. The middle node 920 checks for packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is the same as the eAxC ID included in the predetermined information, and stores the packets in memory 950. Alternatively, the packets may be directly transmitted to the copier 960 without being stored in memory. The middle node 920 drops packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is different from the predetermined information.

[0126] The middle node 920 determines and counts the number of packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is the same as the eAxC ID included in the predetermined information. At this time, the number of downlink counters 940a and 940n can be determined based on the count. For example, the downlink counters 940a and 940n are identified as "RX_XX_XX" counters. There may be multiple downlink counters 940a and 940n. The "RX_XX_XX" counters include "RX_UP_DL" indicating the count of downlink user plane packets, "RX_CP_UL" indicating the control plane count used in the uplink, and "RX_CP_DL" indicating the control plane count used in the downlink. For example, if the number of packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is the same as the predetermined information is four among the packets in the downlink user plane message received from the north node 910, the middle node 920 determines the downlink user plane counter "RX_UP_DL" to be four. Furthermore, if the number of packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is the same as the predetermined information is two among the packets in the downlink control plane message received from the north node 910 and whose destination MAC / IP address is the middle node 920, the middle node 920 sets the downlink control plane counter "RX_CP_DL" to 2. Furthermore, if the number of packets whose destination MAC / IP address is the middle node 920 and whose eAxC ID is the same as the predetermined information is three among the packets in the control plane message used in the uplink received from the north node 910 and whose destination MAC / IP address is the middle node 920, the middle node 920 sets the uplink control plane counter "RX_CP_UL" to 3.

[0127] The middle node 920 defines downlink counters 940a and 940n and stores received packets that are not dropped in memory 950. For example, the middle node 920 defines downlink counters for messages received from the north node 910 and stores received packets that are not dropped in memory 950.

[0128] The middle node 920 retrieves from memory, among packets stored in memory, packets to be copied at the copy timing to the copier 960. For example, the middle node 920 retrieves, from the packets stored in memory 950, packets corresponding to symbols to be copied at the copy timing. The middle node 920 may determine downlink copy counters 955a and 955n by counting the number of packets for the symbols retrieved at the copy timing from the packets retrieved from memory. Here, the downlink copy counters 955a and 955n may be identified as "RX_XX_XX_COPIED" counters. The downlink copy counters 955a and 955n indicate the number of packets of user plane messages or control plane messages in the downlink direction that are delivered to the copier to generate copy messages to be transmitted to the south node. For example, the middle node 920 may retrieve downlink user plane packets to be copied from among the packets received from the north node 910 and stored in the memory 950. If the number of such packets is four, the middle node 920 sets the downlink user plane copy counter "RX_UP_DL_COPIED" to 4. Also, the middle node 920 may retrieve downlink control plane packets to be copied from among the packets received from the north node 910 and stored in the memory 950. If the number of such packets is two, the middle node 920 sets the downlink control plane copy counter "RX_CP_DL_COPIED" to 2. Also, the middle node 920 may retrieve control plane packets used for uplink copying from among the packets received from the north node 910 and stored in the memory 950. If the number of such packets is three, the middle node 920 sets the downlink control plane copy counter "RX_CP_UL_COPIED" to 3.

[0129] The middle node 920 can retrieve packets received from the north node 910 and copy them on a copier 960. After copying, the middle node 920 transmits messages to the first south node 930a and the nth south node 930n, including the copied packets and any uncopied packets destined for those south nodes.

[0130] FIG. 10 is a diagram illustrating message flow for copying at a middle node according to one embodiment of the present invention.

[0131] The north node (not shown) in Figure 10 may be the same as or similar to the controller 650, the DUs 315a and 315b, the O-DUs 610a and 610b, or the north nodes 710 and 910 in Figures 1A to 9. The middle node (e.g., FHM / Cascade O-RU) 1000 may be the same as or similar to the FHM 320, the RUs 325d and 325e, or the middle nodes 620a, 620b, 720, 800, and 920 in Figures 1A to 9. The south node (not shown) may be the same as or similar to RUs 325a, 325b, 325c, 325d, 325e, 325f, O-RUs 640a, 640b, ..., 640f, or south nodes 730a, 730n, 930a, 930n in Figures 1A to 9.

[0132] FIG. 10 may illustrate an example of message and packet flow in a system including various types of counters in the downlink as described in FIG.

[0133] 10, the middle node 1000 can receive a downlink user plane message or a control plane message from a north node (not shown). First, the middle node 1000 receives a downlink message 1005 from the north node at a first port 1075. For example, the downlink message 1005 includes a total of nine packets: 11, 12, 13, 14, 21, 22, 31, 32, and 33.

[0134] The middle node 1000 previously receives information 1070 indicating a packet to be copied and transmitted to a south node included in a shared cell from a north node (not shown) via a management plane message. The information indicating the packet to be copied and transmitted to the shared cell includes the transmission flow and eAxC ID of the packet to be copied. For example, the information indicating the packet to be copied and transmitted to the shared cell is identified as "shared-cell-copy-entities." Here, the transmission flow includes the source MAC address and destination MAC address of the packet. The middle node 1000 identifies the transmission flow and eAxC ID from the received downlink message 1005.

[0135] The middle node 1000 determines whether the destination MAC / IP address of a packet included in the received downlink message 1005 is the middle node 1000 based on information 1070 indicating a packet to be copied and transmitted to a south node included in the shared cell. The middle node 1000 transmits packets 1015 whose destination MAC / IP address is not the middle node 1000 to the south node where the destination MAC / IP address is set without separately saving them. For example, packets 23, 15, and 34 of the first port 1075 correspond to packets whose destination MAC / IP address is not the middle node 1000. In particular, packets 15 and 34 are packets 1045 whose destination MAC / IP address is the first south node, and packet 23 is a packet 1050 whose destination MAC / IP address is the second south node.

[0136] When the middle node 1000 determines a packet whose destination MAC / IP address is the middle node 1000, it checks whether the eAxC ID of the packet whose destination MAC / IP address is the middle node 1000 corresponds to a predetermined eAxC ID in the information 1070 indicating packets to be copied to and transmitted in a shared cell. If the eAxC ID of the packet does not correspond to the predetermined eAxC ID, the middle node 1000 drops the packet. If the eAxC ID of the packet whose destination MAC / IP address is the middle node 1000 corresponds to the predetermined eAxC ID, the middle node 1000 counts the number of packets and determines a downlink counter. Here, the downlink counter may be identified as an "RX_XX_XX" counter. The "RX_XX_XX" counters include "RX_UP_DL" indicating a counter 1020 for downlink user plane packets, "RX_CP_UL" indicating a control plane counter 1025 used in the uplink, and "RX_CP_DL" indicating a control plane counter 1030 used in the downlink. For example, the downlink user plane counter "RX_UP_DL" 1020 in the downlink message 1005 is determined to be 4 by a total of four packets, 11, 12, 13, and 14. The control plane counter "RX_CP_UL" 1025 used in the uplink in the downlink message 1005 is determined to be 2 by a total of two packets, 21 and 22. The control plane counter "RX_CP_DL" 1030 used in the downlink in the downlink message 1005 is determined to be 3 by a total of three packets, 31, 32, and 33.

[0137] The middle node 1000 calls the packets to be copied to the copier 1040. For example, the middle node 1000 calls the packets for combining into downlink user plane packets, downlink control plane packets, and control plane packets for use in the uplink.

[0138] The middle node 1000 counts packets just before inputting them to the copier 1040 to generate a copied message to be transmitted to the south node, and determines the copy counter 1035. Here, the copy counter may be identified as "RX_XX_XX_COPIED." For example, the middle node 1000 has called the copier 1040 for four packets, 11, 12, 13, and 14, which are downlink user plane packets specified to be copied in the downlink message 1005, so the downlink user plane copy counter 1035a is 4. Also, the middle node 1000 has called the copier 1040 for two packets, 21 and 22, which are downlink control plane packets specified to be copied in the downlink message 1005, so the downlink control plane copy counter 1035b is 2. In addition, since the middle node 1000 has called the copier 1040 for a total of three packets, 31, 32, and 33, which are control plane packets used for the uplink that are to be copied in the downlink message 1005, the uplink control plane copy counter 1035c becomes 3.

[0139] The middle node 1000 copies the called packet using a copier 1040, includes the copied packet in a first downlink message 1060 at a second port 1080, and transmits both to a first south node (not shown). The middle node 1000 also includes the copied packet in a second downlink message 1065 at a third port 1085, and transmits both to a second south node (not shown). At this time, uncombined packets 1045 and 1050 may be transmitted together by including them in downlink messages 1060 and 1065, respectively.

[0140] FIG. 11 is a flowchart illustrating a method for determining and reporting performance counters according to one embodiment of the present invention.

[0141] The operations described in Figure 11 are operations performed by the north node, middle node, and south node described in Figures 1A to 10, respectively. The north node 1105 in Figure 11 may be the same as or similar to the controller 650, the DUs 315a and 315b, the O-DUs 610a and 610b, or the north nodes 710 and 910 in Figures 1A to 10. The middle node (e.g., FHM / Cascade O-RU) 1110 may be the same as or similar to the FHM 320, the RUs 325d and 325e, or the middle nodes 620a, 620b, 720, 800, and 920 in Figures 1A to 10. The south node 1115 may be the same as or similar to RUs 325a, 325b, 325c, 325d, 325e, 325f, O-RUs 640a, 640b, ..., 640f, or south nodes 730a, 730n, 930a, 930n in Figures 1A to 10.

[0142] The North node in Figure 11 includes multiple nodes. Here, a North node exists for each of the user plane, control plane, synchronization plane, and management plane. Each North node is logically configured to integrate the O-RU controller, DU, O-DU, SMO, etc. (e.g., hierarchical mode), or the O-RU controller, SMO, DU, and O-DU may be separated from each other and function as separate devices.

[0143] In step S1101, the north node 1105 requests and receives middle node information from the middle node 1110. The middle node information includes a topology configuration. For example, the north node 1105 requests and receives from the middle node 1110 information about the middle node 1110, information about the south node 1115 connected to the middle node 1110, information about the shared cell, and information about the eAxC ID associated with the shared cell.

[0144] In step S1102, the north node 1105 requests and receives south node information from at least one south node 1115. The south node information may include topology configuration. For example, the north node 1105 requests and receives information about the south node 1115, information about shared cells, and information about eAxC IDs associated with the shared cells.

[0145] In step S1103, the north node 1105 generates U-plane configuration information based on the middle node and at least one south node capability information received in steps S1101 and S1102, and transmits the U-plane configuration information to the middle node 1110 and at least one south node 1115. The U-plane configuration information can be transmitted via a management plane message.

[0146] In step S1104, the north node 1105 sets information for specifying packets to be copied and information for specifying packets to be combined, and transmits the information to the middle node 1110. The information for specifying packets to be copied and information for specifying packets to be combined may be transmitted via a management plane message. The information for specifying packets to be combined is identified as "shared-cell-combine-entities" in the management plane message. The information for specifying packets to be combined includes source MAC / IP addresses, destination MAC / IP addresses, and eAxC IDs of the packets to be combined. The information for specifying packets to be copied is identified as "shared-cell-copy-entities" in the management plane message. The information for specifying packets to be copied includes source MAC / IP addresses, destination MAC / IP addresses, and eAxC IDs of the packets to be copied.

[0147] In step S1105, the North node 1105 sets performance counters in at least one South node 1115. Here, the performance counters may be transmitted to the at least one South node 1115 via a control plane message. The performance counters include a counter for a receive window (Rx-Window) and a counter for transmission statistics (Tx-stats).

[0148] The counters for the receive window include counters such as those shown in Table 2 below.

[0149] [Table 2]

[0150] RX_ON_TIME is a counter that indicates the number of data packets received on time (receive window defined by the delay parameter) within the "Rx-window-measurement-interval".

[0151] RX_EARLY is the "Receive Window Measurement Interval (Rx-window-measurement-interval)" within the receive window Counter indicating the number of data packets received too early.

[0152] RX_LATE is the "Rx-window-measurement-interval" within the receive window Counter indicating the number of data packets received too late.

[0153] RX_CORRUPT is a packet with a damaged or bad header received within the "Rx-window-measurement-interval". (Data and Control) This is a counter that indicates the number of

[0154] RX_TOTAL is a counter that indicates the total number of packets (data and control) received within the "Rx-window-measurement-interval".

[0155] RX_ON_TIME_C is the time within the "Rx-window-measurement-interval" Receive window This is a counter that indicates the number of control packets received on time.

[0156] RX_EARLY_C is "Rx-window-measurement-interval" within the receive window Counter indicating the number of control packets received too early.

[0157] RX_LATE_C is the "Receive Window Measurement Interval (Rx-window-measurement-interval)" within the receive window Counter indicating the number of control packets received too late.

[0158] RX_SEQID_ERR is a counter that indicates the number of data packets received with an incorrect sequence ID within the "Rx-window-measurement-interval".

[0159] RX_SEQID_ERR_C is a counter that indicates the number of control packets received with an incorrect sequence ID within the "Rx-window-measurement-interval".

[0160] RX_ERR_DROP is a counter indicating the total number of inbound messages dropped by the O-RAN entity for any reason within the "Rx-window-measurement-interval".

[0161] The counters for the transmission statistics include counters such as those shown in Table 3 below.

[0162] [Table 3]

[0163] TX_TOTAL is a counter indicating the number of outbound packets (data and control) transmitted within the "Tx-measurement-interval".

[0164] TX_TOTAL_C is a counter indicating the number of outbound control packets transmitted within a "Transmission Measurement Interval" and can be used only if the RU supports the LAA / LBT function.

[0165] When the North node 1105 sets a performance counter in at least one South node 1115, it transmits a message to the North node 1105 to set a method for reporting the performance counter. First, the notification method can be set to report. The notification method can be a method instructing the North node 1105 to transmit information about a performance counter determined during a measurement interval periodically (e.g., a notification interval) or when an event occurs. Second, the file upload method can be set to report. The file upload method can be a method in which a performance counter determined during a measurement interval is transmitted in file format to the North node's memory or a separate storage server at predetermined times (e.g., at a predetermined upload timing) for each predetermined upload interval. The notification method allows the North node to identify and use information received from the middle node immediately, while the file upload method allows information to be stored in file format and viewed as needed.

[0166] In step S1106, the north node 1105 configures shared cell performance counter measurement objects and reporting types to be sent to the middle node 1110. The shared cell performance counter measurement objects and reporting types are transmitted as management plane messages and are identified as "performance-measurement-objects" and "shared-cell-stats." The shared cell performance counter measurement object configuration also includes information on a counter measurement interval for the shared cell. The counter measurement interval indicates a period for measuring the shared cell copy performance counter and the shared cell binding performance counter. The shared cell performance counter measurement object configuration also includes information on a reporting method after measuring the counter value. According to one embodiment, the reporting method includes a notification method or a file upload method. The shared cell performance counter includes information on a notification interval for the notification method and an upload interval for the file upload method. The shared cell performance counters include a shared cell copy performance counter and a shared cell binding performance counter. The shared cell copy performance counters include a downlink counter and a downlink copy counter. The downlink counters are "RX_XX_XX" counters, and are identified as "RX_UP_DL" indicating the count of downlink user plane packets, "RX_CP_UL" indicating the control plane count used in the uplink, and "RX_CP_DL" indicating the control plane count used in the downlink. The downlink copy counters are identified as respective "RX_XX_XX_COPIED" counters. The downlink copy counters include a user plane downlink copy counter "RX_UP_DL_COPIED", a control plane downlink copy counter "RX_CP_DL_COPIED", and a user plane uplink copy counter "RX_CP_UL_COPIED". The shared cell combining performance counters include an uplink counter and an uplink combining counter. The uplink counter can be identified as an "RX_UP_UL" counter. The uplink counter indicates the number of user plane packets received in the uplink data direction corresponding to the processing elements and eAxC ID configured in the shared cell.The uplink combined counter may be identified as an "RX_UP_UL_COMBINED" counter. The uplink combined counter indicates the "RX_UP_UL" user plane message processed by the combining function to generate a combined message for the processing elements configured in the shared cell and the north node corresponding to the eAxC ID.

[0167] In operation S1107, once the configuration is complete, the north node 1105 transmits and receives user plane messages and control plane messages with the middle node 1110 and at least one south node 1115. Here, the north node 1105 may be a concept distinct from a node that transmits a management plane message. A management function that transmits a management plane message may not transmit or receive user plane messages or control plane messages. In this case, the north node 1105 that transmits and receives user plane messages or control plane messages with the middle node 1110 and the south node 1115 may represent a node that does not include a management function.

[0168] In step S1108, the middle node 1110 measures a downlink counter while performing a copy process for downlink data according to the set information, and measures an uplink counter while performing a merging process for uplink data. The copy process performed by the middle node 1110 is the same as or similar to the copy process described in FIGS. 9 and 10. The merging process performed by the middle node 1110 is the same as or similar to the merging process described in FIGS. 7 and 8.

[0169] In step S1109, the middle node 1110 transmits the counters measured according to the configured method and timing to the north node 1105. The middle node 1110 transmits the measured downlink counters and uplink counters according to the configured method and timing to the north node 1105. The north node 1105 stores the received counter values ​​according to the configured method or uses them to determine performance.

[0170] In step S1110, at least one south node 1115 transmits counters measured according to a set method and timing to the north node 1105. At least one south node 1115 transmits the measured receive window counters and transmission statistics counters to the north node 1105 according to a set method and timing.

[0171] FIG. 12 is a diagram illustrating the performance management portion of the Yang model according to one embodiment of the present invention.

[0172] Referring to Figure 12, the configuration of the O-RAN performance management part can be seen in the Yang model. The O-RAN performance management part is broadly divided into three parts: O-RU and FHM capability values ​​(measurement capabilities), performance measurement object configuration (performance-management-objects), and reporting subscription configuration (measurement-result-stats). First, in O-RAN performance management, the measurement capabilities part includes "shared-cell-stats-objects" 1205 information.

[0173] The performance measurement object component may include "shared-cell-measurement-interval" 1210 information indicating the interval for measuring "shared-cell-stats" in the "measurement-group" portion. It may also include a notification interval and an upload interval. Server location and encryption or authentication information for file uploads are also provided. The "shared-cell-measurement-objects" 1215 information includes "measurementobject", "active", "object-unit", "report-info", and "shared-cell-measurement-result-grouping" information.

[0174] Here, "Measurement object" can specify a measurement object such as RX_UP_UL, RX_UP_UL_combined, etc., and "object-unit" specifies a measurement unit, i.e., a transport flow. Currently, only "report-info" in count format is supported, and this can be reported or uploaded as a pe-measured-result consisting of a transport flow (processing element) and the corresponding count.

[0175] The measurement-result-stats section, which is a notification subscription-style configuration for reporting, includes "shared-cell-stats" 1220. The "shared-cell-stats" 1220 counts numbers in units of transport flows using counters. A transport flow includes a processing element, a destination MAC / IP address, and a source MAC / IP address. This indicates that the counter counts in units of south node or cascade O-RU.

[0176] FIG. 13 is a diagram illustrating the configuration of a north node according to an embodiment of the present invention.

[0177] The North node 1300 in FIG. 13 may be the same as or similar to the controller 650, the DUs 315a and 315b, the O-DUs 610a and 610b, or the North nodes 710, 910, 1105 in FIGS. 1A-11.

[0178] According to an embodiment of the present invention, each function may be included in one device or may be separated into each device in the North node 1300. The North node 1300 may further include other middle nodes (e.g., FHM and cascade RUs connected to FHM and cascade RUs), an O-RU controller, an SMO, a DU, and an O-DU.

[0179] The North node 1300 according to one embodiment of the present invention includes a controller (or processor) 1310 that controls the overall operation of the North node, a transceiver (or transceiver unit) 1320 that includes a transmitter and a receiver, and memory 1330. Of course, the North node 1300 is not limited to the above example, and may include more or less components than those shown in FIG.

[0180] According to an embodiment of the present invention, the transceiver 1320 can transmit and receive signals to and from other network nodes (e.g., south node, O-RU, O-DU, SMO, middle node, upper network entity). Signals transmitted and received to and from the north node include C-plane, U-plane, S-plane, M-plane signals, uplink data, and downlink data. In addition, the transceiver 1320 receives signals via a wireless path or a wired path such as fiber, transfers them to the processor 1310, and transmits signals determined and output from the processor 1310.

[0181] According to an embodiment of the present invention, the processor 1310 may control the north node device to perform any one of the operations of the embodiments of Figures 1A to 12. The processor 1310, memory 1330, and transceiver 1320 do not necessarily have to be implemented as separate modules, but may be implemented as a single component, such as a single chip. The processor 1310, memory 1330, and transceiver 1320 are electrically connected to each other. The processor 1310 may also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0182] According to an embodiment of the present invention, the memory 1330 may store data such as basic programs, applications, and configuration information for the operation of the north node 1300. The memory 1330 also stores uplink and downlink data (user plane, control plane) received by the north node 1300. In particular, the memory 1330 provides the stored data in response to a request from the processor 1310. The memory 1330 may be configured as a storage medium such as a ROM, a RAM, a hard disk, a CD-ROM, or a DVD, or a combination of storage media. The memory 1330 may also be multiple. The processor 1310 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in the memory 1330.

[0183] FIG. 14 illustrates a configuration of a middle node according to an embodiment of the present invention.

[0184] The middle node 1400 of FIG. 14 is the same as or similar to the FHM 320, RUs 325d and 325e, and middle nodes 620a, 620b, 720, 800, 920, and 1110 of FIGS. 1A through 13.

[0185] According to an embodiment of the present invention, the middle node 1400 may include the middle nodes (FHM, cascaded O-RU) described in Figures 1A to 13. In the middle node, each function is included in one device, and each function is separated into each device.

[0186] The middle node 1400 according to one embodiment of the present invention includes a controller (or processor) 1410 that controls the overall operation of the middle node, a transceiver (or transceiver unit) 1420 including a transmitter and a receiver, and memory 1430. Of course, the above example is not limiting, and the middle node 1400 may include more or less components than those shown in FIG.

[0187] According to an embodiment of the present invention, the transceiver 1420 can transmit and receive signals to and from other network nodes (e.g., south node, north node, O-DU, O-RU, RU controller, SMO, other middle node). Signals transmitted and received to and from middle nodes include C-plane, U-plane, S-plane, M-plane signals, uplink data, and downlink data. In addition, the transceiver 1420 receives signals via a path such as a fiber, transfers them to the processor 1410, and transmits signals determined and output from the processor 1410 via the channel.

[0188] According to an embodiment of the present invention, the processor 1410 may control the middle node device to perform any one of the operations of the embodiments shown in FIGS. 1A to 13. The processor 1410, memory 1430, and transceiver 1420 do not necessarily have to be implemented as separate modules, but may be implemented as a single component, such as a single chip. The processor 1410, memory 1430, and transceiver 1420 are electrically connected to each other. The processor 1410 may also be an application processor (AP), a communication processor (CP), a circuit, an application-specific circuit, or at least one processor. The processor 1410 of the middle node 1400 includes a combiner, a copier, and the like for performing operations. Each function may be included as a separate device or may be included in the processor 1410 as a function. The processor controls the operations of the combiner and the copier.

[0189] According to an embodiment of the present invention, the memory 1430 may store data such as basic programs, applications, and configuration information for the operation of the middle node. The memory 1430 also stores uplink and downlink data (user plane and control plane) received by the middle node. In particular, the memory 1430 provides the stored data in response to a call from the processor 1410. The memory 1430 may be configured as a storage medium such as a ROM, RAM, hard disk, CD-ROM, or DVD, or a combination of storage media. The memory 1430 may include at least one buffer for temporarily storing uplink data or downlink data. The memory 1430 may also include multiple memories 1430. The processor 1410 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in the memory 1430.

[0190] FIG. 15 is a diagram illustrating the configuration of a south node according to an embodiment of the present invention.

[0191] The south node 1500 in Figure 15 may be the same as or similar to RUs 325a, 325b, 325c, 325d, 325e, 325f, O-RUs 640a, 640b, ..., 640f, or south nodes 730a, 730n, 930a, 930n, 1115 in Figures 1A to 14.

[0192] According to an embodiment of the present invention, each function of south node 1500 may be included in a single device, or each function may be separated into a separate device. South node 1500 may further include other middle nodes (e.g., FHM and cascade RUs connected to FHM and cascade RUs), RUs, and O-RUs.

[0193] The south node 1500 according to one embodiment of the present invention includes a controller (or processor) 1510 that controls the overall operation of the south node, a transceiver (or transceiver unit) 1520 including a transmitter and a receiver, and memory 1530. Of course, the above example is not limiting, and the south node 1500 may include more or less components than those shown in FIG.

[0194] According to an embodiment of the present invention, the transceiver 1520 can transmit and receive signals to and from other network nodes (e.g., southbound nodes, northbound nodes, O-RUs, controllers, SMOs, middle nodes, and upper network entities). Signals transmitted and received from the south node include C-plane, U-plane, S-plane, and M-plane signals, uplink data, and downlink data. The transceiver 1520 also receives signals via a wireless path or a wired path such as fiber, transmits the signals to the processor 1510, and transmits the signals determined and output from the processor 1510 via the channels.

[0195] According to an embodiment of the present invention, the processor 1510 may control the south node device to perform any one of the operations of the embodiments of Figures 1A to 14. Meanwhile, the processor 1510, the memory 1530, and the transceiver 1520 do not necessarily have to be implemented as separate modules, but may be implemented as a single component in the form of a single chip, for example. The processor 1510, the memory 1530, and the transceiver 1520 are electrically connected to each other. The processor 1510 may also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0196] According to an embodiment of the present invention, memory 1530 may store data such as basic programs, applications, and setting information for operation of south node 1500. Memory 1530 also stores uplink and downlink data received by the south node. In particular, memory 1530 provides stored data in response to a request from processor 1510. Memory 1530 may be configured as a storage medium such as ROM, RAM, a hard disk, CD-ROM, or DVD, or a combination of storage media. Memory 1530 may also be multiple. Processor 1510 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in memory 1530.

[0197] FIG. 16 is a flow chart illustrating a method for performance measurement and reporting according to one embodiment of the present invention.

[0198] The performance counter measurement method of the middle node described in Figures 1A to 15 will be described below with reference to Figure 16. Each operation is not necessarily included in the series of steps, and may be partially configured and operated depending on the situation.

[0199] In step S1610, a middle node (e.g., FHM 320, RUs 325d and 325e, middle nodes 620a, 620b, 720, 800, 920, 1110 in FIGS. 1A to 11) receives information regarding messages to be combined in a shared cell (e.g., information indicating packets to be combined in the shared cell in FIG. 8, information for specifying packets to be combined in FIG. 11) from a north node (e.g., controller 650, DUs 315a and 315b, O-DUs 610a and 610b in FIGS. 1A to 11, other middle nodes, or north nodes 710, 910, 1105 in FIGS. 1A to 11).

[0200] Here, the information regarding the messages to be combined in the shared cell includes information regarding the transport flow and eAxC (extended antenna-carrier) ID (identifier) ​​of the messages to be combined among the uplink messages transmitted from the multiple south nodes (e.g., information for specifying the packets to be combined in FIG. 11), and the information regarding the transport flow includes the source MAC or IP address and destination MAC or IP (MAC / IP) address of the messages to be combined.

[0201] In step S1620, the middle node receives user plane messages (e.g., the first uplink user plane message 805a and the second uplink user plane message 805b in FIG. 8) from multiple south nodes (e.g., RUs 325a, 325b, 325c, 325d, 325e, 325f, O-RUs 640a, 640b, ..., 640f in FIGS. 1A to 11, and other middle nodes or south nodes 730a, 730n, 930a, 930n, 1115), respectively.

[0202] In step S1630, the middle node identifies packets to combine from packets included in each user plane message based on information about messages to be combined in the shared cell.

[0203] Here, the middle node identifies the transmission flow and the eAxC ID of packets included in each of the user plane messages, and if the destination MAC / IP address of at least one first packet among the packets included in each of the user plane messages is not the middle node MAC / IP address, transmits the at least one first packet (e.g., packet 817 whose destination MAC / IP address is not the middle node 800 in FIG. 8) to the north node without combining; if the destination MAC / IP address of at least one second packet among the packets included in each of the user plane messages is the middle node MAC / IP address and the eAxC ID is different from the eAxC ID included in the information related to the messages to be combined in the shared cell, drops the at least one second packet; and if the destination MAC / IP address of at least one third packet among the packets included in each of the user plane messages is the middle node MAC / IP address and the eAxC ID matches the eAxC ID included in the information related to the messages to be combined in the shared cell, identifies the at least one third packet as the packet to be combined.

[0204] In step S1640, the middle node counts the identified combined packets to determine an uplink counter value (e.g., uplink counter values ​​740a and 740n in FIG. 7, uplink counter values ​​815a and 815b in FIG. 8) for each of the multiple south nodes.

[0205] In one embodiment, the middle node stores the identified packets to be combined in a memory (e.g., memories 725a and 725b in FIG. 7, memory 830 in FIG. 8), and at a predetermined timing (e.g., T-waiting timing in FIG. 8), retrieves the packets related to the symbols to be combined stored in the memory (e.g., packets 832 and 834 in FIG. 8) in a combiner (e.g., combiner 760 in FIG. 7, combiner 840 in FIG. 8), counts the retrieved packets, and determines an uplink combining counter value (e.g., first uplink combining counter 750a in FIG. 7, nth uplink combining counter 750n, or uplink combining counters 835a and 835b in FIG. 8) for each of the plurality of south nodes.

[0206] In one embodiment, the middle node receives information (e.g., the shared cell performance counters of FIG. 11) regarding a first interval (e.g., an interval in the notification method of FIG. 11) or a second interval (e.g., an interval in the file upload method of FIG. 11) for counter reporting from the north node via a control plane message, and transmits the uplink counter value and the uplink combined counter value to the north node for each first interval, or transmits the uplink counter value and the uplink combined counter value in file format to a memory or storage server of the north node for each second interval.

[0207] In one embodiment, the middle node determines that no packets are missing in user plane messages received from each of the plurality of south nodes if the values ​​of the uplink combining counters for each of the plurality of south nodes are all equal, or determines that an equal number of packets are missing in user plane messages received from each of the plurality of south nodes.

[0208] In one embodiment, the middle node determines that messages received from a first south node are persistently missing when the difference between the uplink counter value for a first south node among the plurality of south nodes and the uplink combined counter value for the first south node gradually increases.

[0209] In one embodiment, the middle node determines that if the values ​​of the uplink combining counters for each of the plurality of south nodes are different, then some messages are missing or a different number of messages are received at a particular time.

[0210] In one embodiment, the middle node receives from the north node configuration information for uplink counters and uplink combined counters for each of the plurality of south nodes, and the configuration information for the uplink counters and uplink combined counters includes information indicating the measurement interval for the counters (e.g., "shared-cell-measurement-interval" 1210 in FIG. 12), information indicating the entities for which the counters are to be measured (e.g., "shared-cell-stats-objects" 1205 in FIG. 12), and information regarding the notification interval or file upload interval for reporting counter values.

[0211] In one embodiment, the middle node includes a fronthaul-multiplexer or a cascade radio unit, the north node includes a middle node different from the middle node, a distributed unit, a radio unit controller, or a service management and orchestration (SMO), and the plurality of south nodes include further middle nodes or radio units.

[0212] The various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions, including, but not limited to, various hardware and / or software components and / or modules, such as an application specific integrated circuit (ASIC), or a processor. Generally, where there are corresponding operations in the figures, such operations may also have corresponding relative means and functional components with the same numbers.

[0213] The various illustrative logic blocks, modules, and circuits described in connection with the present invention may be embodied or implemented by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions disclosed herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be embodied in a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other configuration.

[0214] Additionally, the term "determining" as used above encompasses a wide variety of actions. For example, "determining" includes calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or other data structure), ascertaining, etc. Also, "determining" includes receiving (e.g., receiving information), accessing (accessing data in a memory), etc. Also, "determining" includes resolving, selecting, choosing, establishing, etc.

[0215] Those skilled in the art will appreciate that various modifications and variations may be made without departing from the essential characteristics of the technical idea of ​​the present invention.

[0216] Therefore, the embodiments exemplified in the present invention are intended to explain rather than limit the technical idea of ​​the present invention, and the scope of the technical idea of ​​the present invention is not limited by these embodiments.

[0217] The scope of protection of the technical idea of ​​the present invention should be interpreted by the following claims, and all technical ideas within the equivalent range should be interpreted as being included in the technical imaginary scope of the present invention.

Claims

1. 1. A method performed by a middle node in a communication system, comprising: receiving a configuration message from a north node, the configuration message including information regarding messages to be combined in a shared cell; receiving user plane messages from a plurality of south nodes included in the shared cell; identifying packets to be combined from packets included in each of the received user plane messages based on information about messages to be combined in the shared cell; and counting the identified combining packets to determine an uplink counter value for each of the plurality of south nodes.

2. storing the identified combined packets in a memory; calling a packet relating to a symbol to be combined stored in the memory to a combiner at a predetermined timing; 2. The method of claim 1, further comprising counting the invoked packets to determine an uplink combined counter value for each of the plurality of south nodes.

3. receiving information regarding a first interval or a second interval for counter reporting from the north node via a control plane message; 3. The method of claim 2, further comprising: transmitting an uplink counter value and an uplink combined counter value for each of the plurality of south nodes to the north node at each first interval; or transmitting an uplink counter value and an uplink combined counter value for each of the plurality of south nodes in file format to a memory or a storage server of the north node at each second interval.

4. Information about messages that should be combined in a shared cell is The message includes information regarding transport flows and eAxC (extended antenna-carrier) IDs (identifiers) of messages to be combined among uplink messages transmitted from the plurality of south nodes, 2. The method of claim 1, wherein the information about the transmission flow includes a source media access control (MAC) or internet protocol (IP) address and a destination MAC or IP (MAC / IP) address of the messages to be combined.

5. identifying packets to be combined from packets included in each of the received user plane messages based on information about messages to be combined in the shared cell, identifying the transport flow and the eAxC ID of packets included in each of the user plane messages; If a destination MAC / IP address of at least one first packet among packets included in each of the user plane messages is not a middle node MAC / IP address, transmitting the at least one first packet to the north node without combining; dropping at least one second packet among packets included in each of the user plane messages if a destination MAC / IP address of the second packet is the middle node MAC / IP address and the eAxC ID is different from an eAxC ID included in information related to a message to be combined in the shared cell; and identifying at least one third packet as the packet to be combined if a destination MAC / IP address of the at least one third packet among the packets included in each of the user plane messages is the middle node MAC / IP address and the eAxC ID matches an eAxC ID included in information related to messages to be combined in the shared cell.

6. 3. The method of claim 2, further comprising determining that no packets are missing in user plane messages received from each of the plurality of south nodes if the values ​​of the uplink combining counters for each of the plurality of south nodes are all equal, or determining that an equal number of packets are missing in user plane messages received from each of the plurality of south nodes.

7. 3. The method of claim 2, further comprising determining that messages received from a first south node are persistently missing when a difference between an uplink counter value for a first south node among the plurality of south nodes and a value of an uplink combined counter for the first south node gradually increases.

8. 3. The method of claim 2, further comprising determining that if the values ​​of the uplink combining counters for each of the plurality of south nodes are different, then some messages are missing at a particular time or a different number of messages are received.

9. The middle node includes a fronthaul multiplexer or a cascade radio unit; the north node includes a middle node, a distributed unit, a radio unit controller, or a service management and orchestration (SMO) different from the middle node; The method of claim 1 , wherein the plurality of south nodes further includes other middle nodes or wireless units.

10. receiving, from the north node, configuration information for an uplink counter and an uplink combined counter for each of the plurality of south nodes; 3. The method of claim 2, wherein the configuration information for the uplink counter and the uplink combined counter includes information indicating a measurement interval for the counter, information indicating an entity for measuring the counter, and information regarding a notification interval or a file upload interval for reporting the counter value.

11. In a middle node in a communication system, A transmitter / receiver; Memory and at least one processor electrically coupled to the transceiver and the memory; The at least one processor: receiving a configuration message from a north node containing information regarding messages to be combined in a shared cell; receiving user plane messages from a plurality of south nodes included in the shared cell, respectively; Identifying packets to be combined from packets included in each of the received user plane messages based on information about messages to be combined in the shared cell; A middle node configured to count the identified combining packets to determine an uplink counter value for each of the plurality of south nodes.

12. The at least one processor: storing the identified combining packets in a memory; At a predetermined timing, the packets related to the symbols to be combined stored in the memory are called by the combiner; 12. The middle node of claim 11, further configured to count the invoked packets to determine an uplink combined counter value for each of the plurality of south nodes.

13. The at least one processor: receiving information regarding a first interval or a second interval for counter reporting via a control plane message from the north node; 13. The middle node of claim 12, further configured to: transmit an uplink counter value and an uplink combined counter value for each of the plurality of south nodes to the north node at each first interval; or transmit an uplink counter value and an uplink combined counter value for each of the plurality of south nodes in file format to a memory or storage server of the north node at each second interval.

14. Information about messages that should be combined in a shared cell is The message includes information regarding transport flows and eAxC (extended antenna-carrier) IDs (identifiers) of messages to be combined among uplink messages transmitted from the plurality of south nodes, 14. The middle node of claim 11, wherein the information about the transmission flow includes a source media access control (MAC) or internet protocol (IP) address and a destination MAC or IP (MAC / IP) address of the messages to be combined.

15. The at least one processor: When identifying packets to be combined from packets included in each of the received user plane messages based on information about messages to be combined in the shared cell, Identifying the transport flow and the eAxC ID of packets included in each of the user plane messages; If a destination MAC / IP address of at least one first packet among packets included in each of the user plane messages is not a middle node MAC / IP address, the at least one first packet is transmitted to the north node without being combined; Dropping at least one second packet among the packets included in each of the user plane messages if the destination MAC / IP address of the second packet is the middle node MAC / IP address and the eAxC ID is different from the eAxC ID included in the information related to the message to be combined in the shared cell; 15. The middle node of claim 14, further configured to: identify at least one third packet among the packets included in each of the user plane messages as the packet to be combined if a destination MAC / IP address of the at least one third packet is the middle node MAC / IP address and the eAxC ID matches an eAxC ID included in information related to messages to be combined in the shared cell.

16. The at least one processor:

13. The middle node of claim 12, further configured to: determine that no packets are missing in user plane messages received from each of the plurality of south nodes if the values ​​of the uplink combining counters for each of the plurality of south nodes are all equal, or determine that an equal number of packets are missing in user plane messages received from each of the plurality of south nodes.

17. The at least one processor:

13. The middle node of claim 12, further configured to determine that messages received from a first south node are persistently missing if a difference between an uplink counter value for a first south node of the plurality of south nodes and an uplink combined counter value for the first south node becomes increasingly large.

18. The at least one processor:

13. The middle node of claim 12, further configured to determine that if the uplink combining counters for each of the plurality of south nodes have different values, then some messages are missing at a particular time or a different number of messages are received.

19. The middle node includes a fronthaul multiplexer or a cascade radio unit; the north node includes a middle node, a distributed unit, a radio unit controller, or a service management and orchestration (SMO) different from the middle node; The middle node of claim 11 , wherein the plurality of south nodes further includes other middle nodes or wireless units.

20. The at least one processor: further configured to receive from the north node configuration information for an uplink counter and an uplink combined counter for each of the plurality of south nodes; 13. The middle node of claim 12, wherein the configuration information for the uplink counter and the uplink combined counter includes information indicating a measurement interval for the counter, information indicating an entity for measuring the counter, and information regarding a notification interval or a file upload interval for reporting the counter value.

Images