DL PDU set utilizing ATSSS

Abstract

The UPF receives a set of PDUs. The UPF may send a first set of PDUs in the set of PDUs to a RAN node. The UPF may send PDU set information to a non-3GPP access node, the PDU set information including a size of a second set of PDUs in the PDU set and a guidance to provide a report. The UPF may transmit the second set of PDUs to the non-3GPP node. The UPF may send notification information to the RAN node. The notification information may include an indication of a PDU sequence number associated with a PDU included in the second group and information indicating the size of the second group. The UPF may receive a report from the non-3GPP node. The report may indicate whether a PDU in the second group is received at the non-3GPP node. The UPF may send the report to the RAN node, which may be used by the RAN node in reporting processing.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 531,957, filed August 10, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). The previous generation (traditional) mobile communication RAT could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] Systems, methods, and tools for sending downlink (DL) protocol data units (PDUs) using Access Traffic Bootstrapping, Switching, and Offloading (ATSSS) are disclosed.

[0004] A computing system (which may include, for example, a User Plane Function (UPF)) can receive an indication that a PDU session involves two access branches. This indication can be received via an N4 rule that indicates the PDU session involves two access branches.

[0005] The computing system can receive XRM PDUs. The received XRM PDUs may include multiple PDUs containing a set of PDUs.

[0006] The computing system can send the first group of PDUs in the PDU set to the RAN node. The system can determine the first group of PDUs to send based on the received N4 rules. The system can also send the group size associated with the first group of PDUs to the RAN node.

[0007] This computing system can send PDU set information to non-3GGP nodes (e.g., non-3GPP interoperability functions). The PDU set information may include an indication of the size of a second set of PDUs in the PDU set and an indication to provide a report. The PDU set information may also include an indication that other PDUs in the PDU set have been sent via another access tributary (e.g., via a RAN node). This computing system can send a second set of PDUs to non-3GPP nodes.

[0008] The computing system can send notification information to the RAN node. This notification information may include information indicating the PDU sequence number associated with the PDUs included in the second PDU group and information indicating the size of the second PDU group. The notification information may also include an indication to the RAN node that a successful delivery notification associated with the delivery of the second PDU group can be sent if the second PDU group is successfully delivered. The notification information may also include an End-of-Burst (EOB) indication associated with the second PDU group.

[0009] The computing system can receive reports from non-3GPP nodes. These reports can indicate whether PDUs from the second group of PDUs have been received at the non-3GPP node. For example, the report could indicate that all PDUs in the second group of PDUs have been received.

[0010] The computing system can send information from the report to the RAN node, which can then use that information in the configuration process.

[0011] Non-3GPP node computing systems can be configured to receive PDU set information from a UPF, which can be included in a 3GPP core network node. The PDU set information may include an indication of the size of a second set of PDUs in the PDU set and an indication to provide a report. The PDU set information may also include an indication that other PDUs in the PDU set have been transmitted via another access tributary (e.g., via a RAN node).

[0012] Non-3GPP node computing systems can receive a second set of PDUs from the UPF. The non-3GPP computing system can generate a report indicating whether PDUs from the second set have been received at the non-3GPP computing system. For example, the report could indicate that all PDUs in the second set have been received. The non-3GPP computing system can send this report to the UPF or the 3GPP RAN node.

[0013] Non-3GPP node computing systems can send a second set of PDUs to the Radio Transmit and Receive Unit (WTRU).

[0014] The 3GPP RAN node computing system can be configured to receive the first set of PDUs from the UPF PDU set.

[0015] The 3GPP RAN node computing system can receive notification information from the UPF running on the 3GPP core network node. This notification information may include information indicating the PDU sequence number associated with the PDUs included in the second PDU group and information indicating the size of the second PDU group. The notification information may also include an indication that a successful delivery notification associated with the delivery of the second PDU group can be sent to the RAN node if the second PDU group is successfully delivered. The notification information may also include an End-of-Burst (EOB) indication associated with the second PDU group.

[0016] The 3GPP RAN node computing system can receive information from reports, including indications of whether PDUs in the second set of PDUs have been received at non-3GPP node computing systems. For example, the information from the reports could indicate that all PDUs in the second set of PDUs have been received at non-3GPP computing systems.

[0017] The 3GPP RAN node computing system can use this report to determine configuration processing. This configuration processing may include determining the WTRU connectivity DRX mode setting based on the report. It may also include determining the error rate calculation based on the report. Attached Figure Description

[0018] Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments.

[0019] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0020] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows a sample radio access network (RAN) and a sample core network (CN) used in the communication system.

[0021] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is another example RAN and another example CN used in the communication system.

[0022] Figure 2 A diagram depicts an example processing method for utilizing ATSSS features to employ PDU set features. Detailed Implementation

[0023] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings.

[0024] Figure 1A This diagram illustrates an example communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may 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 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0025] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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, and 102d may 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 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.

[0026] 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 to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, 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.

[0027] 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 one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0029] 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 Radio Access (UTRA) for air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0031] In the embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using New Radio (NR) to establish NR radio access for air interface 116.

[0032] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various 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 various types of radio access technologies and / or by transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0033] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., 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), GSMEDGE (GERAN), etc.

[0034] 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 one embodiment, 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 another embodiment, 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 yet another embodiment, 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 picocells 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 CN 106 / 115.

