Indicating IP multimedia system (IMS) capabilities for evolved packet system (EPS) fallback

Abstract

Apparatuses, methods, and systems are disclosed for indicating IMS capabilities for EPS fallback. An apparatus (500) in a mobile communication network includes a processor (505) and a transceiver (525) that transmits (705), to an IMS network entity, a first SIP message including a request to establish a data session, wherein the first SIP message contains a first Contact header field. The transceiver (525) receives (710), from the IMS network entity, a second SIP message (i.e., indicating a successful registration) for establishing the data session, wherein the second SIP message contains an indicator. The processor (505) determines (715) IMS network capabilities from a combination of the first Contact header field and the indicator.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 059,816, filed July 31, 2020, entitled “INDICATION OF THE IMS NETWORK CAPABILITY FOR EPSFALLBACK”, by Roozbeh Atarius, Dimitrios Karampatsis, and Andreas Kunz, which is incorporated herein by reference. Technical Field

[0003] The subject matter disclosed herein generally relates to wireless communications, and more specifically to IP Multimedia System (“IMS”) capabilities indicating the use of Evolved Packet System (“EPS”) fallback. Background Technology

[0004] Some wireless networks support interoperability with Evolved Packet System (“EPS”). According to current 3GPP standards, if a 5G System (“5GS”) network supports interoperability with EPS without any N26 reference point (i.e., the inter-CN interface between the Mobility Management Entity (“MME”) in the EPS core network (“CN”) and the Access and Mobility Management Function (“AMF”) in the 5G CN (“5GC”), to avoid loss of session establishment for Multimedia Telephone Reporting (“MMTEL”) services, the User Equipment (“UE”) requests the network to use Transmission Control Protocol (“TCP”) as the transport protocol for Session Initiation Protocol (“SIP”) signaling for MMTEL session establishment during IMS registration. Using TCP requires a dedicated connection and may include some limitations if Network Address Translation (“NAT”) exists between the UE and the Proxy Call Session Control Function (“P-CSCF”) in the IMS network. Summary of the Invention

[0005] A process for indicating EPS rollback IMS capability is disclosed. The process can be implemented by an apparatus, system, method, or computer program product.

[0006] A method of a user equipment (“UE”) includes transmitting to a network entity a first Session Initiation Protocol (“SIP”) message including a request to establish a data session, wherein the first SIP message includes a first contact header field. The first method includes receiving from the network entity a second SIP message for establishing a data session, wherein the second SIP message includes an indicator. The first method includes determining IP Multimedia Protocol (“IMS”) network capabilities from a combination of the first contact header field and the indicator.

[0007] One method of an IMS entity includes receiving a first SIP message, which includes a request to establish a data session, into a UE, wherein the first SIP message contains a first contact header field. A second method includes transmitting a second SIP message to the UE for establishing a data session, wherein the second SIP message contains a first contact header field and an indicator. Here, the second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities. Attached Figure Description

[0008] A more specific description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and should therefore not be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, in which:

[0009] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system for non-uniform coverage of network slices within a registration area;

[0010] Figure 2A A diagram depicts an embodiment of EPS fallback that uses TCP as the transport protocol for MMTEL session establishment.

[0011] Figure 2B yes Figure 2A The continuation of the process;

[0012] Figure 3A A diagram illustrating one embodiment of EPS fallback for MMTEL session establishment is provided.

[0013] Figure 3B yes Figure 3A The continuation of the process;

[0014] Figure 4 This is a block diagram illustrating one embodiment of a network device apparatus that can be used to indicate the IMS capability of EPS rollback;

[0015] Figure 5This is a block diagram illustrating one embodiment of a user equipment device that can be used to indicate the IMS capability of EPS rollback;

[0016] Figure 6 This is a flowchart illustrating one embodiment of a method for indicating the IMS capability of EPS rollback;

[0017] Figure 7 This is a flowchart illustrating another embodiment of a method for indicating the IMS capability of EPS rollback; and

[0018] Figure 8 This is a flowchart illustrating a third embodiment of a method for indicating the IMS capability of EPS rollback. Detailed Implementation

[0019] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Therefore, embodiments can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining aspects of both software and hardware.

[0020] For example, the disclosed embodiments can be implemented as hardware circuitry that includes custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0021] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device employs only signals for accessing the code.

[0022] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.

[0023] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable compact disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0024] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, and C++, and traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network including a local area network ("LAN"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").

[0025] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0026] Throughout this specification, references to "an embodiment," "embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases "in an embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, refer to the same embodiment, but rather mean "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly stated otherwise, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a," "an," and "the" also mean "one or more."

[0027] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of…” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of…” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0028] The following description of various aspects of the embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that individual blocks in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0029] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that implement the functions / actions specified in the flowchart and / or block diagram.

[0030] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0031] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing specified logical functions(s).

[0032] It should also be noted that in some alternative implementations, the functions marked in the boxes may not appear in the order shown in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functionality involved. Other steps and methods that are equivalent in function, logic, or effect to one or more boxes or portions thereof shown in the figures can be contemplated.

[0033] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In practice, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of a depicted embodiment. It will also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware or a combination of dedicated hardware and code that performs the specified function or action.

[0034] The description of the elements in each figure can be referenced to the elements in the preceding figures. In all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0035] Generally, this disclosure describes systems, methods, and apparatuses for verifying IP Multimedia System (“IMS”) capabilities indicating Evolved Packet System (“EPS”) fallback. In some embodiments, the methods may be performed using computer code embedded in a computer-readable medium. In some embodiments, the apparatus or system may include a computer-readable medium containing computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of a solution. The disclosed techniques are used in IMS networks capable of maintaining Multimedia Telegraph (“MMTEL”) session establishment without any loss of Session Initiation Protocol (“SIP”) signaling to indicate such capability to user equipment (“UE”), and thereby enabling the UE to support interoperability between 5GS and EPS without any N26 reference point due to factors such as congestion control or segmentation avoidance using transport protocols.

[0036] The process for how the IMS network notifies the UE about support for EPS backoff is disclosed. Therefore, when the 5G network supports interoperability with EPS without any N26 reference point, the UE does not need to use the TCP transport protocol for MMTEL services to avoid the loss of SIP signaling during EPS backoff.

[0037] Figure 1 A wireless communication system 100 for improving suspended data connections is depicted according to embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, a mobile core network 130, and an IMS network 160. The RAN 120 and the mobile core network 130 form a mobile communication network. The RAN 120 may consist of a base station unit 121, and the remote unit 105 communicates with the base station unit 121 using a wireless communication link 123. Although in Figure 1 The document describes a specific number of remote units 105, base station units 121, wireless communication links 123, RAN 120, mobile core network 130, and IMS network 160, but those skilled in the art will recognize that any number of remote units 105, base station units 121, wireless communication links 123, RAN 120, mobile core network 130, and IMS network 160 can be included in the wireless communication system 100.

[0038] In one implementation, RAN 120 conforms to a 5G system as specified in the 3GPP (“3GPP”) specifications. For example, RAN 120 may be a Next Generation Radio Access Network (“NG-RAN”) that implements New Radio (“NR”) Radio Access Technology (“RAT”) and / or Long Term Evolution (“LTE”) RAT. In another example, RAN 120 may include a non-3GPP RAT (e.g., Wi-Fi® or an IEEE 802.11 series compliant WLAN). In yet another implementation, RAN 120 conforms to an LTE system as specified in the 3GPP specifications. However, more generally, wireless communication system 100 may implement other open or proprietary communication networks, such as Global Microwave Access Interoperability (“WiMAX”) or the IEEE 802.16 series standards, and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0039] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art. In various embodiments, remote unit 105 includes a subscriber identity and / or identification module (“SIM”) and a mobile device (“ME”) that provides mobile terminal functions (e.g., radio transmission, conversion, voice encoding and decoding, error detection and correction, signaling and access to the SIM). In some embodiments, the remote unit 105 may include a terminal device (“TE”) and / or be embedded in an appliance or device (e.g., a computing device as described above).

[0040] Remote unit 105 can communicate directly with one or more base station units 121 in RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, UL and DL communication signals can be carried on wireless communication link 123. Here, RAN 120 is an intermediate network providing access to mobile core network 130 to remote unit 105. As described in more detail below, base units 121 can provide cells operating using a first carrier frequency and / or cells operating using a second carrier frequency. Cells using the first carrier frequency can form a first frequency layer, while cells using the second carrier frequency can form a second frequency layer.

[0041] In some embodiments, remote unit 105 communicates with application server 141 via a network connection to mobile core network 130. For example, application 107 in remote unit 105 (e.g., a web browser, media client, telephone, and / or Voice over Internet Protocol (“VoIP”) application) can trigger remote unit 105 to establish a Protocol Data Unit (“PDU”) session (or other data connection) with mobile core network 130 via RAN 120. Mobile core network 130 then uses the PDU session to relay services between remote unit 105 and application server 151 in packet data network 150. The PDU session represents a logical connection between remote unit 105 and user plane function (“UPF”) 141 in 5GC 140.

