Methods and apparatus for setting internet protocol multimedia subsystem calls in mobile communications

Abstract

Various solutions for efficient call setup in Internet Protocol Multimedia Subsystem (IMS) by pre-allocating call-related parameters are described. A user equipment (UE) may transmit an invite message without negotiating call-related parameters for an IMS call to a network. The UE may receive a 180 Ringing message from the network. The UE may receive a 200 OK message from the network. The UE may then receive a media flow from the network according to a set of predetermined call-related parameters, and transmit an acknowledgement (ACK) message to the network. The predetermined call-related parameters may be obtained through various mechanisms including network-predetermined defaults, early SIP messages, or reuse of stored parameters from previous calls.

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 / 759,573 filed 18 February 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 efficient call setup in Internet Protocol Multimedia Subsystem (IMS) by pre-allocating call-related parameters in mobile communications using satellite access.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] Using mobile phones to make voice calls via satellite access has become increasingly popular as satellite systems provide extensive coverage in rural and remote regions. Within the 3rd Generation Partnership Project (3GPP) standards, satellite voice call services enable consistent network connectivity across both terrestrial and satellite networks, facilitating communication at any time and place.

[0005] Starting from 3GPP Release 17, Geostationary Earth Orbit (GEO) satellite access has been incorporated as a 5G access technology, mainly supporting short message service. However, GEO satellite systems face inherent limitations, such as a long transmission distance of approximately 35,786 km, one-way signal delays of around 285 milliseconds (ms) , atmospheric attenuation, and constrained data transmission rates that cannot be easily improved by increasing bandwidth. Consequently, several services that can be supported by Low Earth Orbit (LEO) or other Non-Geostationary Satellite Orbit (NGSO) systems may not be feasible over GEO links. For example, the IP Multimedia Subsystem (IMS) voice call service is not directly supported via GEO satellite access due to the low data rate and high latency, which result in unacceptably long IMS call setup time and insufficient bandwidth for conventional IMS voice codecs.

[0006] IMS has been standardized since 3GPP Release 15 as a common platform for providing voice and multimedia services, including IMS emergency call, messaging, group management, push-to-talk, and real-time communications. Although IMS ensures interoperability and service continuity across heterogeneous access networks, integrating IMS with GEO satellite access introduces three primary issues affecting user experience: one-way transmission delay, codec bitrate constraints, and IMS call setup time.

[0007] In existing systems, the IMS call setup procedure relies on the SDP (Session Description Protocol) offer / answer model defined in RFC 3264. The offer / answer model allows flexible media parameter negotiation between the caller, the IMS server, and the callee. However, such flexibility introduces considerable signaling overhead. In practice, the media codec information exchanged in SDP messages for IMS voice calls is typically identical across different calls, resulting in redundant transmission of long SDP payloads. Due to the characteristics of GEO satellite access, which provides a very limited / slow data transmission rate and requires long packet transmission / receipt times, the IMS call setup time becomes even longer when these redundant SDP messages are transmitted over the GEO satellite access.

[0008] Furthermore, because the data rate supported by GEO satellite access is extremely limited, only a very small set of codecs (possibly only one) may be suitable for voice communication over GEO, making dynamic codec negotiation through SDP unnecessary and burdensome.

[0009] Moreover, in conventional IMS call procedures where SDP negotiation is performed during call setup, media transmission does not begin until after the call-related parameters have been negotiated and confirmed. This sequential process, which requires multiple round-trip exchanges to negotiate media parameters before media transmission can commence, introduces additional delays, particularly problematic over GEO satellite links where each round-trip time can exceed 500 milliseconds (ms) . The conventional approach does not allow media transmission to begin until after the called party sends a 200 OK message and the calling party sends an ACK message. As a result, when a user accepts an incoming call, there is a noticeable delay of one or more satellite round-trip times before bidirectional voice communication can be established, leading to a poor user experience.

[0010] Accordingly, there is a need for mechanisms that not only eliminate redundant SDP negotiation by pre-allocating call-related parameters but also enable early media transmission to significantly shorten the time between call acceptance and the establishment of bidirectional voice communication for user equipment (UEs) using GEO satellite access or other high-latency communication environments.SUMMARY

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

[0012] An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issue pertaining to setting IMS calls.

[0013] In one aspect, a method may involve an apparatus transmitting an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call to a network. The method may further involve the apparatus receiving a 180 Ringing message from the network. The method may further involve the apparatus receiving a 200 OK message from the network. The method may further involve the apparatus transmitting an acknowledgement (ACK) message to the network.

[0014] In another aspect, a method may involve an apparatus receiving an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call from a network. The method may further involve the apparatus transmitting a 180 Ringing message to the network. The method may further involve the apparatus transmitting a 200 OK message to the network. The method may further involve the apparatus transmitting a media flow to the network according to a set of predetermined call-related parameters. The method may further involve the apparatus receiving an acknowledgement (ACK) message from the network.

[0015] In another aspect, a method may involve a network receiving and transferring an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call from a first user equipment (UE) to a second UE. The method may further involve the network receiving and transferring a 180 Ringing message from the second UE to the first UE. The method may further involve the network receiving and transferring a 200 OK message from the second UE to the first UE. The method may further involve the network receiving a media flow from the second UE to the first UE according to a second set of predetermined call-related parameters and transferring the media flow to the first UE according to a first set of predetermined call-related parameters. The method may further involve the network receiving and transferring an acknowledgement (ACK) message from the first UE to the second UE.

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

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

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

[0019] FIG. 2 illustrates a comparison between a traditional call flow and an optimized call flow in accordance with an implementation of the present disclosure.

[0020] FIG. 3 is a signaling diagram illustrating a method for a UE using GEO satellite access to perform an IMS call without early media transmission and without pre-configured call-related parameters.

[0021] FIG. 4 is a signaling diagram illustrating methods for pre-allocating, updating, and adding call-related parameters in accordance with an implementation of the present disclosure.

[0022] FIG. 5 is a signaling diagram illustrating a method for a UE using GEO satellite access to perform an IMS call with early media transmission using pre-configured call-related parameters in accordance with an implementation of the present disclosure.

[0023] FIG. 6 is a signaling diagram illustrating a method in which a calling UE using GEO satellite access with pre-allocated call-related parameters performs an IMS call to a called UE using terrestrial network access with conventional IMS procedures in accordance with an implementation of the present disclosure.

[0024] FIG. 7 is a signaling diagram illustrating a method for optimizing call quality during an active IMS call by creating and storing additional parameter sets through in-call negotiation in accordance with an implementation of the present disclosure.

[0025] FIG. 8 is a signaling diagram illustrating a method in which two UEs perform an IMS call using multiple sets of predetermined call-related parameters obtained from a previous call with indexing support in accordance with an implementation of the present disclosure.

[0026] FIG. 9 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.

[0027] FIG. 10 is a flowchart of an example process in accordance with an implementation of the present disclosure.

[0028] FIG. 11 is a flowchart of another example process in accordance with an implementation of the present disclosure.

[0029] FIG. 12 is a flowchart of yet another example process in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS

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

[0031] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to setting 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.

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

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

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

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

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

[0037] It should be understood that the term “SDP pre-configuration” may be used interchangeably throughout this disclosure with the terms “slim call / simplified call / optimized call mechanism” . In addition, the term “SDP pre-config” feature tag may be used interchangeably throughout this disclosure with the terms “slim call” (or “simplified / optimized call” ) feature tag.