[0035] 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 using 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) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] CN 106 / 115 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 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 / 113 or a different RAT.

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

[0038] Figure 1B This is a system diagram illustrating example 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 peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0039] Processor 118 can 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 can 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 can be coupled to transceiver 120, which can 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 in an electronic package or chip.

[0040] 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 embodiments, for example, 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.

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

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

[0043] 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 identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not actually located on WTRU 102, such as on a server or home computer (not shown).

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

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

[0046] The processor 118 can also be connected to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), 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. Peripheral devices 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.

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

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

[0049] 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 one embodiment, 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 / or receive radio signals from WTRU 102a.

[0050] 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 UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0051] 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 (or PGW) 166. While each of the foregoing elements is described as part of 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.

[0052] 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, activating / deactivating bearers, 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.

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

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

[0055] 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 such an IP gateway 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.

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

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

[0058] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can have an interface to a Distribution System (DS) or another type of wired / wireless network that loads traffic into and / or loads traffic out of 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 peer-to-peer traffic. Peer-to-peer 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 can 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 a "self-organizing" communication mode in this document.

[0059] 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 - Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. With CSMA / CA, each STA (e.g., every STA), including 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.

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

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

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

[0063] 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 can be considered busy even if most of the band remains idle and potentially available.

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

[0065] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an 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.

[0066] 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 one embodiment, 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 gNBs 180a, 180b, and 180c. 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 may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0067] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be varied 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 of various lengths or scalable lengths, or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

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

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

[0070] 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 possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is described as part of the 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.

[0071] 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 PDU sessions with different requirements), selecting specific SMFs 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing 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 established for different use cases, such as services dependent on Ultra Reliable Low Latency (URLLC) access, services dependent on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. 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 WiFi).

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

[0073] UPF 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 WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 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.

[0074] 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 one 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.

[0075] Given Figures 1A to 1D and Figures 1A to 1D The corresponding descriptions can be performed by one or more emulation devices (not shown) that perform one or more of the functions described herein with respect to: 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 devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0077] One or more simulation devices may perform one or more functions when implemented / deployed without being part of a wired and / or wireless communication network. For example, simulation devices may be used to test scenarios in a laboratory and / or undeployed (e.g., tested) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices may be test equipment. Simulation devices may transmit and / or receive data using direct RF connections and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0078] The references to “an example” or “example” or “an implementation” or “implementation”, and their variations, mean that a particular feature, structure, characteristic, etc., described in connection with the example is included in at least one example. Therefore, the phrases “in an example” or “in a sample” or “in an implementation” or “in an implementation”, and any other variations, appearing throughout this application, do not necessarily refer to the same example.

[0079] Additionally, this application may relate to "determining" various types of information. Determining information may include one or more of the following: for example, estimated information, calculated information, predicted information, or information retrieved from memory. Obtaining may include receiving, retrieving, constructing, generating, and / or determining.

[0080] Furthermore, this application may involve "accessing" various types of information. Accessing information may include one or more of the following: for example, receiving information, retrieving information (e.g., retrieving from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0081] Additionally, this application may relate to "receiving" various types of information. Like "access," the intent to receive is a broad term. Receiving information may include one or more of the following: for example, accessing information or retrieving information (e.g., retrieving from memory). Furthermore, "receiving" is generally referred to in one or more ways during operation, such as storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0082] It should be understood that, for example, in the cases of “A / B,” “A and / or B,” and “at least one of A and B,” the use of any of the following “ / ,” “and / or,” and “at least one” is intended to cover selecting only the first listed option (A), or only the second listed option (B), or selecting both options (A and B). As yet another example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” this wording is intended to include selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or selecting all three options (A, B, and C). As will be apparent to those skilled in the art and related fields, this can be extended to a large number of listed items.

[0083] UPF can be configured to route extended and multimodal reality (XRM) traffic within an MA PDU session that supports PDU set characteristics, via one tributary (e.g., RAN node) and a second tributary (e.g., non-3GPP node). UPF can also be configured to send a notification to the first tributary (e.g., RAN node) that a second portion of the same PDU set is being transmitted via the second tributary (e.g., non-3GPP access node) if the first portion of a PDU in the PDU set is being transmitted via the first tributary (e.g., RAN node).

[0084] The notification may include information including the sequence number and group size of the PDUs in the PDU set to be transmitted via a second tributary (e.g., non-3GPP access). The notification information may also include an indication of successful delivery of the second part of the PDUs via non-3GPP access. The notification information may also include an indication of sending a data burst end indication within the second part of the PDUs.

[0085] The second access node (which may be a non-3GPP access node, such as an N3IWF) can receive a second portion of the PDUs in the PDU set. The N3IWF can also receive PDU set information indicating that a report on the delivery of PDUs may be requested (e.g., demanded). The N3IWF may have been pre-configured to detect successful reception of PDUs in the PDU set and delivery to the WTRU.

[0086] The N3IWF can generate a delivery report and send it to the UPF or directly to the RAN node using N2 signaling.

[0087] The first branch (e.g., the RAN node) can use information from the delivery report to make processing decisions, such as configuring the connection DRX mode settings of the WTRU and the QoS processing of the PDUs in the received PDU set.

