Patent Description:
The document "<NPL>, discusses a mechanism for ensuring adequate privacy over PC5. When performing V2X communication over PC5, the user equipment runs a privacy timer. When the timer expires, the user equipment changes the source Layer-<NUM> ID and then resets the privacy timer. When performing V2X communication over PC5, if the user equipment gets a notification from upper layers that the application layer identifier has been changed, the user equipment changes the source Layer-<NUM> ID and then resets the privacy timer.

The document "<NPL>, discusses aspects of privacy of PC5 communication. In particular, it is proposed to include an indication of an ID change event to a V2X application, in addition to the already foreseen indication from the V2X application.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (VTRUs) 102a, 102b, 102c, 102d, a RAN <NUM>/<NUM>, a CN <NUM>/<NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.

Thus, the air interface utilized by VIΓΓRUs 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., an eNB and a gNB).

The RAN <NUM>/<NUM> may be in communication with the CN <NUM>/<NUM>, 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 VIΓΓRUs 102a, 102b, 102c, 102d.

More specifically, the VIΓΓRU <NUM> may employ MIMO technology. Thus, in one embodiment, the VIΓΓRU <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface <NUM>.

The processor <NUM> may receive power from the power source <NUM> and may be configured to distribute and/or control the power to the other components in the VIΓΓRU <NUM>. The power source <NUM> may be any suitable device for powering the VIΓΓRU <NUM>. For example, the power source <NUM> may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithiumion (Li-ion), etc.), solar cells, fuel cells, and the like.

It will be appreciated that the WTRU <NUM> may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

The full duplex radio may include an interference management unit <NUM> to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor <NUM>).

The MME <NUM> may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN <NUM> via an S1 interface and may serve as a control node. For example, the MME <NUM> may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the VIΓΓRUs 102a, 102b, 102c, and the like.

The SGW <NUM> may be connected to the PGW <NUM>, which may provide the VIΓΓRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet <NUM>, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

A <NUM> channel may be formed by combining <NUM> contiguous <NUM> channels, or by combining two noncontiguous <NUM> channels, which may be referred to as an <NUM>+<NUM> configuration.

The VIΓΓRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).

In the standalone configuration, VIΓΓRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In a non-standalone configuration VIΓΓRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, VIΓΓRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.

For example, the AMF 182a, 182b may be responsible for authenticating users of the VIΓΓRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized VIΓΓRUs 102a, 102b, 102c.

In view of <FIG>, and the corresponding description of <FIG>, one or more, or all, of the functions described herein with regard to one or more of: VIΓΓRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME <NUM>, SGW <NUM>, PGW <NUM>, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).

As discussed herein, a WTRU can run one or more V2X applications. Source WTRUs are interchangeably referred to as requesting WTRUs, and target VIΓΓRUs are interchangeably referred to as destination WTRUs or peer WTRUs herein.

In an example V2X architecture, a V2X Application Server (AS) can be located in the network and can interface with V2X applications installed on the WTRUs (i.e., V2X devices in this context). A V2X Control Function (CF) can handle authorization and provisioning for the V2X devices (i.e., V2X policy and parameters configuration towards the WTRU). The V2X control function (CF) can be located in the <NUM> CN and may be assumed to be part of the service-based architecture. V2X WTRU-to-WTRU communication can be based on two modes of operation. In a first mode, V2X WTRU-to-WTRU communication can take place over an LTE-Uu interface. In a second mode, V2X WTRU-to-WTRU communication can take place over a PC5 (e.g., V2X sidelink or Proximity-based Services) (ProSe)) interface.

V2X communication over a PC5 reference point is a type of ProSe direct communication. One-to-one ProSe direct communication can be realized by establishing a secure layer-<NUM> (L2) link over PC5 between two WTRUs. The initiating WTRU trying to establish the link must have the L2 identification (ID) for both itself and the peer (target) WTRU. The L2 ID of the target WTRU may be preconfigured on the initiating WTRU or may be obtained via ProSe Direct Discovery. The initiating WTRU may initiate the direct link setup by generating a PC5 Signaling message (e.g., a DIRECT_COMMUNICATION_REQUEST message). The message may include: <NUM>) User Info set <NUM>) an IP Address Config Information Element (IE) <NUM>) a Link Local IPv6 Address IE and <NUM>) a maximum inactivity period IE. If the target VIΓΓRU receives the message from the initiating WTRU (e.g., a DIRECT_COMMUNICATION_REQUEST message), the target WTRU may store the pair of the L2 IDs and associate them with the direct link in context. After the completion of link authentication procedure and a successful establishment of the security association, the target VIΓΓRU may send a message (e.g., a DIRECT_COMMUNICATION_ACCEPT message) to the initiating WTRU. After receiving the PC5 Signaling message from the target WTRU (e.g., the DIRECT_COMMUNICATION_ACCEPT message), the initiating WTRU may use the established link for all one-to-one communications with the target WTRU.

Each VIΓΓRU may have a L2 ID for unicast communication that is included in the Source L2 ID field of every frame that it sends on the L2 link and in the Destination L2 ID of every frame that it receives on the L2 link.

The PC5 signaling protocol supports keep-alive functionality that may be used to detect whether the WTRUs are not in ProSe Communication range, e.g., so that they can proceed with implicit L2 link release. The requesting VIΓΓRU may initiate a keep-alive procedure, e.g., if (<NUM>) a request from upper layers to check the viability of the direct link is received; or (<NUM>) a keep-alive timer for the direct link expires.

The source L2 ID may be changed over time and randomized for security purposes; e.g., to avoid tracking and/or identification of the source WTRU (e.g., a vehicle) by any other WTRUs (e.g., other vehicles) beyond a certain short time-period required by the application. This applies to both WTRUs and identifiers associated with the session; i.e., both source & target.

Some implementations provide a Security Association and Session Identifier (KD-sess ID). During link establishment, a security association may be created between the peer WTRUs to secure the link, (i.e., to facilitate confidentiality & integrity protection). Each peer WTRU keeps locally a security context containing keys to encrypt/decrypt messages and to integrity protect them. This security context is associated with this specific Peer-to-Peer link. A security association identifier for the specific link (which may be referred to as a KD-sess ID) may be used by each peer WTRU to identify and retrieve the security context and/or keys if a message is received (e.g., to check the integrity of the message and/or to decrypt it) or if a message needs to be sent (e.g., to encrypt the message and/or to protect its integrity). The session identifier (i.e., KD-sess ID) is created by concatenating identifier components from each peer, i.e., the most-significant byte (MSB) (i.e., most significant <NUM> bits) of KD-sess ID is from the initiating WTRU and the least-significant byte (LSB) (i.e., least significant <NUM> bits) of K D-sess ID is from the peer WTRU. Each WTRU uses its portion of the KD-sess ID (i.e., MSB or LSB) to retrieve the security context associated to the link.

<FIG> depicts an example <NUM> of the Packet Data Convergence Protocol (PDCP) header for one-to-one communications. As shown in <FIG>, the session identifier <NUM> (i.e., KD-sess ID) is transmitted with each packet as part of the PDCP header together with a counter <NUM> representing the number of exchanged packets since establishment of the security context. Also included in the PDCP is a Payload portion <NUM>, which is optionally ciphered, and a Message Authentication Code (MAC) portion <NUM> when required.

Enhanced V2X (eV2X) may support unicast/multicast over PC5 for eV2X communication. Besides the broadcast mechanism, eV2X may support a new interactive delivery mechanism to handle high data rate data sharing between vehicles; e.g., using unicast and/or multicast. Such mechanisms may utilize a long duration session using the same source L2 ID. This may create a privacy issue if the source L2 ID is tracked and linked. Such privacy issues would affect both peers; i.e., both the source WTRU and target WTRU.

