TECHNICAL FIELD

[0001] The present technology pertains to segment routing, and more specifically to implementing segment routing in a 5G network environment without the need for tunneling.

BACKGROUND

[0002] Segment Routing for IPv6 (SRv6) is a source routing technique that allows a packet to be steered through an explicit path or ordered list of segments in a network. This is achieved via the insertion of a Segment Routing Header (SRH) into an IPv6 packet, wherein the SRH contains sufficient information to specify the sequence of on-path routers that should be traversed in order to steer the packet through the desired explicit path. Within the SRH, the explicit path information comprises an ordered set of instructions, wherein each instruction is referred to as a segment and has its own segment ID (SID). This ordered set of instructions can be encoded as a label stack, with each label representing one particular segment and the MPLS label values carrying the corresponding SIDs. In this manner, an MPLS-enabled (Multiprotocol Label Switching) network can process the SRH without needing to store additional state information on all of the routers along the desired path.

[0003] Unlike previous source routing techniques, SRv6 assigns the responsibility of creating the explicit path information to an ingress router - previous source routing techniques relied upon the sending host to encode an explicit path for a packet, meaning that a malicious actor could gain access to a private network given sufficient knowledge of which routers to traverse in order to reach the target. However, conventional proposals for implementing SRv6 in a mobile user-plane do not make use of an ingress router (edge node) to insert the SRH, and instead rely upon an on-path node such as a gNB (e.g., found in fifth-generation (5G) mobile networks) to insert the SRH. As an additional complicating factor, the base IPv6 specifications (RFC 8200) disallow an on-path node from inserting an SRH into a received packet without first encapsulating the received packet in a new IPv6 packet with the on-path node itself as the source. Consequently, conventional proposals for implementing SRv6 in the mobile user-plane must therefore rely upon tunneling. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In order to describe the manner in which the above recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only example embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0005] FIG. 1 illustrates an example diagram and process flow of an example end-to-end SRv6 service delivery in a 5G mobile network environment according to one or more aspects of the present disclosure;

[0006] FIG. 2 illustrates an example diagram and process flow of an example end-to-end SRv6 service delivery in a 5G Software Defined Access (SDA) environment according to one or more aspects of the present disclosure;

[0007] FIG. 3 illustrates an example method according to aspects of the present disclosure;

[0008] FIG. 4 illustrates an example network device upon which one or more aspects of the present disclosure may be provided; and

[0009] FIG. 5 illustrates an example computing system architecture upon which one or more aspects of the present disclosure may be provided.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0010] Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. Thus, the following description and drawings are illustrative and are not to be construed as limiting the scope of the embodiments described herein. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well- known or conventional details are not described in order to avoid obscuring the description.

[0011] Reference to“one embodiment” or“an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase“in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others.

[0012] The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Alternative language and synonyms may be used for any one or more of the terms discussed herein, and no special significance should be placed upon whether or not a term is elaborated or discussed herein. In some cases, synonyms for certain terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any terms discussed herein is illustrative only, and is not intended to further limit the scope and meaning of the disclosure or of any example term. Likewise, the disclosure is not limited to various embodiments given in this specification.

[0013] Without intent to limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, technical and scientific terms used herein have the meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.

[0014] Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.

OVERVIEW

[0015] Disclosed are systems and methods for SRv6 (Segment Routing for IPv6) service delivery in end-to-end fashion with collaboration across different control planes of a fifth- generation (5G) environment. A registration request is transmitted to a first control plane element of the 5G environment, where the registration request specifies one or more requested services within the 5G environment. In some embodiments, the registration request comprises (or is replaced by) an access authentication/NAS signaling message. For each service, one or more associated service requirements are determined and subsequently used to generate one or more Service Level Agreement (SLA)-specific service requests. For each SLA-specific service request, a first bidirectional path is instantiated through a core portion of the 5G environment, and is stored as a first SRv6 segment stack. A first SLA-Binding SID (SLA-BSID) is generated in order to associate the first SRv6 segment stack with its SLA- specific service request. A second bidirectional path is then instantiated to connect a Radio Access Network (RAN) to the core portion of the 5G environment, and is stored as a second SRv6 segment stack. The first SLA-BSID is appended as the last segment of the second SRv6 segment stack, and a second SLA-BSID is generated in order to associate the second SRv6 segment stack with the same SLA-specific service request. The second SLA-BSID is transmitted to the originator of the access authentication/NAS signaling message.

