Method and apparatus for improving internet protocol multimedia subsystem message flow in mobile communications

Abstract

Methods and apparatuses for optimizing Internet Protocol Multimedia Subsystem (IMS) message flows for geostationary earth orbit (GEO) non-terrestrial network (NTN) voice services are disclosed. A user equipment (UE) can include IMS registration information in a non-access stratum (NAS) attach request message transmitted over a control plane signaling radio bearer (SRB). A mobility management entity (MME) can perform IMS registration on behalf of the UE. Voice call setup signaling can be transmitted as binary-coded Session Initiation Protocol (SIP) messages over NAS information transfer messages on the control plane. Voice media can be transmitted as Real-Time Transport Protocol (RTP) packets over a default bearer using non-IP data delivery (NIDD). The methods disclosed can reduce signaling overhead, thereby meeting call setup key performance indicators (KPIs) in a GEO NTN environment.

Description

[0001] Cross-references to related applications This invention is part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 796,460, filed April 29, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention is generally related to mobile communications, and more specifically, relates to improving the Internet Protocol Multimedia Subsystem (IMS) message flow for voice services in mobile communications. Background Technology

[0003] Unless otherwise stated in this invention, the methods described in this section are not prior art to the listed claims, nor are they admitted as prior art by virtue of their inclusion in this section.

[0004] The Internet Protocol Multimedia Subsystem (IMS) is a standardized framework within the 3rd Generation Partnership Project (3GPP) for providing voice and multimedia services over mobile and satellite networks. IMS voice calls rely on the Session Initiation Protocol (SIP) for call control signaling and on the Real-time Transport Protocol (RTP) for media packet transmission. According to traditional 3GPP specifications, IMS Packet Data Network (PDN) connections are established through a default bearer and a dedicated bearer, both of which are transmitted via a Data Radio Bearer (DRB).

[0005] However, in Geostationary Earth Orbit (GEO) Non-Terrestrial Network (NTN) environments, the resource constraints and high propagation delays of satellite links pose fundamental challenges to traditional IMS signaling architectures. GEO satellite access suffers from approximately 280 milliseconds of one-way signal propagation delay and extremely limited available data rates (approximately 1 to 3 kilobits per second). Following conventional procedures, a single SIP INVITE message can reach approximately 2000 bytes, while the cumulative data transmission required to complete the IMS call setup process can reach approximately 10,000 bytes. Given the available data rates of GEO NTN links, such a large data volume can cause IMS call setup times to exceed 90 seconds using existing methods, which is fundamentally incompatible with the Key Performance Indicator (KPI) for call setup defined by 3GPP for voice services.

[0006] Therefore, shortening call setup time in GEO NTN scenarios has become a crucial issue in newly developed wireless communication networks. To address this, suitable solutions are needed to improve IMS message flow. Summary of the Invention

[0007] The following overview is illustrative only and is not intended to be limiting in any way. That is, it is provided to introduce the concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described in this invention. Selective embodiments are further described in the detailed description below. Therefore, the following overview is not intended to identify the essential features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter.

[0008] One object of the present invention is to provide a solution or approach to address the aforementioned problems related to improving IMS message flow in voice services in mobile communications.

[0009] In one aspect, a method may include an apparatus, via its processor, including IMS registration information in a Non-Access Stratum (NAS) attach request message. The method may also include the apparatus, via its processor, sending the NAS attach request message to a network. The method may further include the apparatus, via its processor, receiving a NAS attach accept message from the network. The NAS attach accept message may contain IMS notification information.

[0010] In one aspect, a method may include: the device encoding a SIP INVITE message using a binary encoding scheme via its processor to generate an encoded INVITE message. The method may further include: the device transmitting the encoded SIP INVITE message to the network via NAS uplink (UL) information transmission signaling via the processor. The method may further include: the device receiving a SIP response message encoded using a binary encoding scheme from the network via NAS downlink (DL) information transmission signaling via the processor.

[0011] In another approach, one method may include: a network node receiving a NAS connection request message containing IMS registration information via its processor. The method may also include: the network node performing IMS registration with the core network based on the IMS registration information via its processor. Furthermore, the method may include: the network node sending a NAS connection acceptance message containing IMS notification information via its processor.

[0012] It is worth noting that, although the description provided in this invention may be based on certain wireless access technologies, networks, and network topologies, such as Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, 5G, NR, Internet of Things (IoT), Narrow Band Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), and 6G (6G)... th (Generation 6G), but the proposed concepts, schemes, and any variations / derivatives thereof can be applied to other types of wireless access technologies, networks, and network topologies. Therefore, the scope of this invention is not limited to the examples described herein. Attached Figure Description

[0013] The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this invention. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. It should be noted that the drawings are not necessarily drawn to scale, as in actual implementations some components may be shown out of proportion to clearly illustrate the concepts of the invention.

[0014] Figure 1A shows a schematic diagram of an exemplary NTN architecture according to an embodiment of the present invention, in which a GEO satellite operates as a relay node but does not have onboard processing capabilities.

[0015] Figure 1B shows a schematic diagram of an exemplary NTN architecture according to an embodiment of the present invention, wherein a GEO satellite is equipped with full core network functionality and optionally with IMS functionality.

[0016] Figure 2 illustrates an exemplary IMS registration process according to an embodiment of the present invention.

[0017] Figure 3 is an example block diagram of the optimized call setup and voice media transmission process according to an embodiment of the present invention.

[0018] Figure 4 is an example flowchart of the I1 binary encoding scheme according to an embodiment of the present invention.

[0019] Figure 5 is an example block diagram of a communication system according to an embodiment of the present invention.

[0020] Figure 6 is a flowchart of another example process according to an embodiment of the present invention.

[0021] Figure 7 is a flowchart of another example process according to an embodiment of the present invention.

[0022] Figure 8 is a flowchart of another example process according to an embodiment of the present invention. Detailed Implementation

[0023] This invention discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely examples of the claimed subject matter, which can be implemented in various forms. This invention can be implemented in many different forms and should not be construed as being limited to the exemplary embodiments and implementations described herein. Rather, these exemplary embodiments and implementations are provided to make the description of the invention thorough and complete, and to fully convey the scope of the invention to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the provided embodiments and implementations.

