Patent Description:
According to <NPL>, RAN shall support the selection of the RAN part of the network slice, by one or more slice ID(s) provided by the user equipment (UE) or the core network (CN) which unambiguously identifies one or more of the pre-configured network slices in the PLMN (public land mobile network). Furthermore, RAN shall support a differentiated handling of traffic for different network slices which have been pre-configured. In this context, <NPL> defines configured and accepted NSSAI (Network Slice Selection Assistance Information) used by RAN to help on decide the RAN configuration.

The updated version of above "<NPL> also discloses that RAN shall support the selection of the RAN part of the network slice, by one or more slice ID(s) provided by the user equipment (UE) or the core network (CN) which unambiguously identifies one or more of the pre-configured network slices in the PLMN (public land mobile network). Furthermore, RAN shall support a differentiated handling of traffic for different network slices which have been pre-configured.

It is not yet specified how is NSSAI mapping to Slice_ID, how is Slice_ID mapping to RAN configuration, how RAN configuration looks like and how RAN configuration should be performed.

It is the object of the invention to provide a concept for an efficient RAN configuration in Slice-based networks.

This object is achieved by the features of the independent claims.

Besides abstracting context from UE/CN used to decide the RAN configuration and the procedure to get them, the core idea includes also determining the decision mechanism and the configuration procedure for the adaptation of RAN configuration at RAN. The disclosed RAN configuration can be subdivided in two parts:
A first part is related to SA5, slice management domain presenting a mechanism for per slice RAN configuration and RAN configuration adaptation within each slice. Two phases of RAN configuration, i.e. a pre-configuration phase and an adaptation phase, can be identified: The first phase is a RAN pre-configuration at the deployment phase, to identify recommended RAN configuration mode per slice type (based on NSSAI / Slice ID). The second phase is a RAN configuration adaptation to cope with changes in different time scales, i.e. slow changes and fast changes. Slow changes may be related to e.g. change of the traffic situation at the RAN, group UE mobility, change of backhauling capacity, etc. Fast changes may be related to e.g., communication protocol of individual traffic flow, dynamic RAN topologies, individual UE mobility, critical slice traffic, etc..

A second part is related to SA2, RAN3, context and signaling domain presenting a Context exchange to support RAN configuration adaptation within each slice. This may include: Receiving Context Information related to UE (e.g. mobility, multi-Air Interface measurements, UE capabilities,. ); Receiving Context Information from the CN (communication protocol,. ); Receiving abstract of RAN configuration from the CN, which will be mapped to a network slice; and Forwarding RAN configuration adaptation decision to the involved nodes (UE, gNBs, CN).

This disclosure fills the gap on slice realization at the RAN side and can provide standardization impact on 3GPP TR. <NUM>, SA2 TS on <NUM> network function description, and SA2 TS on <NUM> procedure regarding the context exchanged to decide on the RAN configuration, as well as SA5 on the RAN configuration/reconfiguration method.

In order to describe the invention in detail, the following terms, abbreviations and notations will be used:.

According to a first aspect, the invention relates to a Slice Management entity for a Radio Access Network (RAN) according to claim <NUM>.

Such a Slice Management entity can be used for providing an efficient RAN configuration in Slice-based networks. The RAN can be a base station or a group of base stations. Such a Slice Management entity provides the advantage of setting up a slice more effectively and of benefitting from more efficient resource allocation.

In a first possible implementation form of the Slice Management entity according to the first aspect, the configuration comprises information for an operation of the slice at the RAN, in particular information on a process, a protocol function, and/or a resource required by the Slice.

Such a Slice Management entity provides the advantage that it can adapt more effectively to a context or to changes of a context.

In a second possible implementation form of the Slice Management entity according to the first aspect as such or according to the first implementation form of the first aspect, the Slice Management entity is configured to reside as a RAN domain specific management entity at a Domain Support System (DSS); and the Slice Management entity comprises an interface to a cross domain management entity at a Slice Support System (SSS) for communicating configuration information.

A cross domain management entity can be an entity that provides information to different Slice Management entities (i.e. to different DSSs) and/or between a Slice Management entity and other domain specific management entities, e.g. a transport slice management entity or a core slice management entity (i.e. to a single DSS). Such a Slice Management entity provides the advantage that it can synchronize configuration information with other Slice Management entities or other slice related entities of the same DSS.

In a third possible implementation form of the Slice Management entity according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor is further configured: to receive a Context Change message from the RAN indicating a change of context with respect to a change of information on a process, a protocol function, and/or a resource of the RAN and/or traffic at the RAN, and to adjust the configuration for the RAN based on the change of context.

This provides the advantage that the Slice Management entity can immediately change the context if required.

