Multi-hop sidelink relay communications

Abstract

In some examples, a method for reducing latency in multi-hop sidelink relay communications comprises establishing, by a relay user equipment, UE, a connection with a network, receiving, by the relay UE, an authorization to operate in an always-on model, maintaining, by the relay UE, a radio resource control, RRC, connected state for an extended duration based on the authorization, and serving, by the relay UE, one or more other relay and remote UEs while in the RRC connected state.

Description

MULTI-HOP SIDELINK RELAY COMMUNICATIONSTECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication systems and multi-hop sidelink relay communications, and more particularly to methods and systems for reducing latency in multi-hop sidelink relay communications used for emergency services and public warning systems (PWS) .BACKGROUND

[0002] Wireless communication systems have evolved significantly, enabling various enhancements in connectivity, coverage, and reliability. One important advancement has been the development of sidelink (SL) communications, which allow direct device-to-device (D2D) interactions without the need for centralized network infrastructure. Sidelink technology is standardized by the Third Generation Partnership Project (3GPP) and has been introduced to support proximity services (ProSe) , enabling user equipment (UE) to communicate directly with other UEs in scenarios where traditional cellular coverage is limited or unavailable.

[0003] In particular, sidelink-enabled UE-to-Network (U2N) relays have been introduced to extend network coverage and improve power efficiency for remote UEs. These relay UEs facilitate connections between remote UEs that are out of direct network coverage and the cellular network infrastructure. The relay UE communicates with the network via a traditional cellular link (Uu interface) and with remote UEs via sidelink communication (PC5 interface) . Such relays have been standardized in recent 3GPP releases (Rel-17, Rel-18) , addressing scenarios where either the relay UE or remote UE is outside cellular coverage.

[0004] However, single-hop sidelink relays have inherent limitations due to their restricted communication range. To overcome this limitation, multi-hop sidelink relays have been proposed. Multi-hop sidelink relay systems involve multiple relay UEs forwarding messages from remote UEs to the cellular network through intermediate relay devices. This approach significantly expands coverage and enhances reliability, particularly in challenging environments such as disaster zones or remote locations where conventional network infrastructure may be compromised or unavailable.SUMMARY

[0005] An objective of the present disclosure is to provide improved multi-hop sidelink relay mechanisms which can be used to reduce latency and enhance reliability for critical communication scenarios, such as emergency response operations and public warning systems (PWS) for example.

[0006] The foregoing and other objectives are achieved by the features of the independent claims.

[0007] Further implementation forms are apparent from the dependent claims, the description and the Figures.

[0008] A first aspect of the present disclosure provides a method for reducing latency in multi-hop sidelink relay communications, the method comprising establishing, by a relay user equipment, UE, a connection with a network, receiving, by the relay UE, an authorization to operate in an always-on mode, maintaining, by the relay UE, a radio resource control, RRC, connected state for an extended duration based on the authorization, and serving, by the relay UE, one or more other relay and remote UEs while in the RRC connected state.

[0009] Operating in an always on connection / mode reduces latency and enables a maximum number of remote UE (s) to be reached so that they may remain connected to a network in, e.g., an emergency situation. For example:

[0010] Search and Rescue Operations: In areas where infrastructure is compromised (such as after an earthquake or avalanche) , search-and-rescue teams can use multi-hop sidelink relays to maintain communication. Devices like smartphones, wearable devices, or drones can serve as relays to ensure the team remains in contact even when they are far apart.

[0011] Disaster Recovery: After natural disasters, traditional communication networks (e.g., cell towers) might be down. Multi-hop sidelink relays allow emergency services to communicate effectively by using devices that are still operational, such as vehicles, portable communication devices, or even satellite terminals.

[0012] Vehicular Networks: Emergency vehicles (ambulances, fire trucks, police cars) can act as relays to extend coverage for emergency responders in remote areas. The emergency vehicle’s communication systems can relay data and voice signals between distant teams, ensuring uninterrupted communication throughout a large area.

[0013] Mass Casualty Incidents: In mass casualty events, where there is a high density of emergency responders, multi-hop relays can help ensure that medical data, victim information, and other critical communications are transmitted efficiently across large areas without network congestion.

[0014] Real-Time Surveillance and Monitoring: Drones equipped with cameras can provide real-time surveillance in disaster zones. Multi-hop relays can extend the reach of drone communication, allowing live video feeds and situational data to be relayed to ground teams or command centers.

[0015] Public Safety Networks: Multi-hop relays can be deployed to create resilient public safety communication networks that function even during major disruptions. These networks can ensure that first responders, healthcare workers, and other emergency services remain connected.

