Privacy in relay selection in cellular slice networks

Abstract

The cellular communication system supports a network relay function (140) for managing indirect connections. A mobile device (110) can send a request message to a relay device (120), the request message including a relay service code (associated with a set of privacy-sensitive PDU session parameters). The relay device receives the request message and sends a transmission request message to the cellular communication system, indicating a request to transmit data via the indirect connection and including the requested relay service code. The network relay function receives the transmission request message, determines a different relay service code to use instead of the requested relay service code; and sends a transmission response message including the different relay service code in an encrypted manner that allows it to be decrypted by the mobile device rather than the relay device; and the relay device forwards the encrypted different relay service code to the mobile device in response to the request message.

Description

Technical Field

[0001] This invention relates to the well-known field of cellular wireless communication systems (CCS), such as LTE, 4G, or 5G networks. A cellular wireless communication system includes a core network (CN) and a radio access network (RAN) comprising multiple cellular base stations (BSs). The cellular communication system can provide cellular networks supporting network slicing and indirect connections, while mobile devices can connect to the core network via base stations. Access to the network is managed by a so-called provider or mobile network operator (MNO). Network slicing provides a logical network using the shared physical infrastructure of the cellular communication system. Indirect connections provide data transmission between the mobile device and the cellular communication system via at least one relay device. Background Technology

[0002] Mobile devices that communicate using cellular wireless communication standards (such as those according to the 3GPP 5G specification) are being continuously developed. Wireless devices can be different types of devices, such as mobile phones, vehicle-to-vehicle (V2V) communication, or more generally vehicle-to-anything (V2X) communication, Internet of Things (IoT) devices, medical (emergency) diagnostic and treatment devices, virtual reality (VR) headsets, etc. Because mobile devices such as those mentioned above vary greatly in characteristics (e.g., in terms of low-power operation, maximum tolerable latency, required bandwidth, and mobility), the concept of network slicing is defined in 5G system and radio access network specifications (see [23.501], [38.300], [Elayoubi]).

[0003] Network slicing can be viewed as an isolated “virtual 5G network” that runs on a shared hardware / software platform. Platform components can be shared across multiple slices, but each slice still operates independently. Each slice can provide performance, service levels, policies, and characteristics optimally tailored for a specific use case or application domain. Slices can also be operated as a service by different network operators (rather than by the network operator owning the hardware / software platform). Slicing can be accomplished in the core network (CN), the radio access network (RAN), or both.

[0004] A mobile device (often referred to as User Equipment (UE)) can be part of multiple slices simultaneously. A UE can establish multiple Protocol Data Unit (PDU) sessions with the CN, each running within a specific slice. Further explanation of network slicing can be found in [PavelShulgin]. The UE also covers the case where the UE is a fixed device. User Equipment can be any device directly used by the end user. This includes both non-fixed and fixed devices. Another characteristic of a UE is that it typically communicates with the base station using the 3GPP Uu interface, and it usually has its own mobile subscription, its own SIM card, and can be identified via IMSI.

[0005] An example of a session requesting to run in a slice is discussed in [EventHelix]. Figure 1 shows an excerpt from a diagram illustrating a requested slice by a User Equipment (UE). The UE sends the requested Network Slice Selection Assistance Information (NSSAI) in the 21:RRCSetupComplete message and the base station (gNB), and forwards this information in its 24:NGAP Initial UE message. The term 5GC is used to refer to the 5G core network.

[0006] The 3GPP specifications for 4G define the Proximity Service (ProSe) function (see [23.303] and [24.334]) to enable cellular user equipment (UEs) temporarily outside the coverage area of ​​a cellular network base station (eNB) to establish a connection. This specific function is called ProSe UE-to-Network Relay, or simply Relay UE. A Relay UE is a UE that facilitates communication between an OoC UE and an eNB by relaying application and network traffic in both directions between the OoC UE and the eNB. Local communication between the Relay UE and the OoC UE is called Device-to-Device (D2D) communication or sidechain (also known as PC5) communication (see [23.303] and [24.334]). Once the relay relationship is established, the OoC UE returns to the coverage area via the Relay UE and functions as a “remote UE.” This means that the remote UE has an indirect connection to the 4G core network, rather than a direct network connection, which is normal.

[0007] In this document, the terms “eNB” (4G term) and “gNB” (5G term) refer to cellular base stations. eNB / gNB is part of the Radio Access Network (RAN), which interfaces with functions in the Core Network (CN). “OoC” means outside coverage. “Indirect connection” is the same as “indirect network connection” as defined in [22.261]. Slice-specific 5G terms NSSAI, S-NSSAI, NSSF, etc., have the meanings defined in [23.501]. “D2D” is device-to-device communication, and “PC5” is an interface for sidechain communication, as defined by ProSe [23.303], eProSe [36.746], or V2X [23.287].

[0008] Various traditional solutions involving relays are known in the art and are related to 3GPP work (each of the following figures is a separate topic):

[0009] US20180092017A1, US9826460, US10212651B2, and US20160212721A1 describe the selection of a relay from multiple candidate relays based on signal strength or ad group ID;

[0010] US10177834B2 describes the bandwidth requirements for eNB broadcast relays to its unit, and devices with relay capabilities automatically use this method to determine whether to become a relay if they meet the requirements.

[0011] US20160227518A1 describes how an eNB determines that a UE is an Out-of-Call (OoC) and how it needs to send some information (via a relay) to the UE to help it reconnect.

[0012] US20160227518A1 describes a UE with relay capability that becomes a relay only when it has sufficient connectivity or battery power or appropriate service type / background.

[0013] US9445352B2 describes an OoC UE that requires relaying, so it sends a D2D message to its neighbor to request a device to become a relay, at which point one or more UEs become relays;

[0014] WO2018083381A1 describes an OoC UE that queries a peer UE for certain configuration information via a sidechain / D2D, and this configuration information needs to be relayed back to the network;

[0015] US20180035448A1 describes an eNB that sends sidechain scheduling authorization information with a specific schedule for an OoC UE; this information is received by UEs within the coverage area and retransmitted by these UEs to the OoC UE;

[0016] US9565573B2 describes a UE within coverage area sending a D2D signal, to which an OoC UE can respond with an indication that it requires coverage. The UE within coverage area then forwards the received indication to the network. Optionally, the network can use the indication to instruct the UE within coverage area to become a relay.

[0017] It is possible to define a mechanism for selecting the most suitable relay UE for a specific network slice that the serving remote UE wishes to use (via relay UE) to connect to the cellular core network.

[0018] This invention relates to privacy aspects of relay discovery and selection of relay UEs in cellular slice networks, particularly for UEs outside coverage areas. For relay UE discovery, the ProSe framework utilizes so-called relay service codes (see [23.303] and [24.334]). Relay service codes can be used by a remote UE during relay UE discovery. For example, using a so-called "Model A" discovery mechanism, a relay UE can broadcast information about a set of relay service codes that it supports. Each relay service code can correspond to a set of PDU session attributes, and a remote UE can use the discovered relay UEs and their broadcast relay service codes to find one or more relay UEs that match the set of PDU session parameters known to the remote UE, and thus use this to select, from among a possible number of relay UEs, the most suitable relay UE for use as the relay of one or more PDU sessions(s) that the remote UE wishes to set up. Similarly, using the so-called "Model B" discovery mechanism, a remote UE can request a set of relay service codes as part of its discovery request. If the relay UE supports one or more of the requested relay service codes, it will use them to match and respond to them. Importantly, it should be noted that the open discovery and connection request messages on PC5 are not encrypted, and therefore any other nearby devices can monitor and listen to these messages.

[0019] In cases where UE-based relaying is performed at Layer 3 (i.e., the IP layer), the relay UE needs to receive information at a specific point in time, before the indirect connection between the remote UE and the cellular network via the relay UE can begin, regarding how to set up a PDU session on behalf of the remote UE. This raises privacy concerns because PDU session information includes details such as the specific network slice or data network name (DNN) the remote UE wants to connect to. This could reveal that the remote UE is, for example, from law enforcement personnel connected to a DNN reserved for a police department or a slice dedicated to police communications. Relay UEs are typically authorized by the network to act as relay devices and may have to undergo some vetting process. However, this does not mean that it is permissible to simply keep track of all this privacy-sensitive information even after the remote UE has disconnected, or that the relay UE is allowed to track the remote UE by tracking its relay service code, which can be used for subsequent discovery and / or connection to another relay UE, nor is it permissible for the relay UE to use the same relay service code to track other nearby remote UEs. As a possible mitigation, the relay service code can be given a very short lifespan, for example, changing every few minutes. However, updating all potential remote and relay UEs with this new relay service code would result in a significant amount of traffic. For this information to be updated, each of these UEs would have to be awake and within the coverage area of ​​a gNB operated by the core network. Given that many UEs might be asleep or out of coverage, this could be quite difficult to implement. In particular, remote UEs are typically outside coverage; otherwise, they wouldn't need a relay to reach the network. Therefore, such a mechanism would be highly inefficient. Summary of the Invention

[0020] This requires ProSe relay technology or similar technologies for UE-based relay to next-generation cellular communication networks (e.g., 5G). However, if UE-based relay needs to be considered, the use of network slicing, as introduced by 5G, introduces new requirements and challenges, such as the following situations.

[0021] • The UE needs to be able to connect to one or more of its required and / or preferred 5G network slice instances via relay UEs, so the UE needs to know which nearby relay UEs will be able to or will not be able to do this;

[0022] There may be multiple candidate relay UEs within the UE's radio range. Relay UEs may move around and go out of range, and new relay UEs may appear within range.

[0023] • The network slice instance requested and / or preferred by the UE may be different from the slice(s) to which the best relay UE candidate is currently connected;

[0024] • When a choice needs to be made, the UE may be OoC;

[0025] • Relay UEs may be resource-constrained devices and therefore may not be able to provide QoS as expected / required for a particular network slice;

[0026] • A relay UE may have its own one or more PDU connections (i.e., since it is usually a UE owned by someone else who wants to access, for example, the Internet) and may have very limited resources to support indirect network communication to another UE;

[0027] • The frequency band used by the network slice requested or preferred by the UE may be different from the frequency band currently used by the relay UE candidate;

[0028] • A UE may participate in two or more network slices, each of which has its own unique requirements in terms of forming the optimal relay and corresponding network path for indirect connections. Therefore, it may be necessary to select two (or even more) relay UEs as the optimal solution for performing relay.

[0029] • Candidate relay UEs are often unknown and untrusted to the UE beforehand – posing a mutual security risk, as the lack of initial trust between the parties and the use of insecure procedures to connect to the relay UE also pose a security risk. For example, there may be a UE that has never been encountered before to initiate a relay / remote relationship. This can often happen if, for example, 1) a mobile cellular IoT device is moved around or 2) a mobile or fixed cellular IoT device is deployed and activated for the first time in a new environment.

[0030] • The candidate relay UE may not be authorized and may not have the necessary credentials to connect to and / or send / receive data from and / or participate in relay connections toward the network slice, especially private network slices that are only permitted for use by UEs belonging to a predefined group.

[0031] An additional concern is the potential privacy risks. For example, the candidate relay UE (and other remote UEs) may gain access to or require information about network slices, as well as, for example, the DNN to which the remote UE (intends) to connect. DNN identifiers (e.g., similar to URIs that may contain names such as companies, organizations, or specific facilities) or slice identifiers can reveal privacy-sensitive information or may link to specific companies / organizations or other entities, as this information is often very static. This raises privacy concerns and can, for example, allow the relay UE to determine the types of information the remote UE is interested in, to which DNN it will send its data, and from which DNN it will receive its data. It also allows the relay UE to potentially track the remote UE even after it has disconnected or has not connected to the relay UE at all. Specifically, in the case of Layer 3 relay (i.e., relaying at the IP layer rather than the MAC layer), the relay UE needs to set up a PDU session on behalf of the remote UE and therefore needs to be provided with information about that PDU session at some point in time.

[0032] Generally speaking, the exposure of information related to slices and DNNs that a UE uses or intends to use for its relay operations (i.e., for the purpose of relay selection and / or establishing relay connections to the network) is privacy-sensitive because it may reveal that the UE belongs to a special subscription group, such as police / law enforcement / customs, or is linked to, for example, a healthcare facility.

[0033] One potential problem is that remote UEs and relay UEs can be provided, for example, by providing one or more S-NSSAI values ​​or (one or more) DNN values ​​associated with a specific relay service code, which is a set of PDU session parameters associated with each relay service code it supports. Relay service codes are used during relay UE discovery. Given that remote UEs should be able to operate outside coverage, relay service codes are expected to be fairly static and have a fairly long lifespan (i.e., possibly in hours rather than seconds). Pre-configuring a large number of relay UE devices or remote UE devices with persistent and / or relatively static information that can be associated with slice and / or DNN information such as relay service codes could enable these devices to perform various privacy attacks, including tracking and tracing the identity of remote UEs by linking their identifiers to relatively static or persistent information. This is especially problematic because remote UEs and relay UEs are end-user equipment and cannot be fully trusted (unlike, for example, core network functions or base stations).

[0034] Some of these considerations also apply to accessing non-public networks (NPNs), see [23.501]. This concept shares some similarities with network slicing, which has already been introduced in 5G. An NPN is a private network for a limited set of users and can operate as a standalone mobile core network or at the top of a mobile network operator's Public Land Mobile Network (PLMN), where the NPN is typically deployed as a slice and / or closed access group within the PLMN. In addition to the fact that NPNs are implemented at the top of existing hardware / software infrastructure using network slicing, an NPN can also have one or more slices of its own, particularly when the NPN is operated as a separate, independent network. Relaying traffic targeting certain NPNs is also limited to remote UEs and relay UEs authorized to access the NPN, similar to slicing. Furthermore, NPNs may have requirements regarding minimum QoS and service area restrictions, as well as other aspects similar to network slicing, and other dynamic aspects need to be considered to assess whether a relay UE is suitable for use as a relay for data connections between remote UEs and the NPN. Throughout this document, the term network slicing is also used to refer to non-public networks.

[0035] The purpose of this invention is to provide an effective mechanism in cellular communication systems to avoid the use of privacy-sensitive PDU session information and relatively static relay service codes by relay UEs (and other remote UEs) to track remote UEs.

[0036] For this purpose, devices and methods as defined in the claims are provided. According to one aspect of the invention, cellular communication systems, mobile devices, network relay entities, and relay devices as defined in the appended claims are provided. According to another aspect of the invention, a computer program product downloadable from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium is provided, the product comprising program code instructions for implementing the methods described above when executed by a computer.

[0037] A cellular communication system (CCS) includes a core network (CN) and a radio access network (RAN) comprising multiple cellular base stations (BSs). The cellular communication system provides cellular networks supporting network slicing and indirect connections. Each network slice provides a logical network using the shared physical infrastructure of the cellular communication system. Each indirect connection provides data transmission between a mobile device and the cellular communication system via at least one relay device, which is a mobile device configured to communicate with the radio access network and capable of supporting the indirect connection. The cellular communication system includes at least one network relay entity configured to provide network relay functionality (NRF) for managing the indirect connections.

[0038] The mobile device may include a transceiver arranged for wireless communication in the cellular network, and a connection processor arranged for managing connections to the cellular network, the connection processor providing relay functionality for managing at least one indirect connection. The relay functionality may be arranged as follows:

[0039] - Send a request message to at least one relay device (UEx), the request message including a relay service code (RSC1), and also including an identifier of the at least one relay device (UEx), and also including an identifier of the mobile device;

[0040] - Receive a response message from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2), the encrypted relay service code (RSC2) being encrypted by the network relay function (NRF) in the cellular network using a key that allows it to be decrypted by the mobile device rather than the relay device;

