Method performed by relay user equipment and relay user equipment

Abstract

A method performed by a Relay User Equipment is described, which consists of acquiring a first group of at least one System Information Block, SIB receiving from a first UE, a first message carrying a request for a second group of at least one SIB determining that all of the at least one SIB in the second group are included in the first group transmitting the at least one SIB in the second group to the first UE; and terminating the request without forwarding to a parent UE.

Description

METHOD PERFORMED BY RELAY USER EQUIPMENT AND RELAY USER EQUIPMENT

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long-Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive relevance to, signalling procedures for multiple hop (multi-hop) UE-to-network (U2N) relaying.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more RAN nodes. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. For example, such a communication device may be operable by a human or may be a partially or fully automated (e.g., machine-type-communication (MTC) / Internet of Things (IoT)) device.

[0006] In the current 5G architecture, the RAN architecture may be distributed with the RAN node structure split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of RAN nodes may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each RAN node.

[0007] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0008] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

[0009] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0010] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0011] Current communication technology also provides various ways in which UEs can communicate data between each other directly without using resources of a RAN node (although in some cases the UEs will require at least some control signalling from the RAN node). Such communication is often referred to as UE-to-UE direct communication, Device-to-Device (D2D) communication or sidelink communication. D2D communication was originally defined as part of Proximity Services (ProSe) services in Release 12 and Release 13 of the 3GPP specifications. As part of ProSe services, a new D2D interface was introduced. This D2D interface may be referred to as the 'PC5' interface, or simply the 'Sidelink', at the physical layer. The sidelink provides a direct link for communication between devices, with or without network coverage. As D2D technology has been developed, sidelink communication has been further enhanced for vehicular use cases, addressing high speed (up to 250km / h along roads and up to 500km / h along railways) and high density (thousands of nodes) scenarios as well.

[0012] Sidelink communication has several application areas / use cases, such as proximity services, public safety, IoT, including machine type communication and sensors, wearable devices, amongst others. The term Vehicle-to-Everything (V2X) covers a special application area of Sidelink / PC5 for the purpose of communication between vehicles using a direct link. V2X encompasses at least the following categories: Vehicle-to-Vehicle (V2V); Vehicle-to-Infrastructure (V2I); Vehicle-to-Pedestrian (V2P); Vehicle-to-Home (V2H); and enhanced Vehicle-to-Everything (eV2X).

[0013] As sidelink communication involves direct communication between UEs, it supports a range of use cases in which a UE is not necessarily within coverage of a RAN node. These use cases include: in-coverage use cases in which a given pair of UEs involved in sidelink communication are both in coverage of the RAN node, partial-coverage use cases in which one of the UEs involved in the sidelink communication is in coverage of the RAN node while another of the UEs involved in the sidelink communication is not in coverage of the RAN node; and out-of-coverage use cases in which neither of a given pair of UEs involved in sidelink communication are in coverage of the RAN node. Of course, a given UE may move between in-coverage, partial-coverage, and out-of-coverage scenarios.

[0014] It can be seen, therefore, that these various coverage scenarios allow for network coverage to be extended by using a sidelink capable UE as a relay UE for relaying communication either between a RAN node and another, remote, UE or between two remote UEs. Such a sidelink relay is referred to as a UE-to-network (U2N) relay when the relay UE connects a remote UE to the network and as a UE-to-UE relay when the relay UE connects a first remote UE to a second remote UE. Release 17 of the 3GPP specifications defined basic functionality support for U2N relays. Work in respect of Release 18 of the 3GPP specifications introduced enhancements in the support provided for U2N relays and began introducing support for UE-to-UE relays, and investigating the possibility of providing multi-path support in which the UE is connected to the network via more than one path including a direct path to the RAN node, and an indirect path via the sidelink relay.

[0015] The ability of a UE to operate as a U2N relay, or to operate as a remote UE that communicates with the network via a U2N relay, introduces the possibility of additional mobility related 'path switch' / handover scenarios in which the path between the UE and the network changes (e.g., as a result of movement of the remote UE and / or the U2N relay UE).

[0016] Initially support for such path switch scenarios was focussed on intra-RAN node scenarios in which the serving RAN node remains unchanged. In particular support was focussed on intra-RAN node path switch involving a path switch from a direct path (e.g., via the air interface) to the RAN node, to an indirect path (e.g., via the U2N relay) to the same RAN node (or vice versa).

[0017] More recently, support has been considered for inter-RAN node path switch scenarios in which communication with the network is switched from a first path via a first (source) RAN node to a second path via a second, different, (target) RAN node. These inter-RAN node path switch scenarios involving U2N relay-based relaying may include, for example: -　　inter-RAN node indirect-to-indirect path switch in which the remote UE connects indirectly, via a (source) U2N relay, to the first RAN node before the path switch, and indirectly, via another (target) U2N relay, to the second RAN node after the path switch; -　　inter-RAN node direct-to-indirect path switch in which the remote UE connects directly to the first RAN node before the path switch, and indirectly to the second RAN node, via a U2N relay, after the path switch; and -　　inter-RAN node indirect-to-direct path switch in which the remote UE connects indirectly to the first RAN node via a U2N relay before the path switch, and directly to the second RAN node after the path switch.

[0018] Consideration has also been given to providing support for intra-RAN node indirect-to-indirect path switch involving a path switch from one indirect path (e.g., via one U2N relay) to the RAN node, to another indirect path (e.g., via another U2N relay) to the same RAN node.

[0019] More recently, work has been carried out to investigate support for multi-hop Layer-2 (L2) UE-to-Network relaying for a single indirect path via a plurality of relay UEs (e.g., including a plurality of sidelink relay UEs (or 'hop relays') and a U2N relay - building on the established sidelink functionalities. This work has included consideration of the possible introduction of mechanisms to support up to (at least) two additional relay UEs in addition to a U2N relay. Initially it is envisaged that support for one additional relay UE / hop relay (i.e., remote UE <= => first relay UE <= => last relay UE (e.g., a U2N relay) <= => RAN node) might be introduced, with further work in the future to consider the possibility of extending this to two additional relay UEs / hop relays (i.e., remote UE <= => first relay UE <= => second (intermediate) relay UE <= => last relay UE (e.g., a U2N relay) <= => RAN node).

[0020] Accordingly, there is a need to develop and specify mechanisms for supporting at least one additional relay UE (hop relay) that are easily extendible to support two (and possibly more) additional relay UEs (hop relays), and that are forward compatible for future extensions for additional relays.

[0021] In order to facilitate this, there is a need for procedures / mechanisms that take into consideration a number of different matters including, for example: relay discovery and (re)selection; signalling support for relay UEs and remote UE authorisation (if considered necessary); the impact on the sidelink relay adaptation protocol (SRAP) sublayer and quality of service (QoS) handling for multi-hop scenarios; and / or control plane procedures.

[0022] Moreover, there is a need to develop procedures / mechanisms for supporting intra-RAN node service continuity scenarios for multi-hop U2N relaying for the remote UE including, for example: intra-RAN node multi-hop indirect to direct path switching; and / or intra-RAN node multi-hop indirect to single-hop indirect path switching.

[0023] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.

[0024] The current consensus is that, for multi-hop L2 UE-to-Network relaying, it would be beneficial for possible scenarios to be supported in which the last relay UE (e.g., U2N relay) may have a plurality of (downlink) connections - e.g., a connection with one intermediate relay UE and a connection with one remote UE (where the intermediate relay UE and remote UE are physically different UEs). Moreover, it would be beneficial for possible scenarios to be supported in which two physically different remote UEs may each have an indirect path via the same intermediate relay UE and the same last relay UE. It is still to be established whether the last relay UE can use the same L2 identifier for both of the connections in either of these scenarios.

[0025] The current consensus is also that it would be beneficial for possible scenarios to be supported in which an intermediate relay UE can serve a plurality of different multi-hop indirect paths for different remote UEs. It is not envisaged that an intermediate relay UE that is also operating as a remote UE will have to support different indirect paths to the RAN node having the same (or different) last relay UE, U2N relay UE, or parent intermediate relay UE, based on different PC5 unicast links. It is also not envisaged that scenarios in which there are two indirect paths to the RAN node, for the same remote UE, will have to be supported.

[0026] With the involvement of more relay UEs, in addition to the remote UE, the question arises as to how a transition of the remote UE to an RRC connected mode / state should impact the RRC states of the relay UEs. In this regard, the current consensus is that it would be beneficial to support at least a baseline procedure for a case in which all the intermediate relay UEs for a remote UE transition to an RRC connected mode / state (if not already there) when the remote UE transitions to an RRC connected mode / state. This case may be supported, for example, based on the existing U2N framework, with all the UEs involved being RRC connected to the last relay UE's serving cell. It is still to be established whether to support a case in which intermediate relay UEs do not all move to an RRC connected mode / state when the remote UE triggers connection establishment and if so how.

[0027] In current UE-to-Network relaying via a single U2B relay, the SRAP header enables mapping from an end-to-end bearer identifier to an egress (PC5) RLC channel. It is envisaged that this principle will also be applicable for bearer mapping in the context of multi-sop scenarios involving one or more additional intermediate relay UEs albeit that this does not preclude modification of the SRAP header by an intermediate relay UE. It is also envisaged that, to facilitate this, a remote UE identifier and a bearer identifier may be included in the SRAP header for multi-hop L2 U2N relaying.

[0028] In multi-hop L2 U2N relaying, the remote UE will need to acquire the system information broadcast in the cell of the last relay UE. This will therefore need to be forwarded via each intermediate relay UE and it is not yet established how such forwarding is to be to performed or whether or not an intermediate relay UE may be able to obtain and forward available system information directly (rather than retrieving it from the last relay UE).

[0029] Whilst progress has been made in respect of multi-hop L2 U2N relaying, there are still a number of open issues including, for example: what the procedure should be for forwarding the first uplink RRC message for multi-hop L2 U2N relaying; how routing of the first downlink RRC message should be implemented for multi-hop L2 U2N relaying; what the procedure should be for acquiring system information; and how paging notifications (which may also be referred to as paging messages) for a remote UE should be handled for multi-hop L2 U2N relaying.

[0030] The disclosure aims to describe one or more apparatus and / or one or more associated methods that at least partially contributes to addressing one or more of the above needs and / or issues.

[0031] The disclosure has a method performed by a Relay User Equipment, UE, the method comprising acquiring a first group of at least one System Information Block, SIB receiving from a first UE, a first message carrying a request for a second group of at least one SIB determining that all of the at least one SIB in the second group are included in the first group transmitting the at least one SIB in the second group to the first UE; and terminating the request without forwarding to a parent UE.

[0032] The disclosure has a method performed by a Relay User Equipment, UE, the method comprising acquiring a first group of at least one System Information Block, SIB receiving from a first UE, a first request for a second group of at least one SIB determining that the first group is a part of the second group forwarding the first request to a parent UE.

[0033] The disclosure has a Relay User Equipment, UE comprising means for acquiring a first group of at least one System Information Block, SIB means for receiving from a first UE, a first message carrying a request for a second group of at least one SIB means for determining that all of the at least one SIB in the second group are included in the first group means for transmitting the at least one SIB in the second group to the first UE; and means for terminating the request without forwarding to a parent UE.

[0034] The disclosure has a Relay User Equipment, UE, comprising means for acquiring a first group of at least one System Information Block, SIB means for receiving from a first UE, a first request for a second group of at least one SIB means for determining that the first group is a part of the second group means for forwarding the first request to a parent UE.

[0035] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0036] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0037] Various apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0038] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 is a simplified illustration of different single-hop UE-to-network relaying scenarios that may occur in the communication system of Fig.1;Fig. 3 is a simplified illustration of user plane and control plane protocol stacks for a single-hop U2N relay architecture that may be implemented in the communication system of Fig. 1;Fig. 4A is a simplified illustration of different possible multi-hop UE-to-network relaying scenarios that may occur in the communication system of Fig. 1;Fig. 4B is a simplified illustration of different possible multi-hop UE-to-network relaying scenarios that may occur in the communication system of Fig. 1;Fig. 5A is a simplified illustration of different possible multi-hop UE-to-network relaying scenarios involving a plurality of remote UEs served by relay UEs of the same relay path that may occur in the communication system of Fig. 1;Fig. 5B is a simplified illustration of different possible multi-hop UE-to-network relaying scenarios involving a plurality of remote UEs served by relay UEs of the same relay path that may occur in the communication system of Fig. 1;Fig. 6 is a simplified illustration of another possible multi-hop UE-to-network relaying scenario involving a plurality of remote UEs served by relay UEs of different relay paths that may occur in the communication system of Fig. 1;Fig. 7 is a simplified illustration of user plane protocol stacks for a multi-hop U2N relay architecture that may be implemented in the communication system of Fig. 1;Fig. 8 is a simplified illustration of control plane protocol stacks for a multi-hop U2N relay architecture that may be implemented in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating a procedure for establishing a connection between a remote UE and a RAN node, in the context of multi-Hop U2N relaying, in the communication system of Fig. 1;Fig. 10 is a simplified illustration of how routing of a first downlink RRC message might be implemented in a single-hop UE-to-network relaying scenario in the communication system of Fig.1;Fig. 11 is a simplified sequence diagram of a system information acquisition procedure between a UE and RAN node in the context of a single-hop UE-to-network relaying scenario that may be implemented in the communication system of Fig.1;Fig. 12 is a simplified sequence diagram of a procedure for handling paging notifications in the context of a single-hop UE-to-network relaying scenario that may occur in the communication system of Fig. 1.Fig. 13 is a simplified illustration of how routing of a first downlink RRC message might be implemented in a multi-hop UE-to-network relaying scenario in the communication system of Fig. 1;Fig. 14 is a simplified sequence diagram of a system information acquisition procedure between a UE and RAN node in the context of a multi-hop UE-to-network relaying scenario that may be implemented in the communication system of Fig.1;Fig. 15 is a simplified sequence diagram of a procedure for handling paging notifications in the context of a multi-hop UE-to-network relaying scenario that may be implemented in the communication system of Fig.1;Fig. 16 is a simplified schematic block diagram illustrating the main components of a UE for the communication system of Fig. 1; andFig. 17 is a simplified schematic block diagram illustrating the main components of a base station for the communication system of Fig. 1.

[0039] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 12.

[0040] Fig. 1 schematically illustrates a communication system 1 to which the examples described herein are applicable.

[0041] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3, 3-4) (e.g., mobile telephones and / or other mobile devices) can communicate with each other via corresponding (radio) access network ((R)AN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a base station or 'gNB' operating one or more associated cells 9. Communication via the RAN node 5 is typically routed through a core network 7 (e.g., a 5G and / or later generations core network, evolved packet core network (EPC), or any other core network).

[0042] As those skilled in the art will appreciate, whilst four UEs 3 and one RAN node 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5 and UEs 3.

[0043] The RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, transmission reception points (TRPs) and / or the like). It will be appreciated that the RAN node 5 may be configured to support more than one radio access technology and its associated communication protocols (e.g., 4G, 5G, 6G, and / or later generation, and / or any other 3GPP or non-3GPP communication protocols).

[0044] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu', 'NG-Uu', interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0045] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the telecommunication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0046] The RAN node 5 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communication is routed transparently via the RAN node 5.

[0047] Each UPF 11 is respectively connected to an external data network (e.g. an IP network such as the internet) via an appropriate reference point (e.g., N6 reference point) for communication of the user data.

[0048] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

[0049] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3. The SMF 10-2 uses user information provided via the AMF to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.The RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The downlink physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the downlink physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0050] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal / PBCH Block (SSB), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form a SS / PBCH block. The RAN node 5 may transmit a number of SSBs corresponding to different downlink beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0051] The downlink physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0052] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and uplink physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (which may be abbreviated as either 'PRACH' or 'RACH' - the term (P)RACH will be used herein). The uplink physical signals may include, for example, demodulation reference signals (DMRS) for an uplink control / data signal, and / or sounding reference signals (SRS) used for uplink channel measurement.

[0053] <Direct UE-to-UE (Sidelink) Communication> 　　In the communication system 1, at least some of the UEs 3-1, 3-2, and 3-4 are capable of performing direct (UE-to-UE) - or 'sidelink' - communication between one another, via a direct UE-to-UE interface (e.g., the 'sidelink' or 'PC5' interface) when in range. This direct communication may be: in-coverage sidelink communication involving a pair of UEs 3-1, 3-2 that are both in coverage of the RAN node 5 (e.g., as illustrated between UEs 3-2 and 3-1); partial-coverage sidelink communication involving a UE 3-1 that is in coverage of the RAN node 5 and a UE 3-4 that is not in coverage of the RAN node 5 (e.g., as illustrated between UEs 3-4 and 3-1); or out-of-coverage sidelink communication involving a pair of UEs 3-4 that are both outside the coverage of the RAN node 5.

[0054] The sidelink capable the UEs 3-1, 3-2, 3-4 are configured for communication via a number of dedicated sidelink physical channels and transmission / reception of a number of SL physical signals. The sidelink physical channels include the Physical Sidelink Broadcast Channel (PSBCH), the Physical Sidelink Feedback Channel (PSFCH), the Physical Sidelink Shared Channel (PSSCH), and the Physical Sidelink Control Channel (PSCCH).

[0055] The PSBCH carries the sidelink broadcast transport channel (SL-BCH) which is used for periodic transmission (e.g., every 160ms) of a Master Information Block (MIB) for sidelink. The MIB carries system information for UE-to-UE communication. The information carried by the PSBCH is transmitted with a Sidelink Primary Synchronization Signal / Sidelink Secondary Synchronization Signal (S-PSS / SSS) as part of a sidelink-synchronization signal block (S-SSB).

[0056] The PSFCH is used for transmission of hybrid automatic repeat request (HARQ) feedback from a receiver UE 3-1, 3-2, 3-4 to a transmitter UE 3-1, 3-2, 3-4 on the SL for a unicast or groupcast communication.

[0057] The PSSCH contains transport blocks (i.e., user data traffic) of the sidelink shared transport channel (SL-SCH) and is typically associated with a PSCCH transmitted in the same slot.

[0058] The sidelink capable UEs 3-1, 3-2, 3-4 are able to send sidelink control information (SCI) in two stages for general sidelink communication. The 1ststage is carried by a PSCCH, and the 2nd stage is carried by a corresponding PSSCH, which is associated with the PSCCH.

[0059] A UE 3-1, 3-2, 3-4 may use the 1st stage SCI to inform other UEs 3-1, 3-2, 3-4 of resources allocated by the RAN node for a particular dynamic grant (DG) / configured grant (CG) period (e.g., in mode 1) or autonomously selected by the UE (e.g., in mode 2). A UE 3-1, 3-2, 3-4 may use the 2nd-stage SCI to inform other UEs 3-1, 3-2, 3-4 of information to be used for decoding the PSSCH, and for supporting HARQ feedback and CSI reporting.

[0060] The first-stage SCI may contain, for example, information to enable sensing operations, information about the resource allocation of the PSSCH, and, when needed, an indication that the UE can receive conflict information in inter-UE coordination. The 1st stage SCI typically includes, for example: a frequency resource (e.g., sub-channels) assignment for the PUSCH; a time resource assignment; a resource reservation period for up to two further transmissions an associated TB; a priority for the associated PUSSCH; a demodulation reference signal (DMRS) pattern; information identifying a 2nd-stage SCI format and size; a modulation and coding scheme of the data payload carried in the associated PSSCH; one or more reserved bits; a beta offset indicator; and / or a number of a DMRS port.

[0061] The second-stage SCI can carry information needed to identify and decode the associated SL-SCH, as well as control for HARQ procedures, triggers for channel state information (CSI) feedback, inter-UE coordination requests and information, etc. The 2nd stage SCI typically includes, for example: a HARQ process ID; a new data indicator; a redundancy version; a source ID; a destination ID; and / or a CSI request.

