Method for enabling a satellite call service

Abstract

A method for enabling a satellite call service is executed by a first node involved in a call service. The first node exchanges, between nodes involved in the call service through a satellite access or non-Terrestrial Network (NTN), information that includes one or more of access types, transmission rates, supported codecs of calling user equipment (UE) and called UE, call setup time, and one-way propagation delay. The first node performs for the call service one or more of header reduction, codec selection, and signalling reduction based on the information.

Description

METHOD FOR ENABLING A SATELLITE CALL SERVICEBACKGROUND OF DISCLOSURE1. Field of Disclosure

[0001] The present disclosure relates to the field of satellite wireless communication systems, and more particularly, to a method for enabling a satellite call service. 2. Description of Related Art

[0002] 5G is expanding its reach to remote areas by incorporating satellite access, offering consistent connectivity anywhere. Since Release 17, 3rd Generation Partnership Project (3GPP) standards have included 5G satellite access, enabling services like voice calls, messaging, and video communication.

[0003] Release 18 introduced features like location verification and improved mobility between satellite and terrestrial networks. Release 19 further enhanced this by adding support for advanced satellite operations and direct communication between devices via satellite.

[0004] Looking ahead to 5G Advanced (Rel-20) , a new study aims to improve voice services (Internet Protocol Multimedia subsystem (IMS) ) over narrowband geostationary orbit (GEO) satellites. This presents significant challenges due to GEO satellites' high altitude, long transmission delays, and limited bandwidth.Technical Problem:

[0005] Specifically, the challenges are illustrated in the following: 1 Data rate limitations: Transmitting voice data over GEO satellites requires a minimum data rate that  exceeds the current capabilities of narrowband GEO systems. 2 High latency: The delay in transmitting voice packets over GEO satellites can be too high for optimal  voice quality. 3 Call setup delays: Establishing a voice call over GEO satellites takes significantly longer than the  recommended time, impacting user experience.

[0006] Therefore, integrating IMS with GEO satellites requires careful design to ensure acceptable voice quality. A method is desirable to address these challenges and enable efficient IMS voice services over GEO satellites within the 5G framework.SUMMARY

[0007] An object of the present disclosure is to propose a method for enabling a satellite call service and system.

[0008] In a first aspect, an embodiment of the invention provides a method for enabling a satellite call service executed by a first node involved in a call service comprising: exchanging, between nodes involved in the call service through satellite access or a non-Terrestrial Network (NTN) , information that includes one or more of access types, transmission rates, supported codecs of calling user equipment (UE) and called UE, call setup time, and one-way propagation delay; and performing for the call service at least of a header reduction, a codec selection, and / or a signalling reduction based on the information.

[0009] An embodiment of the invention provides a user equipment (UE) comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the disclosed method and any combination of embodiments of the disclosed method.

[0010] An embodiment of the invention provides a network node comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method. The network node may be a RAN node, a core network node, or a IMS node.

[0011] The disclosed method may be programmed as computer executable instructions stored in non-transitory computer readable medium. The non-transitory computer readable medium, when loaded to a computer, directs a processor of the computer to execute the disclosed method.

[0012] The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

[0013] The disclosed method may be programmed as a computer program product that causes a computer to execute the disclosed method.

[0014] The disclosed method may be programmed as a computer program that causes a computer to execute the disclosed method.Advantageous Effects

[0015] The invention offers several significant advantages for satellite-based communications systems. First and foremost, it enables IMS voice calls to function effectively over narrowband GEO satellites, which was previously challenging due to bandwidth limitations. Through the disclosed methods, the system achieves notable reductions in call setup times and transmission delays, making satellite communications more responsive and user-friendly. Voice quality is substantially improved through intelligent codec selection and optimization techniques that work within satellite bandwidth constraints. These enhancements collectively contribute to a superior user experience for satellite-based communications, making the technology more practical for everyday use. The invention proves particularly valuable in extending 5G coverage to remote and rural areas where traditional terrestrial networks are impractical or impossible to implement, while still maintaining voice communication quality that meets acceptable standards. This breakthrough helps bridge the digital divide by bringing reliable voice communications to previously underserved regions.

[0016] This disclosure describes methods for enabling high-quality IMS voice calls over satellites with limited bandwidth and high latency, such as those in geostationary orbit (GEO) . These methods aim to improve the user experience by addressing one or several of the following key challenges: 1. Reducing data rate requirements:

[0017] To avoid or minimize the need for transcoding, which can degrade audio quality, the methods employ techniques like: ● Protocol compression: Reducing the size of protocol headers in IMS voice packets through the  proposed header compression. ● Signaling reduction: Minimizing the number of signaling messages exchanged. ● Codec selection: Choosing codecs that efficiently use the available bandwidth. 2. Optimizing transmission delay:

[0018] To ensure smooth conversations and quick call setup, the methods focus on: ● Minimizing latency: Keeping the overall delay of IMS voice packets below the ITU-recommended  limits for telephony services. ● Reducing call setup time: Optimizing the process of establishing an IMS call to meet acceptable  standards. 3. Improving network efficiency:

[0019] To make the most of the limited bandwidth available on GEO satellite links, the methods introduce: ● Header compression: Reducing the overhead of protocol headers. ● Signaling optimization: Minimizing the number of signaling messages.

[0020] By addressing these challenges, the proposed methods aim to enable a positive user experience for IMS calls over GEO satellites, with clear audio, minimal delays, and efficient use of network resources.BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present disclosure or related art, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field may obtain other figures according to these figures without paying the premise.

[0022] FIG. 1 illustrates a schematic view showing an NTN with a regenerative payload hosting a gNB on board a satellite.

[0023] FIG. 2 illustrates a schematic view showing a solution for addressing data rate and / or transcoding issues.

[0024] FIG. 3 illustrates a schematic view showing a solution for addressing delay and call setup time issues.

[0025] FIG. 4 illustrates a schematic view showing signaling exchange to invoke a setup of low overhead / reduced headers for IMS protocol.

[0026] FIG. 5 illustrates a schematic view showing a method to apply adaptive protocol compression for IMS voice packet encapsulation and a method to select codecs that are similar to each other.

[0027] FIG. 6 illustrates a schematic view showing a method and procedure for finding optimal compressed header plan.

[0028] FIG. 7 illustrates a schematic view showing an example of a random header distribution for AMR codec transmission over 1 kbps GEO.

[0029] FIG. 8 illustrates a schematic view showing an example of a bitwise header distribution for AMR codec transmission over 1 kbps GEO.

[0030] FIG. 9 illustrates a schematic view showing a method for selecting codecs close to each other to encode IMS UP session the packets.

[0031] FIG. 10 illustrates a schematic view showing a method to address delays and call setup time.

[0032] FIG. 11 illustrates a schematic view showing a lightweight / reduced IMS signalling based on optimized delay and call setup time.

[0033] FIG. 12 illustrates a schematic view showing a procedure to find optimal signalling reduction in bytes that minimize the delay and call setup time.

[0034] FIG. 13 illustrates a schematic view showing an example of reduced IMS signaling for AMR codec for GEO with achievable 1 kbps data rate.

[0035] FIG. 14 illustrates a schematic view showing an example of reduced IMS signaling for 1 kbps GEO using PRACK message elimination and header optimization.

[0036] FIG. 15 illustrates a schematic view showing an example of detailed solution based on UPDATE message elimination and header optimizing for reduced IMS signaling for GEO with 1 kbps data rate.

[0037] FIG. 16 illustrates a schematic view showing an inter-access IMS session flow section.

[0038] FIG. 17 illustrates a schematic view showing signaling in default procedures for IMS call involving UEs under different radio access.

[0039] FIG. 18 illustrates a schematic view showing an example of full signaling procedures considering IMS deciding the header compression, codec selection and / or signaling reduction.

[0040] FIG. 19 illustrates a schematic view showing an example of full signaling procedures considering gNB / AMF / SMF node decides the header compression / selection and / or signaling reduction.

[0041] FIG. 20 illustrates a schematic view showing an example of a user equipment (UE) .

[0042] FIG. 21 illustrates a schematic view showing an example of a network node.

[0043] FIG. 22 illustrates a schematic view showing a chip or executing the disclosed method in a UE.

[0044] FIG. 23 illustrates a schematic view showing a chip or executing the disclosed method in a network node.DETAILED DESCRIPTION OF EMBODIMENTS

[0045] Embodiments of the disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

[0046] Abbreviations used in the description are listed in the following: Table 1

[0047] This invention introduces methods to improve the quality and efficiency of IMS calls (e.g., voice call) over GEO satellite networks. These methods include new indication exchanges, procedures, and protocol compression techniques that reduce the size of IMS voice packet headers and minimize signaling messages during call setup and ongoing calls.

[0048] The primary goals of these methods are to: 1 Minimize or eliminate the need for transcoding: Transcoding can degrade audio quality, introduce  artifacts, and increase processing demands. By reducing the data rate requirements of IMS voice packets, these methods aim to avoid transcoding altogether, ensuring clear and consistent audio for users. 2 Reduce latency: GEO satellites introduce significant delays in voice communication. These methods  aim to keep call setup times, propagation delays, and processing delays within the recommended International Telecommunication Union (ITU) limits for optimal voice quality. This ensures a responsive and natural conversation experience. 3 Improve network efficiency: By reducing protocol overhead and minimizing signaling messages, these  methods optimize bandwidth usage and improve overall network efficiency. This is crucial for GEO satellite links, which often have limited bandwidth.

[0049] Ultimately, this invention seeks to provide acceptable IMS call quality over GEO satellite wireless access by addressing the unique challenges of this communication medium.

[0050] This disclosure provides methods for enabling efficient IMS calls over GEO satellites, which are high-altitude, narrowband satellites with limited bandwidth. It also aims to improve inter-domain IMS calls between GEO satellite access and other terrestrial / non-terrestrial networks (TN / NTN) .

[0051] With reference to FIG. 1, a first node executes a method for enabling a satellite call service. The first node is involved in a call service. Instance of the first node may comprise a user equipment (UE) , an IMS node, a base station (e.g., a gNB) , and a core network node. Examples of the IMS node are shown as IMS in the drawings. The base station may comprise a gNB. The core network node may comprise an AMF or an SMF. Examples of the core network node are shown as core or CN in the drawings.

[0052] Step S001: The first node exchanges, between nodes involved in the call service through satellite access or a non-Terrestrial Network (NTN) , information that includes one or more of access types, transmission rates, supported codecs of calling user equipment (UE) and called UE, call setup time, and one-way propagation delay.

[0053] Step S002: The first node performs for the call service at least one of a header reduction, a codec selection, and / or a signalling reduction based on the information.

[0054] Step S003: The first node provides feedback regarding a compressed header reduction plan, a selected codecs, a signaling reduction plan to the nodes involved in IMS communications.

[0055] In one or more embodiments of the disclosure, the information is transmitted through at least one of: Radio Resource Control (RRC) signaling between the UEs and a Next Generation Radio Access Network  (NG-RAN) ; Non-Access Stratum (NAS) signaling between the UEs and a core network entity; or IMS protocol signaling using Session Description Protocol (SDP) transactions between the UEs and an  IMS node.

[0056] In one or more embodiments of the disclosure, the performing for the call service further comprises: determining, based on the information, a selected compressed header reduction plan that ensures a data rate calculated from an Internet Protocol Multimedia Subsystem (IMS) codec bitrate remains below an achievable transmission data rate of a geosynchronous equatorial orbit (GEO) satellite and a desired transmission data rate for sending IMS messages is less than or equal to the achievable transmission data rate of the GEO satellite; distributing the selected compressed header reduction plan among protocol stacks used for encapsulating  IMS packets; and providing feedback regarding the selected compressed header reduction plan to the nodes involved in IMS  communications.

[0057] In one or more embodiments of the disclosure, the method further comprises: applying static field compression to static header fields; and / or applying dynamic field compression to dynamic header fields.

[0058] In one or more embodiments of the disclosure, the static header fields with fixed header values comprise one or more of protocol identifiers, padding, and constant addresses; and The dynamic header fields comprise one or more of checksum, flags, sequence numbers, and timestamps.

