A method for operating a cellular network

Abstract

The invention relates to a method and an apparatus for configured for communicating in a network with a least a a first device, wherein the apparatus is configured to: - receive a message from the first device including at least one first message and an indication of a timing value t1, - extract the first message and the indication of the timing value t1, - storing the first message with a validity time, said validity time being based on a time reconciliation process and on the indication of the timing value t1.

Description

[0001]A METHOD FOR OPERATING A CELLULAR NETWORK FIELD OF THE INVENTION The present invention relates to the field of wireless communications, and in particular to security aspects in the context of cellular networks, like the UMTS Long Term Evolution (LTE) or LTE Advanced (both included in 4G), New Radio (NR) (5G), 6G or other cellular networks or mobile in communication networks. BACKGROUND OF THE INVENTION In conventional cellular networks, a primary station serves a plurality of secondary stations located within a cell served by this primary station. Wireless communication from the primary station towards each secondary station is done on downlink channels. Conversely, wireless communication from each secondary towards the primary station is done on uplink channels. The wireless communication can include data traffic (sometimes referred to User Data), and control information (also referred sometimes as signalling). This control information typically comprises information to assist the primary station and / or the secondary station to exchange data traffic (e.g. resource allocation / requests, physical transmission parameters, information on the state of the respective stations). In the context of cellular networks as standardized by 3GPP, the primary station is referred to a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or eNB) in 4G (LTE). The eNB / gNB is part of the Radio Access Network RAN, which interfaces to functions in the Core Network (CN). In the same context, the secondary station corresponds to a mobile station, or a User Equipment (or a UE) in 4G / 5G, which is a wireless client device or a specific role played by such device. The term “node” is also used to denote either a UE or a gNB / eNB. Additionally, for example, in the case of PC5 interface or Sidelink communication, it is possible to have Direct communication between secondary stations, here UEs. It is then also possible for UEs to operate as Relays to allow for example out of coverage UEs to get an intermediate (or indirect) connection to the eNB or gNB. To be able to work as a relay, a UE may use discovery messages to establish new connections with other UEs. Therefore, the role of a relay node as shown on Fig.1 has been introduced in 3GPP. This relay node 120 is a wireless communication station 120 that includes functionalities for relaying communication between a primary station 100, e.g. a gNB and a secondary station 110, e.g. a UE. This relay function for example allows to extend the coverage of a cell 10 to an out-of-coverage (OoC) secondary station 110. This relay node 120 may be a mobile station or could be a different type of device. In the specifications for 4G, the Proximity Services (ProSe) functions are defined inter alia in TS23.303, and TS24.334 to enable - amongst others –connectivity for the cellular User Equipment (UE) 110 that is temporarily not in coverage of the cellular network base station (eNB) 100 serving the cell 10. This particular function is called ProSe UE-to-network relay, or Relay UE for short. The Relay UE 120 relays application and network traffic in two directions between the OoC UE 110 and the eNB 100. The local communication between the Relay UE 120 and the OoC UE 110 is called device-to-device (D2D) communication or Sidelink (also known as PC5) communication in TS23.303 and TS24.334. Once the relaying relation is established, the OoC-UE 110 is, e.g., IP-connected via the Relay UE 120 and acts in a role of “Remote UE” 110. This situation means the Remote UE has an indirect network connection to selected functions of the Core Network as opposed to a direct network connection to all Core Network functions that is the normal case. Further, it has been introduced the role of a UE to UE relay node, i.e., a relay node relaying the communication between two UE devices. This is as illustrated in Fig.3 where the relay node 310 relays the communications between UE devices 320 and 330. UEs 310, 320, 330 may connect to the core network through a base station 300 when in-coverage. In such relay scenarios, the relay devices may receive and store some information for some time before forwarding it towards the target device. This information that may be stored and forwarded may be discovery messages received from a source UE whereby the relay UE may release them at some point of time later. This information that may be stored and forwarded may be a SIB that may contain a timestamp. Furthermore, cellular networks are evolving to enable more mobile access devices such as satellites, unmanned aerial vehicles, buses or trains that are capable of storing data for some time before forwarding it further. An example relates to a satellite that receives and stores certain data when it is close to a terrestrial gateway and only releases it when the receiving party becomes in coverage. Furthermore, cellular networks are evolving to enable Ambient IoT scenarios whereby resource constrained tags may send short messages indicating its presence, sensed values, etc. These short messages need to be kept as short as feasible due to the limited resources of the tags and may be stored for some time in intermediate devices before being further forwarded. However, these application areas are still prone to multiple technical challenges. For instance, in some situations, the exchanged messages may include data related to a timestamp or a counter whereby the data may be only related to part of the timestamp or counter. This data may be required in the context of a security protocol, e.g., the timestamp or counter may be used for freshness, e.g., as input or in combination with a cryptographic function such as a key derivation function. For instance, instead of including an n bit long counter the information may be the b least significant bits of the counter (b less than n) to help the receiving party or the intermediate (relay) devices to determine the whole n bit long counter. In general, it is challenging to determine how UEs communicating by means of a relay device can recover the original information (e.g., timestamp or counter) given the exchanged data. Similarly, it is challenging to maximize the storage time or validity time of certain data, e.g. security parameters or credentials. In some situations, a single hop in a UE-to-Network relay configuration or a UE-to-UE configuration is not sufficient to enable the communication between cellular devices. Similarly, in some situations, UEs may be prone to security errors and privacy attacks, e.g., when long term identities may leak. SUMMARY OF THE INVENTION One aim of the present invention is to alleviate the above mentioned problems and technical challenges. To this end, it is proposed in accordance with a first aspect of the invention, an apparatus as claimed in claim 1. In accordance with a second aspect of the invention, it is proposed a method for communicating in a network as claimed in claim 14. In particular, it is proposed an apparatus and a corresponding method for communicating in a network with a least a first device, wherein the apparatus is configured to: - receive a message from the first device including at least one first message and an indication of a timing value t1, - extract the first message and the indication of the timing value t1, - obtain a validity time being based on a time reconciliation process and on the indication of the timing value t1, and - perform one of: i. storing the first message with the validity time or ii. checking the freshness of the message based on the validity time. In a first variant of the first and second aspect of the invention, the validity time is determined by applying the time reconciliation process on the indication of the timing value t1 encoded by the first device to recover the timing value and based on at least a timing value ••of the apparatus and the parameters used to encode the indication of the timing value t1. Further to the first variant, the indication of the timing value t1 can include the b least significant bits of the timing value t1, < ••>•, included in the message, wherein < ••>•, is the remainder of dividing t1by B, where B is a parameter. Optionally, according to the reconciliation process, the apparatus may be configured to compute ••= ••+ ••< < ••>•• •< ••>••+ • >•• where s is a synchronization error between Alternatively, the apparatus may be configured to compute •• = •• • • • • + < <•• >•• •< •• • ••• >••>•• where s is a synchronization error between •• and •• and • isthe maximum storage time of the apparatus. In a further variant of these two options, the apparatus may be configured to recover one or more reconciled timing values ••and verify their validity by using the reconciled timing value with a cryptographic function. Additionally, the cryptographic function may be a key derivation function and the validity verification may consist in checking that the computed MIC equals a received MIC in the received message. Further to the two above mentionned options, s may be defined as s = 2*MAX_OFFSET, wherein MAX_OFFSET is a security parameter stored on the apparatus. Additionally or optionally, a maximum validity time may be determined as the recovered plus 2•– 2• or the recovered ••itself. Additionally or optionally, a maximum storage time may be 2•– 2• or the recovered t1 minus a current local time t2 of the apparatus. In all the previously defined variants, B may be equal to 2•, where b is a number of bits. In another variant of the first or second aspects or all their variants, the first timing value may indicate the validity time of the first message and determines how long it can be stored by the apparatus. In accordance with a third aspect of the invention, it is proposed an apparatus as claimed in claim 15. In accordance with a fourth aspect of the invention, it is proposed a method as claimed in claim 16. In particular, it is proposed an apparatus and a corresponding method for communicating in a network, the apparatus being configured to receive a timing value indication, derive a timing value from the received timing value indication on the basis of a time reconciliation process, obtain a synchronized timer based on the derived timing value, and apply the synchronized timer to the apparatus or transmit the synchronized timer. In accordance with a fifth aspect of the invention, it is proposed a method for managing privacy-aware emergency connectivity services, comprising a second device receiving a request message from a first device, the second device being authorized for emergency connectivity services, the second device providing its identifier to the first device based on one or more of the following conditions : the second device requested emergency connectivity services in a previous message; and / or the second device did not provide its identifier in a previous message; and / or the 5GS identity type in the request message is set to IMEI or IMEISV. In accordance with a sixth aspect of the invention, it is proposed a method for resilient emergency connectivity services, comprising receiving, by a first device, a first message from a second device comprising an identifier and an emergency relay service code; a first device determining whether to (1) store an identifier provided by the second device and / or (2) provide emergency connectivity services to the second device, the first device being authorized to provide emergency connectivity services to the second device, wherein the determining comprises the first device checking whether the identifier is valid by: - validating it against a local database and / or - sending a second message to a network function for validation andreceiving a third message from the network function with the identifier validation. In accordance with a seventh aspect of the invention, it is proposed a method for discovery ,wherein the direct discovery sets that carry the Application Layer IDs of a first device and a second device, are protected separately, wherein the method comprises receiving, by the first or the second device, a protected discovery message, wherein the first protected direct discovery set is located before the second protected direct discovery set in the protected direct discovery set information element included in the protected discovery message. In accordance with an eigthth aspect of the inveniton, it is proposed a method for device to device communication between a first device and a second device comprising: - receiving, by the second device, a direct link establishment request message transmitted by the first device containing a relay service code, wherein the relay service code is associated with a Network Assistance Security Indicator indicating a security procedure without network assistance is required, and - determining, by the second device, whether it is configured with valid long-term credentials, and - transmitting, by the second device, if the second device is not configured with valid long-term credentials, a first PC5 reject message with a failure cause indicating that security procedure without network assistance is unsupported. In accordance with a ninth aspect of the invention, it is proposed a method for device to device communication between a first device and a third device, through a second device acting as a relay, comprising: - receiving, by the third device, a direct link establishment request message containing a relay service code associated with a Network Assistance Security Indicator indicating the security procedure without network assistance is required, - determining, by the third device whether it is configured with valid-long term credentials, and - transmitting, by the third device to the second device, if no valid long-term credentials are available, a second PC5 reject message indicating that the security procedure without network assistance is unsupported. In accordance with a tenth aspect of the invention, it is proposed a method for UE-to-UE communication, wherein, while a first, second, and third device acting as, Source End UE, UE-to-UE relay UE, and Target End UE, respectively, are establishing a UE-to-UE communication link using a relay service code associated with a Network Assistance Security Indicator indicating the security procedure with network assistance is required, if the second device is not served by NG-RAN, the second device shall send PC5 reject messages to the first and third devices, indicating that security procedure with network assistance is not possible. In accordance with an eleventh aspect of the invention, it is proposed a method for multi- hop connectivity services comprising: - receiving, by a second device, one or more first discovery messages, each first discovery message comprising a relay service code and / or a set of User Info IDs and / or a number of hops, wherein the relay service code indicates the maximum number of hops authorized when providing multi-hop connectivity services, the set of User Info IDs identifies the relaying devices in the multi-hop route, and the number of hops indicates the number of hops in the multi-hop route, and - selecting, by the second device, a preferred multi-hop route from the one or more received discovery messages based on one or more of the maximum number of hops indicated by the relay service code and / or the set of User Info IDs and / or the number of hops contained in the one or more received discovery messages. In accordance with a twelfth aspect of the invention, it is proposed an apparatus adapted for communicating in a network, the apparatus comprising at least one antenna coupled to a receiver, configured for receiving a timing value indication, a controller configured for deriving a timing value from the received timing value indication on the basis of a time reconciliation process, the controller being adapted to obtain a synchronized timer based on the derived timing value, and to apply the synchronized timer to the apparatus and / or to transmit a synchronized timer value. In accordance with a thirteenth aspect of the invention, it is proposed an apparatus configured for managing privacy-aware emergency connectivity services, comprising a receiver configured for receiving a request message from a first device, the apparatus being authorized for emergency connectivity services, a controller adapted to cause a transmitter to provide the apparatus identifier to the first device based on one or more of the following conditions : the apparatus requested emergency connectivity services in a previous message; and / or the appartus did not provide its identifier in a previous message; and / or the 5GS identity type in the request message is set to IMEI or IMEISV. In accordance with a fourteenth aspect of the invention, it is proposed an apparatus, comprising a receiver for receiving a first message from a second device comprising an identifier and an emergency relay service code; a controller adapted for determining whether to (1) store an identifier provided by the second device and / or (2) provide emergency connectivity services to the second device, the first device being authorized to provide emergency connectivity services to the second device, wherein the determining comprises the controller checking whether the identifier is valid by: - validating it against a local database and / or - sending a second message to a network function for validation andreceiving a third message from the network function with the identifier validation. In accordance with a fifteenth aspect of the invention, it is proposed an apparatus configured for discovery ,wherein the direct discovery set that carry the Application Layer IDs of a first device and a second device, are protected separately, wherein the apparatus comprises a transmitter adapted for transmitting a protected discovery message, wherein the first protected direct discovery set is located before the second protected direct discovery set in the protected direct discovery set information element included in the protected discovery message. In accordance with a sixteenth aspect of the invention, it is proposed an apparatus adapted for device to device communication between a first device and the apparatus comprising: a receiver configured for receiving a direct link establishment request message transmitted by the first device containing a relay service code, wherein the relay service code is associated with a Network Assistance Security Indicator indicating a security procedure without network assistance is required, and a controller that determines whether the apparatus is configured with valid long- term credentials, wherein the controller is configured to cause a transmitter to transmit a first PC5 reject message with a failure cause indicating that security procedure without network assistance is unsupported if the apparatus is not configured with valid long-term credentials. In accordance with a seventeenth aspect of the invention, it is proposed an apparatus for device to device communication between a first device and the apparatus, through a second device acting as a relay, comprising: a receiver adapted to receivea direct link establishment request message containing a relay service code associated with a Network Assistance Security Indicator indicating the security procedure without network assistance is required, a controller adapted to determine whether it is configured with valid-long term credentials, wherein the controller is adapted to cause a transmitter for transmitting to the second device a second PC5 reject message indicating that the security procedure without network assistance is unsupported, if no valid long-term credentials are available. In accordance with an eighteenth aspect of the invention, it is proposed an apparatus adapted for multi-hop connectivity services, comprising: a receiver configured for receiving one or more first discovery messages, each first discovery message comprising a relay service code and / or a set of User Info IDs and / or a number of hops, wherein the relay service code indicates the maximum number of hops authorized when providing multi-hop connectivity services, the set of User Info IDs identifies the relaying devices in the multi-hop route, and the number of hops indicates the number of hops in the multi-hop route, and a controller configured for selecting a preferred multi-hop route from the one or more received discovery messages based on one or more of the maximum number of hops indicated by the relay service code and / or the set of User Info IDs and / or the number of hops contained in the one or more received discovery messages. In accordance with a fifth aspect of the invention, it is proposed a computer program product comprising code means for producing the steps of the method of the second and fourth aspects of the invention when run on a computer device. It is noted that the above apparatuses may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet. It shall be understood that the apparatuses and the methods may have similar, corresponding and / or identical preferred embodiments, in particular, as defined in the dependent claims. It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. It is noted that the above apparatuses may be implemented based on discrete hardware circuitry, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet. It shall be understood that the apparatus of claim 1 or 15, the methods of claim 14 and 16, the corresponding computer program product may have similar and / or identical preferred embodiments, in particular, as defined in the dependent claims. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS Fig.1, already described, schematically represents a cellular system in which the invention is implemented; Fig.2 schematically represents a time scale from the point of view of the transmitting UE and the receiving UE; Fig.3 schematically describes a discovery process in a UE-to-UE Relay scenario; Fig.4 schematically describes a procedure for setting up the security of a PC5 communication link in a UE-to-UE Relay scenario; Fig.5 schematically represents another cellular system in which the invention is implemented; Fig.6 schematically represents a cellular system using a multi-hop sidelink configuration; Fig 7. schematically represents a method to establish a secure multi-hop path; Fig.8 schematically represents exemplary procedures for multi-hop (in this example, 2 hops) communication establishment in a cellular system; and Fig.9 is a communication exchange chart schematically representing a procedures for multi- hop communication establishment in a cellular system in accordance with an embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION The various aspects of the invention will be elaborated in the following embodiments. As explained earlier, the embodiments of the invention can be related to various types of wireless communication, and in particular to the connection setup of devices trying to access a wireless network. A typical example is a cellular network, for example a 5G network, possibly including some relay nodes. These relay nodes may be implemented by UEs, such as Sidelink compatible Ues which can operate as relay nodes, or by other types of repeaters. In an exemplary embodiment of the invention, to allow a new connection through this kind of relay, a discovery phase is required where discovery messages may be sent to the relay UE or by the relay UE. One general aim of this particular exemplary embodiment is to increase the protection of such discovery messages. The Technical Specifications TS 33.303 v17.0.0 describe in Section 6.1.3.4.3 the protection of the discovery messages. It lists three types of security used to protect the restricted discovery messages detailed as follows: Firstly, integrity protection may be provided by appending a MIC (Message Identification Code) as in Open Discovery (see subclauses 6.1.3.3.1). The MIC is calculated in the sending UE using a received Discovery User Integrity Key (DUIK) and may either be checked at the receiving UE using the supplied DUIK or at the ProSe Function (Relay node) using the DUIK. Secondly, scrambling protection, which ensures that there is no relationship between the discovery messages sent by a particular UE, i.e. to prevent tracking of a UE over time, may be used. A scrambling keystream is calculated from the Discovery User Scrambling Key (DUSK) and the UTC-based counter associated with the discovery slot (see 6.1.3.4.3.5 for more details on the calculation). Finally, message-specific confidentiality may be provided for confidentiality protection for part of the discovery message. This is used either when several UEs use the same DUSK or if it is desired to obfuscate part of the discovery message from some of the UEs that are allowed to discover the UE. A keystream is calculated from the Discovery User Confidentiality Key (DUCK), the content of the message and the UTC-based counter associated with the discovery slot (see 6.1.3.4.3.6 for more details on the calculation). The security procedures that are applied at the sending and receiving UE are controlled by the ProSe Function by sending the Code-Sending Security Parameters and / or Code-Receiving Security Parameters to the appropriate UE (i.e. the UE shall support all of integrity protection, scrambling and message specific confidentiality). To achieve integrity protection for a ProSe restricted discovery message, either a DUSK or a DUIK needs to be provided. When a DUCK is used to apply message specific confidentiality, a DUIK is required for integrity protection as more than one message is being protected. Examples of combinations of Discovery User Keys according to use case type is provided in Annex G. In this invention, the terms “security keying materials”, “keying materials”, “discovery security parameters” or “security keys / materials”, and “set of keys” are used interchangeably and may refer to the same set of keys (e.g., discovery keys) including DUIK, DUSK, DUCK. At the receiving side, the scrambling protection must be undone before any matching can be attempted. Given that the operation of undoing message-specific confidentiality is computationally intense, the matching operation that precedes it should have a very minimal chance of a false positive. To this end, the ProSe Function should ensure the number of bits in a discovery message that can be matched after any scrambling has been undone is at least 16 (leading to a false positive chance of 1 in 65,536 or less). The technical specification TS 33.503 describes further procedures to protect discovery messages where the discovery messages are featured by a long size. The discovery procedures are also specified in the context of UE to Network relays. The main differences compared with TS 33.303 refer to the usage of scrambling in the first up to 32 bytes, the confidentiality protection of the whole message and the usage of a MIC set to a random value when the message is not integrity protected. Furthermore, TS 33.503 describes in Clause 6.3.5 a procedure for the protection of the direct communication request (DCR) message that is sent by a remote UE to the UE to Network relay whereby the protection mechanisms reuses the discovery keys. When the DUIK is configured, the DCR message is integrity protected. When the DUCK or DUSK are configured, the relay service code (RSC) and PRUK-ID are confidentiality protected. Similar techniques may apply to the establishment of a (secure) PC5 communication link in a UE-to-UE Relay scenario, upon discovery and with reference to Fig.4 where a UE, e.g., the Source- UE may send a direct communication request (DCR) message including certain parameters, such as an RSC or the PRUK ID or a first nonce used for a subsequent key derivation. This information might be exchanged in the clear unless a procedure as in Clause 6.3.5 in TS 33.503 is applied. This procedure and need is further illustrated by means of a Source-UE 420 that wants to establish a secure communication link with a Target-UE 430 over a UE-to-UE Relay 410. The CN or one or more network functions in the CN 400 perform configuration. In a first Step, the Remote UEs (Source and Target-UEs) and the UE-to-UE Relay get the discovery parameters and Prose Key management function (PKMF) address from the 5G DDNMF and the discovery security material from the PKMF respectively. Furthermore, the Remote UEs can be provisioned with the security materials for end-to- end security setup by the PKMF. For example, the security materials for end-to-end security setup include the Prose Service Code (PSC) and associated key. In a subsequent step, the remote UE 420 performs the discovery procedure and PC5 unicast link setup procedure with the UE-to-UE Relay 410 by (i) discovering a UE-to-UE Relay; (ii) sending a Direct Communication Request that includes Relay Service Code (RSC), PRUK ID, and Nonce1; (iii) performing authentication and key agreement between the remote UE 420 and UE-2-UE relay 410 and as result of successful authentication, a key KNRP is derived. Later, the UE-2-UE relay 410 generates Nonce2 and derives KNRP-SESS using KNRP, Nonce1 and Nonce2. The UE-2-UE relay 410 sends a Direct Security Mode Command that contains Nonce 2 to the Remote UE 420. The Direct Security Mode Command is integrity protected based on KNRP-SESS. Then, the Remote UE 410 derives KNRP-SESS using KNRP, Nonce1 and Nonce2 and checks the integrity of the Direct Security Mode Command. If the verification is successful, the Remote UE 420 sends a Direct Security Mode Complete to the UE-2-UE relay 410. To protect certain privacy sensitive fields, or all fields in a DCR message exchange during UE-to-UE Relay, e.g., as detailed in above exemplary procedure, one of the keys in the discovery parameters needs to be selected by the sending device and the receiving device, e.g.: 1. if the DUCK available, the DUCK is to be used to protect those privacy sensitive fields, and 2. if the DUCK is not available AND the DUSK is available, then the DUSK is to be used to protect those, and otherwise, 3. if neither DUCK nor DUSK are available, then privacy sensitive fields, or all fields in the DCR message must not be protected. Once (and if) a key is selected, the sending device can protect the DCR message and transmit the protected DCR message. Once (and if) a key is selected, the receiving device can receive the protected DCR message and securely process it (decrypt / integrity verify). It is to be noted that if the Source-UE and the Target-UE have a set of common discovery keys unknown to the relay, then this set of keys might be preferred. These embodiments are described in the context of UE relays that may allow, e.g., a remote UE that may be out of coverage to connect to the network. This type of relay is called UE to Network relay or U2N relay, etc. The UE relays may also allow two end-UEs to communicate with each other. This type of relay is called UE-to-UE relay or U2U relay, etc. The end-UEs may be denoted source UE and target UE, etc. The different peers of UEs may execute a discovery procedure to discovery each other and / or may send initial communication messages to establish a secure between n ng link. For instance, the remote UE and UE to Network relay may discovery each other and then the remote UE may send a Direct Communication Request to the UE to Network relay. For instance, the UE to UE relay and the two end UEs may want to discovery each other and then one of the end UEs may send a Direct Communication Request to start the establishment of the PC5 communication links. Throughout this disclosure, the following acronyms refer to following respective definitions: KDF: stands for Key Derivation Function. A KDF is for example defined in TS 33.220 v18.0.0 in Appendix B.2. In this example, the KDF of an input bit string S with a key K, i.e., KDF(K,S), may be equivalent to HMAC-SHA-256(K,S) where SHA-256 is the hash function used in the HMAC construction. The bit string S may be constructed as described in TS 33.220 from multiple parameters param1, param2, …, paramN but concatenating those parameters with their assigned length and including a unique identifier denoted FC for the specific usage of the KDF. Sometimes, instead of writing KDF(K,S) it is written KDF(K, param1, param2, …, paramN) where it is to be understood that the bit string S is constructed with the field param1, param2, …, paramN. NEA and NIA: These are Encryption (NEA) and Integrity Algorithms (NIA). In a 5G implementation, these are described in Appendices D.2 and D.3 of TS 33.501. DUSK, DUCK, and DUIK: these refer to respective keys, used respectively for Scrambling, Ciphering and Integrity. In a 5G Discovery embodiments, these refer to the Discovery User Scrambling Key, Discovery User Ciphering Key, and Discovery User Integrity Key, respectively. DP_X-Y: These correspond to some security discovery parameters, for example keying materials used between entities X and Y. e.g., DP_S-UE-to-UE refers to the discovery security parameters associated with the RSC used between Source-UE and UE-to-UE Relay. SCRAMBLING / CONFIDENTIALITY / INTEGRITY PROTECTION ROUTINES FOR DISCOVERY MESSAGES IN UE-to-UE Relay SCENARIOS. In the following embodiments and embodiment variants related to “UE-to-UE” relay use cases are presented in which a source user equipment (UE) device needs or wants to communicate with a Target-UE device over a UE-to-UE Relay device. This UE-to-UE Relay use case involves at least two phases, (secure) discovery and establishment of a (secure) PC5 communication link. These two phases exhibit certain challenges that have been already dealt with in some of the above embodiments. Regarding the (secure) discovery of UEs (Source-UE, UE-to-UE Relay, Target-UE), certain architectural solutions might require “hop-by-hop” and “end-to-end” discovery. For instance, a discovery message (e.g., an announcement discovery message in discovery model A or a solicitation discovery message in discovery model B) sent by the Source-UE and directed to the Target-UE might be (1) firstly protected with discovery parameters bound to the end-to-end communication link between Source-UE and Target-UE, these discovery parameters (DP_S-T) might include a DUIK, DUSK, or DUCK. Then, the discovery message might be (2) secondly protected with discovery parameters (DP_s-UetoUE) bound to the hop-by-hop communication link between Source-UE and UE-to-UE Relay. These parameters might also have a DUIK, a DUSK, and a DUCK. When the UE- to-UE Relay receives the message, the UE-to-UE might process the message where processing involves the security processing of a discovery message using DP_s-UetoUE. After processing, the UE-to-UE Relay can check whether this discovery message is intended for its UE-to-UE Relay services, e.g., by performing a matching action as in TS 33.503. If it is, then it protects the message with the discovery parameters (Dp_UetoUE-T) bound to the hop-by-hop communication link between UE-to-UE Relay and Target-UE. When the Target-UE receives message, the Target-UE might process the message where processing involves (1) the security processing of a discovery message using Dp_UetoUE-T and then (2) the security processing of a discovery message using DP_S-T. In a complementary description, the security procedure for 5G ProSe UE-to-UE Relay discovery Model A is described – referring to Fig.3 – as follows: In Fig.3, Step 340, announcing UE 320 is provisioned with discovery security materials from a network function in the CN 300, e.g., 5G PKMF, by performing a Relay Discovery Key Request procedure. The discovery security materials may comprise two sets of Code-Sending Security Parameters: the Code-Sending Security Parameters associated with a ProSe service and the Code- Sending Security Parameters associated with a Relay Service Code (RSC). In addition, CURRENT_TIME and MAX_OFFSET parameters are included for each set of Code-Sending Security Parameters. In Fig.3, Step 341, ProSe 5G UE-to-UE Relay 310 may be provisioned with discovery security materials from a network function in the CN 300 by performing a Relay Discovery Key Request procedure. The discovery security materials include both Code-Sending Security Parameters and Code-Receiving Security Parameters associated with the RSC. In addition, CURRENT_TIME and MAX_OFFSET parameters may be included for each set of security parameters. In Fig.3, Step 342, the monitoring UE 330 is provisioned with discovery security materials from a network function in the CN 300 by performing a Relay Discovery Key Request procedure. The discovery security materials may comprise two sets of Code-Receiving Security Parameters: the Code-Receiving Security Parameters associated with the ProSe service and the Code-Receiving Security Parameters associated with the RSC. In addition, CURRENT_TIME and MAX_OFFSET parameters are included for each set of security parameters. In Fig.3, Step 350, the Announcing UE can start broadcasting an Announcement message, if the UTC-based counter provided by the system associated with the discovery slot is within the MAX_OFFSET of the Announcing UE’s ProSe clock and if the validity Timer has not expired. The Announcing UE can form an Announcement message and protect the message as follows: it first protects the End-to-End (E2E) ProSe discovery information using the Code-Sending Security Parameters associated with the ProSe service; then, it protects the Announcement message using the Code-Sending Security Parameters associated with the RSC. In Fig.3, Step 360, the ProSe 5G UE-to-UE Relay listens for an Announcement message that matches its Discovery Filter, if the UTC-based counter associated with that discovery slot is within the MAX_OFFSET of the ProSe 5G UE-to-UE Relays ProSe clock. The ProSe 5G UE-to-UE Relay processes a received Announcement message to find a matching message to its Discovery Filter. When the ProSe 5G UE-to-UE Relay processes the message, it undoes the protection of the received message using the Code-Receiving Security Parameters associated with the RSC. Upon identifying a matching message, the ProSe 5G UE-to-UE Relay forms a Relayed Announcement message containing the original Announcement message and protects the Relayed Announcement message using the Code-Sending Security Parameters associated with the RSC. Then, the ProSe 5G UE-to-UE Relay starts broadcasting the Relayed Announcement message. The 5G ProSe UE-to-UE Relay may store the Relayed Announcement message set along with its validity time. A Relayed Announcement message may be removed once its validity time has expired. The validity time is determined from the UTC-based counter associated to the received direct discovery set that works as a timestamp. The Relayed Announcement message remains valid as long as the 5G ProSe UE-to-UE Relay and Monitoring 5G ProSe End UE estimates the same UTC-based counter used by the Announcing ProSe End UE. In Fig.3, Step 370, the Monitoring UE listens for a Relayed Announcement message from ProSe 5G UE-to-UE Relay. The Monitoring UE processes a received Relayed Announcement message to find a matching message to its Discovery Filter. When the Monitoring UE processes the message, it first undoes the protection of the message using the Code-Receiving Security Parameters associated with the RSC, and further undoes the protection of the E2E ProSe discovery information using the Code-Receiving Security Parameters associated with the ProSe service. In Fig.3, message in Step 350 may include the Type of Discovery Message, Discoverer Info, RSC and E2E discovery information in the solicitation message In Fig.3, message in Step 360 may include the Type of Discovery Message, Discoverer Info (i.e. Relay User Info ID), RSC, Relay indication (to indicate ProSe direct discovery forwarding), original Discoverer Info (i.e. source 5G ProSe U2U UE User Info ID) and E2E discovery information. Thus, message in Step 360 includes additional information including the Discoverer Info, i.e. Relay User Info ID, and a Relay indication. In model A discovery, the Source-UE might be called an announcing UE and the Target-UE might be a monitoring UE or vice versa. In model B discovery, the Source-UE might be called a discoverer UE and the Target-UE might be a discovery UE. In model B discovery, the message flow is as in Fig.3 where messages 350 and 360 correspond to solicitation and relayed solicitation messages with additional messages replied by 330 towards 320 over 310 corresponding to response and relayed response messages. Section: time-counter reconciliation In the following embodiments of the invention, for integer a and positive integer B, we denotewith < • >• the remainder of dividing a by B. That is, < • >• is in the set {0,1,…,B—1}, and • =< • >•+ •• for some integer q. In a particular case, • = 2•. The source or sending UE S sends amessage to a relay device R, e.g., a UE to UE relay, a UE to Network relay, or a mobile access device such as a satellite, UAV, or vehicle-mounted base station, together with the value < •• is the time or a time-based counter at which S sent its message. If • = 2•, then < ••>•corresponds to the • least significant bits of ••. After some delay, e.g., caused by the storage of the message at the relay, the relay sends to the target T the message and < ••>•. The target T receives the information from R at its (own) timestamp ••. The target wishes to retrieve ••from < ••>•and••It is to be noted that in some cases the communication between S and T may be direct but the transmission time may be comparable or greater than the time or time-based counter. This may be the case in circumstances in which the message needs to travel a very long distance, e.g., if a message is relayed by a transparent satellite working as a reflector or if a message is exchanged over a very long distance, e.g., in a communication link between earth and moon. We write ••= ••+ ••+ •, where ••is the synchronization error between the clocks of S and T, and • is the delay incurred at R or due to the communication delay. We consider that • • 0 and that the positiveintegers s and • are such that•• • •• • • ••• 0 • • • •.Then device T knows that •• = •• • •• • • • •• • • • •, and that •• = •• • •• • • • •• +•. In other words, T knows that2023P00654WO 23.09.2024•• • {•• • • • •, •• • • • • + 1, … , •• + • • 1, •• + •}.This is illustrated by means of Fig.2 (bottom) that represents the timeline from the point of view of the receiving / target device. Fig.2 (top) represents the timeline from the point of view of the sending / transmitting device indicating when the message is transmitted and how long the message canremain valid. The above set consists of 2• + • + 1 consecutive integers. The target T knows <>•; hence, if 2• + • + 1 • •, then T can retrieve •• from >• and ••. This retrieval can berealized in multiple ways, for instance: Option 1• = •• • • • ••• = < • >• •••••• (•+< •• >•• ••)•••••••••• (•+ < •• >•• •• + •)Option 2• = •• • • • ••• = < • >• •• < • > < ••• •••• = ••• + ••••••• •1• The logic behind both options is to obtain • being the oldest possible time. Thenobtain the •’, the b LSBs of •. If the received value < ••>•is greater than •’, then it is only needed toadd the difference between < •• >• and •’ to • to obtain ••. If the received value < •• >• is less than•’, then it is needed to additionally add •.Still another option 3 is to formula (2) below or an implementation of it, e.g. • = •• +•; •• = • + •• • •••••••.Still another option is to list the 2• + • + 1 possible values of ••• • {•• • • • •, •• • • •• + 1, … , •• + • • 1, •• + •} and try for each of them whether < ••• >• equals the received < •• >•.For example, take B=16, s=4 and • = 7. Then •• • •• • {•11, •10, … ,4}, that is, •• • {•• •11, •• • 10, .. , •• + 4}. There are thus 16 options for As T knows ••, it knows these 16 options.As it knows < ••>••, it knows which from these 16 options it has to pick. An explicit formula to find is obtained as follows. Let •, •, • be positive integers suchthat:2• + • + 1 • •. (1)Let ••, •• be integers such that •• • {•• • • • •, •• • • • • + 1, … . , •• + • • 1, •• +•}. Then: To show the correctness of (2), let •• denote the right-hand side of (**). As 0 • < • >• •• • 1 for each integer •, it follows that •• • •• + • and •• • •• + • • (• • 1) • •• • • • •, wherewe used (1) to obtain the final inequality. So •• is in the correct interval. Moreover, as < • >••• (••• •) for each integer m, it follows that The above idea describes how a receiving target device T can recover the transmission time counter ••of the sending device S. However the relay device R may also need to retrieve the thetransmission time counter •• given its own time •• when receiving the message. In this case, •• =•• • •• • •• • •, and that •• = •• • •• • •• + •. In other words, the relay device R knows that:•• • {•• • •, •• • • + 1, … , •• + • • 1, •• + •}.This is because there is not intermediate device and • = 0. This is illustrated by means of Fig.2, middle, where it is possible to observe a small time difference between the timings of transmitting device and relay device. The relay device R can then determine ••from < ••>•and ••. For instance, Option 2 above can beadapted as follows:• = •• • ••• = < • >•• <•• >••= << •• >•>•••• = • •• + < •• >••• ••• < •• >•• < ••2023P00654WO 23.09.2024••• = ••• + 2••••••• •1•In this case, •’ is obtained as c module 2• because the timer error has a total range of 2• + 1, and 2• is close and can be made a power of two. Thus, the above process allows correcting the errors when •• < ••• • and both s and B are powers of 2. By applying above procedure or a similar one derived from above analysis, the relay device R can determine the transmission time of the sending / transmitting device. In another option, the relay device R can then determine ••from < ••>•and ••knowing thatthere was no additional storage time, i.e., • = 0. This may be done as follows:• = •• • ••• = < • >••• = • + < • •• • >•• ••• < •• >• < •••• •• = •• + ••••••• •1•Once the relay has determined ••, the relay can determine also the exact expiration time, i.e., when the message is to be removed. The storage time and / or maximum transmission delay is •~ B – 2s = 2• • 2••• whenB = 2• and • = 2•.In above description, it is assumed that ••refers to the transmission time of the source / transmitting device / UE. However, ••may refer to the transmission time plus the maximum storage time and synchronization error. This is illustrated as ••••in Fig.2 top. This time then refers tothe highest possible value of the final validity time of the message including the parameter •, i.e., •• +• + •. In this case, the relay UE may then be able to recover •••• in a similar way as in previous cases,e.g., by computing:• = •• + • + ••• = < • >••• = • • •• (< •• >•• • )•• < • •• >• < ••• = •• •• • ••••••• •1•In this case, the returned value •••indicates directly the validity time. This may require removing the parameter •. In some cases, the transmitting UE may also encode and transmit < ••>•of any time ••between ••. and ••••as per Fig.2. However, in this case, if the transmitting UE encodes ••= ••••but the relay device does not store, the receiving UE will have a time much lower than the encoded value. The difference will be roughly ••• ••~•. On the contrary, if the transmitting UE encodes ••= but the relay device does store, the receiving UE will have a time much lower than the encoded value. The difference will be roughly ••• ••~ • •. This means that the range of potential values is larger,and thus, B should be greater to be able to discern the difference, in particular, greater than or equal to2• + 2• + 1.In some cases, the receiving device (e.g., relay UE or target UE) will accept the message as long as the MIC verification succeeds and its local time (t2in the case of the target UE or t3in the case of the relay UE) is less than the recovered ••••(in general, ••) plus, optionally, a small time window. A reasonable value for this time window is • = 2 • •••_••••••. Other variations of the processes are feasible, e.g., when the time transmitted by the sending / source UE is + •, or in general, the current time of the sending / source UE plus the time T the message should remain valid where this time T together with the parameter s determines the amount of bits of the time counter that need to be transmitted to ensure that both relay device and receiving / target device / UE are capable of recovering the time of the transmitter. An advantage of this specific variant is that the transmitting / source UE can specify any validity time for the message to be transmitted while minimizing the amount of data to be transmitted. It is to be noted that the above expressions indicate that the time counters of the devices may differ up to s time units. In some cases or scenarios, a device such as UE may receive the current time Tnwkand a MAX_OFFSET from a core network, and the UE may consider its own time Tlocal as valid if the absolute time difference between Tnwkand Tlocalis less than MAX_OFFSET. This aims at ensuring that the clocks of the devices are closely synchronized. It is to be noted that this implies that two UEs may have a time difference between their respectives local times of up to two times the MAX_OFFSET. Thus, in related embodiment variants, the parameter s defined above may be chosen to be 2* MAX_OFFSET. For instance, if the exhaustive test runs b–tween - MAX_OFFSET and MAX_OFFSET for both counters, then no errors are made. If s = 4, then an exhaustive test runs between -2 and 2, so the total error can be -4, -3, -2,…0, 1, 2, 3, 4. And then the storage time can be up to 7. In the case of the discovery messages used in Proximity Services, e.g., UE-to-UE relay use cases as described above, the parameter • may be related to the MAX_OFFSET parameter. Thus, if the relayed direct discovery set, i.e., the Relayed Announcement message needs to remain valid for up to • seconds, then sending / source UE needs to send the•••••(• + •••_••••••)•least significant bits of its UTC-based counter where ••• returns the integer part of • rounded upwards. In the case of the discovery messages used in Proximity Services, e.g., UE-to-UE relay use cases as described above, a network function or the application may configure the maximum transmission delay / storage time in the devices. This configuration may be explicit or implicit. Explicit if • is configured. Implicit if • and • are configured. In the above description, e.g., Option 1 and Option 2, the receiving / target device needs to substract a value dependent on +• and • , e.g., • + •. This value may be configurable. In some cases, it is advantageous if • + • or 2• + • is a power of two. In this case, the receiving / target device can count the number of bits • used to encode the received LSBs of the UTC-based counter and obtain • by substracting 2•• • to its time ••. Similarly, a relay device may derive the maximum storage time by counting the number of bits bits • used to encode the received LSBs of the UTC-based counter and computing 2•or 2•• •. In a particular implementation, a sending UE has an n bit long UTC counter ••. An end receiving UE has an n bit long UTC counter ••. A relay UE has an n bit long UTC counter ••. A receiving UE or relay UE recover the UTC counter of the sending UE given ••or ••and < ••>••,the b least significant bits of •• as follows under the assumption that •• and •• (or ••) differ up to• = 2 • •••_•••••• time units and a relay device may store the message up to • seconds:A relay UE sets ••to ••and an end receiving UE sets ••to ••. Arelay UE sets • to 0 and an end receiving UE sets • to 2• • 2•.• = •• • 2 • •••_•••••• • ••• = < • >•• •• < •• > ••• < ••• = • •• •• + 2•••••• ••• The above processes allow performing time reconciliation when the parameters and time difference is small enough. However, if for any reason the time difference increases, the processes may in some cases properly perform time reconciliation while in others they cannot. For instance, when • = 2•= 16, and • = 4, at time 489, for a synchronization error at the transmitter of -3. And a synchronization error at the receiver of 2, storage_time=0, the actual time at the transmitter is 486 while the receiver obtains 502. This is because the difference between the synchronization error differences is 5 > s. We observe that the recovered value differs by 16 = B. This leads to another configuration in which the receiving device may recover the time value (in above example 502), and use the time value in combination with a cryptographic function, e.g., a cryptographic function to compute a message integrity code, e.g., by applying a key derivation function having as input a key (e.g., DUIK) and the recovered time. If the computed MIC does not match the MIC received in the message that included or referred to the least significant bits of the time counter, the receiving UE may try again to obtain another time value by adding or removing multiples of B. In previous example, it may remove B=16 to obtain 486. The receiving UE may then apply again the recovered time to a cryptographic function and check whether the result is positive, e.g., whether the MIC value matches. The receiving UE may perform this variant of the process based on a policy. The receiving UE may also perform this process a maximum number of times. In some situations, the process may be implemented in a different way. For instance, the receiving device may need to try out multiple potential (UTC-based) counter values, e.g., in the set of potential counter values as described above. Note, that in the case of UE-to-UE relay, the UE- to-UE relay may know whether the estimated counter is correct by checking whether the match after descrambling (as specified in TS 33.303) is correct or checking whether, e.g., the matching after scrambling or decryption succeeds or by checking whether the MIC verification succeeds. In some situations, the process may estimate potential (UTC-based) counters by: - taking the most significant bits of the local (UTC-based) counter and replacing the least significant bits with the received least significant bits of the transmitting UE; - taking the most significant bits of the local (UTC-based) counter and adding one, two,three,... and replacing the least significant bits with the received least significant bits of the transmitting UE; - taking the most significant bits of the local (UTC-based) counter and subtracting one, two, three,... and replacing the least significant bits with the received least significant bits of the transmitting UE. Which of the estimated UTC-based counters is correct is determined by checking whether, e.g., the matching after scrambling or decryption succeeds or by checking whether the MIC verification succeeds. It is to be noted that this approach and other approaches based on trial and error may allow recovering the UTC-based counter, even if quite some time has elapsed. For instance, if a receiving UE has a counter 00101111 and the sending UE has (UTC-based) counter 00000010, we can observe that 101101 time units have elapsed. The receiving UE may be able to reconcile / recover the sending UE (UTC-based counter) by replacing the received b LSBs (e.g., 0010 if b=4) into its UTC-based counter, and tweaking the most significant bits and trying one or more of the potential values to perform the unscrambling and / or MIC check as per TS 33.303 and TS 33.503. If those checks pass, then the estimated (UTC-based) counter succeeds. For instance, this approach can be applied to the construction of the UTC-based counters by a UE when performing a Match report since TS 24.554, Clause 6.2.8.2 describes a procedure in which a UTC-based counter is re-constructed by a UE by replacing the 4 LSBs of the own UTC-based counter the 4 LSBs contained in the PROSE PC5 Discovery message. This approach may lead to an error because of a bit overflow, and thus, the re- construction may also modify the most significant bits as indicated above. Note also that to check that the value is within a given time window with respect to the time of the receiving UE, the receiving UE may consider the least significant bits, e.g., the b = 4 LSBs, of the UTC-based counter of the receiving UE. Note however that in such approaches, it may be efficient to apply a further embodiment in which the receiving UE, or another entity in its behalf, upon reconciliation / estimation of the UTC- based counter of the transmitting UE, the receiving UE verifies that the estimated / reconciled time is within a given time window with respect to the time of the receiving UE, e.g., time_receiving_UE – reconciled_time_transmitting_UE < Threshold where the Threshold may be based on configuration / policy, e.g., Threshold may be 2^b or 2^b – synchronization error or 2^b – synchronization error or just a configuration value, e.g., 4 reflecting the maximum synchronization error. Otherwise, even if the same UTC-based counter of the transmitting UE is recovered / estimated / reconciled in such a way that the MIC check succeeds, the UTC-based counter may be too “old” and represent an expired / non-valid message. This Threshold check may be applicable to the processing of TS 24.554, Clause 6.2.8.2 because the estimated UTC- based counter is re-constructed by the UE by replacing the 4 LSBs of the own UTC-based counter with the 4 LSBs contained in the PROSE PC5 Discovery message and it is done without checking whether the estimated UTC-based counter is has a higher or a lower value than the current one, for instance, even if the MSBs of the UTC-based counter of the transmitting UE and the receiving UE are equal, the LSBs of the transmitting UE and the receiving UE may be 0000 and 1111, so that the time difference is too high, and thus, non-allowed. The above idea describes an approach to enable a target UE or receiving device T to determine the time of the sending / source device S, e.g., a source UE taking into account the storage requirements of the relay device R and / or the transmission delay. This approach allows achieving the maximum possible storage and / or enduring the longest possible delay with the smallest possible transmission overhead. Another application scenario refers to the construction of the UTC-based counters by a UE when performing a Match report. TS 24.554, Clause 6.2.8.2 describes a procedure in which a UTC- based counter is re-constructed by a UE by replacing the 4 LSBs of the own UTC-based counter the 4 LSBs contained in the PROSE PC5 Discovery message. However, as already pointed out, this can lead to a wrongly generated counter because of a bit overflow from the 4 LSBs to the most significant bits. Thus, such a procedure also benefits from the application of the counter reconciliation procedures described in previous embodiments. Another application scenario for the techniques of this invention relates to Ambient IoT where a tag may send a message to another device (e.g., another tag, a relay UE, or other type of relay device) that may store said message for a certain amount of time. Ambient IoT tags have a very limited energy budget so it is desired that the amount of transmitted data is kept at a minimum, and thus, it is desirable that the receiving UE is capable to recover the transmission time of the transmitting device tag without errors for the longest possible period of time given the b least significant bits of time counter ••. Another application scenario refers to the synchronization of a UE to an access device wherein the synchronization is performed with respect to a given frame structure of a given duration. For instance, we may consider a frame structure such as the System Frame Number (SFN) counter used in 5G networks to keep track of the current radio frame. A UE may use it to determine when the receive or transmit data such as uplink or downlink messages or a paging message. In 5G, the SFN range is from 0 to 1023, meaning that the SFN can take on 1024 different values. After reaching the maximum value, the SFN rolls over and starts again from 0. An SFN frame has a duration of 10 ms, so that the SFN rolls over every 10.24 seconds. Instead of such a short counter, we may consider a more extensive counter, e.g., 20 or 30 or more bits long to enable, e.g. periodic communications over a longer period of time or with higher accuracy, e.g., an accuracy of 1 millisecond. However, instead of having to exchange the 30 bits, it may be feasible to only exchange, e.g., 10 bits, if the counter are bound to a time value so that the devices are capable of getting an initial estimate from the locally known time value. Another application refers to non-terrestrial networks when an access device (e.g., satellite) transmits a counter value that is received by wireless devices with a variable delay due to the propagation delay. Another application refers to the handling of NAS COUNT and NAS sequence number as specified in Clause 4.4.3. of TS 24.501. 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, shown on Fig.5. A cell of the network is served by a primary station 1000. Under the coverage of the primary station 1000 (e.g. a gNB), a plurality of secondary stations can connect to the primary station. Some secondary station may be adapted to operate as relay stations 1010. Such a relay station may comprise a transmitter 1011, coupled with a transmit antenna, a receiver 1012 coupled with a receive antenna. Typically, the receive and transmit antenna are the same antenna. Further, depending on the technology, the antenna may be formed by an antenna array which may allow different transmission / reception modes, such as MIMO, transmit diversity, and operation on different sets of frequencies. A controller 1013, for example a CPU or microcontroller (such as a microprocessor dedicated for the communication (baseband processor) or a main microprocessor of the device including the UE) operating with a software stored on an internal memory (e.g. ROM, EEPROM, SSD) is adapted to control the transmitter and the receiver and control the antennas. It is to be noted that some or all of the transmitter, the receiver and the 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 for receiving in at least one first secure message from the primary station 1000 a first set of configuration parameters including attributes or service codes The controller 1013 can control the transmitter 1011 and cause it to transmit at least one transmitted attribute or service code from the first set of configuration parameters. This attribute or service code can be broadcast for reception by other stations, for example like secondary station 1020 or 1030. Typically, the relay station may be a UE, like a Sidelink compatible UE, which thus can behave as a relay station when configured to. Alternatively, the relay station may also be another primary station, like an Access Point, or a gNB or a femtocell gNB. The secondary station 1020 (or similary 1030) may typically be a UE, and comprises a transmitter 1021, a receiver 1022, both typically coupled to one or more antennas or antenna array. Further, the secondary station 1020 includes a controller 1023 which is adapted to control the receiver 1021, the transmitter 1022 and possibly other elements of the UEs. As for the relay station, the controller 1023 may be a processor or a CPU, and may operate thanks to a software. The controller 1023 is able to cause the receiver 1021 and the transmitter 1022 to establish a connection with the primary station 1000. This includes for example configuring the receiver 1021 for receiving from the primary station 1000 in at least one second secure message a second set of configuration parameters including attributes or relay service codes linked to an upcoming data exchange with the relay station 1010. The receiver 1021 may be adapted for receiving at least one transmitted attribute or service code from the relay station 1010 and the controller may be configured for determining whether the transmitted attribute or service code is included in the second set of configuration parameters or fulfil a policy in it and causing the transmitter to establish a direct communication with the relay station 1010 upon determination that the transmitted service code is included in the second set. The secondary stations 1020 and 1030 may also be able to communicate with each other by means of relay station 1010. A single unit or device 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 described operations like those indicated in the different figures, e.g., Fig.3 and Fig.4, can be implemented as program code by means of a computer program and / or as dedicated hardware of the related communication device or access device, respectively. The 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. Section: UE Identifiers used in UE-to-UE discovery In some scenarios, a UE (e.g.5G ProSe End UE or 5G ProSe UE-to-UE Relay) is provisioned with two sets of security materials, i.e. one for protecting information exchanged during ProSe Direct Discovery and one for protecting UE-to-UE Relay Discovery. The first set of security materials may be Code-Receiving Security Parameters associated with a ProSe service / ProSe application (that may enable Direct Communication over PC5 and that may be announced via ProSe Direct Discovery) and may be used for protecting information used / configured for ProSe Direct Discovery (i.e. a so-called Direct Discovery Set that may contain e.g. User Info IDs of the respective UEs involved) in an end-to- end manner, whereby end-to-end means that the protected information as transmitted by an End UE may be transmitted via / forwarded by one or more UE-to-UE relay devices to another End UE in such manner that the UE-to-UE relay device(s) may not be able to decrypt such Direct Discovery Set. The second set of security materials may be Code-Receiving Security Parameters used for UE-to-UE relay communication (e.g. associated with an RSC), and may be used for protecting information used / configured for ProSe UE-to-UE Relay Discovery (i.e. a so-called UE-to-UE Relay Discovery Set that may contain e.g. User Info ID of the respective UE-to-UE relay device(s) involved). If the Direct Discovery Set contains identifiers (e.g. User Info IDs) to identify the End UEs in UE-to-UE Relay communication, then as indicated in 3GPP Document if the UE-to-UE relay is not able to decrypt the Direct Discovery Set, the UE-to-UE relay is not able to forward / transmit a discovery message from an End UE acting as a discoverer to a particular End UE acting as a discoveree, and hence UE-to-UE Relay discovery does not function properly. In order to solve this problem, in an embodiment that can be combined with other embodiments or implemented independently, the End UEs need to be adapted / configured (e.g. by receiving a policy from a core network function, such as AMF or PCF) to use a set of identifiers (e.g. User Info IDs) for Direct Discovery / Direct Communication (i.e. to be used in the Direct Discovery Set) to identify the End UEs that is different from the set of identifiers (e.g. User Info IDs) for UE-to- UE Relay Discovery (i.e. to be used in the UE-to-UE Relay Discovery Set). In order to identify a particular End UE during UE-to-UE relay discovery, a first identifier (e.g. User Info ID) of that particular End UE as configured for use in the Direct Discovery Set is included in the Direct Discovery set and protected using the first set of security material provisioned for protecting the information exchanged during ProSe Direct Discovery, and a second identifier (e.g. User Info ID) of that same particular End UE as configured for use in the UE-to-UE Relay Discovery Set is included in the UE-to-UE Relay Discovery set and protected using the second set of security material provisioned for protecting the information exchanged during UE-to-UE Relay Discovery, whereby both the Direct Discovery Set and the UE-to-UE Relay Discovery set may be included in the same ProSe discovery message. In a related embodiment variant, the End UEs may be configured to verify that the provided set of identifiers (e.g. User Info IDs) for Direct Discovery / Direct Communication (i.e. to be used in the Direct Discovery Set) to identify the End UEs is different from the set of identifiers (e.g. User Info IDs) for UE-to-UE Relay Discovery (i.e. to be used in the UE-to-UE Relay Discovery Set). In a related embodiment variant, a core network function, such as AMF or PCF or PKMF or DDNMF is configured to verify and distribute a set of identifiers (e.g. User Info IDs) for Direct Discovery / Direct Communication (i.e. to be used in the Direct Discovery Set) to identify the End UEs is different from the set of identifiers (e.g. User Info IDs) for UE-to-UE Relay Discovery (i.e. to be used in the UE-to-UE Relay Discovery Set). This may also require indicating to an AF this need and / or verifying the received identifiers from an AF. In a related embodiment that can be combined with other embodiments or implemented independently, the Layer-2 identifiers that are used / configured for ProSe Direct Discovery are also included in the Direct Discovery Set and protected using the first set of security material provisioned for protecting the information exchanged during ProSe Direct Discovery or using a third set of security material (that may be configured for the particular purpose of protecting the Layer-2 identifiers). This has the benefit that after decrypting the Direct Discovery Set (i.e. using the first and / or third set of security material) the ProSe Direct Discovery procedures can be used in the same manner as if no UE-to-UE relay would have been involved since the same identifiers have been used throughout. To this end, the receiving End UE may have to provide the decrypted Layer-2 identifiers to the MAC layer of the UE and / or construct a direct discovery message based on the decrypted Layer-2 identifiers and encrypted or decrypted other information of the Direct Discovery Set before further processing the direct discovery message. It is to be noted that an advantage of using User Info ID of discoverer and discoveree for UE- to-UE Relay Discovery instead of other type of identifier such as the Layer-2 ID is that the Layer-2 ID may rotate while the User Info IDs is usually more stable. This can facilitate later extensions for multi-hop discovery wherein the User Info IDs would be the addresses of the end points in a multi- hop route. Section: Usage of announcement prohibited indication In UE-to-UE discovery model A, an End UE may indicate that it prohibits (does not want) an announcement which includes the direct discovery set e.g., from a previous discovery solicitation / response message to be further broadcasted. This happens after SA2 agreement in S2- 2311606 with agreed 23.304 CR#0376 introducing "Announce Prohibited Indication" as in CR0376. In CR0376, the "Announce Prohibited Indication" is optionally included in the U2U Relay Discovery Solicitation / Response messages (Discovery model B) to indicate that a U2U relay can not include a Direct Discovery Set in discovery announcement messages model A. This is however challenging because of multiple reasons. First, the contents of the direct discovery sets are end-to-end protected between the end UEs so that the UE-to-UE relay does not have access to the identities (User Info IDs / Application Layer IDs) of the end UEs. Thus, it is challenging to determine which Direct Discovery Sets may be announced and which ones may not be announced. This is particularly challenging if both the Discoverer UE (sending UE) sending the Discovery model B Solicitation message and the Discoveree UE (receiving UE) receiving the Discovery model B S Solicitation message and sending the Discovery model B S Response message back to the Discoverer may include the "Announce Prohibited Indication" field in the respective Solicitation / Response messages. Thus, an aim of this invention is to address this problem. This situation is illustrated as follows with [Tx] being the sending UE (Discoverer End UE); [R] being the UE-to-UE relay; [Rx] being the receiving UE (Discoveree End UE); D_1 and D_2 being the Solicitation messages sent by [Tx] to [R] and by [R] to [Rx], respectively; and D_3 and D_4 being the Response messages sent by [Rx] to [R] and by [R] to [Tx], respectively: [Tx] –> D_1 –> [R] –> D_2 –> [Rx] [Tx] < – D_4 <– [R] <– D_3 <– [Rx] In this situation, · Message D_1 is sent by [Tx] to [R] and includes the direct discovery set, optionally the User Info ID of [Tx], and / or its optionally self-assigned L2 address as Source L2 ID and / or a default Destination L2 address for Relay as well as the Tx "Announce Prohibited Indication", Tx_API. · Message D_2 is sent by [R] to [Rx] and includes the direct discovery set, the User Info ID of [R], and its L2 address o if it self assigns an L2 ID, it may keep a mapping between this self-assigned L2 ID and either the User Info of [Tx], if included in D_1, or the Source L2 ID of the discoverer to link / associate the discovery solicitation message in D_1 to the one transmitted in D_2 and discovery response received in message D_3. o In some cases, it may (re-)use that Destination L2 ID set by the discoverer in D_1 as a Source L2 ID in D_2. However, this option is prone to collisions, given that the same default Destination L2 ID may be received from different Discoverer End UEs. · Message D_3 is sent by [Rx] to [R] and includes the direct discovery set, optionally the User Info ID of [Rx], and optionally its self assigned L2 address as Source L2 ID, and the Rx “Announce Prohibited Indication” (Rx_API), whereas the Destination L2 address for the Relay can be configured / set to the one received in message D_2 (as self-assigned by the Relay and configured / set to be used as Source L2 ID) o Using the mapping built before transmitting D_2, the Relay [R] can associate messages D_1 to D_3 and thus take a decision based on the respective prohibited announce indications received in D_1 and D_3, on whether the Direct Discovery Set (DDS) received in D_3 may be announced in a Model A discovery procedure or not. · Message D_4 is sent by [R] to [Tx] and includes the direct discovery set, the User Info ID of [R], and / or its self-assigned L2 address (i.e., Source L2 address) set to a self-generated L2 ID, and set the Destination L2 ID to the Discoverer L2 ID received in D_1, that may enable the Discoverer End UE to map message D_1 to D_4. Thus, to successfully map (a) D_1 and the indicated Tx “announcement prohibited indication” that may be included within it to (b) D_3 and the indicated Rx “announcement prohibited indication” that may be included within it, it is mandatory that the Relay self-assigns a unique layer 2 address (R_L2ID). The self-assigned layer 2 address used by [R] in D_2 should be mapped to the received source layer 2 address from [Tx] in D_1 (Tx_L2ID) and / or the User Info ID of [Tx] in D_1 (Tx_UIID). Then [R] sends D_2 with its self-assigned L2 address for this message set at Source layer 2 ID. In its response, [Rx] i.e., Target Discoveree End UE, may self-assign an L2 address (Rx_L2ID) and / or transmit its User Info ID (Rx_UIID) and sets the Destination layer 2 address to the layer 2 address of [R] as received in D_2, i.e., R_L2ID. Hence, when D_3 is received by the Relay [R], the Relay [R] can create a mapping between the Source Layer 2 address in D_1 which belongs to Tx, the self-assigned source L2 address set by [R] in D_2, and the source layer 2 address in D_3 which belongs to Rx, [Tx_L2ID -- R_L2ID -- Rx_L2ID] And / or User Info IDs [Tx_UIID -- R_L2ID -- Rx_UIID] thus linking D_1 and D_3 and allowing the Relay to check the respective Announce prohibited indications indicated in these messages and decide on that basis. It is to be noted the "Announce Prohibited Indication" (Tx_API) included in D_1 by [Tx] and "Announce Prohibited Indication" (Rx_API) included in D_3 by [Rx] may be part of the mapping. In particular, in an embodiment that may be used independently or combined with other embodiments, the mapping kept by [R] is [Tx_API, Rx_API, R_L2ID] Thus, relay [R] knows whether the direct discovery set exchanged in D_1 and D_3 may be announced in a further announcement discovery message if neither Tx_API nor Rx_API in [Tx_API, Rx_API, R_L2ID] are set, or if they indicate non-prohibition in Announcement prohibition indication i.e., the indication is set to “It is not prohibited to broadcast the User Info”. It is to be noted since the direct discovery sets in D_1 and D_3 may be essentially the same, thus, in a further embodiment, only one of the direct discovery sets may be stored and further announced, e.g., the direct discovery set in D_3 may be stored and announced only when the above check succeeds, i.e., message if neither Tx_API nor Rx_API in [Tx_API, Rx_API, R_L2ID] are set. It is to be noted that some embodiments have been described using (a unique self-assigned) relay [R] layer 2 address. However, the relay may also include any other (unique / self-assigned) identifier in the discovery message D_2 and the receiving UE [Rx] may send it back in discovery message D_3 to map D_1 / D_2 and D_3. Such identifier can be used to create the mapping as well. For instance, the (unique / self-assigned) identifier in D_2 may refer to some bits in discovery message D_2, e.g., k bits of the MIC in D_2 or the encrypted RSC in D_2. These k bits may be then send back in D_3 and be used to create the map. It is to be noted that this can be advantageous because otherwise, having a unique / self-addressed L2 address per D_2 / D_3 message interaction may contradict other requirements such as having a unique / self-addressed L2 address per RSC as a way to determine the keys to be used to security process e.g., a subsequent DCR or Direct Communication Security Request (DCSR) message. Additionally and / or alternatively, when the relay [R] selects a unique / self-selected layer 2 address for a given message exchange D_2 / D_3 as explained in multiple embodiments, the relay [R] may need to store the mapping of that layer 2 address with the RSC. Since multiple message exchanges D_2 / D_3 may be exchanged for the same RSC with multiple devices, the relay may need to store a one to many mapping of RSC to Layer 2 addresses (i.e., the same RSC may be mapped to multiple layer 2 addresses) in order to identify the discovery keys to be used to security process a received DCR / DCSR message including a protected RSC and PRUK-ID. In an embodiment, an End UE may not include an announcement prohibited indication in the discovery solicitation / response message, in which case, the Relay considers that the End UE does not prohibit the Relay from Announcing the DDS which includes its User Info e.g., Application Layer ID. In an embodiment, the UE-to-UE relay only stores the direct discovery set received in the UE-to-UE relay discovery response message if both APIs (i.e., Tx_API, and Rx_API) associated with the relay’s layer-2 ID (i.e., R_L2ID) are set to “it is not prohibited to announce the User Info”, otherwise the UE-to-UE relay ignores the direct discovery set. Furthermore, to preserve privacy and ensure non linkability, It is advantageous if the Relay [R] self- assigns unique / different Layer 2 addresses per discovery message in D_2 and / or D_4, but it is not mandatory that [Tx] and [Rx] self-assign unique Layer 2 addresses in D_1 and D_3 since those messages may include the User Info IDs, which are sent protected. Thus, in an embodiment that may be used independently or combined with other embodiments, when [Tx] and / or [Rx] do not self-assign unique L2 addresses, the mapping at [R] for the UE ([Tx] and / or [Rx]) would be based on User Info IDs of [Tx] and / or [Rx] (if [R] has the security keys to decrypt the User Info IDs) or the payload (or the MIC or length) of the encrypted direct discovery set or part thereof (if [R] does not have the security keys to decrypt the User Info ID) and self-assigned L2 Address of [R] in D_2 or D_4. In an further embodiment that may be used independently or combined with other embodiments, when [Tx] and / or [Rx] do self-assign unique L2 addresses, the mapping at [R] for the UE ([Tx] and / or [Rx]) is the self-assigned L2 address of [Tx] and / or [Rx] and the self-assigned L2 Address of [R] in D_2 or D_4. It is to be noted that the User Info ID used in a direct discovery set may be a RPAUID, Restricted ProSe App User ID. In accordance with a more general definition of above embodiments, it is described a method and apparatus that may be implemented in a UE-to-UE relay for determining whether the UE-to-UE relay is allowed to announce a direct discovery set and whereby the apparatus is adapted to: · receive a first discovery message from a sending UE that includes a direct discovery set and may include a first "Announce Prohibited Indication" (Tx_API) and may include the User Info ID Tx_UIID of the sending UE or a unique self-assigned layer 2 address Tx_L2ID, · self-select a unique layer 2 address R_L2ID, · construct partial map o [Tx_API, Tx_UIID, R_L2ID] or o [Tx_API, Tx_L2ID, R_L2ID] or o [Tx_API, R_L2ID], · constructs a second discovery message including the direct discovery set and the self-selected unique layer 2 address R_L2ID, · transmits the second discovery message to a receiving UE · receives a third discovery message from the receiving UE including a direct discovery set, and R_L2ID as destination address, and may include a second "Announce Prohibited Indication" (Rx_API) and may include either the User Info ID Rx_UIID of the receiving UE or a unique self-assigned layer 2 address Rx_L2ID, · constructs the map o [Tx_API, Rx_API, Tx_UIID, Rx_UIID, R_L2ID] or o [Tx_API, Rx_API, Tx_L2ID, Rx_L2ID, R_L2ID] or o [Tx_API, Rx_API, R_L2ID], · stores and / or announces the direct discovery set in a fourth discovery message if both Tx_API and Rx_API in the map associated to R_L2ID are not set, or if both are set to “it is not prohibited to announce the User Info ID”. In an embodiment that may be used independently or combined with other embodiments, after receives a discovery response message from a Discoveree End UE and constructs the map: o [Tx_API, Rx_API, Tx_UIID, Rx_UIID, R_L2ID], or o [Tx_API, Rx_API, Tx_L2ID, Rx_L2ID, R_L2ID] which may be reduced to: o [Tx_UIID, Rx_UIID, R_L2ID], or o [Tx_L2ID, Rx_L2ID, R_L2ID] After the making of the decision to announce, or not. The reduced mapping containing the Layer-2 IDs of [Tx], [R], and [Rx] may be used to maintain the link between each [Tx] and [Rx] establishing a, or have an established, communication link over [R]. In an embodiment variant, the reduced mapping also includes the RSC associated with connectivity service used in the first and second hop, and subsequently the security materials used to protect discovery and communication messages. During and after a UE-to-UE Relay discovery procedure e.g., direct communication over UE- to-UE Relay, the UE-to-UE Relay may need to maintain mappings between each two end UEs that are performing a discovery procedure (e.g., with Model B) that involves back and forth messaging (e.g., discovery solicitation and response messages), or a direct link establishment procedure, or both over the UE-to-UE Relay, or have an established PC5 secure link with and / or over the UE-to-UE relay. For example, the UE-to-UE relay may create a mapping as described above such as [Tx_UIID, Rx_UIID, R_L2ID], or [Tx_L2ID, Rx_L2ID, R_L2ID] or may create separate mappings for [Tx] and [Rx], e.g. [Tx_L2ID, R_L2ID-Tx] and / or [R_L2ID-Rx, Rx_L2ID], e.g. by assigning a unique R_L2ID-Tx for each [Tx] or [Rx] and / or a unique R_L2ID-Rx for each [Rx] or [Tx]. Additionally or alternatively, R_L2ID-Tx may be the same as R_L2ID-Rx, however when R_L2ID-Tx and R_L2ID-Rx are different, the UE-to-UE relay may further maintain an additional mapping [R_L2ID-Tx, R_L2ID-Rx] to enable the Relay to link the two mappings with Tx_L2ID and Rx_L2ID (i.e., [Tx_L2ID, R_L2ID- Tx] and [R_L2ID-Rx, Rx_L2ID]). In relation to this, the following NOTE is captured in clause 8a.2.1.3.3.2 of TS 24.554: NOTE 4: If the UE is processing a PROSE DIRECT LINK ESTABLISHMENT REQUEST message from the same source layer-2 ID of the received PROSE PC5 DISCOVERY message for UE-to-UE relay discovery solicitation, it depends on UE implementation to avoid the conflict of destination layer- 2 ID (e.g. send a PROSE DIRECT LINK ESTABLISHMENT REJECT message containing PC5 signalling protocol cause value #3 "conflict of layer-2 ID for unicast communication is detected", or ignore the PROSE DIRECT DISCOVERY message for UE-to-UE relay discovery solicitation). That is, when a UE-to-UE Relay receives a Discovery message with the same source layer-2 ID as the one received in the direct link establishment request being processed, the UE-to-UE Relay needs to avoid the conflict. During the discovery procedure the User Info ID of target end UE may not be provided to source end UE (e.g., in the discovery response message i.e., outside of the direct discovery set), in which case the UE-to-UE Relay cannot rely on source End UE to retrieve the target end UE’s User info ID. Also, the UE-to-UE relay may not have access to the User Info ID of the End UEs, since these may be protected using keys that are not available to the UE-to-UE relay. Hence, the UE-to-UE relay and the End UEs may need to rely on the layer-2 ID related mappings. Therefore, it is important that these mappings are kept up-to-date. It is proposed the following embodiments to address the aforementioned issues: In an embodiment that may be used independently or combined with other embodiments, between the discovery procedure and initiating the direct communication procedure or during the direct communication procedure, UEs (e.g., Source and / or Relay and / or Target UE) may self-assign new layer-2 IDs, in which case, the UE-to-UE Relay updates the mapping(s) that it has created (e.g., during the discovery phase) with the new layer-2 IDs, and if needed informs the Source UE and / or Target UE of the changed layer-2 ID. For instance, following the discovery procedure, the Source End UE may self-assign a new Layer-2 ID (e.g., Tx_L2ID2), which it sets as Source Layer-2 ID during the transmission of the DCR message; in this case, the Source End UE uses the R_L2ID (or the R_L2ID- Tx or the R_L2ID-Rx if the U2U maintains separate mapping for [Rx] (i.e. Target End UE) and [Tx] (i.e. Source End UE)) received during the last discovery response message as a Destination Layer-2 ID to communicate with [R], thus enabling the UE-to-UE Relay to identify the intended Target UE, the RSC, and subsequently security keys to process the protected DCR message. The UE-to-UE relay also updates the mapping(s), e.g. from [Tx_L2ID, Rx_L2ID, R_L2ID] to [Tx_L2ID2, Rx_L2ID, R_L2ID]; or from [Tx_L2ID, R_L2ID-Tx] to [Tx_L2ID2, R_L2ID-Tx]; or from [Tx_L2ID, R_L2ID-Rx] to [Tx_L2ID2, R_L2ID-Rx]; or from [Tx_L2ID - Tx_UIID, Rx_L2ID – Rx_UIID, R_L2ID] to [Tx_L2ID2 – Tx_UIID, Rx_L2ID – Rx_UUID, R_L2ID]; depending on the format of the mapping. Once the UE-to-UE Relay receives the DCR message, processes it, and updates the mapping, it may construct a DCR message to be transmitted to the Target End UE. The UE-to-UE Relay may self-assign a new Layer-2 ID (e.g., R_L2ID2), in which case the mapping(s) is further updated to [Tx_L2ID2, Rx_L2ID, R_L2ID2] or [Tx_L2ID2, R_L2ID-Tx2] or [Tx_L2ID2, R_L2ID-Rx2] or [Tx_L2ID2 – Tx_UIID, Rx_L2ID – Rx_UUID, R_L2ID2] and the R_L2ID2 (or R_L2ID_Tx2 or R_L2ID_Rx2) is set as a Source Layer-2 ID for the DCR message in the second hop; in this case, the UE-to-UE Relay shall use the Rx_L2ID from the mapping as a Destination Layer-2 ID. Once the Target End UE receives the DCR message and processes it, if the RSC is associated with a network assistance security indicator indicating the security procedure is to be used with network assistance, the Target End UE responds with a protected Direct Communication Security Request, otherwise a Direct Auth and Key Establishment procedure, as described in 5.3.3.1.4.3 or 5.3.3.1.4.4 of TS 33.536 is triggered by Target End UE. In both cases, the Target End UE may self-assign a new Layer-2 ID (e.g., Rx_L2ID2) and sets it as the Source Layer-2 ID in the message to be transmitted to UE-to-UE Relay, with the received Layer-2 ID from the UE-to-UE Relay e.g. R_L2ID2 (or R_L2ID_Tx2 or R_L2ID_Rx2) set as a Destination Layer-2 ID. Once the UE- to-UE Relay receives the response message from Target End UE, it may further update the mapping to [Tx_L2ID2, Rx_L2ID2, R_L2ID2] or [Rx_L2ID2, R_L2ID-Tx2] or [Rx_L2ID2, R_L2ID-Rx2] or [Tx_L2ID2– Tx_UIID, Rx_L2ID2– Rx_UUID, R_L2ID2] . The mapping update mechanism, which is based on identifying the mapping instance based on a fixed L2_ID (e.g., R_L2ID in the first hop message, or Rx_L2ID2in the second hop response message i.e., generally the UE-to-UE Relay Layer- 2 ID received last) when an End UE self-assigns a new Layer-2 ID, or when a UE-to-UE Relay self- assigns a new Layer-2 ID, may be re-used whenever any of the UEs (i.e., End UEs or Relay UE) self- assigns a new Layer-2 ID. Additionally or alternatively, the UE-to-UE relay may autonomously decide to self-assign a new Layer-2 ID that corresponds to a [Tx] or [Rx] or both and inform the [Tx] and / or [Rx] about the new self assigned layer-2 ID(s) of the UE-to-UE relay. In a related embodiment, a Layer-2 UE-to-UE relay may maintain an additional mapping of each of its self-assigned Layer-2 IDs that correspond to a [Tx] or [Rx] to a local ID to be used at the SRAP layer as specified in TS 38.351, whereby a local ID may be used as in the previous embodiment instead of R_L2ID2(or R_L2ID_Tx2or R_L2ID_Rx2), or may be provided to a [Tx] or [Rx] by using a RRCReconfigurationSidelink message that includes both the self-assigned Layer-2 ID of the U2U relay and the corresponding local ID. In another embodiment, the UE-to-UE relay UE may retrieve the User Info ID corresponding to a target end UE with which an ongoing direct link establishment procedure is taking place, whereby when the UE-to-UE relay receives the DCR message from the source End UE, it retrieves the target end UE’s User Info ID by retrieving the mapping instance which is identified by the layer 2 IDs of source end UE and UE-to-UE relay. In another embodiment, the User Info IDs of the UEs (i.e., end UEs and UE-to-UE Relay) may not be required in discovery messages or direct link establishment request(s), and instead, if a discovery procedure has already taken place, the layer-2 ID mapping as described in previous embodiment can be used. In an embodiment related to the conflict resulting from receiving the same source layer-2 ID in a discovery message as in a link establishment request message, since the same source layer-2 ID may be associated with different mappings (i.e., one for each link), there should not be any conflict at the UE-to-UE relay as the latter self-assigns different Layer-2 IDs for the different links. In general it is described a method by which a second device (e..g, UE-to-UE relay UE) creates and maintains mappings which enable the second device to associate each PC5 first hop link with its corresponding PC5 second hop link, wherein the mapping is based on the self-assigned layer- 2 IDs of any first device (e.g., source end UE), the second device, and any third device (e.g., a target end UE) whereby the link is constructed as follows: - The first device self-assigns a layer-2 ID (e.g. X) and sets it as source layer-2 ID, and may set a default destination layer-2 ID, then sends a message (e.g., discovery message, direct communication request message or link identifier update request) to the second device - The second device processes the message and retrieves the source layer-2 ID, constructs the message (e.g., discovery message, direct communication request message or link / relay identifier update request) to be sent over the second hop, self-assign a layer-2 ID (e.g., Y) and sets it as a source Layer-2 ID, and stores the partial map [X,Y] - The third device processing the received message, constructing a response message (e.g., discovery message, direct communication accept message or link / relay identifier update response), self-assigns a layer-2 ID (e.g., Z) and sets it as s source layer-2 ID, then set the destination layer-2 ID to the layer-2 ID i.e., Y received in the message from the second device. - The second device processing the response message from the third device, then constructs the complete map: [X, Y, Z] or partial map [Y,Z]. And every time the first, or third device self-assign new layer-2 IDs, they shall use the same layer-2 ID associated with the second device (e.g. as received earlier through a configuration or relay identifier update request or RRCReconfigurationSidelink, or received as source layer-2 ID in the forwarded message) as destination layer-2 ID in the message (e.g., direct link establishment request) to be transmitted, thus enabling the second device to identify the corresponding mapping instance and updating it based on the new self-assigned layer-2 ID(s); And / or the second device autonomously decides to self-assign a new Layer-2 ID that corresponds to the first and / or third device, and informs the first and / or third device about the new self assigned layer-2 ID; And / or the second device stores an additional mapping [Y, L] between a self-assigned Layer-2 ID that corresponds to the third device (or first device) and a Local ID (i.e. L) that may be used instead of the Layer-2 ID (e.g. Z in case of the third device or X in case of the first device) to communicate messages (e.g. via SRAP Layer for Layer-2 UE-to-UE relayed communication) between the first device and the third device (respectively between the third device and first device), and whereby the second device may use a message (e.g. RRCReconfigurationSidelink message) that includes both the self-assigned Layer-2 ID of the second device (i.e. Y) and the corresponding local ID (i.e. L). In an embodiment, during UE-to-UE relay discovery, the direct discovery set which carries the User Info IDs of Source and Target (e.g., Discoverer and Discoveree) end UEs may be protected in such a way that the User Info IDs are protected (i.e., encrypted and integrity protected) separately, thus they may have the following structure: Direct discovery set IEI Length of direct discovery set elements Length Counter MIC Encrypted Discoveree User Info ID Length Counter MIC Encrypted Discoverer User Info ID This enables the UE-to-UE relay to be able to extract User Info IDs of Discoverer and / or Discoveree UE from a direct discovery set corresponding to a Model B discovery and include the User Info ID(s) of Discoveree and / or Discoverer to the list of direct discovery sets to be announced in a Model A discovery, provided that the Discoveree and / or Discoverer UEs have indicated (i.e., set the prohibited announce indication (API) to " It is not prohibited to broadcast the User Info ID ") that the UE-to-UE Relay is not prohibited from announcing their User Info IDs during a subsequent model A discovery. Although, the protected User Info IDs are time bound, hence, for instance if the Discoverer UE sets its API to "It is not prohibited to broadcast the User Info ID", by the time the Discoveree UE sends a ProSe discovery response message to the UE-to-UE relay and / or the UE-to-UE relay switches to model A discovery, the protected User Info ID of the Discoverer UE might already be expired. As such, in an embodiment that may be used independently or combined with other embodiments, the UE-to-UE relay may be configured (e.g., via a policy) to store only the most fresh protected User Info IDs. For instance, if the discoverer UE sets its API to " It is not prohibited to broadcast the User Info ID ", once the UE-to-UE relay receives the discovery solicitation message, and upon checking that the API doesn't prohibit announcement, it may extract and stores the encrypted Discoverer User Info ID with its MIC and validity timer, and upon receiving the discovery response message from the Discoveree UE, the UE-to-UE relay extracts and replaces the stored Discoverer User Info ID received in the discovery solicitation message by the Discoverer User Info ID received in the discovery response message. As described in previous embodiments, the UE-to-UE relay maintains, using a self-assigned unique layer-2 ID, a mapping between the discovery solicitation message (e.g., D_1) and the discovery response message (e.g., D_3). Thus making it possible to link and replace the encrypted Discoverer User Info ID from D_1 by the one received in D_3. This is particularly relevant to the Discoverer's User Info ID since its API is received in D_1 while the most fresh encrypted User Info ID is received in D_3, whereas for the Discoveree UE, both the API and the User Info ID are received in D_3. In another embodiment that may be combined with the previous embodiment or used independently, during 5G ProSe UE-to-UE Model B Relay discovery, the processing of the protected discoverer end UE discovery info (i.e., protected discoverer User Info ID) shall only be performed if the received discoveree end UE user info, upon being processed, matches the discoveree end UE's User Info ID. Section: Optimization of security processing of UE-to-UE discovery messages In some scenarios, the monitoring End UE may obtain a UE-to-UE discovery message including multiple Direct Discovery Sets. Depending on how the Direct Discovery Sets are processed, some of them may be rejected because of the processing delay at the monitoring UE. For instance, the last processed Direct Discovery Set may be processed at a later time so the UTC-based time counter reconciliation procedure fails. Thus, it is an aim of the following embodiments to provide solutions to deal with this problem. Thus: In an embodiment that can be combined with other embodiments or implemented independently, which relates to the security processing of the Direct Discovery Set(s) received by a Monitoring End UE in a ProSe UE-to-UE Relay discovery announcement message, the monitoring End UE may obtain a single valid UTC time from the lower layers, which is subsequently used to perform the UTC-based counter reconciliation(s) for all direct discovery set(s) whereby for each direct discovery set, the UTC-based counter is reconciled based on the UTC-based counter LSB parameter associated with the direct discovery set and the UTC-based counter generated from the UTC time obtained from the lower layers. This is advantageous because it addresses above problem and a single valid UTC time needs to be obtained from the lower layers. In a related embodiment variant, the Monitoring UE may use the same UTC-based counter generated to process the 5G ProSe UE-to-UE Relay discovery Announcement message to perform the UTC-based counter reconciliations(s) for the extracted direct discovery set(s). The use of a single UTC time to reconcile all UTC-based counter(s) associated with the direct discovery set(s) has the advantage of ensuring that the direct discovery set(s) do not expire while awaiting to be processed by the Monitoring UE. In a related embodiment, the monitoring UE may security process the Direct Discovery Sets one by one (unscrambling, decryption and integrity verification for each of them) or in parallel (first unscrambling of all of them, then decrypting of all of them, and then integrity verifying of all of them). The last parallel option may be advantageous for multiple reasons, e.g., it decreases the delay to start processing all of them (obtaining a valid UTC time from the lower layers) or it allows filtering out / identifying earlier the Direct Discovery Sets that are for the monitoring UE. In accordance with a general definition of this embodiment, it is described a method by which a receiving UE security processes a discovery message containing one or more direct discovery sets by obtaining a receiving UTC-based counter from the lower layers and applying said UTC-based counter to: - Reconcile a first transmitting UTC-based counter used by a first transmitting device to protect the discovery message, and applying the first transmitting UTC-based counter to security process the discovery message, and if the security processing of the discovery message succeeds, - Reconcile a second transmitting UTC-based counter used by a second transmitting device to protect a discovery set, and applying the second transmitting UTC-based counter to security process the discovery set. In some scenarios, it is also important to reduce computational overhead and reduce latency. If many Direct Discovery Sets are received in a UE-to-UE discovery message, some of those Direct Discovery Sets may not be for the monitoring UE receiving them, and currently, it is only possible to determine it once they have been unscrambled, decrypted and integrity verified. Furthermore, since the ProSe Service Code may not be included in the direct discovery set, it is not possible to follow the security processing routines described in TS 33.303 and TS 33.503 clause 6.1.3.2.3. In that clause, after unscrambling, the receiving UE checks whether the Prose Service Code matches, and only if it matches, it proceeds with the decryption / integrity verification. If the ProSe Service Code is not available, existing implementations are not interoperable. In other to address these problems, the following embodiments are proposed: In an embodiment -- that can be combined with other embodiments or implemented independently -- related to the security processing of the Direct Discovery Set(s) received by a Monitoring End UE in a ProSe UE-to-UE Relay discovery announcement message, if the Monitoring UE is provisioned with a DUSK and / or DUCK in the code-receiving security parameters, the Monitoring UE shall use DUSK and / or DUCK, together with the reconciled UTC-based counter(s), to unscramble and / or decrypt the direct discovery set(s). To reduce the computational overhead and / or verify whether the direct discovery set was unscrambled and / or decrypted successfully, the Monitoring UE may verify whether the (Target / Monitoring UE) User Info ID, as provided by the upper layers, matches with the decrypted (Target) User Info ID received. Based on the outcome of the verification, the Monitoring UE decides whether to stop the direct discovery set processing and / or discard the direct discovery set and move to process another direct discovery set, if any, or proceed to perform the MIC check to verify the integrity of the direct discovery set. This embodiment is advantageous because it provides a method for efficient processing of a UE-to-UE discovery message by performing an efficient check (matching the User Info IDs) before / instead of an expensive check (MIC check) In a related embodiment variant, if the Monitoring UE is provisioned with both DUSK and DUCK, the monitoring UE may only perform the User Info ID matching check after performing both the unscrambling and decryption. Otherwise, the Monitoring UE may perform the User Info ID matching check, after either unscrambling or decryption, based on which Discovery User Keys the Monitoring UE is provisioned with. For instance, if it is only provisioned with the DUSK, it may only perform a partial match after unscrambling and for instance, if it is only provisioned with the DUCK, it may only perform a full match after decryption. In a related embodiment variant, aimed at reducing the computational overhead associated with the processing of direct discovery set(s), a direct discovery set may include an information element which enables a Receiving / Target End UE (e.g., Discoveree or Monitoring UE) to determine whether a direct discovery set is intended for it, and whether a set of security key materials is the right set of security key materials to use to process the direct discovery set. For instance, this information element may consist of a set of k bits, e.g., the first / last k bits, of the Target End UE’s (e.g., Discoveree / Monitoring UE) User Info ID or a function thereof as in other embodiments, which is protected (e.g., scrambled) by the Source End UE (e.g., Discoverer / Announcing UE), with k being pre-configured by the network. Upon receiving and processing a Discovery message, the Target End UE may extract the direct discovery set(s) and processes it / them as follows: - Perform unscrambling of the information element containing the first / last / a subset of k bits of the Target End UE’s User Info ID, - Verifying / matching the k bits from the unscrambled information element against the same set of bits from the Target User Info ID provided by the upper layers, - Based on the outcome of the check in the previous step, Target End UE either proceeds with the processing of the direct discovery set (e.g, when there’s a match), or discards the direct discovery set (e.g., when there’s no match), - If the initial check is successful and DUCK is provided, the Target End UE proceeds to decrypt the confidentiality protected information elements of the direct discovery sets, - The UE may perform another check to verify whether the Target End UE’s decrypted User Info ID matches the Target End UE’s User Info ID, as provided by the upper layers, and - If the check if successful, the UE proceeds to perform an integrity verification, provided that the UE is provisioned with DUIK. In an embodiment variant, this proposed processing is applied to align with the processing in TS 33.503 Clause 6.1.3.2.3 and TS 33.303 Clause 6.1.3.4.3.3 so that existing implementations can be reused. This processing allows for more optimized performance. In particular, Step 2 in Clause 6.1.3.4.3.3 in TS 33.303 needs to be adapted to match k bits of the target’s User Info ID. In particular, Step 4 in Clause 6.1.3.4.3.3 in TS 33.303 refers to the target’s User Info ID. It is to be further noted that TS 33.503 only allows scrambling the first 32 bytes of the discovery message and for this to work, the Target UE’s User Info ID needs to be transmitted at the beginning of the Direct Discovery set, i.e., before the Source UE’s User Info ID because based on TS 33.503 only the first 32 bytes can be scrambled (because of “NOTE 2: The maximum length of the discovery message to be scrambled is limited to 256 bits.” In Clause 6.1.3.2.3) and all information starting from bytes 32 is encrypted if the DUCK is configured (because of “KEYSTREAM = output_keystream AND (Encrypted_bits_mask || 0xFF..FF) ” in Annex A.7). This is different than stated in TS 33.503 v1.0.0 where in Clause 6.1.3.3.3.2 it says: “The direct discovery set shall include User Info ID of the discoverer 5G ProSe End UE and User Info ID of the discoveree 5G ProSe End UE”. Similarly, proposed Tdoc C1-238997 proposes a similar encoding of Source UE’s User Info ID (Source discoverer end UE info) and Target UE’s User Info ID (Target discoveree end UE info) where the Source UE’s User info ID is transmitted. 8 7 6 5 4 3 2 1 Direct discovery set IEI octet 1 octet 2 Length of direct discovery set contents octet 3 Source discoverer end UE info octet 4 octet a Target discoveree end UE info octet (a+1) octet b MIC octet (b+1) octet (b+4) Spare UTC-based counter LSB contents octet (b+5) Figure 11.2.xx.1: Direct discovery set information element Thus, in order for the security routines in TS 33.303 and TS 33.503 to apply, the Target UE’s User Info ID must be transmitted first / before the Source UE’s User Info ID. It is also to be noted that these checks fulfill a double purpose: allow the UE to identify which keys to use for the security processing and allow the UE to identifying whether a direct discovery set is intended for it or not, so that the UE (target UE) does not need to try to process many potential Direct Discovery Sets. In a related embodiment, the information elements in a direct discovery set may be encoded as follows / in the following order to limit changes in the security processing specified in TS 33.503: · First, Direct discovery set IE (1 byte) · Second, Spare | UTC-based counter LSB (1 byte) · Third, MIC (four bytes) · Fourth, length of the Target UE’s user info ID and Source UE’s user info ID (two bytes) · Target UE’s user info ID (Target discoveree end UE Info) · Source UE’s user info ID (Source discoverer end UE Info). Other fields may be added as per other embodiment (variants). With this encoding, the first 2 bytes are not scrambled as per TS 33.503. The following 32 bytes may be scrambled as per the definition of the configured time-hash-bitsequence in TS 33.503. To achieve the partial match of the target UE’s User info ID the Encrypted_bits_mask should be such that it does not encrypt k bits in the top 24 bytes of the target UE’s User info ID. In an embodiment variant, that may be combined with other embodiments or used independently, the information element carrying the K bits of the Target UE’s User Info ID may be sent unscrambled, e.g., in case the Source End UE is not provisioned with DUSK, but it is at least integrity protected, if a DUIK is provisioned. Additionally or alternatively, a function (e.g., a truncated hash, e.g., the k least significant bits of the Hash computed over the Target UE’s User Info ID or the concatenation of Target UE’s User Info ID and UTC-based counter) of the Target UE’s User Info ID may be exchanged to protect the privacy of the target UE. In this case, the Target End UE may not be able to determine which security key materials to use to process the direct discovery set, but it will manage to determine whether the direct discovery set is intended for it or not. This has the advantage of reducing the number of direct discovery set(s) the target End UE has to process, especially in UE-to-UE relay discovery with model A, where the Target UE may receive a list of direct discovery sets. In an embodiment variant, that may be combined with other embodiments or used independently, the order of the security operations performed when protecting the direct discovery set may be set to, Confidentiality protection, Integrity protection, and then scrambling, so as to reduce the computational overhead when processing the direct discovery set at the target End UE, because the MIC verification may be less costly, resource wise, than decryption and because decryption is only required if the integrity check is successful. Hence, when a target End UE receive a direct discovery set or a list of direct discovery sets, initially it performs unscrambling and then verifies whether the K bits from the target End UE IE match the k bits from the target End UE provided by the upper layers, then if successful, and UE determines the correct security key materials to use, the UE performs a MIC check, and only upon successfully verifying the integrity of the direct discovery set does the UE proceed to perform the decryption, otherwise (e.g., if the MIC couldn’t be verified) the UE may discard the direct discovery set. In another embodiment that may be combined with other embodiments or used independently, if the integrity protection of the direct discovery set is performed after the confidentiality protection , the UE-to-UE relay may be provisioned with the DUSK and / or DUIK, but not the DUCK, of the code-receiving security materials associated with the prose direct discovery service, which may enable the UE-to-UE to verify the (time) validity of the direct discovery sets(s) it receives. For instance, upon receiving a direct discovery set, the UE-to-UE relay may reconstruct the UTC-based counter associated with the direct discovery set, as described in one of the previous embodiments, and using the DUSK and / or DUIK, the UE-to-UE Relay may unscramble and / or perform an integrity check over the direct discovery set. A successful unscrambling and / or integrity verification ensures that the direct discovery set remains valid. In another embodiment related to UE-to-UE relay discovery with Model A, where an Announcing End UE employs two sets of User Info IDs; one intended for the Monitoring UE (i.e., the User Info IDs included in the direct discovery set), and the other intended for the UE-to-UE relay. In this case, and to enable Monitoring End UEs to know whether the ProSe Discovery Announcement message contains at least a direct discovery set intended to them, the UE-to-UE Relay may set the list of 5G ProSe End UEs to only include the Target User Info IDs (e.g., associated with the UE-to-UE relay discovery) received with a direct discovery set. This has the advantage of enabling a Monitoring UE to determine whether to attempt the processing of the direct discovery set(s) based on whether the list of ProSe End UE(s) in the ProSe Discovery Announcement message includes its User Info ID for UE-to-UE Relay discovery. In an embodiment, the number of (UTC-based) counter LSBs exchanged may be variable. In above data structure, we observe 1 byte used to transfer 4 LSBs: [Bit 7, Bit 6, Bit 5, Bit 4, Bit 3, Bit 2, Bit 1, Bit 0] It can be observed that the number of LSBs exchanged is currently fixed to four bits. The four remaining bits are spare bits. If the number of exchanged LSBs is made variable, the validity time, i.e., how long the message (e.g., direct discovery set) can be stored by the UE-to-UE relay can also be made variable. For instance, with 4 bits the message may be valid for 16 seconds, with 5 bits for 32 seconds, with 6 bits for 64 seconds and with 7 bits for 128 seconds. This can be advantageous. How many bits are used may be encoded in the four spare bits. For example, - If Bits 7-4 are set to zero, then only 4 LSBs information are exchanged,If Bit 5 is set to 1, then Bits 4-0 correspond to 5 LSBs,If Bit 6 is set to 1, then Bits 5-0 correspond to 6 LSBs. If Bit 7 is set to 1, then Bits 6-0 correspond to 7 LSBs.This approach provides a means to use different amount of LSBs, and thus, it provides a means to having different validity times ranging from 16 seconds to 128 seconds. Depending on the discovery model, (i.e., discovery model A and model B) being used during a UE-to-UE Relay discovery procedure, the content of the direct discovery set may be different. For instance, during UE-to-UE discovery with model B, a Source End UE (i.e., Discoverer UE) constructs a direct discovery set which includes the User Info IDs of both the Source End UE and the Target End UE, and for which, the security processing procedure from the previous embodiments is applicable, whereas during UE-to-UE relay discovery with model A, the Target End UE’s (e.g., Monitoring End UE) may be an optional field. If the direct discovery set includes only the Source End UE’s (e.g., Announcing End UE) User Info ID, the security processing mechanism from the previous embodiments may not be applicable, as the Target End UE’s User Info ID may not be included in the direct discovery set. In which case, if the Monitoring End UE has the User Info ID associated to the Announcing End UE, it may attempt the security processing mechanism from the previous embodiments, where instead of unscrambling and matching the unscrambled sequence with the first k bits of the Target End UE’s User Info ID, it matches the unscrambled sequence with the Source End UE’s User Info ID(s) it has or expects a discovery message from. Performing a check of part (e.g., k bits) of the User Info ID of a device may not always allow differenting devices, e.g., because some bits of the User Info ID may be common to multiple devices. Thus, in an embodiment a k bit value may be derived from the User Info ID, e.g., it may be derived by means of a function, e.g., the function may be the truncated hash of the User Info ID. This k bit value may be a representative fingerprint of the whole User Info ID and it may be included in the discovery message / direct discovery set e.g., in the first 32 bytes to be scrambled. Similarly, in an embodiment that may be used independently, the k bit value used to perform a match after descrambling of a direct discovery set / discovery message may be derived by means of a function (e.g., truncated hash function, or a bit selection function that selects some specific bits from the input) from one or more fields or part of fields in the discovery message, e.g., User Info IDs of source and target if the Target UE knows, e.g., the User Info IDs of both source and target. This allows the receiving UE to match whether the message is intended for it or not. In another embodiment that may be combined with other embodiments or used independently, the direct discovery set or a part thereof (e.g., protected User Info ID of an end UE) is protected using the same protection mechanism described in clause 6.1.3.2.3 of TS 33.503, with the following changes: In A.5 of TS 33.303 [4], the time-hash-bitsequence keystream is set to L least significant bits of the output of the KDF, where L is the bit length of the direct discover set to be scrambled and set to Min (the length of direct discovery set - 8, 256). Step 3 of clause 6.1.3.4.3.5 of TS 33.303 [4] becomes: If L is set to 256bits: XOR the time-hash-bitsequence with the most significant L bits of the direct discovery set. Otherwise: XOR (time-hash-bitsequence || 0xFF) with the most significant (L + 8) bits of the direct discovery set. where 8 is the size of the UTC-based counter LSB field in bit length. In accordance with a more general definition of this embodiment, it is described a method by which a sending UE ( e.g., Source End UE) security processes a discovery message (e.g., a Direct Discovery Set) containing a set of discovery parameters in such a way that enables a receiving UE (e.g., Target End UE) to check whether the discovery message containing the set of discovery parameters is intended for it and / or whether the set of security key materials used to process the protected discovery message containing the set of discovery parameters is the correct set of security materials, wherein: 1. a sending UE a. orders the set of discovery parameters in the discovery message in such a way that the receiving UE’s User Info ID is placed in the first 32 bytes of the discovery message, b. and creates a protected discovery message by i. not encrypting k bits of the receiving UE’s User Info ID or a function of it in the first 32 bytes of the discovery message, and ii. scrambling the k non-encrypted bits of the receiving UE’s User Info ID or a function of it in the first 32 bytes of the discovery message, and 2. A receiving UE securely processes the protected discovery message by: a. unscrambling the discovery message and checking whether the unscrambled sequence matches k bits of the User Info ID of the receiving UE or a function of it, or the User Info ID of a sending UE from which a discovery message is expected or a function of it, as provided by the upper layers, and b. if there is a match, decrypting the unscrambled message into a decrypted discovery message, and checking whether the decrypted User Info ID of the receiving UE matches the User Info ID of the receiving UE as provided by the upper layers, and c. if there is a match, integrity verifying the decrypted discovery message. In the above general process, only the scrambling check or the decryption check may be performed, even if it is advantageous to perform both. During a UE-to-UE relay discovery procedure based on Model A, the Announcing UE (i.e., UE-to-UE relay) may receive several discovery announcement messages from Announcing End UEs (i.e., Source End UEs) which may contain direct discovery set(s) meant to be relayed. The discovery announcement messages received by the Announcing UE may include relay service codes which are associated with different Network Assistance Security Indicators (NASI) i.e., some may be associated with security procedures with network assistance, while others may be associated with security procedures without network assistance; When the UE-to-UE relay is outside of 3GPP coverage, clause 6.6.3.3 of TS 33.503 states that the UE-to-UE relay shall only use an RSC associated with a NASI indicating security procedures without network assistance are to be used, but whether it shall ignore the discovery announcement messages including an RSC associated with a NASI indicating security procedures with network assistance are to be used, or it may announce them, is not specified. Similarly, when the UE-to-UE relay is inside 3GPP coverage, clause 6.6.3.3 of TS 33.503 states that the UE-to-UE relay may use both RSCs associated with NASIs indicating the two security procedures (i.e., with / without network assistance), however, as described above, the UE-to-UE relay may receive discovery announcement messages from Announcing End UEs which include different RSCs associated with NASIs indicating different security procedures, and the UE-to-UE relay bundles the received direct discovery set(s) into a list of direct discovery set(s) which is announced in a discovery announcement message which includes only one RSC associated to a NASI indicating a particular security procedure (i.e., with or without network assistance). As such, the security procedure selected / indicated by the RSC used by Announcing End UE and the security procedure indicated by the RSC announced by the UE-to-UE relay may be in conflict, and the Monitoring End UE knows only of the security solution indicated by the UE-to-UE relay. It is therefore the object of the following embodiments to address these gaps. In an embodiment that may be combined with other embodiments or used independently, during Model A UE-to-UE relay discovery, when the UE-to-UE Relay receives a discovery announcement message, UE-to-UE relay checks the direct discovery set's validity time, and may also check whether the RSC contained in the received discovery announcement message is associated with a NASI indicating a security procedure it supports. For instance, if the RSC included in the received discovery announcement message is associated with a network assistance security indicator indicating the security procedure with network assistance is required, the Announcing UE may ignore the received discovery announcement message if it is outside 3GPP coverage. Alternatively, the UE-to- UE Relay may still include such direct discovery set regardless of the security procedure indicated by the RSC included in it, but may indicate to the Monitoring UE which direct discovery set(s) are associated with which security procedure. For instance, the UE-to-UE Relay may group direct discovery set(s) extracted from announcement messages including RSCs indicating the same security procedure (e.g., with or without network assistance) together, separating the two sets using a delimiter e.g., empty direct discovery set. In such case, the Monitoring End UE may recognize which security procedure is supposed to be used based on the classification of the direct discovery set and the RSC included in the discovery announcement message by the Announcing UE. For example, if the direct discovery set is grouped with the set associated with the security procedure without network assistance, while the RSC used by the Announcing UE is associated with a NASI indicating that the security procedure with network assistance is to be used, the Monitoring End UE recognizes that since Announcing UE used said RSC, it means it is within 3GPP coverage, and thus support both security procedures, and since the direct discovery set is associated with the security procedure without network assistance, then the Monitoring End UE knows that it may establish a link with the Announcing End UE using security procedures without network assistance. In another embodiment that may be combined with other embodiments or used independently, the Announcing UE may transmit multiple announcement messages wherein each discovery announcement message includes an RSC associated with a security procedure (i.e., with or without network assistance) such that each discovery announcement message contains only the direct discovery set(s) corresponding to a similar security procedure requested by the announcing End UE(s). For instance, the direct discovery set(s) received within discovery announcement messages including an RSC indicating a security procedure without network assistance are grouped in a list of direct discovery sets and announced in a discovery announcement message which includes an RSC indicating the security procedure without network assistance is to be used; similarly, the DDS(s) sent with an RSC associated with a security procedure with network assistance are bundled and announced in a discovery announcement message which includes an RSC indicating the security procedure with network assistance is to be used, provided that the announcing UE is within 3GPP coverage. Section: UE-to-UE Relay discovery Model A – User Info protection According to clause 6.1.3.3.3.1 of TS 33.503 V18.0.0, the ProSe UE-to-UE Relay which plays the role of an Announcing UE, retrieves and announces direct discovery sets, as provided by the Announcing 5G ProSe End UE (Source End UE) through a previous 5G ProSe UE-to-UE Relay Discovery or communication procedures. As the direct discovery set in model B contains both the User Info of a Source Discoverer End UE and a Target Discoveree End UE, the UE-to-UE Relay must not announce the direct discovery set in a Modal A discovery procedure, unless it was indicated by both the End UEs, whose User Info are included in the direct discovery set, that the UE-to-UE Relay is not prohibited from announcing the direct discovery set, or if they have not included the Announce prohibited indication in the discovery solicitation and / or response messages. Since the direct discovery set is only announced if both End UEs allow it, it is problematic for an End UE (e.g., Source Discoverer End UE) that wishes to be announced by the UE-to-UE Relay to be dependent on the announce prohibition decision of another End UE (e.g., Target Discoveree End UE). Furthermore, the direct discovery set is time bound; that is, it is only valid for a certain period of time, which depends on the fixed bit length of the UTC-based counter LSB parameter associated with it. Thus, it is the object of the following embodiments to address these issues: In an embodiment that may be combined with other embodiments or used independently, an End UE may announce itself using the Restricted 5G ProSe Direct Discovery model A procedure, wherein an indication e.g., relay_indication / announce prohibited indication may be included in the discovery announcement message so as to indicate to a UE-to-UE Relay whether it may further announce the End UE in a UE-to-UE Relay discovery announcement message. The discovery announcement message broadcasted by the End UE may include an RSC, and be protected using the security materials associated with said RSC, such that only End UEs provisioned with the same Relay / connectivity service can discover it, and / or only UE-to-UE Relays configured with the same Relay / connectivity service can further announce it e.g., if so it is indicated. In a related embodiment aimed at enabling the Announcing End UE to have more control over the granularity of the privacy protection of its User Info, the Announcing End UE may choose between an announcement intended for the UEs authorized for discovery using the same Relay / connectivity service and / or an announcement intended for the UEs authorized for discovery with the same ProSe service. In case of the former, the Announcing End UE may include its User Info, in the discovery message, and protect the discovery message using the security materials associated with the Relay Service Code as per Clause 6.1.3.2.3 in TS 33.503, whereas in case of the latter, the Announcing End UE may first protect its User Info (i.e., its Application layer ID) using the security materials associated with the ProSe service, as per clause 6.1.3.2.3 in TS 33.503 (e.g., similarly to how the direct discovery set in Model B is protected), then include the protected User Info in the Direct discovery announcement message, which is protected using the security materials associated with the RSC. In an embodiment that may be combined with other embodiments or used independently, a UE-to-UE Relay may receive discovery announcement messages from different (Announcing) End UEs, which may have their User Infos protected differently. For instance, an Announcing End UE (e.g., Source End UE) may indicate to the Announcing UE (e.g., UE-to-UE Relay) that it not prohibited from announcing its User Info, in which case and depending on how the User Info of the Announcing End UE is protected, the UE-to-UE Relay may choose to group the User Infos that are protected as part of the discovery message (i.e., using the security materials associated with the RSC) in e.g., a list of End UEs’ User Infos, whereas the User Infos which are protected with security materials associated with particular ProSe services may be grouped / appended to the list of direct discovery sets. The Announcing UE (e.g., UE-to-UE Relay) may be able to distinguish between these User Infos, which are privacy protected differently, based on an explicit or implicit indication, e.g., based on whether the protected User Info is associated with additional parameters (e.g., MIC IE, UTC based counter LSB parameter); for instance, a User Info protected using the security materials associated with the ProSe service may be associated with a UTC-based counter LSB parameter and a MIC IE set by the announcing End UE. In another embodiment that may be combined with other embodiments or used independently, an Announcing End UE that intends to be announced only to the (End) UEs authorized for discovery using the same ProSe service may set the validity time of its protected User Info by varying the bit length of the UTC-based counter LSB parameter as described in previous embodiments. In another embodiment that may be combined with other embodiments or used independently, an Announcing End UE that intends to be announced only to the (End) UEs authorized for discovery using the same ProSe service, may include an indication / identifier of the ProSe Service e.g., scrambled / Hash value of a ProSe Code, such that the Announcing UE (e.g., UE-to-UE Relay) may group protected User Infos associated with the same ProSe Service together, without necessarily having access to the ProSe service indicator / identifier in plaintext, in a container associated with said indication / identifier. The Announcing UE (e.g., UE-to-UE Relay) may includ said container(s) in the list of direct discovery sets in the UE-to-UE Relay discovery Announcement message. Alternatively, said container(s) may be included in the list of End UEs’ User Infos. In another embodiment that may be combined with other embodiments or used independently, Monitoring End UEs which are authorized for discovery of a particular ProSe service may be able to identify the container associated with said ProSe service (e.g., based on the ProSe service indication / identifier), which is included in the discovery announcement message of the Announcing UE (e.g., UE-to-UE Relay) as part of the list of direct discovery sets, or as part of the list of End UEs’ User Infos. The monitoring End UE may thus be enabled to distinguish and process only the protected User Infos included in that container. Additionally, or alternatively, the Monitoring End UE may also extract and process the direct discovery sets and / or the User Infos that are included in the list of End UE’s User Infos and protected (using the security materials associated with the RSC) as part of the Announcement message. In another embodiment that may be combined with other embodiments or used independently, a Monitoring end UE computes the unscrambling time-hash-bitsequence, according to TS 33.303, using its UTC-bit counter with the 4 LSBs set to zero, i.e., the 4 LSBs received as a UTC-based counter LSB parameter with a protected direct discovery set or a protected User Info are not used in computing the time-hash-bitsequence. However, due to potential time synchronization errors and / or delays, the UTC-based Counter (e.g., UTC-bC1) at the Announcing End UE and the UTC-based Counter (e.g., UTC-bC2) at the Monitoring End UE may have a different 5thLSB, thus the MSBs used to compute the un / scrambling sequence at the Announcing End UE and Monitoring End UE may be different, thus resulting in different time-hash-bitsequences. As such, and to remediate such issue, the Monitoring End UE may also compute the time-hash-bitsequences for unscrambling using UTC-bC2 with the MSBs set to MSB-1, and MSB+1, to account for the potential difference between UTC-bC1 and UTC-bC2. In general it is described an apparatus for secure announcement of a User Info of a first device to a third device, wherein the apparatus is configured to: - receive a protected direct discovery announcement message from a first device - undo the protection of the direct discovery announcement message and extract the User Info of the first device from the message - determine whether the User Info has another layer of protection based on whether the information element is associated with other parameters such as MAC IE and / or UTC-based counter LSB parameter - based on the previous check: o if the User Info is protected using security materials associated with a ProSe service: § determine whether the ProSe Service could be identified from the scrambling sequence and / or based on an implicit or explicit indication, and if so, group it in a container with other User Infos associated with the same ProSe service to be announced in the discovery announcement message; or § include the protected User Info in the list of direct discovery set(s) to be annouced in the discovery announcement message; and o Announce the protected User Info in the discovery announcement message as long as it remains valid and the device is authorized to announce discovery messages - Otherwise: o include the User Info in the list of User Infos to be announced in the discovery announcement message; and o Announce the User Info in the discovery announcement message as long as the device is authorized to announce discovery messages. In accordance with a general definition of this embodiment, it is proposed an apparatus for secure announcement of a User Info to a third device via a relaying second device wherein the apparatus is configured to: - determine whether to announce itself to a third device that is authorized for discovery using the same connectivity service, or to a third device that is authorized for discovery using the same connectivity and ProSe services; and - based on the decision in the first step, security process / protect the User Info as follows: o If the User Info is intended for a third device that is authorized for discovery using the same connectivity and ProSe Services, the User Info is protected as follows: § Protect the User Info using the security materials associated with the ProSe Service, wherein a MAC IE and a UTC-based counter LSB parameter is associated with the protected User Info; § Include the protected User Info in the direct discovery announcement message and protect this latter with the security materials associated with the Relay Service Code; § Transmit the direct discovery announcement message as long as the protected User Info remains valid and the device is authorized to announce discovery messages. o Otherwise: § Include the User Info in the direct discovery announcement message and protect this latter with the security materials associated with the Relay Service Code. § Transmit the direct discovery announcement message as long as the device is authorized to announce discovery messages. In accordance with another general definition of this embodiment, it is proposed an apparatus for monitoring discovery announcement messages, wherein the apparatus is configured to: - receive a protected discovery announcement message from a second device; and - undo the protection of the received discovery announcement message and extract the list of direct discovery set(s) and / or the list of User Infos and / or list of protected User Infos; and - if the apparatus is authorized for discovery using a ProSe service, identify based on the scrambled sequence and / or an implicit or an explicit indication, if any, the container of protected User Infos and / or direct discovery set(s) associated with the ProSe service which the apparatus is authorized to discover; and o If identified, undo the protection for the protected User Info(s) and / or direct discovery set(s) using the security materials associated with said ProSe Service; o Otherwise, undo the protection for all protected User Info(s) and / or direct discovery set(s) using the security materials associated with said ProSe service and verify whether the decryption was succesfull based on the MIC / integrity verification. It is to be noted that the apparatus may be further configured to compute and the (un)scrambling sequence based on UTC-based counter MSBs set to MSB+1 and MSB-1 to account for potential synchronization errors. In general, it is described a method by which a first device securely announces its presence to third device(s) via a second relaying device, wherein the first device determines the granularity or level of protection it intends to apply on its User Info and whereby: - Based on whether the first device chooses to announce itself to third device(s) authorized for discovery using the same connectivity service, or third device(s) authorized for discovery using the same connectivity and ProSe services, the User Info to be announced is security processed / protected differently; when the first device chooses to announce itself to third device(s) authorized for discovery using the same connectivity and ProSe Services, it may protect its User Info at a first stage using security materials associated with the ProSe service, then include the protected User Info in the direct discovery announcement message and protect this latter with the security materials associated with the Relay Service Code, otherwise the User Info is included in the direct discovery announcement message in clear and is protected as part of the discovery message using the security materials associated with the Relay Service Code; and - The second device upon receiving and processing the direct discovery announcement message and based on the granularity of User Info protection and any implicit / explicit ProSe service indications associated with the protected User Info(s), either includes the protected User Info in a container associated with said ProSe service, or in the list of direct discovery set(s), or in a a list of User Infos, then broadcasts the discovery announcement message; and The third device upon receiving and processing the discovery announcement message, extracts the list of User Infos, and / or list of direct discovery sets and / or list of protected User Info containers, and based on whether the third device is authorized for discovery using a ProSe service, it may identify using implicit / explicit indications, if any, the container(s) and / or direct discovery set(s) associated with the ProSe service it is authorized to discover, then, security processes / undoes the protection of the protected direct discovery set(s) and / or protected User Infos included in said container(s); otherwise, it may process all direct discovery set(s) and / or protected User Info container(s). According to the approved CR S2-2401494, during Model A UE-to-UE relay discovery procedure, the UE-to-UE relay may obtain direct discovery set(s) from previous UE-to-UE relay discovery procedure(s) and / or from secure PC5 link(s) between UE-to-UE relay and end UE(s) (e.g., Announcing end UE(s)). For direct discovery set(s) to be retrieved through (pre) establish PC5 secure links between UE-to-UE relay and end UE(s), a potential solution is described in C1-240846, wherein the 5G ProSe direct keep-alive procedure is used by the UE-to-UE relay to request a direct discovery set from the end UE, where the request may include a ProSe Restricted Code previously received from the end UE. However, the ProSe Restricted Code is not provided to the UE-to-UE relay by end UE, and since the ProSe Restricted Code may be associated with a particular ProSe Service, the end UE may be limited to announcing itself only to UEs authorized for discovery using the same service. It is, thus, the object of the following embodiments to address these issues. In an embodiment, the UE-to-UE relay may include in the keep-alive request message an indication and / or a counter (e.g., time counter / window), for example instead of a ProSe code, to end UE(s) with which secure PC5 link(s) is / are already established that indicates that UE-to-UE relay is about to initiate a discovery procedure with model A thus allowing the end UE to provide its protected User Info ID (e.g., direct discovery set as described in 6.1.3.3.3.1 or TS 33.503) to the UE-to-UE relay prior to the broadcast of the discovery announcement message. This has the advantage of not restricting the end UE to a particular ProSe service. In another embodiment that may be used independently or combined with other embodiments (e.g., previous embodiment), an end UE may be authorized for discovery using several ProSe services and may wish to announce itself to all UEs authorized for discovery using any (e.g., at least one, some, or all) of those ProSe services. In this case, the end UE may construct a list of protected User Info IDs, wherein each protected User Info ID corresponds to the end UE’s User Info ID protected using security materials associated with one of those ProSe services. The end UE may then provide the list of protected User Info IDs (or direct discovery sets) to the UE-to-UE relay through the direct link keep-alive response message. Additionally, if needed, the end UE may further include ProSe Restricted Code(s) associated with the ProSe service(s) for which the end UE wishes to be discovered e.g., to facilitate (i.e., through partial matching of the ProSe Restricted Code) the processing of the direct discovery set(s) at the Monitoring end UE(s). This has the advantage of enabling the end UE to be announced to all Monitoring end UEs authorized for discovery using any of those ProSe services . In another embodiment that may be used independently or combined with other embodiments, and in relation to the granularity of privacy protection of the end UE’s User Info ID, as described in previous embodiments, the end UE may wish to avoid protecting its User Info ID several times (e.g., depending on the ProSe services it wishes to be announced for) and opt for being announced to all UEs authorized for discovery using the same connectivity service. In this case, the UE-to-UE relay may include, in addition to the indication and / or counter (e.g., time counter / window) in the direct link keep-alive request a relay service code (e.g., the RSC to be used for the upcoming discovery announcement) or a list of relay service codes corresponding to the connectivity services the UE-to- UE relay is authorized to use for discovery. The end UE may subsequently provide its User Info ID unprotected (i.e., not protected using security materials associated with a ProSe service) along with the selected relay service code associated with the connectivity service for which the end UE is authorized for discovery, to the UE-to-UE relay in the direct link keep-alive response message. The UE-to-UE relay may then announce the User Info ID of said end UE protected (e.g., using the security materials associated with the RSC) within the discovery announcement message. Alternatively, if the RSC selected by the end UE does not match the RSC to be used for the subsequent discovery announcement, the Relay may store the User Info ID of the end UE for an upcoming discovery announcement. This is possible, given that when provided unprotected, the User Info ID is not time bound. In another embodiment that may be combined with other embodiments or used independently, the end UE needs to verify whether it is authorized for discovery for the connectivity service(s) associated with the RSC(s) provided by the UE-to-UE relay in the direct link request message. In case the authorization check fails (e.g., when a single RSC is provided or if the check fails for all RSCs), the end UE may indicate that to the UE-to-UE relay in the direct link keep-alive response message and may not provide its User Info ID to the UE-to-UE relay, regardless of whether the latter is protected (i.e., with security materials associated with a ProSe service) or not. In general, it is described a method by which a first device and a second device exchange a request and response through an established PC5 secure link, wherein the first device is notified of a subsequent Model A UE-to-UE discovery procedure by the second device, whereby the request: - may be triggered by the second device’s intent to perform a Model A UE-to-UE discovery procedure; and - includes an indication to the first device indicating that the second device will initiate a Model A UE-to-UE relay discovery procedure; and - may include a counter or time window indicating the time until the discovery procedure is triggered; and - may include the relay service code which the second device intends to use for the Model A UE-to-UE relay discovery procedure; and / or - may include a list of relay service codes associated with connectivity service(s) which the second device provides; and upon receiving the request, if the first device wishes to be announced in said Model A UE- too-UE relay discovery procedure, the first device verifies whether it is authorized for discovery using the connectivity service associated with the received relay service code, or any of the received relay service codes in the request, and upon successful verification, the first device constructs a response message which: - includes the User Info ID of the first device protected using security materials associated with a ProSe service in which the first device is authorized for discovery; or - includes several instances of the User Info ID of the first device wherein each instance is protected using security materials associated with a ProSe service in which the first device is authorized for discovery; or - includes the User Info ID unprotected; and - may include a ProSe Restricted Code or multiple ProSe restricted codes associated with the ProSe service in which the first device is authorized for discovery;and - may include the relay service code associated with the connectivity service in which the first device is authorized for discovery; or - may include a relay service code selected by the first device, which is associated with a connectivity service in which the first device is authoried for discovery. Section: Unicast direct communication – User Info ID protection According to clause 6.1.3.3.3 of TS 33.503, the User Info IDs of End UEs (i.e., Discoverer End UE and Discoveree End UE in Model B discovery, and Announcing End UE in Model A discovery) are protected end-to-end between the end UEs within the direct discovery set. This information is too sensitive to be protected with the security keying materials associated to the relay service code. However, according to clause 6.4.3.7.1 of TS 23.304, the direct communication request (DCR) message over the first and the second hop includes the same set of UEs’ (i.e., source End UE, target End UE, and UE-to-UE relay) User Info IDs, which according to TS 33.503 (e.g., clause 6.6.3.1) are not protected. Furthermore, the User Infos (e.g., Application layer IDs or User Info IDs) exchanged between a Source-UE and a Target-U during direct communication establishment, as described in clause 6.2 of TS 33.503, or between Remote-UE and UE-to-Network relay UE, in the context of UE-to-Network direct communication establishment, as described in clause 6.3 of TS 33.503 are also sent unprotected. It is unclear how the User Infos may be protected, in particular, because different procedures may rely on different trust assumptions and may require different keying materials. Furthermore, the target entity requiring the User Infos may be different. Thus, it is challenging to find an overall / applicable procedure that is applicable to all use cases. Hence, it is the object of the following embodiments to address these issues. In an embodiment that may be combined with other embodiments or used independently, the User Infos (e.g., Application Layer IDs) exchanged between Source-UE and Target-UE may be protected by reusing the same security mechanism described in clause 6.3.5, wherein clause A.5 used to compute the DCR confidentiality keystream is adapted to use a ProSe code (e.g., ProSe Restricted Code) instead of the RSC as parameter P1, and accordingly, L1 is adapted to be the length of said ProSe code, whereby the DCR confidentiality keystream is set to the L least significant bits of the output of the KDF, where L=length of User Infos included (e.g., could be only Source-UE Application Layer ID, or both Source and Target UEs Application Layer IDs), and the security materials used to derive the DCR confidentiality keystream (e.g., DUCK) and compute the MIC (e.g., DUIK) may be associated with the ProSe service. On the receiving end, the Target-UE may process (i.e., decrypt and integrity verify) the protected User Info in the DCR message using on the security materials (e.g., DUCK) associated with ProSe codes (e.g., ProSe Restricted Codes) it is provisioned with. If the User Infos include the target UE’s application layer ID, the target UE may identify the correct keys based on whether the decrypted target UE’s user info matches its application layer ID, and in case of mismatch, the target UE skips integrity verification and tries the next security materials. Otherwise (i.e., if target UE’s user info is not included), the target UE may be required to perform both decryption and integrity verification to identify the correct security materials. In a related embodiment to the previous one that may be combined with other embodiments or used independently, the User Infos (e.g., Application Layer IDs) exchanged between Source-UE and Target-UE may be protected by adapting the confidentiality algorithm in clause A.7 since it allows protecting User Infos of a longer length. Clause A.7 may be adapted to direct communication messages (e.g., DCR message) in terms of message length and fields to be protected, or to be left unprotected, and whose length may be subtracted from the LENGTH parameter. Additionally, an encrypted_bit_mask tailored to the communication scenario (e.g., between a Source and a Target UE) may be configured or provisioned to the UEs by the network. In another embodiment that may be combined with other embodiment or used independently, the User Infos (e.g., User Info IDs) exchanged between Remote-UE and UE-to-Network relay UE may be protected by extending the security mechanism described in clause 6.3.5, whereby clause A.5 used to compute the DCR confidentiality keystream extends the length of the keystream L to also include the lengths of Remote-UE and UE-to-Network relay’s User Infos. The security materials used for the keystream derivation and MIC calculation are associated with the relay service. Alternatively, the Remote UE may not send any user info IDs in the DCR message, given that UE-to-Network Relay may be able to identify the Remote UE through the destination L2 ID, which is also used to identify the security keys associated with the RSC to be used. In a related embodiment to the previous one that may be combined with other embodiments or used independently, the User Infos (e.g., Application Layer IDs and / or User Info IDs) exchanged between Remote-UE and UE-to-Network relay UE may be protected by adapting the confidentiality algorithm in clause A.7 since it allows protecting User Infos of a longer length. Accordingly, Clause A.7 may be adapted to direct communication messages (e.g., DCR message) in terms of message length and fields to be protected, or to be left unprotected, and whose length may be subtracted from the LENGTH parameter. Additionally, an encrypted_bit_mask tailored to the communication scenario (e.g., between a Remote UE and a UE-to-Network relay UE) may be configured or provisioned to the UEs by the network. In another embodiment that may be combined with other embodiments or used independently, the User Infos (e.g., source and target end UE’s Application layer IDs and UE-to-UE relay UE’s User Info ID) exchanged between end UEs and / or between end UEs and UE-to-UE relay during unicast link establishment in a UE-to-UE relay communication scenario may be protected in at least one of the following ways: - If the security procedure is with network assistance: o Similarly to the U2N-relay communication scenario, wherein section A.5 defining the DCR confidentiality keystream may be adapted to extend the length of the keystream to consider the length of the UE-to-UE relay UE’s User Info ID, and protect it together with the RSC and CP / UP PRUK ID using the security materials associated with the relay / connectivity service, whereas the end UE’s User Infos (e.g., Application Layer IDs) may be protected in at least one of the following ways: § Using selected keying materials, e.g., similarly to during discovery, the selected keying materials may be the security materials (e.g., DUCK / DUSK / DUIK) associated with the ProSe service or using one or more keys shared, -or one or more keys derived from one or more keys shared - with a core network, e.g., PRUK. § Similarly to during discovery, but without separating the identifiers i.e., the Application Layer IDs of source and target end UEs are protected together e.g., as described in step 1, clause 6.1.3.3.3.2 of TS 33.503 (v18.1.0), and using the selected security materials. § Using a mechanism based on section A.5 (for confidentiality) and A.9 (for integrity) whereby the User Infos may be protected together, or separately, and using the selected security materials. § Source end UE may only send its User Info in the first DCR message, protected as in the first or third bullet, using the selected security materials , and only upon security establishment, it may provide the target end UE’s user info (e.g., in Direct Security Mode Complete message) protected using the selected security materials to the UE-to-UE relay to initiate direct link establishment in the second hop. § Using a KDF to derive a key, e.g., derive a key from the DUCK, where the key may be used in combination with a New Radio Encryption Algorithm (NEA) to protect the data. § Based on the confidentiality algorithm in clause A.7 since it allows protecting User Infos of a longer length. - If the security procedure is without network assistance: o Similarly to the U2N-relay communication scenario, wherein section A.5 defining the DCR confidentiality keystream may be adapted to set UP / CP PRUK ID length to zero and add U2U-relay UE’s User Info ID length, such that it is protected together with the RSC using the security materials associated with the relay / connectivity service, whereas the end UE’s User Infos (e.g., Application Layer ID) may be protected similarly to as described above, for the security procedure with network assistance, using the security materials associated with the ProSe service. It is worth noting that in UE-to-UE relay communication, end UE’s user infos (e.g., Application Layer IDs) may require protection end-to-end, hence the use of the security materials associated with the ProSe service. As such, and to enable the target end UE to identify the security materials to be used to undo the protection for the end-to-end protected user infos, the UE-to-UE relay UE may use the same Layer-2 (source) ID received from target end UE in the discovery response message, as the destination Layer-2 ID in the DCR message in the second hop. Furthermore, when target end UE initiate the Direct Communication Security Establishment procedure, it may also include the set of user infos (e.g., source and target end UEs’ Application Layer IDs) in the Direct Communication Security Request (DCSR) protected similarly to as described above, depending on whether the security procedure is with, or without, network assistance, and using the security materials associated with the ProSe Service, whereas the UE-to-UE relay UE’s User Info ID, may also be protected similarly i.e., together with RSC and UP.CP PRUK-ID if the security procedure is with network assistance, or together with RSC, if the security procedure is without network assistance, using the security materials associated with the relay / connectivity service. In general, it is described a method for secure transmission of User Infos (e.g., User Info IDs or Application Layer IDs) in a communication procedure wherein the method comprises the steps of: - determining the communication procedure out of a plurality of communication procedures (e.g., direct communication, UE-to-Network communication, or UE-to-UE relay communication); and - if the communication procedure is a relayed communication procedure (e.g. UE-to-UE relay communication), determining based on network assistance security indication associated with the relay service code used the network assistance mode to be used in the communication procedure security establishment (e.g., with network assistance or without network assistance), and - determining User Infos to be included in a message, e.g., a Direct Communication Request message, in the communication procedure based on the purpose and type of the communication procedure, - selecting suitable keying materials to protect the determined User Infos based on the purpose and type of the communication procedure and the network assistance mode, - applying the selected keying materials and a security algorithm (e.g., confidentiality algorithm) adaptable to be used by the plurality of communication procedures. In general, it is described a method for secure reception of User Info IDs in a communication procedure, wherein the method comprises the steps of: - determining the communication procedure out of a plurality of communication procedures (e.g., direct communication, UE-to-Network communication, or UE-to-UE relay communication), - if the communication procedure is a relayed communication procedure (e.g. UE-to-UE), determining based on network assistance security indication associated with the relay service code used the network assistance mode to be used in the communication procedure security establishment (e.g., with network assistance or without network assistance), - determining User Infos included in a message, e.g., a Direct Communication Request message, in the communication procedure based on the purpose and type of the communication procedure, - selecting suitable keying materials to securely retrieve (e.g., decrypt and / or integrity verify) the determined User Infos based on the purpose and type of the communication procedure and the network assistance mode, - applying the selected keying materials and a security algorithm (e.g., confidentiality algorithm) adaptable to be used by the plurality of communication procedures. In an embodiment that may be combined with other embodiments or used independently, the User Info IDs of the End UEs (i.e., Source End UE, Target End UE) may be protected following the same procedure used to protect the direct discovery set during discovery phase, as described in clause 6.1.3.2.3 of TS 33.503, wherein the User Info IDs of the End EUs are end-to-end protected with the security materials associated with the ProSe service. This information may be then forwarded to the core network in the key request message and the core network may decrypt / integrity verify it. In another embodiment that may be combined with other embodiments or used independently, when the User Info IDs are protected end-to-end in the Direct Communication Request Message using the security materials associated with the ProSe Service and the Relay Service Code is associated with the security procedure with network assistance, the DCR message further contains a UE identifier (e.g., UP / CP PRUK-ID or SUCI) which may be used by the core network to identify the security materials to undo the protection for User Info IDs. For instance, if the UE-to-UE relay communication security establishment is performed over User Plane, when the UE-to-UE relay receives the DCR message, it may send a Key Request to its 5G PKMF which, among other parameters, includes UP- PRUK ID or the SUCI, RSC, the protected User Info IDs; Upon verifying the UE-to-UE relay's authorization to provide relay services, the 5G PKMF of the relay may send a Key Request including UP-PRUK ID or SUCI or Source End UE and the protected User Info IDs to the 5G PKMF of Source end UE; upon receiving the Key Request, the 5G PKMF of Source end UE checks based on UP- PRUK ID or SUCI and RSC whether Source end UE is authorized to use the relay service, and based on the UE's identifier (i.e., UP-PRUK ID or SUPI) the 5G PKMF retrieves the security materials associated with the ProSe service(s) for which the UE is authorized for discovery, undo the protection of the User Info IDs, and verify whether the Source end UE is authorized to establish a PC5 communication link with the Target end UE, if so, the 5G PKMF of the Source end UE generates and sends a Key response to the 5G PKMF of the UE-to-UE relay containing K_NRP and K_NRP freshness parameter 2. Similarly, if the UE-to-UE relay communication security establishment is performed over Control Plane, the UE-to-UE relay sends a Key Request to its AMF including SUCI or CP-PRUK ID, RSC, Nonce_1, and the protected User Info IDs received in the DCR message, and upon verifying the UE-to-UE relay's authorization to provide relay services, the relay's AMF forwards the parameters received in the Key Request to the AUSF of the Source End UE, which selects and sends a ProSeKey_get request message containing RSC, CP-PRUK ID, and the protected User Info IDs to the PAnF identified with CP-PRUK ID; upon receiving the ProSeKey_get request message, PAnF may retrieve the security materials associated with the ProSe service(s) for which Source end UE is authorized for discovery, then undo the protection of the User Info IDs, the PAnF further retrieves CP-PRUK and verifies (e.g., with UDM) whether the Source end UE is authorized to use the UE-to-UE relay services and whether it is authorized to establish a PC5 communication link with Target end UE, if so, PAnF sends a ProSeKey_get response message with CP-PRUK to the AUSF, which then performs the rest of the procedure from step 11 onwards, as described in clause 6.3.3.3.2 of TS 33.503. In another related embodiment that may be combined with other embodiments (e.g., the previous one) or used independently, the User Info IDs may not be protected with the security materials associated with the ProSe service(s) for which the UE is authorized for discovery, but with other key, e.g., a key derived from the UP / CP PRUK or KAUSF. In which way, when the core network receives the UP / CP PRUK ID or SUCI, the core network can directly obtain the key to be used to decrypt / integrity verify the protected User Info IDs. In another embodiment that may be combined with other embodiments or used independently, during UE-to-UE relay communication security establishment, the Direct Communication Request in the second hop (i.e., from UE-to-UE relay to Target End UE) may include the User Info IDs of Source end UE and Target end UE end-to-end protected using the security materials associated with the ProSe service or other keying materials as per other embodiments (e.g., previous one). Upon receiving the DCR message, Target End UE may undo the protection and verify whether the DCR message is intended for it, and if so, it may protect and include the User Info IDs in the Direct Communication Security Request message, as described in step 2 of Fig.6.6.3.1-1 of TS 33.503, such that UE-to-UE relay may forward the protected User Info IDs to the 5G PKMF of Target end UE (e.g., in case of User Plane based security establishment), or to the AUSF of Target end UE (e.g., in case of Control Plane based security establishment) to authenticate and verify Target end UE's authorizations to use relay services and establish a PC5 communication link with Source end UE, as described in the previous embodiment. In another embodiment that may be combined with other embodiments or used independently, an end UE may include with the protected User Info IDs in the Direct Communication Request message an indication (e.g., ProSe Code, UP PRUK ID,...) which indicates to the core network the key used to protect the User Info IDs, e.g., the ProSe service with which the security materials used to protect the User Info IDs is associated. In some situations, the UE identities, e.g., User Info IDs, are confidentiality protected but in such a manner that the length of the UE identity or the lenght of two UE identities is not hidden. For instance: - In discovery model A, the User Info ID of the source UE is encrypted, but the length of the User Info ID can be guessed since other parameters have a fixed length. Thus, it may be possible to identify a UE by the length of its User Info ID, e.g., when it is too long or too short, - In discovery model B, the User Info IDs of the source UE and target UE are encrypted, but the combined length of the User Info IDs can be guessed since other parameters have a fixed length. Thus, it may be possible to identify a given connection between two UEs by observing the combined length of the User Info IDs, These problems may also happen when the User Info ID(s) are exchanged in a direct communication request if they / it are / is not protected in a way that the length of the User Info ID(s) are / is hidden. This may be done by performing one or more of the following actions when encoding and exchanging the ID, in particular, User Info ID: a) Padding the ID to a fixed length, e.g., the maximum length of the field carrying the ID, e.g., if an ID is k, e.g., 8 bytes long and the field can be up to n, e.g., 256 bytes long, then the first l bits (e.g., log2(n) rounded upwards) byte of the ID may indicate the length in bytes of the ID, the following k bytes may include the ID, and the remaining n – k - l bytes may be padded information, b) The padding may be done by using all 0s, or all 1s, or setting them at random, c) padding the ID in a randomized manner, e.g., adding a random number of bits or bytes to the ID such that the length of the field transporting the ID is different than the length of the ID itself, d) Splitting the ID into two ID parts and exchanging the two ID parts in two messages where the ID part in each of the messages may be padded individually, e) changing the padding length of the ID, e.g., randomized ID length, every time the ID is exchanged over the air (e.g., a sent in a discovery message or direct communication request), f) sending a fixed length identifier indicative of the ID, e.g., if there are 2^n UEs in a group, each of them linked to a different User Info ID, the exchanged fixed length identifier may be an n-bit identifier that identifies which one of the User Info IDs is used. In general, it is described a method that may be implemented in a system comprising an end UE (e.g., source UE) and a UE relay (e.g., UE-to-UE relay) adapted to: - selecting, by the end UE, a relay UE based on a discovery message exchanged during a discovery phase wherein the selection is based on the relay service code (RSC) in the discovery message, - preparing, by the end UE, a direct communication request including the selected RSC and the identity of the end UE, - sending, by the end UE, the direct communication request, wherein the identity of the end UE is protected. Section: UE-to-UE Relay direct communication – security procedure without network assistance Clause 6.6.3.2 in TS 33.305 v18.0.0 describes Security of 5G ProSe PC5 Communication for 5G ProSe Layer-3 UE-to-UE Relay without network assistance. A problem in this approach is that a UE-to-UE relay may receive a DCR message with an RSC and trigger the security procedure without network assistance. This may however not always work because a remote UE may have discovered the UE-to-UE relay previously, and the security credentials may have become invalid in the meantime. Thus, it is an object to address this problem. To this end, in an embodiment that may be combined with other embodiments or used independently related to the UE-to-UE Relay’s support of the selected security procedure (e.g., with or without network assistance), upon receiving a Direct Communication Request (DCR) message from an end UE, e.g., Source 5G ProSe End UE, which includes an RSC associated with the Network Assistance Security Indicator indicating the security procedures without network assistance are required, the 5G ProSe UE-to-UE Relay needs to make sure it is provisioned with valid long term credentials, and thus, supports the security procedures without network assistance prior to initiating said security procedures. If the 5G ProSe UE-to-UE Relay does not support the security procedures without network assistance, it shall not perform / initiate the security procedures without network assistance and it may reject the Direct Communication Request message. The rejection may be done by means of a message that may include the cause of the rejection or an RSC enabling the security establishment.The rejection may consist in not replying to the DCR message. The rejection may trigger the distribution of discovery messages, e.g. Model A. In an embodiment, If the 5G ProSe direct link establishment procedure is for 5G ProSe direct communication between the source 5G ProSe end UE and the 5G ProSe UE-to-UE relay UE and is using the security procedure without network assistance, and the target UE acting as the 5G ProSe UE-to-UE relay UE does not have valid long term credentials, as specified in 33.536, the 5G ProSe UE-to-UE relay UE shall send a PROSE DIRECT LINK ESTABLISHMENT REJECT message containing PC5 signalling protocol cause value #zz "security procedure unsupported" to the source 5G ProSe end UE. security procedure eIn another embodiment, If the 5G ProSe direct link establishment procedure is for 5G ProSe direct communication between the 5G ProSe UE-to-UE relay UE and the target 5G ProSe end UE and is using the security procedure without network assistance, and the target UE acting as the 5G ProSe target end UE does not have valid long term credentials, as specified in 33.536, the 5G ProSe target end UE shall send a PROSE DIRECT LINK ESTABLISHMENT REJECT message containing PC5 signalling protocol cause value #zz "security procedure unsupported" to the 5G ProSe UE-to-UE relay. Upon receiving the PROSE DIRECT LINK ESTABLISHMENT REJECT message containing PC5 signalling protocol cause value #zz "security procedure unsupported", the initiating UE (i.e., 5G ProSe UE-to-UE relay) shall send PROSE DIRECT LINK ESTABLISHMENT REJECT message containing a PC5 signalling protocol cause "Failure from 5G ProSe end UE" and the PC5 end UE failure cause set to ##zz "security procedure unsupported".eIn another embodiment, If the 5G ProSe direct link establishment procedure is for 5G ProSe direct communication between the 5G ProSe UE-to-UE relay UE and the target 5G ProSe end UE and is using the security procedure with network assistance, and the target UE acting as the 5G ProSe UE-to-UE relay UE is not served by NG-RAN (e.g., due to moving outside of 3GPP coverage), the 5G ProSe UE-to-UE relay UE shall send a PROSE DIRECT LINK ESTABLISHMENT REJECT message containing PC5 signalling protocol cause value #zz "security procedure unsupported" to the target 5G ProSe end UE and to the source 5G ProSe end UE. eA further embodiment that may be combined with other embodiments or used independently aims at handling of error situations. In this embodiment, a UE (e.g., UE-to-UE relay or Target end UE) may not support a security procedure e.g., due to a change in the coverage status of UE-to-UE relay (e.g., moving outside 3GPP coverage), or expiry and / or unavailability of long term credentials (e.g., at the Target end UE). The UE may indicate in the DIRECT ESTABLISHMENT REJECT MESSAGE whether it supports the alternative security procedure (e.g., security procedure with / without network assistance, when UE-to-UE relay moves into / outside 3GPP coverage). The UE (UE (e.g., UE-to-UE relay or end UE) may indicate this alternative support for example by including an RSC (or an indication thereof e.g. bitmap, or flag) associated with a Network Assistance Security Indication indicating the alternative security procedure (i.e., with / without network assistance) in the DIRECT ESTABLISHMENT REJECT MESSAGE. Additionally, prior to indicating the supported security procedure, the UE (e.g., UE-to-UE relay or end UE) may verify whether it indeed supports the indicated alternative security procedure e.g, UE- to-UE relay has moved within coverage or that UE (e.g., UE-to-UE relay or target end UE) has valid long-term credentials. eIn an embodiment that may be combined with the previous embodiment or used independently, the RSC associated with a Network Assistance Security Indication indicating an alternative security procedure in the DIRECT ESTABLISHMENT REJECT MESSAGE may be protected using the security materials associated with the RSC received in the DCR message (e.g., in UE-to-UE relay's case) or the Direct Communication Security Request (DCSR) (i.e., the RSC associated with the security procedure that is not supported). This has the advantage of allowing the UE initiating the Direct communication establishment procedure to process and retrieve the RSC to be used subsequently (i.e., in the second attempt to establish the link with the alternative security procedure). In another embodiment that may be combined with previous embodiments or used independently, the initiating UE (e.g., Source end UE in the first hop, or Target end UE in the second hop) upon receiving a DIRECT COMMUNICATION REJECT MESSAGE containing an RSC associated with an alternative security procedure, verifies whether it supports said alternative security procedure (e.g., has long term credentials) and / or whether it matches one of the RSCs it has been configured with by the network. In the previous two embodiments, the RSC (RSC2) associated with a Network Assistance Security Indication indicating an alternative security procedure in the DIRECT ESTABLISHMENT REJECT MESSAGE may be protected using the security materials associated with the RSC (RSC1) received in the DCR message. This gives guarantees to the party receiving the message that the sender has the keying materials associated to RSC1, but not to RSC2. Discovery messages including RSC2 are usually protected with the keying materials associated to RSC2. Thus, in another embodiment that may be combined with previous embodiments or used independently, RSC2 included in the DIRECT ESTABLISHMENT REJECT MESSAGE is first protected with the keying materials associated to RSC2, and then the DIRECT ESTABLISHMENT REJECT MESSAGE is protected with the keying materials associated to RSC1. If this is done, this requires a UE, e.g., UE-to-UE relay to first protect RSC2 with the keying materials associated to RSC2, and then insert the protected RSC2 (e.g., encrypted and including a MIC) in the DIRECT ESTABLISHMENT REJECT MESSAGE, and then protect the message with the keying materials of RSC1. Similarly, a UE receiving said protected message, e.g., the source UE, needs to first process it with security keying materials associated to RSC1, and then process the protected RSC field. To this end, it may need to try out all keys for all RSCs it is associated with. Or if RSC2 is not confidentiality protected, it may then look up the integrity key associated to RSC2 and just check the MIC. In another embodiment that may be combined with previous embodiments or used independently, the DIRECT ESTABLISHMENT REJECT MESSAGE may be protected using the security materials associated with the RSC (RSC1) received in the DCR message and contains a discovery message, e.g., model A, containing RSC2 and protected with the keys associated to RSC2. In another embodiment that may be combined with previous embodiments or used independently, the transmission of a DIRECT ESTABLISHMENT REJECT MESSAGE with, e.g., a failure cause ”security procedure unsupported" may trigger the transmission of a discovery message , e.g., model A, containing RSC2 and protected with the keys associated to RSC2. In another embodiment that may be combined with previous embodiment or used independently, if the UE-to-UE relay receives a DIRECT SECURITY ESTABLISHMENT REJECT MESSAGE from the Target end UE (e.g., due to a lack of valid long term credentials), the UE-to-UE relay may need to inform the Source end UE of such failure and the failure cause through a DIRECT ESTABLISHMENT REJECT MESSAGE, in which the UE-to-UE relay may set the PC5 protocol cause value set to "Failure from 5G ProSe end UE" and also include a PC5 end UE failure cause IE that is set to "security procedure unsupported" to clarify to source end UE the failure cause. In another embodiment that may be combined with the previous embodiment or used independently, if a target UE (e.g., UE-to-UE Relay or Target end UE) receives a PC5 discovery solicitation message containing an RSC associated with a NASI indicating the security procedure without network assistance is to be used, and the target UE is not provisioned and / or no longer has valid long term credentials, the target UE may indicate its lack of valid long term credentials in the PC5 discovery response message to the other UEs (i.e., UE-to-UE Relay and source end UE when target UE is the target end UE, or source end UE when target UE refers to UE-to-UE Relay). This has the advantage of saving the source end UE from starting a DIRECT LINK ESTABLISHMENT PROCEDURE that will subsequently end up with a DIRECT ESTABLISHMENT REJECT message. As such, the UE may avoid starting the direct link establishment procedure with said target UE. Additionally such indication may be an explicit indication e.g., flipping the NASI bit of the same RSC, or an implicit indication e.g., excluding a parameter e.g., User Info ID of the UE-to-UE or of Target end UE User info from the relayed PC5 response message to indicate to the source end UE which UE doesn't support the security procedure. In another embodiment that may be combined with previous embodiments or used separately, if UE-to-UE relay indicates in a DIRECT ESTABLISHMENT REJECT message a failure to establish a PC5 communication link with target end UE (e.g., due to target end UE lacking valid long term credentials, due to congestion, etc), UE-to-UE relay may include a back-off timer determining a time window during which UE-to-UE relay waits on a decision from Source end UE on whether it wants nonetheless to establish a secure PC5 link over the first hop. This is due to the security establishment procedure being already conducted between source end UE and UE-to-UE relay. From the source end UE's perspective, upon receiving a DIRECT ESTABLISHMENT REJECT message due to failure in establishing a secure link over the second hop, if source end UE wishes to establish a secure link with the UE-to-UE relay, it may respond to the DIRECT ESTABLISHMENT REJECT message with a PC5 direct communication message requesting the UE-to-UE relay to complete the establishment of the secure link in the first hop (i.e., send a DIRECT COMMUNICATION ACCEPT message). Thus, in addition to previous embodiments, this has the advantage of optimizing PC5 link establishment between UEs also in a multi-hop communication scenario. The previous embodiment allows establishing one hop communication even if the establishment of a PC5 communication link with target end UE fails. This situation may also happen in U2U multihop and U2N multihop scenarios as described in other embodiments, and the previous embodiment may allow establishing at least part of the route even if the establishment of the PC5 communication link in one of the hops fails. At this point, the end UE may use the existing route to try to establish the desired end-to-end communication. For instance, the end UE may send a direct discovery set (in the case of multi-hop UE to UE relay) over the established route so that each of the UE-to-UE relays perform discovery. Thus, in accordance with a general definition of the previous set of embodiments, it is proposed a terminal device, such as a UE (e.g., UE-to-UE relay or Target end UE), the UE comprising - a controller that determines that a first security procedure is not supported by the terminal device, e.g., due to a change in the coverage status of UE-to-UE relay (e.g., moving outside 3GPP coverage), or expiry and / or unavailability of long term credentials (e.g., at the Target end UE), wherein the controller determines whether a second security procedure is supported; - a transmitter configured by the controller to transmit or indicate in a connection rejection message (such as a DIRECT ESTABLISHMENT REJECT MESSAGE), one and / or the other of: o whether it supports the second security procedure (e.g., security procedure with / without network assistance, when UE-to-UE relay moves into / outside 3GPP coverage) or o to indicate the second security procedure if it is determined that it is supported. This alternative support may for example be indicated by including an RSC (or an indication thereof e.g. bitmap, or flag) associated with a Network Assistance Security Indication indicating the alternative security procedure (i.e., with / without network assistance) in the DIRECT ESTABLISHMENT REJECT MESSAGE. In accordance with a general definition of this embodiment, it is described a method that may be implemented in a system comprising an end UE (e.g., source UE) and a UE relay (e.g., UE-to-UE relay) adapted to: - receiving, by the UE relay, a direct communication request including a relay service code (RSC), - checking, by the UE relay, whether the RSC is associated with a Network Assistance Security Indicator indicating the security procedures without network assistance are required, - determining, by the UE relay, whether to execute the security procedures without network assistance, wherein determining whether to execute the security procedures without network assistance requires checking whether the UE relay fulfils at least one of the following conditions: - the UE relay is configured with valid long-term credentials, and - the UE relay configuration or policy allows executing the security procedures without network assistance when the UE relay is in 5G network coverage. Section: Discovery and security procedures for sidelink multi-hop networks UE-to-UE discovery and security procedures have been developed in Release 18 and the corresponding security procedures are available in TS 33.503 v1.0.0. In Release 19 it is foreseeable that UE-to-UE discovery and security procedures are extended to allow for multi-hop networks as shown in Fig.6. In a multi-hop network, two UEs (e.g., 601 and 604 in Fig.6) are connected by one or more UE-to-UE relays (e.g., 602 and 603 in Fig.6). In current discovery procedures for UE-to-UE relay, the discovery message in model A and / or model B carries a relay service code that is linked to an indication of the security procedure to be performed, with or without network assistance. Currently, TS 33.503 v1.0.0 and TS 24.554 only mention two options, with or without network assistance. Furthermore, when a UE-to-UE relay receives a discovery message with an RSC linked to an indication of a security procedure, e.g., with network assistance and the UE-to-UE relay is out of coverage, the UE-to-UE relay does not forward the discovery message. This is a problem because setting up a multi-hop communication over multiple relays would require that all UE-to-UE relays are in coverage, or out-of-coverage. Another problem is that the (security links of) current UE-to-UE relay procedure are established hop after hop. This has two issues: first, it is slower because each of the hops requires an interaction with the core network (in the case of a security procedure with network assistance, sending a key request and receiving a key response) to retrieve the corresponding keys; second, it may not be a good overall approach for secure routing because if one of the hops is not authorized, the route establishment needs to start from scratch. Another problem is that when the number of hops increases, the latency between the communicating UEs also increases. This may lead to a situation in which discovery / communication messages are dropped because the UTC-based counter of the transmitting / sending UE cannot be reconciled properly anymore and / or the received message is considered to be too old. To address this problem, the following embodiments are applicable: In an embodiment, the discovery message includes an indication of multi-hop path establishment. This indication serves the purpose of establishing a route with one or more hops as in Fig.6. The discovery message may also include the maximum number of hops that are allowed, e.g., N hops. The processing at a UE-to-UE relay may be such that every time that a discovery message is forwarded, the UE-to-UE relay forwarding the discovery message may decrease this value by one. The receiving end UE may use this value to determine the best route. The processing at a UE-to-UE relay may be such that every time that a discovery message is forwarded, the UE-to-UE relay forwarding the discovery message may include its identifier, e.g., its User Info ID, with the purpose of identifying the route. The receiving end UE may also determine the number of hops by counting the number of identifiers that may have been included in the discovery message. Other means to determine the number of hops may be feasible, e.g., by increasing the number of hops. In an embodiment, a discovery message may include an indication defining how far a given target is. For instance, when a UE is announcing its connectivity to the network as a UE-to-Network relay, it may include a field indicating how many hops away from the network it is located. A UE to Network relay that is directly connected to a base station may announce a value “0”. If a remote UE is connected to previous UE to Network relay, and it becomes itself a UE to Network relay, it may announce value “1”, and so on. A UE receiving a discovery message including this indication may use this indication to select a relay device, e.g., the one that is closest to the target. In an embodiment, if a multi-hop indication is included in the discovery message, a UE-to-UE relay may accept / forward a discovery message with an RSC bound to an indication of a security procedure with network assistance even if the UE-to-UE relay is out-of-coverage as long as the UE- to-UE relay supports / is configured with said RSC and has the corresponding keying materials. Similarly, a UE-to-UE relay may accept a discovery message with an RSC bound to an indication of a security procedure without network assistance even if the UE-to-UE relay is in-coverage as long as the UE-to-UE relay supports / is configured with said RSC. This embodiment allows establishing a multi-hop path even if not all UE-to-UE relays have the same coverage status. In a further embodiment, the (discovery) message going from the sending end UE towards the receiving end UE is extended hop by hop with an identifier of each of the hops, e.g., the UE-to-UE Relay’s User Info IDs or L2 addresses. This allows the end UEs to determine the path route and / or best path route. For instance, in discovery model B, the receiving end UE of the first discovery message can determine the best route and path, e.g., the route with the least number of hops. The receiving end UE can then reply with a second discovery message including the chosen route including the User Info IDs or L2 addresses of the selected UE-to-UE relays. In a further embodiment, the information included in the (discovery) message is protected with keying materials (e.g., DUCK, DUSK, DUIK as per TS 33.303) bound to the RSC. In a further embodiment, an end UE (e.g., the sending end UE that may have started the discovery phase) or one of the UE-to-UE relays that are in coverage or the UE-to-Network relay that is closest to the network may be in charge of sending a request to the core network to authorize two or more of the UEs involved in the path and retrieve the communication parameters to establish the secure links between the hops. This may require that each of the devices involved securely share required security parameters (e.g., their PRUK-IDs) with the UE sending said request to the network, e.g., the sending end-UE. The sending end-UE can decrypt / verify said security parameters if those security parameters are protected with the discovery keys bound to the RSC (as in Clause 6.3.5 in TS 33.503) and send them in a key request to the core network. In the case that the sending end-UE sends this key request (e.g., similar to step 4a in Clause 6.3.3.2.2 in TS 33.503) to the core network for route establishment, the reception of the key response (e.g., step 4.e in Clause 6.3.3.2.2) from the core network gives assurances to the sending end-UE about the selected route and the hops / UE relays in the path. In general, a UE (e.g., sending End UE) may send a route request (extension of the key request above) and receive a route response (extension of the key response) from the core network after the discovery procedure where the information in the route request message is based on the information collected during the discovery procedure and may include the PRUK-IDs of the hops and / or SUCIs and / or NRP_freshness_parameter_1. Additionally and / or alternatively, the security parameters shared by a UE with the sending end-UE may be end-to-end protected, e.g., with a key shared by the UE and the PKMF. In this case, the UE-to-UE relay is not capable of tampering with / accessing said security parameters. Note that this embodiment describes a solution in which the whole path can be determined / established in a single step. In an embodiment, the sending UE sending the route request message may be the sending end UE that has initiated the discovery procedure or the receiving end UE that has received the discovery message. In this case, it is advantageous if the discovery message received by the sending end UE (or the receiving end UE) includes, next to the User Info ID of each of the UE-to-UE relay hops also the security information required to establish a secure connection in each of the links between the hops, I.e., PRUK-IDs and / or SUCI and / or NRP_freshness_parameter_1. This requires that each UE that is passing this second discovery message includes its security parameters. It is to be noted that in the case of a single message going from the sending end UE to the receiving end UE, this may be considered as an integrated discovery message used to directly determine the route and establish the security between the links in the multi-hop route without explicit discovery phase. In an embodiment, the sending UE sending the route request may be the receiving end UE where the discovery procedure ends. In this case, it is advantageous if the discovery message received by the sending end UE includes, next to the User Info ID of each of the UE-to-UE relay hops also the security information required to establish a secure connection in each of the links between the hops, I.e., PRUK-IDs and / or SUCI and / or NRP_freshness_parameter_1. This requires that each UE passing / forwarding the discovery message includes its security parameters. In an embodiment, the path response (extension of the key response) may include K_NRP, K_NRP freshness parameter_2 for each of the hops. In an embodiment, the received K_NRP and K_NRP freshness parameter_2 are protected in such a way that only the “target” / ”destination” UEs have access to them. In particular, a single UE (e.g., the sending end UE that sent the route request message) may receive the path response message including the security parameters K_NRP and K_NRP freshness parameter_2 for the UEs, UE-to-UE relays in the selected path. The UE receiving the path response only has access to the security parameters used to establish its path. For instance, the K_NRP and K_NRP freshness parameter_2 for said UE may be encrypted shared between the UE and the core network, e.g., the K_NRP associated to that UE. The UE can then extract said security parameters and use them to establish a secure link in the first link. Once the first link security is established, the following UE-to-UE relay in the route receives the security parameters obtained in the route response message and it is only able to access the security parameters to establish secure connection of the following hop in a similar way, e.g., those parameters are the only ones protected with a key shared by the UE and the core network. This process is repeated till the link security of the last hop with the receiving end UE is established. This procedure allows for the establishment of an authenticated route. This process is illustrated in Fig.7 where 701 and 704 represent end UEs and 702 and 703 represent UE-to-UE relays.705 represents a NF in the core network in charge of handling security parameters, e.g., the PKMF. Messages 707 and 708 refer to the route request and route response.709 represents a process to establish a secure link between two UEs, in this case, 701 and 702, e.g., based on the received K_NRP and K_NRP_freshness_parameter_2. Message 710 represents the sharing of the remaining parameters received in the path response message with next hop once the secure link has been established successfully. Steps 709 and 710 are repeated for each of the subsequent hops, e.g., 711 and 712. Once the last UE 704 (e.g., receiving end UE) has established the security in the last link, UE 704 may confirm the security establishment in message 713, a path establishment confirmation message. In an embodiment, message 713 may be protected with key such as K_NRP delivered to the receiving end UE by the core network in the path response so that the first end UE (sending end UE) can receive message 713 and verify it is sent by the receiving end UE. Note that this requires the sending end UE to include in the path request an extra K_NRP_freshness_parameter_1 for the derivation of this key K_NRP. In a related embodiment, the secure link between hops may be established in parallel, and not sequentially, e.g., 709 and 711 may happen in parallel. In this case, the sending end UE or the receiving end UEs may require the reception of a confirmation message, a link establishment message. Only once all the links have been established, the sending end UE can start communicating with the receiving end UE. In a related embodiment, the security parameters received by the sending end UE may be protected in a recursive manner, e.g., as in the following message: E_k1{security_parameters_first_hop, E_k2{security_parameters_second_hop, E_k3{security_parameters_third_hop,…,E_kn{security_parameters_last_hop}...}}}. Where E_k{a,b} may refer to the encryption of the concatenation of a and b using key k. Furthermore, ki may be a key shared between UE I^th (in charge of establishing the i^th secure link) and the core network. When the first UE (e.g., sending end UE) receives above message, it can access security_parameters_first_hop, it uses them to establish the link security of the first hop, and if successful, it forwards the remaining part of the message to the second hop, I.e., E_k2{security_parameters_second_hop, E_k3{security_parameters_third_hop,…, E_kn{security_parameters_last_hop}...}}. For instance, the security_parameters_first_hop may include K_NRP, K_NRP_fresnhess_parameter_2 In an embodiment, a UE may report a route establishment link failure when the establishment of a secure link in the multi-hop route to be established fails. It may include the UE identifier of the UE with which the route establisment link failed. In an embodiment, when establishing the route, each UE is required to include its location (e.g., GPS obtained) so that the correctness of the route can be verified, e.g., by the sending / receiving end UEs or a network function in the core network. The location sharing may be done in a secure manner so that only the receiving party can access it. In an embodiment, the shared locations may be used by a UE (e.g., sending end UE) or the core network to verify its correctness from the point of view of secure routing. A UE may send a route check verification message. A UE may receive a route check confirmation message indicating whether the route is correct or not. For instance, a route may only be accepted if the location of a UE between any two other UEs in the route is within an area (e.g., a circle) whose center is somewhere between the UEs, e.g., in the middle of the straight line connecting the UEs. This ensures that an attacking UE is not placing an attacking UE far from the route. In an embodiment, the core network may support in the path selection procedure based on the core network knowledge of, e.g., the location of the UE-to-UE relays. For instance, the sending end UE may share with the core network the identity of the receiving end UE it wishes to communicate with, and the core network may send to the sending end UE a list of identifiers of the UE-to-UE relays that may serve as suitable hops in the multi-hop path given the core network knowledge of their positions. In some cases, not the sending end UE, but the first UE-to-UE relay that is in coverage may share this indication (of the identity of the receiving end UE it wishes to communicate with) with the core network. The core network may also know already whether those UE-to-UE relays already have an established PC5 communication link and may send a message to them indicating the new discovery and / or communication request, e.g., an identifier indicating the route request / requested route. The discovery message or direct communication request may then include this multi-hop route identifier so that UE-to-UE relays that receive it know whether / how to forward it. For instance, if a sending UE indicates to the network that it desires to connect to a receiving UE, the sending UE may receive a multi-hop route identifier, and the sending UE may include said multi-hop route identifier in a discovery message or direct communication request. The UE-to-UE relays may be aware already of said multi-hop route identifier and only process / forward a discovery message or direct communication request if they identify said multi-hop route identifier in the received message. A multi-hop route identifier may be configured in a UE-to-UE relay by a network function in the core network, e.g., on demand. A multi-hop route identifier may be linked to a given relay service code, for instance, a relay service code may be used to discovery relays that may offer or be part of one or more multi-hop routes and be identified by one or more multi-hop route identifiers. In an embodiment that may be combined with other embodiments or used independently, a multi-hop route identifier is a code that may be exchanged explicitly or implicitly and allows establishing a communication route over multiple hops. This identifier may be used to identify the route. In an embodiment, the UE sending the path request may include the identities (e.g., User Info IDs, PRUK-IDs, SUCIs,…) corresponding to the UE-to-UE relays in one or more possible routes. The route response includes the selected / proposed UE-to-UE relays by the core network, whereby the core network may use knowledge of, e.g., the location of the UE-to-UE relays, to make the selection / proposal. This may require that the LMF is involved to retrieve the locations of the UE-to-UE relays as required for the creation of the route. For instance, if the PKMF receives the route request (as an extension of the key request), the PKMF may then interact with the LMF. In an embodiment, a (discovery) message sent by the sending end UE may include the identities of candidate UE-to-UE relays to facilitate the discovery procedure. For instance, a discovery message may contain the User Info IDs of suitable candidate UE-to-UE relays (e.g., obtained from the core network). Only UE-to-UE relays with matching User Info IDs may reply / match said discovery messages. It is to be noted that in embodiments for multi-hop communication the devices allowing the communication between two end UEs (in the case of multi-hop UE-to-UE communication) or between a remote UE and the network (in the case of multi-hop UE-to-Network communication) may be denoted UE-to-UE relays, but may also be denoted intermediate UEs. The above embodiments may also be applicable to multi-hop PC5 communication link establishment, wherein relays (e.g., UE-to-UE Relays and / or UE-to-Network Relay) may forward / relay discovery and / or communication messages between End UEs and / or between an End- UE (Remote-UE) and the Network, taking into consideration the changes required to be implemented to adapt the procedures to a multi-hop link. For instance, the checks performed to verify e.g., the validity of an end-to-end protected direct discovery set that is relayed over multiple relays is performed at each UE-to-UE Relay that the discovery message is relayed through, and where deemed invalid by a k_th UE-to-UE Relay, the discovery message is dropped by said UE-to-UE Relay. For instance, in a UE-to-Network relay scenario with relays between a Remote UE and the UE-to- Network Relay, if an RSC mismatch or the integrity verification of the message fails at or between the relays between Remote UE and the UE-to-Network Relay, a reject message is sent back through to the Remote UE through the relays used to establish the link. For instance, to ensure the path (i.e., list of UE-to-UE Relays used to establish the link) is preserved, each relay may store an identifier of the relay from which the message was received, and the relay to which the message was relayed. For instance, a relay_indication_counter may be added to the discovery / communication message, whereby the counter is updated (e.g., incremented) every time the message is relayed, and where, if a max_limit, which may be configured by the network and / or a Source-UE (e.g., Announcing / Discoverer / Remote UE) is reached before the discovery / communication message reaches the destination UE (e.g., Target End UE / UE-to-Network Relay), the message may be dropped. For instance, in a UE-to-relay(s)-to-Network scenario, the protection of the DCR message may be adapted to account for the multitude of the RSCs that could be used between the several relay UEs, whilst the Remote UE identifier (I.e., PRUK-ID / SUCI) which remains as is may for instance be protected end- to-end between the Remote UE and the U2N Relay and / or is protected using the hop-by-hop security keys associated with the different RSCs used between the relay-UEs. Fig.8 schematically represents exemplary procedures for multi-hop (in this example, 2 hops) communication establishment in a cellular system. Previous embodiments and techniques may be applied to these procedures. Entities 800, 801, 802, 803, and 804 refer to a remote UE, a first UE to Network / UE-to-UE relay, and second UE to Network relay, a RAN device (e.g., an access device such as a gNB), and a core network (including one or multiple network functions), respectively. This figure includes two sets of procedures, 805 and 806, that may be used independently. In 805, the communication between the remote UE 800 and the core network is established hop by hop. In 806 the communication is established at once. Specific illustrative steps for the communication establishment are as follows, even if some of the steps may be performed more than once and some steps may be omitted or performed in a different order. Step 807, represents a discovery solicitation message (discovery model B) sent by UE 801 acting as a remote UE (since it is not connected to the network yet). Step 808, represents a discovery response message (discovery model B) sent by UE 802 acting as a UE to Network relay. Step 809, represents a discovery announcement message (discovery model A) sent by UE 802 acting as a UE to Network relay. Step 810, represents a direct discovery request (DCR) message sent by UE 801 to initiate the communication establishment. Step 811, represents interaction between UE 802 and the core network 804 to enable the communication establishment, e.g., a key request and a key response message. Step 812, represents messaging between UEs 801 and 802 with the goal to establish a secure PC5 communication link between both UEs. Step 813, represents a discovery solicitation message (discovery model B) sent by UE 800 acting as a remote UE (since it is not connected to the network yet). Step 814, represents a discovery response message (discovery model B) sent by UE 801 acting as a UE to Network relay. Step 815, represents a discovery announcement message (discovery model A) sent by UE 801 acting as a UE to Network relay. Note that this assumes that 801 is already connected to the network e.g., through 802, or directly. Step 816, represents a direct discovery request (DCR) message sent by UE 800 to initiate the communication establishment with UE 801. Step 817, represents interaction between UE 801 and the core network 804 to enable the communication establishment, e.g., a key request and a key response message. Step 818, represents messaging between UEs 800 and 801 with the goal to establish a secure PC5 communication link between both UEs. Step 819, represents messaging between UEs 800 and the core network or an application. This can include user plane traffic generated or received by UE 800. Step 820, represents a discovery solicitation message (discovery model B) sent by UE 800 acting as a remote UE (since it is not connected to the network yet). This discovery message aims at determining a UE to Network relay (802 in this case) over one or more UE to UE relays (801). The discovery solicitation message may include an indication and / or a counter allowing the UE-to-UE relay(s) (e.g., 801) to further relay the discovery solicitation message for a maximum number of hops (e.g., determined by the counter) to reach a UE-to-Network. Step 821, represents a discovery response message (discovery model B) sent by UE 802 acting as a UE to Network relay with the aim of confirming its presence as UE-to-Network relay to UE 802 over UE-to-UE relay 801. Step 822, represents a discovery announcement message (discovery model A) sent by UE 802 acting as a UE to Network relay to announce its presence to remote UE 800 as UE-to-Network relay over UE to UE relay 801. The discovery announcement message by 802 may include an indication and / or a counter allowing UE-to-UE relay(s) to further relay the discovery announcement message for a maximum number of hops determined by e.g., the counter, which may be set according to a policy / configuration by the network, to reach potential Remote UE(s). Step 823, represents a direct discovery (DCR) message sent by UE 800 to initiate the communication establishment with UE 801 and 802 as well as between UE 801 and 802. Step 824, represents interaction between UE 802 and the core network 804 to enable the communication establishment, e.g., a key request and a key response message. Step 825, represents messaging between UEs 800 and 801 and 802 with the goal to establish secure PC5 communication link between UEs, e.g., 800-801, and / or 801-802, and / or 800-802. Step 826, represents messaging between UEs 800 and the core network or an application. This can include user plane traffic generated or received by UE 800. It is to be noted that devices 800, 801, 802 require an initial configuration phase during which discovery parameters are configured. This phase is not shown in Fig.8. After successful establishment of communication in Step 812, UE 801 may receive a policy / authorization so that it can announce itself or respond to discovery solicitation messages acting as a UE to Network relay. Note that this configuration may have been also pre-configured in an initial step so that if the UE gains access to the network through a UE to Network relay (802), it can also become a UE to Network relay itself. Message 807 and 813 may include a field indicating whether the UE transmitting the discovery solicitation message seeks a UE to Network relay that is directly connected to the network or through one or more relays. This can serve as condition for the receiving party to determine whether a given route is suitable or not, and thus determine whether to respond to, forward / relay, or drop the discovery message. Messages 808, 809, 814 and 815 may include a field indicating whether they are connected to the network directly or through one or more relays. This can serve as a condition for the receiving party to determine whether a given route is suitable or not. Message 816 may include an indication about the number of hops it has agreed to use for the multihop communication in the previous discovery phase. This information may be then included in a key request message exchanged in the subsequent message exchange 817. This information may be checked by the core network to verify that the route is being established as foreseen (since the core network has knowledge about the network topology); additionally or alternatively, the information may be checked by the UE-to-UE relay (801) to check whether the communication link with the core network (e.g., through 802) is alive / established still. The number of hops connecting 801 and the network may also be included in a subsequent message (e.g., key response in message exchange 817) or in 818. This information (the number of hops desired and confirmed by the network) may be used as input in the authentication procedure between 800 and 801 (so that 800 gets assurances that 801 is not misbehaving) or may be shared securely end to end from the core network to UE 800 (e.g., MAC protected with a key, e.g., PRUK or a key derived from it, owned by UE 800). Message 820 may include a field indicating that UE 800 is seeking a UE with connectivity to the network (to act as a UE to Network relay). This flag may be used by the UE receiving said message to determine whether to answer with the discovery response message 821, or not. Note that this message is not only used to identify 801, but also 802 (this is a key difference with UE-to-UE relay discovery. Message 821 may include a field indicating that UE 802 has connectivity to the network (to act as a UE to Network relay). This flag may be used by the UE receiving said message to determine whether to select this UE or not. Note that this message is not only used to identify 801, but also 802 (this is a key difference with UE-to-UE relay discovery. Message 822 may include a field indicating that UE 802 has connectivity to the network (to act as a UE to Network relay). This message, when forwarded by UE 801 may include a further flag (from UE 801) to indicate that it is connected to 802. Message 823 may be a DCR message sent to 802 over 801 to trigger the distribution of parameters (e.g., keys) for the communication establishment. In particular, the DCR message sent by 800 includes the PRUK ID of 800. When the DCR message is received by 801, 801 enhances it by including also its own PRUK ID. Messages 824 are exchanged by UE 802. UE 802, with both PRUK IDs of 800 and 801, can send a key request (in the next phase 824) so that the network can authorize the communication and provide UE 802 with keying materials for the secure establishment of the communication links. Message 825 refers to the establishment of the secure communication links, e.g., as illustrated in other embodiments and where this establishment may involve a procedure for secure routing. In an embodiment that may be combined with other embodiments or used independently, an RSC is linked to information (e.g., multi-hop indication, architecture indication) determining whether the RSC may be used for the establishment of a multihop communication link over a number of hops. The RSC may also be linked to the maximum number of hops that may be performed. Fig.9 schematically represents exemplary procedures for multi-hop (in this example, 2 hops) communication establishment in a cellular system between two end UEs through for example two, e.g. ,UE-to-UE, relay UEs. Previous embodiments and techniques may also be applied to these procedures. Entities 900, 901, 902, 903, 904 represent respectively a first (source) end UE, a first (e.g, UE-to-UE) relay UE, a second (e.g., UE-to-UE) relay UE, a second (target) end UE, and the core network (or a NF therein), and 905 and 906 represent exemplary (sub-)procedures of how the PC5 link may be established between 900 and 903 through relays 901 and 902. Step 910 represents a successful discovery procedure (e.g., model B discovery) whereby 900 discovers 903 through the relays 901 and 902. The following steps / messages refer to a multi-hop relay communication procedure by which 900 and 903 establish a PC5 multi-hop secure link. This procedure may be based, e.g., on other embodiments in this invention. Message 911 refers to a Direct Communication Request (DCR) which may include the User infos of 900 and 903 that may be end-to-end protected, or protected using the security materials associated with the connectivity service (e.g., associated with the relay service code (RSC)), additionally the User Info IDs of the relays 901 and 902, that may also be protected using the security materials associated with the connectivity service (i.e., RSC) and may also include a relay service code and part, or all, of the parameters described in Table 10.3.1.1.1 of TS 24554 (v18.3.0). The connectivity service (or RSC) may also refer to a multi-hop route identifier as in other embodiments. Assuming the relay service code received in the DCR message is valid (i.e., it matches a relay service code associated with a previous multi-hop relay discovery) and is associated with a Network Assistance Security Indication (NASI) indicating that security procedures with network assistance are required, the exchange 912 represents a Key Request to a NF in the CN (e.g., PKMF) and Key Response from said NF providing the relay with security materials and parameters (e.g., KNRP, KNRPfreshness parameter 2) for security establishment e.g., Direct Auth, Key Establishment, and Security Mode security procedures, in the first hop, which is indicated by step 913. Message 914 refers to the DCR message relayed to 902, to be subsequently forwarded to 903 as indicated by message 914’. In message 914, 901 may indicate explicitly e.g., through an indication e.g., link_establishment_indication to 902 that security for the first hop has been established, or it may be indicated implicitly by removing the (CP / UP-)PRUK ID or SUCI and Freshness_parameter_1 from the DCR message (i.e., 902 may conclude that since the RSC is associated with security procedures with network assistance and the DCR message does not include end UE identifiers (e.g., CP / UP- PRUK ID or SUCI), security with the end UE has been established via a previous UE-to-UE relay UE). Upon receiving message 914, 902 may process the DCR message and check whether the DCR message includes an identifier e.g., (CP / UP-)PRUK ID, or SUCI, and / or whether it includes a relay indication (e.g., to know whether it is allowed to further relay the message), and / or a counter (e.g., giving an indication of how many hops the DCR message has crossed), and / or check which security procedure the RSC is associated with, and / or whether the DCR includes a link_establishment_indication indicating whether security for the PC5 link with the source end UE has been already established. If that is the case, and if 902 is allowed to further relay the message, 902 sends message 914’. Note that if 902 is configured to support multi-hop link communication over a maximum or two hops, and if message 914 is received from a UE-to-UE relay (e.g., 901) which may be concluded from the source layer-2 ID used, and / or from an (in / de)cremental relay counter included in the DCR message, 902 may remove the relay_indicator and / or remove the (CP / UP)-PRUK ID or SUCI from the DCR message as it is intended for the target end UE (e.g., 903). Upon receiving the DCR message 914’, target end UE 903 responds with a Direct Communication Security Request (DCSR) message 915, that may be relayed transparently by relay 902 to relay 901 given that the first hop link was established through relay 901. Alternatively, relay 902 may include in the DCSR message an indication of its coverage status e.g., such that if the RSC being used is associated with a security procedure with network assistance and 901 happens to move out of coverage, 901 may be able to fall-back / delegate the secure link establishment of the second hop to relay 902. Similar fall-back scenarios will be explained further in the communication link establishment steps indicated by clause 906 in Fig.9. Upon receiving 915, and if relay 901 supports the security procedure indicated by the relay service code, which may require security establishment with network assistance.902 may perform a key request 916 procedure similar to the one performed in step 912. Following which, 901 establishes a secure link with the target end UE 903 in Step 917. Message 918 refers to the Direct Communication Accept (DCA) message sent by the end UE 903 to relay 901 via relay 902. Upon receiving said DCA, the relay 901 sends a DCA message 919 to end UE 900, and starts forwarding data traffic between 900 and 903 through 902, which relays / forwards the traffic between 901 and 900 transparently. Note that in the described procedure, it may not be needed to establish a separate secure link between relays 901 and 902 as the link between 901 and 903 is secured end-to-end. This has the advantage of reducing latency, as establishing each hop security separately entails that at each relay, further processing is required by a relay UE to undo the protection associated with the security materials used in the (first)reception hop, then apply protection using the security materials associated with the transmission hop. This principle may also apply to a multi-hop scenario where the maximum number of hops exceeds two; The choice of a maximum number of hops secured separately may be a security configuration choice and / or a QoS requirement indicated by the UE to the relays involved in the secure link establishment e.g., during the discovery procedure. UE-to-UE relay UEs (e.g., 901 and 902 in this example, but the following may apply to a multi-hop relay discovery with N relay UEs where N exceeds two) involved in the discovery procedure, may, following a discovery procedure (e.g., model B discovery) exchange signaling messages with other UE-to-UE relay UEs to determine a main / primary relay UE, a secondary relay UE... etc, generally a prioritization list of relay UEs to establish a PC5 secure link between end UEs (e.g., 900 and 903) in a timely manner. Alternatively, the prioritization list may be determined by the network based on parameters (e.g., mobility status (e.g., whether relay UE is static, or mobile), coverage status, number of hops to both end UEs, etc) provided by the UE-to-UE relays to a designated relay UE connected to the network; said designated relay UE may be assigned a role (e.g., root relay UE) by the network if it fulfils certain conditions (e.g., static relay UE, always within NG-RAN coverage, percentage of availability above a network- defined threshold, etc). A root relay UE may indicate its (root) designation / role during discovery through an indication (e.g., a flag / bit configured / set by the network in the relay’s User Info ID), or a capability (e.g., in UE security capabilities) or the like. For an out of 3GPP coverage multi-hop relay communication establishment, the establishment of said prioritization list may be performed by a root relay UE, whereby relay UEs indicate to the root relay UE whether they are configured / provisioned with valid long-term credentials, capacity to support secure link establishment (e.g., indicate the number of link established and / or a limit / max number of allowed links)), coverage status, and / or a list of User Info IDs of UE-to-UE relays in proximity and / or participating in an established multi-relay link. The prioritization list may be stored and maintained by root relay UE and / or other relay UEs as well, and may be updated regularly through the exchange of PC5 and / or RRC signalling messages whereby relay UEs may want to indicate e.g., a change of their coverage status, capacity for secure link establishment, an updated list of UE-to-UE relays in proximity and / or participating in an established multi-relay link, and / or whether they are provisioned with valid long-term credentials. It is to be noted that the exchange of said parameters may not be solely for the purpose of updating said prioritization list, but may be used to determine whether to perform relay re-selection (e.g., in case of a link with another relay UE deteriorates) to support other established secure links which may be linking two other end UEs or a remote UE to the network. In a related but alternative description of Fig.9, the first steps till Step 914 occur in a similar manner. Upon reception of 913, the first hop is established, and relay 901 establishes the route. In this alternative description, the route 901 – 902 is already available and indicated by a multi-hop route indicator, so that Step 914 serves the purpose to indicate to 902 that a new route is being established with end UE 903. Relay 902 then forwards message 914’. Upon reception of 914’, end UE 903 responds with DCSR message 915 to relay 902 (not 901 as in the figure). The relay 902 and 903 may establish the communication link. To this end relay 902 may send a key request message 916. Upon establishment, the end UE 903 sends message 918 to relay 902, and this one sends message 919 towards relay 901 and end UE 900. This alternative description has the advantage of ensuring the security of all hops. In a further alternative description, the end UEs 900 or 903 or the relays 901 or 902 may indicate which of the devices is taking the role to interact with a network function in the core network to establish the link security. The potential change in coverage status of relay UEs 901 and 902 may hinder the secure PC5 link establishment (e.g., if the security procedure indicated by the relay service code requires network assistance). Hence, in the exemplary procedure 906, and the following description, it is described steps to ensure that PC5 link establishment is rejected only when relays both cannot ensure secure PC5 link establishment based on the security procedure (i.e., with / without network assistance) associated with the relay service code used. Message 921 may refer to a DCR message similar to message 911. Assuming the first relay UE (901) cannot perform security establishment with 900 (e.g., due to being out of 3GPP coverage while the NASI associated with the RSC used indicates that security procedures with network assistance are to be used, or if the security procedure to be used is without network assistance and the relay does not have valid long term credentials), 901 forwards the DCR message to relay 902 in step 921’. Similarly to step 914, 901 may indicate explicitly e.g., through an indication e.g., link_establishment_indication to 902 that security for the first hop has (or has not) been established, or it may be indicated implicitly by removing the (CP / UP-)PRUK ID or SUCI and Freshness_parameter_1 from the DCR message. Assuming the relay 902 can also not perform the security establishment with 900. If the security procedure without network assistance is indicated by the relay service code, 902 may send a DIRECT LINK ESTABLISHMENT REJECT message (922) to 901, which may be transparently forwarded in step 922’ to 900. Otherwise, if the security procedure with network assistance is indicated by the relay service code, and 902 is not within coverage, 902 may send a DIRECT LINK ESTABLISHMENT REJECT message (922) to 901, which upon receiving it, performs a coverage check and if it is within 3GPP coverage, it may discard / ignore / drop the rejection message and trigger a Key Request / Response procedure similar to step 912 to establish a secure PC5 communication link with 900. Otherwise, if the coverage check performed by 901 is negative (i.e., it is still out of coverage), it may forward the REJECT message to 900 in step 922’. Assuming 902 is within coverage, it triggers the Key Request / Response procedure similar to step 912 in 923, and then security establishment between 900 and 902 occurs in step 924. Following security establishment with the source end UE (900), 902 may strip the DCR message from the parameters, if any, (e.g., CP / UP PRUK ID, SUCI, Freshness_parameter_1) used for security establishment of the PC5 link between 900 and 902, and / or the link_establishment_indication (e.g., if set by 901), then forwards the DCR message to 903 in step 925. Message 926 refers to the Direct Communication Security Request sent by target end UE 903 to establish security for the second / third hop. Assuming the security procedures with network assistance are indicated by the RSC used, and 902 happens to have moved out of 3GPP coverage, 902 may forward the DCSR message 926’ to 901, which upon reception, checks its coverage status, and if it happens to also be out of 3GPP coverage, it sends a DIRECT LINK SECURITY ESTABLISHMENT REJECT message 927 to 902. Upon receiving 927, 902 may check its coverage status yet another time, and if always out-of-coverage, 902 sends a DIRECT LINK SECURITY ESTABLISHMENT REJECT message 927’ to 903 and a DIRECT LINK ESTABLISHMENT REJECT message 927’’ to 900 through 901. Alternatively, as 902 sends 926’ to 901, it may simultaneously send a DIRECT LINK SECURITY ESTABLISHMENT REJECT message to 903 with a backoff timer, so as to allow some time (e.g., to move within coverage) before 903 re-attempts the PC5 link establishment again. Assuming that prior to receiving 926’, 901 has moved in-coverage, upon receiving 926’, 901 may trigger the Key Request / Response procedure in step 928 similarly to step 912. Then, in step 929, security establishment may be performed between 901 and 903. It is worth noting that during security establishment (929), the backoff timer which 903 may have received in the DIRECT LINK SECURITY ESTABLISHMENT REJECT message from 902 may still be running, in which case, 903 may ignore the backoff timer, and upon verifying that 901 is one of the relays ensuring the PC5 link between 900 and 903 (e.g., through its User Info ID), security establishment 929 is performed, and in message 930, 903 sends a Direct Communication Accept message to 901. As the DCA message goes through 902, this latter may infer that the secure PC5 link was successfully established between 901 and 903 from the DCA message header (e.g., ProSe PC5 signalling message type), and since 900 awaits the outcome of the PC5 link establishment in the second / third hop, 902 may send a DCA message 931 to 900. At this stage (i.e., after message 931), 900 and 902 have a secure PC5 link established through 901 which forwards traffic transparently, and 901 and 903 have a secure PC5 link established through 902 which forwards traffic transparently. However, messages from an end UE (e.g., 900 and / or 903) received by relays (e.g., 902 and / or 901) cannot be transferred to the other end UE (e.g., 903 / 901) as the security materials for each link are different. Hence, 902 (or 901) may trigger a Link Modification procedure for UE-to-UE relay UE reselection so as to set a primary relay UE (e.g., 901 if 902 triggers Link Modification procedure, and vice versa) and enable traffic to flow between the end UEs 900 and 903. Alternatively, 901 and 902 may establish a secure PC5 link between each other e.g., following successful security establishment in step 929. In another embodiment, the network (e.g., NF within the CN e.g., PKMF) upon receiving the Key Request in step 928, may detect the potential conflict that could arise due to the separate PC5 secure links being established between 900 and 902 and between 901 and 903, as such, the network may preemptively provide 901 with the security materials ensuring the security of the PC5 communication link between 902 and 900, thereby enabling 901 (or 902, depending on which relay UE trigger the Key Request / Response procedure last) to act as the primary relay UE, whereas the other relay UE may be configured to play the role of a secondary / back-up relay UE and may also be provisioned with the security materials ensuring the security of the PC5 communication link between the primary relay UE (e.g., 901) and the end UE it established a secure PC5 link with last (e.g., 903 in this case). Section: Emergency communication over multi-hop / UE-to-UE networks In an embodiment, a discovery message such as a multi-hop UE-to-UE relay discovery message or a UE-to-Network discovery message may include an emergency multi-hop RSC that may indicate the need to establish a multi-hop path allowing for emergency communication between two or more UEs or between a UE and network over multiple hops. Note that the emergency multi-hop RSC may be an RSC with the emergency label so that the path can always be established to enable an emergency communication and multi-hop may be indicated by means of the RSC itself e.g., an indicator associated with the RSC or by means of a different parameter, e.g., included in the discovery message such as a maximum hop count indicating how many hops the discovery message can be forwarded. In multi-hop UE-to-UE relay discovery scenarios, the discovery message may include the User Info ID / UserInfo (application layer ID) of the destination / receiving end UE, the discovery message may also include the User Info ID / UserInfo (application layer ID) of the sending end UE. In a related embodiment, relays, e.g., UE-to-UE relays, may only be allowed to forward such emergency multi-hop discovery messages if allowed by the core network, e.g., given a fixed configuration or given a context dependent configuration or policy (e.g., when connection to the core network is lost, e.g., for a given period of time, or when the number of hops is less than X, e.g., X=2, or when a public-warning message of a given type has been received, etc). In an embodiment, a discovery message may include an emergency / public safety RSC that may indicate that the content message of the sender is to be distributed to multiple receivers, as in the case of discovery model A, over multiple N>=0 hops. If the content message is to be transmitted to one or more receivers belonging to the same group, e.g., ProSe Service, then the content message may be protected as part of the direct discovery set that is protected with the corresponding discovery keys associated to the ProSe service, e.g., a public safety Service Code. This content message may, thus, not be accessible to relay devices that have not been configured with said public safety Service Code. The discovery message may be forwarded by UE-to-UE or UE-to-Network relays that have been configured with the emergency / public safety RSC. For instance, the direct discovery set protected with the discovery keys associated to the ProSe service may be: [UTC-counter LSB parameter, MIC, UserInfo of Source End-UE, content message] In an embodiment, the content message included in the discovery message may refer to a voice message transmitted by the source UE. The content message may encode the voice message in an efficient manner, e.g., in text using a speech to text encoder. This may allow for very compact content message for the voice message. The receiving parties may use a text to speech decoder to listen to the communication. This embodiment combined with previous embodiments provides a means for one to many communication over discovery messages. In an embodiment that may be combined with other embodiments or used independently, the discovery message may including a digital signature included by the transmitting device, as well as the public key to verify it and / or certificate to verify it, whereby the certificate may be provided by a 3rdparty such as a public safety organization and the certificate may allow receiving parties to verify that the message is coming from a trusthworty device. In a related embodiment, a first discovery message including a content message and sent by a first UE may include an indication or be indicative so that other UEs receiving the first discovery message stop transmitting another discovery message with another content message for t seconds, where t depends on the length / duration of the decoded content message in the first discovery message. For instance, if a sender / source UE sends the first discovery message with content message “Hello, any first responders available?” and the text to speech decoder decodes it in a voice message of 2 seconds, then UEs receiving said first discovery message may / should not (be able to) transmit any discovery message with a (reply) content message in the subsequent t= 2 seconds. This is advantageous in order to implement a simple communication protocol to enable communication. Section: Privacy considerations in emergency communications over UE-to-Network relays According to clause 6.3.6.3.1 of TS 33.503 (v18.1.0), in emergency situations where a remote UE has no USIM, and if no discovery security materials are provisioned or locally configured, the discovery of Emergency services may be performed without security protection if the regulation allows. Following the discovery procedure, the UE sends a Direct Communication Request that contains a Permanent Equipment Identifier (PEI) and Emergency RSC to the UE-to-Network relay UE which may be unprotected if no discovery security materials are provisioned or locally configured at the remote UE. Furthermore, if UP / CP based security procedure fails or is skipped and the PEI was not received in the DCR message, the UE-to-Network relay UE sends a Remote Identity Request message to the remote UE, which upon receiving said request, responds with a Remote Identity Response which includes its PEI. Whether the PEI is received in a DCR message or upon request (i.e., through Identity Request procedure), the PEI shall be stored by UE-to-Network relay UE upon receipt, which could potentially lead to a Denial of Service (DOS) attack, e.g., an attacker could capture an Emergency RSC that is sent unprotected, then replay it with random PEI values thereby causing the UE-to-Network relay UE to saturate its storage capacity. Furthermore, when a Remote Identity Request message is sent to a remote UE, this latter provides a response containing its PEI without performing any checks e.g., whether PEI was provided during DCR and / or whether the requested identity type (as per Table 10.3.34.1.1 of TS 24.554 (v18.3.0) and Table 9.11.3.3.1 of TS 24.501 (v18.5.0)) matches the identity type which the UE-to-Network relay UE is authorized to request and store. This represents a privacy threat since an attacker may misuse this situation to collect the PEI of a device (or many devices). Hence, it is the object of the following embodiments to address the aforementioned security issues. In an embodiment related to the storage of PEIs during Emergency communication over a UE-to-Network relay that may be combined with other embodiments or used independently, the UE- to-Network Relay may only store the PEI if the remote UE has provided a valid Emergency RSC, which matches the Emergency RSC used during the discovery phase and / or when the UE-to-Network Relay has engaged in a discovery phase using an Emergency RSC, and where the validity of the Emergency RSC is verified by the UE-to-Network Relay UE, or a NF (e.g., AMF) in the UE-to- Network Relay’s home network.. In an embodiment related to the storage of PEIs during Emergency communication over a UE-to-Network relay, which may be combined with other embodiments or used independently, the UE-to-Network relay may, upon receiving the PEI from the Remote UE (e.g., in the Direct Link Establishment Request, or upon request e.g., through Remote Identity Request procedure), sends a request to its AMF (e.g., in step 2 of Fig 6.3.6.3.1.1-1 of TS 33.503 (v18.1.0) or following step 4b of the same figure, if the PEI is provided upon request), including the remote UE’s PEI, to check the validity and status of PEI (i.e., corresponds to a known equipment and is permitted / whitelisted). The relay UE’s AMF may use the 5G-EIR Equipment Identity Check Service (as per TS 29.511) to perform the check and then forward the response back to the UE-to-Network relay UE or another NF involved in the Emergency services procedure. Upon receiving the response from AMF, the UE-to- Network relay UE checks the PEI’s validity and status and only if it is known and permitted / whitelisted, it may store the PEI and send a Direct Communication Accept message to the Remote UE. Otherwise, the UE-to-Network relay may send a DIRECT LINK ESTABLISHMENT REJECT message, including the failure / rejection cause e.g., Equipment unknown / blacklisted. Additionally or alternatively, if the rejection cause is due to the PEI not being identified / known (i.e., 5G-EIR returns a “404 Not Found” error response to AMF, as per clause 6.1.5 TS 29.511) by the 5G- EIR e.g., due to transmission error, the UE-to-Network relay UE may add a back-off timer for the Remote UE to allow it to re-attempt link establishment with its PEI, until it reaches a pre-configured limit of retries allowed. In another embodiment that may be combined with the previous embodiment or used independently, the UE-to-Network Relay may be configured with a threshold / limit of PEIs to be stored per Emergency RSC used. Additionally or alternatively, the UE-to-Network relay UE may be configured with a threshold / limit of PEIs to be stored during a time window. For instance, the UE-to- Network relay may be configured to only process X number of emergency requests (and store X number of PEIs) per time unit (e.g., per hour, 12h, 24h). In another embodiment that may be combined with previous embodiments or used independently, the UE-to-Network relay UE may be configured to blacklist (forever or for a given amount of time) an Emergency RSC if the latter is abused (i.e., used with several PEIs within a short time window) to saturate UE-to-Network relay UE storage capacity, whereby said configuration determines the number of requests, pertaining to different PEIs and using the same Emergency RSC, that are allowed during a determined time window. Note that this does not limit a Remote UE that requires emergency services from using its PEI with the same Emergency RSC from re-attempting PC5 link establishment in case of failures (e.g., due to congestion, network coverage, or any other failure causes). In another embodiment that may be combined with other embodiments or used independently, a UE-to-Network relay UE and / or remote UE may be configured to inform a network function in the core network about a potential DoS or privacy attack. In another embodiment that may be combined with previous embodiments or used independently, upon receiving a DCR message (or several DCR messages) with an Emergency RSC (which may be the same, or different Emergency RSCs) and a fresh PEI which has exceeded the configured threshold / limit of PEIs allowed per Emergency RSC over a time window, or the configured threshold / limit of PEIs allowed per time window (e.g., per hour, 12h, 24h) at the UE-to- Network relay UE, the latter may send a Reject message (i.e., DIRECT LINK ESTABLISHMENT REJECT message) indicating to the initiating UE (remote UE) that the Emergency RSC is blacklisted / expired / not valid and / or that the threshold of requests allowed has been reached. In another embodiment that may be combined with previous embodiments or used independently, in an Emergency communication scenario, the UE-to-Network relay may store the PEI together with the Emergency RSC it was sent with, thus enabling the UE-to-Network relay UE to track the PEIs used with the same Emergency RSC and detect potential DOS attacks. In another embodiment related to the Remote Identity Request procedure triggered during an emergency communication scenario between a remote UE and a UE-to-Network relay UE, and given that the UE identity type in the direct link identity request message (as per Table 10.3.34.1.1 of TS 24.554) may be set to any of the following 5GS identity types: SUCI, 5G-GUTI, IMEI, 5G-S-TMSI, IMEISV, MAC address, or EUI-64 (as per Table 9.11.3.3.1 of TS 24.501), the remote UE shall, upon receiving the Remote Identity Request (i.e., direct link identity request) message, check whether the requested UE identity type corresponds to the identity types IMEI or IMEISV, which UE-to-Network relay UE is authorized to request, and only provide an identity response containing the requested identity if the check is successful (i.e., request identity type matches IMEI or IMEISV). In another embodiment that may be combined with the previous embodiment or used independently, a remote UE, shall, upon receiving a Remote Identity Request message, check a number of conditions, e.g., whether it has initiated a direct communication procedure for emergency services, and / or whether it has already provided its PEI to the requesting UE (e.g., UE-to-Network relay UE) in the DCR message and / or the DCR message included an emergency RSC. Remote UE shall only provide its PEI in a Remote Identity Response if the aforementioned checks are successful. For instance, in a configuration the checks may involve checking if the Remote UE triggered a direct communication procedure for emergency services and it has not provided its PEI during DCR. For instance, in another situation it may involve checking if the Remote UE triggered a direct communication procedure by sending a DCR message with an emergency RSC and including its PEI. Otherwise, remote UE may send a DIRECT LINK ESTABLISHMENT REJECT message, which may include an indication of the failure cause e.g., PEI provided in DCR, or unauthorized identity type request. One embodiment of the method for resilient emergency connectivity services, which may be combined with other embodiments or used independently, is to involve a network function (e.g., SMF) in verifying the validity and status of the PEI provided by the second device and / or detecting potential DoS attacks. For instance, in the Emergency Service over 5G UE-to-Network relay procedure, as described in clause 6.3.6.3.1.1 of TS 33.503 (v18.3.0), the UE-to-Network relay sends the Remote UE Report to the SMF in step 6. In this case, the SMF may be the network function that checks whether multiple Remote UE Reports associated with the same PEI are received, or whether too many Remote UE Reports per time unit are received, or whether the PEI is blacklisted. The SMF may then inform (by means of a policy and / or configuration) the 5G UE-to-Network relay about the situation so that the UE-to-Network relay applies the corresponding policies / configurations. For example, the SMF may instruct the UE-to-Network relay by means of the policy / configuration to reject the request from the 5G Remote UE or to invalidate / blacklist an abused Emergency RSC, or to limit the number of requests allowed per time unit or per Emergency RSC. Alternatively, the SMF may perform these actions itself without involving the UE-to-Network relay. Furthermore, the N5g- eir_Equipment Identity Check service is provided by the 5G-EIR to check the Permanent Equipment Identifier (PEI) whether it is in the black list or not. The SMF checks with the AMF whether a PEI is blacklisted or not (since the AMF is the only entity consuming the service and / or the SMF may become a consumer itself of said N5g-eir_Equipment Identity Check service. In certain emergency situations, a Remote-UE requesting an emergency session may belong to a PLMN that is different from the UE-to-Network Relay’s PLMN, in which case, the 5G- Equipment Identity Register at the UE-to-Network Relay’s PLMN may not have / recognize the PEI of the Remote UE, and as such, the PEI status check cannot be performed. Hence, in another embodiment that may be combined with other embodiments or used independently, the UE-to- Network Relay may recognize whether the PEI check could be performed by its core network, e.g., a NF such as the AMF, or not, based on whether the PLMN ID (e.g., in the discovery message from the Remote UE), if included, matches the PLMN ID of the UE-to-Network’s HPLMN. In which case, the UE-to-Network relay may include the PLMN ID in the message sent to the network of the UE-to- Network relay (e.g., AMF) for the PEI check of the Remote UE, which UE-to-Network Relay’s AMF may forward to the network of the Remote UE (e.g., an AMF belonging to the Remote-UE’s HPLMN) to perform the PEI check. Additionally, or alternatively, if the Remote UE has no current PLMN ID, it may instead include the last known / used PLMN ID, which is then forwarded to UE-to- Network Relay’s network (e.g., AMF) triggering a similar check as the one described above. Additionally, or alternatively, if Remote UE does not include any PLMN ID, it may be left to the UE- to-Network Relay’s network operator to configure the UE-to-Network Relay with a network policy determining whether UE-to-Network Relay UE should allow or block direct communication requests with an Emergency RSC coming from Remote UEs belonging to a different PLMN or not belonging to any PLMN (e.g., USIMless device). Additionally, or alternatively, the UE-to-Network Relay UE may include the Emergency RSC in the request message to UE-to-Network Relay UE’s network (e.g., AMF), which may be used (e.g., by AMF or another NF (e.g., PKMF), upon AMF’s request) to identify the PLMN, or at least narrow down the potential PLMN(s), which may have provisioned the UE with the Emergency RSC used. Then, the UE-to-Network Relay’s AMF may send the PEI check request to said PLMN (or group of PLMNs) to perform the PEI status check. In another embodiment, that may be combined with other embodiments or used independently, a UE (e.g., ProSe capable UE) may be configured to store at least one PLMN ID (e.g., the most recent HPLMN used by the ME) in the ME or in a eUICC, pertaining to a network which has the UE’s PEI in store. This information (i.e., PLMN ID) may be used as described in the previous embodiment to assist the Serving PLMN (SPLMN) (or UE-to-Network Relay’s HPLMN) to recognize at least one PLMN containing the UE’s PEI and can perform the PEI check where needed (e.g., during emergency situations). It is to be noted that the PEI check across PLMNs (i.e., SPLMN and UE’s past HPLMN or a PLMN which has served and stored the UE’s PEI in the past) applies not only in Emergency situations using ProSe services (i.e., through a UE-to-Network Relay), but also in Emergency situations where UE connects directly to a SPLMN that is different from its past HPLMN (or a PLMN which has served and stored its PEI in the past. In another embodiment that may be combined with previous embodiments or used independently, a second device (e.g., initiating UE or remote UE) authorized for emergency connectivity services may include in its request message (e.g., Direct Link Establishment Request message) an indication of a PLMN that can verify the validity and status of its identifier (e.g., permanent equipment identifier (PEI)). This may help the first device (e.g., receiving device or UE-to-Network relay UE) or a network function (e.g., AMF) to perform a PEI check across different PLMNs and determine whether the second device is whitelisted (and not blacklisted) and thus trustworthy. The second device may also include other parameters that may assist in its identification, such as a SUCI, a 5G-GUTI, a 5G-S-TMSI, a MAC address, or a EUI-64. The first device or the network function may use these parameters to query a database (e.g., a 5G- EIR) or contact a corresponding PLMN to obtain the status of the second device's PEI. If the PEI check is successful, the first device may store the PEI and allow the emergency communication. Otherwise, the first device may reject the request and / or blacklist the second device or the Emergency RSC used. It is to be noted that this may be indicated by the PLMN ID associated to the emergency RSC. If a Remote UE uses a given Emergency RSC for a given PLMN ID, the check for a whitelisted UE may be in the scope / domain of said PLMN, and the UE-to-Network relay (or the network of the UE-to-Network relay)may direct the request (to verify the fact that the UE is whitelisted) to said PLMN. Note that this may also require a Service Level Agreement (SLA) between PLMNs. In general, it is described a method for resilient emergency connectivity services by which a first device (e.g., receiving UE or UE-to-Network relay) authorized to provide emergency connectivity services to a second device (e.g., initiating UE) determines whether to store an identifier (e.g., the permanent equipment identifier (PEI)) provided by a second device based on whether the emergency request meets (pre-)configured conditions which may include one or more of the following:·The identifier (e.g., PEI), if provided in a first (e.g., direct link establishment request) message, this latter shall include a valid Emergency RSC; · The identifier (e.g., PEI) is provided to a network function (e.g., a mobility function such as AMF) to be checked using an identity check service (e.g., 5G-EIR Equipment Identity Check Service), and the PEI is valid and permitted; · A threshold / limit (X) for the number of requests per T timer unit, where X and T are configured parameters, is not reached; · A threshold / limit (X) for the number of requests associated with the same Emergency RSC, where X is a configured parameter, is not reached; or · A combination of the third and fourth alternative conditions, i.e., a threshold / limit (X) for the number of requests associated with the same Emergency RSC per T time unit, is not reached; and where, upon failing to meet any of or one or more of the aforementioned (pre-)configured conditions, the first device may discard / ignore the request and / or send a reject message (e.g., DIRECT LINK ESTABLISHMENT REJECT message) to the second device, and / or invalidate / blacklist an abused Emergency RSC, whereas upon successfully meeting all the conditions, the first device may store the PEI, and optionally, together with the Emergency RSC used. It is also described a method for privacy-aware emergency connectivity services by which a second device (e.g., initiating UE or remote UE) authorized for emergency connectivity services may provide its identifier (e.g., permanent equipment identifier (PEI)) to a first device (e.g., receiving device or UE-to-Network relay UE) upon receiving a request message (e.g., Remote Identity Request procedure) based on whether the request meets (pre-)configured conditions which may include the one or more of the following conditions: · The initiating UE has requested Emergency service, e.g., in a previous message (e.g., Direct Link Establishment Request message); and / or · The initiating UE has not provided its identity (e.g., PEI) in a previous message (e.g., the Direct Link Establishment Request message); and / or · The 5GS identity type in the request message (e.g., Direct Link Identity Request message) is set to IMEI or IMEISV, and where, upon failing to meet one or more of the aforementioned (pre-)configured conditions, the second device may discard / ignore the request message and / or send a reject message (e.g., Direct Link Establishment Reject message), which may include an indication of the failure cause and / or send a report / alarm message to the core network indicating the unsuccessful Remote Identity Request attempt. The above embodiments may also be applicable to wireless using relay devices, e.g., multihop UE-to-Network deployments or UE-to-UE multi-hop networks. 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 indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil 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. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.

