Apparatus and method for signaling rans assistance in codec adaptation capability in ims multimedia telephony session

By employing SDP and RTP/RTCP methods between user equipment (UE), signaling notification ANBR capabilities, and RAN-assisted codec adaptation, the lack of end-to-end coordination in existing technologies is addressed, thereby improving the quality of IMS multimedia telephony sessions and network resource utilization efficiency.

CN116566958BActive Publication Date: 2026-04-28APPLE INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
APPLE INC
Filing Date
2019-09-09
Publication Date
2026-04-28

AI Technical Summary

Technical Problem

The lack of an effective end-to-end coordination mechanism in the existing technology to support radio access network (RAN)-assisted codec adaptation leads to frequent Session Description Protocol (SDP) renegotiation, increasing network burden and wasting resources.

Method used

By implementing SDP and Real-time Transport Protocol (RTP)/Real-time Transport Control Protocol (RTCP)-based methods between User Equipment (UEs), signaling ANBR capabilities and RAN-assisted codec adaptation capabilities are provided, including encoding and decoding SDP response messages to transmit ANBR information, supporting adaptive adjustment of the codec.

Benefits of technology

It improves the end-to-end quality of IMS multimedia telephony sessions, reduces the frequency of SDP renegotiation, optimizes network resource utilization, and enhances the efficiency and flexibility of codec adaptation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116566958B_ABST
    Figure CN116566958B_ABST
Patent Text Reader

Abstract

Apparatuses and methods for signaling RAN assistance codec adaptation capabilities via IMS are provided herein. An apparatus for a UE is disclosed that includes an RF interface to receive an SDP offer message from the remote UE, the SDP offer message including a first dedicated SDP attribute parameter to indicate support for ANBR capabilities of the remote UE; and a processor circuit. The processor circuit is to decode the SDP offer message to determine support for ANBR capabilities of the remote UE; encode an SDP answer message in response to the SDP offer message, the SDP answer message including a second dedicated SDP attribute parameter to indicate support for ANBR capabilities of the UE; and cause transmission of the SDP answer message to the remote UE. Other implementations are also disclosed and claimed.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of the invention patent application filed on September 9, 2019, which entered the Chinese national phase on March 5, 2021, with Chinese national application number 201980058426.3, entitled "Apparatus and method for signaling notification of RAN-assisted codec adaptive capability in an IMS multimedia telephone session". Technical Field

[0002] The embodiments of this disclosure relate generally to wireless communication, and more specifically, to apparatus and methods for signaling RAN-assisted codec adaptive capabilities in an IMS multimedia telephony session. Background Technology

[0003] In Internet Protocol (IP) Multimedia Subsystem (IMS) multimedia telephony sessions, such as Voice Long Term Evolution (VoLTE) calls, Radio Access Network (RAN)-assisted codec adaptation can be enabled to improve end-to-end quality. Codec adaptation can be triggered by Access Network Bit Rate Recommendation (ANBR) information received from the RAN. This disclosure provides radio capabilities for supporting ANBR signaling, solutions for signaling RAN-assisted codec adaptation capabilities in IMS multimedia telephony sessions, and other related solutions. Summary of the Invention

[0004] One aspect of this disclosure provides an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the apparatus comprising: a radio frequency (RF) interface for receiving a Session Description Protocol (SDP) provision message from the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating support for Access Network Bit Rate Recommendation (ANBR) capability of the remote UE, and wherein the ANBR capability of the remote UE corresponds to the ability to receive ANBR information from a Remote Radio Access Network (RAN) to which the remote UE is connected or the ability of the remote RAN to transmit ANBR information; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: decode the SDP provision message received from the RF interface to obtain the first dedicated SDP attribute parameter, thereby determining support for the ANBR capability of the remote UE; encode an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating support for the ANBR capability of the UE, and wherein the ANBR capability of the UE corresponds to the ability to receive ANBR information from a RAN to which the UE is connected or the ability of the RAN to transmit the ANBR information; and cause the SDP response message to be transmitted to the remote UE.

[0005] One aspect of this disclosure provides one or more computer-readable media having instructions stored thereon, which, when executed by processor circuitry of a UE, cause the processor circuitry to: decode an SDP provision message received from a remote UE, the UE being operable to stream a multimedia telephony session with the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating support for ANBR capability of the remote UE and support for RAN-assisted codec adaptation of the remote UE; encode an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating support for ANBR capability of the UE and support for RAN-assisted codec adaptation of the UE; and cause the SDP response message to be transmitted to the remote UE, wherein the ANBR capability of the remote UE corresponds to the ability to receive ANBR information from a remote RAN to which the remote UE is connected or the ability of the remote RAN to transmit ANBR information, and the ANBR capability of the UE corresponds to the ability to receive ANBR information from a RAN to which the UE is connected or the ability of the RAN to transmit ANBR information.

[0006] One aspect of this disclosure provides an apparatus for a UE operable to stream a multimedia telephony session with a remote UE, the apparatus comprising: an RF interface for receiving an SDP provision message from the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating adaptive support for RAN-assisted codecs of the remote UE; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: decode the SDP provision message received from the RF interface; encode an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for RAN-assisted codecs of the UE; and cause the SDP response message to be transmitted to the remote UE. Attached Figure Description

[0007] The embodiments disclosed herein will be illustrated by way of example rather than limitation in the accompanying drawings, in which similar reference numerals refer to similar elements.

[0008] Figure 1 An exemplary architecture of a system according to some embodiments of this disclosure is shown.

[0009] Figure 2 A schematic diagram illustrating an example of an SDP provide-response with SDP attribute parameters according to some embodiments of this disclosure is shown.

[0010] Figure 3A flowchart is shown of a method for supporting ANBR capabilities based on SDP instructions, according to some embodiments of this disclosure.

[0011] Figure 4 A flowchart is shown of an adaptive method for ANBR triggered by a transmitting UE, according to some other embodiments of this disclosure.

[0012] Figure 5 A flowchart is shown of an adaptive method for ANBR triggered by a receiving UE, according to some other embodiments of this disclosure.

[0013] Figure 6 A flowchart is shown of a method for supporting ANBR capabilities based on RTP / RTCP indications according to some embodiments of this disclosure.

[0014] Figure 7 A schematic diagram illustrating an example of an RTP header extension message format according to some embodiments of this disclosure is shown.

[0015] Figure 8 Exemplary components of a device according to some embodiments of this disclosure are shown.

[0016] Figure 9 An exemplary interface of a baseband circuit according to some implementation schemes is shown.

[0017] Figure 10 This is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium and executing any or more of the methods discussed herein, according to some example embodiments. Detailed Implementation

[0018] The exemplary embodiments will be described using terminology commonly used by those skilled in the art to convey the essence of this disclosure to others skilled in the art. However, it will be apparent to those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. For purposes of explanation, many specific quantities, materials, and configurations are set forth to provide a thorough understanding of the exemplary embodiments. However, it will be apparent to those skilled in the art that alternative embodiments can be implemented without these specific details. In other instances, well-known features may have been omitted or simplified to avoid obscuring the exemplary embodiments.

[0019] Furthermore, the various operations will be described sequentially as multiple discrete operations in a manner most conducive to understanding the illustrative implementation; however, the order of description should not be interpreted as implying that these operations necessarily depend on the order. Specifically, these operations do not necessarily need to be performed in the order they are presented.

[0020] The phrases “in an implementation,” “in one implementation,” and “in some implementations” are used repeatedly in this document. The phrases generally do not refer to the same implementation; however, they may refer to the same implementation. Unless the context otherwise requires, the terms “comprising,” “having,” and “including” are synonymous. The phrases “A or B” and “A / B” mean “(A), (B), or (A and B).”

[0021] Signaling related to Radio Access Network (RAN)-assisted codec adaptation and Access Network Bit Rate Recommendation (ANBR) information from the RAN to the User Equipment (UE) has been defined for Long Term Evolution (LTE) and New Radio (NR) access in 3GPP Technical Specifications (TS) 36.321V15.2.0 (2018-07) and 3GPP TS 38.321V15.2.0 (2018-06). RAN-assisted codec adaptation (also known as RAN support for ANBR) has been specified as an optional feature for both LTE and NR access.

[0022] Furthermore, from a media processing perspective, support for ANBR as adaptive triggering has always been optional for voice and is recommended for video in 3GPP TS 26.114 V15.3.0 (2018-06) (particularly in Clause 10.7). Meanwhile, ANBR-triggered adaptation requires end-to-end use, as described in the workflow of Clause 10.7.3 of 3GPP TS 26.114 V15.3.0. However, there is currently no signaling to provide end-to-end coordination between UEs regarding ANBR capability or ANBR-triggered adaptive capability.

[0023] Regarding radio capabilities supporting ANBR signaling, Clause 5.5.5 of 3GPP Technical Report (TR) 26.919 V2.0.0 (2018-08) describes an SDP-based capability indication method that allows indication of ANBR signaling support through a given access network (i.e., LTE or NR access). For example, in the case of LTE access, a UE supporting ANBR reception via the LTE air interface confirms with its evolved NodeB (eNB) whether it also supports ANBR signaling, and if so, the UE includes the Session Description Protocol (SDP) attribute `anbr_e2e` in its SDP offering or response, as described in 3GPP TR 26.919 V2.0.0. However, whenever a UE changes its access (e.g., switching from NR to LTE), this access-specific nature of the SDP-based capability indication requires SDP renegotiation. This frequent SDP renegotiation is costly and undesirable from the core network's perspective.

[0024] This disclosure enables a method based on SDP and Real-time Transport Protocol (RTP) / Real-time Transport Control Protocol (RTCP) to signal ANBR capability information and specific RAN-assisted codec adaptation capabilities to improve end-to-end quality of VoLTE calls. The RAN-assisted codec adaptation capabilities of the signaled transmission may include various client rate adaptation behaviors triggered by ANBR information received from the access network, including changing the transmitted bit rate and transmitting Codec Mode Request (CMR) / RTCP-Application (RTCP-APP) messages for voice rate adaptation and Temporary Maximum Media Stream Bit Rate Request (TMMBR) / Temporary Maximum Media Stream Bit Rate Notification (TMMBN) messages for video rate adaptation. Furthermore, the RAN-assisted codec adaptation capabilities of the signaled transmission may also include support for radio capabilities of ANBR signaling over a given access network.

