Systems and methods for establishing and modifying user plane communications

Systems described herein provide techniques for establishing and modifying user plane communications sessions between Long-Term Evolution (“LTE”) User Equipment (“UE”) devices, connected to LTE base stations, and a Fifth Generation (“5G”) core network. An LTE-5G Interworking function (“LTE-5G IWF”) may logically generate a virtual 5G UE and/or 5G base station, map a LTE UE to the virtual 5G UE, and cause the establishment of a Protocol Data Unit (“PDU”) Session, at the 5G core network, with the virtual 5G UE. The LTE-5G IWF may provide PDU Session information to the LTE UE and base station to facilitate the establishment of user plane communications (e.g., via a tunnel) between the LTE UE and the 5G core network. The LTE-5G IWF may also receive modification parameters, such as Quality of Service (“QoS”) parameters, and provide instructions to the 5G core and/or to the LTE UE to handle traffic according to such parameters.

BACKGROUND

Wireless networks utilize different types of radio access networks (“RANs”) and/or core networks. Fifth Generation (“5G”) RANs may offer relatively low latency and/or high throughput services, but may not be as widely deployed as Long-Term Evolution (“LTE”) RANs, which may be available or already installed in areas that do not have 5G coverage.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments described herein provide for the establishment and modification of connections (e.g., user plane sessions) between User Equipment (“UE”) communicating via a LTE radio access technology (“RAT”) and a 5G core network. As discussed herein, a LTE-to-5G Interworking Function (“LTE-5G IWF”) may be communicatively coupled to one or more devices or systems associated with an LTE network (e.g., one or more LTE base stations, which may take the form of evolved Node Bs (“eNBs”) and/or one or more Mobility Management Entities (“MMEs”)) and to one or more devices or systems associated with a 5G network (e.g., an Access and Mobility Function (“AMF”)).

As described herein, the LTE-5G IWF may receive information regarding a LTE UE that has connected to a particular eNB (e.g., using an LTE RAT), and may simulate control plane signaling associated with establishing communications between the UE and an LTE core network. Further, the LTE-5G IWF may simulate, based on the eNB and the LTE UE, a 5G base station (e.g., a Next Generation Node B (“gNB”)) and a 5G UE. As discussed herein, the simulated gNB and 5G UE may be referred to as a “virtual” gNB and a “virtual” 5G UE, or as a “vgNB” and a “vUE,” respectively. The LTE-5G IWF may communicate control signaling with an AMF of a 5G core network to simulate the establishment of communications between the 5G core network and the vUE (e.g., as if the vUE were connected to the vgNB). By virtue of performing these control signaling processes with elements of the LTE network and the 5G network, each of these networks may maintain a context associated with a UE. That is, the LTE network may maintain context information associated with the LTE UE, and the 5G network may maintain context information associated with the vUE. As described herein, these “dual” contexts (i.e., as maintained by the LTE and 5G networks, respectively) may further be used to establish and/or modify one or more user plane data sessions between the LTE UE and a User Plane Function (“UPF”) of the 5G network.

FIG. 1provides an overview of some of the concepts discussed above. As shown inFIG. 1, for example, LTE core network101may receive (at102) an Attach Request. For the sake of simplicity, the Attach Request is shown in this figure as originating from LTE UE107. In practice, the Attach Request may be received from eNB103, which may output the Attach Request based on a Radio Resource Configuration (“RRC”) connection procedure performed between UE101and eNB103. That is, once a radio frequency (“RF”) connection has been established between UE101and eNB103, eNB103may output the Attach Request, associated with UE101, to one or more elements of LTE core101. The Attach Request may be sent via an S1-C interface between eNB103and an MME of LTE core101.

As shown inFIG. 1, LTE core101may include, and/or may be communicatively coupled to, LTE-5G IWF105. For example, LTE-5G IWF105may be communicatively coupled with an MME of LTE core101(e.g., a particular MME that received the Attach Request from eNB103), and may receive the Attach Request from the MME. Additionally, or alternatively, a first MME of LTE core101may receive the Attach Request, determine that LTE UE107and/or the Attach Request should be forwarded to a second MME and/or to LTE-5G IWF105, and may accordingly forward the Attach Request to the second MME and/or to LTE-5G IWF105.

The Attach Request may include information identifying LTE UE107. Generally, the identifying information received in the Attach Request may include identifying information used by LTE networks to establish communications between LTE UEs and LTE RANs and/or a LTE core network. The identifying information received in the Attach Request may include, in some embodiments, International Mobile Subscriber Identity (“IMSI”), International Mobile Station Equipment Identity (“IMEI”), Globally Unique Temporary Identifier (“GUTI”), and/or identifying information of LTE UE107. In some embodiments, the Attach Request may include one or more Packet Data Network (“PDN”) identifiers, which may indicate a type of service or application that LTE UE107is requesting (e.g., voice, data, etc.).

Once LTE-5G IWF105receives the Attach Request, LTE-5G IWF105may generate a 5G context, for subsequent use by 5G core network109, associated with LTE UE107. For example, LTE-5G IWF105may map a first set of identifiers associated with LTE UE107(e.g., IMSI, IMEI, GUTI, PDN identifier, and/or one or more other identifiers) to a second set of identifiers. As discussed above, this first set of identifiers may have been received via the Attach Request, and may be associated with operations related to LTE networks. The second set of identifiers may be generated by LTE-5G IWF105and/or selected from a pool of available identifiers, and may be associated with operations related to 5G networks. The second set of identifiers may include, for example, a Subscription Concealed Identifier (“SUCI”), a Subscription Permanent Identifier (“SUPI”), a Permanent Equipment Identifier (“PEI”), Access Point Name (“APN”), and/or another identifier. In some embodiments, the second set of identifiers may include one or more cell or base stations identifiers associated with 5G networks, such as a New Radio (“NR”) Cell Identity (“NCI”), NR Cell Global Identity (“NCGI”), and/or some other identifier associated with base stations (e.g., gNBs) associated with a 5G RAN.

In some embodiments, the second set of identifiers may be generated based on the first set of identifiers. For example, LTE-5G IWF105may generate one or more of the second set of identifiers by performing a hash or some other function based on one or more of the first set of identifiers. In some embodiments, the second set of identifiers may be generated or selected independent of the values of the first set of identifiers.

