Considerations regarding Quality of Service (QOS) hints for uplink streaming services

Abstract

In one aspect, a responder receives a first plurality of quality of service (QoS) parameters for a multimedia session from an initiator, the first plurality of QoS parameters comprising a first loss and / or delay parameter indicating a first expected maximum end-to-end packet loss and / or delay for the multimedia session, determines that the first expected maximum end-to-end packet loss is higher than a second expected maximum end-to-end packet loss, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay, or both, and sends a second plurality of QoS parameters for the multimedia session to the initiator, the second plurality of QoS parameters comprising a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Application No. 62 / 915,554, filed on October 15, 2019, entitled “CONSIDERATIONS ON QUALITY of SERVICE (QOS) HINTS for AN UPLINK STREAMING SERVICE,” and U.S. Non-Provisional Application No. 17 / 060,816, filed on October 1, 2020, entitled “CONSIDERATIONS ON QUALITY of SERVICE (QOS) HINTS for AN UPLINK STREAMING SERVICE,” both of which are assigned to the assignee of this application and are expressly incorporated herein by reference in their entirety. Technical Field

[0003] Aspects of the present disclosure generally relate to wireless communications. Background Art

[0004] Wireless communication systems have evolved over several generations, including first generation analog wireless telephone service (1G), second generation (2G) digital wireless telephone service (including transitional 2.5G networks), third generation (3G) high speed data, wireless services with Internet capabilities, and fourth generation (4G) services (e.g., LTE or WiMax). There are many different types of wireless communication systems currently in use, including cellular and personal communications service (PCS) systems. Examples of known cellular systems include cellular analog Advanced Mobile Phone System (AMPS) and digital cellular systems based on code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile Communications (GSM), etc.

[0005] The fifth generation (5G) wireless standard, known as New Radio (NR), calls for higher data transmission speeds, a greater number of connections, and better coverage, among other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard is designed to provide data rates of tens of megabits per second to each of tens of thousands of users, and 1 gigabit per second to dozens of workers in an office building. To support large-scale sensor deployments, hundreds of thousands of simultaneous connections should be supported. Therefore, the spectral efficiency of 5G mobile communications should be significantly enhanced compared to the current 4G standard. In addition, signaling efficiency should be enhanced, and latency should be significantly reduced compared to the current standard. Summary of the invention

[0006] A brief summary of one or more aspects disclosed herein is provided below. Therefore, the following summary should not be considered a broad overview related to all expected aspects, nor should the following summary be considered to identify key or important elements related to all expected aspects or to delineate the scope associated with any particular aspect. Therefore, the sole purpose of the following summary is to provide certain concepts about one or more aspects related to the mechanisms disclosed herein in a simplified form before the detailed description given below.

[0007] In one aspect, a wireless communication method performed by a responder includes: receiving a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator and the responder from an initiator, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; determining that the first expected maximum end-to-end packet loss is higher than a second expected maximum end-to-end packet loss for the multimedia session, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay for the multimedia session, or both; and sending a second plurality of QoS parameters for the multimedia session to the initiator, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both.

[0008] In one aspect, a wireless communication method performed by an initiator includes: sending a first plurality of QoS parameters for a multimedia session to be established between the initiator and the responder to a responder, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; receiving a second plurality of QoS parameters for the multimedia session from the responder, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia session, a second delay parameter indicating a second expected maximum end-to-end packet delay for the multimedia session, or both; determining whether the initiator can establish the multimedia session with the responder based on the multimedia session having the second plurality of QoS parameters; and establishing the multimedia session with the responder, the multimedia session having the second plurality of QoS parameters.

[0009] In one aspect, a responder apparatus comprises: a memory; a communication device; and at least one processor, which is communicatively coupled to the memory and the communication device, the at least one processor being configured to: receive a first plurality of QoS parameters for a multimedia session to be established between the initiator apparatus and the responder apparatus from an initiator apparatus, the first plurality of QoS parameters comprising a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; determine that the first expected maximum end-to-end packet loss is higher than a second expected maximum end-to-end packet loss for the multimedia session, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay for the multimedia session, or both; and cause the communication device to send a second plurality of QoS parameters for the multimedia session to the initiator apparatus, the second plurality of QoS parameters comprising a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both.

[0010] In one aspect, an initiator device comprises: a memory; a communication device; and at least one processor, which is communicatively coupled to the memory and the communication device, and the at least one processor is configured to: cause the communication device to send a first plurality of QoS parameters for a multimedia session to be established between the initiator device and the responder device to the responder device, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; receive a second plurality of QoS parameters for the multimedia session from the responder device, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia session, a second delay parameter indicating a second expected maximum end-to-end packet delay for the multimedia session, or both; determine whether the initiator device can establish a multimedia session with the responder device based on the multimedia session having the second plurality of QoS parameters; and establish a multimedia session with the responder device, the multimedia session having the second plurality of QoS parameters.

[0011] In one aspect, a responder device comprises: a component for receiving a first plurality of QoS parameters for a multimedia session to be established between the initiator device and the responder device from an initiator device, the first plurality of QoS parameters comprising a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; a component for determining that the first expected maximum end-to-end packet loss is higher than a second expected maximum end-to-end packet loss for the multimedia session, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay for the multimedia session, or both; and a component for sending a second plurality of QoS parameters for the multimedia session to the initiator device, the second plurality of QoS parameters comprising a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both.

[0012] In one aspect, an initiator device includes: a component for sending a first plurality of QoS parameters for a multimedia session to be established between the initiator device and the responder device to a responder device, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; a component for receiving a second plurality of QoS parameters for the multimedia session from the responder device, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia session, a second delay parameter indicating a second expected maximum end-to-end packet delay for the multimedia session, or both; a component for determining whether the initiator device is able to establish a multimedia session with the responder device based on the multimedia session having the second plurality of QoS parameters; and a component for establishing a multimedia session with the responder device, the multimedia session having the second plurality of QoS parameters.

[0013] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions includes computer-executable instructions, which include: instructing a responder to receive at least one instruction for a first plurality of QoS parameters for a multimedia session to be established between the initiator and the responder from an initiator, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; instructing the responder to determine that the first expected maximum end-to-end packet loss is higher than a second expected maximum end-to-end packet loss for the multimedia session, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay for the multimedia session, or both; and instructing the responder to send at least one instruction for a second plurality of QoS parameters for the multimedia session to the initiator, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both.

[0014] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions includes computer-executable instructions, the computer-executable instructions including: instructing an initiator to send at least one instruction for a first plurality of QoS parameters for a multimedia session to be established between the initiator and the responder to a responder, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both; instructing the initiator to receive at least one instruction for a second plurality of QoS parameters for the multimedia session from the responder, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia session, a second delay parameter indicating a second expected maximum end-to-end packet delay for the multimedia session, or both; at least one instruction instructing the initiator to determine whether the initiator can establish the multimedia session with the responder based on the multimedia session having the second plurality of QoS parameters; and at least one instruction instructing the initiator to establish the multimedia session with the responder, the multimedia session having the second plurality of QoS parameters.

[0015] Other objects and advantages associated with the various aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings are provided to aid in describing the various aspects of the disclosure and are provided solely for illustration of these aspects and not limitation thereof.

[0017] Figure 1An example wireless communication system in accordance with aspects of the present disclosure is described.

[0018] Figure 2A and Figure 2B Example wireless network structures in accordance with aspects of the present disclosure are described.

[0019] FIG. 3A to FIG. 3C is a simplified block diagram of several example aspects of components that may be employed in a user equipment (UE), a base station, and a network entity, respectively.

[0020] Figure 4 An example end-to-end communication flow between two terminals conducting a multimedia-based communication session according to various aspects of the present disclosure is illustrated.

[0021] Figure 5 An exemplary uplink streaming service architecture in accordance with various aspects of the present disclosure is described.

[0022] Figures 6 to 8 Example methods of wireless communications in accordance with various aspects of the present disclosure are described. DETAILED DESCRIPTION

[0023] Various aspects of the present disclosure are provided in the following description of various examples provided for the purpose of specification and the related drawings. Alternative aspects can be thought of without departing from the scope of the present disclosure. Additionally, well-known elements of the present disclosure will not be described in detail or will be omitted to avoid obscuring the relevant details of the present disclosure.

[0024] The terms "exemplary" and / or "example" are used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

[0025] Those skilled in the art will recognize that the information and signals described below may be represented using any of a variety of different techniques and technologies. For example, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc., data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout this description may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0026] In addition, many aspects are described in terms of a sequence of actions to be performed by, for example, elements of a computing device. It should be appreciated that the various actions described herein may be performed by a dedicated circuit (e.g., an application specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of the two. In addition, the sequence of actions described herein may be viewed as fully embodied in any form of a non-transitory computer-readable storage medium having a set of corresponding computer instructions stored therein, which, when executed, will cause or instruct the processor of the associated device to perform the functions described herein. Therefore, various aspects of the present disclosure may be embodied in many different forms, all of which are contemplated to fall within the scope of the subject matter claimed. In addition, for each of the various aspects described herein, the corresponding form of any of these aspects may be described herein as, for example, a "logic unit" that is "configured to" perform the described actions.

[0027] As used herein, unless otherwise indicated, the terms "user equipment" (UE) and "base station" are not intended to be dedicated to or limited to any specific radio access technology (RAT). In general, a UE may be any wireless communication device (e.g., a mobile phone, a router, a tablet computer, a laptop computer, a tracking device, a wearable device (e.g., a smart watch, glasses, augmented reality (AR) / virtual reality (VR) headsets, etc.), a vehicle (e.g., a car, a motorcycle, a bicycle, etc.), an Internet of Things (IoT) device, etc.) used by a user to communicate over a wireless communication network. A UE may be mobile or may be fixed (e.g., at a particular time) and may communicate with a radio access network (RAN). As used herein, the term "UE" may be interchangeably referred to as an "access terminal" or "AT", "client device", "wireless device", "subscriber device", "subscriber terminal", "subscriber station", "user terminal" or UT, "mobile device", "mobile terminal", "mobile station" or variations thereof. In general, a UE may communicate with a core network via a RAN, and through the core network, the UE may be connected to an external network such as the Internet and to other UEs. Of course, other mechanisms for the UE to connect to the core network and / or the Internet are also possible, such as through a wired access network, a wireless local area network (WLAN) network (eg, based on Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc.), etc.

[0028] Depending on the network in which it is deployed, the base station may operate according to one of several RATs when communicating with the UE, and may be alternatively referred to as an access point (AP), a network node, a node B, an evolved node B (eNB), a next generation eNB (ng-eNB), a new radio (NR) node B (also referred to as a gNB or g node B), etc. The base station may be primarily used to support wireless access for the UE, including supporting data, voice and / or signaling connections for the supported UE. In some systems, the base station may simply provide edge node signaling functions, while in other systems, it may provide additional control and / or network management functions. The communication link through which the UE may send a signal to the base station is referred to as an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). The communication link through which the base station may send a signal to the UE is referred to as a downlink (DL) or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). As used herein, the term traffic channel (TCH) may refer to an uplink / reverse or downlink / forward traffic channel.

[0029] The term "base station" may refer to a single physical transmit receive point (TRP), or to multiple physical TRPs that may or may not be co-located. For example, where the term "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station corresponding to a cell of the base station. Where the term "base station" refers to multiple co-located physical TRPs, the physical TRP may be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). Where the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common resource via a transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, the non-co-located physical TRP may be a serving base station that receives measurement reports from the UE and a neighboring base station whose reference radio frequency (RF) signal (or simply "reference signal") the UE is measuring. Because as used herein, a TRP is the point from which a base station transmits and receives wireless signals, references to transmissions from a base station or receptions at a base station should be understood to refer to the specific TRP of the base station.

