US20190215729A1 - Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions - Google Patents

Abstract

Systems, apparatuses, methods, and computer-readable media are provided for negotiating Radio Access Network (RAN)-level capabilities toward improving end-to-end quality of Internet Protocol Multimedia Subsystem (IMS) communication sessions, such as Voice over Long-Term Evolution (VoLTE) calls. Disclosed embodiments include Session Description Protocol-based mechanisms to signal the RAN-level capabilities. The RAN-level capabilities may include, for example, delay budget information signaling, Transmission Time Interval bundling, RAN frame aggregation, RAN-assisted codec adaptation or access network bitrate recommendation, and/or other like capabilities. Other embodiments may be described and/or claimed.

Description

RELATED APPLICATIONS
• The present application claims priority under 35 U.S.C. § 119 to U.S. Provisional App. No. 62/643,541 filed Mar. 15, 2018, the contents of which is hereby incorporated by reference in its entirety.
FIELD
• Various embodiments of the present application generally relate to the field of wireless communications, and in particular, to Multimedia Telephony Service for IMS technologies.
BACKGROUND
• MTSI supports conversational speech, video, and text transported over RTP to deliver a user experience equivalent to or better than that of circuit switched conversational services using the same amount of network resources. MTSI defines media handling (e.g., signaling, transport, jitter buffer management, packet-loss handling, and adaptation), as well as interactivity (e.g., adding or dropping media during a call). The focus is to ensure a reliable and interoperable service with a predictable media quality, while allowing for flexibility in the service offerings. MTSI uses SIP, SDP, and SDP capabilities negotiation protocols for media negotiation and configuration. No signaling mechanisms are currently defined to provide e2e coordination between UEs with respect to radio capabilities.
BRIEF DESCRIPTION OF THE FIGURES
• FIG. 1 depicts an architecture of a system of a network in accordance with some embodiments.
• FIG. 2 illustrates an example Multimedia Telephony Service for IMS architecture according to various embodiments.
• FIG. 3 depicts an example use case for RAN delay budget reporting.
• FIG. 4 depicts an example procedure for RAN delay budget reporting in MTSI according to some embodiments.
• FIG. 5 shows an example bitmask, which may be used for SDP-based negotiation of RAN capabilities, in accordance with various embodiments.
• FIG. 6 depicts an example of infrastructure equipment in accordance with various embodiments.
• FIG. 7 depicts example components of a computer platform in accordance with various embodiments.
• FIG. 8 depicts a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
• FIG. 9 depicts example components of baseband circuitry and radio frequency circuitry in accordance with various embodiments.
• FIG. 10 is an illustration of various protocol functions that may be used for various protocol stacks in accordance with various embodiments.
• FIG. 11 depicts example bit rate recommendation MAC CEs according to various embodiments.
• FIGS. 12-13 depict example processes for practicing the various embodiments discussed herein.
DETAILED DESCRIPTION
• Embodiments herein are related to SDP-based mechanisms to signal specific RAN-level capabilities toward improving e2e quality of VoLTE/ViLTE calls. Signaled RAN-level capabilities may include, for example, Delay Budget Reporting, TTI bundling, RAN frame aggregation, RAN-assisted codec adaptation, etc. According to various embodiments, a first UE is operable to perform multimedia telephony with a second UE, wherein the second UE is remote from the first UE. The first UE is configured to receive an SDP offer message from the second UE with an attribute describing radio capabilities of the second UE, and send an SDP answer message to the second UE with an attribute describing the radio capabilities of the first UE. In some embodiments, the attribute describing radio capabilities includes descriptors, configurations, and/or parameters pertaining to specific RF circuitry or modem (or baseband circuitry) capabilities. In some embodiments, the specific RF circuitry or modem (or baseband circuitry) capabilities include one or more of a delay budget reporting capability, a TTI bundling capability, a RAN frame aggregation and RAN-assisted codec adaptation capability, and/or other like capabilities. Other embodiments may be described and/or claimed.
• Referring now toFIG. 1, in which an example architecture of asystem100 of a network according to various embodiments, is illustrated. The following description is provided for anexample system100 that operates in conjunction with the LTE system standards and 5G or NR system standards as provided by 3GPP technical specifications. However, the example embodiments are not limited in this regard and the described embodiments may apply 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., WMAN, WiMAX, etc.), or the like.
• As shown byFIG. 1, thesystem100 includes UE101aand UE101b(collectively referred to as “UEs101” or “UE101”). In this example, UEs101 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as consumer electronics devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants, pagers, wireless handsets, desktop computers, laptop computers, in-vehicle infotainment, in-car entertainment devices, an Instrument Cluster, head-up display (HUD) devices, onboard diagnostic devices, dashtop mobile equipment, mobile data terminals, Electronic Engine Management System, electronic/engine control units, electronic/engine control modules, embedded systems, microcontrollers, control modules, engine management systems, networked or “smart” appliances, MTC devices, M2M, IoT devices, and/or the like. As discussed in more detail infra, the UEs101 (and the RAN nodes111) incorporate the SDP-based signaling embodiments discussed herein. In these embodiments, the UEs101 are capable of, inter alia, signaling specific RAN-level capabilities using SDP toward improving e2e quality of VoLTE calls. The RAN-level capabilities may include, for example, delay budget reporting, TTI bundling, RAN frame aggregation, RAN-assisted codec adaptation, and/or the like. These and other embodiments are discussed in more detail infra.
• In some embodiments, any of the UEs101 may be IoT UEs, which may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a PLMN, ProSe or D2D communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.
• The UEs101 may be configured to connect, for example, communicatively couple, with an or RAN110. In embodiments, the RAN110 may be an NG RAN or a 5G RAN, an E-UTRAN, or a legacy RAN, such as a UTRAN or GERAN. The term “NG RAN” or the like refers to a RAN110 that operates in an NR or5G system100, and the term “E-UTRAN” or the like refers to a RAN110 that operates in an LTE or4G system100. The UEs101 utilize connections (or channels)103 and104, respectively, each of which comprises a physical communications interface or layer.
• In this example, theconnections103 and104 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, and/or any of the other communications protocols discussed herein. In embodiments, the UEs101 may directly exchange communication data via aProSe interface105. The ProSeinterface105 may alternatively be referred to as aSL interface105 and may comprise one or more logical channels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.
• The UE101bis shown to be configured to access an AP106 (also referred to as “WLAN node106,” “WLAN 106,” “WLAN Termination106,” “WT106” or the like) viaconnection107. Theconnection107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP106 would comprise a WiFi® router. In this example, the AP106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below). In various embodiments, the UE101b, RAN110, and AP106 may be configured to utilize LWA operation and/or LWIP operation. The LWA operation may involve the UE101bin RRC_CONNECTED being configured by a RAN node111a-bto utilize radio resources of LTE and WLAN. LWIP operation may involve the UE101busing WLAN radio resources (e.g., connection107) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) sent over theconnection107. IPsec tunneling may include encapsulating the entirety of original IP packets and adding a new packet header, thereby protecting the original header of the IP packets.
• TheRAN110 can include one or more AN nodes orRAN nodes111aand111b(collectively referred to as “RAN nodes111” or “RAN node111”) that enable theconnections103 and104. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The term “NG RAN node” or the like refers to a RAN node111 that operates in an NR or 5G system100 (for example, a gNB), and the term “E-UTRAN node” or the like refers to a RAN node111 that operates in an LTE or 4G system100 (e.g., an eNB). According to various embodiments, the RAN nodes111 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and/or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
• In some embodiments, all or parts of the RAN nodes111 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and/or a vBBUP. In these embodiments, the CRAN or vBBUP may implement a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN/vBBUP and other L2 protocol entities are operated by individual RAN nodes111; a MAC/PHY split wherein RRC, PDCP, RLC, and MAC layers are operated by the CRAN/vBBUP and the PHY layer is operated by individual RAN nodes111; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN/vBBUP and lower portions of the PHY layer are operated by individual RAN nodes111. This virtualized framework allows the freed-up processor cores of the RAN nodes111 to perform other virtualized applications. In some implementations, an individual RAN node111 may represent individual gNB-DUs that are connected to a gNB-CU via individual F1 interfaces (not shown byFIG. 1). In these implementations, the gNB-DUs may include one or more remote radio heads or RFEMs (see, e.g.,FIG. 6), and the gNB-CU may be operated by a server that is located in the RAN110 (not shown) or by a server pool in a similar manner as the CRAN/vBBUP. Additionally or alternatively, one or more of the RAN nodes111 may be next generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs101, and are connected to a5GC120 via an NG interface.
• In V2X scenarios one or more of the RAN nodes111 may be or act as RSUs. The term “Road Side Unit” or “RSU” refers to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE. In one example, an RSU is a computing device coupled with RF circuitry located on a roadside that provides connectivity support to passing vehicle UEs101 (vUEs101). The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Short Range Communications (DSRC) band to provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications, as well as other cellular communications services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and/or provide connectivity to one or more cellular networks to provide uplink and downlink communications. The computing device(s) and some or all of the radiofrequency circuitry of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and/or a backhaul network.
• Any of the RAN nodes111 can terminate the air interface protocol and can be the first point of contact for the UEs101. In some embodiments, any of the RAN nodes111 can fulfill various logical functions for theRAN110 including, but not limited to, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In embodiments, the UEs101 can be configured to communicate using OFDM communication signals with each other or with any of the RAN nodes111 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a SC-FDMA communication technique (e.g., for uplink and ProSe or SL communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.
• In embodiments, the UEs101 implement or operate a client for MTSI supporting conversational speech (including DTMF), video, and text transported over RTP with the scope to deliver a user experience equivalent to or better than that of Circuit Switched (CS) conversational services using the same amount of network resources. MTSI defines media handling (e.g., signaling, transport, jitter buffer management, packet-loss handling, adaptation, etc.), as well as interactivity (e.g., adding or dropping media during a call). In these embodiments, the UEs101 may connect to the IMS (e.g., AS130) using 3GPP access (e.g., viaRAN110 and CN120) or using non-3GPP access (e.g., viaWLAN 106, Bluetooth, DECT/NG DECT).
• According to various embodiments, UEs101 may communicate with one another using VoLTE mechanisms. VoLTE is a standard for high-speed wireless communication, which is based on IMS networks where specific profiles for control and media planes of voice service over an LTE network may be defined. In various embodiments, SIP is used to convey information during a call setup procedure. SIP is an application-layer control protocol for creating, modifying, and terminating sessions (e.g., Internet multimedia conferences, Internet telephone calls, and multimedia distribution using an offer/answer model) that works independently of underlying transport protocols and without dependency on the type of session that is being established. SIP works in concert with various protocols for carrying various forms of real-time multimedia session data such as voice, video, and/or text messages. SIP works in concert with these protocols by enabling Internet endpoints (referred to as “user agents”) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (referred to as “proxy servers”) to which user agents can send registrations, invitations to sessions, and other requests.
• SIP messages used to create sessions may carry session descriptions that allow participants to agree on a set of compatible media types to be used during the communication session. The session descriptions may be formatted according to SDP, wherein media type and parameter negotiation and media setup is performed with SDP that is carried as payload in SIP messages. SIP employs many aspects of the HTTP request/response model, including reuse of header fields, encoding rules, and status codes of HTTP. Furthermore, a suitable transport layer protocol may be used to convey data before session establishment (e.g., audio and/or video as early media) or during an established session. The transport layer protocol may include, for example, UDP, TCP, RSTP, SCTP, RTP, SRTP, and/or the like for the transmission of media streams (e.g., voice, video). Moreover, the SIP messages may be encrypted using TLS, SRTP, and/or the like. In some embodiments, another encapsulation protocol, such as RTSP, may be used to convey SDP messages. RTSP is an application-level protocol for controlling the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters.
• SDP is used to set up a call and create a session, such as a real-time text, voice, or video call. The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP provides a means to communicate the existence of a session, and a means to convey sufficient information to enable joining and participating in the session. Media streams can be many-to-many, and sessions need not be continually active. An SDP session description includes the following: session name and purpose; time(s) the session is active; the media comprising the session; and information needed to receive those media (e.g., addresses, ports, formats, etc.). The session description may also include information about the bandwidth to be used by the session, and contact information for the person responsible for the session.
• During the creation of the session, two endpoints (e.g.,UE101aandUE101b) that are supposed to later on exchange media packets, send each other SDP offer messages and answer messages so that the two endpoints exchange respective capability information. For example, a sender (e.g.,UE101a) may want to understand what kind of decoders the receiver (e.g.,UE101b) can support, what kind of codecs the receiver can support, and so forth. The sender and the receiver need to agree on the parameters to be used during the session, such as the codecs, protocols, payload formats, and other like parameters related to the delivery of content. And on top of it our proposal here is to. According to various embodiments, various radio capabilities of the UEs101 may also be indicated during the SDP offer/answer exchanges.
• The offer/answer exchange of session descriptions assumes the existence of a higher layer protocol (e.g., SIP), which is capable of exchanging SDP for the purposes of session establishment between agents. SDP protocol operation begins when one agent (e.g.,UE101a) sends an initial offer to another agent (e.g.,UE101b). An agent is the protocol implementation involved in the offer/answer exchange, and there are at least two agents involved in an offer/answer exchange. An offer is an SDP message sent by an offerer, and an offerer is an agent that generates a session description in order to create or modify a session. An offer is an initial offer if it is outside of any context that may have already been established through the higher layer protocol. It is assumed that the higher layer protocol provides maintenance of some kind of context which allows the various SDP exchanges to be associated together.
• The agent receiving the offer may generate an answer, or the agent may reject the offer. An answer is an SDP message sent by an answerer in response to an offer, and an answerer is an agent which receives a session description from another agent describing aspects of desired media communication, and then responds to that with its own session description. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic in that if the answer is rejected, the session reverts to the state prior to the offer, which may be absence of a session. At any time, either agent may generate a new offer that updates the session. However, the agents may not generate a new offer if it has received an offer to which it has not yet answered or rejected. Furthermore, an agent may not generate a new offer if the agent has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a glare condition. The term “glare” was originally used in circuit switched telecommunications networks to describe the condition where two switches both attempt to seize the same available circuit on the same trunk at the same time. For purposes of the present disclosure, “glare” may mean that both agents have attempted to send an updated offer at the same time.
• For example, an originatingUE101amay generate and send an SIP INVITE request to be delivered to a terminatingUE101b. The INVITE request message may include an SDP offer, at least one media description, and one or more radio capabilities of theUE101a. The SDP offer may reflect the capabilities and user preferences of theUE101afor the session. In this example, after the INVITE message is conveyed to the terminatingUE101b, a response message including response code180 may be conveyed to the originatingUE101b. The response code180 may indicate that the destination user agent (e.g., terminatingUE101b) received the INVITE, and is alerting the user of the terminatingUE101bof the call/session. While the call/session is in a ringing state, early media may be conveyed between the two UEs101 using a suitable mechanism, such encoding media data in RTP packets and conveying those RTP packets according to RTP. Response messages may be sent by a user agent server indicating a result of a received request. Several classes of responses are recognized, determined by the numerical range of result codes. For example, the 200 response code may indicate a successful completion of the request and/or may indicate that a call/session has been established in response to the INVITE message. The SIP and/or SDP messages may include or indicate other information than that described previously such as, for example, user location which is a determination of the end system to be used for communication, and user availability: determination of the willingness of the called party to engage in communications.
• An SDP session description itself is entirely textual, and includes a number of lines of text in the form of <type>=<value>. In general, <value> is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. An SDP session description comprises a session level section followed by zero or more media level sections. The session level part starts with a “v=” line and continues to the first media level section. Each media-level section starts with an “m=” line and continues to the next media-level section or end of the whole session description. Generally, session level values are the default for all media unless overridden by an equivalent media-level value. Example SDP session description parameters are shown by table 1.

• TABLE 1
  SDP Session Descriptions
  Session level description

  v=(protocol version)	Specifies the version of Session Description
  	Protocol
  o=<username><sess-id>	Details about the originator and identifi-
  <sess-version><nettype>	cation of the session.
  <addrtype><unicast-address>	• <username> - user login.
  	• <sess-id> - numeric string used as
  	unique identifier for the session
  	• <sess-version> - numeric string used
  	as version number for this session
  	description
  	• <nettype> - Text string, specifying the
  	network type, e.g., IN for internet
  	• <addrtype> - Text string specifying the
  	type of the address of originator E.g.IP4
  	or IP6
  	• <unicast-address> - The address of the
  	from where the session is machine
  	originating, which can be both FQDN or
  	IP address.
  s=<session name>	Only one session name per session descrip-
  	tion can be specified. It must not be empty;
  	therefore if no name is assigned to the
  	session, a single empty space should be
  	used as session name
  i=< Session information>	Only one session-level “i” field can be
  	specified in the Session description. The
  	“i” filed can be used in session or media
  	description. It is primarily intended for
  	labeling media streams when used in
  	media description section. It can be a
  	human readable description
  u=<URI>	The URI (Uniform Resource Identifier)
  	specified in the “u” filed, is a pointer to
  	additional information about the session
  e=<email address>	Email address of person responsible for
  	conference or session
  p=<phone number>	Specifies contact information for the
  	person responsible for the conference or
  	session
  c=<connection information>;	Connection information can be included in
  c=<nettype> <addrtype>	Session description or in media description.
  <connection-address>	A session description MUST contain either
  	at least one “c=” field in each media
  	description or a single “c=” field at the
  	session level.
  	• <nettype> A text string describing the
  	network type, e.g., IN for internet.
  	• <addrype> A text string describing the
  	type of the address used in connection-
  	address; E.g., IP4 or IP6.
  	• <connection-address> A Multicast IP
  	address is specified including TTL, e.g.,
  	224.2.36.42/127
  b=<bwtype>:<bandwidth>	Bandwidth field can be used both in the
  	session description, specifying the total
  	bandwidth of the whole session and can
  	also be used in media description, per
  	media session.
  	• <bwtype> Bandwidth type can be CT;
  	conference total upper limit of band-
  	width to be used, or AS; application
  	specific, therefore it will be the
  	application's concept of maximum
  	bandwidth.
  	• <bandwidth> is interpreted as kilobits
  	per second by default.
  z=<adjustment time> <offset>	To schedule a repeated session that
  <adjustment time> <offset>	specifies a change from daylight saving
  	time to standard time or vice versa, it is
  	necessary to specify difference from the
  	originating time
  k=<method>:<encryption key>	If channel is secure and trusted, SDP can
  	be used to convey encryption keys. A key
  	can be specified for the whole session or
  	for each media description.
  a=<attribute>:<value>	Zero or more session attribute lines.
  may	Attributes be defined at “session-level” or
  	at “media-level” or both. Session level
  	attributes are used to advertise additional
  	information that applies to conference as a
  	whole. Media level attributes are specific
  	to the media, i.e. advertising information
  	about the media stream

  Time description

  t=<start-time>:<value>	Specifies the start and stop times for a
  	session. If a session is active at irregular
  	intervals, multiple time entries can be used
  r=<repeat interval>	Zero or more repeat times; If a session is
  <active duration>	to be repeated at fixed intervals, the “r”
  <offsets from start-time>	field is used. By default all values should
  	be specified in seconds, but to make
  	description more compact, time can also
  	be given in different units, such as days,
  	hours or minutes; e.g., r=6d 2h 14m

  Media description

  m=<media> <port>/	Media name and transport address. This
  <number of ports>	field is used in the media description
  <proto> <fmt>	section to advertise properties of the media
  	stream, such as the port it will be using for
  	transmitting, the protocol used for
  	streaming and the format or codec.
  	• <media> Used to specify media type,
  	generally this can be audio, video, text
  	etc.
  	• <port> The port to which the media
  	stream will be sent. Multiple ports can
  	also be specified if more than 1 port is
  	being used.
  	• <proto> The transport protocol used
  	for streaming, e.g., RTP (real time
  	protocol).
  	• <fmt> The format of the media being
  	sent, e.g., in which codec is the media
  	encoded; e.g., PCMU, GSM etc.
  i=<media title>	media title or information field
  c=<connection information)>	connection information - optional if
  	included at session level
  b=<bwtype>:<bandwidth>	bandwidth information
  k=<method>:<encryption key>	encryption key
  a=<attribute>:<value>	zero or more media attribute lines

