WO2018145103A1

WO2018145103A1 - Methods for qos management for 5g networks

Info

Publication number: WO2018145103A1
Application number: PCT/US2018/017089
Authority: WO
Inventors: Guanzhou Wang; Saad Ahmad
Original assignee: Idac Holdings, Inc.
Priority date: 2017-02-06
Filing date: 2018-02-06
Publication date: 2018-08-09

Abstract

A wireless transmit/receive unit (WTRU) may receive first user plane (UP) downlink (DL) data from a network. The first UP DL data may include an indication to initiate reflective quality of service (QoS) and a first QoS marking. The WTRU may transmit UP uplink (UL) data to the network using one or more QoS rules derived from the indication to initiate reflective QoS and the first QoS marking. Additionally, the WTRU may receive second UP DL data from the network. The second UP DL data may include an indication to deactivate reflective QoS and the QoS first marking. The WTRU may deactivate the one or more QoS rules based on the indication to deactivate reflective QoS and the second QoS marking. The WTRU may apply another QoS rule for upcoming transmissions of UP UL data.

Description

METHODS FOR QOS MANAGEMENT FOR 5G NETWORKS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/455,351 filed on February 6, 2017, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] In a Long-Term Evolution (LTE) Network, Quality of Service (QoS) is implemented between wireless transmit/receive units (WTRUs) and a Packet Data Network (PDN) Gateway. The QoS may be applied to one or more bearers. A bearer with QoS applied may be a set of network configurations that can provide special treatment to a certain type of traffic, such as Voice over Internet Protocol (VoIP) packets, so that that it is prioritized by network compared to other types of traffic (e.g., web browser traffic).

[0003] Subscribers may be willing to pay more for higher bandwidth and better network access on their devices. Network operators may wish to throttle data usage by certain users. In addition, some services, such as VoIP calls, may require better priority handling in the network. QoS may play a role to be able to fulfill this priority handling. It may be desirable to further develop the QoS mechanism for 5G/NextGen networks.

SUMMARY

[0004] Methods, apparatuses, and systems are disclosed for quality of service (QoS) management in Fifth Generation (5G) networks. A wireless transmit/receive unit (WTRU) may receive first user plane (UP) downlink (DL) data from a network. The first UP DL data may include an indication to initiate reflective quality of service (QoS) and a first QoS marking. The WTRU may transmit UP uplink (UL) data to the network using one or more QoS rules derived from the indication to initiate reflective QoS and the first QoS marking. Additionally, the WTRU may receive second UP DL data from the network. The second UP DL data may include an indication to deactivate reflective QoS and the QoS first marking. The WTRU may deactivate the one or more QoS rules based on the indication to deactivate reflective QoS and the second QoS marking. The WTRU may apply another QoS rule for upcoming transmissions of UP UL data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein: [0006] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0007] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit

(WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0009] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 2 is a system diagram of a Fifth Generation/Next Generation (5G/NextGen) network;

[0011] FIG. 3 is a flow diagram illustrating a process in which a WTRU reports that reflective quality of service (QoS) is not available or supported after disappearance of a reflective QoS indicator (RQI) in downlink (DL) data;

[0012] FIG. 4 is a flow diagram illustrating triggering a priory change between a pre- authorized QoS rule and a reflective QoS rule;

[0013] FIG. 5 is a flow diagram illustrating using an explicit reflective QoS deactivation indication in user plane (UP) packets to deactivate/remove a reflective QoS rule;

[0014] FIG. 6 is a flow diagram illustrating reporting current QoS flow information to a target radio access network (RAN) by the WTRU; and

[0015] FIG. 7 is a flow diagram illustrating a WTRU reporting stored configuration of mapping between QoS flow and data radio bearer (DRBs) of a previously connected RAN when returning to the RAN.

DETAILED DESCRIPTION

[0016] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ 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, filter bank multicarrier (FBMC), and the like.

[0017] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and/or a "STA", 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 telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0018] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0019] The base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. 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, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the 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, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

[0020] 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).

[0021] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. 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 establish the air interface 115/116/117 using wideband CDMA (WCDMA). 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).

[0022] 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 LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

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

[0024] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by 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., a eNB and a gNB).

[0025] 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 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-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), GSM EDGE (GERAN), and the like.

[0026] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115.

[0027] 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 of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, 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 as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. [0028] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c,

102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), 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 communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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). For example, the WTRU 102c shown in FIG. 1A 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.

[0030] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG.

1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 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, among others. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0031] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, 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. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0033] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

[0035] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), 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, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0036] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the 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 (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like. [0037] 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) regarding 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0038] The processor 118 may further be coupled to other peripherals 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 peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

[0039] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0040] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106. [0041] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each 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, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0042] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell

(not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0043] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME)

162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0044] 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, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may 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.

[0045] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the

RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0046] 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.

[0047] 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 may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves 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 the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0048] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0049] In representative embodiments, the other network 112 may be a WLAN.