[0024] Overview The implementation of this invention relates to various techniques, methods, schemes, and / or solutions related to improving IMS message flows. According to this invention, many possible solutions can be implemented individually or in combination. That is, although these possible solutions will be described separately below, two or more of them can be implemented in some combination.

[0025] The technologies described in this invention can be applied to various telecommunications systems utilizing IMS communication services, such as current 4G and 5G communication systems, or next-generation communication systems (e.g., 6G). The IMS media described in this invention is not limited to voice, but also includes any real-time media type, such as video, text, and applications. The user equipment involved in this invention is not limited to mobile phones, but can also include any device capable of providing IMS communication services, such as wearable devices, in-vehicle devices, Internet of Things (IoT) devices, etc.

[0026] Figure 1A and Figure 1B Two schematic system diagrams are shown, illustrating two example 3GPP NTN architectures according to embodiments of the present invention.

[0027] Figure 1A illustrates an NTN architecture where the GEO satellite 102 does not contain any onboard processing capabilities, such as base station functionality and / or core network (CN) functionality. In this configuration, the GEO satellite 102 primarily operates as a relay node. Taking the UE's transmission (Tx) direction as an example, the UE 101 on the ground first sends data to the GEO satellite 102 via service link 111. The GEO satellite 102 then forwards the data to the gateway 103 via feeder link 112. After the data reaches the ground network, it is processed by the base station (BS) 104 via link 113, processed by the core network 105 via link 114, and finally reaches the IMS server 106 via link 115. The core network 105 can be the evolved packet core (EPC) in a 4G communication system, the 5G core (5GC) in a 5G communication system, or the 6G core (6GC) in a 6G communication system.

[0028] Figure 1B illustrates an NTN architecture in which GEO satellite 102 is equipped with full CN functionality and may also include onboard IMS functionality. In this configuration, the communication path between UE 101 and IMS server 106 includes at least one GEO service link 111, and IMS server 106 can be directly deployed on GEO satellite 102.

[0029] It should be noted that the present invention is not limited to the NTN architecture shown in Figures 1A and 1B. Rather, the present invention can also be applied to other NTN configurations in which one or more satellites act as intermediate nodes on the data path between the UE and the IMS server.

[0030] Note that UE 101 in Figures 1A and 1B may include one or more UEs, wherein at least one UE is a mobile originating (MO) terminal for an IMS call, making the call via a terrestrial network (TN) and / or NTN; and at least one UE is a mobile terminating (MT) terminal for the same IMS call, making the call via a TN and / or NTN.

[0031] IMS calls can be initiated between MO UE and MT UE according to one or more of the 3GPP technical specifications, including RFC 3261 Session Initiation Protocol (SIP), RFC 4566 Session Description Protocol (SDP), and RFC 3550 Real-time Transport Protocol (RTP).

[0032] In traditional 5G NR networks that support voice services (e.g., Voice over New Radio (VoNR)), the IMS registration process is performed in a series of independent signaling phases, each of which must be completed before the next phase can begin. Under this traditional approach, IMS registration is decoupled from the 5G core network registration process and relies entirely on the User Plane (UP) path for all SIP signaling exchanges.

[0033] In the first phase of the traditional IMS registration process, the User Equipment (UE) performs 5G core network registration by sending a Non-Access Stratum (NAS) registration request to the Access and Mobility Management Function (AMF) via the gNB through the Signaling Radio Bearer (SRB). During this NAS registration process, the UE indicates its support for IMS voice services by including a capability indicator in its UE Capability Information Unit. After successful NAS registration, the AMF sends a registration acceptance message to the UE. However, at this stage, no IMS-specific information is transmitted, and no IMS PDU session is established.

[0034] In the second phase, the UE initiates a dedicated IMS Protocol Data Unit (PDU) session establishment procedure, independent of the aforementioned NAS registration procedure, and proceeds thereafter. The UE sends a PDU session establishment request specifying the IMS Data Network Name (DNN) to the AMF, which forwards the request to the Session Management Function (SMF). The SMF creates the PDU session and routes relevant user plane traffic via the User Plane Function (UPF). As part of the PDU session establishment process, the network assigns an IP address to the UE and provides the UE with the address of the Proxy-Call Session Control Function (P-CSCF) via the Protocol Configuration Option (PCO) or Extended PCO (ePCO) information element. The IMS PDU session is assigned a non-guaranteed bit rate (non-GBR) Quality of Service (QoS) stream with a 5G QoS Identifier (5QI) value corresponding to the IMS signaling traffic. This IMS PDU session is transmitted entirely via the user plane path through the Data Radio Bearer (DRB), passing through the gNB and UPF, and bypassing the AMF.

[0035] In the third phase, the UE initiates SIP-based IMS registration by sending a SIP REGISTER request over the IMS PDU session established in the second phase. This SIP REGISTER request is transmitted as a standard IP packet on the user plane DRB and routed via the P-CSCF to the Interrogating-Call Session Control Function (I-CSCF). The I-CSCF queries the Home Subscriber Server (HSS) or Unified Data Management (UDM) to obtain the authentication vector and selects a Serving-Call Session Control Function (S-CSCF). The IMS network responds with a SIP 401 Unauthorized Challenge message carrying authentication parameters. Subsequently, the UE sends a second SIP REGISTER request containing the calculated authentication response. The S-CSCF verifies this response against the expected value stored in the HSS / UDM. Upon successful verification, it downloads the user profile and sends a SIP 200 OK response to the UE via the I-CSCF and P-CSCF. Each SIP message exchange is transmitted via the user plane DRB as a full-size SIP message, thus incurring all transmission overhead associated with the plaintext SIP header and IP encapsulation. A complete SIP IMS registration process requires at least two complete round-trip SIP exchanges on the user plane, in addition to the signaling overhead of the previous NAS registration and IMS PDU session establishment phases.

[0036] In the fourth phase, after successful IMS registration, voice media is transmitted during IMS calls via a dedicated GBR QoS stream with a 5QI value of 1, established via the PDU session modification procedure. SIP call setup signaling during the call continues to be transmitted via the user plane DRB on the default IMS PDU session, while Real-time Transport Protocol (RTP) voice packets are also carried via the user plane DRB on a dedicated GBR QoS stream.