[0025] Figure 1 An exemplary architecture of system 100 according to some embodiments of this disclosure is shown. The following description is provided for an exemplary system 100 operating in combination with the Long Term Evolution (LTE) system standard provided by the 3GPP Technical Specification (TS) and the 5G or New Radio (NR) system standard. However, the exemplary embodiments are not limited in this respect, and the embodiments can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., Wireless Metropolitan Area Network (MAN), Global Microwave Access Interoperability (WiMAX), etc.).

[0026] like Figure 1As shown, system 100 may include UE 101a and UE 101 (collectively referred to as "UE 101"). As used herein, the term "user equipment" or "UE" may refer to a device of a remote user having radio communication capabilities and capable of describing network resources in a communication network. Furthermore, the terms "user equipment" or "UE" may be considered synonymous and may refer to a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device including a wireless communication interface. In this example, UE 101 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 consumer electronics devices, cellular phones, smartphones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptops, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument cluster (IC), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminal (MDT), electronic engine management system (EEMS), electronic / engine electronic control unit (ECU), electronic / engine electronic control module (ECM), embedded systems, microcontrollers, control modules, engine management system (EMS), connected or “smart” appliances, machine-type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, etc.

[0027] In some implementations, any of UEs 101 may include an IoT UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived 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, Proximity Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or an IoT network. M2M or MTC data exchange may be machine-initiated. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0028] UE 101 can be configured to be communicatively coupled to, for example, an access network (AN) or a radio access network (RAN) 110. In implementations, RAN 110 can be a next-generation (NG) RAN or a 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), or a traditional RAN such as UTRAN (UMTS terrestrial radio access network) or GERAN (GSM (Global System for Mobile Communications or Group Special Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN," etc., can refer to RAN 110 operating in an NR or 5G system 100, while the term "E-UTRAN," etc., can refer to RAN 110 operating in an LTE or 4G system 100. UE 101 utilizes connections (or channels) 103 and 104, respectively, each connection including a physical communication interface or layer. As used herein, the term "channel" can refer to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous and / or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and / or any other similar term that indicates a path or medium through which data is transmitted. Additionally, the term "link" may refer to a connection between two devices for transmitting and receiving information via radio access technology (RAT).

[0029] In this example, connections 103 and 104 are shown as air interfaces for communication coupling and can be consistent with cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Cellular PTT (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, New Radio (NR) protocol, and / or any other communication protocols described herein. In an implementation, UE 101 can directly exchange communication data via ProSe interface 105. ProSe interface 105 may alternatively be referred to as sidelink (SL) interface 105 and may include one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0030] UE 101b is shown configured to access access point (AP) 106 (also referred to as "WLAN node 106", "WLAN 106", "WLAN terminal 106", or "WT 106", etc.) via connection 107. Connection 107 may include local wireless connectivity, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 will include Wireless Fibre. Router. In this example, AP 106 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below). In various implementations, UE 101b, RAN 110, and AP 106 can be configured to utilize LTE-WLAN aggregation (LWA) operation and / or WLAN LTE / WLAN Radio Level (LWIP) operation integrated with an IPsec tunnel. LWA operation may involve UE 101b, located in RRCCONNECTED, being configured by RAN node 111 to utilize the radio resources of LTE and WLAN. LWIP operation may involve UE 101b using WLAN radio resources (e.g., connection 107) via an Internet Protocol Security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) transmitted through connection 107. The IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

[0031] RAN 110 includes one or more AN nodes or RAN nodes 111a and 111b (collectively referred to as "RAN node 111") that enable connections between 103 and 104. As used herein, the terms "AN node," "RAN node," "access node," "access point," etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between the network and one or more users. These access nodes can be referred to as base stations (BS), next-generation NodeBs (gNBs), RAN nodes, evolved NodeBs (eNBs), NodeBs, road-side units (RSUs), transmit-receive points (TRxPs or TRPs), etc., and can 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," etc., can refer to an RNA node 111 (e.g., a gNB) operating in an NR or 5G system 100, while the terms "E-UT RAN node," etc., can refer to a RAN node 111 (e.g., an eNB) operating in an LTE or 4G system 100. According to various implementation schemes, RAN node 111 may be implemented as one or more of dedicated physical devices such as macro cell base stations and / or low-power (LP) base stations for providing smaller coverage areas, smaller user capacity or higher bandwidth compared to macro cells.

[0032] Although RAN nodes 111a and 111b are in Figure 1 The nodes are shown in the same RAN 110, but in some embodiments they may be in different RANs. Furthermore, RAN nodes 111a and 111b may be nodes of different types. For example, RAN node 111a may be an eNB, and RAN node 111b may be a gNB. This disclosure is not limited in this respect.

[0033] In some implementations, all or part of RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and / or a Virtual Baseband Unit Pool (vBBUP). In these implementations, CRAN or vBBUP may implement RAN function partitioning, such as PDCP partitioning, where the RRC and PDCP layers are operated by CRAN / vBBUP and other Layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP and the PHY layer is operated by individual RAN nodes 111; or “lower PHY” partitioning, where the upper portions of the RRC, PDCP, RLC, MAC, and PHY layers are operated by CRAN / vBBUP and the lower portions of the PHY layer are operated by individual RAN nodes 111. This virtualization framework allows the idle processor cores of multiple RAN nodes 111 to execute other virtualized applications. In some specific implementations, a single RAN node 111 may represent a virtualized application running via a respective F1 interface (…). Figure 1 (Not shown) Individual gNB-DUs connected to the gNB-CU. In these specific implementations, the gNB-DU may include one or more remote radio headers or radio front-end modules (RFEMs) (not shown), and the gNB-CU may be operated by a server (not shown) located in RAN 110 or by a server pool in a manner similar to CRAN / vBBUP. Alternatively or in addition, one or more nodes in RAN 111 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminals to UE 101 and are connected to 5GC via the NG interface (discussed below).

[0034] In a V2X scenario, one or more nodes in RAN Node 111 can be an RSU or act as an RSU. The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU", an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU", and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside that provides connectivity support to passing vehicle UE 101 (vUE 101). An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Near Range Communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance and traffic warnings. Alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low-latency communication as well as other cellular communication services. Alternatively, the RSU may operate as a WiFi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. Some or all of the computing device and the RSU's radio frequency circuitry may be encapsulated in a weather-resistant housing suitable for outdoor installation and may include a network interface controller to provide wired (e.g., Ethernet) connectivity to traffic signal controllers and / or backhaul networks.

[0035] Any node in RAN 111 can serve as the endpoint of the air interface protocol and can be the first point of contact for UE 101. In some implementations, any node in RAN 111 can perform various logical functions of RAN 110, including but not limited to the functions of the Radio Network Controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0036] In the implementation, UE 101 may be configured to communicate with each other or with any of the RAN nodes 111 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals, based on various communication technologies, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0037] In some implementations, the downlink resource grid can be used for downlink transmissions from any node in RAN 111 to UE 101, 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 within each time slot. This time-frequency plane representation is common practice 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 comprises multiple resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements. In the frequency domain, this can represent the minimum amount of resources currently available for allocation. Such resource blocks are used to transmit several different physical downlink channels.

[0038] According to various implementations, UE 101 and RAN nodes 111, 112 transmit (e.g., send and receive data) data through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 5 GHz band.

[0039] To operate in unlicensed spectrum, UE 101 and RAN nodes 111 and 112 may use Licensed Assisted Access (LAA), Enhanced LAA (eLAA), and / or additional eLAA (feLAA) mechanisms. In these specific implementations, UE 101 and RAN nodes 111 and 112 may perform one or more known media sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmission in the unlicensed spectrum. Media / carrier sensing operations may be performed according to the Listen Before Talk (LBT) protocol.

[0040] LBT is a mechanism by which equipment (e.g., UE 101, RAN nodes 111, 112, etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when that medium is sensed to be idle (or when a specific channel in that medium is sensed to be unoccupied). Medium sensing operations may include Clear Channel Assessment (CCA), which utilizes at least Energy Detection (ED) to determine the presence of other signals on the channel in order to determine whether the channel is occupied or cleared. This LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing radio frequency (RF) energy over a period of time through a desired transmission band and comparing the sensed RF energy to predefined or configured thresholds.

[0041] Typically, existing systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). Here, when a WLAN node (e.g., a mobile station (MS) such as UE 101, AP 106, etc.) intends to transmit, the WLAN node can first perform CCA before transmission. Additionally, in cases where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. This backoff mechanism can be a counter randomly drawn within the contention window size (CWS), which increases exponentially upon collision and resets to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some specific implementations, the LBT process for DL ​​or UL transmission bursts (including PDSCH or PUSCH transmissions) can have a variable-length LAA contention window between CCA (ECCA) slots extended in X and Y, where X and Y are the minimum and maximum values ​​of the LAA's CWS. In one example, the minimum CWS for LAA transmission can be 9 microseconds (μs); however, the size of the CWS and the maximum channel occupancy time (MCOT) (e.g., transmission burst) can be based on government regulatory requirements.

[0042] The LAA mechanism is built upon carrier aggregation (CA) technology in LTE-Advanced systems. In CA, each aggregated carrier is called a component carrier (CC). A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and a maximum of five CCs can be aggregated, resulting in a maximum aggregated bandwidth of 100 MHz. In Frequency Division Duplex (FDD) systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have different bandwidths than the other CCs. In Time Division Duplex (TDD) systems, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0043] The CA also includes individual serving cells to provide individual CCs. The coverage of serving cells can differ, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell, or primary cell (PCell), provides the primary CC (PCC) for both UL and DL and handles Radio Resource Control (RRC) and Non-Access Layer (NAS) related activities. Other serving cells are called secondary cells (SCells), and each SCell provides a single secondary CC (SCC) for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells can operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured to have more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, indicating the start positions of different Physical Uplink Shared Channels (PUSCHs) within the same subframe.

[0044] The Physical Downlink Shared Channel (PDSCH) carries user data and higher-layer signaling to UE 101. The Physical Downlink Control Channel (PDCCH) carries information such as transmission format and resource allocation related to the PDSCH channel. It also notifies UE 101 of transmission format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UE 101b within the cell) can be performed at any of the RAN nodes 111 based on channel quality information fed back from any of UE 101. Downlink resource allocation information can be transmitted on the PDCCH used for (e.g., allocated to) each UE in UE 101.

