GB2604723A - Improvements in and relating to a telecommunication network following a disaster condition - Google Patents

Abstract

A method of controlling access to a network supporting disaster roaming, of a User Equipment, UE, when disaster roaming on the network supporting disaster roaming, wherein the UE sends a non-access stratum NAS message to the network supporting disaster roaming; the network verifies at least one condition in response; and based on the at least one condition, the network supporting disaster roaming accepts the NAS message and indicates that the UE is registered for emergency services. The at least one condition may comprise the UE moving outside its previous registration area RA, moving into a new tracking area TA, being registered for a disaster roaming service or having a PDU session for emergency services. The network supporting disaster roaming may indicate to the UE in a NAS message that the UE is registered for emergency services. The NAS message may be a registration accept message or a configuration update command message.

Description

Improvements in and relating to a telecommunication network following a Disaster Condition The present invention relates to the efficient provision of services to Disaster Inbound Roamers in the event of a Disaster Condition (DC) arising in a telecommunication network. A DC occurs when some or all of a network is unable to offer services to subscribers as a result of e.g. a fire or earthquake or other disaster. In such circumstances, subscribers of an affected network may be allowed to roam and temporarily access another network, not so affected.

Standards specification TS 22.261 lists some requirements to avoid service interruptions that may arise when a disaster condition e.g. fire, occurs on a given Public Land Mobile Network (PLMN) and for which the User Equipments (UEs) are to be redirected to another PLMN in a manner that keeps the service interruption to a minimum.

"A mobile network may fail to provide service in the event of a disaster (for example a fire.) The requirements listed in this clause provide the 5GS with the capability to mitigate interruption of service. UEs may obtain service in the event of a disaster, if there are PLMN operators prepared to offer service. The minimization of service interruption is constrained to a particular time and place. To reduce the impact to the 5G System of supporting Disaster Roaming, the potential congestion resulting from an influx or outflux of Disaster Inbound Roamers is taken into account." As can be seen from the above, the service interruption is limited to a particular time and place and hence only the UEs that are in the given location at the given time of disaster will be impacted by the disaster condition and hence should be serviced by another PLMN.

The following detailed requirements are also listed in IS 22.261.

"6.31.2 Requirements 6.31.2.1 General Subject to regulatory requirements or operator's policy, 3GPP system shall be able to enable a UE of a given PLMN to obtain connectivity service (e.g. voice call, mobile data service) from another PLMN for the area where a Disaster Condition applies.

6.31.2.2 Disaster Condition The 3GPP system shall enable UEs to obtain information that a Disaster Condition applies to a particular PLMN or PLMNs.

NOTE: If a UE has no coverage of its HPLMN, then obtains information that a Disaster Condition applies to the UE's HPLMN, the UE can register with a PLMN offering Disaster Roaming service.

The 3GPP system shall support means for a PLMN operator to be aware of the area where Disaster Condition applies.

The 3GPP system shall be able to support provision of service to Disaster Inbound Roamer only within the specific region where Disaster Condition applies.

The 3GPP system shall be able to provide efficient means for a network to inform Disaster Inbound roamers that a Disaster Condition is no longer applicable.

Subject to regulatory requirements or operator's policy, the 3GPP system shall support a PLMN operator to be made aware of the failure or recovery of other PLMN(s) in the same country when the Disaster Condition is applies, or when the Disaster Condition is not applicable 6.31.2.3 Disaster Roaming The 3GPP system shall be able to provide means to enable a UE to access PLMNs in a forbidden PLMN list if a Disaster condition applies and no other PLMN is available except for PLMNs in the forbidden PLMN list.

The 3GPP system shall provide means to enable that a Disaster Condition applies to UEs of a specific PLMN.

The 3GPP system shall be able to provide a resource efficient means for a PLMN to indicate to potential Disaster Inbound Roamers whether they can access the PLMN or not.

Disaster Inbound Roamers shall perform network reselection when a Disaster Condition has ended.

The 3GPP system shall minimize congestion caused by Disaster Roaming.

3GPP system shall be able to collect charging information for a Disaster Inbound Roamer with information about the applied disaster condition." TR 24.811 is a further part of the specification that is used to perform a study based on the above requirements. This captures key issues for which solutions will be developed and chosen for normative work when the study concludes.

It is assumed that a disaster condition (DC) can occur on the Radio Access Network (RAN) level for which e.g. the radio towers will be non-functional and hence the UE cannot connect to the PLMN in the area where the DC occurred. For example, consider Figure 1 which shows examples of RAN nodes 1, 2, 3 that connect to the Access & Mobility Management Function (AMF) 20.

