UE assistance information for cellular voice

Abstract

Methods, systems, apparatus, and computer programs are disclosed for providing assistance information from a user equipment (UE) participating in a multimedia telephony session to a network. In one aspect, the method includes determining connection parameters for a multimedia telephony session between the user equipment (UE) and a remote UE. The method also includes generating assistance information based on the connection parameters. Furthermore, the method includes sending the assistance information to an access node (AN) serving the UE using a medium access control (MAC) control element.

Description

[0001] Priority claim

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 866,222, filed on June 25, 2019, entitled “UE Assistance Information for Voice Over Cellular,” which is incorporated herein by reference in its entirety. Background Art

[0003] User Equipment (UE) can transmit data wirelessly using a wireless communication network. To transmit data wirelessly, the UE connects to a node of a Radio Access Network (RAN) and synchronizes with the network. Summary of the Invention

[0004] The present disclosure relates to methods, systems, apparatus, and computer programs for providing assistance information from a user equipment (UE) participating in a multimedia telephony session to a network.

[0005] In one aspect, a method includes determining connection parameters for a multimedia telephony session between a user equipment (UE) and a remote UE. The method also includes generating assistance information based on the connection parameters. Furthermore, the method includes sending the assistance information to an access node (AN) serving the UE using a medium access control (MAC) control element.

[0006] Other versions include corresponding systems, apparatus, and computer programs for performing the actions of the method defined by the instructions encoded on the computer-readable storage device.These and other versions may optionally include one or more of the following features.

[0007] In some embodiments, determining the connection parameters of the multimedia telephony session involves measuring an end-to-end delay of the multimedia telephony session.

[0008] In some embodiments, generating assistance information based on connection parameters involves requesting a delay budget for a remote radio link of the remote UE from the remote UE; determining a delay budget for a local radio link of the UE based on at least one of: an end-to-end delay measurement of the multimedia telephony session, or a delay budget for the remote radio link of the multimedia telephony session; and generating a delay budget indicator based on the delay budget of the local radio link, the assistance information including the delay budget indicator.

[0009] In some embodiments, determining connection parameters for the multimedia telephony session involves determining the robustness of a codec used in conjunction with the multimedia telephony session.

[0010] In some embodiments, generating auxiliary information based on connection parameters involves generating a robustness indicator based on at least one of: feedback from a jitter buffer indicating a packet drop rate or robustness to packet loss of a codec used in conjunction with the multimedia telephony session, wherein the auxiliary information includes the robustness indicator.

[0011] In some embodiments, the robustness indicator comprises a maximum supported packet loss rate on the UE's radio local link.

[0012] In some implementations, the codec robustness indicator includes a target block error rate (BLER).

[0013] In some embodiments, generating assistance information based on connection parameters involves determining a packet loss rate for a local radio link applicable to the UE based on: (i) the robustness of a codec used in conjunction with the multimedia telephony session to packet loss, and (ii) packet loss observed on a remote radio link of a remote UE; and generating a robustness indicator based on the packet loss rate, the assistance information including the robustness indicator.

[0014] In some embodiments, the assistance information also includes a request to the access node to adjust the delay budget of the UE's local radio link.

[0015] In some embodiments, the assistance information also includes a request to the access node to enable Packet Data Convergence Protocol (PDCP) packet repetition.

[0016] In some embodiments, a plurality of radio link control (RLC) bearers are connected to a packet data convergence protocol (PDCP) entity of the UE, and the assistance information further includes a request to the access node to change a default RLC bearer among the plurality of RLC bearers.

[0017] According to another aspect of the present disclosure, a method involves receiving assistance information from a remote user equipment (UE) conducting a multimedia telephony session with the UE; and modifying at least one of a configuration of a local radio link or a configuration of a layer 2 data plane of the UE based on the assistance information.

[0018] In some embodiments, the assistance information includes at least one of: (i) a delay budget indicator indicating a delay budget of a local radio link; or (ii) a robustness indicator indicating the robustness of a codec used in conjunction with the multimedia telephony session.

[0019] In some embodiments, modifying at least one of the configuration of the UE's local radio link or the configuration of the Layer 2 data plane involves enabling Packet Data Convergence Protocol (PDCP) packet repetition; changing a default Radio Link Control (RLC) bearer among multiple Radio Link Control (RLC) bearers connected to the UE's PDCP entity; or changing a Connected Mode DRX (C-DRX) cycle length.

[0020] In some embodiments, PDCP packet repetition is enabled in response to determining that end-to-end delay of the multimedia telephony session or robustness of a codec used in conjunction with the multimedia telephony session does not meet corresponding conditions.

[0021] In some embodiments, modifying at least one of the configuration of the UE's local radio link or the configuration of the Layer 2 data plane includes using in-band Packet Data Convergence Protocol (PDCP) reconfiguration to: change the default Radio Link Control (RLC) bearer of the UE's Packet Data Convergence Protocol (PDCP) entity; or enable or disable PDCP data repetition.

[0022] In some embodiments, the in-band PDCP reconfiguration uses New Radio (NR) PDCP control protocol data units (PDUs).

[0023] According to yet another aspect of the present disclosure, a method involves selecting an action to be performed by an access node (AN) serving a user equipment (UE) based on (i) audio quality in a multimedia telephony session between the UE and a remote UE, or (ii) an end-to-end delay measurement of the multimedia telephony session. The method also involves sending an indication of the action to be performed to the AN.

[0024] In some embodiments, sending the indication involves sending the indication in a radio resource control (RRC) signal, a packet data convergence protocol (PDCP) control protocol data unit (PDU), or a medium access control (MAC) control element.

[0025] In some embodiments, the action is at least one of: enabling data repetition; changing the default radio link control (RLC) bearer of the UE's packet data convergence protocol (PDCP) entity; enabling transmission time interval (TTI) bundling or lowering the modulation and coding scheme (MCS). BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1A and Figure 1B An exemplary medium access control element for signaling of a delay budget is shown, according to some embodiments of the present disclosure.

[0027] Figure 2An exemplary control protocol data unit for packet data convergence protocol reconfiguration according to some embodiments of the present disclosure is shown.

[0028] Figure 3A and Figure 3B An exemplary Packet Data Convergence Protocol Control Protocol Data Unit is shown, according to some embodiments of the present disclosure.

[0029] Figure 4A 、 Figure 4B and Figure 4C Each shows a flow chart of an exemplary process according to some embodiments of the present disclosure.

[0030] Figure 5 An example of a wireless communication system according to some embodiments of the present disclosure is shown.

[0031] Figure 6 An exemplary architecture of a system including a CN according to some embodiments of the present disclosure is shown.

[0032] Figure 7 Examples of infrastructure equipment according to some embodiments of the present disclosure are shown.

[0033] Figure 8 Exemplary components of a baseband circuit and a radio front end module (RFEM) are shown according to some embodiments of the present disclosure.

[0034] Figure 9 Various protocol functions that may be implemented in a wireless communication device according to some embodiments of the present disclosure are illustrated.

[0035] Figure 10 is a block diagram according to some embodiments of the present disclosure, which shows components capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some exemplary embodiments.

[0036] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0037] In an Internet Protocol (IP) Multimedia Subsystem (IMS) that provides multimedia telephony services for IMS (MTSI), such as Voice over Long Term Evolution (VoLTE) or Voice / Video over New Radio (VoNR), a radio access network (RAN) may use different methods to increase the reliability of the radio link for a call session (also referred to as a "multimedia telephony session"). These methods include, for example, hybrid automatic repeat request (HARQ) retransmissions, transmission time interval (TTI) bundling, and packet data convergence protocol (PDCP) redundancy. These methods may have different effects on the latency associated with the radio link.

[0038] During implementation, when selecting a method for improving the reliability of a call session, the network may rely on information received from the user equipment (UE) participating in the call session. For example, the network may receive a recommended bit rate from the UE. In addition, the 3rd Generation Partnership Project (3GPP) has a defined method for measuring end-to-end (E2E) delay during a VoLTE or VoNR call and for sharing a delay budget between peer UEs participating in the call. The method involves a Real-time Transport Control Protocol (RTCP) feedback message type that enables the following capabilities of signaling delay budget information (DBI) across peer UEs in an IMS telephony session: (i) the MTSI receiver can indicate the available delay budget to the MTSI sender, and (ii) the MTSI sender can explicitly request a delay budget from the MTSI receiver. For example, these methods are described in 3GPP TS 26.114 (Multimedia Telephony Service (MTSI) over IP Multimedia Systems Specification) v16.2.0.

[0039] The MTSI receiver can use such RTCP-based DBI signaling to indicate the availability of a delay budget created by other means (such as jitter buffer size adaptation). The receiving UE of the RTCP feedback message carrying the DBI can then use this information to determine the delay budget adjustment it can request from the network through the RAN interface. For example, as defined in 3GPP TS 36.331, v15.5.1 and TS 38.331, v15.5.1, the UE can use Radio Resource Control (RRC) signaling based on UEAssistanceInformation to request a delay budget adjustment. In addition, the UE can use RRC signaling to provide a delay budget report to the network (for example, as described in 3GPP TS 38.331 and 36.331). The delay budget report uses an enumerated data type to indicate the possible values of the delay.

[0040] However, these existing solutions have drawbacks. For example, the network does not know the performance of the codec (e.g., audio codec) used in the call session, nor does it know the robustness of the codec to packet loss. The codec type can change dynamically during the call session without notifying the network. As another example, although the network receives delay budget reports, RRC signaling typically requires additional processing and heavier signaling. In addition, encoding the delay report using an enumerated data type limits the number of possible delay values indicated in the message. As another example, the delay budget adjustment requested by the UE is limited. For example, there is no signaling for the UE to recommend to the network to enable data repetition based on audio quality. In addition, in the case of dual connectivity (e.g., NR-NR or Evolution-Universal Terrestrial Radio Access-New Radio [EN-DC]), there is no signaling available to change the default radio link control (RLC) bearer.

[0041] Disclosed herein are methods and systems that enable a UE participating in a multimedia telephony session to provide connection parameters to the network. These connection parameters enable the network to better configure or reconfigure radio resource allocation based on call quality and / or end-to-end delay for the session. Specifically, disclosed are signaling messages for the UE to report assistance information to the network, where the assistance information includes, for example, a delay budget indicator and a robustness indicator. Compared to existing RRC signaling for delay budget reporting, this signaling message offers greater flexibility and requires less processing and lighter signaling.

[0042] In addition, the network uses the information provided by the UE to optimize or otherwise improve radio resource allocation, thereby improving the user experience during the call. For example, when the end-to-end (E2E) voice delay is too long (e.g., greater than a threshold) or the robustness is not good enough (e.g., does not meet a threshold robustness), the network can determine to perform remedial measures. The remedial measures may include enabling PDCP packet repetition or changing the length of the connected mode DRX (C-DRX) cycle. Therefore, the additional information provided by the present disclosure enables the network to better configure radio resource allocation than existing solutions.

[0043] The present disclosure also describes in-band signaling (e.g., using PDCP control messages) to perform PDCP-related actions. For example, in the presence of multiple RLC bearers associated with a PDCP entity of a UE, in-band signaling can be used to change the default RLC bearer, or to control (e.g., enable / disable) PDCP data repetition. The disclosed in-band signaling enables faster reconfiguration of PDCP compared to existing solutions. In addition, the present disclosure describes a method for a UE to provide a recommendation to the network to enable PDCP data repetition (e.g., based on audio encoder performance) for an IMS voice bearer or to change the default radio link control (RLC) bearer when dual connectivity is enabled. As described above, existing solutions do not support providing such recommendations.