EXAMPLE EMBODIMENTS

[0016] In comparison to prior generations of mobile and wireless networks, fifth generation (5G) mobile and wireless networks will provide enhanced mobile broadband communications and deliver a wider range of services and applications than ever before. Unlike prior generation networks, the 5G architecture is service based, meaning that wherever suitable, 5G architecture elements are defined as network functions (NFs) that offer their services to other network functions via common framework interfaces. Many of the services and network functions contemplated in the context of 5G networks are either new or are improvements on existing implementations that have just now been enabled or made cost effective in light of the enhanced functionalities offered by 5G networks.

[0017] In the context of the present disclosure, one such example is the disclosed SRv6 functionality that can advantageously be implemented in a 5G mobile user-plane without the need for tunneling (e.g., GTP-U), thereby providing a key optimization to the mobile user- plane. In order to achieve this improved mobile user-plane SRv6 functionality, it is contemplated that limited but relevant segment routing policy information and overlay encapsulation details can be offloaded from one or more control planes participating in the 5G network to a given User Equipment (UE). Additionally, the control planes participating in the 5G network can compile and transmit the necessary segment list(s) to the UE, for example upon successful access authentication of the UE.

[0018] Because the segment lists are delivered with one or more associated flow policies, the UE is able to construct a complete Segment Routing Header (SRH) and include it in a desired packet for transmission. Because the UE itself inserts the SRH, and not an on-path node such as a gNB (next generation NodeB) or UPF (User Plane Function) of the 5G network, there is no re-encapsulation and there is no tunneling, which can be undesirable in the mobile user- plane, as mentioned previously. In some embodiments, the UE may also insert additional details such as a timestamp or other monitoring information into the SRH or some other overlay header, such that these additional details can later be used during transmission of the packet to provide service assurance and/or to take necessary actions within or upon the 5G network environment. For example, a timestamp or other monitoring information could be used to provide OAM (Operations, Administration and Management) functionality and telemetry computation in the SRH.

[0019] The disclosure turns now to FIG. 1, which depicts an example diagram and process flow 100 for end-to-end cross-layer control plane collaboration for a 5G mobile network environment according to one or more aspects of the present disclosure. It is noted that although a 5G mobile network environment is discussed in the following example, other mobile network environments are compatible with aspects of the present disclosure and the instant example is not intended to be limiting. Additionally, although reference is made in general to a 5G network, it is appreciated that this description encompasses both a full- fledged 5G core (5GC) network as well as a combined 4G/5G Evolved Packet Core (EPC) network, as would be appreciated by one of ordinary skill in the art.

[0020] The various constituent components depicted in diagram and process flow 100 can be divided broadly into a set of user plane components and a set of control plane components. For purposes of clarity, user plane components are indicated as rectangles with rounded corners (e.g., 110, 120, 130, 140) and control plane components are indicated as rectangles with 90-degree corners (e.g., 150, 160, 170, 180). As illustrated, there are four user plane components: User Equipment (UE) 110; Radio Access Network (RAN) 120; Mobile Backhaul Network 130; and 5G Core Network 140.

[0021] User Equipment (UE) 110 is depicted as a smartphone or mobile computing device, but in general it is contemplated that UE 110 can comprise all manner of devices capable of connecting to or otherwise wirelessly communicating with the 5G mobile network, including but not limited to Internet-of- Things (IoT) devices, connected automobiles, drones, factory equipment with cellular modems, a repeater or extender station, etc. In the context of FIG. 1, UE 110 begins in an unregistered state with respect to the 5G mobile network.

[0022] Radio Access Network (RAN) 120 comprises a plurality of discrete radio cells, base stations, towers, or other radio infrastructure elements that are utilized to provide the most immediate and direct wireless connection to various UEs such as UE 110. A first border node 125 is depicted as interconnecting RAN 120 to mobile backhaul network 130, although it is appreciated that a plurality of different first border nodes 125 can be employed without departing from the scope of the present disclosure. For example, rather than using a single first border node 125 to connect all of the discrete infrastructure elements of RAN 120 to mobile backhaul network 130, a number of first border nodes 125 approximately equal to the number of discrete RAN infrastructure elements could utilized.