[0059] In one or more embodiments of the disclosure, the protocol stacks comprise one or more of: Real-time Transport Protocol (RTP) ; User Datagram Protocol (UDP) ; Internet Protocol (IP) ; Packet Data Convergence Protocol (PDCP) ; Radio Link Control (RLC) ; and Medium Access Control (MAC) .

[0060] In one or more embodiments of the disclosure, the feedback is signaled through at least one of: IMS protocol signaling; Non-Access Stratum (NAS) signaling; or Radio Resource Control (RRC) signaling.

[0061] In one or more embodiments of the disclosure, the method further comprises: determining a total bit constraint for compressed headers; implementing a compression strategy to allocate available bits among multiple protocol layers; and  compressing protocol headers according to the implemented compression strategy.

[0062] In one or more embodiments of the disclosure, the compression strategy comprises a Random Distribution Strategy, and the implementing the compression strategy comprises: allocating a minimum necessary number of bits to each protocol layer according to a predetermined  distribution pattern; ensuring balanced bit distribution across protocol layers; and maintaining consistent overhead allocation across protocols within the total bit constraint.

[0063] In one or more embodiments of the disclosure, allocating the minimum necessary number of bits comprises: assigning bits to Real-time Transport Protocol (RTP) for sequence numbers and timing information; assigning bits to User Datagram Protocol (UDP) for checksums and port information; assigning bits to Internet Protocol (IP) for addressing functions; assigning bits to Packet Data Convergence Protocol (PDCP) for sequence numbers and encryption; assigning bits to Radio Link Control (RLC) for dynamic fields; and assigning bits to Medium Access Control (MAC) for access control.

[0064] In one or more embodiments of the disclosure, for a 20-bit total constraint, the Random Distribution Strategy allocates: 6 bits to RTP; 4 bits to UDP; 2 bits to IP; 4 bits to PDCP; 2 bits to RLC; and 2 bits to MAC.

[0065] In one or more embodiments of the disclosure, the compression strategy comprises a Bitwise Optimization Strategy, and the implementing the compression strategy comprises: determining criticality levels of different protocol functions; analyzing protocol interdependencies; allocating bits based on protocol criticality; and

[0066] optimizing bit distribution for critical functions while maintaining functionality for less critical functions. In one or more embodiments of the disclosure, for a 20-bit total constraint, the Bitwise Optimization Strategy  allocates: 4 bits to RTP optimized for timing synchronization; 2 bits to UDP for port management; 4 bits to IP prioritizing routing functionality; 4 bits to PDCP emphasizing security operations; 2 bits to RLC for reliable data transfer; and 4 bits to MAC optimizing access control.

[0067] In one or more embodiments of the disclosure, the method further comprises: monitoring network conditions and protocol performance; adjusting bit allocation based on real-time requirements; and maintaining performance for critical functions through adaptive bit distribution.

[0068] In one or more embodiments of the disclosure, the protocol headers are compressed from 416 bits to 20 bits while maintaining protocol functionality.

[0069] In one or more embodiments of the disclosure, the performing for the call service further comprises: selecting, based on the information, codecs to minimize transcoding requirements between the calling UE and the called UE, wherein one of the UEs comprises a UE accessing via GEO satellite, and the other one of the UEs comprises another UE accessing via non-GEO satellite or terrestrial network; and providing feedback to the nodes involved in IMS communications regarding the selected codecs.

[0070] In one or more embodiments of the disclosure, the selecting codecs comprises: identifying codec pairs with minimal bitrate differences while maintaining voice quality above a target  threshold based on Mean Opinion Score (MOS) ratings.

[0071] In one or more embodiments of the disclosure, the codecs comprises one or more of: Adaptive Multi-Rate (AMR) ; AMR Wideband (AMR-WB) ; Enhanced Voice Services (EVS) ; EVS Primary Silence Insertion Descriptor (SID) ; EVS Special case; and AMR-WB SID.

[0072] In one or more embodiments of the disclosure, the feedback is signaled through at least one of: IMS protocol signaling; Non-Access Stratum (NAS) signaling; or Radio Resource Control (RRC) signaling.

[0073] In one or more embodiments of the disclosure, the performing for the call service further comprises: determining, based on the information, a signaling reduction plan that maintains both call setup time and total propagation and processing delay within International Telecommunication Union (ITU) recommended limits; and

[0074] providing feedback regarding the signaling reduction plan to the nodes involved in IMS communications. In one or more embodiments of the disclosure, the determining the signaling reduction plan comprises: calculating a maximum allowable message transmission delay by subtracting a maximum propagation  and processing delay from a maximum total delay; calculating an allowable IMS signaling message size based on the maximum allowable message  transmission delay and an achievable transmission data rate among the transmission rates; and determining a number of signaling messages to eliminate based on comparing the allowable IMS  signaling message size with a default IMS message size.

[0075] In one or more embodiments of the disclosure, the signaling reduction plan comprises eliminating one or more non-essential Session Initiation Protocol (SIP) messages while maintaining call setup functionality; and consolidating information elements (IEs) and headers from eliminated messages into remaining messages.

[0076] In one or more embodiments of the disclosure, the feedback is signaled through at least one of: IMS protocol signaling; Non-Access Stratum (NAS) signaling; or Radio Resource Control (RRC) signaling.

[0077] In one or more embodiments of the disclosure, the eliminated messages comprise one or more of SIP TRYING, SIP PRACK, SIP 200 OK PRACK, SIP UPDATE, SIP 200 OK UPDATE.

[0078] In one or more embodiments of the disclosure, the remaining messages comprise one or more of SIP 183, SIP 180 Ring, SIP 200 OK for invitation, and SIP ACK.

[0079] In one or more embodiments of the disclosure, the IEs consolidated into the remaining messages comprise one or more of quality of service (QoS) and codecs selected by the calling UE and session modifications.

[0080] In one or more embodiments of the disclosure, when the first node is an IMS node, the method further comprises: transmitting signals to determine the optimization plan to at least one of: a Session Management Function  (SMF) via Nsmf_communication; an Access and Mobility Management Function (AMF) via Namf_communication; or a base station via Next Generation Application Protocol (NGAP) Protocol Data Unit (PDU) session modification signaling.

[0081] In one or more embodiments of the disclosure, when the first node is a base station, the method further comprises: indicating the optimization plan to: an AMF via NGAP PDU session modification signaling; an SMF via NGAP and Namf_communication; an IMS node via NGAP PDU session modification, Namf_communication and Nsmf_communication;  the calling UE via RRC signaling; and a called UE via at least one of NGAP PDU session modification, Namf_communication,  Nsmf_communication, or SIP signaling.

[0082] In one or more embodiments of the disclosure, when the first node is an AMF, the method further comprises: indicating the optimization plan to: an SMF via Namf_communication; an IMS node via Namf_communication and Nsmf_communication; the calling UE via NAS signaling; and a called UE via Namf_communication, Nsmf_communication and NAS signaling.

[0083] The proposed methods focus on three key areas: 1. Addressing data rate limitations: ● Eliminate transcoding: GEO satellites have low transmission rates compared to the data rates  required by many common IMS voice codecs, thus a transcoding may be needed if one party of the voice service call is a GEO satellite. To avoid the need for transcoding, which can degrade audio quality, the methods propose new indication signaling and header reduction or protocol compression techniques. These compression techniques aim to reduce the data rate requirements of IMS voice packets so the packets can be transmitted efficiently over GEO satellites without a need of transcoding.  2. Mitigating transcoding impacts: ● Minimizing quality degradation: In cases where transcoding is unavoidable, the methods aim to  minimize its negative impacts. To minimize the impact of transcoding, which can degrade audio quality, the methods propose new indication signaling and codec selection techniques. These techniques aim to select codecs with data rates compatible with GEO satellite capabilities, thus ensuring clear and consistent audio during inter-domain calls. 3. Reducing latency and call setup time: ● Optimizing signaling: To ensure timely call setup and smooth conversations, the methods propose  techniques to minimize the rate of IMS signaling messages exchanged between network nodes. This helps keep the overall IMS call setup time and propagation &processing delay of voice packets within the recommended ITU limits for telephony services.

[0084] By addressing these challenges, the proposed methods aim to enable high-quality IMS voice services over GEO satellite access, even with its inherent limitations. Note that the disclosed method is not limited to voice call. The embodiments of the disclosed method can be applied to video call, teleconferencing, surveillance, and other applications.

[0085] Solution #1: To Address Low Transmission Rate Issue:

[0086] FIG. 2 shows a solution for addressing data rate and / or transcoding issues.

[0087] This solution tackles the challenge of low transmission rates in GEO satellite communication, particularly for IMS calls. Since GEO satellites have limited bandwidth compared to the data rate needs of common voice codecs, this solution aims to minimize or eliminate the need for transcoding, which can degrade audio quality during inter-domain calls (e.g., between a user on a GEO satellite and a user on a terrestrial network) . FIG. 5 illustrate a signaling procedure of the solution. The procedure of the solution addresses data rate and / or transcoding issues. The solution offers two main approaches: A) Eliminating Transcoding:

[0088] This approach focuses on reducing the data rate requirements of IMS voice packets so the packets can be transmitted efficiently over GEO satellites without a need of transcoding. The transcoding eliminating approach involves one or more of the following: ● Exchanging signaling indications: Network nodes involved in the IMS call exchange information  about access types (GEO, LEO, and MEO) , achievable data rates, and supported codecs. This allows the network to select a suitable low-overhead protocol and ensure proper synchronization between involved nodes (as detailed in Embodiment 1) . ● Finding an optimal header reduction plan: Procedures are used to determine the best way to  compress protocol headers, minimizing the overall data rate and ensuring the overall data rate remains below the GEO satellite's transmission capacity. Procedures are implemented to determine optimal compressed header reduction plans in bytes, ensuring data rates based on reported IMS codec bitrates remain below achievable transmission rates of UHF, S and L-band-GEO satellites (As detailed in Embodiment 3) . ● Implementing new header compression techniques: New protocols header compression  techniques are used to reduce the size of IMS voice packets, optimizing the packets for transmission over GEO satellite links and ensuring required transmission data rates stay below reported GEO satellite transmission speeds (as detailed in Embodiment 4) . B) Minimizing Transcoding Impacts:

[0089] In cases where transcoding is unavoidable, this approach aims to minimize its negative effects on audio quality. This approach selects codecs with minimal bitrate differences for inter-domain IMS calls to reduce disadvantages of transcoding between codecs with significant bitrate variations. The transcoding impact minimizing approach involves one or more of the following: ● Exchanging signaling information: Similar to the previous approach, network nodes exchange  information about access types and supported codecs. This helps in selecting two codecs with similar bitrates for encoding and decoding the voice data, minimizing the differences that can lead to audio quality degradation during transcoding (as detailed in Embodiment 1) . ● Implementing codec selection procedures: Procedures are used to select the most suitable codecs  for inter-domain IMS calls between calling parties (as detailed in Embodiment 4) , minimizing transcoding requirements and ensuring the best possible audio quality.

[0090] This solution aims to provide a seamless and high-quality voice communication experience for users accessing IMS services over GEO satellites, despite the challenges of limited bandwidth.

[0091] Solution #2: To Address Long Delay and Call Setup Issue:

[0092] FIG. 3 illustrates a solution for addressing delay and call setup time issues. This solution addresses the issue of long delays and call setup times that are inherent in IMS voice communication over GEO satellites. Due to the high altitude of these satellites, significant delays can occur in transmitting voice packets, impacting the quality of real-time conversations.

[0093] To mitigate these delays, the solution focuses on minimizing the number of signaling messages exchanged between network nodes during an IMS call. This solution aims to minimize IMS signaling message exchange rates between nodes involved in IMS calls to maintain overall IMS call setup time, propagation delay, and processing delay of IMS voice packets over GEO satellite within recommended ITU budget telephony services parameters. The solution implements the following signaling exchanges and procedures: ● Exchanging signaling indications: Network nodes share information about various factors that can  affect call setup and transmission delays. This includes access type (GEO, LEO, MEO) , one-way propagation delay of the GEO satellite link, achievable data rates, and supported codecs. This exchange helps reduce or eliminate unnecessary IMS signaling messages between nodes involved in IMS calls. ● Providing feedback on reduced signaling: After reducing signaling messages, feedback is  exchanged between nodes to ensure proper communication and synchronization between involved nodes (as detailed in Embodiment 5) . ● Finding an optimal signaling reduction plan: Procedures are implemented to determine the most  effective signaling reduction plan for messages between nodes involved in IMS calls. This ensures both call setup time and total propagation and processing delay of IMS voice packets over GEO satellite remain within ITU recommendations for acceptable voice call quality (as detailed in Embodiment 6) . ● Implementing detailed signaling reduction proposals: Specific proposals are outlined to ensure  that both call setup time and overall delay (e.g., propagation and processing delay ) remain within the ITU-recommended limits for telephony services (as detailed in Embodiment 7)