[0062] <Single-Hop UE-to-Network Relaying (via Direct UE-to-UE Communication): > 　　Referring to Fig. 2, which illustrates different single-hop UE-to-network relaying scenarios, the RAN node 5, and each of the UEs 3-1, 3-2, and 3-4 that are capable of performing sidelink communication, are mutually configured to support UE-to-network relaying. In this context, each of those UEs 3-1, 3-2, 3-4 is respectively configured to be able to operate either as a UE-to-network (U2N) relay, or as a remote UE, in a U2N relaying scenario. The supported U2N scenarios include an in-coverage U2N scenario, as shown for Scenario A in Fig. 2, in which both a UE 3-2 operating as a U2N relay (which may also be referred to simply as a 'relay' or 'relaying' UE), and a UE 3-1 operating as a remote UE (which may also be referred to simply as a 'relayed' UE), are in-coverage. The supported U2N scenarios also include an out-of-coverage U2N scenario, as shown for Scenario B in Fig. 2, in which a UE 3-4 operating as a remote UE is out-of-coverage but the UE 3-1 operating as a U2N relay is in-coverage (corresponding to the more general partial coverage sidelink scenario described above).

[0063] < Single-Hop U2N Relay Architecture User Plane and Control Plane Protocol Stacks:> 　　Fig. 3 is a simplified illustration of user plane and control plane protocol stacks for a single-hop U2N relay architecture that may be implemented in the communication system 1 (e.g., for an L2 U2N relay).

[0064] In this example, there is a single remote UE 3-4, a single the U2N relay UE 3-1, and a single RAN node 5. Hence, uplink communication between the remote UE 3-4 that originates the communication and the RAN node 5 is via a single additional hop from the remote UE 3-4 to the U2N relay UE 3-1 before being forwarded from the U2N relay UE 3-1 to the RAN node 5. Similarly, downlink communication between the RAN node 5 and the remote UE 3-4 that terminates the communication is via a single additional hop from the RAN node 5 to the U2N relay UE 3-1 before being forwarded from the U2N relay UE 3-1 to the remote UE 3-4.

[0065] As seen in Fig. 3, the protocol stacks include a number of protocol layers that are terminated at the remote UE 3-4 and at the RAN node 5. These layers include a service data adaptation protocol (SDAP) sublayer (for the user plane), and a radio resource control (RRC) sublayer (for the control plane), above a packet data convergence protocol (PDCP) sublayer.

[0066] The RRC layer is considered to be a layer 3 sublayer and is the highest layer in the control plane of the access stratum (AS). It is also responsible for transferring messages of the non-access stratum (NAS), which is located above the RRC layer. RRC is responsible for handling many RAN-related control plane procedures such as: broadcasting system Information (SI); transmission of paging notifications (which may also be referred to as paging messages) to notify a UE about incoming connection requests; connection management; handling UE capabilities; measurement configuration and reporting; etc.

[0067] The SDAP layer is the highest L2 sublayer of the protocol stack in this example. It is responsible for quality of service (QoS) flow handling across the air interface (e.g., Uu) and N3 interface. The SDAP sublayer can have multiple SDAP entities (e.g., one for each protocol data unit (PDU) session between the RAN node 5 and remote UE 3-4) where SDAP entity establishment / release is initiated by RRC.

[0068] In particular, SDAP is responsible for the transfer of user plane data between the remote UE 3-4 and the core network 7 (UPF 11). An SDAP entity maps each QoS flow from higher layers, within a particular PDU session, to a respective data radio bearer (DRB) established, via lower layers (e.g., PDCP and RLC) with the appropriate level of QoS, over the air interface between the remote UE 3-4 and the RAN node 5. As those skilled in the art will appreciate, the QoS flow may be in either the downlink or in the uplink and there may be more than one such QoS flow within the PDU session. It will be appreciated that the SDAP layer is not present in some architectures (e.g., in a non-stand-alone (NSA) architecture).

[0069] The PDCP sublayer is the layer 2 sublayer that sits below the SDAP sublayer for user plane data, and below the RRC sublayer for control plane data. The PDCP sublayer provides a number of functions depending on requirements including, for example: transfer of user plane data (to / from the SDAP sublayer); transfer of control plane data (to / from the RRC sublayer); maintenance of PDCP sequence numbers; header compression and decompression (e.g., using the robust header compression (ROHC) protocol); ciphering and deciphering; integrity protection and integrity verification; timer based discarding of packets (PDCP SDUs); routing (e.g., for split bearers); duplication; reordering and in-order delivery; out-of-order delivery; and / or duplicate discarding.

[0070] In particular, one or more PDCP entities may be established in the PDCP sublayer for receiving data from higher layers and for processing the PDCP SDUs through the PDCP layer to become PDCP PDUs (and vice versa). Following the processing of the PDCP SDUs to form PDCP PDUs, the PDCP entity transfers the PDCP PDUs to the RLC sublayer (where they are received as RLC SDUs).

[0071] A PDCP entity at the RAN node 5 may send a PDCP status report (a PDCP status PDU) to a corresponding peer PDCP entity at the remote UE 3-4 to indicate the received status of uplink PDCP packets at the RAN node 5. Similarly, a PDCP entity at the remote UE 3-4 may send a PDCP status report / PDU to a corresponding peer PDCP entity at the RAN node 5 to indicate the received status of downlink PDCP packets at the remote UE 3-4. A PDCP status report PDU will typically include a 'PDU type' field to identify the PDU as being a PDCP status report type of PDU. The PDCP status report will also specify a first missing count (FMC) value for the counter associated with PDCP SDUs having sequence numbers (SNs). The count value is a concatenation of a hyper frame number (HFN) and the PDCP SN. A bitmap may also, optionally, be included to indicate what count values, following the FMC, are also missing. On receipt of a PDCP status report a PDCP entity of a transmitting device (RAN node 5 / UE 3) can thus discard all packets which have been successfully received at a PDCP entity of the peer receiving device (UE 3 / RAN node 5).

[0072] Below the PDCP sublayer, the protocol stack includes a number of layers that are terminated at either side of the UE-to-UE interface (e.g., PC5) between the remote UE 3-4 and the U2N relay UE 3-1, and at either side of the air interface (e.g., Uu) between the U2N relay UE 3-1 and the RAN node 5 - i.e., these layers are terminated at each hop (i.e., the link between U2N remote UE 3-4 and the U2N relay UE 3-1 and the link between U2N relay UE 3-1 and the RAN node 5).

[0073] The layers below the PDCP sublayer include a sidelink relay adaptation protocol (SRAP) sublayer, a radio link control (RLC) sublayer, a medium (or media) access control (MAC) sublayer, and a physical (PHY) sublayer.

[0074] The SRAP sublayer is provided, above the RLC sublayer, for both the control plane and the user plane signalling. For U2N relaying in the uplink, the SRAP sublayer over the air interface (e.g., Uu) (the 'Uu SRAP' sublayer) supports uplink bearer mapping between the incoming (ingress) RLC channels over the UE-to-UE interface (e.g., PC5) for relaying, and the outbound (egress) RLC channels over the air interface (e.g., Uu) between the U2N relay UE 3-1 and the RAN node 5. For uplink relaying traffic, the different end-to-end radio bearers (signalling radio bearers (SRBs) for control plane traffic or DRBs for user plane traffic) of the same remote UE 3-4 and / or different remote UEs can be multiplexed over the same (Uu) RLC channel. The (Uu) SRAP sublayer supports remote UE identification for the uplink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are included in a (Uu) SRAP header for uplink so the RAN node 5 can correlate the received packets for a specific PDCP entity associated with the correct (Uu) radio bearer of the remote UE 3-4. The SRAP sublayer over the UE-to-UE interface (e.g., PC5) (which may be referred to as the 'PC5 SRAP' sublayer), at the remote UE 3-4, supports uplink bearer mapping between a remote UE (Uu) radio bearer and egress (PC5) RLC channels.

[0075] For U2N relaying in the downlink, the (Uu) SRAP sublayer supports downlink bearer mapping at the RAN node 5 to map end-to-end radio bearers (SRBs / DRBs) of a remote UE 3-4 into a (Uu) RLC channel over the air interface (e.g., Uu) between the U2N relay UE 3-1 and the RAN node 5. The (Uu) SRAP sublayer can be used to support downlink bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of the remote UE 3-4 and / or different remote UEs 3 and one (Uu) RLC channel over the air interface (e.g., Uu) between the U2N relay UE 3-1 and the RAN node 5. The (Uu) SRAP sublayer also supports remote UE identification for downlink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are put into the (Uu) SRAP header by the RAN node 5 for downlink so the U2N relay UE 3-1 can map the received packets from the remote UE (Uu) radio bearer to the associated (PC5) RLC channel. The (PC5) SRAP sublayer at the U2N relay UE 3-1 also supports downlink bearer mapping between ingress (Uu) RLC channels and egress (PC5) RLC channels. The (PC5) SRAP sublayer at the remote UE 3-4 supports downlink bearer mapping between ingress (PC5) RLC channels and remote UE (Uu) radio bearers.

[0076] On the U2N relay UE 3-1, the SRAP sublayer contains one SRAP entity at the air interface (e.g., Uu) and a separate collocated SRAP entity at the UE-to-UE interface (e.g., PC5) . On the remote UE 3-4, the SRAP sublayer contains an SRAP entity at the UE-to-UE interface (e.g., PC5).

[0077] Each SRAP entity has a transmitting part and a receiving part. Across the UE-to-UE interface (e.g., PC5) in the U2N case, for the transmitting part of the SRAP entity at the remote UE 3-4, there is a corresponding receiving part of the SRAP entity at the U2N relay UE 3-1, and vice versa. Across the air interface (e.g., Uu), for the transmitting part of the SRAP entity at the U2N relay UE 3-1, there is a corresponding receiving part of the SRAP entity at the RAN node 5, and vice versa.

[0078] The RLC layer is another layer 2 sublayer. The RLC sublayer provides a radio link protocol used over the air interfaces between the UE 3 and the RAN node 5 (e.g., Uu) and, in the illustrated example, between the remote UE 3-4 and the relay UE 3-1 (e.g., PC5). The RLC sublayer provides a number of functions depending on requirements including, for example: transfer of upper layer (PDCP) PDUs in one of three modes including acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM); error correction through automatic repeat requests (ARQ) for AM data transfer; concatenation, segmentation and reassembly of RLC SDUs (UM and AM); re-segmentation of RLC data PDUs when a complete RLC PDU cannot be transmitted (AM); reordering of RLC data PDUs (UM and AM); duplicate detection (UM and AM); RLC SDU discard (UM and AM); RLC re-establishment; protocol error detection and recovery.

[0079] In particular, one or more RLC entities may be established in the RLC sublayer for receiving data from higher layers and for processing the RLC SDUs through the RLC layer to become RLC PDUs (and vice versa). Following the processing of the RLC SDUs to form RLC PDUs, the RLC entity transfers the RLC PDUs to the MAC sublayer (where they are received as MAC SDUs).

[0080] A receiving RLC entity in one device (e.g., the RAN node 5, remote UE 3-4, or relay UE 3-1) can generate an RLC status report indicating the receive status of packets (RLC SDUs) successfully received (or not received) from a transmitting RLC entity at a corresponding peer device (e.g., the RAN node 5, remote UE 3-4, or relay UE 3-1) and send the RLC status report as an RLC status PDU to the peer device. An RLC status report / PDU will typically include the receive status for a plurality of received RLC SDUs (and possibly RLC SDU segments). On receipt of the RLC status report / PDU, the RLC entity at the peer (transmitting) device will iterate through the positively acknowledged packets in the RLC status report / PDU and notify the PDCP layer of each RLC SDU (and hence PDCP PDU) that has been positively acknowledged.

[0081] Accordingly, the RAN node 5 and remote UE 3-4 may operate data radio bearers (DRBs) in an RLC acknowledge mode (AM) indirectly via the relay UE 3-1.

[0082] In the uplink, an RLC entity in the RAN node 5 can acknowledge RLC SDUs / RLC SDU segments relayed from the remote UE 3-4 by the relay UE 3-1. Similarly, an RLC entity in the relay UE 3-1 can acknowledge RLC SDUs / RLC SDU segments received, from the remote UE 3-4, for relaying to the RAN node 5. A corresponding RLC entity at the remote UE 3-4 can process acknowledgments received (in the RLC status PDU) from the relay UE 3-1 and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The RLC entity at the relay UE 3-1 can process acknowledgments received (in the RLC status PDU) from the RAN node 5 and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the RAN node 5).

[0083] In the downlink, an RLC entity in the remote UE 3-4 can acknowledge RLC SDUs / RLC SDU segments relayed from the RAN node 5 by the relay UE 3-1. Similarly, an RLC entity in the relay UE 3-1 can acknowledge RLC SDUs / RLC SDU segments received, from the RAN node 5, for relaying to the remote UE 3-4. A corresponding RLC entity at the RAN node 5 can process acknowledgments received (in the RLC status PDU) from the relay UE 3-1 and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The RLC entity at the relay UE 3-1 can process acknowledgments received (in the RLC status PDU) from the remote UE 3-4 and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the remote UE 3-4).

[0084] The MAC sublayer receives the RLC PDUs (as MAC SDUs) from the RLC sublayer and processes them to form MAC PDUs (which are packaged as transport blocks (TBs)) for transmission via the PHY sublayer. PDCP PDUs carrying data from the upper layers may also be referred to as PDCP data PDUs to distinguish them from a PDCP control PDU carrying control data.

[0085] Fig. 2 relates to different single-hop UE-to-network relaying scenarios, and the user plane and control plane protocol stacks shown in Fig. 3 are for a single-hop U2N relay architecture. Beneficially, however, the communication system 1 also supports multi-hop UE-to-network relaying. A number of different possible multi-hop UE-to-network relaying scenarios that may be supported in the communication system 1, and associated user plane and control plane protocol stacks will now be described, by way of example only, with reference to Figs. 4A, 4B to 8.

[0086] < Multi-Hop UE-to-Network Relaying (via Direct UE-to-UE Communication):> 　　Figs. 4A and 4B illustrate different possible multi-hop UE-to-network relaying scenarios that may occur in the communication system 1.

[0087] As seen at Fig. 4A in a first scenario ('scenario-1'), there is a single additional hop before an uplink or downlink communication is forwarded to its destination (RAN node 5 or remote UE 3-4) compared to the single-hop scenarios introduced above. Specifically, there are two relay UEs 3-1a, 3-1b - a first relay UE 3-1a and last relay UE 3-1b (the labels 'first' and 'last' being relative to the uplink direction).

[0088] The first relay UE 3-1a operates as a UE-to-UE relay: for receiving uplink communication from the remote UE 3-4; for forwarding that uplink communication to the last relay UE 3-1b; for receiving downlink communication forwarded by the last relay UE 3-1b from the RAN node 5; and for forwarding that downlink communication to the remote UE 3-4. The first relay UE 3-1a may also be referred to as an 'intermediate' relay UE 3-1c.

[0089] The last relay UE 3-1b effectively operates as a U2N relay: for receiving uplink communication forwarded by the first relay UE 3-1a, from the remote UE 3-4; for forwarding that uplink communication to the RAN node 5; for receiving downlink communication from the RAN node 5; and for forwarding that downlink communication to the first relay UE 3-1a.

[0090] The relay UE closest (in the forwarding path) to the RAN node 5 - i.e., the last relay UE 3-1b (e.g., U2N relay) - will typically be in-coverage (of the RAN node 5) whereas the relay UE closest (in the forwarding path) to the remote UE 3-4 - i.e., the first relay UE 3-1a (e.g., UE-to-UE relay) - may either be out-of-coverage or in-coverage (of the RAN node 5).

[0091] As seen at Fig. 4B, in a second scenario ('scenario-2'), there are a plurality of additional hops before an uplink or downlink communication is forwarded to its destination (RAN node 5 or remote UE 3-4) compared to the single-hop scenarios introduced above. Specifically, there are more than two relay UEs 3-1a, 3-1b, 3-1c - a first relay UE 3-1a, last relay UE 3-1b (the labels 'first' and 'last' being relative to the uplink direction) and at least one further UE 3 ('intermediate' relay UE 3-1c).

[0092] The first relay UE 3-1a operates as a UE-to-UE relay: for receiving uplink communication from the remote UE 3-4; for forwarding that uplink communication to the intermediate relay UE 3-1c; for receiving downlink communication forwarded by the intermediate relay UE 3-1c from the last relay UE 3-1b (or possibly another intermediate relay UE 3-1c); and for forwarding that downlink communication to the remote UE 3-4. The first relay UE 3-1a may also be referred to as another 'intermediate' relay UE 3-1c.

[0093] Each intermediate relay UE 3-1c operates as a UE-to-UE relay: for receiving uplink communication from the first relay UE 3-1a (or possibly another intermediate relay UE 3-1c); for forwarding that uplink communication to the last relay UE 3-1b (or possibly another intermediate relay UE 3-1c); for receiving downlink communication forwarded by the last relay UE 3-1b (or possibly another intermediate relay UE 3-1c) from the RAN node 5 (or possibly another intermediate relay UE 3-1c); and for forwarding that downlink communication to the first relay UE 3-1a (or possibly another intermediate relay UE 3-1c).

[0094] The last relay UE 3-1b operates as a U2N relay: for receiving uplink communication forwarded by the intermediate relay UE 3-1c, from the first relay UE 3-1a (or possibly another intermediate relay UE 3-1c), and for forwarding that uplink communication to the RAN node 5; and for receiving downlink communication from the RAN node 5, and for forwarding that downlink communication to the intermediate relay UE 3-1c.

[0095] The relay UE closest (in the forwarding path) to the RAN node 5 - i.e., the last relay UE 3-1b (e.g., U2N relay) - will typically be in-coverage (of the RAN node 5) whereas each relay UE that is between the last relay UE 3-1b and the remote UE 3-4 - i.e., the first relay UE 3-1a and / or each intermediate relay UE 3-1c - may be respectively out-of-coverage or in-coverage (of the RAN node 5).

[0096] In the scenarios in Fig. 4A or 4B there is a single remote UE 3-4. Nevertheless, the communication system 1 also supports multi-hop UE-to-network relaying in which there are a plurality of remote UEs 3-4 served by the same RAN node 5 either: via the all or a subset of the first / last / intermediate relay UEs 3-1a, 3-1b, 3-1c of a common relaying path; or via different relaying paths in which at least one relay UE 3-1 is not common to the different relaying paths. A number of different possible multi-hop UE-to-network relaying scenarios involving a plurality of remote UEs 3-4 that may be supported in the communication system 1 will now be described, by way of example only, with reference to Figs. 5A, 5B and 6.

[0097] < Multi-Hop UE-to-Network Relaying - Plural Remote UEs / Common Relaying Path:> 　　Figs. 5A and 5B illustrate different possible multi-hop UE-to-network relaying scenarios, involving a plurality of remote UEs 3-4 served by the first / last / intermediate relay UEs 3-1a, 3-1b, 3-1c of the same relay path, that may occur in the communication system 1.

[0098] As in example (b) of Fig. 3 above, each of the different possible multi-hop UE-to-network relaying scenarios shown in Figs. 5A and 5B involve at least some U2N relaying involving a plurality of additional hops before an uplink or downlink communication is forwarded to its destination (RAN node 5 or remote UE 3-4) compared to the single-hop scenarios introduced above. It will, nevertheless, be appreciated that similar scenarios could apply in a scenario involving a single additional hop before an uplink or downlink communication is forwarded to its destination (as in example (b) of Fig. 3).