[0023] Mobile backhaul network 130 connects each of the discrete infrastructure elements of RAN 120 to the 5G core network 140, via pathways traversing at least the one or more first border nodes 125, a Multi-access Edge Computing (MEC) network edge 132, one or more User Plane Functions (UPFs) 134, and one or more second border nodes 135. The one or more second border nodes 135 are disposed between the mobile backhaul network 130 and the 5G core network 140 and control ingress and/or egress for the 5G core network 140. In some embodiments, the second border nodes can be similar or identical to one or more of the first border nodes 125. In some embodiments, one or more of the second border nodes 135 can be different than a first border node 125. In general, mobile backhaul network 130 provides a transport pipeline for bidirectional communications traveling between the relatively distributed radio elements of RAN 120 (each element typically having its own unique location, e.g., uniquely located cell towers) and the relatively centralized 5G core network 140.

[0024] 5G core network 140 implements one or more 5G network core architectures as would be appreciated by one of ordinary skill in the art. As illustrated, 5G core network 140 comprises at least one User Plane Function (UPF) 144, although various other network functions (NFs) can be provided as needed or in accordance with a desired 5G network core architecture. Also shown are one or more third border nodes 145, which can be used, for example, to connect 5G core network 140 to one or more data networks (not shown) such as the Internet. Various ones of the third border nodes 145 can be similar to, identical to, or different from the first border nodes 125 and/or the second border nodes 135.

[0025] In addition to these four user plane components described above, FIG. 1 also depicts four control plane components (noting again that control plane components have 90-degree corners in contrast to the rounded corners of the user plane components). The four control plane components include: Core Access and Mobility Management Function (AMF) 150; Session Management Function (SMF) 160; Policy Control Function (PCF) 170; and Path Computation Element (PCE) 180. The functionalities and specific compositions and sub components of these four control plane components will be appreciated by one of ordinary skill in the art, and can be provided according to one or more existing 5G mobile network architectures as desired. It is noted again that in Evolved Packet Core (EPC) networks which combine 4G and 5G elements, that one or more of the control plane components might change in accordance with the accepted EPC architecture, e.g., AMF 150 could instead be provided as a Mobility Management Entity (MME).

[0026] The disclosure turns now to the illustrated sequential flow presented in diagram 100. Nine different steps are identified as numerals contained within a circle; dotted lines with arrows indicate the parties involved in each step and the direction of the flow between the involved parties. The flow begins with UE 110 in an unregistered state and concludes with UE 110 receiving, from the control plane components, the necessary segment routing information for UE 110 to create a Segment Routing Header (SRH) for various packets it wishes to transmit.

[0027] Step (1 ): UE 110 registers with the 5G mobile network by transmitting an access authentication/NAS signaling message to AMF 150. In addition to standard registration information, the access authentication/NAS signaling message includes service information in a Service Descriptor File (SDF), which carries different service requirements for UE 110. For example, service requirements can pertain to one or more of the following: SLA-specific (Service Level Agreement) requests for ultra-low latency, high bandwidth, a certain packet loss sensitivity/threshold, etc; certain network slices or network slice parameters, whether of existing network slices or network slices that must be newly instantiated; various service functions and/or network functions; and various other service requirements as would be appreciated by one of ordinary skill in the art.

[0028] In the context of the present example, assume that UE 110 transmits an access authentication/NAS signaling message containing an SDF for an ultra-low latency service and a high bandwidth service.

[0029] Step (2): Upon receiving the access authentication/NAS signaling message and extracting service information from the SDF, AMF 150 begins the multi-step process of instantiating bi-directional paths for each of the SLA specific service requests that were received from UE 110, e.g., an ultra- low latency path needs to be instantiated and a high- bandwidth path needs to be instantiated. Accordingly, in step (2) AMF 150 sends the access authentication/NAS signaling message to SMF 160.

