Distributed unit, radio unit and methods performed therein

Abstract

A method performed by a distributed unit (DU) (1202) for handling communications in a wireless communication network (1). The DU (1202) configures (803) one static endpoint mapped to two or more non-static endpoints for a radio unit (RU) (1203). Each non-static endpoint has a defined logical path between the DU (1202) and the RU (1203) for transmitting data of the data stream of the one static endpoint.

Description

Technical Field

[0001] The embodiments herein relate to a distributed unit (DU), a radio unit (RU), and a method for wireless communication performed therein. Furthermore, a computer program and a computer-readable storage medium are also provided herein. Specifically, the embodiments herein relate to processing communications, such as processing data in a wireless communication network. Background Technology

[0002] In a typical wireless communication network, User Equipment (UE) (also referred to as wireless communication device, mobile station, site (STA), and / or wireless device) communicates with one or more core networks (CN) via a Radio Access Network (RAN). RAN coverage can be divided into geographical areas of service or cells, each of which is served by a radio network node, such as an access node (e.g., a Wi-Fi access point or radio base station (RBS)). In some networks, radio network nodes may also be referred to as, for example, NodeB, gNodeB, or eNodeB. A service area or cell can be understood as a geographical area where wireless services can be provided by radio network nodes. Radio network nodes operate on radio frequency to communicate with UEs within their range via an air interface. Radio network nodes can communicate with UEs via downlink (DL), and UEs can communicate with radio network nodes via uplink (UL).

[0003] Universal Mobile Telecommunications System (UMTS) can be understood as a third-generation (3G) telecommunications network evolved from the second-generation (2G) Global System for Mobile Communications (GSM). The UMTS Terrestrial Radio Access Network (UTRAN) can be understood as essentially a RAN that uses Wideband Code Division Multiple Access (WCDMA) and / or High-Speed ​​Packet Access (HSPA) to communicate with user equipment. In a forum known as the 3rd Generation Partnership Project (3GPP), telecommunications providers propose and agree on standards for current and next-generation networks, and investigate aspects such as enhanced data rates and radio capacity. In some RANs, such as those in UMTS, several radio network nodes can connect (e.g., via terrestrial lines or microwave) to a controller node (e.g., a Radio Network Controller (RNC) or Base Station Controller (BSC)), which monitors and coordinates the various activities of the multiple radio network nodes connected to it. The RNC can typically connect to one or more core networks.

[0004] The Evolved Packet System (EPS) specification has been completed within 3GPP, and upcoming 3GPP versions, such as New Radio (NR) and 6G, are being developed. EPS can be understood as comprising the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) (also known as the Long Term Evolution (LTE) Radio Access Network) and the Evolved Packet Core (EPC) (also known as the System Architecture Evolution (SAE) Core Network). E-UTRAN / LTE can be understood as 3GPP radio access technologies where radio network nodes can directly connect to the EPC core network. Therefore, the EPS radio access network (RAN) can be understood as having a essentially "flat" architecture, consisting of radio network nodes directly connected to one or more core networks.

[0005] In emerging 5G technologies such as New Radio (NR), the extensive use of transmit and receive antenna elements is of great interest because it allows for the utilization of beamforming, such as transmit-side beamforming and receive-side beamforming. Transmit-side beamforming can be understood as the transmitter amplifying the transmitted signal in one or more selected directions while suppressing transmitted signals in other directions. Similarly, on the receiver side, the receiver amplifies signals from one or more selected directions while suppressing unwanted signals from other directions.

[0006] Open RAN (O-RAN) is made possible by a set of standards that can be used by vendors. Therefore, a wireless communication network can include one or more Open RAN (ORAN) nodes. An ORAN node can be understood as a node in a wireless communication network that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or in conjunction with other nodes to implement one or more functions of any node in the wireless communication network (including one or more network nodes and / or core network nodes).

[0007] Examples of ORAN network nodes can include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), RAN intelligent controllers (near real-time or non-real-time), or any combination thereof (the adjective "open" indicates support for the ORAN specification). ORAN network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces), open fronthaul user plane interfaces, or open fronthaul management plane interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment where one or more network functions can be virtualized. For example, the virtualized environment can include an open cloud (O-Cloud) computing platform orchestrated by a service management and orchestration framework via an O-2 interface or equivalent technology defined by the O-RAN Consortium.

[0008] An O-RAN Distributed Unit (O-DU) can be understood as a node that hosts the Radio Link Control (RLC) / Media Access Control (MAC) / Physical High Layer (PHY) based on lower-level functional segmentation, such as a logical node. High PHY can be understood as referring to the portions of the PHY layer that are processed on the O-DU side of the fronthaul interface.

[0009] An O-RAN radio unit (O-RU) can be understood as a node that hosts a low-PHY layer and radio frequency (RF) processing based on low-level functional segmentation, such as a logical node. The low-PHY layer can be understood as those parts of the PHY layer that are processed on the O-RU side of the fronthaul interface.

[0010] In O-RAN, control / user (C / U) plane application endpoints (referred to as endpoints in this document) can be understood to include low-level endpoints and static low-level endpoints. In O-RAN, a static low-level endpoint can be declared by the O-RU and can be understood as representing the capability to process data streams and different message types, as well as the beamforming methods it supports. Static low-level endpoints can be reported by the O-RU, where "static" can be understood to mean that the reported parameter values ​​may be read-only and may mean that they are not configured or changed by any client. Low-level endpoints can be associated with static low-level endpoints by using the same name to refer to them. Additional configurations can be made, such as enabling their supported functions and assigning an eAXC_iD that can be used as the address of a low-level endpoint in C / U plane messages. Currently, it can be understood that each endpoint can represent a layer or spatial stream in a carrier. Spatial streams can be understood as referring to the data streams on the DL associated with precoded data (which may be the same as or different from the layer if extensions exist in the precoding), and on the UL, it can be associated with the number of digital beamforming outputs (sometimes referred to as "beams"). Layers can be understood as 3GPP concepts primarily used for PDSCH and PUSCH channels. Spatial streams in the UL can be understood as defining beamforming data streams that can be used to transmit data for other channels, such as the Physical Random Access Channel (PRACH).

[0011] In O-RAN, low-level (LL) endpoints can be understood as corresponding to static low-level endpoints, which may also be referred to as static endpoints in this document. Low-level endpoints can utilize the capabilities that may have been declared by static endpoints. Low-level endpoints can be configured.

[0012] This low-level endpoint can be understood as being associated with processing uplink and downlink data flows between O-DU and O-RU.

[0013] In the O-RU, static low-level transmit and / or receive (t[r]x) endpoints can be reported as part of a capability report. Each static low-level t[r]x endpoint can be understood as representing the processing capability for a data stream (e.g., a layer) on a carrier. In the O-RAN Low-Level Segmentation (LLS) interface, a data stream can be understood as a layer or spatial stream of data that can move through various components and layers of the network. This can involve sending data packets from one endpoint to another, thereby ensuring that information can be processed and transmitted correctly. If the O-RU supports eight uplink data layers for a carrier, it can report eight static low-level rx endpoints for each of the eight uplink data layers supported by the receive (rx) carrier.

[0014] Currently, low-level t[r]x endpoints and static low-level t[r]x endpoints have a one-to-one cardinality constraint. That is, a constraint on the number of relationships they can have. Each static endpoint can be understood as mapping to a low-level endpoint. An identifier (id) can be configured for each low-level t[r]x endpoint, such as an extended antenna carrier (eAxC) id. eAxC can be understood as referring to the data stream of a single antenna or the spatial stream of a single carrier in a single sector. User (U) plane applications can use an identifier such as eAxC-id to switch messages to the intended processing entity in the O-DU. This can be understood because a low-level t[r]x endpoint can be understood as having a mapping to a processing entity on the O-DU. The processing entity can be understood as a digital signal processor (DSP), a central processing unit (CPU) core, or a dedicated processor. In cases where a DU may have multiple processing entities that may share the processing workload of a data layer or data spatial stream, it may be necessary to publish (i.e., reported by the O-RU) many static endpoints to achieve load sharing at the DU.

[0015] As shown in the following excerpt from the M-plane Yang model, in O-RAN, it is currently assumed that lower-level endpoints can use the exact same names as static lower-level endpoints, corresponding to a 1:1 cardinality.

[0016]

[0017] Figure 1 The example illustrates a general understanding that can be interpreted as a one-to-one cardinality constraint between static endpoints (SEPs) and lower-level endpoints (EPs).

