UE and communication method

Abstract

To provide a communication system that can reduce security risks in communication.SOLUTION: A communication system (100) includes first UE (User Equipment) (110) that transmits a message including an L2ID (Layer 2 Identity) and verification information, and second UE (120) that receives the message from the first UE (110) and uses the verification information to determine whether to accept the L2ID.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a communication system, a user equipment, a communication method, and a computer-readable medium. [Background technology]

[0002] There have been developments in mobile communication technologies, such as Release 14 and Release 15 of the 3GPP (3rd Generation Partnership Project) that define Vehicle-to-Everything (V2X) communication in Long Term Evolution (LTE).

[0003] Regarding V2X communication, Non-Patent Document 1 describes research into the security aspects of LTE support for V2X services, and points out the risk of vehicles being tracked and privacy being violated. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] 3GPP TS 33.185: “Security aspect for LTE support of Vehicle-to-Everything (V2X) services”, 2017 Summary of the Invention [Problem to be solved by the invention]

[0005] In consideration of the above circumstances, an object of the present disclosure is to provide a communication system, a user equipment, a communication method, and a computer-readable medium that can reduce security risks in communications. [Means for solving the problem]

[0006] In a first exemplary embodiment, a communication system includes: a first UE (User Equipment) that transmits a message including a Layer 2 Identity (L2ID) and verification information; a second UE that receives the message from the first UE and determines whether to accept the L2 ID using the verification information.

[0007] In a second exemplary aspect, a UE (User Equipment) a sending means for sending a message including an L2 ID and verification information to another UE; The validation information allows another UE to determine whether to accept the new L2 ID.

[0008] In a third exemplary aspect, a UE (User Equipment) receiving means for receiving a message including an L2 ID and verification information from another UE; and a determination means for determining whether or not to accept the L2ID using the verification information.

[0009] In a fourth exemplary aspect, a communication method includes: sending a message to the UE including the L2 ID and verification information; The verification information is a way for the UE to determine whether to accept the new L2 ID.

[0010] In a fifth exemplary aspect, a communication method includes: receiving a message including an L2 ID and verification information from the UE; The verification information is used to determine whether to accept the L2 ID.

[0011] In a sixth exemplary embodiment, a non-transitory computer-readable medium comprises: causing a computer to perform a process of sending a message including the L2 ID and verification information to the UE; The verification information enables the UE to determine whether to accept the new L2 ID. A non-transitory computer-readable medium that stores a program.

[0012] In a seventh exemplary embodiment, a non-transitory computer-readable medium comprises: receiving a message from the UE, the message including an L2 ID and verification information; a process of determining whether to accept the L2ID using the verification information; It is a non-transitory computer-readable medium that stores a program for causing a computer to execute the above. [Effects of the Invention]

[0013] According to the present disclosure, it is possible to provide a communication system, a user equipment, a communication method, and a computer-readable medium that can reduce security risks in communications. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram of a communication system. [Figure 2] FIG. 2 is a sequence diagram showing the procedure of the communication system. [Figure 3] FIG. 3 is a diagram illustrating an example of a KDF function on the transmitting side. [Figure 4] FIG. 4 is a diagram illustrating an example of a KDF function on the receiving side. [Figure 5] FIG. 5 is a diagram illustrating an example of a KDF function on the transmitting side. [Figure 6] FIG. 6 is a diagram illustrating an example of a KDF function on the receiving side. [Figure 7] FIG. 7 is a sequence diagram showing the procedure of the communication system. [Figure 8] FIG. 8 is a sequence diagram showing the procedure of the communication system. [Figure 9A] FIG. 9A is a diagram showing a repetition message from a source UE. [Figure 9B] FIG. 9B is a diagram showing a relay message from the UE. [Figure 9C]FIG. 9C illustrates a flooded message from a UE. [Figure 9D] FIG. 9D is a diagram illustrating a combination of repeated, relayed, and flooded messages from a UE. [Figure 10] FIG. 10 is a diagram illustrating an example of a KDF function for deriving a new sequence number. [Figure 11] FIG. 11 is a sequence diagram illustrating the mechanism for re-establishing an L2 ID. [Figure 12] FIG. 12 is a sequence diagram illustrating the mechanism for providing a "default" L2 ID. [Figure 13] FIG. 13 is a diagram showing a mobile communication system 1. [Figure 14] FIG. 14 is a block diagram showing the main components of the UE 3. [Figure 15] FIG. 15 is a block diagram illustrating the major components of an exemplary (R)AN node 5. [Figure 16] FIG. 16 is a block diagram illustrating the main components of an exemplary core network node. DETAILED DESCRIPTION OF THE INVENTION

[0015] Before describing the embodiments of the present disclosure, the following description will be given.

[0016] (abbreviation) For the purposes of this disclosure, the following abbreviations apply: 3GPP 3rd Generation Partnership Project 4G 4th Generation 5G 5th Generation 5GC 5G Core Network 5GS 5G System AF Application Function AMF Access and Mobility Management Function AN Access Node AID Application Identifier AKA Authentication and Key Agreement ARPF Authentication credential Repository and Processing Function AS Access Stratum AUSF Authentication Server Function CP Control Plane D2D Device to Device EAP Extensible Authentication Protocol eNB evolved NodeB EPS Evolved Packet System EPC Evolved Packet Core ETSI European Telecommunications Standards Institute E-UTRA Evolved Universal Terrestrial Radio Access gNB next Generation NodeB IEEE Institute of Electrical and Electronics Engineers IoT Internet of Things ITS Intelligent Transport Systems KDF Key Derivation Function L2 ID Layer 2 Identity LTE Long Term Evolution ("4G") M2M Machine to Machine MAC Message Authentication Code MBMS Multimedia Broadcast and Multicast Service MitM Man in the Middle MME Mobility Management Entity MTC Machine Type Communication MVNO Mobile Virtual Network Operator NAS Non-Access Stratum NB-IoT Narrow Band IoT NEF Network Exposure Function NF Network Function NG-RAN Next Generation Radio Access Network NID Network identifier NR New Radio (5G) NRF Network Repository Function NW NetWork PCF Policy Control Function PLMN Public Land Mobile Network PSID Provider Service IDentity QoS Quality of Service (R)AN (Radio) Access Network RRC Radio Resource Control SEAF Security Anchor Functionality SIDF Subscription Identifier De-concealing Function SMF Session Management Function UDM Unified Data Management UE User Equipment UPF User Plane Function UDR Unified Data Repository V2X Vehicle to Everything

[0017] (definition) For purposes of this disclosure, the following definitions apply: PC5 Radio interface between two or more UEs Uu Radio interface between UE and base station Groupcast: A communication mode in which two or more members in a group communicate with each other. Group membership may be managed or unmanaged. If managed, it is assumed to be done at the application layer. If unmanaged, group membership shall be defined by some other means, such as pre-configuration.

[0018] (Related Technology) As mentioned above, Release 14 and Release 15 of the 3GPP (3rd Generation Partnership Project) define Vehicle-to-Everything (V2X) communications in LTE. Stage 1 specifications by 3GPP SA WG1 (SA1) define the architecture and security requirements for V2X communications. Based on the advanced use cases specified in SA1 in Release 16, additional architecture extensions will be defined to include 5G V2X. Based on these specifications, LTE V2X communications will support two types of communications: communications over the LTE Uu interface and communications over the LTE PC5 interface. The LTE Uu interface only supports unicast mode communications, while the LTE PC5 interface only supports broadcast.

[0019] For communications over the LTE PC5 interface, minimal security considerations and mechanisms are expected at the 3GPP layer, with most security mechanisms expected to be addressed at the application layer. This is consistent with other V2X standards, such as IEEE 802.11p, IEEE 1609, and ETSI ITS. 3GPP SA WG2 (SA2) completed standardization work on eV2X architecture extensions for Release 16 based on the architecture extension requirements defined in Release 15 Stage 1 for 5G NR-based V2X communications in Release 16. These specifications reveal that 5G V2X, like LTE V2X, supports two communication types: the 5G Uu interface and the 5G PC5 interface. Communications over the 5G Uu interface only support unicast mode, just like the LTE Uu interface. Meanwhile, the 5G PC5 interface supports two communication modes: unicast mode and groupcast mode, in addition to broadcast mode. For this reason, additional security considerations are required to realize the new functions of 5G V2X, and 3GPP SA WG3 (SA3) has begun studying the security aspects of eV2X communications in 5G. The Rel-15 LTE V2X specification architecture extensions are based on several new use cases, as described below.

[0020] The overall security architectures for LTE and 5G are specified in 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture" and 3GPP TS 33.501: "Security architecture and procedures for 5G system," respectively.

[0021] As mentioned above, V2X communication involves two types of radio access technologies (RATs) and two types of interfaces, resulting in a total of four types of communication. 1. Uu a) LTE Uu b) 5G Uu 2. PC5 a) LTE PC5 b) 5G PC5

[0022] These operating modes are used independently. The privacy requirements of the LTE V2X specification state that "if a UE uses the same ID in multiple broadcast messages, the vehicle may be tracked and privacy may be violated." This could lead to traceability and linkability of vehicles and users. It is important to note that the privacy concerns mentioned above only apply to the PC5 interface and not to the Uu interface, where existing LTE-Uu unicast security solutions apply.

[0023] As mentioned above, the SA2 specification defines procedures for V2X communications over PC5, including Layer 2 link establishment, link identifier update, Layer 2 link release, and Layer 2 link modification. Currently, research in SA3 is focused on how to prevent privacy issues, particularly in unicast and groupcast communications, such as tracking the L2 ID of a vehicle or user source. An adversary with the ability to connect and link an L2 identity to a real or long-term (permanent) eV2X endpoint identity can track and trace the endpoint across space and time. Such traceability and linking capabilities constitute an attack against the privacy of eV2X endpoints.

