Patent Description:
According to the 3GPP Minimization of Interruption (MINT) feature, a mobile network, such as a public land mobile network (PLMN) can host user equipment (UEs) of another network in case of a disaster situation. For example, if a first network becomes inoperative, the users of that network may be allowed to use another network in the event of a disaster. Two types of PLMNs are discussed herein: a serving PLMN and a disaster PLMN. A serving PLMN is a PLMN which is associated with a given cell under normal (non-disaster) situations. These may be the PLMN(s) of the operator(s) which owns the cell, and potentially other PLMNs whose UEs also are allowed to use the cell. A Disaster PLMN is a PLMN whose UEs are welcome to use the cell in disaster situations. These users may normally (in non-disaster situations) not be allowed to use the cell, but are only allowed to do so when there is a disaster so their normal PLMN is not operating normally.

The serving PLMNs of a cell are indicated in the CellAccessRelatedInfo field in the SIB1 message broadcast in the cell as part of the system information associated with the cell. There can be up to <NUM> Serving PLMNs in a normal New Radio (NR) cell.

One cell in a 3GPP system can be shared among different operators. Normally, each operator has their own PLMN. If three operators (e.g., operator A, operator B and operator C) share a cell, the PLMNs of those three operators are all broadcast by the cell as part of its system information. For example, referring to <FIG>, a mobile network is illustrated including a base station <NUM> that serves a cell <NUM>. The cell <NUM> is shared by two PLMNs, PLMN <NUM> and PLMN <NUM>. A first UE 20A is authorized to use PLMN <NUM> in the cell <NUM>, while a second UE 20B is authorized to use PLMN <NUM> in the cell <NUM>.

In particular, the System Information Block <NUM> (SIB1) has a field named "cellAccessRelatedInfo". That field contains a list named PLMN-IdentityInfoList. Each entry in the PLMN-IdentityInfoList is a PLMN-IdentityInfo. Each PLMN-IdentityInfo has several fields such as a cell identity, tracking area code, etc., along with the plmn-IdentityList field. That field is yet another list. Each entry in that list is a PLMN identity.

The contents of a SIB1 message are shown in Table <NUM>, below.

In situations where there are many PLMNs, to indicate disaster PLMNs for serving PLMNs would require a large amount of signalling. The signalling size of system information, and in particular SIB1 (since SIB1 is frequently repeated) should be kept low so as not to waste radio resources.

3GPP document CP-<NUM> suggests that if a PLMN D is subject to disaster and PLMN A is alive and not subject to disaster. PLMN A is informed of the disaster condition in PLMN D. Once the PLMN A is prepared to accept inbound roamers from PLMN D, PLMN A shall update its broadcast information (System Information) to include an indication of disaster roaming active condition. Broadcasting the disaster roaming active condition in SIB1 and not broadcasting in SIB X additional PLMN IDs for which disaster roaming is active indicates that disaster roaming is allowed for UEs from any PLMN. This is useful for the case where all PLMNs in the area, except PLMN A, are facing disaster condition. <CIT> suggests an access and mobility management function (AMF) of a first public land mobile network (PLMN) receives status information from a first network function. The status information comprises a network disaster indication and an identifier of the second PLMN. The network disaster indication indicates a failure of a second PLMN in a coverage area. Based on the status information, the AMF determines at least one base station of the first PLMN. The AMF sends a configuration message to the at least one base station. The configuration message comprises the status information.

The invention defines a network node, a user equipment and the corresponding methods for signalling disaster PLMNs in a flexible manner so that signalling overhead is kept small.

According to one aspect, the above-mentioned object is achieved with a method according to claim <NUM> and a corresponding network node according to claim <NUM>. According to another aspect, the above-mentioned object is achieved with a method according to claim <NUM> and a corresponding user equipment according to claim <NUM>.

As described above, the SIB1 message includes lists of lists for PLMNs. As an example of this signalling, assume that the three operators (A, B and C) share a cell, where operator A and B use the same cell identities for the shared cell, while operator C uses its own cell identity. The list of lists approach allows this situation by signalling the following in SIB1: the cellAccessRelatedInfo field in the cell has two entries in the PLMN-IdentityInfoList. The first entry is the PLMN-IdentityInfo for operator A and operator B. That first entry of PLMN-IdentityInfo has two PLMNs listed in plmn-IdentityList, namely PLMN A and PLMN B. The PLMN-IdentityInfo also another entry, namely an entry for operator C. That entry has also a plmn-IdentityList, but with only one entry, namely PLMN C.