[0030] "RF" signals include electromagnetic waves of a given frequency that transmit information through the space between a transmitter and a receiver. As used herein, a transmitter may send a single RF signal or multiple RF signals to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple RF signals corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal" or simply a "signal," where it is clear from the context that the term "signal" refers to either a wireless signal or an RF signal.

[0031] According to various aspects, Figure 1 An exemplary wireless communication system 100 is illustrated. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 (labeled as "BS") and various UEs 104. The base stations 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, the macrocell base stations 102 may include eNBs (where the wireless communication system 100 corresponds to an LTE network) or gNBs (where the wireless communication system 100 corresponds to an NR network) or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0032] The base stations 102 may collectively form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) via a backhaul link 122, and interface with one or more positioning servers 172 (which may be part of the core network 170 or may be external to the core network 170) via the core network 170. The base stations 102 may perform, among other functions, functions related to one or more of the following: transmitting user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and device tracking, RAN information management (RIM), paging, positioning, and transmission of warning messages. The base stations 102 may communicate with each other directly or indirectly (e.g., via EPC / 5GC) via a backhaul link 134 (which may be wired or wireless).

[0033] The base station 102 can communicate with the UE 104 wirelessly. Each of the base stations 102 can provide communication coverage for a respective geographic coverage area 110. In one aspect, the base station 102 can support one or more cells in each geographic coverage area 110. A "cell" is a logical communication entity used to communicate with a base station (e.g., on a certain frequency resource (referred to as a carrier frequency, component carrier, carrier, frequency band, etc.)), and can be associated with an identifier (e.g., a physical cell identifier (PCI), a virtual cell identifier (VCI), a cell global identifier (CGI)) used to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells may be configured according to different protocol types (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB) or other protocol types) that can provide access to different types of UEs. Because a cell is supported by a specific base station, the term "cell" can refer to either or both of a logical communication entity and a base station supporting the logical communication entity, depending on the context. In addition, because the TRP is generally the physical transmission point of the cell, the terms "cell" and "TRP" can be used interchangeably. In some cases, the term "cell" can also refer to a geographic coverage area (e.g., a sector) of a base station within which a carrier frequency can be detected and used for communications within a portion of the geographic coverage area 110.

[0034] Although the geographic coverage areas 110 of adjacent macrocell base stations 102 may partially overlap (e.g., in a handover region), some of the geographic coverage areas 110 may substantially overlap with the larger geographic coverage areas 110. For example, a small cell base station 102' may have a geographic coverage area 110' that substantially overlaps with the geographic coverage areas 110 of one or more macrocell base stations 102. A network that includes both small cell base stations and macrocell base stations may be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB), which may provide services to a restricted group referred to as a closed subscriber group (CSG).

[0035] The communication link 120 between the base station 102 and the UE 104 may include uplink (also called reverse link) transmissions from the UE 104 to the base station 102 and / or downlink (also called forward link) transmissions from the base station 102 to the UE 104 .

[0036] The communication link 120 may use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 may be over one or more carrier frequencies. The allocation of carriers may be asymmetric with respect to uplink and downlink (e.g., more or fewer carriers may be allocated for the downlink than for the uplink).

[0037] The wireless communication system 100 may also include a wireless local area network (WLAN) access point (AP) 150 that communicates with a WLAN station (STA) 152 via a communication link 154 in an unlicensed spectrum (e.g., 5 GHz). When communicating in the unlicensed spectrum, the WLAN STA 152 and / or the WLAN AP 150 may perform a clear channel assessment (CCA) or listen before talk (LBT) procedure before communicating to determine whether a channel is available.

[0038] The small cell base station 102' can operate in a licensed and / or unlicensed spectrum. When operating in an unlicensed spectrum, the small cell base station 102' can adopt LTE or NR technology and use the same 5GHz unlicensed spectrum used by the WLAN AP 150. The small cell base station 102' adopting LTE / 5G in the unlicensed spectrum can improve the coverage of the access network and / or increase the capacity of the access network. NR in the unlicensed spectrum can be referred to as NR-U. LTE in the unlicensed spectrum can be referred to as LTE-U, Licensed Assisted Access (LAA) or MulteFire.

[0039] The wireless communication system 100 may also include a millimeter wave (mmW) base station 180 that communicates with the UE 182, which may operate in mmW frequencies and / or near mmW frequencies. Extremely high frequency (EHF) is a portion of RF in the electromagnetic spectrum. EHF has a range of 30Ghz to 300GHz and has a wavelength between 1 mm and 10 mm. Radio waves in this band may be referred to as millimeter waves. Near mmW can be extended down to a frequency of 3GHz with a wavelength of 100 mm. The super high frequency (SHF) band extends between 3Ghz and 30GHz and is also referred to as centimeter waves. Communications using mmW / near mmW radio frequency bands have high path loss and relatively short distances. The mmW base station 180 and the UE 182 may utilize beamforming (sending and / or receiving) on ​​the mmW communication link 184 to compensate for extremely high path loss and short distances. In addition, it will be appreciated that in alternative configurations, one or more base stations 102 may also use mmW or near mmW and beamforming for transmission. Accordingly, it will be appreciated that the foregoing description is merely exemplary and should not be construed as limiting the various aspects disclosed herein.

[0040] Transmit beamforming is a technique for focusing RF signals in a specific direction. Traditionally, when a network node (e.g., a base station) broadcasts an RF signal, it broadcasts the signal in all directions (omnidirectionally). With transmit beamforming, the network node determines where a given target device (e.g., UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thereby providing a faster (in terms of data rate) and stronger RF signal to the receiving device. In order to change the direction of the RF signal when transmitting, the network node can control the phase and relative amplitude of the RF signal at each of the one or more transmitters that broadcast the RF signal. For example, the network node can use an array of antennas (referred to as a "phased array" or "antenna array") that creates a beam of RF waves that can be "guided" to points in different directions without actually moving the antenna. Specifically, the RF current from the transmitter is fed to individual antennas with the correct phase relationship so that the radio waves from the individual antennas are added together to increase radiation in the desired direction and destructively in the undesired direction to suppress radiation.

[0041] The transmit beams can be quasi-co-located, which means that they appear to have the same parameters to the receiver (e.g., UE), regardless of whether the transmit antennas of the network nodes themselves are physically co-located. In NR, there are four types of quasi-co-location (QCL) relationships. Specifically, a given type of QCL relationship means that certain parameters about the second reference RF signal on the second beam can be derived from information about the source reference RF signal on the source beam. Therefore, if the source reference RF signal is QCL type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, average delay and delay spread of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type D, the receiver may use the source reference RF signal to estimate spatial reception parameters of a second reference RF signal transmitted on the same channel.

[0042] In receive beamforming, the receiver uses a receive beam to amplify the RF signal detected on a given channel. For example, the receiver may increase the gain setting and / or adjust the phase setting of the antenna array in a particular direction to amplify the RF signal received from that direction (e.g., to increase the gain level of the RF signal). Therefore, when a receiver is said to be beamforming in a certain direction, it means that the beam gain in that direction is high relative to the beam gain along other directions, or the beam gain in that direction is the highest compared to the beam gain in that direction of all other receive beams available to the receiver. This results in a stronger received signal strength (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR), etc.) of the RF signal received from that direction.

[0043] The transmit and receive beams may be spatially correlated. Spatial correlation means that the parameters for the transmit beam for the second reference signal may be derived from information about the receive beam for the first reference signal. For example, the UE may use a specific receive beam to receive a reference downlink reference signal (e.g., positioning reference signal (PRS), tracking reference signal (TRS), phase tracking reference signal (PTRS), cell-specific reference signal (CRS), channel state information reference signal (CSI-RS), primary synchronization signal (PSS), secondary synchronization signal (SSS), synchronization signal block (SSB), etc.) from a base station. The UE may then form a transmit beam for sending an uplink reference signal (e.g., uplink positioning reference signal (UL-PRS), sounding reference signal (SRS), demodulation reference signal (DMRS), PTRS, etc.) to the base station based on the parameters of the receive beam.

[0044] Note that a "downlink" beam can be a transmit beam or a receive beam, depending on the entity that forms it. For example, if the base station is forming a downlink beam for sending a reference signal to the UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, it is a receive beam for receiving a downlink reference signal. Similarly, an "uplink" beam can be a transmit beam or a receive beam, depending on the entity that forms it. For example, if the base station is forming an uplink beam, it is an uplink receive beam, and if the UE is forming an uplink beam, it is an uplink transmit beam.

[0045] In 5G, the spectrum in which wireless nodes (e.g., base stations 102 / 180, UEs 104 / 182) operate is divided into multiple frequency ranges: FR1 (from 450 to 6000 MHz), FR2 (from 24250 to 52600 MHz), FR3 (above 52600 MHz), and FR4 (between FR1 and FR2). In a multi-carrier system (such as 5G), one of the carrier frequencies is called a "primary carrier" or "anchor carrier" or "primary serving cell" or "PCell", and the remaining carrier frequencies are called "secondary carriers" or "secondary serving cells" or "SCells". In carrier aggregation, the anchor carrier is a carrier operating on the primary frequency (e.g., FR1) utilized by the UE 104 / 182 and the cell in which the UE 104 / 182 performs an initial radio resource control (RRC) connection establishment procedure or initiates an RRC connection re-establishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (however, this is not always the case). A secondary carrier is a carrier operating on a second frequency (e.g., FR2), where the second frequency may be configured once an RRC connection is established between the UE 104 and the anchor carrier, and may be used to provide additional radio resources. In some cases, the secondary carrier may be a carrier in an unlicensed frequency. The secondary carrier may contain only necessary signaling information and signals, for example, there may be no UE-specific signaling information and signals in the secondary carrier, because both the primary uplink carrier and the primary downlink carrier are usually UE-specific. This means that different UEs 104 / 182 in a cell may have different downlink primary carriers. This is also true for the uplink primary carrier. The network is able to change the primary carrier of any UE 104 / 182 at any time. This is done to, for example, balance the load on different carriers. Since a "serving cell" (whether PCell or SCell) corresponds to a carrier frequency / component carrier on which a base station is communicating, the terms "cell", "serving cell", "component carrier", "carrier frequency", etc. may be used interchangeably.

[0046] For example, still refer to Figure 1 , one of the frequencies utilized by the macrocell base station 102 may be an anchor carrier (or "PCell"), and the other frequencies utilized by the macrocell base station 102 and / or the mmW base station 180 may be secondary carriers ("SCells"). Simultaneous transmission and / or reception of multiple carriers enables the UE 104 / 182 to significantly increase its data transmission and / or reception rate. For example, two 20 MHz aggregated carriers in a multi-carrier system would theoretically result in a two-fold increase in data rate (i.e., 40 MHz) (compared to the data rate achieved with a single 20 MHz carrier).

[0047] The wireless communication system 100 may also include a UE 164, which may communicate with the macrocell base station 102 via a communication link 120 and / or communicate with the mmW base station 180 via a mmW communication link 184. For example, the macrocell base station 102 may support a PCell and one or more SCells for the UE 164, and the mmW base station 180 may support one or more SCells for the UE 164.

