Procedure enabling v2x unicast communication over pc5 interface

Abstract

To provide a system, a method, and means for establishment of a vehicle-to-vehicle / road-to-vehicle (V2X) service oriented link.SOLUTION: A first wireless transmit receive unit (WTRU) can broadcast a direct communication request message. The direct communication request message can include a first security context identifier (ID). The first WTRU can receive a direct security mode command message from a second WTRU. The direct security mode command message can include a second security context ID. The first WTRU can determine a third security context ID by combining the first security context ID and the second security context ID. The first WTRU can establish, by using the third security context ID, a secure direct communication link with the second WTRU.SELECTED DRAWING: Figure 7A

Description

[Technical field]

[0001] The present invention relates to a procedure for enabling V2X unicast communication. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 794,052, filed Jan. 18, 2019, the contents of which are incorporated herein by reference.

[0003] Proximity service (ProSe) direct communication can be used to establish a communication path between two or more ProSe-enabled wireless devices. For example, ProSe direct communication between two wireless devices can be set up by establishing a layer 2 link over a PC5 reference point between them. The layer 2 link can be secure. Summary of the Invention [Problem to be solved by the invention]

[0004] A novel procedure is provided that enables V2X unicast communication. [Means for solving the problem]

[0005] A first wireless transmit / receive unit (WTRU) may transmit (e.g., via broadcast) a direct communication request message. The direct communication request message may include a first security context identifier (ID). The first security context ID may be associated with the first WTRU. The first security context ID may be or may include a set of most significant bits (MSBs) of a security key ID. The security ID may be a security key ID of K. D-sessThe first WTRU may receive a direct security mode command message from the second WTRU. The direct security mode command message may include a second security context ID. The second security context ID may be associated with the second WTRU. The second security context ID may include a set of least significant bits (LSBs) of a security key ID. The first WTRU may determine a third security context ID by combining the first security context ID and the second security context ID. The third security context ID may include a set of MSBs and a set of LSBs of the security key ID. The first WTRU may use the third security context ID to establish a secure direct communication link with the second WTRU. The first WTRU may generate a security context entry for the secure direct communication link with the second WTRU based on the third security context ID. The direct communication request message may include a list of supported vehicle-to-everything (V2X) services. The direct security mode command message may indicate one or more V2X services from a list of supported V2X services.

[0006] The direct security mode command message may be a first direct security mode command message. The first WTRU may receive a second direct security mode command message from a third WTRU. The second direct security mode command message may include a fourth security context ID. The fourth security context ID may be associated with the third WTRU. The fourth security context ID may include a set of LSBs of a security key ID. The first WTRU may determine whether the fourth security context ID is the same as the second security context ID. On a condition that the fourth security context ID is the same as the second security context ID, the first WTRU may send a direct security mode reject message to the third WTRU. The first WTRU may receive a third direct security mode command message from the third WTRU, e.g., in response to the direct security mode reject message. The third direct security mode command message may include a fifth security context ID. The fifth security context ID may be associated with the third WTRU. The fifth security context ID may include a set of LSBs of the security key ID.

[0007] The WTRU may receive a direct communication request message, for example, from the initiating WTRU, which may include the first security context ID. The WTRU may generate a second security context ID associated with the WTRU. The WTRU may send a direct security mode command message to the initiating WTRU, which may include the second security context ID. The WTRU may receive a direct security mode complete message, which may indicate that a secure direct communication link has been established between the WTRU and the initiating WTRU using a third security context ID. The third security context ID may include a security key ID (e.g., K D-sess The set of MSBs of the security key ID may be or may include a first security context ID generated by the initiating WTRU, and the set of LSBs of the security key ID may be or may include a second security context ID generated by the WTRU.

[0008] The WTRU may receive a direct security mode reject message, which may indicate a collision of a second security context ID (e.g., the LSB of a potential security key ID). The WTRU may create a new security context ID (e.g., a fourth security context ID) associated with the WTRU and send a second direct security mode command message to the initiating WTRU, which may include the fourth security context ID. The fourth security context ID associated with the WTRU is combined with the first security context ID generated by the initiating WTRU to generate a security key ID (e.g., K D-sessFor example, the MSB of the security key ID may be or may include a first security context ID generated by the initiating WTRU, and the LSB of the security key ID may be or may include a fourth security context ID generated by the WTRU. The WTRU may determine whether the secure direct communications link is established based on the security key ID (e.g., K D-sess A direct security mode complete message may be received that may indicate that a security mode has been established between the WTRU and the initiating WTRU using the direct security mode complete message. Effect of the Invention

[0009] A novel procedure can be provided that enables V2X unicast communication. [Brief description of the drawings]

[0010] [Figure 1A] FIG. 1 illustrates an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system of FIG. 1A, according to an embodiment. [Figure 1C] FIG. 1B illustrates an exemplary radio access network (RAN) and core network (CN) that may be used within the communications system of FIG. 1A, according to an embodiment. [Figure 1D] FIG. 1B illustrates a further exemplary RAN and CN that may be used within the communication system of FIG. 1A, according to an embodiment. [Diagram 2] FIG. 1 illustrates an exemplary security association establishment during a direct link connection setup. [Diagram 3] FIG. 1 illustrates an example WTRU-oriented Layer 2 link establishment. [Figure 4] FIG. 1 illustrates an example V2X service-oriented Layer 2 link establishment. [Figure 5A]FIG. 1 illustrates an example V2X service-oriented Layer 2 link establishment where the security context is based on the most significant bits of the KD-sess ID. [Figure 5B] FIG. 1 illustrates an example V2X service-oriented Layer 2 link establishment where the security context is based on the most significant bits of the KD-sess ID. [Figure 6A] FIG. 1 illustrates an example V2X service-oriented Layer 2 link establishment where the security context is based on the least significant bits of the KD-sess ID. [Figure 6B] FIG. 1 illustrates an example V2X service-oriented Layer 2 link establishment where the security context is based on the least significant bits of the KD-sess ID. [Figure 7A] FIG. 1 illustrates an exemplary V2X service-oriented link establishment where the security context is based on the complete KD-sess ID. [Figure 7B] FIG. 1 illustrates an exemplary V2X service-oriented link establishment where the security context is based on the complete KD-sess ID. [Figure 8] FIG. 1 illustrates an exemplary V2X service-oriented Layer 2 unicast link establishment using a list of V2X services. [Figure 9] 13 illustrates an example WTRU-directed Layer 2 link establishment for a list of WTRUs using higher layer information of the WTRU. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] As previously mentioned, embodiments may be implemented in a WTRU, a robotic vehicle, an automobile, IoT gear, any device that moves, or other communications device, which in turn may be used within a communications network. The following sections provide a description of some example WTRUs and / or other communications devices, and networks that may include them.

[0012] FIG. 1A 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 the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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-tailed Unique Word DFT Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, and Filter Bank Multi-Carrier (FBMC).

[0013] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 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 “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as UEs.

[0014] 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 any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B (HNB), a Home eNode B (HeNB), a gNB, a NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0015] The base station 114a may be part of the 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. The base station 114a and / or the 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 a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a particular geographic area, which may be relatively constant or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an embodiment, the base station 114a may utilize multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, e.g., beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0017] More specifically, as mentioned above, the communication system 100 may be a multiple access system and may utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. 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 establish the air interface 116 using Wideband CDMA (WCDMA). 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).

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

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

