Congestion Control Process of PC5 Communication

Abstract

An initiating wireless transmit receive unit (WTRU) includes circuitry configured to monitor, by the initiating WTRU, a congestion level experienced by the initiating WTRU while communicating with at least one peer WTRU. Detection of the congestion level by the initiating WTRU triggers 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-REFERENCE 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] The present disclosure relates to network communications, including but not exclusively to vehicular wireless communication technology services based on a 5G communication architecture. Background Art

[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) communications. The 5G specifications define multiple types of reference point interfaces. However, not all communication methods are defined. The present disclosure addresses issues in V2X communications where communication congestion can affect V2V or V2X communications over the PC5 reference point interface between multiple user equipments (UEs). Summary of the Invention

[0005] A method, apparatus, and computer-readable storage medium for resolving congestion in a wireless transmit / receive unit (WTRU) communicating with a peer WTRU includes monitoring, by an initiating WTRU, a level of congestion experienced by the initiating WTRU while communicating with at least one peer WTRU (locally observed), detecting the congestion level by the initiating WTRU, triggering congestion control, and sending, by the initiating WTRU, at least one message based on the congestion level to reconfigure ongoing communications between the initiating WTRU and the at least one peer WTRU.

[0006] In further features, the initiating WTRU may send at least one message to reconfigure ongoing communications based on the congestion level by sending periodic messages. The periodic message may be one of a keep-alive message, a privacy protection message, and / or a key update message. The at least one reconfiguration message may be a message that changes the periodic message interval.

[0007] In another feature, the initiating WTRU may send at least one message to reconfigure the ongoing communication to a message indicating a change in quality of service (QoS). In one example, the change in QoS may include changing a QoS parameter of a PC5 QoS indicator (PQI) to a lower value compared to a current value.

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

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

[0010] Although various embodiments are described and / or claimed herein in which devices, systems, equipment, etc. and / or any elements thereof implement operations, processes, algorithms, functions, etc. and / or any portion thereof, it should be understood that any embodiment described and / or claimed herein assumes that any device, system, equipment, etc. and / or any elements thereof are configured to implement any operations, processes, algorithms, functions, etc. and / or any portion thereof. Unless otherwise expressly stated herein, features of one embodiment may be combined with another embodiment. Furthermore, embodiments and / or features of embodiments may be combined to achieve further advantageous results. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with the accompanying drawings attached hereto. As with the detailed description, the figures in such drawings are examples. As such, the drawings and detailed description should not be considered limiting, and other equally effective examples are also possible and feasible.

[0012] Furthermore, like reference numerals ("REF") in the drawings indicate like elements, and wherein:

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

[0014] Figure 1B is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example WTRU for use within a communications system is shown in FIG.

[0015] Figure 1C is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system illustrated in FIG.

[0016] Figure 1D is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of a further example RAN and a further example CN for use within the communication system illustrated in FIG.

[0017] Figure 2 A signaling diagram describing the Layer 2 link establishment process for V2X services between peer WTRUs.

[0018] Figure 3 A signaling diagram describing the Layer 2 link establishment process for a WTRU;

[0019] Figure 4 An example signal diagram illustrating a WTRU of interest initiating a link establishment procedure is described;

[0020] Figure 5 A signal diagram illustrating determining which WTRU handles a communication link reconfiguration is described;

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

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

[0023] Figure 8 Described is a signal diagram illustrating unicast link interval reconfiguration based on a congestion level received from a peer WTRU;

[0024] Figure 9 A signal diagram illustrating unicast link interval reconfiguration based on detected congestion levels is described;

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

[0026] Figure 11 A signal diagram illustrating radio access technology offloading due to congestion control using reject messages is described; and

[0027] Figure 12 Signal diagrams illustrating radio access technology offloading due to congestion control using keep-alive messages are described. DETAILED DESCRIPTION

[0028] A detailed description of illustrative embodiments will now be described with reference to the various accompanying drawings. While this description provides detailed examples of possible implementations, it should be noted that the purpose of these details is exemplary and in no way limits the scope of the present application. Numerous specific details will be set forth in the following detailed description in order to provide a comprehensive understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth in detail herein. In other cases, well-known methods, processes, components, and circuits are not described in detail to avoid confusion with subsequent descriptions. Furthermore, embodiments and examples that are not specifically described herein may also be practiced, thereby replacing or combining with the embodiments and other examples described, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively, "provided") herein.

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

[0030] like Figure 1AAs shown in FIG, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, 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 may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “base station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, 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 (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0031] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, 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 may include any number of interconnected base stations and / or network elements.

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

[0033] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may 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 may be established using any suitable radio access technology (RAT).

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

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

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

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

[0038] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0039] For example, Figure 1AThe base station 114b in the may be a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may 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 may 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 may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to Internet 110. Thus, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0040] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may 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. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in Figure 1A Although not shown in the figures, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may 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 may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0041] The CN 106 / 115 may 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 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as TCP, User Datagram Protocol (UDP), and / or IP from the Transmission Control Protocol / Internet Protocol (TCP / IP) internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0043] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B , the WTRU 102 may include, among other things, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0044] The processor 118 may 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may 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 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0045] The transmit / receive element 122 can be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via 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 a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive RF and light signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