[0038] FIG. 2 illustrates a comparison between a traditional call flow 210 and an optimized call flow 220 in accordance with an implementation of the present disclosure. The traditional call flow 210 includes a calling phase that consists of multiple Session Initiation Protocol (SIP) exchanges and SDP negotiation before media transfer can begin. In contrast, the optimized call flow 220 separates the process into two distinct phases: a pre-allocation phase and a calling phase. During the pre-allocation phase, SIP messages and SDP negotiation occur in advance to establish predetermined call-related parameters. Subsequently, during the calling phase (triggered by user dial) , the call setup requires only simplified SIP exchanges and proceeds directly to media transfer without any SDP negotiation, significantly reducing call setup time.

[0039] In the traditional call flow 210, the calling phase begins when a user initiates a dial action. Following this, the system performs a series of SIP message exchanges accompanied by SDP negotiation to establish the media parameters for the call. Only after completing these negotiation steps can media transfer commence. This sequential process introduces substantial delays, particularly problematic over high-latency links such as GEO satellite access, where each round of SIP and SDP exchange can consume hundreds of milliseconds or more.

[0040] In the optimized call flow 220, the pre-allocation phase occurs before any call is initiated. During this phase, SIP signaling and SDP negotiation are performed to pre-establish and store call-related parameters. These parameters may be obtained through various mechanisms, such as network-predetermined defaults, early SIP messages (INVITE, INFO, or NOTIFY) , or stored parameters from previous calls. The key advantage is that this negotiation happens in advance, transparent to the end user, and the established parameters are stored for use in subsequent calls.

[0041] When a user initiates a call in the optimized call flow 220, the calling phase proceeds with only the essential SIP exchanges required for call signaling, without any SDP negotiation. The predetermined call-related parameters established during the pre-allocation phase are automatically applied. As a result, media transfer can begin much more quickly after the user dial action, dramatically reducing the perceived call setup time compared to the traditional approach.

[0042] The comparison illustrated in FIG. 2 demonstrates the fundamental architectural difference between conventional IMS call procedures and the proposed optimized approach. By decoupling parameter negotiation from the actual call setup procedure through pre-allocation, the optimized call flow achieves significantly reduced signaling overhead and faster call establishment, which is particularly beneficial for high-latency communication environments such as GEO satellite access, where minimizing round-trip message exchanges is critical for acceptable user experience.

[0043] FIG. 3 is a signaling diagram illustrating a conventional method for IMS call setup over GEO satellite access without early media transmission. This figure demonstrates the traditional IMS call establishment procedure, where media transmission does not begin until after the complete signaling exchange is finished. The comparison between FIG. 3 and FIGs. 5 to 8 highlight the significant advantages achieved by the early media transmission approach proposed in the present disclosure.

[0044] Step 301: A calling UE (UE-1) (i.e., mobile originated (MO) UE) initiates an IMS call and transmits an INVITE message with Session Description Protocol (SDP) containing codec information (e.g., codec1, codec2) to the IMS server.

[0045] Step 302: The network, such as an IMS server, forwards the INVITE message with SDP to the called UE (UE-2) (i.e., mobile terminated (MT) UE) .

[0046] Step 303: The called UE (UE-2) responds with a 183 Session Progress message including SDP (e.g., selecting codec2) to the network (e.g., the IMS server) , indicating the media parameters it supports.

[0047] Step 304: The network (e.g., the IMS server) forwards the 183 Session Progress message with SDP to the calling UE, completing the SDP offer / answer negotiation.

[0048] Step 305: The calling UE transmits a PRACK (Provisional Response Acknowledgement) message to the network (e.g., the IMS server) .

[0049] Step 306: The network (e.g., the IMS server) forwards the PRACK message to the called UE.

[0050] Step 307: The called UE responds with a 200 OK message for the PRACK to the network (e.g., the IMS server) .

[0051] Step 308: The network (e.g., the IMS server) forwards the 200 OK (PRACK) message to the calling UE.

[0052] Step 309: The called UE transmits a 180 Ringing message to the network (e.g., the IMS server) .

[0053] Step 310: The network (e.g., the IMS server) forwards the 180 Ringing message to the calling UE.

[0054] Step 311: After the user at the called UE accepts the call (e.g., the user pressing an accept button at UE-2) , the called UE transmits a 200 OK message for the INVITE to the network (e.g., the IMS server) .

[0055] Step 312: The network (e.g., the IMS server) forwards the 200 OK (INVITE) message to the calling UE.

[0056] Step 313: The calling UE transmits an ACK message to the network (e.g., the IMS server) to confirm the call establishment.

[0057] Step 314: The network (e.g., the IMS server) forwards the ACK message to the called UE.

[0058] Step 315: Only after the complete signaling exchange described in Steps 301-314 is finished, bidirectional media flows are established between the calling UE and the called UE through the IMS server. Then, the user at the calling UE and the user at the called UE can hear the voice of the call.

[0059] The conventional method illustrated in FIG. 3 has significant drawbacks in high-latency environments such as GEO satellite access. Specifically, the complicated SDP negotiation process (Steps 303-308) consumes multiple satellite round-trip times, and more critically, media transmission cannot begin until the final ACK message is sent (Step 313) . This means that when the user at the called UE presses the accept button (Step 311) , there is still a long delay of at least one or two additional GEO satellite round-trip times (approximately 500-1000 ms or more) before the user can hear the caller's voice. This results in a total call setup time that can exceed 30-40 seconds, leading to a poor user experience.

[0060] In contrast, the methods proposed in the present disclosure (illustrated in subsequent figures such as FIG. 4 to FIG. 8) eliminate or significantly reduce these delays by enabling early media transmission, allowing the called party to hear the caller's voice immediately upon accepting the call, thereby substantially improving the user experience in high-latency communication environments.

[0061] In some implementations, the set of predetermined call-related parameters for media flow may be obtained through various methods prior to initiating the actual IMS call. These methods provide flexibility in different network deployment scenarios and allow optimization based on specific network conditions and UE capabilities. The predetermined call-related parameters may include, but are not limited to, IP addresses, port numbers for voice / video / text / data channels, codec information, transport protocol information, and security protocol information. Three schemes for obtaining predetermined call-related parameters are illustrated in the following: a. Scheme 1 (network-predetermined defaults) , b. Scheme 2 (user-unaware negotiation via early SIP messages) , and c. Scheme 3 (reusing stored parameters from previous calls) . Scheme 1: Network-Predetermined Call-Related Parameters

[0062] In some implementations, the predetermined call-related parameters may be network-predetermined defaults that are pre-defined by the network for use by UEs. These network-predetermined parameters may be specified in industry standards such as 3rd Generation Partnership Project (3GPP) , Global System for Mobile Communications Association (GSMA) , or Internet Engineering Task Force (IETF) Request for Comments (RFC) specifications. The network-predetermined parameters represent a default set of call-related parameters that are known and available to both the UE and the network without requiring any prior exchange or negotiation. For example, the network may pre-define a specific codec type, bitrate, packet time (ptime) , and port number range that are optimized for satellite access or other high-latency communication environments. When a UE initiates or receives an IMS call, it may automatically use these network-predetermined parameters for media transmission without requiring Session Description Protocol (SDP) negotiation during call setup. This approach is particularly advantageous when standardized media parameters are suitable for the communication environment, as it requires minimal setup and no prior exchange of parameter information between the UE and the network. The network-predetermined parameters may be provisioned to the UE during initial network attachment, PDU session establishment, or IMS registration procedures. In some implementations, the UE may indicate its support for using network-predetermined parameters through capability signaling, and the network may confirm acceptance of this mechanism through appropriate response messages. Scheme 2: User-Unaware Negotiation for Obtaining Call-Related Parameters via Early SIP Messages

