Device and related method for delivering emergency messages over a mobile phone network

Abstract

Devices and related methods for delivering emergency messages over a mobile phone network are provided. The methods and systems for delivering emergency messages over a communication network include relay units that receive messages through data or communication interfaces. These relay units determine whether a message should be rebroadcast over the communication interface and which communication resources should be used for rebroadcasting. The message is then rebroadcast over the communication interface. The relay units perform their own evaluations of message forwarding and determine their own behavior as set by the protocol. Relay units can use preemptive communication strategies or collision avoidance strategies. Relay units can transmit or forward discovery / alert messages, including emergency alert messages and their indicators.

Description

Technical Field

[0001] The present invention relates to the field of communication networks, and in particular to a method and system for delivering emergency messages in a communication network such as a 3GPP network. The communication network can employ one or more relay units that receive messages through a data interface and a communication interface and rebroadcast the messages.

Background Art

[0002] In the current technical environment, communication networks are becoming increasingly complex and interconnected. These networks are used for transmitting a variety of information including emergency messages. Delivery of these messages is critical during crises and disasters, as timely and accurate information can save lives and mitigate damage.

[0003] Emergency alert systems and related standards In the United Kingdom and the EU, emergency alert systems have been established under the European Electronic Communications Code (EECC) directive, which corresponds to the Wireless Emergency Alerts (WEA) in the United States. Various standards have been developed for public emergency broadcasting using mobile phone systems. The 3rd Generation Partnership Project (3GPP) launched a project in 2006 to define requirements for improving the reliability, security and resilience of Public Warning System (PWS). The resulting technical specification sets out general criteria for alert delivery, message content, and terminal functions of PWS-compatible terminals. The standard also includes additional requirements for specific PWS implementations, such as Japan's Earthquake and Tsunami Warning System (ETWS) and the Commercial Mobile Alert System (CMAS) in North America. Important 3GPP reports and standards relating to 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).

[0004] PWS implementations do not specify which alarm technology should be used. However, based on 3GPP requirements and standards, the efforts of the European Telecommunications Standards Institute (ETSI), and experience gained from existing PWS implementations such as NTT DoCoMo's Area Mail system introduced in 2007, Cell Broadcast Service (CBS) has emerged as the mainstream PWS technology. CBS has existed since 1988 and is already standardized by 3GPP. Key standards for Cell Broadcast include: 3GPP TS 23.041 - Technical Realization 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.

[0005] These standards cover requirements for, for example, CBS and user equipment (UE) to communicate and respond to wireless emergency alerts, and cover all applications of such systems (e.g., tsunamis and earthquakes). The UE activities described in these standards include displaying and sounding alarms specific to CBS communication reception.

[0006] In addition to 3GPP standards, other standards for PWS and cell broadcasting have also been developed. Importantly, CMAS and EU-Alert are compatible, and a common standard exists for citizens of the United States and the EU.

[0007] In March 2023, the United Nations launched the Early Warning for All (EW4All) initiative, calling for all people worldwide to be protected by early warning systems by 2027. The initiative's action plan calls for the International Telecommunication Union (ITU) to play a leading role in "warning, dissemination, and communication," a crucial element of early warning systems to ensure timely delivery of warnings to those at risk and prompt action. The action plan also specifically mentions the Global Mobile Communications System Association (GSMA) and mobile network operators (MNOs), urging them to promote the deployment of geo-located mobile early warning services using cell broadcast and / or location-based SMS. As part of the EW4All initiative, the ITU is supporting national governments in deploying mobile early warning systems to reach more high-risk populations.

[0008] The current system needs to resolve the following issues: 1. How can we ensure that all users in that location receive an emergency alert and can communicate even if they are not directly connected to a base station (BS) for a certain period afterward? Conventional emergency alert systems notify local users when a life-threatening event occurs. Not everyone will receive the alert, as some users may not be connected to a mobile phone system, and the emergency itself may disrupt local communications. 2. How can device-to-device (D2D) networks be utilized to improve the transmission of emergency alerts and support disaster-related communication needs? This process needs to be rethought in 6G, considering the use of communications that integrate different communication protocols and methods, particularly to improve the integration of D2D networks. [Overview of the project] [Problems that the invention aims to solve]

[0009] The objective of this invention is to compensate for the shortcomings of existing solutions and to improve the efficiency and / or effectiveness of emergency warning systems. [Means for solving the problem]

[0010] The objective of this invention is to compensate for the shortcomings of existing solutions and to improve the efficiency and / or effectiveness of emergency warning systems.

[0011] According to the first aspect, a device is provided in a mobile phone system for delivering emergency messages (PWM and other high-priority messages (e.g., emergency alerts)), and the device is An emergency message or its indicator (e.g., a paging message containing a flag indicating the availability of an emergency message) is received through the first data or communication interface (e.g., a Uu or PC5 interface), Based on a set of criteria, it is determined whether an emergency message or its indicator should be delivered to another device via a second data or communication interface (e.g., a PC5 interface). Determine the communication resources that should be used to deliver the emergency message or its indicators through a second data or communication interface. The emergency message or its indicator is transmitted through a second data or communication interface on the designated communication resource.

[0012] According to the second aspect, a system for distributing emergency messages in a communication network is provided, the system including one or more relay units having the equipment of the first aspect.

[0013] In the third aspect, a method for delivering emergency messages over a communication network is provided, and this method is The steps include receiving an emergency message or an indicator thereof through a first data interface or communication interface by one or more relay units, A step of determining, based on a set of criteria, whether an emergency message or its indicator should be delivered through a second data or communication interface, The steps include determining the communication resources to be used to deliver an emergency message or its indicator through a second data or communication interface, The process includes the step of transmitting an emergency message or its indicator through a second data or communication interface on a determined communication resource.

[0014] In one aspect, a computer product is provided, which includes coding means for running on a computer device to generate steps of the method of the third aspect.

[0015] Therefore, it is possible to provide a flexible and adaptable solution for delivering emergency messages over cellular networks, which can be adjusted to specific network requirements and circumstances. More specifically, it is possible to ensure that more people can receive emergency alert messages after they have been sent, even if they are not connected to a cellular system. Furthermore, it is possible to build and maintain a robust communication network between UEs during and immediately after an emergency, providing considerable resilience even if cellular communication is interrupted.

[0016] Enhanced robustness can be achieved by integrating cellular and D2D communications to enable efficient and robust communication in order to minimize mutual interference, ensure at least two of the most reliable D2D links (if possible) for each UE, minimize the total "hop length" from cellular to any UE not directly connected to cellular (minimizing communication delay), and / or minimize the load on the cellular network by limiting base station-UE connections to the extent that it does not compromise the robustness of the entire network, appropriately scheduling new connections to minimize channel interference during connection establishment, optimizing the speed of emergency message delivery to UEs that have not yet received the emergency message, and / or reorganizing the set of UEs connected to the D2D network (adding and removing links) and the cellular network.

[0017] According to the first option, which can be combined with any of the first to fourth aspects, it is possible to determine whether the emergency message or its indicator should be delivered by broadcast and / or groupcast communication on the PC5 communication interface, or whether the emergency message or its indicator can be broadcast and / or groupcast on the PC5 communication interface by one or more relay units.

[0018] According to the first option or the second option, which can be combined with any of the first through fourth aspects, at least one of the set of criteria for determining whether an emergency message or its indicator should be delivered can be set by the communications network through a set of policies.

[0019] According to the first or second option, or a third option which can be combined with any of the first through fourth aspects, at least one criterion from a set of criteria for determining whether an emergency message or its indicator should be delivered may be provided as part of a paging message and / or a Radio Resource Control (RRC) message and / or a Downlink Control Information (DCI) and / or a Media Access Control (MAC) Control Element (CE) message that is sent prior to the emergency message or its indicator.

[0020] According to a fourth option which can be combined with any of the first to third options or any of the first to fourth aspects, the emergency message or its indicator may include auxiliary data to help (for example, a device) determine whether and / or how the emergency message or its indicator should be delivered.

[0021] According to a fifth option, which can be combined with any one of the first to fourth options or any one of the first to fourth aspects, one or more criteria may be determined (e.g., by an apparatus), an independent assessment on whether to forward an emergency message or an indicator thereof may be performed (e.g., by the apparatus), and said one or more determined criteria may be provided (e.g., by the apparatus) to a communication network or another relay unit using a configuration protocol.

[0022] According to a sixth option, which can be combined with any one of the first to fifth options or any one of the first to fourth aspects, for example, a proactive communication strategy and a collision avoidance strategy may be used by an apparatus.

[0023] According to a seventh option, which can be combined with any one of the first to sixth options or any one of the first to fourth aspects, the emergency message or the indicator thereof may be embedded in a PC5 discovery message or a PC5 connection setup message transmitted via a PC5 communication interface.

[0024] According to an eighth option, which can be combined with any one of the first to seventh options or any one of the first to fourth aspects, the emergency message or the indicator thereof may be transmitted by a remote unit in idle or inactive mode in a time slot that depends on a preset time delay and a time slot in which the emergency message or the indicator thereof, or paging or radio resource control (RRC) preceding the emergency message or the indicator thereof, or a downlink / sidelink control information (DCI / SCI) message is received (e.g., by an apparatus).

[0025] According to the ninth option, which can be combined with any of the first to eighth options or the first to fourth aspects, discovery and / or paging and / or page alarm and / or RRC and / or SCI messages can be transmitted (e.g., by the device), which include indicators or pointers to broadcasts and / or group casts of emergency message transmissions to be made, for example, in this case the discovery and / or paging and / or page alarm and / or RRC and / or SCI messages may include information about the timing and type of emergency message to be transmitted.

