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 an ongoing communication to another communication medium. In one example, the offload message to relocate the ongoing communication to another communication medium can include offloading the ongoing communication to another radio access technology (RAT), where the initiating WTRU and the at least one peer WTRU exchange access capabilities. In a further feature, the offload message can include a list of radio access technologies (RATs) specific to vehicle-to-everything (V2X) services or V2X applications in a preferred order.

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

[0010] While various embodiments are described and / or claimed herein, it should be understood that any listed or individual elements of the embodiments can be combined with other elements or removed from the embodiments, and the application is intended to embrace modifications and permutations of these embodiments. It is intended to include also any additional items, features, functions, procedures, operations, steps, components, and / or functions specified within the description, claims, and / or drawings. Furthermore, a BRIEF DESCRIPTION OF DRAWINGS

[0011] A more detailed understanding can be had from the following detailed description, taken in conjunction with the accompanying drawings, wherein:

[0012] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0013] FIG. 1B is a system diagram illustrating an example WTRU that can be used within the communications system FIG. 1A illustrated in FIG. 1A;

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

[0015] FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that can be used within the communications system of FIG. 1A FIG. 1 is a system diagram illustrating the communications system that can be used within the communications system of

[0016] FIG. 2 A signal diagram of a Layer 2 link establishment procedure between peer WTRUs for V2X services is described;

[0017] FIG. 3 A signal diagram of a Layer 2 link establishment procedure for a WTRU is described;

[0018] FIG. 4 An example signal diagram showing a WTRU of interest initiating a link establishment procedure is described;

[0019] FIG. 5 A signal diagram showing a determination of which WTRU handles a communication link reconfiguration is described;

[0020] FIG. 6 A signal diagram showing a direct communication release message with a back-off timer is described;

[0021] FIG. 7 A signal diagram showing a direct communication reject message with a back-off timer is described;

[0022] FIG. 8 A signal diagram showing a unicast link interval reconfiguration based on a congestion level received from a peer WTRU is described;

[0023] FIG. 9 A signal diagram showing a unicast link interval reconfiguration based on a detected congestion level is described;

[0024] FIG. 10 A signal diagram showing a radio access technology offload due to congestion control using a release message is described;

[0025] FIG. 11 A signal diagram showing a radio access technology offload due to congestion control using a reject message is described; and

[0026] FIG. 12 A signal diagram showing a radio access technology offload due to congestion control using a keep-alive message is described. DETAILED DESCRIPTION

[0027] A detailed description will now be made regarding the detailed description of the illustrative embodiments with reference to the various drawings. While the present description provides detailed examples of possible implementations, it should be noted that these are meant to be exemplary in nature and are in no way limiting to the scope of the present application. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding. However, it should be understood that such embodiments and examples can be practiced without some or all of these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail since it would be

[0028] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

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

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

[0031] The base stations 114a can be part of the RAN 104 / 113, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies (which can be referred to as a cell (not shown)). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide wireless service to a particular geographic area that can be fixed or can change over time. A cell can be further divided into cell sectors. For example, a cell associated with a base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In an embodiment, the base station 114a can employ Multiple Input Multiple Output (MIMO) techniques and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0032] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0033] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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 an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro.

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

[0036] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB), using the same frequency (within a same frequency spectrum band) or different frequencies (within different frequency spectrum bands). Additionally or alternatively, the base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and / or the like.

[0037] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and / or the like.

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

[0039] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can be utilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. FIG. 1A

[0040] ​​CN 106 / 115 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use the Transmission Control Protocol / Internet Protocol (TCP / IP) suite of communications protocols to exchange

[0041] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Figure 1 A can be configured to communicate with the base station 114a, which can employ a cellular-based radio technology, and with the base station 114b, which can employ an IEEE 802 radio technology. FIG. 1A The WTRU 102c, as shown in Figure IB, can be configured to communicate as a cellular-based WTRU 102c with the base station 114a, and as an IEEE 802-based

[0042] FIG. 1B is a system diagram of an example WTRU 102. As shown in Figure 1 C, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment. FIG. 1B

[0043] ​The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While FIG. 1B The processor 118 and the transceiver 120 are depicted as separate components, it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0045] Although the transmit / receive element 122 is depicted in the WTRU 102 FIG. 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

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

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

[0049] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0050] The processor 118 can further be coupled to other peripherals 138 that can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands -free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or an augmented reality (VR / A R) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors, the sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0051] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit 139 to reduce and / or eliminate self-interference and / or cross- interference due to concurrent transmission and reception by the WTRU 102. In an embodiment, the WTRU 102 can include a half duplex radio, in which transmission and reception cannot be concurrent and / or simultaneous.

[0052] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

[0053] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

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

[0055] FIG. 1C The CN 106 shown in FIG. 10 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0059] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, or other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice, video, and data communication services to users. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 can include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include networks like or similar to the positioning network 100 described with reference to FIG. 1.

[0060] Although not shown in FIG. 1, a WTRU can be in communication with one or more positioning nodes, such as a location management function (LMF) or a secure user plane location (SUPL) location platform (SLP). The positioning nodes can be in communication with the core network 106 and / or the Internet 110. FIGS. 1A-1D Although WTRUs 102a, 102b, 102c are each described as a wireless terminal, in certain representative embodiments, it is contemplated that a terminal can be configured to use a wired communication interface in place of, or in addition to, a wireless communication interface.

[0061] In representative embodiments, the other networks 112 can be a WLAN.

[0062] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or other type of wired / wireless network that carries traffic in to and / or from the BSS. Traffic to STAs that originates from outside the BSS can arrive via the AP and can be delivered to the STAs by the AP. Traffic that originates from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations via the AP. Traffic between STAs within the BSS can be sent through the AP, for example, where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between (e.g., directly between) source and destination STAs using a direct link setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode can not have an AP, and / or all STAs within the IBSS can communicate directly with each other. The IBSS communication mode can sometimes be referred to herein as “ad-hoc” mode of communication.

[0063] When using an 802.11 ac infrastructure mode of operation or similar modes of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) with collision avoidance can be implemented, for example, in 802.11 systems. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected as busy and / or determined to be busy by a particular STA, the particular STA can backoff. Only one STA can transmit in the given BSS at any given time.

