WO2019083522A1

WO2019083522A1 - Automatic selection of cu-up instances for 5g

Info

Publication number: WO2019083522A1
Application number: PCT/US2017/058258
Authority: WO
Inventors: Anand Bedekar
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2017-10-25
Filing date: 2017-10-25
Publication date: 2019-05-02
Anticipated expiration: 2020-04-25

Abstract

A method includes: receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU); using one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection; providing the identifiers for the one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and establishing the UE/flow context in one of the one or more suitable CU-UP instances to complete the connection.

Description

AUTOMATIC SELECTION OF CU-UP INSTANCES FOR 5G

TECHNICAL FIELD

This disclosure relates to 5G network deployment, and, in particular, to the problem of ensuring that each user equipment (UE) or flow is served by the right instance of CU-UP as best meets its flow and slice needs.

BACKGROUND

In 3 GPP, the 5G radio access network (RAN) architecture will include a centralized part, or central unit (CU), and a distributed part, or distributed unit (DU). The CU and the DU will be connected to one another by a so-called Fl interface.

As shown schematically in Figure 1, the CU may be split into a CU-UP (central unit-user plane) 12, 14 and a CU-CP (central unit-control plane) 16. The CU-UP 12, 14 and the CU-CP 16 will be connected to one another by a so-called El interface, and the Fl interface will be split between Fl-c and Fl-u interfaces for the control and user planes, respectively.

The CU-CP 16 and/or the CU-UP 12, 14 may be virtualized in the "cloud", as suggested by the cloud shapes in Figure 1, and designed for "elastic scaling", so that, as the load on each fluctuates, scaling will lead to a multiple (time-varying) number of instances of each serving a set of cells within a coverage area.

One reason for splitting the CU into CU-CP 16 and CU-UP 12, 14 is to enable independent placement of the CU-UP 12, 14 relative to the CU-CP 16, with CU- UP 12, 14 instances being placed topologically at different locations relative to CU-CP 16 instances. For example, CU-CP 16 may be in a centralized data center, while CU-UP 12, 14 may be in an edge cloud data center.

Further, CU-UP 12, 14 instances may be placed at topologically different locations relative to different DUs 18, the DUs 18 being analogous to base stations or gNBs. For example, to support applications with low E2E (equipment to equipment) user-plane latency expectations, certain CU-UP 12, 14 instances may be placed "close" to certain DUs 18, such as within 1 to 2 ms latency of the DU 18, but may be at greater latencies from other DUs 18. In general, any given CU-UP 12, 14 instance will have different latencies relative to different DUs 18.

Alternatively, for applications having ultra-high throughput needs but relaxed latency needs, CU-UP 12, 14 instances may be placed in edge clouds at 10 to 20 ms latency from the DU 18, but providing highly scalable computing to accommodate high throughput for virtuahzed CU-UP 12, 14 instances.

With network slicing, including RAN (radio access network) slicing in 5G, different slices may have very different service needs, and may require very different functional behaviors. To provide different behaviors, different types of CU-UP 12, 14 instances, optimized for different network or service characteristics, may be instantiated, such as from different virmal-machine images. For example, some CU-UP 12, 14 instances may be optimized for high throughput, such as ciphering acceleration or multi- connectivity algorithms. Further, some instances of CU-UP 12, 14 may have special multi-connectivity algorithms needed for certain tenants or services. Some instances of CU-UP 12, 14 may be optimized or configured only to serve certain network slices.

Thus, the system architecture may include a diverse collection of CU-CP 16 and CU-UP 12, 14 instances and DUs 18 in which: (1) different instances of CU-UP 12, 14 are placed at different topological locations relative to CU-CP 12 and DUs 18; (2) different instances of CU-UP 12, 14 are optimized for different characteristics behaviors suited for different slices; (3) there is a multiple, time-varying number of instances of each type of CU-UP 12, 14; and (4) different types of instances of CU-UP, optimized for different characteristics, may be from different vendors.

Clearly, in such a system architecture, it is necessary to ensure that each UE or flow, which may have specific needs for certain service characteristics, and which may possibly be associated with a given network/RAN slice, is served by the right CU- UP 12, 14 instance, so that the right behaviors or characteristics are provided.