Claims

CLAIMS 1. An apparatus for communicating in a network with a least a first device, wherein the apparatus is configured to: - receive a message from the first device including at least one first message and an indication of a timing value t1, - extract the first message and the indication of the timing value t1, - obtain a validity time being based on a time reconciliation process and on the indication of the timing value t1, and - perform one of: i. storing the first message with the validity time or ii. checking the freshness of the message based on the validity time.

2. The apparatus of claim 1, wherein the validity time is determined by applying the time reconciliation process on the indication of the timing value t1 encoded by the first device to recover the timing value ••and based on at least a timing value ••of the apparatus and the parameters used to encode the indication of the timing value t1.

3. The apparatus of claim 2, wherein the indication of the timing value t1includes the b least significant bits of the timing value t1, < •• >•, included in the message, wherein <>•, is the remainder of dividing t1 by B, where B is a parameter.

4. The apparatus of claim 3, wherein according to the reconciliation process, the apparatus is configured to computesynchronization error betweenand ••.

5. The apparatus of claim 3, wherein according to the reconciliation process, the apparatus is configured to compute ••= ••• • • • + < < ••>•• •< ••• ••• >••>•• where s is a synchronization error between ••and ••and • is the maximum storage time of the apparatus.

6. The apparatus of claim 4 or 5, wherein the apparatus is configured to recover one or more reconciled timing values ••and verify their validity by using the reconciled timing value with a cryptographic function.