As mentioned above, the mapped identifiers (e.g., the second set of identifiers) may be associated with a “virtual” UE and gNB, conceptually shown inFIG. 1as 5G vUE111and vgNB113, and may be used to simulate the attachment of vUE111to 5G core network109via vgNB113. LTE-5G IWF105may thus maintain a “dual context” associated with LTE UE107. A first context may include information (such as the first set of identifiers) used to establish, maintain, modify, etc. communications between LTE UE107and LTE core network101, and the second context may include information (such as the second set of identifiers) used to establish, maintain, modify, etc. communications between 5G vUE111and 5G core network109. As described herein, these dual contexts may be used by LTE-5G IWF105to facilitate communications between LTE UE107and 5G core network109.

For example, as described in greater detail below, LTE-5G IWF105may use one of these contexts (e.g., including the second set of identifiers) to simulate (at106) the attachment of vUE111to 5G core network109. The attachment procedure may be performed, for example, by way of communications between LTE-5G IWF105and an AMF of LTE-5G IWF105. Thus, while conceptualized in the figure as being “performed by” 5G vUE111through vgNB113, the actual signaling to simulate the attachment of 5G vUE111to 5G core network109may be performed by LTE-5G IWF105.

For instance, as shown inFIG. 2A, LTE-5G IWF105and/or MME201(which may be associated with LTE core network101) may communicate with AMF203(which may be associated with 5G core network109) via an N26 interface. In some embodiments, LTE-5G IWF105may communicate with AMF203“directly” via the N26 interface. In some embodiments, LTE-5G IWF105may “indirectly” communicate with AMF203via the N26 interface by communicating with MME201, which may in turn communicate with AMF203via the N26 interface. Similarly, AMF203may communicate with LTE-5G IWF105“directly” via the N26 interface, and/or “indirectly” by communicating messages, intended for LTE-5G IWF105, to MME201. For brevity, communications will be described herein as though LTE-5G IWF105and AMF203are “directly” connected via the N26 interface. In practice, such communications may be provided “indirectly” in a manner similar to that outlined above.

Via the interface between LTE-5G IWF105and AMF203, “virtual” N1 and N2 interfaces (shown in the figure as “vN1” and “vN2”) may be provided. For example, LTE-5G IWF105and AMF203may communicate, via N26 messages (e.g., in N26 “containers”), N1 and/or N2 messages (e.g., messages in N1 and/or N2 containers). That is, a “vN1” message may be passed by LTE-5G IWF105to AMF203(or vice versa) by providing the message in an N1 container that is contained within an N26 container. Similarly, a “vN2” message may be passed by LTE-5G IWF105to AMF203(or vice versa) by providing the message in an N2 container that is contained within an N26 container.

As shown inFIG. 2B, for example, the vN1 interface may be used to simulate messages between vUE111and AMF203, and the vN2 interface may be used to simulate messages between vgNB113and AMF203. Thus, a message sent by LTE-5G IWF105via the vN1 interface (e.g., in an N1 container) may be interpreted by AMF203as having been sent by vUE111, while a message sent by LTE-5G IWF105via the vN2 interface (e.g., in an N2 container) may be interpreted by AMF203as having been sent by gNB113.

Returning toFIG. 1, once the attachment of 5G vUE111to 5G core network109has been simulated, LTE-5G IWF105may perform (at110) a user plane bearer establishment procedure. A more detailed example of this procedure is provided below. Briefly, this procedure may include establishing one or more bearers, sessions, tunnels (e.g., a General Packet Radio Service (“GPRS”) Tunneling Protocol (“GTP”) tunnel), etc. between eNB103and one or more devices or systems (e.g., a UPF) associated with 5G core network109. Once established, eNB103and 5G core network109(e.g., a UPF of 5G core network109) may be configured to communicate (at112) user plane traffic, such as voice traffic, data traffic, etc., with each other. Further, by virtue of its attachment to eNB103, LTE UE107may now be considered to be communicatively coupled to 5G core network109, and may communicate with 5G core network109without using any different signaling than when LTE UE107is communicatively coupled to LTE core network101.

As referred to above,FIG. 3illustrates example signaling, involving LTE-5G IWF105, to establish communications between LTE UE107and a 5G core network109, in accordance with some embodiments. As shown, LTE UE107and eNB103may perform (at302) an RRC Connection Setup procedure. By way of this procedure, LTE UE107and eNB103may establish an RF connection, via which LTE UE107and eNB103may communicate wirelessly. As part of this procedure, eNB103may receive or determine one or more identifiers associated with LTE UE107, such as IMSI, IMEI, GUTI, and/or some other suitable identifier of LTE UE107. Further, as part of this procedure, eNB103may also identify one or more types of services or networks to which UE107is authorized to access, which may be indicated by one or more APNs. For example, one or more messages sent from UE107to eNB103as part of this procedure may indicate the one or more APNs. In some embodiments, different APNs may be associated with different services (e.g., one APN may be associated with voice call services, another APN may be associated with data services, etc.).

Once the RF connection between LTE UE107and eNB103has been established, eNB103may output (at304) an Attach Request to MME201. The Attach Request may be provided via an S1 interface (e.g., an S1-C interface) between eNB103and MME201. The Attach Request may include one or more of the identifiers associated with LTE UE107.

MME201may, in some embodiments, be an MME that is associated with a tracking area (“TA”) with which LTE UE107and/or eNB103is associated. In some embodiments, MME201may be communicatively coupled with LTE-5G IWF105. MME201may output (at306) an Attach Request to LTE-5G IWF105. In some embodiments, this Attach Request (output at306) may include the Attach Request provided by eNB103, and/or may otherwise be based on the Attach Request provided by eNB103. For example, the Attach Request (output at306) may include identifying information for LTE UE107.

In some embodiments, MME201may pass through (at306) the Attach Request (received at304) without modifying the Attach Request. In some embodiments, an interface (e.g., an S1-C interface) may be provided directly between eNB103and LTE-5G IWF105, and eNB103may output the Attach Request to LTE-5G IWF105directly (e.g., without outputting the Attach Request to MME201) via the provided interface.

LTE-5G IWF105may map (at308) LTE UE107to a virtual UE (e.g., 5G vUE111). For example, as similarly discussed above, LTE-5G IWF105may generate a set of identifiers associated with 5G vUE111, and maintain information indicating that this set of identifiers is associated with LTE UE107. This set of identifiers may include, for example, SUCI, SUPI, PEI, and/or some other identifier that may be used by AMF203and/or other elements of 5G core network109to identify or communicate with 5G vUE111. In some embodiments, LTE-5G IWF105may generate these identifiers by performing a hash or some other function on one or more identifiers of LTE UE107(e.g., IMSI, IMEI, etc.). In some embodiments, LTE-5G IWF105may generate these identifiers in a manner independent of the identifiers of LTE UE107(e.g., using random and/or arbitrary identifiers). In some embodiments, LTE-5G IWF105may select these identifiers from a pool of available identifiers, and remove any identifiers from this pool when selecting them for 5G vUE111(e.g., mapping the selected identifiers to LTE UE107).