Normally, every cell (or RAN node, which may support multiple cells) broadcasts the Tracking Area Identity (TAD, or actually a Tracking Area Code (TAC) in addition to the PLMN identity together which form the TAI of the cell. The UE identifies the PLMN ID (or TAI) of a cell based on this information that is broadcast.

Note that PLMN ID = Mobile Country Code (MCC) + Mobile Network Code (MNC); and TAI = PLMN ID + Tracking Area Code (TAC) = MCC + MNC + TAC.

A UE that registers to the Fifth Generation System (5GS) will be provided with a registration area (RA) which consists of a set of TAls (i.e. one or more TAI) in which the UE is allowed to enter without performing a registration procedure except for periodic updating or other reasons. For example, if the UE registers and receives an RA that is composed of TAI#1 and TAI #2, then the UE can move from TAI #1 to TAI #2 in idle mode without sending a Registration Request. On the other hand, if the UE enters a new area that is not part of the UE's RA e.g. TAI #3, then the UE is required to perform a registration procedure in order to get services during which the network will provide a new RA assuming the UE is indeed allowed to use the service in TAI #3.

When a DC occurs, the RAN nodes may be down and, as such, the UE may not receive any broadcast information and, as such, may not be able to receive any system information that would otherwise enable the UE to determine the PLMN ID or the TAI of the cell. In fact, the UE would not detect a cell when this occurs.

Note that this assumes that the DC impacts the RAN such that no information can be sent by the RAN and, as such, the UE cannot detect the presence of the cell as per normal methods.

As indicated earlier, a DC may be limited to a certain place and time. It is possible that the DC impacts one or more TAls such as: The area covered by TAI #1 only, or TAI #2 only, or TAI #3 only; or the area covered by one or more TAls e.g. TAI #1 and TAI #2 only, or TAI #2 and TAI #3 only, or TAI #1 and TAI #2 and TAI #3. Note that the above is just an example to explain the location where a DC may occur.

Additionally, a TAI, or a set of TAI, may also correspond to a particular geographic area that can be e.g. a set of geographical coordinates, where this set may for example define a particular shape such as a triangle, rectangle, or any other polygon, etc. For example, the DC may span all the TAls 1, 2, 3 shown in Figure 2 such that the DC may be composed of a set of 4 coordinate points (P1, P2, P3, P4) that define a rectangular shape that covers the cells that broadcast TAI #1 to TAI #3.

When a DC occurs, and the UE is aware of it, the UE will attempt to register on another PLMN, where this PLMN may be a visited PLMN (VPLMN) i.e. the PLMN may not be the UE's home PLMN (HPLMN). In fact, the UE may be allowed to use a PLMN in a list of forbidden PLMNs that the UE maintains.

When the UE registers on another PLMN where there is no DC, the UE can receive services from that PLMN, e.g. a target VPLMN, until the DC in its source PLMN (e.g. HPLMN or a previous source VPLMN) ends. The UE can then return to the previous PLMN.

As the number of UEs that go to a target PLMN due to a DC, or return to source PLMN after a DC ends, the requirements listed earlier require that this be done in a way that avoids congestion on a (target or source) PLMN that may result from a very large number of UEs attempting registration at the same time.

Embodiments of the present invention aim to address the problem as set out above.

According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

According to a first aspect of the present invention, there is provided a method of controlling access to a network supporting disaster roaming, of a User Equipment, UE, when disaster roaming on the network supporting disaster roaming, wherein: the UE sends a NAS message to the network supporting disaster roaming; the network verifies at least one condition in response; and based on the at least one condition, the network supporting disaster roaming accepts the NAS message and indicates that the UE is registered for emergency services.

In an embodiment, the at least one condition comprises the UE moving outside its previous Registration Area, RA, or moving into a new Tracking Area, TA, or sending a NAS message from a cell or TA that is outside the UE's current RA.

In an embodiment, the at least one condition comprises that the UE is registered for a disaster roaming service.

In an embodiment, the at least one condition is that the UE has a PDU session for emergency services.

In an embodiment, the at least one condition may be verified in any order or combination.

In an embodiment, the at least one condition comprises a plurality of conditions and if all of the plurality of conditions are met, then the network, considers the UE to be registered for emergency services.

In an embodiment, there is further provided the step that the network indicates to the UE, in a NAS message, that the UE is registered for emergency services.

In an embodiment, the NAS message is a Registration Accept message or a Configuration Update Command message.

In an embodiment, if the at least one condition is not met, then the network rejects the UE's NAS message.

In an embodiment, the NAS message is a Registration Reject message.

According to a first aspect of the present invention, there is provided apparatus arranged to perform the method of the first aspect.

Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows an example deployment of RAN and non-3GPP Access Points with Connection to an AMF within a PLMN, known in the prior art; Figure 2 shows a DC area, covering a rectangular geographic area, known in the prior art; Figure 3 shows a DC Area that overlaps with a coverage area of another PLMN not affected by the DC; and Figure 4 shows a message flow according to an embodiment of the invention.

There is a requirement that the 3GPP system shall be able to support provision of service to Disaster Inbound Roamer only within the specific region where Disaster Condition applies. The following embodiment seeks to satisfy the above requirement.

Reference is made to Figure 3, which assumes that the cells and TAls belong to a given PLMN, (PLMN X). PLMN X includes TAI #1(101), TAI #2(102) and TAI #3 (103).

Assuming that PLMN X experiences a disaster condition (DC) that impacts the RAN node which broadcasts TAI #2 (102), the UE may attempt to register onto PLMN Y where the coverage of PLMN Y overlaps with that of PLMN X. However, PLMN Y needs to ensure that the UE will only use services from PLMN Y within the area of the DC in PLMN X. In this case, for example, since the DC affects TAI #2(102) of PLMN X, then the UE should only be allowed to use services in the overlapping area which is TAI #63 (202) of PLMN Y. Figure 3 shows AMF 120 of PLMN X and AMF 220 of PLMN Y. In the prior art, there is no known solution which allows this to happen. The following embodiment addresses this issue.

A further requirement is that Disaster Inbound Roamers shall perform network reselection when a Disaster Condition has ended. This relates to reselection when a DC ends. However, it is possible that the UE can return to its PLMN when it leaves the area of the DC. The following embodiment relates to this issue.

A still further requirement is that the 3GPP system shall minimize congestion caused by Disaster Roaming. There are no known solutions that have been adopted to satisfy the above requirement in general, and there may be specific cases that need to be resolved.

For example, many UEs try to access the 5G Core (5GC) of the target PLMN, which is not experiencing DC. This may overload the 5GC of the target PLMN and methods are needed to reduce such a load.

For example, several UEs may register to the same target PLMN. After registration, each of these UEs may request the establishment of PDU sessions towards the same slice and/or Data Network Name (DNN) which may overload the same Session Management Function (SMF) nodes. Furthermore, the AMF will be overloaded since each 5GSM message is transported to the SMF via the AMF. Therefore, both the AMF and SMF nodes may be overloaded due to the sudden surge in Session Management (5GSM) requests. This may well overload the system and impact both existing and new UEs that use the target PLMN PLMN with no DC).