[0024] In unicast communication, changing the source L2ID is essential so that the receiving peer can continue to identify the source of the message. In broadcast or groupcast V2X communication, destination L2ID = broadcast L2ID or groupcast L2ID, and source L2ID = ID of the individual group member UE sending the message.

[0025] In groupcast or broadcast mode, if the source L2ID changes, all group member UEs must track this change to continue to identify the source of the message, i.e., they must always keep track of "who sent a message to the group."

[0026] Therefore, in broadcast or groupcast mode, if a UE misses an L2ID update message from another group member UE, the receiving UE can receive the broadcast / groupcast message (the destination L2ID remains unchanged), but the receiving UE can no longer identify "who sent the message." Such a situation needs to be mitigated and made recoverable.

[0027] This also means that a source L2ID change initiated by a UE must be verifiable by the receiving UE to prevent malicious UEs from disrupting legitimate UE communications. Such verifiability is required because broadcast mode communications are uncontrolled (recipient numbers and identities are unknown) and because membership control in groupcast is less strict than in unicast communications. Therefore, all member UEs in broadcast and groupcast must be synchronized regarding UE L2ID changes.

[0028] Regarding privacy protection, the 3GPP specifications for LTE and 5G V2X communication state that if UEs use the same ID for communication over the PC5 interface, the vehicle may be tracked and privacy may be violated. Therefore, communication privacy protection on the PC5 interface is necessary to mitigate the risk of users or vehicles being tracked. a) Existing SA3 research includes privacy and security solutions for L2ID updates in unicast mode communication. Similar to unicast mode, privacy protection is equally applicable to broadcast and groupcast operation modes. In broadcast mode, the sending UE does not know who is listening to the broadcast message. In groupcast mode, a member UE that has left the group or someone who knows the groupcast destination L2ID can track and identify the source of the message (vehicle or user ID). b) The change of source L2ID in PC5 communication must be verifiable by the receiving UE to avoid malicious UEs from disrupting legitimate UEs and their broadcast and groupcast communication modes. c) Application layer messages (e.g., basic safety messages) continue independent of L2ID update events. Application layer messages often include safety messages to prevent traffic accidents. These messages typically require low-latency communication. L2ID change events should not interfere with ongoing application layer messaging.

[0029] As mentioned above, V2X communication has two modes of operation: communication over the PC5 reference point and communication over the Uu reference point. These two modes of operation can be used independently by the UE for transmission and reception. V2X communication over the PC5 reference point is supported by LTE and NR. V2X communication over the Uu reference point is supported by E-UTRA connected to EPC or 5GC and / or NR connected to 5GC. In this release, V2X communication over the Uu reference point uses only unicast transmission and reception. LTE PC5 communication only supports broadcast mode. Meanwhile, 5G PC5 supports broadcast and groupcast modes in addition to unicast mode communication.

[0030] V2X communication procedure identifier: a) Each UE has an L2 ID for V2X communication over the PC5 reference point, which is included in the source Layer 2 ID field of each frame the UE transmits on the Layer 2 link. The UE self-assigns the Layer 2 ID for V2X communication over the PC5 reference point. b) If IP-based V2X messages are supported, the UE auto-configures a link-local IPv6 address to use as the source IP address. The UE can use the auto-configured link-local IP address for V2X communications over the PC5 reference point without sending neighbor discovery and neighbor advertisement messages for duplicate address detection. c) If the UE has an active V2X application requiring privacy support in its current geographical region as specified by its configuration, the source Layer 2 ID must be changed and randomized over time to prevent the source UE (e.g., a vehicle) from being tracked or identified by other UEs (e.g., vehicles) beyond the short time required by the application. For IP-based V2X communications over PC5 reference points, the source IP address must also be changed and randomized over time. Changes to the source UE's identifier must be synchronized across layers used by PC5, for example, when the application layer identifier changes or when the source Layer 2 ID and source IP address need to be changed. d) Configure the UE with the destination Layer 2 ID used for the V2X service. The Layer 2 ID of the V2X message is selected based on the configuration. e) The source L2ID used on the PC5 interface may be different for each operating mode and for different RATs within the same UE. The table below outlines the differences in operating modes and source L2IDs for LTE V2X and 5G V2X. The different designations for different L2IDs indicate that these ID values ​​may be different.

[0031] Table 1: Types and modes of RATs for PC5 communications [Table 1]

[0032] Each of these source L2 IDs is independently assigned or reassigned by the UE, while the destination ID may be pre-configured and depends on the communication mode.

[0033] The study on security aspects of V2X in 5G (3GPP TR 33.836: "Study on security aspects of 3GPP support for advanced V2X services") presents existing key challenges and solutions. One of the key challenges is privacy protection for groupcast messages on the PC5 interface.

[0034] This disclosure primarily relates to methods for mitigating traceability attacks against UEs in mobile communication systems and focuses on privacy protection for broadcast and groupcast communications, although it is equally applicable to privacy protection in unicast communications.

[0035] The present disclosure also relates to aspects of a 5G system supporting V2X communications in the context of how a Source L2ID Update procedure provides user privacy protection in broadcast, groupcast, or unicast V2X communications.

[0036] (Description of the embodiment) The present disclosure describes a number of embodiments and variations of each embodiment, which can be combined with each other in any desired manner.

[0037] (Embodiment 1: Verifiable L2 ID Update in Broadcast and Groupcast Modes) (Embodiment 1, Variation 1a, General Description) In this proposed embodiment, the communication system 100 includes a UE 110 (first UE) and a UE 120 (second UE) of Figure 1. Although one UE 110 and one UE 120 are shown in Figure 1, multiple UEs 110 and / or multiple UEs 120 may be present.

[0038] UE 110 transmits a message including a Layer 2 Identity (L2ID) and verification information to UE 120. Figure 1 shows that UE 110 includes a transmitter 111, which transmits the message including the L2ID and verification information to other UEs, particularly UE 120. The verification information allows other UEs to determine whether to accept the new L2ID.

[0039] UE 120 receives a message from UE 110 and determines whether to accept the L2ID using the verification information. As shown in FIG. 1, UE 120 includes a receiving unit 121 and a determining unit 122. The receiving unit 121 receives a message including the L2ID and verification information from another UE, particularly UE 110. The determining unit 122 determines whether to accept the L2ID using the verification information.

[0040] In this modification 1a, the UE 110 transmits verification information, and the UE 120 uses this information to determine whether to accept the L2ID. Therefore, the UE 120 can reject communication from a malicious UE, thereby reducing security risks in communication.

[0041] (Embodiment 1, Variation 1b, General Description) In this modification 1b, the first embodiment will be described in more detail.

[0042] As shown in Figure 2, the transmitting UE sends its newly derived L2ID to the peer UE in an L2ID Update Request message. The receiving UE verifies the legitimacy of the sender of the update message. This prevents a malicious UE from sending false update messages to one or more UEs via broadcast, groupcast, or unicast communication. Security (e.g., encryption and integrity protection) shall be provided at the application layer (consistent with other V2X technologies such as IEEE 802.11p, IEEE 1609, and ETSI ITS).

[0043] To verify messages from any member UE, the update message contains information that indicates whether the message is valid, i.e., sent by a genuine user. Examples of information elements that may be used are: 1. Current L2ID 2.New L2ID 3. Group ID (GroupCast only) 4. V2X Service ID (e.g. PSID or ITS-AID) 5. Other information (e.g., time / location information) 6. MAC (Message Authentication Code) or hash value of the above information An example of a message flow is shown in the following diagram: In this disclosure, V2X includes V2V, V2I, V2N, and V2P.

[0044] 2, S1a to S1c show that a transmitting UE (UE-Tx) transmits an L2 ID update request message that includes verification information, which allows a receiving UE to verify the validity of the message sender.

[0045] S2a to S2c in FIG. 2 show that the receiving UE (UE-1 to UE-3 in FIG. 2) uses information included in the L2ID update message from UE-Tx to verify the validity and authenticity of the message sender and determine whether the received message was sent by a legitimate UE. If the validity and authenticity of the message sender are confirmed, the receiving UE accepts the received update message. If confirmation is not possible, the receiving UE does not accept the received update message. This action by the receiving UE prevents a malicious UE from sending a false update message in broadcast, groupcast, or unicast communications.

[0046] For broadcast and groupcast communication, there can be one or more member UEs that receive the L2ID update message, whereas for unicast communication, there is only one UE that receives the L2ID update message.

[0047] (First embodiment, second modification, explanation: Verifiable L2ID update in broadcast and groupcast communications) In this variation, a key derivation function (KDF) is introduced to derive a new L2 ID and MAC (or "hash value") using appropriate inputs as described in the previous section.

[0048] It should be noted that the term "KDF" is used generally to refer to a function that receives a set of input parameters and produces one or more output parameters. In this particular example, the KDF does not produce a "key." However, the term can generally be applied to other types of similar functions. Therefore, the term KDF will be used in this disclosure.

[0049] As an example of this KDF, as mentioned in the previous section, these inputs can include the current L2 ID, service type, group ID (applies only to groupcast), V2X service ID (e.g., PSID or ITS-AID), and other information such as time and location information. Based on these inputs, the output of the KDF function is a MAC (i.e., a hash of the above information) and a new L2 ID. Figure 3 shows an example of a KDF function on the transmitter side.

[0050] An exemplary formula for deriving the new L2ID and MAC value can be defined as follows: (New L2ID, MAC) = KDF(Current L2ID, Group ID, V2X Service ID, location information or time information, etc.).

[0051] In another example, the KDF function can be derived using additional or different types of input parameters to achieve the same result and uniquely identify the validity of the L2ID update message and sender. This newly generated L2ID and MAC are updated in all peer member UEs in groupcast, broadcast, or unicast communications.

[0052] When the receiving UE receives the L2ID Update message, it verifies the validity and authenticity of the message sender. The receiving UE uses the same set of input parameters and the peer's current L2ID used by the sender. The receiving UE calculates a MAC (hash value) of the input parameters. The receiving UE then compares this MAC (hash) value with the value received in the L2ID Update message. If they match, the receiving UE assumes the message is from a legitimate UE and accepts the new L2ID sent in the received message. However, if they do not match, the receiving UE assumes the message is from a malicious UE and rejects the new L2ID in the received message. Figure 4 shows an example of a receiver's KDF function.

