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 sending media packets early are described. A user equipment (UE) may transmit an invite message for an IMS call to a network. The UE may transmit or receive a first media flow to or from the network without negotiating a set of call-related parameters during a call setup procedure. The UE may receive at least one of a response or a 180 Ringing message from the network after transmitting the first media flow. By transmitting media packets early, before completing the full call setup signaling exchange, the time required for establishing bidirectional communication is significantly reduced, particularly in high-latency environments such as GEO satellite access.

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 US provisional 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 sending media packets early 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, in conventional IMS call procedures, media transmission does not begin until after the called party sends a 200 OK message and the calling party sends an ACK message. This sequential process introduces additional round-trip delays, particularly problematic over GEO satellite links where each round-trip time can exceed 500 ms. As a result, when a user accepts an incoming call, there is a noticeable delay of one or more satellite round-trip times before the user can hear the caller's voice, leading to a poor user experience.

[0009] Accordingly, there is a need for mechanisms that not only simplify IMS call setup signaling 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

[0010] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

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

[0012] In one aspect, a method may involve an apparatus transmitting an invite message for an Internet Protocol Multimedia Subsystem (IMS) call to a network. The method may further involve the apparatus transmitting or receiving a first media flow to or from the network without negotiating a set of call-related parameters during a call setup procedure. The method may further involve the apparatus receiving at least one of a response or a 180 Ringing message from the network after transmitting the first media flow.

[0013] In another aspect, a method may involve an apparatus receiving an invite message for an Internet Protocol Multimedia Subsystem (IMS) call from a network. The method may further involve the apparatus receiving or transmitting a first media flow from or to the network without negotiating a set of call-related parameters during a call setup procedure. The method may further involve the apparatus transmitting at least one of a response or a 180 Ringing message to the network after receiving the first media flow.

[0014] In another aspect, a method may involve a network receiving and transferring an invite message for an 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 first media flow between the first UE and the second UE without negotiating a set of call-related parameters during a call setup procedure. The method may further involve the network receiving and transferring at least one of a response or a 180 Ringing message from the second UE to the first UE after transferring the first media flow.

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

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

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

[0018] FIG. 2 illustrates an example scenario of IMS call setup without early media transmission.

[0019] FIG. 3 illustrates an example scenario of efficient IMS call setup by sending media packets early in accordance with an implementation of the present disclosure.

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

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

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

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

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

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

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

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

[0028] 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. For example, in the UE transmission (Tx) direction, 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.

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

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

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

[0032] FIG. 2 is a signaling diagram illustrating a method for enabling a UE operating over a GEO satellite link to obtain specific IP addresses for use in subsequent processes of a slim, simplified, or optimized IMS call mechanism through a packet data unit (PDU) session establishment procedure in accordance with an implementation of the present disclosure.

[0033] FIG. 2 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. 2 and FIG. 3 highlights the significant advantages achieved by the early media transmission approach proposed in the present disclosure.

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

[0035] Step 202: 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) .

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

[0037] Step 204: 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.

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

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

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

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

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

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

[0044] Step 211: 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) .

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

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

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

[0048] Step 215: Only after the complete signaling exchange described in Steps 201-214 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.

[0049] The conventional method illustrated in FIG. 2 has significant drawbacks in high-latency environments such as GEO satellite access. Specifically, the complicated SDP negotiation process (Steps 203-208) consumes multiple satellite round-trip times, and more critically, media transmission cannot begin until the final ACK message is sent (Step 213) . This means that when the user at the called UE presses the accept button (Step 211) , 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.

[0050] In contrast, the methods proposed in the present disclosure (illustrated in subsequent figures such as FIG. 3) 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.

[0051] FIG. 3 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.

[0052] Step 301: 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) . The INVITE message may optionally include an indication or identifier referencing pre-allocated call-related parameters.

[0053] Step 302: The calling UE transmits or receives a first media flow to or from the network (e.g., the IMS server) using the pre-allocated call-related parameters (e.g., the first set of call-related parameters in FIG. 3) shortly after or simultaneously with the INVITE message. The network (e.g., the IMS server or another media server) receives and forwards the first media flow from the calling UE to the called UE or from the called UE to the calling UE using the pre-allocated call-related parameters (e.g., the first set and second set of call-related parameters in FIG. 3) .

[0054] Step 303: The network (e.g., the IMS server) forwards the INVITE message without SDP to the called UE (UE-2) operating over GEO satellite access.

