Patent Description:
A network may transport data based on the sensitivities and tolerances of the data for the applications and/or services. For example, a network may be configured to provide different levels of quality of service (QoS). Each level of QoS may indicate how the network will transport data associated with that level of QoS. For example, a level of QoS may indicate one or more guarantees, or limits, for latency and throughput. Any data associated with that level of QoS may be processed and/or allocated with network resources in an attempt to deliver the data based on the one or more guarantees, or limits, for latency and throughput. There are many ways in which network technologies associate data with a level of QoS. For example, in a <NUM> radio access network, a QoS Class Identifier (QCI) may be used to associate data with a level of QoS. In a <NUM> radio access network a QoS flow identifier (QFI) may be used to associate data with a level of QoS.

<CIT> discloses a method wherein PDU session is modified for some reason and PDU Session Modification command is sent by a <NUM> radio access network to a UE. <CIT> discloses a method wherein session management function, SMF, sends a PDU session modification to a UE.

Further embodiments are set forth in the dependent claims.

According to the claimed invention, there is provided a method comprising: receiving, by a computing device associated with a first network, from an application or service server, and via a second network, quality of service, QoS, information, wherein the QoS information associates an application or service with one or more QoS flow identifiers, QFIs, and wherein the computing device is configured to operate as a QoS management function, QMF, and a Network Exposure Function, NEF; generating, based on the QoS information, a QoS profile that indicates the one or more QFIs; determining that the QoS profile is associated with a user device based on an indication of a PDU session established for the user device and associated with the transportation of data for the application or service, sending the QoS profile to the user device via the first network, receiving from the user device, via the first network, a selected QFI from the one or more QFIs, and sending, by the computing device, a request to modify the PDU session, wherein the request to modify the PDU session indicates the selected QFI, and wherein the request to modify the PDU session is configured to cause performance of a procedure for modifying, based on the selected QFI, the PDU session.

Some example embodiments are illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:.

In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which are shown by way of illustration various embodiments in which the disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present disclosure.

As discussed above, a network may transport data based on the sensitivities and tolerances of the data for the applications and/or services. For example, a network may be configured to provide different levels of quality of service (QoS). Each level of QoS may indicate how the network will transport data associated with that level of QoS. For example, a level of QoS may indicate one or more guarantees, or limits, for latency and throughput. Any data associated with that level of QoS may be processed and/or allocated with network resources in an attempt to deliver the data based on the one or more guarantees, or limits, for latency and throughput. There are many ways in which network technologies associate data with a level of QoS. In a <NUM> radio access network, a QoS Class Identifier (QCI) may be used to associate data with a level of QoS. In a <NUM> radio access network a QoS flow identifier (QFI) may be used to associate data with a level of QoS.

There are, however, complexities involved in associating a level of QoS with particular data that is to be transported over a network. For example, an application or service may provide different types of data for transport over a network, and each type of data may be sensitive and/or tolerant to a different set of network conditions. To account for these different types of data, existing network infrastructure may associate the data for transport with a level of QoS based on performance of an analysis and classification scheme. The network infrastructure, however, may not have enough information about a type of data for the application or service to efficiently perform the analysis and classification. Other sources may have more information regarding the data and obtaining that information may improve the ability to associate the data with levels of QoS. Examples of such sources include a server, computing device, provider or other entity associated with the application or service. These sources may provide, for example, information indicating the types of data that will be provided for transport over the network, information indicating one or more levels of QoS that can be associated with the types of data, and information indicating how to charge, or bill, for the types of data and/or the one or more levels of QoS. This information may be used to configure QoS for the application or service.

<FIG> is a schematic diagram showing an example communication network <NUM> in which features described herein may be implemented. The communication network <NUM> may include one or more user devices (e.g., user device <NUM>), one or more radio access networks (e.g., radio access network <NUM>), one or more core networks (e.g., core network <NUM>), one or more data networks (e.g., data network <NUM>), and one or more application or service servers (e.g., application or service servers 109A, 109B). The communication network <NUM> may be configured to implement various communication protocols, such as communication protocols specified by the Third Generation Partnership Project (3GPP).

The user device <NUM> may include, for example, a smartphone, personal computer, tablet, desktop computer, laptop computer, gaming device, virtual reality headset, or any other mobile device or other fixed device having a wireless interface configured to communicating with a radio access network. An application or service server 109A, 109B may be implanted using one or more computing devices and may be configured to offer any desired data service. For example, an application service server 109A, 109B may provide, via the data network <NUM>, to the core network <NUM>. The core network <NUM> may transport the data to the user device <NUM> via the radio access network <NUM>.

The data network <NUM> may be a single network or a collection of multiple connected networks. The data network <NUM> may include one or more of any of various types of information distribution networks, such as, without limitation, a satellite network, a telephone network, a cellular network, a Wi-Fi network, an Ethernet network, an optical fiber network, a coaxial cable network, a hybrid fiber coax network, etc. The data network <NUM> may include a local area network (LAN), a wide area network (WAN), a backbone network, etc. The data network <NUM> may include an Internet Protocol (IP) based network (e.g., the Internet). The data network <NUM> may include a plurality of interconnected communication links (e.g., to connect the data network service servers 109A, 109B and/or other devices).

The radio access network <NUM> may include any type of device used to implement radio access technologies, such as the third generation wireless systems (<NUM>), the fourth generation wireless systems (<NUM>), Long Term Evolution (LTE), and the fifth generation wireless systems (<NUM>). For example, the radio access network <NUM> may include a Universal Terrestrial Radio Access Network (UTRAN), Evolved Node B (eNodeB), gNodeB (gNB), or other types of radio access networks. The radio access network <NUM> may be configured to implement a radio protocol stack. The radio access network <NUM> may additionally or alternatively include a cloud radio access network (e.g., comprising central units and distributed units together carrying out the radio protocol stack).

The core network <NUM> may include processes implemented on one or more computing devices. The core network <NUM> may be configured to manage connectivity between the user device <NUM> and the data network <NUM> (e.g., the Internet) via the radio access network <NUM>. The core network <NUM> may include, for example, an Evolved Packet Core (EPC), a <NUM> Core Network, or other types of core networks. The core network <NUM> may communicate with the radio access network <NUM> and/or the data network <NUM> via any type of communication link, such as an IP-based communication link. The radio access network <NUM> and the core network <NUM> may be configured to provide wireless communication between the user device <NUM> and the data network <NUM> (e.g., the Internet).