• Recent voice and video enhancements for LTE include several VoLTE/ViLTE enhancement features including RAN-assisted codec adaptation, VoLTE/ViLTE signaling optimization and VoLTE/ViLTE quality/coverage enhancement. In addition to RAN-assisted codec adaptation, another important feature is VoLTE quality/coverage enhancement functionality. As part of this functionality, a delay budget reporting framework has been specified so that the VoLTE coverage can be effectively enhanced by relaxing the air interface delay budget. This involves the UE101 using RRC signaling to report DBI. Based on the reported DBI, when the UE101 is in “good” coverage, the RAN node111 (e.g., an eNB or gNB) can configure longer DRX for power saving purpose. When a remote UE101 is in “bad” coverage, the RAN node111 (e.g., an eNB or gNB) can reduce DRX cycle in order to reduce e2e delay and jitter, and/or configure the remote UE101 in the “bad” coverage to increase the retransmission times in order to reduce the packet loss.
• While RAN-layer delay budget reporting allows UEs101 to locally adjust their own air interface delay, such a mechanism does not provide coordination between the UEs101 to manage delay and jitter on an e2e basis. In particular, considering the autonomous operation of the MTSI sender and MTSI receiver (as discussed in more detail with respect toFIG. 4), an MTSI receiver's decision to turn cDRX off may be dependent on the remote MTSI sender's ability to leverage the available delay budget to further improve the reliability of its transmissions. As such, it would be desirable for the UEs101 to exchange information about specific RAN capabilities that would be relevant in influencing the remote UE's101 adaptation and impact the e2e quality of the VoLTE call. Such RAN capabilities may include RAN delay budget reporting, TTI bundling, HARQ support and RAN-assisted codec adaptation or ANBR, and/or other like RAN capabilities.
• Embodiments herein provide mechanisms to enable SDP-based methods to signal specific RAN-level capabilities toward improving e2e quality of VoLTE calls. Signaled RAN-level capabilities may include Delay Budget Reporting, TTI bundling, RAN frame aggregation, RAN-assisted codec adaptation or ANBR, and the like. In various embodiments, a new SDP attribute RANCapabilities' is defined, which includes dedicated parameters that allow UEs101 to indicate support for specific RAN capabilities. The RANCapabilities may include individual parameters that correspond to support of each of RAN delay budget reporting, TTI bundling, RAN frame aggregation, RAN-assisted codec adaptation or ANBR, and/or the like. These aspects are discussed in more detail with respect toFIG. 5.
• With respect to ANBR, it has been observed that the ANBR procedures, in the absence of e2e coordination, may suffer from unfavorable consequences such as relatively high PLR and poor quality. Enabling such e2e coordination may be useful for a UE101 to learn the ANBR capabilities of its remote UE101 and may accordingly determine the most suitable media adaptation on its end, for example, in response to ANBR information received from its local RAN node111 (e.g., an eNB and/or gNB). Moreover, as also observed in 3GPP TR 26.919, such signaling can allow the PCF/PCRF when setting GBR<MBR bearers. Furthermore, from a conformance point of view, the LTE_VoLTE_ViLTE_enh test case included in 3GPP TS 36.523-1 assumes that if a UE101 is capable of receiving ANBR information then it is also capable of using this ANBR information as an adaptation trigger. Such a conformance point is currently not supported by the existing media handling requirements on ANBR in 3GPP TS 26.114, where ANBR is an optional/recommended feature, for example, the UE101 is free to ignore ANBR information as an adaptation trigger. The present disclosure introduces SDP-based indications of ANBR-capabilities. In embodiments, if a UE101 signals the ANBR SDP capability, then the UE101 is capable of receiving ANBR information from its access network and its MTSI client is capable of ANBR as defined in clause 10.7 of 3GPP TS 26.144 v16.0.0 (2018 December).
• RAN-assisted codec adaptation or ANBR functionality, as defined in 3GPP TS 26.114, 3GPP TS 36.321, and 3GPP TS 38.321 provides a means for the RAN node111 (e.g., an eNB or gNB) to send a codec adaptation indication with recommended bit rate to assist the UE101 to select or adapt to a codec rate for voice or video. The RAN-assisted codec adaptation mechanism supports the uplink/downlink bit rate increase or decrease. For a bearer associated with configuration of MBR greater than GBR, the recommended uplink/downlink bit rate is within boundaries set by the MBR and GBR of the concerned bearer. For uplink or downlink bit rate adaptation, the RAN node111 may send a recommended bit rate to the UE101 to inform the UE101 on the currently recommended transport bit rate on the local uplink or downlink, which the UE101 may use in combination with other information to adapt the bit rate. For example, theUE101amay send a bit rate request to thepeer UE101bvia application layer messages as specified in 3GPP TS 26.114, which thepeer UE101bmay use in combination with other information to adapt the codec bit rate. The recommended bit rate is in kbps at the physical layer at the time when the decision is made. The recommended bit rate for UL and DL is conveyed as a MAC CE from the RAN node111 to the UE101. Based on the recommended bit rate from the RAN node111, a UE101 may initiate an e2e bit rate adaptation with its peer (e.g., another UE101 or MGW). The UE101 may also send a query message to its local RAN node111 to check if a bit rate recommended by its peer can be provided by the RAN node111. The UE101 is not expected to go beyond the recommended bit rate from the RAN node111.
• According to various embodiments, a session description may include a media-level SDP attribute to indicate support for ANBR. For example, the media-level SDP attribute may be “anbr.” Use of ANBR with dynamic bitrate adaptation is described in 3GPP TS 26.144 v16.0.0 (2018 December) clause 10.7.3, and related adaptation of sent and received media is described in 3GPP TS 26.144 v16.0.0 (2018 December) clauses 10.7.3.2 and 10.7.3.3, respectively. At the radio signaling level, ANBR signaling capability, also known as RAN-assisted codec adaptation as specified in 3GPP TS 36.321 for LTE access and 3GPP TS 38.321 for NR access. The embodiments discussed herein allow for little or no e2e coordination between the UEs101 on their ANBR-triggered adaptation capabilities.
• If an MTSI client in terminal signals the ANBR attribute in the SDP, then the MTSI client in terminal supports ANBR as described in 3GPP TS 26.144 v16.0.0 (2018 December) clause 10.7, including the use of ANBR with dynamic bitrate adaptation as described in 3GPP TS 26.144 v16.0.0 (2018 December) clause 10.7.3. An MTSI client in terminal is an MTSI client that is implemented in a terminal or UE101, and an MTSI client is a function in a terminal (or UE101) or in a network entity (e.g., a MRFP) that supports MTSI. An MTSI client capable of supporting multiple streams may be referred to as an “MSMTSI client.” If the MTSI client in terminal signals the ANBR attribute in the SDP, then its UE101 is capable of RAN-assisted codec adaptation specified in 3GPP TS 36.321 for LTE access and/or 3GPP TS 38.321 for NR access. For LTE access, inclusion of “anbr” in the SDP indicates whether the UE101 is able to query and receive ANBR information (for both downlink and uplink ANBR) from its eNB. Likewise, for NR access inclusion of this attribute indicates whether the UE101 is able to query and receive ANBR information. In various embodiments, the “a=anbr” attribute may only be used on media level.
• Informing the remote MTSI client via the SDP about the ANBR support using the “anbr” attribute helps the remote MTSI client to determine the most suitable media adaptation on its end, this is especially valid if the remote MTSI client itself is also capable of performing ANBR-triggered adaptation, e.g., in response to ANBR information received from its local RAN node111 (e.g., an eNB or gNB). As an example, for ANBR-triggered rate up-switching, an MTSI client may adapt its sent bitrate and also perform CMR/RTCP-APP/TMMBR/TMMBN signaling more responsively based on the ANBR information it receives from its local RAN node111, if it knows that the remote MTSI client also supports ANBR. In the absence of the knowledge of the ANBR capabilities of the remote UE101, an MTSI client may not have dynamic knowledge on the feasibility of the new bitrate based on ANBR over the access network of the remote UE101, and this may not be desirable especially in a rate up-switching scenario. Furthermore, signaling of ANBR capabilities in the SDP via “a=anbr” can also be useful for the PCF/PCRF when setting GBR<MBR bearers. An example use of the “a=anbr” attribute relative to a media line is as follows: a=anbr. The IANA registration information for the “a=anbr” SDP attribute is provided in table 2.

• TABLE 2
  Contact name, email address, and telephone number:
  3GPP Specifications Manager
  3gppContact@etsi.org
  +33 (0)492944200
  Attribute Name (as it will appear in SDP)
  anbr
  Long-form Attribute Name in English:
  3GPP access network bitrate recommendation (ANBR) support attribute
  Type of Attribute
  Media level
  Is Attribute Value subject to the Charset Attribute?
  This Attribute is not dependent on charset.
  Purpose of the attribute:
  This attribute is used to indicate the UE's ability to use ANBR as an
  adaptation trigger and also its ability to receive ANBR information from
  the access network.
  Appropriate Attribute Values for this Attribute:
  No values. See clause 6.2.X for detailed usage.