A first embodiment of the present invention uses service area restrictions to constrain the services of a UE within the area of the DC.

A DC may occur in PLMN X and the DC may span a certain area. The UE 110 may select and attempt to register on another PLMN, say PLMN Y. However, it is required that PLMN Y only gives service to the UE 110 in an area where the DC is known to occur.

To meet the requirement, as previously stated, an embodiment assumes that the target PLMN (PLMN Y), where PLMN Y is a PLMN that does not have a DC and which receives a UE, knows the area of the disaster condition. This may be achieved by operators of both PLMNs exchanging information with each other and identifying the area of the DC.

For this solution to work, the target PLMN, i.e. any node or network function (NF) of the target PLMN (Y) should use the received information about the area of the DC and map it to a coverage area in the target PLMN i.e. PLMN Yin our example.

For example, the DC in another PLMN is mapped to any combination of the following: a geographical area that is composed of a set of coordinates; a registration area (PA), where the RA consists of a list of TAls, noting that the RA may be larger than the area of the DC; and a set of TAls, where this set may or may not be within one specific RA, such that the set of TAls would map, as closely as possible, to the area of the DC When a UE, due to a DC in a previous PLMN (e.g. PLMN X), registers on another PLMN (PLMN Y) that does not have a DC, in order to receive normal service, the UE may indicate that it is registering to PLMN Y due to a DC. This may be done by introducing a new indication or a new bit in a new Information Element (1E) or an existing IE. For example, the existing 5GS update type IE can be used for this purpose, where one of the existing bits can be defined to indicate "registration due to a disaster condition", or "registration due to temporary service unavailability in source PLMN", or similar.

Similarly, for such a UE, based on the proposed new indication as explained above, the AMF 220 in the new PLMN should indicate to the UE 110 that the registration for a DC has been accepted. The AMF 220 may do so by using a new bit in a new IE or an existing IE. For example, a new bit in the 5GS registration result IE (or 5GS network feature support 1E) can be used to inform the UE 110 that the current registration is accepted as a result of a DC in the UE's source PLMN. For example, the bit may be used to indicate "registration due to a disaster condition".

B

Note that the IE may be newly-defined IE or an existing IE. The values used for the bit positions are examples and can be defined to indicate something different but still with the common objective to indicate that a registration is being done due to a DC, and the registration is accepted following a DC, respectively by a UE and the network (e.g. AMF).

Note that the UE may determine that its registration is accepted due to a DC based on either receiving a new value or new bit or new indication in a Registration Accept message as described above e.g. a new bit in the 5G3 registration result 1E, or if the UE indicates that it is registering due to a DC in another PLMN (as set out above) and the UE's registration is accepted then the UE can determine that it is registered in the current PLMN as a result of a DC in its source PLMN. The UE may locally store this information.

When the UE registers to a target PLMN following a DC in a source PLMN, the following features are provided to ensure that the UE's service is restricted, such that it is only serviced within the area of the DC.

The AMF may provide an RA to the UE (i.e. the list of TAls) such that the TAls are restricted to cover the area of DC that the AMF has determined as explained above.

The AMF may provide the Service area list IE such that the AMF sets the TAls as follows: * The AMF ensures that the service area would allow the UE to access normal service in an area that overlaps with the area of DC that was determined * The AMF provide a service area list which is an allowed service area that comprises a set of TAls such that the set of TAls that are provided would map and be restricted to, as much as possible, the area of the DC that has been determined * The AMF provides a service area list which is a non-allowed area service are where the provided TAI list are those TAls that are not allowed such that they exclude the area of the DC that has been determined Note that in all of the options above, the objective is that the service area list that is provided to the UE should be such that the result is that the UE will only be allowed to obtain services in an area (e.g. a set of TAls) that is restricted (as much as possible) to the area of DC that has been determined.

