Method for operating a cellular network - Patents.com

Abstract

The invention relates to a method for operating a communication system including a primary station linked to a core network and serving a cell, a relay station served by the primary station and a secondary station served by the primary station, the method comprising the steps of the relay station establishing a connection with the primary station, including receiving a first set of configuration parameters in at least one first secure message from the primary station, the secondary station establishing a connection with the primary station, including receiving from the primary station a second set of configuration parameters linked to an upcoming data session in at least one second secure message, the relay station transmitting at least one transmitted service code from the first set of configuration parameters and, if it is determined that the transmitted configuration parameter is included in the second set of configuration parameters, the secondary station establishing a direct communication with the relay station.

Description

[Technical field]

[0001] The present invention relates to the field of wireless communications, and in particular to relaying architectures in the context of cellular networks such as UMTS Long Term Evolution (LTE) or LTE-Advanced (both included in 4G), New Radio (NR) (5G), or other cellular or mobile communication networks. [Background technology]

[0002] In a conventional cellular network, a primary station serves multiple secondary stations located within the cell served by the primary station. Wireless communication from the primary station to each secondary station occurs on a downlink channel. Conversely, wireless communication from each secondary station to the primary station occurs on an uplink channel. Wireless communication may include data traffic (sometimes referred to as user data) and control information (sometimes referred to as signaling). This control information typically includes information that helps the primary and / or secondary stations exchange data traffic (e.g., resource allocations / requests, physical transmission parameters, information about the status of each station).

[0003] In the context of a cellular network standardized by 3GPP, the primary station is called a base station, in 5G (NR) it is called a gNodeB (or gNB), or in 4G (LTE) it is called an eNOdeB (or eNB). The eNB / gNB is part of the radio access network RAN, which has an interface that functions in the core network (CN). In the same context, the secondary station corresponds to a mobile station or user equipment (or UE) in 4G / 5G, which is a wireless client device or a specific role played by that device. The term "node" is also used to indicate either a UE or an eNB / gNB.

[0004] In 3GPP, the role of a relay node is introduced, as shown in Fig. 1. The relay node 120 is a wireless communication station 120 that includes functionality for relaying communication between a base station 100 and a UE 110. This relay functionality helps, for example, to extend the coverage of a cell 10 to an out-of-coverage (OoC) mobile station 110. This relay node 120 can be a mobile station or a different type of device. In the 4G specifications, the Proximity Services (ProSe) functionality is defined, among other functions, in TS 23.303 and TS 24.334 as enabling connectivity for cellular user equipment (UE) that is temporarily not in the coverage of a cellular network base station (eNB) 100 serving a cell 10. This particular functionality is called relay between UE and network by ProSe, or simply relay UE. The relay UE 120 relays application and network traffic between the OoC UE 110 and the eNB 100 in both directions. The local communication between the relay UE 120 and the OoC UE 110 is referred to as device-to-device (D2D) communication, or sidelink (also known as PC5) communication in TS 23.303 and TS 24.334. Once the relay relationship is established, the OoC UE 110 is IP connected via the relay UE 120 and functions in the role of "remote UE" 110. This situation means that the remote UE has an indirect TS22.261 network connection to selected functions of the core network, as opposed to a direct TS22.261 network connection to all functions of the core network, which is the usual case.

[0005] Additionally, in such a system, as shown in FIG. A) A remote UE can make a call towards the base station / core network via relay between the UE and the network. B) A source UE can make a call to a destination UE via relay between UEs. C) A group of UEs can talk to each other as groupcast communication, sometimes via relay between the UEs.

[0006] In 3GPP® SA2, communication models and procedures are discussed and agreed upon for relay-based systems. These procedures are contained in TR 23.752. In 3GPP® SA3, security solutions and procedures are discussed and agreed upon for relay-based systems. These procedures are contained in TR 33.847.

[0007] For example, Solution #28 of TR23.752 describes a mechanism for a remote UE to discover a relay between the UE and the network at Layer 3 and establish a PC5 unicast connection using the relay between the UE and the network, which does not require interaction with the core network during operation.

[0008] For example, solution #32 of TR33.847 describes a mechanism by which a remote UE protects its PDU parameters from relaying between the UE and the network so that only authorized relays can access them. This solution requires interaction with the core network. Summary of the Invention [Problem to be solved by the invention]

[0009] The current solution discussed in solution #28 of TR23.752 presents the advantage that it does not require interaction with the CN during discovery. However, it also presents some problems, e.g. related to KI#16 of TR33.847. How to avoid pre-configuration of slicing information is not resolved (problem 1). Also, this solution requires that PDU session parameters are transported in the clear (problem 2). A possible solution to these challenges in TR33.847 is solution #32. However, this solution requires communication through the core network during the course of operation to achieve privacy protection of PDU parameters (problem 3).

[0010] One object of the present invention is to alleviate the above-mentioned problems.

[0011] Another object of the invention is to propose a method of communication in a network that allows a secure setup for establishing a Protocol Data Unit (PDU) session for a secondary station.

[0012] Yet another object of the invention is to propose a method of communication for a secondary station in a network which, once operational, requires only a minimum of interaction with the core network. [Means for solving the problem]

[0013] To this end, according to a first aspect of the invention, a method for operating a system according to claim 1 and its variants in the dependent claims is proposed.

[0014] Thus, according to the first aspect of the invention, the secondary station and the relay station obtain the required security elements, e.g. a signed public key intended for the receiving UE, from the core network at an early stage, e.g. during initial connection to a cell, and during a later phase, e.g. during network operation, the secondary station and the relay station can establish a secure exchange and authentication in order to start a PDU session.

[0015] In the exemplary embodiment described below, the configuration parameters included in the first and second messages may be a Relay Service Code (RSC). However, these configuration parameters may also be different parameters or combinations of parameters, such as any one or more of the following: · 1 set of access roles, A set of attributes, Communication parameters, such as transmission modes, constraints on some set of resources, etc. A special identifier, such as an ID for an application, a group ID, or a UE; -Policies that define access rights, · Policies that define the types of communications that can be relayed.

[0016] According to a second aspect of the invention, a method for operating a relay station is proposed as claimed in claim 18.

[0017] According to a third aspect of the invention, a method for operating a secondary station is proposed as claimed in claim 19.

[0018] According to a fourth aspect of the invention linked to the second aspect of the invention, a relay station as claimed in claim 20 is proposed.

[0019] According to a fifth aspect of the invention linked to the third aspect of the invention, a secondary station as claimed in claim 21 is proposed.

[0020] According to a sixth aspect of the present invention there is proposed a computer program product comprising code means which, when executed on a computing device, causes the steps of the methods of the first, second or third aspects of the present invention.

[0021] Thus, according to a first aspect of the invention, a method is proposed for operating a communication system including a primary station linked to a core network and serving a cell, a relay station served by the primary station and a secondary station served by the primary station, the method comprising the steps of: a relay station establishing a connection with the primary station, the connection including receiving a first set of configuration parameters including a service code in at least one first secure message from the primary station; the secondary station establishing a connection with the primary station, the connection including receiving from the primary station a second set of configuration parameters including a relay service code linked to the upcoming data session in at least one second secure message; a relay station transmitting at least one transmitted service code from a first set of configuration parameters; if it is determined that the transmitted service code is included in the second set of configuration parameters, the secondary station establishes direct communication with the relay station; has.

[0022] According to a second aspect of the invention, a method is proposed for operating a relay station arranged for communication in a network, the relay station including a primary station linked to a core network and serving a cell, and a secondary station served by the primary station, the method comprising the steps of: the relay station establishing a connection with the primary station, the connection comprising receiving a first set of configuration parameters, the first set of configuration parameters including a number of attributes or a set of service codes, in at least one first secure message from the primary station; transmitting, by the relay station, at least one attribute from the second set of configuration parameters or a transmitted service code from the second set of configuration parameters; the relay station establishing direct communication with the secondary station upon request from the secondary station based on the transmitted service code; has.

[0023] According to a third aspect of the invention, a method is proposed for operating a secondary station for communication in a communication system comprising a primary station linked to a core network and serving a cell, and a relay station served by the primary station, the secondary station being served by the primary station, the method comprising the steps of: - the secondary station establishing a connection with the primary station, comprising receiving from the primary station in at least one second secure message a public encryption key and a second set of attributes or a relay service code linked to future data exchanges with the at least one relay station; receiving, by a secondary station, at least one transmitted attribute or relay service code from the relay station; the secondary station determining whether the transmitted attribute or relay service code is included in a second set of configuration parameters, and if the secondary station determines that the transmitted attribute or relay service code is included in the second set of configuration parameters or satisfies a policy therein, establishing direct communication with the relay station; has.

[0024] According to a fourth aspect of the invention, a relay station is proposed adapted for communication in a network including a primary station linked to a core network and serving a cell, and a secondary station served by the primary station, the relay station being served by the primary station, the relay station being adapted for communication in a network including a primary station and a secondary station served by the primary station, the relay station comprising: A transmitter; A receiver; a controller configured to establish a connection with a primary station and configured to configure the receiver to receive a first set of configuration parameters including an attribute or service code in at least one first secure message from the primary station; Equipped with The transmitter is configured to transmit at least one transmitted attribute or service code from the first set of configuration parameters; The controller is configured to establish direct communication with the secondary station using the public key upon request based on the transmitted service code from the secondary station.

[0025] According to a fifth aspect of the invention, a secondary station is proposed adapted to communicate in a communication system including a primary station linked to a core network and serving a cell, and a relay station served by the primary station, the secondary station being served by the primary station, the secondary station comprising: A transmitter; A receiver; a controller configured to establish a connection with the primary station, the controller configuring the receiver to receive from the primary station in at least one second secure message a second set of configuration parameters including attributes or a relay service code linked to future data exchanges with the at least one relay station; Equipped with The receiver is configured to receive at least one transmitted attribute or relay service code from the relay station; The controller is configured to determine whether the transmitted attribute or relay service code is included in or satisfies a policy within a second set of configuration parameters, and to cause the transmitter to establish direct communication with the relay station if it is determined that the transmitted relay service code is included in the second set of configuration parameters.

[0026] According to a first option, which may be combined with any of the first to fifth aspects of the invention, the first secure message further comprises a relay public encryption key and a corresponding relay private encryption key.

[0027] Similarly, according to a second option, which may be combined with the first to fifth aspects of the invention or with the second option of the invention, the second secure message further comprises a secondary station public encryption key and a corresponding secondary station private encryption key.

