Quality of service management for interworking between different communication architectures

Abstract

This document discusses quality of service management for interworking between different communication architectures, and specifically discusses processes, systems, and devices for addressing quality of service (QoS) during inter-system changes of wireless transmit / receive units (WTRUs). The WTRU may send a packet data unit (PDU) modification request to a network node, such as a session management function (SMF) device, indicating support for reflective quality of service (RQoS). In response to the modification request, the WTRU may then receive an acknowledgement, after which the WTRU may then be able to transmit data for the PDU having the particular RQoS. The RQoS may be specific to a single PDU or a plurality of PDUs. The modification request may include session management (SM) and / or mobility management (MM) information. The modification request may be included in an attach process or tracking area update (TAU).

Description

This application is a divisional application of Chinese patent application No. 202210238682.4, filed on January 8, 2018, entitled “Quality of Service Management for Intercommunication between Different Communication Architectures”, and Chinese patent application No. 202210238682.4 is a divisional application of Chinese patent application No. 201880006338.4, filed on January 8, 2018, entitled “Quality of Service Management for Intercommunication between Different Communication Architectures”, the contents of which are hereby introduced as reference. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 575,978, filed October 23, 2017, U.S. Provisional Application No. 62 / 572,160, filed October 13, 2017, and U.S. Provisional Application No. 62 / 444,124, filed January 9, 2017, the contents of which are incorporated herein by reference. Background Art

[0002] In wireless communication system architecture, the Evolved Packet Core (EPC) network is a framework for providing converged voice and data on LTE networks. As wireless standards evolve, EPC can be used in conjunction with other types of core networks to facilitate universal operation of wireless transmit / receive units (WTRUs). In 5G networks, the Next Generation Core (NGC) network can operate, but how it interoperates with existing networks needs to be addressed. Summary of the invention

[0003] Processes, systems and devices for addressing quality of service (QoS) during inter-system changes of a wireless transmit / receive unit (WTRU) are discussed herein. The WTRU may send a packet data unit (PDU) modification request to a network node such as a session management function (SMF) device, indicating support for reflective quality of service (RQoS). In response to the modification request, the WTRU may then receive an acknowledgment, after which the WTRU may be able to send data for the PDU with a specific RQoS. The RQoS may be specific to a single PDU or to multiple PDUs. The modification request may include session management (SM) and / or mobility management (MM) information. The modification request may be included in an attach procedure or a tracking area update (TAU). BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0005] Figure 1Ais a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0006] Figure 1B is a diagram showing the Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system as shown in;

[0007] Figure 1C is a diagram showing the Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown in;

[0008] Figure 1D is a diagram showing the Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown in;

[0009] Figure 2 is an exemplary architecture for interworking between an EPC and a next generation system according to one or more embodiments;

[0010] Figure 3 is an exemplary architecture for interworking between an EPC and a next generation system according to one or more embodiments;

[0011] Figure 4 is an example diagram of a bearer-based QoS model in an EPC according to one or more embodiments;

[0012] Figure 5 is an example diagram of a QoS model in the next generation according to one or more embodiments;

[0013] Figure 6 is an example process for a WTRU to transfer from one system to another in accordance with one or more embodiments;

[0014] Figure 7 is an example process for QoS rule generation for non-IP data using well-known data protocols according to one or more embodiments;

[0015] Figure 8 is an example process for QoS rule generation for non-IP data using a proprietary data protocol in accordance with one or more embodiments; and

[0016] Fig. 9 is an example process for addressing RQoS of one or more PDUs during an inter-system change. DETAILED DESCRIPTION

[0017] Figure 1A1 is a diagram showing an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0018] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. The CN may represent a next generation core (NGC) network, such as a 5G network using new radio (NR). Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated process chain environment), consumer electronic devices, and devices working on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0019] The communication system 100 may also include a base station 114a and / or a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, gNBs, NR Node Bs, site controllers, access points (APs), and wireless routers, among others. Although each base station 114a, 114b is depicted as a single component, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0020] The base station 114a may be part of the RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

[0021] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0022] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as new radio (NR) access, which may establish the air interface 116 using new radio (NR).

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access (e.g., using dual connectivity (DC) principles). Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN), among others.

[0027] Figure 1A The base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106 / 115.

[0028] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet Protocol Suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, wherein the one or more RANs may use the same RAT or a different RAT as the RAN 104 / 113.

[0030] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0031] Figure 1B is a system diagram showing an example WTRU 102. Figure 1B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

[0033] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in an embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In an embodiment, the transmit / receive component 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0034] Although in Figure 1B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0035] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0036] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memories that are not physically located in the WTRU 102, such as, for example, a server or a home computer (not shown).

[0037] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0038] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.

[0039] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0040] The WTRU 102 may include a full-duplex radio in which the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio. The full-duplex radio may include an interference management unit 139 that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0041] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0042] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0043] Each eNodeB 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0044] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing components is described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.

[0045] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0046] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

[0047] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0048] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or be in communication with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0049] Although in Figures 1A-1D Although the WTRU is described as a wireless terminal, it should be appreciated that in certain typical embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0050] In a typical embodiment, the other network 112 may be a WLAN.

[0051] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain typical embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0052] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set with the aid of signaling. The primary channel may be a working channel of the BSS and may be used by STAs to establish a connection with the AP. In certain typical embodiments, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a specified BSS, one STA (e.g., only one station) may transmit at any given time.

[0053] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).

[0054] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can separate the data into two streams. Inverse fast Fourier transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0055] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to certain typical embodiments, 802.11ah can support instrument type control / machine type communication (such as MTC devices in macro coverage areas). MTC can have certain capabilities, such as limited capabilities including support (for example, only support) certain and / or limited bandwidths. The MTC device may include a battery, and the battery life of the battery is higher than a threshold (for example, for maintaining a very long battery life).