[0053] In this modification, the transmitting UE includes a generation unit that generates a new L2 ID and a first MAC using a KDF function, and a transmission unit (111 in FIG. 1) appends the MAC and transmits the message. The receiving UE includes a generation unit that generates a second MAC using the KDF, and a determination unit (122 in FIG. 1) compares the first MAC and the second MAC to determine whether to accept the L2 ID. By using the KDF, the transmitting UE can easily derive a new Layer 2 ID and MAC, and the receiving UE can easily determine the validity of the new L2 ID.

[0054] (First embodiment, third modification, description: Verifiable L2 ID update in broadcast and groupcast communications with replay protection) Similar to Variation 2 of Embodiment 1, this variation also describes how to verify L2ID updates in broadcast, groupcast, or unicast modes. Furthermore, to mitigate replay attacks, an additional information element is included as an input to the key derivation function. In this variation, a "sequence number" is introduced as an input to the key derivation function (KDF). The main advantage of this solution is that it prevents man-in-the-middle (MitM) replay attacks.

[0055] FIG. 5 shows how the L2 ID and MAC are derived on the transmitting side, and FIG. 6 shows how the MAC is derived and the MAC value is verified on the receiving side.

[0056] Figure 5 shows that the transmitting UE uses the current L2 ID and input parameters of the KDF function, similar to Figure 3. In addition, the transmitting UE also uses the sequence number to generate a new L2 ID and MAC (hash value).

[0057] Similar to the second variation of the first embodiment, when the receiving UE receives the L2ID update message, it verifies the validity and authenticity of the sender of the message. The receiving UE uses the same set of input parameters and the current L2ID of the peer as the sender. The receiving UE also uses the same sequence number as the sending UE to generate a MAC (hash value). The receiving UE then compares this MAC (hash) value with the value received in the L2ID update message. If they match, the receiving UE considers the message to be from a legitimate UE and accepts the new L2ID in the received message. However, if they do not match, the receiving UE considers the message to be from a malicious UE and rejects the new L2ID in the received message.

[0058] Note that the sequence number can be used to ensure that a received L2 ID update message does not overlap with a previously sent message, which is achieved by the UE incrementing the sequence number each time it sends an L2 ID update message.

[0059] (Embodiment 1, Modification 4, Description: One-way update without confirmation) This variation describes a one-way update procedure for updating the L2 ID without confirmation. In this variation, the transmitting UE transmits the updated new L2 ID to peer UEs in broadcast or groupcast mode without receiving any confirmation from the receiving UE. In the broadcast or groupcast mode, for example, when there are a large number of receiving UEs, it is advantageous to reduce the overhead of receiving and tracking confirmation from other UEs. In the broadcast mode, it is not possible to know in advance which and how many receiving UEs are present within the communication range.

[0060] Therefore, the main advantage of this solution is that it improves the scalability of the L2 ID update procedure regardless of the number of peer UEs in the group.

[0061] Also, there is no acknowledgement sent by the peer UE, which reduces overhead as mentioned above. The sending UE does not need to keep track of acknowledgements from all member UEs. An example procedure is shown in Figure 7.

[0062] In S1 of FIG. 7, the transmitting UE (UE-Tx) updates its own L2ID. S2a to S2c in Fig. 7 show that a transmitting UE (UE-Tx) transmits an L2 ID update request message including verification information (e.g., MAC). This MAC (hash) value is calculated based on the method described in the first or second modification of the embodiment. This information allows a receiving UE to verify the validity of the sender of the message. S3a to S3c in FIG. 7 show that the receiving UE (UE-1 to UE-3 in FIG. 7) uses information included in the L2ID update message from UE-Tx to verify the validity and authenticity of the message sender and determine whether the received message was sent by a legitimate UE. If the validity and authenticity of the message sender are confirmed, the receiving UE accepts the received update message. If confirmation is not possible, the receiving UE does not accept the received update message. This action by the receiving UE prevents a malicious UE from sending a false update message via broadcast, groupcast, or unicast communication.

[0063] (First embodiment, fifth modification, explanation: bidirectional update with confirmation) In this variation, the receiving UE acknowledges the L2ID update from the first UE by sending an L2ID Update Response message. Thus, this solution variation allows the transmitting UE to track acknowledgements from other communicating UEs. Therefore, this variation always ensures synchronous updating of the new L2ID.

[0064] The main advantage of this variation is that the transmitting UE can recognize whether the L2 ID update message has been successfully received by the receiving UE. This variation is advantageous in groupcast mode communication with a small number of UEs in a group. An example of the procedure is shown in Figure 8.

[0065] S1 in FIG. 8 is the same as S1 in FIG. 7 of the fourth modification of the first embodiment. S2a to S2c in FIG. 8 are the same as S2a to S2c in FIG. 7 of the fourth modification of the first embodiment. S3a to S3c in FIG. 8 are the same as S3a to S3c in FIG. 7 of the fourth modification of the first embodiment. S4a to S4c in FIG. 8 show that the receiving side UE (UE-1 to UE-3) transmits an L2 ID update response indicating the success or failure of the verification to UE-Tx.

[0066] (Embodiment 1, Modification 6, Explanation: KDF Algorithm Negotiation) This solution variant introduces a mechanism for communicating UEs to negotiate and agree on a KDF, as described in Variation 1 and Variation 2 of Embodiment 1. This variant introduces the concept of possible differences or variations in KDF functions between communicating UEs. In this case, this variant allows communicating UEs to exchange one or more of the KDF functions they support and negotiate a KDF that all UEs can agree on.

[0067] In one example, the negotiation of the KDF function can occur at the time groupcast or unicast communication is established.

[0068] This modification is advantageous for illustrating different implementation variations of the KDF function by the UE. Furthermore, this modification is useful for unicast communication or groupcast communication with a small number of member UEs. Note that this modification may not be suitable for broadcast communication where the number of UEs is not known in advance or for groupcast mode where a large number of members participate in the communication.

[0069] (First embodiment, seventh modification, explanation: KDF input parameter negotiation) Similar to Variant 5 of the previous embodiment, this variant proposes that the UEs should support a similar discovery / negotiation / agreement procedure regarding the set of input parameters for deriving the KDF between member UEs.

[0070] This variant of the solution introduces a mechanism for communicating UEs to negotiate and agree on a KDF, as described in variant 1 and variant 2 of embodiment 1. This variant introduces the concept of possible differences or changes in input parameters used by the KDF between communicating UEs. In this case, in this variant, communicating UEs can exchange supported input parameters used by the KDF and negotiate a set of input parameters agreed upon by all UEs.

[0071] In one example, parameter negotiation for the KDF function can occur at the time groupcast or unicast communication is established.

[0072] This variation is advantageous in considering different implementation variations of the KDF function by the UE. Furthermore, this variation is useful for unicast or groupcast communications with a small number of member UEs. Note that this variation may not be suitable for broadcast communications where the number of UEs may not be known in advance.

[0073] (Embodiment 2: Improved delivery of L2ID updates in groupcast and broadcast communications) (Embodiment 2, Variation 1: Improved Delivery of L2ID Updates in Groupcast and Broadcast Communications) In the case of unicast communication, only two UEs are involved in the communication. In this case, it is rather trivial to ensure successful delivery of the L2ID update by defining a bidirectional request / response message exchange. However, in groupcast and broadcast communication, multiple UEs are involved in the communication, and the problem arises that not all UEs can always successfully receive the same message.

[0074] In groupcast and broadcast modes, one or more group members may miss an L2ID update message (e.g., due to poor signal conditions). In this state, such UEs may continue to receive groupcast or broadcast messages (because the destination L2ID is the groupcast or broadcast L2ID), but they will be unable to distinguish where the groupcast or broadcast message originated from. This is because a UE that misses an L2ID update from a particular source UE will no longer be able to track the continuity of the L2ID from that particular source UE, and as a result, will be unable to identify to whom the particular source L2ID belongs.

[0075] In this regard, it is important to increase the probability of successful delivery of the L2 ID Update message in groupcast and broadcast modes. In this disclosure, two variations to achieve this goal are discussed.

[0076] This variation maximizes the chances of the L2 ID update being received by all group members and introduces a mechanism to resynchronize the receiving UE if the original L2 ID update message is missed.

[0077] As an example, consider a scenario in which one member UE misses an L2ID update from the transmitting UE. In this case, all peer UEs except one successfully receive the updated L2ID in the original transmission. After a certain period of time, the transmitting UE repeats the L2ID update message, allowing the member UEs that missed the update in the initial transmission to receive the updated L2ID from the same UE.

[0078] The period over which the L2ID update message is repeated may be set by the network or may be derived internally within the UE. In another example, the number of times the same message is repeated may be set by the network or derived internally within the UE.

[0079] Sub-variations of Variation 1 are as follows: Variation 1.a: Repetition by the transmitting UE Variation 1.b: Relay by receiving UE Variation 1.c: Flooding by the receiving UE Variation 1.d: Combination of (a) to (c) The following Figures 9A to 9D show these sub-variations.

[0080] Figure 9A shows a repeat message from the source UE. In this case, UE-4 misses the first L2 ID update message sent by UE-1, while UE-2 and UE-3 successfully receive the first L2 ID update message. However, UE-4 successfully receives the same update from UE-1 in a repeat message. The dashed lines indicate the repeat message.

[0081] Figure 9B shows relayed messages from UEs that successfully received the original L2 ID Update message. In this case, UE-4 misses the initial L2 ID Update message sent by UE-1, while UE-2 and UE-3 successfully receive the initial L2 ID Update message. However, UE-4 successfully receives the same update relayed from UE-3. The dashed line indicates the relayed message from UE-3.

