Method and apparatus for transmitting and receiving data in a new radio system

Abstract

Methods and apparatus for low latency transmission of sensor data and wireless modem data are described. A method may include associating, by a wireless transmit / receive unit (WTRU), a first unique data identifier (UDI) with the sensor data and a second UDI with the wireless modem data. The method may further include generating, by the WTRU, a mapping between the first UDI and a first network quality of service (QoS) flow identifier (QFI) and a mapping between the second UDI and a second network QFI. The method may further include transmitting, by the WTRU, the sensor data and the wireless modem data to a network node.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 908,799, filed on October 1, 2019, the content of which is incorporated herein by reference. Background Art

[0003] The 3rd Generation Partnership Project (3GPP) is working on identifying challenges in vertical applications related to wireless communication. Some upcoming cases focus on cyber - physical control applications, which may require a very high level of communication service availability. Some applications may also require very low end - to - end latency. For example, industrial use cases may require extremely low latency and determinism on the data path in and out of the network. Factory automation deals with the automated control, monitoring, and optimization of processes and workflows within a factory. This includes aspects such as closed - loop control applications (e.g., based on programmable logic or motion controllers) and robotics, as well as computer - integrated manufacturing. Factory automation is typically a key factor in achieving high - quality, cost - effective large - scale industrial production. The corresponding applications can be characterized as imposing the highest requirements on the underlying communication infrastructure, especially in terms of communication service availability, determinism, and latency. Improvements that allow existing frameworks to meet such requirements are currently under investigation, targeting 3GPP Release 17, which aims to support lower latency and determinism compared to the capabilities currently supported by 5th Generation (5G) New Radio (NR) technology. Thus, a factory control system can be an example of an application that may benefit from the methods, devices, and their improvements discussed herein. Summary of the Invention

[0004] Methods and devices for low - latency transmission of sensor data and wireless modem data are described herein. A method may include associating a first unique data identifier (UDI) with the sensor data and a second UDI with the wireless modem data by a wireless transmit / receive unit (WTRU). The method may also include generating, by the WTRU, a mapping between the first UDI and a first network Quality of Service (QoS) flow identifier (QFI) and a mapping between the second UDI and a second network QFI. The method may further include transmitting, by the WTRU, the sensor data and the wireless modem data to a network node. Brief Description of the Drawings

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

[0006] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments may be implemented;

[0007] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the Figure 1A illustrated communication system;

[0008] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the Figure 1A illustrated communication system;

[0009] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that can be used within the Figure 1A illustrated communication system;

[0010] Figure 2 illustrates a general scenario where a factory floor includes equipment (e.g., manufacturing equipment) 201 connected to a digital twin;

[0011] Figure 3 illustrates a general example of a traditional closed-loop control system;

[0012] Figure 4 illustrates a sensor adaptation function (SAF) implemented in an exemplary low-latency industrial control system;

[0013] Figure 5 is another example of an application that uses the SAF to carry sensor identifiers via a Quality of Service (QoS) flow identifier (QFI) framework;

[0014] Figure 6 depicts a specific implementation of the SAF that allows sensor data to be directly transmitted as a Service Data Adaptation Protocol (SDAP) service data unit (SDU) and received as an SDAP SDU while maintaining the QoS requirements associated with the sensor data;

[0015] Figure 7 is a flow chart depicting the transmission of packets from a transmitting SAF entity to receiving SDAP and SAF entities;

[0016] Figure 8 illustrates an exemplary specific implementation of the SAF in an NR system;

[0017] Figure 9 depicts two examples of unique data identifiers (UDIs) that can be carried in an SDAP header;

[0018] Figure 10 depicts an exemplary data flow and the mapping of unique data identifiers (UDIs) to flow IDs in an NR system;

[0019] Figure 11 depicts the SAF implemented in a vehicle-to-everything (V2X) model; and

[0020] Figure 12 shows the SAF within the representation of a V2X reference point. DETAILED DESCRIPTION

[0021] Figure 1A is a schematic diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcasts, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through the sharing of system resources, including wireless bandwidth. 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0022] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should 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 may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any one of which may be referred to as a station (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 telephones, personal digital assistants (PDA), smart phones, laptop computers, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

[0023] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as the CN 106, the Internet 110, and / or other networks 112. As an example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation Node Bs, such as g-node Bs (gNBs), new radio (NR) Node Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0024] Base station 114a may be part of RAN 104, 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 wireless signals on one or more carrier frequencies, and the base station may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, 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 the desired spatial direction.

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

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

[0027] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish the air interface 116.

[0028] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which may use NR to establish the air interface 116.

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

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

[0031] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as a commercial venue, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0032] The RAN 104 can communicate with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or Internet protocol voice (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 can provide call control, billing services, location-based services, prepaid calling, Internet connection, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A it should be understood that the RAN 104 and / or the CN 106 can communicate directly or indirectly with other RANs using the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that can utilize the NR radio technology, the CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0035] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0036] The processor 118 may be a general-purpose processor, a dedicated 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), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. AlthoughFigure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0037] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

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

[0041] The processor 118 may receive power from a power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0042] 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) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via an air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0043] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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 device 138 may include one or more sensors. The sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0044] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL (e.g., for reception)).

[0045] Figure 1C is a system diagram showing RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 may communicate with WTRU 102a, 102b, 102c via air interface 116 using E-UTRA radio technology. RAN 104 may also communicate with CN 106.

[0046] RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that RAN104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to WTRU 102a and / or receive wireless signals from WTRU 102a.