[0063] In some implementations, the predetermined call-related parameters may be obtained by the UE transmitting an SIP early message before initiating the actual IMS call. The term “early” in this context refers to pre-call signaling that occurs before an actual user-initiated call takes place. Unlike conventional SIP signaling which is triggered by user dial action, the SIP early message is transmitted autonomously by the UE or network to negotiate and establish call-related parameters in advance, without user awareness or intervention. The SIP early message may comprise at least one of an early INVITE message, an early INFO message, or an early NOTIFY message. For instance, when no user has initiated a dial action, the UE may autonomously send an early INVITE with SDP to trigger parameter negotiation with the network. The network processes this early message and responds with appropriate SIP messages (such as 200 OK) containing the negotiated call-related parameters. Both the UE and the network store these negotiated parameters for use in subsequent actual calls.

[0064] In some implementations, the negotiated parameters may be assigned an index or identifier to distinguish among multiple sets of predetermined call-related parameters. When multiple parameter sets are available, the index allows efficient identification of which set should be applied for a particular call. The index may be UE-indicated (where the UE specifies which parameter set to use in the INVITE message) or network-indicated (where the network selects the appropriate parameter set and informs the UE) . This user-unaware negotiation approach allows the UE to establish the media configuration in advance, transparent to the end user, while eliminating the need for SDP negotiation during the actual call setup phase. The approach provides flexibility by allowing the network to select and provide appropriate parameter sets based on current network conditions, UE capabilities, or service requirements. Scheme 3: Reusing Stored Call-Related Parameters from Previous Calls

[0065] In some implementations, the predetermined call-related parameters for a first IMS call may be obtained by reusing stored call-related parameters from a second IMS call that occurred before the first IMS call. This reuse mechanism leverages the fact that call-related parameters established during previous calls often remain valid and optimal for subsequent calls, particularly when the same UE, network conditions, or communication patterns are involved. The stored parameters may be obtained and preserved from the second IMS call through various mechanisms. Specifically, the set of predetermined call-related parameters of the first IMS call may be: (a) identical to a set of call-related parameters that was successfully used during the second IMS call, (b) a set of call-related parameters that was updated during the second IMS call using a re-INVITE or UPDATE message, or (c) a set of call-related parameters that was added during the second IMS call using a re-INVITE or UPDATE message.

[0066] In case (a) , when the second IMS call completes successfully using a particular set of call-related parameters, both the UE and the network may store this parameter set for reuse in future calls. If network conditions, UE capabilities, and service requirements remain similar, the same parameter set can be directly applied to the first IMS call (and other subsequent calls) without requiring any negotiation. This is the simplest form of parameter reuse and is particularly effective when call patterns are consistent.

[0067] In case (b) , during the second IMS call, the UE or network may determine that the initially negotiated call-related parameters need modification to improve call quality, adapt to changing network conditions, or accommodate updated capabilities. Either party may initiate a re-INVITE or UPDATE message during the active call to propose updated parameters. For example, the codec type might be changed to better suit current bandwidth conditions, the bitrate might be adjusted for improved quality, or port numbers might be modified. Once the updated parameters are successfully negotiated and applied during the active call, both the UE and the network store this updated parameter set (referred to as set1'if the original was set1) . When the first IMS call is subsequently initiated, this updated parameter set may be used as the predetermined call-related parameters, benefiting from the optimization that occurred during the active call.

[0068] In case (c) , during the second IMS call, the UE or network may determine that additional parameter sets should be created to support different scenarios, quality levels, or network conditions. Through re-INVITE or UPDATE messages during the active call, new parameter sets (such as set1B if the original was set1) may be negotiated and added to the collection of available parameter sets maintained by both the UE and the network. These additional parameter sets represent alternative configurations that may be optimal for different circumstances. For example, one parameter set might be optimized for high-quality audio with higher bandwidth requirements, while another might be optimized for low-bandwidth scenarios with longer battery life. When the first IMS call is initiated, the UE or network may select the most appropriate parameter set from among the multiple available sets (including both original and added sets) based on current conditions, and this selected set becomes the predetermined call-related parameters for that call.

[0069] FIG. 4 to FIG. 6 illustrate Scheme 2.

[0070] FIG. 4 is a signaling diagram illustrating methods for pre-allocating, updating, and adding call-related parameters in accordance with an implementation of the present disclosure. The figure demonstrates three distinct mechanisms: (1) pre-allocating parameters through an initial exchange with SDP, (2) updating an existing parameter set during a call, and (3) adding new parameter sets during a call. These mechanisms provide flexibility in managing call-related parameters over time and across multiple calls. The UE 101 may be an example of UE 101 in FIG. 1A or FIG. 1B. Pre-allocate Parameters (Steps 401-405) :

[0071] Step 401: The UE 101 transmits an INVITE message for pre-allocation with Session Description Protocol (SDP) to the network. This INVITE message includes SDP information containing proposed call-related parameters that the UE wishes to establish and store for future use. The purpose of this message is not to initiate an actual call but rather to negotiate and pre-allocate a set of call-related parameters (referred to as “set1” ) that can be used in subsequent calls without requiring SDP negotiation during those calls.

[0072] Step 402: The network responds with a 200 OK message for the INVITE. This response may include the network's confirmation or modification of the proposed parameters, completing the negotiation of the first set of call-related parameters.

[0073] Step 403: The UE 101 stores the negotiated set of call-related parameters (set1) locally. This stored parameter set becomes available for use in future IMS calls, allowing the UE to initiate or receive calls without requiring SDP negotiation during the actual call setup.

[0074] Step 404: The UE 101 transmits an ACK message to the network to confirm the successful pre-allocation process.

[0075] Step 405: The network also stores the set of call-related parameters (set1) . Both the UE and the network now have the same parameter set stored and available for use in subsequent calls, eliminating the need for SDP negotiation when these parameters are applied. Update Parameters (Steps 411-413) :

[0076] Step 411: During an active call or at any time when parameter modification is needed, the UE, the network, or both may update the parameter set from set1 to set1' (an updated version of set1) . This update may be triggered by various factors such as changing network conditions, quality requirements, or user preferences. The update is performed through re-INVITE or UPDATE messages that include the modified parameters with SDP.

[0077] Step 412: The UE 101 stores the updated set of call-related parameters (set1') . This updated parameter set replaces or supplements the original set1, and becomes available for use in future calls.

[0078] Step 413: The network also stores the updated set of call-related parameters (set1') . Both the UE and the network now have the updated parameter set available for subsequent calls. The updated set may include modifications such as changed codec settings, updated port numbers, adjusted quality parameters, or other refined call-related parameters based on experience from previous calls or changing network conditions. Add Parameters (Steps 421-423) :

[0079] Step 421: The UE, the network, or both create one or more additional parameter sets (e.g., set1B) during a call. This addition of new parameter sets allows the system to maintain multiple sets of call-related parameters for different scenarios, quality levels, or network conditions. For example, set1B might represent parameters optimized for different codec types, bandwidth constraints, or service requirements. The new parameter sets are created through re-INVITE or UPDATE messages with SDP.

[0080] Step 422: The UE 101 stores the newly added set of call-related parameters (set1B) . The UE has at least a portion or all of multiple parameter sets available (e.g., set1, set1', and set1B) , providing flexibility to select the most appropriate parameter set for each call based on current conditions or requirements.

[0081] Step 423: The network also stores the newly added set of call-related parameters (set1B) . The network has at least a portion or all of multiple parameter sets available (e.g., set1, set1', and set1B) . With multiple parameter sets stored at both the UE and the network, the system can efficiently manage different call scenarios by selecting the appropriate parameter set using an index, which may be UE-indicated or network-indicated.

[0082] The method illustrated in FIG. 4 demonstrates the comprehensive parameter management capabilities of the proposed system. By supporting pre-allocation of initial parameter sets, updating of existing sets, and addition of new sets, the system provides both flexibility and efficiency. These mechanisms enable the system to adapt to varying network conditions, user requirements, and service scenarios while maintaining the core benefit of eliminating SDP negotiation during actual call setup procedures. The ability to manage multiple indexed parameter sets is particularly valuable in dynamic environments such as GEO satellite access, where conditions may vary and different parameter sets may be optimal for different situations.

[0083] FIG. 5 is a signaling diagram illustrating a method in which a UE using GEO satellite access performs an IMS call with early media transmission in accordance with an implementation of the present disclosure. In this scenario, the called UE (i.e., UE-2) receives an incoming call and transmits media flow early to reduce the delay before bidirectional communication is established. In some implementations, at least one of the calling UE (i.e., UE-1) or called UE (i.e., UE-2) operates over GEO satellite access. The calling UE (i.e., UE-1) and called UE (i.e., UE-2) may be two examples of UE 101 in FIG. 1A or FIG. 1B.

[0084] Step 501: A calling UE (UE-1) (i.e., mobile originated (MO) UE) initiates an IMS call toward the called UE (UE-2) (i.e., mobile terminated (MT) UE) by transmitting an INVITE message without SDP to the network (e.g., the IMS server) . An example of the IMS server or media server may include Proxy-Call Session Control Function (P-CSCF) . The INVITE message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., first set of call-related parameters, set1) .

[0085] Step 502: The network (e.g., the IMS server ) forwards the INVITE message without SDP to the called UE (UE-2) operating over GEO satellite access. The INVITE message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., second set of call-related parameters, set2) .

[0086] Step 503: Upon receiving the INVITE message, the called UE transmits a 180 Ringing message without SDP to the network (e.g., the IMS server) to indicate that the user is being alerted. The 180 Ringing message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., second set of call-related parameters, set2) .

[0087] Step 504: The network (e.g., the IMS server) forwards the 180 Ringing message without SDP to the calling UE. The 180 Ringing message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., first set of call-related parameters, set1) .

[0088] Step 505: When the user at the called UE accepts the call (e.g., the user pressing an accept button at UE-2) , the called UE transmits a 200 OK message for the INVITE without SDP to the network (e.g., the IMS server) . At this point, the called UE can begin playing the buffered or incoming media from the calling UE, allowing the user to hear the caller immediately upon accepting the call. The 200 OK message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., second set of call-related parameters, set2) .