[0045] PDCCH can use Control Channel Elements (CCEs) to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH are first organized into quadruplets, which are then 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 a set of four physical resource elements (REGs) of nine. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the size of the Downlink Control Information (DCI) and channel conditions, one or more CCEs can be used to transmit the PDCCH. Four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L = 1, 2, 4, or 8) can exist.

[0046] Some implementations can use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations can utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. EPDCCH can be transmitted using one or more enhanced control channel elements (ECCEs). Similarly, each ECCE can correspond to a set of nine physical resource elements, called an enhanced resource element group (EREG). In some cases, an ECCE can have a different number of EREGs.

[0047] RAN nodes 111 can be configured to communicate with each other via interface 112. In an implementation where system 100 is an LTE system, interface 112 can be an X2 interface 112. The X2 interface can be defined between two or more RAN nodes 111 connected to EPC 120 (e.g., two or more eNBs, etc.), and / or between two eNBs connected to EPC 120. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U can provide flow control mechanisms for user packets transmitted via the X2 interface and can be used to transmit information about the delivery of user data between eNBs. For example, X2-U can provide specific sequence number information about user data transmitted from the primary eNB (MeNB) to the secondary eNB (SeNB); information about the successful in-order delivery of PDCP PDUs from the SeNB to UE 101 for user data; information about PDCP PDUs not delivered to UE 101; information about the current minimum expected buffer size at the SeNB for transmitting data to the UE; and so on. X2-C provides intra-TE access mobility functions, including context transmission from the source eNB to the destination eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0048] In implementations where system 100 is a 5G or NR system, interface 112 may be an Xn interface 112. The Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gNBs, etc.) connected to 5GC 120, between a RAN node 111 (e.g., a gNB) connected to 5GC 120 and an eNB, and / or between two eNBs connected to 5GC 120. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 101 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more RAN nodes 111. This mobility support may include context transfer from the old (source) serving RAN node 111 to the new (destination) serving RAN node 111; and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (destination) serving RAN node 111. The Xn-U protocol stack may include a transport network layer built on top of the Internet Protocol (IP) transport layer, and a GTP-U layer 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 top of SCTP. SCTP may be on top of the IP layer and provides guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other specific 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.

[0049] RAN 110 is shown communicatively coupled to the core network—in this embodiment, communicatively coupled to the core network (CN) 120. CN 120 may include multiple network elements 122 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of multiple UEs 101) connected to CN 120 via RAN 110. The term "network element" can describe physical or virtualized equipment used to provide wired or wireless communication network services. The term "network element" can be considered and / or referred to as a networked computer, networking hardware, network equipment, router, switch, hub, bridge, wireless network controller, wireless access network equipment, gateway, server, virtualized network function (VNF), network function virtualization infrastructure (NFVI), etc. Components of CN 120 may be implemented in a 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 implementations, Network Functions Virtualization (NFV) can be used to virtualize any or all of the aforementioned network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. A logical instance of CN 120 may be referred to as a network slice, and a logical instance of a portion of CN 120 may be referred to as a network subslice. NFV architectures and infrastructures can be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (optionally performed by proprietary hardware). In other words, an NFV system can be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0050] Generally, application server 130 may be an element that provides IP bearer resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). Application server 130 may also be configured to support one or more communication services for UE 101 via EPC 120 (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.).

[0051] In the implementation, CN 120 may be a 5GC (referred to as "5GC 120", etc.), and RAN 110 may be connected to CN 120 via NG interface 113. In the implementation, NG interface 113 may be divided into two parts: NG User Plane (NG-U) interface 114, which carries traffic data between RAN node 111 and User Plane Function (UPF); and S1 Control Plane (NG-C) interface 115, which is the signaling interface between RAN node 111 and AMF.

[0052] In one implementation, CN 120 may be a 5G CN (referred to as "5GC 120", etc.), while in other implementations, CN 120 may be an evolved packet core (EPC). When CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may connect to CN 120 via S1 interface 113. In another implementation, S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries traffic data between RAN node 111 and the Serving Gateway (S-GW); and an S1 Mobility Management Entity (MME) interface 115, which is the signaling interface between RAN node 111 and the MME.

[0053] Figure 2 A schematic diagram illustrating an example of an SDP provide-response 200 having SDP attribute parameters is shown according to some embodiments of this disclosure.

[0054] like Figure 2 As shown, two UEs (UE-1 and UE-2) are connected to two eNBs (eNB-1 and eNB-2), respectively. The two eNBs are connected to the EPC. The UEs can communicate with each other via the EPC through IMS in IMS multimedia telephony sessions.

[0055] exist Figure 2 In some implementations, an eNB with LTE access may be used, for example. However, other RAN nodes, such as a gNB with NR access, may also be used, which is not limited in this disclosure.

[0056] exist Figure 2 In one example, UE-2 may transmit an SDP provisioning message including dedicated SDP attribute parameters to UE-1, and in response, UE-1 may transmit an SDP reply message including dedicated SDP attribute parameters to UE-2. In other examples, UE-1 may transmit an SDP provisioning message to UE-2, and in response, UE-2 may transmit an SDP reply message to UE-1. This disclosure is not limited in this respect.

[0057] Figure 3 A flowchart is shown of a method 300 for supporting ANBR capabilities based on SDP instructions, according to some embodiments of this disclosure.