[0056] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a certain STA, where the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because a STA (which only supports the 1MHz operating mode) transmits to the AP), then the entire available frequency band can be considered busy even if most of the frequency band remains idle and available for use.

[0057] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0058] Figure 1D1 is a system diagram showing the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0059] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit a plurality of component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0060] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0061] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0062] Each gNB 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, implement dual connectivity, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, and the like. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an X2 interface.

[0063] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. The AMF 182a, 182b, UPF 184a, 184b and SMF 183a, 183b may be the same or different types of devices, and the hardware of these devices may include processors, memories, transceivers and other data interfaces as needed. In one example, the AMF 182a, 182b, UPF 184a, 184b and SMF 183a, 183b hardware may be similar to the hardware of the WTRU as described herein. In another example, each of the AMF 182a, 182b, UPF 184a, 184b and SMF 183a, 183b may include more than one device. While each of the foregoing components is described as being part of CN 115, it should be appreciated that any of these components may be owned and / or operated by entities other than the CN operator.

[0064] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. The AMF 182a, 1823b may use network slicing processing to customize the CN support provided to the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) using other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0065] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and may configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0066] The UPF 184a, 184b can be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which can provide the WTRU 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRU 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchor processing, etc.

[0067] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via an N3 interface connected to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b and through the UPF 184a, 184b.

[0068] In view of Figures 1A-1D and about Figures 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0069] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0070] The one or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., tested) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (as an example, the circuits can include one or more antennas).

[0071] Figure 2 An example of an architecture for tight interworking of an Evolved Packet Core (EPC) network and a Next Generation (NG) Core (NGC) network is shown. Figure 2, a Home Subscriber Server (HSS) 202 may communicate with an NGC 204. An operator may deploy an NG RAN 208 (e.g., in conjunction with an EPC and upgraded for 5G New Radio (NR)), or "evolve" all installed E-UTRAN nodes 206 to support a new NGC 204. The NGC 204 may communicate with the "evolved" E-UTRAN 206 and the NG RAN 208 via N2 / N3 interfaces 222a and 222b, respectively. The NGC 204 may communicate with NGC WTRUs 205a and 205b via N1 connections 220a and 220b, respectively. In this example, service continuity to an NGC WTRU (e.g., 205a or 205b) is provided only between the "evolved" E-UTRAN 206 and the NG RAN 208 connected to the NGC 204. Furthermore, when E-UTRAN is "evolved" by supporting access to the NGC 20, interworking such as idle and connected mode mobility may be performed using NGC procedures.

[0072] Figure 3 An example of an architecture for interworking of EPC and NG CN is shown, where there is non-roaming and roaming with local breakout possibility. Figure 3In the example of , the operator of the EPC 310 has not yet upgraded the installed E-UTRAN node(s) 307, has upgraded or "evolved" some installed E-UTRAN node(s) 306 to support the new NGC 304 via N2 / N3 321a, or has deployed an E-UTRAN / NR 309 scenario (also referred to as "Option 3") for macro coverage with a standalone NR component connected to the NGC (e.g., for small cells). Option 3 309 may provide a dual connectivity deployment where E-UTRA may be the anchor radio access technology (RAT) and NR may be a secondary RAT connected to the EPC via an eNB. In addition, core network interworking between the EPC 310 and the NGC 304 may be provided for full service continuity. Interfaces Nx 324 and Ny 325 may be introduced between MME 313 and SGW 315, respectively, and an Nz 326 interface may be defined between SGW 315 and CP function 318 to enable interworking between EPC 310 and NGC 304. Nx 324 and Ny 325 may be inter-core network interfaces for c-plane and u-plane, respectively, and may correspond to inter-NGC interfaces. In addition, an N4 323 interface may be introduced between CP function 318 and UP function 316. If policy and charging are controlled in a dynamic manner, an NG point coordination function (PCF) 314 may be involved. The NG PCF 314 may be capable of supporting the functions of an evolved packet system (EPS) policy and rule change function (PCRF).

[0073] exist Figure 3 In the example of FIG. 1 , in a scenario connected to an E-UTRAN (e.g., 307 and / or 309), a WTRU such as an NGC WTRU 305c may use the EPC NAS 330a and 330b. In this scenario, when connected to the non-evolved E-UTRAN 307 and 309, WTRU authentication, mobility management, and session management may be performed by the MME 312 towards the NGC WTRU 305c.

[0074] Further in Figure 3In order to support idle or connected mode mobility between the EPC 310 and the NGC 304, the WTRU's serving MME 313 may be connected to the CP function 318 in the NGC 304 via a control plane Nx 324 interface, and the WTRU's serving SGW 314 may be connected to the UP function 316 via a user plane Ny 325 interface and to the CP function 318 via a control plane Nz 326 interface. The user plane may always be anchored in the NGC 304 for NGCWTRUs 305c with associated subscriptions. GW selection may be done by the MME 313 and may result in the selection of a GW in the NGC 304 based on the 5G-enabled WTRU subscription.

[0075] As discussed herein, to interwork with the NGC 304, the NGC WTRU 305c may perform an initial attach on the E-UTRAN 307 or 309 using the EPC NAS 330a or 330b, respectively, and later move to the Evolved E-UTRAN 306 or NG RAN 308 connected to the N1 320a and 320b (i.e., NG NAS) by interworking with the NGC 304 (e.g., moving the WTRU context from the EPC 310 to the NGC 304). During the initial attach, the WTRU user plane may be anchored in the UP function 318 provided by the NGC 304 to support mobility. Interworking with the NGC 304 may also be performed by having the NGC WTRU 305a and / or 305b perform an initial attach and session management on the “evolved” E-UTRAN 306 using N1 320a or on the NG RAN 308 using N1 320b, respectively. The NGC WTRU 305a and / or 305b may then move to the E-UTRAN 307 using the EPC NAS 330a and / or the E-UTRAN Option 3 309 using the EPC NAS 330b, respectively, by interworking with the NGC 304 (e.g., moving the WTRU 305a and / or 305b context from the NGC 304).