[0088] The User Plane Function (UPF) can be configured with PDU sessions that support multiple access PDU sets to configure information related to PDU offloading, notification of access nodes, and forwarding of delivery reports. The UPF can be configured to perform, for example, the following.

[0089] In can be combined Figure 2 In the first example item corresponding to the implementation described at reference numeral 2 in the figure, the UPF can receive N4 rules from the Session Management Function (SMF) regarding extended and multimodal reality (XRM) traffic that can be carried within a PDU session, which can be a multi-access PDU session that supports PDU set characteristics.

[0090] In can be combined Figure 2 In the second example item corresponding to the implementation described at reference numerals 4 and 5a, the UPF can receive XRM PDU set traffic. The UPF can receive a first number of PDUs from the PDU set.

[0091] In can be combined Figure 2 In the third example item corresponding to the implementation described at reference numeral 5a, the UPF can determine the first tributary to send the PDU to the WTRU via the multiple access PDU session based on information in the corresponding N4 rule. This tributary can be connected via a RAN node or a non-3GPP node (e.g., a non-3GPP interoperability function (N3IWF)).

[0092] In can be combined Figure 2In the fourth item corresponding to the embodiment described at reference numeral 5b, the UPF may send a first portion of the PDUs of the PDU set to the first access tributary, and may include PDU set information in the PDUs sent through the first tributary. The included information may include PDU sequence number, PDU set size, PDU set importance, combinations thereof, etc. This information may be sent in the GTP-U header of each PDU, or may be sent in some PDUs (e.g., the first PDU of the PDU set sent through the first tributary).

[0093] In can be combined Figure 2 In the fifth item corresponding to the implementation described at reference numeral 5c in the attached figure, the UPF can receive a second number of PDUs from the same PDU set.

[0094] In can be combined Figure 2 In the sixth item corresponding to the embodiment described at reference numeral 5c in the attached figure, the UPF can determine a second number of PDUs in the PDU set to be transmitted via the second access tributary based on the N4 rule. This tributary can be connected via a RAN node or a non-3GPP node (e.g., N3IWF).

[0095] In can be combined Figure 2 In the seventh item corresponding to the embodiment described at reference numeral 5c in the attached figure, the UPF can transmit a second part of the PDUs of the same PDU set via the second branch, and can include PDU set information in the PDUs transmitted via the second branch. This information may include PDU sequence number, PDU set size, PDU set importance, etc. This information may be transmitted in the GTP-U header of each PDU or in some PDUs (e.g., the first PDU of the PDU set transmitted via the second branch).

[0096] The transmitted information may also include information identifying the group size of the PDUs to be transmitted via the second access tributary. This information may include an indication that some PDUs in the PDU set may have already been transmitted via another access tributary. Information may also be added to this indication regarding the PDU sequence number of the PDUs transmitted via the other tributary, the size of the PDU group, and whether the group of PDUs can be expected to successfully deliver notifications.

[0097] In can be combined Figure 2In the eighth embodiment described at reference numeral 5d, the UPF may send information to the first access tributary providing an indication or notification of a second number of PDUs in the PDU set. The sent information may indicate or include information about the sequence number of a PDU within the PDU set that can be transmitted via the second tributary. The sent information may indicate or include information about the size of the group of PDUs in the PDU set that will be transmitted via the second tributary access. This information may be expressed in bytes or the number of PDUs. The sent information may indicate or include an indication that a notification of successful delivery of the group of PDUs in the PDU set can be sent to the first access tributary. If the second number of PDUs in the PDU set includes an EoB indication, the sent information may indicate or include information indicating that the EoB indication may be associated with a PDU that may have already been transmitted via the second tributary.

[0098] In can be combined Figure 2 In the ninth item corresponding to the embodiment described at reference numeral 6b, the UPF may receive a delivery report from the second (and / or first) access tributary, which may include an indication of whether a PDU in the second (and / or first) number of PDUs has been successfully received and delivered to the WTRU by the second (and / or first) access node.

[0099] In can be combined Figure 2 In the ninth item corresponding to the embodiment described at reference numeral 7 in the attached figure, the UPF may send a delivery report to the first (and / or second) access tributary.

[0100] Access nodes (which can be 3GPP or non-3GPP) can be configured to know the PDU sets that can be distributed across two access points, and can report and / or receive delivery reports of PDU sets sent through other access points.

[0101] The first access node (which may be a 3GGP or non-3GPP node) may perform one or more of the following actions.

[0102] In can be combined Figure 2 In the first action corresponding to the implementation described at reference numeral 2 in the attached figure, the first access node can receive a QoS profile from the SMF, which may relate to XRM traffic that can be carried within a multi-access PDU session that supports PDU set features.

[0103] In can be combined Figure 2 In the second action corresponding to the embodiment described at reference numeral 3 in the figure, the first access node can be configured to detect and report the reception of PDUs as part of the PDU set of PDU sessions and the successful delivery to the WTRU based on information in the received QoS profile.

[0104] In can be combined Figure 2 In the third action corresponding to the embodiment described at reference numeral 5b in the attached figure, the first access node can receive a first number of PDUs from the PDU set from the UPF.

[0105] In can be combined Figure 2 In the fourth action corresponding to the embodiment described at reference numeral 5d in the attached figure, if a second number of PDUs of the same PDU set are sent by a second access node through a multiple access PDU session, the first access node can receive a notification regarding the second number of PDUs in the PDU set.

