CN119999329A - Packet aggregation for enhanced UE to NTN voice operations - Google Patents

Abstract

A User Equipment (UE) is configured to determine a real-time transport protocol (RTP) packet size, determine to aggregate one or more voice packets into an RTP packet based on the RTP packet size, determine a number of the one or more voice packets, and transmit the RTP packet including the number of the one or more voice packets.

Description

Packet aggregation for enhanced UE to NTN voice operations

Background Art

A non-terrestrial network (NTN) refers to a network or network segment that uses an airborne or spaceborne vehicle for transmission. NTNs may provide NTN cells that provide wider coverage than terrestrial network (TN) cells. In some cases, the coverage area of a single NTN may span multiple countries.

NTNs typically have greater latency, lower throughput, and a larger coverage area than TNs. Despite these tradeoffs, NTNs can be used to address mobile broadband and security needs in areas that are underserved by TNs. NTNs can conceivably be used in maritime, aviation, rail, and rural/wilderness use cases.

The existing NTN has poor support for voice services. Therefore, it is necessary to enhance the NTN voice operation to improve the mobile broadband and security experience of users on the NTN network.

Summary of the invention

Some exemplary embodiments relate to a method performed by a user equipment (UE). The method includes: determining a real-time transport protocol (RTP) packet size; determining to aggregate one or more voice packets into an RTP packet based on the RTP packet size; determining a number of the one or more voice packets; and sending the RTP packet including the number of the one or more voice packets.

Other exemplary embodiments relate to a method performed by a base station. The method includes: exchanging a real-time transport protocol (RTP) packet with a user equipment (UE), the RTP packet including a voice packet; determining a connection quality of a connection between the UE and the base station; and transmitting a message including information related to the RTP packet to the UE.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary network arrangement according to various exemplary embodiments.

FIG. 2 illustrates an exemplary UE according to various exemplary embodiments.

FIG3 illustrates an exemplary base station in accordance with various exemplary embodiments.

4 illustrates an application layer providing a single voice packet per RTP packet according to various exemplary embodiments.

5 illustrates an application layer aggregating multiple voice packets per RTP packet according to various exemplary embodiments.

6 illustrates a call flow for an enhanced voice packet scheme for UE to NTN voice operations according to various exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments may be further understood with reference to the following description and associated drawings, wherein like elements are provided with like reference numerals.Exemplary embodiments relate to enhanced voice operations using aggregated voice packets.

The exemplary embodiments are described with reference to UE. However, reference to UE is provided for illustrative purposes only. The exemplary embodiments may be used with any electronic component that can establish a connection with a network and is configured with hardware, software and/or firmware for exchanging information and data with the network. Therefore, the UE described herein is used to represent any electronic component.

The exemplary embodiments are also described with reference to 5G New Radio (NR) networks. However, it should be understood that the exemplary embodiments may also be implemented in other types of networks, including but not limited to LTE networks, future evolutions of cellular protocols (e.g., 6G networks, etc.), or any other type of network.

The exemplary embodiment is also described with reference to the voice service of the NTN network. As will be described herein, the aggregation of voice packets can provide advantages in this type of application. However, it should be understood that the exemplary embodiment is not limited to the NTN network. The aggregation of voice packets can be used in any network arrangement.

Exemplary embodiments relate to aggregating voice packets in a real-time transport protocol (RTP) packet. As will be described in more detail below, under certain conditions, the UE and/or the network may aggregate multiple voice packets in each RTP packet. These conditions may be based on various factors, including the quality of the connection between the UE and the network, the transmission interval, the number of repetitions of each RTP packet, etc.

FIG. 1 illustrates an exemplary network arrangement 100 according to various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will appreciate that the UE 110 may be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a desktop computer, a smart phone, a tablet phone, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. It should also be appreciated that an actual network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single UE 110 is provided for illustrative purposes only.

UE 110 may be configured to communicate with one or more networks. In the example of network configuration 100, the network with which UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, it should be understood that UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, next generation RAN (NG-RAN), traditional cellular networks, etc.), and UE 110 may also communicate with the network via a wired connection. Referring to the exemplary embodiment, UE 110 may establish a connection with 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with NR RAN 120.

The 5G NR RAN 120 may be part of a cellular network that may be deployed by a network operator (e.g., Verizon, AT&T, T-Mobile, etc.). The RAN 120 may include cells or base stations that are configured to transmit and receive traffic from UEs equipped with appropriate cellular chipsets. In this example, the 5G NR RAN 120 includes a gNB 120A. However, reference to a gNB is provided for illustrative purposes only, and any appropriate base station or cell (e.g., Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cell, micro cell, small cell, femto cell, etc.) may be deployed.