[0076] Service continuity can be provided between E-UTRAN and the NG RAN option deployed by the operator via interworking functions and common anchoring of the user plane.

[0077] Figure 4is an example of a QoS model based bearer in the EPC. The WTRU 402 may be connected to the eNB 404 via Uu 420. The eNB 404 may be connected to the S-GW 406 via an S1-U connection 422. The S-GW 406 may be connected to the PGW 408 via an S5 connection 424. The PGW 408 may be connected to a packet data network (PDN) 410 via an SGi 426 connection. The WTRU 402 may have a PDN connection 421 to the PDN 410 through the EPC.

[0078] In this example, packets with different QoS characteristics (e.g., QoS Class Identifier (QCI) values ​​in the EPC) are filtered to different end-to-end bearers between the WTRU 402 and the core network (e.g., PGW 408). There may be different flows, such as IP flows 410, 412, 414, 416, and 418. Figure 4 As shown, IP flows may require similar QoS treatment and may be grouped together, such as QoS x 413, which groups IP flows 412 and 414 together, or QoS y 417, which groups IP flows 416 and 418 together. IP flows that require similar QoS in the downlink are placed in dedicated bearers (DBs) that can meet the QoS requirements of the IP flows, such as, for example, where DB 432 can be associated with a QCI of QoS x 413, and DB 434 can be associated with a QCI of QoS y 417. Figure 4 In the example of , the default bearer 430 may be the first EPS bearer established simultaneously with the PDN connection; furthermore, it may be associated with some default QoS treatment. IP flows that do not require specific QoS treatment and can be satisfied with the default QoS treatment may be forwarded to the default bearer 430. A similar process (not shown) may occur in the uplink direction at the WTRU. The end-to-end QoS channel in the EPC may include an S5 424 channel between the PGW 406 and the SGW 408, and / or an S1-U channel 422 between the SGW 408 and the eNB 404. Further as Figure 4 As shown, for a packet flowing through a specific bearer or channel, it meets the same QoS treatment when flowing through these three channels (ie, S5, S1-U and Uu) between different nodes in uplink and downlink directions.

[0079] Figure 55 is an example of a user plane architecture for QoS management in an NG system. The architecture may include a WTRU 502 connected to a next generation RAN (NG RAN) 504 via an NG radio 520. The NG RAN 504 may be connected to a UP-GW 506 via an N3 interface 522. The UP-GW 506 may be connected to a data network (DN) 508 via an N6 interface 524. The DN 508 may have a PDU connection 521 to the WTRU 502 via the NGC.

[0080] exist Figure 5 In, with Figure 4 Differently, dedicated bearers may not be implemented in the NGC, but there may be a single channel (N3 interface) between the NG RAN 504 and the user plane gateway (UP-GW) 506, through which all packets flow. Packet marking as part of the packet header may be used to identify IP packets from the data network (DN) 508 that require different QoS treatment, such as flows 1, 2, and 4 with QoS x 410, QoS y 412, and QoS z 414, respectively. In this example, QoS x 410, QoS y 412, and QoS z 414 may be QoS requirements for varying levels / degrees of data contained in the IP packets of each flow. The marking is performed by the UP-GW 506 in the downlink direction and by the NG RAN 504 in the uplink direction. Based on the packet marking, the NG RAN 504 may decide to place the packet in a different dedicated radio bearer (DRB) once the packet (e.g., DRB 530, 531, and 533) is outside the NGC. Data with QoS x 410, QoS y 412, and QoS z 414 may be placed in DRBs 530, 531, and 533, respectively, where each DRB is assigned an IP data flow associated with one QoS. Each DRB may be created to meet QoS requirements for different IP flows, such as packet delay budget and / or packet error rate, etc.

[0081] In one embodiment, there may be procedures to ensure that interworking of QoS treatment between the EPC and the Next Generation system is maintained. In a scenario where the WTRU moves between an EPC system and a Next Generation system, the handover may be seamless in both the direction from the EPC to the Next Generation system and from the Next Generation system to the EPC so that service continuity may be maintained. If the handover is seamless, then the QoS treatment of a particular IP flow may be the same from the perspective of the application running on the WTRU. The procedures discussed here may ensure seamlessness when the WTRU moves between NG and EPC systems (and vice versa).

[0082] In one embodiment to address QoS interworking between NGC and EPC, the NG CP function (Fxn) (also referred to as NG-CP) may perform actions such as sending a new uplink traffic flow template (TFT) and / or packet filter to the WTRU. In an NG system, the packet filter may be sent to the WTRU by the RAN node, which means that there may be no packet filter at the NAS level. Upon switching to E-UTRAN, the CP-Fxn may need to send UL packet filters to the WTRU because the IP flows need to be separated into various dedicated bearers above the Packet Data Convergence Protocol (PDCP) level in the WTRU. The CP-Fxn may emulate N1 signaling between WTRUs by sending a Modify Bearer Request message to the WTRU. One or more pieces of information may be included in the TFT or in a message sent to the WTRU via N1.

[0083] In some embodiments, there may be a reflective QoS (RQoS) where a received flow / packet has a given QoS and in response to that flow / packet, the same QoS or a QoS based on the QoS of the received flow / packet would need to be used, thus being "reflected". In other words, for cases where RQoS is used, the QoS may not be pre-negotiated or pre-set with the node / participant transmitting the flow / packet, but may be reflected based on the QoS of the received flow / packet. Information included in the TFT or in the message sent to the WTRU via N1 may be an indication that the RQoS indication (RQI) is no longer applicable. The indication may be part of explicit control plane signaling, or the network may not include the RQI in the user plane packets (or packet headers) sent to the WTRU.