[0094] By optimizing signaling exchanges, this solution aims to minimize latency and ensure a smooth and responsive experience for users making IMS voice calls over GEO satellites.

[0095] Embodiment 1: Signaling to Address Low Transmission Rate Issue

[0096] FIG. 4 illustrates signaling exchange to invoke a setup of low overhead / reduced headers for IMS protocol. This embodiment addresses scenarios where the data rate required to transmit IMS voice messages over GEO satellite air interface exceeds the actual achievable uplink transmission rate, or where transcoding becomes necessary for inter-domain IMS calls between GEO and other networks. To address these challenges, the system implements a signaling exchange between the UE and either the IMS system, 5GC (AMF / SMF) , or gNB. This exchange includes several critical types of signaling information including: 1. Access type indication; 2. Supported codecs information; 3. Transmission rate indication; and 4. Codec quality selection factor. 1. Access Type Indication:

[0097] The first type of information is an access type indication, which specifies the satellite type such as GEO, MEO, or LEO. This indication helps determine whether an optimal signaling or reduction plan is necessary. For example, when GEO access is indicated, the node will initiate optimization procedures; otherwise, it will follow the default signaling procedures. 2. Supported Codecs Information:

[0098] The second type is information about supported codecs from the UE. This indication provides essential parameters such as frame length and codec bit-rate, which are necessary for calculating the optimal header reduction optimization plan. 3. Transmission Rate Indication:

[0099] The third type involves an indication of the achievable transmission data rate for the given GEO satellite. This information plays a crucial role in calculating the header reduction optimization plan and ensuring efficient transmission. An example of the header reduction optimization plan is given in Embodiment 4. 4. Codec Quality Selection Factor.

[0100] The fourth type is a codec quality selection factor, which serves as a bitrate threshold for minimizing transcoding impacts. One approach is to use the Mean Opinion Score (MOS) as a measure for voice quality after the transcoding process. This threshold works in conjunction with the UE's supported codecs information to help select codecs that have minimal differences in bitrates while still achieving the required voice quality after transcoding.

[0101] Through this comprehensive signaling framework, the system can intelligently optimize transmission parameters while maintaining high voice quality standards across different network domains. An example scenario is provided in Embodiment 7. An example of signaling exchange is detailed in Embodiment 8.

[0102] Based on the received indications, a RAN, 5GC and / or IMS node evaluates the scenario and follows one of two decision paths:

[0103] For the first path, the node takes the following three actions if any of these conditions are met: ● GEO access type is indicated; ● The delay and call setup time exceeds the ITU-recommended budget for the IMS call; or ● A header optimization plan exists where the calculated data rate (based on the reported IMS codec  bitrate) is below the achievable transmission rate of a narrowband GEO satellite.

[0104] When these conditions apply, the node takes three actions: 1 The node finds an optimal compressed header reduction plan in bytes, ensuring the data rate  calculated from the UE's reported IMS codec bitrate remains below the GEO satellite's achievable transmission rate. 2 The node either performs encapsulation / compression of the IMS voice packet using this optimal  plan, instructs lower layer nodes (like 5GC or RAN) to calculate and implement the protocol header plan, or both. 3 The node provides feedback to the UE (either directly or through intermediate nodes) about the  reduced headers, ensuring proper de-capsulation and synchronization of IMS protocols across all nodes involved in the call.

[0105] For the second path, the node takes the following three actions if any of these conditions are met: ● The indicated access type is not GEO; or ● No header optimization plan exists where the data rate (based on reported IMS codec bitrate) is below  the narrowband GEO satellite's achievable transmission rate.

[0106] In these cases, the node: 1 Executes a codec selection procedure and recommends appropriate low bitrate codecs to the  calling / called party / UE that will minimize transcoding impact when one UE uses GEO satellite access and the other uses NGEO or TN access. 2 Provides feedback signaling about the selected codecs plan to ensure minimal transcoding  impacts.

[0107] An example of a procedure for selecting the optimal compressed header reduction plan is detailed in Embodiment 2. An example of a feedback procedure is detailed in Embodiment 8.

[0108] FIG. 5 (A) illustrates a method to apply adaptive protocol compression for IMS voice packet encapsulation.

[0109] FIG. 5 (B) illustrates a method to select codecs that are similar to each other.

[0110] Embodiment 2: Finding Optimal Headers Reduction Plan

[0111] This embodiment discusses the procedures used to find an optimal compressed header reduction plan in bytes such that the data rate calculated based on the reported IMS codec bitrate is less than the achievable transmission rate of UHF, S and L-band-GEO satellite.

[0112] FIG. 6 shows a procedure for finding an optimal header reduction plan. The problem can be expressed as an optimization problem with the objective of finding minimum compressed header size (H) such that the desired transmission data rate (R) for sending IMS messages is less than or equal to GEO satellite air interface data rate (1 to 3 kbps) . The procedures for finding an optimal header reduction plan include: 1 Defining or obtaining the following parameters from UE and / or from another intermediate node: ● h: Default headers; ● p: payload; ● r: Default required transmission rate based on default header h and payload; ● R: Desired GEO transmission data rate ● UE supported codec parameters: ■ L: Codec frame length L; ■ P: Payload size P; and / or ■ B: codec bit-rate B. 2 Setting up the proportion to solve for New Compressed Header Size (H) using the known header and  payloads sizes and corresponding rates: 3 Substituting the default known values into the equation and solve by finding new optimal compressed  header size H such that R*L≤ (H+P) , given desired transmission rate (R) , the frame length L and bit-rate B of the reported supported codec. 4 Distributing the new optimal headers among the protocols used to formulate the encapsulation plan  for the IMS packet or RTP payload (As illustrated in Embodiment 4) .

[0113] The difference between the calculated header value and common header compressed protocols indicates how much compression enhancement is needed compared to standard protocols.

[0114] An example of finding an optimal compressed header reduction plan in bytes is presented below, using these parameters: ● AMR codec specifications: ■ Frame length L = 20ms ■ Bit-rate B = 4.75kbps ● Default plan metrics: ■ RTP packet size (h0+p0) = 536 bits ■ Required transmission rate r0 = 26.8 kbps ● Compressed plan metrics: ■ Compressed packet header (h1+p1) = 184 bits ■ Required transmission rate r1 = 9.2 kbps

[0115] The optimal compressed header plan size that guarantees a narrow band GEO transmission rate below 1 and 3 kbps for a narrow band GEO satellite, along with the possible reduction in total header compared to common compression technique, is given in Table 2 below. Table 2: Example of optimal header size for 1 to 3 kbps for a narrow band GEO satellite

[0116] Table 2 illustrates the optimal header size requirements for various protocols when transmitting over a narrowband GEO satellite with data rates of 1-3 kbps. The table compares the default header size in bits against the common compressed size for six different protocols: RTP, UDP, IP, PDCP, RLC, and MAC. For example, RTP's default size of 96 bits can be compressed to 24 bits, while IP's larger default size of 160 bits can be compressed to 48 bits. The total default header size across all protocols is 416 bits. When operating at 1 kbps, the compression achieves a 20-bit reduction from the common compressed size of 132 bits, resulting in 112 bits. At 3 kbps, a more aggressive 60-bit reduction is achieved, bringing the total down to 72 bits. This compression scheme demonstrates how the protocol stack can be optimized to work within the limited bandwidth constraints of GEO satellite communications.

[0117] Embodiment 3: Header Compression Techniques for Encapsulating IMS Packets

[0118] This embodiment discusses the procedures used to perform encapsulation plan distribution based on the optimal compressed header reduction plan in bytes computed in embodiment 3. When distributing the computed header among the protocol stacks used for encapsulating IMS packets to formulate the new header compression plan, one or more of the following schemes can be applied: 1 Static Fields Compression: ■ Static fields compression applies to fixed header values, protocol identifiers, padding, and  constant addresses. The compression technique uses shorter representations and omits repetitive values, which results in significant data size reduction while maintaining information integrity. Details about static fields can be found in Table 3. 2 Dynamic Fields Compression: ■ For dynamic fields like sequence numbers and timestamps, adaptive compression techniques that  can handle variations should be used. However, dynamic critical control information such as header checksums and essential flags should remain uncompressed or minimally compressed to ensure data integrity and correct packet interpretation at the receiver. Table 3 provides detailed information about dynamic fields compression. 3 Initial vs Subsequent Packets: ■ The treatment of initial versus subsequent packets differs in the compression approach. Initial IMS  packets should use complete headers to ensure accurate session establishment. After establishment, subsequent packets can be compressed to optimize transmission and reduce overhead.

[0119] For determining an optimal strategy to distribute the computed header among protocol stacks, consider: ■ An optimal strategy for distributing the computed header among protocol stacks can be  determined based on the size of static and dynamic fields in protocol headers, as detailed in Table 4. This distribution strategy should also take into account all the previously mentioned compression approaches for both static and dynamic fields. Table 3: Static and dynamic fields of protocols headers used to encapsulate IMS packet

[0120] Table 3 outlines the static and dynamic fields present in various protocol headers used for encapsulating IMS packets. For RTP (Real-time Transport Protocol) , static fields include Version, Padding, Extension, and Payload Type, while dynamic fields include Sequence Number, Timestamp, and SSRC Identifier. UDP (User Datagram Protocol) contains Source Port, Destination Port, and Length as static fields, with Checksum as an optional dynamic field. IP (Internet Protocol) has several static fields including Version, Header Length, Service Type, Total Length, and Identification, while its dynamic fields include Flags, Fragment Offset, Time to Live (TTL) , and Header Checksum. For PDCP (Packet Data Convergence Protocol) , Data Integrity Protection and Ciphering Information are static fields, while Sequence Number, PDCP Control PDU, and Header Compression Information are dynamic. RLC (Radio Link Control) contains fixed header fields as static elements and Sequence Number, Polling Bit, and Status Report as dynamic elements. Finally, MAC (Medium Access Control) includes Frame Control, Duration, and Address Fields as static fields, with Sequence Number and Frame Check Sequence as dynamic fields. Table 4: Example of size of static and dynamic fields of protocols headers used to encapsulate IMS  packet

[0121] Table 4 provides a detailed breakdown of the size specifications for various protocol headers used in IMS packet encapsulation. The table compares three different size metrics -default size, compressed size, and minimum compressed size (all measured in bits) -along with allocations for static and dynamic fields. For example, RTP headers start with a default size of 96 bits but can be compressed to 24 bits, with a minimum possible compression of 12 bits, distributed as 8 bits for static fields and 4 bits for dynamic fields. UDP headers, which begin at 64 bits, can be compressed to 12 bits with a minimum of 8 bits, allocating 6 bits to static fields and 2 bits to dynamic fields. IP headers show the largest default size at 160 bits, compressible to 48 bits with a minimum of 20 bits, using 14 bits for static and 6 bits for dynamic fields. PDCP headers range from 16-96 bits by default but can be compressed to 12 bits with a minimum of 4 bits, split between 2 bits each for static and dynamic fields. RLC and MAC headers show similar patterns of compression, with default sizes ranging from 16-48 bits and 8-48 bits respectively, both compressible to specific minimums while maintaining essential functionality through careful allocation between static and dynamic fields.

[0122] Several strategies exist for distributing the computed header among protocol stacks used for encapsulating IMS packets, taking into consideration all previously discussed factors.

[0123] The present disclosure provides two distinct strategies for header compression in IMS communications over narrowband GEO satellites: a Random Distribution Strategy and a Bitwise Optimization Strategy. These strategies address the challenge of compressing protocol headers while maintaining essential functionality within constrained bandwidth environments.