[0044] Media layer management engine in UE

[0045] In one embodiment, a media layer management engine of a UE participating in a multimedia telephony session determines a delay budget for the UE's local radio link. In one example, the delay budget is determined based on at least one of an end-to-end voice delay measurement or a delay budget request from a peer UE. The media layer management engine then provides the delay budget to the cellular protocol stack of the UE. The delay budget can be determined and provided separately for uplink (UL) and downlink (DL), or can be determined and provided for both UL and DL simultaneously.

[0046] In one embodiment, the media layer management engine additionally and / or alternatively determines a robustness indicator. In one example, the robustness indicator is determined based on feedback from a jitter buffer regarding packet drop rate (e.g., voice packet drop rate) and codec (e.g., voice codec) robustness to packet loss. The media layer management engine may also provide the robustness indicator to the cellular protocol stack of the UE separately or together with the delay budget.

[0047] Cellular protocol stack in UE

[0048] In one embodiment, the cellular protocol stack of the UE receives a delay budget and / or robustness indicator from a media layer management engine. The cellular protocol stack notifies the network (e.g., via a base station serving the UE, such as an eNB or gNB) of the delay budget so that the network can guarantee or otherwise provide acceptable voice / video quality. Additionally or alternatively, the cellular protocol stack can notify the network of the robustness indicator. In an example, the cellular protocol stack can notify the network using RRC signaling, a PDCP control message on a data radio bearer (DRB), or a medium access control (MAC) control element (CE).

[0049] Figure 1A and Figure 1BAn example medium access control (MAC) control element (CE) for signaling a delay budget is shown according to some implementations. Figure 1A An exemplary MAC CE 100 is shown. In this example, MAC CE 100 is an existing bit rate recommendation query message from a UE to a base station. To include a delay budget, MAC CE 100 is extended to include a field that can carry the delay budget. In this example, MAC CE 100 is extended to include field 102 (UL / DL) and field 104 (Delay Budget). Field 102 is used to indicate whether the delay budget for signaling is for UL or DL, and field 104 is used to indicate the delay budget.

[0050] Figure 1B An exemplary MAC CE 130 is shown. In this example, MAC CE 130 is a new message for signaling a delay budget. Figure 1B As shown, MAC CE 130 includes field 132 (UL / DL) and field 134 (delay budget), where field 132 is used to indicate whether the delay budget for the signaling is for UL or DL, and field 134 is used to indicate the delay budget. In both MAC CE 100 and MAC CE 130, the delay budget value can be provided in milliseconds (ms). For example, encoding on 7 bits would allow reporting in the range of 0 ms to 127 ms.

[0051] In one embodiment, if a new MAC CE is introduced, the logical channel identifier list (LCID) may be enhanced as shown in Table 1.

[0052] Table 1

[0053]

[0054]

[0055] In this embodiment, LCID 10001 is used for Delay Budget MAC CE 230. Alternatively, an extended LCID may be used, as shown in Table 2.

[0056] Table 2: UL-SCH eLCID values

[0057] Code Point index LCID value 000000-000110 32-38 Logical channel identifier 000111-111110 39-94 reserve 111111 95 Delay Budget

[0058] Note that similar enhancements to those described above may be performed for NR MAC CE.

[0059] In one embodiment, the UE may also report auxiliary information related to the robustness of the codec to the packet loss. Several options for reporting this auxiliary information are possible. In the first option, the UE may add a flag to the message to recommend to the network that robustness be increased. This option may be triggered when the UE's media layer detects that a decoder (e.g., an audio decoder) or codec has reached its limit in maintaining the current packet loss rate. In the second option, the UE may report a target block error rate (BLER) based on codec performance.

[0060] In one embodiment, this assistance information may be sent to the base station using RRC signaling of a MAC control element. If a MAC CE is used, the following options are possible: (i) extend the existing bit rate recommendation query message from the UE to the eNB, (ii) use this new MAC CE defined above to report the delay budget, or (iii) create a new MAC CE.

[0061] Network base stations (eNB and gNB)

[0062] Upon receiving a delay budget message from a UE on the UL or DL, the network (e.g., with the aid of a base station) may determine one or more remedial measures to meet the indicated budget requirement. In one example, the one or more remedial measures may be determined based on at least one of radio resource availability, EN-DC support, radio link quality, and fading type, or the number of users to be served. In addition, the one or more remedial measures may include: (i) adapting the maximum number of HARQ retransmissions, (ii) enabling / disabling TTI bundling, (iii) enabling separate bearers with PDCP redundancy in dual connectivity or carrier aggregation scenarios, (iv) changing the default radio link in scenarios where dual connectivity is supported, and / or (v) changing the connected mode discontinuous reception (C-DRX) cycle length or disabling C-DRX.

[0063] In one embodiment, PDCP control messages are used for in-band PDCP reconfiguration, which enables fast reconfiguration of PDCP during a call. In-band reconfiguration is faster than standard PDCP reconfiguration using RRC signaling. In particular, the network can trigger in-band PDCP reconfiguration to change the default RLC bearer. This is particularly useful for quickly switching data traffic from LTE to an NR radio leg, or vice versa. Alternatively, the network can trigger in-band PDCP reconfiguration to dynamically enable or disable PDCP data repetition (e.g., based on radio link conditions and UE assistance information).

[0064] In one embodiment, a new NR PDCP control protocol data unit (PDU) type is introduced: "PDCP Reconfiguration (More Than One RLC)." This new NR PDCP PDU can be used for in-band PDCP reconfiguration. Table 3 contains a description of the PDCP control PDU types.

[0065] Bit describe 000 PDCP status report 001 Scattered ROHC feedback 010 PDCP reconfiguration (more than one RLC) 011-111 reserve

[0066] Table 3: PDCP Control PDU Types

[0067] Figure 2 An example control PDU 200 for PDCP reconfiguration according to some implementations is shown. In this example, the control PDU 200 is associated with the new NR PDCP control PDU type. Figure 2 As shown, the control PDU 200 includes a PP field 202, a CG ID field 204, an LCH ID field 206, and a DD field 208. The PP field 202 indicates whether the primary path is being reconfigured (e.g., by changing the default RLC bearer). For example, the PP field 202 is set to 1 to indicate reconfiguration of the primary path. In this case, octet 2 is included in the PDU 200. In octet 2, the CG ID field 204 indicates the cell group ID of the primary path, and the LCH ID field 206 indicates the logical channel ID of the primary path. The DD field 208 indicates whether PDCP data repetition is disabled or enabled. For example, the DD field 208 is set to 0 to indicate that PDCP data repetition is disabled, and the DD field 208 is set to 1 to indicate that PDCP data repetition is enabled.

[0068] In addition, the control PDU can be further enhanced, for example, to reconfigure the UL-DataSplitThreshold. Alternatively, a separate PDCP control PDU can be introduced to change the PDCP data repetition configuration or change the primary path.

[0069] In one embodiment, the UE directly selects and recommends to the network (e.g., with the help of a base station) to perform this action based on current voice quality and end-to-end delay measurements. In particular, instead of reporting a delay budget or robustness indicator to the network, the UE directly sends a recommendation to enable PDCP data repetition, enable TTI bundling, or request a lower modulation and coding scheme (MCS).

[0070] In one embodiment, the recommendation can be sent to the base station using a control message. Several options for sending this control information are possible. To request the activation of PDCP data repetition, the UE sends this control information using RRC signaling, a PDCP control PDU, or a MAC control element. In the example of a MAC control element, the UE can reuse the PDCP reactivation / deactivation MAC control element used by the base station. From the UE to the base station, the meaning of this MAC CE will be a recommendation for PDCP reactivation / deactivation. Alternatively, a new PDCP control PDU can be introduced for this purpose.

[0071] Figure 3A and Figure 3B An exemplary PDCP control PDU for signaling a recommendation according to some implementations is shown. Specifically, Figure 3A A MAC CE 300 based on PDCP reactivation / deactivation MAC control element is shown, and Figure 3B A new PDCP control PDU 310 is shown. Figure 3B As shown, the PDCP Control PDU 310 includes a PP field 312 and a DD field 314. The PP field 312 indicates whether the UE recommends the network to change the primary path. For example, if the PP field 312 is set to 1, it indicates that the UE recommends the network to change the primary path. The DD field 314 indicates whether the UE recommends the network to enable PDCP data repetition. For example, if the DD field 314 is set to 1, it indicates that the UE recommends the network to enable PDCP data repetition, and if the DD field 314 is set to 0, it indicates that the UE recommends the network to disable PDCP data repetition.

[0072] The following figures depict UEs (e.g., UE 501a / UE 501b) and eNBs / gNBs (e.g., RAN nodes 511a / 511b), which may be configured to implement various aspects of the embodiments described herein.

