WO2025032116A1

WO2025032116A1 - Apparatus for distributing emergency messages in a cellular network and related method

Info

Publication number: WO2025032116A1
Application number: PCT/EP2024/072320
Authority: WO
Inventors: Oscar Garcia Morchon; Robert James Davies; Walter Dees; Nicholas Simon Walker
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2023-08-08
Filing date: 2024-08-07
Publication date: 2025-02-13
Anticipated expiration: 2026-02-08
Also published as: CN121666777A

Abstract

The method and system for distributing emergency messages in a communication network involves relay units receiving a message through a data or communication interface. These relay units determine if the message should be rebroadcasted in the communication interface and the communication resources to be used for the rebroadcast. The message is then rebroadcasted in the communication interface. The relay units may also perform their own assessment about forwarding the message and configure with a protocol determining their behavior. The relay units may use a pre-emptive communication strategy or a conflict prevention strategy. The relay units may also send or forward discovery/alert messages containing an emergency alert message or an indication thereof.

Description

APPARATUS FOR DISTRIBUTING EMERGENCY MESSAGES IN A CELLULAR NETWORK AND RELATED METHOD

FIELD OF THE INVENTION

The present invention relates to the field of communication networks, and more specifically, to a method and system for distributing emergency messages in a communication network such as a 3GPP network. The communication network may involve the use of one or more relay units that receive messages through a data interface or a communication interface and rebroadcast the messages.

BACKGROUND OF THE INVENTION

In the current technological landscape, communication networks are increasingly complex and interconnected. These networks are used to transmit a wide variety of information, including emergency messages. The distribution of these messages may be critical in situations of crisis or disaster, where timely and accurate information can save lives and mitigate damage.

Emergency alert systems and associated standards

Emergency alert systems have been set up in the UK and the EU under the Directive on European Electronic Communications Code (EECC). This is compatible with US Wireless Emergency Alerts (WEA). A range of standards have been developed for public emergency broadcasts using cellular systems. The 3rd Generation Partnership Project (3GPP) began a project in 2006 to define the requirements of a public warning system (PWS) in order to enhance its reliability, security and resilience. The resulting technical specification document gives general criteria for the delivery of alerts, the content of messages and handset features of PWS-capable handsets. The specifications also include additional requirements of specific PWS implementations such as the Earthquake and Tsunami Warning System (ETWS) in Japan and the Commercial Mobile Alert System (CMAS) in North America. Important 3GPP reports and standard specifications for the definition of PWS include the following:

• 3GPP TR 22.968 Study for Requirements for a Public Warning System (PWS) Service; and

• 3GPP TS 22.268 Technical Specification: Public Warning System (PWS).

The implementation of a PWS does not specify which alerting technology has to be used. However, from the 3GPP requirements and specification documents, the work done by the European Telecommunications Standards Institute (ETSI) and experience gained from existing PWS implementations such as NTT DoCoMo's Area mail system implemented in 2007, Cell Broadcast Service (CBS) emerges as a dominant technology for PWS. CBS has existed since 1988 and is already standardised in 3GPP, some of the important standards for cell broadcast are the following:

3GPP TS 23.041 - Technical Realisation of Cell Broadcast Service (CBS);

3GPP TS 44.012 - Short Message Service Cell Broadcast (SMSCB); and

3GPP TS 22.268 - Public Warning System (PWS) requirements.

These standards cover requirements of e.g. CBS and user equipment (UE) to communicate and respond to wireless emergency alerts, covering the full range of uses of such a system (e.g., Tsunami and earthquake).

Activities of the UE noted in these standards comprise display and sounding of unique alerts on CBS communication receipt.

In addition to the 3GPP standards, other standards have been created for PWS and cell broadcast. An important point to note is that CMAS and EU-Alert are compatible and so a universal standard exists for US and EU citizens.

In March 2023, the UN launched the Early Warnings for All (EW4AII) Initiative, which stipulates that every person in the world should be protected by an early warning system by 2027. The initiative's action plan puts the International Telecommunication Union (ITU) in the leading role on 'Warning Dissemination and Communication' - a critical component of early warning systems that ensures alerts reach the people at risk in time to take action. The action plan also specifically references the Global System for Mobile Telecommunications Association (GSMA) and Mobile Network Operators (MNOs) and calls for the promotion of the implementation of geo-located mobile early warning services using cell broadcast and/or location-based SMS. As part of the EW4AII Initiative, ITU is working to support countries to implement mobile early warning systems to reach more people at risk.

For current systems, the following problems need to be solved:

1. How to ensure that all users in the location can both receive an emergency alert and subsequently (for some defined time) be able to communicate even if not directly connected to a base station (BS). Conventional emergency alert systems message users in a locality when a life-threatening event occurs. Not everyone receives the alert since some users may not be connected to the cellular system and the emergency may itself disrupt local communications.

2. How can device-to-device (D2D) networks be used to improve the dissemination of emergency alerts as well as support disaster-associated communications needs. This process needs to be reconsidered in 6G, considering the use of communications which integrate different communications protocols and methods; particularly increased integration of D2D networks. SUMMARY OF THE INVENTION

It is an object of the present invention is to address the shortcomings of existing solutions and improve efficiency and/or effectiveness of emergency alert systems.

According to a first aspect, an apparatus for distributing emergency messages (such as PWMs or other high priority messages (e.g., Emergency Alerts)) in a cellular system is provided, wherein the apparatus is adapted to: receive an emergency message or an indication thereof (e.g., a paging message containing a flag indicating the availability of an emergency message) through a first data or communication interface (e.g., a Uu or PC5 interface), determine based on a set of criteria whether or not the emergency message or an indication thereof is to be distributed to other devices over a second data or communication interface (e.g., a PC5 interface), determine communication resources to be used to distribute the emergency message or an indication thereof over the second data or communication interface, and transmit the emergency message or the indication thereof over the second data or communication interface in the determined communication resources.

According to a second aspect, a system for distributing emergency messages in a communication network is provided, the system comprising one or more relay units comprising the apparatus of the first aspect.

According to third aspect, a method for distributing emergency messages in a communication network is provided, the method comprising: receiving an emergency message or an indication thereof through a first data interface or a communication interface by one or more relay units; determining based on a set of criteria whether or not the emergency message or an indication thereof is to be distributed via a second data or communication interface; determining communication resources to be used to distribute the emergency message or an indication thereof via the second data or communication interface; and transmitting the emergency message or an indication thereof via the second data or communication interface in the determined communication resources.

According to an aspect, a computer program product is provided, which comprises code means for producing the steps of the method of the third aspect when run on a computer device. Accordingly, a flexible and adaptable solution for distributing emergency messages in cellular networks can be provided, that can be tailored to specific network needs situations at hand. More specifically, it can be ensured that an increased number of people receive an emergency alert message after it is issued, even if they are not connected to a cellular system. Moreover, a robust communications network can be set up and maintained amongst UEs in an emergency situation and shortly afterwards, which is reasonably resilient even if cellular communications are disrupted.

An enhanced robustness can be achieved by integrating the cellular and D2D communications to achieve efficient and robust communications, correctly scheduling new connections to minimize channel interference during connection setup, optimising the speed at which an emergency message can be delivered to UEs which have not received it, and/or reorganising the D2D network (adding and pruning links) and the set of UEs connecting to cellular networks in order to minimise mutual interference, ensure at least two D2D links (if possible) with each UE, where these links are most reliable, minimise the total 'hoplength' from cellular to any UE not directly connected to cellular (minimise communications latencies), and/or minimise the load on the cellular networks by limiting BS-to-UE connections where the robustness of the whole network is not compromised.

According to a first option that can be combined with any of the first to fourth aspects, it may be determined whether the emergency message or indication thereof is to be distributed by using broadcast and/or groupcast communication over a PC5 communication interface, and the emergency message or the indication thereof may be broadcasted and/or groupcasted over the PC5 communication interface by one or more relay units.

According to a second option that can be combined with the first option or any of the first to fourth aspects, at least one criterion of the set of criteria to determine whether or not the emergency message or an indication thereof is to be distributed may be configured by the communication network through a set of policies.

According to a third option that can be combined with the first or second option or any of the first to fourth aspects, at least one criterion of the set of criteria to determine whether or not an the emergency message or an the indication thereof is to be distributed may be provided as part of a paging message and/or radio resource control, RRC, message and/or downlink control information, DCI, and/or media access control, MAC, control element, CE, message sent prior to the emergency message or the indication thereof.

According to a fourth option that can be combined with any of the first to third options or any of the first to fourth aspects, the emergency message or the indication thereof may comprise supplementary data to help (e.g., the apparatus) to decide whether the emergency message or an indication thereof is to be distributed or not and/or how it is to be distributed.

According to a fifth option that can be combined with any of the first to fourth options or any of the first to fourth aspects, one or more criteria may be determined (e.g., by the apparatus) and an own assessment may be made (e.g., by the apparatus) about whether or not to forward the emergency message or the indication thereof, and the one or more determined criteria may be provided (e.g., by the apparatus) to the communication network or to other relay units using a configuration protocol.

According to a sixth option that can be combined with any of the first to fifth options or any of the first to fourth aspects, a pre-emptive communication strategy or a conflict prevention strategy may be used e.g. by the apparatus.

According to a seventh option that can be combined with any of the first to sixth options or any of the first to fourth aspects, the emergency message or the indication thereof may be embedded in a PC5 discovery message or a PC5 connection setup message transmitted over a PC5 communication interface.

