阅读说明：本技术 通过PC5接口实现V2x单播通信的过程 (Procedure for implementing V2x unicast communication through PC5 interface ) 是由 米歇尔·佩拉斯 萨阿德·艾哈迈德 萨米尔·费尔迪 哈立德·安瓦尔 于 2020-01-20 设计创作，主要内容包括：提供了用于面向车辆到所有事物(V2X)服务的链路建立的系统、方法和手段。第一无线发射接收单元(WTRU)可以广播直接通信请求消息。该直接通信请求消息可以包括第一安全上下文标识符(ID)。所述第一WTRU可以从第二WTRU接收直接安全模式命令消息。所述直接安全模式命令消息可以包括第二安全上下文ID。所述第一WTRU可以通过组合所述第一安全上下文ID和所述第二安全上下文ID来确定第三安全上下文ID。所述第一WTRU可以使用所述第三安全上下文ID建立与所述第二WTRU的安全直接通信链路。所述第一WTRU可以基于所述第三安全上下文ID,生成用于与所述第二WTRU的所述安全直接通信链路的安全上下文条目。(Systems, methods, and instrumentalities are provided for vehicle-to-everything (V2X) service oriented link establishment. A first Wireless Transmit Receive Unit (WTRU) may broadcast a direct communication request message. The direct communication request message may include a first security context Identifier (ID). The first WTRU may receive a direct security mode command message from a second WTRU. The direct security mode command message may include a second security context 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 first WTRU may establish a secure direct communication link with the second WTRU using the third security context ID. 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.)

1. A first wireless transmit/receive unit (WTRU), comprising:

a processor configured to:

sending a direct communication request message including a first security context Identifier (ID) associated with the first WTRU;

receiving a direct security mode command message from a second WTRU, the direct security mode command message including a second security context ID associated with the second WTRU;

determining a third security context ID by combining the first security context ID and the second security context ID; and

establishing a secure direct communication link with the second WTRU using the third security context ID.

2. The WTRU of claim 1, wherein the first security context ID associated with the first WTRU includes a set of Most Significant Bits (MSBs) of a security key ID, and wherein the second security context ID associated with the second WTRU includes a set of Least Significant Bits (LSBs) of the security key ID.

3. The WTRU of claim 2, wherein the third security context ID includes the set of MSBs and the set of LSBs of the security key ID.

4. The WTRU of claim 1, wherein the direct security mode command message is a first direct security mode command message, the processor further configured to:

receiving a second direct security mode command message from a third WTRU, the second direct security mode command message including a fourth security context ID associated with the third WTRU;

determining whether the fourth security context ID is the same as the second security context ID; and

sending a direct security mode reject message to the third WTRU on a condition that the fourth security context ID is the same as the second security context ID.

5. The WTRU of claim 4, wherein the fourth security context ID associated with the third WTRU includes a set of Least Significant Bits (LSBs) of a security key ID.

6. The WTRU of claim 4, wherein the processor is further configured to 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 including a fifth security context ID associated with the third WTRU.

7. The WTRU of claim 6, wherein the fifth security context ID associated with the third WTRU includes a set of Least Significant Bits (LSBs) of a security key ID.

8. The WTRU of claim 1, wherein the processor is further configured to generate a security context entry for the secure direct communication link with the second WTRU based on the third security context ID.

9. The WTRU of claim 1, wherein the direct communication request message includes a list of supported vehicle-to-everything (V2X) services.

10. The WTRU of claim 9, wherein the direct security mode command message from the second WTRU indicates a V2X service from the list of supported V2X services.

11. A method, comprising:

broadcasting a direct communication request message including a first security context Identifier (ID) associated with the first WTRU;

receiving a direct security mode command message from a second WTRU, the direct security mode command message including a second security context ID associated with the second WTRU;

determining a third security context ID by combining the first security context ID and the second security context ID; and

establishing a secure direct communication link with the second WTRU using the third security context ID.

12. The method of claim 11, wherein the first security context ID associated with the first WTRU comprises a set of most significant bits, MSBs, of a security key ID, and wherein the second security context ID associated with the second WTRU comprises a set of least significant bits, LSBs, of the security key ID.

13. The method of claim 12, wherein the third security context ID includes the set of MSBs and the set of LSBs of the security key ID.

14. The method of claim 11, wherein the direct security mode command message is a first direct security mode command message, the method further comprising:

receiving a second direct security mode command message from a third WTRU, the second direct security mode command message including a fourth security context ID associated with the third WTRU;

determining whether the fourth security context ID is the same as the second security context ID; and

sending a direct security mode reject message to the third WTRU on a condition that the fourth security context ID is the same as the second security context ID.

15. The method of claim 14, wherein the fourth security context ID associated with the third WTRU comprises a set of Least Significant Bits (LSBs) of a security key ID.

16. The method of claim 14 further comprising receiving 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 including a fifth security context ID associated with the third WTRU.

17. The method of claim 16, wherein the fifth security context ID associated with the third WTRU comprises a set of Least Significant Bits (LSBs) of a security key ID.

18. The method of claim 11, further comprising generating a security context entry for the secure direct communication link with the second WTRU based on the third security context ID.

19. The method of claim 11, wherein the direct communication request message comprises a list of supported vehicle-to-everything (V2X) services.

20. The method of claim 19 wherein the direct security mode command message from the second WTRU indicates V2X services from the list of supported V2X services.

Background

ProSe direct communication may be used to establish a communication path between two or more proximity services (ProSe) enabled wireless devices. For example, ProSe direct communication between two wireless devices may be established by establishing a layer 2 link between the two wireless devices over a PC5 reference point. The layer 2 link may be secure.

Disclosure of Invention

