SYSTEMS AND METHODS FOR MONITORING AND EFFICIENTLY TESTING NETWORK RESOURCE AVAILABILITY AND CONFIGURATION FOR PUBLIC WARNING SYSTEMS

Abstract

A simulated Public Warning System (PWS) message is defined for efficient PWS testing. The simulated PWS message mimics a conventional PWS message, but indicates that it is not to be propagated across an air interface to UEs. However, the simulated PWS message is otherwise propagated through the network as a PWS message. This allows for testing the generation and propagation of PWS messages, without wasting valuable air interface and battery resources. In some embodiments, network nodes may initiate testing by requesting a simulated PWS message. An Access and Mobility management Function (AMF) node in a wireless communication network collects and reports network status to a PWS entity. The AMF node ascertains the functionality of network functions, nodes, and interfaces to which it is connected, independently from receiving reports of such functionality, and an indication of any detected fault or failure is sent to the PWS entity.

Claims

1. A method, performed by a Public Warning System (PWS) entity within or connected to a wireless communication network, of testing PWS functionality in the network, comprising: generating a simulated PWS message that indicates the message is not to be propagated across an air interface to a User Equipment (UE), but otherwise propagated through the network as a PWS message; and sending the simulated PWS message into the network.

2. The method of claim 1, wherein the simulated PWS message comprises a new standardized Message Identifier.

3. The method of claim 1, wherein the simulated PWS message comprises the PWS message having an Information Element (IE) indicating the message is not to be propagated across the air interface.

4. The method of claim 3, wherein the IE further indicates that a network node should ascertain that coverage for an area over which the message is to be broadcast, is active.

5. The method of claim 4, wherein the area over which the message is to be broadcast is defined by a list of cells, and wherein ascertain that coverage for the area is active comprises ascertaining that the cells on the list are active and in service.

6. The method of claim 3, wherein the IE further indicates that a network node should ascertain that one or more of air interface resources and transport resources needed to forward the PWS message to a base station network node are available.

7. The method of claim 1, further comprising, prior to generating and sending the simulated PWS message: receiving from a network node an indication of a need for PWS testing; and wherein generating and sending the simulated PWS message is done in response to receiving the indication of the need for PWS testing.

8. The method of claim 7, wherein the indication of the need for PWS testing received from the network node comprises a new standardized Message Identifier.

9. The method of claim 7, wherein the indication of the need for PWS testing received from the network node comprises the PWS message having an Information Element (IE) indicating the need for PWS testing.

10. The method of claim 7, wherein: the indication of the need for PWS testing received from the network node identifies a broadcast area towards which PWS testing should be performed; and generating the simulated PWS message in response to receiving the indication of the need for PWS testing comprises generating the simulated PWS message to cover only the identified broadcast area.

11. A node, within or connected to a wireless communication network, and fully or partially implementing Public Warning System (PWS) functionality, comprising: one or more communication interfaces; and processing circuitry operatively connected to the communication interfaces and configured to: generate a simulated PWS message that indicates the message is not to be propagated across an air interface to a User Equipment (UE), but otherwise propagated through the network as a PWS message; and send the simulated PWS message into the network.

12-20. (canceled)

21. A method, performed by an Access and Mobility management Function (AMF) in a wireless communication network, of ascertaining and reporting network status to a Public Warning System (PWS) entity, comprising: ascertaining functionality of network functions, nodes, and interfaces to which it is connected, independently from receiving reports of the functionality; and upon detecting a fault or failure of a network function, node, or interface, independently from receiving notification of the fault or failure, sending an indication of the fault or failure to the PWS entity.

22. The method of claim 21, wherein sending the indication of the fault or failure to the PWS entity comprises sending the indication of the fault or failure to the PWS entity in response to the PWS entity initiating PWS service in the network.

23. The method of claim 21, wherein the indication of the fault or failure includes one of a list of Tracking Area Codes (TAC) and a list of Tracking Area Indications (TAI) subject to outage due to the detected fault or failure.

24. The method of claim 21, wherein the indication of the fault or failure includes a list of Cells subject to outage due to the detected fault or failure.

25. The method of claim 21, wherein the indication of the fault or failure includes a type of fault or failure detected.

26. The method of claim 21, wherein the indication of the fault or failure includes identification of the faulted or failed function, node, or interface.