[0018] Because of this 1-to-1 cardinality limitation, it can be understood that it is intended to support only hierarchical load balancing. This can be understood as meaning that an O-DU can have an allocation to a single processing entity (e.g., Figure 1 Several processing layers of processing entity 1 in the process and the processing layer assigned to another processing entity (e.g., Figure 1 The other processing layers in processing entity 2). The allocated units can be understood as each data layer.

[0019] Because the endpoint identifier eAxC-Id used in C / U plane messages can be understood as not expected to change frequently, the possibility of O-DU load balancing is limited. The endpoint's eAxC_id can be understood as having 16 bits and can be divided into four fields: DU port id, component carrier (cc) id, band sector ID, and RU_Port-id. The DU port id can be used to indicate which DU processing entity will be able to process the data received and sent to that endpoint. If it is expected that data streams will be sent to two different DU processing entities, the DU port id can be understood as needing to have different values. However, because the DU port id can be understood as part of the eAxC_id, the eAxC_id can be understood as being different for data to be processed in different DU processing entities. Using two DU processing entities to process data from a single eAxC_Id may not be feasible. Load can be understood as being divided by layer and / or spatial stream level rather than by message level. Spatial streams in the defined UL can be understood as beamforming data streams that may need to be transmitted between O-RU and O-DU. Based on the WG4 definition, data from a spatial stream may need to be segmented into C / U plane messages. There may be many C / U plane messages to be sent from the O-RU to the O-DU for converting symbol data.

[0020] exist Figure 1 In the specific example shown, assuming the O-RU supports 8 layers, then for these data layers, there are 8 static endpoints (in... Figure 1 The area depicted as a solid black cube can be interpreted as exposed. Figure 1 In this process, spatial flow is sent from O-RU to O-DU via lower-level endpoints, as shown by the arrows from right to left.

[0021] exist Figure 1 In the specific example shown, the O-DU has two processing entities (processing entity 1 and processing entity 2), and for each layer, only one processing entity will perform processing. Each processing entity can be understood as receiving the stream via a corresponding port, which may have a corresponding identifier. Figure 1 In this configuration, the first three lower-level endpoints can use DU-Port-ID=1, and the remaining endpoints may need to use DU-Port-ID=2. The O-DU understands how the DU-port-ID can be assigned to different eAXCids; that is, it can be assigned as part of the eAxC_ID for each lower-level endpoint. The O-DU port ID can be used to indicate logical flows, such as data layers or spatial flows. Since the DU-Port-Id can be understood as part of the eAxC-id in the eAxC-id structure, each layer can be directed to an O-DU processing entity. Figure 1The processing element flow 1, depicted by a cylinder, can be understood as referring to the transport flow. Summary of the Invention

[0022] As part of the development examples described herein, one or more issues are first identified.

[0023] UE traffic can be understood as uneven, with peaks and variations over time and location. This can be reflected at the data layer, where data at each layer can differ significantly over time. To better utilize O-DU processing capabilities, it can be understood that it is desirable to send data at one layer to different processing entities based on load conditions. However, load balancing can be understood as currently limited by low-level t[r]x endpoints and static low-level t[r]x endpoints, as well as the cardinality of low-level t[r]x endpoints and processing entities. This can be understood as load balancing only being statically achieved through layers, streams, and / or spatial streams. As previously mentioned, load can be partitioned at the layer and / or spatial stream level rather than the message level.

[0024] To leverage the current specification to enable data from a single layer to be processed by multiple O-DU processing entities, while still adhering to the current specification's principle that a low-level t[r]x endpoint can only be mapped to one processing entity, it may be necessary to break one of the O-RAN concepts (e.g., a static endpoint can represent a data layer). By consuming two or three times the number of static low-level t[r]x endpoints per carrier, it is possible to enable a layer to be processed by multiple O-DU processing entities. However, this can be understood as potentially reducing the number of carriers supported by the O-RU.

[0025] Figure 2 This is a schematic diagram illustrating an example of this approach, where achieving flexible load balancing at the message level, allowing a spatial stream to be sent to multiple DU processing entities (e.g., 2 DU processing entities), may require twice the number of endpoints. In the example shown, for 8 layers, if each layer's data is to be processed by 2 processing entities, this can be understood as requiring 16 static endpoints. This usage can also be understood as breaking the concept that each endpoint can represent a layer or spatial stream. This can be understood as: while maintaining the principles of the current specification, a low-level t[r]x endpoint can thus be mapped to only one processing entity. The consequence of this approach can be understood as: for O-RUs reporting a certain number of static endpoints, the number of supported carriers can be understood as being reduced to half the original value.

[0026] Another aspect of this approach can be understood as O-RU design potentially needing to consider the O-DU load balancing architecture. When an O-RU can declare the number of static endpoints it supports, it can only consider the number of layers or data streams it can support. It's understandable that it's unreasonable for an O-RU to consider the O-DU architecture when reporting static endpoint support. That is, one workaround for load balancing using the current base is to have each data stream (space stream) use more static endpoints and create multiple low-level endpoints. Each low-level endpoint is assigned a different value for the DU port ID. In this case, for a defined number of space streams to be sent, the number of static endpoints used per carrier can be understood as the support for each carrier and the number of carriers it can support, and is the product of the number of DU processing entities and the number of space streams. However, if the number of reported static endpoints is fixed, the number of supported carriers can be understood as decreasing. To keep the number of supported carriers constant, an O-RU might need to report many times more static endpoints while considering how many O-DU processing entities perform load balancing. This configuration approach can be understood as introducing an architectural dependency between the O-RU and O-DU. When an O-RU can report its static endpoints, it may need to consider the load balancing model supported by the O-DU. For an O-DU that may intend to send a layer of data to multiple processing entities, the O-RU may need to report more supported static lower-level t[r]x endpoints. This dependency between the O-RU design and the O-DU architecture is undesirable. The O-DU's use of static endpoints can be understood as affecting the number of carriers supported by the O-RU.

[0027] The embodiments described herein can be understood as addressing problems identified in existing methods.

[0028] The purpose of the embodiments described herein can be understood as providing a mechanism for efficient data processing communication in a wireless communication network.

[0029] According to one aspect, and according to embodiments thereof, this objective can be achieved by providing a method performed by a distributed unit for processing communications (e.g., data) in a wireless communication network. The DU configures the RU to map to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU and the RU for transmitting data streams from the static endpoint.

[0030] According to one aspect, and according to embodiments herein, this objective can be achieved by providing a method performed by a radio unit for processing communications (e.g., data) in a wireless communication network. The RU receives configuration data from the DU. This configuration data configures the RU to map to one static endpoint among two or more non-static endpoints. Each non-static endpoint has a defined logical path between the DU and the RU for transmitting data streams from that static endpoint.

[0031] According to one aspect, according to embodiments herein, this objective is achieved by providing DUs and RUs respectively configured to perform the methods described herein.

[0032] According to one aspect, and according to embodiments herein, this objective can be achieved by providing a distributed unit for processing communications (e.g., data) in a wireless communication network. The DU is configured to map a RU to a static endpoint mapped to two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU and the RU for transmitting data streams from the static endpoint.

[0033] According to one aspect, and according to embodiments herein, this objective can be achieved by providing a method performed by a radio unit for processing communications (e.g., data) in a wireless communication network. The RU is configured to receive configuration data from the DU. This configuration data maps the RU to one static endpoint among two or more non-static endpoints. Each non-static endpoint has a defined logical path between the DU and the RU for transmitting data streams from that static endpoint.

[0034] This document also provides a computer program product including instructions that, when executed on at least one processor, cause the at least one processor to perform the method of this document, which is executed by a DU and a RU, respectively. This document also provides a computer-readable storage medium having stored thereon a computer program product including instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to this document, which is executed by a DU and a RU, respectively.

[0035] Therefore, embodiments of this paper can map data from one layer of a transmit and / or receive endpoint of the RU to be processed by multiple processing units of the DU. This can be achieved by configuring multiple low-level t[r]x endpoints to refer to the same static low-level t[r]x endpoint.

[0036] This can be understood as enabling the assignment of multiple eAxC-IDs with different DU-Port-IDs to a single data layer. DUs can then route data and / or messages to different DU processing units based on workload conditions.

[0037] This can be understood as, for example, achieving more flexible load balancing on the DU side.

[0038] Therefore, data communication can be processed efficiently in wireless communication networks. Attached Figure Description

[0039] The embodiments will now be described in more detail with reference to the accompanying drawings, in which:

[0040] Figure 1 An example of DU and RU deployment based on existing technology is shown;

[0041] Figure 2 Examples of DU and RU deployments according to alternative examples of embodiments of this document are shown;

[0042] Figure 3 An overview depicting a wireless communication network according to embodiments thereof is shown;

[0043] Figure 4 An overview depicting a radio network node according to an embodiment of this document is shown;

[0044] Figure 5 The combined signaling scheme and flowcharts illustrating embodiments described herein are shown;

[0045] Figure 6 An example of DU and RU deployment according to embodiments of this document is shown;

[0046] Figure 7 Another example of DU and RU deployment according to the embodiments of this document is shown;

[0047] Figure 8 A flowchart depicting a method performed by a DU according to an embodiment of this document is shown;

[0048] Figure 9 A flowchart depicting a method performed by a RU according to an embodiment of this document is shown;

[0049] Figure 10 A block diagram depicting an embodiment of a DU according to embodiments herein is shown;

[0050] Figure 11 A block diagram depicting an embodiment of the RU according to embodiments herein is shown;

[0051] Figure 12 An example of a communication system 1200 according to some embodiments is shown;

[0052] Figure 13 A UE 1300 according to some embodiments is shown;

[0053] Figure 14A network node 1400 according to some embodiments is shown;

[0054] Figure 15 This is a block diagram of host 1500 based on the various aspects described herein, which host 1500 can be Figure 12 An embodiment of host 1216;

[0055] Figure 16 This is a block diagram illustrating a virtualization environment 1600 in which functionality implemented by some embodiments can be virtualized; and

[0056] Figure 17 A communication diagram is shown of a host 1702 communicating with a UE 1706 via a network node 1704 through a partial wireless connection, according to some embodiments. Detailed Implementation

[0057] The embodiments described herein generally relate to wireless communication networks. Figure 3 This is a schematic overview of a wireless communication network 1. Wireless communication network 1 includes one or more RANs and one or more CNs. Wireless communication network 1 can use one or more different technologies. The embodiments described herein relate to recent technology trends of particular interest in the New Radio (NR) environment; however, the embodiments are also applicable to the further development of existing wireless communication systems, such as LTE or Wideband Code Division Multiple Access (WCDMA).

[0058] In wireless communication network 1, user equipment (UE) 10, exemplified herein as wireless devices (e.g., battery-powered IoT devices, mobile stations, non-access point (non-AP) stations (STAs), STAs, and / or wireless terminals), communicates with one or more core networks (CNs) via one or more access networks (ANs) (e.g., radio access networks (RANs)). Those skilled in the art will understand that "UE" is a non-limiting term, meaning any terminal, wireless communication terminal, user equipment, narrowband Internet of Things (NB-IoT) device, machine-type communication (MTC) device, device-to-device (D2D) terminal, or node (e.g., smartphone, laptop, mobile phone, sensor, relay, mobile tablet, or even a small base station capable of communicating with a radio network node using radio communication within an area served by that radio network node).

[0059] Wireless communication network 1 includes a radio network node 12 that provides radio coverage over a geographic area (first service area 11 or first cell) of a first radio access technology (RAT) (e.g., NR, LTE, etc.). The radio network node 12 may be a transmitting and receiving point (e.g., an access node), an access controller, a base station (e.g., a radio base station, such as a gNodeB (gNB), evolved NodeB (eNB, eNodeB), NodeB, base transceiver station, radio remote unit, access point base station, base station router, wireless area network (WLAN) access point or access point station (AP STA), a transmission device of a radio base station, a stand-alone access point, or any other network element capable of communicating with wireless devices within the service area served by the radio network node, depending on, for example, the first radio access technology and the terminology used). The radio network node 12 may be referred to as the first radio network node or the serving radio network node, wherein the service area may be referred to as the serving cell, and the serving network node may communicate with the UE in the form of DL transmissions to the UE and UL transmissions from the UE. It should be noted that the service area may be represented as a cell, beam, beam group, etc., to define the radio coverage area.

[0060] like Figure 4 As shown, radio network node 12 may include a central unit 1201 (e.g., an O-CU including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a distributed unit 1202 (e.g., an O-DU) having one or more processing units (PUs), and a radio unit 1203 (e.g., an O-RU including a non-static endpoint (EP) and one or more static endpoints (SEPs). Radio network node 12 may also include a RAN intelligent controller (near real-time or non-real-time) hosting software or software plugins, such as a near real-time control application (e.g., xApp) or a non-real-time control application (e.g., rApp) or any combination thereof.

[0061] By modifying the M-plane specification, CUS specification, and WG4 YANG model, multiple low-level t[r]x endpoints can be created to refer to the same static low-level t[r]x endpoint.

[0062] The embodiments described herein can allow multiple low-level t[r]x endpoints to be configured to point to the same static low-level t[r]x endpoint. This can be understood as enabling multiple eAxC-IDs with different DU-Port-IDs to be assigned to a data layer. DU1202 can route data and / or messages to different processing units at each transmission time interval (TTI) or at other granularities based on traffic load conditions. As previously mentioned, extended antenna carrier (eAxC) can be understood to refer to the data stream of a single antenna or the spatial stream of a single carrier in a single sector.

[0063] Now refer to Figure 5 The flowchart shown illustrates an embodiment of a method performed by a wireless communication network (e.g., wireless communication network 1). Figure 5 Schematic combined signaling schemes and flowcharts according to some embodiments herein are shown. This method can be understood as being used to process communications in a wireless communication network (e.g., wireless communication network 1). This method can be understood as being computer-implemented.

[0064] Wireless communication network 1 can be understood to include DU 1202 and RU 1203.

[0065] In some embodiments, the wireless communication network 1 may support New Radio (NR) or operate under NR.

[0066] The method includes one or more of the following actions. In a particular embodiment, the method may include action 503. In some embodiments, all actions may be performed. It should be noted that the examples herein are not mutually exclusive. Where applicable, one or more embodiments may be combined. Components from one embodiment may be assumed by default to exist in another embodiment, and how these components can be used in other exemplary embodiments will be apparent to those skilled in the art. For the sake of simplicity, not all possible combinations have been described. Figure 5 The document describes a non-limiting example of a method performed by a wireless communication network 1. In some embodiments, it can be performed in accordance with... Figure 5 The actions are executed in different sequences as shown.

[0067] Action 501. RU 1203 may report an instruction to DU 1202, instructing RU 1203 to map a static endpoint to two or more non-static endpoints. A static endpoint can be understood as representing a data stream of a carrier. Each of the two or more non-static endpoints may have a defined logical path to DU 1202 for transmitting data from the data stream.

[0068] Action 502.DU 1202 can determine the configuration of RU 1203 for processing data streams (layers).

[0069] Action 503. DU 1202 configures RU 1203 to map to one static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between DU 1202 and RU 1203 for transmitting data in a data stream. Therefore, DU 1202 can configure RU 1203 to process a carrier based on this instruction, and can map a data layer to multiple logical paths to the PU for transmitting data in a data stream. As an example, multiple low-level t[r]x endpoints can be configured to refer to the same static low-level t[r]x endpoint.

[0070] The configuration in action 503 can be based on the received instructions.

[0071] According to the examples in the embodiments described herein, it is possible to map multiple low-level endpoints to a single static endpoint. This can be understood as maintaining the layer and spatial flow relationship with the static endpoint. A low-level endpoint can be understood as representing a logical path used to send data to a processing entity in the DU.

[0072] RU_Port_ID can be understood as specifying logical flows such as data layer or space streams and logical flows such as separate parameter sets (e.g., PRACH or signaling channels that require special antenna assignment, such as sounding reference signals (SRS)).

[0073] In the uplink, RU-PORT-ID can represent either the layer ID or the spatial stream ID.

[0074] All low-level endpoints that can be associated with a static endpoint may need to have the same RU-PORT-ID, CC-ID, and BAND-SECTOR-ID. Furthermore, these low-level endpoints can be understood as serving a data layer.

[0075] Action 504. DU 1202 can also detect the load of one or more data streams (layers). As an example, DU 1202 can analyze the load of one or more data streams (e.g., one or more data streams between DU 1202 and RU 1203).

[0076] Action 505. DU 1202 can then determine the service guiding the data flow, such as performing service actions on data from a static endpoint among two or more processing units at DU 1202. DU 1202 can, for example, assign data processing from one of the two or more non-static endpoints to a first PU and data processing from the other non-static endpoint to a second PU. DU 1202 can perform service actions, such as load balancing actions to balance services.

[0077] Therefore, RU 1203 can map data from one layer of a transmit and / or receive endpoint of RU 1203 to be processed by multiple processing units of DU 1202.

[0078] The defined logical path for transmitting the data stream of a static endpoint can be between the two or more processing units of DU 1202 and RU1203.

[0079] Performing business actions may include deciding which of the two or more processing units (PUs) receives the next group.

[0080] Business actions can be performed based on the analyzed load.

[0081] Action 506. DU 1202 may send a control (C) plane message for configuring RU 1203, depending on the service action. DU 1202 may send a 506 control message, which includes an ID indicating a non-static endpoint for the data used in the one or more data flows. DU 1202 may send a control (C) plane message to RU 1203, which includes an endpoint identifier (ID) indicating a non-static endpoint, and the endpoint ID includes a PU ID corresponding to the determined PU.

[0082] Action 507. RU 1203 can send U-plane messages, such as U-plane packets, to DU 1202 using the indicated non-static endpoint.

[0083] Action 508. DU 1202 can then guide the group to the PU based on the determined results.

[0084] Since static low-level t[r]x endpoints can be understood as representing processing capabilities at the data layer, RU 1203 can be understood as not needing to consider the supported DU architecture when reporting supported static low-level t[r]x endpoints. This approach can be understood as eliminating the dependency between O-RU and O-DU architectures.

[0085] According to the embodiments described herein, the WG4 YANG model may need to be updated.

[0086] Because the instance is required to be understood as false, the low-level t[r]x endpoint may have a different name than its associated static low-level tx endpoint.

[0087] You can add a static ep name for a leaf node. In this way, several low-level t[r]x endpoints can be created and refer to the same static low-level t[r]x endpoint. It can be understood that the following examples for low-level tx endpoints can also be used for low-level rx endpoints.

[0088]

[0089] Figure 6 This is a schematic diagram depicting a non-limiting example of the configuration of an O-RU according to embodiments of this document. Specifically, Figure 6 The diagram depicts the mapping between static low-level rx endpoints in the O-RU, the low-level rx endpoints, and processing entities in the O-DU, as well as the data direction in the UL (indicated by arrows at the bottom of the figures). In the example shown, for 8 layers, if each layer's data is to be processed by 2 processing entities, then 8 static endpoints may be required. Each static endpoint can be understood as representing data in a spatial flow (e.g., a layer). Embodiments in this paper can be implemented by having multiple low-level rx endpoints (in...) Figure 6 In a non-restrictive example, a solid white box and a dotted box are configured to refer to the same static low-level rx endpoint (depicted as a black box), mapping data from one layer of a receiving endpoint of the RU to be processed by multiple processing units of the DU (in this case, processing entity 1 and processing entity 2). A low-level endpoint can be understood as representing a logical path used to send data to a processing entity in the DU. As mentioned earlier, in the uplink, the RU-PORT-ID can represent a layer ID or a spatial stream ID. All low-level endpoints that can be associated with a static endpoint may need to have the same RU-PORT-ID, CC-ID, and BAND-SECTOR-ID. And these low-level endpoints can be understood as serving a data layer. Figure 6 In a non-limiting example, each low-level rx endpoint depicted as a white box sends data in the UL to processing entity 1, while each low-level rx endpoint depicted as a dotted box sends data in the UL to processing entity 2 via a single processing element or transport stream (stream 1). This can be understood as enabling multiple eAxC-IDs with different DU-Port-IDs to be assigned to a data layer. Based on traffic load conditions, the DU can thus be able to direct data and / or messages to different DU processing units. Therefore, the embodiments described herein can be understood, for example, to achieve more flexible load balancing on the DU side.

[0090] Figure 7 This is a schematic diagram depicting another non-limiting example of the configuration of an O-RU according to embodiments of this document. Specifically, Figure 7The mapping between static low-level TX endpoints in the O-RU, low-level TX endpoints, and processing entities in the O-DU, as well as the data direction in the DL, is depicted (indicated by the arrows at the bottom of the figure). In the example shown, the O-DU has two distinct load-sharing domains accessible via different processing elements, each load-sharing domain comprising two distinct processing entities: processing entities 1.1 and 1.2 in load-sharing domain 1, and processing entities 2.1 and 2.2 in load-sharing domain 2. Figure 7 The unrestricted example depicts 8 layers. It may require 8 static tx endpoints. Figure 7 The text describes the data as a solid black box. Each static TX endpoint can be understood as representing a layer of spatial flow. According to embodiments of this document, data from the same layer can be processed by multiple processing units of the DU and mapped to the same static low-level TX endpoint. In this particular non-limiting example, data from layers 1, 2, and 3 are processed by processing entities 1.1 and 1.2 in the load sharing domain 1, and each layer can be mapped to two different low-level TX endpoints (in...). Figure 7 In a non-restrictive example (a solid white box and a dotted box), for layers 4 through 8, each low-level TX endpoint depicted as a white box receives data from the DL from processing entity 2.1, while each low-level TX endpoint depicted as a dotted box receives data from the DL from processing entity 2.2. Similarly, data for each layer is mapped to the same static low-level TX endpoints. Low-level endpoints can be understood as representing logical paths used for sending and receiving data. Low-level TX endpoints receiving data from layers 1 through 3 receive data from the DL via a single processing element or transport stream (stream 1). Low-level TX endpoints receiving data from layers 4 through 8 receive data from the DL via a single processing element or transport stream (stream 2). All low-level endpoints that can be associated with a static endpoint may need to have the same RU-PORT-ID, CC-ID, and BAND-SECTOR-ID. And these low-level endpoints can be understood as serving a single data layer. Depending on the workload, the DU may be able to direct data and / or messages to different DU processing units. Therefore, the embodiments described herein can be understood as, for example, achieving more flexible load balancing on the DU side.

[0091] Now refer to Figure 8 The flowcharts shown illustrate method actions performed by DU 1202 for processing communications in wireless communication network 1 according to various embodiments. These actions need not be performed in the order stated below, but can be performed in any suitable order. Dashed boxes indicate optional features.

[0092] This method can be understood as being implemented by a computer.

[0093] The method includes one or more of the following actions. In a particular embodiment, the method includes action 803. In some embodiments, all actions may be performed. It should be noted that the examples herein are not mutually exclusive. Where applicable, one or more embodiments may be combined. Components from one embodiment may be assumed by default to exist in another embodiment, and how these components can be used in other exemplary embodiments will be apparent to those skilled in the art. For the sake of simplicity, not all possible combinations have been described.

[0094] Regarding the actions described for wireless communication network 1, the detailed descriptions of some of the following contents correspond to the same contents provided above, and therefore will not be repeated here for the sake of simplicity.

[0095] Action 801. DU 1202 may receive an indication from RU 1203. This indication (value or index) may indicate that RU 1203 is capable of mapping a static endpoint (representing a data stream of a carrier) to two or more non-static endpoints (each non-static endpoint has a defined logical path to the DU for transmitting data of the data stream). This indication may be a report message, a capability message, etc.

[0096] Action 802.DU 1202 can determine the configuration of RU 1203 for processing data streams (layers).

[0097] Action 803. DU 1202 configures RU 1203 to map to one static endpoint among two or more non-static endpoints, each non-static endpoint having a defined logical path between DU 1202 and RU 1203 for transmitting data stream data. That is, the data stream data of a static endpoint. Therefore, DU 1202 can configure RU 1203 to process the carrier based on this indication, i.e., configuration 803 can be based on the received indication, and a data layer can be mapped to multiple logical paths to PU for transmitting data stream data. As an example, multiple low-level t[r]x endpoints can be configured to refer to the same static low-level t[r]x endpoint.

[0098] Action 804. DU 1202 can analyze the load of one or more data streams. DU 1202 can also detect the load of one or more data streams (layers). That is, the load of one or more data streams between DU 1202 and RU 1203. For example, detecting whether the load exceeds a set threshold.

[0099] Action 805. DU 1202 can then perform service actions on the data of a static endpoint between two or more processing units at DU 1202. DU 1202 can, for example, assign data processing of one of the two or more non-static endpoints to a first PU and data processing of another non-static endpoint to a second PU. For example, when a criterion is met, DU 1202 can bootstrap services (or packets) at the data layer between two or more PUs. This criterion can be load-related. DU 1202 can perform service actions, such as load balancing actions to balance services. DU 1202 can bootstrap services using C-plane messages.

[0100] In some examples, business actions can be performed based on the analyzed load.

[0101] DU 1202 can send a C-plane message with an ID indicating the EP ID to RU 1203. For example, DU 1202 can determine which PU receives the next packet. DU 1202 can then select a non-static endpoint, such as a low-level endpoint (eAxC-id), and send a C-plane message to RU 1203. The C-plane message can include an eAxC-id value indicating the PU ID or a portion of the DU-Port-ID indicating the PU ID. Therefore, DU 1202 can bootstrap traffic using a C-plane message with ecpriRtcid (the expected value of the eAxC-id of the low-level endpoint).

[0102] DU 1202 can receive user plane (U plane) messages from RU 1203 using the indicated non-static endpoint. DU 1202 can then direct the data to the indicated PU.

[0103] Therefore, in some examples, performing a business action may include: determining which of the two or more processing units (PUs) receives the next packet; and sending a C-plane message including the endpoint ID to RU 1203. The endpoint ID may indicate a non-static endpoint. The PU ID included in the endpoint ID may correspond to the determined PU.

[0104] Therefore, DU 1202 can send control plane messages for configuring CU 1203 based on service actions. DU 1202 can send control messages that include an ID indicating the EP / PUID used for using / processing one or more data streams.

[0105] Now refer to Figure 9The flowcharts shown illustrate method actions performed by RU 1203 for processing communications in wireless communication network 1 according to various embodiments. These actions need not be performed in the order stated below, but can be performed in any suitable order. Dashed boxes indicate optional features.

[0106] This method can be understood as being implemented by a computer.

[0107] The method includes one or more of the following actions. In a particular embodiment, the method includes action 902. In some embodiments, all actions may be performed. It should be noted that the examples herein are not mutually exclusive. Where applicable, one or more embodiments may be combined. Components from one embodiment may be assumed by default to exist in another embodiment, and how these components can be used in other exemplary embodiments will be apparent to those skilled in the art. For the sake of simplicity, not all possible combinations have been described.

[0108] Regarding the actions described for wireless communication network 1, the detailed descriptions of some of the following contents correspond to the same contents provided above, and therefore will not be repeated here for the sake of simplicity.

[0109] Action 901. RU 1203 may report an indication to DU 1202. That is, RU 1203 may send an indication of capability. This indication (value or index) may indicate that RU 1203 is capable of mapping a static endpoint (representing a data stream of a carrier) to two or more non-static endpoints (each non-static endpoint has a defined logical path to the DU for transmitting data of the data stream). This indication may be a report message, a capability message, etc.

[0110] Action 902. RU 1203 receives configuration data from DU 1202. This configuration data configures RU 1203 to map to one static endpoint among two or more non-static endpoints, each non-static endpoint having a defined logical path between DU and RU 1203 for transmitting data streams. That is, the data stream data of one static endpoint. Therefore, RU 1203 can be configured to process a carrier based on reported indications and can map a data layer to multiple logical paths to PU for transmitting data streams. As an example, multiple low-level t[r]x endpoints can be configured to refer to the same static low-level t[r]x endpoint. Therefore, RU 1203 can map data of one layer from one transmit and / or receive endpoint of RU 1203 to be processed by multiple processing units of DU 1202.

[0111] Action 903. RU 1203 may, for example, receive control plane messages for configuring RU 1203 based on service actions. RU 1203 may receive control messages that include an ID indicating the EP / PUID used to process one or more data streams. As an example, RU 1203 may receive C-plane messages from DU 1202. C-plane messages may include an eAxC-id value indicating the PU ID or a portion of the DU-Port-ID indicating the PU ID.

[0112] C-plane messages may include endpoint IDs. An endpoint ID may indicate a non-static endpoint. The PU ID included in the endpoint ID may correspond to a PU in one or more processing units used to process one or more data streams. It is understood that an endpoint ID may indicate a non-static endpoint, and a non-static endpoint may in turn correspond to a static endpoint.

[0113] Action 904. RU 1203 can then use one of the two or more non-static endpoints (i.e., the indicated non-static endpoint) to send a U-plane message to DU 1202.

[0114] The WG4 M-plane specification may need to be updated to clarify the concepts according to the embodiments described herein.

[0115] The WG4 CUS specification may need to be updated to account for the O-DU behavior according to the embodiments described herein. The eAxC definition may also need to be updated according to the embodiments described herein.

[0116] The WG4 YANG model may need to be updated according to the embodiments described in this article.

[0117] An alternative to mapping a static endpoint to multiple low-level endpoints is to configure multiple eAxC_IDs for the low-level endpoints. This maintains a one-to-one relationship between the static endpoint and the low-level endpoints.

[0118] These eAxC_IDs assigned to the same low-level endpoint have the same BandSector_ID, CC_ID, and RU_Port_ID values, differing only in the DU_Port_ID value. The O-RU may need to declare that it supports configuring multiple eAxC_IDs for a single low-level endpoint, and that the O-DU supports configuring multiple eAxC_IDs for a single low-level endpoint based on the load balancing of data flows across its processing entities.

[0119] In the sliding process for O-RU and O-DU Figure 8 and Figure 9This still relates to the alternative approach. C-plane information is still used to guide traffic. Instead of implying the use of different low-level endpoints for different processing entities, different eAxC_ID values ​​are used to indicate which DU processing entity intends to process the data. For UL, the O-RU forming a U-plane message will copy the eAxC_ID used in the received C-plane message, and in this way, messages sent to the DU will be routed to the correct DU processing entity. For DL, to deliver data streams processed in DU processing entities based on load balancing actions, C-plane and U-plane messages can be sent to the O-RU using an eAxC_ID with a DU_Port_ID value to reflect the location within the DU where the data stream is processed.

[0120] Currently, it is assumed that each endpoint (lower-level endpoint) has only one eAxC_ID. In this new manner, lower-level endpoints will have multiple eAxC_IDs. The CU plane specification needs to be updated to reflect this by modifying the definitions of endpoints and / or eAxC_IDs. Not only will the eAxC_ID be the identifier of the data flow (layer or spatial flow), but it will also include routing information from the DU regarding which DU entity the C-plane and U-plane messages are intended to process. Furthermore, multiple eAxC_IDs with the same BandSector_ID, CC_ID, and RU_Port_ID can affect a single data flow (layer or spatial flow).

[0121] The M-plane specification and YANG model need to be updated. Lower-level endpoints can be configured with an additional eAxC_ID, or the endpoint can use DU_Port_Id. Since C-plane and U-plane messages use the full-format eAxC_ID, both O-DU and O-RU need to know the full format of the eAxC_ID. If the full-format eAxC_ID is not configured, it needs to be exported.

[0122] Figure 10 This is a block diagram depicting a DU 1202 for processing communications in a wireless communication network 1 according to an embodiment of the present document.

[0123] This document includes several embodiments. Components from one embodiment may be assumed by default to exist in another embodiment, and how these components can be used in other exemplary embodiments will be apparent to those skilled in the art. Regarding the operation described with respect to wireless device 130, some specific descriptions below correspond to the same references provided above, and therefore will not be repeated here.

[0124] DU 1202 may include processing circuitry 1001, such as one or more processors, configured to perform the methods described herein.

[0125] DU 1202 and / or processing circuitry 1001 can be configured to receive an indication from RU 1203. This indication (value or index) can instruct RU 1203 to map a static endpoint (representing a data stream on a carrier) to two or more non-static endpoints (each non-static endpoint having a defined logical path to the DU for transmitting data from the data stream). This indication can be a report message, capability message, etc. Configuration can be based on the received indication.

[0126] DU 1202 and / or processing circuit 1001 can be configured to determine the configuration of RU 1203 for processing data streams (layers).

[0127] DU 1202 and / or processing circuitry 1001 are configured to map RU 1203 to one static endpoint among two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU and RU for transmitting data in a data stream. Therefore, DU 1202 and / or processing circuitry 1001 can be configured to configure RU 1203 to process the carrier based on this indication, and can map a data layer to multiple logical paths to the PU for transmitting data in a data stream. As an example, multiple low-level t[r]x endpoints can be configured to refer to the same static low-level t[r]x endpoint.

[0128] DU 1202 and / or processing circuit 1001 can be configured to analyze the load of one or more data streams. That is, one or more data streams between DU 1202 and RU 1203. DU 1202 and / or processing circuit 1001 can be configured to detect the load of one or more data streams (layers). For example, detecting whether the load exceeds a set threshold.

[0129] DU 1202 and / or processing circuit 1001 can be configured to perform service actions on data from a static endpoint between two or more processing units at DU 1202. DU 1202 and / or processing circuit 1001 can be configured to assign data processing from one of the two or more non-static endpoints to a first PU and data processing from the other non-static endpoint to a second PU. DU 1202 and / or processing circuit 1001 can be configured to route data layer services (or packets) between two or more PUs. This criterion can be load-related. DU 1202 and / or processing circuit 1001 can be configured to perform service actions, such as load balancing actions for balancing services.

[0130] DU 1202 can be configured to bootstrap services using C-plane messages.

[0131] In some examples, business actions can be performed based on the analyzed load.

[0132] DU 1202 and / or processing circuitry 1001 can be configured to send a C-plane message with an ID indicating the EP ID to RU 1203. For example, DU 1202 and / or processing circuitry 1001 can be configured to determine which PU receives the next packet. DU 1202 and / or processing circuitry 1001 can then be configured to select a non-static endpoint, such as a low-level endpoint (eAxC-id), and then send a C-plane message to RU 1203. The C-plane message may include an eAxC-id value indicating the PU ID or a portion of a DU-Port-ID indicating the PU ID. Therefore, DU 1202 and / or processing circuitry 1001 can be configured to bootstrap traffic using a C-plane message with ecpriRtcid (the expected value of the eAxC-id of the low-level endpoint).

[0133] DU 1202 and / or processing circuitry 1001 can be configured to receive user plane (U-plane) messages from RU 1203. DU 1202 and / or processing circuitry 1001 can be configured to direct data to the indicated PU.

[0134] Therefore, in some examples, performing a business action may include: determining which of the two or more processing units (PUs) receives the next packet; and sending a C-plane message including the endpoint ID to RU 1203. The endpoint ID may indicate a non-static endpoint. The PU ID included in the endpoint ID may correspond to the determined PU.

[0135] Therefore, DU 1202 and / or processing circuit 1001 can be configured to send control plane messages for configuring CU 1203 based on service actions. DU 1202 and / or processing circuit 1001 can be configured to send control messages including an ID indicating the EP / PU ID for processing one or more data streams.

[0136] DU 1202 may include memory 1005. Memory 1005 includes one or more units for storing data, such as data packets, messages, configurations, capabilities, events, and applications that execute the methods disclosed herein when executed. Furthermore, DU 1202 may include a communication interface 1006, which may include, for example, a transmitter, a receiver, a transceiver, and / or one or more antennas.

[0137] The methods described herein with respect to the embodiments of DU 1202 are implemented, for example, by a computer program product 1007 or a computer program, which includes instructions (i.e., software code portions) that, when executed on at least one processor, cause the at least one processor to perform the actions described herein performed by DU 1202. The computer program product 1007 may be stored on a computer-readable storage medium 1008 (e.g., a disk, a Universal Serial Bus (USB) disk, etc.). The computer-readable storage medium 1008 on which the computer program product is stored may include instructions that, when executed on at least one processor, cause the at least one processor to perform the actions described herein performed by DU 1202. In some embodiments, the computer-readable storage medium may be a transient or non-transitory computer-readable storage medium. Therefore, embodiments herein may disclose a DU 1202 for processing communications in a wireless communication network, wherein the DU 1202 includes processing circuitry and a memory including instructions executable by the processing circuitry, thereby enabling the DU 1202 to operate to perform any of the methods herein.

[0138] Figure 11 This is a block diagram depicting an RU 1203 for processing communications in a wireless communication network 1 according to an embodiment of the present document.

[0139] This document includes several embodiments. Components from one embodiment may be assumed by default to exist in another embodiment, and how these components can be used in other exemplary embodiments will be apparent to those skilled in the art. Regarding the operation described with respect to wireless device 130, some specific descriptions below correspond to the same references provided above, and therefore will not be repeated here.

[0140] RU 1203 may include processing circuitry 1101, such as one or more processors, configured to perform the methods described herein.

[0141] RU 1203 and / or processing circuitry 1101 can be configured to report an indication to DU 1202. This indication (value or index) can indicate that RU 1203 is capable of mapping a static endpoint (representing a data stream on a carrier) to two or more non-static endpoints (each non-static endpoint having a defined logical path to the DU for transmitting data from the data stream). This indication can be a reporting message, a capability message, etc.

[0142] RU 1203 and / or processing circuitry 1101 are configured to receive configuration data from DU 1202. This configuration data maps RU 1203 to one static endpoint among two or more non-static endpoints, each non-static endpoint having a defined logical path between DU 1202 and RU 1203 for transmitting data streams. That is, the data stream data of one static endpoint. Therefore, RU 1203 and / or processing circuitry 1101 can be configured to process a carrier based on reported indications and can map a data layer to multiple logical paths to the PU for transmitting data streams. As an example, multiple low-level t[r]x endpoints can be configured to refer to the same static low-level t[r]x endpoint. Therefore, RU 1203 and / or processing circuitry 1101 can be configured to map data from one layer of a transmit and / or receive endpoint of RU 1203 to be processed by multiple processing units of DU 1202.

[0143] RU 1203 and / or processing circuitry 1101 can be configured to receive control plane messages for configuring RU 1203 based on service actions. RU 1203 and / or processing circuitry 1101 can be configured to receive control messages including an ID indicating an EP ID for processing one or more data streams. As an example, RU 1203 can receive C-plane messages from DU 1202. C-plane messages may include an eAxC-id value indicating a PU ID or a portion of a DU-Port-ID indicating a PU ID.

[0144] C-plane messages may include endpoint IDs. An endpoint ID can indicate a non-static endpoint. The PU ID included in the endpoint ID can correspond to a PU in one or more processing units used to process one or more data streams.

[0145] RU 1203 and / or processing circuit 1101 can be configured to send U-plane messages to DU 1202 using one of the two or more non-static endpoints (i.e., the indicated non-static endpoints).

[0146] RU 1203 may include memory 1105. Memory 1105 includes one or more storage units for storing data, such as data packets, capabilities, messages, indications, configurations, events, and applications that execute the methods disclosed herein when executed. Furthermore, RU 1203 may include a communication interface 1106, which may include, for example, a transmitter, a receiver, a transceiver, and / or one or more antennas.

[0147] The methods described herein with respect to the embodiments of RU 1203 are implemented, for example, by a computer program product 1107 or a computer program including instructions (i.e., software code portions) that, when executed on at least one processor, cause the at least one processor to perform the actions described herein performed by RU 1203. The computer program product 1107 may be stored on a computer-readable storage medium 1108 (e.g., a disk, a Universal Serial Bus (USB) disk, etc.). The computer-readable storage medium 1108 on which the computer program product is stored may include instructions that, when executed on at least one processor, cause the at least one processor to perform the actions described herein performed by RU 1203. In some embodiments, the computer-readable storage medium may be a transient or non-transitory computer-readable storage medium. Therefore, embodiments herein may disclose an RU 1203 for processing communications in a wireless communication network, wherein the RU 1203 includes processing circuitry and a memory including instructions executable by the processing circuitry, thereby enabling the RU 1203 to operate to perform any of the methods herein.

[0148] In some embodiments, the more general term "radio network node" is used, which can correspond to any type of radio network node or any network node that communicates with wireless devices and / or with another network node. Examples of network nodes are NodeB, MeNB, SeNB, network nodes belonging to a primary cell group (MCG) or secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node (e.g., MSR BS), eNodeB, gNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node control relay, base transceiver station (BTS), access point (AP), transmitting point, transmitting node, remote radio unit (RRU), remote radio headend (RRH), nodes in a distributed antenna system (DAS), etc.

[0149] In some embodiments, the non-limiting term wireless device or user equipment (UE) is used, and it refers to any type of wireless device that communicates with a network node in a cellular or mobile communication system and / or with another wireless device. Examples of UEs are target devices, device-to-device (D2D) UEs, UEs with proximity capabilities (aka ProSe UEs), machine-type UEs or UEs capable of machine-to-machine (M2M) communication, tablet computers, mobile terminals, smartphones, laptop embedded devices (LEEs), laptop mounted devices (LMEs), USB dongles, etc.

[0150] The embodiments are applicable to any RAT or multi-RAT system in which wireless devices receive and / or transmit signals (e.g., data), such as New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE Advanced, 5G, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications / Enhanced Data Rate GSM Evolution (GSM / EDGE), Global Microwave Interoperability Access (WiMax), or Ultra Mobile Broadband (UMB), and the above are only some of the possible implementations.

[0151] Those skilled in communication design will readily understand that functional devices or circuits can be implemented using digital logic and / or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, some or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC) or in two or more separate devices having suitable hardware and / or software interfaces. For example, several functions may be implemented on a processor shared with other functional components of a wireless device or network node.

[0152] Alternatively, some functional elements in the processing apparatus discussed may be provided using dedicated hardware, while other functional elements may be provided using hardware for executing software in combination with suitable software or firmware. Therefore, the terms "processor" or "controller" as used herein do not exclusively refer to hardware capable of executing software and may implicitly include, but are not limited to, digital signal processor (DSP) hardware and / or program or application data. Other conventional and / or custom hardware may also be included. Designers of communication equipment will understand the trade-offs in cost, performance, and maintenance among these design options.

[0153] Any suitable steps, methods, features, functions, or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers and other digital hardware (including digital signal processors (DSPs), application-specific digital logic, etc.). The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more techniques described herein. In some implementations, the processing circuitry may be used to cause corresponding functional units to perform corresponding functions according to one or an embodiment of this disclosure.

[0154] Figure 12An example of a communication system 1200 according to some embodiments is shown.

[0155] In this example, the communication system 1200 includes: a telecommunications network 1202, including an access network 1204 such as a radio access network (RAN); and a core network 1206, including one or more core network nodes 1208. The access network 1204 includes one or more access network nodes (e.g., network nodes 1210a and 1210b, exemplified as a first radio network node 12 and a second radio network node 13, where one or more nodes may be collectively referred to as network node 1210)) or any other similar 3GPP access node or non-3GPP access point. Furthermore, those skilled in the art will understand that the network nodes exemplified as entities herein are not necessarily limited to implementations provided by a single vendor and integrating the radio and baseband portions. Therefore, it should be understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, the telecommunications network 1202 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 1202 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or together with other nodes to perform one or more functions of any node in the telecommunications network 1202 (including one or more network nodes 1210 and / or core network nodes 1208).

[0156] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), RAN intelligent controllers (near real-time or non-real-time), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces), open fronthaul user plane interfaces, or open fronthaul management plane interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below) where one or more network functions are virtualized. For example, a virtualization environment may include an open cloud (O-Cloud) computing platform orchestrated by a service management and orchestration framework via an O-2 interface or equivalent technology defined by the O-RAN Alliance. Network node 1210 facilitates direct or indirect connections of user equipment (UE) 10, such as connecting UE 1212a, UE 1212b, UE 1212c, and UE 1212d (one or more of which may generally be referred to as UE 1212) to core network 1206 via one or more wireless connections.