A first Wireless Transmit Receive Unit (WTRU) may send (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 K_D-sessAnd (4) ID. The first WTRU may receive direct data from a second WTRUA secure mode command message. 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 the set of MSBs and the set of LSBs of the security key ID. The first WTRU may establish a secure direct communication link with the second WTRU using the third security context ID. 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.

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. The first WTRU may send a direct security mode reject message to the third WTRU on a condition that the fourth security context ID is the same as the second security context ID. 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 a security key ID.

The WTRU may initiate a WT fromThe RU receives a direct communication request message, which may include, for example, a 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 a second security context ID. The WTRU may receive a direct security mode complete message that 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-sessID) and a set of LSBs. The set of MSBs of the security key ID may be or may include the first security context ID generated by the initiating WTRU, and the set of LSBs of the security key ID may be or may include the second security context ID generated by the WTRU.

The WTRU may receive a direct security mode reject message, which may indicate a collision of the second security context ID (e.g., the LSB of the 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, which may include the fourth security context ID, to the initiating WTRU. The fourth security context ID associated with the WTRU may be combined with the first security context ID generated by the initiating WTRU to form a security key ID (e.g., K)_D-sessID). For example, the MSB of the security key ID may be or may include the first security context ID generated by the initiating WTRU, and the LSB of the security key ID may be or may include the fourth security context ID generated by the WTRU. The WTRU may receive a direct security mode complete message, which may indicate that the security key ID (e.g., K) has been used_D-sessID) establishes a secure direct communication link between the WTRU and the initiating WTRU.

Drawings

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment;

figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 2 illustrates an exemplary security association establishment during a direct link connection establishment.

Figure 3 illustrates an exemplary WTRU-oriented layer 2 link establishment.

Fig. 4 illustrates an exemplary layer 2 link setup for V2X-oriented services.

FIGS. 5A and 5B illustrate exemplary layer 2 link establishment for V2X-oriented services, e.g., where the security context is based on K_D-sessThe most significant bits of the ID.

FIGS. 6A and 6B illustrate exemplary layer 2 link establishment for V2X-oriented services, e.g., where the security context is based on K_D-sessThe least significant bit of the ID.

FIGS. 7A and 7B illustrate exemplary V2X service oriented link establishment, e.g., where the security context is based on a complete K_D-sessID。

Fig. 8 illustrates an exemplary V2X service oriented layer 2 unicast link establishment utilizing a list of V2X services.

Figure 9 is an exemplary WTRU-oriented layer 2 link setup for a WTRU list using upper layer information as the WTRU.

Detailed Description

Fig. 1A is a diagram illustrating an exemplary 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 a plurality of wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use 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), among others.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be appreciated that any number of WTRUs, base stations, networks, and/or network components are contemplated by the disclosed embodiments. The WTRUs 102a, 102b, 102c, 102d may each be any type of device configured to operate and/or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a "station" and/or a "STA," which may be configured to transmit and/or receive wireless signals, and may include a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an internet of things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., tele-surgery), an industrial device and application (e.g., a robot and/or other wireless device operating in an industrial and/or automated processing chain environment), a consumer electronics device, a wireless transceiver, and/or a wireless transceiver, And devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

The communication system 100 may also include a base station 114a and/or a base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106/115, the internet 110, and/or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102 d. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home enodebs, gnbs, NR node bs, site controllers, Access Points (APs), and wireless routers, among others. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network components.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and/or network components (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, known as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area that is relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of a cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, using beamforming, signals may be transmitted and/or received in desired spatial directions.

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, millimeter-wave, Infrared (IR), Ultraviolet (UV), visible, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple-access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104/113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 115/116/117 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).

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-Pro (LTE-a Pro).

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

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 collectively implement LTE radio access and NR radio access (e.g., using Dual Connectivity (DC) principles). As such, the air interface used 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., eNB and gNB).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless high fidelity (WiFi)), IEEE 802.16 (worldwide interoperability for microwave Access (WiMAX)), CDMA2000, CDMA 20001X, 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), and GSM EDGE (GERAN), among others.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may facilitate wireless connectivity in a local area using any suitable RAT, such as a business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), and a road, among others. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Local Area Network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, base station 114b need not access the internet 110 via CN 106/115.

The RAN 104/113 may communicate with a 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, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, among others. CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104/113 and/or CN 106/115 may communicate directly or indirectly 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 using NR radio technology, the CN 106/115 may communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN 106/115 may also act 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 system of globally interconnected computer network devices that utilize common communication protocols, such as transmission control protocol/internet protocol (TCP), User Datagram Protocol (UDP), and/or IP in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104/113 or a different RAT.

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 that communicate with different wireless networks over different wireless links). For example, the WTRU102 c shown in fig. 1A may be configured to communicate with a base station 114a using a cellular-based radio technology and with a base station 114b, which may use an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive component 122, a speaker/microphone 124, a keypad 126, a display/touch pad 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 should be appreciated that the WTRU102 may include any subcombination of the foregoing components while maintaining consistent embodiments.

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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive component 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic component or chip.

The transmit/receive component 122 may 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 component 122 may be an antenna configured to transmit and/or receive RF signals. As an example, in another embodiment, the transmit/receive component 122 may be an emitter/detector configured to emit and/or receive IR, UV or visible light signals. In yet another embodiment, the transmit/receive component 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Although transmit/receive component 122 is depicted in fig. 1B as a single component, WTRU102 may include any number of transmit/receive components 122. More specifically, the WTRU102 may use MIMO technology. Thus, in one embodiment, the WTRU102 may include two or more transmit/receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as 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. Further, processor 118 may access information from and store information in any suitable 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 so forth. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located in the WTRU102, such memory may be located, for example, in a server or a home computer (not shown).

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

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) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU102 may acquire location information via any suitable positioning method while maintaining consistent embodiments.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and/or video), general purpose cameras, and the likeSerial Bus (USB) port, vibration device, television transceiver, hands-free headset,Modules, Frequency Modulation (FM) radio units, digital music players, media players, video game modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, and activity trackers, among others. The peripheral device 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 geographic position sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor, among others.