[0042] To establish a PDU session (or PDN connection), remote unit 105 must register with mobile core network 130 (also referred to as "attached to mobile core network" in the context of fourth-generation ("4G") systems). Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 130. Therefore, remote unit 105 may have at least one PDU session for communicating with packet data network 150. Remote unit 105 may establish additional PDU sessions for communicating with other data networks (such as IMS network 160) and / or other communication peers.

[0043] In the context of a 5G system (“5GS”), the term “PDU session” refers to a data connection that provides end-to-end (“E2E”) user plane (“UP”) connectivity between remote unit 105 and a specific data network (“DN”) via UPF 141. A PDU session supports one or more Quality of Service (“QoS”) streams. In some embodiments, a one-to-one mapping may exist between QoS streams and QoS profiles, such that all packets belonging to a particular QoS stream have the same 5G QoS identifier (“5QI”).

[0044] In the context of 4G / LTE systems such as Evolved Packet System (“EPS”), a Packet Data Network (“PDN”) connection (also known as an EPS session) provides end-to-end (E2E) connectivity between the remote unit and the PDN. The PDN connectivity process establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and the packet gateway (“PGW”) 137 in the EPC 131. In some embodiments, a one-to-one mapping exists between the EPS bearer and the QoS profile, such that all packets belonging to a particular EPS bearer have the same QoS class identifier (“QCI”).

[0045] In some embodiments, remote unit 105 accesses services in IMS network 160 via a network connection to mobile core network 130. For example, application 107 in the remote unit can trigger the establishment of a session with IMS network 160 via mobile core network 130 and RAN 120. Mobile core network 130 then uses the PDU session to relay services between remote unit 105 and IMS network 150.

[0046] Base station unit 121 may be distributed across a geographical area. In some embodiments, base station unit 121 may also be referred to as an access terminal, access point, base station, base station, node B (“NB”), evolved Node B (abbreviated as eNodeB or “eNB”, also known as Evolved Universal Terrestrial Radio Access Network (“E-UTRAN”) node B), 5G / NR node B (“gNB”), home node B, relay node, RAN node, or any other term used in the art. Base station unit 121 is typically part of a RAN such as RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base station units 121. These and other elements of the radio access network are not shown, but are generally well known to those skilled in the art. Base station unit 121 is connected to mobile core network 130 via RAN 120.

[0047] Base station unit 121 can serve multiple remote units 105 within a service area, such as a cell or cell sector, via wireless communication link 123. Base station unit 121 can communicate directly with one or more remote units 105 via communication signals. Typically, base station unit 121 transmits DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on wireless communication link 123. Wireless communication link 123 can be any suitable carrier in licensed or unlicensed radio spectrum. Wireless communication link 123 facilitates communication between one or more remote units 105 and / or one or more base station units 121. Note that during NR operation (referred to as "NR-U") on unlicensed spectrum, base station unit 121 and remote units 105 communicate via unlicensed (i.e., shared) radio spectrum.

[0048] In various embodiments, the mobile core network 130 may include an evolved packet core (“EPC”) 131 and a 5G core (“5GC”) 140, which may be coupled to data networks such as the Internet and private data networks, as well as other data networks. As depicted, the mobile core network 140 is also coupled to an IMS network 160. The remote unit 105 may have a subscription or other account with respect to the mobile core network 130. In various embodiments, each mobile core network 130 belongs to a single mobile network operator (“MNO”). This disclosure is not intended to limit implementations to any particular wireless communication system architecture or protocol.

[0049] The depicted EPC 131 includes various network entities, including MME 133, SGW 135, PGW 137, PCRF 138, and USS 139. The EPC 131 may include additional entities as understood in the art. Although in Figure 1 The document describes a specific number and type of core network entities and network functions, but those skilled in the art will recognize that any number and type of core network entities and / or network functions may be included in EPC 131.

[0050] The depicted 5GC 140 includes several network functions (“NFs”). As depicted, the 5GC 140 includes at least one UPF 141. The 5GC 140 also includes multiple control plane (“CP”) functions, including but not limited to Access and Mobility Management Functions (“AMF”) 143, Session Management Functions (“SMF”) 145, Policy Control Functions (“PCF”) 147, Unified Data Management Functions (“UDM”), and User Data Repository (“UDR”) serving the RAN 120. Figure 1The document describes a specific number and type of network functions, but those skilled in the art will recognize that any number and type of network functions can be included in 5GC 140.