[0028] In a third option, which may be combined with the second and / or third options, the at least one first secure message comprises at least A relay public encryption key; at least one attribute of the first set of configuration parameters or one of a service code of the first set of configuration parameters; at least one first core network signature from a core network, The at least one second secure message comprises at least A secondary station public encryption key; at least one attribute of the second set of configuration parameters or one of a service code of the second set of configuration parameters; The at least one second core network signature from the core network generated in

[0029] Alternatively, in a fourth option, which may be combined with the second and / or third options, the at least one first secure message comprises at least A relay public encryption key; at least one attribute of the first set of configuration parameters or one of a service code of the first set of configuration parameters; at least one first core network signature from a core network, The at least one second secure message comprises at least parameters related to the upcoming data session and included in the second secure message; A secondary station public encryption key; at least one attribute of the second set of configuration parameters or one of a service code of the second set of configuration parameters; The at least one second core network signature from the core network generated in

[0030] In a fifth option, which may be combined with the third or fourth option, the step of establishing direct communication comprises: a. a secondary station sending a direct communication request to a relay station; b. the relay responding to the direct communication request with a response message including the relay public encryption key, the first core network signature, and the response message signature; c. the secondary station checking the first core network signature included in the response message and the response message signature; Includes.

[0031] Further, in a fifth option, which can be combined with the fourth option, the direct communication request includes a secondary station nonce, and the response message signature is generated by applying the relay private encryption key to at least the secondary station nonce.

[0032] Additionally, in a sixth option, which may be combined with the fifth option, the response message signature is generated by applying a relay private encryption key to at least the secondary station nonce and at least one of the core network first signature and the relay public encryption key.

[0033] In a seventh option, which can be combined with the fourth, fifth, or sixth options, the response message further includes a relay nonce, and the secondary station sends the communication parameters in a configuration message, the configuration message including a configuration message signature, the configuration message signature being generated by applying the secondary station private encryption key to at least the relay nonce.

[0034] In an eighth option, which can be combined with the seventh option, the configuration message signature is generated by applying the secondary station private encryption key to at least the relay nonce and at least one of the core network second signature and the secondary station public encryption key.

[0035] In a ninth option that can be combined with the first to fifth aspects, the step of establishing direct communication comprises: a. a secondary station generating or selecting a secondary station cryptographic public key, a secondary station cryptographic private key, and a secondary station nonce, and sending a direct communication request to a relay station; b. the relay responding to the direct communication request with a response message, the response message including the relay public encryption key, the first core network signature, and / or the response message signature, encrypted using the public key received in step a; c. the secondary station decrypting the response message and checking the first core network signature included in the response message and the response message signature; Includes.

[0036] In a tenth option that can be combined with any of the aspects and options of the invention, the relay station transmits at least one transmitted attribute of the first set of configuration parameters or a service code from the first set of configuration parameters and at least one of the further information of the data session policy, the data session parameters, the first core network signature and the relay public encryption key, and the secondary station establishes direct communication with the relay station when it determines that the transmitted attribute of the first set of configuration parameters or the transmitted service code is included in the second set of configuration parameters and the further information is compatible with the upcoming data session.

[0037] In an eleventh option, which can be combined with the tenth option, the transmitted message from the relay station includes a signature that is applied to at least the timestamp.

[0038] In a twelfth option of the present invention, which can be combined with any of the aspects and options of the present invention, the at least one transmitted service code from the first set of configuration parameters is a result of a hashed service code of the first set of configuration parameters combined with a transmitted nonce, and the relay station further transmits the transmitted nonce.

[0039] In a thirteenth option of the present invention, which may be combined with the fifth to tenth options, the method further comprises the step of the secondary station notifying the core network if the first core network signature fails.

[0040] In a fourteenth option combined with the first to fifth aspects of the present invention, the step of the relay station establishing a connection with the primary station includes the steps of the relay station generating a relay public encryption key and a relay private encryption key by the relay station, sending the relay public encryption key to the primary station for signing by the core network, and receiving in at least one first secure message from the primary station the first set of service codes and a first core network signature based on at least the relay public encryption key.

[0041] In a fifteenth option of the present invention combined with the first to fifth aspects or the fourteenth option of the present invention, the step of the secondary station establishing a connection with the primary station comprises the steps of the secondary station generating a secondary station public encryption key and a secondary station private encryption key, sending the secondary station public encryption key to the primary station for signing by the core network, and receiving in at least one second secure message from the primary station a second set of service codes and a second core network signature based on at least the secondary station public encryption key.

[0042] It should be noted that the above apparatus may be implemented based on a discrete hardware circuit configuration comprising discrete hardware components, integrated circuits or chip modules, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer readable medium or downloaded from a network such as the Internet.

[0043] It should be understood that the wireless devices, systems, relay stations, cell stations and methods may have similar, corresponding and / or identical preferred embodiments, particularly as defined in the dependent claims.

[0044] It has to be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above embodiments with the respective independent claim. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. [Brief description of the drawings]

[0045] [Figure 1] 1 is the already described schematic diagram representing a cellular system in which the present invention is implemented; [Diagram 2] 2 is a schematic diagram, already described, illustrating different possible operation modes in the network of FIG. 1. [Diagram 3] 2 is a time diagram of communication according to the protocol of the first embodiment of the present invention. [Figure 4] 4 is a time diagram of communication according to the protocol of the second embodiment of the present invention. [Diagram 5] 11 is a time diagram of communication according to the protocol of the third embodiment of the present invention. [Figure 6] 2 is a time diagram of communication according to the protocol of the first embodiment of the present invention. [Figure 7] 4 is a timing diagram for one improvement made possible by an embodiment of the present invention; [Figure 8] 4 is a timing diagram for one improvement made possible by an embodiment of the present invention; [Figure 9] 4 is a time diagram of communication according to a protocol in another embodiment of the present invention. [Figure 10] FIG. 2 is a block diagram illustrating a secondary station and a relay station according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0046] In the following, solutions addressing problems 1, 2 and 3 are described in various embodiments. These solutions, in a first embodiment, consist in distributing information signed by the CN to each UE (also called secondary station, remote UE and relay station, also called relay UE), in particular a public key bound to each UE. This information distribution phase occurs during the initial provisioning and authorization steps, i.e. early in the connection. The UEs can be remote UEs or relay UEs. It may also be that the UE under consideration has to act alternately as a relay UE and as a remote UE in operation. The signed information including the public key allows, in this first embodiment, the following: · The remote UE checks whether the relay UE is allowed to act as a relay without accessing the CN during operation. · The relay UE checks the PDU parameters of the remote UE when permitted without accessing the CN during operation. · Establishment of a secure PC5 link between the remote UE and the relay UE without accessing the CN during operation.