[0157] Examples of wireless communication via wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wiring, cables, or other conductors. Furthermore, in various embodiments, communication system 1200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals (whether via wired or wireless connections). Communication system 1200 may include any type of communication, telecommunications, data, cellular, radio network, and / or other similar system, and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar system.

[0158] UE 1212 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 1210 and other communication devices. Similarly, network node 1210 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 1212 and / or with other network nodes or devices in telecommunication network 1202 to implement and / or provide network access (e.g., wireless network access) and / or to perform other functions (e.g., management) in telecommunication network 1202.

[0159] In the example shown, core network 1206 connects network node 1210 to one or more hosts (e.g., host 1216). These connections can be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1206 includes one or more core network nodes (e.g., core network node 1208), such as network node 15, which are formed together with hardware and software components. The characteristics of these components may be substantially similar to those described with respect to UEs, network nodes, and / or hosts, such that the description is generally applicable to the corresponding components of core network node 1208. Example core network nodes include the functions of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Unhiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0160] Host 1216 may be owned or under the control of a service provider other than the operator or provider of access network 1204 and / or telecommunications network 1202, and may be operated by or on behalf of the service provider. Host 1216 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0161] As a whole, Figure 12The communication system 1200 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0162] In some examples, telecommunications network 1202 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 1202 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 1202 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive IoT services to yet another UE.