According to an eighth option that can be combined with any of the first to seventh options or any of the first to fourth aspects, the emergency message or the indication thereof may be transmitted to a remote unit in an idle or inactive mode at a time slot that may depend on a time slot when the emergency message or an indication thereof or a paging or radio resource control, RRC, or downlink/sidelink control information, DCI/SCI, message preceding the emergency message or the indication thereof have been received (e.g., by the apparatus) and a pre-configured time delay.

According to a ninth option that can be combined with any of the first to eighth options or any of the first to fourth aspects, a discovery and/or paging and/or page alert and/or RRC and/or SCI message may be transmitted (e.g., by the apparatus), which contain an indication of and/or a pointer to a broadcast and/or groupcast of the emergency message transmission to be made (e.g., by the apparatus), wherein the discovery and/or paging and/or page alert and/or RRC and/or SCI message may comprise information about a timing or type of the emergency message to be sent.

According to a tenth option that can be combined with any of the first to ninth options or any of the first to fourth aspects, a probability to forward the emergency message or an indication thereof may be used (e.g., by the apparatus) as a criterion to determine whether or not to distribute the emergency message or the indication thereof.

According to an eleventh option that can be combined with any of the first to tenth options or any of the first to fourth aspects, it may be determined (e.g., by the apparatus) whether or not it is near a cell edge, and this determination may be used (e.g., by the apparatus) as a criterion for distributing an the emergency message or an indication thereof.

According to a twelfth option that can be combined with any of the first to eleventh options or any of the first to fourth aspects, another device may be queried (e.g., by the apparatus) over a connection to determine if the other device has received an emergency message or an indication thereof, or it may be responded (e.g., by the apparatus) to a query determining if an emergency message or an indication thereof has been received.

The apparatus may be implemented in a relay unit and may determine a time and/or frequency and/or number of times to transmit the emergency message or an indication thereof that maximizes the chance of other devices to receive the emergency message or an indication thereof.

The emergency message or indication thereof may include supplementary data (e.g., additional criteria or information to assist in evaluating criteria) to help the apparatus to decide whether the message or an indication thereof is to be distributed or not and/or how it is to be distributed.

It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings:

Fig. 1 schematically shows a block diagram depicting an implementation of a system for distributing emergency messages in a communication network;

Fig. 2 schematically shows a flowchart illustrating a method where a relay unit distributes an emergency message or an indication thereof to a remote UE at a time-slot that may depend on the time-slot when the relay received the emergency message or an indication thereof and a pre-configured first time delay and optionally a second time delay;

Fig. 3 schematically shows a block diagram showing a system and process flow for creating an ad- hoc network for distributing emergency messages;

Fig. 4 schematically shows a flow chart representing a method for creating an ad-hoc network for distributing emergency messages; and

Fig. 5 schematically shows a diagram showing example network topologies. DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the present invention are described below based on a (3GPP-based) cellular network environment.

Throughout the present disclosure, the abbreviation "gNB" (5G terminology) is intended to mean access device such as a cellular base station or a Wi-Fi access point. The gNB is part of the radio access network (RAN), which provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements a radio access technology (RAT). Conceptually, it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN. The CN is the communication network's core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks. Furthermore, an access and mobility management function (AMF) terminates the control plane of different access networks onto the 5G CN (5GC) and controls which UEs can access the 5GC to exchange traffic. It also manages the mobility of UEs when they roam from one gNB to another for session/service continuity, whenever possible. Additionally, an Information Element (IE) designates (a group of) information which may be included within a signalling message or data flow which is sent across an interface (examples may include QoS (Quality of Service) definitions, setup parameters, user identifiers etc.). A location management function (LMF) is a network entity defined in the 5G Core Network to provide positioning functionality by means to determine the geographic or relative position of a mobile device based on downlink, uplink and sidelink location measuring radio signals. Further, a gateway mobile location center (GMLC) is used for active mobile positioning, meaning that it triggers specific activities on the network to retrieve a subscriber's location in real-time. For improved positioning precision, a GMLC can connect with additional precise location components in the network. The GMLC may contain functionality required to support LCS (Location Services). In one PLMN (Public Land Mobile Network), there may be more than one GMLC. The GMLC is the first node an external LCS client accesses in the network. Moreover, the abbreviation "QAM" (operations, administration, and management or maintenance) is understood to designate processes, activities, tools, and standards involved with operating, administering, managing and maintaining any system.

In the 3GPP specifications TS23.304 and TS24.501 for 5G networks, so-called proximity service (ProSe) functions are defined to enable - amongst others - connectivity for cellular communication devices (e.g UEs) that are temporarily not in coverage of an access device (gNB). This particular function is called ProSe UE-to-Network relay, or Relay UE. The Relay UE is a communication device that helps another UE to communicate to the gNB (i.e., access device) by relaying application and network data traffic in two directions between the other UE and the gNB. The local communication between the Relay UE and the other UE is called D2D communication or Sidelink communication or PC5 communication. The abbreviation "PC5" designates an interface for sidelink communication as defined by ProSe. Furthermore, the abbreviation "UL" is used for the uplink direction from the communication device (e.g., UE) to the access device (e.g., gNB), the abbreviation "DL" for the downlink direction from the access device (e.g., gNB) to the communication device (e.g., UE), and the abbreviation "SL" for sidelink communication between two or more communication devices (e.g., UEs). Once the relaying relation is established, a UE can be connected via the Relay UE and acts in a role of "Remote UE". This situation means that the Remote UE has an indirect network connection to the CN as opposed to a direct network connection that is the normal case (cf. 3GPP specification TS 22.261 V16.10.0).

Furthermore, 3GPP specifications TR 23.733 V15.1.0 and TR 36.746 V15.1.1 provide studies on architectural enhancements e.g. to enable an loT device (in a role of Remote UE) to operate on very low power by using a Relay UE to connect to the wider network. Because the Relay UE is physically very close, it can be reached using very low power transmissions. This work also includes security, speed and stability improvements to ProSe. These extensions of ProSe are called enhanced ProSe ("eProSe"). One proposed improvement in eProSe is an enhanced relaying architecture that operates in the second Open Systems Interconnection (OSI)/protocol layer (i.e., L2) intended to offer end-to-end Internet Protocol (IP) packet and Packet Data Convergence Protocol (PDCP) packet transmissions to remote communication devices for application and/or user data. A benefit of this architecture is that the remote communication devices become directly visible as a registered entity in the CN, which is relevant for monitoring and billing purposes and for improved control by the access device over the communication device.

Furthermore, an element for implementing scheduling mechanisms may be the Radio Resource Control (RRC) protocol which can operate end-to-end to UEs, potentially over one or more hops taking into consideration the above relay architecture on the second protocol OSI/layer (i.e., L2). A further element may be the use of a downlink control information (DCI), which is a short message sent in a low-bitrate control channel (e.g. Physical Downlink Control Channel (PDCCH)) with a special blindly detectable modulation or coding. Here, various DCI formats can be defined with different information content.

Current work in 3GPP