[0037] The aforementioned traditional VoNR IMS registration process presupposes that the user plane has sufficient bandwidth and sufficiently low propagation latency to complete multiple sequential signaling phases within an acceptable timeframe. Specifically, the process requires the sequential completion of the following steps: (1) a NAS registration process; (2) a separate IMS PDU session establishment process on the user plane; and (3) a SIP-based IMS registration process, which includes at least two SIP round-trip exchanges, each carrying approximately 1,000 to 2,000 bytes of complete SIP messages on the user plane. In terrestrial 5G NR deployments, the user plane round-trip time is approximately in the millisecond range, and the available data rate is approximately in the megabits per second range; therefore, this multi-stage sequential process can be completed in approximately one second or less.

[0038] However, in a GEO NTN environment, the aforementioned traditional methods are fundamentally insufficient. GEO satellite links introduce approximately 280 milliseconds of one-way propagation delay and limit the available data rate to approximately 1 to 3 kilobits per second. Under these conditions, the cumulative data volume required to complete the traditional NAS registration, IMS PDU session establishment, and two round trips of SIP IMS registration (transmitted entirely through the user plane in standard IP-encapsulated SIP message format) results in IMS registration and call setup times exceeding 90 seconds. This performance does not conform to the 30-second call setup KPI defined by 3GPP for GEO NTN voice services, making the traditional VoNR IMS registration architecture unsuitable for deployment in a GEO NTN environment.

[0039] Furthermore, conventional approaches do not provide a mechanism for integrating IMS registration information with the NAS attach process, a mechanism for passing IMS registration parameters in NAS signaling messages, or a mechanism for delegating SIP-based IMS registration exchanges to network nodes (such as the Mobility Management Entity, MME) on behalf of the UE. Similarly, conventional approaches do not provide any mechanism for using Non-IP Data Delivery (NIDD) to transmit voice RTP packets as a default bearer, replacing a dedicated GBR bearer that transmits RTP over UDP over IP.

[0040] Therefore, methods and apparatus are needed to optimize the IMS registration and voice call setup process in GEO NTN or other constrained network environments by combining IMS registration with NAS attachment, transmitting SIP signaling via binary encoding on the non-access stratum control plane path, and transmitting voice media via non-IP data transmission on the default bearer, thereby meeting the call setup KPIs defined by 3GPP under the strict bandwidth and latency constraints of satellite access.

[0041] According to the present invention, an optimized IMS registration process for UEs running on GEO NTN is proposed. This process integrates the IMS registration process with the NAS attachment process, thereby eliminating the sequential signaling stage and accumulated user plane data overhead, making the traditional VoNR IMS registration architecture unsuitable for the GEO NTN environment.

[0042] The optimized IMS registration process of this invention is executed in an NTN system architecture that includes a UE, a GEO satellite as a transparent relay node, a BS, an MME, and an IMS core network. Figure 2 An example IMS registration process disclosed in this invention is shown.

[0043] The UE (User Equipment) is a ground-based communication device capable of establishing a wireless connection with the network via a GEO satellite link. The UE can be any device capable of supporting IMS voice services, including but not limited to smartphones, tablets, wearable devices, or Internet of Things (IoT) devices. The GEO satellite operates as a transparent relay node between the UE and the ground network infrastructure. In this transparent payload architecture, the GEO satellite relays radio frequency signals between the UE and ground network equipment via a service link facing the UE and a feeder link facing the network. The network side can include base stations, which can be evolved Node Bs (eNBs) in 4G Evolved Packet System (EPS) architectures, next-generation Node Bs (gNBs) in 5G New Radio (NR) architectures, or base stations in 6G network architectures, located on the ground and connected to the GEO satellite via feeder links. In this architecture, the MME (Mobile Equipment) is the core network node responsible for NAS signaling and mobility management.

[0044] In the optimized IMS registration process of this invention, the network can broadcast an IMS signaling optimization capability indicator to UEs within the coverage area. Specifically, the satellite can send a system information block (e.g., SIBx) containing an IMS signaling optimization capability indicator (e.g., IMSsigOpt) to indicate to the UE that the network supports the optimized IMS registration process described in this invention. After receiving the SIBx and detecting the presence of the IMS sigOpt capability indicator, the UE can determine that the optimized IMS registration process is available and merge the IMS registration information into its NAS attach request message. In implementations where the IMS sigOpt capability indicator is not present in the received SIBx, the UE can fall back to the traditional SIP-based IMS registration process on the user plane. Therefore, the IMS sigOpt capability indicator acts as a gating mechanism, enabling the network to activate the optimized IMS registration process on a cell-by-cell basis, thereby allowing the network to selectively enable the process in GEO NTN cells while maintaining backward compatibility with the traditional IMS registration process in terrestrial cells.

[0045] The UE can then incorporate the IMS registration information into a NAS attach request message, which is sent to the Mobility Management Entity (MME) via the Control Plane (CP) Signaling Radio Bearer (SRB). In traditional VoNR methods, such IMS registration information (including the IMS Public User Identity (IMPU) and IMS Private Identity (IMPI)) is transmitted entirely as standard IP-encapsulated SIP packets within a SIP register message sent via the User Plane Data Radio Bearer (DRB). This requires establishing a dedicated IMS PDU session prior to IMS registration. In contrast, in this invention, IMPU, IMPI, and any other IMS registration parameters required to initiate the IMS registration process in the IMS core network are embedded in the NAS attach request message itself. No separate SIP-based registration exchange between the UE and the IMS core network is required before the IMS PDU session is established. The NAS attach request message carrying IMS registration information is transmitted via the control plane SRB, which provides mandatory integrity protection and encryption, and is routed to the MME via the radio access network. In some implementations, the NAS attach request message may also include a PDN connection request for IMS Packet Data Network (PDN) connectivity with a request type set to "initial attach" (IA), so that the IMS PDN connection is requested to be established simultaneously with the NAS attach process, without issuing a separate PDN connection request after the attach is complete.