Accordingly, it may be desired to change the source L2 ID while the session is ongoing (e.g., periodically or randomly). However, if the source L2 ID is changed on the source WTRU, the peer WTRU may need to be informed since the ongoing session is identified by source L2ID. Current ProSe mechanisms do not support source L2 ID modification for an ongoing session. In addition, changing the L2 ID may introduce other problems. For example, a VIΓΓRU having multiple sessions and using the same L2 ID must update all its sessions/peers at the same time (or within a defined, e.g., short, time). It may also be necessary for the WTRU to update L2 IDs for each session. For each session, the WTRU may need to keep receiving traffic on its old L2 ID until the change of L2 ID is confirmed by its peer WTRU. Such requirements may generate or require inefficient procedures, and may potentially generate a plurality of message exchanges, e.g., because all WTRUs in this example must periodically change their L2 IDs.

It may also be necessary to address privacy of the security context ID. In some implementations, the security context ID (KD-sess ID), transmitted in the PDCP header, may be used by an eavesdropper to indirectly detect that the old L2 ID (e.g., source or destination L2 ID) is changed to a new L2 ID, if the same KD-sess ID is used before and during and/or after L2 ID change procedure.

It may be desired, for privacy or other communication security purposes, for the source WTRU to prevent its old and new L2 ID being linked together by an eavesdropper while communicating the change of its L2 ID to its peer WTRU.

New procedures are typically described herein with reference to the source WTRU and source ID, however it is noted that the source and target VIΓΓRUs involved in a communication may each assume the role of the source and/or target, depending on which peer is initiating a specific exchange. Various methods, systems, and devices are discussed herein which facilitate modification of the source and target L2 IDs associated with an ongoing session. The session may be a unicast or multicast session that is used for a certain period of time that is long enough to permit a potential tracking threat. This period may be determined arbitrarily, empirically, or in any suitable manner. The period may depend on the application using it; e.g., an application that transmits information for more than a threshold amount of time. It is noted that V2X, as used in this document, serves as an example of direct WTRU to WTRU (e.g., utilizing a ProSe PC5 interface) communications. It may also apply to other types of WTRU to WTRU communications, (e.g., drones, etc.).

For example, a WTRU may be provisioned with a new interval (e.g., privacy timer), which may be set to the lifetime of its L2 ID for unicast communications and may include privacy protection parameters. Such parameters may also be the output of a function (e.g., a pseudo-random function). According to this interval, the WTRU's L2 ID must be changed (and randomized) within the specified interval, if the session is still ongoing. After the ID has been changed, the timer may be restarted so that the L2 ID will be changed again within the specified period. This process may be repeated as long as the session is ongoing.

As discussed earlier, the change in L2 ID of either or both WTRUs (i.e., either or both, source and target) may need to be communicated to the other VTRU(s) participating in communication. The WTRUs may also need to be made aware of the value of the new L2 ID value. Additionally, the source WTRU may update its security context and security context ID (KD-sess ID) with its peer WTRU during the procedure used to update its L2 ID. Conversely, the source WTRU may update its L2 ID during the procedure used to update its security context (e.g., Direct Link Rekeying procedure). Since the session involves two VIΓΓRUs (i.e., source and target) and two L2 IDs, both L2 IDs may need to be changed simultaneously, and each WTRU may need to be informed when the other WTRU is changing its L2 ID. The new source and target L2 IDs associated with the ongoing session may be changed independently, i.e., one after the other, or at the same time, during the same procedure.

In some examples, more than one event may trigger a L2 ID regeneration and update with the peer WTRU. For example, a timer expiration, the reception of a new L2 ID value from the peer WTRU, the update of an associated application identifier, a request from the peer WTRU, a communication context change, or other events may trigger L2 ID regeneration and update. A high-level view and example methods described below are detailed based on a privacy timer, for the sake of example, however it is understood that any of the triggers discussed above, or any other suitable trigger, may apply.

In some examples, a "relay" WTRU may be used between the source VIΓΓRU and target WTRU. This "relay" is not shown or discussed in the various figures and description herein. However, the same procedures as described in the following sub-sections may be applied to communications involving a relay WTRU, the relay being used only to transfer (e.g., "transparently") messages between the source and target WTRUs.

As discussed above, in some implementations, a WTRU having multiple sessions, which use the same L2 ID, must update all of its sessions/peers at the same time (or within a defined, e.g., short, time). In some implementations, for each session, the WTRU needs to keep receiving traffic on its old L2 ID until the change of L2 ID is confirmed by its peer WTRU. This may make the L2 ID change mechanism inefficient and may potentially generate a plurality of message exchanges, e.g., because all WTRUs must periodically change their L2 IDs. Therefore, to simplify the L2 ID update procedure and eliminate or reduce the impacts on other sessions, it is herein disclosed that, in some implementations, a WTRU implementing privacy support may use a different L2 ID per session. Explained another way, in such a newly disclosed implementation, every unicast session with different peer WTRUs would use a different source L2 ID. Also, each session with the same peer WTRU may be associated with only one application. Also, multiple applications running on source/target WTRU may all use distinct sessions.

<FIG> is a sequence chart <NUM> illustrating a high-level view of an example change of the requesting/source WTRU <NUM> L2 ID and, optionally, a change of the peer/destination/target WTRU <NUM> L2 ID, which may occur at the same time.

In reference block <NUM> of <FIG>, WTRUs are provisioned with privacy specific parameters, e.g., a privacy timer value, a seed value to generate the L2 ID, a seed value to generate the privacy timer, and so forth. Privacy policies are also provisioned, indicating which methods may be used and for a single WTRU or both WTRUs, e.g., privacy enabled/disabled, L2 ID privacy only, L2 ID + KD-sess ID privacy, etc. Such provisioning information may be provided by the V2X Control Function (CF), V2X application server (AS) or the parameters may be pre-provisioned in the WTRU (e.g., either in mobile equipment (ME) or in a universal integrated circuit card (UICC)). These parameters may be provisioned on a per-WTRU basis (e.g., to be used for all ProSe/V2X direct communication for a particular WTRU) or on a per-V2X application ID (e.g., intelligent transport systems application identifier (ITS-AID) or provider service identifier (PSID)) basis (e.g., to be used for all ProSe/V2X direct communication for a particular V2X application). In reference block <NUM> of <FIG>, PC5 communication is set up between a source WTRU and a peer WTRU (referred to as UEs in <FIG>). The peer WTRU may be provisioned with privacy-specific parameters (as described above) of the source WTRU, e.g., during session establishment (and vice-versa). Privacy policies received on the peer WTRU may be compared with the peer WTRU's provisioned policies and the privacy protection method matching the highest order may be selected. The source VIΓΓRU may be provisioned with privacy-specific parameters (as described above) of the peer WTRU, e.g., during link establishment. Blocks <NUM> and <NUM> of <FIG> represent a setup procedure for PC5 communications.

