Congestion control procedure for pc5 communication

Abstract

An initiating wireless transmit receive unit (WTRU) includes circuitry configured to monitor, by the initiating WTRU, a level of congestion experienced by the initiating WTRU when communicating with at least one peer WTRU. And the initiating WTRU detects the congestion level and triggers the congestion control. The initiating WTRU sends at least one message based on the congestion level to reconfigure ongoing communications between the initiating WTRU and the at least one peer WTRU.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 805,558, filed February 14, 2019, which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] This disclosure relates to network communications, including, but not exclusively, to vehicular wireless communication technology services based on 5G communication architecture. Background Technology

[0004] Vehicle-to-everything (V2X) services can be part of the fifth-generation (5G) architecture. 5G communication systems can accommodate both vehicle-to-vehicle (V2V) and vehicle-to-everything (V2X) communication. The 5G specification defines various types of reference point interfaces. However, not all communication methods are defined. This disclosure addresses a problem in V2X communication where communication congestion affects V2V or V2X communication over PC5 reference point interfaces between multiple user equipment (UEs). Summary of the Invention

[0005] A method, apparatus, and computer-readable storage medium for resolving congestion in a WTRU communicating with a peer wireless transceiver unit (WTRU), comprising: an initiating WTRU monitoring the congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU (partial observation); the initiating WTRU detecting the congestion level triggering congestion control; and the initiating WTRU sending at least one message based on the congestion level to reconfigure ongoing communication between the initiating WTRU and at least one peer WTRU.

[0006] In a further feature, the initiating WTRU can reconfigure ongoing communication by sending at least one message based on the congestion level, using periodic messages. The periodic message can be one of a keep-alive message, a privacy-preserving message, and / or a key update message. At least one reconfiguration message can be a message that changes the interval of the periodic message.

[0007] In another feature, the initiating WTRU can send at least one message to reconfigure ongoing communication as a message indicating a change in Quality of Service (QoS). In one example, a QoS change could include changing the QoS parameter of the PC5 QoS Indicator (PQI) to a lower value compared to the current value.

[0008] In another feature, the reconfiguration message sent by the initiating WTRU can be an offload message to relocate ongoing communication to another communication medium. In one example, the offload message relocating ongoing communication to another communication medium may include offloading the ongoing communication to another radio access technology (RAT), wherein the initiating WTRU and at least one peer WTRU exchange access capabilities. In a further feature, the offload message may include a list of RATs specific to a vehicle-to-everything (V2X) service or V2X application, arranged in a preferred order.

[0009] In another feature, the initiating WTRU can send a release message for ongoing communication between the initiating WTRU and at least one peer WTRU. In yet another feature, the initiating WTRU can send a rejection message for an incoming communication request received at its location from a peer WTRU.

[0010] Although various embodiments are described and / or claimed herein, wherein apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any parts thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof. Unless expressly stated otherwise herein, features of one embodiment may be combined with those of another embodiment. Furthermore, embodiments and / or features of embodiments may be combined to achieve further advantageous results. Attached Figure Description

[0011] A more detailed understanding can be obtained from the following detailed description, given in conjunction with the accompanying drawings as examples. Like the detailed description, the figures in such drawings are illustrative. Thus, the drawings and detailed description should not be considered limiting, and other examples of equivalent utility are also possible. Furthermore, the same reference numerals (“references”) in the figures indicate the same elements, and wherein:

[0012] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented;

[0013] Figure 1B The illustration shows an embodiment that can be used Figure 1A The diagram shows a system diagram of an example WTRU used in a communication system.

[0014] Figure 1C The illustration shows an embodiment that can be used Figure 1A The diagram shows a system diagram of an example radio access network (RAN) and an example core network (CN) used in a communication system.

[0015] Figure 1D The illustration shows an embodiment that can be used Figure 1A The diagram shows a further example RAN and a further example CN used in the communication system.

[0016] Figure 2 A signal diagram describing the process of establishing a Layer 2 link for V2X services between peer WTRUs;

[0017] Figure 3 A signal diagram describing the Layer 2 link establishment process for WTRU;

[0018] Figure 4 An example signal diagram illustrating the WTRU of interest that initiates the link establishment process is described;

[0019] Figure 5 A signaling diagram is described to show which WTRU handles communication link reconfiguration;

[0020] Figure 6 A signal diagram illustrating a direct communication release message with a backoff timer is described;

[0021] Figure 7 A signal diagram illustrating a direct communication rejection message with a backoff timer is described;

[0022] Figure 8 A signal diagram illustrating the reconfiguration of unicast link spacing based on congestion levels received from peer WTRUs is described.

[0023] Figure 9 A signal diagram illustrating the reconfiguration of unicast link spacing based on the detected congestion level is described;

[0024] Figure 10 A signal diagram is described, illustrating the offloading of radio access technology due to congestion control using release messages;

[0025] Figure 11 A signal diagram illustrating the offloading of radio access technology due to congestion control using rejection messages is described; and

[0026] Figure 12 A signal diagram is described, illustrating the offloading of radio access technology due to congestion control using keep-alive messages. Detailed Implementation

[0027] Detailed description of illustrative embodiments will now be described with reference to the accompanying drawings. While this description provides detailed examples of possible implementations, it should be noted that these details are exemplary in purpose and in no way limit the scope of this application. Numerous specific details will be set forth in the following detailed description to provide a full understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits are not described in detail to avoid confusion with the following description. Furthermore, embodiments and examples not specifically described herein are also practiced and can be used to replace or combine with the embodiments and other examples described, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively, the “Provided”).

[0028] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing 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 DFT-Extended OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0029] like Figure 1AAs shown, the communication system 100 may include wireless transceiver 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 is 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. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “base 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 industrial and / or automated processing chain environments), 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.

[0030] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be configured to wirelessly engage 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 transceivers (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Although each of base stations 114a and 114b is described as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0031] 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further 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, one for each 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.

[0032] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 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.

[0033] 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 stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish 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).

[0034] In the 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 Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

[0036] 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 implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0037] 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., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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 Evolution of GSM (EDGE), GSM EDGE (GERAN), etc.

[0038] For example, Figure 1ABase station 114b can be a wireless router, home NodeB, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), 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-APro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114b does not need to access the Internet 110 via CN 106 / 115.

[0039] 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 WTRUs 102a, 102b, 102c, and 102d. Data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. 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 not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0040] 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 / Internet Protocol (TCP / IP), TCP from the Internet Protocol Suite, User Datagram Protocol (UDP), and / or IP. 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.

[0041] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the 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 base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0042] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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 should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0043] 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, and transceiver 120 can be coupled to transmitting / receiving element 122. Although Figure 1B While processor 118 and transceiver 120 are described as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0047] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) 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, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 may access and store information from any type of suitable 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 may access and store information from memory not physically located on WTRU 102 (such as a server or home computer (not shown)).

[0048] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can 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.

[0049] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or 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 the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0050] The processor 118 may further couple 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 device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos or videos), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth module, FM radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0051] 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 both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference through signal processing via hardware (e.g., a choke map) or via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, 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 either uplink (e.g., for transmission) or downlink (e.g., for reception)) are performed.

[0052] Figure 1C The diagram illustrates a system diagram of 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.