Example components of the core network <NUM> (e.g., a <NUM> Core Network) are shown in <FIG>. The core network <NUM> may include one or more network functions, such as an AMF <NUM> (Core Access and Mobility Management Function), an UPF <NUM> (User plane Function), an SMF <NUM> (Session Management Function), an AUSF <NUM> (Authentication Server Function), a NSSF <NUM> (Network Slice Selection Function), a NEF <NUM> (Network Exposure Function), a NRF <NUM> (Network Repository Function), a PCF <NUM> (Policy Control Function), an UDM <NUM> (Unified Data Management), an AF <NUM> (Application Function), a CDF <NUM> (Charging Domain Function), an APPQM <NUM> (Application or Service QoS Management Function), a QMF <NUM> (a QoS Management Function), and/or other network functions. The network functions <NUM>-<NUM> may comprise processes implemented on one or more computing devices. The network functions <NUM>-<NUM> may communicate with each other via any type of communication link, such as an IP-based communication link, a virtual network link, a logical connection, etc. The network functions <NUM>-<NUM> described herein may have similar meanings as those specified by 3GPP (e.g., in 3GPP Technical Specification <NUM> version <NUM>. <NUM> Release <NUM>). The core network <NUM> may include additional or alternative network functions, for example, in order to provide wireless communication between the user device <NUM> and the data network <NUM> (e.g., the Internet).

A network (e.g., the communication network <NUM>) or a portion thereof may be sliced into a plurality of virtual networks, which may run on the same physical infrastructure of the network (e.g., an underlying physical <NUM> infrastructure). A network slice (e.g., a virtual network of the plurality of virtual networks) may include, for example, a radio access network, network functions of a core network, etc. Resources (e.g., computing devices, storage devices, networking devices, and other physical computing resources) of the physical infrastructure may be assigned to a network slice to implement the radio access network and/or network functions of the core network, for example, using Network Function Virtualization (NFV). A network slice may be configured to provide specific network functions, such as network functions <NUM>-<NUM>, and/or may be customized for the user(s) in the network slice.

Various types of network slices may be established for different purposes. For example, an enhanced mobile broadband (eMBB) type network slice may be suitable for handling <NUM> enhanced mobile broadband traffic, such as augmented reality (AR) or virtual reality (VR) application and/or service traffic. A massive Internet of Things (MIoT) type network slice may be suitable for handling Internet of Things traffic. An ultra-reliable low latency communications (URLLC) type network slice may be suitable for handling ultra-reliable low latency communications, such as vehicle-to-everything (V2X) communications. Additionally or alternatively, a network slice may be associated with different performance parameters, such as bandwidth, transmission latency, traffic security, etc. A network slice may be associated with one or more levels of QoS.

The user device <NUM> may communicate with the data network service servers 109A, 109B via one or more network slices. To communicate via a network slice, the user device <NUM> may establish, in the network slice, one or more packet data unit (PDU) sessions. A PDU session may comprise an association between a user device and a data network that provides a connectivity service or a data service. The user device <NUM> may indicate the S-NSSAI of the network slice to the AMF <NUM> and/or the SMF <NUM> during a procedure for establishing a PDU session. The procedure for establishing a PDU session may create or otherwise configure a PDU session in the network slice. A PDU session may be associated with different levels of QoS, and/or may be connected to different types of data networks (e.g., an IP network, a non-IP network, the Ethernet, etc.).

The user device <NUM> may run and/or have installed various applications and/or services. The applications and/or services 321A-321C may be, for example, an augmented reality application or augmented reality service; a vehicle-to-everything application or a vehicle-to-everything service, and/or other types of applications and/or services. The applications and/or services may be, via the various networks of <FIG>, in communication with an application or service server 109A, 109B. The applications and/or services may, via the various networks of <FIG>, transmit and/or receive different types of traffic. For example, an augmented reality service or a virtual reality service may transmit and/or receive enhanced mobile broadband traffic. A thermostat service may generate Internet of Things traffic. A vehicle-to-everything service may generate ultra-reliable low latency traffic. The following table provides a few non-limiting examples of the types of data that a user device may send or receive via the various networks of <FIG>. The table, for each example type of data, indicates a number of example network conditions (e.g., throughput, latency, etc.) that may allow for adequate performance for the example type of data. The downlink (DL) may indicate data being sent to the user device <NUM>. The uplink (UL) may indicate data being sent from the user device <NUM>.

The core network <NUM> includes APPQM <NUM> and QMF <NUM>, and these network functions may be configured to cause a PDU session to be associated with a level of QoS based on information received from an application or service server 109A, 109B. As shown in <FIG>, the APPQM <NUM> may be implemented on a computing device or other computing resource that also implements the PCF <NUM>. The QMF <NUM> may be implemented on a computing device or other computing resource that also implements the NEF <NUM>.

The QMF <NUM> may be configured to communicate with an application or service server 109A, 109B. The communication between QMF <NUM> and an application or service server 109A, 109B may be based on an applications programming interface (API) that enables the application or service server 109A, 109B to, for example, provide information usable to configure levels of QoS for a PDU session. The API may allow for the application or service server 109A, 109B to send QoS information to the QMF <NUM>. Based on the QoS information, the QMF <NUM> may generate and/or store a QoS profile. The QoS profile may, for a particular application or service, include information indicating one or more types of data that will be transported over the various networks of <FIG>; information indicating one or more levels of QoS that can be associated with the one or more types of data; and information indicating how to charge, or bill, for the types of data and/or the one or more levels of QoS. The API may allow for the QMF <NUM> to send charging information to the application or service server 109A, 109B. Based on the charging information, the application or service server 109A, 109B may generate the QoS information. More details regarding the communication between the QMF <NUM> and the application or service server 109A, 109B, the QoS information, the QoS profile, and the charging information is provided below.

