UE and communication methods

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 Art

[0002] There has been development in mobile communication technology. For example, in Releases 14 and 15 of 3GPP (3rd Generation Partnership Project), V2X (Vehicle-to-Everything) communication in LTE (Long Term Evolution) is defined.

[0003] Regarding V2X communication, Non-Patent Document 1 describes research on the security aspect of LTE support for V2X services. Non-Patent Document 1 points out the risk that vehicles are tracked and privacy is invaded.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In view of the above situation, 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 communication.

Means for Solving the Problems

[0006] In a first exemplary aspect, the communication system is A first UE (User Device) that sends a message containing L2ID (Layer 2 Identity) and verification information, The system includes a second UE that receives the message from the first UE and determines whether or not to accept the L2ID using the verification information.

[0007] In the second exemplary embodiment, the UE (User Equipment) is: It includes a transmission means for sending a message containing L2ID and verification information to another UE, The verification information makes it possible to determine whether another UE accepts the new L2ID.

[0008] In a third exemplary embodiment, the UE (User Equipment) is: A receiving means for receiving messages containing L2ID and verification information from other UEs, The system includes a determination means for determining whether or not to accept the L2ID using the verification information.

[0009] In a fourth exemplary embodiment, the communication method is: A message containing the L2ID and verification information is sent to the UE. The verification information is a method that enables the UE to determine whether or not to accept the new L2ID.

[0010] In the fifth exemplary embodiment, the communication method is: Receive a message from the UE containing the L2ID and verification information. This method determines whether or not to accept the L2ID using the aforementioned verification information.

[0011] In the sixth exemplary embodiment, the non-temporary computer-readable medium is: The computer is instructed to perform the process of sending a message containing the L2ID and verification information to the UE. The verification information makes it possible to determine whether the UE accepts the new L2ID. A non - transient computer - readable medium storing a program.

[0012] In a seventh exemplary aspect, a non - transient computer - readable medium includes a process of receiving a message including an L2ID and verification information from a UE, a process of determining whether to accept the L2ID using the verification information, and is a non - transient computer - readable medium storing a program for causing a computer to execute the above.

Advantages of the Invention

[0013] According to the present disclosure, a communication system, a user equipment, a communication method, and a computer - readable medium capable of reducing security risks in communication can be provided.

Brief Description 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 a communication system. [Figure 3] FIG. 3 is a diagram showing an example of a KDF function on the transmission side. [Figure 4] FIG. 4 is a diagram showing an example of a KDF function on the reception side. [Figure 5] FIG. 5 is a diagram showing an example of a KDF function on the transmission side. [Figure 6] FIG. 6 is a diagram showing an example of a KDF function on the reception side. [Figure 7] FIG. 7 is a sequence diagram showing the procedure of a communication system. [Figure 8] FIG. 8 is a sequence diagram showing the procedure of a communication system. [Figure 9A] FIG. 9A is a diagram showing a repeated message from a source UE. [Figure 9B] FIG. 9B is a diagram showing a relay message from a UE. [Figure 9C]Figure 9C shows the flooded messages from the UE. [Figure 9D] Figure 9D shows a combination of messages that have been repeated, relayed, and flooded from the UE. [Figure 10] Figure 10 shows an example of a KDF function for deriving a new sequence number. [Figure 11] Figure 11 is a sequence diagram showing the mechanism for re-establishing the L2ID. [Figure 12] Figure 12 is a sequence diagram illustrating the mechanism that provides the "default" L2ID. [Figure 13] Figure 13 shows a mobile communication system 1. [Figure 14] Figure 14 is a block diagram showing the main components of UE3. [Figure 15] Figure 15 is a block diagram showing the main components of an exemplary (R)AN node 5. [Figure 16] Figure 16 is a block diagram showing the main components of an exemplary core network node. [Modes for carrying out the invention]

[0015] Before describing embodiments of this disclosure, the following explanation 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 the purposes of this disclosure, the following definitions apply. PC5 Wireless interface between two or more UEs Wireless interface between Uu UE and base station Groupcast is a communication mode in which two or more members within a group communicate with each other. Group membership may or may not be managed. If managed, it is expected to be done at the application layer. If not managed, group membership should be defined by other means, such as preconfiguration.

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

[0019] In communication over the LTE PC5 interface, only minimal security considerations and mechanisms are expected at the 3GPP layer, with most security mechanisms being handled at the application layer. This is consistent with other V2X standards such as IEEE 802.11p, IEEE 1609, and ETSI ITS. The 3GPP SA WG2 (SA2) has completed standard work on the eV2X architecture extension for Release 16, based on the architecture extension requirements defined in Stage 1 of Release 15 for 5G NR-based V2X communication in Release 16. From these specifications, 5G V2X, like LTE V2X, supports two types of communication (5G Uu interface and 5G PC5 interface). Communication over 5G Uu supports only unicast mode, similar to the LTE Uu interface. On the other hand, the 5G PC5 interface supports two communication modes, unicast mode and groupcast mode, in addition to broadcast mode. Therefore, in order to realize the new functions of 5G V2X, additional security considerations were necessary, and the 3GPP SA WG3 (SA3) began considering the security aspects of eV2X communication in 5G. The architectural extensions in the Rel-15 LTE V2X specification are based on several new use cases, as described below.

[0020] The overall security architectures for LTE and 5G are defined 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 earlier, 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 of each other. The LTE V2X specification's privacy requirements state that "if a UE uses the same ID in multiple broadcast messages, the vehicle may be tracked and its privacy may be compromised." This could lead to vehicle and user traceability and linkability. It is important to note that the aforementioned privacy issues apply only to the PC5 interface and not to the Uu interface. Existing LTE-Uu unicast security solutions apply to the Uu interface.

[0023] As mentioned above, the SA2 specification defines procedures for V2X communication on PC5, including Layer 2 link establishment, link identifier update, Layer 2 link release, and Layer 2 link modification. Furthermore, current research in SA3 focuses on privacy, particularly in unicast and groupcast communications, and how to prevent privacy issues such as tracking the source L2ID of vehicles or users. An adversary with the ability to connect and link L2 identities to real or long-term (permanent) eV2X endpoint identities can track and trace endpoints across space and time. Such traceability and linking capabilities constitute an attack on 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, the destination L2ID is the broadcast L2ID or groupcast L2ID, and the source L2ID is the ID of the individual group member UE sending the message.

[0025] In groupcast or broadcast mode, changing the source L2ID requires all group member UEs to track this change and continue to identify the source of the message, meaning they always need to track "who sent the message to the group."

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