The WTRU102 may include a full duplex radio for which reception or transmission of some or all signals (e.g., associated with particular subframes for UL (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 that reduces and/or substantially eliminates self-interference via signal processing by hardware (e.g., a choke coil) or by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

RAN 104 may include enodebs 160a, 160B, 160c, however, it should be appreciated that RAN 104 may include any number of enodebs while maintaining consistent embodiments. The enodebs 160a, 160B, 160c may each include one or more transceivers that communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enodebs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU102a and/or to receive wireless signals from the WTRU102 a.

The enodebs 160a, 160B, 160c may each 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, and so forth. As shown in FIG. 1C, eNode Bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C 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 components are described as being part of the CN 106, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

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, performing bearer activation/deactivation processes, and selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, among other things. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies (e.g., GSM and/or WCDMA).

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, 102 c. The SGW 164 may also perform other functions such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

The SGW 164 may be connected to a PGW 146, which may provide packet-switched network (e.g., internet 110) access for the WTRUs 102a, 102b, 102c to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may serve 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 the other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some exemplary embodiments, such a terminal may use a (e.g., temporary or permanent) wired communication interface with a communication network.

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

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 access another type of wired/wireless network that is either interfaced to a Distribution System (DS) or that carries traffic into and/or out of the BSS. Traffic originating outside the BSS and destined for the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs that are inside the BSS may be transmitted through the AP, for example, in the case where the source STA may transmit 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 point-to-point traffic. The point-to-point traffic may be transmitted between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In some exemplary embodiments, DLS may use 802.11e DLS or 802.11z channelized DLS (tdls)). For example, a WLAN using an Independent Bss (IBSS) mode has no AP, and STAs (e.g., 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.

When using the 802.11ac infrastructure mode of operation or similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., 20MHz bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some exemplary embodiments, implemented may be carrier sense multiple access with collision avoidance (CSMA/CA) (e.g., in 802.11 systems). For CSMA/CA, STAs (e.g., each STA) including the AP may sense the primary channel. A particular STA may back off if it senses/detects and/or determines that the primary channel is busy. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

High Throughput (HT) STAs may communicate using 40MHz wide channels (e.g., 40MHz wide channels formed by combining a20 MHz wide primary channel with 20MHz wide adjacent or non-adjacent channels).

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels or by combining two discontinuous 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may be passed through a fragment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped on two 80MHz channels and data may be transmitted by STAs performing the transmissions. At the receiver of the STA performing the reception, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to a Medium Access Control (MAC).

802.11af and 802.11ah support operating modes below 1 GHz. The use of channel operating bandwidths and carriers in 802.11af and 802.11ah is reduced compared to 802.11n and 802.11 ac. 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. In accordance with an exemplary embodiment, the 802.11ah may support meter type control/machine type communication (e.g., MTC devices in a macro coverage area). MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., supporting only) certain and/or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a threshold (e.g., to maintain a long battery life).

For WLAN systems (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths, these systems contain channels that can be designated as primary channels. The bandwidth of the primary channel may be 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 is sourced from all STAs operating in the BSS supporting the minimum bandwidth operating mode. In an example for 802.11ah, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes, the width of the primary channel may be 1MHz for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy (e.g., because STAs (which support only 1MHz mode of operation) transmit to the AP), the entire available band may be considered busy even though most of the available band remains free and available for use.

In the united states, the available frequency band available for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, in accordance with the country code.

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

RAN 113 may include gnbs 180a, 180b, 180c, but it should be appreciated that RAN 113 may include any number of gnbs while maintaining consistent embodiments. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 180b may use beamforming processing to transmit and/or receive signals to and/or from the gnbs 180a, 180b, 180 c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU102a and to receive wireless signals from the WTRU102 a. 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 WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive a cooperative transmission from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may be different 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) having different or scalable lengths (e.g., including different numbers of OFDM symbols and/or lasting different absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. 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, 160 c). 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 frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gnbs 180a, 180B, 180c while communicating/connecting with other RANs (e.g., enodebs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c in a substantially simultaneous manner by implementing DC principles. 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 to serve the WTRUs 102a, 102B, 102 c.

The gnbs 180a, 180b, 180c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support network slicing, dual connectivity, implement interworking processing between NR and E-UTRA, route user plane data to User Plane Functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, among other things. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in fig. 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, 185 b. While each of the foregoing components are depicted as being part of the CN 115, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

The AMFs 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 control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, among others. The AMFs 182a, 182b may use network slicing processing to customize the CN support provided for the WTRUs 102a, 102b, 102c based on the type of service the WTRUs 102a, 102b, 102c are using. As an example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, and/or services for Machine Type Communication (MTC) access, among others. The AMF 182 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (e.g., LTE-A, LTE-a Pro, and/or non-3 GPP access technologies such as WiFi).

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 UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b, and may configure traffic routing through the UPFs 184a, 184 b. SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, among others. The PDU session type may be IP-based, non-IP-based, and ethernet-based, among others.

The UPFs 184a, 184b may connect 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 a packet-switched network (e.g., the internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices, and the UPFs 184a, 184b may perform other functions, such as routing and forwarding packets, implementing user-plane policies, supporting multi-homed PDU sessions, processing user-plane QoS, buffering downlink packets, providing mobility anchoring processing, and so forth.

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 connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface that interfaces to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185 b.

In view of fig. 1A-1D and the corresponding description with respect to fig. 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enode bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN185a-B, and/or any other device(s) described herein. These emulation devices can be one or more devices configured to simulate one or more or all of the functions described herein. These emulation devices may be used, for example, to test other devices and/or to simulate network and/or WTRU functions.

The simulated device may be designed to conduct one or more tests with respect to other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more simulated devices may perform one or more or all functions while implemented and/or deployed, in whole or in part, as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more or all functions while temporarily implemented/deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device to perform testing and/or may perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more functions, including all functions, while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario of a test laboratory and/or a wired and/or wireless communication network that is not deployed (e.g., tested) in order to conduct testing with respect to one or more components. The one or more simulation devices may be test devices. The simulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., the circuitry may include one or more antennas).

Systems, methods, and instrumentalities are provided for vehicle-to-everything (V2X) service oriented link establishment. May be based on an identifier (e.g., K)_D-sessID) to identify the security context of a link established between two Wireless Transmit Receive Units (WTRUs) at a PC5 reference point. May be based on a full identifier (e.g., K)_D-sessID) to identify the security context of the link established between the two WTRUs at the PC5 reference point.