[0050] A WLAN in 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 have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer- to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.

[0051] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS. [0052] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0053] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or

160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0054] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 η, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0055] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 η, 802.11ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0056] In the United States, the available frequency bands, which may be used by

802.11ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0057] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0058] 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 an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating 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, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, 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 multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).

[0060] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0062] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b,

180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 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, services for machine type communication (MTC) access, and/or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

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

[0065] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b,

180c in the RAN 113 via an N3 interface, 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. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi- homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0066] 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 serves 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 the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0067] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0068] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.

[0069] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0070] In the following description, a core network (CN), which also may be referred to as a network (NW), may receive capability information indicating whether a RAN supports reflective Quality of Service (QoS). This capability information may be transmitted either directly from the RAN or the WTRU and received by the network. In the latter case, the WTRU may derive the capability information by observing a change of a reflective QoS indication (RQI) in downlink (DL) user plane (UP) packets received from the RAN, and report the capability information to the network.

[0071] Further, dynamic priority switching between a pre-authorized QoS rule and a reflective QoS rule is described. One or more events may trigger a switching of priority between a pre-authorized QoS rule and a reflective QoS rule. An example event may include determining which rule has changed most recently and giving that rule a higher priority. Another example event may include explicit signaling (i.e., a signaling between a WTRU and a control plane (CP) function) to control the priorities. Another example event may include an explicit reflective QoS Deactivation flag in downlink (DL) user plane (UP) packets that deactivates the reflective QoS rule. Further, another example event may be a timer controlled priority change in which a timer corresponding to a specific rule expires and the priority of the specific rule is downgraded.

[0072] The following description may also include a WTRU configured to report QoS flow information, including a QoS flow - data radio bearer (DRB) mapping configuration, to a target RAN during a mobility procedure. This may enable the target RAN to correctly configure the DRBs and the QoS flow - DRB mapping according to the received QoS flow information. A bearer may be an IP packet flow with a defined QoS between the PDN gateway and a WTRU. It should be noted that a QoS flow include a traffic flow (or a set of traffic flows), a data flow (or a set data flows), a packet flow (or a set packet flows), or the like with a same assigned QoS.

[0073] Referring now to FIG. 2, a system diagram of a 5G/NextGen network 200 is shown.

The 5G/NextGen network 200 may include a CN 202 that may have a CP function 204 and a UP function 206 connected via an NG4 interface. A WTRU 208 may be connected to the CP function 204 via an NG1 interface. A RAN 210 may be connected to the CP function 204 via an NG2 interface and may be connected to the UP function 206 via an NG3 interface. The CP function 204 may be connected to an Application Function (AF) 212 via an NG5 interface. The UP function 206 may be connected to a Data Network (DN) 214 via an NG6 interface.

[0074] It should be noted that the RAN 210 may be based on the 5G RAT or Evolved E-

UTRA and may connect the WTRU to the CN 202. The CP function 204 and the UP function 206 are depicted as single boxes in FIG. 2. However, there may be a variety of CP functions, such as Access Control and Mobility Management Function (AMF), Session Management Function (SMF), and a variety of UP functions represented by each box. Further, there may be standardized interfaces among these various CP and UP functions, but have been simplified so as to not obscure the general inventive concept. The interfaces above may be referred to as communication interfaces, paths, channels, links, or tunnels throughout this description.

[0075] A QoS flow may be the finest granularity for QoS treatment in a NextGen system.

User plane traffic that shares the same QoS treatment (e.g., scheduling policy, queue management policy, rate shaping policy, RLC configuration) may belong to the same QoS flow even if the traffic is made up of different application data flows. Thus, QoS treatment may be a set of parameters of a QoS configuration. A QoS flow may be identified by a QoS marking or QoS flow identifier (ID), which may be carried in UP packets over the NG3 interface and transmitted to the WTRU. Thus, a QoS flow may include a plurality service data flows that share the same QoS marking or ID.

[0076] A WTRU may be provided with QoS rules for each QoS flow that it may have. A

QoS rule may include a flow packet filter, a QoS marking, and a QoS profile. The flow packet filter may be used to identify the QoS flow. For an Internet Protocol (IP)-type flow, IP tuples (source address/port, destination address/port) may be configured as the packet filter. The QoS profile may describe a variety of QoS metrics such as: priority level, Packet Delay Budget (PDB), Packet Error Rate (PER), Allocation and Retention Priority (ARP), UL and DL Guaranteed Bit Rate (GBR), uplink (UL) and DL Maximum Bit Rate (MBR), and the like.

[0077] A QoS marking may be uniquely associated with one QoS profile. A QoS profile may be an A-Type QoS profile or a B-Type QoS profile. The A-Type QoS profile may have standardized QoS characteristics. The B-Type QoS profile may have QoS characteristics that are dynamically configured and signaled by the network to the WTRU and RAN.

