Systems and methods for o-du and o-RU collaboration in network slicing enabled o-ran architectures

Abstract

A method for implementing network slice service including multiple network slices for users of different service categories with different service level agreement (SLA) requirements in an Open Radio Access Network (O-RAN) system having an O-RAN distributed unit (O-DU) and an O-RAN radio unit (O-RU) configured for implementing Demodulation Reference Signal-based Beamforming (DMRS-BF), includes: sending, by the O-DU to the O-RU, a slice priority indicator specific to a user; determining, by the O-RU, a specified service level of the user from the priority indicator; associating, by the O-RU, the specified service level of the user with a corresponding delay profile comprising at least one O-RU latency parameter value; and scheduling, by the O-RU, a receive (Rx) window for control plane (C-plane) messages and a transmit (Tx) window for user plane (U-plane) messages according to the at least one O-RU latency parameter value specified in the delay profile.

Description

SYSTEMS AND METHODS FOR O-DU AND O-RU COLLABORATION IN NETWORK SLICING ENABLED O-RAN ARCHITECTURESBACKGROUND OF THE DISCLOSURE1. Field of the Disclosure

[0001] The present disclosure is related to Open Radio Access Network (O-RAN) architecture wireless systems, and relates more particularly to O-DU and O-RU collaboration to enable network slicing into the O-RAN architecture.2. Description of Related Art

[0002] O-RAN is based on disaggregated components which are connected through open and standardized interfaces based on 3GPP NG-RAN. O-RAN network comprises disaggregated O- RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), and O-RAN Radio Unit (O- RU). The O-CU and the O-DU, which are typically located at different physical locations, are connected using the Fl interface over a mid-haul (MH) path. The O-RU is located at a cell-site and communicates with the O-DU via a front-haul (FH) interface.

[0003] Network slicing is a key concept in 5Gthat enables the creation of multiple independent logical networks (i.e., slices) on a shared physical network infrastructure. Each slice is a virtual end-to-end network designed to meet the diverse throughput, latency, and bandwidth requirements for various service types of user applications. 5GNR has pre-defined three major service categories: Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC). Network slicing enables new business models across vertical markets by providing the flexibility and capability to deliver services with high security, isolation, and guaranteed performance characteristics to meet the Service Level Agreement (SLA) requirements. An SLA for network slicing is an end-to-end commitment between a service provider and a client that defines quality of service (QoS) requirements such as bandwidth, throughput, and latency. A network slice is composed of a Core Network slice, a Transport network slice, and a RAN slice, whereby various slices collaborate to deliver end-to-end network slicing service.

[0004] With a slice-aware RAN, the available RAN network resources can be allocated and prioritized according to the service performance requirements for different service categories. Such a prioritization scheme can include, e g., differentiation in admission control, radio resource partitioning, scheduler strategy, priority, and QoS flow management. A single UE can be assigned and access up to 8 network slices concurrently, using Single-Network Slice Selection Assistance Information (S-NSSAI) as the Network Slice identifier.

[0005] Demodulation Reference Symbol-based beamforming (DMRS-BF) has been approved by Working Group 4 (WG4) of the O-RAN Alliance, with the objective of providing uplink performance improvement, especially in high mobility and / or high interference scenarios. The key difference between DMRS-BF and its predecessor, Weight-based Dynamic Beamforming (WDBF), is that some of the user-specific functionalities on the 0-DU are now moved in DMRS-BF to the O-RU, which functionalities include DMRS channel estimation, DMRS-based beamforming, and / or equalization functions.

[0006] The International Telecommunication Union (ITU) has classified 5G mobile network services into three main categories: Enhanced Mobile Broadband (eMBB), Ultra-reliable and Low-latency Communications (uRLLC), and Massive Machine Type Communications (mMTC). Unlike eMBB, which emphasizes high throughput, URLLC is suitable for mission-critical applications such as factory automation, autonomous driving, and virtual / augmented reality.According to 3GPP 38.913, the URLLC requires reliability of le-5 for 32 bytes with a user plane latency of 1 ms. On the other hand, mMTC goes to the other extreme, and mMTC is tailored to support Internet of Things (loT) use cases where connectivity needs to handle a large number of devices (e.g., 50,000 devices per sector) with limited data volume.

[0007] A network slice extends from an end-user device to an application and encompasses a wide spectrum of network functions, such as the core, transport, and radio access network (RAN). RAN slice is a critical part of the end-to-end network slices since it plays a key role in the user experience in terms of bandwidth, throughput, and latency. Slice-specific resource allocation, scheduling, and admission control functions in O-CU and O-DU are some of the measures that enable differentiated user traffic handling and isolation.