There currently exist certain challenge(s). For example, to indicate all associations of disaster PLMNs and serving PLMNs in SIB1 may require a significant amount of signalling overhead, since there may be many PLMNs. The signalling size of system information, and in particular SIB1 (since SIB1 is frequently repeated), should be kept low as to not waste radio resources.

Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, some embodiments described herein provide methods for signalling the identity of disaster PLMNs that may use a cell and the association of disaster PLMNs with the serving PLMN(s) of the cell. In particular, some embodiments described herein provide signalling approaches for disaster PLMN provision. Embodiments described herein include sending a common list of disaster PLMNs that are applicable to sets of serving PLMNs of the cell, sending a common list of disaster PLMNs that are applicable to selected sets of serving PLMNs of the cell, sending a common list of disaster PLMNs and indicate which of those apply to which serving PLMNs, sending both a common list and a serving PLMN-specific list and the UE uses the union of them, and sending a common list and for each serving PLMN indicate to use the common list or use a serving PLMN-specific list of disaster PLMNs.

Certain embodiments may provide one or more of the following technical advantage(s). Some embodiments described herein may provide efficient signalling of disaster PLMNs and associations of disaster PLMNs with one or more serving PLMNs in the system information of a cell.

Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

In the following description, when it is described that information is signaled for or applies to a serving PLMN, such information can be signaled for or apply to a set of serving PLMNs (i.e. one or more PLMNs), due to the list-of-list structure used to signal the identity of PLMNs in SIB1 messages, as described above. Moreover, the description herein of the use of SIB1 to signal the identities of disaster PLMNs is provided as a non-limiting example. It may be possible to signal the identities of disaster PLMNs in another portion of the system information, such as another SIB. Some embodiments are described herein in connection with NR technology. However, some embodiments may be applied to other radio access technologies, such as LTE, UMTS, etc..

Some embodiments signal the availability of disaster PLMNs by providing a common list of disaster PLMNs that are applicable to all serving PLMNs of the cell. That is, in some embodiments, the network indicates a list of disaster PLMNs which are common for all serving PLMNs. This can be implemented by a list of PLMNs which is placed in the CellAccessRelatedInfo IE of SIB <NUM> as shown, for example, in Table <NUM> below.

Another approach to implement this embodiment in the specification is that the list is placed on the top-level of SIB <NUM>, as shown in Table <NUM> below.

In yet further embodiments, the common list of Disaster PLMNs that are applicable to all serving PLMNs may be signalled in another SIB.

In further embodiments, the network indicates a list of disaster PLMNs which are common for a selected set of serving PLMNs. The network would indicate for a serving PLMN (or set of Serving PLMNs) whether the list of common disaster PLMNs applies to the serving PLMN or not. That can be implemented by a flag for a serving PLMN. An example implementation is shown in Table <NUM> below in which the flag "commonDisasterPLMNsApplicable" indicates that the common disaster PLMNs (indicated in commonDisasterPLMN) are applicable to the PLMNs of that PLMN-IndentifyInfo entry.

With this approach, if the flag is not provided/indicated for a serving PLMN, no disaster PLMN are applicable to this serving PLMN. In the example of Table <NUM>, the common disaster PLMNs are placed in CellAccessRelatedInfo but could be placed in another place as well, e.g. on the top-level in SIB <NUM> or in another SIB, etc.
<IMG>.

In further embodiments, the network may provide a set of disaster PLMNs which are common for a set of serving PLMNs. The network may further indicate, for a set of serving PLMNs, which of the common disaster PLMNs apply for the set of serving PLMNs.

For example, assume there are disaster PLMN X, Y and Z, and serving PLMN A and B. The network would indicate for PLMN A which of disaster PLMN X, Y and Z are applicable, and similarly, indicate for PLMN B which of disaster PLMN X, Y and Z are applicable. It would be possible to indicate that none of the common disaster PLMNs are applicable for a given serving PLMN.

This association of disaster PLMNs and serving PLMNs can be implemented by a mapping. There can be at least these two approaches for the mapping. In a first approach, for each (set of) serving PLMN the network would indicate which of the disaster PLMNs apply. In a second approach, for each disaster PLMN the network indicates for which (set of) serving PLMNs this disaster PLMN applies.

One approach that the mapping is implemented using a bitmap where each bit in the bitmap corresponds to a PLMN (or set of PLMNs). For example, a bitmap may be provided for a (set of) serving PLMN where the first bit corresponds to the first disaster PLMN, the second bit corresponds to the second disaster PLMN, and so on. If a bit in the bitmap is set to <NUM>, the disaster PLMN applies to the corresponding serving PLMN, while if the bit is set to <NUM>, the disaster PLMN does not apply to the corresponding serving PLMN.