For this reason, a mechanism ensuring that each UE or flow is served by the right instance of CU-UP 12, 14 according to its respective flow and slice needs in the 5G network deployment scenario described above will be required. Such a mechanism is provided by the present invention.

SUMMARY

In a first aspect of the present invention, a method comprises: receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU); using one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection; providing said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and establishing the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection.

In a second aspect of the present invention, an apparatus comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform the following: receive a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU); use one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection; provide said identifiers for said one or more suitable CU-UP instances to a central unit- control plane (CU-CP); and establish the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection.

In a third aspect of the present invention, an apparatus comprises: means for receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU); means for using one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection; means for providing said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and means for establishing the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection.

In a fourth aspect of the present invention, a computer-program product comprises a non-transitory computer-readable storage medium bearing computer program code embodied therein for use with a computer. The computer program code comprises code for performing at least the following: receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU); using one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection; providing said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and establishing the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection. BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other aspects of these teachings are made more evident in the following detailed description, when read in conjunction with the attached drawing figures.

Figure 1 is a schematic representation of a 5G radio access network (RAN) architecture.

Figure 2 is a schematic representation of a 5G radio access network (RAN) architecture modified in accordance with the present invention.

Figure 3 is a signaling diagram illustrating steps by which a "CU-UP selector" functional entity updates mapping for instances within the CU-CP.

Figure 4 schematically illustrates a proposed interface to a lookup server from a CU-UP and a network orchestration system.

Figure 5 shows an exemplary apparatus, which may serve as the CU-CP in the event that the CU-CP is not virtualized.

DETAILED DESCRIPTION

In accordance with the present invention, the CU-CP 16 includes a "CU- UP selector" functional entity 20, as shown in Figure 2, a schematic representation of a 5G radio access network (RAN) architecture modified in accordance with the present invention. The "CU-UP selector" functional entity 20 has the following aspects:

1. The "CU-UP selector" functional entity 20 maintains one or more mappings of network or service identifiers to a list of CU-UP instance identifiers suitable for each slice ID. The instance identifiers can identify CU-UP instances, and/or functional entity instances within the DU, and, optionally, instances of functional entities, or VNFCs (virtual network function components), internal to the CU-CP;

2. The network or service identifiers may comprise, for example, network slice identifiers. The network or service identifiers may also comprise a latency value describing the latency between CU-UP instances and one or more DUs within the coverage area. The mapping maintained by the "CU-UP selector" functional entity 20 may be instantiated based on a mapping providing the latency of each CU-UP relative to each DU within its coverage area. The network or service identifiers may comprise other attributes, such as the bandwidth of the path between the DU and a CU-UP instance, or the capacity of the CU-UP instance, and so forth;

3. Referring to Figure 3, a signaling diagram illustrating steps by which a "CU-UP selector" functional entity updates mapping for instances within the CU-CP, at appropriate instants of time, for example, periodically, or based on events, such as UE connection requests, the "CU-UP selector" functional entity 20 updates its mappings at 36 (i) by sending to a suitable server, such as lookup server 22, a query 32 providing an identifier of DU 18 or gNB; an identifier identifying the desired service as a CU-UP function; and additional information including one or more slice identifiers, and/or a desired latency relative to the DU; and (ii) by receiving a response 34 from the server containing a list of CU-UP instance identifiers suitable for the provided DU/gNB identifier, supporting the slice identifiers provided in the query, and satisfying the desired latency of CU-UP instances relative to the provided DUs/gNBs. The query 32 may be a DNS (domain name system) query to a DNS server 22;

4. On receiving a request 38 from a UE/flow connecting to a given DU 18, possibly with a slice ID, the "CU-UP selector" functional entity 20 (i) uses its mappings to select one or more suitable instances, and (ii) provides the instance identifier to appropriate parts of the RAN-CU-CP. (iii) The RAN-CU-CP will then further establish the UE or flow context in the selected instance(s), for example, the CU-CP communicates with the selected CU-UP instance over the El interface to establish UE/flow context within the desired slice, or notifies the DU 18 over the Fl interface to establish appropriate Fl-u association with the chosen CU-UP. The request 38, for example, may be an RRC (radio resource control) conn req (connection request), an HO (handover) request, a flow creation req, or a dual/multi-conneetivity leg change; and

