Preserving emergency calls during transfer failure

Abstract

This application is titled "Retaining an Emergency Call During Transfer Failure". Embodiments of this disclosure relate to retaining an emergency call during a transfer failure. A system and method in a user equipment (UE) for transferring an emergency session from a first network to a second network. The method includes: sending a first registration request message to the second network; receiving a registration rejection message from the second network; detecting that an emergency session between the UE and the first network is in progress; sending a second registration request message including an emergency registration request to the second network; and receiving a registration acceptance message for the emergency session.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 202011409247.0, filed on December 4, 2020, entitled "Retaining Emergency Calls During Transfer Failure".

[0002] Cross-reference to related applications

[0003] This application is a continuation of U.S. Patent Application No. 16 / 882,245 (Attorney’s File No. 50984-US-PAT-4214-70000) entitled “Preserving Emergency Call During Failure to Transfer”, filed May 22, 2020 by Jan Hendrik Lucas Bakker, which is incorporated herein by reference in its entirety. Technical Field

[0004] Embodiments of this disclosure relate to retaining emergency calls during transfer failures. Background Technology

[0005] As used herein, the term "user equipment" (or alternatively "UE") may in some cases refer to mobile or wireless devices such as mobile phones, personal digital assistants, handheld devices, laptops, or personal computers, and similar devices with telecommunications capabilities, including text and email functionality. The terms UE, mobile device, and wireless device are used interchangeably herein. Such a UE may include a device and its associated removable memory modules, such as, but not limited to, universal integrated circuit cards (UICCs) including Subscriber Identity Module (SIM) applications, Universal Subscriber Identity Module (USIM) applications, or Removable Subscriber Identity Module (R-UIM) applications. Alternatively, such a UE may include the device itself without such a module. In other cases, the term "UE" may refer to a device with similar capabilities but not transportable, such as a desktop computer, set-top box, or network device. The term "UE" may also refer to any component that can terminate a user's communication session. Similarly, the terms "user agent," "UA," "user equipment," and "mobile device" are used synonymously herein.

[0006] An emergency call or session is a special type of call or session. It typically has a higher priority than other calls in the network, and its bearer has characteristics different from other calls; for example, the bearer may have one or more of higher priority or higher Quality of Service (QoS). Furthermore, the UE may not need a network subscription to request an emergency call. For example, an emergency call can be completed if a UICC does not exist, or if the UE is associated with an expired or invalid subscription. Interrupting or blocking an emergency call can have dire consequences. Summary of the Invention

[0007] According to one aspect of this disclosure, a method is provided in a user equipment (UE) for transferring an ongoing emergency session from a first network to a second network. The method includes: the UE sending a first attachment request message to the second network, the first attachment request message including a Packet Data Network (PDN) connectivity request message with a request type set to "handover"; receiving an attachment rejection message from the second network at the UE; detecting at the UE that an ongoing emergency session is in progress between the UE and the first network; the UE sending a second attachment request message to the second network in response to detecting the ongoing emergency session and in response to receiving the attachment rejection message from the second network, the second attachment request message including a PDN connectivity request message with a request type set to "handover of emergency bearer service" for the ongoing emergency session; and receiving an attachment acceptance message at the UE.

[0008] According to another aspect of this disclosure, a user equipment (UE) is provided. The UE includes: a processor; and a memory storing instructions that, when executed by the processor, cause the UE to: send a first attachment request message to a second network, the first attachment request message including a PDN connectivity request message with the request type set to "handover"; receive an attachment rejection message from the second network; detect that an ongoing emergency session is in progress between the UE and a first network; in response to detecting the ongoing emergency session and in response to receiving the attachment rejection message from the second network, send a second attachment request message to the second network, the second attachment request message including a PDN connectivity request message with the request type set to "handover of emergency bearer service" for the ongoing emergency session; and receive an attachment acceptance message.

[0009] According to another aspect of this disclosure, a non-transient computer-readable storage medium is provided, comprising instructions. When executed by a processor, the instructions cause the processor to: send a first attachment request message to a second network, the first attachment request message including a PDN connectivity request message with a request type set to "handover"; receive an attachment rejection message from the second network; detect that an ongoing emergency session between the UE and the first network is in progress; in response to detecting the ongoing emergency session and in response to receiving the attachment rejection message from the second network, send a second attachment request message to the second network, the second attachment request message including a PDN connectivity request message with a request type set to "handover of emergency bearer service" for the ongoing emergency session; and receive an attachment acceptance message. Attached Figure Description

[0010] To gain a more complete understanding of this disclosure, reference is now made to the following brief description in conjunction with the accompanying drawings and detailed description, wherein similar reference numerals denote similar parts.

[0011] Figure 1 This is a diagram of an embodiment of the architecture used for interworking between 5GS and EPC / U-TRAN.

[0012] Figure 2 This is a message flow diagram of an embodiment that preserves emergency calls during the handover from 5GC to EPC.

[0013] Figure 3 This is a message flow diagram of an embodiment that preserves emergency calls during the handover from EPC to 5GC.

[0014] Figure 4 This is a message flow diagram of an embodiment that preserves emergency calls with reduced messaging during the handover from 5GC to EPC.

[0015] Figure 5 This is a message flow diagram of an embodiment that preserves emergency calls with reduced messaging during the switch from EPC to 5GC.

[0016] Figure 6 This is a proposed change to Section 5.3.11 of 3GPP TS24.301.

[0017] Figure 7 This is a proposed change to Section 5.3.15 of 3GPP TS24.301.

[0018] Figure 8 This is a proposed change to Section 5.5.1.2.5A of 3GPP TS24.301.

[0019] Figure 9 This is a proposed change to Section 5.5.1.2.5B of 3GPP TS24.301.

[0020] Figure 10 This is a proposed change to section 5.5.1.2.5B1 of 3GPP TS24.301.

[0021] Figure 11A and Figure 11B This is a proposed change to Section 5.5.1.2.6 of 3GPP TS24.301.

[0022] Figure 12 This is a proposed change to Section 5.5.1.2.6 of 3GPP TS 24.501.

[0023] Figure 13This is a proposed change to Section 5.5.1.2.6A of 3GPP TS24.501.

[0024] Figure 14A , Figure 14B and Figure 14C This is a proposed change to Section 5.5.1.2.7 of 3GPP TS24.501.

[0025] Figure 15 This is a diagram of an embodiment of a network element.

[0026] Figure 16 This is a diagram of an embodiment of a communication device.

[0027] Figure 17 This is a diagram of an embodiment of a system suitable for implementing one or more embodiments disclosed herein. Detailed Implementation

[0028] Emergency calls can be established by a UE operating in a single registration mode, meaning the UE registers with only a single network at any given time (the term registration is considered synonymous with attachment, depending on the context of its use). The network can be a fifth-generation (5G) core network supported by an access network, or an older network, such as a typical fourth-generation (4G) core network supported by an access network. An example of an access network supporting a 4G core network is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), i.e., an Evolved Universal Terrestrial Radio Access Network (E-UTRA) connected to an Evolved Packet Core (EPC). If an emergency call is established in one network (e.g., a 5G core network supported by an access network) and there is no interoperability between the two networks (e.g., a 5G core network supported by an access network and an EPC or 4G core network supported by an access network), the handover of the emergency call between networks may fail, and the emergency call may be dropped. Several techniques for handing over emergency calls between 5G core networks and EPC networks are described in this paper.

[0029] A 5G access network can be at least one of several access networks, including New Radio (NR) and E-UTRA. The 5G access network provides access to the 5G core network (5GC). A Wireless Local Area Network (WLAN) can also be used to access the 5GC. The UE uses Non-Access Stratum (NAS) protocols to communicate with the core network via the access network. A typical network element in the EPC that processes NAS messages is the Mobility Management Entity (MME). A typical network element in the 5GC that processes NAS messages is the Access and Mobility Management Function (AMF) or Session Management Function (SMF). The AMF and SMF are 5G core network nodes.

[0030] NAS protocols include mobility (management) protocols and session management protocols. An example of an EPC NAS mobility protocol message is an attach message, such as an ATTACH REQUEST message. An example of an EPC NAS session management protocol message is a Packet Data Network (PDN) connection request message, such as a PDNCONNECTION REQUEST message. An example of a 5GC NAS mobility protocol message is a registration message, such as a REGISTRATION REQUEST message. An example of a 5GC NAS session management protocol message is a Protocol Data Unit (PDU) session request message, such as a PDU SESSION REQUEST message. The sender of these NAS messages can receive response messages for any of these NAS messages. For example, response messages are NAS response messages, such as an ATTACH REJECT message, an ATTACH ACCEPT message, etc.

[0031] The UE can be in one or more operating modes. In idle mode (typically the opposite of connected mode), the UE cannot initiate NAS procedures involving session management and the session management protocol. NAS procedures involving mobility management and the mobility management protocol are required to change the UE from idle mode to connected mode.

[0032] When performing the EPC NAS registration process, a UE may request to combine attachments (e.g., packet-switched and circuit-switched services provided by the EPC) through the attachment process (which causes the UE to send an attachment request message to the network), or request to attach only Evolved Packet System (EPS) services through the attachment process, or request to attach only Emergency Bearer services through the attachment process.