[0016] Natural Disaster Alerts (Earthquakes, Tsunamis, Floods, etc. ) : During natural disasters, public safety messages need to reach affected populations quickly. Sidelink relays can be used to spread these messages in remote or heavily damaged areas where cellular coverage may be unavailable. For example, an alert sent by emergency services could be relayed by a smartphone or connected vehicle to nearby devices that do not have direct access to the cellular network.

[0017] Evacuation Alerts: During large-scale evacuations (such as from a wildfire, flood, or chemical spill) , sideline relays can ensure that evacuation orders and safety instructions are broadcast across all areas affected by the disaster, even when the central infrastructure (like cell towers or internet connections) is down or overwhelmed.

[0018] Hazardous Weather Warnings (Tornadoes, Severe Storms, etc. ) : When extreme weather events like tornadoes or hurricanes are imminent, it’s critical that warnings reach the public immediately. Sidelink relays allow these warnings to be disseminated to all devices in the vicinity, ensuring even people who are not directly connected to traditional cellular networks or broadcasting systems receive timely alerts.

[0019] Terrorism or Security Threats: In the event of a terrorist attack or another security threat, a public warning system must be able to quickly notify the public about the situation. Sidelink relays can be used to deliver location-based alerts to everyone in the vicinity of a threat, without needing to rely on centralized communication systems.

[0020] Transportation-Related Alerts: Vehicles can act as moving relays to distribute important warnings in case of accidents, road closures, or public safety alerts, especially in urban environments with dense populations. For example, in the event of a traffic disaster or a large public event, emergency messages can be passed through a vehicle fleet or public transportation systems to devices on the ground (phones, wearables, etc. ) .

[0021] Crowd Safety and Public Events: In large public events or gatherings, crowd control and safety are paramount. If there is an emergency, sideline relay communication could allow the authorities to distribute emergency alerts to all attendees' smartphones in real-time, even if the event overwhelms nearby cellular infrastructure.

[0022] In an implementation of the first aspect, the authorization can be received from a core network via a base station. The method can further comprise transmitting, by the relay UE, a capability indication that the relay UE supports the always-on mode. Maintaining the RRC connected state can comprise remaining in the RRC connected state even when there is no active traffic from the relay UE. The method can further comprise generating, by the relay UE, periodic heartbeat packets to maintain the RRC connected state. The method can further comprise requesting, by the relay UE, a release of the RRC connection after completion of an emergency operation.

[0023] In an example, requesting the release can be triggered by expiration of a timer indicating no remote UEs have been connected to the relay UE for a predetermined time period.

[0024] A second aspect of the present disclosure provides a method for configuring relay user equipment, UE, for low-latency communications, comprising receiving, by a base station, an always-on authorization for a relay UE from a core network, receiving, by the base station, capability information indicating the relay UE supports an always-on mode, maintaining, by the base station, a radio resource control, RRC, connection with the relay UE for an extended duration based on the authorization and capability information.

[0025] In an implementation of the second aspect, the method can further comprise refraining, by the base station, from releasing the RRC connection with the relay UE even when there is no active traffic from the relay UE. The method can further comprise receiving, by the base station, a request from the relay UE to release the RRC connection, and releasing, by the base station, the RRC connection in response to the request.

[0026] A third aspect of the present disclosure provides a method for configuring low-latency relay communications, comprising activating, by an application or non-access stratum, NAS, layer of a relay user equipment, UE, an always-on mode for the relay UE, indicating, by the relay UE to a network, to maintain a radio resource control, RRC, connected connection, serving, by the relay UE, one or more other relay or remote UEs while in the RRC connected state maintained by the network.

[0027] In an implementation of the third aspect the method can further comprise indicating to maintain the RRC connection as part of an RRC connection setup request message. The method can further comprise deactivating, by the application or NAS layer, the always-on mode for the relay UE, and requesting, by the relay UE, release of the RRC connection. The method can further comprise sending, by the relay UE, an always-on relay mode indication in a discovery message.

[0028] In an example, remote UEs can be configured to prioritise connection establishment with the network through always on relays.

[0029] A fourth aspect of the present disclosure provides a method for configuring low-latency relay communications in a public warning system, PWS, area, comprising broadcasting, by a base station, an always-on relay mode indication in a system information broadcast message, receiving, at the base station from a relay user equipment, UE, a request to operate in an always-on mode, and maintaining, by the base station, a radio resource control, RRC, connection with the relay UE for an extended duration.

[0030] In an implementation of the fourth aspect, the method can further comprise receiving, by the base station, a PWS cancel message, broadcasting, by the base station, cancellation of the always-on relay mode indication, and releasing, by the base station, the RRC connection with the relay UE.