[0008] In the current RAN slicing architecture, O-RU is not considered to be slice-aware sincethe O-RU in the existing 7.2x fronthaul split option with WDBF performs only basic, low-PHY operations such as FFT and beamforming weights application.

[0009] With the advent of the 7.2x with DMRS-BF, user-specific functions such as DMRS channel estimation, DMRS-based beamforming, and / or equalization were moved to the O-RU. This makes it necessary to also include the O-RU in the RAN slice architecture to ensure guaranteed service characteristics as defined in the SLA for different service categories.

[0010] The current DMRS-BF based user prioritization is inadequate to meet network slicing requirement due to primarily the following reasons: capacity; latency; and service guarantee.

[0011] 1. Capacity: O-RU has finite computational capacity and memory resources, unlike O- DU, where resource pooling makes it possible to expand capacity. The current DMRS-BF O-RU is dimensioned to handle a small number of users per slot with high data rate traffic. Inevitably, it would run into capacity or resource bottlenecks, for example, i) with mMTC traffic, where user traffic has low bandwidth but the number of users per slot may be significantly higher, or ii) with URLLC traffic when the number of DMRS symbols in a full slot increases significantly due to the usage of mini-slots. In short, the new type of services may increase the processing overhead significantly.

[0012] 2. Latency: With URLLC traffic and mini-slot usage, the current full-slot-based delay profile for DMRS-BF O-RU becomes inadequate to meet the stringent latency requirement of mission-critical communications.

[0013] 3. Service Guarantee: The current DMRS-BF specification does not include a mechanism to gauge resource partitioning to ensure that a certain bandwidth / latency target is met for a certain number of users of that service category to satisfy the service level agreement (SLA).

[0014] Network slicing creates multiple virtual networks on top of a shared physical network to provide greater flexibility in the usage and allocation of network resources. Each network slice can have its own logical topology, security rules, and performance characteristics within the limits imposed by the underlying physical network. Different slices can be dedicated to different service attributes, such as ensuring a specific application or service gets priority access to capacity and delivery, or isolating traffic for specific users or device classes according to certainservice level agreements (SLAs).

[0015] An example of network slicing is shown in FIG. 1, which illustrates an example network with 3 network slices that serve 3 types of user devices, i.e., a smart phone (eMBB) 1001, a connected vehicle (URLLC) 1002, and a smart meter (mMTC) 1003. Over the same physical network components, i.e., O-RU 1004 and O-DU 1005 of the O-RAN network, as well as the 5G Core (5GC) network 1006, RAN slices (e.g., RAN slices 1, 2 and 3) and dedicated Core slices (e.g., Core slices 1, 2 and 3) work together to deliver guaranteed service to the user devices according to the SLA for each service category. Each of the slices can be uniquely identifiable through a Slice ID (e.g., Slice ID 1 for eMBB 1001; Slice ID 2 for URLLC 1002; and Slide ID 3 for mMTC 1003). In the traditional network, O-RU 1004 is cell-specific and does not contribute to the user service differentiation, and therefore O-RU 1004 is depicted in FIG. 1 with a dashed outline. Also shown in FIG. 1 are common network functions 1006a, and slice-specific core network functions 1006b, 1006c and 1006d.

[0016] A 5G network may support a large number of network slices, but for a single user equipment (UE), the maximum number of simultaneous network slice instances is currently limited to 8. A network slice may consist of several network elements, such as core, transport, and access (RAN), where each network element may have its own slices, as shown in FIG. 1.

[0017] RAN slicing has a similarity to QoS, but it is a superset of the existing QoS mechanism, i.e., RAN slicing allows further differentiation of users of the same QoS type. For example, 5QI1 Voice over New Radio (VoNR) can be further separated by network slicing into an emergency call slice and a regular VONR call slice. The emergency call slice may be handled with higher reliability and expediency in comparison to the regular call slice, and be routed to a special public safety portal as a vertical application of the network, in order to offer differentiated service for the first responders. RAN slicing may map an SLA to an existing QoS level or create a new service with specific throughput, latency, and reliability attributes that are not available from the existing QoS levels.

[0018] Each network slice is uniquely identified by a Single Network Slice Selection Assistance Information (S-NSSAI). Network Slice Selection Assistance Information (NSSAI) includes one or more of S-NSSAIs. The structure of S-NSSAI, which is shown in FIG. 2, is a combination of: i)the mandatory Slice / Service Type (SST) field; and ii) optional Sice Differentiator (SD) field. The SST field identifies the slice type and consists of 8 bits (with a range of 0-255). The SST field may have standardized and non-standardized values, i.e., values 0 to 127 belong to the standardized SST, and values 128 to 255 belong to the operator-specific range. The optional SD field, which consists of 24 bits, differentiates among slices with the same SST field.