[0073] Figure 4A 、 Figure 4B and Figure 4C Each shows a flow chart of an exemplary process according to some embodiments. For clarity of presentation, the following description generally describes processes in the context of other figures in this specification. For example, flowchart 400, flowchart 420 can be executed by a UE (e.g., Figure 5 ) and flowchart 410 may be executed by an access node (e.g., as Figure 5 However, it should be understood that these processes can be performed, for example, by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware. In some embodiments, the steps of the process can be run in parallel, in combination, in a loop, or in any order.

[0074] Figure 4A is a flow chart of an example process 400 for providing assistance information from a user equipment (UE) participating in a multimedia telephony session to a network, according to various embodiments. Figure 5 5. The process 400 includes determining connection parameters for a multimedia telephony session between a user equipment (UE) and a remote UE. At step 402, the process 400 includes generating assistance information based on the connection parameters. At step 406, the process 400 includes sending the assistance information to an access node (AN) serving the UE using a medium access control (MAC) control element.

[0075] In some embodiments, determining the connection parameters of the multimedia telephony session involves measuring an end-to-end delay of the multimedia telephony session.

[0076] In some embodiments, generating assistance information based on connection parameters involves requesting a delay budget for a remote radio link of the remote UE from the remote UE; determining a delay budget for a local radio link of the UE based on at least one of: an end-to-end delay measurement of the multimedia telephony session, or a delay budget for the remote radio link of the multimedia telephony session; and generating a delay budget indicator based on the delay budget of the local radio link, the assistance information including the delay budget indicator.

[0077] In some embodiments, determining connection parameters for the multimedia telephony session involves determining the robustness of a codec used in conjunction with the multimedia telephony session.

[0078] In some embodiments, generating auxiliary information based on connection parameters involves generating a robustness indicator based on at least one of: feedback from a jitter buffer indicating a packet drop rate or robustness to packet loss of a codec used in conjunction with the multimedia telephony session, wherein the auxiliary information includes the robustness indicator.

[0079] In some embodiments, the robustness indicator comprises a maximum supported packet loss rate on the UE's radio local link.

[0080] In some implementations, the codec robustness indicator includes a target block error rate (BLER).

[0081] In some embodiments, generating assistance information based on connection parameters involves determining a packet loss rate for a local radio link applicable to the UE based on: (i) the robustness of a codec used in conjunction with the multimedia telephony session to packet loss, and (ii) packet loss observed on a remote radio link of a remote UE; and generating a robustness indicator based on the packet loss rate, the assistance information including the robustness indicator.

[0082] In some embodiments, the assistance information also includes a request to the access node to adjust the delay budget of the UE's local radio link.

[0083] In some embodiments, the assistance information also includes a request to the access node to enable Packet Data Convergence Protocol (PDCP) packet repetition.

[0084] In some embodiments, a plurality of radio link control (RLC) bearers are connected to a packet data convergence protocol (PDCP) entity of the UE, and the assistance information further includes a request to the access node to change a default RLC bearer among the plurality of RLC bearers.

[0085] Figure 4B 4 is a flow diagram of an exemplary process 410 for a base station to perform remedial measures based on assistance information received from a UE. At step 412, process 410 involves receiving assistance information from a remote user equipment (UE) that is engaged in a multimedia telephony session with the UE. At step 414, process 410 involves modifying at least one of a configuration of a local radio link or a configuration of a layer 2 data plane of the UE based on the assistance information.

[0086] In some embodiments, the assistance information includes at least one of: (i) a delay budget indicator indicating a delay budget of a local radio link; or (ii) a robustness indicator indicating the robustness of a codec used in conjunction with the multimedia telephony session.

[0087] In some embodiments, modifying at least one of the configuration of the UE's local radio link or the configuration of the Layer 2 data plane involves enabling Packet Data Convergence Protocol (PDCP) packet repetition; changing a default Radio Link Control (RLC) bearer among multiple Radio Link Control (RLC) bearers connected to the UE's PDCP entity; or changing a Connected Mode DRX (C-DRX) cycle length.

[0088] In some embodiments, PDCP packet repetition is enabled in response to determining that end-to-end delay of the multimedia telephony session or robustness of a codec used in conjunction with the multimedia telephony session does not meet corresponding conditions.

[0089] In some embodiments, modifying at least one of the configuration of the UE's local radio link or the configuration of the Layer 2 data plane includes using in-band Packet Data Convergence Protocol (PDCP) reconfiguration to: change the default Radio Link Control (RLC) bearer of the UE's Packet Data Convergence Protocol (PDCP) entity; or enable or disable PDCP data repetition.

[0090] In some embodiments, the in-band PDCP reconfiguration uses New Radio (NR) PDCP control protocol data units (PDUs).

[0091] Figure 4C 4 is a flow chart of an exemplary process 420 for providing a recommendation by a UE to a base station based on the state of a multimedia telephony session in which the UE is engaged. At step 422, the process 420 involves selecting an action to be performed by an access node (AN) serving the UE based on (i) audio quality in the multimedia telephony session between the user equipment (UE) and a remote UE, or (ii) end-to-end delay measurements of the multimedia telephony session. At step 424, the process 420 involves sending an indication of the action to be performed to the AN.

[0092] In some embodiments, sending the indication involves sending the indication in a radio resource control (RRC) signal, a packet data convergence protocol (PDCP) control protocol data unit (PDU), or a medium access control (MAC) control element.

[0093] In some embodiments, the action is at least one of: enabling data repetition; changing the default radio link control (RLC) bearer of the UE's packet data convergence protocol (PDCP) entity; enabling transmission time interval (TTI) bundling; or lowering the modulation and coding scheme (MCS).

[0094] Figure 4A 、 Figure 4B and Figure 4C The exemplary processes shown may be modified or reconfigured to include additional, fewer, or different steps (not shown), and the steps may be performed in the order shown or in a different order.

[0095] Figure 5 An example of a wireless communication system 500 is shown. For convenience and not limitation, the exemplary system 100 is described in the context of Long Term Evolution (LTE) and fifth generation (5G) New Radio (NR) communication standards, as defined by the Third Generation Partnership Project (3GPP) technical specifications. More specifically, the wireless communication system 500 is described in the context of a non-standalone (NSA) network (e.g., E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity (EN-DC) network and a NE-DC network) that combines both LTE and NR. However, the wireless communication system 500 may also be a standalone (SA) network that combines only NR. In addition, other types of communication standards are also possible, including future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like.

[0096] like Figure 5As shown, system 500 includes UE 501a and UE 501b (collectively referred to as "UEs 501" or "UE 501"). In this example, UE 501 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, a mobile phone, a smartphone, a feature phone, a tablet computer, a wearable computer device, a personal digital assistant (PDA), a pager, a wireless handheld device, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-car entertainment (ICE) device, an instrument panel (IC), a head-up display (HUD) device, an on-board diagnostic (OBD) device, a dashtop mobile equipment (DME), a mobile data terminal (MDT), an electronic engine management system (EEMS), an electronic / engine electronic control unit (ECU), an electronic / engine electronic control module (ECM), an embedded system, a microcontroller, a control module, an engine management system (EMS), a connected or "smart" appliance, a MTC device, an M2M device, an IoT device, etc.

[0097] In some embodiments, any of the UEs 501 may be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, ProSe or D2D communications, a sensor network, or an IoT network. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0098] UE 501 may be configured to connect, e.g., be communicatively coupled, to RAN 510. In an embodiment, RAN 510 may be an NG RAN or 5G RAN, E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN" or the like may refer to RAN 510 operating in NR or 5G systems 500, while the term "E-UTRAN" or the like may refer to RAN 510 operating in LTE or 4G systems 500. UE 501 utilizes connections (or channels) 503 and 504, respectively, each of which includes a physical communication interface or layer (discussed in further detail below).

[0099] In this example, connection 503 and connection 504 are shown as air interfaces to achieve communication coupling and may be consistent with a cellular communication protocol, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, an advanced long term evolution (LTE-A) protocol, an LTE-based unlicensed spectrum access (LTE-U), a 5G protocol, a NR protocol, an NR-based unlicensed spectrum access (NR-U) protocol, and / or any other communication protocol discussed herein. In an embodiment, the UE 501 may directly exchange communication data via a ProSe interface 505. The ProSe interface 505 may alternatively be referred to as an SL interface 505 and may include one or more logical channels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0100] UE 501b is shown as being configured to access AP 506 (also referred to as "WLAN node 506," "WLAN 506," "WLAN terminal 506," "WT 506," etc.) via connection 507. Connection 507 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein AP 506 would include Wireless Fidelity. Router. In this example, AP 506 is shown connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 501b, RAN 510, and AP 506 can be configured to utilize LWA operation and / or LWIP operation. LWA operation can involve UE 501b in an RRC_CONNECTED state being configured by RAN nodes 511a-b to utilize radio resources of LTE and WLAN. LWIP operation can involve UE 501b using WLAN radio resources (e.g., connection 507) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent over connection 507. IPsec tunneling can include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0101] RAN 510 includes one or more AN nodes or RAN nodes 511a and 511b (collectively referred to as "multiple RAN nodes 511" or "RAN nodes 511") that enable connections 503 and 504. As used herein, the terms "access node," "access point," and the like may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, or TRPs, and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node" and the like may refer to RAN nodes 511 (e.g., gNBs) operating in NR or 5G systems 500, while the terms "E-UTRAN node" and the like may refer to RAN nodes 511 (e.g., eNBs) operating in LTE or 4G systems 500. According to various embodiments, the RAN node 511 may be implemented as one or more dedicated physical devices such as a macrocell base station and / or a low power (LP) base station for providing a femtocell, picocell or other similar cell with a smaller coverage area, smaller user capacity or higher bandwidth than a macrocell.

[0102] In some embodiments, all or part of the multiple RAN nodes 511 may be implemented as one or more software entities running on a server computer as part of a virtual network that may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN functional partitioning such as PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP, while other L2 protocol entities are operated by individual RAN nodes 511; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes 511; or "lower PHY" partitioning, where the RRC, PDCP, RLC, MAC layers, and upper portions of the PHY layers are operated by the CRAN / vBBUP, and the lower portions of the PHY layers are operated by individual RAN nodes 511. This virtualization framework allows idle processor cores of the multiple RAN nodes 511 to execute other virtualized applications. In some implementations, a separate RAN node 511 may represent a separate RAN node 511 connected to the RAN via a separate F1 interface ( Figure 5 In these implementations, the gNB-DU may include one or more remote radio heads or RFEMs (see, e.g., Figure 7), and the gNB-CU may be operated by a server (not shown) located in the RAN 510 or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 511 may be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol terminations to multiple UEs 501 and is connected to the 5GC via an NG interface (discussed below).

[0103] In a V2X scenario, one or more of the RAN nodes 511 may be or function as an RSU. The term "roadside unit" or "RSU" may refer to any traffic infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a "UE-type RSU," an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU," and so on. In one example, the RSU is a computing device coupled to RF circuitry located on the roadside that provides connectivity support to passing vehicle UEs 501 (vUEs 501). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Short Range Communication (DSRC) band to provide extremely low latency communications required for high-speed events, such as collision avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the computing device and the RSU's RF circuitry may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or backhaul network.

[0104] Any of the multiple RAN nodes 511 may serve as the endpoint for the air interface protocol and may be the first point of contact for multiple UEs 501. In some embodiments, any of the multiple RAN nodes 511 may perform various logical functions of the RAN 510, including but not limited to functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0105] In an embodiment, UE 501 may be configured to communicate with each other or with any of the AN nodes in RAN node 511 using OFDM communication signals over a multi-carrier communication channel according to various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communication) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiment is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0106] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 511 to the UE 501, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink in each time slot. This type of time-frequency plane representation is common for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a collection of resource elements; in the frequency domain, this can represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0107] According to various embodiments, the UE 501 and the RAN node 511 communicate data (e.g., transmit data and receive data) over a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include the 5 GHz band. NR in the unlicensed spectrum may be referred to as NR-U, and LTE in the unlicensed spectrum may be referred to as LTE-U, License Assisted Access (LAA), or MulteFire.

[0108] To operate in the unlicensed spectrum, the UE 501 and the RAN node 511 may operate using LAA, eLAA, and / or feLAA mechanisms. In these implementations, the UE 501 and the RAN node 511 may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to a listen-before-talk (LBT) protocol.

[0109] LBT is a mechanism by which equipment (e.g., UE 501, RAN node 511, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine whether other signals are present on the channel in order to determine whether the channel is occupied or idle. The LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy over a period of time on an intended transmission band and comparing the sensed RF energy to a predefined or configured threshold.

[0110] Typically, existing systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism known as CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 501, AP 506, etc.) intends to transmit, the WLAN node may first perform CCA before transmitting. In addition, in the event that more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. The backoff mechanism may be a counter randomly introduced within the CWS that increases exponentially when a collision occurs and is reset to a minimum value when the transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLAN. In some implementations, the LBT process for a DL or UL transmission burst (including PDSCH or PUSCH transmission) may have an LAA contention window of variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values of the CWS for LAA. In one example, the minimum CWS for LAA transmissions may be 9 microseconds (μs); however, the size of the CWS and MCOT (eg, transmission burst) may be based on government regulatory requirements.

[0111] The LAA mechanism is built on the Carrier Adaptation (CA) technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, resulting in a maximum aggregate bandwidth of 100 MHz. In an FDD system, the number of aggregated carriers can be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, each CC can have a different bandwidth than other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are generally the same for DL and UL.

[0112] CA also includes individual serving cells to provide individual CCs. The coverage of the serving cells may be different, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell or PCell may provide the PCC for both UL and DL and may handle activities related to RRC and NAS. The other serving cells are called SCells, and each SCell may provide individual SCCs for both UL and DL. SCCs may be added and removed as needed, and changing the PCC may require the UE 501 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in unlicensed spectrum (referred to as "LAA SCells"), and the LAA SCells are assisted by the PCells operating in the licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive UL grants on the configured LAA SCells indicating different PUSCH starting positions within the same subframe.