• Referring back toFIG. 1, the RAN nodes111 are configured to communicate with one another viainterface112. In embodiments where thesystem100 is an LTE system (e.g., whenCN120 is an EPC120), theinterface112 may be anX2 interface112. The X2 interface may be defined between two or more RAN nodes111 (e.g., two or more eNBs and the like) that connect toEPC120, and/or between two eNBs connecting toEPC120. In some implementations, the X2 interface may include an X2-U and an X2-C. The X2-U may provide flow control mechanisms for user data packets transferred over the X2 interface, and may be used to communicate information about the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information for user data transferred from a master eNB (MeNB) to an secondary eNB (SeNB); information about successful in sequence delivery of PDCP PDUs to a UE101 from an SeNB for user data; information of PDCP PDUs that were not delivered to a UE101; information about a current minimum desired buffer size at the SeNB for transmitting to the UE user data; and the like. The X2-C may provide intra-LTE access mobility functionality, including context transfers from source to target eNBs, user plane transport control, etc.; load management functionality; as well as inter-cell interference coordination functionality.
• In embodiments where thesystem100 is a 5G or NR system (e.g., whenCN120 is an 5GC120), theinterface112 may be anXn interface112. The Xn interface is defined between two or more RAN nodes111 (e.g., two or more gNBs and the like) that connect to5GC120, between a RAN node111 (e.g., a gNB) connecting to5GC120 and an eNB, and/or between two eNBs connecting to5GC120. In some implementations, the Xn interface may include an Xn-U interface and an Xn-C interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. The Xn-C may provide management and error handling functionality, functionality to manage the Xn-C interface; mobility support for UE101 in a CM-CONNECTED mode including functionality to manage the UE mobility for connected mode between one or more RAN nodes111. The mobility support may include context transfer from an old (source) serving RAN node111 to new (target) serving RAN node111; and control of user plane tunnels between old (source) serving RAN node111 to new (target) serving RAN node111. A protocol stack of the Xn-U may include a transport network layer built on IP transport layer, and a GTP—U layer on top of a UDP and/or IP layer(s) to carry user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as XnAP) and a transport network layer that is built on SCTP. The SCTP may be on top of an IP layer, and may provide the guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver the signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be same or similar to the user plane and/or control plane protocol stack(s) shown and described herein.
• TheRAN110 is shown to be communicatively coupled to a core network—in this embodiment,CN120. TheCN120 may comprise one ormore network elements122, which are configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UEs101) who are connected to theCN120 via theRAN110. TheCN120 includes one ormore servers122, which may implement various core network elements or AFs such as those discussed herein. The components of theCN120 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be utilized to virtualize any or all network node functions via executable instructions stored in one or more computer-readable storage mediums (described in further detail below). A logical instantiation of theCN120 may be referred to as a network slice, and a logical instantiation of a portion of theCN120 may be referred to as a network sub-slice. NFV architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more EPC components/functions.
• In some embodiments, theCN120 may be an EPC (referred to as “EPC120”). In these embodiments, the one ormore network elements122 may include or operate one or more an MMEs, SGSNs, S-GWs, P-GWs, HSSs, PCRFs, and/or other like LTE core network elements. Additionally, the RAN110 (referred to as “E-UTRAN110” or the like) may be connected with theEPC120 via anS1 interface113. In embodiments, theS1 interface113 may be split into two parts, an S1-U interface114, which carries traffic data between the RAN nodes111 and the S-GW, and the S1-MME interface115, which is a signaling interface between the RAN nodes111 and MMEs. Additionally, the P-GW within theEPC120 may route data packets between theEPC120 and external networks such as a network including aPDN130 via anIP interface125. ThePDN130 may be an operator external public, a private PDN (e.g., enterprise network, etc.), or an intra-operator PDN (e.g., for provision of IMS and/or IP-CAN services).
• In some embodiments, theCN120 may be a 5GC (referred to as “5GC120”). In these embodiments, thenetwork elements122 may implement, inter alia, an AUSF, AMF, SMF, NEF, PCF, NRF, UDM, AF, UPF, SMSF, N3IWF, NSSF and/or other like NR NFs. Additionally, the RAN110 (referred to as “5G-RAN110,” “NG-RAN110,” or the like) may be connected with the5GC120 via anNG interface113. In these embodiments, theNG interface113 may be split into two parts, an NG-U interface114, which carries traffic data between the RAN nodes111 and a UPF, and the NG-C interface115, which is a signaling interface between the RAN nodes111 and AMFs. Additionally, the UPF within the5GC120 may perform packet routing, filtering, inspection, forwarding, etc., between the5GC120 and external networks such as aDN130 via anIP interface125. TheDN130 may represent one or more data networks, including one or more LADNs, and may be an operator external public, a private PDN (e.g., enterprise network, etc.), or an intra-operator PDN, for example, for provision of IMS and/or IP-CAN services.
• TheCN120 is shown to be communicatively coupled to PDN/DN130 via anIP communications interface125. The PDN/DN130 may include one or more application servers, for example, theAS250aand250bdepicted byFIG. 2. The application server(s) comprise one or more physical and/or virtualized systems for providing functionality (or services) to one or more clients (e.g., UEs101) over a network. The server(s) within PDN/DN130 and/or the server(s)122 may include various computer devices with rack computing architecture component(s), tower computing architecture component(s), blade computing architecture component(s), and/or the like. The server(s) may represent a cluster of servers, a server farm, a cloud computing service, or other grouping or pool of servers, which may be located in one or more datacenters. The server(s) may also be connected to, or otherwise associated with one or more data storage devices (not shown). Moreover, the server(s) may include an operating system (OS) that provides executable program instructions for the general administration and operation of the individual server computer devices, and may include a computer-readable medium storing instructions that, when executed by a processor of the servers, may allow the servers to perform their intended functions. Suitable implementations for the OS and general functionality of servers are known or commercially available, and are readily implemented by persons having ordinary skill in the art. Generally, the server(s) offer applications or services that use IP/network resources. As examples, the server(s) may provide traffic management services, cloud analytics, content streaming services, immersive gaming experiences, social networking and/or microblogging services, and/or other like services. In addition, the various services provided by the server(s)130 may include initiating and controlling software and/or firmware updates for applications or individual components implemented by the UEs101. The server(s) can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs101 via theCN120.
• FIG. 2 illustrates an example Multimedia Telephony Service for IMS (MTSI)architecture200 according to various embodiments. MTSI (also referred to as “Multimedia Telephony”) is an IMS telephony service that builds on IMS capabilities to establish multimedia communications between terminals (e.g.,UEs101a,101b) within and in-between operator networks (operator networks202a,202b). The terminals connect to the IMS using either a fixed access network or a 3GPP access network.
• TheMTSI architecture200 includes two operator networks, including anoperator A network202aand anoperator B network202b. In this example,operator A network202aservesUE101aandoperator B network202bservesUE101b. TheUEs101a,101bmay include MTSI clients and/or MSMTSI clients. An MTSI client in terminal is an MTSI client that is implemented in a terminal or UE101. The term “MTSI client in terminal” is used in the present disclosure when entities such as MRFP, MRFC or media gateways are excluded. An MSMTSI client is a multi-stream capable MTSI client supporting multiple streams. An MTSI client may support multiple streams, even of the same media type, without being an MSMTSI client. Such an MTSI client may, for example, add a second video to an ongoing video telephony session.
• Each of theoperator networks202aand202binclude RAN210 (includingRAN210ain theoperator A network202aandRAN210bin theoperator B network202b) and a PS domain220 (includingPS domain220ain theoperator A network202aandPS domain220bin theoperator B network202b), which may be the same or similar to theRAN110 andCN120 ofFIG. 1, respectively. Each of the operator networks include various CSCF mechanisms to route control-plane signaling between theUEs101aand101binvolved in a call, including a P-CSCF230 (including P-CSCF230ain theoperator A network202aand P-CSCF230bin theoperator B network202b) and a S-CSCF240 (including S-CSCF240ain the operator A domain and S-CSCF240bin the operator B domain).Operator B network202bincludes an I-CSCF245b, however, in other embodiments theoperator A network202amay also include an I-CSCF. In some embodiments, the operator networks202 may include other elements that are not shown byFIG. 2, such as an MFRP, MRFC, MGW, and/or the like.
• The P-CSCF230 is the first contact point for theUE101a,101bwithin the IMS. An address of the P-CSCF230 is discovered by UEs using the mechanism described in the clause “Procedures related to Local CSCF Discovery”. The P-CSCF230 behaves like a proxy (also referred to as “SIP proxy servers” or the like) in that the P-CSCF230 accepts requests and services the requests internally or forwards them to an appropriate entity. In particular, the P-CSCF230 forwards SIP register requests received from the UE101 to an entry point determined using the home domain name, as provided by the UE101, forwards SIP messages received from the UE101 to an SIP server (e.g., the S-CSCF240) whose name the P-CSCF230 has received as a result of the registration procedure, and forwards the SIP request or response to the UE101. The P-CSCF230 may behave as a UA wherein the P-CSCF230 may terminate and independently generate SIP transactions in abnormal conditions. The P-CSCF230 also performs SIP message compression/decompression.
• The S-CSCF240 handles session states in the network. For registration, the S-CSCF240 may behave as a registrar (also referred to as an “SIP registration server” or the like) in that the S-CSCF240 accepts registration requests and makes its information available through a location server (e.g., HSS224). The S-CSCF240 also notifies subscribers about registration changes including the GRUU sets assigned to registered instances. During registration process, the S-CSCF240 provides policy information, if available, for a Public User Identity from the HSS224 to the P-CSCF230 and/or UE101. For example, the policy information includes MPS IMS Subscription status and policy applicable to enterprise network subscribers. For session-related and session-unrelated flows, the S-CSCF240 provides session control for the registered endpoint's (e.g., UEs101) sessions, and rejects IMS communication to/from Public User Identity(s) that are barred for IMS communications after completion of registration. The S-CSCF240 may behave as a proxy server in that the S-CSCF240 accepts requests and services them internally or forwards them on, possibly after translation. The S-CSCF240 may behave as a UA in that the S-CSCF240 may terminate and independently generate SIP transactions. Based on the determined served user, the S-CSCF240 handles interactions with the services platforms for the support of services. The S-CSCF240 provides endpoints with service event related information (e.g., notification of tones/announcement together with location of additional media resources, billing notification).
• The I-CSCF245bis the contact point within an operator's network (e.g., theoperator B network202b) for all IMS connections destined to a subscriber of that network operator (e.g., theUE101b), or a roaming subscriber currently located within that network operator's service area. The I-CSCF245balso generates CDRs for charging and resource utilization.
• Each operator network in theIMS architecture200 also include an AS250 (including AS250ain theoperator A network202aand AS250bin theoperator B network202b). The AS250 may influence and impact the SIP session on behalf of the services supported by the operator's network. An AS250 may host and execute services. The AS250 may resides either in the user's home network or in a third party location. The third party could be a network or simply a stand-alone AS. In the control plane, AS250 provides supplementary services such as call hold/resume, call forwarding, multi-party calls, and/or the like. The AS250 may be an SIP AS, OSA AS, or CAMEL IM-SSF. The OSA AS does not directly interact with the IMS network entities but through the OSA SCS-s. The SIP Application Server supports IMS reference points (e.g., ISC, Sh, Ut (not shown byFIG. 2)), in support of an application, is considered as part of the IM CN subsystem. Examples of such ASs are SCC AS and TAS. The AS (SIP AS, OSA SCS, and/or IM-SSF) can communicate with the HSS224 over the Sh and Si interfaces (not shown byFIG. 2). An S-CSCF to AS interface is used to provide services residing in an AS, and an I-CSCF to AS interface is used to forward SIP requests destined to a Public Service Identity hosted by the AS directly to that AS.
• The HSS/SLF224bis a master database wherein the HSS portion of the HSS/SLF224 (hereinafter referred to as “HSS224”) includes (or stores) subscription-related information to support the network entities actually handling calls/sessions, and the SLF portion of the HSS/SLF224 (hereinafter referred to as “SLF224”) includes (or stores) information used to locate the subscription-related information. AlthoughFIG. 2 only depicts HSS/SLF224blocated in theoperator B network202b, in other embodiments, theoperator A network202amay also include an HSS/SLF224. In some embodiments, the SLF is not required such as in a single HSS environment (e.g., a server farm architecture) or when an AS250 are configured/managed to use pre-defined HSS224. A home network may contain one or several HSSs224 depending on the number of mobile subscribers, the capacity of the equipment, and on the organization of the network. As an example, the HSS224 provides support to the call control servers in order to complete the routing/roaming procedures by solving authentication, authorization, naming/addressing resolution, location dependencies, etc.
• The HSS224 is responsible for holding (or storing) the following user related information: user identification, numbering, and addressing information; user security information including network access control information for authentication and authorization; user location information at inter-system level wherein the HSS224 supports the user registration and stores inter-system location information, etc.; and user profile information. The HSS224 also generates user security information for mutual authentication, communication integrity check and ciphering. Based on this information, the HSS224 also supports the call control and session management entities of the different domains and subsystems of the operator network. The HSS224 may integrate heterogeneous information, and enable enhanced features in the core network to be offered to the application & services domain, at the same time hiding the heterogeneity. Furthermore, the HSS224 includes IP multimedia functionality, which provides support to control functions of the IM subsystem such as the CSCF230,240,245. The IP multimedia functionality enables subscriber usage of the IM CN subsystem services and is independent of the access network used to access the IM CN subsystem.
• The SLF224 is queried by the I-CSCF245bvia a Dx interface (not shown byFIG. 2) during the registration and session setup to get the name of the HSS224 containing the required subscriber specific data. Furthermore the SLF224 is also queried by the S-CSCF240 via the Dx interface (not shown byFIG. 2) during registration. The SLF224 is queried by the AS250 via the Dh interface (not shown byFIG. 2) in conjunction with the Sh interface (not shown byFIG. 2) operation to get the name of the HSS224 containing the required subscriber specific data. The SLF224 is queried by an 3GPP AAA server (not shown byFIG. 2) via the Dw interface (not shown byFIG. 2) to get the name of the HSS224 containing the required subscriber specific data.
• As mentioned previously, the UEs101 may use SIP, SDP, and SDPCapNeg for media negotiation and configuration. General SIP signaling (see e.g., 3GPP TS 24.229) is used to convey SDP offer and answer messages. The SIP messages include SDP offer and answer messages in the message body portion of the SIP messages. In some implementations, the MTSI client in terminal may use the OMA-DM solutions for enhancing SDP negotiation and resource reservation process.
• The session setup for RTP transported media may determine, for each media, IP address(es), RTP profile, UDP port number(s); codec(s); RTP Payload Type number(s), RTP Payload Format(s), the maximum bandwidth that is allowed in the session, and/or the like. The session setup may also determine ECN usage and any additional session parameters. The session setup for UDP transported media without RTP may determine IP address(es), UDP port number(s) and additional session parameters.
• An MTSI client (e.g., a UE101) offers at least one RTP profile for each RTP media stream. Multiple RTP profiles may be offered using SDPCapNeg. For voice and real-time text, the first SDP offer may include at least the AVP profile. For video, the first SDP offer for a media type may include at least the AVPF profile. Subsequent SDP offers may include only other RTP profiles if it is known from a preceding offer that this RTP profile is supported by the answerer. The MTSI client may be capable of receiving an SDP offer containing both AVP and AVPF offers in order to support interworking. The configuration of ECN for media transported with RTP for speech and for video.
• SDPCapNeg is used to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg may support the complete SDPCapNeg framework. SDPCapNeg attributes that are directly applicable for the RTP profile negotiation include, inter alia, tcap, pcfg and acfg attributes. For voice and real-time text, SDPCapNeg may be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client may either offer AVPF and AVP together using SDPCapNeg, or the MTSI client may offer only AVPF without using SDPCapNeg. When offering AVP and AVPF using SDPCapNeg, the MTSI client may offer AVP on the media (m=) line and may offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows: The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF may be preferred over AVP. At least one configuration using AVPF may be listed using the attribute for potential configurations ‘pcfg’.
• An invited MTSI client should accept using AVPF whenever supported. If AVPF is to be used in the session then the MTSI client selects one configuration out of the potential configurations defined in the SDP offer for using AVPF; indicates in the media (m=) line of the SDP answer that the profile to use is AVPF; and indicates the selected configuration for using AVPF in the attribute for actual configurations ‘acfg’. If AVP is to be used then the MTSI may not indicate any SDPCapNeg attributes for using AVPF in the SDP answer.
• The SDP may include bandwidth information for each media stream and also for the session in total. The bandwidth information for each media stream and for the session is defined by the application specific bandwidth modifier as defined in RFC 4566. An MTSI client in terminal may include the ‘a=bw-info’ attribute in the SDP offer. When accepting a media type where the ‘a=bw-info’ attribute is included the MTSI client in terminal may include the ‘a=bw-info’ attribute in the SDP answer if it supports the attribute. When the ‘a=bw-info’ attribute is supported, the following bandwidth properties may be included for each RTP payload type in the SDP: Maximum Supported Bandwidth for sending direction; Maximum Desired Bandwidth for sending direction; Minimum Desired Bandwidth for sending direction; Minimum Supported Bandwidth for sending direction; Maximum Supported Bandwidth for receiving direction (with some exceptions); Maximum Desired Bandwidth for receiving direction; Minimum Desired Bandwidth for receiving direction; and Minimum Supported Bandwidth for receiving direction.
• When an MTSI client in terminal receives an SDP offer or answer it may determine the maximum sending rate for the selected codec by selecting the smallest of the following: the bandwidth value, if the b=AS parameter was included in the received SDP offer or answer; the Maximum Supported Bandwidth for the receiving direction, if included in the received SDP; the preconfigured data rate for the selected codec, if the MTSI client has been preconfigured by the operator to use a particular data rate for the selected codec; the maximum data rate for the selected codec as determined by examining the codec information (e.g., codec, mode, profile, level) and any other media information (e.g., ptime and maxptime) included in the received SDP offer or answer. The maximum data rate is determined assuming no extra bandwidth is allowed for redundancy. The maximum sending rate may be further updated by the MTSI client in terminal based on receiving an indication of the granted QoS.
• The MTSI client in terminal may not transmit at a rate above the maximum sending rate. For speech, the MTSI client should transmit using the codec mode with the highest data rate allowed by the maximum sending rate, except if limited to a lower codec mode by the initial codec mode procedures or by adaptation procedures. With respect to ANBR, the SDP offer/answer re-negotiation may not be used as a replacement for dynamic media bitrate adaptation. ANBR contains information on short-term bandwidth and SDP offer/answer re-negotiations should be avoided or minimized since they consume network resources. Therefore, SDP offer/answer re-negotiation (e.g., in SIP UPDATE) may not be initiated based on ANBR information other than in the following cases: the received ANBR from the access network is below the established GBR; the received ANBR cannot be supported by any of the negotiated codec configurations; potentially increased loss and/or delay due to not lowering the bitrate are not acceptable; the MTSI client in terminal supports one or more codec configurations that supports the received ANBR; and ANBR messages with values meeting all the aforementioned conditions are received consistently for an extensive period of time (e.g., 5 seconds or more). Then the MTSI client in terminal may re-negotiate the session to switch to a codec or codec configuration that can support the lower bitrate in the ANBR (if any); and/or to reduce the number of used RTP streams (e.g., turning off the affected media); and if the session re-negotiation fails, may not initiate further re-negotiation based on ANBR for that bearer in the session. For video, if TMMBR/TMMBN are not supported in the session; and for an extensive period of time (e.g., 5 seconds), the MTSI client in terminal consistently receives ANBR messages with values significantly below the video bitrate sent (as estimated by the receiving MTSI client in terminal) from the remote peer. Then the MTSI client in terminal may re-negotiate the session to set the session bitrate for video to a value corresponding to the minimum of the received ANBR and GBR (if >0); or to turn the video off.
• The UEs101 may also support adaptive mechanisms, which are used to optimize the session quality given the current transport characteristics. The mechanisms provided in MTSI are bit-rate, packet-rate and error resilience adaptation. These mechanisms can be used in different ways; however, they should only be used when the result of the adaptation is assumed to increase the session quality even if e.g., the source bit-rate is reduced. Adaptive mechanisms that act upon measured or signaled changes in the transport channel characteristics may be used in a conservative manner. Examples of measured changes in transport characteristics are variations in PLR and delay jitter. Examples of signaled changes in transport characteristics are ANBR and ECN Congestion Experienced (ECN-CE) marking in IP packet headers. A conservative use of adaptation is characterized by a fast response to degrading conditions, and a slower, careful upwards adaptation intended to return the session media settings to the original default state of the session. The long-term goal of any adaptive mechanism is assumed to be a restoration of the session quality to the originally negotiated quality. The short-term goal is to maximize the session quality given the current transport characteristics, even if that means that the adapted state of the session will give a lower session quality compared to the session default state if transported on an undisturbed channel.
• Some access networks may provide the MTSI client in terminal with ANBR messages, separately per local access bearer and separately for the local uplink and downlink. An ANBR message is sent to the MTSI client in terminal whenever the access network finds it reasonable to inform about a change in the recommended bitrate, such that the MTSI client in terminal is generally provided with up-to-date recommended bitrate information. In general, a single access bearer can carry multiple RTP streams, in which case ANBR applies to the sum of the individual RTP stream bitrates on that bearer. Access networks supporting ANBR may also support a corresponding ANBRQ message, which allows the MTSI client in terminal to query the network for updated ANBR information. ANBRQ may only be used to query for an ANBR update when media bitrate is to be increased, not for media bitrate decrease.
• The ANBR and ANBRQ messages are conceptual messages that allows generalization of the description between different accesses, for example, LTE, NR, and wireless LAN. Where ANBR/ANBRQ signaling is to be used, a mapping between the conceptual ANBR/ANBRQ and the actual messages for each access may be defined. The format of such access-specific ANBR/ANBRQ messages may differ between different types of access networks, and there may not even exist a one-to-one mapping of messages. The bitrate value in ANBR/ANBRQ may include IP and higher layer overhead, including bitrate used for RTCP signaling, as opposed to for example, b=AS line in SDP, which does not include RTCP. Other definitions can be used by the individual access network mappings, for example, including overhead below IP layer that is added by the access network, and the UE101 may then perform appropriate value translation, for example, adjusting for use of ROHC and removing the lower layer overhead.
• When using LTE access, ANBR is mapped to a MAC level message named “Recommended bit rate MAC Control Element” sent by the RAN node111 (e.g., an eNB) and applicable to a specific dedicated bearer. Similarly, when using LTE access, ANBRQ is mapped to a MAC level message named “Recommended bit rate query MAC Control Element” sent to the the RAN node111 (e.g., an eNB) and applicable to a specific, existing dedicated bearer. An MTSI client in terminal using LTE access may support ANBR and ANBRQ signaling. When using NR access, ANBR is mapped to a MAC level message named “Recommended bit rate MAC Control Element” sent by the RAN node111 (e.g., an gNB) and applicable to a specific logical channel which is mapped to the single media flow (e.g., audio or video) to which the recommended bit rate applies. Similarly, when using NR access, ANBRQ is mapped to a MAC level message named “Recommended bit rate query MAC Control Element” sent to the RAN node111 (e.g., an gNB) and applicable to a specific, existing logical channel which is mapped to the single media flow to which the recommended bit rate applies. An MTSI client in terminal using NR access may support ANBR and ANBRQ signaling.
• An MTSI client in terminal may use the ANBR message as an adaptation trigger, taking other available triggers into account. This may apply for both speech and video, adapting to the lowest bitrate resulting from any of the possibly multiple, available triggers. An adaptation trigger is used to indicate a currently allowed bitrate. The currently allowed bitrate is the minimum of the bitrate negotiated in SDP offer/answer and the bitrate allowed after the latest preceeding adaptation (e.g., a last previous TMMBR message) that increased or decreased the allowed bitrate for the encoder. When no bitrate reduction trigger is received, the value from SDP offer/answer is used. Therefore, the currently allowed bitrate may vary over time. Multiple adaptation trigger algorithms can be used in parallel, for example ECN-triggered adaptation, adaptation based on ANBR, and PLR-triggered adaptation. When multiple adaptation algorithms are used for the rate adaptation, the rate that the MTSI client is allowed to use should be no higher than any of the rates determined by each adaptation algorithm. A received ANBR message for a certain access bearer and media direction may be considered valid for use as input to adaptation trigger evaluation until either another ANBR message is received for the same access bearer and media direction, until that access bearer is closed, or until the SIP session is either re-negotiated or closed. No signaling is currently present to provide e2e coordination between the UEs101 in regards to ANBR support. These ANBR procedures, in the absence of e2e coordination, may suffer from unfavorable consequences such as high PLR and poor quality.
• The UEs101 may also support RAN delay budget reporting through the use of RRC signaling to a RAN node111 (e.g., an eNB or gNB) allows UEs101 to locally adjust air interface delay. Based on the reported delay budget information, a good coverage UE101 on the receiving end (e.g., the UE101 that contains the MTSI receiver) can reduce its air interface delay, for example, by turning off CDRX or via other means. This additional delay budget can then be made available for the sending UE101 (e.g., the UE101 that contains the MTSI sender), and can be quite beneficial for the sending UE101 when it suffers from poor coverage. When the sending UE101 is in bad coverage, that UE101 may request the additional delay from its local RAN node111 (e.g., an eNB or gNB), and if granted, that UE101 would utilize the additional delay budget to improve the reliability of its uplink transmissions in order to reduce packet loss, for example, via suitable repetition or retransmission mechanisms, and thereby improve end-to-end delay and quality performance.
• While RAN-layer delay budget reporting allows UEs101 to locally adjust air interface delay, such a mechanism does not provide coordination between the UEs101 to manage delay and jitter on an e2e basis. In particular, these approaches do not allow UEs101 to coordinate the delay adjustments on an e2e basis. To alleviate this issue, embodiments herein define SDP and/or RTCP signaling to realize the following capabilities on signaling of DBI across UEs101: (i) an MTSI receiver can indicate available delay budget to an MTSI sender, and (ii) an MTSI sender can explicitly request delay budget from an MTSI receiver.
• More specifically, the RTCP-based signaling of DBI is composed of a dedicated RTCP feedback (FB) message type to carry available additional delay budget during the RTP streaming of media, signaled from the MTSI receiver to the MTSI sender. In addition, the defined RTCP feedback message type may also be used to carry requested additional delay budget during the RTP streaming of media, signaled from the MTSI sender to the MTSI receiver. A corresponding dedicated SDP parameter on the RTCP-based ability to signal available or requested additional delay budget during the IMS/SIP based capability negotiations is also defined. For example, an MTSI client (e.g., a UE101) supporting DBI may offer ‘Delay Budget Information’ (DBI) signaling in SDP for all media streams containing speech and/or video. DBI may be offered by including the a=rtcp-fb attribute with the DBI type under the relevant media line scope. DBI signaling involves RTCP feedback signaling to carry both available additional delay budget from the MTSI receiver to the MTSI sender, and requested additional delay budget from the MTSI sender to the MTSI receiver. The DBI type in conjunction with the RTCP feedback method may be expressed with the following parameter: 3gpp-delay-budget. A wildcard payload type (“*”) may be used to indicate that the RTCP feedback attribute for DBI signaling applies to all payload types. Here is an example usage of this attribute to signal DBI relative to a media line based on the RTCP feedback method: a=rtcp-fb:*3gpp-delay-budget. The ABNF for rtcp-fb-val corresponding to the feedback type “3gpp-delay-budget” is given as follows: rtcp-fb-val=/“3gpp-delay-budget”. Such RTCP-based signaling of DBI can also be used by an MTSI receiver to indicate delay budget availability created via other means such as jitter buffer size adaptation. The signaling of available or requested additional DBI may use RTCP feedback messages as specified in IETF RFC 4585. The RTCP feedback message is identified by PT (payload type)=RTPFB (205), which refers to RTP-specific feedback message. The RTCP feedback method may involve signaling of available or requested additional delay budget in both of the immediate feedback and early RTCP modes.
• As such, the RTCP feedback message may be sent from the MTSI receiver to the MTSI sender to convey to the sender the available additional delay budget from the perspective of the receiver. The recipient UE101 of the RTCP feedback message (e.g., the UE101 containing the MTSI sender) may then use this information in determining how much delay budget it may request from its eNB/gNB over the RAN interface, for example, by using RRC signaling based on UEAssistanceInformation as discussed in more detail infra.
• FIG. 3 depicts an example use case for RAN delay budget reporting. The example ofFIG. 3 is a shortening cDRX cycle for a degraded VoLTE call. InFIG. 3,UE101ais experiencing “good” radio conditions and is configured with 40 ms connected mode DRX (cDRX). Radio conditions may be considered “good” (or “better” than threshold radio conditions) if theUE101adetects or measures a channel quality and/or signal strength to be at or above some predefined threshold (within some margin of error), or detects or measures a signal noise or interference to be below a predefined threshold (within some margin of error). Additionally,UE101bis experiencing “bad” radio conditions and is configured with no cDRX. Radio conditions may be considered “bad” if theUE101bdetects or measures a channel quality and/or signal strength to be below some predefined threshold (within some margin of error), or detects or measures a signal noise or interference to be at or above a predefined threshold (within some margin of error). As examples, a bad radio condition may be declared when a UE101 detects or determines a high BLER (e.g., at or above a threshold BLER value), a large jitter or delay (e.g., at or above a threshold jitter or delay values), and/or the like.
• The example ofFIG. 3 may operate as follows. When theUE101bdetects bad radio conditions, theUE101bmay send multiple HARQ retransmissions, which may cause long jitter and/or e2e delay at thereceiver UE101a. Next, when theUE101adetects that VoLTE quality is bad (e.g., large jitter or delay), theUE101asuggests to theRAN node111ato deconfigure cDRX or shorten a cDRX cycle. In response, theRAN node111amay adjust the cDRX cycle, and the e2e delay and jitter may be reduced. According to various embodiments, theUE101amay indicate to its local RAN node111 (e.g.,RAN node111ainFIG. 3) a cDRX cycle value that is different than a currently configured cDRX cycle value. In these embodiments, theUE101aindicates a preferred cDRX cycle length via a new RRC message, and theRAN node111adecides which cDRX cycle to use. A prohibit timer may also be configured by theRAN node111ato prevent theUE101afrom sending the indication too frequently. Next, when theUE101bdetects that VoLTE e2e delay has dropped, theUE101breports a larger delay headroom toRAN node111b, and theRAN node111bmay apply more eMTC repetitions and/or more HARQ retransmissions.
• In order to realize the solution ofFIG. 3, RRC signaling procedures have been adopted based on the UEAssistanceInformation message (see e.g., tables 4-5 and 7-8 infra) that allows theUE101ato signal to delay budget reporting information to theRAN node111aas follows: theUE101ain good coverage indicates a preference to theRAN node111ato reduce the local air interface delay by sending a UEAssistanceInformation message with delayBudgetReport value and indication of type1 to decrease the connected mode DRX cycle length so that the e2e delay and jitter can be reduced; and thepeer UE101bin bad coverage can send a UEAssistanceInformation message with delayBudgetReport value and indication of type2 to its eNB to indicate a preference on Uu air interface delay adjustments. When a UE101 detects changes such as e2e MTSI voice quality or local radio quality, the UE101 may inform the eNB its new preference by sending UEAssistanceInformation messages with updated contents on delayBudgetReport. Air interface delay adjustments made through RAN delay budget reporting impact the e2e delay and quality performance of MTSI in 3GPP TS 26.114. MTSI as in 3GPP TS 26.114 currently does not specify when and how the UEs101 should use RAN-based delay adjustment mechanisms in an end-to-end fashion.
• RAN delay budget reporting may be used by MTSI UEs101 in order to locally adjust air interface delay, towards improving e2e delay and quality performance. RAN delay budget reporting allows agood coverage UE101aon the receiving end to reduce its air interface delay by turning off cDRX. This additional delay budget can then be made available for the sending UE110a, which suffers from poor coverage. The sendingUE101bin such poor coverage condition would typically keep its cDRX off and seek improving the reliability of its uplink transmissions. The sendingUE101awould request the additional delay from itslocal RAN node111ausing the RAN delay budget reporting procedures, and if granted, it would utilize the additional delay budget to improve the reliability of its uplink transmissions in order to reduce packet loss (e.g., via suitable repetition or retransmission mechanisms).
• Toward developing an e2e operational perspective for MTSI, the following mode of operation is considered. MTSI sender and MTSI receiver independently use RAN delay budget reporting mechanisms toward adjusting air interface delay in their respective RANs. As such there is no coordination between them. In the meantime, both sending and receiving UEs101 utilize available e2e metrics and other information available at their MTSI client to trigger RAN delay budget reporting.
• FIG. 4 depicts anexample procedure400 for RAN delay budget reporting in MTSI according to some embodiments.Procedure400 involves RAN delay budget reporting usage for voice in MTSI without DBI signaling. However, aspects ofprocedure400 may be applicable to RAN delay budget reporting usage for other media types (e.g., video) in MTSI without DBI signaling. In the example ofFIG. 4, theUE101ais served byRAN node111awhich is communicatively coupled with afirst CN120aandIMS130; and theUE101bis served byRAN node111bwhich is communicatively coupled with asecond CN120bandIMS130.
• Procedure400 begins atoperation401 whereUE101asendsUE101ba rate request for bitrate R0. The “Request” message in this example is a generalized application level rate request message that corresponds to CMR or RTCP-APP for voice. Where video is used, the request may also be a generalized application level rate request message that corresponds to RTCP TMMBR for video. Atoperation402,UE101bsends an RTP media flow with bitrate R0. In some embodiments, prior to sending the RTP media flow atoperation402, theUE101bmay send a rate notification message to indicate acceptance of bitrate R0. In these embodiments, the notification may be a “Notify” message, which is a generalized application level message that corresponds to RTCP TMMBN for video. Atoperation403, theUE101adetects a long delay and jitter. Additionally or alternatively, theUE101amay detect a relatively high PLR. At operation404 (includingoperations404A and404B), theUE101adetects relatively good radio conditions locally. For example,RAN node111amay send a DL ANBR of bitrate R1>R0 to theUE101a(e.g.,operation404B), and theUE101ameasures a relatively low BLER over a local radio link based on the monitoring of successful downlink packet transmissions. Additionally or alternatively, theUE101amay measure downlink throughput over the radio air interface that is much higher than the received bitrate after accounting for the relevant headers. In the meantime,UE101adetects relatively high packet losses (e.g., operation403) after monitoring reception of RTP packets, also by monitoring RTCP sender and receiver reports, and applying the highest possible jitter buffer according to the reference JBM subject to the JBM compliance (performance) requirement(s) of MTSI. The JBM performance requirements may be a threshold for a CDF of the speech-frame delay introduced by a reference delay computation algorithm, where the CDF threshold may be set by shifting the reference delay computation algorithm CDF 60 ms. The speech-frame delay CDF is defined as: P(x)=Probability (delay_compensation_by_JBM≤x). The video-frame delay CDF may be the same or similar as the speech-frame delay CDF. Hence,UE101aconcludes that the local radio conditions experienced byUE101bare relatively poor.
• The adaptation of media in RTP streams that the MTSI client in terminal receives in the downlink direction (e.g.,operation404B) may require sending application-level messages to adapt the remote media encoder bitrate. When an MTSI client in terminal receives an ANBR message for the local DL that triggers an adaptation decision (e.g.,operation404B inFIG. 4), for the case of video and if TMMBR/TMMBN are supported in the session, then a corresponding TMMBR message requesting the remote media sender to change its rate to match the local downlink restriction may be sent, as described in clause 10.3.2 of 3GPP TS 26.114 (2018 December). For the case of voice, adaptation signaling to match the local downlink restriction may be initiated towards the remote media sender, as described in clause 10.2 of 3GPP TS 26.114 (2018 December). When an MTSI client in terminal receives application signaling for bitrate adaptation related to received media, such as TMMBN (for video), the media receiver receiving a TMMBN with increased bitrate and where the remote media sender owns the restriction may re-evaluate its downlink adaptation triggers and, if an adaptation decision arrives at a lower bitrate value than in the received TMMBN, send a TMMBR with that lower bitrate. When deciding whether or not to send TMMBR, the media receiver may take all available adaptation triggers into account, e.g., bitrate limit from the most recently received downlink ANBR message. If the media receiver has reason to believe the most recently received ANBR for its downlink no longer applies, it may send an ANBRQ message for its downlink, if supported, to trigger receiving an ANBR message with recent information.
• Atoperation405A, theUE101asends an RRC message including a UEAssistanceInformation message toRAN node111awith type-1 to turn off cDRX. It is assumed thatRAN node111agrants this request and turns off CDRX forUE101a, and atoperation405B, theRAN node111asends an ACK to theUE101ato indicate that the cDRX has been turned off. Turning off cDRX is relevant when PLR is relatively high, which is the conclusion ofUE101ain the example ofFIG. 4, as peroperations403,404A, and404B. However, it should be noted thatUE101acan increase the JBM depth to compensate the delay if PLR is relatively low and the detected jitter is relatively high. In this scenario, delay budget request from theUE101ato theRAN node111ais not necessary and UEAssistanceInformation message may not be sent. Moreover, even in a relatively high PLR situation and/or based on other considerations, theUE101amay choose not to turn cDRX off, for example, when saving battery power is critical or otherwise desired.
• Atoperation406A, theUE101bdetects relatively high packet losses on its uplink due to poor coverage conditions. For example, theUE101bmay measure high BLER over its local radio link based on the monitoring of successful uplink packet transmissions, for example, by monitoring the HARQ acknowledgements received. Atoperation406B, theUE101brequests additional delay budget from itslocal RAN node111bin order to perform additional re-transmissions to increase the reliability of its UL transmissions. When requesting this additional delay budget, theUE101bmay also consider e2e RTT measured based on RTCP reports. In this example,RAN node111bgrants the request for additional delay budget, and atoperation406C, theRAN node111bsends an ACK message to theUE101bto indicate acceptance of the additional delay budget. Because theUE101ahas already turned its cDRX off, it is unlikely that the JBM constraint atUE101awill lead to packet losses in response to the increase air interface delay over theRAN110 corresponding toUE101b. Atoperation407, theUE101ameasures reduced e2e delay and jitter. Additionally or alternatively, theUE101amay detect reduced PLR, in comparison with the PLR detected at operation403 (if a PLR was detected at operation403), and improved voice quality. Atoperation408,UE101bsends an RTP media flow for voice with bitrate R0. The actions of theUE101ain operations403-405B and the actions ofUE101binoperations406A-C may be completely independent, and there may be no coordination between the two UEs101 for this autonomous mode of operation.
• FIG. 5 shows anexample bitmask500, which may be used for SDP-based negotiation of RAN capabilities, in accordance with various embodiments. While RAN-layer delay budget reporting allows UEs101 to locally adjust air interface delay, such a mechanism does not provide coordination between the UEs to manage delay and jitter on an e2e basis. In particular, considering the autonomous operation of the MTSI sender and receiver as described previously, an MTSI receiver's decision to turn cDRX off may be dependent on the remote MTSI sender's ability to leverage the available delay budget to further improve the reliability of its transmissions. As such, it would be desirable for the UEs101 to exchange information about specific RAN capabilities that would be relevant in influencing the remote UE's101 adaptation and impact the e2e quality of the VoLTE call. Such RAN capabilities may include RAN delay budget reporting, TTI bundling, HARQ support, and RAN-assisted codec adaptation or ANBR, and/or the like.
• According to various embodiments, during SDP capability negotiation, each UE101 may include a RANCapabilities attribute to describe its capabilities. Using the RANCapabilities attribute, each UE101 may know the other UE's101 radio capabilities after the SDP offer and answer exchange. Each UE101 may use this knowledge as part of its media and radio level adaptation. For instance, upon learning during the SDP exchange that theremote UE101b(e.g., an MTSI sender) supports delay budget reporting and TTI bundling, alocal UE101a(e.g., the MTSI receiver) may decide to turn off cDRX when it detects good radio conditions locally, but high packet loss on an e2e basis after monitoring RTP reception statistics. However, if theremote UE101bdoes not support delay budget reporting as indicated in the SDP, then thelocal UE101amay decide not to turn of cDRX, since even if cDRX was turned off, theremote UE101bmay not be able to make use of the additional delay budget.
• In various embodiments, the RAN capabilities may be signaled in an SDP message using the “a=RANCapabilities” attribute at the session level. The following parameters may be provided in the RANCapabilities attribute: a Delay Budget field including a Boolean value indicating whether the UE101 supports delay budget reporting; a TTI_Bundling field including a Boolean value indicating whether the UE supports TTI bundling; a RAN frame aggregation field including a Boolean value indicating whether the UE supports RAN frame aggregation; and RAN_Codec field including a Boolean value indicating whether the UE supports RAN-assisted codec adaptation (or ANBR). In theexample bitmask500 ofFIG. 5, the Delay_Budget field is included in the bit position0 (i.e., the least significant bit), the TTI_Bundling field isbit position1, the RAN frame aggregation field is the 2 bit position, the RAN_Codec field isbit position3, and a reserved bit field is in thebit position4. The other bits of theexample bitmask500 may be used to convey other parameters or other types of information. Additionally, other arrangements are possible in other embodiments.
• In addition to indicating whether various RAN capabilities are supported, the RANCapabilities attribute may also contain parameters that describe specific RAN configurations (e.g., that may be configured by the UE's101 local RAN node111) in the UE101 that may be relevant in influencing the remote UE's101 adaptation and impact the end to end quality of the VoLTE call. An example use of the RANCapabilities attribute in the SDP is shown by table 3.

• Table 3
  	a=RANCapabilities[Delay Budget=1,TTI Bundling=1,RAN Codec=0]

• FIG. 6 illustrates an example ofinfrastructure equipment600 in accordance with various embodiments. The infrastructure equipment600 (or “system600”) may be implemented as a base station, radio head, RAN node such as the RAN nodes111 and/orAP106 shown and described previously, application server(s)130, and/or any other element/device discussed herein. In other examples, thesystem600 could be implemented in or by a UE101. Thesystem600 includesapplication circuitry605,baseband circuitry610, one or more radio front end modules (RFEMs)615,memory circuitry620, power management integrated circuitry (PMIC)625,power tee circuitry630,network controller circuitry635,network interface connector640,satellite positioning circuitry645, anduser interface650. In some embodiments, thedevice600 may include additional elements such as, for example, memory/storage, display, camera, sensor, or I/O interface. In other embodiments, the components described below may be included in more than one device. For example, said circuitries may be separately included in more than one device for CRAN, vBBU, or other like implementations.
• Application circuitry605 includes circuitry such as, but not limited to one or more processors (or processor cores), cache memory, and one or more of low drop-out voltage regulators (LDOs), interrupt controllers, serial interfaces such as SPI, I²C or universal programmable serial interface module, real time clock (RTC), timer-counters including interval and watchdog timers, general purpose I/O, memory card controllers such as Secure Digital (SD) MultiMediaCard (MMC) or similar, USB interfaces, Mobile Industry Processor Interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. The processors (or cores) of theapplication circuitry605 may be coupled with or may include memory/storage elements and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on thesystem600. In some implementations, the memory/storage elements may be on-chip memory circuitry, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any other type of memory device technology, such as those discussed herein.
• The processor(s) ofapplication circuitry605 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSP), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, theapplication circuitry605 may comprise, or may be, a special-purpose processor/controller to operate according to the various embodiments herein. As examples, the processor(s) ofapplication circuitry605 may include one or more Intel Pentium®, Core®, or Xeon® processor(s); Advanced Micro Devices (AMD) Ryzen® processor(s), Accelerated Processing Units (APUs), or Epyc® processors; ARM-based processor(s) licensed from ARM Holdings, Ltd. such as the ARM Cortex-A family of processors and the ThunderX2® provided by Cavium™, Inc.; a MIPS-based design from MIPS Technologies, Inc. such as MIPS Warrior P-class processors; and/or the like. In some embodiments, thesystem600 may not utilizeapplication circuitry605, and instead may include a special-purpose processor/controller to process IP data received from an EPC or 5GC, for example.
• In some implementations, theapplication circuitry605 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision and/or deep learning accelerators. As examples, the programmable processing devices may be one or more FPGAs; programmable logic devices (PLDs) such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs); ASICs such as structured ASICs; programmable SoCs (PSoCs); and the like. In such implementations, the circuitry ofapplication circuitry605 may comprise logic blocks or logic fabric, and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry ofapplication circuitry605 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc. in look-up-tables (LUTs) and the like.
• Thebaseband circuitry610 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. The various hardware electronic elements ofbaseband circuitry610 are discussed infra with regard toFIG. 9.User interface circuitry650 may include one or more user interfaces designed to enable user interaction with thesystem600 or peripheral component interfaces designed to enable peripheral component interaction with thesystem600. User interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, speakers or other audio emitting devices, microphones, a printer, a scanner, a headset, a display screen or display device, etc. Peripheral component interfaces may include, but are not limited to, a nonvolatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc.
• The radio front end modules (RFEMs)615 may comprise a millimeter wave (mmWave) RFEM and one or more sub-mmWave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. The RFICs may include connections to one or more antennas or antenna arrays (see e.g.,antenna array911 ofFIG. 9 infra), and the RFEM may be connected to multiple antennas. In alternative implementations, both mmWave and sub-mmWave radio functions may be implemented in the samephysical RFEM615, which incorporates both mmWave antennas and sub-mmWave. Thememory circuitry620 may include one or more of volatile memory including dynamic random access memory (DRAM) and/or synchronous dynamic random access memory (SDRAM), and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may incorporate the three-dimensional (3D) cross-point (XPOINT) memories from Intel® and Micron®.Memory circuitry620 may be implemented as one or more of solder down packaged integrated circuits, socketed memory modules and plug-in memory cards.
• ThePMIC625 may include voltage regulators, surge protectors, power alarm detection circuitry, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuitry may detect one or more of brown out (under-voltage) and surge (over-voltage) conditions. Thepower tee circuitry630 may provide for electrical power drawn from a network cable to provide both power supply and data connectivity to theinfrastructure equipment600 using a single cable. Thenetwork controller circuitry635 may provide connectivity to a network using a standard network interface protocol such as Ethernet, Ethernet over GRE Tunnels, Ethernet over MPLS, or some other suitable protocol. Network connectivity may be provided to/from theinfrastructure equipment600 vianetwork interface connector640 using a physical connection, which may be electrical (commonly referred to as a “copper interconnect”), optical, or wireless. Thenetwork controller circuitry635 may include one or more dedicated processors and/or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, thenetwork controller circuitry635 may include multiple controllers to provide connectivity to other networks using the same or different protocols.
• Thepositioning circuitry645 includes circuitry to receive and decode signals transmitted/broadcasted by a positioning network of a GNSS. Examples of navigation satellite constellations (or GNSS) include United States' GPS, Russia's GLONASS, the European Union's Galileo system, China's BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (e.g., Navigation with Indian Constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), etc.), or the like. Thepositioning circuitry645 comprises various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate OTA communications) to communicate with components of a positioning network, such as navigation satellite constellation nodes. In some embodiments, thepositioning circuitry645 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance. Thepositioning circuitry645 may also be part of, or interact with, thebaseband circuitry610 and/orRFEMs615 to communicate with the nodes and components of the positioning network. Thepositioning circuitry645 may also provide position data and/or time data to theapplication circuitry605, which may use the data to synchronize operations with various infrastructure (e.g., RAN nodes111, etc.), or the like.
• The components shown byFIG. 6 communicate with one another using interface circuitry, which may include interconnect (IX)606. TheIX606 may include any number of bus and/or IX technologies such as industry standard architecture (ISA), extended ISA (EISA), inter-integrated circuit (I²C), an serial peripheral interface (SPI), point-to-point interfaces, power management bus (PMBus), peripheral component interconnect (PCI), PCI express (PCIe), Intel® Ultra Path Interface (UPI), Intel® Accelerator Link (IAL), Common Application Programming Interface (CAPI), Intel® QuickPath interconnect (QPI), Ultra Path Interconnect (UPI), Intel® Omni-Path Architecture (OPA) IX, RapidIO™ system IXs, Cache Coherent Interconnect for Accelerators (CCIA), Gen-Z Consortium IXs, Open Coherent Accelerator Processor Interface (OpenCAPI) IX, a HyperTransport interconnect, and/or any number of other IX technologies. The IX technology may be a proprietary bus, for example, used in an SoC based system.
• FIG. 7 illustrates an example of a platform700 (or “device700”) in accordance with various embodiments. In embodiments, thecomputer platform700 may be suitable for use as UEs101,application servers130, and/or any other element/device discussed herein. Theplatform700 may include any combinations of the components shown in the example. The components ofplatform700 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in thecomputer platform700, or as components otherwise incorporated within a chassis of a larger system. The block diagram ofFIG. 7 is intended to show a high level view of components of thecomputer platform700. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.
• Application circuitry705 includes circuitry such as, but not limited to one or more processors (or processor cores), cache memory, and one or more of LDOs, interrupt controllers, serial interfaces such as SPI, I²C or universal programmable serial interface module, RTC, timer-counters including interval and watchdog timers, general purpose I/O, memory card controllers such as SD MMC or similar, USB interfaces, MIPI interfaces, and JTAG test access ports. The processors (or cores) of theapplication circuitry705 may be coupled with or may include memory/storage elements and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on thesystem700. In some implementations, the memory/storage elements may be on-chip memory circuitry, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any other type of memory device technology, such as those discussed herein.
• The processor(s) ofapplication circuitry705 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSP, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, a multithreaded processor, an ultra-low voltage processor, an embedded processor, some other known processing element, or any suitable combination thereof. The processors (or cores) of theapplication circuitry705 may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on thesystem700. In these embodiments, the processors (or cores) of theapplication circuitry705 are configured to operate application software to provide a specific service to a user of thesystem700. In some embodiments, theapplication circuitry705 may comprise, or may be, a special-purpose processor/controller to operate according to the various embodiments herein.
• As examples, the processor(s) ofapplication circuitry705 may include an Intel® Architecture Core™ based processor, such as a Quark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, or another such processor available from Intel® Corporation, Santa Clara, Calif. The processors of theapplication circuitry705 may also be one or more of Advanced Micro Devices (AMD) Ryzen® processor(s) or Accelerated Processing Units (APUs); A5-A9 processor(s) from Apple® Inc., Snapdragon™ processor(s) from Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™ processor(s); a MIPS-based design from MIPS Technologies, Inc. such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; an ARM-based design licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M family of processors; or the like. In some implementations, theapplication circuitry705 may be a part of a system on a chip (SoC) in which theapplication circuitry705 and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel® Corporation. Other examples of the processor circuitry ofapplication circuitry605 are mentioned elsewhere in the present disclosure.
• Additionally or alternatively,application circuitry705 may include circuitry such as, but not limited to, one or more FPGAs; programmable logic devices (PLDs) such as CPLDs, HCPLDs, etc.; ASICs such as structured ASICs; PSoCs; and the like. In such embodiments, the circuitry ofapplication circuitry705 may comprise logic blocks or logic fabric, and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry ofapplication circuitry705 may include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc. in LUTs and the like.
• Thebaseband circuitry710 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. Thebaseband circuitry710 may include circuitry such as, but not limited to, one or more single-core or multi-core processors (e.g., one or more baseband processors) or control logic to process baseband signals received from a receive signal path of theRFEMs715, and to generate baseband signals to be provided to theRFEMs715 via a transmit signal path. In various embodiments, thebaseband circuitry710 may implement a real-time OS(RTOS) to manage resources of thebaseband circuitry710, schedule tasks, etc. Examples of the RTOS may include Operating System Embedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by Mentor Graphics®, Versatile Real-Time Executive (VRTX) provided by Mentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or any other suitable RTOS, such as those discussed herein. The various hardware electronic elements ofbaseband circuitry710 are discussed infra with regard toFIG. 9.
• TheRFEMs715 may comprise a millimeter wave (mmWave) RFEM and one or more sub-mmWave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. The RFICs may include connections to one or more antennas or antenna arrays (see e.g.,antenna array911 of Figure XT infra), and the RFEM may be connected to multiple antennas. In alternative implementations, both mmWave and sub-mmWave radio functions may be implemented in the samephysical RFEM715, which incorporates both mmWave antennas and sub-mmWave.
• Thememory circuitry720 may include any number and type of memory devices used to provide for a given amount of system memory. As examples, thememory circuitry720 may include one or more of volatile memory including RAM, DRAM and/or SDRAM, and NVM including high-speed electrically erasable memory (commonly referred to as Flash memory), PRAM, MRAM, etc. Thememory circuitry720 may be developed in accordance with a Joint Electron Devices Engineering Council (JEDEC) low power double data rate (LPDDR)-based design, such as LPDDR2, LPDDR3, LPDDR4, or the like.Memory circuitry720 may be implemented as one or more of solder down packaged integrated circuits, single die package, dual die package, or quad die package (Q17P), socketed memory modules, dual inline memory modules (DIMMs) including microDIMMs or MiniDIMMs, and/or soldered onto a motherboard via a ball grid array. In low power implementations, thememory circuitry720 may be on-die memory or registers associated with theapplication circuitry705. To provide for persistent storage of information such as data, applications, operating systems and so forth,memory circuitry720 may include one or more mass storage devices, which may include, inter alia, a solid state disk drive (SSDD), hard disk drive (HDD), a micro HDD, resistance change memories, phase change memories, holographic memories, or chemical memories, among others. For example, thecomputer platform700 may incorporate the three-dimensional (3D) cross-point (XPOINT) memories from Intel® and Micron®.
• Removable memory circuitry723 may include devices, circuitry, enclosures/housings, ports or receptacles, etc. used to couple portable data storage devices with theplatform700. These portable data storage devices may be used for mass storage purposes, and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD picture cards, and the like), and USB flash drives, optical discs, external HDDs, and the like.
• In some implementations, thememory circuitry720 and/or theremovable memory723 provide persistent storage of information such as data, applications, operating systems (OS), and so forth. The persistent storage circuitry is configured to store computational logic (or “modules”) in the form of software, firmware, or hardware commands to implement the techniques described herein. The computational logic may be employed to store working copies and/or permanent copies of computer programs (or data to create the computer programs) for the operation of various components of platform700 (e.g., drivers, etc.), an operating system ofplatform700, one or more applications, and/or for carrying out the embodiments discussed herein. The computational logic may be stored or loaded intomemory circuitry720 as instructions (or data to create the instructions) for execution by theapplication circuitry705 to provide the functions described herein. The various elements may be implemented by assembler instructions supported by processor circuitry or high-level languages that may be compiled into such instructions (or data to create the instructions). The permanent copy of the programming instructions may be placed into persistent storage devices of persistent storage circuitry in the factory or in the field through, for example, a distribution medium (not shown), through a communication interface (e.g., from a distribution server (not shown)), or OTA.
• In an example, the instructions provided via thememory circuitry720 and/or the persistent storage circuitry are embodied as one or more non-transitory computer readable storage media including program code, a computer program product (or data to create the computer program) with the computer program or data, to direct theapplication circuitry705 ofplatform700 to perform electronic operations in theplatform700, and/or to perform a specific sequence or flow of actions, for example, as described with respect to the flowchart(s) and block diagram(s) of operations and functionality depicted infra (see e.g.,FIGS. 12-13). Theapplication circuitry705 accesses the one or more non-transitory computer readable storage media over theIX706.
• Although the instructions and/or computational logic have been described as code blocks included in thememory circuitry720 and/or code blocks in the persistent storage circuitry, it should be understood that any of the code blocks may be replaced with hardwired circuits, for example, built into an FPGA, ASIC, or some other suitable circuitry. For example, whereapplication circuitry705 includes (e.g., FPGA based) hardware accelerators as well as processor cores, the hardware accelerators (e.g., the FPGA cells) may be pre-configured (e.g., with appropriate bit streams) with the aforementioned computational logic to perform some or all of the functions discussed previously (in lieu of employment of programming instructions to be executed by the processor core(s)).
• Theplatform700 may also include interface circuitry (not shown) that is used to connect external devices with theplatform700. The external devices connected to theplatform700 via the interface circuitry includesensor circuitry721 andactuators722, as well as removable memory devices coupled toremovable memory circuitry723.
• Thesensor circuitry721 include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other a device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units (IMUs) comprising accelerometers, gyroscopes, and/or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) comprising 3-axis accelerometers, 3-axis gyroscopes, and/or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging (LiDAR) sensors; proximity sensors (e.g., IR radiation detector and the like), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other like audio capture devices; etc.
• Actuators722 include devices, modules, or subsystems whose purpose is to enableplatform700 to change its state, position, and/or orientation, or move or control a mechanism or (sub)system. Theactuators722 comprise electrical and/or mechanical devices for moving or controlling a mechanism or system, and converts energy (e.g., electric current or moving air and/or liquid) into some kind of motion. Theactuators722 may include one or more electronic (or electrochemical) devices, such as piezoelectric biomorphs, solid state actuators, solid state relays (SSRs), shape-memory alloy-based actuators, electroactive polymer-based actuators, relay driver integrated circuits (ICs), and/or the like. Theactuators722 may include one or more electromechanical devices such as pneumatic actuators, hydraulic actuators, electromechanical switches including electromechanical relays (EMRs), motors (e.g., DC motors, stepper motors, servomechanisms, etc.), wheels, thrusters, propellers, claws, clamps, hooks, an audible sound generator, and/or other like electromechanical components. Theplatform1000 may be configured to operate one ormore actuators722 based on one or more captured events and/or instructions or control signals received from a service provider and/or various client systems.
• In some implementations, the interface circuitry may connect theplatform700 withpositioning circuitry745. Thepositioning circuitry745 includes circuitry to receive and decode signals transmitted/broadcasted by a positioning network of a GNSS. Examples of navigation satellite constellations (or GNSS) include United States' GPS, Russia's GLONASS, the European Union's Galileo system, China's BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (e.g., NAVIC), Japan's QZSS, France's DORIS, etc.), or the like. Thepositioning circuitry745 comprises various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and the like to facilitate OTA communications) to communicate with components of a positioning network, such as navigation satellite constellation nodes. In some embodiments, thepositioning circuitry745 may include a Micro-PNT IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance. Thepositioning circuitry745 may also be part of, or interact with, thebaseband circuitry710 and/orRFEMs715 to communicate with the nodes and components of the positioning network. Thepositioning circuitry745 may also provide position data and/or time data to theapplication circuitry705, which may use the data to synchronize operations with various infrastructure (e.g., radio base stations), for turn-by-turn navigation applications, or the like
• In some implementations, the interface circuitry may connect theplatform700 with Near-Field Communication (NFC)circuitry740.NFC circuitry740 is configured to provide contactless, short-range communications based on radio frequency identification (RFID) standards, wherein magnetic field induction is used to enable communication betweenNFC circuitry740 and NFC-enabled devices external to the platform700 (e.g., an “NFC touchpoint”).NFC circuitry740 comprises an NFC controller coupled with an antenna element and a processor coupled with the NFC controller. The NFC controller may be a chip/IC providing NFC functionalities to theNFC circuitry740 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to emit short-range RF signals. The RF signals may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transmit stored data to theNFC circuitry740, or initiate data transfer between theNFC circuitry740 and another active NFC device (e.g., a smartphone or an NFC-enabled POS terminal) that is proximate to theplatform700.
• Thedriver circuitry746 may include software and hardware elements that operate to control particular devices that are embedded in theplatform700, attached to theplatform700, or otherwise communicatively coupled with theplatform700. Thedriver circuitry746 may include individual drivers allowing other components of theplatform700 to interact with or control various I/O devices that may be present within, or connected to, theplatform700. For example,driver circuitry746 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface of theplatform700, sensor drivers to obtain sensor readings ofsensor circuitry721 and control and allow access tosensor circuitry721, actuator drivers to obtain actuator positions of theactuators722 and/or control and allow access to theactuators722, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.
• The power management integrated circuitry (PMIC)725 (also referred to as “power management circuitry725”) may manage power provided to various components of theplatform700. In particular, with respect to thebaseband circuitry710, thePMIC725 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. ThePMIC725 may often be included when theplatform700 is capable of being powered by abattery730, for example, when the device is included in a UE101.
• In some embodiments, thePMIC725 may control, or otherwise be part of, various power saving mechanisms of theplatform700. For example, if theplatform700 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as DRX after a period of inactivity. During this state, theplatform700 may power down for brief intervals of time and thus save power. If there is no data traffic activity for an extended period of time, then theplatform700 may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. Theplatform700 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. Theplatform700 may not receive data in this state; in order to receive data, it must transition back to RRC_Connected state. An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.
• Abattery730 may power theplatform700, although in some examples theplatform700 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. Thebattery730 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in V2X applications, thebattery730 may be a typical lead-acid automotive battery.
• In some implementations, thebattery730 may be a “smart battery,” which includes or is coupled with a Battery Management System (BMS) or battery monitoring integrated circuitry. The BMS may be included in theplatform700 to track the state of charge (SoCh) of thebattery730. The BMS may be used to monitor other parameters of thebattery730 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of thebattery730. The BMS may communicate the information of thebattery730 to theapplication circuitry705 or other components of theplatform700. The BMS may also include an analog-to-digital (ADC) convertor that allows theapplication circuitry705 to directly monitor the voltage of thebattery730 or the current flow from thebattery730. The battery parameters may be used to determine actions that theplatform700 may perform, such as transmission frequency, network operation, sensing frequency, and the like.
• A power block, or other power supply coupled to an electrical grid may be coupled with the BMS to charge thebattery730. In some examples, the power block XS30 may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in thecomputer platform700. In these examples, a wireless battery charging circuit may be included in the BMS. The specific charging circuits chosen may depend on the size of thebattery730, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, among others.
• User interface circuitry750 includes various I/O devices present within, or connected to, theplatform700, and includes one or more user interfaces designed to enable user interaction with theplatform700 and/or peripheral component interfaces designed to enable peripheral component interaction with theplatform700. The user interface circuitry750 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, and/or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any number and/or combinations of audio or visual display, including, inter alia, one or more simple visual outputs/indicators (e.g., binary status indicators (e.g., light emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (e.g., Liquid Chrystal Displays (LCD), LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of theplatform700. The output device circuitry may also include speakers or other audio emitting devices, printer(s), and/or the like. In some embodiments, thesensor circuitry721 may be used as the input device circuitry (e.g., an image capture device, motion capture device, or the like) and one ormore actuators722 may be used as the output device circuitry (e.g., an actuator to provide haptic feedback or the like). In another example, NFC circuitry comprising an NFC controller coupled with an antenna element and a processing device may be included to read electronic tags and/or connect with another NFC-enabled device. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power supply interface, etc.
• The components shown byFIG. 7 communicate with one another using interface circuitry, which may includeIX706. TheIX706 may include any number of bus and/or IX technologies such as ISA, EISA, I²C, SPI, point-to-point interfaces, PMBus, PCI) PCIe, Intel® UPI, IAL, CAPI, Intel® QPI, UPI, Intel® OPA IX, RapidIO™ system IXs, CCIA, Gen-Z Consortium IXs, OpenCAPI IX, a HyperTransport interconnect, Time-Trigger Protocol (TTP) system, a FlexRay system, and/or any number of other IX technologies. The IX technology may be a proprietary bus, for example, used in an SoC based system.
• According to various embodiments, the various components of thesystem700 may implement an MTSI client in terminal using 3GPP access. The MTSI client in terminal may include speech decoder and/or encoder circuitry, video decoder and/or encoder circuitry, text decoder and/or encoder circuitry, session setup and control circuitry, and a packet-based network interface. The packet-based network interface handles the transport of media, which includes the encapsulation of the coded media in a transport protocol as well as handling of coded media received from the network. The packet-based network interface interfaces with 3GPP L2 for the transport of media and control data. The various decoder and/or encoder circuitries interface with the user interface circuitry750 to obtain media data to be encoded for transmission, and to provide decoded media data to the user interface circuitry750 to be output. The various decoder and/or encoder circuitries interface with the packet-based network interface to obtain respective encoded media data to be decoded. General control-related elements of an MTSI client for conversational media, such as SIP signaling, are handled by the session setup handling and session control circuitry. These control-related elements include, for example, usage of SDP (see e.g., RFC 4566) and SDPCapNeg in SIP invitations for capability negotiation and media stream setup, set-up and control of the individual media streams between clients, and interactivity such as adding and dropping of media components.
• Various combinations of the components of thesystem700 may implement the elements of the MTSI client in terminal. In one example, all of the MTSI client in terminal elements may be implemented in thebaseband circuitry710. In a second example, theapplication circuitry705 may implement the speech decoder and/or encoder circuitry, video decoder and/or encoder circuitry, text decoder and/or encoder circuitry, and the session setup and control circuitry; and the packet-based network interface may be implemented by thebaseband circuitry710.
• The Multimedia Telephony Service for IMS supports simultaneous transfer of multiple media components with real-time characteristics. Media components denote the actual components that the end-user experiences. Multiple media components (including media components of the same media type) may be present in a session, where at least one of these components is present in all conversational multimedia telephony sessions. All media components can be added or dropped during an ongoing session as required either by the end-user or by controlling nodes in the network, assuming that when adding components, the capabilities of the MTSI client support the additional component. The media components may include core media components including, for example, speech (e.g., the sound that is picked up by a microphone of a first terminal (e.g.,UE101a), transferred from the first terminal to a second terminal (e.g.,UE101b), and played out in an earphone/loudspeaker of the second terminal; speech includes detection, transport and generation of DTMF events), video (e.g., moving image(s) captured by a camera of a first terminal (e.g.,UE101a), transmitted to a second terminal (e.g.,UE101b), and rendered on a display of the second terminal), and text (e.g., characters typed on a keyboard or drawn on a screen on a first terminal (e.g.,UE101a) and rendered in real time on the display of a second terminal (e.g.,UE101b); the flow is time-sampled so that no specific action is needed from the user to request transmission). For the purposes of the present disclosure, the terms “voice,” “speech,” and “audio” may be synonymous and used interchangeably. The aforementioned media components may be transported in real time over RTP with each respective payload format mapped onto one or more RTP streams (see e.g., IETF RFC 3550). Other media types than those mentioned previously may be included in a session, for example, facsimile (fax) transmission data and non-conversational media such as IMS messaging (see e.g., 3GPP TS 24.247).
• The MTSI client specifies various media codecs for individual media components. A “codec” refers to program code or process/procedure for encoding or decoding a digital data stream or signal. Examples of the codecs that may be used include AMR (see e.g., 3GPP TS 26.071) including AMR-NB, AMR-WB, and EVS AMR-WB IO (i.e., AMR-WB IO included in the EVS codec); EVS; DSR Extended Advanced Front-end codec; DTMF codecs; H.224; H.281; H.263; H.264 (MPEG-4/AVC); H.265 (HEVC); H.324 and/or 3G-324M; EVRC including EVRC-WB; G.729-based codecs including CS-ACELP codecs, the G.729.1 Audio Codec; ITU-T Recommendation T.140 codecs (including presentation control functions from ISO 6429); and/or other like codecs.
• In various embodiments, theapplication circuitry705 and/or thebaseband circuitry710 may implement JBM circuitry. JBM denotes the actual buffer as well as any control, adaptation and media processing algorithm (excluding speech decoder) used in the management of the jitter induced in a transport channel. In some implementations, the JBM circuitry of an MTSI client with an adaptive jitter buffer may include a jitter buffer, network analyzer, adaption control logic, a decoder, and an adaptation unit. The network analyzer and the adaptation control logic, together with the information on buffer status form the actual buffer, control the JBM functionality, whereas the decoder and the adaptation unit provide the media processing functionality.
• In these implementations, the jitter buffer is configured to unpack incoming RTP payloads and to store received media frames (e.g., speech or video). The buffer status may be used as input to the adaptation control logic. Furthermore, the buffer is also linked to the decoder to provide frames for decoding when requested for decoding by the decoder. The decoder may be the same or similar to the decoder circuitry mentioned previously. For example, the decoder may be a speech decoder implementing standard AMR, AMR-WB, and/or EVS speech codecs. In some implementations, the decoder may include error concealment and/or bad frame handling functionality. The decoder may be used with or without the adaptation unit. The network analyzer is configured to monitor the incoming packet stream and to collect reception statistics (e.g., jitter, packet loss) that are needed for jitter buffer adaptation. In implementations where RTCP is used, the network analyzer is also configured to maintain statistics required by the RTCP.
• The adaptation control logic (also referred to as “buffer control logic”) is configured to adjust playback delay, and the operation of the adaptation functionality makes decisions on the buffering delay adjustments and required media adaptation actions based on the buffer status (e.g., average buffering delay, buffer occupancy, etc.) and input from the network analyzer. External control input, including RTCP inputs/statistics from the sender, can be used, for example, to enable inter-media synchronization, to adapt the jitter buffer, and/or other external scaling requests. In these cases, the adaptation control logic provides scaling requests and scaling window information to the adaptation unit. The adaptation control logic may utilize different adaptation strategies such as fixed jitter buffer (without adaptation and time scaling), simple adaptation during comfort noise periods or buffer adaptation also during active speech. The general operation is controlled with desired proportion of frames arriving late, adaptation strategy and adaptation rate.
• The adaptation unit is configured to shorten or extend the output signal length according to requests given by the adaptation control logic to enable buffer delay adjustment in a transparent manner. The adaptation is performed using the frame based or sample based time scaling on the decoder output signal during comfort noise periods only or during active speech and comfort noise. The buffer control logic may have a mechanism to limit the maximum scaling ratio. Providing a scaling window in which the targeted time scale modifications are performed improves the situation in certain scenarios (e.g., when reacting to the clock drift or to a request of inter-media (re)synchronization) by allowing flexibility in allocating the scaling request on several frames and performing the scaling on a content-aware manner. The adaptation unit may be implemented either in a separate entity from the decoder or embedded within the decoder.
• Speech JBM used in MTSI may support source-controlled rate operation as well as non-source-controlled rate operation; is capable to receive the de-packetized frames out of order and present them in order for decoder consumption; is capable to receive duplicate speech frames and only present unique speech frames for decoder consumption; and is capable of handling clock drift between the encoding and decoding end-points. JBM may also be used for video frames/data wherein the overall design of the buffer may aim to minimize delay, maintain synchronization with speech, and minimize dropping of late packets. In some implementations, JBM for text may not be needed, but may still be used according tosection 5 of RFC 4103 where a calculation is described for the time allowed before an extra delayed text packet may be regarded to be lost.
• FIG. 8 illustrates components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.Hardware resources800 include one or more processors (or processor cores)810, one or more memory/storage devices820, and one ormore communication resources830, each of which may be communicatively coupled via abus840. For embodiments where node virtualization (e.g., NFV) is utilized, ahypervisor802 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize thehardware resources800.
• The processors810 may include, for example, aprocessor812 and aprocessor814. The processor(s)810 may be, for example, a CPU, a reduced instruction set computing (RISC) processor, a CISC processor, a GPU, a DSP such as a baseband processor, an ASIC, an FPGA, a RFIC, another processor (including those discussed herein), or any suitable combination thereof. The memory/storage devices820 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices820 may include, but are not limited to, any type of volatile or nonvolatile memory such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-state storage, etc.
• Thecommunication resources830 may include interconnection or network interface components or other suitable devices to communicate with one or moreperipheral devices804 or one ormore databases806 via anetwork808. For example, thecommunication resources830 may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components, such as those discussed herein.
• Instructions850 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors810 to perform any one or more of the methodologies discussed herein. Theinstructions850 may reside, completely or partially, within at least one of the processors810 (e.g., within the processor's cache memory), the memory/storage devices820, or any suitable combination thereof. Furthermore, any portion of theinstructions850 may be transferred to thehardware resources800 from any combination of theperipheral devices804 or thedatabases806. Accordingly, the memory of processors810, the memory/storage devices820, theperipheral devices804, and thedatabases806 are examples of computer-readable and machine-readable media.
• FIG. 9 illustrates example components ofbaseband circuitry910 andRFEM915 in accordance with various embodiments. Thebaseband circuitry910 corresponds to thebaseband circuitry610 and710 ofFIGS. 6 and 7, respectively. TheRFEM915 corresponds to theRFEM615 and715 ofFIGS. 6 and 7, respectively. As shown, theRFEMs915 may includeRF circuitry906, front-end module (FEM)circuitry908,antenna array911 coupled together at least as shown.
• Thebaseband circuitry910 includes circuitry and/or control logic configured to carry out various radio/network protocol and radio control functions that enable communication with one or more radio networks via theRF circuitry906. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of thebaseband circuitry910 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of thebaseband circuitry910 may include convolution, tail-biting convolution, turbo, Viterbi, LDPC, and/or polar code encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. Thebaseband circuitry910 is configured to process baseband signals received from a receive signal path of theRF circuitry906 and to generate baseband signals for a transmit signal path of theRF circuitry906. Thebaseband circuitry910 is configured to interface withapplication circuitry605/705 (seeFIGS. 6 and 7) for generation and processing of the baseband signals and for controlling operations of theRF circuitry906. Thebaseband circuitry910 may handle various radio control functions.
• The aforementioned circuitry and/or control logic of thebaseband circuitry910 may include one or more single or multi-core processors. For example, the one or more processors may include a3G baseband processor904A, a 4G/LTE baseband processor904B, a 5G/NR baseband processor904C, or some other baseband processor(s)904D for other existing generations, generations in development or to be developed in the future (e.g., 6G, etc.). In other embodiments, some or all of the functionality ofbaseband processors904A-D may be included in modules stored in the memory904G and executed via aCPU904E. In other embodiments, some or all of the functionality ofbaseband processors904A-D may be provided as hardware accelerators (e.g., FPGAs, ASICs, etc.) loaded with the appropriate bit streams or logic blocks stored in respective memory cells. In various embodiments, the memory904G may store program code of a real-time OS(RTOS), which when executed by theCPU904E (or other baseband processor), is to cause theCPU904E (or other baseband processor) to manage resources of thebaseband circuitry910, schedule tasks, etc. Examples of the RTOS may include Operating System Embedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by Mentor Graphics®, Versatile Real-Time Executive (VRTX) provided by Mentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or any other suitable RTOS, such as those discussed herein. In addition, thebaseband circuitry910 includes one or moreaudio DSPs904F. The audio DSP(s)904F include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.
• In some embodiments, each of theprocessors904A-904E include respective memory interfaces to send/receive data to/from the memory904G. Thebaseband circuitry910 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as an interface to send/receive data to/from memory external to thebaseband circuitry910; an application circuitry interface to send/receive data to/from theapplication circuitry605/705 ofFIGS. 6 and 7); an RF circuitry interface to send/receive data to/fromRF circuitry906 ofFIG. 9; a wireless hardware connectivity interface to send/receive data to/from one or more wireless hardware elements (e.g., NFC components, Bluetooth®/Bluetooth® Low Energy components, Wi-Fi® components, and/or the like); and a power management interface to send/receive power or control signals to/from thePMIC725.
• In alternate embodiments (which may be combined with the above described embodiments),baseband circuitry910 comprises one or more digital baseband systems, which are coupled with one another via an interconnect subsystem and to a CPU subsystem, an audio subsystem, and an interface subsystem. The digital baseband subsystems may also be coupled to a digital baseband interface and a mixed-signal baseband subsystem via another interconnect subsystem. Each of the interconnect subsystems may include a bus system, point-to-point connections, network-on-chip (NOC) structures, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include DSP circuitry, buffer memory, program memory, speech processing accelerator circuitry, data converter circuitry such as analog-to-digital and digital-to-analog converter circuitry, analog circuitry including one or more of amplifiers and filters, and/or other like components. In an aspect of the present disclosure,baseband circuitry910 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and/or radio frequency circuitry (e.g., the radio front end modules915).
• Although not shown byFIG. 9, in some embodiments, thebaseband circuitry910 includes individual processing device(s) to operate one or more wireless communication protocols (e.g., a “multi-protocol baseband processor” or “protocol processing circuitry”) and individual processing device(s) to implement PHY layer functions. In these embodiments, the PHY layer functions include the aforementioned radio control functions. In these embodiments, the protocol processing circuitry operates or implements various protocol layers/entities of one or more wireless communication protocols. In a first example, the protocol processing circuitry may operate LTE protocol entities and/or 5G/NR protocol entities when thebaseband circuitry910 and/orRF circuitry906 are part of mmWave communication circuitry or some other suitable cellular communication circuitry. In the first example, the protocol processing circuitry would operate MAC, RLC, PDCP, SDAP, RRC, and NAS functions. In a second example, the protocol processing circuitry may operate one or more IEEE-based protocols when thebaseband circuitry910 and/orRF circuitry906 are part of a Wi-Fi communication system. In the second example, the protocol processing circuitry would operate Wi-Fi MAC and LLC functions. The protocol processing circuitry may include one or more memory structures (e.g.,904G) to store program code and data for operating the protocol functions, as well as one or more processing cores to execute the program code and perform various operations using the data. Thebaseband circuitry910 may also support radio communications for more than one wireless protocol.
• The various hardware elements of thebaseband circuitry910 discussed herein may be implemented, for example, as a solder-down substrate including one or more integrated circuits (ICs), a single packaged IC soldered to a main circuit board or a multi-chip module containing two or more ICs. In one example, the components of thebaseband circuitry910 may be suitably combined in a single chip or chipset, or disposed on a same circuit board. In another example, some or all of the constituent components of thebaseband circuitry910 andRF circuitry906 may be implemented together such as, for example, a system on a chip (SoC) or System-in-Package (SiP). In another example, some or all of the constituent components of thebaseband circuitry910 may be implemented as a separate SoC that is communicatively coupled with and RF circuitry906 (or multiple instances of RF circuitry906). In yet another example, some or all of the constituent components of thebaseband circuitry910 and theapplication circuitry605/705 may be implemented together as individual SoCs mounted to a same circuit board (e.g., a “multi-chip package”).
• In some embodiments, thebaseband circuitry910 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, thebaseband circuitry910 may support communication with an E-UTRAN or other WMAN, a WLAN, a WPAN. Embodiments in which thebaseband circuitry910 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
• RF circuitry906 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, theRF circuitry906 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.RF circuitry906 may include a receive signal path, which may include circuitry to down-convert RF signals received from theFEM circuitry908 and provide baseband signals to thebaseband circuitry910.RF circuitry906 may also include a transmit signal path, which may include circuitry to up-convert baseband signals provided by thebaseband circuitry910 and provide RF output signals to theFEM circuitry908 for transmission.
• In some embodiments, the receive signal path of theRF circuitry906 may include mixer circuitry906a, amplifier circuitry906band filter circuitry906c. In some embodiments, the transmit signal path of theRF circuitry906 may include filter circuitry906cand mixer circuitry906a.RF circuitry906 may also include synthesizer circuitry906dfor synthesizing a frequency for use by the mixer circuitry906aof the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry906aof the receive signal path may be configured to down-convert RF signals received from theFEM circuitry908 based on the synthesized frequency provided by synthesizer circuitry906d. The amplifier circuitry906bmay be configured to amplify the down-converted signals and the filter circuitry906cmay be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to thebaseband circuitry910 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry906aof the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.
• In some embodiments, the mixer circuitry906aof the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry906dto generate RF output signals for theFEM circuitry908. The baseband signals may be provided by thebaseband circuitry910 and may be filtered by filter circuitry906c. In some embodiments, the mixer circuitry906aof the receive signal path and the mixer circuitry906aof 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 circuitry906aof the receive signal path and the mixer circuitry906aof the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry906aof the receive signal path and the mixer circuitry906aof the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry906aof the receive signal path and the mixer circuitry906aof the transmit signal path may be configured for super-heterodyne operation.
• In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, theRF circuitry906 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and thebaseband circuitry910 may include a digital baseband interface to communicate with theRF circuitry906.
• In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect. In some embodiments, the synthesizer circuitry906dmay be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry906dmay be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. The synthesizer circuitry906dmay be configured to synthesize an output frequency for use by the mixer circuitry906aof theRF circuitry906 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry906dmay be a fractional N/N+1 synthesizer. In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either thebaseband circuitry910 or theapplication circuitry605/705 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by theapplication circuitry605/705.
• Synthesizer circuitry906dof theRF circuitry906 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus 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 either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle. In some embodiments, synthesizer circuitry906dmay 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 divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, theRF circuitry906 may include an IQ/polar converter.
• FEM circuitry908 may include a receive signal path, which may include circuitry configured to operate on RF signals received fromantenna array911, amplify the received signals and provide the amplified versions of the received signals to theRF circuitry906 for further processing.FEM circuitry908 may also include a transmit signal path, which may include circuitry configured to amplify signals for transmission provided by theRF circuitry906 for transmission by one or more of antenna elements ofantenna array911. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in theRF circuitry906, solely in theFEM circuitry908, or in both theRF circuitry906 and theFEM circuitry908. In some embodiments, theFEM circuitry908 may include a TX/RX switch to switch between transmit mode and receive mode operation. TheFEM circuitry908 may include a receive signal path and a transmit signal path. The receive signal path of theFEM circuitry908 may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry906). The transmit signal path of theFEM circuitry908 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry906), and one or more filters to generate RF signals for subsequent transmission by one or more antenna elements of theantenna array911.
• Theantenna array911 comprises one or more antenna elements, each of which is configured convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. For example, digital baseband signals provided by thebaseband circuitry910 is converted into analog RF signals (e.g., modulated waveform) that will be amplified and transmitted via the antenna elements of theantenna array911 including one or more antenna elements (not shown). The antenna elements may be omnidirectional, direction, or a combination thereof. The antenna elements may be formed in a multitude of arranges as are known and/or discussed herein. Theantenna array911 may comprise microstrip antennas or printed antennas that are fabricated on the surface of one or more printed circuit boards. Theantenna array911 may be formed in as a patch of metal foil (e.g., a patch antenna) in a variety of shapes, and may be coupled with theRF circuitry906 and/orFEM circuitry908 using metal transmission lines or the like.
• Processors of theapplication circuitry605/705 and processors of thebaseband circuitry910 may be used to execute elements of one or more instances of a protocol stack. For example, processors of thebaseband circuitry910, alone or in combination, may be used executeLayer 3,Layer 2, orLayer 1 functionality, while processors of theapplication circuitry605/705 may utilize data (e.g., packet data) received from these layers and further executeLayer 4 functionality (e.g., TCP and UDP layers). As referred to herein,Layer 3 may comprise a RRC layer, described in further detail below. As referred to herein,Layer 2 may comprise a MAC layer, an RLC layer, and a PDCP layer, described in further detail below. As referred to herein,Layer 1 may comprise a PHY layer of a UE/RAN node, described in further detail infra.
• FIG. 10 illustrates various protocol functions that may be implemented in a wireless communication device according to various embodiments. In particular,FIG. 10 includesprotocol stack1000 showing interconnections between various protocol layers/entities. The following description ofFIG. 10 is provided for various protocol layers/entities that operate in conjunction with the 5G/NR system standards and LTE system standards, but some or all of the aspects ofFIG. 10 may be applicable to other wireless communication network systems as well. The protocol layers ofprotocol stack1000 may include one or more ofPHY1010,MAC1020,RLC1030,PDCP1040,SDAP1047,RRC1055, andNAS1057, in addition to other higher layer functions not illustrated. The protocol layers may include one or more service access points (e.g.,items1059,1056,1050,1049,1045,1035,1025, and1015 inFIG. 10) that may provide communication between two or more protocol layers.
• ThePHY1010 may transmit and receivephysical layer signals1005 that may be received from or transmitted to one or more other communication devices. Thephysical layer signals1005 may comprise one or more physical channels, such as those discussed herein. ThePHY1010 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as theRRC1055. ThePHY1010 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and MIMO antenna processing. In embodiments, an instance ofPHY1010 may process requests from and provide indications to an instance ofMAC1020 via one or more PHY-SAP1015. According to some embodiments, requests and indications communicated via PHY-SAP1015 may comprise one or more transport channels.
• Instance(s) ofMAC1020 may process requests from, and provide indications to, an instance ofRLC1030 via one or more MAC-SAPs1025. These requests and indications communicated via the MAC-SAP1025 may comprise one or more logical channels. TheMAC1020 may perform mapping between the logical channels and transport channels, multiplexing of MAC SDUs from one or more logical channels onto TBs to be delivered toPHY1010 via the transport channels, de-multiplexing MAC SDUs to one or more logical channels from TBs delivered from thePHY1010 via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through HARQ, and logical channel prioritization.
• Instance(s) ofMAC1020 may also perform a RAN-assisted codec adaptation or ANBR (also referred to as a “recommended bit rate procedure”). The recommended bit rate procedure is used to provide theMAC1020 implemented by a UE101 with information about the bit rate (e.g., for PHY1010) which the RAN node111 (e.g., eNB or gNB) recommends. An averaging window of default value 2000 ms may apply as specified in 3GPP TS 26.114. The RAN node111 may transmit the recommended bit rate MAC CE (see e.g.,FIG. 11) to theMAC1020 of the UE101 to indicate the recommended bit rate for the UE101 for a specific logical channel and a specific direction (either uplink or downlink). Upon reception of a recommended bit rate MAC CE, theMAC1020 may indicate, to upper layers, the recommended bit rate for the indicated logical channel and direction. TheMAC1020 may request the RAN node111 to indicate the recommended bit rate for a specific logical channel and a specific direction. If theMAC1020 is requested by upper layers to query the RAN node111 for the recommended bit rate for a logical channel and for a direction (e.g., for uplink or downlink), theMAC1020 may trigger a recommended bit rate query for the logical channel, direction, and desired bit rate if/when a recommended bit rate query for the logical channel and direction has not been triggered. If theMAC1020 has UL resources allocated for new transmission theMAC1020 may, for each recommended bit rate query that the recommended bit rate procedure determines has been triggered and not cancelled, instruct the multiplexing and assembly entity within theMAC1020 to generate the recommended bit rate MAC CE for the logical channel and the direction of the recommended bit rate query; start the bitRateQueryProhibitTimer for the logical channel and the direction of the recommended bit rate query; and cancel the recommended bit rate query when the bitRateQueryProhibitTimer for the logical channel and the direction of the recommended bit rate query is configured, and it is not running, and when theMAC1020 has UL resources allocated for new transmission and the allocated UL resources can accommodate a recommended bit rate MAC CE plus its subheader as a result of LCP.
• FIG. 11 depicts an example recommended bitrate MAC CE1100A and an example recommended bitrate MAC CE1100B according to various embodiments. TheMAC CE1100A is used to convey recommended bit rate queries and recommended bit rate messages in LTE implementations and theMAC CE1100B is used to convey recommended bit rate queries and recommended bit rate messages in NR implementations. Recommended bit rate messages are used to indicate the recommended bit rate for the UE101 for a specific logical channel and a specific direction (either UL or DL). Recommended bit rate queries are used to query or otherwise request a recommended bit rate for a specific logical channel and a specific direction from the RAN node111. Recommended bit rate queries are also used to indicate a desired bit rate or radio level adaptation.
• The recommended bitrate MAC CEs1100A-B are each identified by a MAC PDU subheader with a first LCID value for bit rate recommendation message from the RAN node111 to the UE101 (e.g., over the DL-SCH) and a second LCID value for a bit rate recommendation query message from the UE101 to the RAN node111 (e.g., over an UL-SCH). For LTE implementations, the first LCID value may be “10110,” and the second LCID value may be “10100.” For NR implementations, the first LCID value may be “47,” and the second LCID value may be “53.” TheMAC CEs1100A-B may each have a fixed size and may include two octets. For eachMAC CE1100A-B the first octet (oct 1) includes an LCID field, Uplink/Downlink (UL/DL) field, and part of a bit rate field; and the second octet (oct 2) includes a remaining portion of the bit rat field and a plurality of reserved bit (R) fields. The LCID field indicates the identity of the logical channel for which the recommended bit rate or the recommended bit rate query is applicable. The length of the LCID field is 4 bits forMAC CE1100A and the LCID field forMAC CE1100B is 6 bits. The UL/DL field indicates whether the recommended bit rate or the recommended bit rate query applies to uplink or downlink. For bothMAC CE1100A and1100B the length of the UL/DL field is 1 bit. For bothMAC CE1100A and1100B the UL/DL field is set to “0” to indicate downlink and set to “1” to indicate uplink. The bit rate field indicates a value of the recommended bit rate for the bit rate recommendation message, and indicates a value of a desired bit rate for the bit rate recommendation query. For bothMAC CE1100A and1100B the length of the bit rate field is 6 bits. Each of the R fields includes a reserved bit, which is/are set to “0”.
• Referring back toFIG. 10, instance(s) ofRLC1030 may process requests from and provide indications to an instance ofPDCP1040 via one or more radio link control service access points (RLC-SAP)1035. These requests and indications communicated via RLC-SAP1035 may comprise one or more RLC channels. TheRLC1030 may operate in a plurality of modes of operation, including: TM, UM, and AM. TheRLC1030 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. TheRLC1030 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.
• Instance(s) ofPDCP1040 may process requests from and provide indications to instance(s) ofRRC1055 and/or instance(s) ofSDAP1047 via one or more packet data convergence protocol service access points (PDCP-SAP)1045. These requests and indications communicated via PDCP-SAP1045 may comprise one or more radio bearers. ThePDCP1040 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).
• Instance(s) ofSDAP1047 may process requests from and provide indications to one or more higher layer protocol entities via one or more SDAP-SAP1049. These requests and indications communicated via SDAP-SAP1049 may comprise one or more QoS flows. TheSDAP1047 may map QoS flows to DRBs, and vice versa, and may also mark QFIs in DL and UL packets. Asingle SDAP entity1047 may be configured for an individual PDU session. In the UL direction, the NG-RAN110 may control the mapping of QoS Flows to DRB(s) in two different ways, reflective mapping or explicit mapping. For reflective mapping, theSDAP1047 of a UE101 may monitor the QFIs of the DL packets for each DRB, and may apply the same mapping for packets flowing in the UL direction. For a DRB, theSDAP1047 of the UE101 may map the UL packets belonging to the QoS flows(s) corresponding to the QoS flow ID(s) and PDU session observed in the DL packets for that DRB. To enable reflective mapping, the NG-RAN110 may mark DL packets over the Uu interface with a QoS flow ID. The explicit mapping may involve theRRC1055 configuring theSDAP1047 with an explicit QoS flow to DRB mapping rule, which may be stored and followed by theSDAP1047. In embodiments, theSDAP1047 may only be used in NR implementations and may not be used in LTE implementations.
• TheRRC1055 may configure, via one or more management service access points (M-SAP), aspects of one or more protocol layers, which may include one or more instances ofPHY1010,MAC1020,RLC1030,PDCP1040 andSDAP1047. In embodiments, an instance ofRRC1055 may process requests from and provide indications to one ormore NAS entities1057 via one or more RRC-SAPs1056. The main services and functions of theRRC1055 may include broadcast of system information (e.g., included in MIBs or SIBs related to the NAS), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE101 and RAN110 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. The MIBs and SIBs may comprise one or more IEs, which may each comprise individual data fields or data structures.
• According to various embodiments,RRC1055 is used to configure the UE101 with specific parameters, and for the UE101 to provide the network with UE-specific parameters. For example, theRRC1055 of a RAN node111 may transmit a suitable RRC message (e.g., RRC connection reconfiguration message, RRC setup message during an RRC connection establishment procedure, or the like) to the UE101, where the RRC message includes one or more IEs, which is a structural element containing one or more fields where each field includes parameters, content, and/or data. The parameters, content, and/or data included in the one or more fields of the IEs are used to configure the UE101 to operate in a particular manner. Additionally, the UE101 may send a suitable RRC message to indicate supported radio capabilities, and to request a change to one or more radio link parameters as discussed herein.
• As an example, a UE assistance information (UEAssistanceInformation) message may be used to indicate UE assistance information to the network, such as aRAN110. The purpose of the UEAssistanceInformation procedure for LTE implementations is to inform an E-UTRAN110 of the UE's101 power saving preference and SPS assistance information, maximum PDSCH/PUSCH bandwidth configuration preference, overheating assistance information, or the UE's101 delay budget report carrying desired increment/decrement in the Uu air interface delay or connected mode DRX cycle length and for BL UEs or UEs in CE of the RLM event (“early-out-of-sync” or “early-in-sync”) and RLM information. Upon configuring the UE101 to provide power preference indications, the E-UTRAN110 may consider that the UE101 does not prefer a configuration primarily optimized for power saving until the UE101 explicitly indicates otherwise. Table 4 shows an example LTE-based UEAssistanceInformation message, and table 5 shows field descriptions for the LTE-based UEAssistanceInformation message.