The first WTRU may generate a broadcast message including information regarding the V2X service. The first WTRU may advertise the V2X service, for example, by including a V2X service indication when sending the broadcast message (e.g., one or more WTRUs including the second WTRU). The first WTRU may receive a direct communication request message from a second WTRU. The direct communication request message may include a security key identifier K_D-sessA set of Most Significant Bits (MSBs) of the ID.

The first WTRU may generate a set of Least Significant Bits (LSBs) of the key identifier. The first WTRU may create a security context associated with the direct communication request message received from the second WTRU.

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 V2X service information.

The first WTRU may generate a broadcast message that includes information about the V2X service and a set of MSBs of the key identifier. The first WTRU may receive a direct security mode command from a second WTRUA message. The direct secure mode command message may include a key identifier K_D-sessA set of LSBs of the ID. The first WTRU may generate the key identifier by combining a set of the generated MSBs of the key identifier with a received set of LSBs of the key identifier.

The first WTRU may determine whether the combined key identifier is unique. The first WTRU may generate a security context associated with the direct security mode command message received from the second WTRU if the combined key identifier is unique. The security context may be identified based on the uniquely combined key identifier. The first WTRU may send a direct security mode complete message to the second WTRU.

The first WTRU may send a direct security mode reject message to the second WTRU if the key identifier is not unique. The direct security mode reject message may include a cause value indicating that the group LSB 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 another set of LSBs.

Fig. 2 shows an example of security association establishment during connection establishment. One type of proximity services (ProSe) direct communication or WTRU-to-WTRU communication (e.g., vehicle-to-property (V2X) communication) may be established over the PC5 reference point. One-to-one ProSe direct communication may be achieved by establishing a security layer-2 link over a PC5 reference point between two WTRUs, e.g., an initiating WTRU (e.g., WTRU-1) and a target WTRU (e.g., WTRU-2). The initiating WTRU (WTRU 1) may initiate DIRECT link setup by generating a DIRECT _ COMMUNICATION _ REQUEST message. The terms "DIRECT COMMUNICATION REQUEST" message and "DIRECT COMMUNICATION REQUEST" message may be used interchangeably. Upon receiving the DIRECT _ COMMUNICATION _ REQUEST message, the initiating WTRU and the target WTRU may perform link authentication and establish a DIRECT link security association. Upon completion of the link authentication and successful establishment of the 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 communication with the target WTRU.

For example, in ProSe direct one-to-one communication, multiple layers of keys (e.g., four different layers of keys) may be used. The multi-layer key may include K_DSecret key, K_D-sessKeys, ProSe Encryption Keys (PEKs), and/or ProSe Integrity Keys (PIKs). There may be 256 bits of the root key. K_DThe key may be shared between two entities communicating using ProSe direct one-to-one communication. K_DThe ID may be used to identify the K_D。K_D-sessThe ID key may be a 256-bit root key. K_D-sessThe ID key may be the root of the actual security context used to protect data transmissions between the two WTRUs. The keys (e.g., PEK and PIK) used by the confidentiality and integrity algorithms may be selected from K_D-sessThe ID key is derived. Security context ID (e.g., 16-bit K)_D-sessID) can be used to identify K_D-sessAn ID key. The PEK and PIK may be session keys that may be used by a confidentiality algorithm and an integrity algorithm, respectively. PEKs and PIKs may be used to secure ProSe direct one-to-one communication over the PC5 interface. PEK and/or PIK can be selected from K_D-sessThe ID key is derived.

The target WTRU may initiate a DIRECT security mode control procedure, for example, in response to receiving a DIRECT _ COMMUNICATION _ REQUEST message. The target WTRU may generate K_D-sessLSB of ID. The target WTRU may receive K from the initiating WTRU, e.g., via a DIRECT _ COMMUNICATION _ REQUEST message_D-sessThe MSB of the ID. The target WTRU may send K_D-sessLSB and K of ID_D-sessThe Most Significant Bit (MSB) combination of the ID.

The target WTRU may generate a 128-bit Nonce _2 value. The target WTRU may use, for example, K_DNonce _1 and Nonce _2 to derive K_D-sessAnd (4) ID. As shown in fig. 2, the target WTRU may send a DIRECT SECURITY MODE COMMAND message to the initiating WTRU. The target WTRU may include the DIRECT _ SECURITY _ MODE _ COMMAND message with the target WTRU's IDNonce _2 and K_D-sessThe least significant 8 bits of the ID. The terms DIRECT SECURITY MODE COMMAND message and DIRECT SECURITY MODE COMMAND message may be used interchangeably. The initiating WTRU may calculate K, e.g., in response to receiving a DIRECT SECURITY MODE COMMAND message_D-sessID. A confidentiality key and/or an integrity key. The initiating WTRU may use, for example, K_DNonce _1 and Nonce _2 to calculate K_D-sessAnd (4) ID. As shown in fig. 2, the initiating WTRU may send a DIRECT SECURITY MODE COMPLETE message to the target UE. The terms DIRECT SECURITY MODE COMPLETE message and DIRECT SECURITY MODE COMPLETE message may be used interchangeably. The initiating WTRU may send the K_D-sessLSB of ID (e.g., received in DIRECT _ SECURITY _ MODE _ COMMAND message) and K generated by initiating WTRU_D-sessMSBs of the ID are combined to form K_D-sess ID。