Note that the AMF may also send a set of global cell IDs to offer finer control of the areas to which the service should be confined. The global cell IDs may be sent such that they may correspond to the TAls of the service area list IE. The list of global cell IDs may be sent as a new IE or as part of an existing IE. As such, the AMF determines the DC area, determines the cells that are within this area, and sends the global cell ID of each cell that has been determined to overlap or be within the area of the DC.

Note that the information sent to the UE e.g. list of TAls, service area list with specific TAls, or a new set of global cell ID, may be used in any combination and sent to the UE in any combination.

Note also that the serving PLMN may use any NAS message to update the UE with any of the above information if a change has occurred e.g. if the network (e.g. serving AMF) determines that the DC area has changed based on any new development with the DC.

When the UE receives a set of global cell ID as set out above, the UE may store this list in a new list of e.g. "allowed cell list for DC" (where the name of the list may be different), and use these cell IDs to determine if it is within the DC area as follows.

The UE verifies if the global cell ID of the cell onto which it is camped is present within the list of global cell IDs that the UE has received and may have optionally stored. If yes, the UE can access the cell to get service. If no, the UE may, even if the TAI of the cell is in the UE's registration area, determine that service cannot be received via this cell. The UE may remain in the registered state, or enter a new substate to indicate that service cannot be received. The UE may respond to paging or Notification message, or may perform registration procedure but optionally without including the Uplink data status IE.

Figure 4 illustrates a message flow in connection with the foregoing. This shows messages 25 exchanged between UE 110 and AMF 220 of PLMN Y. Note that the steps set out above can be used in any combination and the IEs that are listed should be considered as examples, whereas other existing IEs or new IEs can be used by the UE or the network, as required.

It is possible that the UE, while registered on a target PLMN that does not have a DC -say PLMN Y in this example, may move or enter a new cell that broadcasts a new TAI that is currently not in the UE's 5GS tracking area list IE i.e. the UE enters a new TAI that is currently not in the UE's registration area. When this occurs, the UE usually sends a Registration Request message to register with the network.

When the network receives a Registration Request from the UE, the network (e.g. AMF 220) should determine if the UE's location (e.g. based on the global cell identify of the RAN node, which is known to the AMF from the message on the N2 interface i.e. between the RAN and the AMF) and verify if the UE 110 is within the DC area or not. If not, the AMF 220 should reject the UE's registration and send a Registration Reject message. The AMF 220 may use a new 5GMM cause code "Roaming outside areas of network disaster not allowed", or any of the existing 5GMM cause codes such as #12 "Tracking area not allowed", or #13 "Roaming not allowed in this tracking area", or #15 "No suitable cells in tracking area".