[0055] Step 304: The network (e.g., the IMS server or another media server) receives and forwards the first media flow from the calling UE to the called UE or from the called UE to the calling UE using the pre-allocated call-related parameters (e.g., the first set and second set of call-related parameters in FIG. 3) . An example of the IMS server or media server may include Proxy-Call Session Control Function (P-CSCF) . After receiving the first media flow, the called UE may temporarily buffer the first media flow. The called UE receives or transmits the first media flow from or to the network (e.g., the IMS server) using the pre-allocated call-related parameters (e.g., the second set of call-related parameters in FIG. 3) shortly after or simultaneously with the INVITE message.

[0056] Step 305: Upon receiving the INVITE message, the called UE transmits at least one of a 18x response or a 180 Ringing message without SDP to the network (e.g., the IMS server) to indicate that the user is being alerted. For example, when the disclosed method is applied to a call setup procedure with 183 Session Progress messages, PRACK, and 200 OK (for the PRACK) , an example of the 18x response is a 183 Session Progress message followed by PRACK, and 200 OK.

[0057] Step 306: The network (e.g., the IMS server) forwards the at least one of the 18x response or 180 Ringing message without SDP to the calling UE.

[0058] Step 307: 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.

[0059] Step 308: Immediately after or simultaneously with transmitting the 200 OK message, the called UE begins transmitting or receiving a second media flow to or from the network (e.g., the IMS server) using the pre-allocated call-related parameters (e.g., the second set of call-related parameters in FIG. 3) .

[0060] Step 309: The network (e.g., the IMS server) forwards the 200 OK message without SDP to the calling UE.

[0061] Step 310: The network (e.g., the IMS server) forwards (e.g., by the IMS server or another media server) the second media flow from the called UE to the calling UE or from the calling UE to the called UE.

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

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

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

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

[0066] In some implementations, the set of 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. Schemes 1, 2, and 3 are illustrated in the following.

[0067] Scheme 1: Obtaining call-related parameters via SIP Early Message: In some implementations, the call-related parameters may be obtained by the calling UE (e.g., UE-1) transmitting a SIP early message before transmitting the invite message for the actual call. The term “early” in this context refers to pre-call signaling, as defined in RFC 3261, where messages are exchanged before an actual user-initiated call takes place. 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 dialed an actual call, the UE may autonomously send an early INVITE with SDP to trigger negotiation with the network and pre-determine the call-related parameters. The network responds with appropriate SIP messages to complete the parameter negotiation, and both the UE and the network store these parameters for use in subsequent actual calls. This approach allows the UE to establish the media configuration in advance, eliminating the need for SDP negotiation during the actual call setup phase.

[0068] Scheme 2: Obtaining call-related parameters During Registration: In some implementations, the call-related parameters may be obtained by the calling UE (e.g., UE-1) during registration of the calling UE (e.g., UE-1) with an IMS network. The IMS registration process involves interactions with multiple network nodes, including a Proxy Call Session Control Function (P-CSCF) , an Interrogating CSCF (I-CSCF) , a Serving CSCF (S-CSCF) , and a core network entity, such as a Home Subscriber Server (HSS) in 4G LTE or an access and mobility management function (AMF) in 5G NR. During this registration procedure, the UE may include information indicating its capability to support the slim / simplified / optimized call mechanism and may exchange media call-related parameters with the network. For example, the UE may include a feature tag (e.g., +g. 3gpp. slimcall or +g. 3gpp. sdp-preconfig) in the REGISTER message to indicate support for pre-configuration of media parameters. The network, such as through the S-CSCF, may respond with corresponding network-side call-related parameters. These parameters are then stored at both the UE and the network (e.g., at the S-CSCF and / or IMS media server) for use in subsequent call establishments within the same registration lifecycle. This method leverages the existing registration procedure to efficiently distribute and synchronize media call-related parameters without requiring additional signaling exchanges.

[0069] Scheme 3: Pre-allocation of call-related parameters: In some implementations, the call-related parameters may be pre-allocated for the calling UE (e.g., UE-1) . Pre-allocation refers to the assignment of specific media parameters to the UE by the network before any call is initiated. This may occur, for example, during the PDU (Packet Data Unit) session establishment procedure when the UE establishes connectivity with the IMS network. The UE may transmit a PDU Session Establishment Request message to the core network, optionally including an IMS data network name (DNN) and an indication that the UE supports the slim / simplified / optimized call mechanism. The PDU Session Establishment Request may include at least one of: (1) an indication that the UE is enabled to support pre-allocation of media parameters, (2) a UE-side port number to be used for voice Real-time Transport Protocol (RTP) transmission for all subsequent IMS calls, and (3) codec-related information compliant with 3GPP, Groupe Speciale Mobile Association (GSMA) , or Internet Engineering Task Force (IETF) specifications. The core network responds with a PDU Session Establishment Accept message that may include network-side media parameters such as an IP address and / or port number of the IMS server to be used for voice RTP transmission. These pre-allocated call-related parameters are stored at both the UE and the network and are subsequently used for all IMS calls, eliminating the need for per-call parameter negotiation.

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

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

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

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

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