[0033] When a UE is attached via combination, the network or MME has already registered the UE in a circuit-switched (CS) domain network node (e.g., a Mobile Switching Center (MSC) or MSC server). In other words, the network registers the UE on behalf of the UE in the CS domain network node. After successful combination registration, the UE can obtain CS services via Circuit Switched Backoff (CSFB). The attachment request message sent by the UE to the network may also include a Packet Data Network (PDN) connection request message.

[0034] When performing the 5GC NAS registration process, the UE can request to register through the registration process (which causes the registration message to be sent by the UE to the network), or request to register for emergency bearer services only through the registration process.

[0035] In certain communication environments, 4G access networks (i.e., access networks connected to the 4G core network EPC) are more prevalent than 5G access networks (i.e., access networks connected to the 5G core network 5GC). UEs may need to migrate existing connections from 5G access networks to 4G access networks (e.g., when handing over from an access network providing access to the 5GC) and vice versa (e.g., when handing over from an access network providing access to the EPC). Systems such as EPS and 5GS include both core and access networks.

[0036] Figure 1 This is a diagram illustrating an embodiment of architecture 100 for interoperability between 5G and EPC. The N26 interface is the core network (CN) interface between the MME and the 5G system (5GS) AMF to enable interoperability between the EPC and the 5G core. Support for the N26 interface in the network is optional for interoperability.

[0037] The core PDN gateway (PGW-C) + SMF and user plane function (UPF) + PDN gateway user plane (PGW-U) are dedicated to interoperability between 5GS and EPC. They are optional and based on UE mobility management (MM) core network capabilities and UE subscriptions. UEs not restricted to 5GS and EPC interoperability can be served by entities not dedicated to interoperability, i.e., by PGW or SMF / UPF.

[0038] Another UPF (not shown) may exist between the NG Radio Access Network (NG-RAN) and the UPF+PGW-U; that is, the UPF+PGW-U may support an N9 interface toward the additional UPF if needed. The diagrams and procedures describing the Serving Gateway (SGW) in this specification do not assume that the SGW is deployed as a monolithic SGW or as a Serving Gateway (SGW) split into its control plane and user plane functionalities.

[0039] Unless the UE is dual-registered (e.g., registered to a 5G network and attached to a 4G network), the UE cannot be in connected mode simultaneously in both 5GS and EPS. Therefore, the N26 interface can be used to provide interoperability between 5GS and EPS to allow for handover between networks.

[0040] For example, an emergency call in a restricted service state can occur when a UE lacks sufficient credentials to access the network (e.g., the UE may not need to subscribe to the network to request an emergency call). The network can also convert an emergency call into a restricted service state emergency call when it switches the emergency call to a cell where the UE would otherwise not be allowed access. When the network converts a UE's emergency call into a restricted service state emergency call, the UE is in connected mode. In a restricted service state, subscription-based services are not allowed or are no longer permitted. Subscription-based services typically include shared services such as Short Message Service (SMS), non-emergency voice calls, and internet access.

[0041] When a UE performs an emergency attach procedure with an EPC (i.e., an attach procedure that results in the transmission of an attach request message for only the emergency bearer service), the UE cannot obtain non-emergency services while it is attached in this manner. The UE is in a restricted service state. When a UE performs a (non-emergency) attach procedure with an EPC (i.e., an attach procedure that results in the transmission of an attach request message for only the attach request message or the EPS service attach request message), the UE can use non-emergency services (assuming the attach request is accepted by the network). In either case, the attached request message sent can include a PDN connection request for the emergency bearer service.

[0042] When a UE performs an emergency registration procedure with the 5GC (i.e., a registration procedure that results in the sending of a registration request message for emergency services only), the UE cannot use non-emergency services while it is registered in this way. The UE is in a restricted service state. When a UE performs a (non-emergency) registration procedure with the 5GC (i.e., a registration procedure that results in the sending of a registration request message), the UE can obtain non-emergency services (assuming the registration request is accepted by the network). In either case, the UE can send a PDU session request to establish a PDU session for emergency services after sending the registration request message or after the network accepts the registration request.

[0043] There are many reasons why a network might reject an attachment or registration request sent by a UE. For example, a request might be rejected due to network failure, network overload, UE subscription limitations, or user subscription limitations. Other examples exist.

[0044] 5GS supports interoperability with EPS via the N26 interface (between AMF and MME) or without the N26 interface (i.e., via coordination or co-location between PDG and SMF or UPF). The issues discussed in this paper relate to networks supporting interoperability without N26 and UEs operating in single-registration mode.

[0045] UEs in dual-registration mode but not yet concurrently registered in another system are also affected by the issues discussed in this paper.

[0046] UEs that are registered concurrently in a dual-registration mode and in another system are affected by a subset of the problems discussed in this paper.

[0047] When a cell via the 5G access network is registered in the 5GC, and when there are emergency PDU sessions (which may be in addition to, for example, non-emergency PDU sessions), the UE can determine that the 4G access network cell is or becomes more desirable. For example, when the UE is in idle mode with the EPC, the UE may need to transfer ongoing connectivity provided by some or all PDU sessions to the EPC serving a cell on the 4G access network.

[0048] To transfer ongoing connectivity provided by an emergency PDU session from 5GC to EPC, the UE performs an attach procedure and, preferably, includes a PDN connection request message representing the connectivity provided by the emergency PDU session in the attach message. However, some UEs may also include a PDN connection request message representing connectivity provided by a non-emergency PDU session in the attach message. In the latter case, the UE will have to transfer the connectivity provided by the emergency PDU session in a subsequent separately sent PDN connection request message. The UE can then attempt to transfer more (non-emergency) PDU sessions.

[0049] In 4G networks, the MME or EPC may be unable to accept attachment requests for various reasons, such as network congestion or unavailability of other resources. In some current methods, if an attachment request is rejected, an ongoing emergency call using the connectivity provided by an emergency PDU session cannot be transferred to the network. Therefore, an ongoing emergency call may be terminated unintentionally or prematurely. This could put the user of the UE whose emergency call was terminated at risk.

[0050] When a cell via the 4G access network is attached to the EPC, and when there is a PDN connection with emergency bearer service (possibly in addition to, for example, non-emergency PDU sessions), the UE can determine that the 5G access network cell is or becomes more desirable. For example, when the UE is in idle mode with the 5GC, the UE may need to transfer ongoing connectivity provided by some or all of the PDN connections to the 5GC serving the 5G access network cell.

[0051] To transfer ongoing connectivity provided by an emergency bearer PDN connection from EPC to 5GC, the UE performs a registration procedure and subsequently sends a PDU session request message indicating the connectivity provided by the emergency bearer PDN connection. The UE may also attempt to transfer connectivity provided by one or more (non-emergency) PDN connections.

[0052] In 5G networks, due to various reasons (e.g., network congestion or other resource unavailability), the AMF or 5GC may be unable to accept registration requests. In some current methods, if a registration request is rejected, ongoing emergency calls using the connectivity provided by the PDN connection of the emergency bearer service cannot be transferred to the network. Therefore, ongoing emergency calls may be terminated undesirably or prematurely. This could put the user of the UE whose emergency call was terminated at risk.

[0053] The current procedures for transferring ongoing emergency calls from 5G to EPC or from EPC to 5GC do not adequately account for failure scenarios. While solutions exist for handling failure scenarios in the case of "fallback" from one system to another (i.e., before establishing an emergency call), solutions for preventing unexpected and undesirable termination of ongoing emergency calls during transfer from one system to another have not been considered. Another new aspect of this problem space is the scenario where a UE expects to transfer connectivity (including emergency connectivity) from 5GC to EPC, but the UE neglects to include a request for emergency connectivity in the attachment request sent to EPC.

[0054] In a first embodiment, when a UE has one or more PDU sessions to transfer from 5GS to EPS, the UE performs an attachment procedure with a first network including EPC. This network may reject the attachment request message (i.e., the first attachment request message) sent by the UE as a result of the attachment procedure. Since the network rejects the attachment, the UE may receive an attachment rejection message. The network sends the attachment rejection message and includes an EPS Mobility Management (EMM) reason value in the attachment rejection message. If the UE determines or detects that one or more PDU sessions include an emergency PDU session, or if the UE receives the attachment rejection message or depends on the (EMM) reason value in the attachment rejection message, the UE performs attachment to an emergency bearer service with a second network. The attachment request sent by the UE for the emergency bearer service includes a PDN connectivity request message (CONNECTIVITY REQUEST message), which requests activation of the default bearer corresponding to the default EPS bearer context of the emergency PDU session (i.e., the first PDN connectivity request message), and the request type of the PDN connectivity request is set to "Emergency Bearer Service Switching". The network can accept attachment requests sent by the UE due to emergency bearer service attachment, including requests to activate the default bearer corresponding to the default EPS bearer context of the emergency PDU session. Optionally, the attachment request sent by the UE during the attachment process also includes a PDN connectivity request message, which may have a request type set to "Emergency Bearer Service Handover". Both the first and second networks are part of a Public Land Mobile Network (PLMN). The second PLMN may be the first PLMN or a PLMN considered equivalent to the first PLMN, or the second PLMN may be neither the first PLMN nor considered equivalent. PLMNs are considered equivalent when their PLMN identities exist in an equivalent PLMN list. The UE may be configured with an equivalent PLMN list.