[0019] A UE may initiate a Registration Request with the requested S-NASSI to an Access and Mobility Management Function (AMF) and receive a Registration Accept message if the S- NASSI is supported. The UE subsequently sends the Protocol Data Unit (PDU) Session Establishment Request and receives the PDU Session Establishment Accept message to set up the data pipe and associate it with the allowed S-NASSI. A PDU session provides a connectivity service between a UE and the data network. The S-NSSAI is carried from the core to the radio access network (RAN) for each PDU session. The slice-aware RAN (e.g., radio resource management (RRM) functions in O-CU and 0-DU) will use the slice identity to provide resource admission and resource allocation prioritization to ensure differentiated handling of the user traffic to meet the SLA.

[0020] Until now, the 0-RU has not factored in the RAN slicing architecture, e g., in the legacy WDBF, the 0-RU is agnostic to user-specific operations. The low PHY functionalities in the O- RU, such as the fast fourier transform (FFT) and / or inverse fast fourier transform (IFFT) function and the beamforming application functions are sector-specific. However, with the advent of DMRS-BF, the 0-RU is enabled to handle user-specific traffic for Physical Uplink Shared Channel (PUSCH), which allows for service differentiation for different users.

[0021] As shown in FIG. 3, the current technical specification for the DMRS-BF method stipulates that the DMRS-BF processing cannot start until the last DMRS symbol of all user PUSCH PRBs arrives. As shown in FIG. 3, UE1 and UE2 occupy a certain number of PRBs, where UE1 has double symbol DMRS of r 12, rl3, rl 10, and ri l l at symbol positions of 2, 3, 10, and 11 in slot N, whereas UE2 has single DMRS r22 and r210 at symbol position of 2 and 10 in slot N. According to the CUS plane specification, the DMRS-BF processing can start after symbol 11 when the last DMRS symbol of the 2 UEs (i.e., rl 1) has arrived over the air. Hence, for the user plane, in order to get the DMRS-BF results, the 0-DU needs to wait Ta3_min_up (asshown in FIG. 3) to get any data. This is certainly inadequate for servicing mission-critical traffic such as URLLC when mini-slots are used to ensure a faster turn-around.

[0022] In addition to the above, although different delay profiles can be configured for different channels, e.g., physical uplink control channel (PUCCH), there must be a single delay profile across all DMRS-BF’d PUSCH (i.e., a single delay profile is mandated for all DMRS-BF users). For this reason, the ability to reduce latency when needed for various services is severely hampered.

[0023] Accordingly, there is a need to more effectively support RAN network slicing by providing user differentiation and / or service differentiation in DMRS-BF-based 0-RU for different service categories.SUMMARY

[0024] According to an example embodiment of a method and a system according to the present disclosure, network slicing is supported via 0-DU and 0-RU collaboration in 0-RAN.

[0025] According to an example embodiment of a method and a system according to the present disclosure, the 0-DU supports RAN slicing whereby a RAN slice instance may be associated with one or more Core network slices to form one or more network slices.

[0026] According to an example embodiment of a method and a system according to the present disclosure, an 0-RU communicates with the 0-DU over multiple network slices, e.g., by performing the following: receiving, by the O-RU from a RAN slice in 0-DU, a request for establishing a service associated with the RAN slice, the request comprising at least one of the performance attributes such as bandwidth, latency, or throughput corresponding to a Service Level Agreement; transmitting, by the 0-RU, a response comprising granted resources for the RAN slice after evaluating the request against the processing capacity of the 0-RU; sending, by the 0-DU, a priority indicator on a per-user or per-bearer basis to theO-RU, wherein the indicator can be associated with an S-NSSAI or a delay profile ID; and granting, by the O-RU, prioritized access to the O-RU resources to one or more priority users relative to one or more non-priority users.

[0027] For this application the following terms and definitions shall apply:

[0028] The term “network” as used herein includes both networks and internetworks of all kinds, including the Internet, and is not limited to any particular type of network or inter-network.

[0029] The terms “first” and “second” are used to distinguish one element, set, data, object or thing from another, and are not used to designate relative position or arrangement in time.

[0030] The terms “coupled”, “coupled to”, “coupled with”, “connected”, “connected to”, and “connected with” as used herein each mean a relationship between or among two or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, and / or means, constituting any one or more of (a) a connection, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, (b) a communications relationship, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, and / or (c) a functional relationship in which the operation of any one or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means depends, in whole or in part, on the operation of any one or more others thereof.