[0030] Step (3): Based on the access authentication/NAS signaling message, SMF 160 instructs PCF 170 for policy enforcement. [0031] Step (4): PCF 170 generates a plurality of SLA-specific path instantiation requests corresponding to the service requirement information received from UE 110 in the SDF of the access authentication/NAS signaling message. In the context of the present example, PCF 170 generates an SLA-specific instantiation request for at least an ultra-low latency path and a high-bandwidth path. The SLA-specific path instantiation requests are then transmitted to PCE 180, which is the control plane of 5G core network 140.

[0032] Step (5): For each SLA-specific request that it has received, PCE 180 instantiates an SLA-specific bi-directional path through 5G core network 140 for the given SLA requirement or policy. The instantiated paths satisfy all of the stipulated SLA requirements and policies and provide a communicative link from the second border node 135, through 5G core network 140 and UPFs 144, and to the third border node 145 (which, recall, is the egress point from the 5G core network 140 to an external data network like the Internet). In the context of the present example, PCE 180 instantiates at least an ultra- low latency path between second border node 135 and third border node 145, and a high-bandwidth path between second border node 135 and third border node 145.

[0033] Once a given SLA-specific path has been instantiated, PCE 180 assigns a Core-SLA- Binding SID (Core-SLA-BSID) on the second border node 135 and associates the Core-SLA- BSID with both the segment stack comprising the SLA-specific path through 5G core network 140 and the SLA requirement corresponding to the SLA-specific path.

[0034] Therefore, whenever the second border node 135 interconnecting the backhaul network 130 and the 5G core network 140 receives SRv6 traffic, it will expect the incoming traffic to contain a relevant Core-SLA-BSID as the top segment in its Segment Routing Header (SRH). The second border node 135 can then use this Core-SLA-BSID to identify SLA requirements and policies for the incoming traffic, and then push the relevant segment stack to realize the appropriate SLA-constrained path for the incoming traffic.

[0035] Step (6): PCE 180 transmits back to PCF 170 a listing of the Core-SLA-BSIDs for each of the SLA-specific paths that were instantiated as described above in step (5).

[0036] Step (7): PCF 170 signals SMF 160 and instantiates relevant bi-directional paths through mobile backhaul network 130 for each of the given SLA-specific requests. Just as in step (5), these instantiated paths satisfy all of the stipulated SLA requirements and policies requested by UE 110 and the path provides a communicative link from first border node 125, through MEC 132 and UPFs 134, and to second border node 135.

[0037] Once a given SLA-specific path has been instantiated through mobile backhaul network 130, PCF 170/SMF 160 assigns a Mobile-SLA-BSID on the first border node 125 between RAN 120 and mobile backhaul network 130. This Mobile-SLA-BSID is then associated with both the segment stack comprising the SLA-specific path through mobile backhaul network 130 and the SLA requirement corresponding to the SLA-specific path.

[0038] However, in a departure from step (5), for a given SLA requirement, the corresponding Core-SLA-BSID identifying the segment stack for the given SLA-specific path through 5G core network 140 is included as the last segment in the segment stack that is generated to identify the SLA-specific path through mobile backhaul network 130.

[0039] Accordingly, step (7) generates a segment stack which specifies a composite SLA- specific path through both mobile backhaul network 130 and 5G core network 140, where the segment stack for the path through the mobile backhaul network 130 is identified by the Mobile-SLA-BSID and the segment stack for the path through the 5G core network 140 is identified by the Core-SLA-BSID.

[0040] Step (8): The composite segment stack that has been generated for each SLA requirement/policy (i.e. the segment stack consisting of a Mobile-SLA-BSID and a Core- SLA-BSID plus the intermediate segments) is handed over from SMF 160 to AMF 150.

[0041] Step (9): In some embodiments, the composite segment stack that is received at AMF 150 from SMF 160 can already be in a form that is appropriate for transmission to UE 110, in which case AMF 150 can simply forward the composite segment stack directly to UE 110. In some embodiments, AMF 150 can transform the received composite segment stack into an appropriate form for use by UE 110, e.g., AMF 150 applies a transformation in order to generate the segment routing (SR) listing and the associated flow policy, and subsequently forwards both pieces of information to UE 110 in order for the UE to implement SRv6 and generate Segment Routing Headers to attach to its IPv6 packets.