7. The apparatus of claim 6, wherein the cryptographic function is a key derivation function and the validity verification consists in checking that the computed MIC equals a received MIC in the received message.

8. The apparatus of any of claims 4-7, wherein s = 2*MAX_OFFSET, wherein MAX_OFFSET is a security parameter stored on the apparatus.

9. The apparatus of any of claims 4- 8, wherein a maximum validity time is determined as the recovered ••plus 2•– 2• or the recovered ••itself.

10. The apparatus of any of claims 4- 8, wherein a maximum storage time is 2•– 2• or the recovered t1 minus a current local time t2 of the apparatus.

11. The apparatus of any of claims 3 to 9, wherein B equals 2•, where b is a number of bits.

12. The apparatus of any previous claims, wherein the first timing value indicates the validity time of the first message and determines how long it can be stored by the apparatus.

13. A UE-to-UE Relay comprising the apparatus of any of claims 1-12.

14. A method for operating a communication apparatus, said apparatus being configured for communicating in a network with a least a a first device, the method comprising the apparatus performing the steps of: - receiving a message from the first device including at least one first message and an indication of a timing value t1, - extracting the first message and the indication of the timing value t1, - storing the first message with a validity time, said validity time being based on a time reconciliation process and on the indication of the timing value t1.

15. An apparatus for communicating in a network, the apparatus being configured to receive a timing value indication, derive a timing value from the received timing value indication on the basis of a time reconciliation process, obtain a synchronized timer based on the derived timing value, and apply the synchronized timer to the apparatus or transmit a synchronized timer value.

