Method, apparatus, and computer program product for authentication procedures between devices

Abstract

A method, an apparatus, and a computer program product for an authentication procedure in unicast device-to-device communication are disclosed. According to an embodiment, the method comprises receiving, from an initiating device, a request for establishing unicast device-to-device communication between the initiating device and a target device; sending, from the target device, an authentication request to the initiating device to authenticate the initiating device; receiving, from the initiating device, an authentication response to the authentication request, the authentication response comprising one or more parameters related to the authentication; providing information of the one or more parameters to an application; checking, by the application in the target device, whether the one or more parameters can be accepted; and sending, to the initiating device, an authentication failure message if the checking indicates that at least one of the one or more parameters cannot be accepted.

Description

Technical Field

[0001] This invention relates to the authentication process in unicast device-to-device communication, and more particularly to vehicle-to-everything communication via PC5 for 5G systems. Background Technology

[0002] This section is intended to provide background or context for the invention as described in the claims. The description herein may include concepts that may be sought, but need not be previously conceived or sought. Therefore, unless otherwise stated herein, what is described in this section is not prior art relative to the specification and claims of this application, and is not acknowledged as prior art by virtue of its inclusion in this section.

[0003] Vehicle-to-Everything (V2X) communication is a type of communication that enables services from vehicles to everything. V2X services are implemented through various types of V2X applications, such as vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N). Typically, V2X communication can be considered a subset of device-to-device (D2D) communication. Summary of the Invention

[0004] A method, apparatus, and computer program product are provided for an authentication process in unicast device-to-device communication.

[0005] This disclosure provides a mechanism for processing mutual authentication for V2X communication via PC5 in a 5G system. According to embodiments of this disclosure, a mechanism is provided for a target device (User Equipment, UE) to refuse to return a received direct link authentication response to the initiating device in the event of authentication failure. The authentication process may fail due to rejection by either the initiating UE or the target UE (e.g., due to authentication failure of that UE as one of the purposes of the authentication process).

[0006] This mechanism may include: the target UE can reject the received direct link authentication response message and send a reply message, which may be referred to as a direct link authentication failure. This message can be sent from the target UE to the initiating UE, reflecting the mutual authentication failure reported by the upper layer of the target UE.

[0007] The scope of protection sought by the various embodiments of the present invention is defined by the independent claims. Embodiments, examples, and features (if any) described in this specification that do not fall within the scope of the independent claims are to be interpreted as examples that aid in understanding the various embodiments of the invention.

[0008] The subject matter of the independent claims is provided according to several aspects. Further aspects are defined in the dependent claims. Embodiments not falling within the scope of the claims are to be interpreted as examples that aid in understanding this disclosure.

[0009] According to the first aspect, a method is provided for an authentication process in unicast device-to-device communication, comprising: The target device receives a request from the initiating device to establish unicast device-to-device communication between the initiating device and the target device. The target device sends an authentication request to the initiating device to authenticate the initiating device; Receive an authentication response from the initiating device in response to the authentication request. The authentication response includes one or more parameters related to authentication. Provide information about one or more parameters to the application in the target device; The application is used to check whether the one or more parameters are acceptable; and If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

[0010] According to a second aspect, an apparatus is provided, comprising components for performing the following: Receive a request from the initiating device to establish unicast device-to-device communication between the initiating device and the device; Send an authentication request to the initiating device to authenticate the initiating device; Receive an authentication response from the initiating device in response to the authentication request. The authentication response includes one or more parameters related to authentication. Provide information about one or more parameters to the application in the device; The application is used to check whether the one or more parameters are acceptable; and If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

[0011] According to a third aspect, an apparatus is provided, comprising at least one processor and at least one memory including computer program code, said at least one memory and the computer program code being configured, together with the at least one processor, to cause the apparatus to: Receive a request from the initiating device to establish unicast device-to-device communication between the initiating device and the device; Send an authentication request to the initiating device to authenticate the initiating device; Receive an authentication response from the initiating device in response to the authentication request. The authentication response includes one or more parameters related to authentication. Provide information about one or more parameters to the application in the device; The application is used to check whether the one or more parameters are acceptable; and If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