[0046] On the network side, the MME can perform IMS registration with the IMS core network on behalf of the UE based on the IMS registration information received in the NAS Attach Request message. After receiving the NAS Attach Request message and extracting the embedded IMS registration information, the MME uses the extracted IMPU, IMPI, and any relevant authentication parameters to initiate and complete the IMS registration process with the IMS core network, without requiring the UE to directly exchange SIP REGISTER messages with the P-CSCF, I-CSCF, or S-CSCF. In this way, the SIP-based IMS registration exchange (in the traditional process, this process requires at least two complete round-trip message exchanges between the UE and the IMS core network through the user plane, each exchange carrying approximately 1000 to 2000 bytes of complete SIP messages) is replaced by the network-side process performed by the MME, without requiring any additional user plane transmission from the UE. Therefore, the MME acts as a proxy for the UE during the IMS registration process, utilizing the existing NAS control plane signaling infrastructure to pass the IMS registration parameters to the IMS core network in a transparent manner to the UE, without requiring the UE to establish an IMS PDU session or user plane DRB before IMS registration.

[0047] After the MME (Mobile Equipment Manager) successfully completes IMS registration on behalf of the UE, the network sends a NAS Attach Accept message to the UE via the control plane SRB (System Resource Block). In this invention, the NAS Attach Accept message carries IMS notification information indicating that IMS registration has been successfully completed and the IMS PDU connection has been established. In some implementations, the IMS notification information carried in the NAS Attach Accept message may include one or more of the following: confirmation information of successful IMS registration, the assigned IMS contact address or binding, authentication result parameters, and the P-CSCF address assigned to subsequent IMS signaling. After receiving the NAS Attach Accept message and its contained IMS notification information, the UE can store the IMS registration status and IMSPDN connection parameters, and consider itself to have completed IMS registration without sending any SIP messages on the user plane.

[0048] Thanks to the optimized IMS registration process described above, the UE can complete 5G core network attachment and IMS core network registration through a single NAS signaling exchange on the control plane SRB, while simultaneously establishing an IMS PDN connection. All of this is accomplished within the latency and bandwidth limitations of GEO NTN satellite access. This contrasts sharply with traditional VoNR methods, where IMS registration requires three consecutive signaling phases—NAS registration, IMS PDU session establishment, and SIP-based IMS registration—each generating user plane data transmissions that are individually incompatible with the approximately 1 to 3 kilobits per second bandwidth limitation of GEO NTN. By integrating these three phases into a single NAS control plane exchange, this invention significantly reduces the total data volume and round-trip exchanges required to complete IMS registration, enabling IMS voice services to be provided via GEO NTN within the timeframes defined by 3GPP call setup KPIs.

[0049] The optimized call setup and voice media transmission process of this invention is executed within the same GEO NTN system architecture as the optimized IMS registration process described above, and adds a Serving Gateway (S-GW) participating in the voice media transmission path. Figure 3 illustrates the signaling entities and transmission paths involved in the optimized call setup and voice media transmission process of this invention.

[0050] In addition to the UE, GEO, base station, and MME mentioned above, the system architecture used for call setup and voice media transmission also includes the S-GW. The S-GW is the user plane gateway node in the EPC, anchoring the default EPS bearer of the IMS PDN connection and routing user plane packets between the radio access network and the Packet Data Network Gateway (P-GW). In the context of this invention, the S-GW performs extended functions beyond its traditional user plane forwarding role: before initiating voice media transmission, the S-GW is configured with a forwarding rule that enables it to handle Real-time Transport Protocol (RTP) packets encapsulated in Non-IP Data Delivery (NIDD) format via the default bearer of the IMS PDN connection, as will be described in detail below.

[0051] The call setup process of this invention utilizes two distinct transmission paths for two types of traffic: one is a Non-Access Stratum Control Plane (NAS CP) path on the Signaling Radio Bearer (SRB) used for SIP call setup signaling; the other is a User Plane (UP) path on the default Data Radio Bearer (DRB) for the IMS PDN connection used for voice RTP media. The NAS CP path routes NAS messages carrying encoded SIP signaling from the UE to the terrestrial MME via the base station and GEO satellite relay. The User Plane path for voice media routes NIDD-encapsulated RTP packets from the UE to the remote terminal via the base station, GEO satellite relay, and S-GW. A novel aspect of this invention is the separation of SIP call setup signaling onto the NAS control plane path and the separation of voice RTP media onto the default User Plane bearer path, which contrasts sharply with traditional IMS call architectures. In the traditional IMS call architecture, both SIP signaling and voice media are transmitted via user plane data wireless bearer.

[0052] According to the present invention, after completing the above-described IMS registration process, an optimized Mobile Originating (MO) call setup process is executed. In this process, all SIP call setup signaling is transmitted via the NAS control plane path using a binary encoding scheme, while voice media is transmitted via the default bearer of the IMS PDN connection using Non-IP Data Delivery (NIDD). This avoids the overhead of user plane data volume and dedicated bearer setup, which makes the traditional IMS call setup architecture unsuitable for GEO NTN environments.

[0053] During the optimized call setup process, the UE encodes the SIP INVITE message using a binary encoding scheme and transmits the encoded SIP INVITE message to the MME within a NAS uplink (UL) information transmission message via the control plane SRB. In some implementations, this binary encoding scheme can be the I1 encoding scheme defined in the 3GPP standard, which transmits a subset of key SIP message fields in a compact binary format. These key SIP message fields include at least the dialed number and a call type indicator indicating whether the call is a voice or video call. By using the I1 binary encoding scheme to encode the SIP INVITE message and transmitting it within a NAS UL information transmission message via the control plane SRB, this invention reduces the data size of the SIP INVITE message from approximately 2,000 bytes in the traditional full-size plain text SIP format to a significantly smaller binary encoded representation compatible with the 1 to 3 kilobits per second data rate limit of GEO NTN satellite links. When the MME receives the NAS UL information transmission message, it extracts the I1-encoded SIP INVITE message and forwards the corresponding SIP INVITE message to the IMS core via the standard IMS signaling interface.

[0054] Next, the IMS core network processes the SIP INVITE and returns a temporary SIP 100 Trying response, indicating that the INVITE has been received and is being processed. The MME receives the SIP 100 Trying response from the IMS core network, encodes it using the I1 binary encoding scheme, and sends the encoded response to the UE within a NAS downlink (DL) information transmission message via the control plane SRB. In this way, every SIP response message generated by the IMS core network during call setup is encoded in binary format by the MME and transmitted to the UE via the NAS control plane path, without requiring any user plane DRB transmission for SIP signaling purposes.