In a fourth possible implementation form of the Slice Management entity according to the third implementation form of the first aspect, the Context Change message indicates a change of a traffic and/or a requirement related to traffic at the RAN, handover requests from a group of UEs and/or a change of backhauling conditions and availability.

Such a Slice Management entity provides the advantage that it can efficiently adapt the Slice configuration to traffic changes, handover requests and/or backhauling changes.

In a fifth possible implementation form of the Slice Management entity according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor is configured to transmit the RAN Slice configuration message based on configuration updates in terms of protocols and RAN functions for the at least one Slice.

Such a Slice Management entity provides the advantage that configuration updates can be considered without producing delay.

According to a second aspect, the invention relates to a Radio Access Network (RAN) entity according to claim <NUM>.

Such a RAN entity can be used for providing an efficient RAN configuration in Slice-based networks. The UE can also adapt its part of the Slice.

In a first possible implementation form of the RAN entity according to the second aspect, the RAN configuration message comprises a Slice ID of the at least one Slice, at least one network function associated with the at least one Slice and/or a flag indicating an uplink or downlink configuration.

Such a RAN entity provides the advantage that it conveys the necessary context of the configuration to the involved entities.

In a second possible implementation form of the RAN entity according to the second aspect as such or according to the first implementation form of the second aspect, the RAN Slice configuration message comprises a configuration update for the at least one Slice, and the processor is configured to transmit the RAN configuration message based on the configuration update.

Such a RAN entity provides the advantage that efficient configuration updates can be provided without producing significant latency.

In a third possible implementation form of the RAN entity according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the processor is configured to detect a change of context at the RAN, in particular a change of information on a process, a protocol function, and/or a resource of the RAN and/or traffic at the RAN, and to transmit a Context Change message to the Slice Management entity responsive to detecting the change of context.

Such a RAN entity provides the advantage that the Slice configuration can be efficiently adapted to a context change at the RAN.

In a fourth possible implementation form of the RAN entity according to the third implementation form of the second aspect, the processor is configured: to detect the change of context at the RAN for the at least one Slice based on mobility information from the at least one UE associated with the at least one Slice of the RAN.

Such a RAN entity provides the advantage that the context change at the RAN also considers conditions at the UE.

In a fifth possible implementation form of the RAN entity according to the third or fourth implementation form of the second aspect, the processor is configured: to detect the change of context at the RAN for the at least one Slice based on information from at least one neighboring RAN entity, in particular a different operator RAN entity, the information indicating a change of context at the at least one neighboring RAN entity.

Such a RAN entity provides the advantage that the context change at the RAN also considers conditions at neighboring RANs.

In a sixth possible implementation form of the RAN entity according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the processor is configured to generate context information based on UE measurements on different Air Interface Variants (AIV), communication protocols and/or Slice-related information from the at least one UE, the RAN and/or a Core Network (CN) associated with the RAN.

Such a RAN entity provides the advantage that the context change at the RAN considers all available information from UE, RAN and CN.

In a seventh possible implementation form of the RAN entity according to the sixth implementation form of the second aspect, the processor is configured to adjust the configuration for the at least one Slice of the RAN according to user and/or Slice requirements based on the context information.

Such a RAN entity provides the advantage that the configuration can be flexibly updated based on user and/or Slice requirements.

In an eighth possible implementation form of the RAN entity according to the sixth or seventh implementation form of the second aspect, the processor is configured to generate the context information based on information from adjacent RAN nodes and/or adjacent base station, in particular information about capability, load, backhaul and/or cell density.

Such a RAN entity provides the advantage that the configuration can be flexibly updated based on information from adjacent RAN nodes and/or adjacent base station.

In a ninth possible implementation form of the RAN entity according to any of the sixth to the eighth implementation forms of the second aspect, the information from the CN comprises Packet Data Unit (PDU) type and/or communication protocol indication.

Such a RAN entity provides the advantage that the information from the CN can be efficiently transported by a PDU.

In a tenth possible implementation form of the RAN entity according to the ninth implementation form of the second aspect, the information from the CN is indicated via RAN-to-Core-network interface on user plane (UP) or via RAN-to-Core-network interface signaling on control plane (CP).

Such a RAN entity provides the advantage that the information from the CN can be flexibly indicated via user plane or control plane.

Further embodiments of the invention will be described with respect to the following figures, in which:.

In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration specific aspects in which the disclosure may be practiced. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.

It is understood that comments made in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa.

The described devices may include integrated circuits and/or passives and may be manufactured according to various technologies. For example, the circuits may be designed as logic integrated circuits, analog integrated circuits, mixed signal integrated circuits, optical circuits, memory circuits and/or integrated passives.