[0113] The PDSCH carries user data and higher-layer signaling to multiple UEs 501. The PDCCH carries, among other information, information about the transport format and resource allocation associated with the PDSCH channel. It can also inform UEs 501 about the transport format, resource allocation, and HARQ information associated with the uplink shared channel. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UEs 501b within a cell) can be performed on any of the RAN nodes 511 based on channel quality information fed back from any of the UEs 501. Downlink resource allocation information can be sent on the PDCCH for (e.g., allocated to) each of the multiple UEs 501.

[0114] PDCCH uses CCE to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, respectively, called REGs. Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).

[0115] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize EPDCCH that uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to a set of nine physical resource elements, called EREGs, including four physical resource elements. In some cases, an ECCE may have other numbers of EREGs.

[0116] RAN nodes 511 may be configured to communicate with each other via interface 512. In embodiments where system 500 is an LTE system (eg, when CN 520 is a Figure 6 ), the interface 512 may be an X2 interface 512. The X2 interface may be defined between two or more RAN nodes 511 (e.g., two or more eNBs, etc.) connected to the EPC 520, and / or between two eNBs connected to the EPC 520. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user packets transmitted over the X2 interface and may be used to convey information regarding the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information regarding user data transmitted from the MeNB to the SeNB; information regarding successful in-sequence delivery of PDCP PDUs for user data from the SeNB to the UE 501; information regarding PDCP PDUs that were not delivered to the UE 501; information regarding the current minimum expected buffer size at the SeNB for transmitting user data to the UE; and the like. X2-C provides intra-LTE access mobility functions, including context transfer from the source eNB to the target eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0117] In embodiments where system 500 is a 5G or NR system, interface 512 may be an Xn interface 512. The Xn interface is defined between two or more RAN nodes 511 (e.g., two or more gNBs, etc.) connected to a 5GC 520, between a RAN node 511 (e.g., a gNB) and an eNB connected to a 5GC 520, and / or between two eNBs connected to a 5GC 520. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U interface may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C interface may provide management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 501 in connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected mode between one or more RAN nodes 511. This mobility support may include context transfer from the old (source) serving RAN node 511 to the new (target) serving RAN node 511, as well as control of the user plane tunnel between the old (source) serving RAN node 511 and the new (target) serving RAN node 511. The Xn-U protocol stack may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer built on top of the UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be built on top of the IP layer and may provide guaranteed delivery of application layer messages. Within the transport IP layer, signaling PDUs are delivered using point-to-point transport. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0118] RAN 510 is shown as being communicatively coupled to a core network—in this embodiment, to a core network (CN) 520. CN 520 may include multiple network elements 522 configured to provide various data and telecommunication services to customers / users (e.g., users of UE 501) connected to CN 520 via RAN 510. Components of CN 520 may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, NFV may be used to virtualize any or all of the aforementioned network node functions (described in further detail below) via executable instructions stored on one or more computer-readable storage media. A logical instance of CN 520 may be referred to as a network slice, and a logical instance of a portion of CN 520 may be referred to as a network sub-slice. NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (alternatively, performed by proprietary hardware). In other words, the NFV system can be used to perform virtual or reconfigurable implementations of one or more EPC components / functions.

[0119] Generally speaking, the application server 530 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). The application server 530 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social network services, etc.) for the UE 501 via the EPC 520.

[0120] In an embodiment, CN 520 may be a 5GC (referred to as "5GC 520" or the like), and RAN 510 may be connected to CN 520 via an NG interface 513. In an embodiment, NG interface 513 may be divided into two parts: an NG user plane (NG-U) interface 514, which carries traffic data between RAN node 511 and UPF; and an S1 control plane (NG-C) interface 515, which is a signaling interface between RAN node 511 and AMF.

[0121] In an embodiment, CN 520 may be a 5G CN (referred to as "5GC 520," etc.), while in other embodiments, CN 520 may be an EPC. In the case where CN 520 is an EPC (referred to as "EPC 520," etc.), RAN 510 may be connected to CN 520 via an S1 interface 513. In an embodiment, S1 interface 513 may be divided into two parts: an S1 user plane (S1-U) interface 514, which carries traffic data between RAN node 511 and S-GW; and an S1-MME interface 515, which is a signaling interface between RAN node 511 and MME.

[0122] Figure 6 FIG. 6 illustrates an exemplary architecture of a system 600 including a first CN 620 according to various embodiments. In this example, the system 600 may implement the LTE standard, wherein the CN 620 is a Figure 5 In addition, UE 601 can communicate with Figure 5 The UE 501 is the same as or similar to the UE 501, and the E-UTRAN 610 may be Figure 5 The CN 620 may be a RAN that is the same as or similar to the RAN 510 of the mobile network and may include the RAN node 511 discussed previously. The CN 620 may include an MME 621 , an S-GW 622 , a P-GW 623 , an HSS 624 , and an SGSN 625 .

[0123] MME 621 may be functionally similar to the control plane of a traditional SGSN and may implement MM functionality to keep track of the current location of UE 601. MME 621 may perform various MM procedures to manage mobility aspects of access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in E-UTRAN systems) may refer to all applicable procedures, methods, data stores, etc. used to maintain knowledge of the current location of UE 601, provide user identity confidentiality to users / subscribers, and / or perform other similar services. Each UE 601 and MME 621 may include an MM or EMM sublayer, and upon successful completion of the attach procedure, an MM context may be established in UE 601 and MME 621. An MM context may be a data structure or database object that stores MM-related information for UE 601. The MME 621 may be coupled to the HSS 624 via an S6a reference point, to the SGSN 625 via an S3 reference point, and to the S-GW 622 via an S11 reference point.

[0124] The SGSN 625 may be a node that serves the UE 601 by tracking the location of the individual UE 601 and performing security functions. Furthermore, the SGSN 625 may perform inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by the MME 621; handling of UE 601 time zone capabilities, as specified by the MME 621; and MME selection for handover to the E-UTRAN 3GPP access network. The S3 reference point between the MME 621 and the SGSN 625 may enable the exchange of user and bearer information for inter-3GPP access network mobility in idle and / or active states.

[0125] The HSS 624 may include a database for network users, including subscription-related information used to support network entities handling communication sessions. The EPC 620 may include one or several HSSs 624, depending on the number of mobile subscribers, equipment capacity, network organization, and the like. For example, the HSS 624 may provide support for routing / roaming, authentication, authorization, naming / addressing solutions, location dependencies, and the like. The S6a reference point between the HSS 624 and the MME 621 may enable the transfer of subscription and authentication data for authenticating / authorizing users to access the EPC 620 between the HSS 624 and the MME 621.

[0126] The S-GW 622 may terminate the S1 interface 513 towards the RAN 610 ( Figure 6 The S-GW 622 is a RAN-based gateway ("S1-U" in

[15] ) and routes data packets between the RAN 610 and the EPC 620. Additionally, the S-GW 622 can be the local mobility anchor for inter-RAN node handovers and can also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and enforcing certain policies. The S11 reference point between the S-GW 622 and the MME 621 can provide a control plane between the MME 621 and the S-GW 622. The S-GW 622 can be coupled to the P-GW 623 via the S5 reference point.

[0127] The P-GW 623 may terminate the SGi interface towards the PDN 630. The P-GW 623 may communicate with the PDN 630 via the IP interface 525 (see, e.g., Figure 5 ) routes data packets between EPC 620 and external networks such as a network including application server 530 (alternatively referred to as "AF"). In an embodiment, P-GW 623 can communicate with the EPC 620 via IP communication interface 525 (see, e.g., Figure 5 ) is communicatively coupled to an application server ( Figure 5 Application server 530 or Figure 6630 in the PDN). The S5 reference point between the P-GW 623 and the S-GW 622 can provide user plane tunneling and tunnel management between the P-GW 623 and the S-GW 622. Due to the mobility of the UE 601 and whether the S-GW 622 needs to be connected to a non-colocated P-GW 623 for the required PDN connectivity, the S5 reference point can also be used for S-GW 622 relocation. The P-GW 623 may also include nodes for policy enforcement and charging data collection, such as PCEF (not shown). In addition, the SGi reference point between the P-GW 623 and the packet data network (PDN) 630 can be an operator-external public, private PDN, or an internal operator packet data network, for example, for providing IMS services. The P-GW 623 can be coupled to the PCRF 626 via the Gx reference point.

[0128] PCRF 626 is the policy and charging control element of EPC 620. In a non-roaming scenario, a single PCRF 626 may exist in the Home Public Land Mobile Network (HPLMN) associated with UE 601's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local traffic breakout, two PCRFs may be associated with UE 601's IP-CAN session: a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). PCRF 626 may be communicatively coupled to application server 630 via P-GW 623. Application server 630 may signal PCRF 626 to indicate a new service flow and select appropriate QoS and charging parameters. PCRF 626 may configure the rules with the PCEF (not shown) with the appropriate TFT and QCI, which initiates QoS and charging as specified by application server 630. The Gx reference point between PCRF 626 and P-GW 623 may allow for the transfer of QoS policies and charging rules from PCRF 626 to PCEF in P-GW 623. The Rx reference point may reside between PDN 630 (or "AF 630") and PCRF 626.

[0129] Figure 7 An example of infrastructure equipment 700 according to various embodiments is shown. Infrastructure equipment 700 (or "system 700") can be implemented as a base station, a radio head, a RAN node (such as the RAN node 511 and / or AP 506 shown and described previously), an application server 530, and / or any other element / device discussed herein. In other examples, system 700 can be implemented in or by a UE.

[0130] System 700 may include application circuitry 705, baseband circuitry 710, one or more radio front-end modules 715, memory circuitry 720, a power management integrated circuit (PMIC) 725, a power tee circuit 730, a network controller circuit 735, a network interface connector 740, satellite positioning circuitry 745, and a user interface 750. In some embodiments, device 700 may include additional elements such as, for example, memory / storage, a display, a camera, sensors, or input / output (I / O) interfaces. In other embodiments, these components may be included in more than one device. For example, the circuitry may be separately included in more than one device for a CRAN, vBBU, or other similar implementation.

[0131] The application circuit 705 may include circuits such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: a low dropout regulator (LDO), an interrupt controller, a serial interface such as SPI, I2C, or a general-purpose programmable serial interface module, a real-time clock (RTC), a timer-counter including an interval timer and a watchdog timer, general-purpose input / output (I / O or IO), a memory card controller such as a secure digital (SD) multimedia card (MMC) or similar product, a universal serial bus (USB) interface, a mobile industry processor interface (MIPI) interface, and a joint test access group (JTAG) test access port. The processor (or core) of the application circuit 705 may be coupled to or include a memory / storage element and may be configured to execute instructions stored in the memory / storage element to enable various applications or operating systems to run on the system 700. In some implementations, the memory / storage element can be an on-chip memory circuit that can include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0132] The processor of the application circuit 705 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuit 705 may include or may be a dedicated processor / controller for operating in accordance with various embodiments herein. As an example, the processor of the application circuit 705 may include one or more Apple A series processors, Intel or Processor; Advanced Micro Devices (AMD) Processor, Accelerated Processing Unit (APU), or processors; ARM-based processors licensed from ARM Holdings, Ltd., such as the ARM Cortex-A series processors and MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processor; etc. In some embodiments, system 700 may not utilize application circuitry 705 and instead may include a dedicated processor / controller to process IP data received, for example, from an EPC or 5GC.