[0082] Figure 9C shows flooding messages from UEs that successfully received the original L2 ID update messages. In this case, UE-4 misses the initial L2 ID update message sent by UE-1, but UE-2 and UE-3 successfully receive the initial L2 ID update messages. However, UE-4 successfully receives the same updates from UE-2 and UE-3 in flooding messages. The dashed lines indicate relay messages from UE-2 and UE-3.

[0083] Figure 9D shows a combination of repeated, relayed, and flooded messages from UEs that successfully received the original L2 ID update message. In this case, UE-4 misses the initial L2 ID update message sent by UE-1, while UE-2 and UE-3 successfully receive the initial L2 ID update message. However, UE-4 successfully receives the same update from UE-1, UE-2, and UE-3 in repeated, relayed, and flooded messages. The dashed lines indicate the repeated / relayed / flooded messages from UE-1, UE-2, and UE-3.

[0084] Alternatively, in the above variations, one or more UEs may receive the same message more than once (i.e., the original message and a repeated / relayed / flooded message, or two or three repeated / relayed / flooded messages). As an example, the UE may detect such duplicate receipt of the same message and discard the duplicates.

[0085] In another example, repeated / relayed / flooded messages may be sent to a separate destination L2ID that is specifically intended to deliver the repeated / relayed / flooded messages. Using a separate L2ID dedicated to repeated / relayed / flooded messages simplifies the receiving operation at the UE, allowing duplicate messages to be quickly detected and discarded.

[0086] (Embodiment 2, Modification 2: Improvement of L2ID update distribution in groupcast and replay-protected broadcast) In this modification, an additional function is introduced to the modification 1 of embodiment 2. Replay attacks such as man-in-the-middle attacks by malicious UEs are avoided.

[0087] This expansion function can be applied to all sub-variations (ie, variations 1.a to 1.d) of variation 1 of embodiment 2. The additional functions in this variation can be explained as follows.

[0088] In (Embodiment 2, Variation 1, and Sub-Variations 1.a to 1.d), a sequence number is introduced when generating a repeated message. Each message is assigned a valid sequence number (value). Therefore, if a message is repeated, the sequence number of the repeated message will be different from the original message. This sequence number is used only once, and any subsequent attempts to replay the message will be rejected by the receiving UE.

[0089] It should be noted that the sequence numbers used in this modification are used for a different purpose than the sequence numbers introduced in the second modification of the first embodiment.

[0090] In one example, this sequence number can be defined in a more complex way than simply a monotonically increasing number for each successive repetition / replay / flooding of the same message, otherwise it is clear that an attacker could assume the next sequence number is N+1 and perform a replay attack.

[0091] In another example, the last used sequence number can be used as input to a KDF to derive the next sequence number, as shown in Figure 10.

[0092] In another example, the initial value of the sequence number can be randomly selected by the sender, and subsequent repeated messages can use monotonically increasing sequence numbers as input, in which case the sender communicates the initial value to the receiver in a secure manner (e.g., a message encrypted using an existing security context, including encryption keys, etc.).

[0093] In these examples, additional parameters unrelated to sequence numbers can be used as input to the KDF.

[0094] Figure 10 shows an example of a KDF function for deriving a new sequence number using the last used sequence number and an additional parameter as input parameters. In Figure 10, a timestamp is used as the additional parameter.

[0095] (Embodiment 3: Improved delivery of application layer messages in groupcast, broadcast, and unicast communications) (Embodiment 3, Modification 1: Duplicate communication when updating L2ID) The L2ID update procedure described in the first and second embodiments protects the privacy of users and vehicles in V2X communications. This mechanism occurs periodically at intervals configured by the system, self-configured by the UE itself, or specified by the UE.

[0096] Note that this L2ID update procedure is separate and independent from application layer communications (e.g., basic safety messages for avoiding traffic accidents) using the PC5 interface between UEs. This means that the flow of application layer messages triggered by the L2ID update event continues independently of such an L2ID update event, since the application layer message event is not aware of this L2ID update. This independence of events generally follows the principle of layer concepts commonly present in communication systems. If an L2ID update event occurs simultaneously with an application layer message flow, the L2ID update event should not cause unexpected communication interruptions between UEs involved in communication over the PC5 interface. This situation applies to broadcast, groupcast, and unicast modes of communication. If application layer communications are interrupted due to a lower layer event, such as an L2ID update, possible consequences include the loss of application layer messages.

[0097] If one or more UEs in a broadcast, groupcast, or unicast communication miss an L2ID update for a UE involved in the communication, or if an application message is delayed or lost due to an event such as an L2ID update, the resulting application layer service may be interrupted. Note that typical V2X application layer communications contain basic safety messages to avoid traffic accidents, which require very low-latency communications. Therefore, preventing communication interruptions at the application layer is critical. If such an event occurs, it may make the difference between an accident occurring or not.

[0098] To address this situation and mitigate potential impacts, Variant 1 of Embodiment 3 proposes the following mechanism to improve delivery of application layer messages in groupcast, broadcast, and unicast modes of communication.

[0099] In this variation, a UE involved in broadcast, groupcast, or unicast communications identifies an event in which its L2ID periodically changes. The UE then transmits the same application layer message multiple times (e.g., twice) using the old L2ID and the new L2ID as the source L2ID. This results in the same application layer message being repeated multiple times (e.g., twice) using two different source L2IDs. This maximizes the likelihood that other UEs in communication will be able to successfully receive application layer messages without interruption, even if the UE's L2ID changes.

[0100] In one example, the L2 layer responsible for the L2ID update indicates to the upper layer (application layer) that the L2ID change is occurring. The upper layer (application layer) then transmits the message multiple times (e.g., twice) for each message it generates. This variant is more applicable when the application layer uses IP-based communication. Note that in IP-based communication, the source IP address and the source L2ID are updated simultaneously. In this case, the description of this variant regarding the change of the L2ID also applies to the change of the IP address.

[0101] In another example, the Layer 2 responsible for L2 ID updates detects the period when L2 ID updates occur. During this period, the Layer 2 sends application layer messages from the upper layer using both the old and new L2 IDs in the communication mode (broadcast, groupcast, or unicast) that the application layer is using. This sub-variant is more applicable when the application layer communication uses non-IP-based communication.

[0102] In one example, the message sent by the sending UE is successfully received in both of the following scenarios: Therefore, this variation is advantageous in communication modes where there are multiple receiving UEs, such as broadcast mode and groupcast mode. a) Even if the receiving UE is in the process of updating the L2ID of the sending UE, the receiving UE can recognize the old L2ID as a valid ID of the sending UE. In this case, the receiving UE recognizes messages sent by the sending UE that contain the old L2ID in the source L2ID field. b) If the receiving UE has already accepted the L2ID update of the sending UE, it may recognize the new L2ID as a valid ID of the sending UE, in which case the receiving UE will recognize messages sent by the sending UE that include the new L2ID in the source L2ID field.

[0103] In one example, the time window during which this duplicate transmission occurs is defined by a timer called the "L2 ID Update Safeguard Timer." In one example, this timer may be configured by the system or may be self-assigned by the UE itself.

[0104] (Embodiment 3, Modification 2: Acceptance of multiple L2IDs when updating L2IDs) In this variation, the receiving UE accepts a message from the transmitting UE that contains either the old or new L2 ID as the message sender ID. The old and new L2 IDs used by the transmitting UE refer to the ones used before and after the L2 ID change procedure, respectively. This variation of the solution is applicable to broadcast, groupcast, and unicast communications.

[0105] This solution variant addresses the relative timing difference between the time the sending UE starts using the new L2 ID in messages and the time the receiving UE starts recognizing the sending UE's new L2 ID. In other words, this mechanism addresses the following race condition: 1) A scenario in which a sending UE starts using a new L2ID as the source address in messages, even though one or more receiving UEs recognize the old L2ID as a valid source L2ID for the sending UE. 2) A scenario in which a message from a sending UE arrives at the receiving UE containing the old L2ID, while the receiving UE already recognizes the new L2ID as a valid source L2ID for the sending UE.

[0106] In either scenario, without the mechanism described in this section, the receiving UE would discard the received message because the L2ID in the source address of the sending UE is invalid. The mechanism described in this section allows the receiving UE to receive the message from the sending UE without discarding it, preventing message loss regardless of the relative timing difference between when the sending UE switches to sending messages using the new L2ID and when the receiving UE switches to receiving messages using the new L2ID.

[0107] In one example, the receiving UE stops accepting the old L2ID from the sending UE as soon as it receives a message from the sending UE that includes the sending UE's new L2ID as the source ID, which indicates that the sending UE has already switched to the new L2ID, and therefore the receiving UE will no longer receive messages that include the sending UE's old L2ID.

[0108] In another example, the receiving UE uses a time window during which it accepts messages from both the old and new L2IDs from the transmitting UE. The definition and usage of this time window are similar to the "L2ID update safeguard timer" described in Variation 1 of Embodiment 3 above. When this timer expires, the receiving UE stops receiving messages containing the transmitting UE's old L2ID. As a result, the receiving UE switches only to the transmitting UE's new L2ID.

[0109] In the case of IP-based communication, the change of IP address and L2 ID occurs simultaneously, in which case the mechanism described in this variant applies to both the IP address and the L2 ID.

[0110] (Embodiment 4: Mechanism for rescuing UEs that miss L2ID updates over multiple update cycles) (Fourth embodiment, variant 1: explicit query) The L2 ID update mechanism described in the first, second, and third embodiments is implemented by the source UE communicating its old (i.e., current) L2 ID and new L2 ID. This mechanism "rescue" a UE that has missed multiple L2 ID updates. This update is sent to other communicating UEs depending on the mode used (broadcast, groupcast, and unicast).

[0111] Note that this L2ID update mechanism only communicates two immediately consecutive L2ID values, e.g., an L2ID of generation "N" followed by an ID of generation "N+1", and these two L2IDs are sent in an L2ID update message.