K_D-sessThe ID (e.g., root of security association) may be generated by the initiating WTRU and/or the transmitting WTRU. K_D-sessA portion of the ID may be used (e.g., used locally) to identify the security context. For example, the initiating WTRU may use K_D-sess8 MSBs of an ID to locate K for a link_D-sess. The target WTRU may use the formed K_D-sess8 LSBs of the ID to locate its K_D-sessFor linking. The security context may include one or more of the following information elements: k_D-sessPEK, PIK, remote UE user information and/or K_D。

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. A service announcement mechanism may be used in V2X communications, for example, to inform peer WTRUs about the WTRU's presence. The capabilities of a WTRU (e.g., a V2X WTRU) may be transmitted via the service announcement mechanism. The capabilities of the WTRU may include, for example, services supported by the V2 XWTRU. For example, the V2x WTRU may inform peer WTRUs of its capability to support unicast communications. V2X (e.g., enhanced V2X (eV2X)) link establishment may utilize various mechanisms. The mechanism may include WTRU-oriented layer 2 link establishment and/or V2X service oriented layer 2 link establishment.

Fig. 3 illustrates an exemplary layer 2 link establishment mechanism that may be used for V2X. As shown in fig. 3, in the layer 2 link establishment mechanism, a first WTRU (e.g., WTRU-1) may send a DIRECT _ COMMUNICATION _ REQUEST message via a broadcast mechanism, for example, to a broadcast address associated with an application. For example, the first WTRU may broadcast a 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 a second WTRU (e.g., WTRU-2). The second WTRU's upper layer identifier in the DIRECT _ COMMUNICATION _ REQUEST may be used to allow the second WTRU (e.g., WTRU-2) to decide 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 (e.g., WTRU-1) may obtain the L2 ID of a second WTRU (e.g., of WTRU-2) for future communications, e.g., for signaling traffic and/or for data traffic.

Fig. 4 illustrates an exemplary V2X layer 2 link establishment. As shown in fig. 4, information about the V2X service requesting the L2 link establishment (e.g., information about the V2X service advertised) 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 or not to respond to the DIRECT _ COMMUNICATION _ REQUEST message. One or more WTRUs interested in using the V2X service advertised by the DIRECT _ COMMUNICATION _ REQUEST message (e.g., WTRU-2 and WTRU-4 shown in figure 4) may respond to the REQUEST. A responding WTRU (e.g., WTRU-2 and WTRU-4) may be interchangeably referred to as a WTRU of interest, a responding WTRU, and/or a peer WTRU.

The initiating WTRU may broadcast a DIRECT _ COMMUNICATION _ REQUEST message. The broadcast DIRECT _ notification _ REQUEST message may include information related to the V2X service. One or more WTRUs may receive a broadcast DIRECT _ COMMUNICATION _ REQUEST message that includes information about the V2X service. One or more WTRUs interested in using V2X services may initiate direct security mode control. One or more interested WTRUs may send respective DIRECT _ COMMUNICATION _ ACCEPT messages to the initiating WTRU. The corresponding DIRECT _ COMMUNICATION _ ACCEPT message may establish a corresponding unicast link with the initiating WTRU (e.g., WTRU-1 in figure 4).

Interested WTRUs may reply to the broadcasted DIRECT _ COMMUNICATION _ REQUEST message. For example, each interested WTRU may send a DIRECT SECURITY MODE COMMAND message to the initiating WTRU. The DIRECT SECURITY MODE COMMAND message(s) may create a SECURITY association with the initiating WTRU. K_D-sessThe MSB of the ID may be used to locally identify the security association on the initiating WTRU (e.g., WTRU-1). Most significant 8 bits (MSB) for each K at an initiating WTRU (e.g., WTRU-1)_D-sessThe IDs may be the same. An initiating WTRU (e.g., WTRU-1) may associate each of the interested WTRUs with the same security context. K_D-sessThe ID (e.g., 8 MSBs from the initiating WTRU plus 8 LSBs from the peer WTRU) may be unique for each of the one-to-one links between the initiating WTRU and the WTRU of interest. Since multiple peer WTRUs reference the same MSB K_D-sessThe ID, and thus the security association for each link/session, may or may not be unique.

Fig. 5A and 5B illustrate exemplary link establishment for the V2X service. As shown in fig. 5A and 5B, each interested WTRU that replies to the DIRECT _ COMMUNICATION _ REQUEST message may point to the same security association on the initiating WTRU side.

Referring to fig. 5A and 5B, an initiating WTRU (e.g., WTRU1) may receive a DIRECT SECURITY MODE COMMAND message from a first WTRU of interest (e.g., WTRU 2). The initiating WTRU may be created by MSB K_D-sessThe ID identifies the security context entry. The initiating WTRU may be on DIRECT _ SECInformation received in the URITY _ MODE _ COMMAND message (e.g., random number 2, selected algorithm) and other information (e.g., K)_D-sessID. PEK, PIK and K_D-sessID) are stored together. The initiating WTRU may receive a second DIRECT SECURITY MODE COMMAND message from a second WTRU of interest (e.g., WTRU 3). The initiating WTRU (e.g., WTRU1) may not update the security context with the value received from the second interested WTRU (e.g., WTRU 3) because the key from the first interested WTRU (e.g., WTRU2) is already stored in the same security context entry. The security procedures used by the first and second interested WTRUs (e.g., WTRU2, WTRU 3) may be based on the same MSB K that each of the first and second interested WTRUs receive from the initiating WTRU (e.g., WTRU1)_D-sess ID。

In an example, one or more keys from a second WTRU of interest may be saved (e.g., override keys from a first WTRU of interest (e.g., WTRU 2)). As a result, communication with the first interested WTRU may not be possible because one or more keys corresponding to the first interested WTRU may be lost. The loss of one or more keys corresponding to the first WTRU of interest may cause a security check failure in a subsequent direct communication between the initiating WTRU (e.g., WTRU1) and the first WTRU of interest (e.g., WTRU 2).

In an example, one or more keys from a second WTRU of interest (e.g., WTRU 3) may not be maintained by the initiating WTRU (e.g., WTRU 1). The initiating WTRU (e.g., WTRU1) may not be able to establish a security association with a second WTRU of interest (e.g., WTRU 3). A link between the initiating WTRU and a second WTRU of interest may not be established. The initiating WTRU may not be able to establish secure direct communication with multiple responding/interested WTRUs simultaneously. One or more Nonce _2 values may be generated on each of the first WTRU of interest and the second WTRU of interest. For example, the one or more Nonce _2 values may be randomly generated on each of the two WTRUs. The one or more Nonce _2 values may have different values.