[0124] The Random Distribution Strategy implements a balanced approach to bit allocation across protocol layers. This strategy assigns the minimal necessary bits to each protocol to ensure basic functionalities can operate effectively. In an exemplary embodiment with a 20-bit compression target, the Random Distribution Strategy allocates: 6 bits to RTP for handling sequence numbers and timing information; 4 bits to UDP for maintaining checksums and port information; 2 bits to IP for addressing functions; 4 bits to PDCP for sequence numbers and encryption details; 2 bits to RLC for dynamic fields; and 2 bits to MAC for access control. This distribution ensures each protocol retains sufficient bits to maintain its essential operations while staying within the overall bit constraint.

[0125] In contrast, the Bitwise Optimization Strategy employs a more sophisticated approach based on protocol criticality and field interdependency. This strategy implements an optimized distribution pattern that considers the relative importance of different protocol functions and their dynamic requirements. In an exemplary embodiment targeting the same 20-bit compression, the Bitwise Optimization Strategy allocates: 4 bits to RTP optimized specifically for timing synchronization; 2 bits to UDP for minimal but sufficient port management; 4 bits to IP prioritizing routing functionality; 4 bits to PDCP emphasizing security operations; 2 bits to RLC maintaining reliable data transfer; and 4 bits to MAC optimizing access control functions. This distribution pattern reflects a deeper consideration of protocol interdependencies and operational priorities.

[0126] The key differentiation between these strategies lies in their underlying philosophies and implementation approaches. The Random Distribution Strategy offers simplicity and predictability, making it particularly suitable for implementations where consistent performance across all protocols is prioritized. Its balanced approach ensures that no single protocol layer suffers disproportionate degradation, though this may come at the cost of sub-optimal allocation for critical functions. Conversely, the Bitwise Optimization Strategy provides enhanced efficiency through its priority-based allocation, making it more suitable for scenarios where certain protocol functions carry greater importance than others. This strategy can better maintain critical service quality metrics but requires more complex implementation and management mechanisms.

[0127] Both strategies achieve significant header compression while maintaining protocol functionality. For example, in compressing a standard 416-bit header to 20 bits, the Random Distribution Strategy ensures basic functionality across all protocols through its balanced allocation, while the Bitwise Optimization Strategy maintains optimal performance for critical functions through its prioritized distribution. The choice between these strategies depends on specific implementation requirements, with the Random Distribution Strategy favoring simplicity and predictability, and the Bitwise Optimization Strategy prioritizing optimized performance for critical functions.

[0128] The strategies further differ in their adaptability to changing network conditions. The Random Distribution Strategy maintains a fixed distribution pattern, providing consistent performance but limited flexibility. The Bitwise Optimization Strategy can potentially adapt its bit allocation based on real-time protocol requirements, though this adds complexity to the implementation. This adaptability becomes particularly relevant in satellite communications where link conditions may vary significantly over time.

[0129] Implementation of either strategy requires careful consideration of the underlying protocol stack and service requirements. The Random Distribution Strategy can be implemented with relatively straightforward control mechanisms, making it suitable for systems where implementation complexity must be minimized. The Bitwise Optimization Strategy requires more sophisticated control mechanisms to manage its priority-based allocation but offers potentially better performance for critical services such as voice communications over GEO satellites.

[0130] The present disclosure provides four distinct approaches to achieve balanced bit allocation across protocol layers in header compression. In the quantitative approach, bits are allocated according to specific predetermined ratios, such as maintaining a 3: 2: 1: 2: 1: 1 ratio for RTP: UDP: IP: PDCP: RLC: MAC layers respectively when compressing to a 20-bit total constraint, resulting in 6 bits for RTP, 4 bits for UDP, 2 bits for IP, 4 bits for PDCP, 2 bits for RLC, and 2 bits for MAC. The functional approach ensures each protocol layer maintains minimum operational functionality by allocating bits based on essential operations-for example, allocating at least 4 bits to any layer requiring sequence numbering (such as RTP and PDCP) , 2 bits minimum to layers requiring basic state maintenance (such as RLC and MAC) , and remaining bits distributed based on additional functional requirements. The specific distribution approach implements a fixed pattern where each protocol receives a predetermined number of bits -for example, in a 20-bit constraint scenario, RTP always receives 6 bits for timing and sequence information, UDP receives 4 bits for port management, and remaining protocols receive fixed allocations optimized through testing and validation. The comparative approach maintains balance by limiting allocation differences between layers, such as enforcing a maximum 2-bit difference between any two protocol layers' allocations, ensuring that if RTP receives 6 bits, no other layer can receive fewer than 4 bits or more than 8 bits, thus preventing extreme disparities while allowing for necessary functional differences.

[0131] Each approach offers distinct advantages for different operational scenarios. The quantitative approach provides clear, mathematically verifiable balance but may be less adaptable to varying protocol requirements. The functional approach offers better adaptation to protocol needs but requires careful definition of minimum functional requirements. The specific distribution approach provides implementation simplicity and predictability but may lack flexibility for different network conditions. The comparative approach offers flexibility while preventing extreme imbalances but requires additional computational overhead to maintain allocation differences within prescribed limits. The selection of approach depends on specific implementation requirements, with considerations including processing capability, adaptability needs, and protocol criticality. a) Random Distribution Strategy

[0132] The first approach, called Random Distribution Strategy, allocates the minimal necessary bits to each protocol to ensure their basic functionalities can operate. Under this strategy, RTP, UDP, and IP protocols receive just enough bits to maintain essential timing, sequencing, addressing, and routing functions. Similarly, PDCP, RLC, and MAC protocols are given a balanced allocation of bits that allows them to maintain data integrity, encryption, reliable data transfer, and access control while all of the bits stay within the 20-bit limit. Table 5 shows the bit allocation to compressed header of the protocols. FIG. 7 shows an example of the random distribution strategy. Table 5: An example of a header plan for AMR codec for transmission over GEO with1 kbps data rate.

[0133] Table 5 presents an example header plan for AMR codec transmission over GEO satellite with a 1 kbps data rate, detailing how 20 total bits are allocated across different protocols. The plan assigns 6 bits to RTP (Real-time Transport Protocol) to adequately handle sequence numbers and timing information, ensuring minimal disruption to these essential fields. UDP (User Datagram Protocol) receives 4 bits to properly maintain its dynamic fields, particularly checksums and ports. IP (Internet Protocol) is allocated 2 bits, which is sufficient for managing addressing functions. PDCP (Packet Data Convergence Protocol) is given 4 bits to preserve both sequence numbers and encryption details. RLC (Radio Link Control) protocol receives 2 bits to keep its dynamic fields operational. Finally, MAC (Medium Access Control) protocol, which primarily handles access to the physical medium, is allocated 2 bits as this is sufficient for its core functionality. This distribution represents a careful balance between maintaining essential protocol functions while meeting the stringent bandwidth constraints of GEO satellite communication. b) Bitwise Optimization Strategy:

[0134] FIG. 8 shows an example of a bitwise header distribution for AMR codec transmission over 1 kbps GEO. This approach follows principles similar to the random distribution strategy, but focuses specifically on ensuring that each protocol's critical needs are efficiently met within the 20-bit constraint. The strategy allocates minimal bits to RTP, UDP, and IP protocols for their essential functions, while providing balanced bit allocations to PDCP, RLC, and MAC protocols to preserve their key operations. The detailed allocations and implementation of this approach are illustrated in Table 6 and FIG. 8. Table 6: An example of a bitwise header distribution for AMR codec transmission over 1 kbps GEO

[0135] Table 6 outlines a bitwise header distribution scheme for AMR codec transmission over 1 kbps GEO satellite, allocating a total of 20 bits across different protocols based on their operational priorities. RTP (Real-time Transport Protocol) receives 4 bits specifically for handling dynamic fields, particularly sequence numbers and timing information. UDP (User Datagram Protocol) is allocated 2 bits, a minimal allocation that suffices for its dynamic field requirements. IP (Internet Protocol) is given 4 bits to properly manage dynamic routing and addressing fields. PDCP (Packet Data Convergence Protocol) also receives 4 bits, which are necessary for handling its dynamic fields, especially sequence numbers. RLC (Radio Link Control) protocol is allocated 2 bits to manage reliable data transfer through its dynamic fields. MAC (Medium Access Control) protocol receives 4 bits, though its dynamic fields are noted as less critical to overall functionality. This distribution demonstrates a more sophisticated approach to bit allocation based on protocol criticality and operational requirements, differing from the random distribution strategy shown in Table 5.

[0136] Embodiment 4: Finding Optimal Codec Selection to Minimize Transcoding

[0137] This embodiment demonstrates a procedure for codec selection that aims to minimize transcoding impacts during inter-domain IMS calls between two parties. The process focuses on identifying and selecting pairs of codecs with similar bitrates to encode IMS session packets. When one party is accessing through GEO satellite and the other through non-GEO (NGEO) or terrestrial networks (TNs) , the procedure carefully evaluates codec combinations to find those with minimal bitrate differences while maintaining acceptable voice quality thresholds. The procedures are as given below

[0138] FIG. 9 shows the complete process for selecting codecs that are similar to each other for encoding IMS UP Session packets. The process maintains all the original steps: 1. Starting with the reported supported codecs and quality thresholds; 2. Creating a comprehensive list of supported and possible codecs; 3. Filtering codecs based on MOS ratings above the target threshold; and 4. Making final codec selections that achieve minimal bitrate differences while meeting quality  requirements.

[0139] The method for selecting codec pairs optimizes transcoding efficiency by carefully matching codecs with similar bitrates for IMS UP session packets. When the system (e.g., an IMS or CN node) detects either a non-GEO access type or determines that no viable header optimization plan exists to support the IMS codec bitrate within GEO satellite transmission constraints, the system initiates a codec selection process that minimizes transcoding impact through analysis of bitrate differences and Mean Opinion Score (MOS) ratings.

[0140] The selection process begins by analyzing the reported supported codecs along with their corresponding quality target thresholds. The system then compiles a comprehensive list of both the reported supported codecs and all potential compatible codecs, including AMR, AMR-WB, EVS, EVS Primary SID, EVS Special case, and AMR-WB SID, organizing them according to their respective bitrates and MOS ratings.

[0141] Next, the system applies a quality filter to identify codecs that meet or exceed the target reported quality threshold based on MOS ratings. The final selection phase involves identifying optimal codec pairs by matching the filtered codecs with at least one of the reported supported codecs. These pairs must satisfy two key criteria: achieving the desired quality threshold or MOS rating while maintaining minimal bitrate differences between the paired codecs.

[0142] The system identifies suitable codecs for GEO satellite low bit rate communications by focusing on specific codecs, such as three specific codecs detailed at the end of Table 7: AMR-WB SID (Adaptive Multi-Rate Wideband Silence Insertion Descriptor) , EVS (Enhanced Voice Services) Special Case, and EVS Primary. When a UE accessing via GEO satellite selects one of these codecs for the first end of an IMS voice call, the system then chooses the lowest bit rate version of either Adaptive Multi-Rate, EVS, or AMR-WB from the beginning of Table 7 for the second UE that is accessing via NGEO satellite or terrestrial network. This pairing approach minimizes transcoding impact.

[0143] For example, when EVS Primary SID operating at 2.4 kbps with an MOS of 3.5 -4.0 is reported and the system targets a quality threshold of 4.0, the node can select AMR-WB operating at 6.6 kbps (with MOS 4.0 -4.5) because their bitrates are relatively close and both maintain high MOS ratings. Another viable option would be pairing the EVS Primary SID at 2.4 kbps with EVS at 5.9 kbps (MOS 4.5 -5.0) to meet the same quality threshold. These careful codec pairings achieve an optimal balance between bitrate efficiency and voice quality while keeping transcoding impact to a minimum. Table 7: An Example of a comprehensive overview of existing codecs that are compatible with  narrowband GEO satellite communications

