Methods, architectures, devices and systems for notifying network elements in IoT network of changed quality of service information

Abstract

Processes, methods, architectures, devices, systems, apparatuses, and computer program products are described for notifying a network element in an IoT network of changed quality of service information. A gateway device receives information comprising a first set of Quality of Service (QoS) requirements, the information originating from a first network; determining a client device in a second network and the gateway device acting as a gateway for the client device to access the first network, the client device involving at least one traffic flow affected by the first set of QoS requirements; sending information indicating the first set of QoS requirements to the client device; receiving, from the client device, information indicating whether the client device accepts or rejects the first set of QoS requirements; and sending the information to the first network indicating whether the client device accepts or rejects the first set of QoS requirements.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 528,118, filed July 21, 2023, and U.S. Provisional Application No. 63 / 528,120, filed July 21, 2023, which are incorporated herein by reference in their entirety. Background Technology

[0002] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, devices, and systems for notifying network elements in an IoT network (particularly an IoT network connected to an external wireless network) of changes in quality of service information. Summary of the Invention

[0003] In a first aspect, this principle relates to a method in a gateway device, the method comprising: receiving information including a first set of Quality of Service (QoS) requirements, the information originating from a first network; identifying a client device in a second network, wherein the gateway device acts as a gateway for the client device to access the first network, the client device being involved in at least one traffic flow affected by the first set of QoS requirements; sending information to the client device indicating the first set of QoS requirements; receiving information from the client device indicating whether the client device accepts or rejects the first set of QoS requirements; and sending information to the first network indicating whether the client device accepts or rejects the first set of QoS requirements.

[0004] In a second aspect, this principle relates to an apparatus comprising at least one processor configured to: receive information including a first set of Quality of Service (QoS) requirements originating from a first network; identify a client device in a second network, wherein the gateway device acts as a gateway for the client device to access the first network, the client device being involved in at least one service flow affected by the first set of QoS requirements; send information to the client device indicative of the first set of QoS requirements; receive information from the client device indicative of whether the client device accepts or rejects the first set of QoS requirements; and send information to the first network indicative of whether the client device accepts or rejects the first set of QoS requirements. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the figures and the detailed description should not be considered limiting, and other equally valid examples are possible. Furthermore, the same reference numerals (“reference numerals”) in the figures indicate the same elements, and wherein: Figure 1AThis is a system diagram illustrating an exemplary communication system; Figure 1B It shows that it can be shown Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It shows that it can be shown Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D It shows that it can be shown Figure 1A The system diagram shown illustrates yet another exemplary RAN and yet another exemplary CN used within the communication system. Figure 2 An example of a personal IoT network PIN architecture is shown; Figure 3 An example of a PIN application framework in a 5G system is shown; Figure 4 This illustrates a scenario where PINE requests communication via 5GS; Figure 5 (by) Figure 5A and Figure 5B The composition illustrates an exemplary method according to this principle, wherein a PEGC client processes N3QAI changes received from the network; Figure 6 (by) Figure 6A and Figure 6B The composition illustrates an exemplary method according to this principle, wherein a PEMC client processes N3QAI changes received from the network; Figure 7 (by) Figure 7A and Figure 7B The diagram illustrates an exemplary method according to this principle, wherein a PEGC client initiates a notification when QoS requirements cannot be met; Figure 8 (by) Figure 8A and Figure 8B The composition illustrates a first embodiment of an exemplary method according to this principle, wherein an exemplary process in which a PEMC client initiates a notification when QoS requirements cannot be met; and Figure 9 (by) Figure 9A and 9B The present invention illustrates a second embodiment of an exemplary method according to the present principle, wherein an exemplary process is provided in which a PEMC client initiates a notification when QoS requirements cannot be met. Detailed Implementation

[0006] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”). Although various embodiments are described and / or claimed herein in which devices, systems, apparatuses, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described and / or claimed herein assumes that any device, system, apparatus, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0007] Exemplary communication system The methods, apparatus, and systems described herein are well-suited for communications involving wired and wireless networks. About Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted and / or configured for the methods, devices and systems provided herein.

[0008] Figure 1A This is a system diagram illustrating an example communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. For example, the communication system 100 can 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 (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0009] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include / or be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B (NB), eNode-B (eNB), home Node-B (HNB), primary eNode-B (HeNB), gNode-B (gNB), NR Node B (NR NB), site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0011] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (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 specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0012] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0013] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c can implement radio technologies, such as using Wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial air interface (UTRA) access for air interface 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0015] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0016] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can 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).

[0017] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Interconnection (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0018] Figure 1ABase station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In embodiments, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: small cells, pico cells, or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN106 / 115.

[0019] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can 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. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although Figure 1A As not shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) employing any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi.

[0020] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 114 or a different RAT.

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

[0022] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing components.

[0023] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together, for example, in an electronic package or chip.

[0024] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0025] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may employ MIMO technology. Therefore, in an embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0026] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

[0027] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information and store data from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)).

[0028] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to other components in the WTRU 102 and / or control power to those other components. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 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, etc.

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0030] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Components / 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.

[0031] WTRU 102 may include a full-duplex radio, wherein some or all of the transmission and reception of signals (e.g., associated with specific subframes of the uplink (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 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, wherein some or all of the transmission and reception of signals (e.g., associated with specific subframes of the uplink (e.g., for transmission) or downlink (e.g., for reception)) may be separate.

[0032] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0033] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0034] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0035] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0036] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0037] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0038] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0039] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with it, serving as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0041] In a representative embodiment, the other network 112 may be a WLAN.

[0042] A WLAN in Infrastructure Basic Services 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 access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0043] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (e.g., the AP) can sense the primary channel. If a particular STA senses / detects that the primary signal is busy and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

[0044] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0045] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0046] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0047] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth 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 the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, 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 Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and potentially available.

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

[0049] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0050] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In embodiments, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0051] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including different numbers of OFDM symbols and / or absolute times of varying durations).

[0052] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0053] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] 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 at least one Data Network (DN) 185a, 185b. While each of the foregoing elements is described as part of CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0055] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 162 can provide control plane functions for handover between 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 Wi-Fi).

[0056] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0057] UPFs 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110), for example, to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPFs 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0058] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide WTRUs 102a, 102b, and 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 an embodiment, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0059] Given Figures 1A to 1D and Figures 1A to 1D The corresponding description may be performed by one or more of the functions described herein with respect to any of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other element / device described herein. A simulation device may be one or more devices configured to simulate one or more of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0061] One or more simulation devices may perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used to test test scenarios in a laboratory and / or undeployed (e.g., tested) wired and / or wireless communication networks to enable testing of one or more components. One or more simulation devices may be test equipment. The simulation device may transmit and / or receive data using direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas).