[0047] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As Figure 1C shown, the evolved Node Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0048] 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. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0050] The SGW 164 may be connected to each of the evolved Node Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between evolved Node Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0052] CN 106 can facilitate communication with other networks. For example, CN 106 can provide access to a circuit-switched network (such as the PSTN 108) for the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108 or can communicate with the IP gateway. Additionally, CN 106 can provide access to other networks 112 for the WTRUs 102a, 102b, 102c, and the other networks can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0054] In a representative embodiment, the other network 112 can be a WLAN.

[0055] A WLAN in infrastructure basic service 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 access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating outside the BSS and destined for an STA can reach the STA through the AP and can be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS can be sent through the AP, e.g., where the 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 and a destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode can sometimes be referred to as an "ad-hoc" communication mode in this document.

[0056] When operating in an 802.11ac infrastructure mode or a similar operating mode, the AP can transmit beacons on a fixed channel (such as the primary channel). The primary channel can be of a fixed width (e.g., 20 MHz bandwidth) or dynamically set width. 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. For CSMA / CA, the STA (e.g., each STA) (including the AP) can listen to the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0057] A High Throughput (HT) STA can communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0058] A Very High Throughput (VHT) STA can support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. The 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. The 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). For the 80 + 80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Each stream can be individually processed with an Inverse Fast Fourier Transform (IFFT) and time - domain processing. These streams can be mapped to two 80 MHz channels and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80 + 80 configuration described above can be reversed and the combined data can be sent to the Medium Access Control (MAC).

[0059] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (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 meter type control / machine type communication (MTC), such as MTC devices in a macro coverage area. The MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. The MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0060] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operation bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or restricted by the STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In the example of 802.11ah, for an STA that supports (e.g., only supports) the 1 MHz mode (e.g., an MTC type device), the primary channel may 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 operation modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (only supporting the 1 MHz operation mode) is transmitting to the AP, all available frequency bands may be considered busy even if most of the available bands remain idle.

[0061] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In 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.

[0062] Figure 1D is a system diagram showing RAN 104 and CN 106 according to one embodiment. As noted above, RAN104 may communicate with WTRUs 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 104 may also communicate with CN106.

[0063] The RAN 104 may include gNBs 180a, 180b, 180c, but it should be understood that, while remaining consistent with the embodiments, the RAN 104 may include any number of gNBs. Each of the gNBs 180a, 180b, 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive a coordinated transmission from the gNB 180a and the gNB 180b (and / or gNB 180c).

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

[0065] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with or be connected to gNBs 180a, 180b, 180c while also communicating with or being connected to other RANs (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can be used as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

[0066] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0067] Figure 1DThe CN 106 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 data networks (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slices in order to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182a, 182b may provide control plane functions for handovers between the RAN 104 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0070] UPF 184a and 184b can be connected via the N3 interface to one or more of gNBs 180a, 180b, and 180c in RAN 104, and these gNBs can provide access to a packet switched network (such as the Internet 110) to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPF 184a and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, etc.

[0071] CN 106 can facilitate communication with other networks. For example, CN 106 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108 or can communicate with this IP gateway. Additionally, CN 106 can provide access to other networks 112 to WTRUs 102a, 102b, and 102c, and these other networks can 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 DNs 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 DNs 185a and 185b.

[0072] In view of Figures 1A to 1D and Figures 1A to 1D the corresponding descriptions, one or more or all of the functions described herein with reference to one or more of the following: one or more functions or all functions of WTRUs 102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to mimic one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0073] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being 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. The one or more simulation devices can perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or perform tests using over-the-air wireless communication.

[0074] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement tests of one or more components. The one or more simulation devices can be test devices. Direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0075] Using the current 5G NR ultra-reliable low-latency communication (URLLC) transmission scheme, today's radio access network (RAN) latency can be reduced to 1 ms. This reduction may only apply to the RAN user plane latency and may not consider application processing, transmission processing, or the conversion of user plane (UP) packets to Internet Protocol (IP) packets (in the case of using the IP protocol). This means that the amount of processing that can be performed within the time budget allowed by the application may depend on the achievable end-to-end network latency, not just the RAN latency. The lower the achievable end-to-end network latency, the greater the time budget for application processing.

[0076] Industrial use cases, especially in closed-loop control systems, may require low latency and determinism of the network. This latency may be required not only at the radio level but also end-to-end (including the radio layer, transport layer, core layer, and application (including processing) layer). 3GPP is currently starting to conduct research on industrial vertical markets for Release 17, with the aim of supporting lower latency and determinism compared to what 5G NR can currently achieve.

[0077] Figure 2A general scenario is shown where a factory floor includes equipment (e.g., manufacturing equipment) 201 connected to a digital twin, which can be accessed, for example, via a locally available multi-access edge computing (MEC) platform or the cloud, as shown at 202. The digital twin can refer to a digital representation of a physical object that interacts with other digital systems. To be able to offload functions (e.g., control functions) to the digital twin system, low one-way latency and round-trip latency may be required. The control process can be performed by the digital twin based on data periodically or aperiodically received from sensors monitoring activities on the factory floor.