[0058] At 310, UE (e.g., Figure 1 UE 101 or Figure 2 UE-1 can be accessed from a remote UE (e.g., Figure 1 UE 101 or Figure 2 UE-2) receives the SDP provision message. For example, in this implementation, Figure 2 UE-1 is described as a local UE, and Figure 2 UE-2 is described as a remote UE relative to UE-1.

[0059] The SDP provision message may include dedicated SDP attribute parameters indicating support for the ANBR capability of the remote UE-2. The ANBR capability of the remote UE-2 may correspond to support from its RAN (e.g., Figure 2 The ability of the eNB-2 to receive / or query ANBR information and / or the ability of the eNB-2 to transmit ANBR information.

[0060] At 320, UE-1 can decode SDP provisioning messages received from remote UE-2 to obtain support for the ANBR capability of remote UE-2.

[0061] At 330, UE-1 may encode an SDP response message in response to an SDP provision message, including dedicated SDP attribute parameters indicating support for UE-1's ANBR capability. UE-1's ANBR capability may correspond to that from its RAN (e.g., Figure 2 The ability of the eNB-1 to receive / query ANBR information and / or the ability of the eNB-1 to transmit ANBR information.

[0062] At 340, UE-1 can transmit an SDP response message to remote UE-2, and then remote UE-2 can know that it supports UE-1's ANBR capability.

[0063] In the implementation scheme, the dedicated SDP attribute parameter can be a media-level SDP attribute parameter and can be identified as "ANBR adaptive". In the example, "a = ANBR adaptive" can be used to indicate that the associated UE supports ANBR capability. Figure 2 As shown, SDP provide messages with a=ANBR adaptive and SDP response messages with a=ANBR adaptive can be used to indicate support for the UE's ANBR capability. However, other SDP parameters can be used to indicate support for ANBR capability, and this disclosure is not limited in this respect.

[0064] In the implementation scheme, alternatively or otherwise, dedicated SDP attribute parameters of UE-1 may indicate support for RAN-assisted codec adaptation of UE-1, and dedicated SDP attribute parameters of UE-2 may indicate support for RAN-assisted codec adaptation of UE-2. For example, RAN-assisted codec adaptation of UE-1 is performed by UE-1 based on ANBR information received from eNB-1, and RAN-assisted codec adaptation of UE-2 is performed by UE-2 based on ANBR information received from eNB-2.

[0065] Signaling via dedicated SDP attribute parameters (e.g., "a=ANBR_adapt") in the SDP message enables multimedia telephony services for the UE's IMS (MTSI) client (application or media rate adaptation engine) to recognize that the ANBR capability and / or RAN-assisted codec adaptation are supported, and that ANBR signaling from its RAN will not be ignored, thus enabling end-to-end coordination of the ANBR capability across the UE or access network.

[0066] Below, we will combine Figure 4 , Figure 5 and Figure 2 Detailed explanation of RAN-assisted codec adaptation based on ANBR information.

[0067] Figure 4 A flowchart of an adaptive method 400 for ANBR triggered by a transmitting UE, according to some other embodiments of this disclosure, is shown. Figure 5 A flowchart of an adaptive method 500 for ANBR triggered by a receiving UE, according to some other embodiments of this disclosure, is shown. For example, in this embodiment, Figure 2 UE-1 is described as a local UE, and Figure 2 UE-2 is described as a remote UE relative to UE-1.

[0068] Figure 4 An adaptive method for ANBR triggering based on the transmit bit rate of the transmitting UE is shown.

[0069] At 410, UE-1 can receive an SDP provisioning message from remote UE-2. The SDP provisioning message may include dedicated SDP attribute parameters indicating support for RAN-assisted codec adaptation for remote UE-2. Support for RAN-assisted codec adaptation for remote UE-2 enables remote UE-2 to perform codec adaptation based on its RAN (e.g., Figure 2 The eNB-2 receives ANBR information to adjust its codec rate. In this document, the codec rate may include the uplink transmission rate and the downlink reception rate. Therefore, the ANBR information may include uplink ANBR information and downlink ANBR information.

[0070] At 420, UE-1 can decode SDP provisioning messages received from remote UE-2 to obtain RAN-assisted codec adaptation support for remote UE-2.

[0071] At 430, UE-1 may encode an SDP response message in response to an SDP provision message, including dedicated SDP attribute parameters indicating support for RAN-assisted codec adaptation for UE-1. Support for RAN-assisted codec adaptation for UE-1 enables UE-1 to adapt to its RAN (e.g., RAN-assisted codec adaptation) based on data from its RAN. Figure 2 The eNB-1 receives ANBR information to adjust its codec rate.

[0072] At 440, UE-1 can transmit an SDP response message to remote UE-2, and then remote UE-2 can know about the RAN-assisted codec adaptation support for UE-1.

[0073] Accordingly, Figure 5 An adaptive method for ANBR triggering based on the received bit rate of the receiving UE is illustrated. For example, in this embodiment, Figure 2 UE-2 is described as a local UE, and Figure 2 UE-1 is described as a remote UE relative to UE-2.

[0074] At 510, UE-2 may encode an SDP provision message including dedicated SDP attribute parameters indicating support for adaptive RAN-assisted codecs for UE-2. At 520, UE-2 may transmit the SDP provision message to a remote UE-1. At 530, UE-2 may decode an SDP response message transmitted from the remote UE-1 in response to the SDP provision message. The SDP response message may include dedicated SDP attribute parameters indicating support for adaptive RAN-assisted codecs for the remote UE-1.

[0075] Implementation schemes related to RAN-assisted codec adaptation behavior will be described in detail. In these schemes, UE-1 and UE-2 can transmit media via a multimedia telephony session. For example, UE-1 can operate as a transmitting UE (e.g., an MTSI transmitter), and UE-2 can operate as a receiving UE (e.g., an MTSI receiver). It should be noted that in other schemes, UE-1 can operate as a receiving UE, and UE-2 can operate as a transmitting UE; this is not a limitation in this respect. Furthermore, SDP provide messages can be transmitted not only to the receiving UE but also to the transmitting UE, and similarly, SDP reply messages can be transmitted not only to the transmitting UE but also to the receiving UE; this is not a limitation in this respect.

[0076] In one implementation, as a transmitting UE, UE-1 may perform RAN-assisted codec adaptation based on uplink ANBR information received from eNB-1. Specifically, UE-1 may be configured to adjust the transmission bit rate of the media used for transmitting multimedia telephony sessions based on the uplink ANBR information received from eNB-1.

[0077] In the implementation scheme, when the bit rate value is less than the transmit bit rate, UE-1 can reduce the transmit bit rate to the bit rate value indicated by the uplink ANBR information.

[0078] In another implementation, when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, UE-1 may increase the transmit bit rate to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of UE-1's other bit rate adaptive triggers. Other bit rate adaptive triggers may include, but are not limited to, rate adaptation triggered by explicit congestion notification (ECN) for audio and video, rate adaptation triggered by CMR for audio, rate adaptation triggered by RTCP-APP for audio, and rate adaptation triggered by TMMBR and TMMBN for video. In other words, in the implementation where the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, UE-1's transmit bit rate may be determined based on the smallest of all bit rate adaptive triggers of UE-1 (including those indicated in the uplink ANBR information).

[0079] In an implementation where the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, UE-1 may alternatively or additionally adjust the transmit bit rate based at least on the downlink ANBR information of the remote UE-2. In other words, before increasing the transmit bit rate, UE-1 may send an RTCP-TMMBN message to the receiving UE (i.e., UE-2) based on the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate values ​​limited by each of UE-1's other bit rate adaptive triggers. UE-2 may then send an ANBR query to eNB-2 to obtain UE-2's latest ANBR information to check whether the bit rate value indicated in the TMMBN message is supported. If UE-2 receives a lower ANBR value from eNB-2, UE-2 will send a TMMBR message with the lower ANBR value indicated by eNB-2 to UE-1. In response, UE-1 may adjust its transmit bit rate based on a lower ANBR value. For example, UE-1 may adjust its transmit bit rate to a lower ANBR value indicated by eNB-2.

[0080] The above implementation scheme can be applied to various media types, including but not limited to audio and video.

[0081] In the implementation scheme for receiving UE-2, voice and video will be described separately when different messages are involved.

[0082] In an implementation scheme for transmitting voice between UE-1 and UE-2, UE-2, as the receiving UE, may encode a CMR / RTCP-APP message based on downlink ANBR information received from eNB-2 for transmission to UE-1. The CMR / RTCP-APP message is used to indicate the desired receive bit rate of UE-2 for receiving voice.

[0083] In the implementation scheme, when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate used to receive voice, the desired receive bit rate can be determined as the bit rate value indicated by the downlink ANBR information.

[0084] In another implementation, when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate used for receiving voice, the desired receive bit rate can be determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of UE-2. In other words, in the implementation where the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate, the receive bit rate of UE-2 can be determined based on the smallest of all bit rate adaptive triggers of UE-2 (including those indicated in the downlink ANBR information).

[0085] In an implementation scheme for transmitting video between UE-1 and UE-2, UE-2, as the receiving UE, may encode an RTCP TMMBR message based on downlink ANBR information received from eNB-2 for transmission to UE-1. The RTCP TMMBR message is used to indicate the expected receive bit rate of the received video.

[0086] Similarly, in the implementation, when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate used to receive video, the desired receive bit rate can be determined as the bit rate value indicated by the downlink ANBR information.

[0087] In another implementation, when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate used to receive voice, the desired receive bit rate can be determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of UE-2.

[0088] The additional codec adaptive behavior described in Clause 10.7.3 of 3GPP TS 26.114V15.3.0 can also be included in this document based on the newly defined dedicated SDP attribute parameters mentioned above.

[0089] The preceding text described some implementations related to indications for ANBR capability support and indications for RAN-assisted codec adaptation. These implementations relate to SDP-based indications. The following describes some other implementations to discuss indications for RTP / RTCP-based ANBR capability support.

[0090] Figure 6 A flowchart is shown of a method 600 for supporting ANBR capabilities based on RTP / RTCP indications according to some embodiments of the present disclosure.

[0091] At 610, the UE can encode a message that includes the UE's radio capability information. At 620, the UE can transmit the message to a remote UE.

[0092] As mentioned above, this message may include an SDP message during capability negotiation based on IMS / Session Initiation Protocol (SIP), which is omitted here for brevity.

[0093] In the implementation scheme, the UE may include the aforementioned SDP attribute parameters in the SDP provisioning / response only if it supports the corresponding radio capability through a given access network, such as in the case of ANBR, and only if the UE supports receiving ANBR information from its access network. Then, once the session, associated bearer, and logical channel are established, the UE will also determine whether its access network (e.g., the eNB in ​​the case of LTE access and the gNB in ​​the case of NR access) is capable of sending ANBR information to the UE. Based on this understanding, the UE can use the aforementioned SDP signaling methods to notify the remote UE of radio capability information (e.g., support for ANBR capabilities). Alternatively, the UE can use the following RTP / RTCP signaling messages to notify the remote UE of radio capability information.

[0094] In the implementation scheme, messages carrying radio capability information may include application layer messages. These application layer messages may include RTCP Feedback (RTCP-FB) messages or RTP header extension messages as specified in Internet Engineering Task Force (IETF) Request for Comment (RFC) 4585 (2006.7). Both RTCP-FB messages and RTP header extension messages are configured to carry radio capability information of the current access network to which the UE is connected during RTP streaming media. However, they describe radio functions on different sides, which will be described in detail below.

[0095] RTCP-FB messages describe the radio capabilities of the receiving side and can be signaled from the MTSI receiver to the MTSI transmitter. The MTSI transmitter gains a basic understanding of the radio capabilities of the MTSI receiver and performs various media adaptation actions based on this information. When the UE of the MTSI receiver moves to a new access network, such as during a handover from NR to LTE, the MTSI receiver can send a new RTCP-FB message describing its radio capabilities to the MTSI transmitter through the new access network.

[0096] RTCP FB messages can be identified by payload type (PT) = payload-specific feedback (PSFB) messages (206). Feedback message type (FMT) can be set to the value "Y" of the radio capability information of the currently accessed network. RTCPFB-based methods may involve signaling the radio capability information of the currently accessed network in both immediate feedback mode and early RTCP mode.

[0097] The RTP header extension message describes the radio capabilities of the transmitting side and can be signaled from the MTSI transmitter to the MTSI receiver. The MTSI receiver will then have a basic understanding of the radio capabilities of the MTSI transmitter and can perform various media adaptation actions based on this information. When the UE used as the MTSI transmitter client moves to a new access network, for example, during a handover from NR to LTE, the MTSI transmitter can send a new RTP header extension message describing the radio capabilities to the MTSI receiver through the new access network.

[0098] In the implementation scheme, radio capability information may include information for delay budget reporting capability, indicating the UE's support for delay budget reporting and the RAN to which the UE is connected's support for receiving delay budget reports. Delay budget reporting capability can be used to indicate, as detailed in 3GPP TR 26.910V2.0.0 (2018-09), for example, whether the UE can perform delay budget reporting and whether its eNB can receive delay budget reports for LTE access, or whether the UE can perform delay budget reporting and whether its gNB can receive delay budget reports for NR access.

[0099] In the implementation, radio capability information may include information for ANBR signaling capabilities, indicating support for the UE to receive ANBR information from its RAN and support for the transmission of ANBR information from the RAN to the UE, as described above. For example, ANBR signaling capabilities may be used, for instance, to indicate whether the UE can receive ANBR from its eNB and whether its eNB can send ANBR information to the UE for LTE access, or to indicate whether the UE can receive ANBR and whether its gNB can send ANBR for NR access. ANBR information may include the UE's uplink ANBR information and the UE's downlink ANBR information, which is not limited in this disclosure.

[0100] The RTCP FB message, which signals from the MTSI receiver to the MTSI transmitter, can carry radio capability information for both downlink and uplink. For example, in the case of ANBR signaling capability, this message would indicate the eNB / gNB's ability to transmit and the UE's ability to receive downlink ANBR, uplink ANBR, or both.

[0101] The RTP header extension message signaled by the MTSI transmitter to the MTSI receiver can carry radio capability information for both downlink and uplink. For example, in the case of ANBR signaling capability, this message would indicate the eNB / gNB's ability to transmit and the UE's ability to receive downlink ANBR, uplink ANBR, or both.

[0102] The Feedback Control Information (FCI) format of the RTCP FB may contain exactly one instance of radio capability information for the currently accessed network. For example, the radio capability information may include: i) ANBR support - Boolean parameters for ANBR signaling capabilities, such as, for LTE access, whether the UE can receive ANBR from its eNB and whether its eNB can send ANBR information to the UE, or for NR access, whether the UE can receive ANBR and whether its gNB can send ANBR; and ii) Delay budget - Boolean parameters for delay budget reporting capabilities, as detailed in 3GPP TR 26.910V2.0.0, such as, for LTE access, whether the UE can perform delay budget reporting and whether its eNB can receive delay budget reports, or for NR access, whether the UE can perform delay budget reporting and whether its gNB can receive delay budget reports.

[0103] 3GPP MTSI clients that support this RTCP FB message can provide this capability in SDP for all media streams containing video / audio. This provision can be made by including the attribute “a=rtcp-fb” in conjunction with the parameter “3gpp-radio-capability”. A wildcard payload type (“*”) can be used to indicate that the RTCP FB attribute applies to all payload types. Here is an example use of this attribute: a=rtcp-fb:*3gpp-radio-capability.

[0104] The extended Backus normal form (ABNF) for rtcp-fb-val corresponding to the feedback type “3gpp-radio-capability” can be given as follows: rtcp-fb-val = / “3gpp-radio-capability”.

[0105] Figure 7 A schematic diagram is shown illustrating an example of an RTP header extension message format 700 according to some embodiments of this disclosure.

[0106] like Figure 7 As shown, parameters “q” and “p” are included in the RTP header extension message. Parameter “q” can be a Boolean parameter relating to ANBR signaling capabilities. For example, it can indicate whether, for LTE access, the UE can receive ANBR information from its eNB and whether its eNB can send ANBR information to the UE; or, for NR access, whether the UE can receive ANBR information and whether its gNB can send ANBR. Parameter “p” can be a Boolean parameter relating to delay budget reporting capabilities, as detailed in 3GPP TR26.910V2.0.0. For example, it can indicate whether, for LTE access, the UE can perform delay budget reporting and whether its eNB can receive delay budget reports; or, for NR access, whether the UE can perform delay budget reporting and whether its gNB can receive delay budget reports.

[0107] 3GPP MTSI clients (based on 3GPP TS 26.114V15.3.0) that support this RTP header extension message can provide this capability in SDP for all media streams containing video / audio. This capability is provided by including the attribute “a=extmap” indicating a Private Uniform Resource Name (URN) under the relevant media line range. The URN corresponding to the capability to signal radio capability information of the currently accessed network is: urn:3gpp:radio-capability. Here is an exemplary use of this URN in SDP: a=extmap:7urn:3gpp:radio-capability. The number 7 in the example can be replaced with any number in the range 1-14.

[0108] The implementation described herein provides SDP and RTP / RTCP-based techniques for negotiating support for ANBR capabilities and RAN-assisted codec adaptation capabilities. Utilizing such indications of ANBR capabilities and RAN-assisted codec adaptation capabilities, the UE can receive ANBR information from the corresponding RAN, and its MTSI client can perform actions triggered by the ANBR information as defined in Clause 10.7 of 3GPP TS26.114 V15.3.0. Therefore, end-to-end coordination between the UE and the access network regarding its ANBR capabilities is achieved, thereby improving the end-to-end quality of VoLTE calls.

[0109] Figure 8 Exemplary components of device 800 according to some embodiments are shown. In some embodiments, device 800 may include application circuitry 802, baseband circuitry 804, radio frequency (RF) circuitry 806, front-end module (FEM) circuitry 808, one or more antennas 810, and power management circuitry (PMC) 812 (at least coupled together as shown). Components of the illustrated device 800 may be included in a UE or AN node. In some embodiments, device 800 may include fewer components (e.g., the AN node may not utilize application circuitry 802, but instead include a processor / controller to process IP data received from the EPC). In some embodiments, device 800 may include additional components such as, for example, memory / storage devices, displays, cameras, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., the circuitry may be individually included in more than one device for a cloud-RAN (C-RAN) specific implementation).

[0110] Application circuitry 802 may include one or more application processors. For example, application circuitry 802 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Processors may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). These processors may be coupled to or may include memory / storage devices and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on device 800. In some embodiments, the processor of application circuitry 802 may process IP data packets received from the EPC.

