Method and apparatus for public warning system indication and acquisition in wireless networks

Abstract

This document describes systems and methods for indicating to a user equipment (UE) that a public warning system (PWS) is to be, and is being broadcasted, and for the UE to acquire the PWS broadcast.

Description

Technical Field The technical field relates generally to implementing techniques to support public warning system (PWS) indication and acquisition in wireless networks. Background In recent years, there has been a rapid development in communications technologies that are compliant with third generation partnership project (3GPP™) standards. A 4th generation (4G) wireless communication standard (sometimes referred to as long term evolution (LTE™) was designed to support mobile internet and higher speeds for activities, such as video streaming and gaming. The 3GPP™ standards then developed a fifth generation (5G) of mobile wireless communications, which provides a step change in the delivery of better and faster communications, for example powering businesses, improving communications within homes and spearheading advances such as driverless cars. A sixth generation (6G) wireless communication standard is currently under development, as the planned successor to 5G and will likely be significantly faster. Like its predecessors, 6G networks will likely be broadband cellular networks, in which the service area is divided into small geographical areas called cells. 6G networks are expected to be even more diverse than their predecessors and are likely to support applications beyond current mobile use scenarios, such as virtual and augmented reality (VR / AR), ubiquitous instant communications, pervasive intelligence and the Internet of Things (loT). It is expected that mobile network operators will adopt flexible decentralized business models for 6G, with local spectrum licensing, spectrum sharing, infrastructure sharing and intelligent automated management underpinned by mobile edge computing, artificial intelligence (AI), short-packet communication and blockchain technologies. Non-Terrestrial Networks (NTNs) is an emerging area in 3GPP™ with Release 17 defining a solution to enable 5G New Radio (NR) and NG-RAN to support Non-Terrestrial Networks. It addressed solutions for Transparent payload for both Geostationary and non-Geostationary network scenarios, with the UE having GNSS capability and the satellite beams being both earth-fixed or earth-moving. The aim is to provide 5G cellular coverage using space borne and / or air borne platforms, where traditional ground-based networks have difficulty in providing coverage and / or capacity. loT NTN was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN loT devices (NB-IoT and LTE-M / eMTC) [RP-202689], And NR NTN was a work item in Rei-17 to specify adaptation to allow NR to function over NTN [RP-211557], Non-Terrestrial Network access may be through Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS). Following the Work items in Release 17 there were work items proposed to enhance NR NTN [RP-220953] and loT NTN [RP-223519] in Release 18. A work item description for loT NTN in Release 19 (Rei-19) is the following [RP-242145]: ‘Support of Store&Forward (S&F) satellite operation with full eNB as regenerative payload, therefore: Define the necessary enhancements into E-UTRAN (network &UE) to support S&F operation for delay-tolerant services [RAN3, RAN2]; At least specify necessary enhancements e.g. related to SI protocol, especially to address the feeder link switch over as needed [RAN3], Note: Strive to minimise UE impact. Note: Coordination with SA2 (Rel-19 SA2 led Sat-Arch ph3 SI) is needed on the detail requirements (e.g. traffic type, or QoS parameters for S&F), network architecture (e.g. whether consider (partial) core network on satellite) etc.; further coordination with CT1 might be required. Support of Capacity enhancements for uplink: Study then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the min of 4 and the maximum allowed by the existing UL and DL signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH [RANI, RAN2, RAN4]: Multi-tone support for 15 kHz SCS should also be considered; Specify necessary signalling, if needed; Update RF requirements accordingly, if needed. Note: Impact of impairment shall be taken into account Study and specify, if beneficial the following enhancements to reduce the necessary uplink and downlink signaling to complete an Early Data Transmission (EDT) transaction [RAN2]: Msg3 transmission without msgl / Random Access Response (RAR); Efficient delivery (reduced overhead) of msg4 / RRCEarlyDataComplete; Study and specify RRM requirement, if identified [RAN4], Support broadcast of PWS messages for NB-IoT re-using the LTE mechanisms [RAN2], Note: The solutions will be developed for NTN but can be applicable to TN (if possible). Specific NB-IoT TN optimizations will not be considered as part of this WI. Note: Support for indication of intended service area for ETWS will be considered based on NR NTN discussions / outcome.’ Narrowband Internet of Things (NB-IoT) is also a 3GPP-defined network based on 4G E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. The use case of NB-IoT is to serve massive loT application, where requirements for instance are to support enhanced coverage, power-efficient operation and a massive number of devices. Some of the features introduced are: (i) Support for enhanced coverage through low bandwidth and extreme amounts of repetitions; and (ii) Power efficient operation by allowing the UE to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell. 5G and 5G new radio (5G NR) includes three RRC states; RRC connected mode, RRC inactive mode and RRC idle mode, where RRC inactive is a newly introduced mode. RRC idle and RRC inactive operation are to a large part similar and a differentiation is to a large part in the procedures used to go to RRC connected mode. Referring to FIG. 1, a known simplified cellular architecture diagram 100 illustrates a first non terrestrial base station / satellite 102 supporting communications within a coverage area 104, including communication support for a wireless communication unit, sometimes referred to as a terminal device, such as a user equipment UE 106. In 4G as well as 5G, the UE 106 is able to support traditional Human Type Communications (HTC) and LTE-Machine (LTE-M) and enhanced Machine Type Communication (eMTC), which is a 3GPP™-defined network that is an extension of 4G E-UTRAN that supports low-complexity devices with more narrow bandwidths compared to normal LTE and further simplifications of procedures. Similarly to NB-IoT, the use case is to serve massive loT, but with more capabilities. Instead of being an entirely new type of device with major air interface changes as in NB-IoT, the LTE-M inherits most feature of a regular LTE device, but with some adaptations for low complexity considerations. The UE 106 is considered to be active when communicating and in the operational state technically known as radio resource control (RRC) connected. 4G or LTE™, which Internet of Things (loT) (NB-IoT and LTE-M) is based on, has two RRC states; RRC connected mode and RRC idle mode. The known simplified cellular architecture diagram 100 comprises a connection 120 that connects the first non-terrestrial base station / satellite 102 and a second terrestrial base station 108 via a gateway 114. For RRC- idle state UEs 106, a cell re-selection process may be warranted, if the signal strength from the current serving cell (e.g., non-terrestrial base station 102) deteriorates as the UE transitions from base station 102 to 108. Similarly, a cell re-selection process is performed for ‘RRC idle state UEs when the UE nears the cell edge of the current cell 104 that it is camped on and is able to receive a signal from the neighbour base station 108. For loT, this is a known 4G or E-UTRAN cell reselection process, which is also driven by signal strength measurements of the base stations carried out by the UE. Thus, the 3GPP™ LTE™ (and NR) cell reselection, e.g., the act of camping on another cell, is an autonomous decision based on radio signal measurements performed by UEs 106 based on signals received from serving base station 102 and one or more neighbour base station(s) 112, sometimes referred to as fifth generation Node Bs (gNB) or eNBs and configured thresholds related to such radio signal measurements. In RRC connected mode, a threshold A dB may be set to avoid ping-pong type handover near the cell border, as the instantaneous signal strengths can vary dynamically. The serving gNB 102 can instruct each individual UE 106 to provide these measurement reports and the measurement frequency can be adapted depending on whether a particular UE is nearing a cell edge, for example. Also, cell re-selection processes happen on an individual UE basis, based on the measurements of the current camped-on and neighbour base stations (gNBs). In RRC idle mode / state, thresholds are also used to govern the cell reselections, but they are not used by comparing one cell with the serving cell as is done in RRC connected mode. In cell reselection in idle mode, the cells will, for instance, compute a ranking based on parameters such as thresholds and the measured signal strength. In the ‘RRC- idle’ state, the current camped-on base station (gNB) 102 is able to instruct the UEs 106 on an individual basis in order to carry out these measurements and the UE 106 themselves will initiate and carry out the cell re-selection process. NB-IoT has the following physical channels: - NPDCCH (NB-IoT Physical Downlink Control Channel). This is used to signal control messages to the UE, containing Downlink Control Information (DCI). o DCI format NO is mostly used for uplink grants, i.e., scheduling of NPUSCH. o DCI format N1 is mostly used for PDSCH assignments, i.e., scheduling of NPDSCH. o DCI format N2 is mostly used for paging and Direct indication. - NPDSCH (NB-IoT Physical Downlink Shared Channel). This is used to signal user-plane and control-plane messages to a UE. - NPUSCH (NB-IoT Physical Uplink Shared Channel). This is used to transmit both data and control messages. This is different from normal LTE, where only data is transmitted on PUS CH and PUCCH is used to transmit uplink control information. The control messages sent on NPUSCH are HARQ ACK / NACK and Scheduling Requests. - NPRACH (NB-IoT Physical Random Access Channel). This is used to transmit Msgl in the random access procedure. - NPBCH (NB-IoT Physical Broadcast Channel). Used for broadcasting synchronization information as well as the Master information Block (MIB). NB-IoT supports multi-carrier operation by having the ability to operate on anchor and nonanchor carriers. Anchor carrier is originally where the UE accesses the cell, and after having accessed the cell, the UE may be moved to a non-anchor carrier to perform data transmissions. The UE may be configured, as an enhancement, to receive paging on a non-anchor carrier. The of Physical layer LTE-M has the same physical channels as normal LTE, except for the following: (i) MTC Physical Downlink Control Channel (MPDCCH), which is used to signal control messages to the UE; and (ii) PHICH is not supported for LTE-M as it does not support synchronous HARQ. LTE-M supports multi-carrier operation by having the ability to operate, e.g., receive and transmit data on different narrowband channels. Each narrowband is 6 PRBs, and the narrowband can be switched. System information blocks (SIBs) may be configured on different narrowband channels. System information is information that is broadcasted by a cell for a wide range of purposes. System information tells the UE how to operate in a cell, give the UE access information and also give the UE assistance information for emergency cases. The UE may also, as in NB-IoT, be configured to receive paging on different narrowband channels. Idle and inactive mode mobility is based on a UE autonomously performing measurements and deciding according to some rules whether a UE shall re-select to another cell or not to camp on. During cell selection, the UE identifies suitable cells, according to a cell’s suitability criteria based on signal strength and signal quality measurements. After identifying one or several suitable cells, the UE can choose any of them. For instance, the UE can select the cell with the strongest signal strength and signal quality within a PLMN. Cell selection can be performed following PLMN selection (which may be after a UE is turned on), after being released by a network, or during the RRC re-establishment procedure and a number of other cases. A cell may be classified into a number of different types of cells. A suitable cell is a cell that fulfills the cell selection criteria, the cell is not barred, etc. and is part of the tracking area of the UE - thus a normal type of cell. An acceptable cell is a cell on which the UE is only allowed to camp for specific reasons such as emergency cases, but the cell cannot be barred and the cell selection criteria need to be fulfilled. A UE only camps on such a cell if it cannot find a suitable cell. A reserved cell is a reserved if the system information indicates that it is reserved. When camped on a cell, the UE shall perform the cell reselection procedures which includes searching and detecting cells and camping on a better or more suitable cell. In the cell reselection procedure, the UE searches intra-frequency cells, inter-frequencies cells and inter-RAT cells following the signalling by the serving cell. Each frequency (inter-RAT or intra-RAT) may have a specific cell reselection priority. The cell reselection algorithm is designed to ensure that the UE chooses a cell with highest priority, given that it is not barred or not allowed to camp on. A UE shall always select an inter-frequency or inter-RAT cell with a higher priority over a lower priority cell. If frequencies of equal priority are detected, then the UE shall rank all of the cells, where the ranking metric is based on signal strength and signal quality measurements and then choose the best candidate. The UE then camps on the newly re-selected cell. There are also certain rules related to how long a new cell shall be deemed better than the serving cell, before camping on the new cell. This parameter is called Treselection and can be specific for a RAT or for other cases. There are also thresholds for the signal strength of signal quality that may need to be fulfilled before selecting a new cell to camp on, which may depend on whether the cell is lower or higher priority and depend on whether the cell is inter-frequency or inter-RAT. As part of the idle mode and inactive procedures, the UE also checks whether a cell is barred or not. If a cell is barred or not, the UE is not allowed to connect to the cell, not allowed to camp or consider the cell for cell reselection. In 4G, the barring bit is signalled in SIB1 while in 5G NR, the barring bit is signalled in MIB. Inter-RAT may be considered any other than the current RAT. As an example for 4G E-UTRA UE, the following may be considered inter-RAT: 2G, 3G, 4G NB-IoT, 5G NR or 6G. Within the 3 GPP™ standards, discussions have taken place related to a Public Warning System (PWS), which is the capability of a network to broadcast emergency messages to UEs. The PWS messages are broadcasted by eNBs and can be read by any UEs that are connected to, or camping on, the cell. In most mobile phones, these messages will alert the user of an emergency in the area. There are currently two types of PWS systems currently specified: Earthquake and Tsunami Warning System (ETWS) and Commercial Mobile Alert System (CMAS). ETWS is used for alerting users about emergency messages. The ETWS message in Uu consists of a primary and a secondary notification. The primary notification is transmitted in SIB 10 in LTE and SIB8 in 5G NR and the primary notification alerts users of an emergency and contains information on the message identifier, the serial number as well as the warning type. The secondary notification is transmitted in SIB11 in LTE and SIB9 in 5G NR and the secondary notification may be segmented into different SIB transmissions. To do this, the SIB11 includes a segmentation identifier. CMAS is also used to alert users about emergency messages. It is compatible with EU Alert system and Korean Public Alert System. The CMAS message in Uu is transmitted in SIB 12 in LTE and SIB 10 in 5GNR. The emergency alert system may also be segmented across different SIB transmissions. It similarly contains information on the segments transmitted in each individual SIB 12 / SIB10 transmission. If a SIB that signals PWS, i.e., SIB10-12 in LTE or SIB8-10 in 5GNR, is indicated to be broadcasted, the UE shall immediately attempt to acquire the respective system information. However, the UE needs to be informed that it is being broadcasted. For this purpose, paging is introduced, where the paging indicates that either CMAS or ETWS shall be acquired. Paging is normally done by the UE monitoring for PDCCH scrambled with P-RNTI, where the PDCCH points to a PDSCH containing the Paging RRC message. In LTE, either a CMAS-Indication or ETWS-Indication is sent in the Paging RRC message to indicate that PWS is being broadcasted. For eMTC and 5GNR, a Direct Indication message or Short Message, which is a field with a single-bit indication of length 8 bits that is included in a DCI in the PDCCH scrambled by P-RNTI that is sent in the Paging Occasions. The Direct Indication or Short Message can also be used to indicate system information change and some other indications. In eMTC, the UE in connected mode may be indicated with CMAS or ETWS via Direct Indication sent in MPDCCH via monitoring for SI-RNH. In order for an eNB to start broadcasting the PWS signalling, the eNB needs to be configured to start the broadcasting. For this, there is support for inter-node signalling over SI interface for an MME to indicate to the eNB to start broadcasting an emergency message and the content of the emergency broadcast. To start the emergency broadcasting, a ‘WRITE-REPLACE WARNING REQUEST’ and a ‘WRITE-REPLACE WARNING RESPONSE’ message are used. A ‘KILL REQUEST’ and a ‘KILL RESPONSE’ message is sent by an MME to an eNB to order the eNB to stop broadcasting the emergency broadcast message. In 4G loT, i.e., in eMTC and NB-IoT, the UE is limited on how it can acquire system information since it is considered a cheaper device. For instance, the 4GIoT UE is unable to acquire system information while in connected mode and may thus only be able to acquire system information when the UE is in idle mode. Since LTE-M introduces the concept of narrowband channels within the cells bandwidth, the network may configure certain system information blocks to be configured on a specific narrowband. This may for instance be done to ensure that system information does not take up too much of the resources of a specific narrowband. 4G loT also introduces repetitions of system information in order to improve the coverage. In light of the above state of the 3 GPP™ standards, the inventors have recognised and appreciated that NB-IoT does currently not support any type of PWS emergency broadcasting, as is supported by E-UTRAN and NR. Normally, this was not considered a priority as NB-IoT users are normally simple sensors or other machine-type communications, to whom emergency broadcasts would not be relevant. However, the inventors have recognised and appreciated that in NB-IoT NTN, the use cases may be different. This is because NB-IoT is the most likely Radio Access Technology to be adopted for loT satellite communication, owing to its superior coverage and ease of implementation. For example, due to this reason, it was recently agreed to address PWS broadcasting for NB-IoT re-using the LTE mechanisms [RAN2] (RP-242145). It is noted that the solutions will be developed for NTN, but can be applicable to TN (if possible). Specific NB-IoT TN optimizations will not be considered as part of this WI. Also, there is support for indication of intended service area for ETWS may be considered, based on NR NTN discussions / outcome. Thus, the inventors have recognised and appreciated that a need exists for improved devices, networks and methods to support PWS broadcast messages, since NB-IoT currently does not support PWS broadcasting, and since PWS broadcasting has been supported from the beginning for both 4G E-UTRAN and 5G NR. In particular, the inventors have recognised and appreciated that some issues need to be resolved, including: how a UE acquires the PWS broadcasting in connected and idle mode; and how to ensure that a UE camps on cells that are capable of indicating PWS broadcast to satisfy a use case. Summary Examples herein described propose devices, networks and methods for indicating to a UE that PWS is being broadcasted, and for a UE to acquire the PWS that is broadcast. It is noted that, whilst part of the examples described herein are described in terms of NB-IoT, it is envisaged that the examples are not to be limited only to NB-IoT, but may also apply to other loT technologies, such as LTE-M (also called eMTC, or bandwidth limited (BL) UEs or UEs in Coverage Extension (CE)) or 5G NR Redcap. Indeed, it is envisaged that the examples described herein may also apply for a UE operational in either a non-terrestrial network, or in a terrestrial network. In a first aspect, a wireless communication unit for communicating in a wireless communication system is described, wherein the wireless communication unit is an Internet of Things, loT, wireless communication unit or an enhanced Machine Type Communication, eMTC, wireless communication unit. The wireless communication unit comprises: a transceiver arranged to receive a message direct from a wireless serving communication unit; and a processor, operably coupled to the transceiver, arranged to process the message, wherein the message indicates a broadcast public warning system, PWS, message; wherein, in response to the processed message, the transceiver is arranged to receive the broadcast PWS message. In some examples, the wireless communication unit may be a narrowband loT, NB-IoT, wireless communication unit and the wireless communication system may be a non-terrestrial network, NTN. In some examples, the message received direct from the wireless serving communication unit is Downlink Control Information, DCI. In some examples, the DCI may be one of: scrambled with a Paging Radio Network Temporary Identifier, P-RNU; a DCI format N2; received in a Physical Downlink Control Channel, PDCCH; received in a NB-IoT Physical Downlink Control Channel, NPDCCH, using P-RNTI but without an associated Paging-NB message; received in a MTC Physical Downlink Control Channel, MPDCCH. In some examples, the message that provides a direct indication of the broadcast PWS message may be received when the wireless communication unit is in connected mode with the wireless serving communication unit. In some examples, when in connected mode with wireless serving communication unit, the transceiver and processor of the wireless communication unit may be arranged to receive and process system information blocks, SIBs, that contain the broadcast PWS message. In some examples, the transceiver and processor may be arranged to receive the broadcast PWS message using one of: an Earthquake and Tsunami Warning System, ETWS, via one of a system information block, SIB, SIB 10 message or SIB 11 message; a Commercial Mobile Alert System, CMAS, via a SIB 12 message. In some examples, the transceiver and processor of the wireless communication unit may be arranged to monitor a Radio Network Temporary Identifier, RNTI, for a Downlink Control Information, DCI that indicates a broadcast PWS message and in response thereto the transceiver is arranged to receive the broadcast PWS message. In some examples, the transceiver and processor may be arranged to transmit a capability message to the wireless serving communication unit in connected mode, wherein the capability message indicates that the wireless communication unit includes a capability to receive a broadcast PWS message when the wireless communication unit operates in a radio resource control, RRCIDLE state or an RRCINACTIVE state. In some examples, the transceiver and processor of the wireless communication unit may be arranged to receive and process a radio resource control, RRC, connection release message received direct from the wireless serving communication unit and in response thereto enter a RRC IDLE state or an RRC INACTIVE state and receive the broadcast PWS message. In some examples, the transceiver and processor may be arranged to receive and process a message that indicates a PWS broadcast capability of a first communication cell supported by a first wireless serving communication unit. In some examples, the transceiver and processor of the wireless communication unit may be arranged to receive and process a system information block, SIB that indicates the first communication cell includes the PWS broadcast capability of at least one of: an Earthquake and Tsunami Warning System, ETWS; a Commercial Mobile Alert System, CMAS. In some examples, in response to the processed message that indicates a capability PWS broadcast of the first communication cell supported by the first wireless serving communication unit, the transceiver and processor may be arranged to prioritize camping on the first communication cell over camping on a second communication cell supported by a second wireless serving communication unit that is not capable of transmitting a message that indicates a capability of PWS broadcast. In a second aspect, a method for a wireless communication unit for communicating in a wireless communication system is described, wherein the wireless communication unit is an Internet of Things, loT, wireless communication unit or an enhanced Machine Type Communication, eMTC, wireless communication unit. The method comprises, at the wireless communication unit: receiving a message direct from a wireless serving communication unit; processing the message, wherein the message indicates a broadcast public warning system, PWS, message in the wireless communication system; and receiving, in response to the processed message, the broadcast PWS message. In a third aspect, a wireless serving communication unit arranged to support communications for a plurality of wireless communication units in a communication system, is described, wherein the plurality of wireless communication units comprise Internet of Things, loT, wireless communication units or enhanced Machine Type Communication, eMTC, wireless communication units. The wireless serving communication unit comprises: a transceiver; and a processor, operably coupled to the transceiver, arranged to: identify a broadcast of a public warning system, PWS, message in the communication system; and transmit a message direct to at least one wireless communication unit of the plurality of wireless communication units wherein the message provides an indication of the broadcast PWS message. In some examples, the message transmit direct at least one wireless communication unit provides a direct indication of the broadcast PWS message in Downlink Control Information, DCI. In some examples, the transceiver and processor may be arranged to transmit a capability message that indicates to the plurality of wireless communication units that the wireless serving communication unit is able to perform at least one of: transmit the message that provides an indication of the broadcast PWS message, broadcast the PWS message. In some examples, the message that provides an indication of the broadcast PWS message may be transmit to the plurality of wireless communication units in a system information block, SIB, SIB1 message. In some examples, the wireless serving communication unit may be a narrowband Internet of Things Non-Terrestrial Network, NB-IoT NTN, wireless serving communication unit. In some examples, the transceiver and processor may be arranged to: receive a PWS capability message from the wireless communication unit in connected mode, wherein the PWS capability message indicates that the wireless communication unit includes a capability to receive a broadcast PWS message when the wireless communication unit operates in a radio resource control, RRC IDLE state or an RRCINACUVE state; and transmit, in response thereto, a radio resource control, RRC, connection release message direct to the wireless communication unit that enables the wireless communication unit to enter a RRCIDLE state or an RRCINACTIVE state and receive the broadcast PWS message. In a fourth aspect, a method for a wireless serving communication unit is described. The method comprises, at the serving communication unit: supporting communications for a plurality of wireless communication units in a communication system, wherein the plurality of wireless communication units comprise Internet of Things, loT, wireless communication units or enhanced Machine Type Communication, eMTC, wireless communication units; identifying a broadcast of a public warning system, PWS, message in the communication system; and transmitting a message direct to at least one wireless communication unit of the plurality of wireless communication units, wherein the message provides an indication of the broadcast PWS message. Brief Description of the Drawings Further details, aspects and embodiments will be described, by way of example only, with reference to the drawings. In the drawings, similar reference numbers are used to identify like or functionally similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. FIG. 1 illustrates a known simplified non-terrestrial cellular architecture with a known NR NTN and loT NTN operation. FIG. 2 illustrates a simplified example of a message sequence chart of a procedure that indicates to a UE that PWS is being broadcasted, and for a UE to acquire the PWS broadcast, adapted in accordance with some example embodiments. FIG. 3 illustrates a block diagram of a base station (in a form of an eNB) communicating with a UE, adapted in accordance with some example embodiments. FIG. 4 illustrates one example of a message sequence chart whereby an NB-IoT UE in connected mode monitors P-RNTI for DCI format N2, which indicates the Direct Indication that contains an indication of PWS broadcasting, in accordance with some example embodiments. FIG. 5 illustrates a simplified message sequence chart of a procedure following an RRC Connection Release message and a UE having moved to RRC IDLE, whereby the UE will acquire the PWS broadcast, in accordance with some example embodiments. FIG. 6 illustrates a simplified message sequence chart whereby the network indicates emergency indication through system information updates that may configure the UE to first always assume that any type of system information update is an emergency signalling, so the UE will first always check for emergency broadcast system information, and the UE performs the system information update procedure as normal if this is not detected, in accordance with some example embodiments. FIG. 7 illustrates a simplified message sequence chart whereby the indication may indicate that the PWS broadcast shall be performed in the associated NB-IoT cells in addition to cells in other RATs, or may be indicated that it shall only be performed in the associated NB-IoT cells, in accordance with some example embodiments. Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and / or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various example embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments. It will be further appreciated that certain actions and / or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein. Detailed Description The inventors have recognised and appreciated that a method is needed for indicating to a UE that a PWS is to be, and is being broadcast, and for a UE to acquire the PWS broadcast. Whilst part of the concepts are described in terms of a NB-IoT, it is envisaged that the concepts should not be considered as being limited only to NB-IoT, but may also apply to other loT technologies, such as LTE-M (also termed eMTC, or bandwidth limited (BL) UEs or UEs in Coverage Extension (CE)) or 5G NR Redcap Referring now to FIG. 2, a simplified example of a message sequence chart 200 of a procedure that indicates to a UE 210 that PWS is being broadcasted, and for the UE to acquire the PWS broadcast by the network, e.g., an eNB 220, is illustrated, in accordance with some example embodiments. Here, the PWS broadcast is triggered at 230, an indication of a PWS being broadcast is broadcast from the eNB 220 at 240 and the UE 210 acquires the broadcasted PWS message at 250. Whilst some examples are described with reference to a UE 210 acquiring Public Warning system information, it is envisaged that the UE 210 may also be configured to acquire other related disaster information, such as disaster roaming information via SIB30 in LTE™. It is also envisaged that the examples described herein may also be applied for system information updates, which may lead to the broadcasted PWS messages being acquired by UEs 210. It is also envisaged that the broadcasted PWS message approaches described below apply equally to eNBs, gNBs, NG-RAN or NG-eNB. Hence, it is envisaged that the terms are to be considered interchangeably. For instance, in some cases the below description may be for an eNB, but it may also apply for NG-eNB (eNB is connected to EPC, while NG-eNB is connected to 5GC). In some cases as identified below, it is envisaged that there may also be methods that are explicitly configured for an NG-eNB, en-gNB, gNB, or NG-RAN. It is also envisaged that the broadcasted PWS message are not limited to being broadcast by an NTN cell, e.g., a cell that operates over a NTN, as it is also envisaged that the broadcasted PWS message may be broadcast in a terrestrial network. In some examples, an NTN may also be defined to be a cell that indicates it is a cellBarred-NTN. This can be a 4G loT NTN, 5G NR or 6GNTN cell. This category may also encompass Store and Forward cells. It should be noted that examples herein described are not limited to loT NTN E-UTRAN as it is envisaged that “ordinary” non-IoT LTE NTN are also supported. Thus, examples are described with reference to ‘radio access networks’, which term encompasses and is considered to be equivalent to and interchangeable with communication cells, namely the facilitation of communications within a cell that may access other parts of the communication system as a whole. Referring now to FIG. 3, a high-level block diagram of an eNB (or gNB TN or NTN wireless base station (equivalent in functionality details to eNB or gNB TN or NTN base station) 220 and a wireless communication unit (such as a user equipment (UE) 210) are illustrated, where the respective communications units have been adapted in accordance with some example embodiments. The eNB (wireless base station) 220 contains an antenna 302, for receiving transmissions, coupled to an antenna switch or duplexer 304 that provides isolation between receive and transmit chains within the eNB 220. One or more receiver chains, as known in the art, include receiver front-end circuitry 306 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 306 is coupled to a signal processor 308 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent. The controller 314 maintains overall operational control of the eNB 220. The controller 314 is also coupled to the receiver front-end circuitry 306 and the signal processor 308. In some examples, the controller 314 is also coupled to a frequency generation circuit 317 and a memory device 316 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 318 is operably coupled to the controller 314 to control the timing of operations (e.g., transmission or reception of timedependent signals) within the eNB 220. As regards the transmit chain, this essentially includes an input interface 320, coupled in series through transmitter / modulation circuitry 322 and a power amplifier 324 to the antenna 302, antenna array, or plurality of antennas. The transmitter / modulation circuitry 322 and the power amplifier 324 are operationally responsive to the controller 314. The signal processor 308 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 3. Clearly, the various components within the eNB 220 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. In accordance with examples described herein, the processor 308 and transceiver (e.g., transmitter / modulation circuitry 322 and receiver front-end circuitry 306) of the eNB 220 are configured to trigger a PWS broadcast message and broadcast the PWS (in some examples with one or more PWS indication(s)) to a plurality of served wireless communication units, such as UE 210, according to at least one of the operations in accordance with the approach described in at least one of: FIG. 2 or FIG. 4 or FIG. 5 or FIG. 6 or FIG. 7 or described hereafter. In some examples, the PWS broadcast message may be sent on a P-RNTI or within a RRCConnectionRelease message. FIG. 3 also shows a high-level block diagram of the wireless communication unit (e.g., a user equipment (UE) 210 in 3 GPP parlance) contains an antenna 352, for receiving transmissions, coupled to an antenna switch or duplexer 354 that provides isolation between receive and transmit chains within the UE 210. One or more receiver chains, as known in the art, include receiver front-end circuitry 356 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 356 is coupled to a signal processor 358 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent. The controller 364 maintains overall operational control of the UE 210. The controller 364 is also coupled to the receiver front-end circuitry 356 and the signal processor 358. In some examples, the controller 364 is also coupled to a frequency generation circuit 367 and a memory device 366 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 368 is operably coupled to the controller 364 to control the timing of operations (e.g., transmission or reception of timedependent signals) within the UE 210. As regards the transmit chain, this essentially includes an input interface 370, coupled in series through transmitter / modulation circuitry 372 and a power amplifier 374 to the antenna 352, antenna array, or plurality of antennas. The transmitter / modulation circuitry 372 and the power amplifier 374 are operationally responsive to the controller 364. The signal processor 358 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 3. Clearly, the various components within the UE 210 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. In accordance with examples described herein, the processor 358 and transceiver (e.g., transmitter / modulation circuitry 372 and receiver front-end circuitry 356) of the UE 210 are configured to receive a PWS broadcast message, according to at least one of the operations in accordance with the approach described in at least one of: FIG. 2 or FIG. 4 or FIG. 5 or FIG. 6 or FIG. 7 or described hereafter. In some examples, the PWS broadcast message may be received in a P-RNTI or within a RRCConnectionRelease message. As clarified previously, currently within NB-IoT it is not possible to signal and indicate that the network is broadcasting Public Warning System information. The inventors have recognized and appreciated that if a PWS message is introduced via system information, there may be some instances where an NB-IoT UE cannot be assumed to be able to acquire the broadcasted PWS information in connected mode. This is because the NB-IoT UE may not be assumed to acquire any system information in connected mode. Furthermore, for the indication to the UE that the PWS is being broadcasted, the inventors have recognized and appreciated that there is also no ability of a NB-IoT UE to be indicated of the broadcast PWS message, not least as the NB-IoT UE does not monitor for paging nor system information changes in connected mode. Thus, in some examples, it is envisaged that the UE 210 is arranged to monitor for paging or system information change, e.g., RNTI (P-RNTI or SI-RNTI) in connected mode in order to receive a direct indication that the network is broadcasting PWS information, as illustrated in FIG. 5. In this example, it is envisaged that the UE 210 may monitor a new RNTI for PWS signalling in connected mode, in order to receive an indication that the network is broadcasting PWS information, which may be termed a ‘PWS-RNTI’. In another example, it is envisaged that the UE 210 may monitor a RNTI used for data transmissions for PWS signalling in connected mode, in order to receive an indication that the network is broadcasting PWS information. This can, for instance, be the C-RNTI. It is envisaged that the monitoring of a specific RNTI may be performed in the User-specific Search Space (USS) or in the Common Search Space (CSS). In some examples, it is envisaged that the indication that PWS message may be transmitted in a Direct Indication message (rather than broadcast). In this example, it is envisaged that this may be enclosed in a DCI in a PDCCH, NPDCCH or MPDCCH message, for which the UE 210 monitors using the RNTI, as above. In this example, it is envisaged that this format may, for instance, be the Format NO, Nl, N2. In this example, it is envisaged that there may also be a new format used specifically for this case, which can, for instance, be Format N3. If it is enclosed in a DCI in NPDCCH in Direct Indication, an example may be seen below in Specification Example #1. An example of how the above may be combined is described below. An NB-IoT UE in connected mode monitors P-RNTI for DCI format N2 which indicates the Direct Indication, which contains an indication of PWS broadcasting, as illustrated in FIG. 4. Referring now to FIG. 4, one example of a message sequence chart 400, whereby at 430 an NB-IoT UE 210 in connected mode monitors P-RNTI for DCI format N2 sent by eNB 220, which provides a message that indicates PWS broadcasting, is illustrated in accordance with some example embodiments. At 440, a PWS broadcast is triggered and at 450 an indication of the PWS being broadcast is sent on a P-RNTI. At 460, the UE 210 acquires the broadcasted PWS message. Alternatively, it is envisaged that the NB-IoT UE in connected mode may be arranged to monitor one or more of the following that provides a message that indicates PWS broadcasting SI-RNU for DCI format N2, PWS-RNTI for DCI format N2, P-RNTI for DCI format Nl, SI-RNTI for DCI format Nl, C-RNTI for DCI format N2. In some examples, if an existing format, such as a NO, Nl, and N2, is used, then the DCI may be extended to provide a PWS broadcast indication, or reserved fields may be used. This example is illustrated in Specification Example #2 below. In some alternative examples, if an existing format such a NO, Nl, and N2 is used, then the UE 210 may be configured to reuse certain fields to indicate PWS information. In this manner, a condition may thus be set that the UE 210 is configured to be provided with a PWS indication, and certain fields may be reused. In one example, from Format NO, it is envisaged that one or more of the following fields in the DCI may be re-purposed: (i) Number of scheduled TB for Unicast (ii) Resource reservation In one example, from Format Nl, it is envisaged that one or more of the following fields in the DCI may be re-purposed: (i) Number of scheduled TB for SC-MTCH (ii) Number of scheduled TB for Unicast; (iii) Resource reservation. In some examples, it is envisaged that the UE 210 may be arranged to monitor an RNTI (C-RNTI, P-RNTI, SI-RNTI, PWS-RNTI or other RNTI) for (N)PDCCH, which indicates that a PWS message is being broadcasted on a different carrier from the one that the UE 210 operates on. For instance, the UE 210 may operate on a non-anchor carrier, in other words the UE 210 is configured to monitor and transmit data on the non-anchor carrier, while the UE 210 also monitors an RNTI for (N)PDCCH that indicates PWS message being broadcasted on another carrier, for instance the anchor carrier. In another example, the UE 210 may be configured to operate on the anchor carrier, but may be configured to monitor for indications of PWS being broadcasted on another carrier, for instance a non-anchor carrier. In some examples, the carrier to monitor for PWS broadcast indication may be determined based on network indication, in other words the network (e.g., eNB 220) may indicate to the UE 210 which specific carrier to monitor for PWS broadcast indication, or the UE 210 may be configured to monitor according to other configurations, such as the paging narrowband channels. In some examples, it is envisaged that the monitoring may be performed on multiple carriers (anchor and non-anchor), which may be such that the UE 210 is capable of monitoring on both carrier-types simultaneously. Alternatively, it is envisaged that the monitoring may be that UE 210 may switch carrier just to monitor for PWS indication on the anchor carrier. For instance, it is envisaged that the monitoring of the different carriers may be time-multiplexed, such that the UE 210 does not need to concurrently monitor and perform another action on another carrier. In some examples, it is envisaged that the capability to monitor multiple carriers may be a capability that is signalled to the network, e.g., eNB 220. This capability may mean that the UE 210 is capable of monitoring on another carrier for PWS indications, which may also mean that the UE 210 is capable of monitoring for an RNTI (C-RNU, P-RNU, SI-RNTI, PWS-RNTI or other RNTI) for (N)PDCCH on another carrier. This capability may also mean that the UE 210 is capable of monitoring for an RNTI for (N)PDCCH that indicates PWS is being broadcasted on a non-anchor carrier, for instance while the UE 210 is operating on a non-anchor carrier. In some examples, it is envisaged that the UE 210 may also be configured to only monitor an RNTI (C-RNU, P-RNTI, SI-RNTI, PWS-RNTI or other RNTI) for (N)PDCCH which indicates that PWS message is being broadcasted on the anchor carrier. In some examples, it is envisaged that this may override any other type of paging configurations, such as configuration of paging on non-anchor carrier (for instance via SIB22-NB). In some examples, it is envisaged that the indication may indicate CMAS, ETWS or either of CMAS and ETWS, or any other PWS message type. In some examples, it is envisaged that if both are indicated, this may be a 1 -bit indicator, which may be configured to indicate that either of CMAS and ETWS. This example is shown in Specification Example #2. In some examples, it is envisaged that the indication that the network is broadcasting PWS information may be sent in a MAC CE. This MAC CE may be known as a PWS Indication MAC CE. In some examples, it is envisaged that this may a ‘O’-bit indication that indicates that either ETWS or CMAS is being broadcasted. Alternatively, In some examples, it is envisaged that this may be a ‘ 1 ’-bit indication field that indicates that ETWS and a 1 -bit indication field that indicates that CMAS is being broadcasted, which means that the MAC CE would have two 1 -bit fields. Furthermore, an example of the MAC CE is illustrated in Specification Example #3. In some examples, it is envisaged that upon receiving the indication, the UE 210 shall acquire the associated PWS information. The MAC entity may indicate to RRC that RRC shall acquire the PWS information. In some examples, it is envisaged that the PWS indication may be sent over RRC. In this example, it is envisaged that this can, for instance, be sent over any RRC messages, for example any downlink RRC message, such as an RRCSetup, RRCResume, or RRCEarlyDataComplete message. In some examples, it is envisaged that the expression “Terrestrial network”, when used herein, is intended to not only relate to a land mobile network (e.g., IMT), but may also encompass other terrestrial telecommunication services. This, for instance, may include Air-To-Ground networks or High Altitude Platform Systems (HAPS). On the other hand, in some examples, it is envisaged that the expression may also be applied to such Air-To-Ground networks or High Altitude Platforms. Also, when examples mention NTN and / or satellites, it is intended to additionally encompass such other platforms / payloads above the earth surface. In some examples, it is envisaged that the wording “RRC connected”, “connected mode” or “RRCCONNECTED” herein described are intended to be used interchangeably. Similarly, “idle mode”, “RRC idle” or ’’RRCIDLE” herein described are intended to be used interchangeably. Sometimes, when methods related to “idle mode” are mentioned, it is also envisaged that this may also encompass “inactive mode”, “RRC inactive” or “RRC INACHVE” herein described as the actions performed in those two states in general are the same. In some examples herein described, it is envisaged that terms of 5G NR, all proposals, embodiments, and examples may also apply for eNBs, NG-eNBs (eNBs connected via 5GC) or 6G NBs. Furthermore, in some examples herein described, it is envisaged that all related, newly defined and / or existing: RRC signaling and / or messages, X2, Xn, SI, NG, and / or Fl signaling and messages, and / or related network entities (e.g., MME, AMF, other). In some examples, it is envisaged that concepts herein described related to 4G and 5G, and potential equivalents in a 6G system, may apply equally and include: (i) 4G and 5G RRC connected state: UE 210 having established a connection with a RAN, e.g., a cell, gNB or similar identity. (ii) Cell: This may also be a different concept in a 6G system. For instance, in a cell-less case a UE may attach, connect and be associated with a beam or other similar identity. (iii) RRC idle: UE 210 not in a RRC connected state, e.g., not having established a connection. RRC idle also means that UE 210 will be camping on a cell or similar identity and then performing measurements and evaluating to find a better cell or similar identity. (iv) 5G RRC inactive: UE 210 in a state similar to RRC idle where the UE 210 stores the RRC configuration and resumes the RRC connection using the configuration. The network also stores the UE context and uses it to restore the UE connection. (v) 5G RRC procedures (RRC Setup, RRC Resume, RRC Re-establishment, RRC Reconfiguration): Any procedures that aim to establish a connection with a cell, a gNB or similar identity. For instance, a procedure that aims to establish a 5G-6GDual Connectivity setting with a 5G and 6G cell. (vi) Random access: The process of synchronizing the MAC layer via sending a preamble and receiving a message that synchronizes the uplink, as well as following messages to resolve any contention. (vii) Radio Link Failure: Failure of the radio link, which may be a failure based on measured radio signals, or based on operation in the cell, such as a number of retransmissions, random access failures, the radio beams failing etc. After the radio link failure, the UE 210 may try to reselect to another cell and re-establish the RRC connection. (viii) Handover: Performing active mobility to another cell, gNB or similar identity. May also be termed a ‘reconfiguration with synch’. (ix) Releasing RRC connection: The UE 210 is released via messages, such as RRC Release that releases the RRC connection the UE 210 has to one or more cells. This may also include the UE 210. In some examples, it is envisaged that the notion of ‘out-of-date’, ‘outdated’, ‘invalid’ or ‘not valid’ may be used. Similarly, the notion of ‘valid’ may also be used. This can be defined, for instance, based on how old the specific information or data value is, or how long ago that the information was acquired. A timer may be associated with this specific information or data value, which governs whether it is out-of-date, outdated or invalid (or conversely whether it is valid). The length of this timer or duration may be configured by the UE 210, the network (e.g., eNB 220), or it may be determined for instance based on the scenario. A network may for instance allow or configure certain UEs, for instance stationary UEs serving a Fixed Wireless Access scenario, to always have its UE position be valid. A network may also change the method for determining whether the information or data value is valid or not. This could for instance mean that if UE 210 is allowed or configured to determine whether the information or data value is out-of-date, outdated or invalid, then if the network detects issues, then the network may reconfigure the UE 210 to only use a timing-related invalidity determination. The notion of data being valid or invalid may also be based on the accuracy of said data. For instance, if there is an accuracy value along with the estimation of for instance the UE 210 or the network position, then this can be used to determine whether the UE 210 or network position is valid or not. The validity or invalidity may also be determined by the UE 210 based on any type of sensors or information, for instance using inertial navigation methods. Any other determination of the data being valid or invalid may potentially be used. In some examples, it is envisaged that the UE 210 may be indicated of a presence of PWS messages being broadcasted via an RRCConnectionRelease message. This RRC release message may indicate that the UE 210 shall go to RRC IDLE or RRCIN ACTIVE in order to acquire the PWS message that is being indicated to be broadcasted. In some examples, it is envisaged that it may also indicate that the UE 210 shall suspend its RRC connection in order to acquire the PWS message that is being broadcasted. Once the RRC Connection Release message is applied and UE 210 has moved to RRC IDLE, the UE 210 will acquire the PWS broadcast, which may be ETWS via SIB 10 and SIB11 and CMAS via SIB 12. This is illustrated in FIG. 5. Referring now to FIG. 5, a simplified message sequence chart 500 illustrates a procedure following an RRC Connection Release message and a UE having moved to RRC IDLE, whereby the UE will acquire the PWS broadcast, in accordance with some example embodiments. At 540, at an eNB 220, a PWS broadcast is triggered. At 550, an RRCConnectionRelease (containing a PWS indication) is sent from eNB 220 to a UE 210. At 560, the UE 210 enters an RRC IDLE mode and at 570 the UE 210 acquires the broadcasted PWS message. In some examples, it is envisaged that any other type of broadcasted emergency information may also be acquired using the concepts herein described, such as disaster roaming in SIB30. In some examples, it is envisaged that the UE 210 shall immediately acquire the PWS and not start entering DRX after having entered RRC IDLE. The network, e.g., eNB 220 may thus indicate specific system information blocks that shall be acquired. The network, e.g., eNB 220, may indicate that one of SIB10, SIB11, SIB12 or SIB30 shall be acquired and the network may also include the system information scheduling, such as SIB1 scheduling info (schedulinglnfoSIB 1) or scheduling info for all SIB (schedulinglnfoList) in the RRC Connection Release message. This may give the UE information on the system information scheduling and may allow a UE to not be required to acquire SIB1 after having entered RRC IDLE. In some examples, it is envisaged that, after having received the RRCConnectionRelease message, the UE 210 first acquires the broadcasted emergency information, and then moves to RRCIDLE mode. This may potentially allow the UE 210 to remain in RRCCONNECTED mode whilst the emergency information is being broadcasted. In some examples, it is envisaged that the UE 210 may also be configured to re-connect to the cell (for example eNB 220) after the PWS broadcast message has been received. In some examples, it is envisaged that the reconnecting to the cell may be automatic, or it may be configured in the RRC Connection Release message. In some examples, it is envisaged that the network (for example eNB 220) transmits dedicated PWS information to the UEs that are in connected mode if the PWS broadcast is triggered. It is envisaged that this can be a specific RRC message, or the message may be sent in a dedicated system information block. In some examples, it is envisaged that from the time when the UE 210 receives a notification that it shall acquire a PWS broadcasting message, in other words receiving an indication that PWS is being broadcasted, the UE 210 may stop all other actions in order to acquire the PWS broadcast immediately. This may, for instance, encompass switching its current carrier to another carrier in order to acquire the related system information (SIB1, SIB10-12, SIB30). This may, for instance, be a switch from a non-anchor carrier to an anchor carrier, or it may be a switch from one narrowband channel to another narrowband channel. Such a switch may mean that the UE 210 is unable to perform the actions on the other carrier whilst the related system information is being acquired. The UE 210 may be configured to return to the original carrier after having acquired the system information, or the UE 210 may be configured to stay on the carrier that it was switched to. In some examples, it is envisaged that acquiring a PWS broadcasting message may also encompass not monitoring the downlink for PDCCH, NPDCCH, PDSCH or NPDSCH, and not transmitting any PUSCH, NPUSCH in the uplink, etc. This may be required in order for the UE to quickly acquire system information. It may also be required if, for instance, the UE is required to switch its carrier to acquire the system information. As an example, if the UE is scheduled via PDCCH to transmit in the uplink via PUSCH, then the UE may avoid transmitting PUSCH messages to acquire the PWS broadcasting message. This may for instance be very important if a lot of repetitions are applied, whereby a single transmission may take several seconds. In some examples, it is envisaged that if the UE 210 is performing transmissions, such as downlink or uplink transmissions, the UE 210 may be configured to stop these transmissions in order to acquire the related system information. It is envisaged that this may be particular important if the UE 210 is performing lengthy transmissions, for example due to transmission repetitions as well as small subcarrier spacing. In a worst-case scenario, the longest single transmission may take more than 40 seconds; therefore it would be important to interrupt this (if not crucial) in case of an emergency. In some examples, it is envisaged that the time to acquire PWS broadcasting messages may be handled using one or more timer(s). In some examples, upon such a timer expiry, the UE 210 may be configured to leave RRC connected and continue to attempt to acquire the PWS broadcasting message in RRC idle. In this example, a timer can be started upon receiving the notification that the UE 210 shall acquire the PWS broadcasting message. Similarly, a timer may be stopped upon successfully acquiring the PWB broadcasting message, or if the PWS broadcasting message has stopped, or timers may continue to run and if expired the actions may be performed after the PWS broadcast has been acquired. In some examples, it is envisaged that if the NB-IoT cell is operating ‘in-band’ and is capable of operating in another RAT, the UE 210 may be configured to acquire the PWS broadcasting in the other RAT in which the PWS is being broadcasted. For instance, if the NB-IoT UE 210 is connected to (or potentially camping in RRC idle on) an NB-IoT cell in-band of an E-UTRAN cell, but the NB-IoT UE 210 receives an indication of PWS being broadcasted, the UE 210 may tune in to the E-UTRAN cell to acquire the PWS broadcasting. For example, in some envisaged cases, the RAT itself may not have implemented PWS broadcasting, so instead the PWS is only broadcast in the other RAT. For example, potentially, the NB-IoT RAT is used for UE power saving purposes due to the efficient waveforms etc., but the other RAT may for instance be more power consuming, but able to handle a lot more signalling. In another example if the NB-IoT UE 210 is connected to (or potentially camping in RRC idle) an NB-IoT cell in-band of an 5GNR cell, may receive an indication of PWS being broadcasted, the UE 210 may then re-tune to the 5G NR cell in order to acquire the PWS broadcasting. In some examples, it is envisaged that this operation may be configurable by the network, e.g., eNB 220, and it may be configurable along with the option of acquiring the PWS broadcasting in the NB-IoT cell. The difference between these options may be that it could be faster to acquire the PWS broadcasting in the E-UTRA or NR cell, since these are wideband cells, noting that acquiring the PWS broadcasting may take a long time due to slow acquisition procedures that may be configured for UEs in extended coverage. Extended coverage may for instance be when the UE has a very large pathloss to another UE, which normally requires a large number of message repetitions. In some examples, it is envisaged that a system information update may be used in order to indicate that the network is broadcasting emergency updates. In this example, it is envisaged that the SIB1 may be used to indicate that the network is broadcasting emergency updates. This can be performed by either signalling that specific SIBs are being broadcasted, or there may be a specific indication in SIB1 that the network is broadcasting emergency information. If the UE 210 for instance determines that the SIBs transmitting one of the emergency broadcasts, then the UE 210 will immediately attempt to acquire the related system information. This procedure may also be used in RRCCONNECTED, i.e., an NB-IoT UE 210 in RRCCONNECTED monitors for indications of system information update and then re-acquires system information, but may prioritize the emergency broadcasting. If the network provides an emergency indication through a system information update, this may be used to (re-)configure the UE 210 to first always assume that any type of system information update is an emergency signalling. Hence, the UE 210 will first always check for emergency broadcast system information. If this is not detected, then the UE 210 may perform the system information update procedure as normal. This example is illustrated in Specification Example #E and FIG. 6. Referring now to FIG. 6, one example of a message sequence chart 600, whereby at 640 a PWS broadcast is triggered at an eNB 220. At 650, the eNB 220 broadcasts a PWS message. At 660, the eNB 220 sends a message to the UE 210 to indicate that there is a system information update and the UE detects at 670 from the SIB1 that the PWS message is being transmitted. Following which, at 680, the UE 210 is able to acquire the PWS message. In some examples, it is envisaged that the network (e.g., eNB 220) indicates to the UE 210 that it is capable of broadcasting PWS messages. In some examples, it is envisaged that this indication may be used by a UE 210 in multiple ways. For example, this indication may indicate that the UE 210 supports ETWS, CMAS, both ETWS and CMAS, or any other emergency message. In some examples, it is envisaged that this may be indicated in a SIB1 message, as illustrated below in Specification Example #F. In some examples, it is envisaged that the UE 210 may prioritize a cell that is capable of broadcasting PWS messages over other cells that are incapable of broadcasting PWS messages, when performing cell (re-)selection. For example, if there are certain cells or networks that are capable of PWS broadcasting, and certain cells or networks that are incapable of PWS broadcasting, then a UE 210 may allocate a higher priority to the cells that are capable of PWS broadcast. For a UE 210 that is used for, or has a primary use for, safety purposes, this can be very valuable to ensure safety. In some examples, it is envisaged that this can be performed in the cell selection and cell reselection procedures. For instance, the UE 210 may prioritize a cell or a frequency with cells that indicate that they support PWS signalling. Similarly, the UE 210 may de-prioritize a cell or a frequency that indicate they do not support PWS signalling. In this scenario, it is envisaged that a UE 210 capable of PWS signalling, and perhaps requiring the PWS signalling support for its use case, the NB-IoT UE 210 may be configured to consider cells that do not support PWS broadcasting to be barred. In some examples, it is envisaged in another example that if the UE 210 is unable to detect any suitable cells where it can be provided with services, it may still camp on an acceptable or reserved cell in order to receive PWS indications, if any. In this case, the UE 210 may prioritize an acceptable or reserved cell that is capable of broadcasting PWS messages over other acceptable or reserved cells that are not capable of broadcasting PWS messages. Without this, if the UE 210 wants to receive PWS broadcasts for its use case, then there would be no way of ensuring that the UE 210 can have its use case satisfied. An NB-IoT UE 210 may be deployed specifically for the purpose of receiving PWS broadcasts, but the UE 210 may thus not be aware of whether the cell supports it. Hence, it would be beneficial for the UE 210 to be aware of this and that the UE 210 may select cells accordingly. In some examples, it is envisaged that an NB-IoT cell may be considered suitable if it supports PWS broadcasting. In other words, if one or two conditions are not fulfilled, the NB-IoT cell supporting PWS broadcasting may still be considered suitable. For instance, in some examples, it is envisaged that the NB-IoT cell suitability criteria may currently consist of a number of conditions, and if one or more of these conditions are not fulfilled, then the NB-IoT cell may still be considered suitable if it supports PWS broadcasting. It is envisaged that this approach may be useful as it avoids having to introduce the acceptable cell concept for NB-IoT, thereby reducing implementation-burden. For instance, even though the NB-IoT cell is not part of one or more of selected PLMN, registered PLMN or PLMN or equivalent PLMN list, if the NB-IoT cell supports PWS broadcasting, the condition may still be considered fulfilled and the UE 210 may still consider the NB-IoT cell to be a suitable cell, which may depend on other conditions. Furthermore, for instance, despite the cell perhaps being a part of a list of forbidden tracking areas (TAs) for roaming, meaning that the cell is part of a tracking area for which the UE is forbidden to roam on, it is noted that if the NB-IoT cell is capable of PWS broadcasting, the condition may still be considered to be fulfilled. In some examples, it is envisaged that the concept of Acceptable cells may be introduced for NB-IoT. In NB-IoT, an acceptable cell may be defined to be a cell that supports PWS signalling, e.g., the acceptable cell either supports ETWS, CMAS or any other emergency signalling. In other words, it is envisaged that a condition for fulfilling the acceptable cell criteria in NB-IoT may be that the network supports PWS signalling. It is also envisaged that a condition for fulfilling the acceptable cell criteria may be that the UE 210 supports receiving PWS signalling. In some examples, it is envisaged that this may also encompass a scenario where a NB-IoT in an ‘Any Cell Selection’ state may search for acceptable cells. Notably, this is different to known current behaviour where the NB-IoT UE 210 only searches for suitable cells, because there are no acceptable cells in NB-IoT. Thus, a UE 210 normally enters the ‘Any Cell Selection’ state when there are no suitable cells available. This may include a complete scan of all RATs and / or frequency bands in order to find an acceptable cell. For instance, for the UE 210 that only supports NB-IoT, the UE may be configured to only include a search of all frequency bands. It is envisaged that this may be applicable if the UE 210 supports receiving PWS broadcasts. In some examples, it is envisaged that the introduction of a NB-IoT acceptable cell may also mean that UEs camping on a cell, or being in any cell selection of another RAT, may select an NB-IoT acceptable cell. It is envisaged that this may, for instance, be useful for selecting an NB-loT cell from another RAT. For instance, a UE 210 on another terrestrial RAT may select an NB-IoT NTN cell to camp on, for emergency signalling or PWS broadcasting. In this case, the above part, relating to searching for other RATs when in an ‘Any Cell Selection’ state, would be important, not least as a multi-RAT UE may camp on a NB-IoT cell in order to receive PWS broadcast. In this state, the UE 210 should be required to search for other RATs to go back to a cell that is more suitable for the UE 210 and the services that it wishes to be provided with. In some examples, if the NB-IoT finds an acceptable cell, for instance if the acceptable cell supports emergency signalling and / or PWS broadcasting, the NB-IoT UE 210 may move to a ‘Camped on any cell’ state. This state does not exist for NB-IoT. When the NB-IoT is in a ‘Camped on any cell’ state, the NB-IoT UE 210 may search for suitable cells, which may also include searching for suitable cells that support PWS broadcasting. In some examples, it is envisaged that a new type of cell category may be introduced, instead of Acceptable cell: referred to as an emergency cell or a PWS broadcast cell, or any other suitable cell category. This new type of cell category may be a cell that a UE 210 may camp on just to receive PWS broadcasting. In some examples, it is envisaged that this may be specific for NB-loT. In some examples, it is envisaged that the above examples may be applicable if the UE 210 also supports receiving PWS broadcasts. The NB-IoT UE 210 that supports receiving PWS broadcasts, but may not wish to operate as such, may be configured to not perform the above operation. The UE in this example may, for instance, be configured by an implementer, or it may be configurable by a network, such as a core network for instance using NAS. In some examples, it is envisaged that the UE 210 may be always configured to monitor for an RNTI (C-RNH, P-RNTI, SI-RNTI, PWS-RNTI or other RNTI) for (N)PDCCH, which indicates that PWS message is being broadcasted on the anchor carrier. This may be performed regardless of any other paging configurations, such as any configured paging narrowband channels or paging carriers, for instance via SIB22-NB. Here, the UE 210 may be configured to monitor for P-RNTI on different narrowband channels or paging carriers, and this may be ignored or overridden if the UE 210 is configured to monitor for PWS broadcast indications. Alternatively, in some examples, the UE 210 may be configured to monitor for paging on multiple carriers or narrowband channels according to the configurations. Thus, the UE 210 may be configured to monitor P-RNTI for M or NPDCCH on a non-anchor or paging narrowband channels and configured to monitor RNTI (C-RNTI, P-RNTI, SI-RNTI, PWS-RNTI or other RNTI) for M or NPDCCH, which indicates that PWS message is being broadcasted on the anchor carrier or a narrowband channel. In some examples, it is envisaged that a core network element, such as an MME (for 4G this would be an EPC) or AMF (for 5GC), may indicate that the eNB 220 shall also broadcast the indication over the NB-IoT cell. Otherwise, the eNB 220 may assume that the cell shall only broadcast the indication over the normal E-UTRA cell. In some examples, it is envisaged that this approach may be a result of the MME being better aware of the services that are to be delivered in the network. In some examples, it is envisaged that the indication may indicate that the PWS broadcast shall be performed in the associated NB-IoT cells, in addition to cells in other RATs, or it may be indicated that it shall only be performed in the associated NB-IoT cells. This is illustrated in FIG. 7. Referring now to FIG. 7, one example of a message sequence chart 700 is illustrated whereby an indication may indicate that the PWS broadcast shall be performed in the associated NB-IoT cells in addition to cells in other RATs, or may be indicated that it shall only be performed in the associated NB-IoT cells, in accordance with some example embodiments. At 720, a MME 715 (or AMF) sends a WRITE-REPLACE WARNING REQUEST message to an eNB 220, which indicates a broadcast PWS in an NB-IoT cell. At 750, the eNB 220 then broadcasts the PWS emergency message, following which, at 780, the UE 210 is able to acquire the PWS broadcasted message. In some examples, it is envisaged that this may also be signalled by indicating NB-IoT cell IDs in the PWS emergency message. In one example, it is envisaged that the UE 210 may send the capability to the network, e.g., eNB 220, that the NB-IoT UE 210 is capable of receiving PWS broadcasts. This may apply for both RRC idle and RRC connected mode, or only be for one of the modes. If it applies to connected mode, then the capability may indicate that the UE 210 is capable of acquiring the related system information. In some examples, it may also mean that the UE 210 is capable of both monitoring for an indication of PWS being broadcasted in connected mode, which in some examples may imply that the UE 210 is capable of monitoring a specific RNTI for a specific format on (N)PDCCH. Specific examples are now described with regard to a 5G implementation and the 3GPP™ 5G standard. Example A - Indication in NB-IoT direction indication -------------------------- 36.331 VI8.2.0 example-------------------------- 6.7.5 Direct Indication Information: Direct Indication information is transmitted on NPDCCH using P-RNTI but without associated Paging-NB message. Table 6.7.5-1 defines the Direct Indication information, see TS 36.212

[22] , clause 6.4.3.3. When bit n is set to 1, the UE shall behave as if the corresponding field is set in the Paging-NB message, see 5.3.2.3. Bit 1 is the least significant bit. Table 6.7.5-1: Direct Indication information Bit Field in Direct Indication information 1 systemlnfoModification 2 systemlnfoModification-eDRX 3 etws-Indication 4 cmas-Indication 5, 6, 7, 8 Not used and shall be ignored by UE if received -------------------------- 36.331 VI8.2.0 example-------------------------- Example B - Indication in DCI format N1 --------------------------36.212 V18.0.0 example-------------------------- 6.4.3.2 DCI Format N1 DCI format N1 is used for the scheduling of one NPDSCH codeword per TTI in one cell, random access procedure initiated by a NPDCCH order, notifying SC-MCCH change, and operation on preconfigured UL resources. The DCI corresponding to a NPDCCH order is carried by NPDCCH. The following information is transmitted by means of the DCI format N1: If the format N1 CRC is scrambled by C-RNTI or RA-RNTI or PUR-RNH: Flag for format NO / format N1 differentiation - 1 bit, where value 0 indicates format NO and value 1 indicates format N1 NPDCCH order indicator - 1 bit . . . OMITTED . . . Otherwise, Scheduling delay - 3 bits as defined in clause 16.4.1 of [3] Resource assignment - 3 bits as defined in clause 16.4.1.3 of [3] Modulation and coding scheme - 4 bits as defined in clause 16.4.1.5 of [3], If npdsch-16QAM-Config is configured and the value is ' 1111', it functions as 16QAM indicator. Repetition number - 4 bits as defined in clause 16.4.1.3 of [3], If 16 QAM is indicated, it functions as Modulation and coding scheme for 16QAM as defined in 16.4.1.5 of [3]. New data indicator - 1 bit. If multiple TB are scheduled, it functions as New data indicator for the first TB. HARQ-ACK resource - 4 bits as defined in clause 16.4.2 of [3], If downlinkHARQ-FeedbackDisabled-DCI-NB is configured, or if downlinkHARQ-FeedbackDisabled-Bitmap-NB and downlinkHARQ-FeedbackDisabled-DCI-NB are configured, and the value is ‘ 15’, it functions as a HARQ feedback disabled indicator. DCI subframe repetition number - 2 bits as defined in clause 16.6 in [3] Number of scheduled TB for SC-MTCH - 3 bits, indicating from 1 to 8 TBs. This field is only present if higher layer parameter sc-mtch-InfoListMultiTB-rl6 is enabled and the CRC of the DCI is scrambled by G-RNTI. Number of scheduled TB for Unicast - 1 bit, where value 0 indicates a single TB is scheduled and value 1 indicates multiple TB are scheduled. This field is only present if higher layer parameter npdsch-MultiTB-Config is enabled and the corresponding DCI is mapped onto the UE specific search space given by the C-RNTI as defined in [3] HARQ process number - 1 bit. This field is only present if 2 HARQ processes are configured and the corresponding DCI format is mapped onto the UE specific search space given by the C-RNTI as defined in [3], or if Number of scheduled TB for Unicast is present. If multiple TB are scheduled, it functions as New data indicator for the second TB. Resource reservation - 1 bit as defined in clause 16.4 of [3], This field is only present if higher layer parameter resourceReservationConfigDL is configured and the DCI is mapped onto the UE-specific search space given by C-RNTI as defined in [3], PWS broadcasting indicator - 1 bit. This field is only present if higher layer parameterpws-DCI-Indication is configured and the DCI is mapped onto the UE-specific search space given by C-RNTI as defined in [3], When the format N1 CRC is scrambled with a RA-RNTI or a G-RNTI, then the following fields among the fields above are reserved for RA-RNTI and not present for G-RNTI: New data indicator HARQ-ACK resource If the number of information bits in format N1 mapped onto the same search space is less than that of format NO and the format N1 CRC is not scrambled by G-RNTI, zeros shall be appended to format N1 until the pay load size equals that of format NO. --------------------------36.212 VI8.0.0 example-------------------------- Example C - MAC CE -------------------------- 36.321 VI8.2.0 example-------------------------- 6.1.3.3 PWS Indication MAC Control Element The PWS indication MAC Control Element is identified by a MAC PDU subheader with LCID as specified in table 6.2.1-1. It has a fixed size of zero bits. -------------------------- 36.321 VI8.2.0 example-------------------------- Example D - Indication in RRC release message -------------------------- 36.331 VI8.2.0 example-------------------------- 5.3.12 UE actions upon leaving RRC_CONNECTED or RRCIN ACTIVE Upon leaving RRC_CONNECTED or RRC INACTIVE, the UE shall: . . . OMITTED . . . 1> if entering RRCIDLE was triggered by reception of the RRCConnectionRelease message including a etws-Indication. 2> acquire SystemlnformationBlockTypel 0 and SystemlnformationBlockTypel 1 before performing any of the procedures in TS 36.304, clause 5.2.7; 1> if entering RRC IDLE was triggered by reception of the RRCConnectionRelease message including a cmas-Indication. 2> acquire SystemlnformationBlockTypel before performing any of the procedures in TS 36.304, clause 5.2.7; -------------------------- 36.331 VI8.2.0 example-------------------------- -------------------------- 36.331 VI8.2.0 example-------------------------- RRCConnectionRelease-NB The RRCConnectionRelease-NB message is used to command the release of an RRC connection, or to complete an UP-EDT procedure. Signalling radio bearer: SRB1 or SRBlbis RLC-SAP: AM Logical channel: DCCH Direction: E-UTRAN to UE RRCConnectionRelease-NB message - ASN1 START RRCConnectionRelease-NB ::= rrc-Transactionldentifier criticalExtensions cl rrcConnectionRelease-r 13 spare 1 NULL criticalExtensionsFuture . . . OMITTED . . . SEQUENCE { RRC-Transactionldentifier, CHOICE { CHOICE { RRCConnectionRelease-NB-r 13-IEs, SEQUENCE {} RRCConnectionRelease-NB-vl700-IEs ::= SEQUENCE { cbp-Index-rl7 INTEGER (1..2) OPTIONAL, - Need OR nonCriticalExtension RRCConnectionRelease-NB-vl900-IEs OPTIONAL RCConnectionRelease-NB-vl900-IEs ::= SEQUENCE { cmas-Indication-rl9 ENUMERATED {true} OPTIONAL, — Need OP etws-Indication-rl9 ENUMERATED {true} OPTIONAL, — Need OP nonCriticalExtension SEQUENCE}} OPTIONAL . . . OMITTED . . . - ASN1STOP i RRCConnectionRelease-NB field descriptions [ . . OMITTED . . . cmas-1ndication: This field indicates ... etws-Indication: This field indicates ... j.........' ' Q..................................................................................................................................................................................... -------------------------- 36.331 VI8.2.0 example-------------------------- Example E - Acquiring emergency broadcast due to system information update -------------------------- 36.331 VI8.2.0 example-------------------------- 5.3.2.3 Reception of the Paging message by the UE Upon receiving the Paging message, the UE shall: . . . OMITTED . . . 1> if the UE is not configured with a DRX cycle longer than the modification period and the systemlnfoModification is included; or 1> if the UE is configured with a DRX cycle longer than the modification period and the systemlnfoModification-eDRX is included: 2> if the UE is configured to check for emergency broadcast upon system information update: 3> re-acquire SystemlnformationBlockTypel immediately, i.e without waiting until the next system information update period boundary; 3> If schedulinglnfoList indicates that one of SystemInformationBlockTypelO-12 is present: 4> acquire the respective system information blocks immediately 3> else: 4> re-acquire the required system information using the system information acquisition procedure as specified in 5.2.2; 2> else: 3> re-acquire the required system information using the system information acquisition procedure as specified in 5.2.2; -------------------------- 36.331 VI8.2.0 example-------------------------- Example F - eNB indicating PWS capability -------------------------- 36.331 VI8.2.0 example-------------------------- SystemlnformationBlockType 1 message - ASN1 START SystemlnformationBlockType! -BR-r 13 : := SystemlnformationBlockType 1 SystemlnformationBlockType 1 ::= SEQUENCE { cellAccessRelatedlnfo SEQUENCE { plmn-IdentityList PLMN-IdentityList, trackingAreaCode TrackingAreaCode, cellldentity Cellldentity, cellBarred ENUMERATED {barred, notBarred}, intraFreqReselection ENUMERATED {allowed, notAllowed}, csg-Indication BOOLEAN, csg-Identity CSG-Identity OPTIONAL - Need OR cellSelectionlnfo SEQUENCE { q-RxLevMin Q-RxLevMin, q-RxLevMinOffset INTEGER (1..8) OPTIONAL-Need OP }, p-Max P-Max OPTIONAL, - Need OP freqBandlndicator F reqBandlndicator, schedulinglnfoList S chedulinglnfoList, tdd-Config TDD-Config OPTIONAL, - Cond TDD si-WindowLength ENUMERATED { msl, ms2, ms5, mslO, msl5, ms20, ms40}, systemlnfoValueTag INTEGER (0..31), nonCriticalExtension SystemlnformationBlockType l-v890-IEs OPTIONAL SystemlnformationBlockType l-vl800-IEs ::= SEQUENCE { freqBandIndicatorAerial-rl8 FreqBandlndicator-rl 1 OPTIONAL, — Need OR freqBandlnfoAerial-rl 8 NS-PmaxListAerial-rl8 OPTIONAL, — Need OR multiBandlnfoListAerial-rl 8 MultiBandInfoListAerial-rl8 OPTIONAL, — Need OR nonCriticalExtension SystemlnformationBlockTypel -vl 900-IEs OPTIONAL SystemInformationBlockTypel-vl900-IEs ::= SEQUENCE { pws-Support-rl9 ENUMERATED {cmas, etws, cmas-etws}, nonCriticalExtension SEQUENCE {} OPTIONAL - ASN1STOP SystemlnformationBlockTypel field descriptions pws-Support Indicates whether the cell supports PWS message broadcasting. The value etws indicates support of ETWS via SystemlnformationBlockTypelO-NB and SystemlnformationBlockTypel 1-NB and value cmas indicates support of CMAS via SystemlnformationBlockTypel2-NB. A UE may use this to prioritize cells that support PWS. -------------------------- 36.331 VI8.2.0 example-------------------------- Example G - NB-IoT idle mode operation --------------------------36.304 V18.2.0 example-------------------------- 5.2.8a Any Cell Selection state for NB-IoT In this state, the UE shall attempt to find a suitable cell of any PLMN to camp on and searching first for a high quality cell, as defined in clause 5.1.2.2. The UE, which is not camped on any cell, shall stay in this state until a suitable cell or an acceptable cell that supports PWS broadcasting is found. 5.2.9 Camped on Any Cell state In this state, the UE shall perform the following tasks: - monitor the paging channel of the cell as specified in clause 7 according to information sent in system information; - monitor relevant System Information as specified in TS 36.331 [3]; - perform necessary measurements for the cell reselection evaluation procedure; - execute the cell reselection evaluation process on the following occasions / triggers: 1) UE internal triggers, so as to meet performance as specified in TS 36.133

[10] ; 2) When information on the BCCH or BR-BCCH used for the cell reselection evaluation procedure has been modified; - regularly attempt to find a suitable cell trying all frequencies of all RATs that are supported by the UE. If a suitable cell is found, UE shall move to camped normally state; - if the UE supports voice services and the current cell does not support emergency call as indicated in System information specified in TS 36.331 [3], the UE should perform cell selection / reselection to an acceptable cell of any supported RAT regardless of priorities provided in system information from current cell, if no suitable cell is found. NOTE: The UE is allowed to not perform reselection to an inter-frequency E-UTRAN cell in order to prevent camping on a cell on which it cannot initiate an IMS emergency call. --------------------------36.304 V18.2.0 example-------------------------- Example I - acceptable NB-IoT cell --------------------------36.304 V18.2.0 example-------------------------- acceptable cell: An "acceptable cell" is a cell on which the UE may camp to obtain limited service (originate emergency calls and receive ETWS and CMAS notifications), and it is not applicable to RRC INACTIVE state. Such a cell shall fulfil the following requirements, which is the minimum set of requirements to initiate an emergency call and to receive ETWS and CMAS notification in a E-UTRAN network: - The cell is not barred, see clause 5.3.1; - The cell selection criteria are fulfilled, see clause 5.2.3.2; - For an NB-IoT cell, the cell supports PWS broadcasting --------------------------36.304 V18.2.0 example-------------------------- In particular, it is envisaged that the aforementioned inventive concept can be applied by a semiconductor manufacturer to any integrated circuit comprising a signal processor configured to perform any of the aforementioned operations. Furthermore, the inventive concept can be applied to any circuit that is able to configure, process, encode and / or decode signals for wireless distribution. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a digital signal processor, or application-specific integrated circuit (ASIC) and / or any other sub-system element. It will be appreciated that, for clarity purposes, the above description has described example embodiments with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors, for example with respect to the signal processor may be used without detracting from the concepts described herein. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization. Aspects may be implemented in any suitable form including hardware, software, firmware or any combination of these. Example embodiments may optionally be implemented, at least partly, as computer software running on one or more data processors and / or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the concepts have been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in other examples. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps. Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and / or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate. Thus, examples have been described that provide improved devices, networks and methods to support PWS broadcast messages. In particular, some issues identified by the inventors have been alleviated or resolved, including: how a UE acquires the PWS broadcasting in connected and idle mode; and how to ensure that a UE camps on cells that are capable of indicating PWS broadcast to satisfy a use case, wherein the aforementioned disadvantages with prior art arrangements have been substantially alleviated. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions are used. 3 GPP 3rd Generation Partnership Project 6G 6th Generation 5G 5th Generation 5GC 5G Core 5GS 5G System ACK Acknowledge AM Acknowledged Mode AMF Access and Mobility management Function AS Access Stratum BL Bandwidth-reduced Low-complexity CA Carrier Aggregation CCCH Common Control Channel CDMA Code Division Multiple Access CE Coverage Enhancement CIoT Cellular loT CN Core Network C-RNTI Cell RNTI CS Circuit Switched DC Dual Connectivity DCCH Dedicated Control Channel DRB Data Radio Bearer EDGE Enhanced Data rates for Global Evolution EDT Early Data Transmission eMTC enhanced Machine Type Communication EN E-UTRAN NR eNB Base Station EPC Evolved Packet Core EPS Evolved Packet System E-UTRA Evolved Universal Terrestrial Radio Access E-UTRAN Evolved Universal Terrestrial Radio Access Network GEO Geosynchronous Equatorial Orbit GERAN GSM EDGE Radio Access Network gNB GSM 5G Base Station Groupe Special Mobile HAPS High Altitude Platform Station HARQ Hybrid Automatic Repeat Request ID Identity / Identifi cation IE Information Element 5 loT Internet of Things LEO Lower Earth Orbit LTE Long Term Evolution LTE-M LTE Machine Type Communication MAC Medium Access Control 10 MCG Master Cell Group MEO Medium Earth Orbit MME Mobility Management Entity NAS Non Access Stratum NB Narrow Band 15 BS Base Station NG Next Generation NR New Radio NTN Non-Terrestrial Network PCell Primary Cell 20 PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PSCell Primary and Secondary Cells RAN Radio Access Network RAT Radio Access Technology 25 RB Radio Bearer RLC Radio Link Control RLF Radio Link Failure RNTI Radio Network Temporary Identifier ROHC Robust Header Compression 30 RRC Radio Resource Control SI Interface between RAN and CN SAP Service Access Point SCG Secondary Cell Group SIB System Information Block 35 SRB Signalling Radio Bearer S-TMSI Short TMSI TAU Tracking Area Update TM Transparent Mode TMSI Temporary Mobile Subscriber Identity TN Terrestrial Network TS Technical Specification Txxx Timer xxx 5 UE User Equipment UP User Plane X2 / Xn Interface between RAN nodes.

Claims

1. A wireless communication unit (210) for communicating in a wireless communication system, wherein the wireless communication unit (210) is an Internet of Things, loT, wireless communication unit or an enhanced Machine Type Communication, eMTC, wireless communication unit, the wireless communication unit (210) comprising:a transceiver arranged to receive a message direct from a wireless serving communication unit (220); anda processor, operably coupled to the transceiver, arranged to process the message, wherein the message indicates a broadcast public warning system, PWS, message;wherein, in response to the processed message, the transceiver is arranged to receive the broadcast PWS message.

2. The wireless communication unit (210) of Claim 1 wherein the wireless communication unit (210) is a narrowband loT, NB-IoT, wireless communication unit and the wireless communication system is a non-terrestrial network, NTN.

3. The wireless communication unit (210) of any preceding Claim wherein the message received direct from the wireless serving communication unit (220) is Downlink Control Information, DCI.

4. The wireless communication unit (210) of Claim 3 wherein the DCI is one of: scrambled with a Paging Radio Network Temporary Identifier, P-RNTI; a DCI format N2;received in a Physical Downlink Control Channel, PDCCH;received in a NB-IoT Physical Downlink Control Channel, NPDCCH, using P-RNU but without an associated Paging-NB message;received in a MTC Physical Downlink Control Channel, MPDCCH.

5. The wireless communication unit (210) of Claim 4 wherein the message that provides a direct indication of the broadcast PWS message is received when the wireless communication unit (210) is in connected mode with the wireless serving communication unit (220).

6. The wireless communication unit (210) of Claim 1 or Claim 2 wherein, in connected mode with wireless serving communication unit (220), the transceiver and processor of the wireless communication unit (210) are arranged to receive and process system information blocks, SIBs, that contain the broadcast PWS message.

7. The wireless communication unit (210) of Claim 6 wherein the transceiver and processor are arranged to receive the broadcast PWS message using one of:an Earthquake and Tsunami Warning System, ETWS, via one of a system information block, SIB, SIB 10 message or SIB 11 message;a Commercial Mobile Alert System, CMAS, via a SIB 12 message.

8. The wireless communication unit (210) of Claim 6 wherein, in connected mode, the transceiver and processor of the wireless communication unit (210) are arranged to monitor a Radio Network Temporary Identifier, RNTI, for a Downlink Control Information, DCI that indicates a broadcast PWS message and in response thereto the transceiver is arranged to receive the broadcast PWS message.

9. The wireless communication unit (210) of Claim 1 or Claim 2 wherein the transceiver and processor are arranged to:transmit a capability message to the wireless serving communication unit (220) in connected mode wherein the capability message indicates that the wireless communication unit (210) includes a capability to receive a broadcast PWS message when the wireless communication unit (210) operates in a radio resource control, RRCIDLE state or an RRCINACTIVE state.

10. The wireless communication unit (210) of Claim 9 wherein the transceiver and processor of the wireless communication unit (210) are arranged to receive and process a radio resource control, RRC, connection release message received direct from the wireless serving communication unit (220) and in response thereto enter a RRC IDLE state or an RRC INACTIVE state and receive the broadcast PWS message.

11. The wireless communication unit (210) of Claim 1 or Claim 2, wherein the transceiver and processor are arranged to receive and process a message that indicates a PWS broadcast capability of a first communication cell supported by a first wireless serving communication unit (220).

12. The wireless communication unit (210) of Claim 11 wherein the transceiver and processor of the wireless communication unit (210) are arranged to receive and process a system information block, SIB that indicates the first communication cell includes the PWS broadcast capability of at least one of:an Earthquake and Tsunami Warning System, ETWS;a Commercial Mobile Alert System, CMAS.

13. The wireless communication unit (210) of Claim 11 or Claim 12, wherein in response to the processed message that indicates a capability PWS broadcast of the first communication cell supported by the first wireless serving communication unit (220), the transceiver and processor are arranged to prioritize camping on the first communication cell over camping on a second communication cell supported by a second wireless serving communication unit that is not capable of transmitting a message that indicates a capability of PWS broadcast.

14. A method for a wireless communication unit for communicating in a wireless communication system, wherein the wireless communication unit (210) is an Internet of Things, loT, wireless communication unit or an enhanced Machine Type Communication, eMTC, wireless communication unit the method comprising at the wireless communication unit: receiving a message direct from a wireless serving communication unit (220);processing the message, wherein the message indicates a broadcast public warning system, PWS, message in the wireless communication system; andreceiving, in response to the processed message, the broadcast PWS message.

15. A wireless serving communication unit (220) arranged to support communications for a plurality of wireless communication units in a communication system, wherein the plurality ofwireless communication units comprise Internet of Things, loT, wireless communication units or enhanced Machine Type Communication, eMTC, wireless communication units, wherein the wireless serving communication unit (220) comprises:a transceiver; anda processor, operably coupled to the transceiver, arranged to:identify a broadcast of a public warning system, PWS, message in the communication system; andtransmit a message direct to at least one wireless communication unit (210) of the plurality of wireless communication units wherein the message provides an indication of the broadcast PWS message.

16. The wireless serving communication unit (220) of Claim 15 wherein the message transmit direct at least one wireless communication unit (210) provides a direct indication of the broadcast PWS message in Downlink Control Information, DCI.

17. The wireless serving communication unit (220) of Claim 15 or Claim 16 wherein thetransceiver and processor are arranged to transmit a capability message that indicates to the plurality of wireless communication units that the wireless serving communication unit (220) is able to perform at least one of: transmit the message that provides an indication of the broadcast PWS message, broadcast the PWS message.

18. The wireless serving communication unit (220) of Claim 17 wherein the message that provides an indication of the broadcast PWS message is transmit to the plurality of wireless communication units in a system information block, SIB, SIB1 message.

19. The wireless serving communication unit (220) of any of preceding Claims 15 to 18 wherein the wireless serving communication unit (220) is a narrowband Internet of Things NonTerrestrial Network, NB-IoT NTN, wireless serving communication unit (220).

20. The wireless serving communication unit (220) of any of preceding Claims 15 to 19 wherein the transceiver and processor are arranged to:receive a PWS capability message from the wireless communication unit (210) in connected mode, wherein the PWS capability message indicates that the wireless communication unit (210) includes a capability to receive a broadcast PWS message when the wireless communication unit (210) operates in a radio resource control, RRCIDLE state or an RRCINACTIVE state; andtransmit, in response thereto, a radio resource control, RRC, connection release message direct to the wireless communication unit (210) that enables the wireless communication unit (210) to enter a RRC IDLE state or an RRCIN ACTIVE state and receive the broadcast PWS message.

21. A method for a wireless serving communication unit (220), the method comprising, at the serving communication unit (220):supporting communications for a plurality of wireless communication units in a communication system, wherein the plurality of wireless communication units comprise Internet of Things, loT, wireless communication units or enhanced Machine Type Communication, eMTC, wireless communication units;identifying a broadcast of a public warning system, PWS, message in the communication system; andtransmitting a message direct to at least one wireless communication unit (210) of the plurality of wireless communication units, wherein the message provides an indication of the broadcast PWS message.w

Images