[0078] 3GPP encourages research on RAN-centric data collection mechanisms. Minimized drive test (MDT) provides one such mechanism. The MDT function was introduced in 3GPP Long Term Evolution Release 10 to support the collection of data directly from one or more WTRUs via a control plane mechanism and reduce the costs associated with drive testing (e.g., driving a vehicle to physical network locations). MDT was initially used to send network optimization data to the RAN and reduce operating costs. The initial design of MDT was not intended to transfer large amounts of data originating from WTRUs to the network. However, the new RAN architecture in NR (e.g., the central unit (CU) and distributed unit (DU) interfaces), more powerful storage and computing capabilities, and emerging technologies in the industry (e.g., machine learning) provide new opportunities for data collection and utilization, thus driving further research and investigation into potential enhancements.

[0079] Other methods can also be used to perform data collection. For example, limited data collection can also be performed via sidelink applications and / or via a proprietary sidelink implementation.

[0080] The methods and apparatuses described herein can solve the problem of how to send sensor data from a WTRU to the network in a deterministic manner. The embodiments disclosed herein can also solve the problem of how to identify the source of transmission at the receiving end (e.g., in scenarios involving a large number of industrial sensors). For example, wireless data collection can be performed via MDT or via sidelink applications. MDT can allow specific measurement values to be sent via a control channel. On the other hand, the sidelink can allow a proprietary implementation of an application to send data via a sidelink server application in the core network. One problem with MDT is that it may not allow general data transmission or prioritization of one or more data sources. Such problems with the MDT data path may become apparent as the amount of data sent via MDT increases. As the amount of sensor data sent via the control plane (MDT) increases, the SRB queue may become unnecessarily congested and block important configuration signaling. In addition, MDT may not provide QoS differentiation between MDT data and configuration signaling, or differentiation between data from different sources.

[0081] One problem with side link methods is that they may rely on proprietary mechanisms and may not provide determinism and low latency for closed-loop control systems. When sending low-latency data via the side link, the side link data may need to cycle through the Core Network Network Data Analytics Function (NWDAF), which may not be required if the data has been consumed near the RAN. For the current NR QoS framework, there may be additional problems with the scalability of dedicated radio bearers (DRBs) in factory use cases where traffic differentiation is required. The NR QoS framework may be able to differentiate traffic based on traffic type (i.e., similar traffic types can be mapped to the same QFI and then again to a DRB). In the NR system, the number of supported DRBs may depend on the logical channel ID (LCID) space. The number of supported Quality of Service Flow Identifiers (QFI) may be limited by the 6-bit header in the Service Data Adaptation Protocol (SDAP) header and may also be enforced by the core network. As the number of sensors attached to a UE (e.g., an industrial WTRU) increases (e.g., 100 to 1000 sensors in a machine), the traffic-based flow differentiation framework may not scale or provide information about data source destinations because the differentiation is based on traffic type. Even if the sensors are grouped into multiple WTRUs, the amount of DRB resources shared in a fifth-generation Node B (gNB) (e.g., memory or processing capacity) may be fixed, such that allowing each WTRU and each PDU session to have more DRBs may not be sufficient to solve the problem.

[0082] This document describes various solutions to the above problems. One solution proposed for the above problems may be to introduce a new user plane data path for low-latency situations. This data path can be implemented via an adaptation function in the SDAP, which can link one or more data producers and one or more consumers. The solution can be data agnostic and can be used, for example, in scenarios where the RAN (e.g., via virtualized applications attached to the gNB) collects data from WTRU peripherals.

[0083] Some solutions may introduce new functions to the WTRU (e.g., as an SDAP mechanism) as well as identifiers associated with one or more sensing data sources. In addition to traffic-based differentiation (i.e., based on QFI), this may also allow low-latency systems to perform data source (i.e., sensor) differentiation. Notably, the same mechanism can be applied to WTRU sensing data originating from WTRU peripherals. The sensor adaptation function introduced by the present invention can be directly connected to the user plane.

[0084] The solution enables data to be transparently and directly transmitted from the WTRU to the RAN CU while maintaining the QoS of each transmitted data stream. A network implementing one or more aspects of the solution can associate the WTRU unique data identifier (UDI) and the QFI via a sensor adaptation function (SAF) and an SAF controller. In some solutions, the UE can directly transmit peripheral sensor data as SDAP SDUs to the central unit (CU) via the user plane pipeline and maintain one or more global identifiers of the sensor / drive unit. According to some solutions, sensor data can be obtained via a WTRU modem-level interface with factory equipment (i.e., the WTRU vendor can implement a proprietary interface between the application processor and the modem). According to some embodiments, the solution can be symmetric. For example, both the transmitting entity and the receiving entity can have data producer, consumer entities, and / or SAF functions that provide UDI association capabilities. Some solutions can also allow the RAN gNBCU to directly process the received WTRU data and directly send data to the WTRU. Some solutions can provide improvements to the sidelink implementation. For example, the transmitting endpoint and the receiving endpoint can also be implemented in a sidelink server simulated in the RAN. In this case, the SAF can use the PC5 interface for communication. The UDI mechanism can remain the same.

[0085] This document describes various benefits of the proposed solutions. One or more of these solutions can allow the 3GPP system to have one or more additional, general, and low-latency data paths between the WTRU and the gNB, where the priority of each individual sensor data stream can be controlled via the 5G NR QoS framework. The UDI can allow the flow framework to be extended without losing backward compatibility (e.g., by modifying the SDAP QFI length). Additionally, the mechanisms according to the proposed solutions can allow the 3GPP RAN data framework to evolve beyond wireless data transmission (i.e., MDT). As generally discussed in the above paragraphs, the desire to provide greater functionality within a closed-loop control system can be a motivating factor.