[0048] The wireless communication system 100 may also include one or more UEs (such as UE 190) indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as “side links”). Figure 1 In the example of FIG. 1 , UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of base stations 102 (e.g., through D2D P2P link 192, UE 190 can indirectly obtain cellular connectivity) and a D2D P2P link 194 with WLAN STA 152 connected to WLAN AP 150 (through D2D P2P link 194, UE 190 can indirectly obtain WLAN-based Internet connectivity). In an example, any well-known D2D RAT (such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), etc.) to support D2D P2P links 192 and 194.

[0049] According to various aspects, Figure 2AAn example wireless network architecture 200 is illustrated. For example, the 5GC 210 (also referred to as the Next Generation Core (NGC)) can be viewed functionally as a control plane function 214 (e.g., UE registration, authentication, network access, gateway selection, etc.) and a user plane function 212 (e.g., UE gateway function, access to data networks, IP routing, etc.) that operate in conjunction to form a core network. A user plane interface (NG-U) 213 and a control plane interface (NG-C) 215 connect the gNB 222 to the NGC 210, and specifically, to the control plane function 214 and the user plane function 212. In additional configurations, the ng-eNB 224 can also be connected to the 5GC 210 via the NG-C 215 to the control plane function 214 and the NG-U 213 to the user plane function 212. In addition, the eNB 224 can communicate directly with the gNB 222 via the backhaul connection 223. In some configurations, the new RAN 220 may have only one or more gNBs 222, while other configurations include one or more of both ng-eNBs 224 and gNBs 222. The gNB 222 or the ng-eNB 224 may communicate with the UE 204 (e.g., Figure 1 204). Another optional aspect may include a positioning server 230 that can communicate with the 5GC 210 to provide positioning assistance for the UE 204. The positioning server 230 may be implemented as a plurality of separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed on a plurality of physical servers, etc.), or alternatively, each may correspond to a single server. The positioning server 230 may be configured to support one or more positioning services for a UE 204 that may be connected to the positioning server 230 via the core network, the 5GC 210, and / or via the Internet (not shown). In addition, the positioning server 230 may be integrated into a component of the core network, or alternatively, may be external to the core network.