5. The "CU-UP selector" functional entity 20 also supports an interface 24, such as an API (application programming interface), allowing an operator to provide rules to modify the logic for the selection of CU-UP instances, for example, (i) by receiving a command over the interface 24 to configure prioritization rules for the selection of the interface, and, when using the mapping to select a suitable instance, (ii) by taking the configured prioritization rules into account for selecting the suitable instance. In brief, the present invention provides a method to automatically provision a lookup server 22 with information to allow it to respond to queries 32 requesting a set of services with certain characteristics (slice identifier, latency) for a given DU 18 or gNB.

The following are further details about certain embodiments where queries to a DNS server, that is, lookup server 22, are used to update the mapping. Reference will again be made in the following discussion to Figure 3, the signaling diagram illustrating steps by which a "CU-UP selector" functional entity 20 updates mapping for instances within the CU-CP 16.

At appropriate instants of time, for example, periodically, or based on events, such as UE connection requests, the "CU-UP selector" functional entity 20 updates the mapping by:

(i) querying a suitable server 22, such as a DNS (domain name system) server, with a query 32 that provides an identifier of a DU/gNB, for example, an FQDN (fully qualified domain name) formed according to certain rules, including one or more additional identifiers of network or service characteristics, such as a network slice identifier or a latency between the DU and the desired CU-UP instance. The query can be a DNS query for an NAPTR (name authority pointer) record that provides the following (based on IETF RFC 3958):

^• A lookup identifier that may correspond, for example, to the location of the gNB/DU where the request is received, such as in the form of a Fully Qualified Domain Name (FQDN);

• For example, a DU ID can be represented as a FQDN as "du- id.ran.mnc<MNCID> .mcc<MCCID> .3 gppnetwork.org";

^• An identifier identifying the type of function or service requested, in this case, a CU-UP service: this may be indicated in the query as an "app-service" which may be represented, for example, as "x-3gpp-ran-cu-up";

^• Optionally, an "app-protocol" identifying the desired protocol, such as "x- 3gpp-fl-gtp" (assuming GTP is the desired protocol to be used over Fl-u, or, alternatively, GRE (generic routing encapsulation), and so forth); • If the additional identifier of network or service characteristic is a slice identifier, it may be represented as an additional qualifier for "app -protocol" that identifies the desired slice identifier: "slice-<Slice-identifier>";

• If the additional identifier of network or service characteristic is a network latency or bandwidth between the DU and the desired CU-UP instance, it may be represented for example,

— "latency-<max-tolerable-latency-in-ms>" - for example, "latency-20ms"; and

— ''bandwidth-<rnin-desired-bandwidth-in-Mbps>" - for example, "bandwidth-10Mbps";

• When multiple "app-protocol" identifiers are to be provided, they can be concatenated with "+". Thus, the app-service/app-protocol in the query may look like: x-3gpp-ran-cu-up:x-3gpp-fl-gtp+slice-100+latency- 20ms+b and width- 10Mbps, indicating that the desired service is a CU-UP instance, following a desired protocol of GTP over the Fl interface, for a slice identifier of 100, with the desired CU-UP instance being within no more than 20 ms of the DU and supporting a network bandwidth of at least 10 Mbps towards the DU, as indicated in Figure 3;

(ii) receiving a response 34 from the server containing a list of instance identifiers that are suitable for the slice identifiers provided in the query. The response 34 can be a DNS record providing the following:

• An NAPT record providing the FQDN(s) of the instance(s) and the matching app-service/app -protocol/qualifiers provided in the query, such as additional identifiers of network or service characteristics based on those provided in the query; and

• Additionally, A AAAA records providing IPv4/IPv6 addresses of the instances.

The following are further details about certain embodiments describing the selection of CU-UP 12, 14 on receiving a request 38 from a UE:

- The request could be one of: an RRC connection request, an HO request, a dual/multi-connectivity leg add/mod request, or a flow/bearer creation request. Any of these could also contain slice identifiers, or the slice identifier may be associated with the UE. On receiving a request 38 from a UE/flow connecting to a given DU 18, possibly indicating a slice ID that the UE or flow is part of, the "CU-UP selector" functional entity 20:

(i) uses its mappings to select one or more suitable instances:

- The "CU-UP selector" functional entity 20 can sort the NAPTR records received from the DNS server 22 according to the rules of IETF RFC 3958;

- If the desired flow or slice has latency targets, the CU-UP 12, 14 can be selected to satisfy the latency target, using the mapping to look up CU-UP instances that are within the desired latency from the DU 18;

- If a slice identifier is associated, the CU-UP 12, 14 can be selected to match the slice identifier;

(ii) provides the selected instance identifier to appropriate parts of the RAN-CU-

CP:

- The "CU-UP selector" functional entity 20 is a logical part of the RAN-

CU-CP. The interaction between this and other parts of the RAN-CU-CP is currently not in the scope of standardization. In the present implementation, the "CU-UP selector" functional entity 20 may be a micro service that interacts with other CP micro services, or may be part of a virtual machine;

(iii) the RAN-CU-CP will then further establish the UE or flow context in the selected instance(s); for example, the CU-CP communicates with the selected CU-UP instance over the El interface to establish UE/flow context within the desired slice, or notifies the DU over the Fl interface to establish appropriate Fl-u association with the chosen CU-UP.

The following are further aspects of embodiments wherein queries 32 to a DNS server 22 are used, describing the automatic provisioning of a lookup (DNS) server 22 to achieve the desired functionality:

· In the above, it is assumed that the lookup server 22, such as a DNS server, has the requisite information regarding CU-UP 12, 14 instances so that it can respond to the queries;

• Since the information about CU-UP instances may be relatively large, due to large number of CU-UP instances compared to SGWs, for example, and also time-varying due to elastic scaling and due to variable network latencies, it is desirable to have a method that automatically updates this information at the lookup server 22;

• Thus, an interface 42 to the lookup server 22, either directly from CU-UP 12, 14, or from a network orchestration system, that allows automatically updating these characteristics information at the lookup server 22 is also proposed, as shown in Figure 4;

• For example:

- Each CU-UP 12, 14 can periodically measure its latency relative to each DU 18 of interest, such as by using TWAMP (Two Way Active Measurement Protocol) protocol. The CU-UP 12, 14 can then use the proposed interface 42 to automatically update the information database at the lookup server 22, When a CU-UP updates the lookup server 22, the lookup server 22 can use the updated information in formulating its response 34;

- When elastic scaling creates, or deletes, instances of CU-UP 12, 14, the service orchestrator 44 can use the interface 32 to automatically update the lookup server 22, for example, to provide it with updated information on the ΓΡ addresses or FQDNs of CU-UP instances;

- When a new slice is configured, appropriate CU-UP instances will be assigned to the slice by the slice orchestration system 46. The slice orchestrator 46 can use the proposed interface 42 to update the lookup server 22 about the slice identifiers supported by CU-UP instances.

In the present method, the CU-CP 16 will provide the identifier of a specific DU 18 or gNB/ID in the query 32. This is very useful for the RAN, rather than just providing a coarse identifier like TAC (tracking area code), because CU-UP instances may be placed at locations close to certain DU/gNB for low latency.

The present method also allows the query 32 to contain a latency bound, allowing identification of CU-UP instances that are within a certain latency of a given DU 18.

The present method further enables querying based on slice identifier, allowing selection of instances that provide characteristics behaviors that are suitable for a given slice. The present invention further enables an automatic method of selecting CU-UP. This automation is key to allowing operators to deploy edge-cloud-based (virtualized) CU-UP which will provide elastic scaling, as well as more distributed deployments of CU-UP which will enable lower E2E latencies.

Figure 5 shows an exemplary apparatus 50, which may serve as CU-CP 16 in the event that the CU-CP is not virtualized.