[0062] Introduction The following expressions were used in the description.

[0063] Personal IoT Network (PIN): A set of configured and managed PIN elements, which are managed by at least one managed PIN element (PEMC) and are able to communicate with each other directly or via a gateway-capable PIN element (PEGC), and communicate with a 5G network via at least one PEGC.

[0064] PIN element (PINE): A device that can communicate within a PIN (directly connected to the PIN, via PEGC, or via PEGC and 5G core network 5GC) or outside the PIN via PEGC and 5GC.

[0065] PIN element with gateway capability (PEGC): A PIN element that has the ability to provide bidirectional connectivity to 5G networks for other PIN elements or to relay communication between PIN elements.

[0066] PIN element with management capability (PEMC): A PIN element with the ability to manage PINs.

[0067] PINE to PINE communication: Communication between two PINEs, which can be either direct PINE to PINE communication or indirect PINE to PINE communication.

[0068] PINE-to-PINE direct communication: communication between two PIN elements without any PEGC, 3GPPRAN, or core network entity in between.

[0069] PINE-to-PINE indirect communication: Communication between two PIN elements via PEGC or UPF.

[0070] PINE to PINE routing: PEGC routes traffic between two PINEs, which are directly connected to PEGC via non-3GPP access.

[0071] PINE to Network Routing: Traffic is routed between PINE and 5GS by PEGC. PINE connects directly to PEGC via a non-3GPP access point.

[0072] N3QAI: Non-3GPP QoS Assistance Information Personal Internet of Things Networks Internet of Things (IoT) capabilities have already been designed for devices that communicate using traditional cellular networks. IoT-enabled devices require better power efficiency and increased network efficiency for batch operations.

[0073] When deploying multiple IoT devices in a private environment, IoT-capable UEs can be organized into a Personal IoT Network (PIN). For example, in a home environment, security sensors, smart lights, smart sockets, printers, mobile phones, etc., are managed by a residential gateway and can communicate with each other. In this case, all the devices in the home constitute a Personal IoT Network (PIN). Each device is called a PIN element, and different PIN elements have different capabilities. For example, a residential gateway can be a PIN element with gateway capabilities (PEGC) and provide connectivity between PIN elements as well as between 5G networks and PIN elements. A PIN element with management capabilities (PEMC) is a PIN element that provides authorized administrators with the means to configure and manage PINs. A residential gateway acting as a PEGC can also support PIN management functions and is a PIN element with management capabilities (PEMC).

[0074] Wearable devices constitute another type of PIN, in which smartphones can act as PIN elements with gateway capabilities (PEGC) and PIN elements with management capabilities (PEMC), and smartwatches, VR / AR glasses and AirPods communicate in the PIN (or communicate with other UEs via 5G networks).

[0075] Personal IoT network architecture Figure 2An example of a personal IoT network PIN architecture is shown. PIN 210 includes: two PIN elements PINE 212, 214; a PIN element PEMC 216 with management capabilities; and a PIN element PEGC 218 with gateway capabilities.

[0076] PEGC 218 can establish a connection with RAN 222 of 5GC 220, which also includes AMF 224, SMF 226 and UPF 228 connected to data network 230.

[0077] The 5G system design assumes that only 3GPP UEs can act as PEGCs and / or PEMCs, one or more PEGCs exist in the PIN, one or more PEMCs exist in the PIN, and only one of these can control the PIN. The PIN elements use non-3GPP access (e.g., WIFI, Bluetooth) for direct communication. The PEMC can use 5G ProSe direct communication to communicate directly with the PEGC. The PEGC and PEMC subscribe to the same PLMN or (S)NPN, and a single PEGC can support more than one PIN at a time.

[0078] Figure 3 An example of a PIN application (PINAPP) framework in a 5G system is shown. Application entities (such as PIN clients in PINE, PIN gateway clients in PEGC, PIN management clients in PEMC, and PIN servers in the data network) are part of the PINAPP architecture and enable the desired functionality in PIN.

[0079] QoS Management in PIN Networks A UE consists of a Terminal Equipment (TE) portion and a Mobile Terminal (MT) portion. Simply put, the TE portion hosts the applications, and the MT is the receiver / transmitter that provides network services to the TE. The interface between the MT and TE portions is what's known as AT commands or APIs.

[0080] As UEs, both PEGC and PEMC have TE and MT sections. PEGC clients and PEMC clients are "applications" hosted in the TE section. Messages such as PDU session modification requests and PDU session modification commands are sent and received by the MT section of the PEGC (UE).

[0081] Section 5.44.3.3 of TS 23.501 explains that "Non-3GPP QoS Assistance Information (N3QAI)" can be included as part of a PDU session modification command. This PDU session modification command is provided by the SMF to the UE. PEGC is an example of a UE.

[0082] N3QAI may include 5G QoS identifier (5QI), Guaranteed Stream Bit Rate (GFBR) uplink, GFBR downlink, Maximum Stream Bit Rate (MFBR) uplink, MFBR downlink, average window, resource type, priority level, packet delay budget (PDB), packet error rate, maximum data burst, maximum packet loss rate downlink, maximum packet loss rate uplink, ARP, and periodicity, all of which are known in the art.

[0083] The QoS experienced by a PINE connected behind a PEGC depends on the end-to-end path between the PINE and the application server. Non-3GPP QoS Assist Information (N3QAI) enables the PEGC to perform QoS differentiation on PINEs in non-3GPP networks behind it. Based on a combination of (DNN, S-NSSAI) from the PDU session, the SMF provides the PEGC with QoS flow descriptions, including N3QAIs for each QoS flow sent to the PEGC. Based on the N3QAIs and QoS rule information, the PEGC can reserve resources in non-3GPP networks.

[0084] However, how to implement QoS based on N3QAI in non-3GPP networks is considered to be outside the scope of 3GPP's work.

[0085] Section 8.6.2.2 of TS 23.542 describes PINE requests and 5GS communication. Figure 4 This describes a scenario where PINE requests communication via 5GS. In step S402, PINE 412 sends a request for 5G communication to PEGC 416. This request includes the QoS of the packet stream (e.g., packet delay, AMBR). In step S404, PEGC 416 initiates a PDU session modification procedure to 5GS 418. In step S404, 5GS 418 signals the non-3GPP QoS auxiliary information N3QAI to PEGC 416. In step S406, PEGC 416 notifies PINE 412 of N3QAI.