[0163] In some examples, UE 1212 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 1204 according to a predetermined schedule when triggered by internal or external events or in response to a request from access network 1204. Additionally, the UE may be configured to operate in single-RAT mode, multi-RAT mode, or multi-standard mode. For example, the UE may operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0164] In this example, hub 1214 communicates with access network 1204 to facilitate indirect communication between one or more UEs (e.g., UE 1212c and / or 1212d) and network nodes (e.g., network node 1210b). In some examples, hub 1214 may be a controller, router, content source and analyzer, or any other communication device described herein relating to the UE. For example, hub 1214 may be a broadband router that enables the UE to access core network 1206. As another example, hub 1214 may be a controller that sends commands or instructions to one or more actuators of the UE. Commands or instructions may be received from the UE, network node 1210, or via executable code, scripts, procedures, or other instructions in hub 1214. As another example, hub 1214 may be a data collector that acts as a temporary storage device for UE data, and in some embodiments, may perform data analysis or other processing. As another example, hub 1214 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 1214 can retrieve VR assets, video, audio, or other media or data related to perceived information via a network node, and then provide them directly to the UE after performing local processing and / or adding additional local content. In yet another example, hub 1214 acts as a proxy server or orchestrator for the UE, particularly if one or more of the UEs are low-power IoT devices.