• TABLE 4
  UEAssistanceInformation message (LTE implementations)

  -- ASN1START

  UEAssistanceInformation-r11 ::=

  SEQUENCE {

  criticalExtensions

  CHOICE {

  c1

  CHOICE {

  ueAssistanceInformation-r11

  UEAssistanceInformation-r11-IEs,

  spare3 NULL, spare2 NULL, spare1 NULL

  },

  criticalExtensionsFuture

  SEQUENCE { }

  }

  }

  UEAssistanceInformation-r11-IEs ::=

  SEQUENCE {

  powerPrefIndication-r11

  ENUMERATED {normal, lowPowerConsumption}

  OPTIONAL,

  lateNonCriticalExtension

  OCTET STRING

  OPTIONAL,

  nonCriticalExtension

  UEAssistanceInformation-v1430-IEs

  OPTIONAL

  }

  UEAssistanceInformation-v1430-IEs ::=

  SEQUENCE {

  bw-Preference-r14

  BW-Preference-r14

  OPTIONAL,

  sps-AssistanceInformation-r14

  SEQUENCE {

  	trafficPatternInfoListSL-r14	TrafficPatternInfoList-r14	OPTIONAL,
  	trafficPatternInfoListUL-r14	TrafficPatternInfoList-r14	OPTIONAL

  }

  OPTIONAL,

  rlm-Report-r14

  SEQUENCE {

  rlm-Event-r14

  ENUMERATED {earlyOutOfSync, earlyInSync},

  excessRep-MPDCCH-r14

  ENUMERATED {excessRep1, excessRep2}

  OPTIONAL

  }

  OPTIONAL,

  delayBudgetReport-r14

  DelayBudgetReport-r14

  OPTIONAL,

  nonCriticalExtension

  UEAssistanceInformation-v1450-IEs

  OPTIONAL

  }

  UEAssistanceInformation-v1450-IEs ::=

  SEQUENCE {

  	overheatingAssistance-r14	OverheatingAssistance-r14	OPTIONAL,
  	nonCriticalExtension	UEAssistanceInformation-v1530-IEs	OPTIONAL

  }

  UEAssistanceInformation-v1530-IEs ::=

  SEQUENCE {

  sps-AssistanceInformation-v1530

  SEQUENCE {

  trafficPatternInfoListSL-v1530

  TrafficPatternInfoList-v1530

  }

  OPTIONAL,

  nonCriticalExtension

  SEQUENCE { }

  OPTIONAL

  }

  BW-Preference-r14 ::= SEQUENCE {

  dl-Preference-r14

  ENUMERATED

  {mhz1dot4, mhz5, mhz20 }

  OPTIONAL,

  ul-Preference-r14

  ENUMERATED

  {mhz1dot4, mhz5}

  OPTIONAL

  }

  TrafficPatternInfoList-r14 ::= SEQUENCE (SIZE (1..maxTrafficPattern-r14)) OF TrafficPatternInfo-r14

  TrafficPatternInfo-r14 ::=

  SEQUENCE {

  trafficPeriodicity-r14

  ENUMERATED {

  	sf20, sf50, sf100, sf200, sf300, sf400, sf500,
  	sf600, sf700, sf800, sf900, sf1000},

  timingOffset-r14

  INTEGER (0..10239),

  	priorityInfoSL-r14	SL-Priority-r13	OPTIONAL,
  	logicalChannelIdentityUL-r14	INTEGER (3..10)	OPTIONAL,

  messageSize-r14

  BIT STRING (SIZE (6))

  }

  TrafficPatternInfoList-v1530 ::= SEQUENCE (SIZE (1..maxTrafficPattern-r14)) OF TrafficPatternInfo-v1530

  TrafficPatternInfo-v1530 ::=SEQUENCE {

  	trafficDestination-r15	SL-DestinationIdentity-r12	OPTIONAL,
  	reliabilityInfoSL-r15	SL-Reliability-r15	OPTIONAL

  }

  DelayBudgetReport-r14::=

  CHOICE {

  type1

  ENUMERATED {

  	msMinus1280, msMinus640, msMinus320, msMinus160,
  	msMinus80, msMinus60, msMinus40, msMinus20, ms0,

  ms20,

  ms40, ms60, ms80, ms160, ms320, ms640,

  ms1280},

  type2

  ENUMERATED {

  	msMinus192, msMinus168,msMinus144, msMinus120,
  	msMinus96, msMinus72, msMinus48, msMinus24, ms0,

  ms24,

  ms48, ms72, ms96, ms120, ms144, ms168, ms192}

  }

  OverheatingAssistance-r14 ::=

  SEQUENCE {

  reducedUE-Category

  SEQUENCE {

  	reducedUE-CategoryDL	INTEGER (0..19),
  	reducedUE-CategoryUL	INTEGER (0..21)

  }

  OPTIONAL,

  reducedMaxCCs

  SEQUENCE {

  	reducedCCsDL	INTEGER (0..31),
  	reducedCCsUL	INTEGER (0..31)

  }

  OPTIONAL

  }

  -- ASN1STOP