[0111] Baseband circuitry 804 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 804 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of RF circuitry 806 and to generate baseband signals for the transmit signal path of RF circuitry 806. Baseband processing circuitry 804 may interact with application circuitry 802 to generate and process baseband signals and control the operation of RF circuitry 806. For example, in some embodiments, baseband circuitry 804 may include a third-generation (3G) baseband processor 804A, a fourth-generation (4G) baseband processor 804B, a fifth-generation (5G) baseband processor 804C, or one or more other existing, under development, or future generations of baseband processors 804D (e.g., second-generation (2G), sixth-generation (6G), etc.). Baseband circuitry 804 (e.g., one or more of baseband processors 804A-D) may handle various radio control functions to implement communication with one or more radio networks via RF circuitry 806. In other embodiments, some or all of the functions of the baseband processors 804A-D may be included in modules stored in memory 804G and executed via a central processing unit (CPU) 804E. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, and radio frequency shifting. In some embodiments, the modulation / demodulation circuitry of the baseband circuitry 804 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuitry 804 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity-check (LDPC) encoder / decoder functions. Implementations of the modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

[0112] In some embodiments, the baseband circuitry 804 may include one or more audio digital signal processors (DSPs) 804F. The audio DSP 804F may include elements for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing elements. In some embodiments, components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the components of the baseband circuitry 804 and the application circuitry 802 may be implemented together, for example, on a system-on-a-chip (SoC).

[0113] In some implementations, baseband circuit 804 can provide communication compatible with one or more radio technologies. For example, in some implementations, baseband circuit 804 can support communication with the Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Networks (WMAN), Wireless Local Area Networks (WLAN), or Wireless Personal Area Networks (WPAN). Implementations in which baseband circuit 804 is configured to support radio communication with more than one wireless protocol may be referred to as multimode baseband circuits.

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

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

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

[0117] In some embodiments, the mixer circuit 806a for the receive signal path and the mixer circuit 806a for the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuit 806a for the receive signal path and the mixer circuit 806a for the transmit signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some embodiments, the mixer circuit 806a for the receive signal path and the mixer circuit 806a for the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuit 806a for the receive signal path and the mixer circuit 806a for the transmit signal path may be configured for superheterodyne operation.

[0118] 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 circuit 806 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuit 804 may include a digital baseband interface for communicating with RF circuit 806.

[0119] In some dual-mode implementations, separate radio IC circuits can be provided to process signals for each spectrum, but the scope of the implementation is not limited in this respect.

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

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

[0122] In some implementations, the frequency input may be provided by a voltage-controlled oscillator (VCO), although this is not mandatory. The divider control input may be provided by the baseband circuitry 804 or the application processor 802 according to the desired output frequency. In some implementations, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by the application processor 802.

[0123] 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 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 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 elements 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. Thus, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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

[0125] FEM circuit 808 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 810, amplify the received signals, and provide an amplified version of the received signals to RF circuit 806 for further processing. FEM circuit 808 may also include a transmit signal path, which may include circuitry configured to amplify transmit signals provided by RF circuit 806 for transmission through one or more of the one or more antennas 810. In various embodiments, amplification via the transmit or receive signal path may be performed only in RF circuit 806, only in FEM 808, or in both RF circuit 806 and FEM 808.

[0126] In some embodiments, FEM circuit 808 may include a TX / RX switch to switch between transmit and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., provided to RF circuit 806). The transmit signal path of FEM circuit 808 may include a power amplifier (PA) for amplifying (e.g., provided by RF circuit 806) the input RF signal; and one or more filters for generating an RF signal for subsequent transmission (e.g., through one or more antennas in one or more antennas 810).

[0127] In some implementations, the PMC 812 can manage the power supplied to the baseband circuitry 804. Specifically, the PMC 812 can control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 812 is typically included when the device 800 is capable of being battery powered, for example, when the device is included in a UE. The PMC 812 can improve power conversion efficiency while providing the desired specific implementation size and thermal characteristics.

[0128] and Figure 8The PMC 812 is shown coupled only to the baseband circuit 804. However, in other embodiments, the PMC 812 may be additionally or alternatively coupled to other components, such as, but not limited to, application circuit 802, RF circuit 806, or FEM 808, and perform similar power management operations.

[0129] In some implementations, PMC 812 can control or otherwise become part of various power-saving mechanisms of device 800. For example, if device 800 is in the RRC_Connected state, where the device is still connected to the RAN node because it expects to receive traffic immediately, it can enter a state called Discontinuous Receive Mode (DRX) after a period of inactivity. During this state, device 800 can be powered down for short intervals, thereby saving power.

[0130] If there is no data traffic activity during the extended period, device 800 may transition to the RRC Idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback or handover. Device 800 enters a very low power state and performs paging, in which the device periodically wakes up again to listen to the network, and then powers off again. Device 800 may be unable to receive data in this state, and in order to receive data, it must transition back to the RRC Connected state.

[0131] An additional power-saving mode allows the device to be unavailable from the network for periods exceeding the paging interval (ranging from seconds to hours). During this time, the device is completely unconnected to the network and can be completely powered off. Any data sent during this period will incur significant latency, which is assumed to be acceptable.

[0132] The processors of application circuitry 802 and baseband circuitry 804 are elements that can be used to execute one or more instances of the protocol stack. For example, the processor of baseband circuitry 804 can be used alone or in combination to execute layer 3, layer 2, or layer 1 functions, while the processor of application circuitry 804 can utilize data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., Transport Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include the Radio Resource Control (RRC) layer. As mentioned herein, layer 2 may include the Media Access Control (MAC) layer, Radio Link Control (RLC) layer, and Packet Data Convergence Protocol (PDCP) layer. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node.

[0133] Figure 9 An exemplary interface of a baseband circuit according to some embodiments is shown. As discussed above, Figure 8The baseband circuit 804 may include processors 804A-804E and a memory 804G utilized by the processors. Each of the processors 804A-804E may respectively include a memory interface 904A-904E for sending / receiving data to / from the memory 804G.

[0134] The baseband circuit 804 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 912 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 804) and an application circuit interface 914 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 804). Figure 8 Application circuit 802 (interface for sending / receiving data), RF circuit interface 916 (e.g., for sending / receiving data to / from...). Figure 8 The RF circuit 806 is an interface for transmitting / receiving data, and the wireless hardware connection interface 918 is used for transmitting / receiving data to / from near field communication (NFC) components. Components (e.g.) (low power consumption) Interfaces for sending / receiving data to / from components and other communication components) and power management interface 920 (e.g., an interface for sending / receiving power or control signals to / from PMC 812).

[0135] Figure 10 This is a block diagram illustrating components, according to some exemplary embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of executing any or more of the methods discussed herein. 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 can be communicatively coupled via bus 1040. For implementations utilizing node virtualization (e.g., NFV), an executable hypervisor 1002 can be used to provide an execution environment for one or more network slices / subslices to utilize hardware resources 1000.

[0136] Processor 1010 (e.g., 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 digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1012 and processor 1014.

[0137] The memory / storage device 1020 may include main memory, disk storage devices, 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 devices, etc.

[0138] Communication resource 1030 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1004 or one or more databases 1006 via network 1008. For example, communication resource 1030 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB), cellular communication components, NFC components, etc. Components (e.g.) (low power consumption) Components and other communication components.

