METHOD AND APPARATUS FOR IMPROVEMENTS IN AND RELATING TO MANAGEMENT OF A DISASTER CONDITION IN A MOBILE COMMUNICATION SYSTEM

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a terminal in a wireless communication system is provided. The method includes transmitting, to a network entity associated with a first network system, a registration request message for a disaster roaming service, the registration request message including capability information of the terminal, transmitting, to the network entity, a service request message for an emergency service using a second network system, and after the emergency service ends, performing a cell reselection to return to the first network system providing the disaster roaming service.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: transmitting, to a network entity associated with a first network system, a registration request message for a disaster roaming service, the registration request message including capability information of the terminal; transmitting, to the network entity, a service request message for an emergency service using a second network system; and after the emergency service ends, performing a cell reselection to return to the first network system providing the disaster roaming service.

2. The method of claim 1, wherein the capability information indicates that the second network system is not supported even if the terminal supports the second network system.

3. The method of claim 1, wherein the capability information indicates whether the second network system is supported accordingly, and wherein, in case that the capability information indicates that the second network system is supported, a handover to the second network system is prevented by the network entity.

4. The method of claim 1, further comprising: receiving, from the network entity, information on at least one identifier of area overlapping with a disaster area; determining whether the terminal is within the disaster area based on the information; and in case that the terminal is out of the disaster area, determining to return to an original public land mobile network (PLMN) which previously had a disaster condition.

5. A method performed by a network entity associated with a first network system in a wireless communication system, the method comprising: receiving, from a terminal, a registration request message for a disaster roaming service, the registration request message including capability information of the terminal; and receiving, from the terminal, a service request message for an emergency service using a second network system, wherein, after the emergency service ends, a cell reselection to return to the first network system providing the disaster roaming service is performed.

6. The method of claim 5, wherein the capability information indicates that the second network system is not supported even if the terminal supports the second network system.

7. The method of claim 5, wherein the capability information indicates whether the second network system is supported accordingly, and wherein, in case that the capability information indicates that the second network system is supported, a handover to the second network system is prevented by the network entity.

8. The method of claim 5, further comprising transmitting, to the terminal, information on at least one identifier of area overlapping with a disaster area, wherein the information is used to determine whether the terminal is within the disaster area so that the terminal returns to an original public land mobile network (PLMN) which previously had a disaster condition in case that the terminal is out of the disaster area.

9. A terminal in a wireless communication system, the terminal comprising: a transceiver; and a controller configured to: transmit, to a network entity associated with a first network system via the transceiver, a registration request message for a disaster roaming service, the registration request message including capability information of the terminal, transmit, to the network entity via the transceiver, a service request message for an emergency service using a second network system, and after the emergency service ends, perform a cell reselection to return to the first network system providing the disaster roaming service.

10. The terminal of claim 9, wherein the capability information indicates that the second network system is not supported even if the terminal supports the second network system.

11. The terminal of claim 9, wherein the capability information indicates whether the second network system is supported accordingly, and wherein, in case that the capability information indicates that the second network system is supported, a handover to the second network system is prevented by the network entity.

12. The terminal of claim 9, wherein the controller is further configured to: receive, from the network entity via the transceiver, information on at least one identifier of area overlapping with a disaster area, determine whether the terminal is within the disaster area based on the information, and in case that the terminal is out of the disaster area, determine to return to an original public land mobile network (PLMN) which previously had a disaster condition.

13. A network entity associated with a first network system in a wireless communication system, the network entity comprising: a transceiver; and a controller configured to: receive, from a terminal via the transceiver, a registration request message for a disaster roaming service, the registration request message including capability information of the terminal, and receive, from the terminal via the transceiver, a service request message for an emergency service using a second network system, wherein, after the emergency service ends, a cell reselection to return to the first network system providing the disaster roaming service is performed.

14. The network entity of claim 13, wherein the capability information indicates that the second network system is not supported even if the terminal supports the second network system.

15. The network entity of claim 13, wherein the capability information indicates whether the second network system is supported accordingly, and wherein, in case that the capability information indicates that the second network system is supported, a handover to the second network system is prevented by the network entity.

16. The network entity of claim 13, wherein the controller is further configured to transmit, to the terminal via the transceiver, information on at least one identifier of area overlapping with a disaster area, and wherein the information is used to determine whether the terminal is within the disaster area so that the terminal returns to an original public land mobile network (PLMN) which previously had a disaster condition in case that the terminal is out of the disaster area.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0070] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:

[0071] FIG. 1 shows a schematic of a network according to the prior art showing several RANs;

[0072] FIG. 2 shows a schematic of the network of FIG. 1 and the definition of a DC in a defined area;

[0073] FIG. 3 illustrates a schematic of a DC area in a first that overlaps with a coverage area of a second network not affected by the DC according to embodiments of the present disclosure;

[0074] FIG. 4 illustrates a block diagram of a network entity according to embodiments of the present disclosure; and

[0075] FIG. 5 illustrates a user equipment (UE) according to embodiments of the present disclosure.

DETAILED DESCRIPTION

[0076] FIGS. 1 through 5, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0077] 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.

[0078] 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 “51 mode not supported” in the 5GMM capability IE of the REGISTRATION REQUEST message even if the UE does support S1 mode.

[0079] 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.

[0080] 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.

[0081] 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 Iu-CS mode) or any other PS domain such as EPS (or Gb mode and/or Iu-PS mode).