[0051] In the 5G architecture, (multiple) UPF 141s are responsible for packet routing and forwarding, packet inspection, QoS processing, and external PDU sessions for interconnecting the data network (DN). AMF 143 is responsible for NAS signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF 145 is responsible for UPF 141 session management (i.e., session establishment, modification, and release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and service orientation configuration for appropriate service routing.

[0052] PCF 147 is responsible for a unified policy framework, providing policy rules for CP functions and accessing subscription information for policy decisions in the UDR. UDM is responsible for generating Authentication and Key Agreement (“AKA”) credentials, user identification processing, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to serve multiple network functions. For example, the UDR can store subscription data, policy-related data, subscriber-related data that can be exposed to third-party applications, etc. In some embodiments, the UDM and UDR are co-located and depicted as a combined entity “UDM / UDR” 149.

[0053] In various embodiments, 5GC 140 may also include a Network Repository Function (“NRF”) (which provides Network Function (NF) service registration and discovery, enabling NFs to identify appropriate services among themselves and communicate with each other via an Application Programming Interface (“API”), a Network Exposure Function (“NEF”) (which is responsible for enabling customers and network partners to easily access network data and resources), an Authentication Server Function (“AUSF”), or other NFs defined for 5GC. When present, the AUSF can be used as an authentication server and / or authentication proxy, thereby allowing AMF 143 to authenticate remote unit 105. In some embodiments, mobile communication network 130 may include an Authentication, Authorization, and Accounting (“AAA”) server.

[0054] Note that 5G network functions perform similar functions to the entities in EPC 131. For example, AMF 143 can be mapped to MME 133, SMF 145 can be mapped to the control plane portion of PGW 137 (i.e., PGW-C) and / or to MME 133, UPF 141 can be mapped to SGW 135 and the user plane portion of PGW 137 (i.e., PGW-U), PCF 147 can be mapped to PCRF 138, UDM / UDR 149 can be mapped to HSS 139, and so on.

[0055] In various embodiments, the 5GC 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the 5GC 140 optimized for a specific service type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") services. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") services. In other examples, network slices may be optimized for machine-type communication ("MTC") services, massive MTC ("mMTC") services, and Internet of Things ("IoT") services. In still other examples, network slices may be deployed for specific application services, vertical services, specific use cases, etc.

[0056] Network slice instances can be identified by a single network slice selection aid information (“S-NSSAI”), while the set of network slices authorized for use by remote unit 105 is identified by network slice selection aid information (“NSSAI”). Here, “NSSAI” refers to a vector value including one or more S-NSSAI values. In some embodiments, various network slices may include separate instances of network functions, such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For illustration purposes, Figure 1 Different network slices are not shown, but support for them is assumed.

[0057] Although Figure 1 The components of EPC and 5GC are described, but the described implementation of IMS capability for backoff signaling is applicable to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications (“GSM”, i.e., 2G digital cellular networks), General Packet Radio Service (“GPRS”), General Mobile Telecommunications System (“UMTS”), LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, etc.

[0058] In the following description, the term "RAN node" is used for base stations, but it can be replaced by any other radio access node such as gNB, ng-eNB, eNB, base station ("BS"), access point ("AP"), etc. Furthermore, the operation is primarily described in the context of 5G NR. However, the solutions / methods described below are equally applicable to improving other mobile communication systems that have suspended data connections.

[0059] As discussed above, remote unit 105 can communicate with IMS network 160 via a data path traversing mobile core network 130. For example, mobile core network 130 can use the data path to relay IMS signaling and / or media services between remote unit 105 and IMS application server 161. In some embodiments, remote unit 105 can connect to IMS network 160 via 5G core network 140. In some embodiments, remote unit 105 can connect to (e.g., fallback to) EPC 131 to access services in IMS network 160.

[0060] IMS network 160 is a network used to provide, for example, IP-based multimedia services to remote unit 105. As depicted, IMS network 160 includes an IMS application server (“AS”) 161. Here, IMS AS 161 hosts and / or performs multimedia services, such as IMS MMTEL. In some embodiments, IMS AS 161 is a SIP application server. As depicted, IMS network 160 may also include multiple call session control functions (“CSCFs”), including a proxy CSCF (“P-CSCF”) 163, an interrogation CSCF (“I-CSCF”) 165, and a service CSCF (“S-CSCF”) 167. CSCFs 163-167 may be SIP functions that provide control plane services to IMS network 160.

[0061] As previously mentioned, the remote unit 105 connected to 5GC 140 may be unable to access the IMS network 160 for MMTEL services (e.g., due to the lack of an N26 interface in the mobile core network 130 to connect AMF 141 to MME 133), thus requiring a fallback to EPC 131. However, EPS fallback introduces additional latency to the IMS MMTEL session setup, which can lead to the loss of IMS signaling (resulting in further latency).

[0062] To prevent the loss of IMS signaling, remote unit 105 can rely on Transmission Control Protocol (“TCP”) instead of User Datagram Protocol (“UDP”) to guarantee the delivery of SIP signaling. UDP is a connectionless protocol, allowing the sender to transmit data packets out of order to the receiver. Unlike UDP, TCP is a connection-based protocol, where the sender and receiver can establish a connection before data packets are transmitted and received to guarantee the reception of sent data packets. Data packets can be received in the order they were transmitted. While TCP provides reliability, it may come at the cost of longer transmission times, potentially 2.5 times the header overhead of UDP, mandatory acknowledgments at the receiver, and signal exchange between the sender and receiver. Therefore, the solution described below addresses the situation where IMS networks support EPS backoff without relying on TCP.

[0063] In 5GS networks supporting EPS backoff without an N26 reference point, the UE registers with the Internet Protocol Multimedia Subsystem (“IMS”) network by establishing a new binding with TCP delivery configured for MMTEL session establishment. This is likely due to the time required for EPS backoff from NR during MMTEL session establishment, as the N26 reference point is absent. TCP delivery prevents SIP signaling from being lost during MMTEL session establishment. The new binding using TCP delivery for MMTEL session establishment can be accomplished by adding the record address to the contact header field of the SIP REGISTER request and adding the IMS Communication Service Identifier (“ICSI”) for MMTEL, for example, encoded as URN. urn:urn-7: 3gpp-service.ims.icsi.mmtel And added as a tag value to the media feature. tagg.3gpp.icsi-ref In this context, TCP is used as the transport protocol (see 3GPP TS 24.229). Therefore, the contact header field of a SIP REGISTER request can be as follows:

[0064]

[0065] Once IMS has authenticated the UE, it can send a binding for the recorded address in the Contact Header field of the SIP 200 OK response to indicate that the binding has been registered for that recorded address. The “expires” parameter, which indicates how long the UE's binding is valid, can also be in the Contact Header field. The IMS network can also include all other registered bindings already registered for that recorded address. The Contact Header field of the SIP 200 OK response can be as follows:

[0066]

[0067] Figure 2A-2B The process 200 for EPS backoff using TCP as the transport protocol for MMTEL session establishment is described. Process 200 involves UE 205, NG-RAN 207, E-UTRAN 209, AMF 211, MME 213, SGW 215, PGW-C / SMF 217, PGW-U / UPF 219, PCF / PCRF 221, and P-CSCF (AF) 223. As a premise, it is assumed that UE 205 is registered to the IMS network as described above, and an EPS backoff from NR occurs during resource allocation.

[0068] At step 1, UE 205 sends a SIP INVITE message containing an SDP proposal to P-CSCF (AF) 223 to establish an IMS session (see Message Passing 225).

[0069] At step 2, P-CSCF (AF) 223 obtains connection information, such as IP address and port (see block 227).

[0070] At step 3, P-CSCF (AF) 223 forwards a SIP INVITE message request to the remote UE (see Message Passing 229).

[0071] At step 4, P-CSCF (AF) 223 receives a “183 SIP Session Progress” response from the remote UE (see message 231).

[0072] At step 5, P-CSCF(AF)223 obtains connection information, such as IP address and port (see block 233).

[0073] At step 6, P-CSCF(AF) 223 sends session information to PCF / PCRF 221 (see Message Passing 235).

[0074] In step 7, PCF / PCRF 221 stores session information and performs session binding by associating a data stream with applicable PCC rules with an existing PDU session (see block 237). PCF / PCRF 221 creates a session context for the application.

[0075] At step 8, PCF / PCRF 221 sends an acknowledgment to P-CSCF(AF) 223 (see message passing 239).

[0076] At step 9, PCF / PCRF 221 sends an Npcf_SMPolicyControl_UpdateNotify request to provide PGW-C / SMF 217 with session management related policies for updating PDU sessions, for example, according to 3GPP TS 29.512 (see Message Passing 241).

[0077] At step 10, PGW-C / SMF 217 invokes a service operation on AMF 211 to transmit N2 SM information to NG-RAN node 207 (see message passing 243). For example, PGW-C / SMF 217 may send a Namf_Communication_N1N2MessageTransfer message with the following parameters: SM context ID, N2 SM information (PDU session ID, N3 tunnel information, (multiple) QFIs, (multiple) QoS profiles, session-AMBR). Due to IMS message exchange between UE 205 and the 3GPP network (e.g., 5GS), UE 205 is in CM-CONNECTED state, and AMF 211 has already established an N2 transport association with NG-RAN node 207, therefore a paging procedure is not required.

[0078] At step 11, AMF 211 transmits the N2 SM information received from PGW-C / SMF 217 to NG-RAN node 207 (see message passing 245). For example, according to 3GPP TS 38.40, AMF 211 can use a PDU_Session_Resource_Modify request and send an N2 interface message containing a PDU session request.

[0079] At step 12, NG-RAN node 207 rejects a new QoS flow from the PDU session establishment request of PGW-C / SMF 217 (see block 247). NG-RAN rejection may be based on the configuration of using E-UTRAN 209 for this PDU session, and thus uses inter-RAT mobility. Therefore, EPS backoff begins.

[0080] continue Figure 2B At step 13, when an acknowledgment is received from PCF / PCRF 221 in step 8, P-CSCF (AF) 223 forwards the SDP response within the "SIP 183 Session Progress" message to UE 205 via PGW-U / UPF 219 (see message passing 249). Note that without special action, the "SIP 183 Session Progress" message may be lost due to EPS backoff triggered by NG-RAN node 207 rejecting a new QoS flow for a PDU session establishment request.

[0081] At step 14, NG-RAN node 207 sends a QoS flow rejection indication to AMF 211 of PGW-C / SMF 217 (see message 251). The QoS flow rejection indication may be included in an N2 SM information container, which is included in an N2 message (N2 session response message). NG-RAN node 207 may also provide the reason for the rejected QoS flow establishment (e.g., 5QI not supported and / or inter-system change required). NG-RAN node 207 may send an indication to AMF 211 in the N2 session response message or in a separate N2 message (e.g., an N2 request for resource release) that the request for inter-system redirection and / or establishment of a QoS flow for IMS voice has failed. AMF 211 then releases the existing N1 connection with UE 205 to initiate a redirection to E-UTRAN 209 (see clause 4.2.6 in 3GPP TS 23.502).

[0082] At step 15, AMF 211 forwards the N2 SM information container to PGW-C / SMF 217 with a reason for rejection (see message 253). If the N26 interface is deployed, AMF 211 performs a handover procedure (e.g., as described in sub-clause 4.11.1.2.1 of 3GPP TS 23.502), or if the N26 interface is not deployed, it performs an RRC release with redirection (e.g., as described in sub-clauses 4.2.6 and 4.11.1.3.2 of 3GPP TS 23.502). Here, it is assumed that the N26 interface is not deployed, therefore no handover is performed and an RRC release message with redirection is sent.

[0083] When NG-RAN 207 receives message 14, if the N26 interface exists (which is not applicable in the depicted embodiment), NG-RAN 207 initiates any handover; or if the N26 interface does not exist, it releases access to the EPS via inter-system redirection (see block 255). In both cases, it is assumed that UE 205 is a dual-mode UE with 5GS and EPS functionality. PGW-C / SMF 217 reports changes in RAT type to PCF / PCRF 221 if these changes are subscribed to by PCF / PCRF 221 (e.g., as specified in clauses 4.11.1.2.1 or 4.11.1.3.2.6). When UE 205 connects to the EPS, option 1 or option 2 is executed (as described below) (see block 257).

[0084] Option 1: In the case of a 5GS to EPS handover (see sub-clause 4.11.1.2.1 of 3GPP TS 23.502) and in the case of inter-system redirection to EPS using the N26 interface (see sub-clause 4.11.1.3.2 of 3GPP TS 23.502). In either case, UE 205 initiates a TAU procedure. Here, it is assumed that the N26 interface is not deployed, therefore Option 1 is not executed.

[0085] Option 2: In the case of inter-system redirection to EPS without using the N26 interface (see sub-clause 4.11.2.2 of 3GPP TS 23.502). If UE 205 supports the request type flag "Switch" for PDN connectivity requests during the attach procedure (e.g., as described in sub-clause 5.3.2.1 of 3GPP TS 23.401), and UE 205 has received an indication to support interoperability without N26, then UE 205 initiates an attach with a PDN connectivity request of request type "Switch". Here, it is assumed that the N26 interface is not deployed, therefore Option 2 is executed.

[0086] At step 16, UE 205 and the mobile network (i.e., EPS) are already connected by E-UTRAN 209. Since TCP is used as the transport protocol, a SIP 183 session progress request (i.e., received by PGW-U / UPF 219 in step 13) is sent to UE 205 (see message 259). After the mobility procedure to EPS or the handover procedure from 5GS to EPS is completed, E-UTRAN 209 sends an attachment completion message to MME 213 (see message 261).

[0087] At step 17, upon receiving the attachment completion message, MME 213 sends a modify bearer request to SGW 215 (see Message Passing 263).

[0088] At step 18, SGW 215 sends a modify bearer request to PGW-C / SMF 217 (see message passing 265).

[0089] At step 19, PGW-C / SMF 217 re-initiates the setup of multiple dedicated bearers for the maintained PCC rules(multiple), and maps 5G QoS parameters to EPC QoS parameters (see Diameter Credit Control Request (“CCR”) 267). PGW-C / SMF 217 reports the successful resource allocation to PCF / PCRF 221. If subscribed by PCF / PCRF 221, PGW-C / SMF 217 also reports access network information.

[0090] At step 20, PCF / PCRF 221 is confirmed (see Diameter Credit Control Response (“CCA”) 269).

[0091] At step 21, PCF / PCRF 221 reports successful resource allocation to P-CSCF(AF) 223 (see Diameter Reauthorization Request (RAR) message 271). If subscribed by P-CSCF(AF) 223, PCF / PCRF 221 also reports access network information, such as changes in access type (e.g., as specified in 3GPP TS 29.514) and / or changes in IP-CAN type (e.g., as specified in 3GPP TS 29.214).

[0092] At step 22, P-CSCF(AF) 223 acknowledges (see Diameter Reauthorization Response (“RAA”) 273). At this point, P-CSCF(AF) 223, which has already subscribed to the access network information, knows that it has regained network access with the change from NG-RAN 207 to E-UTRAN 209.

[0093] Then, UE 205 and the IMS network continue with the remaining IMS session establishment process (see block 275).

[0094] Figures 3A-3B The process 300 for EPS rollback for MMTEL session establishment is described. Process 300 involves UE 205, NG-RAN 207, E-UTRAN 209, AMF 211, MME 213, SGW 215, PGW-C / SMF 217, PGW-U / UPF 219, PCF / PCRF 221, and P-CSCF(AF) 223. In cases where the IMS network supports service rollback to EPS, P-CSCF(AF) 223 can subscribe to EPS rollback events (e.g., as specified in 3GPP TS 29.514 and 3GPP TS 29.214). When P-CSCF(AF) 223 subscribes to EPS rollback, P-CSCF(AF) 223 can receive notification that EPS rollback has been initiated. P-CSCF(AF) 223 then knows that network access may be lost and UE 205 may be unable to access the network. Therefore, P-CSCF (AF) 223 avoids forwarding any SIP messages targeting UE 205 until EPS fallback is complete and UE 205 reconnects to the IMS network (i.e., for E-UTRAN 209 and EPS).

[0095] According to IETF RFC 3262, reliable temporary responses (such as SIP 183 session progress) can begin retransmission at T1 seconds, with each retransmission doubling the time. T1 is an estimate of the round-trip time (“RTT”), and it defaults to 500 ms (see IETF RFC 3261). A matching PRACK should be received within 64 × T1 seconds of the SIP 183 session progress retransmission; otherwise, the original request should be rejected (see IETF RFC 3262). Therefore, MMTEL session establishment can be based on... Figures 3A-3B .

[0096] At step 1, UE 205 sends a SIP INVITE message containing an SDP proposal to P-CSCF (AF) 223 to establish an IMS session (see Message Passing 301).

[0097] At step 2, P-CSCF(AF)223 obtains connection information, such as IP address and port (see block 303).

[0098] At step 3, P-CSCF (AF) 223 forwards a SIP INVITE message request to the remote UE (see Message Passing 305).

[0099] At step 4, P-CSCF (AF) 223 receives a “183 SIP Session Progress” response from the remote UE (see message 307).

[0100] At step 5, P-CSCF(AF)223 obtains connection information, such as IP address and port (see block 309).

[0101] At step 6, P-CSCF(AF) 223 sends session information to PCF / PCRF 221 (see Message Passing 311).

[0102] At step 7, PCF / PCRF 221 stores session information and performs session binding by associating a data stream with applicable PCC rules with an existing PDU session (see block 313). PCF / PCRF 221 creates a session context for the application.

[0103] At step 8, PCF / PCRF 221 sends an acknowledgment to P-CSCF(AF) 223 (see message passing 315).

[0104] At step 9, PCF / PCRF 221 sends an Npcf_SMPolicyControl_UpdateNotify request to provide PGW-C / SMF 217 with session management related policies for updating PDU sessions, for example, according to 3GPP TS 29.512 (see Message Passing 317).

[0105] At step 10, PGW-C / SMF 217 invokes a service operation on AMF 211 to transmit N2 SM information to NG-RAN node 207 (see message passing 319). For example, PGW-C / SMF 217 may send a Namf_Communication_N1N2MessageTransfer message with the following parameters: SM context ID, N2 SM information (PDU session ID, N3 tunnel information, (multiple) QFIs, (multiple) QoS profiles, session-AMBR). Due to IMS message exchange between UE 205 and the 3GPP network (e.g., 5GS), UE 205 is in CM-CONNECTED state and AMF 211 has already established an N2 transport association with NG-RAN node 207, therefore a paging procedure is not required.

[0106] At step 11, AMF 211 transmits the N2 SM information received from PGW-C / SMF 217 to NG-RAN node 207 (see message passing 321). For example, according to 3GPP TS 38.40, AMF 211 can use the PDU_Session_Resource_Modify request to send an N2 interface message containing a PDU session request.

[0107] At step 12, if NG-RAN node 207 rejects a new QoS flow from the PDU session establishment request of PGW-C / SMF 217 (see block 323), the NG-RAN rejection may be based on the configuration of using E-UTRAN 209 for the PDU session, thus utilizing inter-RAT mobility. Therefore, EPS fallback begins.

[0108] At step 13, upon receiving an acknowledgment from PCF / PCRF 221 in step 8, P-CSCF(AF) 223 forwards the SDP response within the "SIP 183 Session Progress" message to UE 205 via PGW-U / UPF 219 (see message passing 325). SIP 183 session progress may be lost due to EPS backoff triggered by NG-RAN node 207 rejecting a new QoS flow requesting a PDU session establishment request.

[0109] At step 14, NG-RAN node 207 sends a QoS flow rejection indication to AMF 211 of PGW-C / SMF 217 (see message 327). The QoS flow rejection indication may be included in an N2 SM information container, which is included in an N2 message (N2 session response message). NG-RAN node 207 may also provide the reason for the rejected QoS flow establishment (e.g., 5QI not supported and / or inter-system change required). NG-RAN node 207 may send an indication to AMF 211 in the N2 session response message or in a separate N2 message (e.g., an N2 request for resource release) that the request for inter-system redirection and / or establishment of a QoS flow for IMS voice has failed. AMF 211 then releases the existing N1 connection with UE 205 to initiate a redirection to E-UTRAN 209 (see clause 4.2.6 in 3GPP TS 23.502).

[0110] continue Figure 3B In step 15, AMF 211 forwards the N2 SM information container to PGW-C / SMF 217 with a reason for rejection (see message 329). If the N26 interface is deployed, AMF 211 performs a handover procedure (e.g., as described in sub-clause 4.11.1.2.1 of 3GPP TS 23.502), or if the N26 interface is not deployed, it performs an RRC release with redirection (e.g., as described in sub-clauses 4.2.6 and 4.11.1.3.2 of 3GPP TS 23.502). Here, it is assumed that the N26 interface is not deployed, therefore no handover is performed and an RRC release message with redirection is sent.

[0111] At step 16, because PCF / PCRF 221 has subscribed to the EPS backoff event at PGW-C / SMF 217, PGW-C / SMF 217 notifies PCF / PCRF 221 of the loss of access network information, for example, as specified in 3GPP TS 29.514 and 3GPP TS 29.214 (see message 331). Alternatively, if PCF / PCRF 221 is able to subscribe to the EPS backoff event at AMF, then AMF 211 can notify PCF / PCRF 221 that inter-RAT redirection is in progress upon a receive rejection from NG-RAN node 207 used for QoS flow establishment (see message 331).

[0112] At step 17, because P-CSCF(AF) 223 has subscribed to the EPS rollback event at PCF / PCRF 221 (as specified in 3GPP TS 29.514 and 3GPP TS 29.214), PCF / PCRF 221 notifies P-CSCF(AF) 223 that an EPS rollback has been initiated (see Diameter reauthorization request (“RAR” 333).

[0113] At step 18, P-CSCF(AF)223 is acknowledged (see Diameter Reauthorization Response (“RAA”)335).

[0114] At step 19, P-CSCF(AF) 223 is aware that EPS backoff has begun and therefore UE 205 does not have any access connection to the network. Therefore, it should be assumed that if P-CSCF(AF) 223 receives a retransmitted SIP 183 session progress request in message 4' (see message passing 337), P-CSCF(AF) 223 will not forward the SIP 183 session progress request until P-CSCF(AF) 223 is notified that access to the network has been established (see block 339). Retransmissions of SIP 183 session progress can occur after a default value of 500 ms and double with each retransmission. This retransmission can be limited to 64 times within 500 ms or 32 seconds, see, for example, IETF RFC 3262 and IETF RFC 3261.

[0115] When NG-RAN 207 receives message 14, if the N26 interface exists (not applicable in the depicted embodiment), NG-RAN 207 initiates any handover; otherwise, if the N26 interface does not exist, it releases access to the EPS via inter-system redirection (see block 341). In both cases, it is assumed that the UE is a dual-mode UE with 5GS and EPS functionality. The PGW-C+SMF reports changes in RAT type to PCF / PCRF 221 if these changes are subscribed to by PCF / PCRF 221 (as specified in clauses 4.11.1.2.1 or 4.11.1.3.2.6). When the UE connects to the EPS, option 1 or option 2 is executed (as described below).

[0116] Option 1: In the case of a 5GS to EPS handover (see sub-clause 4.11.1.2.1 of 3GPP TS 23.502) and in the case of inter-system redirection to EPS using the N26 interface (see sub-clause 4.11.1.3.2 of 3GPP TS 23.502). In either case, UE 205 initiates a TAU procedure. Here, it is assumed that the N26 interface is not deployed, therefore Option 1 is not executed.

[0117] Option 2: In the case of inter-system redirection to EPS without using the N26 interface (see sub-clause 4.11.2.2 of 3GPP TS 23.502). If UE 205 supports the request type flag "Switch" for PDN connectivity requests during the attach procedure (e.g., as described in sub-clause 5.3.2.1 of 3GPP TS 23.401), and UE 205 has received an indication to support interoperability without N26, then UE 205 initiates an attach with a PDN connectivity request of request type "Switch". Here, it is assumed that the N26 interface is not deployed, therefore Option 2 is executed.

[0118] At step 20, UE 205 and the mobile network (i.e., EPS) are already connected by E-UTRAN 209. If TCP is used as the transport protocol, a SIP “183 Session Progress” request (i.e., received by PGW-U / UPF 219 in step 13) is sent toward UE 205 (see message 345). After the mobility procedure to EPS or the handover procedure from 5GS to EPS is completed, E-UTRAN 209 sends an attachment completion message to MME 213 (see message 347).

[0119] At step 21, upon receiving the attachment completion message, MME 213 sends a modify bearer request to SGW 215 (see message passing 349).

[0120] At step 22, SGW 215 sends a modify bearer request to PGW-C / SMF 217 (see message passing 351).

[0121] At step 23, PGW-C / SMF 217 re-initiates the setup of multiple dedicated bearers for the maintained PCC rules(multiple), and maps 5G QoS to EPC QoS parameters (see Diameter Credit Control Request (“CCR”) 353). PGW-C / SMF 217 reports the successful resource allocation to PCF / PCRF 221. If subscribed by PCF / PCRF 221, PGW-C / SMF 217 also reports access network information.

[0122] At step 24, PCF / PCRF 221 is confirmed (see Diameter Credit Control Response (“CCA”) 355).

[0123] At step 25, PCF / PCRF 221 reports successful resource allocation to P-CSCF(AF) 223 (see Diameter Reauthorization Request (RAR) message 357). If subscribed by P-CSCF(AF) 223, PCF / PCRF 221 also reports access network information, such as access type change and / or IP-CAN type change.

[0124] At step 26, P-CSCF(AF) 223 acknowledges (see Diameter Reauthorization Response (“RAA”) 359). At this point, P-CSCF(AF) 223, which has already subscribed to access network information, knows that network access has been regained following the change from NG-RAN 207 to E-UTRAN 209. If, once access network is established, P-CSCF(AF) 223 receives a retransmitted SIP 183 session progress request in message 4' (see message passing 337), then P-CSCF(AF) 223 forwards the SIP 183 session progress request to UE 205 in message 13' (see message passing 361). UE 205 and the IMS network will continue with the remaining IMS session establishment process (see block 363).

[0125] Sub-clause 18.1.1 in IETF RFC 3261 and 3GPP TS 24.229 introduces a mechanism that reuses the same existing TCP connection used in response to a request. However, IETF RFC 3261 does not preclude the response from being transmitted over a new TCP connection, rather than the connection used in the request. If the request was transmitted using UDP, it is unclear whether P-CSCF (AF) 223 will use a UDP connection to send the response. The SIP message transmission protocol can be chosen based on factors such as the size of the SIP message, congestion control, and avoiding fragmentation. For example, a SIP response is often larger than a SIP request due to the added record routing header field value, and therefore can be sent by TCP, while the SIP request is transmitted by UDP.

[0126] Figure 4An exemplary SIP message 400 according to embodiments of this disclosure is depicted. In one embodiment, SIP message 400 is a SIP REGISTER request indicating the transport layer preferences of remote unit 105 and / or UE 205 when registering to IMS network 160. In another embodiment, SIP message 400 is a SIP INVITE request used by remote unit 105 and / or UE 205 to establish an MMTEL session using a TCP connection to P-CSCF 163 and / or P-CSCF (AF) 223. In other embodiments, SIP message 400 may be another SIP request / response message.

[0127] SIP message 400 includes multiple message headers 405 and a message body 410. SIP message header 405 includes one or more of the following: contact header 415, characteristic capitalization header 420, call ID header 425, "to" header 430, and "from" header 435.

[0128] By adding a transmission TCP header field 415 in the contact header field for a specific service such as MMTEL during IMS registration, it can be assumed that P-CSCF(AF) 223 is "willing" to use TCP, and therefore P-CSCF(AF) 223 may not be "willing" to do so unless it is forced as an implementation option for non-traditional IMS networks. Traditional IMS networks can still ignore UE 205's request to use TCP for transmitting SIP messages for the MMTEL service. However, responses to requests sent by UE 205 via a TCP connection are still forced on the same connection, thus UE 205 can force the IMS network to respond using TCP transmission.

[0129] If P-CSCF(AF) 223 has subscribed to EPS fallback and access network information, then when the MMTEL session is established, if EPS fallback occurs, P-CSCF(AF) 223 will know about the lack of access network and when to re-establish access network. Figures 3A-3B As shown, P-CSCF(AF) 223 can therefore forward the retransmitted SIP 183 session progress toward the UE when the access network is re-established. Therefore, TCP may not be required as the transport protocol in this case. Requiring TCP transport when it is not required can cause complexity, such as network address translation (“NAT”) between UE 205 and P-CSCF(AF) 223.

[0130] According to this first solution, when the network supports interoperability without N26, if the UE includes services such as MMTEL ICSI as a URN... urn:urn-7:3gpp-service.ims.icsi.mmtelAnd add it as a tag value to the media feature tag in the contact header field 415 of the SIP REGISTER request with extended transport=tcp. g.3gpp.icsi-ref Within the IMS network, if the P-CSCF supports subscription EPS rollback and subscription access network information, the IMS network can create at least one new contact for that service.

[0131] According to the first solution, the UE can recognize from 5G registration that the network supports interoperability without the N26 interface. During IMS registration, the UE inserts the following content into the Contact Header field 415 of the SIP REGISTER request.

[0132]

[0133] In some embodiments, the same ICSI (e.g., ...) is included in the contact header field 415 of the SIP 200 OK response to the SIP REGISTER request sent by the UE. urn:urn-7:3gpp-service.ims.icsi.mmtel And without any extensions to any specific transport protocol, it is added as a tag value to the media feature tag. g.3gpp.icsi-ref Within the IMS network, new contacts are created for the service without any specific transport protocol.

[0134] Therefore, if registration is successful and the IMS network confirms the registration binding for the Record Address (“AOR”), and adds a new contact for the same binding without a specific transport protocol, the IMS network inserts the following into its SIP 200 OK response to the SIPREGISTER request:

[0135]

[0136] In other embodiments, the same ICSI (e.g., ...) is included in the Contact header field 415 of the SIP 200 OK response to the SIP REGISTER request sent by the UE. urn:urn-7:3gpp-service.ims.icsi.mmtel And add it as a tag value to the media feature tag. g.3gpp.icsi-ref Within the service, and by extending the service with supported transport protocols, the IMS network creates new contacts using all supported transport protocols.

[0137] Therefore, if registration is successful and the IMS network confirms the registration binding for AOR, and a new contact is added for the same binding using the UDP transport protocol and any other supported transport protocols, the IMS network inserts the following into the SIP 200 OK response to the SIP REGISTER request:

[0138]

[0139]

[0140] In either alternative, upon receiving a SIP200 OK response with a newly added contact in the Contact Header field 415, the UE determines that the IMS network supports EPS rollback, and therefore, the UE does not need to use TCP delivery for MMTEL session establishment to avoid any loss of SIP signaling due to EPS rollback. Note that TCP delivery may still be used due to other factors such as message size and congestion control. However, the use of the TCP delivery protocol is not mandatory to avoid loss of SIP signaling during EPS rollback.

[0141] It should be noted that, according to the first solution, during registration, a legacy UE sees new contacts already registered on its behalf and may attempt to unregister those contacts, or behave differently depending on the implementation. A legacy UE may not understand instructions expressed in other words by the IMS network. How a legacy UE behaves depends on the UE implementation. However, the IMS network may not comply with a legacy UE's requests for TCP transmissions, and therefore, termination SIP signaling for the MMTEL session can use appropriate UDP or TCP or any other protocol for transmission, regardless of the UE's requests for TCP transmissions during IMS registration, as long as those IMS signaling messages for the MMTEL session are not a response to the UE's requests for TCP transmissions.

[0142] According to the second solution, the Feature Capability Header field 420 in the SIP 200 OK response to the UE's SIP REGISTER request to the IMS network can be used by the P-CSCF or S-CSCF or any IMS network entity to include a Feature Capability Indicator as specified in IETF RFC 6809. The Feature Capability Indicator in the SIP 200 OK response indicates that the IMS network supports EPS fallback. According to the ABNF specified in IETF RFC 6809, the indicator can be encoded as "+g.3gpp.epsfallback" or "+g.3gpp.eps-fallback" or any "+g.3gpp.XXX", where "XXX" informs the UE that the network supports EPS fallback.

[0143] The UE can recognize network support for interoperability without the N26 interface from 5G registration. During IMS registration, the UE inserts the following content into the Contact Header field 415 of the SIPREGISTER request:

[0144]

[0145] If registration is successful and the IMS network confirms the registration binding for the Record Address (“AOR”), and adds a new contact for the same binding without a specific transport protocol, the IMS network inserts the following into the SIP 200 OK response to the SIP REGISTER request:

[0146]

[0147] IMS networks include the following uppercase header characteristics in a SIP 200 OK response:

[0148] feature-cap=+g.3gpp.eps-fallback

[0149] Upon receiving a SIP 200 OK response with an indicator in the Feature Uppercase Header field 420 showing the added new feature capability for IMS network support of EPS rollback, the UE determines that the IMS network supports EPS rollback. Therefore, the UE does not need to use TCP delivery for MMTEL session establishment to avoid any loss of SIP signaling due to EPS rollback. TCP delivery may still be used due to other factors such as message size and congestion control.

[0150] According to the second solution, a legacy UE sees a new feature capability indicator in the Feature Uppercase Header field 420 of the SIP 200 OK response to the UE's SIP REGISTER request during registration. The legacy UE may not understand the indications expressed in other words by the IMS network. How the legacy UE behaves depends on the implementation. However, the IMS network may not comply with the legacy UE's requests for TCP deliveries, and therefore, termination SIP signaling for the MMTEL session can use appropriate delivery UDP or TCP or any other protocol, regardless of the UE's requests for TCP deliveries during IMS registration, as long as those IMS signaling messages established for the MMTEL session are not in response to the UE's requests for TCP deliveries.

[0151] According to the third solution, the new ICSI or IARI value can be used as an indicator of EPS fallback support for the UE's IMS network, and therefore the UE does not need to use TCP transmission during MMTEL session establishment. The new ICSI or IARI value, along with all ICSI and IARI values ​​received in the Contact Header field 415 of the SIP 200 OK response, is added to the Contact Header field 415 of the SIP 200 OK response. Examples of this ICSI or IARI could be "urn:urn-7:3gpp-service.ims.icsi.epsfallback" and "urn:urn-7:3gpp-appli

[0152] cation.ims.iari.epsfallback" or any urn:urn-7:3gpp-service.ims.icsi.XXX

[0153] "X or urn:urn-7:3gpp-application.ims.iari.XXXX", where "XXXX" refers to the IMS network's ability to perform EPS rollback.

[0154] The UE can recognize from 5G registration that the network supports interoperability without the N26 interface. During IMS registration, the UE inserts the following content into the Contact Header field 415 of the SIPREGISTER request.

[0155]

[0156] If registration is successful, and the IMS network confirms the registration binding for the Record Address (AOR), and adds a new contact for the same binding without a specific transport protocol, the IMS network inserts the following into its SIP 200 OK response to the SIP REGISTER request:

[0157] or

[0158]

[0159] This instructs the IMS network to support EPS rollback.

[0160] Upon receiving a SIP 200 OK response with a newly added ICSI or IARI value in the Contact Header field 415 indicating IMS network support for EPS rollback, the UE determines that the IMS network supports EPS rollback. Therefore, the UE does not need to use TCP delivery for MMTEL session establishment to avoid any loss of SIP signaling due to EPS rollback. Note, however, that TCP delivery may still be used due to other factors such as message size and congestion control.

[0161] According to the third solution, a legacy UE sees the Contact Header field 415 with a new ICSI or IARI in the SIP 200 OK response to the UE's SIP REGISTER request during registration. The legacy UE may not understand the indications used by the IMS network in other terms. How the legacy UE behaves depends on the implementation. However, the IMS network may not comply with the legacy UE's requests for TCP deliveries, and therefore the termination SIP signaling used for MMTEL session establishment can use appropriate UDP or TCP or any other protocol for delivery, regardless of the UE's request for TCP deliveries during IMS registration, as long as those IMS signalings for MMTEL session establishment are not a response to the UE's requests for TCP deliveries.

[0162] According to the fourth solution, the new 5GS network feature support information element (“IE”) will indicate that the IMS network supports EPS fallback, and therefore the UE does not need to use TCP transmission during MMTEL session establishment. For example, according to 3GPP TS 24.501, during UE NAS registration, the new 5GS network feature support IE is communicated by the network to the UE via the REGISTRATION ACCEPT message. In one embodiment, the new 5GS network feature support IE can be a bit that can be set to “1” if the IMS network supports EPS fallback. Otherwise, the new IE can be set to “0” to indicate the lack of IMS network support for EPS fallback. It should be noted that other bit values ​​can be used to indicate whether the IMS network supports EPS fallback without losing SIP signaling.

[0163] According to the fourth solution, during NAS registration, the legacy UE receives the new IE in the REGISTRATION ACCEPT message; however, it may not understand the new IE and therefore may ignore it. How the legacy UE behaves depends on the UE implementation. However, the IMS network may not comply with the legacy UE's requests for TCP deliveries, and therefore the termination SIP signaling established for the MMTEL session can use appropriate transport UDP or TCP (or any other transport protocol) regardless of the UE's requests for TCP deliveries during IMS registration, as long as those IMS signaling messages established for the MMTEL session are not in response to the UE's requests for TCP deliveries.

[0164] Figure 5User equipment device 500, which can be used to improve the suspension of data connections according to embodiments of the present disclosure, is described. In various embodiments, user equipment device 500 is used to implement one or more of the solutions described above. User equipment device 500 may be an embodiment of remote unit 105 and / or UE 205 described above. In addition, user equipment device 500 may include processor 505, memory 510, input device 515, output device 520, and transceiver 525.

[0165] In some embodiments, input device 515 and output device 520 are combined into a single device, such as a touchscreen. In some embodiments, user equipment device 500 may not include any input device 515 and / or output device 520. In various embodiments, user equipment device 500 may include one or more of the following: processor 505, memory 510, and transceiver 525, and may not include input device 515 and / or output device 520.

[0166] As depicted, transceiver 525 includes at least one transmitter 530 and at least one receiver 535. In some embodiments, transceiver 525 communicates with one or more cells (or radio coverage areas) supported by one or more base station units 121. In various embodiments, transceiver 525 may operate on unlicensed spectrum. Furthermore, transceiver 525 may include multiple UE panels supporting one or more beams. Additionally, transceiver 525 may support at least one network interface 540 and / or application interface 545. The application interface(s) 545 may support one or more APIs. The network interface(s) 540 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 540 may be supported, as will be understood by those skilled in the art.

[0167] In one embodiment, processor 505 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 505 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 505 executes instructions stored in memory 510 to perform the methods and routines described herein. Processor 505 is communicatively coupled to memory 510, input device 515, output device 520, and transceiver 525.

[0168] In various embodiments, processor 505 controls user equipment device 500 to implement the UE behavior described above. In some embodiments, processor 505 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0169] In various embodiments, processor 505 controls transceiver 525 to transmit a first SIP message to the IMS network entity, including a request to establish a data session, wherein the first SIP message contains a first contact header field. Transceiver 525 receives a second SIP message from the IMS network entity for establishing a data session (i.e., indicating successful registration), wherein the second SIP message contains an indicator. Processor 505 determines IMS network capabilities from the combination of the first contact header field and the indicator.

[0170] In some embodiments, a request is made to instruct the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator indicates support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol is different from the first transport protocol. In some embodiments, processor 505 establishes an MMTEL session supporting both the first and second transport protocols.

[0171] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capabilities indicate the IMS network's ability to maintain established data sessions during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0172] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0173] In one embodiment, the indicator includes a special ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a special IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0174] In one embodiment, memory 510 is a computer-readable storage medium. In some embodiments, memory 510 includes volatile computer storage media. For example, memory 510 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 510 includes non-volatile computer storage media. For example, memory 510 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 510 includes both volatile and non-volatile computer storage media.

[0175] In some embodiments, memory 510 stores data related to improving paused data connectivity. For example, memory 510 may store various parameters, panel / beam configurations, resource assignments, strategies, etc., as described above. In some embodiments, memory 510 also stores program code and related data, such as an operating system or other controller algorithms operating on device 500.

[0176] In one embodiment, input device 515 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 515 may be integrated with output device 520, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 515 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting input on the touchscreen. In some embodiments, input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0177] In one embodiment, output device 520 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 520 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 520 may include, but is not limited to, a liquid crystal display (“LCD”), a light-emitting diode (“LED”) display, an organic LED (“OLED”) display, a projector, or a similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, output device 520 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., separate from but communicatively coupled to the rest of user equipment device 500. Furthermore, output device 520 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0178] In some embodiments, output device 520 includes one or more speakers for generating sound. For example, output device 520 may generate an auditory alarm or notification (e.g., a buzzer or ring). In some embodiments, output device 520 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 520 may be integrated with input device 515. For example, input device 515 and output device 520 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 520 may be located near input device 515.

