Methods and apparatus for setting internet protocol multimedia subsystem calls in mobile communications
Patent Information
- Application Number
- PCT/CN2026/088374
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-04-17
- Filing Date
- 2026-04-02
- Publication Date
- 2026-10-22
Smart Images
Figure CN2026088374_22102026_PF_FP_ABST
Abstract
Description
METHODS AND APPARATUS FOR SETTING INTERNET PROTOCOL MULTIMEDIA SUBSYSTEM CALLS IN MOBILE COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION (S)
[0001] The present disclosure is part of a PCT Application claiming the priority benefit of U.S. Patent Application No. 63 / 790, 174 filed 17 April 2025, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD
[0002] The present disclosure is generally related to wireless communications and, more particularly, to methods and apparatus for reducing signaling overhead in Internet Protocol Multimedia Subsystem (IMS) call procedures.BACKGROUND
[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.
[0004] The 3rd Generation Partnership Project (3GPP) standards define the Session Initiation Protocol (SIP) as the primary signaling protocol for Internet Protocol Multimedia Subsystem (IMS) services, including voice calls, video calls, and messaging. IMS has been standardized since 3GPP Release 15 as a common platform for providing voice and multimedia services, enabling interoperability and service continuity across heterogeneous access networks.
[0005] During an IMS call procedure, such as IMS call setup, a series of SIP messages is exchanged between a User Equipment (UE) and a network node (e.g., a Proxy Call Session Control Function, or P-CSCF) . A typical IMS call setup flow involves at least ten SIP messages, including INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, and ACK. In practice, the aggregate size of SIP messages transmitted in a single call setup procedure can reach approximately 9,000 bytes or more.
[0006] A key observation is that SIP messages exchanged for IMS calls within the same operator network are highly similar across different calls. Much of the content of each SIP message-such as header fields, routing information, media codec parameters, and SDP (Session Description Protocol) payloads-remains identical or nearly identical from one call to the next, resulting in substantial redundancy in repeated transmissions of long SIP message content.
[0007] This redundancy is particularly problematic in communication environments limited by low data rates or high latency. Starting from 3GPP Release 17, Geostationary Earth Orbit (GEO) satellite access has been incorporated as a 5G access technology. However, GEO satellite systems face inherent limitations, including a transmission distance of approximately 35, 786 km, one-way signal propagation delays of around 285 milliseconds, and constrained data transmission rates. In GEO Non-Terrestrial Network (NTN) environments, the available bitrate for signaling may be as low as 1 kbps. Under such constraints, transmitting the full content of ten SIP messages totaling approximately 9,000 bytes would require over 70 seconds to complete the call setup procedure-far exceeding the 30-second call setup Key Performance Indicator (KPI) requirement defined by 3GPP SA1 for IMS calls over GEO NTN.
[0008] Furthermore, in conventional IMS procedures, each new call requires full retransmission of complete SIP messages even when the content differs only slightly from previously transmitted messages.
[0009] Accordingly, there is a need for a method that allows a UE and a network node to exchange SIP messages so as to significantly reduce the amount of data transmitted per SIP message during an IMS call procedure, and thereby fulfill 3GPP call setup time requirements in bandwidth-constrained and high-latency communication environments.SUMMARY
[0010] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
[0011] An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issue pertaining to signaling for IMS calls.
[0012] In one aspect, a method may involve an apparatus transmitting a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call to a network node. The method may also involve the apparatus generating a simplified SIP message based on the first SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message. The method may further involve the apparatus transmitting the simplified SIP message to the network node.
[0013] In another aspect, a method may involve an apparatus receiving a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call from a user equipment (UE) . The method may also involve the apparatus receiving a simplified SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message. The method may further involve the apparatus determining, by the processor, a second SIP message for the second IMS call based on the first SIP message and the simplified SIP message.
[0014] It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as LTE, LTE-Advanced, LTE-Advanced Pro, 5G, NR, 5G-Advanced, Internet-of-Things (IoT) , Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , beyond 5G (B5G) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s) / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale, as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.
[0016] FIG. 1A illustrates a schematic system diagram of an example Non-Terrestrial Network (NTN) architecture in which a Geostationary Earth Orbit (GEO) satellite operates as a relay node without on-board processing capabilities, in accordance with aspects of the present disclosure.
[0017] FIG. 1B illustrates a schematic system diagram of an example Non-Terrestrial Network (NTN) architecture in which a GEO satellite is equipped with full core network functionalities and optionally IMS functionalities on board, in accordance with aspects of the present disclosure.
[0018] FIG. 2 is a diagram illustrating an example structure of a Session Initiation Protocol (SIP) message, comprising a starting line, a header field, a separator, and a message body, in accordance with an implementation of the present disclosure.
[0019] FIG. 3 is a flowchart illustrating an example process performed by a User Equipment (UE) for transmitting a simplified SIP message comprising a delta part for a second IMS call, in accordance with an implementation of the present disclosure.
[0020] FIG. 4 is a flowchart illustrating an example process performed by a network node for transmitting a simplified SIP message comprising a delta part for a second IMS call, in accordance with an implementation of the present disclosure.
[0021] FIG. 5 is a diagram illustrating an example comparison between a first SIP message for a first IMS call used as a baseline SIP message and a second SIP message for a second IMS call, highlighting the call-specific fields that differ between the two messages, in accordance with an implementation of the present disclosure.
[0022] FIG. 6 is a diagram illustrating an example structure of a simplified SIP message comprising a starting line, a Call-ID field, a CSeq field, and a delta part consisting of one or more delta entries, generated based on the comparison illustrated in FIG. 5, in accordance with an implementation of the present disclosure.
[0023] FIG. 7 is a signaling diagram illustrating a comparison of IMS call setup procedures between a UE and a network, showing the SIP message sizes and transmission times before and after application of the delta transfer mechanism of the present disclosure.
[0024] FIG. 8 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.
[0025] FIG. 9 is a flowchart of an example process in accordance with an implementation of the present disclosure.
[0026] FIG. 10 is a flowchart of another example process in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS
[0027] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview
[0028] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to signaling for IMS calls. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.
[0029] The techniques described in the disclosure may be applied to a variety of telecommunication systems utilizing IMS communication services, such as current 4G and 5G communications systems, or a next-generation communications system (e.g., 6G) . The IMS media described in the disclosure are not limited to voice but also include any real-time media types such as video, text, and applications. The UEs involved in the disclosure are not limited to mobile phones but can also include any device capable of providing IMS communication services, such as wearable devices, vehicular devices, Internet of Things (IoT) devices, and so on.
[0030] FIGS. 1A and 1B illustrate two schematic system diagrams that illustrate two example 3rd Generation Partnership Project (3GPP) NTN (Non-Terrestrial Network) architectures in accordance with aspects of the present disclosure.
[0031] FIG. 1A illustrates an NTN architecture in which the GEO satellite 102 does not include on-board processing capabilities, such as base station functionalities and / or core network (CN) functionalities. In this configuration, the GEO satellite 102 operates primarily as a relay node. Taking the UE transmission (Tx) direction as an example, the UE 101 on the ground first transmits data to the GEO satellite 102 through the service link 111. The GEO satellite 102 then forwards the data to a gateway 103 through the feeder link 112. After reaching the terrestrial network, the data is processed by a base station (BS) 104 via link 113, a core network 105 via link 114, and finally arrives at the IMS server 106 via link 115. The core network 105 may correspond to an evolved packet core (EPC) in a 4G communications system, a 5G core (5GC) in a 5G communications system, or a 6G core (6GC) in a 6G communications system.
[0032] FIG. 1B illustrates an NTN architecture in which the GEO satellite 102 is equipped with full CN functionalities, and may additionally include IMS functionalities on board. In this configuration, the communication path between the UE 101 and the IMS server 106 includes at least one GEO service link 111, and the IMS server 106 may be deployed directly on the GEO satellite 102.
[0033] It should be noted that the present disclosure is not limited to the NTN architectures illustrated in FIGS. 1A and 1B. Rather, the present disclosure may also be applied to other NTN configurations in which one or more satellites function as intermediary nodes along the data path between the UE and the IMS server.
[0034] As discussed above, SIP messages exchanged for IMS calls within the same operator network are highly similar across different calls. Much of the content of each SIP message remains identical or nearly identical from one call to the next, resulting in substantial redundancy in repeated transmissions of long SIP message content.
[0035] FIG. 2 is a schematic diagram illustrating an example structure of a SIP message 210 in accordance with an implementation of the present disclosure. As shown in FIG. 2, a SIP message 210 is composed of four distinct parts: a starting line, a header field, a separator (blank line) , and a message body.
[0036] The starting line is the first line of the SIP message 210 and identifies the type and purpose of the message. For a SIP request, the starting line is a request line that includes a method name (e.g., INVITE) , a Request-URI that identifies the destination (e.g., sip: sip2@sip. com) , and the SIP version (e.g., SIP / 2.0) . In some implementations, an SIP message used in the disclosed method may include a tag (e.g., “delta” or “diff” ) to identify the message as a delta SIP message (i.e., a simplified SIP message) . For a SIP response, the starting line is a status line that includes the SIP version, a three-digit status code, and a reason phrase. In the example shown in FIG. 2, the starting line is “INVITE sip: sip2@sip. com SIP / 2.0” , indicating that this is an INVITE request directed to the URI sip: sip2@sip. com using SIP version 2.0.
[0037] The header field follows the starting line and contains a set of header entries, each of which provides metadata and control information for the SIP message 210. As illustrated in FIG. 2, example header entries include: a Via header (e.g., “Via: SIP / 2.0 / UDP 10.0.100; branch=z9hG4bk1234” ) indicating the transport protocol, source address, and branch parameter used for routing; a Max-Forwards header (e.g., “Max-Forwards: 70” ) limiting the number of hops the message may traverse; a To header (e.g., “To: <sip: sip1@sip. com> “) identifying the intended recipient of the request; a From header (e.g., “From: <sip: sip2@sip. com>; tag=123456” ) identifying the originator of the request together with a tag parameter; a Call-ID header (e.g., “Call-ID: 3d45f59a12b54” ) providing a globally unique identifier for the call session; a CSeq header (e.g., “CSeq: 1 INVITE” ) carrying a sequence number and the method name for ordering requests within a dialog; a Contact header (e.g., “Contact: sip: 10.2.0.100: 5060” ) providing a direct URI for subsequent requests; a Content-Type header (e.g., “Content-Type: application / sdp” ) specifying the media type of the message body; and a Content-Length header (e.g., “Content-Length: 100” ) indicating the byte length of the message body.
[0038] Note that the header field of a SIP message carries a substantial amount of information. In practice, for IMS calls placed by the same UE to the same network operator, the majority of header field content-such as routing information, codec parameters, and transport protocol details-remains identical or nearly identical across successive calls. This high degree of similarity across successive SIP messages forms the basis for the delta transfer mechanism proposed in the present disclosure, as further described below.
[0039] The separator is a mandatory blank line (i.e., a Carriage Return + Line Feed (CRLF) sequence) that delimits the header field from the message body, as defined in RFC 3261. The separator allows a receiving entity to determine where the header field ends and the message body begins.
[0040] The message body follows the separator and carries the payload of the SIP message 210. For IMS call procedures (e.g., call setup, creating, update, modifying, terminating, or service invoking) , the message body typically contains a Session Description Protocol (SDP) offer or answer that describes the media parameters for the call session, such as media type, transport protocol, codec information, IP address, and port number. As shown in FIG. 2, an example message body entry includes an origin field (e.g., “o=-5894032 5894032 IN IP4 10.2.0.100” ) and a session name field (e.g., “s=SDP Media Session” ) , followed by additional SDP attributes. The full SDP content is omitted for brevity in FIG. 2.
[0041] The structure of a SIP message 210 illustrated in FIG. 2 is relevant to understanding the delta transfer mechanism of the present disclosure. Specifically, the delta SIP message (also referred to herein as the simplified SIP message) proposed in the present disclosure retains the starting line to identify the message type and is augmented with a delta part in place of the full header field and message body. The delta part encodes only the differences between a current SIP message and a previously synchronized baseline SIP message (i.e., the first SIP message) , thereby significantly reducing the total amount of data that must be transmitted for each IMS call setup. The structure and contents of the delta part are described in further detail in connection with FIG. 3 below.
[0042] FIG. 3 is a flowchart illustrating an example process performed by a User Equipment (UE) 101 in accordance with an implementation of the present disclosure. In the example, the UE 101 serves as a transmitting entity while the network node serves as the receiving entity. The process illustrated in FIG. 3 represents the UE-side procedure for transmitting a simplified SIP message comprising a delta part for a second IMS call, and may be implemented by a processor of the UE 101, such as processor 812 of communication apparatus 810 described below in connection with FIG. 8.
[0043] Step 301 (Optional) : The UE 101 and the network exchange capability information to indicate mutual support for the delta transfer mechanism. In some implementations, this capability exchange is performed during IMS registration, for example, by including a feature tag in the REGISTER message and receiving a corresponding confirmation from the network in the 200 OK response. Step 301 is optional (as indicated by the “Opt” label in FIG. 3) . In some implementations where both the UE 101 and the network are pre-configured to support the delta transfer mechanism, Step 301 may be omitted. In some implementations, the IMS registration process may involve interactions with multiple network nodes, including a Proxy Call Session Control Function (P-CSCF) , an Interrogating CSCF (I-CSCF) , a Serving CSCF (S-CSCF) , and a core network entity, such as a Home Subscriber Server (HSS) in 4G LTE or an access and mobility management function (AMF) in 5G NR.
[0044] Step 302: The UE 101 and the network synchronize initial messages. In some implementations, baseline message synchronization is performed during the first IMS call setup procedure following IMS registration, during which the UE 101 and the network exchange full SIP messages in accordance with conventional SIP procedures (e.g., as defined in RFC 3261) . For example, the UE 101 may transmit a first SIP message for a first IMS call to the network. The network receives the first SIP message. The full SIP messages exchanged during this first IMS call are stored by both the UE 101 and the network as baseline SIP messages (also referred to herein as first SIP messages) for their respective message types (e.g., INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, and ACK) .
[0045] Step 303: The UE 101 determines a full SIP message (referred to as a second SIP message) for a second IMS call and obtains a first SIP message (i.e., a baseline SIP message) for the second SIP message. Specifically, when the UE 101 prepares to initiate or respond to a second IMS call, the UE 101 generates a full SIP message corresponding to the second IMS call (referred to herein as a second SIP message) and identifies a stored baseline SIP message (e.g., the first SIP message) that is most similar to the second SIP message. In some implementations where a plurality of baseline SIP messages have been stored from prior IMS calls, the UE 101 selects the baseline SIP message that would yield the smallest delta part. In some implementations, a plurality of baseline SIP messages are categorized according to message types, such as INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK. The UE 101 selects the baseline SIP message and the second SIP message of the same message type.
[0046] Step 304: The UE 101 generates, for the second SIP message, a simplified SIP message to include a delta part. The simplified SIP message is generated based on the baseline SIP message (first SIP message) obtained in Step 303. The first SIP message and the simplified message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK. The simplified SIP message comprises a starting line, a Call-ID field, a header field indicating a sequence number of the simplified SIP message, and one or more delta entries constituting the delta part. Each delta entry specifies an action (e.g., replace, insert, or delete) , a target line number within the baseline SIP message, a character position within that line, a length indicating the number of characters to be modified, and replacement data where applicable. The delta part encodes only the differences between the second SIP message and the baseline SIP message. In some implementations, the action replace, insert, or delete may be coded as a single character, such as r, I, or d.
[0047] Step 305: The UE 101 evaluates the message size. Specifically, the UE 101 compares the size of the simplified SIP message generated in Step 304 with the size of the second SIP message. This evaluation ensures that the delta transfer mechanism is applied only when it results in a reduction in the amount of data to be transmitted. The delta transfer mechanism enables delta transfer operations, including the generation and transmission of the delta part and the simplified SIP message at the transmitting entity, reception of the simplified SIP message, and reproduction of the second SIP message at the receiving entity.
[0048] Step 306a (Alt1) : If the size of the simplified SIP message is smaller than the size of the second SIP message, the UE 101 transmits the simplified SIP message to the network. The network receives the simplified SIP message and determines the second SIP message for the second IMS call based on the first SIP message and the simplified SIP message. This is the primary path in which the delta transfer mechanism provides a benefit by reducing signaling overhead.
[0049] Step 306b (Alt2) : If the size of the simplified SIP message is not smaller than the size of the second SIP message (e.g., because the content of the second IMS call differs substantially from the baseline SIP message) , the UE 101 transmits the full second SIP message to the network in accordance with conventional SIP procedures. In some implementations, the full second SIP message transmitted in Alt2 may be stored as a new or updated baseline SIP message for use in subsequent IMS calls.
[0050] FIG. 4 is a flowchart illustrating an example process performed by a network node in accordance with an implementation of the present disclosure. The process illustrated in FIG. 4 represents the network-side procedure corresponding to the UE-side procedure of FIG. 3, and may be implemented by a processor of a network node, such as processor 822 of network apparatus 820 described below in connection with FIG. 8. The network node may be, for example, an IMS server, a P-CSCF, an S-CSCF, or another IMS network entity. In the example, the network node serves as a transmitting entity while the UE 101 serves as the receiving entity.
[0051] Step 401 (Optional) : The network and the UE 101 exchange capability information to indicate mutual support for the delta transfer mechanism. Step 401 corresponds to Step 301 in FIG. 3 and is similarly optional. In some implementations, this capability exchange is performed during IMS registration by including a feature tag in the network's 200 OK response to the UE's REGISTER message.
[0052] Step 402: The network and the UE 101 synchronize initial messages. Step 402 corresponds to Step 302 in FIG. 3. The network stores the full SIP messages exchanged during the first IMS call setup as baseline SIP messages for subsequent delta transfer operations. For example, the network may transmit a first SIP message for a first IMS call to the UE 101. The UE receives the first SIP message.
[0053] Step 403: The network determines a full SIP message (referred to as a second SIP message) for a second IMS call and obtains a first SIP message (i.e., a baseline SIP message) for the second SIP message. Specifically, when the network prepares to initiate or respond to a second IMS call, the network generates a full SIP message corresponding to the second IMS call (referred to herein as a second SIP message) , and identifies a stored baseline SIP message (e.g., the first SIP message) that is most similar to the second SIP message. In some implementations where a plurality of baseline SIP messages have been stored from prior IMS calls, the network selects the baseline SIP message that would yield the smallest delta part.
[0054] When the network receives a simplified SIP message from the UE 101 for a second IMS call, the network identifies the corresponding stored baseline SIP message to be used for reconstructing the full second SIP message. The baseline SIP message to be used may be indicated by information carried in the simplified SIP message, such as the Call-ID field or the CSeq field.
[0055] Step 404: The network generates, for the second SIP message, a simplified message to include a delta part. The simplified SIP message is generated based on the baseline SIP message (first SIP message) obtained in Step 403. The first SIP message and the simplified message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK. The simplified SIP message comprises a starting line, a Call-ID field, a header field indicating a sequence number of the simplified SIP message, and one or more delta entries constituting the delta part. Each delta entry specifies an action (e.g., replace, insert, or delete) , a target line number within the baseline SIP message, a character position within that line, a length indicating the number of characters to be modified, and replacement data where applicable. The delta part encodes only the differences between the second SIP message and the baseline SIP message.
[0056] In some implementations, the network receives the simplified SIP message from the UE 101. In other implementations, the network may generate simplified SIP messages for transmission to the UE 101 in the downlink direction (e.g., for SIP responses such as 100 Trying, 183 Session Progress, 200 OK, and 180 Ringing) . In either case, the simplified SIP message includes a delta part encoding the differences between the second SIP message and the baseline SIP message. In some implementations, the simplified SIP message may additionally include a tag (e.g., tag 610 with a value “delta” or “diff” ) in the starting line or a designated header field to identify the message as a delta SIP message, thereby allowing the receiving entity to distinguish a delta SIP message from a conventional SIP message.
[0057] Step 405: The network evaluates the message size. Analogously to Step 305 in FIG. 3, the network compares the size of the simplified SIP message with the size of the second SIP message to determine which should be used for transmission.
[0058] Step 406a (Alt1) : If the size of the simplified SIP message is smaller than the size of the second SIP message, the network transmits the simplified SIP message to the UE 101. In the downlink direction (i.e., for SIP responses originated by the network) , this step involves the network transmitting to the UE 101 a simplified SIP message comprising a delta part, from which the UE 101 reconstructs the full SIP response by applying the delta entries to the corresponding stored baseline SIP message.
[0059] Step 406b (Alt2) : If the size of the simplified SIP message is not smaller than the size of the second SIP message, the network transmits the full second SIP message to the UE 101 in accordance with conventional SIP procedures.
[0060] It will be appreciated that the processes illustrated in FIG. 3 and FIG. 4 are symmetric: both the UE 101 and the network apply the delta transfer mechanism to reduce the size of SIP messages transmitted in both the uplink and downlink directions, thereby reducing total signaling overhead for the IMS call setup procedure in both directions.
[0061] FIG. 5 is a diagram illustrating an example of baseline message synchronization and delta part generation in accordance with an implementation of the present disclosure. FIG. 5 shows two SIP messages side by side: a first SIP message 510 corresponding to the first IMS call (used as the baseline SIP message) , and a second SIP message 520 corresponding to the second IMS call.
[0062] The first SIP message 510 (baseline) comprises the following header lines: line 1 contains the starting line “INVITE tel: +86820 SIP / 2.0” ; line 2 contains the Via header “Via: SIP / 2.0 / TCP [2001: 468: 3000: 1: : ] 34508; branch=z9hG4bKe5cb1b665” ; line 3 contains the Route header “Route: <sip: [2100: 468: 3000: 2: 2001: 468: 3000: 2] : 40038; lr> “; line 4 contains the From header “From: <sip: Amarisoft-IMS-2024-12-13@amarisoft. com>; tag=z9hG4bKfff975562” ; line 5 contains the To header “To: <tel: +86820> “; line 6 contains the Call-ID header “Call-ID: 78749cc8056fc9ef” ; and line 7 contains the CSeq header “Cseq: 1 INVITE” . As indicated by reference numeral 511, a portion of line 2 (specifically the branch parameter value “z9hG4bKe5cb1b665” ) is call-specific and will differ in the second IMS call. As indicated by reference numeral 512, a portion of line 4 (specifically the tag parameter value “z9hG4bKfff975562” ) is likewise call-specific and will differ. As indicated by reference numeral 513, the Call-ID value “78749cc8056fc9ef” in line 6 is call-specific and will differ in the second IMS call.
[0063] The second SIP message 520 (for the second IMS call) has the same structure as the first SIP message 510, with the exception of three call-specific fields that differ between the two calls. Specifically, as indicated by reference numeral 521, the branch parameter in line 2 has changed to “z9hG4bK777993992” ; as indicated by reference numeral 522, the tag parameter in line 4 has changed to “z9hG4bK6984fb4a7” ; and as indicated by reference numeral 523, the Call-ID in line 6 has changed to “92cd77c2e4fdb8a3” . All other lines (lines 1, 3, 5, and 7) remain identical between the first SIP message 510 and the second SIP message 520.
[0064] The comparison of the first SIP message 510 and the second SIP message 520 illustrated in FIG. 5 demonstrates that the content of successive SIP messages for IMS calls placed by the same UE to the same network is highly similar, with only a small number of call-specific fields (such as the branch parameter, the tag parameter, and the Call-ID) differing between calls. The delta part of the simplified SIP message for the second IMS call, therefore, needs to encode only these three differences, resulting in a significantly reduced message size compared to a full SIP message. The specific delta entries generated from this comparison are illustrated in FIG. 6.
[0065] FIG. 6 is a diagram illustrating an example simplified SIP message 600 generated in accordance with the delta transfer mechanism of the present disclosure. The simplified SIP message 600 is an example of the delta SIP message in place of the full second SIP message 520 illustrated in FIG. 5.
[0066] The simplified SIP message 600 comprises six lines. Line 1 contains the starting line : “INVITE tel: +86820 SIP / 2.0 delta” . The starting line 610 retains the method name (INVITE) , the Request-URI (tel: +86820) , and the SIP version (SIP / 2.0) from the original second SIP message 520, and additionally includes the keyword “delta” (denoted by reference number 610) to identify the message as a delta SIP message, thereby allowing the receiving entity to distinguish the simplified SIP message 600 from a conventional SIP message and to apply the appropriate reconstruction procedure. Line 2 contains a Call-ID field: “i 92cd77c2e4fdb8a3” , which carries the Call-ID of the second SIP message 520 to identify which stored baseline the network should use for reconstruction. Line 3 contains a CSeq field: “c 1” , indicating the sequence number (i.e., “Cseq: 1 INVITE” in the second SIP message 520) .
[0067] Lines 4 through 6 of the simplified SIP message 600 contain the delta part, which consists of three delta entries 611, 612, and 613 respectively. Each delta entry is expressed in the format <action>, <line>, <position>, <length> <data>, where: the action field specifies the type of modification to be applied ( “r” denotes a replace operation) ; the line field specifies the line number in the baseline SIP message 510 to be modified; the position field specifies the character position within that line at which the modification begins; the length field specifies the number of characters to be replaced; and the data field contains the replacement string.
[0068] Delta entry 611 in line 4 is “r, 2, 58, 9 777993992” : replace 9 characters starting at character position 58 of line 2 of the baseline SIP message 510 with the string “777993992” . As shown in FIG. 5, this entry corresponds to updating the branch parameter in the Via header from the baseline value to the call-specific value for the second IMS call.
[0069] Delta entry 612 in line 5 is “r, 4, 63, 9 6984fb4a7” : replace 9 characters starting at character position 63 of line 4 of the baseline SIP message 510 with the string “6984fb4a7” . As shown in FIG. 5, this entry corresponds to updating the tag parameter in the From header from the baseline value to the call-specific value for the second IMS call.
[0070] Delta entry 613 in line 6 is “r, 6, 26, 16 92cd77c2e4fdb8a3” : replace 16 characters starting at character position 26 of line 6 of the baseline SIP message 510 with the string “92cd77c2e4fdb8a3” . As shown in FIG. 5, this entry corresponds to updating the Call-ID value from the baseline value to the call-specific value for the second IMS call.
[0071] In some implementations, the PATCH method in RFC5789 can be used to generate, transmit, and respond to the simplified SIP message, in which the first SIP message is processed as an existing resource (i.e., a document) , and the simplified SIP message is processed as a patch document.
[0072] In some implementations, requesting transmission of deltas, delta algorithm and format, identification of delta-encoded responses, transmission of delta-encoded responses in RFC3229 can be used for corresponding delta processing in the disclosed method. In some implementations, encoding algorithms (e.g., diff, gzip, deflate, vcdiff, vdelta, gdiff, or others) and formats in RFC3229 can be used to encode the delta part. In some implementations, bsdiff or xdelta can be used for corresponding delta processing in the disclosed method.
[0073] In some implementations, a signaling compression mechanism, such as SigComp as defined in RFC 3320, may be applied to the SIP messages exchanged during the baseline synchronization procedure (e.g., the first IMS call setup) to further reduce the amount of data transmitted during the initial handshake. In such implementations, the SIP messages compressed by SigComp serve as the baseline SIP messages stored by both the UE and the network for subsequent delta transfer operations. It is noted that SigComp and the delta transfer mechanism proposed in the present disclosure are complementary: SigComp reduces the size of the baseline SIP messages transmitted during the first IMS call, while the delta transfer mechanism reduces the size of SIP messages transmitted in subsequent IMS calls by encoding only the differences relative to the stored baseline. The combination of SigComp and the delta transfer mechanism may therefore achieve greater overall signaling overhead reduction than either mechanism applied alone, which is particularly beneficial in bandwidth-constrained environments such as GEO NTN access with a bitrate of approximately 1 kbps.
[0074] By applying the three delta entries 611, 612, and 613 to the baseline SIP message 510, the receiving entity (e.g., the network node or UE 101) can reconstruct the full second SIP message 520 as illustrated in FIG. 5. The simplified SIP message 600 thus encodes the complete information necessary for the second IMS call in a compact form, and requires transmission of significantly fewer bytes than the full second SIP message 520.
[0075] FIG. 7 is a signaling diagram illustrating a comparison of IMS call setup procedures before and after application of the delta transfer mechanism of the present disclosure. FIG. 7 shows two signaling flows side by side: a conventional IMS call setup flow 710 (left) and a delta-transfer-enabled IMS call setup flow 720 (right) , each between a UE 101 and a network node.
[0076] The conventional IMS call setup flow 710 illustrates the ten SIP messages exchanged in a single call setup procedure without delta transfer, together with the size and estimated transmission time of each message at a bitrate of approximately 1 kbps (as applicable in GEO NTN environments) : INVITE (1, 415 bytes, 11.32 s) , 100 Trying (265 bytes, 2.2 s) , 183 Session Progress (1, 327 bytes, 10.8 s) , PRACK (775 bytes, 6.2 s) , 200 OK (419 bytes, 3.352 s) , UPDATE (1, 473 bytes, 12 s) , 200 OK (1, 274 bytes, 10.19 s) , 180 Ringing (729 bytes, 5.832 s) , 200 OK (813 bytes, 6.5 s) , and ACK (466 bytes, 3.728 s) . As shown in FIG. 7, the aggregate transmission time for all ten SIP messages in the conventional flow 710 exceeds 70 seconds, far exceeding the 30-second call setup KPI requirement defined by 3GPP SA1 for IMS over GEO NTN.
[0077] The delta-transfer-enabled IMS call setup flow 720 illustrates the corresponding ten simplified SIP messages after application of the delta transfer mechanism, together with the reduced size and transmission time of each message: INVITE (138 bytes, 1.1 s) , 100 Trying (124 bytes, 1.1 s) , 183 Session Progress (136 bytes, 1.1 s) , PRACK (12x bytes, 1.1 s) , 200 OK (12x bytes, 1.1 s) , UPDATE (13x bytes, 1.1 s) , 200 OK (13x bytes, 1.1 s) , 180 Ringing (13x bytes, 1.1 s) , 200 OK (13x bytes, 1.1 s) , and ACK (12x bytes, 1.1 s) . Each simplified SIP message requires approximately 1.1 seconds for transmission, and the total transmission time for all ten simplified SIP messages is reduced to approximately 11 seconds, well within the 30-second KPI requirement.
[0078] A comparison of the conventional flow 710 and the delta-transfer-enabled flow 720 illustrates the significant reduction in SIP message size and IMS call setup time achieved by the proposed delta transfer mechanism. For example, the INVITE message is reduced from 1, 415 bytes to 138 bytes, representing a reduction of approximately 90%in message size. Similar reductions are achieved for all other SIP messages in the call setup flow, collectively enabling IMS call setup over GEO NTN to fulfill the 30-second KPI requirement defined by 3GPP SA1.
[0079] In some implementations, the UE 101 communicates with the network through a satellite network. In some implementations, the UE 101 uses a Geostationary Earth Orbit (GEO) satellite access to initiate the IMS call. In some implementations, the delta transfer mechanism described in connection with FIGS. 3 through 7 may be applied to any network access type that benefits from reduced signaling overhead, including but not limited to Low Earth Orbit (LEO) satellite access, constrained IoT networks, and other bandwidth-limited communication environments. Illustrative Implementations
[0080] FIG. 8 illustrates an example communication system 800 having at least an example communication apparatus 810 and an example network apparatus 820 in accordance with an implementation of the present disclosure. Each of the communication apparatus 810 and network apparatus 820 may perform various functions to implement schemes, techniques, processes, and methods described herein of signaling for IMS calls, including scenarios / schemes described above, as well as processes 900 and 1000 described below.
[0081] Communication apparatus 810 may be a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus, or a computing apparatus. For instance, communication apparatus 810 may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer, or a notebook computer. Communication apparatus 810 may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, or IIoT apparatus, such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus, or a computing apparatus. For instance, communication apparatus 810 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker, or a home control center. Alternatively, communication apparatus 810 may be implemented in the form of one or more integrated-circuit (IC) chips, such as, for example, and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. Communication apparatus 810 may include at least some of those components shown in FIG. 8, such as a processor 812, for example. Communication apparatus 810 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device, and / or user interface device) , and, thus, such component (s) of communication apparatus 810 are neither shown in FIG. 8 nor described below in the interest of simplicity and brevity.
[0082] Network apparatus 820 may be a part of a network apparatus, which may be a network node such as an IMS server, a media server, a P-CSCF, an I-CSCF, an S-CSCF, an AMF, an HSS, a satellite, a base station, a small cell, a router, or a gateway. For instance, network apparatus 820 may be implemented in an eNB in an LTE network, in a gNB in a 5G / NR, IoT, NB-IoT or IIoT network, or in a satellite or base station in a 6G network. Network apparatus 820 may include at least some of those components shown in FIG. 8, such as a processor 822, for example. Processor 822 may further include protocol stacks and a set of control functional modules and circuits. Network apparatus 820 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of network apparatus 820 are neither shown in FIG. 8 nor described below in the interest of simplicity and brevity.
[0083] In one aspect, each of the processor 812 and processor 822 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 812 and processor 822, each of the processor 812 and processor 822 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of the processor 812 and processor 822 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of the processor 812 and processor 822 is a special-purpose machine specifically designed, arranged, and configured to perform specific tasks in a device (e.g., as represented by communication apparatus 810) and a network (e.g., as represented by network apparatus 820) in accordance with various implementations of the present disclosure.
[0084] In some implementations, communication apparatus 810 may also include a memory 814 coupled to processor 812 and capable of being accessed by processor 812 and storing data therein. In some implementations, communication apparatus 810 may further include a transceiver 816 coupled to processor 812 and capable of wirelessly transmitting and receiving data. In some implementations, transceiver 816 may be capable of wirelessly communicating with different types of UEs and / or wireless networks of different RATs, e.g., 2G GSM, 3G UMTS, 4G LTE, 5G NR, and / or 6G.
[0085] In some implementations, network apparatus 820 may further include a memory 824 coupled to processor 822 and capable of being accessed by processor 822 and storing data therein, and a transceiver 826 coupled to processor 822 and capable of wirelessly transmitting and receiving data. Accordingly, communication apparatus 810 and network apparatus 820 may wirelessly communicate with each other via transceiver 816 and transceiver 826, respectively.
[0086] For illustrative purposes and without limitation, descriptions of capabilities of the communication apparatus 810 and network apparatus 820 are provided below with process 900 and process 1000. In which, communication apparatus 810 is implemented in or as a communication apparatus or a UE, and network apparatus 820 is implemented in or as a network node of a communication network (e.g., an IMS server, or a proxy-CSCF (P-CSCF) ) . Illustrative Processes
[0087] FIG. 9 illustrates an example process 900 in accordance with an implementation of the present disclosure. Process 900 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting an IMS call. Process 900 may represent an aspect of the implementation of features of communication apparatus 810. Process 900 may include one or more operations, actions, or functions as illustrated by one or more of blocks 910, 920, and 930. Although illustrated as discrete blocks, various blocks of process 900 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 900 may be executed in the order shown in FIG. 9 or, alternatively, in a different order. Process 900 may be implemented by communication apparatus 810 or any suitable UE (e.g., UE 101) or machine-type devices. Solely for illustrative purposes and without limitation, process 900 is described below in the context of communication apparatus 810 as a UE. Process 900 may begin at block 910.
[0088] At block 910, process 900 may involve processor 812 of communication apparatus 810 transmitting, via transceiver 816, a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call to a network node (e.g., network apparatus 820) . Process 900 may proceed from block 910 to block 920.
[0089] At block 920, process 900 may involve processor 812 generating a simplified SIP message based on the first SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message. Process 900 may proceed from block 920 to block 930.
[0090] At block 930, process 900 may involve processor 812 transmitting, via transceiver 816, the simplified SIP message to the network node (e.g., network apparatus 820) .
[0091] In some implementations, process 900 may further involve processor 812 generating a second SIP message for the second IMS call. Process 900 may further involve processor 812 evaluating a size of the simplified SIP message and a size of the second SIP message. Process 900 may further involve processor 812 selecting the simplified SIP message for transmission in an event that the size of the simplified SIP message is smaller than the size of the second SIP message.
[0092] In some implementations, the first SIP message and the simplified SIP message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.
[0093] In some implementations, the simplified SIP message comprises: a starting line; a Call-ID field; a header field indicating a sequence number of the simplified SIP message; and one or more delta entries, each delta entry comprising an action field, a line field, a position field, a length field, and a data field.
[0094] In some implementations, the line field indicates a line number in the first SIP message. In some implementations, the position field indicates a character position within the line. In some implementations, the length field indicates a number of characters to be modified. In some implementations, the data field comprises replacement data.
[0095] In some implementations, the action field indicates at least one of a replace operation, an insert operation, and a delete operation. In some implementations, the data field is used to replace a portion of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the replace operation. In some implementations, the data field is inserted into a location of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the insert operation. In some implementations, a portion of the first SIP message specified by one or more of the line field, the position field, and the length field is deleted in an event that the action field indicates the delete operation.
[0096] In some implementations, process 900 may further involve processor 812 exchanging, via transceiver 816, capability information with the network node (e.g., network apparatus 820) during IMS registration to indicate support for a delta transfer mechanism.
[0097] In some implementations, process 900 may further involve processor 812 synchronizing, via transceiver 816, the first SIP message with the network node (e.g., network apparatus 820) for subsequent delta transfer operations.
[0098] In some implementations, the UE communicates with the network through a satellite network.
[0099] In some implementations, the UE uses a Geostationary Earth Orbit (GEO) access to initiate the IMS call.
[0100] FIG. 10 illustrates an example process 1000 in accordance with an implementation of the present disclosure. Process 1000 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting an IMS call. Process 1000 may represent an aspect of the implementation of features of network apparatus 820. Process 1000 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1010, 1020, and 1030. Although illustrated as discrete blocks, various blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1000 may be executed in the order shown in FIG. 10 or, alternatively, in a different order. Process 1000 may be implemented by network apparatus 820 or any network entity in the 4G, 5G, or 6G network, including a base station, an IMS server, a media server, a P-CSCF, an I-CSCF, an S-CSCF, an AMF, or an HSS. Solely for illustrative purposes and without limitation, process 1000 is described below in the context of network apparatus 820 as a network node. Process 1000 may begin at block 1010.
[0101] At block 1010, process 1000 may involve processor 822 of network apparatus 820 receiving, via transceiver 826, a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call from a user equipment (UE) (e.g., communication apparatus 810) . Process 1000 may proceed from block 1010 to block 1020.
[0102] At block 1020, process 1000 may involve processor 822 receiving, via transceiver 826, a simplified SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message. Process 1000 may proceed from block 1020 to block 1030.
[0103] At block 1030, process 1000 may involve processor 822 determining a second SIP message for the second IMS call based on the first SIP message and the simplified SIP message.
[0104] In some implementations, the first SIP message and the simplified message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.
[0105] In some implementations, the simplified SIP message comprises: a starting line; a Call-ID field; a header field indicating a sequence number of the simplified SIP message; and one or more delta entries, each delta entry comprising an action field, a line field, a position field, a length field, and a data field.
[0106] In some implementations, the line field indicates a line number in the first SIP message. In some implementations, the position field indicates a character position within the line. In some implementations, the length field indicates a number of characters to be modified. In some implementations, the data field comprises replacement data.
[0107] In some implementations, the action field indicates at least one of a replace operation, an insert operation, and a delete operation. In some implementations, the data field is used to replace a portion of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the replace operation. In some implementations, the data field is inserted into a location of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the insert operation. In some implementations, a portion of the first SIP message specified by one or more of the line field, the position field, and the length field is deleted in an event that the action field indicates the delete operation.
[0108] In some implementations, process 1000 may further involve processor 822 exchanging, via transceiver 826, capability information with the UE (e.g., communication apparatus 810) during IMS registration to indicate support for a delta transfer mechanism.
[0109] In some implementations, process 1000 may further involve processor 822 synchronizing, via transceiver 826, the first SIP message with the UE (e.g., communication apparatus 810) for subsequent delta transfer operations.
[0110] In some implementations, the UE communicates with the network through a satellite network.
[0111] In some implementations, the UE uses a Geostationary Earth Orbit (GEO) access to initiate the IMS call. Additional Notes
[0112] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact, many other architectures can be implemented that achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected” , or “operably coupled” , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being “operably couplable” , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.
[0113] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.
[0114] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an, ” e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of “two recitations, ” without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”
[0115] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
Claims
1.A method, comprising:transmitting, by a processor of a user equipment (UE) , a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call to a network node;generating, by the processor, a simplified SIP message based on the first SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message; andtransmitting, by the processor, the simplified SIP message to the network node.2.The method of claim 1, further comprising:generating, by the processor, a second SIP message for the second IMS call;evaluating, by the processor, a size of the simplified SIP message and a size of the second SIP message;selecting, by the processor, the simplified SIP message for transmission in an event that the size of the simplified SIP message is smaller than the size of the second SIP message.3.The method of claim 1, wherein the first SIP message and the simplified SIP message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.4.The method of claim 1, wherein the simplified SIP message comprises:a starting line;a Call-ID field;a header field indicating a sequence number of the simplified SIP message; andone or more delta entries, each delta entry comprising an action field, a line field, a position field, a length field, and a data field.5.The method of claim 4, wherein:the line field indicates a line number in the first SIP message;the position field indicates a character position within the line;the length field indicates a number of characters to be modified; andthe data field comprises replacement data.6.The method of claim 4, wherein:the action field indicates at least one of a replace operation, an insert operation, and a delete operation;the data field is used to replace a portion of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the replace operation;the data field is inserted into a location of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the insert operation; ora portion of the first SIP message specified by one or more of the line field, the position field, and the length field is deleted in an event that the action field indicates the delete operation.7.The method of claim 1, further comprising:exchanging, by the processor, capability information with the network node during IMS registration to indicate support for a delta transfer mechanism.8.The method of claim 1, further comprising:synchronizing, by the processor, the first SIP message with the network node for subsequent delta transfer operations.9.A method, comprising:receiving, by a processor of a network node, a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call from a user equipment (UE) ;receiving, by the processor, a simplified SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message;determining, by the processor, a second SIP message for the second IMS call based on the first SIP message and the simplified SIP message.10.The method of claim 9, wherein the first SIP message and the simplified message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.11.The method of claim 9, wherein the simplified SIP message comprises:a starting line;a Call-ID field;a header field indicating a sequence number of the simplified SIP message; andone or more delta entries, each delta entry comprising an action field, a line field, a position field, a length field, and a data field.12.The method of claim 11, wherein:the line field indicates a line number in the first SIP message;the position field indicates a character position within the line;the length field indicates a number of characters to be modified; andthe data field comprises replacement data.13.The method of claim 11, wherein:the action field indicates at least one of a replace operation, an insert operation, and a delete operation;the data field is used to replace a portion of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the replace operation;the data field is inserted into a location of the first SIP message specified by one or more of the line field, the position field, and the length field in an event that the action field indicates the insert operation; ora portion of the first SIP message specified by one or more of the line field, the position field, and the length field is deleted in an event that the action field indicates the delete operation.14.The method of claim 9, further comprising:exchanging, by the processor, capability information with the UE during IMS registration to indicate support for a delta transfer mechanism.15.The method of claim 9, further comprising:synchronizing, by the processor, the first SIP message with the UE for subsequent delta transfer operations.16.An apparatus, comprising:a transceiver which, during operation, communicates wirelessly; anda processor communicatively coupled to the transceiver such that, during operation, the processor performs operations comprising:transmitting, via the transceiver, a first Session Initiation Protocol (SIP) message for a first Internet Protocol Multimedia Subsystem (IMS) call to a network node;generating a simplified SIP message based on the first SIP message for a second IMS call, wherein the simplified SIP message comprises a delta part, and the delta part comprises differences compared to the first SIP message; andtransmitting, via the transceiver, the simplified SIP message to the network node.17.The apparatus of claim 16, wherein the processor further performs operations comprising:generating a second SIP message for the second IMS call;evaluating a size of the simplified SIP message and a size of the second SIP message;selecting the simplified SIP message for transmission in an event that the size of the simplified SIP message is smaller than the size of the second SIP message.18.The apparatus of claim 16, wherein the first SIP message and the simplified SIP message each comprise INVITE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.19.The apparatus of claim 16, wherein the simplified SIP message comprises:a starting line;a Call-ID field;a header field indicating a sequence number of the simplified SIP message; andone or more delta entries, each delta entry comprising an action field, a line field, a position field, a length field, and a data field.20.The apparatus of claim 19, wherein:the line field indicates a line number in the first SIP message;the position field indicates a character position within the line;the length field indicates a number of characters to be modified; andthe data field comprises replacement data.