[0050] According to various aspects, Figure 2BAnother example wireless network structure 250 is illustrated. For example, the 5GC 260 can be functionally viewed as a control plane function provided by an access and mobility management function (AMF) 264, and a user plane function provided by a user plane function (UPF) 262, which operate in conjunction to form a core network (i.e., the 5GC 260). The user plane interface 263 and the control plane interface 265 connect the ng-eNB 224 to the 5GC 260, and specifically to the UPF 262 and the AMF 264, respectively. In an additional configuration, the gNB 222 may also be connected to the 5GC 260 via a control plane interface 265 to the AMF 264 and a user plane interface 263 to the UPF 262. In addition, the ng-eNB 224 may communicate directly with the gNB 222 via a backhaul connection 223, with or without a direct connection to the 5GC 260. In some configurations, the new RAN 220 may have only one or more gNBs 222, while other configurations include one or more of both ng-eNBs 224 and gNBs 222. The gNB 222 or the ng-eNB 224 may communicate with the UE 204 (e.g., Figure 1 The base stations of the new RAN 220 communicate with the AMF 264 over the N2 interface and with the UPF 262 over the N3 interface.

[0051] The functions of AMF 264 include registration management, connection management, reachability management, mobility management, lawful interception, transmission of session management (SM) messages between UE 204 and session management function (SMF) 266, transparent proxy service for routing SM messages, access authentication and access authorization, transmission of short message service (SMS) messages between UE 204 and short message service function (SMSF) (not shown), and security anchor function (SEAF). AMF 264 also interacts with authentication server function (AUSF) (not shown) and UE 204, and receives intermediate keys established as a result of the UE 204 authentication process. In the case of authentication based on UMTS (Universal Mobile Telecommunications System) Subscriber Identity Module (USIM), AMF 264 obtains security materials from AUSF. The functions of AMF 264 also include security context management (SCM). SCM receives keys from SEAF, where SCM uses the keys to derive keys specific to the access network. The functions of AMF 264 also include location service management for management services, transmission of location service messages between UE 204 and Location Management Function (LMF) 270 (which acts as location server 230), transmission of location service messages between new RAN 220 and LMF 270, allocation of EPS bearer identifiers for interworking with Evolved Packet System (EPS), and notification of mobility events of UE 204. In addition, AMF 264 also supports functions for non-3GPP (3rd Generation Partnership Project) access networks.

[0052] The functions of the UPF 262 include: acting as an anchor point for intra-RAT / inter-RAT mobility (when applicable), acting as an external protocol data unit (PDU) session point for interconnection to a data network (not shown), providing packet routing and forwarding, packet inspection, user plane policy rule enforcement (e.g., gating, redirection, traffic steering), lawful interception (user plane collection), traffic utilization reporting, quality of service (QoS) processing for the user plane (e.g., uplink / downlink rate enforcement, reflective QoS marking in the downlink), uplink traffic verification (service data flow (SDF) to QoS flow mapping), transmission level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and sending and forwarding one or more "end flags" to the source RAN node. The UPF 262 can also support the transmission of positioning service messages over the user plane between the UE 204 and a positioning server (e.g., a secure user plane positioning (SUPL) positioning platform (SLP) 272).

[0053] The functions of SMF 266 include session management, UE IP address allocation and management, selection and control of user plane functions, configuring traffic steering at UPF 262 to route traffic to the correct destination, controlling part of policy enforcement and QoS, and downlink data notification. The interface through which SMF 266 communicates with AMF 264 is called the N11 interface.

[0054] Another optional aspect may include an LMF 270 that can communicate with the 5GC 260 to provide positioning assistance for the UE 204. The LMF 270 can be implemented as multiple independent servers (e.g., physically independent servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, the LMFs 270 can each correspond to a single server. The LMF 270 can be configured to support one or more positioning services for the UE 204, and the UE 204 can be connected to the LMF 270 via the core network, the 5GC 260, and / or via the Internet (not shown). The SLP 272 can support similar functions to the LMF 270, but the LMF 270 can communicate with the AMF 264, the new RAN 220, and the UE 204 on the control plane (e.g., using interfaces and protocols intended to transmit signaling messages rather than voice or data), and the SLP 272 can communicate with the UE 204 and external clients ( Figure 2B ) communications (e.g., using protocols intended to carry voice and / or data, such as the Transmission Control Protocol (TCP) and / or IP).

[0055] Figure 3A , 3B 3C illustrates multiple exemplary components (represented by corresponding boxes) that may be incorporated into UE 302 (which may correspond to any UE described herein), base station 304 (which may correspond to any base station described herein), and network entity 306 (which may correspond to or embody any network function described herein, including application server 172, positioning server 230, LMF 270, and SLP 272) to support file transfer operations as taught herein. It will be appreciated that these components may be implemented in different types of devices (e.g., in an ASIC, in a system on a chip (SoC), etc.) in different implementations. The illustrated components may also be incorporated into other devices in the communication system. For example, other devices in the system may include components similar to the described components to provide similar functionality. In addition, a given device may include one or more components. For example, a device may include multiple transceiver components that enable the device to operate on multiple carriers and / or communicate via different technologies.

[0056] UE 302 and base station 304 each include a wireless wide area network (WWAN) transceiver 310 and 350, respectively, configured to communicate via one or more wireless communication networks (not shown), such as NR network, LTE network, GSM network, etc. (e.g., components for transmitting, components for receiving, components for measuring, components for tuning, components for avoiding transmitting, etc.). WWAN transceivers 310 and 350 can be connected to one or more antennas 316 and 356, respectively, for communicating with other network nodes (e.g., other UEs, access points, base stations (e.g., ng-eNB, gNB)), etc. via at least one designated RAT (e.g., NR, LTE, GSM, etc.) over a wireless communication medium of interest (e.g., a certain set of time / frequency resources in a specific spectrum). The WWAN transceivers 310 and 350 may be configured differently for transmitting and encoding signals 318 and 358 (e.g., messages, indications, information, etc.) according to a specified RAT, and conversely, for receiving and decoding signals 318 and 358 (e.g., messages, indications, information, pilots, etc.), respectively. Specifically, the WWAN transceivers 310 and 350 include one or more transmitters 314 and 354 for transmitting and encoding signals 318 and 358, respectively, and one or more receivers 312 and 352 for receiving and decoding signals 318 and 358, respectively.

[0057] UE 302 and base station 304 also include wireless local area network (WLAN) transceivers 320 and 360, respectively, at least in some cases. WLAN transceivers 320 and 360 can be connected to one or more antennas 326 and 366, respectively, for communicating via at least one designated RAT (e.g., WiFi, LTE-D, The WLAN transceivers 320 and 360 may be configured differently to transmit and encode signals 328 and 368 (e.g., messages, indications, information, etc.) according to a specified RAT, and conversely, to receive and decode signals 328 and 368 (e.g., messages, indications, information, pilots, etc.), respectively. Specifically, the WLAN transceivers 320 and 360 include one or more transmitters 324 and 364, respectively, for transmitting and encoding signals 328 and 368, respectively, and one or more receivers 322 and 362, respectively, for receiving and decoding signals 328 and 368, respectively.

[0058] The transceiver circuitry including at least one transmitter and at least one receiver may include an integrated device (e.g., a transmitter circuit and a receiver circuit embodied as a single communication device) in some embodiments, may include separate transmitter devices and separate receiver devices in some embodiments, or may be embodied in other ways in other embodiments. In one aspect, the transmitter may include or be coupled to multiple antennas (e.g., antennas 316, 326, 356, 366), such as an antenna array, which allows the corresponding device to perform transmit "beamforming" as described herein. Similarly, the receiver may include or be coupled to multiple antennas (e.g., antennas 316, 326, 356, 366), such as an antenna array, which allows the corresponding device to perform receive beamforming as described herein. In one aspect, the transmitter and receiver may share the same multiple antennas (e.g., antennas 316, 326, 356, 366) so that the corresponding device only receives or transmits at a given time, rather than receiving or transmitting at the same time. The wireless communication devices of UE 302 and / or base station 304 (eg, one or both of transceivers 310 and 320 and / or transceivers 350 and 360 ) may also include a network listening module (NLM) or the like for performing various measurements.

[0059] UE 302 and base station 304 also include satellite positioning system (SPS) receivers 330 and 370, at least in some cases. SPS receivers 330 and 370 can be connected to one or more antennas 336 and 376, respectively, for receiving and / or measuring SPS signals 338 and 378 (such as global positioning system (GPS) signals, global navigation satellite system (GLONASS) signals, Galileo signals, Beidou signals, Indian regional navigation satellite system (NAVIC), Quasi-Zenith Satellite System (QZSS), etc.). SPS receivers 330 and 370 can include any suitable hardware and / or software for receiving and processing SPS signals 338 and 378, respectively. SPS receivers 330 and 370 appropriately request information and operations from other systems, and use measurements obtained by any suitable SPS algorithm to perform calculations necessary to determine the location of UE 302 and base station 304.

[0060] The base station 304 and the network entity 306 each include at least one network interface 380 and 390, respectively, for communicating with other network entities (e.g., components for sending, components for receiving, etc.). For example, the network interfaces 380 and 390 (e.g., one or more network access ports) can be configured to communicate with one or more network entities via a wired or wireless backhaul connection. In some aspects, the network interfaces 380 and 390 can be implemented as transceivers, which are configured to support wired or wireless signal communications. Such communications can involve, for example, sending and receiving messages, parameters, and / or other types of information.

[0061] UE 302, base station 304, and network entity 306 also include other components that can be used in conjunction with the operations disclosed herein. UE 302 includes a processor circuit that implements a processing system 332 for providing functions related to, for example, positioning operations and for providing other processing functions. Base station 304 includes a processing system 384 for providing functions related to, for example, positioning operations disclosed herein and for providing other processing functions. Network entity 306 includes a processing system 394 for providing functions related to, for example, positioning operations disclosed herein and for providing other processing functions. Processing systems 332, 384, and 394 can therefore provide components for processing, such as components for determining, components for calculating, components for receiving, components for sending, components for indicating, etc. In one aspect, processing systems 332, 384, and 394 may include, for example, one or more general-purpose processors, multi-core processors, ASICs, digital signal processors (DSPs), field programmable gate arrays (FPGAs), or other programmable logic devices or processing circuits.

[0062] UE 302, base station 304, and network entity 306 include memory circuitry implementing memory components 340, 386, and 396, respectively (e.g., each including a memory device), for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Thus, memory components 340, 386, and 396 may provide means for storing, means for retrieving, means for maintaining, etc. In some cases, UE 302 and base station 304 may include uplink streaming service components 342 and 388, respectively, and network entity 306 may include QoS allocation component 398. Components 342, 388, and 398 may be hardware circuits that are part of or coupled to processing systems 332, 384, and 394, respectively, which when executed cause UE 302, base station 304, and network entity 306 to perform the functions described herein. In other aspects, components 342, 388, and 398 can be external to processing systems 332, 384, and 394 (e.g., as part of a modem processing system, integrated with another processing system, etc.). Alternatively, components 342, 388, and 398 can be memory modules (e.g., memory modules) stored in memory components 340, 386, and 396, respectively. FIG. 3A to FIG. 3C ), which, when executed by the processing systems 332, 384, and 394 (or a modem processing system, another processing system, etc.), causes the UE 302, the base station 304, and the network entity 306 to perform the functions described herein.

[0063] UE 302 may include one or more sensors 344 coupled to processing system 332 to provide means for sensing and detecting motion and / or orientation information that is independent of motion data derived from signals received by WWAN transceiver 310, WLAN transceiver 320, and / or SPS receiver 330. For example, sensor(s) 344 may include an accelerometer (e.g., a microelectromechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), and / or any other type of motion detection sensor. In addition, sensor(s) 344 may include a variety of different types of devices and combine their outputs to provide motion information. For example, sensor(s) 344 may use a combination of a multi-axis accelerometer and an orientation sensor to provide the ability to calculate a position in a 2D and / or 3D coordinate system.

[0064] In addition, the UE 302 includes a user interface 346 that provides means for providing indications to the user (e.g., audible and / or visual indications) and / or for receiving user input (e.g., when the user activates a sensing device such as a keyboard, touch screen, microphone, etc.). Although not shown, the base station 304 and the network entity 306 may also include a user interface.

[0065] Referring to the processing system 384 in more detail, in the downlink, IP packets from the network entity 306 may be provided to the processing system 384. The processing system 384 may implement functions for the RRC layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Medium Access Control (MAC) layer. The processing system 384 can provide RRC layer functions associated with broadcasting system information (e.g., master information block (MIB), system information block (SIB)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with transmission of upper layer PDUs, error correction through automatic repeat request (ARQ), concatenation, segmentation and reassembly of RLC service data units (SDUs), re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; MAC layer functions associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0066] The transmitter 354 and the receiver 352 may implement layer 1 (L1) functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on the transmission channel, forward error correction (FEC) encoding / decoding of the transmission channel, interleaving, rate matching, mapping to physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The transmitter 354 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols may then be divided into parallel streams. Each stream may then be mapped to an orthogonal frequency division multiplexing (OFDM) subcarrier, multiplexed with a reference signal (e.g., pilot) in the time domain and / or frequency domain, and then combined together using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. The channel estimate from the channel estimator can be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate can be derived from a reference signal and / or channel condition feedback sent by the UE 302. Each spatial stream can then be provided to one or more different antennas 356. The transmitter 354 can modulate the RF carrier with the corresponding spatial stream for transmission.

[0067] At the UE 302, the receiver 312 receives the signal through its respective (multiple) antennas 316. The receiver 312 recovers the information modulated onto the RF carrier and provides the information to the processing system 332. The transmitter 314 and the receiver 312 implement layer 1 functions associated with various signal processing functions. The receiver 312 can perform spatial processing on the information to recover any spatial streams destined for the UE 302. If multiple spatial streams are destined for the UE 302, they can be combined into a single OFDM symbol stream by the receiver 312. The receiver 312 then converts the OFDM symbol stream from the time domain to the frequency domain using a fast Fourier transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols and reference signals on each subcarrier are recovered and demodulated by determining the most likely signal constellation point sent by the base station 304. These soft decisions can be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally sent on the physical channel by the base station 304. The data and control signals are then provided to the processing system 332, which implements Layer 3 (L3) and Layer 2 (L2) functions.

[0068] In the uplink, the processing system 332 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the core network. The processing system 332 is also responsible for error detection.

[0069] Similar to the functions described in conjunction with downlink transmissions performed by the base station 304, the processing system 332 provides RRC layer functions associated with system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functions associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions associated with transmission of upper layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; MAC layer functions associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing MAC SDUs from transport blocks, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), priority processing, and logical channel prioritization.

[0070] Channel estimates derived by the channel estimator from a reference signal or feedback sent by the base station 304 may be used by the transmitter 314 to select appropriate coding and modulation schemes and to facilitate spatial processing. The spatial streams produced by the transmitter 314 may be provided to different (multiple) antennas 316. The transmitter 314 may modulate an RF carrier with a corresponding spatial stream for transmission.

[0071] The uplink transmission is processed at the base station 304 in a manner similar to that described in conjunction with the receiver functionality at the UE 302. The receiver 352 receives the signal through its corresponding antenna(s) 356. The receiver 352 recovers the information modulated onto the RF carrier and provides the information to the processing system 384.

[0072] In the uplink, the processing system 384 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, control signal processing to recover IP packets from the UE 302. The IP packets from the processing system 384 may be provided to the core network. The processing system 384 is also responsible for error detection.

[0073] For convenience, UE 302, base station 304 and / or network entity 306 may FIG. 3A to FIG. 3C 1 and 2. The block diagram of FIG. 1 is shown as including various components that can be configured according to various examples described herein. However, it should be understood that the blocks shown may have different functions in different designs.

[0074] The various components of UE 302, base station 304, and network entity 306 may communicate with each other via data buses 334, 382, ​​and 392, respectively. FIG. 3A to FIG. 3C The components of can be implemented in various ways. In some embodiments, FIG. 3A to FIG. 3C The components of may be implemented in one or more circuits (e.g., one or more processors and / or one or more ASICs (which may include one or more processors)). Here, each circuit may use and / or combine at least one memory component to store information or executable code used by the circuit to provide the function. For example, some or all of the functions represented by blocks 310 to 346 may be implemented by (multiple) processors and memory components of UE 302 (e.g., by executing appropriate code and / or by appropriately configuring processor components). Similarly, some or all of the functions represented by blocks 350 to 388 may be implemented by (multiple) processors and memory components of base station 304 (e.g., by executing appropriate code and / or by appropriately configuring processor components). In addition, some or all of the functions represented by blocks 390 to 398 may be implemented by (multiple) processors and memory components of network entity 306 (e.g., by executing appropriate code and / or by appropriately configuring processor components). For simplicity, various operations, actions and / or functions are described herein as being performed by "UE", "base station", "network entity", etc. However, as will be appreciated, these operations, actions and / or functions may actually be performed by specific components or combinations of components of the UE, base station, network entity, etc. (e.g., processing systems 332, 384, 394, transceivers 310, 320, 350 and 360, memory components 340, 386 and 396, components 342, 388 and 398, etc.).

[0075] When a UE supporting multimedia (e.g., voice) services reaches the edge of network coverage (e.g., the edge of a WWAN such as an LTE or NR network), the network typically checks a handover threshold and decides whether to handover the UE to a different radio access technology (RAT) based on measurement reports from the UE. For example, although LTE and NR networks were initially deployed to support data services, LTE and NR networks have evolved to increasingly support real-time multimedia-based services such as real-time uplink streaming uplink real-time streaming framework (FLUS), multimedia telephony service (MTSI) for Internet Protocol (IP) Multimedia Subsystem (IMS), virtual reality, augmented reality, telepresence, split presentation (where the network shares the graphics processing load with the UE), and the like.

[0076] The uplink coverage in some networks (e.g. LTE and NR networks) tends to be limited, or at least more limited than the downlink coverage. Therefore, a problem arises that the uplink coverage from the UE to the base station (e.g. eNB, gNB) at the edge of the network tends to be weaker (e.g. resulting in higher packet loss rate (PLR) or block error rate (BLER)). Therefore, thresholds are defined to handover multimedia-based sessions to avoid further degradation in service due to increased packet loss. In these situations, the UE checks the handover threshold and decides when to handover from one radio cell, for example to a neighboring radio cell with a similar radio access technology, or to a completely different RAT such as WLAN.

[0077] In general, the handover threshold may vary even from one UE to another, since the impact of packet loss on a multimedia service may depend on various factors, such as the multimedia codec or codec mode being used by the service, the packet loss concealment (PLC) algorithm implemented at the receiving UE, and the jitter (or de-jitter) buffer management (JBM) implementation used at the receiving UE. For example, one multimedia codec that may be used is the Adaptive Multi-Rate (AMR) audio codec, which uses link adaptation to select from one of eight different bit rates based on link conditions and is typically used in circuit-switched networks. Another multimedia codec is the Adaptive Multi-Rate Wideband (AMR-WB), which is similar to the AMR codec, except that AMR-WB provides improved voice quality due to a wider voice bandwidth compared to the AMR audio codec. Yet another multimedia codec, Enhanced Voice Service (EVS), provides greater robustness than AMR and AMR-WB, and also provides a channel-aware mode that includes a packet loss concealment mechanism based on partial redundancy, resulting in improved quality / intelligibility relative to the EVS non-channel-aware mode or AMR / AMR-WB.

[0078] Furthermore, PLC algorithms such as zero insertion, waveform replacement, model-based approaches, etc. can mask the effects of packet loss to some extent. This is because multimedia signals are sent over the network in the form of packets that may reach their destination via different routes and thus arrive late, corrupted, out of order, or not at all. Relatedly, because packets may arrive at the decoder out of order or with random jitter in the arrival times, JBM implementations may use different techniques to absorb the jitter in packet arrival times so that multimedia packets can be fed to the decoder at evenly spaced periodic intervals. Therefore, there are various factors that may affect the packet loss that each UE can tolerate to maintain a high-quality multimedia session.

[0079] One of the challenges in setting appropriate handover thresholds, which are typically handled at the mobile infrastructure in a WWAN or other wireless network (e.g., at a gNB in ​​an NR network), is to ensure that the end-to-end (e2e) error rate across the transmission path from the media sender to the media receiver does not exceed the maximum packet loss that the codec, PLC, and JBM can handle, and does not result in a significant degradation in quality and / or intelligibility. For example, Figure 4 An example end-to-end communication flow between two UEs conducting a multimedia-based communication session according to various aspects of the present disclosure is illustrated. Figure 4 In the example of , a multimedia transmission in a direction from UE 402-2 to UE 402-1 (which may correspond to any UE described herein) is sent from UE 402-2 to its serving gNB 422-2 (e.g., any base station described herein) on an uplink 432. gNB 422-2 forwards the transmission to UE 402-1's serving gNB 422-1 (e.g., any other base station described herein) via a backhaul link 434. Serving gNB 422-1 then sends the multimedia transmission to recipient UE 402-1 on a downlink 436. Similarly, in the reverse direction, a multimedia transmission from UE 402-1 to UE 402-2 is sent from UE 402-1 to serving gNB 422-1 on an uplink 442, which then forwards the transmission to UE 402-2's serving gNB 422-2 via a backhaul link 444. The serving gNB 422-2 then sends the multimedia transmission on the downlink 446 to the receiving UE 402-2.

[0080] Assuming that there is no or negligible packet loss on the backhaul links 434, 444, for multimedia transmissions sent in the direction from UE 402-2 to UE 402-1, the sum of the PLRs on the uplink 432 and downlink 436 should be less than or equal to the maximum PLR achieved by the codec, PLC algorithm, and JBM used at UE 402-1. Similarly, in the direction of sending multimedia from UE 402-1 to UE 402-2, the sum of the PLRs on the uplink 442 and downlink 446 should be less than or equal to the maximum PLR achieved by the codec, PLC algorithm, and JBM used at UE 402-2.

[0081] FLUS enables real-time media streaming from a source entity (also referred to as a "FLUS source" or simply "source") to a sink entity (also referred to as a "FLUS sink" or simply "sink"). Figure 4, for transmission from UE 402-1 to UE 402-2, UE 402-1 will be the FLUS source entity, and UE 402-2 will be the FLUS sink entity. FLUS provides IMS-based and non-IMS-based instantiations. IMS / MTSI-based instantiations enable real-time media streams to be established between two UEs or between a source entity and a sink entity within and across operator networks. Compared to MTSI, in which limited types of QoS are available for voice or video media, FLUS can provide a wider range of QoS operations in terms of, for example, maximum delay, available bandwidth, or target PLR. In non-IMS-based instantiations, FLUS can be operated as a more general framework that is controlled by a RESTful application programming interface (API) and supports other media plane protocols (i.e., not based on IMS or MTSI). In addition to providing a wider range of QoS operations on radio links, FLUS can also provide other advanced features, such as signaling of immersive media (e.g., virtual reality, augmented reality) on existing networks.

[0082] The FLUS source entity and the FLUS sink entity can support point-to-point transmission of voice / audio, video and text. The FLUS source entity (which can be embodied in a single UE or distributed between a UE and a separate audio-visual capture device) can support all or a subset of the FLUS features. When used as a general framework, only the FC procedures (control procedures for source and sink) used to establish a FLUS session need to be supported by the source and sink entities. When provided as part of an IMS / MTSI service, the source and sink entities should support the IMS control plane and media plane procedures, and the quality of service is determined by the MTSI service policy.

[0083] As used herein, a FLUS session is a logical association between a source entity and a sink entity in which media content of one or more media types (e.g., voice, audio, video) can be sent from the source to the sink. A media session is a subset or portion of a FLUS session, including the duration of establishing a media session, the time period during which media content can be sent from a FLUS source to a FLUS sink, and the duration of terminating a media session. One or more media sessions can be delivered during a FLUS session. A media stream is content sent from a FLUS source to a FLUS sink within a media session.

[0084] Figure 5An exemplary uplink streaming service architecture 500 according to various aspects of the present disclosure is illustrated. The uplink streaming service architecture 500 is based on a FLUS source 510 located in a UE (e.g., any UE described herein) and a FLUS sink 520 located in another UE or a network. For example, the FLUS sink 520 can be located at a base station (e.g., any base station described herein) or other network entity. The FLUS source 510 receives media content from one or more media capture devices (e.g., cameras, microphones, etc.). As used herein, one or more capture devices are considered to be part of or connected to the UE.

[0085] When the FLUS sink 520 is located in the UE, the FLUS sink forwards the media content to the decoding and rendering functions. When the FLUS sink 520 is located in the network, the FLUS sink 520 can forward the media content to the processing or distribution sub-function. The FLUS sink 520 can be used as a media gateway function (MGW) and / or an application function (AF).

[0086] The "F" reference point connects the FLUS source 510 and the FLUS sink 520. The "F" reference point enables a single FLUS session to be established and controlled. The "F" reference point also enables the FLUS sink 520 and the FLUS source 510 to mutually authenticate and authorize each other. The FLUS source 510 and the FLUS sink 520 are each divided into a media source and sink (referred to as "FU" endpoints), a control source and sink (referred to as "FC" endpoints), a remote controller and a remote control target (referred to as "F-RC" endpoints), and an auxiliary sender and receiver (referred to as "FA" endpoints).

[0087] The UE, FLUS source 510 and FLUS sink 520 are considered logical functions and therefore do not need to be located in the same physical device; they can be distributed over multiple physical devices and interconnected via other interfaces. In addition, multiple FA and F-RC endpoints can exist in a single FLUS source 510. The FA and F-RC endpoints are independent of the FLUS sink 520 and depend on the service initiated. The "F" reference point supports security functions for confidentiality protection of all sub-functions.

[0088] The FLUS architecture is described in 3GPP Technical Specification (TS) 26.238, the entire contents of which are incorporated herein by reference. Therefore, for the sake of brevity, further details will not be described here.

[0089] Real-time uplink media flows (e.g., FLUS) may be added and used in an MTSI session. In order to add FLUS-specific media to an MTSI session and give the FLUS-specific media appropriate QoS treatment suitable for real-time uplink streaming in place of a regular session, a method is needed that enables initiation of selection of an appropriate QoS for a specific use of FLUS. The initial QoS may be based on different 5G QoS Indicator (5QI) and / or QoS Class Identifier (QCI) values ​​that are attributed for use with real-time uplink flows.

[0090] For the above QoS requirements, it is not sufficient to use "a=group:FLUS", because there are at least five defined real-time uplink flow 5QI / QCIs to choose from. Furthermore, it is neither desirable nor sufficient to assume that for all FLUS applications, the network operator always selects a single FLUS out of the five FLUS 5QI / QCIs for a certain media, because this would be suitable only for a portion of the possible FLUS use cases and at best be suboptimal for other FLUS use cases. It is also assumed that it is not feasible to define new, separate applications (even if part of an existing MTSI application) for different FLUS use cases in order to be able to maintain a 1:1 mapping approach between 5QI / QCI and (application, media type) tuples.

[0091] As a solution to the problem of insufficient QoS specification, it has been proposed to include in the Session Description Protocol (SDP) for a FLUS session a non-authoritative QoS hint for each FLUS-tagged media (e.g., one or more parameters indicating the desired QoS), taken from the current settings in the FLUS application or set by the end user of the device who knows the needs of the current use case. This would allow the Policy Control Function (PCF) / Policy and Charging Rules Function (PCRF) in the core network to (authoritatively) select which 5QI / QCI to use, both matching the current user subscription and current use of the FLUS device, assuming that the FLUS device itself should be available for all FLUS use cases (e.g., from ultra-low latency to fairly relaxed but still "live" broadcast latency). The QoS hints may include a "latency" attribute that may be defined as an ordered list of values ​​(such as "lowest", "low", "medium", "high", and "highest"), and a "loss" attribute that may be similarly defined as an ordered list of values ​​(such as "lowest", "low", "medium", "high", and "highest").

[0092] The "loss" value describes the maximum expected packet loss rate for a FLUS session and may be expressed as a percentage by a zero-based integer or a non-zero real value. The "latency" value describes the maximum expected packet delay for a FLUS session and may be expressed in milliseconds (ms) by a zero-based integer or a non-zero real value. Currently, the "loss" value included in the SDP offer represents half of the expected maximum end-to-end packet loss, assuming that the SDP initiator (e.g., a FLUS source or sink) and the responder (e.g., the other of the FLUS source and sink) will share the packet loss budget equally. The "latency" value included in the SDP offer typically represents half of the expected maximum end-to-end packet delay, assuming that the initiator and the responder will share the packet delay budget equally.

[0093] A "loss" value received in the SDP answer that is the same as the SDP offer is considered as the SDP responder accepting to share the end-to-end packet loss budget equally, which value is half of the resulting maximum end-to-end packet loss. A "loss" value received in the SDP answer that is greater than the SDP offer is considered as the SDP responder not being able to share the end-to-end packet loss budget equally, the value in the SDP answer represents the SDP responder's portion, and the resulting total maximum end-to-end loss hint is equal to the sum of the "loss" parameters from the SDP offer and the SDP answer.

[0094] A "delay" value received in the SDP answer that is the same as the SDP offer is considered as an indication that the SDP answerer accepts to share the end-to-end packet delay budget equally, and that this value is half of the resulting maximum end-to-end packet delay. A "delay" value received in the SDP answer that is greater than the one in the SDP offer is considered as an indication that the SDP answerer does not share the end-to-end packet delay budget equally, that the value in the SDP answer represents the SDP answerer's portion, and that the resulting total maximum end-to-end delay hint is equal to the sum of the "delay" parameters from the SDP offer and the SDP answer.

[0095] Based on the loss and latency parameters in the QoS hints exchanged between the initiator and the answerer during the SDP session, the network assigns the appropriate QoS treatment, ie, the appropriate QCI / 5QI.

[0096] This QoS hinting solution can be used across all services that provide uplink streaming services, such as FLUS and MTSI. The solution can even be extended to services where specific loss and latency requirements may vary significantly, such as conversational virtual reality and / or augmented reality, telepresence, split presence, cloud presence, etc. Therefore, it is important to consider how QoS hinting can be used more generally for these other services and future services.

[0097] When the SDP initiator proposes a certain QoS, it may select the QoS based on the user's subscription, the type / quality of the service being provided (e.g., breaking news coverage vs. live streaming on a social network), and the initiator's link requirements in order to provide a specific quality of experience (e.g., voice quality). This last factor (i.e., the link loss rate required to achieve a specific voice quality) is based on the UE's functional implementation, such as JBM and PLC. Such variations in implementation may require different target loss rates to achieve the same voice quality, even if the UE is part of the same mobile network operator's (MNO's) network. This consideration has been addressed by allowing the media receiver to indicate the maximum e2e PLR ​​it can handle based on its specific implementation.

[0098] In some cases, the SDP responder may require a stricter latency than initiated, for example, if the UE's receive-decode-render processing chain (including the lack of asynchronous time warp / partial reprojection functionality) requires more time to render the media within the end-to-end target latency for more latency-sensitive services. There may also be situations where the initiator does not request the strictest QoS allowed by its subscription. For example, a UE and its subscription may be able to support semi-professional news reporting while also supporting social video sharing applications. Or a virtual reality head-mounted display (HMD) may support both cloud rendering and split rendering, each of which may have very different latency requirements. In such a situation, the responder may be able to negotiate a QoS level that is allowed by the initiator's subscription and that is stricter than what it initiated. Therefore, the responder should have the ability to indicate that a stricter QoS than initiated is required.

[0099] When the FLUS sink is located in the core network and there is no wireless link between the gNB / eNB and the FLUS sink (i.e., there is a wired connection between the gNB / eNB and the FLUS sink), the loss on this link can be considered to be essentially zero, and the latency can be considered to be very low (if not zero). It may be beneficial for the FLUS sink to be able to indicate this very low loss / latency in the SDP answer for reserving appropriate QoS resources on the radio link to the FLUS source (i.e., the radio link between the UE as the FLUS source and the serving base station). Furthermore, if there is a use case where the network FLUS sink sends an SDP offer, it would also be beneficial to be able to indicate this very low loss / latency in the initiation.

[0100] Even for non-FLUS services, there may be other scenarios where one of the links in the end-to-end path may have very low loss / latency, which should be appropriately indicated to the network so that any radio QoS reservations can be made effectively. Such scenarios may include, for example, MTSI or conversational AR / VR sessions where one of the terminals is connected via a wired or very low loss / latency connection.

[0101] There are various solutions to the problem that the SDP answerer needs to request a stricter QoS. As a first solution, as described above, a QoS hint can be used for half of the expected maximum end-to-end loss / delay. In this solution, as described above, the "loss" value included in the SDP offer represents half of the expected maximum end-to-end packet loss, assuming that the initiator and the answerer will share the packet loss budget equally. Similarly, the "delay" value included in the SDP offer represents half of the expected maximum end-to-end packet delay, assuming that the initiator and the answerer will share the packet delay budget equally.

[0102] However, although this solution provides the option for the responder to request a higher loss / delay value than initiated, it does not provide the option for the responder to request a lower loss / delay value. This means that the end-to-end loss / delay will need to be at least twice as much as initiated. Even if the solution can be modified to allow the responder to request a lower loss / delay value than initiated, the lowest loss / delay that the responder can request is zero, which will prevent the end-to-end loss / delay from being lower than any loss / delay initiated. For example, an SDP initiator (e.g., a FLUS sink) may provide a 50ms delay on its radio link, but this may not be good enough for an SDP responder (e.g., a FLUS source), which may require, for example, an end-to-end delay of 30ms. Even if the responder reduces its delay to 0 (which is unlikely), the end-to-end delay will still be 50ms. Under this solution, the responder cannot indicate to the initiator that it needs a better delay.

[0103] Another challenge with this approach is to address the problem of insufficient QoS in the proposal. If the FLUS source sends an Initiation, this may result in an overly strict QoS assignment. For example, when the FLUS source sends an Initiation with half of its expected end-to-end loss / latency, and the network FLUS sink responds with approximately zero loss / latency, the resulting total end-to-end loss / latency will be half of what the FLUS source required (because the FLUS source asked for half of what it needed). If the PCRF / PCF only looks at the loss / latency values ​​in the Initiation (from the FLUS source on its network), it may choose an overly strict QoS treatment.

[0104] Also, if the network FLUS sink sends an origination, and the origination indicates very low loss / latency, then the FLUS source (answerer) would appear to be encouraged to try to match this very low value for its own radio link. This may place unnecessarily stringent QoS requirements on the FLUS source's radio link, when in reality it may be less stringent because the FLUS sink does not introduce any significant loss or latency. It is therefore unclear how the network FLUS sink can indicate very low loss / latency and encourage the FLUS source to take advantage of this with a more relaxed QoS on its radio link.

[0105] To address at least some of these issues, the answerer may reject the SDP INVITE that includes the initiation, and then send a new initiation with lower loss / latency to meet its requirements. However, in some situations, having the answerer reject the initiation and then send a re-initiation may not be acceptable. For example, if the initiator is a FLUS source and the answerer is a FLUS sink (in the network or another UE), having the FLUS sink reject the initiation and then make an initiation to receive the FLUS flow is a problematic use case.

[0106] Another approach is for the responder to reject the INVITE with an SDP 488 (Not Acceptable Here) message and include the desired (stricter) QoS penalty / delay. This will provide an indication to the initiator of what QoS hint value to include in the re-initiation. However, this still has some of the disadvantages mentioned above.

[0107] Therefore, the present disclosure provides a technique that enables a FLUS sink and source to negotiate end-to-end loss / delay via SDP. In one aspect, the definitions of "loss" and "delay" may be modified to have these SDP attributes representing end-to-end loss / delay as follows. Under the assumption that the initiator and responder will share the packet loss budget equally, the "loss" value included in the SDP initiation may represent the expected maximum end-to-end packet loss. Under the assumption that the initiator and responder will share the packet delay budget equally, the "delay" value included in the SDP initiation may represent the expected maximum end-to-end packet delay. In one aspect, the loss value may describe the maximum expected packet loss rate in units of percentage (but without the "%" sign) as a zero-based integer or non-zero real value. The delay value may describe the maximum expected packet delay in milliseconds as, for example, a zero-based integer or non-zero real value. Based on these values, the network (e.g., PCF / PCRF) can use half of the end-to-end loss / latency to select appropriate QoS treatment (e.g., QCI / 5QI) for each radio link (i.e., the radio link for the FLUS source and the radio link for the FLUS sink, both of which are UEs).

[0108] In some cases, there may still be problems when the network FLUS sink sends an SDP response in response to an initiation from a FLUS source. For example, in the first case, the FLUS sink may respond with an end-to-end loss delay value twice that initiated by the FLUS source, because it understands that its link will introduce negligible loss / delay, and the PCF / PCRF will use half of the end-to-end delay when selecting the QCI / 5QI. However, if the FLUS source providing the service believes that twice the loss / delay it initiated is unacceptable for the service, it can terminate the session. As another example, in the second case, the FLUS sink may respond with an end-to-end loss delay value equal to that initiated by the FLUS source. In this case, the PCRF / PCF will select a QCI / 5QI that is too strict to meet half of the loss / delay initiated.

[0109] Similar problems may arise if the network FLUS sink sends the SDP Initiate. For example, as a first case, the FLUS sink may set the end-to-end loss / latency to what the service actually expects. However, when the PCF / PCRF sees this, it will not understand that the FLUS sink introduces negligible loss / latency, and will select a QCI / 5QI that is not necessarily strict, specifically, half of the end-to-end loss / latency. As another example, in the second case, the FLUS sink may set the end-to-end loss / latency to twice what the service actually expects. This will allow the PCF / PCRF to select an appropriate QCI / 5QI, i.e., half of twice the expected loss / latency. However, the answering client may decide that the (double) loss / latency in the SDP Initiate is too high, and try to lower the end-to-end value in the SDP Answer. This will result in the same overly strict QoS reservation for the radio link as described in the first case.

[0110] Therefore, in some cases, it may still be necessary for the network FLUS sink to indicate to the PCF / PCRF that the network can allocate the entire end-to-end loss / delay to the radio link between the FLUS source and the base station, and therefore there is no reliable way to avoid selecting an overly stringent QCI / 5QI for the radio link.

[0111] Therefore, the present disclosure provides additional techniques for FLUS source and sink to negotiate end-to-end and per-link loss / latency via SDP.In one aspect, in addition to the above solutions, optional parameters can be defined that will allow the initiator and responder to indicate how to distribute end-to-end loss / latency across their radio links.

[0112] In one aspect, the QoS prompt may include an uplink prompt value and a downlink prompt value. The uplink prompt value indicates the expected loss / delay on the uplink of the initiator / responder, and the downlink prompt value indicates the expected loss / delay on the downlink of the initiator / responder. In this way, the network FLUS sink can use these optional uplink / downlink parameters to explicitly indicate the approximate zero loss / delay on its link, so that the network can allocate the entire expected loss / delay to the UEFLUS source. For example, the network FLUS sink can initiate / respond to a downlink prompt value of "0" (to indicate the near-zero loss / delay of its return link from the base station to the FLUS sink). It can also optionally include an uplink prompt value, which is applied to the return link between the FLUS sink and the base station when it is expected to send traffic in this direction (e.g., a TCP confirmation (ACK) sent in the opposite direction of the media transmission transmitted by TCP). The UE FLUS source can specify end-to-end loss / delay or specific uplink loss / delay in its initiation / response, and optionally specify downlink loss / delay. The network can then allocate the entire loss / delay to the radio link of the UE FLUS source, rather than to the network FLUS sink.

[0113] The uplink and downlink values ​​are independently optional. That is, they do not have to be provided in pairs. This allows for the following two scenarios: 1) the initiator or responder does not have any preference for one of the transmission directions, and / or 2) the QoS hint is used in a unidirectional "send only" or "receive only" flow, and therefore, setting the uplink or downlink values ​​would be meaningless. For example, for an uplink-only flow where no traffic is sent on the UE downlink, the FLUS source does not care, and therefore does not need to specify the downlink parameters for the FLUS sink.