[0031] The above-described and other features and advantages of the present disclosure will be appreciated and understood by those skilled in the art from the following detailed description, drawings, and appended claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG. l is a block diagram illustrating traditional network slicing in O-RAN.

[0033] FIG. 2 is a block diagram illustrating S-NASSI Structure.

[0034] FIG. 3 is a block diagram illustrating the coexistence of WDBF’d data and DMRS-BF’d data.

[0035] FIG. 4 is a signal flow diagram illustrating signaling between O-DU and O-RU for establishing a new network slice.

[0036] FIG. 5 is a chart illustrating parameters impacted by the new delay profile.

[0037] FIG. 6 is a chart illustrating an example of new Section Type 5 that supports network slicing.

[0038] FIG. 7 is a chart illustrating an example of new Section Extension 10 that supports network slicing.

[0039] FIG. 8 is a chart illustrating an example of new Section Extension 24 that supports network slicing.

[0040] FIG. 9 a signal flow diagram illustrating user slice priority signaling between O-DU and O-RU.

[0041] FIG. 10 illustrates an example U-Plane delay profile for different service types.DETAILED DESCRIPTION

[0042] According to an example embodiment of a method and a system according to the present disclosure, network slicing is supported via O-DU and O-RU collaboration in 0-RAN. The O- DU supports RAN slicing whereby a RAN slice instance may be associated with one or more Core network slices to form one or more network slices.

[0043] According to an example embodiment of a method and a system according to the present disclosure, an O-RU communicates with the O-DU over multiple network slices, e.g., by performing the following: receiving, by the O-RU from a RAN slice in O-DU, a request for establishing aservice associated with the RAN slice, the request comprising at least one of the performance attributes such as bandwidth, latency, or throughput corresponding to a Service Level Agreement; transmitting, by the O-RU, a response comprising granted resources for the RAN slice after evaluating the request against the processing capacity of the O-RU; sending, by the O-DU, a priority indicator on a per-user or per-bearer basis to the O-RU, wherein the indicator can be associated with an S-NSSAI or a delay profile ID; and granting, by the O-RU, prioritized access to the O-RU resources to one or more priority users relative to one or more non-priority users.

[0044] Network slicing allows multiple logical networks to run on top of a shared physical network infrastructure, with each network slice instance being uniquely identified by a SingleNetwork Slice Selection Assistance Information (S-NASSI) to provide service assurance to a diverse range of user devices. Such user devices may include enhanced mobile broadband (eMBB) devices that emphasize high bandwidth content, massive Machine Type Communication (mMTC) devices that emphasize a massive number of users with low traffic volume, and ultrareliable low latency communication (URLLC) devices that emphasize high reliability and low latency. The user device may request and be granted a network slice from the network. Subsequently, the network slice guarantees the device-to-network communication according to the Service Level Agreement (SLA), which dictates one or more performance attributes such as bandwidth, throughput, or latency.

[0045] Unlike the traditional WDBF O-RU, a DMRS-BF O-RU is a new kind of O-RU with several user-specific PUSCH processing functions relocated from O-DU to the O-RU, such as DMRS-based channel estimation, beamforming and / or equalization. Because these PUSCH processing functions are user-specific, the DMRS-BF O-RU provides an opportunity for service differentiation to different user devices in different service categories under different SLAs. Different slices have different optimization targets, e.g., for the URLLC slice, the target is to minimize the buffer occupancy and minimize the latency within the O-RU, whereas, for mMTC, the target is to support a vast number of devices (e.g., 50000 devices in a cell).

[0046] A physical device, such as a DMRS-BF O-RU, has a capacity limitation, and hence it cannot be dimensioned to support all possible service categories and scenarios simultaneously in practice. These limitations may include limited computing capacity, limited timing budget, limited memory, energy consumption or device cooling constraints, cost-effective target, and the like, and the DMRS-BF O-RU can compromise in one or more aspects to be competitive in the marketplace.

[0047] According to an example embodiment of a method, the RAN-slice-aware O-DU negotiates with the DMRS-BF O-RU to establish a network slice service. FIG. 4 illustrates a signal flow between the DMRS-BF O-RU 1004 and the O-DU 1005 which is RAN-slice-aware. The RAN-slice-aware O-DU 1005 can send (as referenced by the process arrow 4001 in FIG. 4) a slice setup request to the DMRS-BF O-RU 1004, which request can comprise the first information related to i) a new slice's service attributes, e.g., throughput, latency, and bandwidth, and ii) the endpoints' resource requirements, e.g., the layers, transceiver (TRX) channels, physical resource blocks (PRBs), and / or bandwidth parts, etc. As referenced by 4002, the O-RU 1004 evaluates the existing endpoint resources and determines whether the service attributes of the new slice and the endpoints' resource requirements can be satisfied according to the current resource utilization (for the existing network slices), energy consumption, cooling constraint, etc. If the new slice’s service attributes and the endpoints' resource requirements can be met (given the resource utilization for the existing network slices), the O-RU 1004 can send a response (as referenced by the process arrow 4005 in FIG. 4) with the allowed service parameters (for the new slice and any existing slices, if applicable) to the O-DU 1005, which response can comprise the attributes of the service, the maximum number of UEs that can use the slice, the provisioning of the endpoints that are available for the specified service attributes.