[0133] In some implementations, the application circuit 705 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, and the like. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, the programmable processing device may be one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs); programmable logic devices (PLDs), such as complex PLDs (CPLDs) and high-capacity PLDs (HCPLDs); ASICs, such as structured ASICs; programmable SoCs (PSoCs); and the like. In such implementations, the circuitry of the application circuit 705 may include logic blocks or logic fabrics, as well as other interconnected resources that can be programmed to perform various functions, such as the procedures, methods, functions, and the like of the various embodiments discussed herein. In such an embodiment, the circuitry of the application circuit 705 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), anti-fuse, etc.)) for storing logic blocks, logic structures, data, etc. in lookup tables (LUTs), etc.

[0134] The baseband circuit 710 may be implemented, for example, as a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Figure 8 The various hardware electronic components of baseband circuit 710 are discussed.

[0135] The user interface circuitry 750 may include one or more user interfaces designed to enable a user to interact with the system 700 or a peripheral component interface designed to enable a peripheral component to interact with the system 700. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio transmitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power port, etc.

[0136] The radio front end module (RFEM) 715 may include a millimeter wave (mmWave) RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separate from the mmWave RFEM. The RFIC may include connections to one or more antennas or antenna arrays (see, for example, below). Figure 8The antenna array 811 is configured such that the RFEM can be connected to multiple antennas. In an alternative embodiment, both millimeter-wave and sub-millimeter-wave radio functions can be implemented in the same physical RFEM 715 that combines both millimeter-wave antennas and sub-millimeter-wave antennas.

[0137] The memory circuit 720 may include one or more of the following: a volatile memory including a dynamic random access memory (DRAM) and / or a synchronous dynamic random access memory (SDRAM), a non-volatile memory (NVM) including a high-speed electrically erasable memory (commonly referred to as a "flash memory"), a phase change random access memory (PRAM), a magnetoresistive random access memory (MRAM), etc., and may be combined with and The memory circuit 720 may be implemented as one or more of the following: a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

[0138] The PMIC 725 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources, such as batteries or capacitors. The power alarm detection circuit may detect one or more of a brownout (brownout) and a surge (overvoltage). The power tee circuit 730 may provide power drawn from the network cable to provide both power and data connectivity for the infrastructure equipment 700 using a single cable.

[0139] The network controller circuit 735 can provide connectivity to the network using a standard network interface protocol such as Ethernet, Ethernet based on GRE tunnels, Ethernet based on Multi-Protocol Label Switching (MPLS), or some other suitable protocol. Network connectivity can be provided to / from the infrastructure equipment 700 via the network interface connector 740 using a physical connection, which can be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 735 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 735 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0140] The positioning circuit 745 includes circuits for receiving and decoding signals transmitted / broadcasted by the positioning network of the global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) include the United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, regional navigation systems or GNSS augmentation systems (e.g., navigation using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbit Chart and Satellite Integrated Radio Positioning (DORIS), etc.). The positioning circuit 745 includes various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. for facilitating OTA communication) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 745 may include a micro technology (micro PNT) IC for positioning, navigation, and timing that uses a master timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 745 may also be part of or interact with the baseband circuit 710 and / or RFEM 715 to communicate with nodes and components of the positioning network. The positioning circuit 745 may also provide location data and / or time data to the application circuit 705, which may use the data to synchronize operations with various infrastructure (e.g., RAN node 511, etc.).

[0141] Figure 7 The components shown can communicate with each other using interface circuitry that can include any number of bus and / or interconnect (IX) technologies, such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI express (PCIe), or any number of other technologies. The bus / IX can be a proprietary bus, such as used in SoC-based systems. Other bus / IX systems can be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

[0142] Figure 8 Exemplary components of a baseband circuit 810 and a radio front end module (RFEM) 815 are shown according to various embodiments. The baseband circuit 810 corresponds to Figure 7 Baseband circuit 710. RFEM 815 corresponds to Figure 7 RFEM 715. As shown, RFEM 815 may include radio frequency (RF) circuitry 806, front end module (FEM) circuitry 808, and an antenna array 811 coupled together at least as shown.

[0143] The baseband circuitry 810 includes circuitry and / or control logic components configured to execute various radio / network protocols and radio control functions that enable communication with one or more radio networks via the RF circuitry 806. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of the baseband circuitry 810 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuitry 810 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functions. The implementation of the modulation / demodulation and encoder / decoder functions is not limited to these examples and may include other suitable functions in other embodiments. The baseband circuitry 810 is configured to process baseband signals received from the receive signal path of the RF circuitry 806 and to generate baseband signals for the transmit signal path of the RF circuitry 806. The baseband circuitry 810 is configured to communicate with the application circuitry 705 (see Figure 7 ) to generate and process baseband signals and control the operation of RF circuit 806. Baseband circuit 810 can handle various radio control functions.

[0144] The aforementioned circuits and / or control logic components of the baseband circuitry 810 may include one or more single-core or multi-core processors. For example, the one or more processors may include a 3G baseband processor 804A, a 4G / LTE baseband processor 804B, a 5G / NR baseband processor 804C, or some other baseband processor 804D for other existing, developing, or future generations (e.g., the sixth generation (6G), etc.). In other embodiments, some or all of the functions of the baseband processors 804A to 804D may be included in modules stored in the memory 804G and executed via the central processing unit (CPU) 804E. In other embodiments, some or all of the functions of the baseband processors 804A to 804D may be provided as hardware accelerators (e.g., FPGAs, ASICs, etc.) loaded with appropriate bitstreams or logic blocks stored in corresponding memory units. In various embodiments, the memory 804G may store program code of a real-time OS (RTOS) that, when executed by the CPU 804E (or other baseband processor), enables the CPU 804E (or other baseband processor) to manage resources of the baseband circuit 810, schedule tasks, etc. Examples of RTOS may include Operating System Embedded (OSE) TM , by Mentor Nucleus RTOS provided TM , by Mentor Versatile Real-TimeExecutive (VRTX) provided by Express ThreadX TM ,Depend on FreeRTOS and REX OS provided by Open Kernel (OK) The baseband circuit 810 may include one or more audio digital signal processors (DSPs) 804F. The audio DSPs 804F may include elements for compression / decompression and echo cancellation, and may include other suitable processing elements in other embodiments.

[0145] In some embodiments, each of processors 804A to 804E includes a corresponding memory interface to send data to / receive data from memory 804G. Baseband circuit 810 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as an interface for sending data to / receiving data from a memory external to baseband circuit 810; an interface for sending data to / receiving data from a memory external to baseband circuit 810; Figure 7 and Figure 8 Application circuit interface for sending data to / receiving data from the application circuit 705; Figure 8 RF circuit 806 to send data / receive data from the RF circuit RF circuit interface; for receiving data from one or more wireless hardware elements (e.g., near field communication (NFC) components, Low power consumption components, components, etc.) to send data / receive data from these wireless hardware elements; and a power management interface for sending power or control signals to / receiving power or control signals from the PMIC.

[0146] In an alternative embodiment (which may be combined with the above embodiment), the baseband circuit 810 includes one or more digital baseband systems that are coupled to each other and to the CPU subsystem, audio subsystem, and interface subsystem via an interconnect subsystem. The digital baseband subsystem may also be coupled to a digital baseband interface and a mixed-signal baseband subsystem via another interconnect subsystem. Each of the interconnect subsystems may include a bus system, a point-to-point connection, a network on chip (NOC) structure, and / or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include a DSP circuit, a buffer memory, a program memory, a voice processing accelerator circuit, a data converter circuit such as an analog-to-digital converter circuit and a digital-to-analog converter circuit, an analog circuit including one or more of an amplifier and a filter, and / or other similar components. In one aspect of the present disclosure, the baseband circuit 810 may include a protocol processing circuit having one or more control circuit instances (not shown) to provide control functions for the digital baseband circuit and / or the radio frequency circuit (e.g., a radio front-end module 815).

[0147] although Figure 8 Although not shown, in some embodiments, the baseband circuitry 810 includes various processing devices (e.g., a "multi-protocol baseband processor" or "protocol processing circuitry") for operating one or more wireless communication protocols and various processing devices for implementing PHY layer functions. In these embodiments, the PHY layer functions include the aforementioned radio control functions. In these embodiments, the protocol processing circuitry operates or implements various protocol layers / entities of one or more wireless communication protocols. In a first example, when the baseband circuitry 810 and / or the RF circuitry 806 are part of millimeter wave communication circuitry or some other suitable cellular communication circuitry, the protocol processing circuitry may operate LTE protocol entities and / or 5G / NR protocol entities. In the first example, the protocol processing circuitry will operate MAC, RLC, PDCP, SDAP, RRC, and NAS functions. In a second example, when the baseband circuitry 810 and / or the RF circuitry 806 are part of a Wi-Fi communication system, the protocol processing circuitry may operate one or more IEEE-based protocols. In the second example, the protocol processing circuitry will operate Wi-Fi MAC and Logical Link Control (LLC) functions. The protocol processing circuitry may include one or more memory structures (e.g., 804G) for storing program code and data for operating protocol functions, and one or more processing cores for executing program code and performing various operations using data. The baseband circuitry 810 may also support radio communications for more than one wireless protocol.

[0148] The various hardware elements of the baseband circuit 810 discussed herein may be implemented as, for example, a solder-in substrate comprising one or more integrated circuits (ICs), a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module comprising two or more ICs. In one example, the components of the baseband circuit 810 may be appropriately combined in a single chip or a single chipset, or provided on the same circuit board. In another example, some or all of the components of the baseband circuit 810 and the RF circuit 806 may be implemented together, such as, for example, a system on a chip (SOC) or a system in a package (SiP). In another example, some or all of the components of the baseband circuit 810 may be implemented as a separate SoC communicatively coupled to the RF circuit 806 (or multiple instances of the RF circuit 806). In yet another example, some or all of the components of the baseband circuit 810 and the application circuit 705 may be implemented together as a separate SoC mounted to the same circuit board (e.g., a "multi-chip package").

[0149] In some embodiments, the baseband circuitry 810 can provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 810 can support communications with E-UTRAN or other WMANs, WLANs, or WPANs. Embodiments in which the baseband circuitry 810 is configured to support radio communications using more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0150] RF circuitry 806 can communicate with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, RF circuitry 806 can include switches, filters, amplifiers, etc. to facilitate communication with the wireless network. RF circuitry 806 can include a receive signal path that can include circuitry for down-converting RF signals received from FEM circuitry 808 and providing baseband signals to baseband circuitry 810. RF circuitry 806 can also include a transmit signal path that can include circuitry for up-converting baseband signals provided by baseband circuitry 810 and providing an RF output signal to FEM circuitry 808 for transmission.

[0151] In some embodiments, the receive signal path of RF circuitry 806 may include mixer circuitry 806a, amplifier circuitry 806b, and filter circuitry 806c. In some embodiments, the transmit signal path of RF circuitry 806 may include filter circuitry 806c and mixer circuitry 806a. RF circuitry 806 may also include synthesizer circuitry 806d for synthesizing frequencies used by mixer circuitry 806a in the receive and transmit signal paths. In some embodiments, mixer circuitry 806a in the receive signal path may be configured to downconvert the RF signal received from FEM circuitry 808 based on the synthesized frequency provided by synthesizer circuitry 806d. Amplifier circuitry 806b may be configured to amplify the downconverted signal, and filter circuitry 806c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 810 for further processing. In some embodiments, the output baseband signal may be a zero-frequency baseband signal, although this is not required.In some embodiments, the mixer circuit 806a of the receive signal path may include a passive mixer, although the scope of the embodiments is not limited in this respect.