[0027] This also means that source L2ID changes initiated by a UE must be verifiable by the receiving UE to prevent a malicious UE from interfering with legitimate UE communications. Such verifiability is required because broadcast mode communications are uncontrolled (the recipient's number and ID are unknown), and membership management in groupcasts is less stringent than establishing unicast communications. Therefore, all member UEs in broadcasts and groupcasts must be synchronized with respect to UE L2ID changes.

[0028] Regarding privacy protection, the 3GPP specifications for LTE and 5G V2X communications state that if a UE uses the same ID for communications via the PC5 interface, the vehicle may be tracked and its privacy may be compromised. Therefore, to mitigate the risk of user or vehicle tracking, communication privacy protection is necessary on the PC5 interface. a) Existing SA3 research includes privacy and security solutions for L2ID updates in unicast mode communication. Similar to unicast mode, privacy protections can also be applied to broadcast and groupcast operating modes. In broadcast mode, the sending UE does not know who is listening to the broadcast message. In groupcast mode, a member UE who has left the group or someone who knows the destination L2ID of the groupcast can track and identify the source of the message (vehicle or user ID). b) Changes to the source L2ID in PC5 communication must be verifiable by the receiving UE to prevent a malicious UE from interfering with a legitimate UE and its broadcast and groupcast communication modes. c) Application layer messages (e.g., basic safety messages) continue independently 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 operating modes: communication over a PC5 reference point and communication over a Uu reference point. These two operations can be used independently by the UE for transmission and reception. V2X communication over a PC5 reference point is supported by LTE and NR. V2X communication over a Uu reference point is supported by E-UTRA connected to an EPC or 5GC and / or NR connected to a 5GC. In this release, V2X communication over a Uu reference point uses only unicast transmission and reception. LTE PC5 communication supports only broadcast mode. On the other hand, 5G PC5 supports broadcast mode and groupcast mode in addition to unicast mode communication.

[0030] Identifier for V2X communication procedure: a) Each UE has an L2ID for V2X communication over the PC5 reference point. This is included in the source Layer 2 ID field of each frame that the UE transmits over the Layer 2 link. The UE self-assigns its Layer 2 ID for V2X communication over the PC5 reference point. b) If IP-based V2X messaging is supported, the UE automatically configures a link-local IPv6 address to be used as the source IP address. The UE can use the automatically configured link-local IP address for V2X communication on the PC5 reference point without sending neighbor discovery and neighbor advertisement messages for duplicate address detection. c) If a UE has an active V2X application that requires privacy support in the current geographical area specified by the 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 a predetermined short period of time required by the application. In IP-based V2X communication over a PC5 reference point, the source IP address must also be changed and randomized over time. Changes to the source UE identifier must be synchronized across layers used by the PC5, for example, if the application layer identifier changes or if the source Layer 2 ID and source IP address need to be changed. d) Set the destination Layer 2 ID used for the V2X service to the UE. The Layer 2 ID for V2X messages will be selected based on the setting. e) The source L2ID used for the PC5 interface may differ for each operating mode within the same UE and for different RATs. The table below summarizes the differences in source L2IDs between LTE V2X and 5G V2X operating modes. Different designations for different L2IDs indicate that these ID values ​​may differ.

[0031] Table 1: Types and modes of RAT for PC5 communication [Table 1]

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

[0033] The 3GPP TR 33.836 ("Study on security aspects of 3GPP support for advanced V2X services") outlines existing critical issues and solutions. One of the key challenges is protecting the privacy of groupcast messages on the PC5 interface.

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

[0035] Furthermore, this disclosure relates to a 5G system that supports V2X communication in 5G, in the context of how the source L2ID update procedure provides user privacy protection in broadcast, groupcast, or unicast V2X communication.

[0036] (Description of the embodiment) This disclosure describes several embodiments and variations within each embodiment. These embodiments and variations can be combined in any way.

[0037] (Embodiment 1: Verifiable L2ID update in broadcast and groupcast modes) (Embodiment 1, Modification 1a, General Description) In this proposed embodiment, the communication system 100 comprises UE110 (first UE) and UE120 (second UE) as shown in Figure 1. Although one UE110 and one UE120 are shown in Figure 1, there may be multiple UE110s and / or multiple UE120s.

[0038] UE110 sends a message containing the L2ID (Layer 2 Identity) and verification information to UE120. Figure 1 shows that UE110 includes a transmitter 111, which sends a message containing the L2ID and verification information to another UE, specifically UE120. The verification information allows the other UE to determine whether or not to accept the new L2ID.

[0039] UE120 receives a message from UE110 and uses the verification information to determine whether to accept the L2ID. As shown in Figure 1, UE120 includes a receiving unit 121 and a determination unit 122. The receiving unit 121 receives a message containing the L2ID and verification information from another UE, particularly UE110. The determination unit 122 uses the verification information to determine whether to accept the L2ID.

[0040] In this modified example 1a, UE110 transmits verification information, and UE120 uses this information to determine whether or not to accept the L2ID. Therefore, UE120 can reject communication from a malicious UE, thereby reducing security risks in communication.

[0041] (Embodiment 1, Modification 1b, General Description) This modified example 1b describes Embodiment 1 in more detail.

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

[0043] To verify a message from any member UE, the update message includes information indicating whether the message is valid, i.e., sent by a genuine user. Examples of the information elements used are as follows: 1. Current L2ID 2.New L2ID 3. Group ID (for group casts 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] Steps S1a to S1c in Figure 2 show that the sending UE (UE-Tx) sends an L2ID update request message containing verification information. This information allows the receiving UE to verify the validity of the message's origin.

[0045] S2a to S2c in Figure 2 show that the receiving UEs (UE-1 to UE-3 in Figure 2) use the information contained in the L2ID update message from UE-Tx to verify the validity and authenticity of the message source and determine whether the received message was sent by a legitimate UE. If the validity and authenticity of the message source are confirmed, the receiving UE accepts the received update message. If they cannot be confirmed, the receiving UE does not accept the received update message. This action by the receiving UE prevents malicious UEs from sending false update messages in broadcast, groupcast, or unicast communications.

[0046] For broadcast and groupcast communications, there can be one or more member UEs that receive L2ID update messages. For unicast communications, there is only one UE that receives L2ID update messages.

[0047] (Embodiment 1, Modification 2, Description: Verifiable L2ID update in broadcast and groupcast communications) In this modified version, a key derivation function (KDF) is introduced, and the new L2ID and MAC (or "hash value") are derived using the appropriate inputs as described in the previous section.

[0048] It should be noted that the term "KDF" is generally used to refer to a function that takes 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 also be used in this disclosure.

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

[0050] An example formula for deriving the new L2ID and MAC values ​​can be defined as follows: (New L2ID, MAC) = KDF(Current L2ID, Group ID, V2X Service ID, Location 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 on all peer member UEs in groupcast, broadcast, or unicast communications.

[0052] When a receiving UE receives an L2ID update message, it verifies the validity and authenticity of the message sender. The receiving UE uses the same set of peer's current L2ID and input parameters as the sender. The receiving UE calculates the MAC (hash value) of the input parameters. Next, the receiving UE compares this MAC (hash) value to 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 sent 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. Figure 4 shows an example of a receiving KDF function.

[0053] In this modified example, the transmitting UE includes a generation unit that generates a new L2ID and a first MAC using a KDF function, and the transmitting unit (111 in Figure 1) sends the message with the MAC attached. The receiving UE includes a generation unit that generates a second MAC using a KDF, and the determination unit (122 in Figure 1) compares the first MAC and the second MAC to determine whether or not to accept the L2ID. By using a 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 L2ID.

[0054] (Embodiment 1, Modification 3, Description: Verifiable L2ID update in broadcast and groupcast communications with replay protection) Similar to Modification 2 of Embodiment 1, this modification also describes a method for verifying L2ID updates in broadcast, groupcast, or unicast mode. Furthermore, additional informational elements are included as inputs to the key derivation function to mitigate replay attacks. In this modification, 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] Figure 5 shows the derivation of the L2ID and MAC on the transmitting side, and Figure 6 shows the derivation of the MAC on the receiving side and the verification of the MAC value.

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