[0179] Transceiver 525 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 525 operates under the control of processor 505 to transmit and receive messages, data, and other signals. For example, processor 505 may selectively activate transceiver 525 (or a portion thereof) at specific times to send and receive messages.

[0180] Transceiver 525 includes at least a transmitter 530 and at least one receiver 535. One or more transmitters 530 can be used to provide UL communication signals to base station unit 121, such as UL transmissions described herein. Similarly, as described herein, one or more receivers 535 can be used to receive DL communication signals from base station unit 121. Although only one transmitter 530 and one receiver 535 are illustrated, user equipment device 500 can have any suitable number of transmitters 530 and receivers 535. Furthermore, the transmitter(s) 530 and receiver(s) 535 can be of any suitable type. In one embodiment, transceiver 525 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0181] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some transceivers 525, transmitters 530, and receivers 535 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 540.

[0182] In various embodiments, one or more transmitters 530 and / or one or more receivers 535 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (“ASIC”), or other types of hardware components. In some embodiments, one or more transmitters 530 and / or one or more receivers 535 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as network interface 540 or other hardware components / circuitets may be integrated with any number of transmitters 530 and / or receivers 535 into a single chip. In such embodiments, transmitters 530 and receivers 535 may be logically configured as transceivers 525 using a plurality of common control signals or as modular transmitters 530 and receivers 535 implemented in the same hardware chip or multi-chip module.