[0020] 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 LTE radio access and NR radio access together, e.g., using a dual connectivity (DC) principle. 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).

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

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

[0023] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, delay requirements, error resilience requirements, reliability requirements, data throughput requirements, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that utilize 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 communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0025] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may utilize a cellular-based wireless technology and with a base station 114b that may utilize an IEEE 802 wireless technology.

[0026] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 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 source 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the above elements while remaining consistent with an embodiment.

[0027] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction 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 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0029] 1B, the transmit / receive element 122 is depicted as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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.

[0030] 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 mentioned 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, for example, NR and IEEE 802.11.

[0031] 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. In addition, the processor 118 may obtain information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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 located on a server or home computer (not shown).

[0032] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components within 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0033] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or may 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.

[0034] The processor 118 may further be 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 e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, 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.

[0035] The processor 118 of the WTRU 102 may be in operative communication with various peripherals 138 including, for example, one or more accelerometers, one or more gyroscopes, a USB port, other communications interfaces / ports, a display and / or any of other visual / audible indicators, for implementing the representative embodiments disclosed herein.

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

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

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

[0039] Each of the eNodeBs 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. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0040] 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the above elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

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

[0042] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, as well as managing and storing the context of the WTRUs 102a, 102b, 102c.

[0043] The SGW 164 may be connected to a 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.

[0044] 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 landline communications devices. For example, the CN 106 may include or 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.

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

[0046] In an exemplary embodiment, the other network 112 may be a WLAN.

[0047] 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 or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs in the BSS may be sent through the AP, e.g., a source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs in the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using a direct link setup (DLS). In one representative embodiment, 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 (e.g., all of the STAs) in or using an IBSS may communicate directly with each other. IBSS mode communication is sometimes referred to herein as an "ad-hoc" mode of communication.

[0048] When using 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In one representative embodiment, for example, in an 802.11 system, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. Within a given BSS, one STA (e.g., only one station) may transmit at any given time.

[0049] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

[0051] Sub-1 GHz mode operation is supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. In accordance with a representative embodiment, 802.11ah can support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices can have limited functionality, including, for example, support of (e.g., only) a certain bandwidth and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0052] A WLAN system, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, that may support multiple channels and channel bandwidths, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA that supports a minimum bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, for a STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (that only supports a 1 MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy, even though most of the available frequency band may remain idle and available.

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

[0054] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 utilizing NR radio technology. The RAN 113 may also communicate with the CN 115.

[0055] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas, for example. In an embodiment, the gNBs 180a, 180b, 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 an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

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

[0057] 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., eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to a gNB 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act 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.

[0058] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, and routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c can communicate with each other over the Xn interface.

[0059] The CN 115 shown in Figure 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the above elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0060] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, and mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. Different network slices may be established for different use cases, such as, for example, services relying on ultra-reliable low latency communications (URLLC) access, services relying on high speed mobile (e.g., large capacity mobile) broadband (eMBB) access, and / or services for machine type communications (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.

[0061] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification. The PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0062] The UPFs 184a, 184b may connect 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 UPFs 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homing PDU sessions, handling user plane QoS, buffering downlink packets, as well as providing mobility anchoring.

[0063] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or 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 connect to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0064] In view of Figures 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

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