[0078] Furthermore, a WTRU may have different types of QoS rules: a default QoS rule, a pre-authorized QoS rule, and a reflective QoS rule. A default QoS rule may be defined when there is no other QoS rule available for a QoS flow. The WTRU may apply the default QoS rule. The default

QoS rule may be signaled to the WTRU during a protocol data unit (PDU) session establishment procedure.

[0079] A pre-authorized QoS rule may be defined when the network explicitly configures the QoS rules for certain flows. The network may signal the QoS rules to the WTRU via NG1 signaling during a PDU session establishment procedure.

[0080] A reflective QoS rule may apply when a WTRU derives a QoS rule from a downlink

(DL) packet reflectively. The WTRU may use the DL IP header of the DL packet to derive the UL flow packet filter (e.g., by reversing source address/port and destination address/port) and the WTRU may use the same DL QoS marking or ID for subsequent uplink (UL) traffic. The network may choose which flows are going to be applied with the reflective QoS rule. The network may include a per-packet Reflective QoS Indication (RQI) in DL UP packets sent over the NG3 interface to indicate to the WTRU the flows to which the reflective QoS rule is to be applied. If the QoS profile associated with the QoS marking used in the reflective QoS is B-type, the QoS profile may be signaled to the RAN over the NG2 interface so the RAN may treat the flow with correct QoS characteristics. In other words, a reflective QoS rule may be one or more QoS parameters for UL UP traffic that is derived from one or more QoS parameters for DL UP traffic. The QoS of the UL UP traffic may reflect, or may be reflective of, the QoS of the DL UP traffic.

[0081] A Data Radio Bearer (DRB) may be a basic logical entity to which the QoS treatments apply. However, there may not be a one-to-one mapping between QoS flows and DRBs. Various QoS flows from a WTRU (in the UL) and the NG3 interface (DL) may be mapped to the DRBs. The RAN may configure this mapping according to one or more strategies and algorithms. The QoS flow to DRB mapping configuration may be signaled to the WTRU.

[0082] The QoS flows for which reflective QoS will be used may be chosen by the CN. A per-packet indication of using reflective QoS (i.e., the RQI) may be carried in the DL data packets of the chosen QoS flow over the NG3 interface. Presumably the RQI, together with a DL QoS marking (or QoS ID) and application data, may be passed on from the RAN, which may be either 3GPP- access or non-3GPP-access, to a WTRU in radio protocol data units.

[0083] After receiving the RQI, the WTRU may derive the reflective QoS rule from the DL packet header and QoS marking for the UL data flow. However, it is possible that the RAN may not be able to pass on the RQI in its radio protocol data packets. If the WTRU is connected to a RAN that does not support the reflective QoS mechanism, the RQI may be lost in the radio interface and the WTRU may end up using a default QoS rule for that QoS flow, which is not intended by the network. In addition, the WTRU may move from a RAN that supports reflective QoS to a RAN that does not. The WTRU may observe the disappearance of the RQI in the DL packets and may misunderstand it for the deactivation of reflective QoS. The WTRU may then fall back to the pre- authorized QoS rule or the default QoS rule, which is also not intended by the network.

[0084] Certain QoS flows may be chosen by the network to apply reflective QoS and the per-packet indication of using reflective QoS may be carried in the DL packets of that flow. For the same QoS flow, a pre-authorized UL QoS rule may also be provided by the network. A static priority can be configured between the pre-authorized QoS rule and the reflective QoS rule. The pre- authorized QoS rule may take precedence over reflective QoS rule, or vice versa.

[0085] However, it may be desirable for the CN to be able to dynamically alter the priority between the pre-authorized QoS rule and the reflective QoS rule. For example, the network may initially configure a QoS flow to use a high-quality QoS profile and also choose that QoS flow to use reflective QoS. In this case, the UL and the DL flow may be treated according to the high-quality QoS profile. The network may also configure a pre-authorized QoS rule for the same flow that uses a lower quality QoS profile. When the network resource allows, the core network may apply reflective QoS and achieve high-quality QoS for both the UL and DL flows. However, if there is some network load situation (e.g., the UL user plane is congested), the network may desire to activate the pre-authorized QoS rule for the UL to sacrifice some UL QoS performance. Subsequently, when the network recovers, it may desire to reapply reflective QoS again.

[0086] Aside from the priority issues between the reflective QoS rule and the pre- authorized QoS rule, the core network may need to deactivate or remove the reflective QoS rule in the WTRU. For example, when the WTRU moves from a serving RAN that supports reflective QoS and to a new serving RAN that does not, the network may need to deactivate or remove the previously derived reflective QoS rule in the WTRU.

[0087] Accordingly, it may be desirable to enable the network and the WTRU to dynamically switch between a pre-authorized QoS rule and a reflective QoS rule, as well as deactivate/remove a reflective QoS rule.