[0086] The SAF can be used to provide information from the WTRU to the network and vice versa. The SAF can allow industrial control systems to be directly attached to the SDAP layer (e.g., via the gNB or the distributed unit (DU) of the gNB) and reduce latency while maintaining the advantages provided by deterministic radio systems (low latency, duplication, retransmission, etc.). Additionally, the SAF can allow traffic to be differentiated not only based on QoS requirements but also based on the originating source.

[0087] Figure 3Shows a general example of a traditional closed-loop control system. The motion controller 301 can interact with the actuator 302, which can initiate process 303 according to instructions from the motion controller 301. Next, process 303 can trigger sensor 304 to generate feedback or measurement results based on the output from process 303. Sensor 304 can directly transmit the actual value of the feedback or measurement results to the motion controller 301, and then, the motion controller can analyze or process the feedback or measurement to provide commands to the actuator 302. In this case, the data consumer entity can be the motion controller, and the data producer entity can be the sensor.

[0088] Figure 4 Shows the SAF implemented in an exemplary low-latency industrial control system. A WTRU or industrial WTRU 410 operating in an industrial system (e.g., manufacturing operations in a factory floor) may include an actuator 411, one or more components 412 responsible for performing industrial processes, sensors 413a and 413b, and a sensor adaptation function (SAF) 414, or communicate directly with them. The WTRU or industrial WTRU 410 can communicate with the gNB 420 via an interface (e.g., as shown, the NR air interface). The gNB 420 can be configured with a SAF 421, which is configured to receive data streams from the SAF 414 of the WTRU. The SAF 421 can be implemented directly in the SDAP layer or in the DU of the gNB 420. The SAF 421 can interact with the analysis component 431 and / or one or more motion controllers 432, which can be implemented in a virtualized platform (such as a MEC platform). The actuator 411 can initiate or update instructions for the processing component 412. The sensors 413a and 413b can generate feedback or measurement results based on the output from the processing component 412 and subsequently provide the feedback or measurement results to the SAF 414. The SAF 414 can transmit the feedback or measurement results to the SAF 421 of the gNB 420, which can then route the data stream to the analysis component 431 and / or the motion controller 432 at the virtualized platform 430. The analysis component 431 can process the feedback or measurement results, which can instruct the motion controller 432 to provide instructions or adjustments by which the WTRU or industrial WTRU 310 can perform the industrial process.

[0089] Figure 5Another example of an application that uses SAF to carry sensor identifiers via the QFI framework. An industrial process can be performed on the factory floor 501, where a data producer entity 511 sends a data stream along a low-latency path to a digital twin implemented in a cloud-based or multi-access edge platform 502. The digital twin can have a corresponding data consumer entity 512 that receives the data stream from the data producer entity 511. The data producer entity 513 can send a data stream to a data consumer entity 514 on the factory floor via a low-latency data path. As Figure 5 shown, the application 515 can perform an analysis of control signaling via anomaly detection. For example, when receiving feedback or measurement information from the factory floor via entities 511 and 512, the anomaly detection application 515 can process the information and cause a control command to be returned to the factory floor via entities 513 and 514. In an industrial anomaly detection scenario, the faster the machine stops or the faster the control path changes, the more the system can avoid catastrophic failures. Therefore, in the case of lower latency, the consumer can be allocated more time to process the data. Figure 5 Also shown is a device that generates multiple types of control signals, and the receiving application (e.g., DNN-based anomaly detection) can use these multiple types of control signals as input features. In a complex system, these input features (i.e., sensor readings) can have different latency requirements. Therefore, as Figure 5 depicted, the data path can pass through the SDAP layers 516 and 517 on the transmit side and the receive side. The SDAP layer can include a SAF entity that can associate a data stream from one or more sensors with a UDI. By identifying the data source, the SDAP layer and / or SAF 516 can determine a priority (e.g., QoS flow identifier (QFI)) corresponding to the data stream before forwarding the data stream to the receiving SDAP layer / SAF 517 and provide such information when forwarding the data stream to the receiving SDAP layer / SAF. The receiving SDAP layer / SAF 517 can use the identifier according to the UDI to transmit the data stream to the data consumer entity 512 and the application 515. The application 515 can process the data stream based on the UDI and, for example, provide a control data stream to the data consumer entity 514 via the SDAP layers 516 and 517. The SDAP layers 517 and 516 can again associate the control data stream with the UDI and map the stream to a QFI, which can preserve the source identification and priority information when received by the data consumer entity 514.

[0090] Figure 6Depicts a specific implementation of the SAF that allows sensor data to be directly transmitted and received as an SDAP SDU while maintaining the QoS requirements associated with the sensor data. The SAF 611 can be symmetric, as shown by elements 611 and 614, meaning it can be defined on both the transmitter side 601 and the receiver side 602. The SDAP SDU can be associated with one or more unique data identifiers (UDIs). The SAF 611 can map the UDI to one or more QFIs defined by the NR framework. Each SAF can have a control entity (e.g., shown at 612 and 616) responsible for negotiating QoS mapping with the NR core network functions. If needed, the control entity 612 can send requests for QFI add / modify or release operations. The SAF function can be implemented in the data producer entity or the data consumer entity, or the function can be directly provided by the SDAP entity.

[0091] At the transmitter 601, the SAF 611 can receive data packets associated with the UDI from the data producer entity 613 and map these data packets to the correct QFI based on a pre-configured mapping. At the receiver, the SAF 614 can receive the SDAP PDU / SDU, map the QFI to the UDI, and provide the data stream associated with the UDI to the data consumer entity 615. Additionally, in some solutions at the receiver, the SDAP PDU / SDU can be directly provided to the Internet protocol layer for external transmission without going through the SAF 614.