[0144] Table 7 provides a comprehensive overview of codecs compatible with narrowband GEO satellite communications, detailing their specifications and quality ratings. The table includes six codec types: AMR operates at 4.75-12.2 kbps with a frame size ranging from bits at 4.475 kbps to 244 bits at 12.2 kbps, achieving a MOS rating of 3.0-3.5. AMR-WB functions at 6.6-23.85 kbps with frame sizes from 132 bits at 6.6 kbps to 477 bits at 23.85 kbps, reaching a higher MOS rating of 4.0-4.5. EVS operates across a wide range of 5.9-128 kbps with frame sizes from 118 bits to 2560 bits, achieving the highest MOS rating of 4.5-5.0. EVS Primary SID operates at 2.4 kbps with a 48-bit frame size and MOS rating of 3.5-4.0. EVS Special case runs at 2.8 kbps using 56-bit frames with a MOS rating of 3.0-3.5. Finally, AMR-WB SID operates at the lowest bit rate of 1.75 kbps with 40-bit frames, maintaining a MOS rating of 3.5-4.0. All codecs share a common frame length of 20 milliseconds.

[0145] AMR (Adaptive Multi-Rate) is a standard speech codec optimized for encoding speech signals in cellular systems.

[0146] AMR-WB (Adaptive Multi-Rate Wideband) is an extended version of AMR that provides enhanced speech quality through wideband audio coding.

[0147] EVS (Enhanced Voice Services) is a superior speech and audio codec that offers high-quality communication across a wide range of network conditions.

[0148] EVS Primary SID (Silence Insertion Descriptor) is a specialized mode of EVS designed to efficiently encode silence or background noise periods.

[0149] EVS Special Case refers to specific operating modes of the EVS codec optimized for particular network conditions or requirements.

[0150] AMR-WB SID (Silence Insertion Descriptor) is a feature of AMR-WB that handles the encoding of silence periods in wideband audio transmission.

[0151] Embodiment 5: Signaling to Address Delay and Call Setup Issue

[0152] One or more embodiment addresses delay and call setup challenges in scenarios where IMS messages transmitted over GEO satellite exceed ITU's recommended budget for call setup time, propagation &processing delay. This embodiment introduces signaling procedures designed to optimize IMS signaling and overall message size while ensuring total IMS call setup time remains under 20 seconds and maintaining propagation &processing delay within ITU-recommended limits for GEO satellite transmission.

[0153] FIG. 10 illustrates a method to address delay and call setup time, showing signaling exchange between UE1 (called party) , UE2 (calling party) , and intermediate nodes including RAN / CORE and IMS nodes. The method includes: 1. Exchange of RRC / NAS signaling containing one or more of: ■ Access type (GEO, LEO, MEO) ; ■ Data rate; ■ RTT (round trip time) ; and / or ■ Time stamp to calculate RTT. 2. Exchange of IMS signaling with the same information parameters; 3. Indication to inform UE that reduced signaling IMS needs to be enabled for this call; 4. IMS registration and IMS signaling session establishment; 5. Decision making regarding IMS signaling reduction based on RRC / NAS or IMS signaling; 6. Performance of the remaining IMS call based on the decided reduced signaling parameters.

[0154] FIG. 10 demonstrates the complete flow of signaling and decision-making process to optimize delay and call setup time in IMS communications.

[0155] The solution involves exchanging signaling information between UE, IMS system, 5G Core (5GC) components like Access and Mobility Management Function / Session Management Function (AMF / SMF) , and gNB, as detailed in Embodiments 8. This exchange helps these network nodes determine the optimal size for IMS signaling data and messages to maintain performance within ITU budget constraints. These signaling exchanges occur across Radio Access Network (RAN) , 5GC, and IMS systems as illustrated in Embodiment 7.

[0156] The signaling protocol includes several critical indicators. First, it uses an access type indicator that specifies the satellite type (GEO, MEO, or LEO) , which helps determine whether optimization is necessary. For instance, when GEO access is indicated, the node initiates optimization procedures; otherwise, it follows standard signaling protocols. Second, it includes an indicator of the achievable transmission data rate for the specific GEO satellite, which is essential for calculating the signaling optimization plan as described in Embodiment 5. Finally, it incorporates either a timestamp within the IMS call setup SIP message or direct measurement of one-way propagation delay. This delay information, whether measured during IMS registration or PDU session establishment / modification, works in conjunction with the transmission rate data to determine the optimal signaling plan according to Embodiment 5.

[0157] Based on the analyzed indicators, network nodes including Radio Access Network (RAN) , 5G Core (5GC) components such as Access and Mobility Management Function (AMF) and Session Management Function (SMF) , and / or IMS nodes follow a decision-making process. When these nodes detect either GEO satellite access or determine that delay and call setup time exceed ITU recommended budgets, these nodes initiate two key actions: 1 First, they develop an optimal signaling reduction plan for inter-node IMS call messages that maintains  both call setup time and total propagation and processing delay of IMS voice packets over GEO satellite within ITU-recommended limits, as detailed in Embodiment 6. 2 Second, they communicate this detailed signaling reduction plan to lower layer nodes to ensure IMS  voice call quality remains within ITU recommendations while managing both call setup time and propagation / processing delay, as outlined in Embodiment 8.

[0158] However, if the system detects non-GEO access or determines that delay and call setup time fall within ITU recommended budgets, the node proceeds with the IMS call using standard default signaling procedures without implementing any optimization measures.

[0159] FIG. 11 illustrates the original full IMS signaling process with standard call setup time and reduced signaling with optimized call setup time. The reduced signaling procedure shows the progressive reduction in signaling exchange between UE and IMS (IP Multimedia Subsystem) , demonstrating the optimization of delay and call setup time through reduced signaling procedures.

[0160] Embodiment 6: Finding Optimal Signaling Reduction to Ensures Delay Budget

[0161] Embodiment 6 describes a systematic procedure for developing an optimal signaling reduction plan that minimizes unnecessary message exchanges between IMS calling parties while maintaining delay and call setup times within ITU budget requirements. This process begins by gathering or defining essential parameters either from the UE or other network nodes: ● Satellite Transmission Rate (R) , ● Maximum Total Delay (T) , and ● Maximum Propagation &Processing Delay (P) .

[0162] Using these parameters, the system first calculates the Maximum Allowable Message Transmission Delay (M) by subtracting the Maximum Propagation &Processing Delay from the Maximum Total Delay: M = T –P               (2) where M is Maximum Allowable Message Transmission Delay, T is Maximum Total Delay, and P is Maximum  Propagation &Processing Delay. The system then determines the allowable IMS signaling message size in bits needed for completing the IMS call setup by multiplying the Maximum Allowable Message Transmission Delay by the Satellite Transmission Rate: Message Size in bits = M × R              (3) where R is Satellite Transmission Rate. This value is then converted to bytes: Message Size (bytes) = Message Size (bits) ÷ 8          (4) This calculated IMS signaling message size represents the maximum allowable data that can be  transmitted while meeting the system's delay constraints.

[0163] To determine the necessary reduction in signaling, the system calculates the signaling difference in bytes by subtracting the calculated IMS signaling message size (based on satellite transmission rate R) from the default IMS message size, as shown in Table 8. This calculation yields the amount of signaling that needs to be eliminated: Signaling difference = (Default IMS Message Size -IMS signaling Message Size@R) bytes.    (5)

[0164] The resulting signaling difference value guides the system in determining how many messages can be eliminated from the default IMS call setup signaling sequence while still maintaining required call setup time and one-way delay budget constraints. The complete procedure for determining optimal signaling reduction is illustrated in FIG. 12.

[0165] FIG. 12 provides a complete process for optimizing signaling reduction to minimize delay and call setup time, maintaining all the original steps: 1. Initial parameter definition / reception (Access type, T, R, P) ; 2. Maximum allowable delay calculation (M = T -P) ; 3. Message size calculation using satellite transmission rate and conversion to bytes; 4. Determination of signaling difference and reduction amount by comparing calculated size against  default IMS message size.

[0166] The procedure provides a systematic approach to determine the optimal amount of signaling reduction needed while maintaining system functionality.

[0167] Embodiment 7. Detailed Signaling Reduction Proposal to Ensures Delay Budget

[0168] Embodiment 7 provides a detailed example of IMS signaling message optimization for a narrowband GEO satellite operating at a transmission rate of 1 kbps. The system parameters in this example specify a maximum total call setup delay of 20 seconds and a propagation &processing delay of 4ms per message.

[0169] In the example, by implementing the procedures outlined in Embodiments 5 and 6, the analysis determines that the optimal IMS signaling message size should be approximately 2000 bytes to maintain delay and call setup times within budget constraints. Since the default IMS signaling requires 2550 bytes, the system must reduce the total signaling size by 550 bytes (2550 -2000 = 550 bytes) .

[0170] This reduction can be accomplished by eliminating at least two signaling steps from the default IMS call setup sequence, with each step accounting for approximately 300 bytes. The system then notifies the UE to bypass these eliminated signaling steps during IMS setup. FIG. 13 illustrates this optimized signaling reduction approach.

[0171] FIG. 13 shows three scenarios for IMS signaling with AMR codec over GEO satellite with 1 kbps data rate: 1. FIG. 13 (a) shows full signaling (2550 bytes total) : ■ Complete sequence of 10 SIP messages ■ Individual message sizes ranging from 200-300 bytes 2. FIG. 13 (b) shows reduced signaling (2000 bytes total) : ■ Optimized sequence with 7 SIP messages ■ Maintains essential signaling while reducing overall size 3. FIG. 13 (c) shows further reduced signaling (2550-800 bytes) : ■ Additional optimization of message sequence ■ Preserves core functionality with minimal signaling overhead

[0172] Each scenario demonstrates progressive optimization of the signaling process while maintaining necessary communication between UE and IMS nodes.

[0173] When determining which specific messages to remove from the default IMS call setup signaling sequence to meet call setup time and one-way delay budget requirements, the system follows a three-step evaluation process. 1 First, the system identifies combinations of signaling messages whose total size in bytes matches the  calculated signaling difference, ensuring precise adherence to the required reduction target. 2 Second, the system prioritizes the elimination of less critical messages that can be removed without  compromising the core call setup procedure. According to Table 8, certain messages such as SIP TRYING, SIP PRACK, and SIP UPDATE, along with their corresponding responses, can be safely omitted without disrupting the overall call setup process. 3 Third, the system preserves essential communication by consolidating important information elements  (IEs) and headers from eliminated messages into the remaining critical messages. This ensures that all necessary information continues to reach the calling and called UE despite the reduced signaling overhead. Table 8: The IMS voice call setup and steps based on whether they can be eliminated or not

[0174] Table 8 provides a detailed breakdown of IMS voice call setup steps and their eligibility for omission in the signaling process. The table outlines ten critical steps, each with a "Can be Omitted" status and corresponding rationale. Essential messages that cannot be omitted include SIP INVITE (initiates call setup) , SIP 183 (indicates call progress) , SIP 180 Ringing (indicates recipient alert) , SIP 200 OK (INVITE) (confirms call answer) , and SIP ACK (completes handshake) . Conversely, messages that can be safely omitted include SIP TRYING (simple acknowledgment of INVITE receipt) , SIP PRACK (ensures reliability for provisional responses) , SIP 200 OK PRACK (acknowledges PRACK) , SIP UPDATE (modifies session description) , and SIP 200 OKUPDATE (acknowledges UPDATE) . The rationale for omission typically relates to the message's non-critical nature in stable network conditions or redundancy with other signals, while messages marked as non-omissible are fundamental to establishing and maintaining the call connection.

[0175] The example outlines three feasible solutions for optimizing IMS signaling in a narrowband GEO satellite system operating at 1kbps transmission rate, where the target signaling size after reduction is approximately 2000 bytes.

[0176] The first detailed solution involves eliminating PRACK and SIP PRACK 200 OK signaling steps, which typically handle QoS and codec matching information between calling and called UEs. To maintain this essential information flow, the system redistributes these communications across the SIP 183 Session Progress, SIP UPDATE, and SIP 200 OK UPDATE messages. This ensures the call setup process remains robust and complete while maintaining effective QoS communication between parties.