Those skilled in the art will appreciate that any relevant process may be performed for the UE 110 to connect to the 5G NR RAN 120. For example, as described above, the 5G NR RAN 120 may be associated with a particular network operator at which the UE 110 and/or its user has protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of the 5G NR RAN 120, the UE 110 may transmit corresponding credential information in order to associate with the 5G NR RAN 120. More specifically, the UE 110 may be associated with a particular cell (e.g., gNB 120A).

The network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP multimedia subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 manages traffic flowing between the cellular network and the Internet 140. The IMS 150 can be generally described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network service backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network service backbone 160 can be generally described as a collection of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 to communicate with various networks.

UE 110 may be connected to gNB 120A via satellite 170. Satellite 170 may communicate with UE 110 via a serving link or wireless interface. Satellite 170 may also communicate with gNB 120A via a feeder link or wireless interface. In some embodiments, satellite 170 may operate as a passive or transparent network relay node between UE 110 and gNB 120A. Those skilled in the art will appreciate that any association process may be performed to connect satellite 170 to UE 110 and gNB 120A.

FIG2 illustrates an exemplary UE 110 according to various exemplary embodiments. UE 110 will be described with reference to network arrangement 100 of FIG1 . UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input/output (I/O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting UE 110 to other electronic devices, a sensor for detecting conditions of UE 110, and the like.

Processor 205 may be configured to execute multiple engines of UE 110. For example, the engines may include packet aggregation engine 235 for performing operations such as aggregating voice packets on a per-RTP packet basis for UE to NTN voice operations.

The above-described engine as an application (e.g., program) executed by the processor 205 is merely exemplary. The functionality associated with the engine may also be represented as a separate combined component of the UE 110, or may be a modular component coupled to the UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing the signal and other information. The engine may also be embodied as an application or multiple separate applications. In addition, in some UEs, the functionality described for the processor 205 is split between one or more processors (such as a baseband processor and an application processor). The exemplary embodiments may be implemented in any of these or other configurations of the UE.

The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to display data to a user, and the I/O device 220 may be a hardware component that enables a user to enter input. The display device 215 and the I/O device 220 may be separate components or may be integrated together (such as a touch screen). The transceiver 225 may be a hardware component configured to establish a connection with the 5G-NR RAN 120. Thus, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of contiguous frequencies). For example, when configured, for example, NR-U, the transceiver 225 may operate on an unlicensed spectrum.

3 illustrates an exemplary base station 300 according to various exemplary embodiments. Base station 300 may represent gNB 120A or any other access node that UE 110 may use to establish a connection and manage network operations.

The base station 300 may include a processor 305, a memory arrangement 310, an input/output (I/O) device 315, a transceiver 320, and other components 325. These other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports for electrically connecting the base station 300 to other electronic devices and/or a power source, and the like.

Processor 305 may be configured to execute multiple engines of UE 110. For example, the engines may include packet aggregation engine 330 for performing operations such as aggregating voice packets on a per-RTP packet basis for UE to NTN voice operations.

The memory 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I/O device 315 may be a hardware component or port that enables a user to interact with the base station 300. The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UE in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., a continuous set of frequencies). Therefore, the transceiver 320 may include one or more components (e.g., radio devices) to enable data exchange with various networks and UEs.

There may be various schemes for voice packet transmission in the NTN. Two exemplary schemes for voice packet transmission are provided below.

Fig. 4 shows an application layer that provides a single voice packet per RTP packet according to various exemplary embodiments. In a first exemplary scheme, the application layer provides a voice packet for each real-time transport protocol (RTP) packet. The RTP layer provides a single network abstraction layer (NAL) unit packet of the RTP type to the RTP packet. This means that the RTP packet includes a voice packet.

4, RTP packet 405 is shown as including a single voice packet 410. RTP packet 405 is sent. After 20ms, a second RTP packet 415 including voice packet 420 is sent. This process is repeated every 20ms until all voice packets have been sent. It should be understood that each RTP packet includes a unique voice packet, e.g., voice packet 410 is different from voice packet 405.