[0099] As seen at (a) in Figs. 5A and 5B, in a first exemplary scenario, two remote UEs (remote UE 3-4a (remote UE #1) and remote UE 3-4b (remote UE #2)) are served by a RAN node 5 via a multi-hop U2N relaying path comprising a first relay UE 3-1a, an intermediate relay UE 3-1c, and a last relay UE 3-1b. In this example, the two remote UEs 3-4a, 3-4b are both connected (e.g., via an appropriate sidelink interface) to the same relay UE 3-1 (first relay UE 3-1a).

[0100] The first relay UE 3-1a operates as a UE-to-UE relay: for receiving uplink communication from either or both of the remote UEs 3-4a, 3-4b; for forwarding that uplink communication to the intermediate relay UE 3-1c; for receiving downlink communication, destined for either or both of the remote UEs 3-4a, 3-4b, forwarded by the intermediate relay UE 3-1c from the last relay UE 3-1b; and for forwarding that downlink communication to the correct remote UE 3-4a, 3-4b.

[0101] The intermediate relay UE 3-1c operates as a UE-to-UE relay: for receiving uplink communication, that originated from either of the remote UEs 3-4a, 3-4b, from the first relay UE 3-1a; for forwarding that uplink communication to the last relay UE 3-1b; for receiving downlink communication, destined for either or both of the remote UEs 3-4a, 3-4b, forwarded by the last relay UE 3-1b from the RAN node 5; and for forwarding that downlink communication to the first relay UE 3-1a.

[0102] The last relay UE 3-1b operates as a U2N relay: for receiving uplink communication, that originated from either of the remote UEs 3-4a, 3-4b, forwarded by the intermediate relay UE 3-1c from the first relay UE 3-1a; for forwarding that uplink communication to the RAN node 5; and for receiving downlink communication, destined for either or both of the remote UEs 3-4a, 3-4b, from the RAN node 5, and for forwarding that downlink communication to the intermediate relay UE 3-1c.

[0103] The relay UE closest (in the forwarding path) to the RAN node 5 - i.e., the last relay UE 3-1b (e.g., U2N relay) - will typically be in-coverage (of the RAN node 5) whereas each relay UE that is between the last relay UE 3-1b and the remote UEs 3-4a, 34b - i.e., the first relay UE 3-1a and / or each intermediate relay UE 3-1c - may be respectively out-of-coverage or in-coverage (of the RAN node 5).

[0104] As in example Fig. 5A, in a second exemplary scenario example (illustrated at Fig. 5B) two remote UEs (remote UE 3-4a (remote UE #1) and remote UE 3-4b (remote UE #2)) are each served by the same RAN node 5 via a multi-hop U2N relaying path (or part of that relaying path) comprising a first relay UE 3-1a, an intermediate relay UE 3-1c, and a last relay UE 3-1b. However, unlike the example illustrated at Fig. 5A in this example the two remote UEs 3-4a, 3-4b are connected (e.g., via an appropriate sidelink interface) to different relay UEs 3-1 of the same U2N relaying path. Specifically, a first remote UE (remote UE 3-4a (remote UE #1)) is connected (e.g., via an appropriate sidelink interface) to the first relay UE 3-1a, a second remote UE (remote UE 3-4b (remote UE #2)) is connected (e.g., via an appropriate sidelink interface) to the last relay UE 3-1b. Accordingly, in this exemplary scenario, the second remote UE 3-4b is effectively served via a single-hop U2N relaying path, whereas the first remote UE 3-4a is served via a multi-hop U2N relaying path (i.e., single-hop and multi-hop U2N relaying effectively coexist in parallel). It will, nevertheless, be appreciated that a similar scenario might involve the second remote UE 3-4b being connected (e.g., via an appropriate sidelink interface) to the intermediate relay UE 3-1c.

[0105] The first relay UE 3-1a operates as a UE-to-UE relay: for receiving uplink communication from the first remote UE 3-4a; for forwarding that uplink communication to the intermediate relay UE 3-1c; for receiving downlink communication, destined for the first remote UE 3-4a, forwarded by the intermediate relay UE 3-1c from the last relay UE 3-1b; and for forwarding that downlink communication to the first remote UE 3-4a.

[0106] The intermediate relay UE 3-1c operates as a UE-to-UE relay: for receiving uplink communication, that originated from the first remote UE 3-4a, from the first relay UE 3-1a; for forwarding that uplink communication to the last relay UE 3-1b; for receiving downlink communication, destined for the first remote UE 3-4a, forwarded by the last relay UE 3-1b from the RAN node 5; and for forwarding that downlink communication to the first relay UE 3-1a.

[0107] The last relay UE 3-1b operates as a U2N relay: for receiving uplink communication, that originated from the first remote UE 3-4a, forwarded by the intermediate relay UE 3-1c; for receiving uplink communication, that originated from the second remote UE 3-4b directly (e.g., over the air interface); for forwarding that uplink communication (from either or both of the remote UEs 3-4a, 3-4b) to the RAN node 5; and for receiving downlink communication, destined for either or both of the remote UEs 3-4a, 3-4b, from the RAN node 5; for forwarding downlink communication destined for the first remote UE 3-4a, to the intermediate relay UE 3-1c; and for forwarding downlink communication destined for the second remote UE 3-4b directly to that second remote UE 3-4b (e.g., over the air interface).

[0108] The relay UE 3-1 closest (in the forwarding path) to the RAN node 5 - i.e., the last relay UE 3-1b (e.g., U2N relay) - will typically be in-coverage (of the RAN node 5) whereas each relay UE 3-1 that is between the last relay UE 3-1b and the first remote UE 3-4a - i.e., the first relay UE 3-1a and / or each intermediate relay UE 3-1c - may be respectively out-of-coverage or in-coverage (of the RAN node 5).

[0109] < Multi-Hop UE-to-Network Relaying - Plural Remote UEs / Different Relaying Paths:> 　　Fig. 6 illustrates another possible multi-hop UE-to-network relaying scenario involving a plurality of remote UEs 3-4 served by relay UEs 3-1 of different relay paths that may occur in the communication system 1.

[0110] As seen in Fig. 6), in this example, multiple remote UEs 3-4 (remote UE 3-4a (remote UE #1), remote UE 3-4b (remote UE #2), remote UE 3-4c (remote UE #3), remote UE 3-4d (remote UE #4), and remote UE 3-4e (remote UE #5)) are each served by the same RAN node 5.

[0111] In this example, a first subset of the remote UEs 3-4 (remote UE 3-4a (remote UE #1), remote UE 3-4b (remote UE #2), remote UE 3-4c (remote UE #3), and remote UE 3-4d (remote UE #4)) is served via a first multi-hop U2N relaying path (or part of that relaying path), whereas a second subset of the remote UEs 3-4 (remote UE 3-4e (remote UE #5)) is served via a second multi-hop U2N relaying path. The first multi-hop U2N relaying path comprises a 'first path' first relay UE 3-1a-1, an intermediate relay UE 3-1c, and a last relay UE 3-1b. The second multi-hop U2N relaying path comprises a 'second path' first relay UE 3-1a-2, and the last relay UE 3-1b (that also forms part of the first multi-hop U2N relaying path.

[0112] In this example first and second remote UEs 3-4 (remote UE 3-4a (remote UE #1), and remote UE 3-4b (remote UE #2)) are both connected (e.g., via an appropriate sidelink interface) to the one of the first relay UEs (first path first relay UE 3-1a-1 (first path first relay UE #1)) for communicating via the first multi-hop U2N relaying path. A third remote UE (remote UE 3-4c (remote UE #3)) is connected (e.g., via an appropriate sidelink interface) to the intermediate relay UE 3-1c for communicating via part of that the first multi-hop U2N relaying path. A fourth remote UE (remote UE 3-4d (remote UE #4)) is connected (e.g., via an appropriate sidelink interface) to the last relay UE 3-1b for communicating via another part of that first multi-hop U2N relaying path. A fifth remote UE (remote UE 3-4e (remote UE #5)) is connected (e.g., via an appropriate sidelink interface) to the other first relay UE (second path first relay UE 3-1a-2 (second path first relay UE #1)) for communicating via the second multi-hop U2N relaying path.

[0113] The first path first relay UE 3-1a-1 operates as a UE-to-UE relay: for receiving uplink communication from the either or both of the remote UEs 3-4a, 3-4b connected to that first path first relay UE 3-1a-1; for forwarding that uplink communication to the intermediate relay UE 3-1c; for receiving downlink communication, destined for either or both of the remote UEs 3-4a, 3-4b connected to that first path first relay UE 3-1a-1, that is forwarded by the intermediate relay UE 3-1c from the last relay UE 3-1b; and for forwarding that downlink communication to the correct remote UE 3-4a, 3-4b connected to that first path first relay UE 3-1a-1.

[0114] The second path first relay UE 3-1a- operates as a UE-to-UE relay: for receiving uplink communication from the fifth remote UE 3-4e connected to that second path first relay UE 3-1a-2; for forwarding that uplink communication to the last relay UE 3-1b; for receiving downlink communication, destined for the fifth remote UE 3-4e connected to that second path first relay UE 3-1a-2, that is forwarded by the last relay UE 3-1b from the RAN node 5; and for forwarding that downlink communication to the fifth remote UE 3-4e connected to that second path first relay UE 3-1a-2.

[0115] The intermediate relay UE 3-1c operates as a UE-to-UE relay: for receiving uplink communication, that originated from either of the remote UEs 3-4a, 3-4b connected to the first path first relay UE 3-1a-1, from the first path first relay UE 3-1a-1; for receiving uplink communication, that originated from the third remote UE 3-4c directly (e.g., over the corresponding air interface); for forwarding that uplink communication (originating from any combination of the first, second, or third remote UEs 3-4a, 3-4b, or 3-4c) to the last relay UE 3-1b; for receiving downlink communication, destined for any combination of the first, second, or third remote UEs 3-4a, 3-4b, or 3-4c, forwarded by the last relay UE 3-1b from the RAN node 5; and for forwarding that downlink communication to the first path first relay UE 3-1a-1.

[0116] The last relay UE 3-1b operates as a U2N relay: for receiving uplink communication, that originated from any combination of the first, second, or third remote UEs 3-4a, 3-4b, or 3-4c, forwarded by the intermediate relay UE 3-1c; for receiving uplink communication, that originated from the fourth remote UE 3-4b directly (e.g., over the corresponding air interface); for receiving uplink communication, that originated from the fifth remote UE 3-4e, forwarded by the second path first relay UE 3-1c-1; for forwarding that uplink communication (from any combination of the first, second, third, fourth or fifth remote UEs 3-4a, 3-4b, 3-4c, 3-4d, or 3-4e) to the RAN node 5; and for receiving downlink communication, destined for any combination of the first, second, third, fourth or fifth remote UEs 3-4a, 3-4b, 3-4c, 3-4d, or 3-4e, from the RAN node 5; for forwarding downlink communication destined for the first, second, or third remote UEs 3-4a, 3-4b, or 3-4c, to the intermediate relay UE 3-1c; for forwarding downlink communication destined for the fourth remote UE 3-4d directly to that fourth remote UE 3-4d (e.g., over the corresponding air interface); and for forwarding downlink communication destined for the fifth remote UE 3-4e to the second path first relay UE 3-1a-2.

[0117] The relay UE closest (in the forwarding path) to the RAN node 5 - i.e., the last relay UE 3-1b (e.g., U2N relay) - will typically be in-coverage (of the RAN node 5) whereas each relay UE that is between the last relay UE 3-1b and the first remote UE 3-4a - i.e., the first path first relay UE 3-1a-1, second path first relay UE 3-1a-2, and / or each intermediate relay UE 3-1c - may be respectively out-of-coverage or in-coverage (of the RAN node 5).

[0118] User plane and control plane protocol stacks that may be used for (or adapted to be used for) the various multi-path U2N relaying scenarios introduced above (and many others) will now be described, by way of example only, with reference to Figs. 7 and 8.

[0119] < Multi-Hop U2N Relay Architecture User Plane Protocol Stacks:> 　　Fig. 7 is a simplified illustration of user plane protocol stacks for a multi-hop U2N relay architecture that may be implemented in the communication system 1.

[0120] In this example, there a single remote UE 3-4 is shown that is configured to communicate with a RAN node 5 via a first relay UE 3-1a, an intermediate relay UE 3-1c, and a last relay UE 3-1b (that is effectively a U2N relay) - i.e., the example corresponds to example Fig. 4A. Nevertheless, the respective user plane protocol stacks shown for each of the relay UEs 3-1 are generally applicable to those of corresponding relay UEs in other multi-hop U2N relaying scenarios.

[0121] As seen in Figs. 4A and 4B, the user plane protocol stacks include a number of protocol layers that are terminated at the remote UE 3-4 and at the RAN node 5. These layers include a SDAP sublayer (Uu-SDAP), and a radio resource control (RRC) sublayer (for the control plane), above a PDCP (Uu-PDCP) sublayer.

[0122] The SDAP layer is the highest L2 sublayer of the protocol stack in this example. It is responsible for QoS flow handling across the air interface and N3 interface. The SDAP sublayer can have multiple SDAP entities (e.g., one for each PDU session between the RAN node 5 and remote UE 3-4) where SDAP entity establishment / release is initiated by RRC.

[0123] In particular, SDAP is responsible for the transfer of user plane data between the remote UE 3-4 and the core network 7 (UPF 11). An SDAP entity maps each QoS flow from higher layers, within a particular PDU session, to a respective DRB established, via lower layers (e.g., PDCP and RLC) with the appropriate level of QoS, over the air interface between the remote UE 3-4 and the RAN node 5. As those skilled in the art will appreciate, the QoS flow may be in either the downlink or in the uplink and there may be more than one such QoS flow within the PDU session. It will be appreciated that the SDAP layer is not present in some architectures (e.g., in a non-stand-alone (NSA) architecture).

[0124] The PDCP sublayer is the layer 2 sublayer that sits below the SDAP sublayer for user plane data. The PDCP sublayer provides a number of functions depending on requirements including, for example: transfer of user plane data (to / from the SDAP sublayer); maintenance of PDCP sequence numbers; header compression and decompression (e.g., using the robust header compression (ROHC) protocol); ciphering and deciphering; integrity protection and integrity verification; timer based discarding of packets (PDCP SDUs); routing (e.g., for split bearers); duplication; reordering and in-order delivery; out-of-order delivery; and / or duplicate discarding.

[0125] In particular, one or more PDCP entities may be established in the PDCP sublayer for receiving data from higher layers and for processing the PDCP SDUs through the PDCP layer to become PDCP PDUs (and vice versa). Following the processing of the PDCP SDUs to form PDCP PDUs, the PDCP entity transfers the PDCP PDUs to the RLC sublayer (where they are received as RLC SDUs).

[0126] A PDCP entity at the RAN node 5 may send a PDCP status report (a PDCP status PDU) to a corresponding peer PDCP entity at the remote UE 3-4 to indicate the received status of uplink PDCP packets at the RAN node 5. Similarly, a PDCP entity at the remote UE 3-4 may send a PDCP status report / PDU to a corresponding peer PDCP entity at the RAN node 5 to indicate the received status of downlink PDCP packets at the remote UE 3-4. A PDCP status report PDU will typically include a 'PDU type' field to identify the PDU as being a PDCP status report type of PDU. The PDCP status report will also specify a first missing count (FMC) value for the counter associated with PDCP SDUs having sequence numbers (SNs). The count value is a concatenation of a hyper frame number (HFN) and the PDCP SN. A bitmap may also, optionally, be included to indicate what count values, following the FMC, are also missing. On receipt of a PDCP status report a PDCP entity of a transmitting device (RAN node 5 / UE 3) can thus discard all packets which have been successfully received at a PDCP entity of the peer receiving device (UE 3 / RAN node 5).

[0127] Below the PDCP sublayer, the protocol stacks include a number of layers that may be respectively terminated at either side of each UE-to-UE interface (e.g., PC5) (between the remote UE 3-4 and the first relay UE 3-1a, between the first relay UE 3-1a and the intermediate relay UE 3-1c, and between the intermediate relay UE 3-1c and the last relay UE 3-1b (e.g., U2N relay)). The protocol stacks also include a number of corresponding layers that are respectively terminated at either side of the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. Hence, the layers may be terminated at each hop (i.e., the link between U2N remote UE 3-4 and the U2N relay UE 3-1 and the link between U2N relay UE 3-1 and the RAN node 5).

[0128] The layers below the PDCP sublayer include SRAP sublayers (PC5-SRAP / Uu-SRAP), RLC sublayers (PC5-RLC / Uu-RLC), MAC sublayers (PC5-MAC / Uu-MAC), and PHY sublayers (PC5-PHY / Uu-PHY).

[0129] The SRAP sublayer is provided, above the RLC sublayer. For U2N relaying in the uplink, the SRAP sublayer over the air interface (e.g., Uu) (the 'Uu SRAP' sublayer) between the last relay UE 3-1b and the RAN node 5, supports uplink bearer mapping between the incoming (ingress) RLC channels over the UE-to-UE interface (e.g., PC5) for relaying, and the outbound (egress) RLC channels over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. For uplink relaying traffic, the different end-to-end radio bearers (e.g., DRBs for user plane traffic) of the same remote UE 3-4 and / or different remote UEs 3-4 may be multiplexed over the same (Uu) RLC channel. The (Uu) SRAP sublayer supports remote UE identification for the uplink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are included in a (Uu) SRAP header for uplink so the RAN node 5 can correlate the received packets for a specific PDCP entity associated with the correct (Uu) radio bearer of the remote UE 3-4. The SRAP sublayer over UE-to-UE interfaces (e.g., PC5) (which may be referred to as the 'PC5 SRAP' sublayer), at the remote UE 3-4, the first relay UE 3-1a, the intermediate relay UE 3-1c, and the last relay UE 3-1b (e.g., U2N relay), each supports uplink bearer mapping between a remote UE (Uu) radio bearer and egress (PC5) RLC channels.

[0130] For U2N relaying in the downlink, the (Uu) SRAP sublayer supports downlink bearer mapping at the RAN node 5 to map end-to-end radio bearers (DRBs) of a remote UE 3-4 into a (Uu) RLC channel over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. The (Uu) SRAP sublayer can be used to support downlink bearer mapping and data multiplexing between multiple end-to-end radio bearers (DRBs) of the remote UE 3-4 and / or different remote UEs and one (Uu) RLC channel over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. The (Uu) SRAP sublayer also supports remote UE identification for downlink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are put into the (Uu) SRAP header by the RAN node 5 for downlink so the last relay UE 3-1b can map the received packets from the remote UE (Uu) radio bearer to the associated (PC5) RLC channel. The (PC5) SRAP sublayer at the last relay UE 3-1b also supports downlink bearer mapping between ingress (Uu) RLC channels and egress (PC5) RLC channels. The respective (PC5) SRAP sublayer at the remote UE 3-4, the first relay UE 3-1a, the intermediate relay UE 3-1c, and the last relay UE 3-1b (e.g., U2N relay), each supports downlink bearer mapping between ingress (PC5) RLC channels and remote UE (Uu) radio bearers.

[0131] On the last relay UE 3-1b, the SRAP sublayer contains one SRAP entity at the air interface (e.g., Uu) and a separate collocated SRAP entity at the UE-to-UE interface (e.g., PC5) . On the remote UE 3-4, the SRAP sublayer contains an SRAP entity at the UE-to-UE interface (e.g., PC5) . On the UE-to-UE (U2U) relay UEs 3-1 (i.e., first / intermediate relay UEs 3-1a / 3-1c) and the remote UE 3-4, the SRAP sublayer, in this example, includes a single SRAP entity at the UE-to-UE interface (e.g., PC5) .

[0132] Each SRAP entity has a transmitting part and a receiving part. Across the UE-to-UE interface (e.g., PC5) in the U2N case, for the transmitting part of the SRAP entity at the remote UE there is a corresponding receiving part of the SRAP entity at the U2N relay UE 3-1, and vice versa. Across the air interface (e.g., Uu), for the transmitting part of the SRAP entity at the U2N relay UE 3-1 there is a corresponding receiving part of the SRAP entity at the RAN node 5, and vice versa. Across the UE-to-UE interface (e.g., PC5) in the U2U case, for the transmitting part of the SRAP entity at the remote UE 3-4 there is a corresponding receiving part of the SRAP entity at the recipient relay UE 3-1a / 3-1c), and vice versa.

[0133] The RLC layer is another layer 2 sublayer. The RLC sublayer provides a radio link protocol used over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5 and, in the illustrated example, over each UE-to-UE interface (e.g., PC5) (between the remote UE 3-4 and the first relay UE 3-1a, between the first relay UE 3-1a and the intermediate relay UE 3-1c, and between the intermediate relay UE 3-1c and the last relay UE 3-1b (e.g., U2N relay)). The RLC sublayer provides a number of functions depending on requirements including, for example: transfer of upper layer (PDCP) PDUs in one of three modes including acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM); error correction through automatic repeat requests (ARQ) for AM data transfer; concatenation, segmentation and reassembly of RLC SDUs (UM and AM); re-segmentation of RLC data PDUs when a complete RLC PDU cannot be transmitted (AM); reordering of RLC data PDUs (UM and AM); duplicate detection (UM and AM); RLC SDU discard (UM and AM); RLC re-establishment; protocol error detection and recovery.

[0134] In particular, one or more RLC entities may be established in the RLC sublayer for receiving data from higher layers and for processing the RLC SDUs through the RLC layer to become RLC PDUs (and vice versa). Following the processing of the RLC SDUs to form RLC PDUs, the RLC entity transfers the RLC PDUs to the MAC sublayer (where they are received as MAC SDUs).

[0135] A receiving RLC entity in one device (e.g., the RAN node 5 or remote UE 3-4, or relay UE 3-1a, 3-1b, 3-1c) can generate an RLC status report indicating the receive status of packets (RLC SDUs) successfully received (or not received) from a transmitting RLC entity at a corresponding peer device (e.g., the RAN node 5, remote UE 3-4, or relay UE 3-1a, 3-1b, 3-1c) and send the RLC status report as an RLC status PDU to the peer device. An RLC status report / PDU will typically include the receive status for a plurality of received RLC SDUs (and possibly RLC SDU segments). On receipt of the RLC status report / PDU, the RLC entity at the peer (transmitting) device will iterate through the positively acknowledged packets in the RLC status report / PDU and notify the PDCP layer of each RLC SDU (and hence PDCP PDU) that has been positively acknowledged.

[0136] Accordingly, the RAN node 5 and remote UE 3-4 may operate data radio bearers (DRBs) in an RLC acknowledge mode (AM) indirectly via the relay UEs 3-1a, 3-1b, 3-1c.

[0137] In the uplink, an RLC entity in the RAN node 5 can acknowledge RLC SDUs / RLC SDU segments relayed from the remote UE 3-4 by the relay UEs 3-1a, 3-1b, 3-1c. Similarly, an RLC entity in each relay UE 3-1a, 3-1b, 3-1c can respectively acknowledge RLC SDUs / RLC SDU segments, from the remote UE 3-4 or relay UE 3-1a, 3-1c from which those RLC SDUs / RLC SDU segments are received, for relaying towards the RAN node 5. A corresponding RLC entity at the remote UE 3-4 can process acknowledgments received (in the RLC status PDU) from the first relay UE 3-1a and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The respective RLC entity at each relay UE 3-1a, 3-1b, 3-1c can process acknowledgments received (in the RLC status PDU) from the RAN node 5, or other relay UE 3-1b, 3-1c, and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the RAN node 5 or other relay UE 3-1b, 3-1c).

[0138] In the downlink, an RLC entity in the remote UE 3-4 can acknowledge RLC SDUs / RLC SDU segments relayed from the RAN node 5 by the relay UEs 3-1a, 3-1b, 3-1c. Similarly, an RLC entity in each relay UE 3-1a, 3-1b, 3-1c can respectively acknowledge RLC SDUs / RLC SDU segments received, from the RAN node 5, or relay UE 3-1b, 3-1c from which those RLC SDUs / RLC SDU segments are received, for relaying towards the remote UE 3-4. A corresponding RLC entity at the RAN node 5 can process acknowledgments received (in the RLC status PDU) from the last relay UE 3-1b and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The respective RLC entity at each relay UE 3-1a, 3-1b, 3-1c can process acknowledgments received (in the RLC status PDU) from the remote UE 3-4, or other relay UE 3-1a, 3-1c, and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the remote UE 3-4 or other relay UE 3-1a, 3-1c).

[0139] The MAC sublayer receives the RLC PDUs (as MAC SDUs) from the RLC sublayer and processes them to form MAC PDUs (which are packaged as transport blocks (TBs)) for transmission via the PHY sublayer. PDCP PDUs carrying data from the upper layers may also be referred to as PDCP data PDUs to distinguish them from a PDCP control PDU carrying control data.

[0140] It will be appreciated that whilst, in Fig. 7, the first relay UE 3-1a and intermediate relay UE 3-1c are each respectively illustrated as having a number of common ingress / egress sublayer entities for each sublayer, this need not be the case. For example, the (PC5) PHY, (PC5) MAC, and / or (PC5) RLC sublayers for the first relay UE 3-1a and intermediate relay UE 3-1c may each be respectively split into a pair of complementary entities - one for an ingress (PC5) relay RLC channel and one for and one for an egress (PC5) relay RLC channel.

[0141] < Multi-Hop U2N Relay Architecture Control Plane Protocol Stacks:> 　　Fig. 8 is a simplified illustration of control plane protocol stacks for a multi-hop U2N relay architecture that may be implemented in the communication system 1.

[0142] In this example, there a single remote UE 3-4 is shown that is configured to communicate with a RAN node 5 via a first relay UE 3-1a, an intermediate relay UE 3-1c, and a last relay UE 3-1b (that is effectively a U2N relay) - i.e., the example corresponds to example a) of Figs. 4A and 4B. Nevertheless, the respective control plane protocol stacks shown for each of the relay UEs 3-1 are generally applicable to those of corresponding relay UEs 3-1 in other multi-hop U2N relaying scenarios.

[0143] As seen in Figs. 4A and 4B, the control plane protocol stacks include a number of protocol layers that are terminated at the remote UE 3-4 and at the RAN node 5. These layers include an RRC sublayer (Uu-RRC), above a PDCP (Uu-PDCP) sublayer.

[0144] The RRC layer is considered to be a layer 3 sublayer and is the highest layer in the control plane of the access stratum (AS). It is also responsible for transferring messages of the NAS, which is located above the RRC layer. RRC is responsible for handling many RAN-related control plane procedures such as: broadcasting SI; transmission of paging notifications (which may also be referred to as paging messages) to notify a UE about incoming connection requests; connection management; handling UE capabilities; measurement configuration and reporting; etc.

[0145] The PDCP sublayer is the layer 2 sublayer that sits below the RRC sublayer for control plane data. The PDCP sublayer provides a number of functions depending on requirements including, for example: transfer of control plane data (to / from the RRC sublayer); maintenance of PDCP sequence numbers; header compression and decompression (e.g., using the robust header compression (ROHC) protocol); ciphering and deciphering; integrity protection and integrity verification; timer based discarding of packets (PDCP SDUs); routing (e.g., for split bearers); duplication; reordering and in-order delivery; out-of-order delivery; and / or duplicate discarding.

[0146] In particular, one or more PDCP entities may be established in the PDCP sublayer for receiving data from higher layers and for processing the PDCP SDUs through the PDCP layer to become PDCP PDUs (and vice versa). Following the processing of the PDCP SDUs to form PDCP PDUs, the PDCP entity transfers the PDCP PDUs to the RLC sublayer (where they are received as RLC SDUs).

[0147] A PDCP entity at the RAN node 5 may send a PDCP status report (a PDCP status PDU) to a corresponding peer PDCP entity at the remote UE 3-4 to indicate the received status of uplink PDCP packets at the RAN node 5. Similarly, a PDCP entity at the remote UE 3-4 may send a PDCP status report / PDU to a corresponding peer PDCP entity at the RAN node 5 to indicate the received status of downlink PDCP packets at the remote UE 3-4. A PDCP status report PDU will typically include a 'PDU type' field to identify the PDU as being a PDCP status report type of PDU. The PDCP status report will also specify a first missing count (FMC) value for the counter associated with PDCP SDUs having sequence numbers (SNs). The count value is a concatenation of a hyper frame number (HFN) and the PDCP SN. A bitmap may also, optionally, be included to indicate what count values, following the FMC, are also missing. On receipt of a PDCP status report a PDCP entity of a transmitting device (RAN node 5 / UE 3) can thus discard all packets which have been successfully received at a PDCP entity of the peer receiving device (UE 3 / RAN node 5).

[0148] Below the PDCP sublayer, the protocol stacks include a number of layers that may be respectively terminated at either side of each UE-to-UE interface (e.g., PC5) (between the remote UE 3-4 and the first relay UE 3-1a, between the first relay UE 3-1a and the intermediate relay UE 3-1c, and between the intermediate relay UE 3-1c and the last relay UE 3-1b (e.g., U2N relay)). The protocol stacks also include a number of corresponding layers that are respectively terminated at either side of the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. Hence, the layers may be terminated at each hop (i.e., the link between U2N remote UE 3-4 and the U2N relay UE 3-1 and the link between U2N relay UE 3-1 and the RAN node 5).

[0149] The layers below the PDCP sublayer include SRAP sublayers (PC5-SRAP / Uu-SRAP), RLC sublayers (PC5-RLC / Uu-RLC), MAC sublayers (PC5-MAC / Uu-MAC), and PHY sublayers (PC5-PHY / Uu-PHY).

[0150] The SRAP sublayer is provided, above the RLC sublayer. For U2N relaying in the uplink, the SRAP sublayer over the air interface (e.g., Uu) (the 'Uu SRAP' sublayer) between the last relay UE 3-1b and the RAN node 5, supports uplink bearer mapping between the incoming (ingress) RLC channels over the UE-to-UE interface (e.g., PC5) for relaying, and the outbound (egress) RLC channels over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. For uplink relaying traffic, the different end-to-end radio bearers (e.g., SRBs for control plane traffic) of the same remote UE 3-4 and / or different remote UEs may be multiplexed over the same (Uu) RLC channel. The (Uu) SRAP sublayer supports remote UE identification for the uplink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are included in a (Uu) SRAP header for uplink so the RAN node can correlate the received packets for a specific PDCP entity associated with the correct (Uu) radio bearer of the remote UE 3-4. The SRAP sublayer over UE-to-UE interfaces (e.g., PC5) (which may be referred to as the 'PC5 SRAP' sublayer), at the remote UE 3-4, the first relay UE 3-1a, the intermediate relay UE 3-1c, and the last relay UE 3-1b (e.g., U2N relay), each supports uplink bearer mapping between a remote UE (Uu) radio bearer and egress (PC5) RLC channels.

[0151] For U2N relaying in the downlink, the (Uu) SRAP sublayer supports downlink bearer mapping at the RAN node 5 to map end-to-end radio bearers (SRBs) of a remote UE 3-4 into a (Uu) RLC channel over the air interface (e.g., Uu) between the last UE 3-1b and the RAN node 5. The (Uu) SRAP sublayer can be used to support downlink bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs) of the remote UE 3-4 and / or different remote UEs and one (Uu) RLC channel over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5. The (Uu) SRAP sublayer also supports remote UE identification for downlink traffic. The identity information of the remote UE (Uu) radio bearer and a local remote UE ID are put into the (Uu) SRAP header by the RAN node 5 for downlink so the last relay UE 3-1b can map the received packets from the remote UE (Uu) radio bearer to the associated (PC5) RLC channel. The (PC5) SRAP sublayer at last relay UE 3-1b also supports downlink bearer mapping between ingress (Uu) RLC channels and egress (PC5) RLC channels. The respective (PC5) SRAP sublayer at the remote UE 3-4, the first relay UE 3-1a, the intermediate relay UE 3-1c, and the last relay UE 3-1b (e.g., U2N relay), each supports downlink bearer mapping between ingress (PC5) RLC channels and remote UE (Uu) radio bearers.

[0152] On the last relay UE 3-1b, the SRAP sublayer contains one SRAP entity at the air interface (e.g., Uu) and a separate collocated SRAP entity at the UE-to-UE interface (e.g., PC5) . On the remote UE 3-4, the SRAP sublayer contains an SRAP entity at the UE-to-UE interface (e.g., PC5) . On the UE-to-UE (U2U) relay UEs 3-1 (i.e., first / intermediate relay UEs 3-1a / 3-1c) and the remote UE 3-4, the SRAP sublayer, in this example, includes a single SRAP entity at the UE-to-UE interface (e.g., PC5) .

[0153] Each SRAP entity has a transmitting part and a receiving part. Across the UE-to-UE interface (e.g., PC5) in the U2N case, for the transmitting part of the SRAP entity at the remote UE there is a corresponding receiving part of the SRAP entity at the U2N relay UE 3-1, and vice versa. Across the air interface (e.g., Uu), for the transmitting part of the SRAP entity at the U2N relay UE 3-1 there is a corresponding receiving part of the SRAP entity at the RAN node 5, and vice versa. Across the UE-to-UE interface (e.g., PC5) in the U2U case, for the transmitting part of the SRAP entity at the remote UE 3-4 there is a corresponding receiving part of the SRAP entity at the recipient relay UE 3-1a / 3-1c), and vice versa.

[0154] The RLC layer is another layer 2 sublayer. The RLC sublayer provides a radio link protocol used over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5 and, in the illustrated example, over each UE-to-UE interface (e.g., PC5) (between the remote UE 3-4 and the first relay UE 3-1a, between the first relay UE 3-1a and the intermediate relay UE 3-1c, and between the intermediate relay UE 3-1c and the last relay UE 3-1b (e.g., U2N relay)). The RLC sublayer provides a number of functions depending on requirements including, for example: transfer of upper layer (PDCP) PDUs in one of three modes including acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM); error correction through automatic repeat requests (ARQ) for AM data transfer; concatenation, segmentation and reassembly of RLC SDUs (UM and AM); re-segmentation of RLC data PDUs when a complete RLC PDU cannot be transmitted (AM); reordering of RLC data PDUs (UM and AM); duplicate detection (UM and AM); RLC SDU discard (UM and AM); RLC re-establishment; protocol error detection and recovery.

[0155] In particular, one or more RLC entities may be established in the RLC sublayer for receiving data from higher layers and for processing the RLC SDUs through the RLC layer to become RLC PDUs (and vice versa). Following the processing of the RLC SDUs to form RLC PDUs, the RLC entity transfers the RLC PDUs to the MAC sublayer (where they are received as MAC SDUs).

[0156] A receiving RLC entity in one device (e.g., the RAN node 5 or remote UE 3-4, or relay UE 3-1a, 3-1b, 3-1c) can generate an RLC status report indicating the receive status of packets (RLC SDUs) successfully received (or not received) from a transmitting RLC entity at a corresponding peer device (e.g., the RAN node 5, remote UE 3-4, or relay UE 3-1a, 3-1b, 3-1c) and send the RLC status report as an RLC status PDU to the peer device. An RLC status report / PDU will typically include the receive status for a plurality of received RLC SDUs (and possibly RLC SDU segments). On receipt of the RLC status report / PDU, the RLC entity at the peer (transmitting) device will iterate through the positively acknowledged packets in the RLC status report / PDU and notify the PDCP layer of each RLC SDU (and hence PDCP PDU) that has been positively acknowledged.

[0157] In the uplink, an RLC entity in the RAN node 5 can acknowledge RLC SDUs / RLC SDU segments relayed from the remote UE 3-4 by the relay UEs 3-1a, 3-1b, 3-1c. Similarly, an RLC entity in each relay UE 3-1a, 3-1b, 3-1c can respectively acknowledge RLC SDUs / RLC SDU segments, from the remote UE 3-4 or relay UE 3-1a, 3-1c from which those RLC SDUs / RLC SDU segments are received, for relaying towards the RAN node 5. A corresponding RLC entity at the remote UE 3-4 can process acknowledgments received (in the RLC status PDU) from the first relay UE 3-1a and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The respective RLC entity at each relay UE 3-1a, 3-1b, 3-1c can process acknowledgments received (in the RLC status PDU) from the RAN node 5, or other relay UE 3-1b, 3-1c, and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the RAN node 5 or other relay UE 3-1b, 3-1c).