[0048] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may 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).

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

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

[0051] The processor 118 may be further coupled to other peripherals 138, which may 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 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors, which may be one or more of the following: 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.

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

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

[0054] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may 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 may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

[0056] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is described as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also 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.

[0058] The SGW 164 may be connected to each eNode B 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0059] The SGW 164 may be connected to the PGW 166, which may 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.

[0060] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0061] Despite Figures 1A to 1D WTRUs are described in the WO 2007 / 030625 PCT / US2007 / 030625 as wireless terminals, but in certain representative embodiments, it is contemplated that such terminals may use a wired communication interface with a communication network (eg, temporarily or permanently).

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

[0063] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a distribution system (DS) or other type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from a STA outside the BSS may reach the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) source and destination STAs using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0064] When using 802.11ac infrastructure operation mode or similar operation mode, the AP can send beacons on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set 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) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) (including the AP) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0065] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a primary 20 MHz channel in combination with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0066] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or a 160MHz channel can be formed by combining two non-contiguous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The stream can be mapped to two 80MHz channels, and the data can be sent by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0067] 802.11af and 802.11ah support Sub 1GHz operating modes. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n 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 a representative embodiment, 802.11ah can support meter type control / machine type communication (such as MTC devices in macro coverage areas). MTC devices may have certain capabilities, for example, limited capabilities, which limited capabilities include support for (for example, only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (for example, to maintain very long battery life).

[0068] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) 1 MHz mode (e.g., an MTC-type device), 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, for example, because a STA (supporting only 1 MHz operating mode) is transmitting to the AP, the entire available frequency band can be considered busy, even if most of the frequency band remains idle and may be available.

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

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

[0071] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

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

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

[0074] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown in , gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0075] Figure 1DThe CN 115 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one Session Management Function (SMF) 183 a, 183 b, and possibly a Data Network (DN) 185 a, 185 b. While each of the aforementioned elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0078] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may 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 may 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.

[0079] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may 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 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0080] Given that Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more or all of the functionality described herein with respect to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulated device may be used to test other devices and / or emulate network and / or WTRU functionality.

[0081] The emulation device can be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device can be directly coupled to another device for testing purposes and / or can be tested using over-the-air wireless communications.

[0082] One or more emulation devices can perform one or more (including all) functions rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device can be utilized in a test lab and / or in a test scenario in a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices can be test devices. Direct RF coupling and / or wireless communication via RF circuitry (e.g., the RF circuitry can include one or more antennas) can be used by the emulation device to send and / or receive data.

[0083] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies, eg, using the same or different principles, which may be applicable.

[0084] As explained herein, a wireless transmit receive unit (WTRU) may be an example of a user equipment (UE). Therefore, the terms UE and WTRU may be used in the same context herein. The Layer 2 link establishment process for V2X services is as follows: Figure 2 As shown in . Figure 2 , direct communication request (DCR) messages 206, 208, 210 may be sent by 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 may be received by other WTRUs including WTRU 202, WTRU 203, and WTRU 204. Information about the V2X service for which a Layer 2 (L2) link is requested to be established (i.e., information about the advertised V2X service) may be included in the direct communication request message to allow other (peer) WTRUs to decide whether to respond to the request. All WTRUs that are interested in using the V2X service advertised by the direct communication request (DCR) message may respond to the request. For example, Figure 2 The WTRU 202 in responds to the DCR broadcast message with a Direct Communication Accept (DCA) message 212. Figure 2The WTRU 204 in responds to the DCR broadcast message with a DCA message 214. This link for V2X services is compliant with 3GPP TR 23.786 V1.1.0 (2019-01), Studying Architecture Enhancements for EPS and 5G Systems to Support Advanced V2X Services (Release 16).

[0085] Figure 3 The Layer 2 link establishment process for the WTRU is shown in FIG. Direct communication request messages 306, 308, and 310 may be sent by WTRU 301 using a broadcast mechanism, i.e., to a broadcast address associated with the application, such as to WTRUs 302, 303, and 304. An upper layer identifier (e.g., an upper layer ID) for WTRU 302 is included in the direct communication request message to allow WTRU 302 to decide whether to respond to the request. WTRU 302 may send a direct communication accept (DCA) message 312 in response to DCR message 306.

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

[0087] An initiating WTRU (e.g., WTRU 401) may broadcast supported V2X services over a PC5 radio access technology (RAT) (such as a 5G PC5 reference point interface) via broadcast DCR messages 406, 408, 410. Many WTRUs may be interested in such V2X services and may establish communications with the initiating WTRU. Likewise, many V2X services may be broadcast, so a WTRU may end up running multiple communications simultaneously to maintain and generate and / or receive data. In addition, unicast communications may be established with specific WTRUs, increasing the number of established communications, resource usage, etc. In one example, an interested WTRU 2 sends a DCR message 412 to the initiating WTRU 401, which may then respond with a DCA message 414.

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

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

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