[0047] The main advantage of this first embodiment of the invention, compared to existing security solutions (solution #28 in TR23.752 and solution #32 in TR33.847), is that it does not require access to the core network during operation to operate in a secure manner. This means: Lower workload on the core network; - Reduced latency for establishing a communication link, since no further checks are required with the CN once it is up and running; Relay UEs may be out of coverage; The remote UE may be out of coverage; · Privacy-related parameters are not disclosed.

[0048] In this way, this first embodiment presents a solution applicable to solution #28 of TR23.752 to address privacy concerns and avoid problems 1 and 2.

[0049] It should be noted that although this first embodiment is described in the context of protecting PDU parameters in the context of KI#16 of TR33.847, the same techniques and other embodiments building on these techniques can be used to address other problems, for example as described in the table below. This detailed description includes several embodiments that provide solutions to these problems. In particular, this detailed description provides improvements over Solution#8 and Solution#31 in TR33.847. These two solutions are the only solutions in TR33.847 that use public key cryptography. Solution#8 and Solution#31 address KI#6 and KI#7, respectively.

[0050] [Table 1]

[0051] It should be noted that the first embodiment of the present invention is also applicable to protect the confidentiality of other parameters, for example application functions, as addressed in solution #21 of TR33.847.

[0052] It should be noted that this solution can also be used independently for security establishment in PC5, as an alternative solution to solutions #1, #6, #10 and #15 of TR33.847.

[0053] A first embodiment will now be described with reference to Fig. 3. In a network similar to the one described in the preamble of this description, the CN is generally able to sign information. This can be realized by the Digital Signature Network Function (DSnF) proposed in solution #20 of TR33.809. Alternatively, for example, an application function could be in charge of signing the requested information. In addition, the remote UE is configured with trust anchors that allow the verification of information when it is signed by the CN. These trust anchors could be as in the DSnF solution. In a variant of this first embodiment, these trust anchors could also be delivered to the UE during the initial provisioning phase (steps 1.a and 1.b below).

[0054] The first embodiment corresponds to ProSe operation according to "Discovery Model A". In fact, constrained ProSe direct discovery is a process in which a UE detects and identifies other UEs in its vicinity using its radio access direct radio signals with the explicit permission of the UE being discovered. According to Discovery Model A ("I'm Here"), two roles of a ProSe-enabled UE are involved in this model: announcing UEs and monitoring UEs. Announcing UEs broadcast discovery messages at predefined discovery intervals, and monitoring UEs interested in these messages read and process them. Instead, in Model B ("Who's there?" / "Are you there?"), two roles of a ProSe-enabled UE are involved: discovering UEs and discovered UEs. Discovering UEs send information about other UEs from which they would like to receive a response, which is equivalent to "Who's there / Are you there?", and for example, this information can be about a ProSe application ID corresponding to a group, which members of the group can respond to.

[0055] According to a first embodiment, as shown in FIG. - In step a, during initial provisioning, the CN distributes to the relay UE a set of configuration parameters, e.g. the relay service codes (RSCs) it supports. The configuration parameters may include other capabilities offered by the relay UE, e.g. which applications it supports. This distribution can be done without disclosing to the relay UE specific privacy-sensitive parameters to which each set of configuration parameters is linked, e.g. the RSCs. The CN also creates a key pair of relay public keys to be used by the relay UE. The CN can also distribute other information, e.g. policies describing which types of remote UEs or connections the relay is allowed to serve for which types of remote UEs. The CN can sign the supported configuration parameters and the relay public key (or do other security processing, e.g. encrypt the message). The CN provides the signed configuration parameters and the relay public key to the relay UE, together with the corresponding relay private key. This can be done in a single message as shown in Fig. 3, or in separate messages in variants of this embodiment. In case of signing by the CN, the core network public key is also shared at this point. Other encryption processes may include, for example, encryption of the entire first message, e.g., if encryption keys have already been exchanged or are known by the relay UE. - In step b, during initial provisioning, the CN provides the remote UE with a set of configuration parameters linked to specific PDU session parameters, e.g. RSC. The CN also creates a key pair of secondary station public keys. The CN signs the configuration parameters and the corresponding PDU parameters. It can include other elements in the signature, such as the secondary station public key. The CN sends the signed secondary station public key, the RSC, the PDU parameters and the secondary station private key. In case of signing by the CN, the core network public key is also shared at this point. The CN can also distribute other information, e.g. a policy describing what type of relay UE is allowed to provide its communication needs. Other encryption processes include, e.g. encryption of the entire second message, e.g. if encryption keys have already been exchanged or are known by the relay UE. This distribution can also be performed in a single message as shown in Fig. 3, or in multiple messages. - In step c, in the example of discovery model A, the relay UE broadcasts some of its supported configuration parameters, e.g. its RSC, during relay UE discovery. In case of discovery model B, the remote UE (secondary station) may broadcast some message to indicate its presence. Indeed, in discovery model B, the remote UE is the one sending the discovery message, not the relay UE. To adapt the first embodiment to this alternative scenario, the remote UE is the one sending the discovery message including its supported configuration parameters, e.g. its RSC. - In step d, when the remote UE receives the above mentioned data, it checks whether the relay UE supports its PDU communication requirements, for example by matching the RSC. - In step e, it is first determined whether an RSC match exists, and then the remote UE may decide to establish a PC5 connection, for example as follows: i. The remote UE generates a nonce N_remote and sends it to the relay UE. Optionally, the remote UE may also include the specific RSCs it is interested in so that the relay UE knows about them. ii. The relay UE sends: 1. Its public key (PuK_relay) and configuration parameters, e.g. RSC, 2. The configuration parameters (e.g., RSC) and the CN signature on the public key received from the CN, i.e., S(PrK_CN, RSCs|PuK_relay); 3. Received remote N_remote (optionally sent, but required in signature calculation) 4. Relay nonce, N_relay. Some or all of these items may be signed with the relay's private key (PrK_relay). In FIG. 3, S(PrK, M) denotes the signature of message M using private key PrK. In this description, "|" corresponds to the concatenation operation. iii. The remote UE then verifies (i) the CN signature and (ii) the relay signature, which includes the remote nonce (iii). In this way, the remote UE can check that the relay UE has been authenticated by the core network first, without needing to contact the CN during the operation. This thus reduces the load on the core network, which would otherwise need to perform an authentication operation for each connection between the devices. iv. If step iii) is successful, the remote UE may then send: 1. its communication parameters, in particular its PDU session parameters linked to the RSC and to the public key PuK_remote, 2. The corresponding CN signature for the corresponding communication parameters and public key; 3. The nonce received from the relay UE, i.e., N_relay (optional); 4. The above information elements (communication parameters, corresponding CN signature, nonce N_relay (optional)) can be signed using the secondary station private key (PrK_remote) whose public key is signed by the CN. The entire message can then be encrypted using the public key PuK_relay of the relay node, so that these parameters and information are not sent in the clear over the air network (OTA). As can be seen in Figure 3, E(PuK,M) represents the encryption of the message M with the public key PuK. v. The relay UE decrypts the received information and checks the remote CN signature and the remote UE signature. If the verification is correct and N_relay is present, the relay UE provides the remote UE's requirements for the disclosed PDU parameters.

[0056] Thus, as explained above, during connection to the relay UE, neither the relay UE nor the remote UE need to communicate with the core network for authentication / authorization purposes. All validation is implemented up front, which leads to a smooth and secure connection protocol without any help from the CN during operation. Thus, even when out of coverage, the UE can securely connect to the PDU session.

[0057] As explained above, discovery model B requires a remote UE to broadcast in order to connect to a relay UE. Thus, when implementing the variant of the first embodiment in the specific case of discovery model B, in step c, the remote UE broadcasts its configuration parameters, such as its RSC. In a subsequent step of this alternative, the relay UE matches the received configuration parameters, e.g. the received RSC, with its own. If there is a match, the relay UE can send its signed RSC, the relay nonce, the CN signature associated with its relay service code, and / or its public key similar to the subsequent steps in the first embodiment (model A).

[0058] In a variant of the first embodiment, it may be impossible for the relay UE to be tracked. For this purpose, the remote UE generates an ephemeral public key pair and sends it to the relay UE in step e i. As this public key pair is ephemeral, it cannot be used to track the remote UE. The relay UE uses it in step e ii to encrypt messages so that the relay parameters remain secret from an external (passive) attacker. Thus, the step of establishing direct communication may include a step of the secondary station generating its own cryptographic public and private keys. Together with the secondary station nonce, the remote UE can send a direct communication request to the relay station. This first message, similar to that in the first embodiment, is optional but may be secure.

[0059] In response to the direct communication request, the relay station sends a response message including the relay public encryption key, the first core network signature, and / or a response message signature, where the message is protected (confidentiality) using the public key received with the direct communication request.

[0060] The secondary station may then decrypt the received message and check the first core network signature included in the response message and the response message signature.

[0061] It should be noted that due to the small discovery messages, the above protocol allows to exchange RSC in step c. Another variant of the first embodiment, which reduces the number of round trips, consists in the relay UE broadcasting its configuration parameters (or part of them), policy, public key and signature at that point (step c). Once this is done, in step d, the remote UE can already check if the relay UE's policy supports its PDU communication requirements. If so, it checks the validity of the policy and public key by verifying the signature. In a subsequent step e according to this variant, the remote UE can decide to establish a PC5 connection as in solution #28, but additionally, this UE shares its signed PDU session requirements encrypted with the relay UE's public key. Finally, in step f, the relay UE can decrypt the remote UE data and verify the signature. If the verification is correct and the parameters are allowed by its policy, the relay UE supplies the remote UE's needs.

[0062] Note that here, and elsewhere in this document, verifying a signature includes checking the signature itself as well as other fields such as expiration date, issuer, etc. It also includes retrieving or accessing a revocation list that may contain revoked public keys.

[0063] In addition to the previous variant, the following can be done to (further) mitigate replay attacks: in step 1c, the relay UE can use its private key to sign on a timestamp, such as the current UTC time, and optionally the rest of the broadcasted information. This signature can also be included in step 1c. In step 1d, the remote UE checks the received signature on the UTC time to see if this time is recent. This thus avoids the risk of an attacker memorizing and replaying past messages.

[0064] In addition to the previous variant, the following can be done to (further) mitigate MitM attacks: The relay UE can use its private key to sign its current location, e.g. GPS coordinates or building name. This information can be included in step 1c. In step 1d, the remote UE validates the received signature and checks if the location matches its own. This avoids the risk that an attacker could compromise a relay device at a specific location and reuse its broadcast message at multiple locations. This feature can be used independently and stand-alone.

[0065] Since broadcasting a static RSC may be considered a privacy risk, another variant of the first embodiment consists in the sender generating a nonce N and deriving a pseudo RSC as pRSC=HASH(RSC|N), where HASH is a hash function that has as input the concatenation of RSC and N. The sender then broadcasts (pRSC,N) (step c). The receiver must apply this hash function to each of the RSCs it has and check if there is a match. For this approach to be secure and to work without collisions, pRSC, RSC, and N must be long enough. If these values ​​are only small in the discovery message (step c), the following messages may contain other pairs (pRSC',N') with longer parameters.

[0066] In the first embodiment and all variants already discussed, if step e.iii fails, the remote UE aborts the connection. It can then inform the CN about the verification failure and relay the relay UE parameters the next time it connects. Similarly, if step e.v fails, the relay UE refuses to deliver the service. It can inform the CN about the verification failure and the remote UE parameters. Thus, in case of a security risk being found, the core network is quickly informed and can check the concerned station.

[0067] In a further variant of the first embodiment, the remote UE receives, eg from the core network, the public key (or fingerprint) of the relay UE already accepted in step 1.b instead of step e.ii.1.

[0068] As described in the first embodiment, in step 1d, the remote UE checks whether the relay UE supports its PDU requirement by checking whether the RSC matches. This is a one-to-one relationship, similar to the "role-based access control" approach, which uses predefined roles to perform certain actions. In other words, if the relay UE has RSC=x, the relay UE is authorized.

[0069] This signed RSC can be seen as an "authorization token", which can be considered as the proposed operation where an RSC (unsigned "authorization token") is distributed in step 1c to perform a first check matching the bandwidth needs of the discovery message. The complete "authorization token" can be distributed in step eii if a match is found in the previous step. This simple operation, being stand-alone, can be integrated for example in solution #31 of TR33.847.

[0070] Note that in the context of "attribute-based access control", it is possible to define more complex "policies". Instead of having only the RSC, it is also possible to consider more attributes related to the relay UE's device type (e.g. is it a secret device? is it a public device?), the action being performed (e.g. upload data? is it a data download?), the data being accessed (e.g. level of confidentiality?), the application, device or group ID, or the current context (e.g. normal or emergency situation). The receiver (e.g. remote) side may have an XACML access control policy that can be used to check, for example, if the sender (e.g. relay) side is authorized. This policy can be distributed during provisioning together with other configuration parameters including any device attributes such as the RSC.

[0071] If the solution requires other sets of information (which can be thought of as roles or attributes) or configuration parameters during discovery, such as solution #11 or solution #8 of TR23.752, this information can also be signed and distributed by the CN during the initial provisioning. The CN can also distribute a policy during provisioning describing what requirements the other should meet to be allowed to act as a repeater, remote or peer. The information sent in steps e.ii and e.iv includes all or part of the information sent during discovery, including the corresponding CN signature, so that upon receipt the data can be verified and cross-checked against the policy that was also received during provisioning.

[0072] In steps 1a and 1b, the CN generates key pairs for both the remote UE and the relay UE. Alternatively, the key pairs can be generated by the UEs and the public key can be sent to the CN to be signed. The advantage of doing this is that the CN has no knowledge of the private key.

[0073] In steps 1a and 1b, the CN signs one set of information for both remote and relay UEs. The CN may also sign multiple sets of information so that these UEs can rotate them, i.e. change them regularly for privacy reasons.

[0074] In steps 1a and 1b, the CN signs public keys for both the remote UE and the relay UE. These public keys are associated with the corresponding private keys. In further variants, these key pairs can be used sometimes for public key encryption and sometimes for digital signatures. In general, it is convenient to reuse the same key pair (in a secure manner) for both signing and encryption. However, this is not a recommended practice, since it leaks information if, for example, encryption can be used to break the signature. Thus, steps 1a and 1b include the delivery of multiple signed public keys, e.g. two, such that each of the multiple signatures is used for a different purpose, e.g. encryption and signing.

[0075] If the remote UE has multiple RSCs for multiple PDU parameters, one option is for the CN to sign all the information together. The problem with this approach is that when the remote UE sends this information to the relay UE for verification (message e, iv in Fig. 3), it must send all the RSCs and PDU parameters, because otherwise the relay UE cannot verify the message. This again poses a privacy risk. A solution to this could be to build a Merkle tree with 2n leaves, where n is the number of RSCs the (remote) UE has. In this Merkle tree, leaves 2k and 2k+1 take as input the kth RSC and the corresponding PDU parameters, respectively, for k=0,...,n-1. The CN signs the root of the Merkle tree. When a remote UE has to disclose PDU parameters for its k-th RSC, it only discloses leaves 2k and 2k+1, the corresponding intermediate nodes in the Merkle tree that allow computing the root of the Merkle tree, and the CN signature at the root of the Merkle tree.

[0076] The same applies to the RSC at the relay, which in this case corresponds to the leaves of the Merkle tree. When the relay discloses a particular RSC in message e in Figure 3, it must disclose that RSC, the path in the Merkle tree to recompute the root, and the signature provided by the CN at the root of the Merkle tree.

[0077] Given this information, the recipient must use its path through the Merkle tree, the RSC (and the PDU parameters) to check that the information allows recomputation of the root of the Merkle tree, and then check the signature.

[0078] In all variants, the appropriate signature algorithm may be the Elliptic Curve (EC) Digital Signature Algorithm (DSA).

[0079] The information provided in the initial provisioning step may include a different signature for each piece of information, e.g. each RSC, each public key, each PDU parameter, etc. The advantage of this is that the different pieces of information can be disclosed independently of each other.

[0080] In the above description, public key cryptography was used. This can be replaced by identity-based cryptography (IBE). In IBE, the identity of a UE corresponds to its public key. Given the identity of a UE, the CN uses a master secret to derive the corresponding private key for that UE. The advantage of IBE is that public keys do not need to be exchanged. Another advantage is that the public key acts as a "certificate" itself, and only "authorized" parties can receive and decrypt privacy-sensitive content. For example, consider a relay with the identity "RSC=x, expiration_date=2022 / 02 / 22". This is the information that a relay can broadcast and a remote UE can receive. If RSC=x and expiration_date are OK for the remote UE according to the policy that the remote UE received from the CN during provisioning, the remote UE can use this relay UE's identity "RSC=x, expiration_date=2022 / 02 / 22" as its public key. This means that the remote UE uses this public key to encrypt even privacy sensitive parameters such as PDU parameters and sends this encrypted information, and only the repeater that has the corresponding private key issued by the core network can decrypt this information.

[0081] In the above description, a UE has a private key that can be used to prove its identity. However, digital signatures are too large for some implementations and their verification requires significant computation time. This is especially relevant for discovery messages, which are limited in size, e.g., limited to a few hundred bits. An alternative solution to this consists of the CN configuring the announcing UE (e.g., relay device) and monitoring UE (e.g., remote UE) with a hash chain seed and anchor, such that the hash chain link can be used to prove that some broadcasted messages come from the announcing UE. Such a solution is, for example, relevant for discovery messages sent by the announcing UE. This discovery message corresponds to message c in Figure 3. The security needs in protecting these discovery messages are outlined in Key Issue #1 of TR33.847.

[0082] This solution focuses on key issue #1 (discovery message protection). The solution proposes to reuse the open discovery security mechanisms specified in TS 33.303 for 5G ProSe open discovery, as does solution #3 in TR 33.847, but with the following emphasis: Improving resilience against message modification and replay attacks; Ensuring the reliability of the source; Eliminates the need for the core network to check the integrity of the announcing messages.

[0083] The proposed enhancement is motivated by the fact that in TS33.303, integrity protection of discovery messages at the PC5 interface requires a Discovery User Integrity Key (DUIK). This key is used to calculate the Message Integrity Code (MIC). The MIC can be verified in the receiving UE if it has been provisioned with the DUIK or if it is in the ProSe function with the DUIK. In the first case, the DUIK is provided to the monitoring UE, which can verify the MIC itself. However, if multiple monitoring UEs receive the same DUIK, integrity protection, replay protection, or source authenticity cannot be guaranteed, since any of these UEs may be malicious. If the ProSe function has to check the MIC, this increases the load on the CN and the overall communication latency.

[0084] The basic idea of ​​this solution is to complement the use of the DUIK with a Discovery User Integrity Hash Chain (DUIHC) for source authenticity. H j (Input) TRUNC b (Hash(identifier|j|H j-1 (input))) H 1 (Input)=TRUNC b (Hash(identifier|1|input)). Where: "|" indicates concatenation, Hash(input) refers to the calculation of a hash function for a given input. "Identifier" includes fixed and provisioned policies / parameters related to the announcing UE's identity, such as its L2 identifier, the PLMN the UE is announcing, and radio parameters when the UE is "not provisioned by NG-RAN"; · TRUNCb(A) is a function that returns b bits of the input A, for example the least significant b bits of A.

[0085] H j Including either "j" and / or "identifier" in the computation of (input) is optional, but makes the solution more resilient to pre-computation attacks. b The use of (A) aims to reduce communication overhead.

[0086] Using this, the DUIHC is derived from a randomly generated seed S as follows: S → H 1 (S) → H 2 (S) → H 3 (S) →···→H N-2 (S) → H N-1 (S) → H N (S)

[0087] Here, the arrow "→" represents the link H of the hash chain. 1 (S) → H 2 (S) → Indicates the direction when generating... The last element H N (S) is the anchor for this DUIHC.

[0088] An announcing UE, such as a relay UE, is given the seed S of its DUIHC. All monitoring UEs are given the anchor of the DUIHC of the announcing UE. These steps may take place during device authorization and initial provisioning, corresponding to steps a and b of Figure 3. Once the UEs are given these parameters, they are also given a reference time t0, which is the time when the announcing UE is assumed to use the hash chain link, and a timeslot duration tDelta.

[0089] When an announcing UE wants to send an announcement message m at UTC time t, the announcing UE first checks whether the announcing UE is connected to the DUIHC link H N-jThe announcing UE calculates the current time slot j as (t-t0) / tDelta, which means that it must use (S). Note that this requires that Nj>0. The announcing UE uses H with the DUIK to calculate the final key used in creating the MIC for message m. N-j (S). This key is denoted as the Discovery User Integrity Key and Hash Chain Link (DUIKHCHL) and is calculated as follows: DUIKHCL = Hash(DUIK|H N-j (S)

[0090] The reason for including DUIK in the derivation of DUIKHCL is to provide interoperability with existing TS33.303 solutions. This also ensures that this solution is as secure as the existing solutions. N-j Note that one may use only (S) or a key subordinate to it in computing the MIC.

[0091] The MIC of message m is MIC m and is calculated as follows: MIC m =MIC(m,DUKHCL)

[0092] The announcing UE also detects the previous DUIHC link, i.e., H N-j+1 Includes (S). m,H N-j+1 (S), MIC m

[0093] When a monitoring UE receives the above announcing message at time t, the monitoring UE first calculates the time slot j by taking the reference time t0 and the time slot duration tDelta as input. Then, the monitoring device calculates H N-jCache the received message until the next time slot j+1 for receiving (S). H N-j Using (S), the monitoring UE can check: a) The validity of the MIC received in the previous message, and therefore the integrity of the message itself. This can be done by recalculating the DUIKHCL, m This is done by checking that the MIC matches the computed MIC. b) H N-j Freshness and source authenticity of the message by checking that the received value of (S) is correct. For this purpose, the monitoring UE uses the received anchor as input.

