CN116918300A

CN116918300A - Method for operating a cellular network

Info

Publication number: CN116918300A
Application number: CN202280016331.7A
Authority: CN
Inventors: O·加西亚莫尔琼
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2021-02-22
Filing date: 2022-02-22
Publication date: 2023-10-20

Abstract

The present invention relates to a method for operating a communication system comprising a primary station, a relay station and a secondary station, the primary station being linked to a core network, the primary station serving a cell, the relay station being served by the primary station, the secondary station being served by the primary station, the method comprising the steps of: the relay station establishing a connection with the primary station, comprising receiving a first set of configuration parameters in at least one first security message from the primary station; the secondary station establishing a connection with the primary station, comprising receiving a second set of configuration parameters in at least one second secure message from the primary station, the second set of configuration parameters being linked to an upcoming data session; the relay station transmitting at least one transmission service code from the first set; the secondary station establishes direct communication with the relay station upon determining that transmission configuration parameters are included in the second set.

Description

Method for operating a cellular network

Technical Field

The present invention relates to the field of wireless communications, and in particular to relay architecture in a cellular network environment, 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

In a conventional cellular network, a primary station serves a plurality of secondary stations located within a cell served by the primary station. Wireless communication from the primary station to each secondary station is accomplished on a downlink channel. Instead, wireless communication from each secondary station to the primary station is accomplished on an uplink channel. Wireless communications can include data traffic (sometimes referred to as user data) and control information (sometimes referred to as signaling). The control information typically includes information (e.g., resource allocation/request, physical transmission parameters, information about the status of the individual stations) for assisting the primary and/or secondary stations in exchanging data traffic.

In the context of cellular networks standardized by 3GPP, the primary station refers to a base station, or in 5G (NR) to a gndeb (or gNB), or in 4G (LTE) to an eNodeB (or eNB). The eNB/gNB is part of a radio access network RAN that interfaces with functions in a Core Network (CN). In the same environment, the secondary station corresponds to a mobile station, or in 4G/5G to a user equipment (or UE), which is a wireless client device or a specific role played by such a device. The term "node" is also used to refer to a UE or a gNB/eNB.

In 3GPP, the role of relay node has been introduced, as shown in fig. 1. The relay node 120 is a wireless communication station 120, and the wireless communication station 120 includes a function for relaying communication between the base station 100 and the UE 110. The relay function, for example, helps to extend the coverage of the cell 10 to out-of-coverage (OoC) mobile stations 110. The relay node 120 may be a mobile station or may be a different type of device. In the specification of 4G, proximity services (ProSe) functionality is defined, inter alia, in TS23.303 and TS24.334 to enable connectivity or the like of cellular User Equipment (UE) 110 that is temporarily not within the coverage area of cellular network base station (eNB) 100 of serving cell 10. This special function is called ProSe UE to network relay, or simply relay UE. Relay UE120 relays application and network traffic in both directions between OoC UE110 and eNB 100. In TS23.303 and TS24.334, local communication between relay UE120 and OoC UE110 is referred to as device-to-device (D2D) communication or side link (also referred to as PC 5) communication. Once the relay relationship is established, the OoC UE110 makes an IP connection via the relay UE120 and plays the role of "remote UE" 110. This situation means that the remote UE has an indirect network connection TS22.261 to selected functions of the core network, as opposed to a direct network connection TS22.261 to all core network functions in normal circumstances.

Additionally, in such a system, as depicted in fig. 2:

a) The remote UE is able to talk to the base station/core network through UE-to-network relay.

B) The source UE is able to talk to the destination UE through UE-to-UE relay.

C) A group of UEs are able to talk to each other in multicast communications, sometimes through UE-to-UE relay.

In 3gpp SA2, a communication model and procedure of a relay-based system are being discussed and agreed upon. These processes are included in TR 23.752. In 3gpp SA3, security solutions and procedures are being discussed and agreed upon with respect to relay-based systems. These processes are included in TR 33.847.

For example, the solution No. 28 in TR23.752 describes a mechanism for a remote UE to discover a third tier UE-to-network relay and establish a PC5 unicast connection with the UE-to-network relay. This mechanism does not require interaction with the core network during operation.

For example, the 32 # solution in TR33.847 describes a mechanism for a remote UE to protect its PDU parameters from UE-to-network relay so that only authorized relays can access them. This solution requires interaction with the core network.

An advantage of the current solution discussed in solution number 28 in TR23.752 is that it does not require interaction with the CN during discovery. However, it also creates problems, for example, with ki#16 in TR 33.847. How to avoid the pre-configuration of slice information has not been solved (problem 1). Moreover, this solution requires that the PDU session parameters be transmitted in plain text (problem 2). A possible solution to these problems in TR33.847 is solution number 32. However, this solution requires communication through the core network during operation (problem 3) in order to achieve privacy protection of the PDU parameters.

Disclosure of Invention

It is an object of the present invention to alleviate the above mentioned problems.

Another object of the invention is to propose a method for communication in a network which allows security settings for the establishment of a Protocol Data Unit (PDU) session for a secondary station.

It is a further object of the invention to propose a secondary station method for communication in a network, which method in operation requires minimal interaction with the core network.

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

Thus, according to the first aspect of the invention, at an early stage, e.g. in an initial connection to a cell, the secondary and relay stations get the required security elements from the core network, e.g. the signature public key bound to the receiving UE. At a later stage, e.g., during network operation, the secondary station can establish a secure exchange and authentication with the relay station to begin a PDU session.

In the exemplary embodiments described below, the configuration parameters included in the first message and the second message can 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:

● Accessing a set of roles;

● A collection of attributes;

● Communication parameters, e.g., transmission mode, restrictions on certain resource sets;

● Special identifiers, e.g., application ID, group ID, UE;

● Defining a strategy of access authority;

● Policies for the types of communications that can be relayed are defined.

According to a second aspect of the present invention, a method for operating a relay station according to claim 18 is presented.

According to a third aspect of the invention, a method for operating a secondary station according to claim 19 is presented.

According to a fourth aspect of the invention linked to the second aspect of the invention, a relay station according to claim 20 is presented.

According to a fifth aspect of the invention linked to the third aspect of the invention, a secondary station according to claim 21 is presented.

According to a sixth aspect of the present invention, there is provided a computer program product comprising code means for producing the steps of the method according to the first, second or third aspects of the present invention when run on a computer device.

Thus, according to a first aspect of the present invention, there is provided a method for operating a communication system comprising a primary station, a relay station and a secondary station, the primary station being linked to a core network, the primary station serving a cell, the relay station being served by the primary station, the secondary station being served by the primary station, the method comprising the steps of:

The relay station establishing a connection with the primary station, comprising receiving a first set of configuration parameters comprising a service code in at least one first safety message from the primary station,

the secondary station establishing a connection with the primary station comprising receiving a second set of configuration parameters in at least one second secure message from the primary station, the second set of configuration parameters comprising a relay service code linked with an upcoming data session,

the relay station transmits at least one transmission service code from the first set,

the secondary station establishes direct communication with the relay station upon determining that the transmission service code is included in the second set.

According to a second aspect of the present invention there is provided a method for operating a relay station adapted to communicate in a network, the network comprising a primary station and a secondary station, the primary station being linked to a core network, the primary station serving a cell and the secondary station being served by the primary station, wherein the relay station is served by the primary station, the method comprising the steps of:

the relay station establishing a connection with the primary station, comprising receiving a first set of configuration parameters in at least one first security message from the primary station, the first set of configuration parameters comprising a set of a plurality of attributes or service codes,

The relay station transmits at least one attribute from the second set of configuration parameters or a transmission service code from the second set of configuration parameters,

the relay station establishes direct communication with the secondary station according to a request from the secondary station, the request being based on a transfer service message.

According to a third aspect of the present invention there is provided a method for operating a secondary station adapted to communicate in a communication system comprising a primary station and a relay station, the primary station being linked to a core network, the primary station serving a cell and the relay station being served by the primary station, wherein the secondary station is served by the primary station, the method comprising the steps of:

the secondary station establishing a connection with the primary station comprising receiving an encrypted public key in at least one second secure message from the primary station, and a second set of attributes or relay service codes linked to an upcoming data exchange with at least one relay station,

the secondary station receives at least one transmission attribute or relay service code from the relay station,

the secondary station determines whether the transmission attribute or service code is included in a second set of configuration parameters and establishes direct communication with the relay station upon determining that the transmission attribute or service code is included in the second set of configuration parameters or that its policy is satisfied.

According to a fourth aspect of the present invention there is provided a relay station adapted to communicate in a network comprising a primary station and a secondary station, the primary station being linked to a core network, the primary station serving a cell and the secondary station being served by the primary station, wherein the relay station is served by the primary station, the relay station comprising:

the conveyor is provided with a conveyor belt,

the number of the channels of the receiver is determined,

a controller adapted to establish a connection with the master station,

comprising configuring said receiver to receive a first set of configuration parameters in at least one first security message from said primary station, said first set of configuration parameters comprising an attribute or service code,

the transmitter is configured to transmit at least one transmission attribute or service code from the first set of configuration parameters,

wherein the controller is configured to establish direct communication with the secondary station using a public key in accordance with a request from the secondary station, the request being based on a transfer service message.

According to a fifth aspect of the present invention there is provided a secondary station adapted to communicate in a communication system comprising a primary station and a relay station, the primary station being linked to a core network, the primary station serving a cell and the relay station being served by the primary station, wherein the secondary station is served by the primary station, the secondary station comprising:

The conveyor is provided with a conveyor belt,

the number of the channels of the receiver is determined,