[0158] In the downlink, an RLC entity in the remote UE 3-4 can acknowledge RLC SDUs / RLC SDU segments relayed from the RAN node 5 by the relay UEs 3-1a, 3-1b, 3-1c. Similarly, an RLC entity in each relay UE 3-1a, 3-1b, 3-1c can respectively acknowledge RLC SDUs / RLC SDU segments received, from the RAN node 5, or relay UE 3-1b, 3-1c from which those RLC SDUs / RLC SDU segments are received, for relaying towards the remote UE 3-4. A corresponding RLC entity at the RAN node 5 can process acknowledgments received (in the RLC status PDU) from the last relay UE 3-1b and notify a corresponding PDCP layer entity that the associated RLC SDU (and hence the corresponding PDCP data PDU) has been acknowledged. The respective RLC entity at each relay UE 3-1a, 3-1b, 3-1c can process acknowledgments received (in the RLC status PDU) from the remote UE 3-4, or other relay UE 3-1a, 3-1c, and discard RLC packets, from an RLC buffer, which have been positively acknowledged (and retain RLC packets in the buffer that have not been acknowledged in an RLC status from the remote UE 3-4 or other relay UE 3-1a, 3-1c).

[0159] The MAC sublayer receives the RLC PDUs (as MAC SDUs) from the RLC sublayer and processes them to form MAC PDUs (which are packaged as transport blocks (TBs)) for transmission via the PHY sublayer. PDCP PDUs carrying data from the upper layers may also be referred to as PDCP data PDUs to distinguish them from a PAC control PDU carrying control data.

[0160] It will be appreciated that whilst, in Fig. 8, the first relay UE 3-1a and intermediate relay UE 3-1c are each respectively illustrated as having a number of common ingress / egress sublayer entities for each sublayer, this need not be the case. For example, the (PC5) PHY, (PC5) MAC, and / or (PC5) RLC for the first relay UE 3-1a and intermediate relay UE 3-1c may each be respectively split into a pair of complementary entities - one for an ingress (PC5) relay RLC channel and one for and one for an egress (PC5) relay RLC channel.

[0161] Before the remote UE 3-4 is able to fully communicate with the RAN node 5, and wider communication network, in the uplink or the downlink, a connection (e.g., an RRC connection) has to be established. A procedure for establishing a connection between the remote UE 3-4 and the RAN node 5, in the context of multi-hop U2N relaying, will now be described, by way of example only, with reference to Fig. 9.

[0162] < Connection Establishment for Multi-Hop U2N Relaying> 　　Fig. 9 is a simplified sequence diagram illustrating a procedure for establishing a connection between the remote UE 3-4 and the RAN node 5, in the context of multi-hop U2N relaying, in the communication system 1.

[0163] As seen in Fig. 9, the illustrated procedure begins at S902 when a remote UE 3-4 (e.g., an L2 U2N remote UE), first relay UE 3-1a, intermediate relay UE 3-1c, and last relay UE 3-1b engage in a discovery procedure (e.g., to discover associated UE-to-UE direct communication capable UEs 3 suitable for operating as relay UEs 3-1, and for forming a multi-hop U2N relaying routing path from the remote UE 3-4 to the last relay UE 3-1b, and hence the RAN node 5).

[0164] The adjacent UEs 3 (remote UE 3-4 and relay UEs 3-1 discovered during discovery) are mutually configured to establish, at S904, a respective UE-to-UE interface (e.g., PC5) based connection (e.g., RRC connection) between each adjacent UE 3 (e.g., remote UE 3-4 <= => first relay UE 3-1a, first relay UE 3-1a <= => intermediate relay UE 3-1c, intermediate relay UE 3-1c <= => last relay UE 3-1b). This may be achieved using an appropriate direct UE-to-UE (sidelink) unicast link establishment procedure that will be familiar to those skilled in the art (e.g., but not limited to, the NR sidelink (PC5) unicast link establishment procedure, or the like).

[0165] The remote UE 3-4 is configured to send, at S906, a first RRC message to request the establishment of an associated RRC connection (e.g., an 'RRC Setup Request' or the like) with the RAN node 5 via the first relay UE 3-1a, for example using a specified (PC5) relay RLC channel configuration or the like. This RRC message for requesting the establishment of an associated RRC connection may, for example, be sent on a (PC5) relay RLC channel associated with a channel identifier (e.g., 'SL-RLC-ChannelID' or the like), for identifying a (PC5) relay RLC channel in the link between the relay UE 3-1 and the remote UE 3-4, corresponding to a specific channel identity (e.g. 'SL-RLC0' or the like). This RRC message for requesting the establishment of an associated RRC connection may be provided, for example, via an appropriate 'common' SRB (e.g., 'SRB0' on a common control channel (CCCH) logical channel).

[0166] The first relay UE 3-1a may then send an appropriate message, towards the RAN node 5 (e.g., to the intermediate relay UE 3-1c), for requesting the dedicated configurations required to support the multi-hop relay operation for the (U2N) remote UE 3-4 (e.g., a 'SidelinkUEInformationNR' message or the like).

[0167] If the first relay UE 3-1a is not (already) in an RRC connected mode / state, then that first relay UE 3-1a may also perform its own (e.g., Uu RRC) connection establishment procedure via the intermediate relay UE 3-1c (in a similar manner to the (U2N) remote UE 3-4) - e.g., upon reception of the a message from the (U2N) remote UE 3-4 on the specified (PC5) relay RLC channel.