The devices described herein may be configured to transmit and/or receive radio signals. Radio signals may be or may include radio frequency signals radiated by a radio transmitting device (or radio transmitter or sender) with a radio frequency lying in a range of about <NUM> to <NUM>. The frequency range may correspond to frequencies of alternating current electrical signals used to produce and detect radio waves.

The devices and systems described herein may include processors. In the following description, the term "processor" describes any device that can be utilized for processing specific tasks (or blocks or steps). A processor can be a single processor or a multi-core processor or can include a set of processors or can include means for processing. A processor can process software or firmware or applications etc..

In the following Slice-based new radio (NR) networks, i.e. communication networks with multiple network slices are described. A "Slice" or a "network slice" is a fully operational logical network containing all required protocols and network resources. In some deployments, network slices can be considered as completely individual networks which however belong to the same network operator. This gives to the network operator the ability to share resources among the network slices for meeting the respective slice demands. In some deployments, network slices may share some user plane (UP) and/or control plane (CP) functionalities and/or the same pool of network resources may be shared by the network slices, e.g., a pool of radio resources, such as, frequency and time resources.

In the following, Radio Access Networks (RAN), e.g. <NUM> RANs, and network Slices are described. In <NUM> RAN, use cases originating from vertical industries (e.g. automotive, e-health, smart grid etc.) will be considered as drivers for <NUM> requirements. <NUM> network should be able to adapt to their needs in terms of latency, reliability, security, QoS, etc. To this end, the introduction of network slices, which are logical end-to-end sub-networks corresponding to different verticals, is envisioned as a key <NUM> feature according to <NPL>. Network slices may impact the RAN design, since RAN needs to be aware of the requirements from different slices and provide the services accordingly. However, due to different deployment and characteristics of the RAN at different site, handling of slices can be different. Moreover, dynamic situations at the RAN (e.g., load situation, UE mobility, characteristics of individual traffic flow, etc.) may influence the actual RAN treatments for certain slice. This disclosure targets at providing the slice-aware RAN services with joint considerations of diverse RAN characteristics and dynamic situations.

RAN configurations determine the RAN behavior and also the services provided by RAN. RAN may have some pre-defined abstract RAN Configurations per slice (e.g., specified in OAM). When RAN gets some indication of slice from the core network or User Equipment (UE) (E. , Slice ID), it maps Slice ID to pre-defined abstract RAN configurations. However, such abstract RAN Configuration is not enough to map slices to RAN configurations due to dynamic situations on channel / resource availability, user mobility, isolation requirements at RAN, etc. And local adaptation will be required to allow for flexible tuning of RAN protocol / split configuration based on parameters like slice scalability, RAN configuration sharing between slices, isolation and RAN characteristics.

Disclosed devices, systems and methods described in the following provide solutions for the above addressed issues by: <NUM>) Taking into account new context information (RAN characteristics, multiple communication protocols to CN, abstract RAN configuration-to-slice mapping and different service types), efficiently abstracting and building this context information at RAN side, mapping different traffic flows to different RAN configurations (RAN functions and deployment); and <NUM>) Defining the nature of slice aware RAN configuration and identifying who decides the RAN configurations and with which criteria; and determining how the RAN (re)configurations can be applied to the RAN. Such solutions are described in detail below with respect to <FIG>.

<FIG> shows a schematic diagram illustrating a context abstraction framework <NUM> for a Radio Access Network (RAN) according to the disclosure.

For each network slice, RAN characteristics <NUM> like UE Mobility, User/ Cell Density, Spectrum, Air Interface Variant <NUM>; required slice KPIs <NUM> (e.g., reliability, delay, etc.) and also used communication protocol <NUM> require different actions from RAN node (gNBs, access points) point of view, to meet the e2e KPIs <NUM>. So, different User Plane Configuration and possible different Functions / Protocols and Placements are considered. An abstraction of such context information (Communication Protocol, RAN characteristics (UE, BS), Abstracted RAN Configuration <NUM>, <NUM> and Slice Requirements (KPIs)) may be required to dynamically select the RAN configuration <NUM> and process the flows accordingly.

According to the disclosure, the RAN configuration can be divided in two phases: a pre-configuration phase, e.g. as described below with respect to <FIG> and a re-configuration phase (run time adaptation), e.g. as described below with respect to <FIG>. An abstract pre-configuration can be decided at the network deployment phase. In case of data flows, the pre-configuration can be adjusted according to the actual situation. This adjustment can be done with different time granularity based on the time granularity of the adaptation (e.g., the pre-configuration may need to be changed when the RAN deployment changes).