[0092] According to a specific implementation, the UDI can be an identifier defined only by the application and transparently passed from the data producer entity to the data consumer entity, or it can be a specific identifier representing a value from a specification that describes standardized parameters associated with the UDI value. The UDI can be associated with the sensed data or assigned to the sensed data and passed to the SAF. The SAF can map the UDI to a QoS flow ID, and the sensor data can be transmitted to the receiving entity. Then, before the data is transmitted to the data consumer entity, the SAF can associate the UDI with the data stream.

[0093] The SAF can be located, embodied, or implemented inside or outside the SDAP entity. The SAF and / or the SDAP entity can be located, embodied, or implemented on the transmit side and the receive side (e.g., a WTRU and a gNB or a base station) via hardware or software. For example, a processor, an FPGA transmitter / receiver, and / or one or more antennas can provide the functions of the SAF and / or the SDAP entity.

[0094] According to the embodiments described herein, new functionality may be provided to the SDAP layer or entity via the SAF. For example, the SDAP controller may negotiate the QFI-to-UDI mapping with data producer and / or consumer entities and the network. If a QFI establishment or remapping is needed, this may be performed via a legacy mechanism (e.g., at the SDAP layer, packets being transmitted may be marked according to the relevant QFI). When receiving data from an external system, the data producer entity may associate a unique data identifier with the data stream, generate a PDU, and transmit the PDU to the SDAP layer. The SDAP entity may receive the data in an SDAP SDU with a UDI and associate it with a QoS flow ID. The SDAP entity may transmit the data to the lower layer via a legacy mechanism. The receiving SDAP entity may be configured with a flow having a data consumer / producer association. Then, the receiving SDAP entity may transmit the SDAP SDU to the data consumer. The data consumer may receive the PDU and transmit the data stream to an external entity according to the UDI.

[0095] Figure 7 is a flowchart depicting the transmission of packets from a transmitting SAF entity to receiving SDAP and SAF entities. At Figure 7 the transmitting entity, at 701, the data producer entity may wait until it has data to send. If there is data to send and, at 702, it is determined that there is no UDI-to-QFI mapping in the transmitting SAF function, the SAF control function may configure the QFI-to-UDI mapping and request QFI establishment, modification, or removal from the corresponding core network entity, as shown at 703. If there is data to send and there is a UDI-to-QFI mapping, then at 704, the SDU is associated with header information, and at 705, the PDU is transmitted to the QFI channel via a legacy SDAP mechanism.

[0096] At Figure 7At the receiving entity, at 706, the receiving SAF entity may wait until data associated with the receiving SAF / data consumer entity exists in the QFI. Once data with an SDAP flow mapping is received at the receiving SAF, the packet encapsulating the data may be transmitted to the receiving SAF, as shown at 707. At 708, in the case where the information is included in the header, the receiving SAF may associate the QFI information with the UDI information. If the information is included in the header, then at 709, the receiving SAF may transmit the SDU to the data consumer entity based on the UDI information associated with the data. If the receiving SAF entity is unable to retrieve the UDI-to-QFI mapping from the header, the receiving SAF may send a message to the SAF control function at the receiving or transmitting entity indicating that the UDI-to-QFI mapping cannot be found. In addition or alternatively, the receiving SAF may request that the information be sent separately (e.g., from the controller or the transmitting SAF entity) to allow the operation to continue; otherwise, the receiving SAF may only abort the operation.

[0097] Figure 8Shows an exemplary embodiment of the SAF in the NR system. The NR system may include a WTRU that communicates with a network node of a radio access network (e.g., a next generation (NG) RAN) via a radio interface (e.g., an air interface (Uu)). The transmitting entity 810 defined at the SDAP layer may receive data from a data producer 811 and SDUs associated with QoS requirements (e.g., QoS flows). The QoS flow may have an associated QoS flow ID (QFI), or a QFI may be assigned or allocated at the SDAP layer. The data from the data producer and the data stream may be passed to the SAF 812 at the transmitting SDAP entity 810 in the SDAP SDU. The SAF may associate, assign, or allocate a UDI with the data from the data producer such that the data is associated with a QoS flow (e.g., via a UDI to QoS flow ID association). The transmitting SDAP entity 810 may include a function that allows mapping of a QoS flow to a dedicated radio bearer (DRB). The SDAP entity 810 may have an additional function that allows configuration of an SDAP header for an SDU received at the SDAP layer. The header may include one or more of the information associated with the QoS flow to DRB mapping or the association between the UDI and the QoS flow. If the header is configured, the transmitting SDAP entity 810 may add an SDAP header to the SDU to produce a PDU for transmission to the receiving SDAP entity 820 using the radio interface. If the header is not configured, the transmitting entity 810 may transmit the SDU to the receiving SDAP entity 820 without adding one or more headers. The SDU or PDU may be received at the receiving SDAP entity 820. The receiving SDAP entity 820 may determine whether an SDAP header is configured. If the SDAP header is configured, the receiving SDAP entity 820 may determine a reflexive QoS flow to DRB mapping based on, for example, a QoS flow identifier included in one or more headers. The receiving SDAP entity may remove one or more headers before forwarding the payload of the PDU to other network elements. If an SDAP header is not configured for the SDU, the receiving SDAP entity may forward the SDU to other network elements only via the data stream. In addition or alternatively, the receiving SDAP entity may be configured with a SAF 821. The SAF 821 may be configured to receive the SDU or PDU sent by the transmitting SDAP entity 810. The SAF may be able to associate the SDU or PDU with a QoS flow (e.g., based on the QFI) and further associate the QoS flow with one or both of the data producer entity 811 or the data consumer entity 822 (e.g., based on the UDI). When configured, the QFI or UDI information used to derive the relationship may be included in the SDAP header or signaled between the SAFs 812 and 821 via control signaling.If a header is included in the received PDU, the SAF 821 may remove one or more headers and transfer the data PDU to the data consumer entity.