[0012] According to a fourth aspect, an apparatus is provided, comprising: The first circuit is configured to receive from the initiating device a request for establishing unicast device-to-device communication between the initiating device and the apparatus; The second circuit is configured to send an authentication request to the initiating device to authenticate the initiating device; The third circuit is configured to receive an authentication response from the initiating device in response to the authentication request, the authentication response including one or more parameters related to authentication; A fourth circuit is configured to provide information about the one or more parameters to an application in the device; and The fifth circuit is configured to check whether the one or more parameters are acceptable through the application; The second circuit is further configured to send an authentication failure message to the initiating device if the check indicates that at least one of the one or more parameters is unacceptable.

[0013] According to a fifth aspect, a computer program product is provided, comprising computer program code configured to, together with at least one processor, cause a device to perform at least the following: Receive a request from the initiating device to establish unicast device-to-device communication between the initiating device and the device; Send an authentication request to the initiating device to authenticate the initiating device; Receive an authentication response from the initiating device in response to the authentication request. The authentication response includes one or more parameters related to authentication. Provide information about one or more parameters to the application in the device; The application is used to check whether the one or more parameters are acceptable; and If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device. Attached Figure Description

[0014] To gain a more complete understanding of exemplary embodiments of the invention, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein:

[0015] Figure 1 A portion of an exemplary wireless communication access network according to at least some embodiments of the present invention is shown;

[0016] Figure 2 Examples of communication settings that can implement some of the embodiments are shown;

[0017] Figure 3a An example signaling diagram is provided illustrating the direct link authentication process between UEs after receiving a direct link authentication response from the initiating UE, when the target UE does not send an acknowledgment to the initiating UE.

[0018] Figure 3b An example signaling diagram illustrates the direct link authentication process between UEs when the initiating UE rejects an authentication request from the target UE;

[0019] Figure 4a An example signaling diagram is described for the direct link authentication process between UEs when the target UE does not send an acknowledgment, even though the target UE rejects the authentication response from the initiating UE.

[0020] Figure 4b An example signaling diagram illustrates the direct link authentication process between UEs when the target UE rejects the authentication response from the initiating UE and when the target UE sends a negative acknowledgment.

[0021] Figure 5a and Figure 5b An example of a protocol stack is shown; and

[0022] Figure 6 An apparatus according to an embodiment is shown. Detailed Implementation

[0023] The following embodiments are exemplary. Although the specification may refer to "a," "an," or "some" embodiments in multiple places, this does not necessarily mean that each such reference refers to the same embodiment(s), or that the feature applies only to a single embodiment. Individual features of different embodiments may also be combined to provide other embodiments.

[0024] In the following text, vehicle-to-everything (V2X) communication is used as an example of device-to-device (D2X) communication. V2X communication has at least two operating modes: V2X communication via the PC5 reference point and V2X communication via the Uu reference point. These two operating modes can be used independently by the UE for sending and receiving. PC5 is the reference point between UEs, and it includes LTE-based PC5 and / or NR-based PC5. Uu is the reference point between the UE and the NG-RAN.

[0025] The term PC5 refers to a reference point in which a UE can communicate directly with another UE via a direct UE-to-UE channel without the need for any base station in between. At the system architecture level, Proximity Service (ProSe) is a feature of the architecture that specifies direct communication between UEs. In the 3GPP RAN specification, the term "sidelink" is used when referring to direct communication via PC5.

[0026] 3GPP (3rd Generation Partnership Project) has been developing standards for sidelinks (SL) as a tool for direct communication (UE-to-UE communication) between user equipment in various use cases. In some use cases, solutions including New Radio (NR) sidelinks are being specified primarily for Vehicle-to-Everything (V2X), while they can also be used for public safety when service requirements are met.

[0027] V2X communication via NR-based PC5 reference points supports broadcast, multicast, and unicast modes.

[0028] A PC5 unicast link between two UEs allows V2X communication between one or more pairs of peering V2X services within those UEs. A PC5 unicast link supports one or more V2X service types. To perform unicast mode V2X communication via a PC5 reference point, a Layer-2 link must be established between the two peering UEs. The initiating UE (UE-1) sends a direct link establishment request message to the target UE (UE-2) to initiate the unicast Layer-2 link establishment process. Afterward, authentication and security procedures are performed, and relevant authentication and security messages are exchanged between the initiating UE and the target UE. In a successful scenario, the target UE sends a direct link establishment accept message to the initiating UE to indicate that the target UE has successfully established security with the initiating UE.

[0029] The PC5 unicast link authentication process (also known as: direct authentication and key establishment process) can be triggered during the PC5 unicast link establishment process or the PC5 unicast link key reuse process, and it serves two purposes: 1) Perform mutual authentication for UEs establishing PC5 unicast links, and 2) Derive a new shared key for encryption, which can be called K. NRP This key should be shared between the two UEs during the PC5 unicast link establishment process or the PC5 unicast link key reuse process.