[0086] PDU session modification commands can be triggered by the network at any time. According to the definition of PDU session modification commands, the PEGC (MT) can receive the modified N3QAI for non-3GPP connections between the PEGC and the PINE. As described herein, QoS information is notified to the PINE after 5G communication has been requested. However, there is no mechanism to notify the PINE of QoS information changes, such as when the network changes, modifies, or updates QoS information.

[0087] One question that arises is how members of PIN become aware of changes in QoS indicated by the network so that they can adjust their application-layer behavior to take into account the modified QoS information (i.e., N3QAI). Furthermore, the N3QAI received by PEGC (MT) via the PDU session modification command can indicate that notification control is enabled. When notification control is enabled, the application server (AS) can anticipate notifications that certain QoS settings cannot be maintained. For example, if the GFBR of a QoS flow cannot be satisfied, the application server may need to be notified.

[0088] The 5G core network may not be aware of the status of the PIN network. Therefore, the 5GC will not know if there are any QoS issues in the PIN network. Consequently, the 5GC cannot notify the AS of QoS failures, and the 5GC cannot adjust network settings based on the status of the PIN network. Another question that arises is how to notify the application server when the condition in the PIN causes the QoS to be unsatisfactory, and how to trigger 5GC to adjust the QoS settings. Introduction At least one embodiment of this principle proposes a mechanism for notifying PIN elements of changes or updates to the non-3GPP portion of the PIN via an application-layer messaging mechanism, using N3QAI information. A PEGC client or PEMC client can receive the new N3QAI and notify the PINE and PIN server.

[0089] At least one embodiment of this principle provides a mechanism for notifying application servers and PIN elements of network-indicated changes to the QoS / N3QAI, and includes notification control. A PEGC client or PEMC client processes the new N3QAI carrying the notification control. Embodiments of this principle provide an application-level mechanism for notifying a PIN client in a PINE of changes in QoS information based on N3QAI, which in turn notifies an application client in the PINE.

[0090] Embodiments of this principle also provide a solution for notifying the AS that PINE cannot support the requested N3QAI when notification control is enabled.

[0091] PIN clients can subscribe to PEGC or PEMC clients to receive notifications about QOS / N3QAI changes.

[0092] Before proceeding with a more detailed description, various embodiments of this principle will now be briefly described.

[0093] PEGC client handles N3QAI changes The PEGC client in the UE and the MT portion of the UE receive information from the MT portion of the UE. The information from the MT portion of the UE indicates QoS requirements for at least one PIN data stream. The MT portion of the UE is triggered to send information to the PEGC client by receiving a PDU session modification command that includes N3QAI information. The MT portion of the UE determines which PIN data streams are associated with the N3QAI information.

[0094] The PEGC client identifies the PIN client associated with at least one data stream and sends a message to the PIN client that includes QoS requirements.

[0095] The PEGC client can receive response messages from the PIN client. The response message indicates which QoS requirement the PIN client accepts.

[0096] The PEGC client can send information to the MT part of the UE. The information sent to the MT part of the UE indicates the accepted QoS requirements for at least one data stream.

[0097] The PEGC client can send messages to the PIN server. The message sent to the PIN server can indicate that QoS requirements for at least one data stream can be met. The message can also indicate QoS requirements that cannot be met.

[0098] PEMC client handles N3QAI changes The PEMC client in the UE receives information from the PEGC client regarding QoS requirements for changes to at least one data stream in the PIN.

[0099] The PEMC client identifies the PIN client associated with the data stream and sends a message to the PIN client that includes QoS requirements.

[0100] The PEMC client responds to the PEGC client to notify whether a QoS requirement has been sent to at least one PIN client. This message includes information on whether the QoS requirement for at least one data flow can be satisfied. Optionally, the message may include whether the QoS requirement cannot be satisfied. The response may include the identifier of the PIN client.

[0101] A PEMC client can send a message to the PIN server to notify whether QoS requirements for at least one data stream can be met. This message identifies the data stream and may also identify the PIN client. The message may include QoS information indicating that the requirements may not be met. This message can also prompt the PIN server to notify the application server, allowing the application server to switch to a different data rate.

[0102] PEGC client-side notification control The PEGC client in the UE and the MT portion of the UE receive information from the MT portion of the UE. This information indicates QoS requirements for the data streams and includes an indication to enable notification control for at least one data stream. The MT portion of the UE is triggered to send information to the PEGC client by receiving a PDU session modification command that includes N3QAI information. The MT portion of the UE determines which PIN data streams are associated with the N3QAI information.

[0103] The PEGC client identifies the PIN client associated with at least one data stream.

[0104] The PEGC client sends a message to the PIN client. This message includes QoS requirements and an indication to enable notification control for at least one data stream.

[0105] The PEGC client receives a message from the PIN client. This message indicates that the QoS request has been rejected or cannot be met.

[0106] The PEGC client sends a message to the MT section of the UE. The message sent to the MT section indicates that the QoS requirements for at least one data stream cannot be met. The message can indicate the QoS requirements that can be met.

[0107] This message triggers the MT portion of the UE to send a PDU session modification command to the network. The PDU session modification command indicates that the QoS requirements for at least one data stream cannot be met, and may indicate the QoS requirements that can be met.

[0108] The PEGC client can send a message to the PIN server. The message sent to the PIN server indicates that the QoS requirements for at least one data stream cannot be met. The message can also indicate the QoS requirements that can be met.

[0109] PEMC client-side notification control The PEMC client in the UE receives information from the PEGC client regarding the changed QoS requirements and an indication to enable notification control for at least one data stream in the PIN.

[0110] The PEMC client determines that the changed QoS requirements cannot be met, and the PINE associated with the first PEGC should be associated with the second PEGC instead in order to meet the requirements.

[0111] The PEMC client sends a message to the PIN client indicating the QoS requirements and identifier of the PIN client that it may have with its associated PEGC.

[0112] The PEMC client sends a message to the PEGC client indicating whether the QoS requirements can be met.

[0113] The PEMC client can send a message to the PIN server indicating that the QoS requirements for at least one data stream cannot be met. This message can also indicate the QoS requirements that can be met.

[0114] Detailed description PEGC or PEMC clients can handle N3QAI changes indicated by the network. Handling N3QAI changes means that the PEGC or PEMC client notifies the PIN client of the N3QAI change, collects responses from the PIN client, and notifies the network or application server whether the PINE accepts or rejects the QoS change. The PIN client notifies the application client of the QoS change, and the application client can take actions such as reducing data rates or reserving resources.

[0115] In the description of Figures 5 through 9, and elsewhere in this document, the following terms may be used: New N3QAI The first option for N3QAI provided by the network.