[0177] The detailed changes in the call setup procedures are based on the procedures provided below. Examples are provided in Table 9and FIG. 14: 1. The calling UE sends a SIP INVITE message to the called UE to initiate the call. This message  includes basic session parameters, such as the desired codecs and media types, signaling the start of the call setup process. 2. Upon receiving the SIP INVITE, the CN responds with a SIP TRYING message to indicate that  the call processing has started. This message confirms receipt of the INVITE and reassures the calling UE that the setup process is underway. 3. The called UE sends a SIP 183 Session Progress message as a provisional response. This  message includes QoS and selected codec matching status information of the called UE. This information allows calling UE to adjust call or resource parameters to meet QoS for codec selected by calling UE. The calling UE can adjust its settings based on the information received. 4. The calling UE acknowledges the provisional response by sending a SIP UPDATE message. This  ensures reliable delivery and agreement on the provisional parameters and confirms that calling UE is aligned with the initial QoS and codec settings provided in the SIP 183 Session Progress message. 5. The called UE responds with a SIP 200 OK UPDATE message, confirming acknowledgment of  the provisional response. This message assures that the called UE has accepted and agreed to the QoS parameters and codec settings, allowing both UEs to proceed with resource allocation and PDU session establishment for voice data based on accepted QoS parameters and codec settings. 6. The called UE sends a SIP 180 Ringing message, indicating that the call is being processed and  the called party is being alerted. 7. The called UE sends a SIP 200 OK (INVITE) message to finalize the session parameters,  including the agreed-upon QoS settings and codec selection. This message confirms that both UEs have accepted the session parameters, allowing the call setup to proceed to the next stage. 8. Finally, the calling UE sends a SIP ACK message to acknowledge the final session parameters.  This message confirms the agreement between both parties on the session settings, marking the completion of the call setup process and establishing a stable communication channel.

[0178] Eliminating these signaling messages achieves around 1, 950 bytes of signaling reduction, which is already below the required 2,000 bytes. Further optimization of the remaining essential messages can be achieved by: 1 Reducing non-essential headers (User-Agent, Allow and Supported) ; and 2 Combining the QoS-related header lines (which are necessary for QoS and codec matching  communication between caller UE and called UE in SIP PRACK) into SIP INVITE, SIP 183 Session Progress and SIP 200 INVITE OK messages.

[0179] These optimizations can reduce the overall message size to 1, 724 bytes. Since a 2,000-byte reduction is sufficient to optimize the IMS signaling and bring the delay and call setup time below the required budget, this creates a 276-byte gap. This gap could be used to carry new signaling indications such as: ● Access type (GEO, MEO, LEO) ● GEO satellite data rate ● One-way propagation delay

[0180] These indications could be included if SIP signaling messages, such as SIP INVITE, are used for transmission (Embodiment 5) . Table 9: Changes in steps after eliminating SIP PRACK and its feedback from defaults IMS signaling

[0181] Table 9 details the changes made to IMS signaling steps after eliminating SIP PRACK and its feedback from default IMS signaling. The table compares the original message sizes with optimized sizes and explains specific modifications for each step. While SIP INVITE remains unchanged at 200 bytes, other messages see significant size reductions through header optimization. For example, SIP TRYING is reduced from 200 to 120 bytes by removing non-essential headers like User-Agent, Supported, and Allow. SIP 183 Session Progress is modified to 258 bytes by adding a QoS status header while removing Allow and Supported headers. SIP UPDATE and SIP 200 OK UPDATE are increased to 356 and 328 bytes respectively to accommodate additional QoS headers. SIP 180 Ringing is reduced to 130 bytes, and SIP ACK is similarly optimized to 130 bytes, both through removal of non-essential headers. These modifications result in a total reduction from 1, 950 bytes to 1, 724 bytes, demonstrating significant optimization while maintaining essential functionality.

[0182] In another solution example, the SIP UPDATE and SIP 200 OK UPDATE steps are eliminated. These messages are only used to confirm QoS requirements are met at both ends and to modify session descriptions if changes occur after the initial INVITE. While these messages are omitted, to ensure proper call setup, the QoS confirmation information is instead communicated via the SIP 180 Ringing message and its acknowledgment SIP 200 OK (as shown in FIG. 15, Table 10) . Additionally, if session modifications are needed after the initial INVITE, the session modifications can be conveyed through the SDP Offer / Answer Model in either: ● SIP INVITE / SIP ACK messages, or ● SIP 180 Ringing / SIP 200 OK messages

[0183] These messages are explained in the following: 1. Offer: The calling UE sends an SDP offer in the SIP 180 Ringing message, detailing the desired  session parameters, such as codecs, media types, and other attributes. 2. Answer: The called UE responds with an SDP answer in the SIP 200 OK (INVITE) message, either  accepting the proposed parameters or suggesting modifications. 3. ACK: The calling UE acknowledges the SIP 200 OK response with an ACK message, confirming the  agreed-changed session parameters.

[0184] The detailed changes in the call setup procedures based on this approach are as provided below: 1. The calling UE sends a SIP INVITE message to initiate the call. This message includes basic  session parameters, such as the desired codecs and media types, to the called UE, signalling the start of the call setup process. 2. Upon receiving the INVITE, the IMS (CN) sends a SIP TRYING message to indicate that the call  processing has started, confirming the receipt of the INVITE and assuring the calling UE that the setup process is ongoing. 3. The called UE sends a SIP 183 Session Progress message via the IMS system to the calling UE.  This message provides early media information, such as a list of supported codecs (excluding unsupported) . 4. The calling UE sends a SIP PRACK message to acknowledge the receipt of the SIP 183 Session  Progress message. This PRACK message indicate whether the QoS requirements for the selected codec (e.g., AMR) are met at the calling side (i.e., the calling UE) . 5. The called UE sends a SIP 200 OK PRACK message to confirm receipt of the PRACK and provide  an update on the QoS status at the called side. This message indicates whether the QoS requirements for the session have been met for the called UE. 6. The called UE sends a SIP 180 Ringing message, indicating that the call is being processed and  indicating the session parameters change status (if any) and confirming that QoS parameters and codec settings are accepted by the called UE to proceed with resource allocation and PDU session establishment or modification for voice data based on accepted QoS parameters and codec settings. 7. The calling UE sends a SIP ACK message to acknowledge the ringing and confirm that QoS  parameters and codec settings are accepted by the calling UE. After this step, the called UE proceeds with resource allocation and PDU session establishment modification based on accepted or updated QoS parameters setting and parameters of the session. 8. Finally, the called UE sends a SIP 200 OK (INVITE) message to finalize the call initiation. This  message confirms that both UEs can proceed with the call at the next stage.

[0185] Eliminating SIP UPDATE and SIP 200 OK UPDATE steps achieves around 1, 950 bytes of signaling reduction. Further optimization of the remaining messages (SIP TRYING, SIP 180 Ringing, SIP ACK) through reducing non-essential headers (User-Agent, Allow and Supported) can successfully reduce the overall message size to 1, 886 bytes. This creates a gap of around 114 bytes which could be used for carrying new signaling indications, such as: ● Access type (GEO, MEO, and LEO) ; ● GEO satellite data rate; and / or ● One-way propagation delay.

[0186] These indications could be transmitted if SIP signaling messages, such as SIP INVITE, are used (Embodiment 5) . This approach ensures all essential information is maintained for a robust, complete, and efficient call setup process while effectively conveying QoS information. Table 10: Changes in steps after eliminating SIP UPDATE and its feedback from defaults IMS signaling

[0187] Table 10 outlines the changes in IMS signaling steps after eliminating SIP UPDATE and its feedback messages from default IMS signaling. The table shows the size changes and specific modifications for each message type. While SIP INVITE maintains its original 200 bytes, SIP TRYING is reduced from 200 to 120 bytes by removing non-essential headers. SIP 183 Session Progress, SIP PRACK, and SIP 200 OK PRACK remain unchanged at 300 bytes each. SIP 180 Ringing is modified from 250 to 236 bytes by removing non-essential headers like Allow and Supported while adding a QoS confirmation header. SIP 200 OK (INVITE) increases from 200 to 228 bytes with the addition of a QoS confirmation header. SIP ACK is reduced from 200 to 130 bytes through the removal of non-essential headers. These optimizations result in a total reduction from 1, 950 bytes to 1, 886 bytes, creating 114 bytes of space that could be used for new signaling indications such as access type, data rate, and propagation delay information.

[0188] Reduced IMS Signaling for GEO with 1 kbps Data Rate:

[0189] In another solution example, the optimization focuses only on eliminating non-essential headers and information elements (such as User-Agent, Allow, and Supported headers) from each SIP step after the initial one. This approach: ● Preserves all steps in the call setup process ● Focuses on message optimization by removing unnecessary headers ● Maintains all essential information (Table 11)

[0190] By carefully eliminating these non-essential headers and information elements from each SIP message, the overall message size can be reduced to 2,000 bytes without removing any steps. This ensures: ● A complete call setup process ● Maintained reliability ● Required QoS and codec matching between calling and called UEs Table 11: Changes in steps eliminating only non-essential header and keeping default IMS signaling

[0191] Table 11 presents a comprehensive overview of changes made to IMS signaling steps by eliminating only non-essential headers while maintaining the default IMS signaling structure. The table details the default message size, optimized size, and specific changes for each step, along with the total bytes removed. While SIP INVITE remains unchanged at 200 bytes, other messages see significant size reductions. For instance, SIP TRYING is reduced from 200 to 160 bytes by removing User-Agent and Supported headers. SIP 183 Session Progress sees an 80-byte reduction from 300 to 220 bytes by removing User-Agent, Allow, and Supported headers. Similar optimizations are applied to subsequent messages: SIP PRACK and SIP 200 OK PRACK are each reduced by 60 bytes, SIP UPDATE and SIP 200 OK UPDATE by 80 bytes each, SIP 180 Ringing by 80 bytes, SIP 200 OK (INVITE) by 30 bytes, and SIP ACK by 40 bytes. These careful optimizations result in a total reduction from 2, 550 bytes to 2,000 bytes, achieving a 550-byte reduction while preserving the complete call setup process and maintaining essential functionality.

[0192] Embodiment 8: Scenarios and Implementation in 3GPP IMS Systems

[0193] This embodiment examines a scenario involving two IMS voice call parties, where:

[0194] The first UE accesses via narrowband GEO satellite, while the second UE accesses through one of: ● Terrestrial wireless access ● NGEO satellite access ● Another narrowband GEO satellite access

[0195] The narrowband GEO satellite used for the first UE's access can be one of: ● S-band GEO satellite ● L-band GEO satellite ● UHF-band GEO satellite

[0196] FIG. 16 illustrates one scenario of the environment setting.

[0197] The complete solution for enabling effective IMS call over narrowband GEO signalling enhances the 5G IMS system by addressing three key aspects: ● Data rate optimization; ● Latency reduction; and / or ● Transcoding impact mitigation.

[0198] The solution leverages enhancements proposed in Embodiments 1-7, including: ● New signaling indicators; ● New codec selection methods; ● Protocol overhead / header reduction techniques; and / or ● Latency reduction procedures.

[0199] Signaling information is exchanged between nodes including UE, RAN node, 5GC (AMF, SMF, UPF) and / or IMS system to enable: ● Optimal header reduction plan (as illustrated Embodiment 1)  ● Selection of codecs with minimal bitrate differences (as illustrated Embodiment 1)  ● Optimal signaling reduction (as illustrated Embodiment 5)

[0200] Enabling signalling:

[0201] FIG. 17 illustrates signallings between nodes for the disclosed method. These signals are exchanged through the following channels: 1 Radio Resource Control Signaling: ■ Between UE and NG-RAN ■ RAN-assisted codec adaptation (e.g., step 2a / 2b) ■ RRC connection establishment / resumption for IMS / registration voice call (e.g., step 1a / 1b / 2a / 2b) ■ UE Capability Inquiry and Information signaling (e.g., step 2a / 2b) ■ RAN-assisted codec adaptation 2 Non-Access Stratum (NAS) Signaling: ■ Between UE and 5GC (AMF) ■ UE registration signaling (IMS registration request / accept) (e.g., step 1a / 1b) ■ IMS voice session signaling (PDU session establishment / modification) (e.g., step 3a / 3b) ■ IMS Voice Data PDU session context activation (PDU session establishment / modification) (e.g.,  step 1a / 1b, 5a / 5b) 3 IMS Protocol Signaling: ■ Session Description Protocol (SDP) transactions between UE and IMS ■ IMS Call Setup Signaling (e.g., step 4a / ab) ■ IMS Codec Negotiation Signaling (e.g., step 4a / 4b) 4 Network Signaling: ■ NG application protocol signaling (between gNB and AMF / SMF) ■ NG: PDU session Resource Setup or Modification (e.g., step 4a / 4b) ■ NG: UE Radio Capability Check Request / Response (e.g., step 1a / 1b) ■ Namf_Communication: response between AMF and SMF or IMS ■ N1N2 Message Transfer request / response (e.g., step 4a / 4b)