a controller adapted to establish a connection with the primary station, comprising configuring the receiver to receive a second set of configuration parameters in at least one second security message from the primary station, the second set of configuration parameters comprising an attribute or relay service code linked to an upcoming data exchange with at least one relay station,

the receiver is adapted to receive at least one transmission attribute or service code from the relay station,

wherein the controller is configured to: determining whether the transmission attribute or service code is included in the second set of configuration parameters or satisfies a policy thereof, and causing the transmitter to establish direct communication with the relay station upon determining that the transmission service code is included in the second set.

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

Similarly, according to a second option which can 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 encryption public key and a corresponding secondary station encryption private key.

In a third option, which can be combined with the second option and/or the third option, the at least one first secure message comprises at least one first core network signature from the core network generated at least on:

the relay encryption public key, and

at least one of an attribute of said first set of configuration parameters or said service code of said first set of configuration parameters,

and the at least one second secure message includes at least one second core network signature from the core network generated on at least:

the secondary station encrypts a public key, and

at least one of an attribute of the second set of configuration parameters or the service code of the second set of configuration parameters.

Alternatively, a fourth option, combinable with the second option and/or the third option, the at least one first secure message comprising at least one first core network signature from the core network generated at least on:

the relay encryption public key, and

parameters relating to an upcoming data session, said parameters being included in said second secure message,

the secondary station encrypts a public key, and

In a fifth option of the invention that is combinable with the third option or the fourth option, the step of establishing direct communication includes:

a. the secondary station sends a direct communication request to the relay station,

b. the relay station responds to the direct communication request with a response message comprising the relay encryption public key, the first core network signature and a response message signature,

c. the secondary station checks the first core network signature included in the response message and the response message signature.

With respect to a fifth option that can be combined with the fourth option, the direct communication request includes a secondary station random number (nonce), and wherein the response message signature is generated by applying the relay encryption private key on at least the secondary station random number.

In addition, in a sixth option that can be combined with the fifth option, the response message signature is generated by applying the relay encryption private key to at least the secondary station random number and at least one of the core network first signature and the relay encryption public key.

In a seventh option in combination with the fourth, fifth or sixth option, the response message further comprises a relay random number, and wherein the secondary station transmits communication parameters in a configuration message comprising a configuration message signature generated by applying the secondary station encryption private key on at least the relay random number.

In an eighth option in combination with the seventh option, the configuration message signature is generated by applying the secondary station encryption private key on at least the relay random number and at least one of the core network second signature, the secondary station encryption public key.

In a ninth option which can be combined with the first to fifth aspects of the invention, wherein the step of establishing direct communication comprises:

a. the secondary station generates or selects a secondary station encryption public key, a secondary station encryption private key and a secondary station random number, sends a direct communication request to the relay station,

b. The relay station responds to the direct communication request by a response message comprising a relay encryption public key and/or a first core network signature and/or a response message signature, wherein the response message is encrypted using the public key received in step a,

c. the secondary station decrypts the response message and checks the first core network signature included in the response message and the response message signature.

In a tenth option, which can be combined with any of the aspects and options of the invention, the relay station transmits at least one transmission 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 following further information: a data session policy, data session parameters, the first core network signature, a relay encryption public key, and wherein the secondary station establishes direct communication with the relay station when determining that the transfer attribute or the transfer service code of the first set of configuration parameters is included in the second set of configuration parameters and the further information is compatible with the upcoming data session.

In an eleventh option in combination with the tenth option, the message transmitted from the relay station includes a signature applied at least on a time stamp.

In a twelfth option of the invention, which may be combined with any of the aspects and options of the invention, the at least one transmit service code from the first set of configuration parameters is a result of a combination of a hash service code of the first set and a transmit random number, and the relay station also transmits the transmit random number.

In a thirteenth option of the invention that is combinable with the fifth to tenth options, the method further comprises: the secondary station informs the core network if the checking of the first core network signature fails.

In a fourteenth option in combination with the first to fifth aspects of the invention, the relay station establishing a connection with the master station comprises: the relay station generates a relay encrypted public key and a relay encrypted private key, sends the relay encrypted public key to the primary station for signing by the core network, and receives the first set of service codes and a first core network signature based at least on the relay encrypted public key in the at least one first secure message from the primary station.

In a fifteenth option of the invention in combination with the first to fifth aspects of the invention or with the fourteenth option, the secondary station establishing a connection with the primary station comprises: the secondary station generates a secondary station encrypted public key and a secondary station encrypted private key, sends the secondary encrypted public key to the primary station for signing by the core network, and receives the second set of service codes in the at least one second secure message from the primary station and a second core network signature based at least on the secondary station encrypted public key.

Note that the above-described apparatus may be implemented based on an arrangement of discrete hardware circuits, integrated chips or chip modules with discrete hardware components, or based on a signal processing device or chip controlled by a software routine or program stored in memory, written on a computer readable medium or downloaded from a network such as the internet.

It will be appreciated that the wireless device, system, relay station, cell station and method may have similar, corresponding and/or identical preferred embodiments, in particular as defined in the dependent claims.

It is to be understood that the preferred embodiments of the invention can also be any combination of the dependent claims or the above embodiments with the corresponding independent claims. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

Drawings

Fig. 1, which has been described, schematically shows a cellular system embodying the invention.

Fig. 2, which has been described, schematically shows different possible modes of operation in the network of fig. 1;

fig. 3 is a timing diagram of communication of a protocol according to a first embodiment of the invention;

FIG. 4 is a timing diagram of communication of a protocol according to a second embodiment of the invention;

fig. 5 is a timing diagram of communication of a protocol according to a third embodiment of the invention;

fig. 6 is a timing diagram of communication of a protocol according to a first embodiment of the invention;

FIG. 7 is a timing diagram relative to an improvement realized as a result of an embodiment of the present invention;

FIG. 8 is a timing diagram relative to one improvement realized as a result of an embodiment of the present invention;

FIG. 9 is a timing diagram of communication of a protocol according to another embodiment of the invention; and is also provided with

Fig. 10 is a block diagram illustrating a secondary station and a relay station according to an embodiment of the present invention.

Detailed Description

In the following description, solutions to problems 1, 2 and 3 are described in various embodiments. These solutions involve in a first embodiment the distribution of information signed by the CN to each UE, in particular a public key bound to each UE (secondary station (also called remote UE) and relay station (also called relay UE)). This information distribution phase occurs during the initial provisioning and authorization steps, i.e. at an early stage of the connection. The UE can be a remote UE or a relay UE. In operation, the UE under consideration may have to operate alternately as a relay UE and a remote UE. In this first embodiment, the signature information including the public key allows:

● The remote UE checks whether the relay UE is authorized to act as a relay without accessing the CN during operation.

● If authorized, the relay UE validates PDU parameters of the remote UE without accessing the CN during operation.

● The remote UE and the relay UE establish a secure PC5 link without having to access the CN during operation.

The main benefit of the first embodiment of the invention compared to existing security solutions (solution number 28 in TR23.752 and solution number 32 in TR 33.847) is that it does not require access to the core network during operation when it is operated in a secure manner. This means:

● The effort on the core network is low and,

● The delay in the establishment of the communication link is reduced, since once the CN is operational, no further checking of the CN is required,

● The relay UE may be out of coverage and,

● The remote UE may be out of coverage and,

● The privacy-related parameters are not disclosed.

Thus, this first embodiment provides a solution applicable to the 28 th solution in TR23.752 to solve the privacy problem around problems 1 and 2.

Furthermore, while this first embodiment is described in the context of the KI #16 in TR33.847 in the context of PDU parameter protection, the same techniques and other embodiments constructed on their basis can be used to address other issues, such as those described in the following table. The detailed description includes a number of embodiments that provide solutions to these problems. In particular, it improves on the solutions No. 8 and No. 31 in TR 33.847. These two solutions are the only solutions in TR33.847 that use public key encryption. Solution 8 and solution 31 solve for ki#6 and ki#7, respectively.

It should be noted that the first embodiment of the invention is applicable to protecting confidentiality of other parameters. For example, the application function address in solution 21 in TR 33.847.

It should be noted that this solution can also be used independently for security establishment in PC5 as an alternative solution to the solutions No. 1, 6, 10 and 15 in TR 33.847.

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 specification, the CN is typically able to sign the information. This can be achieved by means of the digital signature network function (DSnF) proposed in solution No. 20 in TR 33.809. Alternatively, the application function may also be responsible for signing the required information, for example. In addition, the remote UE is configured with a trust anchor that allows verification of the information when the CN signs the information. These trust anchors can be the same as in the DSnF solution. In a variation of this first embodiment, these trust anchors may also be delivered to the UE in the initial provisioning phase (steps 1.A and 1.B below).