[0075] 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. Illustrative Implementations

[0076] FIG. 4 illustrates an example communication system 400 having at least an example communication apparatus 410 and an example network apparatus 420 in accordance with an implementation of the present disclosure. Each of the communication apparatus 410 and network apparatus 420 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 500, 600, and 700 described below.

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

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

[0079] In one aspect, each of the processor 412 and processor 422 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 “aprocessor” is used herein to refer to processor 412 and processor 422, each of the processor 412 and processor 422 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 412 and processor 422 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 412 and processor 422 is a special-purpose machine specifically designed, arranged, and configured to perform specific tasks in a device (e.g., as represented by communication apparatus 410) and a network (e.g., as represented by network apparatus 420) in accordance with various implementations of the present disclosure.

[0080] In some implementations, communication apparatus 410 may also include a memory 414 coupled to processor 412 and capable of being accessed by processor 412 and storing data therein. In some implementations, communication apparatus 410 may further include a transceiver 416 coupled to processor 412 and capable of wirelessly transmitting and receiving data. In some implementations, transceiver 416 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.

[0081] In some implementations, network apparatus 420 may further include a memory 424 coupled to processor 422 and capable of being accessed by processor 422 and storing data therein, and a transceiver 426 coupled to processor 422 and capable of wirelessly transmitting and receiving data. Accordingly, communication apparatus 410 and network apparatus 420 may wirelessly communicate with each other via transceiver 416 and transceiver 426, respectively.

[0082] For illustrative purposes and without limitation, descriptions of capabilities of the communication apparatus 410 and network apparatus 420 are provided below with process 500, process 600, and process 700. In which, communication apparatus 410 is implemented in or as a communication apparatus or a UE, and network apparatus 420 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

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

[0084] At block 510, process 500 may involve processor 412 of communication apparatus 410 transmitting, via transceiver 416, an invite message for an Internet Protocol Multimedia Subsystem (IMS) call to a network. Process 500 may proceed from block 510 to block 520.

[0085] At block 520, process 500 may involve processor 412 transmitting or receiving, via transceiver 416, a first media flow to or from the network without negotiating a set of call-related parameters during a call setup procedure. Process 500 may proceed from block 520 to block 530.

[0086] At block 530, process 500 may involve processor 412 receiving, via transceiver 416, at least one of a 18x response or a 180 Ringing message from the network after transmitting the first media flow.

[0087] In some implementations, process 500 may further involve processor 412 receiving, via transceiver 416, a 200 OK message for the invite message from the network. Process 500 may further involve processor 412 receiving or transmitting, via transceiver 416, a second media flow from or to the network before transmitting an acknowledgement (ACK) message. Process 500 may further involve processor 412 transmitting, via transceiver 416, the ACK message to the network.

[0088] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message.

[0089] In some implementations, the set of 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, REGISTER, or NOTIFY.

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

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

[0092] In some implementations, the first media flow and the invite message are transmitted simultaneously or within a predetermined time window.

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

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

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

[0096] At block 610, process 600 may involve processor 412 of communication apparatus 410 receiving, via transceiver 416, an invite message for an Internet Protocol Multimedia Subsystem (IMS) call from a network. Process 600 may proceed from block 610 to block 620.

[0097] At block 620, process 600 may involve processor 412 receiving or transmitting, via transceiver 416, a first media flow from or to the network without negotiating a set of call-related parameters during a call setup procedure. Process 600 may proceed from block 620 to block 630.

[0098] At block 630, process 600 may involve processor 412 transmitting, via transceiver 416, at least one of a 18x response or a 180 Ringing message to the network after receiving the first media flow.

[0099] In some implementations, process 600 may further involve processor 412 transmitting, via transceiver 416, a 200 OK message for the invite message to the network. Process 600 may further involve processor 412 transmitting or receiving, via transceiver 416, a second media flow to or from the network before receiving an acknowledgement (ACK) message. Process 600 may further involve processor 412 receiving, via transceiver 416, the ACK message from the network.

[0100] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message .

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

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

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

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

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

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

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

[0108] At block 710, process 700 may involve processor 422 of network apparatus 420 receiving and transferring, via transceiver 426, an invite message for an Internet Protocol Multimedia Subsystem (IMS) call from a first UE (e.g., communication apparatus 410, UE-1, or UE 101) to a second UE (e.g., communication apparatus 410, UE-2, or UE 101) . Process 700 may proceed from block 710 to block 720.