In some embodiments, LTE-5G IWF105may also associate 5G vUE111with vgNB113. That is, from the standpoint of 5G core network109, 5G vUE111may be a wireless 5G UE that is wirelessly connected to vgNB113. In actuality, and from the standpoint of LTE-5G IWF105, 5G vUE111and vgNB113may be virtual devices with a logical association. LTE-5G IWF105may store or maintain this mapping for subsequent communications described herein.

LTE-5G IWF105may proceed to establish logical communications between AMF203and 5G vUE111. For example, LTE-5G IWF105may output (at310), via an N1 interface (e.g., a vN1 interface) between LTE-5G IWF105and AMF203, an Initial UE Message. The Initial UE Message may include one or more of the identifiers for 5G vUE111generated or selected by LTE-5G IWF105(e.g., SUPI, SUCI, PEI, etc.). In some embodiments, the Initial UE Message may include one or more Protocol Data Unit (“PDU”) Session IDs, which may be used to establish a PDU Session between 5G vUE111and UPF305, and/or AMF203may determine or generate one or more PDU Session IDs based on the Initial UE Message.

As described above, the N1 interface may be provided via a “virtual” N1 interface (e.g., “vN1”) between LTE-5G IWF105and AMF203. For example, LTE-5G IWF105may send the Initial UE Message to AMF203in an N1 container, via an N26 interface between LTE-5G IWF105and AMF203. In some embodiments, although not explicitly shown here, LTE-5G IWF105may instruct MME201to send the Initial UE Message to AMF203via an N26 interface between MME201and AMF203. For example, LTE-5G IWF105may provide the Initial UE Message to MME201in an N1 container, along with an instruction to provide the N1 container to AMF203via the N26 interface. Upon receiving the Initial UE Message, AMF203may perform (at312) a PDU Session creation process, which may include communicating with one or more other elements of 5G core network109, such as Session Management Function (“SMF”)303and/or UPF305.

The PDU Session creation process may include the generation or selection of a Core Network (“CN”) Tunnel identifier (“CN Tunnel ID”), as well as the generation or selection of an IP address for 5G vUE111. As described herein, this IP address may ultimately be used by UPF305and LTE UE107to establish user plane communications between UPF305and LTE UE107. As part of the PDU Session creation process (at310), the IP address may be generated or selected by SMF303and/or by UPF305. The IP address may include an IPv4 address, an IPv6 address, and/or a portion of an IPv6 address (e.g., an IPv6 prefix). As part of this PDU Session creation process, the generated CN Tunnel ID and IP address may be provided to AMF203(e.g., by SMF303via an N11 interface, and/or by UPF305via an N4 interface).

Once the PDU Session creation process is complete, AMF203may output (at314) one or more Registration Accept messages to LTE-5G IWF105. The Registration Accept messages may be provided in an N1 container and an N2 container (e.g., via the “virtual” N1 and N2, or “vN1” and “vN2,” interfaces between AMF203and LTE-5G IWF105). The Registration Accept messages may include information received by AMF203as part of the PDU Session creation process (at310). Generally, the message sent via the vN1 interface may serve to logically associate 5G vUE111with the PDU Session, and the message sent via the vN2 interface may serve to logically associate vgNB113with the PDU Session.

For example, the Registration Accept message (sent at314via the vN1 interface, also referred to as the “vN1 Registration Accept message”) may include the CN Tunnel ID and the IP address associated with 5G vUE111. In some embodiments, the vN1 Registration Accept message may include other information, such as Quality of Service (“QoS”) information associated with the PDU Session, Data Network Name (“DNN”) determined based on PDN identifier included in the Attach Request, and/or other parameters associated with PDU Session establishment.

In some embodiments, the Registration Accept message (sent at314via the vN2 interface, also referred to as the “vN2 Registration Accept message”) may include the CN Tunnel ID. In some embodiments, the vN2 Registration Accept message may include a slice identifier of a 5G network slice associated with AMF203, SMF303, and/or UPF305(e.g., Single—Network Slice Selection Assistance Information (“S-NSSAI”)). In some embodiments, the vN2 Registration Accept message may include QoS-related information, such as QoS Flow Identifier (“QFI”) and/or one or more QoS profiles associated with the PDU Session.

Thus, from the standpoint of 5G core network109, a PDU Session has been established between UPF305and 5G vUE111, via vgNB113. That is, UPF305may maintain information indicating that the PDU Session, having the PDU Session ID, is associated with the IP address associated with 5G vUE111. As discussed herein, this IP address and PDU Session ID may subsequently be used (e.g., by LTE-5G IWF105) to establish communications between UPF305and LTE UE107.

Once LTE-5G IWF105receives the vN1 and vN2 Registration Accept messages, LTE-5G IWF105may generate (at316) an Attach Accept message based on the information included in the vN1 and vN2 Registration Accept messages. The generated Attach Accept message may be in a format utilized by elements of LTE core network101(e.g., MME201) and/or an LTE RAN (e.g., eNB103). In order to generate the Attach Accept message, LTE-5G IWF105may map one or more of the parameters indicated in the vN1 and/or vN2 Registration Accept messages to one or more parameters that may be utilized by MME201, eNB103, and/or LTE UE107to establish the PDU Session. In some embodiments, LTE-5G IWF105may store information indicating 5G parameters (e.g., as received in the vN1 and vN2 Registration Accept messages) to LTE parameters (e.g., to include in the Attach Accept message).

For example, LTE-5G IWF105may map the QoS information indicated in the vN1 and/or vN2 Registration Accept messages (e.g., QFI, QoS profiles, S-NSSAI, etc.) to QoS information utilized by MME201, eNB103, and/or LTE UE107, such as QoS Class Identifier (“QCI”), Traffic Flow Template (“TFT”), and/or other QoS-related parameters. In some embodiments, the Attach Accept message may include some of the information included in the vN1 and/or vN2 Registration Accept messages, such as the CN Tunnel ID. In some embodiments, this information may be placed in a different field in the Attach Accept message and/or may be denoted as a different information element (“IE”). For example, the CN Tunnel ID may be represented in the Attach Accept message as a Tunnel Endpoint Identifier (“TEID”), and/or the PDU Session ID may be represented in the Attach Accept Message as an Evolved Packet System (“EPS”) Bearer ID. The Attach Accept message may include the IP address generated or selected as part of the PDU Session creation process (at312). As discussed below, this IP address may be assigned to LTE UE107, to facilitate communications between LTE UE107and UPF305.