[0091] Since the congestion level is always changing, it can be notified in a variety of ways or times or periodically. For example, when initiating unicast link establishment, during keep-alive, privacy protection and key update processes. Any periodic message sent by the WTRU is a candidate for containing congestion level or status information. Due to congestion, the initiating WTRU may reject the communication establishment request from another WTRU, or it may release the ongoing unicast communication. In both cases, a backoff interval can be specified on the release and rejection messages as well as an appropriate reason code indicating that the reason for the rejection is due to congestion. Therefore, the peer WTRU does not need to retry (re)establishing the communication immediately. A backoff timer is used on the peer WTRU for each peer Layer 2 identifier (L2 ID). The backoff timer can also be per L2 ID and V2X application ID Intelligent Transportation System Application Identifier (ITS-AID) Provider Service Identifier (PSID), that is, associated with the L2 ID of the initiating WTRU and may also be associated with the V2X application.

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

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

[0094] The WTRU may be provisioned with a QoS profile that maps to a congestion level and congestion control functionality that is enabled or disabled. Furthermore, congestion thresholds may be configured so that the WTRU knows when congestion is too high and congestion control can be applied, or when congestion is low enough to cancel congestion control measures. Reverse congestion control measures may include reconfiguring intervals to normal values, accepting new communication setups again, etc. Although many of the procedures in this document are described from the perspective of interactions between WTRUs at the V2X layer / NAS layer / ProSe layer or higher layers, the same procedures are applicable to RRC signaling exchanges between WTRUs.

[0095] According to a novel feature, congestion detection for WTRUs operating on PC5 RATs is based on link measurements. The access stratum (AS) layer processes the link measurements and may be aware of link congestion. The AS layer may send an indication to the V2X layer to inform it of the congestion condition (on / off) on a particular RAT. The congestion level may also be specified by the AS layer. Another possibility involves the AS layer providing measurement information to the V2X layer, which itself determines whether a congestion condition has occurred. In either case, it is assumed that the V2X layer may be aware of the congestion condition.

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

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

[0098] For example, during communication establishment, the WTRU may determine who is responsible for handling communication reconfiguration. The initiating WTRU may request responsibility and the responding WTRU may allow the responsibility to be allocated. Alternatively, the responding WTRU may request responsibility. The responding WTRU may be the one that makes the final decision, or it may be predetermined that the responding WTRU has and maintains reconfiguration responsibility. A WTRU may have responsibility for reconfiguring a particular communication, while a peer WTRU may have responsibility for another communication.

[0099] Figure 5The following examples illustrate how a WTRU may determine which is responsible for handling communication reconfiguration. These examples are based on the three methods of unicast link establishment described previously. Figure 5 In the specific example shown in FIG, WTRU 501 requests responsibility for handling communication reconfiguration using a DCR message 506. WTRU 502 accepts via a DCA 512 and a first communication may be established between WTRU 501 and WTRU 502, with WTRU 501 handling the reconfiguration. A second communication may be established between WTRU 501 and WTRU-4, with WTRU-4 requesting responsibility for the reconfiguration using a DCA message 514. WTRU 503 may then initiate establishment of communication with WTRU 501 and request handling of the reconfiguration via a DCR message 516. A third communication may be established between WTRU 503 and WTRU 501 via a DCA message 518. WTRU 502 may then initiate establishment of communication with WTRU 503 and request handling of the reconfiguration for that communication via a DCR message 520. A fourth communication may be established between WTRU 502 and WTRU 503 via a DCA message 522. Note that WTRU 502 has two communications (one with WTRU 501 and one with WTRU 503) and may be processing the reconfiguration for the communication (communication #4) only with WTRU 503. WTRU 501 is processing the reconfiguration for the other communication (communication #1). Alternatively, the WTRU notified of the congestion level may implicitly always be responsible for the reconfiguration of the PC5 unicast link.

[0100] A WTRU may be configured to monitor congestion and such a WTRU may notify other WTRUs of its congestion level in different ways, as described below. The congestion level may be notified as, for example, none, low, medium, high, etc. The congestion level may be notified 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.

[0101] In a first example technique for notifying the congestion level, the initiating WTRU may send a DCR with an indication of the initiating WTRU's congestion level. 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 WTRUs should establish a link with the initiating WTRU or whether the peer WTRUs should not establish a link due to a high congestion level that is expected to provide poor quality communications and not meet the required QoS. The initiating WTRU may 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 made in Figure 6 and Figure 7 Shown above.

[0102] In a second example technique for notifying the congestion level, an initiating WTRU may send a keep-alive message with an indication of the initiating WTRU's congestion level. Here, a link has already been established between two peer WTRUs. A peer WTRU receiving such a keep-alive message, wherein the message also includes an indication of the congestion experienced (i.e., the congestion level and the congestion indication), may apply congestion control on the existing link, as discussed below. A backoff interval for periodic keep-alive messages may also be specified. Furthermore, the interval may be signaling specific. That is, the interval may apply to session management (SM) signaling or QoS reconfiguration PC5 signaling or both.

[0103] In a third example technique for notifying the congestion level, the initiating WTRU may send a privacy-preserving message with an indication of the initiating WTRU's congestion level. This technique is similar to the keep-alive message technique in the second example technique above. Thus, the privacy-preserving message may contain an indication of the congestion level for evaluation by the peer WTRU.

[0104] In a fourth example technique for notifying the congestion level, the initiating WTRU may send a direct key update request message with the initiating WTRU's congestion level. Here, the technique is similar to the keep-alive message technique in the second example technique above. Thus, the direct key update request message may include a congestion level indication for the peer WTRU to evaluate.

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

[0106] 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 may be rejected. Existing communications can be reconfigured, for example by changing the intervals for keepalive, privacy, or key update procedures. The QoS applied to the communication can also be reconfigured. In the event that congestion on a particular RAT is too high, the communication may be released or offloaded to another RAT. These different methods are detailed below.

[0107] In case the congestion is too high, a unicast link release may be performed. In this case, a link has already been established between 2 peer WTRUs. When congestion is detected at the WTRU, the release of the existing communication may be triggered. How to determine which communication to release may be based on various criteria or a 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 traffic sent / received), or inactive communications or the least active communications may be selected or released when congestion is detected. Other examples of criteria include determination based on the number of flows (e.g., such as the communication with the smallest number of flows is released), determination based on application (ITS-AID / PSID) priority (e.g., the communication associated with the application with the lowest priority is released). Here, a priority may be provided for each application at the WTRU. Another example of criteria may be based on the PQI (PC5 QoS Indicator) and / or other QoS parameters of the different flows.