[0168] The intermediate relay UE 3-1c may also send a message, towards the RAN node 5 (e.g., to the last relay UE 3-1b), for requesting the dedicated configurations required to support the multi-hop relay operation for the (U2N) remote UE 3-4 (e.g., a 'SidelinkUEInformationNR' message or the like). If the intermediate relay UE 3-1c is not (already) in an RRC connected mode / state, then that intermediate relay UE 3-1c may also perform its own (e.g., Uu RRC) connection establishment procedure via the last relay UE 3-1b (in a similar manner to the (U2N) remote UE 3-4) - e.g., upon reception of a message from the first relay UE 3-1a on the specified (PC5) relay RLC channel.

[0169] The last relay UE 3-1b may also send a message, to the RAN node 5, for requesting the dedicated configurations required to support the multi-hop relay operation for the (U2N) remote UE 3-4 (e.g., a 'SidelinkUEInformationNR' message or the like). If the last relay UE 3-1b is not (already) in an RRC connected mode / state, then that last relay UE 3-1b may also perform its own (e.g., Uu RRC) connection establishment procedure with the RAN node 5 - e.g., upon reception of a message from the intermediate relay UE 3-1c on the specified (PC5) relay RLC channel.

[0170] At step S908, the RAN node 5 may respond, to the first RRC message to request the establishment of an associated RRC connection (e.g., the 'RRC Setup Request' or the like) from the remote UE 3-4, with an appropriate RRC message (e.g., an 'RRC Setup' message or the like) for providing information for establishing an SRB (e.g., 'SRB1') specifically for communication of RRC messages (which may possibly include a piggybacked NAS message). This RRC message for establishing an SRB may be provided via the common SRB (e.g., SRB0 on a CCCH logical channel) and may be forwarded to the remote UE 3-4 via the last relay UE 3-1b, intermediate relay UE 3-1c, and first relay UE 3-1a.

[0171] At step S910, the RAN node 5, last relay UE 3-1b, intermediate relay UE 3-1c and first relay UE 3-1a perform relaying channel setup procedure over the air interface (e.g., Uu). According to a configuration from the RAN node 5, the first relay UE 3-1a / remote UE 3-4 may establish a (PC5) relay RLC channel for relaying of SRB1 towards the remote UE 3-4 / first relay UE 3-1a over the (PC5) between them. Similarly, the intermediate relay UE 3-1c / first relay UE 3-1a may establish a (PC5) relay RLC channel for relaying of SRB1 towards the first relay UE 3-1a / intermediate relay UE 3-1c over the UE-to-UE interface (e.g., PC5) between them. Moreover, the last relay UE 3-1b / intermediate relay UE 3-1c may establish a (PC5) relay RLC channel for relaying of SRB1 towards the intermediate relay UE 3-1c / last relay UE 3-1b over the UE-to-UE interface (e.g., PC5) between them.

[0172] At step S912, an appropriate RRC message (e.g., an 'RRC Setup Complete' message or the like) is sent by the remote UE 3-4 (e.g., on the established SRB1) to confirm the successful completion of the RRC connection establishment. This RRC message is sent by the (U2N) remote UE 3-4 to the RAN node 5 via the first relay UE 3-1a, intermediate relay UE 3-1c and the last relay UE 3-1b using SRB1 relaying channels over the UE-to-UE interface (e.g., PC5) and an SRB1 relaying channel configured to the last relay UE 3-1b over the air interface (e.g., Uu). Then the (U2N) remote UE 3-4 will effectively be in an RRC connected mode / state with the RAN node 5.

[0173] At steps S914 and S916, the remote UE 3-4 and the RAN node 5 establish security following an appropriate security mode procedure over the air interface (e.g. a 'Uu security mode procedure' or the like). As part of this procedure the RAN node 5 and remote UE 3-4 exchange appropriate security messages (e.g., including a 'Security Mode Command' message from the RAN node 5 to the remote UE 3-4 as seen at S914 and a 'Security Mode Complete' message from the remote UE 3-4 to the RAN node 5 as seen at S916). The security messages are forwarded through the last relay UE 3-1b, intermediate relay UE 3-1c, and first relay UE 3-1a (and vice versa).

[0174] The RAN node 5 sends, at S918 an appropriate RRC message / command (e.g., an RRC reconfiguration message or the like), to the remote UE 3-4, for modifying the RRC connection (e.g., conveying information for measurement configuration, mobility control, radio resource configuration, AS security configuration and / or the like). This RRC message may be sent via the last relay UE 3-1b, intermediate relay UE 3-1c, and first relay UE 3-1a to setup the end-to-end SRB (e.g., the SRB for NAS messages and for RRC messages which include logged measurement information - 'SRB2') and DRBs of the remote UE 3-4. At S920 the remote UE 3-4 sends an appropriate RRC message (e.g., an RRC Reconfiguration Complete message or the like) to the RAN node 5 to confirm the successful completion of the RRC connection reconfiguration. This RRC message may be sent via the first relay UE 3-1a, intermediate relay UE 3-1c, and last relay UE 3-1b (e.g., as a response to an RRC Reconfiguration message). Moreover, the RAN node 5 may configure, at S922, additional (Uu) relay RLC channels between the RAN node 5 and the last relay UE 3-1b, and (PC5) relay RLC channels for the relaying traffic. The (PC5) relay RLC channels may, for example, be established between each pair of relay UEs 3-1 (e.g., first relay UE 3-1a <= => intermediate relay UE 3-1c, intermediate relay UE 3-1c <= => last relay UE 3-1b), and between the first relay UE 3-1a and the remote UE 3-4 (e.g., remote UE 3-4 <= => first relay UE 3-1a).

[0175] In the context of multi-hop U2N relaying, in order for the remote UE 3-4 to communicate with the RAN node 5, and wider communication network appropriate uplink / downlink, bearer mapping is typically performed, at each relay UE 3-1, to ensure that the communication is correctly routed between the incoming ingress relay channel and the outgoing egress relay channel. Some of the general principles that may be applied in respect of such bearer mapping for the uplink and for the downlink, in the context of multi-hop U2N relaying, and associated considerations, will now be described briefly by way of example only.

[0176] < Bearer Mapping (Uplink)> 　　In the context of multi-hop U2N relaying, and bearer mapping for the uplink, the operation of the last relay UE 3-1b is similar to that of a U2N relay for a single-hop scenario with the exception that the downstream UE is a relay UE 3-1 (which may be an intermediate UE 3-1c or a first UE 3-1a depending on the type of multi-hop U2N relaying scenario). Accordingly, the last relay UE 3-1b may perform uplink bearer mapping in the same, or a similar, way to that of the U2N relay for a single-hop scenario, which those skilled in the art will be familiar with.

[0177] In respect of the first relay UE 3-1a and / or intermediate relay UE 3-1c (where applicable), the (PC5) SRAP sublayer at that first relay UE 3-1a and / or intermediate relay UE 3-1c perform uplink bearer mapping between the ingress (PC5) relay RLC channels for relaying and egress (PC5) relay RLC channels for relaying.

[0178] For uplink relaying traffic, the different end-to-end (Uu) radio bearers (e.g., SRBs and / or DRBs) of the same remote UE 3-4 and / or of different remote UEs 3-4 (if applicable) may be multiplexed over the same egress (PC5) relay RLC channel by the first relay UE 3-1a and / or intermediate relay UE 3-1c.

[0179] In respect of the remote UE 3-4, on the other hand, the (PC5) SRAP sublayer at that remote UE 3-4 will add an appropriate UE identifier for identifying that remote UE 3-4 (e.g., a remote UE ID) and a radio bearer identifier for that remote UE 3-4 (e.g., an end-to-end (Uu) radio bearer ID) into each (PC5) SRAP sublayer data packet (e.g., (PC5) SRAP header of an SRAP PDU). The first relay UE 3-1a, intermediate relay UE 3-1c, and last relay UE 3-1b, beneficially maintain (rather than discard) that remote UE identifier, and radio bearer identifier, along with information representing the relaying path until the corresponding data packet is forwarded to (or towards) the RAN node 5. The RAN node 5 may then use the remote UE identifier and / or radio bearer identifier to correlate the received packets with a specific PDCP entity associated with the correct end-to-end (Uu) radio bearer of the remote UE 3-4. Other than this identification information, the first relay UE 3-1a and / or, intermediate relay UE 3-1c, may beneficially each add its own relay UE identifier (and / or any another form of local identifier) into the (PC5) SRAP header before forwarding the traffic or message to the next relay UE 3-1. This can help the next node to determine where that traffic or message has come from.

[0180] < Bearer Mapping (Downlink)> 　　In the context of multi-hop U2N relaying, and bearer mapping for the downlink, the operation of the RAN node 5 is similar to that of a RAN node 5 for a single-hop scenario with the exception that there are plural downstream relay UEs 3-1. Accordingly, the RAN node 5 may perform downlink bearer mapping in the same, or a similar, way to that of the RAN node 5 for a single-hop scenario, which those skilled in the art will be familiar with. Specifically, the RAN node 5 may map end-to-end (Uu) radio bearers (SRBs and / or DRBs) of a remote UE 3-4 into a (Uu) relay RLC channel over the L2 U2N relay UE (Uu) interface with the last relay UE 3-1b. The (Uu) SRAP sublayer supports remote UE identification for downlink traffic. The identity information (radio bearer identifier) for the L2 U2N remote UE end-to-end (Uu) radio bearer and (a local) remote UE identifier may be included into the (Uu) SRAP header by the RAN node 5, in the downlink, for the last relay UE 3-1b to use to map the received packets, transmitted via the L2 U2N remote UE end to end (Uu) radio bearer, to a corresponding (PC5) relay RLC channel of the last relay UE 3-1b.

[0181] In respect of the last relay UE 3-1b, intermediate relay UE 3-1c, and / or first relay UE 3-1a, that remote UE identifier and radio bearer identifier is beneficially maintained by that relay UE 3-1, along with information representing the relaying path, until the corresponding data packet is forwarded to (or towards) the remote UE 3-4. The remote UE 3-4 may then use the remote UE identifier and / or radio bearer identifier to correlate the received packets with a specific PDCP entity associated with the correct end-to-end (Uu) radio bearer of the remote UE 3-4.

[0182] The (PC5) SRAP sublayer entity at the last relay UE 3-1b may perform downlink bearer mapping between an ingress (Uu) relay RLC channel and an egress (PC5) relay RLC channel. The (PC5) SRAP sublayer of the intermediate relay UE 3-1c and first relay UE 3-1a each respectively performs downlink bearer mapping between a corresponding ingress (PC5) relay RLC channel for relaying and an egress (PC5) relay RLC channel for relaying.

[0183] For downlink relaying traffic, the different end-to-end (Uu) radio bearers (SRBs and / or DRBs) of the same remote UE 3-4 and / or of different remote UEs 3-4 may be multiplexed over the same egress (PC5) relay RLC channel by the last relay UE 3-1b, the intermediate relay UE 3-1c, and / or first relay UE 3-1a.

[0184] < Additional Enhancements for Supporting Multi-Hop U2N Relaying> 　　Beneficially, the RAN node 5, relay UEs 3-1, and remote UE 3-4 are mutually configured for implementing one or more techniques / procedures for supporting multi-hop U2N relaying in the communication system 1.

[0185] < First RRC Message Forwarding (Uplink):> 　　Beneficially, for example, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for supporting the forwarding of a first uplink RRC message (e.g., the RRC Setup Request sent at S906 in Fig. 9 or the like) in the context of a multi-hop U2N relaying scenario.

[0186] It will be appreciated that the forwarding of the first uplink RRC message in the context of a multi-hop U2N relaying scenario is not trivial because each relay UE 3-1 may, or may not be, in an RRC connected mode / state.

[0187] Referring to single-hop U2N relaying scenarios (e.g., as illustrated in Figs. 2 and 3), the transmitting part of the SRAP entity of the U2N relay UE 3-1, on the air (e.g. Uu) interface between the U2N relay UE 3-1 and the RAN node 5, can receive SRAP data packets (e.g., SRAP data PDUs) from the receiving part of the SRAP entity on the UE-to-UE interface (e.g., PC5) of the same U2N relay UE 3-1, and can construct corresponding SRAP data PDUs for transmitting to the RAN node 5. When the transmitting part of the SRAP entity on that air interface (e.g., Uu) has received an SRAP data PDU, if that SRAP Data PDU has been received from a (PC5) relay channel having a channel identifier (e.g., 'SL-RLC-ChannelID' or the like) corresponding to a specific channel identity associated with transmission of the first RRC message (e.g. 'SL-RLC0' or the like) can proceed by determining the UE identifier and bearer identifier field. The SRAP entity of the U2N relay UE 3-1 can then construct an SRAP Data PDU, for transmission to the RAN node 5, having an SRAP header with a UE identifier field and bearer identifier field set to the determined values. The SRAP entity of the U2N relay UE 3-1 can then determine an appropriate egress RLC channel (over the air interface (e.g., Uu) with the RAN node 5) and submit the constructed SRAP data PDU to the determined egress RLC channel.

[0188] In this single-hop scenario if the U2N relay UE 3-1 is not in an RRC connected mode / state, then it performs its own (Uu) RRC connection establishment e.g. via an appropriate random-access procedure over the air (e.g. Uu) interface.

[0189] Moreover whilst, for single-hop U2N relaying scenarios (e.g., as illustrated in Figs. 2 and 3), when the U2N relay UE 3-1 is not in an RRC connected mode / state, it can establish an RRC connection with the RAN node 5 before forwarding the first RRC message from the remote UE 3-4, such behaviour (whilst not necessarily precluded) may not be ideal in the context of multi-hop U2N relaying scenarios (e.g., as illustrated in Figs. 4A, 4B to 6). This is because in a multi-hop U2N relaying scenario each additional hop via a relay UE 3-1 that, itself, needs to establish an RRC connection, has the potential to significantly increase latency - both because of the delay associated with each additional RRC connection establishment procedure that needs to be performed, and because the RRC connection establishment procedure for each additional relay UE 3-1a, 3-1c may experience additional delay associated with the additional hops.

[0190] Accordingly, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures that address, at least partially, the potential issues that might otherwise arise with the forwarding of the first uplink RRC message in the context of multi-hop U2N relaying scenarios (e.g., as illustrated in Figs. 4A, 4B to 6). It will be appreciated that whilst these techniques / procedures have been developed for a multi-hop U2N relaying scenario the general principles represented by these techniques / procedures could, potentially, be applied in other relaying scenarios (including single-hop scenarios and scenarios involving non-UE relays) to provide a commensurate benefit.

[0191] For example, as described in more detail later, the communication system 1 may support a technique / procedure involving the immediate forwarding of each first uplink RRC message, by the first relay UE 3-1a, intermediate relay UE 3-1c, and / or last relay UE 3-1b, regardless of the RRC state of that relay UE 3-1a, 3-1c, 3-1b.

[0192] Alternatively (or additionally) as described in more detail later, the communication system 1 may support a technique / procedure that involves the respective storage / buffering of each first uplink RRC message, by the first relay UE 3-1a and / or intermediate relay UE 3-1c, if that first relay UE 3-1a and / or intermediate relay UE 3-1c is not already in an RRC connected mode / state. The first relay UE 3-1a and / or intermediate relay UE 3-1c does not then forward the stored / buffered first uplink RRC message (or messages) unless / until that first relay UE 3-1a and / or intermediate relay UE 3-1c transits from an RRC idle / Inactive mode / state to an RRC connected mode / state. Whilst this approach may involve delays / unsuccessful remote UE connections it has the benefit of simplicity and reduced relay UE complexity.

[0193] Alternatively (or additionally) as described in more detail later, the communication system 1 may support a technique / procedure that involves the forwarding of combined first uplink RRC messages by the first relay UE 3-1a and / or intermediate relay UE 3-1c. Specifically, in this technique / procedure, if the first relay UE 3-1a and / or intermediate relay UE 3-1c is not in an RRC connected mode / state, that first relay UE 3-1a and / or intermediate relay UE 3-1c may combine and encapsulate the first RRC message / messages received from a downstream relay UE 3-1 / remote UE 3-4 together with its own first uplink RRC message into the same SRAP data PDU.

[0194] < First RRC Message Routing (Downlink):> 　　Beneficially, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may additionally (or alternatively) be mutually configured for implementing one or more techniques / procedures for supporting the routing of a first downlink RRC message (e.g., the RRC setup message sent at S908 in Fig. 9 or the like) in the context of a multi-hop U2N relaying scenario.

[0195] It will be appreciated that the routing of the first downlink RRC message in the context of a multi-hop U2N relaying scenario is not trivial because, unlike in single-hop U2N relaying scenarios (e.g., as illustrated in Figs. 2 and 3) in which the U2N relay UE 3-1 may only serve one or more remote UEs 3-4, in multi-hop U2N relaying scenarios (e.g., as illustrated in Figs. 4A, 4B to 6) one or more relay UEs 3-1 in the relaying path (e.g., intermediate relay UE 3-1c and / or last relay UE 3-1b) may serve a plurality of UEs including one or more remote UEs 3-4 and / or one or more other relay UEs 3-1. Accordingly, simply relying on a remote UE identifier associated with a specific egress (PC5) relay RLC channel to route the first downlink RRC message from such a relay may not be sufficient because, where there is a choice of different downstream relay paths to follow, the relay UE 3-1 may not be able to resolve which path should be used to route the first downlink RRC message.