[0098] Figure 9 Two examples of UDIs that can be carried in the SDAP header are depicted (e.g., shown by headers 910 and 920). The UDI can be an identifier for indicating a device, application, or peripheral data source. The UDI can be an integer or a tuple, or it can be an integer referring to a configuration tuple. In some solutions, the UDI can be transmitted via SDAP control or data packets, and the UDI association (e.g., QFI / PFI) can be transmitted via RRC signaling. The UDI can be used to maintain source sensor information from the data producer entity to the consumer entity. More specifically, the UDI can be different from the QoS flow ID (QFI) used in the 5G core network and can also be different from the ProSe network flow identifier (PFI). The UDI can be mapped to the QFI or PFI of the NR system through the SAF function. As Figure 9 shown, the SDAP header can include a UDI using one octet (e.g., as shown by header 920) or multiple octets (e.g., as shown by header 920). The SDAP header can also include a 1-bit data / control (D / C) indicator that indicates whether the SDAP PDU is an SDAP data PDU or an SDAP control PDU. The header can also include a QFI field indicating the ID of the QoS flow to which the SDAP PDU belongs.

[0099] Figure 10 An exemplary data flow and the mapping of the unique data identifier (UDI) to the flow ID of the NR system are depicted. The data producer entity and the consumer entity can be used to interact with actual device sensors. In addition to connecting the data source to the data consumption application, such entities can also connect the sensors to the SAF function. The sensor adaptation function (SAF) can map the unique data identifier corresponding to the data flow originating from the sensor or manufacturing device to the 3GPP system. As shown at 1012 and 1014, the SAF can be implemented within both the transmitting entity and the receiving entity. Each SAF can also have control entities 1013 and 1015 on the transmitting side and the receiving side respectively, which configure, control, and negotiate the SAF parameters and RAN parameters (e.g., UDI to QFI mapping and flow addition / modification / release). The data producer entity 1011 can be connected to the device peripheral and interact with the device bus. The producer entity 1011 can have a mechanism for generating SAF SDUs. The data consumer entity 1016 can receive the SAF SDUs generated and transmitted by the data producer entity 1011. The system can be symmetric such that both the WTRU and the network have corresponding entities.

[0100] This document describes other aspects of the SAF control function. One purpose of the SAF control function can be to control the SAF function and to coordinate the SAF UDI to QFI mapping with RAN and 5G core network entities. The SAF control function can request to add, modify, or remove QFIs from the core network and then initiate the corresponding QoS flow add, modify, or remove procedures. The SAF control function can also configure and coordinate data producer entities and consumer entities. For example, when it is necessary to assign one or more unique data identifiers for a specific sensor function, the control function can assign free UDIs for these specific sensors. The SAF control function can be centralized or can have two corresponding components on the transmit side and the receive side. The SAF components can share the UDI configuration between these two SAF entities.

[0101] The control function can also know the sensor type identifier, which can be mapped to a standardized sensor category. Then, the SAF can request to add and / or modify QFIs based on the category. The sensor adaptation controller function can include: creating UDI to QFI associations; updating UDI to QFI associations; terminating UDI to QFI associations; requesting new QFIs and / or QFI modifications from the core network (e.g., via the Policy Control Function (PCF)); assigning one or more UDIs to producers; mapping UDIs to sensor type identifiers; or transmitting UDI to QFI mapping information.

[0102] It may be necessary to transfer the QFI to UDI mapping information from the transmit entity to the receive entity. There can be several methods for transferring the association. For example, in some embodiments, the transfer can be performed via explicit RRC signaling (e.g., by sending an RRC configuration to the SAF controller). In some embodiments, the transmit entity can use the SAF function with a modified header. For example, an in-band signaling mechanism such as a header can be used (e.g., in the case where the UDI is placed in the data or control element of the SDAP layer). When receiving the header, the SAF at the receiver side can associate the QFI and UDI without explicit control signaling. A UDI can be associated with the same QFI one or more times.

[0103] This document describes methods for activating and deactivating data flows. When data transmission starts or ends, it may be necessary to activate or deactivate the data flows associated with UDIs. When receiving data from a data producer entity, the SAF can perform the data flow procedure and start transmitting packets with UDI associations to the SDAP entity. For example, when the flow associated with a UDI terminates, when explicit RRC signaling for terminating the mapping has been received, or when the UDI of the transmit entity terminates, the data producer entity and / or the SAF can terminate or deactivate the data flow.