[0067] A system, method, and means for vehicle-to-everything (V2X) service-oriented link establishment is provided. The security context of a link established between two wireless transmit / receive units (WTRUs) over a PC5 reference point is determined by an identifier (e.g., K D-sessThe security context of a link established between two WTRUs over a PC5 reference point can be determined based on the complete identifier (e.g., K D-sess It can be identified based on the ID.

[0068] The first WTRU may generate a broadcast message including information about the V2X service. When the first WTRU transmits the broadcast message (e.g., to one or more WTRUs including the second WTRU), it may advertise the V2X service by, for example, including a V2V service indication. The first WTRU may receive a direct communication request message from the second WTRU. The direct communication request message may include a security key identifier, K D-sess It may contain a set of most significant bits (MSBs) of the ID.

[0069] The first WTRU may generate a set of least significant bits (LSBs) of a key identifier. The first WTRU may create a security context associated with the direct communication request message received from the second WTRU.

[0070] The first WTRU may send a direct security mode command message to the second WTRU. The direct security mode command message may include the LSB of the generated key identifier and / or the V2X service information.

[0071] The first WTRU may generate a broadcast message including information about the V2X service and a set of MSBs of a key identifier. The first WTRU may receive a direct security mode command message from the second WTRU. The direct security mode command message includes the key identifier, K D-sessThe first WTRU may generate a key identifier by combining the set of MSBs of the generated key identifier with the set of LSBs of the received key identifier.

[0072] The first WTRU may determine whether the combined key identifier is unique. If the combined key identifier is unique, the first WTRU may create a security context associated with the direct security mode command message received from the second WTRU. The security context may be identified based on the unique combined key identifier. The first WTRU may send a direct security mode complete message to the second WTRU.

[0073] If the key identifier is not unique, the first WTRU may send a direct security mode reject message to the second WTRU. The direct security mode reject message may include a cause value indicating that the set of LSBs of the key identifier is not unique. The first WTRU may then receive another set of LSBs of the key identifier from the second WTRU. The first WTRU may generate another security context using the other set of LSBs.

[0074] FIG. 2 illustrates an example of security association establishment during connection setup. Certain types of Proximity Services (ProSe) direct communication or WTRU-to-WTRU communication (e.g., vehicle-to-vehicle / vehicle-to-infrastructure (V2X) communication) can be established over the PC5 reference point. One-to-one ProSe direct communication can be implemented by establishing a secure Layer 2 link over the PC5 reference point between two WTRUs, for example, an initiating WTRU (e.g., WTRU-1) and a target WTRU (e.g., WTRU-2). The initiating WTRU, WTRU-1, can initiate the direct link setup by generating a DIRECT_COMMUNICATION_REQUEST message. The terms DIRECT_COMMUNICATION_REQUEST message and direct communication request message can be used interchangeably. Upon receiving the DIRECT_COMMUNICATION_REQUEST message, the initiating WTRU and the target WTRU can perform link authentication and establish a direct link security association. Upon completing link authentication and successfully establishing a direct link security association, the target WTRU may send a DIRECT_COMMUNICATION_ACCEPT message to the initiating WTRU. The terms DIRECT_COMMUNICATION_ACCEPT message and direct communication accept message may be used interchangeably. The initiating WTRU may use the established link for subsequent one-to-one communications with the target WTRU.

[0075] For example, in a ProSe direct one-to-one communication, multiple layers of keys (e.g., four different layers of keys) can be used. D Key, K D-sess The key may include a ProSe encryption key (PEK), a ProSe integrity key (PIK), and / or a ProSe encryption key (PEK). There may be a 256-bit root key. DKeys can be shared between two entities communicating using ProSe direct one-to-one communication. D Using ID, K D It is possible to identify D-sess The key may be a 256-bit root key. D-sess The key may be the root of the actual security context used to protect the data transfer between the two WTRUs. The keys used by the confidentiality and integrity algorithms (e.g., PEK and PIK) are D-sess The security context ID (e.g., the 16-bit K D-sess ID) to D-sess The PEK and PIK may be session keys that may be used by the confidentiality and integrity algorithms, respectively. The PEK and PIK may be used to protect ProSe direct one-to-one communication over the PC5 interface. The PEK and / or PIK may be a combination of K D-sess It can be derived from the key.

[0076] The target WTRU may initiate a direct security mode control procedure, for example, in response to receiving a DIRECT_COMMUNICATION_REQUEST message. D-sess The target WTRU may generate the LSBs of the ID from the initiating WTRU, for example, via a DIRECT_COMMUNICATION_REQUEST message. D-sess The target WTRU can receive the MSB of the ID. D-sess The LSB of ID is K D-sess It can be combined with the most significant bit (MSB) of the ID.

[0077] The target WTRU may generate a 128-bit Nonce_2 value. D, Nonce_1, and Nonce_2 are used to calculate K D-sess As illustrated in FIG. 2, the target WTRU may send a DIRECT_SECURITY_MODE_COMMAND message to the initiating WTRU. The target WTRU may derive Nonce_2 and K D-sess The least significant 8 bits of the ID may be included in a DIRECT_SECURITY_MODE_COMMAND message. The terms DIRECT_SECURITY_MODE_COMMAND message and direct security mode command message may be used interchangeably. The initiating WTRU may, for example, in response to receiving the DIRECT_SECURITY_MODE_COMMAND message, include D-sess , confidentiality keys, and / or integrity keys. D , Nonce_1, and Nonce_2 are used to calculate K D-sess As illustrated in FIG. 2, the initiating WTRU may send a DIRECT_SECURITY_MODE_COMPLETE message to the target WTRU. The terms DIRECT_SECURITY_MODE_COMPLETE message and direct security mode complete message may be used interchangeably. The initiating WTRU may calculate K D-sess The LSBs of the ID generated by the initiating WTRU are D-sess By combining with the MSB of ID, K D-sess An ID can be formed.

[0078] K D-sess (e.g., the root of the security association) may be generated by the initiating WTRU and / or the transmitting WTRU. D-sess A portion of the ID may be used (e.g., used locally) to identify the security context. For example, the initiating WTRU may D-sessK for link using the 8 MSBs of ID D-sess The target WTRU can be found by D-sess Using the 8 LSBs of the ID, it is possible to determine the K D-sess The security context consists of the following information elements: D-sess , PEK, PIK, remote UE user information, and / or K D may include one or more of:

[0079] The WTRU may be configured to perform service announcement and / or unicast link establishment procedures for V2X services. Discovery channels, as used in other ProSe contexts, may not be available for V2X contexts. For example, a service announcement mechanism may be used in V2X communication to inform peer WTRUs of the WTRU's presence. Capabilities of a WTRU (e.g., a V2X WTRU) may be conveyed via the service announcement mechanism. The capabilities of a WTRU may include, for example, services supported by the V2X WTRU. For example, a V2X WTRU may inform peer WTRUs about its capability to support unicast communication. Various mechanisms may be utilized for V2X (e.g., enhanced V2X (eV2X)) link establishment. The mechanisms may include WTRU-oriented Layer 2 link establishment and / or V2X service-oriented Layer 2 link establishment.

[0080] FIG. 3 illustrates an example Layer 2 link establishment mechanism that may be utilized for V2X. As illustrated in FIG. 3, in the Layer 2 link establishment mechanism, a DIRECT_COMMUNICATION_REQUEST message may be sent by a first WTRU (e.g., WTRU-1) via a broadcast mechanism, e.g., to a broadcast address associated with an application. For example, the first WTRU may broadcast the DIRECT_COMMUNICATION_REQUEST message. One or more WTRUs (e.g., WTRU-2, WTRU-3, and / or WTRU-4) may receive the DIRECT_COMMUNICATION_REQUEST message. The DIRECT_COMMUNICATION_REQUEST message may include an upper layer identifier of the second WTRU (e.g., WTRU-2). The upper layer identifier of the second WTRU in the DIRECT_COMMUNICATION_REQUEST message may be utilized to enable the second WTRU (e.g., WTRU-2) to determine whether to respond to the DIRECT_COMMUNICATION_REQUEST message received from the first WTRU (e.g., WTRU-1). The source L2 ID of the DIRECT_COMMUNICATION_REQUEST message may be the unicast L2 ID of the first WTRU (e.g., WTRU-1). The second WTRU (e.g., WTRU-2) may use the source L2 ID of the received DIRECT_COMMUNICATION_REQUEST message as the destination L2 ID for subsequent messages to the first WTRU (e.g., WTRU-1). The second WTRU (e.g., WTRU-2) may use its own unicast L2 ID as the source L2 ID for subsequent messages to the first WTRU (e.g., WTRU-1).A first WTRU (eg, WTRU-1) may acquire the L2 ID of a second WTRU (eg, WTRU-2) for future communications, eg, for signaling traffic and / or data traffic.

[0081] FIG. 4 illustrates an example V2X Layer 2 link establishment. As illustrated in FIG. 4, information about a V2X service requesting L2 link establishment, e.g., information about an advertised V2X service, may be included in a DIRECT_COMMUNICATION_REQUEST message. The information about the V2X service may enable other WTRUs (e.g., WTRU-2, WTRU-3, and / or WTRU-4) to decide whether to respond to the DIRECT_COMMUNICATION_REQUEST message. One or more WTRUs (e.g., WTRU-2 and WTRU-4, as illustrated in FIG. 4) that are interested in using the V2X service advertised by the DIRECT_COMMUNICATION_REQUEST message may respond to the request. The responding WTRUs (e.g., WTRU-2 and WTRU-4) may be interchangeably referred to as interested WTRUs, responding WTRUs, and / or peer WTRUs.

[0082] An initiating WTRU may broadcast a DIRECT_COMMUNICATION_REQUEST message. The broadcasted DIRECT_COMMUNICATION_REQUEST message may include information associated with the V2X service. One or more WTRUs may receive the broadcasted DIRECT_COMMUNICATION_REQUEST message including information about the V2X service. One or more WTRUs interested in using the V2X service may initiate direct security mode control. One or more interested WTRUs may send respective DIRECT_COMMUNICATION_ACCEPT messages to the initiating WTRU. The respective DIRECT_COMMUNICATION_ACCEPT messages may establish respective unicast links with the initiating WTRU (e.g., WTRU-1 in FIG. 4).

[0083] The interested WTRUs may respond to the broadcasted DIRECT_COMMUNICATION_REQUEST message. For example, each of the interested WTRUs may send a DIRECT_SECURITY_MODE_COMMAND message to the initiating WTRU. The DIRECT_SECURITY_MODE_COMMAND message may create a security association with the initiating WTRU. D-sess The MSBs of the ID may be used to locally identify a security association on the initiating WTRU (e.g., WTRU-1). The most significant 8 bits (MSBs) of each K D-sess The IDs may be the same. The initiating WTRU (e.g., WTRU-1) may associate each of the interested WTRUs with the same security context. D-sessThe ID (e.g., 8 MSBs from the initiating WTRU + 8 LSBs from the peer WTRU) may be unique for each one-to-one link between the initiating WTRU and the interested WTRU. D-sess Since an ID is referenced by multiple peer WTRUs, the security association for each of the links / sessions may or may not be unique.

[0084] 5A and 5B illustrate an example V2X service-oriented link establishment. As illustrated in FIG. 5A and 5B, each of the interested WTRUs replying to the DIRECT_COMMUNICATION_REQUEST message can point to the same security association as at the initiating WTRU.

[0085] 5A and 5B, an initiating WTRU (e.g., WTRU1) may receive a DIRECT_SECURITY_MODE_COMMAND message from a first interested WTRU (e.g., WTRU2). D-sess The initiating WTRU may create a security context entry identified by the ID. The initiating WTRU may combine the information received in the DIRECT_SECURITY_MODE_COMMAND message (e.g., Nonce 2, Chosen Algorithms) with other information, e.g., K D-sess , P.E.K., P.I.K., K. D-sessThe initiating WTRU may receive a second DIRECT_SECURITY_MODE_COMMAND message from a second interested WTRU (e.g., WTRU3). The initiating WTRU (e.g., WTRU1) may not update the security context with the value received from the second interested WTRU (e.g., WTRU3) because the key from the first interested WTRU (e.g., WTRU2) has already been saved in this same security context entry. The security procedures used by the first interested WTRU (e.g., WTRU2) and the second interested WTRU (e.g., WTRU3) may use the same MSB K value that each of the first interested WTRU and the second interested WTRU received from the initiating WTRU (e.g., WTRU1). D-sess Can be based on ID.

[0086] In an example, one or more keys from the second interested WTRU may be saved (e.g., overwriting the keys from the first interested WTRU (e.g., WTRU2). As a result, one or more keys corresponding to the first interested WTRU may be lost such that communication with the first interested WTRU may not be possible. The loss of one or more keys corresponding to the first interested WTRU may result in a security check failure in subsequent direct communication between the initiating WTRU (e.g., WTRU1) and the first interested WTRU (e.g., WTRU2).

[0087] In an example, one or more keys from a second interested WTRU (e.g., WTRU3) may not be saved by the initiating WTRU (e.g., WTRU1). The initiating WTRU (e.g., WTRU1) may not be able to establish a security association with the second interested WTRU (e.g., WTRU3). A link between the initiating WTRU and the second interested WTRU may not be established. It may not be possible for the initiating WTRU to simultaneously establish secure direct communication with multiple responding / interested WTRUs. One or more Nonce_2 values ​​may be generated in each of the first and second interested WTRUs. For example, the one or more Nonce_2 values ​​may be randomly generated in each of the two WTRUs. The one or more Nonce_2 values ​​may have different values.

[0088] Service-oriented and / or WTRU-oriented Layer 2 link establishment may be performed. Service-oriented Layer 2 unicast link establishment may be performed for a service, e.g., a V2X service in case of V2X communication, or another service in case of other types of communication, e.g., communication between drones.

[0089] 6A and 6B illustrate an example V2X service-oriented link establishment. As illustrated in FIG. 6A and 6B, each of the interested WTRUs (e.g., WTRU2 and WTRU3) may receive a DIRECT_COMMUNICATION_REQUEST message from the initiating WTRU (e.g., WTRU1). The DIRECT_COMMUNICATION_REQUEST message may include information about the V2X service. One or more of the interested WTRUs may determine that they are interested in the V2X service. One or more interested WTRUs interested in the V2X service may initiate a unicast link establishment with the initiating WTRU, for example, by sending a respective DIRECT_COMMUNICATION_REQUEST message to the initiating WTRU. Each of the interested WTRUs or peer WTRUs may initiate the unicast link establishment. The initiating WTRU may create respective different security contexts on the initiating WTRU based on the received DIRECT_COMMUNICATION_REQUEST messages from one or more interested WTRUs (e.g., WTRU2 and WTRU3). For each peer or interested WTRU, (e.g., K D-sess A different security context index (based on the LSB of the ID) may be created. A different security context may be created, for example, by the initiating WTRU each time a DIRECT_COMMUNICATION_REQUEST message is received from a peer or an interested WTRU.

[0090] As illustrated in Figures 6A and 6B, an interested WTRU or a peer WTRU (e.g., WTRU2) may be the initiator of the link establishment setup. The DIRECT_COMMUNICATION_REQUEST message sent by the initiating WTRU (e.g., WTRU1) may indicate the supported V2X services. One or more WTRUs that are interested in the indicated supported V2X services may initiate link establishment with the initiating WTRU. The initiating WTRU (e.g., WTRU1) may set K D-sess The MSB of the ID can be indicated. D-sess Setting the MSB of the ID to a dummy value or zero may indicate that the value is not associated with a security context on the initiating WTRU (e.g., WTRU1). In the example, the initiating WTRU (e.g., WTRU1) receives the K D-sess The MSB of the ID can be omitted.

[0091] In an example, the initiating WTRU (e.g., WTRU1) may indicate the supported V2X services in different types of messages (e.g., V2X_SERVICE_ANNOUNCEMENT, V2X_SERVICE_ADVERTISEMENT), e.g., to reflect the true capabilities of this initial message from the initiating WTRU (e.g., WTRU1). D-sess The MSB of the ID may be generated by the interested WTRU or the peer WTRU. For example, one or more WTRUs (e.g., WTRU2 and WTRU3) that are interested in the announced V2X service may generate K D-sess The initiating WTRU may generate a set of MSBs of the ID for each direct link communication request received. D-sess The initiating WTRU may generate a different set of LSBs of the ID. For each direct link communication request, the initiating WTRU may generate a different security context. Each security context may be D-sessThe initiating WTRU (e.g., WTRU1) may index using the LSB of the ID that it sent in the initial broadcast DIRECT_COMMUNICATION_REQUEST message (e.g., to announce the V2X service). D-sess The dummy MSB created at the beginning of the ID can be discarded.

[0092] 6A and 6B, an interested WTRU (e.g., WTRU2) may send a DIRECT_COMMUNICATION_REQUEST message to an initiating WTRU (e.g., WTRU1). The destination field of the DIRECT_COMMUNICATION_REQUEST message may be set to be the L2 ID of WTRU1, and the source field of the DIRECT_COMMUNICATION_REQUEST message may be set to be the L2 ID of WTRU2. Information associated with the V2X service (e.g., a service of interest to an interested WTRU, WTRU2) advertised by the initiating WTRU (e.g., WTRU1) on the initial DIRECT_COMMUNICATION_REQUEST message may be copied by the interested WTRU (e.g., WTRU2) onto the message sent to the initiating WTRU (e.g., WTRU1).

[0093] Another interested WTRU (e.g., WTRU3) may send a DIRECT_COMMUNICATION_REQUEST message to the initiating WTRU (e.g., WTRU1). The DIRECT_COMMUNICATION_REQUEST message from the other interested WTRU (e.g., WTRU3) may include a destination field set to be the WTRU1 L2 ID, and the source field of the DIRECT_COMMUNICATION_REQUEST message may be set to be the WTRU3 L2 ID. The advertised V2X service received by the initiating WTRU (e.g., WTRU1) may be included in the DIRECT_COMMUNICATION_REQUEST message sent by the other interested WTRU (e.g., WTRU3) to the initiating WTRU (e.g., WTRU1). Upon receiving the message from the interested WTRU (e.g., WTRU2 or WTRU3), the initiating WTRU may initiate mutual authentication with the interested WTRU (e.g., WTRU2 or WTRU3).

[0094] 7A and 7B illustrate an example V2X service-oriented link establishment. The security context is determined by a security context ID (e.g., the complete K D-sess 7A and 7B, an initiating WTRU (e.g., a first WTRU, WTRU1) may, for example, locate the WTRU based on a security context ID (e.g., K D-sess Instead of using the MSB of the security context ID (e.g., K D-sess The initiating WTRU (e.g., a first WTRU, WTRU1) may find the security context using the entire security context ID (e.g., K1, K2, K3, K4, K5, K6, K7, K8, K9, K10, K111, K112, K113, K114, K115, K120, K121, K122, K123, K124, K125, K126, K127, K128, K129, K23, K24, K25, K26, K27, K38, K39, K40, K41, K42, K43, K44, K45, K56, K57, K58, K60, K61, K72, K73, K74, K85, K96, K97, K108, K111, K125, K130, K131, K132, K133, K134, K135, K136, K137, K138, K139, K240, K251, K262, K273, K39, K40, K41, K57, K60, K74, K85, K97, K138, K140, K151, K162, K173, K184, K185, K186, K187, K188, K189, K290, K291, K292, K293, K394, K395, K406, K407, K408, K41, K42, K57, K609, K61, K71, K72, K73, K84, K98, K109, K111, D-sessThe entire security context ID may be a third security context ID. The resulting third security context ID (e.g., K D-sess The initiating WTRU may send a security mode complete message directly to the peer WTRU (eg, WTRU2).

[0095] As illustrated in FIG. 7A and FIG. 7B , a first WTRU (e.g., an initiating WTRU) may transmit a direct communication request message. The direct communication request message may be transmitted via broadcast. The direct communication request message may include a first security context ID. For example, the first WTRU may generate a first security context ID. The first security context ID may be associated with the first WTRU. The first security context ID may include a security key ID (e.g., K D-sess The direct communication request message may include a set of MSBs of a security mode command message (e.g., a set of MSBs of a security context ID ... D-sessThe direct security mode command message may include a first set of LSBs of a security context ID (Security Key ID). The direct security mode command message may indicate a V2X service from a list of supported V2X services. For example, the second WTRU may be interested in the V2X service. The first WTRU may determine a third security context ID, for example, by combining the first security context ID and the second security context ID. The third security context ID may include a set of MSBs and a set of LSBs of a security key ID. The first WTRU may establish a secure direct communications link with the second WTRU (e.g., using the third security context ID). The first WTRU may generate a security context entry for the secure direct communications link with the second WTRU based on the third security context ID. The second WTRU may receive a direct security mode completion message, which may indicate that a secure direct communications link associated with the third security context ID has been established between the first WTRU and the second WTRU.

[0096] The third WTRU may send a second direct security mode command message to the first WTRU. The first WTRU may receive the second direct security mode command message. The second direct security mode command message may include a fourth security context ID. The fourth security context ID may be associated with the third WTRU. The fourth security context ID may include a second set of LSBs of a security key ID. The first WTRU may determine whether the fourth security context ID is the same as the second security context ID. For example, the first WTRU may determine whether the first set of LSBs is the same as the second set of LSBs. When the fourth security context ID is the same as the second security context ID, the first WTRU may send a direct security mode reject message to the third WTRU. The direct security mode reject message may indicate that the second set of LSBs is not unique. The third WTRU may receive the direct security mode reject message. The third WTRU may determine that the fourth security context ID is not unique, e.g., based on receiving the direct security mode reject message. The third WTRU may generate a fifth security context ID, e.g., in response to receiving the direct security mode reject message. The fifth security context ID may be associated with the third WTRU. The fifth security context ID may include a third set of LSBs of the security key ID. The third WTRU may send a third direct security mode command message to the first WTRU. For example, the first WTRU may receive a third direct security mode command message from the third WTRU in response to the direct security mode reject message. The third direct security mode command message may include the fifth security context ID.

[0097] As illustrated in FIGS. 7A and 7B, a peer WTRU (e.g., WTRU4) may receive a peer WTRU K that is already being used by another peer WTRU (e.g., WTRU3). D-sess In such a case, the set of LSBs of the formed K D-sess The ID (e.g., the set of MSBs combined with the set of LSBs) may already be present on the initiating WTRU. D-sess When the ID already exists in the initiating WTRU, the initiating WTRU may reject the direct security mode command message, for example, by sending a direct security mode reject message to the peer WTRU (e.g., WTRU4). D-sess The LSB of the ID is not unique (for example, D-sess When a peer WTRU (e.g., WTRU4) receives such a rejection message, the cause value in the rejection message may include a cause value indicating a collision of the LSB of the K D-sess A peer WTRU (e.g., WTRU4) may determine whether a collision of the LSBs of the IDs occurs. D-sess A peer WTRU (e.g., WTRU4) may generate another set of LSBs of the ID. D-sess The security context entry (e.g., information saved from the direct communication request message received from the initiating WTRU, derived K D-sess key, PEK, PIK, etc.) D-sess The peer WTRU (e.g., WTRU4) may copy the generated security context associated with it to another security context created with another set of LSBs of the ID. D-sess The peer WTRU (e.g., WTRU4) may forget and / or discard the set of rejected LSBs of the ID. D-sess The peer WTRU may then transmit another (e.g., a new) Direct Security Mode Command message indicating another (e.g., a newly generated) set of LSBs of the ID. D-sessAnother set of the LSBs of the ID can be saved (eg saved locally).

[0098] K D-sess MSB and K of ID D-sess The LSB of ID and K formed using D-sess The ID may be unique for each peer WTRU (e.g., an interested WTRU). D-sess The ID value may be used to store and / or find a security context associated with a peer WTRU. A peer WTRU (e.g., a single peer WTRU) may store and / or find a security context (e.g., K D-sess Even if the same MSB of the ID is used, it can be related (e.g., K D-sess For each security context, K D-sess Different LSBs of ID, different K D-sess For multiple unicast communications (e.g., with multiple interested WTRUs), different K IDs can be used. D-sess You can use ID.

[0099] The WTRU may be configured to perform a V2X service-oriented Layer 2 unicast link establishment. A list of V2X services (e.g., instead of one V2X service) may be specified via a broadcast DIRECT_COMMUNICATION_REQUEST message. For example, the broadcast DIRECT_COMMUNICATION_REQUEST message may indicate a list of V2X services. The list of services in the DIRECT_COMMUNICATION_REQUEST message (e.g., instead of one V2X service per message) may reduce the number of messages that may be sent by the initiating WTRU, thereby reducing the number of messages that may otherwise be processed by the receiving WTRU.

[0100] FIG. 8 illustrates an example V2X service-oriented Layer 2 unicast link establishment using a list of V2X services. As illustrated in FIG. 8, a direct communication request broadcast message from an initiating WTRU (e.g., WTRU1) may include information associated with a list of V2X services (e.g., instead of information associated with one V2X service). An initiating WTRU sending a list of services in a direct communication request broadcast message may reduce the number of messages sent by the initiating WTRU. An initiating WTRU sending a list of services in a direct communication request broadcast message may reduce the number of messages processed by a receiving WTRU. For example, if a WTRU supports five V2X services, the initiating WTRU may advertise all five V2X services using one message (e.g., instead of five messages). Because the advertisement messages may be repeated periodically, utilizing one message to advertise all five V2X services may result in saving a significant amount of messages (e.g., sent by the initiating WTRU and / or processed by the receiving WTRU) over a period of time.

[0101] An initiating WTRU sending a list of services in a direct communication request broadcast message can reduce the time required to connect a WTRU for one or more (e.g., all) V2X services in the list of services. For example, a WTRU receiving a message advertising support for multiple services (e.g., five services) can trigger (e.g., immediately trigger) link establishment for the V2X services of interest (e.g., if three V2X services are of interest to the receiving WTRU, three links can be set up simultaneously). For example, the WTRU can trigger link establishment without having to wait for receipt of additional messages advertising support for additional V2X services.

[0102] As illustrated in FIG. 8, an initiating WTRU (e.g., WTRU1) may broadcast a DIRECT_COMMUNICATION_REQUEST message including a list of supported V2X services. The list of supported V2X services may include multiple V2X service IDs. Each V2X service ID may be paired with user information (e.g., WTRU1 user information value). User information may be provided for each V2X service and / or for each V2X application. As illustrated in FIG. 8, multiple receiving WTRUs (e.g., WTRU2, WTRU3, and / or WTRU4) may receive the broadcast DIRECT_COMMUNICATION_REQUEST message from the initiating WTRU (e.g., WTRU1). Each of the receiving WTRUs may process and decode multiple V2X services. The receiving WTRU (e.g., WTRU2) may be interested in one V2X service. The receiving WTRU (e.g., WTRU2) may initiate unicast communication for the V2X services of interest, for example, as described herein. The receiving WTRU (e.g., WTRU2) may send a DIRECT_COMMUNICATION_REQUEST message with the source ID as the Layer 2 ID of the receiving WTRU (e.g., WTRU2 L2 ID) and the destination ID as the Layer 2 ID of the initiating WTRU (e.g., WTRU1 L2 ID). The receiving WTRU (e.g., WTRU2) may specify the services of interest in the DIRECT_COMMUNICATION_REQUEST message.

[0103] As illustrated in FIG. 8, a receiving WTRU (e.g., WTRU4) may receive a broadcast DIRECT_COMMUNICATION_REQUEST message from an initiating WTRU (e.g., WTRU1) advertising a list of services. The receiving WTRU (e.g., WTRU4) may be interested in multiple V2X services from the list of services it received from the initiating WTRU. The receiving WTRU (e.g., WTRU4) may initiate unicast communication for the first V2X service of interest as described herein. The receiving WTRU (e.g., WTRU4) may send an initial DIRECT_COMMUNICATION_REQUEST message with a source ID as the receiving WTRU's Layer 2 ID (e.g., WTRU4 L2 ID) and a destination ID as the initiating WTRU's Layer 2 ID (e.g., WTRU1 L2 ID). The receiving WTRU may include the V2X services of interest in its DIRECT_COMMUNICATION_REQUEST message. The Layer 2 ID of the initiating WTRU (e.g., WTRU1 L2 ID) may use a per-service value (e.g., a unique value). A new source Layer 2 ID may be added by the initiating WTRU during link establishment and / or when sending a direct communication accept message (not shown in the figure). An information element (IE) may be used to update the Layer 2 ID. The peer WTRU may update its peer L2 ID with the value received via the IE. The peer WTRU may use the updated L2 ID for one or more subsequent communications. The receiving WTRU (e.g., WTRU4) may initiate unicast communication for each of the V2X services of interest as described herein. The initiation of unicast communication for each of the V2X services may be simultaneous.

[0104] FIG. 9 illustrates an example WTRU-directed Layer 2 link establishment for a list of WTRUs, e.g., using the WTRUs' upper layer information. As illustrated in FIG. 9, a direct communication request broadcast message from an initiating WTRU (e.g., WTRU1) may include upper layer information associated with each of the WTRUs. Sending one broadcast message including a list of the WTRUs' upper layer IDs may reduce the number of messages that may be sent by the initiating WTRU. For example, the initiating WTRU may send one direct communication request broadcast message (e.g., instead of sending a single message to each of the multiple receiving WTRUs) to multiple receiving WTRUs with which the initiating WTRU may want to establish a link.

[0105] Upon receiving the direct communication request broadcast message, which has a list of upper layer IDs of the WTRU, the receiving WTRU may determine whether its upper layer ID is in the list. The receiving WTRU may process and decode the received direct communication request broadcast message. If the receiving WTRU determines that its upper layer ID is in the direct communication request broadcast message's list of upper layer IDs of the WTRU, the receiving WTRU may trigger (e.g., immediately trigger) a Layer 2 link establishment with the initiating WTRU. The receiving WTRU may establish a Layer 2 link, for example, without waiting to receive additional messages from the initiating WTRU.

[0106] As illustrated in FIG. 9, an initiating WTRU (e.g., WTRU-1) may broadcast a DIRECT_COMMUNICATION_REQUEST message with destination upper layer IDs of WTRUs it may wish to reach. Each of the receiving WTRUs (e.g., WTRU-2, WTRU-3, and WTRU-4) may receive the DIRECT_COMMUNICATION_REQUEST message. Each of the receiving WTRUs (e.g., WTRU-2, WTRU-3, and WTRU-4) may process and decode the DIRECT_COMMUNICATION_REQUEST message, and the WTRUs specified in the DIRECT_COMMUNICATION_REQUEST message may respond. For example, if an initiating WTRU (e.g., WTRU-1) wishes to establish links with multiple WTRUs, the initiating WTRU may send the DIRECT_COMMUNICATION_REQUEST message multiple times (e.g., each time including the upper layer IDs of the respective WTRUs).

[0107] 9, an initiating WTRU (e.g., WTRU1) may broadcast a single DIRECT_COMMUNICATION_REQUEST message with upper layer IDs of WTRUs that the initiating WTRU may want to reach to multiple receiving WTRUs (e.g., WTRU2, WTRU3, and WTRU4). Each of the receiving WTRUs (e.g., WTRU2, WTRU3, and WTRU4) may process and decode the received single broadcast DIRECT_COMMUNICATION_REQUEST message.

[0108] 9, a receiving WTRU (e.g., WTRU2 or WTRU4) may establish a Layer 2 link by sending a response to the DIRECT_COMMUNICATION_REQUEST message received from the initiating WTRU (e.g., WTRU1). The receiving WTRU (e.g., WTRU2 or WTRU4) may either send a direct communication accept message (e.g., option A) or its own DIRECT_COMMUNICATION_REQUEST message (e.g., option B) as described herein.

[0109] As illustrated in FIG. 9, an initiating WTRU (e.g., WTRU1) may broadcast a DIRECT_COMMUNICATION_REQUEST message with a list of destination upper layer IDs. Multiple receiving WTRUs (e.g., WTRU2, WTRU3, and WTRU4) may receive the message. Multiple WTRUs (e.g., WTRU2, WTRU3, and WTRU4) may process and decode the multiple upper layer IDs. If a receiving WTRU (e.g., WTRU2 or WTRU4) determines that the list of destination upper layer IDs includes its own upper layer ID, the receiving WTRU may proceed with link establishment. Using Option A, the receiving WTRU (e.g., WTRU2 or WTRU4) may send a DIRECT_COMMUNICATION_ACCEPT message to the initiating WTRU (e.g., WTRU1) in response to the received message, for example, after link authentication and security association. Using Option A, a DIRECT_COMMUNICATION_ACCEPT message may be sent ... D-sessThe entire ID may be used to find the security context locally. With Option B, not each of the replying WTRUs may reply to the initiating WTRU's (e.g., WTRU1's) DIRECT_COMMUNICATION_REQUEST message. One or more of the replying WTRUs may initiate link establishment, for example, by sending their own DIRECT_COMMUNICATION_REQUEST messages. [Industrial Applicability]

[0110] The present invention can be used in wireless communication. [Explanation of symbols]

[0111] 100 Communication Systems 102 WTRU 104 RAN 106 Core Network 108 PSTN 110 Internet 114a, 114b base station 116 WTRU

Claims

1. A first wireless transmit / receive unit (first WTRU) for establishing a communications link, comprising: transmitting a first message to a second WTRU, the first message indicating a request to communicate with the second WTRU; receiving a second message from the second WTRU, the second message indicating a first set of least significant bits (LSBs) associated with the second WTRU; determining that a collision exists between the first set of LSBs associated with the second WTRU and a second set of LSBs associated with a third WTRU; transmit a third message to one of the second WTRU or the third WTRU indicating the collision between the first set of LSBs and the second set of LSBs. Processor configured to A first WTRU comprising:

2. The first WTRU of claim 1 , wherein the first message includes a list of supported vehicle-to-everything (V2X) services.

3. The method of claim 2, wherein the third message is sent to the second WTRU; The first WTRU of claim 1, wherein the processor is configured to receive a fourth message from the second WTRU, the fourth message indicating a third set of LSBs associated with the second WTRU, the third set of LSBs being different from the second set of LSBs.

4. The processor, determining that the third set of LSBs does not cause a collision; determining a security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; The first WTRU of claim 3 , further configured to transmit the fourth message to the second WTRU using a secure communications link associated with the security key identifier.

5. The method of claim 1, further comprising: sending the third message to the third WTRU; 2. The first WTRU of claim 1, wherein the processor is further configured to receive a fourth message from the third WTRU, the fourth message indicating a third set of LSBs associated with the third WTRU.

6. The processor, determining that the third set of LSBs does not cause a collision; determining a security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; 6. The first WTRU of claim 5, further configured to transmit a sixth message to the third WTRU using a second secure communications link, the second secure communications link being associated with a second security key identifier.

7. 1. A method for establishing a communication link, the method comprising: transmitting a first message to a second WTRU, the first message indicating a request to communicate with the second WTRU; receiving a second message from the second WTRU, the second message indicating a first set of least significant bits (LSBs) associated with the second WTRU; determining that a collision exists between the first set of LSBs associated with the second WTRU and a second set of LSBs associated with a third WTRU; sending a third message to one of the second WTRU or the third WTRU indicating the collision between the first set of LSBs and the second set of LSBs; A method for providing the above.

8. 8. The method of claim 7, wherein the first message includes a list of supported vehicle-to-everything (V2X) services.

9. The method of claim 8, further comprising: sending the third message to the second WTRU; receiving a fourth message from the second WTRU, the fourth message indicating a third set of LSBs associated with the second WTRU, the third set of LSBs being different than the second set of LSBs; The method of claim 7 further comprising: determining that the third set of LSBs does not cause a collision; determining a security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; sending a fifth message to the second WTRU using a secure communications link associated with the security key identifier; The method of claim 9 further comprising:

11. transmitting the third message to the third WTRU, the third message indicating the collision between the first set of LSBs and the second set of LSBs; receiving a fourth message from the third WTRU, the fourth message indicating a third set of LSBs associated with the third WTRU; The method of claim 7 further comprising:

12. The method of claim 11, further comprising: determining that the third set of LSBs does not cause a collision; and determining a security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; sending a fifth message to the third WTRU using a secure communications link, the secure communications link being associated with the security key identifier; The method of claim 11 further comprising:

13. A first wireless transmit / receive unit (first WTRU) for establishing a communication link, transmitting a first message to a second WTRU, the first message indicating a request to communicate with the second WTRU; receiving a second message from the second WTRU, the second message indicating a first set of least significant bits (LSBs) associated with the second WTRU; determining whether a collision exists between the first set of LSBs associated with the second WTRU and a second set of LSBs associated with a third WTRU; if a collision is determined to exist, transmitting a third message indicating the collision between the first set of LSBs and the second set of LSBs; If it is determined that no collision exists, generating a security key identifier using a set of most significant bits (MSBs) and the first set of LSBs, the set of MSBs being associated with the first WTRU and the first set of LSBs being associated with the second WTRU; Send a fourth message to the second WTRU using a secure communications link associated with the security key identifier. Processor configured to A first WTRU comprising:

14. The first WTRU of claim 13, wherein the first message includes a list of supported vehicle-to-everything (V2X) services.

15. 14. The first WTRU of claim 13, wherein if a collision is determined to exist, the processor is further configured to transmit the third message to the third WTRU, the third message indicating the collision.

16. The first WTRU of claim 15, wherein the processor is further configured to receive a fifth message from the third WTRU, the fifth message indicating a third set of LSBs associated with the third WTRU.

17. The processor, determining that the third set of LSBs does not cause a collision; determining a second security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; 17. The first WTRU of claim 16, further configured to transmit a sixth message to the third WTRU using a second secure communications link, the second secure communications link being associated with the second security key identifier.

18. 14. The first WTRU of claim 13, wherein if a collision is determined to exist, the processor is further configured to transmit the third message to the second WTRU, the third message indicating the collision.

19. The first WTRU of claim 18, wherein the processor is further configured to receive a fifth message from the second WTRU, the fifth message indicating a third set of LSBs associated with the second WTRU.

20. The processor, determining that the third set of LSBs does not cause a collision; determining a second security key identifier using a set of most significant bits (MSBs) associated with the first WTRU and the third set of LSBs; 20. The first WTRU of claim 19, further configured to transmit a sixth message to the second WTRU using a second secure communications link, the second secure communications link being associated with the second security key identifier.

Images