Patent Description:
Example embodiments, although not limited to this, relate to gNBs. In NR, a gNB may comprise a CU (gNB-CU) and set of DUs (gNB-DU). The CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB, and controls the operation of one or more DUs. The DU is a logical node hosting RLC, MAC and PHY layers of the gNB. One DU supports one or multiple cells. A CU and a DU are connected to each other through the F1 Interface and they communicate with F1AP procedures.

The CU can be separated into a CU-CP including the functions on the control plane (RRC and PDCP-C) and a CU-UP including the functions on the user plane (SDAP and PDCP-U). CU-CP and CU-UP are connected via the E1 interface. In this case, the CU-CP is connected with the DU via the F1-C interface, whereas the CU-UP is connected with the DU via the F1-U interface. An example is shown in <FIG>, according to which a gNB <NUM> comprises a CU-CP <NUM> and a CU-UP <NUM> and two DUs, namely DU1 <NUM> and DU2 <NUM>.

The general principles for the specification of the E1 interface are as follows: The E1 interface is open. The E1 interface supports the exchange of signalling information between its endpoints. From a logical standpoint, the E1 is a point-to-point interface between a CU-CP and a CU-UP. The E1 interface separates Radio Network Layer and Transport Network Layer. The E1 interface enables exchange of UE associated information and non-UE associated information.

The general principles for the specification of the F1 interface are as follows: The F1 interface is open. The F1 interface supports the exchange of signalling information between its endpoints, in addition the interface supports data transmission to the respective endpoints. From a logical standpoint, the F1 is a point-to-point interface between the endpoints. The F1 interface supports control plane and user plane separation. The F1 interface separates Radio Network Layer and Transport Network Layer. The F1 interface enables exchange of UE associated information and non-UE associated information.

Thus, the current <NUM> architecture has defined a gNB disaggregated architecture exhibiting three entities within the gNB (CU CP, CU UP and DU) and interfaces between them: F1 interface between CU CP and DU, E1 interface between CU CP and CU UP.

The F1 interface between the CU CP and DU is defined as a legacy point to point interface since 3GPP Release <NUM>. F1AP is designed as a 3GPP F1-C Application Protocol over SCTP over F1.

The E1 interface between the CU CP and CU UP is defined as a legacy point to point interface since 3GPP Release <NUM>. E1AP is designed as a 3GPP E1-C Application Protocol over SCTP over F1.

In this scenario, it would be advantageous when services etc. could be handled more flexibly among CU-CP, CU-UP and DU of a gNB.

<CIT> describes a communications method and apparatus according to which an appropriate central unit-user plane may be selected for a PDU session. The method comprises receiving, at a central unit-control plane, a message from a core network element, where the message carries assistance information, and the assistance information includes an identifier of a first data network corresponding to a protocol data unit session. The method also includes determining, by the central unit-control plane based on the assistance information, a first central unit-user plane corresponding to the protocol data unit session.

<NPL> describes NF discovery and NF service discovery enabled by Core Network entities (NFs or Service Communication Proxy (SCP)) such that they discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type. Methods described are such that a consumer adds necessary discovery and selection parameters required to find a suitable producer to a service request. The SCP uses the request address and the discovery and selection parameters in the request message to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

Dependent claims define preferred embodiments.

Examples aim to provide measures for flexibly managing services such as UE context management services intra-RAN, such as among CU-CP, CU-UP and DU of an access node such as a gNB.

According to a first aspect, an apparatus, in proxy element, is provided which comprises:
at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:.

According to a second aspect, a method, in proxy element, is provided which comprises:.

The first and second aspects may be modified as follows:.

The at least one radio access service and/or slice and/or area may comprise a user equipment context management service.

The proxy element may be a signalling proxy function, and/or the network information storing element may be a network repository function.