[0053] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may 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, eNode-B 160a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

[0055] 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 should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0057] The SGW 164 can connect to each eNode B 160a, 160b, or 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, or 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, or 102c, and managing and storing the context of WTRUs 102a, 102b, or 102c.

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

[0059] 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 traditional landline communication equipment. For example, CN 106 may include or can communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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.

[0060] Despite Figures 1A to 1D The WTRU is described as a wireless terminal, but in some representative embodiments, such a terminal may be expected to use a wired communication interface with a communication network (e.g., temporary or permanent).

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

[0062] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or other type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from a STA outside the BSS can reach and be delivered to the STA via the AP. Traffic originating 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 source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without 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 the "ad-hoc" communication mode in this document.

[0063] 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 20 MHz wide bandwidth) 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 (CSMA / CA) with collision avoidance can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0065] Ultra-high throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. A 40MHz and / or 80MHz channel can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0066] 802.11af and 802.11ah support Sub-1 GHz operating modes. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support instrument-type control / machine-type communication (such as MTC devices in macro coverage areas). MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) 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).

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

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

[0069] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0070] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c may 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. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to 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 embodiments, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0072] 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., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility 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 serve as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0073] 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, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and 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.

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

[0075] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used 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 SMF183a and 183b, managing registration areas, terminating (non-access stratum) (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 type being used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and / or services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies (such as WiFi)).

[0076] SMF 183a and 183b can connect to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b and configure service routes through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU / UEIP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0077] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks, such as the Internet, 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.

[0078] CN 115 can facilitate communication with other networks. For example, CN 115 may include or can 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, 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, 102c can be connected to DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and local data networks (DNs) 185a and 185b.

[0079] Given Figures 1A to 1D as well as Figures 1A to 1D The functions described herein, including one or more of the following, can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other devices described herein. An emulation device can be one or more devices configured to simulate 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.

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

[0081] One or more emulation devices may perform one or more (including all) functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be utilized in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., RF circuitry may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0082] The examples provided in this article do not limit the applicability of this topic to other wireless technologies, such as using the same or different principles that may be applicable.

[0083] As explained herein, a Radio Transmitter Receiver Unit (WTRU) can be an example of a User Equipment (UE). Therefore, the terms UE and WTRU can be used in the same context herein. The Layer 2 link establishment process for V2X services is as follows: Figure 2 As shown in the image. Reference Figure 2 Direct Communication Request (DCR) messages 206, 208, and 210 can be broadcast by WTRU 201, i.e., sent to the broadcast address associated with the application (such as a V2V or V2X application). The broadcast message can be received by other WTRUs, including WTRU 202, WTRU 203, and WTRU 204. Information about the V2X service requesting the establishment of a Layer 2 (L2) link (i.e., information about the broadcast V2X service) can be included in the DCR message to allow other (peer) WTRUs to decide whether to respond to the request. All WTRUs interested in using the V2X service broadcast by the DCR message can respond to the request. For example, Figure 2 The WTRU 202 in the middle responds to the DCR broadcast message with Direct Communication Receive (DCA) message 212. Figure 2WTRU 204 in the document responds to the DCR broadcast message with DCA message 214. This V2X service-oriented link conforms to 3GPP TR23.786 V1.1.0 (2019-01), which studies the architectural enhancements of EPS and 5G systems to support advanced V2X services (Release 16).

[0084] Figure 3 The diagram illustrates the Layer 2 link establishment process for a WTRU. Direct communication request messages 306, 308, and 310 can be sent by WTRU 301 using a broadcast mechanism, i.e., to a broadcast address associated with the application, such as WTRU 302, WTRU 303, or WTRU 304. The upper-layer identifier of WTRU 302 (e.g., upper-layer ID) is included in the direct communication request message to allow WTRU 302 to decide whether to respond to the request. WTRU 302 can send a Direct Communication Acceptance (DCA) message 312 in response to DCR message 306.

[0085] Alternative link establishment procedures are possible, where each WTRU may be interested in the advertised V2X service upon receiving a DCR message from the initiating WTRU (i.e., WTRU 301). The interested WTRU can then initiate a unicast link establishment procedure by sending its own DCR message to the initiating WTRU. In one alternative link establishment, the peer WTRU does not reply to the DCR message from the initiating WTRU. The procedure is as follows: Figure 4 As shown in the diagram. Here, the interested WTRU initiates a link establishment message. Although unicast communication is used as an example of PC5 communication in steps 406, 408, and 410, other types of PC5 communication can also be used between WTRUs. For example, if a broadcast discovery message is sent instead of a DCR message, the peer WTRU can learn the WTRU 401L2ID and establish a PC5 link, as shown in steps 412 and 414.

[0086] The initiating WTRU (e.g., WTRU 401) can broadcast supported V2X services on PC5 Radio Access Technology (RAT) (such as the 5G PC5 Reference Point Interface) via broadcast DCR messages 406, 408, and 410. Many WTRUs may be interested in such V2X services and can establish communication with the initiating WTRU. Similarly, many V2X services may be broadcast, so a WTRU may end up running multiple communications simultaneously to maintain and generate and / or receive data. In addition, unicast communication can be established with specific WTRUs, increasing the number of established communications, resource usage, etc. In one example, interested WTRU 2 sends DCR message 412 to initiating WTRU 401, and WTRU 401 can then respond with DCA message 414.

[0087] It is understandable that numerous ongoing communications on a WTRU can lead to congestion on the WTRU and / or RAT. Consequently, peer WTRUs may experience lower quality communication. That is, some V2X applications may fail to meet Quality of Service (QoS) requirements. In severe cases, communication on the PC5 interface may even be lost. Furthermore, lost communication due to congestion may cause peer WTRUs to attempt to re-establish links, creating even more congestion on the RAT and WTRU. Finally, multiple WTRUs may respond and establish unicast links with the initiating WTRU. Congestion can occur due to too much unicast communication established on the initiating WTRU. Therefore, techniques to address WTRU congestion are needed.

[0088] It should be noted that the V2X used in this disclosure is only an example of communication. The procedures defined herein can be applied to other types of communication, such as communication with other electronic devices (e.g., drones, trains, and maritime communications). This document describes a set of actions that a WTRU can take to resolve congestion issues. Any or all of these actions can be taken to resolve or otherwise reduce or isolate congestion. The WTRU can manage congestion by dynamically controlling its resource usage. Such dynamic control actions may include releasing existing communication or rejecting new communication requests. Other dynamic control operations may be adapting to existing communication, such as reducing control plane traffic, changing the required QoS, or offloading communication to another RAT.

[0089] According to a novel feature, the initiating WTRU can notify its congestion level when initiating a unicast link establishment or during ongoing PC5 unicast communication. The congestion level sent / notified to other WTRUs is the congestion level that the sending WTRU is experiencing or is known to the sending WTRU. This sending / notification of the congestion level by the sending WTRU enables interested peers or receiving WTRUs to decide, based on the congestion information, whether they should respond to the link establishment request from the initiating WTRU, or whether they should choose to ignore the link establishment request and wait for congestion to recover or decrease, or wait for the arrival of another less congested initiating WTRU supporting the same service.