[0041] - Decrypt the Encrypted Relay Service Code (RSC2) and insert the Decrypted Relay Service Code (RSC2') instead of RSC1 in the subsequent Discovery and Connection Setup message, thereby associating RSC2' with the same set of PDU session attributes as RSC1;

[0042] In one embodiment, the mobile device may include non-volatile storage units arranged to store a set of relay service codes supported by the mobile device, each of which may be associated with a set of PDU session attributes.

[0043] The relay device may include: a communication unit arranged for communication in the cellular network, and a relay processor arranged for managing the communication in the cellular network and for managing indirect connections between the mobile device and the cellular network. The relay processor may be arranged as follows:

[0044] -A collection of code for storing standby relay services;

[0045] - Receive the request message from the mobile device;

[0046] - Upon receiving a request message, a transmission request message is sent to the cellular communication system according to the request message, the transmission request message including the mobile device identifier and the relay service code RSC1 received from the mobile device in the request message;

[0047] - Receive a transmission response message from the cellular communication system, the transmission response message containing the Encrypted Relay Service Code (RSC2);

[0048] - Upon receiving the transmission response message, a response message (M) is sent to the mobile device based on the transmission response message, and the response message includes the encrypted relay service code (RSC2).

[0049] The relay device may include a non-volatile storage unit arranged to store a set of relay service codes supported by the mobile device, including a set of backup relay service codes.

[0050] The network relay function can be configured as follows:

[0051] - Receive at least one transmission request message from the relay device, the transmission request message including a relay service code (RSC1) and an identifier of the mobile device;

[0052] - Determine a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message, wherein the different relay service code (RSC2') is selected from one or more alternative relay service codes or new relay service codes available in the relay device.

[0053] - The different relay service code (RSC2') is encrypted using a key that allows it to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2).

[0054] - Send a transmission response message including the encrypted relay service code (RSC2) to the relay device.

[0055] Advantageously, eavesdroppers (including relay devices and other remote UEs) cannot use the relay service code RSC1 to track the mobile device after it disconnects, even though the discovery and connection setup message itself is unencrypted and unauthenticated, and the relay service code is sent in plaintext. It also does this efficiently because only the relay service code used by the remote UE (i.e., mobile device UE0) needs to be updated, not all relay service codes of all other remote UEs and / or relay UEs. Furthermore, it works even if the remote UE is outside the coverage area of ​​the network's base station.

[0056] Moreover, advantageously, the process can be combined with a process for verifying authorization granted by the network to the remote UE and the relay UE, a process for establishing a relay connection for the specific relay service code and / or for establishing the PDU session using PDU session parameters associated with the relay service code, and / or can be combined with a process for requesting the security key or privacy-sensitive PDU session parameters (e.g., slice identifier / NSAI, DNN) to set up such a relay connection from the network, and in this way achieves faster and more secure connection setup.

[0057] Furthermore, information regarding slices, DNNs, non-public networks, and other PDU session-related parameters may be considered privacy-sensitive. This could lead to unwanted tracking of mobile devices and expose operator deployment information (e.g., which slices and NPNs are supported by the core network). In 5G, to prevent privacy breaches of slice information, it may be sent to the UE only later in the CN attachment / authentication process, after some initial security context is in place, thus not being sent early in the process (or only encrypted or temporary slice information). Additionally, relay UEs may not have access to, have unauthorized access to, or be unable to support the features of the slices that remote UEs want to use (e.g., the required QoS or frequency band). Therefore, by using NRF to provide the PDU session parameters only to the relay UE selected by the remote UE (and possibly only after verifying whether the relay UE is authorized to set up the corresponding relay connection on behalf of the remote UE and / or to set up a PDU session to the network using the corresponding PDU session parameters), unnecessary information about PDU session parameters should not be stored beforehand in the relay UE or in other relay UEs that have not yet been selected, which are often untrusted end-user equipment.

[0058] A cellular communication system is provided, comprising a radio access network including multiple cellular base stations and a core network. The cellular communication system supports an indirect connection via the cellular network, each indirect connection providing data transmission between a mobile device and the cellular communication system via at least one relay device. The relay device is a mobile device configured to communicate with the radio access network and capable of supporting the indirect connection. The cellular communication system includes at least one network relay entity configured to provide network relay functionality (NRF) for managing the indirect connection. The mobile device includes:

[0059] - A connection processor, configured to manage connections to the cellular network, the connection processor providing relay functionality for managing at least one indirect connection.

[0060] The relay function is configured to at least:

[0061] - As part of the setup process, a request message is sent to at least one relay device (UEx), the request message including a relay service code (RSC1) and an encrypted identifier of the at least one relay device (UEx), and also including an encrypted identifier of the mobile device;

[0062] - Receive a response message from the at least one relay device (UEx), the response message including the encrypted relay service code (RSC2);

[0063] - Decrypt the Encrypted Relay Service Code (RSC2) and insert the Decrypted Relay Service Code (RSC2') instead of RSC1 in the subsequent Discovery and Connection Setup message, thereby associating RSC2' with the same set of PDU session attributes as RSC1;

[0064] The relay equipment includes:

[0065] - A communication unit, which is arranged for communication in the cellular network (130), and,

[0066] - A relay processor, configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network.

[0067] The relay processor is configured as follows:

[0068] - Receive the request message from the mobile device;

[0069] - Upon receiving a request message, a transmission request message is sent to the cellular communication system according to the request message, the transmission request message including at least one of the relay service code RSC1 and the encrypted identifier received from the mobile device in the request message;

[0070] - Receive a transmission response message from the cellular communication system, the transmission response message containing the Encrypted Relay Service Code (RSC2);

[0071] - Upon receiving the transmission response message, a response message is sent to the mobile device based on the transmission response message, and the response message includes the encrypted relay service code (RSC2);

[0072] The network relay function is configured as follows:

[0073] - Receive at least one transmission request message from the relay device, the transmission request message including at least one of the relay service code (RSC1) and the encrypted identifier of the mobile device and the encrypted identifier of the relay device;

[0074] - Determine a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message; - Encrypt the different relay service code (RSC2') using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device instead of the relay device, thereby obtaining an encrypted relay service code (RSC2).

[0075] - Send a transmission response message including the encrypted relay service code (RSC2) to the relay device.

[0076] According to one aspect, the network relay function is configured to use a key to encrypt the identifier of the mobile device and / or the identifier of the relay device, the key allowing them to be decrypted by the network relay function (NRF) in the cellular network rather than by the relay device.

[0077] Alternatively, a cellular communication system (CCS) is provided, including a core network (CN) and a radio access network (RAN) including a plurality of cellular base stations (BSs). The cellular communication system provides a cellular network supporting indirect connections, each indirect connection providing data transmission between a mobile device and the cellular communication system via at least one relay device, the relay device being a mobile device arranged to communicate with the radio access network and capable of supporting the indirect connections.

[0078] The cellular communication system includes at least one network relay entity (140) arranged to provide network relay functionality (NRF) for managing the indirect connection.

[0079] The mobile device includes:

[0080] - A connection processor, configured to manage connections to the cellular network, the connection processor providing relay functionality for managing at least one indirect connection.

[0081] The relay function is configured to at least:

[0082] - As part of the setup process, a request message is sent to at least one relay device (UEx), the request message including a relay service code (RSC1), and also including an identifier of the at least one relay device (UEx) and an identifier of the mobile device and a message authentication code;

[0083] - Receive a response message from the at least one relay device (UEx), the response message including the encrypted relay service code (RSC2);

[0084] - Decrypt the Encrypted Relay Service Code (RSC2) and insert the Decrypted Relay Service Code (RSC2') instead of RSC1 in the subsequent Discovery and Connection Setup message, thereby associating RSC2' with the same set of PDU session attributes as RSC1;

[0085] The relay equipment includes:

[0086] - A communication unit, which is arranged for communication in the cellular network, and,

[0087] - A relay processor, configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network.

[0088] The relay processor is arranged as follows:

[0089] - Receive the request message from the mobile device;

[0090] - Upon receiving a request message, a transmission request message is sent to the cellular communication system according to the request message. The transmission request message includes the relay service code RSC1, the message authentication code, and the identifier of the mobile device received from the mobile device in the request message.

[0091] - Receive a transmission response message from the cellular communication system, the transmission response message containing the Encrypted Relay Service Code (RSC2);

[0092] - Upon receiving the transmission response message, a response message is sent to the mobile device based on the transmission response message, and the response message includes the encrypted relay service code (RSC2);

[0093] The network relay function is configured as follows:

[0094] - Receive at least one transmission request message from the relay device, the transmission request message including a relay service code (RSC1) and an identifier of the mobile device, as well as the message authentication code;

[0095] - Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message;

[0096] - The different relay service code (RSC2') is encrypted using a key that allows it to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2).

[0097] - Send a transmission response message including the encrypted relay service code (RSC2) to the relay device.

[0098] In one aspect, the relay processor is arranged to store a set of backup relay service codes, and the network relay function is arranged to select the different relay service code (RSC2') from the set of backup relay service codes available in the relay device or a new relay service code.

[0099] In this aspect, at least one of the relay service code (RSC1) in the request message (M) and the transmission request message, the identifier of the mobile device, and the identifier of the at least one relay device (UEx) is encrypted by the mobile device or protected for integrity by the message authentication code, so as to indicate a protected indicator indicating that the mobile device has selected the at least one relay device (UEx).

[0100] In one aspect, the relay device includes in the transmission request message the identifier of the at least one relay device received from the mobile device in the request message.

[0101] In this aspect, the key used by the mobile device to encrypt at least one of the relay service code, the identifier of the mobile device, and the identifier of the at least one relay device, or the key used to determine the message authentication code, allows decryption by the network relay function (NRF) in the cellular network instead of by the relay device (UEx).

[0102] In this respect, if the output of decrypting the received encrypted identifier reveals the identifier of the at least one relay device, or if the message authentication code forwarded by the at least one relay device and originating from the mobile device reveals that the identifier has not been manipulated using the information received in the transmission request message (N), then the network relay function (NRF) sends only a transmission response message containing PDU session information related to the encrypted relay service code RSC2 or RSC1 to the at least one relay device (UEx).

[0103] In this aspect, the information provided by the encrypted identifier or message payload with the corresponding message authentication code in the transmission request message is used by the cellular communication system (CCS) to perform additional authentication on whether to allow / authorize the at least one relay device (UEx) to act as a relay UE for the corresponding remote UE.

[0104] In one aspect, the mobile device is configured to send a freshness parameter in the request message, the freshness parameter indicating whether the key used to encrypt elements of the request message has not been updated for a predetermined time, or indicating the time when the key was last updated.

[0105] In this aspect, the Network Relay Function (NRF) is configured to add a decrypted relay service code to the transport response message, and the relay device is configured to use the decrypted relay service code to obtain PDU session attributes.

[0106] In this context, the request message and the response message include a globally unique temporary identifier (GUTI), a temporary mobile subscriber identity (TMSI), or a subscription hidden identifier (SUCI).

[0107] In this aspect, the request message includes a relay service code (RSC1) associated with a set of PDU session attributes.

[0108] In one aspect, the mobile device is arranged to include a random number in the request message (M), and the relay device is arranged to maintain the random number used for tracking and discard any request message containing previously used random numbers or abort the setup process.

[0109] In one aspect, the mobile device is arranged to include a random number in the request message (M), and a relay device is arranged to forward the random number in the transmission request message (N), and the relay function is arranged to keep track of the random number used and discard any transmission request message containing previously used random numbers or abort the setup process.

[0110] In one aspect, the mobile device includes a non-volatile storage unit arranged to store a set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes. The mobile device is also arranged to store the set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes. The relay device includes a non-volatile storage unit arranged to store the set of relay service codes supported by the relay device, the set of relay service codes including a set of backup relay service codes. The relay processor of the relay device is also arranged to store the set of backup relay service codes. Furthermore, the network relay function is further arranged to determine a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message, wherein the different relay service code (RSC2') is selected from the set of backup relay service codes available in the relay device.

[0111] A mobile device is provided for use in a cellular communication system as defined above, comprising:

[0112] - A transceiver, arranged for wireless communication in the cellular network (130), and arranged to store a set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes, and

[0113] - A connection processor, which is arranged to manage connections to the cellular network, the connection processor providing relay functionality (116) for managing at least one indirect connection.

[0114] The relay function is configured to at least:

[0115] - Send a request message to at least one relay device (UEx), the request message including a relay service code (RSC1) associated with a set of PDU session attributes, and also including an encrypted identifier of the at least one relay device (UEx), and further including an encrypted identifier of the mobile device, the identifier being encrypted using a key that allows the identifier to be decrypted by the network relay function (NRF) in the cellular network;

[0116] - Receive a response message from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2), the encrypted relay service code (RSC2) being encrypted by the network relay function (NRF) in the cellular network using a key that allows the encrypted relay service code to be decrypted by the mobile device rather than the relay device;

[0117] - Decrypt the encrypted relay service code (RSC2) and insert the decrypted relay service code (RSC2') instead of RSC1 in the subsequent discovery and connection setup message, thereby associating RSC2' with the same set of PDU session attributes as RSC1.

[0118] Alternatively, a mobile device arranged for use in a cellular communication system as defined above is provided, comprising:

[0119] A transceiver, configured for wireless communication within the cellular network, and arranged to store a set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes, and

[0120] - A connection processor, configured to manage connections to the cellular network, the connection processor providing relay functionality for managing at least one indirect connection.

[0121] The relay function is configured to at least:

[0122] - Send a request message to at least one relay device (UEx), the request message including a relay service code (RSC1), and also including an identifier of the at least one relay device (UEx), and also including an identifier of the mobile device, and a message authentication code;

[0123] - Receive a response message from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2), the encrypted relay service code (RSC2) being encrypted by the network relay function (NRF) in the cellular network using a key that allows the encrypted relay service code to be decrypted by the mobile device rather than the relay device;

[0124] - Decrypt the encrypted relay service code (RSC2) and insert the decrypted relay service code (RSC2') instead of RSC1 in the subsequent discovery and connection setup message, thereby associating RSC2' with the same set of PDU session attributes as RSC1.

[0125] In this aspect, the key is used to encrypt at least one of the following: the relay service code, the identifier of the mobile device, and the identifier of the at least one relay device, or the key is used to determine the message authentication code that allows decryption by the network relay function (NRF) in the cellular network rather than by the relay device (UEx).

[0126] In this aspect, the mobile device selects a different Layer 2 identifier for the request message (M) from at least the most recently used Layer 2 identifier used in previous messages sent from the mobile device to the relay device. The previous message may be part of a discovery message.

[0127] In one aspect, the mobile device is configured to send a freshness parameter in the request message, the freshness parameter indicating whether the key used to encrypt elements of the request message has not been updated for a predetermined time, or indicating the time when the key was last updated.

[0128] In this aspect, the mobile device is configured to include a globally unique temporary identifier (GUTI), a temporary mobile subscriber identity (TMSI), or a subscription hidden identifier (SUCI) in the request message.

[0129] A network relay entity is provided that provides network relay functionality (NRF) for use in a cellular communication system as defined above, said network relay entity being arranged as follows:

[0130] - Receive at least one transmission request message from a relay device, the transmission request message including a relay service code (RSC1) and an encrypted identifier of a mobile device that has sent the relay service code (RSC1) to the relay device;

[0131] - Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message;

[0132] - The different relay service code (RSC2') is encrypted using a key that allows it to be decrypted by the mobile device rather than the relay device, which results in the encrypted relay service code (RSC2).

[0133] - Send a transmission response message including the encrypted relay service code (RSC2) to the relay device.

[0134] In this aspect, a different relay service code (RSC2') is selected from the set of alternative relay service codes available in the relay device to replace the relay service code (RSC1).

[0135] Alternatively, a network relay entity (140) is provided, which provides network relay functionality (NRF) for use in a cellular communication system as defined above, said network relay entity being arranged as follows:

[0136] - Receive at least one transmission request message from the relay device, the transmission request message including a relay service code (RSC1) and an identifier of the mobile device that has sent the relay service code to the relay device, as well as a message authentication code;

[0137] - Check the message authentication code to verify that the relay service code and the identifier of the mobile device have not been manipulated.

[0138] - Determine a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message, wherein the different relay service code (RSC2') is selected from a set of alternative relay service codes available in the relay device or a new relay service code.

[0139] - The different relay service code (RSC2') is encrypted using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device rather than the relay device, thereby obtaining an encrypted relay service code (RSC2).

[0140] - Send a transmission response message including the encrypted relay service code (RSC2) to the relay device.

[0141] In one aspect, the network relay function is configured to add a decryption relay service code to the transmission response message, and the relay device is configured to use the decryption relay service code to obtain PDU session attributes.

[0142] In this aspect, the network relay function is configured to include a new encrypted Globally Unique Temporary Identifier (GUTI) or Temporary Mobile Subscriber Identity (TMSI) or Subscription Hidden Identifier (SUCI) in the transmission response message (N').

[0143] A relay device is provided for communication in a cellular network as defined above, and includes:

[0144] - A relay processor, configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network.

[0145] The relay processor is configured as follows:

[0146] - As part of the setup process, receive the request message from the mobile device;

[0147] - Upon receiving the request message, a transmission request message is sent to the cellular communication system according to the request message, the transmission request message including at least one of the relay service code RSC1 and an encrypted identifier received from the mobile device in message M;

[0148] - Receive a transmission response message from the cellular communication system, the transmission response message containing the Encrypted Relay Service Code (RSC2);

[0149] - Upon receiving the transmission response message, a response message is sent to the mobile device based on the transmission response message, and includes the Encrypted Relay Service Code (RSC2).

[0150] Alternatively, a relay device is provided for communication in a cellular network as defined above, and includes:

[0151] - A relay processor, configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network.

[0152] The relay processor is configured as follows:

[0153] -A collection of code for storing standby relay services;

[0154] - As part of the setup process, receive the request message from the mobile device;

[0155] - Upon receiving a request message, a transmission request message is sent to the cellular communication system according to the request message. The transmission request message includes the relay service code RSC1, the message authentication code, and the identifier of the mobile device received from the mobile device in the request message.

[0156] - Receive a transmission response message from the cellular communication system, the transmission response message containing the Encrypted Relay Service Code (RSC2);

[0157] - Upon receiving the transmission response message, a response message is sent to the mobile device based on the transmission response message, and the response message includes the encrypted relay service code (RSC2).

[0158] In this aspect, the relay device is arranged to forward any random number or freshness parameter received in the request message (M) in the transmission request message (N).

[0159] In this aspect, the relay device is configured to maintain the random number used for tracking and discard any request messages containing previously used random numbers or abort the setup process.

[0160] The method according to the invention can be implemented on a computer as a computer-implemented method, or implemented in dedicated hardware, or implemented in a combination of both. Executable code for the method according to the invention can be stored on a computer program product. Examples of computer program products include memory (e.g., memory stick), optical storage devices (e.g., optical disc), integrated circuits, servers, online software, etc.

[0161] A non-transient form of computer program product may include non-transient program code units stored on a computer-readable medium, which, when run on a computer, are used to perform the method according to the invention. In embodiments, the computer program includes computer program code units adapted to perform all steps or stages of the method according to the invention when run on a computer. Preferably, the computer program is embodied on a computer-readable medium. A transient form of computer program product is also provided, which can be downloaded from a network and / or stored in volatile computer-readable storage and / or a microprocessor-executable medium, the product including program code instructions that, when run on a computer, are used to implement the method as described above.

[0162] Another aspect of the invention provides a method for creating a transient, downloadable computer program. This method is used when the computer program is uploaded to Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and when the computer program is available for download from such stores.

[0163] Further preferred embodiments of the apparatus and method according to the invention are set in the appended claims, the disclosure of which is incorporated herein by reference. Attached Figure Description

[0164] These and other aspects of the invention will be apparent and illustrated by further reference to the embodiments described below by way of example and to the accompanying drawings, in which:

[0165] Figure 1 shows an excerpt from a chart illustrating a user equipment (UE) requesting a slice.

[0166] Figure 2 illustrates communication via single-hop (left) and multi-hop (right) using UE-based relay equipment.

[0167] Figure 3 The diagram illustrates mobile devices, relay devices, network relay entities, and cellular communication networks.

[0168] Figure 4 An example of an NRF-assisted relay selection sequence diagram is shown.

[0169] Figure 5 An example multi-hop relay topology for mobile UEs is shown.

[0170] Figure 6a A computer-readable medium was shown, and

[0171] Figure 6b A schematic representation of the processor system is shown.

[0172] Figure 7 An example of an NRF-assisted relay selection sequence according to an embodiment is shown.

[0173] Figure 8 An example of a relay service code update sequence according to an embodiment is shown.

[0174] The accompanying drawings are purely illustrative and not drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. Detailed Implementation

[0175] Figure 3Mobile devices, relay devices, network relay entities, and cellular communication networks are illustrated. In cellular communication system 100, mobile device 110 is arranged for wireless communication in cellular communication network 130. The mobile device may be, for example, a mobile phone, a wearable medical device, or a data communication unit embedded in a vehicle. The cellular communication system (CCS) may include a radio access network (RAN) and a core network (CN), the radio access network comprising multiple cellular base stations (BS). The cellular communication system provides cellular networks that support network slicing and indirect connections.

[0176] Each network slice uses the shared physical infrastructure of the cellular communication system to provide the logical network. This is typically the case for non-public networks (NPNs), especially NPNs operating within public networks. In the case of a standalone NPN, the logical network can also be deployed as a separate mobile core network and can run a private small cell infrastructure. Sharing means that the physical infrastructure can be shared completely or partially. For example, some network functions of the first slice or NPN may be software running on other computers, rather than the network functions of the second slice or NPN, while RAN components can be fully shared between the two slices or between the two NPNs. Furthermore, the first slice or NPN, rather than the second slice or NPN, can be assigned to different frequency bands, and RAN components can be fully shared. Each indirect connection provides data transmission between the mobile device and the cellular communication system via at least one relay device. Another typical characteristic of network slices is that network traffic associated with the slice is isolated from other network traffic. Standalone NPNs also exhibit the above characteristics.

[0177] As explained in the introduction, cellular communication networks can be enhanced 5G networks.

[0178] Figure 1 schematically illustrates a network 130 for providing communication between the mobile device MOB-DEV110 and the relay device REL-DEV120. The core network may be managed by at least one telecommunications provider (e.g., for managing the subscriber database and issuing invoices).

[0179] The network can also be coupled to network relay entity 140, which provides network relay functionality (NRF) for managing indirect connections. The network relay entity can be implemented on a processor system, for example, provided at a core network, in a radio access network, or on a separate server on the Internet. The entity can be coupled to the network wirelessly and / or via wired means or through a dedicated link.

[0180] A relay device can be a mobile device used to communicate with a radio access network and can support indirect connections for data transmission to and from mobile devices. Note the difference between NRF managing multiple indirect connections. An NRF may manage indirect connections for thousands of UEs, while a relay device only manages one or more indirect connections for nearby mobile devices.

[0181] Mobile device 110 may be arranged for wireless communication with a network and has a transceiver 111 arranged for wireless communication, and a connectivity processor 112 arranged for controlling the mobile device and providing an interface to a user. The connectivity processor may be arranged for managing connections to a cellular network and provides relay functionality 116 for managing at least one indirect connection as described below. The mobile device may be provided with a user interface 113, which may include, for example, a display and one or more user input elements 115. For example, user input elements may include one or more of a touchscreen, various buttons, a mouse, or a touchpad. Buttons may be conventional physical buttons, touch sensors, or virtual buttons (e.g., virtual buttons on a touchscreen or icons to be activated via a mouse). The user interface may also be a remote user interface. Connectivity processor 112 may be coupled to non-volatile memory 116.

[0182] The relay device 120 may have a relay processor 122 and a communication unit 121. The relay processor 122 is configured to manage communications in the cellular network and to manage indirect connections with mobile devices described below. The communication unit 121 is configured to communicate wirelessly with the network. The relay processor 122 may be coupled to a non-volatile memory 123.

[0183] In a mobile device, the relay function can be configured to perform the following operations: First, a request message (M) is sent to at least one relay device (UEx). The request message may include an identifier (ID1) indicating that the mobile device is requesting access to a network slice. Next, at least one response message (N) is received from the at least one relay device. The response message may contain an indication of at least one available slice for relaying via the at least one relay device to provide an indirect connection. This indication may be explicitly defined (e.g., defined as part of an additional "slice relay information" field in the response message N), or implicitly defined (e.g., message N is an acknowledgment confirming that the requested slice can be relayed via the appropriate relay device). Then, based on the response message, a relay device (UEy) is selected from the at least one relay device that supports the requested slice. The response message may also include information about additional slices that can be supported from which the remote UE can select. If the remote UE is limited to only a single (e.g., private) slice or if only one available slice is suitable for the UE, the selection is effectively to take such a single slice. If the selected slice is the same as the requested slice, the remote UE can select the appropriate relay UE from which it receives a response, and can reuse the same device-to-device (D2D) connection (e.g., PC5) between the remote UE and the relay UE used to set up the indirect connection to the network via the relay UE. If only a single available relay UE is suitable for the remote UE, then the selection is effective in using such a single relay UE. The indirect connection is then joined to the selected slice via the selected relay UE, which can reuse the same D2D connection between the remote UE and the relay UE used to send request messages (M) and / or receive response messages (N).

[0184] In a relay device, a relay processor can be configured to perform the following operations: First, receive a request message (M) from a mobile device. Then, based on the request message, send a transmission request message (M') to the cellular communication system. The transmission request message indicates a request for data transmission to and from the mobile device via an indirect connection. The transmission request message includes a requested identifier (ID1). The transmission request message can be the same as message M, or it can be a newly constructed message by the relay device based on information received in message M, or it can be a message encapsulating the contents of message M (e.g., as part of an IPSec tunnel, or by adding / changing some routing headers) or a variation thereof. The identifier sent as part of the transmission request message (M') can be a copy of the requested identifier (ID1), or it can be an encrypted, encoded, hashed, and / or captured ID1, or it can be a one-to-one mapped replacement identifier.

[0185] Then, a transmission response message (N') is received from the cellular communication system, as explained below. A response message (N) is then sent to the mobile device based on the transmission response message.

[0186] In a network relay entity, the Network Relay Function (NRF) is configured to perform the following operations: First, at least one Transmission Request message (M') is received via at least one cellular base station. Then, relay capability data is obtained regarding relay devices capable of transmitting data to and from mobile devices for at least one available slice. One or more available slices are determined based on the requested identifier (ID1). Next, at least one Transmission Response message (N') is transmitted via at least one cellular base station. The Transmission Response message includes network relay information indicating at least one available slice and at least one relay device capable of transmitting data from the available slice.

[0187] Optionally, in the network relay information, the transmission response message (N') includes a set of relay devices (T). Also, or alternatively (e.g., in the slice relay information field), the response message (N) includes a set of relay devices (T). For example, the set of relay devices could be an ordered list of available relay devices, such as sorted by preference level or suitability.

[0188] Optionally, the corresponding transmission response message may be addressed to only one specific relay device, and the response message may indicate the relay device itself as a relay device. Such a message may only implicitly indicate the relay device. Therefore, the message may not explicitly indicate the relay device with some "relay ID" or similar message element. Alternatively, the message may include, for example, only the network address of the specific relay as the destination address in the message header. The relay device may be implicitly indicated by the destination address of the relay (e.g., in the case of the transmission response message (N')) or may be implicitly indicated by the source address of the relay (e.g., in the case of the response message (N)). For example, a use case may have 3 relay devices a, b, c, each responding to a broadcast from a mobile device using information about its own slice(s)(s) it is capable of supporting to the mobile device. Then message N does not need to list any relay (capability) devices, because each relay (a / b / c) responds on its own behalf. In this scenario, the relay's (a / b / c) identity can only be found in the standard "Source" field (e.g., MAC source address) in the message header. In higher-level messages, the relay's (a / b / c) identity may not exist, or it may indicate itself. The mobile device selects one of the relay devices (from which it receives the appropriate response message) and establishes an indirect connection via the selected relay device.

[0189] Optionally, the corresponding transport response message includes instructions for various actions. Instructions may be available to reconfigure the existing PDU session between the relay device and the network to accommodate relay network traffic for a specific slice (e.g., changing the DNN, connecting to a different user plane function), update the UE configuration (potentially including information such as different S-NSSAI information, different policy information, different credentials), trigger the device to reconnect to the network by breaking the existing PDU session and setting up a new one, which may result in the selection of a different Access and Mobility Management Function (AMF) to serve the network slice. The transport response message may include instructions for initiating an additional PDU session with the network in case the relay UE is already serving other remote UEs, and may also include instructions for connecting to a different PLMN / NPN. The transport response message may also include instructions to reside on a specific unit associated with a Closed Access Group (CAG) ID to access the slice, particularly in the case of an NPN operating in a public network.

[0190] Optionally, the corresponding transmission response message includes instructions / information in the network relay information regarding resource scheduling requests from base stations based on available slices (e.g., related to characteristics, QoS flow, minimum / maximum / preferred bit rate, priority, frequency band, bandwidth, resource allocation between different slices), in which the base station is using the resource scheduling requests to schedule sidechain resources for selected relay devices for communication on available or selected slices, for mobile devices and available relay devices. Alternatively, instructions / information regarding base station resource scheduling requests from base stations based on available slices can be sent as a separate message from the NRF to the base station (or nearby base stations) via the AMF, either directly or via routing / tunneling (in the case where the NRF is not integrated with the AMF).

[0191] Optionally, the corresponding transmission response message may include configuration updates, authorization updates, or policy updates for a remote UE that has been out of coverage for some time. The relay UE may forward this information to the remote UE using response message N. This information may be encrypted using security credentials known only to the remote UE to prevent it from being exposed to the relay UE.

[0192] More specifically, the cellular communication system refers to a mobile device UE0 operating as a cellular communication user equipment, and a set of relay devices S{UE1,...,UEn} (n>=1) operating as cellular communication user equipment and also capable of relaying network traffic from UE0 to a cellular communication system CCS capable of supporting relay operation and network slicing / network traffic from a cellular communication system CCS capable of supporting relay operation and network slicing to UE0.

[0193] Device UE0 can operate as follows.

[0194] Device UE0 sends message M to relay device UEx in set S. This message includes an identifier, which may be the network slice identifier ID1 that device UE0 is requesting access to. ID1 may be S-NSSAI (as defined in 3GPP [24.501]), optionally a portion of the set of slice identifiers. Alternatively, the message may include a temporary slice identifier (complete or as a hash value) or an encrypted slice identifier (as defined in 3GPP [33.813]). Note that in this case, it would be convenient for the core network to maintain a list of previous temporary identifiers to check for matches, as the remote UE may have been out of coverage for some time and therefore the temporary identifier may no longer be up-to-date. Alternatively, the message may include a combination of PLMN and network identifier (NID) or CAG ID to refer to the slice, particularly in the case of NPN. The message may include any other type of identifier (e.g., an identifier pre-configured in the UE, or an identifier that is periodically updated during or after registration, or an identifier derived from a derivation function or mapping table that can be uniquely pre-configured for each UE), based on which the NRF (e.g., AMF / NSSF / ProSe function or other network function) or the relay device UEx is able to (e.g., using a hash table or other type of mapping function) deduce which slice device UE0 is requesting.

[0195] Message M can be, for example (as defined in 3GPP [23.303]), a D2D / PC5 discovery message with additional information elements to indicate the requested network slice identifier, or message M can be, for example (as defined in 3GPP [23.287]), a PC5 direct communication request with additional information elements to indicate the requested network slice identifier, or message M can be used with the requested identifier (ID1) as a (V2X) service code or application ID, or message M can be, for example (as defined in 3GPP [24.501]), a PDU session establishment request with additional information elements to indicate the requested network slice identifier, or message M can be, for example (as defined in 3GPP [24.501]), a registration request using the existing “Requested NSSAI” attribute, or message M can be, for example (as defined in 3GPP [24.501]), a UL NAS using the existing “S-NSSAI” attribute. TRANSPORT, or message M, can be, for example, another type of PC5 / NAS / RRC message, which has additional information elements to indicate the requested network slice identifier.

[0196] Device UE0 receives message N from device UEx. The message may include a network slice identifier ID2, for example, as part of an additional slice relay information field. ID2 may be the same as ID1, an instance identifier, an allowed slice identifier, or a default slice identifier. Alternatively, message N may include information about a subset S' of S that allows or disallows, or prefers to use UE0 to set up indirect connection sessions with the network slice of the cellular communication system CCS identified by ID2. As another alternative, message N includes a Boolean value or a set of Boolean values ​​indicating support for a set of requested and / or supported slices. In yet another alternative, message N is an acknowledgment of a match found between the requested slice and a list of slice IDs to which the mobile device can connect via the eRelay UE. Message N may be sent only if it is possible for relay device UEx to act as a relay for the indirect communication session of device UE0 within the requested network slice. Message N can be formatted, for example, as a D2D / PC5 discovery response message (as defined in 3GPP [23.303]), or a PC5 direct communication accept message (as defined in 3GPP [23.287]), or a PDU session establishment accept message (as defined in 3GPP [24.501]), or a registration accept message (as defined in 3GPP [24.501]), or a DL NAS TRANSPORT using the existing “S-NSSAI” attribute (as defined in 3GPP [24.501]), or another type of PC5 / NAS / RRC message.

[0197] Device UE0 selects relay device UEy from set S for communicating with the cellular communication system CCS. If device UEx is not permitted or is not preferred for setting up an indirect connection with the requested network slice, UEy may differ from UEx.

[0198] Note that, optionally, the relay UE can respond automatically via message N, for example, based on pre-configured information from the NRF that enables it to serve a particular slice, for example, because it is part of the same slice, has the same security context, and has sufficient resources to act as a relay for remote UEs. This option can also work for default slices, such as those operating within the same PLMN, and for relays operating in private slices, such as those operated and configured by the same third party to be part of the same group, or belonging to a specific group of devices (e.g., public security UEs). Optionally, the NRF can pre-configure relay UEs for a set of slices (e.g., default slices in which the relay UE can operate and / or specific private slices), and optionally, for relevant policy rules, such as when the relay UE is authorized, enabled, or granted resources to respond to relay discovery messages. This can be accomplished, for example, by pre-sending a message containing pre-configured slice relay information to the relay UE.

[0199] The relay device UEx (1<=x<=n) can operate as follows.

[0200] Device UEx receives message M from device UE0, which includes the network slice identifier ID1 that device UE0 is requesting to access.

[0201] The device UEx transmits message M' to the cellular communication system CCS, either directly or via one or more other relay devices UEy (1 <= y <= n), based at least in part on message M.

[0202] The device UEx receives a message N' from the cellular communication system CCS, which includes a network slice identifier ID2 and a subset S' of S' indicating whether UE0 is allowed or not allowed, or whether it prefers to use UE0 to set up a relay connection session with the network slice of the cellular communication system CCS identified by ID2.

[0203] Device UEx sends message N to device UE0 based at least in part on message N'.

[0204] Message M' can be, for example, a ProSe matching report (as defined in 3GPP [24.334]), or message M' can be, for example, another message on the PC3 interface with (one or more) additional fields to indicate information about the slice requested by UE0, or message M' can be, for example, a NAS message with (one or more) additional fields to indicate information about the slice requested by UE0 (as defined in 3GPP [24.501]). In the case of Layer 2 relay, message M' can be a received PDCP frame containing a NAS message as received from device UE0, which is transparently forwarded by relay device UEx to the base station / core network via its Uu interface (or transparently forwarded to subsequent relay devices via other PC5 interfaces). It can also be a new dedicated NAS or RRC message (e.g., a relay request message) containing the requested information about the slice requested by UE0.

[0205] In a cellular communication system (CCS), a relay device (UEx) can be communicatively coupled to base stations (BS) of multiple cellular base stations within the RAN. The CCS provides a Network Relay Function (NRF). Base stations can be communicatively coupled to Access and Mobility Management Functions (AMFs) in the CN. The core network can host multiple AMFs assigned to different slices. A base station can select the appropriate AMF based on the requested slice identifier ID1 received in message M'.

[0206] The base station (BS) can receive messages M' from one or more relay devices (UEx) and forward them to the NRF. The BS generates a new message for the NRF based on the received message, or interprets message M' via the NRF (e.g., through a built-in NRF). The forwarded message can be a NAS message. The new message can be, for example, an initial registration message, a UE background information message, or another NG Application Protocol (NGAP) message on the N2 interface, similar to the S1 Application Protocol (S1AP) on the S1 interface in 4G.

[0207] CCS can also host different network relay functions, or different NRF instances can be assigned to different slices. The base station can select the appropriate NRF based on the requested slice identifier ID1 received in message M' and forward the message to the selected NRF. If the NRF is not directly coupled to the base station but is directly coupled to the AMF, the AMF can select the appropriate NRF based on the requested slice identifier ID1 received from the message it receives from the base station.

[0208] In CCS, the Network Relay Function (NRF) can operate as follows.

[0209] The message M' received from the Access and Mobility Management Function (AMF) or at least partially based on message M', or the message M' received directly from the base station BS, includes the network slice identifier ID1 that UE0 is requesting to access.

[0210] Obtain information I about the set T of UEs capable of relaying network traffic from UE0 to RAN / from RAN to UE0, and the capabilities of these UEs.

[0211] The relay device is determined in part based on the received message M” and the obtained information I. The relay device may constitute a subset T' of the relay communication sessions T' set up with the network slice of the cellular communication system CCS identified by ID1, which are either allowed or not allowed or preferred to use UE0 as a relay device.

[0212] Message N” can be sent back to the AMF or base station BS. Message N” may include information about subset T’ and network slice identifier ID2.

[0213] Finally, the AMF or base station BS sends message N' to the relay device UEx at least in part based on message N'. Note that the message may also be addressed directly to a subset of the remote UE or relay UE, either alternatively (e.g., via the AMF) or to an intermediate node, such as a base station connected to the relay UE, which then forwards the information in the new message to the relay UE.

[0214] During discovery, the UE describes NRF-assisted relay selection via a request, whereby the UE makes a selection based on pre-selection by the NRF. The UE can be configured to connect to one or more network slices and can also be configured to discover nearby relay-capable UEs in certain situations based on configured policies, such as relay-capable UEs outside the coverage area of ​​a base station. To discover nearby relay-capable UEs, the UE sends a D2D / PC5 discovery message, which may include new attributes indicating one or more IDs of the slice it wishes to connect to. Relay-capable UEs within radio range can receive this message and can report the information from the message to the Network Relay Function (NRF) in the core network (CN). Specifically, the message includes information about the IDs of one or more slices(s)(s)(s)(s)) the UE is requesting.

[0215] Based on the received information, the NRF determines which (potential or already activated) candidate relay UEs are capable of and / or permitted and / or will optimally utilize (one or more) of the requested slices to serve the requesting UE, or, if the complete set is unavailable, to serve a subset of the requesting UEs. To this end, the NRF may need to request / receive information from other network functions (e.g., Access and Mobility Management Functions (AMF) – where the NRF and AMF are not integrated – or the Radio Access Network (RAN)), or request / receive information directly from the relay UE, including further details about capabilities, contextual information, connection nature, and other information such as mobility / location / speed information for each relay-capable UE within the UE's discovery range, or information that, in other cases, may or is involved in (e.g., in the case of multi-hop relay) setting up an indirect connection from the UE to the Radio Access Network. The NRF can use this information along with other information it may request / receive from other network functions (e.g., Policy Control Function (PCF), Unified Data Management (UDM), Network Slice Selection Function (NSSF), etc.) (where the NRF is not integrated into these network functions) to assess whether each of these candidate relay UEs is permitted, capable, and has sufficient resources available and will be able to obtain the required QoS to act as a relay UE for the requested network slice. Additionally, the NRF may request information about its "reputation as a relay UE" (e.g., from the Network Data Analysis Function (NWDAF)), as a relay UE can have a "bad reputation" (or record) when it begins acting as a relay, for example, it may drop connections, perform service denial by ignoring traffic from all remote UEs, or limit the bandwidth of remote UEs.

[0216] In addition, NRF can consider other criteria, such as RAN congestion or whether the base station or AMF / MME to which the candidate relay UE is connected is close to or has reached a certain maximum number of UE / PDN connections per slice, and can provide different candidate relay UEs for requesting the UE to connect to.

[0217] Furthermore, the NRF can use preliminary UE subscription information to check whether the UE is allowed to operate in the slice(s) it has requested. Note: Because the UE has not yet authenticated with the core network at this point, and the UE only sends information related to its identity via a relay discovery request, which may be unauthenticated data (i.e., easily forged / altered), the NRF does not use this information to authenticate the UE. It is only used as guidance in the selection process.

[0218] When the Network Relay Function (NRF) receives the requested identifier (ID1) in a Transmission Request message (M'), it can use ID1 to obtain relay capability data about the relay device capable of transmitting data to / from a specific network slice based on the characteristics of the network slice indicated by ID1. However, in the case of a roaming remote UE, the NRF may be unaware of both the identifier ID1 and the characteristics of the slice indicated by ID1. Alternatively, the NRF may be aware of the identifier ID1, but that identifier ID1 has different slice characteristics because the relay UE's operator and the remote UE's operator use the identifier ID1 for different purposes. In other words, overlap between identifiers may exist if operators do not use a mutual agreement regarding the values ​​of identifiers such as ID1. To address these potential issues, upon receiving M', the NRF can contact the NRF of the remote UE's home PLMN (HPLMN) (if known), or it can contact the AMF (or database) of one or more other PLMNs (using, for example, a request message M' to the HPLMN NRF) to obtain the characteristics of the slice indicated by ID1, and can also verify if the remote UE is authorized to connect to the slice indicated by ID1. Once the slice characteristics are retrieved (e.g., via a response message N'' from the HPLMN NRF), the NRF can configure the relay UE to support relaying for the slice indicated by ID1 using parameters, such as sending a security key to the relay UE or parameters from which the relay UE can derive the security key. The NRF can include such configuration information, wholly or partially, in the transmission response message N', or the NRF can include the configuration information in other separate messages. The NRF can also configure the PDU sessions of the relay UE and / or the remote UE based on the retrieved characteristics of the slice indicated by ID1 to, for example, optimally meet the QoS service requirements of a particular slice. Furthermore, the NRF can configure parameters on the gNB serving the relay UE to, for example, optimally meet the QoS service requirements of a specific slice, which may include communication latency requirements or data throughput requirements.

[0219] Another solution is to coordinate the allocation of identifiers such as ID1 among operators. For example, one operator may reach an agreement with all operators for which it enables UEs to roam from other operators on its own (one or more) cellular networks.

[0220] The NRF can then send a message back to one or more selected candidate relay UEs, wherein the message for each relay UE includes a set of slices that can be provided to the requesting UE via that particular relay UE. In other words, for each candidate relay UE, it includes a set of "accepted slice IDs". The NRF may also include a set of "rejected slice IDs" if the complete set of requested slices cannot be reached, or if the relay UE is not permitted to be used as a relay UE for network communication for the requested slice. The received slice information can also be an instance identifier, an allowed slice identifier, or a default slice. Optionally, the message may include information about a list of other possible candidate relay UEs that can be used to establish an indirect connection with the core network to gain access to the requested slice. This list can be sorted according to preference or suitability to act as relay UEs for the requested slice.

[0221] Each relay UE receiving such a message will then send a discovery response back to the requesting UE using the information from the message. This response may optionally include slice information (or other information from which the requesting UE can deduce whether the relay UE can support relay communication for the requested slice), and may also include information about other candidate relay UEs. Because the (potential) relay UE communicates with the NRF before sending a discovery response to the requesting UE, the discovery response from the relay UE may potentially be sent slightly later than expected by the requesting UE. In this case, the relay UE may send an initial discovery response indicating its existence, but further information, including slice information, will be sent later, pending NRF / CN approval.

[0222] Based on the received discovery response it receives from the candidate relay UE, the UE is now able to select the best candidate relay UE to connect to, and then (e.g., via a ProSe-like process) connect to that best candidate relay UE, and via core network procedures, connect to (one or more) the requested slice or its available subset. Alternatively, the NRF selects only a single relay UE and instructs the relay UE to connect to the UE that requested the relay to connect to the requested slice.

[0223] Figure 4 An example of an NRF-assisted relay selection sequence diagram is shown. The diagram schematically illustrates an example flow and message sequence. In this diagram:

[0224] •NF is the Network Relay Function (NRF) as described above;

[0225] • NF2 is an optional extension of NRF (or ProSe function) that handles granting permission for a relay UE to accept a new remote UE;

[0226] R1, R2, and R3 are relay UEs or potential relay UEs; it is assumed here that R3 is connected to a different gNB, namely gNB2. In this example message sequence, detailed information about each relay UE (e.g., capabilities, signal quality, etc.) is sent directly to the NF to reduce the time the NF takes to collect all this information;

[0227] The “opt” box refers to optional communication used to request further information from the RAN regarding slices and QoS, but it could also be information about other potential nearby relay UEs, measurement information, location / mobility information of different UEs, etc. Currently, it is shown as information requested from the RAN, but it may also need to be requested from the AMF, PCF, UDM, NSSF, or other network functions. It is shown as optional because the NRF may have already received this information in advance;

[0228] • NSSAI is a collection of up to 8 slice IDs, as further described in the 3GPP specification [23.501].

[0229] A connectivity processor in a mobile device can be configured to initiate a relay discovery process and engage an initial indirect connection. The connectivity processor then sends a request message via the initial indirect connection. A network relay entity (140) or relay function can be configured to reconfigure the initial indirect connection to route the indirect connection to a selected slice via a selected relay device. Thus, an active relay UE can be reconfigured to use another relay, where the UE initially selects an initial relay, and the NRF or UE reconfigures that selection. The UE requiring relay UE selection sends a D2D / PC5 message to initiate relay discovery. The relay UE and potential relay-capable UEs within radio range receive this message and respond to the discovery response using existing procedures (possibly ProSe procedures). The UE then selects a suitable relay UE candidate, even if it is not yet aware whether the relay UE will fully support all its required slices, and connects to it. Through the relay UE connection, the UE performs 5G network registration and / or PDU session establishment using existing procedures, which includes requests for one or more slices.

[0230] The NRF may involve the following process. Once the base station or Access and Mobility Management Function (AMF) receives the NSSAI requested by the UE, it can inform the NRF of this. Following this, the NRF can determine which (potential) relay UE or set of relay UEs can and / or is permitted and / or will optimally utilize the requested set of slices to serve the requesting UE in the same manner as previously described. Then, if the NRF determines that the most suitable relay UE for the UE requesting access to one or more slices is another relay UE rather than the current relay UE, the NRF sends a reconfiguration message to the UE (e.g., a configuration update command as defined in 3GPP [24.501]). This message can be sent directly or addressed via an intermediary such as a gNB or relay UE, and can indicate in new attributes of the message the ID or address of the relay UE to be preferentially used and the set of slices available to that relay UE. This set can be larger than the currently supported slices for the UE. Additionally, the NRF may send a list of relay UEs along with the preference level and / or slice set for each relay UE. Alternatively, information about which relay UEs can or should be used for a specific slice can be provided as a new extension to the UE Routing Policy (URSP) as defined in 3GPP [29.507][23.503], and this new extension can be sent to the UE using the UE Policy Delivery Protocol defined in Annex D of 3GPP [24.501].

[0231] When a UE receives a reconfiguration message or an updated URSP, and based on the information received, the UE may continue to use the relay UE it already uses, or the UE may need to perform relay UE discovery again, optionally by specifically searching for a new preferred relay UE during the discovery period and connecting to it.

[0232] As an additional example, an enhanced ProSe (eProSe) scenario in 5G is described, which embodies the reconfiguration of another eRelay UE (enhanced relay UE) that better supports the requested slice. The example scenario illustrates how it can be applied to a 5G system architecture. This scenario assumes that devices with relay capabilities have already activated their relay functions and are therefore used as relay devices with 5G network licenses. On-demand activation of relay functions in devices with relay capabilities is also possible, but is not described further.

[0233] The example eProSe scenario involves the following. A mobile device (UE) that has lost connection to the 5G core network and is unable to re-establish it uses eRelay open discovery to initiate the eProSe eRelay discovery model B process. The mobile device acts as an eRemote UE in this process. If authorization to perform this process is granted by the ProSe function for situations outside coverage, the mobile device first checks its UE configuration. If this is the case, it checks its UE configuration whether the ProSe function authorizes it to act as an eRemote UE when outside coverage. If this is also the case, it sends a PC5_DISCOVERY message of the eRelay discovery solicitation type to request a nearby eRelay UE (which can also be referred to as an eProSe UE to a network relay UE). This message is sent via sidechain (SL) spectrum resources. In this example, open discovery is used, meaning the broadcast request is not encrypted: any eRelay UE can parse the request without requiring a specific security context or key. Alternatively, without further detail here, a secure discovery process called eRelay restricted discovery can be used to prevent potential information leakage.

[0234] Subsequently, each eRelay UE reports the information and / or request parameters received from the mobile device to the ProSe function via the PC3 interface or its 5G eProSe equivalent, using messages such as ProSe MATCH_REPORT. The ProSe function collects all MATCH_REPORT messages sent by the eRelay UE. It determines what the response to each message should be and (via the PC3 interface or its 5G eProSe equivalent, using, for example, a MATCH_REPORT_ACK message) sends each response message back to the corresponding eRelay UE. Each eRelay UE that receives such a message (i.e., a message implemented, for example, as a MATCH_REPORT_ACK message via PC3) will send a response message to the mobile device based on its content. This response message is implemented, for example, as a PC5_DISCOVERY message of the eRelay discovery response type via interface PC5-D. The mobile device receives such a message from one or more eRelay UEs, which allows it to select an eRelay UE that appears suitable for connection using, for example, a decision process standardized for 4G ProSe or its 5G eProSe equivalent.

[0235] Subsequently, using the selected eRelay UE, the mobile device continues the 5G core network attachment procedure, where communication is relayed by the selected eRelay UE at the MAC layer (i.e., L2). This procedure may, for example, involve the mobile device, acting as an eRemote UE, sending an INDIRECT_COMMUNICATION_REQUEST message to the eRelay UE via PC5. Based on this, the eRelay UE sends a message to the relevant network function, which can be implemented as sending a UE-triggered service request message to the Access and Mobility Management Function (AMF) or the ProSe function in the 5G core network, allowing the 5G core network to determine what response the eRelay UE should send to the mobile device. The 5G network function (e.g., AMF or ProSe function) sends a response from the core network to the eRelay UE, based on which the eRelay UE sends a response message such as INDIRECT_COMMUNICATION_REQUEST to the mobile device via the PC5 interface. Following a successful positive response, the mobile device performs a process similar to the existing 5G core network registration process—the key difference being that messages sent by the mobile device are not directly sent to the base station, but are relayed to the base station via the eRelay UE and ultimately to the core network. The registration process begins with the 5G-NR RRC connection setup procedure, which ends when the mobile device sends an RRCSetupComplete message to the base station, which includes a NAS registration request. The NAS registration request sequentially includes the NSSAI requested for each element of the standard 5G procedure. Based on this procedure, the base station (gNB) initiates UE registration with the 5G core network, which begins by forwarding the mobile device's NAS registration request to the AMF. The NAS registration request, containing the requested NSSAI, acts as a transport request message. In this case, the AMF largely implements NRF as described herein. The AMF (potentially assisted by other network functions, such as ProSe functions – which would constitute a distributed NRF) determines the optimal eRelay UE that the mobile device should connect to in order to best satisfy its requested NSSAI, and also determines the allowed NSSAI (i.e., the set of slice IDs (S-NSSAIs) that the optimal eRelay UE can serve). In response to the NAS registration request, the AMF constructs a response message NAS registration accept, which includes a new information element indicating the "allowed NSSAIs served by the optimal eRelay UE" and the identity / address information of the optimal eRelay UE.Note that the AMF can optionally include multiple eRelay UEs, where each eRelay UE includes a set of allowed NSSAIs, thus enabling the mobile device to select an eRelay UE from a set of multiple “optimal” eRelay UEs. NAS registration acceptance is delivered back to the base station.

[0236] Subsequently, based on the received message, the base station sends a message, such as an RRC reconfiguration message, which includes, as a new element in the message, information about the "permitted NSSAI served by the optimal eRelay UE" and an indication of the optimal eRelay, or alternatively, a set of multiple eRelays having their permitted NSSAIs. This triggers the mobile device to evaluate the new information to detect another eRelay UE that can better serve it using the indicated slice in the permitted NSSAI, and to restart the relay procedure by establishing a connection via the indicated optimal eRelay UE. This process can optionally involve the updated discovery of eRelay UEs.

[0237] Additionally, the "Permitted NSSAI by Optimal eRelay UE Service" information can be supplemented by an optional field for each eRelay UE, which indicates which security background ID or application ID the mobile device should use to correctly discover the eRelay UE.

[0238] The following describes a second eProSe scenario in 5G, in which slice information exists in eProSe discovery, and Model B messages enable the UE to directly select the optimal relay device. Furthermore, this example scenario assumes that devices with relay capabilities have already activated their relay functions.

[0239] The second eProSe scenario involves the following. A mobile device UE that has lost its connection to the 5G core network and is unable to re-establish that connection uses eRelay open discovery to initiate the eProSe eRelay discovery model B process. The mobile device acts as an eRemote UE in this process. If authorization to perform this process is granted by the ProSe function for situations outside coverage, the mobile device first checks its UE configuration. If this is the case, it checks its UE configuration whether the ProSe function authorizes it to act as an eRemote UE when outside coverage. If this is also granted, it sends a PC5_DISCOVERY message on the sidechain (SL) spectrum of the eRelay discovery solicitation type to request a nearby eRelay UE (which can also be referred to as an eProSe UE to a network relay UE) to respond using relay information. In this example, open discovery is used, meaning that the broadcast request sent is not encrypted, allowing any eRelay UE to parse the request without requiring a specific security context or key. Alternatively, a secure discovery process, eRelay restricted discovery, can be used to prevent potential information leakage, but this will not be discussed further. The eRelay discovery call message may include an additional element, “Requested NSSAI,” which is a list of one or more slice IDs (i.e., a list of S-NSSAIs) that the mobile device will want to connect to via the eRelay UE.

[0240] Subsequently, each eRelay UE, via the PC3 interface or its 5G eProSe equivalent, uses messages such as ProSe MATCH_REPORT to report information and / or requests received from the mobile device, including the requested NSSAI, to the ProSe function. The ProSe function implements this network relay function and collects all transmission request messages. It determines, for each eRelay UE, which slice from the requested NSSAI slices can be provided to the mobile device via an indirect connection. This determination may involve communication with other network functions (RAN, base station, AMF, servers containing MNO subscription information, etc.) to obtain the optimal slice decision that can be supported.

[0241] Subsequently, the ProSe function sends a transmission response message back to each eRelay UE in the corresponding eRelay UE via the PC3 interface or its 5G eProSe equivalent, using, for example, a MATCH_REPORT_ACK message. This message destined for a given eRelay UE optionally includes the additional information element "Allowed NSSAI," which is a list of one or more slice IDs (i.e., a list of S-NSSAIs) that the mobile device can connect to via that eRelay UE; and it optionally includes the additional information element "Denyed NSSAI," which is a list of one or more slice IDs for which access via the eRelay UE is determined by the ProSe function to be infeasible.

[0242] Subsequently, each eRelay UE that receives the message (i.e., implemented as a MATCH_REPORT_ACK message via PC3) will send a response message to the mobile device, which is implemented as, for example, a PC5_DISCOVERY message of the eRelay discovery response type sent to the mobile device via interface PC5-D. This message now includes the slice ID included in the MATCH_REPORT_ACK as a new element. The new element is optionally an allowed NSSAI if a given eRelay UE can be used as an eRelay UE for (one or more) slices for the mobile device, and optionally a rejected NSSAI if the eRelay UE is rejected by the ProSe function for (one or more) slices for the mobile device. Alternatively, the response message includes a Boolean value or set of Boolean values ​​as a new element indicating support for the set of requested and / or supported slices. Alternatively, the response message is a different formatted message confirming that a match has been found between the requested slice and a list of slice IDs that the mobile device can connect to via the eRelay UE. A response message may only be sent if it is possible for a given eRelay UE to be used as a relay for a mobile device for the requested network slice.

[0243] Subsequently, the mobile device receives the message from one or more eRelay UEs, allowing it to select, for example, an eRelay UE that initially indicated all or most network slices in its requested NSSAI. Alternatively, the mobile device can choose an eRelay UE that does not provide the most network slices, but does provide the most important (highest priority) network slice that the mobile device wishes to connect to. Using the selected eRelay UE, the mobile device proceeds with the 5G core network attachment procedure, where communication is relayed at L2 by the selected eRelay UE. This procedure may, for example, involve the mobile device (acting as an eRemote UE) first sending an INDIRECT_COMMUNICATION_REQUEST message to the eRelay UE via PC5, based on which the eRelay UE sends a message to the relevant network function, which can be implemented as sending a UE-triggered service request message to the Access and Mobility Management Function (AMF) or the ProSe function in the 5G core network, enabling the core network to determine the content of the response that the eRelay UE should send to the mobile device. The network function sends a response from the core network to the eRelay UE. Based on this, the eRelay UE sends an INDIRECT_COMMUNICATION_REQUEST to the mobile device via the PC5 interface. After successfully parsing a positive response, the mobile device initiates a process similar to a normal 5G core network registration process—the key difference being that related traffic is relayed via the eRelay UE. This process begins with the 5G-NR RRC connection setup procedure, which, for each standard 5G procedure, ends again with the mobile device sending an RRCSetupComplete message to the base station, including the requested NSSAI. Based on this procedure, the base station (gNB) initiates UE registration with the 5G core network, which includes connections to one or more network slices.

[0244] In the third eProSe scenario in 5G, the discovery process is skipped, and instead the requested slice identifier is sent to the eRelay UE via PC5 as part of the INDIRECT_COMMUNICATION_REQUEST message. At this time, after performing message exchange with the AMF or ProSe function (or other network function) to confirm whether the eRelay UE can and is allowed to act as a relay for communication between the eRemote UE and the requested network slice, the eRelay UE sends an INDIRECT_COMMUNICATION_REQUEST message including information (e.g., a set of allowed slice IDs, a Boolean value indicating support for the requested slice) to confirm that the eRemote UE can connect to the requested slice via the eRelay UE.

[0245] In another alternative, relaying can be performed at Layer 3 or via application-level relay, in which case the DIRECT_COMMUNICATION_REQUEST message (as defined in 3GPP [23.287]) and the DIRECT_COMMUNICATION__ACCEPT message (as defined in 3GPP [23.287]) can be used instead of the INDIRECT_COMMUNICATION_REQUEST message and the INDIRECT_COMMUNICATION__RESPONSE message, respectively.

[0246] In another example scenario, a vehicle-to-everything (V2X) mobile device can communicate with a specific destination within the network. The vehicle UE can use V2X 5G communication on two specific slices, where "V2X" and "Entertainment" might lose their gNB coverage at some point. The vehicle UE initiates relay UE discovery and finds 10 candidates belonging to different PLMNs. Two of the candidates indicate specific support for both the V2X and Entertainment slices in their discovery response messages. The vehicle UE selects the candidate with the highest signal quality and initiates a connection to that relay UE as a remote UE. During the core network registration process, these two slices are designated as "allowed NSSFs" for the vehicle UE.

[0247] Figure 5 An example multi-hop relay topology for a mobile UE is shown. The mobile UE may have lost coverage while it was previously connected to a gNB / eNB. The UE outside coverage (OoC) can initiate a relay discovery procedure, which instructs it to request slices X and Y. In this figure, both UE (1) and UE (3) receive a discovery message and report the OoC-UE information and the requested slices X / Y to the NRF in the CN via the gNB. The NRF can determine that slice X is associated with Ultra-Reliable Low-Latency Communication (URLLC) and is optimally served with the minimum number of hops for the lowest latency, while a high data rate is important for slice Y.

[0248] The NRF determines that UE (1) has the fastest connectivity to the gNB, sufficient bandwidth to add additional relay traffic, and also satisfies slice Y. The NRF then reports back to UE (1) with slice IDs for both X and Y and a preference value of "high". Furthermore, the NRF can authorize UE (1) to become a relay UE for serving OoC-UEs. Authorization can be based on a separate message / protocol or in combination with the previous step. The NRF can also (simultaneously) provide credentials to allow the relay UE access (one or more) of the requested slices.

[0249] The NRF can report to the UE (2) with slice IDs X and Y and a preference value of "low". Upon receiving an NRF response, the UE (1) can send a discovery response to the OoC-UE with slices X / Y and a preference value of "high".

[0250] UE(3) can receive NRF responses and send discovery responses to OoC-UEs with slice X / Y and preference "low".

[0251] The OoC-UE can receive two discovery responses and can select UE(1) as a relay UE; and perform an attachment procedure to that relay UE. Thus, by running the above procedure, UE(1) becomes a relay UE during processing. It can optionally perform this operation when it determines a high probability that it will be selected as a relay UE by the OoC-UE due to a “high” preference value.

[0252] Note that the above concept can be mapped to 5G cellular communication systems (5GS). Network Relay Function (NRF) can be mapped to the Network Slice Selection Function (NSSF) defined in 5G [23.501] or a combination of NSSF and AMF [23.501], but it can also be a new, standalone network function. A requested slice / slice instance can be mapped to a requested NSSAI [23.501] or a temporary / encrypted slice identifier [33.813] or some other newly defined identifier. Allowed / supported slices determined by the NRF can be mapped to allowed NSSAI [23.501]. Slice IDs can be mapped to S-NSSAI [23.501] and sets of slice IDs can be mapped to NSSAI [23.501].

[0253] Furthermore, a "discovery message" can be either a discovery-type message or an announcement-type message. It can be sent on sidechain (SL) scheduled resources; or it can be a RACH (Random Access Channel) type message sent via sidechain or uplink (UL) unscheduled resources. It can also be sent via non-3GPP defined spectrum (e.g., Bluetooth, Wi-Fi).

[0254] Furthermore, the discovery message sent by the UE upon request may optionally include the following. Initially, the UE may send a discovery message to search for a relay or potential relay. The content of this message should be included in a slice of the request in the "NRF Secondary Relay Selection" example, and may also be included in a slice of the request in the "NF Reconfigure Relay" example. Moreover, the discovery message may include any of the following:

[0255] - A message header or message type that indicates that the requesting device is requesting another device to act as a relay for traffic originating from the requester; or

[0256] - Message header or message type, which indicates that the requester intends to discover available relay devices.

[0257] Furthermore, the discovery message may include information about the security background in which the UE is running or where the UE wishes to run, such as a slice-specific security background, encrypted credentials provided by the eNB, encrypted PLMN session key, security background identifier, ProSe group ID or service ID, and related group / service credential information.

[0258] Furthermore, the discovery message can include indications of why a relay is requested, such as low battery, being outside base station range, or poor signal to the base station, recommending a relay via NRF. It can include the received signal strength of any messages received from nearby devices, which can assist the NRF in relay selection. It can also include device power status information, such as power supply, battery powered, trunk powered, or solar powered; or current battery level information. Additionally, it can include standard fields such as the message's transmitted signal strength and UE identity information. The UE identity information can optionally be a derived or temporary ID for privacy reasons, which the NRF / CN can calculate back to the real UE ID if needed.

[0259] Furthermore, the discovery message may include distance measurement data or other types of location information, such as the speed of the mobile device (which may be absolute or relative speed) and / or header / direction information. The mobile device 110 and / or relay device may be arranged to perform distance measurements between the mobile device and the relay device. The connectivity processor 112 may be arranged to enable distance measurement and transmit the measured distance to the network for determining the location data of the mobile device and / or relay device. By receiving one or more distance measurement results between the mobile device and the relay device, the NRF can enhance its selection of the relay device. In practice, location data received from transmissions by the mobile device is not very accurate, often having a tolerance of 100 meters. Conversely, local distance measurements are much more accurate, often having a tolerance of 1 meter. Combining multiple locations of multiple mobile devices with the distances between such positioned devices can improve the accuracy of the location data.

[0260] To detect the distance between a mobile device and a relay device, a special mode can be requested on the device to measure the distance, for example by using Wi-Fi fine time measurement as specified in IEEE 802.11-2016 or by authorizing the ProSe function on both devices (as specified in [23.303] and [24.334]) using the sidechain D2D communication channel and performing distance measurement or proximity detection (e.g., via PC5 or Wi-Fi awareness ranging).

[0261] The possible content of a request message (M) with the requested network slice identifier can be as follows. When the requesting UE initiates a request message as part of the registration process, such as if it is further sent to the NRF, the message may include the source address or identifier of the mobile device, i.e., the UE itself. The request message may also include QoS requirements or a set of requested QoS, such as a preferred set and an alternative backup set. It may also contain information (e.g., signal strength) about the relay UEs in the area obtained during the original relay UE discovery process. Alternatively, this information may be included in the transmission request message (M') by the relay device or a selected relay device for indirect connection, and / or, when the information is forwarded from the UE to the core network, the information may be included in the transmission request message (M') by the base station. Alternatively, the NRF may request this information and additional relevant information from the RAN, AMF, or other network functions as described above.

[0262] When a relay device (e.g., during a discovery process or indirect connection setup) initiates a message based on information received from the requesting UE, the relay UE can send the message to the NRF to indicate that the requesting UE is looking for a relay UE and may include its own source address or identifier in the message.

[0263] The network relay entity may be configured to obtain metadata from the cellular communication system, such as received signal strength, signal quality, or distance estimation. Alternatively or additionally, the transmission request message may include metadata identifying the current connection state, such as the network connection method, quality of service (QoS) and hop count, connection stability information, and / or the frequency band being used or the frequency band supported by the relay equipment. The network relay entity (140) may be configured to determine network relay information based on the metadata.

[0264] Metadata can also be obtained from other sources within the cellular communication system (e.g., sources within the RAN or core network). For example, hop counts can be obtained from the base station, and distance estimates can come from location services within the core network. Furthermore, subscription information from the UDM can be important, for example, for assessing whether a relay UE is operated by the same MNO as a remote UE, or for assessing whether a relay UE is authorized to access a specific slice, or acts as a relay within a specific slice. UE capability information can come directly from the UE, but can also be (partially) provided by the UDM or SCEF. Since the resources of relay and remote UEs are typically scheduled by the base station, the base station is a device that knows whether relay and remote UEs can be given sufficient sidechain resources to accommodate a certain QoS request from the NRF to meet the QoS requirements of a particular network slice.

[0265] NRF can determine whether QoS requirements for a given network slice can be met. QoS refers to an important criterion used to determine which relay devices will be able to act as relays for a specific slice.

[0266] NRF can use the attributes / requirements of a specific slice to determine which relay(s) should be prioritized. For example, for an IoT slice, a fixed relay(s) or a relay(s) that are not themselves IoT devices can be prioritized.

[0267] The relay device may optionally include metadata about the message requesting the UE (e.g., RSSI, signal quality, or distance estimate) or a signal quality or distance estimate for another relay device. It may also include information identifying its current connection status, such as one or more of the following:

[0268] • Direct / indirect connection methods;

[0269] • QoS information and / or the number of hops toward the gNB;

[0270] • (Past) connection stability information;

[0271] • Cache size;

[0272] • Current number of connections;

[0273] • Information about data streams or duty cycles / sleep cycles;

[0274] • The frequency band currently being used by the relay UE, or the frequency band it supports.

[0275] The NRF can also obtain such information by connecting to the RAN / gNB or other core network function interfaces. The RAN / gNB can provide additional information, such as information about the available resources for sidechain communication between each relay UE and a remote UE. Upon receiving such information, the NRF can use it to perform decision-making processes. For example, the NRF can use the hop count, along with QoS and / or signal quality information, to determine whether a given relay UE can satisfy a UE's requested slice. For example, a relay UE with a large number of hops is not preferred if the slice provides low-latency communication. If the required latency cannot be achieved due to the hop count, the NRF can even disable the slice and indicate this to the originating UE.

[0276] Furthermore, messages destined for the NRF may optionally include the UE capabilities of the relay UE. UE capability information may include:

[0277] • Information regarding relay functionality may include, for example, specific constraint information regarding the UE's ability to perform relaying;

[0278] • Radio Rx / Tx speed category, or 3GPP UE category / level;

[0279] • The radio frequency bands used or supported;

[0280] • Processor performance category and / or current load;

[0281] Mobility information: fixed (e.g., roadside V2X nodes) or potentially mobile (e.g., mobile phones or wearable sensors). It may also include location / header information (e.g., in the case of V2X).

[0282] • Power supply, battery level, or expected equipment operating duration information (which can be used to make optimal relay decisions);

[0283] • Identifiers for specific relay-related security contexts already supported by the device;

[0284] • Preferences for relaying certain application types, application IDs, or group IDs;

[0285] • Support for IP traffic and certain packet sizes;

[0286] • Support for certain services (e.g., location support);

[0287] • The types of trunks the trunk equipment can support, such as Layer 2 (at the PDCP level) trunks or Layer 3 (at the IP level) trunks. The NRF can use this capability information to determine the optimal choice for trunking the UE given the attributes / requirements of one or more specific slices requested. For example:

[0288] • For IoT slicing: Non-mobile trunk-powered nodes with ample resources and high-speed connectivity are preferred as relay UEs over battery-powered mobile low-resource IoT sensors;

[0289] • For IoT slicing: Using a relay UE that is not itself an IoT device may be a better option than a direct network connection for IoT devices, in order to save battery power;

[0290] • For V2X slices: Using a relay UE that is itself in the V2X slice may be preferred;

[0291] For V2X slices: Using a relay UE that is moving in the same direction as the requesting UE may be preferred. This is true even if the relay UE is not in the same V2X slice;

[0292] • The NRF can use information about the frequency band currently used by the relay UE during the selection process. When the NRF obtains information about one or more frequency bands currently used by the relay UE (e.g., information from messages received from the relay UE or from the gNB or otherwise), the NRF can use this information during the selection process to determine which relay UE cannot serve a particular slice. This occurs, for example, when a slice is associated with the use of one or more specific dedicated frequency bands, such as a “V2X” slice using a reserved V2X band. Some candidate relay UEs may not currently be operating in that band, and therefore these candidate relay UEs may not be suitable for performing any relay role for that slice. The NRF can exclude these candidate relay UEs from the selection process, or it can still include them, but as candidates with low preference. As a backup solution, such relay UEs can serve the “V2X” slice via a different frequency band. The same applies to NB-IoT / LTE-M devices, which can operate in, for example, guard bands that may not be supported by the mobile phones that might be candidate relay UEs.

[0293] The requesting UE can indicate a security background or key for subsequent attachment to a relay UE. The security background for relaying can be linked to a security background for a slice. In ProSe, the remote UE and the relay UE need to have a shared security background (i.e., key material) to be able to establish a D2D connection for relay purposes. In existing specifications, security backgrounds are pre-configured at the application level, which limits the usefulness of relay functionality to devices with only the same application background. In the enhancement, arbitrary and unknown UEs can be supported as relays. The following can be applied.

[0294] • The requesting UE may indicate its supported security background or key C in its discovery message. This could be a slice-specific security background, or more generally a security background valid for multiple slices, or, for example, a security background for a (third-party) defined group of devices (e.g., all medical devices within a hospital or a ProSe application group). The background information may also include a random ID or partial key that can be later used by the NRF / CN to derive the full key to be used.

[0295] • A relay UE can send information about security background C to the NRF, enabling the NRF to retrieve information related to that security background from CN.

[0296] • NRF may include information based on the above (e.g., key materials or credentials) in the response message sent back to the relay UE.

[0297] • The relay UE can then use security information to accept a secure relay request from the requesting UE and execute the secure relay request in a secure manner, such as preventing eavesdropping, replay, packet injection, etc. during the relay establishment protocol.

[0298] Note that by using the random ID or partial key mentioned above, the potential impact of malicious relay UEs storing and sharing security materials is reduced, as the security materials will only be valid for a temporary period.

[0299] The CN can detect UEs that have visited the OoC. Subsequently, the CN can request one or more UEs that it calculates are likely near the OoC-UE to begin broadcasting a "Relay Available" message, thereby assisting the OoC-UE in quickly discovering suitable relay UEs. In this scenario, the CN can involve the NRF to determine which relay UEs are best suited to become available in this manner based on the OoC-UE's previous slice information.

[0300] Furthermore, the NRF can authorize and instruct selected relay UE(s) to activate their relay functionality, even if they are not yet acting as relays. This ensures a quick connection later with the selected relay UE, as it has been activated and has network permission / authorization to act as a relay UE. Moreover, after the NRF has determined the optimal relay device for the requesting UE, it can inform the gNB of the requesting UE's decision and the anticipated slice requirements. This allows the gNB to begin scheduling appropriate resources to support the requesting UE. This has the benefit that appropriate resources have already been prepared and scheduled at the gNB for the requesting UE's operation in its desired slice(s), even before the UE is fully attached to the relay UE and CN. This reduces any temporary QoS / bandwidth issues during relay transitions or transitions from direct network connection to a relay connection.

[0301] Furthermore, if one of the requested slices is an "emergency" type slice, this can be given priority in the selection process, or it can be subject to special treatment from potential candidate relay UEs, such as automatically enabling them to act as relay UEs and allowing the setting of emergency connections to any discovered candidate relay UEs. Alternatively, emergency slices can be automatically included in the discovery response generated by candidate relay UEs. This can also be done for relay UEs participating in slices with known restricted use (e.g., public safety). These are unlikely to act as relay UEs against any other device, and therefore public safety slices can be automatically included in their responses, and there may not even be a contact NF in the process.

[0302] Furthermore, discovery messages or "relay request" messages can include an identifier indicating a class of devices or applications associated with the UE. For example, medical devices could be a separate category as well as emergency service devices. An application category could be "IoT applications for local government." This identifier helps the UE decide whether it will act as a relay UE for a device indicating that specific identifier. This allows potential relay devices to configure the purposes they wish to assist in their relay role; for example, a medical application might be considered more important to the user than a purely commercial application. Moreover, not all relay devices are acceptable for relaying medical or security-related data (e.g., to comply with regulatory rules for medical data processing and transport). To prevent fraud (identifier deception), cryptographic certificates, signatures, or proof elements can be added to the communication, enabling the UE to prove it is part of the claimed application or device category.

[0303] The following scenario may occur: the UE moves out of range but can still receive synchronization information and / or other broadcast messages from the eNB (albeit weakly), but is unable to send them back due to distance, signal congestion, lack of battery power, or transmitter output power; that is, the eNB will not listen to the device. In such a case, the eNB can assume that the UE may still be listening and proactively send certain instructions to the UE. For example, the network can instruct such a UE to begin requesting a relay, possibly including channel information and timing information. Alternatively, it can send the UE information about the optimal time to send a "relay request," for example, as part of a discovery message.

[0304] If a UE has just lost contact with the eNB, it can use its (previously) synchronization with the base station as the basis for its local clock, or alternatively, detect synchronization signals from devices operating in discovery mode. If contact has just been lost, the eNB can provide synchronization information to nearby candidate relay UEs, including information from when the UE was last seen, and / or possibly estimates of clock drift and / or timing margins to adjust its listening time window, thereby ensuring the highest probability of hearing the expected transmission from the UE. Alternatively, candidate relay devices can receive information from the eNB about previously scheduled resources for the UE on a sidechain or uplink channel. The relay device can use this information to listen for the "relay request" message at the correct time / frequency.

[0305] If a UE is already connected to a slice via a relay connection and detects that the bandwidth / QoS available for its communication is insufficient based on the requirements / expectations of the slice it is currently operating in, it can initiate a request to one of the other candidate relay UEs it has previously discovered based on preference information indicated by the NRF. Alternatively, it can initiate a new discovery process or send a request directly to the NRF to provide (up-to-date) information on which other relay UE should be selected to reach the slice's QoS attributes. In this case, the NRF can be involved in initiating a discovery process between the relay UE and the gNB in ​​a specific geographic area near the UE.

[0306] Similar to the above, the eNB / network can detect insufficient available bandwidth or QoS and proactively initiate a process to find a suitable relay. First, it instructs the UE to send a "request relay" message, and then instructs it to connect to a specific relay or select a relay from a set of relays.

[0307] Note that for this effort, users or operators of UEs who provide relay functionality to others may be rewarded or compensated. Compensation can take various forms, such as payments, adding usage credits to their cellular subscription bundles, or special service benefits (e.g., the ability to utilize other relay equipment). It may be necessary to extend some charging functionality for this. This could include special charging functionality for UEs acting as relays in a slice, which may or may not have a subscription operating in, for example, a private slice.

[0308] In a further detailed example, the mobile network defines a set of Connection Background Identifiers (CCIs), where each CCI is mapped to a combination of PDU session parameters [23.501] (e.g., PLMN ID (+NID / CAG ID), S-NSSAI, DNN, PDU session type, etc.) and some possible additional parameters (e.g., the group ID, QoS requirements, frequency, security background, etc., that a remote UE might wish to use to connect to the core network via a relay UE). Some of these parameters may impose restrictions on whether a relay UE is authorized and can be used as a relay for remote UEs.

[0309] Because much of the aforementioned information is privacy-sensitive and could lead to the tracking of remote UEs and exposure of operator deployment information (e.g., which slices / NPNs the core network supports), it is preferable to store this information in the core network and use it as much as possible within the core network, and not to provide this information to relay UEs, which can be considered untrusted end-user equipment. Storing, using, and processing this information within the core network also makes it possible to handle dynamic aspects of slice usage in order to, for example, meet the QoS requirements defined by the Service Level Agreement for network slices. Even if the remote UE is also an untrusted end-user equipment, it may be necessary to provide some of this information to the remote UE because the remote UE may be out of coverage when it needs to discover and utilize the relay UE to reach the network. However, it is not a problem for remote UEs to expose some of this information, as it is possible to provide it to the remote UE using only the PDU session parameters enabled by the remote UE's subscription. This is different for relay UEs, as they can potentially act as relays for a diverse set of remote UEs (which may even include inbound roaming remote UEs). The CCI that a remote UE can use may only be known to the remote UE's operator, and therefore the relay UE may not know the CCI when it is discovered, but the relay UE's network operator (i.e., the access network) can retrieve the CCI from the remote UE's home operator.

[0310] Furthermore, given the potential number of slices and NPNs that 5GC can support, the number of possible combinations of the above parameters could be potentially very high and could require a considerable number of CCIs.

[0311] To minimize the number of CCIs provided to relay UEs while ensuring that remote UEs using potentially unknown or outdated CCIs can still discover the relay UE and request network access via it, one solution is to use one or more generic CCIs. The CCI is bound to a specific set of PDU session parameters, and the relay UE may not be aware of this CCI. The generic CCI is an identifier (e.g., a predefined value that may have a longer lifespan and may be shared across different PLMNs) that can be used as a "wildcard" to request access to a set of PDU session parameters for one or more PLMNs. Generic CCI values ​​can be mapped to or indicate wildcard values ​​(e.g., asterisks) or other regular expressions. Generic CCI values ​​can be associated with an initial security context through which both the remote and relay UEs can demonstrate their authorization to issue discovery or connection setup requests, enabling the remote UE to request access to a specific slice / NPN and / or use a specific set of PDU session parameters via the relay UE. Generic CCIs can also be associated with a default network slice for one or more PLMNs. Alternatively, a generic CCI can be associated with an application context or (V2X) application ID [23.287]. Advantageously, at least one generic CCI is provided in both the remote UE and the relay UE. Using a generic CCI also makes it easier to support Model A discovery (i.e., broadcasting "I'm here"), as these messages can remain small and typically do not contain an expanded list of CCIs (which may need to be changed periodically). It also makes discovery easier by using a single identifier in the request message (instead of having to include a potentially large list of identifiers) to discover all available options available to the remote UE. A generic CCI can also be used as a trigger in both the remote and relay UEs to include a specific CCI as part of a discovery message or connection request. Alternatively, separate messages can be defined to send the generic CCI, but the benefit of using a generic CCI is the ability to reuse the same discovery and PC5 connection setup messages.

[0312] The following description and Figure 7 The diagram illustrates the detailed process.

[0313] Step 0 Before relay UE discovery can be performed, the following information should be provided in advance in both the remote UE and the relay UE, for example, by using a UE configuration update procedure [23.501] (e.g., initiated from the AMF or PCF):

[0314] For remote UEs:

[0315] - The remote UE is authorized to use one or more CCIs, including a flag indicating each CCI if it is a generic CCI or a specific CCI.

[0316] - The mapping between each CCI authorized for use by the remote UE, and the default destination Layer 2 ID (one or more) for the initial signaling used to establish the PC5 unicast connection [23.287].

[0317] - The mapping between each set of CCI and PDU session parameter values ​​may, among other things, include one or more of the following:

[0318] -PLMN ID

[0319] -NID / CAG ID

[0320] -S-NSSAI

[0321] -DNN

[0322] -PDU Session Type

[0323] For general CCI, this set can be empty or a small subset of parameters, can indicate wildcard values ​​(e.g., asterisks, regular expressions), or can contain special predefined values ​​to refer to, for example, the default slice.

[0324] - (Optional) Mapping between each CCI and the security context (e.g., a set of credentials).

[0325] - A strategy to restrict the PDU session of a remote UE to the PDU session parameter value corresponding to the requested CCI.

[0326] For relay UEs:

[0327] - The relay UE is authorized to expose and re-act on one or more CCIs during discovery, including a flag indicating each CCI, depending on whether it is a general CCI or a specific CCI. This should be a small subset of all CCIs, and the relay UE may be able to process and configure this small subset after consulting the relay UE's AMF to reduce the exposure of potentially privacy-sensitive information.

[0328] - The mapping between each CCI in the CCI that the relay UE is authorized to expose and re-act on during discovery and the default destination Layer 2 ID (one or more) used for initial signaling to establish a PC5 unicast connection [23.287].

[0329] - (Optional) Mapping between each CCI and the security context (e.g., a set of credentials).

[0330] - (Optional) Default destination Layer 2 ID for broadcast communication via PC5 [23.287].

[0331] In addition, the following information should be provided to the AMF of the relay UE (either in advance or when the AMF receives a transmission request message (M) and is able to consult the relevant network function (e.g., PCF, NSSF, UDM)):

[0332] - Relay UEs may be able to process and obtain an expanded list of CCIs authorized for them, including flags indicating each CCI, whether it is a general CCI or a specific CCI. Since the list of CCIs for the AMF may not always be updated simultaneously with remote UEs (and relay UEs) (which may be out of coverage for a period of time), the AMF should also retain the history of old CCI values.

[0333] - The mapping between each set of CCI and PDU session parameter values ​​may, among other things, include one or more of the following:

[0334] -PLMN ID

[0335] -NID / CAG ID

[0336] -S-NSSAI

[0337] -DNN

[0338] -PDU Session Type

[0339] For general CCI, this set can be empty or a small subset of parameters, can indicate wildcard values ​​(e.g., asterisks, regular expressions), or can contain special predefined values ​​to refer to, for example, the default slice.

[0340] The PCF in the HPLMN of a UE that needs to be provided as a remote UE or a relay UE can interact with the PCF of other PLMNs (e.g., PLMNs that may be accessed by roaming partners) to perform CCI allocation and management.

[0341] Step 1: A relay UE can periodically broadcast one or more CCIs, which can be configured by the relay UE using (V2X) broadcast messages via PC5. To keep the broadcast messages small, the set of CCIs is preferably kept very small and preferably includes common CCIs.

[0342] Step 2:A remote UE can initiate discovery to find a relay UE by sending a direct communication request via PC5 as specified in TS 23.287 or a similar message with a requested CCI used as a (V2X) service / application identifier. If the requested CCI is a generic CCI, the direct communication request may include additional CCIs indicating the set of PDU parameters that the remote UE wishes to use. The direct communication request uses a default destination Layer 2 ID configured for the requested CCI (or, if the Layer 2 ID of the target relay UE is known), and in the case of V2X, is typically sent via a sidechain shared broadcast / multicast channel and can be received by multiple relay UEs. This direct communication request message corresponds to the request message (M) referenced elsewhere in this document.

[0343] Step 3: One or more relay UEs can receive direct communication requests via PC5. If the CCI in the direct communication request matches a CCI known to the relay UE, the relay UE sends a registration request [23.501], service request [23.501], or dedicated request message to its serving AMF (which is in both the CM_IDEL and CM_CONNECTED states). The registration / service / dedicated request message includes the requested CCI, and if the relay UE has already received additional CCIs in the direct communication request in step 2, those additional CCIs will be included in the registration / service / dedicated request message. Preferably, additional CCIs are included instead of the generic CCI. The relay UE can (re)use an existing PDU session that has been pre-established to connect to the relay UE's AMF to send the registration / service / dedicated request message. This registration / service / dedicated request message corresponds to the transport request message (M') as used in other parts of this document.

[0344] Step 4:The serving AMF of the relay UE will receive a transmission request message (M') and verify whether the relay UE is authorized to act as a relay UE for a given CCI (and in particular, the associated network slice (indicated by S-NSSAI) and / or (indicated by PLMN ID+NID / CAG ID) in the mapping table between CCI and PDU session parameters), and also verify whether the relay UE can meet the requirements associated with the PDU parameters of the CCI (in particular, if it can and is authorized to act as a relay UE for the associated network slice (indicated by S-NSSAI) and / or (indicated by PLMN ID+NID / CAG ID) in the mapping table), and whether it can meet the QoS requirements of the specific slice / NPN. To perform this verification, the AMF can request information from other network functions, such as NSSF (regarding allowed network slices), RAN (regarding the relay UE's capabilities and load, congestion, and signal quality), SMF (regarding ongoing PDU sessions and their QoS), UDM (regarding subscription-related information), PCF (regarding policy information, PDU session configuration, and QoS-related information), NWDAF (regarding combined measurement information, analytics data, and historical data), ProSe functions, application functions, etc. If the relay UE sends a general CCI to the AMF and does not provide additional values ​​in the transmission request message (M'), the AMF will determine whether the relay UE is capable of providing services for each set of combinations of PDU session parameters. If the CCI value is not part of the mapping to PDU session parameters in the AMF, the AMF can search its previous CCI value history or contact the AMF (or database) of other network operators' 5G networks.

[0345] Step 5: If it is determined that the relay UE is capable of acting as a relay for a given CCI and its associated network slice(s) and / or NPN(s) and other PDU session parameters, the AMF will send an RRC connection reconfiguration message to the relay UE and / or may send a UE configuration update and / or a dedicated message to the relay UE. This connection reconfiguration / UE configuration update / dedicated message may include information for the following operations:

[0346] - Reconfigure existing PDU sessions between the relay device and the network to accommodate relay network traffic for a specific slice (e.g., change the DNN to connect to a different user plane function);

[0347] - Update the UE configuration (which may include different S-NSSAI information, different policy information, different credentials) and issue a reconnection (which may, for example, cause the selection of different Access and Mobility Management Functions (AMF) for network slicing services).

[0348] The connection reconfiguration / UE configuration update / dedicated message may include instructions for initiating additional PDU sessions with the network if the relay UE is already serving other remote UEs. The connection reconfiguration / UE configuration update / dedicated message may also include instructions for connecting to different PLMNs / NPNs, and may include instructions for radio access to the network, such as instructions for sending an updated list of allowed NSSAI values ​​for the relay UE and / or remote UEs, or instructions for residing on a specific unit to access an NPN (identified by the CAG ID in the case of an NPN operating in a public network, or by the NID in the case of a standalone NPN (along with PLMN ID information)).

[0349] Specifically, the AMF can configure the relay device's PDU session to connect (within the radio access network, for example, based on NGAP messages from the AMF to the radio access network [38.413]) to a cellular base station configured with CAG ID / NID, where the CAG ID / NID is part of the list of allowed CAG / NIDs in the mobility restriction information and / or is configured as a CAG element that can broadcast the CAG ID / NID within a system information block, and / or the radio access network is configured (for example, within NGAP messages to the AMF [38.413]) to report it to the core network. Where the relay device is directly connected to a cellular base station or the mobile device is indirectly connected to a cellular base station (which is configured as a CAG element and / or where the CAG ID / NID is part of the list of allowed CAG / NIDs in the mobility restriction information) via the relay device, the CAG ID / NID refers to a non-public network.

[0350] If it is determined that a relay UE cannot act as a relay for a given CCI and its associated network slice(s) and / or NPN(s) and other PDU session parameters, the AMF will include a "Relay Reject" error code for the requested CCI as part of the Connection Reconfiguration / UE Configuration Update / Dedicated Message. This Connection Reconfiguration / UE Configuration Update / Dedicated Message may also include information about other CCIs (e.g., a list of CCIs for possible combinations of PDU session parameters that the relay UE can only relay with if a generic CCI is sent to the AMF) and information about other nearby relay UEs. This Connection Reconfiguration / UE Configuration Update / Dedicated Message corresponds to the Transport Response Message (N') as used in other sections of this document.

[0351] Step 6:If the serving AMF of the relay UE does not reject the relay for the given CCI in step 4 / 5, the relay UE executes the PC5 unicast link security procedure [23.287] and sends a direct communication accept message [23.287] to the remote UE, which includes the given CCI as a (V2X) service / application identifier. The direct communication accept message may include some QoS information, IP configuration information (e.g., for a Layer 3 relay), and some additional information about the relay. The message may also include information about other CCIs and information about other nearby relay UEs. If the serving AMF of the relay UE rejects the relay for the given CCI in step 4 / 5, the relay UE may either not send any response to the remote UE or may send a direct communication reject message [24.587]. This can be used to send other CCIs and information about other nearby relay UEs to the remote UE. This direct communication accept / reject message corresponds to the response message (N) used in other parts of this document.

[0352] Step 7: After successfully completing steps 2-6, the remote UE can initiate indirect communication with the core network using the PC5 connection established between the remote UE and the relay UE via the direct communication request / accept procedure. In this case, the relay UE relays traffic received from the remote UE to the network. In the case of Layer 2 relay (i.e., forwarding PDCP messages), the remote UE can initiate / restore a PDU session by sending a registration / service request to the network. This requires limiting the PDU parameters used (e.g., during initial registration) to the configured PDU parameters associated with the CCI received in the direct communication accept message. In the case of Layer 3 relay (i.e., forwarding IP packets), the remote UE receives IP address information from the relay UE, which can be used to forward IP traffic to the relay UE, and then forwards the IP traffic to the correct destination based on the configured PDU parameters associated with the CCI. If the remote UE wants / needs to establish a PDU session using different PDU parameters (e.g., different S-NSSAI or different CAG ID / NID), the remote UE should repeat steps 2-7. In the case of Layer 2 relay, each time a remote UE sets up a new PDU session, the AMF should verify that the PDU parameters used correspond to the CCI received in step 4. If not, the AMF may reject the PDU session or send an RRC reconfiguration or UE configuration update message to the remote UE via an indirect connection.

[0353] Figure 6aA computer-readable medium 1000 is shown having a writable component 1010 including a computer program 1020, which includes instructions for causing a processor system to perform one or more of the methods and processes described above in the system with reference to Figures 1-4. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical label or by means of magnetization of the computer-readable medium 1000. However, any other suitable embodiments are conceivable. Furthermore, it will be understood that although the computer-readable medium 1000 is shown herein as an optical disc, the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state storage, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to perform one of the methods described above.

[0354] Figure 6b A schematic representation of a processor system 1100 according to an embodiment of the device or method described with reference to Figures 1-4 is shown. The processor system may include circuitry 1110, such as one or more integrated circuits. The architecture of circuitry 1110 is schematically shown in the figures. Circuitry 1110 includes a processing unit 1120, such as a CPU, for running computer program components to perform the methods according to the embodiments and / or implement modules or units thereof. Circuitry 1110 includes a memory 1122 for storing programming code, data, etc. A portion of memory 1122 may be read-only. A portion of memory 1122 may be non-volatile. Circuitry 1110 may include a communication element 1126, such as an antenna, transceiver, connector, or both. Circuitry 1110 may include an application-specific integrated circuit 1124 for performing some or all of the processing defined in the method. Processor 1120, memory 1122, application-specific IC 1124, and communication element 1126 may be interconnected with each other via interconnection 1130 (e.g., a bus). The processor system 1110 can be arranged for wired and / or wireless communication using connectors and / or antennas, respectively.

[0355] In an embodiment, there exists a system comprising a device UE0 that operates as a cellular user equipment and is also capable of operating as a remote UE, and a device UE1 that operates as a cellular user equipment and is also capable of relaying network traffic from UE0 to / from a cellular communication system CCS capable of relaying operations (typically via a logical function called a Network Relay Function (NRF), which can be a separate network function in the core network or radio access network of the CCS, or can be combined / integrated with any core network function (such as AMF, PCF, SMF...), thereby:

[0356] a. Device UE0 sends a message to relay device UE1, which includes (optionally encrypted) relay service code RSC1. The relay service code identifies or is associated with a set of PDU session-related attributes (such as PLMN ID (+NID / CAG ID), (temporary / encrypted) S-NSSAI, (temporary / encrypted) DNN, PDU session type, group ID, QoS requirements (such as 5QI), frequency, security background, etc.), and also includes (e.g. as part of a security envelope V) UE0's (optionally encrypted) identifier and UE1's (optionally encrypted) identifier.

[0357] b. Relay device UE1 sends a message to the cellular communication system CCS containing one or more of RSC1 and optionally V or (encrypted) identifiers received from device UE0 (i.e., relay service code, UE0's identifier, UE1's identifier).

[0358] c. Relay device UE1 receives a message containing encrypted relay service code RSC2 from CCS, whereby RSC2 is encrypted using credentials shared between device UE0 and CCS but not with device UE1, thereby preferably selecting a different relay service code (RSC2') from the set of alternative relay service codes available in the relay device.

[0359] d. Relay device UE1 sends a message containing the encrypted relay service code RSC2 to device UE0.

[0360] e. Device UE0 uses RSC2 instead of RSC1 in subsequent messages for discovering and / or establishing connections to relay devices.

[0361] The benefit of this is that eavesdroppers (including relay device UE1 and other relay and remote devices) cannot use RSC1 to track device UE0 after it has disconnected, even though the discovery and connection setup messages themselves are not encrypted and unauthenticated, and the relay service code is sent in plaintext.

[0362] It also does this efficiently because it only needs to update the RSC already used by the remote UE (i.e., device UE0), rather than all RSC values ​​of all other remote UEs and / or relay UEs. And it can also work if the remote UE is outside the coverage area of ​​the network base station. Moreover, advantageously, the process can be combined with a process that verifies authorization granted by the network to the remote UE and relay UE for establishing a relay connection for a specific relay service code and / or for setting up a PDU session using PDU session parameters associated with the relay service code, and / or can be combined with a process that requests a security key from the network for setting up such a relay connection, and / or can be combined with (e.g., in the case of Layer 3 relay) a process in which relay device UE1 obtains or is provided with a set of privacy-sensitive PDU session-related parameters (e.g., slice identifier / NSAI, DNN) associated with RSC1 for setting up a relay connection to the network, thus achieving faster and more secure connection establishment.

[0363] The following description and Figure 8 The diagram illustrates the detailed process.

[0364] Step 0 Device UE0 (i.e., remote UE) is provided by CCS, particularly the CCS's Network Relay Function (NRF), with a set of relay service codes that identify one or more PDU session-related parameters (e.g., S-NSSAI, DNN, etc.) or associated with them. This set may be limited to relay service codes associated with PDU session parameters that UE0 can use based on subscription information in the CCS. Relay device UE1 (and other relay UEs) is provided with a set of relay service codes that UE1 is allowed to use / respond to during discovery, but may or may not be given corresponding associated PDU session-related parameter information. Preferably, in these initial steps, several relay service codes provided to relay device UE1 have not yet been assigned to any remote UE, and / or have not yet been assigned (in the network or to any remote UE or other relay UE) to the set of PDU session parameters, and are therefore considered as spare (i.e., additional / unassigned) relay service codes. During step 0, the relay UE may also provide a policy describing the connection types it supports, as well as long-term public / private key pairs or other security materials (e.g., as described in steps 2 and 5 below), or a temporary ID or randomization function, to generate a temporary ID that the remote UE (or relay UE) should use in subsequent messages used to set up a relay connection via the relay UE. Advantageously, the policy and / or PDU session parameters can be signed by the core network along with the associated long-term public key.

[0365] All other data (relay service codes, PDU session parameters, policies, security materials) can also be signed by the core network.

[0366] Step 1 This is an optional step in which device UE0 and relay device UE1 can (via PC5) exchange discovery information, such as their supported relay service codes and relay device identity information (as described in the following steps), enabling device UE0 to select relay device UE1 as the relay device that device UE0 (the remote UE) wants to use to send messages to / receive messages from the CCS. The discovery exchange can use the relay service code RSC1. For security and privacy reasons, discovery information such as the relay service code should be protected (e.g., by encrypting it using, for example, a pre-configured discovery key, and preferably, it can only be decrypted by a relay device that has been authorized to support the relay service code requested by the remote UE). For further privacy protection, including avoiding tracking of the remote UE during discovery from those UEs to the network relay, the remote UE should frequently change its Layer 2 identifier (e.g., "Model B") for discovery request messages, preferably using a different Layer 2 identifier for each subsequent request message. The remote UE should also pause randomly between sending two subsequent messages (e.g., by skipping a random number of allocation / scheduling resources for sidelink discovery) to avoid any pattern detection, and if possible, exchange other relay service codes that the remote UE supports, or request them by using pseudo / random relay service codes that the remote UE does not support, or by frequently changing keys to encrypt / integrity protect the payload of the discovery message.

[0367] In the discovery message, the relay device may send a random number and its public key. Additionally, the relay device may send its policy and / or what connection types it supports and / or what PDU session parameter values ​​or combinations it can accept. The relay device may include a signature to verify the authenticity of the sent information. For efficiency, this can also be sent to the remote UE only upon request.

[0368] The remote UE can verify the received information (e.g., policy and associated public key) in previous steps (e.g., by verifying that it has been properly signed by the core network) and infer that the relay UE supports its request (based on the received policy, relay service code, PDU session parameters / connection type). The remote UE can then proceed to the following steps and can use the received public key to encrypt the PDU parameters or the relay service code it prefers to request from the relay UE.

[0369] Step 2: Device UE0 sends a request message M (e.g., a direct communication request message or discovery request via PC5), which includes the relay service code RSC1, and may also include a payload / envelope V containing a Layer 2 identifier or other identifier received from relay device UE1 during step 1 or otherwise (e.g., GPSI / TMSI / IMSI / SUPI / SUCI / GUTI or a signature / hash / security credential associated with relay device UE2 or indicating the identity of relay device UE1) (e.g., an identifier received from / generated by an application running on device UE0, or a temporary ID received in step 0).

[0370] The payload / envelope V may also contain a (unique) identifier for UE0 (e.g., GPSI / TMSI / IMSI / SUPI / SUCI / GUTI, or a temporary ID received in step 0). The relay service code and / or payload / envelope V may be encrypted using a key derived from the USIM of UE0. Alternatively, the relay service code, the identifiers of relay device UE1 and device UE0 may be individually encrypted and included as individual parameters / fields of message M, or combined before being encrypted and included in message M (e.g., some bits of UE0's identifier are concatenated with some bits of UE1's identifier, or hashes of each of these identifiers are combined). Note that SUCI stands for Subscription Hidden Identifier (SUCI) and is a privacy-protected identifier containing a hidden SUPI. The UE generates the SUCI using an ECIES-based protection scheme that has a public key securely provided to the home network of the USIM during USIM registration, and therefore cannot be decrypted by relay device UE1 to retrieve the SUPI because it does not have the corresponding private key for decryption. Even though the SUCI value also includes a plaintext home network identifier (e.g., mobile country code / mobile network code), it is considered an encrypted identifier in the context of this description; that is, the encryption scheme does not necessarily need to protect all bits of the identifier. The identifier can also be sent unencrypted in the same message, whereby the message can include a message authentication code / hash / random number / digital signature (e.g., generated using a cryptographic hash function such as HMAC) for integrity protection, which may need to be forwarded to the network for further verification. It should be noted that the message authentication code can also overlay the encrypted value and the identifier to ensure that the encrypted value and the identifier have not been tampered with. All these different alternatives combining information from UE0 and UE1 represent an indicator of a protected / secure signature, i.e., that device UE0, acting as the remote UE, has selected relay device UE1 to set up the indirect / relay connection between UE0 and the CCS. The encryption method or (cryptographic) hash function may employ additional values ​​as a seed, such as a counter, to prevent replay attacks or other information received or derived from earlier messages received from relay device UE1 (e.g., PHY level information, such as the time-of-flight of the discovery message received in step 1). These values ​​can also be added to the (encrypted) payload / envelope.The key used for encryption can be a key derived from the USIM of UE0, a public key received from the relay UE during (restricted) discovery (e.g., provided by the CCS or the relay UE) or key material, or a pre-shared key with some key material to be used during such a process (e.g., the remote UE may have pre-provided it (e.g., along with other information in step 0)) (e.g., the root relay connection key, such as the ProSe Relay User Key (PRUK) as defined in TS 33.303 or a long-term credential in TS 33.536 that forms the root of the security of the PC5 unicast link), thus allowing the use of different key material depending on whether the remote UE is within or outside the coverage area of ​​the gNB, or with some key material used by a particular relay UE or in a particular tracking area). The key used for encryption can also be the same key as the key identified by the home network public key identifier of the remote UE's SUCI.

[0371] By combining UE0's (encrypted) identifier (e.g., SUCI / 5G-GUTI) with the (encrypted) identifier of UE1, as selected by UE0 (e.g., combined in a secure envelope and / or by including a message authentication code as previously described), it can be ensured that only the relay UE selected by UE0 can properly participate in the process (i.e., it indicates that the device UE0 acting as the remote UE has selected a protected / securely signed indicator for the relay device UE1 used to set up the indirect / relay connection between UE0 and CCS), and it can prevent malicious UEs from tracking UE0 based on their knowledge of the relay service code that they may acquire by listening to traffic, prevent malicious UEs from manipulating / replaying / interrupting the process, and prevent malicious UEs from potentially gaining access to privacy-sensitive information about UE0 or UE1. This even works if the message itself is not encrypted and unauthenticated, and the relay service code is sent in plaintext.

[0372] The request message M can be received by multiple relay devices. For additional privacy protection, the remote UE should select a different Layer 2 ID for the direct communication request from the Layer 2 IDs used in the previous Model B discovery request message (e.g., by selecting a new random source Layer 2 IS). In practice, preferably, device UE0 should also use a different Layer 2 identifier each time it sends a request message (M), or at least one different from the previous request message (M).

[0373] Step 3Upon receiving request message M, relay device UE1 sends message N (e.g., service request, registration request, PDU session establishment request, relay request report, or other RRC or NAS message, or by forwarding a direct connection request) to the cellular communication system CCS. This message, also described as a transmission request message, contains one or more of RSC1 and V, or, in step 2, the encrypted identifier received from device UE0 in message M (as is or after decryption / re-encryption). Message N may also include a message authentication code received from device UE0. Furthermore, UE1 may verify the presence of its random number (e.g., if it was sent to UE0 in step 1) to prevent replay attacks. Alternatively or additionally, the relay UE may limit the number of messages N generated by the incoming message M toward the CCS (e.g., based on a policy provided by the PCF that allows setting such a limit, possibly per RSC).

[0374] Step 4 Upon receiving a message N containing one or more of RSC1 and V or an encrypted identifier, the CCS, particularly the NRF (e.g., using core network functions such as Policy and Control Functions (PCF) and / or Direct Discovery Name Management Functions (DDNMF), determines that RSC2 should be used next instead of RSC1. This new trunk service code RSC2 can be considered an alias of the original RSC1, which can be used in place of the original value RSC1, but it is still associated with, for example, the same PDU session parameters and authorization policies. Preferably, the trunk service code RSC2 is selected from a set of alternative trunk service codes already stored on trunk device UE1. The advantage of doing so is that only UE0 needs to be updated, not trunk device UE1 or any other trunk device or remote UE device. Once these devices are within coverage and connected to the network, for example, periodically or after all alternative trunk service codes have been used to update remote UEs using the procedures defined herein, these devices can later be updated using the regular PCF or DDNMF provisioning procedures. Preferably, the backup relay service code has not yet been assigned to the set of PDU session parameters, or has been assigned to the default, general, or pseudo PDU session parameters.

[0375] The CCS (e.g., using core network functions such as AMF along with Authentication Server Function (AUSF), Unified Data Management (UDM), and ProSe Key Management Function (PKMF)) can decrypt the V or encrypted identifier and securely determine that the message N received from relay device UE1 in step 3 is associated with UE0 and relay device UE2. To this end, the CCS can verify the integrity or authenticity of the contents of the secure envelope V and / or message N, and / or associate the decrypted identifier with other identity information about device UE0 and relay device UE1 already stored by the CCS. In other words, it can verify that the protected / securely signed indicator (originating from UE0 via message M) or its different representations (e.g., if relay device UE1 is allowed to re-encrypt a portion of the original indicator from UE0, or is allowed to decrypt the encrypted identifier of UE1 and replace it with another secure representation of device UE1's identity) indeed proves that the corresponding relay device UE1 was selected by the remote UE (i.e., device UE0).

[0376] This step can also be combined with the step of verifying authorization granted by the network to the remote UE and the relay UE, for setting up a relay connection for a specific relay service code and / or for setting up a PDU session using PDU session parameters associated with the relay service code, and / or can be combined with a process of requesting a security key for setting up such a relay connection from the network. For this purpose, the exchanged messages and / or the contents of messages N and N' can be combined with messages used in the authorization / relay security setup process (e.g., message N can be a NAS relay authorization request / key request message or a similar message, and / or the corresponding message can be expanded with fields to carry one or more of the encrypted relay service code or encrypted identifier received from device UE0, and message N' can be a NAS relay authorization response / key response message or a similar message and / or the corresponding message can be expanded with fields to carry the decrypted relay service code or one or more decryption identifiers and the (encrypted) new relay service code RSC2). To determine the value of RSC2 (e.g., selecting from a set of standby relay service codes or a new (i.e., previously unused or currently unassigned) relay service code), the CCS can manage a set of tables that keep track of which relay service codes have been used by which remote UE and / or which PDU session information has been exposed to one or more relay UEs, and / or which relay service codes are available in one or more relay UEs or remote UEs (e.g., as standby relay service codes). The CCS can prevent replay attacks by not accepting the same message N twice (within a specific time frame).

[0377] Step 5The CCS sends a response message N' (e.g., a service request response, RRC connection reconfiguration, UE configuration update, relay request response / acceptance, or other RRC or NAS message) to the relay device UE1. Message N' contains RSC2, which is encrypted using a known key, or for which a decryption key can be derived by UE0 instead of the relay device UE2. Examples of such a decryption key may include a key based on UE0's USIM credentials (e.g., encrypted by the latest remote UE's Kausf - see [TS33.501]) or the remote UE's signing public key (which may be sent to the relay UE as part of a direct communication request, which the relay UE then forwards to the core network) or a decryption key derived from key materials provided during the initial provisioning of the remote UE (e.g., along with other information from step 0).

[0378] Step 6 The relay device UE1 sends a response message M' to UE0 (e.g., via PC5 or via a direct communication response message or a direct discovery response message forwarded from message N'), which includes the encrypted RSC2 received by the relay device UE1 as part of message N' in step 5.

[0379] Step 7 UE0 decrypts RSC2 and updates the table containing the set of relay service codes as received in step 0 and their associated PDU session parameters, or stores information about RSC1 being replaced by RSC2 in its memory or non-volatile storage device. If not already started, UE0 can initiate its indirect communication session with CCS via relay device UE1 using the PDU session attributes associated with RSC1.

[0380] Step 8 During the subsequent discovery and connection setup message on PC5, UE0 uses RSC2 (after decryption) instead of RSC1 to find or set up a relay connection that is expected to utilize the PDU session attributes associated with RSC1, but which is also associated with the same PDU session attributes or is now recently associated with them (i.e., after step 6).

[0381] In another element of the embodiment, the relay device UE1 is provided by the CCS only to store a set of relay service codes that do not contain information about PDU session parameters, or therefore each relay service code is associated with a set of unique temporary identifiers (such as temporary slice identifiers or temporary DNN identifiers known by the CCS to be linked to the same S-NSSAI) to refer to privacy-sensitive PDU session parameters.

[0382] The benefit of this approach is that the remote UE can search for one of the alternative service codes next time, and the relay UE will not be able to link the alternative service code to the same slice / DNN or the same remote UE (assuming the Layer 2 ID has changed simultaneously). Note that it is assumed that RSC2 is encrypted using a key that can only be decrypted by device UE0 (e.g., derived from device UE0's USIM credentials). UE0's identifier can be, for example, a Globally Unique Temporary Identifier (GUTI), a Temporary Mobile Subscriber Identity (TMSI), or a Subscription Hidden Identifier (SUCI). UE1's identifier can be a Layer 2 identifier used in PC5 discovery messages or other PC5 messages received from relay device UE1, or another identifier (such as GUTI / TMSI / SUCI) received as part of PC5 discovery messages or other PC5 messages received from relay device UE1. The previously selected relay UE may still know the slice information only if an outdated remote UE appears and searches for the old RSC. This can be mitigated by limiting the lifetime of the RSC and / or by reusing the RSC for other PDU session parameters (making it impossible for the relay UE to determine which PDU session parameters correspond to a specific RSC) and / or by updating all remote UEs or potential remote UEs near the relay UE (e.g., within a specific tracking area) to use RSC2 instead of RSC1 (e.g., by performing a policy update or UE configuration update). Note that relay UE1 may have already been automatically exposed or responded to RSC2 during PC5 discovery if it is part of a set of backup relay service codes, or may need to be triggered by the CCS by sending a separate message containing one or more relay service codes (including RSC2) to relay UE1 at a randomized time, preferably after UE0 has been disconnected (to ensure that relay UE1 cannot associate RSC1 and RSC2).

[0383] Reusing relay service codes is possible (e.g., by linking PDU session parameters within the CCS to a specific combination of remote and relay UEs), but this can require careful management. If, after some time, all alternative relay service codes have been used, or if there is a policy of occasionally refreshing all relay service codes, then a new set of relay service codes will need to be given to all (potential) remote and (potential) relay UEs. Typically, the UE will then have to be within the coverage area of ​​the core network's base stations to be able to connect directly and securely to the core network, rather than via a potentially insecure connection through the relay UE. If some (potential) remote UEs are out of coverage for an extended period, these UEs may not have been updated by the time they want to discover and connect to the relay UE, and therefore these remote UEs may still be using the old set of relay service codes. This can lead to potential errors and security and privacy risks. If such an outdated remote UE connects to a relay device, it should preferably send a relay service code encoded using (U)SIM credentials (such as the remote UE's latest Kausf), along with a freshness parameter indicating that the key has not been updated for a period of time (e.g., by using a key freshness parameter, or a time value when it last received an updated set of relay service codes). If this parameter indicates that the remote UE's relay service code and key have not been updated for a period of time, then the relay UE and / or CCS should refuse to use the relay service code, refuse to establish a relay connection, and not provide the relay UE with PDU session parameters. In such a case, the relay UE can send an encrypted relay service code and freshness parameter to the CCS, after which the CCS can assign a new RSC2 to the remote UE (and the relay UE) and send it back to the relay UE as an encrypted payload. The relay UE can then send it to the remote UE, which can use the new RSC2 to connect to the network (e.g., using a set of default PDU session parameters with, for example, a default slice).

[0384] It should be understood that it is possible to use both the encrypted identifier and the selection of an RSC from a set of alternative RSCs.

[0385] In another element of the embodiment, if the output of decrypting the received security envelope V or the received encrypted identifier reveals the identifier of the relay device UE1, or if the message authentication code forwarded by the relay device and originating from UE0 reveals that the identifier has not been manipulated, or if the relay device UE1 can be uniquely identified using the information received in message N, then the cellular communication system CCS sends only message N' containing the encrypted relay service code RSC2 or PDU session information associated with RSC1 to the relay device UE1.

[0386] The benefit of this is that relay UEs not selected by the remote UE cannot receive new RSC2 or receive PDU session information associated with RSC1 by replaying messages from the selected relay UE or by sending their own messages to the CCS containing RSC1. Note that it is assumed that the security envelope V or encrypted identifier or message authentication code is encrypted / encoded / hashed using a key derived from the USIM credentials. Note that the CCS can also use the information provided by the encrypted envelope V or encrypted identifier or message payload along with the corresponding message authentication code to perform additional authentication of whether relay device UE1 is allowed / authorized to act as a relay UE for the corresponding remote UE, and can send some encrypted verification codes to device UE0 as part of the same message containing the encrypted relay service code RSC2.

[0387] In another element of the embodiment, RSC1 is added to the secure envelope / payload V, or sent as part of message M as an encrypted value (e.g., using a public key received during relay discovery). The encrypted RSC1 can then be included by the relay device in message N, and if RSC1 (e.g., using the original encryption, decryption, or re-encryption) and the unique identifier of UE1 are included in message N, or if RSC1 is included and the relay device UE1 can uniquely identify itself using the information received in message N, then the CCS can send only a message to the relay device UE1 containing the encrypted relay service code RSC2 or PDU session information associated with RSC1.

[0388] In the example, the payload of message M may include the SUCI or 5G-GUTI (i.e., ID_Remote) of the remote UE, and / or the encrypted relay service code (RSC) and / or SUCI or 5G-GUTI of the relay device (i.e., ID_Relay) selected by the remote UE device (UE0). Additionally or independently, the payload of message M may include a random number N_Relay received from the relay device (UE1), a new random number N_Remote generated by the remote UE device, and / or a message authentication code. The relay service code and the identity of the selected relay UE can be encrypted (together) to prevent eavesdroppers from linking these identities to the remote UE device. Preferably, encryption is performed using a key / credential that prevents the information from being decrypted by the relay device (or at least the unselected relay device), while the CCS will be able to decrypt the information to ensure that only the relay device selected by the remote UE will receive PDU session parameters from the network, will be authorized, and / or will obtain the obtained key for setting up the relay connection. The encryption key (K_enc) can be derived from the USIM, such as the latest Kausf or Ksea that the remote UE has established with the CCS, or long-term security material received in step 0 for relay connection or PC5 link setup (e.g., PRUK as defined in TS 33.303 or long-term credentials as defined in TS 33.536, or other pre-shared keys or public keys to ensure secure communication between the CCS and the remote UE). Thus, the random numbers N_Relay and / or N_Remote can be used as additional inputs to the key derivation function. As an example, if RSC and ID_Relay are encrypted together, the message authentication code can be calculated using the integrity key K_int as follows: MAC(K_int, ID_Remote|N_Relay|N_Remote|ENCRYPT(K_enc, RSC|ID_Relay)). Upon receiving message M, relay device UE1 sends message N to CCS. Message N may include the selected relay device's ID_Remote, the (encrypted) relay service code, and / or the (encrypted) ID_relay (e.g., SUCI / 5G-GUTI), or an encrypted combination of RSC and ID_relay (e.g., ENCRYPT(RSC|ID_relay)). It should be understood that even if SUCI itself is already an encrypted identifier, it can be encrypted again using another key, the benefit of which is that this securely links the identifier to RSC.

[0389] Message N may include a random number and a message authentication code in the NAS relay authorization request / key request. Upon receiving message N, the CCS (e.g., AMF along with AUSF / UDM / PKMF) can derive K_enc and K_int based on ID_Remote and the received random number, and can check the integrity of the message fields and decrypt the encrypted RSC and / or the encrypted value ENCRYPT(RSC|ID_Relay) to obtain RSC and ID_Relay. The CCS can also verify that ID_Relay matches the identity of the UE from which it received the message to the network relay before continuing subsequent procedures. The CCS and / or the relay device can track the random number used, and discard any messages if the random number is reused to prevent replay attacks. Similarly, the CCS can keep track of 5G-GUTI or SUCI values ​​that have been used to verify that the same value has not been used multiple times. The CCS can also keep track of the number of requests from a remote UE or relay device or remote device to verify that it has not exceeded the maximum number of requests within a certain time window. CCS can send its own random number to a remote UE or relay device and wait for a confirmation message from the device that uses it.

[0390] As mentioned above, preferably, the requested relay service code can only be decrypted by the CCS. If the relay device UE1 is pre-configured with PDU session attributes associated with the supported relay service code during initial provisioning, the decryption of the relay service code needs to be provided to the relay device only after it has been decrypted by the CCS, and preferably only after it has been verified that the relay device and the remote UE are authorized to set up a relay connection for the corresponding relay service code via the selected relay device. This can be accomplished by adding the decrypted relay service code to the response message N', allowing the relay device to use the decrypted relay service code to obtain the PDU session attributes associated with the relay service code and to set up a PDU session to the core network based on those PDU session attributes.

[0391] In the above embodiments, ID_Remote is sent without any additional encryption (i.e., SUCI itself is already encrypted with the home network public key) and can be used by the CCS (after being forwarded by the relay device) to identify the corresponding decryption key or select the correct AUSF, PCF, UDM, PKMF, or other network service responsible for authentication, provisioning / configuration, subscription, and prose key management of the remote UE, as well as other network services in the home or access network. For example, the CCS (e.g., the AMF acting as a relay device) can provide a decryption key (e.g., derived from Kausf) for decrypting the encrypted value ENCRYPT(RSC|ID_relay) after selecting the correct AUSF / PCF / UDM / PKMF, or it can request the corresponding network service to decrypt the encrypted value ENCRYPT(RSC|ID_relay). The CCS can also use ID_Remote to select the correct PCF or other network service responsible for allocating new relay service codes. To further protect the identity of the remote UE, ID_Remote is not sent in plaintext, but as part of an encrypted value (i.e., by concatenating RSC, ID_Remot, and ID_Relay before encrypting it – preferably by using a key / credential that does not allow the relay device to decrypt the information, while the CCS will be able to decrypt the information). Thus, after being decrypted by the CCS and preferably only after the relay device and the remote UE have been verified to be authorized to set up a relay connection for the corresponding relay service code via the selected relay device, ID_Remote is provided to the relay device (in response message N').

[0392] The benefit of this approach is that other nearby remote UEs (which may use the same RSC and may already have PDU session parameters associated with that RSC) cannot track other remote UEs and infringe on their privacy by monitoring unprotected PC5 discovery and connection setup traffic, because the RSC is no longer sent in plaintext, and it will also be unaware of the RSC2 that will be used after the remote UE has disconnected from the relay UE. Furthermore, by securely combining the relay service code (e.g., via a protected payload / envelope or a message authentication code that can only be decrypted by the core network), a malicious relay UE cannot easily replace the relay service code with another. Additionally, a relay UE that has not yet been selected cannot easily request the CCS to participate in relaying with a remote UE for the corresponding relay service code.

[0393] In another element of the invention, which can be combined with or implemented independently of any other embodiment, the device UE0 is provided with a set of alternative / equivalent RSCs associated with the same PDU session parameter set, and the device UE0 selects one of these alternative / equivalent RSCs in a discovery or connection setting message from PC5 to the relay UE (e.g., on a random basis or by periodically rotating these alternative / equivalent RSCs).

[0394] This makes it more difficult for other UEs to understand the correlation between the RSC value and the PDU session parameters, and increases the lifetime required to update the RSC value and its mapping to the PDU session parameters before it is updated.

[0395] In another element of the embodiment, which can be combined with or implemented independently of any other embodiment, in step 0, the necessary policies, rules, and information (e.g., ranges of values, wildcards, randomization seeds, functions that generate them, such as hash functions like SHA-2 or SHA-3, extensible output functions like SHAKE, or DRBG as defined in NIST.SP.800-90) are provided to the device UE0 and / or the relay device UE1 so that the currently valid RSC can be generated pseudo-randomly based on time using a pseudo-random function (PRF) (assuming the remote UE can know the current time via an internal clock or an external reference clock (e.g., GPS or using synchronization frames from the base station or relay device)). To handle small time differences that may result in different relay service codes (RSCs), message exchange (such as the following challenge-response authentication handshake, where the seed RSC is a key) can be performed between the remote UE and the relay UE, assuming they both have a seed for generating the RSC:

[0396] a) The remote UE announces its presence by randomly generating a random number N_UE and broadcasting it.

[0397] b) The relay UE receives N_UE, generates a random number relay N_R, and derives a pseudo-random RSC for all its supported seed_RSC_i (where i is the index), as PRF_RSC_i = Truncate(HASH(seed_RSC_i|N_UE|N_R), b_bits), where Hash() is a hash function, | indicates concatenation, and Truncate(X,b) returns b bits of X, such as b least significant bits.

[0398] c) The relay UE sends back its N_R and all calculated PRF_RSC_i

[0399] d) The remote UE performs a similar operation given the received N_R, and checks if one of the PRF_RSC_i is the same. If a match is found, it selects that relay.

[0400] After connecting to the relay UE (which can run a corresponding pseudo-random RSC generator for one or more remote UE groups and / or use wildcards to match the RSCs of one or more remote UE groups) with an RSC valid at that specific time, the CCS can replace or supplement the determination of RSC2 in step 4, generate a new value range, wildcards, randomization seed for the pseudo-random RSC generator, and send the information as part of message N' by encrypting the information with a known key, or for that, the decryption key can be derived by UE0 instead of relay device UE1 (e.g., based on UE0's USIM credentials).

[0401] The benefit of this approach is that, over time, more relay service codes will be used, and it becomes very difficult for eavesdroppers (including remote UEs running other pseudo-random key generators or with different ranges or seeds) to link relay service codes to a specific set of session parameters for a particular remote UE and PDU. In this way, it prevents overlap of relay service codes between remote UEs without hindering scalability.

[0402] In another element of an embodiment that can be combined with or implemented independently of any other embodiment, device UE0 includes a globally unique temporary identifier (GUTI) or a temporary mobile subscriber identity (TMSI) or a subscription hidden identifier (SUCI) as part of a message M to the relay UE and a subsequent message N to the CCS, so that the CCS can uniquely identify the remote UE, and in its response to the received message N, the CCS sends a new encrypted GUTI or TMSI or SUCI to device UE0 via relay device UE1.

[0403] The reason for this is that the GUTI, TMSI, or SUCI may need to be sent in plaintext via PC5 along with a discovery and / or communication request so that the CCS can identify the key used to decrypt the security envelope V and / or the encrypted identifier. If this is done in this way, it means that the GUTI / TMSI / SUCI has been exposed and should not be used again, and therefore needs to be updated. The CCS can also verify whether the GUTI / TMSI / SUCI sent along with the message corresponds to the identifier of UE0 sent within the security envelope V or serves as an encrypted identifier.

[0404] In another element of the embodiment, the CCS sends an updated Layer 2 ID or other updated identifier (e.g., an update of the temporary identifier received in step 0) of device UE0 and / or relay device UE1 to be used as part of its response message N' in subsequent messages between UE0 and UE1. Alternatively, device UE0 and / or relay device UE1 may assign itself a new Layer 2 ID after receiving response message N', after sending response message M', or after UE0 and UE1 disconnect from each other, or the CCS may also trigger device UE0 and / or relay device UE1 to update its Layer 2 ID by sending a separate message.

[0405] The reason for this is that the Layer 2 ID or other (temporary) identifier used between UE0 and UE1 can be sent unencrypted in message exchanges, potentially exposing privacy-sensitive information. Therefore, the unencrypted Layer 2 ID or other (temporary) identifier sent between UE0 and UE1 should be updated to provide additional protection against malicious tracking of the device. We note that UEs typically use GUTI / SUCI, where SUCI is an encrypted version of SUPI and is used to hide the UE's long-term identity. After authentication using SUCI, a GUTI is assigned to the UE for subsequent connections. In this document, a time identifier is introduced as an alternative. This is because relays can collect many GUTIs or SUCIs. Relays can also prevent the UE from receiving a response from the CN. If a remote device sends its GUTI and it does not receive the expected response, this can have consequences for the remote UE. This may force the UE to use the more expensive SUCI next time. Typically, relays can cause synchronization errors in the mapped GUTI–SUPI that increase latency. This is likely the reason for introducing a third temporary identifier, as proposed above. Such a third temporary identifier can be of independent interest and can be used in conjunction with other solutions. For example, in the context of solutions #1, #6, #10, and #15 in TR 33.847, when a remote device sends a request to the CN to establish a secure PC5 link with the relay, we note that the third temporary ID can be exported in a manner similar to the GUTI and used only for relay settings, or it can also be exported from the current GUTI.

[0406] In another element of an embodiment that can be combined with or implemented independently of any other embodiment, to further prevent malicious relaying of the UE, if device UE0 does not receive a new RSC value (i.e., RSC2) after sending RSC1 to relay device UE1 after a specific timeout period, device UE0 temporarily ceases to act as a remote UE and temporarily blocks / stops / interrupts any ongoing relaying process. Device UE0 may wait until it enters the coverage area of ​​the gNB, and after connecting to the gNB, request an RSC update before activating the remote UE function and resume acting as a remote UE.

[0407] The reason for this is that the response N' sent by the CCS to the relay UE may never be forwarded to the remote UE, so the remote UE will not know that it should use the new RSC and can continue to use the old RSC.

[0408] In another element of the embodiment, to further prevent another relay device from sending a request message with the same content as message N to the CCS, relay device UE1 may send a second encrypted identity or signature, enabling the CCS to verify whether the encrypted identifier of UE1 received in message N corresponds to the second encrypted identifier or signature and / or whether these encrypted identifiers (after decryption) directly or indirectly identify the same relay device or are associated with the same relay device (i.e., in this case, relay device UE2). This can also be accomplished by linking the encrypted identifier of relay device UE1 with an identifier used by the relay device to establish a secure link between the relay device and the CCS through which message N is sent.

[0409] Note that when the mobile device uses a PC5 Layer 2 identifier (e.g., during discovery) as the identifier for the relay device UE1 as input for message M, the following procedure can be applied and supplements the detailed procedure described above:

[0410] a. If the PC5 Layer 2 identifier used by relay device UE1 is securely configured / provided by CCS (e.g., using a secure connection between PCF and relay device UE1 and / or device UE0), then if

[0411] 1. Relay device UE1 has an authenticated secure connection to CCS, which can obtain information configured / provided for relay device UE1 and verify that the PC5 Layer 2 identifier configured / provided for relay device UE1 corresponds to or relates to the same PC5 Layer 2 identifier of relay device UE1 sent in encrypted form as part of message N.

[0412] (Originating from message M sent by device UE0).

[0413] 2. Relay device UE1 does not have an authenticated secure connection to CCS. Relay device UE1 can use encrypted methods.

[0414] (Or as part of a signature) add its GUTI / TMSI / IMSI / SUPI / SUCI / GPSI or any other unique identifier or hash thereof to message N (other than the encrypted identifier received by envelope V or relay device UE1 in message M from device UE0), which allows CCS to associate this information with the PC5 Layer 2 identifier it has configured / provided for relay device UE1, and to verify whether it corresponds to or relates to the same PC5 Layer 2 identifier (originating from message M as sent by device UE0) that is sent encrypted as part of message N.

[0415] b. If the PC5 Layer 2 identifier is self-assigned, relay device UE1 can securely send the self-assigned PC5 Layer 2 identifier to the CCS (e.g., after each time it assigns a new Layer 2 identifier). The CCS can store this information and link it to other identifiers it has already stored for relay device UE1. The CCS can use this information to verify whether the self-assigned PC5 Layer 2 identifier for relay device UE1 corresponds to or relates to the same PC5 Layer 2 identifier received cryptographically as part of message N (originating from message M, such as that sent by device UE0).

[0416] Note that when CSS configures / provides PC5 Layer 2 identifiers, CSS can configure / provide remote UEs (i.e., device UE0) with a set of PC5 Layer 2 identifiers that a specific relay UE can use or with a mapping between the relay UE's PC5 Layer 2 identifier and a set of other identities of the relay UE (e.g., GUTI / TSI / SUCI).

[0417] In another element of an embodiment that can be combined with or implemented independently of any other embodiment, the relay device UE1, upon (initial) registration to the CCS (e.g., upon entering a new registration area) or when setting up a PDU session with the CCS (e.g., for relay purposes), receives an updated list of relay service codes from the CCS, wherein only relay service codes associated with permitted network slices / S-NSAIs are valid in that registration area for use by remote UEs and / or relay devices (e.g., as determined by AMF, PCF, DDNMF, NG-RAN) to (temporarily) replace or update a list of relay service codes (and their associated PDU session parameters) already provided in the relay device or to be stored as a separate list in the relay device, or receives from the CCS a list of relay service codes associated with disallowed network slices / S-NSAIs in that registration area to update the list of relay service codes (and their associated PDU session parameters) already provided in the relay device or to be stored as a separate list in the relay device, or receives a discovery filter that it should apply during discovery, which matches only relay service codes associated with permitted network slices / S-NSAIs. Similarly, in the case of non-public network access, if relay device UE1 registers with a base station dedicated to that non-public network (e.g., identified as a Closed Access Group (CAG) cell), it receives an updated list of relay service codes from the CCS. These codes are associated only with the non-public network identity / closed access group, which is valid / permitted / authorized for remote UE and / or relay device access (e.g., determined by AMF, PCF, DDNMF, NG-RAN), to (temporarily) replace or update relay services already provided in the relay device or to be stored in a separate list. The system receives a list of service codes (and their associated PDU session parameters), or a list of relay service codes associated with a non-public network identity / closed access group that is invalid / allowed / authorized for remote UE and / or relay device access, in order to update the list of relay service codes (and their associated PDU session parameters) that are already provided in the relay device or to be stored as a separate list, or receives a discovery filter that should be applied during discovery, which only matches relay service codes associated with non-public network identity / closed access groups that are valid / allowed / authorized for remote UE and / or relay device access.

[0418] Solution 18 in TR 33.847 describes a protocol for setting up and authorizing PC5 links from a UE to a network relay. Its main steps are as follows: In step 0, the CN, specifically the PKMF and DDNMF, provides parameters, including discovery parameters, PKMF addresses, or discovery parameters, to both the remote UE and the relay UE.

[0419] In step 1, the remote UE performs a remote user key request and retrieves the PRUK and PRUK ID from the PKMF.

[0420] In step 2, the discovery process is performed, for example, based on solutions 3 and 4 in TS 33.303 or TR 33.847.

[0421] In step 3, the remote UE sends a direct communication request to the relay UE, including parameters such as PRUK ID, relay service code, and first freshness parameter.

[0422] In step 4, the relay UE sends a key request to the core network to retrieve the K_NRP, ensuring the PC5 interface with the remote UE and the second freshness parameter. The K_NRP is derived from the PRUK and the freshness parameter.

[0423] In step 5, the relay forwards the freshness parameters to the remote UE. Using these freshness parameters and the PRUK, the remote UE can generate the same K_NRP as received by the relay UE. The K_NRP serves as the basis for mutual authentication and security on the PC5 link.

[0424] One problem with Solution 18 in TR 33.847 is that in step 3, the relay service code and PRUK ID are exchanged in plaintext, which represents a privacy issue as identified in the embodiments described above. This is why S3-212859 proposes to enhance Solution 18 by scrambling these fields in step 3. The pCR of Solution 18 in 3GPP TR 33.847 is another element of embodiments that can be combined with any other embodiment or implemented independently, or that can be combined with the processes in Tdoc S3-212859.

[0425] For additional privacy protection, remote UEs should use different keys or pseudo-random sequences for encrypting or scrambling the Relay Service Code (RSC) and / or for the identifiers of remote UEs and / or relay UEs for direct communication requests from the key, which were used in the previous Model B discovery request message to encrypt / scramble the discovery parameters as part of the discovery message, for example by using different FC values ​​(as defined in TS 33.220) as inputs for the key derivation function.

[0426] This could help prevent eavesdroppers from linking discovery messages and related direct communication request messages. For example, in S3-212859, a privacy enhancement is proposed where the RSC sent in the (scrambled) DCR message is protected by the discovery user scrambling key (DUSK) key in the remote UE's code reception security parameters. However, this does not provide sufficient protection because it is recommended to use the same DUSK to protect both the RSC and the Prose relay user key (PRUK) ID. If this key is also used to scramble the discovery message, and the UTC counter can remain the same because the exchange of discovery and DCR messages is very fast, then the same scrambling pseudo-random sequence will be used. If the same pseudo-random sequence is used to scramble two different sets of information (discovery message and PRUK ID|RSC), then by XORing the two scrambling sequences, we obtain the XOR of the two sets of information, namely the XOR of the discovery message and the PRUK ID|RSC. This is a plaintext XOR and represents a security risk because individual parts could be guessed.

[0427] To prevent such security risks, as advantageously mentioned in this embodiment, different pseudo-random sequences should be specified for scrambling the relay service code and PRUK ID. Preferably, when using the same DUSK, this problem is avoided by using a different FC value for the discovery message than for the direct communication request message. Alternatively, a different key distributed during initial provisioning, or a key distributed during message exchange with the CCS (e.g., with DDNMF), or a key distributed during discovery should be used.

[0428] Furthermore, according to the previous embodiment, the process in S3-212859 should be extended to include a step whereby the CCS (e.g., DDNMF) assigns a new relay service code value to be used, instead of the relay service code used for subsequent discovery messages in step 4a. This new relay service code value is then sent to the remote UE (e.g., by extending the key response message of step 4b to the relay UE and the subsequent direct security mode command message of step 5a, which has additional fields with the new relay service code or different (groups) of messages (such as PC3 messages between DDNMF and the remote UE)). Thus, the relay service code can be protected by using a key derived from the Prose relay service key (PRUK) (e.g., based on ID) using a key derivation function (whose S string may include the K_NRP freshness parameter 1 and a UTC-based counter).

[0429] Furthermore, according to previous embodiments, the process in S3-212859 should be extended by the relay UE (including the random number) during discovery step 2, whereby the received random number should be sent by the remote UE in a subsequent direct communication request message (e.g., as an additional field). After receiving the direct communication request message, the relay UE can then verify the freshness of the random number and verify that no replay attack exists. Alternatively or additionally, the remote UE should use the received random number instead of a UTC-based counter (i.e., ensuring that the scrambling sequences are different) in step 1 of 6.18.2.2.2 of S3-212859 to ensure that the scrambling sequences are different and to allow the relay UE to avoid replay attacks if the relay UE has a strategy that allows each sent random number as a replay in the discovery message to be used only once when forwarding the DCR message.

[0430] Alternatively or additionally, the relay UE may limit the number of messages (e.g., key request messages) generated toward the CCS by incoming direct communication request messages (e.g., based on a policy provided by the PCF that allows setting such limits, possibly per RSC).

[0431] Various methods are provided for use in the cellular communication system described above. A first method includes the step of performing a relay function in a mobile device. A second method includes the step of performing a relay processor function in a relay device. A third method includes the step of performing a network relay function in a cellular network.

[0432] These methods can be implemented in many different ways, as will be apparent to those skilled in the art. For example, the order of stages or steps can be changed, or some stages can be executed in parallel. Furthermore, other method steps can be inserted between the steps. The inserted steps may represent a refinement of, for example, the methods described herein, or they may be unrelated to the method.

[0433] A computer program product is provided, which can be downloaded from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium. This computer program product includes program code instructions that, when executed on a computer device, are used to implement the methods, linking sequences, security procedures, and other operations described above. Therefore, software can be used to run the methods according to the invention, the software including instructions for causing a processor system to execute the corresponding methods.

[0434] Typically, mobile devices, relay devices, and NRFs include a processor coupled to memory containing appropriate software code stored at the device; for example, this software may have been downloaded and / or stored in a corresponding memory, such as volatile memory like RAM or non-volatile memory like flash memory (not shown). The device may, for example, be equipped with a microprocessor and memory (not shown). Alternatively, the device may be implemented wholly or partially as programmable logic units, such as a field-programmable gate array (FPGA). The device and server may be implemented wholly or partially as so-called application-specific integrated circuits (ASICs), i.e., integrated circuits (ICs) customized for their specific purpose. For example, the circuit may be implemented in CMOS (e.g., using a hardware description language such as Verilog, VHDL, etc.).

[0435] The software may include only those steps taken by specific sub-entities of the system. The software may be stored in a suitable storage medium (e.g., hard disk, floppy disk, memory, etc.). The software may be transmitted as a signal along a wired or wireless route or using a data network (e.g., the Internet). The software may be downloaded to a server and / or used remotely. The method according to the invention may be executed using a bitstream arranged to configure programmable logic units (e.g., field-programmable gate arrays (FPGAs)). It will be appreciated that the software may be in the form of source code, object code, intermediate source code, and object code in a partially compiled form, or any other form suitable for use in embodiments of the method according to the invention. Embodiments relating to a computer program product include computer-executable instructions corresponding to each processing step in at least one of the processing steps of the illustrated method. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to a computer program product includes computer-executable instructions corresponding to each module in at least one of the modules of the illustrated system and / or product.

[0436] It will be appreciated that, for clarity, the above description refers to different functional units and processors to describe embodiments of the invention. However, it should be understood that any suitable functional distribution among different functional units or processors can be used without departing from the invention. For example, functions illustrated as being performed by a separate unit, processor, or controller can be performed by the same processor or controller. Therefore, references to specific functional units are considered merely as references to suitable units used to provide the described functions, and not as indications of strict logical or physical structures or organizations. The invention can be embodied in any suitable form, including hardware, software, firmware, or any combination of these items.

[0437] It should be noted that in this document, the verb "comprising" does not exclude the presence of elements or steps other than those listed, and the words "a" or "an" preceding an element do not exclude the presence of multiple such elements. When expressions such as "at least one of" appear after a list of elements, such expressions indicate the selection of all elements or any subset thereof from that list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. No reference numerals are intended to limit the scope of the claims. The invention can be implemented by means of both hardware and software. Several "modules" or "units" can be represented by the same items in hardware or software, and a processor can implement the functionality of one or more units, possibly cooperating with hardware elements to implement the functionality of one or more units. Furthermore, the invention is not limited to these embodiments, and the invention lies in each novel feature or combination of features described above or recited in mutually different dependent claims.

[0438] In summary, the cellular communication system supports network slicing and has a network relay function for managing indirect connections. A mobile device can send a request message to a relay device, the request message including a relay service code (associated with a set of privacy-sensitive PDU session parameters). The relay device receives the request message and sends a transmission request message to the cellular communication system, indicating a request to transmit data via the indirect connection and including the requested relay service code. The network relay function receives the transmission request message, determines a different relay service code (from a set of alternative relay service codes) to be used in place of the requested relay service code, and sends a transmission response message to the relay device. The transmission response message includes the different relay service code in an encrypted manner that allows it to be decrypted by the mobile device rather than the relay device. The relay device then forwards the encrypted different relay service code to the mobile device in response to the initial request message.

[0439] References:

[0440] [22.261] 3GPP TS 22.261v16.7.0, Service requirements for the 5G system; Phase 1, March 2019.

[0441] [22.866]3GPP TR 22.866v0.2.0, enhanced Relays for Energy Efficiency and Extensive Coverage; Phase 1, February 2019.

[0442] [23.287] 3GPP TS 23.287v1.0.0, Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services (version 16), May 2019.

[0443] [23.303] 3GPP TS 23.303v15.0.0, Proximity-based services (ProSe); Stage 2; Phase 2 (Release 15), June 2017.

[0444] [23.501] 3GPP TS 23.501, System Architecture for the 5G System; Phase 2, v16.0.2, April 2019. - [23.503] 3GPP 23.503, TS Policy and charging control framework for the 5G System (5GS); Phase 2 (Version 15.6.0, June 2019).

[0445] [23.733] 3GPP TR 23.733v15.1.0, Study on Architecture Enhancements to ProSe UE-to-Network Relay (Version 15), December 2017.

[0446] [24.334] 3GPP TS 24.334v15.1.0, Proximity-services (ProSe) User Equipment (UE) to ProSe function protocol aspects; Phase 3, December 2017.

[0447] [24.501] 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for 5G System (5GS); Phase 3 (Version 15.4.0, June 2019)

[0448] [29.507] 3GPP TS 29.507, 5G System; Access and Mobility Policy Control Service; Phase 3 (Version 15.4.0, June 2019)

[0449] [33.813] 3GPP TR 33.813v0.5.0, Study on Security Aspects of Enhanced Network Slicing, June 2019. [36.300] 3GPP TS 36.300v15.2.0, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Phase 2 (Release 15), June 2018.

[0450] [36.746] 3GPP TR 36.764v15.1.0, Study on further enhancements to LTEDevice to Device (D2D), User Equipment (UE) to network relays for Internet of Things (IoT) and wearables; (Release 15), December 2017. [38.300] 3GPP TS 38.300v15.5.0, NR; NR and NG-RAN Overall Description; Phase 2, March 2019. [38.331] 3GPP TS 38.331v15.5.1, NR; Radio Resource Control (RRC) protocol specification, April 2019.

[0451] [38.473] 3GPP TS 38.473, v15.4.1, NG-RAN; F1 application protocol (F1AP), January 2019.

[0452] [38.874] 3GPP TR 38.874v16.0.0, NR; Study on Integrated Access and Backhaul, December 2018.

[0453] [S2-1907204] 3GPP TS 23.501CR1522 Introduction of the IAB support in5GS, June 2019.

[0454] [elayoubi] 5G RAN Slicing for Verticals: Enablers and Challenges (IEEE Communications Magazine, Vol. 57, No. 1, 2019).

[0455] [EventHelix]The EventHelix website, https: / / www.eventhelix.com / 5g / stestalone-access-registration / , has a link to a PDF file overview and detailed information.

[0456] [Pavelshulgin]5G StandAlone Access-Registration Procedure-Part2 (AMFselection procedures, slices), https: / / www.linkedin.com / pulse / 5g-standalone-access-registration-procedure-part2amf-pavel-shulgin /

Claims

1. A cellular communication system (CCS) comprising a radio access network (RAN) including multiple cellular base stations (BS) and a core network (CN), The cellular communication system provides support for cellular networks with indirect connectivity. Each indirect connection provides data transmission between the mobile device and the cellular communication system via at least one relay device, the relay device being a mobile device configured to communicate with the radio access network and capable of supporting the indirect connection. The cellular communication system includes at least one network relay entity (140), which is configured to provide network relay functionality (NRF) for managing the indirect connection. The mobile device (110) includes: A connection processor (112) is arranged to manage connections to the cellular network, the connection processor providing relay functionality (116) for managing at least one indirect connection. The relay function is configured to at least: As part of the setup process, a request message (M) is sent to at least one relay device (UEx), the request message including a relay service code (RSC1) and an encrypted identifier of the at least one relay device (UEx), and also including an encrypted identifier of the mobile device; Receive a response message (N) from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2); The encrypted relay service code (RSC2) is decrypted, and the decrypted relay service code (RSC2') is inserted into the subsequent discovery and connection setup message instead of RSC1, thereby associating RSC2' with the same set of PDU session attributes as RSC1; The relay device (120) includes: A communication unit (121) is arranged for communication in the cellular network (130), and, A relay processor (122) is configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network. The relay processor is configured as follows: Receive the request message (M) from the mobile device; After receiving the request message (M), a transmission request message (M') is sent to the cellular communication system according to the request message (M), the transmission request message (M') including at least one of the encrypted identifiers received from the mobile device in the request message (M) and the relay service code (RSC1); Receive a transmission response message (N') from the cellular communication system, the transmission response message (N') containing the Encrypted Relay Service Code (RSC2); After receiving the transmission response message (N'), a response message (N) containing the encrypted relay service code (RSC2) is sent to the mobile device according to the transmission response message; The network relay function is configured as follows: At least one transmission request message (M') is received from the relay device, the transmission request message (M') including a relay service code (RSC1) and at least one of the following: the encrypted identifier of the mobile device and the encrypted identifier of the relay device; Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message (M'); The different relay service code (RSC2') is encrypted using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2). Send a transmission response message (N') including the encrypted relay service code (RSC2) to the relay device.

2. The cellular communication system of claim 1, wherein, The network relay function is configured to encrypt the identifier of the mobile device and / or the identifier of the relay device using a key, the key allowing the identifier of the mobile device and / or the identifier of the relay device to be decrypted by the network relay function (NRF) in the cellular network instead of by the relay device itself.

3. A cellular communication system (CCS) comprising a radio access network (RAN) including multiple cellular base stations (BS) and a core network (CN), The cellular communication system provides support for cellular networks with indirect connectivity. Each indirect connection provides data transmission between the mobile device and the cellular communication system via at least one relay device, the relay device being a mobile device configured to communicate with the radio access network and capable of supporting the indirect connection. The cellular communication system includes at least one network relay entity (140), which is configured to provide network relay functionality (NRF) for managing the indirect connection. The mobile device (110) includes: A connection processor (112) is arranged to manage connections to the cellular network, the connection processor providing relay functionality (116) for managing at least one indirect connection. The relay function is configured to at least: As part of the setup process, a request message (M) is sent to at least one relay device (UEx), the request message including a relay service code (RSC1), and also including an identifier of the at least one relay device (UEx), and also including an identifier of the mobile device and a message authentication code; Receive a response message (N) from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2); The encrypted relay service code (RSC2) is decrypted, and the decrypted relay service code (RSC2') is inserted into the subsequent discovery and connection setup message instead of RSC1, thereby associating RSC2' with the same set of PDU session attributes as RSC1; The relay device (120) includes: A communication unit (121) is arranged for communication in the cellular network (130), and, A relay processor (122) is configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network. The relay processor is configured as follows: Receive the request message (M) from the mobile device; After receiving the request message (M), a transmission request message (M') is sent to the cellular communication system according to the request message (M), the transmission request message (M') including the relay service code (RSC1), the message authentication code and the identifier of the mobile device received from the mobile device in the request message (M); Receive a transmission response message (N') from the cellular communication system, the transmission response message (N') containing the Encrypted Relay Service Code (RSC2); After receiving the transmission response message (N'), a response message (N) containing the encrypted relay service code (RSC2) is sent to the mobile device according to the transmission response message; The network relay function is configured as follows: Receive at least one transmission request message (M') from the relay device, the transmission request message (M') including a relay service code (RSC1) and an identifier of the mobile device and the message authentication code; Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message (M'); The different relay service code (RSC2') is encrypted using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2). Send a transmission response message (N') including the encrypted relay service code (RSC2) to the relay device.

4. The cellular communication system (CCS) according to any one of claims 1-3, wherein, The relay processor is configured to store a set of backup relay service codes, and the network relay function is configured to select the different relay service code (RSC2') from the set of backup relay service codes available in the relay device or a new relay service code.

5. The cellular communication system according to claim 3, wherein, At least one of the relay service code (RSC1) in the request message (M) and the transmission request message (M'), the identifier of the mobile device, and the identifier of the at least one relay device (UEx) is encrypted by the mobile device or protected for integrity by the message authentication code in order to indicate a protected indicator that the mobile device has selected the at least one relay device (UEx).

6. The cellular communication system according to claim 5, wherein, The relay device includes in the transmission request message (M') the identifier of the at least one relay device received from the mobile device in the request message (M).

7. The cellular communication system according to claim 5 or 6, wherein, The key used by the mobile device to encrypt at least one of the relay service code, the identifier of the mobile device, and the identifier of the at least one relay device, or the key used to determine the message authentication code, allows decryption by the network relay function (NRF) in the cellular network instead of by the relay device (UEx).

8. The cellular communication system according to claim 5 or 6, wherein, If the output of decrypting the received encrypted identifier reveals the identifier of the at least one relay device, or if the message authentication code forwarded by the at least one relay device and originating from the mobile device reveals that the identifier has not been manipulated using the information received in the transmission request message (M'), then the Network Relay Function (NRF) sends only a transmission response message (N') to the at least one relay device (UEx) containing PDU session information related to the encrypted relay service code RSC2 or RSC1.

9. The cellular communication system according to claim 8, wherein, The information provided by the encrypted identifier or message payload with the corresponding message authentication code in the transmission request message (M') is used by the cellular communication system (CCS) to perform additional authentication on whether to allow / authorize the at least one relay device (UEx) to act as a relay UE for the corresponding remote UE.

10. The cellular communication system according to any one of the preceding claims, wherein, The mobile device is configured to send a freshness parameter in the request message, the freshness parameter indicating whether the key used to encrypt elements of the request message has not been updated for a predetermined time, or indicating the time when the key was last updated.

11. The cellular communication system according to any of the preceding claims, wherein, The network relay function is configured to add a decryption relay service code to the transmission response message (N'), and the relay device is configured to use the decryption relay service code to obtain PDU session attributes.

12. The cellular communication system according to any of the preceding claims, wherein, The request message (M) and the response message (N) include a globally unique temporary identifier (GUTI), a temporary mobile subscriber identity (TMSI), or a subscription hidden identifier (SUCI).

13. The cellular communication system (CCS) according to any of the preceding claims, wherein, The request message (M) includes a relay service code (RSC1) associated with a set of PDU session attributes.

14. The cellular communication system (CCS) according to any one of the preceding claims, wherein, The mobile device is configured to include a random number in the request message (M), and the relay device is configured to maintain the random number used for tracking and discard any request message containing previously used random numbers or abort the setup process.

15. The cellular communication system (CCS) according to any of the preceding claims, wherein, The mobile device is configured to include a random number in the request message (M), and the relay device is configured to forward the random number in the transmission request message (M'), and the relay function is configured to keep track of the random number used and discard any transmission request message containing previously used random numbers or abort the setup process.

16. The cellular communication system according to any of the preceding claims, wherein, The mobile device includes a non-volatile storage unit (116) arranged to store a set of relay service codes supported by the mobile device, each relay service code being associatable with a set of PDU session attributes. The mobile device is also arranged to store a set of relay service codes supported by the mobile device, each relay service code being associatable with a set of PDU session attributes. The relay device includes a non-volatile storage unit (123) arranged to store data supported by the relay device. The network relay function is further configured to determine a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message (M'), wherein the different relay service code (RSC2') is selected from the set of the backup relay service codes available in the relay device.

17. A mobile device (110) arranged for use in a cellular communication system according to claim 1, comprising: A transceiver (111), arranged for wireless communication in the cellular network (130), and arranged to store a set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes, and A connection processor (112) is arranged to manage connections to the cellular network, the connection processor providing relay functionality (116) for managing at least one indirect connection. The relay function is configured to at least: As part of the setup process, a request message (M) is sent to at least one relay device (UEx), the request message including a relay service code (RSC1) associated with a set of PDU session attributes, and also including an encrypted identifier of the at least one relay device (UEx), and further including an encrypted identifier of the mobile device, the identifier being encrypted using a key that allows the identifier to be decrypted by the network relay function (NRF) in the cellular network; A response message (N) is received from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2), the encrypted relay service code (RSC2) being encrypted by the network relay function (NRF) in the cellular network using a key that allows the encrypted relay service code to be decrypted by the mobile device rather than the relay device; The encrypted relay service code (RSC2) is decrypted, and the decrypted relay service code (RSC2') is inserted into the subsequent discovery and connection setup message instead of RSC1, thereby associating RSC2' with the same set of PDU session attributes as RSC1.

18. A mobile device (110) arranged for use in a cellular communication system according to claim 3, comprising: A transceiver (111), arranged for wireless communication in the cellular network (130), and arranged to store a set of relay service codes supported by the mobile device, each relay service code being associated with a set of PDU session attributes, and A connection processor (112) is arranged to manage connections to the cellular network, the connection processor providing relay functionality (116) for managing at least one indirect connection. The relay function is configured to at least: As part of the setup process, a request message (M) is sent to at least one relay device (UEx), the request message including a relay service code (RSC1), and also including an identifier of the at least one relay device (UEx), an identifier of the mobile device, and a message authentication code; A response message (N) is received from the at least one relay device (UEx), the response message including an encrypted relay service code (RSC2), the encrypted relay service code (RSC2) being encrypted by the network relay function (NRF) in the cellular network using a key that allows the encrypted relay service code to be decrypted by the mobile device rather than the relay device; The encrypted relay service code (RSC2) is decrypted, and the decrypted relay service code (RSC2') is inserted into the subsequent discovery and connection setup message instead of RSC1, thereby associating RSC2' with the same set of PDU session attributes as RSC1.

19. The mobile device according to claim 18, wherein, The key is used to encrypt at least one of the following: the relay service code, the identifier of the mobile device, and the identifier of the at least one relay device, or the key is used to determine the message authentication code that allows decryption by the network relay function (NRF) in the cellular network rather than by the relay device (UEx).

20. The mobile device according to any one of claims 17-19, wherein, The mobile device selects a different Layer 2 identifier for the request message (M) from at least the most recently used Layer 2 identifier used in previous messages sent from the mobile device to the relay device.

21. The mobile device according to any one of claims 17-20, wherein, The mobile device is configured to send a freshness parameter in the request message, the freshness parameter indicating whether the key used to encrypt elements of the request message has not been updated for a predetermined time, or indicating the time when the key was last updated.

22. The mobile device according to any one of claims 17-21, wherein, The mobile device is configured to include a globally unique temporary identifier (GUTI), a temporary mobile subscriber identity (TMSI), or a subscription hidden identifier (SUCI) in the request message (M).

23. The mobile device according to any one of claims 17-22, wherein, The mobile device is configured to include a random number in the request message (M).

24. The mobile device according to any one of claims 17-23, wherein, The mobile device is configured to send a freshness parameter in the request message (M), the freshness parameter indicating whether the key used to encrypt the elements of the request message has not been updated for a predetermined time, or indicating the time when the key was last updated.

25. A network relay entity (140) providing network relay functionality (NRF) for use in a cellular communication system according to claim 1, said network relay entity being arranged as follows: Receive at least one transmission request message (M') from the relay device, the transmission request message (M') including a relay service code (RSC1) and an encrypted identifier of the mobile device that has sent the relay service code (RSC1) to the relay device; Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message (M'); The different relay service code (RSC2') is encrypted using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2). Send a transmission response message (N') including the encrypted relay service code (RSC2) to the relay device.

26. The network relay entity according to claim 25, wherein, Select the different relay service code (RSC2') to be used from the set of available alternative relay service codes in the relay device to replace the relay service code (RSC1).

27. A network relay entity (140) providing network relay functionality (NRF) for use in a cellular communication system according to claim 3, said network relay entity being arranged as follows: Receive at least one transmission request message (M') from the relay device, the transmission request message (M') including a relay service code (RSC1) and an identifier of the mobile device that has sent the relay service code to the relay device, as well as a message authentication code; The message authentication code is checked to verify whether the relay service code and the identifier of the mobile device have not been manipulated. Determine the different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the transmission request message (M'), wherein, The different relay service code (RSC2') is selected from the set of available backup relay service codes or new relay service codes in the relay equipment; The different relay service code (RSC2') is encrypted using a key that allows the different relay service code (RSC2') to be decrypted by the mobile device rather than the relay device, thereby obtaining the encrypted relay service code (RSC2). Send a transmission response message (N') including the encrypted relay service code (RSC2) to the relay device.

28. The network relay entity according to any one of claims 25-27, wherein, The network relay function is configured to add a decryption relay service code to the transmission response message (N'), and the relay device is configured to use the decryption relay service code to obtain PDU session attributes.

29. The network relay entity according to any one of claims 25-28, wherein, The network relay function is configured to include a new encrypted Globally Unique Temporary Identifier (GUTI), Temporary Mobile Subscriber Identity (TMSI), or Subscription Hidden Identifier (SUCI) in the transmission response message (N').

30. A relay device (120) arranged for communication in a cellular network according to claim 1, and comprising: A relay processor (122) is configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network. The relay processor is configured as follows: As part of the setup process, the request message (M) is received from the mobile device; After receiving the request message (M), a transmission request message (M') is sent to the cellular communication system according to the request message (M), the transmission request message (M') including at least one of the encrypted identifiers received from the mobile device in the request message (M) and the relay service code (RSC1); Receive a transmission response message (N') from the cellular communication system, the transmission response message (N') containing the Encrypted Relay Service Code (RSC2); After receiving the transmission response message (N'), a response message (N) containing the encrypted relay service code (RSC2) is sent to the mobile device based on the transmission response message.

31. A relay device (120) arranged for communication in a cellular network according to claim 3, and comprising: A relay processor (122) is configured to manage the communications within the cellular network and to manage the indirect connection between the mobile device and the cellular network. The relay processor is configured as follows: A collection of code for storing backup relay services; As part of the setup process, the request message (M) is received from the mobile device; After receiving the request message (M), a transmission request message (M') is sent to the cellular communication system according to the request message (M), the transmission request message (M') including the relay service code (RSC1), the message authentication code and the identifier of the mobile device received from the mobile device in the request message (M); Receive a transmission response message (N') from the cellular communication system, the transmission response message (N') containing the Encrypted Relay Service Code (RSC2); After receiving the transmission response message (N'), a response message (N) containing the encrypted relay service code (RSC2) is sent to the mobile device based on the transmission response message.

32. The relay device according to claim 30 or 31, wherein, The relay device is configured to forward any random number or freshness parameter received in the request message (M) in the transmission request message (M').

33. The relay device according to any one of claims 30-32, wherein, The relay device is configured to maintain the random number used for tracking and discard any request messages containing previously used random numbers or abort the setup process.

Images