[0030] After successfully completing the PC5 unicast link authentication process, during the PC5 unicast link security mode control process, the new K... NRP The key is used to establish a secure connection.

[0031] K NRP The key is a 256-bit root key shared between two entities communicating using an NR PC5 unicast link. It can be refreshed by rerunning the authentication signaling using long-term credentials. To generate K... NRP -sess (next-layer key) exchanges random numbers between UEs. This ensures that K is maintained even when there is no active unicast communication session between UEs. NRP K NRPID is used to identify K NRP Key.

[0032] The mutual authentication portion occurs at the upper layer of the two UEs, using information exchanged within information elements (IEs) that can be referred to as key-based information containers (IEs) (also known as Key_Est_Info containers) during the authentication process. According to embodiments of this disclosure, the V2X layer at the two peer UEs provides an authentication framework (message passing signals, corresponding IE containers, etc.) for performing mutual authentication at the upper layer of the UE's communication protocol stack.

[0033] Wireless equipment can be a device configured to communicate over radio waves via a wireless radio link (i.e., a wireless link). Communication may include user services and / or signaling. User services may include data, voice, video, and / or audio. Examples of wireless links include point-to-point wireless links and point-to-multipoint wireless links. A wireless link may be provided between two wireless devices. It should be understood that wireless devices may vary. For example, wireless devices connected via a wireless link may include one or more of the following: user equipment (UE), access node, access point, relay node, user terminal, and Internet of Things (IoT) devices.

[0034] The radio equipment can be a radio access device configured to serve multiple other radio devices, user radio devices, and provide radio access to the communication system for the user radio devices. The radio equipment can also be a radio station acting as a relay node or providing wireless backhaul for one or more radio access nodes. Examples of radio access devices include at least access nodes, access points, base stations, and (e / g) NodeBs. Examples of user radio devices include at least user terminals and user equipment (UEs). The radio equipment can be airborne and / or extraterrestrial radio devices configured to operate above the ground without being fixed at a specific altitude. Examples of extraterrestrial radio devices include at least satellites and spacecraft configured for radio communications within the communication system. Examples of airborne radio devices include at least High Altitude Platform Stations (HAPS) and unmanned aerial vehicles (UAVs), such as drones. The radio access device can have one or more cells that user radio devices can connect to in order to access the communication system's services via the radio access device. Cells can include cells of different sizes, such as macrocells, microcells, picocells, and femtocells. A macro cell can be a cell configured to provide coverage over a large coverage area within the service area of ​​a communication system, such as in rural areas or along highways. A micro cell can be a cell configured to provide coverage over a smaller coverage area than a macro cell, such as in densely populated urban areas. A pico cell can be a cell configured to provide coverage over an area smaller than a micro cell, such as in large offices, shopping malls, or train stations. A femto cell can be a cell configured to provide coverage over an area smaller than a femto cell, such as in a home or small office. For example, a macro cell provides coverage for user radio equipment passing through a city on a highway / road, while a local cell (e.g., a micro cell or smaller) provides coverage for user radio equipment within the city. In another example, a macro cell provides coverage for airborne and / or grounded radio equipment, while a local cell (e.g., a micro cell or smaller) provides coverage for airborne and / or grounded radio equipment located at an elevated position relative to one or more radio access devices of the communication system. Therefore, airborne or extraterrestrial radio equipment can be connected to a microcell of a radio access device, and when the airborne or extraterrestrial radio equipment is above a certain altitude above the ground, it can be switched to a macrocell, for example, through a handover process.

[0035] Figure 1 An example of a simplified system architecture is depicted, showing only a few components and functional entities, all of which are logical units whose implementations may differ from those shown. Figure 1The connections shown are logical connections; the actual physical connections may differ. It will be apparent to those skilled in the art that the system typically includes, in addition to... Figure 1 Other functions and structures besides those shown.

[0036] Figure 1 The example shows a portion of an example radio access network.