[0084] Information included in the TFT or in the message sent to the WTRU via N1 may also be a mapping between the QCI and a flow-based packet marking rule (e.g., a flow priority indicator (FPI), which may be sent to the WTRU by the CP-Fxn). The mapping may be a static mapping, e.g., for each QCI, there will be a corresponding FPI value. Alternatively, the network may send a dynamic mapping, where for each service, the FPI for that service corresponds to an appropriate (different) or the same QCI value. This concept may be applied to situations where the WTRU has multiple protocol data unit (PDU) connections for different services. In this case, the CP-Fxn may send a different QCI-FPI mapping for each PDU connection. The CP-Fxn may make the mapping determination based on PDU connection parameters (e.g., service type, slice type serving the PDU connection, WTRU capabilities, subscription information, and / or local policies).

[0085] The information included in the TFT or the message sent to the WTRU via N1 may also be packet marking information, which is determined by the NG based on intent-level rules for a specific application that may receive such information from an application server. Due to the bearer-based model, the intent-level rules may not be applicable to the EPC system, so if the intent-level rules apply to the IP flow, the CP-Fxn may take the following actions: notify the application server that the flow has been moved to the EPC system; request the application server or policy node to convert the intent-level QoS rules to the best possible transport-level QoS rules; Based on the actions described here, the CP-Fxn may receive the transport-level QoS rules, such as a specific FPI value, which may then be mapped to a QCI by the CP-Fxn, as previously described.

[0086] The NG CP-Fxn may also perform N2 signaling to the network (between the CP-Fxn and the RAN). The CP-Fxn may have or may derive QCI information based on the QoS characteristics of a particular PDU connection. The CP-Fxn may interact with a policy node and / or a user subscription database to determine the QCI value. In addition, the CP-Fxn may send a mapping between the QCI and the FPI (user plane marking) to the evolved eNB. The CP-Fxn may require this action because the user plane packets carried by the N3 path between the UP-GW and the eNB in ​​the downlink direction may still have the marking as part of the packet header. The eNB may need to have information to convert the packet marking information to the QCI, which may then be applied by the eNB to send the packet to the WTRU over the Uu interface through one or more data radio bearers (DRBs). In addition, the eNB may use this mapping information to mark packets received from the WTRU in the uplink direction and then send them to the UP-GW over the N3 path.

[0087] Additionally, in cases where there may be additional packet marking to specify the QCI value in the user plane packets, it may not be necessary to send the QCI to FPI mapping to the eNB as described herein, and the NG CP-Fxn may perform an N3 interface update.

[0088] Figure 6A process is shown that can be implemented using an embodiment of a network node in a 5G wireless communication system discussed herein, wherein a WTRU 608 is switched from a NG system to an EPC system. An FPI to QCI mapping may be retrieved 603 by the NG CP 602 from a policy server / Fxn. The NG CP 602 may then generate a UL TFT to enable the WTRU 608 to separate the 5G data flow into multiple dedicated bearers. The generated UL TFTs may each include an indication that the RQI may not be applicable to the EPC system. The NG CP 602 may send 605 the FPI to QCI mapping and the EPS bearer identifier to NG3 channel identifier mapping to the eNB 606. The NGCP 602 may then send 607 the generated UL TFT and FPI to QCI mapping information to the WTRU 608. The NG CP 602 may then send 609 a message to the application server / Fxn 610 indicating that the 5G data flow has been switched to the EPC system.

[0089] In one embodiment to address QoS interworking between NG and EPC, the MME may perform actions upon handover to the EPC, such as triggering a network initiated Modify Bearer Request (MBR) or Create Bearer Request (CBR) procedure to establish a dedicated bearer for a different FPI value. Alternatively or additionally, the MME may receive an authorized FPI value for a PDU connection active at the WTRU, which means that the MME may have to convert that FPI value to a QCI value. The MME may interact with the PCF and / or HSS to determine the conversion of the FPI value to the QCI value.

[0090] In one embodiment to address QoS interworking between NG and EPC, the WTRU may perform a Tracking Area Update (TAU) for idle mode mobility scenarios. Alternatively, the WTRU may perform a registration update when it moves from the NG system to the EPC system. In the case of either action, for example, when the WTRU communicates with the MME after moving to the EPC system, such as in Figure 3 As may be possible in the example of , the WTRU may include certain information in the TAU request or in other NAS messages provided to the MME. Such information may include one or more of the following: a pre-authorized FPI (the FPI value authorized by CP-Fxn at PDU session establishment); other FPI values, such as an FPI value used by the WTRU for a particular PDU connection in addition to the pre-authorized value (e.g., the WTRU has requested additional QoS support for IP flows during an ongoing PDU connection); and / or an indication of whether RQoS is applied accordingly to the authorized FPI value.

[0091] In one embodiment to address QoS interworking between NG and EPC, the WTRU may perform a Modify Bearer Request procedure to establish a dedicated bearer in the EPC system. The Modify Bearer procedure may be performed for each active PDU session. Dedicated bearers may then be established by the MME for different authorized FPI values.

[0092] In one embodiment that addresses QoS interworking between NG and EPC, the actions taken by the network as described herein may be a result of actions taken by the WTRU for QoS management.

[0093] QoS processing in an EPC or NG system may be flow-specific, where before a traffic flow can be associated with certain QoS profiles, it may be necessary to detect and identify it. For IP data flows, traffic flow detection can be relatively straightforward because IP tuples can be conveniently used to form traffic flow templates (TFTs) or packet filters. However, non-IP data flows may be handled differently from IP data flows. Non-IP data may be carried in a PDU session different from an IP-based PDU session, and / or there may not be mixed IP data flows and / or non-IP data flows in a single PDU session. In addition, in a non-IP PDU session, there may be multiple non-IP data flows. In one or more embodiments, processes and rules may be developed to perform differentiated QoS processing, which may be required for multiple non-IP data flows within a PDU session. These rules and processes may involve non-IP traffic detection and identification. In addition, in the case of reflection rules, the WTRU may need to identify the UL data received from its non-IP application as a relative portion of the received DL data, so the WTRU may apply the same QoS marking as received from the DL data.