[0048] If, on the other hand, the attributes of the new slice cannot be met given the current resource utilization of the existing slices, the O-RU can evaluate the existing services and determine whether a new provisioning of the set of resources for the existing slice is possible (i.e., determine whether existing slices need to be preempted for the new slice, as referenced by 4003). In certain cases, a preemption of a portion of the existing services in favor of the new service is warranted according to priority criteria, and the O-RU can reassign a portion of the endpoint resources to the new slice in order to satisfy the new service attributes (i.e., determinethe new parameters (resources) for the new slice and the existing slices, as referenced by 4004). The 0-RU 1004 can subsequently send a response (as referenced by the process arrow 4005 in FIG. 4) with the allowed parameters of the new service as well as the adjusted parameters for the existing services to the 0-DU 1005, which response can comprise the attributes of the services, the maximum number of UEs for the slice, and the newly provisioned endpoints for the new as well as the existing services.

[0049] After receiving the response from the 0-RU 1004, the 0-DU 1005 can i) evaluate the parameters of the new slice and / or the existing slices, and ii) determine whether the new set of service attributes for the new service and / or the existing services (i.e., SLA ) can be met by the 0-DU 1005. Subsequently, the 0-DU 1005 can send a new slice setup request (as referenced by the process arrow 4007 in FIG. 4) to the DMRS-BF 0-RU 1004, which request can comprise the 2nd information related to the service attributes of the new slice and / or the existing slices and the endpoint resource requirements. The 0-RU 1004 can subsequently reserve the endpoint resources (e g., computation capacity and memory) according to the 2nd information sent from the 0-DU 1005.

[0050] According to an example embodiment of the present disclosure, the resource (re)dimensioning procedure can be implemented by the O-DU and the 0-RU in a dynamic manner, as explained in connection with FIG. 5, which illustrates parameters impacted by the new delay profile to be implemented. By enabling dynamic resource (re)dimensioning, the endpoint resources provisioning (e.g., layers, TRX channels, PRBs, and / or the size of the bandwidth part) can be adjusted in real time through a joint evaluation of the served user’s traffic composition and the SLAs to achieve an optimal configuration.

[0051] According to an example embodiment of the present disclosure, different delay profiles can be supported between the 0-DU and the O-RU for different service types using the same beamforming method, such as DMRS-BF. For mission-critical services like URLLC, in which the traffic may use mini-slots where the time-domain length is 2, 4, or 7 symbols, the data packets carried in the mini-slot require i) a short scheduling delay compared to full slot scheduling, and ii) a new delay profile such that low latency traffic can be sent out to the 0-DU with much lower latency than the conventional eMBB traffic.

[0052] According to an example embodiment of the present disclosure, a new set of delay profiles is provided for slices that use sub-slot granularity and require minimal delay. The starred (*) parameters shown in FIG. 5 represent the latency parameters that are related to the UL FH messages, as follows: T2a_min_cp_ul and T2a_max_cp_ul are related to the C-Plane messages (ST5, SET10, SE24 etc.) from the O-DU to the 0-RU; Ta3_min_2g and Ta3_max_2g are related to the RRM report from the 0-RU to the O-DU; Ta3_min_up and Ta3_max_up are related the U-Plane data that is the output of DMRS-BF 0-RU. The present disclosure provides a new delay profile (i.e., a set of 0-RU latency parameter values) for service categories requiring low latency. The new delay profile can be sent by the 0-RU through an M-Plane message to the network management function during the 0-RU power-up. The delay profile can be stored in the network management function and be retrieved by the 0-RU when the service related to that delay profile gets established between the O-DU and 0-RU.