[0139] Instructions 1050 may include software, programs, applications, applets, or other executable code for causing at least one processor in processor 1010 to perform any one or more of the methods discussed herein. Instructions 1050 may reside wholly or partially in processor 1010 (e.g., within the processor's cache memory), memory / storage device 1020, or any suitable combination thereof. Furthermore, any portion of instructions 1050 may be transferred to hardware resource 1000 from any combination of peripheral device 1004 or database 1006. Therefore, the memory of processor 1010, memory / storage device 1020, peripheral device 1004, and database 1006 are examples of computer-readable and machine-readable media.

[0140] The following paragraphs describe examples of various implementation schemes.

[0141] Example 1 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE. The apparatus includes: a radio frequency (RF) interface for receiving a Session Description Protocol (SDP) provision message from the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating support for Access Network Bit Rate Recommendation (ANBR) capability of the remote UE, and wherein the ANBR capability of the remote UE corresponds to the ability to receive ANBR information from a Remote Radio Access Network (RAN) to which the remote UE is connected, or the ability of the remote RAN to transmit ANBR information; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: decode the SDP provision message received from the RF interface to obtain the first dedicated SDP attribute parameter, thereby determining support for the ANBR capability of the remote UE; encode an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating support for the ANBR capability of the UE, and wherein the ANBR capability of the UE corresponds to the ability to receive ANBR information from a RAN to which the UE is connected, or the ability of the RAN to transmit the ANBR information; and cause the SDP response message to be transmitted to the remote UE.

[0142] Example 2 includes the device according to Example 1, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0143] Example 3 includes the device according to Example 1, wherein the second dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the UE, and the first dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the remote UE.

[0144] Example 4 includes the device according to Example 3, wherein the RAN-assisted codec adaptation of the UE is performed by the UE based on ANBR information received from the RAN, and the RAN-assisted codec adaptation of the remote UE is performed by the remote UE based on ANBR information received from the remote RAN.

[0145] Example 5 includes the device according to Example 4, wherein the ANBR information received by the UE from the RAN is uplink ANBR information, and wherein the processor circuitry is configured to adjust the transmission bit rate of the media used for transmitting a multimedia telephony session based on the uplink ANBR information.

[0146] Example 6 includes the device according to Example 5, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0147] Example 7 includes the device according to Example 5, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0148] Example 8 includes the device according to Example 7, wherein the ANBR information received by the remote UE from the remote RAN is downlink ANBR information, and wherein when the bit rate value is greater than the transmit bit rate, the processor circuitry is configured to further adjust the transmit bit rate based on the downlink ANBR information of the remote UE.

[0149] Example 9 includes the device according to any one of Examples 1-8, wherein the media includes voice or video.

[0150] Example 10 includes the device according to Example 4, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the medium includes voice, and wherein processor circuitry is configured to: encode a Codec Mode Request (CMR) / Real-Time Transmission Control Protocol (RTCP) Application (RTCP-APP) message for transmission to the remote UE based on the downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice for the multimedia telephony session.

[0151] Example 11 includes the device according to Example 10, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0152] Example 12 includes the device according to Example 10, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0153] Example 13 includes the device according to Example 4, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the media including video, and wherein processor circuitry is configured to: encode, based on the downlink ANBR information received from the RAN, a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to the remote UE, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0154] Example 14 includes the device according to Example 13, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0155] Example 15 includes the device according to Example 13, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0156] Example 16 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE. The apparatus includes: a radio frequency (RF) interface for receiving a Session Description Protocol (SDP) provisioning message from the remote UE, wherein the SDP provisioning message includes a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the remote UE; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: decode the SDP provisioning message received from the RF interface; encode an SDP response message in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the UE; and cause the SDP response message to be transmitted to the remote UE.

[0157] Example 17 includes the device according to Example 16, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0158] Example 18 includes the device according to Example 17, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0159] Example 19 includes the device according to Example 17, wherein the processor circuitry is used to adjust the transmission bit rate of the medium for transmitting a multimedia telephone session based on uplink ANBR information received from the RAN.

[0160] Example 20 includes the device according to Example 19, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0161] Example 21 includes the device according to Example 19, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0162] Example 22 includes the device according to Example 21, wherein when the bit rate value is greater than the transmit bit rate, the processor circuitry is configured to further adjust the transmit bit rate based on the downlink ANBR information of the remote UE.

[0163] Example 23 includes the device according to any one of Examples 16-22, wherein the media includes voice or video.

[0164] Example 24 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the apparatus comprising: a radio frequency (RF) interface; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: encode a Session Description Protocol (SDP) provisioning message including a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the UE; cause the SDP provisioning message to be transmitted to the remote UE; and decode an SDP response message transmitted from the remote UE in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the remote UE.

[0165] Example 25 includes the device according to Example 24, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0166] Example 26 includes the device according to Example 25, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0167] Example 27 includes the device according to Example 25 or 26, wherein the medium includes voice, and wherein the processor circuitry is configured to: encode a Codec Mode Request (CMR) / Real-Time Transmission Control Protocol (RTCP) Application (RTCP-APP) message for transmission to the remote UE based on downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice for the multimedia telephony session.

[0168] Example 28 includes the device according to Example 27, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0169] Example 29 includes the device according to Example 27, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0170] Example 30 includes the device according to Example 25 or 26, wherein the media includes video, and wherein the processor circuitry is configured to: encode a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to a remote UE based on downlink ANBR information received from the RAN, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0171] Example 31 includes the device according to Example 30, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0172] Example 32 includes the device according to Example 30, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0173] Example 33 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephone session with a remote UE, the apparatus including: a radio frequency (RF) interface; and processor circuitry coupled to the RF interface, wherein the processor circuitry is configured to: encode a message including radio capability information of the UE; and cause the message to be transmitted to the remote UE.

[0174] Example 34 includes the device according to Example 33, wherein the messages include application layer messages.

[0175] Example 35 includes the device according to Example 34, wherein the application layer messages include: Real-time Transport Control Protocol (RTCP) feedback messages; or Real-time Transport Protocol (RTP) header extension messages.

[0176] Example 36 includes the device according to Example 33, wherein the message includes a Session Description Protocol (SDP) message during capability negotiation based on Internet Protocol (IP) Multimedia Subsystem (IMS) / Session Initiation Protocol (SIP), wherein the SDP message includes: dedicated SDP parameters based on Real-time Transmission Control Protocol (RTCP) capabilities; or dedicated SDP parameters based on Real-time Transport Protocol (RTP) capabilities.

[0177] Example 37 includes the device according to any one of Examples 33 to 36, wherein the radio capability information includes information for delay budget reporting capability, which indicates the UE's support for delay budget reporting and the radio access network (RAN) to which the UE is connected to support the reception of delay budget reporting.

[0178] Example 38 includes the device according to any one of Examples 33 to 36, wherein the radio capability information includes information for Access Network Bit Rate Recommendation (ANBR) signaling capabilities, which indicates the UE's support for receiving ANBR information from the radio access network (RAN) to which the UE is connected and for transmitting ANBR information from the RAN to the UE.

[0179] Example 39 includes the device according to Example 38, wherein the ANBR information includes uplink ANBR information for the UE and downlink ANBR information for the UE.

[0180] Example 40 includes the device according to any one of Examples 37 to 39, wherein the RAN includes an access node, and wherein the access node includes an enhanced NodeB (eNB) or a next-generation NodeB (gNB).

[0181] Example 41 includes a method for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the method comprising: decoding a Session Description Protocol (SDP) provision message received from the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating support for Access Network Bit Rate Recommendation (ANBR) capability of the remote UE, and wherein the ANBR capability of the remote UE corresponds to the ability to receive ANBR information from a remote radio access network (RAN) to which the remote UE is connected or the ability of the remote RAN to transmit ANBR information; encoding an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating support for the UE's ANBR capability, and wherein the ANBR capability of the UE corresponds to the ability to receive ANBR information from a RAN to which the UE is connected or the ability of the RAN to transmit ANBR information; and transmitting the SDP response message to the remote UE.

[0182] Example 42 includes the method according to Example 41, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0183] Example 43 includes the method according to Example 41 or 42, wherein the second dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the UE, and the first dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the remote UE.

[0184] Example 44 includes the device according to Example 43, wherein the RAN-assisted codec adaptation of the UE is performed by the UE based on ANBR information received from the RAN, and the RAN-assisted codec adaptation of the remote UE is performed by the remote UE based on ANBR information received from the remote RAN.

[0185] Example 45 includes the method according to Example 44, wherein the ANBR information received by the UE from the RAN is uplink ANBR information, and wherein the method further includes adjusting the transmission bit rate of the media used for transmitting multimedia telephony sessions based on the uplink ANBR information.

[0186] Example 46 includes the method according to Example 45, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0187] Example 47 includes the method according to Example 45, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0188] Example 48 includes the method according to Example 47, wherein the ANBR information received by the remote UE from the remote RAN is downlink ANBR information, and wherein when the bit rate value is greater than the transmit bit rate, the method further includes adjusting the transmit bit rate based on the downlink ANBR information of the remote UE.

[0189] Example 49 includes the method of any one of Examples 41-48, wherein the media includes voice or video.

[0190] Example 50 includes the method according to Example 44, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the medium includes voice, and wherein the method further includes: encoding a Codec Mode Request (CMR) / Real-Time Transmission Control Protocol (RTCP) Application (RTCP-APP) message for transmission to the remote UE based on the downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice of the multimedia telephony session.

[0191] Example 51 includes the method according to Example 50, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0192] Example 52 includes the method according to Example 50, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0193] Example 53 includes the method according to Example 44, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the media including video, and wherein the method further includes: encoding a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to the remote UE based on the downlink ANBR information received from the RAN, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0194] Example 54 includes the method according to Example 53, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0195] Example 55 includes the method according to Example 53, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0196] Example 56 includes a method for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the method comprising: decoding a Session Description Protocol (SDP) provisioning message from the remote UE, wherein the SDP provisioning message includes a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the remote UE; encoding an SDP response message in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the UE; and transmitting the SDP response message to the remote UE.

[0197] Example 57 includes the method according to Example 56, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0198] Example 58 includes the method according to Example 57, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0199] Example 59 includes the method according to Example 57, wherein the method further includes adjusting the transmission bit rate of the media used for transmitting multimedia telephony sessions based on uplink ANBR information received from the RAN.

[0200] Example 60 includes the method according to Example 59, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0201] Example 61 includes the method according to Example 59, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0202] Example 62 includes the method according to Example 61, wherein when the bit rate value is greater than the transmission bit rate, the method further includes adjusting the transmission bit rate based on the downlink ANBR information of the remote UE.