[0026] According to a tenth option which can be combined with any of the first to ninth options or any of the first to fourth aspects, the probability of forwarding an emergency message or its indicator can be used (e.g., by the device) as a criterion for deciding whether to deliver the emergency message or its indicator.

[0027] According to an eleventh option, which can be combined with any of the first to tenth options or any of the first to fourth aspects, it is possible to determine whether the cell is approaching its edge, and this determination can be used (e.g., by a device) as a criterion for delivering an emergency message or its indicators.

[0028] According to a twelfth option, which can be combined with any of the first to eleventh options or any of the first to fourth aspects, the other device can be queryed through the connection (e.g., by the device) to determine whether the other device has received an emergency message or its indicator, or can be responded to (e.g., by the device) to a query determining whether an emergency message or its indicator has been received.

[0029] This device is mounted on a relay unit and can determine the timing and / or frequency and / or number of times to send emergency messages and their indicators in order to maximize the likelihood that other devices will receive the emergency messages and their indicators.

[0030] Emergency messages and their indicators may include supplementary data (e.g., additional criteria or information to help evaluate criteria) to help the device determine whether and / or how the message and its indicators should be delivered.

[0031] It should be understood that preferred embodiments of the present invention may be dependent claims or any combination of the above embodiments and their respective independent claims.

[0032] These and other aspects of the present invention will become apparent from and be explained with reference to the embodiments described below. [Brief explanation of the drawing]

[0033] [Figure 1] A block diagram illustrating the implementation of a system for delivering emergency messages over a communication network. [Figure 2] A flowchart illustrating how a relay unit transmits an emergency message or its indicator to a remote UE in a time slot that depends on the time slot in which the relay received the emergency message or its indicator, and on a pre-configured first time delay and optionally a second time delay. [Figure 3] A block diagram illustrating the system and process flow for creating an ad-hoc network for distributing emergency messages. [Figure 4] A flowchart outlining how to create an ad-hoc network for distributing emergency messages. [Figure 5] A diagram illustrating a schematic example of a network topology. [Modes for carrying out the invention]

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

[0035] Throughout this disclosure, the abbreviation “gNB” (5G terminology) is intended to refer to access devices such as cellular base stations and Wi-Fi access points. A gNB is part of the Radio Access Network (RAN) and provides an interface to functions within the Core Network (CN). The RAN is part of the wireless communication network. It enables Radio Access Technology (RAT). Conceptually, it exists between communication devices such as mobile phones, computers, or remotely controlled machines and provides connectivity to their CN. The CN is the core of the communication network and provides numerous services to customers interconnected via the RAN. More specifically, it forwards communication streams across the communication network and, in some cases, other networks. Furthermore, the Access Mobility Management Function (AMF) terminates the control planes of different access networks into the 5G CN (5GC) and controls which UEs can access the 5GC and exchange traffic. It also manages the mobility of UEs as they roam from one gNB to another for session / service continuity wherever possible. Furthermore, Information Elements (IEs) specify the information (or groups of information) contained in signaling messages and data flows transmitted through the interface (examples include QoS (Quality of Service) definitions, setup parameters, and user identifiers). The Location Management Function (LMF) is a network entity defined in the 5G core network that provides location capabilities by means of determining the geographical or relative location of mobile terminals based on downlink, uplink, and sidelink location radio signals. Additionally, a Gateway Mobile Location Center (GMLC) is used for active mobile location measurement, triggering specific activities on the network to obtain subscriber locations in real time. To improve location accuracy, the GMLC can connect to additional precision location components within the network. The GMLC may include the necessary functionality to support the LoCation Service (LCS). A single PLMN (Public Land Mobile Network) may have multiple GMLCs.GMLC is the first node accessed by external LCS clients on the network. Furthermore, the abbreviation "OAM" (Operations, Administration, Management, or Maintenance) is understood to refer to the processes, activities, tools, and standards related to the operation, administration, management, and maintenance of the system.

[0036] The 3GPP standards TS23.304 and TS24.501 for 5G networks define a so-called proximity service (ProSe) function, which enables connectivity, among other things, for cellular communication equipment (e.g., UEs) that are temporarily outside the coverage of an access device (gNB). This function is called ProSe UE-to-network relay, or relay UE. A relay UE is a communication device that helps other UEs communicate with gNBs (i.e., access devices) by relaying application and network data traffic in two directions between the other UE and the gNB. Local communication between a relay UE and other UEs is called D2D communication, sidelink communication, or PC5 communication. The abbreviation "PC5" refers to the interface for sidelink communication as defined by ProSe. Furthermore, the abbreviation "UL" is used for uplink communication from a communication device (e.g., UE) to an access device (e.g., gNB), "DL" for downlink communication from an access device (e.g., gNB) to a communication device (e.g., UE), and "SL" for sidelink communication between two or more communication devices (e.g., UE). Once a relay relationship is established, the UE is connected via the relay UE and acts as a "remote UE." This situation means that the remote UE has an indirect network connection to the CN rather than a direct network connection as in the usual case (see 3GPP standard TS 22.261 v16.10.0).

[0037] Furthermore, 3GPP standards TR 23.733 v15.1.0 and TR 36.746 v15.1.1 provide research on architectural enhancements that enable IoT devices (acting as remote UEs) to operate at very low power by connecting to a wide area network using relay UEs. Because the relay UEs are physically very close, they are reachable even with very low-power transmissions. This research also includes improvements to the security, speed, and stability of ProSe. These enhancements to ProSe are called "enhanced ProSe (eProSe)". One of the proposed improvements of eProSe is an enhanced relay architecture that operates at the second Open Systems Interconnection Layer (OSI) / protocol layer (i.e., L2), which provides end-to-end Internet Protocol (IP) and Packet Data Convergence Protocol (PDCP) packet transmission to remote communication devices for application data and / or user data. The advantage of this architecture is that remote communication devices are directly visible as registered entities in the CN, which is important for monitoring and billing purposes, and for improved control over communication devices by access devices.

[0038] Furthermore, an element for implementing the scheduling mechanism can be a Radio Resource Control (RRC) protocol, which can operate end-to-end to the UE through one or more potential hops, considering the relay architecture described above on the second protocol OSI / layer (i.e., L2). Another element to consider is the use of Downlink Control Information (DCI), which is a short message transmitted over a low-bitrate control channel (e.g., a Physical Downlink Control Channel (PDCCH)) by special blind-detectable modulation or coding. Here, various DCI formats with different information content can be defined.

[0039] Current activities at 3GPP 3GPP Provisional 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) introduces support for the relaying of public warning messages (PWM) in accordance with the requirements specified in standard TS 22.268. This aligns the 3GPP standard with the RAN Rel-17 solution for transferring PWS system information blocks (SIBs) over a unicast link to a remote UE as specified in TS 38.300. Tdoc S2-2307039 describes how a UE acting as a 5G ProSe UE-to-Network relay will, upon receiving a warning message, broadcast that warning message to a remote UE. In this solution, described in Tdoc S2-2307039, the 5G ProSe UE-to-network relay broadcasts alarm messages (i.e., SIB 6 / 7 / 8) received from the network to the 5G ProSe remote UE using the broadcast mode of 5G ProSe direct communication as defined in section 5.3.2 of TS 23.304. The 5G ProSe UE-to-network relay uses the configured Destination Layer-2 ID specified in section 5.1.4.1 of TS 23.304 when broadcasting alarm messages, and the 5G ProSe remote UE receives alarm messages transmitted via the PC5 reference point using the configured Destination Layer-2 ID specified in section 5.1.4.1. The PC5 QoS parameters defined in section 5.1.4.1 are used for broadcasting and receiving alarm messages for the 5G ProSe UE-to-network relay and the 5G ProSe remote UE, respectively. A 5G ProSe remote UE can receive broadcasted alarm messages without establishing a connection to the 5G ProSe UE-to-network relay.The 5G ProSe UE-to-network relay performs the duplicate detection function specified in TS 23.041 to suppress duplicate alarm messages received on the Uu. The 5G ProSe remote UE performs the duplicate detection function specified in TS 23.041 to detect duplicate alarm messages received on the PC5 and / or Uu. The 5G ProSe Layer-2 UE-to-network relay can alternatively forward PWS SIBs (i.e., SIBs 6 / 7 / 8) to the connected 5G ProSe Layer-2 remote UE via a unicast link as specified in TS 38.300

[12] . The public alarm system architecture for the 5G system is specified in TS 23.041.

[0040] The solution in Tdoc S2-2307039 still has several issues, including, for example, (1) the inability to control which relay UE forwards the PWM, (2) the possibility that a relay UE may connect remote UEs that may still be connected (i.e., connected to the network via the relay UE) and for which rebroadcasting of emergency messages on the PC5 interface may not be useful, while other UEs may not be connected at all and will continue to miss emergency messages, (3) remote UEs that are not connected to the relay UE or are in an IDLE / INACTIVE state may not be able to receive the PWM, and (4) the failure to consider other types of relays (e.g., residential gateway devices, RF repeaters).

[0041] In some embodiments, delivering an emergency message (e.g., a public alert message, an emergency alert message, etc.) over a communication network (e.g., a 3GPP-based cellular communication network) requires several steps. These include receiving the message, determining whether the message should be delivered, determining the communication resources to be used for delivery, and finally, sending the message. This process can be carried out by one or more relay units within the network (e.g., UE-to-network relays, UE-to-UE relays, gateway UEs, also known as "relay nodes").