In blocks <NUM> A and <NUM> B of <FIG>, a privacy timer is started on the source VIΓΓRU (and optionally on the peer WTRU). In block <NUM> of <FIG>, communication is ongoing between the source VIΓΓRU and peer WTRU using source L2 ID #<NUM> (and peer L2 ID #<NUM>) and KD-sess ID #<NUM>. In blocks <NUM> A and <NUM> B of <FIG>, privacy timer expiration may occur, In block <NUM> A1, source WTRU <NUM> may apply the selected privacy policy for the ongoing session (assuming here that the selected policy to be applied is L2 ID + KD-sess ID privacy on both sides): the source WTRU generates a new source L2 ID (e.g., source L2 ID #<NUM>) or obtains it by other means; e.g., from the upper layer, and a new portion of the session ID (e.g., MSB of KD-sess ID #<NUM>). The new L2 ID and new MSB of KD-sess ID #<NUM> are associated with the current source L2 ID and current MSB of KD-sess ID used for this session and saved locally with the existing ID. The existing source L2 ID (source L2 ID #<NUM>) and possibly session ID (KD-sess ID #<NUM>) are still used at this point to identify the ongoing session. The source WTRU sends the new source L2 ID, in a new L2 ID IE, and possibly the new MSB of KD-sess ID in a new MSB of session ID IE, to the peer WTRU (e.g., using one of the methods described herein) or the peer VIΓΓRU itself regenerates a source L2 ID identical to the one obtained on the source VIΓΓRU (e.g., using a method described herein). It is noted that in the latter case, the KD-sess ID may not need to be updated since no privacy message is exchanged between the peer WTRUs. In some implementations, the same steps may be performed on both WTRUs at the same time in order to change the L2 ID, and potentially the session ID, during the same procedure. The privacy timer is just one example trigger for changing the L2 ID and session ID. The L2 ID and session ID may also be generated and subsequently communicated to the other WTRU, for example, if the WTRU receives a new source L2 ID from the peer WTRU e.g., as described herein; if upper layers or an application layer triggers the privacy procedure; if the WTRU moves into a new geographic area; if the WTRU receives new privacy parameters and/or policies from the V2X control function (CF) or V2X application server (AS); or when the UE receives a request from its peer to trigger the privacy procedure, e.g., as described herein.

In some implementations, in case where the V2X layer is triggered to change its L2 ID, e.g., timer, request from peer, etc., the V2X layer may inform/communicate to the upper layer about the imminent change of identity, e.g., for synchronization purposes. The upper layer may reply with a new upper layer identity, which may be sent with the new L2 ID to the peer VIΓΓRU. In some implementations, the interface between the V2X layer and upper layer is enhanced to allow such information to be passed; e.g., by an indication from V2X layer to application and a response from application to V2X layer.