[0055] The IMS core network can also send a SIP 183 session progress message, indicating that end-to-end session parameters have been negotiated and the media path is being prepared. After receiving the SIP 183 session progress message from the IMS core network, the MME encodes the message using the I1 binary encoding scheme and transmits it to the UE via the control plane SRB within the NAS downlink information transmission message. Upon receiving the SIP 183 session progress message, the UE recognizes that sufficient session parameters are available to begin preparing for voice media transmission via NIDD.

[0056] Upon receiving a SIP 183 session progress indication, or immediately thereafter, the MME can configure an NIDD forwarding rule to the S-GW. This configuration step instructs the S-GW to process voice RTP packets encapsulated as non-IP packets over the default bearer of the IMS PDN connection, thereby enabling the default bearer to replace the traditional dedicated GBR bearer as the transmission path for voice media. In some implementations, the NIDD forwarding rule configuration can specify one or more of the following: an identifier for the default IMS PDN bearer used to forward NIDD-encapsulated RTP packets; the non-IP packet encapsulation format to apply; and the remote endpoint address and port parameters negotiated during SIP session establishment. Configuring the NIDD forwarding rule in the S-GW before voice media transmission begins ensures that the S-GW can correctly process NIDD-encapsulated RTP packets upon receipt, without incurring the dedicated bearer establishment delays common in traditional IMS media architectures.

[0057] Then, the IMS core network sends a SIP 180 ringing message to indicate that the called device is ringing. The MME encodes the SIP 180 ringing message using the I1 binary encoding scheme and transmits it to the UE via the control plane SRB within the NAS DL information transmission message.

[0058] After the called party answers the call, the IMS core network sends a final SIP 200 OK response. The MME encodes the SIP 200 OK message using the I1 binary encoding scheme and sends it to the UE via the control plane SRB within the NAS downlink information transmission message. Upon receiving the encoded SIP 200 OK response, the UE sends a SIP ACK message encoded using the I1 binary encoding scheme within the NAS uplink information transmission message via the control plane SRB, thereby completing the SIP handshake and establishing an IMS session.

[0059] After the SIP session is established, voice media is transmitted via the default bearer DRB through the IMS PDN connection in the form of RTP packets. In this invention, RTP packets are encapsulated in NIDD format and transmitted via the default bearer, instead of using IP-based UDP RTP encapsulation as in traditional dedicated bearer methods. Using NIDD encapsulation of voice RTP packets on the default bearer of the IMS PDN connection eliminates the need to establish a dedicated GBR bearer for voice media. In traditional IMS architectures, this requires additional bearer establishment signaling exchange via the GEO NTN satellite link before voice transmission begins. As described above, by pre-configuring NIDD forwarding rules in the S-GW during call setup, this invention enables voice RTP transmission to begin immediately after the SIP ACK exchange, without any additional bearer establishment delay.

[0060] The complete optimized call setup process of this invention—from transmitting I1-encoded SIPINVITE messages through the NAS control plane to completing the SIP ACK exchange and initiating NIDD-encapsulated voice RTP transmission—aims to meet the 30-second call setup KPI defined by 3GPP for GEO NTN voice services by minimizing the total data volume of SIP signaling exchanged over the GEO NTN satellite link and eliminating the dedicated bearer setup process required under the traditional IMS call architecture.

[0061] According to the present invention, SIP call setup messages transmitted via the NAS control plane path can be encoded using an I1 binary encoding scheme to reduce the data size of each SIP message to a level compatible with GEO NTN satellite access bandwidth limitations. Figure 4 illustrates an exemplary embodiment of the I1 binary encoding scheme according to the present invention. The I1 encoding scheme represents each SIP message as a compact binary structure containing two main fields: a five-bit message type value field for identifying the general category of the SIP message; and a ten-bit reason value field for distinguishing a specific message subtype or SIP response code within a given message type category. The mapping between SIP messages and their corresponding I1-encoded message types and reason values ​​is defined in the table “General Message Types” in Figure 4, which specifies the binary representation of all SIP message types associated with the IMS call setup and teardown process.

[0062] In some implementations, the UE can encode the SIP INVITE message for an MO call using an I1 encoding scheme before transmission via the NAS control plane path. According to the table in Figure 4, the I1 INVITE message for an MO call is represented by a message type value of 0x1 and a reason value of 0x000. In addition to the message type and reason fields, the I1-encoded INVITE message can also carry other call parameters that are crucial for establishing the call but cannot be derived solely from the message type and reason fields, including at least one dialed number to identify the called party and a call type indicator to specify whether the call is a voice or video call. These additional parameters are encoded in binary format in the I1 message payload according to the field definitions in the 3GPP standard. The resulting I1-encoded INVITE message is a significantly compressed binary equivalent of the corresponding full-size plaintext SIP INVITE message, which in traditional IMS implementations can be approximately 2,000 bytes long and contain many redundant or deducible SIP header fields from the network context. By replacing the full-size SIP INVITE message with its I1-encoded binary representation, this invention reduces the amount of uplink data initiated by a call to a level compatible with the 1 to 3 kilobits per second data rate limit of GEO NTN satellite links.

[0063] In some implementations, the MME can use the I1 encoding scheme to encode SIP provisional and final response messages received from the IMS core, and then transmit them to the UE via the control plane SRB within a NAS DL information transmission message. Specifically, SIP 1xx provisional response messages (including SIP 100 Trying response and SIP 183 Session Progress response) are encoded as I1 Progress messages with a message type value of 0x00 and a reason value corresponding to the hexadecimal encoded SIP response code specified in Note 1 of Table 4, indicating that the value of the Reason field corresponds to the hexadecimal encoded SIP 1xx value specified in RFC 3261. For example, a SIP 183 session progress response (carrying a decimal response code 183 with a hexadecimal value of 0xB7) is encoded as an I1 progress message with a Reason value of 0x0B7; a SIP 180 ringing response (with a hexadecimal value of 0xB4) is encoded as an I1 progress message with a Reason value of 0x0B4. Similarly, a SIP 100 attempt response (with a hexadecimal value of 0x64) is encoded as an I1 progress message with a Reason value of 0x064.