[0116] Backup N3QAI : The second option for N3QAI provided by the network.

[0117] Accepted N3QAI : New N3QAI or alternative N3QAI accepted by PINE.

[0118] Accepted QoS Same as the accepted N3QAI, used to notify the PIN server and AS.

[0119] QoS Rejection The new N3QAI, the alternative N3QAI, or both rejected by PINE.

[0120] Based on this principle, service flows within a PIN may need to be identified by a flow ID. A flow ID can be a combination of one or more PINE IDs, a PINE IP address, and a DSCP code. The UE can map the flow ID to a QoS flow identified by a QFI.

[0121] Figure 5 (by) Figure 5A and Figure 5B The composition illustrates an exemplary method according to this principle, in which a PEGC client processes N3QAI changes received from the network.

[0122] like Figure 5AAs shown, after determining to change or update the QOS information (including N3QAI) provided to the PEGC for the PIN, in step S502, 5GS 509 sends a PDU session modification command with the new N3QAI and the alternate N3QAI to PEGC (MT) 507.

[0123] In step S504, PEGC (MT) 507 determines which flows are affected by the new N3QAI. PEGC (MT) determines this by examining which service flows are mapped to the QoS flows indicated in the N3QAI.

[0124] In step S506, PEGC(MT) 507 sends an N3QAI change request message to PEGC client 505 to indicate the new N3QAI and alternative N3QAI received for these flows. The message also includes information about the affected flows. PEGC client 505 determines the identifier of the PINE associated with the affected flows. If PEGC client 505 has subscribed to PEGC(MT) 507, this message can be a notification.

[0125] In step S508, the PEGC client 505 sends an N3QAI change request message to the PIN client 501 to notify the new N3QAI, the backup N3QAI, and the affected flows by indicating the flow ID. If the PIN client has already subscribed to the PEGC client, this message can be a notification.

[0126] In step S510, the PIN client 501 can notify the application client of the new N3QAI and the alternative N3QAI. The application client can accept the new N3QAI or the alternative N3QAI and take specific actions, such as reducing or increasing video quality. For example, the application client can adjust application layer settings to use different bitrates or information encoding techniques. Different bitrates or information encoding techniques may be more suitable for or more compatible with the current QoS settings. If the new N3QAI cannot be adapted, the suggested N3QAI can also be rejected.

[0127] In step S512, PIN client 501 sends an N3QAI change response to PEGC client 505, indicating that it accepts a new or alternative N3QAI or that it cannot support the proposed N3QAI. An accepted N3QAI indicates either the accepted new N3QAI or the alternative N3QAI. For example, the message could indicate that PIN client 501 will use the alternative N3QAI. A rejected QoS includes both the new and alternative N3QAIs, and instructs PINE to reject both.

[0128] In step S514, the PIN client 501 may also notify the PIN server 511 of the accepted QoS (i.e., the accepted N3QAI (new or standby)) or the rejected QoS by sending a QoS change indication message.

[0129] Go to Figure 5B In step S516, the PEGC client 505 responds to the request from the PEGC MT in step S506 by sending an N3QAI change response message to the PEGC MT. This message may include information about the N3QAI (new or alternative) accepted or rejected by the PINE, indicated by the PINE ID, and information about the affected flow, indicated by the flow ID.

[0130] In step S518, the PEGC client 505 can also notify the PIN server 511 of the QoS accepted or rejected by the PINE indicated by the PINE ID and the affected flow indicated by the flow ID by sending a QoS change indication message. In step S520, PEGC MT 507 sends at least one PDU session modification request to the 5GS network 509. The PDU session modification request can be per PINE and instructs the corresponding PINE within the PIN to accept or reject the use of N3QAI.

[0131] If the PIN server 511 receives a message about a QoS change in step S514 or S518, then, if it has the corresponding capability, in step S522, the PIN server 511 can update the AS with the QoS accepted or rejected by the PINE, identified by the PINE ID, and the affected flows, indicated by the flow ID. After receiving the update, the AS can take action based on the QoS notification, such as increasing or decreasing the data rate.

[0132] Figure 6 (by) Figure 6A and Figure 6B The composition illustrates an exemplary method according to this principle, in which a PEMC client processes N3QAI changes received from the network.

[0133] like Figure 6A As shown, steps S602 to S606 correspond to steps S502 to S506 in Figure 5.

[0134] In step S608, PEGC client 605 sends an N3QAI change request message to PEMC client 603 to notify the new N3QAI, the standby N3QAI, and the affected PINE. The affected PINE is identified by its PINE ID, and the affected flow is identified by its flow ID and PEGC ID. PEMC client 603 uses the PEGC ID to exclude it from the list of recommended PEGCs sent by PEMC client 603 to PINE 601 for PEGC discovery. If the PEMC client has subscribed to a PEGC client, this message can be a notification. In step S610, PEMC client 603 sends an N3QAI change request message to PIN client 601 in the PINE to notify the new N3QAI, the backup N3QAI, and the affected flow ID. This message can be a notification if PIN client 601 has already subscribed to PEMC client 603.

[0135] In step S612, the PIN client 601 can notify the application client of the new N3QAI and the alternative N3QAI. The application client can accept the new or alternative N3QAI and take specific actions (such as reducing or increasing video quality). The application client can also reject the suggested N3QAI. For example, the application client can adjust the application layer settings to use a different bitrate or information encoding technique. A different bitrate or information encoding technique may be more suitable for or more compatible with the current QoS settings.

[0136] In step S614, PIN client 601 sends an N3QAI change response message to PEMC client 603, which indicates whether it is an N3QAI (new or alternative) or whether it cannot support the recommended N3QAI.

[0137] In step S616, the PIN client 603 may send a QoS change indication message to the PIN server 611 to notify it of the QoS accepted or rejected by the PINE as indicated by the PINE ID and the affected flow as indicated by the flow ID.

[0138] Go to Figure 6B In step S618, PEMC client 603 responds to the request received in step S608 by sending an N3QAI change response message to PEMC client 605. The N3QAI change response message indicates whether the PIN client accepts the N3QAI (new or alternative) or rejects the change / update of the QoS. The N3QAI change response message includes the PINE ID for indicating the PINE and the affected stream by indicating the stream ID.

[0139] In step S620, the PEMC client 605 may notify the PIN server 611 of the QoS accepted or rejected by the PINE identified by the PINE ID and the flow identified by the flow ID.