[0094] The resulting message flow is similar to Solution #3 in TR 33.847 and the open discovery security mechanism specified in TS 33.303. Referring to Figure 6.3.2-1, the following key differences result from using the DUIK followed by the DUIHC: Step 4 (discovery response) also includes the seed S of the DUIHC, the reference time t0, and the time slot duration. Step 5 (start of announcement) is modified to use the link in the DUIHC when calculating the broadcasted MIC as described above. Step 9 (discovery response) contains the DUIHC anchor, the reference time t0, and the time slot duration. Step 10 (receiving the announced code) is modified to use the received anchor of the DUIHC in step 9 to verify the integrity, freshness and source authenticity of the broadcasted and received messages as described above. Steps 11 to 15 are not required. Additionally, If a monitoring UE detects a discovery message with an incorrect MIC or DUIHC link, it can inform the HPLMN or the DDNMF of the M-UE about the event. · If an announcing UE is disabled, the HPLMN or MU DDNMF must inform monitoring UEs that have expressed an interest in being able to discover the announcing UE. · The DUIHC anchor received by the monitoring UE in step 9 corresponds to the latest or most recently disclosed link of the DUIHC of the announcing UE.

[0095] The basic ideas described above can be applied to limited discovery mode A as well.

[0096] The basic idea described above can also be applied to restricted discovery mode B, which requires that both discoveree and discovering UEs can be holders of a DUIHC to prove their identity based on the policy. Possessing a DUIHC is especially suitable for a discoveree UE, in case multiple discovering UEs can discover the same discoveree UE, and validation of responses (response codes) from discovering UEs is done locally by the discoveree UE.