[0064] In some implementations, the SIP 200 OK final response message can be encoded as an I1 success message according to the table in Figure 4. The message type value of the I1 success message is 0x00, and the reason value ranges from 0xC8 to 0x12B, corresponding to the hexadecimal encoded SIP 2xx response codes specified in Note 1 of the table in Figure 4. Specifically, the SIP 200 OK response carrying a decimal response code 200 corresponding to the hexadecimal value 0xC8 is encoded as an I1 success message with a reason value of 0xC8. The MME can send the I1-encoded SIP 200 OK message to the UE in a NAS DL information transmission message via the control plane SRB. After receiving the I1-encoded SIP 200 OK message, the UE can encode the SIP ACK message using the I1 encoding scheme and send the encoded ACK message to the MME in a NAS UL information transmission message via the control plane SRB, thereby completing the SIP handshake.

[0065] This invention encodes all SIP call setup messages exchanged between the UE and the IMS core network using the I1 binary encoding scheme defined in the 3GPP standard, and transmits all encoded messages in the NAS information transmission message through the control plane SRB. This replaces the full-size plaintext SIP message exchange in the traditional IMS call setup architecture (which requires approximately 10,000 bytes of user plane data transmission to complete the call setup process) with a series of compact binary-encoded NAS control plane messages. The total data volume of these messages is compatible with the bandwidth limit of 1 to 3 kilobits per second for GEO NTN satellite links, thus enabling the complete call setup process to be completed within the 30-second call setup KPI defined by 3GPP for GEO NTN voice services.

[0066] Exemplary Implementation Figure 5 illustrates an example communication system 500 constructed according to an embodiment of the present invention, the system having an example communication device 510 and an example network device 520. Both the communication device 510 and the network device 520 can perform various functions to implement the schemes, techniques, processes, and methods for improving the IMS message flow of voice services in mobile communications as described in the present invention, including the scenarios / schemes described above and processes 600, 700, and 800 described below.

[0067] The communication device 510 may be part of an electronic device, which may be a UE (User Equipment), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the communication device 510 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device (e.g., tablet, laptop). The communication device 510 may also be part of a machine-type device, which may be an IoT, NB-IoT, or IIoT device, such as a fixed or non-mobile device, a home appliance, a wired communication device, or a computing device. For example, the communication device 510 may be applied to a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, the communication device 510 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction-set computing (RISC) processors, or one or more complex-instruction-set computing (CISC) processors. The communication device 510 may include at least some of the components shown in FIG. 5, such as the processor 512. The communication device 510 may also include one or more other components unrelated to the present invention (e.g., internal power supply, display device and / or user interface device), therefore, for the sake of brevity, such components of the communication device 510 are neither shown in FIG. 5 nor described below.

[0068] Network device 520 may be part of a network device, which may be a network node, such as a satellite, base station, small cell, router, gateway, or other network element. For example, network device 520 may be implemented in an eNodeB in an LTE network, a gNB in ​​a 5G / NR, IoT, NB-IoT, or IIoT network, or in a satellite or base station in a 6G network. Alternatively, network device 520 may be implemented as one or more integrated circuit chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. Network device 520 may include at least some of the components shown in FIG. 5, such as processor 522. Network device 520 may also include one or more other components unrelated to the proposed embodiments of the present invention (e.g., internal power supply, display device, and / or user interface device); therefore, for simplicity, such components of network device 520 are not shown in FIG. 5 and will not be described below.

[0069] In one aspect, both processor 512 and processor 522 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the present invention uses the singular term "processor" to refer to processor 512 and processor 522, according to the present invention, processor 512 and processor 522 may include multiple processors in some implementations and a single processor in others. On the other hand, both processor 512 and processor 522 may be implemented in hardware (and optionally firmware), whose electronic components include, but are not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, which are configured and arranged according to the present invention to achieve a specific purpose. In other words, in at least some embodiments, processor 512 and processor 522 are both dedicated machines designed, arranged, and configured to perform specific tasks, including proposed IMS message streams for voice services implemented according to various embodiments of the present invention.

[0070] In some embodiments, the communication device 510 may further include a transceiver 516 coupled to the processor 512, which is capable of wirelessly transmitting and receiving data. In some embodiments, the communication device 510 may further include a memory 514 coupled to the processor 512, which can be accessed by the processor 512 and stores data therein. In some embodiments, the network device 520 may further include a transceiver 526 coupled to the processor 522, which is capable of wirelessly transmitting and receiving data. In some embodiments, the network device 520 may further include a memory 524 coupled to the processor 522, which can be accessed by the processor 522 and stores data therein. Therefore, the communication device 510 and the network device 520 may wirelessly communicate via transceiver 516 and transceiver 526, respectively.

[0071] To better understand, the operation, functions, and capabilities of communication device 510 and network device 520 are described below in the context of a mobile communication environment, wherein communication device 510 is implemented as a communication device or UE, or implemented as a communication device or UE, and network device 520 is implemented as a network node of a communication network or implemented as a network node of a communication network.

[0072] Exemplary process Figure 6 illustrates an example process 600 according to an embodiment of the present invention. Process 600 may be an example implementation of the above-described scenario / scheme, whether in part or in whole, aimed at improving the IMS message flow of the voice service of the present invention. Process 600 may represent one aspect of the functional implementation of communication device 510. Process 600 may include one or more operations, actions, or functions, as shown by one or more modules 610 to 630 in the figure. Although the various modules of process 600 are shown as discrete modules, these modules may be split into more modules, merged into fewer modules, or deleted, depending on the desired implementation. Furthermore, the various modules of process 600 may be executed in the order shown in Figure 6, or in a different order. Process 600 may be implemented by communication device 510 or any suitable UE or machine type device. For ease of illustration and without limitation, process 600 is described below in the context of communication device 510. Process 600 may begin with block 610.

[0073] In block 610, process 600 may include processor 512 of communication device 510 including IMS registration information in the NAS connection request message. Process 600 may proceed from block 610 to block 620.

[0074] In block 620, process 600 may include the processor 512 of communication device 510 sending a NAS connection request message to the network via transceiver 516. Process 600 may proceed from block 620 to block 630.