16. A method of an apparatus for communicating in a network, the method comprising the apparatus performing the steps of receiving a timing value indication, deriving a timing value from the received timing value indication on the basis of a time reconciliation process, obtaining a synchronized timer based on the derived timing value, and applying the synchronized timer to the apparatus or transmitting a synchronized timer value.

17. A method for managing privacy-aware emergency connectivity services, comprising a second device receiving a request message from a first device, the second device being authorized for emergency connectivity services, the second device providing its identifier to the first device based on one or more of the following conditions : the second device requested emergency connectivity services in a previous message; and / or the second device did not provide its identifier in a previous message; and / or the 5GS identity type in the request message is set to IMEI or IMEISV.

18. The method of claim 17, wherein upon failing to fulfil one or more of the conditions, the second device discards the request message.

19. The method of claim 17-18, wherein upon failing to fulfil one or more of the conditions, the second device sends a report / alarm message to the core network indicating the unsuccessful request message attempt.

20. The method of claim 17-19, wherein upon failing to fulfil one or more of the conditions, the second device sends a reject message.

21. The method of claim 20, wherein the reject message includes an indication of the failure cause 22. A method for resilient emergency connectivity services, comprising receiving, by a first device, a first message from a second device comprising an identifier and an emergency relay service code;a first device determining whether to (1) store an identifier provided by the second device and / or (2) provide emergency connectivity services to the second device, the first device being authorized to provide emergency connectivity services to the second device, wherein the determining comprises the first device checking whether the identifier is valid by: - validating it against a local database and / or - sending a second message to a network function for validation andreceiving a third message from the network function with the identifier validation .

