Methods and apparatus for setting internet protocol multimedia subsystem calls in mobile communications
Patent Information
- Application Number
- PCT/CN2026/085802
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-04-14
- Filing Date
- 2026-03-25
- Publication Date
- 2026-10-22
Smart Images
Figure CN2026085802_22102026_PF_FP_ABST
Abstract
Description
METHODS AND APPARATUS FOR SETTING INTERNET PROTOCOL MULTIMEDIA SUBSYSTEM CALLS IN MOBILE COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION (S)
[0001] The present disclosure is part of a PCT Application claiming the priority benefit of U.S. Patent Application No. 63 / 788,191 filed 14 April 2025, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD
[0002] The present disclosure is generally related to wireless communications and, more particularly, to methods and apparatus for efficient Session Initiation Protocol (SIP) messaging for Internet Protocol Multimedia Subsystem (IMS) calls in mobile communications using satellite access, particularly in Geostationary Earth Orbit (GEO) Non-Terrestrial Network (NTN) environments.BACKGROUND
[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.
[0004] Using mobile phones to make voice calls via satellite access has become increasingly popular as satellite systems provide extensive coverage in rural and remote regions. Within the 3rd Generation Partnership Project (3GPP) standards, satellite voice call services enable consistent network connectivity across both terrestrial and satellite networks, facilitating communication at any time and place.
[0005] Starting from 3GPP Release 17, Geostationary Earth Orbit (GEO) satellite access has been incorporated as a 5G access technology, mainly supporting short message service. However, GEO satellite systems face inherent limitations, such as a long transmission distance of approximately 35, 786 km, one-way signal delays of around 285 milliseconds (ms) , atmospheric attenuation, and constrained data transmission rates that cannot be easily improved by increasing bandwidth. Consequently, several services that can be supported by Low Earth Orbit (LEO) or other Non-Geostationary Satellite Orbit (NGSO) systems may not be feasible over GEO links. For example, the IP Multimedia Subsystem (IMS) voice call service is not directly supported via GEO satellite access due to the low data rate and high latency, which result in unacceptably long IMS call setup time and insufficient bandwidth for conventional IMS voice codecs.
[0006] The Session Initiation Protocol (SIP) , as defined in RFC 3261, provides a comprehensive framework for the use of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) in SIP messaging within IMS. UDP offers low-latency transmission where packet loss is tolerable and is suitable for smaller SIP messages, while TCP provides reliable, ordered delivery with guaranteed message integrity. However, RFC 3261 specifies that if a request is within 200 bytes of the path Maximum Transmission Unit (MTU) , or if it is larger than 1300 bytes and the path MTU is unknown, the request must be sent using an RFC 2914 congestion controlled transport protocol, such as TCP.
[0007] The delay impact on TCP transmission in GEO NTN environments can be significant and is influenced by various factors, including three-way handshake, slow start with acknowledgement, and timeout and retransmission mechanisms. Specifically, the first SIP message transmission is delayed by one Round-Trip Time (RTT) , which ranges from 500 ms to 5 seconds in GEO NTN. Additionally, sending subsequent SIP messages is slowed by waiting for TCP acknowledgements, and the GEO NTN environment, with its variable RTT, causes undesired retransmissions. Consequently, when using TCP for SIP transmission over GEO NTN, the total call setup time can exceed 93 seconds, which is far beyond acceptable user experience standards.
[0008] Hence, an enhanced method for addressing the SIP transport protocol selection is desirable.SUMMARY
[0009] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
[0010] An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issue pertaining to SIP signaling for IMS calls.
[0011] In one aspect, a method may involve a user equipment (UE) determining whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the UE is operating in a restricted network environment. The method may further involve the UE transmitting a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to a network in an event that the network condition determination indicates that the UE is operating in the restricted network environment, regardless of a size of the SIP message.
[0012] In another aspect, a method may involve a network determining whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the network is operating with a user equipment (UE) through a restricted network environment. The method may further involve the network transmitting a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to the UE in an event that the network condition determination indicates that the network is operating with the UE through the restricted network environment, regardless of a size of the SIP message.
[0013] It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as LTE, LTE-Advanced, LTE-Advanced Pro, 5G, NR, 5G-Advanced, Internet-of-Things (IoT) , Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , beyond 5G (B5G) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s) / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale, as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.
[0015] FIGs. 1A and 1B illustrate two schematic system diagrams that illustrate two example 3rd Generation Partnership Project (3GPP) NTN (Non-Terrestrial Network) architectures in accordance with aspects of the present disclosure.
[0016] FIG. 2 illustrates an example scenario of SIP messaging for an IMS call initiated by a UE in accordance with an implementation of the present disclosure.
[0017] FIG. 3 illustrates another example scenario of SIP messaging for an IMS call initiated by a network in accordance with an implementation of the present disclosure.
[0018] FIG. 4 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.
[0019] FIG. 5 is a flowchart of an example process in accordance with an implementation of the present disclosure.
[0020] FIG. 6 is a flowchart of another example process in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS
[0021] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview
[0022] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to SIP signaling for IMS calls. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.
[0023] The techniques described in the disclosure may be applied to a variety of telecommunication systems utilizing IMS communication services, such as current 4G and 5G communications systems, or a next-generation communications system (e.g., 6G) . The IMS media described in the disclosure are not limited to voice but also include any real-time media types such as video, text, and applications. The UEs involved in the disclosure are not limited to mobile phones but can also include any device capable of providing IMS communication services, such as wearable devices, vehicular devices, Internet of Things (IoT) devices, and so on.
[0024] FIGs. 1A and 1B illustrate two schematic system diagrams that illustrate two example 3rd Generation Partnership Project (3GPP) NTN (Non-Terrestrial Network) architectures in accordance with aspects of the present disclosure.
[0025] FIG. 1A illustrates an NTN architecture in which the GEO satellite 102 does not include on-board processing capabilities, such as base station functionalities and / or core network (CN) functionalities. In this configuration, the GEO satellite 102 operates primarily as a relay node. Taking the UE transmission (Tx) direction as an example, the UE 101 on the ground first transmits data to the GEO satellite 102 through the service link 111. The GEO satellite 102 then forwards the data to a gateway 103 through the feeder link 112. After reaching the terrestrial network, the data is processed by a base station (BS) 104 via link 113, a core network 105 via link 114, and finally arrives at the IMS server 106 via link 115. The core network 105 may correspond to an evolved packet core (EPC) in a 4G communications system, a 5G core (5GC) in a 5G communications system, or a 6G core (6GC) in a 6G communications system.
[0026] FIG. 1B illustrates an NTN architecture in which the GEO satellite 102 is equipped with full CN functionalities, and may additionally include IMS functionalities on board. In this configuration, the communication path between the UE 101 and the IMS server 106 includes at least one GEO service link 111, and the IMS server 106 may be deployed directly on the GEO satellite 102.
[0027] It should be noted that the present disclosure is not limited to the NTN architectures illustrated in FIGS. 1A and 1B. Rather, the present disclosure may also be applied to other NTN configurations in which one or more satellites function as intermediary nodes along the data path between the UE and the IMS server.
[0028] FIG. 2 illustrates an example scenario of SIP messaging for an IMS call in accordance with an implementation of the present disclosure.
[0029] In this scenario, the UE 101 is configured to communicate with a network through different transport protocols, i.e., UDP and TCP. A UE (e.g., UE 101) may use GEO satellite access to perform a mobile-originated (MO) or a mobile-terminated (MT) IMS call with the network in accordance with an implementation of the present disclosure. In one or more embodiments, the UE transmits SIP messages to the network, and the network responds with corresponding SIP messages to complete the SIP signaling for establishing, updating, or terminating an IMS call. Conversely, the network may initiate the signaling by transmitting SIP messages to the UE, and the UE subsequently responds with appropriate SIP messages to complete the SIP signaling procedure for the IMS call.
[0030] The SIP messages optimized under this disclosure include, but are not limited to: REGISTER, INVITE, re-INVITE, UPDATE, 100 Trying, 183 Session Progress, PRACK, 200 OK, 180 Ringing, and ACK messages.
[0031] The network may include at least one of an IMS server, a Proxy Call Session Control Function (P-CSCF) , an Interrogating CSCF (I-CSCF) , a Serving CSCF (S-CSCF) , and a core network entity, such as a Home Subscriber Server (HSS) in 4G LTE or an access and mobility management function (AMF) in 5G NR.
[0032] Step 201: The UE 101 performs a network condition determination to determine whether it is operating within a restricted network environment. The restricted network environment may be characterized by at least one of a bit rate threshold (e.g., a first threshold) , a latency threshold (e.g., a second threshold) , or a constraint on call setup time. Exemplary restricted network environments include Geostationary Earth Orbit (GEO) satellite networks or Non-Terrestrial Networks (NTN) .
[0033] Note that in an optional implementation, the UE may perform network condition determination based on an explicit indication or an implicit indication from the network (including at least one of radio access network, core network, or IMS network) .
[0034] For example, the network condition determination may be based on at least one of: (a) an indication that IMS service is to be utilized over a long-latency network; (b) broadcasted system information received by the UE; (c) an indication within a received downlink Radio Resource Control (RRC) message; (d) an indication within a received downlink Non-Access Stratum (NAS) message; (e) at least one UE implementation parameter; (f) pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ; (g) a type of attached network; (h) a device type or UE usage setting; (i) a Subscriber Identity Module (SIM) card profile; and (j) runtime measurement data.
[0035] In some implementations, the system information comprises at least one of SystemInformationBlockType1-NB, SystemInformationBlockType2-NB, or SystemInformationBlockType3-NB. These specific blocks may be generally represented or categorized using the format SystemInformationBlockTypeXYZ-NB, wherein XYZ serves as a placeholder for a specific numerical or alphanumeric identifier.
[0036] Step 202A: In response to determining that the UE 101 is operating in a restricted network environment, the UE 101 transmits a SIP message over User Datagram Protocol (UDP) to the network. Notably, this UDP transmission is performed regardless of the size of the SIP message, thereby deviating from conventional RFC 3261 requirements that mandate Transmission Control Protocol (TCP) for messages exceeding 1300 bytes.
[0037] Step 202B: As illustrated in dashed lines, as an alternative, an approach is shown where SIP message transmission is performed over UDP or TCP based on message size. Under such operation, TCP would be utilized for messages larger than 1300 bytes, introducing significant latency in GEO NTN environments due to the TCP three-way handshake, acknowledgement wait times, and retransmission mechanisms.
[0038] By forcing UDP transmission in restricted network environments (step 202A) instead of applying size-based protocol selection (step 202B) , the present disclosure eliminates TCP-associated overhead, thereby significantly reducing call setup time in high-latency scenarios.
[0039] Note that 1300 bytes is a threshold on message size and may be modified according to development of the network and standardization works.
[0040] FIG. 3 is a schematic diagram illustrating another exemplary scenario of SIP messaging for an IMS call, initiated by the network in accordance with an implementation of the present disclosure. Similar to FIG. 2, this scenario involves communication between the UE 101 and the network through alternative communication paths.
[0041] Step 301: The network performs a network condition determination to determine whether it is operating with the UE through a restricted network environment. Note that in an optional implementation, the network may perform network condition determination may be based on an explicit indication or an implicit indication from the UE (including at least one of radio access network, core network, or IMS network) . For example, this determination may be based on or responsive to criteria identical to those described for the UE-initiated scenario, including long-latency indications, broadcast system information, or RRC / NAS signaling.
[0042] Step 302A: Based on the determination that the network is operating with the UE through a restricted network environment, the network transmits a SIP message over UDP to the UE 101. Consistent with FIG. 2, this UDP transmission is performed regardless of the size of the SIP message, avoiding the latency penalties inherent to TCP in high-latency environments.
[0043] Step 302B (illustrated in dashed lines) : This operation represents an approach where the network would perform SIP message transmission over UDP or TCP based on message size, leading to prolonged call setup times for large messages in GEO NTN scenarios.
[0044] The network-side implementation (FIG. 3) complements the UE-side implementation (FIG. 2) , ensuring bilateral transport protocol optimization based on network conditions. This ensures consistent protocol behavior regardless of which party initiates the SIP signaling, providing a comprehensive solution for IMS call setup optimization.
[0045] In some implementations, the network condition determination may be based on: a. explicit indication of network environment; b. implicit indication of network environment; or c. pre-configured setting for network environment determination.
[0046] In one or more embodiments, the determination of the network environment is based on an explicit indication received from the network. The user equipment (UE) is configured to receive a specific flag or information element (IE) via broadcast system information (e.g., a System Information Block or SIB) , a downlink Radio Resource Control (RRC) message, or a Non-Access Stratum (NAS) message. For instance, in a Geostationary Earth Orbit (GEO) satellite network, the base station or the core network may transmit a dedicated indication signifying that Internet Protocol Multimedia Subsystem (IMS) services are to be conducted over a long-latency network. Upon detecting such an explicit indication, the UE identifies the current network state as a restricted network environment and adjusts its communication behavior, such as by bypassing conventional transport protocol selection rules to utilize User Datagram Protocol (UDP) for all Session Initiation Protocol (SIP) signaling.
[0047] In some embodiments, the UE implicitly determines the network condition by evaluating observed network characteristics or performance metrics. This implicit determination may be based on identifying a type of the attached network, such as a Public Land Mobile Network (PLMN) or a network slice instance associated with a satellite service provider. Alternatively, the UE may analyze runtime measurement data, such as a measured Round-Trip Time (RTT) that exceeds a predefined temporal threshold (e.g., 540 ms) . Even in the absence of a direct flag from the network, if the UE observes characteristics consistent with a low-bit-rate, long-latency, or bandwidth-constrained network, it autonomously classifies the environment as a restricted network environment. Consequently, the UE may initiate signaling optimizations, including dynamic SIP timer adjustments and protocol forcing (using UDP for SIP message transmission) , to mitigate the impact of the high-latency environment on IMS call setup efficiency.
[0048] In further embodiments, the network condition determination is performed based on pre-configured settings or internal device parameters. The UE may retrieve pre-configured information stored within the device or a Universal Subscriber Identity Module (USIM) , such as a SIM card profile, a specific device type designation, a service type, or a UE usage setting. For example, a UE implementation parameter may designate the device as a dedicated satellite terminal, or the USIM may contain a profile specifically optimized for non-terrestrial network (NTN) operations. By matching its hardware profile or subscriber identity against these pre-configured parameters, the UE determines it is operating within a restricted network environment. This allows the UE to apply protocol optimizations-such as the prioritization of UDP over TCP regardless of SIP message size-immediately upon network attachment for SIP message transmission, ensuring reliable session establishment based on the device's inherent configuration.
[0049] Reliable transmission for SIP messages may be supported by at least one of: a SIP protocol layer mechanism, a 3GPP Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) procedure, a 3GPP Radio Link Control (RLC) Acknowledged Mode (AM) , or a 3GPP Packet Data Convergence Protocol (PDCP) mechanism. These lower-layer mechanisms provide an alternative to TCP reliability while avoiding TCP-specific latency overhead.
[0050] In various implementations, both the UE and the network may adjust SIP timer values based on Round-Trip Time (RTT) measurements in the restricted network environment. For example, the T1 timer value may be dynamically adjusted based on RTT measured from past SIP message handshakes or Real-time Transport Control Protocol (RTCP) results, preventing unnecessary retransmissions while ensuring reliable delivery.
[0051] 3GPP Technical Specification (TS) 24.229 lists SIP timers defined in RFC 3261, RFC 6026, and RFC 6665. Different timer values can be set to accommodate the air interface delays. Different scenarios with different air interfaces may be represented by values of P-Access-Network-Info header field in requests or responses, such as “3GPP-NR-SAT” , “3GPP-NR-LEO” , “3GPP-NR-MEO” , “3GPP-NR-GEO” , “3GPP-NR-OTHERSAT” , “3GPP-WB-E-UTRAN-LEO” , “3GPP-WB-E-UTRAN-MEO” , “3GPP-WB-E-UTRAN-GEO” , “3GPP-WB-E-UTRAN-OTHERSAT” , “3GPP-NB-IoT-LEO” , “3GPP-NB-IoT-MEO” , “3GPP-NB-IoT-GEO” , “3GPP-NB-IoT-OTHERSAT” , “3GPP-LTE-M-LEO” , “3GPP-LTE-M-MEO” , “3GPP-LTE-M-GEO” , “3GPP-LTE-M-OTHERSAT” . One or more values may be set for the satellite network or the NTN in accordance with the method of the disclosure. The following Table 1 shows the SIP timers:
[0052] Table 1: SIP timers
[0053] The timers T1, T2, T4 A, B, C, D, E, F, G, H and I (defined in RFC 3261) , timers L and M (defined in RFC 6026) , and timer N (defined in RFC 6665) need modification in some cases to accommodate the delays introduced by the air interface processing and transmission delays in satellite network or NTN.
[0054] In some implementations, the method may further involve adjusting SIP timer values based on Round-Trip Time (RTT) measurements in the restricted network environment. The dynamic timer adjustment mechanism addresses the challenge that GEO NTN environments exhibit significantly longer and more variable RTT compared to terrestrial networks. Conventional SIP timer values, which are optimized for terrestrial networks with RTT typically under 100 ms, are inadequate for GEO NTN scenarios where RTT can range from 500 ms to over 5 seconds depending on satellite position, atmospheric conditions, and network congestion.
[0055] Specifically, the SIP timer adjustment may involve modifying the T1 timer value, which represents the RTT estimate as defined in RFC 3261. The default T1 value is 500 ms for terrestrial networks, but this value is insufficient for GEO NTN environments. According to the present disclosure, the processor of the UE or network apparatus dynamically adjusts the T1 timer value based on the actual measured RTT in the restricted network environment. For example, if the measured RTT in a GEO NTN environment is 1200 ms, the T1 timer may be adjusted from the default 500 ms to 1200 ms or slightly higher (e.g., 1500 ms) to account for RTT variation.
[0056] In addition to the T1 timer, the method may also adjust other SIP timers whose values are defined as multiples of T1. These timers include: a. Timer A: Initially set to T1, used for INVITE request retransmit interval for UDP only; b. Timer B: Set to 64×T1, used for INVITE transaction timeout timer; c. Timer D: Set to greater than 32 seconds for UDP, used for wait time for response retransmits; d. Timer E: Initially set to T1, used for non-INVITE request retransmit interval for UDP only; e. Timer F: Set to 64×T1, used for non-INVITE transaction timeout timer; f. Timer G: Initially set to T1, used for INVITE response retransmit interval; g. Timer H: Set to 64×T1, used for wait time for ACK receipt; h. Timer I: Set to T4 for UDP, used for wait time for ACK retransmits; i. Timer J: Set to 64×T1 for UDP, used for wait time for non-INVITE request retransmits; j. Timer K: Set to T4 for UDP, used for wait time for response retransmits; k. Timer L: Set to 64×T1, used for wait time for accepted INVITE request retransmits; l. Timer M: Set to 64×T1, used for wait time for retransmission of 2xx to INVITE; and m. Timer N: Set to 64×T1, used for wait time for receipt of NOTIFY request upon sending SUBSCRIBE.
[0057] By adjusting T1 based on the measured RTT, all dependent timers are automatically scaled proportionally, ensuring that the entire SIP state machine operates appropriately for the high-latency GEO NTN environment.
[0058] The RTT measurement for timer adjustment may be obtained through multiple mechanisms. In a first approach, the RTT may be measured based on past SIP message handshakes. For example, when the UE sends a SIP INVITE message and receives a 100 Trying response, the time difference between transmission and reception provides an RTT measurement. The processor may maintain a moving average or exponentially weighted moving average (EWMA) of multiple RTT samples from recent SIP transactions to obtain a stable RTT estimate that accounts for network variability.
[0059] In a second approach, the RTT may be measured based on Real-time Transport Control Protocol (RTCP) measurement results. RTCP, as defined in RFC 3550, is used alongside Real-time Transport Protocol (RTP) for monitoring media transmission quality. RTCP Sender Reports (SR) and Receiver Reports (RR) contain timestamps that enable RTT calculation between media endpoints. Since RTCP measurements are continuously performed during an active IMS voice call, they provide real-time RTT information that reflects current network conditions. The processor may leverage these RTCP-derived RTT measurements to adjust SIP timer values not only for the current call but also for subsequent call attempts.
[0060] In a third approach, the RTT measurement may combine both SIP-based and RTCP-based measurements. The processor may use SIP message handshake RTT during the call setup phase (before media transmission begins) and then refine the RTT estimate using RTCP measurements once media is flowing. This hybrid approach provides both early estimation for timer adjustment during call setup and continuous refinement during the call.
[0061] The dynamic timer adjustment provides several technical benefits. First, it prevents premature timeout and unnecessary retransmissions that would occur if default timer values were used in high-latency environments. Unnecessary retransmissions not only waste limited bandwidth in GEO NTN but also contribute to network congestion. Second, by adapting to actual network conditions, the method avoids excessively long timer values that would delay error detection and recovery when a message is genuinely lost. Third, the use of passive RTT measurement (from regular SIP transactions and RTCP) eliminates the need for active probing mechanisms that would introduce additional overhead.
[0062] In some implementations, the processor may store multiple RTT profiles corresponding to different network types or satellite configurations.
[0063] When the UE attaches to a network or receives system information indicating the network type, it may initialize T1 with the appropriate profile value and then refine it through RTT measurements. This approach provides reasonable timer values immediately upon network attachment while still benefiting from measurement-based adaptation.
[0064] The timer adjustment mechanism may be coordinated between the UE and the network. In some implementations, the network (e.g., IMS server or P-CSCF) may include recommended timer values in SIP messages or configuration messages sent to the UE. For example, the network may include a vendor-specific header or parameter (with recommended timer values) in the SIP 200 OK response to a REGISTER message.
[0065] The UE processor, upon receiving this recommendation, may adopt the suggested T1 value or use it as one input among others (including its own measurements) to determine the optimal timer value. This coordination ensures that both endpoints use compatible timer values, reducing the likelihood of asymmetric timeout behavior.
[0066] In implementations where both the UE and the network perform dynamic timer adjustment, race conditions or inconsistencies may be avoided through the following rules. a. The initiating party (caller or callee) uses its locally adjusted timer values for transactions it initiates. b. The responding party uses its locally adjusted timer values for retransmission of responses. c. Both parties update their RTT estimates based on observed transaction timing, leading to convergence over multiple transactions. d. In case of significant discrepancy, the longer of the two timer values prevails, ensuring that neither party times out prematurely.
[0067] The timer adjustment mechanism is backward compatible with conventional SIP implementations. If a UE operating in a GEO NTN environment communicates with a legacy network element that does not support dynamic timer adjustment, the UE’s use of longer timer values simply means it will wait longer before retransmitting or timing out. The legacy network element will operate with its default timer values, which may result in retransmissions, but the overall SIP transaction will still complete successfully. The benefit of reduced retransmissions is partially realized even in such mixed scenarios.
[0068] The proposed methods achieve several significant technical improvements by optimizing transport layer interactions and signaling protocols for high-latency environments. Specifically, the elimination of TCP three-way handshake latency reduces initial connection overhead by one round-trip time (RTT) , which represents a temporal saving of 500 ms to 5 seconds in GEO NTN environments. By removing the requirement for TCP acknowledgement wait times, the system enables more rapid transmission of sequential SIP messages. This avoids traditional TCP timeout and retransmission issues that typically degrade performance in variable-latency GEO scenarios.
[0069] Furthermore, the methods incorporate dynamic SIP timer adjustments based on measured RTT. This optimization prevents unnecessary retransmissions of signaling packets while ensuring reliable delivery across the network. The cumulative effect of these technical enhancements is a substantial reduction in overall IP Multimedia Subsystem (IMS) call setup time, which is decreased from over 93 seconds to under 30 seconds in GEO NTN scenarios. As a result, user experience is improved through a significantly reduced delay between the moment of call acceptance and the actual establishment of voice communication.
[0070] It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as LTE, LTE-Advanced, LTE-Advanced Pro, 5G, NR, 5G-Advanced, Internet-of-Things (IoT) , Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , beyond 5G (B5G) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s) / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein. Illustrative Implementations
[0071] FIG. 4 illustrates an example communication system 400 having at least an example communication apparatus 410 and an example network apparatus 420 in accordance with an implementation of the present disclosure. Each of the communication apparatus 410 and network apparatus 420 may perform various functions to implement schemes, techniques, processes, and methods described herein of SIP signaling for IMS calls, including scenarios / schemes described above, as well as processes 500, 600, and 700 described below.
[0072] Communication apparatus 410 may be a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus, or a computing apparatus. For instance, communication apparatus 410 may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer, or a notebook computer. Communication apparatus 410 may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, or IIoT apparatus, such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus, or a computing apparatus. For instance, communication apparatus 410 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker, or a home control center. Alternatively, communication apparatus 410 may be implemented in the form of one or more integrated-circuit (IC) chips, such as, for example, and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. Communication apparatus 410 may include at least some of those components shown in FIG. 4, such as a processor 412, for example. Communication apparatus 410 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device, and / or user interface device) , and, thus, such component (s) of communication apparatus 410 are neither shown in FIG. 4 nor described below in the interest of simplicity and brevity.
[0073] Network apparatus 420 may be a part of a network apparatus, which may be a network node such as an IMS server, a media server, a P-CSCF, an I-CSCF, an S-CSCF, an AMF, an HSS, a satellite, a base station, a small cell, a router, or a gateway. For instance, network apparatus 420 may be implemented in an eNB in an LTE network, in a gNB in a 5G / NR, IoT, NB-IoT or IIoT network, or in a satellite or base station in a 6G network. Network apparatus 420 may include at least some of those components shown in FIG. 4, such as a processor 422, for example. Processor 422 may further include protocol stacks and a set of control functional modules and circuits. Network apparatus 420 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of network apparatus 420 are neither shown in FIG. 4 nor described below in the interest of simplicity and brevity.
[0074] In one aspect, each of the processor 412 and processor 422 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 412 and processor 422, each of the processor 412 and processor 422 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of the processor 412 and processor 422 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of the processor 412 and processor 422 is a special-purpose machine specifically designed, arranged, and configured to perform specific tasks in a device (e.g., as represented by communication apparatus 410) and a network (e.g., as represented by network apparatus 420) in accordance with various implementations of the present disclosure.
[0075] In some implementations, communication apparatus 410 may also include a memory 414 coupled to processor 412 and capable of being accessed by processor 412 and storing data therein. In some implementations, communication apparatus 410 may further include a transceiver 416 coupled to processor 412 and capable of wirelessly transmitting and receiving data. In some implementations, transceiver 416 may be capable of wirelessly communicating with different types of UEs and / or wireless networks of different RATs, e.g., 2G GSM, 3G UMTS, 4G LTE, 5G NR, and / or 6G.
[0076] In some implementations, network apparatus 420 may further include a memory 424 coupled to processor 422 and capable of being accessed by processor 422 and storing data therein, and a transceiver 426 coupled to processor 422 and capable of wirelessly transmitting and receiving data. Accordingly, communication apparatus 410 and network apparatus 420 may wirelessly communicate with each other via transceiver 416 and transceiver 426, respectively.
[0077] For illustrative purposes and without limitation, descriptions of capabilities of the communication apparatus 410 and network apparatus 420 are provided below with process 500, process 600, and process 700. In which, communication apparatus 410 is implemented in or as a communication apparatus or a UE, and network apparatus 420 is implemented in or as a network node of a communication network (e.g., an IMS server, or a proxy-CSCF (P-CSCF) ) . Illustrative Processes
[0078] FIG. 5 illustrates an example process 500 in accordance with an implementation of the present disclosure. Process 500 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting an IMS call. Process 500 may represent an aspect of the implementation of features of communication apparatus 410. Process 500 may include one or more operations, actions, or functions as illustrated by one or more of blocks 510 and 520. Although illustrated as discrete blocks, various blocks of process 500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 500 may be executed in the order shown in FIG. 5 or, alternatively, in a different order. Process 500 may be implemented by communication apparatus 410 or any suitable UE (e.g., UE 101) or machine-type devices. Solely for illustrative purposes and without limitation, process 500 is described below in the context of communication apparatus 410 as a UE. Process 500 may begin at block 510.
[0079] At block 510, process 500 may involve processor 412 of communication apparatus 410 determining whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the UE is operating in a restricted network environment. Process 500 may proceed from block 510 to block 520.
[0080] At block 520, process 500 may involve processor 412 transmitting, via transceiver 416, a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to a network in an event that the network condition determination indicates that the UE is operating in the restricted network environment, regardless of a size of the SIP message.
[0081] In some implementations, the restricted network environment comprises at least one of a first threshold on bit rate, a second threshold on latency, or a constraint on call setup time.
[0082] In some implementations, the restricted network environment comprises a Geostationary Earth Orbit (GEO) satellite network or a Non-Terrestrial Network (NTN) .
[0083] In some implementations, the network condition determination is based on one or more of the following: an IMS service is to be used over a long latency network; broadcasted system information received by the UE; an indication in a received downlink Radio Resource Control (RRC) message; an indication in a received downlink Non-Access Stratum (NAS) message; at least one UE implementation parameter; pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ; a type of attached network; a device type or UE usage setting; a Subscriber Identity Module (SIM) card profile; and runtime measurement data.
[0084] In some implementations, process 500 may involve processor 412 transmitting, via transceiver 416, the SIP message using UDP in the restricted network environment in an event that the size of the SIP message is larger than a threshold. Furthermore, process 500 may involve processor 412 transmitting, via transceiver 416, the SIP message using Transmission Control Protocol (TCP) in a terrestrial network in an event that the size of the SIP message is larger than the threshold.
[0085] In some implementations, process 500 may involve processor 412 adjusting a SIP timer value based on a Round-Trip Time (RTT) in the restricted network environment.
[0086] In some implementations, the SIP timer comprises at least one of a T1 timer or a timer with a value being set to a multiple of a T1 timer value, and wherein the RTT is measured based on at least one of past SIP message handshakes and Real-time Transport Control Protocol (RTCP) measurement results.
[0087] In some implementations, process 500 may involve processor 412 performing reliable transmission for the SIP message, wherein reliable transmission for the SIP message is supported by one or more of: a SIP protocol layer mechanism; a 3rd Generation Partnership Project (3GPP) Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) procedure; a 3GPP Radio Link Control (RLC) Acknowledged Mode (AM) ; and a 3GPP Packet Data Convergence Protocol (PDCP) layer mechanism.
[0088] In some implementations, the SIP message comprises at least one of: INVITE, re-INVITE, UPDATE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK.
[0089] FIG. 6 illustrates an example process 600 in accordance with an implementation of the present disclosure. Process 600 may be an example implementation of the above scenarios / schemes, whether partially or completely, with respect to setting an IMS call. Process 600 may represent an aspect of the implementation of features of network apparatus 420. Process 600 may include one or more operations, actions, or functions as illustrated by one or more of blocks 610 and 620. Although illustrated as discrete blocks, various blocks of process 600 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 600 may be executed in the order shown in FIG. 6 or, alternatively, in a different order. Process 600 may be implemented by network apparatus 420 or any network entity in the 4G, 5G, or 6G network, including a base station, an IMS server, a media server, a P-CSCF, an I-CSCF, an S-CSCF, an AMF, or an HSS. Solely for illustrative purposes and without limitation, process 600 is described below in the context of network apparatus 420. Process 600 may begin at block 610.
[0090] At block 610, process 600 may involve processor 422 of network apparatus 420 determining whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the network is operating with a user equipment (UE) through a restricted network environment. Process 600 may proceed from block 610 to block 620.
[0091] At block 620, process 600 may involve processor 422 transmitting, via transceiver 426, a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to the UE in an event that the network condition determination indicates that the network is operating with UE through the restricted network environment, regardless of a size of the SIP message.
[0092] In some implementations, the restricted network environment comprises at least one of a first threshold on bit rate, a second threshold on latency, or a constraint on call setup time.
[0093] In some implementations, the restricted network environment comprises a Geostationary Earth Orbit (GEO) satellite network or a Non-Terrestrial Network (NTN) .
[0094] In some implementations, the network condition determination is indicated in or responsive to one or more of the following: an IMS service is to be used over a long latency network; system information broadcasted by the network; an indication in a downlink Radio Resource Control (RRC) message; an indication in a downlink Non-Access Stratum (NAS) message; at least one UE implementation parameter; pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ; a type of attached network; a device type or UE usage setting; a Subscriber Identity Module (SIM) card profile; and runtime measurement data.
[0095] In some implementations, process 600 may further involve processor 422 transmitting, via transceiver 426, the SIP message using UDP through the restricted network environment in an event that the size of the SIP message is larger than a threshold. Process 600 may further involve processor 422 transmitting, via transceiver 426, the SIP message using Transmission Control Protocol (TCP) through a terrestrial network in an event that the size of the SIP message is larger than the threshold.
[0096] In some implementations, process 600 may involve processor 422 adjusting a SIP timer value based on a Round-Trip Time (RTT) in the restricted network environment.
[0097] In some implementations, the SIP timer comprises at least one of a T1 timer or a timer with a value being set to a multiple of a T1 timer value, wherein the RTT is measured based on at least one of past SIP message handshakes and Real-time Transport Control Protocol (RTCP) measurement results.
[0098] In some implementations, process 600 may involve processor 422 performing reliable transmission for the SIP message, wherein reliable transmission for the SIP message is supported by one or more of: a SIP protocol layer mechanism; a 3rd Generation Partnership Project (3GPP) Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) procedure; a 3GPP Radio Link Control (RLC) Acknowledged Mode (AM) ; and a 3GPP Packet Data Convergence Protocol (PDCP) layer mechanism.
[0099] In some implementations, the SIP message comprises at least one of: INVITE, re-INVITE, UPDATE, 100 Trying, 183 Session Progress, PRACK, 200 OK, UPDATE, 180 Ringing, or ACK. Additional Notes
[0100] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact, many other architectures can be implemented that achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected” , or “operably coupled” , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being “operably couplable” , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.
[0101] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.
[0102] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an, ” e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of “two recitations, ” without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”
[0103] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
Claims
1.A method, comprising:determining, by a processor of a user equipment (UE) , whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the UE is operating in a restricted network environment; andtransmitting, by the processor, a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to a network in an event that the network condition determination indicates that the UE is operating in the restricted network environment, regardless of a size of the SIP message.2.The method of claim 1, wherein the restricted network environment comprises at least one of a first threshold on bit rate, a second threshold on latency, or a constraint on call setup time.3.The method of claim 1, wherein the restricted network environment comprises a Geostationary Earth Orbit (GEO) satellite network or a Non-Terrestrial Network (NTN) .4.The method of claim 1, wherein the network condition determination is based on one or more of the following:an IMS service is to be used over a long latency network;broadcasted system information received by the UE;an indication in a received downlink Radio Resource Control (RRC) message;an indication in a received downlink Non-Access Stratum (NAS) message;at least one UE implementation parameter;pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ;a type of attached network;a device type or UE usage setting;a Subscriber Identity Module (SIM) card profile; andruntime measurement data.5.The method of claim 1, further comprising:transmitting, by the processor, the SIP message using UDP in the restricted network environment in an event that the size of the SIP message is larger than a threshold; ortransmitting, by the processor, the SIP message using Transmission Control Protocol (TCP) in a terrestrial network in an event that the size of the SIP message is larger than the threshold.6.The method of claim 1, further comprising:adjusting, by the processor, a SIP timer value based on a Round-Trip Time (RTT) in the restricted network environment.7.The method of claim 6, wherein the SIP timer comprises at least one of a T1 timer or a timer with a value being set to a multiple of a T1 timer value, and wherein the RTT is measured based on at least one of past SIP message handshakes and Real-time Transport Control Protocol (RTCP) measurement results.8.The method of claim 1, further comprising:performing, by the processor, reliable transmission for the SIP message, wherein reliable transmission for the SIP message is supported by one or more of:a SIP protocol layer mechanism;a 3rd Generation Partnership Project (3GPP) Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) procedure;a 3GPP Radio Link Control (RLC) Acknowledged Mode (AM) ; anda 3GPP Packet Data Convergence Protocol (PDCP) layer mechanism.9.A method, comprising:determining, by a processor of a network, whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the network is operating with a user equipment (UE) through a restricted network environment; andtransmitting, by the processor, a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to the UE in an event that the network condition determination indicates that the network is operating with the UE through the restricted network environment, regardless of a size of the SIP message.10.The method of claim 9, wherein the restricted network environment comprises at least one of a first threshold on bit rate, a second threshold on latency, or a constraint on call setup time.11.The method of claim 9, wherein the restricted network environment comprises a Geostationary Earth Orbit (GEO) satellite network or a Non-Terrestrial Network (NTN) .12.The method of claim 9, wherein the network condition determination is indicated in or responsive to one or more of the following:an IMS service is to be used over a long latency network;system information broadcasted by the network;an indication in a downlink Radio Resource Control (RRC) message;an indication in a downlink Non-Access Stratum (NAS) message;at least one UE implementation parameter;pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ;a type of attached network;a device type or UE usage setting;a Subscriber Identity Module (SIM) card profile; andruntime measurement data.13.The method of claim 9, further comprising:transmitting, by the processor, the SIP message using UDP through the restricted network environment in an event that the size of the SIP message is larger than a threshold; ortransmitting, by the processor, the SIP message using Transmission Control Protocol (TCP) through a terrestrial network in an event that the size of the SIP message is larger than the threshold.14.The method of claim 9, further comprising:adjusting, by the processor, a SIP timer value based on a Round-Trip Time (RTT) in the restricted network environment.15.The method of claim 14, wherein the SIP timer comprises at least one of a T1 timer or a timer with a value being set to a multiple of a T1 timer value, wherein the RTT is measured based on at least one of past SIP message handshakes and Real-time Transport Control Protocol (RTCP) measurement results.16.The method of claim 9, further comprising:performing, by the processor, reliable transmission for the SIP message, wherein reliable transmission for the SIP message is supported by one or more of:a SIP protocol layer mechanism;a 3rd Generation Partnership Project (3GPP) Medium Access Control (MAC) Hybrid Automatic Repeat Request (HARQ) procedure;a 3GPP Radio Link Control (RLC) Acknowledged Mode (AM) ; anda 3GPP Packet Data Convergence Protocol (PDCP) layer mechanism.17.An apparatus, comprising:a transceiver which, during operation, communicates wirelessly; anda processor communicatively coupled to the transceiver such that, during operation, the processor performs operations comprising:determining whether to use User Datagram Protocol (UDP) for transmitting Session Initiation Protocol (SIP) messages based on a network condition determination, wherein the network condition determination comprises determining whether the UE is operating in a restricted network environment; andtransmitting, via the transceiver, a SIP message using UDP for an Internet Protocol Multimedia Subsystem (IMS) call to a network in an event that the network condition determination indicates that the UE is operating in the restricted network environment, regardless of a size of the SIP message.18.The apparatus of claim 17, wherein the restricted network environment comprises at least one of a first threshold on bit rate, a second threshold on latency, or a constraint on call setup time.19.The apparatus of claim 17, wherein the restricted network environment comprises a Geostationary Earth Orbit (GEO) satellite network or a Non-Terrestrial Network (NTN) .20.The apparatus of claim 17, wherein the network condition determination is based on one or more of the following:an IMS service is to be used over a long latency network;broadcasted system information received by the UE;an indication in a received downlink Radio Resource Control (RRC) message;an indication in a received downlink Non-Access Stratum (NAS) message;at least one UE implementation parameter;pre-configured information stored in the UE or a Universal Subscriber Identity Module (USIM) ;a type of attached network;a device type or UE usage setting;a Subscriber Identity Module (SIM) card profile; andruntime measurement data.