27. The method of claim 21, further comprising: ascertaining that the fault or failure, which existed when the PWS entity initiated PWS service in the network, has been cured; and sending an indication to the PWS entity to restart the PWS service.

28-34. (canceled)

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. However, this invention should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

[0039] FIGS. 1A-1C are block diagrams of various wireless communication network architectures for implementing a Public Warning System (PWS).

[0040] FIG. 2 is a block diagram of Central and Distributed Units of a Radio Access Network.

[0041] FIG. 3 is a message flow diagram of a PWS message propagating through a wireless communication network from the generating entity to a UE.

[0042] FIG. 4 is a message flow diagram of a PWS failure or restart message propagating through a wireless communication network from a RAN node to the PWS generating entity.

[0043] FIG. 5 is a message flow diagram of a dry-run PWS test message propagating through a wireless communication network from the PWS generating entity to a RAN, that is not broadcast to UEs.

[0044] FIG. 6 is a message flow diagram of an AMF node notifying a PWS generating entity of a discovered network fault, and requesting a PWS test.

[0045] FIG. 7 is a flow diagram of a method of testing PWS functionality in a network.

[0046] FIG. 8 is a block diagram of a network node.

[0047] FIG. 9 is a flow diagram of a method of testing PWS functionality in a network.

DETAILED DESCRIPTION

[0048] For simplicity and illustrative purposes, the present invention is described by referring mainly to an exemplary embodiment thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be readily apparent to one of ordinary skill in the art that the present invention may be practiced without limitation to these specific details. In this description, well known methods and structures have not been described in detail so as not to unnecessarily obscure the present invention.

[0049] As discussed above, it is desired for an emergency service provider to have up-to-date status of network sanity, resource availability, and message content sanity well ahead of a time of actual disaster. However, running a full-blown PWS test with high periodicity (for example, on the order of hourly) is quite expensive in wasted network resources and power consumption. According to one embodiment of the present invention, which is directed to the first use case described above (network testing), the PWS entity of the 3GPP network (e.g., CBCF) or external to the network (e.g., CBE) may initiate a “dry-run” or “test-run” of propagating PWS message(s), but no actual transmission of the PWS messages occurs over the air interface Uu. As used herein, this is referred to as a “simulated PWS message,” or a “PWS simulation.” Based on the simulated PWS message, the network nodes act as if the message were going to be broadcast, and perform sanity checks of the received message, their configurations, the availability of resources, and the like, without actual transmission over the air. Potential faults are reported back through WRITE-REPLACE WARNING REPONSE/PWS FAILURE.

[0050] In one aspect of the present invention such a simulated PWS message is realized by a new standardized and/or reserved Message Identifier. FIG. 5 demonstrates the call flow.

[0051] In another aspect, such a simulated PWS message is realized by a new information element (e.g., a flag or the like) in the existing WRITE-REPLACE request messages. In yet another related aspect, this information element (IE) may only be applicable to some specific Message Identifiers (e.g., test messages) and ignored otherwise. This new IE indicates to the node in charge of broadcasting PWS messages over the air that the PWS message identified by the Message Identifier with the new IE included shall not be broadcast over the air interface. Alternatively, the IE may indicate to the receiving node that a number of tasks are performed, for example: [0052] Check that coverage for the area for which the message is assumed to be broadcast is active. For example, if a list of cells defines the broadcast area for the PWS message, this would translate into checking that these cells are active and in service. Check that resources needed to deliver and broadcast the message are available. [0053] Note that these resources may not be limited to air interface resources but also to, e.g., transport resources needed to forward the Write Replace Warning Request to the opportune network node. [0054] Check that the components hosting processes in charge of delivering and broadcasting the PWS message are correctly functioning and able to correctly process and deliver the message. For example, if a gNB-DU is connected to multiple Remote Radio Units (RRU), the IE could indicate to the gNB-DU to check that all the RRUs involved in the delivery of the PWS message are correctly operating and able to deliver the message.

[0055] One way to achieve encoding of the new IE in existing standardized messages is shown below with the example of the NGAP protocol:

[0056] 9.2.8.1 Write-Replace Warning Request

[0057] This message is sent by the AMF to request the start or overwrite of the broadcast of a warning message.

[0058] Direction: AMF->NG-RAN node