[0094] In one embodiment for addressing QoS processing of non-IP data streams, each non-IP data stream may have a data header of a specific format. For example, there may be several types of non-IP data header formats: 1) One type of header format may be standardized, and in the header, there is at least one pair of information elements that may be reversed for UL and DL (e.g., an Ethernet (802.3) or WLAN MAC (802.11) packet has a pair of "source address" and "destination address" in the header; 2) Another type of header format may be standardized, but there may not be a pair of information elements that are reversed for UL and DL; 3) Another type of header format may not be standardized, or may be standardized only in a certain industry / application.

[0095] For the third example type of non-IP data format, these header formats may be less well known and may be proprietary. For the first and second example types of non-IP data formats, these header formats may be standardized and / or known, but if there are other non-IP data streams of different data formats mixed within the same PDU session, they may still be difficult to detect because there is no unique "signature" information element in the header that can clearly point to a specific data format.

[0096] Figure 7 An example process for QoS rule generation or application for non-IP data using a known data protocol is shown. In one embodiment, the WTRU 704 may receive 720 explicit information of the data protocol used in a communication request from a non-IP data application 702. Such information may include the name of the data protocol (e.g., "802.3" or "Ethernet"), the version number, and other relevant information. The WTRU 704 may include the data protocol information in a PDU Session Establishment Request message sent 721 to the SMF 706 in the NGC. If the NGC supports the requested data protocol, it may confirm the PDU session establishment, otherwise it may reject the request.

[0097] The SMF 706 handling the non-IP PDU session may be configured with default QoS rules and it may apply the default QoS rules to some or all non-IP data flows in the non-IP PDU session using the same data protocol. For those non-IP data flows to which the default QoS rules are applied, traffic templates or packet filters for traffic detection may not be required. The SMF 706 may also request 722 the default QoS rules for the non-IP PDU session from a policy function 710 in the NGC, which may respond 723 back to the SMF 706 with the default rules. The SMF 706 may provide 724 the same default QoS rules to the WTRU 704 during the PDU session establishment procedure.

[0098] For some non-IP data flows 725 from non-IP servers 712, the SMF 706 can also receive 727 QoS rules that include traffic detection information generated 726 by the policy function, which is similar to the traditional EPC QoS policy framework. Once the SMF 706 receives the QoS rules, it can send them to the UP-GW 708 for installation. The traffic detection information can be specific to the non-IP data protocol used by the PDU session. For example, if the Ethernet data format is used, the source MAC address and the destination MAC address can be used as part of the TFT. If the UL TFT can also be derived, which may be the case if there is a pair of reversible information elements (such as source and destination addresses) available, the SMF 706 can build UL non-IP TFTs for some non-IP data flows and provide them 729 to the WTRU in the session management process (e.g., QoS rule update).

[0099] If the WTRU receives an application data request from another non-IP application that requires a different data protocol, it may initiate the establishment of a separate PDU session for the different data protocol.

[0100] When the WTRU receives non-IP data from an application, the data may be accompanied by a data protocol indication and the WTRU may use this information to map the data to the corresponding non-IP PDU session previously created. If UL QoS rules are available for the data flow, the WTRU may use traffic detection rules to detect the data and apply the associated QoS profile (e.g., insert a QoS tag in the UL data), otherwise the WTRU may use default QoS rules (if available).

[0101] RQoS processing is also possible if a pair of reversible information elements are present in the header.

[0102] Figure 8 An example process for generating QoS rules for non-IP data using a proprietary data protocol is shown. In one embodiment, if the data protocol used by the non-IP application is not standardized or known, some unique "signature information" can be carried in the data header, and the NGC can use this signature information to generate non-IP traffic detection rules, thereby being able to provide QoS rules for this non-IP data flow. An example of signature information carried in a non-IP data header may be a specially encoded flag octet or octets, such as "0x0FAF" in the first two octets of the header, which can identify a non-IP application. Another example of signature information carried in a non-IP data header may be an encoded service ID or application ID in the header.

[0103] exist Figure 8804, the WTRU 802 may send a PDU setup request 820 to the SMF 804, where the PDU type is non-IP. The SMF 804 may send a PDU setup response 821 to the WTRU 802 using default QoS rules that the SMF 804 may have been pre-configured 822 with. These default rules may be a set of traffic detection rules for non-IP applications, and each rule may include one or more of the following information: 1) signature information that should be carried in the data header (e.g., "0x0FAF"); 2) the location of the header information in the header (e.g., the first and second octets of the header); 3) the length of the header. When establishing a PDU session for non-IP applications, the SMF 804 may also install 823 these traffic detection rules in the corresponding UP-GW or UP traffic detection function 806. The default QoS profile associated with each traffic detection rule may also be configured in the SMF 804 and installed in the UP function. The QoS profile may be a set of QoS parameters, such as 5QI, or Allocation and Reservation Policy (ARP), etc. QoS rules may be used to identify which QoS flow a service flow belongs to, and may have a packet filter to map the service flow to obtain a QoS flow ID. A QoS flow ID may be associated with a standard or non-standard QoS profile.

[0104] The UP-GW or traffic detection function 806 may generate a traffic detection event 825 to the SMF 804 when a certain non-IP data flow 824 from a non-IP server 810 is detected according to the installed detection rules. If there is no default QoS profile for the detected non-IP data flow at the UP-GW or traffic detection function 806, the SMF 804 may generate 826 the corresponding QoS profile itself when non-IP traffic is detected, or retrieve it from the policy function and then provide it to the UP-GW or traffic detection function 806 for installation 827.