[0031] A fifth aspect of the present disclosure provides user equipment comprising a relay for multi-hop sidelink relay communications, the user equipment configured to establish a connection with a network, receive an authorization to operate in an always-on mode, maintain a radio resource control, RRC, connected state for an extended duration based on the authorization, and serve one or more remote UEs or other relay UEs while in the RRC connected state.

[0032] A sixth aspect of the present disclosure provides a node in a communications network, wherein the node is configured to receive an always-on authorization for a relay UE from a core network component of the network, receive capability information indicating the relay UE supports an always-on mode, and maintain a radio resource control, RRC, connection with the relay UE for an extended duration based on the authorization and capability information.

[0033] A seventh aspect of the present disclosure provides user equipment comprising a relay user equipment, wherein the user equipment is configured to receive an indication for activating, by an application or non-access stratum, NAS, layer of a relay user equipment, UE, an always-on mode for the relay UE, indicate, to a network, to maintain a radio resource control, RRC, connected connection for the relay UE, and serve one or more remote UEs or the other relay UEs while in the RRC connected state maintained by the network.

[0034] A eight aspect of the present disclosure provides a node in a communications network, wherein the node is configured to broadcast an always-on relay mode indication in a system information broadcast message, whereby to configure low-latency relay communications in a public warning system, receive, from a relay user equipment, UE, a request to operate in an always-on mode, and maintain a radio resource control, RRC, connection with the relay UE for an extended duration.

[0035] These and other aspects of the invention will be apparent from the embodiment (s) described below.BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order that the present disclosure may be more readily understood, embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

[0037] FIG. 1 is a schematic representation of a signalling chart for a network controlled always on relay setup, according to an example;

[0038] FIG. 2 is a schematic representation of a signalling chart for a network controlled always on release procedure, according to an example;

[0039] FIG. 3 is a is a schematic representation of a signalling chart for operator controlled higher-layer applications or non-access stratum (NAS) relay setup, according to an example;

[0040] FIG. 4 is a schematic representation of a signalling chart for a higher-layer application or non-access stratum (NAS) always on release procedure, according to an example;

[0041] FIG. 5 is a schematic representation of a signalling chart for a higher-layer application or non-access stratum (NAS) always on release procedure, according to an example;

[0042] FIG. 6 is a schematic representation of a signalling chart for a network controlled Always ON procedure for a Public Warning Systems (PWS) , according to an example;

[0043] FIG. 7 is a schematic representation of a signalling chart for relay setup for an Always ON procedure for a Public Warning Systems (PWS) , according to an example;

[0044] FIG. 8 is a schematic representation of a signalling chart for a connection release procedure, according to an example;

[0045] FIG. 9 is a schematic representation of a signalling chart for a connection release procedure, according to an example;

[0046] FIG. 10 is a schematic representation of a signalling chart for a connection release procedure, according to an example;

[0047] FIG. 11 is a schematic representation of a machine according to an example; and

[0048] FIG. 12 is as schematic representation of a method for reducing latency in multi-hop sidelink relay communications, according to an example.DETAILED DESCRIPTION

[0049] Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

[0050] Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

[0051] The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a, ” “an, ” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises, ” “comprising, ” “includes, ” and / or “including, ” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or groups thereof. The term “and / or” is only an association relationship for describing associated objects and represents that three relationships may exist such that A and / or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character “ / ” generally represents that the associated objects are in an “or” relationship.

[0052] Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

[0053] The following contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed disclosure are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art.

[0054] The phrases “in one implementation, ” or “in some implementations, ” may each refer to one or more of the same or different implementations. The term “coupled” is defined as connected whether directly or indirectly through intervening components and is not necessarily limited to physical connections. The expression “at least one of A, B and C” or “at least one of the following: A, B and C” means “only A, or only B, or only C, or any combination of A, B and C” .

[0055] The terms “system” and “network” may be used interchangeably.

[0056] For the purposes of explanation and non-limitation, specific details such as functional entities, techniques, protocols, and standards are set forth for providing an understanding of the present disclosure. In other examples, detailed disclosure of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the present disclosure with unnecessary details.

[0057] Persons skilled in the art will immediately recognize that any network function (s) or algorithm (s) disclosed may be implemented by hardware, software or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof.

[0058] A software implementation may include machine-and / or computer-readable and / or executable instructions stored on a machine-and / or computer-readable medium such as memory or other types of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function (s) or algorithm (s) .