[0165] Hub 1214 may have a persistent / persistent or intermittent connection to network node 1210b. Hub 1214 may also allow different communication schemes and / or scheduling between hub 1214 and UEs (e.g., UEs 1212c and / or 1212d) and between hub 1214 and core network 1206. In other examples, hub 1214 is connected to core network 1206 and / or one or more UEs via a wired connection. Furthermore, hub 1214 may be configured to connect to an M2M service provider via access network 1204 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1210 while still being connected via hub 1214 through a wired or wireless connection. In some embodiments, hub 1214 may be a dedicated hub, i.e., a hub whose primary function is to route communication from network node 1210b to UE / to route communication from UE to network node 1210b. In other embodiments, the hub 1214 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node 1210b, but additionally capable of operating as a communication start point and / or endpoint for certain data channels.

[0166] Figure 13A UE 1300 according to some embodiments is illustrated. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including NB-IoT UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs.

[0167] The UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user who owns and / or operates the associated device. Alternatively, the UE may represent a device intended to be sold to or operated by a human user but which may not or may not initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended to be sold to or operated by an end user but which may be associated with or operated for the benefit of the user (e.g., a smart power meter).

[0168] UE 1300 includes processing circuitry 1302, which is operatively coupled via bus 1304 to input / output interface 1306, power supply 1308, memory 1310, communication interface 1312, and / or any other component or any combination thereof. Some UEs may utilize... Figure 13 The components shown may be all or a subset. The level of integration between components can vary depending on the UE. Furthermore, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0169] Processing circuitry 1302 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 1310 as machine-readable computer processes. Processing circuitry 1302 can be implemented as: one or more hardware-implemented state machines (e.g., implemented with discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with appropriate software; or any combination of the foregoing. For example, processing circuitry 1302 may include multiple central processing units (CPUs).

[0170] In the example, input / output interface 1306 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into UE 1300. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, directional keyboards, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0171] In some embodiments, power supply 1308 is configured as a battery or battery pack. Other types of power sources can be used, such as external power sources (e.g., power outlets), photovoltaic devices, or batteries. Power supply 1308 may also include power supply circuitry for delivering power from power supply 1308 itself and / or external power sources to various parts of UE 1300 via input circuitry or an interface such as a power cable. The delivery of power can, for example, be used for charging power supply 1308. The power supply circuitry can perform any formatting, conversion, or other modifications on the power from power supply 1308 to suit the power for the corresponding components of UE 1300 to which it is supplied power.