[0055] A PLMN may include, for example, a 5GC+ access network, or an EPC+ access network, or both a 5GC+ access network and an EPC+ access network. A PLMN operator operates one or more core networks and access networks.

[0056] In a first enhancement of the first embodiment, the attachment procedure performed with the second network is subject to the UE's lower layer or the UE's access (AS) layer instructing the NAS (or the UE's NAS layer) to support the emergency bearer service under limited service conditions. Alternatively, the attachment procedure performed with a network including the EPC is subject to the UE's lower layer or the UE's AS layer having already instructed the NAS (or the UE's NAS layer) to support the emergency bearer service under limited service conditions.

[0057] In the second enhancement of the first embodiment, if the EMM reason value in the attachment rejection message from the first network differs from one or more predefined EMM reason values, the UE performs attachment for emergency bearer service with the second network. One or more predefined EMM reason values ​​include, for example, #5 "IMEI not accepted". If the EMM reason value does not differ from one or more predefined EMM reason values, the UE performs one of the following: 1) enters the state EMM-DEREGISTERED.NO-IMSI; or 2) attempts to attach on the second network, which is different from the first network from which its EMM reason value was received. Both the first and second networks are part of a Public Land Mobile Network (PLMN). The second PLMN can be the first PLMN or a PLMN considered equivalent to the first PLMN, or the second PLMN can be neither the first PLMN nor considered equivalent. PLMNs are considered equivalent when their PLMN identities exist in an equivalent PLMN list. The UE can be configured with an equivalent PLMN list. If the attachment request sent by the UE due to the attachment procedure includes a first PDN connectivity request, the first network can set the EMM reason value to one of one or more predefined EMM reason values.

[0058] In the third enhancement of the first embodiment, in a shared network, the UE may attempt to register with one of a plurality of PLMNs in the shared network. In the shared network, when the UE receives an attach rejection message, before performing attach for emergency bearer service, the UE performs an attach procedure with another PLMN, including the EPC, which is one of a plurality of PLMNs in the shared network. This other PLMN may be equivalent to the PLMN from which the EMM cause value was received.

[0059] In the fourth enhancement of the first embodiment, when performing an attachment procedure with a network including an EPC, the UE should not request the use of Power Saving Mode (PSM) or Cellular Internet of Things (CIoT) optimization. The use of PSM or CIoT optimization may adversely affect emergency calls. This adverse effect could put the UE's user at risk. When performing an attachment procedure with a network including an EPC, the UE should not request the use of PSM or CIoT optimization, and the UE detects that one or more PDU sessions include emergency PDU sessions. When performing an attachment procedure with a network including an EPC, the UE should not request the use of PSM or CIoT optimization, and the attachment request sent by the UE due to the attachment procedure includes a PDN connectivity request message.

[0060] In the fifth enhancement of the first embodiment, the UE detects that it has received an EMM reason code set to #19, indicating an EPS Session Management (ESM) failure. The ESM failure indicates that the network detected a failure while inspecting or processing a PDN connectivity request message included in the first attach request message. Based on this detection, instead of first performing an attach procedure with a second network for emergency bearer services (as described in the first embodiment), the UE performs another attach procedure with a network including the EPC. The network including the EPC can be equivalent to the first network. The UE sends an attach request message due to the other attach procedure, which includes the first PDN connectivity request message.

[0061] If another attachment process fails, the UE can perform an attachment for emergency bearer services with a second network and continue as described in the first embodiment.

[0062] Figure 2 This is message flow diagram 200 for an embodiment of preserving an emergency call during a handover from 5GC to EPC. During an ongoing emergency PDU session 220 between UE 205 and 5GC 210, UE 205 may determine to hand over to EPC 215. UE 205 sends an attachment message to EPC 215 at step 230 and receives an attachment rejection message from EPC 215 at step 240. Attachment may be rejected for various reasons, such as EPC 215 being overloaded. In response to the attachment rejection, UE 205 may determine or detect the existence of an ongoing emergency call. In response to determining an ongoing emergency call, UE 205 may submit a second attachment message at step 250 indicating that the emergency session needs to be transferred. EPC 215 may then respond with a response indicating that the second attachment is acceptable (at step 260), or with a response indicating that the second attachment is unacceptable (the second attachment is not shown in the diagram). The second attachment may include a PDN connection request from UE 205 to EPC 215 to transfer an emergency session. The transfer of the emergency session for the ongoing emergency call has been successful when UE 205 receives the ACTIVATE DEFAULT EPS BEARERCONTEXT REQUEST message. Optionally, in step 270, if the second attachment is unacceptable, UE 205 may send an emergency attachment including a request to transfer connectivity provided by the ongoing emergency PDU session. If response 260 is received, another optional transmission in step 280 may be a PDN connection request from UE 205 to EPC 215 to transfer the emergency session. The second attachment message may be an emergency attachment message.

[0063] In the second embodiment, when a UE has one or more PDN connections to transfer from EPS to 5GS, the UE performs an (initial) registration procedure with a first network including 5GC, and the 5GC network may reject registration requests sent by the UE due to the registration procedure. The 5GC network sends a registration rejection message to the UE. The 5GC network includes a 5GMM reason value in the registration rejection message. The UE receives the registration rejection message. If the UE determines that one or more PDN connections include PDN connections for the emergency bearer service, and the UE receives the registration rejection message, the UE performs emergency service registration with a second network. The UE sends a registration request message for the emergency service to the second network. If the second network accepts the emergency service registration request, the second network sends a registration acceptance message to the UE. When the UE receives the registration acceptance message, the UE transfers the PDN connection for the emergency bearer service by sending a PDU session request message with the request type set to "existing emergency PDU session". When the UE sends the registration request, the UE includes a follow-up request indicator set to "follow-up request pending" in the registration request. Both the first and second networks are part of the PLMN. The second PLMN can be the first PLMN or a PLMN considered equivalent to the first PLMN, or the second PLMN can be neither the first PLMN nor considered equivalent. PLMNs are considered equivalent when their PLMN identities exist in a list of equivalent PLMNs. UEs can be configured with a list of equivalent PLMNs.

[0064] A PLMN may include, for example, a 5GC+ access network, or an EPC+ access network, or both a 5GC+ access network and an EPC+ access network. The PLMN operator operates one or more core networks and access networks. In the first enhancement of the second embodiment, registration with the second network for emergency services is subject to the UE's lower layer or the UE's AS layer instructing the NAS (or the UE's NAS layer) that the network supports emergency bearer services in a limited service state. Alternatively, if one or more PDN connections include PDN connections for emergency bearer services, then registration with the network including the 5GC is subject to the UE's lower layer or the UE's AS layer having already instructed the NAS (or the UE's NAS layer) that the first network supports emergency bearer services in a limited service state.

[0065] In the second enhancement of the second embodiment, if the 5GMM cause value differs from one or more predefined 5GMM cause values, the UE performs emergency service registration with a second network. One or more predefined 5GMM cause values ​​include, for example, #5 "PEI not accepted". If the 5GMM cause value does not differ from one or more predefined 5GMM cause values, the UE performs one of the following: 1) enters the state 5GMM-DEREGISTERED.NO-SUPI; or 2) attempts to register on a third network, which is different from the first network from which its 5GMM cause value was received. Both the first and third networks are part of a Public Land Mobile Network (PLMN). The third PLMN can be a PLMN considered equivalent to the first PLMN. PLMNs are equivalent when their PLMN identities exist in an equivalent PLMN list. The UE can be configured with an equivalent PLMN list. If the registration request sent by the UE due to the registration process includes an indication that the UE needs to transfer the emergency session, the network can set the 5GMM cause value to one of one or more predefined 5GMM cause values. The UE can indicate that it needs to transfer an emergency session by using the 5GS registration type to indicate that the registration request is for transferring an emergency session.

[0066] In the third enhancement of the second embodiment, in a shared network, the UE may attempt to register with one of a plurality of PLMNs in the shared network. In the shared network, when the UE receives a registration rejection message, and before performing emergency bearer service registration, the UE performs a registration process with a fourth PLMN, including the 5GC, which is one of a plurality of PLMNs in the shared network. The fourth PLMN may be equivalent to a PLMN from which a registration rejection message was received or from which a PLMN was received.

[0067] In the fourth enhancement of the second embodiment, when performing a registration procedure with a network including 5GC, the UE should not request the use of PSM or CIoT optimization. When performing a registration procedure with a network including 5GC, the UE should not request the use of PSM or CIoT optimization, and the UE detects that one or more PDU sessions include emergency PDU sessions. When performing a registration procedure with a network including 5GC, the UE should not request the use of PSM or CIoT optimization, and the registration request sent by the UE due to the registration procedure includes an indication that the UE needs to transfer the emergency session.