The first embodiment corresponds to ProSe operation according to "discovery model a". In practice, limited ProSe direct discovery is a process in which a UE uses its radio access direct radio signal to detect and identify another UE in the vicinity under explicit permission of the UE being discovered. According to discovery model a ("i am here"), two roles for ProSe-enabled UEs are involved in this model: advertising the UE and monitoring the UE. The advertising UE broadcasts discovery messages at predefined discovery intervals and monitoring UEs interested in these messages read and process these messages. Alternatively, in model B ("who is there": a discoverer UE and a discoveree UE. This amounts to "who is there/you are there" because the discoverer UE sends information about other UEs from which it wants to receive responses, e.g. the information can be about ProSe application identities corresponding to the group, and the members of the group can respond.

According to a first embodiment, as shown in figure 3,

at step a: during initial provisioning, the CN distributes to the relay UE a set of configuration parameters, e.g., relay Service Codes (RSCs) it supports. The configuration parameters can include other capabilities provided by the relay UE, for example, which applications it supports. Such distribution can be accomplished without disclosing to the relay UE the specific privacy-sensitive parameters linked to each set of configuration parameters (e.g., RSCs). The CN may also create a relay public key pair for use by the relay UE. The CN can also distribute other information, such as policies stating which type of remote UE or connection to allow relaying for which type of remote UE to serve. The CN can sign (or other security processes such as message encryption) the supported configuration parameters and relay public key. The CN may provide the signed configuration parameters and the relay public key and the corresponding relay private key to the relay UE. This can be done within a single message as shown in fig. 3, or in a separate message in a variation of this embodiment. The core network public key may also be shared at this time in case the CN signs. Other encryption procedures include, for example, encrypting the entire first message, for example, in case the encryption key has been exchanged or is known to the relay UE.

At step b, during initial provisioning, the CN provides the remote UE with a set of configuration parameters (e.g., RSCs) linked with specific PDU session parameters. The CN also creates a secondary station public key pair. The CN may sign the configuration parameters, the corresponding PDU parameters. It can include other elements in the signature, for example, the secondary station public key. The CN may send the signed secondary station public key, RSC, PDU parameters, and secondary station private key. The core network public key may also be shared at this time in case the CN signs. The CN can also distribute other information, such as policies stating which types of relay UEs are allowed to service their communication needs. Other encryption procedures include, for example, encrypting the entire second message, for example, in case the encryption key has been exchanged or is known to the relay UE. Moreover, such distribution can be performed on a single message as shown in fig. 3, as well as on multiple messages.

At step c, in the example of discovery model a, the relay UE broadcasts some supported configuration parameters, e.g., RSCs of configuration parameters during relay UE discovery. Note that in case of discovery model B, the remote UE (secondary station) will broadcast some message to indicate its presence. In fact, in discovery model B, it is the remote UE that sends the discovery message, not the relay UE. To apply the first embodiment to this alternative scenario, the remote UE is the UE that sends the discovery message including its supported configuration parameters (e.g., its RSC).

At step d, the remote UE, upon receiving the data (e.g., by matching RSCs), checks whether the relay UE supports its PDU communication requirements.

At step e, it is first determined if there is an RSC match, and then the remote UE can decide to establish a PC5 connection, for example as follows:

i. the remote UE generates a random number (n_remote) and sends it to the relay UE. Optionally, it can also include a specific RSC that it is interested in, so that the relay UE knows it.

Relay UE transmission:

1. its public key (PuK _ relay) and configuration parameters (e.g., RSC),

2. the CN signature on the configuration parameters (e.g., RSC) and the public key received from the CN, i.e., S (prk_cn, rscs|puk_relay),

3. the received remote N _ remote (optionally sent, but required in the signature calculation),

4. relay random number (n_relay).

Some or all of these items can be signed with the private key of the relay (PrK _ relay).

In fig. 3, S (PrK, M) means a signature of the message M using the private key PrK.

In this description, "|" corresponds to a cascading operation.

The remote UE can then (i) verify the CN signature, and (ii) verify the relay signature that includes (iii) the remote nonce. Thus, the remote UE can check that the relay UE has first been authenticated by the core network without having to contact the CN during operation. This therefore reduces the burden on the core network that would otherwise be required to authenticate each device-to-device connection.

if step iii) is successful, the remote UE can send:

1. its communication parameters, in particular its PDU session parameters linked to RSC and public key PuK _ remote,

2. for the corresponding communication parameters and the corresponding CN signature of the public key,

3. the random number received from the relay UE, i.e., n_relay (optional).

4. All the above information elements (communication parameters, corresponding CN signature, random number (n_relay) (optional)) can be signed with the secondary station private key (prk_remote), the public key of which is signed by the CN.

The entire message can then be encrypted with the public key of the relay node puk_relay so that these parameters and information are not sent over the air in the clear. As can be seen in fig. 3, E (PuK, M) represents encrypting the message M using the public key PuK.

The relay UE decrypts the received information and checks the CN signature of the remote UE and the signature of the remote UE. If the verification is correct and N_relay exists, the relay UE will serve the remote UE's need for the disclosed PDU parameters.

Thus, as previously described, neither the relay UE nor the remote UE need to communicate with the core network for authentication/authorization purposes during the connection to the relay UE. All authentication is pre-implemented, thus resulting in a smooth and secure connection protocol without assistance from the CN during operation. Thus, the UE can be securely connected to the PDU session even if out of coverage.

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

In a variation of the first embodiment, relay UEs may not be tracked. To this end, the remote UE may generate a ephemeral public key pair and send it to the relay UE in step e.i. Because this public key pair is ephemeral, it cannot be used to track remote UEs. The relay UE uses it in step e.ii to encrypt the message so that the relay parameters remain confidential to external (passive) aggressors. Thus, the step of establishing direct communication can include the secondary station generating its own encrypted public and private keys. Along with the secondary station nonce, the remote UE is able to send a direct communication request to the relay station. Similar to the first embodiment, the first message can optionally be secure.

In response to the direct communication request, the relay station transmits a response message comprising a relay encryption public key and/or a first core network signature and/or a response message signature, wherein the message is protected (confidentiality) using the public key received with the direct communication request.

The secondary station can then decrypt the received message and check the first core network signature included in the response message as well as the response message signature.

It should be noted that the above protocol is able to exchange RSCs in step c, since the discovery messages are small. Another variation of the first embodiment, which reduces the number of round trips, is that the relay UE broadcasts its configuration parameters (or part thereof), policy, public key and signature at this point in time (step c). If so, the remote UE is already able to check in step d whether the relay UE policy supports its PDU communication requirements. If so, it will check 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 the solution No. 28, in addition the UE shares its signed PDU session requirement encrypted with the public key of the relay UE. Finally, in step f, the relay UE can decrypt the remote UE data and verify its signature. If the verification is correct and its policy allows these parameters, the relay UE will serve the needs of the remote UE.

Here and anywhere in this document, verifying the signature may include checking the signature itself, as well as other fields, such as expiration date, issuer, etc. Note that this may also include retrieving or accessing a revocation list that includes revoked public keys.

In addition to this previous variation, the following operations can be performed to (further) mitigate replay attacks: in step 1c, the relay UE can sign at a timestamp using its private key, e.g. the current UTC time and optionally the remaining broadcast information. This signature can also be included in step 1 c. In step 1d, the remote UE verifies the received signature at UTC time and checks if this time is the most recent. This therefore avoids the risk of an attacker storing and replaying past messages.

In addition to the above variants, the following operations can be performed to (further) mitigate MitM attacks. The relay UE can sign its current location using its private key, e.g., GPS coordinates, building name, etc. This information can be included in step 1 c. In step 1d, the remote UE verifies the received signature and checks if the location matches its own location. This avoids the risk of an attacker compromising the relay device at a particular location and reusing its broadcast messages at multiple locations. This feature can be used independently and individually.

Since the broadcasting of static RSCs can be considered privacy-risky, another variant of the first embodiment consists in the sender generating a random number N and deriving a pseudo RSC as prsc=hash (rsc|n), where HASH is a HASH function taking as input a concatenation of RSC and N. The sender then broadcasts (pRSC, N) (step c). The receiver must apply a hash function to each RSC it owns and check if there is a match. In order for this method to work safely and collision-free, pRSC, RSC and N should be long enough. If the value in the discovery message can only be small (step c), the subsequent message may include another pair (pRSC ', N') using longer parameters.

In the first embodiment and all variants discussed above, the remote UE will terminate the connection if step e.iii fails. The remote UE can then notify the CN of the failed verification and relay UE parameters at the next connection. Similarly, if step e.v fails, the relay UE denies delivery of the service. The relay UE can inform the CN of the failed authentication and remote UE parameters. Thus, in case security risks are found, the core network is informed quickly and can check the relevant stations.

In a further variant of the first embodiment, the remote UE may receive the public key (or fingerprint) of the relay UE that has been allowed in step 1.B instead of in step e.ii.1, e.g. from the core network.

As explained in the first embodiment, in step 1.D, the remote UE checks whether the relay UE supports its PDU requirements by checking whether the RSCs match. This is a one-to-one relationship and is similar to a "role-based access control" method that employs predefined roles to perform specific actions. In other words, if the relay UE has rsc=x, the relay UE is authorized.

This signed RSC can be regarded as an "authorization token". The proposed operation can then be considered, wherein RSCs (no signed "authorization tokens") are allocated in step 1.C to perform a first check of the bandwidth requirements of the adaptation discovery message. If a match is detected in the previous step, a complete "authorization token" can be distributed in step e.ii. This simple separate operation can be integrated into solution 31 of TR 33.847.