Subdividing the RAN configuration in these two phases provides the following advantages: The RAN configuration can be provided in an adaptive manner based on communication protocols of individual data flows (tunnel-based, tunnel-less, connection-less protocols, PDU types). The RAN configuration can further be adaptively provided in case of dynamic RAN deployment and RAN characteristics (e.g., function split, self-backhauling, dual connectivity, frequency band, etc.).

The adaptation of RAN configuration is not limited to the U-plane traffic from the CN. It can also apply on the C-plane traffic from the CN, which also needs to be transported to UE via RAN (e.g., NAS message). New/future communication protocols can also be supported by some extension of this disclosure.

The adaptation capability at the RAN decouples the influence of local variations/dynamics from the abstract per slice RAN configurations. This facilitates the slice management from an end to end point of view. The pre-configuration enables RAN to provide different services per slice in a short time. The RAN can also provide an expected range of KPIs per slice from the pre-configuration to the network (e.g., CN slice selection entity, end-end slice orchestrator).

With different levels of adaptation (based on time scale), the solution according to this disclosure is able to provide different granularity and speed of adaptation on the RAN configuration depending on the actual situation.

<FIG> shows a schematic diagram illustrating a pre-configuration process <NUM> of a RAN according to the disclosure.

At the management place, the RAN Slice Management logical entity <NUM> (which can reside at DSS <NUM>, which is a single vendor management entity for individual domains) defines initial abstract configuration per slice based on the target KPI <NUM> per slice type (e.g. eMBB, URLLC, mlOT) and RAN capabilities. Upon instantiation of a RAN slice which is handled at SSS <NUM> (cross domain multi-vendor management), a pre-configuration function <NUM> maps the received slice ID <NUM> to an initial abstract configuration, and sends a request <NUM> including this configuration to RAN part <NUM>. RAN <NUM> applies the correspondent RAN configuration to RAN functions at each node (e.g., gNB). An example RAN configuration includes context information (e.g. the configuration of protocols / functions which are required by this slice), but this decision is made having the following assumptions: <NUM>) To be supported slice-types, per slice RAN KPIs, where RAN capabilities are known; and <NUM>) Based on long term provisioning of resources (conditions and availability).

So, as can be seen in <FIG>, the RAN domain Slice Management Entity <NUM> (e.g. OAM, DSS) sends an abstracted version of this information to RAN nodes <NUM> (gNBs), as can also be seen in the message chart <NUM> described below with respect to <FIG> at the network deployment phase. This abstracted information can be sent via a RAN Slice Configuration message <NUM> (from DSS <NUM> to RAN node <NUM>) which includes: <NUM>) a list of Slice IDs; <NUM>) Abstract configuration in terms of protocols and RAN Functions per slice; and <NUM>) RAN part KPI.

Based on this pre-configuration message <NUM>, RAN <NUM> broadcasts (e.g. using SIB) the RAN configuration message <NUM> to the user terminals <NUM> using RAN Configuration message (RAN-UE) which includes: <NUM>) Slice ID; <NUM>) a set of network functions (NFs) as part of the configuration; and <NUM>) a flag for UL / DL, since the configuration may be different between uplink (UL) and downlink (DL).

Exemplary implementations of a Slice Management entity <NUM> as RAN Slice Management logical entity <NUM> residing in the DSS <NUM> and a RAN entity <NUM> residing in the RAN <NUM> are described below with respect to <FIG> and <FIG>.

<FIG> shows a schematic diagram illustrating a RAN configuration adaptation operation <NUM> for a RAN according to the disclosure.

The adaptation at the management layer as shown in <FIG>, e.g. by using an adaptation function <NUM>, is essential for gross adaptation of the RAN configuration (e.g., for change of the traffic situation at the RAN, group UE mobility, change of backhauling capacity, for better provisioning of the RAN resources etc.). This can be triggered by the certain amount of abstract resource/context changes <NUM> received from RAN control entity <NUM>. The RAN Slice Management Entity <NUM> (that can reside at DSS <NUM>) decides on the update of abstract configuration <NUM> and sends to RAN nodes <NUM> (gNBs) per slice, taking into account the resource situation changes and availability at RAN. Short-term or fine adaptation of RAN configuration can also be performed (e.g., communication protocol of individual traffic flow, individual UE mobility, etc.) to meet fast changes at the control layer especially for delay critical slices.

Here, a particular embodiment for the RAN side is to have RAN deployments from different vendors <NUM> with overlapping coverage or sharing of radio resources. In this case, new messages are forwarded between RAN elements (e.g. over Xn) for resource negotiations and indications <NUM> (e.g. load, interference, changes on AIVs).