Fig. 5 shows the application layer of multiple voice packets aggregated per RTP packet according to various exemplary embodiments. In the second exemplary scheme, the application layer can aggregate multiple voice packets for each RTP packet. As will be described in more detail below, this may result in a longer transmission interval. The RTP layer provides an aggregated packet of RTP type to the RTP packet. This means that each RTP packet includes multiple voice packets. In the example of Fig. 5, three voice packets will be aggregated. However, it should be understood that it is only exemplary to aggregate three voice packets in the RTP packet. The packets of other quantities can be aggregated in the RTP packet, for example, two, four, five, etc.

Thus, in FIG5 , the RTP packet 505 includes three voice packets 510, 515, and 520. These three voice packets 510, 515, and 520 are transmitted in the RTP packet 505. As shown in FIG5 , there are optional transmission repetitions for the RTP packet 505. It should be understood that these transmission repetitions are optional because all data can be successfully transmitted in the initial RTP packet transmission, thereby eliminating the need for repetition, or can be successfully transmitted in the first repetition, thereby eliminating the need for the second repetition. For example, the PHY repetition transmission can be based on the configuration of the gNB and/or L1 scheduling. If the repetition is a HARQ retransmission, the retransmission can be based on whether the previous transport block (TB) was successfully transmitted. After 60 ms, a second RTP packet 525 including three voice packets 530, 535, and 540 can be transmitted. This process is repeated every 60 ms until all voice packets are transmitted.

The two schemes illustrated in Figures 4 and 5 can be compared. It can be considered that after 60ms, each of these schemes has sent 3 voice packets. However, the second scheme may have certain advantages over the first scheme. For example, as mentioned above, the longer interval between the original packet transmissions in the second scheme allows a greater number of transmission repetitions, which will increase the reliability of the transmission. In addition, the second scheme may have less overhead than the first scheme. For example, the first scheme requires three RTP packets to send three voice packets. These three RTP packets include three layer 2 (L2) headers and three cyclic redundancy checks (CRCs). In contrast, if it is considered that the first transmission of the second scheme is successful, only one L2 header and CRC are used to send the same three voice packets. This means that if the same bit rate is used to send the two schemes, the second exemplary scheme (e.g., aggregated voice packets) may have better transmission performance in the Uu interface.

Therefore, in some scenarios, aggregating multiple voice packets in a single RTP packet may be a preferred transmission mode. These scenarios may include scenarios where the UE operates in an NTN network with an active voice call. However, the application layer is not aware of the radio quality in the Uu interface and cannot adjust the RTP packet type between a single packet and an aggregated packet that matches the active Uu radio scenario. Exemplary embodiments provide enhancements to the AS layer to provide auxiliary information to the application layer and/or the RTP layer to adjust the RTP packet type according to the active networking scenario.

FIG6 illustrates a call flow for an enhanced voice packet scheme for UE to NTN voice operation according to various exemplary embodiments. In the example of FIG6 , UE 110 is shown as including an application layer 610 and an access layer (AS) layer 615. However, it should be understood that the information shown as provided by the AS layer 615 to the application layer 610 may also be provided by the AS layer 615 to the RTP layer.

FIG6 also shows UE 110 in communication with gNB 120A. However, as described above, the call flow is for UE to NTN voice operations. Therefore, it can be considered that UE 110 has a Uu link to satellite 170, which also has a link to gNB 120A. Therefore, in this example, satellite 170 operates as a transparent relay. However, it should be understood that the exemplary embodiments may be implemented in other types of NTN networks where the satellites operate differently.

In 605, UE 110 may be considered to be operating in a radio resource control (RRC) connected mode with 5G NR-RAN 120 via gNB 120A. UE 110 may also be considered to be actively engaged in a voice call, e.g., UE 110 is exchanging voice packets in uplink (UL) and downlink (DL) with gNB 120A.

This active voice packet exchange between UE 110 and gNB 120A is illustrated in 620. In this example, the packet exchange in 620 is a first scheme, where each RTP packet includes a single voice packet.

In 630, the UE-AS layer 610 may determine that an aggregate type of RTP packet should be used, e.g., the RTP packet includes multiple voice packets. In 640, the UE-AS layer 610 provides this information to the UE application layer 615. In this example, it is shown that the information provided to the UE application layer 615 is the number of voice packets that should be aggregated, e.g., AggPackNum=3. However, as described in more detail below, this information is not limited to a specific aggregation number.

The UE AS layer 610 may determine that the RTP packet type should be changed to an aggregate type based on various factors. In some exemplary embodiments, this information may be provided by the network (e.g., via gNB 120A). This operation is shown as optional operation 625 in FIG. 6 , where gNB 120A provides a recommended RTP packet size to the UE AS layer 610. As will be appreciated by those skilled in the art, the network may have information about the Uu connection with UE 110 (e.g., various parameters associated with connection quality). The network may use this connection information to determine the appropriate RTP packet size to be exchanged on the connection. Other examples of information that the network may use to determine the RTP packet size are described in more detail below.