We note that more complex "policies" can be defined in the context of "attribute-based access control". Instead of having only RSC, we can consider more attributes about the device type of the relay UE (e.g., is it a private device. The recipient (e.g., remote) can have a policy, e.g., XACML access control policy, that can be used to check whether the sender (e.g., relay) is authorized. The policy can be distributed during provisioning along with other configuration parameters including any device attributes (e.g., RSC).

If the solution requires other information or a set of configuration parameters (which can be considered roles or attributes) during discovery (e.g., solution 11 or solution 8 in TR 23.752), this information can also be signed and distributed by the CN during initial provisioning. The CN can also distribute policies during provisioning regarding which requirements the other party should meet to be allowed to act as a relay, remote or peer. The information sent in steps e.ii and e.iv may include all or part of the information sent during discovery (including the corresponding CN signature) so that upon reception the data can be validated and cross checked against the policies also received during provisioning.

In steps 1.A and 1.B, the CN generates a key pair for the remote UE and the relay UE. Alternatively, the key pair can be generated by the UE and the public key can be sent to the CN for signing. This has the advantage that the CN is unaware of the private key.

In steps 1.A and 1.B, the CN signs the information set for the remote UE and the relay UE. The CN is also able to sign multiple sets of information so that the UE can rotate them, i.e. change periodically for privacy reasons.

In steps 1.A and 1.B, the CN signs the public key for the remote UE and the relay UE. These public keys are associated with corresponding private keys. In a further variant, the key pair can sometimes be used for public key encryption and sometimes for digital signing. In general, it is feasible to re-use the same key pair (in a secure manner) for signing and encryption. However, this is not recommended because the information may be compromised, for example, when encryption may be used to break the signature. Thus, steps 1.A and 1.B may also include delivering multiple (e.g., 2) signed public keys so that each of them can be used for different purposes, e.g., encryption and signing.

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), the remote UE must send all RSC and PDU parameters, since otherwise the relay UE cannot verify the message. This is again 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 (k=0, …, n-1) take as input the kth RSC and corresponding PDU parameters, respectively. The CN signs the root of the Merkle tree. When the remote UE has to disclose PDU parameters for its kth RSC, the remote UE only discloses the leaves 2k and 2k+1, the corresponding intermediate node in the Merkle tree that allows to calculate the root of the Merkle tree, and the CN signature on the Merkle tree root.

The same applies to RSCs in repeaters. In this case, the RSCs may correspond to leaves of Merkle trees. When relaying the specific RSC disclosed in message e.ii in fig. 3, it has to disclose the RSC, the path of the recalculation root in the Merkle tree and the signature provided by the CN on the root of the Merkle tree.

Given the above information, the receiver must use the path of the Merkle tree, the RSC (and PDU parameters) to check if the information allows the root of the Merkle tree to be recalculated, and then check the signature.

In all variations, a suitable signature algorithm can be an Elliptic Curve (EC) Digital Signature Algorithm (DSA).

The information provided in the initial providing step may include a different signature for each piece of information (e.g., for each RSC, each public key, each PDU parameter). This has the advantage that different information can be disclosed independently of each other.

In the above description, public key encryption is used. This can be replaced by identity-based encryption (IBE). At IBE, the identity of the UE corresponds to its public key. Given the identity of the UE, the CN uses the master secret to derive a corresponding private key for the UE. An advantage of IBE is that no exchange of public keys is required. Another advantage is that the public key itself acts as a "certificate" and only the "authorized" party will receive or be able to decrypt privacy-sensitive content. For example, suppose a relay with an identity of "rsc=x, expiration_date=2022/02/22". This is information that the relay can broadcast and the remote UE can receive. If rsc=x and expiration_date are appropriate for the remote UE according to the policies received by the remote UE from the CN during provisioning, the remote UE can use the identity of the relay UE "rsc=x, expiration_date=2022/02/22" as its public key. This means that the remote UE will encrypt any privacy sensitive parameters (e.g., PDU parameters) using the public key and send the encrypted information. Only relays that possess the corresponding private key (issued by the core network) can decrypt the information.

In the above description, the UE has a private key that can be used to prove its identity. However, digital signatures may be too bulky for some implementations, and verification thereof may require a considerable computational time. This is particularly relevant for discovery messages whose size may be limited (e.g., limited to a few hundred bits). An alternative solution to this is that the CN configures the advertising UE (e.g., relay device) and the monitoring UE (e.g., remote UE) with the seed and anchor of the hash chain so that the hash chain link can be used to prove that some broadcast messages are coming from the advertising UE. Such a solution is relevant, for example, to discovery messages sent by advertising UEs. The discovery message corresponds to message c in fig. 3. The key number 1 problem in TR33.847 outlines the security requirements in protecting these discovery messages.

This solution focuses on key number 1 problem (discovery message protection). This solution suggests reusing the open discovery security mechanism specified in TS33.303 for 5G ProSe open discovery, as was done by solution No. 3 in TR33.847, but enhanced as:

● Improving resistance to message modification and replay attacks

● Ensuring source authenticity

● The need for the core network to have to verify the integrity of the advertisement message is eliminated.

The proposed enhancement is due to the integrity protection requirement of discovery messages over the PC5 interface in TS33.303 to discover the user integrity key (DUIK). The key is used to calculate a Message Integrity Code (MIC). The MIC can be verified upon receiving the UE if the UE has been provided with DUIK or when ProSe functions of DUIK are used. In the first case, if DUIK is provided to the monitoring UE, the monitoring UE can verify the MIC itself. However, if multiple monitoring UEs receive the same DUIK, it is not feasible to guarantee integrity protection, replay protection, or source authenticity, as any of these UEs may be malicious. This can increase the burden on the CN and the overall communication delay if the ProSe function has to check the MIC.

The basic idea of this solution is to supplement source authentication with Discovery User Integrity Hash Chain (DUIHC) for use of DUIK. In the following the description of the preferred embodiments,

H ^j (input) represents TRUNC _b (hash (identifier |j|H) ^j-1 (input))

H ¹ (input) =trunk _b (hash (identifier |1| input)).

Wherein, the liquid crystal display device comprises a liquid crystal display device,

● "|" indicates a cascade of stages,

● Hashing (input) refers to computing a hash function over a given input,

● The "identifier" includes fixedly provided policies/parameters related to advertising the identity of the UE, e.g. its L2 identifier, the PLMN advertised by the UE, radio parameters when the UE is "not served by NG-RAN", etc.

●TRUNC _b (A) Is a function of the b bits of the return input a (e.g., the b least significant bits of a).

In pair H ^j The inclusion of "j" and/or "identifier" in the (input) computation is optional, but makes the solution more resilient to pre-computation attacks. Using TRUNC _b (A) Aiming to reduce the communication overhead.

Thereby, DUIHC is obtained from the randomly generated seed S as follows:

S→H ¹ (S)→H ² (S)→H ³ (S)→…→H ^N-2 (S)→H ^N-1 (S)→H ^N (S)

here, an arrow "→" indicates a link H that generates a hash chain ¹ (S)、H ² (S), …. Last element, H ^N (S) is the anchor for this DUIHC.

The advertising UE (e.g., relay UE) is given its seed S of DUIHC. All monitoring UEs are given anchors advertising the UE's DUIHC. These steps can be completed during device authorization and initial provisioning corresponding to steps a and b in fig. 3. When the UE is given these parameters, the UE is also given a reference time t0 (the time that the UE should be informed of the hash chain link to use) and a slot duration tDelta.

When the advertising UE wants to send an advertising message m at UTC time t, the advertising UE may first calculate the current slot j as (t-t 0)/tDelta, which means that the advertising UE has to use the DUIHC link H ^N-j (S). Note that this requires N-j>0. Advertising UE usage H ^N-j (S) and DUIK to calculate together a final key for use in creating the MIC for message m. This key is denoted as discovery user integrity key and hash chain link (DUIKHCHL), and is calculated as:

DUIKHCL＝Hash(DUIK|H ^N-j (S))

the reason for including DUIK in the derivation of DUIKHCL is to provideInteroperability with existing TS33.303 solutions. This also ensures that the solution is as safe as existing solutions. We note that an alternative is to use only H in the calculation of MIC ^N-j (S) or a key dependent thereon.

Representing the MIC of message m as MIC _m And calculated as follows:

MIC _m ＝MIC(m，DUKHCL)

the advertising UE may also include the previous DUIHC link, i.e., H, in the broadcasted advertising message ^N-j+1 (S)：

m，H ^N-j+1 (S)，MIC _m

When the monitoring UE receives the above-mentioned announcement message at time t, the monitoring UE first calculates slot j by taking as input the reference time t0 and slot duration tDelta. The monitoring device then buffers the received message until the next slot j+1 to receive H in the next notification message ^N-j (S). By H ^N-j The monitoring UE can check:

a) The validity of the MIC received in the previous message, and thus the integrity of the message itself. This is done by re-computing DUIKHCL and checking the MIC received _m Whether or not to match the calculated MIC.

b) By checking received H ^N-j Whether the value of (S) is correct or not determines the freshness and source authenticity of the message. To this end, the monitoring UE uses the received anchor as input.

The resulting message flow is similar to solution number 3 in TR33.847 and the open discovery security mechanism specified in TS 33.303. Referring to fig. 6.3.2-1, the following key differences occur with DUIHC beside DUIK.

● Step 4 (discovery response) also includes the seed S of DUIHC, reference time t0 and slot duration.

● Step 5 (start announcement) is modified to use the links in the DUIHC when calculating the broadcast MIC as described above.

● Step 9 (discovery response) includes the anchor of DUIHC, reference time t0 and slot duration.

● Step 10 (receiving the announcement code) is modified to verify the integrity, freshness and source authenticity of the received broadcast message as described above using the anchor of the DUIHC received in step 9.

Steps 11-15 are not required.

In addition:

● If the monitoring UE detects a discovery message with an erroneous MIC or DUIHC link, the monitoring UE can notify the HPLMN or M-UE DDNMF of the event.

● If the advertised UE is revoked, the HPLMN or M-U DDNMF should inform the monitoring UE that it has indicated that it is interested in being able to discover the advertised UE.

● The DUIHC anchor received by the monitoring UE in step 9 corresponds to the latest link or the most recently disclosed link advertising the UE DUIHC.

The basic idea described above can be similarly applied to the limited discovery mode a.

The basic idea described above can also be applied to the restricted discovery mode B. This may require that both the discoveree UE and the discoveree UE be able to be owners of the DUIHC to prove their identities based on policies. Possession of the DUIHC is particularly relevant for the discoveree UE if multiple discoverer UEs are able to discover the same discoveree UE and verification of the response (response code) from the discoveree UE is done locally by the discoveree UE.