[0075] In block 630, process 600 may include processor 512 of communication device 510 receiving a NAS connection acceptance message from the network via transceiver 516. The NAS additional acceptance message may include IMS notification information.

[0076] In some embodiments, process 600 may include the processor 512 of communication device 510 receiving, via transceiver 516, an SIB containing an IMS signaling optimization capability indicator from the network. This IMS signaling optimization capability indicator may indicate that the network supports IMS registration optimization.

[0077] In some embodiments, process 600 may include processor 512 of communication device 510 determining not to initiate SIP registration process upon receiving an IMS signaling optimization capability indicator from the network.

[0078] In some embodiments, IMS registration information may include IMS public user identity (IMPU) and / or IMS private identity (IMPI).

[0079] In some embodiments, IMS registration information can be transmitted via NAS signaling over the signaling radio bearer (SRB) on the control plane (CP).

[0080] In some embodiments, the request type for the IMS Packet Data Network (PDN) connection can be set to initial attach (IA) in the NAS attach request message.

[0081] Figure 7 illustrates an example process 700 according to an embodiment of the present invention. Process 700 may be an example implementation of the above-described scenario / scheme, whether in part or in whole, aimed at improving the IMS message flow of the voice service of the present invention. Process 700 may represent one aspect of the functional implementation of communication device 510. Process 700 may include one or more operations, actions, or functions, as shown by one or more modules 710 to 730 in the figure. Although the various modules of process 700 are shown as discrete modules, these modules may be divided into more modules, merged into fewer modules, or deleted, depending on the desired implementation. Furthermore, the various modules of process 700 may be executed in the order shown in Figure 7, or in a different order. Process 700 may be implemented by communication device 510 or any suitable UE or machine type device. For ease of illustration and without limitation, process 700 is described below in the context of communication device 510. Process 700 may begin with block 710.

[0082] In block 710, process 700 may include processor 512 of communication device 510 encoding the SIP INVITE message using a binary encoding scheme to generate an encoded INVITE message. Process 700 may proceed from block 710 to block 720.

[0083] In block 720, process 700 may include the processor 512 of communication device 510 sending an encoded SIP INVITE message to the network via transceiver 516 through NAS UL information transmission signaling. Process 700 may proceed from block 720 to block 730.

[0084] In block 730, process 700 may include processor 512 of communication device 510 receiving SIP response messages encoded using a binary encoding scheme from the network via transceiver 516 through NAS DL information transmission signaling.

[0085] In some embodiments, process 700 may include the processor 512 of communication device 510 transmitting voice media in the form of RTP packets over the default bearer of the IMS PDN connection via transceiver 516 using NIDD.

[0086] In some embodiments, the binary encoding scheme may include the I1 encoding scheme.

[0087] In some embodiments, the dialing number and / or call type indicator indicating a voice or video call in the SIP INVITE message may be encoded by a binary encoding scheme.

[0088] Figure 8 illustrates an example process 800 according to an embodiment of the present invention. Process 800 may be an example implementation of the scenario / scheme described above, whether in part or in whole, as long as it relates to the improved connection release procedure of the present invention. Process 800 may represent one aspect of the functional implementation of network device 520. Process 800 may include one or more operations, actions, or functions, as shown by one or more modules 810 to 830 in the figure. Although the various modules of process 800 are shown as discrete modules, these modules may be split into more modules, merged into fewer modules, or deleted, depending on the desired implementation. Furthermore, the various modules of process 800 may be executed in the order shown in Figure 8, or in a different order. Process 800 may be implemented by network device 520 or any suitable network node or base station. For illustrative purposes only and without limitation, process 800 is described below in the context of network device 520. Process 800 may begin at block 810.

[0089] In block 810, process 800 may include the processor 522 of network device 520 receiving a NAS attach request message containing IMS registration information via transceiver 526. Process 800 may proceed from step 810 to step 820.

[0090] In block 820, process 800 may include the processor 522 of network device 520 performing IMS registration with the core network based on IMS registration information. Process 800 may proceed from step 820 to step 830.

[0091] In block 830, process 800 may include the processor 522 of network device 520 sending a NAS attach accept message containing IMS notification information via transceiver 526.

[0092] In some embodiments, process 800 may include a processor 522 of network device 520 broadcasting an ISB containing an IMS signaling optimization capability indicator via transceiver 526. The IMS signaling optimization capability indicator may instruct network nodes to support IMS registration optimization.

[0093] In some embodiments, the network node includes a mobility management entity (MME).

[0094] In some embodiments, IMS registration information may include at least one of IMS Public User Identity (IMPU) and IMS Private Identity (IMPI).

[0095] In some embodiments, IMS registration information may be received by NAS signaling via a signaling radio bearer (SRB) on the control plane (CP).

[0096] In some embodiments, the request type for the IMS Packet Data Network (PDN) connection can be set to Initial Attach (IA) in the NAS attach request message.

[0097] In some embodiments, process 800 may include the processor 522 of network device 520 receiving a SIP INVITE message encoded using a binary encoding scheme via transceiver 526 through NAS uplink information transmission signaling. In some embodiments, process 800 may include the processor 522 of network device 520 sending a SIP response message encoded using a binary encoding scheme via transceiver 526 through NAS downlink information transmission signaling.

[0098] In some embodiments, process 800 may include a processor 522 of network device 520 receiving voice media in the form of RTP packets over the default bearer of an IMS PDN connection via transceiver 526 using NIDD.

[0099] In some embodiments, process 800 may include the processor 522 of network device 520 configuring the Service Gateway (S-GW) to use NIDD rules.

[0100] In some implementations, the binary encoding scheme may include the I1 encoding scheme.

[0101] Additional Notes The subject matter described in this invention sometimes illustrates different components contained within or connected to other components. It should be understood that the depicted architecture is merely an example, and many other architectures that achieve the same functionality can actually be implemented. Conceptually, any arrangement of components achieving the same function is effectively “associated” to achieve the desired function. Therefore, regardless of the architecture or intermediate components, any two components of this invention combined to achieve a specific function can be considered “associated” with each other to achieve the desired function. Similarly, any two such associated components can also be considered “operationally connected” or “operationally coupled” to achieve the desired function, and any two components that can be suchly associated can also be considered “operationally coupled” to achieve the desired function. Specific examples of operationally coupled components include, but are not limited to: physically mating and / or physically interacting components and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0102] Furthermore, regarding the extensive use of any plural and / or singular terms in this invention, those skilled in the art can, depending on the context and / or application, convert from plural to singular and / or from singular to plural. For clarity, various singular / plural interchanges can be explicitly described in this invention.