LTE-5G IWF105may provide (at318) the Attach Accept message to MME201, which may output (at320) the Attach Accept message to eNB103. For example, MME201may output the Attach Accept message to eNB103via the S1 interface (e.g., via the S1-C interface). In some embodiments, as similarly described above, LTE-5G IWF105may provide the Attach Accept message “directly” to eNB103(e.g., via an S1-C interface), without providing the Attach Accept message to MME201. Based on the information received in the Attach Accept message (at320), eNB103may establish communications (e.g., an EPS bearer such as a “default” bearer, a PDU Session, etc.) with UPF305. In some embodiments, the communications between eNB103and UPF305may be, may include, and/or may be carried via a GTP tunnel. For example, eNB103may use the CN Tunnel ID and/or the TEID associated with UPF305to communicate with UPF305. Further, eNB103may provide information to LTE UE107regarding the established communications, including the IP address assigned to LTE UE107.

The established communications (e.g., GTP tunnel carrying a PDU Session, EPS Bearer, etc.) between eNB103and UPF305may enable LTE UE107to communicate user plane traffic with UPF305. For example, LTE UE107may output (e.g., in the “uplink” direction) user plane traffic, such as voice traffic, data traffic, or the like. eNB103may proceed to forward (at322) the traffic to UPF305via the established communications between eNB103and UPF305. For example, eNB103may use the TED, EPS Bearer ID, IP address, etc. when forwarding the user plane traffic. One or more routing components that are communicatively coupled to eNB103(e.g., a Serving Gateway (“SGW”)) may forward the user plane traffic to UPF305using the TED, EPS Bearer ID, IP address, etc. UPF305may forward the traffic to its destination via an external Data Network (“DN”), such as the Internet.

In this manner, while LTE UE107maintains an RF connection with eNB103of an LTE RAN, the traffic may be handled by 5G core network109instead of by LTE core network101. Handling the traffic by 5G core network109may aid in the transition of the utilization of 5G technologies as they become more prevalent. Additionally, 5G core network109may be capable of providing additional or enhanced services, as compared to LTE core network101. Further, leveraging the continued use of currently deployed LTE architecture (e.g., existing LTE RANs) in conjunction with elements of a 5G core network may facilitate the more rapid deployment of 5G technologies without requiring the decommissioning, removal, or non-utilization of existing LTE architecture.

FIG. 4illustrates example signaling to modify an existing communications session between LTE UE107and a 5G core network109, in accordance with some embodiments. The signaling shown in this figure may be used to modify an existing communications session (e.g., PDU Session) and/or to establish a new PDU Session between LTE UE107and 5G core network109. In some embodiments, the signaling shown inFIG. 4may occur in conjunction with, or after, the signaling shown inFIG. 3. For instance, the signaling shown inFIG. 4may be used to change QoS parameters associated with an existing PDU Session, and/or to establish additional PDU Sessions according to particular QoS parameters.

As shown, for example, eNB103may output (at402) a Service Request message to MIME201. This message may be outputted via an S1 interface (e.g., an S1-C interface). eNB103may output the Service Request message based on uplink traffic received from LTE UE107. The uplink traffic may include user plane traffic, such as voice call traffic (e.g., Voice over LTE (“VoLTE”) traffic), data traffic, and/or other user plane traffic. The Service Request message may include a PDU Session ID and/or one or more other identifiers (e.g., as indicated in the Attach Accept message received at320, shown inFIG. 3) of the PDU Session, GTP tunnel, and/or other established communication between eNB103and UPF305.

MME201may forward and/or otherwise output (at404) the Service Request message to LTE-5G IWF105. As similarly described above, in some embodiments, eNB103may “directly” provide the Service Request message to LTE-5G IWF105(e.g., without providing the message to MME201). LTE-5G IWF105may identify, based on the Service Request message, stored context information for UE107(e.g., context information in accordance with the above description ofFIG. 3). For example, LTE-5G IWF105may identify one or more TFTs associated with the Service Request and/or UE107, a QCI associated with the Service Request and/or with UE107, one or more APNs associated with UE107and/or the Service Request, and/or other context information associated with UE107. While not explicitly shown here, MME201and/or LTE-5G IWF105may perform a verification and/or authentication process (e.g., by communicating with an Home Subscriber Server (“HSS”) and/or one or more other elements of LTE core network101) to verify that UE107is authorized to access the requested service, and/or is authorized to access the requested service with a given QoS level (e.g., QCI).

LTE-5G IWF105may map (at406) a first set of parameters, associated with the Service Request, to a second set of parameters. Generally speaking, the first set of parameters may be parameters utilized by elements of LTE core network101(and may be referred to as “LTE parameters”), while the second set of parameters may be parameters utilized by elements of 5G core network109(and may be referred to as “5G parameters”). For example, LTE-5G IWF105may identify a QFI, Service Data Flow (“SDF”), and/or other QoS-related 5G parameters that correspond to a QCI, TFT, and/or other QoS-related LTE parameters indicated by the Service Request. For example, LTE-5G IWF105may receive and/or maintain mapping information that may be used to determine the appropriate 5G parameters that correspond to the LTE parameters.

LTE-5G IWF105may output (at408) a Service Request message to AMF203. This Service Request message may be provided in an N2 container, via an N26 interface between LTE-5G IWF105and AMF203. Thus, this Service Request message may be considered as being provided between the vN2 interface between LTE-5G IWF105and AMF203, as similarly discussed above. By virtue of being provided via the vN2 interface, from the standpoint of AMF203, AMF203may determine that the Service Request message was received from vgNB113.

While described herein in the context of a PDU Session modification performed based on a Service Request message (e.g., as received from eNB103and/or from LTE UE107), in practice, the PDU Session modification may be triggered by a message or notification from another device or system (e.g., in lieu of eNB103or LTE UE107). For example, AMF203may initiate the PDU Session modification (e.g., based on information received from Unified Data Management function (“UDM”) of 5G core network109), and/or some other device or system may initiate the PDU Session modification (e.g., Policy Control Function (“PCF”) of 5G core network109, an Application Function (“AF”) of 5G core network109, and/or some other device or system).

AMF203may utilize the PDU Session ID, included in the Service Request message, to identify UPF305and to perform (at410) a PDU Session modification procedure. While the PDU Session modification procedure is shown in the figure as a single line, in practice, this procedure may include multiple signals or messages communicated between AMF203, SMF303, UPF305, and/or one or more other elements of 5G core network109. For the sake of brevity, these multiple signals or messages are not reproduced or discussed here. The PDU Session modification procedure may include indicating, to UPF305, the 5G QoS-related parameters (e.g., as determined by LTE-5G IWF105at406) indicated in the Service Request message.