[0089] Step 506: Immediately after or simultaneously with transmitting the 200 OK message, the called UE begins transmitting a first media flow to the network (e.g., the IMS server) using the pre-allocated call-related parameters (e.g., second set of call-related parameters, set2) .

[0090] Step 507: The network (e.g., the IMS server) forwards the 200 OK message without SDP to the calling UE. The 200 OK message may optionally include an indication, index, or identifier referencing pre-allocated call-related parameters (e.g., first set of call-related parameters, set1) .

[0091] Step 508: The network (e.g., the IMS server) forwards (e.g., by the IMS server or another media server) the first media flow from the called UE to the calling UE using the pre-allocated call-related parameters (e.g., first set of call-related parameters, set1) .

[0092] Step 509: The calling UE transmits an ACK message without SDP to the network (e.g., the IMS server) to confirm the call establishment.

[0093] Step 510: The calling UE transmits a second media flow to the network (e.g., the IMS server) using the pre-allocated parameters (e.g., first set of call-related parameters, set1) shortly after or simultaneously with the ACK message.

[0094] Step 511: The network (e.g., the IMS server) forwards the ACK message to the called UE, completing the call setup procedure.

[0095] Step 512: The network (e.g., the IMS server or another media server) receives and forwards the second media flow from the calling UE to the called UE using the pre-allocated call-related parameters (e.g., first set of call-related parameters, set1) .

[0096] Full bidirectional media communication is established between the two UEs before transmission of the ACK message. The critical advantage of this method is that both the called party's ability to hear the caller and the calling party's ability to hear the called party are optimized through early media transmission, significantly reducing the perceived call setup time compared to conventional IMS procedures over GEO satellite access.

[0097] In some implementations, the network (e.g., the IMS server) may perform additional processing on the media flows, such as IPv4 / IPv6 translation if the two UEs use different IP versions, or voice transcoding if different codecs are employed, to ensure compatibility and optimal media quality.

[0098] In some implementations, the set of call-related parameters comprises Session Description Protocol (SDP) parameters. SDP parameters define the media characteristics for a communication session and typically include information such as media type (audio, video, text) , transport protocol, media format, codec information, and network addressing information. By pre-configuring these SDP parameters, the need to include SDP in each INVITE message and perform SDP offer / answer negotiation for each call is eliminated, thereby reducing signaling overhead and call setup time.

[0099] Specific call-related parameters: In some implementations, the set of call-related parameters comprises at least one of: an Internet Protocol version 4 (IPv4) address of the calling UE (e.g., UE-1) , an Internet Protocol version 6 (IPv6) address of the calling UE (e.g., UE-1) , a port number of the calling UE (e.g., UE-1) for voice media, a port number of the calling UE (e.g., UE-1) for video media, a port number of the calling UE (e.g., UE-1) for text media, a port number of the calling UE (e.g., UE-1) for data channel media, codec information for the IMS call, transport protocol information for the IMS call, and security protocol information for the IMS call.

[0100] The codec information may include codec type (e.g., AMR, AMR-WB, EVS, Codec2) , codec parameters (e.g., bitrate, mode-set) , payload type, ptime (packetization time) , maxptime (maximum packetization time) , and other codec-specific attributes. For example, in a GEO satellite environment with limited bandwidth, the codec information may specify a low-bitrate codec such as Codec2 with a bit rate of 0.7 kbps and a ptime of 320 ms, which is suitable for the constrained data rate available over satellite links.

[0101] The transport protocol information may specify the protocol to be used for media transmission, such as RTP (Real-time Transport Protocol) , SRTP (Secure RTP) , RTP / AVP (RTP Audio / Video Profile) , or RTP / SAVP (Secure Audio / Video Profile) . The security protocol information may include encryption algorithms, key exchange mechanisms, and authentication methods to ensure secure media transmission.

[0102] By pre-configuring these specific parameters, both the UE and the network have complete knowledge of the media characteristics before the call is initiated. This enables the UE to begin transmitting media packets immediately upon sending the INVITE message, without waiting for parameter negotiation to complete, thereby achieving the early media transmission that significantly reduces call setup time in high-latency environments such as GEO satellite access. FIG. 6 illustrates a scenario in which the calling UE (UE-1) using GEO satellite access has pre-allocated call-related parameters while the called UE (UE-2) using terrestrial network access follows the conventional IMS procedure with SDP negotiation. The IMS server manages the interoperability between the optimized call mechanism used by UE-1 and the conventional mechanism used by UE-2. Although this figure shows UE-1 as the calling party with pre-allocated parameters, the principles described herein apply equally when the roles are reversed.