[0140] In step S622, PEGC client 605 sends an N3QAI change response message to PEGC MT 607 in response to its request in step S606. This message may include information about the N3QAI (new or alternative) accepted by the PINE or the QoS rejected, indicated by the PINE ID, and information about the affected flow, indicated by the flow ID. In step S624, PEGC MT 607 sends at least one PDU session modification request to network 5GS 609. The PDU session modification request indicates whether N3QAI is accepted or rejected within the PIN. As described with reference to step S520, the PDU session modification request can be per PIN and indicates whether the corresponding PIN within the PIN accepts or rejects the use of N3QAI.

[0141] If the PIN server 611 receives a message about a QoS change in step S616 or S620, then, if it has the corresponding capability, in step S626, the PIN server 611 can update the AS with the QoS accepted or rejected by the PINE, identified by the PINE ID, and the affected flows, indicated by the flow ID. The AS can take actions based on the QoS notification, such as increasing or decreasing the data rate.

[0142] PEGC or PEMC clients can handle N3QAI changes carrying notification control, as indicated by the network. Handling an N3QAI change means the PEGC or PEMC client notifies the PIN client of the N3QAI change enabling notification control and collects responses from the PIN client. If the PIN client rejects QoS, it must notify the PIN server; if QoS is accepted, it can notify the PIN server. The PIN client notifies the application client of the QoS requirement change, and the application client can take actions such as reducing data rates or reserving resources.

[0143] In this embodiment, the PEGC client receives information about changes to N3QAI that enable notification control and notifies the PIN client of the N3QAI change (including that notification control is now enabled). After receiving an indication from the PIN client that N3QAI is not supported, the PEGC client directly notifies the AS. The PEGC client may also send an indication that N3QAI is not supported to the PEGC MT. This indication may trigger the PEGC MT to send a PDU session modification message to the network. The PDU session modification message may include the indication that N3QAI is not supported and may trigger the SMF to notify the application server that the PINE does not support N3QAI.

[0144] In this embodiment, the PEGC client notifies the PEMC client of the new N3QAI with enabled notification control. The PEMC client may notify the PIN client of the new N3QAI with enabled notification control, or it may avoid notifying the PIN client and decide for itself whether the PINE can support the new N3QAI. The PEMC client may receive an indication from the PIN client that it cannot support the new N3QAI. The PEMC decides whether to notify the AS. The PEMC client notifies the AS directly. Alternatively, the PEMC client notifies the PEGC client and the PEGC MT, which can update the network by triggering a PDU session modification procedure.

[0145] Figure 7 (by) Figure 7A and Figure 7B The diagram illustrates an exemplary method based on this principle, wherein a PEGC client initiates a notification when QoS requirements cannot be met.

[0146] The 5GS 709 can determine changes or updates to the QoS information provided to the PEGC, including N3QAI and notification controls. QoS information may include QoS information (e.g., new N3QAI, standby N3QAI with GFBR) and whether notification controls are enabled. Figure 7A As shown, in step S702, the 5GS sends a PDU session modification command with a new N3QAI, a spare N3QAI, and enabled notification control to the PEGC (MT) 707.

[0147] In step S704, PEGC(MT) 707 determines which flows / PINEs are affected by the new QoS information (i.e., new N3QAI, alternate N3QAI). PEGC(MT) 707 can determine this by examining which flows are mapped to the QoS flows indicated in the N3QAI.

[0148] In step S706, PEGC(MT) 707 sends an N3QAI change request message to PEGC client 705 to indicate that new N3QAI received for these flows and alternative N3QAI with GFBR and notification control have been enabled. The message also includes information about the affected flows. PEGC client 705 identifies the PIN associated with the affected flows. If the PEGC client has subscribed to PEGC(MT), this message can be a notification.

[0149] In step S708, the PEGC client 705 sends an N3QAI change request message to the PIN client 701 to notify of the new N3QAI, the standby N3QAI with GFBR, the activation of notification control, and the affected flow identified by the flow ID. If the PIN client has already subscribed to the PEGC client, this message can be a notification.

[0150] In step S710, the PIN client 701 can notify the application client that a new N3QAI, a backup N3QAI, and notification control are enabled. The application client can accept the new or backup N3QAI and take specific actions (such as reducing or increasing video quality). The application client can also reject a suggested N3QAI. For example, the application client can adjust application layer settings to use a different bitrate or information encoding technique. A different bitrate or information encoding technique may be more suitable for or more compatible with the current QoS settings. The application client can also reject a suggested N3QAI because it cannot adapt to the new N3QAI.

[0151] In step S712, PIN client 701 sends an N3QAI change response to PEGC client 705. This N3QAI change response indicates that PIN client 701 accepts a new or alternative N3QAI, or that the proposed N3QAI cannot be supported due to GFBR inability to meet its requirements. An accepted N3QAI indicates either the accepted new or alternative N3QAI. For example, the message could indicate the alternative N3QAI that the PIN client will use. A rejected QoS includes both a new N3QAI with notification control enabled and an alternative N3QAI, and indicates that neither was accepted by PINE.

[0152] In this embodiment, the PIN client 701 processes responses from the application client. If the application client rejects a new N3QAI or a backup N3QAI, the PIN client may decide that it needs to notify the PIN server because notification control is enabled. If so, in step S714a, the PIN client 701 notifies the PIN server 711 of the accepted or rejected QoS by sending a QoS change indication message. The PIN server may update the AS with the accepted or rejected QoS identified by the PINE ID and the flow identified by the flow ID. The AS can take actions based on the QoS notification, such as increasing or decreasing the data rate.

[0153] Go to Figure 7B In other embodiments, after receiving a message that no N3QAI has been accepted, the PEGC client 705 determines that the AS should be notified (because notification control is enabled). In step S714b, the PEGC client 705 notifies the PEGC MT 707 of the QoS information accepted or rejected by the PINE by sending an N3QAI change response message (possibly per PINE). The N3QAI change response message indicates the flow ID and the accepted or rejected QoS information. In step S716, in response to receiving QoS rejection information, the PEGC MT 707 determines that the AS 711 needs to be notified because notification control has been enabled. In step S718, the PEGC MT 707 sends at least one PDU session modification request to the network 709. The PDU session modification request indicates an N3QAI carrying notification control and accepted or rejected for use in the PIN. As described with reference to step S520, the PDU session modification request may be per PINE and indicates whether the corresponding PINE within the PIN accepts or rejects the N3QAI used. In step S720, 5GS 709 notifies the PIN server / AS 711 that the N3QAI carrying notification control cannot be satisfied.