[0090] Because congestion levels are constantly changing, they can be communicated in various ways, either at different times or periodically. For example, during the initiation of a unicast link establishment, or during keep-alive, privacy protection, and key update processes. Any periodic messages sent by the WTRU are candidates containing congestion level or status information. Due to congestion, the initiating WTRU may reject a communication establishment request from another WTRU, or it may release ongoing unicast communication. In both cases, a backoff interval and an appropriate reason code indicating that the rejection is due to congestion can be specified on the release and rejection messages. Therefore, the peer WTRU does not need to immediately retry (re)establish communication. A backoff timer is used on each peer WTRU using a Level 2 identifier (L2 ID). This backoff timer can also be each L2 ID and V2X application ID (Intelligent Transportation System Application Identifier - AID) or Provider Service Identifier (PSID), which is associated with the initiating WTRU's L2 ID and may also be associated with the V2X application.

[0091] When congestion is observed on a link, initiating a WTRU can reduce the amount of traffic exchanged on the signaling plane to limit congestion. For example, the keep-alive interval may be increased by a certain period. The privacy protection interval and key update interval may also be increased. Furthermore, if congestion is observed (or if congestion is no longer observed), initiating a WTRU can change the requested link QoS. New QoS values ​​can be specified, for example, to increase acceptable latency.

[0092] Another possibility when congestion is observed is to offload communications to another RAT. Offloading effectively relocates services from one communication medium / access to another. For example, communications on a 5G / NR PC5 (5G / New Radio PC5) might be offloaded to a Long Term Evolution (LTE) PC5 for a period of time. This action can be taken if the LTE PC5 is less congested when the WTRU is congested. The reverse is also possible; that is, moving the LTE PC5 to a 5G / NR PC5. To achieve this offloading, the initiating WTRU and the peer WTRU may need to exchange their capabilities. In this case, only unicast communications between the two WTRUs supporting both the LTE and 5G versions of the PC5 can be offloaded.

[0093] QoS profiles mapped to congestion levels and congestion control functions enabled or disabled can be provided to the WTRU. Furthermore, congestion thresholds can be configured so that the WTRU knows when congestion is too high and congestion control can be applied, or when congestion is low enough to cancel congestion control measures. Reverse congestion control measures can include reconfiguring the interval to a normal value, accepting new communication establishments again, etc. Although many procedures in this document are described from the perspective of interaction between WTRUs at the V2X / NAS / ProSe layer or higher, the same procedures apply to RRC signaling exchanges between WTRUs.

[0094] Based on the novel feature, congestion detection for WTRUs operating on PC5 RATs is based on link measurements. The Access Layer (AS) layer processes link measurements and can detect link congestion. The AS layer can send indications to the V2X layer to notify it of the congestion status (on / off) on a specific RAT. The congestion level can also be specified by the AS layer. Another possibility involves the AS layer providing measurement information to the V2X layer, which itself determines whether congestion has occurred. In any case, it is assumed that the V2X layer is aware of the congestion status.

[0095] Congestion on or associated with a WTRU can also be considered to be affected by factors such as the amount of ongoing communication, memory usage, and CPU usage. Congestion on a WTRU can be monitored by the V2X layer (or another layer interfacing with the V2X layer) and can be based on availability within the WTRU. For example, when determining the presence of congestion on a WTRU, the maximum amount of ongoing communication can be considered.

[0096] In the case of unicast communication between two WTRUs, both WTRUs can monitor and handle congestion, or only one of them can handle congestion. That is, both WTRUs can monitor their resource usage, notify them of their congestion levels, release existing communication, and / or reject new communication requests. However, one WTRU can be selected to handle the reconfiguration of existing communication.

[0097] For example, during communication establishment, a WTRU can determine which is responsible for handling communication reconfiguration. The initiating WTRU can request responsibility, and the responding WTRU allows responsibility assignment. Alternatively, the responding WTRU can request responsibility. The responding WTRU can be the WTRU that makes the final decision, or it can be predetermined that the responding WTRU has and maintains the reconfiguration responsibility. A WTRU may have responsibility for reconfiguring a specific communication, while for another communication, the peer WTRU has this responsibility.