[0037] Figure 1 User equipment 100 and 102 are illustrated, configured to wirelessly connect to an access node (such as an (e / g) NodeB) 104 providing the cell on one or more communication channels within a cell. The physical link from the user equipment to the (e / g) NodeB is referred to as an uplink or reverse link, while the physical link from the (e / g) NodeB to the user equipment is referred to as a downlink or forward link. It should be understood that the (e / g) NodeB, or its functionality, can be implemented using any entity suitable for such use, such as a node, host, server, or access point. Access nodes provide access via communication using radio frequency (RF) signals and can be referred to as radio access nodes. It should be understood that a radio access network may include more than one access node, thereby enabling the handover of a user equipment's wireless connection from one cell of an access node (e.g., the source cell of the source access node) to another cell of another node (e.g., the target cell of the target access node).

[0038] A communication system typically includes one or more (e / g)NodeBs, which may also be configured to communicate with each other via wired or wireless links designed for this purpose. These links can be used for signaling purposes. An (e / g)NodeB is a computing device configured to control the radio resources of the communication system to which it is coupled. A NodeB may also be referred to as a base station, access point, or any other type of interface device, including relay stations capable of operating in a wireless environment. An (e / g)NodeB includes or is coupled to a transceiver. A connection is provided from the transceiver of the (e / g)NodeB to an antenna element that establishes a bidirectional radio link to the user equipment. The antenna element may include multiple antennas or antenna elements. The (e / g)NodeB is further connected to the core network 110 (CN or Next Generation Core NGC). Depending on the system, the counterpart on the CN side may be a Serving Gateway (S-GW, which routes and forwards user data packets), a Packet Data Network Gateway (P-GW) for providing connectivity to external packet data networks for user equipment (UE), or a Mobility Management Entity (MME), etc.

[0039] User equipment (also known as UE, user equipment, user terminal, terminal equipment, wireless equipment, communication equipment, etc.) is shown as a type of device to which resources on the air interface are allocated and assigned, so any features described herein with the user equipment can be implemented with a corresponding device, such as a relay node. An example of such a relay node is a Layer 3 relay (self-backhaul relay) toward a base station.

[0040] User equipment (UE) generally refers to portable computing devices that include wireless mobile communication devices operating with or without a Subscriber Identity Module (SIM), including but not limited to the following types of devices: mobile stations (mobile phones), smartphones, personal digital assistants (PDAs), handheld devices, devices using wireless modems (such as alarm or measuring devices), laptops and / or touchscreen computers, tablets, game consoles, and multimedia devices. It should be understood that UE can also be a device almost exclusively dedicated to the uplink, an example being a camera or camcorder that loads images or video clips onto a network. UE can also be a device capable of operating in an Internet of Things (IoT) network, a scenario that provides objects with the ability to transmit data over a network without requiring human-to-human or human-to-computer interaction. UE can also utilize the cloud. In some applications, UE may include small portable devices with radio components (such as watches, headphones, or glasses), and computation is performed in the cloud. UE (or, in some embodiments, a Layer 3 relay node) is configured to perform one or more UE functions. UE may also be referred to as a subscriber unit, mobile station, remote terminal, access terminal, user terminal, or user equipment (UE), with only a few names or devices mentioned.

[0041] Figure 5a This illustrates an example of the PC5 control plane (PC5-C) protocol stack and signaling between layers of the protocol stacks of two UEs. Figure 5b This diagram illustrates an example of signaling between layers of the PC 5 user plane (PC5-U) protocol stack and the protocol stacks of two UEs. The bottom layer is the physical layer, which performs the actual signaling (message sending / receiving). The next layer above the physical layer is the Media Access Control (MAC) layer, which is responsible for channel management. The next layer is the Radio Link Control (RLC) layer, responsible for the transmission of upper-layer Packet Data Units (PDUs). The next layer below that is the Packet Data Convergence Control (PDCP) layer, which, among other things, is responsible for IP data header compression and decompression, data transmission (user plane or control plane), etc. Above the PDCP layer are the Radio Resource Control (RRC) layer in the Control Location Protocol stack and the Service Data Adaptation Protocol (SDAP) layer in the user plane protocol stack. The RRC layer is responsible for, for example, connection establishment, connection release, and connection reconfiguration. The SDAP layer is responsible for, for example, the mapping between Quality of Service (QoS) streams and data radio bearers.

[0042] The highest layer in these examples is the application layer, where applications utilizing direct links can be executed. Therefore, the determination of whether an authentication response from the target UE can be accepted or rejected by the initiating UE can be performed at the application layer, unless a lower layer has already detected that authentication should be rejected. For example, the direct link the UE wants to establish might meet the requirements of the physical layer and media access control layer, but not some requirements of the initiating application.