[0112] This messaging scheme means that if a receiving UE misses an L2 ID update cycle, the next L2 ID update from the same UE will contain the old (i.e., current) L2 ID, which is unknown to the UE that missed the previous L2 ID update cycle. In this case, the UE will no longer be able to track the sequence of L2 IDs for a given UE with which it is communicating. For example, if UE-A's L2 ID changes from ID value #1 to ID value #2 in one update cycle and then from ID value #2 to ID value #3 in the next update cycle, and one of the receiving UEs misses the first update cycle (the update from ID value #1 to ID value #2) but successfully receives the next L2 ID update cycle (the update from ID value #2 to ID value #3), the UE will not be able to track the order in which the ID values ​​changed from ID value #1 to ID value #3. Therefore, it will not be able to identify that ID value #1 and ID value #3 belong to the same UE.

[0113] Generally, if a receiving UE fails to receive an L2ID update for one or more update cycles, it will not be able to establish continuity of L2ID changes in subsequent L2ID updates for a given UE with which it is communicating.

[0114] To alleviate the conditions described in the above section, this variant introduces a mechanism to restore continuity of L2ID changes over time spanning multiple update cycles.

[0115] Each UE in a communication using the PC5 interface defines a "default" L2ID. This "default ID" is used as a fallback L2ID and as a means for a receiving UE to re-establish an association between the source UE and the currently used (i.e. most recent) L2ID. This mechanism means that all UEs involved in the communication "know" this "default ID" in some way.

[0116] In another example, this "default" L2ID is of a more permanent nature, where it is implicitly known by all communicating UEs, such as by system configuration or by an L2ID value statically assigned to each UE.

[0117] In another example, this "default" L2ID can be created by an explicit formula based on the last known L2ID by the receiving UE. For example, the last few bits of the L2ID can be set to a predetermined, well-known format (e.g., all "1's") to designate this as the "default" L2ID for a given source UE.

[0118] In this variant, any legitimate UE in an already established communication can send an explicit request message to the source UE. This request can be made by the UE sending an explicit message to the UE in question over the PC5 interface, requesting that the UE send its latest L2 ID. In other words, this variant can be summarized as a recovery method when the receiving UE loses track of the source UE's L2 ID. This is shown in Figure 11.

[0119] FIG. 11 shows the mechanism for re-establishing the L2 ID when the UE misses multiple L2 ID updates over PC5 communication. S1 in FIG. 11 shows a case where UE-2 loses track of UE-1's L2ID, for example, by missing multiple L2ID updates from UE-1. S2 in Figure 11 shows that UE-2 sends an L2ID query message to request UE-1 to provide the latest L2ID, for example, based on the latest L2ID of UE-1 that UE-2 knows about. This message also includes other information that identifies the requesting entity (UE-2) as a valid and legitimate UE in communication. At S3 in FIG. 11, UE-1 verifies the validity of the request received at S2. In S4 of FIG. 11, if the validity check in S3 is successful, UE-1 sends the latest (current) L2 ID to UE-2. S5 in FIG. 11 shows how UE-2 receives the message of S4 and restores the L2 ID of UE-1. S6 in FIG. 11 indicates that UE-2 can identify the message sent from UE-1 as the sender.

[0120] (Fourth embodiment, second modification: periodic updates) In another example, the UE in question can voluntarily and periodically include a "default" L2ID in its L2ID update messages to all receiving UEs. This mechanism is intended to "cure" a UE that has missed multiple L2ID updates. For the purpose of resynchronizing to the source UE's most recent L2ID, this "default" L2ID is relatively persistent in time compared to the regular L2ID, which changes periodically. In other words, this variant can be summarized as a preventative measure to avoid the receiving UE losing track of the source UE's L2ID. This is illustrated in Figure 12.

[0121] Figure 12 shows the mechanism for providing a "default" L2 ID to a peer UE via PC5 communication.

[0122] S1 in Figure 12 shows UE-1 sending an L2ID Update Request message to a communicating peer UE. This message includes UE-1's "default" L2ID. Note that this "default" L2ID information is included less frequently than the regular "L2ID," which is updated periodically. S2 in Figure 12 shows UE-2 retaining UE-1's "default" L2ID.

[0123] (Other embodiments) (System Overview) FIG. 13 is a diagram schematically illustrating a mobile (cellular or wireless) communication system 1 to which the above-described embodiments can be applied.

[0124] In this network, users of mobile devices 3 (UE) can communicate with each other via respective base stations 5 and a core network 7 using an appropriate 3GPP radio access technology (RAT), e.g., E-UTRA and / or 5G RAT. It will be appreciated that many base stations 5 form a (radio) access network or (R)AN. Those skilled in the art will appreciate that while Figure 13 shows one mobile device 3 and one base station 5 for illustrative purposes, a system implementation will typically include other base stations and mobile devices (UE).

[0125] Each base station 5 controls (directly or via other nodes such as home base stations, relays, remote radio heads, distributed units, etc.) one or more associated cells. Base stations 5 that support E-UTRA / 4G protocols are referred to as "eNBs," and base stations 5 that support next generation / 5G protocols are referred to as "gNBs." It will be appreciated that some base stations 5 may be configured to support both 4G and 5G, and / or any other 3GPP or non-3GPP communication protocols.

[0126] A mobile device 3 and its serving base station 5 are connected via a suitable air interface (e.g., the so-called "Uu" interface and / or the like). Adjacent base stations 5 are connected to each other via suitable inter-base station interfaces (e.g., the so-called "X2" interface, "Xn" interface and / or the like). Base stations 5 are also connected to core network nodes via suitable interfaces (e.g., the so-called "S1", "N1", "N2", "N3" interfaces and / or the like).

[0127] The core network 7 typically includes logical nodes (or "functions") for supporting communications in the communications system 1. Typically, for example, the core network 7 of a "next generation" / 5G system includes, among other functions, a control plane function (CPF) and a user plane function (UPF). It will be appreciated that the core network 7 may include, among other functions, an access and mobility management function (AMF) 10, a session management function (SMF) 11, a security anchor function (SEAF) 12, an authentication server function (AUSF) 13, a unified data management (UDM) function 15, an authentication credential repository and processing function (ARPF) 16, a subscription identifier unhiding function (SIDF) 17, a policy control function (PCF) 18, and an application function (AF) 19.

[0128] The core network 7 also provides connectivity to external IP networks 20 (such as the Internet). The components of the system 1 are configured to perform one or more of the exemplary embodiments described above.

[0129] (User Equipment (UE)) Figure 14 is a block diagram illustrating the main components of the UE 3 shown in Figure 13. As shown in Figure 14, the UE 3 includes transceiver circuitry 31 operable to transmit and receive signals to and from connected nodes via one or more antennas 33. Although not shown in Figure 14, the UE 3 naturally has all the usual functionality of a conventional mobile device (such as a user interface 35), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in memory and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD).

[0130] The controller 37 controls the operation of the UE 3 in accordance with software stored in the memory 39. The controller 37 can be realized, for example, by one or more CPUs (Central Processing Units). The controller 37 can also load software (computer programs) from the memory 39 and execute the loaded software to perform the processing of the UE 3 described with reference to the sequence diagrams and flowcharts of the above-described embodiments.

[0131] The memory 39 is configured by combining volatile memory and non-volatile memory. The memory 39 may include a storage device located separately from the controller 37. In this case, the controller 37 can access the memory 39 via an I / O interface (not shown). The software stored in the memory 39 includes instructions for causing a computer to execute the algorithms described above with reference to the drawings.

[0132] The software includes, among other things, an operating system 41 and a communications control module 43 having at least a transceiver control module. The communications control module 43 (using a transceiver control sub-module) is responsible for signaling and processing (generating / sending / receiving) uplink / downlink data packets between the UE 3 and other nodes, such as base stations / (R)AN nodes 5, MMEs, AMFs 10 (and other core network nodes). Such signaling may include, for example, appropriately formatted signaling messages related to connection establishment and maintenance (e.g., RRC messages), periodic location update related messages (e.g., tracking area updates, paging area updates, location area updates), and other NAS messages.

[0133] ((R)AN node) FIG. 15 is a block diagram illustrating the main components of an exemplary (R)AN node 5, e.g., a base station (eNB in ​​LTE, gNB or ngNB in ​​5G) shown in FIG. 13. As shown in the figure, the (R)AN node 5 includes transceiver circuitry 51 operable to transmit and receive signals to and from connected UEs 3 via one or more antennas 53 and to transmit and receive signals to and from other network nodes (directly or indirectly) via a network interface 55. A controller 57 controls the operation of the (R)AN node 5 in accordance with software stored in memory 59. The controller 57 may be realized, for example, by one or more CPUs. Furthermore, the controller 57 may load software (computer programs) from memory 59 and execute the loaded software to perform the processing performed by the core network node. The software may be pre-installed in memory 59 and / or downloaded via a communication network or from a removable data storage device (RMD), for example.

[0134] The memory 59 is configured by combining volatile memory and non-volatile memory. The memory 59 may include a storage device located separately from the controller 57. In this case, the controller 57 can access the memory 59 via an I / O interface (not shown). The software stored in the memory 59 includes a group of instructions for causing a computer to execute an algorithm.

[0135] The software includes, among other things, an operating system 61 and a communications control module 63 having at least a transceiver control module. The communications control module 63 (using the transceiver control sub-module) is responsible for handling (generating / sending / receiving) signaling (e.g., directly or indirectly) between the (R)AN node 5 and other nodes, such as the UE 3, the MME, the AMF 10, etc. The signaling may include, for example, appropriately formatted signaling messages related to radio connectivity and location procedures (for a particular UE), in particular connection establishment and maintenance (e.g., RRC connection establishment and other RRC messages), periodic location update related messages (tracking area updates, paging area updates, location area updates, etc.), S1AP messages and NGAP messages (i.e., messages over the N2 reference point), etc. Such signaling may also include, for example, in the case of transmission, broadcast information (e.g., master information and system information).