[0068] Figure 3This is message flow diagram 300 for an embodiment of preserving emergency calls during a handover from EPC to 5GC. During an ongoing PDN connection of Emergency Bearer Service 320 between UE 305 and EPC 310, UE 305 may determine to hand over to 5GC 315. UE 305 sends a registration message to 5GC 315 in step 330 and receives a registration rejection message from 5GC 315 in step 340. Attachment may be rejected for various reasons, such as 5GC 315 being overloaded. In response to the registration rejection, in step 350, UE 305 may determine that an ongoing emergency call exists and submit a second registration message because an emergency session needs to be transferred. 5GC 315 can then respond with a response (a response to the second registration message) indicating that registration is acceptable (in step 360), or a response indicating that registration is unacceptable (the second registration is not shown in the diagram). Upon receiving a response indicating that registration is acceptable (a response to the second registration message), UE 305 sends a PDU session establishment request from UE 305 to 5GC 315 in step 380 to transfer the emergency session. The PDU session establishment request may include an indication that the emergency session is an existing emergency session. This indication may indicate that the existing emergency session will be transferred. Optionally, in step 370, if the second registration is unacceptable, the UE may send an emergency registration. In step 380, if the second registration is unacceptable (360) or the emergency registration (370) is acceptable, the UE transfers the emergency session.

[0069] In the third embodiment, when a UE has one or more PDU sessions to transfer from 5GS to EPS, and one or more PDU sessions include emergency PDU sessions, the UE performs an attachment procedure with the network including the EPC. The network can accept an attachment request message sent by the UE due to the attachment procedure. Since the network accepts the attachment, the UE can receive an attachment acceptance message. The network sends the attachment acceptance message and may include an indication that attachment for emergency services only is accepted. Because the UE receives the indication that attachment for emergency services only is accepted, the UE avoids transferring non-emergency PDU sessions. If the attachment request message sent by the UE does not include a PDN connectivity request message requesting activation of the default bearer corresponding to the default EPS bearer context of the emergency PDU session, or if the attachment request message sent by the UE includes a different PDN connectivity request message, the UE can send a separate PDN connectivity request message requesting activation of the default bearer corresponding to the default EPS bearer context of the emergency PDU session. After receiving the indication that attachment for emergency services only is accepted, the separate PDN connectivity request message is sent.

[0070] In the first enhancement of the third embodiment, the PDN connectivity request message can be included in the attachment request sent by the UE. Alternatively, the UE can include a different indication in the attachment request indicating that the UE intends to transfer an emergency PDU session (after sending the attachment request). The UE can transfer the emergency PDU session after sending the attachment request. The emergency PDU session will be transferred using a PDN connectivity request message with the request type set to "Switchover of Emergency Bearer Service". This PDN connectivity request message will be sent independently. The network, for example, determines whether to include an indication that attachment for emergency service is accepted only in the attachment acceptance message based on receiving an indication that the UE intends to transfer the emergency PDU session after sending the attachment request.

[0071] Figure 4 This is a message flow diagram 400 of an embodiment for preserving emergency calls with reduced messaging during a handover from 5GC to EPC. During an ongoing emergency PDU session 420 between UE 405 and 5GC 410, UE 405 may determine to hand over to EPC 415. UE 405 may send an attach message at step 430 indicating the need to transfer the emergency session to EPC 415. EPC 415 may send a response at step 440 indicating acceptance of the attach for the emergency session. Optionally, in response to the acceptance of the attach for the emergency session, at step 450, UE 405 may send a PDN connection request to EPC 415 to transfer the emergency session.

[0072] In the fourth embodiment, when a UE has one or more PDN connection sessions to migrate from EPS to 5GS, and one or more PDN connection sessions include PDN connection sessions for emergency bearer services, the UE performs a registration procedure with the network including 5GS. The network can accept a registration message sent by the UE as a result of the registration procedure. Since the network accepts the registration, the UE can receive a registration acceptance message. The network sends the registration acceptance message and may include an indication that the registration for emergency services only has been accepted. Because the UE receives the indication that the registration for emergency services only has been accepted, the UE avoids migrating non-emergency PDN connections. After receiving the indication that the registration for emergency services only has been accepted, a PDU session establishment request message corresponding to the default EPS bearer context of the emergency service PDN connection is sent.

[0073] In the first enhancement of the fourth embodiment, the UE may include an indication in the registration request that the UE intends to transfer the PDN connection for the emergency bearer service. After sending the registration request, the UE transfers the PDN connection for the emergency bearer service. The PDN connection for the emergency bearer service is transferred by using a PDU session establishment request message with the request type set to "existing emergency PDU session". The network, for example, determines whether to include an indication that registration for emergency services is accepted only in the registration acceptance message based on receiving the indication that the UE intends to transfer the PDN connection for the emergency bearer service.

[0074] Figure 5 This is a message flow diagram 500 illustrating an embodiment of preserving emergency calls with reduced messaging during a handover from EPC to 5GC. During an ongoing PDN connection 520 for emergency bearer service between UE 505 and EPC 510, UE 505 may determine to hand over to 5GC 515. In step 530, UE 505 sends a registration message indicating the need to transfer the emergency session. In step 540, 5GC 515 can then respond with a response indicating that the registration is acceptable for the emergency session. In step 550, in response to the acceptance of the registration for the emergency session, UE 505 may send a PDU session establishment request to 5GC 515 to transfer the emergency session.

[0075] In the fifth embodiment, emergency calls are preserved with reduced messaging during the handover from 5GC to EPC as follows: During an ongoing emergency PDU session between the UE and 5GC, the UE may determine to hand over to the EPC. The UE may have one or more additional PDU sessions to transfer from 5GS to EPS. The UE may send an emergency attach message indicating that the emergency session to be transferred to the EPC is to be transferred. The EPC may send a response indicating that the attach is accepted. The EPC may indicate in the message that attaches for non-emergency purposes are also accepted. The EPC may determine to indicate that attaches for non-emergency purposes are accepted based on receiving the indication that the emergency session is to be transferred. Optionally, since the message indicating that attaches for non-emergency purposes are accepted has been received, the UE may continue and transfer any PDU session in one or more additional PDU sessions.

[0076] In the sixth embodiment, emergency calls are preserved with reduced messaging during the handover from EPC to 5GC as follows: During ongoing use of the PDN connection for the emergency bearer service between the UE and 5GC, the UE may determine to hand over to 5GC. The UE may have one or more additional PDN connection sessions to transfer from EPS to 5GC. The UE may send an emergency registration message. 5GC may send a response indicating registration acceptance. 5GC may indicate in the message that attachments for non-emergency purposes are also accepted. Based on the message also received at the UE indicating that attachments for non-emergency purposes are accepted, in addition to transferring the PDN connection for the emergency bearer service, the UE may continue and transfer any PDU sessions from one or more additional PDN connection sessions.

[0077] In the enhancement of the sixth embodiment, emergency calls are retained with reduced message passing during the handover from EPC to 5GC as follows: The UE can indicate in the emergency registration message that an existing emergency session is to be transferred or that an emergency session exists. The 5GC can determine whether to accept registration for non-emergency purposes based on receiving the indication that an existing emergency session is to be transferred or that an emergency session exists.

[0078] In the seventh embodiment, when performing an attachment procedure with a network including an EPC and due to the transfer of one or more PDU sessions of a certain type to the EPC, the UE should not request the use of PSM or CIoT optimization. The use of PSM or CIoT optimization may adversely affect emergency calls. This adverse effect may put the UE's user at risk. Specifically, when performing an attachment procedure with a network including an EPC and the UE detects that one or more PDU sessions include an emergency PDU session, the UE should not request the use of PSM or CIoT optimization. When performing an attachment procedure with a network including an EPC, the UE should not request the use of PSM or CIoT optimization, and the attachment request intention sent by the UE due to the attachment procedure is followed by the first PDN connectivity request message. That is, the first PDN connectivity request message will be sent independently. Specifically, the attachment message does not include a PDN connectivity request message with the request type set to "Emergency Bearer Service Switching".

[0079] In the eighth embodiment, retaining an emergency call during a handover from the source core network to the target core network includes the UE verifying whether the target network supports the handover of an existing emergency session. The target core network may include either an EPC or a 5GC. Verifying whether the target network supports the handover includes: if the target core network is an EPC, sending an indication of the request type flag "handover" regarding the UE's support for PDN connectivity requests during the attach procedure. If the target core network is a 5GC, verifying whether the target network supports the handover includes verification performed during registration and registration update. If the UE determines that the target core network does not support the handover, the UE selects another PLMN, which is an equivalent PLMN, or the UE attempts to transfer the emergency call to another Internet Protocol (IP-CAN) connection. IP-CAN is an access network that provides IP connectivity. Alternatively, the UE attempts to transfer the emergency call to a circuit-switched domain.

[0080] A UE in dual-registration mode, concurrently attached or registered in both EPC and 5GS, and detecting or establishing an active emergency session in one of the two systems, updates its registration information in the other system. The UE anticipates the active emergency session may transfer to the other system, therefore updating its registration information in the other system as well. Updating registration information includes disabling the use of PSM or disabling the use of CIoT optimization. Updating registration information also includes performing either a registration update or a tracking area update depending on whether the other system is EPS or 5GS. Performing either a registration update or a tracking area update involves sending a NAS message to the core network. Executing a registration update involves sending a registration request message to the 5GC. Executing a tracking area update involves sending a tracking area update request message to the EPC.

[0081] The above embodiments can be combined depending on the network and / or UE. Furthermore, if switching emergency calls is not required, certain steps can be omitted from the embodiments.

[0082] Figure 6 This is a proposed change 600 to Section 5.3.11 of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0083] A UE may request to use Power Saving Mode (PSM) during an attachment or tracking area update process. The UE should not request to use PSM during the following periods:

[0084] - Attachments for emergency bearer service procedures; or

[0085] - The attachment process is not set to "EPS Emergency Attach", and:

[0086] a) Used to initiate a PDN connection for the emergency bearer service; or

[0087] b) Transmission of PDN connectivity request messages with the request type set to "handover" when the UE intends to send a standalone PDN connectivity request message with the request type set to "handover of emergency bearer service";

[0088] - Used to initiate the tracking area update process for PDN connections to emergency bearer services;

[0089] - Tracking area update procedure when the UE has a PDN connection established for emergency bearer service; or

[0090] - Attachment used for accessing RLOS.

[0091] Figure 7 This is a proposed change 700 to Section 5.3.15 of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0092] In NB-S1 mode, when requesting the use of CIoT EPS optimization, the UE will not:

[0093] - Request an attachment for the emergency bearer service procedure;

[0094] - Request a PDN connection attachment process where the attachment type is not set to "EPS Emergency Attach"; and:

[0095] a) Used to initiate a PDN connection for the emergency bearer service; or

[0096] b) Transmission of PDN connectivity request messages with the request type set to "handover" when the UE intends to send a standalone PDN connectivity request message with the request type set to "handover of emergency bearer service";

[0097] - Indicates voice domain preferences and UE usage settings; or

[0098] - Requesting attachment for accessing RLOS.

[0099] Figure 8 This is a proposed change 800 to Section 5.5.1.2.5A of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0100] If an attachment request for emergency bearer service fails or is rejected due to receiving an attachment rejection, the UE continues to notify the upper layer of the access network failure.

[0101] Note: Notifying the upper layer may result in the upper layer requesting the establishment of a CS emergency call (if it has not already been attempted in the CS domain), transfer to a non-3GPP access, or other implementation-specific mechanisms, such as the procedures specified in 3GPP TS 24.229 that may result in the emergency call being attempted or transferred to another IP-CAN…

[0102] In a shared network, upon receiving an attach denial message, the UE shall perform the actions described in subsection 5.5.1.2.5, and shall:

[0103] a) Notify the upper level that the process failed; or

[0104] b) If the attach request message does not include a PDN connectivity request message with the request type set to "Emergency bearer service switchover", or if the attach request message does include a PDN connectivity request message with the request type set to "Emergency bearer service switchover" and the other PLMN is an equivalent PLMN, then attempt to attach the emergency bearer service to the other PLMN in the shared network.

[0105] In a shared network, if an attachment request for emergency bearer service fails due to an exception condition a) in subsection 5.5.1.2.6, the UE shall perform the actions described in subsection 5.5.1.2.6, and shall:

[0106] a) Notify the upper layer of network access failure; or

[0107] b) If the attach request message does not include a PDN connectivity request message with the request type set to "Emergency bearer service switchover", or if the attach request message does include a PDN connectivity request message with the request type set to "Emergency bearer service switchover" and the other PLMN is an equivalent PLMN, then attempt to attach the emergency bearer service to the other PLMN in the shared network.

[0108] In a shared network, if an attachment request for emergency bearer service fails due to an exception (b), (c), or (d) in subsection 5.5.1.2.6, the UE shall perform the actions described in subsection 5.5.1.2.6, and shall:

[0109] a) Notify the upper level that the process failed; or

[0110] b) If the attach request message does not include a PDN connectivity request message with the request type set to "Emergency bearer service switchover", or if the attach request message does include a PDN connectivity request message with the request type set to "Emergency bearer service switchover" and the other PLMN is an equivalent PLMN, then attempt to attach the emergency bearer service to the other PLMN in the shared network.

[0111] Figure 9 This is a proposed change 900 to Section 5.5.1.2.5B of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0112] If the network cannot accept an attachment request that includes a PDN connectivity request message with the request type set to "urgent" and the attachment type not set to "EPS urgent attachment," the UE should perform the procedure described in subsection 5.5.1.2.5. Then, if the UE is in the same selected PLMN where the last attachment request was attempted, the UE should:

[0113] a) Notify the upper level that the process failed; or

[0114] b) Attempt to attach the emergency bearer service to the EPS, including the PDN connectivity request message.

[0115] If the network cannot accept a PDN connectivity request message with the request type set to "Emergency Bearer Service Switching" and an attachment request with the attachment type not set to "EPS Emergency Attachment," the UE will perform the procedure described in subsection 5.5.1.2.5. Then, if the UE is in the same selected PLMN or an equivalent PLMN where the last attachment request was attempted, the UE should attempt EPS attachment for emergency bearer service, including the PDN connectivity request message.

[0116] If an attachment request for initiating an emergency bearer service for which the attachment type is not set to "EPS Emergency Attach" fails due to an exception condition a) in section 5.5.1.2.6, the UE shall perform the actions described in section 5.5.1.2.6 and notify the upper layer of the access network failure.

[0117] If an attachment request, including a PDN connectivity request message with the request type set to "urgent" and the attachment type not set to "EPS urgent attachment," fails due to an exception (b), (c), or (d) in subsection 5.5.1.2.6, the UE shall perform the procedure described in subsection 5.5.1.2.6. Then, if the UE is in the same selected PLMN where the last attachment request was attempted, the UE shall:

[0118] a) Notify the upper level that the process failed; or

[0119] b) Attempt to attach the emergency bearer service to the EPS, including the PDN connectivity request message.

[0120] If an attachment request for a PDN connection to an emergency bearer service whose initiating attachment type is not set to "EPS Emergency Attach" fails due to an exception in subsection 5.5.1.2.6 (b), (c), (d), or (o), the UE shall perform the procedure described in subsection 5.5.1.2.6. Then, if the UE is in the same selected PLMN or an equivalent PLMN where the last attachment request was attempted, the UE shall attempt an EPS attachment for the emergency bearer service that includes a PDN connectivity request message.

[0121] Figure 10 This is a proposed change 1000 to Section 5.5.1.2.5B1 of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0122] If the network cannot accept an attachment request that includes a PDN connectivity request message with the request type set to "Switchover", and the UE also intends to transfer an emergency PDU session, the UE should attempt to attach an EPS for the emergency bearer service that includes a PDN connectivity request message with the request type set to "Switchover of emergency bearer service" for the emergency PDU session.

[0123] If an attach request that includes a PDN connectivity request message with the request type set to "Switchover" fails due to an exception condition a) in subsection 5.5.1.2.6, and the UE intends to transfer the emergency PDU session, the UE should attempt to attach an EPS message that includes a PDN connectivity request message with the request type set to "Switchover of emergency bearer service" for the emergency PDU session.

[0124] If the attach request, including a PDN connectivity request message with the request type set to "Switchover", fails due to the exceptions b), c), d), or o) in subsection 5.5.1.2.6, and the UE intends to transfer the emergency PDU session, if

[0125] - If an EMM reason set to #19 "ESM Failure" is received, the UE should attempt EPS attachment with an attachment request message that includes a PDN connectivity request message with the request type set to "Emergency Bearer Service Switching" for an emergency PDU session; and

[0126] Otherwise, the UE should attempt to attach to the EPS of the emergency bearer service, which includes an attach request message for the PDN connectivity request message whose request type is set to “Emergency Bearer Service Switching” for an emergency PDU session.

[0127] Figure 11A and Figure 11B This is a proposed change 1100 to Section 5.5.1.2.6 of 3GPP TS24.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0128] The following anomalies can be identified:

[0129] a) Access is denied because the network rejects the connection due to access class restrictions, EAB, ACDC, or NAS signaling, and no "extended wait time" is received from the lower layer.

[0130] In WB-S1 mode, if access for originating signalling is prohibited, the attachment procedure should not be initiated. The UE remains in the current serving cell and the normal cell reselection procedure is applied. The attachment procedure will initiate as soon as possible, i.e., when access for originating signalling is authorized on the current cell, or when the UE moves to a cell where access for originating signalling is authorized…

[0131] b) Lower-layer failure or NAS signaling connection release before the Attach Accept or Attach Reject message is received, where no "Extended Waiting Time" and no "Extended Waiting Time CP Data" are received from the lower layer.

[0132] The attachment process should be aborted, and the UE should proceed as described below.

[0133] c) T3410 timeout

[0134] The UE should abort the attachment procedure and proceed as follows. The NAS signaling connection (if any) should be released locally.

[0135] d) Attached rejections, other EMM cause values ​​besides those handled in section 5.5.1.2.5, and the cases of EMM cause values ​​#22, #25 and #31 that are considered anomalous according to section 5.5.1.2.5.

[0136] Upon receiving EMM reason #19 "ESM Failure", if the UE is not configured with low NAS signaling priority and the ESM reason value received in the PDN connectivity rejection message is not #54 "PDN connection does not exist", the UE can set the attach attempt counter to 5. Subsequently, if the UE needs to retransmit the attach request message to request PDN connectivity to a different APN, the UE can stop T3411 or T3402 (if running) and send the attach request message. If the UE needs to attempt EPS attach to request the transfer of the PDN connection for the emergency bearer service via a PDN connectivity request message with the request type set to "Emergency Bearer Service Switching", the UE should stop T3411 or T3402 (if running) and send the attach request message.

[0137] Note 3: When an EMM reason #19 "ESM failure" is received, coordination is required between the EMM and ESM sublayers in the UE to determine whether to set the attachment attempt counter to 5.