Exemplary implementations of a Slice Management entity <NUM> as RAN Slice Management logical entity <NUM> residing in the DSS <NUM> and a RAN entity <NUM> residing in the RAN1, <NUM> or in the RAN2, <NUM> are described below with respect to <FIG> and <FIG>.

<FIG> shows an exemplary message sequence chart <NUM> for a RAN configuration operation including two phases according to an implementation form. The message sequence chart <NUM> describes the messages between different entities which are: UE <NUM>, RAN <NUM>, e.g. a RAN entity <NUM> as described below with respect to <FIG>, RAN Slice Management (DSS) <NUM>, e.g. a Slice management entity <NUM> as described below with respect to <FIG>, and Cross Domain Slice Orchestration <NUM>, e.g. an SSS <NUM> as described above with respect to <FIG>.

The message sequence chart <NUM> incorporates both pre-configuration phase (Phase <NUM>, <NUM>), e.g. as described above with respect to <FIG> and adaptation phase (Phase <NUM>, <NUM>), e.g. as described above with respect to <FIG>.

With respect to the pre-configuration phase <NUM>, the Cross Domain Slice Orchestration <NUM> transmits information <NUM> to RAN Slice Management <NUM>. This information <NUM> may include RAN Slice KPIs, Slice ID and/or NSSAI as described above with respect to <FIG>. Based on this information <NUM> RAN Slice Management <NUM> determines a suitable RAN pre-configuration <NUM> and transmits a RAN Slice configuration message <NUM> to the RAN <NUM>. The RAN Slice configuration message <NUM> may include e.g. a list of Slice ID, abstract RAN configuration in terms of functionality and/or RAN part KPI. Based on receiving this RAN Slice configuration message <NUM> the RAN <NUM> transmits a RAN configuration message <NUM> to the UE <NUM> or to multiple UEs. This RAN configuration message <NUM> may include the Slice ID, a set of network functions (NFs) and/or a flag for DL/UL, e.g. using SIB.

With respect to the adaptation phase <NUM>, RAN <NUM> determines context information, e.g. based on information elements <NUM> received from the UE <NUM> or UE/RAN condition <NUM> detected by the RAN <NUM>. As can be exemplified in <FIG>, based on the context information RAN <NUM> can send a Resource Situation Trigger message <NUM> (RAN-DSS) to trigger the adaptation <NUM> of configuration. The Management entity <NUM> then sends the RAN Slice Configuration Update message <NUM> (DSS- RAN) to the RAN <NUM>. The RAN Slice Configuration Update message <NUM> may include a List of Slice IDs, Updates on configuration in terms of protocols and RAN Functions per slice, and/or RAN part KPI. Based on this adaptation message <NUM>, RAN <NUM> can broadcast (e.g. using SIB) the adapted RAN configuration message <NUM> to the user terminals <NUM>.

Exemplary implementations of a Slice Management entity <NUM> as RAN Slice Management entity <NUM> residing in the DSS <NUM> and a RAN entity <NUM> residing in the RAN, <NUM> which may perform the above described message chart <NUM> are described below with respect to <FIG> and <FIG>.

One key idea is to build new context information based on the UE measurements on different AIVs, the communication protocols, and the slice related information (slice KPIs, slice to RAN mapping, slice indication, pre-configured abstract RAN configuration) from UE, RAN and CN. Based on this new context, the RAN configurations can be dynamically adjusted to meet the user / slice requirements. One other input to this decision can be the Level of RAN Slice Isolation. To optimize RAN Resource Utilization in RAN flexible isolation /sharing in different levels (Full, partial and no isolation) may be provided. In this case, the level of isolation is known the RAN configurations can be accordingly adjusted.

From UE side, 3GPP Release <NUM> provides context data as information elements (UE power preference indicator (PPI), RRM Measurements (RSRP, RSRQ) of serving and neighboring cells, CSI Measurements (CQI, RI, PMI), RLM Measurements, etc..

In <NUM> specification <NPL>, the extended UE context is investigated for multiple Air Interface Variants (AIVs) (e.g. eLTE, <NUM> AIVs) and <NUM> service types. These can be Inter / Intra-AIV measurements and interference levels, Mobility / Accuracy, etc..

Also, more context may be required from adjacent BSs or RAN nodes (BS capability, load, backhaul, cell density etc.) to build this new context. The new context exchange method within RAN can be: <NUM>) X2 between BSs (BS measurements, Interference Indications); <NUM>) Uu from UE to BS (CSI/RRM/RLM per AIV, Mobility).

The Context (e.g. Communication Protocol, Slice Information) can be retrieved from the Core Network (CN). From CN, the context will be mainly the communication protocol, which can be NAS (over SCTP), TCP (over GTP-U), UDP (over GRE), etc. The Context representation can have the following format: <PDU session ID, communication protocol, PDU type>, as described below with respect to <FIG>.