[0042] Accordingly, UE 110 is able to seamlessly obtain and maintain accurate segment stack/Segment Routing information without any additional burden being experienced by UE 110 itself or any of the other user plane components of the 5G network environment depicted in FIG. 1. UE 110 need only receive the segment stack information periodically forwarded to it by AMF 150 and to then maintain a few policies for each service or SLA requirement that it has requested.

[0043] Advantageously, the use of an overlay mechanism such as SRv6 permits telemetry information to be carried in the Segment Routing Header (SRH) or in some other overlay on a packet transmitted by UE 110. This telemetry information, such as the timestamp mentioned previously, can be extracted at relevant border nodes within the 5G network environment (e.g., such as one or more of the first border nodes 125, second border nodes 135, and third border nodes 145) and analyzed in order to re-instantiate one or more portions of the path/segment stack over a given SLA-constrained path if needed.

[0044] Additionally, the use of end-to-end SRv6 and end-to-end segment stacks spanning from at least first border nodes 125 to third border nodes 145 helps instruct the SLA requirement in an end-to-end fashion at the user plane itself (as opposed to the control plane, as is conventional) via the use of SLA-BSIDs such as the Mobile-SLA-BSIDs and the Core- SLA-BSIDs.

[0045] The disclosure turns now to FIG. 2, which depicts an example diagram and process flow 200 for end-to-end cross-layer control plane collaboration for 5G Software Defined Access (SDA). Three user plane components are provided (indicated with rounded edges, as in FIG. 1): a 5G SDA environment 210; a first Radio Access Network (RAN) 220a; and a second RAN 220b. As shown, 5G SDA environment 210 includes a Multi-access Edge Computing (MEC) edge 212, and at least a first UPF 214 configured as a Serving Gateway (SGW) and a second UPF 216 configured as a Packet Gateway (PGW). As would be appreciated by one of ordinary skill in the art, additional components and UPFs can be provided to the 5G SDA environment 210 in accordance with one or more 5G architectures without departing from the scope of the present disclosure.

[0046] The first RAN 220a is associated with a first control plane AMF/MME 240a, and the second RAN 220b is associated with a second control plane AMF/MME 240b, in accordance with one or more of the aspects described previously with respect to FIG. 1.

[0047] A control plane for the 5G SDA environment 210 is provided as a virtual SDA control plane service 250, which in some embodiments can be instantiated on MEC 212. In some embodiments, vSDA control plane 250 can implement a LISP (Locator/ID Separation Protocol) mapping server or an SRv6 mapping server.

[0048] A first fabric border node 5G-FBN1 272 and a second fabric border node 5G-FBN2 274 are provided, and are connected to first RAN 220a and second RAN 220b, respectively. In some embodiments, one or both of the fabric border nodes can request a 5G network slice specific to SDA.

[0049] The disclosure turns now to the illustrated sequential flow presented in diagram 200. 6 different steps are identified via numerals contained within a circle; dotted lines with arrows indicate the parties involved in each step and the direction of the flow between the involved parties. For purposes of clarity of explanation, steps (l)-(3) depict the registration of 5G- FBN1 272 with vSDA control plane 250, while steps (4)-(6) depict the propagation of SRv6 and/or SRH information to 5G-FBN2 274. However, it is appreciated that either one of the two fabric border nodes 5G-FBN1 272 and 5G-FBN2 274 can perform all of these steps as desired.

[0050] Step ( 1 ): 5G-FBN1 272 registers with vSDA control plane 250. As shown, this registration processed is performed using LIPS Map-register, although it is appreciated that other registration messages can be used according to the protocol or service architecture implemented by vSDA control plane 250.

[0051] Step (2 ): vSDA control plane 250 performs registration for 5G-FBN1 272, and communicates with the control plane AMF/MME 240a associated with RAN 220a of 5G- FBN1 272 in order to thereby instantiate various end-to-end service paths based on the registration request transmitted by 5G-FBN1 272. This path instantiation process for different services is performed much in the same manner as described previously with respect to FIG. 1.

[0052] Step (3): vSDA control plane 250 completes the process of instantiating the end-to- end per-service paths and next programs the details of each path into a local policy & mapping table 280. As illustrated, the policy & mapping table 280 includes entries for EID, Service, Locator, and Segment Stack, although it is appreciated that other column headings and entries are possible without departing from the scope of the present disclosure.