In other exemplary embodiments, the UE AS layer 610 may make this determination based on one or more conditions. For example, just as the network may have information about a Uu connection, the UE AS layer 610 may also have information about the connection and use this information to determine whether the RTP packet type should be aggregated. Examples of conditions are provided in more detail below.

As described above, the UE AS layer 610 may provide the application/RTP layer with a recommended RTP packet size or related information. The UE application/RTP layer may decide whether to aggregate voice packets together, and if the information does not include the aggregation amount, may also determine the aggregation amount to form the RTP packet.

In a first option, UE AS layer 610 may provide the aggregate number of packets to UE application layer 615 based on the current codec mode. For example, the current packet exchange between UE 110 and gNB 120A may be based on the currently implemented codec. UE AS layer 610 may be aware of the currently implemented codec and determine the number of aggregated packets based on the codec. This information may then be provided to application layer 615, which may then use the suggested number of aggregated packets for the aggregated RTP packets.

In the second option, the UE AS layer 610 may provide the UE application layer 615 with the aggregate number of packets based on the default codec mode. For example, regardless of the currently implemented codec, the UE AS layer 610 will report the aggregate number of packets for a predefined codec (e.g., 4.75 kbps). When the UE application layer 615 receives the aggregate number of packets from the UE AS layer 610, the UE application layer 615 may understand that the codec mode should be set to the default codec (e.g., 4.75 kbps). Therefore, the UE 110 may change the codec mode according to the indicated default mode, and the application layer 615 may then use the recommended number of aggregated packets for the aggregated RTP packets.

In a third option, the UE AS layer 610 may provide the aggregated number of packets and the codec mode to the UE application layer 615. In this option, the UE 110 may change the codec mode based on the indication of the UE AS layer 610, and the application layer 615 may then use the recommended number of aggregated packets for the aggregated RTP packets corresponding to the recommended coding mode.

In the fourth option, the UE AS layer 610 may provide the aggregate RTP packet size to the UE application layer 615. In the first three options, the UE AS layer 610 provides the aggregate number of packets. However, in this option, the UE AS layer 610 provides the size of the RTP packet. The UE application layer 615 may then determine the aggregate number of packets on a per-RTP packet basis based on a formula. For example, since the UE application layer 615 knows the total size of the RTP packet and the size of the information to be included in the RTP packet in addition to the voice packet, the UE application layer 615 may calculate the number of voice packets that will fit into the remaining space in the RTP packet, for example, the aggregate number of packets may be understood as: (RTP packet size) divided by (per voice packet size) according to the current codec mode.

Therefore, in 650, the RTP layer switches the RTP packet type to an aggregate packet type. The application layer 615 will then provide a number of voice packets corresponding to the aggregate number of packets to be included in the RTP packet. As described above, in this example, the number is three voice packets. The UE 110 will then send an RTP packet with the aggregate number of voice packets, as shown in 650.

In the above examples, it should be appreciated that the exemplary voice packet aggregation and all options related to the exemplary voice packet aggregation may be applied exclusively to uplink packets, exclusively to downlink packets, or exclusively to both uplink and downlink packets.

As discussed above with respect to 625, the network may provide recommended voice packet information to UE 110. The recommendation may be based on the network's scheduling scheme for UE 110, and may also be based on UE 110's current radio connection quality and service delivery performance.

The network may provide the voice grouping information to UE 110 via L1/L2/L3 signaling. It should be understood that in the grouping scheme recommended by the network, all four options above may be provided by the network instead of being decided at UE 110. The network may provide the initial configuration via RRC signaling, and may dynamically adjust the voice grouping information via L1/L2 signaling. The network may also provide the voice grouping information based on a UE request or UE preference, and the UE request may also be sent via L1/L2/L3 signaling.

As also described above, the UE AS layer 610 may decide how to process the recommended voice packet information based on one or more conditions.