Service-oriented and/or WTRU-oriented layer 2 link establishment may be implemented. Service-oriented layer 2 unicast link establishment may be implemented for a service, e.g., for a V2X service in the case of V2X communication, or for another service in the case of other types of communication (e.g., communication between drones).

Fig. 6A and 6B illustrate exemplary link establishment for the V2X service. As shown in fig. 6A and 6B, each WTRU of interest (e.g., WTRU2 and WTRU 3) may receive a DIRECT _ COMMUNICATION _ REQUEST message from an initiating WTRU (e.g., WTRU 1). The DIRECT _ COMMUNICATION _ REQUEST message may include information about the V2X service. One or more interested WTRUs may determine that they are interested in V2X services. One or more interested WTRUs interested in V2X service may initiate unicast link establishment with the initiating WTRU, for example, by sending a corresponding DIRECT _ COMMUNICATION _ REQUEST message to the initiating WTRU. Each interested or peer WTRU may initiate a unicast link establishment. The initiating WTRU may create a respective different security context on the initiating WTRU based on DIRECT _ COMMUNICATION _ REQUEST messages received from one or more interested WTRUs (e.g., WTRU2 and WTRU 3). A different security context index may be created for each peer-to-peer or interested WTRU (e.g., based on K)_D-sessThe LSB of the ID). For example, the initiating WTRU may create a different security context each time a DIRECT _ COMMUNICATION _ REQUEST message is received from a peer or interested WTRU.

As shown in fig. 6A and 6B, the WTRU of interest or a peer WTRU (e.g., WTRU2) may be the initiator of the link establishment. The DIRECT _ COMMUNICATION _ REQUEST message sent by the initiating WTRU (e.g., WTRU1) may indicate the V2X services supported. One or more WTRUs interested in the indicated supported V2X service may initiate a link setup with the initiating WTRU. The initiating WTRU (e.g., WTRU1) may indicate K set to null or zero in the initial link setup message_D-sessThe MSB of the ID. Will K_D-sessThe MSB of the ID set to a null value or zero may indicate that the value is not associated with a security context on the initiating WTRU (e.g., WTRU 1). In an example, an initiating WTRU (e.g., WTRU1) may set K_D-sessThe MSB of the ID is left outside the DIRECT _ COMMUNICATION _ REQUEST message.

In an example, an initiating WTRU (e.g., WTRU1) may indicate supported V2X SERVICEs in different types of messages (e.g., V2X _ SERVICE _ announce (V2X _ SERVICE _ announce), V2X _ SERVICE _ advertise (V2X _ SERVICE _ advertise)), e.g., to reflect the true functionality of the initial message from the initiating WTRU (e.g., WTRU 1). K_D-sessThe MSB of the ID may be generated by the WTRU or peer WTRU of interest. For example, one or more WTRUs interested in the advertised V2X service (e.g., WTRU2 and WTRU 3) may generate K_D-sessA set of MSBs of the ID. The initiating WTRU may generate K for each received direct link communication request_D-sessDifferent sets of LSBs of the ID. The initiating WTRU may generate a different security context for each direct link communication request. Can use K_D-sessThe LSB of the ID indexes each security context. The initiating WTRU (e.g., WTRU1) may discard the K it sent in the initial broadcast DIRECT _ notification _ REQUEST message (e.g., to advertise V2X service)_D-sessThe initially created empty MSB of the ID.

As shown in fig. 6A and 6B, the WTRU of interest (e.g., WTRU2) may send a DIRECT _ communication _ REQUEST message to the initiating WTRU (e.g., WTRU 1). The destination field of the DIRECT _ COMMUNICATION _ REQUEST message may be set to the L2 ID of WTRU1, and the source field of the DIRECT _ COMMUNICATION _ REQUEST message may be set to the L2 ID of WTRU 2. Information associated with V2X services (e.g., services of interest to the WTRU of interest (WTRU 2)) that the initiating WTRU (e.g., WTRU1) announced on the initial DIRECT _ COMMUNICATION _ REQUEST message may be copied on the message that the WTRU of interest (e.g., WTRU2) sent to the initiating WTRU (e.g., WTRU 1).

Another WTRU of interest (e.g., WTRU 3) may send a DIRECT _ COMMUNICATION _ REQUEST message to the initiating WTRU (e.g., WTRU 1). The DIRECT _ COMMUNICATION _ REQUEST message from the other WTRU of interest (e.g., WTRU 3) may include the destination field set to WTRU 1L 2ID and the source field of the DIRECT _ COMMUNICATION _ REQUEST message may be set to WTRU 3L 2 ID. The advertised V2X service received by the initiating WTRU (e.g., WTRU1) may be included in a DIRECT _ COMMUNICATION _ REQUEST message sent by other interested WTRUs (e.g., WTRU 3) to the initiating WTRU (e.g., WTRU 1). The initiating WTRU may initiate mutual authentication with the WTRU of interest (e.g., WTRU2 or WTRU 3) upon receiving a message from the WTRU of interest (e.g., WTRU2 or WTRU 3).

Fig. 7A and 7B illustrate exemplary link establishment for the V2X service. The security context may be based on a security context ID (e.g., a full K)_D-sessID). As shown in fig. 7A and 7B, the initiating WTRU (e.g., the first WTRU, WTRU1) may use the entire security context ID (e.g., K)_D-sessID) to locate the security context, e.g., rather than using the security context ID (e.g., K)_D-sessID). An initiating WTRU (e.g., a first WTRU, WTRU1) may generate an entire security context ID (e.g., K) by combining (e.g., concatenating) a first security context ID associated with the initiating WTRU and a second security context ID from a peer WTRU (e.g., received from a peer WTRU (e.g., WTRU2) via a direct security mode command message)_D-sessID). The entire security context ID may be the third security context ID. The resulting third security context ID (e.g., K)_D-sessID) may be unique for each one-to-one link. The initiating WTRU may send a direct security mode complete message to a peer WTRU (e.g., WTRU 2).