[0059] The microprocessors or general-purpose computers may include Applications Specific Integrated Circuitry (ASIC) , programmable logic arrays, and / or using one or more Digital Signal Processor (DSPs) . Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware or as hardware or as a combination of hardware and software are well within the scope of the present disclosure. The computer readable medium includes but is not limited to Random Access Memory (RAM) , Read Only Memory (ROM) , Erasable Programmable Read-Only Memory (EPROM) , Electrically Erasable Programmable Read-Only Memory (EEPROM) , flash memory, Compact Disc Read-Only Memory (CD-ROM) , magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0060] As noted above, there have been advancements in existing multi-hop relay procedures. However, certain drawbacks are still exhibited. A primary issue arises from latency introduced during connection establishment procedures. Current baseline multi-hop relay methods assume that all intermediate relay UEs are initially in an idle or inactive state. Thus, when a remote UE initiates a connection request, each intermediate relay UE must transition individually from idle to connected states before serving the request. This sequential transition process results in increased latency and higher failure probability, which is particularly detrimental in emergency situations requiring immediate communication.

[0061] The present disclosure describes a mechanisms to enable relay UEs to maintain extended radio resource control (RRC) connected states ( "Always ON" mode) . These solutions ensure rapid connection establishment and efficient communication pathways for emergency services and public safety applications, thereby significantly improving responsiveness and reliability during critical situations.

[0062] According to an example, a network-controlled "Always ON" relay setup can be used, in which certain relay UEs are authorized by a network core (CN) through a base station (gNB) to operate in an extended RRC connected state ( "Always ON" ) during emergencies or disaster recovery operations. Upon establishing a connection with the network, the gNB can receive authorization information from the CN indicating that specific relay UEs are permitted to remain connected continuously. The gNB also receives capability information from relay UEs confirming support for this "Always ON" mode.

[0063] In an example, authorized relay UEs remain in RRC connected state even without active traffic, optionally generating periodic heartbeat packets through established Data Radio Bearers (DRBs) to maintain connectivity. Relay UEs can proactively request RRC connection release after emergency operations conclude or after a predefined timer expires without any remote UEs connecting through them. This ensures immediate availability of relay resources, significantly reducing latency when remote UEs initiate connections during emergencies.

[0064] FIG. 1 is a schematic representation of a signalling chart for a network controlled always on relay setup, according to an example. In the example of FIG. 1, remote UE 1 (101) comprises user equipment initiating communication. Remote UE 2 (103) is another UE requiring connectivity via the relay. The intermediate / first U2N relay (105) comprises the intermediate and / or first relay UE in the multi-hop chain, and the last relay UE (107) is the final relay UE before connecting to the network. gNB (109) comprises a base station managing network connectivity, and AMF (111) is an access and mobility management function part of the core network.

[0065] At 0 registration and authorization takes place. Specifically, relay UEs are registered and authorized for single-hop or multi-hop relay operations, including the "Always ON" mode. This authorization is received during the registration procedure via NAS or higher-layer signalling.

[0066] An RRC connection setup process is performed in which, at 1a, an "Always ON" mode is authorized through NAS / higher-layer signalling for the last relay UE (107) . At 1b-3, the last relay UE (107) initiates an RRC connection setup with the gNB (109) by sending (1b) an RRCSetupRequest with an establishment cause set to "Emergency" to indicate that an emergency situation for example, in which the last relay UE 107 should remain in an RRC connected state of operation even if no traffic is detected. The gNB (109) responds (2) with an RRCSetup for the last relay UE (107) and receives (3) an RRCSetupComplete message from the last relay UE (107) , which includes an initial NAS message.

[0067] At 4–5 a core network context request process is performed in which the gNB (109) forwards an initial UE Message to the AMF (111) indicating that a UE context request is required. The AMF (111) processes this request and sends a UE context setup request back to the gNB (109) including authorization details for the "Always ON" mode and information about UE capabilities.

[0068] At 6, for security activation and data bearer setup, the gNB (109) activates security and establishes Data Radio Bearers (DRBs) for communication with the Last Relay UE (107) . Based on the "Always ON" authorization, the gNB (109) decides not to release the RRC connection, even if there is no active traffic at the last relay UE (107) .

[0069] At 7, the AMF (111) receives a UE Context Setup Response to confirm that the Last Relay UE (107) has been successfully configured for "Always ON" operation. At 8, discovery of intermediate relays (e.g. intermediate / first U2N relay (105) ) is performed using a discovery method (Model A or Model B) as defined in 3GPP TS 23.304. This involves either transmitting or responding to discovery messages with indications of "Always ON" mode included.

[0070] At 9, intermediate relays, such as intermediate / first U2N relay (105) , receive authorization for "Always ON" mode through NAS or higher-layer signalling. Remote UEs (101, 103) can initiate sidelink (PC5) connection establishment with their respective relays and then send RRCSetupRequest messages. These requests also specify an establishment cause of, e.g., "Emergency" .