[0196] Fig. 10, for example, illustrates how routing of a first downlink RRC message might be implemented in a single-hop UE-to-network relaying scenario in the communication system 1. In the illustrated example a single U2N relay UE 3-1 (relay UE #1 in this example) relays uplink communication from a plurality of remote UEs 3-4a, 3-4b to a RAN node 5 and relays downlink communication from the RAN node 5 to the correct remote UE 3-4a, 3-4b of the plurality of remote UEs 3-4a, 3-4b.

[0197] As explained above, when the first uplink RRC message (e.g., RRC setup request sent at S906 in Fig. 9 or the like) is received from one of the remote UEs 3-4a, 3-4b at a RAN node 5, that RAN node 5 responds by transmitting an appropriate first downlink RRC message (e.g., RRC setup sent at S908 in Fig. 9 or the like) to the remote UE 3-4a, 3-4b which sent the first uplink RRC message - this first downlink RRC message is routed via the U2N relay UE 3-1. Specifically, first downlink RRC message is sent to the correct remote UE 3-4a, 3-4b, using SRB (e.g., SRB0) relaying over an appropriate (Uu) relay RLC channel and over an appropriate (PC5) relay RLC channel (e.g., (PC5) RLC relay channel #1 for remote UE 3-4a (remote UE #1), or (PC5) RLC relay channel #2 for remote UE 3-4b (remote UE #2)).

[0198] At the RAN node 5, downlink routing of the first downlink RRC message is based on information (e.g., derived from an entry in a routing table, or the like) indicating the identity of the remote UE 3-4 (e.g., a remote UE ID) in association with information (e.g., derived from an entry in a routing table, or the like) indicating a specific relay UE 3-1, from which the first uplink RRC message was received, as the relay path. It will be appreciated that whilst, in this example, there is only one relay UE 3-1 (relay UE #1) and by extension a single relay path that may be indicated, in a real communication system the RAN node 5 may serve a plurality of similar relay UEs 3-1, each relay UE 3-1 respectively serving one or more respective remote UEs 3-4, and hence plural possible relay paths.

[0199] At the U2N relay UE 3-1, downlink routing of a first downlink RRC message received from the RAN node 5 is based on information (e.g., derived from an entry in a routing table, or the like) indicating the identity of the remote UE 3-4 (e.g., a remote UE ID) in association with information (e.g., derived from an entry in a routing table, or the like) indicating the egress (PC5) relay channel via which the identified remote UE 3-4a, 3-4b may be reached (e.g., the egress (PC5) relay channel corresponding to the ingress (PC5) relay channel from which the first uplink RRC message that is being responded to was received).

[0200] It can be seen, therefore, that in the routing mechanism for the single-hop scenario routing from the relay UE 3-1 can be achieved based simply on the target destination of the first downlink RRC message (e.g., the remote UE identifier).

[0201] Contrastingly, in multi-hop scenarios, whilst the first relay UE 3-1a and intermediate relay UE 3-1c each have only one upstream (parent) relay UE 3-1 (and so can simply forward a first UL RRC message of a remote UE 3-4 to that its upstream (parent) relay UE 3-1 via the corresponding egress (PC5) RLC channel in the UL), the situation in the downlink is more complex. Specifically, in the downlink direction, the last relay UE 3-1b and any intermediate relay UEs 3-1c may serve a plurality of UEs 3 of different types (e.g., one or more remote UEs 3-4, one or more (other) intermediate relay UEs 3-1c, and / or one or more first relay UEs 3-1a). The routing mechanism for the single-hop scenario routing from the relay UE 3-1 may not, therefore, be sufficient for more complex multi-hop scenarios.

[0202] Accordingly, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for routing DL packets (e.g., first DL RRC message) for a given remote UE 3-4 sent from a last relay UE 3-4b and / or the intermediate relay UE 3-1c in which the egress (PC5) link (i.e., as represented by the downstream node that will, ultimately, lead to the remote UE 3-4 for which a downlink packet is destined) is first determined, and then the (PC5) RLC channel for downlink forwarding is then determined.

[0203] < System Information Acquisition:> 　　Beneficially, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may additionally (or alternatively) be mutually configured for implementing one or more techniques / procedures for supporting the acquisition of system information at the remote UE 3-4 in the context of a multi-hop U2N relaying scenario.

[0204] It will be appreciated that the acquisition of system information at the remote UE 3-4 in the context of a multi-hop U2N relaying scenario is not trivial because, unlike single-hop U2N relaying scenarios (e.g., as illustrated in Figs. 2 and 3) in which the U2N relay UE 3-1 will be in coverage of the RAN node 5 and can thus acquire system information directly from the RAN node 5, should a remote UE 3-4 request it, the first relay UE 3-1a that receives a request system information from a remote UE 3-4 in multi-hop U2N relaying scenarios (e.g., as illustrated in Figs. 4A, 4B to 6) may not be in-coverage of the RAN node 5.

[0205] Specifically, in a single-hop scenario, the remote UE 3-4 in an RRC connected mode / state can use the conventional on-demand SIB framework (that will be familiar to those skilled in the art) to request one or more SIBs via the U2N relay UE 3-1. The U2N relay UE 3-1 can then trigger its own on-demand SI / SIB acquisition procedure according to its own RRC state (if needed) to acquire the requested SI / SIB / SIBs and send the acquired SI / SIB / SIBs to the remote UE 3-4 that requested it via an appropriate UE-to-UE (PC5) RRC message or the like. The remote UE 3-4 in an RRC idle / inactive mode / state, on the other hand, may use a remote UE information provision procedure to acquire system information.

[0206] Fig. 11 is a simplified sequence diagram of a system information acquisition procedure between the UE 3 and the RAN node 5 in the context of a single-hop UE-to-network relaying scenario that may be implemented in the communication system 1.

[0207] In the example of Fig. 11, the remote UE 3-4 is configured for indirect communication, via the (U2N) relay UE 3-1, with the RAN node 5 using single-hop UE-to-network relaying.

[0208] In the example of Fig. 11, when the remote UE 3-4 requires system information, the remote UE 3-4 may request system information (e.g., one or more on-demand SIBs) from the RAN node 5 via the relay UE 3-1.

[0209] Specifically, at step S1102, the remote UE 3-4 may request the required system information (e.g., one or more on-demand SIBs) from a RAN node 5 via the relay UE 3-1 by sending, to the relay UE 3-1, a system information request in an appropriate UE-to-UE (e.g., PC5 / sidelink) message (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) over the direct UE-to-UE interface (e.g., PC5) between the remote UE 3-4 and the relay UE 3-1. Upon receipt of the system information request, the relay UE 3-1 may trigger an on-demand system information SI / SIB acquisition procedure with the RAN node 5 according to the current RRC mode / state of the relay UE 3-1.

[0210] Specifically, upon receiving the system information request at step S1102, the relay UE 3-1, at step S1104, sends to the RAN node 5, an appropriate system information request message (e.g., an on-demand SIB request message, or the like) over the air interface (e.g., Uu) between the relay UE 3-1 and the RAN node 5 to request the RAN node 5 to perform on-demand SIB transmissions to the relay UE 3-1.

[0211] At step S1106, the RAN node 5, having received the system information request message (e.g., the on-demand SIB request message, or the like) from the relay UE 3-1, triggers the requested on-demand system information (SIB) transmissions / broadcasts to provide the relay UE 3-1 with the requested system information.

[0212] On receipt of the system information transmitted / broadcast from the RAN node 5, the relay UE 3-1 forwards that system information to the remote UE 3-4 at step S1108 using an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like).

[0213] Contrastingly, in multi-hop scenarios, the first relay UE 3-1a to which any on-demand SIB request would be sent cannot, itself, request on-demand SIB transmission / broadcast from the RAN node 5 as it does not have a direct connection to the RAN node 5 and because, if it is not in-coverage of the RAN node 5, cannot receive an on-demand SIB transmission / broadcast from the RAN node 5.

[0214] Accordingly, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for the acquisition of system information at the remote UE 3-4, in the context of a multi-hop U2N relaying scenario, in which: a system information request from a remote UE 3-4 can be forwarded from the first relay UE 3-1a, via any intermediate relay UE 3-1c, to the last relay UE 3-1b (which can then request the RAN node 5 provides the required system information); and requested system information from a RAN node 5 can be forwarded from the last relay UE 3-1b, via any intermediate relay UE 3-1c, to the first relay UE 3-1a (and hence to the remote UE 3-4).

[0215] < Paging Notification Handling:> 　　Beneficially, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may additionally (or alternatively) be mutually configured for implementing one or more techniques / procedures for supporting the handling of paging notifications for the remote UE 3-4 in the context of a multi-hop U2N relaying scenario.

[0216] It will be appreciated that the handling of paging notifications for the remote UE 3-4, in the context of a multi-hop U2N relaying scenario, is not trivial. For example, unlike single-hop U2N relaying scenarios (e.g., as illustrated in Figs. 2 and 3) in which the U2N relay UE 3-1 will be in coverage of the RAN node 5 and can thus transfer the necessary paging information received from each connected remote UE 3-4 directly to the RAN node 5, the first relay UE 3-1a that receives the paging information from a remote UE 3-4 in multi-hop U2N relaying scenarios (e.g., as illustrated in Figs. 4A, 4B to 6) may not be in-coverage of the RAN node 5. Similarly, unlike single-hop U2N relaying scenarios in which the U2N relay UE 3-1 can transfer paging notifications received from the RAN node 5 directly to the correct destination remote UE 3-4, the last relay UE 3-1b that receives paging notifications from the RAN node 5 in multi-hop U2N relaying scenarios cannot transfer them directly to the correct destination remote UE 3-4.

[0217] For example, in a single-hop scenario, the remote UE 3-4 and the relay UE 3-1 can follow a similar procedure to that illustrated in Fig. 11 for the acquisition of system information for the reception of paging information from the remote UE 3-4 and for the provision of paging notifications to the remote UE 3-4.

[0218] Fig. 12 is a simplified sequence diagram of a procedure for handling paging notifications in the context of a single-hop UE-to-network relaying scenario that may occur in the communication system 1.

[0219] In the example of Fig. 12 the remote UE 3-4 is configured for indirect communication, via the (U2N) relay UE 3-1, with the RAN node 5 using single-hop UE-to-network relaying.

[0220] In the example of Fig. 12, at step S1202, the remote UE 3-4 may transfer paging information to the relay UE 3-1 by sending, to the relay UE 3-1, that paging information in an appropriate UE-to-UE (e.g., PC5 / sidelink) message (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) over the direct UE-to-UE interface (e.g., PC5) between the remote UE 3-4 and the relay UE 3-1. The paging information may, for example, include one or more remote UE identifiers for the purposes of monitoring for paging (e.g., a serving temporary mobile subscriber identity (S-TMSI), an inactive radio network temporary identifier (I-RNTI), and / or the like).

[0221] When the relay UE 3-1 is in an RRC connected mode / state, upon receipt of the paging information, the relay UE 3-1 may notify, at S1204, the paging information received from the remote UE 3-4 (e.g., the remote UE ID for paging monitoring / 5G-S-TMSI / I-RNTI), to the RAN node 5, via an appropriate message (e.g., 'SidelinkUEInformationNR' or the like) over the air interface (e.g., Uu) between the RAN node 5 and the relay UE 3-1. When the RAN node 5, having received the paging information from the relay UE 3-1, needs to page the remote UE 3-4, the RAN node 5 can therefore send the paging notification to the relay UE 3-1 over the air interface (e.g., Uu) between the RAN node 5 and the relay UE 3-1, at S1206. The paging notification for the remote UE 3-4 may, for example, be sent via a dedicated (RRC) message from the RAN node 5 to the relay UE 3-1 if the relay UE 3-1 is in an RRC connected mode / state.

[0222] It will be appreciated that if the relay UE 3-1 is in an RRC idle / inactive mode / state, then the relay UE 3-1 may monitor paging occasions for each connected remote UE 3-4 (if the active downlink bandwidth part (BWP) of the last relay UE 3-1b is configured with a common search space that includes the appropriate paging search space).

[0223] On receipt of the paging notification for the remote UE 3-4, the relay UE 3-1 forwards that paging notification to the remote UE 3-4 at step S1208 using an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like).

[0224] Contrastingly, in multi-hop scenarios, the first relay UE 3-1a to which any on-demand SIB request would be sent cannot, itself, receive paging notifications from the RAN node 5 as it does not have a direct connection to the RAN node 5 and because, if it is not in-coverage of the RAN node 5, cannot receive paging notifications from the RAN node 5.

[0225] Accordingly, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for the handling of paging notifications for the remote UE 3-4, in the context of a multi-hop U2N relaying scenario, in which: paging information from the remote UE 3-4 can be forwarded from the first relay UE 3-1a, via any intermediate relay UE 3-1c, to the last relay UE 3-1b (which can then provide the RAN node 5 with the paging information); and paging notifications from a RAN node 5 can be forwarded from the last relay UE 3-1b, via any intermediate relay UE 3-1c, to the first relay UE 3-1a (and hence the remote UE 3-4).

[0226] It will be appreciated that whilst a number of different techniques / procedures are for supporting multi-hop U2N relaying in the communication system 1 are introduced above, the methods are neither mutually exclusive, nor mutually reliant on one another. For example, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be configured to support all, or a subset of one or more of the techniques / procedures, to achieve a commensurate benefit.

[0227] < First RRC Message Forwarding (Uplink)> 　　As mentioned above, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for supporting the forwarding of a first uplink RRC message (e.g., the RRC Setup Request sent at S906 in Fig. 9 or the like) in the context of a multi-hop U2N relaying scenario. Examples of a number of such techniques / procedures will now be described in more detail, by way of example only.

[0228] < Immediate First Uplink RRC Message Forwarding:> 　　For example, as mentioned above, the communication system 1 may support a technique / procedure involving the immediate forwarding of each first uplink RRC message, by the first relay UE 3-1a and / or intermediate relay UE 3-1c, regardless of the RRC state of the relay UE 3-1a, 3-1c.

[0229] Specifically, in this example, the first relay UE 3-1a and / or intermediate relay UE 3-1c is configured to forward, regardless of that relay UE's RRC state, the first uplink RRC message (e.g., RRC setup request) received from a downstream node (e.g., the remote UE 3-4 or the first relay UE 3-1a) to the corresponding parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c) via a determined egress RLC channel (e.g. a specific (PC5) RLC channel such as 'SL-RLC0' or the like). For example, the first relay UE 3-1a and / or intermediate relay UE 3-1c may be configured to forward, regardless of that relay UE's RRC state, an SRAP Data PDU received on an ingress (PC5) RLC relay channel that corresponds to a specific logical channel identifier for a (PC5) RLC relay channel that is associated with transmission of the first uplink RRC message (e.g., the (PC5) RLC channel identified as SL-RLC0).

[0230] In this example, if the recipient relay UE 3-1a, 3-1c is not in RRC Connected state, that relay UE 3-1a, 3-1c will initially forward the first uplink RRC message received (e.g., from the (PC5) RLC relay channel identified as 'SL-RLC0') - e.g., within an SRAP Data PDU - to its parent relay UE (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c). Once that first uplink RRC message has been forwarded, the first relay UE 3-1a and / or intermediate relay UE 3-1c may (if needed) send another SRAP data PDU to the corresponding parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c), with its own first uplink RRC message (e.g. RRC Setup Request) encapsulated. It will be appreciated that this other SRAP data PDU may be sent over the same specific (PC5) RLC relay channel (e.g. SL-RLC0) used for forwarding the earlier first RRC message, or over a different specific (PC5) RLC channel (e.g. SL-RLCx).

[0231] It can be seen, therefore, that in this example the delays associated with the first part of procedure of Fig. 9 (e.g., sending the first uplink RRC message), for example the delays at each of the relay UE's downstream nodes), can be significantly reduced compared to a procedure in which each relay UE 3-1 that is not in an RRC connected mode / state has to transition to an RRC connected mode / state before the first uplink RRC message received from a downstream node can be forwarded.

[0232] < First Uplink RRC Message Buffering:> 　　As mentioned above, the communication system 1 may support a technique / procedure involving the respective storage / buffering of each first uplink RRC message, by the first relay UE 3-1a and / or intermediate relay UE 3-1c, if the first relay UE 3-1a and / or intermediate relay UE 3-1c is not already in an RRC connected mode / state.

[0233] Specifically, in this example, the first relay UE 3-1a and / or intermediate relay UE 3-1c is configured to only forward the first uplink RRC message (e.g., RRC setup request) received from a downstream node (e.g., the remote UE 3-4 or the first relay UE 3-1a) to the corresponding parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c) via a determined egress RLC channel (e.g. a specific (PC5) RLC channel such as 'SL-RLC0' or the like) if the first relay UE 3-1a and / or intermediate relay UE 3-1c is in an RRC connected mode / state. For example, the first relay UE 3-1a and / or intermediate relay UE 3-1c may be configured to forward, if the relay UE 3-1a / 3-1c is in an RRC connected state, an SRAP Data PDU received on an ingress (PC5) RLC relay channel that corresponds to a specific logical channel identifier for a (PC5) RLC relay channel that is associated with transmission of the first uplink RRC message (e.g., the (PC5) RLC channel identified as SL-RLC0).

[0234] In this example, if the recipient relay UE 3-1a, 3-1c is not in RRC connected state, the relay UE 3-1a, 3-1c will store / buffer any received first uplink RRC message / messages (e.g., from the (PC5) RLC relay channel identified as 'SL-RLC0'). It will be appreciated that any received first uplink RRC message / messages may be received from the remote UE 3-4 or the relay UE 3-1 (e.g., relay UE 3-1a).

[0235] If the recipient relay UE 3-1a, 3-1c that has stored / buffered one or more first uplink RRC messages transitions from an RRC idle / inactive mode / state to an RRC connected mode / state, that relay UE 3-1a, 3-1c will then transmit the buffered first uplink RRC message / messages received from that (PC5) RLC relay channel (e.g. SL-RLC0) to its parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c) via a determined egress RLC channel (e.g. a specific (PC5) RLC channel such as SL-RLC0 or the like).

[0236] The first relay UE 3-1a and intermediate relay UE 3-1c may each be configured with an appropriate timer (e.g., a validity timer or the like) that is used to determine when any buffered first uplink RRC message / messages may be removed. The first relay UE 3-1a and / or intermediate relay UE 3-1c may, for example, remove the buffered first uplink RRC message / messages when the configured timer expires (e.g., because RRC connection establishment for that relay UE 3-1a, 3-1c has failed).

[0237] It will be appreciated that whilst this approach may involve delays / unsuccessful remote UE connections, it has the benefit of simplicity and reduced relay UE complexity.

[0238] < Combined First Uplink RRC Message Forwarding:> 　　As mentioned above, the communication system 1 may support a technique / procedure involving the forwarding of combined first uplink RRC messages a by the first relay UE 3-1a and / or intermediate relay UE 3-1c.

[0239] Specifically, in this example, the first relay UE 3-1a and / or intermediate relay UE 3-1c is configured such that when that relay UE 3-1a, 3-1c it is not in an RRC connected mode / state, that relay UE 3-1a, 3-1c may effectively combine each first RRC message (e.g. RRC setup request) received from its downstream node (e.g., the remote UE 3-4 or the first relay UE 3-1a), with that relay UE's own first uplink RRC message (e.g. RRC setup request), by encapsulating those first RRC messages in the same SRAP data PDU. For example, the first relay UE 3-1a and / or intermediate relay UE 3-1c may be configured to combine and encapsulate an SRAP Data PDU received on an ingress (PC5) RLC relay channel that corresponds to a specific logical channel identifier for a (PC5) RLC relay channel that is associated with transmission of the first uplink RRC message (e.g., the (PC5) RLC channel identified as SL-RLC0) with that relay UE's own first uplink RRC message in a new 'combined' SRAP data PDU.

[0240] The relay UE 3-1a, 3-1c performing the combining / encapsulation may then transmit the 'combined' SRAP data PDU that encapsulates the combined first RRC uplink messages to its parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c) via a determined egress RLC channel (e.g. a specific (PC5) RLC channel such as SL-RLC0 or the like).

[0241] It will be appreciated that the 'combined' SRAP data PDU may be formed of a plurality of SRAP data (sub-)PDUs, each (sub-)PDU having a respective SRAP (sub-)header, indicating a corresponding RRC message within that SRAP data (sub-)PDU. Each SRAP (sub-)header may, for example, be configured to respectively indicate which UE 3 the corresponding RRC message belongs to. The SRAP data (sub-)PDU may, for example include: at least one UE identifier (which may comprise a remote UE identifier and / or one or more relay UE identifiers); and optionally the bearer identity for the SRB (e.g. the bearer identity of SRB0).

[0242] < Common Considerations for First Uplink RRC Message Forwarding:> 　　It will be appreciated that for any of the first uplink RRC message forwarding techniques / procedures described above, for the second hop and following hops, a specified (PC5) relay RLC channel configuration may be defined between a given relay UE (first relay UE 3-1a / intermediate relay UE 3-1c) and its parent relay UE 3-1 (e.g., the last relay UE 3-1b or intermediate relay UE 3-1c) for the purpose of the first uplink RRC message forwarding for multi-hop U2N relaying.

[0243] It will be appreciated that for any of the first uplink RRC message forwarding techniques / procedures described above, for each first RRC message (e.g. RRC setup request) to be respectively forwarded to the RAN node 5, when that first RRC message is encapsulated into the SRAP data PDU, a source UE identifier (which may be a remote UE identifier or a relay UE identifier as appropriate) may be included. This source UE identifier may be maintained when the SRAP data PDU is decapsulated / resolved at the next hop. This source UE identifier may thus be used by the RAN node 5 to derive where each received first RRC message has originated from and hence to decide the destination of the corresponding response message - for example the first downlink RRC message (e.g., RRC Setup message) sent at S908 in Fig. 9. For example, if the first relay UE 3-1a initiates transmission of an RRC setup request message encapsulated in an SRAP data PDU (carrying a first relay UE identifier as the source identifier) is sent to the intermediate relay UE 3-1c, when intermediate relay UE 3-1c resolves that SRAP data PDU, it keeps that first relay UE identifier as the source identifier when it forwards that RRC setup request message to the last relay UE 3-1b (in a newly generated SRAP data PDU).

[0244] It will be appreciated that, from the receiver perspective, as the first relay UE 3-1a and the intermediate relay UE 3-1c may or may not each respectively transmit its own first RRC message, a given SRAP data PDU received from the specified (PC5) relay RLC channel (e.g. SL-RLC0 or the like from a first relay UE 3-1a, or from an intermediate relay UE) may include a single first RRC message or a plurality of first RRC messages from the downstream nodes (e.g., from the remote UE 3-4, and / or relay UEs 3-1a, 3-1c).

[0245] < First RRC Message Routing (Downlink)> 　　As mentioned above, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for routing DL packets (e.g., first DL RRC message) for a given remote UE 3-4 sent from a last relay UE 3-4b and / or the intermediate relay UE 3-1c in which the egress (PC5) link (i.e., as represented by the downstream node that will, ultimately, lead to the remote UE 3-4 for which a downlink packet is destined) is first determined, and then the (PC5) RLC channel for downlink forwarding is then determined.

[0246] An example of such a technique / procedure will now be described in more detail, by way of example only with reference to Fig. 13.