[0172] Memory 1310 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable magnetic tape, flash drive, etc. In one example, memory 1310 includes one or more application processes 1314, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 1316. Memory 1310 may store any one or a combination of various operating systems used by UE 1300.

[0173] The memory 1310 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC) including one or more subscriber identification modules (SIMs), such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The memory 1310 can allow the UE 1300 to access instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of manufacture, such as those utilizing a communication system, may be tangibly embodied in or contained in memory 1310, which may be or include a device-readable storage medium.

[0174] Processing circuitry 1302 can be configured to communicate with an access network or other network using communication interface 1312. Communication interface 1312 may include one or more communication subsystems and may include antenna 1322 or be communicatively coupled to antenna 1322. Communication interface 1312 may include one or more transceivers for transmission (e.g., via one or more remote transceivers capable of wireless communication with another device (e.g., another UE or a network node in the access network). Each transceiver may include transmitter 1318 and / or receiver 1320 suitable for providing network communications (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 1318 and receiver 1320 may be coupled to one or more antennas (e.g., antenna 1322) and may share circuitry, software, or firmware, or alternatively, be implemented separately.

[0175] In the illustrated embodiment, the communication functions of the communication interface 1312 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (e.g., using a Global Positioning System (GPS) to determine location), another type of communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards (e.g., IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.).

[0176] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface 1312 through a wireless connection with a network node. Data captured by the UE's sensors can be transmitted via another UE through the same wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), responsive to a triggering event (e.g., sending an alarm when humidity is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., real-time video feed of a patient).

[0177] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0178] When the UE is in the form of an Internet of Things (IoT) device, the UE can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door and window sensors, flood / humidity sensors, electronic door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device (such as heart rate monitors or remotely controlled process robots). In addition to the above... Figure 13 In addition to the other components described in the UE 1300 shown, UEs in the form of IoT devices also include circuitry and / or software depending on the intended application of the IoT device.

[0179] As another specific example, in an IoT scenario, a UE can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, this UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle (e.g., a car, bus, truck, ship, and aircraft) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0180] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, and provides the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first UE and / or the second UE can also include more than one of the functions described above. For example, the UE can include sensors and actuators, and handle data communication between both the speed sensor and the actuators.

[0181] Figure 14 A network node 1400 according to some embodiments is illustrated. As used herein, a network node refers to a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0182] Base stations can be classified based on the coverage they provide (or, in other words, their transmission power levels); therefore, depending on the coverage provided, a base station can be called a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor for control relays. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). These remote radio units can be integrated with antennas to form an antenna-integrated radio, or they can be independent of antenna integration. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0183] Other examples of network nodes include multi-transmitter point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices (e.g., MSR BS), network controllers (e.g., radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmitter points, transmitter nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved Serving Mobility Location Center (E-SMLC)) and / or minimized drive test (MDT).

[0184] Network node 1400 includes processing circuitry 1402, memory 1404, communication interface 1406, and power supply 1408. Network node 1400 may consist of multiple physically separate components (e.g., Node B components and RNC components, BTS components and BSC components, etc.), each with its own corresponding components. In some scenarios where network node 1400 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique “NodeB and RNC pair” can be considered a single, separate network node in some cases. In some embodiments, network node 1400 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 1404 exists for different RATs) and some components may be reused (e.g., the same antenna 1410 may be shared by different RATs). Network node 1400 may also include multiple sets of various components shown herein for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth wireless technologies). These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1400.