[0071] At 12, gNB (109) receives sidelink-related information from the last relay UE (107) , enabling it to configure sidelink communication channels with intermediate relay UEs (105) . Then, at 13, RRC reconfiguration is performed in order to provide intermediate relay UEs (105) with Uu RLC channel configurations. At 14, RRC reconfiguration is performed in order to provide intermediate relay UEs (105) with PC5 RLC channel configurations for SRB1 (Signaling Radio Bearer) . This ensures that intermediate relays (105) are prepared for communication with other UEs in the chain.

[0072] At 15–17, for intermediate relay connection setup, last relay UE (107) forwards (15) an RRCSetupRequest to gNB (109) . At 16, gNB (109) sends an RRCSetup message to the intermediate / first U2N relay (105) , which responds (17) with RRCSetupComplete message containing an initial NAS message. This establishes an RRC connection between intermediate relays (105) and the last relay UE (107) ensuring readiness for multi-hop communication. Accordingly, intermediate relays (105) are in an RRC connected state of operation. A similar connection setup would happen for the first relay UE.

[0073] At 18, security activation and context setup procedures are performed for intermediate relays (105) ensuring secure communication channels are established. At 19, with "Always ON" mode enabled, fast connection availability is ensured for remote UEs (101, 103) attempting to establish RRC connections via intermediate relays (105) .

[0074] At 20, discovery is performed using Model A or Model B as defined in 3GPP TS 23.304. Intermediate relays (105) can transmit or respond to discovery messages, including indications of "Always ON" mode. At 21–23, remote UEs (101, 103) initiate sidelink (PC5) connection establishment with the intermediate / first relay UE 105 and then send (22) RRCSetupRequest messages to their respective relays . At 24, by leveraging "Always ON" mode, latency is significantly reduced for Remote UEs during RRC connection setup. This ensures faster communication pathways during emergencies.

[0075] Accordingly, intermediate relays are dynamically configured to establish secure and efficient communication channels with upstream and downstream entities, and an "Always ON" mode eliminates delays caused by transitioning from idle states, ensuring immediate availability of relay resources. An establishment cause set to "Emergency" prioritizes these connections during critical scenarios. Relays participate in discovery processes to identify suitable upstream / downstream entities while maintaining authorization for continuous operation.

[0076] Thus, according to an example, for emergency or disaster recovery scenario an “Always ON” Connection / Mode can be introduced as an additional option for Relay UEs which is beneficial in reducing latency. Certain Relay UE (s) can be authorised to remain in an RRC Connected State of operation for a longer duration after establishing a connection with the network, thereby enabling them to serve other intermediate and remote UEs as a recovery operation is ongoing. gNB can receive the “Always ON” authorization for the relay UEs from the CN when the connection is established. Additionally, the gNB can also receive information of the Relay UE capable of supporting Always ON feature through UE Capabilities. In an example, gNB will not release these UEs, even if there is no traffic from them. Alternatively these relay UEs can generate heart-beat packets at periodic intervals through the establishment of such a DRB. After the emergency operation is completed, relay UEs can request RRC connection release from the network through an RRC message, which can trigger the release of these UEs. This can be controlled by a timer such that if there is no UEs connected to the relay UE for a certain time it will request the network to release its connection.

[0077] FIG. 2 is a schematic representation of a signalling chart for a network controlled always on release procedure, according to an example. In the example of FIG. 2, a signalling mechanism is provided for the situation in which disaster recovery operations are completed, and therefore the need for an "Always ON" connections ends (2) .

[0078] If no remote UEs (101, 103) connect to a relay for a predetermined period of time (3) , relay (105) sends (4) an UE assistance information message with an indication for RRC Connection Release Request to request release from the network, which is received by the gNB (109) . The gNB (109) processes the release request and forwards (5) it to the AMF (111) . The AMF (111) issues (6) a UE context release command to gNB 109, which confirms (7) release completion by sending a UE Context Release Complete message back to the AMF (111) . gNB (109) releases remote UEs (101, 103) from the RRC connected state. Similar release procedures (9 –14) are followed for intermediate relays if they remain idle for a specified duration.

[0079] According to an example, activation and deactivation of the "Always ON" mode can be controlled by higher-layer applications or non-access stratum (NAS) signalling within relay UEs. As such, for example, first responders or operators can deploy relay devices strategically within disaster areas. Such deployed relay devices activate an "Always ON" mode via an application-level command or NAS signalling. During RRC connection establishment with the network, relay UEs can indicate, via a new establishment cause value, that their RRC connections should be maintained continuously until explicitly requested otherwise. Relay UEs can deactivate the "Always ON" mode via application-level commands or NAS signalling once emergency operations conclude, prompting RRC connection release requests. This provides flexibility for emergency responders to dynamically deploy and manage low-latency relay networks tailored specifically to operational needs.

[0080] FIG. 3 is a is a schematic representation of a signalling chart for operator controlled higher-layer applications or non-access stratum (NAS) relay setup, according to an example.