The PDU Session modification procedure may include modifying an existing PDU Session (e.g., as established at312inFIG. 3) in accordance with the 5G QoS-related parameters. For example, UPF305and/or AMF203may maintain information associating the PDU Session with the 5G QoS-related parameters, such that UPF305and/or one or more other elements of 5G core network109may process the traffic in accordance with these parameters. For example, the QoS-related parameters may be used to queue, process, prioritize, etc. traffic in a differentiated manner compared to traffic associated with different QoS-related parameters. In some embodiments, in addition to, or in lieu of, the modification (at410) of an existing PDU Session, AMF203and UPF305may establish a new PDU Session based on the 5G QoS-related parameters. The establishment of a new PDU Session, in such situations, may thus also be represented by dashed arrow410inFIG. 4.

Once the PDU Session has been modified or created (at410), AMF203may output (at412) a Service Request Acknowledgement (“Ack”) message to LTE-5G IWF105. This message may be provided, for example, via the vN2 interface between AMF203and LTE-5G IWF105. Thus, from the standpoint of AMF203, AMF203may provide the Service Request Ack message to vgNB113. The Service Request Ack message may indicate that the PDU Session has been modified in accordance with the Service Request message (provided at408). Among other information, the Service Request Ack message may include the PDU Session ID of the PDU Session that was modified. The Service Request Ack message may indicate the 5G QoS-related parameters based on which the PDU Session was modified. LTE-5G IWF105may verify that these parameters match the parameters that were mapped (at406) by LTE-5G IWF105to LTE QoS-related parameters. In the event that the PDU Session modification was initiated by an element of 5G core network109, LTE-5G IWF105may use the QoS information in the Service Request Ack message to generate a mapped set of LTE QoS-related parameters that correspond to the 5G QoS-related parameters indicated in the Service Request Ack message.

LTE-5G IWF105may output (at414) an indication to MME201that the Service Request Ack message was received (at412) from AMF203. The Service Request Ack message (output at414) may include some or all of the information included in the Service Request Ack message (output at412), such as the PDU Session ID of the PDU Session that was modified. Based on receiving the indication that the PDU Session has been modified (e.g., in accordance with the Service Request message received at402), MME201may output (at416) a Bearer Setup Request to eNB103via an S1-C interface. The Bearer Setup Request may include QoS-related parameters, which may be used by eNB103to process, prioritize, etc. traffic associated with the PDU Session. For example, the Bearer Setup Request may include or indicate a TFT, a QCI, etc.

Further, as shown, eNB103and LTE UE107may perform (at418) an RRC reconfiguration procedure based on the received QoS-related parameters. For example, via one or more RRC messages, eNB103may indicate the QoS-related parameters (e.g., TFT, QCI, etc.) to LTE UE107, which may utilize such parameters when communicating (at420) with UPF305.

Based on the above example process, UE107, eNB103, and UPF305may process user plane traffic according to corresponding QoS parameters. For example, as noted above, LTE UE107and eNB103may process the traffic according to a set of LTE QoS-related parameters (e.g., as indicated in or determined based on the Service Request message output at402), while UPF305may process the traffic according to a corresponding set of 5G QoS-related parameters. For example, as discussed above, the corresponding set of 5G QoS-related parameters may have been determined or mapped (at406) by LTE-5G IWF105, based on the set of LTE QoS-related parameters. By virtue of processing the traffic according to the same (or corresponding) QoS parameters across both LTE and 5G networks (e.g., an LTE RAN as implemented by eNB103and elements of 5G core network109, such as UPF305), embodiments described herein may allow for the interworking between these two types of networks in a manner that does not alter or modify QoS parameters. Accordingly, QoS parameters, which may be associated with particular subscriber types, traffic types, UE device types, etc. may be maintained in situations where 5G core network109is used to handle user plane traffic that is carried over an LTE RAN, thus preserving or enhancing the user experience of users associated with such traffic.

FIG. 5illustrates an example process500for establishing user plane communications between LTE UE107and 5G core network109, in accordance with some embodiments. In some embodiments, some or all of process500may be performed by LTE-5G IWF105. In some embodiments, one or more other devices may perform some or all of process500(e.g., in concert with, and/or in lieu of, LTE-5G IWF105).

As shown, process500may include receiving (at502) an Attach Request via an S1-C interface. For example, the Attach Request may have been received from eNB103, to which a particular LTE UE107is connected. As mentioned above, the Attach Request may be received “directly” by LTE-5G IWF105from eNB103, and/or may be received “indirectly.” For example, MME201may have received the Attach Request via an S1-C interface between MME201and eNB103, and may forward some or all of the Attach Request to LTE-5G IWF105.

Process500may further include identifying (at504) one or more LTE UE identifiers associated with the Attach Request. For example, the Attach Request may include one or more identifiers of LTE UE107. The identifiers may be LTE identifiers, in that these identifiers may be used by elements of LTE networks to identify LTE UE107. Such identifiers may include, for instance, IMSI, IMEI, GUTI, and/or other identifiers of LTE UE107.

Process500may additionally include mapping (at506) the LTE UE identifiers to one or more 5G UE identifiers. For example, LTE-5G IWF105may logically associate LTE UE107with 5G vUE111by mapping a set of LTE UE identifiers (e.g., IMSI, IMEI, GUTI, etc.), associated with LTE UE107, to a set of 5G UE identifiers (e.g., SUCI, SUPI, PEI, etc.) associated with 5G vUE111. As mentioned above, the 5G UE identifiers may be generated based on the LTE UE identifiers, and/or the 5G UE identifiers may be generated or selected in a manner that is independent of the LTE UE identifiers. In some embodiments, when mapping LTE UE107to 5G vUE111, LTE-5G IWF105may also generate a logical association between LTE UE107and vgNB113. More specifically, LTE-5G IWF105may generate or maintain identifying information for vgNB113, as well as a logical indication that 5G vUE111is communicatively coupled to vgNB113.

Process500may also include outputting (at508) an Initial UE Message via a vN1 interface. For example, as described above, the Initial UE Message may be provided via an N26 interface (e.g., between LTE-5G IWF105and AMF203, and/or between MME201and AMF203) in an N1 container. The Initial UE Message may include the mapped 5G UE identifiers (mapped at506). Thus, by virtue of being received via an N1 container, AMF203may interpret this message as having been received from 5G vUE111, with which the 5G UE identifiers are associated.