[0103] FIG. 6 is a signaling diagram illustrating a method in which a UE-1 using GEO satellite access performs a mobile-originated (MO) IMS call to a UE-2 using terrestrial network (TN) access with pre-allocated call-related parameters in accordance with an implementation of the present disclosure. The figure demonstrates how predetermined call-related parameters enable simplified call setup between UEs using different access technologies. The method includes a pre-allocation phase where call-related parameters are established and stored, followed by a calling phase where an actual call is initiated without SDP negotiation. UE-1 may be an example of UE 101 in FIG. 1A or FIG. 1B. Pre-Allocation Phase:

[0104] Before the calling phase begins, both UE-1 and the network perform pre-allocation of call-related parameters. UE-1 stores a first set of call-related parameters, while the network also stores a first set of call-related parameters. These parameter sets are established through one of the mechanisms described earlier (such as network-predetermined defaults, early SIP messages, or parameters from previous calls) and are ready for use in subsequent calls without requiring SDP negotiation. Calling Phase:

[0105] Step 601: UE-1 initiates an IMS call toward UE-2 by transmitting an INVITE message for a call without SDP to the network (e.g., the IMS server) . The INVITE message optionally indicates to use the first set of call-related parameters (e.g., through an index or other indication) . The absence of SDP in this message signifies that UE-1 intends to use pre-allocated call-related parameters rather than performing SDP negotiation during call setup.

[0106] Step 602: The network (e.g., the IMS server) forwards an INVITE message for a call with SDP to UE-2. Since UE-2 is using terrestrial network access and may not support the optimized call mechanism, the IMS server converts the INVITE message by adding appropriate SDP information based on the stored first set of call-related parameters. This enables interoperability between the optimized call procedure used by UE-1 and the conventional IMS procedure used by UE-2.

[0107] Step 603: UE-2 responds with a 183 Session Progress message with SDP to the network. This message includes UE-2's media parameters and capabilities following the standard SDP offer / answer procedure.

[0108] Step 604: The network transmits a PRACK (Provisional Response Acknowledgement) message to UE-2.

[0109] Step 605: UE-2 responds with a 200 OK message for the PRACK to the network, completing the provisional response exchange.

[0110] Step 606: UE-2 transmits a 180 Ringing message to the network, indicating that the user at UE-2 is being alerted to the incoming call.

[0111] Step 607: The network forwards a 180 Ringing message to UE-1, optionally indicating to use the first set of call-related parameters. Notably, this 180 Ringing message to UE-1 does not include SDP, as the call-related parameters have already been pre-allocated. The SIP interactions between the network and UE-2 involving SDP (Steps 603-605) are not forwarded to UE-1, as they are unnecessary given the pre-allocated parameters.

[0112] When the user at UE-2 accepts the call (indicated by “Press accept button at UE-2” ) , UE-2 prepares to send a 200 OK message.

[0113] Step 608: UE-2 transmits a 200 OK message for the INVITE to the network.

[0114] Step 609: Simultaneously with or shortly after (e.g., within a predetermined time window) Step 608, UE-2 begins transmitting a media flow to the network. This early media transmission from UE-2 allows the network to start forwarding the media flow toward UE-1 without waiting for the complete signaling exchange to finish.

[0115] Step 610: The network forwards a 200 OK message for the INVITE to UE-1, optionally indicating to use the first set of call-related parameters. This message does not include SDP, as the predetermined call-related parameters are applied.

[0116] Step 611: The network forwards the media flow from UE-2 to UE-1 according to the first set of call-related parameters. At this point, even before the ACK message is sent, bidirectional media communication can begin, with UE-1 able to hear the voice from UE-2.

[0117] As indicated in the figure, “Hear voice at UE-2” shows that the called party (UE-2) can also hear the calling party's voice at this stage, establishing bidirectional communication.

[0118] Step 612: UE-1 transmits an ACK message to the network to confirm the call establishment.

[0119] Step 613: The network forwards the ACK message to UE-2, completing the call setup procedure.

[0120] FIG. 7 is a signaling diagram illustrating a method for optimizing call quality during an active IMS call by creating and storing additional parameter sets through in-call negotiation in accordance with an implementation of the present disclosure. The figure demonstrates how multiple sets of call-related parameters can be established during an active call (referred to as a previous call) and then utilized for improved call quality in subsequent calls. This mechanism enables the system to maintain and leverage multiple parameter configurations, providing flexibility to adapt to different network conditions or quality requirements. UE-1 and UE-2 may be examples of UE 101 in FIG. 1A or FIG. 1B. Negotiation During a First Call

[0121] Step 701: At the beginning of the figure, the system performs a current call setup flow with SDP negotiation for first and second sets of call-related parameters. This initial negotiation establishes the baseline parameter sets that will be used during the current call. The negotiation determines two distinct sets of parameters (referred to as the first set and the second set) , which may differ in aspects such as codec types, bandwidth allocation, quality parameters, or other call-related characteristics.

[0122] Step 702: UE-1 stores the first set of call-related parameters locally. This set represents one configuration of media and session parameters suitable for certain network conditions or quality requirements.

[0123] Step 703: The network stores both the first set and a second set of call-related parameters. The network maintains both sets to support flexible parameter selection for different scenarios.

[0124] Step 704: UE-2 stores the second set of call-related parameters locally. By having UE-1 and UE-2 store different parameter sets, the system can optimize the media transmission path for each UE's specific access technology or network characteristics. In-Call Optimization for Better Call Quality (Optional)

[0125] The section marked as “Opt” (optional) in the figure demonstrates an optional process for further optimizing call quality during the active call. This in-call optimization allows the system to refine or add parameter sets based on actual call performance and network conditions.

[0126] Step 705: UE-1 transmits a re-INVITE message with SDP to the network. This re-INVITE may propose modifications to the existing parameter sets or entirely new parameter configurations aimed at improving call quality. The SDP in this message contains the updated or additional call-related parameters.

[0127] Step 706: The network forwards a re-INVITE message with SDP to UE-2, propagating the proposed parameter changes or additions.

[0128] Step 707: UE-2 responds with a 200 OK message to the network, accepting the proposed parameter changes or additions.

[0129] Step 708: The network forwards the 200 OK message to UE-1, confirming the successful parameter update or addition.

[0130] Step 709: UE-1 transmits an ACK message to the network, and the network forwards this ACK to UE-2, completing the in-call parameter optimization process.

[0131] Step 710: UE-1 stores the updated or newly added first set of call-related parameters. This updated parameter set reflects the optimizations performed during the call and becomes available for use in future calls.

[0132] Step 711: The network stores both the updated first set and the second set of call-related parameters. The network now maintains multiple parameter sets, including any updates or additions made during the in-call optimization.

[0133] Step 712: UE-2 stores the updated or newly added second set of call-related parameters. Both UEs and the network now have refined parameter sets that have been validated and optimized based on actual call experience.

[0134] The method illustrated in FIG. 7 demonstrates the dynamic nature of parameter management in the proposed system. By enabling in-call optimization through re-INVITE messages, the system can continuously improve call quality and adapt to changing conditions. The stored parameter sets from this active call (i.e., the previous call) -including any updates or additions made during the optional optimization phase-become available for immediate use in subsequent calls without requiring SDP negotiation. This approach combines the benefits of pre-allocated parameters (reduced signaling overhead and faster call setup) with the flexibility to optimize and refine those parameters based on actual call experience.