[0098] Figure 5The illustrations show examples of how WTRU can determine which process handles communication reconfiguration. These examples are based on the three unicast link establishment methods described earlier. Figure 5 In the specific example shown, WTRU 501 requests responsibility for handling communication reconfiguration via DCR message 506. WTRU 502 accepts via DCA 512 and a first communication can be established between WTRU 501 and WTRU 502, where WTRU 501 handles the reconfiguration. A second communication can be established between WTRU 501 and WTRU-4, where WTRU-4 requests responsibility for reconfiguration using DCA message 514. Then, WTRU 503 can initiate communication with WTRU 501 via DCR message 516 and request reconfiguration processing. A third communication can be established between WTRU 503 and WTRU 501 via DCA message 518. Then, WTRU 502 initiates communication with WTRU 503 via DCR message 520 and requests reconfiguration processing for that communication. A fourth communication can be established between WTRU 502 and WTRU 503 via DCA message 522. It is important to note that WTRU 502 has two communications (one with WTRU 501 and one with WTRU 503) and may be handling reconfiguration for the communication only with WTRU 503 (communication #4). WTRU 501 handles the reconfiguration for the other communication (communication #1). Alternatively, the WTRU notifying the congestion level can implicitly always be responsible for reconfiguring the PC5 unicast link.

[0099] WTRUs can be configured to monitor congestion, and such WTRUs can notify other WTRUs of their congestion levels in different ways, as described below. Congestion levels can be notified as, for example, none, low, medium, high, etc. Congestion levels can also be notified as numeric information elements (IEs) in PC5 messages; for example, a congestion level IE represents a congestion level from an integer 0 to 10, where 0 represents no congestion and 10 represents a very high congestion level.

[0100] In the first example technique for notifying congestion levels, the initiating WTRU can send a Congestion Level Response (DCR) indicating its congestion level. Here, no link is established when the DCR is sent. The peer WTRU receives the DCR message, and if any of the peer WTRUs is interested in the V2X service, the peer WTRU evaluates whether the received congestion level of the initiating WTRU is acceptable. That is, whether the peer WTRU should establish a link with the initiating WTRU, or whether the peer WTRU should not establish a link due to the high congestion level, which is expected to provide poor quality communication and not meet the required QoS. The initiating WTRU can notify the congestion level on a per-V2X-service basis. The congestion level notification and the decision on establishing communication based on that congestion level are made in [the following context]. Figure 6 and Figure 7 As shown above.

[0101] In the second example technique for notifying congestion levels, the initiating WTRU can send a keep-alive message with a congestion level indication of the initiating WTRU. Here, a link has already been established between two peer WTRUs. The peer WTRU receiving such a keep-alive message can apply congestion control on the existing link, where the message also includes an indication of experiencing congestion (i.e., congestion level and congestion indication), as discussed below. A backoff interval for periodic keep-alive messages can also be specified. Furthermore, this interval can be signaling-specific. That is, the interval can be applicable to Session Management (SM) signaling or QoS reconfiguration PC5 signaling, or both.

[0102] In the third example technique for notifying congestion levels, the initiating WTRU can send a privacy-preserving message with a congestion level indication of the WTRU initiation. This technique is similar to the keep-alive message technique in the second example technique above. Therefore, the privacy-preserving message can contain a congestion level indication for evaluation by peer WTRUs.

[0103] In the fourth example technique for notifying congestion levels, the initiating WTRU can send a Direct Key Update Request message with the congestion level of the initiating WTRU. Here, this technique is similar to the keep-alive message technique in the second example technique above. Therefore, the Direct Key Update Request message can contain a congestion level indication for evaluation by the peer WTRU.

[0104] Other PC5 signaling messages (not described in this document) can also be used to notify congestion levels. The V2X layer or upper layers may also pass the congestion level to the RRC layer. In this case, the RRC layer can notify the congestion level via RRC signaling.

[0105] Congestion control procedures can be used when congestion is detected. Different congestion control procedures can be applied depending on the situation. Incoming communication establishment requests may be rejected. Existing communication can be reconfigured, for example, by changing the intervals of keep-alive, privacy, or key update procedures. The QoS applied to communication can also be reconfigured. If congestion is too high on a particular RAT, communication may be released or offloaded to another RAT. These different methods are detailed below.

[0106] In cases of excessive congestion, unicast link release can be performed. In this scenario, a link has already been established between two peer WTRUs. When congestion is detected at the WTRU, the release of existing communication may be triggered. Determining which communication to release can be based on various criteria or combinations thereof. Examples include the last established communication (such as the most recently established communication), or activities that can be monitored on the communication (such as sending / receiving traffic), or the selection or release of inactive or least active communication upon detection of congestion. Other examples of criteria include determination based on the number of flows (e.g., communication with the minimum number of flows is released), and determination based on application (ITS-AID / PSID) priority (e.g., communication associated with the application with the lowest priority is released). Here, priority can be assigned to each application at the WTRU. Another example of a criterion could be based on the PQI (PC5 QoS Indicator) and / or other QoS parameters for different flows.

[0107] The congestion control explained below uses a V2X service-oriented approach and the release of the last established communication as an example. However, unicast link release applies to any link establishment process discussed herein and any criteria for communication selection used for release as described herein.

[0108] like Figure 6 As shown, congestion control can be added to a V2X service-oriented approach using a direct communication release message with a backoff timer. The initiating WTRU (WTRU 601) monitors its congestion 606 and initiates communication specifying its congestion level 608. WTRU 601 notifies WTRUs 602, 603, and 604 of its congestion level using a broadcast DCR message 610. The peer WTRU 602, interested in the V2X service, accepts the current congestion level and accepts communication via a DCA message 614, which includes WTRU 602's congestion level. Communication between WTRU 601 and WTRU 602 occurs at 616. WTRU 601 verifies the current congestion level, determines there is no congestion, and communication is established 618.

[0109] At 620, the peer WTRU (WTRU 604) is interested in the V2X service from WTRU 601 and verifies that the congestion level is acceptable. WTRU 604 establishes a link to WTRU 601 by sending a DCA message 622 including WTRU 604's congestion level. Communication between WTRU 601 and WTRU 604 occurs at 624. At some later time, WTRU 601 may determine at 626 that its congestion level is too high. This can be determined in several ways, including by the congestion level exceeding a threshold or by an indication. When it receives the DCA message or at some later time, WTRU 601 terminates the link with WTRU 604 by sending a Direct Communication Release message 628. A backoff interval can also be specified on this message. Sending the backoff interval indicates to the peer WTRU (WTRU 604) the waiting time before attempting to re-establish the link. WTRU 604 responds by sending a direct communication release accept message 630, and communication 632 between WTRU 601 and WTRU 604 terminates.

[0110] When a direct communication release with a specified backoff interval is received, at 634, the peer WTRU (WTRU 604) starts a backoff timer using the value specified on the release message 628. This backoff timer and associated interval value are per L2 ID, i.e., per unicast communication. It could also be per L2 ID and V2X service. WTRU 604 tracks the association between L2 IDs and backoff intervals, and possibly the associated V2X services, at 634. When the backoff timer expires, WTRU 604 can attempt to re-establish communication with WTRU 601 by sending a DCR message using the L2 ID associated with the backoff timer. WTRU 604 can verify that the congestion level on its side is acceptable before attempting to re-establish communication. If it is still determined that the congestion level is too high, the backoff timer is restarted and no attempt is made to re-establish communication. Although this backoff timer runs at WTRU 604, WTRU 604 can still attempt to establish PC5 direct communication with a different WTRU that is notifying of the same service and has a lower congestion level. If the WTRU 604 can successfully establish a PC5 unicast connection with a different WTRU providing the same service, the WTRU 604 can stop the backoff timer.

[0111] The peer WTRU (WTRU 604) can also assess the congestion level of WTRU 601 by tracking the most recent congestion level notifications received from WTRU 601. For example, the initiating WTRU 601 can periodically generate broadcast messages such as DCRs (Distributed Congestion Level Responses) to notify supported V2X services of their current congestion level. WTRU 601 can also use a WTRU-oriented approach to broadcast DCRs including its congestion level. Even if the message is not intended for WTRU 604, or if WTRU 604 is not interested in the broadcast V2X service, WTRU 604 can still track the congestion level of WTRU 601 included in the broadcast message. Figure 6 (Not shown in the image).

[0112] If the backoff timer is running on this specific WTRU (i.e., WTRU-601) and optionally on this specific V2X service, then WTRU 604 can track the congestion level of WTRU-601. When the backoff timer expires, WTRU 604 can consider the saved congestion level of WTRU-601 and decide whether to send another DCR, depending on whether congestion still exists. If it is decided not to send a DCR, the backoff timer is restarted. The saved congestion level can be saved along with a timestamp (from the broadcast message) to ensure it remains accurate. This is done if the broadcast interval on WTRU-601 is long enough to clear congestion.

[0113] Another congestion control process is unicast link establishment rejection. In this process, link establishment exists and may occur between two peer WTRUs. The link establishment method used can be any of the techniques previously described for link establishment. The initiating WTRU broadcasts a DCR message specifying the V2X service. Interested peer WTRUs respond by initiating an establishment process, such as sending a DCR message to the initiating WTRU.

[0114] Figure 7 This is an example of a direct communication rejection message with a backoff timer. WTRU 701 performs congestion monitoring at 706 and initiates a communication establishment message at 708, also specifying the congestion level. Figure 7During the unicast link establishment rejection process, the initiating WTRU (WTRU 701) includes a congestion level in the DCR message 710 broadcast to its peers WTRU 702, WTRU 703, and WTRU 704. At points 712 and 722, the peer WTRUs (WTRU 702 and WTRU 704) are interested in the V2X service and consider whether the congestion level is acceptable. That is, if the peer WTRUs are monitoring their own congestion, they can assess the congestion level received from WTRU 702 on the broadcast message and the congestion level on the peer WTRUs 702 and 704. If no adverse congestion is determined, WTRU 702 and WTRU 704 send a DCR message back to WTRU 701, specifying their congestion levels.

[0115] WTRU 701 receives a DCR message 714 from, for example, WTRU 702, assesses the congestion level experienced by WTRU 701 at this time, and at 716, may consider the congestion level specified on the DCR message received from the peer WTRU, and if the congestion level is determined to be acceptable, WTRU 701 accepts communication by sending a DCA message 718 to WTRU 702. At 720, communication is established between WTRU 701 and WTRU 702.

[0116] On the other hand, at 726, when the DCR is received from WTRU 704, the congestion situation has worsened and WTRU 701 determines that the congestion level at WTRU 701 is unacceptable. Therefore, it rejects the link establishment request by sending a Direct Communication Rejection Message 728 to WTRU 704. A backoff interval is specified on the rejection message. Therefore, no communication is established between WTRU 701 and WTRU 704.

[0117] Upon receiving a Direct Communication Rejection Message 728 including a backoff interval, at 730, WTRU 704 starts a backoff timer using the interval specified in the release message. This backoff timer is associated with the interval value and L2 ID of WTRU 701. That is, at 732, WTRU 704 tracks the association between the L2 ID and the backoff interval. When the backoff timer expires, WTRU 704 can attempt to re-establish communication with WTRU 701 by sending a DCR message again using the L2 ID associated with the backoff timer. WTRU 704 can verify that the congestion level on its side is acceptable before attempting to establish communication. If it determines that the congestion level is too high (i.e., unacceptable), it restarts the backoff timer and does not attempt to establish communication.

[0118] As described in the unicast link release procedure, the peer WTRU (such as WTRU704) can also assess the congestion level of WTRU 701 by tracking the most recent congestion notification received from WTRU701. WTRU 704 can track this congestion level if a backoff timer is running on this particular WTRU (i.e., WTRU701) and optionally on this particular V2X service. When the backoff timer expires, WTRU 704 can consider the saved congestion level of WTRU 701 and decide whether to send another DCR, depending on whether congestion still exists. If it is decided not to send a DCR, the backoff timer is restarted. The congestion level saved by WTRU 701 can be saved along with a timestamp (from the broadcast message) to ensure it remains accurate. This is done if the broadcast interval on WTRU701 is long enough to clear congestion.

[0119] Another aspect of congestion control is unicast link reconfiguration. In some cases, congestion can be detected, and the WTRU can decide to reconfigure existing communications to limit the amount of signaling traffic sent until the congestion clears. Similarly, requested QoS can be modified to attempt to adapt to existing conditions. These reconfigurations are described in more detail below.

[0120] One possible reconfiguration due to congestion is QoS. QoS profiles associated with V2X applications can be provisioned on the WTRU, as described later in this document. Depending on the congestion level, new QoS profiles describing priorities, delays, etc., and ranges (the minimum distance that QoS parameters must satisfy) can be applied to adapt to the situation. When congestion is detected, V2X peers can agree on the QoS profiles and ranges to be applied. Signaling messages (such as keep-alive procedures or different PC5 signaling procedures) can trigger the application of new QoS profiles and ranges, along with the current congestion level.

[0121] Another possibility is to notify each congestion level of its QoS profile and range during communication establishment, i.e., when sending a direct communication request message. Whenever a new congestion level with a corresponding QoS profile is notified, the new QoS profile and range can then be applied.

[0122] The V2X layer can configure the AS layer based on QoS profiles and range information exchanged between peer WTRUs. QoS parameters are typically exchanged during link establishment. The negotiated QoS can then be applied to the PC5 unicast link. WTRUs can exchange / negotiate possible QoS levels during PC5 link establishment. Once agreed upon, in the event of congestion, WTRUs can implicitly reduce the QoS of the PC5 link by changing the link's QoS parameters (such as QFI, 5QI, PC5 QoS Indicator (PQI)) to a lower agreed value. Changes to lower QoS values ​​can be based on the congestion levels experienced and / or notified on the link. For example, WTRUs (the initiating WTRU and the peer WTRU) can negotiate three different PQIs during PC5 link establishment. An example could be PQIs a, b, and c, where "a" might be the highest and "c" might be the lowest. Traffic on this PC5 link could be sent with PQI a when there is no congestion, with PQI b at low to medium congestion levels, and with PQI c at high congestion levels. WTRU implicitly changes PQI based on the notified / observed congestion level.

[0123] It is also possible that when using one of the previously described methods to notify of congestion levels, the WTRU may include an indication that QoS signaling and / or SM signaling is not allowed. Therefore, when a congested WTRU sends such an indication, the WTRU can avoid sending any PC5 signaling to reconfigure the QoS of the PC5 link. The WTRU may also implicitly take such action based on the observed / notified congestion level. Furthermore, when the WTRU receives a backoff interval during congestion (e.g., on a keep-alive message), the associated timer can be specific to SM signaling and / or QoS reconfiguration PC5 signaling. If specific to QoS signaling, QoS signaling traffic may not be sent during the specified interval.

[0124] A potential second reconfiguration due to congestion could be setting intervals for periodic messages such as keep-alive, privacy protection, or key updates. The basic processes for keep-alive, privacy protection, and key updates already exist. These processes repeat periodically. That is, signaling messages are exchanged between two peers at specific intervals. To limit congestion at the initiating WTRU or peer WTRU, it may be necessary to reduce the number of signaling messages sent for each existing communication. This can be done by increasing the intervals based on observed congestion. As a novel feature, a congestion level is added to the messages described above. Additionally, a new congestion indicator is added, and the interval values ​​are reconfigured as needed.

[0125] Figure 8This is an example method for reconfiguration based on congestion levels received from peer WTRUs. This example includes link spacing reconfiguration. Congestion monitoring can be performed at WTRU 801 at 804 and at WTRU 802 at 806. Communication between the two WTRUs is underway at 808. At 810, WTRU 802 detects the congestion level. Figure 8 As shown, WTRU 801 receives a keep-alive message 812 from WTRU 802. Upon receiving such a message, in addition to the usual WTRU behavior, at 814, WTRU 801 checks the congestion level of the received WTRU 802 and whether congestion control is needed (e.g., based on a supplied QoS threshold). WTRU 801 can reconfigure a periodic timer to a larger value. The congestion level can indicate whether congestion control is needed or no longer needed. A congestion indication can be specified, indicating which function should apply congestion control, such as specific SM signaling or QoS reconfiguration for PC5. Figure 8 The triggering mechanism for sending a direct keep-alive message acknowledgment from WTRU 801 is that WTRU 801 has assessed the congestion level of WTRU 802 in the direct communication keep-alive message 812 from WTRU 802. The assessment at 814 indicates that, based on the congestion level of either WTRU 801 or WTRU 802, a backoff interval in the keep-alive acknowledgment message 816 sent by WTRU 801 to WTRU 802 may be appropriate. This backoff interval has the effect of exchanging fewer periodic keep-alive messages between WTRU 801 and WTRU 802, thus reducing congestion.

[0126] The WTRU 801 can also trigger congestion control and link reconfiguration based on its own congestion detection (i.e., without receiving any indication of congestion experienced by the peer WTRU). This is in Figure 9The diagram illustrates a reconfiguration of unicast link intervals based on the detected congestion level. At 904, WTRU 901 monitors for congestion. This congestion monitoring is observed by WTRU 901 and monitored locally within WTRU 901. Therefore, the congestion monitored at 904 is the congestion experienced by WTRU 901 due to resource usage (i.e., congestion observed and experienced by WTRU). Normal communication occurs between WTRU 901 and WTRU 902 at 906. At 908, WTRU 901 detects the need for congestion control (e.g., based on a provisioned QoS threshold). WTRU 901 triggers a keep-alive process via a direct communication keep-alive message 910 and reconfigures the periodic keep-alive message timer to a larger value by including a congestion indication, its own congestion level, and a backoff timer value. The congestion indication indicates the need for congestion control (e.g., via the use of a keep-alive process). At 912, a direct communication keep-alive acknowledgment message, including the congestion level of WTRU 902, is sent from WTRU 902 to WTRU 901. At 914, a keep-alive periodic timer is started or restarted in WTRU 902 based on the backoff interval value received from WTRU 901.

[0127] Figure 9 The diagram illustrates a reconfiguration using a keep-alive procedure. However, the same mechanism (i.e., adding congestion levels and adapting periodic intervals) can be applied to other periodic procedures, such as privacy-preserving messages and key update messages. A WTRU can trigger keep-alive / privacy-preserving / key update procedures (in addition to existing triggers). One possible trigger is when congestion is detected and signaling traffic should be reduced (e.g., increasing the interval) to alleviate congestion. Another possible trigger is when congestion is no longer detected and a reduction in the interval can be indicated.

[0128] When the process needs to run, the WTRU can reconfigure the periodic interval. For example, the periodic interval can be reconfigured because a periodic timer has expired or due to other triggers. In this case, if congestion is detected, the WTRU tracks the ongoing congestion level and the new interval configuration to be applied. The new interval may be used to execute the process when the running timer expires or due to other triggers. The WTRU then adds the previously saved congestion level indication and the new interval to a message and sends the message to the peer WTRU to delay the next execution of the process.

[0129] Alternatively, when congestion is observed or notified, WTRUs may implicitly increment their keep-alive timer values. If no keep-alive message is received when the keep-alive timer expires, the WTRU currently implicitly assumes the PC5 link is unavailable. It is recommended that during congestion, WTRUs could increment (e.g., double) the keep-alive value and then expect a keep-alive message only after the incremented keep-alive timer has expired. The timer value can be implicitly incremented by the WTRU based on the congestion level.

[0130] Another congestion control technique is called RAT offloading. RAT offloading can be used to reduce congestion on a RAT. To support this feature, WTRUs may first need to exchange their capabilities during the communication establishment process. For example, if congestion is detected on the initiating WTRU, that WTRU can recommend that its peer WTRU establish a link on another RAT. Example alternative RATs are LTE-PC5 or 5G-PC5, either of which can be expected to have less or no congestion. The initiating WTRU can recommend a list of RATs specific to V2X services or V2X applications in a preferred order. To establish communication on another RAT, the peer WTRU selects a RAT from the list provided by the initiating WTRU and based on the preferred order from the initiating WTRU.

[0131] RAT uninstallation can be done in different ways. This article discusses three alternatives:

[0132] A. Once communication has been established, use direct communication to release messages;

[0133] B. During communication establishment, use a direct communication rejection message; and

[0134] C. Use periodic messages, such as keep-alive, privacy protection, or key update procedures, while communication is still in progress.

[0135] If a direct communication release or direct communication rejection message is used, the peer WTRU can decide whether to wait or immediately try the suggested RAT before attempting to re-establish communication on the same RAT (using a backoff timer). This decision can be based on a policy configured on the WTRU. Such a policy can depend on the V2X service, the urgency of sending data, etc. The RAT offloaded using the direct communication release message (Alternative A) Figure 10 In China, and in the use of direct communication rejection messages (Alternative B) Figure 11 As shown in the image. Figure 10 and Figure 11 As shown, the first WTRU and the second WTRU exchange their capabilities during communication establishment.

[0136] consider Figure 10Alternative A (i.e., the direct communication release message method for RAT offloading) uses DCR message 1004 and DCA message 1006 to exchange capabilities between WRTU 1001 and WTRU 1002. Communication is established on 5G-PC5. WTRU 1001 detects congestion at 1008 and decides to release communication using direct communication release message 1010. This is followed by... Figure 10 Direct communication releases received message 1012. Consider... Figure 11 Alternative scheme B (i.e., the direct communication rejection message method for RAT offloading) uses DCR messages 1104 and 1106 to exchange capabilities. The communication request is rejected due to congestion at 1108.

[0137] The backoff timer is provided in Figure 10 Direct communication release message 1010 and Figure 11 On the direct communication rejection message 1110, as described above and as follows Figure 10 and Figure 11 As shown in the diagram. Furthermore, the first WTRU is... Figure 10 Direct communication release message 1010 and Figure 11 The direct communication rejection message 1110 suggests that the second WTRU offload communication to another RAT (such as LTE-PC5).

[0138] Upon receiving a release or rejection message with an offloaded RAT and a backoff timer, the second WTRU decides what it should do. The second WTRU can either immediately establish communication with the first WTRU on the proposed offloaded RAT or start a backoff timer and retry establishing communication on the current RAT, which may no longer be congested, when the timer expires. (See Figure 10 and...) Figure 11 In the example, WTRU 1002 and WTRU 1102 decide to offload communication to the recommended RAT, i.e. Figure 10 Activity box 1004 and Figure 11 LTE-PC5 in activity box 1112.

[0139] exist Figure 10 Once the decision to offload to the LTE-PC5 link is made, WTRU 1002 sends a DCR message 1016 to WTRU 1001 on the LTE-PC5 communication link. The DCR message 1016 includes the congestion level of WTRU 1002. WTRU 1001 can then send a DCA message 1018 to WTRU 1002 on the LTE-PC5 communication link. The DCA message 1018 includes the congestion level of WTRU 1001.

[0140] exist Figure 11Once the decision to offload to the LTE-PC5 link is made, WTRU 1102 sends a DCR message 1114 to WTRU 1101 on the LTE-PC5 communication link. The DCR message 1114 includes the congestion level of WTRU 1102. WTRU 1101 can then send a DCA message 1116 to WTRU 1102 on the LTE-PC5 communication link. The DCA message 1116 includes the congestion level of WTRU 1101.

[0141] If periodic messages are used to instruct offloading to another RAT, communication between WTRUs may still be in progress. Periodic messages can be used to trigger RAT offloading. This use of periodic messages can signal to peer WTRUs that congestion has been detected and suggest offloading. A list of potential RATs in preferred order can be provided. For example, such a list can be provided by triggering a keep-alive procedure. In this case, the peer WTRU can decide to establish another communication on the suggested RAT, and if successful, offload all traffic to this new communication path. Communication currently in progress on the congested RAT can then be released. This is in... Figure 12 As shown in the image.

[0142] In Figure 12, the first WTRU 1201 has an ongoing direct communication link 1204 with the second WTRU 1202. At 1206, WTRU 1201 detects congestion and makes a decision to recommend offloading to another RAT. A direct communication keep-alive message 1208 is sent to WTRU 1202, which includes the congestion level of WTRU 1201 and an offloading indication to the new RAT: LTE-PC5. WTRU 1202 sends a direct keep-alive confirmation message 1210. At 1212, WTRU 1202 makes a decision to offload to another RAT based on the information received in message 1208. WTRU 1202 sends a DCR to WTRU 1202 on the LTE-PC5 RAT, which indicates the congestion level of WTRU 1202. WTRU 1201 accepts DCR by sending DCA 1216, indicating the congestion level of WTRU 1201. At 1218, the two WTRUs communicate on the LTE-PC5 communication link. After successful communication on the LTE-PC5 RAT, WTRU 1202 can initiate offloading of the communication established on the initially used 5G-PC5 RAT at step 1220. WTRU 1202 sends a Direct Communication Release Message 1222 to WTRU 1201 to release the 5G-PC5 RAT link. WTRU 1201 responds to the release request with a Direct Communication Release Accept at 1224. As a result, the offloading of the 5G-PC5 link is completed.

[0143] Alternatively, before attempting to establish communication on another RAT, the peer WTRU can decide to immediately release ongoing congested communication. This decision can be based on a policy configured on the WTRU, taking into account factors such as V2X service and the urgency of sending data.

[0144] As mentioned earlier, ongoing communication may become congested; that is, the RAT in use may become congested. The WTRU may decide to offload the communication to another RAT. The decision (as in the examples discussed above regarding release and rejection) may be based on various factors, such as the strategy of the V2X application using this communication, the capabilities of the peer WTRU (such as access to other RATs), and the congestion of available alternative RATs.

[0145] When congestion is no longer observed, the WTRU that decided to apply congestion control measures can reverse these measures. Congestion can be alleviated on the WTRU itself or its peer. In this case, existing communication may be reconfigured to a periodic interval value. Communication can also be offloaded back to the preferred PC5 RAT.

[0146] The WTRU can be supplied to enable / disable congestion control features. If congestion control is enabled, relevant parameters can be supplied. For example, congestion control can be enabled or disabled. Before declaring a congestion-on indication, the number of communications between two peers can be set to a certain allowed limit. An example limit for a congestion-on decision could be 10 communications between peers. The number of communications allowed before declaring a congestion-off condition / state can be set to indicate when a congestion condition / state can be closed. An example limit for a congestion-off condition / state from a congestion-on condition / state could be reduced to 7 communications between peers. The WTRU can supply a table indicating the congestion level for each V2X application ID (e.g., PSID or ITS-AID), where the QoS profile is configured for each QoS level and range. Furthermore, this table can be a list of supported RATs for offloading in a preferred order.

[0147] In an additional method of transferring congestion levels from the initiating WTRU to the peer WTRU, the initiating WTRU can restrict its response to proposals to establish communication with the peer WTRU. Here, the initiating WTRU can send a set of requirements that the peer WTRU must meet before accepting a link establishment offered by the initiating WTRU. The initiating WTRU may include such a list of requirements, a link establishment request sent to one or more peer WTRUs, and the congestion level of the initiating WTRU.

[0148] While features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature and component can be used alone or in any combination with other features and components. This disclosure is not intended to limit the scope to the specific embodiments described herein, which are intended as illustrative of different aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of this disclosure. Elements, actions, or instructions used in the description of this application should not be construed as essential or indispensable to the invention unless expressly provided in this manner. In addition to the methods and apparatuses enumerated herein, those skilled in the art will clearly understand from the foregoing description functionally equivalent methods and apparatuses within the scope of this disclosure. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the full scope of the appended claims and their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

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

[0150] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. The term "video" or "image" as used herein can mean any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, the term "user equipment" and its abbreviation "UE," and the term "remote," as used herein, can mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device with wireless and / or wired capabilities (e.g., connectable), particularly configured with some or all of the structure and functions of a WTRU; (iv) a device with wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU; or (iv) a similar device. Figures 1A to 1D Details of an example WTRU that can represent any of the WTRUs discussed in this article are provided.

[0151] Furthermore, the methods provided herein can be implemented as 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 via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multipurpose discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0152] Various modifications to the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) providing any appropriate voltage.