TABLE-US-00001 IE type and Semantics Assigned IE/Group Name Presence Range reference description Criticality Criticality Message Type M 9.3.1.1 YES reject Message Identifier M 9.3.1.35 YES reject Serial Number M 9.3.1.36 YES reject Warning Area List O 9.3.1.37 YES ignore Repetition Period M 9.3.1.49 YES reject Number of Broadcasts M 9.3.1.38 YES reject Requested Warning Type O 9.3.1.39 YES ignore Warning Security O 9.3.1.40 YES ignore Information Data Coding O 9.3.1.41 YES ignore Scheme Warning Message O 9.3.1.42 YES ignore Contents Concurrent O 9.3.1.46 YES reject Warning Message Indicator Warning Area O 9.3.1.112 YES ignore Coordinates DoNotBroadcast O Indicates that YES reject the PWS message identified by Message Identifier and Serial Number should not be broadcast over the air

[0059] The table above is copied from 3GPP TS 38.413, and lists IEs for the Write Replace Warning Message. The last element, DoNotBroadcast, has been added as one non-limiting example the inventive IE.

[0060] Furthermore, according to embodiments of the present invention, it is possible for a network node to indicate a potential need for PWS testing. The node may indicate such need based on a configuration or resource availability change that may be relevant to PWS provision, for example, a change in configuration related to cell bandwidth. Or as another example, a change in configuration related to broadcast functionality (e.g., SIB periodicity or the like). Alternately, a new/redundant node added to the network may initiate a sanity check is desirable. Such indication from the network node may be realized either through extension of existing messages, or by introducing new explicit messages targeted to this purpose. Based on such indication from various network nodes, the PWS entity may carry out a PWS transmission test in the specific area of the network, rather than broadly across the whole network or significant parts of it. Furthermore, the rate of testing may be reduced, since extra testing is carried out when necessary and appropriate, and the rate of other potential background testing can be reduced.

[0061] FIG. 6 depicts this method in one embodiment. Note that the test request generated towards the CBCF and/or CBC/PWS-IWF may identify a broadcast area towards which the test shall be performed.

[0062] In one aspect, the indicating network node, may further indicate or recommend the type of testing that should be carried out by the PWS entity. For example, it may indicate whether the testing should include transmission over the air (as per current specifications) or according to the PWS simulation procedure described herein. The request may be directed to the PWS entity (e.g., CBCF) or any other entity—including one external to the network that may initiate the PWS simulation.

[0063] FIG. 7 depicts the steps of a method 100, performed by a PWS entity within or connected to a wireless communication network, of testing PWS functionality in the network. The method includes generating a simulated PWS message that indicates the message is not to be propagated across an air interface to UE, but otherwise propagated through the network as a PWS message (block 102). The method then includes sending the simulated PWS message into the network (block 104).

[0064] FIG. 8 depicts a node 10, which for example may comprise a PWS entity, such as a CBCF (within the network) or a CBC/PWS-IWF (external to the network). The PWS entity 10 includes processing circuitry 12, memory 14 (which may be internal to the processing circuitry 12 as depicted, or may be separate), and communication circuitry 16. The memory 14 is configured to store, and the processing circuitry 12 is configured to execute, software instructions that cause the node 10 to implement the method 100 of testing PWS functionality in the network.

[0065] The processing circuitry 12 may comprise any sequential state machine operative to execute machine instructions stored as machine-readable computer programs in memory 14, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored-program, general-purpose processors, such as a microprocessor or Digital Signal Processor (DSP), or any combination of the above. The memory 14 may comprise any non-transitory machine-readable media known in the art or that may be developed, including but not limited to magnetic media (e.g., floppy disc, hard disc drive, etc.), optical media (e.g., CD-ROM, DVD-ROM, etc.), solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, Flash memory, solid state disc, etc.), or the like. The communication circuitry 16 may comprise a receiver and transmitter interface used to communicate with one or more other nodes over a communication network according to one or more communication protocols known in the art or that may be developed, such as Ethernet, TCP/IP, SONET, ATM, IMS, SIP, or the like. The communication circuits 12 implement receiver and transmitter functionality appropriate to the communication network links (e.g., optical, electrical, and the like). The transmitter and receiver functions may share circuit components and/or software, or alternatively may be implemented separately.