[0154] In another embodiment, in step S714c, the PEGC client 705 sends a QoS change indication message to the PIN server 711 to notify of the accepted or rejected QoS (such as GFBR failure) and that notification control has been enabled. This message includes the affected PINE indicated by the PINE ID and the affected flow indicated by the flow ID. The PIN server 711 can trigger notification control on the AS.

[0155] Figure 8 (by) Figure 8A and Figure 8B The diagram illustrates a first embodiment of an exemplary method based on this principle, wherein an exemplary process in which a PEMC client initiates a notification when QoS requirements cannot be met.

[0156] According to the first embodiment, the PEMC client receives new QoS information and notification control from the PEGC client. If PINE cannot support the requested QoS, the PEMC client determines this and initiates a process to notify the application server.

[0157] like Figure 8A As shown, steps S802 to S806 correspond to steps S702 to S706 in Figure 7: The PEGC client receives new N3QAI information with notification control enabled from the network / 5GS. The QoS information may include QoS information (e.g., new N3QAI, standby N3QAI with GFBR) and notification control being enabled.

[0158] In step S808, the PEGC client 805 sends an N3QAI change request message to the PEMC client 803 to notify the new N3QAI, the standby N3QAI with notification control enabled, and the affected PINE. The affected PINE is identified by its PINE ID, and the affected flow is identified by its flow ID and PEGC ID. The PEMC client 803 uses the PEGC ID to exclude it from the list of recommended PEGCs sent by the PEMC client to the PINE for PEGC discovery. If the PEMC client has already subscribed to the PEGC client, this message can be a notification.

[0159] In step S810, PEMC client 803 determines that PINE cannot support the new N3QAI with GFBR. PEMC client 803 may make this determination based on PINE profile, its location, connection, etc. PEMC client 803 may determine that PINE should discover a different PEGC. PEMC client 803 initiates a process that associates PINE with a different PEGC, as described in step S822. Since notification control is enabled, PEMC client 803 also determines that AS 811 should be notified.

[0160] In step S812, PEMC client 803 sends an N3QAI change response (towards the message in step S808) to PEGC client 805. The N3QAI change response indicates that the PIN client cannot support the requested N3QAI by indicating the rejected N3QAI with GFBR in the rejected QoS and a notification indicating that the Flow ID is enabled.

[0161] Since the PEMC client 803 knows that notification control is enabled, in step S814, the PEMC client 803 can send a QoS change indication message to the PIN server 811 to notify that the N3QAI with GFBR is unsatisfactory. This message may also include the affected PINE identified by the PINE ID, the affected flow identified by the flow ID, and the PEGC connected to the PEGC identified by the PEGC ID. The PIN server can provide this information to the AS, allowing the AS to take actions such as reducing the data rate.

[0162] After receiving the notification response in step S812, the PEGC client 805 determines that the AS should be notified (because notification control is enabled). Proceed to... Figure 8B In step S816, the PEGC client 805 sends an N3QAI change response message to the PEGC MT 807. This message includes information about the rejected QoS for the PINE, and indicates the affected PINE by the PINE ID and the affected flow by the flow ID.

[0163] In step S818, PEGC MT 807 sends at least one PDU session modification request to network 809. The PDU session modification request indicates that notification control is enabled and that N3QAI is rejected for use within a PIN. As described with reference to step S520, the PDU session modification request can be per PIN and indicates that the corresponding PIN within the PIN accepts or rejects the use of N3QAI. In step S820, 5GS 809 notifies the PIN server / AS 811 that the N3QAI carrying notification control cannot be satisfied.

[0164] In step S822, the PEMC client 805 sends a message to the PIN client 801 instructing it to begin searching for new PEGCs because the current PEGCs do not support the desired QoS. This message includes a list of PEGCs to help the PIN client discover new ones.

[0165] In step S824, PIN client 801 notifies application client and initiates PEGC discovery.

[0166] Figure 9 (by) Figure 9A and 9B The present invention illustrates a second embodiment of an exemplary method according to the present principle, wherein an exemplary process is provided in which a PEMC client initiates a notification when QoS requirements cannot be met.

[0167] According to the second embodiment, the PEMC client receives new QoS information and notification control from the PEGC client. The PEMC client does not know whether the PINE can support the requested QoS. The PEMC client notifies the PIN client of the new N3QAI. After receiving a response from the PIN client, the PEMC begins notifying the network or AS of the QoS that has been agreed to or rejected. The following figure illustrates this process.

[0168] like Figure 9A As shown, steps S902 to S906 correspond to steps S702 to S706 in Figure 7: The PEGC client receives new N3QAI information with notification control enabled from the network / 5GS. The QoS information may include QoS information (e.g., new N3QAI, standby N3QAI with GFBR) and notification control being enabled.

[0169] In step S908, PEGC client 905 sends an N3QAI change request message to PEMC client 903 to notify the new N3QAI, the standby N3QAI with notification control enabled, and the affected PINE. The affected PINE is identified by its PINE ID, and the affected flow is identified by its flow ID and PEGC ID. PEMC client 903 uses the PEGC ID to exclude it from the list of recommended PEGCs sent by the PEMC client to the PINE for PEGC discovery. If PEMC client 903 has already subscribed to the PEGC client, this message can be a notification.

[0170] In step S910, the PEMC client 903 determines that new N3QAI and alternate N3QAI information with GFBR and enabled notification control are available to the PINE. The PEMC client 903 cannot determine whether the PINE can support the new N3QAI. The PEMC client 903 determines to notify the PINE of QOS information and a list of PEGC information. If the PINE cannot support the N3QAI, it can discover new PEGCs.

[0171] In step S912, PEMC client 903 sends an N3QAI change request message to PIN client 901 in the PINE to notify the new N3QAI, the standby N3QAI, the GFBR with notification control enabled, and the affected flow ID identified by the flow ID. If the PIN client has already subscribed to the PEMC client, this message can be a notification.

[0172] In step S914, the PIN client 901 can notify the application client that the new N3QAI, the backup N3QAI, and notification control are enabled. The application client can accept the new N3QAI or the backup N3QAI and take specific actions (such as reducing or increasing video quality). The application client can also reject the suggested N3QAI. For example, the application client can adjust the application layer settings to use a different bitrate or information encoding technique. A different bitrate or information encoding technique may be more suitable for or more compatible with the current QoS settings.

[0173] In step S916, the PIN client 901 sends an N3QAI change response message to the PEMC client. This N3QAI change response message indicates that it accepts a new N3QAI or an alternative N3QAI carrying notification control, or indicates that it cannot support the proposed N3QAI by including rejected QoS information.