[0135] FIG. 8 is a signaling diagram illustrating a method in which two UEs perform an IMS call using multiple sets of predetermined call-related parameters with indexing support in accordance with an implementation of the present disclosure. The figure demonstrates how the system manages and applies different parameter sets for different UEs or call scenarios through the use of indices. This capability enables flexible parameter selection while maintaining the benefits of pre-allocated parameters and early media transmission. UE-1 and UE-2 may be examples of UE 101 in FIG. 1A or FIG. 1B. Negotiation During a First Call

[0136] At the top of the figure, the system performs a current call setup flow during which multiple sets of call-related parameters are negotiated and stored. This initial negotiation establishes the baseline parameter sets that will be available for use in subsequent calls.

[0137] UE-1 stores a first set of call-related parameters. This parameter set is optimized for UE-1's specific characteristics, such as its access technology (e.g., GEO satellite access) , capabilities, or network conditions.

[0138] The network stores both a first set and a second set of call-related parameters. By maintaining multiple parameter sets, the network can support different configurations for different UEs, call scenarios, or quality requirements. These parameter sets may differ in aspects such as codec types, bandwidth allocation, latency tolerance, or other media and session characteristics.

[0139] UE-2 stores a second set of call-related parameters. This parameter set may be optimized for UE-2's specific characteristics, which may differ from UE-1 (e.g., terrestrial network access vs. satellite access) . Calling Phase

[0140] Step 801: UE-1 transmits an INVITE message for a call without SDP to the network, optionally indicating to use the first set of call-related parameters. The indication may include an index value (such as “1” ) that references the first parameter set stored at both the UE and the network. This index-based approach allows efficient identification of which parameter set should be applied for this call without requiring the actual parameter values to be transmitted.

[0141] Step 802: The network forwards an INVITE message for a call without SDP to UE-2, optionally indicating to use the second set of call-related parameters. The network may include a different index value (such as “2” ) that references the second parameter set. This demonstrates the network's ability to apply different parameter sets for different UEs within the same call, enabling optimized media paths for each UE's specific characteristics.

[0142] Step 803: UE-2 transmits a 180 Ringing message to the network, optionally indicating to use the second set of parameters. This message confirms UE-2's readiness to use the indicated parameter set.

[0143] Step 804: The network forwards the 180 Ringing message to UE-1, optionally indicating to use the first set of parameters. This ensures UE-1 knows which parameter set will be applied for the call.

[0144] When the user at UE-2 accepts the call (indicated by “Press accept button at UE-2” ) , the following steps occur:

[0145] Step 805: UE-2 transmits a 200 OK message for the INVITE to the network, optionally indicating to use the second set of parameters.

[0146] Step 806: Simultaneously with or shortly after (e.g., within a predetermined time window) Step 805, UE-2 begins transmitting a media flow to the network using the second set of call-related parameters. This early media transmission enables immediate voice communication upon call acceptance without waiting for the complete signaling exchange.

[0147] Step 807: The network forwards the 200 OK message for the INVITE to UE-1, optionally indicating to use the first set of parameters.

[0148] Step 808: The network forwards the media flow to UE-1 using the first set of call-related parameters. Notably, the network may perform media processing or translation as needed, since UE-2 is transmitting media using the second parameter set while UE-1 expects to receive media according to the first parameter set. This may include codec transcoding, bitrate adjustment, or other media adaptations.

[0149] Step 809: UE-1 transmits an ACK message to the network.

[0150] Step 810: Simultaneously with or shortly after (e.g., within a predetermined time window) Step 809, UE-1 transmits a media flow to the network using the first set of call-related parameters. This enables bidirectional media communication.

[0151] Step 811: The network forwards the ACK message to UE-2, completing the call setup signaling.

[0152] Step 812: The network forwards the media flow from UE-1 to UE-2 using the second set of call-related parameters. Again, the network may perform necessary media processing to ensure compatibility between the first parameter set used by UE-1 and the second parameter set used by UE-2.

[0153] As indicated in the figure, “Hear voice at UE-2” shows that the called party can hear the calling party's voice, confirming successful bidirectional media communication.

[0154] In some implementations, multiple sets of call-related parameters may be pre-configured, each set corresponding to different call scenarios or media types. For example, a first parameter set may be optimized for voice-only calls with low-bitrate codecs suitable for satellite links, while a second parameter set may be configured for higher-quality voice or multimedia calls when network conditions permit. Each parameter set may be associated with a unique identifier (or index) , allowing the UE and network to reference the appropriate set during call establishment by including the identifier (or index) in the INVITE message. This provides flexibility while maintaining the benefits of pre-configuration.

[0155] The present disclosure provides several technical improvements over conventional IMS call setup procedures, particularly for high-latency communication environments such as GEO satellite access.

[0156] First, by pre-allocating call-related parameters before initiating an IMS call, the proposed schemes eliminate the need for SDP negotiation during call setup. This significantly reduces signaling overhead and shortens call setup time, which is especially beneficial over GEO satellite links where data transmission rates are severely limited and each signaling exchange incurs substantial delay.

[0157] Additionally, the disclosure enables multiple flexible mechanisms for obtaining pre-allocated call-related parameters. These include: (a) network-predetermined default parameter sets defined in specifications, (b) parameter sets obtained through early SIP messages (such as INVITE, INFO, or NOTIFY) sent before call initiation, and (c) reuse of stored parameter sets from previous IMS calls, which may be identical to, updated versions of, or additions to parameters from prior calls. By providing these diverse approaches for parameter pre-allocation, the proposed schemes accommodate various network configurations and operational scenarios while maintaining compatibility with existing IMS infrastructure.

[0158] Furthermore, by allowing media transmission to begin simultaneously with or shortly after sending critical signaling messages (such as the 200 OK message from the called party) , rather than waiting for the completion of the full signaling exchange, the proposed schemes enable early establishment of bidirectional voice communication. This early media transmission capability is particularly valuable in high-latency environments, where it can reduce the delay between call acceptance and actual voice communication by one or more satellite round-trip times, thereby substantially improving user experience.

[0159] Still further, the proposed mechanisms for managing multiple sets of predetermined call-related parameters, with either UE-indicated or network-indicated indexing, provide flexibility in supporting different call scenarios, quality requirements, or network conditions without requiring real-time negotiation. This approach enables rapid adaptation to changing communication needs while minimizing signaling overhead.

[0160] Collectively, these technical improvements address the fundamental challenges of IMS voice calling over GEO satellite access and other high-latency networks by reducing both signaling overhead and end-to-end call setup latency, while maintaining service quality and compatibility with existing IMS infrastructure. The combination of pre-allocated parameters and early media transmission represents a significant advancement in enabling practical, user-friendly voice communication services over satellite networks. Illustrative Implementations

[0161] FIG. 9 illustrates an example communication system 900 having at least an example communication apparatus 910 and an example network apparatus 920 in accordance with an implementation of the present disclosure. Each of the communication apparatus 910 and network apparatus 920 may perform various functions to implement schemes, techniques, processes, and methods described herein of setting IMS calls, including scenarios / schemes described above, as well as processes 1000, 1100, and 1200 described below.

[0162] Communication apparatus 910 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 910 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 910 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 910 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 910 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 910 may include at least some of those components shown in FIG. 9, such as a processor 912, for example. Communication apparatus 910 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 910 are neither shown in FIG. 9 nor described below in the interest of simplicity and brevity.

[0163] Network apparatus 920 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 920 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 920 may include at least some of those components shown in FIG. 9, such as a processor 922, for example. Processor 922 may further include protocol stacks and a set of control functional modules and circuits. Network apparatus 920 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 920 are neither shown in FIG. 9 nor described below in the interest of simplicity and brevity.