[0108] The congestion control explained below uses a V2X service-oriented approach and the last established communication to be released as an example. However, unicast link release is applicable to any link establishment procedure discussed herein and any criteria for communication selection for release as described herein.

[0109] like Figure 6 As shown in FIG, a direct communication release message with a backoff timer can be used to add congestion control to a method for V2X services. An initiating WTRU (WTRU 601) monitors its congestion 606 and initiates communication specifying its congestion level 608. WTRU 601 uses a broadcast DCR message 610 to notify WTRUs 602, 603, and 604 of its congestion level. Peer WTRU 602 is interested in V2X services and accepts the current congestion level and accepts the communication via a DCA message 614, which includes the WTRU 602 congestion level. Communication between WTRU 601 and WTRU 602 occurs at 616. WTRU 601 verifies the current congestion level, determines that there is no congestion, and communication establishment is completed 618.

[0110] At 620, a peer WTRU (WTRU 604) is interested in V2X services 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 WTRU 604 congestion level. Communication between WTRU 601 and WTRU 604 occurs at 624. At some later time, WTRU 601 may determine at 626 that its congestion level is too high. This may be determined in a variety of ways, including by the congestion level exceeding a threshold or indication. Upon receiving 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 may also be specified on this message. The backoff interval is sent to indicate to the peer WTRU (WTRU 604) how long to wait before attempting to reestablish the link. The WTRU 604 responds by sending a direct communication release accept message 630, and the communication 632 between the WTRU 601 and the WTRU 604 is terminated.

[0111] Upon receiving a direct communication release specifying a backoff interval, the peer WTRU (WTRU 604) starts a backoff timer at 634 using the value specified in the release message 628. This backoff timer and associated interval value is per L2 ID, i.e., per unicast communication. It could also be per L2 ID and V2X service. WTRU 604 tracks the L2 ID and backoff interval association, and possibly the associated V2X service, at 634. Upon expiration of the backoff timer, WTRU 604 may attempt to reestablish communication with WTRU 601 by sending a DCR message using the L2 ID associated with the backoff timer. WTRU 604 may verify that the congestion level on its side is acceptable before attempting to reestablish communication. If the congestion level is still determined to be too high, the backoff timer is restarted and no attempt to reestablish communication is made. While the backoff timer is running at WTRU 604, WTRU 604 may still attempt to establish PC5 direct communication with a different WTRU advertising the same service and having a lower congestion level. If the WTRU 604 is able to successfully establish a PC5 unicast connection with a different WTRU providing the same service, the WTRU 604 may stop the backoff timer.

[0112] A peer WTRU (WTRU 604) may also assess the congestion level of WTRU 601 by tracking the most recent congestion level notification received from WTRU 601. For example, the initiating WTRU 601 may notify supported V2X services by periodically generating a broadcast message such as a DCR that includes its current congestion level. WTRU 601 may also broadcast a DCR including its congestion level using a WTRU-oriented approach. Even if the message is not intended for WTRU 604, or if WTRU 604 is not interested in the broadcasted V2X services, WTRU 604 may still track the congestion level of WTRU 601 included in the broadcast message ( Figure 6 not shown).

[0113] If a backoff timer is running on this particular WTRU (i.e., WTRU-601) and optionally this particular V2X service, the WTRU 604 may track the WTRU-601 congestion level. Upon expiration of the backoff timer, the WTRU 604 may consider the saved congestion level of the WTRU-601 and decide whether to send another DCR, depending on whether congestion still exists. If a decision is made not to send a DCR, the backoff timer is restarted. The saved congestion level may be saved along with a timestamp (from the broadcast message) to ensure that it remains accurate. This is done in the event that the broadcast interval on the WTRU-601 is long and the interval is long enough for congestion to clear.

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

[0115] Figure 7 is an example of a direct communication rejection message with a backoff timer. The WTRU 701 performs congestion monitoring at 706 and initiates a communication setup message at 708 that also specifies the congestion level. Figure 7In a unicast link establishment rejection procedure, the initiating WTRU (WTRU 701) includes the congestion level in a DCR message 710 broadcast to peer WTRUs 702, 703, and 704. At 712 and 722, the peer WTRUs (WTRU 702 and 704), respectively, are interested in V2X services and consider whether the congestion level is acceptable. That is, if the peer WTRUs are monitoring their own congestion, they may evaluate the congestion level received in the broadcast message from WTRU 702 and the congestion levels on the peer WTRU side, WTRUs 702 and 704. If it is determined that there is no adverse congestion, WTRUs 702 and 704 send a DCR message back to WTRU 701, specifying their congestion levels.

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