[0136] Also, if a controller is implemented, it is configured (by software or hardware) to handle related tasks such as UE mobility estimation and / or motion trajectory estimation.

[0137] (core network node) FIG. 16 is a block diagram illustrating major components of an exemplary core network node shown in FIG. 13 , such as AMF 10, SMF 11, SEAF 12, AUSF 13, UPF 14, UDM 15, ARPF 16, SIDF 17, PCF 18, and AF 19. The core network node is included in the 5GC. As shown in the figure, the core network node includes a transceiver circuit 71 operable to transmit and receive signals to and from other nodes (including UE 3) via a network interface 75. A controller 77 controls the operation of the core network node in accordance with software stored in a memory 79. The controller 77 may be realized, for example, by one or more CPUs. Furthermore, the controller 77 can load software (computer programs) from the memory 79 and execute the loaded software to perform the processes performed by the core network node. The software may be pre-installed in the memory 79 and / or downloaded via a communication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 81 and a communications control module 83 having at least a transceiver control module.

[0138] The memory 79 is configured by combining volatile memory and non-volatile memory. The memory 79 may include a storage device located separately from the controller 77. In this case, the controller 77 can access the memory 79 via an I / O interface (not shown). The software stored in the memory 79 includes instructions that cause the computer to execute algorithms.

[0139] The communications control module 83 (using the transceiver control sub-module) is responsible for handling (generating / sending / receiving) signaling (directly or indirectly) between the core network nodes and other nodes, such as the UE 3, base stations / (R)AN nodes 5 (e.g., "gNB" or "eNB"), etc. Such signaling may include, for example, appropriately formatted signaling messages related to the procedures described herein, such as NGAP messages (i.e., messages over the N2 reference point) for conveying NAS messages to and from the UE, etc.

[0140] The AMF 10 provides UE-based authentication, authorization, and mobility management services. It serves the session management function. It also provides services to other AMFs, policy control functions 18, short message service functions, location management functions, gateway mobile location centers, and NEFs via name-of-service-based interfaces. Key AMF services include registration, connectivity, reachability, and mobility management. It also serves as the termination point for the RAN control plane interface (N2).

[0141] The SMF 11 manages UE sessions and assigns IP addresses to UEs 3. It also selects and controls the UPF 14 for data forwarding. A UE with multiple sessions may be assigned a separate SMF for each session. It also interacts with the User Plane Function 14 for efficient routing of user packets.

[0142] The SEAF 12 generates a unified anchor key KSEAF (common for all accesses) that can be used by the UE 3 and the serving network to secure subsequent communications for primary authentication. In a scenario where the UE 3 is connected to a 3GPP access (visited network) and a non-3GPP access (home network), there may be two anchor keys.

[0143] The AUSF 13 component processes authentication requests for 3GPP access and non-3GPP access networks. The AUSF 13 component interacts with the Security Anchor Function 12 to authenticate the user equipment 3. The Universal Subscriber Identification Module value set is used by the authentication credential repository and processing function. The subscription identifier uniquely identifies the subscription and is used to mutually authenticate the UE 3 and the 5G core network 7. The AUSF 13 provides the necessary authentication and authorization processes and acts as the terminal point for user plane security. It also handles network slice security and Enhanced International Mobile Subscriber Identity Privacy.

[0144] The UPF 14 supports packet routing and forwarding, packet inspection, and QoS processing. It also serves as the external PDU session point for interconnection to data networks and as an anchor point for intra- and inter-RAT movement. This is a critical function, and it must efficiently process packets within sub-milliseconds. Slowing down this function significantly increases packet latency and reduces the user's quality of experience. The UPF 14 utilizes the services of the Session Management Function 11.

[0145] The UDM 15 provides services to the AMF 10, SMF 11, SMSF, NEF, and AUSF 13. Services include subscription data storage, context data management services, and authentication services in cooperation with the AUSF 13. Subscription data management is used by NFs (AMF 10 and SMF 11) to obtain UE subscription data related to consumer NFs from the UDM 15. It is also used by consumer NFs to subscribe or unsubscribe to data change notifications. The UDM 15 enables previously subscribed consumer NFs (AMF 10, SMF 11, SMSF) to be notified by notification service operations when the UDM 15 determines that their subscription data will change.

[0146] The ARPF16 (usually collocated with the UDM15) stores long-term security credentials, such as the EPS AKA or EAP-AKA key K, for authentication. The ARPF16 can run a cryptographic algorithm using the long-term security credentials as input to create an authentication vector.

[0147] The PCF 18 controls the network behavior by supporting a unified policy framework and provides policy rules to the control plane functions, such as the AMF 10 for access and mobility management related policies, UE policies for access network discovery and selection policies, and UE route selection policies.

[0148] AF19 enables application influence over traffic routing, access to the NEF, and interaction with the policy framework for policy control. This capability has significant implications for reliability and security, as core functionality is exposed to the application level.

[0149] The NEF can expose external network functions that support monitoring, provisioning, and policy / charging. Network function exposure consists of: (i) exposing network events to external and internal core network NFs, (ii) exposing provisioning functions to external functions, (iii) exposing policy and charging functions to external functions, and (iv) exposing functions internal to the core network for analysis.

[0150] In the above-described embodiments, the program may be stored and provided to a computer using any type of non-transitory computer-readable medium. The non-transitory computer-readable medium includes any type of tangible storage medium. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, and hard disk drives), magneto-optical storage media (such as magneto-optical disks), compact disc read-only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-R / W), and semiconductor memory (such as mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, and random access memory (RAM)). The program may be provided to a computer using any type of temporary computer-readable medium. Examples of temporary computer-readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium may provide the program to a computer via a wired communication line (such as an electric wire or optical fiber) or a wireless communication line.

[0151] (Modifications and Substitutions) Detailed embodiments have been described above. As will be appreciated by those skilled in the art, many modifications and variations can be made to the above-described embodiments while still benefiting from the teachings embodied therein. By way of example, only a few of these modifications and variations are described herein.

[0152] The embodiments of the present disclosure describe a Layer 2 Identity (L2ID) update procedure. The general concept of identity update is also applicable to equivalent functions in other communication layers, such as IP address update functions in the IP layer. If the L2ID update and IP address update are synchronized within the UE so that they occur simultaneously at two different layers, the procedures described in this disclosure can be applied at different layers to achieve similar results.

[0153] The message and parameter names used in the above-described embodiments represent intended functions and information elements. These message and parameter names are used only as examples to describe specific exemplary embodiments. However, it will be understood that different implementations may use different message and parameter names. It will also be understood that related standard specifications, such as 3GPP TS or TR documents, may use similar or different names to represent the same functions or information as the above-described messages and parameters.

[0154] In this disclosure, user equipment (or "UE," "mobile station," "mobile device," or "wireless device") is connected to a network via a radio interface. It should be noted that the UE in this specification is not limited to a dedicated communication device, but can apply to any device having communication capabilities as described herein as a UE, as described below.

[0155] The terms "user equipment" or "UE" (as the term is used by 3GPP), "mobile station," "mobile equipment," and "wireless equipment device" are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, mobile phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. It will be understood that the terms "UE" and "wireless equipment" also include stationary devices that remain stationary for extended periods of time.

[0156] UE may be, for example, production and manufacturing equipment and / or energy-related equipment (e.g., boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal power generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical equipment, pumps including vacuum pumps, compressors, fans, blowers, air blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or application systems thereof, tools or dies, rolls, conveying equipment, lifting equipment, material handling equipment, textile machinery, sewing machines, printing and / or related equipment, paper converting machinery, chemical machinery, mining and / or construction machinery and / or related equipment, agricultural machinery and implements, safety and environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, pipe fittings, and / or application systems of any of the foregoing).

[0157] A UE may be, for example, an item of transportation equipment (e.g., a rail vehicle, an automobile, a motorcycle, a bicycle, a train, a bus, a cart, a rickshaw, a water vehicle such as a ship, an aircraft, a rocket, a satellite, a drone, a balloon, etc.).

[0158] The UE may be, for example, an item of information and communication equipment (eg, information and communication equipment such as electronic computers and related equipment, communication-related equipment, electronic components, etc.).

[0159] The UE may be, for example, a refrigerator, a refrigerator application product, trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a home appliance or electronic device (e.g., audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee makers, dishwashers, washing machines, dryers, fans or related equipment, cleaners, etc.).

[0160] The UE may be, for example, an electrical application system or device (e.g., an electrical application system or device such as: an x-ray system; a particle accelerator; a radioisotope device; an acoustic device; an electromagnetic application device; an electro-motive application device, etc.). The UE may be, for example, an electronic lamp, lighting fixture, measuring instrument, analyzer, tester, or surveying or detector (e.g., a smoke alarm, a motion sensor, a radio frequency tag, etc.), a wristwatch or watch, laboratory equipment, optical equipment, medical equipment and / or systems, a weapon, an item of cutlery, a hand tool, etc.

[0161] The UE may be, for example, a personal digital assistant or related device with wireless capabilities (e.g., a wireless card or module designed to be attached to or inserted into another electronic device, such as a personal computer or electrical measuring instrument).

[0162] The UE may be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below with respect to the Internet of Things (IoT).