[0064] High Throughput (HT) STAs can use 40 MHz wide channels for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0066] 802.11af and 802.11ah support Sub 1 GHz operating modes. The channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter type control / machine type communication, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., support only) certain and / or limited bandwidths. MTC devices can include a battery with a battery life above 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.11η, 802.11ac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC type devices) that support (e.g., only support) 1 MHz mode, the primary channel can be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (supporting only 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the frequency band remains idle and can be available.

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

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

[0070] The RAN 113 can include gNBs 180a, 180b, 180c, although the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple downlink communications (e.g., communication streams or beams) to the WTRU 102a (not shown) over multiple component carriers. The WTRU 102a can simultaneously receive these multiple downlink communications (not shown) over the multiple component carriers. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0072] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of the gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal transmission and reception over unlicensed radio frequency spectrum. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / be connected with the gNBs 180a, 180b, 180c, while also communicating / being connected with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, the eNode-Bs 160a, 160b, 160c can function as a mobility anchor point for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for servicing the WTRUs 102a, 102b, 102c.

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

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

[0075] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting for network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing the WTRU 102a, 102b, 102c registration area, terminating a Non-Access Stratum (NAS) signaling, mobility management, and the like. The AMF 162 can provide access to a 5G core network for the WTRUs 102a, 102b, 102c, using a network slice to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, and / or the like. The AMF 162 can provide a control plane function for switching between the RAN 113 and other RANs (not illustrated) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0077] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0078] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0079] In view of FIGS. 1A-1D And FIGS. 1A-1D corresponding description, one or more or all of the functions described herein in relation to one or more of the following: WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or to emulate a network and / or WTRU functionality.

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

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

[0082] Examples provided herein do not limit the applicability of the present subject matter to other wireless technologies, e.g., using the same or different principles that can be applicable.

[0083] As explained herein, a wireless transmit receive unit (WTRU) can be an example of a user equipment (UE). Thus, the terms UE and WTRU can be used herein in the same scope. A layer 2 link establishment procedure for V2X services is shown in FIG. 2 FIG. 2 A direct communication request (DCR) message 206, 208, 210 can be transmitted by a WTRU 201 using a broadcast mechanism, i.e., to a broadcast address associated with an 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 to establish a layer 2 (L2) link, i.e., information about the advertised V2X service, can be included in the direct communication request message to allow other (peer) WTRUs to decide whether to respond to the request. All WTRUs interested in using the V2X service advertised by the direct communication request (DCR) message can respond to the request. For example, FIG. 2 WTRU 202 in FIG. 2 ​The WTRUs 204 in the group respond to the DCR broadcast message with DCA messages 214. This V2X service oriented link is in line with 3GPP TR 23.786 V1.1.0 (2019-01), Study on Architecture Enhancements for EPS and 5GS to support Advanced V2X Services (Release 16).

[0084] FIG. 3 A WTRU-oriented Layer 2 link establishment procedure is shown in FIG. 3. Direct communication request messages 306, 308, 310 can be sent by the WTRU 301 using a broadcast mechanism, i.e., to a broadcast address associated with the application, such as to WTRU 302, WTRU 303, WTRU 304. An upper layer identifier (e.g., upper layer ID) of the WTRU 302 is included in the direct communication request message to allow the WTRU 302 to decide whether to respond to the request. The WTRU 302 can send a direct communication accept (DCA) message 312 to respond to the DCR message 306.

[0085] An alternative link establishment procedure can be possible where each WTRU can be interested in the announced V2X service upon receiving the 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. This procedure is shown in FIG. 4. Here, the interested WTRU initiates the link establishment message. Although unicast communication is used as an example PC5 communication at steps 406, 408, 410, other types of PC5 communication can be employed between WTRUs as well. For example, if a broadcast discovery message is sent instead of a DCR message, the peer WTRU can learn the WTRU 401 L2 ID and establish a PC5 link, as shown at steps 412, 414. FIG. 4

[0086] The initiating WTRU (e.g., WTRU 401) can broadcast supported V2X services via a broadcast DCR message 406, 408, 410 over a PC5 radio access technology (RAT), such as a 5G PC5 reference point interface. Many WTRUs can be interested in such V2X services and can establish communication with the initiating WTRU. Also, many V2X services can be announced, so a WTRU can end up running multiple communications at the same time to maintain and generate and / or receive data. In addition to this, unicast communications can be established with specific WTRUs, increasing the number of established communications, usage of resources, etc. In one example, interested WTRU 2 sends a DCR message 412 to the initiating WTRU 401, which can then respond with a DCA message 414. ​

[0087] It can be appreciated that having many ongoing communications on a WTRU can lead to congestion conditions on the WTRU and / or the RAT. As a result, the peer WTRUs can experience lower quality communications. That is, certain V2X applications can not be able to meet quality of service (QoS) requirements. In severe cases, communications on the PC5 interface can even be lost. Furthermore, losing communications due to congestion conditions can cause the peer WTRUs to attempt to reestablish links, thereby creating even more congestion on the RAT and WTRUs. Finally, multiple WTRUs can reply and establish unicast links with the initiator WTRU. Congestion can occur due to too many unicast communications established on the initiating WTRU. Therefore, techniques are needed to address WTRU congestion.

[0088] It is noted that V2X is used in this disclosure as an example of communications. The procedures defined herein can be applicable to other types of communications, for example, communications with other electronic devices such as drones, trains, and maritime communications. A set of actions that a WTRU can take to address congestion problems are described herein. Any or all of the set of actions can be taken to address or otherwise reduce or isolate congestion. The WTRU can manage congestion by dynamically controlling its resource usage. Such dynamic control actions can include releasing existing communications or rejecting new communication requests. Other dynamic control operations can be adapting existing communications, such as reducing control plane traffic, changing the required QoS, or offloading communications to another RAT.

[0089] According to one novel feature, the initiating WTRU can inform its congestion level when initiating unicast link establishment or during ongoing PC5 unicast communications. The congestion level sent / informed to other WTRUs is the congestion level that the sending WTRU is experiencing or is known to the sending WTRU. This sending / informing of the congestion level by the sending WTRU enables interested peer or receiving WTRUs to decide based on the congestion information whether they should reply to the link establishment from the initiating WTRU or whether they should choose to ignore the link establishment request and wait for congestion to recover or reduce, or wait for the appearance of another less congested initiating WTRU that supports the same service.