[0138] If the attachment request is neither for an emergency bearer service nor for initiating a PDN connection for an emergency bearer service whose attachment type is not set to "EPS Emergency Attach", then after receiving EMM reasons #95, #96, #97, #99 and #111, the UE should set the attachment attempt counter to 5.

[0139] The UE should proceed as follows...

[0140] o) Timer T3447 is running.

[0141] The UE should not initiate the attachment procedure unless:

[0142] The UE is configured to use AC11-15 in the selected PLMN;

[0143] The UE attempts to attach emergency bearer service; or

[0144] The UE attempts to attach without a PDN connection request.

[0145] The UE remains in the current serving cell and the normal cell reselection procedure is applied. When timer T3447 expires, the attach request procedure is initiated if still required.

[0146] For cases b, c, d, l, la, and m, if timer T3410 is still running, it should be stopped. For cases b, c, d, and l, when "Extended Waiting Time" is ignored, and for la, when "Extended Waiting Time CP Data" is ignored, if the attachment request is neither for an emergency bearer service nor for initiating a PDN connection for an emergency bearer service whose attachment type is not set to "EPS Emergency Attachment", the attachment attempt counter should be incremented unless it has already been set to 5.

[0147] If the attachment attempt counter is less than 5...

[0148] For cases b, c, d, and l, when the "Extended Waiting Time" is ignored, and for la, when the "Extended Waiting Time CP Data" is ignored, if the attach request is neither for an emergency bearer service nor for an PDN connection initiating an attach service whose attach type is not set to "EPS Emergency Attach," then timer T3411 is started and its state is changed to EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH. When timer T3411 expires, the attach process should be restarted if the ESM sublayer still requires it.

[0149] Figure 12 This is another proposed change 1200 to Section 5.5.1.2.6 of 3GPP TS24.501. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0150] Upon receiving a registration rejection message or a failed registration request, the UE shall perform the actions described in subsection 5.5.1.2.5 and add the following:

[0151] The UE should notify the upper layer that the process has failed.

[0152] Note: This may cause upper-layer requests to be redirected to non-3GPP access or to implement specific mechanisms. For example, the procedure specified in 3GPP TS24.229 may cause an emergency call to be attempted to go to another IP-CAN...

[0153] In a shared network, upon receiving a registration rejection message, the UE shall perform the actions described in subsection 5.5.1.2.5, and shall:

[0154] a) Notify the upper level that the process failed; or

[0155] b) If the registration request message is not a PDU session establishment message with the request type set to "existing emergency PDU session" or the registration request message is a PDU session establishment message with the request type set to "existing emergency PDU session" and the other PLMN is an equivalent PLMN, then attempt to perform PLMN selection in the shared network and initiate initial registration for emergency services to the selected PLMN.

[0156] In a shared network, if the initial registration request for emergency services fails due to an abnormal situation, the UE shall perform the actions described in subsection 5.5.1.2.7, and shall:

[0157] a) Notify the upper level that the process failed; or

[0158] b) If the registration request message is not a PDU session establishment message with the request type set to "existing emergency PDU session" or the registration request message is a PDU session establishment message with the request type set to "existing emergency PDU session" and the other PLMN is an equivalent PLMN, then attempt to perform initial registration for emergency services to the other PLMN in the shared network.

[0159] Figure 13 This is a proposed change 1300 to Section 5.5.1.2.6A of 3GPP TS24.501. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0160] If the network cannot accept an initial registration request for a PDU session establishment message whose request type is set to "Initial Urgent Request" and whose 5GS registration type IE is set to "Initial Registration," the UE should perform the procedure described in subsection 5.5.1.2.5. Then, if the UE is in the same selected PLMN where the last initial registration request was attempted, the UE should:

[0161] a) Notify the upper level that the process failed; or

[0162] b) Attempt initial registration for emergency services.

[0163] If the network cannot accept an initial registration request for an emergency service PDU session whose initiating 5GS registration type IE is set to "Initial Registration," and the PDU session needs to be established due to the switching of an existing PDN connection for the emergency bearer service, the UE should perform the procedure described in subsection 5.5.1.2.5. Then, if the UE is in the same selected PLMN or equivalent PLMN where the last initial registration request was attempted, the UE should attempt initial registration for the emergency service.

[0164] If the initial registration request for an emergency service PDU session for which the 5GS registration type IE is set to "Initial Registration" fails due to an exception condition c), d), or e) in subsection 5.5.1.2.7, and the PDU session does not need to be established due to the switching of an existing PDN connection for the emergency bearer service, then the UE should perform the actions described in subsection 5.5.1.2.7. Then, if the UE is in the same selected PLMN where the last initial registration request was attempted, then the UE should:

[0165] a) Notify the upper level that the process failed; or

[0166] b) Attempt initial registration for emergency services.

[0167] If an initial registration request for an emergency service PDU session for which the 5GS registration type IE is set to "Initial Registration" fails due to an exception condition (c), (d), or (e) in subsection 5.5.1.2.7, and the PDU session needs to be established due to a switchover of an existing PDN connection for the emergency bearer service, the UE should perform the procedure described in subsection 5.5.1.2.7. Then, if the UE is in the same selected PLMN or an equivalent PLMN where the last initial registration request was attempted, the UE should attempt initial registration for the emergency service.

[0168] Figure 14A , Figure 14B and Figure 14C This is a proposed change 1400 to Section 5.5.1.2.7 of 3GPP TS25.301. Proposed deletions are indicated by strikethrough text, and proposed additions are indicated by underlined text. The proposed change may support various embodiments of emergency calls described herein.

[0169] The following anomalies can be identified:

[0170] a) Timer T3346 is running.

[0171] The UE should not initiate the initial registration process unless:

[0172] 1) The UE is a UE configured for high-priority access in the selected PLMN;

[0173] 2) The UE needs to perform the initial registration process for emergency services;

[0174] 3) The UE receives a "Cancel Registration Request" message with a "Re-registration Required" indication; or

[0175] 4) The upper layer requests the UE in NB-N1 mode to send user data related to the abnormal event, and:

[0176] UEs are allowed to use exception data reports, such as the ExceptionDataReportingAllowed leaf of the NAS configuration management object or the USIM file EF. NASCONFIG ;and

[0177] Timer T3346 is not started when the N1 NAS signaling connection is established with the RRC establishment reason set to "mo-ExceptionData".

[0178] The UE remains in the current serving cell and applies the normal cell reselection process.

[0179] Note 1: If the UE needs to initiate a registration process for initial registration while timer T3346 is running, regardless of whether timer T3346 was started due to an abnormal situation or an unsuccessful situation, it is considered an abnormal situation.

[0180] The lower layer indicated that the access attempt was blocked.

[0181] The UE should not initiate the initial registration process. The UE should remain in the current serving cell and apply the normal cell reselection process. Receiving an access denied indication should not trigger the selection of another core network type (EPC or 5GCN).

[0182] When the prohibition of the access category associated with the access attempt is mitigated by the lower layer, the initial registration process is initiated if it is still required.

[0183] ba) The lower layer indicates that access prohibition applies to all access categories except categories 0 and 2, and the access category associated with the access attempt is not 0 or 2.

[0184] If the registration request message has not yet been sent, the UE should proceed as specified for case b. If the registration request message has already been sent, the UE should proceed as specified for case e, and additionally, if the lower layer indicates that the prohibition of the access category associated with the access attempt has been mitigated, the initial registration process is initiated if still required.

[0185] c) T3510 timeout.

[0186] The UE should abort the initial registration process, and if the initial registration request is neither for an emergency service nor for a PDU session of an emergency service whose request type is set to "existing emergency PDU session", the NAS signaling connection (if any) should be released locally. The UE should proceed as follows.

[0187] d) Registration rejection messages, other 5GMM cause values ​​besides those handled in section 5.5.1.2.5, and the cases of 5GMM cause values ​​#11, #22, #31, #72, #73, #74, #75, #76 and #77 that are considered anomalous cases according to section 5.5.1.2.5.

[0188] If the registration request is not an initial registration request for an emergency service, nor is it an initial registration request for a PDU session of an emergency service whose request type is set to "existing emergency PDU session", then after receiving 5GMM reasons #95, #96, #97, #99 and #111, the UE should set the registration attempt counter to 5.

[0189] The UE should proceed as described below.

[0190] e)……

[0191] l) Timer T3447 is running.

[0192] The UE should not initiate the registration process for initial registration by setting the follow-up request indicator to "follow-up request pending" unless:

[0193] 1) The UE is a UE configured for high-priority access in the selected PLMN; or

[0194] 2) The UE needs to perform the initial registration process for emergency services.

[0195] The UE remains in the current serving cell and applies the normal cell reselection procedure. When timer T3447 expires, the initial registration procedure is initiated if still required.

[0196] For cases c, d, and e, the UE should proceed as follows:

[0197] If timer T3510 is still running, it should be stopped.

[0198] If the registration process is neither an initial registration for an emergency service nor for establishing an emergency PDU session whose registration type is not set to "emergency registration", the registration attempt counter should be incremented unless it has already been set to 5.

[0199] If the registration attempt counter is less than 5:

[0200] If the initial registration request is not for emergency services, timer T3511 is started, and the state change is set to 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION. When timer T3511 expires, the initial registration process should be restarted if still required.