23. The method of claim 22, comprising the first device storing the identifier together with its validation status and / or received emergency relay service code.

24. The method of claims 22 or 23 , comprising the first device storing a configuration indicative of the number X of first messages per T time units per emergency relay service that may be processed by the first device, where X and T are configured parameters in the configurationo 25. The method of any one of claims 22-24, comprising, upon unsucessful identifier validation, the first device performing one or more of the following actions: discard / ignore the request and / or send a reject message (e.g., DIRECT LINK ESTABLISHMENT REJECT message) to the second device, and / or invalidate / blacklist an abused Emergency RSC.

26. The method of any one of claims 17-25, wherein the second device identifier is a permanent device identifier.

27. The method of any one of claims 17 – 26, wherein the second device is a remote UE and the first device is a UE-to-Network relay.

28. A method for discovery ,wherein the direct discovery sets that carry the Application Layer IDs of a first device and a second device, are protected separately, wherein the method comprises receiving, by the first or the second device, a protected discovery message, wherein the first protected direct discovery set is located before the second protected direct discovery set in the protected direct discovery set information element included in the protected discovery message.

29. The method of claim 28, wherein the protected discovery message is a discovery sollicitation message, and the method further comprises: - processing, by the second device, the protected discovery message using keying materials associated with the relay service code obtaining a first protected direct discovery set and a second protected direct discovery set, - processing a first protected direct discovery set obtaining a first direct discovery set, and - processing, by the second device, the second protected direct discovery set if the Application Layer ID contained in the first direct discovery set matches the Application Layer ID of the second device.