• TABLE 5
  UEAssistanceInformation field descriptions (LTE implementations)
  UEAssistanceInformation field descriptions

  delayBudgetReport

  Indicates the UE-preferred adjustment to connected mode DRX or cover-

  age enhancement configuration.

  dl-Preference

  Indicates UE's preference on configuration of maximum PDSCH band-

  width. The value mhz1dot4 corresponds to CE mode usage in 1.4MHz

  bandwidth, mhz5 corresponds to CE mode usage in 5MHz bandwidth,

  and mhz20 corresponds to CE mode usage in 20MHz bandwidth or nor-

  mal coverage.

  excessRep-MPDCCH

  Indicates the excess number of repetitions on MPDCCH. Value

  excessRep1 and excessRep2 indicate the excess number of repetitions

  defined in TS 36.133.

  logicalChannelldentityUL

  Indicates the logical channel identity associated with the reported traffic

  pattern in the uplink logical channel.

  messageSize

  Indicates the maximum TB size based on the observed traffic pattern.

  The value refers to the index of TS 36.321, table 6.1.3.1-1.

  powerPrefIndication

  Value lowPowerConsumption indicates the UE prefers a configuration

  that is primarily optimised for power saving. Otherwise the value is set

  to normal.

  priorityInfoSL

  Indicates the traffic priority (i.e., PPPP) associated with the reported

  traffic pattern for V2X SL communication.

  reducedCCsDL

  Indicates the UE's preference on reduced configuration corresponding

  to the maximum number of downlink SCells indicated by the field, to

  address overheating. This maximum number includes both SCells of

  E-UTRA and PSCell/SCells of NR in EN-DC.

  reducedCCsUL

  Indicates the UE's preference on reduced configuration corresponding

  to the maximum number of uplink SCells indicated by the field, to

  address overheating. This maximum number includes both SCells of

  E-UTRA and PSCell/SCells of NR in EN-DC.

  reducedUE-CategoryDL, reducedUE-CategoryUL

  Indicates that UE prefers a configuration corresponding to the reduced

  UE category, to address overheating. The reduced UE DL category and

  reduced UE UL category should be indicated according to supported

  combinations for UE UL and DL Categories, see TS 36.306, Table

  4.1A-6.

  reliabilityInfoSL

  Indicates the traffic reliability (i.e., PPPR) associated with the reported

  traffic pattern for V2X SL communication.

  rim-Event

  This field provides the RLM event (“early-out-of-sync” or “early-in-

  sync”).

  rim-Report

  This field provides the RLM report for BL UEs and UEs in CE.

  sps-AssistanceInformation

  Indicates the UE assistance information to assist E-UTRAN to

  configure SPS.

  timingOffset

  This field indicates the estimated timing for a packet arrival in a SL/UL

  logical channel. Specifically, the value indicates the timing offset with

  respect tosubframe#0 ofSFN#0 in milliseconds.

  trafficDestination

  Indicates the destination associated with the reported traffic pattern for

  V2X SL communication.

  trafficPatternInfoListSL

  This field provides the traffic characteristics of SL logical channel(s)

  that are setup for V2X SL communication. If trafficPatternInfoListSL-

  v1530 is included, it includes the same number of entries, and listed in

  the same order, as in trafficPatternInfoListSL-r14.

  trafficPatternInfoListUL

  This field provides the traffic characteristics of uplink logical channel(s).

  trafficPeriodicity

  This field indicates the estimated data arrival periodicity in a SL/UL

  logical channel. Value sf20 corresponds to 20 ms, sf50 corresponds to

  50 ms and so on.

  type1

  Indicates the preferred amount of increment/decrement to the connected

  mode DRX cycle length with respect to the current configuration. Value

  in number of milliseconds. Value ms40 corresponds to 40 milliseconds,

  msMinus40 corresponds to −40 milliseconds and so on.

  type2

  Indicates the preferred amount of increment/decrement to the coverage

  enhancement configuration with respect to the current configuration so

  that the Uu air interface delay changes by the indicated amount. Value

  in number of milliseconds. Value ms24 corresponds to 24 milliseconds,

  msMinus24 corresponds to −24 milliseconds and so on.

  ul-Preference

  Indicates UE's preference on configuration of maximum PUSCH band-

  width. The value mhz1dot4 corresponds to CE mode usage in 1.4MHz

  bandwidth, and mhz5 corresponds to CE mode usage in 5MHz band-

  width.