[0164] In one aspect, each of the processor 912 and processor 922 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 912 and processor 922, each of the processor 912 and processor 922 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 912 and processor 922 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 912 and processor 922 is a special-purpose machine specifically designed, arranged, and configured to perform specific tasks in a device (e.g., as represented by communication apparatus 910) and a network (e.g., as represented by network apparatus 920) in accordance with various implementations of the present disclosure.

[0165] In some implementations, communication apparatus 910 may also include a memory 914 coupled to processor 912 and capable of being accessed by processor 912 and storing data therein. In some implementations, communication apparatus 910 may further include a transceiver 916 coupled to processor 912 and capable of wirelessly transmitting and receiving data. In some implementations, transceiver 916 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.

[0166] In some implementations, network apparatus 920 may further include a memory 924 coupled to processor 922 and capable of being accessed by processor 922 and storing data therein, and a transceiver 926 coupled to processor 922 and capable of wirelessly transmitting and receiving data. Accordingly, communication apparatus 910 and network apparatus 920 may wirelessly communicate with each other via transceiver 916 and transceiver 926, respectively.

[0167] For illustrative purposes and without limitation, descriptions of capabilities of the communication apparatus 910 and network apparatus 920 are provided below with process 1000, process 1100, and process 1200. In which, communication apparatus 910 is implemented in or as a communication apparatus or a UE, and network apparatus 920 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

[0168] 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 communication apparatus 910. Process 1000 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1010, 1020, 1030, 1040, and 1050. 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 communication apparatus 910 or any suitable UE (e.g., UE-1 or UE 101) or machine-type devices. Solely for illustrative purposes and without limitation, process 1000 is described below in the context of communication apparatus 910 as a UE. Process 1000 may begin at block 1010.

[0169] At block 1010, process 1000 may involve processor 912 of communication apparatus 910 transmitting, via transceiver 916, an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call to a network. Process 1000 may proceed from block 1010 to block 1020.

[0170] At block 1020, process 1000 may involve processor 912 receiving, via transceiver 916, a 180 Ringing message from the network. Process 1000 may proceed from block 1020 to block 1030.

[0171] At block 1030, process 1000 may involve processor 912 receiving, via transceiver 916, a 200 OK message from the network. Process 1000 may proceed from block 1030 to block 1040.

[0172] At block 1040, process 1000 may involve processor 912 receiving, via transceiver 916, a media flow from the network according to a set of predetermined call-related parameters. Process 1000 may proceed from block 1040 to block 1050.

[0173] At block 1050, process 1000 may involve processor 912 transmitting, via transceiver 916, an acknowledgement (ACK) message to the network.

[0174] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message without a Session Description Protocol (SDP) .

[0175] In some implementations, the set of predetermined call-related parameters is predetermined by the network.

[0176] In some implementations, the set of predetermined call-related parameters is obtained by transmitting an SIP early message before transmitting the invite message. The SIP early message comprises at least one of INVITE, INFO, and NOTIFY.

[0177] In some implementations, the set of predetermined call-related parameters is pre-allocated before transmitting the invite message. In some implementations, the set of predetermined call-related parameters is updated before transmitting the invite message. In some implementations, the set of predetermined call-related parameters is added before transmitting the invite message.

[0178] In some implementations, the set of predetermined call-related parameters of a first IMS call is a stored set of call-related parameters obtained by the UE during a second IMS call before the first IMS call.

[0179] In some implementations, the set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call. In some implementations, the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message. In some implementations, the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.

[0180] In some implementations, the set of predetermined call-related parameters is one of a plurality of sets of predetermined call-related parameters. An index of the set of predetermined call-related parameters is UE-indicated or network-indicated.

[0181] In some implementations, the UE communicates with the network through a satellite network.

[0182] In some implementations, the UE uses a Geostationary Earth Orbit (GEO) access to initiate the IMS call.

[0183] FIG. 11 illustrates an example process 1100 in accordance with an implementation of the present disclosure. Process 1100 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting an IMS call. Process 1100 may represent an aspect of the implementation of features of communication apparatus 910. Process 1100 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1110, 1120, 1130, 1140, and 1150. Although illustrated as discrete blocks, various blocks of process 1100 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1100 may be executed in the order shown in FIG. 11 or, alternatively, in a different order. Process 1100 may be implemented by communication apparatus 910 or any suitable UE (e.g., UE-2 or UE 101) or machine-type devices. Solely for illustrative purposes and without limitation, process 1100 is described below in the context of communication apparatus 910 as a UE. Process 1100 may begin at block 1110.

[0184] At block 1110, process 1100 may involve processor 912 of communication apparatus 910 receiving, via transceiver 916, an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call from a network. Process 1100 may proceed from block 1110 to block 1120.

[0185] At block 1120, process 1100 may involve processor 912 transmitting, via transceiver 916, a 180 Ringing message to the network. Process 1100 may proceed from block 1120 to block 1130.

[0186] At block 1130, process 1100 may involve processor 912 transmitting, via transceiver 916, a 200 OK message to the network. Process 1100 may proceed from block 1130 to block 1140.

[0187] At block 1140, process 1100 may involve processor 912 transmitting, via transceiver 916, a media flow to the network according to a set of predetermined call-related parameters. Process 1100 may proceed from block 1140 to block 1150.

[0188] At block 1150, process 1100 may involve processor 912 receiving, via transceiver 916, an acknowledgement (ACK) message from the network.

[0189] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message without a Session Description Protocol (SDP) .

[0190] In some implementations, the set of predetermined call-related parameters is predetermined by the network.

[0191] In some implementations, the set of call-related parameters is obtained by receiving an SIP early message before receiving the invite message, and wherein the SIP early message comprises at least one of INVITE, INFO, and NOTIFY.

[0192] In some implementations, the set of predetermined call-related parameters is pre-allocated before receiving the invite message. In some implementations, the set of predetermined call-related parameters is updated before receiving the invite message. In some implementations, the set of predetermined call-related parameters is added before receiving the invite message.

[0193] In some implementations, the set of predetermined call-related parameters of a first IMS call is a stored set of predetermined call-related parameters obtained by the UE during a second IMS call before the first IMS call.

[0194] In some implementations, the set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call. In some implementations, the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message. In some implementations, the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.

[0195] In some implementations, the set of call-related parameters is one of a plurality of sets of call-related parameters. An index of the set of call-related parameters is UE-indicated or network-indicated.

[0196] In some implementations, the 200 OK message and the second media flow are transmitted simultaneously or within a predetermined time window.

[0197] In some implementations, the UE communicates with the network through a satellite network.

[0198] In some implementations, the UE uses a Geostationary Earth Orbit (GEO) access to initiate the IMS call.

[0199] FIG. 12 illustrates an example process 1200 in accordance with an implementation of the present disclosure. Process 1200 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting IMS calls. Process 1200 may represent an aspect of the implementation of features of network apparatus 920. Process 1200 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1210, 1220, 1230, 1240, and 1250. Although illustrated as discrete blocks, various blocks of process 1200 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1200 may be executed in the order shown in FIG. 12 or, alternatively, in a different order. Process 1200 may be implemented by network apparatus 920 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 1200 is described below in the context of network apparatus 920. Process 1200 may begin at block 1210.