However, it is possible that the UE establishes (or already has) a PDU session for emergency services while it is registered for disaster roaming. The UE may then move into a new TA (tracking area) identified by a new TAI (Tracking Area Identity) that is not part of the UE's current registration area (RA). In this case, the UE normally performs a registration procedure i.e. the UE sends a Registration Request message, as it has entered a new TAI. In this case, the following sets out two options for UE behaviour and AMF behaviour In the first option, the UE behaves as follows. In the case that the UE is registered for disaster roaming, if the UE moves into a new TA that is not part of the UE's current RA, then if, additionally, the UE has a PDU session for emergency services that is already established, the UE should send the Registration Request message and may set the 5GS registration type IE to "emergency registration". If the UE does not have a PDU session for emergency services, then the UE should set the 5GS registration type IE to "disaster roaming registration" or may set the 5GS registration type IE to "mobility registration updating". Note that a UE that has already registered for disaster roaming should preferably always set the 5GS registration type IE to "disaster roaming registration" except when the procedure is being performed for periodic update and except for the case that is described above (i.e. the UE moves into a new TA that is not part of the UE's current RA and the UE has a PDU session for emergency services). Similarly, the AMF should always indicate (implicitly or otherwise) that the UE is registered for disaster roaming unless this is not the case and as such the AMF should then indicate otherwise.

The UE may also locally release all other PDU sessions that are not related to the emergency service or that are non-emergency PDU sessions. The UE should consequently include the PDU session status IE in the Registration Request to indicate the PDU sessions that have become inactive in the UE and/or the PDU session that remains active in the UE, where the latter should be associated with the PDU session for emergency service. This IE should be set as above i.e. all non-emergency PDU sessions should be indicated as inactive except the PDU session for emergency service.

Note that the UE may perform any combination of the actions above.

The following describes the proposed AMF behaviour. When the AMF receives a Registration Request from a UE that is registered for disaster roaming and the 5GS registration type indicates "emergency registration", then if a Registration Request message is received (from a UE) and the TA of cell/NG-RAN node, from which the NAS message is received, is not part of the UE's current RA and the UE is currently registered for disaster roaming service, and if the UE does not have a PDU session for emergency services, then the AMF should reject the UE's NAS message i.e. the AMF should send a Registration Reject and include an appropriate new or existing 5GMM cause value e.g. #11, #13, #15, etc, as mentioned above.

If a Registration Request message is received (from a UE) and the TA of the cell/NC-RAN node (from which the NAS message is received) is not part of the UE's current RA and the UE is currently registered for disaster roaming service, and if the UE has a PDU session for emergency services (i.e. a PDU session for emergency service is established for the UE), then the AMF should take any combination of the following actions.

The AMF may verify if the TA of the cell/NG-RAN node (from which the NAS message is received) corresponds to an area that overlaps with the area of the disaster condition (where this area of the disaster condition is the area impacted by the disaster condition for another PLMN, where the AMF may know this, based on local information in the AMF). If the TA of the cell/NC-RAN node (from which the NAS message is received) does overlap, then the AMF continues to consider the UE as registered for disaster roaming service. However, if the TA of the cell/NG-RAN node (from which the NAS message is received) does not overlap with the area of the disaster condition, then the AMF behaves as described in the following. Note that the order of the conditions verified does not matter and may be done in any order. For example, the AMF may first verify whether the UE's current location (or TA of the cell/NC-RAN node from which the NAS message is received) overlaps with the area of disaster condition. If not, then the AMF may subsequently verify if the UE has a PDU session for emergency services. If not, then the AMF rejects the NAS message, otherwise i.e. if the UE has a PDU session for emergency, then the AMF does not reject the NAS message but rather accepts it and considers the UE to be registered for emergency services as proposed/explained in the following.

The AMF should accept the UE's request and send a Registration Accept message.

Optionally the AMF should indicate that the UE is registered for emergency services by setting the 'Emergency registered' bit to 1 (i.e. to indicate Registered for emergency services) in the 5GS registration result IE (of the Registration Accept message).

Optionally, the AMF may send the Configuration Update Command (CUC) message and include the 5GS registration result IE and indicate that the UE is registered for emergency services, where the CUC message can be sent during the registration procedure or after the registration procedure.

Optionally, the AMF should request each SMF to release any PDU session that is not related to the emergency PDU session or that is not the PDU session for emergency services or that is a non-emergency PDU session. The AMF may also perform a local release of such PDU sessions.

Optionally, the AMF may include the PDU session status IE in the Registration Accept message to indicate which PDU session are now inactive (i.e. the non-emergency PDU sessions) and/or to indicate which PDU session is active (i.e. the emergency PDU session). This IE should be set as set out above i.e. all non-emergency PDU sessions should be indicated as inactive except the PDU session for emergency service.

In summary, the AMF may need to verify at least one condition to consider the UE as registered for emergency services (and/or to indicate to the UE that it is registered for emergency services). The AMF verifies these conditions in any order: * condition 1: the UE sends a NAS message from an area (e.g. cell/TA, etc, that does not overlap with the area of the disaster condition; * condition 2: the UE has an ongoing PDU session for emergency services. and * condition 3: the UE is currently registered for disaster roaming service.

For any number of conditions, when all the conditions are met (i.e. one or more from the above), then the AMF determines/considers the UE to be registered for emergency services. Note that the AMF may verify the conditions listed above in any order, noting that other conditions may also be defined.

Note that the steps described herein apply for any NAS message and not just a Registration Request message, and so other NAS messages, such as Service Request message, would be treated in a similar manner.

In the second option, the UE behaviour is exactly the same as that proposed for the first option with the exception that the UE need not set the 5GS registration type IE to "emergency registration". The UE may set the IE to "disaster roaming registration" or may set the 5GS registration type IE to "mobility registration updating". With this exception, all the detail set out for the UE behaviour in the first option, above, also applies for this second option.

For this second option, the AMF behaves in the same manner as described above for the first option, even if the 5GS registration type does not indicate "emergency registration" (e.g. the 5GS registration type may indicate "disaster roaming registration" or "mobility registration updating"). As such, all the details set out above for the AMF behaviour in the first option, above, also apply for this option/ When a UE attempts to use a target PLMN due to a DC on a source PLMN, the UE may have saved any of the following lists corresponding to a PLMN: * "5GS forbidden tracking areas for roaming" * "5GS forbidden tracking areas for regional provision of service" * "permanently forbidden Stand-alone Non-Public Network (SNPNs)" * "temporarily forbidden Stand-alone Non-Public Network (SNPNs)" When the UE tries to access a cell or PLMN due to a DC, if a cell's TAI is in any of the lists listed above e.g. in a "5GS forbidden tracking areas for roaming", or the Stand-alone Non-Public Network (SNPN) ID or SNPN, or PLMN of the SNPN is in any of the lists above e.g. "temporarily forbidden SNPNs", then the UE may autonomously remove the TAI or the SNPN from the corresponding forbidden list so as to enable the UE to access the cell. The UE may create a new list e.g. "temporarily allowed 5GS tracking areas for roaming" or "temporarily allowed SNPN for roaming" and save the corresponding entry (e.g. TAI or SNPN) in this list. This then removes any local restriction in the UE and the UE can then access the cell or SNPN or the TAI.

When the UE deregisters from the PLMN, or goes back and (optionally successfully) registers on the source PLMN, the UE may reinstate the entry e.g. TAI or SNPN, into its original list and delete the created temporary list. For example, if the list of "temporarily allowed 5GS tracking areas for roaming" is not empty, the UE saves its entries into the list of "5GS forbidden tracking areas for roaming" and deletes the temporary list. The same can be done with the other types of information e.g. SNPN and other list e.g. "temporarily allowed SNPN for roaming".

A further aspect of embodiments of the invention enables a quick UE return to the previous (source) PLMN. The UE may retum to the previous PLMN when the UE, based on any method, determines that it has moved out of the area of a DC. This may be based on an explicit indication from the network.

For example, the UE may be handed over to a cell that is outside, which does not align or overlap with, the area of the DC. As such, the serving AMF may send an explicit indication to the UE, indicating that the UE is now out of the area of the DC. This may be done by the AMF monitoring the UE's location per cell, e.g. based on the global cell identity of the serving cell for a UE in connected mode, such that the AMF should compare the UE's location with the area of the DC. If the AMF determines that the UE is now outside of the DC, the AMF may send an explicit indication to inform the UE about this. This explicit indication may be done using any NAS message e.g. Configuration Update Command message which may include this new indication, Registration Accept message which may include this indication, or a Registration Reject or Service Reject message, or Deregistration Request message, which may include this new indication.

Upon reception of this indication, the UE may start a timer, T3540, to guard the release of the NAS signalling connection. The UE may release the NAS connection when T3540 expires and the UE should then scan for a higher priority PLMN, that optionally being the previous PLMN that had a DC e.g. PLMN X. As such, this enables a quick return to the previous PLMN.

However, other steps to enable a quick return to a previous PLMN or a higher priority PLMN are set out as follows.

Upon reception of any NAS reject message (e.g. Registration Reject, Service Reject, etc) by a UE that is using a PLMN following a DC, the UE may consider this as a trigger to perform PLMN search of a higher priority PLMN. The UE may use this a means to determine that the UE has moved outside of the DC area and, as such, should be capable of finding the source PLMN that had experienced a DC e.g. PLMN X. The UE should attempt to scan and search for the source PLMN on which a DC occurred e.g. PLMN X. This scan should occur even if other triggers for higher priority PLMN search did not yet occur.

Alternatively, the UE can autonomously start the higher priority PLMN scan when it moves out of the allowed area, or when it moves into a non-allowed area. This can be determined by the UE verifying the TAI of the cell on which it is camping, versus the TAI(s) in the service area list.

1Nhen the UE determines that it is not in the allowed area (or inside a non-allowed area), the UE may conclude that it has left the area of the DC and as such should start its scan for a higher priority PLMN and attempt to register on the previous PLMN (on which a DC occurred).

Alternatively, the UE may verify if it is within the DC by monitoring and comparing the global cell ID of a cell onto which it is camped against a list of global cell IDs that the UE may have received from the network as set out herein. The UE may have a list of global cell ID that indicates which cells the UE is allowed to access in this PLMN. If the UE moves to a new cell for which the global cell ID is not part of the stored or received list, the UE may determine that it has come out of the DC area. Based on this, the UE may determine to perform higher priority PLMN scan and attempt to register on the previous PLMN.

Note that the UE may use a subset or all of the information that it may have received. For example, to determine if the UE is within the area of the DC, the UE may use the service area list only, or both the service area list and the list of global cell IDs, or the list of global cell IDs only.

Alternatively, the UE may autonomously determine if it has moved out of a DC area by monitoring the broadcast information of a cell. If the cell's broadcast information does not indicate that it accepts inbound roaming UEs due to a DC, or no longer or does not broadcast any other indication about access to the PLMN due to a DC, the UE may determine that it has left the DC area and should then perform PLMN scan to search for higher priority PLMN and attempt to register on the previous or higher priority PLMN.

When the UE returns to the previous PLMN and successfully registers to it, the UE should clear any local indication or flag that the UE may have saved which indicates that a DC has occurred. The UE may restore any previous restrictions regarding the PLMN on which the UE was using during the DC. For example, the UE may restore any TAI in a list of "5GS forbidden tracking areas for roaming" optionally if the UE had removed any TAI from that list when the UE attempted to register on the target PLMN optionally as a result of a DC on a source PLMN.

Note that the DC may also impact non-3GPP access. As such, the UE may determine, via an explicit or implicit method that the non-3GPP access is unavailable due to a DC.

The explicit method may be via an indication that the UE receives in a NAS message or an RRC message (e.g. via the SIBs or MlBs of the broadcast system information of a cell).

The non-3GPP access does not support the concept of TAI and, in fact, for the non-3GPP access, the PLMN indicates one TAI for the entire PLMN. As such, the UE can never know, based on TAI, if it has changed its location while it connects to the non-3GPP access. If the non-3GPP access is unavailable, e.g. due to a DC, the UE's lower layers (i.e. non-3GPP access) may continuously scan for the availability of non-3GPP access. To avoid this, and consequently to avoid excess power consumption in the UE, when the UE determines, based on explicit or implicit indications, that a DC has impacted an access technology, the UE may, e.g. based on the access technology type, disable the access technology to avoid unnecessary power consumption caused by scanning. For example, the UE may disable the non-3GPP access if the UE determines (as described above) that the non-3GPP access is not available.

Note that the AMF from the serving PLMN, may inform the UE whether it should disable an impacted access or not. For example, the AMF may be aware of a DC on an access type (e.g. 3GPP access) and may also be aware that there is no other alternative PLMN in the DC area.

As such, the AMF should inform the UE that a DC has occurred and that there is no other PLMN to serve the UE on that access. The UE may then disable the affected access technology.

Regarding the unavailability of non-3GPP access, it is possible that the UE is registered to a PLMN, e.g. PLMN X, over both the 3GPP and non-3GPP accesses. Then a DC may occur that cause the non-3GPP access to be unavailable. The UE cannot know the exact area of the disaster condition if it is not informed about it by the network. Once the UE knows about the DC, e.g. via an explicit indication from the network, the UE may disable the non-3GPP access (e.g. turn it OFF) in order to not waste power. The UE may then enable the non-3GPP access (e.g. turn it ON) when any of the following occurs, in any combination: the UE enters into a new cell on the 3GPP access, even if the cell belongs to a TAI that is part of the UE's registration area; or the UE enters into a new cell whose TAI is not in the UE's list of the UE's registration area When any of the above occurs, the UE may power on the non-3GPP access and attempt to connect to the 5GC. This is because a 3GPP cell or TA is much larger than the coverage area of non-3GPP access points and the fact that the UE has moved into a new cell or a new TAI would most likely mean that the UE has also moved out of the area of the DC that impacted the non-3GPP access.

Embodiments of the invention also provide a means to reduce congestion that may result from numerous 5GSM requests in a PLMN without a DC.

Several UEs may register at about the same time in a PLMN without a DC after the UE's 30 source PLMN experienced a DC.

In addition to handling mobility management (5GMM) messages, the AMF may experience large amount of signalling resulting from numerous simultaneous requests for PDU sessions from numerous UEs at around the same time. In fact, each UE may request more than one PDU session and since the DC happens in one given area, all the UE are expected to be in the same area in the target PLMN and will therefore be served by the same AMF, and possibly SMF if the slices requested and/or DNN are the same.

As all 5GSM messages (e.g. PDU Session Establishment Request message) are transported within 5GMM messages, the serving AMF will experience a surge of signalling as a consequence of potentially multiple 5GSM requests that are initiated by one UE, let alone numerous UEs. Embodiments provide a solution to prevent such an overload.

One solution to prevent an overload, and to control the amount of generated signalling that an AMF will experience, is that the AMF should indicate a restriction on the number of PDU session that each UE can request, optionally with a set of timers, were the AMF may indicate a time before which the UE can make its first request following a successful registration and/or indicate a time that the UE needs to wait before a subsequent 5GSM request can be made by a UE following a previous 5GSM request.

The AMF may also remove the restriction at a later time when the load is determined to be under control. All these indications may be sent by the AMF using any NAS message.

For example, when the UE registers with the network, the AMF may indicate the following to the UE in the Registration Accept message: a maximum number of PDU sessions or slices that can be requested by the UE; optionally a time to wait before the first request can be made e.g. for example w.r.t PDU session or Slice; optionally a time to wait in between subsequent 5GSM requests for example w.r.t PDU session or Slice; optionally an allowed NSSAI with a limited number of S-NSSAls (e.g. one S-NSSAI), where the number may be determined based on AMF policy or subscription. Note that this may still be done even if the UE is allowed to use more than one S-NSSAI in this serving PLMN.

The AMF may allow a different number of PDU sessions for each UE, based on local policy or based on subscription information.

Wien the load condition is determined to be under control, and the AMF determines that more 5GSM requests can be accommodated e.g. based on local policy or load conditions at the 30 AMF and/or SMF, the AMF may send any NAS message (new or existing) to remove the restriction on the number of PDU sessions that can be requested by the UE.

For example, the AMF may send a Configuration Update Command message to remove the restriction on the number of PDU sessions that are allowed for a UE or modify the number.

This may also be done in a Registration Accept message or any other NAS message.

The numbers and timers referred to above may be defined using new IEs, where the bits or fields of these IEs may be defined to provide specific indications such as an integer number of PDU sessions that may be permitted for a UE, whether or not the restriction is completely removed (i.e. no restrictions are in place), IEs for the timers as proposed above, etc. Note that the restriction on the number of PDU session is not necessarily the same as the maximum number of PDU session that the PLMN can support per UE. For example, this maximum may be 4 but as the UEs register with the PLMN, the AMF may initially allow only one PDU session per UE. This restriction can later be lifted such that the UE may be allowed to request more PDU sessions. This solution enables the AMF to avoid congestion instead of haying to apply congestion control when congestion is detected, which may also lead to cases in which one UE may get more PDU sessions that another UE which registers at as slightly later time but got backed-off due to the surge in signalling.

The UE may receive, in any NAS message (new or existing), a restriction on the number of PDU sessions that can be requested in a network. In this case, the UE should save a local indication about the restriction and also save the maximum current number of PDU session that is permitted by the network, optionally for a given time.

The UE should, upon request to send a new request for establishing a new PDU session, verify if there are any restrictions on 5GSM requests (such as, but not limited to, PDU Session Establishment Request). If yes, the UE verifies if the number of currently established PDU sessions has reached the maximum number that is permitted by the network. If yes, the UE should block the request i.e. not send the 5GSM request, and indicate to the 5GSM entity (or upper layers) that the request cannot be sent due to a limit or restriction.

The UE may receive a time value that indicates when a first, or subsequent, 5GSM request can be sent by the UE. If so, the UE should start a timer that guards a period during which no 5GSM request can be sent, except for emergency services or high priority access. If the UE is permitted to send a request but a wait period is required (e.g. based on a running timer), then the UE should not send the 5GSM request. The UE may indicate to the 5GSM entity (or upper layers) that the request cannot be sent due to a "back-off period. The UE may indicate a time period that the 5GSM entity (or upper layers) need to wait for requesting the transmission of the 5GSM message again. This may be done by providing the remaining timer (that the UE had received, if any, and had started) to the 5GSM entity (or upper layers). Upon expiry of the timer, the UE may send a 5GSM request if received from the 5GSM entity (or upper layers), assuming other restrictions are not in place.

If the UE receives a modified restriction e.g. no more restriction on the number of PDU sessions that can be requested, or the number permitted has now increased, the UE may inform the 5GSM entity (or upper layers) about this so that new requests can be submitted, if any.

In yet another embodiment, to avoid congestion on the PLMN-A (the active PLMN which provides support during disaster situation of the PLMN-D), the PLMN-D (the PLMN experiencing the disaster situation) or HPLMN can indicate to the PLMN-A the PDU sessions (for example in the form of DNN's) or slice(s) to be prioritized during the congestion situation.

Based on this information the PLMN-A can indicate the PDU session(s) or Slice(s) allowed to the UE, based on the congestion situation or anticipated congestion situation of PLMN-A. The UE thus uses this information as described in this embodiment w.r.t time etc. If the UE makes a request for non-allowed PDU session(s) or slices, then the network provides a respective Back-off timer.

In yet another embodiment, the UE can be pre-configured with priority of PDU session(s) or slices to be used during the congestion or anticipated congestion situation, for example, in the UE Route Selection Policy (URSP) rules of the UE, or based on any other user interaction or indication from the network, etc. Note that the indications from the network may come to the UE in a NAS message but the origins of the indications may be from other network nodes such as the Policy and Charging Control (PCC) node and as such the indications may be received in a UE policy container, or a Steering of Roaming (SOR) transparent container, or UE parameters update transparent container. The indication may be sent in any new IE or existing IE or container (new or existing), or in any new or existing NAS message.

Note that the steps above can be used by the network to control or avoid congestion at any time and are not to be restricted to any particular feature such as MINT (minimization of service interruption). As such, the step described herein can be used at any time. In this case, the UE and the network may negotiate capabilities to indicate that at least the UE can support applying such restrictions from the network. Therefore, the network may provide such restrictions, or modify or remove them for UEs that indicate support of such restrictions. The network may apply the proposals above for UEs that indicate the support of the MINT feature or for UEs that are known to register on a network following a disaster condition in a source PLMN.

At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component', 'module' or 'unit' used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims (11)

1. CLAIMS1. A method of controlling access to a network supporting disaster roaming, of a User Equipment, UE, when disaster roaming on the network supporting disaster roaming, wherein: the UE sends a NAS message to the network supporting disaster roaming; the network verifies at least one condition in response; and based on the at least one condition, the network supporting disaster roaming accepts the NAS message and indicates that the UE is registered for emergency services.
2. 2. The method of claim 1 where the at least one condition comprises the UE moving outside its previous Registration Area, RA, or moving into a new Tracking Area, TA, or sending a NAS message from a cell or TA that is outside the UE's current RA.
3. 3. The method of claim 1 or 2 where the at least one condition comprises that the UE is registered for a disaster roaming service.
4. 4. The method of claim 1, 2 or 3 where the at least one condition is that the UE has a PDU session for emergency services.
5. 5. The method of any preceding claim where the at least one condition may be verified in any order or combination.
6. 6. The method of any preceding claim wherein the at least one condition comprises a plurality of conditions and if all of the plurality of conditions are met, then the network, considers the UE to be registered for emergency services.
7. 7. The method of claim 6 further comprising the step that the network indicates to the UE, in a NAS message, that the UE is registered for emergency services.
8. 8. The method of claim 7 wherein the NAS message is a Registration Accept message or a Configuration Update Command message.
9. 9. The method of claim 1, wherein if the at least one condition is not met, then the network rejects the UE's NAS message. 35
10. 10. The method of claim 9 where the NAS message is a Registration Reject message.
11. 11. Apparatus arranged to perform the method of any preceding claim.