Apparatus 50 includes one or more processors 52, one or more memories 54, and an interface 56, interconnected using one or more buses 58. The one or more memories 54 include a computer program 60, which causes the apparatus 50 (CU-CP 12) to perform one or more of the operations described herein, and which creates "CU-UP Selector" functional entity 20.

Interface 56 connects to application programming interface (API) 24 and to lookup server 22, as described above.

In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It should thus be appreciated that at least some aspects of the exemplary embodiments of the inventions may be practiced in various components, such as integrated circuit chips and modules, and that the exemplary embodiments of this invention may be realized in an apparatus that is embodied as an integrated circuit. The integrated circuit, or circuits, may comprise circuitry, as well as possibly firmware, for embodying at least one or more of a data processor or data processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this invention.

Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. For example, while the exemplary embodiments have been described above in the context of advancements to the 5 G N system (Rel.-15), it should be appreciated that the exemplary embodiments of this invention are not limited for use with only this one particular type of wireless communication system. The exemplary embodiments of the invention presented herein are explanatory and not exhaustive or otherwise limiting of the scope of the invention.

The following abbreviations have been used in the preceding discussion: API Application Programming Interface

CP Control Plane

CU Central Unit

CU-CP Central Unit Control Plane

CU-UP Central Unit User Plane

DNS Domain Name System

DU Distributed Unit

E2E Equipment to Equipment

FQDN Fully Qualified Domain Name

GPRS General Packet Radio Service

GRE Generic Routing Encapsulation

GTP GPRS Tunneling Protocol

HO Handover

ID Identifier

NAPTR Name Authority Pointer

RAN Radio Access Network

RRC Radio Resource Control

TAC Tracking Area Code

TWAMP Two Way Active Measurement Pro toco 1

UE User Equipment

UP User Plane

VNFC Virtual Network Function Component

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising", when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications of the teachings of this disclosure will still fall within the scope of the non-limiting embodiments of this invention.

Although described in the context of particular embodiments, it will be apparent to those skilled in the art that a number of modifications and various changes to these teachings may occur. Thus, while the invention has been particularly shown and described with respect to one or more embodiments thereof, it will be understood by those skilled in the art that certain modifications or changes may be made therein without departing from the scope of the invention as set forth above, or from the scope of the claims to follow.

Claims

WHAT IS CLAIMED IS:

1. A method comprising:

receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU);

using one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection;

providing said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and

establishing the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection. 2. The method as claimed in claim 1 , further comprising:

notifying the DU to establish an association with said one of said one or more suitable CU-UP instances.

3. The method as claimed in claim 1 , wherein said request is one of: an RRC (radio resource control) conn req (connection request), an HO (handover) request, a flow creation req, and a dual/multi-connectivity leg change.

4. The method as claimed in claim 1 , further comprising:

maintaining said one or more mappings;

sending a query to a lookup server providing an identifier of a DU and an identifier of a desired service as a CU-UP function;

receiving a response from the lookup server, said response containing a list of CU- UP instance identifiers suitable for the DU identifier with the one or more network or service characteristics; and

updating the one or more mappings based on the response.

5. The method as claimed in claim 4, wherein said query includes additional information comprising one or more identifiers of network or service characteristics.

6. The method as claimed in claim 5, wherein the one or more identifiers of network or service characteristics comprise at least one of one or more slice identifiers, and a latency of a CU-UP instance relative to a DU. 7. The method as claimed in claim 4, wherein said query is a domain name system (DNS) query to a DNS server,

8. The method as claimed in claim 4, wherein said mappings are updated periodically or based on UE/flow connection requests.

9. The method as claimed in claim 1 , wherein said mappings include mappings of slice identifiers to a list of CU-UP instance identifiers.

10. The method as claimed in claim 1 , wherein said mappings include mappings providing the latency of each CU-UP relative to each DU.

11. The method as claimed in claim 4, further comprising:

using an interface to configure prioritization rules used for the selection of CU-UP instances.