[0114] In one aspect, the uplink prompt value is a QoS prompt value on the uplink of the initiator / responder and may be represented by a zero-based integer, a non-zero real number, or a token (e.g., an index value or a value to be extended later). The downlink prompt is a QoS prompt value on the downlink of the initiator / responder and may be represented by a zero-based integer, a non-zero real number, or a token (e.g., an index value or a value to be extended later).

[0115] Note that the above QoS Hint parameter should appear only once in an Initiation / Answer. If a QoS Hint parameter is not included, it should be interpreted that the UE and the application have no preference for any QoS value for that QoS Hint parameter, and anything that the network can offer is equally acceptable.

[0116] Figure 6An example call flow 600 between a UE FLUS source 602 and a network FLUS sink 604 according to aspects of the present disclosure is illustrated. The UE FLUS source 602 may correspond to any UE described herein, and the network FLUS sink 604 may correspond to a base station (e.g., any base station described herein), an entity of a core network, an application server (e.g., application server 172), a remote client, etc. Figure 6 In the example of , the network FLUS sink 604 is the SDP initiator and the UE FLUS source 602 is the SDP responder, but as will be appreciated, these roles may be reversed.

[0117] At 610, the network FLUS sink 604 sends an SDP Origination to the UE FLUS source 602. Because the initiator is the network FLUS sink, the Origination may include at least a downlink loss / delay QoS hint value, instead of or in addition to the end-to-end loss / delay QoS hint value. The downlink loss / delay QoS hint value may be "0" to indicate negligible loss / delay on the backhaul link between the base station (not shown) serving the UE FLUS source 602 and the network FLUS sink 604. The Origination may also include an uplink loss / delay QoS hint value of zero for the backhaul link between the FLUS sink 604 and the serving base station if traffic (e.g., TCP ACK) is expected to be sent in this direction as well.