[0088] As described above, the concept of "bearer" as the finest granularity for QoS treatment may be replaced by the concept of "QoS flow" in 5G networks. However, the DRB may be implemented on the radio interface. A RAN may need to map various QoS flows onto radio DRBs. The mapping configuration may be based on the RAN implementation and different RANs may have different strategies or algorithms to implement such a mapping configuration.

[0089] When a WTRU is handed over from one RAN (i.e., source RAN) to another RAN

(i.e., target RAN), DRBs may need to be re-established at the target RAN to carry the existing QoS flows. However, the new DRBs at the target RAN may not be a simple copy of the DRBs at the source RAN. For example, the number of DRBs and the mapping between QoS flows and DRBs may change as the target RAN may implement a different configuration. For the target RAN to be able to configure DRBs for the WTRU, it may need to know which QoS flows, or at least what QoS markings, the WTRU currently has. The QoS flow or marking information may be acquired by the target RAN in the following ways.

[0090] When the CN signals the QoS profiles to a RAN, the RAN may determine which

QoS flows or markings are expected. For example, this may be the case when the core network configures pre-authorized QoS rules for some QoS flows. Additionally, or alternatively, a RAN may observe the QoS markings in the DL packets over the NG3 interface and the RAN may detect new QoS flows. This may be the case for the reflective QoS flows.

[0091] However, during a handover, the CN may send QoS signaling to the source RAN, and may not repeat this at the target RAN. This may be undesirable, since the target RAN may have to wait for DL packets to determine which reflective QoS flows the WTRU may have. The source RAN may transfer the WTRU's QoS flow information to the target RAN during the handover, but this may not always be possible if there is no direct interface between the two RANs. Thus, it may be desirable for the target RAN to acquire the reliable QoS flow information to re-establish the new DRBs for the WTRU.

[0092] A serving RAN may not support reflective QoS. A CN may be enabled or configured to be aware of whether the WTRU's serving RAN supports reflective QoS or not. The CN may directly receive capability indication from RANs whether they support reflective QoS. The CN may also receive a report from the WTRU whether its serving RAN supports reflective QoS or not. The WTRU may obtain this information directly from the serving RAN or by observing (or detecting) a change of a RQI before and after a handover to a different RAN.

[0093] A RAN may indicate to the CN that it supports reflective QoS during the establishment of a signaling connection (e.g., an NG2 interface) between the RAN and the CN. The CN may determine not to apply reflective QoS for WTRUs served by the RAN that does not support reflective QoS. If the WTRU is using a reflective QoS and is then handed over to a RAN that does not support reflective QoS, the CN may deactivate the reflective QoS rules derived by the WTRU via NG1 signaling. The CN may also instruct (or configure) a corresponding UP gateway of the core network to stop carrying a reflective QoS indication in the DL packets. The CN may also provide pre-authorized QoS rules to the WTRU for the impacted QoS flows. Thus, the pre-authorized QoS rules may replace the reflective QoS rules.

[0094] Referring now to FIG. 3, a flow diagram 300 illustrating a process in which a WTRU

302 reports that reflective QoS is not available or supported after disappearance of a RQI in DL data is shown. The WTRU 302 may report to the core network that reflective QoS is not available or supported by discovering the disappearance of a reflective QoS indication in the DL data. As shown in step 312, the WTRU 302 may be in connected mode with a source RAN 304. In step 314, the WTRU 302 may receive DL data from the source RAN 304. The DL data may be sent to the source RAN 304 from a CN UP function 310 and may include an RQI and a QoS marking. The source RAN 304 may support the transmission of the RQI and QoS marking to the WTRU 302.

[0095] In step 316, the WTRU 302 may be handed over to a target RAN 306. A CN CP function 308 (e.g., AMF or SMF) may be involved in the handover process. The target RAN 306 may not support reflective QoS. In step 318, the CN UP function 310 may send DL data that includes an RQI and QoS marking to the target RAN 306. The target RAN 306 may send the DL data to the WTRU 302, but the RQI may be lost in the radio interface. In step 320, the WTRU 302 may discover the disappearance of the RQI and may start a timer to receive a RQI. In step 322, the timer may expire. The WTRU 302 may fall back to a pre-authorized QoS rule, if it is available for the impacted QoS flow, or to the default QoS rule (e.g., if a pre-authorized QoS rule is not available for the impacted QoS flow).

[0096] In step 324, the WTRU 302 may send a report to the CN CP function 308 (e.g.,

SMF) after the expiration of the timer. The report may indicate that reflective QoS is no longer available. The WTRU 302 may also include the previously derived reflective QoS rule which includes the flow packet filter and the QoS marking or ID in the report to facilitate the network to configure a pre-authorized QoS rule that will achieve similar QoS performance compared to the unsupported reflective QoS rule. The WTRU may include one or more QoS flows in the report.

[0097] In step 326, the CN CP function 308 may send an indication to the CN UP Function