[0057] Similar to Modification 2 of Embodiment 1, when the receiving UE receives an L2ID update message, it verifies the validity and authenticity of the message sender. The receiving UE uses the same set of peer's current L2ID and input parameters as the sender. The receiving UE also uses the same sequence number as the sending UE to generate the MAC (hash value). Next, the receiving UE 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] It should be noted that using sequence numbers allows you to verify that a received L2ID update message does not duplicate a previously sent message. This is achieved by the UE incrementing the sequence number each time it sends an L2ID update message.

[0059] (Embodiment 1, Modification 4, Description: One-way update without confirmation) This modification describes a one-way update procedure for updating an L2ID without confirmation. In this modification, the transmitting UE sends the updated new L2ID to the peer UE in broadcast or groupcast mode without receiving an acknowledgment from the receiving UE. Broadcast or groupcast mode is advantageous, for example, when there are many receiving UEs, as it reduces the overhead of receiving and tracking acknowledgments from other UEs. In broadcast mode, it is not possible to know in advance how many receiving UEs are within range.

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

[0061] Furthermore, since there is no acknowledgment sent by the peer UE, overhead is reduced as mentioned above. The sending UE does not need to track acknowledgments from all member UEs. An example of the procedure is shown in Figure 7.

[0062] In Figure 7, S1, the transmitting UE (UE-Tx) updates its own L2ID. Steps S2a to S2c in Figure 7 show that the sending UE (UE-Tx) sends an L2ID update request message containing verification information (e.g., MAC). This MAC (hash) value is calculated based on the method described in Modification 1 or Modification 2 of the embodiment. This information allows the receiving UE to verify the validity of the message sender. Steps S3a to S3c in Figure 7 show that the receiving UEs (UE-1 to UE-3 in Figure 7) use the information contained in the L2ID update message from UE-Tx to verify the validity and authenticity of the message source and determine whether the received message was sent by a legitimate UE. If the validity and authenticity of the message source are confirmed, the receiving UE accepts the received update message. If they cannot be confirmed, the receiving UE does not accept the received update message. This action by the receiving UE prevents malicious UEs from sending false update messages via broadcast, groupcast, or unicast communication.

[0063] (Embodiment 1, Modification 5, Description: Confirmed bidirectional updates) In this modified version, the receiving UE sends an acknowledgment of the L2ID update from the first UE by sending an L2ID update response message. Thus, according to this modified version of the solution, the sending UE can track acknowledgments from other UEs during communication. Therefore, in this modified version, synchronous updates of the new L2ID are always guaranteed.

[0064] The main advantage of this modification is that the transmitting UE can determine whether or not the receiving UE has successfully received the L2ID update message. This modification is advantageous in groupcast mode communication involving a small number of UEs within a group. An example of the procedure is shown in Figure 8.

[0065] S1 in Figure 8 is the same as S1 in Figure 7 of Modification 4 of Embodiment 1. Steps S2a to S2c in Figure 8 are the same as steps S2a to S2c in Figure 7 of Modification 4 of Embodiment 1. Steps S3a to S3c in Figure 8 are the same as steps S3a to S3c in Figure 7 of Modification 4 of Embodiment 1. S4a to S4c in Figure 8 show that the receiving UEs (UE-1 to UE-3) send L2ID update responses to UE-Tx indicating the success or failure of the verification.

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

[0067] For example, negotiation of KDF functions can take place once groupcast or unicast communication is established.

[0068] This modification is advantageous for illustrating different implementation variations of the KDF function by UEs. Furthermore, this modification is useful in 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 unknown in advance, or for groupcast modes with many members participating in the communication.

[0069] (Embodiment 1, Modification 7, Description: KDF input parameter negotiation) Similar to Modification 5 of the previously described embodiment, this modification proposes that the UE should support a similar discovery / negotiation / agreement procedure with respect to the set of input parameters for deriving the KDF between member UEs.

[0070] A variation of this solution introduces a mechanism for communicating UEs to negotiate and agree on the KDF, as described in Modification 1 and Modification 2 of Embodiment 1. In this variation, the concept of possible differences or changes in the input parameters used by the KDF is introduced among communicating UEs. In this case, the communicating UEs can exchange the supporting input parameters used by the KDF and negotiate a set of input parameters agreed upon by all UEs.

[0071] For example, parameter negotiation for a KDF function can be performed once groupcast or unicast communication is established.

[0072] This modification is advantageous for considering different implementation variations of the KDF function by the UE. Furthermore, this modification is useful for unicast 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 may not be known in advance.

[0073] (Embodiment 2: Improved delivery of L2ID updates in groupcast and broadcast communications) (Embodiment 2, Modification 1: Improved delivery of L2ID updates in groupcast and broadcast communications) In unicast communication, only two UEs are involved in the communication. In this case, ensuring the successful delivery of L2ID updates by defining a bidirectional request / response message exchange is rather trivial. 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 L2ID update messages (for example, due to poor radio conditions). In this state, such UEs can continue to receive groupcast or broadcast messages (because the destination L2ID is the groupcast or broadcast L2ID), but they can no longer distinguish where the groupcast or broadcast message originated from. This is because a UE that misses an L2ID update from a particular source UE can no longer track the continuity of L2IDs from that particular source UE, and as a result, cannot identify who a particular source L2ID belongs to.

[0075] In this regard, it is important to increase the likelihood that L2ID update messages will be successfully delivered in groupcast and broadcast modes. This disclosure discusses two modifications to achieve this objective.

[0076] This modified version maximizes the opportunity for L2ID updates to be received by all group members and introduces a mechanism to resynchronize the receiving UE if the original L2ID update message is missed.

[0077] As an example, consider a scenario where one member UE misses an L2ID update from the sending UE. In this case, all but one peer UE successfully receive the updated L2ID from the original transmission. After a certain period of time, the sending UE repeatedly sends L2ID update messages. This allows the member UE that missed the update in the initial transmission to receive the updated L2ID from the same UE.

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

[0079] The following are some of the secondary modifications of Modification 1. Modification 1.a: Repetition by the transmitting UE Variation 1.b: Relay by the receiving UE Modification 1.c: Flooding by the receiving UE Variation 1.d: Combinations of (a) to (c) Figures 9A to 9D below show these modified versions.

[0080] Figure 9A shows a repeating message from the source UE. In this case, UE-4 misses the initial L2ID update message sent by UE-1, while UE-2 and UE-3 successfully receive the initial L2ID update message. However, UE-4 successfully receives the same update from UE-1 in the repeating message. The dashed line indicates the repeating message.

[0081] Figure 9B shows the relayed message from a UE that successfully received the original L2ID update message. In this case, UE-4 missed the initial L2ID update message sent by UE-1, but UE-2 and UE-3 successfully received the initial L2ID 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 a UE that successfully received the original L2ID update message. In this case, UE-4 missed the initial L2ID update message sent by UE-1, while UE-2 and UE-3 successfully received the initial L2ID update message. However, UE-4 successfully receives the same update 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 a UE that successfully received the original L2ID update message. In this case, UE-4 missed the initial L2ID update message sent by UE-1, while UE-2 and UE-3 successfully received the initial L2ID 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 repeated / relayed / flooded messages from UE-1, UE-2, and UE-3.

[0084] Alternatively, in the modified versions described above, 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). For example, a UE can detect such duplicate receipts of the same message and discard the duplicates.

[0085] In another example, repeated / relayed / flooded messages may be sent to a separate L2ID that is specifically intended to deliver 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: Improved delivery of L2ID updates in groupcast and replay-protected broadcasts) This modified version introduces additional functionality to Modification 1 of Embodiment 2. It prevents replay attacks such as man-in-the-middle attacks by malicious UEs.

