Relay selection privacy in sliced ​​cellular networks

Abstract

This provides an efficient mechanism to avoid tracking of privacy-sensitive PDU session information and relay service code by relay UEs. [Solution] The cellular communication system supports a network relay function (NRF) for managing indirect connections. The mobile device sends a request message containing relay service code 1 (RSC1) to the relay device during the setup procedure. The receiving relay device sends a forwarding request message containing RSC1 to the cellular communication system. The NRF receives the forwarding request message, determines which RSC2' to use instead of the requested RSC1, encrypts RSC2' so that it can be decrypted by the mobile device but not by the relay device to generate RSC2, and sends a forwarding response message containing RSC2 to the relay device.

Description

Technical Field

[0001] The present invention relates to the field of well-known 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) including a plurality of cellular base stations (BS). A cellular communication system may provide a cellular network that supports network slicing and indirect connection, and a mobile device may be connected to the core network via a base station. Access to the network is managed by a so-called provider or mobile network operator (MNO). A network slice provides a logical network using the shared physical infrastructure of the cellular communication system. Indirect connection provides data transfer between a mobile device and a cellular communication system via at least one relay device.

Background Art

[0002] Mobile devices that communicate using cellular wireless communication standards are continuously subject to further development, for example, in accordance with the 3GPP (registered trademark) 5G specifications. Wireless devices can be of various types, such as mobile phones, vehicles for V2V (vehicle-to-vehicle) or more general V2X (vehicle-to-everything communication), Internet of Things (IoT) devices, medical (emergency) diagnostic and treatment devices, virtual reality (VR) headsets, and the like. The characteristics of such mobile devices vary greatly with respect to, for example, low-power operation, acceptable maximum latency, required bandwidth, and mobility. Therefore, the concept of network slicing is defined in 5G systems and radio access network specifications ([23.501], [38.300], [Elayoubi] reference).

[0003] A network slice can be viewed as an isolated "virtual 5G network" running on a common, shared hardware / software platform. While platform components can be shared across multiple slices, each slice operates independently. Each slice can provide performance, service levels, policies, and functionality optimally tailored to a specific use case or application domain. Slices can also be operated as a service by a network operator different from the network operator that owns the hardware / software platform. Slicing can be performed on the core network (CN), the radio access network (RAN), or both.

[0004] A mobile device, commonly referred to as a User Equipment (UE), can belong to multiple slices simultaneously. A UE can establish multiple Protocol Data Unit (PDU) sessions with a CN, each session operating within a specific slice. A detailed explanation of network slicing can be found in [PavelShulgin]. The UE also encompasses cases where the UE is a fixed device. User equipment can be any device directly used by an end user. This includes both non-fixed and fixed devices. Another characteristic of a UE is that it typically communicates with a base station using a 3GPP® Uu interface, typically has its own mobile contract and its own SIM card, and is identifiable by its IMSI.

[0005] An example of a session request operating within a slice is described in [EventHelix]. Figure 1 shows an excerpt from a diagram illustrating a user device (UE) requesting a slice. The UE sends the requested Network Slice Selection Assistance Information (NSSAI) in the 21:RRCSetupComplete message, and the base station (gNB) forwards this information in the 24:NGAP Initial UE message that the base station sends. The term 5GC is used to represent the 5G core network.

[0006] In the 3GPP® specification for 4G, the ProSe (Proximity Services) function (see [23.303] and [24.334]) is defined as enabling connectivity for cellular user equipment (UEs) that are temporarily outside the coverage of a cellular network base station (eNB). This particular function is called ProSe UE-to-network relay, or simply relay UE. A relay UE is an UE that helps an OoC (out-of-coverage) UE communicate with an eNB by relaying application and network traffic bidirectionally between the OoC and the eNB. Local communication between the relay UE and the OoC UE is called D2D (device-to-device) communication or sidelink (also known as PC5) communication (see [23.303] and [24.334]). Once the relay relationship is established, the OoC-UE returns into coverage via the relay UE and acts as a “remote UE”. This situation differs from the usual direct network connection, meaning the remote UE has an indirect connection to the 4G core network.

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

[0008] Various legacy solutions, including relays, related to 3GPP® work are known in this technical field (each number below represents a separate topic).

[0009] US20180092017A1, US9826460, US10212651B2, and US20160212721A1 describe selecting one relay from multiple candidate relays based on signal strength or advertised group ID.

[0010] US10177834B2 states that the eNB broadcasts bandwidth requirements for relaying within its cell, and relay-enabled devices automatically use this to determine if the device meets the requirements and becomes a relay.

[0011] US20160227518A1 states that the eNB determines that the UE is OoC and that it needs to send some information to that UE (via relay) to help that UE reconnect.

[0012] US20160227518A1 describes a relay-enabled UE that decides to become a relay only if it has sufficient connectivity, battery capacity, or the appropriate service type / context.

[0013] US9445352B2 states that because an OoC UE requires relaying, it sends a D2D message to a neighboring device requesting someone to act as relay, and that one or more UEs will act as relays.

[0014] WO2018083381A1 describes how the OoC UE requests configuration information from the peer UE via sidelink / D2D to reconnect to the network via relay.

[0015] US20180035448A1 states that the eNB transmits sidelink scheduling permission information, including specific scheduling for OoC UEs. This information is received by in-coverage UEs and retransmitted by these UEs to the OoC UEs.

[0016] US9565573B2 describes a situation where an In-Coverage UE sends a D2D signal, to which an OoC UE may respond with an indication that coverage is needed. The In-Coverage UE then transmits the received indication to the network. Optionally, the network can use this indication to instruct the In-Coverage UE to relay.

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

[0018] This invention relates to the privacy aspects of relay discovery and selection of relay UEs (particularly for out-of-coverage UEs) in sliced ​​cellular networks. In the ProSe framework, so-called relay service codes are used for the discovery of relay UEs (see [23.303] and [24.334]). Relay service codes can be used by remote UEs during the discovery of relay UEs. For example, using a so-called "Model A" discovery mechanism, a relay UE can broadcast information that it supports a particular set of relay service codes. Each relay service code may correspond to a set of PDU session attributes, and a remote UE can use the discovered relay UEs and the relay service codes broadcast by the remote UE to find relay UEs that match one or more relay service codes known to the remote UE that match a set of PDU session parameters. Thus, the remote UE can use this to select from among several possible relay UEs the relay UE that is best suited to be used as a relay for the PDU session that the remote UE wishes to bring up. Similarly, using the so-called "Model B" discovery mechanism, a remote UE may request, as part of the discovery request, a specific set of relay service codes that the relay UE will use for matching and responding if the relay UE supports one or more of the requested relay service codes. It should be noted that open discovery and connection request messages via PC5 are not encrypted, meaning that other nearby devices can monitor and intercept these messages.

[0019] When UE-based relaying occurs at Layer 3 (i.e., the IP layer), the relay UE needs to receive information about how it will initiate a PDU session on behalf of the remote UE at some point before it can initiate an indirect connection between the remote UE and the cellular network via the relay UE. This leads to privacy issues because the PDU session information includes information such as the specific network slice or DNN (Data Network Name) that the remote UE wishes to connect to. This could reveal that the remote UE is, for example, from a law enforcement officer connecting to a DNN reserved for a particular police department, or a slice dedicated to police communications. Relay UEs are typically authorized by the network to function as relay devices and may have to go through several review processes. However, this does not mean that a relay UE can track a remote UE by simply tracking all this sensitive privacy information after the remote UE has been disconnected and by tracking the relay service code that the remote UE may use to find and / or connect to another relay UE. Nor does it mean that a relay UE can track other nearby remote UEs using the same relay service code. One possible mitigation measure is to make the relay service code's lifecycle very short (e.g., changing it every few minutes). However, updating all potential remote UEs and relay UEs with this new relay service code would generate a massive amount of traffic. Updating this information requires each UE to be up and within the coverage of the gNB operated by the core network. This can be extremely difficult to achieve, given that many UEs may be asleep or out of coverage. Remote UEs, in particular, are typically out of coverage and otherwise do not require relaying to access the network. Therefore, such a mechanism is highly inefficient. [Overview of the Initiative]

[0020] Next-generation cellular communication networks such as 5G need to incorporate ProSe relay or similar technologies for UE-based relaying. However, the use of network slices introduced by 5G brings new requirements and challenges when UE-based relaying needs to be considered, such as the following: • The UE must be able to connect to one or more required and / or preferred 5G network slice instances via relay UEs, and therefore needs to know which neighboring relay UEs can and cannot do this. • Multiple candidate relay UEs may exist within the wireless range of a UE, but relay UEs may move out of range, and new relay UEs may appear within range. • The network slice instance required and / or preferred by the UE may differ from the slice to which the optimal relay UE candidate is currently connected. • The UE (Unified User) may be the OoC (Out of Cost) at the point where a choice must be made. Relay UEs may be resource-constrained devices and therefore may not be able to provide the expected / required QoS for a particular network slice. A relay UE may have one or more PDU connections of its own (i.e., it is usually a UE owned by someone else who wants access to, for example, the internet), and the resources left to support indirect network communication for another UE may be very limited. • The network slice required or preferred by the UE may use a different frequency band than the one currently being used by the relay UE candidate. A UE may participate in two or more network slices, and each slice may have its own requirements regarding what constitutes the optimal relay and corresponding optimal network path for indirect connectivity. Therefore, it may be necessary to select two (or more) relay UEs as the optimal solution for performing relaying. • Candidate relay UEs are typically a priori unknown and not trusted by the UE. The initial lack of trust between parties creates mutual security risks, and using insecure procedures to connect to the relay UE also poses security risks. For example, multiple UEs attempting to initiate a “relay” / “remote” relationship may have never encountered each other before. This can frequently occur, for example, when 1) mobile cellular IoT devices are moving around, or 2) mobile or stationary cellular IoT devices are deployed and first activated in a new environment. - Candidate relay UEs may not be approved and may lack the necessary credentials to connect to and / or exchange data with the network slice, and / or participate in relay connections to the network slice. This is especially true for private network slices that can only be used by UEs belonging to a predefined group.

[0021] A further issue is the potential privacy risk. For example, a candidate relay UE (and other remote UEs) may need to gain access to, or be provided with, network slices and information about the DNNs to which the remote UE is connecting (or attempting to connect). DNN identifiers (similar to URIs, which may include, for example, the name of a company, organization, or specific facility) or slice identifiers are typically very static and could potentially expose privacy-sensitive information or link it to a specific company / organization or other entity. This leads to privacy issues, for example, that a relay UE could enable the remote UE to determine what information the remote UE is interested in, and which DNNs the remote UE is sending and receiving data with. It could also enable the relay UE to track the remote UE after the connection with the relay UE has been severed, or even if there is no connection between the two at all. In particular, with Layer 3 relays (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 at some point needs to obtain information about that PDU session.

[0022] In general, the exposure of information about the slices and DNNs that a UE uses or wishes to use for relay operations (i.e., for relay selection and / or setting up relay connections to the network) is privacy sensitive because it could reveal that the UE belongs to a special membership group, such as police / law enforcement / customs, or is linked to, for example, a medical facility.

[0023] One potential problem is that remote UEs and relay UEs could be supplied with a set of PDU session parameters associated with each relay service code they support, for example, by providing one or more S-NSSAI or DNN values ​​associated with a particular relay service code. Relay service codes can be used during the discovery of relay UEs. Given that remote UEs need to be able to operate outside of coverage, relay service codes are expected to be very static and have a considerably long lifespan (i.e., probably in hours rather than seconds). Pre-configuring a large set of relay UE or remote UE devices with persistent and / or relatively static information that can be associated with slicing and / or DNN information (such as relay service codes) could allow these devices to perform various privacy attacks, for example, by linking remote UEs to relatively static or persistent information, potentially allowing the identification of remote UEs to be traced and tracked. In particular, remote UEs and relay UEs are end-user devices and cannot be fully trusted (unlike core network functions or base stations, etc.).

[0024] Some of these considerations also apply to access to a NPN (Non-Public Network) (see [23.501]). This concept has some similarities to the network slices introduced in 5G. A NPN is a dedicated network for a limited set of users and can operate as a separate mobile core network or on the PLMN (Public Land Mobile Network) of a mobile network operator, whereby the NPN is typically deployed as a slice within the PLMN and / or as a closed access group. In addition to the fact that a NPN can be implemented over an existing hardware / software infrastructure using network slices, a NPN may also have one or more slices of its own, especially when the NPN is operated as a separate stand-alone network. Similar to the case of slices, the relaying of traffic targeted at a specific NPN can also be restricted to only those remote UEs and relay UEs that are authorized to have access to that NPN. Also, a NPN may have some requirements regarding minimum QoS, service area limitations, and other aspects similar to network slices. Furthermore, other dynamic aspects need to be considered to evaluate whether a relay UE is suitable to operate as a relay for the data connection between a remote UE and a NPN. In the remainder of this document, the term network slice also refers to non-public networks.

[0025] An object of the present invention is to provide the following in a cellular communication system. An efficient mechanism for avoiding the use by a relay UE (and other remote UEs) of privacy-sensitive PDU session information and a relatively static relay service code for tracking a remote UE.

[0026] For this purpose, a device and a method as described in the appended claims are provided. According to one aspect of the present invention, a cellular communication system, a mobile device, a network relay entity, and a relay device as described in the appended claims are provided. According to another aspect of the present invention, a computer program product that is downloadable from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium, the computer program product including program code instructions for implementing the above method when executed on a computer, is provided.

[0027] A cellular communication system (CCS) includes a radio access network (RAN) including a plurality of cellular base stations (BSs) and a core network (CN). The cellular communication system provides a cellular network that supports 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 transfer between a mobile device and the cellular communication system via at least one relay device that 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 that provides a network relay function (NRF) for managing the indirect connection.

[0028] A mobile device may include a transceiver configured for wireless communication within a cellular network and a connection processor configured to manage the connection to the cellular network, the connection processor providing a relay function for managing at least one indirect connection. The relay function is: Sending a request message to at least one relay device (UEX), wherein the request message includes a relay service code (RSC1), an identifier for at least one relay device (UEX), and an identifier for a mobile device. Receiving a response message from at least one relay device (UEx), the response message containing an encrypted relay service code (RSC2), which is encrypted by the network relay function (NRF) in the cellular network using a key that can be decrypted by a mobile device but not by a relay device, is also included. The method may be configured to decrypt the encrypted relay service code (RSC2) and insert the decrypted relay service code (RSC2') in place of RSC1 in subsequent discovery and connection setup messages, wherein RSC2' is associated with the same set of PDU session attributes as RSC1.

[0029] In one embodiment, the mobile device may include a non-volatile storage unit that stores a set of relay service codes supported by the mobile device, each of which may be associated with a set of PDU session attributes.

[0030] A relay device may comprise a communication unit configured for communication in a cellular network, and a relay processor configured to manage communication in the cellular network and to manage the indirect connection between a mobile device and the cellular network. The relay processor Save a set of spare relay service codes. Receive request messages from mobile devices, After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, and the forwarding request message (N) includes the relay service code RSC1 and the identifier of the mobile device received from the mobile device in the request message. A forwarding response message is received from the cellular communication system, and the forwarding response message includes an encrypted relay service code (RSC2). After receiving a forwarding response message, the system may be configured to send a response message containing an encrypted relay service code (RSC2) to the mobile device, depending on the forwarding response message.

[0031] The relay device may include a non-volatile memory unit that stores a set of relay service codes, including a set of spare relay service codes, which are supported by the mobile device.

[0032] The network relay function is The relay device receives at least one forwarding request message, and the forwarding request message includes the relay service code (RSC1) and the mobile device identifier. The system determines a different relay service code (RSC2') to use in place of the relay service code (RSC1) received in the forwarding request message. The different relay service code (RSC2') is selected from one or more spare relay service codes available within the relay device, or from a new relay service code. A different relay service code (RSC2') is encrypted using a key that can be decrypted by a mobile device but not by a relay device, thereby generating an encrypted relay service code (RSC2). It may be configured to send a forwarding response message containing an encrypted relay service code (RSC2) to the relay device.

[0033] Preferably, the discovery message and connection setup message themselves are not encrypted or authenticated, and even if the relay service code is sent in plain text, eavesdroppers (including relay devices and other remote UEs) cannot track the mobile device using the relay service code RSC1 after disconnection. Furthermore, this is done efficiently because only the relay service code used by the remote UE (i.e., mobile device UE0) needs to be updated, and it is not necessary to update all relay service codes in all other remote UEs and / or relay UEs. Moreover, this works even if the remote UE is outside the coverage of the base station of the network.

[0034] Furthermore, advantageously, this procedure can be combined with a procedure to verify the network's authority to set up a relay connection for a specific relay service code and / or to set up a PDU session using PDU session parameters associated with the relay service code. Additionally / or, this procedure can be combined with a procedure to request a security key or privacy-sensitive PDU session parameters (e.g., slice identifiers NSSAI, DNN) from the network to set up such a relay connection. This allows for faster and more secure connection setup.

[0035] Furthermore, information regarding slices, DNNs and private networks, as well as other PDU session-related parameters, may be considered privacy sensitive. This could lead to unwanted tracking of mobile devices and the exposure of operator deployment information (e.g., slices and NPNs supported in the core network). In 5G, to prevent privacy leaks of slice information, slice information may only be sent to the UE later in the process during CN attachment / authentication, after some initial security context has been established. Therefore, slice information (or only encrypted or temporary slice information) is not sent at any point earlier in the process. Additionally, relay UEs may not have access to, be authorized to access, or be able to support slice characteristics that the remote UE wishes to use (e.g., required QoS or frequency bandwidth). Therefore, by using NRF to provide PDU session parameters only to relay UEs selected by the remote UE (and, in some cases, only after verifying that the relay UE has the authority to set up relay connectivity to the network on behalf of the remote UE and / or to set up a PDU session with the PDU session parameters), unnecessary information regarding PDU session parameters does not need to be stored in advance on the relay UE or on other unselected relay UEs, which are typically untrusted end-user devices.

[0036] A cellular communication system is provided comprising a radio access network and a core network, the cellular communication system providing a cellular network that supports indirect connections, each indirect connection providing data transfer between a mobile device and the cellular communication system via at least one relay device which is a mobile device that communicates with the radio access network and is capable of supporting indirect connections, the cellular communication system including at least one network relay entity that provides network relay functionality (NRF) for managing indirect connections, and the mobile device is It includes a connectivity processor that manages connections to a cellular network, the connectivity processor provides a relay function for managing at least one indirect connection, and the relay function is As part of the setup procedure, a request message is sent to at least one relay device (UEx), the request message includes the relay service code (RSC1) and the encrypted identifier of at least one relay device (UEx), and further includes the encrypted identifier of the mobile device. Receiving a response message containing an encrypted relay service code (RSC2) from at least one relay device (UEx), The method involves decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of RSC1 in subsequent discovery and connection setup messages, wherein RSC2' is associated with the same set of PDU session attributes as RSC1, and at least performing the following: Relay devices are A communication unit that communicates in a cellular network (130), It includes a relay processor that manages communications within a cellular network and also manages indirect connections between mobile devices and the cellular network, The relay processor is Receive request messages from mobile devices, After receiving a request message, a forwarding request message is sent to the cellular communication system in response to the request message, and the forwarding request message includes the relay service code RSC1 and at least one of the encrypted identifiers received from the mobile device within the request message. A forwarding response message is received from the cellular communication system, and the forwarding response message includes an encrypted relay service code (RSC2). After receiving a forwarding response message, a response message containing an encrypted relay service code (RSC2) is sent to the mobile device in response to the forwarding response message. The network relay function is The relay device receives at least one forwarding request message, the forwarding request message includes the relay service code (RSC1) and at least one of the encrypted identifiers of the mobile device and the relay device. Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message. A different relay service code (RSC2') is encrypted using a key that can be decrypted by a mobile device but not by a relay device, thereby generating an encrypted relay service code (RSC2). It may be configured to send a forwarding response message containing an encrypted relay service code (RSC2) to the relay device.

[0037] One aspect of this is that the network relay function encrypts the identifiers of mobile devices and / or relay devices using a key that can be decrypted by the network relay function (NRF) within the cellular network, but not by the relay device itself.

[0038] Alternatively, a cellular communication system (CCS) is provided, comprising a radio access network (RAN) and a core network (CN) including multiple cellular base stations (BS), wherein the cellular communication system provides a cellular network that supports indirect connections, and each indirect connection provides data transfer between a mobile device and the cellular communication system via at least one relay device which is a mobile device that communicates with the radio access network and is capable of supporting indirect connections. The cellular communication system includes at least one network relay entity (140) that provides a network relay function (NRF) for managing indirect connections, and the mobile device is It includes a connectivity processor that manages connections to a cellular network, the connectivity processor provides a relay function for managing at least one indirect connection, and the relay function is As part of the setup procedure, a request message is sent to at least one relay device (UEx), the request message includes a relay service code (RSC1), an identifier for at least one relay device (UEx), an identifier for a mobile device, and a message authentication code. Receiving a response message containing an encrypted relay service code (RSC2) from at least one relay device (UEx), The method involves decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of RSC1 in subsequent discovery and connection setup messages, wherein RSC2' is associated with the same set of PDU session attributes as RSC1, and at least performing the following: Relay devices are A communication unit that communicates in a cellular network, It includes a relay processor that manages communications within a cellular network and also manages indirect connections between mobile devices and the cellular network, The relay processor is Receive request messages from mobile devices, After receiving a request message, a forwarding request message is sent to the cellular communication system in response to the request message. The forwarding request message includes the relay service code RSC1 and the message authentication code and mobile device identifier received from the mobile device within the request message. A forwarding response message containing an encrypted relay service code (RSC2) is received from the cellular communication system. After receiving a forwarding response message, a response message containing an encrypted relay service code (RSC2) is sent to the mobile device in response to the forwarding response message. The network relay function is The relay device receives at least one forwarding request message, the forwarding request message includes the relay service code (RSC1), the mobile device identifier, and the message authentication code. Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message. A different relay service code (RSC2') is encrypted using a key that can be decrypted by a mobile device but not by a relay device, thereby generating an encrypted relay service code (RSC2). It may be configured to send a forwarding response message containing an encrypted relay service code (RSC2) to the relay device.

[0039] On one hand, the relay processor stores a set of spare relay service codes, and the network relay function is configured to select a different relay service code (RSC2') from the set of spare relay service codes available within the relay device, or from a new relay service code.

[0040] In one aspect, at least one of the following in the request message (M) and forwarding request message—the relay service code (RSC1), the mobile device identifier, and the identifier of at least one relay device (UEx)—is encrypted by the mobile device or secured by a message authentication code to represent a protected indicator that the mobile device has selected at least one relay device (UEx).

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

[0042] On one hand, a key used by a mobile device to encrypt at least one of the relay service code, mobile identifier, and identifier of at least one relay device, or a key used to determine the message authentication code, allows decryption by the network relay function (NRF) within the cellular network, but does not allow decryption by the relay device (UEx).

[0043] On one hand, the Network Relay Function (NRF) sends a forwarding response message to at least one relay device (UEx) containing PDU session information associated with an encrypted relay service code RSC2 or RSC1, using the information received in the forwarding request message, only if the output of decrypting the received encrypted identifier represents the identifier of at least one relay device, or if a message authentication code originating from a mobile device, forwarded by at least one relay device, indicates that the identifier has not been manipulated.

[0044] On one hand, information provided by a message payload containing an encrypted identifier or message authentication code within a forwarding request message is used by the cellular communications system (CCS) to perform additional verification to determine whether at least one relay device (UEx) is authorized / authorized to act as a relay UE for a remote UE.

[0045] On one hand, mobile devices send freshness parameters within request messages, which indicate that the key used to encrypt the elements of the request message has not been updated for a certain amount of time, or indicate the time when the key was last updated.

[0046] On one hand, the Network Relay Function (NRF) adds the decoded relay service code to the forwarding response message, and the relay device uses the decoded relay service code to retrieve the PDU session attribute.

[0047] On one hand, request messages (and response messages) include GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier).

[0048] On one hand, the request message includes a relay service code (RSC1) associated with a set of PDU session attributes.

[0049] On one hand, mobile devices include a nonce in the request message (M), and relay devices track the nonce that has been used and either discard a request message containing a previously used nonce or abort the setup procedure.

[0050] On one hand, the mobile device includes a nonce in the request message (M), the relay device forwards the nonce in the forwarding request message (N), the relay function tracks the nonce that has been used and either discards a request message containing a previously used nonce or aborts the setup procedure.

[0051] In one aspect, the mobile device includes a non-volatile storage unit that stores a set of relay service codes supported by the mobile device and each of which may be associated with a set of PDU session attributes, the relay device includes a non-volatile storage unit that stores a set of relay service codes, including a set of spare relay service codes, supported by the relay device, the relay processor of the relay device stores a set of spare relay service codes, and the network relay function determines a different relay service code (RSC2') to be used instead of the relay service code (RSC1) received in the forwarding request message, and the different relay service code (RSC2') is selected from a set of spare relay service codes available in the relay device.

[0052] A mobile device is provided that is configured for use in the above-mentioned cellular communication system, and the mobile device is A transceiver that performs wireless communication within a cellular network (130) and stores a set of relay service codes that are supported by a mobile device and can each be associated with a set of PDU session attributes, The system includes a connection processor that manages connections to a cellular network, the connection processor providing a relay function (116) for managing at least one indirect connection, and the relay function Sending a request message to at least one relay device (UEX), the request message includes a relay service code (RSC1) associated with a set of PDU session attributes, an encrypted identifier of at least one relay device (UEX), and an encrypted identifier of a mobile device, the identifier being encrypted using a key that can be decrypted by a network relay function (NRF) in a cellular network, Receiving a response message from at least one relay device (UEx), the response message containing an encrypted relay service code (RSC2), which is encrypted by the network relay function (NRF) in the cellular network using a key that can be decrypted by a mobile device but not by a relay device, is also included. The method involves decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of RSC1 in subsequent discovery and connection setup messages, wherein RSC2' is associated with the same set of PDU session attributes as RSC1, and at least performing the following:

[0053] Alternatively, a mobile device (110) configured for use in the cellular communication system described above is provided, and the mobile device is A transceiver that performs wireless communication within a cellular network and stores a set of relay service codes that are supported by mobile devices and can each be associated with a set of PDU session attributes, It includes a connection processor that manages connections to a cellular network, the connection processor providing a relay function for managing at least one indirect connection, and the relay function is Sending a request message to at least one relay device (UEx), the request message including a relay service code (RSC1), an identifier for at least one relay device (UEx), an identifier for a mobile device, and a message authentication code; Receiving a response message from at least one relay device (UEx), the response message containing an encrypted relay service code (RSC2), which is encrypted by the network relay function (NRF) in the cellular network using a key that can be decrypted by a mobile device but not by a relay device, is also included. The method involves decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of RSC1 in subsequent discovery and connection setup messages, wherein RSC2' is associated with the same set of PDU session attributes as RSC1, and at least performing the following:

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

[0055] In one aspect, the mobile device selects for the request message (M) a Layer 2 identifier that is at least different from the Layer 2 identifier last used in a previous message sent from the mobile device to the relay device. The previous message may be part of a discovery message.

[0056] On one hand, mobile devices send freshness parameters within request messages, which indicate that the key used to encrypt the elements of the request message has not been updated for a certain amount of time, or indicate the time when the key was last updated.

[0057] On one hand, mobile devices include a GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier) ​​within the request message.