[0081] The example of FIG. 3 is similar to that described above with reference to FIG. 1, other than that the Activation / Deactivation of the ALWAYS ON mode is now controlled by App / NAS / Higher layers. Relays can be setup and deployed as and when needed by, e.g., first responders or under operator control (in, e.g., mountains, forests, or disaster zones) at certain locations where they can remain Always ON for a predetermined period of time in order to provide connectivity and serve remote UEs of those who may be, e.g., trapped in the mountains, forests, or disaster zones and where traditional network coverage is poor or unavailable.

[0082] According to an example, when emergency responders create a network of relays, relay UE (s) can indicate to the network that their RRC connection is to be maintained until a request is received for the RRC connection to be released through, e.g., an application. This can be performed through a new cause value for the establishment cause during an RRC Connection Setup phase for example.

[0083] FIG. 4 is a schematic representation of a signalling chart for a higher-layer application or non-access stratum (NAS) always on release procedure, according to an example. Once disaster recovery operations are completed, the need for "Always ON" connections ends. The relay (105) can deactivate (3) the Always ON mode of operation and send a message (4) to gNB (109) to request release from the network. For example, an application of the relay (105) can be used to deactivate the Always ON mode of operation. The process followed is then similar to that described above with reference to FIG. 2 for example. However, similarly to the above, for the last relay UE (107) , an application of the relay UE (107) can be used to deactivate the Always ON mode of operation.

[0084] FIG. 5 is a schematic representation of a signalling chart for a higher-layer application or non-access stratum (NAS) always on release procedure, according to an example. In the example of FIG. 5, the decision to deactivate the Always ON mode of operation is made (2) at the CN, e.g., AMF (111) .

[0085] FIG. 6 is a schematic representation of a signalling chart for a network controlled Always ON procedure for a Public Warning Systems (PWS) , according to an example. The example of FIG. 6 relates to sidelink relays operating in disaster / PWS areas that can remain in an RRC connected mode of operation for p [redetermined periods of time in order to serve remote UEs 601. A relay UE can check if it is serving in a disaster area based on a PWS message and if so can request an “Always ON” Connection / Mode. Relay UE (s) , after establishing the ALWAYS ON connection with the network, can remain in RRC Connected State to serve intermediate and remote UEs. Relay UE (s) can indicate to the network that their RRC Connection is to be maintained until, e.g., a disaster recovery operation is over through a new establishment cause value.

[0086] In the example of FIG. 6, a Cell Broadcast Centre (CBC) (603) can send (2) a Write Replace Request to AMF (111) . Once received at the AMF, a Write Replace Confirm is sent back to CBC (603) (3) . AMF (111) sends (4) the Write Replace Request to gNB (109) . gNB (109) sends (5) a paging message or direct indication information message to UEs 601 to indicate modification of the System information or direct indication of presence of PWS SIBs and includes the Primary and Secondary Notification for ETWS in the SIBs or CMAS SIBs. If the gNB (109) supports U2N relay operation, it can broadcast an “ALWAYS ON” relay mode indication in the SIB. The gNB (109) can then send (6) Write Replace Response to MME / AMF (111) . Any Relay UEs which establish the connection to the network from this point can request ALWAYS ON Mode until an emergency situation is resolved (until the next PWS Cancel message is received for example) .

[0087] Thus, in the example of FIG. 6, upon receiving a Write Replace Request associated with a PWS message from Access and Mobility Management Function (AMF) , the gNB broadcasts an indication of "Always ON" Relay Mode within System Information Blocks (SIBs) . Relay UEs detecting active PWS messages recognize their operation within disaster areas and request continuous RRC connectivity ( "Always ON" ) from the network. The gNB maintains these relay UEs in an extended RRC connected state throughout the duration of the emergency situation. Upon receiving a subsequent PWS Cancel message indicating resolution of the emergency scenario, the gNB removes the broadcast indication, prompting relay UEs to request RRC connection release. This integration ensures rapid dissemination of critical public warnings while simultaneously providing robust communication infrastructure for affected populations and emergency responders.

[0088] FIG. 7 is a schematic representation of a signalling chart for relay setup for an Always ON procedure for a Public Warning Systems (PWS) , according to an example. In the example of FIG. 7, after a PWS Warning is broadcast (0a) , ALWAYS ON Mode is Turned ON by gNB 109 at the AS Layer (1a) .

[0089] All the Relay UE (s) can be authorized to remain in RRC Connected State for a longer duration after establishing a connection with the network, mainly to serve other intermediate and remote UEs until, e.g., any recovery operation that may follow the PWS warning has been completed.

[0090] In an example, the last Relay UE 107 and intermediate / first relay UEs 105 can request (1b) the RRC connection Setup with a new establishment cause such as “Always ON relay operation” so that it does not get rejected by the gNB 109 during overload situations.

[0091] gNB 109 can receive the “Always ON” authorization for the relay UEs from the CN when the connection is established and will not release these UEs even if there is no traffic from them.

[0092] This will enable an always ON connection for a network being made available for a remote UE (101, 103) to establish their connection with reduced latency.

[0093] FIG. 8 is a schematic representation of a signalling chart for a connection release procedure, according to an example. In the example of FIG. 8, the connection release procedure depicted exemplifies how the “Always ON mode” can be deactivated by the gNB 109 after a, e.g., PWS warning message broadcast is stopped and a disaster recovery operation is completed (see, for example, FIG. 8) . The gNB 109 itself can deactivate the Always ON mode by updating the SIB and indicating deactivation of Always ON mode. The gNB 109 can then initiate the release of the RRC Connection of the Remote UEs 101, 103 followed by the first / intermediate 105 and the Last Relay UE 107.

[0094] FIG. 9 is a schematic representation of a signalling chart for a connection release procedure, according to an example. In the example of FIG. 9, the connection release procedure relates to the case where too many Relay UEs start operating in an Always ON mode. gNB 109 detects that too many (e.g., more than a predetermined threshold number of) relay UEs are in an Always ON mode and are not needed. gNB 109 can decide to release some of them with an indication not to follow Always ON mode.

[0095] FIG. 10 is a schematic representation of a signalling chart for a connection release procedure, according to an example. In the example of FIG. 10, the connection release procedure relates to the case where intermediate relay UE 105 cannot continue as the relay UE due to, e.g., battery limitation and indicates this to the Network through a UE Assistance Information RRC Message. Based on this indication gNB 109 can release the remote UEs 101, 103 connected via this intermediate relay UE 105 and then release the intermediate relay UE 105.

[0096] The present disclosure offer substantial advantages over existing multi-hop sidelink relay procedures. For example, there is significant latency reduction due to the immediate availability of relay resources as a result of the elimination of sequential transitions from idle / inactive states during emergencies. Enhanced reliability is provided since continuous connectivity reduces failure probability during critical communication scenarios. Operational flexibility is provided: Emergency responders can dynamically deploy relays tailored specifically to operational requirements. Integration with Public Warning Systems: Enables rapid dissemination of critical alerts alongside robust communication capabilities during disasters.

[0097] Aspects can be implemented within 5G NR networks employing multi-hop Layer-2 UE-to-Network relays over NR PC5 interfaces. The architecture includes: · Remote UEs communicating via sidelink interfaces (PC5) with first / intermediate and last-hop relay UEs. · Relay UEs maintaining continuous RRC connectivity via cellular links (Uu interface) with base stations / gNBs. · Base stations / gNBs coordinating authorization, capability negotiation, system information broadcasting, and  maintaining continuous connectivity based on network-controlled or operator-controlled configurations.

[0098] Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc. ) having computer readable program codes therein or thereon.