[0103] Furthermore, those skilled in the art will understand that, generally, the terminology used in this invention, and especially in the appended claims (e.g., the text of the appended claims), generally means "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will also understand that if a particular number of claims is intentionally enumerated, this intention will be explicitly listed in the claims, and if such enumeration is absent, this intention will not exist. For example, to aid understanding, the appended claims may include the use of the introductory phrases "at least one" and "one or more" that enumerate the claims. However, the use of such phrases should not be interpreted as implying that the introduction of the indefinite article "a" or "an" by a claim list limits any particular claim containing such an introduced claim list to an embodiment containing only one such list, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article (such as "a" or "an"). (For example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles used to introduce claim lists. Furthermore, even when a specific number of introduced claim lists is explicitly listed, those skilled in the art will recognize that such a list should be interpreted as meaning at least the number listed (e.g., in the absence of other modifiers, an unmodified list of "two lists" means at least two lists, or two or more lists). Furthermore, in cases where the convention of "at least one of A, B, and C" is used, this interpretation generally means, as those skilled in the art will understand, that "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. In cases where the convention of "at least one of A, B, or C" is used, this interpretation generally means, as those skilled in the art will understand, that "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. Those skilled in the art will also understand that any transitional words and / or phrases that actually present two or more alternatives, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, any, or both of these items. For example, the phrase “A or B” would be understood to include the possibility of “A” or “B” or “A and B”.

[0104] Based on the foregoing, it will be understood that various embodiments of the invention have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of the invention. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the appended claims.

Claims

1. A method for improving message flow in the Internet Protocol Multimedia Subsystem (IPS) of mobile communications, comprising: The device's processor includes the Internet Protocol Multimedia Subsystem (IMS) registration information in the Non-Access Stratum (NAS) attach request message; The processor sends a NAS attach request message to the network; as well as The processor receives a NAS attach accept message from the network, wherein the NAS attach accept message contains IMS notification information.

2. The method according to claim 1, further comprising: The processor receives a System Information Block (SIB) containing an IMS signaling optimization capability indicator from the network. The IMS signaling optimization capability indicator indicates that the network supports IMS registration optimization.

3. The method according to claim 1, further comprising: Upon receiving the IMS signaling optimization capability indicator from the network, the processor determines not to initiate the Session Initiation Protocol (SIP) registration process.

4. The method of claim 1, wherein, The IMS registration information includes the IMS Public User Identity (IMPU) and / or the IMS Private Identity (IMPI).

5. The method of claim 1, wherein, The IMS registration information is transmitted on the control plane (CP) via the signaling radio bearer (SRB) through NAS signaling.

6. The method of claim 1, wherein, In the NAS attach request message, the request type for the IMS packet data network (PDN) connection is set to Initial Attach (IA).

7. A method for improving message flow in the Internet Protocol Multimedia Subsystem (IPS) of mobile communications, comprising: The device's processor encodes the Session Initiation Protocol (SIP) INVITE message using a binary encoding scheme to generate an encoded INVITE message; The processor sends an encoded SIP INVITE message to the network via Non-Access Stratum (NAS) Uplink (UL) Information Transmission Signaling; and The processor receives a SIP response message encoded using the binary encoding scheme from the network via NAS downlink (DL) information transmission signaling.

8. The method of claim 7, further comprising: The processor uses Non-IP Data Transmission (NIDD) to transmit voice media in Real-Time Transport Protocol (RTP) packets over the default bearer of the Internet Protocol (IP) Multimedia Subsystem (IMS) Packet Data Network (PDN) connection.

9. The method of claim 7, wherein, The binary encoding scheme includes the I1 encoding scheme.

10. The method of claim 7, wherein, The dialing number and / or call type indicator indicating a voice or video call in the SIP INVITE message are encoded by the binary encoding scheme.

11. A method for improving message flow in the Internet Protocol Multimedia Subsystem (IPS) of mobile communications, comprising: The network node's processor receives a Non-Access Stratum (NAS) attach request message containing Internet Protocol Multimedia Subsystem (IMS) registration information; The processor performs IMS registration with the core network based on the IMS registration information; as well as The processor sends a NAS attach accept message containing IMS notification information.

12. The method of claim 11, further comprising: The processor broadcasts a System Information Block (SIB) containing an IMS signaling optimization capability indicator. The IMS signaling optimization capability indicator indicates that the network node supports IMS registration optimization.

13. The method of claim 11, wherein, The network nodes include mobility management entities (MMEs).

14. The method of claim 11, wherein, The IMS registration information includes the IMS Public User Identity (IMPU) and / or the IMS Private Identity (IMPI).

15. The method of claim 11, wherein, The IMS registration information is received by NAS signaling via the Signaling Radio Bearer (SRB) on the control plane (CP).

16. The method of claim 11, wherein, In the NAS attach request message, the request type for the IMS Packet Data Network (PDN) connection is set to Initial Attach (IA).

17. The method of claim 11, further comprising: The processor receives Session Initiation Protocol (SIP) INVITE messages encoded using a binary encoding scheme via Non-Access Stratum (NAS) Uplink (UL) Information Transmission Signaling; as well as The processor sends a SIP response message encoded using the binary encoding scheme via NAS downlink (DL) information transmission signaling.

18. The method of claim 17, further comprising: The processor uses Non-IP Data Transmission (NIDD) to receive voice media in the form of Real-Time Transport Protocol (RTP) packets over the default bearer of the Internet Protocol (IP) Multimedia Subsystem (IMS) Packet Data Network (PDN) connection.

19. The method of claim 17, further comprising: The processor configuration service gateway (S-GW) uses non-IP data transmission (NIDD) rules.

20. The method of claim 17, wherein, The binary encoding scheme includes the I1 encoding scheme.

Images