Patent Description:
The following abbreviations and acronyms are herewith defined, at least some of which are referred to within the following description.

Third Generation Partnership Project ("3GPP"), Fifth-Generation Core ("5GC"), Fifth-Generation QoS Indicator ("5QI"), Access and Mobility Management Function ("AMF"), Access Network Performance ("ANP"), Access Point Name ("APN"), Access Stratum ("AS"), Access Traffic Steering, Switching and Splitting ("ATSSS"), Allocation/Retention Policy ("ARP"), Application Programing Interface ("API"), Carrier Aggregation ("CA"), Clear Channel Assessment ("CCA"), Control Channel Element ("CCE"), Channel State Information ("CSI"), Common Search Space ("CSS"), Data Network Name ("DNN"), Data Radio Bearer ("DRB"), Differentiated Services Code Point ("DSCP"), Downlink Control Information ("DCI"), Downlink ("DL"), Enhanced Clear Channel Assessment ("eCCA"), Enhanced Mobile Broadband ("eMBB"), Encapsulating Security Payload ("ESP"), Evolved Node-B ("eNB"), Evolved Packet Core ("EPC"), Evolved UMTS Terrestrial Radio Access Network ("E-UTRAN"), European Telecommunications Standards Institute ("ETSI"), Echo Acknowledgement Indicator ("EAI"), Request Indicator ("ERI", ERI-d refers to an ERI associated with a dummy payload and ERI-v refers to an ERI associated with a valid payload), Fixed Access Gateway Function ("FAGF"), Fixed Network Residential Gateway ("FN-RG"), Frame Based Equipment ("FBE"), Frequency Division Duplex ("FDD"), Frequency Division Multiple Access ("FDMA"), Generic Routing Encapsulation ("GRE"), Globally Unique Temporary UE Identity ("GUTI"), General Packet Radio Service ("GPRS"), GPRS Tunneling Protocol ("GTP", GTP-C refers to control signal tunneling while GTP-U refers to user data tunneling), Hybrid Automatic Repeat Request ("HARQ"), Home Subscriber Server ("HSS"), Internet-of-Things ("IoT"), IP Multimedia Subsystem ("IMS," aka "IP Multimedia Core Network Subsystem"), Internet Protocol ("IP"), Key Performance Indicators ("KPI"), Licensed Assisted Access ("LAA"), Load Based Equipment ("LBE"), Listen-Before-Talk ("LBT"), Long Term Evolution ("LTE"), LTE Advanced ("LTE-A"), Medium Access Control ("MAC"), Multiple Access ("MA"), Modulation Coding Scheme ("MCS"), Machine Type Communication ("MTC"), Massive MTC ("mMTC"), Mobility Management ("MM"), Mobility Management Entity ("MME"), Multiple Input Multiple Output ("MIMO"), Multipath TCP ("MPTCP"), Multi User Shared Access ("MUSA"), Non-Access Stratum ("NAS"), Narrowband ("NB"), Network Function ("NF"), Network Access Identifier ("NAI"), Next Generation (e.g., <NUM>) Node-B ("gNB"), Next Generation Radio Access Network ("NG-RAN"), New Radio ("NR"), Policy Control & Charging ("PCC"), Policy Control Function ("PCF"), Policy Control and Charging Rules Function ("PCRF"), Packet Data Network ("PDN"), Packet Data Unit ("PDU"), PDN Gateway ("PGW"), Public Land Mobile Network ("PLMN"), Quality of Service ("QoS"), QoS Class Identifier ("QCI"), Quadrature Phase Shift Keying ("QPSK"), Registration Area ("RA"), Radio Access Network ("RAN"), Radio Access Technology ("RAT"), Radio Resource Control ("RRC"), Receive ("RX"), Reflective QoS Indicator ("RQI"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Scheduling Request ("SR"), Secure User Plane Location ("SUPL"), Serving Gateway ("SGW"), Session Management Function ("SMF"), Stream Control Transmission Protocol ("SCTP"), System Information Block ("SIB"), Tracking Area ("TA"), Transport Block ("TB"), Transport Block Size ("TBS"), Transmission Control Protocol ("TCP"), Time-Division Duplex ("TDD"), Time Division Multiplex ("TDM"), Transmission and Reception Point ("TRP"), Transmit ("TX"), Trusted WLAN Interworking Function ("TWIF"), Uplink Control Information ("UCI"), Unified Data Management ("UDM"), User Entity/Equipment (Mobile Terminal) ("UE"), Uplink ("UL"), User Plane ("UP"), Universal Mobile Telecommunications System ("UMTS"), Ultra-reliability and Low-latency Communications ("URLLC"), User Datagram Protocol ("UDP"), UE Route Selection Policy ("URSP"), Wireless Local Area Network ("WLAN"), Wireless Local Area Network Selection Policy ("WLANSP"), and Worldwide Interoperability for Microwave Access ("WiMAX").

A <NUM>-capable Residential Gateway ("<NUM>-RG") may register with a <NUM> core network ("5GC") and provide services via the 5GC. Additionally, the <NUM>-RG may be capable of providing access to the 5GC to a UE that is operating "behind" the <NUM>-RG. Currently, based on the 3GPP Rel-<NUM> specifications, the UE operating "behind" the <NUM>-RG can access the 5GC and can establish PDU Sessions, but these PDU Sessions are unable to fulfill strict QoS requirements. Further examples of multi-mode connectivity of remote user terminals are disclosed in <CIT>.

Methods for modifying a data connection to support QoS requirements are disclosed. Apparatuses and systems also perform the functions of the methods.

One method for modifying a data connection to support QoS requirements includes supporting a first data connection with a <NUM> core network over a first access network, the first data connection supporting a plurality of quality of service ("QoS") flows. The method includes receiving a first request over a second access network, the first request containing a first set of parameters for establishing a second data connection with a remote unit over the second access network. The method includes determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection. The method includes sending a second request to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection, the second request containing a second set of parameters derived from the first set of parameters. The method includes relaying the data traffic between the second data connection and the new QoS flow over the first data connection.

In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagram.

Methods, apparatuses, and systems are disclosed for modifying a data connection to support QoS requirements. UEs operating "behind" a <NUM>-capable Residential Gateway (<NUM>-RG) should be able to access the <NUM> core network and establish PDU Sessions capable to support strict QoS, e.g. to support guaranteed bitrate flows.

A problem with the current <NUM>-RGs and gateway UEs (e.g., operating according to current 3GPP Rel-<NUM>) is that the <NUM>-RG (or gateway UE) maps the data traffic (i.e. the IPsec SA traffic) of a UE operating behind the gateway (referred to as "UE-<NUM>") into one of its QoS flows without knowing the QoS requirements of this data traffic. This occurs because the PDU Session of UE-<NUM> and the associated IPsec SA for UE-<NUM> are established completely transparently to the <NUM>-RG (or gateway UE). In other words, the <NUM>-RG (or gateway UE) does not know that UE-<NUM> has created its own PDU Session that requires specific QoS handling. Therefore, when the data traffic of UE-<NUM> goes through the PDU Session of the <NUM>-RG, it is very likely that it does not receive the appropriate QoS handling. This means that it is not possible for the PDU Session of UE-<NUM> to guarantee its assigned level of QoS, because the traffic of this PDU Session goes through the PDU Session of <NUM>-RG and can be mapped to a QoS flow of <NUM>-RG that does not support the appropriate QoS.

To resolve this problem, this disclosure proposes a solution that enables the <NUM>-RG (a) to map the IPsec traffic of UE-<NUM> into a QoS flow that can meet the QoS requirements of this traffic, or (b) to create a new QoS flow that will carry the IPsec traffic of UE-<NUM> and will be capable to offer the QoS for this traffic.

<FIG> depicts a wireless communication system <NUM> for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. In one embodiment, the wireless communication system <NUM> includes at least one remote unit <NUM>, at least one gateway UE <NUM>, a <NUM>-RAN <NUM>, a <NUM>-RG <NUM> and a mobile core network <NUM>. The <NUM>-RAN <NUM> and the mobile core network form a mobile communication network. The <NUM>-RAN <NUM> may be composed of a 3GPP access network <NUM> containing at least one cellular base unit <NUM> and/or a non-3GPP access network <NUM> containing at least one access point <NUM>. The gateway UE <NUM> may communicate with the 3GPP access network <NUM> using 3GPP communication links <NUM> and communicates with the non-3GPP access network <NUM> using non-3GPP communication links <NUM>. In various embodiments, the remote unit <NUM> may communicate with the 3GPP access network <NUM> using 3GPP communication links <NUM>, may communicate with the non-3GPP access network <NUM> using non-3GPP communication links <NUM>, and/or may communicate with the <NUM>-RG <NUM> or the gateway UE <NUM>, e.g., using non-3GPP communication links <NUM>.

Even though a specific number of remote units <NUM>, gateway UEs <NUM>, 3GPP access networks <NUM>, cellular base units <NUM>, 3GPP communication links <NUM>, non-3GPP access networks <NUM>, access points <NUM>, non-3GPP communication links <NUM>, <NUM>-RG <NUM>, and mobile core networks <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, 3GPP access networks <NUM>, cellular base units <NUM>, 3GPP communication links <NUM>, non-3GPP access networks <NUM>, access points <NUM>, non-3GPP communication links <NUM>, and mobile core networks <NUM> may be included in the wireless communication system <NUM>.

In one implementation, the wireless communication system <NUM> is compliant with the <NUM> system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example, LTE or WiMAX, among other networks.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit ("WTRU"), a device, or by other terminology used in the art.

The remote units <NUM> may communicate directly with one or more of the cellular base units <NUM> in the 3GPP access network <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the 3GPP communication links <NUM>. Similarly, the remote units <NUM> may communicate with one or more access points <NUM> in the non-3GPP access network(s) <NUM> via UL and DL communication signals carried over the non-3GPP communication links <NUM>. Additionally, the remote units <NUM> may communicate with the gateway UE <NUM> and/or the <NUM>-RG <NUM> via UL and DL communication signals carried over non-3GPP communication links <NUM>. Here, the access networks <NUM> and <NUM> are intermediate networks that provide the remote units <NUM>, gateway <NUM>, and <NUM>-RG <NUM> with access to the mobile core network <NUM>.

In some embodiments, the remote units <NUM> communicate with a remote host via a network connection with the mobile core network <NUM>. For example, an application in a remote unit <NUM> (e.g., web browser, media client, telephone/VoIP application) may trigger the remote unit <NUM> to establish a PDU session (or other data connection) with the mobile core network <NUM> using the <NUM>-RAN <NUM> (e.g., a 3GPP access network <NUM> and/or a non-3GPP access network <NUM>). The mobile core network <NUM> then relays traffic between the remote unit <NUM> and the data network <NUM> using the PDU session. Note that the remote unit <NUM> may establish one or more PDU sessions (or other data connections) with the mobile core network <NUM>. As such, the remote unit <NUM> may have at least one PDU session for communicating with the data network <NUM>. The remote unit <NUM> may establish additional PDU sessions for communicating with other data network and/or other remote hosts.

The cellular base units <NUM> may be distributed over a geographic region. In certain embodiments, a cellular base unit <NUM> may also be referred to as an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The cellular base units <NUM> are generally part of a radio access network ("RAN"), such as the 3GPP access network <NUM>, that may include one or more controllers communicably coupled to one or more corresponding cellular base units <NUM>. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The cellular base units <NUM> connect to the mobile core network <NUM> via the 3GPP access network <NUM>.

The cellular base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector, via a 3GPP communication link <NUM>. The cellular base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the cellular base units <NUM> transmit DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the 3GPP communication links <NUM>. The 3GPP communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The 3GPP communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the cellular base units <NUM>.

The non-3GPP access networks <NUM> may be distributed over a geographic region. In various embodiments, the non-3GPP access network <NUM> may comprise one or more wireless networks, for example WLAN(s). In certain embodiments, a non-3GPP access network <NUM> may serve a number of remote units <NUM> with a serving area of an access point <NUM>. An access point <NUM> in a non-3GPP access network <NUM> may communicate directly with one or more remote units <NUM> by receiving wireless UL communication signals and transmitting wireless DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Both DL and UL communication signals are carried over the non-3GPP communication links <NUM>. The 3GPP communication links <NUM> and non-3GPP communication links <NUM> may employ different frequencies and/or different communication protocols. In various embodiments, an access point <NUM> may communicate using unlicensed radio spectrum. The mobile core network <NUM> may provide services to a remote unit <NUM> via the non-3GPP access networks <NUM>, as described in greater detail herein.

In some embodiments, the non-3GPP access network <NUM> may comprise one or more fixed wireline networks. Here, a fixed wireline non-3GPP access network <NUM> may connect to a <NUM>-RG <NUM>. A <NUM>-RG <NUM> may connect to the mobile core network <NUM> via the fixed wireline network. Here, the <NUM>-RG <NUM> may register as a UE to the mobile core network <NUM> and thus establish data connections (e.g., PDU sessions) with the mobile core network <NUM>. As such, the <NUM>-RG <NUM> supports <NUM>-NAS signaling and may establish a NAS layer connection with the AMF <NUM>. Additionally, the <NUM>-RG <NUM> may connect to the remote unit <NUM> and serve as a gateway function by providing the remote unit <NUM> with access to the mobile core network <NUM>. While depicted as connecting to the mobile core network <NUM> via a non-3GPP access network <NUM>, in certain embodiments the <NUM>-RG <NUM> may connect to the mobile core network <NUM> using a fixed wireless connection via the 3GPP access network <NUM>.

The gateway UE <NUM> may connect wirelessly to the mobile core network <NUM> via the 3GPP access network <NUM> and/or non-3GPP access network <NUM>. Here, the gateway UE <NUM> may register as a UE to the mobile core network <NUM> and thus establish data connections (e.g., PDU sessions) with the mobile core network <NUM>. Here, the gateway UE <NUM> establishes a NAS layer connection with the AMF <NUM>. Additionally, the gateway UE <NUM> may connect (wirelessly) to the remote unit <NUM> and serve as a gateway function by providing the remote unit <NUM> with access to the mobile core network <NUM>.

In some embodiments, a non-3GPP access network <NUM> connects to the mobile core network <NUM> via an interworking function <NUM>. The interworking function <NUM> provides interworking between the remote unit <NUM> and the mobile core network <NUM>. In some embodiments, the interworking function <NUM> is a Non-3GPP Interworking Function ("N3IWF") and, in other embodiments, it is a Trusted Non-3GPP Gateway Function ("TNGF"). The N3IWF supports the connection of "untrusted" non-3GPP access networks to the mobile core network (e.g. 5GC), whereas the TNGF supports the connection of "trusted" non-3GPP access networks to the mobile core network. The interworking function <NUM> supports connectivity to the mobile core network <NUM> via the "N2" and "N3" interfaces, and it relays "N1" signaling between the remote unit <NUM> and the AMF <NUM>. As depicted, both the 3GPP access network <NUM> and the interworking function <NUM> communicate with the AMF <NUM> using a "N2" interface. The interworking function <NUM> also communicates with the UPF using a "N3" interface.

In certain embodiments, a non-3GPP access network <NUM> may be controlled by an operator of the mobile core network <NUM> and may have direct access to the mobile core network <NUM>. Such a non-3GPP AN deployment is referred to as a "trusted non-3GPP access network. " A non-3GPP access network <NUM> is considered as "trusted" when it is operated by the 3GPP operator, or a trusted partner, and supports certain security features, such as strong air-interface encryption. In contrast, a non-3GPP AN deployment that is not controlled by an operator (or trusted partner) of the mobile core network <NUM>, does not have direct access to the mobile core network <NUM>, or does not support the certain security features is referred to as a "non-trusted" non-3GPP access network.

In one embodiment, the mobile core network <NUM> is a <NUM> core ("5GC") or the evolved packet core ("EPC"), which may be coupled to a data network (e.g., the data network <NUM>, such as the Internet and private data networks, among other data networks. A remote unit <NUM> may have a subscription or other account with the mobile core network <NUM>. Each mobile core network <NUM> belongs to a single public land mobile network ("PLMN").

The mobile core network <NUM> includes several network functions ("NFs"). As depicted, the mobile core network <NUM> includes multiple user plane functions ("UPFs"). Here, the mobile core network <NUM> includes at least a UPF-<NUM><NUM> that serves the <NUM>-RG <NUM> (and/or gateway UE <NUM>) and a UPF-<NUM><NUM> that serves a remote unit <NUM>. Note that in certain embodiments, the mobile core network may contain one or more intermediate UPFs, for example a first intermediate UPF that serves the non-3GPP access network <NUM> and the second intermediate UPF that serves the 3GPP access network <NUM>. In such embodiments, there is an anchor UPF receiving UP traffic of the intermediate UPFs.

The mobile core network <NUM> also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function ("AMF") <NUM> that serves both the 3GPP access network <NUM> and the non-3GPP access network <NUM>, a Session Management Function ("SMF") <NUM>, a Policy Control Function ("PCF") <NUM>, and a Unified Data Management function ("UDM") <NUM>. In certain embodiments, the mobile core network <NUM> may also include an Authentication Server Function ("AUSF"), a Network Repository Function ("NRF") (used by the various NFs to discover and communicate with each other over APIs), or other NFs defined for the 5GC.

In various embodiments, the mobile core network <NUM> supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. The different network slices are not shown in <FIG> for ease of illustration, but their support is assumed.

Although specific numbers and types of network functions are depicted in <FIG>, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network <NUM>. Moreover, where the mobile core network <NUM> is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like.

As depicted, a remote unit <NUM> (e.g., a UE) may connect to the mobile core network <NUM> (e.g., to a <NUM> mobile communication network) via the <NUM>-RG <NUM>. Such a remote unit <NUM> is said to be operating "behind" the <NUM>-RG <NUM>. Similarly, a remote unit <NUM> may connect to the mobile core network <NUM> via the gateway UE <NUM>. Such a remote unit <NUM> is said to be operating "behind" the gateway UE <NUM>.

In some embodiments, the <NUM>-RG <NUM> is able to modify its PDU Session with the <NUM> core network when a remote unit <NUM> operating behind the <NUM>-RG <NUM> requests specific QoS resources (e.g., an IEEE <NUM> Traffic Stream) over non-3GPP access. The modified PDU Session of the <NUM>-RG <NUM> supports a new QoS flow that is capable to transfer the traffic of the remote unit <NUM> to the <NUM> core network by providing the necessary QoS handling. Similarly, a gateway UE <NUM> may be configured to modify its PDU Session with the <NUM> core network when a remote unit <NUM> operating behind the gateway UE <NUM> requests specific QoS resources, such that the modified PDU session supports a new QoS flow that is capable to transfer the traffic of the remote unit <NUM> to the <NUM> core network by providing the necessary QoS handling.

<FIG> depicts a network architecture <NUM>, according to embodiments of the disclosure. The network architecture <NUM> includes a UE <NUM> which is operating behind a gateway - here the <NUM>-RG <NUM>, a UPF-<NUM><NUM>, an IWF-<NUM><NUM> and UPF-<NUM><NUM>. The UE <NUM> may be one implementation of the remote unit <NUM>, while the <NUM>-RG <NUM> may be one implementation of the <NUM>-RG <NUM>. While the network architecture <NUM> depicts the UE <NUM> operating behind the <NUM>-RG <NUM>, in other embodiments of the network architecture <NUM>, the <NUM>-RG <NUM> is replaced with a gateway UE <NUM> (i.e., the UE <NUM> operates behind a gateway UE <NUM>).

The <NUM>-RG <NUM> is registered with a <NUM> core network and has established a PDU Session <NUM> for communicating with Data Network-<NUM><NUM>, e.g. the Internet or an IPTV network offering TV channel streaming. The PDU Session <NUM> of <NUM>-RG is anchored at the UPF-<NUM><NUM>. Initially, the PDU Session <NUM> of the <NUM>-RG is composed of two QoS flows (QoS Flow-<NUM><NUM> and QoS Flow-<NUM><NUM>), each one offering different QoS characteristics. The <NUM>-RG <NUM> is configured with QoS rules that map the uplink data traffic of the <NUM>-RG <NUM> to one of these QoS flows. Similarly, the UPF-<NUM><NUM> is configured with N4 rules that map the downlink data traffic of the <NUM>-RG <NUM> to one of these QoS flows.

In addition, the UE <NUM> is registered with the <NUM> core network via the <NUM>-RG <NUM> and has established its own PDU Session <NUM> for communicating with Data Network-<NUM><NUM>, e.g. an enterprise network. Here, the PDU Session <NUM> of the UE <NUM> is anchored at UPF-<NUM><NUM>. In contrast to the <NUM>-RG <NUM>, the data traffic of the UE <NUM> needs to go through a first Interworking function ("IWF-<NUM>") <NUM> (e.g., a TNGF or a N3IWF) before reaching the <NUM> core network. In various embodiments, this requirement is due to the UE <NUM> (as well as every UE operating "behind" a <NUM>-RG <NUM>) accessing the <NUM> core by utilizing the solution for non-3GPP access, which requires a TNGF or N3IWF.

Note that all data traffic of the UE <NUM>, i.e., all traffic sent via the PDU Session <NUM> of the UE <NUM>, is carried over an IPsec Security Association (SA) <NUM> between the UE <NUM> and the IWF-<NUM><NUM>, which is established during the setup of the PDU Session <NUM> of the UE <NUM>. This IPsec SA <NUM> carries all QoS flows of the UE <NUM> (which are different from the QoS flows of <NUM>-RG <NUM>) and, hence, it should support specific QoS characteristics.

If no established QoS flow for the <NUM>-RG <NUM> supports the appropriate QoS, then the <NUM>-RG <NUM> creates a new QoS flow <NUM> that will carry the IPsec traffic of the UE <NUM>. Here, the <NUM>-RG <NUM> establishes the new QoS flow <NUM>, based on the QoS requirements associated with the IPsec traffic of the UE <NUM> and then maps the IPsec traffic of the UE <NUM> onto this new QoS flow <NUM>. In this way, the IPsec traffic of the UE <NUM> receives the appropriate QoS handling when going through the PDU Session <NUM> of the <NUM>-RG <NUM>. Creating a new QoS flow is discussed in greater detail below with reference to <FIG>.

In the general case, where the PDU Session <NUM> of the UE <NUM> is composed of multiple IPsec SAs, then the <NUM>-RG <NUM> may establish a new QoS flow for every IPsec SA. Alternatively, the <NUM>-RG <NUM> may establish a new QoS for some IPsec SAs and map the other IPsec SAs into existing QoS flows. For ease of illustration, only a single IPsec SA <NUM> is shown in <FIG>.

<FIG> depicts a network procedure <NUM> for modifying a data connection to support QoS requirements of an access network, according to embodiments of the disclosure. The network procedure <NUM> involves the UE <NUM>, the <NUM>-RG <NUM>, the UPF-<NUM><NUM>, the IWF-<NUM><NUM>, the UPF-<NUM><NUM>, an AMF-<NUM><NUM>, an SMF-<NUM><NUM>, and a PCF-<NUM><NUM>. The UE <NUM>, the <NUM>-RG <NUM>, the UPF-<NUM><NUM>, the IWF-<NUM><NUM>, and the UPF-<NUM><NUM> are substantially as described above with reference to <FIG>. The AMF-<NUM><NUM> is an AMF serving the <NUM>-RG <NUM> and may be an implementation of the AMF <NUM>. The SMF-<NUM><NUM> is an SMF serving the <NUM>-RG <NUM> and may be an implementation of the SMF <NUM>. The PCF-<NUM><NUM> is a PCF serving the <NUM>-RG <NUM> and may be an implementation of the PCF <NUM>.

In the network procedure <NUM>, the <NUM>-RG <NUM> makes sure that the traffic over the child IPsec SA between UE <NUM> and IWF-<NUM><NUM> is transferred via its PDU Session (first data connection) by receiving the appropriate QoS handling. In turn, this enables the UE <NUM> to establish a PDU Session (composed by one or more child IPsec SAs) via the <NUM>-RG <NUM> that can receive the expected QoS handling.

At <FIG>, the network procedure <NUM> begins at step <NUM> with the <NUM>-RG <NUM> having registered with a <NUM> core network, either via fixed wireless access, or via fixed wireline access (e.g., cable or xDSL), and has established a PDU Session <NUM> (first data connection) to the Data Network-<NUM><NUM>, e.g., the Internet or an IPTV network offering TV channel streaming. Note that the <NUM> network functions AMF-<NUM><NUM>, SMF-<NUM><NUM>, PCF-<NUM><NUM>, and UPF-<NUM><NUM> have been allocated to support the <NUM>-RG <NUM> and its PDU Session <NUM>. The PDU Session <NUM> supports one or more QoS flows, each one supporting certain QoS characteristics. The data traffic <NUM> of the <NUM>-RG <NUM> is carried via the PDU Session <NUM>.

In addition, the UE <NUM> has connected to the <NUM>-RG <NUM> via non-3GPP access (e.g., Bluetooth, Wi-Fi, etc.) and has registered to the <NUM> core network via the <NUM>-RG <NUM>. Here, such registration may be performed according to 3GPP specifications. The <NUM> network functions IWF-<NUM><NUM> (e.g., a TNGF or N3IWF) and AMF-<NUM> (not shown in the figure) are allocated to serve the UE <NUM>. The UE <NUM> decides to establish a PDU Session in order to communicate with an external Data Network-<NUM><NUM> (e.g., the Internet or a corporate data network). For this purpose, the UE <NUM> sends a PDU Session Establishment Request to the IWF-<NUM><NUM> via the PDU Session <NUM> of the <NUM>-RG <NUM>. The <NUM> network allocates a SMF-<NUM> and UPF-<NUM> to serve this PDU Session of the UE <NUM>.

At step <NUM>, as part of the UE <NUM> PDU Session Establishment procedure, the IWF-<NUM><NUM> sends to the UE <NUM> a request to establish a child IPsec SA, which will carry one or more QoS flows of the PDU Session of the UE <NUM> (see messaging <NUM>). Here, the request includes "Additional QoS Information" that indicates what QoS characteristics (e.g., max delay, mean and peak bitrates, etc.) are required for the traffic over this child IPsec SA.

At step <NUM>, the UE <NUM> requests to reserve QoS resources over the non-3GPP access (between the UE <NUM> and the <NUM>-RG <NUM>) in order to support the QoS requirements of the child IPsec SA (see block <NUM>). For this purpose, the UE <NUM> requests from the <NUM>-RG <NUM> to establish a new Traffic Stream ("TS"), e.g., by sending an Add Traffic Stream ("ADDTS") Request as specified in the IEEE <NUM> specification (see messaging <NUM>). The ADDTS includes the parameters TSPEC and TCLAS, a first set of parameters. It is assumed here that the non-3GPP access between the UE <NUM> and the <NUM>-RG <NUM> complies with IEEE <NUM>. The TCLAS (Traffic Classification) element specifies the traffic that will be carried over the TS, e.g., by containing source and destination IP addresses and the Security Parameter Indexes (SPIs) of the child IPsec SA. The TSPEC (Traffic Specification) element specifies the QoS requirement of the TS, e.g., by containing the delay bound, min/mean/peak data rates, etc. The TSPEC element is populated based on the QoS requirements in the received "Additional QoS Information.

At step <NUM>, after receiving the ADDTS Request containing TCLAS and TSPEC (first set of parameters), the <NUM>-RG <NUM> determines what QoS resources are required for the TS (e.g., based on TSPEC) and what traffic should be carried on the TS (e.g., based on TCLAS). If the <NUM>-RG <NUM> can satisfy the requested QoS reservation, it responds with an ADDTTS Response message and creates the associated Traffic Stream (TS) over non-3GPP access (see messaging <NUM>). This TS will carry the traffic of the child IPsec SA between the UE <NUM> and the <NUM>-RG <NUM>.

At step <NUM>, after successfully establishing the TS with the <NUM>-RG <NUM> (e.g., reserving the QoS resources), the UE <NUM> accepts the child IPsec SA requested by the IWF-<NUM><NUM> (see messaging <NUM>). Note that signaling between the UE <NUM> and the IWF-<NUM><NUM>, including the PDU Session Establishment request/response and the IKE_Create_Child_SA request/response, is sent over a "signaling IPsec" tunnel, which is set up during the UE registration. This "signaling IPsec" tunnel goes through the PDU Session <NUM> of <NUM>-RG and thus through one of the existing QoS flows of the PDU Session <NUM>.

At step <NUM> (refer to block <NUM>), after successfully establishing the TS with the UE <NUM>, the <NUM>-RG <NUM> determines if the traffic of this TS (second data connection) can be mapped into one of the existing QoS flows over its PDU Session <NUM> (first data connection). In various embodiments, this is determined by comparing the QoS characteristics of the TS (as defined by TSPEC) and the QoS characteristics of each existing QoS flow. If the traffic of the TS can be mapped into an existing QoS flow (called the matched QoS flow), then the <NUM>-RG <NUM> is configured to (a) forward the traffic arriving via the TS to the UPF-<NUM><NUM> by using the matched QoS flow and (b) to forward the traffic arriving from the UPF-<NUM><NUM> that matches the TCLAS (e.g., the downlink traffic of the child IPsec SA) to the TS by using the matched QoS flow.

Continuing at <FIG>, at step <NUM>, if the traffic of the TS cannot be mapped into an existing QoS flow, then the <NUM>-RG <NUM> decides to modify its PDU Session <NUM> and request a new QoS flow. For this purpose, the <NUM>-RG <NUM> starts the UE-initiated PDU Session Modification procedure <NUM> by sending a PDU Session Modification Request including the Requested QoS Rules and the Requested QoS flow descriptions (see messaging <NUM>).

The Requested QoS Rules specify the traffic that will be carried on the new QoS flow and is derived by using the TCLAS element received in step <NUM>. In one example, the Requested QoS Rules will include one QoS rule with two packet filters: One that is used to detect the uplink traffic carried over the child IPsec SA (e.g., by means of an SPI and IP addresses) and another that is used to detect the downlink traffic carried over the child IPsec SA (e.g., again by means of an SPI and IP addresses). The Requested QoS flow descriptions specify the QoS characteristics of the requested QoS flow (e.g., guaranteed bitrates for uplink and downlink) and is derived by using the TSPEC element received in step <NUM>. In one example, the Requested QoS flow descriptions will include two parameters: One for the guaranteed bitrate in the downlink direction and another for the guaranteed bitrate in the uplink direction.

Note that the UE-initiated PDU Session Modification procedure <NUM> may be performed according to 3GPP specifications. As such, there may be additional steps (see block <NUM>) prior to the network functions sending a PDU Session Modification Command (see messaging <NUM>). After the PDU Session modification is successfully completed (see messaging <NUM>), the PDU Session of the <NUM>-RG <NUM> is modified to support a new QoS flow <NUM>, which can meet the QoS requirements for the child IPsec SA <NUM> between the UE <NUM> and the IWF-<NUM><NUM>. In this way, the IPsec traffic of the UE's PDU Session <NUM> receives the appropriate QoS handling when going through the <NUM>-RG's modified PDU Session <NUM>. In the general case, where the UE's PDU Session <NUM> is composed by multiple child IPsec SAs, the PDU Session Modification procedure at step <NUM> may create multiple new QoS flows in the PDU Session of <NUM>-RG <NUM>. Each of these new QoS flows may be used to carry the traffic of a separate child IPsec SA.

The <NUM>-RG <NUM> is configured to (a) forward the traffic arriving via the TS <NUM> (second data connection) to the UPF-<NUM><NUM> by using the new QoS flow <NUM> and (b) to forward the traffic <NUM> arriving from the UPF-<NUM><NUM> that matches the TCLAS (e.g., the downlink traffic of the child IPsec SA <NUM>) to the TS <NUM> by using the new QoS flow <NUM>.

<FIG> depicts a second network architecture <NUM>, according to embodiments of the disclosure. Depicted are the UE <NUM> which is operating behind the <NUM>-RG <NUM>. The <NUM>-RG <NUM> is registered with a <NUM> core network and has established a PDU Session <NUM> for communicating with Data Network-<NUM><NUM>. The PDU Session <NUM> of the <NUM>-RG <NUM> is anchored at the UPF-<NUM><NUM> and is composed of two QoS flows (QoS Flow-<NUM><NUM> and QoS Flow-<NUM><NUM>), each one offering different QoS characteristics.

The UE <NUM> is registered with the <NUM> core network via the <NUM>-RG <NUM> and has established its own PDU Session <NUM> for communicating with Data Network-<NUM><NUM>. Here, the PDU Session <NUM> of the UE <NUM> is anchored at UPF-<NUM> and goes through the IWF-<NUM><NUM> before reaching the <NUM> core network. Data traffic of the UE <NUM> mapped to the QoS Flow-<NUM><NUM> is carried over an IPsec Security Association (SA) <NUM> between the UE <NUM> and the IWF-<NUM><NUM>, which is established during the setup of the PDU Session <NUM> of the UE <NUM>. Note that if no established QoS flow for the <NUM>-RG <NUM> supports the appropriate QoS, then the <NUM>-RG <NUM> creates a new QoS flow to carry IPsec traffic of the UE <NUM>. In various embodiments, the <NUM>-RG <NUM> may establish a new QoS flow for some IPsec SAs and map the other IPsec SAs into existing QoS flows. For ease of illustration, only a single IPsec SA is shown in <FIG>.

As discussed above with reference to <FIG>, the UE <NUM> sends an ADDTS request to the <NUM>-RG <NUM> allowing the <NUM>-RG <NUM> to map the data traffic of the UE <NUM> (i.e. IPsec SA traffic) into an appropriate QoS flow of the PDU Session <NUM>. Without knowing the QoS requirements of the data traffic of the UE <NUM>, the <NUM>-RG <NUM> would be unable to perform the appropriate mapping. Rather, the <NUM>-RG <NUM> would blindly map the data traffic of the UE <NUM> into one of its QoS flows without knowing the QoS requirements of this data traffic. Therefore, it is very likely that the blindly mapped data traffic of the UE <NUM> would not receive the appropriate QoS handling as it goes through the PDU Session <NUM> of the <NUM>-RG <NUM> and thus it would not be possible for the PDU Session of the UE <NUM> to guarantee its assigned level of QoS.

<FIG> depicts one embodiment of a gateway apparatus <NUM> that may be used for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. The gateway apparatus <NUM> may be one embodiment of the <NUM>-RG <NUM>, and/or the <NUM>-RG <NUM>. Furthermore, gateway apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touch screen. In certain embodiments, the gateway apparatus <NUM> does not include any input device <NUM> and/or output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more remote units <NUM> and with one or more interworking functions <NUM> that provide access to one or more PLMNs Additionally, the transceiver <NUM> may support at least one network interface <NUM>. For example, the transceiver <NUM> may support a first interface that supports a first data connection with a <NUM> core network over a first access network, the first data connection supporting a plurality of QoS flows, and a second interface that communicates with a remote unit over a second access network.

The processor <NUM> is communicatively coupled to the memory <NUM>, the input device <NUM>, the output device <NUM>, and the first transceiver <NUM>.

In various embodiments, the processor <NUM> receives a first request over the second access network and determines whether a requested second data connection can be mapped into one of the plurality of QoS flows over the first data connection. Here, the first request contains a first set of parameters for establishing a second data connection with the remote unit over the second access network.

In some embodiments, the first access network and the second access network utilize different access technologies, wherein the processor <NUM> further converts the first set of parameters into the second set of parameters. In some embodiments, the data traffic relayed between the second data connection and the new QoS flow over the first data connection is the data traffic of a child IPsec security association established between the remote unit and an Interworking function in the <NUM> core network.

For example, in certain embodiments the first request may be an ADDTS request and the first set of parameters may contain a TCLAS parameter and a TSPEC parameter. In such embodiments, the processor <NUM> may determine whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection by comparing the TSPEC parameter with QoS parameters associated with each of the plurality of QoS flows over the first data connection. In one embodiment, the processor <NUM> further converts the TCLAS parameter into a Requested QoS Rules parameter and the TSPEC parameter into a Requested QoS Flow Description parameter, wherein the Requested QoS Rules parameter and the Requested QoS Flow Description parameter are contained in the second set of parameters.

The processor <NUM> sends a second request to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection, the second request containing a second set of parameters derived from the first set of parameters and relays the data traffic between the second data connection and the new QoS flow over the first data connection. Additionally, the processor <NUM> may relay the data traffic between the second data connection and an existing one of the plurality of QoS flows over the first data connection in response to determining that the second data connection can be mapped to the existing one of the plurality of QoS flows over the first data connection.

In some embodiments, the second request may contain a request to modify the first data connection by creating a new QoS flow that supports the second set of parameters. In certain embodiments, the first data connection may be a PDU Session, wherein the second request contains a PDU Session Modification Request. In some embodiments, the first request indicates QoS resources to reserve over the second access network. In such embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing the QoS resources to reserve over the second access network with QoS parameters associated with each of the plurality of QoS flows over the first data connection.

In some embodiments, the memory <NUM> stores data relating to modifying a data connection to support QoS requirements, for example storing TCLAS parameters, TSPEC parameters, parameter conversion tables, IPsec security associations, and the like. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on the gateway apparatus <NUM> and one or more software applications.

The output device <NUM>, in one embodiment, may include any known electronically controllable display or display device. The output device <NUM> may be designed to output visual, audible, and/or haptic signals. In some embodiments, the output device <NUM> includes an electronic display capable of outputting visual data to a user. As another, nonlimiting, example, the output device <NUM> may include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like.

In other embodiments, all or portions of the output device <NUM> may be located near the input device <NUM>.

As discussed above, the transceiver <NUM> may communicate with one or more remote units and/or with one or more interworking functions that provide access to one or more PLMNs. The transceiver <NUM> may also communicate with one or more network functions (e.g., in the mobile core network <NUM>). The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

The transceiver <NUM> may include one or more transmitters <NUM> and one or more receivers <NUM>. In certain embodiments, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share transceiver hardware and/or circuitry. For example, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. In one embodiment, the transceiver <NUM> implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

<FIG> depicts one embodiment of a user equipment apparatus <NUM> that may be used for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. The user equipment apparatus <NUM> may be one embodiment of the remote unit <NUM> and/or the gateway UE <NUM>. Furthermore, the user equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touch screen. In certain embodiments, the user equipment apparatus <NUM> does not include any input device <NUM> and/or output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF) and over a non-3GPP access network. Additionally, the transceiver <NUM> may support at least one network interface <NUM>. For example, when functioning as a gateway UE, the transceiver <NUM> may support a first interface that supports a first data connection with a <NUM> core network over a first access network, the first data connection supporting a plurality of QoS flows, and a second interface that communicates with a remote unit over a second access network.

In various embodiments, when functioning as a gateway UE, the processor <NUM> receives a first request over the second access network and determines whether a requested second data connection can be mapped into one of the plurality of QoS flows over the first data connection. Here, the first request contains a first set of parameters for establishing a second data connection with the remote unit over the second access network.

In some embodiments, the memory <NUM> stores data relating to modifying a data connection to support QoS requirements, for example storing TCLAS parameters, TSPEC parameters, parameter conversion tables, IPsec security associations, and the like. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on the user equipment apparatus <NUM> and one or more software applications.

As discussed above, the transceiver <NUM> communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

The transceiver <NUM> may include one or more transmitters <NUM> and one or more receivers <NUM>. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the user equipment apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. In one embodiment, the transceiver <NUM> includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

In various embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface <NUM> or other hardware components/circuits may be integrated with any number of transmitters <NUM> and/or receivers <NUM> into a single chip. In such embodiment, the transmitters <NUM> and receivers <NUM> may be logically configured as a transceiver <NUM> that uses one more common control signals or as modular transmitters <NUM> and receivers <NUM> implemented in the same hardware chip or in a multi-chip module.

<FIG> depicts a method <NUM> for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. In some embodiments, the method <NUM> is performed by a gateway device, such as the gateway UE <NUM>, the <NUM>-RG <NUM>, the <NUM>-RG <NUM>, the gateway apparatus <NUM>, and/or the user equipment apparatus <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and supports <NUM> a first data connection with a <NUM> core network over a first access network. Here, the first data connection supports a plurality of QoS flows.

The method <NUM> includes receiving <NUM> a first request over a second access network. Here, the first request contains a first set of parameters for establishing a second data connection with a remote unit over the second access network. In some embodiments, the first request indicates QoS resources to reserve over the second access network. In some embodiments, the first access network and the second access network utilize different access technologies, thus the first set of parameters may require conversion into the second set of parameters.

The method <NUM> includes determining <NUM> whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection. In certain embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing QoS resources to reserve over the second access network with QoS parameters associated with each of the plurality of QoS flows over the first data connection.

In certain embodiments, the first request is an ADDTS request and the first set of parameters includes a TCLAS parameter and a TSPEC parameter. In such embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing the TSPEC parameter with QoS parameters associated with each of the plurality of QoS flows over the first data connection.

The method <NUM> includes sending <NUM> a second request to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection. Here, the second request contains a second set of parameters derived from the first set of parameters.

In some embodiments, the second request contains a request to modify the first data connection by creating a new QoS flow that supports the second set of parameters. In such embodiments, the first data connection may be a PDU Session, wherein the second request contains a PDU Session Modification Request.

The method <NUM> includes relaying <NUM> the data traffic between the second data connection and the new QoS flow over the first data connection. In some embodiments, the data traffic that is relayed between the second data connection and the new QoS flow over the first data connection is the data traffic of a child IPsec security association established between the remote unit and an Interworking function in the <NUM> core network. The method <NUM> ends.

Disclosed herein is a first apparatus for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. The first apparatus may be implemented by a gateway device, such as the gateway UE <NUM>, the <NUM>-RG <NUM>, the <NUM>-RG <NUM>, the gateway apparatus <NUM>, and/or the user equipment apparatus <NUM>. The first apparatus includes a processor, a first interface that supports a first data connection with a <NUM> core network over a first access network, the first data connection supporting a plurality of QoS flows, and a second interface that communicates with a remote unit over a second access network. The processor receives a first request over the second access network, the first request containing a first set of parameters for establishing a second data connection with the remote unit over the second access network. The processor determines whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection. The processor sends a second request to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection, the second request containing a second set of parameters derived from the first set of parameters and relays the data traffic between the second data connection and the new QoS flow over the first data connection.

In some embodiments, the processor relays the data traffic between the second data connection and an existing one of the plurality of QoS flows over the first data connection in response to determining that the second data connection can be mapped to the existing one of the plurality of QoS flows over the first data connection.

In some embodiments, the second request contains a request to modify the first data connection by creating a new QoS flow that supports the second set of parameters. In such embodiments, the first data connection may be a PDU Session, wherein the second request contains a PDU Session Modification Request. In some embodiments, the first request indicates QoS resources to reserve over the second access network. In such embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing the QoS resources to reserve over the second access network with QoS parameters associated with each of the plurality of QoS flows over the first data connection.

In certain embodiments, the first request is an ADDTS request and the first set of parameters contains a TCLAS parameter and a TSPEC parameter. In such embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection may include comparing the TSPEC parameter with QoS parameters associated with each of the plurality of QoS flows over the first data connection. In one embodiment, the processor further converts the TCLAS parameter into a Requested QoS Rules parameter and the TSPEC parameter into a Requested QoS Flow Description parameter, wherein the Requested QoS Rules parameter and the Requested QoS Flow Description parameter are contained in the second set of parameters.

In some embodiments, the first access network and the second access network utilize different access technologies, wherein the processor further converts the first set of parameters into the second set of parameters. In some embodiments, the data traffic relayed between the second data connection and the new QoS flow over the first data connection is the data traffic of a child IPsec security association established between the remote unit and an Interworking function in the <NUM> core network.

Disclosed herein is a first method for modifying a data connection to support QoS requirements, according to embodiments of the disclosure. The first method may be performed by a gateway device, such as the gateway UE <NUM>, the <NUM>-RG <NUM>, the <NUM>-RG <NUM>, the gateway apparatus <NUM>, and/or the user equipment apparatus <NUM>. The first method includes supporting a first data connection with a <NUM> core network over a first access network, the first data connection supporting a plurality of QoS flows. The first method includes receiving a first request over a second access network, the first request containing a first set of parameters for establishing a second data connection with a remote unit over the second access network. The first method includes determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection. The first method includes sending a second request to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection, the second request containing a second set of parameters derived from the first set of parameters. The first method includes relaying the data traffic between the second data connection and the new QoS flow over the first data connection.

In some embodiments, the first method further includes relaying the data traffic between the second data connection and an existing one of the plurality of QoS flows over the first data connection in response to determining that the second data connection can be mapped to the existing one of the plurality of QoS flows over the first data connection.

In some embodiments, the first request includes QoS resources to reserve over the second access network. In certain embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing the QoS resources to reserve over the second access network with QoS parameters associated with each of the plurality of QoS flows over the first data connection.

In certain embodiments, the first request is an ADDTS request and the first set of parameters contains a TCLAS parameter and a TSPEC parameter. In such embodiments, determining whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection includes comparing the TSPEC parameter with QoS parameters associated with each of the plurality of QoS flows over the first data connection. In some embodiments, the first method may further include converting the TCLAS parameter into a Requested QoS Rules parameter and the TSPEC parameter into a Requested QoS Flow Description parameter, wherein the Requested QoS Rules parameter and the Requested QoS Flow Description parameter are contained in the second set of parameters.

In some embodiments, the first access network and the second access network utilize different access technologies. In such embodiments, the first method may further include converting the first set of parameters into the second set of parameters. In some embodiments, the data traffic relayed between the second data connection and the new QoS flow over the first data connection is the data traffic of a child IPsec security association established between the remote unit and an Interworking function in the <NUM> core network.

Claim 1:
An apparatus comprising:
a first interface configured to support that a first data connection (<NUM>) with a <NUM> core network (<NUM>) over a first access network, the first data connection supporting a plurality of quality of service, "QoS", flows;
a second interface configured to communicate with a remote unit (<NUM>) over a second access network; and
a processor (<NUM>) that is configured to:
receive a first request over the second access network, the first request containing a first set of parameters for establishing a second data connection with the remote unit (<NUM>) over the second access network;
determine (<NUM>) whether the second data connection can be mapped into one of the plurality of QoS flows over the first data connection;
send a second request (<NUM>) to establish a new QoS flow over the first data connection in response to determining that the second data connection cannot be mapped into one of the plurality of QoS flows over the first data connection, the second request containing a second set of parameters derived from the first set of parameters; and
relay the data traffic between the established second data connection and the new QoS flow over the first data connection.