[0247] Fig. 13 is a simplified illustration of how routing of a first downlink RRC message might be implemented in a multi-hop UE-to-network relaying scenario that may occur in the communication system 1. In the illustrated example a last relay UE 3-1b (relay UE #1 in this example) is configured to relay downlink communication from a RAN node 5 to an intermediate relay UE 3-1c (relay UE #2 in this example) and to a remote UE 3-4c (remote UE #3 in this example) as needed. The intermediate relay UE 3-1c (relay UE #2 in this example) is configured to relay downlink communication received from the last relay UE 3-1b (relay UE #1) to a first relay UE 3-1a (relay UE #3 in this example). The first relay UE 3-1a (relay UE #3) is configured to relay downlink communication received from the intermediate relay UE 3-1c (relay UE #2) to a plurality of remote UEs 3-4a and 3-4b as needed.

[0248] As explained above, when the first uplink RRC message (e.g., RRC setup request sent at S906 in Fig. 9 or the like) is received from one of the remote UEs 3-4a, 3-4b, 3-4c at a RAN node 5, that RAN node 5 responds by transmitting an appropriate first downlink RRC message (e.g., RRC setup sent at S908 in Fig. 9 or the like) addressed to the remote UE 3-4a, 3-4b, 3-4c which sent the first uplink RRC message - this first downlink RRC message is routed to the last relay UE 3-1b (relay UE #1).

[0249] Specifically, at the RAN node 5, downlink routing of the first downlink RRC message is based on information (e.g., derived from an entry in a routing table, or the like) indicating the identity of the destination remote UE3-4a, 3-4b, 3-4c (e.g., a remote UE ID) in association with information (e.g., derived from an entry in a routing table, or the like) indicating a specific relay UE, from which the first uplink RRC message was received, as the relay path. It will be appreciated that whilst, in this example, there is only one last relay UE 3-1b (relay UE #1) and by extension a single relay path that may be indicated, in a real communication system, the RAN node 5 may serve a plurality of similar last relay UEs 3-1b, each last relay UE 3-1b respectively serving one or more respective remote UEs 3-4, and hence plural possible relay paths.

[0250] For the purpose of first downlink RRC message forwarding, the relay UEs 3-1 (first relay UE 3-1a, intermediate relay UE 3-1c, and / or last relay UE 3-1b), each generate an appropriate routing table for hosting the routing information necessary for routing the first downlink RRC message. Each routing table may, for example, be generated by the corresponding relay UE 3-1a, 3-1c, 3-1b and populated appropriately based on information obtained by that relay UE 3-1a, 3-1c, 3-1b when corresponding first uplink RRC messages (e.g., to which first downlink RRC messages may be sent as a response) are received.

[0251] The routing of a given first downlink RRC message at each relay UE 3-1a, 3-1c, 3-1b may be based on the corresponding entry in the respective routing table generated by that relay UE 3-1a, 3-1c, 3-1b based on reception of the first uplink RRC message to which the first downlink RRC message that is being routed as a response.

[0252] For a relay UE 3-1 (such as the first relay UE 3-1a in the illustrated example) that serves only remote UEs 3-4, the routing table may include entries based on the identity of a remote UE 3-4 (e.g., a remote UE ID) in association with information indicating the egress (PC5) relay channel via which the identified remote UE 3-4 may be reached (e.g., the egress (PC5) relay channel corresponding to the ingress (PC5) relay channel from which a first uplink RRC message from that remote UE 3-4 was received).

[0253] For a relay UE 3-1 (such as the last relay UE 3-1b in the illustrated example) that serves at least one downstream relay UE 3-1, the routing table may include entries based on the identity of a remote UE 3-4 (e.g., a remote UE ID) in association with information indicating the relay path via which the identified remote UE 3-4 may be reached, and possibly information indicating the egress (PC5) relay channel via which the identified remote UE 3-4 may be reached (if needed). The information indicating the relay path via which the identified remote UE 3-4 may be reached may, for example, be in the form of information identifying the next downstream node in the relay path to the identified remote UE 3-4. It will be appreciated that the identified downstream node may be another relay UE 3-1 (where the path to the identified remote UE 3-4 is indirect via that relay UE 3-1) or may be the identified remote UE 3-4 itself (where the path to the identified remote UE 3-4 is direct - e.g., as seen between remote UE 3-4c (remote UE #3) and the last relay UE 3-1b (relay UE #1) in Fig. 13). For example, as seen in Fig. 13, if the intermediate relay UE 3-1c (e.g. relay UE #2 in the illustrated example) receives an SRAP Data PDU from the first relay UE (e.g. relay UE #1 in the illustrated example) carrying a first uplink RRC message for a given remote UE (e.g., remote UE #1 in Fig. 13), then the intermediate relay UE 3-1c (e.g. relay UE #2 in the illustrated example) generates an appropriate routing entry (e.g. remote UE #1 ID, relay UE #3) in its routing table. When the intermediate relay UE 3-1c receives the first downlink RRC message from the last relay UE 3-1b (e.g. relay UE #1 in the illustrated example), the intermediate relay UE 3-1c can thus forward the downlink message to the first relay UE 3-1a (e.g. relay UE #3 in the illustrated example) according to the routing entry generated e.g. (e.g. remote UE #1 ID, relay UE #3).

[0254] < System Information Acquisition> 　　As mentioned above, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for the acquisition of system information at the remote UE 3-4, in the context of a multi-hop U2N relaying scenario, in which: a system information request from the remote UE 3-4 can be forwarded from the first relay UE 3-1a, via any intermediate relay UE 3-1c, to the last relay UE 3-1b (which can then request the RAN node 5 provides the required system information); and requested system information from the RAN node 5 can be forwarded from the last relay UE 3-1b, via any intermediate relay UE 3-1c, to the first relay UE 3-1a (and hence to the remote UE 3-4).

[0255] An example of such a technique / procedure will now be described in more detail, by way of example only, with reference to Fig. 14.

[0256] < System Information Request and Transfer Procedure> 　　Fig. 14 is a simplified sequence diagram of a system information acquisition procedure between the UE 3 and the RAN node 5 in the context of a multi-hop UE-to-network relaying scenario that may be implemented in the communication system 1.

[0257] In the illustrated example the remote UE 3-4 is configured for indirect communication with the RAN node 5, via the first relay UE 3-1a, the intermediate relay UE 3-1c, and the last relay UE 3-1b, using multi-hop U2N relaying.

[0258] In the example of Fig. 14, when the remote UE 3-4 requires system information, the remote UE 3-4 may request system information (e.g., one or more SIBs) from the RAN node 5 via the first relay UE 3-1a.

[0259] Specifically, like the single-hop relaying procedure described with reference to Fig. 11, in this example for multi-hop sidelink relaying, a system information request in an appropriate UE-to-UE (e.g., PC5 / sidelink) message (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) is used to request one or more SIBs. However, in this example, the message carrying system information request is transmitted from the remote UE 3-4 to the first relay UE 3-1a (at step S1402), from first relay UE 3-1a to the intermediate relay UE 3-1c (at step S1404), and from intermediate relay UE 3-1c to the last relay UE 3-1b (at step S1406). It will be appreciated that, in this example, the forwarding is not based on SRAP protocol.

[0260] Whilst the message used to provide the system information request at step S1402 (and forwarded at S1404 and S1406) is similar to that sent at S1102 in Fig. 11, the message sent at step S1402 (and forwarded at S1404 and S1406) may include an additional information element (e.g., an identifier of the last relay UE 3-1b) to indicate the final destination of this message. Such a destination identifier is not used for single-hop relaying because the relay UE 3-1 that receives the system information request in a single-hop scenario is the relay UE 3-1 that terminates this message.

[0261] When the first relay UE 3-1a or the intermediate relay UE 3-1c receives the message carrying the system information request, that first relay UE 3-1a or the intermediate relay UE 3-1c checks the new information element indicating destination of the message, and will forward the message carrying the system information request to the corresponding parent relay UE 3-1 (i.e., the intermediate relay UE 3-1c or last relay UE 3-1b following the next hop), unless the relay UE 3-1 that received the message carrying the system information request is the destination identified in that message. The last relay UE 3-1b will not forward the message anymore since it is the destination of the message.

[0262] It will be appreciated that the intermediate relay UE 3-1c (and possibly other relay UEs 3-1) may derive appropriate routing information for the remote UE 3-4, from the message carrying the system information request, and may generate (or update) a routing table stored at the intermediate relay UE 3-1c (and possibly other relay UEs 3-1) for facilitating SIB forwarding (as described later).

[0263] It will also be appreciated that an alternative way for SIB request handling would be for the first relay UE 3-1a and the intermediate relay UE 3-1c to be configured automatically forward the (PC5) RRC (remote information) message carrying the system information request from remote UE 3-4 to the corresponding parent relay UE 3-1 (intermediate relay UE 3-1c or last relay UE 3-1b), in which case the destination relay UE identifier need not be added to the transfer message.

[0264] Upon receipt of the message carrying the system information request, the last relay UE 3-1b may trigger an on-demand system information SI / SIB acquisition procedure directly with the RAN node 5 according to the current RRC mode / state of the last relay UE 3-1b. Specifically, upon receiving the message carrying the system information request (e.g., at step S1406), the last relay UE 3-1b (or other relay UE identified as the destination relay UE 3-1), may send (e.g., at step S1408) to the RAN node 5, an appropriate SI request message (e.g., an on-demand SIB request message, or the like) over the air interface (e.g., Uu) between the last relay UE 3-1b and the RAN node 5 to request the RAN node 5 to perform on-demand SIB transmissions to the last relay UE 3-1b.

[0265] At step S1410, the RAN node 5, having received the SI request message (e.g., an on-demand SIB request message, or the like) from the relay UE 3-1, triggers the requested on-demand SIB transmissions / broadcasts to provide the last relay UE 3-1b with the requested system information.

[0266] On receipt of the system information transmitted / broadcast from the RAN node 5, the last relay UE 3-1b forwards that system information to the next downstream node (e.g., intermediate relay UE 3-1c) in the relaying path to the remote UE 3-4 (e.g., as indicated at step S1412) using an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like). This transfer message may then be forwarded, as needed, from the intermediate relay UE 3-1c to the first relay UE 3-1a (as indicated at step S1414), and from the first relay UE 3-1a to the remote UE 3-4 (as indicated at step S1416).

[0267] Whilst the transfer message used to provide the system information at step S1412 (and forwarded at steps S1414 and S1416) is similar to that sent at S1108 in Fig. 11, the transfer message sent at step S1412 (and forwarded at steps S1414 and S1416) may include an additional information element (e.g., an identifier of the remote UE 3-4) to indicate the final destination of this message (for the case of SIB transfer).

[0268] When the intermediate relay UE 3-1c or the first relay UE 3-1a receives the transfer message (e.g., a UuMessageTransferSidelink message, or the like), the intermediate relay UE 3-1c or the first relay UE 3-1a checks the new information element indicating destination of the message, and will forward the message carrying the system information to the corresponding downstream node (i.e., the first relay UE 3-1a or remote UE 3-4). The remote UE 3-4 will not forward the message anymore since it is the destination of the message. This system information forwarding by the intermediate relay UE 3-1c (and possibly by other relay UEs 3-1) may be routed based on one or more routing tables stored at the intermediate relay UE 3-1c (and possibly by other relay UEs 3-1) as described above.

[0269] It will be appreciated that the description of the SIB request and SIB transfer above is generally applicable for requesting all types of SIBs (including SIB1).

[0270] It will also be appreciated that the procedure for system information (SIB) transfer is also applicable to system information (SIB) updates, in which case the last relay UE 3-1b can send the updated SIB / SIBs (e.g., for and SIB previously requested by the remote UE 3-4) to the remote UE 3-4.

[0271] For a particular remote UE 3-4, for any relay UE 3-1 (for example, intermediate relay UE 3-1c) in the relaying path, if that relay UE 3-1 receives an updated SIB, the relay UE 3-1 may send that updated SIB, via SIB forwarding (e.g., as described with reference to Fig. 14, steps S1412, S1414, and S1416), to the remote UE 3-4 based on a record of one or more system information requests made by the remote UE 3-4.

[0272] < System Information Storage at the Relay UE> 　　It will be appreciated that as an alternative to (or in addition to) the system information acquisition procedure described with reference to Fig. 14, the communication system 1 may support another technique / procedure for the handling of system information acquisition (e.g., SIB requests from the remote UE 3-4 and SIB transfer from the RAN node 5) in which one or more relay UEs 3-1 (e.g., first relay UE 3-1a, second (intermediate) relay UE 3-1c, and / or last relay UE 3-1b) in the relaying path that may (temporally) store a valid version of one or more SIBs (e.g., all SIBs, or a subset of one or more SIBs) that may be requested by the remote UE 3-4.

[0273] In this example, a relay UE 3-1 (e.g., first relay UE 3-1a, second relay UE 3-1c, and / or last relay UE 3-1b) that stores the system information (e.g., one or more SIBs) may be configured to send any available system information to a remote UE 3-4 on receipt of a system information request (e.g., in a remote information message or the like) from the remote UE 3-4. If the relay UE 3-1 is able to send every SIB requested by the remote UE 3-4, the relay UE 3-1 may be configured to simply terminate the system information request from the remote UE 3-4 without forwarding that system information request on to any parent relay UE 3-1 that may be upstream of the relay UE 3-1. If, on the other hand, the relay UE 3-1 is only able to send a subset of the SIBs requested by the remote UE 3-4, the relay UE 3-1 may be configured not to terminate the system information request from the remote UE 3-4 and to forward the message carrying the system information request on to any parent relay UE 3-1 that may be upstream of the relay UE 3-1. Nevertheless, the relay UE 3-1 may be configured to modify the forwarded message to request only the subset of the SIBs for which the relay UE 3-1 does not have a valid version. Alternatively, the relay UE 3-1 may be configured to forward the message carrying the system information request without modification, and hence the system information request may still indicate a full list of every SIB originally requested by the remote UE 3-4 - this approach can help the upstream parent relay UE 3-1 to maintain a record of each SIB requested by the remote UE 3-4.

[0274] < Routing Mechanism:> 　　It will be appreciated that, for the purposes of forwarding the message carrying the system information request from the remote UE 3-4 to the last relay UE 3-1b, routing is straightforward because, for both the first relay UE 3-1a and the intermediate relay UE 3-1c, there is only a single parent relay UE 3-1 (the intermediate relay UE 3-1c or the last relay UE 3-1b). Hence, the first relay UE 3-1a and the intermediate relay UE 3-1c can simply forward the message carrying the system information request to the appropriate parent relay UE 3-1 (the intermediate relay UE 3-1c or the last relay UE 3-1b).

[0275] However, in downlink direction, the last relay UE 3-1b, the intermediate relay UE 3-1c, and first relay UE 3-1a may each serve one or more UEs (which may include one or more remote UEs 3-4, one or more intermediate relay UEs 3-1c, and / or one or more first relay UEs 3-1a). For example, if the last relay UE 3-1b has a plurality of downstream intermediate relay UEs 3-1c, then when the last relay UE 3-1b needs to forward a requested SIB to a particular remote UE 3-4, the last relay UE 3-1b needs to be able to identify which intermediate relay UE 3-1c will lead to the correct remote UE 3-4.

[0276] To facilitate routing in a downlink direction, therefore, a source remote UE identifier may be incorporated into the message carrying the system information request that is sent from the remote UE 3-4 (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) to the first relay UE 3-1a. The first relay UE 3-1a and the intermediate relay UE 3-1c maintain this information when forwarding the message carrying the system information request to the next relay UE 3-1 in the uplink relaying path (the intermediate relay UE 3-1c or the last relay UE 3-1b) until the message carrying the system information request reaches the last relay UE 3-1b. When the first relay UE 3-1a, the intermediate relay UE 3-1c, or the last relay UE 3-1b receives the message carrying the system information request, the recipient relay UE 3-1 stores (e.g., in a routing table or the like) information representing a mapping relationship between the remote UE identifier and information identifying the next downstream node in the relaying path (e.g. a corresponding relay UE identifier) to the identified remote UE 3-4.

[0277] For example, in the multi-hop scenario of Fig. 13, when the last relay UE 3-1b (relay UE #1 in Fig. 13) receives the message carrying the system information request of one remote UE 3-4a (remote UE #1 in Fig. 13) from the intermediate relay UE 3-1c (relay UE #2 in Fig. 13), the last relay UE 3-1b may generate a routing table entry to record the mapping between the remote UE 3-4a and the last relay UE 3-1b. When the last relay UE 3-1b receives the requested system information (e.g., one or more SIBs), it will send an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like) carrying the requested system information to the intermediate relay UE 3-1c (relay UE #2 in Fig. 13), which can perform further message forwarding.

[0278] It will be appreciated that, alternatively (or additionally), some or all of the routing information required for routing the transfer message carrying the requested system information in the downlink direction (from the last relay UE 3-1b to the remote UE 3-4) may be configured by the RAN node 5, to the last relay UE 3-1b, when the last relay UE 3-1b is in an RRC connected mode / state.

[0279] < Paging Notification Handling> 　　As mentioned above, the RAN node 5, relay UEs 3-1, and remote UE 3-4 may be mutually configured for implementing one or more techniques / procedures for the handling of paging notifications for the remote UE 3-4, in the context of a multi-hop U2N relaying scenario, in which: paging information from the remote UE 3-4 can be forwarded from the first relay UE 3-1a, via any intermediate relay UE 3-1c, to the last relay UE 3-1b (which can then provide the RAN node 5 with the paging information); and paging notifications from the RAN node 5 can be forwarded from the last relay UE 3-1b, via any intermediate relay UE 3-1c, to the first relay UE 3-1a (and hence the remote UE 3-4).

[0280] An example of such a technique / procedure will now be described in more detail, by way of example only, with reference to Fig. 15.

[0281] Fig. 15 is a simplified sequence diagram of a procedure for handling paging notifications in the context of a multi-hop UE-to-network relaying scenario that may be implemented in the communication system 1.

[0282] < Paging Information Transfer:> 　　In the illustrated example a remote UE 3-4 is configured for indirect communication with a RAN node 5, via a first relay UE 3-1a, an intermediate relay UE 3-1c, and a last relay UE 3-1b, using multi-hop U2N relaying.

[0283] In the example of Fig. 15, like the single-hop relaying procedure described with reference to Fig. 12, for multi-hop sidelink relaying, the remote UE 3-4 may transfer paging information to the first relay UE 3-1a by sending, to the first relay UE 3-1a, that paging information in an appropriate UE-to-UE (e.g., PC5 / sidelink) message (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) over the direct UE-to-UE interface (e.g., PC5) between the remote UE 3-4 and the relay UE 3-1. However, in this example, the message carrying paging information is transmitted from the remote UE 3-4 to the first relay UE 3-1a (at step S1502), from first relay UE 3-1a to the intermediate relay UE 3-1c (at step S1504), and from intermediate relay UE 3-1c to the last relay UE 3-1b (at step S1506). It will be appreciated that, in this example, the forwarding is not based on SRAP protocol.

[0284] The provision of the paging information effectively acts as a request for paging occasion monitoring to be performed. When the remote UE 3-4 is in an RRC idle mode / state the paging information may, for example, include one or more remote UE identifiers for the purposes of monitoring for paging (e.g., a serving TMSI (S-TMSI)) and possibly information indicating a UE specific discontinuous reception (DRX) cycle (if configured by an upper layer). When the remote UE 3-4 is in an RRC inactive mode / state the paging information may, for example, include one or more remote UE identifiers for the purposes of monitoring for paging (e.g., an S-TMSI, an I-RNTI, and / or the like) and possibly information indicating the minimum of two different UE specific discontinuous reception (DRX) cycles (if configured respectively by an upper layer and the RAN node 5).

[0285] Whilst the message used to provide the paging information at step S1502 (and forwarded at S1504 and S1506) is similar to that sent at S1202 in Fig. 12, the message sent at step S1502 (and forwarded at S1504 and S1506) may include an additional information element (e.g., an identifier of the last relay UE 3-1b) to indicate the final destination of this message. Such a destination identifier is not used for single-hop relaying because the relay UE 3-1 that receives the paging information in a single-hop scenario is the relay UE 3-1 that terminates the message carrying that paging information.

[0286] When the first relay UE 3-1a or the intermediate relay UE 3-1c receives the message carrying the paging information, that first relay UE 3-1a or the intermediate relay UE 3-1c checks the new information element indicating destination of the message, and will forward the message carrying the paging information to the corresponding parent relay UE 3-1 (i.e., the intermediate relay UE 3-1c or last relay UE 3-1b following the next hop), unless the relay UE 3-1 that received the message carrying the paging information is the destination identified in that message. The last relay UE 3-1b will not forward the message anymore since it is the destination of the message.

[0287] It will be appreciated that the intermediate relay UE 3-1c (and possibly other relay UEs 3-1) may derive appropriate routing information for the remote UE 3-4, from the message carrying the paging information, and may generate (or update) a routing table stored at the intermediate relay UE 3-1c (and possibly other relay UEs 3-1) for facilitating the paging notification forwarding (as described later).

[0288] It will also be appreciated that an alternative way for handling the provision of paging information would be for the first relay UE 3-1a and the intermediate relay UE 3-1c to be configured automatically forward the (PC5) RRC (remote information) message carrying the paging information from remote UE 3-4 to the corresponding parent relay UE (intermediate relay UE 3-1c or last relay UE 3-1b), in which case the destination relay UE identifier need not be added to the transfer message.

[0289] When both the last relay UE 3-1b is in an RRC connected mode / state and the remote UE 3-4 is in an RRC idle / inactive mode / state the last relay UE 3-1b may, following receipt of the paging information (e.g., at step S1506), notify (e.g., at step S1508) the RAN node 5 of the paging information using an appropriate message (e.g., 'SidelinkUEInformationNR' or the like) over the air interface (e.g., Uu) between the RAN node 5 and the last relay UE 3-1b. When the RAN node 5, having received the paging information from the last relay UE 3-1b, needs to page the remote UE 3-4, the RAN node 5 can therefore send the paging notification to last relay UE 3-1b over the air interface (e.g., Uu) between the RAN node 5 and the last relay UE 3-1b, at S1510. The delivery of the paging notification for the remote UE 3-4 may, for example, be achieved be providing the paging notification in a dedicated (RRC) message from the RAN node 5 to the last relay UE 3-1b. The dedicated (RRC) message for delivering the paging notification for the remote UE 3-4 to the (RRC connected) last relay UE 3-1b may contain one or more remote UE IDs (S-TMSI or I-RNTI) - e.g., corresponding to different remote UEs 3-4.

[0290] It will be appreciated that the last relay UE 3-1b (in an RRC connected mode / state) may (alternatively or additionally) simply monitor paging occasions for each connected remote UE 3-4 (if the active downlink bandwidth part (BWP) of the last relay UE 3-1b is configured with a common search space that includes the appropriate paging search space).

[0291] When both the last relay UE 3-1b and the remote UE 3-4 are in an RRC idle / inactive mode / state the last relay UE 3-1b may simply monitor paging occasions of each (directly or non-directly) connected remote UE 3-4. It will be appreciated that when the last relay UE 3-1b needs to monitor paging for a remote UE 3-4, the last relay UE 3-1b will monitor all paging occasions for that remote UE 3-4.

[0292] On receipt of the paging notification from the RAN node 5, the last relay UE 3-1b checks the remote UE identifier / identifiers (e.g., one or more S-TMSIs / I-RNTIs) in the paging record and respectively forwards the paging notification to the next downstream relay UE 3-1 (e.g., intermediate UE 3-1c) in the downlink relaying path for each remote UE 3-4 being paged. The paging notification may be respectively forwarded to the corresponding remote UE 3-4 using an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like). This transfer message may then be forwarded, as needed, from intermediate relay UE 3-1c to the first relay UE 3-1a (as indicated at step S1514), and from first relay UE 3-1a to the remote UE 3-4 (as indicated at step S1516).

[0293] Whilst the transfer message used to provide the paging notification at step S1512 (and forwarded at steps S1514 and S1516) is similar to that sent at S1208 in Fig. 12, the transfer message sent at step S1512 (and forwarded at steps S1514 and S1516) may include an additional information element (e.g., an identifier of the remote UE 3-4) to indicate the final destination of this message (for the case of paging notification).

[0294] When the intermediate relay UE 3-1c or the first relay UE 3-1a receive the transfer message (e.g., a UuMessageTransferSidelink message, or the like), that intermediate relay UE 3-1c or the first relay UE 3-1a checks the new information element indicating destination of the message, and will forward the message carrying the paging notification to the corresponding downstream node (i.e., the first relay UE 3-1a or remote UE 3-4). The remote UE 3-4 will not forward the message anymore since it is the destination of the message. This the paging notification forwarding by the intermediate relay UE 3-1c (and possibly by other relay UEs 3-1) may be routed based on one or more routing tables stored at the intermediate relay UE 3-1c (and possibly by other relay UEs 3-1) as described above.

[0295] < Routing Mechanism:> 　　It will be appreciated that, for the purposes of forwarding the message carrying the paging information from the remote UE 3-4 to the last relay UE 3-1b, routing is straightforward because, for both the first relay UE 3-1a and the intermediate relay UE 3-1c, there is only a single parent relay UE 3-1 (the intermediate relay UE 3-1c or the last relay UE 3-1b). Hence, the first relay UE 3-1a and the intermediate relay UE 3-1c can simply forward the message carrying the paging information to the appropriate parent relay UE 3-1 (the intermediate relay UE 3-1c or the last relay UE 3-1b).

[0296] However, in downlink direction, the last relay UE 3-1b, the intermediate relay UE 3-1c, and first relay UE 3-1a may each serve one or more UEs (which may include one or more remote UEs 3-4, one or more intermediate relay UEs 3-1c, and / or one or more first relay UEs 3-1a). For example, if the last relay UE 3-1b has a plurality of downstream intermediate relay UEs 3-1c, then when the last relay UE 3-1b needs to forward a requested SIB to a particular remote UE 3-4, the last relay UE 3-1b needs to be able to identify which intermediate relay UE 3-1c will lead to the correct remote UE 3-4.

[0297] To facilitate routing in a downlink direction, therefore, a source remote UE identifier may be incorporated into the message carrying the paging information that is sent from the remote UE 3-4 (e.g., a remote information message such as a 'RemoteUEInformationSidelink' message, or the like) to the first relay UE 3-1a. The first relay UE 3-1a and the intermediate relay UE 3-1c maintain this information when forwarding the message carrying the paging information to the next relay UE 3-1 in the uplink relaying path (the intermediate relay UE 3-1c or the last relay UE 3-1b) until the message carrying the paging information reaches the last relay UE 3-1b. When the first relay UE 3-1a, the intermediate relay UE 3-1c, or the last relay UE 3-1b receives the message carrying the paging information, the recipient relay UE 3-1 stores (e.g., in a routing table or the like) information representing a mapping relationship between the remote UE identifier and information identifying the next downstream node in the relaying path (e.g. a corresponding relay UE identifier) to the identified remote UE 3-4.

[0298] For example, in the multi-hope scenario of Fig. 13, when the last relay UE 3-1b (relay UE #1 in Fig. 13) receives the message carrying the paging information of one remote UE 3-4a (remote UE #1 in Fig. 13) from the intermediate relay UE 3-1c (relay UE #2 in Fig. 13), the last relay UE 3-1b may generate a routing table entry to record the mapping between that the remote UE 3-4a and the last relay UE 3-1b. When the last relay UE 3-1b receives a paging notification, it will send an appropriate UE-to-UE (e.g., PC5 / sidelink) transfer message (e.g., a UuMessageTransferSidelink message, or the like) carrying the paging notification to the intermediate relay UE 3-1c (relay UE #2 in Fig. 13), which can perform further message forwarding.

[0299] It will be appreciated that, alternatively (or additionally), some or all of the routing information required for routing the transfer message carrying the paging notification in the downlink direction (from the last relay UE 3-1b to the remote UE 3-4) may be configured by the RAN node 5, to the last relay UE 3-1b, when that the last relay UE 3-1b is in an RRC connected mode / state.

[0300] < Devices of the Communication System> <User Equipment> 　　Fig. 16 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1. In this example the UE 3 is a UE that is capable of performing sidelink communication. In this example the UE 3 is a UE that is capable of operating either as a (U2N) remote UE or as a (U2N) relay UE (in either single-hop or multi-hop scenarios).

[0301] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antenna 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g. a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.

[0302] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communication control module 43.

[0303] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node 5 (and other communication devices connected to the RAN node 5, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling uplink communication via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling receipt of downlink communication via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 43 is responsible, for example, for determining the resources to be used by the UE 3, for determining how slots / symbols are configured (e.g., for UL, DL, flexible, full duplex communication, or the like), for determining which bandwidth parts are configured for the UE 3, for determining how uplink transmissions should be encoded, etc.

[0304] It will be appreciated that the communication control module 43 includes a number of sub-modules to support the corresponding functionalities of the different layers described above. For example, the communication control module 43 will typically include an RRC sub-module, an SDAP sub-module, a PDCP sub-module, an RLC sub-module, a MAC sub-module, a PHY sub-module, an SRAP sub-module, an IP sub-module, etc. for providing corresponding functionality.

[0305] The communication control module 43 also includes a number of sub-modules to support operation of the UE 3 either as a (U2N) remote UE or as (U2N) relay UE, depending on requirements, as described above. These include, for example, sub-modules for controlling transmission and reception over UE-to-UE (PC5 / sidelink) channels and for receiving and forwarding data from other UEs over the air interface (e.g., Uu) with a RAN node 5, when operating as a relay UE.

[0306] The communication control module 43 is configured, in particular, to control the base station's communication, where applicable, in accordance with any of the methods described herein.

[0307] < RAN Node> 　　Fig. 17 is a schematic block diagram illustrating the main components of the RAN node 5 for the communication system 1.

[0308] As shown, the RAN node 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antenna 53 (e.g. a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g. comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes via an appropriate interface (e.g. the so-called 'Xn' interface in NR).

[0309] The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59.

[0310] As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

[0311] The communication control module 63 is operable to control the communication between the RAN node 5 and the UEs 3 and other network entities that are connected to the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall handling of the transmission of downlink communication via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0312] It will be appreciated that the communication control module 63 includes a number of sub-modules to support the corresponding functionalities of the different layers described above. For example, the communication control module 63 will typically include an RRC sub-module, an SDAP sub-module, a PDCP sub-module, an RLC sub-module, a MAC sub-module, a PHY sub-module, an SRAP sub-module, an IP sub-module, etc. for providing corresponding functionality.

[0313] The communication control module 63 is configured, in particular, to control the base station's communication, where applicable, in accordance with any of the methods described herein.

[0314] < Modifications and Alternatives> 　　Detailed examples have been described above along with a number of variations and alternatives. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the innovations embodied therein.

[0315] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

[0316] In the above description, the UEs and the RAN node are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0317] In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the RAN node, to the mobility management entity, or to the UE as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of, this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the RAN node or the UE in order to update their functionalities.

[0318] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0319] The base station may comprise a 'distributed' base station having a central unit 'CU' and one or more separate distributed units (DUs).

[0320] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0321] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0322] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

[0323] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0324] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0325] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0326] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0327] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0328] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0329] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0330] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.