The following is an alternative method for improving the security assurance of discovery messages that can be used with or without the DUICH method described above. In mode B, see TS33.303, the discoverer UE is required to send a query code to the discoveree UE. The discoveree UE must check its integrity/freshness/origin authenticity and if the verification is successful, the discoveree UE replies to the discoveree UE with a response code. The discoverer UE must be able to check the integrity/freshness/source authenticity of the message. In TS33.303, the discoveree UE DUIK-based authentication can only be performed locally; however, the discoverer UE DUIK-based authentication can occur locally or remotely in the core network based on the match report. This can cause the following: for example, if multiple discoverer UEs are able to discover the same discoveree UE, one of the discoverer UEs may behave improperly and impersonate the discoveree UE. This situation can be improved by having two DUIKs, one from the discoverer UE to the discoveree UE and the other DUIK from the discoveree UE to the discoveree UE. This ensures that if multiple discoverers UE can discover the same discoveree UE, and if the MIC of the response code is verified by means of a match report, none of the discoverers UE can impersonate the response code generated by the discoveree UE. Further details and clarification about this second point are as follows:

The key number 1 problem in TR33.847 indicates that limited discovery takes integrity protection, freshness and source authenticity as potential security requirements. The key number 1 problem also indicates that an attacker may pose a potential threat to the discovered party or the discovered UE.

Solution o 4 reuses the LTE solution in TS 33.303. In mode B, a user integrity key (DUIK) is found to protect the query code and the response code. The discoverer UE sends a query code to the discoveree UE. The discoveree UE replies to the discoveree UE with a response code. The discoveree UE cannot verify the MIC of the received query code with the match report. The discoverer UE can verify the MIC of the received response code with the match report.

This solution provides that the code transmission security parameters of the discoverer UE are linked with the code reception security parameters of the discoveree UE. We call this set of security parameters the query code security parameters.

This solution provides that the code transmission security parameters of the discoveree UE are linked with the code reception security parameters of the discoveree UE. We call this set of security parameters the response code security parameters.

Since the solution does not specify anywhere that the security key in the challenge code security parameters must be different from the security key in the response code security parameters, potential security problems may occur. In practice, steps 4 and 11 in fig. 6.4.2.2-1 indicate that the two sets of security parameters are identical.

If this is not explicitly specified as a requirement, a simple error may occur. For example, assume that identical DUIK is configured in the query code security parameter and the response code security parameter. In this case, the discoverer UE can impersonate the discoveree UE. This can be done even if the discoverer UE has to verify the MIC of the received response code with a match report.

This problem can be solved by requiring that the security key in the code transmission security parameter of the discoverer UE (e.g., DUIK) must not be equal to the security key in the code transmission security parameter of the discoveree UE (in other words, two DUIK, DUIKre (from discoverer UE to discoveree UE) are different from DUIKer (from discoveree UE to discoveree UE)).

The way this is suitably described in TR33.847 and TS33.303 is as follows:

● The code transmission security parameter of the discoverer UE and the code reception security parameter of the discoveree UE should be referred to as query code security parameters.

● The code transmission security parameter of the discoverer UE and the code reception security parameter of the discoveree UE should be referred to as response code security parameters.

● It should be specified that the query code security parameters must be different from the response code security parameters.

Tdoc S3-212464, submitted to 3gpp sa3#104e, describes a key handling procedure for group member and relay discovery. In particular, the Tdoc describes how the UE obtains the necessary security parameters in and out of coverage to support group membership and relay discovery, e.g., for public safety scenarios. The following are described in Tdoc S3-212464: "group member discovery is a restricted discovery and is expected to be supported both in-coverage and out-of-coverage. Group member discovery uses provided keys to support the integrity, confidentiality, and untraceability of discovery messages. The discovery root key is used to secure over-the-air discovery and communications from which other keys can be derived. The root key can be provided by 5G DDNMF and/or 5G PKMF. "Tdoc S3-212464 also proposes a TS33.303[2] based solution as follows: "provides the same solution for two public safety discovery scenarios-group member discovery and relay discovery: a Public Safety Discovery Key (PSDK) is provided as a root key for protecting public safety discovery messages and is associated with one or more discovery group IDs or corresponding Relay Service Codes (RSCs). Both identifiers are defined in TS23.303[5 ]. The step of discovering group members includes: "step 0: the UE connects to the network and obtains authorization from the PCF to perform group member discovery. The UE also gets the address of its HPLMN's 5G DDNMF and/or 5G PKMF. In addition to the security policy, the following additional parameters are sent to the UE: one or more application group IDs, (ProSe) second group IDs, user information, discovery group IDs, and set of validity time(s). Step 1: the UE establishes a secure connection with its HPLMN 5G DDNMF or 5G PKMF. The UE ID is authenticated and authorized by either 5G DDNMF or 5G PKMF. Step 2: the UE sends a discovery key request to its HPLMN 5G DDNMF or 5G PKMF. The key request includes at least the following information: UE ID, a set of one or more discovery group IDs, and their validity times. Step 3: the 5G DDNMF or 5G PKMF checks whether the UE is authorized for group member discovery. Step 4: if the check in step 3 is successful, the 5G DDNMF or 5G PKMF generates a Public Safety Discovery Key (PSDK) corresponding to the discovery group ID and its PLMN ID. More than one PSDK may be generated, but the total validity time should match the validity time of the corresponding set of discovery group IDs of step 2. Step 5: the 5G DDNMF or 5G PKMF sends a key response to the UE. The key response message includes at least the following information: UE ID, PDSK identifier, PDSK, validity time. For relay discovery, the procedure/step of relay discovery is substantially the same as the procedure/step of group discovery described above, but with the following differences: (i) the UE is now a remote UE or a UE-to-network relay; (ii) Discovering the group ID using the relay service code instead of the parameter; (iii) Using the destination second layer ID instead of the second layer group ID; and (iv) no application layer group ID is used. "the proposed solution Tdoc S3-212464 fails to identify the need for different keys for the challenge code security parameter and the response code security parameter used during the discovery phase as described in the previous embodiments. If a single PSDK is provided as the root key for protecting public safety discovery messages (as proposed in Tdoc S3-212464), even if a key derivation function is applied such that the challenge code security parameters and the response code security parameters have different DUIK, the involved devices will be able to generate all those keys and thus the discoverer UE may be able to impersonate the discoveree UE, as described above. To address this security issue, the key handling process for discovery must distribute different master keys (i.e., different PSDKs) for deriving the challenge code security parameters and the response code security parameters. For example, two different master keys may be psdk_qcsp and psdk_rcsp: PSDK_QCSP is used to generate query code security parameters (including DUIK and/or DUSK and/or DUCK), and PSDK_RCSP is used to generate response code security parameters (including DUIK and/or DUSK and/or DUCK). In this way masquerading attacks are not feasible. The psdk_qcsp and psdk_rcsp may be independently randomly generated or they may be generated from the master key K by applying a key derivation function. In this last case, K must not be disclosed to the UE (particularly the remote UE and the relay UE) because if K is disclosed to the UE, masquerading attacks are possible. When the corresponding network function in the core network (e.g. DDNMF or PKMF) has authorized the UE and has identified its role (e.g. whether the UE is a remote UE or a relay UE or both), the generation or retrieval of these keys can be done in step 4 above. The distribution of these keys is completed in step 5 above.

In TR33.847v0.7.0 (08/2021), solution No. 37 is included after SA3#104e is established based on the Tdoc S3-212464 revision. Solution 37 indicates that the key process for discovery must distribute different master keys. This updated protocol improves the protocol to some extent to avoid the above-described attacks, since the UE is now able to receive multiple PDSK's, e.g., two PDSK's, one for querying the code security parameters and one for responding to the code security parameters. This improves the situation compared to section 6.6.7 of TS33.303, in section 6.6.7 of TS33.303, protection of discovery messages between UEs is described, including distributing (single) PDSK to UEs, allowing discovery keys to be generated from PDSK by means of a Key Derivation Function (KDF) (DUSK, DUCK, DUIK). However, in the description in tr33.847v0.7.0 (08/2021), the description in solution No. 37 is still insufficient. The reason is that the discoverer UE using the match report cannot receive DUIK or any other key that can be used to derive DUIK for verifying the MIC. If the PDSK used to derive DUIK is distributed to the UE (because it allows to generate DUSK and DUCK), the problem is not solved because the UE has PDSK so it can generate DUIK. Thus, the improved key handling procedure applicable to TR33.847v0.7.0 (08/2021) consists in distributing to the UE (in particular to the discoverer UE):

A first PDSK allowing generation of a first set of DUIK, DUSK and DUCK for protecting the security parameters of the query code, and

a second DUCK and/or a second DUSK for decrypting/descrambling the response code security parameters, but not including the second DUIK. These second DUCK, DUSK and DUIK keys can be generated from the second PSDK, for example by means of a KDF.

In TR33.847v0.7.0 (08/2021), a conclusion was drawn after SA3#104e regarding Key Issues (KI) #1 and # 2. In KI #1, for the restricted ProSe direct discovery scenario, solution No. 4 is used as the basis for a specification work including an annotation of "security key in code transmission security parameters of discoverer UE and security key in code transmission security parameters of discoveree UE need to be generated independently and randomly". This ensures that impersonation of the discoveree UE is not feasible when the discoveree UE utilizes the match report. "the prescribed keys need to be independently and randomly generated consistent with the above embodiments, which require that these keys be different to avoid impersonation attacks. In ki#2, it is specified that: the conclusion of the "direct discovery" is as follows: (1) The discovery key includes a cryptographic key, an integrity key, and a scrambling key. (2) For open discovery, only the integrity key will be assigned by the 5G DDNMF and will be used to provide integrity protection for the advertisement message. (3) For restricted discovery, the 5G DDNMF will assign discovery key(s) based on the requirements of the Prose service. The conclusion in KI #2 is insufficient to defeat the masquerading attack described above and is inconsistent with solution No. 4, as the conclusion in KI #2 limits the number of DUIK to one. Thus, the conclusion of the update ki#2, specifies: "(1) the discovery key comprises at least one cryptographic key, at least one integrity key, and at least one scrambling key. "

