Patent Description:
The present disclosure relates generally to wireless communications, and, in particular embodiments, to a method and apparatus of providing a transport context in the form of a multi-transport network context identifier (MNTC-ID) across multiple domains using a user datagram protocol (UDP) header.

<CIT> describes that a network device has an input port for receiving input packets, and an output port for sending output packets, where the input packets and output packets have context layer information. The network device also includes a processor configured to process the input packets and output packets using a network protocol having a context layer.

Traffic engineered (TE) mobile network backhauls use provisioning based on, more or less, static engineering estimates. These estimates may be changed, and traffic engineering may be configured periodically based on demand and other performance criteria. However, such a traffic engineering process may take a long time (e.g., on the order of weeks or months), and thus may not be suitable for networks having dynamically changing contexts, such as the fifth generation (<NUM>) mobile networks. It is desirable to provide dynamically traffic engineered paths in backhaul networks to meet the need of changing traffic demands.

A first aspect of the present disclosure relates to a method performed by a Next Generation Node B (gNB) in a communications system implementing User Datagram Protocol (UDP) according to claim <NUM>.

Optionally, in a first implementation according to the first aspect, the set of resource provisioning requirements comprises a quality of service (QoS) requirement, a class of service (CoS) requirement, a resilience requirement, and an isolation requirement.

Optionally, in a second implementation according to the first aspect or implementation of the first aspect, each of the one or more transport networks comprises NEs configured to implement at least one of Multiprotocol Label Switching (MPLS), Segment Routing over Internet Protocol (IP) version <NUM> (IPv6) data plane (SRv6), IP transport, or Enhanced Virtual Private Network.

Optionally, in a third implementation according to the first aspect or implementation of the first aspect, the method further comprises storing a forwarding table comprising a mapping between the MTNC-ID and the forwarding path.

Optionally, in a fourth implementation according to the first aspect or implementation of the first aspect, the method further comprises encapsulating the data packet to include a UDP header and the GUE header, wherein the GUE header comprises a "C" flag field, wherein the "C" flag field is set to indicate that the data packet carries a data message.

Optionally, in a fifth implementation according to the first aspect or implementation of the first aspect, the method further comprises encapsulating the data packet to include a UDP header and the GUE header, wherein the GUE header comprises a "C" flag field, wherein the "C" flag field is set to indicate that the data packet carries a control message.

Optionally, in a sixth implementation according to the first aspect or implementation of the first aspect, the method further comprises encapsulating the data packet to further comprise an outer Internet Protocol (IP) header, a UDP extension header, a General Packet Radio Service Tunneling Protocol (GTP)-User Data Tunneling (GTP-U) header, and an inner IP header, wherein the UDP extension header comprises a UDP header and the GUE header carrying the MTNC-ID.

A second aspect of the present disclosure relates to a method performed by a network element (NE) in a communications system implementing User Datagram Protocol (UDP) according to claim <NUM>.

Optionally, in a first implementation according to the second aspect, the set of resource provisioning requirements comprises a quality of service (QoS) requirement, a class of service (CoS) requirement, a resilience requirement, and an isolation requirement.

Optionally, in a second implementation according to the second aspect or implementation of the second aspect, each of the one or more transport networks comprises NEs configured to implement at least one of Multiprotocol Label Switching (MPLS), Segment Routing over Internet Protocol (IP) version <NUM> (IPv6) data plane (SRv6), IP transport, or Enhanced Virtual Private Network.

Optionally, in a third implementation according to the second aspect or implementation of the second aspect, the data packet comprises a UDP header and the GUE header, wherein the GUE header comprises a "C" flag field, wherein the "C" flag field is set to indicate that the data packet carries a data message.

Optionally, in a fourth implementation according to the second aspect or implementation of the second aspect, the data packet comprises a UDP header and the GUE header, wherein the GUE header comprises a "C" flag field, wherein the "C" flag field is set to indicate that the data packet carries a control message.

Optionally, in a fifth implementation according to the second aspect or implementation of the second aspect, the data packet comprises an outer Internet Protocol (IP) header, a UDP extension header, a General Packet Radio Service Tunneling Protocol (GTP)-User Data Tunneling (GTP-U) header, and an inner IP header, wherein the UDP extension header comprises a UDP header and the GUE header carrying the MTNC-ID.

A third aspect of the present disclosure relates to a Next Generation Node B (gNB) implemented in a communications system, according to claim <NUM>.

A fourth aspect of the present disclosure relates to a network element (NE) implemented in a communications system, according to claim <NUM>.

It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims.

Network services requested by users are often associated with requirements, e.g., quality of service (QoS) requirements, which need to be met so that the users may receive levels of services as contracted. Transport networks that are configured to provide transport services also need to provision transport resources according to these requirements for forwarding traffic.

The present disclosure provides various embodiments for enabling an SRV6 data plane to carry an MTNC-ID (which is a type of metadata). The MTNC-ID is processed for each domain to route data packets using a pre-established path in each domain that corresponds to the MTNC-ID. The MTNC-ID represents a combination of QoS requirements, a class of service (CoS) requirement, a resilience requirement, and/or an isolation requirement according to which transport resources of a transport network are provisioned for routing traffic between two service end points.

The User Plane Function (UPF) is a fundamental component of a 3GPP <NUM> core infrastructure system architecture. The UPF provides the interconnect point between the mobile infrastructure and the Data Network (DN), (i.e., encapsulation and decapsulation of General Packet Radio Services (GPRS) Tunneling Protocol for the User Plane (GTP-U)); the Protocol Data Unit (PDU) session anchor point for providing mobility within and between Radio Access Technologies (RATs), including sending one or more end marker packets to the gNB; packet routing and forwarding; application detection; per-flow QoS handling; and traffic usage reporting. As will be described herein, the UPF has four distinct reference points: (<NUM>) N3: Interface between the radio access network RAN (e.g., one or more base stations) and the (initial) UPF; (<NUM>) N9: Interface between two UPF's (i.e., the Intermediate I-UPF and the UPF Session Anchor); (<NUM>) N6: Interface between the data network (DN) and the UPF; and (<NUM>) N4: Interface between the session management function (SMF) and the UPF. The disclosed embodiments are applicable if any of N3, N9, or N6 is a SRV6-enabled network. Additional benefits of the disclosed embodiments can be ascertained from the following description.

<FIG> is a diagram illustrating an embodiment of a wireless communications network <NUM> for communicating data. The network <NUM> comprises a base station <NUM> having a coverage area <NUM>, a plurality of mobile devices <NUM>, and a backhaul network <NUM>. As shown, the base station <NUM> establishes uplink (dashed line) and/or downlink (dotted line) connections with the mobile devices <NUM>, which serve to carry data from the mobile devices <NUM> to the base station <NUM> and vice-versa. Data carried over the uplink/downlink connections may include data communicated between the mobile devices <NUM>, as well as data communicated to/from a remote-end (not shown) by way of the backhaul network <NUM>. As used herein, the term "base station" refers to any component (or collection of components) configured to provide wireless access to a network, such as an enhanced base station (eNB), a next generation gigabit NodeB (gNB), a transmit/receive point (TRP), a macro-cell, a femtocell, a Wi-Fi access point (AP), or other wirelessly enabled devices. Base stations may provide wireless access in accordance with one or more wireless communication protocols, e.g., long term evolution (LTE), LTE advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi <NUM>. 11a/b/g/n/ac, etc. As used herein, the term "mobile device" refers to any component (or collection of components) capable of establishing a wireless connection with a base station, such as a user equipment (UE), a mobile station (STA), and other wirelessly enabled devices. In some embodiments, the network <NUM> may comprise various other wireless devices, such as relays, low power nodes, etc..

<FIG> is a diagram <NUM> illustrating Third Generation Partnership Project (3GPP) control plane functions for setting up user plane connections in the wireless communications network <NUM> of <FIG>. Specifically, <FIG> illustrates 3GPP control plane functions (e.g., an access and mobility management function (AMF), an SMF, etc.) that provide access and session handling capabilities for setting up user plane connections across a segment N3 (e.g., a communication segment between a radio access network (RAN) and a user plane Function (UPF) (also referred to as an interface N3)), across a segment N9 (e.g., a segment between UPFs (also referred to as an interface N9)), and across a segment N6 (e.g., a segment between a UPF and an edge network and/or other external destinations (also referred to as an interface N6)).

The control plane functions shown in <FIG> include a policy control function (PCF) <NUM>, a network data analysis function (NWDAF) <NUM>, an AMF <NUM>, and a SMF <NUM>. 3GPP specifications, including Technical Specification (TS) <NUM> and TS <NUM>, describe these control plane and user plane functions in detail. For example, the SMF <NUM> is responsible for handling individual user sessions, in particular, Internet Protocol (IP) addresses, routing, and mobility. The SMF <NUM> provisions user sessions subject to network and subscription policy as defined in the PCF <NUM>. The NWDAF <NUM> is responsible for network data analysis, i.e., analysis on data from various 3GPP network functions (NFs). The AMF <NUM> is responsible for handling connection and mobility management.