[0087] This extension can be applied to all of the sub-modifications of Modification 1 of Embodiment 2 (i.e., Modifications 1.a to 1.d). The additional functionality in this modification can be described as follows.

[0088] In Embodiment 2, Modification 1, and Sub-Modifications 1.a to 1.d, a sequence number is introduced when generating repeated messages. Each message is assigned a valid sequence number (value). Therefore, when a message is repeated, the sequence number of the repeated message is different from that of 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] Please note that the sequence numbers used in this modified example are used for a different purpose than the sequence numbers introduced in Modified Example 2 of Embodiment 1.

[0090] For example, this sequence number can be defined in a way that is more complex than simply being a monotonically increasing number in each consecutive repetition / replay / flooding of the same message. Otherwise, it is obvious that an attacker could assume N+1 as the next sequence number and execute a replay attack.

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

[0092] In another example, the initial value of the sequence number can be randomly selected by the sender, and subsequent repeating messages can use a monotonically increasing sequence number as input. In this case, the sender communicates the initial value to the recipient in a secure manner (e.g., an encrypted message using an existing security context, such as an encryption key).

[0093] In these examples, additional parameters unrelated to the sequence number can be used as inputs 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 additional parameters as input parameters. In Figure 10, the timestamp is used as an additional parameter.

[0095] (Embodiment 3: Improving the delivery of application layer messages in groupcast, broadcast, and unicast communications) (Embodiment 3, Modification 1: Duplicate communication during L2ID update) The L2ID update procedure described in Embodiments 1 and 2 protects user and vehicle privacy in V2X communication. This mechanism is configured by the system, self-configured by the UE itself, or occurs periodically at specified intervals.

[0096] It should be noted that this L2ID update procedure occurs independently of application layer communication using the PC5 interface between UEs (such as basic safety messages to avoid traffic accidents). This means that application layer message events are not aware of this L2ID update, and the application layer message flow is triggered and continues independently of such an L2ID update event. This event independence generally follows the principle of the layer concept that is common in communication systems. If an L2ID update event occurs simultaneously with the application layer message flow, the L2ID update event should not cause unexpected communication interruptions between UEs involved in communication on the PC5 interface. This situation applies to broadcast, groupcast, and unicast mode communications. If application layer communication is interrupted by an event at a lower layer, 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 of 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 application layer service may be interrupted as a result. It should be noted that typical V2X application layer communication includes basic safety messages to avoid traffic accidents that require very low-latency communication. Therefore, preventing communication interruptions at the application layer is crucial. Such events can make the difference between an accident occurring or not.

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

[0099] In this modified example, a UE involved in broadcast, groupcast, or unicast communication identifies an event in which its L2ID changes periodically. The UE then sends the same application layer message multiple times (e.g., twice) using both the old and new L2IDs as source L2IDs. This ensures that the same application layer message is repeated multiple times (e.g., twice) using two different source L2IDs. This maximizes the likelihood that other UEs in communication can successfully receive the application layer message without interruption, even if the UE's L2ID changes.

[0100] In one example, the L2 layer responsible for updating the L2ID indicates to the upper layer (application layer) that an L2ID change has occurred. The upper layer (application layer) then sends 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. In IP-based communication, the source IP address and source L2ID are updated simultaneously. In this case, the explanation of this variant regarding L2ID changes also applies to IP address changes.

[0101] In another example, Layer 2, responsible for L2ID updates, detects the period during which L2ID updates will occur. During this time, Layer 2 sends application layer messages from the upper layer using both the old and new L2IDs in the communication mode used by the application layer (broadcast, groupcast, or unicast). This variant is more applicable when application layer communication uses non-IP-based communication.

[0102] In one example, the message sent by the transmitting UE is successfully received in both of the following scenarios. Therefore, this modification is advantageous in communication modes with multiple receiving UEs, such as broadcast mode and groupcast mode. a) Even if the receiving UE is in the process of updating the sending UE's L2ID, the receiving UE can recognize the old L2ID as a valid ID for the sending UE. In this case, the receiving UE will recognize a message sent by the sending UE that contains 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 the valid ID of the sending UE. In this case, the receiving UE will recognize messages sent by the sending UE that include the new L2ID in the source L2ID field.

[0103] For example, the time frame in which this replication transmission takes place is defined by a timer called the "L2ID update safeguard timer." For example, this timer may be configured by the system or self-assigned by the UE itself.

[0104] (Embodiment 3, Modification 2: Acceptance of multiple L2IDs during L2ID update) In this modified version, the receiving UE accepts a message from the sending UE that includes either the old or new L2ID as the message's source ID. The old and new L2IDs used by the sending UE refer to those used / are used before and after the L2ID change procedure, respectively. This modified solution can be applied to broadcast, groupcast, and unicast communications.

[0105] A variation of this solution addresses the relative timing difference between the time the sending UE begins using the new L2ID in the message and the time the receiving UE begins recognizing the sending UE's new L2ID. In other words, this mechanism addresses the following race condition: 1) A scenario in which the sending UE begins using the new L2ID as the source address in a message, 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 the receiving UE already recognizes the new L2ID as a valid source L2ID for the sending UE, but the message from the sending UE arrives at the receiving UE containing the old L2ID.

[0106] In either scenario, without the mechanism described in this section, the receiving UE would discard the received message because the L2ID in the sending UE's source address is invalid. The mechanism described in this section allows the receiving UE to receive messages from the sending UE without discarding them, thus avoiding 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 the new L2ID.

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

[0108] In another example, the receiving UE uses a time frame to accept messages from the sending UE with both the old and new L2IDs. The definition and usage of this time frame are the same as the "L2ID update safeguard timer" described in Modification 1 of Embodiment 3 above. When this timer expires, the receiving UE stops receiving messages containing the sending UE's old L2ID. As a result, the receiving UE switches to receiving only the sending UE's new L2ID.

[0109] In IP-based communication, changes to both the IP address and L2ID occur simultaneously. In this case, the mechanism described in this modified example applies to both the IP address and the L2ID.

[0110] (Embodiment 4: Mechanism for recovering UEs that missed L2ID updates in multiple update cycles) (Embodiment 4, Modification 1: Explicit Query) The L2ID update mechanism described in Embodiments 1, 2, and 3 is performed by the source UE communicating the old (i.e., current) L2ID and the new L2ID. This mechanism "rescues" UEs that have missed multiple L2ID updates. This update is transmitted to other UEs in communication, depending on the mode used (broadcast, groupcast, and unicast).

[0111] It should be noted that this L2ID update mechanism ensures that only two immediately consecutive L2ID values ​​are communicated. For example, an L2ID for generation "N" is followed by an ID for generation "N+1", and these two L2IDs are sent in the L2ID update message.

[0112] This messaging scheme means that if a receiving UE misses one L2ID update cycle, the next L2 update from the same UE will include the old (i.e., current) L2ID, which is unknown to the UE that missed the previous L2ID update cycle. In this case, the UE will be unable to track the sequence of L2IDs for a given UE during communication. For example, if UE-A's L2ID 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 L2ID update cycle (the update from ID value #2 to ID value #3), this 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 are from the same UE.

[0113] Generally, if a receiving UE fails to receive an L2ID update in one or more update cycles, it cannot establish continuity of L2ID changes in subsequent L2ID updates for a given UE during communication.

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