An example implementation of this embodiment is provided in Table <NUM> below. In this example there is a bit string named applicableCommonDisasterPLMNs where each bit of the bit string corresponds to an entry in the list of commonDisasterPLMNs. The first bit corresponds to the first entry and the second bit corresponds to the second entry, and so on. A '<NUM>' on location N in the bitstring means that commonDisasterPLMN on position N is applicable to this Serving PLMN, and a <NUM> means that it is not applicable.

Alternatively, for each disaster PLMN there may be a bitmap where the first entry corresponds to the first set of serving PLMNs, the second bit to the second set of serving PLMNs, and so on. And if the bit is set to <NUM> that means that this disaster PLMN applies to the corresponding set of serving PLMNs but if the bit is set to <NUM> it means that this disaster PLMN does not apply to the corresponding set of serving PLMNs.

In some embodiments, the network sends both a common list of disaster PLMNs, and PLMN-specific disaster PLMNs. For a particular serving PLMN, the UE considers the disaster PLMNs for a serving PLMN to be the union of the common disaster PLMNs and the PLMN-specific disaster PLMNs.

The network may determine which disaster PLMNs shall apply for all serving PLMNs and place those in the common list. The network also determines if there are any disaster PLMNs which are only applicable for particular PLMN(s). If so, the network would place those in the PLMN-IdentityInfo IE for those particular PLMN(s). An example of this approach is shown in Table <NUM>, below.

If, for a serving PLMN, the PLMN-specific disaster PLMN-list is empty or not present, the UE may consider the disaster PLMNs for that serving PLMN to be those in the common list. If the common disaster PLMN list is empty or not present, the UE may consider that the disaster PLMNs for a serving PLMN to be only the PLMN-specific disaster PLMNs.

In some embodiments, the network indicates for a set of serving PLMNs whether the disaster PLMNs that are applicable, are the common disaster PLMNs or a list of specific PLMNs.

This can be implemented by a CHOICE structure in the system information, where the CHOICE is set to a first choice (named commonDisasterPLMNsApplicable in the example shown in Table <NUM> below) or a second choice if a list of specific disaster PLMNs (named specificDisasterPLMNs in the below example) is applicable. If the network uses the first choice, the UE would for the serving PLMN (or set of serving PLMNs) consider the disaster PLMN to be those sent in the common list. If the network uses the second choice the UE would for the serving PLMN consider the disaster PLMN to be those explicitly signaled for the (set of) serving PLMNs.

<FIG> illustrates a method of operating a network node in a radio access network, RAN. The method may include transmitting (block <NUM>) system information in a cell served by the network node. The system information includes a set of one or more disaster PLMNs. A UE that can normally connect to one of the disaster PLMNs in the set of disaster PLMNs can use the cell in the event of a disaster in which the UE is unable to communicate with the disaster PLMN. The system information may include, for example, a system information block message, such as a SIB <NUM> message.

In some embodiments, the system information includes a common set of disaster PLMNs that are common to a specified set of serving PLMNs of the cell.

In some embodiments, the common set of disaster PLMNs that are available to UEs associated to the specified set of serving PLMNs of the cell is provided within a top level of a system information block. The specified set of serving PLMNs of the cell for which the common set of disaster PLMNs is provided may be identified by a flag associated with the specified set of serving PLMNs of the cell.

In some embodiments, the system information includes one or more lists of disaster PLMNs. The system information may indicate a list of disaster PLMNs associated to a set of serving PLMNs of the cell.

In the claimed embodiment, the system information indicates which disaster PLMNs are associated to a set of serving PLMNs of the cell such that UEs associated to the disaster PLMN can use a PLMN in the associated set of serving PLMNs in the event of disaster.

In some embodiments, the system information includes a common set of disaster PLMNs that are associated to a selected set of serving PLMNs of the cell. For each set of serving PLMNs of the cell, the system information may identify whether UEs associated to the set of serving PLMNs should use the common set of disaster PLMNs or a set of PLMN-specific disaster PLMNs.

<FIG> illustrates a method of operating a user equipment, UE, in a radio access network, RAN. The method includes receiving (block <NUM>) system information in a cell of the RAN, wherein the system information includes a set of one or more disaster PLMNs, including a disaster PLMN to which the UE is associated, that can use the cell in the event of a disaster in which the UE is unable to communicate with the disaster PLMN, and communicating (block <NUM>) with the cell in the event of a disaster in which the UE is unable to communicate with the disaster PLMN. The system information may include, for example, a SIB message, such as a SIB1 message.

In some embodiments, the system information includes a common set of disaster PLMNs that are associated to a specified set of serving PLMNs of the cell. The common set of disaster PLMNs that are associated to the specified set of serving PLMNs of the cell may be provided within a top level of the system information. The specified set of serving PLMNs of the cell for which the common set of disaster PLMNs is provided may be identified by a flag associated with the specified set of serving PLMNs of the cell.