[0043] However, it should be noted that, Figure 5a and Figure 5b The protocol stacks shown are just examples; in actual implementations, the protocol stack may differ from these.

[0044] Figure 3a and Figure 3b This describes the PC5 unicast link authentication process and the messages exchanged between the two UEs for this process when the target UE does not send an acknowledgment to the initiating UE after receiving a direct link authentication response from the initiating UE. Figure 3a In the example, the initiating UE responds by sending a positive acknowledgment direct link authentication response back to the target UE. Figure 3b In the example, the initiating UE responds by sending back a negative acknowledgment and directly rejecting the link authentication.

[0045] It should be noted that, Figure 3a and Figure 3b In the above description, the initiating UE corresponds to UE-2, and the target UE corresponds to UE-1.

[0046] It is worth noting that, depending on the authentication method used by the upper layer, two UEs can exchange authentication request and authentication response messages multiple times until an authentication agreement is reached between the two UEs.

[0047] If the target UE does not indicate authentication failure to the initiating UE, this may give the mistaken understanding that authentication will always succeed and cannot be rejected by the target UE.

[0048] An example of an upper layer at the target UE wanting to refuse the key establishment information container (key_Est_Info) received from the initiating UE in a direct link authentication response is when (multiple) upper layers at the target UE fail to verify one or more authentication parameters provided in the received key establishment information container. This is because the target UE needs to authenticate the initiating UE by checking the parameters in the received response message and comparing the received authentication token with a locally generated token; otherwise, mutual authentication cannot be achieved.

[0049] Example scenario in Figure 4a It is described in the text and discussed in more detail below.

[0050] In the first step 300, the initiating UE initiates the PC5 unicast link establishment process by sending a DIRECT LINKESTABLISHMENT REQUEST message to the target UE to perform a mutual direct link establishment process, including authentication and security key derivation. In the next step 301, the target UE initiates the PC5 unicast link authentication process by sending a DIRECT LINK AUTHENTICATION REQUEST message to the initiating UE to perform mutual authentication and begin security key derivation. This message may include the target UE's security capabilities (e.g., a list of algorithms the target UE will accept for this connection) and the target UE's signaling security policy. If the target UE's signaling integrity protection policy is "REQUIRED" or "PREFERRED", the target UE may also include Nonce_1 (used for session key K) in this message. NRP -sess generation), and K NRP -The most significant 8 bits of the -sess ID. K can be selected. NRP The most significant 8 bits of the -sess ID enable the target UE to locally recognize the security context created by this process. This is if the target UE has an existing K... NRP The message may also include K NRP ID. K NRP The missing ID parameter indicates that the target UE does not have a K for the initiating UE. NRP The message may also contain Key_Est_Info.

[0051] In step 302, the V2X layer at the initiating UE forwards the received Key_Est_Info container to (multiple) upper layers. The (multiple) upper layers at the initiating UE use the information in the received Key_Est_Info container and available long-term credentials (e.g., public / private key pairs depending on the specific use case) to calculate (multiple) authentication tokens and derive the shared key K. NRP .

[0052] In step 303, the upper layer at the initiating UE forwards the calculated authentication token(s) plus any required security parameters to the V2X layer within the new container Key_Est_Info. The initiating UE then generates a direct link authentication response message including the container Key_Est_Info and sends it to the target UE.

[0053] In step 304, after receiving the direct link authentication response, the target UE forwards the received Key_Est_Info container to the upper layer for use in calculating the shared key K. NRP They are used together with available credentials. In addition, in order to achieve mutual authentication, the target UE calculates a local version of its (multiple) authentication tokens and then compares it with the value received in the authentication response.

[0054] In step 305, depending on the application method used by the upper layer, steps 301, 302, 303 and 304 can be selectively repeated multiple times until full mutual authentication is achieved.

[0055] If the above direct authentication and key establishment process is successful and not rejected by either of the two UEs, the initiating UE can send a Direct Security Mode command message to the target UE. This message may contain only K. NRP The MSB of the ID, unless the initiating UE selected the null integrity algorithm, and if a new K is to be generated. NRP If the message contains a non-empty security algorithm, it can optionally include Key_Est_Info. The initiating UE can include the Chosen_algs parameter to include the selected integrity and confidentiality algorithms. A non-empty security algorithm in Chosen_algs indicates that the corresponding security protection is activated, and the security algorithm the UE will use to protect the data in the message. An empty security algorithm in Chosen_algs indicates that the corresponding security protection is not protected. Chosen_algs can indicate only the use of an empty integrity algorithm if UE_2's signaling integrity security policy is NOT NEED or PREFERRED. The initiating UE can also return the target UE's security capabilities and signaling security policy to provide protection against bidding down attacks. If an empty integrity algorithm is selected, an empty confidentiality algorithm should also be selected, and the initiating UE should specify the Key_Est_Info in the security context. NRP -sess ID is set to all zeros.