[0058] A network relay entity is provided that provides the network relay function (NRF) used in the above cellular communication system, and the network relay entity is: The relay device receives at least one forwarding request message, the forwarding request message includes the relay service code (RSC1) and the encrypted identifier of the mobile device that sent the relay service code (RSC1) to the relay device. Determine a different relay service code (RSC2') to use in place of the relay service code (RSC1) received in the forwarding request message. A different relay service code (RSC2') is encrypted using a key that can be decrypted by a mobile device but not by a relay device, thereby generating an encrypted relay service code (RSC2). It may be configured to send a forwarding response message containing an encrypted relay service code (RSC2) to the relay device.

[0059] In one aspect, the different relay service code (RSC2') used in place of the relay service code (RSC1) is selected from a set of spare relay service codes available in the relay device.

[0060] Alternatively, a network relay entity (140) is provided that provides a network relay function (NRF) used in the cellular communication system described above, and the network relay entity is The relay device receives at least one forwarding request message, the forwarding request message includes the relay service code (RSC1) and the identifier of the mobile device that sent the relay service code (RSC1) to the relay device. To verify that the relay service code and mobile device identifier have not been tampered with, check the message authentication code. The system determines a different relay service code (RSC2') to use in place of the relay service code (RSC1) received in the forwarding request message. The different relay service code (RSC2') is selected from either a set of spare relay service codes available in the relay device or from a new relay service code. A different relay service code (RSC2') is encrypted using a key that can be decrypted by a mobile device but not by a relay device, thereby generating an encrypted relay service code (RSC2). It is configured to send a forwarding response message containing an encrypted relay service code (RSC2) to the relay device.

[0061] On one hand, the network relay function adds the decoded relay service code to the forwarding response message, and the relay device uses the decoded relay service code to retrieve the PDU session attribute.

[0062] In one aspect, the network relay function includes a newly encoded GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier) ​​within the forwarding request message (N').

[0063] A relay device is provided that communicates within the above cellular network, and the relay device is It includes a relay processor that manages communications within a cellular network and also manages indirect connections between mobile devices and the cellular network. The relay processor is As part of the setup procedure, a request message is received from the mobile device. After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, and the forwarding request message includes the relay service code RSC1 and at least one of the encrypted identifiers received from the mobile device in message M. A forwarding response message is received from the cellular communication system, and the forwarding response message includes an encrypted relay service code (RSC2). After receiving a forwarding response message, the system is configured to send a response message containing an encrypted relay service code (RSC2) to the mobile device, depending on the forwarding response message.

[0064] Alternatively, a relay device that communicates in the cellular network is provided, and the relay device is It includes a relay processor that manages communications within a cellular network and also manages indirect connections between mobile devices and the cellular network. The relay processor is Save a set of spare relay service codes. As part of the setup procedure, a request message is received from the mobile device. After receiving a request message, a forwarding request message is sent to the cellular communication system in response to the request message. The forwarding request message includes the relay service code RSC1 and the message authentication code and mobile device identifier received from the mobile device within the request message. A forwarding response message is received from the cellular communication system, and the forwarding response message includes an encrypted relay service code (RSC2). After receiving a forwarding response message, the system is configured to send a response message containing an encrypted relay service code (RSC2) to the mobile device, depending on the forwarding response message.

[0065] In one aspect, the relay device forwards the nonce or freshness parameter received in the request message (M) in the forwarding request message (N).

[0066] On one hand, the relay device tracks the nonce used and either discards request messages containing previously used nonces or aborts the setup procedure.

[0067] The method according to the present invention may be implemented as a computer implementation method on a computer, on dedicated hardware, or as a combination thereof. Executable code for the method according to the present invention may be stored in a computer program product. Examples of computer program products include memory devices such as memory sticks, optical storage devices such as optical discs, integrated circuits, servers, and online software.

[0068] A non-temporary form of computer program product may include non-temporary program code means stored on a computer-readable medium to perform the method according to the present invention when executed on a computer. In one embodiment, the computer program includes computer program code means configured to perform all steps or stages of the method according to the present invention when the computer program is executed on a computer. Preferably, the computer program is embodied on a computer-readable medium. Also provided is a computer program product stored in a temporary and / or volatile computer-readable memory and / or microprocessor-executable medium that is downloadable from a network, wherein the computer program product includes program code instructions for performing the above method when executed on a computer.

[0069] Another aspect of the present invention provides a method for making a computer program downloadable in a temporary form. This aspect is used when the computer program is uploaded to, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and is available for download from such a store.

[0070] Other preferred embodiments of the device and method according to the present invention are presented in the appended claims, which are incorporated herein by reference.

[0071] The above and other aspects of the present invention will be further described and revealed in relation to embodiments described later as examples with reference to the following drawings. [Brief explanation of the drawing]

[0072] [Figure 1] Figure 1 shows an excerpt from a diagram illustrating a user device (UE) requesting a slice. [Figure 2]Figure 2 shows diagrams of single-hop (left) and multi-hop (right) communication using UE-based relay devices. [Figure 3] Figure 3 shows a mobile device, a relay device, a network relay entity, and a cellular communication network. [Figure 4] Figure 4 shows an example of an NRF support relay selection sequence diagram. [Figure 5] Figure 5 shows an example of a multi-hop relay topology for a moving UE. [Figure 6a] Figure 6a shows a computer-readable medium. [Figure 6b] Figure 6b shows a schematic diagram of the processor system. [Figure 7] Figure 7 shows an example of an NRF support relay selection sequence diagram according to one embodiment. [Figure 8] Figure 8 shows an example of a relay service code update sequence according to one embodiment. [Modes for carrying out the invention]

[0073] These diagrams are purely schematic and not drawn to scale. In the drawings, elements corresponding to those already described may be given the same reference number.

[0074] Figure 3 shows a mobile device, a relay device, a network relay entity, and a cellular communication network. In the cellular communication system 100, the mobile device 110 is configured for wireless communication on the cellular communication network 130. The mobile device may be, for example, a mobile phone, a wearable medical device, or an in-vehicle data communication unit. The cellular communication system (CCS) may include a radio access network (RAN) which includes a plurality of cellular base stations (BS) and a core network (CN). The cellular communication system provides a cellular network that supports network slicing and indirect connectivity.

[0075] Each network slice provides a logical network using the shared physical infrastructure of the cellular communication system. This is typically true even for non-public networks (NPNs), particularly NPNs operating on public networks. In the case of a standalone NPN, the logical network may be deployed as a separate mobile core network, operating a private small cell infrastructure. Sharing means that the physical infrastructure may be fully or partially shared. For example, some network functions of the first slice or NPN may be software running on a different computer than the network functions of the second slice or NPN, while RAN components may be fully shared between the two slices or NPNs. Also, the first slice or NPN may be allocated to a different frequency band than the second slice or NPN, while RAN components may 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 the network traffic associated with the slice is isolated from other network traffic. This is also true for standalone NPNs.

[0076] As explained at the beginning, cellular communication networks can become extended 5G networks.

[0077] Figure 1 schematically shows a network 130 for providing communication between a mobile device MOB-DEV110 and a relay device REL-DEV120. The core network may be managed by at least one telecommunications provider, for example, for subscriber database management and billing.

[0078] The network may also be coupled to a network relay entity 140 that provides a network relay function (NRF) for managing indirect connections. The network relay entity may be implemented on a processor system, which may be located, for example, on a core network, a wireless access network, or another server on the internet. The entity may be coupled to the network wirelessly and / or via wired or dedicated links.

[0079] A relay device may be a mobile device configured to communicate with a wireless access network and capable of supporting indirect connections for data exchange with mobile devices. Note the difference from the numerous indirect connections managed by the NRF. While the NRF may manage indirect connections for thousands of UEs, a relay device only manages indirect connections for mobile devices nearby.

[0080] The mobile device 110 may be configured for wireless communication with a network and includes a transceiver 111 configured for wireless communication and a connectivity processor 112 configured to control the mobile device and provide an interface to the user. The connectivity processor may be configured to manage connections to a cellular network and provide a relay function 116 for managing at least one indirect connection, as described below. The mobile device may be provided with a user interface 113, which includes, for example, a display and one or more user input elements 115. For example, the user input elements may include one or more touchscreens, various buttons, a mouse, or a touchpad. The buttons may be conventional physical buttons, touch sensors, or virtual buttons (e.g., buttons or icons on a touchscreen that are operated via a mouse). The user interface may be a remote user interface. The connectivity processor 112 may be coupled to non-volatile memory 116.

[0081] The relay device 120 may have a relay processor 122 configured to manage communications within a cellular network and to manage indirect connections to mobile devices as described below, and a communication unit 121 configured for wireless communication with the network. The relay processor 122 may be coupled to a non-volatile memory 123.

[0082] The relay functionality within a mobile device may be configured to perform the following: First, a request message (M) is sent to at least one relay device (UEx). The request message may include a request identifier (ID1) indicating the network slice that the mobile device is requesting access to. Next, at least one response message (N) is received from at least one relay device. The response message may include an indication of at least one slice available for relaying through at least one relay device to provide indirect connectivity. This indication may be defined explicitly (e.g., as part of an additional “slice relay information” field in response message N) or implicitly (e.g., message N is an affirmative response acknowledging that the requested slice can be relayed through each relay device). Then, depending on the response message, a relay device (UEy) is selected from among at least one relay devices that support the requested slice. The response message may also include information about any additional supported slices that its remote UE can select. If the remote UE is limited to only one slice, e.g., a private slice, or if there is only one available slice suitable for the UE, the selection effectively adopts such a single slice. If the selected slice is the same as the requested slice, the remote UE may select each relay UE that received the response and reuse the same D2D (device-to-device) connection (e.g., PC5) between the remote UE and the relay UE to set up an indirect connection to the network via the relay UE. If there is only one available relay UE suitable for that remote UE, the selection effectively adopts such a single relay UE. An indirect connection to the selected slice is then established through the selected relay UE, which may reuse the same D2D connection between the remote UE and the relay UE that was used to send the request message (M) and / or receive the response message (N).

[0083] The relay processor within a relay device may be configured to perform the following: First, a request message (M) is received from the mobile device. Next, in response to the request message, a forwarding request message (M') is sent to the cellular communication system. The forwarding request message indicates a request to exchange data with the mobile device over an indirect connection. The forwarding request message includes a request identifier (ID1). The forwarding request message may be the same as message M, or a message newly constructed by the relay device based on the information received in message M, or a message that encapsulates the contents of message M (e.g., as part of an IPSec tunnel or by adding / modifying routing headers), or a variation thereof. The identifier sent as part of the forwarding request message (M') may be a copy of the request identifier (ID1), or an encrypted, encoded, hashed, and / or scrambled version of ID1, or a one-to-one mapped substitution identifier.

[0084] Next, a forwarding response message (N'), which will be described later, is received from the cellular communication system. In response to the forwarding response message, a response message (N) is sent to the mobile device.

[0085] Within a network relay entity, the network relay function (NRF) is configured to perform the following: First, at least one forwarding request message (M') is received via at least one cellular base station. Next, relay availability data is obtained regarding relay devices capable of exchanging data with a mobile device for at least one available slice. The available slice is determined according to the request identifier (ID1). Next, at least one forwarding response message (N') is sent via at least one cellular base station. The forwarding response message includes network relay information indicating at least one available slice and at least one relay device capable of forwarding the data for the available slice.

[0086] Optionally, the forwarding response message (N') includes a set of relay devices (T) within the network relay information. Additionally, or alternatively, the response message (N) includes a set of relay devices (T) (for example, within the slice relay information field). For example, the set of relay devices may be an ordered list of available relay devices, such as a list ordered based on priority level or suitability.

[0087] Optionally, each forwarding response message may be sent to only one specific relay device, and the response message may indicate the relay device itself as the relay device. Such a message may only implicitly indicate the relay device. Therefore, the message may not explicitly indicate the relay device as any “relay ID” or similar message element. Instead, the message may include only the network address of a specific relay, for example, as the destination address in the message header. The relay device may be implicitly indicated by the relay’s destination address (e.g., in the forwarding response message (N')) or by the relay’s source address (e.g., in the response message (N)). For example, a use case may have three relay devices a, b, and c, each capable of responding to a mobile device broadcast with information about the slices they can support. In this case, since each relay (a / b / c) responds itself, message N does not need to list the relay(possible) devices. In this message format, the identification information of the relays (a / b / c) exists only in the standard “source” field in the message header (e.g., MAC source address). It may not be present in higher-level messages, or it may be indicated by itself. The mobile device selects one of the relay devices that received each response message and establishes an indirect connection through the selected relay device.

[0088] Optionally, each forwarding response message may contain instructions for various actions. It may instruct the relay device to reconfigure an existing PDU session between the relay device and the network to handle the relaying of network traffic for a specific slice (e.g., change the DNN, connect to a different User plane function). It may also instruct the UE configuration to be updated (potentially including different S-NSSAI information, different policy information, or different authentication information). These actions cause the device to reconnect to the network by interrupting the existing PDU session and setting up a new one. As a result, a different AMF (Access and Mobility management Function) providing the network slice may be selected. The forwarding response message may also include instructions to initiate an additional PDU session with the network if the relay UE is already functioning for another remote UE, or to connect to a different PLMN / NPN. Furthermore, the forwarding response message may include instructions to camp on to a specific cell associated with a CAG (Closed Access Group) ID in order to access a slice, particularly in the case of a public network operational NPN.

[0089] Optionally, each forwarding response message may include instructions / information regarding resource scheduling requirements for the base station based on available slices within the network relay information (e.g., characteristics, QoS flow, minimum / maximum / priority bitrate, priority, frequency bandwidth, bandwidth, and resource allocation between different slices). The resource scheduling requirements are used by the base station to schedule sidelink resources for mobile devices and available or selected relay devices for communication on available or selected slices. Alternatively, instructions / information regarding resource scheduling requirements for the base station based on available slices may be transmitted as a separate message directly from the NRF to the base station (or a nearby base station), or routed / tunneled through the AMF (if the NRF is not integrated with the AMF).

[0090] Optionally, each forwarding response message may contain configuration updates, authorization updates, or policy updates for a remote UE that has been out of coverage for some time. This information may be forwarded from the relay UE to the remote UE using the response message. To prevent this information from being exposed to the relay UE, the information may be encrypted using a security certificate known only to the remote UE.

[0091] More specifically, the cellular communication system includes a mobile device UE0 that operates as a cellular communication user device, and a set S of relay devices {UE1, ...UEn} that also operate as cellular communication user devices and can relay network traffic from / to the cellular communication system CCS (n>=1).

[0092] Device UE0 can operate as follows:

[0093] Device UE0 sends message M to relay device UEx of set S. The message contains an identifier which may be network slice identifier ID1 that device UE0 is requesting access to. ID1 may optionally be S-NSSAI (as defined in 3GPP® [24.501]), which is part of a set of slice identifiers. Alternatively, the message may contain a temporary slice identifier (as defined in 3GPP® [33.813]) (either completely or as a hash value), or an encrypted slice identifier (as defined in 3GPP® [33.813]). In such cases, it is advisable for the core network to maintain a list of past temporary identifiers to check for matches, as the identifier may not be up-to-date because the remote UE has been out of coverage for some time. Alternatively, the message may contain a combination of PLMN and NID (Network Identifier) ​​or CAG ID to indicate the slice, especially in the case of NPN. The message may contain any other type of identifier from which the NRF (e.g., AMF / NSSF / ProSe functions or other network functions) or relay device UEx can derive the slice requested by device UE0 (e.g., using a hash table or other type of mapping function) (e.g., derived from a derivation function or mapping table that may be pre-configured in the UF, updated periodically during or after registration, or uniquely pre-configured for each UE).

[0094] Message M may be, for example, a D2D / PC5 discovery message (as defined in 3GPP® [23.303]) containing an additional information element indicating the requested network slice identifier, or a PC5 direct communication request (as defined in 3GPP® [23.287]) containing an additional information element indicating the requested network slice identifier, or a PDU session establishment request (as defined in 3GPP® [24.501]) using the requested identifier (ID1) as the (V2X) service code or application ID, or a registration request (as defined in 3GPP® [24.501]) using the existing "Requested NSSAI" attribute, or a UL NAS TRANSPORT (as defined in 3GPP® [24.501]) using the existing "S-NSSAI" attribute, or another type of PC5 / NAS / RRC message containing an additional information element indicating the requested network slice identifier.

[0095] Device UE0 receives message N from device UEx. The message may include, for example, a network slice identifier ID2 as part of an additional slice relay information field. ID2 may be the same as ID1, or it may be an instance ID, an authorized slice ID, or a default slice ID. Alternatively, message N may include information about a subset S' of S that UE0 is authorized, unauthorized, or preferred to use to set up an indirect connection session with the network slice of the cellular communication system CCS identified by ID2. Alternatively, message N may include a boolean or a set of boolean values ​​indicating support for the requested and / or supported set of slices. Alternatively, message N is an acknowledgment that a match has been found between the requested slice and the list of slice IDs to which the mobile device can connect via the eRelay UE. Message N may only be sent if relay device UEx is capable of acting as a relay for device UE0 for an indirect communication session in the requested network slice. Message N may be formatted as, for example, a D2D / PC5 discovery response message (defined in 3GPP® [23.303]), a PC5 direct communication accept message (defined in 3GPP® [23.287]), a PDU session establishment accept message (defined in 3GPP® [24.501]), a registration accept message (defined in 3GPP® [24.501]), a DL NAS TRANSPORT using the existing "S-NSSAI" attribute (defined in 3GPP® [24.501]), or another type of PC5 / NAS / RRC message.

[0096] Device UE0 selects relay device UEy for set S to communicate with the cellular communication system CCS. UEy may differ from UEX if the use of device UEX in setting up the indirect connection with the requested network slice is not permitted or preferred.

[0097] Note that, optionally, a relay UE may respond via message N itself, for example, based on pre-configured information from the NRF, indicating that it can provide a particular slice because, for example, it is part of the same slice, has the same security, and has sufficient resources to act as a relay for a remote UE. This option may also work for relays operating within a default slice that operates within the same PLMN, or within a private slice operated and configured by the same third party to be part of the same group, or to belong to a special device group (e.g., public safety UEs). Optionally, the NRF may pre-configure a relay UE for a set of slices, for example, a default slice and / or a specific set of private slices on which the relay UE can operate, and optionally, it may pre-configure relevant policy rules, for example, for when the relay UE is allowed, enabled, or has the resources to respond to relay discovery messages. This can be done, for example, by pre-sending a message to the relay UE containing pre-configured slice relay information.

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

[0099] Device UEx receives message M from device UE0. The message contains network slice identifier ID1, which device UE0 is requesting access to.

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

[0101] Device UEx receives message N' from the cellular communication system CCS. The message includes a network slice identifier ID2 and information about a subset S' of S that UE0 is permitted, not permitted, or preferred to use to set up a relayed communication session with the network slice of the cellular communication system CCS identified by ID2.

[0102] Device UEx sends message N to device UE0, at least partially based on message N'.

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

[0104] Within a cellular communication system CCS, a relay device UEx can be communicatively coupled via a base station BS among multiple cellular base stations in the RAN. Within the CCS, a Network Relay Function (NRF) is provided. A base station can be communicatively coupled to an Access and Mobility Management Function (AMF) in the CN. The core network may host multiple AMFs assigned to multiple different slices. A base station can select the appropriate AMF based on the requested slice identifier ID1 received in message M'.

[0105] The base station BS may receive message M' from the relay device UEx and forward the message to the NRF. Based on the received message, the base station BS generates a new message to the NRF or interprets message M' via the NRF, for example, via the built-in NRF. The forwarded message may be a NAS message. The new message may be, for example, an initial registration message, a UE context information message, or another NGAP (NG Application Protocol) message via the N2 interface, similar to an S1AP (S1 Application Protocol) via the S1 interface in 4G.

[0106] A CCS may host different NRFs, or different instances of an NRF may be assigned to different slices. The base station may select the appropriate NRF based on the requested slice identifier ID1 received in message M' and forward the message to the selected NRF. If an NRF is not directly coupled to the base station but is directly coupled to the AMF, the AMF may select the appropriate NRF based on the requested slice identifier ID1 received in the message received from the base station.

[0107] Within a CCS, the Network Relay Function (NRF) can operate as follows:

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

[0109] A set of UEs T capable of relaying network traffic from UE0 to RAN and from RAN to UE0, and information I regarding the capabilities of these UEs are obtained.

[0110] The relay device is determined, in part, based on the received message M'' and the acquired information I. The relay device may constitute a subset T' of T, consisting of UEs that UE0 is permitted, not permitted, or preferred to use as a relay device to set up a relayed communication session with the network slice of the cellular communication system CCS identified by ID1.

[0111] Message N'' may be sent back to the AMF or base station BS. Message N'' may contain information about subset T' and network slice identifier ID2.

[0112] Finally, the AMF or base station BS sends a message N' based at least partially on message N' to the relay device UEx. The message may, in addition or alternatively, be addressed directly to a remote UE (e.g., via the AMF), to a subset of relay UEs, or to an intermediate node (e.g., the base station to which the aforementioned relay UEs are connected), which then forwards that information to the relay UEs in a new message.

[0113] NRF-assisted relay selection is described via a requesting UE during discovery. Here, the UE makes a selection based on NRF pre-selection. A UE may be configured to connect to one or more network slices and, based on configured policies, may be configured to discover nearby relayable UEs under certain circumstances (e.g., outside base station coverage). To discover nearby relayable UEs, the UE sends a D2D / PC5 discovery message which may contain new attributes indicating one or more IDs of slices it wishes to connect to. Relayable UEs within radio range may receive this message and report the information from the message to the NRF (Network Relay Function) in the CN (Core Network), respectively. Specifically, the message contains information about the IDs of the slices the UE is requesting.

[0114] Based on the received information, the NRF determines which (potential or already active) candidate relay UEs are authorized and / or not authorized and / or best able to provide the requested slice, or a subset of the slice if the complete set is unavailable, to the requesting UE. To this end, the NRF may need to request / receive information from other network functions (e.g., the Access and Mobility Management Function (AMF) or the Radio Access Network (RAN) if the NRF and AMF are not integrated), or directly from the relay UEs, including information such as capability, context information, connectivity characteristics, and mobility / location / speed information, from each relay-enabled UE within the UE's discovery range, or from each relay-enabled UE that can or can set up an indirect connection from the UE to the RAN in other ways, or that is involved in the setup (e.g., in the case of a multi-hop relay). The NRF can use this information, along with other information from other network functions that the NRF may request / receive (if the NRF is not integrated with those network functions), such as the PCF (Policy Control Function), UDM (Unified Data Management), and NSSF (Network Slice Selection Function), to evaluate whether each candidate relay UE is permitted or capable of acting as a relay UE for the requested network slice, and whether it has sufficient resources available to achieve the required QoS. Furthermore, the NRF may request information about a relay UE's "reputation as a relay UE" from, for example, the NWDAF (Network Data Analytics Function), because a relay UE may have a "bad reputation" (or record) for acting as a relay, such as dropping connections, performing denials of service by ignoring all remote UE traffic, or throttling the bandwidth of remote UEs.

[0115] Furthermore, the NRF may take into account 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 already reached a specific maximum number of UE / PDN connections per slice, and may provide different candidate relay UEs to which the requesting UE is connected.

[0116] The NRF may also use preliminary UE join information to verify whether the UE is permitted to operate on the requested slice. However, the NRF will not use this information to authenticate the UE at this point, as the UE has not yet been authenticated on the core network and has only sent information related to its own identity via the relay discovery request that may be unauthenticated data (i.e., easily forged / altered). It will only use it as guidance within the selection process.

[0117] When a Network Relay Function (NRF) receives a request identifier (ID1) in a forwarding request message (M'), the NRF can use ID1 to obtain relay capability data about relay devices capable of sending and receiving data to and from that network slice, based on the characteristics of the specific network slice indicated by ID1. However, in the case of a roaming remote UE, the NRF may not know either the identifier ID1 or the characteristics of the slice it indicates. Alternatively, the NRF may know the identifier ID1 but perceive it as having different slice characteristics because the identifier ID1 is used for different purposes by both the relay UE operator and the remote UE operator. In other words, if operators do not use mutual agreement on the values ​​of identifiers such as ID1, identifier duplication may occur. To address these potential issues, after receiving M', the NRF may contact the HPLMN NRF of the remote UE's HPLMN (Home PLMN) (if known) or the AMF (or database) of one or more other PLMNs, for example, using the request message M'' to obtain the characteristics of the slice indicated by ID1, and further verify whether the remote UE is authorized to connect to the slice indicated by ID1. Once the characteristics of the slice are obtained, for example via the response message N'' from the HPLMN NRF, the NRF may configure parameters on the relay UE to support relaying to the slice indicated by ID1, for example, a security key, or parameters from which the relay UE can derive a security key, and send these parameters to the relay UE. The NRF may include such configuration information entirely or partially in the forwarding response message N', or include the configuration information in another separate message. The NRF may also configure the PDU sessions of the relay UE and / or the remote UE, for example, to optimally meet the QoS service requirements of a particular slice, depending on the obtained characteristics of the slice indicated by ID1.Furthermore, the NRF may configure the parameters of the gNB serving the relay UE to optimally meet QoS service requirements, such as communication delay requirements or data throughput requirements for a particular slice.

[0118] Another solution involves coordinating the assignment of identifiers such as ID1 among operators. For example, one operator could enter into agreements with all operators that allow other operators' UEs to roam on its cellular network.

[0119] The NRF can then send back a message to one or more selected candidate relay UEs, along with a message for each relay UE containing the set of slices it can provide to the requesting UE through that particular relay UE. In other words, each candidate relay UE contains a set of "accepted slice IDs." The NRF may also include a set of "rejected slice IDs" if it could not obtain the complete set of requested slices or if it was not authorized to use that relay UE as a relay UE for network communication of the requested slices. The received slice information may be an instance identifier, an authorized 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 to the core network in order to gain access to the requested slices. This list may be ordered according to priority or suitability for acting as a relay UE for the requested slices.

[0120] Next, each relay UE that receives such a message uses the information from the message to send back a discovery response to the requesting UE. The discovery response may optionally include slice information (or other information that allows the requesting UE to deduce whether the relay UE can support relay communication for the requested slice), and may optionally include information about other candidate relay UEs. Because (potential) relay UEs communicate with the NRF before sending a discovery response to the requesting UE, the discovery response from a relay UE may be sent a little later than the requesting UE expects. In this case, the relay UE may send a preliminary discovery response indicating that it exists, but that additional information, including slice information, is awaiting approval from the NRF / CN and will be sent later.

[0121] Based on discovery responses received from candidate relay UEs, the UE selects the best candidate relay UE to connect to, connects to it using a procedure similar to ProSe, for example, and connects to the requested slice or a subset of achievable slices via the core network procedure. Alternatively, the NRF may select only a single relay UE and instruct the relay UE to connect to the UE requesting the relay connection to the requested slice.

[0122] Figure 4 shows an example of an NRF-assisted relay selection sequence diagram. This diagram schematically illustrates an example of flow and message sequence. In the diagram, • NF stands for Network Relay Function (NRF). NF2 is an optional extension of NRF (or ProSe functionality) that handles authorization for a relay UE to accept a new remote UE. R1, R2, and R3 are relay UEs or potential relay UEs, and here we assume that R3 is connected to a different gNB, namely gNB2. In this example message sequence, detailed information about each relay UE (e.g., capability, signal quality, etc.) is sent directly to the NF, reducing the time it takes for the NF to receive all of this information. The "opt" box indicates optional communication to request detailed QoS information about the slice, for example, from the RAN, but may also include information about other nearby potential relay UEs, measurement information, and location / mobility information for each UE. Here, it is shown as information requested from the RAN, but it may also be necessary to request information from the AMF, PCF, UDM, NSSF, or other network functions. It is shown as optional because the NRF may have already received this information. NSSAI is a set of up to eight slice IDs, as described in more detail in the 3GPP® specification [23.501].

[0123] The connection processor within the mobile device may be configured to initiate the relay discovery process and make an initial indirect connection. Subsequently, the connection processor sends a request message over the initial indirect connection. The network relay entity (140) or relay function may be configured to reconfigure the initial indirect connection into the aforementioned indirect connection to a selected slice via a selected relay device. Thus, an actively relaying UE may be reconfigured to use a different relay, in which case the UE first selects the initial relay, and the NRF or the UE reconfigures that selection. A UE that needs to select a relay UE sends a D2D / PC5 message to initiate relay discovery. Relay UEs and potentially relay-enabled UEs within radio range receive this message and respond with a discovery response using modern technology procedures, possibly ProSe procedures. The UE then selects a suitable relay UE candidate, not yet knowing whether its relay UE fully supports and connects to all the requested slices. The UE performs 5G network registration and / or PDU session establishment over the relay UE connection using modern technology procedures, including requests for one or more slices.

[0124] The NRF may be involved in the process as follows: When an NSSAI requested by a UE is received by a base station or AMF (Access and Mobility Management Function), the NRF is notified of this. The NRF may then determine, in the same manner as described above, which (potential) relay UE or set of relay UEs can and / or is permitted to and / or best provide the requested set of slices to the requesting UE. Next, if the NRF determines that the relay UE best suited to the UE requesting access to one or more slices is a different relay UE from the current relay UE, the NRF sends a reconfiguration message (e.g., a CONFIGURATION UPDATE COMMAND as defined in 3GPP® [24.501]) to the UE. The message may be sent directly or addressed through an intermediary such as a gNB or relay UE, and new attributes in the message may indicate the ID or address of the relay UE that is preferred to use and the set of slices that can be obtained by that relay UE. The set may be larger than the slices currently supported by the UE. Furthermore, the NRF may transmit a list of relay UEs along with a priority level and / or slice set for each relay UE. Alternatively, information on which relay UEs can or should be used for a particular slice may be provided as a new extension to the UE Route Selection Policy (URSP) as defined in 3GPP®[29.507][23.503]. This may be transmitted to the UE using the UE Policy Distribution Protocol as defined in Annex D of 3GPP®[24.501].

[0125] When a UE receives a reconfiguration message or an updated URSP, depending on the information received, the UE may either continue using the relay UE it is already using or perform relay UE discovery again, which may optionally be done by specifically searching for a new preferred relay UE during this discovery and connecting to it.

[0126] As a further example, we describe an enhanced ProSe (eProSe) scenario in 5G, which is a concrete example of reconfiguration to a different eRelay UE (Enhanced Relay UE) that better supports the requested slice. This exemplary scenario demonstrates how it can be applied to a 5G system architecture. In this scenario, we assume that the relay-enabled device has already enabled its relay function and is functioning as a relay device with permission from the 5G network. On-demand activation of the relay function of a relay-enabled device is also possible, but this will not be discussed further.

[0127] This exemplary eProSe scenario includes the following: A mobile device UE, having lost its connection to the 5G core network and unable to re-establish it, initiates the eProSe eRelay Discovery Model B procedure using eRelay Open Discovery. In this procedure, the mobile device acts as an eRemote UE. The mobile device first checks its UE configuration to see if it has been authorized by the ProSe feature to perform this procedure in the out-of-coverage situation. If so, it examines its own UE configuration to see if it has been authorized by the ProSe feature to act as an eRemote UE when out of coverage. If this is also authorized, the mobile device requests a nearby eRelay UE (which may also be called an eProSe UE-to-Network relay UE) by sending a PC5_DISCOVERY message of type eRelay Discovery Solicitation. This message is sent over a sidelink (SL) spectral resource. Open Discovery is used in this example, which means the broadcast request is not protected by encryption. Any eRelay UE can parse the request without requiring any specific security context or key. Alternatively, although not explained in detail here, a secure discovery procedure called eRelay Restricted Discovery may be used to prevent potential data breaches.

[0128] Next, each eRelayUE reports the information and / or request parameters received from the mobile device to the ProSe function using a message, for example, a ProSe MATCH_REPORT via the PC3 interface, or its equivalent in 5G eProSe. The ProSe function collects all MATCH_REPORT messages sent by the eRelay UE. It determines what the response should be for each message and sends each response message back to its respective eRelay UE, for example, a MATCH_REPORT_ACK message via the PC3 interface, or its equivalent in 5G eProSe. Each eRelay UE that receives such a message (i.e., a message implemented as, for example, MATCH_REPORT_ACK via PC3) sends 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. A mobile device receives this message from one or more eRelay UEs, which allows the mobile device to select one eRelay UE that it deems suitable for connection, using, for example, a decision process already standardized in 4G ProSe, or an equivalent in 5G eProSe.

[0129] Next, using the selected eRelay UE, the mobile device continues the 5G core network connection procedure, and the selected eRelay UE relays communication at the MAC layer, i.e., L2. This procedure may include, for example, 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 may be implemented as sending a UE-triggered service request message or similar to the AMF (Access and Mobility Management Function) or ProSe function within the 5G core network, so that the 5G core network can determine what response the eRelay UE should send to the mobile device. The response from the core network is sent to the eRelay UE by the 5G network function, such as the AMF or ProSe function. Based on this, the eRelay UE sends a response message, such as INDIRECT_COMMUNICATION_RESPONSE, to the mobile device via the PC5 interface. After a successfully processed acknowledgment, the mobile device performs a process similar to the existing 5G core network registration process, but the main difference is that messages sent by the mobile device are not sent directly to the base station, but are relayed to the base station via the eRelay UE, and finally to the core network. The registration process begins with the 5G-NR RRC connection setup procedure. This procedure ends with the mobile device sending an RRCSetupComplete message containing a NAS registration request to the base station. The NAS registration request follows the standard 5G procedure and includes the element Requested NSSAI. Based on this procedure, the base station (gNB) initiates the registration of the UE to the 5G core network, which begins with forwarding the mobile device's NAS registration request to the AMF. The NAS registration request containing the Requested NSSAI functions as a forwarding request message.As described herein, in this case the AMF implements most of the NRF. The AMF (which may be supported by other network functions such as ProSe functionality, which constitute a distributed NRF) determines the optimal eRelay UE that a mobile device should connect to in order to best satisfy the Requested NSSAI, and further determines the Allowed NSSAI, i.e., the set of slice IDs (S-NSSAI) that the optimal eRelay UE can provide. In response to a NAS registration request, the AMF creates a response message NAS Registration Accept, which includes a new information element indicating the "Allowed NSSAI provided by the optimal eRelay UE" along with the ID / address information of the optimal eRelay UE. Alternatively, the AMF may include multiple eRelay UEs, each with its own set of Allowed NSSAI. In this way, a mobile device can select an eRelay UE from a set of multiple "optimal" eRelay UEs. The NAS Registration Accept is sent back to the base station.

[0130] Next, based on the received message, the base station sends a message, for example, RRC Reconfiguration. This message includes, as a new element, information about the "Allowed NSSAI provided by the optimal eRelay UE" along with an indication of the optimal eRelay, or information about a set of multiple eRelays and their respective Allowed NSSAIs. In response, the mobile device evaluates the new information, detects that there is another eRelay UE that can better provide the indicated slice within the Allowed NSSAI, and resumes the relay procedure by connecting via the indicated optimal eRelay UE. This process may optionally include rediscovering the eRelay UE.

[0131] Furthermore, the "Allowed NSSAI" information provided by the optimal eRelay UE may be supplemented by an optional field per eRelay UE indicating the security context ID or application ID that the mobile device should use to correctly discover that eRelay UE.

[0132] Next, we will describe a second eProSe scenario in 5G. In this scenario, slice information is present in the eProSe discovery Model B message so that the UE can directly select the optimal relay device. Also, in this example scenario, we assume that the relay-enabled device has already activated its relay function.

[0133] The second eProSe scenario includes the following: A mobile device UE that has lost its connection to the 5G core network and is unable to re-establish it initiates the eProSe eRelay Discovery Model B procedure using eRelay Open Discovery. In this procedure, the mobile device acts as an eRemote UE. The mobile device first checks in its UE configuration whether it has been granted authorization by the ProSe feature to perform this procedure for out-of-coverage situations. If so, it examines its own UE configuration to see if it has been granted ProSe feature authorization to act as an eRemote UE when out of coverage. If this is also granted, the mobile device sends a PC5_DISCOVERY message on the sidelink (SL) spectrum of type eRelay Discovery Solicitation, requesting a nearby eRelay UE (which may also be called an eProSe UE-to-Network relay UE) to return relay information. Open Discovery is used in this example, which means that the broadcast request sent is not protected by encryption and any eRelay UE can parse the request without requiring a specific security context or key. Alternatively, a secure discovery procedure called eRelay Restricted Discovery can be used to prevent potential information leaks, but this will not be discussed further. The eRelay Discovery Solicitation 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 wishes to connect to via the eRelay UE.

[0134] Next, each eRelay UE reports the information and / or request NSSAI received from the mobile device, including the Requested NSSAI, to the ProSe Function using a forwarding request message, such as a MATCH_REPORT via the PC3 interface, or its equivalent in 5G. The ProSe Function implements the Network Relay Function and collects all forwarding request messages. For each eRelay UE, the ProSe Function determines the slices within the Requested NSSAI that the eRelay UE can provide to the mobile device via the indirect connection. This determination may involve communicating with other network functions, such as RAN, base stations, AMF, and servers containing MNO subscription information, to obtain the best possible determination of the supported slices.

[0135] Subsequently, the ProSe Function sends a forwarding response message back to each eRelay UE, for example, using a MATCH_REPORT_ACK message via the PC3 interface or its equivalent for 5G. This message to a given eRelay UE optionally includes an additional information element, "Allowed NSSAI," which is a list of one or more slice IDs (i.e., a list of S-NSSAIs) that a mobile device can connect to via its eRelay UE. It may also optionally include an additional information element, "Rejected NSSAI," which is a list of one or more slice IDs that the ProSe Function has determined cannot be accessed via its eRelay UE.

[0136] Next, each eRelay UE that receives the message (i.e., the message implemented as, for example, MATCH_REPORT_ACK via PC3) sends a response message to the mobile device, which is implemented as, for example, a PC5_DISCOVERY message of type eRelay Discovery Response via interface PC5-D. This message includes, here, the slice ID contained in MATCH_REPORT_ACK as a new element. The new element is an optional Allowed NSSAI if the given eRelay UE can act as the mobile device's eRelay UE for a particular slice, or an optional Rejected NSSAI if the ProSe Function has denied the eRelay UE the right to act as the mobile device's eRelay UE for a particular slice. Alternatively, the response message may include a new element of a Boolean or a set of Boolean values ​​indicating support for the requested and / or supported set of slices. Alternatively, the response message may be a message in another format affirming that a match has been found between the requested slice and the list of slice IDs that the mobile device can connect to via the eRelay UE. A response message may be sent only if a given eRelay UE can act as a relay for the mobile device for the requested network slice.

[0137] Subsequently, the mobile device receives this message from one or more eRelay UEs, which allows it to select, for example, one eRelay UE that provides all or most of the network slices initially indicated in the Requested NSSAI. Alternatively, the mobile device may select an eRelay UE that does not provide most of the network slices but provides the single most important (highest priority) network slice to which the mobile device wishes to connect. Using the selected eRelay UE, the mobile device proceeds with the 5G core network connection procedure, with the selected eRelay UE relaying communications at L2. This procedure may, for example, first 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. This can be implemented as sending a UE-triggered service request message or similar to the AMF (Access and Mobility Management Function) or ProSe Function in the core network, so that the 5G core network can determine the content of the response that the eRelay UE should send to the mobile device. The response from the core network is sent to the eRelay UE by the network function. Based on this, the eRelay UE sends INDIRECT_COMMUNICATION_RESPONSE to the mobile device via the PC5 interface. After a successful acknowledgment that can be parsed, the mobile device initiates a process similar to the normal 5G core network registration process, but with the key difference being that the relevant traffic is relayed via the eRelay UE. The process begins with the 5G-NR RRC connection setup procedure. This procedure concludes with the mobile device sending an RRCSetupComplete message to the base station, which includes a Requested NSSAI, similarly following standard 5G procedures.Based on this procedure, the base station (gNB) initiates the registration of the UE to the 5G core network, which includes connecting to one or more network slices.

[0138] In the third eProSe scenario for 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. The eRelay UE then exchanges messages with the AMF or ProSe function (or other network function) to determine whether it can and is permitted to act as a relay for the eRemote UE's communication with the requested network slice, and then sends an INDIRECT_COMMUNICATION_RESPONSE containing information (e.g., a set of permitted 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.

[0139] In another alternative, relaying may occur at Layer 3 or via application-level relay, in which case DIRECT_COMMUNICATION_REQUEST messages (e.g., as defined in 3GPP®[23.287]) and DIRECT_COMMUNICATION_ACCEPT messages (e.g., as defined in 3GPP®[23.287]) may be used instead of INDIRECT_COMMUNICATION_REQUEST and INDIRECT_COMMUNICATION_RESPONSE messages, respectively.

[0140] In a further exemplary scenario, a vehicle's mobile device may communicate with a destination within the network (V2X). The vehicle UE uses V2X 5G communication on two specific slices, "V2X" and "Entertainment," and at some point may lose gNB coverage. The vehicle UE initiates a relay UE discovery and finds 10 candidates belonging to different PLMNs. Two of the candidates explicitly indicate in their discovery response messages that they support both the V2X slice and the Entertainment slice. The vehicle UE selects the one with the highest signal quality and initiates a connection to that relay UE as the remote UE. In the core network registration process, both slices are presented to the vehicle UE as "authorized NSSFs."

[0141] Figure 5 shows an example of a multi-hop relay topology for a moving UE. The moving UE may have lost coverage while previously connected to a gNB / eNB. The out-of-coverage (OoC) UE may initiate a relay discovery process indicating that it requests slices X and Y. In the figure, both UE(1) and UE(3) receive the discovery message and send the OoC-UE information, along with the requested slices X / Y, to the NRF in the CN via the gNB. The NRF may determine that slice X is related to URLLC (Ultra Reliable Low Latency Communication) and is best provided with the fewest hops for the lowest latency, while determining that a high data rate is important for slice Y.

[0142] The NRF determines that UE(1) has the fastest connection to the gNB, sufficient bandwidth to add additional relay traffic, and also satisfies slice Y. The NRF then reports the slice IDs and priority value "high" for X and Y to UE(1). The NRF may also authorize UE(1) to become the relay UE for the OoC-UE. Authorization may be done according to a separate message / protocol or may be combined with the previous step. The CN may also (simultaneously) provide credentials to allow the relay UE to access the requested slice.

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

[0144] UE(3) receives the NRF response and may send a discovery response with slice X / Y and priority "low" to the OoC-UE.

[0145] The OoC-UE receives both discovery responses, selects UE(1) as the relay UE, and proceeds with the connection process to this relay UE. Thus, by performing the above steps, UE(1) becomes the relay UE during the process. This may be done at will if the OoC-UE determines that UE(1) is likely to be selected as the relay UE because of its "high" priority value.

[0146] The above concepts may be mapped to 5G cellular communication systems (5GS). The Network Relay Function (NRF) may be mapped to the Network Slice Selection Function (NSSF) as defined in 5G[23.501], or to a combination of NSSF and AMF[23.501], but may also be a new or different network function. A requested slice / slice instance may be mapped to a Requested NSSAI[23.501], a temporary / encrypted slice identifier[33.813], or another newly defined identifier. Allowed / supported slices determined by the NRF may be mapped to an Allowed NSSAI[23.501]. A slice ID may be mapped to an S-NSSAI[23.501], or a set of slice IDs may be mapped to an NSSAI[23.501].

[0147] Furthermore, the “discovery message” may be a discovery-type message or an announcement-type message. The discovery message may be transmitted over a sidelink (SL) scheduled resource, or it may be a RACH (Random Access Channel) type message transmitted over a resource that is neither sidelink nor uplink (UL) scheduled. It may also be transmitted over a spectrum not defined by 3GPP®, such as Bluetooth or Wi-Fi.

[0148] Furthermore, the discovery message sent by requesting the UE may optionally include the following: First, the UE may send a discovery message to find a relay or potential relay. The content of this message must include a request slice in the "NRF-assisted relay selection" example, and may include a request slice in the "NF reconfiguration relay" example. The discovery message may also include one of the following: - A message header or message type indicating that the requesting device is requesting another device to act as a relay for traffic from the requesting device, or - A message header or message type indicating that the requesting party is trying to find an available relay device.

[0149] Furthermore, the discovery message may include information about the security context that the UE is using or wants to use, such as a security context specific to the slice, encrypted credentials provided by the eNB, encrypted PLMN keys, security context identifiers, ProSe group ID or service ID, and associated group / service credentials.

[0150] Furthermore, the discovery message may include the reason for the relay request, such as low battery, being out of range of the base station, poor signal reception to the base station, or a relay being recommended by the NRF. This may include the received signal strength of the message received from a nearby device, and this signal strength data may help the NRF select a relay. It may also include power status information of the device, such as power supply, battery power, mains power supply, or solar power, or current battery level information. In addition, it may include standard fields such as the transmitted signal strength of the message and UE identification information. UE identification information is optional and may be a derived or temporary ID that, for privacy reasons, can be calculated by the NRF / CN to be converted back to the actual UE ID if necessary.

[0151] Furthermore, the discovery message may include distance measurement data or other types of location information, such as speed (which may be absolute or relative speed) and / or heading / direction information of the mobile device. The mobile device 110 and / or relay device may be configured to perform distance measurement between the mobile device and the relay device. The connection processor 112 may be configured to enable distance measurement and transmit the measured distance to the network in order to obtain location data for 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 the selection of the relay device. In practice, location data based on receiving transmissions from mobile devices is not very accurate and often has a tolerance of, for example, 100m. In contrast, local distance measurement is much more accurate and often has a tolerance of, for example, 1m. The accuracy of location data can be improved by combining multiple locations of multiple mobile devices with the distance between devices at such locations.

[0152] To detect the distance between a mobile device and a relay device, a special mode for measuring distance may be required for the devices. This can be done, for example, by using Wi-Fi fine-time measurement as described in IEEE 802.11-2016, or by the MNO approving ProSe functionality (described in [23.303] and [24.334]) for both devices, allowing them to discover each other using a sidelink D2D communication channel and perform distance measurement or proximity detection, such as PC5 or Wi-Fi Aware distance measurement.

[0153] The possible contents of a request message (M) containing the requested network slice identifier may be as follows: If the requesting UE initiates the request message as part of a registration procedure, to be 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 the set of QoS requested, e.g., a priority set and an alternative fallback set. Furthermore, it may include information about relay UEs in the area obtained during the original relay UE discovery process, such as signal strength. Alternatively, this information may be included in the forwarding request message (M') by the relay device or selected relay device for indirect connection and / or by the base station when forwarding the message from the UE to the core network. Alternatively, as described above, the NRF may request this information and additional relevant information from the RAN, AMF, or other network functions.

[0154] When a relay device sends a message based on information received from a requesting UE, for example during a discovery process or indirect connection setup, the relay UE may send the message to the NRF to indicate that the requesting UE is looking for the relay UE, and may include its source address or identifier in the message.

[0155] A network relay entity may be configured to obtain metadata from a cellular communication system, such as received signal strength, signal quality, or distance estimates. Alternatively or in addition, the forwarding request message may include metadata that identifies the current connection status, such as the network connection method, quality of service (QoS) and hop count, connection stability information, and / or the frequency band used or supported by the relay device. The network relay entity (140) may be configured to determine network relay information based on the metadata.

[0156] Metadata may be obtained from other sources within the cellular communication system, such as sources within the RAN or core network. For example, hop count can be obtained from base stations, and distance estimation can be obtained from location services within the core network. Also, subscriber information from the UDM may be important, for example, to assess whether a relay UE is operated by the same MNO as a remote UE, whether a relay UE is authorized to access a particular slice, or whether it is authorized to operate as a relay within a particular slice. UE capability information may be obtained directly from the UE, or it may be provided (partially) by the UDM or SCEF. Since the resources of relay UEs and remote UEs are typically scheduled by base stations, the base station is the device that knows whether relay UEs and remote UEs are given sufficient sidelink resources to meet specific QoS requests from the NRF to satisfy the QoS requirements of a particular network slice.

[0157] NRF can determine whether it can meet the QoS requirements for a particular network slice. QoS represents a key criterion for determining which relay devices can function as relays for a particular slice.

[0158] The NRF may use the properties / requirements of a particular slice to determine which relay is preferable. For example, in the case of an IoT slice, it may be preferable to select a relay device that is stationary or not an IoT device itself.

[0159] The relay device may optionally include metadata about the requesting UE's message, such as RSSI, signal quality, distance estimate, or signal quality or distance estimate to another relay device. It may also include information that identifies the current connection status, such as one or more of the following: - Methods of direct / indirect connection. - QoS information and / or number of hops to the gNB. - (Past) connection stability information. - Buffer size. - Current number of connections. - Information regarding data flow or duty / sleep cycles. - The frequency band currently used or supported by the relay UE.

[0160] The NRF may obtain such information by interfacing with the RAN / gNB or other core network functions. The RAN / gNB may provide additional information, such as the resources available for sidelink communication per relay UE and remote UE. Upon receiving such information, the NRF may use it for decision-making processes. For example, the NRF may use the hop count along with QoS information and / or signal quality information to determine whether a given relay UE can fulfill a slice requested by the UE. For example, a relay UE with a high hop count is undesirable if it is a slice that provides low-latency communication. The NRF may even refuse to use a slice if it cannot achieve the required latency for the hop count, and may indicate this to the originating UE.

[0161] Additionally, messages to the NRF may optionally include the UE capabilities of the relay UE. UE capability information may include the following: - This may include information about the relay function, such as specific constraints on the circumstances under which the UE can perform relaying. - Wireless Rx / Tx speed category, or 3GPP® UE class / level. - The radio frequency band used or supported. - The processor's performance class and / or current load. - Mobility information: Fixed (e.g., roadside V2X nodes), or possibly mobile (e.g., mobile phones or wearable sensors). In the case of V2X, location / movement information may also be included. - Power supply, battery level, or expected device operating time information (which may be used to determine the optimal relay). - Identification information for a specific relay-related security context that the device already supports. - Priorities for relaying specific application types, application IDs, or group IDs. - Support for IP traffic and specific packet sizes. - Support for specific services, such as location-based services. - The types of relays the relay device can support, e.g., Layer 2 relays (PDCP level) or Layer 3 relays (IP level). The NRF can use the above capability information to select the optimal relay UE, taking into account the properties / requirements of one or more specific slices requested. For example, - For IoT slices: Non-mobile, wall-plug powered nodes with sufficient resources and high-speed connectivity may be preferred as relay UEs over battery-powered, mobile, and low-resource IoT sensors. - In the case of IoT slices: To conserve battery power, a relay UE, which is not an IoT device itself, may be used in preference to a direct network connection for an IoT device. - For V2X slices: It may be preferable to use a relay UE that is itself located within the V2X slice. - For V2X slices: It may be preferable to use a relay UE that is moving in the same direction as the requesting UE. Even if the relay UE is not in the same V2X slice, - The NRF can use information about the frequency band currently used by relay UEs in the selection process. If the NF obtains information about the frequency band currently used by relay UEs, for example from messages received from relay UEs, from gNBs, or by other means, the NRF can use this information to select which UEs are unable to provide a particular slice. This may occur, for example, when a slice is associated with the use of a specific dedicated frequency band; for example, a "V2X" slice may use the V2X reserved frequency band. Some candidate relay UEs may not currently be operating in this band and may not be suitable as relays for this slice. The NRF may exclude these candidate relay UEs from the selection process or include them as lower-priority candidates.

[0162] As a fallback solution, such a relay UE could provide a "V2X" slice over a different bandwidth. The same applies to NB-IoT / LTE-M devices, which could be candidate relay UEs, for example, that might operate on guard bands that are not supported by cellular networks.

[0163] The requesting UE may indicate the security context or key to be used for subsequent attachment to the relay UE. The security context for relaying may be bound to the security context for slicing. In ProSe, for a remote UE and a relay UE to establish a D2D connection used for relaying, they must possess a shared security context (i.e., key material). In existing specifications, the security context is pre-configured at the application level, thus limiting the usefulness of the relay function to devices with the same application context. In extended forms, any and unknown UE may be supported as a relay. The following may apply: - The requesting UE may indicate the supported security context or key C within its discovery message. This could be a slice-specific security context, a more general security context valid for multiple slices, or a security context for a given group of (third-party) devices, e.g., all medical devices in a hospital or a ProSe application group. Context information may also include a random ID or partial key that the NRF / CN can later use to derive the complete key. - The relay UE may send information about security context C to the NRF, allowing the NRF to retrieve information related to that security context from CN. - The NRF may include information based on the aforementioned key material or authentication information in the response message sent back to the relay UE. - The relay UE can then use security information to accept a secure relay request from the requesting UE. This is done securely to prevent eavesdropping, replay, packet injection, etc., during the relay establishment protocol.

[0164] Furthermore, when using the above random ID or partial key, the security material is only valid for a temporary period, thus reducing the potential impact of a malicious relay UE storing and sharing the security material.

[0165] A CN (Network Controller) may detect that a UE (Upper Unit) has become Out of Control (OoC). The CN can then request one or more UEs that it calculates are likely to be located near the OoC-UE to begin broadcasting an "Available Relay" message, helping the OoC-UE quickly find a suitable relay UE. In this case, the CN may include a NRF (Near-Range Filter) to determine which relay UE is best suited to be made available in this manner, based on the OoC-UE's previous slice information.

[0166] Furthermore, the NRF may authorize and instruct selected relay UE candidates to activate their relay capabilities if they are not already operating as relays. This ensures fast connectivity to the relay UEs afterward, as the selected relay UEs are already activated and have the network authorization / approval to operate as relay UEs. The NRF can also notify the gNB of the decision and the expected slice requirements from the requesting UE after determining the optimal relay device for the requesting UE. This allows the gNB to begin scheduling appropriate resources to support the requesting UE. This has the advantage that appropriate resources for the requesting UE operation on the desired slice are already prepared and scheduled in the gNB before the UE is fully attached to the relay UE and CN. This reduces transient QoS / bandwidth issues during relay transitions or transitions from direct network connectivity to relay connectivity.

[0167] Furthermore, if one of the requested slices is of the "urgent" type, it may be given priority in the selection process or receive special treatment from potential candidate relay UEs, for example, they may be automatically enabled to act as relay UEs and may be allowed to set up an urgent connection to one of the discovered candidate relay UEs. Alternatively, the urgent slice may be automatically included in the discovery response by the candidate relay UEs. This may also apply to relay UEs participating in slices known to have restricted use (e.g., public safety). Since these are unlikely to act as relay UEs for other devices, the public safety slice may be automatically included in their response and, in some cases, may not even contact the NF in the process.

[0168] Furthermore, discovery messages or "request relay" messages may include identifiers that indicate the class of the device or application to which the UE is associated. For example, a medical device may be in a different class, as may an emergency service device. The application class may be "Local Government IoT Application." This identifier can help the UE determine whether it is acting as a relay UE for the device that indicates this particular identifier. This allows a potential relay device to define the purpose for which it wishes to assist in its relay role, and for example, a medical application may be considered more important to the user than a purely commercial application. Also, not all relay devices may be usable for relaying medical or safety-related data, for example, to comply with regulations regarding the processing and transmission of medical data. To prevent fraud (identifier spoofing), a cryptographic certificate, signature, or proof element can be added to the communication to prove that the UE is part of the requested application or device class.

[0169] Even if a UE moves out of range, it may still receive faint synchronization information and / or other broadcast messages from the eNB, but may not be able to send them back due to long distance, signal interference, or insufficient battery power or transmitter output (i.e., the eNB does not receive the device's messages). In such cases, the eNB may assume the UE is still listening and proactively send certain instructions to the UE. For example, the network may instruct such a UE to begin requesting a relay, possibly including channel and timing information. Alternatively, the optimal timing for sending a "request relay" may be sent to the UE, for example, as part of a discovery message.

[0170] If a UE has just lost contact with an eNB, the UE may use its (previous) synchronization with the base station as the basis for its local clock, or it may detect a synchronization signal from a device operating in discovery mode. Immediately after the loss of connection, the eNB may provide synchronization information to various nearby candidate relay UEs. This information may include information about when the UE was last detected, and / or possible clock drift estimates, and / or timing margins, to adjust the listen time window to ensure that the probability of hearing an expected transmission from the UE is maximized. Alternatively, a candidate relay device may receive from the eNB information about resources previously scheduled for the UE on a sidelink or uplink channel. The relay device can use this to listen for “relay request” messages at appropriate times / frequency.

[0171] If a UE is already connected to a slice via a relay connection and detects that it does not have sufficient bandwidth / QoS available for the communication required / expected for the slice it is currently operating on, the UE may initiate a request to one of the other candidate relay UEs previously discovered, based on priority information provided by the NRF. Alternatively, it may initiate a new discovery process or send a request directly to the NRF to provide (updated) information about other relay UEs that should be selected to satisfy the slice's QoS properties. In this case, the NRF may be involved in initiating a discovery process among relay UEs and gNBs located in a specific geographic area near the UE.

[0172] Similarly, the eNB / network may proactively initiate a process to find a suitable relay if it detects insufficient available bandwidth or QoS. In that case, the UE is first instructed to send a "request relay" message, and then to connect to a specific relay or select from a set of relays.

[0173] Furthermore, UE users or businesses that provide relay functionality to others may be entitled to compensation or reimbursement for this effort. This compensation can take various forms, including payments, added usage credits to mobile phone contract bundles, or specific service benefits (e.g., the ability to use other relay devices). This may necessitate extending some billing functionality. This could include specific billing for operating as a relay UE for certain slices (e.g., private slices) where the relay UE may or may not have a contract to operate on that slice.

[0174] In a more detailed example, the mobile network defines a set of Connection Context Identifiers (CCIs). Each CCI maps to a combination of PDU session parameters [23.501] (e.g., PLMN ID (+NID / CAG ID), S-NSSAI, DNN, PDU session type, etc.) and, potentially, additional parameters that a remote UE might want to use to connect to the core network via a relay UE (e.g., group ID, QoS requirements, frequency, security context, etc.). Some of these parameters may impose restrictions on whether a relay UE is authorized to act as a relay for a remote UE, and whether it can act as one.

[0175] Much of the above information is privacy-sensitive and could lead to tracking of remote UEs, potentially exposing carrier deployment information (e.g., which slices / NPNs are supported by the core network). Therefore, it is preferable that this information be stored and used within the core network whenever possible and not directly provided to relay UEs, which may be considered untrusted end-user devices. Storing, using, and processing this information within the core network also allows for addressing the dynamic aspects of slice usage, for example, to meet QoS requirements defined by service level agreements for network slices. While remote UEs are also untrusted end-user devices, some of this information may need to be provided to remote UEs when they need to find and utilize relay UEs to communicate with the network, as remote UEs are likely to be outside coverage. However, since only PDU session parameters enabled by the remote UE's contract can be provided to remote UEs, exposing some of this information is less problematic in the case of remote UEs. It is different for relay UEs, as they may act as relays for various sets of remote UEs (potentially including inbound roaming remote UEs). The CCI that may be used by a remote UE may only be known to the remote UE's operator. Therefore, it may not be known to the relay UE at the time of discovery, but it may be obtained from the remote UE's home operator by the relay UE's network operator (i.e., the visiting network).

[0176] Furthermore, considering the potential number of slices and NPNs that can be supported by 5GC, the number of possible combinations of the above parameters can be very large, potentially requiring a very large number of CCIs.

[0177] One or more generic CCIs are used to provide the relay UE with as few CCIs as possible, and to ensure that remote UEs, which may use potentially unknown or outdated CCIs, can still discover the relay UE and request access to the network through it. While CCIs are bound to specific PDU session parameter sets and may be unknown to the relay UE, generic CCIs are identifiers (e.g., predefined values ​​that may have longer lifespans and may be commonly used for various PLMNs) that can be used as "wildcards" to request access to any PDU session parameter set for one or more PLMNs. Generic CCI values ​​can map to or indicate wildcard values ​​(e.g., asterisks) or other regular expressions. Generic CCI values ​​can be associated with an initial security context. This allows remote UEs and relay UEs to prove that they have the authority to issue discovery or connection setup requests that can be used by the remote UE to request access to a particular slice / NPN and / or request the use of a particular PDU session parameter set through the relay UE. Generic CCIs may be associated with a default network slice for one or more PLMNs. Alternatively, a generic CCI may be associated with an application context or a (V2X) application ID [23.287]. It is advantageous to provide at least one generic CCI to both the remote UE and the relay UE. Using a generic CCI may also facilitate support for Model A discovery (i.e., broadcasting "I'm here") because these messages remain small and typically do not contain a large list of CCIs that may need to be changed periodically. Also, using a single identifier instead of potentially including a large list of identifiers within the request message makes it easier for the remote UE to find all available options.A generic CCI may be used within remote and relay UEs as a trigger to include a specific CCI as part of a discovery message or connection request. Alternatively, a separate message could be defined to send a generic CCI, but the advantage of using a generic CCI is that the same discovery message and PC5 connection setup message can be reused.

[0178] Detailed instructions are shown below and in Figure 7.

[0179] Step 0: Before the discovery of the relay UE can be performed, the following information must be provided to the remote UE and relay UE in advance, for example, using the UE configuration update procedure [23.501] (e.g., starting from AMF or PCF): • For remote UE: - One or more CCIs that the remote UE is permitted to use (including a flag for each CCI indicating whether it is a general CCI or a specific CCI). - Mapping between each CCI that the remote UE is permitted to use and the default destination layer-2 ID for initial signaling to establish a PC5 unicast connection [23.287]. - Mapping between each CCI and a set of PDU session parameter values. Parameter values ​​may include, among other things, one or more of the following: - PLMN ID - NID / CAG ID - S-NSSAI - DNN - PDU session type For a typical CCI, the set can be empty or a small parameter subset, may represent wildcard values ​​(e.g., asterisks, regular expressions, etc.), or may contain predefined special values ​​(e.g., representing a default slice). -(Optional) Mapping between each CCI and a security context (e.g., a set of authentication credentials). - A policy that restricts remote UE PDU sessions to the requested CCI-compatible PDU session parameter values. • In the case of a relay UE: - One or more CCIs (including a flag indicating whether each CCI is a general or specific CCI) that the relay UE is permitted to disclose and respond to during discovery. To reduce the disclosure of potentially privacy-sensitive information, this should be a small subset of all CCIs that the relay UE may handle and should be configured in consultation with the relay UE's AMF. - Mapping between each CCI that the relay UE is permitted to expose and respond to during discovery, and the default destination Layer-2 ID for initial signaling to establish a PC5 unicast connection [23.287]. -(Optional) Mapping between each CCI and a security context (e.g., a set of authentication credentials). -(Optional) Default destination Layer-2 ID for broadcast communication via PC5[23.287].

[0180] Additionally, the following information must be provided to the relay UE's AMF (either in advance or when the AMF receives the forwarding request message (M) and consults with its respective network functions such as PCF, NSSF, and UDM). - A list of large CCIs that a relay UE can handle and may be authorized to handle (including a flag indicating whether each CCI is a general CCI or a specific CCI). Since the AMF's list of CCIs is not necessarily updated simultaneously with remote UEs (and relay UEs) that may be out of coverage for a while, the AMF should also maintain a history of old CCI values. - Mapping between each CCI and a set of PDU session parameter values. Parameter values ​​may include, among other things, one or more of the following: - PLMN ID - NID / CAG ID - S-NSSAI - DNN - PDU session type

[0181] For a typical CCI, the set can be empty or a small parameter subset, may represent wildcard values ​​(e.g., asterisks, regular expressions, etc.), or may contain predefined special values ​​(e.g., representing a default slice).

[0182] The PCF within the HPLMN of a UE that needs to be provided to become a remote UE or relay UE may interact with the PCFs of other PLMNs (e.g., a roaming partner's potential visiting PLMN) to perform CCI assignment and management.

[0183] Step 1: The relay UE may periodically broadcast one or more CCIs that the relay UE is configured with using (V2X) broadcast messages via PC5. To keep the broadcast messages small, the set of CCIs is preferably kept very small and preferably includes general CCIs.

[0184] Step 2: The remote UE can initiate discovery to find the relay UE by sending a Direct Communication Request via PC5 as described in TS23.287, or a similar message, using the request CCI as the (V2X) service / application identifier. If the request CCI is a generic CCI, the Direct Communication Request may include an additional CCI indicating the set of PDU parameters that the remote UE wishes to use. The Direct Communication Request uses the default destination Layer-2 ID configured for the request CCI (or the Layer-2 ID of the target relay UE, if known), and in the case of V2X, is typically sent over a sidelink shared broadcast / multicast channel that can be received by multiple relay UEs. This Direct Communication Request message corresponds to the Request Message (M) mentioned elsewhere in this document.

[0185] Step 3: One or more relay UEs may receive a direct communication request 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 the AMF that the relay UE serves (not only in the CM_IDLE state, but also in the CM_CONNECTED state). The registration / service / dedicated request message includes the request CCI, and if the relay UE received additional CCIs in the direct communication request in Step 2, the registration / service / dedicated request message includes those additional CCIs. It is preferable that additional CCIs be included instead of a general CCI. The relay UE may (re)use an existing PDU session previously 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 forwarding request message (M') used in other parts of this document.

[0186] Step 4: The AMF that the relay UE serves receives the forwarding request message (M') and verifies in the mapping table between the CCI and the PDU session parameters whether the relay UE is authorized to act as a relay UE for a given CCI, in particular for the associated network slice (indicated by S-NSSAI) and / or NPN (indicated by PLMN ID+NID / CAG ID). Furthermore, it verifies whether the relay UE can satisfy the requirements associated with the PDU parameters of the CCI, in particular whether it can and is authorized to act as a relay for the associated network slice (indicated by S-NSSAI in the mapping table) and / or NPN (indicated by PLMN ID+NID / CAG ID), as well as whether it can satisfy the QoS requirements of that particular slice / NPN. To perform verification, the AMF may request information from other network functions, such as NSSF (about permitted network slices), RAN (about relay UE capabilities and load, congestion, and signal quality), SMF (about ongoing PDU sessions and their QoS), UDM (for contract-related information), PCF (for policy information, PDU session configuration, and QoS-related information), NWDAF (for combined measurement information, analysis data, and historical data), ProSe functions, and application functions. If a relay UE sends a general CCI to the AMF and no additional values ​​are provided in the forwarding request message (M'), the AMF will determine whether the relay UE is operational for each set of PDU session parameter combinations. If the CCI value is not part of the mapping to PDU session parameters within the AMF, the AMF may look up the history of previous CCI values ​​or contact the AMF (or database) of another network operator's 5G network.

[0187] Step 5: If the relay UE is determined to be able to act as a relay for a given CCI and its associated network slice, and / or for NPN and other PDU session parameters, the AMF may send a Connection Reconfiguration message and / or a Configuration Update and / or a Dedicated message to the relay UE. This Connection Reconfiguration / UE Configuration Update / Dedicated message may contain information to perform the following: - Reconfigure existing PDU sessions between the relay device and the network to accommodate relaying network traffic for a specific slice (e.g., modify the DNN, connect to a different User Plane Function). - Update the UE configuration (including different S-NSSAI information, different policy information, and different authentication information, if necessary) and issue a reconnection (which may result in different AMFs (Access and Mobility Management Functions) being selected to operate for a particular network slice).

[0188] This connection reconfiguration / UE configuration update / dedicated message may include instructions to initiate an additional PDU session with the network if the relay UE is already operating for another remote UE. This connection reconfiguration / UE configuration update / dedicated message may also include instructions to connect to another PLMN / NPN. It may also include instructions to the radio access network (for example, to send an updated list of allowed NSSAI values ​​for the relay UE and / or remote UE), or instructions to camp on to a specific cell to access an NPN (identified by the CAG ID in the case of an NPN operated by a public network, and by the NID (along with PLMN ID information) in the case of a standalone NPN).

[0189] In particular, the AMF may be configured (for example, within the radio access network based on an NGAP message from the AMF to the radio access network [38.413]) by a CAG ID / NID that is part of the list of permitted CAG / NIDs in Mobility Restriction information, and / or configured as a CAG cell that can broadcast a CAG ID / NID within a system information block, and / or the radio access network may be configured to report a CAG ID / NID for a cellular base station configured as a CAG cell (within an NGAP message to the AMF [38.413]) indicating to the non-public network whether a relay device is directly connected to or a mobile device is indirectly connected via a relay device to that base station, and / or the PDU session of a relay device may be configured for that base station to connect to a cellular base station whose CAG ID / NID is part of the list of permitted CAG / NIDs in Mobility Restriction information.

[0190] If a relay UE determines that it cannot act as a relay for a given CCI and its associated network slice, as well as for NPN and other PDU session parameters, the AMF includes a “relay denied” error code for the requested CCI as part of this 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 relay if only general CCIs are sent to the AMF), and information about other nearby relay UEs. This connection reconfiguration / UE configuration update / dedicated message corresponds to the forwarding response message (N') used in other parts of this document.

[0191] Step 6: If relaying for a given CCI is not denied by the AMF served by the relay UE in Step 4 / 5, the relay UE performs the PC5 unicast link security procedure [23.287] and sends a direct communication acceptance message [23.287] containing the given CCI as the (V2X) service / application identifier to the CCI remote UE. The direct communication acceptance message may contain QoS information, IP configuration information (e.g., for Layer-3 relaying), and possibly additional information regarding relaying. The message may also contain information about other CCIs and other nearby relay UEs. If relaying for a given CCI is denied by the AMF served by the relay UE in Step 4 / 5, the relay UE may not send a response to the remote UE or may send a direct communication rejection message [24.587]. This may be used to send information about other CCIs and other nearby relay UEs to the remote UE. This direct communication acceptance / rejection message corresponds to the response message (N) used in other parts of this document.

[0192] Step 7: After successfully completing steps 2-6, the remote UE may initiate indirect communication to the core network by using the PC5 connection set up between the remote UE and the relay UE using the direct communication request / acceptance procedure. The relay UE then relays the received traffic from the remote UE to the network. In the case of a Layer 2 relay (i.e., forwarding PDCP messages), the remote UE can start / restart a PDU session by sending a registration / service request to the network. This requires the remote UE to restrict the PDU parameters it uses (e.g., in initial registration) to the configured PDU parameters related to the CCI received in the direct communication accept message. In the case of a Layer 3 relay (i.e., forwarding IP packets), the remote UE receives IP address information from the relay UE that can be used to send IP traffic to the relay UE. The relay UE then forwards it to the correct destination based on the configured PDU parameters related to the CCI. If the remote UE wishes / needs to establish a PDU session using different PDU parameters (e.g., different S-NSSAI or different CAG ID / NID), the remote UE repeats steps 2-7. In the case of Layer 2 relay, each time the remote UE sets up a new PDU session, the AMF must verify that the PDU parameters used correspond to the CCI received in step 4. If they do not, the AMF may reject the PDU session or send an RRC reconfiguration or UE configuration update message to the remote UE via the indirect connection.

[0193] Figure 6a shows a computer-readable medium 1000 having a writable portion 1010 containing a computer program 1020. The computer program 1020 includes instructions for causing a processor system to execute one or more of the methods and processes described above with reference to Figures 1 to 4. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical trace or by magnetization of the computer-readable medium 1000. However, any other suitable embodiment is also conceivable. Furthermore, although the computer-readable medium 1000 is shown here as an optical disc, the computer-readable medium 1000 may be any suitable computer-readable medium such as a hard disk, solid-state memory, or flash memory, and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to execute the methods described above.

[0194] Figure 6b is a schematic diagram of a processor system 1100 according to one embodiment of the device or method described with reference to Figures 1 to 4. The processor system may comprise a circuit 1110, for example, one or more integrated circuits. The architecture of the circuit 1110 is schematically shown in the figure. The circuit 1110 comprises a processing unit 1120 (e.g., a CPU) for executing computer program components to perform a method according to one embodiment and / or to implement a module or unit. The circuit 1110 includes a memory 1122 for storing programming code, data, etc. Part of the memory 1122 may be read-only. Part of the memory 1122 may be non-volatile. The circuit 1110 may comprise a communication element 1126, for example, an antenna, transceiver, connector, or both. The circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, memory 1122, dedicated IC 1124, and communication element 1126 may be interconnected via an interconnect 1130, for example, a bus. The processor system 1110 may be configured for wired and / or wireless communication using connectors and / or antennas, respectively.

[0195] In one embodiment, there exists a system comprising a device UE0 that operates as a cellular communication user device and can also operate as a remote UE, and a device UE1 that operates as a cellular communication user device and can also relay network traffic from UE0 to / from a CCS that supports relay operation (usually via a logical function called a network relay function (NRF) which can be coupled / integrated with any core network function (e.g., AMF, PCF, SMF, etc.)). a. Device UE0 sends a message to relay device UE1. The message may include the relay service code RSC1 (optionally encrypted). The relay service code identifies or is associated with a set of PDU session-related attributes (e.g., PLMN ID (+NID / CAG ID), (temporary / encrypted) S-NSSAI, (temporary / encrypted) DNN, PDU session type, group ID, QoS requirements (e.g., 5QI), frequency, security context, etc.). In addition, it includes the (optionally encrypted) identifier of UE0 and the (optionally encrypted) identifier of UE1 (e.g., as part of a secure envelope V). b. Relay device UE1 transmits to RSC1 and, optionally, V or one or more (encrypted) identifiers received from device UE0 (i.e., relay service code, identifier of UE0, identifier of UE1) to the cellular communication system CCS. c. Relay device UE1 receives a message from the CCS containing an encrypted relay service code RSC2. RSC2 is encrypted using authentication information shared between device UE0 and the CCS, but not with device UE1. Preferably, a different relay service code (RSC') is selected from a set of spare relay service codes available within the relay device. d. Relay device UE1 sends a message containing the encrypted relay service code RSC2 to device UE0. e. Device UE0 uses RSC2 instead of RSC1 in subsequent messages for discovering and / or setting up the connection to the relay device.

[0196] This approach has the advantage that, even if the discovery message and connection setup message themselves are not encrypted or authenticated, and the relay service code is sent in plain text, eavesdroppers (including relay device UE1 and other relay and remote devices) cannot track device UE0 using RSC1 after disconnection.

[0197] Furthermore, this is done efficiently because only the RSC used by the remote UE (i.e., device UE0) needs to be updated, and it is not necessary to update all RSC values ​​in all other remote UEs and / or relay UEs. Moreover, this can work even if the remote UE is outside the base station coverage of the network. Also advantageously, this procedure can be combined with a procedure to verify the authorization of the remote UE and relay UE to set up a relay connection for a specific relay service code and / or to set up a PDU session with the PDU session parameters associated with the relay service code. Furthermore / or, this procedure can be combined with a procedure to request a security key from the network to set up such a relay connection. Furthermore / or, this procedure can be combined with a procedure for relay device 1 to obtain or be provided with a set of privacy-sensitive PDU session-related parameters (e.g., slice identifier / NSSAI, DNN) associated with RSC1 for setting up a relay connection to the network (e.g., for a Layer 3 relay). Doing so allows for faster and more secure connection setup.

[0198] Detailed instructions are shown below and in Figure 8.

[0199] Step 0: The CCS, in particular the Network Relay Function (NRF) of the CCS, provides device UE0 (i.e., the remote UE) with a set of relay service codes that identify or associate with one or more PDU session-related parameters (e.g., S-NSSAI, DNN, etc.). This set may be limited to only the relay service codes associated with PDU session parameters that UE0 can use based on contract information within the CCS. Relay device UE1 (and other relay UEs) is provided with a set of relay service codes that UE1 can use / respond to during discovery, provided with or without information on their respective associated PDU session-related parameters. Preferably, some of the relay service codes provided to relay device UE1 are not yet assigned to the remote UE in these initial steps and / or are not yet assigned to a set of PDU session parameters (in that network or any remote UE or other relay UE), and are therefore considered spare (i.e., extra / unassigned) relay service codes. During Step 0, the relay UE may be further provided with a policy indicating the types of connections it supports, a long-term public / private key pair or other security material (e.g., as described in Steps 2 and 5 below) to be used by the remote UE (or relay UE) in subsequent messages to set up a relay connection through the relay UE, or a temporary ID or a randomization function for generating a temporary ID. Preferably, the policy and / or PDU session parameters may be signed by the core network along with the associated long-term public key.

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

[0201] Step 1: This is an optional step in which device UE0 and relay device UE1 exchange (via PC5) some discovery information that enables device UE0 to select relay device UE1 as the relay device that device UE0 (remote UE) wishes to use to send and receive messages with the CCS, such as the relay service codes it supports (as described in the following steps), and the identification information of the relay device. Relay service code RSC1 may be used for the discovery exchange. For security and privacy reasons, discovery information such as relay service codes must be protected (e.g., by encrypting it using a pre-configured discovery key (preferably the discovery key can only be decrypted by an authorized relay device that supports the relay service code requested by the remote UE)). For further privacy protection (including preventing the tracking of the remote UE during discovery by these UE-to-Network relays), the remote UE should frequently change the Layer 2 identifier used in discovery request messages (e.g., "Model B"), and it is preferable to use a different Layer 2 identifier for each subsequent request message. Furthermore, to avoid pattern detection, the remote UE should randomly space out the transmission of two subsequent messages (for example, by skipping a random number of resources allocated / scheduled for sidelink discovery), and, where possible, substitute by requesting other relay service codes supported by the remote UE, or by requesting them using a fake / random relay service code not supported by the remote UE, or by frequently changing the key to encrypt / ensure the payload of discovery messages.

[0202] A relay device may send a nonce and its public key within the discovery message. Furthermore, a relay device may send its policies and / or the types of connections it supports and / or the PDU session parameter values ​​or combinations of parameter values ​​it allows. A relay device may include a signature to verify the authenticity of the transmitted information. For efficiency, this may only be sent to the remote UE upon request.

[0203] The remote UE can verify the information received in the previous step (e.g., the policy and associated public key) (for example, by verifying that it is properly signed by the core network) and conclude that the relay UE supports its requirements (based on the received policy, relay service code, and PDU session parameters / connection type). The remote UE can then proceed to the next step and use the received public key to encrypt the PDU parameters or relay service code that it wishes to request from the relay UE.

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

[0205] The payload / envelope V may also contain the (unique) identifier of 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 with a key derived from the USIM of UE0. Alternatively, the relay service code, as well as the identifiers of device UE0 and relay device UE1, may be encrypted individually and included as separate parameters / fields in message M, or concatenated before encryption (e.g., some bits of the identifier of UE0 are concatenated with some bits of the identifier of UE0, or the hashes of each identifier are concatenated) and placed in message M. Note that SUCI stands for Subscription Concealed Identier, and is a privacy-protected identifier that includes a concealed SUPI. The UE generates the SUCI by using an ECIES-based protection scheme with the public key of the home network securely provided to the USIM during USIM registration. Relay device UE1 does not have the corresponding secret key for decryption and therefore cannot decrypt to obtain the SUPI. The value of SUCI may include the plaintext Home Network Identifier (e.g., Mobile Country Code / Mobile Network Code), but in the context of this explanation, it is considered an encrypted identifier, meaning the encryption scheme does not necessarily need to protect all bits of the identifier. The identifier may also be transmitted unencrypted within the same message, and the message may include a Message Authentication Code / hash / nonce / digital signature (e.g., generated using a cryptographic hash function such as HMAC) for integrity protection, which may be required for forwarding to the network for further verification. The Message Authentication Code may also cover the encrypted value and identifier to ensure that the encrypted value and identifier have not been tampered with.All of these various methods of combining information from UE0 and UE1 represent a protected / securely signed indicator that device UE0, acting as a remote UE, has selected relay device UE1 to set up an indirect / relay connection between UE0 and the CCS. The encryption method or (encryption) hash function may use additional values ​​as seeds, for example, a counter to prevent replay attacks, or other information received from or derived from previous messages from relay device UE1 (e.g., PHY level information such as the time of flight of the discovery message device received in step 1). These values ​​may be added to the (encrypted) payload / envelope. The key used for encryption may be a key derived from the USIM of UE0, a public key (e.g., provided by the CCS or relay UE), key material received from the relay UE during (restricted) discovery, or a pre-shared key (e.g., any key material to be used during such a procedure (e.g., a root relay connection key such as PRUK (ProSe Relay User Key) as defined in TS33.303, or long-term authentication information in TS33.536 that forms the security root of the PC5 unicast link) may be pre-provided to the remote UE (e.g., together with other information in step 0), and different key material may be used depending on whether the remote UE is inside or outside the gNB coverage) (or, for example, any key material to be used for a particular relay UE or within a particular tracking area may be pre-provided). The key used for encryption may also be the same key identified by the home network public key identifier of the remote UE's SUCI.

[0206] By concatenating the (encrypted) identifier of UE0 (e.g., SUCI / 5G-GUTI) with the (encrypted) identifier of UE1 selected by UE0 (e.g., by concatenating them in a secure envelope and / or by including the message authentication code mentioned above), it can be ensured that only the relay UE selected by UE0 can properly participate in this procedure (i.e., this represents a protected / securely signed indicator that device UE0, acting as a remote UE, has selected relay device UE1 to set up an indirect / relay connection between UE0 and the CCS). Furthermore, it can be prevented that a malicious UE could track UE0 based on knowledge it may have gained about the relay service code by intercepting traffic, manipulate / replay / interrupt the procedure, and gain access to privacy-sensitive information about UE0 or UE1. This works even if the message itself is not encrypted and authenticated, and the relay service code is sent in plain text.

[0207] Request message M may 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 than the Layer 2 ID used in the previous Model B discovery request message (e.g., by selecting a new random source Layer 2 IS). In fact, preferably, device UE0 should also use a different Layer 2 identifier each time it sends a request message (M), or at least one that is different from the previous request message (M).

[0208] Step 3: After receiving the request message M, relay device UE1 sends a message N, also called a forwarding request message (e.g., a service request, registration request, PDU session establishment request, relay request report, or other RRC or NAS message, or by forwarding a direct communication request), to the cellular communication system CCS, which contains (as is or decrypted / re-encrypted) one or more encrypted identifiers received from device UE0 in message M in Step 2, RSC1 and V. Message N may also contain a message authentication code received from device UE0. Furthermore, UE1 may verify the existence of its nonce to prevent replay attacks (e.g., if a nonce was sent to UE0 in Step 1). Alternatively or in addition, relay UE may limit the number of messages N to the CCS resulting from the received message M (e.g., based on a policy provided by the PCF, which may set such limits (per RSC, in some cases)).

[0209] Step 4: After receiving message N containing RSC1 and V or one or more encrypted identifiers, the CCS, in particular the NRF, determines (e.g., using core network functions such as PCF (Policy and Control Function) and / or DDNMF (Direct Discovery Name Management Function)) which RSC2 should be used instead of RSC1 next time. Such a new relay service code RSC2 can be used in place of the original value RSC1, but can be considered a kind of alias of the original RSC1, associated with the same PDU session parameters and authorization policy, for example. Preferably, relay service code RSC2 is selected from a set of spare relay service codes already stored in relay device UE1. The advantage of doing so is that relay device UE1 and other relay devices, remote UE devices, do not need to be updated, and only UE0 needs to be updated. These devices can later be updated using the normal PCF or DDNMF providing procedure, for example, occasionally, or after all spare relay service codes have been used to update the remote UE using the procedure described herein, when these devices enter coverage and are connected to the network. Preferably, the spare relay service code has not yet been assigned to a set of PDU session parameters, or it has been assigned to a default, general, or fake PDU session parameter.

[0210] The CCS (using core network functions such as AMF along with AUSF (Authentication Server Function), UDM (Unified Data Management) function, PKMF (ProSe Key Management Function)) can decrypt V or the encrypted identifier and securely determine that message N received from relay device UE1 in step 3 is related to UE0 and relay device UE1. 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 identification information stored in the CCS for device UE0 and relay device UE1. In other words, the CCS can verify whether the protected / securely signed indicator or a different representation of it (e.g., if relay device UE1 is permitted to re-encrypt part of the original indicator from UE0, or if it is permitted to decrypt the encrypted identifier for UE1 and replace it with another secure representation of device UE1's identification information) actually proves that relay device UE1 was selected by the remote UE (i.e., device UE0).

[0211] This step may be combined with a step to verify the network's authorization of the remote UE and relay UE to set up a relay connection for a specific relay service code and / or to set up a PDU session using the PDU session parameters associated with the relay service code, and / or to a step to request a security key from the network to set up such a relay connection. To that end, the contents of the exchanged messages and / or messages N and N' may be combined with a message used for the authorization / relay security setup procedure (for example, message N may be a NAS relay authorization request / key request message or a similar message, and / or each message may be extended by a field holding one or more identifiers, which are either an encrypted relay service code or an encrypted identifier received from device UE0, and message N' may be a NAS relay authorization response / key response message or a similar message, and / or each message may be extended by a field holding a decrypted relay service code or one or more decrypted identifiers, and a new (encrypted) relay service code RSC2). (For example, to determine the value of RSC2, which is selected from a set of spare relay service codes or is new (i.e., a relay service code that has not been used in the past or is not currently assigned), the CCS may maintain a set of tables that record which relay service codes have been used by which remote UEs and / or which PDU session information has been exposed to one or more relay UEs and / or which relay service codes are available (e.g., as spare relay service codes) to one or more relay UEs or remote UEs. The CCS can prevent replay attacks by not allowing the same message N to be used twice (within a given time frame).

[0212] Step 5: The CCS sends a response message N' (e.g., service request response, RRC connection reconfiguration, UE configuration update, relay request response / relay authorization, or other RRC or NAS message) to relay device UE1. Message N' includes an RSC2 encrypted with a key that is known or from which UE0 can derive a decryption key but relay device UE1 cannot. Examples of such decryption keys may include (e.g., a key based on UE0's USIM credentials encrypted by the latest remote UE's Kausf (see [TS33.501]), or a signed public key of a remote UE (which may be sent to the relay UE as part of a direct communication request then forwarded to the core network), or a decryption key derived from key material provided during the initial provisioning of the remote UE (e.g., along with other information in Step 0).

[0213] Step 6: Relay device UE1 sends a response message M' (e.g., a direct communication response message or a direct discovery response message via PC5 or by forwarding message N') to UE0, where response message M' includes the encrypted RSC2 received by relay device E1 as part of message N' in Step 5.

[0214] Step 7: UE0 decodes RSC2 and updates a table containing the set of relay service codes received in Step 0 and their associated PDU session parameters, or stores information that RSC1 has been replaced by RSC2 in memory or non-volatile storage. If not already started, UE0 may use the PDU session attributes associated with RSC1 to initiate an indirect communication session with the CCS via relay device UE1.

[0215] Step 8: During subsequent discovery and connection setup messages via PC5, UE0 uses (decoded) RSC2 instead of RSC1 to find or set up relay connections that were associated with RSC1 but are also associated with the same PDU session attribute, or are newly associated (i.e., after Step 6) with the same PDU session attribute and are expected to utilize that PDU session attribute.

[0216] In a further element of one embodiment, the relay device UE1 is provisioned by the CCS to store only a set of relay service codes without any information about PDU session parameters, or each relay service code is associated with a set of unique temporary identifiers representing privacy-sensitive PDU session parameters (e.g., temporary slice identifiers or temporary DNN identifiers known to the CCS to be associated with the same S-NSSAI).

[0217] The advantage of doing this is that the remote UE can look up one of the spare service codes the next time, and the relay UE cannot associate the spare service codes with the same slice / DNN or the same remote UE (assuming the Layer 2 ID has changed in the meantime). Note that it is assumed that RSC2 is encrypted using a key that can only be decrypted by device UE0 (e.g., a key derived from device UE0's USIM authentication information). The identifier of UE0 may be, for example, GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier). The identifier of UE1 may be a Layer 2 identifier used in the PC5 discovery message or other PC5 messages received from relay device UE1, or another identifier (such as GUTI / TMSI / SUCI) received as part of the PC5 discovery message 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 looks up the old RSC. This can be mitigated by limiting the validity period of RSCs, and / or by reusing RSCs for other PDU session parameters (to ensure that the relay UE cannot reliably know the PDU session parameters corresponding to a particular 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).Furthermore, if relay device UE1 is part of a spare set of relay service codes, it may automatically publish or respond to RSC2 during PC5 discovery, or it may be triggered by CCS by sending a separate message to relay device UE1 containing one or more relay services, including RSC2, at a random time preferably after UE0 has disconnected (to ensure that relay device UE1 cannot associate RSC1 and RSC2).

[0218] Relay service codes can be reused (for example, by associating PDU session parameters in the CCS with specific remote UE and relay UE combinations), but this can require complex management. After some time, if all spare relay service codes have been used, or if there is a policy to periodically update all relay service codes, all (potential) remote UEs and (potential) relay UEs need to be given a new set of relay service codes. In that case, the UEs typically need to be within the coverage of the base stations in the core network to connect directly and securely to the core network without going through potentially insecure connections via relay UEs. If some (potential) remote UEs remain out of coverage for extended periods, these UEs may continue to use the old set of relay service codes because they have not been updated when discovering and connecting to relay UEs. This can lead to errors and also create security and privacy risks. If such information is outdated when a remote UE connects to a relay device, it is preferable to send an encrypted relay service code using (U)SIM authentication information (e.g., the remote UE's latest Kausf) along with a freshness parameter indicating that the key has not been updated for some time (e.g., by using a key freshness parameter or a value indicating the date and time the last updated set of relay service codes was received). If this parameter indicates that the remote UE's relay service code and key have not been updated for some time, the relay UE and / or CCS should refuse to use this relay service code, refuse to set up the relay connection, and not provide the relay UE with PDU session parameters. In such a situation, the relay UE may send the encrypted relay service code and freshness parameter to the CCS. The CCS can then assign a new RSC2 to the remote UE (and relay UE) and send it back to the relay UE as an encrypted payload.The relay UE sends it to the remote UE, which can then use this new RSC2 to connect to the network (for example, by using the default set of PDU session parameters for the default slice).

[0219] It should be understood that it is possible to use both an encrypted identifier and a selection of an RSC from a set of spare RSCs in combination.

[0220] In a further element of one embodiment, the cellular communication system CCS sends a message N' containing an encrypted relay service code RSC2 or PDU session information related to RSC1 to the relay device UE1 only if the output of the received secure envelope V or the decryption of the received encrypted identifier represents the identifier of the relay device UE1, or if the message authentication code forwarded by the relay device and transmitted by UE0 represents an unmanipulated identifier, or if the information received in message N can be used to uniquely identify the relay device UE1.

[0221] The advantage of doing so is that a relay UE not selected by the remote UE cannot receive a new RSC2 or PDU session information related to RSC1 by replaying a message from the selected relay UE or by sending its own message containing RSC1 to the CCS. It is assumed that the protected envelope V, encrypted identifier, or message authentication code is encoded / encrypted / encoded / hashed using a key derived from the USIM authentication information. The CCS may use the information provided by the message payload having the encrypted envelope V, encrypted identifier, or message authentication code to perform additional verification to determine whether relay device UE1 is authorized / approved to act as a relay UE for the remote UE, and may send an encrypted verification code to device UE0 as part of the same message containing the encrypted relay service code RSC2.

[0222] In a further element of one embodiment, RSC1 is either added to a protected envelope / payload V or sent as an encrypted value (e.g., using a public key received during relay discovery) as part of a message M. The encrypted RSC1 may then be included in a message N by the relay device, and CCS may send a message to the relay device UE1 containing an encrypted relay service code RSC2 or PDU session information related to RSC1, only if the message N contains RSC1 (e.g., the original encrypted version or a decrypted or re-encrypted version) and a unique identifier for UE1, or if the message N contains RSC1 and the information received in the message N can be used to uniquely identify the relay device UE1.

[0223] In one example, the payload of message M may include the SUCI or 5G-GUTI of the remote UE (i.e., ID_Remote), and / or the encrypted relay service code (RSC), and / or the SUCI or 5G-GUTI of the relay device selected by the remote UE device (UE0) (i.e., ID_Relay). Additionally, or independently, the payload of message M may include the nonce N_Relay received from the relay device (UE1), a new nonce N_Remote generated by the remote UE device, and / or a message authentication code. The relay service code and the identification information of the selected relay UE may be encrypted (together) to prevent an eavesdropper from associating these identification information with the remote UE device. Preferably, encryption is performed using key / authentication information that allows the CCS to decrypt the information while preventing the information from being decrypted by the relay device (or at least an unselected relay device). This ensures that only the relay device selected by the remote UE receives and approves the PDU session parameters from the network and / or obtains the key to set up the relay connection. The key used for encryption (K_enc) may be derived from the USIM (e.g., the latest Kausf or Kseaf established by the remote UE with the CCS), or from long-term security material for the relay connection or PC5 link setup received in step 0 (e.g., PRUK as defined in TS33.303, or long-term authentication information as defined in TS33.536, or other pre-shared or public key to secure communication between the CCS and the remote UE). The nonce N_Relay and / or N_Remote may 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 may be calculated using the integrity key K_int as follows:After receiving the MAC(K_int,ID_Remote|N_Relay|N_Remote|ENCRYPT(K_enc,RSC|ID_Relay)) message M, relay device UE1 sends message N to CCS. Message N may contain ID_Remote, the (encrypted) relay service code and / or the (encrypted) ID_Relay of the selected relay device (e.g., SUCI / 5G-GUTI), or the encrypted bound value of RSC and ID_Relay (e.g., ENCRYPT(RSC|ID_Relay)). It should be understood that SUCI is already an encrypted identifier, but can be re-encrypted using a different key, which has the advantage of securely binding the identifier to RSC.

[0224] Message N may contain a nonce and message authorization code within the NAS relay authorization request / key request. Upon receiving Message N, the CCS (e.g., AMF and AUSF / UDM / PKMF) may derive K_enc and K_int based on ID_Remote and the received nonce, check the integrity of the message fields, and decrypt the encrypted RSC and / or encrypted value ENCRYPT(RSC|ID_Relay) to obtain the RSC and ID_Relay. The CCS may also verify that ID_Relay matches the identification information of the UE-to-Network relay that sent the message before proceeding to subsequent steps. The CCS and / or relay device may track the nonce used and prevent replay attacks by discarding the message if the nonce is reused. Similarly, the CCS may track the 5G-GUTI or SUCI used to verify that the same value is not used multiple times. The CCS may track the number of requests from a particular remote UE, relay device, or remote to verify that the maximum number of requests within a given time window has not been exceeded. The CCS may send its nonce to a remote UE or relay device and wait for an acknowledgment message from the device using it.

[0225] As described above, only the CCS can decrypt the requested relay service code. If the relay device UE1 has PDU session attributes associated with a supported relay service code pre-configured during initial provisioning, the decrypted relay service code must be provided to the relay device after it has been decrypted by the CCS, preferably only after it has been confirmed that the relay device and the remote UE are authorized to set up a relay connection for that relay service code via the selected relay device. This can be done by adding the decrypted relay service code to response message N'. The relay device can use the decrypted relay service code to retrieve the PDU session attributes associated with the relay service code and set up a PDU session to the core network according to those PDU session attributes.

[0226] In the above embodiment, ID_Remote is transmitted without additional encryption (i.e., SUCI is already encrypted by the home network public key) and (after being forwarded by the relay device) can be used by the CCS to identify the corresponding decryption key, or to select the correct AUSF, PCF, UDM, PKMF, or other network service responsible for authentication, provisioning / configuration, contracting, prose key management, and other network services within the home or visiting network of the remote UE. For example, after selecting the correct AUSF / PCF / UDM / PKMF, the CCS may provide a decryption key (e.g., derived from Kausf) to decrypt the encrypted value ENCRYPT(RSC|ID_Relay) or request the corresponding network service to decrypt the encrypted value ENCRYPT(RSC|ID_Relay). The CCS may also use ID_Remote to select the correct PCF, or other network service responsible for assigning a new relay service code. To further protect the identity of the remote UE, ID_Remote is not sent in plaintext, but also as part of an encrypted value (i.e., by concatenating RSC, ID_Remote, and ID_Relay before encryption (ideally by using key / authentication information that the relay device cannot decrypt, but which allows the CCS to decrypt)). ID_Remote is provided to the relay device (in response message N') only after it has been decrypted by the CCS and preferably after it has been confirmed that the relay device and the remote UE have the authority to set up a relay connection for its relay service code via the selected relay device.

[0227] The advantage of doing this is that other nearby remote UEs that may be using the same RSC and may be provided with the PDU session parameters associated with that RSC cannot compromise privacy by tracking other remote UEs and monitoring unprotected PC5 discovery and connection setup-related traffic, because in this case the RSC is not sent in plain text, and furthermore, the RSC2 used after the remote UE disconnects from the relay UE is unknown. Also, by securely concatenating the relay service codes (e.g., via a protected payload / envelope or message authentication code that can only be decrypted by the core network), a malicious relay UE cannot easily replace one relay service code with another. Furthermore, an unselected relay UE cannot easily request the CCS to engage in relaying with remote UEs regarding the relay service code.

[0228] In a further element of the present invention, which may be combined with any other embodiment or implemented independently, device UE0 is provided with a set of spare / equivalent RSCs associated with the same PDU session parameter set, and device UE0 selects one of these spare / equivalent RSCs in a discovery or connection setup message to the relay UE via PC5 (for example, randomly or by rotating these spare / equivalent RSCs periodically).

[0229] This makes it more difficult for other UEs to understand the correlation between RSC values ​​and PDU session parameters, and extends the lifespan before they have to update the RSC values ​​and their mapping to PDU session parameters.

[0230] In further elements of embodiments that may be implemented in combination with or independently of any other embodiments, device UE0 and / or relay device UE1 are provided in step 0 with policies, rules, and information necessary to enable the current valid RSC to be generated pseudo-randomly based on time (assuming the remote UE can know the current time via an internal clock or an external reference clock (e.g., GPS, or provided using a synchronous frame from a base station or relay device)) by using a pseudo-random number function (PRF) (e.g., a range of values, wildcards, a randomization seed, a function to generate them, such as a hash function such as SHA-2 or SHA-3, an extensible output function such as SHAKE, or a DRBG as defined in NIST.SP.800-90). To address slight time differences that may result in different relay service codes (RSCs), a message exchange between the remote UE and the relay UE (e.g., the following challenge / response authentication handshake where the seeded RSC is the key) may be performed, assuming that both have a seed for generating the RSC. a) A remote UE announces its presence by randomly generating a nonce N_UE and broadcasting it. b) Relay UE receives N_UE, generates a non-relay N_R, and derives a pseudo-random RSC for all 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 the hash function, | indicates concatenation, and Truncate(X, b) returns b bits of X, e.g., b least significant bits. c) Relay UE returns its own N_R and all calculated PRF_RSC_i values. d) The remote UE performs a similar calculation based on the received N_R and checks if one of the PRF_RSC_i is the same. If a match exists, it selects that relay.

[0231] After connecting to the relay UE using an RSC valid at that particular time (perhaps running a corresponding pseudo-random RSC generator for one or more remote UE groups and / or using a wildcard for matching RSCs for one or more remote UE groups), the CCS may in step 4 generate a new range, a wildcard, and a randomization seed for the pseudo-random RSC generator, instead of determining RSC2, or in addition to that, and transmit this information as part of message N' by encrypting this information with a known key, or a key from which UE0 can derive a decryption key (for example, based on the USIM authentication information of UE0) but which relay device UE1 cannot derive.

[0232] The advantage of doing this is that as more relay service codes are used over time, it becomes very difficult for eavesdroppers (including remote UEs running other pseudo-random key generators or using other ranges or seeds) to tie relay service codes to specific remote UEs and specific PDU session parameter sets. In this way, duplication of relay service codes between remote UEs can be prevented without hindering scalability.

[0233] In further elements of embodiments that may be implemented in combination with any other embodiments or independently, device UE0 includes a GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier) ​​as part of a message M to the relay UE and a subsequent message N to the CCS, in order for the CCS to uniquely identify the remote UE. Upon receiving message N, the CCS sends a new encrypted GUTI, TMSI, or SUCI to device UE0 via relay device UE1.

[0234] The reason for doing this is that the GUTI, TMSI, or SUCI may need to be discovered and / or sent in plaintext via PC5 along with the communication request so that the CCS can identify the key used to decrypt the protected envelope V and / or encrypted identifier. If this is done, the GUTI / TMSI / SUCI will be exposed and should not be reused, so it will need to be updated. The CCS may also verify that the GUTI / TMSI / SUCI sent with the message corresponds to the identifier of UE0 sent within the protected envelope V or as an encrypted identifier.

[0235] In a further element of one embodiment, the CCS sends the updated Layer 2 ID or other updated identifier (e.g., an update to the temporary identifier received in step 0) of device UE0 and / or relay device UE1 as part of response message N' for use in subsequent messages between UE0 and UE1. Alternatively, device UE0 and / or relay device UE1 may assign themselves new Layer 2 IDs upon receiving response message N', or after sending response message M', or after UE0 and UE1 are disconnected from each other, or the CCS may trigger device UE0 and / or relay device UE1 to update their Layer 2 IDs by sending a separate message.

[0236] The reason for this is that Layer 2 IDs or other (temporary) identifiers used between UE0 and UE1 may be transmitted unencrypted during message exchange, potentially exposing privacy-sensitive information. Therefore, it is necessary to update Layer 2 IDs or other (temporary) identifiers transmitted unencrypted between UE0 and UE1 to provide additional protection against malicious tracking of devices. Note that UEs typically use GUTI / SUCI, where SUCI is an encrypted version of SUPI and is used to conceal the UE's long-term identification information. After authentication using SUCI, a GUTI is assigned to the UE for subsequent connections. In this document, a temporary identifier is introduced as an alternative because relays can collect many GUTIs or SUCIs. Relays can also prevent UEs from receiving responses from CNs. This can affect remote UEs if a remote sends its own GUTI and does not receive the expected response. This may force the UE to use the more costly SUCI next time. In general, relays can cause synchronization errors in the mapping GUTI-SUPI, which increases latency. This may be a reason to introduce a third temporary identifier as described above. Such a third temporary identifier may be of interest on its own and may be used in conjunction with other solutions. For example, in the context of solutions #1, #6, #10, and #15 in TR33.847, a remote may send a request to the CN to establish a secure PC5 link with the relay. This third temporary ID may be derived in the same way as the GUTI and may be used only in the relay configuration, or it may be derived from the current GUTI.

[0237] In a further element of an embodiment that can be combined with any other embodiment or implemented independently, if, after transmitting RSC1 to relay device UE1 to provide further protection from malicious relay UEs, a new RSC value (i.e., RSC2) is not obtained after a certain timeout period has elapsed, device UE0 temporarily stops operating as a remote UE and temporarily blocks / halts / interrupts the ongoing relay procedure. Device UE0 waits until it enters the coverage of the gNB, attaches to the gNB, and then requests an RSC update before starting the remote UE function, and can resume operating as a remote UE.

[0238] The reason for this is that since the response N' sent to the relay UE by the CCS is never transferred to the remote UE, the remote UE may not recognize the need to use a new RSC and may continue to use the old RSC.

[0239] In a further element of an embodiment, to prevent another relay device from sending a request message with the same content as message N to the CCS, relay device UE1 enables the CCS to verify whether the encrypted identifier of UE1 received within message N corresponds to the second encrypted identification information or signature, and / or whether these encrypted identifiers directly or indirectly identify the same relay device (i.e., in this case, relay device UE1), or are related to the same relay device, by sending the second encrypted identification information or signature. This can also be achieved by associating the encrypted identifier of relay device UE1 with the identifier used by the relay device to set up a secure link between the relay device and the CCS for transmitting message N.

[0240] Note that if the mobile device uses the PC5 layer 2 identifier as the identifier of relay device UE1 as input for message M (e.g., used during discovery), the following procedure may apply and the above detailed procedure may be enhanced.

[0241] a. When the PC5 layer 2 identifier used by the relay device UE1 is securely set / provided by the CCS (e.g., using a secure connection between the PCF and the relay device UE1 and / or the device UE0), 1. The relay device UE1 has a secure authenticated connection to the CCS. The CCS can obtain the information set / provided to the relay device UE1 and check whether the PC5 layer 2 identifier set / provided to the relay device UE1 corresponds to or refers to the same PC5 layer 2 identifier for the relay device UE1 that is encrypted and transmitted as part of the message N (derived from the message M sent by the device UE0). 2. If the relay device UE1 does not have a secure authenticated connection to the CCS, the relay device UE1 can encrypt (or add as part of a signature) its GUTI / TMSI / IMSI / SUPI / SUCI / GPSI, other unique identifier, or its hash to the message N (in addition to the envelope V or encrypted identifier received by the relay device UE1 in the message M from the device UE0). Thereby, the CCS can associate this information with the PC5 layer 2 identifier set / provided to the relay device UE1 and check whether it corresponds to or refers to the same PC5 layer 2 identifier that is encrypted and transmitted as part of the message N (derived from the message M sent by the device UE0).

[0242] b. If the PC5 Layer 2 identifier is self-assigned, relay device UE1 can securely transmit the self-assigned PC5 Layer 2 identifier to the CCS (for example, each time a new Layer 2 identifier is assigned). The CCS can store this information and associate it with other identifiers it has stored for relay device UE1. The CCS can use this information to determine whether the self-assigned PC5 Layer 2 identifier of relay device UE1 corresponds to or points to the same PC5 Layer 2 identifier received encrypted as part of message N (derived from message M transmitted by device UE0).

[0243] When CSS sets / provides a PC5 Layer 2 identifier, CSS may set / provide a remote UE (i.e., device UE0) with a set of PC5 Layer 2 identifiers that a particular relay UE can use, or it may provide a mapping between the relay UE's PC5 Layer 2 identifier and a set of other identification information for the relay UE (e.g., GUTI / TMSI / SUCI).

[0244] In further elements of embodiments that may be implemented in combination with or independently of any other embodiments, the relay device UE1 receives an updated list of relay service codes from the CCS upon (initial) registration with the CCS (e.g., when entering a new registration area) or upon setting up a PDU session with the CCS (e.g., for relay purposes), which contains only relay service codes associated with authorized network slices / S-NSSAI valid within its registration area for the remote UE and / or relay device (determined by AMF, PCF, DDNMF, NG-RAN), and (temporarily) replaces or updates the list of relay service codes (and their associated PDU session parameters) already provided within the relay device, or stores it as a separate list. Alternatively, a list of relay service codes associated with unauthorized network slices / S-NSSAI within its registration area is received from the CCS, updating the list of relay service codes (and their associated PDU session parameters) already provided within the relay device. Alternatively, a discovery filter to be applied during discovery is received, which matches only relay service codes associated with authorized network slices / S-NSSAI.

[0245] Similarly, in the case of non-public network access, when relay device UE1 registers with a base station dedicated to that non-public network (e.g., identified as a CAG (Closed Access Group) cell), an updated list of relay services is received from the CCS, containing only relay service codes associated with non-public network identification information / CAGs that are valid / permitted / authorized for access by remote UEs and / or relay devices (determined by AMF, PCF, DDNMF, NG-RAN), and the list of relay service codes (and associated PDU session parameters) already provided within the relay device is (temporarily) replaced or updated, or stored as a separate list. Alternatively, a list of relay service codes associated with non-public network identification information / CAGs that are not valid / permitted / authorized for access by remote UEs and / or relay devices is received from the CCS, and the list of relay service codes (and associated PDU session parameters) already provided within the relay device is (temporarily) updated, or stored as a separate list. Alternatively, discovery filters to be applied during discovery are received that match only relay service codes associated with non-public network identifiers / CAGs that are enabled / allowed / authorized for access by remote UEs and / or relay devices.

[0246] Solution 18 of TR33.847 describes a protocol for authentication and PC5 link setup for UE-to-Network relay. The main steps are as follows: In step 0, the CN, in particular PKMF and DDNMF, provides the remote UE and the relay UE with discovery parameters, PKMF addresses, or parameters including discovery parameters.

[0247] In Step 1, the remote UE executes a remote user key request and retrieves the PRUK and PRUKID from the PKMF.

[0248] In step 2, the discovery procedure is performed, for example, based on TS33.303, or as in solutions 3 and 4 of TR33.847.

[0249] In step 3, the remote UE sends a direct communication request to the relay UE, which includes parameters such as PRUKID, relay service code, and first freshness parameter.

[0250] In step 4, the relay UE sends a key request to the core network to obtain the K_NRP in order to secure the PC5 interface with the remote UE, and also sends a second freshness parameter. The K_NRP is derived from the PRUK and freshness parameters.

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

[0252] The problem with this Solution 18 in TR33.847 is that in step 3, the relay service code and PRUKID are exchanged in plain text, which constitutes the privacy issue identified in the above embodiment. This is why S3-212859 proposes extending Solution 18 by scrambling these fields in step 3, either in combination with any other embodiment, implemented independently, or as a further element of an embodiment that may be combined with the procedure of Solution 18 in 3GPP® TR 33.847.

[0253] For additional privacy protection, the remote UE should encrypt or scramble the remote UE and / or relay UE identifiers for relay service codes (RSCs) and / or direct communication requests using a different key or pseudo-random sequence than the key used to encrypt / scramble discovery parameters as part of the discovery message in past Model B discovery solicitation messages, for example by using a different FC value (as defined in TS33.220) as input to the key derivation function.

[0254] This could help prevent eavesdroppers from linking discovery messages to associated direct communication request messages. For example, S3-212859 proposes a privacy enhancement where the RSC transmitted within a DCR message is protected (scrambled) by the DUSK (Discover User Scrambling Key) in the remote UE's code-receiving security parameters. However, this does not provide sufficient protection as it is proposed to use the same DUSK to protect both the RSC and the PRUK (Prose Relay User Key) ID. If this key is also used to scramble discovery messages, and the UTC counters remain identical due to the very fast exchange of discovery and DCR messages, the same scrambled 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 performing an XOR on the two scrambled sequences, the XOR of the two sets of information is obtained, i.e., the XOR of the discovery message and the PRUK ID|RSC. This is the XOR of two plaintexts and poses a security risk as the individual parts can be guessed.

[0255] To protect against such security risks, and advantageously as described in this embodiment, it is preferable to specify the use of a different pseudo-random sequence for scrambling the relay service code and PRUK ID by using a different FC value for discovery messages than that for direct communication request messages, in order to prevent this problem when using the same DUSK. Alternatively, a different key should be used, which is distributed during initial provisioning, during message exchange with a CCS (e.g., DDNMF), or during discovery.

[0256] Furthermore, in accordance with the embodiments described above, the procedure of S3-212859 should be extended to include a step in which the CCS (e.g., DDNMF) assigns a new relay service code value to be used in place of the relay service code used in step 4a for subsequent discovery messages. This new relay service code value is sent to the remote UE (e.g., by extending the key response message to the relay UE in step 4b and the subsequent direct security mode command message in step 5a with an additional field containing the new relay service code, or by extending it with a different message (e.g., a set of PC3 messages between DDNMF and the remote UE)), and the relay service code may be protected using a key derived from PRUK (Prose Relay User Key) (e.g., based on ID) by using a key derivation function having an S string which may include the K_NRP freshness parameter 1 and a UTC-based counter.

[0257] Furthermore, in accordance with the embodiments described above, the procedure of S3-212859 should be extended by the relay UE including a nonce during discovery step 2. The received nonce should be sent by the remote UE in a subsequent direct communication request message (e.g., as an additional field). The relay UE receiving the direct communication request message can verify the freshness of the nonce and ensure there is no replay attack. Alternatively or additionally, the remote UE should use the received nonce instead of a UTC-based counter in step 1 of 6.18.2.2.2 of S3-212859 (i.e., to ensure different scrambling sequences). This ensures different scrambling sequences, and if the relay UE has a policy that each nonce sent as a replay to the discovery message can be used only once when forwarding the DCR message, the relay UE can avoid a replay attack.

[0258] Alternatively, or in addition, the relay UE can limit the number of messages to the CCS (e.g., key request messages) that result from received direct communication request messages (for example, based on a policy provided by the PCF, which may allow such limits to be set per RSC).

[0259] As described above, various methods for use in cellular communication systems are provided. The first method includes the step of performing a relay function in a mobile device. The second method includes the step of performing the functions of a relay processor in a relay device. The third method includes the step of performing a network relay function in a cellular network.

[0260] As will be apparent to those skilled in the art, there are many different ways of implementing the method. For example, the order of stages or steps can be changed, or some stages can be executed in parallel. Further, other method steps can be inserted between steps. The inserted steps may be those that improve the method as described herein, or may be unrelated to the method.

[0261] A computer program product is provided that is downloadable from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium. The computer program product includes program code instructions for implementing the above method, connection sequence, security process, and further operations when executed on a computer device. Thus, the method according to the present invention can be executed using software that includes instructions for causing a processor system to execute a corresponding method

[0262] Typically, a mobile device, a relay device, and an NRF each include a processor coupled to a memory that holds appropriate software code stored in the device. For example, the software may be downloaded and / or stored in a corresponding memory, such as a volatile memory like RAM, or a non-volatile memory like flash (not shown). The device may include, for example, a microprocessor and a memory (not shown). Alternatively, the device may be implemented, in whole or in part, as programmable logic, for example as a field programmable gate array (FPGA). The device and the server may be implemented, in whole or in part, as a so-called application specific integrated circuit (ASIC), that is, an integrated circuit (IC) customized for a specific application. For example, the circuit may be implemented in CMOS using a hardware description language such as Verilog, VHDL, etc.

[0263] The software may include only steps taken by a specific sub-entity of the system. The software may be stored on a suitable storage medium such as a hard disk, floppy disk, or memory. The software may be delivered as a signal over a wired or wireless connection, or using a data network such as the Internet. The software may be available for download and / or remote use on a server. The methods according to the present invention may be executed using a bitstream configured to constitute programmable logic, such as a field-programmable gate array (FPGA), to perform the method. The software may take the form of source code, object code, code intermediate source and object code such as a partially compiled form, or any other form suitable for use in carrying out the methods according to the present invention. Embodiments relating to a computer program product include computer executable instructions corresponding to processing steps of at least one of the above methods. These instructions may be stored in one or more files that can be subdivided into subroutines and / or linked statically or dynamically. Other embodiments relating to a computer program product include computer executable instructions corresponding to at least one of the above system and / or product means.

[0264] For clarity, the above description describes embodiments of the present invention in relation to various functional units and processors. However, it will be understood that functions can be arbitrarily and appropriately distributed among different functional units or processors without departing from the present invention. For example, a function shown to be performed by multiple separate units, processors, or controllers may be performed by the same processor or controller. Thus, references to specific functional units should be considered not as indicating a strict logical or physical structure or configuration, but as references to appropriate means for providing the described functions. The present invention can be implemented in any appropriate form including hardware, software, firmware, or any combination thereof.

[0265] In this document, the verb "to have (including, to possess)" does not exclude the existence of elements or steps other than those enumerated, and singular elements do not exclude the existence of multiple such elements. Expressions accompanying enumerated elements, such as "at least one of ~", represent a selection of all elements or any subset of the enumerated elements. For example, the expression "at least one of A, B, and C" should be understood to include A only, B only, C only, both A and B, both A and C, both B and C, or all of A, B, and C. No reference numeral limits the scope of the claims. The present invention can be implemented by both hardware and software. Several "means" or "units" may be represented by the same hardware or software item, and a processor may, in some cases, work with hardware elements to perform the function of one or more units. Furthermore, the present invention is not limited to embodiments, and extends to all novel features or combinations of features described above or in the dependent claims that differ from each other.

[0266] In summary, a cellular communication system supports network slicing and includes a network relay function to manage indirect connections. A mobile device can send a request message to a relay device containing a relay service code (associated with a set of privacy-sensitive PDU session parameters). The relay device receives the request message and sends a forwarding request message to the cellular communication system indicating a request to transfer data over the indirect connection and containing the requested relay service code. The network relay function receives the forwarding request message, determines a different relay service code (from a set of spare relay service codes) that should be used instead of the requested relay service code, and sends a forwarding response message to the server. The forwarding response message contains the different relay service code, encrypted so that the mobile device can decrypt it, but the relay device cannot. The relay device forwards the encrypted different relay service code to the mobile device in response to the initial request message.

[0267] References: [22.261] 3GPP(registered trademark) TS 22.261 v16.7.0, Service requirements for the 5G system; Stage 1, 2019-03. [22.866] 3GPP(registered trademark) TR 22.866 v0.2.0, enhanced Relays for Energy Efficiency and Extensive Coverage; Stage 1, 2019-02. [23.287] 3GPP(registered trademark) TS 23.287 v1.0.0, Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services (Release 16), 2019-05. [23.303] 3GPP(registered trademark) TS 23.303 v15.0.0, Proximity-based services (ProSe); Stage 2 (Release 15), 2017-06. [23.501] 3GPP(registered trademark) TS 23.501, System Architecture for the 5G System; Stage 2, v16.0.2, 2019-04. [23.503] 3GPP(Registered Trademark) 23.503, TS Policy and Charging Stage 2 (Release 15.6.0 2019-06) [23.733] 3GPP(registered trademark) TR 23.733 v15.1.0, Study on Architecture Enhancements to ProSe UE-to-Network Relay (Release 15), 2017-12. [24.334] 3GPP(registered trademark) TS 24.334 v15.1.0, Proximity-services (ProSe) User Equipment (UE) to ProSe function protocol aspects; Stage 3, 2017-12. [24.501] 3GPP(registered trademark) TS 24.501, Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 (Release 15.4.0 2019-06) [29.507] 3GPP(registered trademark) TS 29.507, 5G System; Access and Mobility Policy Control Service; Stage 3, (Release 15.4.0 2019-06) [33.813] 3GPP(registered trademark) TR 33.813 v0.5.0, Study on Security Aspects of Enhanced Network Slicing, 2019-06. [36.300] 3GPP(R) TS 36.300 v15.2.0, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 15), 2018-06. [36.746] 3GPP(R) TR 36.764 v15.1.0, Study on further enhancements to LTE Device to Device (D2D), User Equipment (UE) to network relays for Internet of Things (IoT) and wearables; (Release 15), 2017-12. [38.300] 3GPP(registered trademark) TS 38.300 v15.5.0, NR; NR and NG-RAN Overall Description; Stage 2, 2019-03. [38.331] 3GPP(registered trademark) TS 38.331 v15.5.1, NR; Radio Resource Control (RRC) protocol specification, 2019-04. [38.473] 3GPP(registered trademark) TS 38.473, v15.4.1, NG-RAN; F1 application protocol (F1AP), 2019-01. [38.874] 3GPP(R) TR 38.874 v16.0.0, NR; Study on Integrated Access and Backhaul, 2018-12. [S2-1907204] 3GPP(Registered Trademark) TS 23.501 CR1522 Introduction of the IAB support in 5GS, 2019-06. [Elayoubi] Elayoubi et al., 5G RAN Slicing for Verticals: Enablers and Challenges, IEEE Communications Magazine Vol. 57 Iss. 1, 2019. [EventHelix] EventHelix website with a PDF file summary and a link to a detailed message: https: / / www.eventhelix.com / 5G / standalone-access-registration / [PavelShulgin] 5G StandAlone Access - Registration Procedure - Part2 (AMF selection procedures, slices), https: / / www.linkedin.com / pulse / 5g-standalone-access-registration-procedure-part2amf-pavel-shulgin /

Claims

1. A cellular communication system comprising a radio access network and a core network, including multiple cellular base stations, The cellular communication system provides a cellular network that supports indirect connections. Each indirect connection communicates with the wireless access network and provides data transfer between a mobile device and the cellular communication system via at least one relay device which is a mobile device capable of supporting the indirect connection, the cellular communication system includes at least one network relay entity which provides a network relay function (NRF) for managing the indirect connections, and the mobile device is The connection processor includes a connection processor that manages the connection to the cellular network, the connection processor provides a relay function for managing at least one indirect connection, and the relay function is As part of the setup procedure, a request message is sent to at least one relay device, the request message comprising a relay service code (RSC1) and an encrypted identifier of the at least one relay device, and further comprising an encrypted identifier of the mobile device. Receiving a response message containing an encrypted relay service code (RSC2) from at least one relay device, The procedure involves decrypting the encrypted relay service code and inserting the decrypted relay service code (RSC2') in place of the relay service code (RSC1) in subsequent discovery and connection setup messages, wherein the decrypted relay service code (RSC2') is associated with the same set of PDU session attributes as the relay service code (RSC1), and at least performing the following: The relay device is A communication unit that performs communication in the aforementioned cellular network, The system includes a relay processor that manages communications within the cellular network and manages indirect connections between the mobile device and the cellular network, wherein the relay processor The request message is received from the aforementioned mobile device. After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, the forwarding request message includes the relay service code (RSC1) and at least one of the encrypted identifiers received from the mobile device within the request message. The cellular communication system receives a forwarding response message, and the forwarding response message includes an encrypted relay service code (RSC2). After receiving the forwarding response message, a response message including the encrypted relay service code (RSC2) is sent to the mobile device in response to the forwarding response message. The aforementioned network relay function is The relay device receives at least one forwarding request message, the forwarding request message includes a relay service code (RSC1) and at least one of the encrypted identifier of the mobile device and the encrypted identifier of the relay device, Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message. The aforementioned different relay service codes (RSC2') are encrypted using a key that the mobile device can decrypt but the relay device cannot, thereby generating an encrypted relay service code (RSC2). A cellular communication system that transmits a forwarding response message, including the encrypted relay service code (RSC2), to the relay device.

2. The cellular communication system according to claim 1, wherein the network relay function encrypts the identifier of the mobile device and / or the identifier of the relay device using a key that can be decrypted by the network relay function in the cellular network but cannot be decrypted by the relay device.

3. A cellular communication system comprising a radio access network and a core network, including multiple cellular base stations, The cellular communication system provides a cellular network that supports indirect connections. Each indirect connection communicates with the wireless access network and provides data transfer between a mobile device and the cellular communication system via at least one relay device which is a mobile device capable of supporting the indirect connection, the cellular communication system includes at least one network relay entity which provides network relay functionality for managing the indirect connection, and the mobile device is The connection processor includes a connection processor that manages the connection to the cellular network, the connection processor provides a relay function for managing at least one indirect connection, and the relay function is As part of the setup procedure, a request message is sent to at least one relay device, the request message comprising a relay service code (RSC1), an identifier for the at least one relay device, and further including the identifier for the mobile device and a message authentication code. Receiving a response message containing an encrypted relay service code (RSC2) from at least one relay device, The procedure involves decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of the relay service code (RSC1) in subsequent discovery and connection setup messages, wherein the decrypted relay service code (RSC2') is associated with the same set of PDU session attributes as the relay service code (RSC1), and at least performing the following: The relay device is A communication unit that performs communication in the aforementioned cellular network, The system includes a relay processor that manages communications within the cellular network and manages indirect connections between the mobile device and the cellular network, The aforementioned relay processor The request message is received from the aforementioned mobile device. After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, and the forwarding request message includes the relay service code (RSC1), the message authentication code received from the mobile device within the request message, and the identifier of the mobile device. A forwarding response message containing an encrypted relay service code (RSC2) is received from the cellular communication system. After receiving the forwarding response message, a response message including the encrypted relay service code (RSC2) is sent to the mobile device in response to the forwarding response message. The aforementioned network relay function is The relay device receives at least one forwarding request message, the forwarding request message includes a relay service code (RSC1), an identifier for the mobile device, and a message authentication code. Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message. The aforementioned different relay service codes (RSC2') are encrypted using a key that can be decrypted by the mobile device but not by the relay device, thereby generating an encrypted relay service code (RSC2). A cellular communication system that transmits a forwarding response message, including the encrypted relay service code (RSC2), to the relay device.

4. The cellular communication system according to any one of claims 1 to 3, wherein the relay processor stores a set of spare relay service codes, and the network relay function selects the different relay service code (RSC2') from the set of spare relay service codes available in the relay device or from a new relay service code.

5. The cellular communication system according to claim 3, wherein at least one of the relay service code (RSC1), the identifier of the mobile device, and the identifier of the at least one relay device in the request message and the forwarding request message is encrypted by the mobile device or secured by the message authentication code to represent a protected indicator that the mobile device has selected the at least one relay device.

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

7. The cellular communication system according to claim 5 or 6, wherein the key used by the mobile device to encrypt the relay service code, the identifier of the mobile, and at least one of the identifiers of the at least one relay device, or the key used to determine the message authentication code, enables decryption by the network relay function in the cellular network, but does not enable decryption by the relay device.

8. The cellular communication system according to claim 5 or 6, wherein the network relay function transmits a forwarding response message to the at least one relay device, using the information received in the forwarding request message, including PDU session information related to the encrypted relay service code (RSC2) or the relay service code (RSC1), only if the output obtained by decrypting the received encrypted identifier represents an identifier of the at least one relay device, or if the message authentication code originating from the mobile device and forwarded by the at least one relay device indicates that the identifier has not been manipulated.

9. The cellular communication system according to claim 8, wherein the information provided by the message payload having the encrypted identifier or message authentication code in the forwarding request message is used by the cellular communication system to perform additional verification of whether the at least one relay device is permitted / authorized to operate as a relay for the remote device.

10. The cellular communication system according to any one of claims 1 to 9, wherein the mobile device transmits a freshness parameter in the request message, the freshness parameter indicating that the key used to encrypt the elements of the request message has not been updated for a predetermined time or indicates the time when the key was last updated.

11. The cellular communication system according to any one of claims 1 to 10, wherein the network relay function adds the decoded relay service code to the forwarding response message, and the relay device uses the decoded relay service code to obtain PDU session attributes.

12. A cellular communication system according to any one of claims 1 to 11, wherein the request message and the response message include GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier).

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

14. The cellular communication system according to any one of claims 1 to 13, wherein the mobile device includes a nonce in the request message, and the relay device tracks the used nonce and discards a request message containing a previously used nonce or aborts the setup procedure.

15. The cellular communication system according to any one of claims 1 to 14, wherein the mobile device includes a nonce in the request message, the relay device forwards the nonce in the forwarding request message, and the relay function tracks the used nonce and discards a request message containing a previously used nonce or aborts the setup procedure.

16. A cellular communication system according to any one of claims 1 to 15, wherein the mobile device includes a non-volatile storage unit that stores a set of relay service codes supported by the mobile device and each of which may be associated with a set of PDU session attributes, the mobile device stores a set of relay service codes supported by the mobile device and each of which may be associated with a set of PDU session attributes, the relay device includes a non-volatile storage unit that stores a set of relay service codes, including the set of spare relay service codes, the relay processor of the relay device stores the set of spare relay service codes, the network relay function determines a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message, and the different relay service code (RSC2') is selected from the set of spare relay service codes available in the relay device.

17. A mobile device used in a cellular communication system according to claim 1, wherein the mobile device is A transceiver that performs wireless communication within the cellular network and stores a set of relay service codes that are supported by the mobile device and can each be associated with a set of PDU session attributes, The connection processor includes a connection processor that manages the connection to the cellular network, the connection processor provides a relay function for managing at least one indirect connection, and the relay function is As part of the setup procedure, a request message is sent to at least one relay device, the request message comprising a relay service code (RSC1) associated with a set of PDU session attributes, an encrypted identifier of the at least one relay device, and an encrypted identifier of the mobile device, the identifier being encrypted using a key that allows the network relay function in the cellular network to decrypt it. Receiving a response message from at least one relay device, wherein the response message includes an encrypted relay service code (RSC2), and the encrypted relay service code (RSC2) is encrypted by a network relay function in the cellular network using a key that the mobile device can decrypt but the relay device cannot; A mobile device that at least performs the following: decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of the relay service code (RSC1) in subsequent discovery messages and connection setup messages, wherein the decrypted relay service code (RSC2') is associated with the same set of PDU session attributes as the relay service code (RSC1).

18. A mobile device used in a cellular communication system according to claim 3, wherein the mobile device is A transceiver that performs wireless communication within the cellular network and stores a set of relay service codes that are supported by the mobile device and can each be associated with a set of PDU session attributes, The connection processor includes a connection processor that manages the connection to the cellular network, the connection processor provides a relay function for managing at least one indirect connection, and the relay function is Sending a request message to at least one relay device, wherein the request message includes a relay service code (RSC1), an identifier for the at least one relay device, and further includes the identifier for the mobile device and a message authentication code. Receiving a response message from at least one relay device, wherein the response message includes an encrypted relay service code (RSC2), and the encrypted relay service code (RSC2) is encrypted by a network relay function in the cellular network using a key that the mobile device can decrypt but the relay device cannot; A mobile device that at least performs the following: decrypting the encrypted relay service code (RSC2) and inserting the decrypted relay service code (RSC2') in place of the relay service code (RSC1) in subsequent discovery messages and connection setup messages, wherein the decrypted relay service code (RSC2') is associated with the same set of PDU session attributes as the relay service code (RSC1).

19. The mobile device according to claim 18, wherein a key is used to encrypt at least one of the relay service code, the identifier of the mobile, and the identifier of the at least one relay device, or a key is used to determine the message authentication code which enables decryption by the network relay function in the cellular network but does not enable decryption by the relay device.

20. The mobile device according to any one of claims 17 to 19, wherein the mobile device selects for the request message a Layer 2 identification information that is at least different from the Layer 2 identification information last used in a previous message transmitted from the mobile device to the relay device.

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

22. The mobile device according to any one of claims 17 to 21, wherein the mobile device includes GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier) ​​in the request message.

23. The mobile device according to any one of claims 17 to 22, wherein the mobile device includes a nonce in the request message.

24. The mobile device according to any one of claims 17 to 23, wherein the mobile device transmits a freshness parameter in the request message, the freshness parameter indicating that the key used to encrypt the elements of the request message has not been updated for a predetermined time or indicates the time when the key was last updated.

25. A network relay entity that provides a network relay function used in a cellular communication system according to claim 1, wherein the network relay entity is The relay device receives at least one forwarding request message, the forwarding request message includes a relay service code (RSC1) and an encrypted identifier of the mobile device that sent the relay service code (RSC1) to the relay device. Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the transfer request message. The aforementioned different relay service codes (RSC2') are encrypted using a key that can be decrypted by the mobile device but not by the relay device, thereby generating an encrypted relay service code (RSC2). A network relay entity that transmits a forwarding response message containing the encrypted relay service code (RSC2) to the relay device.

26. The network relay entity according to claim 25, wherein the different relay service code (RSC2') used in place of the relay service code (RSC1) is selected from a set of spare relay service codes available in the relay device.

27. A network relay entity that provides a network relay function used in a cellular communication system according to claim 3, wherein the network relay entity is The relay device receives at least one forwarding request message, the forwarding request message includes a relay service code (RSC1) and an identifier of the mobile device that sent the relay service code (RSC1) to the relay device, In order to verify that the relay service code and the identifier of the mobile device have not been manipulated, the message authentication code is checked. Determine a different relay service code (RSC2') to be used in place of the relay service code (RSC1) received in the forwarding request message, and the different relay service code (RSC2') is selected from a set of spare relay service codes available in the relay device or from a new relay service code. The aforementioned different relay service codes (RSC2') are encrypted using a key that can be decrypted by the mobile device but not by the relay device, thereby generating an encrypted relay service code (RSC2). A network relay entity that transmits a forwarding response message containing the encrypted relay service code (RSC2) to the relay device.

28. The network relay entity according to any one of claims 25 to 27, wherein the network relay function adds the decoded relay service code to the forwarding response message, and the relay device uses the decoded relay service code to obtain PDU session attributes.

29. The network relay entity according to any one of claims 25 to 28, wherein the network relay function includes a newly encoded GUTI (Global Unique Temporary Identifier), TMSI (Temporary Mobile Subscriber Identity), or SUCI (Subscription Concealed Identifier) ​​in the forwarding request message.

30. A relay device that performs communication in a cellular network according to claim 1, wherein the relay device is Includes a relay processor that manages communications within the cellular network and manages indirect connections between the mobile device and the cellular network, The aforementioned relay processor As part of the setup procedure, receive the request message from the mobile device, After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, the forwarding request message includes the relay service code RSC1 and at least one of the encrypted identifiers received from the mobile device within the request message. The cellular communication system receives a forwarding response message, and the forwarding response message includes an encrypted relay service code (RSC2). A relay device that, after receiving the forwarding response message, transmits a response message including the encrypted relay service code (RSC2) to the mobile device in response to the forwarding response message.

31. A relay device that performs communication in a cellular network according to claim 3, wherein the relay device is Includes a relay processor that manages communications within the cellular network and manages indirect connections between the mobile device and the cellular network, The aforementioned relay processor Save a set of spare relay service codes. As part of the setup procedure, receive the request message from the mobile device, After receiving the request message, a forwarding request message is sent to the cellular communication system in response to the request message, and the forwarding request message includes the relay service code (RSC1), the message authentication code received from the mobile device within the request message, and the identifier of the mobile device. The cellular communication system receives a forwarding response message, and the forwarding response message includes an encrypted relay service code (RSC2). A relay device that, after receiving the forwarding response message, transmits a response message including the encrypted relay service code (RSC2) to the mobile device in response to the forwarding response message.

32. The relay device according to claim 30 or 31, wherein the relay device forwards the nonce or freshness parameter received in the request message in the forwarding request message.

33. The relay device according to any one of claims 30 to 32, wherein the relay device tracks the used nonce and discards a request message containing a previously used nonce, or aborts the setup procedure.

Images