According to a third aspect of the present invention a computer program product is provided which comprises code means for performing a method according to the second, aspect and/or its modifications when run on a processing means or module. The computer program product may be embodied on a computer-readable medium, and/or the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of arrangements. Arrangements not falling under the scope of the claims are to be considered examples suitable for understanding the invention. The description of arrangements is to be taken in conjunction with the appended drawings, in which:.

In the following, description will be made to example arrangements. It is to be understood, however, that the description is given by way of example only, and that the described example arrangements are by no means to be understood as limiting the present invention thereto.

As mentioned above, it would be advantageous when services etc. could be handled more flexibly among RAN elements and/or functions, e.g., CU-CP, CU-UP and DU of an access node such as a gNB. Thus, according to some arrangements, the functions of E1 and F1 interfaces, example UE context management, are re-designed to be performed using service based interfaces. For example, it might be beneficial to re-design the functions of F1 interface and the E1 interface as a service-based interface, based on the principles of service-based architecture.

However, when re-designing the F1 and E1 interfaces in this way, the following issues can be associated with the current design of F1 and E1 interfaces for many functions including the UE context management functions:.

Context management between CU-CP and DU is done over a point-to-point interface, i.e., F1, which is not easily scalable, especially when there is more traffic in hotspots. Likewise, context management between CU-CP and CU-UP is done over a point-to-point interface, i.e., E1, which is not easily scalable.

Issue <NUM>: On-demand/Dynamic activation/deactivation of a given slice or service in a gNB.

This implies that a slice/service specific CU-UP and/or gNB-DU needs to be instantiated only when there are UEs requesting/accessing such a service/slice. A static resource allocation (physical, hardware, RRM etc.) can cause a lot of resource wastage. The same principle would have to be used when an entirely new service/slice is requested by a UE. If the operator has provisioned a specific node for such service/slice, it could be activated.

It is noted that issue <NUM> can be particularly complex in a multi-vendor deployment because there could be OAM specific to CU-CP, CU-UP and DU. Co-ordination between them is complex and hence scalability is extremely complex.

Thus, example embodiments aim to enable flexible service management, e.g., UE context management between CU-CP and DU using a service based interface and UE context management between CU-CP and CU-UP using a service based interface.

In the following, a general overview of some example embodiments is described by referring to <FIG> and <FIG>.

As mentioned above, example arrangements aim to provide measures for flexibly managing services such as UE context management services intra-.

RAN, such as among CU-CP, CU-UP and DU of a gNB. The gNB is used to refer to an access node or base station, which is not limited to the <NUM> system. The elements of a gNB, e.g., CU-CP, CU-UP and DU are exemplarily used herein to illustrate the invention; it can be expected that beyond <NUM> networks, e.g., <NUM>, may define or implement new or other network elements and interfaces, where the various embodiments of the invention can be applied. In the following, radio access network (RAN) and access network (AN) are equivalent.

<FIG> shows a NRF <NUM> as an example for a network information storing element according toone arrangement. A procedure carried out by the NRF <NUM> is illustrated in <FIG>.

The NRF <NUM> comprises at least one processor <NUM> and at least one memory <NUM> including computer program code. The at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, is configured to cause the apparatus to perform: receiving information concerning at least one radio access service and/or slice offered by at least one user plane network control element or network access element (e.g., DU/CU-UP <NUM> shown in <FIG>) of an access node (such as a gNB) from the at least one user plane network control element or network access element, as shown in S11 of <FIG>, storing the information as shown in S12 of <FIG>, and, upon receiving a request for providing at least one service and/or slice and/or area in the access node from a requesting entity (e.g., CU-CP <NUM> shown in <FIG>), retrieving information concerning at least one user plane network control element or network access element offering the requested radio access service and/or slice and/or matching the requested area based on the received request from the stored information, as shown in S13 of <FIG>, and sending information concerning the at least one user plane network control element or network access element offering the requested radio access service and/or slice and/or matching the requested area to the requesting entity, as shown in S14 of <FIG>.