[0042] In embodiments, relay units can be used to deliver emergency messages. They receive emergency messages or their indicators (e.g., an SIB containing the emergency message or a flag indicating the availability of the emergency message) through a first data or communication interface (e.g., a Uu interface between a UE and a base station in a cellular network) and determine whether the emergency message or its indicators should be further delivered through a second data or communication interface (e.g., a PC5 communication interface or other sidelink communication interfaces between UEs in a cellular system). Relay units can also determine the communication resources that should be used to deliver the emergency message or its indicators. For example, a relay unit may determine whether to deliver the emergency message or its indicators using broadcast and / or groupcast communication on a second data or communication interface, determine the communication resources that should be used to broadcast and / or groupcast the emergency message or its indicators on a second data or communication interface, and one or more relay units broadcast and / or groupcast the emergency message or its indicators on a second data or communication interface.

[0043] In this explanation, the term "emergency message" may refer to any message that contains an emergency message or the content of an encapsulated emergency message. Examples of emergency messages include messages that constitute or contain an ETWS / CMAS message.

[0044] Please note that throughout this disclosure, only the blocks, components, and / or devices related to the proposed data distribution functionality are shown in the accompanying drawings. Other blocks have been omitted for brevity. Furthermore, blocks designated with the same reference number are intended to have the same or at least similar functionality, and therefore their functionality will not be described again later.

[0045] Figure 1 schematically shows a block diagram illustrating an example implementation of a system for delivering emergency messages in a communication network. In this method, one or more relay units 100 receive emergency messages or indicators through a data interface or communication interface 110 (i.e., the first data or communication interface described above). These relay units 100 then determine, based on a set of criteria, whether the emergency message or indicator should be delivered through a sidelink communication interface 130 (i.e., the second data or communication interface described above (e.g., the PC5 interface)) in a processing unit 120. Subsequently, the relay units 100 identify the communication resources to be used to deliver the emergency message or indicator through the sidelink communication interface 130. Finally, the emergency message or indicator is transmitted through the sidelink communication interface 130.

[0046] This process can be performed by a device or system that includes a processor that executes a set of code for controlling the functional elements of the device. Alternatively, certain processes may be performed on special-purpose hardware. Generally, these operations are performed according to the methods and processes described in this embodiment. In some cases, the operations described herein may consist of multiple substeps or may be performed in parallel with other operations.

[0047] Figure 2 shows examples of methods 500 for delivering emergency messages in a communication network according to various embodiments. In some examples, these operations can be performed by one or more relay units. Furthermore, certain processes can be performed using application-specific hardware. Generally, these operations can be performed according to the methods and processes described in the examples and implementations described herein. In some cases, the operations described herein may consist of multiple substeps or may be performed in parallel with other operations.

[0048] In operation 505, the relay unit receives an emergency message or its indicator (e.g., a paging message containing a flag indicating the availability of an emergency message) through a data interface or communication interface (i.e., the first data or communication interface described above). In operation 510, the relay unit may determine, based on a set of criteria, whether the emergency message or its indicator should be delivered through a sidelink communication interface (i.e., the second data or communication interface described above). In operation 515, the relay unit may determine the communication resources that should be used to deliver the emergency message or its indicator via the sidelink communication interface. Determining the communication resources includes determining the time and / or frequency and / or number of times to send the emergency message, which maximizes the likelihood that other devices (e.g., a remote UE in idle or inactive mode) will receive the emergency message or its indicator. This can be done in time slots where the relay received the emergency message or its indicator, or in time slots where it received a paging, RRC, or DCI / SCI message prior to the emergency message or its indicator, and in time slots that depend on a pre-configured first delay. The relay unit may also decide to set a second time delay between the transmission of an indicator of the emergency message (or the emergency message itself) via the second data or communication interface and the transmission of the actual emergency message (or retransmission of the emergency message) via the second data or communication interface. In operation 520, the relay unit may transmit the emergency message or its indicator via the second data or communication interface. In operation 525, the relay unit may transmit (or retransmit) the emergency message with the second delay determined in operation 515.

[0049] Creating an ad-hoc network for distributing emergency messages In embodiments that can be used in combination with other embodiments or independently, emergency alerts can be sent to UEs within a region using, for example, CBS. However, a UE may not receive the alert and be unable to communicate, while other nearby UEs can communicate. When a UE receives an emergency alert, the formation of an optimized local ad-hoc network (e.g., a D2D mesh network) is initiated to connect (currently) disconnected users and forward the alert to them, and the ad-hoc network persists for a defined period to support subsequent communications (which would be important in an emergency). Therefore, if a UE (which may be in idle mode when an emergency alert is received and may not be connected to the communication network directly via a Uu or indirectly via a relay node) receives an emergency alert or an indicator thereof, this UE will initiate a discovery process to find nearby UEs that may be able to function as relay nodes (e.g., a 5G ProSe UE - a UE that makes itself discoverable as a network-to-network relay or UE-to-UE relay), and / or remote units (e.g., a UE that makes itself discoverable as a 5G ProSe remote UE), and / or other units capable of D2D connectivity (e.g., a UE that makes itself discoverable as a 5G ProSe D2D UE). During or after discovery, the UE can begin setting up a D2D connection with the discovered device (e.g., via PC5, or via a non-3GPP link (sidelink) such as Wi-Fi or Bluetooth; in this case, the Wi-Fi "sidelink" connection is established via a Wi-Fi access point or directly (e.g., via Wi-Fi Direct / Wi-Fi Aware)). As a result, if a relay node can connect to the communication network, the UE can switch to connected mode. During discovery, and / or after connection setup with relay nodes, remote units, or other D2D-connectable units, the UE can broadcast, groupcast, or unicast emergency alerts to the discovered device or D2D-connected devices.The discovery message used in the discovery procedure described above may include, as part of its payload, an indicator of the emergency alert message or the content of the emergency alert message. When a UE forwards an alert to another device, it is considered a relay unit (as described above).

[0050] Connectivity network base stations (BS) and core network functions of communication networks can be assisted in forming ad hoc networks by providing information and coordination to UEs and other relay units, which can be done through (mutual) updates of a (distributed) database with the UEs forming the ad hoc network. The timing and sequence of network connections can be implemented to minimize mutual interference (particularly in connection establishment), minimize the number of D2D hops required for UEs not connected to any base station, and maximize network robustness by, for example, maintaining at least two links for each UE and / or by selecting one or more UEs (which can function as relay units) to use for cellular network connections based on connection reliability.

[0051] Each device within an ad-hoc network (such as relay units or end devices) can perform its own optimization process for establishing and maintaining the ad-hoc network, coordinated with other devices in the D2D network, either through a distributed, collaboratively managed connection status database, or through a BS or core network function connected to the ad-hoc network that maintains, updates, and sustains this connection status database. Once a UE establishes a D2D connection, the network generation plan is integrated among the connected devices. Inter-sequence algorithms can be used to identify and time established connections.

[0052] For example, upon receiving an emergency communication, the relay unit (e.g., UE) that receives it initiates a coordinated device discovery process with other relay units or end devices (i.e., UEs that receive the emergency message but do not forward it further) to discover devices that can be connected via D2D (e.g., via PC5 or via non-3GPP links (sidelinks) such as Wi-Fi or Bluetooth; in this case, the Wi-Fi "sidelink" connection can be via a Wi-Fi access point or established directly (e.g., through Wi-Fi Direct / Wi-Fi Aware)), and then compares the discovered devices with entries in a connection status database (jointly maintained) of already connected relay units and / or end devices (and / or existing D2D connections already established within that network) to determine whether they are already part of an ad-hoc network (in which case their connection priority is set to low).

[0053] For example, the connection status database could be maintained by the communication network (e.g., the local BS or Access Mobility Management Function (AMF) of the core network), or it could be distributed among relay units and end devices and coordinated locally within an already established ad-hoc network using a distributed, collaboratively updated connection database.

[0054] If a newly discovered relay unit or end device is not part of an existing ad-hoc network, its connection priority can be set to high.

[0055] Subsequently, an optimization algorithm can be run to determine the order in which new connections should be established from all relay units and / or to all end devices within that ad-hoc network, within the context of existing connections that are already connected and operational. Using connection priorities, this optimization algorithm is used to add and prune connections to maximize ad-hoc network operation and robustness, for example, by selecting appropriate cellular connection relay units as prime nodes in the network, ensuring redundant connections to each relay unit or end device within the ad-hoc network, minimizing the number of hops (only from cellular connection relay units to D2D connected devices), selecting and scheduling relay units and end devices for device discovery, and / or minimizing channel interference during connection setup and use.

[0056] Newly discovered relay units or end devices that do not yet exist in the network can be inquired about whether they have received an emergency alert through the new connection. If an emergency alert has not been received, the appropriate relay unit (usually one that has just established a connection) is selected to forward the emergency alert to that device, and the new device is fully added to the ad-hoc network. Receiving an emergency alert triggers the new device to perform the D2D device discovery process as part of the ad-hoc network to which it is connected. If the newly discovered device is already part of another ad-hoc network, the networks can work together and merge, integrating the connectivity databases and re-optimizing the operation and robustness of the expanded network.

[0057] An ad-hoc network may terminate its connection and cease operation after a certain period following the receipt of an emergency alert message (or after a certain period following D2D connection setup), or based on a message from the communication network. This period may be based on a pre-configured policy provided to the relay unit by the network.

[0058] Emergency alert messages may require additional protocols at BS, UEs, and other relay units to initiate the construction and maintenance of ad-hoc networks, coordinate connection plans between local UEs, and forward alert messages.