[0183] Figure 6A network device 600, which can be used to improve the suspension of data connections, is depicted according to embodiments of the present disclosure. In one embodiment, the network device 600 may be an implementation of a RAN node, such as base station unit 121 or RAN node 210 as described above. Furthermore, the base station network device 600 may include a processor 605, a memory 610, an input device 615, an output device 620, and a transceiver 625.

[0184] In some embodiments, input device 615 and output device 620 are combined into a single device, such as a touchscreen. In some embodiments, network device 600 may not include any input device 615 and / or output device 620. In various embodiments, network device 600 may include one or more of the following: processor 605, memory 610, and transceiver 625, and may not include input device 615 and / or output device 620.

[0185] As depicted, transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, transceiver 625 communicates with one or more remote units 105. Additionally, transceiver 625 may support at least one network interface 640 and / or application interface 645. The application interfaces 645 may support one or more APIs. The network interfaces 640 may support 3GPP reference points such as Uu, N1, N2, and N3. Other network interfaces 640 may be supported, as will be understood by those skilled in the art.

[0186] In one embodiment, processor 605 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 605 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, processor 605 executes instructions stored in memory 610 to perform the methods and routines described herein. Processor 605 is communicatively coupled to memory 610, input device 615, output device 620, and transceiver 625.

[0187] In various embodiments, network device 600 is a RAN node (e.g., gNB) communicating with one or more UEs, as described herein. In such embodiments, processor 605 controls network device 600 to perform the RAN behaviors described above. When operating as a RAN node, processor 605 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0188] In various embodiments, processor 605 controls network device 600 to perform the IMS network behavior described herein. In some embodiments, transceiver 625 receives a first SIP message from the UE including a request to establish a data session, wherein the first SIP message contains a first contact header field. Processor 605 controls transceiver 625 to transmit a second SIP message to the UE for establishing a data session (i.e., indicating successful registration), wherein the second SIP message contains an indicator. Here, the second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities.