[0185] The processing circuitry 1402 may include one or more of the following: a microprocessor, a controller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or coding logic, operable to provide network node 1400 functionality, either alone or in combination with other network node 1400 components (e.g., memory 1404).

[0186] In some embodiments, the processing circuitry 1402 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1402 includes one or more of a radio frequency (RF) transceiver circuitry 1412 and a baseband processing circuitry 1414. In some embodiments, the RF transceiver circuitry 1412 and the baseband processing circuitry 1414 may be on separate chips (or chipsets), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 1412 and the baseband processing circuitry 1414 may be on the same chip or chipset, board, or unit group.

[0187] Memory 1404 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 1402. Memory 1404 may store any suitable instructions, data, or information, including computer processes, software, applications including logic, rules, codes, tables, and / or other instructions that can be executed by processing circuitry 1402 and used by network node 1400. Memory 1404 may be used to store any calculations performed by processing circuitry 1402 and / or any data received via communication interface 1406. In some embodiments, processing circuitry 1402 and memory 1404 are integrated together.

[0188] Communication interface 1406 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 1406 includes a port / terminal 1416 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface 1406 also includes radio front-end circuitry 1418, which may be coupled to antenna 1410, or in some embodiments to a portion of antenna 1410. Radio front-end circuitry 1418 includes a filter 1420 and an amplifier 1422. Radio front-end circuitry 1418 may be connected to antenna 1410 and processing circuitry 1402. Radio front-end circuitry 1418 may be configured to modulate the signal transmitted between antenna 1410 and processing circuitry 1402. Radio front-end circuitry 1418 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1418 may use a combination of filter 1420 and / or amplifier 1422 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1410. Similarly, when data is received, antenna 1410 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1418. The digital data can then be passed to processing circuitry 1402. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0189] In some alternative embodiments, network node 1400 does not include a separate radio front-end circuitry 1418; instead, processing circuitry 1402 includes radio front-end circuitry and is connected to antenna 1410. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1412 is part of communication interface 1406. In yet another embodiment, communication interface 1406 includes one or more ports or terminals 1416, radio front-end circuitry 1418, and RF transceiver circuitry 1412 as part of a radio unit (not shown), and communication interface 1406 communicates with baseband processing circuitry 1414, which is part of a digital unit (not shown).

[0190] Antenna 1410 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1410 may be coupled to radio front-end circuitry 1418 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1410 is decoupled from network node 1400 and may be connected to network node 1400 via an interface or port.

[0191] Antenna 1410, communication interface 1406, and / or processing circuitry 1402 can be configured to perform any receive operation and / or certain acquire operation described herein by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 1410, communication interface 1406, and / or processing circuitry 1402 can be configured to perform any transmit operation described herein by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0192] Power supply 1408 provides power to the various components of network node 1400 in a form suitable for the various components (e.g., at the voltage and current levels required by each respective component). Power supply 1408 may also include or be coupled to power management circuitry to supply power to the components of network node 1400 for performing the functions described herein. For example, network node 1400 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface (e.g., cable), thereby supplying power to the power circuitry of power supply 1408. As another example, power supply 1408 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0193] Implementations of network node 1400 may include more than Figure 14Additional components shown are provided to offer certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the topics described herein. For example, network node 1400 may include a user interface device to allow information to be input into and output from network node 1400. This allows users to perform diagnostic, maintenance, repair, and other management functions on network node 1400.

[0194] Figure 15 This is a block diagram of host 1500 based on the various aspects described herein, which host 1500 can be Figure 12 The embodiment of host 1216. As used herein, host 1500 can be or include various combinations of hardware and / or software, including processing resources in a standalone server, blade server, cloud-implemented server, distributed server, virtual machine, container, or server cluster. Host 1500 can provide one or more services to one or more UEs.

[0195] Host 1500 includes processing circuitry 1502 operably coupled via bus 1504 to input / output interface 1506, network interface 1508, power supply 1510, and memory 1512. Other components may be included in other embodiments. The features of these components may be substantially similar to those with respect to the previous figures (e.g., Figure 13 and Figure 14 The characteristics described for the device make its description generally applicable to the corresponding components of the host 1500.

[0196] Memory 1512 may include one or more computer programs, including data 1516 and one or more host applications 1514. Data 1516 may include user data, such as data generated by the UE for the host 1500, or data generated by the host 1500 for the UE. Embodiments of host 1500 may utilize only a subset or all of the illustrated components. Host application 1514 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for various categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). Host application 1514 may also provide user authentication and authorization checks and may periodically report health status, routing, and content availability to a central node (e.g., a device in the core network or a device at the edge of the core network). Therefore, host 1500 can select and / or indicate different hosts for over-the-top services for the UE. Host application 1514 can support various protocols, such as HTTP Live Streaming (HLS), Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0197] Figure 16 This is a block diagram illustrating a virtualization environment 1600, in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualization hardware platform, storage devices, and networking resources. As used herein, virtualization can be applied to any device or component thereof described herein, and involves at least a portion of its functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1600 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes can be fully virtualized. In some embodiments, the virtualization environment 1600 includes components defined by the O-RAN Alliance, such as an open cloud environment orchestrated via an O-2 interface by a service management and orchestration framework.

[0198] Application 1602 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) operates in a virtualized environment Q400 to implement some of the features, functions, and / or benefits of some embodiments disclosed herein.

[0199] Hardware 1604 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1606 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1608a and 1608b (one or more of which may generally be referred to as VM 1608), and / or perform any functions, features, and / or benefits described in relation to some embodiments described herein. Virtualization layer 1606 can present a virtual operating platform to VM 1608, which appears as network hardware.

[0200] VM 1608 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be operated by a corresponding virtualization layer 1606. Different embodiments of instances of virtual device 1602 can be implemented on one or more VMs 1608, and these implementations can be carried out in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify numerous network device types into industry-standard high-capacity server hardware, physical switches, and physical storage devices that can reside in data centers and customer residential equipment (CPE).

[0201] In the context of NFV, VM 1608 can be a software implementation of a physical machine, whose operating procedures are executed as if on a physical, non-virtualized machine. Each VM 1608, along with the hardware portion of hardware 1604 that executes that VM (whether it is dedicated hardware for that VM and / or hardware shared by that VM with other VMs), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling the operation of one or more VMs 1608 on top of hardware 1604 and corresponds to the specific network function of application 1602.

[0202] Hardware 1604 can be implemented in a standalone network node with general or specific components. Hardware 1604 may implement some functions via virtualization. Alternatively, hardware 1604 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed by management and orchestration 1610, which in particular oversees the lifecycle management of application 1602. In some embodiments, hardware 1604 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, some signaling may be provided using a control system 1612, which may alternatively be used for communication between hardware nodes and radio units.

[0203] Figure 17 A communication diagram is shown illustrating how host 1702 communicates with UE 1706 via network node 1704 through a partial wireless connection, according to some embodiments. Reference will now be made to... Figure 17 Describe the UE discussed in the preceding paragraphs (e.g., Figure 12 UE1212a and / or Figure 13 UE 1300), network nodes (e.g., Figure 12 Network node 1210a and / or Figure 14 Network node 1400) and host (e.g., Figure 12 Host 1216 and / or Figure 15 Example implementations of the host 1500 according to various embodiments.

[0204] Similar to host 1500, embodiments of host 1702 include hardware such as a communication interface, processing circuitry, and memory. Host 1702 also includes software stored in or accessible by host 1702 and executable by the processing circuitry. This software includes a host application operable to provide services to a remote user, such as UE 1706 connected via an over-the-top (OTT) connection 1750 extending between UE 1706 and host 1702. When providing services to a remote user, the host application can provide user data transmitted using OTT connection 1750.

[0205] Network node 1704 includes hardware that enables it to communicate with host 1702 and UE 1706. Connection 1760 can be a direct connection or via a core network (such as...). Figure 12The connection to the core network (1206) and / or one or more other intermediate networks (e.g., one or more public, private, or hosted networks). For example, an intermediate network could be a backbone network or the Internet.

[0206] UE 1706 includes hardware and software, the software being stored in or accessible by UE 1706 and executable by the UE's processing circuitry. This software includes client applications (e.g., a web browser or operator-specific "application") operable to provide services to human or non-human users via UE 1706, supported by host 1702. In host 1702, the executing host application can communicate with the executing client application via OTT connection 1750, which terminates between UE 1706 and host 1702. When providing services to a user, the UE's client application can receive request data from the host application of the host and, in response to the request data, provide user data. OTT connection 1750 can send both request data and user data. The UE's client application can interact with the user to generate user data provided to the host application via OTT connection 1750.

[0207] OTT connection 1750 can be extended via connection 1760 between host 1702 and network node 1704 and via wireless connection 1770 between network node 1704 and UE 1706 to provide connectivity between host 1702 and UE 1706. Connection 1760 and wireless connection 1770, which provide OTT connection 1750, have been abstractly drawn to illustrate communication between host 1702 and UE 1706 via network node 1704, without explicitly involving any intermediate devices and the precise routing of messages via these devices.

[0208] As an example of sending data via OTT connection 1750, in step 1708, host 1702 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1706. In other embodiments, the user data is associated with UE 1706, which shares data with host 1702 without explicit human interaction. In step 1710, host 1702 initiates a transmission to UE 1706 carrying user data. Host 1702 may initiate the transmission in response to a request sent by UE 1706. This request may be caused by human interaction with UE 1706 or by the operation of a client application executed on UE 1706. Based on the teachings of the embodiments described throughout this disclosure, this transmission may be carried out via network node 1704. Therefore, in step 1712, based on the teachings of the embodiments described throughout this disclosure, network node 1704 sends the user data carried in the transmission initiated by host 1702 to UE 1706. In step 1714, UE 1706 receives user data carried in the transmission, which can be performed by a client application running on UE 1706, which is associated with a host application running by host 1702.

[0209] In some examples, UE 1706 executes a client application that provides user data to host 1702. User data can be provided as a response to data received from host 1702. Therefore, in step 1716, UE 1706 can provide user data, which can be done by executing the client application. When providing user data, the client application may also consider user input received from a user via the input / output interface of UE 1706. Regardless of the specific manner in which user data is provided, in step 1718, UE 1706 initiates a transmission of user data to host 1702 via network node 1704. In step 1720, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1704 receives user data from UE 1706 and initiates the transmission of the received user data to host 1702. In step 1722, host 1702 receives the user data carried in the transmission initiated by UE 1706.

[0210] One or more embodiments in various examples improve the performance of the OTT service provided to the UE 1706 using OTT connection 1750, in which wireless connection 1770 forms the final part. More specifically, the teachings of these embodiments can improve data processing and latency, thereby providing benefits such as reduced user wait time, better responsiveness, and / or extended battery life.

[0211] In the example scenario, host 1702 can collect and analyze plant status information. As another example, host 1702 can process audio and video data that may have been retrieved from the UE for creating mappings. As another example, host 1702 can collect and analyze real-time data to help control vehicle congestion (e.g., control service lights). As another example, host 1702 can store surveillance video uploaded by the UE. As another example, host 1702 can store or control access to media content such as video, audio, VR, or AR, which can be broadcast, multicast, or unicast to the UE. As other examples, host 1702 can be used for energy pricing, remote control of non-time-critical power loads to balance generation demand, location services, presentation services (e.g., compiling charts based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0212] In some examples, a measurement process may be provided for the purpose of monitoring improved data rates, latency, and other factors in one or more embodiments. Optional network functions may also be present for reconfiguring the OTT connection 1750 between host 1702 and UE 1706 in response to changes in measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host 1702 and / or UE 1706. In some embodiments, sensors (not shown) may be deployed in or associated with other devices traversed by the OTT connection 1750; the sensors may participate in the measurement process by providing values ​​of the monitored quantities exemplified above or by providing values ​​of other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1750 may include message formats, retransmission settings, preferred routing, etc.; reconfiguration does not require a direct change in the operation of network node 1704. Such processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates host 1702's measurement of throughput, propagation time, latency, etc. Measurements can be achieved by having the software use an OTT connection 1750 to send messages (especially empty or "virtual" messages) while monitoring propagation time, errors, etc.

[0213] While the computing devices described herein (e.g., UE, network node, host) may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information in ways such as: converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0214] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuitry, for example, in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functions are not limited to the individual processing circuitry or other components of the computing device, but are enjoyed holistically by the computing device and / or generally by the end user and wireless network.