[0056] In step 6, 306, assuming the authentication token comparison fails at the target UE (i.e., the authentication token is invalid, for example, the initiating UE was not authenticated to establish a connection with the target UE), if the target UE does not send a failure indication to the initiating UE, the process enters an undefined state. This is because the target UE will neither be able to indicate a failure to the initiating UE nor initiate the security mode process following the authentication process. Therefore, both UEs enter an undefined state, and the same applies to the parent process that triggered authentication (direct link establishment).

[0057] like Figure 3aAs shown in the message sequence diagram, the current Phase-3 specification 3GPP TS 24.587 provides a mechanism for the initiating UE to verify the parameters of a Direct Link Authentication Request message received from the target UE, and offers the possibility of rejecting the request message by sending a Direct Link Authentication Reject message. Details of this process can be found in sub-clause 6.1.2.6.5 of 3GPP TS 24.587. A typical case for triggering such a rejection is when the received parameters within Key_Est_Info fail during the verification step at the initiating UE.

[0058] However, such rejection may not adequately reflect a failure of the complete authentication process, i.e., the target UE does not accept the authentication tokens received from the initiating UE in the direct link authentication response message.

[0059] However, the embodiments are not limited to the system given as an example, and those skilled in the art can apply this solution to other communication systems with the necessary characteristics. For example, the embodiments can also be implemented in a proximity-based service (ProSe).

[0060] Some features of this proximity-based service include ProSe discovery (direct or EPC tier) and ProSe direct communication. ProSe discovery uses E-UTRAN (with or without E-UTRAN), WLAN technology, or EPC to identify nearby ProSe-enabled UEs. ProSe direct communication enables the establishment of communication paths between two or more ProSe-enabled UEs within direct communication range. ProSe direct communication paths can use E-UTRAN or WLAN. For public safety-specific purposes, ProSe-enabled public safety UEs can directly establish communication paths between two or more ProSe-enabled public safety UEs, regardless of whether the ProSe-enabled public safety UE is served by E-UTRAN. ProSe direct communication is further facilitated by using ProSe UE-to-network relays that act as relays between E-UTRAN and UEs.

[0061] Figure 4b The diagram illustrates a signaling method in which a target UE can notify the initiating UE that it should not authenticate a unicast link based on parameters received from the initiating UE.

[0062] Figure 4b Steps 311 to 315 in the text correspond to respectively Figure 4a Steps 301 to 305 in the process.

[0063] In step 316, it is assumed that the authentication token comparison fails at the target UE, i.e., the authentication token is invalid. Therefore, the target UE will declare the authentication process as failed and abort the parent process that triggered the PC5 unicast link authentication process (e.g., the direct link establishment process or the key reuse process).

[0064] In step 317, the target UE triggers the generation of a direct link authentication failure message and passes this message, along with the target UE's Layer-2 ID for unicast communication and the initiating UE's Layer-2 ID for unicast communication, to a lower layer of the protocol stack for transmission. This message is sent to the initiating UE, informing it that authentication has failed. The direct link authentication failure message may selectively deliver a container `Key_Est_Info` to the initiating UE, depending on the authentication method used by the upper layers. This container `Key_Est_Info` may carry information about the failure type and related parameters. This may help the upper layers make any necessary decisions in the next authentication cycle.

[0065] In step 318, upon receiving a direct link authentication failure, the UE initiates the termination of the parent process that triggers the authentication process (e.g., the direct link establishment process or the key reuse process), and selectively delivers Key_Est_Info to a higher layer.

[0066] According to embodiments of this disclosure, the direct link authentication failure message is defined as follows:

[0067] Message type: Direct link authentication failed

[0068] Importance: Dual

[0069] Direction: UE to peer UE

[0070] The embodiments described above can improve the operation of a user equipment when two user equipments attempt to establish a direct link between them, but for some reason the initiating UE cannot accept some or all of the attributes of the direct link provided by the initiating UE, wherein the target UE is able to report to the initiating UE that the establishment of the direct link has failed.