310 to deactivate the reflective QoS for the affected flows (e.g., to stop carrying the reflective QoS indication in the DL packets). In step 328, the CN CP function 308 may configure an appropriate pre-authorized QoS rule for the impacted QoS flows and send an indication to the WTRU 302. In step 330, the WTRU may apply the new QoS rules received in step 328 and may deactivate the old reflect QoS rule.

[0098] In a reverse situation, when the WTRU 302 is handed over from a source RAN that does not support reflective QoS to a new target RAN that does support reflective QoS, the WTRU 302 may observe (or detect) the (re)appearance of the reflective QoS indication in the DL packets. The WTRU 302 may automatically switch to using the reflective QoS rule for the impacted QoS flow. If a pre-authorized QoS rule is also available for the same flow, the WTRU 302 may decide which QoS rule should be used depending on the priority of the QoS rules.

[0099] In another embodiment, the WTRU 302 may receive an explicit indication from the source RAN 304 and/or target RAN 306 of whether reflective QoS is supported. The indication may be received in a broadcast message, such as System Information (SI) message, beacon message, and the like. The indication may also be received in dedicated signaling such as a Radio Resource Control (RRC) message. The WTRU 302 may include this information in the NG1 messages when it registers with the core network, or when it initiates a PDU session establishment or management procedure. The network may store the information in the WTRU's context and may not apply reflective QoS if the WTRU's serving RAN does not support it. The WTRU 302 may also send a report to the core network when it is handed over to a new serving RAN and when the new serving RAN does not support reflective QoS.

[0100] A WTRU may dynamically switch priority between pre-authorized QoS rules and reflective QoS rules. The dynamic priority switching may be initiated and performed by the WTRU upon receipt of explicit or implied information from the core network and/or RAN. The dynamic priority switching may be based on one or more of the following trigger events or conditions: a most recent change of either rule makes that rule a higher priority; an explicit NG1 signaling to control the priorities; an explicit reflective QoS deactivation flag in DL (e.g., DL UP) packets to deactivate reflective QoS rule; and/or a timer controlled priority change.

[0101] The most recent indication of using one QoS rule, either reflective QoS rule or pre- authorized QoS rule, may indicate a higher priority over the QoS rule currently being used. The higher priority QoS rule may replace the current QoS rule. The indication of using one QoS rule could be one or more of the following: NG1 signaling to provide the pre-authorized QoS rule; a new indication (e.g., a reflective QoS indication) of using reflective QoS rule in the DL packets; a stop or break in receiving an indication (e.g., a reflective QoS indication) of using reflective QoS in the DL packets; a reappearance of a reflective QoS indication in the DL packets; and/or a change in a QoS marking or ID in the DL packets.

[0102] In an example, a WTRU may receive an indication of using a reflective QoS rule in

DL packets of a certain QoS flow. No pre-authorized QoS rule may have been provided for this flow. In this case, the WTRU may use the reflective QoS rule. Subsequently, the WTRU may receive a new pre-authorized QoS rule from the core network. Because the new pre-authorized QoS rule is the most recent signaling for a QoS rule, it may take precedence over the reflective QoS rule even if the same indication of using a reflective QoS rule is still carried in the DL packets.

[0103] In another example, the WTRU may be provided with a pre-authorized QoS rule for a specified QoS flow. The WTRU may also receive ab indication of using a reflective QoS rule in the DL packets of the same flow. According to a static priority configuration, the reflective QoS rule may have higher priority over pre-authorized QoS rule, so the WTRU may use the reflective QoS rule (e.g., the WTRU may derive a UL QoS rule from the DL packet header and QoS marking and apply the UL QoS rule for the UL data flow). Subsequently, the WTRU may receive a new pre-authorized QoS rule from the network. Because the new pre-authorized QoS rule is the most recent signaling for a QoS rule, it may take precedence over the reflective QoS rule even if the same indication of using a reflective QoS rule is still carried in the DL packets. The newly received pre-authorized rule may or may not be different from the existing pre-authorized QoS rule previously provided to the WTRU.

[0104] Referring now to FIG. 4, a flow diagram 400 illustrating triggering a priory change between a pre-authorized QoS rule and a reflective QoS rule is shown. As shown in FIG. 4, a change of a DL QoS marking or ID may trigger the priority change between pre-authorized QoS rule and reflective QoS rule.

[0105] In step 410, a WTRU 402 may be provided with a pre-authorized QoS rule that has been configured for a flow by a CN CP function 406 (e.g., AMF or SMF) . In step 412, a CN UP function 408 may send DL data to the WTRU 402. The DL data may include an RQI and QoS marking X in the DL packets of the same flow. In step 414, the WTRU 302 may apply the pre- authorized QoS rule for the QoS flow because it has a higher priority over the RQI and reflective QoS rule. In step 416, the WTRU 402 may receive DL packets with a new DL QoS marking Y that is different from the DL QoS marking X previously received and the same RQI. This change in DL QoS marking may trigger the WTRU 402 to raise the priority of the reflective QoS rule over the pre- authorized QoS rule. Thus, in step 418, the WTRU 402 may configure to start using the reflective QoS rule for the QoS flow.