[0099] The present disclosure is described with reference to flow charts and / or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and / or additional blocks may be added. It shall be understood that each flow and / or block in the flow charts and / or block diagrams, as well as combinations of the flows and / or diagrams in the flow charts and / or block diagrams can be realized by machine readable instructions.

[0100] The machine-readable instructions may, for example, be executed by a machine such as a general-purpose computer, a node, e.g., a gNB, or base station, a network entity, a platform comprising user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors.

[0101] Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor.

[0102] FIG. 11 is a schematic representation of a machine according to an example. The machine 1100 can be, e.g., a system or apparatus, user equipment, or part thereof, or a base station, node or network entity. The machine 1100 comprises a processor 1103, and a memory 1105 to store instructions 1102, executable by the processor 1103. The machine comprises a storage 1109 that can be used to store data 1111 representing matrices and / or the values of their elements, scaling factors and so on as described above with reference to FIGs. 1 to 10 for example.

[0103] The instructions 1102, executable by the processor 1103, can cause the machine 100 to establish a connection with a network, receive an authorization to operate in an always-on mode, maintain a radio resource control, RRC, connected state for an extended duration based on the authorization, and serve one or more other relay and remote UEs while in the RRC connected state.

[0104] Accordingly, the machine 1100 can implement a method for reducing latency in multi-hop sidelink relay communications.

[0105] Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow (s) in the flow charts and / or block (s) in the block diagrams.

[0106] Further, the teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure.

[0107] In some examples, some methods can be performed in a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc. ) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

[0108] FIG. 12 is as schematic representation of a method for reducing latency in multi-hop sidelink relay communications, according to an example. In block 1201 a relay user equipment, UE, establishes a connection with a network. In block 1203, an authorization to operate in an always-on mode is received by the relay UE. In block 1205, the relay UE maintains a radio resource control, RRC, connected state for an extended duration based on the authorization. In block 1207, the relay UE serves one or more other relay and remote UEs while in the RRC connected state.