[0053] In the example embodiment according to the present disclosure, O-DU can send an indicator of the service priority in the C-Plane message to identify the service type of the user or the data bearer of the user. The indicator can comprise the S-NSSAI or a delay profile ID. In one example embodiment, the priority indicator can be sent by the O-DU in a C-Plane message in a modified version of Section Type 5 (the overall structure of which is as shown in FIG. 6) to the O-DU, which can be accompanied by Section Extension 10 (the overall structure of which is as shown in FIG. 7) when there is more than one UE layer in the user group. Section Type 5 is used to describe a single UE signal layer configuration for DMRS-BF. As shown in FIG. 6, the modified version of Section Type 5 according to the present disclosure includes a delay profile id field (which is starred in FIG. 6) appended after the 15 bit ueld field to indicate the service category of the UE identified by the ueld. Section Extension 10 is an extension of Section Type 5 to support more than 1 layer and more than 1 multi-user group. As shown in FIG.7, the modified version of Section Type 10 according to the present disclosure includes a delay _profile_id field (which field is starred in FIG. 7, e.g., “2ndport delay _profile_id” and “numPortc port delay _profile_id”) appended after each port beamld or ue id (15 bit in width) to indicate the service category of the UE identified by the ueld.

[0054] According to an example embodiment, the indicator can be sent by the O-DU in a C-Plane message to the 0-RU in a modified version of Section Extension 24, which is shown inFIG. 8. Section Extension 24 is mandatory information if DMRS-BF is supported. The present disclosure provides a new entryType field (e.g., entryType 5 as shown in the starred (*) two rows near the bottom of FIG. 8) appended to the Section Extension 24 to indicate the service level priority of the user traffic, which information can comprise the delay_profile_id as shown in FIG. 8. EntryType 5 shall associate the delay_profile_id with a dmrsPortNumber in this entry, and the dmrsPortNumber is further associated with an entryType 2 or entryType 3 of Section Extension 24, where the PRB allocation of user traffic is identified.

[0055] According to an example embodiment, the S-NSSAI can be used with or without delay _profile_id field.

[0056] According to an example embodiment, the O-RU can determine the service level of the user from the indicator, associate the service level with the delay profile, and schedule the C- plane and U-plane traffic according to the latency budget specified in the delay profile. An example message flow between the O-DU and DMRS-BF O-RU for user slice priority signaling is depicted in FIG. 9. As referenced by 9001 in FIG. 9, the O-DU 1005 sends a user-specific slice priority indicator to the O-RU 1004. As referenced by 9002, the O-RU 1004 applies the delay profile corresponding to the received slice priority indicator. Subsequently, as referenced by 9003, the O-RU 1004 adjusts the receive (Rx) and transmit (Tx) window for the corresponding C-plane and U-plane messages according to the delay profile. In addition, as referenced by 9004, the O-RU 1004 prioritizes endpoint resources to satisfy the user service attribute. As referenced by 9005, the O-DU sends the C-plane message (signaling) to the O-RU 1004 according to the O- RU Rx window that is configured (e.g., 9003) earlier in the O-RU 1004 side for the slice attribute. Thereafter, as referenced by 9006, the O-RU 1004 transmits the U-plane message and RRM measurement result to the O-DU 1005 in the O-RU’s Tx window that is specified (e.g., 9003) earlier in the O-RU 1004 side.

[0057] An example of U-Plane uplink data to support different service categories is depicted in FIG. 10. FIG. 10 illustrates 3 UEs in SlotN, i.e., UE1, UE2 and UE3. UE1 is a regular full slot UE that has DMRS symbols rl2, r 13 , rl 10, and rl 1 Iwhich are positioned at symbols 2, 3, 10, and 11 respectively. The UE1 and UE2 / 3 occupy different PRB resources in the same bandwidth part, or they can be in 2 different bandwidth parts. UE2 is a 2-symbol mini-slot UE that hasDMRS symbol r20, which is positioned at symbol 0. UE3 is a 4-symbol mini-slot UE that has DMRS symbol r32, which is positioned at symbol 2.

[0058] According to an example embodiment, the mini-slot traffic can use a different delay profile, e.g., shown as Ta3_min_upl in FIG. 10. The DMRS-BF processing (denoted as “DMRS- BF processing 1” in FIG. 10) can start immediately after the DMRS symbol r20 for UE2, or the DMRS symbol r32 of UE3, arrives over the air. In addition, after Ta3_min_upl for UE2 or UE3, the U-Plane data can be made available to be transmitted to the 0-RU. As a comparison, UE1, which is an eMBB user, can still adhere to the legacy delay profile for DMRS-BF, i.e., waits for the arrival of the last DMRS symbol (rl 11 as shown in FIG. 10) before starting DMRS-BF processing (denoted as “DMRS-BF processing 2” in FIG. 10), and the U-Plane can be made available to the 0-DU after Ta3_min_up2. In addition, RRM Measurement reports from the O- RU for different service categories can also use different delay profiles.