[0117] 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 unacceptable, so it rejects the link establishment request by sending a direct communication reject message 728 to WTRU 704. A backoff interval is specified in the reject message. Therefore, communication is not established between WTRU 701 and WTRU 704.

[0118] Upon receiving the Direct Communication Reject message 728 including the backoff interval, the WTRU 704 starts a backoff timer at 730 using the interval specified in the release message. The backoff timer is associated with the interval value and the L2 ID of the WTRU 701. That is, at 732, the WTRU 704 keeps track of the L2 ID and backoff interval association. Upon expiration of the backoff timer, the WTRU 704 may attempt to establish communication with the WTRU 701 again by sending a DCR message using the L2 ID associated with the backoff timer. The WTRU 704 may verify that the congestion level on its side is acceptable before attempting to establish communication. If the congestion level is determined to be too high (i.e., unacceptable), the backoff timer is restarted and no attempt is made to establish communication.

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

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

[0121] One possible reconfiguration that may be required due to congestion is 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 describing priority, latency, etc., as well as a range (the minimum distance at which QoS parameters need to be met) can be applied to suit the situation. When congestion is detected, the V2X peers can agree on the QoS profile and range to apply. Signaling messages (such as a keep-alive procedure or a different PC5 signaling procedure) can be used to trigger the specification of the new QoS profile and range to apply, as well as the current congestion level.

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

[0123] The V2X layer can configure the AS layer based on the QoS profile and scope information exchanged between peer WTRUs. During link establishment, QoS parameters are typically 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 agreement is reached between the WTRUs, in the event of congestion, the WTRUs can implicitly reduce the QoS of the PC5 link by changing the link's QoS parameters (such as QFI, 5QI, PC5 QoS Indicator (PQI)) to lower, agreed-upon values. 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 and peer WTRUs) can negotiate three different PQIs during PC5 link establishment. An example might be PQIs a, b, and c, where "a" might be the highest and "c" the lowest. Traffic on this PC5 link can be sent with PQI a when there is no congestion, with PQI b at low to medium congestion levels, and with PQI c at high congestion levels. The WTRU implicitly changes the PQI based on the notified / observed congestion level.

[0124] It is also possible that when one of the previously described methods is used to signal the congestion level, the WTRU may 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 may avoid sending any PC5 signaling to reconfigure the QoS of the PC5 link. The WTRU may also take such action implicitly based on the observed / notified congestion level. Furthermore, when the WTRU receives a backoff interval during congestion (e.g., on a keep-alive message), the associated timer may be specific to SM signaling and / or QoS reconfiguration PC5 signaling. If specific to QoS signaling, QoS signaling traffic may not be sent during the specified interval.

[0125] A second reconfiguration that may be taken due to congestion conditions may be to set intervals for periodic messages such as keep-alive or privacy or key updates. The basic processes for keep-alive, privacy protection and key updates already exist. These processes are repeated periodically. That is, signaling messages are exchanged between the two peers at specific intervals. In order to limit congestion at the initiating WTRU or the peer WTRU, it may be necessary to reduce the signaling messages sent for each existing communication. This can be done by increasing the interval based on the observed congestion conditions. 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.

[0126] Figure 8This is an example method of reconfiguration based on a congestion level received from a peer WTRU. This example includes link interval reconfiguration. Congestion monitoring may 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 the congestion level. Figure 8 As shown in FIG, WTRU 801 receives a keep-alive message 812 from WTRU 802. In addition to the usual WTRU behavior upon receiving such a message, WTRU 801 checks the received congestion level of WTRU 802 at 814 and whether congestion control is required (e.g., based on a provisioned QoS threshold). WTRU 801 may reconfigure the periodic timer to a higher value. The congestion level may indicate whether congestion control is required or no longer required. A congestion indication may be specified to indicate to which function congestion control should be applied, such as specific SM signaling or QoS reconfiguration for PC5. Figure 8 The triggering mechanism for sending a direct keep alive message confirmation from WTRU 801 in 814 is that WTRU 801 has evaluated the congestion level of WTRU 802 in a direct communication keep alive message 812 from WTRU 802. The evaluation at 814 indicates that a backoff interval in a keep alive confirmation message 816 sent by WTRU 801 to WTRU 802 may be appropriate based on either or both of the congestion of WTRU 801 or WTRU 802. This backoff interval has the effect that fewer periodic keep alive messages will be exchanged between WTRU 801 and WTRU 802, and thus congestion may be reduced.