[0105] The SMF 804 may provide 828 the same traffic detection rules and associated QoS profile 828 to the WTRU so that the WTRU may use them for UL QoS rules.

[0106] RQoS treatment is also possible for this type of non-IP data. Because the UL data and DL data carry the same signature information, the WTRU may be able to directly use the DL QoS marking for the UL data carrying the same signature information as long as the WTRU is provided with traffic detection rules on where to find the signature information.

[0107] In one embodiment, the use of RQoS may be dependent on an indication from the WTRU, although the network may still decide not to apply RQoS. In the case where the WTRU is started up in a network with RQoS enabled, the WTRU may indicate (i.e., indicate to the SMF) its support for RQoS during the PDU Session Establishment. However, if the PDU Establishment procedure is not performed (e.g., in the case where the WTRU is actually started up in an EPC that does not support RQoS), the WTRU may not be able to indicate support for RQoS. For example, a WTRU may have multi-RAT technologies, such as E-UTRAN and 5G NR, and may first register with the EPC. The WTRU may have at least one PDU Session in the EPC, but may not be able to indicate support for RQoS because RQoS may not be supported in the EPC. Later, the WTRU may move and may experience an inter-system change to a 5G CN, where the WTRU's PDU connection(s) will be moved to a 5G system that supports RQoS, but, because the connection has already been created in the EPC and is now switched to the NGC of 5G, the WTRU may not have the opportunity to indicate its support for RQoS in the NGC because the PDU Establishment procedure has already been performed in the EPC. Thus, the network may not be able to use RQoS for the WTRU until the WTRU establishes a new PDU Session for which an RQoS indication may be sent. The embodiments and processes described herein may address the above scenario to enable the WTRU to send an indication to enable RQoS to be used for a PDU Session that was already activated in a previous system associated with an inter-system change.

[0108] Additionally, the embodiments and processes discussed herein may also be applicable to address other features beyond RQoS during inter-system changes, such as a capability or action that is supported in one system but not supported in a second system to which the WTRU is transitioning or from. For example, these techniques may also be applied to situations where a WTRU supports features that are only available in LTE or EPC, but the WTRU is first started in a 5G NGC system.

[0109] In one example, the WTRU may have a policy or may be configured with information that allows it to determine for which PDU sessions (e.g., based on APN or DDN) the WTRU supports RQoS. The indication of RQoS may be based on the WTRU supporting RQoS, or the support may be indicated for a specific PDU session; the embodiments discussed herein may apply to both.

[0110] When the WTRU registers with the EPC system, the WTRU may send an indication of its RQoS support. This indication may be sent in a mobility management message or a session management message, or both. For mobility management messages, the WTRU may send this indication (or other indications for other NGC features or capabilities) in all NAS messages, not just in the registration message.

[0111] For a WTRU attach or register (due to an existing trigger of a registration message, or due to an inter-system change from, for example, NGC to EPC), the WTRU may include this indication in the registration message (e.g., Attach Request or Tracking Area Update Request). Note that the latter may be due to a periodic registration. Alternatively, the WTRU may also send this indication in a session management message, which may be sent independently or piggybacked in a mobility management message (e.g., Attach Request).

[0112] The WTRU may indicate its support for RQoS using a specific information element (IE) or bit where a value of 1 indicates "RQoS supported" and a value of zero indicates "RQoS not supported" or vice versa. Alternatively, a set of bits (e.g., at least one octet) may be used to indicate support for at least one feature such as RQoS. Each bit position may correspond to a feature or support for a specific operation or capability (e.g., RQoS). The WTRU may include any of these indications in a mobility management or session management message.

[0113] Alternatively, all of the indications presented above (e.g., indications for RQoS, etc.) may be included in a container that is stored and transparently passed to the NGC (e.g., access and mobility management function (AMF)) during inter-system changes. The container may include mobility management or session management related information, such as capabilities at the mobility management or session management level. In addition, the WTRU may send such information in separate mobility management containers and session management containers, each of which has capability or feature support information related to mobility management and session management, procedures / features in the 5G system (or, in the case where the WTRU is first in the 5G system, procedures / features for the LTE system). The container may be referred to as a "UE CN Transparent Container" (UCTC) and may contain information for mobility management and session management, or there may be two separate containers for each mobility management and session management. The WTRU may send the container or information in a mobility management or session management message.

[0114] Alternatively, the WTRU may include its support and desire to use RQoS in a Protocol Configuration Options (PCO) IE sent in a session management message (e.g., PDN Connection Request) or a mobility management message. This may be an RQoS indication for all PDU connections, for each PDU connection, or for each Access Point Name (APN) / Data Network Name (DNN). For example, during PDN connection establishment in the EPC, the WTRU may include a new indication for RQoS in the PCO or in an extended PCO (ePCO). New values ​​for the RQoS indication in the (e)PCO may be defined for both cases. When the WTRU sends the (e)PCO to the network, and when the network responds back to the WTRU, it may also include the RQoS indication in the (e)PCO contained in a NAS message to the WTRU.

[0115] The MME may optionally receive a NAS message from the WTRU with a new indication of the support or RQoS. The MME may save this information and send it to the SGW / PGW-C. The MME may use the new indication on the interface between the MME and the SGW / PGW-C to reflect the WTRU's support for RQoS, or it may send the same indication to the SGW / PGW-C (e.g., in a PCO or ePCO). The PGW-C may also be assumed to be a SMF, or it may support the functionality of the SMF. In addition, the MME may first verify against local policy or subscription information to determine whether the use of RQoS for the WTRU in question is allowed, for example in a 5G system. If the verification is successful, the MME may forward the indication to the SGW / PGW-C.

[0116] The MME may also store the received RQoS information in the WTRU context and then forward the RQoS capabilities to the AMF (e.g. as part of the session management context) when changing between systems. The AMF may then send this capability to one or more SMF / PGW-Cs during handover from EPS to the 5G system.