[0106] In can be combined Figure 2 In the fifth action corresponding to the embodiment described at reference numeral 7 in the attached figure, the first access node can receive a delivery report from the second access node regarding the successful reception of a second PDU in the PDU set and its delivery to the WTRU. The delivery report can be received from the UPF or, for example, directly from the second access node.

[0107] In can be combined Figure 2 In the sixth action corresponding to the embodiment described at reference 6a, the first access node can use information received from the PDUs in the PDU set to detect whether one or more PDUs (e.g., all PDUs) have been successfully received and delivered to the WTRU.

[0108] In can be combined Figure 2 In the seventh action corresponding to the embodiment described at reference numeral 6b, the first access node may send a delivery report regarding the reception of the first portion of the PDU set and the successful delivery to the WTRU. The delivery report may be sent to the UPF or, for example, directly to the second access node.

[0109] In systems such as 5G systems (5GS), the WTRU can support communication via both 3GPP access and non-3GPP access (e.g., Wi-Fi). This capability provides network operators with the flexibility to determine which access method to use for specific service data streams.

[0110] It can provide a feature that can be called Access Traffic Bootstrapping, Switching, and Offloading (ATSSS), and this feature can take advantage of the flexibility provided by supporting communication through both 3GPP access and non-3GPP access.

[0111] ATSSS features may rely on the concept of multiple access connectivity, which may include establishing a multiple access PDU session, in which traffic from the serving data stream can be transmitted via 3GPP access, non-3GPP access, or both.

[0112] Bootstrapping functionality refers to the logic used to switch, bootstrap, or offload traffic. In 3GPP, three bootstrapping functions can be applied (e.g., standardized). The first bootstrap function can be called ATSSS-LL and can be used for Ethernet, TCP, or UDP traffic. The second bootstrap function can be based on the MPTCP protocol and can be used for TCP traffic. The third bootstrap function can be based on the MPQUIC protocol and can be used for UDP traffic.

[0113] In this ATSSS feature, different boot modes can be defined as part of these boot functions. Some of these modes may include active-standby mode, minimum latency mode, load balancing mode, and priority-based mode.

[0114] In systems such as 5GS, rules can be provided to the WTRU and UPF that instruct (e.g., tell) which boot mode to use and provide configuration details of those modes. Switching, bootstrapping, and / or offloading decisions can be made in the WTRU for uplink traffic. Switching, bootstrapping, and / or offloading decisions can be made in the UPF for downlink traffic.

[0115] In examples that support XRM services, a PDU set can be used. A PDU set can be, for example, one or more PDUs carrying the payload of a unit of information generated at the application level (e.g., a frame or video slice of an XRM service).

[0116] In examples where XRM features can be used, the UPF can identify PDU set-related information to support PDU set processing in systems such as 5GS. This information may include, for example, the following: PDU set sequence number; indication of PDU set end; indication of PDU data burst; PDU sequence number within the PDU set; PDU set size; and PDU set importance. RTP header extensions may appear in DL traffic received by the UPF on the N6 interface. The UPF can use information from the RTP header to determine PDU set-related information. The UPF can use PDU set-related information to determine what information to send to the NG-RAN using downlink traffic. For example, the PDU set importance parameter can be used to identify the importance of the PDU set within a QoS flow. The RAN can use this parameter when making decisions about PDU set-level packet drop in the presence of congestion.

[0117] PDU set information can be sent from the UPF to the RAN node via the GTP-U header of the user plane packet. The RAN node can perform PDU set-based QoS processing based on the PDU set QoS parameters received via the control plane and the PDU set information received via the user plane in the GTP-U header. PDU set QoS parameters may include, for example, the following: PDU set delay budget; PDU set error rate; and PDU set integration processing indication (e.g., indicating whether the application needs some or all of the PDUs in the PDU set). PDU set QoS parameters can be sent from the SMF to the RAN node. The SMF can send the PDU set QoS parameters to the AMF, and the AMF can forward the PDU set QoS parameters to the RAN node via the N2 interface.

[0118] PDU set information can be used by the core network. For example, PSDB and PSER can be calculated by the RAN. NG-RAN can use (for example, and then can use) PSDB, PSER, and PSIHI to make scheduling decisions. These scheduling decisions can include deciding whether to drop packets or deciding whether to prioritize sending the first packet over the second packet.

[0119] PDU Set Integration Processing Information (PSIHI) can indicate to NG-RAN nodes whether the application layer in the WTRU can use (e.g., needs) one or more PDUs (e.g., all PDUs) of the PDU set. NG-RAN nodes can be designed such that if a single PDU of the PDU set is not delivered to the WTRU or is not received from the UPF, the PDUs of the PDU set are determined to be discarded.

[0120] "Non-3GPP access node" can be, for example, an N3IWF (Non-3GPP Interoperability Function) or a Trusted Non-3GPP Gateway Function (TNGF), or can be associated with an N3IWF or TNGF.

[0121] An "NG-RAN node" can be, for example, a base station or something associated with it. For example, an NG-RAN node can be a gNodeB. The functions described in conjunction with the NG-RAN access node can be applied to access nodes such as eNodeBs.

[0122] One type of "non-3GPP access" could be, for example, WiFi.

