Patent Description:
The high bitrate and coverage requirements of <NUM> have been achieved by decomposing the Radio Access Network (RAN) into denser deployment of Distributed Units (DUs) wherein these small units are deployed anywhere with potentially high traffic requirements and managed by a Central Unit (CU). In effect, a CU and a collection of its subtending DUs form a logical base station, gNodeB or gNB. This decomposition created the necessity for defining yet another interface between DU and CU called the `F <NUM> interface'. F1 has both user plane and control plane components: F1-C, also known as FlAP, supports the exchange of signaling information between CU and DU, while F1-U supports the data transmission, in the uplink and downlink directions.

The F1-C uses Streaming Control Transmission Protocol (SCTP) defined by the IETF over IP protocol, while F1-U uses UDP over IP, and the GTP-U tunneling (see TS <NUM>) as in <NUM> networks. The FlAP defines the application layer of signaling messages over SCTP (see TS <NUM>). The signaling per F1-C interface is in essence the same as the signaling between UE and eNodeB including Radio Resource Control (RRC) (see TS <NUM>) and Initial Context Setup (ICS) (see TS <NUM>).

Similar to the F1 interface, the backhaul network connection between CU and <NUM> packet core network elements supports separation of control and user plane communications. For control plane communications, each CU and the Access and Mobility Management Function (AMF) has the N2 interface, also known as NG-C or NGAP, supporting Non-access Stratum (NAS) functions. N2 uses SCTP and IP protocols (see TS <NUM>). For user plane communications, each CU and User Plane Functions (UPF) of the <NUM> core has the N3 interface, also known as NG-U. N3 uses UDP and IP protocols (see TS <NUM>).

3GPP designed a sliceable <NUM> mobile network infrastructure to provide many logical network segments over a common single physical network (see TR <NUM>). One of the primary technical challenges facing service providers is being able to deliver the wide array of network performance characteristics that future services will demand. Such performance characteristics are bandwidth, latency, packet loss, security, and reliability- all of which will greatly vary from one service to the other. Emerging applications such as remote operation of robots, massive IoT, and self-driving cars require connectivity, but with vastly different characteristics. New technologies such as virtualization, network programmability and network slicing enable logical networks that are customized to meet the quality of service (QoS) needs of each application. Each slice can be optimized according to capacity, coverage, connectivity, security and performance characteristics. Furthermore, since the slices are isolated from each other both in the control and user planes, the user experience of the network slice will be the same as if it was a physically separate network. The <NUM> data radio bearers (DRBs) carry information about the QoS requirements of the slice of user's data. This information is carried on the F1-C as well as the F1-U interface that carries the user's data.

Standardization efforts have gone into defining specific slices and their requirements based on application/service. For example, the user equipment (UE) can now directly specify its desired slice using a new field in the packet header called Network Slice Selection Assistance Information (NSSAI). NSSAI is a collection of at most <NUM> Single NSSAIs (S-NSSAI). A subfield of S-NSSAI is Slice/Service Types (SST) that is used to indicate the slice type. The standards already defined most commonly usable network slices and reserved the corresponding standardized SST values (see TS <NUM>). For example, SST values of <NUM>, <NUM> and <NUM> correspond to slice types of enhanced Mobile Broadband (eMBB), ultra-reliable and low-latency communications (uRLLC) and massive IoT (MIoT), respectively. These services reflect the most commonly planned new services. The network slice selection instance for a UE is normally triggered as part of the UE's initial registration procedure. The AMF of the core network retrieves the slices that are allowed by the user's subscription and interacts with the Network Slice Selection Function (NSSF) of the core network to select the appropriate network slice instance for that traffic on the RAN.

<CIT> provides a method for performing relay forwarding on integrated access and backhaul links, and an information acquisition method, node, and storage medium.

<CIT> provides a transmission method involving indicating and allocating uplink and downlink tunnel addresses on a user plane, and a network device.

Although the UE's slice information and the implied QoS are carried in the Context Setup message on F1-C or N2, and indirectly within the Tunnel End Identifier (TEID) of the GTP-U tunnel carrying the DRB in the payload, the only defined mechanism is to optionally map QoS definition, i.e., the <NUM> QoS Identifier (5QI), of the flows to DiffServ bits of the IP headers in both F1-U and N3 (see TS <NUM> and TS <NUM>). Mapping only from 5QI to DiffServ bits is inadequate to satisfy QoS requirements for two reasons; (<NUM>) slice based QoS requirements are not completely map-able as they are defined in the NSSAIs by simply setting a DiffServ bit, (<NUM>) the transport networks may prefer other QoS differentiation mechanisms at layers <NUM>-<NUM> besides (or instead of) setting the DiffServ bits. Particularly when the fronthaul network is a Passive Optical Network between the CU and its group of DUs, a mechanism is needed to relay the QoS information from the lower layers to the upper layers. Usually, PON is a layer-<NUM> transport network employing Virtual LANs (VLANs) to separate out different traffic streams. However, PON may use other tunneling techniques. Therefore, to generalize, we used the term 'transport channel' to represent any type of tunnel used at layer-<NUM>. A mechanism is needed to map each DRB into proper transport channel (and its layer <NUM>-<NUM> header information) that satisfy the QoS requirements of each slice. More generally speaking, since each DRB is mapped into a different GTP-U tunnel, a mechanism is needed to map each GTP-U tunnel with certain QoS requirements, wherein those QoS requirements are simply translated from those of the DRB carried within the tunnel, into a transport channel with equivalent QoS capabilities. Note that <NUM> architecture defines a 'QoS flow' to be lowest granularity of data flow and identified it by a QoS Flow Id (QFI) in each packet. Each QFI is related to a 5QI, an indicator that includes a set of packet flow treatment parameters (packet loss, packet delay, reliability etc.) and well known in prior art, and a slice Id represented by NSSAI. A DRB is formed from a collection of those 'QoS flows' that have the same 5QI and NSSAI. Each DRB is then mapped into a GTP-U tunnel on the F1-U interface, meaning a tunnel may carry multiple QoS flows with the same 5QI and NSSAI.

The aforementioned mapping function may include an intelligent and stateful decision mechanism for smart mapping of radio QoS requirements to transport channels. When the transport channel resources are inadequate to satisfy the QoS requirements of the radio, the mapping function is responsible to map the QoS flows to transport channel by maximizing the QoS satisfaction depending on the priority of the flows. Moreover, it is also the responsibility of the mapping function that none of the QoS flows should exhaust all transport channel resources, which may block transmission of the low priority traffic flows. To satisfy the reliability requirements, the mapping may configure data flows to be routed through paths with less error-rate or distributed onto cloned transmissions facilities which travel through physically disjoint paths. The mapping function must have such an intelligent decision making mechanism to trace various what-if scenarios, a few of which are outlines above. The design of internal mechanism of the mapping function is not provided here as there are many possible algorithms that can be used from prior art. Artificial intelligence and machine learning are a few to name.

The aforementioned deficiency is addressed by the present teachings through which the QoS capabilities of the transport network is communicated with the CU and DU by the transport network controller. Similarly, the CU and DU can communicate with the transport network controller demanding transport-channels with specific QoS capabilities when new slices are created. The simplest mapping embodiment is by using a different transport channel (say VLAN) for each QoS category over the F1-U or N3 interface, and by storing the VLAN-to-slice/QoS association within the DU and CU. header information. Without altering the logical structure, the mapping function can be implemented physically out of DU and CU.

In one embodiment, there is provided a method for mapping the radio-level Quality of Service (QoS) of each of a plurality of data flows in a mobile network to equivalent transport-level QoS of a plurality of transport channels of a transport network and selecting a transport-channel within the plurality of transport channels suitable for a General Packet Radio Services (GPRS) Tunneling Protocol User Plane (GTP-U) tunnel, the GTP-U tunnel carrying at least one data flow among the plurality of data flows, the plurality of transport channels controlled by a transport controller, the method as implemented in a first node comprising: (a) subscribing, over a first interface, with a transport controller for information regarding transport-level QoS capabilities between the first node and a second node; (b) receiving from the transport controller, in response to the request in (a), information identifying one or more transportation channels within the plurality of transport channels providing transport-level QoS capabilities between the first node and the second node; (c) based on information received in (b), mapping and storing in a mapping table QoS capabilities for each level of the radio-level QoS and each level of the transport-level QoS; (d) storing, in the mapping table, additional mapping data of at least one transport-channel within the one or more transportation channels identified in (b), the additional mapping data corresponding to a tunnel endpoint identifier (TEID) associated with the GTP-U tunnel; (e) sending the mapping table to the second node over the first interface; and wherein the first node and the second node utilize header information corresponding to the TEID before sending packets towards each other.

The present disclosure, in accordance with one or more various examples, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict examples of the disclosure. These drawings are provided to facilitate the reader's understanding of the disclosure and should not be considered limiting of the breadth, scope, or applicability of the disclosure. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.

While the present teachings are illustrated and described in various specific embodiments, the concepts and approaches taught herein may be produced in many different configurations. There are depicted in the drawings, and will herein be described in detail, various embodiments, with the understanding that the present disclosure is to be considered as an exemplification of the principles of the present teachings and the associated functional specifications for its construction and is not intended to limit the scope to the embodiments illustrated. Those skilled in the art will envision many other possible variations which encompass and benefit from the advances provided by the present teachings.

Note that in this description, references to "one embodiment" or "an embodiment" mean that the feature being referred to is included in at least one embodiment of the present teachings. Further, separate references to "one embodiment" in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those of ordinary skill in the art. Thus, the present teachings can include any variety of combinations and/or integrations of the embodiments described herein.

An electronic device (e.g., a base station, router, switch, gateway, hardware platform, controller etc.) stores and transmits (internally and/or with other electronic devices over a network) code (composed of software instructions) and data using machine-readable media (also known as computer-readable media), such as non-transitory machine-readable media (e.g., machine-readable storage media such as magnetic disks; optical disks; read only memory; flash memory devices; phase change memory) and transitory machine-readable transmission media (e.g., electrical, optical, acoustical or other form of propagated signals-such as carrier waves, infrared signals). In addition, such electronic devices include hardware, such as a set of one or more processors coupled to one or more other components-e.g., one or more non-transitory machine-readable storage media (to store code and/or data) and network connections (to transmit code and/or data using propagating signals), as well as user input/output devices (e.g., a keyboard, a touchscreen, and/or a display) in some cases. The coupling of the set of processors and other components is typically through one or more interconnects within the electronic devices (e.g., busses and possibly bridges). Thus, a machine-readable storage medium of a given electronic device typically stores instructions for execution on one or more processors of that electronic device. Further, transitory machine-readable media may be used to provide such instructions to that electronic device, and/or to transmit such instructions between ones of the set of processors and other components within the electronic device, for example transmitting such instructions over the interconnects. One or more parts of an embodiment of the present teachings may be implemented using different combinations of software, firmware, and/or hardware.

For simplicity, only PON is described as the fronthaul network technology, wherein there may be other alternative layer-<NUM> technology options. Furthermore, only the fronthaul network components are detailed in the following figures because the mapping from fronthaul to backhaul network components (i.e., from F1 to N3 interface) can be trivially deduced.

As used herein, a network device such as a base station, switch, router, transport controller, OLT, or ONT, is a piece of networking component, including hardware and software that communicatively interconnects with other equipment of the network (e.g., other network devices, and end systems). Furthermore, OLT and ONT provide network connectivity to other networking equipment such as switches, gateways, and routers that exhibit multiple layer networking functions (e.g., layer-<NUM> switching, bridging, VLAN (virtual LAN) switching, layer-<NUM> switching, Quality of Service, and/or subscriber management), and/or provide support for traffic coming from multiple application services (e.g., data, voice, and video). User Equipment (UE) is generally a mobile device such as a cellular phone, or a sensor, or another type of equipment that wirelessly connects to the mobile network. The type, ID/name, Medium Access Control (MAC) address, and Internet Protocol (IP) address identifies any physical device in the network.

There may be up to <NUM>, <NUM>, <NUM> or <NUM> ONTs attached to each OLT, depending on the size of OLT implementation. ONT converts optical signals transmitted via fiber to electrical signals, and vice versa. In the upstream direction, UE sends packet data via cellular signals to towards the DU, which in turn converts them into electrical signals and sends them to its attached ONT, which in turn converts them into optical signals and sends them to the upstream OLT, which in turn converts them back to electric signals and sends them to the CU.

Each ONT aggregates and grooms different types of data coming from the DU and sends them to the upstream OLT. Grooming is the process that optimizes and reorganizes the data stream so it would be delivered more efficiently. OLT supports a dynamic bandwidth allocation (DBA) algorithm (and sometimes implements more than one algorithm) that supports fair distribution of upstream fiber capacity amongst multiple ONTs to support traffic that comes in bursts from the UEs. The OLT, its attached ONTs and the optical distribution network form a Passive Optical Network (PON). There are various types of PONs known in prior art such as Gigabit PON (GPON), Ethernet PON (EPON) and ATM PON (APON) depending on the capabilities and layer-<NUM> protocols supported. A typical PON operates at layers <NUM> and <NUM> of OSI, but may also perform some limited layer <NUM> functions such as IP header lookup and processing.

The data flows of UEs are carried through application layer tunnels, called GTP-U tunnels in device-to-device data plane interfaces. Note that in this description, references to "GTP-U tunnel" cover an application layer tunnel that contains general or extended format of GTP-U header carried over IP packets of a data flow of a UE. The extended header of GTP-U tunnel may include NR RAN Container for F1 interface, PDU Session Container for N3 interface, or any other extended proprietary or standardized interface specific extension without changing general GTP-U header structure (see TS <NUM>). In this approach, configuration of lower layers, such as layers <NUM>-<NUM> of GTP-U header, is considered as programmable for GTP-U data flows. Example header information for a GTP-U data flow identified by a TEID includes: for layer-<NUM>, source and destination MAC addresses and the VLAN tag, for layer-<NUM>, source and destination IP addresses, and for layer-<NUM>, TCP or UDP port numbers.

<FIG> illustrates a prior art distributed gNodeB comprised of DU <NUM> and DU <NUM> and CU <NUM>. Both DU <NUM> and DU <NUM> have F1-C interface modules <NUM> and <NUM>, respectively, to send and receive control plane messages of the F1-C interface. Similarly, both DU <NUM> and DU <NUM> have F1-U interface modules <NUM> and <NUM>, respectively, to send and receive user plane messages of the F1-U interface that comprises the data radio bearers (DRBs). F1-C <NUM> and <NUM> attach to connections <NUM> and <NUM>, respectively, via a transport network such as a PON. The PON performs electrical to optical conversion of signals at the DU interface, and from optical back to electrical at the CU interface. Connections <NUM> and <NUM> terminate on F1-C <NUM> on CU <NUM>. Similarly, F1-U <NUM> and <NUM> attach to connections <NUM> and <NUM>, respectively, via a transport network such as a PON. These connections terminate on F1-U <NUM> of CU <NUM>. Note that connections <NUM> and <NUM> are attached to the same ONT <NUM> of transport network <NUM>. Also, connections <NUM> and <NUM> are attached to the same ONT <NUM> of transport network <NUM>. On the CU side, all optical connections terminate on OLT <NUM>, which performs the conversion to electrical. Functions <NUM> and <NUM> in DU <NUM> and <NUM> respectively represent physical, MAC and RLC layer processing of all messages. The reciprocal function in CU <NUM> is function <NUM>, which provides the Packet Data Convergence Protocol (PDCP) to upper layers, i.e., RRC for control plane, and Service Data Adaptation Protocol (SDAP) for user plane. The figure illustrates DRB <NUM> and DRB <NUM> between DU <NUM> and CU <NUM>, and DRB <NUM> and DRB <NUM> between DU <NUM> and CU <NUM>. DRB <NUM> and DRB <NUM> have the best effort QoS flow carrying Internet traffic. While DRB <NUM> has a QoS flow with a higher priority level of QoS carrying voice (Session Initiation Protocol -SIP) traffic, DRB <NUM> has a QoS flow with a lower priority level of QoS carrying IoT traffic.

QoS flow is a term used in <NUM> to represent to lowest level of granularity where policy and charging is enforced. The SDAP function maps backhaul QoS flows to DRBs. In the figure, QoS flows <NUM> and <NUM> are mapped into DRB <NUM> and QoS flow <NUM> is mapped into DRB <NUM>. Therefore, QoS flows <NUM> and <NUM> are transmitted in the same stream of data and cannot be differentiated from each other through transport network <NUM>. All DRBs are received in CU <NUM> and sent towards the core network in the form of QoS flows within GTP-U tunnels. The QoS flow to DRB mapping information is shared between CU <NUM> and DU <NUM> in the UE context setup and update procedures (see TS <NUM>). When UE initially attaches to a DU, its CU sends a context setup request message, which includes DRB to QoS flow mapping, QoS flow identifiers (QFI) per flow, QoS requirements per flow and per DRB by specifying 5QI data type, and the slice information as the NSSAI. Any changes to these information elements are sent to DU by the UE's context setup modification request message. For per QoS flow or per DRB, the 5QI data type includes a large variety of service requirements including, but not restricted to, maximum delay, minimum bandwidth, maximum bandwidth, reliability, etc. In prior art, the transport network capabilities of ONT <NUM>, <NUM> and OLT <NUM> are separately handled by the transport network, and unbeknown to DUs and CU.

<FIG> illustrates a prior art configuration of two CUs, namely CUa and CUb, attached to AMF for control plane, and UPF for user plane functions. The transport network <NUM> between these functions is illustrated as a layer-<NUM> network providing the routing function between each CU and a plurality of control and user plane functions distributed as virtual network functions (VNFs) across the core network. The routing provides a more flexible transport network option in this segment of the network as the control traffic can be routed to different VNFs (of the same type) depending on time of day or workload of a particular control function. In contrast, the F <NUM> interface traffic is always between the DU and a specific CU, and thus never need to be routed elsewhere. A layer-<NUM> network such as a PON is, therefore, most suitable for the fronthaul network. Routers <NUM>, <NUM>, <NUM> and <NUM> are deployed next to each function in <FIG>, but in other embodiments a single router may connect to multiple CUs and/or multiple control and user plane functions.

CU 104a has N2 interface <NUM> and CU 104b has N2 interface function <NUM> for control plane N2 messaging with AMF <NUM>. Similarly, CU 104a has N3 interface function <NUM> and CU 104b has N3 interface function <NUM> for user plane messaging with UPF <NUM>. User plane traffic on interfaces <NUM> and <NUM> towards UPF <NUM> has multiple QoS flows with different QoS characteristics. Router <NUM> forwards N2 traffic of CU 104a towards AMF <NUM>, and N3 traffic towards UPF <NUM>. AMF <NUM> controls NAS functions <NUM> like attach, detach, and handover, while UPF <NUM> controls routing between backhaul tunnels <NUM> and outer network. Complete functional description of AMF <NUM> and UPF <NUM> is not intended to be presented here as it is available in prior art.

Similar to F1 interface, the N3 interface can carry multiple QoS flows in a single GTP-U tunnel between UPF <NUM> and CUa/CUb 104a/104b (see TS <NUM>). The Session Management Function (SMF) controls the establishment of N3 GTP-U tunnels (see TS <NUM>). A GTP-U tunnel initialization or removal is performed during the UE context procedures. When SMF initializes a tunnel, it sends the uplink tunnel ID (TEID) information to AMF. Then, AMF shares with the CU the uplink TEID, the QoS flow-to-tunnel matching information, QFIs per flow, QoS information of flows as 5QI, and slice information as NSSAI in the UE context setup request message or the UE context setup modification request message through N2 interface. When CU receives these messages, responds with the downlink TEID for the tunnel to complete the tunnel establishment procedure. In contrast to F1, the N3 interface also carries QFI in user plane, which may be used in traffic prioritization in transport network <NUM>. However, the prior-art does not provide any coordination between the transport layer (routers <NUM>, <NUM>, <NUM>, <NUM>), and mobile network functions (CUa 104a, CUb 104b, AMF <NUM>, UPF <NUM>) to reflect cross-layer translation of QoS.

Note that the layer-<NUM> transport network of <FIG> may comprise a Software Defined Network (SDN), wherein boxes <NUM>, <NUM>, <NUM> and <NUM> are not routers but switches, meaning routing decisions are taken by the controller. Furthermore, each route and its properties (such as QoS) are downloaded onto each switch in the form of instructions by the controller. Such instructions include QoS settings for specific traffic flows that are identified with VLAN tags, MPLS tags, other tunnel headers, or IP addresses and UDP/TCP port numbers. The layer-<NUM> transport network for each slice may comprise different network facilities and different groups of UPFs allocated to that slice, and possibly controlled by a slice-specific controller.

<FIG> illustrates a simple transport network with ONT <NUM> and <NUM>, and OLT <NUM> and a transport network controller <NUM>. ONT <NUM> carries two upstream VLANs, i.e., VLAN <NUM> and VLAN <NUM>, and ONT <NUM> has upstream VLAN <NUM>. OLT <NUM> has three downstream VLANs, namely VLAN <NUM>, VLAN <NUM> and VLAN <NUM>.

Traffic Container (T-CONT) is traffic bearing object within an ONT that represents a group of logical connections and is treated as a single entity for the purpose of upstream bandwidth assignment on the PON. In the upstream direction, it is used to bear the service traffic. Each T-CONT is identified by an ALLOC_ID uniquely, allocated by OLT i.e., a T-CONT can only be used by one ONT per PON interface on the OLT.

The GPON Encapsulation Method (GEM) port is a virtual port for performing so-called GEM encapsulation for transmitting frames between OLT and ONT in a GEM channel. Each different traffic class (TC) is assigned a different GEM Port ID. A T-CONT consists of one or more GEM Ports. Each GEM port usually bears one kind of service traffic corresponding a quality of service. The GEM Port ID is uniquely allocated by the OLT. Between the ONT and OLT, layer-<NUM> frames are carried through the GEM frames identified by GEM Port IDs. Each GEM Port ID is unique per OLT and represents a specific traffic or group of flows between OLT and ONTs. GEM channels are used to transmit both upstream traffic, which is from ONT to OLT, and to transmit downstream traffic, which is always broadcast traffic from OLT towards all ONTs. Each ONT identifies traffic destined to it based on the matching GEM Port ID in the received GEM frames. In summary, GEM Ports are used to differentiate among different traffic classes (TCs). Shown in <FIG>, GEM ports and T-CONTs are assigned to different traffic classes identified by a VLAN id or tag. Note that there are three distinct bidirectional GEM ports across ONTs and OLT corresponding to those three VLANs.

The traffic classifier in each ONT grooms traffic according to VLAN tags and sends them in upstream direction towards the corresponding GEM port. Each GEM port performs the GEM encapsulation of the VLAN traffic and forwards packets in the GEM channel towards the GEM port on OLT. The received traffic corresponding to VLAN <NUM>, <NUM> and <NUM> are processed by different traffic classifiers (e.g., T-CONT <NUM>, <NUM>, and <NUM>) and scheduled for delivery according to the traffic class priorities and upstream bandwidth assignment to that class with different queuing algorithms such as strict priority and weighted fair queuing. Such traffic classifiers and queuing algorithms are prior art. A similar process is applicable in the downstream direction wherein the roles are reversed, i.e., now both the Classification and the Scheduling is in the OLT.

The control plane of core network assigns to each user's DRB of different type a unidirectional GTP-U tunnel with a unique TEID. For example, UE <NUM> of <FIG> has two DRBs, DRB <NUM> and DRB <NUM>, each using a different GTP-U tunnel between DU and CU. Each DRB contains at least one QoS flow. Each DRB has a QoS requirement definition as 5QI, while each flow also has its own 5QI definitions. Moreover, each UE has its own NSSAI, which defines service/slice type of UE <NUM>. In NSSAI, there are at most <NUM>-NSSAIs to define UE <NUM>'s slice subscription. S-NSSAI has a field known as Standard Slice Type (SST) having values of SST=<NUM> for enhanced Mobile Broadband, eMB, SST=<NUM> for ultra-reliable and ultra-low delay communications, uRLLC and SST=<NUM> for Massive IoT, mIoT. To satisfy all QoS requirements defined by 5QIs and the prioritization by NSSAIs across the fronthaul and backhaul networks, these higher layer QoS definitions should be mapped to lower layer properties such as those of VLANs, which can be differentiated by ONTs, OLTs, switches, routers, etc..

There may be groups of GTP-U tunnels carrying DRBs with the same QoS requirements. Once different groups of GTP-U tunnels are identified in F1-U, with each tunnel group having a different quality of service profile, those tunnels belonging to the same group should logically be placed on the same VLAN identified by a unique VLAN tag, which VLAN providing the quality of service of the tunnel group it is carrying. Alternatively, there may be multiple VLANs providing the same transport level QoS (say on different physical links), in which case, the tunnels from the same group can be distributed across these VLANs. Although the F1-C traffic is not carried in a GTP-U tunnel, that traffic segment can be considered as a special class of the service that has a quality of service requirements such as low packet loss and placed onto a special control VLAN (say VLANc) that is allocated for F1-C traffic only.

A unique VLAN tag/id can be associated with each VLAN that has a different set of quality of service requirements within the transport network. The transport network controller can assign and maintain these tags and associated GEM ports and T-CONTs to ensure the designated quality of service is delivered on each VLAN. The VLAN tag is inserted in the upstream direction by the DU, and removed by the CU. The VLAN tags are only meaningful and visible within the fronthaul portion of the network, because they are removed before the traffic is leaving a CU towards the AMF or UPF. For simplicity, the embodiments here consider only one VLAN tag per GTP-U tunnel (or tunnel group) on F1-U, and one VLANc tag or F1-C.

<FIG> illustrates a first embodiment. In this embodiment, transport network controller <NUM> has TN-C interface 231a towards DU and TN-C interface 231b towards the CU. DU has a new function called QoS mapping 202a and CU has the reciprocal function 202b. DU has a new database called QoS mapping DB 207a and CU has the reciprocal function 207b. A trivial mapping of this configuration is also applicable between the CU and UPF, wherein both CU and UPF have TN-C interfaces towards the transport network controller. Hence, it will not be recited here.

Although a single transport network controller is illustrated in <FIG> for simplicity, there may be multiple transport network controllers, (particularly, when each transport network controller is being associated with a specific slice) and therefore multiple TN-C interfaces at each end. The mapping between slice and TN-C interface is stored in DU, CU and UPF.

The basic TN-C interface messages are illustrated in <FIG> and comprised of:.

QoS Mapping 202a maps radio-level QoS and slice requirements of each DRB type to a transport-level QoS. The mapping is stored and updated from time to time within the QoS Mapping function as a table. It updates the mappings as it received new information on topology changes that affect VLANs from the TN-C interface. Thus, this function basically determines what transport-channel to use to meet the radio-level QoS. The mapping database 207a, however, stores the specific TEID to layer <NUM>-<NUM> header information mapping, each time a new GTP-U tunnel is formed. When the tunnel seizes to exist, the mapping is deleted from the database. Reciprocal functions are performed in the CU independently of the DU. QoS Mapping 202a can also generate requests for new VLANs from transport network controller when new types of radio-level QoS need emerge from UEs. Although we used VLANs and VLAN tags by way of example within this context, it can be some other type of transport layers <NUM>-<NUM>.

<FIG> illustrates a second embodiment. In this embodiment, transport network controller <NUM> has TN-C interface <NUM> towards the CU only. CU <NUM> has a new function called QoS Mapping 202b and a new database called QoS Mapping DB 207b. The basic TN-C interface messages are illustrated in <FIG>. In contrast to the first embodiment, DU of the second embodiment does not have QoS Mapping functions, and their QoS Mapping DB 207a is updated by QoS Mapping 202b function.

For providing QoS Mapping information to DUs, the F1-C capabilities are extended by introducing a new F1 AP so that the CU can disseminate the TEID to layer <NUM>-<NUM> header information mapping information to a subtending DU. This extension on F1 interface can be implemented by using two methods (<NUM>) embedding VLAN tag information to context setup procedure messages (as an example, the VLAN tag information can be embedded into "UP Transport Layer Information" structure defined in Section <NUM>. <NUM> of TS <NUM>), or (<NUM>) defining two extra messages on F1 interface such as:.

QoS Mapping 202b has the mapping in both traffic directions. The data is stored in QoS Mapping Database 207b. QoS Mapping 202b can also generate requests for new VLANs from transport network controller when new types of DRBs emerge from UEs. QoS Mapping Database 207a is a replica of 207b. The CU communicates the information using the F1-C interface using aforementioned messages. Although we used VLANs and VLAN tags by way of example within this context, it can be some other type of transport tunneling mechanism.

An example message flow corresponding the first embodiment is shown in <FIG>. The process starts with a UE context setup procedure between the DU and CU using the F1-C interface. When CU hands over to DU the Uplink (UL) TEID for the GTP-U tunnel for the specific DRB along with the associated radio-level QoS profile identified by NSSAI, flow 5QI and DRB 5QI, the DU sends this information to its QoS Mapping function. QoS Mapping first tests the achievability of new QoS requirements with the existing transport-channels' QoS capabilities. If the new QoS requirements are not achievable with QoS properties of existing VLANs, QoS Mapping function sends a Transport Network QoS Request message to the transport network controller to add a new transport network capability (such as a new VLAN tag, GEM port, TCONT, etc.) corresponding to the requested QoS profile. Depending on the success or failure in the Transport Network QoS Response, QoS Mapping generates layer <NUM>-<NUM> header information. The QoS Mapping constructs the layer <NUM>-<NUM> headers corresponding to the UL TEID and stores it in the database. Thereafter, the F1-U module queries for each packet with the UL TEID the layer <NUM>-<NUM> header information corresponding to the UL TEID's QoS profile, constructs the GTP-U tunnel payload and headers accordingly, and sends packet to the CU on F1-U interface. For the first embodiment, a symmetric version of message sequence in <FIG> is also defined for QoS Mapping of CU, 202b, for DL TEID of DRB.

An example message flow corresponding the second embodiment is shown in <FIG>. The process starts before a UE context setup procedure between the DU and CU using the F1-C interface. F1-C creates UL TEID and sends it with the associated QoS profile identified by NSSAI, flow 5QIs and DRB 5QI to QoS Mapping function. QoS Mapping first tests the achievability of new QoS requirements with existing ones through available VLANs of the transport network. If the new QoS requirements are not achievable with the QoS properties of the existing VLANs, QoS Mapping function sends a Transport Network QoS Request to transport network controller to add a new transport network capability (such as a new VLAN tag, GEM port, TCONT, etc.) corresponding to the requested QoS profile. Depending on success or failure in Transport Network QoS Response, the QoS Mapping generates the layer <NUM>-<NUM> properties for both uplink and downlink QoS profiles of the DRB. QoS Mapping function first sends UL layer <NUM>-<NUM> header information with TEID to F1-C of CU for forwarding to DU. F1-C of CU sends UL layer <NUM>-<NUM> header information along with UL TEID either by embedding directly into the context setup messages or by using a new message type called Transport Mapping Request. When the F1-C of DU gets the UL TEID, it generates DL TEID and sends it to the CU. When the F1-C of CU gets DL TEID, it forwards it to the QoS Mapping function. The QoS Mapping function pairs generate layer <NUM>-<NUM> header information with DL TEID and write them into CU QoS Mapping DB. Similarly, F1-C of DU writes the received UL TEID and its layer <NUM>-<NUM> properties to DU QoS Mapping DB. Thereafter, the F1-U modules of both DU and CU query for TEID of each incoming packet to get the layer <NUM>-<NUM> properties for both uplink and downlink, and construct the GTP-U tunnel payload and headers accordingly.

Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

A computer includes at least a processor for performing or executing instructions and one or more memory devices for storing instructions and data.

In this specification, the term "software" is meant to include firmware residing in read-only memory or applications stored in magnetic storage or flash storage, for example, a solid-state drive, which can be read into memory for processing by a processor. Also, in some implementations, multiple software technologies can be implemented as sub-parts of a larger program while remaining distinct software technologies. In some implementations, multiple software technologies can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software technology described here is within the scope of the subject technology. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

These functions described above can be implemented in digital electronic circuitry, in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.

Some implementations include electronic components, for example microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable storage media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. Some examples of such computer-readable media include transmission media such as carrier waves and transmission signals that can be used to transmit program instructions between computer devices and/or between components within a computer device. The computer-readable media can store (e.g. retain, convey or otherwise provide) a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, for example is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, for example application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself.

As used in this specification and any claims of this application, the terms "computer readable storage medium" and "computer readable storage media" are intended to refer to tangible, physical objects that store information in a form that is readable by a computer. The terms "computer-readable medium" and "computer-readable media" are intended to include such storage media and also include transmission and/or carrier signals such as wireless signals, wired download signals, and any other ephemeral signals.

Therefore, from one perspective there have been described approaches that extend distributed unit (DU), central unit (CU) and control plane of F1 (F1-C) capabilities so that differentiated DRBs of F1-U are placed on differentiated transport network components of equivalent QoS. This is achieved by a transport-aware DU and CU that can map each F1-U DRB into appropriate OSI layer <NUM>-<NUM> headers and can, subsequently, store such mappings. The F1-C interface is extended to distribute the layer <NUM>-<NUM> headers acquired from the transport network controller to the DUs and CU. A new control interface TN-C is defined between transport network controller and CU/DU. Furthermore, a trivial mapping of those embodiments is applicable for the N3 interface as well, which solves the same problem on the backhaul transport network.

Claim 1:
A method for mapping a radio-level Quality of Service, QoS, of each of a plurality of data flows in a mobile network to equivalent transport-level QoS of a plurality of transport channels of a transport network and selecting a transport channel within the plurality of transport channels suitable for a General Packet Radio Services, GPRS, Tunneling Protocol User Plane, GTP-U, tunnel, the GTP-U tunnel carrying at least one data flow among the plurality of data flows, the plurality of transport channels controlled by a transport network controller, the method implemented by a first node comprising the following steps:
step a): subscribing, over a first interface, with the transport network controller, to request information regarding transport-level QoS capabilities between the first node and a second node, wherein the first node is a Central Unit, CU, and the second node is a Distributed Unit, DU, or where the first node is a User Plane Function, UPF, and the second node is a CU;
step b): receiving from the transport network controller, in response to the request according to step a), information identifying one or more transport channels within the plurality of transport channels providing transport-level QoS capabilities between the first node and the second node;
stepc c): based on information received in step b), mapping and storing in a mapping table QoS capabilities for each level of the radio-level QoS and each level of the transport-level QoS;
step d): storing, in the mapping table, additional mapping data of at least one transport channel within the one or more transport channels identified in step b), the additional mapping data corresponding to a tunnel endpoint identifier, TEID, associated with the GTP-U tunnel, wherein the additional mapping data comprises layer-<NUM>, layer-<NUM>, and layer-<NUM> header information;
step e): sending the mapping table to the second node over the first interface; and
wherein the first node and the second node utilize the header information corresponding to the TEID before sending packets towards each other.