[0117] The PGW-C may receive a message associated with the WTRU, for example from the SGW / MME, and the message may indicate that the WTRU supports RQoS. The indication may be a new indication on the S11 / S5-C interface, or may be included in the PCO or ePCO. The SGW / PGW-C may verify (e.g., using local policy or subscription information) whether the WTRU is allowed to use RQoS, for example, in the 5G system. If the verification is successful, the SGW / PGW-C may save this information in the context of the WTRU. The PGW-C / SGW may send (e.g., in a response message to the SGW / MME) a ​​new indication (e.g., in the form of a new value in the PCO or ePCO), which indicates that the WTRU is allowed to use RQoS, for example, in the 5G system. The MME may receive an indication from another network node (e.g., the SGW / PGW-C), indicating that the WTRU is allowed to use RQoS. The MME / SGW may save this information in the context of the WTRU. The SGW may forward the indication to the MME. The MME may forward the indication to the WTRU in a mobility management or session management message. The MME may use the new indication in the NAS message, or it may include the indication in the PCO or ePCO optionally received from the SGW / PGW-C.

[0118] When the WTRU performs an inter-system change to a target system, the WTRU may receive an indication in a NAS mobility management or session management message that the use of RQoS is supported / allowed (optionally for a target system such as 5G). The WTRU may save this information and use it as a trigger to include an indication of support for RQoS when it performs an inter-system change to a target system (e.g., a 5G system).