[0097] An alternative method to improve security guarantees in discovery messages, which can be used with or without the DUICH approach described above, is as follows: In Mode B, see TS33.303, the discovering UE is required to send a query code to the discovered UE. The discovered UE has to check its integrity / freshness / source reliability, and in case of successful verification, the discovered UE replies to the discovering UE with a response code. The discovering UE has to be able to check the integrity / freshness / source reliability of this message. In TS33.303, verification by the discovered UE based on the DUIK can only happen locally, but the DUIK-based verification by the discovered UE can happen locally or remotely in the core network based on a match report. This may lead to a situation where, for example, if multiple discovering UEs can discover the same discoveree UE, one of the discovering UEs misbehaves and poses as the discoveree UE. This situation can be improved by having two DUIKs: DUIKre from the discovering UE to the discoveree UE and DUIKer from the discoveree UE to the discovering UE. This way, if multiple discovering UEs discover the same discoveree UE, any discovering UE cannot spoof the response code generated by the discoveree UE, provided that the MIC of the response code is confirmed by a match report. Further details and clarifications on this second point are given below. o Key Issue #1 in TR33.847 indicates that limited discovery has integrity protection, freshness, and source authenticity as potential security requirements. Key Issue #1 also indicates the possibility of an attacker impersonating a discovered or discovered UE as a potential threat. Solution #4 reuses the LTE solution in TS 33.303. In Mode B, a discovery user integrity key (DUIK) is used to protect the query code and response code. The discovering UE sends the query code to the discovered UE. The discovered UE replies to the discovering UE with the response code. The discovered UE cannot use the match report to verify the MIC of the received query code. The discovering UE can use the match report to verify the MIC of the received response code. o This solution describes that the code sending security parameters of a discovering UE are linked to the code receiving security parameters of a discovered UE. This set of security parameters is called the query code security parameters. o This solution describes that the code sending security parameters of the discoveree UE are linked to the code receiving security parameters of the discovering UE. This set of security parameters is called the response code security parameters. This solution introduces a potential security issue because nowhere does it state that the security keys in the Query Code Security Parameter must be different from the security keys in the Response Code Security Parameter. In fact, steps 4 and 11 in Figure 6.4.2.2-1 show that the two sets of security parameters are identical. ○ If this is not explicitly stated as a requirement, simple errors can occur. For example, imagine that the exact same DUIK is set in the query code security parameter and the response code security parameter. In this situation, the discovering UE can masquerade as the discoveree UE. This can be done even though the discovering UE must use match reporting to verify the MIC of the received response code. o This issue can be addressed by requiring that a security key, e.g. a DUIK, in the code transmission security parameters of the discovering UE must not be identical to a security key in the code transmission security parameters of the discovered UE, in other words that the two DUIKs DUIKre (from the discovering UE to the discovered UE) and DUIKer (from the discovered UE to the discovering UE) must be different from each other. The way this property is explained in TR33.847 and TS33.303 is as follows: ■ The code sending security parameter of the discovering UE and the code receiving security parameter of the discovered UE shall be referred to as the query code security parameter. ■ The code sending security parameter of the discovered UE and the code receiving security parameter of the discovering UE shall be referred to as the response code security parameter. ■ It should be stated that the query code security parameter and the response code security parameter must be different.

[0098] Tdoc S3-212464 submitted to 3GPP SA3#104e describes keying procedures for group member and repeater discovery. In particular, this Tdoc describes how a UE obtains the necessary security parameters to support in-coverage and out-of-coverage discovery of group members and repeaters, e.g., for public secure scenarios. Tdoc S3-212464 explains as follows: "Group member discovery is a limited type of discovery and is expected to be supported in-coverage and out-of-coverage. Group member discovery uses provisioned keys to support integrity, confidentiality and untraceability of discovery messages. A discovery root key, from which other keys can be derived, is used to secure OTA discovery and communication. This root key can be provisioned by the 5G DDNMF and / or by the 5G PKMF." Tdoc S3-212464 further proposes a further solution based on TS 33.303 [2], namely: "For both public secure discovery scenarios, group member discovery and repeater discovery, the same solution is provided, where a public secure discovery key (PSDK) is provisioned as the root key used for protection of public secure discovery messages and is associated with one or more discovery group IDs or respective relay service codes (RSCs). Both of these identifiers are defined in TS 23.303 [5]." The steps for group membership discovery are as follows: "Step 0: The UE connects to the network and obtains authorization from the PCF to perform group membership discovery. The UE also obtains the address of the 5G DDNMF and / or 5G PKMF of its HPLMN.In addition to the security policy, the following additional parameters are sent to the UE: a set of one or more application layer group IDs, (ProSe) Layer 2 group IDs, user information, discovery group IDs, and their validity times, etc. Step 1: The UE establishes a secure connection with the 5G DDNMF or with the 5G PKMF of its HPLMN. The UE's ID is authenticated and authorized by the 5G DDNMF or the 5G PKMF. Step 2: The UE sends a discovery key request to the 5G DDNMF or to the 5G PKMF of its HPLMN. The key request includes at least the following information: the UE's ID, a set of one or more discovery group IDs, and their validity times. Step 3: The 5G DDNMF or the 5G PKMF checks whether the UE is authorized for group membership discovery. Step 4: If the check in step 3 is successful, the 5G DDNMF or 5G PKMF generates a Public Secure Discovery Key (PSDK) corresponding to the discovery group ID and its PLMN ID. Multiple PSDKs may be generated, but the overall validity time should match the validity time of the corresponding set of discovery group IDs in step 2. Step 5: The 5G DDNMF or 5G PKMF sends a key response to the UE. This key response message contains at least the following information: UE ID, PDSK identifier, PDSK, validity time. Regarding repeater discovery, the procedure / steps for repeater discovery are the same as those for group discovery described above, with the following exceptions: That is, (i) the UE is now a remote UE or a relay between the UE and the network, (ii) instead of the parameter discovery group ID a relay service code is used, (iii) instead of the Layer 2 group ID a destination Layer 2 ID is used, and (iv) no application layer group ID is used."The proposed solution Tdoc S3-212464 does not identify the need to have different keys for the query code security parameter and the response code security parameter used during the discovery phase described in the previous embodiment. If a single PSDK is provisioned as the root key used for protection of the public secure discovery message as proposed in Tdoc S3-212464, and even if the key derivation function is applied such that the query code security parameter and the response code security parameter have different DUIKs, the devices involved can generate all these keys, and thus the discovering UE may be able to spoof the discoveree UE as described above. To address this security challenge, the keying procedure for discovery must distribute different master keys, i.e. different PSDKs, used for the derivation of the query code security parameter and the response code security parameter. For example, two different master keys can be PSDK_QCSP and PSDK_RCSP, where PSDK_QCSP is used to generate the query code security parameters (including DUIK, DUSK and / or DUCK) and PSDK_RCSP is used to generate the response code security parameters (including DUIK, DUSK and / or DUCK). In this way, spoofing attacks are not feasible. PSDK_QCSP and PSDK_RCSP are independently and randomly generated or are generated from the master key by applying a key derivation function. In this last case, K is not disclosed to UEs, especially remote UEs and relay UEs, because otherwise spoofing attacks would be feasible. The generation or retrieval of these keys can be done in step 4 when the corresponding network functions in the core network, such as DDNMF or PKMF, authorize the UE and identify its role, e.g. whether the UE is a remote UE, a relay UE or both, when the corresponding network functions in the core network function in the core network.The distribution of these keys is performed in step 5 above.

[0099] In TR33.847 v0.7.0 (08 / 2021), after the construction of SA3#104e in the revision of Tdoc S3-212464, solution #37 is included. Solution #37 indicates that the keying procedure for discovery must distribute different master keys. This updated protocol improves the protocol somewhat to avoid the attacks mentioned above, since the UE can now receive several PDSKs, for example two PDSKs for the query code security parameter and one for the response code security parameter. This improves the situation compared to section 6.6.7 of TS33.303, where the protection of discovery messages between multiple UEs is described, including the fact that a (single) PDSK is distributed to the UE, allowing the generation of discovery keys (DUSK, DUCK, DUIK) from the PDSK by a key derivation function (KDF). However, the explanation in solution #37 of TR33.847 v0.7.0(08 / 2021) is still not sufficient. The reason is that a discovering UE using match reporting should not receive the DUIK used to verify the MIC or any other key that can be used to derive the DUIK. If the PDSK used to derive the DUIK is distributed to the UE because it allows it to generate the DUSK and DUCK, the problem is not solved because the UE has the PDSK and therefore can generate the DUIK. Therefore, the improved keying procedure applicable to TR33.847 v0.7.0(08 / 2021) consists of distributing the following to the UE, especially to the discovering UE: a first PDSK making it possible to generate a first set of DUIK, DUSK and DUCK used to secure the query code security parameter, and o A second DUCK and / or a second DUSK used to decrypt / descramble the response code security parameters but which does not contain a second DUIK. These second DUCK, DUSK, and DUIK keys may be generated by the KDF, for example, from the second PSDK.

[0100] In TR33.847 v0.7.0 (08 / 2021), the conclusion is reached after SA3#104e on key issues (KI)#1 and #2. In KI#1 for the restricted ProSe direct discovery scenario, solution#4 is used as the basis for normative work, which includes the note that "The security keys in the code sending security parameters of the discovering UE and the security keys in the code sending security parameters of the discovered UE are required to be generated independently and randomly. This ensures that spoofing of the discovered UE is not feasible when the discovering UE uses match reporting." The statement that the keys are generated independently and randomly is consistent with the above embodiment that requires these keys to be different to avoid spoofing attacks. KI#2 states that "The conclusion for direct discovery is as follows: (1) the discovery key includes an encryption key, an integrity key, and a scrambling key. (2) for open discovery, only the integrity key is assigned by the 5G DDNMF and is used to provide integrity protection for the announcement message. (3) for restricted discovery, the 5G DDNMF assigns the discovery key based on the requirements of the Prose service." The conclusion in KI#2 is insufficient to defeat the above-mentioned spoofing attack and is inconsistent with solution #4 because the conclusion in KI#2 limits the number of DUIKs to 1. Therefore, the conclusion for KI#2 should be updated to state that "the discovery key includes at least an encryption key, at least an integrity key, and at least a scrambling key."

[0101] Clause 6.3 in TS33.503 describes security for relaying communication between UE and network in 5G ProSe. Regarding security for 5G ProSe communication and control plane in relay between UE and network via 5G ProSe Layer 3 (clause 6.3.3.3 in TS33.503), it is stated that "PCF shall provision authorization policy and parameters for relay discovery and communication between UE and network in 5G as specified in 5.1.4 in TS23.304[2]". Clause 5.1.4 in TS23.304 states that "Whether security parameters can be provided by PCF and the details of security parameters are determined by SA3 WG". The first two steps of the message flow in Figure 6.3.3.3.2-1 in TS33.503 state that "Remote UE and relay UE shall be registered in the network". It states that "a relay between a UE and a network must be authenticated and authorized by the network to support it as a relay UE. A remote UE must be authenticated and authorized by the network to function as a remote UE." For this purpose, the remote UE and the relay UE must contact their respective AMFs. The AMFs act as the entry point for registration in the network. According to clause 4.3.4 of TS 23.304, the AMF selects "a PCF that supports 5G ProSe policy / parameter provisioning based on the indication of 5G ProSe capabilities as part of the "5GMM capabilities" in the registration request." It then states that "the remote UE shall initiate a discovery procedure using either the Model A or Model B method as specified in clause 6.3.1.2 or 6.3.1.3 of TS 23.304 [2], respectively."At a later stage in the process (step 4 in Figure 6.3.3.3.2-1 in TS 33.503), the AMF of the relay UE authorizes the relay UE to act as a relay (for the remote UE). Note that the AMF does so by contacting the UDM to obtain 5G ProSe related subscription information from the UDM and store it as part of the UE context data according to clause 4.3.4 of TS 23.304.