[0189] In some embodiments, a request instructs the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator indicates support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol differs from the first transport protocol. In some embodiments, processor 605 establishes an MMTEL session supporting both the first and second transport protocols.

[0190] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capabilities indicate the IMS network's ability to maintain established data sessions during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0191] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0192] In one embodiment, the indicator includes a specific ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a specific IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0193] In one embodiment, memory 610 is a computer-readable storage medium. In some embodiments, memory 610 includes volatile computer storage media. For example, memory 610 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 610 includes non-volatile computer storage media. For example, memory 610 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 610 includes both volatile and non-volatile computer storage media.

[0194] In some embodiments, memory 610 stores data related to improving paused data connections. For example, memory 610 may store parameters, configurations, resource assignments, policies, etc., as described above. In some embodiments, memory 610 also stores program code and related data, such as an operating system or other controller algorithms operating on device 600.

[0195] In one embodiment, input device 615 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 615 may be integrated with output device 620, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 615 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting input on the touchscreen. In some embodiments, input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0196] In one embodiment, output device 620 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 620 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 620 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., separate from but communicatively coupled to the rest of network device 600. Furthermore, output device 620 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0197] In some embodiments, output device 620 includes one or more speakers for generating sound. For example, output device 620 may generate an auditory alarm or notification (e.g., a buzzer or ring). In some embodiments, output device 620 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 620 may be integrated with input device 615. For example, input device 615 and output device 620 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 620 may be located near input device 615.