[0066] According to one embodiment of the present invention, which is directed to the second use case described above (failure/restart reporting), the AMF node supervises the connection and/or sanity of underlying RAN node(s) (e.g., N2 connection and/or sanity of gNB-CU(s)). The AMF may detect failures in N2 such as physical link breakage, or logical error over the NGAP. Furthermore, even though the interfaces are available, the AMF may detect that the serving gNB-CU is not responding or behaving properly (e.g., not responding to requests as it should, extensive delays in handling procedures, or the like). Based on such failure detections, the AMF may ascertain that the RAN is not able to serve potential PWS requests. As a result, the AMF node itself initiates failure reporting to the CBCF.

[0067] Such failures are detected while the PWS service is currently assumed to be provided in the network. That is, at the time of PWS service start (initiated by CBCF) the underlying subsystem was functional and CBCF believes that the service is ongoing while the AMF detects the failures. In one aspect of the present invention, the AMF initiates the failure indication towards the CBCF while PWS is believed to be ongoing, or active.

[0068] Alternatively, such failure may be detected by AMF while no PWS service is ongoing in the network. As such, in one aspect of the present invention, at the point in time when CBCF initiates PWS, AMF notifies the CBCF that there is a failure; either with a FAILURE INDICATION message or through extension of response messages (WRITE-REPLACE-WARNING-CONFIRM/INDICATION) to the PWS Write Replace Request.

[0069] The failure message generated by the AMF towards the CBCF (or equivalent node in charge of starting PWS services) may include information concerning one or more of the following: [0070] A list of Tracking Area Codes (TAC) and/or Tracking Area Indications (TAI) subject to outage due to detected failure. [0071] A list of Cells subject to outage due to detected failure. [0072] A list of identifiers, e.g., NG RAN node IDs, identifying the nodes affected by the failure. [0073] The failure type detected, e.g., link breakage, unexpected node behavior, or unresponsive node (despite NGAP signaling connection working).

[0074] In another aspect of the present invention, the RAN was unaware of potential PWS start during outage, while the AMF has such knowledge and could have provided, inter alia, the above failure indications. In this aspect, in case of RAN recovery, the AMF initiates RESTART message towards the CBCF when the underlying nodes/interfaces become available again, enabling the CBCF to reload PWS messages, if still relevant.

[0075] In all aspects of the present invention, the messages used for PWS failure/fault indication (whether explicit failure indications, or confirm/response messages) are extended to carry information towards CBCF (or any other node interested in the information) that a failure is within a specific node of the network (e.g., AMF, gNB-CU, gNB-DU) or an interface thereof (e.g., N2 link breakage, F1AP link breakage, or the like) and furthermore include an implicit or explicit identity of the node, from which the specific node location can be derived.

[0076] FIG. 9 depicts the steps of a method 200, performed by an AMF in a wireless communication network, of ascertaining and reporting network status to a PWS entity. The method includes ascertaining the functionality of network functions, nodes, and interfaces to which it is connected, independently from receiving reports of such functionality (block 202). The method then includes, upon detecting a fault or failure of a network function, node, or interface, independently from receiving notification of such a fault or failure, sending an indication of the fault or failure to the PWS entity (block 204).

[0077] The node 10 depicted in FIG. 8 may for example comprise a network node implementing an AMF. As described above, the AMF 10 includes processing circuitry 12, memory 14 (which may be internal to the processing circuitry 12 as depicted, or may be separate), and communication circuitry 16. The memory 14 is configured to store, and the processing circuitry 12 is configured to execute, software instructions that cause the network node 10 to implement the method 200 of ascertaining and reporting network status to a PWS entity.

[0078] Embodiments of the present invention present numerous advantages over the prior art. The simulated PWS message described herein allows robust testing of network resources used in PWS propagation and delivery, without wasting expensive air interface resources or depleting UE batteries. Various network nodes can request such PWS simulation as appropriate (e.g., upon a change in configuration, capacity, coverage, or the like). The ability of an AMF node to report network faults or failures to the PWS entity improves PWS robustness by exposing network shortcomings that the PWS entity may never see in prior art systems (or which may be reported with insufficient specificity). In short, embodiments of the present invention allow the network to keep track of, and act against, potential failure of network functions, nodes, and interfaces critical to the PWS well ahead of actual disaster, and do so in a non-intrusive and non-wasteful manner.

[0079] As used herein, the term “configured to” means set up, organized, adapted, or arranged to operate in a particular way; the term is synonymous with “designed to.”

[0080] The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.