Process500may further include receiving (at510) one or more Registration Accept messages (e.g., via vN1 and vN2 interfaces), including PDU Session information. For example, LTE-5G IWF105may receive, via the N26 interface and in N1 and/or N2 containers, one or more Registration Accept messages from AMF203. The Registration Accept messages may include information identifying one or more PDU Sessions that have been created based on the Initial UE Message. For example, as discussed above with respect toFIG. 3, AMF203, SMF303, and/or UPF305may participate in a PDU Session creation procedure, in which a PDU Session is created at UPF305. In some embodiments, the Registration Accept messages may include QoS-related information for the PDU Session, which may include QFI, SDF, and/or other QoS-related 5G parameters.

As part of the PDU Session creation process, an IP address may be created for 5G vUE111(e.g., by SMF303and/or by UPF305). The IP address may include an IPv4 address or an IPv6 prefix. Further, a CN Tunnel ID may be generated (e.g., by SMF303and/or by UPF305) to represent a GTP tunnel, for which UPF305is one endpoint. As referred to above, the other endpoint for the GTP tunnel may ultimately be LTE UE107, such that LTE UE107and UPF305may communicate over the GTP tunnel. From the standpoint of UPF305, the GTP tunnel may be used to carry a PDU Session. From the standpoint of LTE UE107and eNB103, as discussed herein, the GTP tunnel may be used to carry an EPS bearer.

Process500may additionally include outputting (at512) an Attach Accept message via an S1-C interface. The Attach Accept message may include information associated with the PDU Session, such as a PDU Session Identifier (“ID”). The Attach Accept message may include tunnel information for a GTP tunnel that carries the PDU Session, such as a CN Tunnel ID. In some embodiments, the Attach Accept message may include QoS-related information, which may be determined by LTE-5G IWF105based on QoS-related information included in the Registration Accept message(s) (received at510). In some embodiments, LTE-5G IWF105may perform a mapping operation to identify QoS-related LTE parameters that are associated with QoS-related 5G parameters included in the Registration Accept message(s), and may include these in the Attach Accept message. Further, LTE-5G IWF105may map the CN Tunnel ID to a TEID, and/or may map the PDU Session ID to an EPS Bearer ID, and may include the TEID and PDU Session ID in the Attach Accept message. LTE-5G IWF105may provide the Attach Accept message to eNB103, and/or may instruct MME201to provide the Attach Accept message to eNB103via an S1-C interface.

Based on receiving the Attach Accept message, eNB103may correlate LTE UE107to the established PDU Session and/or GTP Tunnel, and user plane communications between LTE UE107and UPF305may thus be established (at514). For example, eNB103may maintain information correlating the IP address of LTE UE107(at included in the Attach Accept message) to the TEID and/or to the EPS Bearer ID. Thus, when receiving uplink traffic from LTE UE107, eNB103may forward the uplink traffic, via the GTP Tunnel, to UPF305. Further, when receiving downlink traffic from UPF305via the GTP Tunnel, eNB103may identify the IMSI, IMEI, etc. of LTE UE107based on the IP address indicated in the downlink traffic, and may provide the downlink traffic to LTE UE107. Further, in situations where the Attach Accept message includes QoS-related parameters (e.g., QCI, one or more TFTs, etc.), eNB103and/or LTE UE107may utilize this information to implement the appropriate QoS treatment of traffic transmitted through the established user plane communications. In situations where the Attach Accept message does not include QoS-related parameters, eNB103and/or LTE UE107may treat the established communications as a “Default” EPS Bearer.

FIG. 6illustrates an example process600for a UE-initiated session modification. In some embodiments, some or all of process600may be performed by LTE-5G IWF105. In some embodiments, one or more other devices may perform some or all of process600(e.g., in concert with, and/or in lieu of, LTE-5G IWF105).

As shown, process600may include receiving (at602) a Service Request message via an S1-C interface. For example, LTE-5G IWF105may receive the Service Request message from eNB103and/or from MME201, which may have received the Service Request message from LTE-5G IWF105. The Service Request message may generally be related to a request for a particular type of service or application, such as a voice call service, a data service, etc. The requested type of service may be associated with, and/or the Service Request message may specify, one or more QoS-related LTE parameters, such as a QCI. The Service Request may also include an EPS Bearer ID and/or TEID, to indicate the communications that are to be modified. The request may, in some embodiments, have originated from LTE UE107.

Process600may further include identifying (at604) a set of QoS-related LTE parameters associated with the Service Request message. For example, as mentioned above, the Service Request message may indicate a QCI and/or other parameter related to QoS. Additionally, or alternatively, LTE-5G IWF105may determine QCI (or other QoS-related parameter) based on information specified in the Service Request message. For example, the Service Request message may specify a type of service. LTE-5G IWF105may identify a QCI associated with the specified type of service based on communicating with an HSS and/or some other device or system that indicates QoS parameters associated with types of services. Additionally, or alternatively, different UEs may be associated with different QoS levels for the same type of traffic. In such situations, LTE-5G IWF105may determine the QCI based on an identifier associated with LTE UE107, and/or based on the type of requested service.

Process600may additionally include mapping (at606) the set of QoS-related LTE parameters to a set of QoS-related 5G parameters. For example, LTE-5G IWF105may maintain mapping information that relates QoS-related LTE parameters (e.g., QCI, TFTs, etc.) to a set of QoS-related 5G parameters (e.g., QFI, SDFs, etc.). In some embodiments, LTE-5G IWF105may utilize machine learning and/or other suitable techniques to generate or refine this mapping information. For example, over time, LTE-5G IWF105and/or some other device or system may monitor the performance of traffic based on these mappings and may refine or modify the mappings, such that traffic that is associated with mapped QoS-related parameters performs in a manner consistent with its original QoS-related parameters.

Process600may also include outputting (at608) a Service Request message, including the mapped set 5G parameters, via a vN2 interface. For example, LTE-5G IWF105may output a Service Request message to AMF203in an N2 container via an N26 interface. The Service Request message may include an identifier of vgNB113(e.g., which may have been previously associated with 5G vUE111as part of a process in which LTE UE107was mapped to 5G vUE111). Thus, from the standpoint of AMF203, AMF203may receive the Service Request message from vgNB113, via which 5G vUE111is connected. The Service Request message may also indicate the PDU Session ID and CN Tunnel ID for the session to be modified, as well as the QoS-related parameters based on which the session is to be modified.

Once AMF203receives the Service Request message (via the vN2 interface), AMF203may communicate with SMF303and/or UPF305to modify the PDU Session indicated in the Service Request message. For example, UPF305may store or maintain the QoS-related parameters, such that UPF305handles, processes, etc. traffic associated with the PDU Session in accordance with the QoS-related parameters.