Clause 6.3 in TS33.503 describes the security of 5G ProSe UE to network relay communications. In the security of 5G ProSe communications via layer 3 UE-to-network relay, control plane (6.3.3.3 clause in TS 33.503), it is specified that "PCF should provide authorization policies and parameters for 5G UE-to-network relay discovery and communications as specified in 5.1.4 in TS23.304[2 ]. Clause 5.1.4 in "TS23.304 specifies: "whether the security parameters can be provided by the PCF, and the details of the security parameters will be determined by the SA3 WG. "the first two steps 0a and 0b of the message flow of fig. 6.3.3.3.2-1 in TS33.503 specify: "remote UE and relay UE will register with the network. UE-to-network relay will be network authenticated and authorized to support as relay UE. The remote UE will be network authenticated and authorized to act as a remote UE. "to this end, the remote UE and the relay UE must contact their respective AMFs. The AMF acts as an entry point when registered in the network. According to 23.304 clause 4.3.4, the amf selects the PCF that supports providing 5G ProSe policies/parameters based on an indication of 5G ProSe capabilities as part of the "5GMM capabilities" in the registration request. After this, it is specified that "remote UE shall initiate the discovery procedure using either of the model a or model B methods specified in clause 6.3.1.2 or 6.3.1.3 of TS23.304[2], respectively. "at a later stage of the procedure (step 4 in fig. 6.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 according to clause 4.3.4 of 23.304), the AMF does so by: subscription information related to 5G ProSe is obtained from the UDM in contact with the UDM and stored as part of the UE context data.

Two different entities cannot be responsible for managing the parameters and discovery keys that need to be distributed to the relay UE and the remote UE for the discovery process. Thus, the current specification in TS33.503 does not address which entity manages the discovery parameters and keys and which entity authorizes the UE to obtain the discovery parameters and keys. In particular, a single network function in a single network can be responsible for managing discovery keys, which may be PCF or PKMF or DDNMF or another NF in one of the networks.

In a first embodiment that overcomes the above-described problem, a remote UE (or relay UE) has registered with its network and seeks authorization for a given network relay service provided by a different network (e.g., the network of relay UEs (or remote UEs)). In this case, the network of the remote UE (or relay UE), e.g. by AMF or PCF, will be informed about the information (identity or requested relay service) of the remote UE (or relay UE) by the network of the relay UE (or remote UE), in particular by PCF or key management function responsible for the discovery key (e.g. PKMF, DDNMF) of the relay UE (or remote UE). When doing so, the network (e.g., PCF) of the relay UE (or remote UE) will provide the corresponding discovery parameters and keys of the remote UE (or relay UE) to the network (e.g., PCF) of the remote UE (or relay UE). Note that the network of remote UEs and the network of relay UEs can work together to create discovery certificates or keys based on input from both networks (e.g., partial keys, UE identities, or network identities). Once this is done, the remote UE (or relay UE) can be registered, authenticated and authorized by the network of the remote UE (or relay UE) as described in steps 0a and 0b in the message flow in fig. 6.3.3.3.2-1 in TS 33.503. In particular, it will receive discovery parameters and keys at this stage. Whenever the network (e.g., PCF) of the remote UE (or relay UE) updates the discovery parameters and keys, the network (e.g., PCF) of the remote UE (or relay UE) must contact the network (e.g., PCF) of the relay UE (or remote UE), which will be responsible for updating the parameters of the relay UE (or remote UE).

In a second embodiment, which overcomes the above-described problem, a remote UE (or relay UE) has registered with its home network and seeks authorization for a given network relay service provided by a different network (e.g., the network of relay UEs (or remote UEs)). In this case, the network of the remote UE (or relay UE), e.g. by AMF or PCF, will inform 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 needs of the relay service. Furthermore, the network of the remote UE (or relay UE), e.g. by AMF or PCF, will inform the remote UE (or relay UE) about the information of the network of the relay UE (or remote UE), in particular about the AMF or PCF of the relay UE (or remote UE) and/or the key management function responsible for the discovery key, which has to be contacted in order to register, authenticate and authorize the discovery key and/or retrieve the discovery key in steps 0a and 0b in the message flow in fig. 6.3.3.3.2-1 in TS 33.503. This means that if this second embodiment is used, both the remote UE and the relay UE will retrieve the 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 the discovery parameters and keys from, for example, the corresponding PCF.

In a third embodiment, which can be combined with the above embodiments, the network of relay UEs and the network of remote UEs interact to match or align relay service codes. For example, in the above-described first embodiment, when the network of the remote UE (or relay UE) notifies the network of the relay UE (or remote UE) of information about the relay service requested (provided) by the remote UE (or relay UE), the network of the relay UE (or remote UE) may match/align the relay service code of another network with the relay service code used in its network.

Clause 6.3 in TS33.503 describes the security of 5G ProSe UE to network relay communications. In the security of 5G ProSe communication via 5G ProSe third layer UE to network relay, a User Plane (UP) method (clause 6.3.3.2 in TS 33.503) and Control Plane (CP) (clause 6.3.3.3 in TS 33.503) for 5G ProSe third layer UE to network relay authorization and security establishment are described. Fig. 7 refers to fig. 6.3.3.2.2-1 in TS33.503 (authorization and secure PC5 link establishment procedure for UE-to-network relay through UP), fig. 8 refers to fig. 6.3.3.3.2-1 in TS33.503 (authorization and secure PC5 link establishment procedure for UE-to-network relay through CP), there are three phases in both the UP-based procedure and the CP-based procedure (as shown in fig. 7 and 8):

A first phase, which involves providing discovery parameters including a discovery key,

a second phase involving a discovery process that depends on the provided discovery parameters, and

a third phase for PC5 authorization and security establishment.

Although the second phase relies on the same discovery protocol, the first phase and the third phase may involve different protocols or entities (network functions). This can lead to interoperability issues, for example, if the UE is configured with discovery parameters/keys based on the UP first phase, but the third phase is CP-based for PC5 authorization and security establishment. The reason for this interoperability problem may be due to some network functions not being initialized. For example, interoperability problems between the first stage of the UP-based method (CP-based method) and the third stage of the CP-based method (UP-based method).

Fig. 9 shows a more complete description, including the entities involved in the UP procedure and the CP procedure. Fig. 9 summarizes several interactions and communications that ensure interoperability between the first stage and the third stage of the UP/CP based method:

in fig. 9, regarding reference a), the relayed PKMF interacts with a network function (e.g., AMF or UDM) in the relay network by means of a communication interface, so that if the UE is configured via the UP method in the first phase, relay authorization (step 4 in fig. 8) can occur in case the UE starts the CP-based third phase. According to Tdoc S2-2200214, this communication interface is denoted as Npc10 (reference point between UDM and 5G PKMF it is used to provide subscription information in order to authorize whether the UE can act as a 5G ProSe remote UE or a 5G ProSe UE to network relay). Such communication may occur, for example, after the UE is configured via an UP method (i.e., the PKMF pushes the configuration to the AMF), or on demand when the UE begins the CP-based third phase (i.e., the AMF sends a request to the PKMF).

In fig. 9, regarding reference b), the PKMF of the remote device and the AUSF/UDM of the remote device interact with each other by means of a communication interface to inform each other about the configuration of the remote device so that they are ready for the CP-based third phase procedure and the network of the remote UE can authorize the remote device. Such communication may occur, for example, after the UE is configured via an UP method (i.e., the PKMF pushes the configuration to the AMF), or when the UE begins the CP-based third phase (e.g., at steps 4-10 in fig. 8), on demand (i.e., the AMF sends a request to the PKMF).

In fig. 9, concerning reference c), an interaction of AMF-PCF (remote), PCF (remote) -PCF (relay), PCF-DDNMF, DDNMF-PKMF (relay) is shown to retrieve the key managed by PKMF (relay) in an initial first stage (configuration of discovery parameters/keys) in the CP-based procedure. Here, a network function such as PKMF (relay) manages keys of both UP and CP.

In fig. 9, regarding reference d), the interactions of AMF-PCF, PCF-DDNMF, DDNMF-PKMF (remote), and final PKMF (remote) -PKMF (relay) are shown to retrieve keys from PKMF (relay) in the initial first stage of CP-based procedure (discovery of configuration of parameters/keys). Here, a network function such as PKMF (relay) manages keys of both UP and CP.

Hereinafter, various embodiments are described. In addition to KI #16 in TR33.847, the first embodiment and its variations described above also address/can be applied to other key issues related to UE-to-network relay, including at least:

the key issue #4 (KI # 4) is about the authorization in the UE-to-network relay scenario, i.e. how the relay UE is authorized to act as a relay. This can be done in step 1.E.iii, where the remote UE checks the relayed RSC and if its signature is valid, it can verify that it is authorized by the CN to provide the corresponding service.