[0106] In another example, the WTRU 402 may have been provided a pre-authorized QoS rule for a specified QoS flow. The WTRU 402 may also receive an indication of using a reflective QoS rule together with a certain QoS marking in the DL packets of the same flow. In this case, the reflective QoS rule may have a higher priority over the pre-authorized QoS rule. Subsequently, the WTRU 402 may no longer receive the reflective QoS indication in the DL packets (e.g., the WTRU 402 may move to a new serving RAN that does not support reflective QoS). The disappearance of the reflective QoS indication in the DL packets may trigger the WTRU 402 to raise the pre- authorized QoS rule in priority over the reflective QoS rule and may use the pre-authorized QoS rule for the QoS flow. Subsequently, a reflective QoS indication may re-appear in the DL packets (e.g., the WTRU 402 moves back to a serving RAN that supports reflective QoS). This may trigger the WTRU 402 to raise the priority of the reflective QoS rule over the pre-authorized QoS rule again, and the WTRU 402 may use the reflective QoS rule for the QoS flow.

[0107] In another example, the WTRU 402 may receive a pre-authorized QoS rule together with an indication of overriding the reflective QoS rule via NG1 signaling. The detection of this overriding indication may configure the WTRU 402 to switch to using the received pre- authorized QoS rule (e.g., if it is currently using the reflective QoS rule). The overriding indication may apply to a service data flow (e.g., identified by a packet filter), a QoS flow (e.g., identified by the same QoS marking or QoS ID) or a PDU session.

[0108] Referring now to FIG. 5, a flow diagram 500 illustrating using an explicit reflective

QoS deactivation indication in UP packets to deactivate/remove a reflective QoS rule is shown. If the core network decides to downgrade a reflective QoS rule, either by lowering the priority of a reflective QoS rule or by deactivating/removing the reflective QoS rule, the core network may request (or instruct) the related UP gateway to stop sending an RQI in the DL packets of the QoS flow. The UP gateway may instead insert a new lower priority reflective QoS indication, a deactivate reflective QoS indication, or a remove reflective QoS indication, which may be collectively referred to as a downgrade reflective QoS indication in the DL packets.

[0109] Upon detecting a downgrade reflective QoS indication in one or more DL packets, the WTRU may perform one or more actions. The WTRU may maintain the previously derived reflective QoS rule, but lower its priority, and switch to another available QoS rule such as a pre- authorized QoS rule or a default QoS rule for the impacted QoS flows. Alternatively, the WTRU may remove (e.g., discard) the previously derived reflective QoS rule and switch to another available QoS rule, such as a pre-authorized QoS rule or a default QoS rule, for the impacted QoS flows.

[0110] The downgrade reflective QoS indication does not have to be sent on each DL packet continuously. The UP gateway may choose to carry the downgrade reflective QoS indication in the first few DL packets to ensure that the WTRU may safely receive it. After the WTRU observes the downgrade reflective QoS indication for the first time and acts on it, it may be no longer necessary to continue to transmit the indication. After the WTRU has acted upon the reflective QoS downgrade flag (e.g., a lower priority flag, a deactivation flag, or a removal flag), the WTRU may report to the network that it has removed reflective QoS rule or has changed it to a lower priority.

[0111] The core network may activate reflective QoS for a coarse granularity of flows, such as per PDU session or per QoS flow, and two or more service data flows may share the same QoS marking or ID. The downgrade/deactivation method described above (e.g., carrying the explicit deactivation flag in the DL packets) may only affect a particular service data flow (i.e., one of two or more) but may not affect other service data flows that share the same QoS marking/ID or are in the same PDU session. For example, a PDU session may include service data flows A, B and C and the PDU session may be configured to use reflective QoS. A deactivation flag may be received in the DL packets of service data flow A, but not for service data flows B and C. Accordingly, the WTRU may configure flow A to stop using reflective QoS but continue to allow flow B and C to use reflective QoS. This principle of parsing out or selectively configuring individual data flows within a PSU session or within a QoS flow may also be applied to any example described herein to selectively control and configure individual data flows.

[0112] As shown in step 510, a CN UP function 508 may send DL data to a RAN 504, which may in turn send the DL data to a WTRU 502. The DL data may include a RQI and a QoS marking. In step 512, the WTRU 502 may send UL data to the RAN 504, which may in turn send the UL data to the CN UP function 508. The UL data may be sent using the QoS rule derived from the RQI and QoS marking sent in step 510. In step 514, a CN CP function 506 (e.g., AMF or SMF) may decide to deactivate reflective QoS. In step 516, the CN CP function 506 may send an indication to the CN UP function 508 to deactivate reflective QoS.