[0174] After determining that notification control is enabled, in step S918, PIN client 901 can determine to notify PIN server 911. If so, PIN client 901 can directly notify PIN server 911 of the accepted or rejected QoS indicated by PINE ID (where notification control is enabled) and the affected flow indicated by Flow ID by sending a QoS change indication message.

[0175] Go to Figure 9B In step S920, the PEMC client 903 determines whether it is necessary to notify the 5GS / AS because notification control is enabled. If the PINE cannot support the requested QoS and indicates this to the PEMC client by sending a rejected QoS, the PEMC client determines that it is necessary to notify the AS.

[0176] In step S922, in response to the request received from PEGC client 905 in step S908, PEMC client 903 sends an N3QAI change response message to PEGC client 905. The N3QAI change response message indicates whether the PIN client accepts the N3QAI (new or alternative) or refuses to enable notification control for the change / update QoS. The N3QAI change response message includes the PINE ID indicating the PINE and the affected flow indicating the flow ID.

[0177] Upon receiving the QoS rejection message, the PEGC client 905 determines that the AS should be notified (because notification control is enabled). In step S924, the PEGC client 905 sends an N3QAI change response message in response to the request from the PEGC MT in step S906. This message may include information about the QoS rejection by the PINE indicated by the PINE ID (a new N3QAI or a standby N3QAI with notification control enabled) and the affected flow indicated by the flow ID. In step S926, PEGC MT 907 sends at least one PDU session modification request to network 909. The PDU session modification request indicates that N3QAI is rejected for use within a PIN. As described with reference to step S520, the PDU session modification request can be per PIN and indicates whether the corresponding PIN within the PIN accepts or rejects the use of N3QAI.

[0178] In step S928, 5GS 909 notifies the PIN server / AS 911 that the N3QAI carrying notification control cannot be satisfied.

[0179] In step S930, the PEMC client 903 may notify the PIN server 911 of the QoS accepted or rejected by the PINE identified by the PINE ID (where notification control is enabled) and the flow identified by the flow ID.

[0180] In step S932, the PIN server 911 notifies the AS of the QoS rejected by the PINE by indicating the QoS rejected by the PINE, identified by the PINE ID, and the affected flow, identified by the flow ID. The AS can take actions based on the QoS notification, such as reducing the data rate.

[0181] In summary, this disclosure describes different solutions.

[0182] A wireless transmit / receive unit (WTRU) can: receive information from a first network, the information including a first set of Quality of Service (QoS) parameters and a second set of QoS parameters; identify devices in a second network, wherein a gateway device acts as a gateway for the devices to access the first network, and the client devices are involved in service flows affected by the first set of QoS parameters and the second set of QoS parameters; send information to the identified devices indicating the first set of QoS parameters and the second set of QoS parameters; receive from at least one identified device information indicating either a set of QoS parameters accepted from the first set of QoS parameters and the second set of QoS parameters, or information indicating rejection of both the first set of QoS parameters and the second set of QoS parameters; and send information to the first network indicating that the identified devices in the second network accept the set of QoS parameters and reject at least one of the first set of QoS parameters and the second set of QoS parameters.

[0183] A wireless transmit / receive unit (WTRU) can: receive information from a first gateway device in a first network where the WTRU is a management device, the information including a first set of Quality of Service (QoS) parameters and a second set of QoS parameters; after determining that other devices in the first network cannot support the first set of QoS parameters or the second set of QoS parameters, send information to the gateway device indicating rejection of the first set of QoS parameters and the second set of QoS parameters; and send messages to other devices indicating a request to change the gateway device from the first gateway device to the second gateway device.

[0184] A wireless transmit / receive unit (WTRU) can: receive information from a gateway device in a first network where the WTRU is a management device, the information including a first set of Quality of Service (QoS) parameters and a second set of QoS parameters; send information to other devices in the first network indicating the first set of QoS parameters and the second set of QoS parameters; receive from at least one other device information indicating that one set of QoS parameters from the first set of QoS parameters and the second set of QoS parameters is accepted, or information indicating that both the first set of QoS parameters and the second set of QoS parameters are rejected; send information to the gateway device indicating that other devices in a second network accept a set of QoS parameters and reject at least one of the first set of QoS parameters and the second set of QoS parameters; and send information to a server in the second network connected to the gateway device, the information indicating that other devices in the second network accept a set of QoS parameters and that the other devices reject at least one of the first set of QoS parameters and the second set of QoS parameters.

[0185] in conclusion Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited in its specific embodiments described herein, which are intended as illustrative of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Any element, action, or instruction used in the description of this application should not be construed as critical or essential to the invention unless expressly provided so. In addition to those listed herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art based on the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of their legally enjoyed equivalents. It should be understood that this disclosure is not limited to the specific methods or systems described herein.

[0186] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0187] It will also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or the term “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU; (iv) a device having wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU; or (iv) a similar device. References herein Figures 1A to 1D Details of an example WTRU are provided, which may represent any WTRU described herein. As another example, various disclosed embodiments herein are further illustrated. The above text and The following text It is described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and some or all of the embodiments of this disclosure and the various disclosures can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive reality experience.

[0188] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated into computer-readable media 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 non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, 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 discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0189] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0190] Furthermore, in the embodiments provided above, a processing platform, computing system, controller, and other means including a processor are mentioned. These means may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as “execution,” “computer execution,” or “CPU execution.”

[0191] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. An electrical system represents a data bit, which can cause a final conversion or reduction of an electrical signal and is maintained in a memory location within a storage system, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location maintaining the data bit is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bit. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0192] Data bits can also be maintained on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that exist only on the processing system or are distributed across multiple interconnected processing systems that may be located locally or remotely on the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

[0193] In exemplary embodiments, any operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0194] The differences between the hardware and software implementations of various aspects of the system are minor. The use of hardware or software is typically (but not always, as the choice between hardware and software can become important in certain situations) a design choice representing a cost-efficiency trade-off. Various vehicles (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred vehicle can vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may choose the primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may choose the primary software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0195] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, and / or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof, with regard to the inclusion of one or more functions and / or operations in such block diagrams, flowcharts, or examples. In embodiments, several portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein can be equivalently implemented in integrated circuits as one or more computer processes running on one or more computers (e.g., as one or more processes running on one or more computer systems), as one or more processes running on one or more processors (e.g., as one or more processes running on one or more microprocessors), as firmware, or virtually as any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware in accordance with this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as process products in various forms, and the illustrative examples of the subject matter described herein apply regardless of the specific type of signal-bearing medium used for actual distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmitting media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0196] Those skilled in the art will recognize that devices and / or processes are typically described in the manner set forth herein, and that engineering practice is subsequently used to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface, and application processes, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed; control motors for moving and / or adjusting the number and / or quantity of components). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0197] The topics described herein sometimes illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures that achieve the same functionality can actually be implemented. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” such that the desired functionality can be achieved. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other such that the desired functionality is achieved regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include (but are not limited to) physically matable and / or physically interacting components, and / or wirelessly interacting and / or logically interacting components.