[0127] The WTRU 801 may also trigger congestion control and link reconfiguration based on its own congestion detection (i.e., without receiving any indication of congestion experienced by a peer WTRU). Figure 9, which depicts a unicast link interval reconfiguration based on a detected congestion level. At 904, the WTRU 901 monitors congestion. This congestion monitoring is observed by the WTRU 901 and monitored locally within the WTRU 901. Thus, the monitored congestion 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 the WTRU 902 occurs at 906. At 908, the WTRU 901 detects that congestion control is required (e.g., based on a provisioned QoS threshold). The WTRU 901 triggers a keep-alive procedure via a direct communication keep-alive message 910 and reconfigures the periodic keep-alive message timer to a larger value by including a congestion indication, its own congestion level, and a backoff timer value. The congestion indication indicates that congestion control is required (e.g., via the use of a keep-alive procedure). At 912, a direct communication keep alive confirmation message including the congestion level of WTRU 902 is sent from WTRU 902 to WTRU 901. At 914, a keep alive periodic timer is started or restarted in WTRU 902 based on the backoff interval value received from WTRU 901.

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

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

[0130] Alternatively, it is possible for WTRUs to implicitly increase the value of their keepalive timers when congestion is observed or notified. When no keepalive message is received upon expiration of the keepalive timer, the WTRU currently implicitly assumes that the PC5 link is unavailable. It is proposed that during congestion, the WTRU may increase (e.g., double) the keepalive value and then expect a keepalive message only after the increased keepalive timer expires. The timer value may be implicitly increased by the WTRU based on the congestion level.

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

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

[0133] A. When communication has been established, use direct communication to release the message;

[0134] B. During communication establishment, using a direct communication rejection message; and

[0135] C. Use periodic messages while communications are still ongoing, such as keep-alive, privacy protection, or key update procedures.

[0136] If a Direct Communication Release or Direct Communication Reject message is used, the peer WTRU may decide to wait or immediately try the suggested RAT before attempting (using a backoff timer) to reestablish communications on the same RAT. This decision may be based on policies configured on the WTRU. Such policies may depend on the V2X service, the urgency of sending data, etc. The RAT offload is performed using the Direct Communication Release message (Alternative A). Figure 10 and when using direct communication rejection messages (alternative B) Figure 11 As shown in Figure 10 and Figure 11 As shown in FIG, a first WTRU and a second WTRU exchange their capabilities during communication establishment.

[0137] consider Figure 10In alternative A (i.e., the Direct Communication Release message method of RAT offloading), capabilities are exchanged between the WTRU 1001 and the WTRU 1002 using the DCR message 1004 and the DCA message 1006. Communication is established on 5G-PC5. The WTRU 1001 detects congestion at 1008 and decides to release the communication using the Direct Communication Release message 1010. This is followed by Figure 10 Direct communication release acceptance message 1012 in consideration Figure 11 In alternative B (ie, the direct communication rejection message method of RAT offloading), capabilities are exchanged using DCR message 1104 and DCR message 1106. Due to congestion at 1108, the communication request is rejected.

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

[0139] Upon receiving a release or rejection message with the offload RAT and backoff timer, the second WTRU decides what it should do. The second WTRU may immediately establish communication with the first WTRU on the proposed offload RAT or start the backoff timer and upon expiration retry to establish communication on the current RAT which may no longer be congested. Figure 10 and Figure 11 In the example of WTRU 1002 and WTRU 1102, WTRU 1002 and WTRU 1102 decide to offload the communication to the proposed RAT, i.e. Figure 10 The activity box 1004 and Figure 11 LTE-PC5 in activity box 1112.

[0140] exist Figure 10 , once the decision to offload to the LTE-PC5 link is made, WTRU 1002 sends a DCR message 1016 over the LTE-PC5 communication link to WTRU 1001. DCR message 1016 includes the congestion level of WTRU 1002. WTRU 1001 may then send a DCA message 1018 over the LTE-PC5 communication link to WTRU 1002. DCA message 1018 includes the congestion level of WTRU 1001.

[0141] exist Figure 11, once the decision to offload to the LTE-PC5 link is made, WTRU 1102 sends a DCR message 1114 over the LTE-PC5 communication link to WTRU 1101. DCR message 1114 includes the congestion level of WTRU 1102. WTRU 1101 may then send a DCA message 1116 over the LTE-PC5 communication link to WTRU 1102. DCA message 1116 includes the congestion level of WTRU 1101.

[0142] If the periodic message is used for instructions to offload to another RAT, the communication between the WTRUs may still be ongoing. Periodic messages may be used to trigger RAT offloading. Such use of periodic messages may signal to the peer WTRU that congestion is detected and an offload is suggested. A list of potential RATs in order of preference may be provided. For example, such a list may be provided by triggering a keep-alive procedure. In this case, the peer WTRU may 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 may then be released. This is done in Figure 12 Shown in.

[0143] exist Figure 12 In FIG1 , a first WTRU 1201 has an ongoing direct communication link 1204 with a second WTRU 1202. At 1206, WTRU 1201 detects congestion and makes a decision to recommend offloading to another RAT. A direct communication keepalive message 1208 is sent to WTRU 1202, which includes WTRU 1201's congestion level and an offload indication to a new RAT: LTE-PC5. WTRU 1202 sends a direct keepalive acknowledgement message 1210. At 1212, WTRU 1202 makes a decision to offload to another RAT based on the information received in message 1208. WTRU 1202 sends a direct communication call confirmation (DCR) to WTRU 1202 over the LTE-PC5 RAT, which indicates WTRU 1202's congestion level. WTRU 1201 accepts the DCR by sending a direct communication acknowledgement (DCA) 1216 indicating WTRU 1201's congestion level. At step 1218, the two WTRUs communicate over the LTE-PC5 communication link. After successfully communicating over the LTE-PC5 RAT, WTRU 1202 may initiate offloading of the communication established over the initially used 5G-PC5 RAT at step 1220. WTRU 1202 sends a Direct Communication Release message 1222 to WTRU 1201 to release the 5G-PC5 RAT link. WTRU 1201 responds to the Release Request with a Direct Communication Release Accept message at step 1224. Consequently, offloading of the 5G-PC5 link is complete.