[0059] In embodiments that can be used in combination with other embodiments or independently, the relay unit establishes an ad-hoc routing network (essentially temporary, e.g., for a specific limited period) with one or more devices reachable by the relay unit (e.g., UEs or other relay units), allowing further updates from the communication network or transmission of further segments of segmented messages to be forwarded and received by devices reachable by the relay unit. This can be achieved by the relay unit proactively setting up communication connections with neighboring devices (e.g., after ProSe discovery via PC5). Furthermore, such a (temporary) ad-hoc network can be used by devices connected to the ad-hoc network (e.g., UEs or other relay units reachable by the relay unit in the ad-hoc network via multiple hops) to initiate communication with the communication network or neighboring UEs (e.g., to make a phone call to a family member). The communication network to which the relay unit is connected (e.g., by base stations (BS) to which the relay unit is directly / indirectly connected, or by core network functions such as AMF, policy control function (PCF), session management function (SMF)) can set the minimum lifetime and / or traffic policy of the ad-hoc network. For example, if a first relay unit decides to forward a first emergency message or indicator or a fragment thereof, and a second relay unit does not forward it (for example, because the first relay unit had previously sent it), then subsequent emergency messages or fragments thereof, or other subsequent communications, may be forwarded by the first UE but not by the second UE, and this behavior is configurable by policy. To improve future planning and / or to identify locations where emergency messages have not yet been received, relay units can notify the communication network of the network's existence and information (such as the number of nodes, topology, and coverage area) when or after the ad-hoc routing network is established.The communication network can also instruct relay units to discard the ad-hoc network, for example, when it is no longer needed. The period during which the ad-hoc network needs to be active (for example, after receiving an emergency message or after setting up a D2D connection) can be based on a pre-configured policy that the network provides to the relay units.

[0060] Ad hoc networks are not only time-limited but can also be restricted to specific areas (e.g., areas without coverage). Therefore, in relevant embodiments, a relay unit can use local knowledge to determine where this ad hoc network will be used to deliver emergency messages. Local knowledge includes information from past positioning operations in which the location of the relay unit itself is determined and / or the distance and / or angle and / or location of neighboring nodes (e.g., anchors) is shared / determined. If the local knowledge indicates that the relay unit and / or neighboring nodes are inside or outside a particular predetermined area (e.g., based on a policy that includes location / area information received from the network), it can be decided not to deliver any more emergency messages and / or not to set up an ad hoc network connection between each relay unit and neighboring nodes.

[0061] In related embodiments, the propagation and reception of messages may be restricted by tracking areas and / or geographical areas and / or service groups (for example, only people on a particular road should be notified of an emergency road condition ahead, and only emergency workers should be placed on standby in case of a potential serious accident).

[0062] In variations of the embodiment, message propagation and reception can be limited / determined by the context of the relay unit. For example, if the UE is located between a first city (e.g., Eindhoven) and a second city (e.g., Maastricht) and is heading towards the first city, the relay unit may or may not relay emergency messages regarding an accident in the direction of the second city. For example, if the battery level is too low or the coverage is good, the relay unit may not forward messages.