[0123] The type of "3GPP access" can be, for example, NR, LTE, etc.

[0124] PDU set processing for XRM services may already be used in 3GPP access nodes. PDU set processing for XRM services may not yet be used in non-3GPP access nodes. For example, if a PDU session uses non-3GPP access, the PDU set processing feature may not yet be supported.

[0125] If a link experiences congestion, using a single access path for XRM traffic can result in poor quality of experience. Therefore, the use of ATSSS can be useful, for example, beneficial, for XRM traffic. For instance, Wi-Fi connectivity can be used for WTRUs, and Wi-Fi connectivity can provide better data connectivity than cellular connectivity. As another example, Wi-Fi connectivity can be used for WTRUs, and using a combination of Wi-Fi and cellular connectivity can provide better data connectivity than using cellular connectivity alone.

[0126] The design of PDU set processing features can rely on the PSA UPF to identify and tag PDUs in the PDU set, enabling NG-RAN nodes to identify the complete PDU set. NG-RAN nodes can assume that one or more PDUs in the PDU set (e.g., all PDUs) use a single path (e.g., in a single-address PDU session).

[0127] For example, if PSIHI is enabled, identifying and tagging PDUs within a PDU set can be useful. With PSIHI enabled, NG-RAN nodes can benefit from knowing whether one or more (e.g., all) of the PDUs in a PDU set have been successfully transmitted / received. If an NG-RAN node detects that a PDU in the PDU set has not yet been received from the UPF, the NG-RAN node can determine that the complete PDU set is unlikely to be delivered and can determine (e.g., decide) to discard other PDUs in the PDU set. If some PDUs in the PDU set were transmitted via a non-3GPP access node, the NG-RAN node might incorrectly determine that some PDUs in the PDU set were not successfully delivered to the WTRU.

[0128] For example, in conjunction with the process by which NG-RAN nodes can calculate the error rate of a PDU set in a QoS flow, identifying and tagging PDUs within the PDU set can also be useful. If all PDUs in a PDU set are successfully delivered (e.g., only if this is the case), then the PDU set can be considered successfully delivered. If some PDUs in the PDU set are sent via non-3GPP access nodes, the NG-RAN node may not be able to accurately calculate the PSER.

[0129] For example, in conjunction with the process by which NG-RAN nodes can calculate the potential delays experienced by a set of PDUs for a QoS flow, identifying and tagging PDUs within a PDU set can also be useful. The delay can be the duration between the reception time of the first PDU and the time when one or more PDUs (e.g., all PDUs) in the PDU set have been successfully received. If some PDUs in the PDU set are transmitted via non-3GPP access nodes, the NG-RAN node may not be able to accurately calculate the delay of the PDU set because the non-3GPP access node may have already delivered the first PDU, the last PDU, or both of the first and last PDUs in the PDU set.

[0130] If ATSSS is used in conjunction with PDU set processing features, for certain XRM traffic volumes, and depending on some bootstrap function / mode, some PDUs in the PDU set may be transmitted via more than one access tributary (e.g., via 3GPP tributaries and non-3GPP tributaries). As described herein, the RAN node may determine that some PDU sets are incomplete, even though it is true that one or more of the PDUs (e.g., all PDUs) were correctly received by the WTRU, but were received via different access routes.

[0131] Enhancing systems such as 5GS can be useful, enabling 3GPP access / RAN nodes to determine whether a PDU set is complete, accurately calculate the error rate, and accurately calculate latency values ​​when carrying DL traffic within a 5GS system with PDU set features enabled and ATSSS employed. Such features allow PDUs from the same PDU set to be transmitted through different access points. This feature of transmitting PDUs from the same PDU set through different access points can be called "PDU set offloading."

[0132] In some cases, such as when a RAN node on an access tributary does not support PDU set-off, PDU set-off may be inappropriate. In this example, it can be useful to detect whether PDU set-off is inappropriate and, in such cases, to prevent PDU set-off.

[0133] Figure 2 An example processing for using PDU set features by leveraging ATSSS features is described. Figure 2An example procedure is illustrated in a system such as 5G systems for allowing UPF to route multiple access PDU sessions, where the RAN node supports PDU set characteristics and PDU set traffic can be offloaded across two access nodes (e.g., the RAN node and a non-3GPP access node). The UPF can be configured to notify the RAN node whether the second part of the PDUs in the PDU set is sent via the non-3GPP node, and / or whether the first part of the PDUs in the PDU set can be sent via the RAN node. The RAN node and non-3GPP node can be configured to detect and notify the WTRU (in...) Figure 2 The UE reports the successful reception and delivery of PDUs in the PDU set.

[0134] exist Figure 2 In this diagram, non-3GPP nodes are shown as N3IWF, but can also be TNGF. After the WTRU has registered with both the 3GPP and non-3GPP access tributaries, it can request an MA PDU session. Other variations are possible. For example, if the WTRU requests the establishment of the first MA PDU session, it can register only on the 3GPP access tributary. In this case, the WTRU can register with the non-3GPP network at a later time and then use the same PDU session ID used in the first MA PDU session establishment to perform a second MA PDU session establishment request through the second tributary.