[0144] Alternatively, a peer WTRU may decide to immediately release an ongoing congested communication before attempting to establish communication on another RAT. This decision may be based on policies configured on the WTRU, taking into account factors such as V2X services, urgency of sending data, etc.

[0145] As previously mentioned, ongoing communications may become congested, i.e., the RAT in use may become congested. The WTRU may decide to offload communications to another RAT. This decision (as discussed above with respect to release and rejection) may be based on various factors, such as the policy of the V2X application using this communication, the capabilities of the peer WTRU (such as access to other RATs), congestion on available alternative RATs, etc.

[0146] When congestion is no longer observed, the WTRU that decided to apply congestion control measures may reverse those measures. Congestion may be alleviated on the WTRU itself or on its peers. In this case, existing communications may be reconfigured to the value of the periodic interval. Communications may also be offloaded back to the preferred PC5 RAT.

[0147] The WTRU may be provisioned to enable / disable the congestion control feature. If congestion control is enabled, the relevant parameters may be provisioned. For example, congestion control may be enabled or disabled. The number of communications between 2 peers may be set to some allowed limit before declaring a congestion on indication. An example limit for a congestion on decision may be 10 communications between peers. The number of communications allowed before declaring a congestion off condition / state may be set to indicate when the congestion condition / state may be closed. An example limit for a congestion off condition / state from a congestion on condition / state may be that the number of communications between peers is reduced to 7. The WTRU may be provisioned with a table for each V2X Application ID (e.g. PSID or ITS-AID) to indicate the congestion level, where a QoS profile is configured per QoS level and range. Additionally, the table may be a list of supported RATs for offloading in a preferred order.

[0148] In an additional method of communicating the congestion level from an initiating WTRU to a peer WTRU, the initiating WTRU may limit responses to offers to establish communications with a peer WTRU. Here, the initiating WTRU may send a set of requirements to be met by the peer WTRU before accepting a link establishment offer from the initiating WTRU. The initiating WTRU may include such a list of requirements along with a link establishment request sent to one or more peer WTRUs, along with the initiating WTRU's congestion level.

[0149] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature and component can be used alone or in any combination with other features and components. The present disclosure is not limited in accordance with the specific embodiments described in this application, which are intended to be illustrative of different aspects. As those skilled in the art will appreciate, many modifications and variations can be made without departing from the spirit and scope of the present disclosure. The elements, acts, or instructions used in the description of this application should not be understood as being essential or indispensable to the present invention unless explicitly provided in this manner. In addition to the methods and apparatus enumerated herein, those skilled in the art will appreciate from the above description that functionally equivalent methods and apparatus within the scope of the present disclosure. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the appended claims and the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

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

[0151] It should also be understood that the terms used herein are for the purpose of describing specific embodiments only and are not intended to be limiting. The term "video" or the term "image" as used herein may mean any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, the term "user equipment" and its abbreviation "UE", the term "remote" as mentioned herein may 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 capabilities and / or wired capabilities (e.g., connectable), in particular, configured with some or all of the structures and functions of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities, configured with less than all of the structures and functions of a WTRU; or (iv) a similar device. In this document regarding Figures 1A to 1D Details are provided for an example WTRU that may be representative of any WTRU described herein.

[0152] In addition, the methods provided herein can be implemented as a computer program, software or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital versatile discs (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0153] Various variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be employed, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the subsequent claims. For example, the embodiments provided herein include handheld devices that may include or be used with any appropriate voltage source (such as a battery) that provides any appropriate voltage.

[0154] In addition, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to actions or symbolic representations of operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0155] Those skilled in the art will appreciate that actions and symbolically represented operations or instructions include manipulation of electronic signals by a CPU. The electronic system represents data bits that may cause the electronic signals to be transformed or reduced thereby and memory locations in a memory system where the data bits are maintained, thereby reconfiguring or otherwise changing the CPU operation and other signal processing. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments herein are not limited to the aforementioned platforms or CPUs, and that other platforms and CPUs may support the provided methods.

[0156] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, or any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media, which may reside solely on the processing system or distributed among multiple interconnected processing systems located locally or remotely from the processing system. It should be understood that the embodiments are not limited to the aforementioned memories, and that other platforms and memories may support the provided methods.

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

[0158] There is little difference between hardware and software implementations of various aspects of the system. Whether to use hardware or software is usually (but not always, in some environments, the choice between hardware and software may be important) a design choice that represents a compromise between cost and efficiency. The processes and / or systems and / or other technologies described herein can be implemented by various vehicles (e.g., hardware, software and / or firmware), and the preferred vehicle can change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are primary, then the implementer can choose a vehicle that primarily uses hardware and / or firmware. If flexibility is primary, then the implementer can choose an implementation method that primarily uses software. Alternatively, the implementer can choose some combination of hardware, software and / or firmware.