[0163] Internet of Things devices (or "Things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, and these devices can collect and exchange data with each other and with other communicating devices. IoT devices may include automated equipment that follows software instructions stored in internal memory. IoT devices may operate without the need for human supervision or interaction. IoT devices may be shut down and / or inactive for long periods of time. IoT devices may be implemented as part of (typically) stationary equipment. IoT devices may be incorporated into non-stationary equipment (e.g., vehicles) or attached to animals or people being monitored / tracked.

[0164] It will be appreciated that IoT technology may be implemented on any communication device that can connect to a communication network to send and receive data, whether such communication device is controlled by human input or by software instructions stored in memory.

[0165] It should be noted that IoT devices may also be referred to as machine-type communication (MTC) devices, machine-to-machine (M2M) communication devices, or narrowband IoT UEs (NB-IoT UEs). It should be understood that a UE may support one or more IoT or MTC applications. Examples of MTC applications are shown in the following table (Source: 3GPP TS 22.368 V13.1.0, Annex B, the contents of which are incorporated herein by reference). This list is not exhaustive and is intended to illustrate some examples of machine-type communication applications.

[0166] Table 2: Examples of machine-type communications applications [Table 2]

[0167] Applications, services, and solutions include MVNO (Mobile Virtual Network Operator) services, emergency wireless communication systems, PBX (Private Branch Exchange) systems, PHS / digital cordless communication systems, POS (Point of Sale) systems, advertising call systems, MBMS (Multimedia Broadcast and Multicast Service), V2X (Vehicle to Everything) systems, train radio systems, location-related services, disaster / emergency wireless communication services, community services, video streaming services, femtocell application services, VoLTE (Voice over LTE) services, billing services, radio on-demand services, roaming services, activity monitoring services, carrier / network selection services, function restriction services, PoC (Proof of Concept) services, personal information management services, and ad hoc networks / DTN (Delay Tolerant Networking) services.

[0168] Furthermore, the above-mentioned UE categories are merely examples of applications of the technical concepts and exemplary embodiments described in this document, and it should be understood that these technical concepts and embodiments are not limited to the above-mentioned UEs and may be modified in various ways.

[0169] In the above description, the UE, (R)AN node, and core network node are described for ease of understanding as having multiple individual modules (e.g., communication control modules). These modules may be provided in this manner for certain applications, such as when an existing system is modified to implement the present disclosure, but in other applications, such as systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into an overall operating system or code, and therefore may not be identifiable as separate entities. These modules may be implemented in software, hardware, firmware, or a combination thereof.

[0170] Each controller may be comprised of any suitable form of processing circuitry, including, but not limited to, for example, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), microprocessing units (MPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (such as a control bus, data bus, address bus), direct memory access (DMA) functionality, hardware or software-implemented counters, pointers, and / or timers and / or the like.

[0171] In the above embodiments, a number of software modules have been described. As will be understood by those skilled in the art, the software modules may be provided in compiled or uncompiled form and may be supplied to the UE, (R)AN node, and core network node via signals over a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because they facilitate update operations for updating the functionality of the UE, (R)AN node, and core network node.

[0172] The mechanism presented in this disclosure involves message exchanges between UEs with specific information elements. In some cases, UEs may be performing D2D or direct communication. Therefore, intrusions can be detected by monitoring UE communications.

[0173] The above embodiments are also applicable to "non-mobile" or generally stationary user equipment.

[0174] (Method Overview) The above aspects describe an exemplary method, which includes the following steps. (First embodiment, first modification) 1) The transmitting UE sends the new L2 ID and verification information to the receiving UE. 2) The receiving UE uses the verification information to verify the validity and authenticity of the sending UE and decides whether to accept the new L2 ID. (Embodiment 1, Modification 2) 1) The transmitting UE inputs a set of input parameters into the KDF to obtain a new L2 ID and MAC (hash value). 2) The receiving UE inputs the same set of input parameters into the KDF to derive a MAC (hash value) and compares it with the MAC received from the transmitting UE. (Embodiment 1, Modification 3) 1) The transmitting UE inputs the sequence number in addition to the set of input parameters into the KDF to derive a new L2 ID and MAC (hash value). 2) The receiving UE inputs the same set of input parameters plus the sequence number into the KDF, calculates a MAC (hash value), and compares it with the MAC received from the transmitting UE. (Embodiment 1, Modification 4) 1) The transmitting UE transmits the new L2 ID and verification information to the receiving UEs, and, assuming that all receiving UEs have received the new L2 ID and the verification has been successful, starts communication using the new L2 ID. (Embodiment 1, Modification 5) 1) The transmitting UE sends the new L2 ID and verification information to the receiving UE. 2) The receiving UE uses the verification information to verify the validity and authenticity of the sending UE and decides whether to accept the new L2 ID. 3) The receiving UE returns an L2 ID Update Response message to the sending UE indicating success or failure of the verification. (Embodiment 1, Modification 6) 1) The communicating UE exchanges the supported KDF functions and derives a new L2 ID and MAC (hash value) when communication is established. 2) The communicating UEs agree on the KDF function to use. (Embodiment 1, Modification 7) 1) The communicating UE exchanges the supported parameters with the KDF function and derives a new L2 ID and MAC (hash value) when communication is established. 2) The communicating UEs agree on the parameters for the KDF function to use. (Embodiment 2, Modification 1) 1) (Sub-variant 1) When transmitting an L2 ID update message, the transmitting UE repeats the same message multiple times. 2) (Sub-variant 2) When one or more receiving UEs receive an L2 ID update message from a transmitting UE, the receiving UEs relay the same message. 3) (Sub-variant 3) When one or more receiving UEs receive an L2 ID update message from a transmitting UE, the receiving UEs flood the same message. 4) (Sub-variant 4) When sending an L2 ID update message, the sending UE repeats the same message multiple times and / or one or more receiving UEs relay or flood the same message. (Embodiment 2, Modification 2) 1) When sending an L2ID Update message, the sending UE inserts a unique one-time value (eg, a sequence number) into the message. 2) The receiving UE uses the received unique one-time value (e.g., sequence number) to determine whether the received message is an original message or a replayed message. (Embodiment 3, Modification 1) 1) When the transmitting UE updates its L2ID, the transmitting UE repeats the application layer message multiple times using both the old L2ID and the new L2ID. 2) The receiving UE accepts the received application layer message using either the old L2ID or the new L2ID as the source L2ID of the message. (Embodiment 3, Modification 2) 1) When the receiving UE receives an application layer message from the transmitting UE, the receiving UE accepts the message containing either the old or new L2 ID as the source field of the received message while the L2 ID is being updated. (Fourth embodiment, first modification) 1) A receiving UE that has lost track of the L2 ID of the transmitting UE requests the transmitting UE to transmit L2 ID information. 2) The transmitting UE transmits the L2 ID information in response to a request from the receiving UE. 3) The receiving UE re-establishes the L2 ID of the sending UE. (Fourth embodiment, second modification) 1) The transmitting UE periodically inserts a "default" L2ID in the L2ID update message to the receiving UE. 2) The receiving UE stores the received "default" L2 ID. 3) If the receiving UE loses track of the L2ID change of the transmitting UE, the receiving UE will use the "default L2ID" to identify the transmitting UE.

[0175] (Features of the Disclosed Embodiments) Beneficially, the above-described embodiments include one or more of the following features, but are not limited to these. (First embodiment, first modification) a) When the transmitting UE updates its L2ID, it sends an L2ID Update Request message to the receiving UE, which includes the new L2ID and additional information, allowing the receiving UE to verify the validity and authenticity of the transmitting UE. b) When the receiving UE receives the L2ID update message from the sending UE, it uses the additional information in the message to verify the validity and authenticity of the received L2ID update message when deciding whether to accept the new L2ID. (Embodiment 1, Modification 2) a) This additional information in the L2ID update message in variant 1 of embodiment 1 represents one or more information elements that uniquely identify the transmitting UE and the communication context, for example, UE-specific information or communication context-specific information related to the transmitting UE and the receiving UE. b) In addition to the new L2ID, the L2ID Update message contains a MAC (hash value) of these information elements that uniquely represents the sending UE and the communication context mentioned above. c) When generating a new L2 ID and MAC (hash value), the transmitting UE uses a set of one or more information elements as input parameters to a KDF function used to derive the new L2 ID and MAC (hash value), thereby ensuring that the new L2 ID and MAC (hash value) reflect information that uniquely identifies the transmitting UE and the communication context. (Embodiment 1, Modification 3) a) In addition to the second modification of the first embodiment, the transmitting UE generates a new L2 ID and MAC (hash value) by including a sequence number in the KDF function. b) The sequence number is unique to one L2ID update message, which prevents types of attacks such as man-in-the-middle replay attacks. c) The sequence number is updated in each subsequent L2 ID Update message from the transmitting UE so that the same sequence number value is used only once. (Embodiment 1, Modification 4) a) The transmitting UE sends an L2 ID update message to the receiving UE. b) When determining whether to accept a new L2ID value from the transmitting UE, the receiving UE verifies the validity and authenticity of the received message based on the description of Variation 1 or Variation 2 of Embodiment 1. (Embodiment 1, Modification 5) a) In addition to the third variant of the first embodiment, when the receiving UE receives an L2ID update message from the transmitting UE, the receiving UE returns a response message (L2ID update response) to the transmitting UE indicating whether the receiving UE accepts the new L2ID based on verification and authentication checks. b) When the transmitting UE receives this response message from the receiving UE, it checks the acknowledgements from each receiving UE individually, and based on this, the transmitting UE takes corrective action if necessary. (Embodiment 1, Modification 6) a) Upon establishing communication, the communicating UEs exchange one or more supported KDF algorithms. b) Based on the exchanged information, the UE determines and agrees on the new L2ID and the KDF algorithm to be used to derive the MAC (hash value) to be sent in the L2ID Update message. (Embodiment 1, Modification 7) a) The communicating UEs exchange a new L2 ID and one or more supported input parameters for the KDF function that derives the MAC (hash value). b) Based on the exchanged information, the UE determines and agrees on a set of input parameters for the KDF function. (Embodiment 2, Modification 1) a) To maximize the chances that all communicating UEs receive the L2 ID update message, one or more of the following sub-variants are used: (Sub-Modification 1) The transmitting UE repeats the L2 ID update message multiple times. (Sub-variant 2) One or more receiving UEs relay the L2 ID update message received from the transmitting UE. (Sub-variant 3) One or more receiving UEs flood the L2 ID update message received from the transmitting UE. (Sub-variant 4) The transmitting UE repeats the L2 ID update message, and / or one or more receiving UEs relay / flood the L2 ID update message received from the transmitting UE. (Embodiment 2, Modification 2) a) In addition to the first modification of the second embodiment, the transmitting UE includes unique information (for example, a sequence number) that is used only once in the L2ID update message to prevent replay attacks. b) The receiving UE checks the uniqueness of the specific information (sequence number) and determines whether the received L2 ID update message is original or a replay of a previous message. (Embodiment 3, Modification 1) a) While the L2ID update is taking place, the transmitting UE sends the same application layer message multiple times to the receiving UE using both the old and new L2IDs in the source L2ID field. b) The receiving UE accepts the application layer message received from the sending UE regardless of whether the individual receiving UE recognizes the old L2ID or the new L2ID as a valid L2ID for the sending UE. (Embodiment 3, Modification 2) a) While an L2ID update is taking place, the receiving UE will accept messages from the sending UE containing either the old L2ID or the new L2ID in the source L2ID field. (Fourth embodiment, first modification) a) If the receiving UE loses track of the L2ID changes of the transmitting UE over time (e.g., if the receiving UE misses the L2ID update message from the transmitting UE for multiple update cycles), it requests the transmitting UE to indicate the mapping between the transmitting UE and the latest L2ID. b) The receiving UE uses the received information from the transmitting UE to re-establish the correlation between the transmitting UE and the latest L2 ID. (Fourth embodiment, second modification) a) The transmitting UE periodically inserts a "default" L2ID in an L2ID update message to the receiving UE. b) The receiving UE identifies a "default" L2ID as the fallback L2ID for the transmitting UE if the receiving UE loses track of changes in the transmitting UE's L2ID over time (e.g., if the receiving UE misses an L2ID update message from the transmitting UE for multiple update cycles). c) If the receiving UE loses track of the L2ID of the transmitting UE over time, it will use a "default" L2ID to identify the transmitting UE.