[0053] The mechanics of cross-control plane collaboration (e.g., between vSDA control plane 250 and the control plane AMF/MMEs 240a, b) functions in a similar or same manner as described previously with respect to FIG. 1.

[0054] With a new row entry written into policy & mapping table 280 for each service registered for 5G-FBN1 272, the registration process is complete.

[0055] Step (4): Turning now to focus on 5G-FBN2 274, this second fabric border node transmits a mapping request to vSDA control plane 250. Although not shown, it is appreciated that 5G-FBN2 274 can previously have registered with vSDA control plane 250 as described immediately above with respect to steps (l)-(3). In general, it is contemplated that 5G-FBN2 274 transmits a mapping request for one or more remote end-points within the overall 5G environment.

[0056] Step (5): Upon receipt of the mapping request from 5G-FBN2 274, the vSDA control plane 250 transmits or otherwise performs a corresponding query on policy & mapping table 280.

[0057] Step (6): In response to the mapping query, policy & mapping table 280 returns a relevant SRv6 stack, including segment list or segment stack information corresponding to the remote end-point for which the mapping request was generated in step (4). vSDA control plane 250 then forwards this SRv6 stack back to 5G-FBN2 274, thereby satisfying the mapping request and enabling 5G-FBN2 274 to transmit packets with Segment Routing Headers (SRHs) based on the collaborative network topology/control plane information that has been seamlessly assembled without requiring direct interaction between 5G-FBN2 274 and all of the control plane components of the 5G network environment or the 5G SDA environment.

[0058] In some embodiments, services can be instantiated in MEC 212 and vSDA control plane 250 can be configured to update policy & mapping table 280 with the relevant SLA and/or service- specific stacks that help steer traffic between one or more 5G fabric border nodes (such as 5G-FBN1 272 and 5G-FBN2 274) over a specific path and over one or more of the specific services instantiated in MEC 212.

[0059] FIG. 3 illustrates an example method 300 according to one or more aspects of the present disclosure, and in some embodiments, in addition to the steps depicted can include one or more steps discussed above.

[0060] In a first step 302, one or more SLA-specific service requests are received, most typically from a UE associated with a 5G network. In some embodiments, the SLA-specific service requests can be received as a portion of a registration request and/or access authentication/NAS signaling message transmitted from the UE to the 5G network, or more specifically, transmitted from the UE to an AMF or MME of the 5G network. In some embodiments, at least a portion of the SLA-specific service request information is contained within a Service Descriptor File (SDF) transmitted along with the UE registration request (and/or access authentication/NAS signaling message) to the 5G network. The SDF can specify one or more service requirements for the SLA-specific service requests, e.g. ultra-low latency, high bandwidth, a certain packet loss sensitivity/threshold, etc. In some embodiments, one or more of the SLA-specific service requests can be specific to a particular network slice or set of network slices of the 5G network.

[0061] In some embodiments, one or more control plane functions of the 5G network receive the SLA-specific service requests from the AMF/MME and begin the process of performing path instantiation for each of the SLA-specific service requests. These control plane functions of the 5G network can include an SMF, a PCF, and a PCE, although other control plane functions can be utilized without departing from the scope of the present disclosure.

[0062] In a step 304, for a given SLA-specific service request, a first SRv6 segment stack is generated through the core portion of the 5G network (also referred to herein as the 5G core). This can include causing the PCE to first perform path instantiation through the 5G core, i.e. instantiating paths between an ingress and egress border node of the 5G core, where the path instantiation is performed such that the various components and stipulations of the SLA- specific service request are all satisfied along the path traversing the 5G core.

[0063] In some embodiments, the first SRv6 segment stack is associated with an SLA-BSID, and further, this SLA-BSID can be stored at the ingress border node to the 5G core such that any received traffic having a header containing the same SLA-BSID can automatically be routed along the first SRv6 segment stack.