<FIG> shows a DU/CU-UP <NUM> as an example for a network access element (such as a distributed unit in an access node such as a gNB) or a user plane network control element (such as a central unit (CU) handling user plane (UP) in the gNB-CU) according to an arrangement. A procedure carried out by the DU/CU-UP <NUM> is illustrated in <FIG>.

The DU/CU-UP <NUM> comprises at least one processor <NUM> and at least one memory <NUM> including computer program code. The at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, is configured to cause the apparatus to perform: sending information concerning at least one radio access service and/or slice offered by the user plane network control element or the network access element to a network information storing element.

<FIG> shows a CU-CP <NUM> as an example for a control plane network control element according to an arrangement. A procedure carried out by the CU-CP <NUM> is illustrated in <FIG>.

The CU-CP <NUM> comprises at least one processor <NUM> and at least one memory <NUM> including computer program code. The at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, is configured to cause the apparatus to perform: sending a request for providing at least one radio access service and/or slice and/or area in the access node to a network information storing element (e.g., NRF <NUM> shown in <FIG>), as shown in S31 of <FIG>, and receiving information concerning at least one user plane network control element or network access element (e.g., DU/CP-UP <NUM> shown in <FIG>) offering the requested radio access service and/or slice and/or matching the requested area from the network information storing element, as shown in S32 of <FIG>.

<FIG> shows a SCP <NUM> as an example for a proxy element according to an embodiment of the invention. A procedure carried out by
the SCP <NUM> is illustrated in <FIG>.

The SCP <NUM> comprises at least one processor <NUM> and at least one memory <NUM> including computer program code. The at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, is configured to cause the apparatus to perform: receiving a request for providing at least one radio access service and/or slice and/or area from a control plane network control element (e.g., CU-CP <NUM> shown in Fig. 1B) of an access node such as a gNB, as shown in S41 of <FIG>, sending a request for information concerning the at least one radio access service and/or slice and/or area to a network information storing element (e.g., NRF <NUM> shown in <FIG>), as shown in S42 of <FIG>, receiving information concerning at least one a user plane network control element or at least one network access element of the access node offering the radio access service and/or or slice and/or matching the requested area from the network information storing element, as shown in S43 of <FIG>, selecting a user plane network control element or a network access element based on the information for using the at least one radio access service and/or slice and/or area, as shown in S44 of <FIG>, sending information on the requested radio access service and/or slice and/or area to the selected user plane network control element or network access element, as shown in S45 of <FIG>, receiving the provided radio access service from the selected user plane network control element or network access element (e.g. a context ID if the radio access service is UE context management service), as shown in S46 of <FIG> and sending the provided radio access service to the requesting control plane network control element, as shown in S47 of <FIG>.

The elements <NUM> to <NUM> described above may further comprise I/O unit <NUM>, <NUM>, <NUM>, <NUM>, which are capable of transmitting to and receiving from other network elements or functions, such as virtual network functions (VNFs).

Thus, according to some example arrangements as described above, user plane network control elements (e.g., CU-UP) and/or network access elements (e.g., DUs) may register radio access services and/or slices and/or areas which they can offer with a network information element (e.g., NRF). A network element (e.g., CU-CP) requesting such a radio access service/slice may request the NRF to provide it with information concerning the services offered by the user plane network control elements and/or network access elements, so that the requesting network element can easily use the service.

According to example embodiments of the invention, the requesting network element (e.g., CU-CP) may request for information concerning offered radio access services and/or slices or areas via a proxy element (e.g., a SCP).

Thus, it can be possible to provide measures for managing services such as UE context management services without pre-established F1 and/or E1 interfaces.

In the following, this is further described by referring to some further detailed embodiments.

According to some arrangements, the service-based interface (SBI) architecture is leveraged to enable a CU-CP to discover the UE context management service associated with a DU/Cell NF and to enable the discovery of an appropriate CU-UP NF suitable for the involved UE context management service and/or slice and/or to enable the discovery of the UE context management service associated with the CU UP.