[0176] Advantages of the present disclosure over current technology (Embodiment 1) The L2ID update procedure provides a way for the receiving UE to verify the received message and the authenticity of the sending UE. This verification and authenticity check mechanism prevents a malicious UE from sending a fake L2ID update message and potentially causing the sending UE's L2ID mapping information to be corrupted in the receiving UE. The verification information in the L2ID update procedure uses a MAC (hash value) to uniquely identify and verify the transmitting UE and the new L2ID. The L2ID Update procedure provides an option for the sending UE to verify the acceptance or rejection of the L2ID Update message by the receiving UE. The KDF negotiation mechanism provides a way for different UE implementations that have multiple different KDF function implementations to negotiate and agree on a single KDF function. The KDF negotiation mechanism provides a way for different UE implementations with different input parameters to negotiate and agree on the same set of input parameters. (Embodiment 2) These methods improve the likelihood that all communicating UEs will successfully receive the L2 ID update message by using one or more mechanisms to allow all UEs to receive multiple copies of the same L2 ID update message. This method prevents replay attacks by using a unique one-time parameter in the L2ID update message, allowing the receiving UE to identify whether the received message is original or a duplicate. (Embodiment 3) During periods of simultaneous periodic L2ID update events, improve the chances of successful reception of application layer message flows by either 1) duplicating messages using both the old and new L2IDs, or 2) accepting either the old or new L2ID. (Embodiment 4) The method provides a mechanism for a receiving UE to re-establish the L2ID change of a transmitting UE when the receiving UE in a communication misses multiple L2ID update cycles.

[0177] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes. (Appendix 1) a first UE (User Equipment) that transmits a message including a Layer 2 Identity (L2ID) and verification information; A second UE receives the message from the first UE and determines whether to accept the L2 ID using the verification information. (Appendix 2) the first UE generates the L2 ID and a first MAC (Message Authentication Code) using a KDF (Key Derivation Function), adds the first MAC to the message, and transmits the message; The second UE generates a second MAC using a KDF, and compares the first MAC with the second MAC to determine whether to accept the L2 ID. 10. The communication system of claim 1. (Appendix 3) The first UE generates the L2 ID and the first MAC by a KDF using a sequence number; The second UE generates the second MAC by a KDF using the sequence number, and compares the first MAC with the second MAC to determine whether to accept the L2 ID. 10. The communication system of claim 2. (Appendix 4) The first UE transmits the L2 ID to the second UE, and then uses the L2 ID for communication. 4. A communication system according to any one of appendices 1 to 3. (Appendix 5) The second UE transmits a response message indicating the determination result of the second UE to the first UE; A communication system according to any one of appendices 1 to 4. (Appendix 6) the first UE and the second UE exchange one or more KDF functions, and generate the L2 ID and the first MAC for the first UE, and generate the L2 ID and the second MAC for the second UE; 4. The communication system of claim 2 or 3. (Appendix 7) the first UE and the second UE exchange parameters, and generate the L2 ID and the first MAC for the first UE, and generate the L2 ID and the second MAC for the second UE; 10. The communication system of claim 2, 3 or 6. (Appendix 8) the first UE transmits the message multiple times; A communication system according to any one of appendices 1 to 7. (Appendix 9) When the second UE receives the message from the first UE, the second UE relays or floods the message. A communication system according to any one of appendices 1 to 8. (Appendix 10) the first UE inserting a different value into each of the plurality of messages; The second UE uses the different value to determine whether the message received by the second UE is an original message or a replayed message. 9. The communication system of claim 8. (Appendix 11) When the first UE updates the old L2ID to a new L2ID, the first UE transmits the message multiple times using the old L2ID and the new L2ID; the second UE accepts the message using either the old L2 ID or the new L2 ID in the message; A communication system according to any one of appendices 1 to 10. (Appendix 12) When the second UE receives the message from the first UE, the second UE accepts the message including either the old L2ID or the new L2ID as the L2ID of the source of the received message. 12. The communication system of claim 11. (Appendix 13) If the second UE cannot track the L2 ID of the first UE, the second UE requests the first UE to transmit the L2 ID; the first UE transmits the L2 ID to the second UE in response to a request from the second UE; the second UE re-establishes the L2 ID of the first UE; 13. A communication system according to any one of appendices 1 to 12. (Appendix 14) The first UE periodically inserts a default L2 ID into the second UE; The second UE receives and stores the default L2 ID; If the second UE cannot track the L2 ID of the first UE, the second UE uses the default L2 ID to identify the first UE. A communication system according to any one of appendices 1 to 13. (Appendix 15) a sending means for sending a message including an L2 ID and verification information to another UE; The verification information allows another UE to determine whether to accept the new L2 ID. UE (User Equipment). (Appendix 16) Further, a generating unit is provided for generating the L2ID and a MAC (Message Authentication Code) using a KDF (Key Derivation Function), the transmitting means adds the MAC to the message and transmits it. UE as described in Appendix 15. (Appendix 17) receiving means for receiving a message including an L2 ID and verification information from another UE; and a determination means for determining whether to accept the L2ID using the verification information. UE (User Equipment). (Appendix 18) the message to which the first MAC (Message Authentication Code) and the L2 ID are added is generated using a KDF (Key Derivation Function); The UE further comprises: a generating means for generating a second MAC using a KDF; the determining means compares the first MAC with the second MAC to determine whether or not to accept the L2 ID; UE as described in Appendix 17. (Appendix 19) sending a message to the UE including the L2 ID and verification information; The verification information enables the UE to determine whether to accept the new L2 ID. Communication method. (Appendix 20) receiving a message including an L2 ID and verification information from the UE; using the verification information to determine whether to accept the L2ID; Communication method. (Appendix 21) causing a computer to perform a process of sending a message including the L2 ID and verification information to the UE; The verification information enables the UE to determine whether to accept the new L2 ID. A non-transitory computer-readable medium storing a program. (Appendix 22) receiving a message from the UE, the message including an L2 ID and verification information; a process of determining whether to accept the L2ID using the verification information; A non-transitory computer-readable medium storing a program for causing a computer to execute the above.

[0178] Those skilled in the art will appreciate that numerous variations and / or modifications may be made to the present disclosure as illustrated in the specific embodiments without departing from the spirit or scope of the disclosure as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

[0179] This application claims the benefit of priority to Indian Patent Application No. 201911033136 filed on August 16, 2019, and Indian Patent Application No. 201911043095 filed on October 23, 2019, the disclosures of which are incorporated herein by reference in their entireties. [Explanation of symbols]

[0180] 1. Communication Systems 3. Mobile devices 5 base station 7 Core Network 20 External Network 31 Transceiver Circuit 33 Antenna 35 User Interface 37 Controller 39 Memory 41 Operating Systems 43 Communication Control Module 51 Transceiver circuit 53 Antenna 55 Network Interface 57 Controller 59 Memory 61 Operating Systems 63 Communication Control Module 71 Transceiver Circuit 75 Network Interface 77 Controller 79 Memory 81 Operating Systems 83 Communication Control Module 100 Communication Systems 110 UE 111 Transmitter 120 UE 121 Receiving unit 122 Judgment section

Claims

1. User Equipment (UE), In the link identifier update procedure for unicast communication on PC5 with other UEs, means for receiving a first message from the other UE, the first message including a new Layer 2 Identity (L2 ID), first security information, and a sequence number; means for verifying that the received first security information and the UE-generated second security information match; means for transmitting a second message to the other UE after the verification; A UE comprising:

2. The UE of claim 1 , wherein the sequence number is incremented for each transmission of an identifier update request message.

3. The UE of claim 2 , wherein the identifier update request message is repeatedly transmitted based on a timer.

4. A communication method for User Equipment (UE), comprising: In the link identifier update procedure for unicast communication on PC5 with other UEs, receiving a first message from the other UE, the first message including a new Layer 2 Identity (L2 ID), security information, and a sequence number; verifying that the received first security information and the UE-generated second security information match; sending a second message to the other UE after the verification; Communication method.

5. The communication method of claim 4 , wherein the sequence number is incremented for each transmission of an identifier update request message.

6. The communication method according to claim 5 , wherein the identifier update request message is repeatedly transmitted based on a timer.

Images