[0102] It is not possible for two different entities to be in charge of managing the parameters and discovery keys that need to be distributed to both relay and remote UEs for the discovery procedure to work. Thus, the current specification in TS33.503 does not resolve which entity manages the discovery parameters and keys and which entity authorizes the UE to obtain the discovery parameters and keys. In particular, it is possible for a single network function in a single network to be in charge of managing the discovery keys, which could be the PCF, PKMF, DDNMF or other NF in one of the networks.

[0103] In a first embodiment that overcomes the above-mentioned problems, a remote UE (or relay UE) registers with its network and seeks authorization for a given network relay service provided by a different network, for example the network of the relay UE (or remote UE). In this case, the network of the remote UE (or relay UE) (e.g. through the AMF or PCF) informs the network of the relay UE (or remote UE), in particular the PCF or the key management function responsible for the discovery key (e.g. PKMF, DDNMF) of the relay UE (or remote UE), about (the identity of or the requested relay service by it). When doing so, the network of the relay UE (or remote UE) (e.g. PCF) provides the network of the remote UE (or relay UE) with the corresponding discovery parameters and keys for the remote UE (or relay UE). The network of the remote UE and the network of the relay UE can cooperate to create discovery credentials or keys based on inputs (e.g. partial keys, UE identity or network identity) from both networks. Once this is done, the remote UE (or relay UE) is registered, authenticated and authorized by the remote UE (relay UE) network as described in steps 0a and 0b in the message flow in Figure 6.3.3.3.2-1 of TS33.503. In particular, it receives discovery parameters and keys at this stage. Every time the remote UE (or relay UE) network (e.g. PCF) updates discovery parameters and keys, it must contact the relay UE (or remote UE) network (e.g. PCF) which will then be responsible for updating the parameters to the relay UE (or remote UE).

[0104] In a second embodiment that overcomes the above-mentioned problems, a remote UE (or relay UE) registers with its home network and seeks authorization for a given network relay service provided by a different network, for example the network of the relay UE (or remote UE). In this case, the network of the remote UE (or relay UE) (e.g. through the AMF or PCF) informs the network of the relay UE (or remote UE), in particular the PCF of the relay UE (or remote UE), about (the identity of) the remote UE (or relay UE) and the need for relay service. Furthermore, the network of the remote UE (or relay UE) (e.g. through the AMF or PCF) informs the remote UE (or relay UE) about the network of the relay UE (or remote UE), in particular the AMF or PCF of the relay UE (remote UE) and / or the key management function that is responsible for discovery keys and has to be contacted for registration, authentication and authorization and / or discovery key retrieval in steps 0a and 0b of the message flow in Figure 6.3.3.3.2-1 in TS33.503. This means that when this second embodiment is used, both the remote UE and the relay UE will retrieve discovery parameters and keys from the same network, i.e. the serving network, in particular both the remote UE and the relay UE will retrieve discovery parameters and keys from the corresponding, e.g., PCF.

[0105] In a third embodiment, which can be combined with the above embodiments, the network of the relay UE and the network of the remote UE interact to match or align the relay service code. For example, in the first embodiment described above, when the network of the remote UE (or relay UE) informs the network of the relay UE (or remote UE) about the relay service requested (given) by the relay UE (or remote UE), the network of the relay UE (remote UE) matches / aligns the relay service code of the other network with the relay service code used in its own network.

[0106] Clause 6.3 of TS33.503 describes security for relay communication between UE and network in 5G ProSe. In the security for 5G ProSe communication via relay between UE and network in layer 3 in 5G ProSe, a user plane (UP) approach (clause 6.3.3.2 of TS33.503) and a control plane (CP) (clause 6.3.3.3 of TS33.503) are described for relay authorization and security establishment between UE and network in layer 3 in 5G ProSe. Figure 7 refers to Figure 6.3.3.2.2-1 of TS33.503 (authorization and secure PC5 link establishment procedure for relay between UE and network in UP), and Figure 8 refers to Figure 6.3.3.3.2-1 of TS33.503 (authorization and secure PC5 link establishment procedure for relay between UE and network in CP). In both UP and CP based procedures there are three phases (as shown in Figures 7 and 8): - a first phase involving the provisioning of discovery parameters, including a discovery key; - a second phase involving a discovery procedure that relies on provisioned discovery parameters, and - The third phase is for PC5 certification and security establishment.

[0107] Although the second phase relies on the same discovery protocol, the first and third phases may involve different protocols or entities (network functions). This may lead to interoperability issues, e.g., even if the UE is configured with discovery parameters / keys based on the first phase of UP, the third phase is CP-based with respect to PC5 authorization and security establishment. The interoperability issues may be due to a lack of initialization of certain network functions, e.g., between the first phase of a UP-based approach (CP-based approach) and the third phase of a CP-based approach (UP-based approach).

[0108] A more complete description, when the entities involved in both UP and CP procedures are included, is given in Figure 9. Figure 9 outlines some of the interactions and communications that ensure interoperability between the first and third phases of a UP / CP-based approach.

[0109] In Fig. 9, in relation to reference sign (a), relay authorization (step 4 in Fig. 8) may occur when the UE starts the CP-based third phase if the UE is configured via the UP approach in the first phase by the relay PKMF interacting with a network function in the relay network, e.g., AMF or UDM, via a communication interface, which is indicated by Tdoc S2-2200214 as Npc10 (a reference point between the UDM and the 5G PKMF, which is used to provide subscription information to authorize whether the UE can function as a 5G ProSe remote UE or a 5G ProSe UE-to-network relay). This communication may occur, for example, after the UE is configured via the UP approach (i.e., the PKMF pushes the configuration to the AMF) or on demand when the UE starts the CP-based third phase (i.e., the AMF sends a request to the PKMF).

[0110] In Fig. 9, with reference to reference sign (b), the remote PKMF and the remote AUSF / UDM interact with each other via the communication interface to inform each other about the remote configuration so that they are ready for the CP-based third phase procedure and the remote UE's network can authorize the remote. This communication can occur, for example, after the UE is configured via the UP approach (i.e., the PKMF pushes the configuration to the AUSF / UDM), as in steps 4-10 of Fig. 8, or on-demand when the UE starts the CP-based third phase (i.e., the AUSF / UDM sends a request to the PKMF).

[0111] In Fig. 9, in relation to reference sign (c), the AMF-PCF(remote), PCF(remote)-PCF(remote), PCF-DDNMF, DDNMF-PKMF(remote) interactions to retrieve keys managed by the PKMF(remote) for the initial first phase (discovery parameters / key configuration) in the CP-based procedure are shown, where a network function such as the PKMF(remote) manages keys for both the UP and the CP.

[0112] In Fig. 9, in relation to reference sign (d), the interactions to retrieve keys from the PKMF(repeater) for the initial first phase (discovery parameters / key configuration) in the CP based procedure are shown: AMF-PCF, PCF-DDNMF, DDNMF-PKMF(repeater) and finally PKMF(remote)-PKMF(repeater), where a network function such as the PKMF(repeater) manages the keys for both the UP and the CP.

[0113] In the following, different embodiments are described. Following KI#16 of TR33.847, the first embodiment and its above mentioned variants address / are applicable to other key issues related to relaying between UE and network, including at least: o Key Issue #4 (KI#4) concerns the authorization in relaying scenario between UE and network, i.e. how to authorize a relaying UE to act as a relay. This can be done in step 1 e.iii, where a remote UE can check the RSC of the relay and, if the signature is valid, verify that it has been authorized by the CN to provide the corresponding service. Key Issue #3 (KI#3), Security of Relay between UE and Network, and Key Issue #9 (KI#9), Key Management for Proximity Services in 5G for Relayed UE-to-Network Communication, relate to how keys should be handled and how the PC5 link is protected.

[0114] The setup described in the first embodiment can be extended to address these key issues. To secure the PC5 communication link between the remote UE and the relay UE, a shared secret key K' can be exchanged. One option is that the remote UE randomly generates the shared secret key K' before step e.iv. In step e.iv, it sends K to the relay UE in a secure manner by encrypting it. The signature included in step e.iv can also have the (encrypted) K as input so that the relay can check the integrity of K. The shared secret key K' is calculated, for example in step e.vi by applying the KDF to the concatenation of K, N_remote and N_relay. This is shown in Figure 4. Other options arise if extension 1 is available. In this case, K can be generated by the relay UE and sent to the remote UE in step e.ii.

[0115] A suitable approach for key exchange is the Elliptic Curve (EC) Diffie-Hellman algorithm. A suitable approach for public key cryptography is the EC Unified Encryption scheme.

[0116] The above paragraphs describe distributed alternatives to TR33.847 solutions #1, #6, #10 and #15 for addressing KI#9. In these solutions, the core network is responsible for the generation and distribution of a shared symmetric key between the remote UE and the relay UE. In particular, the remote UE sends a "direct communication request" to the relay UE which triggers a further request to the CN to distribute / generate a shared secret key that can be used to secure PC5 between the remote UE and the relay UE.

[0117] o Key Issue #11 (KI#11) concerns UE identity protection during ProSe discovery, i.e. how the identity of the UE during discovery should be protected. This is done as in step 1 e.i, where the remote UE replies with a nonce only upon reception of the RSC broadcasted by the relay. This nonce can have two purposes here. The first one is related to freshness as already explained in the main protocol. The second one is to act as a temporary identifier of the UE, so that its true identity is not revealed until the remote UE has confirmed that the relay UE is authorized to act as a relay. The true identity of the remote UE is revealed in step 1 e.iv together with the PDU parameters.

[0118] The first embodiment and its variants mentioned above address / can be applied to other key issues related to UE-to-UE relaying, in which two remote UEs need to communicate with each other directly via a relay UE.

[0119] Please note that in TR23.752, solution #11 is selected as the bottom line for model A discovery, and solution #8 is selected as the bottom line for model B discovery. In case of solution #11, the discovery information includes (i) type=announcement, (ii) discovery type=UE-to-UE relay discovery, (iii) announcer information (i.e., higher layer identifier for UE-R user), (iv) UE ID in UE-R ProSe (i.e., UE-R Layer 2 identifier), and (v) a list of "target user information" parameters (or attributes) collected during group member discovery in step 2 (including users UE-1 and UE-2). "Target user information" is a higher layer parameter that identifies the target user. To support Layer 2 communication via stateful UE-to-UE relay, the "target user information" also includes the target user's UE Layer 2 identifier. In solution #8, discovery information is performed by sending a "broadcast" direct communication request rather than a separate discovery message, which includes source UE information, target UE information, and application ID, as well as a relay service code.