30. The method of claim 28, wherein the protected discovery message is a discovery response message, and the method further comprises: - processing, by the first device, the protected discovery message using keying materials associated with the relay service code obtaining a first protected direct discovery set and the second protected direct discovery set, - processing the second protected direct discovery set obtaining a second direct discovery set, and - processing, by the first device, the first protected direct discovery set if the Application Layer ID contained in the second direct discovery set matches the Application Layer ID of the first device.

31. The method of claim 28, wherein the discovery is a secure discovery in UE to UE discovery model B.

32. A method for device to device communication between a first device and a second device comprising: - receiving, by the second device, a direct link establishment request message transmitted by the first device containing a relay service code, wherein the relay service code is associated with a Network Assistance Security Indicator indicating a security procedure without network assistance is required, and - determining, by the second device, whether it is configured with valid long-term credentials, and- transmitting, by the second device, if the second device is not configured with valid long-term credentials, a first PC5 reject message with a failure cause indicating that security procedure without network assistance is unsupported.

33. The method of claim 32, wherein the first device and the second device are acting as Source End UE and UE-to-UE relay UE respectively, and a third device, acting as a Target end UE.

34. A Method for device to device communication between a first device and a third device, through a second device acting as a relay, comprising: - receiving, by the third device, a direct link establishment request message containing a relay service code associated with a Network Assistance Security Indicator indicating the security procedure without network assistance is required, - determining, by the third device whether it is configured with valid-long term credentials, and - transmitting, by the third device to the second device, if no valid long-term credentials are available, a second PC5 reject message indicating that the security procedure without network assistance is unsupported.