[0115] Each UE in communication using the PC5 interface defines a "default" L2ID. This "default ID" is used as a fallback L2ID, and is used by the receiving UE as a means to re-establish the association between the sending UE and the currently used (i.e., latest) 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 has a more persistent nature. In this case, it is implicitly known to all UEs during communication, such as a system setting or an L2ID value statically assigned to each UE.

[0117] In another example, this "default" L2ID can be created by a clear expression based on the last known L2ID from 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") to specify that it is the "default" L2ID for a given source UE.

[0118] In this modified version, 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 via the PC5 interface, requesting the UE to send the latest L2ID. In other words, this modified version can be summarized as a recovery method when the receiving UE loses the ability to track the source UE's L2ID. This is shown in Figure 11.

[0119] Figure 11 shows the mechanism by which the UE re-establishes the L2ID when it misses L2ID updates on PC5 communication multiple times. S1 in Figure 11 shows the 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 UE-1, for example, to request UE-1 to provide the latest L2ID based on the most recent L2ID of UE-1 that UE-2 is aware of. This message also includes other information that identifies the requesting entity (UE-2) as a valid and legitimate UE in communication. In S3 of Figure 11, UE-1 verifies the validity of the request received in S2. In S4 of Figure 11, if the validity check in S3 is successful, UE-1 sends the latest (current) L2ID to UE-2. S5 in Figure 11 shows UE-2 receiving the message from S4 and recovering the L2ID of UE-1. S6 in Figure 11 shows that UE-2 can identify the message sent from UE-1 as the source.

[0120] (Embodiment 4, Modification 2: Periodic updates) In another example, the UE in question can voluntarily and periodically include a “default” L2ID in all L2ID update messages to all receiving UEs. This mechanism is intended to “rescue” UEs that have missed multiple L2ID updates. For the purpose of resynchronizing with the latest L2ID of the sending UE, this “default” L2ID is relatively persistent in time compared to the regular L2ID, which changes periodically. In other words, this variation can be summarized as a preventative measure to avoid receiving UEs losing track of the sending UE's L2ID. This is shown in Figure 12.

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

[0122] S1 in Figure 12 indicates that UE-1 sends an L2ID update request message to the peer UE during communication. This message contains 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 indicates that UE-2 holds UE-1's "default" L2ID.

[0123] (Other embodiments) (System Overview) Figure 13 is a schematic diagram showing a mobile (cellular or wireless) communication system 1 to which the above embodiment can be applied.

[0124] In this network, users of mobile devices 3 (UEs) can communicate with each other and other users via their respective base stations 5 and core network 7 using appropriate 3GPP radio access technologies (RATs), such as E-UTRA and / or 5G RATs. It will be understood that many base stations 5 form a (radio) access network or (R)AN. As will be understood by those skilled in the art, Figure 13 shows one mobile device 3 and one base station 5 for illustrative purposes, but when the system is implemented, it will typically include other base stations and mobile devices (UEs).

[0125] Each base station 5 controls one or more associated cells (directly or via other nodes such as home base stations, relays, remote radio heads, and distributed units). Base stations 5 that support the E-UTRA / 4G protocol are called "eNBs," and base stations 5 that support the Next Generation / 5G protocol are called "gNBs." It will be understood 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] The mobile device 3 and its serving base station 5 are connected via an appropriate air interface (e.g., a so-called "Uu" interface and / or similar). Adjacent base stations 5 are connected to each other via appropriate inter-base station interfaces (e.g., a so-called "X2" interface, an "Xn" interface and / or similar). Base stations 5 are also connected to core network nodes via appropriate interfaces (e.g., so-called "S1", "N1", "N2", "N3" interfaces and / or similar).

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

[0128] The core network 7 also provides connectivity to an external IP network 20 (such as the Internet). The components of this 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 showing the main components of the UE3 shown in Figure 13. As shown in Figure 14, the UE3 includes a transceiver circuit 31 that can operate to send and receive signals with connected nodes via one or more antennas 33. Although not shown in Figure 14, the UE3 naturally has all the usual functions of a conventional mobile device (such as a user interface 35), which may be provided by hardware, software, and firmware, or any combination thereof, as appropriate. The 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 UE3 according to the software stored in memory 39. The controller 37 can be implemented, for example, by one or more CPUs (Central Processing Units). The controller 37 can also load software (computer programs) from memory 39 and execute the loaded software, thereby performing the UE3 processing described above with reference to the sequence diagram and flowchart of the embodiment described above.

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

[0132] The software includes, in particular, 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 submodule) is responsible for signaling and processing (generating / transmitting / receiving) uplink / downlink data packets between the UE3 and other nodes such as the base station / (R)AN node 5, MME, AMF10 (and other core network nodes). Such signaling may include, for example, well-formatted signaling messages related to connection establishment and maintenance (e.g., RRC messages), and NAS messages such as periodic location update-related messages (e.g., tracking area updates, paging area updates, location area updates).

[0133] ((R)AN node) Figure 15 is a block diagram showing the main components of an exemplary (R)AN node 5, for example, a base station (eNB in ​​LTE, gNB or ngNB in ​​5G), as shown in Figure 13. As shown in the figure, the (R)AN node 5 includes transceiver circuitry 51 capable of transmitting and receiving signals with connected UE3 via one or more antennas 53 and transmitting and receiving signals with other network nodes (directly or indirectly) via a network interface 55. A controller 57 controls the operation of the (R)AN node 5 according to software stored in memory 59. The controller 57 can be implemented, for example, by one or more CPUs. Furthermore, the controller 57 can perform the processing that the core network node performs by loading software (computer programs) from memory 59 and executing the loaded software. The software may, for example, be pre-installed in memory 59 and / or downloaded via a communication network or from a removable data storage device (RMD).

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

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

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

[0137] (Core network node) Figure 16 is a block diagram showing the main components of an exemplary core network node shown in Figure 13, such as AMF10, SMF11, SEAF12, AUSF13, UPF14, UDM15, ARPF16, SIDF17, PCF18, AF19, etc. The core network node is contained in 5GC. As shown in the figure, the core network node includes transceiver circuitry 71 that can operate to send and receive signals with other nodes (including UE3) via a network interface 75. The controller 77 controls the operation of the core network node according to software stored in memory 79. The controller 77 can be implemented, for example, by one or more CPUs. Furthermore, the controller 77 can perform the processing that the core network node performs by loading software (computer programs) from memory 79 and executing the loaded software. The software may be, for example, pre-installed in memory 79 and / or downloaded via a communication network or from a removable data storage device (RMD). The software includes, in particular, an operating system 81 and a communication control module 83 having at least a transceiver control module.

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

[0139] The communication control module 83 (using a transceiver control submodule) is responsible for processing (generating / transmitting / receiving) signaling between the core network node and other nodes such as UE3, base station / (R)AN node 5 (e.g., "gNB" or "eNB"), either directly or indirectly. Such signaling may include, for example, appropriately formatted signaling messages related to the procedures described herein, such as NGAP messages (i.e., messages from the N2 reference point) for transmitting NAS messages to UEs, etc.

[0140] AMF10 provides UE-based authentication, authorization, and mobility management services. It provides services for session management functions. It also provides services to other AMFs, policy control functions18, short message service functions, location management functions, gateway mobile location center, and NEF via a name-of-service-based interface. Key AMF services include registration, connectivity, reachability, and mobility management. It also functions as a termination point for the RAN control plane interface (N2).