[0152] In some embodiments, mixer circuit 806a of the transmit signal path can be configured to upconvert an input baseband signal based on a synthesized frequency provided by synthesizer circuit 806d to generate an RF output signal for FEM circuit 808. The baseband signal can be provided by baseband circuit 810 and can be filtered by filter circuit 806c.

[0153] In some embodiments, the mixer circuit 806a of the receive signal path and the mixer circuit 806a of the transmit signal path may include two or more mixers and may be arranged for quadrature down conversion and quadrature up conversion, respectively. In some embodiments, the mixer circuit 806a of the receive signal path and the mixer circuit 806a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 806a of the receive signal path and the mixer circuit 806a of the transmit signal path may be arranged for direct down conversion and direct up conversion, respectively. In some embodiments, the mixer circuit 806a of the receive signal path and the mixer circuit 806a of the transmit signal path may be configured for superheterodyne operation.

[0154] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 806 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 810 may include a digital baseband interface to communicate with RF circuitry 806.

[0155] In some dual-mode embodiments, separate radio IC circuits may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0156] In some embodiments, synthesizer circuit 806 d can be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the scope of the embodiments is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 806 d can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0157] Synthesizer circuit 806d may be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 806a of RF circuit 806. In some embodiments, synthesizer circuit 806d may be a fractional-N / N+1 synthesizer.

[0158] In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), although this is not required. The divider control input may be provided by baseband circuitry 810 or application circuitry 705 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by application circuitry 705.

[0159] The synthesizer circuit 806d of the RF circuit 806 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode frequency divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a cascaded, tunable delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay element may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0160] In some embodiments, the synthesizer circuit 806d can be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used with a quadrature generator and divider circuit to generate multiple signals with multiple different phases relative to each other at the carrier frequency. In some embodiments, the output frequency can be the LO frequency (fLO). In some embodiments, the RF circuit 806 can include an IQ / polarity converter.

[0161] The FEM circuitry 808 may include a receive signal path that may include circuitry configured to operate on RF signals received from the antenna array 811, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 806 for further processing. The FEM circuitry 808 may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuitry 806 for transmission by one or more antenna elements in the antenna array 811. In various embodiments, amplification by the transmit or receive signal path may be performed only in the RF circuitry 806, only in the FEM circuitry 808, or in both the RF circuitry 806 and the FEM circuitry 808.

[0162] In some embodiments, the FEM circuitry 808 may include a TX / RX switch to switch between transmit and receive modes of operation. The FEM circuitry 808 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 808 may include an LNA to amplify a received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuitry 806). The transmit signal path of the FEM circuitry 808 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuitry 806), and one or more filters for generating an RF signal for subsequent transmission by one or more antenna elements of the antenna array 811.

[0163] The antenna array 811 includes one or more antenna elements, each configured to convert electrical signals into radio waves for travel through the air and to convert received radio waves into electrical signals. For example, a digital baseband signal provided by the baseband circuit 810 is converted into an analog RF signal (e.g., a modulated waveform), which is amplified and transmitted via the antenna elements of the antenna array 811, which includes one or more antenna elements (not shown). The antenna elements can be omnidirectional, directional, or a combination thereof. The antenna elements can be formed into various arrangements as known and / or discussed herein. The antenna array 811 can include microstrip antennas or printed antennas fabricated on the surface of one or more printed circuit boards. The antenna array 811 can be formed as patches of metal foil of various shapes (e.g., patch antennas) and can be coupled to the RF circuitry 806 and / or the FEM circuitry 808 using metal transmission lines, etc.

[0164] The processor of the application circuitry 705 and the processor of the baseband circuitry 810 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuitry 810 can be used, alone or in combination, to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 705 can utilize data received from these layers (e.g., packet data) and further perform layer 4 functions (e.g., TCP layer and UDP layer). As mentioned herein, layer 3 may include the RRC layer, which is described in further detail below. As mentioned herein, layer 2 may include the MAC layer, the RLC layer, and the PDCP layer, which are described in further detail below. As mentioned herein, layer 1 may include the PHY layer of the UE / RAN node, which is described in further detail below.

[0165] Figure 9 Various protocol functions that can be implemented in wireless communication devices according to various embodiments are shown. Specifically, Figure 9 The present invention includes an arrangement 900 showing the interconnection between various protocol layers / entities. The present invention provides various protocol layers / entities for operating in conjunction with the 5G / NR system standard and the LTE system standard. Figure 9 The following description, but Figure 9 Some or all aspects of the present invention may also be applicable to other wireless communication network systems.

[0166] In addition to other higher layer functionality not shown, the protocol layers of arrangement 900 may include one or more of PHY 910, MAC 920, RLC 930, PDCP 940, SDAP 947, RRC 955, and NAS layer 957. These protocol layers may include one or more service access points (e.g., Figure 9 Items 959, 956, 950, 949, 945, 935, 925, and 915).

[0167] PHY 910 can transmit and receive physical layer signals 905, which can be received from or transmitted to one or more other communication devices. Physical layer signals 905 may include one or more physical channels, such as those discussed herein. PHY 910 may also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes) and other measurements used by higher layers (e.g., RRC 955). PHY 910 may also further perform error detection on transport channels, forward error correction (FEC) encoding / decoding of transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and MIMO antenna processing. In an embodiment, an instance of PHY 910 may process a request from an instance of MAC 920 via one or more PHY-SAP 915 and provide an indication thereto. According to some embodiments, the request and indication transmitted via PHY-SAP 915 may include one or more transport channels.

[0168] An instance of MAC 920 may process requests from an instance of RLC 930 via one or more MAC-SAPs 925 and provide instructions thereto. These requests and instructions transmitted via MAC-SAP 925 may include one or more logical channels. MAC 920 may perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto TBs to be delivered to PHY 910 via transport channels, demultiplexing MAC SDUs from TBs delivered from PHY 910 via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via HARQ, and logical channel prioritization.

[0169] Instances of RLC 930 may process requests from instances of PDCP 940 via one or more Radio Link Control Service Access Points (RLC-SAPs) 935 and provide indications thereto. These requests and indications transmitted via RLC-SAPs 935 may include one or more RLC channels. RLC 930 may operate in multiple modes of operation, including Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC 930 may perform transmission of upper layer protocol data units (PDUs), error correction via Automatic Repeat Request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. RLC 930 may also perform resegmentation of RLC data PDUs for AM data transmission, reorder RLC data PDUs for UM and AM data transmission, detect duplicate data for UM and AM data transmission, discard RLC SDUs for UM and AM data transmission, detect protocol errors for AM data transmission, and perform RLC re-establishment.

[0170] An instance of PDCP 940 may process requests from an instance of RRC 955 and / or an instance of SDAP 947 via one or more Packet Data Convergence Protocol Service Points (PDCP-SAPs) 945 and provide instructions thereto. These requests and instructions conveyed via PDCP-SAP 945 may include one or more radio bearers. PDCP 940 may perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), enforce in-sequence delivery of upper layer PDUs upon lower layer reestablishment, eliminate duplication of lower layer SDUs upon lower layer reestablishment for radio bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discard, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0171] An instance of SDAP 947 can process requests from one or more higher-layer protocol entities via one or more SDAP-SAPs 949 and provide instructions thereto. These requests and instructions transmitted via SDAP-SAP 949 may include one or more QoS flows. SDAP 947 can map QoS flows to DRBs and vice versa, and can also mark the QFI in DL and UL packets. A single SDAP entity 947 can be configured for a single PDU session. In the UL direction, the NG-RAN 510 can control the mapping of QoS flows to DRBs in two different ways: reflective mapping or explicit mapping. For reflective mapping, the SDAP 947 of the UE 501 can monitor the QFI of the DL packets for each DRB and apply the same mapping to packets flowing in the UL direction. For a DRB, the SDAP 947 of the UE 501 can map UL packets belonging to a QoS flow corresponding to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflective mapping, the NG-RAN can mark DL packets with the QoS flow ID over the Uu interface. Explicit mapping may involve RRC 955 configuring SDAP 947 with explicit mapping rules for QoS flows to DRBs, which may be stored and followed by SDAP 947. In an embodiment, SDAP 947 may only be used in NR implementations and may not be used in LTE implementations.

[0172] The RRC 955 may configure aspects of one or more protocol layers, which may include one or more instances of the PHY 910, MAC 920, RLC 930, PDCP 940, and SDAP 947, via one or more Management Service Access Points (M-SAPs). In an embodiment, instances of the RRC 955 may process requests from and provide instructions to one or more NAS entities 957 via one or more RRC-SAPs 956. Primary services and functions of the RRC 955 may include broadcasting of system information (e.g., included in a MIB or SIB related to the NAS), broadcasting of system information related to the access stratum (AS), paging, establishment, maintenance, and release of the RRC connection between the UE 501 and the RAN 510 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. These MIBs and SIBs may include one or more IEs, each of which may include a separate data field or data structure.

[0173] The NAS 957 may form the highest layer of the control plane between the UE 501 and the AMF. The NAS 957 may support the mobility and session management procedures of the UE 501 to establish and maintain an IP connection between the UE 501 and the P-GW in the LTE system.

[0174] According to various embodiments, one or more protocol entities of arrangement 900 may be implemented in UE 501, RAN node 511, AMF in NR implementations or MME 621 in LTE implementations, UPF in NR implementations or S-GW 622 and P-GW 623 in LTE implementations, etc., for control plane or user plane communication protocol stacks between the aforementioned devices. In such embodiments, one or more protocol entities implemented in one or more of UE 501, gNB 511, AMF, etc. may communicate with corresponding peer protocol entities implemented in or on another device (such communication being performed using the services of corresponding lower layer protocol entities). In some embodiments, the gNB-CU of gNB 511 may host the RRC 955, SDAP 947, and PDCP 940 of the gNB, which controls the operation of one or more gNB-DUs, and the gNB-DUs of gNB 511 may each host the RLC 930, MAC 920, and PHY 910 of gNB 511.

[0175] In a first example, the control plane protocol stack may include, in order from highest layer to lowest layer, NAS 957, RRC 955, PDCP 940, RLC 930, MAC 920, and PHY 910. In this example, upper layers 960 may be built on top of NAS 957, including an IP layer 961, SCTP 962, and an application layer signaling protocol (AP) 963.

[0176] In an NR implementation, the AP 963 may be an NG application protocol layer (NGAP or NG-AP) 963 for the NG interface 513 defined between the NG-RAN node 511 and the AMF, or the AP 963 may be an Xn application protocol layer (XnAP or Xn-AP) 963 for the Xn interface 512 defined between two or more RAN nodes 511.

[0177] The NG-AP 963 may support the functionality of the NG interface 513 and may include an elementary procedure (EP). The NG-AP EP may be an interaction unit between the NG-RAN point 511 and the AMF. NG-AP 963 services may include two groups: UE-associated services (e.g., services related to the UE 501) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node 511 and the AMF). These services may include functions including, but not limited to: a paging function for sending a paging request to an NG-RAN node 511 involved in a specific paging area; a UE context management function for allowing the AMF to establish, modify and / or release the UE context in the AMF and the NG-RAN node 511; a mobility function for the UE 501 in ECM-CONNECTED mode, for intra-system HO to support mobility within the NG-RAN, and for inter-system HO to support mobility from / to the EPS system; a NAS signaling transport function for transferring or rerouting NAS messages between the UE 501 and the AMF; a NAS node selection function for determining the association between the AMF and the UE 501; an NG interface management function for setting up the NG interface and monitoring errors over the NG interface; a warning message sending function for providing a means to transfer a warning message via the NG interface or to cancel an ongoing warning message broadcast; a configuration transfer function for requesting and transferring RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes 511 via the CN 520; and / or other similar functions.