[0059] The present disclosure provides network slicing support with 0-DU and 0-RU collaboration to support users of different service categories with different SLA requirements on the 0-RU, whereby UE-specific operation is now possible (e.g., with the upcoming version of O- RAN CUS-plane specification). The present disclosure additionally provides new signaling in the 7.2x fronthaul to augment the existing DMRS-BF signaling, which new signaling can include those for:1) 0-DU and 0-RU to negotiate and agree on an endpoint partition in the 0-RU to guarantee the bandwidth, latency, or throughput according to the end-to-end service level agreement and the hardware capabilities of the 0-RU.2) Multiple delay profiles can be created for different service categories for the same DMRS-BF method in the same BWP. As an alternative, different BWPs carrying different service types can have different delay profiles.3) The 0-DU can use an indicator to represent the user service priority in the CU plane when requesting ULPI processing for a user. This indicator can be an S-NSSAI, a delay profile index, a BWP ID, a processing sequence, a service type ID, or a combination of these elements.

[0060] While the present disclosure has been described with reference to one or more exemplaryembodiments, it will be understood by those skilled in the art that various changes can be made and equivalents can be substituted for elements thereof without departing from the scope of the present disclosure. For example, the although the example methods have been described in the context of specific fronthaul splits, example methods are equally applicable for other types of fronthaul split where the user-specific uplink processing is moved to the O-RU, aside from DMRS-BF. In addition, example methods are equally applicable for any downlink processing split where the user-specific processing is moved to the O-RU. Furthermore, network slicing can be enabled through different fronthaul messages between the O-DU and the O-RU. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiment(s) disclosed as the best mode contemplated, but that the disclosure will include all embodiments falling within the scope of the appended claims.

[0061] For the sake of completeness, a list of abbreviations used in the present specification is provided below:5GC: 5G Core Network5G NR: 5G New RadioBWP - Bandwidth PartCUS-Plane - Control, User, and Synchronization PlaneDMRS-BF - Demodulation Reference Signal-based Beamforming eMBB - Enhanced Mobile Broad BandFH: Fronthaul mMTC: Massive Machine-Type CommunicationsNSI: Network Slice InstanceNSSAI: Network Slice Selection Assistance InformationNS SI: Network Slice Subnet Instance0-RAN: Open Radio Access NetworkO-CU: O-RAN Centralized UnitO-DU: O-RAN Distributed UnitO-RU: O-RAN Radio UnitPRB. Physical Resource BlockPUCCH: Physical Uplink Control ChannelPUSCH: Physical Uplink Shared ChannelSLA: Service Level AgreementS-NSSAI: Single Network Slice Selection Assistance InformationTRX: TransceiverULPI: USB 2.0 Transceiver Macrocell Interface+ (UTMI+) Low Pin InterfaceURLLC: Ultra-Reliable and Low Latency CommunicationsVoNR: Voice over New RadioWDBF: Weight Based Dynamic Beamforming

Claims

CLAIMS:

1. A method for implementing network slice service comprising multiple network slices in an Open Radio Access Network (O-RAN) system having an O-RAN distributed unit (O-DU) and an O-RAN radio unit (O-RU), comprising: transmitting, by the O-DU to the O-RU, a slice setup request for establishing a new network slice in addition to an existing network slice, wherein the slice setup request comprises at least one of a performance attribute of the new network slice and resource requirement of endpoints for the new network slice; evaluating, by the O-RU, whether existing endpoint resources are sufficient to satisfy the resource requirements for the new network slice without preempting at least a portion of resource allocation for the existing network slice; and transmitting, by the O-RU to the O-DU, a response comprising at least one of i) granted parameters for the new network slice, and ii) adjusted parameters for the existing network slice computed in the case the existing endpoint resources are insufficient to satisfy the resource requirements for the new network slice and preempting at least a portion of resource allocation for the existing network slice in favor of the new network slice is necessary.

2. The method according to claim 1, further comprising: evaluating, by the O-DU, the at least one of the i) granted parameters for the new network slice, and ii) adjusted parameters for the existing network slice, to determine whether specified service level agreements for the new network slice and the existing network slice can be satisfied by the O-DU.

3. The method according to claim 1, wherein at least one of: i) the performance attribute of the new network slice comprises at least one of throughput, latency, and bandwidth; and ii) the resource requirement of endpoints for the new network comprises at least one of layers, transceiver channels, physical resource blocks, and bandwidth parts.

4. The method according to claim 1, wherein: in the case the existing endpoint resources are insufficient to satisfy the resource requirements for the new network slice, the preempting of at least a portion of resource allocation for the existing network slice in favor of the new network slice is implemented according to a priority criterion.

5. The method according to claim 4, further comprising: sending, by the O-DU to the O-RU, a priority indicator of a user, wherein the priority indicator is associated with one of a Single Network Slice Selection Assistance Information (S- NSSAI) or a delay profile identifier (ID).