[0082] Alternatively, if the UE supports the circuit switched (CS) domain (e.g., A mode or Iu mode e.g., Iu-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 Iu-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 Iu-PS mode (e.g., UMTS).

[0083] 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.

[0084] 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 5M/1 W 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”.

[0085] 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

[0086] Thirdly, when or if the UE, for any of the proposals herein, reselects to the CS domain (e.g., A mode or Iu-CS mode) or PS domain (e.g., S1 mode, Gb mode, or Iu-PS mode) of a forbidden PLMN, the UE may perform an emergency registration e.g., emergency attach in the 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 Iu-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.

[0087] 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 the 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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, Iu-PS mode, Iu-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.

[0092] In a second embodiment, the UE indicates its support for S1 mode but the network avoids a handover to S1 mode.

[0093] 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 the EPS (or EPC). An exception to this network behaviour may be when the UE needs to use emergency services in the EPS e.g., via the EPS services fallback. For example, the AMF may avoid handing over the UE to the 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 the EPS by either executing a handover or an idle mode reselection.

[0094] To avoid handover or idle mode reselection for the UE as set out above, the AMF may take any of the following actions:

[0095] The AMF may store a local flag or indication that specifies that the UE is not handed over to the 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 the EPS, except for the case of emergency services or emergency services fallback

[0096] 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.

[0097] 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.

[0098] However, when the UE requests to use emergency services or emergency services fallback (to fallback to the EPS/EPC), or when the UE establishes a PDU session for emergency services, where this session may optionally be potentially transferred to the 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.

[0099] 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 the EPS/EPC), or when the UE establishes a PDU session for emergency services, where this session may be transferred to the 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 IEs as listed earlier.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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 sessions that are not a PDU session for emergency service. Furthermore, the AMF may inform the UE in the PDU session status IE that all other PDU sessions have been deactivated in the network.

[0105] 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 the EPS, or emergency services fallback, or if the UE autonomously reselects to the 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 the 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.

[0106] 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.

[0107] Another embodiment ensures that PDU sessions that are not for emergency will not be transferred to the 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:

[0108] 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 the EPS or not.

[0109] 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

[0110] 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

[0111] The UE may: be informed with any other method whether the PDU session is transferable to the 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 the 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

[0112] 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 the 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 the 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 the EPS or not.

[0113] 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 the 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.

[0114] 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 the EPS and/or in general whether or not the UE can use the 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 the 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 the 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, Iu-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.

[0115] 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 the EPS, and if not the UE may locally release the session when the UE performs an inter-system change to the EPS and may indicate the status of the session to be deactivated in the appropriate IE e.g., the EPS bearer status IE that the UE can send in either Attach Request or Tracking Area Update Request message.

[0116] FIG. 4 illustrates a block diagram of a network entity according to embodiments of the present disclosure.

[0117] In one embodiment, the network entity may include an access and mobility management function (AMF).

[0118] Referring to FIG. 4, the network entity 400 may include a processor 410, a transceiver 420 and a memory 430. However, all of the illustrated components are not essential. The network entity 400 may be implemented by more or less components than those illustrated in FIG. 4. In addition, the processor 410 and the transceiver 420 and the memory 430 may be implemented as a single chip according to another embodiment.

[0119] The aforementioned components will now be described in detail.

[0120] The processor 410 may include one or more processors or other processing devices that control the proposed function, process, and/or method. Operation of the network entity 400 may be implemented by the processor 410.

[0121] The transceiver 400 may be connected to the processor 410 and transmit and/or receive a signal. The signal may include control information and data. In addition, the transceiver 420 may receive the signal and output the signal to the processor 410. The transceiver 420 may transmit a signal output from the processor 410.

[0122] The memory 430 may store the control information or the data included in a signal obtained by the network entity 400. The memory 430 may be connected to the processor 410 and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method. The memory 430 may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CD-ROM and/or DVD and/or other storage devices.

[0123] FIG. 5 illustrates a user equipment (UE) according to embodiments of the present disclosure.

[0124] Referring to FIG. 5, the UE 500 may include a processor 510, a transceiver 520 and a memory 530. However, all of the illustrated components are not essential. The UE 500 may be implemented by more or less components than those illustrated in FIG. 5. In addition, the processor 510 and the transceiver 520 and the memory 530 may be implemented as a single chip according to another embodiment.

[0125] The aforementioned components will now be described in detail.

[0126] The processor 510 may include one or more processors or other processing devices that control the proposed function, process, and/or method. Operation of the UE 500 may be implemented by the processor 510.

[0127] The transceiver 520 may include a RF transmitter for up-converting and amplifying a transmitted signal, and a RF receiver for down-converting a frequency of a received signal. However, according to another embodiment, the transceiver 520 may be implemented by more or less components than those illustrated in components.

[0128] The transceiver 520 may be connected to the processor 510 and transmit and/or receive a signal. The signal may include control information and data. In addition, the transceiver 520 may receive the signal through a wireless channel and output the signal to the processor 510. The transceiver 520 may transmit a signal output from the processor 510 through the wireless channel.

[0129] The memory 530 may store the control information or the data included in a signal obtained by the UE 500. The memory 530 may be connected to the processor 510 and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method. The memory 530 may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CD-ROM and/or DVD and/or other storage devices.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] Although the present disclosure has been described with various embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.