[0198] Transceiver 625 includes at least a transmitter 630 and at least one receiver 635. As described herein, one or more transmitters 630 can be used to communicate with a UE. Similarly, as described herein, one or more receivers 635 can be used to communicate with network functions in a PLMN and / or RAN. Although only one transmitter 630 and one receiver 635 are illustrated, network device 600 can have any suitable number of transmitters 630 and receivers 635. Furthermore, transmitters 630 and receivers 635 can be of any suitable type.

[0199] Figure 7 An embodiment of a method 700 for indicating IMS capability for EPS rollback according to embodiments of the present disclosure is described. In various embodiments, method 700 is performed by a user equipment device in a mobile communication network, such as remote unit 105, UE 205 and / or user equipment device 500 described above. In some embodiments, method 700 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0200] Method 700 begins by sending a first SIP message to network entity 705, including a request to establish a data session. The first SIP message includes a first contact header field. Method 700 includes receiving a second SIP message from the network entity (i.e., indicating successful registration) for establishing a data session. The second SIP message includes an indicator. Method 700 includes determining IMS network capabilities from a combination of the first contact header field and the indicator. Method 700 ends.

[0201] Figure 8An embodiment of a method 800 for indicating IMS capabilities for EPS rollback, according to embodiments of the present disclosure, is described. In various embodiments, method 800 is performed by an IMS entity in a mobile communication network, such as P-CSCF 161, P-CSCF (AF) 223, and / or network device 600 described above. In some embodiments, method 800 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0202] Method 800 begins by receiving a first SIP message 805 to the UE, which includes a request to establish a data session. The first SIP message includes a first contact header field. Method 800 then includes transmitting a second SIP message 810 to the UE for establishing a data session. The second SIP message includes an indicator, wherein the second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities. Method 800 ends.