[0090] Since the congestion level is always changing, it can be notified in a variety of ways or time or periodically. For example, at the initiation of unicast link establishment, during keep-alive, privacy protection, and key update procedures. Any periodic message sent by the WTRU is a candidate to include congestion level or status information. Due to congestion, the initiating WTRU can reject a communication establishment request from another WTRU, or it can release an ongoing unicast communication. In both cases, the backoff interval can be specified on the release and reject messages along with an appropriate cause code indicating that the rejection is due to congestion. Thus, the peer WTRU does not need to immediately retry (re)establish the communication. A backoff timer is used per peer Layer 2 identifier (L2 ID) on the peer WTRU. The backoff timer can also be per L2 ID and V2X application identifier (ITS-AID) provider service identifier (PSID), i.e., associated with the L2 ID of the initiating WTRU, and possibly associated with the V2X application.

[0091] When congestion is observed on the link, the initiating WTRU can reduce the amount of traffic exchanged on the signaling plane to limit the congestion. For example, the keep-alive interval can be increased for a period of time. The privacy protection interval and the key update interval can also be increased. In addition, the initiating WTRU can change the requested link QoS if congestion is observed (or if congestion is no longer observed). A new QoS value can be specified, for example, to increase the acceptable delay.

[0092] Another possibility when congestion is observed is to offload the communication to another RAT. Offloading effectively relocates the traffic from one communication medium / access to another communication medium / access. For example, the communication on the fifth generation / new radio PC5 (5G / NR PC5) can be offloaded to the 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 can also be true. That is, move the LTE PC5 to the 5G / NR PC5. To implement such offloading, the initiating WTRU and the peer WTRU can need to exchange their capabilities. In this case, only the unicast communication of two WTRUs that support LTE and 5G versions of PC5 can be offloaded.

[0093] A WTRU can be provisioned with QoS profiles mapped to congestion levels and congestion control functions enabled or disabled. In addition, congestion thresholds can be configured so that a 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 normal values, accepting new communication establishments again, etc. Although many of the procedures in this document are described from the perspective of interactions between WTRUs from the V2X / NAS / ProSe layer or upper layers, the same procedures can apply to RRC signaling exchanges between WTRUs.

[0094] According to novel features, congestion detection for WTRUs operating on PC5 RAT is based on link measurements. The Access Stratum (AS) layer handles link measurements and can be aware of link congestion. The AS layer can send an indication to the V2X layer to inform it of the congestion situation (on / off) on a particular RAT. A congestion level can also be specified by the AS layer. Another possibility includes the AS layer providing measurement information to the V2X layer, which itself determines whether a congestion situation is present. In any case, it is assumed that the V2X layer can be aware of the congestion situation.

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