The QMF <NUM> may be configured to determine whether a QoS profile is associated with a PDU session that was established for the user device <NUM>. Based on this determination, the QMF <NUM> may cause the QoS profile that is associated with the PDU session to be sent to the user device <NUM>. Based on receipt of the QoS profile, the user device <NUM> may determine a level of QoS to associate with the PDU session. The level of QoS may that was determined by the user device <NUM> may have been one of the levels of QoS indicated by the QoS profile. For example, the user device <NUM> may determine a source or destination address for the application or service. The source or destination address may be associated with one of the types of data that will be transported for the PDU session (e.g., the source address may associated with real-time video data). The user device <NUM> may analyze the QoS profile for levels of QoS associated with the source or destination address. The user device <NUM> may, from the levels of QoS associated with the source or destination address, select one of the levels of QoS. The QoS profile may include additional information that is used as a basis for selecting one of the levels of QoS. The user device <NUM> may cause an indication of the level of QoS to be sent to the QMF <NUM>. Based on receipt of the indication of the level of QoS, the QMF <NUM> may be configured to determine a request to modify a PDU session. The request to modify a PDU session may cause performance of a procedure for modifying the PDU session to implement, or otherwise support, the level of QoS. For example, if the level of QoS is identified by a particular QFI, the procedure for modifying the PDU session may configure the PDU session to transport data that includes a particular QFI according to a particular QoS flow. Further details regarding the selection of levels of QoS and the configuration of a PDU session is provided below.

The APPQM <NUM> may be configured to communicate with the QMF <NUM> and/or to act as an interface between the QMF <NUM> and various devices or network functions of the network. For example, the APPQM <NUM> may be configured to receive a QoS profile from the QMF <NUM> and forward the QoS profile for transport to the user device <NUM>. The APPQM <NUM> may be configured to receive an indication of a level of QoS that was determined by the user device <NUM> and forward the indication of the level of QoS to the QMF <NUM>. The APPQM <NUM> may be configured to receive, from the QMF <NUM>, a request to modify a PDU session and may initiate a procedure for modifying the PDU session. Further details regarding the APPQM <NUM> will be provided below.

As discussed above, there are many ways in which network technologies associate data with a level of QoS. In a <NUM> radio access network, a QoS Class Identifier (QCI) may be used to associate data with a level of QoS. In a <NUM> radio access network a QoS flow identifier (QFI) may be used to associate data with a level of QoS. For simplicity, the examples of <FIG> will be discussed in terms of a QoS flow identifier (QFI) and a QoS flow.

<FIG> shows a schematic diagram of an example PDU session that is associated with one or more QoS flows. As shown in <FIG>, a PDU session <NUM> may be established between the UPF <NUM> and the user device <NUM> and may be for the transport of data between the user device <NUM> and an application or service server 109A, 109B. The PDU session <NUM> may include one or more QoS flows including, for example, QoS flow 210A, QoS flow 210B, and QoS flow 210C. Each QoS flow 210A, 210B, 210C may be configured to provide a particular level of QoS for the PDU session <NUM>. For example, QoS flow 210A may allow for high throughput and high latency; QoS flow 210B may allow for low latency and low throughput; and QoS flow 210C may allow for high throughput and low latency. QoS flow 210A may be associated with QFI 220A. QoS flow 210B may be associated with QFI 220B. QoS flow 210C may be associated with QFI 220C. Each QFI 220A, 220B, 220C may have a value different from each other. Further, the values for the QFI 220A, 220B, 220C may be unique for the PDU session <NUM>. Data that includes or is otherwise associated with a particular QFI may, based on being transported based on the associated QoS flow, be provided with the same processing and forwarding treatments (e.g., scheduling, admission threshold). In this way, by associating different types of data with different QFI, the different types of data may be transported, for the PDU session <NUM>, according to different levels of QoS.

One manner of associating data with a QFI is to encapsulate the data with an encapsulation header that includes the QFI. By including the QFI within an encapsulation header, any header and/or payload of the data to be transported may be unchanged (e.g., an IP packet that is to be transported from the application or service server 109A and to the user device <NUM> may be unchanged). For example, if the user device <NUM> intends to send an IP packet to the application or service server 109A, 109B, the user device <NUM> may encapsulate the IP packet with an encapsulation header. The encapsulation header may include a QFI, such as QFI 220A. The user device <NUM> may send the encapsulated IP packet via the RAN <NUM> to the UPF <NUM>. The encapsulated IP packet may, based on the inclusion of the QFI 220A, be transported between the client device <NUM> and the UPF <NUM> according to QoS flow 210A (e.g., transported for high throughput and high latency). The UPF <NUM> may receive the encapsulated IP packet, may remove the encapsulation header, and may forward the IP packet, via the data network <NUM>, to the application or service server 109A, 109B. If the UPF <NUM> receives, from the application or service server 109A, 109B, a User Datagram Protocol (UDP) packet for transport to the user device <NUM>, the UPF <NUM> may encapsulate an encapsulation header onto the UDP packet and forward the resulting encapsulated UDP packet to the user device via the RAN <NUM>. The encapsulation header for the UDP packet may include QFI 220C. The encapsulated UDP packet may, based on the inclusion of the QFI 220C, be transported between the UPF <NUM> and the user device <NUM> according to QoS flow 230C (e.g., transported for high throughput and low latency). The IP packet and UDP packet are just two examples of the underlying data that may be encapsulated and transported over the network. Additional examples of the underlying data include a protocol data unit (PDU) and/or an Ethernet frame.

The QoS flows and QFI of a PDU session may be similar to the flows and indicators described in a version of TS <NUM> published by 3GPP. The following table provides some non-limiting examples of QFI values, associated examples of QoS flow characteristics, and associated examples of application or services that may be suitable for the associated QoS flow characteristics.

<FIG> and <FIG> show one or more example process sequences for configuring a PDU session and transporting data according to one or more levels of QoS. In particular, the one or more example process sequences of <FIG> and <FIG> provide an example involving, among other things, a PDU session, a QoS profile based on information received from an application or service server, a QFI corresponding to a level of QoS, and a QoS flow.

The one or more example process sequences begin at <NUM> where the application or service server (e.g., 109A or 109B) may send QoS information to the QMF <NUM>. The application or service server may send the QoS information based on the application or service becoming available to user devices and/or based on an update to the application or service. The application or service server may send the QoS information based on determining that a current QFI has not met performance thresholds (e.g., latency has increased beyond a threshold). The application or service server may send the QoS information based on a change in charging rates (e.g., a charging rate for a current QFI has changed to be above a threshold and/or the entity that is being charged for the usage has changed).