• When the UE101 is capable of providing power preference indications in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure in several cases including upon being configured to provide power preference indications and upon change of power preference. When the UE101 is capable of providing SPS assistance information in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure in several cases including upon being configured to provide SPS assistance information and upon change of SPS assistance information. When the UE101 is capable of providing delay budget report in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure in several cases, including upon being configured to provide delay budget report and upon change of delay budget preference. When the UE101 is capable of CE mode and providing maximum PDSCH/PUSCH bandwidth preference in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure upon being configured to provide maximum PDSCH/PUSCH bandwidth preference and/or upon change of maximum PDSCH/PUSCH bandwidth preference. When the UE101 is capable of providing overheating assistance information in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure if it was configured to do so, upon detecting internal overheating, or upon detecting that it is no longer experiencing an overheating condition. In LTE implementations, the UEAssistanceInformation message may be included in an UL-DCCH-Message. The UL-DCCH-Message class is the set of RRC messages that may be sent from the UE to the E-UTRAN or from the RN to the E-UTRAN on the uplink DCCH logical channel. An example LTE-based UL-DCCH-Message is shown by table 6.

• TABLE 6
  UL-DCCH-Message (LTE implementations)

  -- ASN1START

  UL-DCCH-Message ::= SEQUENCE {

  message

  UL-DCCH-MessageType

  }

  UL-DCCH-MessageType ::= CHOICE {

  c1

  CHOICE {

  	csfbParametersRequestCDMA2000	CSFBParametersRequestCDMA2000,
  	measurementReport	MeasurementReport,

  	rrcConnectionReconfigurationComplete	RRCConnectionReconfigurationComplete,
  	rrcConnectionReestablishmentComplete	RRCConnectionReestablishmentComplete,

  rrcConnectionSetupComplete

  RRCConnectionSetupComplete,

  securityModeComplete

  SecurityModeComplete,

  	securityModeFailure	SecurityModeFailure,
  	ueCapabilityInformation	UECapabilityInformation,

  	ulHandoverPreparationTransfer	ULHandoverPreparationTransfer,
  	ulInformationTransfer	ULInformationTransfer,
  	counterCheckResponse	CounterCheckResponse,
  	ueInformationResponse-r9	UEInformationResponse-r9,
  	proximityIndication-r9	ProximityIndication-r9,
  	mReconfigurationComplete-r10	RNReconfigurationComplete-r10,

  	mbmsCountingResponse-r10	MBMSCountingResponse-r10,
  	interFreqRSTDMeasurementIndication-r10	InterFreqRSTDMeasurementIndication-r10

  	},
  	messageClassExtensionCHOICE {

  c2

  CHOICE {

  ueAssistanceInformation-r11

  UEAssistanceInformation-r11,

  	inDeviceCoexIndication-r11	InDeviceCoexIndication-r11,
  	mbmsInterestIndication-r11	MBMSInterestIndication-r11,
  	scgFailureInformation-r12	SCGFailureInformation-r12,
  	sidelinkUEInformation-r12	SidelinkUEInformation-r12,
  	wlanConnectionStatusReport-r13	WLANConnectionStatusReport-r13,

  	rrcConnectionResumeComplete-r13	RRCConnectionResumeComplete-r13,
  	ulInformationTransferMRDC-r15	ULInformationTransferMRDC-r15,
  	scgFailureInformationNR-r15	SCGFailureInformationNR-r15,
  	measReportAppLayer-r15	MeasReportAppLayer-r15,

  failureInformation-r15

  FailureInformation-r15,

  spare5 NULL, spare4 NULL, spare3 NULL, spare2 NULL, spare1 NULL

  	},
  	messageClassExtensionFuture-r11 SEQUENCE { }

  }

  }

  -- ASN1STOP

• The purpose of the UEAssistanceInformation procedure for NR implementations is to inform the network of the UE's101/101 delay budget report carrying desired increment/decrement in the Uu air interface delay, connected mode DRX cycle length or overheating assistance information. Table 7 shows an example NR-based UEAssistanceInformation message, and table 8 shows field descriptions for the NR-based UEAssistanceInformation message.

• TABLE 7
  UEAssistanceInformation message (NR implementations)

  -- ASN1START

  -- TAG-UEASSISTANCEINFORMATION-START

  UEAssistanceInformation ::=

  SEQUENCE {

  criticalExtensions

  CHOICE {

  ueAssistanceInformation

  UEAssistanceInformation-IEs,

  criticalExtensionsFuture

  SEQUENCE { }

  }

  }

  UEAssistanceInformation-IEs ::=

  SEQUENCE {

  delayBudgetReport

  DelayBudgetReport

  OPTIONAL,

  lateNonCriticalExtension

  OCTET STRING

  OPTIONAL,

  nonCriticalExtension

  UEAssistanceInformation-v1540-IEs OPTIONAL

  }

  DelayBudgetReport::=

  CHOICE {

  type1

  ENUMERATED {

  	msMinus1280, msMinus640, msMinus320, msMinus160,msMinus80, msMinus60, msMinus40,
  	msMinus20, ms0, ms20,ms40, ms60, ms80, ms160, ms320, ms640, ms1280},

  ...

  }

  UEAssistanceInformation-v1540-IEs ::= SEQUENCE {

  overheatingAssistance

  OverheatingAssistance

  OPTIONAL,

  nonCriticalExtension

  SEQUENCE { }

  OPTIONAL

  }

  OverheatingAssistance ::=

  SEQUENCE {

  reducedMaxCCs

  SEQUENCE {

  	reducedCCsDL	INTEGER (0..31),
  	reducedCCsUL	INTEGER (0..31)

  } OPTIONAL,

  reducedMaxBW-FR1

  SEQUENCE {

  	reducedBW-FR1-DL	ReducedAggregatedBandwidth,
  	reducedBW-FR1-UL	ReducedAggregatedBandwidth

  } OPTIONAL,

  reducedMaxBW-FR2

  SEQUENCE {

  	reducedBW-FR2-DL	ReducedAggregatedBandwidth,
  	reducedBW-FR2-UL	ReducedAggregatedBandwidth

  } OPTIONAL,

  reducedMaxMIMO-LayersFR1

  SEQUENCE {

  	reducedMIMO-LayersFR1-DL	MIMO-LayersDL,
  	reducedMIMO-LayersFR1-UL	MIMO-LayersUL

  } OPTIONAL,

  reducedMaxMIMO-LayersFR2

  SEQUENCE {

  	reducedMIMO-LayersFR2-DL	MIMO-LayersDL,
  	reducedMIMO-LayersFR2-UL	MIMO-LayersUL

  } OPTIONAL

  }

  ReducedAggregatedBandwidth ::= ENUMERATED {mhz0, mhz10, mhz20, mhz30, mhz40, mhz50, mhz60,

  mhz80, mhz100, mhz200, mhz300, mhz400}

  -- TAG-UEASSISTANCEINFORMATION-STOP

  -- ASN1STOP

• TABLE 8
  UEAssistanceInformation field descriptions (NR implementations)
  UEAssistanceInformation field descriptions

  delayBudgetReport

  Indicates the UE-preferred adjustment to connected mode DRX.

  reducedBW-FR1-DL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum aggregated bandwidth across all downlink carriers of FR1

  indicated by the field, to address overheating. This field is allowed to be

  reported only when UE is configured with serving cells operating on FR1.

  reducedBW-FR1-UL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum aggregated bandwidth across all uplink carriers of FR1

  indicated by the field, to address overheating. This field is allowed to be

  reported only when UE is configured with serving cells operating on FR1.

  reducedBW-FR2-DL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum aggregated bandwidth across all downlink carriers of FR2

  indicated by the field, to address overheating. This field is allowed to be

  reported only when UE is configured with serving cells operating on FR2.

  mhz0 is only applicable for FR2.

  reducedBW-FR2-UL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum aggregated bandwidth across all uplink carriers of FR2

  indicated by the field, to address overheating. This field is allowed to be

  reported only when UE is configured with serving cells operating on FR2.

  mhz0 is only applicable for FR2.

  reducedCCsDL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of downlink SCells indicated by the field, to

  address overheating.

  reducedCCsUL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of uplink SCells indicated by the field, to address

  overheating.

  reducedMIMO-LayersFR1-DL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of downlink MIMO layers of each serving cell

  operating on FR1 indicated by the field, to address overheating. This field

  is allowed to be reported only when UE is configured with serving cells

  operating on FR1.

  reducedMIMO-LayersFR1-UL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of uplink MIMO layers of each serving cell

  operating on FR1 indicated by the field, to address overheating. This field

  is allowed to be reported only when UE is configured with serving cells

  operating on FR1.

  reducedMIMO-LayersFR2-DL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of downlink MIMO layers of each serving cell

  operating on FR2 indicated by the field, to address overheating. This field

  is allowed to be reported only when UE is configured with serving cells

  operating on FR2.

  reducedMIMO-LayersFR2-UL

  Indicates the UE's preference on reduced configuration corresponding to

  the maximum number of uplink MIMO layers of each serving cell

  operating on FR2 indicated by the field, to address overheating. This field

  is allowed to be reported only when UE is configured with serving cells

  operating on FR2.

  type1

  Indicates the preferred amount of increment/decrement to the long DRX

  cycle length with respect to the current configuration. Value in number of

  milliseconds. Value ms40 corresponds to 40 milliseconds, msMinus40

  corresponds to −40 milliseconds and so on.

• When the UE101/101 is capable of providing delay budget report in RRC_CONNECTED, the UE101/101 may initiate the UEAssistanceInformation procedure in several cases, including upon being configured to provide delay budget report and upon change of delay budget preference. When the UE101/101 is capable of providing overheating assistance information in RRC_CONNECTED, the UE101/101 may initiate the UEAssistanceInformation procedure if the UE101/101 was configured to do so, upon detecting internal overheating, or upon detecting that it is no longer experiencing an overheating condition. In NR implementations, the UEAssistanceInformation message may be included in an UL-DCCH-Message. The UL-DCCH-Message class is the set of RRC messages that may be sent from the UE to the network on the uplink DCCH logical channel. An example NR-based UL-DCCH-Message is shown by table 9.

• TABLE 9
  UL-DCCH-Message

  -- ASN1START

  -- TAG-UL-DCCH-MESSAGE-START

  UL-DCCH-Message ::=

  SEQUENCE {

  message

  UL-DCCH-MessageType

  }

  UL-DCCH-MessageType ::=

  CHOICE {

  c1

  CHOICE {

  measurementReport

  MeasurementReport,

  rrcReconfigurationComplete

  RRCReconfigurationComplete,

  rrcSetupComplete

  RRCSetupComplete,

  rrcReestablishmentComplete

  RRCReestablishmentComplete,

  rrcResumeComplete

  RRCResumeComplete,

  securityModeComplete

  SecurityModeComplete,

  	securityModeFailure	SecurityModeFailure,
  	ulInformationTransfer	ULInformationTransfer,

  locationMeasurementIndication

  LocationMeasurementIndication,

  	ueCapabilityInformation	UECapabilityInformation,
  	counterCheckResponse	CounterCheckResponse,
  	ueAssistanceInformation	UEAssistanceInformation,

  failureInformation

  FailureInformation,

  	spare3 NULL,
  	spare2 NULL, spare1 NULL

  },

  messageClassExtension

  SEQUENCE { }

  }

  -- TAG-UL-DCCH-MESSAGE-STOP

  -- ASN1STOP