According to example arrangements, the following is used:
A RAN-NRF (or NG-RAN node-NRF) is used for discovery of a target entity (CU UP and/or DU) for a target service, and according to example embodiments of the invention, an SCP is used as proxy routing.

A DU/Cell registers to the NRF, with NF=DU/Cell ID (function). A CU-UP also registers to the NRF, with NF=CU UP ID (function). For example, an NF profile (e.g., area equals list of TAIs/cells, list of slices, list of services) may be supplied form the DU/Cell and/or the CU-UP to the NRF, e.g., based on provisioning from the OAM.

A list of services of the SBI API may be provided by the NRF, e.g. as follows:.

Two modes of operation may be applied in this way:.

Arrangements also offer the following other key characteristics:.

The services subscribed could include discovery and/or dynamic activation/deactivation of a given service/slice from a CU-UP and/or gNB-DU.

The trigger for activation could be a service request from a UE and the trigger for deactivation could be that the service is not being accessed by any UE in the gNB.

In the following, a first arrangement and a second arrangement are described by referring to <FIG> and <FIG>.

In the first arrangement, the discovery is done by CU-CP directly to the RAN NRF and the SCP is not used.

In the second arrangement, in accordance with an example embodiment of the invention, the CU-CP uses the SCP for the discovery and the routing of the HTTP request.

In the following, the first arrangement is described in more detail by referring to the call flow shown in <FIG>. As mentioned above, according to the first embodiment, the discovery is done by CU-CP directly with the RAN NRF, and the SCP is not used.

This is illustrated in the call flow shown in <FIG>, in which the main processes in this connection are shown.

Process <NUM>: all DU/Cells register their services offered to the RAN NRF including the radio access service called UE Context Management and the associated attributes such as the supported slices and/or the associated area (e.g. list of TAIs).

In <FIG>, this is shown in A1: The DU/Cell <NUM> registers its radio access services with the NRF (which may be a RAN-NRF of a NG-RAN node NRF, as mentioned above) by sending a message "Register (NF ID = DU1/Cell1, list TAIs, slices <NUM>,<NUM>,<NUM>, list Services) to the NRF. As indicated in A2, two services are exemplarily registered, namely Service <NUM>: UE context manage, which is identified by IP@<NUM>, and Service <NUM>: cell manage, which is identified by IP@<NUM>.

Process <NUM>: all CU UPs register their radio access services offered to the RAN NRF including the service called UE Context Management and the associated attributes such as the supported slices and/or associated areas (e.g. list of TAIs).

In <FIG>, this is shown in A3, in which CU-UP1 registers its radio access services with the NRF by sending a message "Register (NF ID = CU-UP1, list of cells, slices <NUM>,<NUM>, list Services)" to the NRF. As indicated in A2, the registered service is Service <NUM>: UE context manage, which is identified by IP@<NUM>. In A5, CU-UP2 registers its services with the NRF by sending a message "Register (NF ID = CU-UP2/Cell1, list of cells, slices <NUM>,<NUM>, list Services)" to the NRF. As indicated in A6, the registered service is Service <NUM>: UE context manage, which is identified by IP@<NUM>.

Process <NUM>: CU-CP receives a connection request for a UE for a given DU/Cell <NUM> and triggers the Discovery Request to RAN NRF with associated slice <NUM> (or list of slices) to learn the URI (IP address) at which it could reach the UE context management service of DU/Cell1 for the indicated radio access service or slice(s).

In detail, in A7 the CU-CP sends a message "Discovery request (target DU1/Cell1, slice <NUM>, Service = UE context manage)" to the NRF. The NRF responds with a message "Discovery response (target DU1/Cell1, IP@<NUM>)". Thus, the CU-CP now knows that the requested service is offered by DU1/Cell1, and has the necessary IP address information.