[0118] At 620, the UE FLUS source 602 sends an answer to the network FLUS sink 604. In the SDP, in order to accept the origination, the answer needs to include the same attributes in the origination. If the answering party (i.e., the UE FLUS source 602) accepts the end-to-end loss / delay in the origination, it can include this value in the answer and also include an uplink loss / delay QoS hint value equal to the end-to-end loss / delay, because the backhaul downlink to the network FLUS sink 604 will not introduce any loss / delay.

[0119] If the initiation indicates that there may be traffic in this direction, the response may also include a downlink loss / delay QoS hint value for the wireless link between the serving base station (not shown) and the UE FLUS sink 604. In this case, the response will indicate that the downlink loss / delay is equal to the end-to-end loss delay because the uplink on the backhaul from the network FLUS sink 604 to the serving base station is zero. If the initiation does not include an uplink loss / delay QoS hint value, the UE FLUS source 602 may include the hint and its preferred value in the response.

[0120] Alternatively, if the initiation includes end-to-end loss / delay QoS hint values ​​and downlink loss / delay QoS hint values, the UE FLUS source 602 may derive the initiated uplink loss / delay QoS hint values ​​and decide whether to accept them. If the UE FLUS source 602 accepts them, it may respond with the initiated end-to-end loss / delay QoS hint values ​​and uplink / downlink parameter values ​​as described earlier. If it does not accept them, it may respond with different end-to-end loss / delay QoS hint values ​​and different uplink / downlink parameter values.