[0109] At block 720, process 700 may involve processor 422 receiving and transferring, via transceiver 426, a first media flow between the first UE and the second UE without negotiating a set of call-related parameters during a call setup procedure. Process 700 may proceed from block 720 to block 730.

[0110] At block 730, process 700 may involve processor 422 receiving and transferring, via transceiver 426, at least one of a 18x response or a 180 Ringing message from the second UE to the first UE after transferring the first media flow.

[0111] In some implementations, process 700 may further involve processor 422 receiving and transferring, via transceiver 426, a 200 OK message for the invite message from the second UE to the first UE. Process 700 may further involve processor 422 receiving and transferring, via transceiver 426, a second media flow between the second UE and the first UE before receiving and transferring an acknowledgement (ACK) message from the first UE to the second UE. Process 700 may further involve processor 422 receiving and transferring, via transceiver 426, the ACK message from the first UE to the second UE.

[0112] In some implementations, the invite message is a Session Initiation Protocol (SIP) INVITE message .

[0113] In some implementations, the 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, REGISTER, or NOTIFY.

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

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

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

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

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

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

[0120] 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., “asystem 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., “asystem 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. ”

[0121] 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 for an Internet Protocol Multimedia Subsystem (IMS) call to a network;transmitting or receiving, by the processor, a first media flow to or from the network without negotiating a set of call-related parameters during a call setup procedure; andreceiving, by the processor, at least one of a response or a180 Ringing message from the network after transmitting the first media flow.2.The method of claim 1, further comprising:receiving, by the processor, a 200 OK message for the invite message from the network;receiving or transmitting, by the processor, a second media flow from or to the network before transmitting an acknowledgement (ACK) message; andtransmitting, by the processor, the ACK message to the network.3.The method of claim 1, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message.4.[Corrected under Rule 26, 22.04.2026]The method of claim 1, wherein the set of 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, REGISTER, or NOTIFY.5.The method of claim 1, wherein the set of call-related parameters comprises SDP parameters.6.The method of claim 1, wherein the set of call-related parameters is one of a plurality of sets of call-related parameters; and wherein an index of the set of call-related parameters is UE-indicated or network-indicated.7.The method of claim 1, wherein the first media flow and the invite message are transmitted simultaneously or within a predetermined time window.8.A method, comprising:receiving, by a processor of a user equipment (UE) , an invite message for an Internet Protocol Multimedia Subsystem (IMS) call from a network;receiving or transmitting, by the processor, a first media flow from or to the network without negotiating a set of call-related parameters during a call setup procedure; andtransmitting, by the processor, at least one of a response or a 180 Ringing message to the network after receiving the first media flow.9.The method of claim 8, further comprising:transmitting, by the processor, a 200 OK message for the invite message to the network;transmitting or receiving, by the processor, a second media flow to or from the network before receiving an acknowledgement (ACK) message; andreceiving, by the processor, the ACK message from the network.10.The method of claim 8, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message.11.The method of claim 8, wherein 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, REGISTER, or NOTIFY.12.The method of claim 8, wherein the set of call-related parameters comprises SDP parameters.13.The method of claim 8, wherein the set of call-related parameters is one of a plurality of sets of call-related parameters; andan index of the set of call-related parameters is UE-indicated or network-indicated.14.The method of claim 9, wherein the 200 OK message and the second media flow are transmitted simultaneously or within a predetermined time window.15.A method, comprising:receiving and transferring, by a network, an invite message for an Internet Protocol Multimedia Subsystem (IMS) call from a first user equipment (UE) to a second UE;receiving and transferring, by the network, a first media flow between the first UE and the second UE without negotiating a set of call-related parameters during a call setup procedure; andreceiving and transferring, by the processor, at least one of a response or a 180 Ringing message from the second UE to the first UE after transferring the first media flow.16.The method of claim 15, further comprising:receiving and transferring, by the network, a 200 OK message for the invite message from the second UE to the first UE;receiving and transferring, by the network, a second media flow between the second UE and the first UE before receiving and transferring an acknowledgement (ACK) message from the first UE to the second UE; andreceiving and transferring, by the network, the ACK message from the first UE to the second UE.17.The method of claim 15, wherein the invite message is a Session Initiation Protocol (SIP) INVITE message.18.The method of claim 15, wherein the set of call-related parameters is provided to the first UE to respond to an SIP early message before receiving the invite message; and wherein the SIP early message comprises at least one of INVITE, INFO, REGISTER, or NOTIFY.19.The method of claim 15, wherein the set of call-related parameters comprises SDP parameters.20.The method of claim 15, wherein the set of call-related parameters is one of a plurality of sets of call-related parameters; and wherein an index of the set of call-related parameters is UE-indicated or network-indicated.

Images