[0159] The above detailed description has been described using block diagrams, flow charts and / or examples to illustrate different embodiments of the device and / or process. Just as such block diagrams, flow charts and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or any combination thereof. In an embodiment, several parts 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. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in whole or in part in an integrated circuit as: one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or any combination thereof, and according to the present disclosure, the circuit design and / or code writing of the software and / or firmware will be completely within the technical scope of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, recordable media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.), and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0160] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least portions of the devices and / or processes described herein can be integrated into data processing systems via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system typically may include one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application program, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or parameters). A typical data processing system can be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0161] The subject matter described herein sometimes illustrates different components that are contained within or are connected to different other components. It should be understood that the architecture described in this manner is merely an example, and in fact many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components that achieve the same function is effectively "associated", so that the desired function can be achieved. Therefore, any two components that are combined to achieve a specific function herein can be considered to be "associated" with each other, so that the desired function will be achieved, without considering architecture or intermediate components. Similarly, any two components that are associated in this manner can also be considered to be "operably connected" or "operably coupled" to each other, so as to achieve the desired function, and any two components that can be associated in this manner can also be considered to be "capable of being operably coupled" to each other, so as to achieve the desired function. The specific examples that can be operably coupled include, but are not limited to, components that can be physically paired and / or physically interacted and / or components that can wirelessly interact and / or wirelessly interact and / or components that logically interact and / or can logically interact.

[0162] As for the use of substantially any plural and / or singular terms herein, those skilled in the art can appropriately convert the plural to the singular and / or the singular to the plural according to the context and / or application. For the sake of clarity, various singular / plural permutations may be explicitly set forth herein.

[0163] Those skilled in the art will understand that, in general, terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), should generally be treated as "open-ended" terms (for example, the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if an introduced claim recitation is directed to a specific quantity, such intent should be expressly recited in the claim, and if such recitation is absent, such intent is not present. For example, if only one item is intended, the term "single" or similar language may be used. As an aid to understanding, subsequent appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that a claim recitation introduced by the indefinite article "a" or "an" will encompass any particular claim that includes only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). The same applies to definite articles used to introduce claim recitations. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be construed to refer to at least the recited number (e.g., the unmodified recitation of "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, such construction is generally made in a sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, such construction is generally made in a sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). Those skilled in the art would further understand that virtually any disjunctive word and / or phrase that sets forth two or more alternatives, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, any, or all two of those alternatives.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, as used herein, the term "any of" followed by a list of a plurality of items and / or a plurality of categories of items is intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of" the items and / or categories of items, alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any quantity, including zero.

[0164] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled 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.

[0165] As will be understood by those skilled in the art, for any and all purposes, such as providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any range listed can readily be considered to fully describe and enable the same range to be broken down into at least halves, thirds, quarters, fifths, tenths, and so on. As a non-limiting example, each range discussed herein is readily broken down into a lower third, a middle third, and an upper third, and so on. Those skilled in the art will understand that all language such as "at most," "at least," "greater than," "less than," and so on, is inclusive of the recited number and refers to a range that can subsequently be broken down into the subranges discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

[0166] Furthermore, the claims should not be read as limited to the order or elements provided unless stated to that effect. Furthermore, any claim using the term "means for..." is intended to invoke 35 U.S.C. §112,6 or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

Claims

1. A method for communication, comprising: receiving, by a peer wireless transmit / receive unit (WTRU), from an initiating WTRU, a first message including an indication of a 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 including an indication of a congestion level of the peer WTRU and sent after the first message is received.

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

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

4. The method according to claim 1, further comprising: A third message is received by the peer WTRU from the initiating WTRU, the third message instructing to release the established communication with the initiating WTRU.

5. The method according to claim 4, wherein The third message includes a direct communication release message including a revised indication of a congestion level 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 established communications 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 of claim 5, further comprising reestablishing communication with the initiating WTRU after expiration of the backoff interval.

9. A peer to peer wireless transmit / receive unit (WTRU), comprising circuitry including a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: receiving a first message from an initiating WTRU, the first message including an indication of a 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 including an indication of a congestion level of the peer WTRU and sent after the first message is received.

10. The peer WTRU of claim 9, wherein: The first message includes a direct communication request message, and the second message includes a direct communication accept message.

11. The peer to peer WTRU of claim 9, wherein: The WTRU is configured to determine to establish the communication with the initiating WTRU based on an indication of a congestion level experienced by the initiating WTRU.

12. The peer WTRU of claim 9, further configured to: A third message is received from the initiating WTRU, the third message instructing to release established communications with the initiating WTRU.

13. The peer to peer WTRU of claim 12, wherein: The third message includes a direct communication release message including a revised indication of a congestion level experienced by the initiating WTRU and a backoff interval value.

14. The peer WTRU of claim 12, further configured to: A fourth message is sent to the initiating WTRU, the fourth message accepting an instruction to release established communications with the initiating WTRU, the fourth message comprising a direct communication release accept message.

15. The peer WTRU of claim 13, further configured to re-establish communication with the initiating WTRU after expiration of the backoff interval.

Images