[0178] The XnAP 963 may support the functions of the Xn interface 512 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures for handling UE mobility within the NG RAN 511 (or E-UTRAN 610), such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, and procedures related to dual connectivity. The XnAP global procedures may include procedures unrelated to a specific UE 501, such as Xn interface setup and reset procedures, NG-RAN update procedures, and cell activation procedures.

[0179] In an LTE implementation, the AP 963 may be an S1 application protocol layer (S1-AP) 963 for the S1 interface 513 defined between the E-UTRAN node 511 and the MME, or the AP 963 may be an X2 application protocol layer (X2AP or X2-AP) 963 for the X2 interface 512 defined between two or more E-UTRAN nodes 511.

[0180] The S1 application protocol layer (S1-AP) 963 may support the functionality of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may include an S1-AP EP. The S1-AP EP may be the interaction unit between the E-UTRAN node 511 and the MME 621 within the LTE CN 520. S1-AP 963 services may include two groups: UE-associated services and non-UE-associated services. These services perform functions including, but not limited to, E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling, RAN Information Management (RIM), and configuration transfer.

[0181] The X2AP 963 may support the functions of the X2 interface 512 and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may include procedures for handling UE mobility within the E-UTRAN 520, such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, and procedures related to dual connectivity. The X2AP global procedures may include procedures unrelated to a specific UE 501, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, and cell activation procedures.

[0182] The SCTP layer (alternatively referred to as the SCTP / IP layer) 962 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations). SCTP 962 can ensure reliable delivery of signaling messages between the RAN node 511 and the AMF / MME 621 based in part on the IP protocol supported by IP 961. The Internet Protocol layer (IP) 961 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 961 can use point-to-point transport to deliver and transmit PDUs. In this regard, the RAN node 511 can include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.

[0183] In a second example, the user plane protocol stack may include, in order from highest layer to lowest layer, SDAP 947, PDCP 940, RLC 930, MAC 920, and PHY 910. The user plane protocol stack may be used for communication between UE 501, RAN node 511, and UPF in an NR implementation, or between S-GW 622 and P-GW 623 in an LTE implementation. In this example, upper layers 951 may be built on top of SDAP 947 and may include a user datagram protocol (UDP) and IP security layer (UDP / IP) 952, a general packet radio service (GPRS) tunneling protocol layer (GTP-U) for the user plane 953, and a user plane PDU layer (UP PDU) 963.

[0184] The transport network layer 954 (also referred to as the "transport layer") can be built on top of the IP transport, and the GTP-U 953 can be used on top of the UDP / IP layer 952 (including the UDP layer and the IP layer) to carry user plane PDUs (UP-PDUs). The IP layer (also referred to as the "Internet layer") can be used to perform packet addressing and routing functions. The IP layer can assign IP addresses to user data packets in any of the formats, such as IPv4, IPv6, or PPP.

[0185] GTP-U 953 can be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the transmitted user data can be packets in any of the IPv4, IPv6, or PPP formats. UDP / IP 952 can provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data flows. The RAN node 511 and the S-GW 622 can exchange user plane data using the S1-U interface via a protocol stack including the L1 layer (e.g., PHY 910), the L2 layer (e.g., MAC 920, RLC 930, PDCP 940, and / or SDAP 947), the UDP / IP layer 952, and the GTP-U 953. The S-GW 622 and the P-GW 623 can exchange user plane data using the S5 / S8a interface via a protocol stack including the L1 layer, the L2 layer, the UDP / IP layer 952, and the GTP-U 953. As previously discussed, the NAS protocol may support mobility of the UE 501 and session management procedures to establish and maintain an IP connection between the UE 501 and the P-GW 623 .

[0186] In addition, despite Figure 9Not shown, but an application layer may exist above the AP 963 and / or transport network layer 954. The application layer may be the layer where a user of the UE 501, RAN node 511, or other network element interacts with, for example, software applications executed by the application circuitry 705. The application layer may also provide one or more interfaces for the software applications to interact with the communication system of the UE 501 or RAN node 511, such as the baseband circuitry 810. In some implementations, the IP layer and / or the application layer may provide functionality that is the same as or similar to layers 5 through 7 of the Open Systems Interconnection (OSI) model, or portions thereof (e.g., OSI layer 7—application layer, OSI layer 6—presentation layer, and OSI layer 5—session layer).

[0187] Figure 10 is a block diagram illustrating components capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some exemplary embodiments. Specifically, Figure 10 A schematic diagram of hardware resources 1000 is shown, including one or more processors (or processor cores) 1010, one or more memory / storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1002 may be executed to provide an execution environment for one or more network slices / subslices to utilize the hardware resources 1000.

[0188] Processor 1010 may include, for example, processor 1012 and processor 1014. Processor 1010 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0189] The memory / storage device 1020 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1020 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, etc.

[0190] The communication resources 1030 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 1004 or one or more databases 1006 via the network 1008. For example, the communication resources 1030 may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components, (or Low power consumption) components, components and other communication components.

[0191] The instructions 1050 may include software, programs, applications, applets, applications, or other executable code for causing at least one of the processors 1010 to perform any one or more of the methodologies discussed herein. The instructions 1050 may reside, in whole or in part, within at least one of the processors 1010 (e.g., within a cache memory of the processor), the memory / storage device 1020, or any suitable combination thereof. Furthermore, any portion of the instructions 1050 may be transferred to the hardware resources 1000 from any combination of the peripheral device 1004 or the database 1006. Thus, the memory of the processor 1010, the memory / storage device 1020, the peripheral device 1004, and the database 1006 are examples of computer-readable media and machine-readable media.

[0192] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods described in the following Examples section. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following Examples. For another example, circuitry associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the Examples section below.

[0193] Example

[0194] Embodiment 1 may include a method comprising: determining connection parameters for a multimedia telephony session between a user equipment (UE) and a remote UE; generating assistance information based on the connection parameters; and sending the assistance information to an access node (AN) serving the UE using a medium access control (MAC) control element.

[0195] Embodiment 2 may include the method of embodiment 1 or some other embodiments herein, wherein the connection parameter is a voice call quality of the multimedia telephony session.

[0196] Embodiment 3 may include a method as in embodiment 1 or some other embodiments herein, wherein the MAC control element is a bit rate recommendation query message.

[0197] Embodiment 4 may include the method of embodiment 1 or some other embodiments herein, wherein sending the assistance information to the AN serving the UE is performed by a cellular protocol stack of the UE.

[0198] Embodiment 5 may include the method according to embodiment 1 or some other embodiments herein, wherein determining the connection parameters and generating the assistance information are performed by a media layer management engine of the UE.

[0199] Embodiment 6 may include a method as in embodiment 1 or some other embodiments herein, wherein determining a connection parameter of the multimedia telephony session comprises measuring an end-to-end delay of the multimedia telephony session.

[0200] Embodiment 7 may include the method of embodiment 1 or some other embodiments herein, wherein the assistance information includes a delay budget indicator indicating a delay budget of a radio local link of the UE.

[0201] Embodiment 8 may include the method of embodiment 7 or some other embodiments herein, wherein the delay budget is for uplink (UL) and downlink (DL) of a radio local link of the UE, respectively.

[0202] Embodiment 9 may include the method of embodiment 7 or some other embodiments herein, wherein the delay budget is provided in milliseconds.

[0203] Embodiment 10 may include a method as described in embodiment 7 or some other embodiments herein, wherein the delay budget is encoded on 7 bits of a MAC control element.

[0204] Embodiment 11 may include a method according to embodiment 1 or some other embodiments herein, wherein generating assistance information based on the connection parameters includes requesting a delay budget for a remote radio link of the remote UE from the remote UE; determining a delay budget for a local radio link of the UE based on at least one of: an end-to-end delay measurement of a multimedia telephony session, or a delay budget for a remote radio link of the multimedia telephony session; and generating a delay budget indicator based on the delay budget of the local radio link, wherein the assistance information includes the delay budget indicator.

[0205] Embodiment 12 may include a method as in embodiment 1 or some other embodiments herein, wherein determining a connection parameter of the multimedia telephony session comprises determining a robustness of a codec used in conjunction with the multimedia telephony session.

[0206] Embodiment 13 may include the method according to embodiment 12 or some other embodiments herein, wherein the method further comprises: adding a flag to recommend to the AN to increase the robustness of the codec.

[0207] Embodiment 14 may include a method according to embodiment 13 or some other embodiments herein, wherein in response to the media layer in the UE detecting that the audio decoder of the UE has reached its limit in maintaining the current packet loss rate, adding the flag to recommend to the AN to increase the robustness of the codec is performed.

[0208] Embodiment 15 may include a method according to embodiment 1 or some other embodiments herein, wherein generating auxiliary information based on the connection parameters includes generating a robustness indicator based on at least one of: feedback from a jitter buffer indicating a packet drop rate or robustness to packet loss of a codec used in conjunction with the multimedia telephony session, wherein the auxiliary information includes the robustness indicator.

[0209] Embodiment 16 may include a method according to embodiment 15 or some other embodiments herein, wherein the robustness indicator comprises a maximum supported packet loss rate on a radio local link of the UE.

[0210] Embodiment 17 may include a method as in embodiment 15 or some other embodiments herein, wherein the codec robustness indicator comprises a target block error rate (BLER).

[0211] Embodiment 18 may include a method according to embodiment 1 or some other embodiments herein, wherein generating the auxiliary information based on the connection parameter includes determining a packet loss rate for a local radio link applicable to the UE based on: (i) robustness to packet loss of a codec used in conjunction with the multimedia telephony session, and (ii) packet loss observed on a remote radio link of the remote UE; generating a robustness indicator based on the packet loss rate, wherein the auxiliary information includes the robustness indicator.

[0212] Embodiment 19 may include the method according to embodiment 1 or some other embodiments herein, the assistance information further comprising a request to the access node to adjust a delay budget of a local radio link of the UE.

[0213] Embodiment 20 may include the method of embodiment 1 or some other embodiments herein, the assistance information further comprising a request to the access node to enable Packet Data Convergence Protocol (PDCP) packet repetition.

[0214] Embodiment 21 may include a method according to embodiment 1 or some other embodiments herein, wherein multiple radio link control (RLC) bearers are connected to a packet data convergence protocol (PDCP) entity of the UE, and wherein the auxiliary information also includes a request to the access node to change a default RLC bearer among the multiple RLC bearers.

[0215] Embodiment 22 may include a method comprising: receiving assistance information from a remote user equipment (UE) conducting a multimedia telephony session with the UE; and modifying at least one of a configuration of a local radio link or a configuration of a layer 2 data plane of the UE based on the assistance information.

[0216] Embodiment 23 may include a method according to embodiment 22 or some other embodiments herein, wherein the auxiliary information includes at least one of: (i) a delay budget indicator indicating a delay budget of a local radio link; or (ii) a robustness indicator indicating the robustness of a codec used in conjunction with the multimedia telephony session.