[0141] SMF11 manages UE sessions and assigns IP addresses to UE3. It also selects and controls UPF14 for data transfer. UEs with multiple sessions may be assigned a separate SMF for each session. Furthermore, it interacts with the user plane function 14 for efficient routing of user packets.

[0142] SEAF12 generates a unified anchor key KSEAF (common to all accesses) that can be used by UE3 and the serving network to protect subsequent communications for primary authentication. In scenarios where UE3 is connected to both 3GPP access (visiting network) and non-3GPP access (home network), there may be two anchor keys.

[0143] The AUSF13 component handles authentication requests for 3GPP access and non-3GPP access networks. The AUSF13 component interacts with the security anchor function 12 to authenticate user device 3. A set of values ​​from the Universal Subscriber Identification Module is used by the authentication credential repository and processing functions. The subscriber identifier is used to uniquely identify the subscriber and to mutually authenticate UE3 and the 5G core network 7. AUSF13 provides the necessary authentication and authorization processes and acts as a terminal point for user plane security. It also handles network slice security and Enhanced International Mobile Subscriber Identity Privacy.

[0144] UPF14 supports packet routing and forwarding, packet inspection, and QoS processing. It also functions as an external PDU session point for interconnection to data networks and as an anchor point for movement within and between RATs. This is a critical function, requiring efficient packet processing within sub-milliseconds. A decrease in the speed of this function significantly increases packet latency, degrading the user's perceived quality. UPF14 utilizes the services of session management function 11.

[0145] UDM15 provides services to AMF10, SMF11, SMSF, NEF, and AUSF13. These services include subscription data storage, context data management, and authentication services, all integrated with AUSF13. Subscription data management is used by NFs (AMF10 and SMF11) to retrieve subscription data for UEs associated with consumer NFs from UDM15. It is also used by consumer NFs to subscribe to or unsubscribe from data change notifications. UDM15 allows previously subscribed consumer NFs (AMF10, SMF11, SMSF) to receive notifications via the notification service when UDM15 determines that it has changed its subscription data.

[0146] ARPF16 (usually paired with UDM15) stores long-term security credentials, such as the key K of EPS AKA or EAP-AKA, for authentication. ARPF16 can use long-term security credentials as input to execute cryptographic algorithms and create authentication vectors.

[0147] PCF18 controls network behavior by supporting a unified policy framework. It also provides policy rules for control plane functions. For example, AMF10 provides policies related to access and mobility management, UE policies for access network discovery and selection, and UE route selection policies.

[0148] AF19 enables application influence over traffic routing, NEF access, and interaction with the policy framework for policy control. This feature significantly impacts reliability and security because core functionality is exposed at the application level.

[0149] NEF can expose network functions that support monitoring, provisioning, and policy / billing to external parties. Exposing network functions consists of: (i) exposing network events to external and internal core network NFs; (ii) exposing provisioning functions to external functions; (iii) exposing policy and billing functions to external functions; and (iv) exposing functions within the core network for analysis.

[0150] In the embodiments described above, the program may be stored and provided to the computer using any type of non-temporary computer-readable medium. Non-temporary computer-readable medium includes any type of tangible storage medium. Examples of non-temporary computer-readable medium include magnetic storage media (such as floppy disks, magnetic tapes, and hard disk drives), magneto-optical storage media (e.g., magneto-optical disks), CD-ROMs (compact disc read-only memory), CD-Rs (compact disc recordable), CD-R / Ws (compact disc rewritable), and semiconductor memory (such as maskROMs, PROMs (programmable ROMs), EPROMs (erasable PROMs), flash ROMs, and RAMs (random access memory)). The program can be provided to the computer using any type of temporary computer-readable medium. Examples of temporary computer-readable medium include electrical signals, optical signals, and electromagnetic waves. Temporary computer-readable medium can be provided to the computer via wired communication lines (e.g., electric wires or fiber optics) or wireless communication lines.

[0151] (Changes and replacements) Detailed embodiments have been described above. As those skilled in the art will understand, many modifications and substitutions can be made to the embodiments described above, while benefiting from the disclosures embodied in the embodiments. Only a few of these substitutions and modifications are described here as examples.

[0152] Embodiments of this 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 L2ID updates and IP address updates are synchronized within the UE so that they occur simultaneously in two different layers, similar results can be achieved by applying the procedures described in this disclosure to different layers.

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

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

[0155] The terms “User Equipment” or “UE” (terms used by 3GPP), “Mobile Station,” “Mobile Device,” 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. The terms “UE” and “Wireless Equipment” will be understood to also include stationary devices that remain stationary for extended periods.

[0156] UEs include, 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 power generators, batteries, nuclear systems and / or related equipment, heavy electrical equipment, pumps including vacuum pumps, compressors, fans, blowers, ventilators, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or their application systems, tools or molds, rolls, conveying equipment, lifting equipment, material handling equipment, textile machinery, sewing machines, printing and / or related equipment, paperworking machinery, chemical machinery, mining machinery and / or construction machinery and / or related equipment, agricultural, forestry, and fisheries machinery and equipment, safety and environmental protection equipment, tractors, precision bearings, chains, gears, power transmission systems, lubrication systems, valves, pipe fittings and / or application systems of any of the aforementioned equipment or machines).

[0157] UE may be, for example, items of transport equipment (e.g., transport equipment such as railway cars, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, water vehicles such as ships, aircraft, rockets, satellites, drones, balloons, etc.).

[0158] UE may be, for example, an item of information and communication equipment (e.g., computer and related equipment, communication-related equipment, electronic components, etc.).

[0159] UE may include, for example, refrigerators, refrigerator applications, trade and / or service industry equipment, vending machines, automated service machines, office machinery or equipment, home appliances and electronic equipment (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] UE may be, for example, an electrical application system or device (e.g., electrical application systems or devices such as: X-ray systems; particle accelerators; radioisotope devices; acoustic equipment; electromagnetic application devices; electronic power application devices, etc.). UE may also be, for example, electronic lamps, lighting fixtures, measuring instruments, analyzers, testers, or measuring or sensing devices (e.g., smoke detectors, motion sensors, motion sensors, wireless tags, etc.), wristwatches or clocks, laboratory equipment, optical devices, medical equipment and / or systems, weapons, cutlery items, hand tools, 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 other electronic devices, such as a personal computer or electrical measuring instrument).

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

[0163] An Internet of Things (or “Thing”) may include appropriate electronics, software, sensors, network connectivity, and / or similar, which can collect and exchange data with each other and with other communication devices. An IoT device may include automated devices that follow software instructions stored in internal memory. An IoT device may operate without requiring human monitoring or interaction. An IoT device may be stopped and / or inactive for extended periods. An IoT device may be implemented as part of (generally) stationary equipment. An IoT device may be embedded in non-stationary equipment (e.g., a vehicle) or attached to an animal or person being monitored / tracked.

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

[0165] IoT devices are sometimes also called 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 can 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, its contents 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 communication applications [Table 2]

[0167] Applications, services, and solutions include MVNO (Mobile Virtual Network Operator) services, emergency radio 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 radio 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 network / DTN (Delay Tolerant Networking) services.

[0168] Furthermore, the UE categories described above are merely examples of applications of the technical concepts and exemplary embodiments described in this document. Needless to say, these technical concepts and embodiments are not limited to the UEs described above and can be modified in various ways.

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