[0198] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can convert plural to singular and / or singular to plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0199] Those skilled in the art will understand that, generally, the terms used herein, and especially in the appended claims (e.g., the body of the appended claims), are intended to be largely "open-ended" terms (e.g., the term "comprising" should be interpreted as "comprising but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if an intention is to express a specific number of introduced claims, then such intention will be explicitly stated in the claims, and without such a statement, such intention does not exist. For example, the term "single" or similar language may be used where the intention is only one item. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases "at least one" and "one or more" to introduce multiple claims. However, the use of such phrases should not be construed as implying that a claim recitation introduced by an indefinite article will include any particular claim recitation limited to an embodiment comprising only one such recitation, even if the same claim includes indefinite articles such as the introductory phrases “one or more” or “at least one” (e.g., “a” and / or “one” should be interpreted as meaning “at least one” or “one or more”). The same applies to definite articles used to introduce claim recitations. Furthermore, even if a specific number of introduced claim recitations are explicitly stated, those skilled in the art will recognize that this statement should be interpreted as meaning at least the number recitations (e.g., simply stating “two recitations” without other modifiers means at least two recitations or two or more recitations). Moreover, in cases where conventions such as “at least one of A, B, and C” are used, in a sense, this structure is intended to represent a convention that those skilled in the art will understand (e.g., “a system having at least one of A, B, and C” will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In cases where conventions such as "at least one of A, B, or C" are used, such a structure is generally intended to be understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). Those skilled in the art will further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually provide two or more alternatives should be understood to be intended to include the possibility of including one, any, or both of the terms. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B".Furthermore, the term "any of the following" as used herein, followed by a list of multiple items and / or multiple categories of items, is intended to include "any," "any combination," "any multiple," and / or "a combination of any multiple," individually or in combination with other items and / or other categories of items. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. And the term "many" as used herein is intended to be synonymous with "multiple."

[0200] Furthermore, when features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup member of the Markush Group.

[0201] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and capable of being decomposed into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the listed numbers and refers to a scope that can subsequently be subdivided into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0202] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "for a means of..." in any claim is intended to invoke 35 USC §112, 6 or the means plus function claim format, and any claim without the term "for a means of..." does not have such an intent.

Claims

1. A method comprising, in a gateway device: receiving information comprising a first set of quality of service, QoS, requirements, the information originating from a first network; determining a client device in a second network and the gateway device acting as a gateway for the client device to access the first network, the client device involving at least one traffic flow affected by the first set of QoS requirements; sending information to the client device indicating the first set of QoS requirements; receiving information from the client device indicating whether the client device accepts or rejects the first set of QoS requirements; and sending the information to the first network indicating whether the client device accepts or rejects the first set of QoS requirements.

2. The method of claim 1, further comprising: receiving information comprising a second set of QoS parameters from the first network; wherein the client device further involves at least one traffic flow affected by the second set of QoS parameters; sending information to the client device indicating the second set of QoS parameters; receiving information from the client device indicating whether the client device accepts or rejects the second set of QoS requirements; and sending the information to the first network indicating whether the client device accepts or rejects the second set of QoS requirements.

3. The method of claim 1 or 2, wherein: the received first set of QoS requirements is for the at least one traffic flow; the received information further comprises an indication to enable notification control; and the information sent to the client device further comprises an indication to enable notification control.

4. The method of claim 2, further comprising: sending the information to the client device indicating the traffic flow affected by at least one of the first set of QoS requirements and the second set of QoS requirements.

5. The method of claim 2, wherein: the information sent to an application server indicating whether the client device accepts or rejects the second set of QoS requirements. the received information indicating whether the client device accepts or rejects the first set of QoS requirements and the information indicating whether the client device accepts or rejects the second set of QoS requirements indicates acceptance of one of the first set of QoS requirements and the second set of QoS requirements or rejection of both the first set of QoS requirements and the second set of QoS requirements.

7. The method of claim 2, further comprising:

6. The method of claim 2, wherein, sending information to the first network indicating the at least one traffic flow.

8. The method of claim 2, wherein: the information sent to the first network is sent in a request to modify a packet data unit session.

9. A device comprising at least one processor configured to: receive information comprising a first set of quality of service, QoS, requirements, the information originating from a first network; determine a client device in a second network and the gateway device acting as a gateway for the client device to access the first network, the client device involving at least one traffic flow affected by the first set of QoS requirements; ​ ​ sending, to the client device, information indicating the first set of QoS requirements; receiving, from the client device, information indicating whether the client device accepts or rejects the first set of QoS requirements; and sending, to the first network, the information indicating whether the client device accepts or rejects the first set of QoS requirements.

10. The apparatus of claim 9, wherein, the at least one processor is further configured to: receive, from the first network, information comprising a second set of QoS parameters; wherein the client device is further involved in at least one traffic flow affected by the second set of QoS parameters; sending, to the client device, information indicating the second set of QoS parameters; receiving, from the client device, information indicating whether the client device accepts or rejects the second set of QoS requirements; and sending, to the first network, information indicating whether the client device accepts or rejects the second set of QoS requirements.

11. The apparatus of claim 9 or 10, wherein: the received first set of QoS requirements is for the at least one traffic flow; the received information further comprises an indication of notification control enabled; and the information sent to the client device further comprises an indication of notification control enabled.

12. The apparatus of claim 10, wherein, the at least one processor is further configured to: send, to the client device, the information indicating the traffic flow affected by at least one of the first set of QoS requirements and the second set of QoS requirements.

13. The apparatus of claim 10, wherein: the information indicating whether the client device accepts or rejects the second set of QoS requirements is sent to an application server.

14. The apparatus of claim 10, wherein, the received information indicating whether the client device accepts or rejects the first set of QoS requirements and the information indicating whether the client device accepts or rejects the second set of QoS requirements indicates acceptance of one of the first set of QoS requirements and the second set of QoS requirements or rejection of both the first set of QoS requirements and the second set of QoS requirements.

15. The apparatus of claim 10, wherein, the at least one processor is further configured to: send, to the first network, information indicating the at least one traffic flow.

16. The apparatus of claim 10, wherein: the information sent to the first network is sent in a request to modify a packet data unit session.

Images