[0104] This document describes other aspects of a data producer entity. A data producer entity may be defined as a logical entity that produces data corresponding to a WTRU's radio interface or other peripheral devices / interfaces (e.g., sensors). One purpose of the data producer entity may be to provide an interface entity to the 3GPP system from which data can be read in a specified format. A data source may be used to provide specified 3GPP measurement results, or the data source may be associated with a peripheral device of a terminal device. For example, each data producer entity may have a peer data consumer entity that consumes the produced data and feeds the produced data to other parts of the 3GPP system or an external data processing entity. The data producer entity may be a corresponding data consumer entity on the receiving side of a transmission link. From the perspective of the 3GPP system, the data producer entity may generate PDUs that can be recognized as SDAP SDUs. The entity may be identified by a unified data identifier (UDI) associated with a QFI. The UDI may be added to the header of the PDU produced by the data producer entity.

[0105] It may be desirable for the data producer entity to be able to obtain data from various sources. If certain general data is available, an application (such as the application generally described above with respect to Figure 2 executing various system processes and optimizations. For example, if battery and dynamic power consumption data is available for a certain application, the application may perform power optimization on the system. Such mechanisms for being able to obtain these types of general data only represent one aspect of the presently disclosed embodiments.

[0106] The data provided by the data producer entity may include traditional 3GPP-specified measurement results, but is not limited to those specified by 3GPP. For example, the data source may include a wireless data interface, a radio frequency (RF) front end (e.g., including circuitry responsible for processing received signals at the original incoming frequency), an RF transceiver, a baseband module or processor, a WIFI and / or Bluetooth module, an NFC controller, and / or an RF board. The data source may include a sensor associated with a battery that can provide temperature, voltage, output voltage, charge, discharge, and / or wireless charging module information. The data source may also include position sensors such as accelerometers, barometers, gyroscopes, or ambient light sensors, as well as sensors or modules configured to provide location information via GPS, GLONASS, Galileo, digital compasses, iBeacon, or other technologies. The data source may provide system information such as CPU, GPU, and / or neural engine power consumption information, memory utilization, cache miss rate, and statistical values from each individual hardware component. System peripherals such as complementary metal oxide semiconductor (CMOS) image sensors, light detection and ranging (lidar), radio detection and ranging (radar), or sound navigation and ranging (sonar) systems may also be used as data sources.

[0107] The data producer entity may provide information to the SAF such that packets can be transmitted to the 3GPP system. This information may include information associated with the size of the data (e.g., the size of the PDU or SDU), as well as identifier information associated with a specific data stream (e.g., UDI) and / or header size or type information. For example, the data producer entity may indicate the size of the data PDU or SDU to calculate the required packet size. Such payload information may be provided together with the header information or separately from the header information, which may be configured individually or pre-configured. In some solutions, the header size may be fixed and the SAF or other entity knows the receiving size. Alternatively or in addition, the data producer entity may use a type indicator (e.g., a field with a length of 1-3 bits) that indicates the format of the header. The header information may be configured by the controller.

[0108] In the case of using multiple data streams, the producer entity may be associated with one or more data streams via the SAF through an identifier (e.g., UDI). This may allow the data streams to be uniquely identified by the data consumer entity. The identifier may be transmitted via in-band signaling or out-of-band signaling. The identifier and / or associated information may be exchanged between the data producer and data consumer entities, for example, via a central configuration controller or by including the information in the header. In some solutions, the header content may be configured by the controller. The identifier and / or associated information may include: a unique data identifier (UDI) that identifies the data stream; or a data model identifier (DMI) that identifies the data model of the payload and may be a single identifier or a tuple. The identifier and / or associated information may also include the payload size. In some solutions, the data consumer entity may also directly receive the payload size information from the receiving SDAP layer. The identifier and / or associated information may also include one or more security keys.

[0109] Other aspects of the data consumer entity are described herein. The data consumer entity may be a peer entity of the data producer entity. The data consumer entity may receive the SDAP SDU and directly consume the received data or pass the received data to another entity. The data consumer entity may use the UDI information associated with the data stream and / or the SDAP SDU to associate the data stream identifier with the corresponding data model. The data consumer may be implemented as a CPU, GPU, FPGA, or DNN accelerator. The data consumer entity may process the data by itself or forward the data. For example, the data consumer entity may perform transformation, filtering, inference, or storage operations using the data.

[0110] This document describes a solution for implementing a sensor adaptation function within a sidelink framework. A vehicle-to-everything (V2X) model may need to expose V2X application servers via one or more network exposure functions. In some cases, the SAF mechanism can be used with sidelink applications to perform low-latency processing. For example, when a low-latency application is deployed near a road service unit (RSU), the application server can use SAF to obtain access to WTRU measurement results, peripheral devices, or other sensor data. The V2X layer can use UDI to map the data flow between data consumer and producer peripheral devices. The V2X application or application server can be implemented in or located in the gNB, or near the gNB. The mechanism can operate substantially as described above with respect to Figures 4 to 10 and related embodiments.

[0111] Figure 11 The SAF implemented in the V2X model is depicted. As shown, a data producer entity 1110 (e.g., transmitting WTRU) can send a data flow to a V2X application or application server. The data flow can pass through a V2X adaptation layer, which can be responsible for classifying and tagging PCI QoS flows. The SAF 1120 can be implemented in the V2X adaptation layer and can be used to map the UDI corresponding to the data flow between the data consumer and the data producer. Before being transmitted to the V2X application or application server, the data flow can be received by a data consumer entity 1130 (e.g., receiving WTRU). Figure 11 The SAF that can be used to map a V2X sidelink radio bearer (SLRB) is further shown. A data producer entity 1140 (e.g., transmitting WTRU) can transmit a data flow to the SDAP layer, where the SAF 1150 can be implemented. As generally described with respect to Figures 4 to 10 and related embodiments, the SAF can be used to map the UDI to the data flow. The data flow can be received by a data consumer entity 1160 (e.g., receiving WTRU) before being transmitted to the sidelink application.

[0112] Figure 12 The SAF within the representation of a V2X reference point is shown. The WTRU 1210 can communicate with a 5G access network (AN) 1220 via a PC5 reference point. The WTRU 1210 can be configured with a transmit SAF 1215 and the 5G-AN can be configured with a receive SAF 1225. As shown, the SAF 1215 and the SAF 1225 are capable of communicating via the PC5 reference point such that the V2X server is located in a virtualized gNB.

[0113] Although the features and elements have been described above in specific combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via 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 disks and digital versatile disks (DVDs)). A 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 wireless transmit / receive unit (WTRU), the WTRU comprising: a processor; and a transceiver; the transceiver being configured to receive configuration information associating a plurality of unique data identifiers (UDIs) with corresponding ones of a plurality of quality of service (QoS) flows; the transceiver being configured to receive first sensor data and information indicating one of the plurality of UDIs; the processor and the transceiver being configured to transmit a first protocol data unit (PDU) using one of the corresponding plurality of QoS flows, the first PDU including the first sensor data, wherein the one of the corresponding plurality of QoS flows is selected based on the received information indicating the one of the plurality of UDIs; the transceiver being configured to receive updated configuration information associating the one of the plurality of UDIs with another one of the corresponding plurality of QoS flows; the transceiver being configured to receive second sensor data and information indicating the one of the plurality of UDIs; the processor and the transceiver being configured to transmit a second protocol data unit (PDU) using the another one of the corresponding plurality of QoS flows, the second PDU including the second sensor data, wherein the another one of the corresponding plurality of QoS flows is selected based on the received information indicating the one of the plurality of UDIs.