[0109] While various embodiments have been described and / or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable-storage media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and / or representations of physical devices from one form to another.

[0110] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

1.A method for reducing latency in multi-hop sidelink relay communications, the method comprising:establishing, by a relay user equipment, UE, a connection with a network;receiving, by the relay UE, an authorization to operate in an always-on mode;maintaining, by the relay UE, a radio resource control, RRC, connected state for an extended duration based on the authorization; andserving, by the relay UE, one or more other relay and remote UEs while in the RRC connected state.2.The method of claim 1, wherein the authorization is received from a core network via a base station.3.The method of claim 1 or 2, further comprising:transmitting, by the relay UE, a capability indication that the relay UE supports the always-on mode.4.The method of any preceding claim, wherein maintaining the RRC connected state comprises:remaining in the RRC connected state even when there is no active traffic from the relay UE.5.The method of any preceding claim, further comprising:generating, by the relay UE, periodic heartbeat packets to maintain the RRC connected state.6.The method of any preceding claim, further comprising:requesting, by the relay UE, a release of the RRC connection after completion of an emergency operation.7.The method of claim 6, wherein requesting the release is triggered by expiration of a timer indicating no remote UEs have been connected to the relay UE for a predetermined time period.8.A method for configuring relay user equipment, UE, for low-latency communications, comprising:receiving, by a base station, an always-on authorization for a relay UE from a core network;receiving, by the base station, capability information indicating the relay UE supports an always-on mode;maintaining, by the base station, a radio resource control, RRC, connection with the relay UE for an extended duration based on the authorization and capability information.9.The method of claim 8, further comprising:refraining, by the base station, from releasing the RRC connection with the relay UE even when there is no active traffic from the relay UE.10.The method of claim 8 or 9, further comprising:receiving, by the base station, a request from the relay UE to release the RRC connection; andreleasing, by the base station, the RRC connection in response to the request.11.A method for configuring low-latency relay communications, comprising:activating, by an application or non-access stratum, NAS, layer of a relay user equipment, UE, an always-on mode for the relay UE;indicating, by the relay UE to a network, to maintain a radio resource control, RRC, connected connection;serving, by the relay UE, one or more other relay or remote UEs while in the RRC connected state maintained by the network.12.The method of claim 11, further comprising:indicating to maintain the RRC connection as part of an RRC connection setup request message.13.The method of claim 11 or 12, further comprising:deactivating, by the application or NAS layer, the always-on mode for the relay UE; andrequesting, by the relay UE, release of the RRC connection.14.The method of any preceding claim, further comprising:sending, by the relay UE, an always-on relay mode indication in a discovery message.15.The method of any preceding claim, wherein the remote UEs are configured to prioritise connection establishment with the network through always on relays.16.A method for configuring low-latency relay communications in a public warning system, PWS, area, comprising:broadcasting, by a base station, an always-on relay mode indication in a system information broadcast message;receiving, at the base station from a relay user equipment, UE, a request to operate in an always-on mode; andmaintaining, by the base station, a radio resource control, RRC, connection with the relay UE for an extended duration.17.The method of claim 16, further comprising:receiving, by the base station, a PWS cancel message;broadcasting, by the base station, cancellation of the always-on relay mode indication; andreleasing, by the base station, the RRC connection with the relay UE.18.User equipment comprising a relay for multi-hop sidelink relay communications, the user equipment configured to:establish a connection with a network;receive an authorization to operate in an always-on mode;maintain a radio resource control, RRC, connected state for an extended duration based on the authorization; andserve one or more remote UEs or other relay UEs while in the RRC connected state.19.A node in a communications network, wherein the node is configured to:receive an always-on authorization for a relay UE from a core network component of the network;receive capability information indicating the relay UE supports an always-on mode; andmaintain a radio resource control, RRC, connection with the relay UE for an extended duration based on the authorization and capability information.20.User equipment comprising a relay user equipment, wherein the user equipment is configured to:receive an indication for activating, by an application or non-access stratum, NAS, layer of a relay user equipment, UE, an always-on mode for the relay UE;indicate, to a network, to maintain a radio resource control, RRC, connected connection for the relay UE; andserve one or more remote UEs or the other relay UEs while in the RRC connected state maintained by the network.21.A node in a communications network, wherein the node is configured to:broadcast an always-on relay mode indication in a system information broadcast message, whereby to configure low-latency relay communications in a public warning system;receive, from a relay user equipment, UE, a request to operate in an always-on mode; andmaintain a radio resource control, RRC, connection with the relay UE for an extended duration.

Images