[0170] Each controller comprises, for example, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), microprocessors (MPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (control buses, data buses, address buses, etc.), direct memory access (DMA) functions, hardware or software-implemented counters, pointers, and / or timers and / or similar, and any suitable form of processing circuitry.

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

[0172] The mechanism presented in this disclosure includes message exchange between UEs having specific information elements. In some cases, UEs may engage in D2D communication or direct communication. Therefore, a breach can be detected by monitoring the UE communications.

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

[0174] (Overview of the method) The above embodiments illustrate exemplary methods and include the following steps: (Embodiment 1, Modification 1) 1) The transmitting UE sends the new L2ID 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 or not to accept the new L2ID. (Embodiment 1, Modification 2) 1) The transmitting UE inputs the set of input parameters into the KDF and obtains the new L2ID 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 the new L2ID and MAC (hash value). 2) The receiving UE inputs the sequence number in addition to the same set of input parameters into the KDF, calculates the MAC (hash value), and compares it with the MAC received from the transmitting UE. (Embodiment 1, Modification 4) 1) The transmitting UE sends the new L2ID and verification information to the receiving UE. Assuming that all receiving UEs have received the new L2ID and that verification was successful, they initiate communication using the new L2ID. (Embodiment 1, Modification 5) 1) The transmitting UE sends the new L2ID 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 or not to accept the new L2ID. 3) The receiving UE returns an L2ID update response message to the sending UE indicating whether the verification was successful or unsuccessful. (Embodiment 1, Modification 6) 1) During communication, the UE exchanges supported KDF functions and derives a new L2ID and MAC (hash value) when communication is established. 2) The UEs communicating agree on the KDF function to use. (Embodiment 1, Modification 7) 1) During communication, the UE exchanges the supported parameters for the KDF function and derives a new L2ID and MAC (hash value) when communication is established. 2) The UE, during communication, agrees on the parameters for the KDF function to be used. (Embodiment 2, Modification 1) 1) (Variation 1) When an L2ID update message is sent, the sending UE repeats the same message multiple times. 2) (Variation 2) When one or more receiving UEs receive an L2ID update message from a transmitting UE, these receiving UEs relay the same message. 3) (Variation 3) When one or more receiving UEs receive an L2ID update message from a sending UE, these receiving UEs flood the same message. 4) (Variation 4) When an L2ID update message is sent, 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 an L2ID update message is sent, the sending UE inserts a unique, one-time value (e.g., 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 the original message or a replayed message. (Embodiment 3, Modification 1) 1) When the sending UE updates the L2ID, the sending UE uses both the old and new L2IDs to repeat the application layer message multiple times. 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 sending UE, it accepts the message containing either the old or new L2ID as the source field of the received message while the L2ID update is in progress. (Embodiment 4, Modification 1) 1) A receiving UE that has lost track of the transmitting UE's L2ID requests the transmitting UE to send the L2ID information. 2) The transmitting UE sends L2ID information in response to a request from the receiving UE. 3) The receiving UE re-establishes the L2ID of the transmitting UE. (Embodiment 4, Modification 2) 1) The sending UE periodically inserts a "default" L2ID into the L2ID update message sent to the receiving UE. 2) The receiving UE stores the received "default" L2ID. 3) If the receiving UE loses track of the change in the transmitting UE's L2ID, the receiving UE will use the "default L2ID" to identify the transmitting UE.

[0175] (Functionality of the disclosed embodiment) Beneficially, the embodiments described above, though not limited to them, include one or more of the following features: (Embodiment 1, Modification 1) a) When the transmitting UE updates its L2ID, it sends an L2ID update request message to the receiving UE containing the new L2ID and additional information, which allows the receiving UE to verify the validity and authenticity of the transmitting UE. b) When the receiving UE receives an 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 or not to accept the new L2ID. (Embodiment 1, Modification 2) a) In the modified example 1 of Embodiment 1, this additional information in the L2ID update message 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 includes the MAC (hash value) of these information elements which uniquely represent the sending UE and the aforementioned communication context. c) When the transmitting UE generates a new L2ID and MAC (hash value), it uses a set of one or more information elements as input parameters to the KDF function used to derive the new L2ID and MAC (hash value). This ensures that the new L2ID and MAC (hash value) reflect information that uniquely identifies the transmitting UE and the communication context. (Embodiment 1, Modification 3) a) The transmitting UE, in addition to the modified example 2 of Embodiment 1, includes a sequence number for the KDF function and generates a new L2ID and MAC (hash value). b) The sequence number is unique to each L2ID update message. This prevents types of attacks such as man-in-the-middle replay attacks. c) The sequence number is updated in each subsequent L2ID update message from the sending UE so that the same sequence number value is used only once. (Embodiment 1, Modification 4) a) The sending UE sends an L2ID update message to the receiving UE. b) When the receiving UE determines whether to accept a new L2ID value from the transmitting UE, it verifies the validity and authenticity of the received message based on the description in Modification 1 or Modification 2 of Embodiment 1. (Embodiment 1, Modification 5) a) In addition to the modification 3 of Embodiment 1, when the receiving UE receives an L2ID update message from the sending UE, it sends back a response message (L2ID update response) to the sending UE indicating whether or not the receiving UE accepts the new L2ID, based on verification and authentication checks. b) Upon receiving this response message from the receiving UE, the sending UE checks the acknowledgments from each individual UE. Based on these results, the sending UE takes corrective action as necessary. (Embodiment 1, Modification 6) a) When a UE is communicating, it exchanges one or more supported KDF algorithms once communication is established. b) Based on the exchanged information, the UE determines and agrees on the KDF algorithm to be used to derive the new L2ID and MAC (hash value) to be sent in the L2ID update message. (Embodiment 1, Modification 7) a) During communication, the UE exchanges one or more supported input parameters for the KDF function that derives the new L2ID and MAC (hash value). b) Based on the exchanged information, the UE determines and agrees on the set of input parameters for the KDF function. (Embodiment 2, Modification 1) a) To maximize the chances that all UEs in communication receive the L2ID update message, use one or more of the following sub-modification mechanisms: (Variation 1) The sending UE repeats the L2ID update message multiple times. (Variation 2) One or more receiving UEs relay the L2ID update message received from the transmitting UE. (Variation 3) One or more receiving UEs flood the L2ID update messages received from the transmitting UE. (Variation 4) The transmitting UE repeatedly sends L2ID update messages, and / or one or more receiving UEs relay / flood the L2ID update messages received from the transmitting UE. (Embodiment 2, Modification 2) a) In addition to the modification 1 of Embodiment 2, the transmitting UE includes unique information (e.g., a sequence number) that is used only once in the L2ID update message to prevent replay attacks. b) The receiving UE verifies the uniqueness of the unique information (sequence number) and determines whether the received L2ID update message is the original or a replay of the previous message. (Embodiment 3, Modification 1) a) While the L2ID is being updated, the sending UE sends the same application layer message to the receiving UE multiple times, 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 the L2ID is being updated, the receiving UE accepts messages from the sending UE that contain either the old L2ID or the new L2ID in the source L2ID field. (Embodiment 4, Modification 1) a) If a receiving UE can no longer track the changes in the sending UE's L2ID over time (for example, if the receiving UE misses L2ID update messages from the sending UE over multiple update cycles), it requests the sending UE to provide a mapping between the sending UE and the latest L2ID. b) The receiving UE uses the information received from the transmitting UE to re-establish the correlation between the transmitting UE and the latest L2ID. (Embodiment 4, Modification 2) a) The sending UE periodically inserts a "default" L2ID into the L2ID update message sent to the receiving UE. b) If the receiving UE is unable to track changes in the sending UE's L2ID over time (for example, if the receiving UE misses L2ID update messages from the sending UE over multiple update cycles), the receiving UE identifies the “default” L2ID as the sending UE’s fallback L2ID. c) If the receiving UE is unable to track the change in the transmitting UE's L2ID over time, the receiving UE will use the "default" L2ID to identify the transmitting UE.