[0200] At block 1210, process 1200 may involve processor 922 of network apparatus 920 receiving and transferring, via transceiver 926, an invite message for a first Internet Protocol Multimedia Subsystem (IMS) call from a first UE (e.g., communication apparatus 910, UE-1, or UE 101) to a second UE (e.g., communication apparatus 910, UE-2, or UE 101) . Process 1200 may proceed from block 1210 to block 1220.

[0201] At block 1220, process 1200 may involve processor 922 receiving and transferring, via transceiver 926, a 180 Ringing message from the second UE to the first UE. Process 1200 may proceed from block 1220 to block 1230.

[0202] At block 1230, process 1200 may involve processor 922 receiving and transferring, via transceiver 926, a 200 OK message from the second UE to the first UE. Process 1200 may proceed from block 1230 to block 1240.

[0203] At block 1240, process 1200 may involve processor 922 receiving and transferring, via transceiver 926, a media flow from the second UE to the first UE according to a second set of predetermined call-related parameters and transferring, via transceiver 926, the media flow to the first UE according to a first set of predetermined call-related parameters. Process 1200 may proceed from block 1240 to block 1250.

[0204] At block 1250, process 1200 may involve processor 922 receiving and transferring, via transceiver 926, an acknowledgement (ACK) message from the first UE to the second UE.

[0205] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message without a Session Description Protocol (SDP) .

[0206] In some implementations, at least one of the first set of predetermined call-related parameters or the second set of predetermined call-related parameters is predetermined by the network.

[0207] In some implementations, the first set of call-related parameters is provided to the first UE to respond to an SIP early message before receiving the invite message. The SIP early message comprises at least one of INVITE, INFO, and NOTIFY.

[0208] In some implementations, the second set of predetermined call-related parameters is provided to the second UE to respond to an SIP early message before receiving the invite message. The SIP early message comprises at least one of INVITE, INFO, and NOTIFY.

[0209] In some implementations, the set of call-related parameters comprises SDP parameters.

[0210] In some implementations, the first set of predetermined call-related parameters is pre-allocated before the first UE transmits the invite message. In some implementations, the set of predetermined call-related parameters is updated before the first UE transmits the invite message. In some implementations, the set of predetermined call-related parameters is added before the first UE transmits the invite message.

[0211] In some implementations, the second set of predetermined call-related parameters is pre-allocated before the second UE receives the invite message. In some implementations, the set of predetermined call-related parameters is updated before the second UE receives the invite message. In some implementations, the set of predetermined call-related parameters is added before the second UE receives the invite message.

[0212] In some implementations, the first set of predetermined call-related parameters of a first IMS call is a stored set of predetermined call-related parameters obtained by the first UE during a second IMS call before the first IMS call.

[0213] In some implementations, the second set of predetermined call-related parameters of a first IMS call is a stored set of predetermined call-related parameters obtained by the second UE during a second IMS call before the first IMS call.

[0214] In some implementations, the first set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call. In some implementations, the first set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message. In some implementations, the first set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.

[0215] In some implementations, the second set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call. In some implementations, the second set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message. In some implementations, the second set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.

[0216] In some implementations, the first set of call-related parameters is one of a plurality of sets of call-related parameters. An index of the first set of call-related parameters is UE-indicated or network-indicated.

[0217] In some implementations, the second set of call-related parameters is one of a plurality of sets of call-related parameters. An index of the second set of call-related parameters is UE-indicated or network-indicated.

[0218] In some implementations, at least one of the first UE or second UE communicates with the network through a satellite network.

[0219] In some implementations, at least one of the first UE or second UE uses a Geostationary Earth Orbit (GEO) access to initiate the IMS call. Additional Notes

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

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

[0222] 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. ”

[0223] 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) , an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call to a network;receiving, by the processor, a 180 Ringing message from the network;receiving, by the processor, a 200 OK message from the network;receiving, by the processor, a media flow from the network according to a set of predetermined call-related parameters; andtransmitting, by the processor, an acknowledgement (ACK) message to the network.2.The method of claim 1, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message without Session Description Protocol (SDP) .3.The method of claim 1, wherein the set of predetermined call-related parameters is predetermined by the network.4.The method of claim 1, wherein the set of predetermined call-related parameters is obtained by transmitting an SIP early message before transmitting the invite message; and wherein the SIP early message comprises at least one of INVITE, INFO, and NOTIFY.5.The method of claim 1, wherein the set of predetermined call-related parameters is pre-allocated before transmitting the invite message;wherein the set of predetermined call-related parameters is updated before transmitting the invite message; orwherein the set of predetermined call-related parameters is added before transmitting the invite message.6.The method of claim 1, wherein the set of predetermined call-related parameters of a first IMS call is a stored set of call-related parameters obtained by the UE during a second IMS call before the first IMS call.7.The method of claim 6, wherein the set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call;wherein the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message; orwherein the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.8.The method of claim 1, wherein the set of predetermined call-related parameters is one of a plurality of sets of predetermined call-related parameters; andwherein an index of the set of predetermined call-related parameters is UE-indicated or network-indicated.9.A method, comprising:receiving, by a processor of a user equipment (UE) , an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call from a network;transmitting, by the processor, a 180 Ringing message to the network;transmitting, by the processor, a 200 OK message to the network;transmitting, by the processor, a media flow to the network according to a set of predetermined call-related parameters; andreceiving, by the processor, an acknowledgement (ACK) message from the network.10.The method of claim 9, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message without Session Description Protocol (SDP) .11.The method of claim 9, wherein the set of predetermined call-related parameters is predetermined by the network.12.The method of claim 9, wherein the set of predetermined call-related parameters is obtained by receiving an SIP early message before receiving the invite message; and wherein the SIP early message comprises at least one of INVITE, INFO, and NOTIFY.13.The method of claim 9, wherein the set of predetermined call-related parameters is pre-allocated before receiving the invite message;wherein the set of predetermined call-related parameters is updated before receiving the invite message; orwherein the set of predetermined call-related parameters is added before receiving the invite message.14.The method of claim 9, wherein the set of predetermined call-related parameters of a first IMS call is a stored set of predetermined call-related parameters obtained by the UE during a second IMS call before the first IMS call.15.The method of claim 14, wherein the set of predetermined call-related parameters of the first IMS call is identical to a set of call-related parameters of the second IMS call;wherein the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is updated during the second IMS call using a re-INVITE or UPDATE message; orwherein the set of predetermined call-related parameters of the first IMS call is a set of call-related parameters that is added during the second IMS call using a re-INVITE or UPDATE message.16.The method of claim 9, wherein the set of predetermined call-related parameters is one of a plurality of sets of predetermined call-related parameters; andwherein an index of the set of predetermined call-related parameters is UE-indicated or network-indicated.17.The method of claim 9, wherein the 200 OK message and the media flow are transmitted simultaneously or within a predetermined time window.18.A method, comprising:receiving and transferring, by a network, an invite message without negotiating call-related parameters for a first Internet Protocol Multimedia Subsystem (IMS) call from a first user equipment (UE) to a second UE;receiving and transferring, by the network, a 180 Ringing message from the second UE to the first UE;receiving and transferring, by the network, a 200 OK message from the second UE to the first UE;receiving, by the network, a media flow from the second UE to the first UE according to a second set of predetermined call-related parameters and transferring, by the network, the media flow to the first UE according to a first set of predetermined call-related parameters; andreceiving and transferring, by the network, an acknowledgement (ACK) message from the first UE to the second UE.19.The method of claim 18, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message without Session Description Protocol (SDP) .20.The method of claim 18, wherein at least one of the first set of predetermined call-related parameters or the second set of predetermined call-related parameters is predetermined by the network.

Images