Improvements in and relating to management of a disaster condition in a telecommunication network

Abstract

A method of managing a User Equipment (UE) such that, during a disaster condition, it is only provided with service in an area which overlaps with the area of a DC in the Fifth Generation System (5GS)

Description

In a Disaster Condition, DC, where some or all of a network is adversely affected by a disaster, User Equipments, UEs, from the DC-affected network may, in a controlled manner and with some conditions applied, register temporarily with another network. Controls are required to prevent the other network from being overwhelmed. Embodiments of the present invention relate to confining a UE to an area and / or Core Network Type in the event of a Disaster Condition. 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 Mobile Land Network, PLMN, and for which the UEs are to be redirected to another PLMN in a manner that keeps the service interruption to a minimum. The description of this can be found in TS 22.261: “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 TS 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 the specification that is used to perform the study based on these requirements. TR 24.811 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 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 10, 20, 30 that connect to the Access and Mobility Management Function 40, AMF, of the PLMN. Normally, every cell (or RAN node, which may support multiple cells) broadcasts the Tracking Area Identity (TAI), or actually a Tracking Area Code (TAC) in addition to the PLMN identity which, together, 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 5GS will be provided with a registration area, RA, which consists of a set of TAIs (i.e. one or more TAI) into which the UE is allowed to enter without performing a registration procedure, except for periodic updating or other reasons. For example, if a UE registers and receives an RA that is composed of TAI#1 and TAI #2 (associated with RAN 10 and RAN 20), 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 (associated with RAN 30), 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, one or more of 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. 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 ore more TAIs 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 TAIs 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 place where a DC may occur. Additionally, a TAI, or a set of TAIs, 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 TAIs 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 the 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. In the prior art, there is no reliable way to ensure that roaming UEs can only get service in a confined area, as a result of a DC. Reference was made earlier to the 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 requirement above can somehow be met in 5GS, i.e. if the UE remains in 5GS or N1 mode, by using service area lists that define a set of TAIs where service is allowed. Although not very granular, the use of a service area list can generally define a broad area within which the service area can be confined. However, the concept of service area list is not support in Evolved Packet System, EPS, or in S1 mode, so if the UE goes to EPS of the PLMN that is providing disaster roaming service, then the UE’s service area cannot be confined to a specific area (corresponding to the area of the disaster condition). To be able to confine the area of service in EPS there will be need for additional changes to the nodes in EPS e.g. changes will be required at least to the Mobility Management Entity, MME, and possibly the RAN. For example, looking at Figure 3, assume that the cells and TAIs #1, #2 and #3 belong to a given PLMN, say PLMN X . Now, assume PLMN X experiences a disaster condition that impacts the RAN node 120 which broadcasts TAI #2. In this case, the UE 100 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 100 will only use services from PLMN Y within the area of the DC in PLMN X. In this case, for example, since the DC only affects TAI #2, associated with RAN 120 and not RAN 110 and RAN 130 of PLMN X, then the UE 100 should only be allowed to use services in the overlapping area which is TAI #63 of PLMN Y. Note that the TAIs shown above are assumed to be TAIs of the 5GS of PLMN Y. However, PLMN Y may also have EPS (or LTE) coverage where other TAIs may also exist and potentially overlap with TAIs of the 5GS. These TAIs are not shown in the figure. To summarize, there is no solution known in the prior art that ensures that if a UE accesses the EPS of a target PLMN, which is not affected by a DC, then the UE can only uses services in an area which overlaps with the area of a DC in the 5GS system of an affected PLMN. It is an aim of embodiments of the present invention to address shortcomings in the prior art, whether identified herein or not. 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 managing a User Equipment, UE, such that it is only provided with service from a telecommunication network during a Disaster Condition, in a defined area, comprising the steps of: a) the UE not indicating support for S1 mode upon registration with the telecommunication network when the UE is registering for disaster roaming service; or b) the UE indicating its support for S1 mode and the network is operable to prevent a handover to the UE in S1 mode for a UE which is registered for disaster roaming service. In an embodiment, in case a), the UE sets the S1 mode bit, EPC NAS supported bit, to "S1 mode not supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. In an embodiment, the UE disables S1 mode. In an embodiment, the UE enables S1 mode if at least one of the following circumstances: • the UE needs to place an emergency service or call; • the UE needs to perform emergency services fallback; and • the UE needs to place an emergency call using circuit switched fallback. In an embodiment, after completing the emergency service or call, the UE attempts to return to a 5GS domain of the telecommunication network to resume disaster roaming. In an embodiment, the UE autonomously uses any RAT that supports the Circuit Switched domain, and performs network search or selection using that RAT so as to place an emergency call. In an embodiment, in case b), if the UE sends a Service Request message, then an AMF of the telecommunication network allow the request, due to it being for emergency services, and allows the UE to use EPS by either executing a handover or an idle mode reselection. In an embodiment, in order to avoid handover or idle mode reselection, the AMF: stores a local flag or indication that specifies that the UE should not be handed over to EPS or to S1 mode even if the UE supports S1 mode; or indicate to a Radio Access Network, RAN, of the telecommunication network that the UE is not permitted to use EPC; or if the UE is accessing the 5GC over NR, and the telecommunication network which is providing inbound disaster roaming service is only allowed to provide service to the UE via NR, then the AMF indicates to the RAN that E-UTRA(N) is a forbidden RAT for the UE. 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 a schematic of a network according to the prior art showing several RANs; Figure 2 shows a schematic of the network of Figure 1 and the definition of a DC in a defined area; Figure 3 a schematic of a DC area in a first that overlaps with a coverage area of a second network not affected by the DC; In a first embodiment, the UE does not indicate support of S1 mode when it registers with a target PLMN, which does not have a disaster condition. When the UE registers with a PLMN that does not have a disaster condition, optionally where the UE is registering to obtain disaster roaming services (e.g. optionally the UE is registering with a target PLMN due to a disaster condition on its source PLMN, or the UE is registering with a target PLMN after determining that the PLMN accepts and / or allows disaster inbound roamers), the UE should not indicate that it supports S1 mode, even if the UE actually supports S1 mode. As such, the UE should set the S1 mode bit (or the EPC NAS supported bit) to "S1 mode not supported" in the 5GMM capability IE of the REGISTRATION REQUEST message even if the UE does support S1 mode. Optionally, and / or additionally, the UE should disable its S1 mode. Optionally if the UE is accessing the target PLMN using NR access technology, the UE may optionally disable its E-UTRA capability. The disabling of S1 mode, or optionally the disabling of E-UTRA mode (e.g. when the UE is accessing 5GC of the target PLMN using NR access), ensures that the UE remains in 5GS of the target PLMN, so that the target PLMN may use methods such as, but not limited to, service area list or other methods to confine the UE’s service area to the area of the disaster condition. The UE may later enable S1 mode and / or E-UTRA capability under any of the following conditions, in any combination: the UE needs to place an emergency service or call and optionally the current PLMN does not support emergency services over N1 mode; the UE needs to perform emergency services fallback (optionally after the UE determining that emergency services fallback is supported by the network based on the information received in the Emergency services fallback indicator for 3GPP access (EMF) of the 5GS network feature support IE the UE needs to place an emergency call using circuit switched fallback and / or over any other CS domain (e.g. in A mode or lu-CS mode) or any other PS domain such as EPS (or Gb mode and / or lu-PS mode). Alternatively, if the UE supports the circuit switched (CS) domain (e.g. A mode or lu mode e.g. lu-CS mode), the UE may, upon the need to place a CS emergency call, autonomously reselect (using the access technology for that mode) to a cell and / or PLMN that supports the CS domain to place the emergency call. For example, the UE may autonomously use any RAT that supports the CS domain (e.g. a cell over which the UE operates in A mode or lu-CS mode) and perform PLMN selection on using that RAT so as to place the emergency call. Note that the emergency call may also be a packet switched (PS) emergency call that can be placed over Gb mode (e.g. GERAN / GPRS) or lu-PS mode (e.g. UMTS). If the UE determines that the PLMN that is providing disaster roaming service does provide emergency services fallback, the UE may, upon a need to use emergency services or, optionally, when the UE determines to use emergency services fallback (e.g. knowing that the UE supports emergency services fallback and the network also does support emergency service fallback to EPC), take any of the following actions. Firstly, the UE may enable S1 mode, or E-UTRA access capability, and send a Registration Request message indicating the support of S1 mode by setting the S1 mode bit to “S1 mode supported” in the 5GMM capability IE. After the registration procedure is complete, the UE may initiate the service request procedure (and send a Service Request message, or Control Plane Service Request message) and request emergency services fallback by setting the service type IE or control plane service type IE to indicate “emergency services fallback”. Secondly, the UE may autonomously reselect to a cell (e.g. E-UTRA cell) that connects to EPC over which the UE can operate in S1 mode and requests emergency services Thirdly, when or if the UE, for any of the proposals herein, reselects to the CS domain (e.g. A mode or lu-CS mode) or PS domain (e.g. S1 mode, Gb mode, or lu-PS mode) of a forbidden PLMN, the UE may perform an emergency registration e.g. emergency attach in EPS (or attach for emergency services), even if it was normally registered on the 5GS system of the same (e.g. forbidden) PLMN. Note that the actual name of the registration may vary for each mode, but the proposal is that the UE optionally registers such that the only service it can get is emergency. For example, in a CS domain e.g. A mode or lu-CS mode, the UE may send a CM Service Request with the CM service type set to “Emergency call establishment” where this may be done after performing an IMSI attach, for instance. Fourthly, when the UE ends the emergency call on the CS domain or PS domain of another system that is not 5GS (e.g. CS domain of GPRS or UMTS system, or PD domain of EPS), the UE should, as quickly as possible, return to the 5GS domain (i.e. N1 mode) of the PLMN where disaster inbound roaming service was being received (or any other PLMN that may be selected for disaster roaming service) or where the UE was registered for disaster roaming services. The UE may reselect back to 5GS of the PLMN that provides disaster roaming service when the emergency calls and optionally when the UE is in idle mode of that system. Returning to the obtain disaster roaming service may also imply performing PLMN selection to select a PLMN where disaster roaming service can be obtained on 5GS (N1 mode), where the PLMN selected may or may not be the same as the previous PLMN where disaster roaming service was used, however it is preferable to return to the same PLMN that provided disaster roaming service. The UE may then disable S1 mode again as proposed herein e.g. upon return to the PLMN where disaster roaming service was provided before the emergency call or upon selection of another PLMN that provides disaster roaming service. Note that the details set out above apply even if the UE reselects to any other domain for emergency services where the emergency service may not be just because (or via) emergency services fallback. As such, when the UE is in a target system such as GERAN, UMTS, EPS, etc, for the purpose of placing an emergency call, either via CS domain or PS domain of that system, optionally where that domain is not 5GS of the PLMN where the UE was registered for disaster roaming services, the UE should, upon termination of the emergency service, attempt to return (as fast as possible) to the 5GS domain of the PLMN where the UE was registered for disaster roaming service. The UE may perform cell reselection and / or PLMN (re-)selection to return to the PLMN, and 5GS domain, to resume the disaster roaming service. In this step, the UE may also select another PLMN that provides disaster roaming service if needed. Optionally, if the UE knows that TAIs and / or Routing area identities (RAIs) and / or Location area identities (LAIs) of a target system where these TAIs and / or LAIs as known to overlap with the area of the disaster condition, then the UE, when in these systems, can monitor its location relative to these known TAIs and / or RAIs and / or LAIs. If the UE is outside of these TAIs and / or RAIs and / or LAIs, then the UE can deduce that it is no longer in the area of the disaster condition and, as such, can trigger PLMN selection to return to the original PLMN where a disaster condition was experienced. To this end, when the UE is on a PLMN that provides disaster roaming service, optionally when the UE requests to use emergency services fallback or optionally during a registration procedure, the network (e.g. AMF) may provide a set of TAIs and / or RAIs and / or LAIs that are known to overlap with the area of the disaster condition. The determination of these areas is implementation-specific and beyond the scope of this application, but will be known to the skilled person. The network may provide this information in any NAS message or in any NAS container or policy container, etc. Note that this information will be kept by the UE when the UE accesses the target system and they should be kept in a separate list or entity such that they are not overridden by any other TAI and / or RAI and / or LAI that is provided by the core network of that system. The UE uses this information to determine if it is within a disaster condition area or not as described above. If the UE determines that it is out of the disaster area, by comparing the information received from the AMF of the 5GS in the PLMN that was provided disaster roaming service, versus the TAIs and / or RAIs and / or LAIs that is received from the target system (EPS S1 mode, lu-PS mode, lu-CS mode, etc), to determine if the UE is inside the area of the disaster condition or not. If the UE is outside the area of the disaster condition, then the UE may determine to go back to the original PLMN which previously had a disaster condition since the UE should be able to get normal service again in the original PLMN. If the UE determines that it is outside of the disaster condition area, then the UE should return to its original PLMN after the emergency call ends and as quickly as possible. In a second embodiment, the UE indicates its support for S1 mode but the network avoids a handover to S1 mode. In this solution, the UE indicates whether or not is supports S1 mode accordingly. If the UE does support S1 mode as indicated in the 5GMM capability IE, then the AMF avoids any handover of the UE, or idle mode reselection of the UE, such that the UE will remain on 5GS and not use EPS (or EPC). An exception to this network behaviour may be when the UE needs to use emergency services in EPS e.g. via EPS services fallback. For example, the AMF may avoid handing over the UE to EPS. However, if the UE sends a Service Request message (or Control Plane Service Request message) requesting emergency services fallback, then the AMF may allow the request due to it being for emergency services and may then allow the UE to go to EPS by either executing a handover or an idle mode reselection. To avoid handover or idle mode reselection for the UE as set out above, the AMF may take any of the following actions: • The AMF may store a local flag or indication that specifies that the UE is not handed over to EPS or to S1 mode even if the UE supports S1 mode. For example, the AMF may make this determination for a UE optionally if the UE is registering (or has registered) for disaster roaming services, or the AMF can use the knowledge of the UE being a UE that is registered for disaster roaming services to further determine that such a UE should not be permitted to use EPS, except for the case of emergency services or emergency services fallback • The AMF may indicate to the RAN that the UE is not permitted to use EPC. This may be done by appropriately setting the ‘Core Network Type Restriction for Serving PLMN’ (of the Mobility Restriction List IE that is defined in TS 38.413, see TS 38.413) such that the EPC is indicated to be restricted. The AMF may also set the same information for equivalent PLMNs in the ‘Core Network Type Restriction for Equivalent PLMNs’ and the contained ‘Core Network Type Restriction’ component (i.e. the ‘Core Network Type Restriction’ of the ‘Core Network Type Restriction for Equivalent PLMNs’) of the Mobility Restriction List IE that is defined in TS 38.413. • If the UE is accessing the 5GC over NR, and the PLMN which is providing inbound disaster roaming service is only allowed to provide service to the UE via NR (e.g. based on subscription or local policies), the AMF may also indicate to the RAN (using the appropriate information element) that E-UTRA(N) is a forbidden RAT for the UE in question. The AMF may indicate this using the ‘RAT Restriction Information’ component of the ‘RAT Restrictions’ information element of the Mobility Restriction List IE that is defined in TS 38.413. However, when the UE requests to use emergency services or emergency services fallback (to fallback to EPS / EPC), or when the UE establishes a PDU session for emergency services, where this session may optionally be potentially transferred to EPS or S1 mode, the AMF may remove any restriction that is listed above. The AMF may then update the RAN node such that any such restriction as listed above (or other mobility restriction) is removed. For example, the AMF may update the RAN with a new set of restrictions such that the UE will be allowed to use EPC and / or E-UTRA as needed for the purpose of the emergency service. The AMF may provide this updated information using the Mobility Restriction List IE that the AMF can send to the RAN using any N2 message e.g. Handover Request, INITIAL CONTEXT SETUP REQUEST, DOWNLINK NAS TRANSPORT, or any other N2 message (that is new or existing and) that can be used to carry the Mobility Restriction List IE. To summarize, when the UE is using 5GS of a PLMN such that the UE is registered for roaming disaster service, the serving network e.g. AMF, should ensure that the UE does not access EPC (or optionally E-UTRA if the UE is accessing 5GC using NR, and / or if the network does not support E-UTRAN connected to 5GC). The AMF should ensure that it indicates to the RAN (e.g. using the Mobility Restriction List IE or any other IE) over any N2 message that the UE should not be allowed to use EPC, or optionally E-UTRA, in some conditions as stated above. The AMF should therefore set the restrictions for the related information elements (or components) accordingly e.g. AMF indicates that EPC is restricted in ‘Core Network Type Restriction for Serving PLMN’ and / or in the ‘Core Network Type Restriction for Equivalent PLMNs’. When the UE requests emergency services (e.g. request a PDU session for emergency services) or emergency services fallback (to fallback to EPS / EPC), or when the UE establishes a PDU session for emergency services, where this session may be transferred to EPS or S1 mode, optionally if the request is to use emergency services fallback, and optionally if the network (e.g. AMF or serving PLMN) does not support emergency services in 5GS, then the AMF may determine to remove all mobility restrictions that are listed above, or other restrictions. The AMF may then update the RAN to now indicate that e.g. EPC is no longer restricted and / or E-UTRA is no longer restricted, in the appropriate lEs as listed earlier. The following is not necessarily only related to S1 mode but rather related to confining the UE’s service on 5GS to the area of the disaster condition, where the area is an area of the disaster condition in the source PLMN of the UE, where the PLMN is the PLMN that experienced a disaster condition. However few exceptions apply as will be described. Note that even when the UE remains in 5GS on the PLMN (where the PLMN is the PLMN that is providing disaster roaming service), the AMF ensures that the UE can only receive services within an area that is overlapping with the area of the disaster condition as far as possible. Assuming that the AMF knows the area of the disaster condition in the UE’s source PLMN (where this information is obtained using known methods that are not herein described), the AMF uses this information to determine which cells of the NG-RAN would overlap, or would match to or match with or correspond to, the area of the disaster condition. This may be done by implementation specific methods in the AMF. Having made such a determination, the AMF further determines the cells and optionally their cell identities (e.g. global cell identities) that would overlap with the disaster condition area of the source PLMN. Having made this determination, the AMF sets out the mobility restriction for the UE (for NR, or E-UTRA in the case the UE is accessing 5GC over E-UTRA) such that only the cells that are determined to overlap with the area of the disaster condition would be allowed for the UE. For example, only these cells would be allowed for the UE and, as such, the RAN should only perform mobility (e.g. handover) for the UE if the target cell is part of the identified cell. Therefore, when the AMF provides any N2 message to the RAN (e.g. such as those listed earlier), the AMF ensures that the mobility restrictions (using any of the components listed earlier e.g. in the Mobility Restriction List IE or any other IE that can be used for this purpose) will indicate the cells that are determined to overlap with the area of the disaster condition as the only cells that are permitted for the UE to get normal service. For example, having identified the cells that are allowed for the UE, where these cells are e.g. identified to overlap with the area of the disaster condition, the AMF determines the tracking area codes (TACs) that is / are broadcast by these cells. The AMF e.g. should indicate these TACs to be ‘Allowed TACs’ in the Service Area Information IE of the Mobility Restriction List IE. Similarly, the AMF can determine which TACs (e.g. which cells broadcasts such TACs) are not allowed for the UE using a similar mechanism as described above. For example, by determining which cells are allowed for the UE (where these cells overlap with, or are confined to, the area of the disaster condition) the AMF can therefore deduce which cells are not allowed for the UE and can therefore also deduce the TACs that are not allowed for the UE as these cells may be known to broadcast particular TACs. For the cells and / or TACs that are determined to be not allowed for the UE e.g. because these cells that broadcast the determined TACs are not within the area of the disaster condition, the AMF may inform the RAN that these TACs are not allowed. For example, these TACs can be indicated to be not allowed using the ‘Not Allowed TACs’ field or IE in the Mobility Restriction List IE. Or these TACs (i.e. the TACs that are determined to be not allowed) can be indicated in the ‘Forbidden TACs’ field or IE in the Mobility Restriction List IE. Similarly, when the UE requests to use emergency services on 5GS, or when the UE establishes a PDU session for emergency services, the AMF may remove one or more restriction for the UE. The AMF may update the RAN using any N2 message (e.g. as listed earlier) such as one or more restriction is removed. For example, the AMF may indicate that other TACs that were previously not allowed to be TACs that are currently allowed. For example, the AMF may also indicate an updated service area list which can contain more TACs that are allowed, etc. As such, in general, the listed mobility restrictions, or other mobility restrictions, including restrictions on EPC and / or E-UTRA as described earlier, can be temporary removed or ignored by the AMF such that the AMF updates the restrictions towards the RAN (using any N2 message) such that the UE can be allowed to use other cells that broadcast other TACs even if they are outside of the area of the disaster condition. This may be done to allow the UE to use emergency services. Note that while allowing other areas and / or cells to be used for the UE during an emergency session / service (e.g. when a PDU session for emergency service is established), the AMF may initiate the release (or request the SMF to release) all other PDU session that is not a PDU session for emergency service. Furthermore, the AMF may inform the UE in the PDU session status IE that all other PDU session has been deactivated in the network. Alternatively, the UE may autonomously release one or more PDU sessions that are not a PDU session for emergency service when the UE moves to an area, or uses a RAT or core network type, that is known to be not allowed for the UE. For example, if the UE requests to use emergency services on EPS, or emergency services fallback, or if the UE autonomously reselects to EPS, or a CS domain, or PD domain of UMTS, or GERAN, etc, then the UE may autonomously and / or locally release any or all other PDU sessions that are not a PDU session for emergency services. For example, if the UE has at least one PDU session on 5GS of the PLMN that is providing disaster roaming service, then when the UE accesses S1 mode (e.g. due to emergency services fallback, or UE autonomous reselection to S1 mode or E-UTRA as described herein e.g. after reactivation or re-enabling of S1 mode), then the UE may locally release each and every PDU session that is not a PDU session for emergency services. Alternatively, if the UE does not release such a session, the UE should not attempt to transfer the session to EPS or another PS domain such as GERAN, UTRAN, etc. This ensures that other services are confined to 5GS of the PLMN where disaster roaming service is provided and also the service is confined to the area of the disaster condition. For all of the embodiments described herein, when the emergency service ends, the AMF may then return to the original restrictions of mobility such that the UE’s service can be confined to the area of the disaster condition. The AMF may then update the RAN with the updated restrictions. This may happen e.g. when the PDU session for emergency service is released, or when the UE returns from a target system after a request for emergency services fallback, etc. Another embodiment ensures that PDU session that are not for emergency will not be transferred to EPS, every such PDU session should not be allocated an EPS bearer ID by the network. As such, the UE will not get a corresponding EPS bearer ID for such a PDU session in the PDU Session Establishment Accept message (in the QoS rules IE or QoS flow descriptions IE or the Mapped EPS bearer context IE). Any of the following can be done to achieve this: • The subscription of the UE is updated to indicate whether or not a PDU session that is established in, or transferred to (e.g. from a source PLMN that had experienced disaster condition), a PLMN where disaster roaming service is provided, can be transferable to EPS or not. • If the subscription indicates not, or based on local network policy (e.g. in the SMF), the SMF should not request (e.g. from the AMF) the allocation of an EPS bearer ID for a UE that is receiving disaster roaming services • If the subscription indicates not, or based on local network policy (e.g. in the AMF), the AMF should not allocate an EPS bearer ID for a UE that is receiving disaster roaming services • The UE may: be informed with any other method whether the PDU session is transferable to EPS or not; be configured to transfer any such PDU session or not; or always determine that such a PDU session is transferable or not, based on a predetermined behaviour. Note that these apply even for the case when a PDU session was initiated indicated to be transferable (e.g. the UE had already received the EPS bearer ID as part of the PDU session establishment) to EPS, where for example the PDU session is a session that was first established in a source PLMN (in which a disaster condition was experienced) and where the UE was informed that the session is transferable by virtue of e.g. receiving an EPS bearer ID in the 5GSM message of that session e.g. in the PDU Session Establishment Accept message • For a session that was transferable from a source PLMN to the PLMN where the disaster roaming service is provided, the SMF (e.g. V-SMF or H-SMF) may perform a PDU session modification procedure such as to delete the EPS bearer ID that is related to each QoS flow and / or PDU session. This ensures that the PDU session will not be transferred to EPS. Alternatively, the AMF or SMF may send any NAS message to the UE to indicate whether a PDU session is transferable or not, to EPS, during access to disaster roaming service. Any NAS message and any IE can be used for this purpose. The UE can then, based on this information or other determination as proposed above, further determine if a session in question can be transferred to EPS or not. Note that the subscription of the UE and / or local policies in the PLMN that is providing disaster roaming service may indeed allow the transfer of sessions, even if they are not for emergency services, to EPS. If this is the case, the network nodes may not necessarily perform some of the actions set out above and may for example allocate, or keep an allocated, EPS bearer ID. It is however described that the network (e.g. AMF or SMF in the current serving PLMN or HPLMN) informs the UE whether or not such sessions can be transferred to EPS and / or in general whether or not the UE can use EPS for all services, or for emergency services only, or for a particular type of service. Alternatively, this information may be specific to a DNN, slice, or slice / DNN combination. The UE may use any of the above information to determine whether or not to transfer a session to EPS. If a PDU session is determined to not be transferable e.g. based on the above, then the UE does not attempt to transfer the session to EPS and may release it locally when the UE performs an inter-system change to S1 mode. The network e.g. AMF may provide a list of TAIs and / or RAIs and / or LAIs that the UE can use to determine that areas and / or cells where normal service can be used in e.g. S1 mode, lu-CS modes, etc, as described earlier. If the UE is outside of these areas, it can assume to not be able to get normal service and may enter a new state e.g. limited state or any other state in which not all services can be obtained. The UE may be preconfigured with any of the above information using preconfigurations or any other NAS message or container that the UE may receive and that may carry this information (or that the network may send to the UE, where the network may be a network node such as UDM, AMF, SMF, etc, where the node may be a node in the VPLMN or the HPLMN, and the network can use any NAS message or container to send the information to the UE). Based on this information the UE may determine if a session can be transferable to EPS, and if not the UE may locally release the session when the UE performs an inter-system change to EPS and may indicate the status of the session to be deactivated in the appropriate IE e.g. EPS bearer status IE that the UE can send in either Attach Request or Tracking Area Update Request message. 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. 18 02 05 24

Claims

1. A method of operating a User Equipment, UE, such that the UE’s service is confined to 5 5GS during a Disaster Condition, in a defined area, overlapping with an area of the Disaster Condition in the 5GS system, comprising the step of:the UE not indicating support for S1 mode upon registration with the telecommunication network when the UE is registering for disaster roaming service, by the UE setting S1 mode 10 bit, EPC NAS supported bit, to "S1 mode not supported" in the 5GMM capability IE of the REGISTRATION REQUEST message.

2. The method of claim 1 wherein the UE disables S1 mode.15 3. The method of claim 2 wherein the UE enables S1 mode if at least one of the followingcircumstances:• the UE needs to place an emergency service or call;• the UE needs to perform emergency services fallback; and20 • the UE needs to place an emergency call using circuit switched fallback.

4. The method of claim 3 wherein after completing the emergency service or call, the UE attempts to return to a 5GS domain of the telecommunication network to resume disaster roaming.

255. The method of any of claims 1 to 4 wherein the UE autonomously uses any RAT that supports the Circuit Switched domain, and performs network search or selection using that RAT so as to place an emergency call.30 6. Apparatus arranged to perform the method of any preceding claim.

Images