In some embodiments, the system information indicates which of the disaster PLMNs in the common set of disaster PLMNs is associated to the specified set of serving PLMNs of the cell.

In some embodiments, the system information includes a common set of disaster PLMNs that are associated to a selected set of serving PLMNs of the cell. For each set of serving PLMNs, the system information identifies whether the set of serving PLMNs is associated to the common set of disaster PLMNs or a set of PLMN-specific disaster PLMNs.

<FIG> shows an example of a communication system <NUM> in accordance with some embodiments.

In the example, the communication system <NUM> includes a telecommunication network <NUM> that includes an access network <NUM>, such as a radio access network (RAN), and a core network <NUM>, which includes one or more core network nodes <NUM>. The access network <NUM> includes one or more access network nodes, such as network nodes 410a and 410b (one or more of which may be generally referred to as network nodes <NUM>), or any other similar <NUM>rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes <NUM> facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 412a, 412b, 412c, and 412d (one or more of which may be generally referred to as UEs <NUM>) to the core network <NUM> over one or more wireless connections.

In some examples, the UEs <NUM> are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network <NUM> on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network <NUM>. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub <NUM> communicates with the access network <NUM> to facilitate indirect communication between one or more UEs (e.g., UE 412c and/or 412d) and network nodes (e.g., network node 410b). In some examples, the hub <NUM> may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub <NUM> may be a broadband router enabling access to the core network <NUM> for the UEs. As another example, the hub <NUM> may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes <NUM>, or by executable code, script, process, or other instructions in the hub <NUM>. As another example, the hub <NUM> may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub <NUM> may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub <NUM> may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub <NUM> then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub <NUM> acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

The hub <NUM> may have a constant/persistent or intermittent connection to the network node 410b. The hub <NUM> may also allow for a different communication scheme and/or schedule between the hub <NUM> and UEs (e.g., UE 412c and/or 412d), and between the hub <NUM> and the core network <NUM>. In other examples, the hub <NUM> is connected to the core network <NUM> and/or one or more UEs via a wired connection. Moreover, the hub <NUM> may be configured to connect to an M2M service provider over the access network <NUM> and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes <NUM> while still connected via the hub <NUM> via a wired or wireless connection. In some embodiments, the hub <NUM> may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 410b. In other embodiments, the hub <NUM> may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 410b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

<FIG> shows a UE <NUM> in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE <NUM> shown in <FIG>.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone's speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

<FIG> shows a network node <NUM> in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network.

Applications <NUM> (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware <NUM> includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers <NUM> (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 808a and 808b (one or more of which may be generally referred to as VMs <NUM>), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer <NUM> may present a virtual operating platform that appears like networking hardware to the VMs <NUM>.

Hardware <NUM> may be implemented in a standalone network node with generic or specific components. Hardware <NUM> may implement some functions via virtualization. Alternatively, hardware <NUM> may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration <NUM>, which, among others, oversees lifecycle management of applications <NUM>. In some embodiments, hardware <NUM> is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system <NUM> which may alternatively be used for communication between hardware nodes and radio units.

<FIG> shows a communication diagram of a host <NUM> communicating via a network node <NUM> with a UE <NUM> over a partially wireless connection. Example implementations, in accordance with various embodiments, of the UE (such as a UE 412a of <FIG> and/or UE <NUM> of <FIG>), network node (such as network node 410a of <FIG> and/or network node <NUM> of <FIG>), and host (such as host <NUM> of <FIG> and/or host <NUM> of <FIG>) discussed in the preceding paragraphs will now be described with reference to <FIG>.

One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the efficiency of transmission of system information and thereby provide benefits such as increased network throughput, and lower overhead.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection <NUM> between the host <NUM> and UE <NUM>, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host <NUM> and/or UE <NUM>. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection <NUM> may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node <NUM>. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host <NUM>. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection <NUM> while monitoring propagation times, errors, etc..

Claim 1:
A method performed by a network node in a radio access network, RAN, comprising:
transmitting (<NUM>) system information in a cell served by the network node, wherein the system information comprises a set of one or more disaster public land mobile networks, PLMNs, that indicate that a user equipment, UE, associated to a disaster PLMN can use the cell in the
event of a disaster in which the UE is unable to communicate with a normal PLMN to which the UE may normally connect, and wherein the system information indicates which disaster PLMNs are associated to a set of serving PLMNs of the cell such that UEs associated to the disaster PLMN can use a PLMN in the associated set of serving PLMNs in the event of a disaster.