The QoS information may be associated with a particular application or service (e.g., video service, IoT application), and the QoS information may include an identifier of the particular application or service. The QoS information may include indications, or rules, that associate the particular application or service with one or more QFIs. The indications, or rules, may associate the one or more QFIs with identifiers for the types of data to be transported. The indications, or rules, may associate the one or more QFIs with criteria for when the one or more QFIs may be used. The indications, or rules, may associate the one or more QFIs with charging information indicating which entity (e.g., provider of the application or server, or the user of the user equipment) is to be charged or billed for the network usage. The following table provides an example of the QoS information. As illustrated, the QoS information may include one or more entries for a QFI and each entry for a QFI may be differentiated by an identifier for a type of data and/or the criteria for when the one or more QFIs may be used. Additionally and as illustrated, if the identifier for the type of data and the criteria are associated with multiple QFI, an indication of a priority level for each of the multiple QFI may be included.

In the above example, a number of QFIs for a virtual reality service are associated with types of data, criteria for when the QFIs are to apply, priority levels for the QFIs, and indications of charging information. The QFIs are given a label (e.g., QFI #D, #E, #U, #X, #Y, and #Z) to indicate that each QFI has a value different from the other QFIs. The QFIs of Table III may have values and priority levels similar to those described above in connection with Table II.

In the example, QFIs #U and #Y are associated with a first data type indicated by the first source address or the first destination address. QFIs #D, #E, #X, and #Z are associated with a second data type indicated by the second source address or the second destination address. These source/destination addresses may be used when the user device, application, or service is sending data of that data type (e.g., an IP packet with a payload of the first data type may include the first source address or the first destination address). Source addresses and/or destination addresses are only one example of the types of identifiers that could be used to differentiate the types of data. Other identifiers for differentiating the types of data could be used in place of or in addition to the source address and/or the destination address.

In the example, QFIs #U and #Y are associated with criteria indicating that usage of the QFI #U and #Y is based on a service level associated with the user (e.g., whether a service level is premium or normal). The service level may be found in a user profile stored by UDM <NUM>. QFIs #U and #Y, for the normal service level, are also associated with a priority level. The priority levels for QFI #U and #Y may indicate that QFI #U has a higher priority level than QFI #Y. A higher priority level may indicate that the QFI will be selected over QFIs having a lower priority level if the higher priority level is otherwise available. In the example, QFIs #D, #E, #X, and #Z are associated with criteria indicating that usage of the QFI #D, #E, #X, and #Z is based on a time of day or a range of times within a day. The service levels, time of day or range of times within a day, and the priority levels of the above example are only some of the possible criteria that could be included in QoS information. Other criteria include, for example, a current location of the user device; thresholds of data throughput; thresholds of latency; thresholds of charging rates; sets of key performance indicators (KPIs); media type (e.g., video, audio); other information associated with a user profile saved by UDM <NUM> (e.g., indications on whether the user is able to access certain services such as Internet-of-things services, video services, voice services); and the like. For example, the QoS information may include criteria based on the examples of Table I, such as the DL throughput, the UL throughput, the latency, the reliability, and/or the mobility.

The one or more example process sequences continue at <NUM> where the QMF <NUM> may generate a QoS profile. The QoS profile may be based on the QoS information received from the application or service server. For example, the QoS profile may include some or all of the QoS information (e.g., the QoS profile may include a copy of the example QoS information of Table III).

The QoS profile may include additional data fields not found in the QoS information or may supplement the data of the QoS information. For example, the QoS profile may include a data field for an indication of one or more QFIs that is currently in use for the PDU session. For example, the QoS profile may include data fields for a QFI not found within the QoS information (e.g., a new QFI may be included in the QoS profile based on a rule defined by a provider of the core network <NUM>). For example, the QoS profile may include a data field with an identifier of the application or service server (e.g., a network address of the application or service server). For example, the QoS profile may supplement or replace the identifiers for the types of data from the QoS information (e.g., the first and second source/destination addresses of Table III). The identifiers for the types of data may be determined based on the QFI of the QoS information. To determine the types of data, the QMF <NUM> may process a QFI based on a filter that maps the QFI to one or more sources addresses, destination addresses, transport protocols (e.g., IP protocol), ports, or the like. These identifiers for the types of data (e.g., source address, destination address, transport protocol, port) may be included in the QoS profile for the QFI. For example, the QMF <NUM> may, for each QFI of the QoS information, add charging rate information or replace the charging rate information of the QoS information with current charging rate information. The QMF <NUM> may add, for a QFI, an indication as to whether usage of the QFI is to be charged or is to be free. The QMF may add an indication, for a QFI, of the charging rate for the QFI. The QMF <NUM> may add an indication, for a QFI, of an entity that is charged for the usage of the QFI. These additional indications, or rules, may be formatted similar to the indications, or rules, of the QoS information. The QoS profile may be stored for later access.

At <NUM>, the user device <NUM> may send a request for a PDU session. The request for the PDU session may be sent to the AMF <NUM>. The request for the PDU session may include information indicating one or more requirements of the PDU session. For example, the information may indicate the application or service for the PDU session, such as whether an application or service for <NUM> enhanced mobile broadband, an application or service for virtual reality, an application or service for massive IoT communications, or any other type of application or service (e.g., any of the example applications or services of Table I). The information may indicate, among other things, one or more S-NSSAIs for a network slice, a data network name usable to select an SMF and/or a UPS for a PDU session, and a PDU session type.

At <NUM>, one or more network functions of the core network (e.g., AMF <NUM>, SMF <NUM>, and PCF <NUM>) may perform a procedure for establishing the PDU session. The procedure, for example, may be to establish a new PDU session, to activate an existing PDU session, to switch between PDU sessions, or to handover to the PDU session. The procedure may result in the APPQM <NUM> receiving an indication of the PDU session. The procedure for establishing the PDU session may be performed similar to a version of TS <NUM> published by 3GPP.

At <NUM>, the APPQM <NUM> may send, or forward, the indication of the PDU session to the QMF <NUM>. The indication of the PDU session may include an identifier of the user device <NUM>, one or more identifiers for the type of data to be transported by the PDU session (e.g., one or more source addresses, one or more destination address, one or more transport protocols, one or more ports, or the like), and an identifier for the PDU session.

At <NUM>, the QMF <NUM> may determine that the QoS profile is associated with the user device <NUM>. This determination may be based on a comparison of the one or more identifiers for the types of data to be transported by the PDU session (as included in the indication of the PDU session that was sent from the APPQM <NUM> at <NUM>) and any identifiers for the types of data in the QoS profile. If a match is found (e.g., a source address or destination address included in the indication of the PDU session matches a source address or destination address included in the QoS profile), the QMF <NUM> may determine that the QoS profile is associated with the user device <NUM>. The QMF <NUM> may perform this determination on other conditions, including, for example, whether the QoS profile and the network conditions indicate whether there is a need to have the user device <NUM> determine a QFI. For example, if the QoS profile includes the entries of the example QoS information of Table III, the QMF <NUM> may, based on those entries, determine that usage of at least one QFI in the QoS profile is charged to the user device or the application or service server. Based on determining that usage of at least one QFI in the QoS profile is charged to the user device or the application or service server, the QMF <NUM> may determine that the QoS profile is associated with the user device <NUM>.

At <NUM>, the QMF <NUM> may send the QoS profile to the APPQM <NUM>. The QoS profile may be sent based on determining that the QoS profile is associated with the user device <NUM>. At <NUM>, the APPQM <NUM> may forward, or otherwise send, the QoS profile to the user device <NUM>. The forwarding or sending of the QoS profile may include additional network functions. For example, the APPQM <NUM> may forward the QoS profile to the SMF <NUM>, which in turn may forward the QoS profile to the AMF <NUM>. The AMF <NUM> may forward the QoS profile to the RAN <NUM>. The RAN <NUM> may deliver the QoS profile to the user device <NUM>.

At <NUM>, the user device <NUM> may determine a QFI. This determination may be based on the QoS profile. For example, the user device <NUM> may locate one or more entries from the QoS profile that are associated with the application or service and/or a type of data to be transported (e.g., by locating entries that match a source address or destination address for the type of data). As one example, if the QoS profile includes the entries of the QoS information of Table III, the user device <NUM> may, based on the type of data having the first source address or the first destination address, identify entries for QFI #U and #Y. Based on the entries for QFI #U and #Y, the user device <NUM> may select one of QFI #U and #Y. The selection may be based on the criteria associated with the entries for QFI #U and #Y (e.g., based on the service level, and the priority levels). For example, if the user device <NUM> is associated with a normal service level and based on the priority levels of the QFIs, the user device <NUM> may select QFI #U. If the user device <NUM> is associated with a premium service level, the user device <NUM> may select QFI #Y. The selection may be based on the charging information associated with the entries for QFI #U and #Y. For example, the user device <NUM> may select QFI #Y or QFI #U based on whether the usage is charged to the user of the user device or to the provider of the application or service server.

As part of the determination of a QFI, the user device <NUM> may further analyze a selected QFI based on a desired network performance. For example, the user device <NUM> may determine that the QFI is insufficient to meeting one or more performance thresholds (e.g., throughput associated with the QFI is less a desired throughput, a latency associated with the QFI is more than a desired throughput). Based on determining that the QFI is insufficient, the user device <NUM> may reselect a QFI that satisfies the one or more performance thresholds (e.g., the user device may select QFI #U after determining that QFI #Y is insufficient. The reselected QFI may be one of the QFI indicated in the QoS profile, or may be a QFI that is not indicated in the QoS profile. In this way, the user device <NUM> may, by determining a QFI based on reselection, the user device <NUM> may perform a request for the reselected QFI.

At <NUM>, the user device <NUM> may send an indication of the QFI, which was determined at <NUM>. The indication of the QFI may be forwarded or otherwise sent, via the RAN <NUM> and via various network functions of the network (e.g., AMF <NUM> and SMF <NUM>), to the APPQM <NUM>. At <NUM>, the APPQM <NUM> may forward or otherwise send the indication of the QFI to the QMF <NUM>.

At <NUM>, the QMF <NUM> may verify the QFI and update the QoS profile. The verification of the QFI may be based on a comparison of the QFI and the QoS profile. If the verification passes, the QFI may be accepted and the QoS profile may be updated to indicate that the QFI will be in use for the PDU session. If the verification fails, the QMF <NUM> may apply a set of policy rules to select a different QFI based on the QoS profile, and the QoS profile may be updated to indicate that the different QFI will be in use for the PDU session. Continuing the example of <NUM>, the QMF <NUM> may verify that QFI #Y, based on the QoS profile, is available for use by the user device based on any information or criteria in the QoS profile. The QMF <NUM> may verify that there is sufficient network capacity to support the QFI #Y. If the verification passes, the QoS profile may be updated to indicate that QFI #Y will be in use for the PDU session. If the verification fails, the QMF <NUM> may select a different QFI (e.g., QFI #U) and may update the QoS profile to indicate that QFI #U will be in use for the PDU session. If the user device <NUM> reselected QFI #U after determining that QFI #Y was insufficient, the QMF <NUM> may verify that there is sufficient network capacity to support the QFI #U. If the verification passes, the QoS profile may be updated to indicate that QFI #U will be in use for the PDU session. If the verification fails, the QMF <NUM> may select a different QFI (e.g., QFI #Y) and may update the QoS profile to indicate that QFI #Y will be in use for the PDU session.

At <NUM>, the QMF <NUM> may determine a request to modify the PDU session. The request to modify the PDU session may include an indication of the QFI that will be in use for the PDU session (e.g., QFI #Y if the verification passed, QFI #U if the verification failed).

At <NUM>, the QMF <NUM> may send the request to modify the PDU session. The request may be sent to the APPQM <NUM>. At <NUM>, the APPQM <NUM> may initiate a procedure for modifying the PDU session. This initiation may be based on the request set at <NUM>. At <NUM>, the procedure for modifying the PDU session may be performed. The procedure may result in the QFI being in use for the PDU session. The procedure may be performed similar to a version of TS <NUM> published by 3GPP.

Based on the modification to the PDU session, the QFI may be used to transport data over the network in a QFI flow. For example, at <NUM>, the application or service server may send data for the PDU session. The data may be for an application or service (e.g., any of the example applications or services of Table I). The data may be sent to the UPF <NUM>. Based on receipt of the data by the UPF <NUM>, at <NUM>, the data may be transported, via a QoS flow, based on the QFI. The manner in which the data is processed and/or transported may be similar to the manner described in <FIG>. For example, the UPF <NUM> may encapsulate the data with an encapsulation header that includes the QFI (e.g., QFI 230B) the encapsulated data may be transported to the user device <NUM> via the RAN <NUM> according to the QoS flow (e.g., QoS flow 220B) associated with the QFI.

<FIG> shows one or more example methods for interfacing between one or more network resources and a server of an application or service to enable the configuration of a PDU session. In particular, the one or more example methods of <FIG> is suitable for use by a computing device configured to operate as the QMF <NUM>.

At step <NUM>, a computing device may send charging rate information. The charging rate information may be sent to an application or service server (e.g., 109A, 109B). The application or service server may have previously sent a request for the charging rate information (not shown) to the computing device and the charging rate information may be sent as a response to the request.

The charging rate information may include one or more indications of the current charging rates of the network. For example, the charging rate information may include, for each QFI supported by the network, a current charging rate. The charging rate information may include, for each QFI available for use by the application or service server, a current charging rate. The application or service server may use the charging rate information as a basis for determining the QoS information (e.g., QFI with cheaper charging rates may be prioritized over QFI with lower charging rates). The computing device may receive the current charging rates from a charging domain function of the network (e.g., CDF <NUM>).

At step <NUM>, the computing device receives QoS information. The QoS information is received from an application or service server (e.g., 109A, 109B). Table III, and the associated discussion in connection with <NUM> of <FIG>, provides an example of the QoS information.

At step <NUM>, the computing device may determine whether a QoS profile is stored. For example, the QoS profiles may be searched for a match to an identifier of the application or service server (e.g., a network address of the application or service server). If a match is found, the method may proceed to step <NUM>. If no match is found, the method may proceed to step <NUM>.

At step <NUM>, the computing device generates a QoS profile. The generation is performed based on the QoS information. For example, the generation of the QoS profile may be performed similar to the discussion above in connection with <NUM> of <FIG>. For example, the QoS profile may include some or all of the QoS information, and may include additional information, such as an indication of one or more associated user devices. After generating the QoS profile, the QoS profile may be stored for later access.

At step <NUM>, the computing device may update a QoS profile. The update may be based on which QoS profile was found to match the identifier of the application or service. The update may be based on the QoS information. The QoS profile may be updated to reflect any changes between the stored data of the QoS profile and the QoS information. This may include adding or deleting, from the QoS profile, entries associated with one or more QFIs. For example, if the QoS information includes a new or an updated entry for a QFI, the QoS profile may be updated to include the new or updated entry.

At step <NUM>, the computing device may receive an indication of a PDU session. The indication of the PDU session may be received from an APPQM <NUM> of the network and, similar to <NUM> of <FIG>, may have been received based on a user device requesting the PDU session and/or based on the network establishing the PDU session. The indication of the PDU session may include an identifier of the user device, an identifier of the application or service for the PDU session, and an identifier for the PDU session.

At step <NUM>, the computing device determines whether the QoS profile is associated with a user device. This determination may be performed based on the indication of the PDU session and this determination may be performed similar to the discussion above in connection with <NUM> of <FIG>. For example, this determination may be performed based on comparing information from the indication of the PDU session (e.g., the identifier of the user device, the identifier of the application or service for the PDU session, or the identifier for the PDU session) to information of a QoS profile. If a match is found, the QMF <NUM> may determine that the QoS profile is associated with the user device. The computing device may also perform this determination based on other criteria or information of a QoS profile. For example, based on determining that usage of at least one QFI in the QoS profile is charged to the user device or the application or service server (e.g., at least one QFI is not free of charge), the computing device may determine that the QoS profile is associated with the user device. If the computing device determines that the QoS profile is associated with a user device, the method may proceed to step <NUM>. If the computing device determines that the QoS profile is not associated with a user device, the method may proceed to <NUM>.

At <NUM>, the computing device may select a QFI based on the QoS profile. For example, the computing device, without communicating with the user device, may use the QoS profile as a basis for selecting which QFIs are used for the PDU session. For example, where all QFI are free of charge, the computing device may, based on the QoS profile, select a QFI for use with the PDU session. The computing device may select a QFI based on current network conditions (e.g., to maximize overall bandwidth usage of the network). To perform the selection, the computing device may communicate with one or more network functions of the network. Additionally, based on the selection, the computing device may update the QoS profile to indicate that the selected QFI will be in use for the PDU session the method may then proceed to step <NUM>.

At step <NUM>, the computing device sends the QoS profile that was determined to be associated with the user device. The QoS profile may be sent to the APPQM of the network and may cause the APPQM to forward the QoS profile, via the RAN and/or other network functions, to the user device. The sending of the QoS profile may be performed similar to <NUM> of <FIG>.

At step <NUM>, the computing device receives an indication of a QFI. The indication of the QFI may be received from the APPQM <NUM>. The indication of the QFI may be based on a user device determining, based on the QoS profile, the QFI. The user device may have determined the QFI similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may verify the QFI and update the QoS profile. The verification may be performed based on the indication of the QFI. The update to the QoS profile may be performed based on the result of the verification. The verification and the update may be performed similar to the discussion associated with <NUM> of <FIG>. For example, the verification of the QFI may be based on a comparison of the QFI and the QoS profile. If the verification passes, the QFI may be accepted and the QoS profile may be updated to indicate that the QFI will be in use for the PDU session. If the verification fails, the computing device may apply a set of policy rules to select a different QFI based on the QoS profile, and the QoS profile may be updated to indicate that the different QFI will be in use for the PDU session.

At step <NUM>, the computing device determines request to modify the PDU session. The request to modify a PDU session may indicate the QFI that will be in use for the PDU session (e.g., the QFI that was verified at step <NUM>, the reselected QFI of step <NUM>, or the selected QFI of step <NUM>). The request may be determined similar to the discussion at <NUM> of <FIG>.

At step <NUM>, the computing device sends the request to modify the PDU session. The request may be sent to the APPQM of the network. The APPQM may, in turn, initiate a procedure for modifying the PDU session. The sending and initiation may be performed similar to <NUM> and <NUM>, respectively, of <FIG>. The procedure for modifying the PDU session may be performed similar to the discussion associated with <NUM> of <FIG>. Based on the modification to the PDU session, the GFI may be used to transport data over the network in a QFI flow. An example of data being transported over the network in a QFI flow is provided in the discussion of <NUM> and <NUM> of <FIG>.

<FIG> shows one or more example methods for interfacing between two or more network resources to enable the configuration of a PDU session. In particular, the one or more example methods of <FIG> may be suitable for use by a computing device configured to operate as the APPQM <NUM>.

At step <NUM>, a computing device may send an indication of a PDU session. The indication of the PDU session may have been received based on the PDU being established. Based on receiving the indication of the PDU session, the computing device may forward, or otherwise send, the indication of the PDU session to the QMF of the network. The sending of the indication of the PDU session may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may receive a QoS profile associated with a user device. The QoS profile may have been sent by the QMF of the network after determining that the QoS profile is associated with the user device. The receiving of the QoS profile may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may forward, or otherwise send, the QoS profile. The forwarding, or sending, of the QoS profile may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may receive an indication of a QFI. The indication of the QFI may be received based on a user device determining, based on the QoS profile, a QFI. The receiving of the indication of the QFI may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may forward, or otherwise send, the indication of the QFI. The forwarding, or sending, of the indication of the QFI may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may receive a request to modify the PDU session. The receiving of the request to modify the PDU session may be performed similar to the discussion associated with <NUM> of <FIG>.

At step <NUM>, the computing device may initiate a procedure for modifying the PDU session. The initiation may be performed similar to the discussion associated with <NUM> of <FIG>. The procedure for modifying the PDU session may be performed similar to the discussion associated with <NUM> of <FIG>. Based on the modification to the PDU session, the GFI may be used to transport data over the network in a QFI flow. An example of data being transported over the network in a QFI flow is provided in the discussion of <NUM> and <NUM> of <FIG>.

<FIG> illustrates an example apparatus, in particular a computing device <NUM>, that may be used in a communication network such as the one shown in <FIG>, to implement any or all of the user device <NUM>, the radio access network <NUM>, the core network <NUM>, the data network service servers 109A-109B, and/or other computing devices to perform the steps described above and in <FIG>, <FIG>, <FIG>, and <FIG>. Computing device <NUM> may include a controller <NUM>. The controller <NUM> may be connected to a user interface control <NUM>, display <NUM> and/or other elements as shown. Controller <NUM> may include circuitry, such as for example one or more processors <NUM> and one or more memory <NUM> storing software <NUM> (e.g., computer executable instructions). The software <NUM> may comprise, for example, one or more of the following software options: user interface software, server software, etc., including a radio protocol stack, the network functions <NUM>-<NUM>, etc..

Device <NUM> may also include a battery <NUM> or other power supply device, speaker <NUM>, and one or more antennae <NUM>. Device <NUM> may include user interface circuitry, such as user interface control <NUM>. User interface control <NUM> may include controllers or adapters, and other circuitry, configured to receive input from or provide output to a keypad, touch screen, voice interface - for example via microphone <NUM>, function keys, joystick, data glove, mouse and the like. The user interface circuitry and user interface software may be configured to facilitate user control of at least some functions of device <NUM> though use of a display <NUM>. Display <NUM> may be configured to display at least a portion of a user interface of device <NUM>. Additionally, the display may be configured to facilitate user control of at least some functions of the device (for example, display <NUM> could be a touch screen).

Software <NUM> may be stored within memory <NUM> to provide instructions to processor <NUM> such that when the instructions are executed, processor <NUM>, device <NUM> and/or other components of device <NUM> are caused to perform various functions or methods such as those described herein (for example, as depicted in <FIG>). The software may comprise machine executable instructions and data used by processor <NUM> and other components of computing device <NUM> and may be stored in a storage facility such as memory <NUM> and/or in hardware logic in an integrated circuit, ASIC, etc. Software may include both applications and/or services and operating system software, and may include code segments, instructions, applets, pre-compiled code, compiled code, computer programs, program modules, engines, program logic, and combinations thereof.

Memory <NUM> may include any of various types of tangible machine-readable storage medium, including one or more of the following types of storage devices: read only memory (ROM) modules, random access memory (RAM) modules, magnetic tape, magnetic discs (for example, a fixed hard disk drive or a removable floppy disk), optical disk (for example, a CD-ROM disc, a CD-RW disc, a DVD disc), flash memory, and EEPROM memory. As used herein (including the claims), a tangible or non-transitory machine-readable storage medium is a physical structure that may be touched by a human. A signal would not by itself constitute a tangible or non-transitory machine-readable storage medium, although other embodiments may include signals or ephemeral versions of instructions executable by one or more processors to carry out one or more of the operations described herein.

As used herein, processor <NUM> (and any other processor or computer described herein) may include any of various types of processors whether used alone or in combination with executable instructions stored in a memory or other computer-readable storage medium. Processors should be understood to encompass any of various types of computing structures including, but not limited to, one or more microprocessors, special-purpose computer chips, field-programmable gate arrays (FPGAs), controllers, application-specific integrated circuits (ASICs), hardware accelerators, digital signal processors, software defined radio components, combinations of hardware/firmware/software, or other special or general-purpose processing circuitry.

As used in this application, the term "circuitry" may refer to any of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and (b) combinations of circuits and software (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone, server, or other computing device, to perform various functions) and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present.

These examples of "circuitry" apply to all uses of this term in this application, including in any claims. As an example, as used in this application, the term "circuitry" would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term "circuitry" would also cover, for example, a radio frequency circuit, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or other network device.

Device <NUM> or its various components may be mobile and be configured to receive, decode and process various types of transmissions including transmissions in Wi-Fi networks according to a wireless local area network (e.g., the IEEE <NUM> WLAN standards <NUM>. 11n, <NUM>. 11ac, etc.) and/or wireless metro area network (WMAN) standards (e.g., <NUM>), through a specific one or more WLAN transceivers <NUM>, one or more WMAN transceivers <NUM>. Additionally or alternatively, device <NUM> may be configured to receive, decode and process transmissions through various other transceivers, such as FM/AM Radio transceiver <NUM>, and telecommunications transceiver <NUM> (e.g., cellular network receiver such as CDMA, GSM, <NUM> LTE, <NUM>, etc.). A wired interface <NUM> (e.g., an Ethernet interface) may be configured to provide communication via a wired communication medium (e.g., fiber, cable, Ethernet, etc.).

Although the above description of <FIG> generally relates to a mobile device, other devices or systems may include the same or similar components and perform the same or similar functions and methods. For example, a computer communicating over a wired network connection (for example, the radio access network <NUM>, the core network <NUM>, and the data network service servers 109A-109B) may include the components or a subset of the components described above, and may be configured to perform the same or similar functions as device <NUM> and its components. Further access points as described herein may include the components, a subset of the components, or a multiple of the components (e.g., integrated in one or more servers) configured to perform the steps described herein.

<FIG> illustrates an example system that may be used in a communication network such as the one shown in <FIG>, to implement various devices described herein, such as core networks (e.g., the core network <NUM>), radio access networks (e.g., the radio access network <NUM>), and/or other computing devices to perform the steps described above and in <FIG>, <FIG>, <FIG>, and <FIG>. The system may comprise one or more core networks (e.g., the core network <NUM>), one or more radio access networks (e.g., the radio access network <NUM>), and one or more communication links (e.g., communication link <NUM>).

The core network <NUM> may include a controller <NUM>, which may include circuitry, such as one or more processors <NUM> and one or more memory <NUM> storing software <NUM> (e.g., computer executable instructions). The software <NUM> may comprise, for example, the network functions <NUM>-<NUM>. Software <NUM> may be stored within memory <NUM> to provide instructions to processor <NUM> such that when the instructions are executed, processor <NUM>, the core network <NUM> and/or other components of the core network <NUM> are caused to perform various functions or methods such as those described herein (for example, as depicted in <FIG>, <FIG>, <FIG>, and <FIG>). The core network <NUM> may include general-purpose processors, digital signal processors, hardware accelerators, or software defined radio components.

The core network <NUM> may include a battery <NUM> or other power supply device, and one or more wired interface <NUM>. The wired interface <NUM> (e.g., an Ethernet interface) may be configured to provide communication via a wired communication medium (e.g., fiber, cable, Ethernet, etc.). The wired interface <NUM> may communicate with a wired interface <NUM> in the radio access network <NUM> via the communication link <NUM>. The wired interface <NUM> may also communicate with a network (e.g., the data network <NUM>).

The radio access network <NUM> may include a controller <NUM>, which may include circuitry, such as one or more processors <NUM> and one or more memory <NUM> storing software <NUM> (e.g., computer executable instructions). The software <NUM> may comprise, for example, a radio protocol stack that is implemented by the radio access network <NUM>. Software <NUM> may be stored within memory <NUM> to provide instructions to processor <NUM> such that when the instructions are executed, processor <NUM>, radio access network <NUM> and/or other components of radio access network <NUM> are caused to perform various functions or methods such as those described herein.

The radio access network <NUM> may include a battery <NUM> or other power supply device, one or more wired interface <NUM>, one or more wireless transceiver <NUM>, and one or more antennae <NUM>. The radio access network <NUM> or its various components may be configured to receive, decode and process transmissions through various transceivers, such as wireless transceiver <NUM> (e.g., cellular network receiver such as CDMA, GSM, <NUM> LTE, <NUM>, etc.). The wireless transceiver <NUM> may include downlink processing components and/or uplink processing components. The downlink processing components and/or uplink processing components may include radio frequency transmission components, radio frequency reception components, or baseband processing components. Processing components may include general-purpose processors, digital signal processors, software defined radio components, hardware accelerators, or software components. With the wireless transceiver <NUM> and the antenna <NUM>, the radio access network <NUM> may be configured to communicate with a user device (e.g., the user device <NUM>) according to various aspects described herein. The wired interface <NUM> (e.g., an Ethernet interface) may be configured to provide communication via a wired communication medium (e.g., fiber, cable, Ethernet, etc.). The wired interface <NUM> may communicate with the wired interface <NUM> in the core network <NUM> via the communication link <NUM>.

The software may comprise machine executable instructions and data used by processor and other components of the core network <NUM> and/or the radio access network <NUM> and may be stored in a storage facility such as memory <NUM>, <NUM> and/or in hardware logic in an integrated circuit, ASIC, etc. Software may include both applications and/or services and operating system software, and may include code segments, instructions, applets, pre-compiled code, compiled code, computer programs, program modules, engines, program logic, and combinations thereof.

Memory <NUM>, <NUM> may include any of various types of tangible machine-readable storage medium, including one or more of the following types of storage devices: read only memory (ROM) modules, random access memory (RAM) modules, magnetic tape, magnetic discs (for example, a fixed hard disk drive or a removable floppy disk), optical disk (for example, a CD-ROM disc, a CD-RW disc, a DVD disc), flash memory, and EEPROM memory. As used herein (including the claims), a tangible or non-transitory machine-readable storage medium is a physical structure that may be touched by a human. A signal would not by itself constitute a tangible or non-transitory machine-readable storage medium, although other embodiments may include signals or ephemeral versions of instructions executable by one or more processors to carry out one or more of the operations described herein.

Claim 1:
A method comprising:
receiving (<NUM>), by a computing device associated with a first network, from an application or service server, and via a second network, quality of service, QoS, information, wherein the QoS information associates an application or service with one or more QoS flow identifiers, QFIs, and wherein the computing device is configured to operate as a QoS management function, QMF, and a Network Exposure Function, NEF;
generating (<NUM>), based on the QoS information, a QoS profile that indicates the one or more QFIs;
determining (<NUM>) that the QoS profile is associated with a user device based on an indication of a PDU session established for the user device and associated with the transportation of data for the application or service,
sending (<NUM>) the QoS profile to the user device via the first network, receiving (<NUM>) from the user device, via the first network, a selected QFI from the one or more QFIs, and
sending (<NUM>), by the computing device, a request to modify the PDU session, wherein the request to modify the PDU session indicates the selected QFI, and wherein the request to modify the PDU session is configured to cause performance of a procedure for modifying, based on the selected QFI, the PDU session.