[0063] In related embodiments that can be combined with other embodiments, an ad-hoc network or ad-hoc emergency network may include nodes (e.g., relay units) connected to other cells or networks. For this purpose, the nodes consist of a set of permitted / denied cells or networks and / or can be configured by policies, provided by one of the networks (e.g., UE's Home PLMN) or a master database (operated by the government), regarding the timing / location / method of forwarding emergency alert messages and / or the timing / location / method of setting up the ad-hoc network as described in other embodiments.

[0064] In another embodiment, which can be implemented in combination with other embodiments or independently, the relay unit may check local policies and / or verify received emergency messages and their indicators before creating an ad-hoc network for delivering messages to other devices. This is done to ensure that the messages are authentic, important, and not expired. Local policies may be provided by communication networks or other entities (e.g., governments, public safety agencies, etc.) and may include specific criteria for verifying emergency messages and their indicators. For example, a local policy may specify: - The source or sender of a message or indicator (e.g., a trusted base station, core network function, public warning system, etc.); - The format or structure of messages or metrics (e.g., standard protocols, signed headers, checksums, etc.); - The content or type of the message or indicator (e.g., a predefined category, keyword, code, etc.); - A timestamp or validity period for a message or metric (e.g., date and time, duration, sequence number, etc.).

[0065] The relay unit compares the received message or indicator to the local policy and / or performs a verification process (e.g., decryption, decryption, check, etc.) to determine if the message or indicator meets the criteria. If the relay unit determines that the message or indicator is valid, it can build an ad-hoc network with neighboring devices (e.g., UEs or other relay units) and further deliver the message or indicator as described in other embodiments. If the relay unit determines that the message or indicator is invalid, it can discard the message or indicator and / or report it to the communication network or other authority. Alternatively, the relay unit can notify the user that the message or indicator is invalid and request permission or confirmation to generate an ad-hoc network. The relay unit can also update the local policy based on feedback from the communication network or other authority, changes in circumstances or environment.

[0066] In the following embodiments, the ad-hoc network (referred to as a D2D network) is depicted as a single-level system, but it can also be configured as a hierarchically structured network (including subnetworks and connected / head nodes).

[0067] Figure 3 provides an overview of a block diagram illustrating the system and process flow for creating an ad-hoc network for delivering emergency messages.

[0068] In the embodiment shown in Figure 3, an emergency alert message relay and communication network system is provided, which includes a base station (BS) that supports one or more D2D networks and has a transmission function (EAM Tx) for sending emergency alert messages (EAM) to cellularly connected UEs (UE1, UE2) in addition to cellular communication (CC). This can optionally be achieved by maintaining and updating a connection status database (CS-DB) for each connected D2D network, which also includes running a D2D connection update algorithm (D2D UA) on the connection status database to communicate the desired and required connections to the UEs in that connected D2D network.

[0069] The UE, for example, can communicate bidirectionally with the base station if a link can be established via cellular communication, and has an EAM receiving / display function (EAM Ex / D) for receiving and displaying (and / or notifying) emergency alert messages.

[0070] Furthermore, the UE is configured to establish D2D connections, including D2D network functions (D2D NF) such as device discovery, D2D connectivity, relay, and communication; receive emergency alert messages; initiate communication activities as a result of message reception, for example using an EAM activity controller; host a distributed connectivity status database (CS-DB); perform updates to this database; and / or run a D2D connectivity update algorithm (D2D UA) on this database.

[0071] Furthermore, a UE can be configured to delete or add D2D connections in response to a request from a BS or a change in the connection status database, to query another UE via a connection (e.g., a D2D connection (D2D-C)) to determine whether a particular emergency alert message has been received, and to respond to queries determining whether a particular emergency alert message (EAM) has been received (e.g., using a unique identifier for that particular message).

[0072] Furthermore, a UE can be configured to forward certain emergency alert messages to another UE via a D2D connection (D2D-C), and EAMs delivered via this D2D are treated similarly to EAMs received from a cellular network (including aspects such as being displayed to the user and preventing other phone use until the message is acknowledged).

[0073] The connection status database can be distributed and jointly managed by all UEs (or some of them, e.g., a database of the status of nearby discoverable / discovered UEs or UEs in a specific area) within the D2D network, or it can be centrally managed within the base stations or core network of the communication network. It can be configured to enable database synchronization (DB-SYNC) over cellular and / or D2D communication, and security measures can be installed to protect itself from malicious update operations.

[0074] Furthermore, the connection status database is configured to hold a list of unique identifiers for all UEs in the D2D network (or a portion of them, such as a database of the status of nearby discoverable / discovered UEs or UEs in a specific area), and for each listed UE, information on whether they have received an EAM and whether they are connected to or can connect to the cellular network, optionally information on location and movement, optionally information on associated device capabilities, a list of D2D connections already established in the D2D network, statistics on the reliability and changes over time of these connections, and a list of newly discovered UEs and their connection priority (including whether they wish to connect or not).

[0075] Furthermore, the connection status database can be configured to perform a merge operation with another separate connection status database, thereby merging two D2D networks (or parts thereof).

[0076] The D2D connection update algorithm is implemented using artificial intelligence (AI) algorithms such as appropriate optimization processes or inter-sequence models, which have the ability to analyze a connection status database and generate a connection change plan that optimizes the D2D network, thereby minimizing the number of D2D hops required for UEs not connected to the cellular network to communicate with the cellular network, and / or maximizing the robustness of the D2D network by maintaining, for example, at least two links (these links are highly reliable) for each UE, and / or selecting D2D connections based on current and projected reliability, and / or using connection reliability data, and optionally location and movement data, to select new connections to be established and old connections to be removed to minimize mutual interference between connections (especially during initial setup, e.g., due to the connection establishment sequence), and / or selecting UEs to connect to the cellular network based on the reliability of the cellular connection and / or their location within the D2D network, thereby ensuring that cellular communication channels within the D2D network are utilized efficiently and not overloaded.

[0077] For example, a connection change plan would involve device discovery, establishing new connections between UEs (or UEs discovered by device discovery but not belonging to the network) within a D2D network at specific timings and channel selections, pruning existing connections within D2D, establishing connections from BS (cellular) to UEs, pruning connections from BS (cellular) to UEs, and merging this network with another D2D network (including merging connection status databases), with at least one UE available.

[0078] Figure 4 schematically shows a flowchart illustrating how to create an ad-hoc network for distributing emergency messages according to the embodiment.

[0079] Not all steps (or substeps) are mandatory, and the order of (sub)steps may vary. The left column of each step corresponds to connected UEs (UE-C), and the right column corresponds to unconnected UEs (UE-UC).

[0080] In step S401, the BS receives an EAM containing content and a unique identification number from the emergency alert message source. The BS then transmits the EAM to all cellular-connected UEs, for example, using a cell broadcast service.

[0081] A connected UE receives the EAM and displays it to the user according to the Emergency Alert Display (DISP EAM) standard. An unconnected UE does not receive the EAM (NR) (step S402a). The UE can then perform subsequent communication tasks, for example, by using an EAM activity controller.

[0082] In step S403 (CS-DB), the system adds itself to the newly created connection status database, which includes the current cellular connection, including all existing D2D network connections (if any).

[0083] In step S404(DD), device discovery is initiated, for example by using D2D communication to identify other local UEs that it can connect to (including identifying their unique identifiers), and possibly depending on actions generated by the D2D connection update algorithm (to avoid interference from multiple UEs performing device discovery simultaneously). Optionally, in step S404a, a discovered unconnected UE can accept or reject the requested D2D link. In the latter case, the discovered unconnected UE can indicate that it does not wish to be added to the network, in which case it can be entered into the list of uncooperative UEs in the connection status database.

[0084] In step S405 (D2D UA), 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, the priority status of newly discovered UEs can be set to "High". To achieve this, the UE can run the D2D connection update algorithm against the connection status database and perform relevant actions based on the results. For example, this could return an action for that UE to form a connection to a newly discovered unconnected UE.

[0085] In step S405a (D2D CE), a D2D connection is established to a newly discovered unconnected UE, and this is entered into the connection status database. The new UE can synchronize with the connection status database and begin updating with data such as received signal strength, location, and movement. If it is part of another D2D network, the networks can be integrated.

[0086] In step S406 (EAM ST REQ), the UE queries the newly discovered UE (for example, by using the EAM's unique number as the query) to see if it has received the EAM, and enters the result into the connection status database. The UE runs the D2D connection update algorithm on the connection status database and performs the relevant actions as a result. If the newly discovered UE has not received the EAM, it may return an action to send the EAM to the newly discovered UE.

[0087] In step S406a (EAM RX / D), the EAM is received and displayed to the user of a newly discovered unconnected UE. This UE initiates a process (for example, by its EAM activity controller) in a synchronized connection status database within the same D2D network, which can update the database with communication statistics, movement information, etc., and the database is maintained in an updated state.

[0088] The newly discovered UE can then obtain a distributed copy of the connection status database and / or initiate the process of establishing an emergency alert message relay or communication network system (for example, by forming an ad-hoc network as described in other embodiments).

[0089] Another result of the query in step S406 is that the EAM is received by a newly discovered UE and is part of another D2D network (at least connected to a base station). In this case, an action can be returned to merge the two connection status databases to form a single D2D network. To ensure that the merging process is handled correctly in both networks, coordination between the two networks must be established, for example, to ensure that all UEs in the different D2D networks agree that this network is part of it. The merged network can be efficiently reconfigured while maintaining robustness and reliability (this can be achieved by running the D2D connection update algorithm on the merged connection status database and ensuring that the resulting operation is possible and efficient).

[0090] In steps S407 and S407a (DB DU / SYNC), the D2D connection update algorithm is periodically executed on the connection status database to optimize the D2D network and return actions to accommodate changes in the location and structure of the UEs that comprise the network. UEs can continuously update the connection status database based on the received signal strength of their D2D and cellular connections, and optionally their location and movement. Furthermore, UEs within the D2D can synchronize the distributed connection status database.

[0091] Once a predetermined period has ended (which may begin from the time of EAM reception), the D2D network initiated by the EAM can be shut down (while other unrelated D2D networks, including UE, remain unaffected).

[0092] Figure 5 is a schematic diagram illustrating an example of a network topology showing the delivery of five UEs (UE1 through UE5) and their associated emergency messages and metrics.

[0093] In the topology shown in Figure 5, the EAM is transmitted and received by connected UEs (UE1 to UE3) connected to the transmitting BS via their respective cellular connections, and the D2D connection is not stored in the connection status database (CS-DB). As a result, the alarm is displayed only on the three UEs from UE1 to UE3.

[0094] In the topology below, a D2D network is established that includes all UEs from UE1 to UE5 and is maintained in the CS-DB connection status database. EAMs can be transmitted via D2D connections (sidelink connections) between UE1 and UE2, UE2 and UE3, UE3 and UE4, UE3 and UE5, and UE4 and UE5. As a result, alarms are displayed in all five UEs from UE1 to UE5.

[0095] In addition to the basic functions described above, in embodiments that can be used in combination with other embodiments or independently, the relay unit can evaluate whether to deliver an emergency message or its indicators based on a set of criteria. These criteria can be set in the relay unit by policies that can be defined by the communication network (e.g., by a policy control function (PCF)). Network policies can be a set of conditions, constraints, and settings that allow specifying, for example, who is authorized to connect to the network and the circumstances under which they can or cannot connect. Additionally or alternatively, they can also be set in corresponding protocols that determine the behavior in this regard (e.g., as part of non-access layer (NAS) message exchange with AMF or other network services / functions within the communication network, as part of a protocol between a device and a public alarm system or public safety response station (PSAP), or as part of a protocol between a device and an application function (AF) communicating via a network exposure function (NEF) by the communication network). This adds a layer of complexity to the process, but also provides beneficial flexibility and adaptability in specific situations. For example, criteria for determining whether an emergency message or its indicator should be delivered are provided as part of a paging message, RRC message, DCI message, or MAC CE message sent prior to the emergency message or its indicator. Another example is that the emergency message or its indicator includes supplementary data (e.g., additional criteria or information to help evaluate the criteria) to help the device determine whether and / or how the message or its indicator should be delivered.

[0096] Additionally or alternatively, relay units may determine one or more criteria themselves, independently evaluate whether to forward emergency messages or their indicators, and provide these criteria to the communication network or other relay units using configuration protocols. Additionally or alternatively, the criteria determining the behavior of relay units in sending emergency-related messages may be set by guidelines (e.g., policies or other preconfigurations). This allows for process standardization and ensures that all units in the network operate in a consistently coordinated manner.

[0097] In embodiments that can be used in combination with other embodiments or independently, the relay unit may use a variety of strategies to manage the delivery of emergency messages. These strategies include preemptive communication strategies (e.g., delivering a message if it knows of one or more neighboring devices that are outside the network's coverage) and collision avoidance strategies (e.g., delivering a message only if it is known not to interfere with other entities (e.g., RAN nodes or other relay nodes)). These strategies can help ensure that messages are delivered efficiently and effectively without unnecessary delays or collisions. These strategies can be enforced by criteria set and / or used by the relay unit, which may include a set of conditions (e.g., the minimum or maximum number of neighboring devices that have recently attempted to discover each relay unit, or the minimum or maximum signal strength / quality of messages received from neighboring base stations or other relay units).

[0098] In embodiments that can be used in combination with other embodiments or independently, determining communication resources for delivering emergency messages or their indicators includes determining the time and / or frequency and / or number of times to send emergency messages in order to maximize the likelihood that other devices will receive the emergency messages or their indicators.

[0099] In embodiments that can be used in combination with other embodiments or independently, a relay unit that receives an emergency message or its indicator may initiate a discovery process (e.g., ProSe Model B discovery on the PC5 interface) and forward and / or send the emergency message and / or its indicator during or after the discovery of a UE that is not currently connected to the relay unit in order to reach the UE that is not currently connected to the network or the relay unit. For this purpose, the relay unit may send discovery messages and / or paging messages and / or emergency messages and / or scheduling messages (e.g., SCI) containing the emergency message and its indicator. Such discovery messages and paging messages and / or emergency messages and / or scheduling messages may include broadcasts and group casts (e.g., ETWS / CMAS) of the emergency message and pointers to other messages broadcast by the relay unit. Additionally or alternatively, the relay unit may also send discovery messages and / or paging messages and / or emergency messages and / or scheduling messages to private groups or single users, such as remote nodes connected to a selected relay unit or UEs that share a group ID, group key, and / or address. This behavior of sending emergency-related messages can be configured by policy. In embodiments that can be used in combination with other embodiments or independently, the relay unit can transmit discovery messages and / or page messages and / or page alert messages and / or RRC messages and / or SCI messages and / or MAC communication messages containing information about the emergency message (e.g., the type of emergency message) and / or the content of the emergency message to a specific group or individual user. This is useful when the emergency message concerns a specific group or individual.For this purpose, discovery messages and / or paging messages and / or page alert messages and / or RRC messages and / or SCI messages and / or MAC CE messages may include information about a specific group identifier, UE identifier, or user identifier to which an emergency message should be sent. This information is set by an SIB received by the relay unit from the gNB, which includes information such as the specific group identifier, UE identifier, or user identifier to which an emergency message should be sent. Relay units and remote units may be set with a group key used to protect emergency messages (e.g., through encryption or integrity protection).

[0100] In embodiments that can be used in combination with other embodiments or independently, the device may transmit an emergency message (e.g., its content and type) or an indicator of its availability (e.g., a flag indicating the availability of an emergency message) embedded in a PC5 discovery message (e.g., a ProSe Model A / B discovery message) or a PC5 connection setup message (e.g., a direct communication request message) transmitted over the PC5 interface. This is useful for alerting other units in the network to the presence of an emergency message, for example, if they are not currently connected to or listening via a RAN node (such as a base station) because they are out of coverage, or if they are not currently connected to or listening via a relay node (e.g., because they are not yet synchronized with a relay node, or because they have not previously discovered the presence of a relay node), and can facilitate the rapid delivery of the message. This can also be used to facilitate the construction of an "emergency network" because devices may attempt to connect to obtain information about public alerts or emergencies, or if people may simultaneously initiate calls to contact relatives. By constructing such an emergency network, it is possible to prevent overloading of RAN nodes. A good example is a tsunami warning, which many people are concerned about.

[0101] In additional embodiments, which may be used in combination with or independently of other embodiments, a relay node may send a PC5 connection setup message as soon as a remote node / unit (e.g., a 5G ProSe remote UE) attempts to discover it (for example, by sending a ProSe Model A / B discovery message that includes a specific identifier for this purpose, a reserved / assigned relay service code for setting up such an emergency relay / ad-hoc network for delivering EAM, and / or for temporarily enabling communication with the cellular core network through this emergency relay / ad-hoc network), or based on instructions from the network (e.g., from a base station or core network function) that may know of the presence of a particular device in the area (e.g., because it was previously registered with the network and has just gone out of coverage). For this purpose, these instructions from the network may include an identifier for a particular device in its area and / or a resource schedule used to reach that particular device (e.g., by sending a PC5 connection setup request).

[0102] In another embodiment, which may be used in combination with other embodiments or independently, a remote node receiving such an emergency message or its indicator (e.g., a 5G ProSe remote UE, also referred to in this disclosure as a remote unit or remote device) may be configured and / or requested and / or triggered to set up a PC5 connection with the relay node that received the emergency message or its indicator from there. Once the remote node is connected to the relay node via the PC5 connection, it may be excluded from a list of devices to which the emergency message or its indicator should be further delivered. Such a list of devices may be stored in the relay node or centrally within the network (e.g., all relay nodes that have successfully reached a remote device may notify the network of the identifier of that remote device and / or send a message through their respective relay nodes to register the remote device with the network, notify of its presence and / or to indicate that it has successfully received the emergency message or its indicator). Relay nodes can be connected to such a central storage device (e.g., the connectivity database in Figure 3) that indicates identifiers of remote devices that have already been reached or have not yet been reached, and / or can receive updates from the network about one or more identifiers of remote devices that have already been reached or have not yet been reached, which can be used when each relay node delivers an emergency message or an indicator thereof.

[0103] In embodiments that can be used in combination with other embodiments or independently, the relay unit may transmit an emergency message or an indicator thereof to an idle or inactive remote unit in a time slot that depends on the time slot in which the relay received the emergency message or its indicator, or received a paging, RRC, or DCI / SCI message prior to the emergency message or its indicator, and / or a pre-configured first delay. Additionally or alternatively, the device may decide to introduce a second delay between the transmission of the emergency message indicator (or the emergency message itself) through the PC5 communication interface and the transmission of the actual emergency message (or a retransmission of the emergency message) through the PC5 communication interface. This ensures that the message is delivered to all relevant units in the network, even if they are not currently active.

[0104] In another embodiment, which may be used in combination with other embodiments or independently, the relay unit transmits discovery messages and / or paging messages and / or page alert messages and / or RRC messages and / or SCI messages and / or MAC CE messages, which include indicators and / or pointers to broadcasts and / or group casts of emergency message transmissions to one or more remote units or other relay units made by the relay unit, and the discovery messages and / or paging messages and / or page alert messages and / or RRC messages and / or SCI messages and / or MAC CE messages may include information about the timing and type of emergency message to be transmitted. This allows other units in the network to be notified of the presence / location of the emergency message, facilitating rapid delivery. The message indicators and / or pointers may be assigned (temporal or geographically) unique identifiers that can be used to label the emergency message, helping to determine whether other units have already received the emergency message and can skip the designated broadcast or group cast. The RRC message may be or may include an SIB received by the relay unit from a gNB, which contains information about the timing or type of emergency message to be transmitted by the relay unit.

[0105] In embodiments that can be used in combination with other embodiments or independently, a UE (e.g., a remote UE in the case of ProSe) may attempt to listen to a neighboring gNB by occasionally waking up and listening for MIBs / SIBs when it goes out of coverage. Thus, assuming this is somewhat synchronized with the gNB, if the gNB knows the discontinuous receive (DRX) schedule from its previous connection with its UE, it may notify the relay unit of this and ask the relay unit to broadcast in sync with the gNB's SIB6 / 7 / 8 transmissions. This can be done by transmitting in a different direction (e.g., using beamforming to avoid interfering with the gNB). Alternatively, the relay unit may use a different schedule, and / or the remote UE may increase the number and length of paging opportunities (POs) so that the UE can receive messages.

[0106] In a modified embodiment, if a UE (e.g., a remote node or relay unit, or a UE that could become a relay unit) goes out of coverage, it can be occasionally woken up to listen for Model A discovery messages from neighboring relay UEs, according to the sidelink discovery resource pool configured in the UE. Thus, Model A discovery can be extended with respect to the indicators or content of urgent messages.

[0107] In a modified embodiment, if a UE (e.g., a remote node, relay unit, or a UE that could potentially become a relay unit) goes out of coverage, it can occasionally wake up and listen for group messages via the sidelink according to the sidelink group message resource schedule. In this way, it can receive group casts containing urgent messages or their indicators.

[0108] In a modified embodiment, if a UE (e.g., a remote node, relay unit, or a UE that could become a relay unit) goes out of coverage, it may occasionally wake up and send a Model B discovery message to find a nearby relay unit. In that case, the relay unit can immediately report that an urgent message is available, for example, as part of a Model B discovery response sent from the relay unit to the UE.

[0109] In a concrete example, a method for delivering an emergency message within a communication network is provided. This method includes the steps of: receiving an emergency message or its indicator through a data interface or a first communication interface (e.g., a 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 the emergency message or its indicator should be delivered through a second communication interface of the relay unit (e.g., a PC5 communication interface or other communication interface (e.g., a non-3GPP interface such as Wi-Fi or Bluetooth)); determining the communication resources to be used to deliver the emergency message or its indicator (e.g., via the PC5 communication interface); and transmitting the emergency message or its indicator through the PC5 communication interface or other communication interface on the determined communication resources, wherein the step of determining the communication resources may include determining the time and / or frequency and / or number of times to transmit the emergency message or its indicator in order to maximize the opportunity for other devices to receive the emergency message or its indicator. A relay unit can be configured, for example, by corresponding protocols and guidelines (e.g., policies) that determine its behavior for evaluating whether to forward a message (for example, based on a set of criteria and a given probability as specified in the corresponding protocols and guidelines). One or more relay units can use preemptive communication strategies or collision avoidance strategies, which can also be configured by corresponding protocols and guidelines / policies.

[0110] In a related embodiment, one or more relay units can determine whether to groupcast and / or broadcast a message over the PC5 communication interface. The relay units also determine the communication resources that should be used to groupcast / broadcast the message over the communication interface. One or more relay units can then broadcast / groupcast the message over the communication interface using the determined communication resources.

[0111] In related embodiments, the method may further include one or more relay units transmitting or forwarding paging messages addressed to remote units in idle or inactive mode in time slots that depend on the time slot in which the relay unit received the paging message and a pre-configured time delay.

[0112] In a related embodiment, this method includes transmitting a discovery and / or page alert message that includes a pointer to a broadcast / groupcast of an emergency alert message made by one or more relay units.

[0113] In related embodiments, this method includes sending discovery / page messages to specific groups or individual users via one or more relay units.

[0114] In another embodiment, which can be used in combination with other embodiments or independently, an emergency message and its indicators may include supplementary data for relay units to determine whether or not to (re)broadcast (or groupcast) the message, and how to (re)broadcast (or groupcast) it. For example, an (emergency) message may include metadata for relay units to determine whether and how to (re)broadcast (or groupcast) the message. For example, a paging message may include flags that determine whether the paging message should be (re)broadcast (or groupcast) or whether discovery processing should be performed. For example, an emergency message may include a threshold that determines whether a relay unit should (re)broadcast (or groupcast) it (for example, if the signal strength of a received emergency message is below a threshold). Supplementary data may be determined by the communication network and transmitted to relay units, for example, by the core network, and / or supplementary data may be determined by the relay unit itself and transmitted to other relay units.

[0115] In another embodiment, which can be used in combination with other embodiments, not only the emergency message itself but also paging or discovery messages may be sent / forwarded, because otherwise idle or inactive UEs may not be able to receive forwarded emergency messages.

[0116] In another embodiment, which can be used in combination with other embodiments, a relay unit that forwards an emergency message or an indicator thereof may return to the RRC_CONNECTED state in order to send an emergency message. Nodes that do not forward emergency messages do not need to return to the RRC_CONNECTED state unless necessary to receive the message.

[0117] In another embodiment, which can be used in combination with other embodiments or independently, a relay unit transmits, forwards, and retransmits an emergency message or its indicator n times, and labels the message so that nodes that have received it multiple times can be quickly identified. This behavior regarding the transmission of emergency (related) messages (e.g., the number of times an emergency message with a particular label can be received) can be configured by a policy (e.g., received from the core network) or by configuration information received from gNB and / or other relay units, for example, by configuration information regarding the number of repetitions included in supplemental data or RRC / SIB messages (which can be transmitted as part of the emergency message or its indicator). The policy and / or configuration information may include information about the delay between various repetitions, and information about which modulation coding scheme (MCS) and / or frequency and / or resource and / or timing to use for various repetitions.

[0118] In another embodiment, which can be used in combination with other embodiments or independently, an emergency message or its indicator can be transmitted in a multi-hop relay communication (e.g., with a maximum number of hops), and the number of hops can be added to and / or suffixed before and / or after the emergency message or its indicator, and each relay unit can be configured to increase the number of hops until it reaches the maximum number of hops or decrease it until it reaches zero, at which point the relay unit will no longer forward the emergency message. In this case, a 5G ProSe UE-to-network relay or inter-UE relay acting as an intermediary relay node between a remote UE (or other intermediate relay node) and a 5G network (or other intermediate relay node) performs the duplicate detection function defined in TS 23.041 to suppress duplicate alarm messages received on the PC5. This behavior for sending emergency-related messages (e.g., whether the maximum number of hops, hop counter increment or decrement is used) can be configured by policies (e.g., received from the core network) or through configuration information received from gNBs and / or other relay units, such as configuration information regarding the number of repetitions included in supplemental data or RRC / SIB messages (sent as part of the emergency message or its instructions).

[0119] In another embodiment, which may be used in combination with other embodiments or independently, the relay unit may determine whether it is approaching a cell edge (e.g., distance from the serving base station to indicate the final end of the cell's coverage area) in accordance with protocols and instructions from a network base station, and based on that determination, begin evaluating whether to forward the emergency message or its indicator via a second communication interface (e.g., PC5) and / or transmit the emergency message or its indicator via the second communication interface, before or after receiving the emergency message or its indicator received through a first communication interface (e.g., Uu). For example, the relay unit may perform an evaluation to determine whether it is approaching a cell edge based on policies and instructions from a network base station (e.g., provided through RRC messages such as RRC reconfiguration messages). This decision is based, for example, on channel status information (CSI) information or channel quality (e.g., reference signal received power (RSRP) or reference signal received quality (RSRQ)) against a pre-agreed threshold, or on the signal strength of a measured reference signal (e.g., the signal strength of a received emergency message or its indicator) against a pre-agreed or configurable threshold, or on the number of cells from which SIBs or other messages can be monitored and / or received. Additionally or alternatively, this decision can be based on information about the distance from the communication network to the received cell, for example, a wireless network (e.g., a network base station) can keep relay units informed of the distance to the cell by providing an estimate of the distance between the relay unit and the cell. Additionally or alternatively, the communication network can determine which UEs are closer to the cell edge and which can function as relay units, and instruct only selected UEs / relay units close to the cell edge to forward the emergency message or its indicator as part of the emergency message or its indication (e.g., as part of auxiliary data) (e.g., by including a list of identifiers for the selected UEs / relay units).Additionally or alternatively, this decision is based on positioning and distance measurement operations, which allow the relay unit to determine its relative position and distance from the network base station, and use them (for example, based on a maximum distance threshold or coverage map) to determine whether it is approaching a cell edge.

[0120] In an embodiment, a system for delivering emergency messages within a communication network can be provided. This system includes one or more relay units, which receive an emergency message or an indicator thereof via a data interface or a first communication interface, determine whether the emergency message or its indicator should be (re)broadcast / groupcast via a second communication interface, determine the communication resources to be used to (re)broadcast / groupcast the emergency message or its indicator in the second communication interface, and are configured to (re)broadcast / groupcast the emergency message or its indicator in the second communication interface.

[0121] In a relevant embodiment, relay units can be connected to and controlled by an entity within the communication network (e.g., a network base station), which can instruct selected relay units (e.g., those at the cell edge) to forward messages based on a set of criteria, for example, set by a policy. For example, a relay unit may be configured to forward urgent messages or their indicators only if it is at the cell edge. A relay unit can determine its likelihood of being at the edge based on the signal strength of a received message and the number of cells it can monitor and / or receive from, or the network can keep informing the relay unit of its distance from those cells. In a particular example, the network can instruct selected relay units (those not at the cell edge, or those close to other relay units) not to forward a message.

[0122] In some embodiments, the communication network can instruct relay units (e.g., a selected set of relay UEs) to forward an urgent message or an indicator thereof with a certain probability. This allows for the management of message delivery and ensures that it is delivered in a timely and efficient manner.

[0123] In embodiments that can be used in combination with other embodiments or independently, the communication network can instruct (potential) relay units (e.g., a selected set of relay units) to forward a message with probability p, and the relay units can generate a random number r. For example, if r = p, or if r falls within a certain interval of the distribution function values ​​(the length of the interval determines the probability p), the relay unit forwards the message; otherwise, it discards the message (this also applies to relay units located at the edges of cells). Which device (e.g., a relay unit) retransmits the message may also depend on other factors (e.g., the time slot in which the urgent message is sent (e.g., the system frame number (SFN)), or a (random) number between 1 and 10 included in the (transmitted) urgent message or its indicator), in which case the probability p may depend on such time slots or numbers (e.g., the relay unit forwards the message only if the set value is equal to the remainder of the sum of the time slot set values ​​(e.g., 1 to 10), and / or a specific set probability is assigned to each value, which the relay unit must use to determine whether to forward the message). Relay units can generate different numbers and time slots and forward those numbers and time slots to other relay units, including them in emergency messages and their indicators. Relay units can avoid sending messages in time slots that would result in the same number being omitted or the relay unit itself having the same truncated value (such as time slot modulo 10) set by that value. In this way, the same number or shortened time slot value is not used again, minimizing duplication while optimizing the chances of other relay units and remote units that have not previously received a message receiving it, if other relay units and remote units are configured with different numbers and time slot values.

[0124] Additionally or alternatively, relay units are assigned categories and may or may not forward messages depending on the categories they contain.

[0125] In another embodiment, which can be used in combination with other embodiments or independently, the communication network may configure relay units (e.g., a selected set of relay UEs) to perform their own evaluation of whether or not to forward an incoming urgent message (or its indicator), and to configure those relay units by corresponding policies that determine their behavior, for example, by setting probabilities or categories as in the embodiments described above. A relay unit performing its own evaluation may, for example, use a “Listen-Before-Talk” strategy to listen for a random period of time to detect whether a neighboring relay unit is sending and / or forwarding and / or retransmitting a packet containing an urgent message or its indicator, and if so, suppress its own transmission and discard the message. A relay unit that has suppressed retransmission may notify the communication network and other relay units of this (e.g., why it suppressed retransmission) in order to provide the communication network and other relay devices with knowledge of alternative options.

[0126] In a modified embodiment, a relay unit performing its own evaluation can, for example, use a collision avoidance strategy that can perform random backoffs before discovery transmission. If it detects discovery and / or page messages transmitted from a neighboring node, it can perform another random backoff. After a certain number of backoffs, it can suppress its own transmission and discard the message. A relay unit that has suppressed retransmission can notify the communication network and other relay units about this (for example, why it suppressed retransmission) in order to provide the communication network and other relay devices with knowledge of alternative options.

[0127] In a modified embodiment, a relay unit performing its own evaluation can determine whether it is near a cell edge using RSRP measurements (e.g., based on a pre-configured RSRP threshold), and if it is not near a cell edge (e.g., within good coverage of a base station), it can suppress its own transmission and discard the message. The relay unit that suppressed retransmission can notify the communication network and other relay units of this (e.g., why it suppressed retransmission) in order to provide the communication network and other relay devices with knowledge of alternative options.

[0128] In embodiments that can be used in combination with other embodiments or independently, the relay unit may, upon receiving an urgent message, begin monitoring paging messages addressed to another UE, not itself. Upon receiving a paging message through the Uu interface, the relay may forward or retransmit the paging message based on a policy (e.g., on what occasions and / or which received paging messages should be forwarded) and the content of the paging message itself (e.g., whether or not it should be forwarded).

[0129] In a related embodiment, the relay unit rebroadcasts paging messages received from the base station during the same paging opportunity through the Uu interface so that the UE can receive them if the UE is not in the base station's coverage area. From this perspective, the relay unit can behave as a radio frequency (RF) repeater that extends coverage.

[0130] In a related embodiment, the relay unit rebroadcasts emergency messages received from the base station through the Uu interface in terms of time / frequency resources, so that UEs can receive them even if they are not in the base station's coverage. From this perspective, the relay unit behaves as an RF repeater that extends coverage.

[0131] In a related embodiment, the relay unit may or may not be an RF repeater and / or smart repeater (e.g., an RF repeater in a non-public network) which may or may not be under the control of a base station, and which RF repeater may detect emergency messages and, if configured, forward them.

[0132] In a related embodiment, the relay unit can rebroadcast paging messages received from the base station through the PC5 interface.

[0133] In a related embodiment, the relay unit can send or forward an addressed paging message to an idle or inactive UE in a time slot that depends on the time slot in which the relay unit received the paging message and a predetermined offset (for example, T_sending = T_receiving + offset, or frequency resources may also be predetermined), and frequency resources may also be predetermined. This allows the idle or inactive UE to monitor paging opportunities on the Uu interface and on the PC5 interface, with the paging opportunities on the PC5 interface being delayed by the offset relative to the paging opportunities on the Uu interface.

[0134] In embodiments, a relay unit can add information to a received emergency message before forwarding / re-broadcasting the emergency message. For example, it may be useful to share information among members of a UE group or group of members and add that information to the same emergency message or send it in a separate subsequent message. For example, a network could send a fire alarm message to a node monitoring a forest, and any node that detects an abnormal temperature rise and / or smoke or light from the fire could add (e.g., append) that information to the message.

[0135] In embodiments that can be used in combination with other embodiments or independently, a receiver (e.g., an IoT device) that can play a role in mitigating an emergency (e.g., an actuator node such as a sprinkler installation in the event of a fire hazard) can be instructed and / or (pre-configured) to acknowledge discovery messages and / or paging messages announcing an emergency message, and / or to acknowledge that the emergency message has been successfully received.

[0136] In embodiments that can be used in combination with other embodiments or independently, emergency messages or their indicators, or instructions indicating the setup of an emergency ad-hoc network, may be received through non-terrestrial network (NTN) devices such as satellites or unmanned aerial vehicles (UAVs) that function as relays or access devices for a cellular communication network. NTN access devices are suitable for delivering emergency messages or indicators (for example, when ground base stations are down due to a natural disaster), and there may be a need for the selection of relay devices that can receive emergency messages / indicators from NTN access devices and deliver them locally, and / or deliver local messages when an emergency ad-hoc network is activated. Non-terrestrial network devices transmit emergency messages or their indicators at high power levels or with additional security features such as encryption or authentication, so that the device (e.g., UE) and other devices within its coverage area can receive them and determine their role in the delivery of emergency messages and / or local messages. For example, a non-terrestrial network device may transmit a paging message containing an indicator of an emergency message and / or instructions to set up an ad-hoc emergency network through a second data or communication interface. The device can decide whether to join an ad-hoc emergency network and forward paging messages or emergency messages to other devices through a second data or communication interface. The second data or communication interface may be a sidelink interface, such as a PC5 interface, which enables direct communication between devices without relying on the network infrastructure. Alternatively, the second data or communication interface may be another interface that enables communication with the network infrastructure, such as a Uu interface. The device may select the second data or communication interface based on the availability of network resources, the type and priority of the emergency message, the device configuration, and / or the policies of the network operator or user.

[0137] In embodiments that can be used in combination with other embodiments or independently, a device that transmits an emergency message or indicator, and / or a device that receives an emergency message or indicator from, for example, an NTN access device, may determine and / or indicate which device should respond to the emergency message or indicator based on one or more of the following factors: - For example, the location of a device identified by a global positioning system (GPS) or other geolocation means, and the relevance of an emergency message or its indicator to the location of that device; - The type or category of devices such as sensors, actuators, terminals, and relays, and the role or function of these devices in emergencies; - Device settings and policies (user preferences, network operator settings, device capabilities, etc.), and device compatibility and suitability for emergency messages and their indicators; - Device availability and status, such as battery level, connectivity, memory, and processing power, and the device's feasibility and efficiency in performing the actions required by emergency messages or their indicators.

[0138] The device may determine and / or indicate which device should respond to an emergency message or its indicators using one or more of the following methods: - For example, adding or inserting a field or flag into an emergency message or its indicators that specifies which devices should respond, using device identifiers, device group identifiers, device attributes, device locations, etc.; - For example, sending a separate message to a device that should respond to an emergency message or its indicators by using unicast, multicast, or broadcast transmission through a second data or communication interface; - For example, encrypting or signing an emergency message or its indicator with a key or certificate shared or recognized by the responding device, using symmetric or asymmetric encryption or digital signature methods; - For example, modulating or encoding an emergency message or its indicators in a pattern or code that is recognizable or decodeable by the responding device, using spread spectrum technology or error correction codes.

[0139] In general, the operations and steps described in the above embodiments can be performed by a system including a processor that executes a set of code for controlling the functional elements of the device. Furthermore, certain processes are performed using dedicated hardware.

[0140] In summary, a method and system for delivering emergency messages within a communication network, including relay units that receive messages through data or communication interfaces, was described. These relay units determine whether a message should be rebroadcast on the communication interface and the communication resources to be used for rebroadcasting. The message is then rebroadcast on the communication interface. Relay units perform their own evaluations of message forwarding and determine their own behavior, configured in the protocol. Relay units can use preemptive communication strategies or collision avoidance strategies. Relay units can send or forward discovery / alert messages, including emergency alert messages and their indicators.

[0141] Furthermore, the present invention can be applied to mobile phones, vital sign monitoring / telemetry devices, smartwatches, detectors, vehicles (vehicle-to-vehicle (V2V) communication or more generally vehicle-to-everything (V2X) communication), V2X devices, IoT hubs, low-power medical sensors for health monitoring, IoT devices including medical (emergency) diagnostic and treatment devices for hospitals or first responders, virtual reality (VR) headsets, and the like.

[0142] Other modifications of the disclosed embodiments can be understood and implemented by those skilled in the art in carrying out the claimed invention, from a consideration of the drawings, disclosures, and appended claims. In the claims, the word “has” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude plurality. A single processor or other unit can fulfill the functions of several items enumerated in the claims. The mere fact that certain means are described in mutually different dependent claims does not imply that combinations of these means cannot be used advantageously. The foregoing description details certain embodiments of the invention. However, however detailed the foregoing may be in the text, it will be understood that the invention can be carried out in many forms and is therefore not limited to the disclosed embodiments. It should be noted that the use of certain terms in describing certain features or embodiments of the invention does not mean that the terms are redefined herein to limit them to certain features of the features or embodiments of the invention to which they relate. Furthermore, the expression “at least one of A, B, and C” should be understood disjunctively, i.e., “A and / or B and / or C”.

[0143] A single unit or device may perform the functions of multiple items cited in a claim. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0144] The operations described in the above embodiments can be implemented as program code means for a computer program, or as dedicated hardware for associated network devices or functions, respectively. The computer program may be stored and / or delivered 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 it may also be delivered in other forms such as the Internet or other wired or wireless telecommunications systems.

Claims

1. A device for distributing emergency messages such as public warning messages (PWM) and other high-priority messages within a cellular communication network, Receiving an emergency message or its indicator through the first data or communication interface, Based on a set of criteria, it is determined whether the emergency message or its indicator should be delivered to other devices through a second data or communication interface. Determine the communication resources to be used to deliver the emergency message or its indicator to the second data or communication interface. A device that transmits the emergency message or its indicator through the second data or communication interface on a determined communication resource.

2. It is determined whether the emergency message or its indicator should be delivered by broadcast and / or groupcast communication through the second data or communication interface, which is a PC5 communication interface. The apparatus according to claim 1, wherein one or more relay units broadcast and / or groupcast the emergency message or its indicator through the PC5 communication interface.

3. The apparatus according to claim 1 or 2, wherein at least one of the set of criteria for determining whether the emergency message or its indicator should be delivered is set by a communication network through a set of policies.

4. The apparatus according to claim 1 or 2, wherein at least one of the set of criteria for determining whether the emergency message or its indicator should be delivered is provided as part of a paging message and / or a radio resource control (RRC) message and / or a downlink control information (DCI) and / or a MAC CE (Medium Access Control Control Element) message transmitted prior to the emergency message or its indicator.

5. The apparatus according to claim 1 or 2, wherein the emergency message or its indicator includes auxiliary data that helps the apparatus determine whether and / or how the emergency message or its indicator should be delivered.

6. The apparatus according to claim 1 or 2, configured to determine one or more criteria, evaluate whether or not to forward the emergency message or its indicators, and to provide the one or more criteria to the communication network or other relay units using a configuration protocol.

7. The apparatus according to claim 1 or 2, configured to use a preemptive communication strategy or a collision avoidance strategy.

8. The apparatus according to claim 1 or 2, configured to transmit the emergency message or an indicator thereof embedded in a PC5 discovery message or PC5 connection setup message transmitted via a PC5 communication interface.

9. The apparatus according to claim 1 or 2, configured to transmit the emergency message or its indicator to a remote unit in idle or inactive mode during a time slot in which the apparatus receives the emergency message or its indicator, or during a time slot in which the apparatus receives a paging message, radio resource control (RRC) message, or downlink / sidelink control information (DCI / SCI) message preceding the emergency message or its indicator, and during a predetermined time delay.

10. The apparatus according to claim 1 or 2, configured to transmit discovery messages and / or paging messages and / or page alert messages and / or RRC messages and / or SCI messages, which include indicators and / or pointers for broadcasts and / or group casts of emergency message transmissions performed by the apparatus, wherein the discovery messages and / or paging messages and / or page alert messages and / or RRC messages and / or SCI messages include information regarding the timing or type of the emergency message being transmitted.

11. The apparatus according to claim 1 or 2, configured to use the probability of forwarding the emergency message or its indicator as a criterion for determining whether or not to deliver the emergency message or its indicator.

12. The apparatus according to claim 1 or 2, wherein the apparatus is configured to determine whether it is close to the edge of a cell and to use this determination as a criterion for delivering the emergency message or an indicator thereof.

13. The apparatus according to claim 1 or 2, configured to query, through the connection, whether another device has received the emergency message or an indicator thereof, or to respond to a query for determining whether an emergency message or an indicator thereof has been received.

14. A system for distributing emergency messages over a communication network, comprising one or more relay units including the device described in claim 1 or 2.

15. The system according to claim 14, comprising one or more relay units configured to proactively set up an ad hoc communication network upon receiving an emergency message or an indicator thereof, wherein the ad hoc communication network operates for a predetermined period after receiving the emergency message.

16. A method for delivering emergency messages over a communication network, The steps include receiving an emergency message or an indicator thereof through a first data or communication interface by one or more relay units, A step of determining whether the emergency message or its indicator should be delivered through a second data or communication interface based on a set of criteria, The steps include determining the communication resources to be used to deliver the emergency message or its indicator through the second data or communication interface, A method comprising the step of transmitting the emergency message or its indicator through the second data or communication interface in a determined communication resource.

17. A computer program that is executed on a computer and causes the computer to perform the method described in claim 16.

Images