[0153] Furthermore, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, the behavior or symbolic representation of an operation or instruction can be performed by various CPUs and memories. Such behavior and operations or instructions may be referred to as “execution,” “computer execution,” or “CPU execution.”

[0154] Those skilled in the art will understand that actions, and operations or instructions represented by symbols, include the manipulation of electronic signals by the CPU. An electronic system represents data bits that may cause the electronic signals to be transformed or reduced, and memory locations in a memory system that hold the data bits, thereby reconfiguring or otherwise altering CPU operations and other signal processing. A memory location that holds the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments described herein are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

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

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

[0157] There is little difference between the hardware and software implementations of the various aspects of the system. The choice between hardware and software is typically (but not always; in some environments, the choice between hardware and software may be important) a design choice representing a trade-off between cost and efficiency. The processing and / or system and / or other technologies described herein can be implemented by a variety of vehicles (e.g., hardware, software, and / or firmware), and the preferred vehicle can vary depending on the context in which the processing and / or system and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, then the implementer may choose a vehicle that primarily employs hardware and / or firmware. If flexibility is paramount, then the implementer may choose a implementation that primarily employs software. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0158] The detailed description above has illustrated various embodiments of the device and / or processing using block diagrams, flowcharts, and / or examples. Just as such block diagrams, flowcharts, and / or examples encompass one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit as: one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that the circuit design and / or code writing of the software and / or firmware according to this disclosure will be entirely within the technical scope of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform such distribution. Examples of signal-bearing media include, but are not limited to, recordable media (such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc.) and transmission media (such as digital and / or analog communication media (e.g., optical fibers, waveguides, wired communication links, wireless communication links, etc.)).

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