[0121] The network FLUS sink 604 and the UE FLUS source 602 may repeat operations 610 and 620 until they agree on the loss / delay QoS hint value. Alternatively, even if they do not agree, they may perform operations 610 and 620 only once.

[0122] At 630, the network 606 (e.g., PCF / PCRF) selects a Q5I / QCI based at least in part on the loss / delay QoS hint value. If the UE FLUS source 602 and the downlink loss / delay QoS hint value agree on the loss / delay QoS hint value, the network 606 may select the Q5I / QCI that best matches the agreed upon value.

[0123] At 640, the network 606 allocates resources to the connection between the UE FLUS source 602 and the network FLUS sink 604, in particular, the radio link between the UE FLUS source 602 and its serving base station. Once the link is established with the selected Q5I / QCI, the UE FLUS source 602 can start streaming uplink media to the network FLUS sink 604.

[0124] Figure 7 An example method 700 of wireless communication in accordance with aspects of the present disclosure is illustrated. The method 700 may be performed by an SDP responder (eg, a FLUS source / sink).

[0125] At 710, the responder receives from the initiator (eg, FLUS source / sink) Figure 6610 for a multimedia session (e.g., a FLUS session) to be established between an initiator and a responder. In one aspect, the first plurality of QoS parameters include a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both. In one aspect, in the case where the responder is a UE, operation 710 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any one or all of which may be considered as a component for performing the operation. In one aspect, in the case where the responder is a base station, operation 710 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any one or all of which may be considered as a component for performing the operation. In one aspect, where the responder is a network entity, operation 710 may be performed by network interface 390, processing system 394, memory component 396, and / or QoS allocation component 398, any or all of which may be considered means for performing the operation.

[0126] At 720, the responder determines that the first expected maximum end-to-end packet loss is higher than the second expected maximum end-to-end packet loss for the multimedia session, the first expected maximum end-to-end packet delay is higher than the second expected maximum end-to-end packet delay for the multimedia session, or both. In one aspect, where the responder is a UE, operation 720 may be performed by WWAN transceiver 310, processing system 332, memory component 340, and / or uplink streaming service component 342, any or all of which may be considered as a component for performing the operation. In one aspect, where the responder is a base station, operation 720 may be performed by WWAN transceiver 350, processing system 384, memory component 386, and / or uplink streaming service component 388, any or all of which may be considered as a component for performing the operation. In one aspect, where the responder is a network entity, operation 720 may be performed by network interface 390, processing system 394, memory component 396, and / or QoS allocation component 398, any or all of which may be considered means for performing the operation.

[0127] At 730, the responder sends the initiator a Figure 6A second plurality of QoS parameters for the multimedia session at 620 of . In one aspect, the second plurality of QoS parameters include a second loss parameter indicating a second expected maximum end-to-end packet loss, a second delay parameter indicating a second expected maximum end-to-end packet delay, or both. In one aspect, where the responder is a UE, operation 730 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any or all of which may be considered as a component for performing the operation. In one aspect, where the responder is a base station, operation 730 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any or all of which may be considered as a component for performing the operation. In one aspect, where the responder is a network entity, operation 730 may be performed by network interface 390, processing system 394, memory component 396, and / or QoS allocation component 398, any or all of which may be considered means for performing the operation.

[0128] Figure 8 An example method 800 of wireless communication according to aspects of the present disclosure is illustrated. The method 800 may be performed by an initiator (eg, a FLUS source / sink).

[0129] At 810, the initiator sends a response to the responder (eg, FLUS source / sink) as in Figure 6 610 for a multimedia session to be established between an initiator and a responder. In one aspect, the first plurality of QoS parameters include a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia session, a first delay parameter indicating a first expected maximum end-to-end packet delay for the multimedia session, or both. In one aspect, where the initiator is a UE, operation 810 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any one or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a base station, operation 810 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any one or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a network entity, operation 810 may be performed by network interface 390, processing system 394, memory component 396, and / or QoS allocation component 398, any or all of which may be considered means for performing the operation.

[0130] At 820, the initiator receives from the responder Figure 6 A second plurality of QoS parameters for the multimedia session at 620 of . In one aspect, the second plurality of QoS parameters include a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia session, a second delay parameter indicating a second expected maximum end-to-end packet delay for the multimedia session, or both. In one aspect, where the initiator is a UE, operation 820 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a base station, operation 820 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a network entity, operation 820 may be performed by network interface 390, processing system 394, memory component 396, and / or QoS allocation component 398, any or all of which may be considered means for performing the operation.

[0131] At 830, the initiator determines whether the initiator can establish a multimedia session with the responder based on the multimedia session with the second plurality of QoS parameters. In one aspect, where the initiator is a UE, operation 830 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a base station, operation 830 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a network entity, operation 830 may be performed by the network interface 390, the processing system 394, the memory component 396, and / or the QoS allocation component 398, any or all of which may be considered as a component for performing the operation.

[0132] At 840, the initiator establishes a multimedia session with the responder, the multimedia session having a second plurality of QoS parameters. In one aspect, where the initiator is a UE, operation 840 may be performed by the WWAN transceiver 310, the processing system 332, the memory component 340, and / or the uplink streaming service component 342, any one or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a base station, operation 840 may be performed by the WWAN transceiver 350, the processing system 384, the memory component 386, and / or the uplink streaming service component 388, any one or all of which may be considered as a component for performing the operation. In one aspect, where the initiator is a network entity, operation 840 may be performed by the network interface 390, the processing system 394, the memory component 396, and / or the QoS allocation component 398, any one or all of which may be considered as a component for performing the operation.

[0133] Those skilled in the art will recognize that information and signals may be represented using any of a variety of different techniques and technologies. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout this description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0134] Moreover, those skilled in the art will recognize that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with various aspects of the present disclosure can be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above with respect to their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician can implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing departure from the scope of the present invention.

[0135] The various illustrative logical blocks, modules, and circuits described in conjunction with the various aspects disclosed herein may be implemented or performed with a general purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0136] The methods, sequences and / or algorithms described in conjunction with the various aspects disclosed herein may be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a random access memory (RAM), a flash memory, a read-only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from / write information to the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal (e.g., a UE). In an alternative, the processor and the storage medium may reside in a user terminal as discrete components.

[0137] In one or more exemplary aspects, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions can be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, which include any media that facilitates the transfer of a computer program from one place to another. Storage media can be any available media that a computer can access. As an example, and not a limitation, the computer-readable medium may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, disk storage, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code means in the form of instructions or data structures and can be accessed by a computer. And, any connection is also properly referred to as a computer-readable medium. For example, if the software is sent from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

[0138] Although the foregoing disclosure shows illustrative aspects of the present disclosure, it should be noted that various changes and modifications may be made herein without departing from the scope of the present disclosure as defined by the appended claims. The functions, steps, and / or actions of the method claims according to the various aspects of the disclosure described herein do not need to be performed in any particular order. In addition, although elements of the present disclosure may be described or claimed in singular form, plural forms are contemplated unless limitation to the singular is explicitly stated.

Claims

1. A wireless communication method performed by a responder, comprising: receiving a proposal from an initiator, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator and the responder, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; determining that the first expected maximum end-to-end packet delay is higher than a second expected maximum end-to-end packet delay for the multimedia session; as well as sending a response to the initiator, the response comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating the second expected maximum end-to-end packet delay, Wherein (1) the initiator is a user equipment (UE) that initiates the proposal, and the responder is a non-UE network node that initiates the response, or (2) the initiator is a non-UE network node that initiates the proposal, and the responder is the UE that initiates the response.

2. The method of claim 1, wherein: The second plurality of QoS parameters also includes one or more values ​​indicating how the second desired maximum end-to-end packet delay is distributed across a communication link between the responder and the initiator.

3. The method of claim 2, wherein: The second plurality of QoS parameters also includes an uplink value indicating how the second expected maximum end-to-end packet delay is distributed across the responder's uplink communication links.

4. The method of claim 3, wherein: The responder comprises a real-time uplink flow framework FLUS source, and the initiator comprises a FLUS sink, or The responder comprises a FLUS sink, and the initiator comprises a FLUS source.

5. The method of claim 2, wherein: The second plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across the responder's downlink communication links.

6. The method of claim 5, wherein: The responder comprises a FLUS sink, and the initiator comprises a FLUS source, or The responder comprises a FLUS source, and the initiator comprises a FLUS sink.

7. The method of claim 1, wherein: The first plurality of QoS parameters also includes one or more values ​​indicating how the first expected maximum end-to-end packet delay is distributed across a communication link between the initiator and the responder.

8. The method of claim 1, wherein: The first plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across the initiator's downlink communication links.

9. The method of claim 8, wherein: The initiator comprises a FLUS sink, and the responder comprises a FLUS source, or The initiator comprises a FLUS source, and the responder comprises a FLUS sink.

10. The method of claim 1, wherein: The first plurality of QoS parameters also includes an uplink value indicating how the first expected maximum end-to-end packet delay is distributed across the initiator's uplink communication links.

11. The method of claim 10, wherein: The initiator includes a FLUS source, and the responder includes a FLUS sink, or the initiator includes a FLUS sink, and the responder includes a FLUS source.

12. The method of claim 1, wherein: The first plurality of QoS parameters are received in a first Session Description Protocol (SDP) message, and The second plurality of QoS parameters are sent in a second SDP message.

13. The method of claim 1, wherein: The multimedia session includes a FLUS session, a Multimedia Telephony Service MTSI session for an Internet Protocol IP Multimedia Subsystem IMS, an extended reality session, a telepresence session, or a split-presence session.

14. The method of claim 1, further comprising: receiving, from the initiator, an acceptance of the second plurality of QoS parameters for the multimedia session; as well as The multimedia session with the initiator is established based on receiving the acceptance.

15. The method of claim 1, further comprising: receiving, from the initiator, a rejection of the second plurality of QoS parameters for the multimedia session; as well as The multimedia session with the initiator is dropped based on receiving the rejection.

16. A wireless communication method performed by an initiator, comprising: sending a proposal to the answerer, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator and the answerer, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; receiving a response from the responder, the response comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating a second desired maximum end-to-end packet delay for the multimedia session; determining, based on the multimedia session having the second plurality of QoS parameters, whether the initiator can establish the multimedia session with the responder; as well as establishing the multimedia session with the responder, the multimedia session having the second plurality of QoS parameters, Wherein (1) the initiator is a user equipment (UE) that initiates the proposal, and the responder is a non-UE network node that initiates the response, or (2) the initiator is a non-UE network node that initiates the proposal, and the responder is the UE that initiates the response.

17. The method of claim 16, wherein: The second plurality of QoS parameters also includes one or more values ​​indicating how the second desired maximum end-to-end packet delay is distributed across a communication link between the responder and the initiator.

18. The method of claim 17, wherein: The second plurality of QoS parameters also includes an uplink value indicating how the second expected maximum end-to-end packet delay is distributed across the responder's uplink communication links.

19. The method of claim 18, wherein: The responder comprises a real-time uplink flow framework FLUS source, and the initiator comprises a FLUS sink, or The responder comprises a FLUS sink, and the initiator comprises a FLUS source.

20. The method of claim 17, wherein: The second plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across the responder's downlink communication links.