[0201] If the registration attempt counter equals 5:

[0202] The UE should delete the 5G-GUTI, TAI list, last visited registered TAI, equivalent PLMN list (if any), and ngKSI, start timer T3502, and set the 5GS update status to 5U2 NOT UPDATED. The status is changed to 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION or optionally to 5GMM-DEREGISTERED.PLMN-SEARCH, depending on the PLMN selection.

[0203] If the process is performed via 3GPP access and the UE is operating in single-registration mode:

[0204] When the EPS attachment process fails and the attachment attempt counter equals 5, the UE should additionally handle the EMM parameters specified in 3GPP TS24.301 for abnormal situations: EPS update status, EMM status, 4G-GUTI, TAI list, last visited registered TAI, equivalent PLMN list, and eKSI; and

[0205] The UE should attempt to select the E-UTRAN radio access technology and perform the appropriate EMM-specific procedures. Additionally, the UE may disable the N1 mode capability specified in section 4.9.

[0206] The process for a UE to transfer one or more connections from a first access network connected to a first core network to a second access network connected to a second core network includes: the UE performing a first registration procedure with the second core network and sending a registration request message; the UE receiving a registration rejection message from the second core network; and subject to one or more conditions, after receiving the registration rejection message, the UE performing a second registration procedure with the second core network and sending an emergency registration request message or another registration request message, wherein one or more conditions include detecting an emergency connection among the one or more connections.

[0207] In one embodiment, registration includes attachment.

[0208] In one embodiment, at least one of the attachment request message, another attachment request message, and an emergency attachment request message includes a connection request message with information corresponding to an emergency connection, and the connection request message includes an emergency handover indication.

[0209] In one embodiment, the registration rejection message includes a reason code, wherein the reason code can be set to one of a plurality of reason codes, and at least one of the plurality of reason codes indicates one of the International Mobile Equipment Identifiers (IMEIs) and a Permanent Device Identifier (PEI) is not accepted.

[0210] In one embodiment, the second condition of one or more conditions includes detecting that the reason code is not set to indicate that one of the IMEI and PEI is not accepted.

[0211] In one embodiment, after detecting that the reason code is set to indicate that one of the IMEI and PEI is not accepted and determining that the UE will need to provide one of the IMEI and PEI as part of the emergency registration process, the UE, instead of performing the emergency attachment process, enters one of the states EMM-DEREGISTERED.NO-IMSI and 5GMM-DEREGISTERED.NO-SUPI.

[0212] In one embodiment, a third condition among one or more conditions includes detecting that a timer is running.

[0213] The process for a UE to transfer one or more connections from a first access network connected to a first core network to a second access network connected to a second core network includes: the UE performing a first registration procedure with the second core network; the UE detecting a first condition, the first condition including one of prohibiting access and the second access network rejecting the establishment of a NAS signaling connection; the UE detecting a second condition, the second condition including whether there is an emergency connection among the one or more connections; and subject to the first and second conditions, the UE performing a second registration procedure with the second core network and sending a registration request message.

[0214] If the second core network includes an MME, then the second registration request message includes a request to transfer an existing emergency connection.

[0215] If the second core network includes AMF, then the second registration request message includes emergency registration.

[0216] The various methods or operations described in this article can be implemented by network elements. About Figure 15 An example network element is shown. Figure 15 In this context, network element 3110 includes processor 3120 and communication subsystem 3130, wherein processor 3120 and communication subsystem 3130 cooperate to perform the previously described methods or operations.

[0217] Furthermore, the various methods or operations described herein can be implemented by communication devices (e.g., UE, network node, TE, etc.). See below for reference. Figure 16 Examples of communication devices are described. Communication device 3200 may include a two-way wireless communication device with voice and data communication capabilities. In some embodiments, voice communication capability is optional. Communication device 3200 may have the ability to communicate with other computer systems via the Internet. Depending on the exact functionality provided, communication device 3200 may be referred to, for example, as a data messaging transceiver, a two-way pager, a wireless email device, a cellular phone with data messaging capabilities, a wireless Internet device, a wireless device, a smartphone, a mobile device, or a data communication device.

[0218] In enabling bidirectional communication, the communication device 3200 may include a communication subsystem 3211, which includes a receiver 3212 and a transmitter 3214, as well as associated components such as one or more antenna elements 3216 and 3218, a local oscillator (LO) 3213, and a processing module such as a digital signal processor (DSP) 3220. The specific design of the communication subsystem 3211 may depend on the communication network 3219 in which the communication device 3200 is to operate.

[0219] Network access can also vary depending on the type of communication network 3219. In some networks, network access is associated with a subscriber or user of communication device 3200. Communication device 3200 can use USIM or eUICC to operate on the network. The USIM / eUICC interface 3244 is typically similar to a card slot into which a USIM / eUICC card can be inserted. The USIM / eUICC card may have memory and can store a lot of key configuration 3251 and other information 3253, such as identification and subscriber-related information.

[0220] Once the network registration or activation process is complete, the communication device 3200 can send and receive communication signals through the communication network 3219. As illustrated, the communication network 3219 may include multiple base stations communicating with the communication device 3200.

[0221] The signal received by antenna element 3216 via communication network 3219 is input to receiver 3212, which can perform common receiver functions such as signal amplification, down-conversion, filtering, and channel selection. Analog-to-digital (A / D) conversion of the received signal allows for more complex communication functions, such as demodulation and decoding to be performed in DSP 3220. Similarly, the signal to be transmitted is processed, including modulation and encoding by DSP 3220, and input to transmitter 3214 for digital-to-analog (D / A) conversion, up-conversion, filtering, amplification, and transmission via antenna element 3218 through communication network 3219. DSP 3220 not only processes the communication signal but also provides receiver and transmitter control. For example, the gain of the communication signal applied to receiver 3212 and transmitter 3214 can be adaptively controlled by an automatic gain control algorithm implemented in DSP 3220.

[0222] Communication device 3200 typically includes a processor 3238, which controls the overall operation of the device. Communication functions, including data and voice communication, are performed through a communication subsystem 3211 in cooperation with the processor 3238. The processor 3238 also interacts with other device subsystems, such as a display 3222, flash memory 3224, random access memory (RAM) 3226, auxiliary input / output (I / O) subsystem 3228, serial port 3230, one or more user interfaces (such as a keyboard or keypad 3232, speaker 3234, microphone 3236), one or more other communication subsystems 3240 (such as a short-range communication subsystem), and any other device subsystem generally designated 3242. While other communication subsystems 3240 and 3242 are... Figure 16 While described as a separate component, it should be understood that other communication subsystems 3240 and other device subsystems 3242 (or portions thereof) may be integrated into a single component. Serial port 3230 may include a Universal Serial Bus (USB) port or other ports currently known or developed in the future.

[0223] Some of the subsystems shown perform communication-related functions, while others can provide "resident" or on-device functions. Notably, for example, some subsystems (such as keyboard 3232 and display 3222) can be used for both communication-related functions (such as entering text messages for transmission over a communication network) and on-device resident functions (such as a calculator or task list).

[0224] The operating system software used by the processor 3238 can be stored in a persistent repository such as flash memory 3224, which can alternatively be read-only memory (ROM) or a similar storage element (not shown). The operating system, device-specific applications, or portions thereof can be temporarily loaded into volatile memory (such as RAM 3226). Received communication signals can also be stored in RAM 3226.

[0225] As shown, flash memory 3224 may include different areas for both computer program 3258 and program data storage 3250, 3252, 3254, and 3256. These different storage types indicate that each program can allocate a portion of flash memory 3224 for its own data storage usage. In addition to its operating system functions, processor 3238 also enables the execution of software applications on communication device 3200. A predetermined set of applications controlling basic operations (e.g., including at least data and voice communication applications) can typically be installed on communication device 3200 during manufacturing. Other applications may be installed subsequently or dynamically.

[0226] Applications and software can be stored on any computer-readable storage medium. Computer-readable storage media can be tangible or in transient / non-transient media, such as optical (e.g., CDs, DVDs, etc.), magnetic (e.g., magnetic tape), or other currently known or future-developed memories.

[0227] Software applications can be loaded onto the communication device 3200 via the communication network 3219, auxiliary I / O subsystem 3228, serial port 3230, (multiple) other short-range communication subsystems 3240, or (multiple) any other suitable device subsystems 3242, and can be installed by the user in RAM 3226 or a non-volatile memory (not shown) for execution by the processor 3238. This flexibility in application installation can increase the functionality of the communication device 3200 and can provide enhanced on-device functionality, communication-related functions, or both. For example, secure communication applications can enable the use of the communication device 3200 to perform e-commerce functions and other such financial transactions.

[0228] In data communication mode, received signals such as text messages or web page downloads can be processed by communication subsystem 3211 and input to processor 3238. Processor 3238 can also process the received signals to output to display 3222 or alternatively to auxiliary I / O device 3228.

[0229] For voice communication, the overall operation of the communication device 3200 is similar, except that the received signal can typically be output to the speaker 3234 and the signal used for transmission can be generated by the microphone 3236. Alternative voice or audio I / O subsystems (such as a voice message recording subsystem) can also be implemented on the communication device 3200. Although voice or audio signal output can be primarily accomplished through the speaker 3234, the display 3222 can also be used to provide indications such as the caller's identity, the duration of the voice call, or other voice call-related information.