2. The WTRU according to claim 1, wherein the first sensor data and the second sensor data are received from a data source, and wherein the sensor data received from the other data source is distinguished from the first sensor data and the second sensor data based on different UDIs transmitted together with the sensor data received from the other data source.

3. The WTRU according to claim 1, the transceiver being configured to transmit a message to a network node, the message requesting termination of the association between a UDI and a QoS flow.

4. The WTRU according to claim 1, the transceiver being configured to transmit configuration information to another WTRU, the configuration information including information associating the one of the plurality of UDIs with the one of the corresponding plurality of QoS flows.

5. The WTRU according to claim 1, wherein each of the first PDU and the second PDU includes a header, the header including information indicating the one of the plurality of UDIs.

6. The WTRU according to claim 1, wherein at least one of the configuration information or the updated configuration information is received from a network node.

7. The WTRU according to claim 1, wherein the updated configuration information is received in response to the transmission of the first PDU.

8. The WTRU according to claim 1, wherein the updated configuration information releases the association between the one of the plurality of UDIs and the one of the corresponding plurality of QoS flows.

9. The WTRU according to claim 2, wherein the data source provides one or more types of sensor data, the one or more types including: Wireless data; data associated with a battery; Location data; positioning data; system information; or system peripheral device data.

10. The WTRU according to claim 9, wherein the processor is configured to determine an association between a UDI and a QoS flow based on the type of sensor data received from each data source.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receiving configuration information associating a plurality of unique data identifiers (UDIs) with corresponding multiple quality of service (QoS) flows; Receiving first sensor data and information indicating one of the plurality of UDIs; Transmitting a first protocol data unit (PDU) using one of the corresponding multiple QoS flows, the first PDU including the first sensor data, wherein the one QoS flow among the corresponding multiple QoS flows is selected based on the received information indicating the one UDI among the plurality of UDIs; Receiving updated configuration information associating the one UDI among the plurality of UDIs with another QoS flow among the corresponding multiple QoS flows; Receiving second sensor data and information indicating the one UDI among the plurality of UDIs; And Transmitting a second protocol data unit (PDU) using the another QoS flow among the corresponding multiple QoS flows, the second PDU including the second sensor data, wherein the another QoS flow among the corresponding multiple QoS flows is selected based on the received information indicating the one UDI among the plurality of UDIs.

12. The method according to claim 11, wherein the first sensor data and the second sensor data are received from a data source, and wherein the data received from the other data source is distinguished from the first sensor data and the second sensor data based on different UDIs transmitted together with the data received from the other data source.

13. The method according to claim 11, further comprising transmitting a message to a network node requesting termination of an association between one of the plurality of UDIs and one of the corresponding multiple QoS flows.

14. The method according to claim 11, further comprising transmitting configuration information to another WTRU, the configuration information including information associating the one UDI among the plurality of UDIs with the one QoS flow among the corresponding multiple QoS flows.

15. The method according to claim 11, wherein each of the first PDU and the second PDU includes a header, the header including information indicating the one UDI among the plurality of UDIs.

16. The method according to claim 11, wherein at least one of the configuration information or the updated configuration information is received from a network node.

17. The method according to claim 11, wherein the updated configuration information is received in response to the transmission of the first PDU.

18. The method according to claim 11, wherein the updated configuration information releases the association between the one UDI among the plurality of UDIs and the one QoS flow among the corresponding plurality of QoS flows.

19. The method according to claim 12, wherein the data source provides one or more types of sensor data, and the one or more types include: Wireless data; data associated with the battery; location data; positioning data; system information; Or system peripheral device data.

20. The method according to claim 19, the method further comprising determining an association between a UDI and a QoS flow based on the type of the sensor data received from each data source.

Images