<FIG> shows a schematic diagram illustrating a protocol data unit (PDU) <NUM> with PDU type and CP indication via NG3 according to an implementation form. The exemplary PDU <NUM> includes transport layer section <NUM>, a user data section <NUM> and an encapsulation header <NUM> in between. The transport layer section <NUM> includes a L1/L2 header <NUM> and an outer IP header <NUM>. The user data section <NUM> includes a PDU header <NUM> and a PDU payload <NUM>. In the encapsulation header <NUM> information about PDU type and communication protocol <NUM>, i.e. information about the above described context, may be included.

The Context representation as described above with respect to <FIG> can have the following format: <PDU session ID, communication protocol, PDU type>, where: <NUM>) PDU type can be Ethernet, IP, unstructured PDU, etc. <NUM>) the context on communication protocol, PDU type is mapped to QoS profile at the RAN node (e.g., gNB).

Context exchange method between RAN <NUM> and CN <NUM>, <NUM> can be either via NG2 signaling <NUM> (in Control plane) as depicted in <FIG> and <FIG>, which is provided at PDU session establishment to the RAN together with the QoS profiles, e.g. according to 3GPP <NPL>.

Otherwise, this can be indicated via NG3 <NUM> (Data plane) as depicted in <FIG> and <FIG> as follows: Encapsulation header including PDU type and communication protocol in use according to TR <NUM>; and Transport layer header for retrieving the transport protocol (in case it is needed).

Furthermore, RAN may obtain the indication of slice, some optional required slice KPIs (e.g. reliability, delay, etc.) from UE/CN. It may also obtain the RAN isolation level for the supported slices and the slice-to-RAN performance mapping from the CN.

<FIG> shows an exemplary message sequence chart <NUM> for a RAN configuration and adaptation operation according to an implementation form. The message sequence chart <NUM> describes the messages between different entities which are: UE <NUM>, gNB1, <NUM>, e.g. a RAN entity <NUM> as described below with respect to <FIG>, neighbor gNB2, <NUM> (e.g. of different operator or different vendor), e.g. another RAN entity <NUM> as described below with respect to <FIG>, and CN <NUM>.

Taking into account the context abstraction, a particular implementation of the identification /enforcement of RAN configurations based on RAN characteristics, slice awareness, abstracted RAN configuration per slice and communication protocols is described in the following. To this end, a function who performs this slice-awareness processing is defined and can include functional elements for: <NUM>) Context Retrieval (from RAN, UE and CN) which are used for the decision; <NUM>) Flows Processing and Classifying to Queues; <NUM>) Per Queue basis RAN configuration mapping; <NUM>) Orchestrating parallel RAN configurations; and/or <NUM>) Triggering configurations to involved RAN nodes and the UE.

The processing of traffic flows can include the following: <NUM>) Generation of Virtual Queues for different Combinations of Communication Protocols (CPs), RAN Characteristics and abstract RAN Configurations; <NUM>) Mapping of each queue to a specific RAN configuration; <NUM>) Traffic Prioritization within each queue and among queues based on SLAs; and/or <NUM>) Forwarding of marked PDU data to different PDCP variants.

As can be seen in <FIG>, after receiving the context from UE <NUM> and CN <NUM> (by Information elements <NUM> and flow request <NUM>) and Resource Situation change indication <NUM> from neighbor RAN nodes <NUM>, each RAN node <NUM> performs the RAN Configuration and Adaptation functionality <NUM> and sends a RAN_Configuration message <NUM> (RAN node <NUM> to user terminal <NUM>) and RAN_Configuration_Update notification message <NUM> to other RAN nodes <NUM> (e.g. in a multi-vendor RAN embodiment).

<FIG> shows a block diagram of a Slice Management entity <NUM> according to the disclosure.

The Slice Management entity <NUM> may correspond to the Slice Management RAN entity <NUM> as described above with respect to <FIG> and <FIG> that may be used for a Radio Access Network (RAN) <NUM> as described above with respect to <FIG> and <FIG>. The Slice Management entity <NUM> includes a processor <NUM>.

The processor <NUM> is configured to receive RAN Slice information <NUM>, e.g. information <NUM> as described above with respect to <FIG>, in particular at least one Key Performance Indicator (KPI) <NUM>, a Slice Identifier (ID), and/or Network Slice Selection Assistance Information (NSSAI) <NUM>, e.g. as described above with respect to <FIG> and <FIG>. The processor <NUM> is configured to determine a configuration <NUM>, in particular a pre-configuration, e.g. a pre-configuration <NUM> as described above with respect to <FIG>, for at least one Slice of the RAN <NUM> based on the RAN Slice information <NUM>, <NUM>. The processor <NUM> is configured to transmit a RAN Slice configuration message, e.g. a message <NUM>, <NUM> as described above with respect to <FIG>, to the RAN <NUM> based on the configuration <NUM>.