[0176] (Advantages of this disclosure compared to existing technology) (Embodiment 1) The L2ID update procedure provides a method 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, which could potentially cause the receiving UE to obtain L2ID mapping information from the sending UE. The verification information in the L2ID update procedure uses MAC (hash value) to uniquely identify and verify the sending UE and the new L2ID. The L2ID update procedure provides the sending UE with an option to verify whether the receiving UE has accepted or rejected the L2ID update message. The KDF negotiation mechanism provides a way to negotiate and agree on a single KDF function for various UE implementations that have multiple different KDF function implementations. The KDF negotiation mechanism provides a way to negotiate and agree on the same set of input parameters for various UE implementations with multiple different input parameters. (Embodiment 2) These methods improve the likelihood that all UEs in communication will successfully receive the L2ID update message by using one or more mechanisms to ensure that all UEs receive multiple copies of the same L2ID update message. This method prevents replay attacks by using a one-time parameter unique to the L2ID update message, allowing the receiving UE to identify whether the received message is original or a copy. (Embodiment 3) During periods when periodic L2ID update events occur simultaneously, the likelihood of application-layer message flow being successfully received can be improved by either 1) duplicating messages using both the old and new L2IDs, or 2) accepting either the old or new L2ID. (Embodiment 4) This method provides a mechanism for the receiving UE to re-establish the L2ID change of the transmitting UE if the receiving UE misses multiple L2ID update cycles during communication.

[0177] Some or all of the above embodiments may also be described as follows, but are not limited to the following: (Note 1) A first UE (User Device) that sends a message containing L2ID (Layer 2 Identity) and verification information, A second UE that receives the message from the first UE and determines whether or not to accept the L2ID using the verification information. (Note 2) The first UE generates the L2ID and the first MAC (Message Authentication Code) using the KDF (Key Derivation Function), and sends the message with the first MAC attached. The second UE generates a second MAC using KDF, compares the first MAC with the second MAC, and determines whether or not to accept the L2ID. The communication system described in Appendix 1. (Note 3) The first UE uses the sequence number to generate the L2ID and the first MAC using KDF, The second UE uses the sequence number to generate the second MAC using KDF, compares the first MAC with the second MAC to determine whether to accept the L2ID. The communication system described in Appendix 2. (Note 4) The first UE transmits the L2ID to the second UE and then uses the L2ID for communication. A communication system as described in any one of the following appendices 1 to 3. (Note 5) The second UE sends a response message to the first UE indicating the determination result of the second UE. A communication system described in any one of the following appendices 1 to 4. (Note 6) The first UE and the second UE exchange one or more KDF functions, the first UE generates the L2ID and the first MAC, and the second UE generates the L2ID and the second MAC. The communication system described in Appendix 2 or 3. (Note 7) The first UE and the second UE exchange parameters, generating the L2ID and the first MAC for the first UE and the L2ID and the second MAC for the second UE. A communication system as described in any one of the following appendices: 2, 3, or 6. (Note 8) The first UE sends the message multiple times. A communication system described in any one of the appendices 1 to 7. (Note 9) When the second UE receives the message from the first UE, it relays or floods the message. A communication system described in any one of the items 1 to 8 of the appendix. (Note 10) The first UE inserts a different value into each of the multiple messages, The second UE uses the different values ​​to determine whether the message received by the second UE is the first message or a replayed message. The communication system described in Appendix 8. (Note 11) When the first UE updates the old L2ID to the 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 L2ID or the new L2ID in the message. The 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 transmission source of the received message. The communication system according to Appendix 11. (Appendix 13) When the second UE cannot track the L2ID of the first UE, the second UE requests the first UE to transmit the L2ID. The first UE transmits the L2ID to the second UE in response to the request from the second UE. The second UE re - establishes the L2ID of the first UE. The communication system according to any one of Appendices 1 to 12. (Appendix 14) The first UE periodically inserts a default L2ID into the second UE. The second UE receives and stores the default L2ID. When the second UE cannot track the L2ID of the first UE, the second UE identifies the first UE using the default L2ID. The communication system according to any one of Appendices 1 to 13. (Appendix 15) Comprising transmission means for transmitting a message including an L2ID and verification information to another UE. The verification information enables another UE to determine whether to accept the new L2ID. UE (User Equipment). (Appendix 16) Further comprising generation means for generating the L2ID and MAC (Message Authentication Code) using a KDF (Key Derivation Function), The transmission means transmits the message with the MAC added thereto. The UE according to Supplementary Note 15. (Supplementary Note 17) Receiving means for receiving a message including an L2ID and verification information from another UE, Determination means for determining whether or not to accept the L2ID using the verification information, UE (User Equipment). (Supplementary Note 18) The message to which the first MAC (Message Authentication Code) and the L2ID are added is generated using a KDF (Key Derivation Function). The UE further comprises generation means for generating a second MAC using a KDF. The determination means compares the first MAC and the second MAC and determines whether or not to accept the L2ID. The UE according to Supplementary Note 17. (Supplementary Note 19) Transmitting a message including an L2ID and verification information to a UE, The verification information enables the UE to determine whether or not to accept the new L2ID. Communication method. (Supplementary Note 20) [[ID=3B]]Receiving a message including an L2ID and verification information from a UE, Determining whether or not to accept the L2ID using the verification information. Communication method. (Supplementary Note 21) Causing a computer to execute a process of transmitting a message including an L2ID and verification information to a UE, Enabling the UE to determine whether or not to accept the new L2ID based on the verification information. A non-temporary computer-readable medium storing a program. (Note 22) The process of receiving a message from the UE containing the L2ID and verification information, A process to determine whether or not to accept the L2ID using the aforementioned verification information, A non-temporary, computer-readable medium containing a program to be executed by a computer.

[0178] Those skilled in the art will understand that, as has been widely described, numerous variations and / or modifications can be made to this disclosure, as shown in the specific embodiments, without departing from the spirit or scope of this disclosure. Therefore, these embodiments are considered illustrative and not limiting in all respects.

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

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

Claims

1. User Equipment (UE), In the procedure for updating the link identifier of unicast communication on PC5 with other UEs, Means for receiving an identifier update request message from the aforementioned other UE, which includes a new Layer 2 Identity (L2 ID), first security information, and a sequence number. Means for verifying that the first security information received matches the second security information generated by the UE, After the verification, means for sending a second message to the other UE, It is equipped with, The aforementioned sequence number is derived by inputting the last used sequence number and timestamp into the Key Derivation Function (KDF), and is a UE (User Encoder).

2. A communication method for User Equipment (UE), In the procedure for updating the link identifier of unicast communication on PC5 with other UEs, The aforementioned other UE receives an identifier update request message, which includes a new Layer 2 Identity (L2 ID), security information, and a sequence number. The system verifies that the first security information received matches the second security information generated by the UE. After the verification, a second message is sent to the other UE. The aforementioned sequence number is derived by inputting the last used sequence number and timestamp into the Key Derivation Function (KDF) using this communication method.

Images