[0160] The topics described herein sometimes show different components contained within or connected to other components. It should be understood that the architectures described thus are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to achieve the desired functionality. Therefore, any two components combined in this document to achieve a particular function can be considered “associated” with each other, thereby achieving the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of being operablely coupled include, but are not limited to, components that can be physically paired and / or physically interact and / or wirelessly interact and / or logically interact and / or are logically interactive.

[0161] As for any substantially plural and / or singular terms used herein, those skilled in the art may appropriately convert plural to singular and / or singular to plural depending on the context and / or application. For clarity, various singular / plural substitutions may be explicitly described herein.

[0162] Those skilled in the art will understand that, in general, the terms used herein, particularly in the appended claims (e.g., the body of the appended claims), should be treated as “open-ended” terms (for example, the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” and the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if the introduced claim statement refers to a specific quantity, then this intention should be explicitly stated in the claim, and without such a statement, such intention does not exist. For example, if the intention is for only one item, then the term “single” or similar language can be used. As an aid to understanding, subsequent appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the claim statement. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article "a" or "an" limits any particular claim containing such a claim statement to embodiments containing only one such statement, even when the same claim contains the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as "at least one" or "one or more"). The same applies to definite articles used to introduce claim statements. Furthermore, even when a specific number of introduced claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as referring to at least the number stated (e.g., an unmodified statement of "two statements" without other modifiers means at least two statements or two or more statements). Furthermore, in instances where a convention similar to "at least one of A, B, and C" is used, such a construction is typically made in the sense of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or systems having A, B, and C). In instances where a convention similar to "at least one of A, B, or C" is used, such a construction is typically made in the sense of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or systems having A, B, and C). A person skilled in the art will further understand that virtually any disjoint words and / or phrases proposing two or more alternatives, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, any, or both of these items.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, the term “any one” followed by a series of multiple items and / or multiple item categories, as used herein, is intended to include items alone or in combination with other items and / or other item categories, “any one”, “any combination”, “any multiple”, and / or “any combination of multiples”. Additionally, the term “group” as used herein is intended to include any number of items, including zero. Furthermore, the term “quantity” as used herein is intended to include any quantity, including zero.