The configuration <NUM> may include information for an operation of the slice at the RAN <NUM>, in particular information on a process, a protocol function, and/or a resource required by the Slice. The Slice Management entity <NUM>, <NUM> may be configured to reside as a RAN domain specific management entity at a Domain Support System (DSS) <NUM>, e.g. as described above with respect to <FIG>. The Slice Management entity <NUM>, <NUM> may include an interface to a cross domain management entity at a Slice Support System (SSS) <NUM>, e.g. as described above with respect to <FIG>, for communicating configuration information <NUM>.

The processor <NUM> may be configured to receive a Context Change message, e.g. a message <NUM> as described above with respect to <FIG>, from the RAN <NUM> indicating a change of context with respect to a change of information on a process, a protocol function, and/or a resource of the RAN <NUM> and/or traffic at the RAN <NUM>. The processor <NUM> may be configured to adjust the configuration <NUM> for the RAN <NUM> based on the change of context.

The Context Change message <NUM> may indicate a change of a traffic and/or a requirement related to traffic at the RAN <NUM>, handover requests from a group of UEs <NUM> and/or a change of backhauling conditions and availability. The processor <NUM> may be configured to transmit the RAN Slice configuration message <NUM> based on configuration updates <NUM> in terms of protocols and RAN functions for the at least one Slice, e.g. as described above with respect to <FIG>.

<FIG> shows a block diagram of a RAN entity <NUM> according to the disclosure.

The RAN entity <NUM> may correspond to an entity of the RAN <NUM> as described above with respect to <FIG> and <FIG>. The RAN entity <NUM> includes a processor <NUM> for processing the different functionality of the RAN entity.

The processor <NUM> is configured to receive a RAN Slice configuration message, e.g. a message <NUM>, <NUM> as described above with respect to <FIG>, in particular by a Slice Management entity <NUM>, <NUM> as described above with respect to <FIG>. The RAN Slice configuration message <NUM>, <NUM> comprises a configuration <NUM>, in particular a pre-configuration <NUM> as described above with respect to <FIG>, for at least one Slice of the RAN <NUM>. The processor <NUM> is further configured to transmit a RAN configuration message <NUM> to at least one User Equipment (UE) <NUM> based on the RAN Slice Configuration message <NUM>, <NUM>.

The RAN configuration message <NUM> may include a Slice ID of the at least one Slice, at least one network function associated with the at least one Slice and/or a flag indicating an uplink or downlink configuration, e.g. as described above with respect to <FIG>.

The RAN Slice configuration message <NUM> may include a configuration update, e.g. an update <NUM> as described above with respect to <FIG>, for the at least one Slice. The processor <NUM> may be configured to transmit the RAN configuration message <NUM> based on the configuration update <NUM>.

The processor <NUM> may be configured to detect a change of context, e.g. a context change <NUM> as described above with respect to <NUM>, at the RAN <NUM>, in particular a change of information on a process, a protocol function, and/or a resource of the RAN <NUM> and/or traffic at the RAN <NUM>, e.g. as described above with respect to <FIG>, and to transmit a Context Change message, e.g. a message <NUM> as described above with respect to <FIG>, to the Slice Management entity <NUM>, <NUM> responsive to detecting the change of context <NUM>, e.g. as described above with respect to <FIG>.

The processor <NUM> may be configured to detect the change of context <NUM> at the RAN <NUM> for the at least one Slice based on mobility information from the at least one UE <NUM> associated with the at least one Slice of the RAN <NUM>.

The processor <NUM> may be configured to detect the change of context <NUM> at the RAN <NUM> for the at least one Slice based on information from at least one neighboring RAN entity <NUM>, in particular a different operator RAN entity <NUM>, e.g. as described above with respect to <FIG>, the information indicating a change of context at the at least one neighboring RAN entity <NUM>, <NUM>.

The processor <NUM> may be configured to generate context information based on UE <NUM> measurements on different Air Interface Variants (AIV), communication protocols and/or Slice-related information from the at least one UE <NUM>, the RAN <NUM> and/or a Core Network (CN) <NUM>, <NUM> associated with the RAN <NUM>, e.g. as described above with respect to <FIG>.

The processor <NUM> may be configured to adjust the configuration <NUM>, <NUM> for the at least one Slice of the RAN <NUM> according to user and/or Slice requirements based on the context information, e.g. as described above with respect to <FIG> and <FIG>.