[0135] refer to Figure 2 At reference numeral 0a in the attached diagram, a WTRU supporting ATSSS can request a multiple access PDU session by sending an MA PDU session request. If the AMF supports MA PDU sessions, the AMF can select an SMF that supports MA PDU sessions. The PCF can generate PCC rules including MA PDU session control information and can send these rules to the SMF. The SMF can generate ATSSS rules and send them to the WTRU, and can send N4 rules to the UPF. The SMF can establish user plane resources through 3GPP access and / or non-3GPP access.

[0136] Before reference 0 in the attached figure, for example, during the PDU session establishment, the SMF may have already obtained PDU set support capabilities from the RAN node, including PDU set offloading capabilities.

[0137] At reference 0b in the attached diagram, the AF can send a request to the 5GC (e.g., NEF) to establish or update the QoS (e.g., the requested QoS) for XRM traffic. This request message may include traffic description information identifying the XRM traffic, QoS parameters, and identification information and parameters associated with the PDU set, such as PSDB, PSER, and / or PSIHI. Once authorized, the request can be forwarded to the serving PCF.

[0138] At reference numeral 1 in the attached figure, the PCF can derive PCC rules to include PDU set identification information and PDU set parameters. A PDU session carrying XRM traffic can be a multi-access PDU session. The PDU session may already be an MA PDU session, or may have been modified from a single-access to an MA PDU session. This can occur before XRM traffic begins to be carried through the PDU session. PCC rules can include MA PDU session control information. PCC rules can include PDU set-related control information. The PCF can determine and generate PCC rules. PCC rules can indicate whether both PDU set characteristics and multi-access characteristics (e.g., ATSSS) can be enabled for the PDU session.

[0139] At reference numeral 2 in the attached diagram, a new PCC rule can be sent to the SMF, and the SMF can generate an N4 rule to send to the serving UPF. The N4 rule can indicate to the UPF that a PDU session involves two access tributaries and can enable PDU set features. The SMF can generate the corresponding QoS profile and send it to NG-RAN nodes and non-3GPP nodes, such as the N3IWF. The SMF can also generate the corresponding QoS rules and send them to the WTRU.

[0140] At reference numeral 3 in the attached figure, based on information from the QoS profile received from the SMF, the N3IWF and NG-RAN nodes can be configured to detect and report the reception of PDUs that are part of the PDU set for the corresponding PDU session, for example, successful reception. Reports from the N3IWF and NG-RAN nodes can be sent to the UPF.

[0141] At reference 4 in the attached diagram, the UPF can begin receiving XRM PDU set traffic.

[0142] At reference numeral 5a in the attached diagram, the UPF can receive the first number of PDUs in the PDU set. Based on the corresponding N4 rule, the UPF can determine how to send these PDUs to the WTRU via the NG-RAN node.

[0143] At reference numeral 5b in the attached diagram, the UPF can send the first part of the PDUs in the PDU set to the RAN node. If the PDUs are not in ordered order, the UPF can include the group size of the PDU set in the GTP-U header, which indicates how many PDUs for that set are being sent to the RAN. The UPF can also send the group size in bytes.

[0144] At reference 5c in the attached figure, the UPF can receive a second number of PDUs from the same PDU set.

[0145] UPF can determine a second number of PDUs to be sent to the N3IWF via non-3GPP access, such as ATSSS information or PMF measurement, based on N4 rules (e.g., ATSSS information or PMF measurement in N4 rules).

[0146] UPF can include PDU set information in the PDU to send to N3IWF in the GTP-U header. This information may include, for example, PDU sequence number, PDU set size, PDU set importance, and their combinations.

[0147] The UPF can also include the group size of the PDUs to be transmitted via non-3GPP in the header of each PDU in the PDU set. This information allows the N3IWF to know the number of PDUs in its expected PDU set. The UPF can also include an indication that some PDUs in the PDU set have already been transmitted via another access point. The information sent to the N3IWF can be sent in the header of one or more PDUs (e.g., all PDUs). In the example, some information can be sent in the header of several selected PDUs, for example, it can be sent only in these headers. For example, some information can be sent in the first PDU sent to the N3IWF, for example, it can be sent only in the first PDU.

[0148] At reference numeral 5d in the attached figure, the UPF may send a notification to the NG-RAN regarding a second number of PDUs in the PDU set. This notification may include, for example, the following four information items: The first information item may include information about the sequence numbers of the PDUs within the PDU set to be transmitted via a second tributary, which may be, for example, a non-3GPP access. The second information item may include information about the size of the group of PDUs in the PDU set transmitted via the non-3GPP access. This information may be expressed, for example, in bytes or the number of PDUs. The third information item may include an indication that a notification of successful delivery of this group of PDUs in the PDU set may be sent by the UPF or N3IWF to the NG-RAN node. If the second number of PDUs in the PDU set includes an EoB indication, then the fourth information item may include information or an indication that the EoB indication is associated with the PDUs transmitted via the second tributary (e.g., to the N3IWF).

[0149] At reference numeral 5e in the attached figure, the N3IWF can receive a second number of PDUs with relevant information.

[0150] Since the second number of PDUs may belong to a set of PDUs partially transmitted via NG-RAN access, the UPF may include the following first and second information items in the GTP-U header of the PDUs sent to the N3IWF. The first information item may include an indication requesting / requesting a successful delivery report for the PDU set or for the PDUs within that set. This indication may be used by the N3IWF to determine whether a delivery report needs to be sent from the N3IWF to the UPF or RAN node, for example, via N2 signaling. The second information item may include an indication regarding the granularity of reports that can be used (e.g., can be requested). For example, the UPF may instruct the N3IWF to request reports for each PDU (e.g., each PDU), the PDU set, or within a specific time period.