[0163] Furthermore, if features or aspects of this disclosure are described in accordance with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any single member or subgroup of members within the Markush group.

[0164] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any scope listed can be readily considered to adequately describe and enable the same scope to be decomposed into at least two, three, four, five, ten, etc., equal parts. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will understand that all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the stated number and refers to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope will include each individual member. Thus, for example, a group with 1-3 cells means a group with 1, 2, or 3 cells. Similarly, a group with 1-5 cells means a group with 1, 2, 3, 4, or 5 cells, and so on.

[0165] Furthermore, the claims should not be construed as limited to the order or elements provided, unless such effect is stated. Additionally, the term “component for…” used in any claim is intended to invoke 35 U.S.SC §112, 6 or the means plus function claim format, and any claim without the term “component for…” is not intended to be so.

Claims

1. A method for communication between an initiating wireless transceiver unit (WTRU) and a peer WTRU, the method comprising: The initiating WTRU monitors the congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU; The initiating WTRU detects the congestion level and triggers congestion control; The initiating WTRU sends at least one message based on the congestion level to reconfigure ongoing communication between the initiating WTRU and the at least one peer WTRU. The process by which the initiating WTRU sends at least one message to reconfigure ongoing communication based on the congestion level includes sending periodic messages.

2. The method according to claim 1, wherein, The periodic message is one of the keep-alive message, privacy protection message, and key update message.