[0203] Example 63 includes the method of any one of Examples 56-62, wherein the media includes voice or video.

[0204] Example 64 includes a method for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the method comprising: encoding a Session Description Protocol (SDP) provisioning message, the SDP provisioning message including a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the UE; transmitting the SDP provisioning message to the remote UE; and decoding an SDP response message transmitted from the remote UE in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the remote UE.

[0205] Example 65 includes the method according to Example 64, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0206] Example 66 includes the method according to Example 65, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0207] Example 67 includes the method according to Example 65 or 66, wherein the medium includes voice, and wherein the method further includes: encoding a Codec Mode Request (CMR) / Real-Time Transmission Control Protocol (RTCP) Application (RTCP-APP) message for transmission to the remote UE based on downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice of the multimedia telephony session.

[0208] Example 68 includes the method according to Example 67, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0209] Example 69 includes the method according to Example 67, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0210] Example 70 includes the method according to Example 65 or 66, wherein the media includes video, and wherein the method further includes: encoding a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to a remote UE based on downlink ANBR information received from the RAN, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0211] Example 71 includes the method according to Example 70, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0212] Example 72 includes the method according to Example 70, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0213] Example 73 includes a method for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the method comprising: encoding a message including radio capability information of the UE; and transmitting the message to the remote UE.

[0214] Example 74 includes the method according to Example 73, wherein the message includes an application layer message.

[0215] Example 75 includes the method according to Example 74, wherein the application layer message includes: a Real-time Transport Control Protocol (RTCP) feedback message; or a Real-time Transport Protocol (RTP) header extension message.

[0216] Example 76 includes the method according to Example 73, wherein the message includes a Session Description Protocol (SDP) message during capability negotiation based on Internet Protocol (IP) Multimedia Subsystem (IMS) / Session Initiation Protocol (SIP), wherein the SDP message includes: dedicated SDP parameters based on Real-time Transmission Control Protocol (RTCP) capabilities; or dedicated SDP parameters based on Real-time Transport Protocol (RTP) capabilities.

[0217] Example 77 includes the method according to any one of Examples 73 to 76, wherein the radio capability information includes information for delay budget reporting capability, which indicates the UE's support for delay budget reporting and the radio access network (RAN) to which the UE is connected to support the reception of delay budget reports.

[0218] Example 78 includes the method according to any one of Examples 73 to 76, wherein the radio capability information includes information for Access Network Bit Rate Recommendation (ANBR) signaling capabilities, which indicates the UE's support for receiving ANBR information from the radio access network (RAN) to which the UE is connected and for transmitting ANBR information from the RAN to the UE.

[0219] Example 79 includes the method according to Example 78, wherein the ANBR information includes uplink ANBR information for the UE and downlink ANBR information for the UE.

[0220] Example 80 includes the method according to any one of Examples 77 to 79, wherein the RAN includes an access node, and wherein the access node includes an enhanced NodeB (eNB) or a next-generation NodeB (gNB).

[0221] Example 81 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE. The apparatus includes: means for decoding a Session Description Protocol (SDP) provision message received from the remote UE, wherein the SDP provision message includes a first dedicated SDP attribute parameter indicating support for Access Network Bit Rate Recommendation (ANBR) capability of the remote UE, and wherein the ANBR capability of the remote UE corresponds to the ability to receive ANBR information from a Remote Radio Access Network (RAN) to which the remote UE is connected, or the ability of the remote RAN to transmit ANBR information; means for encoding an SDP response message in response to the SDP provision message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating support for the UE's ANBR capability, and wherein the ANBR capability of the UE corresponds to the ability to receive ANBR information from a RAN to which the UE is connected, or the ability of the RAN to transmit the ANBR information; and means for transmitting the SDP response message to the remote UE.

[0222] Example 82 includes the device according to Example 81, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0223] Example 83 includes the device according to Example 81 or 82, wherein the second dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the UE, and the first dedicated SDP attribute parameter is further used to indicate support for RAN-assisted codec adaptation for the remote UE.

[0224] Example 84 includes the device according to Example 83, wherein the RAN-assisted codec adaptation of the UE is performed by the UE based on ANBR information received from the RAN, and the RAN-assisted codec adaptation of the remote UE is performed by the remote UE based on ANBR information received from the remote RAN.

[0225] Example 85 includes the device according to Example 84, wherein the ANBR information received by the UE from the RAN is uplink ANBR information, and wherein the device further includes adjusting the transmission bit rate of the media used for transmitting multimedia telephony sessions based on the uplink ANBR information.

[0226] Example 86 includes the device according to Example 85, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0227] Example 87 includes the device according to Example 85, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0228] Example 88 includes the device according to Example 87, wherein the ANBR information received by the remote UE from the remote RAN is downlink ANBR information, and wherein when the bit rate value is greater than the transmit bit rate, the device further includes means for further adjusting the transmit bit rate based on the downlink ANBR information of the remote UE.

[0229] Example 89 includes the device according to any one of Examples 81-88, wherein the media includes voice or video.

[0230] Example 90 includes the apparatus according to Example 84, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the medium includes voice, and wherein the apparatus further includes means for encoding a codec mode request (CMR) / RTCP-APP message for transmitting to the remote UE based on the downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice of the multimedia telephony session.

[0231] Example 91 includes the device according to Example 90, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0232] Example 92 includes the device according to Example 90, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0233] Example 93 includes the apparatus according to Example 84, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the media including video, and wherein the apparatus further includes: means for encoding a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to the remote UE based on the downlink ANBR information received from the RAN, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0234] Example 94 includes the device according to Example 93, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0235] Example 95 includes the device according to Example 93, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0236] Example 96 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE, the apparatus comprising: means for decoding a Session Description Protocol (SDP) provisioning message from the remote UE, wherein the SDP provisioning message includes a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the remote UE; means for encoding an SDP response message in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the UE; and means for transmitting the SDP response message to the remote UE.

[0237] Example 97 includes the apparatus according to Example 96, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0238] Example 98 includes the device according to Example 97, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0239] Example 99 includes the apparatus according to Example 97, wherein the apparatus further includes means for adjusting the transmission bit rate of media for transmitting multimedia telephone sessions based on uplink ANBR information received from the RAN.

[0240] Example 100 includes the device according to Example 99, wherein when the bit rate value is less than the transmit bit rate, the transmit bit rate is reduced to the bit rate value indicated by the uplink ANBR information.

[0241] Example 101 includes the device according to Example 99, wherein when the bit rate value indicated by the uplink ANBR information is greater than the transmit bit rate, the transmit bit rate is increased to the minimum bit rate value among the bit rate value indicated by the uplink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0242] Example 102 includes the device according to Example 101, wherein when the bit rate value is greater than the transmit bit rate, the device further includes means for adjusting the transmit bit rate based on downlink ANBR information of the remote UE.

[0243] Example 103 includes the device according to any one of Examples 96-102, wherein the media includes voice or video.

[0244] Example 104 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephony session with a remote UE. The apparatus includes: means for encoding a Session Description Protocol (SDP) provisioning message, the SDP provisioning message including a first dedicated SDP attribute parameter indicating adaptive support for a radio access network (RAN)-assisted codec for the UE; means for transmitting the SDP provisioning message to the remote UE; and means for decoding an SDP response message transmitted from the remote UE in response to the SDP provisioning message, wherein the SDP response message includes a second dedicated SDP attribute parameter indicating adaptive support for a RAN-assisted codec for the remote UE.

[0245] Example 105 includes the device according to Example 104, wherein the RAN-assisted codec adaptation for the transmit bit rate of the UE is performed based on uplink access network bit rate recommendation (ANBR) information received from the RAN to which the UE is connected, the RAN-assisted codec adaptation for the receive bit rate of the UE is performed based on downlink ANBR information received from the RAN, the RAN-assisted codec adaptation for the transmit bit rate of the remote UE is performed based on uplink ANBR information received from the remote RAN to which the remote UE is connected, and the RAN-assisted codec adaptation for the receive bit rate of the remote UE is performed based on downlink ANBR information received from the remote RAN.

[0246] Example 106 includes the device according to Example 105, wherein both the first dedicated SDP attribute parameter and the second dedicated SDP attribute parameter are identified as "ANBR_adapt".

[0247] Example 107 includes the apparatus according to Example 105 or 106, wherein the medium includes voice, and wherein the apparatus further includes means for encoding a Codec Mode Request (CMR) / Real-time Transmission Control Protocol (RTCP) Application (RTCP-APP) message for transmission to the remote UE based on downlink ANBR information received from the RAN, wherein the CMR / RTCP-APP message is used to indicate a desired receive bit rate for receiving the voice of the multimedia telephony session.

[0248] Example 108 includes the device according to Example 107, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0249] Example 109 includes the device according to Example 107, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving voice in a multimedia telephone session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0250] Example 110 includes the apparatus according to Example 105 or 106, wherein the media includes video, and wherein the apparatus further includes means for encoding a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message for transmission to a remote UE based on downlink ANBR information received from the RAN, wherein the RTCP TMMBR message is used to indicate a desired receive bit rate for receiving the video for the multimedia telephony session.

[0251] Example 111 includes the device according to Example 110, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving video for a multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

[0252] Example 112 includes the device according to Example 110, wherein when the bit rate value indicated by the downlink ANBR information is greater than the receive bit rate for receiving video for a multimedia telephony session, the desired receive bit rate is determined as the minimum bit rate value among the bit rate value indicated by the downlink ANBR information and the bit rate value limited by each of the other bit rate adaptive triggers of the UE.

[0253] Example 113 includes an apparatus for a user equipment (UE) operable to stream a multimedia telephone session with a remote UE, the apparatus comprising: means for encoding a message including radio capability information of the UE; and means for transmitting the message to the remote UE.

[0254] Example 114 includes the device according to Example 113, wherein the messages include application layer messages.

[0255] Example 115 includes the device according to Example 114, wherein the application layer messages include: Real-time Transport Control Protocol (RTCP) feedback messages; or Real-time Transport Protocol (RTP) header extension messages.

[0256] Example 116 includes the device according to Example 113, wherein the message includes a Session Description Protocol (SDP) message during capability negotiation based on Internet Protocol (IP) Multimedia Subsystem (IMS) / Session Initiation Protocol (SIP), wherein the SDP message includes: dedicated SDP parameters based on Real-time Transmission Control Protocol (RTCP) capabilities; or dedicated SDP parameters based on Real-time Transport Protocol (RTP) capabilities.