Each of the control plane functions communicate with other functions through their specific interfaces. For example, the PCF <NUM> communicates via an interface Npcf, the NWDAF <NUM> communicates via an interface Nnwdaf, the AMF <NUM> communicates via an interface Namf, and the SMF <NUM> communicates via an interface Nsmf.

In the data plane, UEs may access a RAN <NUM> for wireless communication, and traffic may be routed between the RAN <NUM> and a UPF <NUM> via N3, between the UPF <NUM> and a UPF <NUM> via N9, and between the UPF <NUM> and an application server (AS) <NUM> via N6. In some cases, the interface between the UPF <NUM> and the AS <NUM> may be N6 or a 3GPP external network interface.

The end-to-end connections for N3, N9, and N6 may traverse a backhaul network or a data center (DC) network <NUM>, <NUM>, <NUM>. For example, the connection over N3 traverses a backhaul/DC network <NUM>, the connection over N9 traverses backhaul/DC network <NUM>, and the connection over N6 traverses a backhaul/DC network <NUM>. Each of the backhaul or DC networks may be referred to as a transport network or a domain, and traffic is routed or transported through a transport network corresponding to an interface N3, N6, or N9. The corresponding transport underlay for these interfaces N3, N6, and N9 may need to be traffic engineered to support various <NUM> use cases. For example, to satisfy requirements such as low latency, and high reliability for data flows, as well as the ability to support dynamically varying demands on network capacity, software defined network (SDN)-controllers (SDN-Cs) in the transport domain may need to get requests from a 3GPP system and provide the path capabilities requested.

Mobile network backhauls use static configuration and provisioning of routers for traffic engineering (TE), where TE is configured periodically (e.g., weekly or monthly) based on demand and other performance criteria. The backhauls provide statically traffic engineered paths for forwarding traffic. However, in <NUM> systems with a large range of services, low latency paths, and mobility, the demand estimate varies much more dynamically (e.g., in the order of several minutes in the worst cases). To support and provide dynamically traffic engineered paths (e.g., forwarding paths) that accommodate dynamically varying traffic demand, as well as other requirements, MTNC-IDs are associated and applied to data packets in the control plane based on which transport networks provide contract bound services according to the transport network context or the transport context identified by the MTNC-IDs. The terms "transport network context" and "transport context" are used interchangeably throughout the disclosure. Each MTNC-ID may correspond to one forwarding path between two data plane network functions, e.g., UPFs <NUM> and <NUM>. The forwarding path may include one or more transport networks configured for forwarding traffic on the forwarding path. In one embodiment, the transport network context identified by an MTNC-ID corresponding to a forwarding path may include a set of requirements, such as quality of service QoS requirements, CoS requirements, a resilience requirement, and/or an isolation requirement, according to which transport resources of each transport network on the forwarding path are provisioned for routing traffic on the forwarding path.

In some cases, traffic is transmitted over an end-to-end transmission path from a source network (or a source site) to a destination network (or a destination site). The source network and the destination network are referred to as customer networks (at different sites). In one example, a customer network may be a mobile network, or an edge computing network. In another example, one of the source network and the destination network is a radio access network, and the other one is a mobile core. The following embodiments use 3GPP mobile networks as examples for merely illustrative purposes. Other networks may also be applicable, such as a content delivery network (CDN) or a DC network, without departing from the principle and spirit of the present disclosure.

Communication of traffic between the customer networks (or two sites) may be through one or more backhaul networks or DCs <NUM>, <NUM>, and <NUM>. Thus, traffic is routed from the source network to the destination network through the one or more backhaul networks or DCs. The backhaul networks or DCs for routing traffic between two customer networks may be referred to as transport networks. Traffic communicated between the customer networks through a transport network may also be referred to as being communicated across different domains (or across different sites). The source network, destination network, and the transport network may be viewed as being associated with different domains. In an illustrative example, where the two customer networks may be two different 3GPP mobile networks, the 3GPP mobile networks are associated with 3GPP domains, and the transport network is associated with a transport domain. Thus, in this example, traffic is communicated across 3GPP domains and a transport domain. The mobile networks may also be viewed as being associated with application domains.

Network slicing divides a network service into many parallel network slice instances and distributes functions of each slice instance as independent units based on network conditions and service requirements. Network slicing may allow multiple virtual networks to be created on top of a common shared physical infrastructure, and the virtual networks may then be customized to meet specific needs of applications, services, devices, customers, or operators. For example, in the case of <NUM>, a single physical network may be sliced into multiple virtual networks that may support different RANs, or different service types running across a single RAN.

A network slice may be associated with a set of resources of the network. For example, a 3GPP slice may be associated with a set of 3GPP network resources. A transport slice may be associated with a set of transport network resources. A transport network slice may correspond to QoS, CoS, resilience and isolation requirements. There may be multiple slice instances corresponding to a slice, and they may be dedicated or shared. In this way, an MTNC-ID may also be associated with a network slice.

<FIG> is a diagram illustrating an embodiment of a communications system <NUM> highlighting transport networks used for forwarding traffic between a mobile network <NUM> and a mobile network <NUM> using MTNC-IDs. <FIG> shows that MTNC-IDs are shared by the different transport networks in the communications system <NUM> (e.g., the application (i.e., mobile network) domain and the transport domain).