[0217] Embodiment 24 may include a method according to embodiment 22 or some other embodiments herein, wherein modifying at least one of the configuration of the local radio link or the configuration of the layer 2 data plane of the UE includes: enabling packet data convergence protocol (PDCP) packet repetition; changing a default radio link control (RLC) bearer among multiple radio link control (RLC) bearers connected to the PDCP entity of the UE; or changing a connected mode discontinuous reception (C-DRX) cycle length.

[0218] Embodiment 25 may include a method according to embodiment 24 or some other embodiments herein, wherein PDCP packet repetition is enabled in response to determining that the end-to-end delay of the multimedia telephony session or the robustness of a codec used in conjunction with the multimedia telephony session does not meet a corresponding condition.

[0219] Embodiment 26 may include a method according to embodiment 22 or some other embodiments herein, wherein modifying at least one of the configuration of the UE's local radio link or the configuration of the layer 2 data plane includes using in-band packet data convergence protocol (PDCP) reconfiguration to: change the default radio link control (RLC) bearer of the UE's packet data convergence protocol (PDCP) entity; or enable or disable PDCP data repetition.

[0220] Embodiment 27 may include a method according to embodiment 26 or some other embodiments herein, wherein the in-band PDCP reconfiguration uses New Radio (NR) PDCP control protocol data units (PDUs).

[0221] Embodiment 28 may include a method according to embodiment 27 or some other embodiments herein, wherein the PDU includes (i) a PP bit indicating reconfiguration of the primary RLC path, (ii) a CG ID bit indicating a cell group ID of the primary path, (iii) an LCH ID bit indicating a logical channel ID of the primary path, and (iv) a DD bit indicating whether PDCP data repetition is enabled.

[0222] Embodiment 29 may include a method according to embodiment 27 or some other embodiments herein, wherein the PDU further reconfigures UL-DataSplitThreshold.

[0223] Embodiment 30 may include a method according to embodiment 22 or some other embodiments herein, wherein modifying at least one of the configuration of the local radio link or the configuration of the layer 2 data plane of the UE is further based on radio resource availability, new radio dual connectivity support, radio link quality and fading type, or the number of users to be served.

[0224] Embodiment 31 may include a method according to embodiment 22 or some other embodiments herein, wherein modifying at least one of the configuration of the UE's local radio link or the configuration of the layer 2 data plane includes at least one of: adapting the maximum number of hybrid automatic repeat request (HARQ) retransmissions; enabling or disabling transmission time interval (TTI) bundling; enabling separate bearers with packet data convergence protocol (PDCP) redundancy in case of dual connectivity or carrier aggregation; changing the default radio link in case of new radio dual connectivity support; or changing the connected mode discontinuous reception (C-DRX) cycle length or disabling C-DRX.

[0225] Embodiment 32 may include a method comprising: selecting an action to be performed by an access node (AN) serving a user equipment (UE) based on (i) audio quality in a multimedia telephony session between the UE and a remote UE, or (ii) an end-to-end delay measurement of the multimedia telephony session; and sending an indication to the AN of the action to be performed.

[0226] Embodiment 33 may include a method according to embodiment 32 or some other embodiments herein, wherein sending the indication includes sending the indication in a radio resource control (RRC) signal, a packet data convergence protocol (PDCP) control protocol data unit (PDU), or a medium access control (MAC) control element.

[0227] Embodiment 34 may include a method according to embodiment 32 or some other embodiments herein, wherein the action is at least one of: enabling data repetition; changing the default radio link control (RLC) bearer of the UE's packet data convergence protocol (PDCP) entity; enabling transmission time interval (TTI) bundling or lowering the modulation and coding scheme (MCS).

[0228] Embodiment 35 may include a method according to embodiment 32 or some other embodiments herein, wherein sending an indication of an action to be performed includes sending the indication using a packet data convergence protocol (PDCP) control protocol data unit (PDU).

[0229] Embodiment 36 may include a method according to embodiment 35 or some other embodiments herein, wherein the PDU includes (i) a PP bit indicating whether the UE recommends that the AN change the primary path; and (ii) a DD bit indicating whether the UE recommends enabling PDCP data repetition.

[0230] Embodiment 37 may include an apparatus comprising means for performing one or more elements of a method as described in or related to any of Embodiments 1 to 36, or any other method or process described herein.

[0231] Embodiment 38 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any one of Embodiments 1 to 36 or any other method or process described herein.

[0232] Embodiment 39 may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in accordance with or related to any of Embodiments 1 to 36, or any other method or process described herein.

[0233] Embodiment 40 may include a method, technique, or process as described or related to any one of Embodiments 1 to 36, or a portion or component thereof.

[0234] Embodiment 41 may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or portion thereof, as described or related to any one of Embodiments 1 to 36.

[0235] Embodiment 42 may include a signal as described or associated with any one of embodiments 1 to 36, or a portion or component thereof.

[0236] Embodiment 43 may include a datagram, packet, frame, segment, protocol data unit (PDU) or message as described in or related to any of embodiments 1 to 36 or otherwise described in this disclosure, or a portion or component thereof.

[0237] Embodiment 44 may include a signal encoded with data as described or associated with any one of Embodiments 1 to 36, or a portion or component thereof, or as otherwise described in this disclosure.

[0238] Embodiment 45 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU) or message as described in accordance with or in connection with any of Embodiments 1 to 36 or otherwise described in this disclosure, or a portion or component thereof.

[0239] Embodiment 46 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform the method, technique, or process described in or related to any one of Embodiments 1 to 36, or a portion thereof.

[0240] Embodiment 47 may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process described in or related to any one of Embodiments 1 to 36, or a portion thereof.

[0241] Embodiment 48 may include signals in a wireless network as shown and described herein.

[0242] Embodiment 49 may include a method of communicating in a wireless network as shown and described herein.

[0243] Embodiment 50 may include a system for providing wireless communications as shown and described herein.

[0244] Embodiment 51 may include an apparatus for providing wireless communications as shown and described herein.

[0245] Unless expressly stated otherwise, any of the above examples may be combined with any other example (or combination of examples). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the various embodiments.

[0246] 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 authorized use should be clearly stated to users.

Claims

1. A method for wireless communication, the method comprising: determining connection parameters for a multimedia telephony session between a first user equipment UE and a second UE; generating assistance information based on the determined connection parameters, the assistance information comprising (i) a request for additional delay budget for the multimedia telephony session and (ii) data mapping information for at least one data radio bearer (DRB); selecting a radio bearer based at least on a dual connectivity mode of the first UE; as well as The assistance information is sent to an access node AN serving the first UE via the selected radio bearer.

2. The method of claim 1 , wherein determining the connection parameters of the multimedia telephony session comprises: An end-to-end delay of the multimedia telephony session is measured.

3. The method of claim 1 , wherein generating auxiliary information based on the connection parameters comprises: requesting a delay budget for a long-range radio link of the second UE from the second UE; determining a delay budget for a local radio link of the first UE based on at least one of: an end-to-end delay measurement of the multimedia telephony session, or the delay budget for the remote radio link of the multimedia telephony session; as well as A delay budget indicator is generated based on the delay budget of the local radio link, wherein the assistance information includes the delay budget indicator.

4. The method of claim 1 , wherein determining the connection parameters of the multimedia telephony session comprises: The robustness of a codec used in conjunction with the multimedia telephony session is determined.

5. The method of claim 1 , wherein generating auxiliary information based on the connection parameters comprises: A robustness indicator is generated based on at least one of: feedback from a jitter buffer indicating a packet drop rate or robustness to packet loss of a codec used in conjunction with the multimedia telephony session, wherein the auxiliary information includes the robustness indicator. 6 . The method of claim 5 , wherein the robustness indicator comprises a maximum supported packet loss rate on a radio local link of the first UE. The method of claim 5 , wherein the codec robustness indicator comprises a target block error rate (BLER).

8. The method of claim 1 , wherein generating the auxiliary information based on the connection parameters comprises: determining a packet loss rate for a local radio link applicable to the first UE based on: (i) robustness to packet loss of a codec used in conjunction with the multimedia telephony session; and (ii) packet loss observed on the remote radio link of the second UE; as well as A robustness indicator is generated based on the packet loss rate, wherein the auxiliary information includes the robustness indicator.

9. The method of claim 1, the assistance information further comprising a request to the AN to enable Packet Data Convergence Protocol (PDCP) packet repetition.

10. The method of claim 1, wherein a plurality of Radio Link Control (RLC) bearers are connected to a Packet Data Convergence Protocol (PDCP) entity of the first UE, and wherein the assistance information further comprises a request to the AN to change a default RLC bearer among the plurality of RLC bearers.

11. A method for wireless communication, the method comprising: receiving assistance information from a first user equipment (UE) conducting a multimedia telephony session with a second user equipment (UE) via a radio bearer, the assistance information comprising (i) a request for additional delay budget for the multimedia telephony session and (ii) data mapping information for at least one data radio bearer (DRB), wherein the radio bearer is selected based on at least a dual connectivity mode of the first UE; as well as At least one of a configuration of a local radio link or a configuration of a layer 2 data plane of the first UE is modified based at least on the assistance information.

12. The method of claim 11, wherein the assistance information comprises at least one of: (i) a delay budget indicator indicating a delay budget of the local radio link; or (ii) a robustness indicator indicating the robustness of a codec used in conjunction with the multimedia telephony session.

13. The method of claim 11 , wherein modifying at least one of the configuration of the local radio link or the configuration of the layer 2 data plane of the first UE comprises: Enable Packet Data Convergence Protocol (PDCP) packet repetition; changing a default RLC bearer among a plurality of Radio Link Control (RLC) bearers connected to a PDCP entity of the first UE; or Changing the connected-mode DRX (C-DRX) cycle length.

14. The method of claim 13, wherein the PDCP packet repetition is enabled in response to determining that an end-to-end delay of the multimedia telephony session or a robustness of a codec used in conjunction with the multimedia telephony session does not meet a corresponding condition.

15. The method of claim 11 , wherein modifying at least one of the configuration of the local radio link or the configuration of the layer 2 data plane of the first UE comprises: Use in-band Packet Data Convergence Protocol (PDCP) reconfiguration to: changing a default radio link control (RLC) bearer of a Packet Data Convergence Protocol (PDCP) entity of the first UE; or Enable or disable PDCP data repetition.

16. The method of claim 15, wherein the in-band PDCP reconfiguration uses New Radio (NR) PDCP Control Protocol Data Units (PDUs).

17. A method for wireless communication, the method comprising: Based on (i) audio quality in a multimedia telephony session between the first user equipment UE and the second UE; or (ii) an end-to-end delay measurement of the multimedia telephony session to select an action to be performed by an access node AN serving the first UE, the action comprising allocating an additional delay budget for the multimedia telephony session; selecting a radio bearer based at least on a dual connectivity mode of the first UE; as well as Assistance information is sent to the AN via the selected radio bearer, the assistance information including (i) an indication of the action to be performed and (ii) data mapping information for at least one data radio bearer (DRB).

18. The method of claim 17, wherein sending the indication comprises: The indication is sent in a radio resource control RRC signal, a packet data convergence protocol PDCP control protocol data unit PDU or a medium access control MAC control element.

19. The method of claim 17, wherein the actions further comprise: Enable data duplication; The default radio link control (RLC) bearer of the packet data convergence protocol (PDCP) entity of the first UE is changed; transmission time interval (TTI) bundling is enabled or a modulation and coding scheme (MCS) is reduced.

Images