12. The method as claimed in claim 4, wherein said lookup server includes an interface connecting said lookup server to at least one of: said CU-UP instances, a service orchestrator, and a slice orchestrator. 13. The method as claimed in claim 12, wherein said CU-UP instances use said interface to update said lookup server on respective latencies with respect to DUs of interest.

14. The method as claimed in claim 12, wherein said service orchestrator uses said interface to update said lookup server on creation and deletion of CU-UP instances.

15. The method as claimed in claim 12, wherein said slice orchestrator uses said interface to update said lookup server on slice identifiers supported by CU-UP instances.

16. An apparatus 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, with the at least one processor, to cause the apparatus to perform the following:

receive a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU);

use one or more mappings of one or more identifiers of network or service characteristics to a list of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection;

provide said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and

establish the UE/fiow context in one of said one or more suitable CU-UP instances to complete said connection.

17. The apparatus as claimed in claim 16, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause . the apparatus to:

notify the DU to establish an association with said one of said one or more suitable CU-UP instances.

18. The apparatus as claimed in claim 16, wherein said request is one of: an R C (radio resource control) conn req (connection request), an HO (handover) request, a flow creation req, and a dual/multi-connectivity leg change.

19. The apparatus as claimed in claim 16, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus to:

maintain said one or more mappings;

send a query to a lookup server providing an identifier of a DU and an identifier of a desired service as a CU-UP function; receive a response from the lookup server, said response containing a list of CU- UP instance identifiers suitable for the DU identifier with the one or more network or service characteristics; and

update the one or more mappings based on the response.

20. The apparatus as claimed in claim 19, wherein said query includes additional information comprising one or more identifiers of network or service characteristics.

21. The apparatus as claimed in claim 20, wherein the one or more identifiers of network or service characteristics comprise at least one of one or more slice identifiers, and a latency of a CU-UP instance relative to a DU.

22. The apparatus as claimed in claim 19, wherein said query is a domain name system (DNS) query to a DNS server.

23. The apparatus as claimed in claim 19, wherein said mappings are updated periodically or based on UE flow connection requests.

24. The apparatus as claimed in claim 16, wherein said mappings include mappings of slice identifiers to a list of CU-UP instance identifiers.

25. The apparatus as claimed in claim 16, wherein said mappings include mappings providing the latency of each CU-UP relative to each DU. 26. The apparatus as claimed in claim 19, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus to:

use an interface to configure prioritization rules used for the selection of CU-UP instances.

27. The apparatus as claimed in claim 19, wherein said lookup server includes an interface connecting said lookup server to at least one of: said CU-UP instances, a service orchestrator, and a slice orchestrate r.

28. The apparatus as claimed in claim 27, wherein said CU-UP instances use said interface to update said lookup server on respective latencies with respect to DUs of interest.

29. The apparatus as claimed in claim 27, wherein said service orchestrator uses said interface to update said lookup server on creation and deletion of CU-UP instances.

30. The apparatus as claimed in claim 27, wherein said slice orchestrator uses said interface to update said lookup server on slice identifiers supported by CU-UP instances.

31. An apparatus comprising:

means for receiving a connection request from a user equipment (UE)/flow connecting to a distributed unit (DU);

means for using one or more mappings of one or more identifiers of network or service characteristics to a Hst of central unit-user plane (CU-UP) instance identifiers suitable for each of the network or service characteristics to select one or more suitable CU-UP instances for a connection;

means for providing said identifiers for said one or more suitable CU-UP instances to a central unit-control plane (CU-CP); and

means for estabhshing the UE/flow context in one of said one or more suitable

CU-UP instances to complete said connection.

32. The apparatus as claimed in claim 31 , further comprising:

means for notifying the DU to establish an association with said one of said one or more suitable CU-UP instances.

33. The apparatus as claimed in claim 31 , wherein said request is one of: an RRC (radio resource control) conn req (connection request), an HO (handover) request, a flow creation req, and a dual/multi-connectivity leg change.

34. The apparatus as claimed in claim 31 , further comprising:

means for mamtaining said one or more mappings;