[0202] Feedback signaling:

[0203] Feedback signaling for reduced headers and proper IMS protocol synchronization between nodes is exchanged through the following channels: 1 IMS Protocol Signaling: ■ Session Description Protocol (SDP) transactions between UE and IMS ■ Call Setup Signaling (e.g., step 4a / 4b) ■ Codec Negotiation Signaling (e.g., step 4a / 4b) 2 Non-Access Stratum (NAS) Signaling: ■ Between UE and 5GC (AMF) ■ UE registration signaling (IMS registration request / accept) (e.g., step 1a / 1b) ■ IMS voice session signaling (PDU session establishment / modification) (e.g., step 3a / 3b) ■ IMS Voice Data PDU session context activation (PDU session establishment / modification) (e.g.,  step 5a / 5b) 3 Radio Resource Control Signaling: ■ Between UE and NG-RAN ■ RAN-assisted codec adaptation (e.g., step 2a / 2b) ■ RRC connection establishment / resumption for IMS / registration voice call (e.g., step 1a / 1b / 2a / 2b) ■ UE Capability Inquiry and Information signaling between (e.g., step 2a / 2b) ■ RAN-assisted codec adaptation (e.g., step 2a / 2b)

[0204] FIG. 18 and FIG. 19 provide two examples of complete signaling procedures discussed in Embodiments 1 and 5. FIG. 18 illustrates a complete procedure where IMS makes decisions regarding header compression, codec selection, and / or signaling reduction. With reference to FIG. 18, the IMS call procedure is modified from default as follows: A. The calling party actions: 1 Detects a robust 5G NR cell and register with 5G gNB / 5GC and IMS system, if not yet registered. 2 Enters to connected RRC mode if it’s already registered, 3 Establishes a default PDU session with 5GC for IMS call (e.g., VoLTE / VoNR) signalling messages  and an internet session with IMS for SIP protocol messages. 4 Setups a Voice (e.g., VoLTE / VoNR) MO or MT call and / or perform voice codecs negotiation process  using SIP protocol messages. During this step, the calling UE may indicate via SIP signalling (e.g., SIP INVITE ) one or more of the following: ■ Access type; ■ Achievable transmission data rate for the GEO Satellite; ■ Required codec quality selection factor; and ■ One-way delay for messages from satellite to IMS. B. The IMS system actions: 5 Decides the header compression, codec selection, and / or signalling reduction plan based on the  indicated information as illustrated in Embodiment 1 and 5. 6 Indicates the new header compression, codec selection, and / or signalling reduction plan to be used  for this IMS call to lower layer e.g.: ■ To an AMF / SMF via Namf / SMF_communiction (N1N2 Message) ; ■ To gNB via Namf / SMF_communiction (N1N2 Message) and PDU session Modification; ■ Directly to calling / called UE via N1 (NAS) siganlling or via NGAP and RRC signalling. Then, UE and gNB / AMF / SMF encapsulate the IMS voice using the indicated header compression  and / or performs IMS call using the signalling reduction plan. C. The called UE / party actions: 7 The calling performs steps 1 to 3. 8 Sets up a Voice (e.g., VoLTE / VoNR) MO or MT call and / or perform voice codecs negotiation process  using SIP protocol messages based on the decided the header compression, codec selection, and / or signalling reduction plan as provided by IMS. D. Combined calling and called UE actions: 9 Perform Context Activation for IMS voice data PDU session to set up a dedicated PDU session for  voice data with QoS for selected codecs and header encapsulation as indicated by IMS. 10 Establish voice (e.g., VoLTE / VoNR) MO or MT conversation over the dedicated PDU session. FIG. 19 illustrates a complete procedure where the IMS makes the decision of the header compression,  codec selection and / or signaling reduction. The IMS call procedure is modified from default as follows: A. The calling party UE actions: 1. Detects a robust 5G NR cell and register with 5G gNB / 5GC and IMS system, if not yet registered. 2. Enters to connected RRC mode if already registered, 3. Establish a default PDU session with 5GC for IMS call (e.g., VoLTE / VoNR) signalling messages  and an internet session with IMS for SIP protocol messages. 4. Sets up a Voice (e.g., VoLTE / VoNR) MO or MT call and / or perform voice codecs negotiation  process using SIP protocol messages. During this step, the calling UE may indicate via SIP signalling (e.g., SIP INVITE ) one or more of: a. Access type, b. Achievable transmission data rate for the given GEO Satellite, c. Required codec quality selection factor, and / or d. One-way delay for a message from satellite to IMS. 5. The IMS may transmit signals or messages to decide the header compression, codec selection,  and / or signalling reduction plan based on the information indicated by the UE: a. to the SMF via Nsmf_communiction (i.e., N1N2 Message) ; b. to the AMF via Namf_communiction and Nsmf_communiction (i.e., N1N2 Message) ; or c. to the gNB via Namf_communiction and Nsmf_communiction (i.e., N1N2 Message) and  NGAP PDU session Modification signalling. B. The AMF / SMF / gNB actions: 6. Determines based on one or more instances of the indicated information received from IMS: a. the header compression, b. codec selection, and / or c. signalling reduction plan. 7. Indicate to UE and upper layer node the new header compression, codec selection, and / or  signalling reduction plan to be used for this IMS call through different paths depending on originating component: a. The gNB indicates the new header compression, codec selection, and / or signalling  reduction plan to be used for this IMS call: i. to the AMF via NGAP PDU session Modification signalling, and ii. to the SMF via NGAP and Namf_communiction (i.e., N1N2 Message) , and iii. to the IMS via NGAP PDU session Modification, Namf_communiction and  Nsmf_communiction (i.e., N1N2 Message) , iv. to the calling UE via RRC siganlling and v. to the called UE a combination of NGAP PDU session Modification,  Namf_communiction, and Nsmf_communiction (N1N2 Message) or SIP signaling. b. The AMF indicates the new header compression, codec selection, and / or signalling  reduction plan to be used for this IMS call: i. to SMF Namf_communiction (N1N2 Message) , and ii. to IMS via Namf_communiction and Nsmf_communiction (N1N2 Message) , and iii. to the calling UE via NAS signalling, and iv. to the called UE via Namf_communiction and Nsmf_communiction (N1N2  Message) and NAS signalling. c. The SMF indicates the new header compression, codecselection, and / or signalling  reduction plan to be used for this IMS call: i. to IMS via Namf_communiction and Nsmf_communiction (N1N2 Message) , ii. to the calling UE via NAS signalling, and iii. to the called UE via Namf_communiction and Nsmf_communiction (N1N2  Message) and NAS signalling. Alternatively, the gNB / AMF / SMF may receive the indication of access type, achievable transmission  data rate for the given GEO Satellite, a required codec quality selection factor and / or an one-way delay for a message (e.g., one-way delay from satellite to the IMS) directly from UE via RRC or NAS during IMS registration or IMS signalling PDU session establishment as specified in steps 1 to 3. Then, the gNB / AMF / SMF may encapsulate the IMS voice using the decided header compression or performs IMS call using the decided reduced signalling. 8. The AMF / SMF / gNB may indicate the decided new header compression, codec selection, and  signalling reduction plan to UE or to IMS to use it for encapsulation purposes as shown in step 7a and b. C. The called UE or party: 9. The calling UE / calling party performs steps 1 to 3. 10. The calling UE / calling party sets up a Voice (e.g., VoLTE / VoNR) MO or MT call and performs  voice codecs negotiation process using SIP protocol messages based on the decided the header compression, codec selection, and / or signalling reduction plan as provided by gNB / AMF / SMF. D. The calling and called UE: 11. Perform Context Activation for IMS voice data PDU session to set up a dedicated PDU session  for voice data with QoS for the decided header compression, codec selection, and / or signalling reduction plan as indicated by gNB / AMF / SMF. 12. Establish voice (e.g., VoLTE / VoNR) MO or MT conversation over the dedicated PDU session.

[0205] With reference to FIG. 20, a UE 100 may include a processor 11b, a memory 12b, and a transceiver 13b. The processor 11b is configured tocall and run a computer program stored in the memory 12b, to cause UE 100 in which the processor 11b is installed to execute the disclosed method, steps, and / or functions of a UE. The UE 100 is an example of the UEs (e.g., UE1 and UE2) . The transceiver 13b may include baseband circuitry and radio frequency (RF) circuitry.

[0206] With reference to FIG. 21, the network node 20 is a network device and may include a processor 21a, a memory 22a, and a transceiver 23a. The processor 21a is configured to call and run a computer program stored in the memory 22a, to cause network node 20 in which the processor 21a is installed to execute the method, steps, and / or functions of a network node. The network node 20 is an example of the IMS node, NG-RAN, gNB, on-board gNB, UPF, AMF, and SMF, PCF. The transceiver 23a may include baseband circuitry and radio frequency (RF) circuitry.

[0207] With reference to FIG. 22, the embodiment of the disclosure also provides a chip 700 that may correspond to a user equipment, such as UE1 or UE2, in the embodiments of the disclosure. The chip 700 may implement a corresponding process realized by the user equipment in various methods of the embodiments of the disclosure. The chip 700 includes a processor 701, and the processor 701 may call and run a computer program from memory to implement the methods in the embodiments of the present application.

[0208] Optionally, the chip 700 may also include a memory 702. In particular, the processor 701 may call and run the computer program from the memory 702 to implement the methods in the embodiments of the present application.

[0209] Moreover, the memory 702 may be a separate device from the processor 701 or may be integrated into the processor 701.

[0210] Optionally, the chip 700 may further include an input interface 703. Note that the processor 701 may control the input interface 703 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0211] Optionally, the chip 700 may further include an output interface 704. Note that the processor 701 may control the output interface 704 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0212] With reference to FIG. 23, the embodiment of the disclosure also provides another chip 800 that may correspond to a network node in the embodiment of the disclosure, and the chip 800 may implement the corresponding processes implemented by the network node in the various methods of the embodiments of the disclosure. The chip 800 includes a processor 801, and the processor 801 may call and run a computer program from the memory 802 to implement the methods in the embodiments of the present application.

[0213] Optionally, the chip 800 may further include a memory 802. In particular, the processor 801 may call and run the computer program from the memory 802 to implement the methods in the embodiments of the present application.

[0214] Wherein the memory 802 may be a separate device from the processor 801 or may be integrated into the processor 801.

[0215] Optionally, the chip 800 may also include an input interface 803. In particular, the processor 801 may control the input interface 803 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0216] Optionally, the chip may further include an output interface 804. In particular, the processor 801 may control the output interface 804 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0217] It should be understood that the processor in the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments may be accomplished through integrated logic circuits in the form of hardware in the processor or instructions in the form of software. The processor described above may be a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. Various methods, steps, and logic block diagrams of the disclosure in the embodiments of the present application may be implemented or performed. The general-purpose processor may be a microprocessor, or the processor may also be any conventional processor, etc. The steps of the methods disclosed in conjunction with the embodiments of the present application may be directly embodied in and performed by a hardware decoding processor, or performed with a combination of hardware and software modules in the decoding processor. The software module may be located in random memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, and other storage media well established in the art. The storage medium is located in memory, and the processor reads the messages in the memory and realize the steps of the method described above in combination with its hardware.

[0218] It will be appreciated that the memory in an embodiment of the present application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Among other things, the non-volatile memory may be Read-Only Memory (ROM) , Programmable ROM (PROM) , Erasable Programmable Read-Only Memory (EPROM) , Electrically Erasable Programmable Read-Only Memory (Electrically EPROM, EEPROM) or flash memory. The volatile memory may be Random Access Memory (RAM) , which is used as an external cache. For example, not for limiting, many forms of RAM are available, such as Static RAM (SRAM) , Dynamic RAM (DRAM) , Synchronous DRAM (SDRAM) , Double Data Rate SDRAM (DDRAM) , Double Data Rate SDRAM (DDRAM) , Enhanced Synchronous Dynamic Random Access Memory (ESDRAM) , Synchlink DRAM (SLDRAM) , and Direct Rambus RAM (DR RAM) . It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0219] Embodiments of the present application also provide a computer program product comprising computer program instructions.