In <FIG>, mobile network functions are deployed across two sites (i.e., the mobile networks <NUM> and <NUM>, (referred to as Site <NUM>, Site <NUM>, respectively), and a transport network <NUM> in between. As shown, the mobile network <NUM> includes a transport path manager (TPM) <NUM>, and a SMF <NUM>. The mobile network <NUM> includes a TPM <NUM>. A UE <NUM> communicates with a gNB <NUM> in the mobile network <NUM>. Traffic may be transmitted from the gNB <NUM> to a UPF <NUM> of the mobile network <NUM>, routed by the transport network <NUM> on a path including PE routers <NUM> and <NUM>, forwarded to a UPF <NUM> of the mobile network <NUM>, and then delivered to an application server (AS) <NUM>. Communications between the UE <NUM> and the gNB <NUM> traverse a radio network. Communications between the gNB <NUM> and the UPF <NUM> is through the interface N3 traversing a transport network <NUM> (which is an IP network). Communications between the UPF <NUM> and the UPF <NUM> is through the interface N9 traversing a backhaul network (or a transport network) <NUM>. Communication between the UPF <NUM> and the AS <NUM> is through the interface N6 that may traverse another data center (or a transport network). Each transport network includes an SDN-C provisioning and managing router. The path for communicating traffic between the UE <NUM> and the AS <NUM> may thus include multiple segments, i.e., a N3 segment, a N9 segment, and a N6 segment.

A TPM (e.g., TPM <NUM> or TPM <NUM>) is a control function of a customer network, and one TPM is configured per customer network (or site). A TPM of a network (e.g., a mobile network) may be configured to collect data, e.g., user session information, traffic volume, etc., regarding traffic demand of the network, collect topology information of a transport network that is used to forward traffic between the network and other networks, negotiate with a TPM of another network for traffic matrix, and collect performance data regarding transport paths of a transport network for routing traffic between the network and other networks through the transport network. The TPM may be configured to dynamically determine whether to request to configure a transport path in a transport network for routing traffic from the network to another network through the transport network, based on the collected data, estimates and/or requirements, such as QoS determined, demands estimated, traffic matrix negotiated, PE routers of the transport network that are determined, and one or more transport path configuration constraints.

For example, 3GPP TS <NUM> or <NUM> supports a number of service level guarantees for QoS, such as ultra-low latency, ultra-high reliability, and latency determinism to best effort. 3GPP UPFs classify and allocate resources for packet data network (PDN) connections and flows according to QoS levels and slice information. In the transport networks, resources are granted based on the service level guarantees by the mobile network.

In <FIG>, the N3 segment between the gNB <NUM> and the UPF <NUM> is over the transport network <NUM> at Site <NUM>, which may be a data center or a center office (DC/CO). In the N9 segment, in the case as shown in <FIG>, there are four transport segments (or paths), a transport segment at each mobile network site (Site <NUM> and Site <NUM>), a transport segment from the UPF <NUM> to the router <NUM> of the transport network <NUM>, a transport segment from the router <NUM> to the UPF <NUM>, and a transport (or backhaul) segment in between routers <NUM> and <NUM>. In order for each transport network to provision transport resources and provide a service of an agreed level, each transport network may consider the estimation of traffic and provisioning by TPMs and SDN controllers across the service and transport domains, and the provisioning of MTNC-IDs shared by the application (the mobile network) domain and the transport domain, where the MTNC-IDs indicate different service levels and/or slice information. The MTNC-IDs may be per CoS in the transport domain(s) that corresponds to a data plane segment like N3 or N9.

<FIG> is a diagram illustrating an embodiment of a communications system <NUM> highlighting transport segments. <FIG> shows the relationship between MTNC-IDs, 3GPP data plane segments, and transport segments. In <FIG>, service layer user plane segments (e.g., N3, N9, N6 segments) are located in different data centers interconnected by backhaul and data center transports, and there may be multiple connection segments per 3GPP data plane segment. For example, the N9 user plane segment may use multiple transport segments across data centers and/or backhaul transports. The transport segments may be represented by a list of labels or segment numbers, e.g., {L1}, {L2},.

As shown, the communications system <NUM> includes a data center <NUM>, a data center <NUM>, and a data center <NUM>. Each of the data centers may correspond to a customer network. The data centers include routers routing traffic in or out of the respective data centers, top of rack (TOR) and/or end of row (EOR) switches. The data center <NUM> includes gNBs <NUM> providing access services. A DC network <NUM> is provided in the data center <NUM> for forwarding traffic within the data center <NUM>. An SDN-C <NUM> is configured to provision and manage routing for the DC network <NUM>. Within the data center <NUM>, traffic may be transmitted by a gNB <NUM> to one of the UPFs <NUM> (i.e., segment {L1}), and forwarded from one of the UPFs <NUM> to one of the routers <NUM> (i.e., segment {L2}). Transport services for {L1} and {L2} are provided by the DC network (or transport network) <NUM> within the data center <NUM>.

The data center <NUM> includes a DC network <NUM> for forwarding traffic within the data center <NUM>. An SDN-C <NUM> is configured to provision and manage routing for the DC network <NUM>. Within the data center <NUM>, incoming traffic may be received and forwarded by one of the routers <NUM> to one of the UPFs <NUM> (i.e., segment {L4}), and outgoing traffic may be forwarded from one of the UPFs <NUM> to one of the routers <NUM> (i.e., segment {L5}). Transport services for {L4} and {L5} are provided by the DC network (or transport network) <NUM> within the data center <NUM>.

The data center <NUM> includes a DC network <NUM> for forwarding traffic within the data center <NUM>. An SDN-C <NUM> is configured to provision and manage routing for the DC network <NUM>. Incoming traffic may be received by one of the routers <NUM> and forwarded to one of application servers (AS) <NUM> (i.e., segment {L7}). Transport services for {L7} are provided by the DC network (or transport network) <NUM> within the data center <NUM>.

Traffic transmitted from the data center <NUM> to the data center <NUM> may be transported by a backhaul network <NUM>, e.g., in a segment {L3}. An SDN-C <NUM> is configured to provision and manage routing for the backhaul network <NUM>. Traffic transmitted from the data center <NUM> to the data center <NUM> may also be transported by a backhaul network <NUM>, e.g., in a segment {L6}. An SDN-C <NUM> is configured to provision and manage routing for the backhaul network <NUM>.

For traffic transmitted from the gNB <NUM> to an application server (AS) <NUM>, the traffic may pass through transport segments {L1}, {L2},. Services provided on each of the transport segments meet the requirements of a level of service of a corresponding user plane segment, e.g., N3 or N9.

In some embodiments, MTNC-IDs are provided to indicate or identify the requirements. As described above, an MTNC-ID identifies the MTNC or transport context for a user plane segment (e.g., N3 or N9), where transport resources of each transport segment along the user plane segment are provisioned according to the transport context. As discussed above, there may be one or more transport segments (consequently, one or more transport networks) corresponding to one user plane segment. For example, the N9 segment corresponds to transport segments {L2}, {L3}, and {L4}. Thus, all the transport segments {L2}, {L3}, and {L4} share one MTNC-ID of the corresponding user plane segment.

In the following, a user plane segment is referred to as a connection path between two service end points, i.e., two user plane network functions (e.g., between the gNB <NUM> and the UPF <NUM>, between the UPFs <NUM> and <NUM>, or between the UPF <NUM> and the AS <NUM>). A connection path is established for a user session or a PDU session. For example, for transmitting traffic from the data center <NUM> to the data center <NUM>, three connection paths are established, i.e., from the gNB <NUM> to the UPF <NUM>, from the UPF <NUM> to the UPF <NUM>, and from the UPF <NUM> to the AS <NUM>. The connection path may exist for the duration of the user session. A connection path may include one or more transport segments. For example, the connection path from the gNB <NUM> to the UPF <NUM> includes transport segment {L1}. The connection path from the UPF <NUM> to the UPF <NUM> includes transport segments {L2}, {L3}, and {L4}. The connection path from the UPF <NUM> to the AS <NUM> includes transport segments {L5}, {L6}, and {L7}. A connection path may also be referred to as a forwarding path, a tunnel, or a connection segment in the following embodiments.

The MTNC or transport context identified by an MTNC-ID may include the requirements for a certain level of service. The requirements may include CoS requirements, a set of QoS requirements, such as a bandwidth, a latency, jitter, etc., a resilience requirement, such as a protection level (e.g., <NUM>+<NUM>, <NUM>+<NUM>+restoration, or shared protection, etc.), and/or an isolation requirement, such as hard isolation, soft isolation, or no isolation. Based on the requirements, a network slice (also referred to herein as a transport slice) may be generated to provide routing services. The network slice corresponds to resources provisioned/allocated according to the requirements associated with the MTNC-ID.

CoS requirements indicate a classification of services into categories so that traffic of the services is treated according to the classification. CoS may be associated with a set of QoS characteristics for a network slice or service. For example, 3GPP TS <NUM>, Release <NUM>, section <NUM>. <NUM>, shows mapping from a <NUM> QoS identifier (5QI) that maps CoS to QoS characteristics. For example, a 5QI value "<NUM>" corresponds to a set of QoS characteristics of <NUM> milliseconds (ms) packet delay budget, and a <NUM> averaging window. Hard isolation means that all transport resources (including resources in all layers, packet resources, and/or optical resources) allocated for a virtual network connection (VNC) are dedicated for the VNC without sharing with another VNC. Soft isolation is generally the same as hard isolation except that optical resources may be shared with other VNCs. No isolation means that the VNC is permitted to share, with other VNCs, all transport resources.

An MTNC-ID is shared by the transport network, domains, and the 3GPP (or mobile network) domains on e.g., per (connection) path, class of service, and isolation basis. In the case that a connection path includes multiple transport segments across different domains (e.g., mobile network domains and transport domains), the same MTNC-ID is shared across the different domains. As shown in <FIG>, an MTNC-ID "<NUM>" is used for the N3 segment, which includes the transport segment {L1}. An MTNC-ID "<NUM>" is used for the N9 segment, which includes the transport segments {L2}, {L3}, and {L4}. The MTNC-ID "<NUM>" is shared across the data center <NUM> (including the DC network <NUM>), the backhaul network <NUM>, and the DC network <NUM> in the data center <NUM>. An MTNC-ID "<NUM>" is used for the N6 segment, which includes the transport segments {L5}, {L6}, and {L7}. The MTNC-ID "<NUM>" is shared across the data center <NUM> (including the DC network <NUM>), the backhaul network <NUM>, and the DC network <NUM> in the data center <NUM>.

MTNC-IDs may be set up by estimating demand on each forwarding (or connection) path between two service end points. It is noted that the 3GPP connection segments (user plane segments), e.g., the N3 and N9 segments identified by GTP tunnel endpoint identifiers (TEIDs), only exist for the duration of a PDN session. It should also be noted that an MTNC-ID is not per user (or PDN) session, and the lifetime of the MTNC-ID is based on negotiation across TPMs and SDN-Cs for that connection path and context.

MTNC-IDs may be created and managed through negotiations between TPMs and SDN controllers. Each MTNC-ID is uniquely created for each connection path. A connection path may correspond to multiple MTNC-IDs each indicating a different set of resource provisioning requirements. The MTNC-IDs may then be bound to 3GPP data plane segments (e.g., GTP TEIDs). Details will be provided in the following for carrying the MTNC-IDs in the data plane so that transport entities on-path may provide the level of service guaranteed.

A mobile network may provision resources to handle QoS, compute, and storage based on a slice and a service selected by a user. The provisioned resources may correspond to a "service slice. " For obtaining transport resources corresponding to the requirements of a service slice in the mobile network domain, it would be desirable to provide a means to request and provision these transport resources, and to carry policy binding information in data packets so that the transport domain may provide the right level of service according to the policy binding information. The policy binding information may include MTNC-IDs that need to be set up before being applied to the data packets.

<FIG> is a diagram illustrating an embodiment of a communications system <NUM>. <FIG> illustrates the negotiation of a transport context in the control plane components across TPMs and SDN-Cs. The negotiation binds the transport data plane technology and the associated route object such that a TPM may be able to enforce the corresponding transport context to subsequent control elements, such as a SMF and a UPF. Based on the transport context that is passed down to gNBs and UPFs, the gNBs and the UPFs may be able to add an MTNC-ID corresponding to the transport context to the data packets, which may be routed according to the transport context.

As shown, the communications system <NUM> includes a mobile network <NUM> and a mobile network <NUM> with traffic communicated between the two mobile networks <NUM> and <NUM>. The mobile network <NUM> includes a TPM <NUM> and a SMF <NUM>. The mobile network <NUM> includes a TPM <NUM>. Traffic of a user session initiated by a UE <NUM> is transmitted to a gNB <NUM> in the mobile network <NUM>, then forwarded to a UPF <NUM> of the mobile network <NUM>, to a UPF <NUM> of the mobile network <NUM>, and then to an AS <NUM> of the mobile network <NUM>. The N3 segment between the gNB <NUM> and the UPF <NUM> traverses a transport network <NUM>. The N9 segment between the UPFs <NUM> and <NUM> traverses a transport network <NUM>. The N6 segment between the UPF <NUM> and the AS <NUM> traverses an IP network <NUM>. The TPMs <NUM> and <NUM> and SDN-Cs <NUM> and <NUM> of the transport networks <NUM>, <NUM>, and <NUM> negotiate with each other for data plane capabilities and route lists for transporting traffic along the N3 and N9 segments in the data plane. When the user session is initiated, the SMF <NUM> may pass an MTNC-ID to the gNB <NUM>, and the UPFs <NUM> and <NUM>. The gNB <NUM> or the UPF <NUM> may add the MTNC-ID to the data packets received, and forward the packet to a transport network <NUM>.

For data flow transmission, a GTP-tunnel is established between the gNB <NUM> and the UPF <NUM>, and between the UPF <NUM> and the UPF <NUM>. For the N3 segment, data flows in the data plane are transported in a path <NUM>, i.e., from the gNB <NUM> to routers <NUM>, <NUM> and <NUM> of the transport network <NUM>, and then to the UPF <NUM>. For the N9 segments, the data flows are transported in a path <NUM>, i.e., from the UPF <NUM> to routers <NUM>, <NUM> and <NUM> of the transport network <NUM>, and then to the UPF <NUM>.

<FIG> is a diagram <NUM> illustrating communications between control plane functions, highlighting a setup of MTNC-IDs in the control plane. <FIG> shows a TPM <NUM>, a NWDAF <NUM>, a network slice selection function (NSSF) <NUM>, a PCF <NUM>, a network resource function (NRF) <NUM>, one or more TPMs <NUM>, one or more SDN-Cs <NUM>, one or more SMF <NUM>, and one or more gNBs <NUM>. The TPM <NUM>, the NWDAF <NUM>, the NSSF <NUM>, the PCF <NUM>, the NRF <NUM>, and the one or more SMFs <NUM> belong to a first customer network (first site). Each of the TPMs <NUM> belongs to a second customer network (second site), where traffic may be transmitted between the first customer network and each of the second customer networks. Each of the SMFs <NUM> is configured to manage a set of UPFs <NUM>. Each of the gNBs <NUM> provides access services to UEs in the first customer network.

Each of the SDN-Cs <NUM> belongs to a transport network, which may be a local transport network of a customer network, such as the DC network <NUM> of the data center <NUM> in <FIG>, or a non-local transport network of a customer network, such as the backhaul network <NUM> in <FIG>. Each SDN-C <NUM> manages multiple routers <NUM> within a corresponding transport network. As shown, traffic is transmitted from a gNB <NUM> to a UPF <NUM>, which then forwards the traffic to a router <NUM>.

In general, communications between the control plane functions includes determining a traffic matrix from end-to-end (E2E) (steps <NUM>, <NUM> and <NUM>), and negotiating transport resources and binding MTNC or tokens (steps <NUM>, <NUM> and <NUM>). When a mobile user session is created (step S-<NUM><NUM>), a network policy, and an MTNC-ID are installed in a UPF <NUM>. When both the UPF <NUM> and the router <NUM> (from step <NUM>) have the same binding information for the policy, resources along the transport path may be assigned accordingly.

The TPM <NUM> may obtain configuration information from databases. As shown, the TPM <NUM> may obtain information from the NSSF <NUM>, the PCF <NUM>, and the NRF <NUM> (step <NUM>). The TPM <NUM> may obtain topology and configuration information about the first customer network from the NRF <NUM> and other configuration databases. The TPM <NUM> may subscribe or poll for slice and network policy information from the NSSF <NUM> and PCF <NUM>. Information obtained here may be used in subsequent steps to derive information about connection paths and traffic matrix. Although <FIG> shows that the TPM <NUM> obtains the information from the NSSF <NUM>, the PCF <NUM>, and the NRF <NUM> at the same step <NUM>, obtaining the information from the NSSF <NUM>, the PCF <NUM>, and the NRF <NUM> may be performed in different orders, at different time or the same time.

The TPM <NUM> may derive demand estimates. The TPM <NUM> may subscribe, from the NWDAF <NUM> (step <NUM>) (and may also subscribe from a UPF <NUM>, a SMF <NUM>, or any other session and data path nodes), for data that may be used to calculate and estimate traffic on each connection path. The TPM <NUM> may also use historical data and other network policy information for deriving the estimates. The demand estimates may be used for negotiating bandwidth, latency, and other QoS provisioning with other TPMs, such as the TPM <NUM>, for transmission from the first customer network to other customer networks.

The TPM <NUM> may negotiate traffic matrices with other TPMs <NUM> (step <NUM>). The TPM <NUM> may use estimates derived at step <NUM> to agree across the networks on traffic estimates per connection path. During the communications with the other TPMs <NUM>, the TPM <NUM> and a TPM <NUM> may additionally exchange MTNC-IDs (or tokens) assigned or determined end to end (E2E) per traffic class or CoS and connection path. An MTNC-ID (token) handling system may be provided for assigning unique MTNC-IDs per traffic class and connection path.

The TPM <NUM> may program MTNC-IDs at each SDN-C <NUM>. The TPM <NUM> may send MTNC-IDs assigned/determined at step <NUM> to each SDN-C <NUM> on a connection path (corresponding to a 3GPP user plane segment, e.g., N3 or N9 segment) (step <NUM>). The MTNC-IDs (and thus, the associated service class information, such as QoS requirements bandwidth, latency, etc., which is identified by the MTNC-IDs) are used by each SDN-C <NUM> in each transport domain to program the respective transport network for providing transport services according to the MTNC-IDs.

Each SDN-C <NUM> may program routers <NUM> managed by SDN-C <NUM> with the MTNC-IDs received from the TPM <NUM> (step <NUM>). An SDN-C <NUM> may program a TE policy and parameters to routers on a TE transport path or segment and replies to the TPM <NUM> (step <NUM>). If multiple SDN-Cs <NUM> are being programmed corresponding to an MTNC-ID, such as the SDN-Cs <NUM>, <NUM> and <NUM> are programmed with the MTNC-ID "<NUM>" in <FIG>, only after all SDN-Cs <NUM> accept the TE policy, does the TPM <NUM> commit the MTNC-ID.

Each SMF <NUM> may subscribe for the MTNC-IDs. A SMF <NUM> manages a set of UPFs <NUM> in the corresponding customer network. A SMF <NUM> may request the TPM <NUM> to provide MTNC-IDs for forwarding paths between each pair of UPFs <NUM> (corresponds to a 3GPP data plane segment) (step <NUM>). If the SMF <NUM> has estimates for the forwarding path, it may provide information about the forwarding path to the TPM <NUM>. The TPM <NUM> may respond with subscription and notification for each MTNC-ID (step <NUM>), including CoS provided, slice information (for isolation), and/or load information. The TPM <NUM> may update the status of MTNC-IDs on a continual basis with notifications.

A SMF <NUM> may receive an incoming session request (step <NUM>). When the SMF <NUM> receives a session establishment request initiated by a UE, it handles the request and checks information about the request, e.g., a network policy, QoS, and slice information of the request. The SMF <NUM> may then use the policy, QoS and slicing information to derive an MTNC-ID. The SMF <NUM> may determine the MTNC-ID from a list of MTNC-IDs received from the TPM <NUM>.

The SMF <NUM> may configure the UPFs <NUM> with the derived MTNC-ID (step <NUM>). In some embodiments, the MTNC-ID may be configured in the N4 UPF configuration procedure. The N4 UPF configuration parameters may remain the same as specified in the 3GPP TS <NUM>, with the addition of the MTNC-ID, which is also configured to the UPFs <NUM>. Each UPF <NUM> may include (or add, or insert) the MTNC-ID in each data packet of the user session, as will be further described below. Transport entities on-path, such as the routers <NUM>, may inspect each data packet for an MTNC-ID, and grant resources or service levels in the transport network according to the MTNC-ID carried in each data packet. Similar configuration may also be made to a gNB <NUM> (through the N2 interface) for upstream packets over N3 interface. That is, the MTNC-ID may be configured for the gNB <NUM>, which may add the MTNC-ID to each uplink data packet, as will be further described below.

An MTNC-ID is generated by a TPM <NUM> to be unique for each connection path and per class of service (including QoS requirements and slice). There may be more than one MTNC-ID for the same QoS requirements and connection path if there is a need to provide isolation (slice) of the traffic. MTNC-IDs are per class of service and connection path, and not per user session (nor is it per data path entity).

Since MTNC-IDs are unique, TPMs <NUM> and <NUM> at sites that correspond to both ends (service end points) of a connection path may negotiate values of the MTNC-IDs assigned. The MTNC-ID space may be partitioned in the mobile domain so as to avoid collisions. The consumed identifier space may be sparse, if, e.g., the MTNC-IDs are <NUM> bits or more. Thus, a simple partitioning scheme may be feasible. A formula for determining the number of permutations for "T" traffic classes (i.e., CoS) across "N" sites, with fully meshed, may be (N*(N-<NUM>)/<NUM>) * T. If there are multiple slices for the same QoS class that needs to be fully isolated, this will increase the number of MTNC-IDs assigned. For example, if there are <NUM> traffic classes between <NUM> sites, there are <NUM> MTNC-IDs that need to be set up and managed.

A TPM <NUM> creates unique MTNC-IDs per connection path (or forwarding path) and per set of resource provisioning requirements. For example, a TPM <NUM> at a site may create unique MTNC-IDs per QoS class, path and slice (for an E2E path, i.e., a connection path, between <NUM> sites with TPMs). If two TPMs <NUM> and <NUM> create MTNC-IDs for the same path and attempt to negotiate, the tie may be broken by selecting the one with a greater value (or by any method to resolve). This may be a part of determining the traffic matrix process between the TPMs <NUM>, <NUM>. The TPM <NUM> may then set up and provision QoS and slice with each SDN-C <NUM> on the E2E path. With the MTNC-IDs configured or created, the TPM <NUM> is ready to provision the MTNC-IDs to SMFs <NUM>. Each SMF <NUM> that has subscribed to paths between sets of UPFs <NUM> are notified of the corresponding MTNC-IDs and their status. The TPM <NUM> may send different sets of MTNC-IDs to different SMFs <NUM> to manage load, lifetime, etc., of MTNC-IDs in a fine grained manner.

An SDN-C <NUM> of a transport network may obtain MTNC-IDs from a TPM <NUM> for setting up per path QoS in the transport network. It may provision routers <NUM> that it manages with the MTNC-IDs obtained and respond to the TPM <NUM>. The SDN-C <NUM> may associate transport paths configured with the MTNC-IDs that it has received. There may also be a feedback mechanism between the SDN-C <NUM> and the TPM <NUM>, where the SDN-C <NUM> constantly feeds back information about transport paths in the transport network configured according to the MTNC-IDs. The feedback information may include status of the transport paths, load, and other conditions or performance metrics of the transport paths per MTNC-ID.

Each SMF <NUM> of a customer network may send a subscription request to a TPM <NUM> of the customer network subscribing a list of MTNC-IDs for a set of UPFs <NUM> that it manages. A SMF <NUM> may send, along with the request, the set of UPFs <NUM> and additional information such as expected traffic (which may be derived based on historical patterns or an operator policy). The TPM <NUM> may acknowledge the request and notify the SMF <NUM> with a list of MTNC-IDs per connection path (e.g., UPF - UPF) and class of service (including QoS, slice). A SMF <NUM> may configure an MTNC-ID with a UPF <NUM> in the N4 session setup procedure that is specified in the 3GPP TS <NUM>. For example, a SMF <NUM> may add the MTNC-ID in the parameters that are to be provided to the UPF <NUM> in the N4 session setup procedure according to the 3GPP TS <NUM>, and send the all the parameters including the MTNC-ID to the UPF <NUM>.

In the data plane, a gNB <NUM> or a UPF <NUM> may insert the MTNC-ID in each packet to be transmitted on a connection path (e.g., N3, or N9 segment). Routers <NUM> on a connection path may provide services based on the MTNC-ID carried in each data packet and as configured by respective SDN-Cs <NUM>.

<FIG> is a diagram illustrating an embodiment of a communications system <NUM> highlighting the configuration of MTNC-IDs across multiple transport networks. The communications system <NUM> includes a customer network <NUM>. The customer network <NUM> includes control plane functions such as a TPM <NUM>, a NWDAF <NUM>, a NSSF <NUM>, a PCF <NUM>, a NRF <NUM>, and an AMF <NUM>. As discussed, the TPM <NUM> may collect data from one or more control plane functions for estimation of traffic demand, CoS, QoS requirements, and traffic matrices. The TPM <NUM> may provide a list of MTNC-IDs to a SMF <NUM> for paths between UPFs <NUM> (N9 interface) or between gNB <NUM> and UPF <NUM> (N3 interface), where each of the paths satisfies a provisioned set of QoS, CoS and isolation requirements. The TPM <NUM> also provisions MTNC-IDs to one or more SDN-Cs of transport networks, such as SDN-Cs <NUM>, <NUM>, and <NUM>, on a connection path, according to which resources are provisioned to route traffic on the connection path. Multiple MTNC-IDs may be served by the same segment routes in a transport network. The transport network is responsible to provide services that are bound by the MTNC-IDs within the transport network.

A PDN connection may be initiated by a UE. The PDN connection, as shown in this example, includes two (may be more) transport slice segments, i.e., between the gNB <NUM> and a PE router <NUM>, between PE routers <NUM> and <NUM>, and between a PE Router <NUM> and the UPF <NUM>. Based on the CoS, the QoS requirement, and the isolation requirement of the PDN connection, an MTNC-ID may be determined for the connection path between the gNB <NUM> and the UPF <NUM>. As discussed above, an MTNC-ID may also be determined for a slice segment between two UPFs, or between a UPF and an application server (if the TPM and MTNC-ID mechanism is configured by the 3GPP service provider and the application server provider).

In this example, the connection path between the gNB <NUM> and the UPF <NUM> traverses three transport networks, i.e., a CO or DC <NUM> (which is an Ethernet), a IP backhaul <NUM>, and a CO or DC <NUM> (which is also an Ethernet). Thus, the same MTNC-ID, i.e., "M-ID1" in this example, corresponding to the connection path between the gNB <NUM> and the UPF <NUM> may be provided to each of the SDN-Cs <NUM>-<NUM>. Each of the SDN-Cs <NUM>, <NUM> and <NUM> manages traffic routing for the PDN connection within the respective transport networks <NUM>, <NUM> and <NUM> according to the "M-ID1". The "M-ID1" is thus used across multiple transport networks <NUM>, <NUM>, <NUM> on-path between the gNB <NUM> and the UPF <NUM>.

In the control plane, the PDN connection setup is initiated by the UE, the SMF <NUM> provides the "M-ID1" to both the gNB <NUM> and the UPF <NUM>. In the data plane, after receiving a data packet <NUM> from a UE, the gNB <NUM> adds the "M-ID1" to the data packet <NUM> received by the gNB <NUM> and forwards the data packet <NUM> to routers in the CO or DC <NUM>. Data packets may carry meta data or the transport context indicating how the data packets should be routed by the routers. Currently, there are two approaches for carrying routing information, i.e., an explicit route list approach and an implicit route approach. In the explicit route list approach, meta data carried in data packets includes explicit route lists for each class of service. Explicit route lists may be used in cases where the control plane for routers may not be able to program the MTNC-IDs. Thus, the explicit route list approach may be used when it is necessary to limit changes to router control plane programming. In the implicit route approach, meta data carried in data packets may only include a MTNC-ID which is associated with a traffic class. The first router (or a subset of routers), e.g., an edge router, in each transport domain may inspect the MTNC-ID carried in each data packet and derive an explicit route list. Implicit routes may be used when there are multiple transport technologies (e.g., optical, multiprotocol label switching (MPLS), and Ethernet) used across a 3GPP transport segment, e.g., the N9 segment as shown in <FIG>. The multiple transport technologies may include multiprotocol label switching (MPLS), segment routing (SR), SR over IP version <NUM> (IPv6) data plane (SRV6), Enhanced Virtual Private Network, layer <NUM> (optical transport network (OTN)), or layer <NUM> (wavelength division multiplexing (WDM)) optical data planes.

Disclosed herein are embodiments directed to carrying routing information based on the implicit route approach using a UDP header. In an embodiment, the MTNC-ID is carried in a GUE header of a data packet. Z After receiving a data packet <NUM> from the UE, the gNB <NUM> encapsulates the data packet <NUM> by adding a UDP header and a GUE header to the data packet <NUM>. The MTNC-ID ("M-ID1") is added to a field of the GUE header. In an embodiment, the GUE header includes a "C" flag field, a proto/ctype field, and an "M" flag field. In one embodiment, the "C" flag field is set to indicate that the data packet <NUM> carries a data message, and the "M" flag field is set to indicate that the data packet <NUM> includes the MTNC-ID corresponding to the forwarding path along which the data packet <NUM> should be forwarded. In another embodiment, the "C" flag field is set to indicate that the data packet <NUM> includes a data message, and the proto/ctype field indicates that the data packet <NUM> includes the MTNC-ID.

In some cases, each of the three transport networks, i.e., CO or DC <NUM>, an IP backhaul <NUM>, and a CO or DC <NUM>, may implement a different transport technology, such as, MPLS, SR, SRV6, layer <NUM> (OTN), layer o (WDM) optical data planes, IP version <NUM> (IPv4), or IPv6. The data packet <NUM> that is encapsulated to include the GUE header can be forwarded through the three transport networks <NUM>, <NUM>, <NUM> such that routers within the three transport networks <NUM>, <NUM>, <NUM> may process the data packet <NUM> regardless of the transport technology implemented by the transport network <NUM>, <NUM>, <NUM>.

In these embodiments, routers within each of the three transport networks <NUM>, <NUM>, <NUM> first extract the MTNC-ID from the GUE header, determine a next router by which to forward the data packet <NUM> using a local forwarding table, and forward the data packet <NUM> to the next router. For example, after the gNB <NUM> encapsulates the data packet <NUM> to include the MTNC-ID of the data packet <NUM> in a GUE header of the data packet <NUM>, the gNB <NUM> forwards the data packet <NUM> to a next hop (e.g., router in the CO or DC <NUM>). The router then extracts the MTNC-ID from the GUE header of the data packet <NUM> and searches a local forwarding table to determine a next hop for the data packet <NUM> based on the MTNC-ID. Upon determining the next hop for the data packet <NUM>, the router forwards the data packet <NUM> to the next hop as identified based on the MTNC-ID. As shown by <FIG>, the data packet <NUM>, including the MTNC-ID in the GUE header, is forwarded through the three transport networks <NUM>, <NUM>, <NUM> to the UPF <NUM> in a similar fashion.

<FIG> is a diagram illustrating an example of data packet <NUM>, which is similar to data packet <NUM>, and configured to carry the MTNC-ID, according to various embodiments of the disclosure. As shown by <FIG>, the data packet <NUM> includes a standard IPv4 or IPv6 header <NUM>, a UDP extension header <NUM>, and an encapsulated packet or control message <NUM>. The UDP extension header <NUM> includes a UDP header <NUM> and a GUE header <NUM>.

The standard IPv4 or IPv6 header <NUM> may include an IPv4 header or an IPv6 header. An IPv4 header may be similar to the IPv4 header described by Internet Engineering Task Force (IETF) Request for Comments (RFC) <NUM> entitled "Internet Protocol," dated September <NUM>. An IPv6 header may be similar to an IPv6 header described by IETF RFC <NUM> entitled "Internet Protocol, version <NUM> (IPv6) specification," dated July <NUM>. Both the IPv4 header and the IPv6 header include data used by NEs within a transport network to forward the data packet <NUM>. For example, the IPv4 header and the IPv6 header both include fields to carry a source address and a destination address of the data packet <NUM>. The UDP header <NUM> is similar to the UDP header described by IETF RFC <NUM> entitled "User Datagram Protocol," dated August <NUM>.

The GUE header <NUM> is a header encapsulated onto the data packet <NUM> with the UDP header <NUM> and used for transporting packets of different IP protocols across layer <NUM> networks. The GUE header <NUM> is variable length protocol header that is composed of a primary four byte header and zero or more four byte words of optional header data. The format of a GUE header <NUM> is similar to the GUE header described by the Internet Area Working Group draft document entitled "Generic UDP Encapsulation," by T. Herbet, et. , dated March <NUM>, <NUM> (hereinafter referred to as the "GUE Header Draft"). Examples of the GUE header <NUM> that are configured to carry the MTNC-ID are further described below with reference to <FIG>.

The encapsulated packet or control message <NUM> is the payload of the data packet <NUM>. For example, the encapsulated packet or control message <NUM> may carry user data or a control message, such as an Operations, Administration, and Maintenance (OAM) message.

<FIG> is a diagram illustrating various fields within a UDP extension header <NUM> of the data packet <NUM> according to various embodiments of the disclosure. Similar to the data packet <NUM> of the <FIG>, the UDP extension header <NUM> of <FIG> includes the UDP header <NUM> and the GUE header <NUM>.

The UDP header <NUM> includes a source port field <NUM>, a destination port field <NUM>, a length field <NUM>, and a checksum field <NUM>. The source port field <NUM> is set to indicate the local source port for a connection when connection semantics are applied to an encapsulation. The source port field <NUM> is set to a flow entropy value or a GUE assigned port number when connection semantics are not applied. The destination port field <NUM> is set to indicate the local destination port when connection semantics are applied to an encapsulation. The destination port field <NUM> is set to the GUE assigned port number when connection semantics are not applied. The length field <NUM> includes the canonical length of the data packet <NUM>. The checksum field <NUM> includes a standard UDP checksum. The fields within the UDP header <NUM> are further described in the GUE Header Draft.

The GUE header <NUM> includes a "<NUM>" flag field <NUM>, a "C" flag field <NUM>, an Hlen field <NUM>, a proto/ctype field <NUM>, a flags field <NUM>, an "M" flag field <NUM>, an MTNC-ID field <NUM>, and a private data field <NUM>. The "<NUM>" flag field <NUM> indicates, when the "<NUM>" flag field <NUM> is set to <NUM>, that the data packet <NUM> is encoded according to the GUE protocol version <NUM> with the GUE header <NUM>. The "C" flag field <NUM> (also referred to as the "C-bit") includes a flag, or bit, indicating whether the data packet <NUM> carries a control message or a data message. When the "C" flag field <NUM> is set to <NUM>, the data packet <NUM> carries a control message. When the "C" flag field <NUM> is not set (e.g., is set to <NUM>), the data packet <NUM> carries a data message.

The Hlen field <NUM> carries a length of the GUE header <NUM> in <NUM> bit words, including optional extension fields but not the first four bytes of the GUE header <NUM>. The proto/ctype field <NUM> carries a control message type for the payload included in the data packet <NUM> when the "C" flag field <NUM> is set to <NUM> (indicating that the data packet <NUM> carries a control message). In contrast, when the "C" flag field <NUM> is not set (indicating that the data packet <NUM> carries a data message), the proto/ctype field <NUM> carries the IP number for the encapsulated packet in the payload of the data packet <NUM>.

The flags field <NUM> includes header flags that are allocated for various purposes and may indicate the presence of an extension field. In an embodiment, the flags field <NUM> of the GUE header <NUM> includes an "M" flag field <NUM> (also referred to as the "M flag" or "M bit"). In an embodiment, when the "C" flag field <NUM> is not set (indicating that the data packet <NUM> carries a data message), then the flags field <NUM> of the GUE header <NUM> includes an "M" flag field <NUM>. The "M" flag field <NUM>, when set, indicates that the GUE header <NUM>, and thus the data packet <NUM>, includes an MTNC-ID field <NUM>. The MTNC-ID field <NUM> is an extension field of the GUE header <NUM> that carries the MTNC-ID associated with the data packet <NUM>. As described above, the MTNC-ID corresponds to the forwarding path along which to forward the data path, in which the forwarding path is associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path. Each router or switch on the forwarding path that receives the data packet <NUM> extracts the MTNC-ID from the MTNC-ID field <NUM> of the data packet <NUM> and provisions transport resources for traffic forwarding on the forwarding path based on the MTNC-ID.

In an embodiment in which the "C" flag field <NUM> is set to <NUM> (indicating that the data packet <NUM> carries a control message), the flags field <NUM> may not include the "M" flag field <NUM>. Instead, the proto/ctype field <NUM> includes a value indicating that the GUE header <NUM>, and thus the data packet <NUM>, includes an MTNC-ID field <NUM>, which is an extension field of the GUE header <NUM> that carries the MTNC-ID associated with the data packet <NUM>.

<FIG> is a diagram illustrating an example of a UDP extension header <NUM> of the data packet <NUM> according to various embodiments of the disclosure. The UDP extension header <NUM> is similar to the UDP extension header <NUM> described above with reference to <FIG>. However, unlike the UDP extension header <NUM> of <FIG>, the UDP extension header <NUM> of <FIG> is included in a data packet <NUM> carrying a data message.

The UDP extension header <NUM> includes a UDP header <NUM> and a GUE header <NUM>. The UDP header <NUM> of the UDP extension header <NUM> of <FIG> includes fields similar to the UDP header <NUM> of the UPD extension header <NUM> of <FIG>. In this way, the UDP header <NUM> of <FIG> includes the source port field <NUM>, destination port field <NUM>, length field <NUM>, and checksum field <NUM>, each of which is described above with reference to <FIG>.

The GUE header <NUM> includes the "<NUM>" flag field <NUM>, "C" flag field <NUM>, Hlen field <NUM>, proto/ctype field <NUM>, flags field <NUM>, "M" flag field <NUM>, and MTNC-ID field <NUM>. The "<NUM>" flag field <NUM>, Hlen field <NUM>, proto/ctype field <NUM>, and MTNC-ID field <NUM> are similar to the fields in the GUE header <NUM> described above with reference to <FIG>.

In the GUE header <NUM>, the "C" flag field <NUM> is set to indicate that the data packet <NUM> including the UDP extension header <NUM> carries a data message. For example, in this case, the "C" flag field <NUM> is set to <NUM>, which indicates that the data packet <NUM> including the UDP extension header <NUM> carries a data message.

In this embodiment, when the "C" flag field <NUM> is set to indicate that the data packet <NUM> including the UDP extension header <NUM> carries a data message, the flags field <NUM> includes an "M" flag field <NUM>. As described above, the "M" flag field <NUM> contains a flag or bit indicating whether a MTNC-ID is carried in an extension field (e.g., in the MTNC-ID field <NUM>) of the GUE header <NUM>.

<FIG> is a diagram illustrating another example of a UDP extension header <NUM> of the data packet <NUM> according to various embodiments of the disclosure. The UDP extension header <NUM> is similar to the UDP extension header <NUM> described above with reference to <FIG>. However, the UDP extension header <NUM> of <FIG> is included in a data packet <NUM> carrying a control message.

The UDP extension header <NUM> includes a UDP header <NUM> and a GUE header <NUM>. The UDP header <NUM> of the UDP extension header <NUM> of <FIG> includes fields similar to the UDP header <NUM> of the UPD extension header <NUM> of <FIG>. In this way, the UDP header <NUM> in <FIG> includes the source port field <NUM>, destination port field <NUM>, length field <NUM>, and checksum field <NUM>, each of which is described above with reference to <FIG>.

The GUE header <NUM> includes the "<NUM>" flag field <NUM>, "C" flag field <NUM>, Hlen field <NUM>, proto/ctype field <NUM>, flags <NUM>, and MTNC-ID field <NUM>. The "<NUM>" flag field <NUM>, Hlen field <NUM>, and MTNC-ID field <NUM>, are similar to the fields in the GUE header <NUM> described above with reference to <FIG>.

In the GUE header <NUM>, the "C" flag field <NUM> is set (or not set) to indicate that the data packet <NUM> including the UDP extension header <NUM> carries a control message. For example, in this case, the "C" flag field <NUM> is set to <NUM>, which indicates that the data packet <NUM> including the UDP extension header <NUM> carries a control message.

In this embodiment, when the "C" flag field <NUM> is set to indicate that the data packet <NUM> including the UDP extension header <NUM> carries a control message, the flags <NUM> do not include an "M" flag field. Instead, the proto/ctype field <NUM> carries a Ctype value indicating whether a MTNC-ID is carried in an extension field (e.g., in the MTNC-ID field <NUM>) of the GUE header <NUM>.

As shown by <FIG> and <FIG>, data packets <NUM> are modified to include an extension header (e.g., MTNC-ID field <NUM>) configured to carry an MNTC-ID associated with a forwarding path along which the data packet <NUM> should be forwarded. The data packet <NUM> includes an indicator signaling that the data packet <NUM> carries an MNTC-ID, in which the indicator is included in either the "M" flag field <NUM> or the proto/ctype field <NUM>.

<FIG> is a diagram <NUM> illustrating an encapsulation of data packets across a communications system, such as the communications system <NUM> of <FIG>, according to various embodiments of the disclosure. In particular, diagram <NUM> shows encapsulated data packets <NUM>, <NUM>, and <NUM>, which may be similar to the data packets <NUM> and <NUM>.

The encapsulated data packet <NUM> represents the data packet after encapsulation is performed by the gNB, such as the gNB <NUM> of the communications network <NUM>. For example, when the gNB receives a data packet from an UE comprising user data <NUM>, the gNB encapsulates the data packet to include an inner IP header <NUM>, a GTP - user data tunnel (GTP-U) header <NUM>, the UDP extension header <NUM>, and an outer IP header <NUM>. In this way, at the gNB, the encapsulated data packet <NUM> includes the outer IP header <NUM>, the UDP extension header <NUM>, the GTP-U header <NUM>, the inner IP header <NUM>, and the user data <NUM>.

The outer IP header <NUM> may be an IPv6 header or an IPv4 header signaling the source and the destination for a first communication path (e.g., N3 segment) between the gNB and the first UPF on the forwarding path. For example, referring back to the communications system <NUM> of <FIG>, the outer IP header <NUM> may indicate that the source is the gNB <NUM> and that the destination is the UPF <NUM>.

The UDP extension header <NUM> may be similar to the UDP extension headers <NUM>, <NUM>, or <NUM> described above with reference to <FIG>, <FIG>, and <FIG>, respectively. As described above, the UDP extension header <NUM> includes the UDP header and the GUE header, in which the GUE header carries the MTNC-ID <NUM> associated with the forwarding path along which to forward the encapsulated data packet <NUM>.

The GTP-U header <NUM> may be similar to the standard GTP-U header, as further described in the 3GPP TS <NUM> document. For example, the GTP-U header <NUM> may include tunnel endpoint identifiers indicating endpoints of the communication path.

The inner IP header <NUM> may be an IPv6 header or an IPv4 header signaling the end source and the end destination of the encapsulated data packet <NUM>. For example, the inner IP header <NUM> may indicate the source as an address of the UE from which the user data <NUM> originated, and the destination as an address of the destination toward which the encapsulated data packet <NUM> is destined. The user data <NUM> may be the payload of the encapsulated data packet <NUM>, including the user data <NUM> received from the UE or source.

Referring now to the encapsulated data packet <NUM>, the encapsulated data packet <NUM> represents the data packet being transported through the N9 segment. For example, referring back to the communications system <NUM> of <FIG>, after the UPF <NUM> receives the encapsulated data packet <NUM>, and the UPF <NUM> decapsulates the encapsulated data packet <NUM> by removing the outer IP header <NUM> from the encapsulated data packet <NUM>. The UPF <NUM> adds a new outer IP header <NUM> to the encapsulated data packet <NUM> to create the encapsulated data packet <NUM>. The new outer IP header <NUM> indicates the source and the destination for the next communication path (e.g., N9 segment) along the forwarding path to the destination. In this case, still referring to the communications system <NUM> of <FIG>, the outer IP header <NUM> may indicate that the source is the UPF <NUM> and that the destination is the UPF <NUM>. Similar to the encapsulated data packet <NUM>, the encapsulated data packet <NUM> includes the same UDP extension header <NUM>, GTP-U header <NUM>, inner IP header <NUM>, and user data <NUM>.

The encapsulated data packet <NUM> represents the data packet being transported through the N6 segment. For example, referring back to the communications system <NUM> of <FIG>, after the UPF <NUM> receives the encapsulated data packet <NUM>, and the UPF <NUM> decapsulates the encapsulated data packet <NUM> by removing the outer IP header <NUM> from the encapsulated data packet <NUM>. The UPF <NUM> adds a new outer IP header <NUM> to the encapsulated data packet <NUM> to create the encapsulated data packet <NUM>. The new outer IP header <NUM> indicates the source and the destination for the next communication path (e.g., N6 segment) along the forwarding path to the destination. In this case, still referring to the communications system <NUM> of <FIG>, the outer IP header <NUM> may indicate that the source is the UPF <NUM> and that the destination is the AS <NUM>. Similar to the encapsulated data packets <NUM> and <NUM>, the encapsulated data packet <NUM> includes the same UDP extension header <NUM>, GTP-U header <NUM>, inner IP header <NUM>, and user data <NUM>.

As shown by <FIG>, as a data packet passes through multiple domains (e.g., transport networks) of a communications system, only the outer IP headers <NUM>, <NUM>, and <NUM>, which indicate the source and destination of the communications paths (e.g., N3, N6, and N9 segments) along which the data packet is forwarded, change. The UDP extension header <NUM>, GTP-U header <NUM>, inner IP header <NUM>, and user data <NUM> remain the same in the data packet as the data packet passes through multiple domains of a communications system. In this way, the MTNC-ID <NUM> is carried in UDP extension header <NUM> of the data packet as the data packet passes through multiple domains of a communications system, regardless of the transport technology implemented by each domain.

<FIG> is a flowchart illustrating a method <NUM> of transporting MTNC-IDs across multiple domains (e.g., transport networks) according to various embodiments of the disclosure. Method <NUM> may be implemented by a gNB (e.g., gNB <NUM>) within a communications system (e.g., communications system <NUM>). Method <NUM> may be implemented after the NEs (e.g., nodes) in the communications system <NUM> have programmed the MTNC-IDs assigned by the TPM. For example, the NEs within the transport networks of the communications system maintain a forwarding table that stores the MTNC-IDs and the corresponding forwarding paths associated with the MTNC-ID. In this way, each NE may obtain a next NE along which to forward a data packet including a particular MTNC-ID. Method <NUM> may also be implemented after the gNB receives a data packet from a UE.

At step <NUM>, the gNB indicates that a data packet comprises a MTNC-ID. The gNB encapsulates the data packet to include the UDP extension header <NUM> or the UDP extension header <NUM>. In an embodiment, the MTNC-ID corresponds to a forwarding path and is associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path to provision transport resources for traffic forwarding on the forwarding path.

At step <NUM>, the gNB inserts the MTNC-ID into the GUE header of the data packet. For example, after receiving the data packet <NUM> from a UE and encapsulating the data packet <NUM> to include a UDP header <NUM> and a GUE header <NUM>, the gNB inserts the MTNC-ID into the MTNC-ID field <NUM> of the GUE header <NUM> of the data packet <NUM>.

At step <NUM>, the data packet is transmitted to a NE in the communications system based on the forwarding path corresponding to the MTNC-ID. For example, the gNB searches a local forwarding table to determine the forwarding path, and thus the next hop, by which to forward the data packet based on the MTNC-ID carried in the GUE header. The gNB forwards the data packet to the next hop, or the NE, in the communications system identified using the forwarding table.

<FIG> is a flowchart illustrating another method <NUM> of transporting MTNC-IDs across multiple domains (e.g., transport networks) according to various embodiments of the disclosure. Method <NUM> may be implemented by an intermediate NE in the communications system. For example, in the communications system <NUM> of <FIG>, the method <NUM> may be implemented by the routers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. In the communications system <NUM> of <FIG>, the method <NUM> may also be implemented by the UPFs <NUM> or <NUM> or the AS <NUM>. Method <NUM> may be implemented after the NEs (e.g., routers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, UPFs <NUM> and <NUM>, and the AS <NUM>) in the communications system <NUM> have programmed the MTNC-IDs assigned by the TPM. Method <NUM> may also be implemented after the gNB receives a data packet from a UE, and forwards the data packet along the forwarding path identified by the MTNC-ID.

At step <NUM>, the NE receives a data packet carrying a MTNC-ID in a GUE header of the data packet from a previous NE (e.g., prior hop, upstream node, etc.) in the communications system. For example, the data packet was previously encapsulated to include the UDP extension header <NUM> or the UDP extension header <NUM>, and the MTNC-ID is carried in a field of the GUE header. In an embodiment, the MTNC-ID corresponds to a forwarding path and is associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path to provision transport resources for traffic forwarding on the forwarding path.

At step <NUM>, the NE obtains the forwarding path corresponding to the MTNC-ID from a local forwarding table. For example, each NE in the communications system that receives the MTNC-ID stores the MTNC-ID and details of the forwarding path in a local forwarding table. The forwarding table also stores the set of resource provisioning requirements for one or more transport networks on the forwarding path such that the NE is configured to provision transport resources for traffic forwarding on the forwarding path. By searching the local forwarding table, the NE is able to obtain the forwarding path corresponding to the MTNC-ID.

At step <NUM>, the NE transmits the data packet to a next NE (e.g., next hop, downstream node, etc.) on the forwarding path based on the MTNC-ID. After the NE searches the forwarding table to obtain a next hop identified by the MTNC-ID, the NE forwards the data packet to the next hop (e.g., next NE) on the forwarding path.

<FIG> is a diagram of an embodiment of a network element (NE) <NUM> in the network <NUM>. For instance, the NE <NUM> may be similar to the routers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, UPFs <NUM> and <NUM>, and the AS <NUM> in the communications system <NUM> of <FIG>. The NE <NUM> may be configured to implement and/or support the methods transporting MTNC-IDs across multiple domains (e.g., transport networks) described herein. The NE <NUM> may be implemented in a single node or the functionality of NE <NUM> may be implemented in a plurality of nodes. One skilled in the art will recognize that the term NE encompasses a broad range of devices of which NE <NUM> is merely an example. The NE <NUM> is included for purposes of clarity of discussion, but is in no way meant to limit the application of the present disclosure to a particular NE embodiment or class of NE embodiments. At least some of the features and/or methods described in the disclosure may be implemented in a network apparatus or module such as an NE <NUM>. For instance, the features and/or methods in the disclosure may be implemented using hardware, firmware, and/or software installed to run on hardware. As shown in <FIG>, the NE <NUM> comprises one or more ingress ports <NUM> and a receiver unit (Rx) <NUM> for receiving data, at least one processor, logic unit, or central processing unit (CPU) <NUM> to process the data, a transmitter unit (Tx) <NUM> and one or more egress ports <NUM> for transmitting the data, and a memory <NUM> for storing the data.

The processor <NUM> may comprise one or more multi-core processors and be coupled to a memory <NUM>, which may function as data stores, buffers, etc. The processor <NUM> may be implemented as a general processor or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs). The processor <NUM> may comprise a path module <NUM>, which may perform methods <NUM> and <NUM> discussed above. As such, the inclusion of the path module <NUM> and associated methods and systems provide improvements to the functionality of the NE <NUM>. Further, the path module <NUM> effects a transformation of a particular article (e.g., the network) to a different state. In an alternative embodiment, path module <NUM> may be implemented as instructions stored in the memory <NUM>, which may be executed by the processor <NUM>.