3. The method according to claim 1, wherein, Sending at least one reconfiguration message includes sending a message that changes the interval between periodic messages.

4. A method for communication between an initiating wireless transceiver unit (WTRU) and a peer WTRU, the method comprising: The initiating WTRU monitors the congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU; The initiating WTRU detects the congestion level and triggers congestion control; The initiating WTRU sends at least one message based on the congestion level to reconfigure ongoing communication between the initiating WTRU and the at least one peer WTRU. The initiating WTRU sending at least one message to reconfigure ongoing communication based on the congestion level includes sending a message indicating a change in Quality of Service (QoS).

5. The method according to claim 4, wherein, The QoS change includes changing the QoS parameter of the PC5 QoS indicator PQI to a lower value compared to the current value.

6. A method for initiating communication between a Wireless Transmitter / Receiver Unit (WTRU) and a peer WTRU, the method comprising: The initiating WTRU monitors the congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU; The initiating WTRU detects the congestion level and triggers congestion control; The initiating WTRU sends at least one message based on the congestion level to reconfigure ongoing communication between the initiating WTRU and the at least one peer WTRU, further comprising: the initiating WTRU sending an offload message based on the congestion level to redirect ongoing communication to another communication medium.

7. The method according to claim 6, wherein, The offloading message for relocating ongoing communication to another communication medium includes offloading the ongoing communication to another radio access technology (RAT), and wherein the initiating WTRU and the at least one peer WTRU exchange access capabilities.

8. The method according to claim 6, wherein, The unload message includes a vehicle-specific list of all V2X services or V2X applications in a preferred order.

9. A method for communication between an initiating wireless transceiver unit (WTRU) and a peer WTRU, the method comprising: The initiating WTRU monitors the congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU; The initiating WTRU detects the congestion level and triggers congestion control; The initiating WTRU sends at least one message based on the congestion level to reconfigure ongoing communication between the initiating WTRU and the at least one peer WTRU; as well as The initiating WTRU sends a release message for ongoing communication between itself and at least one peer WTRU based on the congestion level.

10. A wireless transceiver unit (WTRU), comprising: The processor is configured to generate the congestion level experienced by the WTRU; as well as A transceiver, controlled by the processor, for communicating with at least one peer WTRU; The processor detects the congestion level and triggers congestion control. The transceiver sends at least one message based on the congestion level to reconfigure ongoing communication between the WTRU and the at least one peer WTRU. The transceiver sends at least one periodic message based on the congestion level to reconfigure ongoing communication between the WTRU and the at least one peer WTRU.

11. The WTRU according to claim 10, wherein, The at least one periodic message is one of a keep-alive message, a privacy protection message, and a key update message.

12. The WTRU according to claim 10, wherein, At least one message that reconfigures ongoing communication includes: at least one periodic message that changes the interval of a periodic message.

13. A wireless transceiver unit (WTRU), comprising: The processor is configured to generate the congestion level experienced by the WTRU; as well as A transceiver, controlled by the processor, for communicating with the at least one peer WTRU; The processor detects the congestion level and triggers congestion control. The transceiver sends at least one message based on the congestion level to reconfigure ongoing communication between the WTRU and the at least one peer WTRU. The message that reconfigures the ongoing communication includes at least one message that changes the Quality of Service (QoS) between the WTRU and the at least one peer WTRU.

14. The WTRU according to claim 13, wherein, The QoS change includes changing the QoS parameter of the PC5 QoS indicator PQI to a lower value compared to the current value.

15. A wireless transceiver unit (WTRU), comprising: The processor is configured to generate the congestion level experienced by the WTRU; as well as A transceiver, controlled by the processor, for communicating with at least one peer WTRU; The processor detects the congestion level and triggers congestion control. The transceiver sends at least one message based on the congestion level to reconfigure ongoing communication between the WTRU and the at least one peer WTRU. The reconfiguration message is an offloading message that redirects ongoing communication to another communication medium.

16. The WTRU according to claim 15, wherein, An offloading message that redirects ongoing communication to another communication medium includes offloading ongoing communication to another radio access technology (RAT), wherein the WTRU and the at least one peer WTRU exchange access capabilities.

17. The WTRU of claim 16, wherein, The unload message includes a vehicle-specific list of all V2X services or V2X applications in a preferred order.

18. A wireless transceiver unit (WTRU), comprising: The processor is configured to generate the congestion level experienced by the WTRU; as well as A transceiver, controlled by the processor, for communicating with at least one peer WTRU; The processor detects the congestion level and triggers congestion control. The transceiver sends at least one message based on the congestion level to reconfigure ongoing communication between the WTRU and the at least one peer WTRU. The reconfiguration message is a release message for ongoing communication between the WTRU and the at least one peer WTRU.

19. A method for establishing a unicast communication link between a first WTRU and a second WTRU, comprising: The first WTRU sends a communication establishment request, including an indication from the first WTRU of its responsibility for congestion-based reconfiguration of the communication link; The first WTRU receives a communication establishment response from the second WTRU authorizing the request; as well as The first WTRU performs a reconfiguration of the communication link in response to congestion.

20. A method executed by a WTRU, comprising: Maintain ongoing communication with the peer WTRU on the first radio access technology (RAT); The WTRU detects that the congestion level at the WTRU exceeds a threshold; The WTRU sends a periodic signaling message, including an indication to offload the ongoing communication, to the second RAT; as well as The ongoing communication is established on the second RAT by the WTRU and the peer WTRU based on the periodic signaling messages.

Images