[0230] Serial port 3230 can be implemented in personal digital assistant (PDA) type devices, for which synchronization with the user's desktop computer (not shown) may be desired; however, such a port is an optional device component. Such a serial port 3230 allows the user to set preferences via external devices or software applications, and extends the capabilities of communication device 3200 by providing information or software downloads to communication device 3200 instead of via wireless communication network 3219. Alternative download paths can be used, for example, to load encryption keys onto communication device 3200 via a direct and therefore reliable and trusted connection, thereby enabling secure device communication. Serial port 3230 can also be used to connect the device to a computer to act as a modem.

[0231] Other communication subsystems 3240 (such as short-range communication subsystems) are optional components that can provide communication between communication device 3200 and different systems or devices (which are not necessarily similar devices). For example, one or more other communication subsystems 3240 may include infrared devices and associated circuitry and components or Bluetooth. TM A communication module is provided to provide communication with systems and devices with similar functionality. Other communication subsystems 3240 may also include non-cellular communications such as Wi-Fi, WiMAX, Near Field Communication (NFC), Bluetooth, ProSe (Proximity Services) (e.g., sidelink, PC5, D2D, etc.), and / or Radio Frequency Identification (RFID). Multiple other communication subsystems 3240 and / or multiple other device subsystems 3242 may also be used to communicate with auxiliary devices such as flat panel displays, keyboards, or projectors.

[0232] The aforementioned communication device 3200 and other components may include a processing component capable of executing instructions related to the aforementioned actions. Figure 17An example of a system 3300 is shown, including a processing component 3310 suitable for implementing one or more embodiments disclosed herein. In addition to the processor 3310 (which may be referred to as a central processing unit or CPU), the system 3300 may also include a network connectivity device 3320, random access memory (RAM) 3330, read-only memory (ROM) 3340, secondary storage device 3350, and input / output (I / O) device 3360. These components may communicate with each other via a bus 3370. In some cases, some of these components may be absent, or they may be combined with each other or with components not shown in various combinations. These components may reside in a single physical entity or in more than one physical entity. Any action described herein as being taken by the processor 3310 may be taken by the processor 3310 alone, or may be taken by the processor 3310 in combination with one or more components (such as a digital signal processor (DSP) 3380) shown or not shown in the drawings. Although the DSP 3380 is shown as a separate component, the DSP 3380 may be incorporated into the processor 3310.

[0233] Processor 3310 executes instructions, code, computer programs, or scripts accessible from network connectivity device 3320, RAM 3330, ROM 3340, or secondary storage device 3350 (which may include various disk-based systems such as hard disks, floppy disks, or optical disks). Although only one CPU 3310 is shown, multiple processors may exist. Therefore, although instructions may be discussed as being executed by a processor, instructions may be executed simultaneously, serially, or otherwise by one or more processors. Processor 3310 may be implemented as one or more CPU chips.

[0234] Network connectivity device 3320 may take the form of a modem, modem group, Ethernet device, Universal Serial Bus (USB) interface device, serial interface, token ring device, wireless local area network (WLAN) device, radio transceiver device, such as Code Division Multiple Access (CDMA) device, Global System for Mobile Communications (GSM) radio transceiver device, Universal Mobile Telecommunications System (UMTS) radio transceiver device, LTE radio transceiver device, next-generation radio transceiver device, Global Microwave Access Interoperability (WiMAX) device, and / or other known devices for connecting to a network. These network connectivity devices 3320 enable processor 3310 to communicate with the Internet or one or more telecommunications networks or other networks, allowing processor 3310 to receive information from or output information to these networks. Network connectivity device 3320 may also include one or more transceiver components 3325 capable of wirelessly transmitting and / or receiving data.

[0235] RAM 3330 can be used to store volatile data and instructions executed by processor 3310. ROM 3340 is a non-volatile memory device whose memory capacity is typically smaller than that of secondary storage device 3350. ROM 3340 can be used to store instructions and data that may be read during instruction execution. Access to both RAM 3330 and ROM 3340 is generally faster than access to secondary storage device 3350. Secondary storage device 3350 typically includes one or more disk drives or tape drives and can be used for non-volatile data storage or as an overflow data storage device when RAM 3330 is insufficient to hold all working data. Secondary storage device 3350 can be used to store programs loaded into RAM 3330 when such a program is selected for execution.

[0236] I / O device 3360 may include a liquid crystal display (LCD), a touch screen display, a keyboard, a keypad, a switch, a rotary dial, a mouse, a trackball, a voice recognizer, a card reader, a paper tape reader, a printer, a video monitor, or other known input / output devices. Furthermore, transceiver component 3325 may be considered a component of I / O device 3360, rather than a component of network connectivity device 3320, or as a supplement to components of network connectivity device 3320.

[0237] 3GPP TS.24.301 and 3GPP TS 24.501 are incorporated herein by reference for all purposes.

[0238] Although several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods may be implemented in many other specific forms without departing from the scope of this disclosure. These examples are to be considered illustrative rather than restrictive and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated into another system, or certain features may be omitted or not implemented.

[0239] Furthermore, without departing from the scope of this disclosure, the technologies, systems, subsystems, and methods described and illustrated in a discrete or separate manner in various embodiments may be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating electrically, mechanically, or otherwise through some interface, device, or intermediate component. Other examples of changes, substitutions, and modifications can be determined by those skilled in the art and can be made without departing from the spirit and scope of the disclosure herein.

Claims

1. A method in a user equipment (UE) for transferring an ongoing emergency session from a first network to a second network, the method comprising: Send a first registration request message to the second network; Receive a registration rejection message from the second network; The ongoing emergency session between the UE and the first network is detected to be in progress; In response to detecting the ongoing emergency session, a second registration request message is sent to the second network, and Receive registration acceptance message The first registration request message is a first attachment request message, and the second registration request message is a second attachment request message. The first attachment request message includes a first connection request message, which does not include an emergency handover indication, and the second attachment request message includes a second connection request message, which includes an emergency handover indication.

2. The method according to claim 1, wherein the registration rejection message includes a reason code.

3. The method according to claim 2, wherein before sending the second registration request message, the method further comprises: The reason code indicates that one of the following was not accepted: the UE's Permanent Device Identifier (PEI) and International Mobile Equipment Identifier (IMEI).

4. The method of claim 3, further comprising, when the UE determines that the reason code indicates that one of the PEI and the IMEI of the UE is not accepted, entering one of the following states: EMM-DEREGISTERED.NO-IMSI or 5GMM-DEREGISTERE.NO-SUPI.

5. The method according to claim 1, wherein the first network is a fifth-generation 5G network, and wherein the second network is a fourth-generation 4G network.

6. A user equipment (UE), comprising: processor; as well as A memory storing instructions that, when executed by the processor, cause the UE to: Send the first registration request message to the second network; Receive a registration rejection message from the second network; An emergency session between the UE and the first network is detected to be in progress; In response to detecting the emergency session, a second registration request message is sent to the second network; as well as Receive the registration acceptance message for the emergency session. The first registration request message is a first attachment request message, and the second registration request message is a second attachment request message. The first attachment request message includes a first connection request message, which does not include an emergency handover indication, and the second attachment request message includes a second connection request message, which includes an emergency handover indication.

7. The UE according to claim 6, wherein the registration rejection message includes a reason code.

8. The UE of claim 7, wherein the instruction further causes the UE to determine that the reason code does not indicate that one of the following is not accepted: the UE's Permanent Device Identifier (PEI) and International Mobile Equipment Identifier (IMEI).

9. The UE of claim 8, wherein the instruction further causes the UE to: enter one of the following states when the UE determines that the reason code indicates that one of the PEI and the IMEI of the UE is not accepted: EMM-DEREGISTERED.NO-IMSI or 5GMM-DEREGISTERE.NO-SUPI.

10. The UE according to claim 6, wherein the first network is a fifth-generation 5G network, and wherein the second network is a fourth-generation 4G network.

11. A non-transient computer-readable storage medium, comprising instructions that, when executed by a processor, cause the processor to: Send the first registration request message to the second network; Receive a registration rejection message from the second network; An emergency session between the UE and the first network is detected to be in progress; In response to the detection of the ongoing emergency session, a second registration request message is sent to the second network; as well as Receive the registration acceptance message for the emergency session. The first registration request message is a first attachment request message, and the second registration request message is a second attachment request message. The first attachment request message includes a first connection request message, which does not include an emergency handover indication, and the second attachment request message includes a second connection request message, which includes an emergency handover indication.

12. The non-transient computer-readable storage medium of claim 11, wherein the registration rejection message includes a reason code.

13. The non-transient computer-readable storage medium of claim 12, wherein the instructions further cause the processor to determine that the reason code does not indicate that one of the following is not accepted: the UE's Permanent Device Identifier (PEI) and International Mobile Equipment Identifier (IMEI).

14. The non-transient computer-readable storage medium of claim 13, wherein the instructions further cause the processor to enter one of the following states when the UE determines that the reason code indicates that one of the PEI and the IMEI of the UE is not accepted: EMM-DEREGISTERED.NO-IMSI or 5GMM-DEREGISTERE.NO-SUPI.

Images