[0064] In a step 306, for the same given SLA-specific service request, a second SRv6 segment stack is generated through the RAN of the 5G network environment. In some embodiments, the second SRv6 segment stack can be generated through the RAN and the mobile backhaul network of the 5G network environment, or the RAN and mobile backhaul network can be combined into a single entity/component of the 5G network environment. The second SRv6 segment stack is generated by first causing the PCF and/or SMF to perform path instantiation through the RAN, in a similar fashion to the path instantiation performed through the 5G core by the PCE as described above, i.e. between an ingress and egress border node of the RAN and satisfying all requirements of the SLA-specific service request. In some embodiments, the egress border node of the RAN can be the same as the ingress border node of the 5G core, or in other words, the RAN and 5G core are communicatively coupled to one another by this border node.

[0065] In some embodiments, once the second SRv6 segment stack is appropriately generated, the first SLA-BSID corresponding to the first SRv6 segment stack is appended to the end of the second SRv6 segment stack, recalling that the second SRv6 segment stack terminates at the border node connecting the RAN and the 5G core, and further recalling that the first SLA-BSID is stored at this same border node as an identifier of the first SRv6 segment stack.

[0066] In a step 308, a second SLA-BSID is generated and associated with the second SRv6 segment stack. In some embodiments, the second SLA-BSID specifies a composite SLA- specific path through both the RAN/mobile backhaul network and the 5G core, such that it can be utilized by the registering UE from step 302 to generate SRv6 headers for data transmission through the 5G network environment without tunneling. In some embodiments, the second SLA-BSID can be generated via one or more of the PCF and SMF of the control plane of the 5G network environment. In some embodiments, the second SLA-BSID can be assigned at the border node between the RAN and the mobile backhaul network of the 5G network environment, in addition to the first SLA-BSID assigned at the border node between the mobile backhaul network and the 5G core. The process described above can be repeated for every SLA-specific service request that is transmitted by the UE or along with the UE registration request and/or access authentication/NAS signaling message to the 5G network environment. In response, the UE can receive the second SLA-BSID and/or a segment stack for each SLA-specific service request, and can additionally receive, in some embodiments, one or more associated flow policies for SRv6 and/or the specific 5G network environment.

[0067] FIG. 4 depicts an example network device upon which one or more aspects of the present disclosure can be implemented. Although the system shown in FIG. 4 is one specific network device of the present disclosure, it is by no means the only network device architecture on which the concepts herein can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc., can be used. Further, other types of interfaces and media could also be used with the network device 400.

[0068] Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory 406) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc. Memory 406 could also hold various software containers and virtualized execution environments and data.

[0069] The network device 400 can also include an application-specific integrated circuit (ASIC), which can be configured to perform routing, switching, and/or other operations. The ASIC can communicate with other components in the network device 400 via the connection 410, to exchange data and signals and coordinate various types of operations by the network device 400, such as routing, switching, and/or data storage operations, for example.

[0070] FIG. 5 illustrates an example computing system architecture 500 including components in electrical communication with each other using a connection 505, such as a bus, upon which one or more aspects of the present disclosure can be implemented. System 500 includes a processing unit (CPU or processor) 510 and a system connection 505 that couples various system components including the system memory 515, such as read only memory (ROM) 520 and random access memory (RAM) 525, to the processor 510. The system 500 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 510. The system 500 can copy data from the memory 515 and/or the storage device 530 to the cache 512 for quick access by the processor 510. In this way, the cache can provide a performance boost that avoids processor 510 delays while waiting for data. These and other modules can control or be configured to control the processor 510 to perform various actions. Other system memory 515 may be available for use as well. The memory 515 can include multiple different types of memory with different performance characteristics. The processor 510 can include any general purpose processor and a hardware or software service, such as service 1 532, service 2 534, and service 3 536 stored in storage device 530, configured to control the processor 510 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 510 may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0071] To enable user interaction with the computing device 500, an input device 545 can represent any number of input mechanisms, such as a microphone for speech, a touch- sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 535 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device 500. The communications interface 540 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0072] Storage device 530 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 525, read only memory (ROM) 520, and hybrids thereof.

[0073] The storage device 530 can include services 532, 534, 536 for controlling the processor 510. Other hardware or software modules are contemplated. The storage device 530 can be connected to the system connection 505. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer- readable medium in connection with the necessary hardware components, such as the processor 510, connection 505, output device 535, and so forth, to carry out the function. [0074] For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.

[0075] In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0076] Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, Firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0077] Devices implementing methods according to these disclosures can comprise hardware, Firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[0078] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

[0079] Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.