[0071] Embodiments of this disclosure provide a mutual authentication process for the purpose of authenticating V2X communication via PC5 for 5G systems. Prior to this invention, the implementation of mutual authentication was not required.

[0072] The embodiments of this disclosure provide a method for initiating UE and target UE to abort the parent process that triggers authentication in the event of authentication failure.

[0073] Some embodiments of this disclosure enable the target UE to selectively report the reason for authentication failure to the initiating UE by including the optional container Key_Est_Info in the direct link authentication failure message.

[0074] Figure 2 An example of a communication setup in which some embodiments can be implemented is shown. A base station 200 exists, which can operate as an access point for user equipment 204, 206, 208 to communication network 202. User equipment 204, 206, 208 has wireless communication capabilities with other user equipment and / or base stations. For example, in Figure 2 In this setup, user equipment 204 acts as a relay between other user equipments 206, 208 and base station 200. However, some of user equipments 204, 206, and 208 can also have direct communication connections with each other without any relay user equipment or base station. Figure 2 In the example, the second user equipment 206 and the third user equipment 208 are communicating with each other, while the first user equipment 204 is communicating with the base station 200, the second user equipment 206 and the third user equipment 208.

[0075] For example, user equipment that is directly connected to each other can use a side link connection 210.

[0076] exist Figure 2 In the schematic diagram, user equipment 204 communicates with base station 200 using both downlink (DL) and uplink (UL), while user equipment 206 communicates with base station 200 only using the downlink (i.e., only receives signals from base station 200) and communicates with the other two user equipments 204 and 208 via sidelinks. User equipment 208 communicates with user equipments 204 and 206 only via sidelinks. However, user equipment 204, which can communicate with base station 200, can forward messages from other user equipments 206 and 208 to base station 200, and can also forward messages from base station 200 to other user equipments 206 and 208.

[0077] The user equipment (UE) may be able to receive signals from the base station, but the signals it transmits may not be received by the base station. This could be because the base station's available transmission power is higher than the UE's transmission power. In this case, the UE can receive, for example, control information from the base station (via downlink DL) and, for example, send replies and data to the relay UE via sidelink communication with the relay UE.

[0078] Below, will refer to Figure 4a and Figure 4b Flowchart, Figure 5a and Figure 5b Signaling diagram and Figure 2 The system settings are used to describe some example implementations, wherein Figure 5a and Figure 5b The signaling diagram is used for interactions between user equipment via sidelinks and interactions between user equipment and the service network.

[0079] Figure 6 Examples of apparatuses according to at least some embodiments of the present invention are shown. The apparatus may be a radio device, such as a radio access node or a user radio device. The apparatus may perform one or more functions according to the examples described herein.

[0080] The device includes a processor 602 and a transceiver 604. The processor is operatively connected to the transceiver and is used to control the transceiver. The device may include a memory 606. The memory may be operatively connected to the processor. It should be understood that the memory may be a separate memory or may be included in the processor and / or the transceiver.

[0081] According to an embodiment, the processor is configured to control the transceiver to perform one or more functions as described in the embodiment.

[0082] The memory can be a non-transitory computer-readable medium. The memory can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The data processor can be of any type suitable for the local technical environment and can include one or more of the following: as non-limiting examples, general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures.

[0083] Implementations may be carried out using software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and / or hardware may reside on memory or any computer medium. In example embodiments, the application logic, software, or instruction set is maintained on any of a variety of conventional computer-readable media. In the context of this document, "memory" or "computer-readable medium" can be any medium or means capable of containing, storing, communicating, propagating, or transmitting instructions for use by or in conjunction with an instruction execution system, apparatus, or device (such as a computer).

[0084] In relevant contexts, references to "computer-readable storage media," "computer program products," "tangible computer programs," or "processors" or "processing circuits" should be understood to include not only computers with different architectures (such as single / multiprocessor architectures and sequencer / parallel architectures) but also special-purpose circuits (such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), signal processing devices, and other devices). References to computer-readable program code refer to computer programs, computer instructions, and computer code, which should be understood as representing software (e.g., programmable content of hardware devices) used for programmable processor firmware as instructions for a processor or configuration settings for fixed-function devices, gate arrays, programmable logic devices, etc.

[0085] While the foregoing examples describe embodiments of the invention operating within a user radio equipment, UE, radio access equipment, or gNB, it should be understood that the invention described above can be implemented as part of any apparatus including circuitry for transmitting and / or receiving radio frequency signals. Therefore, for example, embodiments of the invention can be implemented in mobile phones, base stations, radio stations, user radio equipment, computers such as desktop computers, or tablet computers that include radio frequency communication components (e.g., wireless LAN, cellular radio, etc.).