Process600may also include receiving (at610) a Service Request Ack via the vN2 interface. For example, once the PDU Session modification is complete, AMF203may output the Service Request Act message to LTE-5G IWF105via the vN2 interface. Specifically, for example, from the standpoint of AMF203, AMF203may notify vgNB113that the PDU Session modification is complete. By virtue of receiving the message intended for vgNB113, LTE-5G IWF105may determine that the PDU Session modification (requested in the Service Request at608) has been completed.

Process600may further include outputting (at612) a Bearer Setup Request message via an S1-C interface. For example, LTE-5G IWF105may output the Bearer Setup Request to eNB103via the S1-C interface, and/or may instruct MME201to output the Bearer Setup Request to eNB103via the S1-C interface. The Bearer Setup Request message may indicate that the QoS parameters have been configured on the network side (e.g., at UPF305), and that the QoS parameters should be configured on the UE side (e.g., at LTE UE107and/or at eNB103). The Bearer Setup Request message may include the QoS-related LTE parameters, as well as the TEID and/or EPS Bearer ID associated with the communications between LTE UE107and UPF305.

eNB103may maintain configuration information associated with the QoS-related parameters, and may handle, process, etc. (at614) traffic associated with this communications session (e.g., received via the GTP Tunnel between LTE UE107and UPF305) according to these QoS-related parameters. Further, eNB103may notify LTE UE107of the QoS-related parameters associated with this traffic via an RRC Reconfiguration procedure, based on which LTE UE107may utilize these parameters when handling this traffic.

FIG. 7illustrates an example process700for a network-initiated session modification. In some embodiments, some or all of process700may be performed by LTE-5G IWF105. In some embodiments, one or more other devices may perform some or all of process700(e.g., in concert with, and/or in lieu of, LTE-5G IWF105).

As shown, process700may include receiving (at702) a request, via a vN2 interface, to modify a PDU Session. For example, the request may be received from AMF203, which may indicate that vgNB113is an intended recipient of the request. As similarly described above, LTE-5G IWF105may determine that the request is ultimately associated with LTE UE107based on a previous mapping that may have been performed between LTE UE107and “virtual” devices 5G vUE111and vgNB113. The request may have been provided by AMF203based on a PDU Session modification procedure that was performed for a PDU session associated with UPF305and LTE UE107(or, from the standpoint of AMF203, between UPF305and 5G vUE111). For example, AMF203, SMF303, UPF305, and/or some other device or system (e.g., an element of 5G core network109) may have initiated the PDU Session modification procedure. The request may include a PDU Session ID, a CN Tunnel ID, one or more identifiers of111(e.g., SUPI, SUCI, PEI, etc.), and/or a set of QoS-related 5G parameters that were used to modify the PDU Session.

Process700may further include identifying (at704) QoS-related 5G params associated with the received request. For example, LTE-5G IWF105may identify the QoS-related 5G parameters indicated in the request (received at702), such as a QFI, one or more SDFs, etc.

Process700may additionally include mapping (at706) the QoS-related 5G parameters to a set of QoS-related LTE parameters. For example, LTE-5G IWF105may identify a QCI, one or more TFTs, etc., based on the identified QoS-related 5G parameters. As similarly discussed above, LTE-5G IWF105may also identify one or more LTE identifiers for the communications session between LTE UE107and UPF305, such as a TEID and/or an EPS Bearer ID, that are mapped to the 5G identifiers (e.g., the CN Tunnel ID and/or the PDU Session ID).

Process700may also include outputting (at708) a Bearer Setup Request message via an S1-C interface. For example, LTE-5G IWF105may output the Bearer Setup Request message to eNB103, and/or may instruct MME201to output the Bearer Setup Request message to eNB103. As similarly discussed above, this message may cause eNB103and/or LTE UE107to handle traffic, associated with this communications session, according to the indicated QoS parameters. Thus, user plane communications between LTE UE107and UPF305may ultimately be modified (at710) based on the QoS parameters indicated in the request (received at702) to modify the communications session.

FIG. 8illustrates an example environment800, in which one or more embodiments may be implemented. In some embodiments, environment800may include elements of a 5G core network. In some embodiments, environment800may correspond to a 5G Non-Standalone (“NSA”) architecture, in which a LTE RAT may be used in conjunction with a 5G core network. While not explicitly shown here, similar concepts may apply in environments that include an LTE core network and/or a 5G RAN that implements one or more 5G RATs.

As shown, environment800may include LTE UE107, LTE RAN812(which may include one or more one or more eNBs103), MME201, AMF203, SMF303, Policy Control Function (“PCF”)825, Application Function (“AF”)830, UPF305, UDM840, HSS842, Authentication Server Function (“AUSF”)845, and Data Network (“DN”)850.

Portions of environment800may correspond to a LTE EPS network, such as LTE RAN812, eNB103, MME201, SGW817, and HSS842. Portions of environment800may correspond to a 5G core network, such as AMF203, SMF303, UPF305, PCF825, AF830, UDM840, and AUSF845. While not explicitly shown inFIG. 8, environment800may include additional, fewer, different, or differently arranged elements the LTE EPS and/or of the 5G core network. Further, in some embodiments, environment800may include a 5G RAN (e.g., as implemented by one or more gNBs) and/or a RAN that implements another type of RAT (e.g., a Third Generation (“3G”) RAT, and/or some other RAT). For the sake of brevity, only some portions of the LTE EPS network and the 5G core network are described here.

The quantity of devices and/or networks, illustrated inFIG. 8, is provided for explanatory purposes only. In practice, environment800may include additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than illustrated inFIG. 8. For example, while not shown, environment800may include devices that facilitate or enable communication between various components shown in environment800, such as routers, modems, gateways, switches, hubs, etc. Alternatively, or additionally, one or more of the devices of environment800may perform one or more functions described as being performed by another one or more of the devices of environment800. Devices of environment800may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. In some implementations, one or more devices of environment800may be physically integrated in, and/or may be physically attached to, one or more other devices of environment800.