35. The methods of claim 32 or 34, wherein the unsupported UE failure cause in the first and / or second PC5 reject indicates that the triggering of security procedure without network assistance is not possible.

36. A method for UE-to-UE communication, wherein, while a first, second, and third device acting as, Source End UE, UE-to-UE relay UE, and Target End UE, respectively, are establishing a UE-to-UE communication link using a relay service code associated with a Network Assistance Security Indicator indicating the security procedure with network assistance is required, if the second device is not served by NG-RAN, the second device shall send PC5 reject messages to the first and third devices, indicating that security procedure with network assistance is not possible.

37. Method of claims 31-34, wherein if a failure cause indicates that a security procedure is unsupported, the security procedure is not possible due to: - the second device moving out of NG-RAN coverage, where the security procedure requires network assistance, or - the second or third device not having valid long-term credentials, where the security procedure does not require network assistance.

38. A method for multi-hop connectivity services comprising: - receiving, by a second device, one or more first discovery messages, each first discovery message comprising a relay service code and / or a set of User Info IDs and / or a number of hops, wherein the relay service code indicates the maximum number of hops authorized when providing multi-hop connectivity services, the set of User Info IDs identifies the relaying devices in the multi-hop route, and the number of hops indicates the number of hops in the multi-hop route, and - selecting, by the second device, a preferred multi-hop route from the one or more received discovery messages based on one or more of the maximum number of hops indicated by the relay service code and / or the set of User Info IDs and / or the number of hops contained in the one or more received discovery messages.