[0086] Generally, various embodiments of the present invention can be implemented in hardware or dedicated circuitry or any combination thereof. While various aspects of the invention may be illustrated and described as block diagrams or using some other illustrations, it should be clearly understood that, by way of non-limiting example, the blocks, devices, systems, techniques or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0087] As used in this application, the term "circuit" may refer to one or more or all of the following: (a) Implementation of hardware circuits only (such as implementations only in analog and / or digital circuits) and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits with software / firmware, and (ii) Any portion of a hardware processor (including a digital signal processor), software, and memory (including a plurality of) that works together to enable a device such as a mobile phone or server to perform various functions, and (c) Multiple hardware circuits and / or multiple processors, such as multiple microprocessors or a portion thereof, that require software (e.g., firmware) to operate, but which may be absent when the software is not required to operate.

[0088] This definition of "circuit" applies to all uses of the term in this application, including in any claim. As a further example, as used in this application, the term "circuit" also covers only hardware circuitry or a processor (or processors) or a portion thereof and its accompanying software and / or firmware implementation. The term "circuit" also covers (e.g., and if applicable to a particular claim element) baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0089] The foregoing description provides a complete and informative description of exemplary embodiments of the invention by way of exemplary and non-limiting examples. However, various modifications and adaptations will become apparent to those skilled in the art when read in conjunction with the accompanying drawings and appended claims, given the foregoing description. Nevertheless, all such and similar modifications taught in this invention will still fall within the scope of this invention.

Claims

1. A communication method, comprising: Receive a request from the initiating device to establish unicast device-to-device communication between the initiating device and the target device; The target device sends an authentication request to the initiating device to authenticate the initiating device; The device receives an authentication response to the authentication request, the authentication response including one or more parameters related to the authentication. Provide information about one or more parameters to the application in the target device; The application is used to check whether the one or more parameters are acceptable. as well as If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

2. The method according to claim 1, comprising: Information regarding the security capabilities and signaling security policies of the target device shall be included in the authentication request.

3. The method of claim 1 or 2, wherein the one or more parameters associated with the authentication include at least one or more authentication tokens.

4. The method of claim 3, wherein the inspection comprises: The received authentication tokens are compared with one or more local authentication tokens of the target device; as well as Based on the comparison, it is determined whether the one or more parameters are acceptable.

5. The method according to claim 1 or 2, further comprising: Information about at least one reason for the authentication failure shall be included in the authentication failure message.

6. The method according to claim 1 or 2, further comprising: The authentication request is formed based on the request used to establish the unicast device-to-device communication.

7. A communication device comprising components for performing the following: The application of the initiating device receives a request to establish unicast device-to-device communication between the initiating device and the communication device; Send an authentication request to the initiating device to authenticate the initiating device; The device receives an authentication response to the authentication request, the authentication response including one or more parameters related to the authentication. Provide information about one or more parameters to the application in the communication device; The application is used to check whether the one or more parameters are acceptable. as well as If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

8. The communication device according to claim 7, further comprising a component for performing the following: Information regarding the security capabilities of the communication device and its signaling security policies should be included in the authentication request.

9. The communication device according to claim 7 or 8, wherein the one or more parameters associated with the authentication include one or more authentication tokens.

10. The communication device according to claim 7 or 8, wherein the component for inspection is configured as follows: Compare the received one or more authentication tokens with one or more local authentication tokens of the communication device; and Based on the comparison, it is determined whether the one or more parameters are acceptable.

11. The communication device according to claim 7 or 8, further comprising components for performing the following: Information about at least one reason for the authentication failure shall be included in the authentication failure message.

12. The communication device according to claim 7 or 8, further comprising components for performing the following: The authentication request is formed based on the request used to establish the unicast device-to-device communication.

13. A communication device comprising at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured together with the at least one processor to cause the communication device to: The application of the initiating device receives a request to establish unicast device-to-device communication between the initiating device and the target device; Send an authentication request to the initiating device to authenticate the initiating device; The device receives an authentication response to the authentication request, the authentication response including one or more parameters related to the authentication. Provide information about one or more parameters to the application in the communication device; The application is used to check whether the one or more parameters are acceptable. as well as If the check indicates that at least one of the one or more parameters is unacceptable, an authentication failure message is sent to the initiating device.

Images