In some exemplary embodiments, the condition may be a radio quality threshold. The radio quality threshold may be based on the association between the number of aggregated packets and the radio quality. For example, if the radio quality of UE 110 is less than a threshold, UE 110 may enable a packet aggregation mode and increase the number of aggregates. In these exemplary embodiments, the network may configure a mapping between a radio quality threshold, the number of aggregated packets, and a codec mode. This information may be provided to UE 110 in the form of a table via any type of signaling (e.g., RRC signaling, medium access control-control element (MAC-CE), etc.) with the network. UE 110 may follow a mapping table configured by the network to select voice packet assembly information (e.g., codec mode, the number of aggregated voice packets) based on a quality threshold. However, in other exemplary embodiments, the threshold information may be provided to UE 110 in other ways.

In other exemplary embodiments, the condition may be a transmission interval. This may be based on an association between the number of aggregate packets and the scheduled transmission interval. For example, if the network provides a configuration grant (CG) configuration with a 20 ms interval, the UE 110 will understand that a single packet mode should be used. On the other hand, if the network enables a CG configuration with a 60 ms interval for voice bearer transmission, the UE 110 will understand that the aggregate packet mode should be used and the number of aggregate packets is 3. The use of the transmission interval may be enabled via the gNB via RRC configuration, and the network may also configure reference time interval information (e.g., 20 ms). The reference time interval information may be an interval for the single packet mode, and the UE 110 may then determine the number of aggregate packets based on an interval that is a multiple of the reference time interval (e.g., 40 ms, 60 ms, 80 ms, etc.).

In a further exemplary embodiment, the condition may be a number of transmission repetitions. This may be based on a correlation between the number of aggregated packets and the scheduled number of transmission repetitions. For example, a maximum of 20 repetitions for a single packet, a maximum of 40 repetitions for two aggregated packets, and a maximum of 60 repetitions for three aggregated packets. This would mean that the number of aggregated packets is determined based on the configured maximum repetition.

It should be noted that all of the aforementioned conditions may be controlled by the network (e.g., gNB 120A) or based on UE implementation. It should also be noted that in addition to the number of voice aggregation packets, the conditions may also be associated with a specific codec mode.

Example

In a first exemplary embodiment, a processor of a user equipment (UE) is configured to: determine a real-time transport protocol (RTP) packet size; determine to aggregate one or more voice packets into an RTP packet based on the RTP packet size; determine a number of the one or more voice packets; and send the RTP packet including the number of the one or more voice packets.

In a second embodiment, the processor according to the first embodiment, wherein the RTP packet size is determined by an access stratum (AS) layer of the UE based on a condition.

In a third embodiment, the processor according to the second embodiment, wherein the condition includes a connection quality of a connection between the UE and a network.

In a fourth embodiment, the processor according to the third embodiment, wherein the connection quality corresponds to one of: (i) the number of the one or more voice packets, (ii) the codec mode of the UE, or (iii) the size of the RTP packet.

In a fifth embodiment, the processor according to the fourth embodiment, wherein the correspondence between the connection quality and one of the following items is based on information received from the network or information stored in the UE: (i) the number of the one or more voice packets, (ii) the codec mode of the UE or (iii) the size of the RTP packet.

In a sixth embodiment, the processor according to the second embodiment, wherein the condition includes a transmission interval between the transmission of the RTP packet and the next RTP packet.

In a seventh embodiment, the processor according to the second embodiment, wherein the condition includes a number of repetitions configured for the RTP packet.

In an eighth embodiment, the processor according to the first embodiment, wherein the RTP packet size is determined based on an indication received from a network.

In a ninth embodiment, the processor according to the eighth embodiment, wherein the indication received from the base station is provided via layer 1 (L1), layer 2 (L2), or layer 3 (L3) signaling.

In a tenth embodiment, the processor according to the eighth embodiment, wherein the indication is received based on a UE request or a UE preference.

In an eleventh embodiment, the processor according to the first embodiment, wherein the number of the one or more voice packets is based on a codec mode.

In a twelfth embodiment, according to the processor of the eleventh embodiment, the codec mode is an active codec mode being used by the UE.

In a thirteenth embodiment, according to the processor of the eleventh embodiment, the codec mode is a default codec mode.

In a fourteenth embodiment, according to the processor of the eleventh embodiment, the processor is further configured to determine the encoding and decoding mode.

In a fifteenth embodiment, the processor according to the first embodiment, wherein the number of the one or more voice packets is based on the RTP packet size.

In a sixteenth embodiment, a user equipment (UE) includes a transceiver for communicating with a network and a processor according to any one of the first to fifteenth embodiments.

In a seventeenth embodiment, a computer-readable storage medium includes an instruction set, which, when executed, causes a processor to perform operations according to any one of the first to fifteenth embodiments.