Process <NUM>: Upon receiving the response from RAN NRF, the CU-CP uses the received URI to request the service of UE context management from DU1/Cell <NUM> for the indicated slice(s) and receives from DU/Cell <NUM> a DU UE Context ID.

In detail, in A9, the CU-CP sends a message "HTTP Post (UE context manage content (slice <NUM>))" to the DU1/Cell1, and in A10, the DU1/Cell1 responds with "HTTP Post Response (UE context manage response content = DU1 UE context ID)".

Process <NUM>: In parallel, the CU-CP triggers the Discovery Request to RAN NRF with associated slice <NUM> (or list of slices) to learn the URI (IP address) at which it could reach the UE context management service of an appropriate CU-UP for the indicates slice(s).

In detail, in A11, the CU-CP sends a message "Discovery request (target CU-UP, slice <NUM>, Service = UE context manage)" to the RAN NRF, which responds with "Discovery response (target CU-UP2, IP@<NUM>)" in A12. Hence, the CU-CP knows that CU-UP2 offers the requested service, and the IP address for the service is IP@<NUM>.

Process <NUM>: Upon receiving the response from RAN NRF, CU-CP uses the received CU-UP <NUM> and associated URI to request the service of UE context management from CU-UP <NUM> for the indicated slice(s) and receives from CU UP <NUM> a CU-UP <NUM> UE Context ID.

In detail, in A13, the CU-CP sends a message "HTTP Post (UE context manage content (slice <NUM>))" to the CU-UP2, which responds with a "HTTP Post Response (UE context manage response content = CU-UP2 UE context ID)" in A14.

It is noted that the order of the flows can be different, e.g., the interaction between the CU-CP and the CU-UP (process <NUM>) may be carried out first, and then the interaction between the CU-CP and DU/Cell (process <NUM>) may be carried out.

According to the first arrangement, the Discovery Request message is an example for the message sent in S13 shown in <FIG> or S31 shown in <FIG>, and the Discovery Response message is an example for the message sent in S14 shown in <FIG> or S32 shown in <FIG>.

It is also noted that the association between the discovered CU-UP and DU for the UE's radio access service or slice is established by the CU-CP. This implies that the further communication in the context of the said UE can occur directly between CU-CP, CU-UP and the DU respectively. That is, the CU-CP may maintain the association between the CU-CP and the CU-UP and/or UE for further transmissions, or the CU-CP may use the association with the CU-UP or the DU to directly request the service. In the latter case, the NRF is only used for getting the right CU UP/DU then the CU CP asks directly the service to CU UP/DU over the legacy interface.

Moreover, in all the above, RAN NRF can be substituted to NG-RAN node-NRF whenever an NRF at one NG-RAN node level would be used.

In the following, the second arrangement, in accordance with an example embodiment of the invention is described by referring to <FIG>. As mentioned above, according to the second arrangement, the CU-CP uses (interacts with) the SCP for the discovery and the routing of the HTTP request.

This is illustrated in the call flow shown in <FIG>. In this call flow only the interactions between CU CP and CU UP are shown, but this is also applicable to the interactions between CU CP and DU (and/or DU/Cell) which can be easily deduced.

Process <NUM>: all CU UPs register their radio access services offered to the RAN NRF including the service called UE Context Management and the associated attributes such as the supported slices and/or area (e.g. list of TAIs).

In detail, in B1, CU-UP1 sends a message "Register (NF ID = CU-UP1, list of cells, slices <NUM>, <NUM>, list Services)" to the NRF. As indicated in B2, the registered service is Service <NUM>: UE context manage, which is identified by IP@<NUM>. In B3, CU-UP2 sends a message "Register (NF ID = CU-UP2, list of cells, slices <NUM>,<NUM>, list Services)" to the NRF. As indicated in B4, the registered service is Service <NUM>: UE context manage, which is identified by IP@<NUM>.

Process <NUM>: The CU-CP receives a connection request for a UE for a given DU/Cell <NUM> and sends an HTTP Post request to the SCP including the targeted slice(s) and node type (CU UP) in the Discovery header and the requested service (UE context manage) in the Discovery payload.