[0203] According to embodiments of this disclosure, a first apparatus for indicating IMS capabilities for EPS rollback is disclosed herein. The first apparatus may be implemented by a user equipment device in a mobile communication network, such as the remote unit 105, UE 205, and / or user equipment device 500 described above. The first apparatus includes a processor and a transceiver that transmits a first SIP message to an IMS network entity, including a request to establish a data session, wherein the first SIP message contains a first contact header field. The transceiver receives a second SIP message from the IMS network entity for establishing a data session (i.e., indicating successful registration), wherein the second SIP message contains an indicator. The processor determines the IMS network capabilities from the combination of the first contact header field and the indicator.

[0204] In some embodiments, a request instructs the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator indicates support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol differs from the first transport protocol. In some embodiments, the processor establishes an MMTEL session supporting both the first and second transport protocols.

[0205] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capabilities indicate the IMS network's ability to maintain established data sessions during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0206] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0207] In one embodiment, the indicator includes a specific ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a specific IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0208] According to embodiments of this disclosure, a first method for indicating IMS capabilities for EPS rollback is disclosed herein. The first method can be performed by a user equipment device in a mobile communication network, such as the remote unit 105, UE 205, and / or user equipment device 500 described above. The first method includes transmitting a first SIP message to an IMS network entity including a request to establish a data session, wherein the first SIP message includes a first contact header field. The first method includes receiving a second SIP message from the network entity for establishing a data session (i.e., indicating successful registration), wherein the second SIP message includes an indicator. The first method includes determining IMS network capabilities from a combination of the first contact header field and the indicator.

[0209] In some embodiments, the request instructs the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator indicates support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol differs from the first transport protocol. In some embodiments, the first method further includes establishing an MMTEL session supporting both the first and second transport protocols.

[0210] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capabilities indicate the IMS network's ability to maintain established data sessions during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0211] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0212] In one embodiment, the indicator includes a specific ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a specific IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0213] According to embodiments of this disclosure, a second means for indicating IMS capabilities for EPS rollback is disclosed herein. The second means may be implemented by an IMS entity in a mobile communication network, such as P-CSCF 161, P-CSCF (AF) 223 and / or network device 600 as described above. The second means includes a processor and a transceiver that receives a first Session Initiation Protocol (“SIP”) message including a request to establish a data session from a remote unit (i.e., the UE), wherein the first SIP message includes a first contact header field. The processor controls the transceiver to transmit a second SIP message to the remote unit for establishing a data session (i.e., indicating successful registration), wherein the second SIP message includes an indicator. Here, the second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities.

[0214] In some embodiments, a request instructs the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator indicates support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol differs from the first transport protocol. In some embodiments, the processor establishes an MMTEL session supporting both the first and second transport protocols.

[0215] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capabilities indicate the IMS network's ability to maintain established data sessions during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0216] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0217] In one embodiment, the indicator includes a specific ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a specific IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0218] According to embodiments of this disclosure, a second method for indicating IMS capabilities for EPS fallback is disclosed herein. The second method can be performed by an IMS entity in a mobile communication network, such as p-CSCF 161, P-CSCF (AF) 223, and / or network device 600 as described above. The second method includes receiving a first SIP message including a request to establish a data session from a remote unit (i.e., UE), wherein the first SIP message contains a first contact header field. The second method includes transmitting a second SIP message to the remote unit for establishing a data session (i.e., indicating successful registration), wherein the second SIP message contains a first contact header field and an indicator. Here, the second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities.

[0219] In some embodiments, the request instructs the use of a first transport protocol (e.g., TCP) to maintain connectivity during service fallback to a different radio access technology (i.e., a fallback from NR / 5GC to LTE / EPS). Here, the indicator instructs support for a second transport protocol (e.g., UDP) to maintain connectivity during service fallback, wherein the second transport protocol differs from the first transport protocol. In some embodiments, the second method further includes establishing an MMTEL session supporting both the first and second transport protocols.

[0220] In some embodiments, the first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response. In some embodiments, the determined IMS network capability indicates the IMS network's ability to maintain the establishment of a data session during EPS rollback. In one embodiment, the first transport protocol is TCP and the second transport protocol is UDP.

[0221] In some embodiments, the second message includes a first contact header field and a second contact header field for establishing a data session, wherein the second contact header field contains an indicator. In some embodiments, the first contact header field includes a first extension indicating the use of a first transport protocol (e.g., TCP) to maintain the connection during service fallback to a different radio access technology. In some embodiments, the second contact header field does not include transport protocol extensions (i.e., it does not include any extensions for a particular transport protocol). In such embodiments, the absence of transport protocol extensions indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol (e.g., UDP). In other embodiments, the second contact header field includes a second transport protocol extension indicating the use of each supported second transport protocol.

[0222] In one embodiment, the indicator includes a specific ICSI value indicating support for EPS fallback. In another embodiment, the indicator includes a specific IARI value indicating support for EPS fallback. In still other embodiments, the second message includes a feature capability field (i.e., a feature capitalization header) containing the indicator.

[0223] The embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims should be covered within their scope.

Claims

1. A user equipment ("UE") apparatus, comprising: Transceiver, the transceiver: A first Session Initiation Protocol ("SIP") message, including a request to establish a data session, is transmitted to the network entity; and the first SIP message includes a first contact header field. Receive a second SIP message from the network entity for establishing the data session, wherein the second SIP message includes an indicator; and A processor that determines IMS network capabilities from a combination of the first contact header field and the indicator, wherein the indicator includes a special value that indicates support for EPS rollback, wherein the special value is an ICSI value or an IARI value.

2. The apparatus according to claim 1, wherein, The request indicates the use of a first transport protocol to maintain the connection during service fallback to a different radio access technology, wherein the indicator indicates support for a second transport protocol, which is different from the first transport protocol, while maintaining the connection during the service fallback.

3. The apparatus according to claim 2, wherein, The processor establishes an MMTEL session supporting the first transport protocol and the second transport protocol, wherein the first transport protocol is Transmission Control Protocol ("TCP") and the second transport protocol is User Datagram Protocol ("UDP").

4. The apparatus according to claim 1, wherein, The first SIP message includes a "SIP REGISTER" request and the second SIP message includes a "SIP 200 OK" response.

5. The apparatus according to claim 1, wherein, The determined IMS network capabilities indicate the IMS network's ability to maintain the establishment of the data session during EPS rollback.

6. The apparatus according to claim 1, wherein, The second SIP message includes a first contact header field and a second contact header field for establishing the data session, wherein the second contact header field contains the indicator.

7. The apparatus according to claim 6, wherein, The first contact header field includes a first extension indicating the use of a first transport protocol to maintain connectivity during service fallback to a different radio access technology, wherein the second contact header field does not include a transport protocol extension, wherein the absence of a transport protocol extension indicates support for both the first transport protocol and a second transport protocol different from the first transport protocol.

8. The apparatus according to claim 1, wherein, The second SIP message includes a characteristic capability field containing the indicator.

9. A method for a user equipment ("UE") apparatus, the method comprising: A first Session Initiation Protocol ("SIP") message is sent to a network entity, including a request to establish a data session, the first SIP message including a first contact header field; Receive a second SIP message from the network entity for establishing the data session, the second SIP message including an indicator; and IMS network capabilities are determined from the combination of the first contact header field and the indicator. The indicator includes a special value that indicates support for EPS rollback, wherein the special value is an ICSI value or an IARI value.

10. A method for an Internet Protocol Multimedia Subsystem ("IMS") network, the method comprising: A first Session Initiation Protocol ("SIP") message, including a request to establish a data session, is received by the remote unit, wherein the first SIP message includes a first contact header field; and A second SIP message for establishing the data session is transmitted to the remote unit. The second SIP message includes an indicator. The second SIP message uses a combination of the first contact header field and the indicator to indicate IMS network capabilities. The indicator includes a special value that indicates support for EPS rollback, wherein the special value is an ICSI value or an IARI value.

11. The method according to claim 10, wherein, The request indicates the use of a first transport protocol to maintain the connection during service fallback to a different radio access technology, wherein the indicator indicates support for a second transport protocol, which is different from the first transport protocol, while maintaining the connection during the service fallback.

12. The method according to claim 10, wherein, The second SIP message includes a first contact header field and a second contact header field for establishing the data session, wherein the second contact header field contains the indicator.

13. The method according to claim 10, wherein, The second SIP message includes a characteristic capability field containing the indicator.

Images