In an eighteenth embodiment, a processor of a base station is configured to: exchange real-time transport protocol (RTP) packets with a user equipment (UE), wherein the RTP packets include voice packets; determine the connection quality of the connection between the UE and the base station; and transmit a message including information related to the RTP packets to the UE.

In a nineteenth embodiment, the processor according to the eighteenth embodiment, wherein the information includes a recommended number of voice packets to be included in each of the RTP packets.

In a twentieth embodiment, the processor according to the eighteenth embodiment, wherein the information includes the size of the RTP packet.

In a twenty-first embodiment, a processor according to the eighteenth embodiment, wherein the information includes a correspondence between the connection quality determined by the UE and one of the following items: (i) the number of one or more voice packets, (ii) the codec mode of the UE, or (iii) the size of the RTP packet.

In a twenty-second embodiment, the processor of the eighteenth embodiment, wherein the message is one of layer 1 (L1), layer 2 (L2), or layer 3 (L3).

In a twenty-third embodiment, a base station includes a transceiver for communicating with a user equipment (UE) and a processor according to any one of the eighteenth to twenty-second embodiments.

In a twenty-fourth embodiment, a computer-readable storage medium includes an instruction set, which, when executed, causes a processor to perform operations according to any one of the eighteenth to twenty-second embodiments.

Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented with any suitable software configuration or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, etc. In another example, the exemplary embodiments of the above method may be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, may be executed on a processor or microprocessor.

Although the present application describes various combinations of aspects each having different features, those skilled in the art will understand that any feature of one aspect may be combined with features of other aspects or features that are not functionally or logically inconsistent with the operation or function of the device of the aspects disclosed in the present invention in any manner not publicly denied.

It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

It will be apparent to those skilled in the art that various modifications may be made to the present disclosure without departing from the spirit or scope of the present disclosure. Therefore, it is intended that the present disclosure covers modifications and variations of the present disclosure as long as they fall within the scope of the appended claims and their equivalents.

Claims (20)

1. A method performed by a User Equipment (UE), the method comprising:

Determining a real-time transport protocol (RTP) packet size;

determining to aggregate one or more voice packets into an RTP packet based on the RTP packet size;

Determining the number of the one or more voice packets, and

Transmitting the RTP packets including the number of the one or more voice packets.

2. The method of claim 1, wherein the RTP packet size is determined by an access layer (AS) layer of the UE based on a condition.

3. The method of claim 2, wherein the condition comprises a connection quality of a connection between the UE and a network.

4. The method of claim 3, wherein the connection quality corresponds to one of (i) the number of the one or more voice packets, (ii) a codec mode of the UE, or (iii) a size of the RTP packets.

5. The method of claim 4, wherein a correspondence between the connection quality and the one of (i) the number of the one or more voice packets, (ii) the codec mode of the UE, or (iii) the size of the RTP packet is based on information received from the network or information stored in the UE.

6. The method of claim 2, wherein the condition comprises a transmission interval between transmitting the RTP packet and a next RTP packet.

7. The method of claim 2, wherein the condition comprises a number of repetitions configured for the RTP packet.

8. The method of claim 1, wherein the RTP packet size is determined based on an indication received from a network.

9. The method of claim 8, wherein the indication received from the base station is provided via layer 1 (L1), layer 2 (L2), or layer 3 (L3) signaling.

10. The method of claim 8, wherein the indication is received based on a UE request or a UE preference.

11. The method of claim 1, wherein the number of the one or more voice packets is based on a codec mode.

12. The method of claim 11, wherein the codec mode is an active codec mode being used by the UE.

13. The method of claim 11, wherein the codec mode is a default codec mode.

14. The method of claim 11, further comprising:

and determining the coding and decoding mode.

15. The method of claim 1, wherein the number of the one or more voice packets is based on the RTP packet size.

16. A method performed by a base station, comprising:

Exchanging real-time transport protocol (RTP) packets with a User Equipment (UE), the RTP packets comprising voice packets;

determining connection quality of a connection between the UE and the base station, and

Transmitting a message including information related to the RTP packet to the UE.

17. The method of claim 16, wherein the information includes a recommended number of voice packets to be included in each of the RTP packets.

18. The method of claim 16, wherein the information comprises a size of the RTP packet.

19. The method of claim 16, wherein the information comprises a correspondence between a connection quality determined by the UE and one of (i) the number of the one or more voice packets, (ii) a codec mode of the UE, or (iii) a size of the RTP packets.

20. The message of claim 16, wherein the message is one of layer 1 (L1), layer 2 (L2), or layer 3 (L3).