[0113] In step 518, the CN UP function 508 may send DL data to the RAN 504, which in turn may send the DL data to the WTRU 502. The DL data may include an explicit reflective QoS deactivation indication and a QoS marking. In step 520, the WTRU 502 may deactivate/remove the preciously derived reflective QoS rule based on the explicit reflective QoS deactivation indication. In step 522, the WTRU 502 may apply a pre-authorized QoS rule, if available, or a default QoS rule. In step 526, which is optional, the CN CP function 506 may configure a new QoS rule for the affected flow and may send an indication to the WTRU 502.

[0114] The core network may configure a related timer when providing a pre-authorized

QoS rule to the WTRU. During a period specified by the timer, the pre-authorized QoS rule may have higher priority than other QoS rules (including the reflective QoS rule). The WTRU may immediately switch to the newly configured pre-authorized QoS rule and start the timer at the same time. When the timer expires, the WTRU may switch back to the reflective QoS rule if it is available, or it may switch to any other higher priority QoS rule (e.g., a current highest priority QoS rule).

[0115] In addition to the examples described above, a RAN may be configured to acquire

WTRU QoS flow information (e.g., DRB mapping for the WTRU) to enable the RAN, or a target RAN in a handover operation, to correctly configure the DRBs and the QoS flow. Thus, a WTRU may be configured to report QoS flow information (including a QoS flow - DRB mapping configuration) to a target RAN during a mobility procedure for the target RAN to use after handover.

[0116] Referring now to FIG. 6, a flow diagram 600 illustrating reporting current QoS flow information to a target RAN by the WTRU is shown. The WTRU may report its QoS flow information, including QoS flow - DRB mapping configuration, to a target RAN during a handover procedure. The reported QoS flow information may include one or more of the following: a list of QoS flows identified by QoS marking or QoS ID that the WTRU may currently have, the QoS profiles corresponding to the QoS flows, identification of which QoS flows are using reflective QoS, and/or the mapping configuration between QoS flows and DRBs at the source RAN.

[0117] The WTRU may send the QoS flow information to the target RAN in a RRC message after it has synchronized with the target RAN. The WTRU may receive a new configuration of DRBs and a mapping between QoS flows and the new DRBs. The number of new DRBs and the identifiers of the new DRBs may be the same as or different from the previous configuration associated with the source RAN (i.e., the previous RAN). The configuration of mapping between QoS flows and DRBs may be the same or different from the previous configuration of mapping associated with the source RAN. After receiving the new configuration, the WTRU may store the new configuration and discard its old configuration.

[0118] The WTRU may also receive a new configuration of DRBs that is the same as what the WTRU had for the source RAN, but without a new configuration of mapping between QoS flows and DRBs. In this case, the WTRU may determine the old mapping configuration provided by the source RAN still applies and continue to use the old configuration.

[0119] As shown in step 610, a WTRU 602 may be in connected mode with a source RAN

604. In step 612, the WTRU 602 may receive a DRB configuration and/or a QoS flow - DRB mapping configuration from the source RAN 604. In step 614, a CN CP function 608 (e.g., AMF or SMF) may initiate a handover procedure to move the WTRU 602 to a target RAN 606. In step 616, the WTRU 602 may synchronize with the target RAN 606.

[0120] In step 618, the WTRU 602 may send a RRC report of QoS flow information to the target RAN 606. The RRC report may include one or more of a list of QoS flow IDs, related QoS profiles, and QoS flow - DRB mapping configuration. In step 620, the target RAN 606 may make one or more of a new DRB configuration and QoS flow - DRB mapping configuration based on one or more of the information received in the RRC report and local policies. In step 622, the target RAN 606 may send one or more of a new DRB

configuration and QoS flow - DRB mapping configuration to the WTRU 602. In step, 624, the WTRU 602 may implement the received configurations and may discard old configurations. [0121] Referring now to FIG. 7, a flow diagram 700 illustrating a WTRU reporting stored configuration of mapping between QoS flow and DRBs of a previously connected RAN when returning to the RAN is shown. When a WTRU acquires new configurations of DRBs and new mapping between the QoS flows and the DRBs from a new serving RAN, it may not discard the old configuration. Instead, the WTRU may maintain the old configuration in its memory. The WTRU may associate a configuration with the RAN's identifier and maintain it in the WTRU's memory. When the WTRU returns to a previous serving RAN for which a corresponding stored configuration is available, it may report the stored configuration of the same RAN to the serving RAN again. The WTRU may keep a list of old configurations (e.g., for reuse) for a number of previous serving RANs. The size of the list may be configurable according to WTRU's implementation.

[0122] As shown in step 710, a WTRU 702 may be in connected mode with a first RAN

704. In step 712, the WTRU 702 may receive a DRB configuration and/or a QoS flow - DRB mapping configuration from the first RAN 704. In step 714, a CN CP function 708 (e.g., AMF or SMF) may initiate a handover procedure to move the WTRU 702 to from the first RAN 704 to a second RAN 706. In step 716, the WTRU 702 may synchronize with the second RAN 706.