39. The method of claim 38, comprising the second device that is authorized to provide multi- hop services providing network access to a first device; and transmitting, by the second device, a second discovery message comprising the relay service code and / or the set of User Info IDs in the selected preferred multi-hop route.

40. The method of claim 36, comprising the second device dropping a received first discovery message if the included number of hops reaches the maximum number of hops.

41. The method of any one of claims 38-40, comprising sending, by the second device, a third message to a core network function, wherein the third message includes (1) security information required to establish a secure connection between the hops in the multi-hop route and / or (2) a route verification request.

42. The method of claim 41, comprising receiving, by the second device, a fourth message from the core network function, wherein the fourth message includes (1) security information required to complete the establishment of the secure connection between the hops in the multi-hop route and / or (2) a route verification confirmation.

43. The method of any of claims 41-42, comprising the second device receiving a fifth message from the first device, wherein the fifth message includes one or more of(1) security information required to establish a secure connection between the hops in the multi-hop route and / or (2) a route identifier and / or (3) a route verification request.

44. The method of any of claims 41 to 43, comprising sending a sixth message to the first device, wherein the sixth message includes one or more of (1) security information required to complete the secure connection between the hops in the multi-hop route and / or (2) a route verification confirmation.

45. The method of claims 43 and / or 44, wherein the fifth and / or sixth messages are relayed transparently by the devices in the multi-hop route whose security hop-by-hop links have already been established.

46. The method of claims 43 and / or 44, wherein the fifth and / or sixth messages are relayed transparently by the devices in the multi-hop route whose security hop-by-hop links are not required to be established.

47. The method of any of claims 38-46, wherein the relay service code is a multi-hop emergency relay service code and the discovery message includes an emergency message.

48. An apparatus adapted for communicating in a network, the apparatus comprising at least one antenna coupled to a receiver, configured for receiving a timing value indication, a controller configured for deriving a timing value from the received timing value indication on the basis of a time reconciliation process, the controller being adapted to obtain a synchronized timer based on the derived timing value, and to apply the synchronized timer to the apparatus and / or to transmit a synchronized timer value.

49. An apparatus configured for managing privacy-aware emergency connectivity services, comprising a receiver configured for receiving a request message from a first device, the apparatus being authorized for emergency connectivity services,a controller adapted to cause a transmitter to provide the apparatus identifier to the first device based on one or more of the following conditions : the apparatus requested emergency connectivity services in a previous message; and / or the appartus did not provide its identifier in a previous message; and / or the 5GS identity type in the request message is set to IMEI or IMEISV.

50. An apparatus, comprising a receiver for receiving a first message from a second device comprising an identifier and an emergency relay service code; a controller adapted for determining whether to (1) store an identifier provided by the second device and / or (2) provide emergency connectivity services to the second device, the first device being authorized to provide emergency connectivity services to the second device, wherein the determining comprises the controller checking whether the identifier is valid by: - validating it against a local database and / or - sending a second message to a network function for validation andreceiving a third message from the network function with the identifier validation.

51. An apparatus configured for discovery ,wherein the direct discovery set that carry the Application Layer IDs of a first device and a second device, are protected separately, wherein the apparatus comprises a transmitter adapted for transmitting a protected discovery message, wherein the first protected direct discovery set is located before the second protected direct discovery set in the protected direct discovery set information element included in the protected discovery message.

52. An apparatus adapted for device to device communication between a first device and the apparatus comprising: a receiver configured for receiving a direct link establishment request message transmitted by the first device containing a relay service code, wherein the relay service code is associated with a Network Assistance Security Indicator indicating a security procedure without network assistance is required, and a controller that determines whether the apparatus is configured with valid long- term credentials, wherein the controller is configured to cause a transmitter to transmit a first PC5 reject message with a failure cause indicating that security procedure without network assistance is unsupported if the apparatus is not configured with valid long-term credentials.

53. An apparatus for device to device communication between a first device and the apparatus, through a second device acting as a relay, comprising: a receiver adapted to receivea direct link establishment request message containing a relay service code associated with a Network Assistance Security Indicator indicating the security procedure without network assistance is required, a controller adapted to determine whether it is configured with valid-long term credentials, wherein the controller is adapted to cause a transmitter for transmitting to the second device a second PC5 reject message indicating that the security procedure without network assistance is unsupported, if no valid long-term credentials are available.

54. An apparatus adapted for multi-hop connectivity services, comprising: a receiver configured for receiving one or more first discovery messages, each first discovery message comprising a relay service code and / or a set of User Info IDs and / or a number of hops, wherein the relay service code indicates the maximum number of hops authorized when providing multi-hop connectivity services, the set of User Info IDs identifies the relaying devices in the multi-hop route, and the number of hops indicates the number of hops in the multi-hop route, and a controller configured for selecting a preferred multi-hop route from the one or more received discovery messages based on one or more of the maximum number of hops indicated by the relay service code and / or the set of User Info IDs and / or the number of hops contained in the one or more received discovery messages.

Images