As shown in fig. 7A and 7B, a first WTRU (e.g., an initiating WTRU) may send a direct communication request message. The direct communication request message may be transmitted via broadcasting. The direct communication request message may include a first security context ID. For example, the first WTRU may generate the 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-sessID) of the same. The direct communication request message may include a list of supported V2X services. A plurality of WTRUs may receive the broadcasted direct communication request message. The second WTRU may send (e.g., in response to receiving the broadcasted direct communication request) to the first WTRUMessage) direct security mode command message. The first WTRU may receive the direct security mode command message. The direct security mode command message may include a second security context ID. For example, the second WTRU may generate the second security context ID. The second security context ID may be associated with the second WTRU. The second security context ID may include a security key ID (e.g., K)_D-sessID) of the first group of LSBs. 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 V2X services. 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 the group MSB and the group LSB of the security key ID. The first WTRU may establish a secure direct communication 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 communication link with the second WTRU based on the third security context ID. The second WTRU may receive a direct security mode complete message that may indicate that a secure direct communication link associated with the third security context ID has been established between the first WTRU and the second WTRU.

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 the 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. The first WTRU may send a direct security mode reject message to the third WTRU when the fourth security context ID is the same as the second security context ID. The direct security mode reject message may indicate that the second set of LSBs is not unique. A 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, for example, 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 the 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 a fifth security context ID.

As shown in fig. 7A and 7B, a peer WTRU (e.g., WTRU 4) may generate a K that has been used by another peer WTRU (e.g., WTRU 3)_D-sessA set of LSBs of the ID. In this case, K is formed_D-sessThe ID (e.g., combined with the group LSB and the group MSB) may already be present on the originating WTRU. When K is formed_D-sessThe initiating WTRU may reject the direct security mode command message when the ID is already present at the initiating WTRU, for example by sending a direct security mode reject message to a peer WTRU (e.g., WTRU 4). The direct security mode rejection message may include a cause value indicating K_D-sessThe LSB of the ID is not unique (e.g., K)_D-sessCollision of LSB of ID). When a peer WTRU (e.g., WTRU 4) receives such a reject message, it may determine whether the cause value in the reject message matches K_D-sessThe collision of the LSBs of the ID is relevant. A peer WTRU (e.g., WTRU 4) may generate K_D-sessAnother set of LSBs of the ID. A peer WTRU (e.g., WTRU 4) may associate K with_D-sessSecurity context entries associated with the rejected LSBs of the ID (e.g., K derived from information held in a direct communication request message received from an initiating WTRU_D-sessID key, PEK, PIK, etc.) to the and K_D-sessOther group LSBs of the ID are associated with another security context of the creation. Peer-to-peerThe WTRU (e.g., WTRU 4) may forget and/or discard K_D-sessA rejected set of LSBs of the ID. A peer WTRU (e.g., WTRU 4) may send another (e.g., updated) direct security mode command message to the initiating WTRU, indicating K_D-sessAnother set (e.g., newly generated) LSBs of the ID. The peer WTRU may save (e.g., locally save) K_D-sessThe other set of LSBs of the ID.

By K_D-sessMSB and K of ID_D-sessK formed by LSB of ID_D-sessThe ID may be unique for each peer WTRU (e.g., WTRU of interest). The initiating WTRU may use K_D-sessThe ID value to store and/or locate a security context associated with the peer WTRU. One peer WTRU (e.g., a single peer WTRU) may be associated with a security context (e.g., even with K)_D-sessThe same MSB of the ID is associated). Having K_D-sessDifferent K of different LSB of ID_D-sessAn ID may be used for each security context (e.g., even if K is used)_D-sessThe same MSB of the ID). Different KD-ses IDs may be used for multiple unicast communications (e.g., unicast communications with multiple interested WTRUs).

The WTRU may be configured to perform layer 2 unicast link establishment towards V2X services. The V2X service list (e.g., instead of one V2X service) may be specified via a broadcast DIRECT _ notification _ REQUEST message. For example, broadcasting a DIRECT _ notification _ REQUEST message may indicate the V2X service list. 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 the initiating WTRU may send, thereby reducing the number of messages that the receiving WTRU may otherwise process.

Fig. 8 illustrates an exemplary V2X service oriented layer 2 unicast link establishment utilizing a V2X service list. As shown in fig. 8, the direct communication request broadcast message from the initiating WTRU (e.g., WTRU1) may include information related to the V2X service list (e.g., instead of information related to one V2X service). Sending the service list in the direct communication request broadcast message by the initiating WTRU may reduce the number of messages to be sent by the initiating WTRU. Transmitting a service list in a direct communication request broadcast message by the initiating WTRU may reduce the number of messages processed by the receiving WTRU. For example, if the WTRU supports five V2X services, the initiating WTRU may use one message (e.g., instead of five messages) to advertise all five V2X services. Since the announce message may be repeated periodically, advertising all five V2X services with a single message may result in saving a significant number of messages over a period of time (e.g., sent by the initiating WTRU and/or processed by the receiving WTRU).

Sending the service list by the initiating WTRU in the direct communication request broadcast message may reduce the time required to connect the WTRU for one or more (e.g., each) V2X services in the service list. For example, a WTRU receiving a message advertising support for multiple services (e.g., five services) may trigger (e.g., immediately trigger) link establishment for a V2X service of interest (e.g., three links may be established simultaneously if the receiving WTRU is interested in three V2X services). For example, the WTRU may trigger link establishment without waiting for the receipt of an additional message announcing that additional V2X services are supported.