[0123] In step 718, the WTRU 702 may send a RRC report of QoS flow information to the target RAN 606. The RRC report may include one or more of a list of QoS flow IDs, related QoS profiles, and QoS flow - DRB mapping configuration. In step 720, the second RAN 706 may send one or more of a new DRB configuration and QoS flow - DRB mapping configuration to the WTRU 702 based on one or more of the information received in the RRC report and local policies. In step 722, the WTRU 602 may implement the received configurations and may store the old configurations from the first RAN 704.

[0124] In step 724, the CN CP function 708 may initiate a second handover procedure in which the WTRU 702 is transferred back to the first RAN 704 (or another RAN different than the first RAN 704). In step 726, the WTRU 702 may synchronize with the first RAN 704. In step 728, the WTRU 702 may send an RRC report to the first RAN 704. The RRC report may include the stored first RAN configuration. In step 730, the first RAN 704 may send one or more of a new DRB configuration and QoS flow - DRB mapping configuration to the WTRU 702 based on one or more of the information received in the RRC report and local policies. The first RAN 704 may apply the previous configuration or may apply a new configuration.

[0125] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein 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 over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is claimed is:

1. A wireless transmit/receive unit (WTRU) comprising:

an antenna;

a processor operatively coupled to the antenna, the processor configured to receive first user plane (UP) downlink (DL) data from a network, wherein the first UP DL data comprises an indication to initiate reflective quality of service (QoS) and a first QoS marking; and

the processor further configured to transmit UP uplink (UL) data to the network using one or more QoS rules derived from the indication to initiate reflective QoS and the first QoS marking.

2. The WTRU of claim 1 , wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS.

3. The WTRU of claim 1 , wherein the processor is further configured to:

receive second UP DL data from the network, wherein the second UP DL data comprises an indication to deactivate reflective QoS and the QoS first marking;

deactivate the one or more QoS rules based on the indication to deactivate reflective QoS and the second QoS marking; and

apply another QoS rule for upcoming transmissions of UP UL data.

4. The WTRU of claim 3, wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS and the second QoS marking indicates a different second one or more QoS flows to deactivate the reflective QoS.

5. The WTRU of claim 3, wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS and the second QoS marking indicates the same first one or more QoS flows to deactivate the reflective QoS.

6. The WTRU of claim 1 , wherein the processor is further configured to receive control plane (CP) information from a CP function of the network over a second interface.

7. The WTRU of claim 1 , wherein the processor is further configured to receive an indication of a new QoS rule from a CP function of the network.

8. The WTRU of claim 1 , wherein the indication to initiate reflective QoS and the first QoS marking are transmitted in one or more packets of the first UP DL data.

9. The WTRU of claim 1 , wherein the another QoS rule comprises a pre-authorized QoS rule configured by the network for one or more QoS flows and is signaled to the WTRU during a protocol data unit (PDU) establishment procedure.

10. The WTRU of claim 1 , wherein the another QoS rule comprises a default QoS rule to apply to all QoS flows if no other rule is available and is signaled to the WTRU during a PDU establishment procedure.

11. A method for use in a wireless transmit/receive unit (WTRU), the method comprising:

receiving first user plane (UP) downlink (DL) data from a network, wherein the first UP DL data comprises an indication to initiate reflective quality of service (QoS) and a first QoS marking; and

transmitting UP uplink (UL) data to the network using one or more QoS rules derived from the indication to initiate reflective QoS and the first QoS marking.

12. The method of claim 11 , wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS.

13. The method of claim 11 , further comprising:

receiving second UP DL data from the network, wherein the second UP DL data comprises an indication to deactivate reflective QoS and the QoS first marking;

deactivating the one or more QoS rules based on the indication to deactivate reflective QoS and the second QoS marking; and

applying another QoS rule for upcoming transmissions of UP UL data.

14. The method of claim 13, wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS and the second QoS marking indicates a different second one or more QoS flows to deactivate the reflective QoS.

15. The method of claim 13, wherein the first QoS marking indicates a first one or more QoS flows to apply the reflective QoS and the second QoS marking indicates the same first one or more QoS flows to deactivate the reflective QoS.

16. The method of claim 11 , further comprising:

receiving control plane (CP) DL information from a CP function of the network over a second interface.

17. The method of claim 11 , further comprising:

receiving an indication of a new QoS rule from a CP function of the network.

18. The method of claim 11 , wherein the indication to initiate reflective QoS and the first QoS marking are transmitted in one or more packets of the first UP DL data.

19. The method of claim 11 , wherein the another QoS rule comprises a pre-authorized QoS rule configured by the network for one or more QoS flows and is signaled to the WTRU during a protocol data unit (PDU) establishment procedure.

20. The method of claim 11 , wherein the another QoS rule comprises a default QoS rule to apply to all QoS flows if no other rule is available and is signaled to the WTRU during a PDU establishment procedure.