[0220] Optionally, the computer program product may be applied to the network nodes in the embodiment of the disclosure, and the computer program instructions cause the computer to execute the corresponding processes implemented by the network nodes in the various methods of the embodiment of the disclosure, which are not described herein for brevity.

[0221] Optionally, the computer program product may be applied to the user equipment (s) in the embodiment of the present application, and the computer program instructions cause the computer to perform the corresponding processes realized by the user equipment (s) in the various methods of the embodiment of the present application, which are not repeated herein for brevity.

[0222] An embodiment of the disclosures also provides a computer program.

[0223] Optionally, the computer program may be applied to the network nodes in the embodiment of the present application, and when the computer program is run on the computer, causes the computer to execute the corresponding processes implemented by the network nodes in the various methods of the embodiment of the present application, which are not described herein for the sake of brevity.

[0224] Optionally, the computer program may be applied to the user equipment (s) in the embodiments of the present application, and when the computer program is run on the computer, causes the computer to execute the corresponding processes realized by the user equipment (s) in the respective methods of the embodiments of the present application, which will not be repeated herein for brevity.

[0225] One of ordinary skill in the art may realize that the units and algorithmic steps described in conjunction with the various examples of the embodiments disclosed herein are capable of being implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the particular application and design constraints of the technical solution. Aperson skilled in the art may use different methods to implement the described functions for each particular application, but such implementations should not be considered outside the scope of this application.

[0226] Those skilled in the art may appreciate that, for the convenience and brevity of the description, the specific working processes of the above-described systems, apparatuses and units can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated herein.

[0227] In the several embodiments provided in this application, it should be understood that the systems, devices and methods disclosed can be realized in other ways. For example, the above-described implementations of the device are merely schematic, e.g., the division of the unit, which is merely a logical functional division, may be divided in other ways when actually implemented, e.g., multiple units or components may be combined or may be integrated into another system, or some features may be ignored, or not implemented. Additionally, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, which may be electrical, mechanical or otherwise.

[0228] The unit illustrated as a separated component may or may not be physically separated, and the component shown as a unit may or may not be a physical unit, i.e., it may be located in one place, or it may be distributed over a plurality of network units. Some or all of these units may be selected to fulfill the purpose of the present embodiment scheme according to actual needs.

[0229] Additionally, each functional unit in various embodiments of the present application may be integrated into a single processing unit, or each unit may exist as a separate entity, or two or more units may be integrated into a single unit.

[0230] The functionality, when implemented as a software functional unit and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied in the form of a software product that is essentially or contributes to the prior art, or portions of the technical solution may be embodied in the form of a software product that is stored in a storage medium and includes a number of instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc. ) to perform all or some of the steps of the various embodiments of the present application. all or some of the steps of the various embodiments of the present application. The aforementioned storage medium is a non-volatile storage medium, including a portable disk, a removable hard disk, a read-only memory (Read-Only Memory, ROM) , a random-access memory (Random Access Memory, RAM) , a magnetic disk, or a CD-ROM, and other media in which the program code can be stored.

[0231] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1.A method for enabling a satellite call service executed by a first node involved in a call service comprising:exchanging, between nodes involved in the call service through satellite access or a non-Terrestrial Network (NTN) , information that includes one or more of access types, transmission rates, supported codecs of calling user equipment (UE) and called UE, call setup time, and one-way propagation delay; andperforming for the call service at least of a header reduction, a codec selection, and / or a signaling reduction based on the information.2.The method for enabling a satellite call service of claim 1, wherein the information is transmitted through at least one of:Radio Resource Control (RRC) signaling between the UEs and a Next Generation Radio Access Network (NG-RAN) ;Non-Access Stratum (NAS) signaling between the UEs and a core network entity; orIMS protocol signaling using Session Description Protocol (SDP) transactions between the UEs and an IMS node.3.The method for enabling a satellite call service of claim 1, wherein the performing for the call service further comprises:determining, based on the information, a selected compressed header reduction plan that ensures a data rate calculated from an Internet Protocol Multimedia Subsystem (IMS) codec bitrate remains below an achievable transmission data rate of a geosynchronous equatorial orbit (GEO) satellite and a desired transmission data rate for sending IMS messages is less than or equal to the achievable transmission data rate of the GEO satellite;distributing the selected compressed header reduction plan among protocol stacks used for encapsulating IMS packets; andproviding feedback regarding the selected compressed header reduction plan to the nodes involved in IMS communications.4.The method for enabling a satellite call service of claim 3, further comprising:applying static field compression to static header fields; and / orapplying dynamic field compression to dynamic header fields.5.The method for enabling a satellite call service of claim 4, wherein the static header fields with fixed header values comprise one or more of protocol identifiers, padding, and constant addresses; andThe dynamic header fields comprise one or more of checksum, flags, sequence numbers, and timestamps.6.The method for enabling a satellite call service of claim 3, wherein the protocol stacks comprise one or more of:Real-time Transport Protocol (RTP) ;User Datagram Protocol (UDP) ;Internet Protocol (IP) ;Packet Data Convergence Protocol (PDCP) ;Radio Link Control (RLC) ; andMedium Access Control (MAC) .7.The method for enabling a satellite call service of claim 3, wherein the feedback is signaled through at least one of:IMS protocol signaling;Non-Access Stratum (NAS) signaling; orRadio Resource Control (RRC) signaling.8.The method for enabling a satellite call service of claim 3, further comprising:determining a total bit constraint for compressed headers;implementing a compression strategy to allocate available bits among multiple protocol layers; andcompressing protocol headers according to the implemented compression strategy.9.The method for enabling a satellite call service of claim 7, wherein the compression strategy comprises a Random Distribution Strategy, and the implementing the compression strategy comprises:allocating a minimum necessary number of bits to each protocol layer according to a predetermined distribution pattern;ensuring balanced bit distribution across protocol layers; andmaintaining consistent overhead allocation across protocols within the total bit constraint.10.The method for enabling a satellite call service of claim 8, wherein allocating the minimum necessary number of bits comprises:assigning bits to Real-time Transport Protocol (RTP) for sequence numbers and timing information;assigning bits to User Datagram Protocol (UDP) for checksums and port information;assigning bits to Internet Protocol (IP) for addressing functions;assigning bits to Packet Data Convergence Protocol (PDCP) for sequence numbers and encryption;assigning bits to Radio Link Control (RLC) for dynamic fields; andassigning bits to Medium Access Control (MAC) for access control.11.The method for enabling a satellite call service of claim 8, wherein for a 20-bit total constraint, the Random Distribution Strategy allocates:6 bits to RTP;4 bits to UDP;2 bits to IP;4 bits to PDCP;2 bits to RLC; and2 bits to MAC.12.The method for enabling a satellite call service of claim 7, wherein the compression strategy comprises a Bitwise Optimization Strategy, and the implementing the compression strategy comprises:determining criticality levels of different protocol functions;analyzing protocol interdependencies;allocating bits based on protocol criticality; andoptimizing bit distribution for critical functions while maintaining functionality for less critical functions.13.The method for enabling a satellite call service of claim 11, wherein for a 20-bit total constraint, the Bitwise Optimization Strategy allocates:4 bits to RTP optimized for timing synchronization;2 bits to UDP for port management;4 bits to IP prioritizing routing functionality;4 bits to PDCP emphasizing security operations;2 bits to RLC for reliable data transfer; and4 bits to MAC optimizing access control.14.The method for enabling a satellite call service of claim 11, further comprising:monitoring network conditions and protocol performance;adjusting bit allocation based on real-time requirements; andmaintaining performance for critical functions through adaptive bit distribution.15.The method for enabling a satellite call service of claim 11, wherein the protocol headers are compressed from 416 bits to 20 bits while maintaining protocol functionality.16.The method for enabling a satellite call service of claim 1, wherein the performing for the call service further comprises:selecting, based on the information, codecs to minimize transcoding requirements between the calling UE and the called UE, wherein one of the UEs comprises a UE accessing via GEO satellite, and the other one of the UEs comprises another UE accessing via non-GEO satellite or terrestrial network; andproviding feedback to the nodes involved in IMS communications regarding the selected codecs.17.The method for enabling a satellite call service of claim 1, wherein the selecting codecs comprises:identifying codec pairs with minimal bitrate differences while maintaining voice quality above a target threshold based on Mean Opinion Score (MOS) ratings.18.The method for enabling a satellite call service of claim 15, wherein the codecs comprises one or more of:Adaptive Multi-Rate (AMR) ;AMR Wideband (AMR-WB) ;Enhanced Voice Services (EVS) ;EVS Primary Silence Insertion Descriptor (SID) ;EVS Special case; andAMR-WB SID.19.The method for enabling a satellite call service of claim 15, wherein the feedback is signaled through at least one of:IMS protocol signaling;Non-Access Stratum (NAS) signaling; orRadio Resource Control (RRC) signaling.20.The method for enabling a satellite call service of claim 1, wherein the performing for the call service further comprises:determining, based on the information, a signaling reduction plan that maintains both call setup time and total propagation and processing delay within International Telecommunication Union (ITU) recommended limits; andproviding feedback regarding the signaling reduction plan to the nodes involved in IMS communications.21.The method for enabling a satellite call service of claim 19, wherein the determining the signaling reduction plan comprises:calculating a maximum allowable message transmission delay by subtracting a maximum propagation and processing delay from a maximum total delay;calculating an allowable IMS signaling message size based on the maximum allowable message transmission delay and an achievable transmission data rate among the transmission rates; anddetermining a number of signaling messages to eliminate based on comparing the allowable IMS signaling message size with a default IMS message size.22.The method for enabling a satellite call service of claim 19, wherein the signaling reduction plan comprises eliminating one or more non-essential Session Initiation Protocol (SIP) messages while maintaining call setup functionality; andconsolidating information elements (IEs) and headers from eliminated messages into remaining messages.23.The method for enabling a satellite call service of claim 19, wherein the feedback is signaled through at least one of:IMS protocol signaling;Non-Access Stratum (NAS) signaling; orRadio Resource Control (RRC) signaling.24.The method for enabling a satellite call service of claim 20, wherein the eliminated messages comprise one or more of SIP TRYING, SIP PRACK, SIP 200 OK PRACK, SIP UPDATE, SIP 200 OK UPDATE.25.The method for enabling a satellite call service of claim 20, wherein the remaining messages comprise one or more of SIP 183, SIP 180 Ring, SIP 200 OK for invitation, and SIP ACK.26.The method for enabling a satellite call service of claim 20, wherein the IEs consolidated into the remaining messages comprise one or more of quality of service (QoS) and codecs selected by the calling UE and session modifications.27.The method for enabling a satellite call service of claim 1, wherein when the first node is an IMS node, the method further comprises:transmitting signals to determine the optimization plan to at least one of: a Session Management Function (SMF) via Nsmf_communication; an Access and Mobility Management Function (AMF) via Namf_communication; or a base station via Next Generation Application Protocol (NGAP) Protocol Data Unit (PDU) session modification signaling.28.The method for enabling a satellite call service of claim 1, wherein when the first node is a base station, the method further comprises: indicating the optimization plan to:an AMF via NGAP PDU session modification signaling;an SMF via NGAP and Namf_communication;an IMS node via NGAP PDU session modification, Namf_communication and Nsmf_communication; the calling UE via RRC signaling; anda called UE via at least one of NGAP PDU session modification, Namf_communication, Nsmf_communication, or SIP signaling.29.The method for enabling a satellite call service of claim 1, wherein when the first node is an AMF, the method further comprises:indicating the optimization plan to:an SMF via Namf_communication;an IMS node via Namf_communication and Nsmf_communication;the calling UE via NAS signaling; anda called UE via Namf_communication, Nsmf_communication and NAS signaling.30.A wireless communication device comprising:a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the method of any of claims 1 to 28.31.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any of claims 1 to 28.32.A computer-readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any of claims 1 to 28.33.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 28.34.A computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 28.

Images