3GPP temporary document (Tdoc) S2-2307039 ("Support of Public Warning Notification Relaying by 5G ProSe UE-to-Network Relay", 3GPP TSG-WG SA2 Meeting # 157, Berlin, May 25-26, 2023) has introduced the support of the relaying of public warning messages (PWMs) according to the requirement specified in specification TS 22.268. Aligning the 3GPP specification with RAN Rel-17 solution for forwarding PWS system information blocks (SIBs) over a unicast link to Remote UE(s) as specified in TS 38.300. In Tdoc S2-2307039, it is described that when a UE that operates as a 5G ProSe UE-to-Network Relay receives a warning message, the UE shall broadcast the warning message to the remote UE(s). In this solution described in Tdoc S2-2307039, the 5G ProSe UE-to-Network Relay broadcasts the warning message i.e., SIB 6/7/8 received from the network to the 5G ProSe Remote UE(s) by using Broadcast mode of 5G ProSe direct communication as specified in clause 5.3.2 of TS 23.304. The 5G ProSe UE-to-Network Relay uses a configured Destination Layer-2 ID as specified in clause 5.1.4.1 of TS 23.304 when broadcasting the warning message and the 5G ProSe Remote UE receives warning messages broadcasted over PC5 reference point by using a configured Destination Layer-2 ID as specified in clause 5.1.4.1. The PC5 QoS parameters as specified in clause 5.1.4.1 are used to broadcast and receive the warning message for the 5G ProSe UE-to-Network Relay and the 5G ProSe Remote UE, respectively. A 5G ProSe Remote UE can receive the broadcasted warning message without establishing a connection to the 5G ProSe UE-to-Network Relay. The 5G ProSe UE- to-Network Relay performs the duplication detection function as specified in TS 23.041 to suppress received duplicated warning messages over Uu. The 5G ProSe Remote UE performs the duplication detection function as specified in TS 23.041 to detect duplicated warning messages received over PC5 and/or Uu. 5G ProSe Layer-2 UE-to-Network Relay can alternatively forward the PWS SIBs (i.e, SIB 6/7/8) to a connected 5G ProSe Layer-2 Remote UE over the unicast link as specified in TS 38.300 [12]. The Public Warning System architecture for 5G System is specified in TS 23.041.

The solution in Tdoc S2-2307039 still has a number of problems, including (1) a lack of control of which relay UEs forward the PWMs, (2) relay UEs may have connected remote UEs that may still be connected (i.e. via a relay UE to the network), and for which rebroadcasting the emergency messages in the PC5 interface may not be useful. While, other UEs may not be connected at all, and those UEs will keep missing the emergency messages, (3) remote UEs that are not connected to a relay UE or that are in IDLE/INACTIVE state may not be able to receive PWMs, or (4) other types of relays are not considered, e.g., (Residential) Gateway devices, RF repeaters.

In embodiments, the distribution of emergency messages (e.g., public warning messages, emergency alert messages, etc.) in a communication network, e.g., a 3GPP based cellular communication network, involves several steps. These may comprise receiving the message, determining whether the message is to be distributed, determining the communication resources to be used for distribution, and finally, transmitting the message. This process may be carried out by one or more relay units (e.g., UE-to- Network relay, UE-to-UE relay, gateway UE, also sometimes called "relay nodes") within the network. In embodiments, the relay units may be used for the distribution of emergency messages. They may receive an emergency message or an indication (e.g., a SIB containing an emergency message or a flag indicating the availability of an emergency message) thereof through a first data or communication interface (e.g., a Uu interface between a UE and a base station of a cellular network), and then determine whether the emergency message or an indication thereof is to be distributed further via a second data or communication interface (e.g., PC5 communication interface or other sidelink communication interface between UEs in a cellular system). The relay units may also determine the communication resources to be used to distribute the emergency message or the indication thereof. In an example, a relay unit may determine whether the emergency message or the indication thereof is to be distributed by using broadcast and/or groupcast communication over the second data or communication interface, determining communication resources to be used to broadcast and/or groupcast the emergency message or indication thereof over the second data or communication interface, and broadcasting and/or groupcasting the emergency message or indication thereof over the second data or communication interface by one or more relay units.

In this description, whenever the term "emergency message" is used, this may also be used to indicate any message that may contain the contents of an emergency message or an encapsulated emergency message. Some examples of emergency messages are messages constituting or containing an ETWS/CMAS message.

It is noted that throughout the present disclosure only those blocks, components and/or devices that are relevant for the proposed data distribution function are shown in the accompanying drawings. Other blocks have been omitted for reasons of brevity. Furthermore, blocks designated by same reference numbers are intended to have the same or at least a similar function, so that their function is not described again later.

Fig. 1 schematically shows a block diagram depicting an implementation of an example of a system for distributing emergency messages in a communication network. In this method, one or more relay units 100 receive an emergency message or an indication thereof through a data interface or a communication interface 110 (i.e., the above first data or communication interface). These relay units 100 then determine in a processing unit 120 based on a set of criteria whether or not the emergency message or the indication thereof is to be distributed via a sidelink communication interface 130 (i.e., the above second data or communication interface (e.g., a PC5 interface)). Following this, the relay units 100 identify communication resources to be used to distribute the emergency message or the indication thereof via the sidelink communication interface 130. Finally, the emergency message or the indication thereof is transmitted via the sidelink communication interface 130.

This process can be executed by an apparatus or a system that includes a processor executing a set of codes to control functional elements of an apparatus. Alternatively, certain processes can be performed using special-purpose hardware. Generally, these operations are performed according to the methods and processes described in the embodiments herein. In some cases, the operations described herein may be composed of various sub-steps, or are performed in conjunction with other operations.

Fig. 2 illustrates an example of a method 500 for distributing emergency messages in a communication network according to various embodiments. In some examples, these operations may be performed by one or more relay units. Additionally or alternatively, certain processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with embodiments or examples described herein. In some cases, the operations described herein may be composed of various sub-steps, or may be performed in conjunction with other operations.

At operation 505, the relay units receive an emergency message or an indication thereof (e.g., a paging message containing a flag indicating the availability of an emergency message) through a data interface or a communication interface (i.e. the above first data or communication interface). The relay units may then determine at operation 510 based on a set of criteria whether or not the emergency message or the indication thereof is to be distributed via a sidelink communication interface (i.e. the above second data or communication interface). At operation 515, the relay units may determine communication resources to be used to distribute the emergency message or the indication thereof via the sidelink communication interface. Determining the communication resources may include determining a time and/or frequency and/or number of times to transmit the emergency message or an indication thereof that maximizes the chance of other devices (e.g., a remote UE in idle or inactive mode) to receive the emergency message or an indication thereof. This may be done at a time slot that may depend on the time slot when the relay received the emergency message or an indication thereof or received a paging or RRC or DCI/SCI message preceding the emergency message or indication thereof, and a pre-configured first time delay. The relay units may also determine to have a second time delay between sending an indication of an emergency message (or the emergency message itself) over the second data or communication interface, and sending the actual emergency message (or a retransmit of the emergency message) over the second data or communication interface. The relay units may then transmit the emergency message or the indication thereof via the second data or communication interface at operation 520. At operation 525, the relay units may transmit the emergency message (or a retransmit of the emergency message) with the second time delay determined in operation 515.

Creating an ad-hoc network to distribute emergency messages

In an embodiment that can be combined with any of the other embodiments or used independently , emergency alerts may be sent to UEs in a locality for example using CBS. However, a UE may not receive the alert and may not be able to communicate, though other UEs nearby may be able to do so. Receipt of an emergency alert by a UE may trigger it to initiate the formation of an optimised local ad-hoc network (e.g., a D2D mesh network) which connects any (currently) unconnected users, forwards to them the alert and the ad-hoc network may then remain in place for a defined time period to support their subsequent communications (which may be critical due to an emergency situation). To this end, if a UE (which may be in idle mode when receiving an emergency alert and which may not be connected to the communication network directly over Uu or indirectly via a relay node) receives an emergency alert or indication thereof, the UE may initiate a discovery process to discover nearby UEs that may be capable of acting as relay node (e.g. UEs that make themselves discoverable as 5G ProSe UE-to-Network Relay or UE-to-UE relay) and/or remote units (e.g. UEs that make themselves discoverable as 5G ProSe Remote UE) and/or other units that are capable of D2D connection (e.g. UEs that make themselves discoverable as 5G ProSe D2D UE). During or after discovery, the UE may initiate D2D connection setup with such discovered device (e.g., via PC5, or via a non-3GPP link (sidelink) such as Wi-Fi or Bluetooth, whereby a Wi-Fi "sidelink" connection may be established via a Wi-Fi access point or directly (e.g., through Wi-Fi Direct/Wi-Fi Aware)). As a result, the UE may change to connected mode if the relay node can connect to the communication network. During discovery and/or after connection setup with a relay node, remote unit or other units capable of D2D connection, the UE may broadcast or groupcast or unicast the emergency alert to such discovered or D2D connected device. Note that the discovery messages used for the above discovery procedures may include an indication of an emergency alert message or the contents of an emergency alert message as part of its payload. If the UE forwards the alert to other devices, it is considered to be a relay unit (as described earlier).

The connecting network base station (BS) or a core network function of the communication network may assist by providing information and coordination to the UEs or other relay units to form the ad-hoc network, which can be done through the UEs forming the ad-hoc network and (mutually) updating a (distributed) database. The timing and sequencing of network connections may be performed so as to minimize mutual interference, particularly in setup, minimize the D2D hops a UE not connected to any BS requires and maximize the network robustness by e.g. maintaining at least two links for each UE and/or by selecting one or more UEs (that may act as relay units)to use for connecting to the cellular network on the basis of the reliability of their connection.

Each device (e.g., relay unit or end device) in the ad-hoc network may run its own optimization process for the establishment and maintenance of the ad-hoc network, coordinated with the other devices in the D2D network either by a distributed jointly maintained connection status database or with the BS or core network function connected to that ad-hoc network holding, updating and maintaining this connection status database. As UEs establish D2D connections, the network generation plan is integrated between the connected devices. Sequence to sequence algorithms can be used to determine and time the connections established.

In an example, when an emergency communication is received, a relay unit (e.g., UE) which has received it starts a coordinated process of device discovery of other relay units or end devices (i.e., UEs receiving the emergency message but that do not further forward the emergency message) by discovering devices that can be connected by D2D (e.g., via PC5, or via a non-3GPP link (sidelink) such as Wi-Fi or Bluetooth, whereby a Wi-Fi "sidelink" connection may be established via a Wi-Fi access point or directly (e.g., through Wi-Fi Direct/Wi-Fi Aware)) and comparing the discovered devices to entries in a jointly maintained connection status database of already connected relay units and/or end devices (and/or the existing D2D connections already established within that network) to determine if they are already part of the ad-hoc network (in which case their connection priority is set to low).

In examples, the connection status database may be maintained by the communication network (e.g., a local BS or an access and mobility management function (AMF) of the core network) or may be distributed across relay units or end devices and coordinated locally within the already established ad-hoc network using a distributed jointly updated connection database.

If not part of the existing ad-hoc network, newly discovered relay units' or end devices' connection priority may be set to high.

An optimization algorithm may then be run to determine an ordering of the new connections to be established from all relay units and/or to all end devices within that ad-hoc network within the context of previous connections already established and operating. Using the connection priorities, this optimization algorithm can be used to add to and prune connections in order to maximize the ad-hoc network operations and robustness, which for example chooses suitable cellular connected relay units as prime nodes in the network; ensures redundant connections to each relay unit or end device within the ad-hoc network; minimizes the number of hops (from cellular connected relay unit to only D2D connected devices); selects and schedules relay units or end devices to perform device discovery; and/or minimizes the channel interference during connection set-up and use.

Any newly discovered relay unit or end device which is not already in the network may be queried over the new connection to it to determine if it has received the emergency alert. If it is found not to have received the emergency alert, then a suitable relay unit (e.g., generally the one that has just established a connection to it) may be chosen to forward the emergency alert to that device, and the new device may now be fully added to the ad-hoc network. Receipt of the emergency alert may then trigger the new device to perform a D2D device discovery process as part of the ad-hoc network it is now connected to and so on. If a newly discovered device is already part of another ad-hoc network, then the networks may coordinate to fuse, including merging their connection status databases and re-optimizing the expanded network for operations and robustness.

After a defined period of time from receipt of the emergency alert message (or period time after D2D connection setup) or based on a message from the communication network, the ad-hoc network may close down its connections and cease to operate. The period of time may be based on a pre-configured policy provided to the relay units by the network.

Additional protocols may be required in the BS as well as UEs and other relay units for the emergency alert message to initiate the construction and maintenance of the ad-hoc network, coordinate the connection plan between the local UEs and forward the alert message.

In an embodiment that can be combined with any of the other embodiments or used independently, a relay unit may establish an ad-hoc routing network (which may be temporary in nature e.g. for a certain limited period) with one or more devices (e.g., UEs or other relay units) reachable by the relay unit, to allow for further updates from the communication network or transmission of further segments of a segmented message to be forwarded and received by devices that are reachable by the relay unit. This may be achieved by a relay unit actively setting up a communication connection (e.g., after ProSe discovery via PC5) with nearby devices. In addition, such (temporary) ad-hoc network could be used by the devices connected to the ad-hoc network (e.g., the UEs or other relay units reachable, possibly through multiple hops, by the relay units in the ad-hoc network) to initiate communication with the communication network or other nearby UEs (e.g., to make a phone call to their family members). The communication network to which the relay unit is connected (e.g., by a base station (BS) to which the relay unit is directly/ind irectly connected or a core network function such as AMF, policy control function (PCF) or session management function (SMF)) may configure/set a minimum life-time and/or configure traffic policies of the ad-hoc network. For instance, if a first relay unit decided to forward a first emergency message or indication or fragment thereof and a second relay unit did not (e.g., because the first relay unit had transmitted before), the following emergency message or fragment thereof or other subsequent communication may also be forwarded by the first UE and not by the second UE, whereby this behaviour may be configured by means of a policy. The relay unit(s) may inform the communication network when/after an ad hoc routing network is established about the existence and/or information about the network (such as number of nodes, topology, coverage area, etc.), in order to improve future planning and/or to allow determining spots where the emergency message may have not been delivered yet. The communication network can then also instruct the relay unit(s) to dismantle the ad-hoc network, e.g., if it is not needed anymore. The period of time that the ad-hoc network needs to be active (e.g. period time after receiving an emergency message or after D2D connection setup) may be based on a pre-configured policy provided to the relay units by the network.

The ad-hoc network may not only be limited in time, but may instead / in addition be limited to certain areas (e.g., areas with lack of coverage). Hence, in a related embodiment, relay units may use local knowledge to determine where this ad hoc network may be used to distribute emergency messages. Local knowledge may include information from a previous positioning operation in which the location of the relay unit itself is determined and/or in which the distance and/or angle and/or location of nearby nodes (e.g., anchors) is shared/determined. If the local knowledge indicates that the relay unit and/or the nearby nodes are inside or outside a certain pre-determined area (e.g. based on policy including location/area information received from the network), then it may determine not to distribute the emergency message further and/or determine not to set up an ad-hoc network connection between the respective relay unit and nearby nodes.

In a related embodiment, message propagation and reception may be restricted by tracking area and/or geographical area and/or service group (e.g., only people on a certain road need to be informed about emergency road conditions ahead; only emergency workers need to be put on standby alert in the event of a potential major incident; etc.).

In an embodiment variant, message propagation and reception may be restricted/determined by the context of the relay unit. For instance, if a UE is between a first city (e.g., Eindhoven) and a second city (e.g., Maastricht) and it determines that it is heading towards the first city, then the relay unit may or may not relay emergency messages for an accident that is in the direction to the second city. For instance, based on a battery level that is too low, or a coverage status that is excellent, the relay unit may not forward the message.

In a related embodiment that can be combined with any of the other embodiments, an ad-hoc network or ad-hoc emergency network may include nodes (e.g., relay units) attached to other cells or to other networks. To this end, nodes may be configured with a set of allowed/disallowed cells or networks and/or may be configured by one of the networks (e.g. Home PLMN of the UE) or by a master database (e.g. operated by the government) with policies on when/where/how to forward emergency alert message and/or when/where/how to setup an ad-hoc network as described in other embodiments.

In another embodiment that can be combined with any of the other embodiments or implemented used independently, a relay unit may check a local policy and/or verify a received emergency message or indication thereof before creating an ad-hoc network for distributing the message to other devices. This may be done to ensure that the message is authentic, relevant, and not outdated. The local policy may be provided by the communication network or by another authority (e.g., government, public safety agency, etc.) and may include specific criteria for validating the emergency message or indication thereof. For example, the local policy may specify:

- The source or sender of the message or indication (e.g., a trusted base station, a core network function, a public warning system, etc.)

- The format or structure of the message or indication (e.g., a standard protocol, a header with a signature, a checksum, etc.)

- The content or type of the message or indication (e.g., a predefined category, a keyword, a code, etc.)

- The time stamp or validity period of the message or indication (e.g., a date and time, a duration, a sequence number, etc.)

The relay unit may compare the received message or indication with the local policy and/or perform a verification process (e.g., decrypting, decoding, checking, etc.) to determine if the message or indication meets the criteria. If the relay unit determines that the message or indication is valid, it may proceed to create an ad-hoc network with nearby devices (e.g., UEs or other relay units) to distribute the message or indication further, as described in other embodiments. If the relay unit determines that the message or indication is invalid, it may discard the message or indication and/or report it to the communication network or another authority. Alternatively, the relay unit may notify the user of the device about the invalidity of the message or indication and ask for confirmation or permission to create the ad-hoc network. The relay unit may also update its local policy based on the feedback from the communication network or another authority or based on the changes in the situation or environment. Y1

In the following embodiment, the ad-hoc network (called D2D network) is portrayed as a single level system, but it could be structured as a hierarchically structured network (with sub-networks and connection/head nodes).

Fig. 3 schematically shows a block diagram showing a system and process flow for creating an ad- hoc network for distributing emergency messages.

In the embodiment of Fig. 3, an emergency alert message relay and communications network system is provided, that comprises a base station (BS) with a transmission capability (EAM Tx) of sending emergency alert messages (EAM) to cellular connected UEs (UE1, UE2) in addition to cellular communications (CC) and supporting one or more D2D networks. This can be achieved by optionally, maintaining and updating a connection status database (CS-DB) for each connected D2D network, including running a D2D connections update algorithm (D2D UA) on the connection status database and communicating desired required connections to the UEs within that connected D2D network.

The UEs are capable of bidirectional communication with the base station if a link can be established e.g., via the cellular communication, and comprise an EAM reception and display functionality (EAM Ex/D) to receive and display (and/or otherwise signal) emergency alert messages.

Furthermore, the UEs are configured to establish D2D connections including D2D network functions (D2D NF) such as device discovery, D2D connection, relaying and communication, to receive an emergency alert message and initiate communications activities using e.g. an EAM activities controller as a result of the message receipt, to host a distributed connection status database (CS-DB), to perform updates on this database, and/or to run a D2D connections update algorithm (D2D UA) on this database.

Additionally, the UEs may be configured to remove or add D2D connections as requested by the BS or in response to changes in the connection status database, to query another UE over a connection (e.g., a D2D connection (D2D-C)) to determine if it has received a specific emergency alert message, to respond to a query determining if a specific emergency alert message (EAM) has been received (e.g., using a unique identifier for that specific message)

Moreover, the UEs may be configured to forward a specific emergency alert message to another UE over a D2D connection (D2D-C) where this D2D-supplied EAM is treated in a similar manner as an EAM received from the cellular network (including aspects of display to the user and preventing other phone use until the message is acknowledged).

The connection status database may be distributed and jointly maintained by all UEs within a D2D network (or part thereof, e.g. a database with the status of all discoverable/discovered UEs in vicinity or the UEs in a certain area) or may be centralized within a base station or core network of the communication network. It may be configured to allow database synchronization (DB-SYNC) via cellular communications and/or D2D communications and may have installed security measures to protect itself against malign manipulation of updates.

Furthermore, the connection status database may be configured to maintain a list of unique identifiers for all UEs within the D2D network (or part thereof, e.g. a database with the status of all discoverable/discovered UEs in vicinity or the UEs in a certain area) plus, for each listed UE, information about whether they have received the EAM and whether they are connected or can connect to the cellular network, optional information about location and movement, and optional information about relevant device capabilities, a list of D2D connections already established in the D2D network plus statistics on the reliability of these connections and their changes over time, and a list of newly discovered UEs and their connection priorities including if they wish to connect or not.

Additionally, the connection status database may be configured to perform a merge operation with another disjoint connection status database, thereby effecting a merge of two D2D networks (or part thereof).

The D2D connections update algorithm may for example be implemented using a suitable optimization process or a artificial intelligence (Al) algorithm such as a sequence-to-sequence model, with the capability of analyzing the connection status database and generating a connection change plan which optimizes the D2D network to minimize the D2D hops a UE not connected to the cellular network requires to communicate with the cellular network, and/or to maximize the D2D network robustness by e.g. maintaining at least two links for each UE, where these links have a high reliability, and/or to choose D2D connections on the basis of their current and future predicted reliability, and/or to choose new connections to establish and old connections to prune in order to minimize mutual interference between connections, (particularly during initial setup, e.g., by sequencing the establishment of connections), using connection reliability data and optionally using location and movement data, and/or to select UEs which connect to the cellular network on the basis of the reliability of their cellular connection and/or their position within the D2D network, ensuring that cellular communications channels are efficiently utilized within the D2D network and not overloaded.

In examples, the connection change plan may provide at least one UE to perform device discovery, establishment of a new connection between UEs in the D2D network (or with a UE not in the network but found using device discovery) with a specific timing, channel selection etc., pruning of an existing connection within the D2D, establishment of a BS (cellular) to UE connection, pruning of a BS (cellular) to UE connection, and merging of another D2D network with this network, including merging their connection status databases.

Fig. 4 schematically shows a flow chart representing a method for creating an ad-hoc network for distributing emergency messages according to an embodiment.

Note that not all steps (or sub-steps) may be mandatory and the order of the (sub)steps may be implemented differently. The left column of steps relates to a connected UE (UE-C) while the right column of steps relate to an unconnected UE (UE-UC).

In step S401, a BS receives from an emergency alert message source an EAM with contents and a unique identification number._The BS sends the EAM to all cellular connected UEs using e.g. a cell broadcast service.

In step S402, the connected UE receives the EAM and shows (displays) it to the user e.g. as per standards for emergency alert display (DISP EAM). Unconnected UEs do not receive (NR) the EAM (step S402a). The UE may then perform the following communications tasks e.g. by using the EAM activities controller:

In step S403 (CS-DB), it adds itself to a newly formed connection status database with its current cellular connection, including all existing D2D network connections it already has (if any).

In step S404 (DD), it initiates device discovery e.g. by using D2D communications and, possibly dependent on actions generated by the D2D connections update algorithm (in order to avoid interference arising from many UEs performing device discovery simultaneously), to determine other local UEs to which it can connect, including determining their unique identity. Optionally, in step S404a, a discovered unconnected UE can accept or reject a requested D2D link. In the latter case, the discovered unconnected UE may indicate that it does not wish to be added to a network, in which case the UE may be entered into a list of non-cooperative UE in the connection status database.

In step S405 (D2D UA), the newly discovered UEs are added to the list of newly discovered UEs in the connection status database. If they are not yet in the list of established UEs, then the priority status of the newly discovered UE may be set to 'high'. To achieve this, the UE may run the D2D connections update algorithm on the connection status database and perform the relevant resulting actions. For example, this may return an action for that UE to form a connection to a newly discovered unconnected UE.

In step S405a (D2D CE), a D2D connection to the newly discovered unconnected UE is established and this is entered into the connection status database. The new UE may synchronize the connection status database and may start updating it with data (e.g., received signal strength, location, movements etc.). If it is part of a different D2D network, the networks may be merged. In step S406 (EAM ST REQ), the UE queries the newly discovered UE to determine if it has received the EAM (e.g., by using the unique number of the EAM as a query) and enters the result in the connection status database. The UE may run the D2D connections update algorithm on the connection status database and performs the relevant resulting actions. If the newly discovered UE has not received the EAM, an action may be returned for that UE to send the EAM to the newly discovered UE.

In step S406a (EAM RX/D), the EAM is received and displayed to the user of the newly discovered unconnected UE and this UE may now initiate a process (e.g., by its EAM activities controller) with the synchronized connection status database within the same D2D network to update the database with communications statistics, movements etc. and the databases may be kept updated.

The newly discovered UE may then gain a distributed copy of the connection status database and/or start a process of establishing an emergency alert message relay and communications network system (e.g. by forming an ad-hoc network as described in other embodiments).

According to another outcome of the query of step S406, the EAM has been received by the newly discovered UE and it is part of another D2D network (minimally just itself connected to a base station). In this case, an action may be returned to merge the two connection status databases to form a single D2D network. A coordination needs to be established between the two networks to ensure that the merge process is correctly handled by both networks together such as to ensure all the UEs in the different D2D network consent to form part of this network. The joint network can be restructured in an efficient manner which maintains robustness and reliability (this may be performed by running the D2D connections update algorithm on the merged connection status database and ensuring that the resulting actions are possible and efficient).

In steps S407 and S407a (DB DU/SYNC), on a regular basis, the D2D connections update algorithm is run on the connection status database to return actions for optimizing the D2D network and dealing with changes in the location and structure or the UEs forming that network. The UEs may constantly update the connection status database based on received signal strengths of its D2D and cellular connections and optionally its location and movement. Furthermore, the UEs within the D2D may synchronize their distributed connection status database.

At the end of a predetermined time period (that may have started at the time of the receipt of the EAM), the EAM-initiated D2D network may be closed (while other unrelated D2D networks involving the UEs may be unaffected).

Fig. 5 schematically shows a diagram showing an example network topology with five UEs UE1 to UE

5 and related distributions of emergency messages or indications thereof. In the upper topology of Fig. 5, an EAM is sent and received by connected UEs UE1 to UE3 which are connected to the sending BS via respective cellular connections, while no D2D connections are stored in the connection status database CS-DB. As a result, the alert is displayed by three UEs UE1 to UES only.

In the lower topology, a D2D network comprising all UEs UE1 to UE5 has been established and maintained in the connection status database CS-DB so that the EAM can be forwarded via D2D connections (sidelink connections) between UE1 and UE2, UE2 and UES, UES and UE4, UES and UE5, and UE4 and UE5. As a result, the alert is displayed by all five UEs UE1 to UE5.

In an embodiment that may be combined with any of the other embodiments or used independently, in addition to the above basic functions, the relay units may perform an assessment, based on a set of criteria, about whether or not to distribute an emergency message or indication thereof. These criteria may be configured in the relay units by means of policies that may be provisioned by the communication network (e.g., by a Policy Control Function (PCF)). Network policies may be sets of conditions, constraints, and settings that allow to designate e.g. who is authorized to connect to the network and the circumstances under which they can or cannot connect. Additionally or alternatively, they may be also configured with a corresponding protocol that determines their behaviour in this regard (e.g., as part of a non-access stratum (NAS) message exchange with the AMF or other network service/function in the communication network, or as part of a protocol between the device and a Public Warning System or a Public Safety Answering Point (PSAP) or as part of a protocol between the device an Application Function (AF) communicating e.g. via a Network Exposure Function (NEF) with/through the communication network. This adds an additional layer of complexity to the process, but also provides a degree of flexibility and adaptability that can be beneficial in certain situations. In an example, the criteria to determine whether or not an emergency message or an indication thereof is to be distributed are provided as part of a paging message or RRC message or DCI message or MAC CE message sent prior to the emergency message or indication thereof. In another example, the emergency message or indication thereof includes supplementary data (e.g., additional criteria or information to assist in evaluating criteria) to help the apparatus to decide whether the message or indication thereof is to be distributed or not and/or how it is to be distributed.

Additionally or alternatively, the relay units may determine one or more criteria by themselves and perform their own assessment about whether or not to forward the emergency message or indication thereof and may provide these criteria to the communication network or to other relay units using a configuration protocol. Additionally or alternatively, the criteria determining the behaviour of the relay units in sending emergency related messages may be configured by means of a guideline (e.g., policy or other pre-configuration). This can help to standardize the process and ensure that all units in the network are operating in a consistent and coordinated manner.

In an embodiment that may be combined with any of the other embodiments or used independently, the relay units may use a variety of strategies to manage the distribution of emergency messages. These strategies may include a pre-emptive communication strategy (e.g., distribute a message if it knows about one or more nearby devices that are out-of-coverage of the network) or a conflict prevention strategy (e.g., only distribute a message if it knows that it will not interfere with other entities (e.g., RAN nodes or other relay nodes). These strategies can help to ensure that the messages are distributed efficiently and effectively, without unnecessary delays or conflicts. These strategies may be implemented by the criteria configured on and/or used by the relay unit, e.g., the criteria may include a set of conditions (e.g., minimum or maximum amount of nearby devices that have recently try to discover the respective relay unit, or a minimum or maximum signal strength/quality of message received from nearby base stations or other relay units).

In an embodiment that may be combined with any of the other embodiments or used independently, determining the communication resources for distributing an emergency message or indication thereof may include determining a time and/or frequency and/or number of times to transmit the emergency message or an indication thereof that maximizes the chance of other devices to receive the emergency message or an indication thereof.

In an embodiment that may be combined with any of the other embodiments or used independently, the relay unit that has received an emergency message or indication thereof may initiate a discovery process (e.g., ProSe model B discovery over PC5 interface) and forward and/or transmit the emergency message or indication thereof during or after discovery of UEs that are currently not yet connected to the relay unit, in order to reach UEs that are currently unattached to the network or the relay unit. To this end, the relay unit may send discovery and/or paging and/or emergency and/or scheduling (e.g., SCI) messages containing the emergency message or indication thereof. Such discovery and/or paging and/or emergency and/or scheduling messages may contain a pointer to a broadcast and/or groupcast of the emergency message (e.g., ETWS/CMAS) or other messages to be broadcasted by the relay unit. Additionally or alternatively, the relay unit may send a discovery and/or paging and/or emergency and/or scheduling message to a closed group or a single user, e.g., just the remote nodes attached to a selected relay unit, or UEs sharing a group identity, group key and/or address. This behaviour for sending of emergency related messages may be configured by means of a policy. In an embodiment that may be combined with any of the other embodiments or used independently, the relay units may send discovery and/or page messages and/or page alert and/or RRC and/or SCI and/or MAC CE messages containing information about the emergency message (e.g. type of emergency message) and/or the emergency message contents to a specific group or individual user. This can be useful in situations where the emergency message is relevant to a specific group or individual. To this end, the discovery and/or paging and/or page alert and/or RRC and/or SCI and/or MAC CE message may include information about a specific group identifier or UE identifier or user identifier to which the emergency message is meant to be sent. This information may be configured by a SIB that the relay unit received from a gNB, wherein the SIB contains information a specific group identifier or UE identifier or user identifier to which the emergency message is meant to be sent. The relay units and remote units may be configured with a group key that is used to protect (e.g. through encryption, integrity protection) the emergency message.

In an embodiment that may be combined with any of the other embodiments or used independently, the apparatus may transmit the emergency message (e.g., its contents and/or type) or an indication thereof (e.g., a flag indicating the availability of an emergency message) embedded in a PC5 discovery message (e.g., ProSe model A/B discovery message) or PC5 connection setup message (e.g., Direct Communication Request message) transmitted over the PC5 interface. This can help to alert other units in the network to the presence of an emergency message that are currently not connected or not listening via other means to a RAN node (e.g., base station), e.g., because it is out-of-coverage, or to a relay node (e.g., because it has not synchronized yet with the relay node or it has not previously discovered the presence of the relay node), and can facilitate the rapid distribution of the message. This can also be used to facilitate setting up an "emergency network", since devices may wish to connect to find out more information about the public warning and/or emergency and/or people start making calls all at once to call their relatives. Setting up such an emergency network could prevent overload situations of the RAN nodes. A good example would be a tsunami warning where lots of people may be worried.

In an additional embodiment that may be combined with any of the other embodiments or used independently, the relay node may transmit a PC5 connection setup message as soon as a remote node/unit (e.g. 5G ProSe Remote UE) tries to discover it (e.g., by sending a ProSe Model A/B discovery message that may include a particular identifier for this purpose, e.g. a relay service code reserved/assigned for the purpose of setting up such an emergency relay/ad-hoc network to distribute an EAM and/or for temporarily enabling communication via this emergency relay/ad-hoc network to the cellular core network) or based on instructions from the network (e.g., from a base station or core network function) that may know about the presence of a particular device in the area (e.g., because it was previously registered to the network and may have just gotten out-of-coverage). To this end, these instructions from the network may include an identifier of such a particular device in the area and/or a resource schedule to use for reaching that particular device (e.g., by means of sending a PC5 connection setup request).

In another embodiment that may be combined with any of the other embodiments or used independently, a remote node (e.g. 5G ProSe Remote UE, also called remote unit or remote device in this disclosure) that receives such an emergency message or indication thereof may be configured and/or requested and/or triggered to set up a PC5 connection with the relay node from which it received the emergency message or an indication thereof. Once a remote node is connected to a relay node via a PC5 connection it may be removed from the list of devices to which the emergency message or indication thereof is to be further distributed. Such list of devices may be stored in the relay nodes, or may be centrally stored in the network (e.g., every relay node that has successfully reached out to a remote device may inform the network of an identity of such remote device and/or the remote device may register to the network or send a message to the network via the respective relay node to indicate its presence and/or indicate that it has successfully received the emergency message or indication thereof). A relay node may be connected to such central storage (e.g., the connection status database of Fig. 3) that indicates the identities of remote devices that may or may not have been reached yet and/or may receive updates from the network with one or more identities of remote devices that may or may not have been reached yet that can be used by the respective relay node in the distribution of emergency messages or indications thereof.

In an embodiment that may be combined with any of the other embodiments or used independently, the relay units may transmit the emergency message or indication thereof to a remote unit in idle or inactive mode at a time slot that may depend on the time slot when the relay received the emergency message or indication thereof or received a paging or RRC or DCI/SCI message preceding the emergency message or indication thereof, and/or a pre-configured first time delay. Additionally or alternatively, the apparatus may also determine to have a second time delay between sending an indication of an emergency message (or the emergency message itself) over the PC5 communication interface, and sending the actual emergency message (or a retransmit of the emergency message) over the PC5 communication interface. This can help to ensure that the message is distributed to all relevant units in the network, even those that are not currently active.

In another embodiment that may be combined with any of the other embodiments or used independently, the relay units may transmit a discovery and/or paging and/or page alert and/or RRC and/or SCI and/or MAC CE message containing an indication of and/or a pointer to a broadcast and/or groupcast of the emergency message transmission to be made by a relay unit to one or more remote units or other relay units, whereby the discovery and/or paging and/or page alert and/or RRC and/or SCI and/or MAC CE message may include information about the timing or type of the emergency message to be sent. This can help to direct other units in the network to the presence/location of the emergency message, facilitating its rapid distribution. The message indication and/or pointer may also carry a (temporally or geographically) unique identifier that can be used to label the emergency message and that can help other units determine whether they have already received the emergency message and can thereby skip the indicated broadcast or groupcast. The RRC message may be or may contain a SIB that the relay unit received from a gNB, wherein the SIB contains information about the timing or type of the emergency message to be sent by the relay unit.

In an embodiment that may be combined with any of the other embodiments or used independently, if a UE (e.g., Remote UE in case of ProSe) gets out of coverage it may wake up once in a while to try to listen for nearby gNBs by listening to MIB/SIBs. Thus, assuming that this is somewhat synchronised with the gNBs, if a gNB knows a discontinuous reception (DRX) schedule from a previous connection with that UE, it may inform a relay unit about it, and ask the relay unit to broadcast it in synchronism with the transmission of SIB6/7/8 of the gNB. This may be done, e.g., by transmitting in another direction (in order to not interfere with the gNB, e.g., by using beamforming). Alternatively, the relay unit may use a different schedule and/or the remote UE may increase the number and length of the paging occasions (POs) to make sure that a UE would hear the message.

In an embodiment variant, if a UE (e.g. remote node or relay unit or UE that may become a relay unit) gets out of coverage it may wake up once in a while to listen to model A discovery messages of nearby relay UEs, according to the sidelink discovery resource pool that has been configured on the UE. Thus, model A discovery may be extended with an indication or contents of an emergency message.

In an embodiment variant, if a UE (e.g. remote node or relay unit or UE that may become a relay unit) gets out of coverage it may wake up once in a while to listen to group messages over sidelink, according to the sidelink group message resource schedule. Thus it may be able to receive a groupcast containing an emergency message or indication thereof.

In an embodiment variant, if a UE (e.g. remote node or relay unit or UE that may become a relay unit) gets out of coverage it will wake up once in a while to transmit model B discovery messages to find nearby relay units. If that happens, then the relay unit may immediately report that an emergency message is available, e.g. as part of the payload in the model B discovery response transmitted by the relay unit to the UE. In an embodiment, a method for distributing emergency messages in a communication network is provided. The method comprises receiving an emergency message or indication thereof through a data interface or a first communication interface (e.g., Uu interface between a UE and a base station of a cellular network) by one or more relay units, determining based on a set of criteria whether or not the emergency message or an indication thereof is to be distributed via a second communication interface (e.g., PC5 communication interface or other communication interface (e.g., non-3GPP interface such as Wi-Fi or Bluetooth) of the relay unit), determining communication resources to be used to distribute the emergency message or an indication thereof (e.g., via the PC5 communication interface), and transmitting the emergency message or an indication thereof via the PC5 communication interface or other communication interface in the determined communication resources, whereby determining the communication resources may include determining a time and/or frequency and/or number of times to transmit the emergency message or an indication thereof that maximizes the chance of other devices to receive the emergency message or an indication thereof. The relay units may be configured with a corresponding protocol or guidelines (e.g., policies) determining their behaviour, e.g. to perform an assessment (e.g., based on a set of criteria or a given probability, indicated by the corresponding protocol or guidelines) whether to forward the message or not. The one or more relay units may use a pre-emptive communication strategy or a conflict prevention strategy. Also, this behaviour may be configured by means of a corresponding protocol or guidelines/policies.

In a related embodiment, the one or more relay units may determine whether the message is to be using groupcast and/or broadcast over the PC5 communication interface. The relay units also determine the communication resources to be used for groupcasting/broadcasting the message in the communication interface. The one or more relay units may broadcast/groupcast the message in the communication interface by using the determined communication resources.

In a related embodiment, the method may further include sending or forwarding a paging message addressed to a remote unit in idle or inactive mode at a time slot that may depend on the time slot when the relay unit received the paging message and a pre-configured time delay by the one or more relay units.

In a related embodiment, the method may include sending discovery and/or page alert messages containing a pointer to a broadcast/groupcast of the emergency alert message to be made by the one or more relay units.

In a related embodiment, the method may include sending a discovery/ page message to a specific group or individual user by the one or more relay units. In an embodiment that can be combined with any of the other embodiments or used independently, the emergency message or indication thereof may include supplementary data to help the relay unit to decide whether the message is to be (re-)broadcasted (or groupcasted) or not and how it is to be (re-)broadcasted (or groupcasted). For example, the (emergency) message may include metadata to help the relay unit to decide whether the message is to be (re-)broadcasted (or groupcasted) or not and how it is to be (re-)broadcasted (or groupcasted). For instance, paging messages may include a flag determining whether the paging message is to be (re-)broadcasted (or groupcasted) or not or whether a discovery process is to be performed. For instance, an emergency message may include a threshold determining whether a relay unit should (re-)broadcast (or groupcast) it (e.g., when the signal strength of the received emergency message is lower than the threshold value). The supplementary data may be determined by the communication network and transmitted e.g. by the core network to the relay unit and/or the supplementary data may be determined by the relay unit itself and transmitted to other relay units.

In another embodiment that can be combined with any of the other embodiments, not only emergency messages themselves but also paging or discovery messages may be transmitted/forwarded because otherwise UEs in idle or inactive state may not be able to receive forwarded emergency messages.

In another embodiment that can be combined with any of the other embodiments, relay units forwarding an emergency message or indication thereof may revert to RRC_CONNECTED state to send the emergency message. Nodes that do not forward the emergency message may not need to revert to the RRC_CONNECTED state except if necessary in order to receive the message.

In another embodiment that can be combined with any of the other embodiments or used independently, relay units may transmit and/or forward and/or resend the emergency message or indication thereof n times, wherein the message may be labelled so that nodes that receive the message more than once can quickly identify it. This behaviour for sending of emergency (related) messages (e.g., number of times an emergency message with certain label may be received) may be configured by means of a policy (e.g. received from the core network) or through configuration information received e.g. from the gNB and/or other relay unit, for example through configuration information about the number of repetitions included in the supplementary data (that may be sent as part of the emergency message or indication thereof) or RRC/SIB message. The policy and/or configuration information may contain information about the delay between the various repetitions, information about which Modulation Coding Scheme (MCS) and/or frequency and/or resources and/or timing to use for the various repetitions.

In another embodiment that can be combined with any of the other embodiments or used independently, an emergency message or an indication thereof may be sent via multi-hop relay communication (e.g., with a maximum hop count), whereby a hop count may be added and/or appended and/or prepended to the emergency message or indication thereof, wherein each relay unit may be configured to increase or decrease the hop count until a maximum hop count or respectively zero is reached, upon which the relay unit does not forward the emergency message anymore. In this case, a 5G ProSe UE-to-Network Relay or UE-to-UE relay acting as an intermediate relay node between a remote UE (or other intermediate relay node) and the 5G network (or other intermediate relay node) performs the duplication detection function as specified in TS 23.041 to suppress received duplicated warning messages over PC5. This behaviour for sending of emergency related messages (e.g., maximum number of hops and whether increasing or decreasing hop counter is used) may be configured by means of a policy (e.g. received from the core network) or through configuration information received e.g. from the gNB and/or other relay unit, for example through configuration information about the number of repetitions included in the supplementary data (that may be sent as part of the emergency message or indication thereof) or RRC/SIB message.

In another embodiment that can be combined with any of the other embodiments or used independently, a relay unit, according to a protocol or instruction from a network base station, may determine whether or not it is near a cell edge (e.g., a distance from a serving base station that is intended to indicate the ultimate edge of the coverage area of a cell), and based on that determination, before or after receiving an emergency message or indication thereof that it received via a first communication interface (e.g., Uu), to initiate performing an assessment whether to forward the emergency message or indication thereof via the second communication interface (e.g., PC5) and/or transmit the emergency message or an indication thereof over the second communication interface. In an example, the relay unit may perform an assessment to determine whether or not it is near the cell edge, according to a policy or instruction from a network base station (e.g., provided through RRC message such as RRC Reconfiguration message). This determination may be based on, for example, checking the channel state information (CSI) information or channel quality (e.g., reference signals received power (RSRP) or reference signal received quality (RSRQ)) against a pre-agreed threshold or measured signal strength of reference signals against a pre-agreed or configurable threshold (e.g., based on the signal strength of the received emergency message or indication thereof), or based on the number of cells from which it can monitor and/or receive SIB or other messages from. Additionally or alternatively, the determination may be based on information received from the communication network about how close they are to the cell, for example the wireless network (e.g., network base station) may keep informing relay units about how close they are to the cell e.g. by providing an estimation of the distance between the cell and the relay unit. Additionally or alternatively, the communication network may determine which UEs that may act as relay units are close to the cell edge and may instruct only the selected UEs/relay units that are close to cell edge to forward the emergency message or indication thereof (e.g. by including a list of identifiers of the selected UE/relay units) as part of the emergency message or indication thereof (e.g. as part of the supplementary data). Additionally or alternatively, the determination may be based on a positioning or ranging operation based on which the relay unit may determine its relative position and/or distance from a network base station, which it may use (e.g., based on a maximum distance threshold, or coverage map) to determine if it is near the cell edge or not.

In an embodiment, a system for distributing emergency messages in a communication network may be provided. The system may comprise one or more relay units configured to receive an emergency message or indication thereof through a data interface or a first communication interface, determine whether the emergency message or indication thereof is to be (re-)broadcasted/groupcasted via a second communication interface, determine communication resources to be used to (re-)broadcast/groupcast the emergency message or indication thereof in the second communication interface, and (re- )broadcast/groupcast the emergency message or indication thereof in the second communication interface. In a related embodiment, the relay units may be connected and controlled by an entity in the communication network (e.g., network base station), which may instruct selected relay units (e.g., those at cell edge) to forward message, e.g., based on a set of criteria configured by a policy. For example, it may only be configured to forward an emergency message or indication thereof if the relay unit is at the cell edge. A relay unit may determine that it is likely at the edge based on the signal strength of the received message, and or based on the number of cells that it can monitor and/or receive, or a network may keep informing relay units about how close they are to the cell, etc. In a particular example, the network may instruct selected relay units (e.g., those not at the cell edge or those close to other relay units) to not forward the message.

In some embodiments, the communication network may instruct relay units (e.g. a selected set of relay UEs) to forward the emergency message or indication thereof with a probability. This can help to manage the distribution of the message and ensure that it is distributed in a timely and efficient manner.

In an embodiment that can be combined with any of the other embodiments or used independently, the communication network may instruct (potential) relay units (e.g. a selected set of relay units) to forward the message with a probability p, whereby the relay units may generate a random number r. For example if r=p or r falls within an interval of values of a distribution function whereby the length of the interval determines the probability p, the relay unit forwards the message else it discards the message (which may also apply for relay units that are located at the cell edge). Which devices (e.g., relay units) retransmit may also depend on other factors, e.g., the time slot (e.g., system frame number (SFN)) in which the emergency message is transmitted), or a (random) number e.g. 1 to 10 included in a (forwarded) emergency message or indication thereof, whereby the probability p may depend on such time slot or number (e.g. relay unit only forwards if a configured value is equal to the time slot modulo a total of configured values (e.g. 1 to 10) and/or each value is given a particular configured probability that the relay unit needs to use for determining whether or not to forward the given message). The relay unit may generate a different number or time slot and may include such number or time slot in an emergency message or indication thereof that it forwards to other relay units. The relay unit may omit the same number or avoid transmitting in a time slot that would result in the same truncated value (e.g. timeslot modulo 10) by which the relay unit is configured itself. In this way the same number or truncated timeslot value is not used again, so if other relay units and remote units are configured with a different number or timeslot value, then it optimizes the chance that other relay units and remote units receive it that have not received it before whilst minimizing the amount of duplication.

Additionally or alternatively, relay units may be assigned a category and relay units may forward or not depending on the category included in the message.

In another embodiment that can be combined with any of the other embodiments or used independently, the communication network may instruct relay units (e.g. a selected set of relay UEs) to perform their own assessment about whether to forward a received emergency message (or indication thereof) or not and may configure those relay units with a corresponding policy determining their behaviour, e.g., configuring a probability or a category as in the previous embodiment. A relay unit performing its own assessment may use, for example, a Listen-Before-Talk strategy, listening for a random period to detect whether a nearby relay unit transmits and/or forwards and/or resends a packet containing the emergency message or indication thereof; if so, it may suppress its own transmission and discard the message. Relay units that suppressed their retransmission may inform the communication network or other relay units, about this (e.g., why it chose to supress the retransmission), in order to provide knowledge of alternative options to the communication network or other relay units.

In an embodiment variant, a relay unit performing its own assessment may use, for example, a collision avoidance strategy may perform random back-off before sending Discovery. If it detects discovery and/or page message sent by a nearby node, then it may perform another random back-off. After a certain number of back-offs, it may suppress its own transmission and discard the message. Relay units that suppressed their retransmission may inform the communication network or other relay units about this (e.g., why it chose to supress the retransmission), in order to provide knowledge of alternative options to the communication network or other relay units.

In an embodiment variant, a relay unit performing its own assessment may use for example, an RSRP measurement (e.g. based on a pre-configured RSRP threshhold) to determine whether or not it is near a cell edge and if it is not near (e.g. in good coverage of a base station) it may suppress its own transmission and discard the message. Relay units that suppressed their retransmission may inform the communication network or other relay units about this (e.g., why it chose to supress the retransmission), in order to provide knowledge of alternative options to the communication network or other relay units.

In an embodiment that can be combined with any of the other embodiments or used independently, once a relay unit receives an emergency message, the relay unit may start monitoring paging messages that are not addressed to it but to a different UE. Upon reception of a paging message via the Uu interface, the relay may forward and/or rebroadcast the paging message based on a policy (e.g., in which occasions and/or for which paging messages it should forward the received paging messages) and the contents of the paging message itself (e.g., whether forwarding is required or not).

In a related embodiment, the relay unit may rebroadcast the paging message received from the base station in the same paging occasion through the Uu interface so that if the UE was not in a coverage area of the base station, the UE can receive it. From this point of view, the relay unit may behave as a radio frequency (RF) repeater in which the coverage is extended.

In a related embodiment, the relay unit may rebroadcast the emergency message received from the base station in the time/frequency resources through the Uu interface so that if the UE was not in coverage of the base station, the UE can receive it. From this point of view, the relay unit behaves as an RF repeater in which the coverage is extended.

In a related embodiment, the relay unit may be an RF repeater and/or smart repeater that may or may not be under the control of the base station (e.g., an RF repeater in a non-public network), whereby the RF repeater is capable of detecting emergency messages and forwarding them if they have been configured.

In a related embodiment, the relay unit may rebroadcast the paging message received from the base station through the PC5 interface.

In a related embodiment, the relay unit may send or forward a paging message addressed to a UE in an idle or inactive mode in a time slot that may depend on the time-slot when the relay unit received the paging message and a pre-configured offset, e.g., T_sending = T_receiving + Offset and/or whereby the frequency resources may also be pre-configured. This allows a UE in idle or inactive mode to monitor paging opportunities in the Uu interface and paging opportunities in the PC5 interface wherein the paging opportunities in the PC5 interface are delayed by the offset with respect to the paging opportunities in the Uu interface.

In an embodiment, relay units may append information to a received emergency message before forwarding/(re-)broadcasting the emergency message. For example, it may be useful to share information between the members of a group of UEs and/or between member groups whereby this information may be appended to the same emergency message or transmitted in a different subsequent message. For instance, a network may send a fire alert message to nodes monitoring a forest, and nodes that detect abnormal temperature rise and/or smoke and/or light from the fire can add (e.g. append) their information to the message.

In an embodiment that can be combined with any of the other embodiments or used independently, (some) recipients (e.g., loT devices) that may have a role to play in mitigating an emergency (e.g. actuator nodes such as a sprinkler installation in case of fire hazard) may be instructed or (pre- )configured to acknowledge the discovery and/or paging message that announces the emergency message and/or may be instructed and/or (pre-)configured to acknowledge that they successfully received the emergency message.

In an embodiment that may be combined with other embodiments or used independently, the emergency message or the indication thereof or the indication to setup an emergency ad-hoc network may be received through a non-terrestrial network (NTN) device, such as a satellite or an unmanned aerial vehicle (UAV), which may act as a relay or access device for the cellular communication network. An NTN access device may be a suitable device to disseminate emergency messages or indications (e.g., when terrestrial base stations are down due to, e.g., a natural catastrophe), and it may require the selection of relay devices capable of receiving the emergency messages / indications from the NTN access device and distributing them locally and/or distributing local messages when the emergency ad-hoc network is activated. The non-terrestrial network device may transmit the emergency message or the indication thereof with a high power level or additional security features, such as encryption or authentication, to ensure that the apparatus (e.g., a UE) and other devices within its coverage area are able to receive it and determine their role in distributing the emergency message and/or local messages. For example, the nonterrestrial network device may send a paging message that contains an indication of the emergency message and/or an instruction to set up an ad-hoc emergency network over the second data or communication interface. The apparatus may then decide whether or not to join the ad-hoc emergency network and forward the paging message or the emergency message to other devices over the second data or communication interface. The second data or communication interface may be a sidelink interface, such as a PC5 interface, that allows direct communication between devices without relying on a network infrastructure. Alternatively, the second data or communication interface may be another interface that enables communication with a network infrastructure, such as a Uu interface. The apparatus may select the second data or communication interface based on the availability of network resources, the type and priority of the emergency message, the configuration of the apparatus, and/or the policies of the network operator or the user.

In an embodiment that can be combined with other embodiments or implemented independently, the device transmitting the emergency message or indication AND/OR the device receiving an emergency message or indication, e.g., from an NTN access device, may determine and/or indicate whether it/which devices should react to the emergency message or the indication thereof based on one or more of the following factors:

- the location of the device, as determined by, e.g., global positioning system (GPS) or other geolocation means, and the relevance of the emergency message or the indication thereof to the device's location;

- the type or category of the device, such as sensor, actuator, terminal, relay, etc., and the role or function of the device in the emergency scenario;

- the configuration or policy of the device, such as user preferences, network operator settings, device capabilities, etc., and the compatibility or compliance of the device with the emergency message or the indication thereof;

- the availability or status of the device, such as battery level, connectivity, memory, processing power, etc., and the feasibility or efficiency of the device to perform the actions required by the emergency message or the indication thereof.

The device may determine and/or indicate which devices should react to the emergency message or the indication thereof by using one or more of the following methods:

- appending or inserting a field or a flag in the emergency message or the indication thereof that specifies the devices that should react to it, e.g., by using a device identifier, a device group identifier, a device attribute, a device location, etc.;

- sending a separate message to the devices that should react to the emergency message or the indication thereof, e.g., by using a unicast, multicast, or broadcast transmission over the second data or communication interface; - encrypting or signing the emergency message or the indication thereof with a key or a certificate that is shared or known by the devices that should react to it, e.g., by using a symmetric or asymmetric encryption scheme or a digital signature scheme;

- modulating or coding the emergency message or the indication thereof with a pattern or a code that is recognizable or decodable by the devices that should react to it, e.g., by using a spread spectrum technique or an error correction code.

In general, operations and/or steps described in the above embodiments may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, certain processes are performed using special-purpose hardware.

To summarize, a method and system for distributing emergency messages in a communication network that involves relay units receiving a message through a data or communication interface has been described. These relay units determine if the message should be rebroadcasted in the communication interface and the communication resources to be used for the rebroadcast. The message is then rebroadcasted in the communication interface. The relay units may also perform their own assessment about forwarding the message and configure with a protocol determining their behavior. The relay units may use a pre-emptive communication strategy or a conflict prevention strategy. The relay units may also send or forward discovery/alert messages containing an emergency alert message or an indication thereof.

Furthermore, this invention can be applied to various types of UEs or terminal devices, such as mobile phone, vital signs monitoring/telemetry devices, smartwatches, detectors, vehicles (for vehicle-to- vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, Internet of Things (loT) hubs, loT devices, including low-power medical sensors for health monitoring, medical (emergency) diagnosis and treatment devices, for hospital use or first-responder use, virtual reality (VR) headsets, etc.

Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when de-scribing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Add i-ti ona I ly, the expression "at least one of A, B, and C" is to be understood as disjunctive, i.e., as "A and/or B and/or C". A single unit or device may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

The described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and/or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and/or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. An apparatus for distributing emergency messages, such as public warning messages, PWMs, or other high priority messages, in a cellular communication network, said apparatus being adapted to: receive an emergency message or an indication thereof through a first data or communication interface, determine based on a set of criteria whether or not the emergency message or the indication thereof is to be distributed to other devices over a second data or communication interface, determine communication resources to be used to distribute the emergency message or the indication thereof over the second data or communication interface, and transmit the emergency message or the indication thereof over the second data or communication interface in the determined communication resources.

2. The apparatus of claim 1, further comprising: determining whether the emergency message or an indication thereof is to be distributed by using broadcast and/or groupcast communication over the second data or communication interface, the second data or communication interface being a PC5 communication interface, and broadcasting and/or groupcasting the emergency message or the indication thereof over the PC5 communication interface by one or more relay units.

3. The apparatus of claim 1 or 2, wherein at least one criterion of the set of criteria to determine whether or not the emergency message or the indication thereof is to be distributed is configured by the communication network through a set of policies.

4. The apparatus of any one of claims 1 to 3, wherein at least one criterion of the set of criteria to determine whether or not the emergency message or the indication thereof is to be distributed is provided as part of a paging message and/or radio resource control, RRC, message and/or downlink control information, DCI, and/or media access control, MAC, control element, CE, message sent prior to the emergency message or the indication thereof.

5. The apparatus of any one of claims 1 to 4, wherein the emergency message or the indication thereof comprises supplementary data to help the apparatus to decide whether the emergency message or the indication thereof is to be distributed or not and/or how it is to be distributed.

6. The apparatus of any one of claims 1 to 5, wherein the apparatus is configured to determine one or more criteria and perform its own assessment about whether or not to forward the emergency message or the indication thereof and to provide the one or more determined criteria to the communication network or to other relay units using a configuration protocol.

7. The apparatus of any one of claims 1 to 6, wherein the apparatus is configured to use a pre-emptive communication strategy or a conflict prevention strategy.

8. The apparatus of any one of claims 1 to 7, wherein the apparatus is configured to transmit the emergency message or the indication thereof embedded in a PC5 discovery message or a PC5 connection setup message transmitted over a PC5 communication interface.

9. The apparatus of any one of claims 1 to 8, wherein the apparatus is configured to transmit the emergency message or the indication thereof to a remote unit in an idle or inactive mode at a time slot that depends on a time slot when the apparatus received the emergency message or the indication thereof or received a paging or radio resource control, RRC, or downlink/sidelink control information, DCI/SCI, message preceding the emergency message or the indication thereof, and a pre-configured time delay.

10. The apparatus of any one of claims 1 to 9, wherein the apparatus is configured to transmit a discovery and/or paging and/or page alert and/or RRC and/or SCI message containing an indication of and/or a pointer to a broadcast and/or groupcast of the emergency message transmission to be made by the apparatus, wherein the discovery and/or paging and/or page alert and/or RRC and/or SCI message comprises information about a timing or type of the emergency message to be sent.

11. The apparatus of any one of claims 1 to 10, wherein the apparatus is configured to use a probability to forward the emergency message or the indication thereof as a criterion to determine whether or not to distribute the emergency message or the indication thereof.

12. The apparatus of any one of claims 1 to 11, wherein the apparatus is configured to determine whether or not it is near a cell edge, and to use this determination as a criterion for distributing the emergency message or the indication thereof.

13. The apparatus of any one of claims 1 to 12, wherein the apparatus is configured to query another device over a connection to determine if the other device has received an emergency message or an indication thereof, or to respond to a query determining if an emergency message or an indication thereof has been received.

14. A system for distributing emergency messages in a communication network, said system comprising one or more relay units comprising the apparatus of any one of claims 1 to 13.

15. A system of claim 14, said system including one or more relay units configured to actively set up an ad-hoc communication network upon receiving an emergency message or an indication thereof, whereby the ad-hoc communication network may be active for a pre-determined period after receiving the emergency message.

16. A method for distributing emergency messages in a communication network, the method comprising: receiving an emergency message or an indication thereof through a first data or communication interface by one or more relay units; determining based on a set of criteria whether or not the emergency message or the indication thereof is to be distributed via a second data or communication interface; determining communication resources to be used to distribute the emergency message or the indication thereof via the second data or communication interface; and transmitting the emergency message or the indication thereof via the second data or communication interface in the determined communication resources.

17. A computer program product comprising code means for producing the steps of claim 16 when run on a computer device.