[0331] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0332] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0333] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0334] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunication system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.

[0335] Further, the above-described UE categories are merely examples of applications of the technical ideas and examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

[0336] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0337] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a Relay User Equipment, UE, the method comprising: acquiring a first group of at least one System Information Block, SIB; receiving from a first UE, a first message carrying a request for a second group of at least one SIB; determining that all of the at least one SIB in the second group are included in the first group; transmitting the at least one SIB in the second group to the first UE; and terminating the request without forwarding to a parent UE. 　　(Supplementary note 2) 　　The method of supplementary note 1, further comprising: receiving, from the first UE, first information for paging monitoring; and providing the first information to the parent UE. 　　(Supplementary note 3) 　　The method of supplementary note 2, wherein the Relay UE is in Radio Resource Control, RRC, IDLE or INACTIVE state. 　　(Supplementary note 4) 　　The method of supplementary note 2 or 3, wherein, the first UE is in an RRC idle state, and the first information includes a remote UE identifier. 　　(Supplementary note 5) 　　The method of supplementary note 4, wherein the remote UE identifier is a serving temporary mobile subscriber identity, S-TMSI. 　　(Supplementary note 6) 　　The method of supplementary note 4, wherein the first information further includes information indicating a UE specific discontinuous reception, DRX, cycle. 　　(Supplementary note 7) 　　The method of any one of supplementary notes 4-6, further comprising: forwarding the first information to a next downstream relay UE in a downlink relaying path for each remote UE being paged. 　　(Supplementary note 8) 　　The method of supplementary note 7, wherein the first information is forwarded in a UuMessageTransferSidelink message. 　　(Supplementary note 9) 　　The method of any one of supplementary notes 1-8, further comprising: receiving, from the parent UE, UuMessageTransferSidelink message containing identification of the first UE. 　　(Supplementary note 10) 　　The method of any one of supplementary notes 1-9, wherein the first message comprises a source remote UE identifier. 　　(Supplementary note 11) 　　The method of supplementary note 10, further comprising: storing information representing a mapping relationship between the source remote UE identifier and information identifying a next downstream node in a relaying path to a remote UE identified by the source remote UE identifier. 　　(Supplementary note 12) 　　The method of any one of supplementary notes 1-11, wherein the first message is RemoteUEInformationSidelink. 　　(Supplementary note 13) 　　A method performed by a Relay User Equipment, UE, the method comprising: acquiring a first group of at least one System Information Block, SIB; receiving from a first UE, a first request for a second group of at least one SIB; determining that the first group is a part of the second group; forwarding the first request to a parent UE. 　　(Supplementary note 14) 　　The method of supplementary note 13, further comprising: modifying the first request to a second request for the first group before the forwarding of the first request. 　　(Supplementary note 15) 　　A Relay User Equipment, UE comprising: means for acquiring a first group of at least one System Information Block, SIB; means for receiving from a first UE, a first message carrying a request for a second group of at least one SIB; means for determining that all of the at least one SIB in the second group are included in the first group; means for transmitting the at least one SIB in the second group to the first UE; and means for terminating the request without forwarding to a parent UE. 　　(Supplementary note 16) 　　The Relay UE of supplementary note 15, further comprising: means for receiving, from the first UE, first information for paging monitoring; and means for providing the first information to the parent UE. 　　(Supplementary note 17) 　　The Relay UE of supplementary note 16, wherein the Relay UE is in Radio Resource Control, RRC, IDLE or INACTIVE state. 　　(Supplementary note 18) 　　The Relay UE of supplementary note 15 or 16, wherein, the first UE is in an RRC idle state, and the first information includes a remote UE identifier. 　　(Supplementary note 19) 　　The Relay UE of supplementary note 18, wherein the remote UE identifier is a serving temporary mobile subscriber identity, S-TMSI. 　　(Supplementary note 20) 　　The Relay UE of supplementary note 19, wherein the first information further includes information indicating a UE specific discontinuous reception, DRX, cycle. 　　(Supplementary note 21) 　　The Relay UE of any one of supplementary notes 15-20, further comprising: means for forwarding the first information to a next downstream relay UE in a downlink relaying path for each remote UE being paged. 　　(Supplementary note 22) 　　The Relay UE of supplementary note 21, wherein the first information is forwarded in a UuMessageTransferSidelink message. 　　(Supplementary note 23) 　　The Relay UE of any one of supplementary notes 15-22, further comprising: means for receiving, from the parent UE, UuMessageTransferSidelink message containing identification of the first UE. 　　(Supplementary note 24) 　　The Relay UE of any one of supplementary notes 15-23, wherein the first message comprises a source remote UE identifier. 　　(Supplementary note 25) 　　The Relay UE of supplementary note 24, further comprising: means for storing information representing a mapping relationship between the source remote UE identifier and information identifying a next downstream node in a relaying path to a remote UE identified by the source remote UE identifier. 　　(Supplementary note 26) 　　The Relay UE of any one of supplementary notes 15-25, wherein the first message is RemoteUEInformationSidelink. 　　(Supplementary note 27) 　　A Relay User Equipment, UE, comprising: means for acquiring a first group of at least one System Information Block, SIB; means for receiving from a first UE, a first request for a second group of at least one SIB; means for determining that the first group is a part of the second group; means for forwarding the first request to a parent UE. 　　(Supplementary note 28) 　　The Relay UE of supplementary note 27, further comprising: means for modifying the first request to a second request for the first group before the forwarding of the first request.

[0338] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2418862.5, filed on December 20, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0339] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 RAN NODE 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE

Claims

A method performed by a Relay User Equipment, UE, the method comprising:acquiring a first group of at least one System Information Block, SIB;receiving from a first UE, a first message carrying a request for a second group of at least one SIB;determining that all of the at least one SIB in the second group are included in the first group;transmitting the at least one SIB in the second group to the first UE; andterminating the request without forwarding to a parent UE.　　The method of claim 1, further comprising:receiving, from the first UE, first information for paging monitoring; andproviding the first information to the parent UE.　　The method of claim 2, wherein the Relay UE is in Radio Resource Control, RRC, IDLE or INACTIVE state.　　The method of claim 2 or 3, wherein,the first UE is in an RRC idle state, andthe first information includes a remote UE identifier.　　The method of claim 4, wherein the remote UE identifier is a serving temporary mobile subscriber identity, S-TMSI.　　The method of claim 4, wherein the first information further includes information indicating a UE specific discontinuous reception, DRX, cycle.　　The method of any one of claims 4-6, further comprising:forwarding the first information to a next downstream relay UE in a downlink relaying path for each remote UE being paged.　　The method of claim 7, wherein the first information is forwarded in a UuMessageTransferSidelink message.　　The method of any one of claims 1-8, further comprising:receiving, from the parent UE, UuMessageTransferSidelink message containing identification of the first UE.　　The method of any one of claims 1-9, wherein the first message comprises a source remote UE identifier.　　The method of claim 10, further comprising:storing information representing a mapping relationship between the source remote UE identifier and information identifying a next downstream node in a relaying path to a remote UE identified by the source remote UE identifier.　　The method of any one of claims 1-11, wherein the first message is RemoteUEInformationSidelink.　　A method performed by a Relay User Equipment, UE, the method comprising:acquiring a first group of at least one System Information Block, SIB;receiving from a first UE, a first request for a second group of at least one SIB;determining that the first group is a part of the second group;forwarding the first request to a parent UE.　　The method of claim 13, further comprising:modifying the first request to a second request for the first group before the forwarding of the first request.　　A Relay User Equipment, UE comprising:means for acquiring a first group of at least one System Information Block, SIB;means for receiving from a first UE, a first message carrying a request for a second group of at least one SIB;means for determining that all of the at least one SIB in the second group are included in the first group;means for transmitting the at least one SIB in the second group to the first UE; andmeans for terminating the request without forwarding to a parent UE.　　The Relay UE of claim 15, further comprising:means for receiving, from the first UE, first information for paging monitoring; andmeans for providing the first information to the parent UE.　　The Relay UE of claim 16, wherein the Relay UE is in Radio Resource Control, RRC, IDLE or INACTIVE state.　　The Relay UE of claim 15 or 16, wherein,the first UE is in an RRC idle state, andthe first information includes a remote UE identifier.　　The Relay UE of claim 18, wherein the remote UE identifier is a serving temporary mobile subscriber identity, S-TMSI.　　The Relay UE of claim 19, wherein the first information further includes information indicating a UE specific discontinuous reception, DRX, cycle.　　The Relay UE of any one of claims 15-20, further comprising:means for forwarding the first information to a next downstream relay UE in a downlink relaying path for each remote UE being paged.　　The Relay UE of claim 21, wherein the first information is forwarded in a UuMessageTransferSidelink message.　　The Relay UE of any one of claims 15-22, further comprising:means for receiving, from the parent UE, UuMessageTransferSidelink message containing identification of the first UE.　　The Relay UE of any one of claims 15-23, wherein the first message comprises a source remote UE identifier.　　The Relay UE of claim 24, further comprising:means for storing information representing a mapping relationship between the source remote UE identifier and information identifying a next downstream node in a relaying path to a remote UE identified by the source remote UE identifier.　　The Relay UE of any one of claims 15-25, wherein the first message is RemoteUEInformationSidelink.　　A Relay User Equipment, UE, comprising:means for acquiring a first group of at least one System Information Block, SIB;means for receiving from a first UE, a first request for a second group of at least one SIB;means for determining that the first group is a part of the second group;means for forwarding the first request to a parent UE.　　The Relay UE of claim 27, further comprising:means for modifying the first request to a second request for the first group before the forwarding of the first request.

Images