21. The method of claim 20, wherein: The responder comprises a FLUS sink, and the initiator comprises a FLUS source, or The responder comprises a FLUS source, and the initiator comprises a FLUS sink.

22. The method of claim 16, wherein: The first plurality of QoS parameters also includes uplink and downlink values ​​indicating how the first expected maximum end-to-end packet delay is distributed across a communication link between the initiator and the responder.

23. The method of claim 16, wherein: The first plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across the initiator's downlink communication links.

24. The method of claim 23, wherein: The initiator comprises a FLUS sink, and the responder comprises a FLUS source, or The initiator comprises a FLUS source, and the responder comprises a FLUS sink.

25. The method of claim 16, wherein: The first plurality of QoS parameters also includes an uplink value indicating how the first expected maximum end-to-end packet delay is distributed across the initiator's uplink communication links.

26. The method of claim 25, wherein: The initiator comprises a FLUS source, and the responder comprises a FLUS sink, or The initiator comprises a FLUS sink, and the responder comprises a FLUS source.

27. The method of claim 16, wherein: The first plurality of QoS parameters are sent in a first Session Description Protocol (SDP) message, and The second plurality of QoS parameters are received in a second SDP message.

28. The method of claim 16, wherein: The multimedia session includes a FLUS session, a Multimedia Telephony Service MTSI session for an Internet Protocol IP Multimedia Subsystem IMS, an extended reality session, a telepresence session, or a split-presence session.

29. The method of claim 16, further comprising: An acceptance of the second plurality of QoS parameters for the multimedia session is sent to the responder.

30. A responder device, comprising: Memory; Communications equipment; as well as one or more processors communicatively coupled to the memory and the communication device, the one or more processors configured to: receiving a proposal from an initiator device, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator device and the responder device, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; determining that the first expected maximum end-to-end packet delay is higher than a second expected maximum end-to-end packet delay for the multimedia session; as well as causing the communication device to send a reply to the initiator apparatus, the reply comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating the second expected maximum end-to-end packet delay, Wherein (1) the initiator device is a user equipment (UE) that initiates the proposal, and the responder device is a non-UE network node that initiates the response, or (2) the initiator device is a non-UE network node that initiates the proposal, and the responder device is the UE that initiates the response.

31. The responder device according to claim 30, wherein: The second plurality of QoS parameters also includes one or more values ​​indicating how the second desired maximum end-to-end packet delay is distributed across a communication link between the responder device and the initiator device.

32. The responder device according to claim 31, wherein: The second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet delay is distributed across an uplink communication link of the responder device.

33. The responder device according to claim 32, wherein: The responder device comprises a real-time uplink flow framework FLUS source, and the initiator device comprises a FLUS sink, or The responder device comprises a FLUS sink, and the initiator device comprises a FLUS source.

34. The responder device according to claim 31, wherein: The second plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across a downlink communication link of the responder device.

35. The responder device according to claim 34, wherein: The responder device comprises a FLUS sink, and the initiator device comprises a FLUS source, or The responder device comprises a FLUS source, and the initiator device comprises a FLUS sink.

36. The responder device according to claim 30, wherein: The first plurality of QoS parameters also includes one or more values ​​indicating how the first expected maximum end-to-end packet delay is distributed across a communication link between the initiator device and the responder device.

37. The responder device according to claim 30, wherein: The first plurality of QoS parameters also includes a downlink value indicating how the first desired maximum end-to-end packet delay is distributed across a downlink communication link of the initiator device.

38. The responder device according to claim 37, wherein: The initiator device comprises a FLUS sink and the responder device comprises a FLUS source, or The initiator device comprises a FLUS source, and the responder device comprises a FLUS sink.

39. The responder device according to claim 30, wherein: The first plurality of QoS parameters also includes an uplink value indicating how the first expected maximum end-to-end packet delay is distributed across an uplink communication link of the initiator device.

40. The responder device according to claim 39, wherein: The initiator device comprises a FLUS source, and the responder device comprises a FLUS sink, or The initiator device comprises a FLUS sink, and the responder device comprises a FLUS source.

41. The responder device according to claim 30, wherein: The initiator device is the UE, and the responder device is the non-UE network node, and The communication device comprises at least one network interface.

42. The responder device according to claim 30, wherein: The initiator device is the non-UE network node, and the responder device is the UE, and The communication device comprises at least one transceiver.

43. The responder device according to claim 30, wherein: The first plurality of QoS parameters are received in a first Session Description Protocol (SDP) message, and The second plurality of QoS parameters are sent in a second SDP message.

44. The responder device according to claim 30, wherein: The multimedia session includes a FLUS session, a Multimedia Telephony Service MTSI session for an Internet Protocol IP Multimedia Subsystem IMS, an extended reality session, a telepresence session, or a split-presence session.

45. The responder apparatus of claim 30, wherein the one or more processors are further configured to: receiving, from the initiator device, an acceptance of the second plurality of QoS parameters for the multimedia session; and The multimedia session with the initiator device is established based on receiving the acceptance.

46. ​​The responder apparatus of claim 30, wherein the one or more processors are further configured to: receiving, from the initiator device, a rejection of the second plurality of QoS parameters for the multimedia session; and The multimedia session with the originator device is dropped based on receiving the rejection.

47. An initiator device, comprising: Memory; Communications equipment; as well as one or more processors communicatively coupled to the memory and the communication device, the one or more processors configured to: causing the communication device to send a proposal to a responder apparatus, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator apparatus and the responder apparatus, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; receiving a response from the responder device, the response comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating a second desired maximum end-to-end packet delay for the multimedia session; determining, based on the multimedia session having the second plurality of QoS parameters, whether the initiator device can establish the multimedia session with the responder device; as well as establishing the multimedia session with the responder device, the multimedia session having the second plurality of QoS parameters, Wherein (1) the initiator device is a user equipment (UE) that initiates the proposal, and the responder device is a non-UE network node that initiates the response, or (2) the initiator device is a non-UE network node that initiates the proposal, and the responder device is the UE that initiates the response.

48. The initiator device of claim 47, wherein: The second plurality of QoS parameters also includes one or more values ​​indicating how the second desired maximum end-to-end packet delay is distributed across a communication link between the responder device and the initiator device.

49. The initiator device of claim 48, wherein: The second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet delay is distributed across an uplink communication link of the responder device.

50. The initiator device of claim 49, wherein: The responder device comprises a real-time uplink flow framework FLUS source, and the initiator device comprises a FLUS sink, or The responder device comprises a FLUS sink, and the initiator device comprises a FLUS source.

51. The initiator device of claim 48, wherein: The second plurality of QoS parameters also includes a downlink value indicating how the first expected maximum end-to-end packet delay is distributed across a downlink communication link of the responder device.

52. The initiator device of claim 51, wherein: The responder device comprises a FLUS sink, and the initiator device comprises a FLUS source, or The responder device comprises a FLUS source, and the initiator device comprises a FLUS sink.

53. The initiator device of claim 47, wherein: The first plurality of QoS parameters also includes uplink and downlink values ​​indicating how the first expected maximum end-to-end packet delay is distributed across a communication link between the initiator device and the responder device.

54. The initiator device of claim 47, wherein: The first plurality of QoS parameters also includes a downlink value indicating how the first desired maximum end-to-end packet delay is distributed across a downlink communication link of the initiator device.

55. The initiator device of claim 54, wherein: The initiator device comprises a FLUS sink and the responder device comprises a FLUS source, or The initiator device comprises a FLUS source, and the responder device comprises a FLUS sink.

56. The initiator device of claim 47, wherein: The first plurality of QoS parameters also includes an uplink value indicating how the first expected maximum end-to-end packet delay is distributed across an uplink communication link of the initiator device.

57. The initiator device of claim 56, wherein: The initiator device comprises a FLUS source, and the responder device comprises a FLUS sink, or The initiator device comprises a FLUS sink, and the responder device comprises a FLUS source.

58. The initiator device of claim 47, wherein: The initiator device is the UE, and the responder device is the non-UE network node, and The communication device comprises at least one transceiver.

59. The initiator device of claim 47, wherein: The initiator device is the non-UE network node, and the responder device is the UE, and The communication device comprises at least one network interface.

60. The initiator device of claim 47, wherein: The first plurality of QoS parameters are sent in a first Session Description Protocol (SDP) message, and The second plurality of QoS parameters are received in a second SDP message.

61. The initiator device of claim 47, wherein: The multimedia session includes a FLUS session, a Multimedia Telephony Service MTSI session for an Internet Protocol IP Multimedia Subsystem IMS, an extended reality session, a telepresence session, or a split-presence session.

62. The initiator device of claim 47, wherein the one or more processors are further configured to: The communication device is caused to send an acceptance of the second plurality of QoS parameters for the multimedia session to the responder apparatus.

63. A responder device comprising: means for receiving, from an initiator device, a proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator device and the responder device, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; means for determining that said first desired maximum end-to-end packet delay is higher than a second desired maximum end-to-end packet delay for said multimedia session; as well as means for sending a reply comprising a second plurality of QoS parameters for the multimedia session to the initiator device, the second plurality of QoS parameters comprising a second delay parameter indicating the second desired maximum end-to-end packet delay, Wherein (1) the initiator device is a user equipment (UE) that initiates the proposal, and the responder device is a non-UE network node that initiates the response, or (2) the initiator device is a non-UE network node that initiates the proposal, and the responder device is the UE that initiates the response.

64. An initiator device, comprising: means for sending to a responder device a proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator device and the responder device, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; means for receiving, from the responder device, a response including a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters including a second delay parameter indicating a second desired maximum end-to-end packet delay for the multimedia session; means for determining whether the initiator device can establish the multimedia session with the responder device based on the multimedia session having the second plurality of QoS parameters; as well as means for establishing the multimedia session with the responder device, the multimedia session having the second plurality of QoS parameters, Wherein (1) the initiator device is a user equipment (UE) that initiates the proposal, and the responder device is a non-UE network node that initiates the response, or (2) the initiator device is a non-UE network node that initiates the proposal, and the responder device is the UE that initiates the response.

65. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a responder, cause the responder to: receiving a proposal from an initiator, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator and the responder, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; determining that the first expected maximum end-to-end packet delay is higher than a second expected maximum end-to-end packet delay for the multimedia session; as well as sending a response to the initiator, the response comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating the second expected maximum end-to-end packet delay, Wherein (1) the initiator is a user equipment (UE) that initiates the proposal, and the responder is a non-UE network node that initiates the response, or (2) the initiator is a non-UE network node that initiates the proposal, and the responder is the UE that initiates the response.

66. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by an initiator, cause the initiator to: sending a proposal to the answerer, the proposal comprising a first plurality of quality of service (QoS) parameters for a multimedia session to be established between the initiator and the answerer, the first plurality of QoS parameters comprising a first delay parameter indicating a first desired maximum end-to-end packet delay for the multimedia session; receiving a response from the responder, the response comprising a second plurality of QoS parameters for the multimedia session, the second plurality of QoS parameters comprising a second delay parameter indicating a second desired maximum end-to-end packet delay for the multimedia session; determining, based on the multimedia session having the second plurality of QoS parameters, whether the initiator can establish the multimedia session with the responder; as well as establishing the multimedia session with the responder, the multimedia session having the second plurality of QoS parameters, Wherein (1) the initiator is a user equipment (UE) that initiates the proposal, and the responder is a non-UE network node that initiates the response, or (2) the initiator is a non-UE network node that initiates the proposal, and the responder is the UE that initiates the response.

Images