[0119] Fig. 9An example of a WTRU process for enabling RQoS for one or more PDUs after an inter-system change is shown. When performing an inter-system change to a target system (e.g., a 5G system), the WTRU 902 may include an indication of support or desire to use the RQoS feature. The WTRU may communicate with a network node 904 of the target system (e.g., a 5G system). The network node 904 may be any node in the NGC that is directly or indirectly reached, such as a gNB, AMF, SMF, or UPF. The WTRU 902 may include the indication in a NAS mobility management message or a session management message or both. The WTRU 902 may include the indication as a new IE or a new value in a PCO or ePCO IE. The WTRU may send a PDU modification request 910 to notify the 5G system that it wants to use RQoS for one or more PDU sessions that have been established in a previous system (e.g., EPC), or that it supports the use of RQoS for these sessions. The WTRU may perform the PDU session modification procedure for all or a subset of the PDU sessions of the NGC that are transferred from the EPC to the 5G system. Alternatively, the WTRU 902 may include the message in any NAS session management message (e.g., when the NAS session management message is a PDU connection request (e.g., a registration request) with a type set to "handover". The WTRU 902 may include the indication for each PDU session registration request for which it wants to handover from a source system (e.g., from the EPC) to a target system (e.g., to the NGC). In one example, the indication may have been included if the WTRU 902 had sent an RQoS indication for the same PDU while the WTRU 902 was in the source system (e.g., EPC), such as when the WTRU 902 received an acknowledgment from the source system (e.g., EPC) that RQoS for the target system (e.g., NGC) was allowed, as discussed herein. Upon receiving the indication at the network node 904 of the target system, the network node 904 may respond with an acknowledgment (ACK) 912 regarding the indication. After the WTRU 902 receives the ACK 912, it may continue to send PDUs with a specific RQoS 914. Alternatively, the WTRU 902 may not require an ACK, and the WTRU 902 may start sending PDUs with a specific RQoS after the inter-system change is completed.

[0120] Alternatively, the WTRU may be configured to deactivate and reactivate its PDU session so that it may include an RQoS support indication when it performs an inter-system change from a source system (e.g., EPC) to a target system (e.g., NGC).

[0121] When making an inter-system change to an NGC, the WTRU may include an indication in the NAS mobility management and / or session management messages that it desires or supports the use of RQoS, and it may do so for all PDU Sessions that need to be transferred to the NGC, or regardless of all PDU Sessions that need to be transferred. The NGC (e.g., AMF, SMF, or both) may verify local policy or subscription information to determine whether the WTRU is allowed to do so. The SMF or AMF, or both, may respond to the WTRU and indicate whether the use of RQoS is allowed or not (e.g., for each PDU Session).

[0122] For a WTRU that has performed an inter-system change from EPC to NGC, the AMF may request context information from the MME. The MME may forward any indication of use or support of RQoS that may have been received from the WTRU when the WTRU was in the EPC.

[0123] In one embodiment, there may be an indication of Network Slice Selection Assistance Information (S-NSSAI) for EPC-NGC intercommunication. In LTE releases, there may be no concept of network slices; therefore, when a PDN connection is established in the EPC, it may not be associated with a specific slice. However, during an inter-system change from EPC to NGC, the same PDN connection may be transferred to the NGC. Since a PDU session in the NGC may be associated with a specific network slice, when a PDN connection from LTE is switched to the NGC, the WTRU may need to have knowledge of the slice associated with the NGC PDU session. There may be a process for notifying the WTRU of the slice corresponding to the PDU session originally established in the EPC system.

[0124] In an example showing S-NSSAI indication when interworking with EPC and NGC, the WTRU may include one or more S-NSSAI information in the Protocol Configuration Options (PCO) portion of the PDN Connection Request NAS message in the EPC, for example based on the (Network Slice Selection Policy) NSSP configured on the WTRU. As previously described, the PCO portion of the message may be transparent to the MME, so during the PDN connection establishment process, the S-NSSAI information may be stored in the PGW-C / SMF node of the EPC. The WTRU may receive the selected S-NSSAI in the PCO of the PDN Connection Accept message from the EPC. Note that the EPC network may send the S-NSSAI in the PDN Connection Accept message even if the WTRU does not include this information in the PDN Connection Request message. In any case, the PGW-C / SMF may check local policies, WTRU subscriptions and / or interact with other network nodes (e.g., NSSF, HSS / UDM) to select the S-NSSAI for the PDN connection. The selected S-NSSAI may then be returned to the WTRU in the PDN Connection Accept message.

[0125] In another example, the SMF / PGW-C may not send S-NSSAI information to the WTRU during the PDN connection process in LTE. The SMF / PGW-C may store the S-NSSAI information (if received by the WTRU in the PCO). The SMF / PGW-C may then send the stored S-NSSAI value to the AMF during an inter-system change (e.g., EPC to NGC handover or EPC to NGC idle mode mobility). If multiple PDN connections are transferred to the NGC, the SMF (one or more) corresponding to each PDU session may send the S-NSSAI information to the AMF during the inter-system change. Based on the allowed NSSAI and / or local policy, the AMF may determine the S-NSSAI associated with the PDU session. The AMF may then return the determined S-NSSAI to each SMF. The SMF may then store this information in the PDU session context or the WTRU SM context. Alternatively, when the AMF receives the SMF / PGW-C address during an inter-system change, the AMF may determine the S-NSSAI for each active PDU session based on the SMF information and / or the allowed NSSAI. The AMF may then send the S-NSSAI to the SMF corresponding to each PDU session.

[0126] Each SMF may trigger a network initiated PDU Session Modification procedure when the SMF receives an S-NSSAI associated with a PDU Session transferred from the EPC. The PDU Modification message to the WTRU may include the S-NSSAI for the corresponding PDU Session.

[0127] When the WTRU receives an allowed NSSAI after a registration update procedure in an NGC when changing between systems, the WTRU may also determine that the PDU Session in the NGC is not associated with an S-NSSAI. Therefore, the WTRU may send the S-NSSAI to the network (e.g., AMF and SMF) by triggering a PDU Session Modification procedure for each PDU Session transferred from the EPC to the NGC.

[0128] Although the features and elements are described above in particular combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with the other features and elements. In addition, the above method may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for handling quality of service (QoS) during an inter-system change, the method comprising: providing a modification message, the modification message including information associating at least one service flow associated with a 5G system (5GS) network to a bearer associated with an evolved packet system (EPS) network, wherein the information indicates a mapping of the at least one service flow associated with the 5GS network to a QoS class identifier (QCI) corresponding to the bearer associated with the EPS network, and the information further indicates one or more service flow templates (TFTs) and one or more packet filters to be applied upon the inter-system change from the 5GS network to the EPS network; and Data associated with the at least one service flow is received in the EPS via the bearer corresponding to the QCI based on the one or more TFTs and the one or more packet filters.

2. The method according to claim 1, wherein: The data is part of a PDU session.

3. The method according to claim 1, wherein: The inter-system change is part of a request that includes one or more of: a session management (SM), a mobility management (MM), or a tracking area update (TAU) message. The method of claim 1 , wherein the QCI indicates a specific QoS for the data.

5. The method of claim 1, wherein a PDU session with the 5GS network is established before the inter-system change.

6. The method according to claim 1, wherein: The modification message is provided by a session management function (SMF).

7. The method of claim 1, wherein the received data is provided by a wireless transmit / receive unit (WTRU).

8. A network node for handling quality of service (QoS) during an inter-system change, the WTRU comprising: a transceiver configured to provide a modification message, the modification message comprising information associating at least one traffic flow associated with a 5G system (5GS) network to a bearer associated with an evolved packet system (EPS) network, wherein the information indicates a mapping of the at least one traffic flow associated with the 5GS network to a quality of service class identifier (QCI) corresponding to the bearer associated with the EPS network, the information further indicating one or more traffic flow templates (TFTs) and one or more packet filters to be applied upon the inter-system change from the 5GS to the EPS network; as well as The transceiver is configured to receive data associated with the at least one service flow in the EPS via the bearer corresponding to the QCI according to the one or more TFTs and the one or more packet filters.

9. The network node according to claim 8, wherein: The data is part of a PDU session.

10. The network node of claim 8, wherein the inter-system change is part of a request comprising one or more of: a session management (SM), a mobility management (MM), or a tracking area update (TAU) message.

11. The network node of claim 8, wherein the QCI indicates a specific QoS for the data.

12. The network node of claim 8, wherein a PDU session with the 5GS network is established before the inter-system change.

13. The network node according to claim 8, wherein: The network node comprises a session management function (SMF).

14. The network node of claim 8, wherein the received data is provided by a wireless transmit / receive unit (WTRU).

15. At least one non-transitory computer-readable storage medium having executable instructions stored thereon that, when executed by a network node, cause the network node to: providing a modification message, the modification message including information associating at least one service flow associated with a 5G system (5GS) network to a bearer associated with an evolved packet system (EPS) network, wherein the information indicates a mapping of the at least one service flow associated with the 5GS network to a QoS class identifier (QCI) corresponding to the bearer associated with the EPS network, the information further indicating one or more service flow templates (TFTs) and one or more packet filters to be applied upon the inter-system change from the 5GS network to the EPS network; and Data associated with the at least one service flow is received in the EPS via the bearer corresponding to the QCI based on the one or more TFTs and the one or more packet filters.

16. The at least one non-transitory computer-readable storage medium of claim 15, wherein: The data is part of a PDU session.

17. The at least one non-transitory computer-readable storage medium of claim 15, wherein: The inter-system change is part of a request that includes one or more of: a session management (SM), a mobility management (MM), or a tracking area update (TAU) message.

18. The at least one non-transitory computer-readable storage medium of claim 15, wherein: The QCI indicates a specific QoS to be used for the data.

19. The at least one non-transitory computer-readable storage medium of claim 15, wherein: Prior to the inter-system change, a PDU session with the 5GS network is established.

20. The at least one non-transitory computer-readable storage medium of claim 15, wherein: The network node comprises a session management function (SMF).

Images