[0215] Benefiting from the foregoing description and the accompanying drawings, those skilled in the art will be able to conceive of modifications and other embodiments of the disclosed embodiments. Therefore, it should be understood that this embodiment is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terminology may be used herein, it is for general and descriptive purposes only and not for limiting purposes.

[0216] Examples related to the embodiments in this article

[0217] A1. A method performed by a distributed unit for processing communications in a wireless communication network, the method comprising:

[0218] - Configure the RU to be mapped to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU and the RU for transmitting data streams from the static endpoint.

[0219] A2. The method described in Example A1 further includes:

[0220] - Receive an instruction from RU 1203, wherein the instruction indicates that RU 1203 is capable of mapping a static endpoint to two or more non-static endpoints.

[0221] A3. The method described according to any one of Examples A1 to A2 further includes:

[0222] - Analyze the load of one or more data streams.

[0223] A4. The method described according to any one of Examples A1 to A3 further includes:

[0224] - Perform business actions on data from a static endpoint across two or more processing units at DU 1202.

[0225] A5. According to the method described in Example A4, performing the business action includes: determining which PU receives the next packet; and sending a control plane (C plane) message including the endpoint ID or PU ID to RU 1203.

[0226] B1. A method performed by a radio unit (RU) for processing communications in a wireless communication network, the method comprising:

[0227] - Receive configuration data from DU, wherein the configuration data is a configuration of RU to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between DU and RU for transmitting data streams of the static endpoint.

[0228] B2. The method described according to Example B1 further includes:

[0229] - Report an instruction to DU 1202, wherein the instruction instructs RU 1203 to map a static endpoint to two or more non-static endpoints.

[0230] B3. The method according to any one of Examples B1 to B2 further includes:

[0231] - Receive control plane messages for configuring CU 1203, which include an ID indicating the EP / PU ID for processing one or more data streams.

[0232] B4. The method according to any one of Examples B1 to B3 further includes:

[0233] - Send U-plane messages to DU 1202 using a non-static endpoint.

[0234] C1. A distributed unit for processing communications in a wireless communication network, wherein the distributed unit is configured to:

[0235] Configure a RU to be mapped to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU and the RU for transmitting data streams from the static endpoint.

[0236] C2. The distributed unit according to Example C1, wherein the distributed unit is configured to perform the method described according to any one of Examples A2 to A5.

[0237] D1. A radio unit (RU) for processing communications such as data in a wireless communication network, wherein the radio unit is configured to:

[0238] Receive configuration data from DU, wherein the configuration data is a configuration of RU mapped to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between DU and RU for transmitting data streams of the static endpoint.

[0239] D2. The radio unit according to Example D1, wherein the radio unit is configured to perform the method according to any one of Examples B2 to B4.

[0240] Further examples relating to the embodiments described herein (e.g., alternatives to the embodiments described herein) may relate to:

[0241] E1. A method performed by a distributed unit (DU) (1202) for processing communications in a wireless communication network (1), the method comprising:

[0242] - Configure (803) for radio unit (RU) (1203) for two static endpoints for each layer, stream or data stream, each static endpoint being mapped to a non-static endpoint, each non-static endpoint having a defined logical path between DU (1202) and RU (1203) for transmitting data of one of the two static endpoints for the layer, stream or data stream.

[0243] E2. The radio unit according to Example D1, wherein non-static endpoints transmitting data of the same data stream, layer or data stream have common identifier (ID) values ​​of BandSector_ID, CC_ID and RU_Port_ID and corresponding different values ​​of DU_Port_ID.

[0244] Figure 2 The text describes unrestricted examples of E1 and E2.

Claims

1. A method performed by a distributed unit DU (1202) for processing communications in a wireless communication network (1), the method comprising: - Configure (803) for radio unit RU (1203) to map to one static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU (1202) and the RU (1203) for transmitting data of the data stream of the one static endpoint.

2. The method of claim 1, further comprising one or more of the following operations: - Receive (801) an instruction from the RU (1203), wherein, The instruction indicates that the RU (1203) can map one static endpoint to two or more non-static endpoints, and wherein the configuration (803) is based on the received instruction; and - Determine (802) the configuration of the RU (1203) for processing data streams.

3. The method according to any one of claims 1 to 2, further comprising: -Analyze (804) the load of one or more data streams between the DU (1202) and the RU (1203).

4. The method according to any one of claims 1 to 3, further comprising: - Between two or more processing units at the DU (1202), perform (805) business actions on the data of the one static endpoint.

5. The method according to claim 4, wherein, Performing the business action includes: determining which of the two or more processing units (PUs) will receive the next packet; and sending a control plane "C plane" message to the RU (1203), the C plane message including an endpoint identifier "ID" indicating a non-static endpoint, and the endpoint ID including the PU ID corresponding to the determined PU.

6. The method according to claim 3 and any one of claims 4 to 5, wherein, The execution of the business action is based on the analyzed load.

7. A method performed by a radio unit RU (1203) for processing communications in a wireless communication network (1), the method comprising: - Receive (902) configuration data from the distributed unit DU (1202), wherein the configuration data is a configuration mapping of the RU (1203) to a static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU (1202) and the RU (1203) for transmitting data streams of the static endpoint.

8. The method according to claim 7, further comprising: - Report (901) to the DU (1202), wherein the instruction indicates that the RU (1203) is capable of mapping a static endpoint to two or more non-static endpoints.

9. The method according to any one of claims 7 to 8, further comprising: - Receive (903) a control plane "C plane" message for configuring the RU (1203), the C plane message including an endpoint identifier "ID" indicating the one non-static endpoint, and the endpoint ID including a PU ID corresponding to the PU among the two or more processing units (PUs) for processing one or more data streams.

10. The method according to any one of claims 7 to 9, further comprising: - Send a (904) User plane "U plane" message to the DU (1202) using one of the two or more non-static endpoints.

11. A distributed unit DU (1202) for processing communications in a wireless communication network (1), wherein, The distributed unit is configured as follows: - Configure RU (1203) to map to one static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between DU (1202) and RU (1203) for transmitting data of the data stream of the one static endpoint.

12. The DU (1202) according to claim 11 is further configured to perform one or more of the following operations: - Receive an instruction from the RU (1203), wherein, The instruction indicates that the RU (1203) can map one static endpoint to two or more non-static endpoints, and wherein the configuration is based on the received instruction; and - Determine the configuration of the RU (1203) for processing data streams.

13. The DU (1202) according to any one of claims 11 to 12 is further configured to: - Analyze the load of one or more data streams between the DU (1202) and the RU (1203).

14. The DU (1202) according to any one of claims 11 to 13 is further configured to: - Perform business actions on the data of the one static endpoint between two or more processing units at the DU (1202).

15. The DU (1202) according to claim 14, wherein, Performing the business action includes: determining which of the two or more processing units (PUs) will receive the next packet; and sending a control plane "C plane" message to the RU (1203), the C plane message including an endpoint identifier "ID" indicating a non-static endpoint, and the endpoint ID including the PU ID corresponding to the determined PU.

16. The DU (1202) according to claim 13 and any one of claims 14 to 15, wherein, The execution of the business action is based on the analyzed load.

17. A radio unit RU (1203) for processing communications such as data in a wireless communication network (1), wherein, The distributed unit is configured as follows: - Receive configuration data from DU (1202), Wherein, the configuration data is the configuration mapping of the RU (1203) to one static endpoint of two or more non-static endpoints, each non-static endpoint having a defined logical path between the DU (1202) and the RU (1203) for transmitting the data stream of the one static endpoint.

18. The RU (1203) according to claim 17 is further configured to: - Report instructions to the DU (1202), wherein, The instruction indicates that the RU (1203) is capable of mapping a static endpoint to two or more non-static endpoints.

19. The RU (1203) according to any one of claims 17 to 18 is further configured to: - Receive a control plane "C plane" message for configuring the RU (1203), the C plane message including an endpoint identifier "ID" indicating the one non-static endpoint, and the endpoint ID including a PU ID corresponding to the PU among the two or more processing units (PUs) for processing one or more data streams.

20. The RU (1203) according to any one of claims 17 to 19 is further configured to: - Send the user plane "U plane" message to the DU (1202) using one of the two or more non-static endpoints.

Images