In blocks <NUM> A and <NUM> B, a new source (and optionally peer) L2 ID and session ID are synchronized/communicated across layers on both WTRUs for PC5 communication. Such synchronization/communication is essentially a communication between layers (e.g., components and/or instances and/or functions) of V2X application portions, no matter where located, to ensure that all such components (hardware and /or software) that rely on updated L2 ID information are updated with the most recent values. The upper layer may be aware of which L2 ID is used and with an AS layer which uses L2 ID for PC5 communication. After the new source L2 ID is synchronized/communicated, new source L2 ID (#<NUM>), and possibly session ID (e.g., KD-sess ID #<NUM>), are used for the ongoing session. If a new peer L2 ID #<NUM> is synchronized, it is also used for the ongoing session as in block <NUM> A1. In blocks <NUM> A and <NUM> B, the privacy timer is restarted on the source WTRU (and optionally on the peer WTRU).

Some approaches to updating the L2 IDs and session ID associated with an ongoing session (e.g., block <NUM> A1 shown and described with respect to <FIG>) include the following and are detailed further herein.

In a new first method, (Method <NUM>), some examples include an exchange of new L2 IDs between source and target VIΓΓRUs. Such examples may include modification of an existing message (e.g., ProSe keepalive messages) to carry the new source L2 ID; e.g., to support concurrent exchange of new source and peer L2 IDs. In a further extension of Method <NUM>, termed Method <NUM> below, an exchange of new MSB of KD-sess ID and LSB of KD-sess ID as well as an exchange of new L2 IDs for the source and peer WTRUs may be supported. Such Method <NUM>- based examples and extensions may also or instead include introduction of new privacy messages and procedures to carry the new source L2 ID, e.g., to support concurrent exchange of new source and peer L2 IDs. , and/or to support exchange of new MSB of KD-sess ID and LSB of KD-sess ID for a new session ID. In some examples, a WTRU may request its peer to change its L2 ID, which may be referred to as peer triggering. Some examples modify the existing Re-keying messages to support concurrent exchange of new source and peer L2 IDs.

In a new second method, (Method <NUM>) some examples include generation of a peer's new L2 ID. In such examples, a source seed may be provided to a target WTRU and a target seed may be provided to the source VIΓΓRU. Such examples may include modification of an existing message (e.g., a ProSe keepalive message or PC5 direct link establishment message) to configure the seed to be used for the regeneration of the L2 ID on the peer WTRU. Such examples may also or instead include introduction of a new privacy message to exchange the seed or seeds. Such examples may also or instead update any other PC5 signaling messages to carry the "seed".

In a new third method, (Method <NUM>), briefly described above, the Method <NUM>, also introduced above, may be augmented with the exchange of new session IDs for greater privacy protection. In a new fourth method, (Method <NUM>), an existing re-keying procedure that also produces a new session ID may be enhanced with the exchange of new L2 IDs between communicating VIΓΓRUs.

Some examples described herein include privacy parameter and/or policy provisioning on the source WTRU and peer WTRU; e.g., using WTRU (or UE) Configuration Update (UCU) procedure and/or during PC5 link setup.

Some examples include privacy parameters provisioning. For example, provisioning and PC5 link setup procedures may be modified to support a privacy procedure. In some examples, the WTRU (source or target or both) is provisioned with a new privacy timer value and other parameters as described using the same mechanism used for eV2X provisioning, e.g., via a UCU procedure using a non-access stratum (NAS) transparent container, or a V3 interface, or a V2X App Server. A <NUM>-value configuration may disable the source L2 ID regeneration procedure. If no provisioning is provided, a default value may be used.

The WTRU may also be provisioned with a new privacy policy to be used by the WTRU to determine its behavior related to privacy protection. The privacy policy may be specified per V2X Application (e.g., Intelligent Transportation System-AID (ITS-AID) or (Provider Service Identifier (PSID)). The privacy policy may specify e.g., the Privacy Protection Methods (PPM) that are supported and may be identified by preference. For example, the following values may exist: PPM <NUM>: disabled - no privacy handling; PPM <NUM>; L2 ID privacy only using Method <NUM>, single UE L2 ID update; PPM <NUM>: L2 ID privacy only using Method <NUM>, both UEs' L2 ID update; PPM <NUM>: L2 ID privacy only using Method <NUM>, both UEs' L2 ID update; PPM <NUM>: L2 ID + session ID privacy using Method <NUM>; PPM <NUM>: L2 ID +session ID privacy using Method <NUM>; and/or other suitable values.

<FIG> is a sequence chart <NUM> illustrating an example of privacy parameter provisioning. In message <NUM>, the V2X Control Function (V2X) or Policy Control Function (PCF) <NUM> forwards the eV2X provisioning parameters to the AMF <NUM> in a policy container to configure the WTRU (noted in <FIG> as UE <NUM>). New eV2X specific parameters for the privacy support (e.g., privacy timer, seed value to generate the L2 ID, seed value to generate the privacy timer, and so forth) are added to the policy container with the existing parameters. A privacy policy may also be specified. In message <NUM>, AMF transfers the WTRU policy container to the WTRU using (R)AN <NUM>. This transfer may be considered "transparent" because the AMF transfers the WTRU policy container to the WTRU without reading or altering it. The eV2X parameters are saved locally on the UE at block <NUM> A. In message <NUM>, the WTRU sends the result of the WTRU policies delivery to the AMF. In message <NUM>, AMF notifies the V2X CF or PCF if it has registered to be notified of the reception of the WTRU policy container.

Some examples of privacy procedures include a direct link setup procedure updated with privacy parameters. In some examples, a direct link setup procedure is used to indicate to the other WTRU that the current session requires a change of L2 ID during an ongoing PC5 session. This may be achieved, for example, either by including a new indication in the direct communication request message and/or by passing the privacy timer value from the one WTRU to the other VIΓΓRU. A new privacy timer IE containing the privacy timer value may be introduced for this purpose. A new privacy indication IE may also be introduced and may be set to the provisioned value(s), for example PPM <NUM>, PPM <NUM>, PPM <NUM> (as described above). The PPM selection may be negotiated between the two VIΓΓRUs during the link setup. For example, the highest privacy protection supported by both sides may be selected. For example, a PPM <NUM>, PPM <NUM> and PPM <NUM> may be supported by originating WTRU and only PPM <NUM> and PPM <NUM> are supported on peer WTRU. Thus, PPM <NUM> (e.g., an L2 ID privacy only using method <NUM>, both VIΓΓRUs L2 ID update) is selected for this specific session. The selected PPM determines how the WTRUs behave during the lifetime of the session; i.e., it determines if privacy protection is applied, which method is used, if both peers update their L2 ID, if the session ID is updated, etc. On a given WTRU, different PPMs may be selected for different sessions based on the provisioned privacy policies and above negotiation process. For example, a WTRU may set up two sessions with another WTRU and may select a different PPM for each session (e.g., where each session is associated with a different V2X application and each application carrying its specific privacy policy). The peer WTRU may reject the link setup if no acceptable (e.g., common) PPM is found based on the provisioned values and the values proposed by the originating WTRU.

<FIG> is a sequence chart <NUM> illustrating an example of such a direct link setup procedure. Message <NUM> is a direct communication request, sent from a requesting or source VIΓΓRU <NUM> to a destination or target or peer WTRU <NUM>, that may include a privacy indication, the source WTRU privacy timer, and/or supported privacy policies. Message <NUM> is a direct communication accept sent in response to the request message from a destination or target or peer WTRU <NUM> to a requesting or source VIΓΓRU <NUM>, that confirms the privacy indication, the source WTRU privacy timer, and/or supported privacy policies sent in the request message. In some examples, the privacy timer value is passed to the other WTRU to inform that WTRU in advance that the L2 ID will change during the lifetime of the session; e.g., periodically. The VIΓΓRU receiving a privacy timer configuration from its peer can expect the change within the time specified by the privacy timer value. If the change does not occur within this period, the receiving WTRU may trigger the replacement of this ID; e.g., using the privacy procedure shown and described with respect to <FIG>.

An example of Method <NUM> referenced above is now described. Some examples of Method <NUM> include an exchange of new L2 identifiers. In some examples, WTRUs exchange their new L2 ID during the same procedure, or independently, one after the other. The privacy timer value may also be updated using this procedure.

In some examples, a ProSe direct link keepalive procedure is updated with a new source L2 ID. The ProSe direct link keepalive procedure can be re-used to change the L2 IDs associated with an ongoing session. New L2 ID IEs may be introduced. Existing keepalive messages may include the new L2 ID IEs, which may be set to the new source/target L2 ID values. A new privacy timer value may be provisioned on the VIΓΓRU (e.g., as shown and described with respect to <FIG>) and may be used as a new trigger (a) for the generation of the new L2 ID and (b) to initiate the keepalive procedure, which may include the newly obtained L2 ID IE.

<FIG> is a sequence chart <NUM> illustrating an example exchange of new L2 identifiers on a requesting or source WTRU <NUM> using an updated direct link keepalive procedure, triggered by the expiration of the privacy timer, to update the Source L2 ID of an existing session on the peer VIΓΓRU <NUM>. <FIG> represents an example of Method <NUM> where only the source L2 ID is changed. It is noted that the Keepalive procedure and messages are used for convenience to describe and illustrate the exchange of new source L2 ID. However, other PC5 signaling messages and procedures may be modified in a similar way and used to achieve the same result. In block <NUM>, V2X parameters are provisioned on the WTRUs <NUM> and <NUM> and a session is set up. In block <NUM>, the source WTRU <NUM> runs a privacy timer using the provisioned value. In block <NUM>, communication is ongoing using Source L2 ID #<NUM> (and peer L2 ID). In block <NUM>, the privacy timer expires on the source VIΓΓRU <NUM>, and the source L2 ID needs to be updated. In block <NUM> A, a new source L2 ID is generated (e.g., source L2 ID #<NUM>). In block <NUM> B, source WTRU initiates the keepalive procedure to send the new ID to the peer WTRU. The source VIΓΓRU sends a keepalive message <NUM> to the peer WTRU containing the new Source L2 ID in a new IE (e.g., Source_L2_ID_IE). The current source L2 ID is still used since this is the ID associated at this point with the session and this is the ID that the peer knows/expects to be used. A new privacy timer value may also be configured on the peer WTRU. The peer WTRU receives the new source L2 ID associated with the session and saves it locally. Both L2 IDs (former and new) may be saved locally in case messages using the former ID are in transit during the ID modification procedure. The peer WTRU stops the keepalive timer at block <NUM> and sends back a keepalive ACK message <NUM> including the new source L2 ID IE (e.g., Source_L2_ID_IE) set to the same value as received with the keepalive message. The former L2 ID is still used as the destination ID for this message. The old source L2 ID may be deleted from local memory after a message using the new L2 ID is received or, e.g., after a grace period. In step 4c, the keepalive timer is restarted on both sides. In blocks <NUM> A and <NUM> B, a new source L2 ID is synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with the upper layer aware of which VIΓΓRU ID is used and with AS layer which uses L2 ID for PC5 communication). In block <NUM>, the source WTRU restarts the privacy timer since source L2 ID needs to be changed periodically. In block <NUM>, the new source L2 ID is used from this point on, from both sides.

In some examples, both WTRUs update their L2 IDs during the same procedure. In such examples, the target WTRU may decide to update its L2 ID at the same time as the source WTRU; e.g., when receiving a keepalive message. <FIG> is a sequence chart <NUM> illustrating an example of this Method <NUM> exchange where both L2ID are changed in both requesting/source VIΓΓRU <NUM> and the peer/destination WTRU <NUM>. The exchanges in <FIG> are similar to the ones previously described with respect to <FIG>, with some changes as shown in <FIG>.

For example, block <NUM> and <NUM> are the same as in <FIG>. Block <NUM> A and <NUM> B indicates a privacy timer is stated in both WTRUs. In blocks <NUM> A and <NUM> B, the privacy timer expires on the source and peer WTRUs and the L2IDs need to be updated. In blocks <NUM> A1 and <NUM> B1, new L2IDs are generated on both WTRUs (e.g., source L2 ID #<NUM>, peer L2 ID #<NUM>). In block <NUM> A2, the source WTRU initiates the keepalive procedure to send its new ID to the Peer WTRU. The source WTRU sends a keepalive message <NUM> containing its new L2 ID in a new IE (e.g., Source_L2_ID_IE). The current source L2 ID is still used since this is the ID associated at this point with the session and this is the ID that the peer knows/expects to be used. A new privacy timer value may also be configured on the source/peer VIΓΓRU. The peer WTRU receives the new source L2 ID and saves it locally. Both L2 IDs (former and new) may be saved locally in case messages using the former ID are in transit during the ID modification procedure. The peer WTRU stops the keepalive timer at block <NUM> since a keepalive message has been received. The peer WTRU sends back a response message <NUM> including the new source L2 ID IE set to the same value as received with the keepalive message (i.e., source L2 ID #<NUM>). It also includes its new ID in another new IE (e.g., target_L2_ID_IE). The former L2 IDs are still used as the source/destination IDs for this message. After receiving the response message, the source WTRU replies with an acknowledgement message <NUM> which includes the new target L2 ID IE. However, the former L2 ID of the target is still used as the destination ID for this message. In block <NUM> A and <NUM> B, new source/peer L2IDs are synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with upper layer aware of which VIΓΓRU ID is used and with an AS layer which uses L2 ID for PC5 communication). In blocks <NUM> A and <NUM> B, both WTRUs restart the privacy timer since source L2 ID needs to be changed periodically. The keepalive timer is also restarted. In block <NUM>, the new L2 IDs are used from this point on, from both sides. In some examples, a new ProSe direct link privacy procedure is introduced. In such examples, a new dedicated Direct Link Privacy procedure is used to modify the source L2 ID associated with the session. The new privacy procedure uses its own privacy timer and privacy messages (e.g., Privacy_Request, Privacy_Response, Privacy_Trigger). The privacy procedure may be initiated from the source VIΓΓRU or the peer WTRU. The procedure may be used to update a L2 ID of a single WTRU or L2 IDs of both VIΓΓRUs.

In some examples, the source WTRU initiates the privacy procedure for a single L2 ID change. <FIG> is a sequence chart <NUM> illustrating an example of such a privacy procedure. In this example, the source WTRU has been provisioned with the privacy timer value. At timer expiration, the WTRU obtains a new L2 ID and updates its peer WTRU with the new L2ID. <FIG> represents one example of a newly defined privacy procedure using a direct link privacy communication between two WTRUs corresponding to one option of Method <NUM>.

In block <NUM>, V2X parameters are provisioned on the WTRUs and a session is set up. In block <NUM>, the source WTRU starts a privacy timer using the provisioned value. At block <NUM>, communication is ongoing between the source and peer WTRUs. In block <NUM>, the privacy timer expires on the source WTRU. In block <NUM> A1, the source VIΓΓRU generates a new source L2 ID (e.g., source L2 ID #<NUM>). At block <NUM> A2, the privacy procedure is initiated. The source WTRU sends a Privacy_Request message <NUM> including the new source L2 ID IE. A new privacy timer value IE may also be specified, if the timer value needs to be changed. The peer WTRU receives the new source L2 ID of its peer and saves it locally. The peer WTRU sends back a Privacy_Response message <NUM> including the new source L2 ID IE set to the same value as received with the Privacy_Request message <NUM>. At blocks <NUM> A and <NUM> B, a new source L2 ID is synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with upper layer aware of which WTRU ID is used and with AS layer which uses L2 ID for PC5 communication). At block <NUM>, the source WTRU restarts the Privacy timer, at block <NUM>, the new source L2 ID may be used from this point on.

In some examples, both L2 IDs are updated during the same procedure. <FIG> is a sequence chart <NUM> illustrating an example of such a procedure. In this example, the peer WTRU updates its L2 ID at the same time as the source WTRU, and exchange of new L2 IDs is done during the same procedure. <FIG> represents one example of a newly defined privacy procedure using a direct link privacy communication between two WTRUs corresponding to another option of Method <NUM> where both WTRUs update their L2 IDs in the same procedure.

In block <NUM>, V2X parameters are provisioned on the VIΓΓRUs and a session is set up. In blocks <NUM> A and <NUM> B, the source VIΓΓRU <NUM> and peer VIΓΓRU <NUM> start a privacy timer using the provisioned value. In block <NUM>, communication is ongoing between the source VIΓΓRU and peer WTRU. In blocks <NUM> A and <NUM> B, the privacy timer expires on the source WTRU, and possibly on the peer VIΓΓRU. In block <NUM> A1, the source WTRU generates a new Source L2 ID (e.g., source L2 ID #<NUM>). The source WTRU sends a Privacy_Request message <NUM> including the new source L2 ID IE and optionally a new privacy timer IE if the timer value needs to be updated. The peer WTRU receives the new source L2 ID of the source WTRU and saves it locally. At block <NUM> B1, the peer WTRU generates a new peer L2 ID (e.g., peer L2 ID # <NUM>) (a) when privacy timer expires (block <NUM> B) or optionally (b) at reception of Privacy Request message <NUM>. The peer WTRU sends back a Privacy_Response message <NUM> including the new source L2 ID IE set to the same value as received with the Privacy Request message and including its new peer L2 ID as well. Optionally a new privacy timer IE may be included if the peer timer value needs to be updated. The source VIΓΓRU receives a Privacy Response message <NUM> which includes a new peer WTRU L2 ID IE, saves this new ID locally, and replies with a Privacy ACK message <NUM> which includes the new peer L2 ID. At blocks <NUM> A and <NUM> B, new L2 IDs are synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with the upper layer aware of which VIΓΓRU ID is used and with AS layer which uses L2 ID for PC5 communication). In blocks <NUM> A and <NUM> B, each WTRU restarts its privacy timer. In block <NUM>, the new L2 IDs are used from this point on.

In some examples, a WTRU triggers a privacy procedure at the peer side. For example, a WTRU may request its peer to change its L2 ID (e.g., the peer WTRU requests the source WTRU to change its L2 ID - i.e., the source L2 ID). The source VIΓΓRU receiving such a request may trigger the L2 ID update procedure. In this case, the source VIΓΓRU obtains a new L2 ID and updates its peer WTRU with the new L2 ID. The peer WTRU, which has been configured with the source WTRU privacy timer value during link setup procedure, may decide to trigger the source VIΓΓRU L2 ID change; e.g., if (a) it receives a trigger locally (e.g., from upper layer) or it determines that the source L2 ID should be changed (e.g., for any suitable reason or additional trigger) or (b) the peer WTRU wants to update its own L2 ID at the same time as the source WTRU.

<FIG> is a sequence chart <NUM> illustrating an example Method <NUM> procedure where the peer WTRU triggers the L2 ID change procedure. In block <NUM>, a session is set up and communication is ongoing between the source VIΓΓRU <NUM> and peer VIΓΓRU <NUM>. In blocks <NUM> A and <NUM> B, both WTRUs may begin a privacy timer. At block <NUM>, communication is ongoing between the source WTRU and peer WTRU. In block <NUM>, the peer WTRU determines that the source WTRU should change its L2 ID and the peer L2 ID may possibly need to be changed as well. The peer WTRU sends a new Privacy_Trigger message <NUM> to the source WTRU. The peer WTRU may generate a new L2 ID if its L2 ID needs to be updated at optional block <NUM> B1. Otherwise, the source VIΓΓRU receiving this trigger message <NUM> stops its privacy timer at block <NUM>. In block <NUM> A1, new source L2 ID is generated (e.g., source L2 ID #<NUM>). In block <NUM> A2, the source WTRU initiates the privacy procedure to send its new ID to the peer WTRU. The direct privacy messages are exchanged in block <NUM>. Alternatively, the source WTRU may use the keepalive procedure, e.g., as shown and discussed with respect to <FIG>, to send the new source L2 ID to the peer WTRU. Procedures as shown and described with respect to <FIG> and <FIG> may be used if only the source L2 ID is changed. Procedures as shown and described with respect to <FIG> and <FIG> may be used if both L2 IDs are changed. In blocks <NUM> A and <NUM> B, new L2 IDs are synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with the upper layer aware of which WTRU ID is used and with an AS layer which uses L2 IDs for PC5 communication). In blocks <NUM> A and <NUM> B, the privacy timer is restarted on the both WTRUs. In block <NUM>, communication is ongoing using the new source L2 ID #<NUM> and the new peer L2 ID #<NUM> if it has changed.

An example Method <NUM> L2 ID change includes generation of peer L2 IDs on source and target WTRUs. In some Method <NUM> examples, the peer L2 ID is regenerated from the source WTRU itself instead of exchanging the new ID via messages. In such examples, each WTRU may be provisioned with a list of possibly secret parameters, and seeds, during the provisioning of V2X parameters stage along with the other necessary V2X parameters. The seeds may be used for the regeneration of the L2 ID of the WTRU.

After the session is established between a source WTRU and peer WTRU, and after the security keys are exchanged and the communications are secured, the source VIΓΓRU and peer WTRU may exchange their privacy timer value and a seed. Accordingly, a WTRU is configured with its peer's (a) privacy timer value and (b) a seed to be used for the new L2 ID regeneration.

The same seed or another seed (e.g., provisioned for generating the timer) value may be used by the WTRU to generate the privacy timer. If a different seed is used to generate the timer value, such seed value may also be exchanged between the WTRUs. The seed value for the timer may facilitate randomization of the timer value for changing the privacy timer.

In some examples, a list of seeds, potentially with corresponding timers, may be configured on both sides and exchanged during the same procedure. This described procedure may reduce or limit the message exchange over the air. The seed used to generate a new L2 ID of the target WTRU may be chosen in a consecutive manner from the list of seeds provided after the privacy timer expires. The WTRU starts a peer_privacy_timer, and when the timer expires, it regenerates its peer L2 ID based on the configured seed. At the same time, the peer WTRU also regenerates its own L2 ID using the same seed, and the same value is obtained. The generation of the new L2 ID of the target WTRU may be periodic. The seed and timer value may be configured on the peer WTRU using an updated keepalive mechanism, any other updated PC5 signaling messages, or new messages.

<FIG> is a sequence chart <NUM> illustrating an example Method <NUM> procedure where the source WTRU configures the peer WTRU to be able to regenerate the source L2 ID after a timer expires. Such mechanisms may be used from the destination WTRU to the source WTRU. In <FIG>, the source L2 ID is regenerated on the source WTRU and the peer WTRU. In block <NUM>, a session is set up between the source WTRU and the peer WTRU. In block <NUM>, communication between the source VIΓΓRU and the peer WTRU is ongoing. "Source L2 ID #<NUM>" is used at this point. In block <NUM> A, a privacy timer is started on the source WTRU. In block <NUM>, the privacy timer and a seed are sent to the peer WTRU (e.g., using either an updated keepalive mechanism or new messages). The timer may indicate, for example, a <NUM>-minute duration and a specific start time. In this example, the timer will expire every <NUM> minutes past the specified start time. This may facilitate expiration of the timers on both sides at the same time, even though they are not started at the same time. In block <NUM> A, the peer WTRU saves the source WTRU privacy timer value and seed and starts a source WTRU privacy timer. The procedures used to exchange info, e.g., as shown and described with respect to <FIG> and <FIG>, may be used here, however, the privacy timer + seed are transported in this case (new IE for seed). In blocks <NUM> A and <NUM> B, after timer expiry, the source WTRU uses the seed that has been shared with its peer to generate a new L2 ID. In blocks <NUM> A1 and <NUM> B1, on the target WTRU, the timer has expired at the same time as on the source WTRU. The target WTRU uses the seed value received from the source VIΓΓRU to regenerate a new source VIΓΓRU L2 ID. The same value for the source L2 ID is obtained on both WTRUs. In blocks <NUM> A and <NUM> B, the new source L2 ID is synchronized/communicated across layers on both WTRUs for PC5 communication (e.g., with the upper layer aware of which WTRU ID is used and with an AS layer which uses L2 ID for PC5 communication). In blocks <NUM> A and <NUM> B, the privacy timer is restarted on both WTRUs. In block <NUM>, communication is ongoing between the source WTRU and the peer WTRU based on the newly formed source L2 ID #<NUM>.

In some examples, an updated keepalive mechanism (e.g., as shown and described with respect to <FIG>) or new messages (e.g., as shown and described with respect to <FIG>) may be used to exchange the privacy timer value and seed. The timer value and seed may be updated regularly and/or periodically.

<FIG> is a sequence chart <NUM> illustrating (A) a WTRU <NUM> configuring its privacy timer value & seed on the peer VIΓΓRU <NUM> and (B) both WTRUs exchanging their configuration. <FIG> illustrates a Method <NUM> exchange of privacy timer value and seeds. Sequence A is an example message exchange where the requesting/source WTRU sends its privacy timer and seed values to the per WTRU. At sequence A, in message <NUM>, a WTRU <NUM> sends a direct communication keepalive, direct privacy request, or other message that contains relevant information for the transfer of WTRU <NUM> privacy timer and seed values to the peer VIΓΓRU <NUM>. After receipt, the peer WTRU <NUM> transmits a response message <NUM> which may be an acknowledgement of the received request message <NUM>. The acknowledgement message <NUM> may include the source WTRU privacy timer value and source seed value among other possible message content. Sequence B may be an alternative to sequence A. Sequence B is an example message exchange where both WTRUs exchange their respective privacy timer and seed values. At sequence B, in message <NUM>, a WTRU <NUM> sends a direct communication keepalive, direct privacy request, or other message that contains relevant information for the transfer of VIΓΓRU <NUM> privacy timer and seed values to the peer VIΓΓRU <NUM>. After receipt, peer VIΓΓRU <NUM> transmits a response message <NUM> which may be a response of the received request message <NUM>. The response message <NUM> may include the source WTRU privacy timer value and source seed value and the peer privacy timer and peer seed value among other possible message content. After receipt of the response message <NUM>, the source WTRU <NUM> may transmit message <NUM> which may be a direct communication keepalive acknowledgement, direct privacy acknowledgement, or other message that contains relevant information for the transfer of peer WTRU <NUM> privacy timer and seed values back to the peer VIΓΓRU <NUM>. The above exchange examples A and B may establish a configuration for the WTRUs as in block <NUM> of <FIG> of Method <NUM>.

An example Method <NUM> may augment the exchange of new L2 identifiers with an exchange of a new session ID. In one example, Method <NUM> augments Method <NUM> with the exchange of a new session ID. For example, as described above, WTRUs may exchange their new session ID during the L2 ID change procedure, independently (i.e., one after the other) or simultaneously during the same procedure. Further, a WTRU may be configured to update its security context identifier (e.g., session identifier) at the same time as its L2 ID, e.g., for privacy reasons. To facilitate this, the exchange of new L2 identifiers discussed above is augmented with additional privacy protection by enabling the exchange of the MSB/LSB of KD-sess ID in addition to the source and destination L2 IDs.

In a first scenario, the initiating/requesting/source WTRU may have a privacy timer running. If the privacy timer expires, or if a trigger is received from the peer WTRU, the initiating/requesting/source VIΓΓRU fetches the security context associated with the session and executes the L2 ID update procedure (e.g., as discussed above regarding ProSe direct link keepalive procedure updated with new source L2 ID, or where the source WTRU initiates a privacy procedure with a single L2 ID change. In addition to the L2 ID regeneration, the WTRU may generate a new session identifier (i.e., MSB of KD-sess ID). This new session ID may be sent to the peer WTRU along with the new L2 ID. It is noted that the communication is already secured, i.e., the exchanged L2 ID and session ID are encrypted, and integrity protected. The new identifiers are used when the procedure is successfully completed. It is noted that the security context content per se is not modified, i.e., the keys and other parameters (e.g., counter) saved in the security context are still the same, only the session identifier, used to locate the security context locally on the initiating/requesting/source VTRU and peer/destination WTRU (i.e., on each peer VTRU), is updated.

In a second scenario, both VTRUs update their IDs during the same procedure, that is, both L2 IDs are updated during the same procedure and both WTRUs change their portion of the session identifier at the same time; during the same privacy procedure. In this case, both WTRUs generate a new portion of the session ID (MSB and LSB) and exchange them along with their new L2 ID. This is illustrated in <FIG>, using Direct Privacy messages. <FIG> is a message sequence chart <NUM> illustrating a case where both WTRUs exchange their new portion of the session ID using the privacy procedure.

In the example of <FIG>, communication is ongoing between source WTRU <NUM> and peer WTRU <NUM> in block <NUM>, where the source WTRU is using L2 ID #<NUM> and the peer WTRU is using its own L2 ID #<NUM>. A security association, identified by the session ID (KD-sess ID #<NUM>) has been established between the WTRUs; i.e., each WTRU has saved locally a security context containing the required security parameters (e.g., encryption keys) to secure the communication. All information exchanged between the peers is encrypted and integrity protected. The initiating WTRU uses the MSB of KD-sess ID to locate the security context and the peer WTRU uses the LSB of KD-sess ID on its side.

In block <NUM>, a privacy timer expires on source WTRU. The source VIΓΓRU generates a new Source L2 ID (e.g., source L2 ID #<NUM>) in block <NUM> A, and the source WTRU generates a new MSB of KD-sess ID (e.g., MSB of KD-sess ID #<NUM>) in block <NUM> B. The source WTRU sends a Privacy_Request message <NUM> or another PC5 Signaling message (e.g., a PC5 Link Update message including the new Source L2 ID IE and new MSB of KD-sess ID IE) and optionally a new privacy timer IE.

The peer WTRU receives the new source L2 ID and new MSB of KD-sess ID of message <NUM> and saves them locally, to eventually replace the previous values currently in use. In block <NUM> A, the peer WTRU generates a new peer L2 ID (e.g., peer L2 ID #<NUM>). In block <NUM> B, the peer WTRU generates a new LSB of KD-sess ID (i.e., LSB of KD-sess ID # <NUM>). In block <NUM> C, the peer WTRU saves its newly generated identifiers locally. The security context is updated locally with the KD-sess ID #<NUM>.

The Peer WTRU sends back (to the source WTRU) a Privacy_Response message <NUM> or another PC5 Signaling message (e.g., PC5 Link Update Response message) including the new source L2 ID IE and new source MSB of KD-sess ID IE set to the same values as received with the Privacy Request message and including its new peer L2 ID IE and new peer LSB of KD-sess ID IE as well. In another embodiment, the peer WTRU does not send back the new source L2 ID IE and new source MSB of KD-sess ID IE with the source WTRU expected to retrieve them locally based on current session context. For example, the source WTRU may store these in the security context identified by current source MSB of KD-sess ID at the time they were generated. In block <NUM>, the source WTRU, receiving a Privacy Response message <NUM>, which includes the new peer L2 ID IE and new peer LSB of KD-sess ID IE, saves these new IDs locally and replies with a Privacy Ack message <NUM> which includes the new peer L2 ID and new LSB of KD-sess ID. In block <NUM>, the new L2 IDs and of KD-sess ID (MSB and LSB) are used from this point onward.

An example Method <NUM> may enhance existing re-keying procedures with the exchange of new L2 IDs. In one example, Method <NUM> an existing re-keying procedure may be enhanced with the exchange of new L2 IDs between communicating WTRUs. The existing re-keying procedure is used to update the security context of an ongoing session. In this case, all parameters are updated, e.g., keys are regenerated, counters are reset, and a new session ID is generated as well.

As an alternative to various approaches discussed herein, this approach uses an existing re-keying procedure (e.g., as discussed in 3GPP TS <NUM><NUM>. <NUM>) and enhances it with the possibility of exchanging the new source and destination L2 IDs between the peer WTRUs, along with the new session ID. As for other approaches discussed herein, a privacy timer may be used to trigger this enhanced re-keying procedure. Other triggers may also exist, (e.g., from upper layers, a request from peer WTRU, before the counter for current link repeats with current keys, etc.).

It is noted that the re-keying procedure may imply a change of the complete session ID, i.e., MSB and LSB portions, and may be done using the already established session. Thus, all messages exchanged between the peers are encrypted and integrated protected. The change of L2 ID may however be done on a single WTRU only, if needed, or both VIΓΓRUs.

<FIG> is a message sequence chart <NUM> illustrating exchange of new L2 IDs using an enhanced re-keying procedure. <FIG> provides an example use of Method <NUM> which provides for an exchange of L2 IDs of both the source and peer WTRUs in the context of a re-keying procedure. In block <NUM>, communication is ongoing between source and peer WTRUs. The source VIΓΓRU <NUM> is using L2 ID #<NUM> and the peer WTRU <NUM> is using its own L2 ID #<NUM>. A security association, identified by the session ID (KD-sess ID #<NUM>) has been established between the source and peer WTRUs (e.g.. , each WTRU has locally saved a security context containing the required security parameters e.g., encryption keys) to secure the communication.

In block <NUM>, a privacy or re-keying timer expires on source WTRU (or another trigger occurs, e.g., from the upper layer). The source WTRU triggers the re-keying procedure enhanced with the L2 ID update exchange. In block <NUM> A, the source WTRU generates a new Source L2 ID (e.g., source L2 ID #<NUM>). In block <NUM> B, the source WTRU generates a new MSB of KD-sess ID (i.e., MSB of KD-sess ID #<NUM>). The source VIΓΓRU sends a DIRECT_REKEYING_REQUEST message <NUM> including the new Source L2 ID IE and new MSB of KD-sess ID, and optionally a new privacy timer IE. The existing security context and L2 IDs are still used to send this message, i.e., the old source/destination L2 ID and existing KD-sess ID.

The peer WTRU receives the new source L2 ID and new MSB of KD-sess ID of the source WTRU via message <NUM> and saves them locally, along with the previous values. In block <NUM> A, the peer WTRU generates a new peer L2 ID (e.g., peer L2 ID # <NUM>). In block <NUM> B, the peer WTRU generates a new LSB of KD-sess ID (i.e., LSB of KD-sess ID # <NUM>). In block <NUM> C, the WTRU saves its newly generated identifiers locally. The security context is updated locally with the KD-sess ID #<NUM> however the old KD-sess ID #<NUM> is kept and used at this point, as well as the old source/destination L2 IDs.

The peer WTRU sends back (to the source WTRU) a DIRECT_SECURITY_MODE_COMMAND message <NUM> including the new source L2 ID IE and new source MSB of KD-sess ID IE set to the same values as received with the DIRECT_REKEYING_REQUEST message <NUM> (to acknowledge them) and including its new peer L2 ID IE and new peer LSB of KD-sess ID IE as well. In another embodiment, the peer WTRU does not send back the new source L2 ID IE and new source MSB of KD-sess ID IE with the source WTRU expected to retrieve them locally based on current session context. For example, the source WTRU may store these in the security context identified by current source MSB of KD-sess ID at the time they were generated.

In block <NUM>, after the source WTRU, receiving a DIRECT_SECURITY_MODE_COMMAND message <NUM>, which specifies the peer WTRU's new L2 ID IE and peer WTRUs new LSB of KD-sess ID IE, saves these new IDs locally. A security association is updated with KD-sess ID #<NUM>. New keys are generated. The source WTRU replies by transmitting a DIRECT_SECURITY_MODE_COMPLETE message <NUM> which repeats the peers new L2 ID and new LSB of KD-sess ID (i.e., acknowledging them). The Peer WTRU, receiving a DIRECT_SECURITY_MODE_COMPLETE message <NUM> acknowledging its new L2 ID and LSB of KD-sess ID, replies by sending back a DIRECT_REKEYING_RESPONSE message <NUM> which completes the procedure. In block <NUM>, from this point on, the new L2 IDs and security context, i.e., KD-sess ID (MSB and LSB) and keys are used.

It is noted that for convenience, most of the procedures in this document are described from the perspective of interactions between the VIΓΓRUs from the V2X layer/NAS layer or upper layers. The same procedures may also be applicable at the level of RRC signaling exchange between the WTRUs or when PC5 messages are exchanged over the RRC protocol.

It is noted that various figures expressed herein are related to one another and as such share common procedural elements. For example, the Method <NUM> example procedure of <FIG> share common setup procedures. In a more global example, the procedures of <FIG> are all variations of Method <NUM> which includes exchanges of new L2 IDs between source and peer WTRUs. In addition, <FIG> is a Method <NUM> that is enhanced using the feature of new session ID generation using a new MSB of session ID from a source WTRU and a new LSB of session ID from a peer WTRU. <FIG> illustrates a logical combination of such shared procedures from the perspective of a source WTRU. In <FIG>, the procedures of <FIG>, <FIG>, and <FIG> are shown highlighting the options that may be exercised using Method <NUM>. Other variations of the expressed examples are possible using techniques expressed herein. Specifically, as shown in <FIG>, the common operations of Method <NUM> shown in the detailed examples of <FIG>, <FIG>, and <FIG> are presented. <FIG> addresses the Method <NUM> options of (i) a communication between the source and peer WTRU is updated with only a new source L2 ID (reference <FIG>), (ii) a communication between the source and peer WTRU updated with both a new source L2 ID and a new peer L2 ID, or (iii) a communication between the source and peer VIΓΓRU updated with the both the new source L2 ID and the peer L2 ID as well as contributions of MSB and LSB of session ID from the source and peer WTRU respectively to communicate using a new session ID.

<FIG> is a procedure <NUM> with options that may be exercised by a source WTRU conducting the principles of Method <NUM> described herein. At block <NUM>, a source WTRU is assumed to have an ongoing communication with a peer WTRU. In one example environment, the communication is a PC5 reference link communication in a V2X operation where each WTRU has access to a V2X application that includes the privacy application provisions described herein. At block <NUM>, a trigger event is detected. Such a trigger event drives the reaction of the source WTRU to conduct the operations of blocks <NUM> through <NUM>. Such a trigger event may be a detected condition and may include a timer that expires on the WTRU, or an upper layer or an application layer of a V2X application that requests a new L2 ID, or the source WTRU moving into a new geographic area, or the source VIΓΓRU receiving new provisioning parameters from the V2X control function or from a V2X application server, or the source VIΓΓRU receiving a request from the peer WTRU to change an L2 ID.

At block <NUM>, on a condition that the trigger event occurred, the source WTRU may generate a new L2 ID for future communications with the peer WTRU. This is similar to the example block <NUM> A of <FIG> which uses Method <NUM>. Optionally, at block <NUM>, the WTRU may also generate a new MSB for a new session ID. This option is a variation of Method <NUM> which is similar to example block <NUM> B of <FIG>. Both <FIG> and <FIG> share common operational elements as variations of Method <NUM>. At block <NUM> of <FIG>, The source WTRU communicates, via message transmission to the peer WTRU, the value of the new source L2 ID for use by the peer WTRU. This Method <NUM> operation, also shown in <FIG> example message <NUM> as an example direct communication keepalive type message. But, as taught above, such messages may be of any commonly known and used messages between WTRUs or may be a specialized message such as a direct privacy request message between WTRUs. At block <NUM> in <FIG>, the communication between WTRUs may optionally also transfer not only the new L2 ID of the source WTRU, but also the new MSB for a new session ID. This option is a Method <NUM> variation shown in <FIG> example message <NUM> as a direct privacy request type message.

At block <NUM>, the source VIΓΓRU receives a message from the peer WTRU. The message responds to the new source ID and may contain a confirmation of the new source L2 ID from the peer VIΓΓRU. Such an example of the Method <NUM> operation is shown in <FIG> example message <NUM> as a keepalive acknowledge message. However, as mentioned above, the message type may be any message type that is used between WTRUs including a new direct privacy communication message. Optionally at block <NUM> of <FIG>, if the Method <NUM> operation includes the generation of a new peer WTRU L2 ID, as in the Method <NUM> operation of <FIG>, then the message at block <NUM> may include both a confirmation of the new source L2 ID and the new peer VIΓΓRU L2 ID. The message that includes both the new source and the new peer L2 IDs is a variation of Method <NUM> shown in <FIG> example message <NUM>. A third option for block <NUM> of <FIG> includes the Method <NUM> variation shown in <FIG> which includes information of the new source L2 ID, the new peer L2 ID, the new MSB for a new session ID, and a new LSB from the peer WTRU for use in a new session ID. The source WTRU, in the option of using a new session ID, after having received the New MSB and LSB would generate a new session ID for the communication between the source VIΓΓRU and the peer WTRU as is described with regard to <FIG>.

At block <NUM>, the source WTRU may communicate with the peer WTRU using or based on the new source L2 ID. This action is included in a Method <NUM> operation as shown in example block <NUM> of <FIG>. As an option, if the Method <NUM> operation includes a change of both the source and the peer L2 IDs as in the Method <NUM> operation of <FIG>, then block <NUM> of <FIG> allows the source WTRU to communicate with the peer WTRU using the new source L2 ID, and the new peer L2ID. This operation is also shown in the Method <NUM> operation of <FIG> example block <NUM>. In block <NUM> of <FIG>, a further Method <NUM> option is for the source WTRU to communicate with the peer WTRU using the new source L2 ID, the new peer L2 ID, and a new session ID that includes the MSB contribution from the source WTRU and the LSB contribution from the peer WTRU. This Method <NUM> operation is shown in <FIG> example block <NUM>.

Thus, Method <NUM> is shown as having some common operations that allow different variations according to whether the communication between the source and peer WTRU is updated with only a new source L2 ID, updated with both the new source L2 ID and the peer L2 ID, or updated with the both the new source L2 ID and the peer L2 ID as well as contributions of MSB and LSB from the source and peer WTRU respectively to communicate with a new session ID.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random-access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, when referred to herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described infra; (ii) any of a number of embodiments of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described infra; or (iv) the like.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. " Further, the terms "any of" followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of" the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having <NUM>-<NUM> cells refers to groups having <NUM>, <NUM>, or <NUM> cells. Similarly, a group having <NUM>-<NUM> cells refers to groups having <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> cells, and so forth.

A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer. The WTRU may be used m conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

Throughout the disclosure, one of skill understands that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

Claim 1:
A method for use in an ongoing vehicle-to-everything, V2X, session, the method comprising:
communicating (<NUM>) between a source wireless transmit/receive unit, WTRU, and a peer WTRU using an existing source WTRU layer <NUM>, L2, identifier, ID, an existing peer WTRU L2 ID, and an existing session ID for an existing session having an existing security context;
on a condition that a trigger event occurs:
generating (1302A, 1302B), by the source WTRU, a new source WTRU L2 ID and a new most significant byte of a new session ID;
transmitting (<NUM>), by the source WTRU to the peer WTRU, the new source WTRU L2 ID and the new most significant byte of the new session ID;
receiving (<NUM>), from the peer WTRU, a new peer L2 ID and a new least significant byte of the new session ID;
transmitting (<NUM>), by the source WTRU to the peer WTRU, an acknowledgement of the new peer WTRU L2 ID and the new least significant byte of the new session ID; and
communicating (<NUM>) with the peer WTRU using the new source WTRU L2 ID, the new peer WTRU L2 ID, and the new session ID that comprises the new most significant byte and the new least significant byte, wherein the communication with the peer WTRU occurs in the existing session using the existing security context.