The memory <NUM> may comprise a cache for temporarily storing content, e.g., a random-access memory (RAM). Additionally, the memory <NUM> may comprise a long-term storage for storing content relatively longer, e.g., a read-only memory (ROM). For instance, the cache and the long-term storage may include dynamic RAMs (DRAMs), solid-state drives (SSDs), hard disks, or combinations thereof. The memory <NUM> may be configured to the forwarding table <NUM>, which stores mappings between the MTNC-IDs <NUM> and the forwarding paths <NUM>. In this way, the forwarding table <NUM> indicates the next hop (e.g., next NE) on a forwarding path by which to forwarding a data packet carrying the MTNC-ID <NUM> in a GUE header.

It is understood that by programming and/or loading executable instructions onto the NE <NUM>, at least one of the processor <NUM> and/or memory <NUM> are changed, transforming the NE <NUM> in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC in a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.

<FIG> is a diagram of an apparatus <NUM> configured to transport MTNC-IDs across multiple domains. The apparatus <NUM> comprises a means for indicating <NUM> that a data packet comprises a MTNC-ID corresponding to a forwarding path and being associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path to provision transport resources for traffic forwarding on the forwarding path, a means for inserting <NUM> the MTNC-ID into a GUE header of the data packet, and a means for transmitting <NUM> the data packet to a NE in the communications system based on the forwarding path corresponding to the MTNC-ID.