[0257] Example 117 includes the device according to any one of Examples 113 to 116, wherein the radio capability information includes information for delay budget reporting capability, which indicates the UE's support for delay budget reporting and the radio access network (RAN) to which the UE is connected to support the reception of delay budget reporting.

[0258] Example 118 includes the device according to any one of Examples 113 to 116, wherein the radio capability information includes information for access network bit rate recommendation (ANBR) signaling capabilities, which indicates the UE's support for receiving ANBR information from the radio access network (RAN) to which the UE is connected and for transmitting ANBR information from the RAN to the UE.

[0259] Example 119 includes the device according to Example 118, wherein the ANBR information includes uplink ANBR information for the UE and downlink ANBR information for the UE.

[0260] Example 120 includes the device according to any one of Examples 117 to 119, wherein the RAN includes an access node, and wherein the access node includes an enhanced NodeB (eNB) or a next-generation NodeB (gNB).

[0261] Example 121: One or more computer-readable media having instructions stored thereon, which, when executed by processor circuitry, cause the processor circuitry to perform the method according to any one of Examples 41 to 80.

[0262] Example 122 includes user equipment (UE) as shown and described in the specification.

[0263] Example 123 includes an access node as shown and described in the specification.

[0264] Example 124 includes a method performed at the user equipment (UE) as shown and described in the specification.

[0265] Example 125 includes a method performed at an access node as shown and described in the specification.

[0266] While specific embodiments have been illustrated and described herein for illustrative purposes, various alternative and / or equivalent embodiments or specific implementations intended to achieve the same purpose may replace the shown and described embodiments without departing from the scope of this disclosure. This patent application is intended to cover any modifications or variations of the embodiments discussed herein. Therefore, it is apparent that the embodiments described herein are limited only by the appended claims and their equivalents.

Claims

1. A method for communication, comprising: At the user equipment (UE), a Session Description Protocol (SDP) Provided Message is received from a remote UE for use in a multimedia telephony session, wherein the SDP Provided Message includes a Real-Time Transport Protocol (RTP) Header Extension Message, which indicates the radio capability information of the remote UE for both uplink and downlink. Based on the values ​​of the SDP attribute parameters included in the SDP provision message, support for the delay budget reporting capability of the remote UE is determined, wherein the delay budget reporting capability of the remote UE corresponds to the remote UE's ability to receive delay budget reports; In response to determining support for the delay budget reporting capability of the remote UE, an SDP response message to the remote UE is encoded, wherein the encoding includes including the value of an SDP attribute parameter in the SDP response message to indicate support for the delay budget reporting capability of the UE, wherein the delay budget reporting capability of the UE corresponds to the UE's ability to receive delay budget reports, wherein the SDP response message includes a Real-time Transmission Control Protocol (RTCP) feedback message indicating the UE's radio capability information for both uplink and downlink; as well as This enables the transmission of the SDP response message to the remote UE.

2. The method of claim 1, wherein the SDP attribute parameter corresponds to a Boolean parameter in the RTP header extension message, the Boolean parameter indicating delay budget reporting capability.

3. The method according to claim 1, wherein the SDP attribute parameter includes the attribute "a=rtcp-fb".

4. The method of claim 1, wherein the delay budget reporting capability of the remote UE corresponds to the ability of at least one of the remote UE and the remote base station to which the remote UE is connected to receive a delay budget report, and wherein the delay budget reporting capability of the UE corresponds to the ability of at least one of the UE and the base station to which the UE is connected to receive a delay budget report.

5. A method for communication, comprising: The user equipment (UE) receives a Session Description Protocol (SDP) Provided Message from a remote UE for use in a multimedia telephony session. The SDP Provided Message includes a first SDP attribute parameter indicating support for the Access Network Bit Rate Recommendation (ANBR) capability of the remote UE. The ANBR capability of the remote UE corresponds to the ability of the remote UE to receive ANBR information from the Remote Radio Access Network (RAN) to which the remote UE is connected. In response to the SDP provide message, an SDP response message is transmitted to the remote UE, wherein the SDP response message includes a second SDP attribute parameter indicating support for the UE's ANBR capability, wherein the UE's ANBR capability corresponds to the UE's ability to receive ANBR information from the RAN to which the UE is connected. The remote UE receives a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message, wherein the RTCP TMMBN message indicates the bit rate of the media used to transmit the multimedia telephony session; as well as Based on the RTCP TMMBN message, a Real-Time Transmission Control Protocol (RTC) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message is transmitted to the remote UE, wherein the RTCP TMMBR message is different from the SDP acknowledgment message and indicates the desired receive bit rate for receiving the media of the multimedia telephony session.

6. The method of claim 5, wherein the second SDP attribute parameter further indicates support for RAN-assisted codec adaptation of the UE, and the first SDP attribute parameter further indicates support for RAN-assisted codec adaptation of the remote UE, and The RAN-assisted codec adaptation of the UE is performed by the UE based on the ANBR information received by the UE from the RAN, and the RAN-assisted codec adaptation of the remote UE is performed by the remote UE based on the ANBR information received by the remote UE from the remote RAN.

7. The method of claim 6, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, and the media includes voice, the method comprising: Based on the downlink ANBR information received from the RAN, a codec mode request CMR / Real-time Transport Control Protocol RTCP Application RTCP-APP message for transmission to the remote UE is encoded, wherein the CMR / RTCP-APP message indicates the desired receive bit rate for receiving the voice of the multimedia telephony session.

8. The method of claim 7, wherein when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving the voice of the multimedia telephone session, the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information.

9. The method of claim 5, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, and the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate of the media used to receive the multimedia telephony session.

10. One or more non-transitory computer-readable media storing instructions that, when executed by processor circuitry of a user equipment (UE), cause the processor circuitry to perform operations, the operations including: At the UE, a Session Description Protocol (SDP) Provided Message is received from a remote UE for use in a multimedia telephony session; Based on the values ​​of the SDP attribute parameters included in the SDP provision message, support for the delay budget reporting capability of the remote UE is determined, wherein the delay budget reporting capability of the remote UE corresponds to the remote UE's ability to receive delay budget reports; In response to determining support for the delay budget reporting capability of the remote UE, an SDP response message to the remote UE is encoded, wherein the encoding includes including the value of an SDP attribute parameter in the SDP response message to indicate support for the delay budget reporting capability of the UE, wherein the delay budget reporting capability of the UE corresponds to the UE's ability to receive delay budget reports; as well as This enables the transmission of the SDP response message to the remote UE.

11. The one or more non-transitory computer-readable media of claim 10, wherein the SDP providing message includes a Real-Time Transport Protocol (RTP) header extension message, the RTP header extension message indicating radio capability information of the remote UE.

12. The one or more non-transitory computer-readable media of claim 11, wherein the SDP attribute parameter corresponds to a Boolean parameter in the RTP header extension message, the Boolean parameter indicating delay budget reporting capability.

13. The one or more non-transitory computer-readable media of claim 10, wherein the SDP response message includes a Real-Time Transmission Control Protocol (RTCP) feedback message, the RTCP feedback message indicating radio capability information of the UE.

14. The one or more non-transitory computer-readable media of claim 10, wherein the SDP attribute parameter includes the attribute "a=rtcp-fb".

15. The one or more non-transitory computer-readable media of claim 10, wherein the delay budget reporting capability of the remote UE corresponds to the ability of at least one of the remote UE and the remote base station to which the remote UE is connected to receive a delay budget report, and wherein the delay budget reporting capability of the UE corresponds to the ability of at least one of the UE and the base station to which the UE is connected to receive a delay budget report.

16. One or more non-transitory computer-readable media storing instructions that, when executed by processor circuitry of a user equipment (UE), cause the processor circuitry to perform operations, the operations including: The UE receives a Session Description Protocol (SDP) Provided Message from a remote UE for use in a multimedia telephony session, wherein the SDP Provided Message includes a first SDP attribute parameter indicating support for the Access Network Bit Rate Recommendation (ANBR) capability of the remote UE, wherein the ANBR capability of the remote UE corresponds to the ability of the remote UE to receive ANBR information from the Remote Radio Access Network (RAN) to which the remote UE is connected. In response to the SDP provide message, an SDP response message is transmitted to the remote UE, wherein the SDP response message includes a second SDP attribute parameter indicating support for the UE's ANBR capability, wherein the UE's ANBR capability corresponds to the UE's ability to receive ANBR information from the RAN to which the UE is connected. The remote UE receives a Real-Time Transmission Control Protocol (RTCP) Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message, wherein the RTCP TMMBN message indicates the bit rate of the media used to transmit the multimedia telephony session; as well as Based on the RTCP TMMBN message, a Real-Time Transmission Control Protocol (RTC) Temporary Maximum Media Stream Bit Rate Request (TMMBR) message is transmitted to the remote UE, wherein the RTCP TMMBR message is different from the SDP acknowledgment message and indicates the desired receive bit rate for receiving the media of the multimedia telephony session.

17. The one or more non-transitory computer-readable media of claim 16, wherein the second SDP attribute parameter further indicates support for RAN-assisted codec adaptation of the UE, and the first SDP attribute parameter further indicates support for RAN-assisted codec adaptation of the remote UE, and The RAN-assisted codec adaptation of the UE is performed by the UE based on the ANBR information received by the UE from the RAN, and the RAN-assisted codec adaptation of the remote UE is performed by the remote UE based on the ANBR information received by the remote UE from the remote RAN.

18. One or more non-transitory computer-readable media according to claim 17, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, the media includes voice, and the operation includes: Based on the downlink ANBR information received from the RAN, a codec mode request CMR / Real-time Transport Control Protocol RTCP Application RTCP-APP message for transmission to the remote UE is encoded, wherein the CMR / RTCP-APP message indicates the desired receive bit rate for receiving the voice of the multimedia telephony session.

19. One or more non-transitory computer-readable media of claim 18, wherein the desired receive bit rate is determined to be the bit rate value indicated by the downlink ANBR information when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate for receiving the voice of the multimedia telephone session.

20. One or more non-transitory computer-readable media according to claim 16, wherein the ANBR information received by the UE from the RAN is downlink ANBR information, and the desired receive bit rate is determined as the bit rate value indicated by the downlink ANBR information when the bit rate value indicated by the downlink ANBR information is less than the receive bit rate of the media used to receive the multimedia telephony session.