[0151] If the report includes information elements related to non-3GPP elements that indicate the successful delivery of that set of PDUs, then the N3IWF may have been configured to detect whether one or more PDUs (e.g., all PDUs) in a second number of PDUs in the PDU set have been successfully received.

[0152] At reference 6a in the attached figure, the N3IWF can use the information sent by the UPF in the GTP-U header of the PDU to detect whether one or more PDUs (e.g., all PDUs) have been successfully received.

[0153] At reference numeral 6b in the attached figure, the N3IWF may send a delivery report to the UPF. The delivery report may include whether one or more PDUs (e.g., all PDUs) of the second number of PDUs have been successfully received.

[0154] In implementations (e.g., alternative implementations), the N3IWF can send delivery reports to the RAN node directly (e.g., without going through the UPF), for example, via N2 signaling.

[0155] At reference numeral 7 in the attached figure, the UPF (or, in another embodiment, the N3IWF) may send a delivery report to the NG-RAN node. The delivery report may include information indicating whether one or more PDUs (e.g., all PDUs) of a second number of PDUs have been successfully delivered by the N3IWF to the WTRU. This information helps the NG-RAN determine whether the entire set of PDUs has been successfully received at the access network (AN).

[0156] For example, the report may include information about the partial transmission of a PDU set via non-3GPP access. If the UPF determines that the first group of PDUs in the PDU set is transmitted via NG-RAN and the second group of PDUs in the same PDU set is transmitted via non-3GPP access (e.g., according to ATSSS control information), the UPF may notify the NG-RAN node that the second part of the PDU set is transmitted via non-3GPP access. The information in the report may include the PDU set sequence number of the PDU set of interest and the PDU sequence number of the PDUs transmitted by the UPF via non-3GPP access (e.g., within the PDU set). If the PDUs are transmitted in ordered sequence, the UPF may send the first PDU sequence number and the last PDU sequence number in the report. The report may include the size of the group of PDUs in the PDU set transmitted via non-3GPP access (e.g., in bytes or the number of PDUs). The report may indicate whether the transmission of the PDU set via non-3GPP access has ended, for example, a PDU end indication with PDU sequence numbers.

[0157] Reports sent from the UPF (or N3IWF) to the NG-RAN node may include indications of whether the PDU portion of a PDU set sent by the UPF via non-3GPP was successfully received by the non-3GPP node and delivered to the WTRU. The NG-RAN node can use this information when calculating error rates and making prioritization decisions for QoS flows with PSIHI features enabled.

[0158] In this implementation, a report sent from the UPF (or from the N3IWF) to the NG-RAN node may include an indication that all or part of the PDU set was sent via a non-3GPP access tributary. This report may not indicate whether the PDUs were successfully delivered via other access tributaries, and may trigger the NG-RAN node to either not calculate erroneous measurements for the PDU set or to discard or disregard erroneous measurements for the PDU set. In this scenario, the RAN node may be responsible for its own delivery and may treat other PDUs (e.g., sent via a second tributary, which may be the N3IWF) as delivered for loss calculation and as non-existent for billing purposes.

[0159] Reports sent from the UPF (or from the N3IWF) to the NG-RAN node may include an indication that a PDU associated with a data burst end indication has been sent from the UPF to the N3IWF. The NG-RAN node can use the burst end indication in the report to configure WTRU power-saving features, such as Connected Mode DRX.

[0160] At reference numeral 8 in the attached figure, NG-RAN nodes can use information from reports to make decisions regarding the DRX settings for configuring the WTRU's connectivity mode. NG-RAN nodes can use this information when performing error rate calculations, or use it to determine whether to perform error rate calculations or to discard or ignore them.

[0161] Referring to reference numeral 6b, an example is depicted where a second branch, which may include an N3IWF, can send a delivery report to the UPF. An NG-RAN node can send a delivery report to the UPF, enabling a delivery report containing information similar to that described in conjunction with reference numeral 5d to be sent to the second branch (e.g., the N3IWF). A global report including information about which branch the PDU group is being delivered to can be sent to both branches, allowing them to have information about one or more PDUs (e.g., all PDUs) in the PDU set.

[0162] Referring to reference numeral 7, an example is depicted where the UPF can send delivery reports to the NG-RAN node. The UPF can also send delivery reports to the N3IWF. Sending reports to the N3IWF helps the N3IWF perform error rate and latency calculations. Sending reports to the N3IWF helps the N3IWF make traffic prioritization and packet drop decisions. In this implementation, the RAN node can send delivery reports to the N3IWF via N2 signaling.

[0163] Referring to reference numerals 5a to 5d in the accompanying drawings, an example is depicted of transmitting a first set of PDUs of a PDU set via a RAN node and a second set of PDUs of the PDU set via a second tributary, which may be, for example, a non-3GPP access (e.g., N3IWF). In an implementation, a first set of PDUs of a PDU set to be transmitted via a non-3GPP access (e.g., N3IWF) can be determined, and then a second set of PDUs of the PDU set can be transmitted via the RAN node.

