Early session initiation protocol retransmission after radio access technology change
The early SIP retransmission mechanism in UE devices addresses the issue of unsynchronized IMS states by promptly retransmitting SIP non-INVITE messages during RAT changes, reducing delays and enhancing user experience in cellular networks.
Patent Information
- Application Number
- PCT/US2024/014287
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-31
- Filing Date
- 2024-02-02
- Publication Date
- 2025-03-06
AI Technical Summary
In cellular networks, user equipment (UE) devices face delays and poor user experiences when initiating or terminating IMS services due to unsynchronized IMS states caused by unsuccessful retransmissions of SIP non-INVITE messages during radio access technology (RAT) changes.
The UE device implements an early SIP retransmission mechanism that retransmits SIP non-INVITE messages without waiting for a specified period, updating the PANI header to reflect the current RAT, and performing retransmissions in response to RAT changes or when the IMS session context is ready.
This approach reduces the wait time for IMS service operations to complete, enhances user experience by minimizing delays, and reduces the reliance on conventional retransmission intervals, thereby improving the reliability of SIP message transmissions.
Smart Images

Figure US2024014287_06032025_PF_FP_ABST
Abstract
Description
EARLY SESSION INITIATION PROTOCOL RETRANSMISSION AFTER RADIO ACCESS TECHNOLOGY CHANGEBACKGROUND
[0001] In some instances, a user equipment (UE) device in a cellular network initiates an internet protocol (IP) multimedia subsystem (IMS) service (e.g., IMS voice call initiation or IMS video call initiation) with an IMS network via a radio access network (RAN) and a core network. As part of establishing the IMS service, each of the originating and terminating UE devices send various IMS signaling messages, such as a session initiation protocol (SIP) message, to the IMS network. For example, the originating UE device sends a SIP INVITE request to establish a call session. The IMS network routes the INVITE request to network components associated with the terminating UE device. The terminating UE device sends a SIP 180 Ringing response, which indicates that the call is being alerted, to the IMS network. The IMS network then sends the SIP 180 Ringing response to the originating UE device, which can play a ringback tone to indicate that the terminating UE device is being alerted. When the terminating UE device answers the call, the terminating UE device sends a SIP 200 OK response to the IMS network, which is forwarded to the originating UE device. The originating UE device then sends a SIP ACK message to confirm the reception of the SIP 200 OK response from the terminating UE device. Once the terminating UE device receives the SIP ACK message from the originating UE device, both UE devices are able to start exchanging media.SUMMARY OF EMBODIMENTS
[0002] In accordance with one aspect, a method for performing a retransmission procedure for session initiation protocol (SIP) messages at a user equipment (UE) device includes receiving a first indication indicating that a current radio access technology at the UE device has changed from a first RAT to a second RAT. Responsive to receiving the first indication, a SIP non-INVITE message that is pending a response from an Internet Protocol Multimedia Subsystem (IMS) network is retransmitted.
[0003] In at least some embodiments, the method further includes storing an indication that the SIP non-INVITE message is pending the response from the IMS network.
[0004] In at least some embodiments, storing the indication is in response to determining that a threshold amount of time has expired without the SIP non-INVITE message having received a response from the IMS network.
[0005] In at least some embodiments, retransmitting the SIP non-INVITE message includes retransmitting the SIP non-INVITE message with a header indicating that the UE device is currently using the second RAT. In at least some embodiments, the header is a private-access-network-info header.
[0006] In at least some embodiments, the method further includes receiving a second indication from a RAT module implementing the second RAT that an IMS session context is ready for the second RAT. In at least some embodiments, retransmitting the SIP non-INVITE message includes retransmitting the SIP non- INVITE message further in response to the second indication.
[0007] In at least some embodiments, retransmitting the SIP non-INVITE message includes selecting the SIP non-INVITE message for retransmission responsive to receiving the first indication; generating a new SIP non-INVITE message representing the SIP non-INVITE message and having a header indicating that the UE device is currently using the second RAT; and transmitting the new SIP non-INVITE message to the IMS network.
[0008] In at least some embodiments, retransmitting the SIP non-INVITE message includes retransmitting the SIP non-INVITE message without actively waiting for a specified period of time before retransmitting the SIP non-INVITE message.
[0009] In at least some embodiments, retransmitting the SIP non-INVITE message prior to a current retransmission interval defined by a specification having expired.
[0010] In at least some embodiments, the method further comprises incrementing an early retransmission counter after retransmitting the SIP non-INVITE message.
[0011] In at least some embodiments, the method further comprises responsive to determining that at least one of the retransmitted SIP non-INVITE message or another SIP non-INVITE message is pending a response from the IMS network and the early retransmission counter indicating a maximum number of early retransmissions has occurred, performing a retransmission procedure for the at least one of the retransmitted SIP non-INVITE message or the other SIP non-INVITE message defined by one or more SIP specifications.
[0012] In at least some embodiments, each of the first RAT and the second RAT is a different one of a cellular-based RAT or a Wireless Fidelity RAT.
[0013] In accordance with another aspect, a user equipment device includes one or more radio frequency (RF) modems configured to wirelessly communicate with at least one network; one or more processors coupled to the one or more RF modems; and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the methods described above and herein.
[0014] In accordance with a further aspect, a computer-readable storage medium embodies a set of executable instructions, the set of executable instructions to manipulate a user equipment device to perform the methods described above and herein.BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art, by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.
[0016] FIG. 1 is a diagram illustrating an example wireless system employing a UE device configured to perform early retransmissions of SIP non-INVITE messages in accordance with some embodiments.
[0017] FIG. 2 is a block diagram illustrating example modes of an early SIP retransmission mechanism employed by the UE device of FIG. 1 in accordance with some embodiments.
[0018] FIG. 3 is a diagram illustrating an example hardware configuration of a UE device of the wireless system of FIG. 1 in accordance with some embodiments.
[0019] FIG. 4 illustrates a diagram of an example method of performing early retransmission techniques for SIP non-INVITE messages in accordance with some embodiments.
[0020] FIG. 5 is a diagram illustrating the signaling between devices for performing the early retransmission techniques for SIP non-INVITE messages in accordance with at least some embodiments.
[0021] FIG. 6 is a diagram illustrating the signaling between devices for performing the early retransmission techniques for SIP non-INVITE messages with respect to over-the-air (OTA) SIP-based communications in accordance with at least some embodiments.DETAILED DESCRIPTION
[0022] In many instances, a UE device sends a SIP non-INVITE message (request), such as a SIP BYE, SIP CANCEL, SIP OPTIONS, or SIP REGISTER message to the network. For example, when ending or terminating an IMS call, the UE device typically sends a SIP BYE message (e.g., when the call is in a connected state) or a SIP CANCEL message (e.g., during call setup before the call is connected) to the IMS network. However, sometimes the UE device does not receive a corresponding response from the IMS network, resulting in an unsynchronized IMS state between the UE device and the IMS network. The UE device may not receive a response to the SIP non-INVITE message from the IMS network for various reasons, such as an unsuccessful attempt to send the SIP non-INVITE message while changing its radio access technology (RAT) or the SIP non-INVITE message not being received or dropped at by IMS network due to an incorrect private (P)-access-network-info (PANI) header. For example, if the SIP non-INVITE message is attempted to be sentover a Long Term Evolution (LTE) RAT after an Evolved Packet System (EPS) fallback (EPSFB) event but the PANI header still indicates a New Radio (NR) RAT or if the SIP non-INVITE message is sent over an NR RAT after a handover event but the PANI still indicates an LTE or a Wireless Fidelity (Wi-Fi) RAT, the IMS network typically does not provide a response to the SIP non-INVITE message.
[0023] The unsynchronized IMS state between the UE device and the IMS network can result in a poor user experience or the eventual failure to perform the operation associated with the SIP non-INVITE message. For example, consider a scenario where the UE device ends and clears a current IMS call at the UE device and attempts to send a SIP BYE message while changing from an NR RAT to an LTE RAT. In this example, the UE device is not successful in sending out the SIP BYE message or the UE device sends the SIP BYE message over LTE but with a PANI header indicating the NR RAT resulting in the IMS network dropping the SIP BYE message. Although the UE device has cleared the IMS call at the UE device side, the IMS network still maintains the dedicated bearer for the IMS call since it did not receive or process the SIP BYE message. Therefore, when the UE device sends a SIP INVITE message to the IMS network for initiating another IMS call on the new RAT, the UE device receives an error message from the IMS network. The UE device typically needs to wait a period of time (e.g., 3 to 6 minutes) until the IMS network clears the old IMS call at the network side before the UE device is able to initiate another IMS call on the new RAT successfully. This delay results in a poor user experience because the user needs to wait for a noticeable amount of time before the new IMS call is successfully established.
[0024] As such, the following describes embodiments of systems and methods for a UE device to perform an early SIP retransmission process when a response is not received from the IMS network for a SIP non-INVITE message sent by the UE device. The early SIP retransmission process of one or more embodiments allows the UE device to reduce the wait time before the operation associated with the SIP non- INVITE message is successfully completed by the UE device and IMS network, and to also reduce the wait time typically imposed by conventional retransmission mechanisms before the SIP non-INVITE message can be retransmitted. Forexample, if the SIP non-INVITE message is a SIP BYE (or CANCEL) message, the UE device is able to retransmit the SIP BYE message when the UE device determines that a response from the IMS network has not been received. By performing the retransmission process described herein, the UE device increases the likelihood that the network will process the SIP BYE so that the UE device is able to initiate another IMS call without continually receiving error messages from the IMS network and having to wait until the network clears the original IMS call at the network side based on, for example, the expiration of a session timer.
[0025] As described in greater detail below, a RAT module (e.g., an LTE RAT module, an NR RAT module, a Wi-Fi RAT module, or the like) of a UE device sends a message or notification to an early SIP retransmission module of the UE device indicating that the current IMS RAT has been changed. For example, if the active (current) IMS RAT has been changed from the NR RAT to the LTE RAT, the active LTE RAT module sends a message to the early SIP retransmission module indicating that the active IMS RAT has been changed to the LTE RAT. In response to this message, the SIP non-INVITE retransmission manager checks if any SIP non-INVITE messages that were previously attempted to be sent have not received a corresponding SIP response from the IMS network. If so, the SIP non-INVITE retransmission manager selects the SIP message for retransmission and updates the PANI header of the selected SIP message based on the current IMS RAT.
[0026] When the active RAT module determines that an IMS session context (e.g., a default IMS bearer is ready or an IMS connection over the Evolved Packet Data Gateway (ePDG) is ready) is ready for the active RAT, the active RAT module sends the SIP non-INVITE retransmission manager a message or notification indicating the IMS session context is ready. In at least some embodiments, one or more RAT modules or another component of the UE device 102 implements a state machine to monitor or track the default IMS bearer or IMS connection state. In response to receiving this message from the active RAT module, the early SIP retransmission module immediately (i.e. , without actively waiting for a specified period of time) retransmits the selected SIP non-INVITE message using the active IMS RAT. For example, after an EPSFB, the SIP non-INVITE message is sent over LTE with anLTE RAT PANI header, or after handover to Wi-Fi, the SIP non-INVITE message is sent over Wi-Fi with a Wi-Fi PANI header. This retransmission is referred to herein as an “early” retransmission because the UE device retransmits the SIP non-INVITE message without actively waiting for a specified period of time and, in at least some embodiments, the UE device retransmits the SIP non-INVITE message prior to the expiration of a specified retransmission time interval as defined by one or more specifications, such as the Request for Comments (RFC) 2543 Specification published by the Internet Engineering Task Force (IETF) in March 1999 or the RFC 3261 Specification published by the IETF in June 2002. For example, if the specification indicates that the UE device is to wait 4 seconds before retransmitting a SIP non-INVITE message, the early SIP retransmission module is configured to retransmit the SIP non-INVITE message before the 4-second internal has expired. In at least some embodiments, the UE device performs the SIP non-INVITE early retransmission process a specified number of times (e.g., one time) per RAT change. In these embodiments, when the maximum number of SIP non-INVITE early retransmissions has been reached and a SIP response for the SIP retransmission has not been received from the network, the UE device performs retransmission according to one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification). For example, UE device performs retransmissions of the SIP non-INVITE message according to the retransmission time intervals defined by the one or more specifications.
[0027] For ease of illustration, the following techniques are described in an example context in which one or more UE devices and one or more RANs implement at least a Fifth Generation (5G) New Radio (NR) standard (e.g., Third Generation Partnership Project (3GPP) Release 15, 3GPP Release 16, etc.) (hereinafter, "5G NR" or"5G NR standard"). However, it should be understood that the present disclosure is not limited to networks employing a 5G NR RAT configuration, but rather the techniques described herein can be applied to any combination of different RATs employed at the UE devices and the RANs. It should also be understood that the present disclosure is not limited to any specific network configurations or architectures described herein for implementing radio link failure detection at the UE. Instead, techniques described herein can be applied to any configuration of RANs. Also, thepresent disclosure is not limited to the examples and context described herein, but rather the techniques described herein can be applied to any network environment where a UE device implements SIP INVITE error recovery techniques.
[0028] FIG. 1 illustrates a mobile cellular network (system) 100 in accordance with at least some embodiments. As shown, the mobile cellular network 100 includes a user equipment (UE) device 102 that is configured to communicate with one or more base stations (BSs) 104 (illustrated as BS 104-1 and BS 104-2) through one or more wireless communication links 106 (illustrated as wireless links 106-1 and 106-2). The UE device 102, in at least some embodiments, includes any of a variety of wireless communication devices, such as a cellular phone, a cellular-enabled tablet computer or cellular-enabled notebook computer, a cellular-enabled wearable device, an automobile, or other vehicle employing cellular services (e.g., for navigation, provision of entertainment services, in-vehicle mobile hotspots, etc.), and so on. In at least some embodiments, the UE device 102 employs a single RAT 108. In other embodiments, the UE device 102 is a multi-mode UE device that employs multiple RATs 108 (illustrated as RAT 108-1 and RAT 108-2). Examples of multiple RATs include cellular-based RATS, such as a 3GPP Long-Term Evolution (3GPP LTE) RAT and a 3GPP Fifth Generation New Radio (5G NR) RAT, a Wi-Fi RAT, and the like. It should be understood that although FIG. 1 only shows the UE device 102 implementing two different RATs 108, the UE device 102, in at least some implementations, implements three or more different RATs 108. In at least some embodiments, one or more RAT modules 136 (illustrated as RAT module 136-1 and RAT module 136-2) manage the RATs 108 and enable communication between the UE device 102 and the radio access technology of the network 100. The one or more RAT modules 136, in at least some embodiments, include one or more of a modem chipset(s) of the UE device 102, a protocol stack(s), driver software, or the like.
[0029] In at least some embodiments, the BSs 104 are implemented in a macrocell, microcell, small cell, picocell, and the like, or any combination thereof. Examples of base stations 104 include an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B), Evolved Node B (eNodeB or eNB), Next Generation(NG or NGEN) Node B (gNode B or gNB), and so on. The BSs 104 communicate with the UE device 102 via the wireless links 106, which are implemented using any suitable type of wireless link. The wireless links 106, in at least some embodiments, include a downlink of data and control information communicated from the base stations 104 to the UE device 102, an uplink of data and control information communicated from the UE device 102 to the BSs 104, or both. In at least some embodiments, the wireless links 106 (or bearers), such as data radio bearers (DRBs) and signal radio bearers (SRBs), are implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP 4G LTE, 5G NR, and so on. In at least some embodiments, multiple wireless links 106 are aggregated in a carrier aggregation to provide a higher data rate for the UE device 102. Also, multiple wireless links 106 from multiple base stations 104 are configured, in at least some embodiments, for coordinated multipoint (CoMP) communication with the UE device 102, as well as dual connectivity, such as single-RAT LTE-LTE or NR-NR dual connectivity, or multi-radio access technology (Multi-RAT) dual connectivity (MR-DC) including E-UTRA-NR dual connectivity (EN- DC), NGEN radio access network (RAN) E-UTRA-NR dual connectivity (NGEN-DC), and NR E-UTRA dual connectivity (NE-DC).
[0030] The BSs 104 collectively form a Radio Access Network (RAN) 110, such as an E-UTRAN or 5G NR RAN. The base stations 104 are connected to a core network (CN) 112 (illustrated as CN 112-1 and CN 112-2) via control-plane and userplane interfaces through one or more links 114 (illustrated as link 114-1 and link 114- 2). Depending on the configuration of the mobile cellular network 100, the core network 112 is either an Evolved Packet Core (EPC) network 112-1 or a 5G Core Network (5GC) 112-2. For example, in an E-UTRAN configuration or a 5G non- standalone (NSA) EN-DC configuration, the core network 112 is an EPC network 112-1 that includes, for example, a Mobility Management Entity (MME) 116, a Serving Gateway (SGW) 118, and a Packet Data Network Gateway (PGW) 120. The MME 116 provides control-plane functions, such as registration and authentication of multiple UE devices 102, authorization, mobility management, and so on. The SGW 118 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The PGW 120 provides connectivity from the UE device 102 to externalpacket data networks 122, such as the Internet 124 and an IMS network 126, by being the point of exit and entry of traffic for the UE device 102. In a 5G standalone (SA) configuration or an NSA NE-DC or NGEN-DC configuration, the core network 112 is a 5GC network 112-2. The 5GC 112-2 includes, for example, an Access and Mobility Management function (AMF) 128 and a User Plane Function (UPF) 130, and a Session Management Function (SMF) 132. The AMF 128 provides control-plane functions such as registration and authentication of multiple UE devices 102, authorization, mobility management, and so on. The UPF 130 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The SMF 132 manages protocol data unit (PDU) sessions.
[0031] In at least some embodiments, the core network 112 communicatively couples the UE device 102 to an IMS network 126 via the RAN 110. The IMS network 126 provides various IMS services to the UE device 102, such as IMS short messages, IMS unstructured supplementary service data (USSD), IMS value-added service data, IMS supplementary service data, IMS voice calls, and IMS video calls. To this end, an entity (e.g., a server or a group of servers) operating in the IMS network 126 supports packet exchange with the UE device 102. The packets convey signaling (such as session initiation protocol (SIP) messages, IP messages, or other suitable messages) as well as data (or media), such as voice or video. In at least some embodiments, the IMS network includes entities (not shown) such as a Proxy Call Session Control Function (P-CSCF), an Interrogating Call Session Control Function (l-CSCF), a Serving Call Session Control Function (S-CSCF), a Home Subscriber Server (HSS), a Media Gateway Control Function (MGCF), and the like.
[0032] As described above, the UE device 102 sends SIP non-INVITE messages (e.g., SIP BYE messages, SIP CANCEL messages, SIP OPTIONS messages, SIP REGISTER messages, or the like) to the IMS network 126 for initiating or performing one or more IMS-based procedures. For example, the UE device 102 sends a SIP BYE message to the IMS network 126 to terminate an established IMS session, a SIP CANCEL message to terminate a pending SIP transaction, a SIP OPTIONS message to query another SIP entity (e.g., another UE device, a network component, or the like) about its capabilities, or a SIP REGISTER message to notify the IMSnetwork 126 of the current location and contact information of the UE device 102. However, in some instances, lower layer (e.g., Transport, Session, etc.) issues between the UE device 102 (e.g., originating UE device) and the terminating UE device, issues at or below the transport layer protocol (e.g., Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)) tunnel, issues in the network 100, or the like, result in an unsuccessful transmission of the SIP non-INVITE message. For example, if these (or other) issues occur while the UE device 102 is attempting to transmit a SIP non-INVITE message during a RAT change (or shortly thereafter) from RAT 108-1 to RAT 108-2, this transmission is typically unsuccessful and the IMS network 126 does not receive the message, or the UE device 102 is able to send the SIP non-INVITE message but sends the message with the access-type field of the PANI header (or similar field of another header) indicating the previous RAT 108 (e.g., RAT 108-1) instead of the currently active RAT 108 (e.g., RAT 108-2), resulting in the IMS 126 dropping the SIP non-INVITE message. In either situation, the UE device 102 does not receive a corresponding SIP response from the IMS network 126, such as a SIP 200 message, a SIP 403 message, a SIP 486 message, a SIP 487 message, a SIP 500 message, a SIP 503 message, a SIP 600 message, or the like. Therefore, the IMS state between the UE device 102 and the IMS network 126 is unsynchronized.
[0033] When the IMS state between the UE device 102 and the IMS network 126 is unsynchronized, subsequent SIP-based operations are performed by the UE device 102 using, for example, RAT 108-2 even though the IMS network 126 is still managing services for the UE device 102 based on the RAT 108-2. For example, when the UE device 102 sends a SIP BYE message to the IMS network 126, the UE device 102 clears a current (first) IMS call at the UE side. However, if the SIP BYE message is sent during a RAT change (i.e. , switching from RAT 108-1 to a RAT 108- 2), the IMS network 126 may not receive the SIP BYE message or may drop the SIP BYE message if the message was sent over the RAT 108-2 but with a PANI header for RAT 108-1. Therefore, the IMS network 126 continues to maintain the bearer for the IMS call established using RAT 108-1. As such, when the UE device 102 sends a subsequent SIP INVITE message to the IMS network 126 for establishing a new (second) IMS call using the RAT 108-2, the IMS network 126 will deny this requestsince the IMS network 126 has not cleared the first call at the network side. The UE device 102 can either wait until the IMS network 126 clears the first call when a session timer expires or can attempt to retransmit the SIP BYE message according to one or more specifications (e.g., the RFC 2543, Specification, the RFC 3261 Specification, or the like). However, both options can result in a noticeable delay when attempting to establish the new IMS call, which leads to a poor user experience or the eventual failure to establish the new IMS service with the IMS network 126
[0034] Therefore, the UE device 102 of one or more embodiments employs at least one early SIP retransmission mechanism 134 for retransmitting SIP non-INVITE messages that have not received a corresponding SIP response from the IMS network 126. In at least some embodiments, the early SIP retransmission mechanism 134 performs the retransmission in response to one or more of a RAT change occurring at the UE device 102 or when the IMS session context (e.g., a default IMS bearer or IMS connection) is ready for the currently active RAT 108 (e.g., RAT 108-2). The early SIP retransmission mechanism 134 retransmits a SIP non- INVITE message to the IMS network 126 earlier than if the UE device 102 followed a specification, such as the RFC 2543 or the RFC 3261 . For example, if the specification defines an interval indicating that the UE device 102 is to wait 10 seconds before retransmitting the SIP non-INVITE message, the early SIP retransmission mechanism 134 is able to retransmit the message before the 10- second interval expires. As such, the early SIP retransmission mechanism 134 reduces the wait time before the operation associated with the SIP non-INVITE message is successfully completed by the UE device 102 and the IMS network 126, and also reduces the wait time typically imposed by conventional retransmission mechanisms before retransmitting the SIP non-INVITE message.
[0035] For example, FIG. 2 illustrates various example modes employed singularly or in various combinations by the UE device 102 as part of the early SIP retransmission mechanism 134 in accordance with at least some embodiments.Each of these modes is discussed in greater detail below with respect to FIG. 3 to FIG. 4. One such mode includes a first early SIP retransmission mode 202. During this mode, the early SIP retransmission mechanism 134 monitors for SIP non-INVITEmessages that are pending or waiting for an IMS response, i.e., SIP non-INVITE messages that have not received an IMS response from the IMS network 126 that have not received a corresponding IMS response from the IMS network 126. For example, during this mode, the early SIP retransmission mechanism 134, in at least some embodiments, maintains a list or other data structure of SIP non-INVITE messages attempted to be transmitted by the UE device 102. When an IMS response is received from the IMS network 126 for a SIP non-INVITE message, the early SIP retransmission mechanism 134 updates the list to indicate that an IMS response has been received. In other embodiments, if an IMS response for a SIP non-INVITE message has not been received within a specified threshold amount of time, the early SIP retransmission mechanism 134 updates the list to indicate that the SIP non-INVITE message has not received an IMS response. In alternative embodiments, the list only tracks SIP non-INVITE messages that have not received an IMS response from the IMS network 126. It should be understood that other methods for monitoring or tracking SIP non-INVITE messages are also applicable.
[0036] Another mode includes a second early SIP retransmission mode 204. During this mode, the early SIP retransmission mechanism 134 monitors for RAT changes at the UE device 102. For example, the early SIP retransmission mechanism 134 monitors for messages, notifications, or signals received from one or more RAT modules 136, such as an LTE RAT module, a 5G NR RAT module, a WiFi RAT module, or the like. In at least some embodiments, when the early SIP retransmission mechanism 134 detects a RAT change, this detection triggers the early SIP retransmission mechanism 134 to monitor for SIP non-INVITE messages that have not received an IMS response from the IMS network 126. However, in other embodiments, the early SIP retransmission mechanism 134 monitors for the SIP non-INVITE messages before or independent of a RAT change occurring at the UE device 102.
[0037] An additional mode includes a third IMS early SIP retransmission mode 206. During this mode, the early SIP retransmission mechanism 134 generates one or more SIP non-INVITE messages for retransmission. For example, when the early SIP retransmission mechanism 134 determines that a previously transmitted SIPnon-INVITE message has not received an IMS response, the mechanism 134 generates a corresponding new SIP non-INVITE message or updates the previously transmitted SIP non-INVITE message, each having a PANI header indicating the current RAT 108.
[0038] A further mode includes a fourth IMS early SIP retransmission mode 208. During this mode, the early SIP retransmission mechanism 134 implements one or more early retransmission procedures for the generated SIP non-INVITE message(s). For example, when the early SIP retransmission mechanism 134 receives a message, notification, or signal from one or more of the RAT modules 136 that an IMS context session (e.g., a default IMS bearer or an IMS connection) is ready for the active RAT 108 (e.g., RAT 108-2), the mechanism 134 immediately (i.e., without actively waiting for a specified period of time) retransmits the generated SIP non- INVITE message using the current RAT 108. In other embodiments, the early SIP retransmission mechanism 134 retransmits the generated SIP non-INVITE message(s) independent of receiving an indication that IMS context session is ready or in response to another condition, such as an IMS re-registration event.
[0039] FIG. 3 illustrates an example device diagram 300 of a UE device 102. In at least some embodiments, the device diagram 300 describes a UE device that implements the early SIP non-INVITE message retransmission techniques described herein. The UE device 102 may include additional functions and interfaces that are omitted from FIG. 3 for the sake of clarity. The UE device 102, in at least some embodiments, includes antennas 302, a radio frequency (RF) front end 304, and one or more RF transceivers 306 (e.g., a 3GPP 4G LTE transceiver 306-1 and a 5G NR transceiver 306-2) for communicating with one or more base stations 104 in a RAN 110, such as a 5G RAN, an E-UTRAN, a combination thereof, and so on. The RF front end 304, in at least some embodiments, includes a transmitting (Tx) front end 304-1 and a receiving (Rx) front end 304-2. The Tx front end 304-1 includes components such as one or more power amplifiers (PA), drivers, mixers, filters, and so on. The Rx front end 304-2 includes components such as low-noise amplifiers (LNAs), mixers, filters, and so on. The RF front end 304, in at least some embodiments, couples or connects the one or more transceivers 306, such as theLTE transceiver 306-1 and the 5G NR transceiver 306-2, to the antennas 302 to facilitate various types of wireless communication.
[0040] In at least some embodiments, the antennas 302 of the UE device 102 include an array of multiple antennas configured similarly to or different from each other. The antennas 302 and the RF front end 304, in at least some embodiments, are tuned to or are tunable to one or more frequency bands, such as those defined by the 3GPP LTE, 3GPP 5G NR, IEEE wireless local area network (WLAN), IEEE wireless metropolitan area network (WMAN), or other communication standards. In at least some embodiments, the antennas 302, the RF front end 304, the LTE transceiver 306-1 , and the 5G NR transceiver 306-2 are configured to support beamforming (e.g., analog, digital, or hybrid) or in-phase and quadrature (l / Q) operations (e.g., I / Q modulation or demodulation operations) for the transmission and reception of communications with one or more base stations 104. By way of example, the antennas 302 and the RF front end 304 operate in sub-gigahertz bands, sub-6 GHz bands, above 6 GHz bands, or a combination of these bands defined by the 3GPP LTE, 3GPP 5G NR, or other communication standards.
[0041] In at least some embodiments, the antennas 302 include one or more receiving antennas positioned in a one-dimensional shape (e.g., a line) or a two- dimensional shape (e.g., a triangle, a rectangle, or an L-shape) for implementations that include three or more receiving antenna elements. While the one-dimensional shape enables the measurement of one angular dimension (e.g., an azimuth or an elevation), the two-dimensional shape enables two angular dimensions to be measured (e.g., both azimuth and elevation). Using at least a portion of the antennas 302, the UE device 102 can form beams that are steered or un-steered, wide or narrow, or shaped (e.g., as a hemisphere, cube, fan, cone, or cylinder). The one or more transmitting antennas may have an un-steered omnidirectional radiation pattern or may produce a wide steerable beam. Either of these techniques enables the UE device 102 to transmit a radio signal to illuminate a large volume of space. In some embodiments, the receiving antennas generate thousands of narrow steered beams (e.g., 2000 beams, 4000 beams, or 6000 beams) with digital beamforming to achieve desired levels of angular accuracy and angular resolution.
[0042] The UE device 102, in at least some embodiments, includes one or more sensors 308 implemented to detect various properties such as one or more of temperature, supplied power, power usage, battery state, or the like. Examples of sensors include a thermal sensor, a battery sensor, a power usage sensor, and so on.
[0043] The UE device 102 also includes at least one processor 310. The processor 310, in at least some embodiments, is a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. In at least some embodiments, the processor 310 is implemented at least partially in hardware, including, for example, components of an integrated circuit or a system-on-a-chip (SoC), a digital-signal-processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), other implementations in silicon or other hardware, or a combination thereof.
[0044] Examples of the processor(s) 310 include a communication processor, an application processor, microprocessors, DSPs, controllers, and so on. A communication processor, in at least some embodiments, is implemented as a modem baseband processor, software-defined radio module, configurable modem (e.g., multi-mode, multi-band modem), wireless data interface, wireless modem, or so on. In at least some embodiments, a communication processor supports one or more of data access, messaging, or data-based services of a wireless network, as well as various audio-based communication (e.g., voice calls). An application processor, in at least some embodiments, provides computing resources to applications executing on the UE device 102. For example, an application provides a self-contained operating environment that delivers system capabilities (e.g., graphics processing, memory management, and multimedia processing) to support applications executing on the UE device 102.
[0045] The UE device 102 further includes a non-transitory computer-readable storage media 312 (CRM 312). The computer-readable storage media described herein excludes propagating signals. The CRM 312, in at least some embodiments, includes any suitable memory or storage device such as random-access memory(RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data 314 of the UE device 102. In at least some embodiments, the device data 314 includes user data, multimedia data, beamforming codebooks, applications 316, a user interface(s) 318, an operating system of the UE device 102, and so on, which are executable by the processor(s) 310 to enable user-plane communication, control-plane signaling, and user interaction with the UE device 102. The user interface 318, in at least one embodiment, is configured to receive inputs from a user of the UE device 102, such as to receive input from a user that defines and or facilitates one or more aspects of adverse radio link condition detection. In at least some embodiments, the user interface 318 includes a graphical user interface (GUI) that receives the input information via a touch input. In other instances, the user interface 318 includes an intelligent assistant that receives the input information via an audible input or speech. Alternatively, or additionally, the operating system of the UE device 102 is maintained as firmware or an application on the CRM 312 and executed by the processor(s) 310.
[0046] The CRM 312, in at least some embodiments, the CRM 312 further includes a SIP non-INVITE message list 320 and either or both of a communication manager 322 and an early SIP retransmission module 324. Alternatively, or additionally, either or both of the communication manager 322 and the early SIP retransmission module 324, in at least some embodiments, are implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the UE device 102. The SIP non-INVITE message list 320 (also referred to herein as “list 320”) is a list or other data structure that maintains an indication of SIP non-INVITE messages attempted to be transmitted by the UE device 102. In at least some embodiments, the list 320 monitors or tracks all SIP non-INVITE messages or at least a specified number of the most recent SIP non-INVITE messages attempted to be transmitted by the UE device 102. In other embodiments, the list 320 only maintains the SIP non- INVITE messages that have not received an IMS response from the IMS network 126 within a specified threshold amount of time. In at least some embodiments, the list 320 includes an entry for each SIP non-INVITE message being monitored. An entry for a SIP non-INVITE message, in at least some embodiments, includes an identifier uniquely identifying the message, a hash representing the message, headers of themessage, the contents of the message, a copy of the message in its entirety, or any other information that allows the early SIP retransmission module 324 to retrieve or recreate the original SIP non-INVITE message or generate a new SIP non-INVITE message corresponding to the monitored SIP non-INVITE message.
[0047] In at least some embodiments, the communication manager 322 configures the RE front end 304, the LTE transceiver (modem) 306-1 , the 5G NR transceiver (modem) 306-2, or a combination thereof, to perform one or more wireless communication operations. The early SIP retransmission module 324, in at least some embodiments, implements the early SIP retransmission mechanism 134 for retransmitting SIP non-INVITE messages that have not received a corresponding SIP response from the IMS network 126 earlier than that allowed by conventional retransmission mechanisms. For example, the early SIP retransmission module 324 is configured to operate in one or more modes, including the first mode 202, in which SIP non-INVITE message transmissions are monitored to detect messages that have not received a corresponding IMS response from the IMS network 126, the second mode 204 in which RAT changes at the UE device 102 are monitored for, the third mode 206 in which one or more SIP non-INVITE messages for are generated retransmission, and the fourth mode 208 in which early retransmission of the generated one or more SIP non-INVITE messages is performed.
[0048] In more detail, when the UE device 102 attempts to transmit a SIP non- INVITE message to the IMS network 126, the early SIP retransmission module 324 updates the SIP non-INVITE message list 320 with an entry for this SIP non-INVITE message. This entry is an indication that an attempt was made to transmit the SIP non-INVITE message. In at least some embodiments, when an IMS response from the network 126 for a SIP non-INVITE message, the early SIP retransmission module 324 updates the entry in the list 320 for the SIP non-INVITE message to indicate that an IMS response was received. In other embodiments, after a specified threshold amount of time has passed, the early SIP retransmission module 324 determines if an IMS response has been received from the IMS network 126 for a SIP non-INVITE message. If not, the early SIP retransmission module 324 updates the entry in the list 320 for the SIP non-INVITE message to indicate that an IMS response has notbeen received. In at least some embodiments, the list 210 includes an indication that one or more SIP non-INVITE messages have received an IMS response from the network 126 and one or more SIP non-INVITE messages have not received an IMS response from the network 126. In other embodiments, instead of creating an entry in the list 320 each time an attempt is made to transmit a SIP non-INVITE message, the early SIP retransmission module 324 creates an entry in the list only when the module 324 determines that a SIP non-INVITE message has not received an IMS response from the IMS network 126. Therefore, in these embodiments, the list 320 only includes entries for SIP non-INVITE messages that have not received an IMS response.
[0049] The early SIP retransmission module 324, in at least some embodiments, also monitors for RAT changes at the UE device 102. For example, the early SIP retransmission mechanism 134 monitors for an indication (e.g., a message, a notification, a signal, or the like) received from one or more RAT modules 136, such as an LTE RAT module a 5G NR RAT module, a Wi-Fi RAT module, or the like. In at least some embodiments, when the early SIP retransmission mechanism 134 detects a RAT change, this detection triggers the early SIP retransmission module 324 to monitor for SIP non-INVITE messages that have not received an IMS response from the IMS network 126. For example, in at least some embodiments, when the early SIP retransmission module 324 detects that a RAT change is occurring or has occurred, the early SIP retransmission module 324 adds an entry to the list 320 for any SIP non-INVITE message that was attempted to be transmitted during the RAT change or within a specified threshold amount of time after the RAT change occurred. When an IMS response from the network 126 is received or not received for the SIP non-INVITE message, the early SIP retransmission module 324 updates the entry in the list 320 for the SIP non-INVITE message, as described above.
[0050] The early SIP retransmission module 324 is also configured to generate a SIP non-INVITE message for early retransmission in response to a tracked SIP non- INVITE not receiving an IMS response from the IMS network 126. For example, in at least some embodiments, when the early SIP retransmission module 324 determines that a previously transmitted SIP non-INVITE message has not received an IMSresponse, the mechanism 134 generates a corresponding new SIP non-INVITE message or updates the previously transmitted SIP non-INVITE message, each having a PANI header indicating the currently active RAT 108, unlike conventional retransmission mechanisms, which typically retransmit the original message having the incorrect PANI header. In at least some embodiments, the updating of the list 320 to indicate that a SIP non-INVITE message has not received an IMS response acts as a trigger condition for the early SIP retransmission module 324 to generate the SIP non-INVITE message for early retransmission. In other embodiments, when the early SIP retransmission module 324 receives an indication (e.g., a message, notification, signal, or the like) from one or more of the RAT modules 136 that an IMS session context (e.g., a default IMS bearer or an IMS connection) is ready for the currently active RAT 108, this message acts as a trigger condition for the early SIP retransmission module 324 to generate the SIP non-INVITE message for early retransmission. However, it should be understood that other trigger conditions are also applicable.
[0051] In at least some embodiments, after the early SIP retransmission module 324 generates the SIP non-INVITE message for retransmission, the early SIP retransmission module performs an early retransmission of the SIP non-INVITE message. For example, instead of waiting a threshold period of time, such as 10 seconds, as defined by one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification) before retransmitting the SIP non-INVITE message, the early SIP retransmission module 324 immediately (i.e. , without actively waiting for a specified period of time) retransmits the SIP non-INVITE message. Stated differently, the early SIP retransmission module 324 retransmits the message before a specification defined retransmission interval expires. In at least some embodiments, the immediate retransmission of the SIP non-INVITE message is triggered by the early SIP retransmission module 324 receiving a message, notification, or signal from one or more of the RAT modules 136 that an IMS context session is ready for the new (current) RAT 108. Stated differently, when the early SIP retransmission module 324 receives this message from one or more of the RAT modules 136, the early SIP retransmission module 324 immediately retransmits a SIP non-INVITE message that has not received an IMS response from the IMS network126. As described above, the retransmitted SIP non-INVITE message is either a newly generated SIP non-INVITE message corresponding to a SIP non-INVITE message that has not received an IMS response or is an updated version of the original SIP non-INVITE message. Also, in at least some embodiments, the retransmitted SIP non-INVITE message includes an updated PANI (or similar header) indicating the current RAT in use by the UE device 102.
[0052] FIG. 4 illustrates an example method 400 for early retransmission techniques for SIP non-INVITE messages in accordance with at least some embodiments. The processes described below with respect to method 400 have been described above in greater detail with reference to FIG. 1 to FIG. 3. It should be understood that method 400 is not limited to the sequence of operations shown in FIG. 4, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 400 can include one or more different operations than those shown in FIG. 4. Also, although a SIP BYE message is used as one example of a SIP non-INVITE message to describe method 400, it should be understood that the early retransmission techniques are applicable to any SIP non-INVITE message.
[0053] In at least some embodiments, method 400 initiates at block 402 after the UE device 102 registers with the IMS network 126. For example, the UE device 102, in at least some embodiments, initially performs a PDU session establishment procedure with the CN 112 via the RAN 110 to establish a PDU Session for a packetbased service (e.g., the IMS service). For example, the UE device 102 sends a PDU Session Establishment Request message for establishing the PDU Session to the CN 112, and the CN 112 sends a PDU Session Establishment Accept message to the UE device 102 via the RAN 110 in response. After establishing the PDU Session, the UE device 102 performs a registration procedure with the IMS network 126 via the RAN 110 and CN 112 to register with the IMS network 126. For example, the UE device 102 sends a first SIP message (e.g., REGISTER message) to the IMS network 126 via the RAN 110 and CN 112 to perform the IMS registration procedure. In response, the IMS network 126 sends a second SIP message (e.g., 200 OK) to the UE device 102 via the RAN 110 and CN 112 to accept the registration. In otherembodiments, the UE device 102 performs a Transmission Control Protocol establishment procedure to register with the IMS network instead, or in addition to, the PDU session establishment procedure.
[0054] At block 402, the UE device 102 attempts to send a SIP non-INVITE message 401 to the IMS network 126 using a first RAT 108. For example, the UE device 102 sends a SIP BYE message to the IMS network 126. At block 404, the early SIP retransmission module 324 creates an entry 403 in the SIP non-INVITE message list 320 for the SIP non-INVITE message 401 attempted to be sent. As described above this entry 403 is an indication that an attempt was made to transmit the SIP non-INVITE message. At block 406, the early SIP retransmission module 324 detects a RAT change from RAT 108-1 (first RAT 108) to RAT 108-2 (second RAT 108). In at least some embodiments, the early SIP retransmission module 324 receives an indication 405 (e.g., a message, a notification, a signal, or the like) from one or more of the RAT modules 136 that the RAT for IMS services is switching or has been switched from RAT 108-1 to the RAT 108-2.
[0055] At block 408, in response to receiving the indication 405, the early SIP retransmission module 324 determines if any previously sent SIP non-INVITE messages 401 are still waiting for an IMS response from the network 126. As described above, the UE device 102 does not receive an IMS response from the IMS network 126 if the SIP non-INVITE message 401 was not successfully sent due to, for example, being sent during a RAT change, or if the IMS network 126 drops the SIP non-INVITE message 401 due to, for example, the SIP non-INVITE message being sent with the access-type field of the PANI header indicating RAT 108-1 instead of RAT 108-2f . In at least some embodiments, the early SIP retransmission module 324 determines if any previously sent SIP non-INVITE messages 401 are still waiting for an IMS response from the network 126 based on the SIP non-INVITE message list 320. For example, as described above, if the early SIP retransmission module 324 determines that the SIP non-INVITE message 401 has not received an IMS response within a specified threshold amount of time since its attempted transmission, the early SIP retransmission module 324 updates the entry 403 in the list 320 to indicate that the SIP non-INVITE message 401 has not received an IMSresponse. Alternatively, the early SIP retransmission module 324 refrains from updating the entry 403 in the list 320 when the specified threshold amount of time has passed, and this non-updated state of the entry 403 is an indication that a SIP non-INVITE message has not received an IMS response. In other embodiments, when a SIP non-INVITE message receives an IMS response from the IMS network 126, the early SIP retransmission module 324 removes the entry corresponding to the SIP non-INVITE message from the SIP non-INVITE message list 320. Therefore, in these embodiments, the SIP non-INVITE message list 320 only includes entries for SIP non-INVITE messages that have not received an IMS response.
[0056] If the early SIP retransmission module 324 determines that there are no SIP non-INVITE messages waiting for an IMS response, the process ends or returns to, for example, block 402 and the UE device 102 sends another SIP non-INVITE message to the IMS network 126. At block 410, if there are one or more SIP non- INVITE messages, such as SIP non-INVITE message 401 , waiting for an IMS response, the early SIP retransmission module 324 determines if a maximum number of early retransmissions has been reached. For example, in at least some embodiments, the early SIP retransmission module 324 increments a counter 407 each time an early retransmission is performed for a SIP non-INVITE message and compares this counter 407 to the maximum number threshold. At block 412, if the maximum number of early retransmissions has been reached, the early SIP retransmission module 324 does not perform an early retransmission for the SIP non- INVITE message 401 and the UE device 102 operates according to one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification).
[0057] For example, the UE device 102, in at least some embodiments, is configured to perform retransmissions of SIP non-INVITE messages according to a specification that defines specific intervals that the UE device 102 needs to wait until a retransmission can be attempted. In these embodiments, if the maximum number of early retransmissions has been reached, the UE device 102 performs retransmissions of the SIP non-INVITE messages according to the intervals defined by the specification. In at least some embodiments, if the specification defines a sequence of intervals, the UE device 102 continues on from the interval in thesequence where the last early retransmission occurred. For example, if the specification defines a sequence of intervals such as 1 second, 2, seconds, 4, seconds, 4, seconds, 4, seconds, etc. and the last early retransmission was performed 1 second into the first 4-second interval, the UE device 102 starts at the first 4-second interval (or a subsequent interval) instead of starting at the beginning of the interval sequence.
[0058] At block 414, if the maximum number of early retransmissions has not been reached, the early SIP retransmission module 324 generates a SIP non-INVITE message 409 for early retransmission. For example, in at least some embodiments, the early SIP retransmission module 324 generates SIP non-INVITE message 409 by generating a new SIP non-INVITE message corresponding to the SIP non-INVITE message 401 waiting for an IMS response or updates a stored copy of the previously transmitted SIP non-INVITE message 401. If the early SIP retransmission module 324 generates a new SIP non-INVITE message, the early SIP retransmission module 324 is able to use any relevant information maintained in the entry 403 of the SIP non-INVITE message list 320 for the previously transmitted SIP non-INVITE message 401 to generate the new SIP non-INVITE message. In at least some embodiments, the early SIP retransmission module 324 generates the new SIP non-INVITE message 409 with an updated PANI or similar header indicating the currently active RAT 108 (e.g., RAT 108-1) of the UE device 102. For example, if the SIP non- INVITE message 401 waiting for an IMS response was sent during the RAT change, the PANI (or similar) header of this message indicates the UE device 102 is using the RAT 108-1 instead of the RAT 108-2. However, the PANI (or similar) header of the SIP non-INVITE message 409 generated for early retransmission indicates that the UE device 102 is using RAT 108-2. In at least some embodiments, the early SIP retransmission module 324 stores the SIP non-INVITE message 409 generated for early retransmission in a queue 411 , other data structure, or in an unstructured portion of memory.
[0059] At block 416, the early SIP retransmission module 324 detects that an IMS session context 413, such as a default IMS bearer or an IMS connection, is ready for the second RAT. At block 418, the early SIP retransmission module 324 selects theSIP non-INVITE message 409 from the queue 411 and performs an early retransmission of the SIP non-INVITE message 409 using the second (current) RAT 108. If multiple SIP non-INVITE messages 409 are in the queue 411 , the early SIP retransmission module 324 selects one or more messages 409 from the queue using any selection technique. The retransmission performed by the early SIP retransmission module 324 is considered an “early” retransmission because the early SIP retransmission module 324 performs the retransmission immediately (i.e., without actively waiting for a specified period of time). Also, if the UE device 102 is configured to perform retransmission according to a specification (e.g., the RFC 2543 Specification or the RFC 3261 Specification), the early SIP retransmission module 324 retransmits the SIP non-INVITE message 409 without waiting for a retransmission interval defined the specification to expire. Stated differently, the early retransmission mode of the UE device 102 overrides the retransmission parameters defined by the specification(s) at least until, for example, the maximum number of early retransmission attempts is reached. For example, if the specification defines an interval indicating that the UE device 102 is to wait 10 seconds before retransmitting the SIP non-INVITE message 409, the early SIP retransmission mechanism 134 does not wait for the 10-second interval to expire and retransmits the message 409 before the 10-second interval expires (e.g., within 1 second of the 10-second interval). As such, the early retransmission of the SIP non-INVITE message 409 reduces the wait time before the operation associated with the SIP non-INVITE message 409 is successfully completed by the UE device 102 and IMS network 126 and also reduces the wait time before the SIP non-INVITE message 409 can be retransmitted typically imposed by conventional retransmission mechanisms.
[0060] In at least some embodiments, after the SIP non-INVITE message 409 is retransmitted, the process returns to block 404 and the early SIP retransmission module 324 tracks if the retransmitted message receives an IMS response from the IMS network, and the processes at blocks 406 to 418 are repeated. If the early SIP retransmission module 324 determines that the SIP non-INVITE message 409 (or another SIP non-INVITE message) did not receive an IMS response, the early retransmission processes described above are performed. However, if the early retransmission counter 407 indicates that a maximum number of earlyretransmissions has been performed for the original SIP non-INVITE message 401 (or the other SIP non-INVITE message), the UE device 102 reverts back to the retransmission procedures defined by one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification).
[0061] FIG. 5 is a diagram illustrating the signaling between devices for performing the early retransmission techniques for SIP non-INVITE messages described herein in accordance with at least some embodiments. The signaling and processes described below with respect to FIG. 5 have been described above in greater detail with reference to FIG. 1 to FIG. 4. It should be understood that one or more embodiments are not limited to the sequence of operations shown in FIG. 5, as at least some of the signaling and operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, embodiments can include one or more different operations than those shown in FIG. 5.
[0062] The early SIP retransmission module 324 of the UE device 102 sends a SIP non-invite message 401 with a PANI header based on the previous RAT 108 implemented by the UE device 102 to the IMS network 126. As described above, the early SIP retransmission module 324 creates an entry 403 in the SIP non-INVITE message list 320 for the SIP non-INVITE message 401 attempted to be sent. When a RAT change occurs at the UE device 102, one or more of the RAT modules 136 provides an indication 405 to the early SIP retransmission module 324 that the RAT 108 has changed. Based on this indication 405, the early SIP retransmission module 324 makes a determination 502 that the RAT has changed and determines 504 if any previously sent SIP non-INVITE messages 401 are still waiting for an IMS response from the IMS network 126. In at least some embodiments, the early SIP retransmission module 324 checks the SIP non-INVITE message list 320 to determine if any SIP non-INVITE message 401 has not received an IMS response within a specified threshold amount of time since its attempted transmission. If there are no SIP non-INVITE messages waiting for an IMS response, the process ends or the UE device 102 sends another SIP non-INVITE message to the IMS network 126.
[0063] If there are one or more previously transmitted SIP non-INVITE messages 401 still waiting for an IMS response, the early SIP retransmission module 324generates a SIP non-INVITE message 409 for early retransmission. One or more of the RAT modules 136 sends an indication 506 that an IMS session context 413, such as a default IMS bearer or an IMS connection, is ready for the current RAT 108. The early SIP retransmission module 324 selects a SIP non-INVITE message 409 and performs an early retransmission 508 of the SIP non-INVITE message 409 using the current RAT 108. As described above, the retransmitted SIP non-INVITE message 409 includes an updated PANI header for SIP non-INVITE message 409 based on the current RAT 108. The retransmission performed by the early SIP retransmission module 324 is considered an “early” retransmission because the early SIP retransmission module 324 performs the retransmission immediately (i.e., without actively waiting for a specified period of time). If a maximum number of early retransmissions has been performed for the original SIP non-INVITE message 401 (or the other SIP non-INVITE message) waiting for a response, or if no SIP non-invite messages 401 are waiting for an IMS response, the UE device 102 reverts 510 back to the retransmission procedures defined by one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification).
[0064] FIG. 6 is a diagram illustrating the signaling between devices for performing the early retransmission techniques for SIP non-INVITE messages with respect to over-the-air (OTA) SIP-based communications in accordance with at least some embodiments. The signaling and processes described below with respect to FIG. 6 have been described above in greater detail with reference to FIG. 1 to FIG. 4. It should be understood that one or more embodiments are not limited to the sequence of operations shown in FIG. 6, as at least some of the signaling and operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, embodiments can include one or more different operations than those shown in FIG. 6.
[0065] As part of an OTA SIP communication, the early SIP retransmission module 324 of the UE device 102 sends a SIP non-invite message 401 with a PANI header based on the previous RAT 108 implemented by the UE device 102 to the IMS network 126. In this example, an IMS response is not received from the IMS network 126 for the SIP non-invite message 401 and the early SIP retransmission module 324generates a SIP non-INVITE message 409 for early retransmission based on the SIP non-INVITE message 401 waiting for an IMS response. When the early SIP retransmission module 324 detects a RAT change 601 , the early SIP retransmission module 324 performs an early retransmission 603 of the SIP non-invite message 409. As described above, the retransmission performed by the early SIP retransmission module 324 is considered an “early” retransmission because the early SIP retransmission module 324 performs the retransmission immediately (i.e., without actively waiting for a specified period of time). The retransmitted SIP non-INVITE message 409 includes an updated PANI header based on the current RAT 108.
[0066] After the early retransmission of the SIP non-INVITE message 409, the UE device 102 reverts 605 back to the retransmission procedures defined by one or more specifications (e.g., the RFC 2543 Specification or the RFC 3261 Specification). For example, if the UE device 102 does not receive an I S response from the IMS network 126 for the early retransmitted SIP non-INVITE message 409, the UE device 102 retransmits the SIP non-INVITE message 409 according to, for example, the time intervals defined in the specification(s). The example shown in FIG. 6 shows a first retransmission 607 and a second retransmission 609 performed according to procedures defined by one or more specifications.
[0067] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium can include, for example, a magnetic or optical disk storage device, solid-state storage devices such as Flash memory, a cache, random access memory (RAM), or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer-readable storage medium may be in source code, assembly language code, object code, orother instruction format that is interpreted or otherwise executable by one or more processors.
[0068] A computer-readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc , magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer- readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).
[0069] Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.
[0070] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particularembodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.
Claims
WHAT IS CLAIMED IS:1 . A method for performing a retransmission procedure for session initiation protocol(SIP) messages at a user equipment (UE) device (102), the method comprising: receiving a first indication (405) indicating that a current radio access technology (RAT) (108) at the UE device has changed from a first RAT to a second RAT ; and responsive to receiving the first indication, retransmitting a SIP non-INVITE message (401) that is pending a response from an Internet Protocol Multimedia Subsystem (IMS) network (126).
2. The method of claim 1 , further comprising: storing an indication that the SIP non-INVITE message is pending the response from the IMS network.
3. The method of claim 2, wherein storing the indication is in response to determining that a threshold amount of time has expired without the SIP non-INVITE message having received a response from the IMS network.
4. The method of any one of claims 1 to 3, wherein retransmitting the SIP non-INVITE message comprises: retransmitting the SIP non-INVITE message with a header indicating that the UE device is currently using the second RAT.
5. The method of claim 4, wherein the header is a private-access-network-info header.
6. The method of any one of claims 1 to 5, further comprising: receiving a second indication from a RAT module (136-1 , 136-2) implementing the second RAT that an IMS session context (413) is ready for the second RAT.
7. The method of claim 6, wherein retransmitting the SIP non-INVITE message comprises: retransmitting the SIP non-INVITE message further in response to the second indication.
8. The method of claim 1 , wherein retransmitting the SIP non-INVITE message comprises: responsive to receiving the first indication, selecting the SIP non-INVITE message for retransmission; generating a new SIP non-INVITE message representing the SIP non-INVITE message and having a header indicating that the UE device is currently using the second RAT; and transmitting the new SIP non-INVITE message to the IMS network.
9. The method of any one of claims 1 to 8, wherein retransmitting the SIP non-INVITE message comprises: retransmitting the SIP non-INVITE message without actively waiting for a specified period of time before retransmitting the SIP non-INVITE message.
10. The method of any one of claims 1 to 9, wherein retransmitting the SIP non-INVITE message comprises: retransmitting the SIP non-INVITE message prior to a current retransmission interval defined by a specification having expired.11 . The method of any one of claims 1 to 10, further comprising: incrementing an early retransmission counter (407) after retransmitting the SIP non-INVITE message.
12. The method of claim 11 , further comprising: responsive to determining that at least one of the retransmitted SIP non- INVITE message or another SIP non-INVITE message is pending a response from the IMS network and the early retransmission counterindicating a maximum number of early retransmissions has occurred, performing a retransmission procedure for the at least one of the retransmitted SIP non-INVITE message or the other SIP non-INVITE message defined by one or more SIP specifications.
13. The method of claim 1 , wherein each of the first RAT and the second RAT are a different one of a cellular-based RAT or a Wireless Fidelity RAT.
14. A user equipment device (102), comprising: one or more radio frequency (RF) modems (306) configured to wirelessly communicate with at least one network (100); one or more processors (310) coupled to the one or more RF modems; and at least one memory (312) storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the method of any of the preceding claims.
15. A computer-readable storage medium (312) embodying a set of executable instructions, the set of executable instructions to manipulate a user equipment device (102) to perform the method of any of claims 1 to 13.