[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, inform their congestion level, release existing communications, and / or reject new communication requests. However, one WTRU can be selected to handle reconfiguration of existing communications.

[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 the responsibility assignment. Alternatively, the responding WTRU can request responsibility. The responding WTRU can be the WTRU that makes the final decision or the responding WTRU can be pre-determined to have and maintain the responsibility for reconfiguration. A WTRU can have the responsibility to reconfigure a particular communication, while for another communication, the peer WTRU has this responsibility.

[0098] FIG. 5Examples are illustrated of how a WTRU can determine which is responsible for handling communication reconfiguration. These examples are based on the three methods of unicast link establishment described previously. In FIG. 5 In the specific example shown in FIG. 5, WTRU 501 requests responsibility for handling communication reconfiguration by using DCR message 506. WTRU 502 accepts via DCA message 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 reconfiguration responsibility using DCA message 514. WTRU 503 can then initiate establishment of a communication with WTRU 501 via DCR message 516 and request handling of the reconfiguration. A third communication can be established between WTRU 503 and WTRU 501 via DCA message 518. WTRU 502 then initiates establishment of a communication with WTRU 503 via DCR message 520 and requests handling of the reconfiguration for that communication. A fourth communication can be established between WTRU 502 and WTRU 503 via DCA message 522. It is noted that WTRU 502 has 2 communications (one with WTRU 501 and one with WTRU 503) and can be handling the reconfiguration for only the communication with WTRU 503 (communication #4). WTRU 501 handles the reconfiguration for the other communication (communication #1). Alternatively, the WTRU that informs of the congestion level can always be implicitly responsible for the reconfiguration of the PC5 unicast link.

[0099] A WTRU can be configured to monitor congestion and such a WTRU can inform other WTRUs of its congestion level in different ways, as described below. The congestion level can be informed as, for example, none, low, medium, high. The congestion level can be informed as a numeric information element (IE) in a PC5 message, for example, a congestion level IE representing congestion from an integer 0 to 10, where 0 represents no congestion and 10 represents a very high congestion level.

[0100] In a first example technique of notifying congestion level, an initiating WTRU can send a DCR with an indication of the congestion level of the initiating WTRU. Here, no link is established when the DCR is sent. The peer WTRUs receive the DCR message and if any of the peer WTRUs are interested in the V2X service, the peer WTRUs evaluate 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 not due to the high congestion level which is expected to provide a poor quality of communication and does 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 communication establishment decision based on the congestion level are shown above in FIG. 6 and FIG. 7 .

[0101] In a second example technique of notifying congestion level, an initiating WTRU can send a keep-alive message with an indication of the congestion level of the initiating WTRU. Here, a link has already been established between the 2 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 back-off interval for periodic keep-alive messages can also be specified. Further, the interval can be signaling specific. That is, the interval can apply to session management (SM) signaling or QoS reconfiguration PC5 signaling or both.

[0102] In a third example technique of notifying congestion level, an initiating WTRU can send a privacy protection message with an indication of the congestion level of the initiating WTRU. Here, the technique is similar to that of the keep-alive message in the second example technique above. Thus, the privacy protection message can contain the congestion level indication for the peer WTRU to evaluate.

[0103] In a fourth example technique of notifying congestion level, an initiating WTRU can send a direct key update request message with the congestion level of the initiating WTRU. Here, the technique is similar to that of the keep-alive message in the second example technique above. Thus, the direct key update request message can contain the congestion level indication for the peer WTRU to evaluate.

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

[0105] Congestion control procedures can be used when congestion is detected. Depending on the situation, different congestion control procedures can be applied. Incoming communication establishment requests can be rejected. Existing communications can be reconfigured, for example by changing the interval of keep-alive, privacy or key update procedures. QoS applied to the communications can also be reconfigured. In case of too high congestion on a specific RAT, the communications can be released or offloaded to another RAT. These different approaches are detailed below.

[0106] In case of too high congestion, unicast link release can be performed. In this case, a link has already been established between 2 peer WTRUs. When congestion is detected at a WTRU, the release of an ongoing communication can be triggered. How to determine which communication to release can be based on various criteria or combination of criteria. Examples include the last established communication (such as the most recently established communication), or the activity that can be monitored on the communication (such as the traffic sent / received), or the least active or inactive communication can be selected or released at the time of congestion detection. Other criteria examples include determination based on the number of flows (e.g. like the communication with the least number of flows is released), determination based on the application (ITS-AID / PSID) priority (e.g. the communication associated with the application with the lowest priority is released). Here, a priority can be provided on the WTRU for each application. Another criteria example can be based on the PQI (PC5 QoS Indicator) and / or other QoS parameters of the different flows.

[0107] The congestion control explained below takes the example of V2X service oriented approach and the last established communication being released. However, unicast link release applies to any link establishment procedure discussed herein and any criteria for communication selection for release as described herein.

[0108] As FIG. 6 Congestion control can be added to the V2X service oriented approach using a direct communication release message with a back-off timer as shown in FIG. 6. The initiating WTRU (WTRU 601) monitors its congestion 606 and initiates a communication specifying its congestion level 608. The WTRU 601 informs the WTRUs 602, 603 and 604 of its congestion level using a broadcast DCR message 610. The peer WTRU 602 is interested in the V2X service and accepts the current congestion level and accepts the communication via a DCA message 614 including the WTRU 602 congestion level. The communication between WTRU 601 and WTRU 602 occurs at 616. The WTRU 601 verifies the current congestion level, determines that there is no congestion and the communication establishment is completed 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 and including the congestion level of WTRU 604. The communication between WTRU 601 and WTRU 604 occurs at 624. At some later time, WTRU 601 can determine that its congestion level is too high at 626. This can be determined in a number of ways, including the congestion level exceeding a threshold or 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. The backoff interval is sent to indicate to the peer WTRU (WTRU 604) a wait time before attempting to reestablish the link. WTRU 604 responds by sending a direct communication release accept message 630 and the communication 632 between WTRU 601 and WTRU 604 is terminated.

[0110] When receiving a direct communication release specifying a backoff interval, at 634, the peer WTRU (WTRU 604) uses the value specified on the release message 628 to start a backoff timer. This backoff timer and associated interval value is per L2 ID, i.e. per unicast communication. It can also be per L2 ID and V2X service. WTRU 604 tracks at 634 the L2 ID and backoff interval association, and possibly the associated V2X service. At the expiration of the backoff timer, WTRU 604 can attempt to reestablish 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 reestablish communication. If it still determines that the congestion level is too high, the backoff timer is restarted and no attempt is made to reestablish communication. While this backoff timer is running at WTRU 604, WTRU 604 can still attempt to establish a PC5 direct communication with a different WTRU that is advertising the same service and has a lower congestion level. If WTRU 604 is able to successfully establish a PC5 unicast connection with a different WTRU providing the same service, WTRU 604 can stop the backoff timer.

[0111] Peer WTRUs (WTRU 604) can also evaluate the congestion level of WTRU 601 by tracking the most recent congestion level notification received from WTRU 601. For example, the initiating WTRU 601 can inform the supported V2X services by periodically generating a broadcast message such as a DCR that includes its current congestion level. WTRU 601 can also use a WTRU-oriented approach to broadcast a DCR that includes its congestion level. Even if the message is not intended for WTRU 604, or if WTRU 604 is not interested in the broadcasted V2X service, WTRU 604 can still track the congestion level of WTRU 601 included in the broadcast message (not shown in the middle). FIG. 6

[0112] If the back-off timer is running on this particular WTRU (i.e. WTRU-601) and optionally on this particular V2X service, WTRU 604 can track the congestion level of WTRU-601. At the expiration of the back-off timer, WTRU 604 can take into account the saved congestion level of WTRU-601 and decide whether to send another DCR or not, depending on whether the congestion still exists. If it is decided not to send a DCR, the back-off timer is restarted. The saved congestion level can be saved together with a timestamp (from the broadcast message) to make sure it is still accurate. This is done in case the broadcast interval on WTRU-601 is long and the interval is long enough to clear the congestion.

[0113] Another procedure for congestion control is unicast link establishment rejection. In this congestion control procedure, a link establishment exists and can be ongoing between 2 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 that specifies a V2X service. Interested peer WTRUs reply by initiating an establishment procedure, such as sending a DCR message to the initiating WTRU.

[0114] FIG. 7 is an example of a direct communication rejection message with a back-off timer. WTRU 701 performs congestion monitoring at 706 and initiates a communication establishment message at 708 that also specifies a congestion level. At 710, WTRU 702 receives the communication establishment message and decides to reject the establishment of the communication link. WTRU 702 sends a communication rejection message at 712 that includes a back-off timer. WTRU 701 receives the communication rejection message at 714 and starts the back-off timer. At 716, WTRU 701 decides to send another communication establishment message. At 718, WTRU 702 receives the communication establishment message and decides to accept the establishment of the communication link. At 720, WTRU 702 sends a communication acceptance message to WTRU 701. FIG. 7 ​In the unicast link establishment rejection procedure, the initiating WTRU (WTRU 701) includes the congestion level on the DCR message 710 broadcast to peer WTRUs 702, 703, and 704. At 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, the congestion level received on the broadcast message from WTRU 702 and the congestion level on the peer WTRU side WTRU 702 and WTRU 704 can be evaluated. If it is determined that there is no adverse congestion, WTRU 702 and WTRU 704 send back a DCR message to WTRU 701 specifying their congestion level.

[0115] WTRU 701 receives such a DCR message 714 from, for example, WTRU 702, evaluates the congestion level that WTRU 701 is experiencing at this time, and at 716, can 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 the 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, upon receiving the DCR from WTRU 704, the congestion situation has worsened and WTRU 701 determines that the congestion level at WTRU 701 is not acceptable, so 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 the direct communication rejection message 728 including the backoff interval, at 730, WTRU 704 uses the interval specified on the release message to start a backoff timer. The backoff timer is associated with the interval value and L2 ID of WTRU 701. That is, at 732, WTRU 704 tracks the L2 ID and backoff interval association. Upon expiration of the backoff timer, WTRU 704 can attempt to establish communication with WTRU 701 again by sending a DCR message 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 is determined that the congestion level is too high (i.e., not acceptable), the backoff timer is restarted and no attempt to establish communication is made.

[0118] A peer WTRU, such as WTRU 704, can also assess the congestion level of WTRU 701 by tracking the last notification of congestion received from WTRU 701 as described for the unicast link release procedure. If a back-off timer is running on this particular WTRU (i.e. WTRU 704) and optionally on this particular V2X service, the WTRU 704 can track this congestion level. At the expiration of the back-off timer, the WTRU 704 can take into account the saved congestion level of WTRU 701 and decide whether to send another DCR or not, depending on whether the congestion still exists. If it is decided not to send a DCR, the back-off timer is restarted. The congestion level saved by WTRU 701 can be saved together with a timestamp (from the broadcast message) to make sure it is still accurate. This is done in case the broadcast interval on WTRU 701 is long enough to clear the congestion.

[0119] Yet another procedure for congestion control is unicast link reconfiguration. In some cases, congestion can be detected and the WTRU can decide to reconfigure the existing communication to limit the amount of signaling traffic sent until the congestion is cleared. Also, the requested QoS can be modified to try to adapt to the existing conditions. These reconfigurations are described in more details below.

[0120] One reconfiguration that can be taken as a result of a congestion situation is the QoS. A QoS profile associated with a V2X application can be provisioned on the WTRU as described later in this document. Depending on the congestion situation, a new QoS profile that can describe the priority, the delay, etc. and a range (minimum distance that the QoS parameters need to meet) can be applied to adapt to the actual situation. When congestion is detected, the V2X peers can agree on the QoS profile and range to apply and a signaling message (such as a keep-alive procedure or a different PC5 signaling procedure) can be used to trigger the new QoS profile and range to apply and the current congestion level to be specified.

[0121] Another possibility can be to inform the QoS profile and range for each congestion level during the communication establishment, i.e. when sending the direct communication request message. A new QoS profile and range can be applied each time a new congestion level with a corresponding QoS profile is informed.

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

[0123] It is also possible that when using one of the previously described methods to notify the congestion level, the WTRU can also include an indication that QoS signaling and / or SM signaling is not allowed. Thus, when a congested WTRU sends such an indication, the WTRU can refrain from sending any PC5 signaling to reconfigure the QoS of the PC5 link. The WTRU can also implicitly take such action based on the observed / notified congestion level. Furthermore, when a 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, no QoS signaling traffic can be sent during the specified interval.

[0124] A second reconfiguration that can be taken as a result of congestion can be to set the interval for periodic messages such as keep-alive or privacy or key update. The basic procedures for keep-alive, privacy protection, and key update already exist. These procedures repeat periodically. That is, signaling messages are exchanged between 2 peers at specific intervals. To limit congestion at the initiating WTRU or peer WTRU, it can be necessary to reduce the signaling messages sent per existing communication. This can be done by increasing the interval based on the observed congestion. As a novel feature, the congestion level is added to the messages described above. In addition, a new congestion indication is added and the interval value is reconfigured as needed.

[0125] FIG. 8is an example method of reconfiguration based on congestion levels received from a peer WTRU. This example includes inter-link interval reconfiguration. Congestion monitoring can be performed at 804 at WTRU 801 and at 806 at WTRU 802. Communication between the two WTRUs is ongoing at 808. At 810, WTRU 802 detects a congestion level. As FIG. 8 As shown in 807, 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 looks at the received congestion level of WTRU 802 and whether congestion control is needed (e.g., based on provisioned QoS threshold), WTRU 801 can reconfigure the periodic timer to a larger value. The congestion level can indicate that congestion control is needed or is no longer needed. A congestion indication can be specified, indicating which functionality should congestion control be applied to, e.g., specific SM signaling or QoS reconfiguration of PC5. FIG. 8 The trigger mechanism for sending a direct keep-alive message acknowledgement from WTRU 801 in 807 is that WTRU 801 has evaluated the WTRU 802 congestion level in the direct communication keep-alive message 812 from WTRU 802. The evaluation at 814 indicates that, based on one or both of the congestion of WTRU 801 or WTRU 802, a back-off interval in the keep-alive acknowledgement message 816 sent by WTRU 801 to WTRU 802 can be appropriate. This back-off interval has the effect of exchanging fewer periodic keep-alive messages between WTRU 801 and WTRU 802, and thus can reduce congestion.

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

[0127] FIG. 9 The reconfiguration using the keep alive procedure is illustrated. However, the same mechanism (i.e. addition of congestion level and adaptation of periodic interval) can be applied to other periodic procedures, such as privacy protection messages and key update messages. The WTRU can trigger the keep alive / privacy protection / key update procedure in addition to the existing triggers. One possible trigger can be that congestion can be detected and the signaling traffic should be reduced (e.g. increase interval) to reduce congestion. Another possible trigger can be that congestion is no longer detected and the reduction of interval can be indicated.

[0128] When the procedure needs to run, the WTRU can reconfigure the periodic interval. For example, the periodic interval can be reconfigured because the 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 can be performed when the running timer expires or due to other triggers that execute the procedure. The WTRU then adds the previous saved congestion level indication and the new interval to the message and sends the message to the peer WTRU to delay the next execution of the procedure.

[0129] Alternatively, when congestion is observed or notified, WTRUs can implicitly increase their keep-alive timer value. When a keep-alive message is not received at the expiration of the keep-alive timer, the WTRU currently implicitly assumes that the PC5 link is not available. It is proposed that during congestion, the WTRU can increase (e.g., double) the keep-alive value and then only expect the keep-alive message after the increased keep-alive timer expires. The value of the timer can be implicitly increased by the WTRU based on the congestion level.

[0130] Another congestion control technique is referred to as RAT offloading. RAT offloading can be used to reduce congestion on a RAT. To support this feature, WTRUs can first need to exchange their capabilities during the communication setup procedure. For example, if congestion is detected on the initiating WTRU, the WTRU can suggest its peer WTRU to setup the link on another RAT. An example alternative RAT is LTE-PC5 or 5G-PC5, either of which can be expected to be less or not congested. The initiating WTRU can suggest a list of RATs specific to a V2X service or V2X application in a preferred order. To setup the 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 offloading can be done in different ways. Three alternatives are discussed herein:

[0132] A. Using a direct communication release message when the communication has already been established;

[0133] B. Using a direct communication reject message during the communication setup; and

[0134] C. Using a periodic message, such as a keep-alive, privacy protection, or key update procedure while the communication is still ongoing.

[0135] If a direct communication release or direct communication reject message is used, the peer WTRU can decide to wait or immediately try the suggested RAT before trying to reestablish the communication (using a back-off timer) on the same RAT. The decision can be based on policies configured on the WTRU. Such policies can depend on the V2X service, urgency of the data being sent, etc. This RAT offloading is illustrated in FIG. 10 for alternative A, using a direct communication release message, and in FIG. 11 for alternative B, using a direct communication reject message. As shown in FIG. 10 and FIG. 11 , the first WTRU and the second WTRU exchange their capabilities during the communication setup.

[0136] Considerations FIG. 10Alternative A in FIG. 10 (i.e., RAT offloaded direct communication release message method), uses DCR message 1004 and DCA message 1006 to exchange capabilities between WRTU 1001 and WTRU 1002. Communication is established over 5G-PC5. WTRU 1001 detects congestion at 1008 and decides to release the communication using direct communication release message 1010. This is followed by FIG. 10 direct communication release accept message 1012 in FIG. 10. Consider FIG. 11 Alternative B in FIG. 11 (i.e., RAT offloaded direct communication reject message method), uses DCR message 1104 and DCR message 1106 to exchange capabilities. The communication request is rejected due to congestion at 1108.

[0137] A backoff timer is provided on the direct communication release message 1010 in FIG. 10 and FIG. 10 direct communication reject message 1110 in FIG. 11, as described above and as shown in FIG. 11 and FIG. 10 and FIG. 11 The first WTRU suggests in the direct communication release message 1010 in FIG. 10 and FIG. 10 direct communication reject message 1110 in FIG. 11 that the second WTRU offload the communication to another RAT (such as LTE-PC5). FIG. 11

[0138] Upon receiving the release or reject message with the offloaded RAT and backoff timer, the second WTRU decides what it should do. The second WTRU can immediately establish communication with the first WTRU on the suggested offloaded RAT or start the backoff timer and upon expiration, re-attempt to establish communication on the current RAT which can no longer be congested. In the example of FIG. 10 and FIG. 11 FIG. 11, WTRU 1002 and WTRU 1102 decide to offload the communication to the suggested RAT, i.e., LTE-PC5 in active block 1004 in FIG. 10 and FIG. 10 active block 1112 in FIG. 11. FIG. 11

[0139] In FIG. 10, once the decision to offload to the LTE-PC5 link is made, WTRU 1002 sends DCR message 1016 to WTRU 1001 over the LTE-PC5 communication link. DCR message 1016 includes the congestion level of WTRU 1002. WTRU 1001 can then send DCA message 1018 to WTRU 1002 over the LTE-PC5 communication link. DCA message 1018 includes the congestion level of WTRU 1001. FIG. 10 In FIG. 11, once the decision to offload to the LTE-PC5 link is made, WTRU 1102 sends DCR message 1116 to WTRU 1101 over the LTE-PC5 communication link. DCR message 1116 includes the congestion level of WTRU 1102. WTRU 1101 can then send DCA message 1118 to WTRU 1102 over the LTE-PC5 communication link. DCA message 1118 includes the congestion level of WTRU 1101.

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

[0141] If periodic messages are used for the instruction to offload to another RAT, then the communication between the WTRUs can still be ongoing. Periodic messages can be used to trigger RAT offloading. This use of periodic messages can signal to the peer WTRU that congestion is detected and offloading is suggested. A list of potential RATs in a preferred order can be provided. Such a list can be provided, for example, 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. The ongoing communication on the congested RAT can then be released. This is shown in FIG. 12

[0142] In FIG. 12, the first WTRU 1201 has an ongoing direct communication link 1204 with the second WTRU 1202. At 1206, the WTRU 1201 detects congestion and makes a decision to suggest offloading to another RAT. A direct communication keep-alive message 1208 is sent to the WTRU 1202, which includes the congestion level of the WTRU 1201 and an offload indication to the new RAT: LTE-PC5. The WTRU 1202 sends a direct keep-alive acknowledgement message 1210. At 1212, the WTRU 1202 makes a decision to offload to another RAT based on the information received in message 1208. The WTRU 1202 sends a DCR on the LTE-PC5 Rat to the WTRU 1202, which indicates the congestion level of the WTRU 1202. The WTRU 1201 accepts the DCR by sending a DCA 1216 indicating the congestion level of the WTRU 1201. At 1218, the two WTRUs communicate on the LTE-PC5 communication link. After successfully communicating on the LTE-PC5 RAT, the WTRU 1202 can initiate offloading of the communication established on the originally used 5G-PC5 RAT at step 1220. The WTRU 1202 sends a direct communication release message 1222 to the WTRU 1201 to release the 5G-PC5 RAT link. The 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, the peer WTRU can decide to release the ongoing congested communication immediately before attempting to establish communication on another RAT. The decision can be based on policies configured on the WTRU taking into account factors such as V2X services, urgency of sending data, etc.

[0144] As previously mentioned, the ongoing communication can become congested, i.e., the RAT in use can become congested. The WTRU can decide to offload the communication to another RAT. The decision, as in the examples discussed above with respect to release and reject, can be based on various factors such as policies of the V2X application using this communication, capabilities of the peer WTRU such as access to other RATs, congestion of available alternative RATs, etc.

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

[0146] The WTRU can be provisioned with enabling / disabling the congestion control feature. If congestion control is enabled, the related parameters can be provisioned. For example, congestion control can be enabled or disabled. The number of communications between 2 peers before declaring congestion open indication can be set to some allowed limit. One example limit for congestion open decision can be 10 communications between peers. The number of communications allowed before declaring congestion closed case / state can be set to indicate when congestion case / state can be closed. One example limit for congestion closed case / state from congestion open case / state can be the number of communications between peers reduced to 7. The WTRU can be provisioned with a table per V2X application ID (e.g., PSID or ITS-AID) to indicate congestion levels where QoS profiles are configured per QoS level and range. In addition, the table can be a list of supported RATs in preferred order for offloading.

[0147] In an additional method of communicating congestion levels from an initiating WTRU to a peer WTRU, the initiating WTRU can limit the response to a proposal to establish communication with the peer WTRU. Here, the initiating WTRU can send a list of requirements that the peer WTRU is to satisfy before accepting the link establishment provided by the initiating WTRU. The initiating WTRU can include such a list of requirements along with a link establishment request sent to one or more peer WTRUs along with the congestion level of the initiating WTRU.

[0148] While features and elements are presented and described above in particular combinations, one of ordinary skill in the art will appreciate that each feature and element can be used alone or in any combination with the other features and elements. In fact, many of these features and elements can be used to implement different embodiments of the disclosure in different ways. The disclosure is not limited to the specific embodiments described herein but can be practiced with modification and alteration within the scope and spirit of the appended claims. The description herein of any aspect of any of the claims using terms such as "comprising", "driving", "including", and "having" are used to provide insight to one of ordinary skill in the art to the scope of the current application. The patentable scope of the application is defined by the appended claims and can include other elements or steps in addition to or other than the elements and steps described herein.

[0149] For simplicity, the foregoing embodiments are discussed in terms of terminology and structures related to devices having 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 acoustic waves.

[0150] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can mean any one of a snapshot, a single image, and / or a plurality of images displayed on a time basis. By way of further example, the term "user equipment" and its acronym "UE" mentioned herein, the term "remote" can mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a device having wireless capability and / or wired capability (e.g., connectivity), particularly, which configures some or all structures and functions of a WTRU; (iii) a device having wireless capability and / or wired capability, which configures less than all structures and functions of a WTRU; or (iv) a similar device. In this document, the term "remote" is used in relation to FIGS. 1A-1D Details of an example WTRU, which can represent any of the WTRUs described herein, are provided.

[0151] Furthermore, the methods provided herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (optical, electrical or the like) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, removable floppy disks, RAM, ROM, RAM, non-volatile computer storage media and the like. The processor associated with the software can be for execution of instructions as provided in the WTRU, UE, terminal, base station, RNC or any host computer.

[0152] Various modifications to the implementations described in this disclosure can and are possible without departing from the scope of the present disclosure. Given the foregoing description of the implementations according to the embodiments discussed above, one skilled in the art will appreciate that the embodiments provide functionality to perform certain actions, and that the means for performing the actions can include various hardware or software elements. It will be appreciated that the embodiments described above are cited by way of example, and that the present disclosure is not limited to what has been described above. Rather, it will be appreciated that the scope of the embodiments is broader than has been described above and / or governed by the following claims.

[0153] Furthermore, in the embodiments provided above, processing platforms, computing systems, controllers and other devices are noted that include a processor. These devices can include at least one central processing unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or computations unambiguously maintains the possessive relationships in the acts, such as referring to "CPU" and "memory" versus "the CPU and the memory" as appropriate.

[0154] Those having ordinary skill in the art will appreciate that the acts and symbolically represented operations or computations include the manipulations of electrical signals by the CPU. The electronic system representations, signals, whether analog or digital, combined on a single microchip, and the signals, whether analog or digital, spanned

[0155] Data bits can also be maintained on a computer readable medium including magnetic 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 readable by the CPU. The computer readable medium can include cooperating or interconnected computer readable media, which exist exclusively in the processing system, or distributed among multiple interconnected processing systems located locally or remotely from the processing system. It is understood that the embodiments are not limited to the above-mentioned memories, and that other platforms and memories can support the provided methods.

[0156] In illustrative embodiments, any of the operations, processes, etc. described herein can be implemented as computer-readable instructions saved on a computer-readable medium. The 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 distinction between the design choice of a hardware system and a software system in terms of the implementation of the embodiments. The choice of whether to implement the processing and / or systems and / or other techniques described herein in hardware or software (or both) is a design choice that will often be determined based on efficiency, cost, and time preferences of the implementer. The processing and / or systems and / or other techniques described herein can be implemented in a variety of ways, such as hardware, software, and / or firmware. The preferred implementation can vary, based on the context in which the processing and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer can opt for a mainly hardware and / or firmware implementation. If flexibility is paramount, the implementer can opt for a mainly software implementation. Alternatively, the implementer can opt for some combination of hardware, software, and / or firmware.

[0158] The above detailed description has discussed various embodiments of devices and / or processes via the use of block diagrams, flowcharts, and / or examples. As a block diagram, flowchart and / or example contains one or more functions and / or operations, those skilled in the art will appreciate 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 an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), and / or other integrated formats. Those skilled in the art will recognize however, that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media utilized to actually carry out this distribution. Examples of a signal bearing media include but are not limited to the following: a recordable type medium such as a floppy diskette, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and transmission type media such as a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired

[0159] Those skilled in the art will recognize that the description of apparatus and / or process which is given herein is illustrative only and that the described apparatus and / or processes can be implemented in an appropriate data processing system, using engineering practices to produce engineering of such apparatus and / or processes, as is within the skill of those in the art. That is, at least portions of the apparatus and / or processes described herein can be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following components: a system unit housing, a video display device, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity; control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0160] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable", to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0161] With respect to any plural entity including the terms "comprise", "comprises", "comprising", "include", "includes", "including" and the like, there are a possibility that the plural entity is intended to convey the meaning of the singular entity to the exclusion of any other potential meaning(s) of the plural entity. Specifically, there is a possibility that these terms are intended to convey the meaning of "consist of only the elements specified" in the plural entity, to the exclusion of any other potential meaning(s) of the plural entity. In contrast, with respect to any plural entity including the terms "including", "includes", "included", "contain", "contains", "containing" and the like, there is a possibility that the plural entity is intended to convey the meaning of the plural entity only and not the singular entity to the exclusion of any other potential meaning(s) of the plural entity. Specifically, there is a possibility that these terms are intended to convey the meaning of "including, without limitation, the specified elements" in the plural entity, to the exclusion of any other potential meaning(s) of the plural entity.

[0162] Those skilled in the art will appreciate that, in general, the terms used in this document, including in the appended claims (e.g., in the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" is intended to be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further appreciate that if an introduced claim recitation is intended to be of a specific quantity, that should be expressly recited in the claim, and if it is not, such an intent is not present. For example, if it is intended that there be only one item, the term "single" or similar language can be used. As an aid to understanding, the appended claims and / or the description herein can include the use of the introductory phrases "at least one" and "one or more" to introduce a claim recitation. However, the use of such phrases is not to be construed to mean that any specific claim recitation introduced by the phrases is in itself limiting as to any specific claim. For example, when the phrase "at least one" or "one or more" appears in the body of a claim, it should be construed that the claim is intended to encompass any of the possibilities of the recited items, including one, two, three, etc., of the items. The same applies to the use of other grammatical articles, such as "a" or "an." This same principle applies to any use of the terms "comprising," "including," "containing," "having," and the like. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such a recitation should be interpreted to mean at least the recited number (e.g., a recitation of "two recitations" without additional modifiers means at least two recitations or two or more recitations). In addition, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to the systems comprising only A, or only B, or only C, or only A and B, or only A and C, or only B and C, or only A and B and C, or the systems comprising A, B, and C etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to the systems comprising only A, or only B, or only C, or only A and B, or only A and C, or only B and C, or only A and B and C, or the systems comprising A, B, or C etc.). It will be further understood by those skilled in the art that virtually any disjunctive word and / or phrase presenting two or more alternative items, whether in the description, claim, or drawings, should be understood to contemplate the possibilities of including one of the items, either of the items, or both of the items.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Still further, as used herein, the term "any of" followed by a listing of a plurality of items and / or categories of items will be understood to include any one of those items and / or categories of items individually or in combination with any of the other items and / or categories of items. Furthermore, as used herein, the term "set" will be understood to include any number of items, including zero. Additionally, as used herein, the term "number" will be understood to include any number, including zero.

[0163] Further, where features or aspects of the disclosure are described in terms of Markush groups, a person of ordinary skill in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0164] As will be understood by those of ordinary skill in the art, all ranges disclosed herein are also intended to encompass any and all possible sub-ranges and combinations of sub-ranges encompassed by the stated ranges. Any maximum numerical limitation

[0165] Further, no limitation will be implied by use of the term "comprising" in the claims. Moreover, any claim that is dependent on another claim should be construed as using the language "comprising" to the extent that no other explicit language to the contrary appears therein and the colon cannot be interpreted as equivalent to "consisting of." Additionally, the use of a progression of terms such as "one," "another," "an," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "certain," "

Claims

1. A method for communication, comprising: The peer-to-peer wireless transmit / receive unit (WTRU) receives a first message from the initiating WTRU, the first message including an indication of the congestion level experienced by the initiating WTRU; as well as Establishing communication with the initiating WTRU includes sending a second message to the initiating WTRU, the second message being sent after the first message has been received.

2. The method according to claim 1, wherein, Receiving the first message includes receiving a direct communication request message, and sending the second message to the initiating WTRU includes sending a direct communication accept message.

3. The method of claim 1, further comprising determining the establishment of the communication based on an indication of the congestion level experienced by the initiating WTRU.

4. The method according to claim 1, further comprising: The peer WTRU receives a third message from the initiating WTRU, and the third message instructs the release of the established communication with the initiating WTRU.

5. The method according to claim 4, wherein, The third message includes a direct communication release message, which includes an indication of the congestion level correction experienced by the initiating WTRU and a backoff interval value.

6. The method according to claim 4, further comprising: A fourth message is sent to the initiating WTRU, the fourth message accepting an instruction to release the established communication with the initiating WTRU.

7. The method according to claim 6, wherein, The fourth message includes a direct communication release accept message.

8. The method according to claim 5, further comprising: Communication with the initiating WTRU is re-established after the backoff interval expires.

9. The method according to claim 1, wherein, The second message includes an indication of the congestion level of the peer WTRU.

10. A peer-to-peer wireless transmit / receive unit (WTRU) comprising circuitry including a transmitter, a receiver, a processor, and a memory, wherein the WTRU is configured to: Receive a first message from the initiating WTRU, the first message including an indication of the congestion level experienced by the initiating WTRU; and Establishing communication with the initiating WTRU includes sending a second message to the initiating WTRU, the second message being sent after the first message has been received.

11. The peer WTRU according to claim 10, wherein, The first message includes a direct communication request message, and the second message includes a direct communication acceptance message.

12. The peer WTRU according to claim 10, wherein, The WTRU is configured to determine whether to establish communication with the initiating WTRU based on an indication of the congestion level experienced by the initiating WTRU.

13. The peer WTRU of claim 10, further configured as follows: The third message is received from the initiating WTRU, and the third message instructs the release of the established communication with the initiating WTRU.

14. The peer WTRU according to claim 13, wherein, The third message includes a direct communication release message, which includes an indication of the congestion level correction experienced by the initiating WTRU and a backoff interval value.

15. The peer WTRU of claim 13, further configured as follows: A fourth message is sent to the initiating WTRU, the fourth message accepting an instruction to release the established communication with the initiating WTRU, the fourth message including a direct communication release accept message.

16. The peer WTRU of claim 14 is further configured to: re-establish communication with the initiating WTRU after the backoff interval expires.

17. The peer WTRU according to claim 10, wherein, The second message includes an indication of the congestion level of the peer WTRU.

Images