<FIG> is a diagram of an apparatus <NUM> configured to transport MTNC-IDs across multiple domains. The apparatus <NUM> comprises a means for receiving <NUM> a data packet carrying a MTNC-ID in a GUE header of the data packet from a previous NE in the communications system, the MTNC-ID corresponding to a forwarding path and being associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path to provision transport resources for traffic forwarding on the forwarding, a means for searching <NUM> a local forwarding table for the forwarding path corresponding to the MTNC-ID, and a means for transmitting <NUM> the data packet to a next NE on the forwarding path based on the MTNC-ID.

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

Claim 1:
A method performed by a Next Generation Node B, gNB, in a communications system implementing User Datagram Protocol, UDP, comprising:
encapsulating a data packet to include a UDP header and a Generic UDP Encapsulation, GUE, header, wherein the GUE header comprises a proto/ctype or M type field and a multi-transport network context-identifier, MTNC-ID, field;
indicating (<NUM>) by the proto/ctype or M type field of the GUE header that the data packet comprises a MTNC-ID corresponding to a forwarding path and being associated with a set of resource provisioning requirements for one or more transport networks on the forwarding path to provision transport resources for traffic forwarding on the forwarding path;
inserting (<NUM>) the MTNC-ID into the Generic UDP Encapsulation, GUE, header of the data packet, wherein the MTNC-ID is inserted into and carried by the MTNC-ID field; and
transmitting (<NUM>) the data packet with the UDP header and the GUE header to a network element, NE, in the communications system based on the forwarding path corresponding to the MTNC-ID.