[0164] The same principle applies.

[0165] In another example, it may be necessary to send more than one set of PDUs via a second tributary, which could be, for example, a non-3GPP node. In this case, instead of sending a notification / delivery report for a set of PDUs (e.g., each set of PDUs) from the PDU set sent via the second tributary (e.g., non-3GPP), the UPF can wait until all sets of PDUs (e.g., one or more sets (e.g., all sets)) have been sent and successfully delivered, and then the UPF can send a notification and delivery report to the first tributary (e.g., the RAN node).

[0166] The examples described herein may include an MA PDU session in which one branch is a 3GPP node and a RAN node, and the other branch is a non-3GPP node. These examples can be generalized if both branches of the MA PDU session are 3GPP nodes and RAN nodes.

[0167] Although features and elements are described herein in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, 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.

Claims

1. A computing system, comprising: Processor, the processor being configured to: The PDU reception session involves indications of two access tributaries; Receive XRM PDUs that include a set of PDUs; Send the first set of PDUs in the PDU set to the RAN node; Send PDU set information to non-3GPP access nodes, the PDU set information including an indication of the size of the second group of PDUs in the PDU set and an indication to provide a report; Send the second group of PDUs in the PDU set to the non-3GPP access node; Send notification information to the RAN node, the notification information including information indicating the PDU sequence number associated with the second group of PDUs and information indicating the size of the second group of PDUs; Receive a report from the non-3GPP access node, the report indicating the number of PDUs received by the non-3GPP access node and successfully delivered to the WTRU; as well as The information from the report is sent to the RAN node.

2. The computing system according to claim 1, in, The notification information also includes an indication that a notification will be sent to the RAN node if the second set of PDUs is successfully delivered.

3. The computing system according to claim 1, in, The notification information also includes an indication that the data burst end (EOB) indication is associated with the second group of PDUs.

4. The computing system according to claim 1, in, The processor configured to receive the indication that the PDU session involves two access branches is configured to: receive an N4 rule indicating that the PDU session involves two access branches.

5. The computing system according to claim 4, in, The processor is also configured to determine the transmission of the first group of PDUs based on the N4 rule.

6. The computing system according to claim 1, wherein, The processor is also configured to send the group size associated with the first group of PDUs to the RAN node for the first group of PDUs in the PDU set.

7. The computing system according to claim 1, wherein, The PDU set information includes an indication that the PDUs in the PDU set have been sent via another access tributary.

8. The computing system according to claim 1, wherein, The non-3GPP access node includes non-3GPP interoperability functionality.

9. A method comprising: The PDU reception session involves indications of two access tributaries; Receive XRM PDUs that include a set of PDUs; Send the first set of PDUs in the PDU set to the RAN node; Send PDU set information to non-3GPP access nodes, the PDU set information including an indication of the size of the second group of PDUs in the PDU set and an indication to provide a report; Send the second group of PDUs in the PDU set to the non-3GPP access node; Send notification information to the RAN node, the notification information including information indicating the PDU sequence number associated with the second group of PDUs and information indicating the size of the second group of PDUs; Receive a report from the non-3GPP access node, the report indicating the number of PDUs received by the non-3GPP access node and successfully delivered to the WTRU; as well as The information from the report is sent to the RAN node.

10. The method according to claim 9, in, The notification information also includes an indication that a notification will be sent to the RAN node if the second set of PDUs is successfully delivered.

11. The method according to claim 9, in, The notification information also includes an indication that the data burst end (EOB) indication is associated with the second group of PDUs.

12. The method according to claim 9, in, Receiving the indication that the PDU session involves two access branches includes receiving an N4 rule indicating that the PDU session involves two access branches.

13. The method according to claim 12, It also includes determining the transmission of the first group of PDUs based on the N4 rule.

14. The method according to claim 9, wherein, The PDU set information includes an indication that the PDUs in the PDU set have been sent via another access tributary.

15. The method of claim 9, further comprising: For the first group of PDUs in the PDU set, the group size associated with the first group of PDUs is sent to the RAN node.

16. A computing system, comprising: Processor, the processor being configured to: Receive PDUs that include a set of PDUs; Send the first set of PDUs in the PDU set to the RAN node; Send PDU information to non-3GPP access nodes, the PDU information including an indication of the size of a second set of PDUs in the PDU set and an indication to provide feedback on the delivered PDUs; Send the second group of PDUs in the PDU set to the non-3GPP access node; Send notification information to the RAN node, the notification information including information indicating the PDU sequence number associated with the second group of PDUs and information indicating the size of the second group of PDUs; An indication of the number of PDUs received by the non-3GPP access node and successfully delivered to the WTRU; as well as The RAN node sends the indication of the number of PDUs received by the non-3GPP access node and delivered to the Radio Transmit and Receive Unit (WTRU).

17. The computing system according to claim 16, in, The notification information also includes an indication that a notification will be sent to the RAN node if the second set of PDUs is successfully delivered.

18. The computing system according to claim 16, in, The notification information also includes an indication that the data burst end (EOB) indication is associated with the second group of PDUs.

19. The computing system according to claim 16, in, The processor is also configured to receive N4 rules indicating that a PDU session involves two access branches.

20. The computing system according to claim 19, in, The processor is also configured to determine the transmission of the first group of PDUs based on the N4 rule.

Images