LTE UE107may include a computation and communication device, such as a wireless mobile communication device that is capable of communicating with LTE RAN812and/or DN850. LTE UE107may be, or may include, a radiotelephone, a personal communications system (“PCS”) terminal (e.g., a device that combines a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., a device that may include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a personal gaming system, an IoT device (e.g., a sensor, a smart home appliance, or the like), a wearable device, a Mobile-to-Mobile (“M2M”) device, or another type of mobile computation and communication device. As provided for herein, LTE UE107may send traffic to and/or receive traffic (e.g., user plane traffic) from DN850via RAN812and UPF305.

While described herein in the context of LTE UE107being an “LTE UE,” in practice, LTE UE107may be a “dual mode” or “multi mode” UE that is capable of communicating via a 5G RAT and/or some other type of RAT. For example, if LTE UE107is capable of communicating via an LTE RAT and a 5G RAT, LTE UE107may communicate using a 5G RAT when in communication range of a 5G RAN (e.g., as implemented by a gNB), and may communicate using an LTE RAT when in communication range of a LTE RAN.

LTE RAN812may be, or may include, an LTE RAN that includes one or more base stations (e.g., one or more eNBs103), via which LTE UE107may communicate with one or more other elements of environment800. LTE UE107may communicate with LTE RAN812via an air interface (e.g., as provided by eNB103). For instance, RAN810may receive traffic (e.g., voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from LTE UE107via the air interface, and may communicate the traffic to UPF305, and/or one or more other devices or networks. Similarly, RAN810may receive traffic intended for LTE UE107(e.g., from UPF305, SGW817, and/or one or more other devices or networks) and may communicate the traffic to LTE UE107via the air interface.

AMF203may include one or more devices, systems, Virtualized Network Functions (“VNFs”), etc., that perform operations to register LTE UE107with the 5G network, to establish bearer channels associated with a PDU session with LTE UE107, to hand off LTE UE107from the 5G network to another network, to hand off LTE UE107from the other network to the 5G network, and/or to perform other operations. In some embodiments, the 5G network may include multiple AMFs203, which communicate with each other via the N14 interface (denoted inFIG. 8by the line marked “N14” originating and terminating at AMF203).

MME201may include one or more devices, systems, VNFs, etc., that perform operations to register LTE UE107, to facilitate the establishment of bearer channels associated with LTE UE107, to facilitate handovers of LTE UE107, and/or to perform other operations. MME201may communicate with AMF203via an N26 interface. MME201may, in some embodiments, be implemented by the same device or system that implements LTE-5G IWF105, and/or may be communicatively coupled with LTE-5G IWF105. For example, MME201may communicate with LTE-5G IWF105via an N26 interface, and/or may instruct LTE-5G IWF105to communicate with AMF203via an N26 interface.

LTE-5G IWF105may include one or more devices, systems, VNFs, etc., that perform operations described herein. Generally speaking, for example, LTE-5G IWF105facilitate the establishment or modification of user plane communications between LTE UE107and UPF305, by communicating with elements of the LTE EPS network (e.g., MME201) and elements of the 5G core network (e.g., AMF203). LTE-5G IWF105may, for example, map 5G parameters or messages to LTE parameters or messages to facilitate the establishment or modification of such communications.

SGW817may include one or more devices, systems, VNFs, etc., that aggregate traffic received from one or more eNBs103and send the aggregated traffic to an external network or device via UPF305. Additionally, SGW817may aggregate traffic received from one or more UPFs305and may send the aggregated traffic to one or more eNBs103. SGW817may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks or LTE RANs812.

SMF303may include one or more devices, systems, VNFs, etc., that gather, process, store, and/or provide information in a manner described herein. SMF303may, for example, facilitate in the establishment of communication sessions on behalf of LTE UE107. In some embodiments, the establishment of communications sessions may be performed in accordance with one or more policies provided by PCF825.

PCF825may include one or more devices, systems, VNFs, etc., that aggregate information to and from the 5G network and/or other sources. PCF825may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users (such as, for example, an administrator associated with PCF825).

AF830may include one or more devices, systems, VNFs, etc., that receive, store, and/or provide information that may be used in determining parameters (e.g., quality of service parameters, charging parameters, or the like) for certain applications.

UPF305may include one or more devices, systems, VNFs, etc., that receive, store, and/or provide data (e.g., user plane data). For example, UPF305may receive user plane data (e.g., voice call traffic, data traffic, etc.), destined for LTE UE107, from DN850, and may forward the user plane data toward LTE UE107(e.g., via LTE RAN812, SGW817, and/or one or more other devices). In some embodiments, multiple UPFs305may be deployed (e.g., in different geographical locations and/or for different traffic or service types), and the delivery of content to LTE UE107may be coordinated via the N9 interface (e.g., as denoted inFIG. 8by the line marked “N9” originating and terminating at UPF305). Similarly, UPF305may receive traffic from LTE UE107(e.g., via RAN812, SGW817, and/or one or more other devices), and may forward the traffic toward DN850. In some embodiments, UPF305may communicate (e.g., via the N4 interface) with SMF303, regarding user plane data processed by UPF305.

UDM840, HSS842, and AUSF845may include one or more devices, systems, VNFs, etc., that manage, update, and/or store profile information associated with one or more subscribers. UDM840, HSS842, and/or AUSF845may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with LTE UE107. One or more of these devices or systems may maintain information indicating particular QoS levels that are associated with particular subscribers. In some embodiments, the QoS information may also be maintained on a per-traffic type basis, a per-device type basis, and/or some other basis. In this manner, UDM840, HSS842, and/or AUSF845may be involved in processes where a QoS level for a given UE, subscriber, traffic flow, etc. is to be determined or verified.

DN850may include one or more wired and/or wireless networks. For example, DN850may include an IP-based PDN, a wide area network (“WAN”) such as the Internet, a private enterprise network, and/or one or more other networks. LTE UE107may communicate, through DN850, with data servers, other UEs, and/or to other servers or applications that are coupled to DN850. DN850may be connected to one or more other networks, such as a public switched telephone network (“PSTN”), a public land mobile network (“PLMN”), and/or another network. DN850may be connected to one or more devices, such as content providers, applications, web servers, and/or other devices, with which LTE UE107may communicate.

FIG. 9illustrates example components of device900. One or more of the devices described above may include one or more devices900. Device900may include bus910, processor920, memory930, input component940, output component950, and communication interface960. In another implementation, device900may include additional, fewer, different, or differently arranged components.

Bus910may include one or more communication paths that permit communication among the components of device900. Processor920may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory930may include any type of dynamic storage device that may store information and instructions for execution by processor920, and/or any type of non-volatile storage device that may store information for use by processor920.

Input component940may include a mechanism that permits an operator to input information to device900, such as a keyboard, a keypad, a button, a switch, etc. Output component950may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc.

Communication interface960may include any transceiver-like mechanism that enables device900to communicate with other devices and/or systems. For example, communication interface960may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface960may include a wireless communication device, such as an infrared (“IR”) receiver, a Bluetooth® radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile telephone, etc. In some embodiments, device900may include more than one communication interface960. For instance, device900may include an optical interface and an Ethernet interface.