The processor <NUM> may be configured to generate the context information based on information from adjacent RAN nodes <NUM> and/or adjacent base station <NUM>, in particular information about capability, load, backhaul and/or cell density, e.g. as described above with respect to <FIG>. The information from the CN <NUM>, <NUM> may comprise Packet Data Unit (PDU) type and/or communication protocol indication <NUM>, e.g. as described above with respect to <FIG>. The information from the CN <NUM>, <NUM> may be indicated via RAN-to-Core-network interface <NUM> on user plane (UP) or via RAN-to-Core-network interface <NUM> signaling on control plane (CP), e.g. as described above with respect to <FIG> and <FIG>.

The present disclosure also supports a computer program product including computer executable code or computer executable instructions that, when executed, causes at least one computer to execute the performing and computing steps described herein, in particular the steps of the method described above. Such a computer program product may include a readable non-transitory storage medium storing program code thereon for use by a computer. The program code may perform the processing and computing steps described herein, in particular the method described above.

In the following, further example implementations are described.

A first example is related to a Two phase RAN configuration to support slice-aware RAN adaptation, comprising: a procedure and signal exchange in pre-configuration phase to decide on initial RAN configuration; and a procedure and signal exchange in run time adaptation phase to decide on RAN configuration adaptation.

A second example is related to an apparatus at RAN Management entity to decide on initial RAN Configuration, comprising: Receiving RAN capability, per slice KPI to decide on slice-pre configuration mapping table; Receiving slice ID(slice type) to decide on the abstraction of pre-configuration in the pre-configuration phase; Sending Abstract information on decided pre-configuration and adaptation to the RAN Element; and Report supported slice type to SSS and RAN Mgmt from other operators / vendors.

A third example is related to an apparatus at RAN Management entity to decide on RAN Configuration Adaptation, including: Receiving information on Resource Changes for the adaptation phase from RAN elements; Receiving resource and context changes from RAN Elements for the configuration adaptation; Sending information on decided configuration adaptation to the involved parties (RAN Element, mobile terminal); and Report abstracted information on configuration adaptation to SSS and RAN Mgmt from other operators / vendors.

A fourth example is related to an apparatus at RAN Element to support Configuration and adaptation decision, comprising: Report the resource/context change to RAN control entity.

A fifth example is related to a method to determine RAN configuration variants given the following constraints: Communication Protocol; Slice-awareness; Radio Access Network Characteristics (user mobility, density, spectrum, Al,CU/DU).

The solution described in this disclosure is standard relevant. Various messages and information elements may require changes in the signaling exchanged over some standardized interface (e.g., Uu, X2 and NG-C/U interfaces).

The disclosed solution also addresses the abstraction of pre-configuration, adaptation within one pre-configuration to actual use case and the adaptation of the pre-configuration itself. The change of RAN capability which is bind to pre-configuration needs to be reported via NBI of the RAN management plane to outside (e.g., e2e slice orchestrator). This can be observed by the signaling over NBI interface of the RAN management plane.

While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations, such feature or aspect may be combined with one or more other features or aspects of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "include", "have", "with", or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise". Also, the terms "exemplary", "for example" and "e.g." are merely meant as an example, rather than the best or optimal. The terms "coupled" and "connected", along with derivatives may have been used. It should be understood that these terms may have been used to indicate that two elements cooperate or interact with each other regardless whether they are in direct physical or electrical contact, or they are not in direct contact with each other.

Claim 1:
A Slice Management entity (<NUM>, <NUM>) for a Radio Access Network, RAN, (<NUM>), the Slice Management entity (<NUM>, <NUM>) comprising a processor (<NUM>), configured:
to receive from a cross domain slice orchestration RAN Slice information (<NUM>, <NUM>), including at least one of a RAN slice Key Performance Indicator, KPI, (<NUM>), a Slice Identifier, ID, Network Slice Selection Assistance Information, NSSAI, (<NUM>);
to determine a configuration (<NUM>), including a pre-configuration (<NUM>), for at least one Slice of the RAN (<NUM>) based on the RAN Slice information (<NUM>, <NUM>);
to transmit a RAN Slice configuration message (<NUM>, <NUM>) to the RAN (<NUM>) based on the configuration (<NUM>);
to receive a Context Change message (<NUM>) from the RAN (<NUM>) indicating a change of context with respect to a change of information on at least one of a process, a protocol function, a resource of the RAN (<NUM>), a traffic at the RAN (<NUM>);
to adjust the configuration (<NUM>) for the RAN (<NUM>) based on the change of context and
to send (<NUM>) a RAN slice configuration update message to the RAN.