means for sending a query to a lookup server providing an identifier of a DU and an identifier of a desired service as a CU-UP function; means for receiving a response from the lookup server, said response containing a list of CU-UP instance identifiers suitable for the DU identifier with the one or more network or service characteristics; and

means for updating the one or more mappings based on the response.

35. The apparatus as claimed in claim 34, wherein said query includes additional information comprising one or more identifiers of network or service characteristics.

36. The apparatus as claimed in claim 35, wherein the one or more identifiers of network or service characteristics comprise at least one of one or more slice identifiers, and a latency of a CU-UP instance relative to a DU.

37. The apparatus as claimed in claim 34, wherein said query is a domain name system (DNS) query to a DNS server.

38. The apparatus as claimed in claim 34, wherein said mappings are updated periodically or based on UE/flow connection requests.

39. The apparatus as claimed in claim 31 , wherein said mappings include mappings of slice identifiers to a list of CU-UP instance identifiers.

40. The apparatus as claimed in claim 31 , wherein said mappings include mappings providing the latency of each CU-UP relative to each DU. 41. The apparatus as claimed in claim 34, further comprising:

means for using an interface to configure prioritization rules used for the selection of CU-UP instances.

42. The apparatus as claimed in claim 34, wherein said lookup server includes an interface connecting said lookup server to at least one of: said CU-UP instances, a service orchestrator, and a slice orchestrator.

43. The apparatus as claimed in claim 42, wherein said CU-UP instances use said interface to update said lookup server on respective latencies with respect to DUs of interest. 44. The apparatus as claimed in claim 42, wherein said service orchestrator uses said interface to update said lookup server on creation and deletion of CU-UP instances.

45. The apparatus as claimed in claim 42, wherein said slice orchestrator uses said interface to update said lookup server on slice identifiers supported by CU-UP instances.

46. A computer-program product comprising a non-transitory computer-readable storage medium bearing computer program code embodied therein for use with a computer, the computer program code comprising code for performing at least the following:

estabhshing the UE/flow context in one of said one or more suitable CU-UP instances to complete said connection.

47. The computer-program product as claimed in claim 46, further comprising:

notifying the DU to establish an association with said one of said one or more suitable CU-UP instances. 48. The computer-program product as claimed in claim 46, wherein said request is one of: an RRC (radio resource control) conn req (connection request), an HO (handover) request, a flow creation req, and a dual/multi-connectivity leg change.

The computer-program product as claimed in claim 46, further comprising: maintaining said one or more map ings;

sending a .query to a lookup server roviding an identifier of a DU and an identifier of a desired service as a CU-UP function;

updating the one or more mappings based on the response.

50. The computer-program product as claimed in claim 49, wherein said query includes additional information comprising one or more identifiers of network or service characteristics.

51. The computer-program product as claimed in claim 50, wherein the one or more identifiers of network or service characteristics comprise at least one of one or more slice identifiers, and a latency of a CU-UP instance relative to a DU.

52. The computer-program product as claimed in claim 49, wherein said query is a domain name system (DNS) query to a DNS server. 53. The computer-program product as claimed in claim 49, wherein said mappings are updated periodically or based on UE/flow connection requests.

54. The computer-program product as claimed in claim 46, wherein said mappings include mappings of slice identifiers to a list of CU-UP instance identifiers.

55. The computer-program product as claimed in claim 46, wherein said mappings include mappings providing the latency of each CU-UP relative to each DU.

56. The computer-program product as claimed in claim 49, further comprising:

using an interface to configure prioritization rules used for .the selection of CU-UP instances.

57. The computer-program, product as claimed in claim 49, wherein said lookup server includes an interface connecting said, lookup server to at least one of: said CU-UP instances, a service orchestrator, and a slice orchestrator. 58. The computer-program product as claimed in claim 57, wherein said CU-UP instances use said interface to update said lookup server on respective latencies with respect to DUs of interest.

59. The computer-program product as claimed in claim 57, wherein said service orchestrator uses said interface to update said lookup server on creation and deletion of CU-UP instances.

60. The computer-program product as claimed in claim 57, wherein said slice orchestrator uses said interface to update said lookup server on slice identifiers supported by CU-UP instances.