[0120] o Key Issue #6 (KI#6) concerns the integrity and confidentiality of information in relays between UEs, i.e. how to protect the communication between two remote UEs communicating through a relay UE. In particular, following the above solution, once two UEs identify and connect to a suitable relay, these two UEs can use the same information established by the CN to exchange symmetric keys (as in extension 2) that can be used to secure the communication between both UEs.

[0121] Related Work and Differences: It should be noted that Solution #8 in TR33.847 also uses public keys to address the same scenario. However, the current solution has some FFS that are addressed in this solution. Solution #16 also addresses KI#6, although it does not directly mention public key cryptography.

[0122] In the following it is explained how solution #8 can be improved by using public key cryptography, some of these improvements are also applicable to solution #16.

[0123] The first point that remains to be discussed is how the public key is bound to a specific UE, which means that this solution does not provide any means of authentication and is vulnerable to man in the middle attacks. In this solution, this is solved because the public key assigned to the UE is signed by the CN.

[0124] Solution #8 also describes the exchange of public keys in messages 2 and 4, and in step 6 it says that "the extended link is secured end-to-end using the public keys of the source UE and the target UE while the routing information remains in the clear." From this description, it seems to rely on the Diffie-Hellman key exchange scheme, where the private key is equal to pr_A*PU_B=pr_B*PU_A, where pr means the private key and PU means the public key. This solution therefore does not cover ECIES or Key Encapsulation Mechanisms (KEMs), for example, standardized by NIST Post-Quantum Cryptography (PQC). Examples of PQC KEMs include SABER, Round5, Kyber, or NTRU. The difference here is that in message 2, the source UE sends its public key, and the target UE randomly generates a random key K that is encapsulated with the source UE's public key upon receipt. Message 4 contains the ephemeral public key component from the target UE and the encapsulated key.

[0125] Another FFS in solution #8 is how to verify that the DCA message is trustworthy. This can be verified if the public key is signed by the CN, as is done in steps 1.a and 1.b in the current solution. As mentioned above, the IBE solution can be used as well.

[0126] Solution #8 configures the relay with policies / parameters in step 0, then relays the message in step 3 if the policies match and the relay is allowed to relay the message. This approach has several challenges: *First, message #2 (direct communication request from source UE to UE-to-UE relay) can be replayed. This can be avoided if the message contains a nonce that was originally revealed by the relay and signed by the source UE. Alternatively, the source UE can also sign the current time, so that the relay will only accept messages that are within a given time window. This is similar to step 1 e.iv. *Second, the parameters in message #2 are left in the clear and are not integrity protected, which means that they can be modified by an attacker. By observing whether the relay or the target UE reacts to messages 2 and 3, the attacker can also know, for example, which ProSe applications the relay or the target UE supports. This can be solved if the relay first reveals its public key (e.g., sends it to the source UE) and the source UE uses it to encrypt any privacy-sensitive parameters. This is similar to step 1, e.ii.

[0127] Figure 5 illustrates how Solution #8 can be improved based on the above ideas. *Steps a0, a1, a2 relate to the initial provisioning of the UE and the relay. This initial provisioning is similar to steps a and b in the main solution, with the addition / difference that these devices are provisioned with information / policies related to their ability to relay information in case of use between UEs. *Step c is as in the first embodiment or its variants. *Step ei is as in the first embodiment or its variants. *Step e.ii is similar to that in the first embodiment or its variants, with the addition / difference that this time the relay station distributes signed information related to its ability to relay information in case of use between UEs. *If this information is successfully verified by the source UE, it replies with e.iv as in the main solution. Note that since the source UE has the relay's public key, these parameters can be encrypted to ensure privacy. Note that since the source UE's public key is signed by the CN, the source UE can sign any communication parameters to avoid MitM / replay attacks. Some of these ProSe parameters (e.g. broadcasted layer 2 ID, ProSe application ID, UE application layer ID, target UE application layer ID, relay applicable indication) are also directly signed by the CN and provided to the source UE in step a0. * In step ev the relay checks if it can / is allowed to forward information in this connection. It also checks if the source UE is who it claims to be. These checks are very similar to the first embodiment. *Step e.vi consists of forwarding the information to the target UE. However, it must be taken into account that the information in e.iv is encrypted with the key of the repeater and the target UE does not have the corresponding private key. However, the target UE can decrypt and encrypt the information again based on the public key of the target UE. Instead, the repeater can use a symmetric key shared between the target UE and the remote UE and established at an earlier stage, i.e. when the target UE went through steps ei, e.ii and e.iv of c itself during the connection with the repeater. The repeater already knows the preferences / policies of the target UE (e.g. whether they have been disclosed to the repeater beforehand) and therefore the repeater forwards this message only if it satisfies the policy of the target UE. This step also includes one or more nonces, e.g. the nonce in step ei, the nonce in step e.ii or a combination thereof. *Step e.vii concerns the target UE checking the incoming message. It checks if the source UE fulfills its policy / communication needs. The target UE is able to check this because it receives the source UE's communication information signed by the CN and / or the source UE. In a specific option in step e.vii, the target UE can randomly generate a symmetric key K and use the received (quantum resistant) public key of the source UE to encapsulate / encrypt the randomly generated symmetric key K, and the source UE generates its ephemeral public key for this purpose. *Step e.viii is used to verify the communication and includes the public key of the target UE. It may also include further information from the target UE, for example signed by the CN so that the source UE can verify it. This information can be encrypted with the encapsulated key (step e.vii) or with the public key of the source UE. This information is also signed by the target UE. Alternatively, a message authentication code can also be obtained using a symmetric key previously established between the relay and the target UE. The purpose of the signature or MAC is to inform the relay that this is a trustworthy message and can be forwarded. This message may also include the nonce in step e.vi so that the relay and the source UE can check the freshness of the message. * Step e.ix involves the repeater checking the signature or MAC exchanged in step e.viii. *Step ex includes the message of e.viii without signature or MAC. Upon receiving this message, the source UE can decapsulate the symmetric key and decrypt any information related to the target UE. After decryption, the source UE can verify the information by checking the signature and the freshness by checking the nonce.

[0128] The steps in FIG. 5 (described above) and FIG. 6.8.2.1-1 of TR33.847 correspond to each other as follows:

[0129] [Table 2]

[0130] o Key issue #7 concerns authorization in UE-to-UE relaying scenarios, i.e. how remote UEs can be sure that they are authorized to interact with each other. In particular, once two UEs have identified and connected to a suitable relay following the above solution, the following can be assumed: ■ At the very first configuration stage, the CN network in the initial provisioning phase must provide each UE with a policy that describes its communication attributes and that determines which attributes are required by the UE to allow device-to-device communication links with other UEs. Each UE must also receive a public key signed by the CN. The UE must have the corresponding private key or receive it from the CN as well.

[0131] During operation, two options are considered: ■ Option 1: During operation, one of the UEs sends its communication policy to the other UE. The second UE checks it and, if it is authorized, sends its own communication policy to the first device. If the first device also authorizes the second device, it sends a confirmation to the second device. ■ Option 2: During operation, when a UE joins a group, it first receives parameters from the relay signed by the CN, which is similar to step e.ii in Fig. 3. The UE then checks whether the relay is authorized for UE-to-UE communication and supports its communication needs (RSC), which is similar to the check in step e.iii in Fig. 3. The UE then sends its communication parameters to the relay UE, which is similar to e.iv in Fig. 3. The relay UE checks them (step ev in Fig. 3).

[0132] The first embodiment and its variants mentioned above also address / are applicable to other key issues related to groupcast communication, in particular this relates in part to KI#13 of TR33.847 which is concerned with protecting L2 IDs for linkability, traceability and privacy with respect to security and privacy of groupcast communication, and also with integrity / confidentiality of communication.

[0133] We now present a solution that addresses these issues arising for option 2 described above with respect to key issue #7. After performing the steps described in option 2, the relay can check whether the UE is authorized to communicate with other UEs that are already part of the group of UEs. If the UEs are authorized to interact with each other, the relay will notify each of the UEs in the group. In particular, assume that a new UE, Z, has joined. When the relay notifies the remote UEs (A, B, . . . , Y) about the new UE, Z, that is joining the group, the relay will send N-1 messages M, one message M to each of the UEs (A, B, . . . , Y) that were already in the group. This message M is similar to e.iv of Fig. 3, where (i) PuK_relay is replaced by the public keys of A, B, ..., (ii) N_relay is replaced by the nonce sent earlier by A, B, ..., Y, (iii) S(PrK_CN,RSC|PDU_param|PuK_remote) is the signature from the core network on the capabilities of the new device Z on behalf of the remote device, and (iv) S(PrK_remote, ...) is replaced by the signature from the relay device on the sent parameters. Furthermore, the relay must also inform the new device Z about the existing devices (A, B, ..., Y). For this purpose, the relay sends a message M' to Z. M' is like M, but instead of containing information about a single device, it contains information about N-1 devices.

[0134] In addition, the repeater can handle a master group key that can be used for communication within the group. The repeater randomly generates this master group key K that can be distributed to the UEs in a protected manner in the above messages M and M'. A new master group key can be generated every time a new device joins or leaves the group. The derived group key K' can be derived as a key derivation function that uses K and the nonces of all devices in the group as input. For example, a hash function can be applied to the concatenation of K and each of the nonces sorted by an increasing value and a counter i. This counter i can be used to rotate K' over time.

[0135] This key can also be used to derive the destination L2-ID, for example, by applying a key derivation function to K' and taking the least significant bits.

[0136] It should be noted that this approach to checking group mutual authorization and allocation means that a repeater must send a total of N-1 messages. 2 This is an improvement over solutions where each UE authenticates / authorizes each other, which may require overhead of 1 message. Such an advantage is also described in solution #12 addressing KI#8: "UE1 can communicate with multiple target UEs on PC5 unicast links via relays between the UEs. In that case, all target UEs must be informed of UE1's new IP address / prefix."

[0137] The solution is illustrated in Figure 6 and its main steps are as follows: *Steps a, b, c relate to the initial provisioning and are similar to steps a and b in FIG. *Step d refers to discovery and distributed authentication / authorization, which includes steps similar to c, d, e i, e ii, e iii, e iv, and e v in Figure 3. * Step e involves checking whether the new UE, Z, is admitted in the group according to the policy of other UEs. *Step f concerns the generation of the master group key, as already defined. * Step g involves sending a message M to each UE that was already part of the group. * Step h relates to sending a message M' to the new UE. *Step i concerns the generation of the current group key.