• TheNAS1057 forms the highest stratum of the control plane between the UE101 and the AMF (e.g., over the N1 reference point). TheNAS1057 may support the mobility of the UEs101 and the session management procedures to establish and maintain IP connectivity between the UE101 and a P-GW in LTE systems.
• According to various embodiments, one or more protocol entities ofarrangement1000 may be implemented in UEs101, RAN nodes111, AMF in NR implementations or MME in LTE implementations, UPF in NR implementations or S-GW and P-GW in LTE implementations, or the like to be used for control plane or user plane communications protocol stack between the aforementioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of UE101, gNB111, AMF, etc. may communicate with a respective peer protocol entity that may be implemented in or on another device using the services of respective lower layer protocol entities to perform such communication. In some embodiments, a gNB-CU of the gNB111 may host theRRC1055,SDAP1047, andPDCP1040 of the gNB that controls the operation of one or more gNB-DUs, and the gNB-DUs of the gNB111 may each host theRLC1030,MAC1020, and PHY810 of the gNB111.
• In a first example, a control plane protocol stack may comprise, in order from highest layer to lowest layer,NAS1057,RRC1055,PDCP1040,RLC1030,MAC1020, and PHY1110. In this example,upper layers1060 may be built on top of the NAS857, which includes anIP layer1061, anSCTP1062, and an application layer signaling protocol (AP)1063.
• In NR implementations, theAP1063 may be anNGAP1063 for theNG interface113 defined between the NG-RAN node111 and the AMF, or theAP1063 may be anXnAP1063 for theXn interface112 that is defined between two or more RAN nodes111. TheNGAP1063 may support the functions of theNG interface113 and may comprise Elementary Procedures (EPs). An NGAP EP may be a unit of interaction between the NG-RAN node111 and the AMF. TheNGAP1063 services may comprise two groups: UE-associated services (e.g., services related to a UE101) and non-UE-associated services (e.g., services related to the whole NG interface instance between the NG-RAN node111 and AMF). These services may include functions including, but not limited to: a paging function for the sending of paging requests to NG-RAN nodes111 involved in a particular paging area; a UE context management function for allowing the AMF to establish, modify, and/or release a UE context in the AMF and the NG-RAN node111; a mobility function for UEs101 in ECM-CONNECTED mode for intra-system HOs to support mobility within NG-RAN and inter-system HOs to support mobility from/to EPS systems; a NAS Signaling Transport function for transporting or rerouting NAS messages between UE101 and AMF; a NAS node selection function for determining an association between the AMF and the UE101; NG interface management function(s) for setting up the NG interface and monitoring for errors over the NG interface; a warning message transmission function for providing means to transfer warning messages via NG interface or cancel ongoing broadcast of warning messages; a Configuration Transfer function for requesting and transferring of RAN configuration information (e.g., SON information, performance measurement data, etc.) between two RAN nodes111 viaCN120; and/or other like functions.
• TheXnAP1063 may support the functions of theXn interface112 and may comprise XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may comprise procedures used to handle UE mobility within the NG RAN111 (or E-UTRAN110), such as handover preparation and cancellation procedures, SN Status Transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and the like. The XnAP global procedures may comprise procedures that are not related to a specific UE101, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, and the like.
• In LTE implementations, theAP1063 may be anS1AP1063 for theS1 interface113 defined between an E-UTRAN node111 and an MME, or theAP1063 may be anX2AP1063 for theX2 interface112 that is defined between two or more E-UTRAN nodes111. TheS1AP1063 may support the functions of the S1 interface, and similar to the NGAP discussed previously, the S1AP may comprise S1AP EPs. An S1AP EP may be a unit of interaction between the E-UTRAN node111 and an MME withinEPC120. TheS1AP1063 services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.
• TheX2AP1063 may support the functions of theX2 interface112 and may comprise X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may comprise procedures used to handle UE mobility within theE-UTRAN120, such as handover preparation and cancellation procedures, SN Status Transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and the like. The X2AP global procedures may comprise procedures that are not related to a specific UE101, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, and the like.
• The SCTP layer (alternatively referred to as the SCTP/IP layer)1062 may provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1AP or X2AP messages in LTE implementations). TheSCTP1062 may ensure reliable delivery of signaling messages between the RAN node111 and the AMF/MME based, in part, on the IP protocol, supported by theIP1061. The Internet Protocol layer (IP)1061 may be used to perform packet addressing and routing functionality. In some implementations theIP layer1061 may use point-to-point transmission to deliver and convey PDUs. In this regard, the RAN node111 may comprise L2 and L1 layer communication links (e.g., wired or wireless) with the MME/AMF to exchange information.
• In a second example, a user plane protocol stack may comprise, in order from highest layer to lowest layer,SDAP1047,PDCP1040,RLC1030,MAC1020, andPHY1010. The user plane protocol stack may be used for communication between the UE101, the RAN node111, and UPF in NR implementations or an S-GW and P-GW in LTE implementations. In this example,upper layers1051amay be built on top of theSDAP1047, and may include UDP/IP1052, a GTP-U1053, and a User Plane PDU layer (UP PDU)1063. The transport layer1054 (also referred to as a “transport network layer”) may be built on IP transport. The IP layer (also referred to as the “Internet layer”) may be used to perform packet addressing and routing functionality. The IP layer may assign IP addresses to user data packets in any of IPv4, IPv6, or PPP formats, for example.
• The GTP-U1053 may be used on top of the UDP/IP layer1052 (comprising a UDP layer and IP layer) to carry UP-PDUs. The GTP-U1053 may be used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example. The UDP/IP1052 may provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication on the selected data flows. The RAN node111 and the S-GW may utilize an S1-U interface to exchange user plane data via a protocol stack comprising an L1 layer (e.g., PHY1010), an L2 layer (e.g.,MAC1020,RLC1030,PDCP1040, and/or SDAP1047), the UDP/IP layer1052, and the GTP-U1053. The S-GW and the P-GW may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising an L1 layer, an L2 layer, the UDP/IP layer1052, and the GTP-U1053. As discussed previously, NAS protocols may support the mobility of the UE101 and the session management procedures to establish and maintain IP connectivity between the UE101 and the P-GW.
• In various embodiments, real-time user plane media data is sent over RTP/UDP/IP layers, and non-real-time media may use other transport protocols such as UDP/IP1052 or TCP/IP. In these embodiments,upper layers1051bmay include UDP/IP1052,RTP layer1074, RTCP/SIP/SDP layer1075, one ormode media codecs1076, and conversationalmultimedia application layer1077. In some embodiments,upper layers1051bmay be built on top ofSDAP1047 orPDCP1040. As shown inFIG. 10,RTP1074 and RTCP/SIP/SDP run on top of UDP, but these layers can also run on top of TCP in other embodiments.
• The conversationalmultimedia application layer1077 includes the media application(s) that presents or outputs media to the user. The media codecs1076 may be any of the codecs discussed herein (e.g., speech, video, real-time text, etc.). The RTCP/SIP/SDP1075 involve SIP, SDP, and the SDPCapNeg for session control, media negotiation, and configuration functionality as discussed herein.RTP1074 is used for the transport of packetized media data. RTP provides real-time delivery of media data, including functionalities such as packet sequence numbering and time stamping. The time stamping provides for inter-media synchronization in the receiving MTSI client. RTP may includeRTCP1075, which provides QoS monitoring, where each endpoint receives and sends quality reports from/to the other endpoint including radio capabilities and radio-based reports according to the embodiments herein.
• SIP1075 performs the logical bound between the media streams of two MTSI clients. SIP uses SDP to describe the session properties (e.g., IP addresses, ports, payload formats, type of media (e.g., audio, video, etc.), media codecs, and session bandwidth). Mobile applications based on the IETF SIP can be implemented on top of non-IMS networks. In this case, only the applications resident in mobile terminals run the SIP protocol, while the network considers SIP as transport protocol. In 3GPP IMS networks, where SIP has been selected to govern the core call control mechanism, both the network and the mobile terminal implement the SIP protocol and exchange SIP messages for establishing and releasing calls. This choice has been made to enable the transition towards ALL-IP mobile networks.
• Moreover, although not shown byFIG. 10, an application layer may be present above theAP1063 and/or thetransport network layer1054. The application layer may be a layer in which a user of the UE101, RAN node111, or other network element interacts with software applications being executed, for example, byapplication circuitry605 orapplication circuitry705, respectively. The application layer may also provide one or more interfaces for software applications to interact with communications systems of the UE101 or RAN node111, such as thebaseband circuitry910. In some implementations the IP layer and/or the application layer may provide the same or similar functionality as layers 5-7, or portions thereof, of the Open Systems Interconnection (OSI) model (e.g.,OSI Layer 7—the application layer,OSI Layer 6—the presentation layer, andOSI Layer 5—the session layer).
• FIGS. 12-13 show example procedures1200-1300, respectively, in accordance with various embodiments. For illustrative purposes, the various operations of processes1200-1300 is described as being performed by a local UE101, or elements thereof, with respect to a remote UE101, or elements thereof (e.g., components discussed with regard toplatform700 ofFIG. 7). Additionally, the various messages/signaling communicated between the UEs101 may be sent/received over the various interfaces and between various intermediary nodes as discussed herein with respect toFIGS. 1-11, and using the various mechanisms discussed herein including those discussed herein with respect toFIGS. 1-11. While particular examples and orders of operations are illustratedFIGS. 12-13, the depicted orders of operations should not be construed to limit the scope of the embodiments in any way. Rather, the depicted operations may be re-ordered, broken into additional operations, combined, and/or omitted altogether while remaining within the spirit and scope of the present disclosure.
• FIG. 12 depicts anexample procedure1200 for indicating support of one or more radio capabilities according to various embodiments.Process1200 begins atoperation1205 where the local UE101 identifies one or more capabilities supported by the local UE101. The one or more radio capabilities include one or more of a delay budget reporting capability, a TTI bundling capability, a RAN frame aggregation capability, and a RAN-assisted codec adaptation capability or an ANBR signaling capability. Atoperation1210, the local UE101 generates an SDP message to indicate the one or more radio capabilities. In some embodiments, the SDP message may include a session level attribute “a=RANCapabilities”, where the RANCapabilities includes individual bits to indicate a corresponding one of the one or more radio capabilities. In other embodiments, the SDP message may include an individual session level attribute for each supported radio capability such as “a=anbr” to indicate that the local UE101 supports the ANBR signaling capability. Atoperation1215, the local UE101 transmits the SDP message to aremote UE101bvia a RAN node121. Afteroperation1215,process1200 may end or repeat as necessary.
• FIG. 13 depicts anexample procedure1300 for adjusting a bit rate or bandwidth for consuming media according to various embodiments.Process1300 may be performed by a local UE101.Process1300 begins atoperation1305 where a local UE101 receives an SDP message from a remote UE101, and atoperation1310, the local UE101 identifies one or more capabilities supported by the remote UE101 based on the contents of the SDP message. The one or more radio capabilities include one or more of a delay budget reporting capability, a TTI bundling capability, a RAN frame aggregation capability, and a RAN-assisted codec adaptation capability or an ANBR signaling capability. At operation1315, the local UE101 determines whether a change in radio conditions has been detected, and if not, continues to monitor the radio conditions with its local RAN node111. If the radio conditions have changed, the local UE101 proceeds tooperation1320 to generate an SDP message to request a change of one or more radio link parameters. The particular radio link parameters to be changed, and the extent to which those parameters are changed may depend on the detected radio conditions and the one or more radio capabilities supported by the remote UE101. Atoperation1325, the local UE101 transmits the SDP message to its local RAN node111 to have the radio link parameters changed. In some embodiments, the RAN node111 may send a suitable ACK message to the local UE101 to indicate the changed radio link parameters. Afteroperation1325,process1300 may end or repeat as necessary.
• Some non-limiting examples are as follows. The following examples pertain to further embodiments, and specifics in the examples may be used anywhere in one or more embodiments discussed previously. Any of the following examples may be combined with any other example or any embodiment discussed herein.
• Example 1 includes a method to be performed by a first UE, the method comprising: generating or causing to generate a SDP message to indicate one or more radio capabilities of the first UE; and transmitting or causing to transmit the SDP message to a second UE via a RAN node.
• Example 2 includes the method of example 1 and/or some other example(s) herein, wherein the SDP message is a first SDP message, the one or more radio capabilities of the first UE are first radio capabilities, and the method comprises: identifying or causing to identify one or more second radio capabilities of the second UE within a second SDP message obtained from the second UE; and determining or causing to determine one or more desired radio level adaptations based on the one or more second radio capabilities.
• Example 3 includes the method of example 2 and/or some other example(s) herein, wherein the method comprises: determining or causing to determine the one or more desired radio level adaptations based on the one or more second radio capabilities and based on detected radio conditions.
• Example 4 includes the method of example 3 and/or some other example(s) herein, wherein the detected radio conditions are one or both of conditions of a radio link between the first UE and the RAN node and conditions of a radio link between the second UE and another RAN node.
• Example 5 includes the method of examples 3-4 and/or some other example(s) herein, wherein the method comprises: generating or causing to generate an RRC message to indicate a desired radio level adaptation; and transmitting or causing to transmit the RRC message to the RAN node. Example 6 includes the method of example 5 and/or some other example(s) herein, wherein the desired radio level adaptation is to turn off cDRX when the one or more second radio capabilities indicate support of DBI signaling and TTI bundling, the detected radio conditions are better than threshold radio conditions, and an e2e packet loss rate is below a threshold e2e packet loss rate. Example 7 includes the method of examples 5-6 and/or some other example(s) herein, wherein the RRC message is to include a UE Assistance Information (UEAssistanceInformation) IE, and the UEAssistanceInformation IE is to indicate the desired radio level adaptation.
• Example 8 includes the method of examples 2-3 and/or some other example(s) herein, wherein the method comprises: generating or causing to generate a first recommended bit rate MAC CE, the first recommended bit rate MAC CE to query for a recommended bit rate or indicate a desired radio level adaptation; transmitting or causing to transmit the first recommended bit rate MAC CE to the RAN node; and receiving a second recommended bit rate MAC CE from the RAN node, the second recommended bit rate MAC CE to include ANBR information.
• Example 9 includes the method of example 8 and/or some other example(s) herein, wherein the method comprises: adapting or causing to adapt a bit rate based on the ANBR information; generating or causing to generate a CMR or an RTCP-APP for voice rate adaptation based on the ANBR information; and/or generating or causing to generate a TMMBR or a TMMBN message for video rate adaptation based on the ANBR information.
• Example 10 includes the method of examples 2-9 and/or some other example(s) herein, wherein the first SDP message is an SDP offer message and the second SDP message is an SDP answer message, or the second SDP message is an SDP offer message and the first SDP message is an SDP answer message.
• Example 11 includes the method of example 10, wherein the method comprises: generating or causing to generate the first SDP message to include a first radio capabilities attribute to indicate the one or more first radio capabilities; and identifying or causing to identify the one or more second radio capabilities within a second radio capabilities attribute in the second SDP message.
• Example 12 includes the method of examples 1-11 and/or some other example(s) herein, wherein the one or more radio capabilities include one or more of a delay budget reporting capability, a TTI bundling capability, a RAN frame aggregation capability, and a RAN-assisted codec adaptation capability or an ANBR signaling capability.
• Example 13 includes a method to be performed by a first MTSI client in terminal, the method comprising: generating or causing to generate a SDP message to indicate one or more RAN-level radio capabilities of the first UE; and transmitting or causing to transmit the SDP message to a second MTSI client in terminal via a radio link between the first MTSI client in terminal and a RAN node.
• Example 14 includes the method of example 13 and/or some other example(s) herein, wherein the SDP message is a first SDP message, the one or more radio capabilities of the first MTSI client in terminal are first radio capabilities, and the method comprises: identifying or causing to identify one or more second radio capabilities of the second MTSI client in terminal within a second SDP message obtained from the second MTSI client in terminal; and determining or causing to determine one or more desired radio level adaptations based on the one or more second radio capabilities and based on detected radio conditions, wherein the detected radio conditions are one or both of conditions of the radio link between the first MTSI client in terminal and the RAN node and conditions of a radio link between the second MTSI client in terminal and another RAN node.
• Example 15 includes the method of example 14 and/or some other example(s) herein, wherein the method comprises: generating or causing to generate a RRC message to indicate a desired radio level adaptation; and transmitting or causing to transmit the RRC message to the RAN node.
• Example 16 includes the method of example 15 and/or some other example(s) herein, wherein the desired radio level adaptation is to turn off cDRX when the one or more second radio capabilities indicate support of DBI signaling and TTI bundling, the detected radio conditions are better than threshold radio conditions, or an e2e packet loss rate is below a threshold e2e packet loss rate. Example 17 includes the method of examples 15-16 and/or some other example(s) herein, wherein the RRC message is to include a UEAssistanceInformation IE, and the UEAssistanceInformation IE is to indicate the desired radio level adaptation.
• Example 18 includes the method of example 14 and/or some other example(s) herein, wherein the method comprises: generating or causing to generate a recommended bit rate MAC CE to include a recommended bit rate query, the recommended bit rate query to query for a recommended bit rate or indicate a desired radio level adaptation; transmitting or causing to transmit the recommended bit rate MAC CE including the recommended bit rate query to the RAN node; and receiving, from the RAN node, a recommended bit rate MAC CE that includes a recommended bit rate message, the recommended bit rate message to indicate an ANBR, and the ANBR is based on the recommended bit rate query.
• Example 19 includes the method of example 18 and/or some other example(s) herein, wherein the method comprises: adapting or causing to adapt a bit rate based on the ANBR; generating or causing to generate a CMR or an RTCP-APP for voice rate adaptation based on the ANBR; or generating or causing to generate a TMMBR or a TMMBN message for video rate adaptation based on the ANBR.
• Example 20 includes the method of examples 13-19 and/or some other example(s) herein, wherein the first SDP message is an SDP offer message and the second SDP message is an SDP answer message, or the second SDP message is an SDP offer message and the first SDP message is an SDP answer message, and wherein the method comprises: generating or causing to generate the first SDP message to include a first radio capabilities attribute to indicate the one or more first radio capabilities; and identifying or causing to identify the one or more second radio capabilities within a second radio capabilities attribute in the second SDP message.
• Example 21 includes the method of examples 13-20 and/or some other example(s) herein, wherein the one or more radio capabilities include one or more of a delay budget reporting capability, a TTI bundling capability, a RAN frame aggregation capability, and a RAN-assisted codec adaptation capability or an ANBR signaling capability.
• Example 22 includes a method to be performed by a MTSI client in terminal comprising: identifying or causing to identify radio capabilities of a remote device based on a session description protocol (SDP) offer message obtained from the remote device; and generating or causing to generate an SDP answer message to include a radio capabilities attribute, the radio capabilities attribute to indicate one or more radio capabilities of the apparatus.
• Example 23 includes the method of example 22 and/or some other example(s) herein, further comprising: receiving the SDP offer message from the remote device, wherein the SDP offer message is to include another radio capabilities attribute of the remote device; and transmitting or causing to transmit the SDP answer message to the remote device. Example 24 includes the method of example 23 and/or some other example(s) herein, wherein the radio capabilities attribute of the apparatus is to indicate whether the apparatus supports one or more of a delay budget reporting, TTI bundling, RAN frame aggregation, and RAN-assisted codec adaptation or an ANBR signaling capability; and the other radio capabilities attribute of the remote device is to indicate whether the remote device supports one or more of a delay budget reporting, TTI bundling, RAN frame aggregation, and RAN-assisted codec adaptation or an ANBR signaling capability.
• Example 25 includes the method of example 24 and/or some other example(s) herein, further comprising: detecting or causing to detect radio conditions local to the MTSI client in terminal, wherein the detected radio conditions are one or both of conditions of the radio link between the MTSI client in terminal and the RAN node and conditions of a radio link between the remote device and another RAN node; and generating or causing to generate a message to indicate one or more desired radio level adaptations based on the radio capabilities of the remote device and based on the detected radio conditions.
• Example 26 includes the method of example 25 and/or some other example(s) herein, wherein the message is an RRC message, and the method comprises: transmitting or causing to transmit the RRC message to a local RAN node; receiving another message from the RAN node based on the RRC message; and adjusting or causing to adjust a bit rate based on the message received from the RAN node. Example 27 includes the method of example 26 and/or some other example(s) herein, wherein when the detected radio conditions include a relatively long packet delay and jitter, the other message is a recommended bit rate MAC CE; and when the detected radio conditions include a relatively large number of packet losses, the other message is a delay budget information acknowledgement indicating that additional budget has been granted by the RAN node.
• Example 28 includes the method of example 25 and/or some other example(s) herein, wherein the message is a recommended bit rate query MAC CE for querying the recommended bitrate or indicating a desired bit rate, and the method comprises receiving a recommended bit rate message MAC CE, the recommended bit rate message MAC CE including an ANBR based on the recommended bit rate query MAC CE. Example 29 includes the method of example 28 and/or some other example(s) herein, further comprising: adapting or causing to adapt a bit rate based on the ANBR. Example 30 includes the method of examples 28-29 and/or some other example(s) herein, wherein the method comprises: generating or causing to generate a CMR or an Application-defined RTCP-APP for voice rate adaptation based on the ANBR; and/or generating or causing to generate a TMMBR or a TMMBN message for video rate adaptation based on the ANBR.
• Example 31 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-30, or any other method or process described herein. Example 32 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-30, or any other method or process described herein. Example 33 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-30, or any other method or process described herein. Example 34 may include a method, technique, or process as described in or related to any of examples 1-30, or portions or parts thereof. Example 35 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-30, or portions thereof. Example 36 may include a signal as described in or related to any of examples 1-30, or portions or parts thereof. Example 37 includes a packet, frame, segment, PDU, or message as described in or related to any of examples 1-30, or portions or parts thereof, or otherwise described in the present disclosure. Example 38 may include a signal in a wireless network as shown and described herein. Example 39 may include a method of communicating in a wireless network as shown and described herein. Example 40 may include a system for providing wireless communication as shown and described herein. Example 41 may include a device for providing wireless communication as shown and described herein.
• In the preceding detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.
• Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments. Also, it is noted that example embodiments may be described as a process depicted as successive operations and/or with a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function a main function.
• The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
• The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “an” and “the” are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specific the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operation, elements, components, and/or groups thereof. For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). The description may use the phrases “in an embodiment,” or “In some embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous. Where the disclosure recites “a” or “a first” element or the equivalent thereof, such disclosure includes one or more such elements, neither requiring nor excluding two or more such elements. Further, ordinal indicators (e.g., first, second or third) for identified elements are used to distinguish between the elements, and do not indicate or imply a required or limited number of such elements, nor do they indicate a particular position or order of such elements unless otherwise specifically stated.
• The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or ink, and/or the like.
• The term “circuitry” refers to a circuit or system of multiple circuits configured to perform a particular function in an electronic device. The circuit or system of circuits may be part of, or include one or more hardware components, such as a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that are configured to provide the described functionality. In addition, the term “circuitry” may also refer to a combination of one or more hardware elements with the program code used to carry out the functionality of that program code. Some types of circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Such a combination of hardware elements and program code may be referred to as a particular type of circuitry. The term “processor circuitry” refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes. The term “module” may refer to one or more independent electronic circuits packaged onto a circuit board, System-on-Chip (SoC), System-in-Package (SiP), Multi-Chip-Package (MCP), etc., configured to provide a basic function within a computer system. The term “module” may refer to, be part of, or include an FPGA, ASIC, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. The term “interface circuitry” may refer to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces (e.g., buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like). The term “memory” and/or “memory circuitry” may represent one or more hardware devices for storing data, including RAM, magnetic RAM, core memory, ROM, magnetic disk storage mediums, optical storage mediums, flash memory devices or other machine readable mediums for storing data. The term “computer-readable medium” may include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instructions or data.
• The term “device” refers to a physical entity embedded inside, or attached to, another physical entity in its vicinity, with capabilities to convey digital information from or to that physical entity. The term “element” refers to a unit that is indivisible at a given level of abstraction and has a clearly defined boundary, wherein an element may be any type of entity. The term “controller” refers to an element or entity that has the capability to affect a physical entity, such as by changing its state or causing the physical entity to move. The term “entity” refers to a distinct component of an architecture or device, and/or information transferred as a payload. The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like. The terms “access node,” “access point,” or the like may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users.
• The term “computer system” refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” refers to various components of a computer that are communicatively coupled with one another, or otherwise organized to accomplish one or more functions. Furthermore, the term “computer system” and/or “system” refers to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources. The term “architecture” refers to a fundamental organization of a system embodied in its components, their relationships to one another, and to an environment, as well as to the principles guiding its design and evolution. The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, 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. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.
• The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information. The term “communication protocol” (either wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for packetizing/depacketizing data, modulating/demodulating signals, implementation of protocols stacks, and/or the like.
• The terms “instantiate,” “instantiation,” and the like refers to the creation of an instance, and an “instance” refers to a concrete occurrence of an object, which may occur, for example, during execution of program code. The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. The term “resource” refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, I/O operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like. The term “service” refers to a particular functionality or a set of functions to be performed on behalf of a requesting party, such as any of the computing systems or devices discussed herein. A service may include or involve the retrieval of specified information or the execution of a set of operations. The term “session” refers to a set of senders and receivers, and the data streams flowing from the senders to receivers. The term “session description” refers to a format for conveying sufficient information to discover and participate in a multimedia session. A “media stream” refers to a single media instance, for example, an audio stream or a video stream, as well as a single whiteboard or shared application group.
• For the purposes of the present document, the abbreviations listed in table 10 may apply to the examples and embodiments discussed herein.

• TABLE 10
  3GPP	Third Generation Partnership Project
  4G	Fourth Generation
  5G	Fifth Generation
  5GC	5G Core Network
  ACK	Acknowledgement
  AF	Application Function
  AM	Acknowledged Mode
  AMF	Access and Mobility Management Function
  AMR	Adaptive Multi-Rate
  AMR-NB	Adaptive Multi-Rate-NarrowBand
  AMR-WB	Adaptive Multi-Rate-WideBand
  AMR-WB IO	Adaptive Multi-Rate-WideBand Inter-operable Mode
  AN	Access Network
  ANBR	Access Network Bitrate Recommendation
  ANBRQ	Access Network Bitrate Recommendation Query
  AP	Application Protocol, Antenna Port, Access Point
  API	Application Programming Interface
  APP	Application-defined RTCP packet
  ARQ	Automatic Repeat Request
  AS	Access Stratum
  AS	Application Server
  ASN.1	Abstract Syntax Notation One
  AUSF	Authentication Server Function
  AVC	Advanced Video Coding
  AVP	Audio-Visual Profile
  AVPF	AVP with Feedback
  BER	Bit Error Ratio
  BLER	Block Error Rate
  BS	Base Station
  BW	Bandwidth
  CA	Carrier Aggregation, Certification Authority
  CAMEL	Customised Application Mobile Enhanced Logic
  CAP	Camel Application Part
  CAPEX	CAPital Expenditure
  CCM	Codec Control Messages
  CDF	Cumulative Distribution Function
  CDMA	Code-Division Multiple Access
  CDR	Charging Data Record
  cDRX	Connected Mode DRX
  CID	Cell-ID (e.g., positioning method)
  CM	Connection Management, Conditional Mandatory
  CMR	Codec Mode Request
  CPU	CSI processing unit, Central Processing Unit
  CRAN	Cloud Radio Access Network, Cloud RAN
  CS	Circuit Switched
  CS-ACELP	Conjugate-Structure Algebraic-Code-Excited
  	Linear Prediction
  CSCF	Call Session Control Function
  D2D	Device-to-Device
  DBI	Delay Budget Information
  DECT	Digital Enhanced Cordless Telecommunications
  DF	Deployment Flavour
  DL	Downlink
  DMTF	Distributed Management Task Force
  DN	Data network
  DRX	Discontinuous Reception
  DSR	Distributed Speech Recognition
  DTMF	Dual Tone Multi-Frequency
  DTX	Discontinuous Transmission
  e2e	End-to-End
  ECN	Explicit Congestion Notification
  ECN-CE	ECN Congestion Experienced
  ECT	ECN Capable Transport
  eNB	evolved NodeB, E-UTRAN Node B
  EPC	Evolved Packet Core
  EPS	Evolved Packet System
  E-UTRA	Evolved UTRA
  E-UTRAN	Evolved UTRAN
  EVRC	Enhanced Variable Rate Codec
  EVS	Enhanced Voice Services
  FDD	Frequency Division Duplex
  FDM	Frequency Division Multiplex
  FDMA	Frequency Division Multiple Access
  FEM	Front End Module
  FPGA	Field-Programmable Gate Array
  FR	Frequency Range
  GBR	Guaranteed Bit Rate
  GERAN	GSM EDGE RAN, GSM EDGE Radio Access
  	Network
  GLONASS	GLObal'naya NAvigatsionnaya Sputnikovaya
  	Sistema (Engl.: Global Navigation Satellite System)
  gNB	Next Generation NodeB
  gNB-CU	gNB-centralized unit
  gNB-DU	gNB-distributed unit
  GNSS	Global Navigation Satellite System
  GPRS	General Packet Radio Service
  GRUU	Globally Routable UA URI
  GSM	Global System for Mobile Communications, Groupe
  	Spécial Mobile
  GTP	GPRS Tunneling Protocol
  GTP-U	GPRS Tunnelling Protocol for User Plane
  HARQ	Hybrid ARQ, Hybrid Automatic Repeat Request
  HEVC	High Efficiency Video Coding
  HSS	Home Subscriber Server
  HTTP	Hyper Text Transfer Protocol
  HTTPS	Hyper Text Transfer Protocol Secure (https is http/1.1
  	over SSL, e.g., port 443)
  I-CSCF	Interrogating CSCF
  IM-SSF	IMS Service Switching Function
  ICM	Initial Codec Mode
  ID	Identity, identifier
  IE	Information Element
  IEEE	Institute of Electrical and Electronics Engineers
  IETF	Internet Engineering Task Force
  IM	Interference Measurement, Intermodulation, IP
  	Multimedia
  IMC	IMS Credentials
  IMS	IP Multimedia Subsystem
  IoT	Internet of Things
  I/O	Input/Output
  IP	Internet Protocol
  IPsec	IP Security, Internet Protocol Security
  IP-CAN	IP-Connectivity Access Network
  IPv4	Internet Protocol Version 4
  IPv6	Internet Protocol Version 6
  IR	Infrared
  ISO	International Organisation for Standardisation
  IWF	Interworking-Function
  I-WLAN	Interworking WLAN
  JBM	Jitter Buffer Management
  kB	Kilobyte (1000 bytes)
  kbps	kilo-bits per second
  ksps	kilo-symbols per second
  L1	Layer 1 (physical layer)
  L2	Layer 2 (data link layer)
  L3	Layer 3 (network layer)
  LAN	Local Area Network
  LLC	Logical Link Control, Low Layer Compatibility
  LPLMN	Local PLMN
  LSB	Least Significant Bit
  LTE	Long Term Evolution
  LWA	LTE-WLAN aggregation
  LWIP	LTE/WLAN Radio Level Integration with IPsec Tunnel
  LTE	Long Term Evolution
  M2M	Machine-to-Machine
  MAC	Medium Access Control, Media Access Control (protocol
  	layering context)
  MBR	Maximum Bit Rate
  MFRC	Media Resource Function Controller
  MFRP	Media Resource Function Processor
  MGW	Media Gateway
  MIB	Master Information Block, Management Information Base
  MIMO	Multiple Input Multiple Output
  MM	Mobility Management
  MME	Mobility Management Entity
  MPDCCH	MTC Physical Downlink Control CHannel
  MPEG	Moving Picture Experts Group
  MPLS	MultiProtocol Label Switching
  MSB	Most Significant Bit
  MSMTSI	Multi-Stream Multimedia Telephony Service for IMS
  MTSI	Multimedia Telephony Service for IMS
  MTC	Machine-Type Communications
  mMTC	massive MTC, massive Machine-Type Communications
  N3GPP	Non-3GPP, Non-Third Generation Partnership Project
  N3IWF	Non-3GPP InterWorking Function
  NACK	Negative Acknowledgement
  NAS	Non-Access Stratum
  NEF	Network Exposure Function
  NF	Network Function
  NFV	Network Functions Virtualization
  NFVI	NFV Infrastructure
  NFVO	NFV Orchestrator
  NG	Next Generation, Next Gen
  NGAP	NG Application Protocol
  NG-DECT	New Generation DECT
  NGEN-DC	NG-RAN E-UTRA-NR Dual Connectivity
  NR	New Radio, Neighbour Relation
  NSSAI	Network Slice Selection Assistance Information
  S-NNSAI	Single-NSSAI
  NSSF	Network Slice Selection Function
  NW	Network
  OFDM	Orthogonal Frequency Division Multiplexing
  OFDMA	Orthogonal Frequency Division Multiple Access
  OSA	Open Services Architecture, Open Services Access
  OTA	Over-the-Air
  P-GRUU	Public GRUU
  PCC	Policy and Charging Control (IMS contexts)
  PCEF	Policy and Charging Enforcement Function
  PCF	Policy Control Function
  PCRF	Policy Control and Charging Rules Function
  PDCP	Packet Data Convergence Protocol
  PDCCH	Physical Downlink Control Channel
  PDCP	Packet Data Convergence Protocol
  PDN	Packet Data Network, Public Data Network
  PDSCH	Physical Downlink Shared Channel
  PDU	Protocol Data Unit
  P-GW	PDN Gateway
  P-CSCF	Proxy CSCF
  PHY	Physical layer
  PLMN	Public Land Mobile Network
  PLR	Packet Loss Rate
  POC	PTT over Cellular
  PP, PTP	Point-to-Point
  PPP	Point-to-Point Protocol
  ProSe	Proximity Services, Proximity-Based Service
  PSBCH	Physical Sidelink Broadcast Channel
  PSDCH	Physical Sidelink Downlink Channel
  PSCCH	Physical Sidelink Control Channel
  PSSCH	Physical Sidelink Shared Channel
  PTT	Push-to-Talk
  PUCCH	Physical Uplink Control Channel
  PUSCH	Physical Uplink Shared Channel
  QoS	Quality of Service
  RAN	Radio Access Network
  RAT	Radio Access Technology
  Rel	Release
  RF	Radio Frequency
  RLC	Radio Link Control
  RNC	Radio Network Controller
  RRC	Radio Resource Control
  RSU	Road Side Unit
  RTCP	RTP Control Protocol, Real-Time Transport Control
  	Protocol
  RTP	Real Time Protocol
  RTSP	RTP Streaming Protocol
  RTT	Round Trip Time
  Rx	Reception, Receiving, Receiver
  S1AP	S1 Application Protocol
  S1-MME	S1 for the control plane
  S1-U	S1 for the user plane
  S-CSCF	Serving CSCF
  S-GW	Serving Gateway
  SAE	System Architecture Evolution
  SAP	Service Access Point
  SC-FDMA	Single Carrier Frequency Division Multiple Access
  SCS	Service Capability Servers
  SCTP	Stream Control Transmission Protocol
  SDAP	Service Data Adaptation Protocol, Service Data
  	Adaptation Protocol layer
  SDP	Service Description Protocol
  SDPCapNeg	SDP Capability Negotiation
  SEAF	Security Anchor Function
  SEPP	Security Edge Protection Proxy
  SGSN	Serving GPRS Support Node
  S-GW	Serving Gateway
  SI	System Information
  SIB	System Information Block
  SIP	Session Initiation Protocol
  SL	Sidelink
  SM	Session Management
  SMF	Session Management Function
  SMS	Short Message Service
  SPS	Semi-Persistent Scheduling
  SRTP	Secure RTP
  SRVCC	Single Radio Voice Call Continuity
  T-GRUU	Temporary GRUU
  TBD	To Be Defined
  TCP	Transmission Communication Protocol
  TLS	Transport Layer Security
  TM	Transparent Mode
  TMMBN	Temporary Maximum Media Bit-rate Notification
  TMMBR	Temporary Maximum Media Bit-rate Request
  TR	Technical Report
  TRP, TRxP	Transmission Reception Point
  TRx	Transceiver
  TS	Technical Specifications, Technical Standard
  TTI	Transmission Time Interval
  Tx	Transmission, Transmitting, Transmitter
  UA	User Agent
  UE	User Equipment
  UDM	Unified Data Management
  UDP	User Datagram Protocol
  UDSF	Unstructured Data Storage Network Function
  UL	Uplink
  UM	Unacknowledged Mode
  UML	Unified Modelling Language
  UMTS	Universal Mobile Telecommunications System
  UP	User Plane
  UPF	User Plane Function
  URI	Uniform Resource Identifier
  URL	Uniform Resource Locator
  USB	Universal Serial Bus
  USIM	Universal Subscriber Identity Module
  UTRA	UMTS Terrestrial Radio Access
  UTRAN	Universal Terrestrial Radio Access Network
  V2X	Vehicle-to-everything
  vBBUP	virtual baseband unit pool
  ViLTE	Video-over-LTE
  VoIP	Voice-over-IP, Voice-over-Internet Protocol
  VoLTE	Voice-over-LTE
  VM	Virtual Machine
  VNF	Virtualized Network Function
  VPLMN	Visited Public Land Mobile Network
  WiMAX	Worldwide Interoperability for Microwave Access
  WLAN	Wireless Local Area Network
  WMAN	Wireless Metropolitan Area Network
  WPAN	Wireless Personal Area Network
  X2AP	X2 Application Protocol
  X2-C	X2 Control plane
  X2-U	X2 User plane
  XnAP	Xn Application Protocol
  Xn-C	Xn Control plane
  Xn-U	Xn User plane
  XML	eXtensible Markup Language

• The foregoing description provides illustration and description of various example embodiments, but is not intended to be exhaustive or to limit the scope of embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. It should be understood that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

Claims (25)

1. A System-on-Chip (SoC) to be implemented in a first user equipment (UE), the SoC comprising:

baseband circuitry to generate a Session Description Protocol (SDP) message to indicate one or more radio capabilities of the first UE; and

interface circuitry coupled with the baseband circuitry, the interface circuitry to provide the SDP message to radio-frequency (RF) circuitry for transmission to a second UE via a Radio Access Network (RAN) node.

2. The SoC ofclaim 1, wherein the SDP message is a first SDP message, the one or more radio capabilities of the first UE are first radio capabilities, and wherein the baseband circuitry is further to:

identify one or more second radio capabilities of the second UE within a second SDP message obtained from the second UE; and

determine one or more desired radio level adaptations based on the one or more second radio capabilities.

3. The SoC ofclaim 2, wherein the baseband circuitry is further to:

determine the one or more desired radio level adaptations based on the one or more second radio capabilities and based on detected radio conditions.

4. The SoC ofclaim 3, wherein the detected radio conditions are one or both of conditions of a radio link between the first UE and the RAN node and conditions of a radio link between the second UE and another RAN node, and wherein:

the baseband circuitry is further to generate a Radio Resource Control (RRC) message to indicate a desired radio level adaptation; and

the interface circuitry is further to provide the RRC message to the RF circuitry for transmission to the RAN node.

5. The SoC ofclaim 4, wherein the desired radio level adaptation is to turn off connected mode discontinuous reception (cDRX) when the one or more second radio capabilities indicate support of Delay Budget Information (DBI) signaling and Transmission Time Interval (TTI) bundling, the detected radio conditions are better than threshold radio conditions, and an end-to-end (e2e) packet loss rate is below a threshold e2e packet loss rate.

6. The SoC ofclaim 4, wherein the RRC message is to include a UE Assistance Information (UEAssistanceInformation) information element (IE), and the UEAssistanceInformation IE is to indicate the desired radio level adaptation.

7. The SoC ofclaim 2, wherein:

the baseband circuitry is to further generate a first recommended bit rate Media Access Control (MAC) Control Element (CE), the first recommended bit rate MAC CE to query for a recommended bit rate or indicate a desired radio level adaptation; and

the interface circuitry is further to provide the first recommended bit rate MAC CE to the to the RF circuitry for transmission to the RAN node, and obtain a second recommended bit rate MAC CE from the RF circuitry, the second recommended bit rate MAC CE to include Access Network Bitrate Recommendation (ANBR) information.

8. The SoC ofclaim 7, wherein the baseband circuitry is further to:

adapt a bit rate based on the ANBR information;

generate a Codec Mode Request (CMR) or an Application-defined Real-Time Transport Control Protocol packet (APP) for voice rate adaptation based on the ANBR information; or

generate a Temporary Maximum Media Bit-rate Request (TMMBR) or a Temporary Maximum Media Bit-rate Notification (TMMBN) message for video rate adaptation based on the ANBR information.

9. The SoC ofclaim 2, wherein the first SDP message is an SDP offer message and the second SDP message is an SDP answer message, or the second SDP message is an SDP offer message and the first SDP message is an SDP answer message, and wherein the baseband circuitry is to:

generate the first SDP message to include a first radio capabilities attribute to indicate the one or more first radio capabilities; and

identify the one or more second radio capabilities within a second radio capabilities attribute in the second SDP message.

10. The SoC ofclaim 1, wherein the one or more radio capabilities include one or more of a delay budget reporting capability, a transmission time interval (TTI) bundling capability, a RAN frame aggregation capability, and a RAN-assisted codec adaptation capability or an ANBR signaling capability.

11. One or more non-transitory computer-readable media (NTCRM) comprising instructions, wherein execution of the instructions is to cause a first user equipment (UE) to operate a Multimedia Telephony Service for Internet Protocol Multimedia Subsystem (MTSI) client to:

generate a Session Description Protocol (SDP) message to indicate one or more Radio Access Network (RAN)-level radio capabilities of the first UE; and

control transmission of the SDP message to a second UE via a radio link between the first UE and a RAN node.

12. The one or more NTCRM ofclaim 11, wherein the SDP message is a first SDP message, the one or more radio capabilities of the first UE are first radio capabilities, and wherein execution of the instructions is to cause the first UE to operate the MTSI client to:

identify one or more second radio capabilities of the second UE within a second SDP message obtained from the second UE; and

determine one or more desired radio level adaptations based on the one or more second radio capabilities and based on detected radio conditions, wherein the detected radio conditions are one or both of conditions of the radio link between the first UE and the RAN node and conditions of a radio link between the second UE and another RAN node.

13. The one or more NTCRM ofclaim 12, wherein execution of the instructions is to cause the first UE to operate the MTSI client to:

generate a Radio Resource Control (RRC) message to indicate a desired radio level adaptation, wherein the desired radio level adaptation is to turn off connected mode discontinuous reception (cDRX) when the one or more second radio capabilities indicate support of Delay Budget Information (DBI) signaling and Transmission Time Interval (TTI) bundling, the detected radio conditions are better than threshold radio conditions, or an end-to-end (e2e) packet loss rate is below a threshold e2e packet loss rate; and

control transmission of the RRC message to the RAN node.

14. The one or more NTCRM ofclaim 13, wherein the RRC message is to include a UE Assistance Information (UEAssistanceInformation) information element (IE), and the UEAssistanceInformation IE is to indicate the desired radio level adaptation.

15. The one or more NTCRM ofclaim 12, wherein execution of the instructions is to cause the first UE to operate the MTSI client to:

generate a recommended bit rate Media Access Control (MAC) Control Element (CE) to include a recommended bit rate query, the recommended bit rate query to query for a recommended bit rate or indicate a desired radio level adaptation;

control transmission of the recommended bit rate MAC CE including the recommended bit rate query to the RAN node; and

receive, from the RAN node, a recommended bit rate MAC CE that includes a recommended bit rate message, the recommended bit rate message to indicate an Access Network Bitrate Recommendation (ANBR), and the ANBR is based on the recommended bit rate query.

16. The one or more NTCRM ofclaim 15, wherein execution of the instructions is to cause the first UE to operate the MTSI client to:

adapt a bit rate based on the ANBR;

generate a Codec Mode Request (CMR) or an Application-defined Real-Time Transport Control Protocol packet (APP) for voice rate adaptation based on the ANBR; or

generate a Temporary Maximum Media Bit-rate Request (TMMBR) or a Temporary Maximum Media Bit-rate Notification (TMMBN) message for video rate adaptation based on the ANBR.

17. The one or more NTCRM ofclaim 12, wherein the first SDP message is an SDP offer message and the second SDP message is an SDP answer message, or the second SDP message is an SDP offer message and the first SDP message is an SDP answer message, and wherein execution of the instructions is to cause the first UE to operate the MTSI client to:

generate the first SDP message to include a first radio capabilities attribute to indicate the one or more first radio capabilities; and

identify the one or more second radio capabilities within a second radio capabilities attribute in the second SDP message.

18. An MTSI client in terminal comprising:

identification means for identifying radio capabilities of a remote device based on a session description protocol (SDP) offer message obtained from the remote device;

message generation means for generating an SDP answer message to include a radio capabilities attribute, the radio capabilities attribute to indicate one or more radio capabilities of the apparatus;

means for receiving the SDP offer message from the remote device, wherein the SDP offer message is to include another radio capabilities attribute of the remote device; and

means for transmitting the SDP answer message to the remote device.

19. The MTSI client in terminal ofclaim 18, wherein the radio capabilities attribute of the apparatus is to indicate whether the apparatus supports one or more of a delay budget reporting, transmission time interval (TTI) bundling, Radio Access Network (RAN) frame aggregation, and RAN-assisted codec adaptation or an access network bitrate recommendation (ANBR) signaling capability; and the other radio capabilities attribute of the remote device is to indicate whether the remote device supports one or more of a delay budget reporting, TTI bundling, RAN frame aggregation, and RAN-assisted codec adaptation or an ANBR signaling capability.

20. The MTSI client in terminal ofclaim 18, further comprising:

means for detecting radio conditions local to the MTSI client in terminal, wherein the detected radio conditions are one or both of conditions of the radio link between the MTSI client in terminal and the RAN node and conditions of a radio link between the remote device and another RAN node, and

wherein the message generation means is for generating a message to indicate one or more desired radio level adaptations based on the radio capabilities of the remote device and based on the detected radio conditions.

21. The MTSI client in terminal ofclaim 20, wherein the message is a Radio Resource Control (RRC) message, the means for transmitting is for transmitting the RRC message to a local RAN node; and the means for receiving is for receiving another message from the RAN node based on the RRC message, and the MTSI client in terminal further comprises:

means for adjusting a bit rate based on the message received from the RAN node.

22. The MTSI client in terminal ofclaim 21, wherein: when the detected radio conditions include a relatively long packet delay and jitter, the other message is a recommended bit rate Media Access Control (MAC) Control Element (CE); and when the detected radio conditions include a relatively large number of packet losses, the other message is a delay budget information acknowledgement indicating that additional budget has been granted by the RAN node.

23. The MTSI client in terminal ofclaim 21, wherein the message is a recommended bit rate query MAC CE for querying the recommended bitrate or indicating a desired bit rate, and wherein the means for receiving is for receiving a recommended bit rate message MAC CE, the recommended bit rate message MAC CE including an ANBR based on the recommended bit rate query MAC CE.

24. The MTSI client in terminal ofclaim 23, further comprising:

means for adapting a bit rate based on the ANBR.

25. The MTSI client in terminal ofclaim 23, wherein the message generation means is for:

generating a Codec Mode Request (CMR) or an Application-defined Real-Time Transport Control Protocol packet (APP) for voice rate adaptation based on the ANBR; or

generating a Temporary Maximum Media Bit-rate Request (TMMBR) or a Temporary Maximum Media Bit-rate Notification (TMMBN) message for video rate adaptation based on the ANBR.

Images