Key issue No. 3 (ki#3) and key issue No. 9 (ki#9), ki#3 being security of UE-to-network relay and ki#9 being key management in 5G proximity services for UE-to-network relay communication, they are related to how keys should be handled and PC5 links protected.

The arrangement described in the first embodiment can be extended to address these key issues. It is possible to exchange a shared secret K' to protect the PC5 communication link between the remote UE and the relay UE. One option is for the remote UE to randomly generate the shared secret K before step e.iv. In step e.iv, it sends K to the relay UE in a secure manner by encryption. The signature included in step e.iv can also have (encrypted) K as input so that the relay can check the integrity of K. For example, the shared secret K' is calculated by applying a KDF to a concatenation of K, N _remote and n_relay in step e.vi. This is shown in fig. 4. Another option occurs if extension 1 is available. In this case, in step e.ii, K can be generated by the relay UE and sent to the remote UE.

One suitable key exchange method is Elliptic Curve (EC) Diffie Hellman. One suitable public key encryption method is an EC-integrated encryption scheme.

Note that the above paragraphs describe the distribution alternatives for solutions No. 1, 6, 10 and 15 in TR33.847 that address KI # 9. In these solutions, the core network participates in 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 that can be used to protect the PC5 between the remote UE and the relay UE.

The key problem #11 (KI # 11) is about UE identity protection during ProSe discovery, i.e. how the UE identity should be protected during discovery. This can be done as in step 1.E.i, where the remote UE replies with a random number only when it receives the RSC broadcast by the relay station. Random numbers serve two purposes here. The first purpose is with respect to freshness, as already described in the main protocol. The second purpose is to act as a temporary identifier for the UE so that its true identity is not disclosed until the remote UE has verified that the relay UE is authorized to act as a relay. The true identity of the remote UE may be disclosed in step 1.E.iv together with PDU parameters.

The above first embodiment and variants thereof also solve/can be applied to other key problems related to UE-to-UE relay. In a UE-to-UE relay scenario, two remote UEs need to communicate directly with each other through a relay UE.

We note that in TR23.752, scheme No. 11 was chosen as the baseline for model a findings, and scheme No. 8 was chosen as the baseline for model B findings. For the case of solution number 11, the discovery information includes: (i) type = announcement, (ii) discovery type = UE-to-UE relay discovery, (iii) advertiser information (i.e., upper layer identifier of UE-R user), (iv) ProSe UE ID of UE-R (i.e., layer 2 identifier of UE-R), (v) list of "target user information" parameters (or attributes) (including users of UE-1 and UE-2) that have been gathered during group member discovery in step 2. The "target user information" is an upper layer parameter identifying the target user. To support layer 2 communications via stateful UE-to-UE relay, "target user information" also includes a layer 2 identifier of the target user's UE. In solution 8, the discovery information is accomplished by sending a "broadcast" direct communication request, and thus is not a separate discovery message. The direct communication request can include source UE information, target UE information, an application ID, and a relay service code.

The key issue 6 (KI # 6) is about the integrity and confidentiality of the information on the UE-to-UE relay, i.e. how to secure the communication between two remote UEs communicating on the relay UE. In particular, once two UEs have identified and connected to the appropriate relay in accordance with the above solution, they can use the same information configured by the CN to exchange a symmetric key (as in extension 2), which can be used to protect the communication between the two UEs.

Related work and differences: it should be noted that solution number 8 in TR33.847 also uses public keys to handle the same situation. However, current solutions have many FFS addressed in the present solution. Solution number 16 also solves KI #6, but it does not directly mention public key encryption.

Hereinafter, it is described how the solution number 8 can be improved by using public key encryption. Some of these improvements can also be applied to solution number 16.

The first point still to be discussed is how to bind the public key to a specific UE. This means that this solution does not provide an authentication means and is vulnerable to man-in-the-middle attacks. This problem is solved in this solution, because the public key assigned to the UE is signed by the CN.

Solution 8 also describes the public key exchange in messages 2 and 4, and in step 6 it writes to: "use the public keys of the source UE and the target UE to protect the end-to-end security of the extended link, while the routing information will not be affected. From this description it seems to focus on Diffie-Hellman key exchange, where the key is equal to pr_a pu_b=pr_b pu_a, where pr represents the private key and PU represents the public key. Thus, this solution does not cover ECIES or Key Encapsulation Mechanisms (KEMs), such as the KEM standardized by NIST Postal Quantum Cryptography (PQC). Examples of PQC KEMs include SABER, round5, kyber, or NTRU. The difference in this respect is that in message 2 the source UE sends its public key and upon reception the target UE randomly generates a random key K encapsulated with the public key of the source UE. Message 4 includes the temporary public key component and the wrapping key from the target UE.

Another FFS in solution number 8 is on how to ensure that DCA messages are trusted. This can be done if the public key is signed by the CN, as is done in steps 1.A and 1.B of the present solution. As mentioned above, IBE solutions can also be used.

Solution number 8 configures the relay with the relay policy/parameters in step 0, then in step 3, if the policy matches and the relay is allowed to relay the message, it does so. This approach has several problems, such as:

* First, message number 2 (direct communication request from source UE to UE relay) can be replayed. This can be avoided if the message includes a random number that is first disclosed by the relay and signed by the source UE. Alternatively, the source UE can also sign in for the current time and the relay station will only accept messages within a given time window. This is equivalent to step 1.E.iv.

* Second, the parameters in message number 2 are in plain text, with no integrity protection. Meaning that they can be modified by an attacker. By observing whether the relay or target UE reacts to message 2 and message 3, the attacker can also know, for example, which ProSe applications the relay or target UE supports. This problem can be solved if the relay first discloses 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 equivalent to step 1.E.ii.

Fig. 5 depicts how the solution number 8 can be modified based on the above concept.

* Steps a0, a1, a2 are initial provisioning with respect to UE and relay. This initial provisioning is similar to steps a and b in the main solution, except/different in that the devices are provided with information/policies regarding their ability to relay information in the UE-to-UE use case.

* Step c is identical to the first embodiment or a variant thereof.

* Step e.i is the same as the first embodiment or a modification thereof.

* Step e.ii is identical to the first embodiment or a variant thereof, except that the relay station now distributes signature information about its ability to relay information in the UE-to-UE use case.

* If the information is successfully verified by the source UE, the source UE replies with e.iv, a.s in the primary solution. Note that these parameters can be encrypted to ensure privacy since the source UE has the public key of the relay. 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. In step a0, some of these ProSe parameters (e.g., broadcast layer 2 ID, proSe application ID, application layer ID of UE, application layer ID of target UE, relay applicable indication) may also have been directly signed by CN and provided to source UE.

* In step e.v, the relay checks whether it can/is allowed to forward information in this connection. The relay also checks whether the source UE is as it claims to be. These checks are very similar to the first embodiment.

* Step e.vi includes forwarding the information to the target UE. However, it must be considered that the information in e.iv is encrypted with the relayed key and the target UE does not have the corresponding private key. However, the target UE is able to decrypt and encrypt the information again based on the target UE's public key. Alternatively, the relay 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 itself goes through steps c, e.i, e.ii, e.iv when connected to the relay. It should be noted that the relay may already know the preferences/policies of the target UE (e.g., if these preferences/policies have been previously disclosed to the relay), and thus the relay may forward the message only if the message meets the policy of the target UE. This step may also include one or more random numbers, for example, the random numbers in step e.i or step e.ii, or a combination thereof.

* Step e.vii is to check the incoming message with respect to the target UE. It checks whether the source UE meets its policy/communication requirements. The target UE can check this because it receives the communication of the source UE signed by the CN and/or the source UE. In a particular option in step e.vii, the target UE is able to randomly generate a symmetric key and to encapsulate/encrypt the randomly generated symmetric key K with the (anti-quantum) public key of the source UE received, for which purpose the source UE will also generate its temporary public key.

* Step e.viii is used to confirm the communication and includes the public key of the target UE. It can also include additional information from the target UE (e.g., additional information signed by the CN) so that the originating UE can verify it. This information can be encrypted with the wrapping key (step e.vii) or the public key used for the source UE. The information may also be signed by the target UE. Alternatively, the message authentication code can also be obtained using a symmetric key previously established between the relay UE and the target UE. The purpose of the signature or MAC is to let the relay know that this is a trustworthy message and be able to forward it. The message can also include a random number in step e.vi, so that the relay UE and the source UE can check the freshness of the message.

* Step e.ix is related to relay checking the signature or MAC exchanged in step e.viii.

* Step e.x contains the message e.viii without signature or MAC. Upon receiving this message, the source UE can decapsulate the symmetric key and decrypt any information about the target UE. After decryption, the source UE can verify the information by checking the signature and the freshness by checking the random number.

The steps in fig. 5 (described above) and in fig. 6.8.2.1-1 in TR33.847 correspond to each other as follows:

FIG. 5	FIG. 6.8.2.1-1 in TR33.847
		Step e.iv	Message 2
Step e.vi	Message 3
		Step e.vii
Step e.viii	Message 4
		Step e.ix
Step e.x	Message 5

The key number o 7 problem is about the authorization in the UE-to-UE relay scenario, i.e., how remote UEs can verify that they are authorized to talk to each other. In particular, once two UEs have identified and connected to the appropriate relay according to the above solution, the following scheme is possible:

■ In the first configuration phase, the CN network should provide each UE with policies describing its communication properties and policies determining which properties are required by the UE to allow a device-to-device communication link with another UE in the initial provisioning phase. Each UE should also receive the public key signed by the CN. The UE should possess the corresponding private key or also receive the corresponding private key from the CN.

During operation, two alternatives are considered:

■ Alternative 1: during operation, one of the UEs may send its communication policy to the other UE. The second UE will check the communication policy and if the communication policy is authorized, the second UE sends its own communication policy to the first device. If the first device also authorizes the second device, the first device will send an acknowledgement to the second device.

■ Alternative 2: during operation, when a UE joins a group, the UE first receives parameters signed by the CN from the relay. This is equivalent 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 Requirement (RSC). These checks are similar to those in step e.iii of fig. 3. Next, the UE sends its communication parameters to the relay UE, similar to e.iv in fig. 3. The relay UE checks the communication parameters (step e.v in fig. 3).

The first embodiment and its variants described above also solve/can be applied to other key problems related to multicast communication. In particular, thisPart of theTo KI #13 in TR33.847, KI #13 with respect to security and privacy of multicast communications, and to protection of L2 ID in terms of linkable, traceability and privacy, and also with respect to integrity/confidentiality of communications.

Next, we propose a solution to address these problems, which is based on the alternative 2 proposed above for key problem # 7. After performing the steps described in alternative 2, the relay can check whether the UE can join (be authorized) communication with other UEs that may already be part of the group of UEs. If the UEs are authorized to talk to each other, the relay notifies each UE in the group. In particular, assume that a new UE Z has joined. When the relay informs the remote UE (A, B, …, Y) that a new UE Z joins the group, the relay sends N-1 messages M, one message M to each of the UEs already in the group (A, B, …, Y). This message M is similar to e.iv in fig. 3, where (i) puk_relay is replaced with A, B, …; (ii) N_relay is replaced with a random number previously sent by A, B, …, Y; (iii) S (prk_cn, rsc|pdu_parameter|puk_remote) is a signature from the core network about the capabilities of the new device Z, not the remote device; and (iv) S (PrK remote, …) is replaced by a signature from the relay device on the transmitted parameters. In addition, the relay must also inform the new device Z about the information of the existing devices (A, B, …, Y). For this purpose, the relay sends a message M' to Z. M' is similar to M, but it does not contain information of a single device, but contains information of N-1 devices.

In addition to the above, the relay can also handle the master group key K that can be used for intra-group communication. The relay randomly generates the master group key K, which can be distributed to the UEs protected in messages M and M' described above. A new master group key can be generated each time a new device joins or leaves the group. By using K and the random numbers of all devices in the group as inputs, the derived group key K' can be derived as a key derivation function. For example, a hash function can be applied to a cascade of: K. each of the random numbers ordered with an incremented value, and a counter i. This counter i can be used to rotate K' over time.

The 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.

Note that this method for checking mutual authorization and group key distribution means that the relay has to send a total of N-1 messages. This is an improvement over the solution where each UE must mutually authenticate/authorize, where the overhead of N2 messages is required. This advantage is also mentioned in solution 12, which solves for ki#8: "UE1 may communicate with more than one target UE over a PC5 unicast link via a UE-to-UE relay. In this case, all target UEs must be informed about the new IP address/prefix of UE 1.

This solution is shown in fig. 6, which mainly comprises the following steps:

* Steps a, b, c are provided initially and are equivalent to steps a and b in fig. 3.

* Step d refers to discovery and distribution authentication/authorization. This includes equivalent steps for c, d, e.i, e.ii, e.iii, e.iv and e.v in fig. 3.

* Step e is to check if the new UE Z is authorized in the group according to the policies of the other UEs.

* Step f is related to the generation of the master group key as defined above.

* Step g is about sending a message M to each UE that is already part of the group.

* Step h is about sending a message M' to the new UE.

* Step i is related to the generation of the current group key.

Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the word "a" or "an" does 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 foregoing description details certain embodiments of the invention. However, it should be understood that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways and is therefore not limited to the embodiments disclosed. It should be noted that when describing certain features or aspects of the present invention, the use of particular terminology should not be taken to imply that the terminology is being redefined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated.

As explained throughout the previous embodiments, the proposed variants of the invention can be implemented in a network, for example a cellular network as a 5G network as shown in fig. 10. The cells of the network are served by the primary station 1000. Under the coverage of the primary station 1000 (e.g., gNB), multiple secondary stations can be connected to the primary station. Some secondary stations may be adapted to operate as relay station 1010. Such a relay station may include a transmitter 1011 coupled to a transmit antenna, and a receiver 1012 coupled to a receive antenna. Typically, the receive antenna is the same antenna as the transmit antenna. In addition, according to the technique, the antennas may be formed of an antenna array that may allow different transmit/receive modes, e.g., MIMO, transmit diversity, and operation on different sets of frequencies.

A controller 1013 (e.g., a CPU or microcontroller operating in software) is adapted 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 connection with the above described embodiments, the controller is adapted to establish a connection between the relay station 1010 and the primary station 1000. More specifically, the controller 1013 can configure the receiver 1012 to receive a first set of configuration parameters in at least one first safety message from the primary station 1000, said first set of configuration parameters comprising an attribute or a service code.

The controller 1013 is capable of controlling the transmitter 1011 and causing the transmitter 1011 to transmit at least one transmission attribute or service code from the first set of configuration parameters. The attribute or service code can be broadcast for receipt by other stations (e.g., secondary station 1020).

In addition, the controller 1013 may then be configured to establish a direct communication with the secondary station 1020 using the public key based on a request from the secondary station, the request being based on the sent service message.

Typically, the relay station may be a UE, like a side link compatible UE, which is thus able to act as a relay station when configured. Alternatively, the relay station may also be another master station, such as an access point, a gNB or a femtocell gNB.

Secondary station 1020 may generally be a UE and includes a transmitter 1021, a receiver 1022, both of which are generally coupled to one or more antennas or antenna arrays. In addition, the secondary station 1020 comprises a controller 1023, the controller 1023 being adapted to control the receiver 1021, the transmitter 1022 and possibly other elements of the UE. Regarding the relay station, the controller 1023 may be a processor or a CPU, and may be operated by software.

The controller 1023 can cause the receiver 1021 and transmitter 1022 to establish a connection with the master station 1000. This includes, for example, configuring the receiver 1021 to receive a second set of configuration parameters in at least one second secure message from the master station 1000, the second set of configuration parameters including an attribute or relay service code linked with an upcoming data exchange with the relay station 1010.

The receiver 1021 may be adapted to receive at least one transmission attribute or service code from the relay station 1010, and the controller may be configured to: it is determined whether the transmission attribute or service code is included in the second set of configuration parameters or whether its policy is met, and the transmitter is caused to establish direct communication with the relay station 1010 when it is determined that the transmission service code is included in the second set.

The described operations are similar to the operations shown in fig. 3 to 9, which can be implemented as program code means of a computer program and/or dedicated hardware of a related communication device or access device, respectively. A computer program may 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 may also be distributed in other forms, such as via the internet or other wired or wireless telecommunication systems.

Claims

1. A method for operating a communication system comprising a primary station, a relay station and a secondary station, the primary station being linked to a core network, the primary station serving a cell, the relay station being served by the primary station, the secondary station being served by the primary station, the method comprising the steps of:

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

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

4. A method according to claims 2 and 3, wherein the at least one first secure message comprises at least one first core network signature from the core network generated at least on:

The relay encryption public key, and

the secondary station encrypts a public key, and

5. A method according to claims 2 and 3, wherein the at least one first secure message comprises at least one first core network signature from the core network generated at least on:

the relay encryption public key, and

The secondary station encrypts a public key, and

6. The method of claim 4 or 5, wherein the step of establishing direct communication comprises:

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

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

9. The method of claim 6, 7 or 8, wherein the response message further comprises a relay nonce, and wherein the secondary station communicates communication parameters in a configuration message comprising a configuration message signature generated by applying the secondary station encryption private key on at least the relay nonce.

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

11. The method of claim 1, wherein establishing direct communication comprises:

12. The method of any of the preceding claims, wherein the relay station transmits at least one transmission 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 following further information: a data session policy, data session parameters, the first core network signature, a relay encryption public key, and wherein the secondary station establishes direct communication with the relay station when determining that the transfer attribute or the transfer service code of the first set of configuration parameters is included in the second set of configuration parameters and the further information is compatible with the upcoming data session.

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

14. The method of any of the preceding claims, wherein the at least one transmit service code from the first set of configuration parameters is a result of a combination of a hash service code of the first set and a transmit random number, and the relay station also transmits the transmit random number.

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

16. The method of claim 1, wherein the relay station establishing a connection with the master station comprises: the relay station generates a relay encrypted public key and a relay encrypted private key, sends the relay encrypted public key to the primary station for signing by the core network, and receives the first set of service codes and a first core network signature based at least on the relay encrypted public key in the at least one first secure message from the primary station.

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

18. A method for operating a relay station adapted to communicate in a network, the network comprising a primary station and a secondary station, the primary station being linked to a core network, the primary station serving a cell and the secondary station being served by the primary station, wherein the relay station is served by the primary station, the method comprising the steps of:

19. A method for operating a secondary station adapted to communicate in a communication system, the communication system comprising a primary station and a relay station, the primary station being linked to a core network, the primary station serving a cell and the relay station being served by the primary station, wherein the secondary station is served by the primary station, the method comprising the steps of:

20. A relay station adapted to communicate in a network, the network comprising a primary station and a secondary station, the primary station being linked to a core network, the primary station serving a cell and the secondary station being served by the primary station, wherein the relay station is served by the primary station, the relay station comprising:

the conveyor is provided with a conveyor belt,

the number of the channels of the receiver is determined,

a controller adapted to establish a connection with the master station,

21. A secondary station adapted to communicate in a communication system comprising a primary station and a relay station, the primary station being linked to a core network, the primary station serving a cell and the relay station being served by the primary station, wherein the secondary station is served by the primary station, the secondary station comprising:

the conveyor is provided with a conveyor belt,

the number of the channels of the receiver is determined,