6. The method according to claim 5, further comprising: determining, by the O-RU, a specified service level of the user from the priority indicator; and associating, by the O-RU, the specified service level of the user with a corresponding delay profile comprising at least one O-RU latency parameter value.

7. The method according to claim 6, further comprising: scheduling, by the O-RU, a receive (Rx) window for control plane (C-plane) messages and a transmit (Tx) window for user plane (U-plane) messages according to the at least one 0- RU latency parameter value specified in the delay profile.

8. A method for implementing network slice service comprising multiple network slices for users of different service categories with different service level agreement (SLA) requirements in an Open Radio Access Network (0-RAN) system having an 0-RAN distributed unit (0-DU) and an 0-RAN radio unit (O-RU) configured for implementing Demodulation Reference Signalbased Beamforming (DMRS-BF), comprising: sending, by the 0-DU to the O-RU, a slice priority indicator specific to a user; determining, by the O-RU, a specified service level of the user from the priorityindicator; associating, by the O-RU, the specified service level of the user with a corresponding delay profile comprising at least one O-RU latency parameter value; and scheduling, by the O-RU, a receive (Rx) window for control plane (C-plane) messages and a transmit (Tx) window for user plane (U-plane) messages according to the at least one 0- RU latency parameter value specified in the delay profile.

9. A system for implementing network slice service comprising multiple network slices in an Open Radio Access Network (0-RAN) system, comprising: an 0-RAN distributed unit (0-DU); and an 0-RAN radio unit (O-RU); wherein, the 0-DU is configured to transmit to the O-RU a slice setup request for establishing a new network slice in addition to an existing network slice, wherein the slice setup request comprises at least one of a performance attribute of the new network slice and resource requirement of endpoints for the new network slice; the O-RU is configured to evaluate whether existing endpoint resources are sufficient to satisfy the resource requirements for the new network slice without preempting at least a portion of resource allocation for the existing network slice; and the O-RU is configured to transmit to the 0-DU a response comprising at least one of i) granted parameters for the new network slice, and ii) adjusted parameters for the existing network slice computed in the case the existing endpoint resources are insufficient to satisfy the resource requirements for the new network slice and preempting at least a portion of resource allocation for the existing network slice in favor of the new network slice is necessary.

10. The system according to claim 9, wherein: the 0-DU is further configured to evaluate the at least one of the i) granted parameters for the new network slice, and ii) adjusted parameters for the existing network slice, to determine whether specified service level agreements for the new network slice and the existing network slice can be satisfied by the 0-DU.

11. The system according to claim 9, wherein at least one of: i) the performance attribute of the new network slice comprises at least one of throughput, latency, and bandwidth; and ii) the resource requirement of endpoints for the new network comprises at least one of layers, transceiver channels, physical resource blocks, and bandwidth parts.

12. The system according to claim 9, wherein: in the case the existing endpoint resources are insufficient to satisfy the resource requirements for the new network slice, the preempting of at least a portion of resource allocation for the existing network slice in favor of the new network slice is implemented according to a priority criterion.

13. The system according to claim 12, wherein: the 0-DU is further configured to send to the 0-RU a priority indicator of a user, wherein the priority indicator is associated with one of a Single Network Slice Selection Assistance Information (S-NSSAI) or a delay profile identifier (ID).

14. The system according to claim 13, wherein: the 0-RU is further configured to i) determine a specified service level of the user from the priority indicator, and ii) associate the specified service level of the user with a corresponding delay profile comprising at least one 0-RU latency parameter value.

15. The system according to claim 14, wherein: the 0-RU is further configured to schedule a receive (Rx) window for control plane (C- plane) messages and a transmit (Tx) window for user plane (U-plane) messages according to the at least one 0-RU latency parameter value specified in the delay profile.

16. A system for implementing network slice service comprising multiple network slices for users of different service categories with different service level agreement (SLA) requirements in an Open Radio Access Network (0-RAN) configured for implementing Demodulation ReferenceSignal-based Beamforming (DMRS-BF), comprising: an O-RAN distributed unit (O-DU); and an O-RAN radio unit (O-RU); wherein, the O-DU is configured to transmit to the O-RU a slice priority indicator specific to a user; and the O-RU is configured to: i) determine a specified service level of the user from the priority indicator; ii) associate the specified service level of the user with a corresponding delay profile comprising at least one O-RU latency parameter value; and iii) schedule a receive (Rx) window for control plane (C-plane) messages and a transmit (Tx) window for user plane (U-plane) messages according to the at least one 0- RU latency parameter value specified in the delay profile.

Images