In detail, in B5, the CU-CP sends a message "HTTP Post (discovery header = target CU-UP, slice <NUM>) payload = UE context manage)" to the SCP.

Process <NUM>: The SCP triggers the Discovery Request to RAN NRF to learn the URI (IP address) at which it could reach the UE context management service of a CU UP suitable for the indicated slice(s).

In detail, in B6, the SCP sends a message "Discovery Request (target CU-UP, slice <NUM>, service = UE context manage)" to the RAN NRF, which responds with "Discovery response (target CU-UP2, URI)" in B7.

Process <NUM>: Upon receiving the response from the RAN NRF, the SCP uses the received CU-UP2 and associated URI to request the service of UE context management from CU-UP2 for the indicated slice(s) and receives from CU-UP2 a CU-UP2 UE Context ID.

In detail, in B8, the SCP sends a message "HTTP Post (payload = UE context manage)" to the CU-UP2. The CU-UP2 responds with "HTTP Post Response (UE context manage response (CU-UP <NUM> UE context ID)" in B9 to the SCP.

Process <NUM>: the SCP provides the received CU-UP <NUM>, CU-UP <NUM> UE Context ID to the source CU-CP in HTTP Post Response message.

In detail, the SCP forwards a message "HTTP Post Response (UE context manage response (CU-UP2 UE context ID)" to the CU-CP in B10.

Thus, in contrast to the first arrangement, according to the second arrangement, the CU-CP sends the service request to SCP and the next message it receives is directly the provided service.

According to the second arrangement, the HTTP Post message is an example for the message sent in S41 shown in <FIG>, the HTTP Post response message is an example for the message sent in S47, the Discovery Request message is an example for the message sent in S42 shown in <FIG>, and the Discovery Response message is an example for the message sent in S43 shown in <FIG>.

It is noted that, similar as according to the first arrangement, in all the above, RAN NRF can be substituted to NG-RAN node-NRF whenever an NRF at one NG-RAN node level would be used.

The above-described example arrangements are only examples and may be modified, e.g., the message content can be modified.

Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

In general, the example arrangements may be implemented by computer software stored in the memory (memory resources, memory circuitry) <NUM>, <NUM>, <NUM>, <NUM> and executable by the processor (processing resources, processing circuitry) <NUM>, <NUM>, <NUM>, <NUM> or by hardware, or by a combination of software and/or firmware and hardware.

As used in this application, the term "circuitry" refers to all of the following:.

The terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as non-limiting examples.

The memory (memory resources, memory circuitry) <NUM>, <NUM>, <NUM>, <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, and non-transitory computer-readable media. The processor (processing resources, processing circuitry) <NUM>, <NUM>, <NUM>, <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi core processor architecture, as non-limiting examples.

Claim 1:
<NUM>. An apparatus, in proxy element, comprising:
at least one processor and at least one memory including computer program code,
the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:
receiving, from a control plane network control element of an access node, a request (B5) for providing at least one radio access service <NUM> and/or slice and/or area;
sending, to a network information storing element, a request (B6) for information concerning the at least one radio access service and/or slice and/or area;
receiving, from the network information storing element, information (B7) concerning a user plane network control element or at least one network access element, the user plane network control element or the at least one network access element belonging to an access node offering the at least one radio access service and/or slice and/or matching the requested area,
selecting, based on the information, a user plane network control element or a network access element for using the at least one radio access service and/or slice and/or area,
sending, to the selected user plane network control element or network access element, information (B8) on the requested radio access service and/or slice and/or area;
receiving (B9), from the selected user plane network control element or network access element, the provided radio access service and/or slice and/or area; and
sending (B10) the provided radio access service and/or slice and/or area to the requesting control plane network control element;
wherein the at least one radio access service and/or slice and/or area comprises a user equipment context management service.