As shown in fig. 8, the initiating WTRU (e.g., WTRU1) may broadcast a DIRECT _ notification _ REQUEST message that includes a list of supported V2X services. The list of supported V2X services may include a plurality of 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 shown in fig. 8, multiple receiving WTRUs (e.g., WTRU2, WTRU 3, and/or WTRU 4) may receive the broadcasted DIRECT _ COMMUNICATION _ REQUEST message from the initiating WTRU (e.g., WTRU 1). Each receiving WTRU may process and decode the multiple V2X services. A receiving WTRU (e.g., WTRU2) may be interested in one V2X service. A receiving WTRU (e.g., WTRU2) may initiate a unicast communication for the V2X service of interest, e.g., as described herein. A receiving WTRU (e.g., WTRU2) may send a DIRECT _ COMMUNICATION _ REQUEST message with the layer 2ID of the receiving WTRU (e.g., WTRU 2L 2 ID) as the source ID and the layer 2ID of the originating WTRU (e.g., WTRU 1L 2 ID) as the destination ID. The receiving WTRU (e.g., WTRU2) may specify the service of interest in a DIRECT _ COMMUNICATION _ REQUEST message.

As shown in fig. 8, a receiving WTRU (e.g., WTRU 4) may receive a broadcasted DIRECT _ COMMUNICATION _ REQUEST message from an initiating WTRU (e.g., WTRU1) broadcasting a service list. A receiving WTRU (e.g., WTRU 4) may be interested in multiple V2X services in the list of services it receives from the originating WTRU. A receiving WTRU (e.g., WTRU 4) may initiate a unicast communication for the first V2X service of interest, as described herein. The receiving WTRU (e.g., WTRU 4) may send an initial DIRECT _ COMMUNICATION _ REQUEST message with the layer 2ID of the receiving WTRU (e.g., WTRU 4L 2 ID) as the source ID and the layer 2ID of the originating WTRU (e.g., WTRU 1L 2 ID) as the destination ID. The receiving WTRU may include the V2X service of interest in its DIRECT _ COMMUNICATION _ REQUEST message. The layer 2ID of the initiating WTRU (e.g., WTRU 1L 2 ID) may use a value per service (e.g., a unique value). The new source layer 2ID may be added by the initiating WTRU during link setup and/or when sending a direct communication accept message (not shown). An Information Element (IE) may be used to update the layer 2 ID. The peer-to-peer WTRU may update its peer-to-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. A receiving WTRU (e.g., WTRU 4) may initiate a 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.

Figure 9 illustrates an exemplary WTRU-oriented layer 2 link establishment for a WTRU list using, for example, upper layer information of the WTRU. As shown in fig. 9, the direct communication request broadcast message from the initiating WTRU (e.g., WTRU1) may include upper layer information associated with each WTRU. Sending one broadcast message that includes the WTRU's upper layer ID list may reduce the number of messages that the initiating WTRU may send. For example, the initiating WTRU may send a direct communication request broadcast message to multiple receiving WTRUs with which the initiating WTRU may want to establish a link (e.g., instead of sending a single message to each of the multiple receiving WTRUs).

The receiving WTRU, upon receiving a direct communication request broadcast message with an upper layer ID list of WTRUs, 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. The receiving WTRU may trigger (e.g., immediately trigger) a layer 2 link establishment with the initiating WTRU if the receiving WTRU determines that its upper layer ID is in the upper layer ID list of the WTRU that directly communicates the request to broadcast message. The receiving WTRU may establish a layer 2 link, e.g., without waiting to receive an additional message from the initiating WTRU.

As shown in fig. 3, the initiating WTRU (e.g., WTRU-1) may broadcast a DIRECT _ COMMUNICATION _ REQUEST message with the destination upper layer ID of the WTRU it may desire to reach. Each receiving WTRU (e.g., WTRU-2, WTRU-3, and WTRU-4) may receive the DIRECT _ COMMUNICATION _ REQUEST message. Each receiving WTRU (e.g., WTRU-2, WTRU-3, and WTRU-4) may process and decode the DIRECT _ COMMUNICATION _ REQUEST message and the WTRU specified in the DIRECT _ COMMUNICATION _ REQUEST message may respond. For example, if an initiating WTRU (e.g., WTRU-1) desires 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 ID of the respective WTRU).

As shown in fig. 9, an initiating WTRU (e.g., WTRU1) may broadcast a single DIRECT _ COMMUNICATION _ REQUEST message to multiple receiving WTRUs (e.g., WTRU2, WTRU 3, and WTRU 4) with the upper layer IDs of WTRUs that the initiating WTRU may desire to reach. Each receiving WTRU (e.g., WTRU2, WTRU 3, and WTRU 4) may process and decode the received single broadcast DIRECT _ COMMUNICATION _ REQUEST message.

As shown in fig. 9, a receiving WTRU (e.g., WTRU2 or WTRU 4) may establish a layer-2 link by sending a response to a DIRECT _ COMMUNICATION _ REQUEST message received from an initiating WTRU (e.g., WTRU 1). A receiving WTRU (e.g., WTRU2 or WTRU 4) may send a DIRECT COMMUNICATION accept message (e.g., option a) or send its own DIRECT _ COMMUNICATION _ REQUEST message (e.g., option B), as described herein.

As shown in fig. 9, the initiating WTRU (e.g., WTRU1) may broadcast a DIRECT _ COMMUNICATION _ REQUEST message with a destination upper layer ID list. Multiple receiving WTRUs (e.g., WTRU2, WTRU 3, and WTRU 4) mayTo receive the message. The plurality of WTRUs (e.g., WTRU2, WTRU 3, and WTRU 4) may process and decode the plurality of upper layer IDs. If the receiving WTRU (e.g., WTRU2 or WTRU 4) determines that the destination upper layer ID list includes its own upper layer ID, the receiving WTRU may continue link establishment. Using option a, a receiving WTRU (e.g., WTRU2 or WTRU 4) may send a DIRECT _ COMMUNICATION _ ACCEPT message to an initiating WTRU (e.g., WTRU1) as a response to the received message, e.g., after link authentication and security association. Using this option a, the entire K may be used in initiating and receiving WTRUs_D-sessID to locate the security context locally. Using option B, each replying WTRU may not reply to the DIRECT _ COMMUNICATION _ REQUEST message of the initiating WTRU (e.g., WTRU 1). One or more of the replying WTRUs may initiate link establishment, for example, by sending their own respective DIRECT _ COMMUNICATION _ REQUEST messages.