[0138] Other variations to the disclosed embodiments will be understood and effected by those skilled in the art from a study of the drawings, the disclosure, and the appended claims in practicing the claimed invention. In the claims, the terms "having, comprising, including" do not exclude other elements or steps, and singular elements do not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The above description sets forth certain embodiments of the invention in detail. However, no matter how detailed the above description may be in the text, the invention can be realized in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of certain terms in describing certain features or aspects of the invention should not be interpreted as implying that the terms are redefined herein to be limited to include any specific characteristic of the relevant feature or aspect of the invention.

[0139] As explained throughout the previous embodiments, the proposed variant of the invention can be implemented in a network, such as a cellular network, such as the 5G network shown in FIG. 10. The cells of the network are served by a primary station 1000. In the coverage of the primary station 1000 (e.g. gNB), several secondary stations can be connected to it. A secondary station can be configured to operate as a relay station 1010. Such a relay station comprises a transmitter 1011 coupled to a transmit antenna and a receiver 1012 coupled to a receive antenna. Typically, these receive and transmit antennas are the same antenna. Furthermore, depending on the technology, these antennas can be formed by antenna arrays allowing different transmit / receive modes, such as MIMO, transmit diversity, and operation on different sets of frequencies.

[0140] The controller 1013, e.g. a CPU or microcontroller running with software, is configured to control the transmitter and receiver and to control the antenna. It should be noted that some or all of the transmitter, receiver and controller may be part of a single baseband processor. In the context of the above described embodiment, the controller is configured to establish a connection between the relay station 1010 and the primary station 1000. More specifically, the controller 1013 may configure the receiver 1012 to receive a first set of configuration parameters including an attribute or service code in at least one secure message from the primary station 1000.

[0141] The controller 1013 can control the transmitter 1011 to cause it to transmit at least one transmitted attribute or service code from the first set of configuration parameters, which can be broadcast to be received by other stations, such as the secondary station 1020.

[0142] Furthermore, the controller 1013 can then be configured to establish direct communication with the secondary station 1020 using the public key upon request from the secondary station, where the request is based on the transmitted service message.

[0143] Typically, a relay station is a UE, such as a sidelink compatible UE, which is therefore capable of acting as a relay station when configured. Alternatively, a relay station could be another primary station, such as an access point, gNB or femtocell gNB.

[0144] The secondary station 1020 is typically a UE and comprises a transmitter 1021 and a receiver 1022, both of which are typically coupled to one or more antennas or antenna arrays. The secondary station 1020 further includes a controller 1023 configured to control the receiver 1021 and the transmitter 1022 and possibly other elements of the UE. As with a relay station, the controller 1023 is a processor or CPU and is operated by software.

[0145] The controller 1023 can cause the receiver 1021 and the transmitter 1022 to establish a connection with the primary station 1000. This includes, for example, configuring the receiver 1021 to receive from the primary station 1000, in at least one second secure message, a second set of configuration parameters including a relay service code or attributes linked to future data exchanges with the relay station 1010.

[0146] The receiver 1021 is configured to receive at least one transmitted attribute or service code from the relay station 1010, and the controller may be configured to determine whether to cause the transmitter to establish direct communication with the relay station 1010 upon determining that the transmitted attribute or service code is included in a second set of configuration parameters or satisfies a policy therein and that the transmitted service code is included in the second set.

[0147] The described operations as shown in Figures 3 to 9 can be implemented as program code means of a computer program and / or as dedicated hardware in the associated communication or access device, respectively. The computer program can be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless communication systems.

Claims

1. 1. A method for operating a communication system including a primary station linked to a core network and serving a cell, a relay station served by said primary station, and a secondary station served by said primary station, said method comprising the steps of: the relay station establishing a connection with the primary station, the connection including receiving a first set of configuration parameters including a service code in at least one first secure message from the primary station; the secondary station establishing a connection with the primary station, the secondary station including receiving from the primary station a second set of configuration parameters including a relay service code linked to a future data session in at least one second secure message; transmitting, by the relay station, at least one transmitted service code from the first set of configuration parameters; if it is determined that the at least one transmitted service code is included in the second set of configuration parameters, the secondary station establishes direct communication with the relay station; The method comprising:

2. The method of claim 1 , wherein the at least one first secure message further comprises a relay public encryption key and a corresponding relay private encryption key.

3. The method of claim 1 or 2, wherein the at least one second secure message further comprises a secondary station public encryption key and a corresponding secondary station private encryption key.

4. The at least one first secure message comprises at least: A relay public encryption key; one of at least one attribute of the first set of configuration parameters or the service code of the first set of configuration parameters; at least one first core network signature from the core network generated in The at least one second secure message comprises at least: A secondary station public encryption key; one of at least one attribute of the second set of configuration parameters or the service code of the second set of configuration parameters; The method of claim 2 or 3, further comprising:

5. The at least one first secure message comprises at least: A relay public encryption key; one of at least one attribute of the first set of configuration parameters or the service code of the first set of configuration parameters; at least one first core network signature from the core network generated in The at least one second secure message comprises at least: parameters related to the future data session and included in the at least one second secure message; A secondary station public encryption key; one of at least one attribute of the second set of configuration parameters or the service code of the second set of configuration parameters; The method of claim 2 or 3, further comprising:

6. The step of establishing direct communication includes: a. the secondary station sending a direct communication request to the relay station; b. the relay station responding to the direct communication request with a response message including the relay public encryption key, the first core network signature, and a response message signature; c) the secondary station checking the first core network signature included in the response message and the response message signature; The method according to claim 4 or 5, comprising:

7. 7. The method of claim 6, wherein the direct communication request includes a secondary station nonce, and the response message signature is generated by applying a relay private encryption key to at least the secondary station nonce.

8. 8. The method of claim 7, wherein the response message signature is generated by applying the relay private encryption key to at least the secondary station nonce and at least one of a core network first signature and the relay public encryption key.

9. 9. The method according to claim 6, wherein the response message further comprises a relay nonce, and wherein the secondary station transmits the communication parameters in a configuration message, the configuration message comprising a configuration message signature, the configuration message signature being generated by applying a secondary station private encryption key to at least the relay nonce.

10. 10. The method of claim 9, wherein the configuration message signature is generated by applying the secondary station private encryption key to at least the relay nonce and at least one of a core network second signature and the secondary station public encryption key.

11. The step of establishing direct communication includes: a. the secondary station generating or selecting a secondary station cryptographic public key, a secondary station cryptographic private key, and a secondary station nonce, and sending a direct communication request to the relay station; b. the relay station responding to the direct communication request with a response message including a relay public encryption key, a first core network signature, and / or a response message signature, the response message being encrypted using the public key received in step a; c) the secondary station decrypting the response message and checking the first core network signature included in the response message and the response message signature; The method of claim 1 , comprising:

12. 12. The method according to claim 1, wherein the relay station transmits the at least one transmitted attribute of the first set of installation parameters or a service code from the first set of configuration parameters and at least one of the following further information: a data session policy, a data session parameter, a first core network signature, and a relay public encryption key; and the secondary station establishes a direct communication with the relay station if it determines that the transmitted attribute of the first set of configuration parameters or the transmitted service code is included in the second set of configuration parameters and that the further information is compatible with the upcoming data session.

13. The method of claim 12 , wherein the message sent from the relay station includes a signature applied to at least a timestamp.

14. 14. The method of claim 1, wherein the at least one transmitted service code from the first set of configuration parameters is a result of a hashed service code of the first set of configuration parameters combined with a transmitted nonce, the relay station further transmitting the transmitted nonce.

15. The method of claim 6 or 11, further comprising the step of the secondary station notifying the core network if the step of checking the first core network signature fails.

16. 2. The method of claim 1, wherein the relay station establishing a connection with the primary station comprises: the relay station generating a relay public encryption key and a relay private encryption key; sending the relay public encryption key to the primary station for signing by the core network; and receiving the first set of service codes and a first core network signature based on at least the relay public encryption key in the at least one first secure message from the primary station.

17. 17. The method of claim 1 or 16, wherein the step of the secondary station establishing a connection with the primary station comprises the steps of: the secondary station generating a secondary station public encryption key and a secondary station private encryption key; sending the secondary station public encryption key to the primary station for signing by the core network; and receiving the second set of service codes and a second core network signature based on at least the secondary station public encryption key in the at least one second secure message from the primary station.

18. 1. A method for operating a relay station for communication in a network including a primary station linked to a core network and serving a cell, and a secondary station served by said primary station, said method comprising the steps of: the relay station establishing a connection with the primary station, the connection comprising receiving a first set of configuration parameters, the first set of configuration parameters including a number of attributes or a set of service codes, in at least one first secure message from the primary station; transmitting, by the relay station, at least one attribute from a second set of configuration parameters or a transmitted service code from the second set of configuration parameters; the relay station establishing direct communication with the secondary station upon request from the secondary station based on the transmitted service code; The method comprising:

19. 1. A method for operating a secondary station for communication in a communication system including a primary station linked to a core network and serving a cell, and a relay station served by said primary station, said method comprising the steps of: the secondary station establishing a connection with the primary station, the secondary station receiving from the primary station in at least one second secure message a public encryption key and a second set of attributes or a relay service code linked to future data exchanges with at least one relay station; receiving, by the secondary station, at least one transmitted attribute or relay service code from the relay station; the secondary station determining whether the transmitted attribute or relay service code is included in the second set of configuration parameters, and if the secondary station determines that the transmitted attribute or relay service code is included in the second set of configuration parameters or satisfies a policy therein, establishing direct communication with the relay station; The method comprising:

20. 1. A relay station for communication in a network including a primary station linked to a core network and serving a cell, and a secondary station served by said primary station, said relay station being served by said primary station, said relay station comprising: A transmitter; A receiver; a controller configured to establish a connection with the primary station and to configure the receiver to receive a first set of configuration parameters including an attribute or service code in at least one first secure message from the primary station; Equipped with The transmitter transmits at least one transmitted attribute or service code from the first set of configuration parameters; The relay station, wherein the controller, upon a request from the secondary station based on the transmitted service code, establishes direct communication with the secondary station using a public key.

21. A secondary station for communication in a communication system including a primary station linked to a core network and serving a cell, and a relay station served by said primary station, said secondary station being served by said primary station, said secondary station comprising: A transmitter; A receiver; a controller for establishing a connection with the primary station, the controller configuring the receiver to receive from the primary station in at least one second secure message a second set of configuration parameters including attributes or a relay service code linked to future data exchanges with at least one relay station; Equipped with The receiver receives at least one of the transmitted attributes or relay service codes from the relay station; The controller determines whether the transmitted attribute or relay service code is included in or satisfies a policy within the second set of configuration parameters, and when it is determined that the transmitted relay service code is included in the second set of configuration parameters, causes the transmitter to establish direct communication with the relay station.

Images