Considerations on quality of service (QOS) hints for an uplink streaming service

Abstract

In one scenario, the responder receives from the proposer a first plurality of Quality of Service (QoS) parameters for a multimedia communication period, the first plurality of QoS parameters including a first loss and / or latency parameter indicating a first expected maximum end-to-end packet loss and / or latency for a multimedia communication period, determining 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 latency is higher than the second expected maximum end-to-end packet latency, or both, and sends to the proposer a second plurality of QoS parameters for a multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second latency parameter indicating a second expected maximum end-to-end packet latency, or both.

Description

Technical Field

[0001] 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", which is assigned to the assignee of this application and whose entire contents are expressly incorporated herein by reference.

[0002] This disclosure relates to a large-scale system of wireless communication. Prior Technology

[0003] Wireless communication systems have evolved through several generations, including first-generation analog wireless telephony (1G), second-generation (2G) digital wireless telephony (including the intermediate 2.5G network), third-generation (3G) high-speed data, wireless services with internet capabilities, and fourth-generation (4G) services (e.g., LTE or WiMax). Currently, many different types of wireless communication systems are in use, including cellular and Personal Communication Services (PCS) systems. Known examples of cellular systems include Advanced Cellular Analog Telephone Systems (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), and more.

[0004] The fifth-generation (5G) wireless standard, known as New Radio (NR), delivers 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 gigabits per second to dozens of employees in an office building. It should support hundreds of thousands of simultaneous connections to support large-scale wireless sensor deployments. Therefore, the spectral efficiency of 5G mobile communications should be significantly enhanced compared to the current 4G standard. Furthermore, signal transmission efficiency should be improved, and latency should be significantly reduced compared to the current standard. Summary of the Invention

[0005] The following provides a brief overview relating to one or more states disclosed herein. Therefore, this overview should not be considered an exhaustive summary relating to all anticipated states, nor should it be considered to identify key or important elements relating to all anticipated states, or to describe categories associated with any particular state. Thus, the sole purpose of this overview is to present, in a simplified form, certain concepts relating to one or more states related to the mechanisms disclosed herein, before the specific implementations provided below.

[0006] In one scenario, a method of wireless communication performed by a responder includes: receiving from a proposer a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposer and the 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, 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 communication period, the first expected maximum end-to-end packet latency is higher than a second expected maximum end-to-end packet latency for the multimedia communication period, or both; and sending to the proposer a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second latency parameter indicating a second expected maximum end-to-end packet latency, or both.

[0007] In one instance, a method of wireless communication performed by a proposer includes: sending to a responder a first plurality of QoS parameters for a multimedia communication period to be established between the proposer and the 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; receiving from the responder a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia communication period, a second latency parameter indicating a second expected maximum end-to-end packet latency for the multimedia communication period, or both; determining, based on the multimedia communication period having the second plurality of QoS parameters, whether the proposer is capable of establishing the multimedia communication period with the responder; and establishing the multimedia communication period with the responder, the multimedia communication period having the second plurality of QoS parameters.

[0008] In one configuration, the responding device includes a memory; a communication device; and at least one processor communicatively coupled to the memory and the communication device, the at least one processor being configured to: receive from the proposing device a first plurality of QoS parameters for a multimedia communication period to be established between the proposing and responding devices, the first plurality of QoS parameters including a first loss parameter indicating a first expected maximum end-to-end packet loss for the multimedia communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, 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 communication period, the first expected maximum end-to-end packet latency is higher than a second expected maximum end-to-end packet latency for the multimedia communication period, or both; and cause the communication device to send to the proposing device a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second latency parameter indicating a second expected maximum end-to-end packet latency, or both.

[0009] In one configuration, the proposing device includes a memory; a communication device; and at least one processor communicatively coupled to the memory and the communication device, the at least one processor being configured to: cause the communication device to send to the responding device a first plurality of QoS parameters for a multimedia communication period to be established between the proposing device and the responding 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; from the responding device... The proposing device receives a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia communication period, a second latency parameter indicating a second expected maximum end-to-end packet latency for the multimedia communication period, or both; based on the multimedia communication period having the second plurality of QoS parameters, determines whether the proposing device can establish the multimedia communication period with the responding device; and establishes the multimedia communication period with the responding device, the multimedia communication period having the second plurality of QoS parameters.

[0010] In one embodiment, the responding device includes: means for receiving from a proposing device a first plurality of QoS parameters for a multimedia communication period to be established between the proposing device and the responding 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; means 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 communication period, the first expected maximum end-to-end packet latency is higher than a second expected maximum end-to-end packet latency for the multimedia communication period, or both; and means for sending to the proposing device a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss, a second latency parameter indicating a second expected maximum end-to-end packet latency, or both.

[0011] In one embodiment, the proposing device includes: means for sending to the responding device a first plurality of QoS parameters for a multimedia communication period to be established between the proposing device and the responding 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; means for receiving from the responding device a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia communication period, a second latency parameter indicating a second expected maximum end-to-end packet latency for the multimedia communication period, or both; means for determining whether the proposing device is capable of establishing the multimedia communication period with the responding device based on the multimedia communication period having the second plurality of QoS parameters; and means for establishing the multimedia communication period with the responding device, the multimedia communication period having the second plurality of QoS parameters.

[0012] In one instance, a non-transitory computer-readable medium storing computer-executable instructions includes: at least one instruction for instructing a responder to receive from a proposer at least one of a first plurality of QoS parameters for a multimedia communication period to be established between the proposer and the 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; at least one instruction for 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 communication period, the first expected maximum end-to-end packet latency is higher than a second expected maximum end-to-end packet latency for the multimedia communication period, or both; and at least one instruction for instructing the responder to send to the proposer at least one of a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: a second loss parameter indicating a second expected maximum end-to-end packet loss, a second latency parameter indicating a second expected maximum end-to-end packet latency, or both.

[0013] In one instance, a non-transitory computer-readable medium storing computer-executable instructions includes: at least one instruction for instructing a proposer to send to a responder at least one instruction for a first plurality of QoS parameters for a multimedia communication period to be established between the proposer and the 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 communication period, a first latency parameter indicating a first expected maximum end-to-end packet latency for the multimedia communication period, or both; and at least one instruction for instructing the proposer to receive from the responder at least one instruction for a second plurality of QoS parameters for the multimedia communication period. An instruction, the second plurality of QoS parameters including: a second loss parameter indicating a second expected maximum end-to-end packet loss for the multimedia communication period, a second latency parameter indicating a second expected maximum end-to-end packet latency for the multimedia communication period, or both; at least one instruction for instructing the proposer to determine whether the proposer can establish the multimedia communication period with the responder based on the multimedia communication period having the second plurality of QoS parameters; and at least one instruction for instructing the proposer to establish the multimedia communication period with the responder, the multimedia communication period having the second plurality of QoS parameters.

[0014] Other objectives and advantages associated with the various embodiments disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed descriptions. Simple Explanation of the Diagram

[0015] The accompanying drawings are provided to illustrate various aspects of this disclosure, and are provided for illustrative purposes only and not to limit the scope of the disclosure.

[0016] Figure 1 illustrates an example wireless communication system according to various aspects of this disclosure.

[0017] Figures 2A and 2B illustrate examples of wireless network structures according to various aspects of this disclosure.

[0018] Figures 3A to 3C are simplified block diagrams of several sampling states of components that can be used in user equipment (UE), base stations, and network entities.

[0019] Figure 4 illustrates an example end-to-end communication flow between two terminals participating in a multimedia-based communication session, according to various aspects of this disclosure.

[0020] Figure 5 illustrates an example uplink streaming service architecture according to various states of this disclosure.

[0021] Figures 6 to 8 illustrate example methods of wireless communication according to various states of this disclosure. Implementation

[0022] Various embodiments of this disclosure are provided in the following description and accompanying drawings for illustrative purposes. Alternative embodiments may be devised without departing from the scope of protection of this disclosure. Furthermore, well-known elements of this disclosure will not be described in detail or will be omitted to avoid obscuring relevant details of this disclosure.

[0023] The terms "exemplary" and / or "example" as used herein mean "serving as an example, instance, or illustration." Any variant described herein as "exemplary" and / or "example" is not necessarily to be construed as being better or more advantageous than other variants. Similarly, the term "various variants of this disclosure" does not require that all variants of this disclosure include the features, advantages, or modes of operation discussed.

[0024] Those skilled in the art will understand that the information and signals described below can be represented using any of a variety of different techniques and methods. For example, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc., the data, instructions, commands, information, signals, bits, symbols, and chips mentioned below can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0025] Furthermore, many of the states are described in the order of actions to be performed by, for example, elements of a computing device. It will be appreciated that the various actions described herein can be performed by specific circuitry (e.g., an application-specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or a combination of both. Moreover, the order of actions described herein can be considered entirely embodied in any form of non-transitory computer-readable storage medium having a corresponding set of computer instructions stored therein, which, when executed, will cause or instruct the associated processor of the device to perform the functions described herein. Therefore, the various states of this disclosure can be embodied in a variety of different forms, all of which are contemplated within the scope of the claimed subject matter. Furthermore, for each of the states described herein, any such state of the corresponding form can be described herein as, for example, "logic" "configured" to perform the described actions.

[0026] As used herein, unless otherwise indicated, the terms “User Equipment” (UE) and “base station” are not intended to be specific or otherwise limited to any particular Radio Access Technology (RAT). Generally, a UE can be any wireless communication device used by a user to communicate via a wireless communication network (e.g., mobile phone, router, tablet, laptop, tracking device, wearable device (e.g., smartwatch, glasses, augmented reality (AR) / virtual reality (VR) headset, etc.), vehicle (e.g., car, motorcycle, bicycle, etc.), Internet of Things (IoT) device, etc.). A UE can be mobile or can (e.g., at certain times) be stationary and can communicate with a Radio Access Network (RAN). As used herein, the term “UE” can be interchangeably referred to as “Access Terminal” or “AT”, “Client Equipment”, “Wireless Equipment”, “User Equipment”, “User Terminal”, “Subscriber Station”, “User Terminal” or UT, “Mobile Equipment”, “Mobile Terminal”, “Mobile Station”, or variations thereof. Typically, a UE can communicate with the core network via the RAN, and the UE can connect to external networks such as the Internet and other UEs via the core network. Of course, other mechanisms are also possible for the UE to connect to the core network and / or the Internet, such as via wired access networks, wireless local area network (WLAN) networks (e.g., based on IEEE 802.11).

[0027] A base station may operate based on one of several RATs (Radio Access Points) communicating with the UE, depending on the network in which it is deployed, and may be alternatively referred to as an Access Point (AP), network node, node B, evolved node B (eNB), next-generation eNB (ng-eNB), new radio (NR) node B (also known as gNB or g node B), etc. A base station may primarily be used to support radio access by the UE, including supporting data, voice, and / or signaling connections for the supported UE. In some systems, a base station may provide full edge node signaling capabilities, while in others it may provide additional control and / or network management functions. The communication link through which the UE can send signals to the base station is called an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link through which the base station can send signals to the UE is called a downlink (DL) or forward link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term Traffic Channel (TCH) can refer to the uplink / reverse or downlink / forward traffic channel.

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

[0029] An "RF signal" comprises 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 multipath propagation characteristics of RF signals, a receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between the transmitter and receiver can 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, as is clear from the context, the term "signal" refers to a wireless signal or an RF signal.

[0030] Figure 1 illustrates an exemplary wireless communication system 100, depending on the configuration. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 and various UEs 104. 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 configuration, macrocell base stations may include eNBs and / or ng-eNBs in the case of the wireless communication system 100 corresponding to an LTE network, or gNBs in the case of the wireless communication system 100 corresponding to an NR network, or a combination of both, and small cell base stations may include femtocells, picocells, microcells, etc.

[0031] Base station 102 can collectively form a RAN and engage with core network 170 (e.g., Evolved Packet Core (EPC) or 5G Core (5GC)) via backhaul link 122, and engage with one or more application servers 172 (which may be part of core network 170 or external to core network 170) via core network 170. Among other functions, base station 102 can perform functions related to one or more of the following: transmission of 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 NAS messages, NAS node selection, synchronization, RAN sharing, Multimedia Broadcast Multicast Service (MBMS), user and device tracking, RAN Information Management (RIM), paging, location, and delivery of warning messages. Base stations 102 can communicate directly or indirectly with each other via backhaul link 134 (e.g., via EPC / 5GC), which can be wired or wireless.

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

[0033] Although the geographic coverage areas 110 of adjacent macrocell base stations 102 may partially overlap (e.g., in delivery areas), some geographic coverage areas 110 may be significantly overlapped by larger geographic coverage areas 110. For example, a small cell base station 102' may have geographic coverage areas 110' that significantly overlap with the geographic coverage areas 110 of one or more macrocell base stations 102. A network that includes both small cell and macrocell base stations can be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB) that can provide service to a restricted group called a Closed User Group (CSG).

[0034] The communication link 120 between base station 102 and UE 104 may include uplink (also known as reverse link) transmission from UE 104 to base station 102 and / or downlink (also known as forward link) transmission from base station 102 to UE 104. The communication link 120 may use MIMO antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be via one or more carrier frequencies. Carrier allocation may be asymmetric relative to the downlink and uplink (e.g., more or fewer carriers may be allocated to the downlink compared to the uplink).

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

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

[0037] The wireless communication system 100 may also include an mmW base station 180 that can operate in millimeter-wave (mmW) frequencies and / or near-mmW frequencies and communicate with the UE 182. Extremely high frequency (EHF) is a portion of the RF spectrum in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and wavelengths between 1 mm and 10 mm. Radio waves in this band can be referred to as millimeter waves. Near-mmW can extend down to a frequency of 3 GHz with a wavelength of 100 mm. Ultra-high frequency (SHF) bands extend between 3 GHz and 30 GHz and are also referred to as centimeter waves. Communication using mmW / near-mmW RF bands has high path loss and relatively short range. The mmW base station 180 and the UE 182 can utilize beamforming (transmit and / or receive) on the mmW communication link 184 to compensate for the extremely high path loss and short range. Furthermore, it will be understood that, in alternative configurations, one or more base stations 102 may also use mmW or near-mmW and beamforming for transmission. Therefore, it will be understood that the foregoing descriptions are merely examples and should not be construed as limiting the various states revealed herein.

[0038] Transmit beamforming is a technique used to focus 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 (omnidirectional). Using transmit beamforming, the network node determines the location of a given target device (e.g., a UE) relative to the transmitting network node and projects a stronger downlink RF signal in that specific direction, thereby providing the receiving device with a faster (in terms of data rate) and stronger RF signal. To change the directionality of the RF signal when transmitting, the network node controls the phase and relative amplitude of the RF signal at each of one or more transmitters broadcasting the RF signal. For example, without physically moving the antennas, the network node can use an array of antennas (called a "phased array" or "antenna array") that creates an RF beam that can be "steered" to be pointed in different directions. Specifically, the RF current from the transmitter is fed to the individual antennas using the correct phase relationship so that the radio waves from the individual antennas are combined to increase radiation in the desired direction, while canceling it to suppress radiation in the undesired direction.

[0039] Transmit beams can be quasi-side-in, meaning they appear to have the same parameters to the receiver (e.g., UE), regardless of whether the transmit antennas of the network nodes are physically side-by-side. In NR, there are four types of quasi-side-in (QCL) relationships. Specifically, a given type of QCL relationship means that certain parameters of the second reference RF signal for the second beam can be derived from information about the source reference RF signal for 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 transmitted 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 transmitted 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 transmitted on the same channel. If the source reference RF signal is of type QCL D, the receiver can use the source reference RF signal to estimate the spatial reception parameters of the second reference RF signal transmitted on the same channel.

[0040] In receive beamforming, a 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 specific direction to amplify the RF signal received from that direction (e.g., to increase its gain level). Therefore, when a receiver is said to be beamforming in a certain direction, this means that the beam gain in that direction is high relative to the beam gain along other directions, or that the beam gain in that direction is the highest compared to the beam gain 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.

[0041] The receive beam can be spatially correlated. The spatial correlation refers to the parameters of the transmit beam for the second reference signal, which can be derived from information about the receive beam for the first reference signal. For example, the UE can use a specific receive beam to receive one or more reference downlink reference signals (e.g., Position 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 the base station. Subsequently, the UE can form a transmit beam based on the parameters of the receive beam to send one or more uplink reference signals (e.g., Uplink Position Reference Signal (UL-PRS), Sounding Reference Signal (SRS), Demodulation Reference Signal (DMRS), PTRS, etc.) to the base station.

[0042] It should be noted that a "downlink" beam can be either a transmit or receive beam, depending on the entity forming it. For example, if a base station is forming a downlink beam to transmit a reference signal to the UE, then the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, then it is a receive beam for receiving downlink reference signals. Similarly, an "uplink" beam can be either a transmit or receive beam, depending on the entity forming it. For example, if a base station is forming an uplink beam, then it is an uplink receive beam, and if the UE is forming an uplink beam, then it is an uplink transmit beam.

[0043] In 5G, the spectrum in which wireless nodes (e.g., base stations 102 / 180, UE 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 multi-carrier systems (such as 5G), one carrier frequency is called the "primary carrier," "anchor carrier," "primary serving cell," or "PCell," and the remaining carrier frequencies are called "secondary carriers," "secondary serving cells," or "SCell." In carrier aggregation, the anchor carrier is the carrier operating on the primary frequency (e.g., FR1) used by UE 104 / 182, and the cell in which UE 104 / 182 performs the initial Radio Resource Control (RRC) connection establishment procedure or initiates the RRC connection re-establishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier on a licensed frequency (however, not always). The secondary carrier is a carrier operating on a second frequency (e.g., FR2), which may be configured once an RRC connection is established between 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 on an unlicensed frequency. The secondary carrier may contain only the necessary signaling information and signals; for example, since both the primary uplink and primary downlink carriers are typically UE-specific, UE-specific signaling information and signals may not be present on the secondary carrier. This means that different UEs 104 / 182 within the cell can have different downlink primary carriers. The same applies to uplink primary carriers. The network can change the primary carrier of any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Because a "service cell" (whether PCell or SCell) corresponds to the carrier frequency / component carrier on which some base stations are communicating, the terms "cell," "service cell," "component carrier," "carrier frequency," etc., can be used interchangeably.

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

[0045] The wireless communication system 100 may also include a UE 164, which can communicate with the macrocell base station 102 via communication link 120 and / or with the mmW base station 180 via mmW communication link 184. For example, the macrocell base station 102 may support PCells 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.

[0046] 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 "sidelinks"). In the example of Figure 1, UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of the base stations 102 (e.g., via which UE 190 can indirectly obtain cellular connectivity), and a D2D P2P link 194 with a WLAN STA 152 connected to a WLAN AP 150 (via which UE 190 can indirectly obtain WLAN-based internet connectivity). In one example, D2D P2P links 192 and 194 may be supported using any known D2D RAT (such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth®, etc.).

[0047] Figure 2A illustrates an example wireless network architecture 200, depending on the configuration. For example, the 5GC 210 (also known as the Next Generation Core (NGC)) can functionally be viewed 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 the data network, Internet Protocol (IP) routing, etc.), which cooperate to form the core network. A user plane interface (NG-U) 213 and a control plane interface (NG-C) 215 connect the gNB 222 to the 5GC 210, and specifically to the control plane function 214 and the user plane function 212. In another configuration, the ng-eNB 224 can also connect 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. Furthermore, the ng-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 the ng-eNB 224 and the gNB 222. The gNB 222 or the ng-eNB 224 can communicate with the UE 204 (e.g., any of the UEs illustrated in Figure 1). Another alternative configuration may include a location server 230, which can communicate with the 5GC 210 to provide location assistance for the UE 204. The location 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 across multiple physical servers, etc.), or alternatively, each may correspond to a single server. Location server 230 can be configured to support one or more location services for UE 204, which can be connected to location server 230 via core network, 5GC 210 and / or via Internet (not shown). Furthermore, location server 230 can be integrated into a component of the core network, or alternatively, can be located outside the core network.

[0048] Depending on the configuration, Figure 2B illustrates another example wireless network architecture 250. For example, 5GC 260 can be functionally viewed as a control plane function provided by Access and Mobility Management Function (AMF) 264 and a user plane function provided by User Plane Function (UPF) 262, which cooperate to form the core network (i.e., 5GC 260). User plane interface 263 and control plane interface 265 connect ng-eNB 224 to 5GC 260, and specifically to UPF 262 and AMF 264, respectively. In another configuration, gNB 222 can also connect to 5GC 260 via control plane interface 265 to AMF 264 and user plane interface 263 to UPF 262. Furthermore, with or without a direct gNB connection to 5GC 260, ng-eNB 224 can communicate directly with gNB 222 via backhaul connection 223. In some configurations, the new RAN 220 may have only one or more gNB 222s, while other configurations include one or more of both ng-eNB 224 and gNB 222. The gNB 222 or ng-eNB 224 can communicate with UE 204 (e.g., any of the UEs illustrated in Figure 1). The base station of the new RAN 220 communicates with AMF 264 via the N2 interface and with UPF 262 via the N3 interface.

[0049] The AMF 264's functions include registration management, connection management, reachability management, mobility management, lawful interception, transmission of Period Management (SM) messages between UE 204 and Period 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 Anchoring Function (SEAF). The AMF 264 also interacts with the Authentication Server Function (AUSF) (not shown) and UE 204, and receives the intermediate key established as a result of the UE 204 authentication process. In the case of authentication based on the UMTS (Universal Mobile Telecommunications System) User Identity Module (USIM), the AMF 264 retrieves security materials from the AAUSF. The AMF 264's functions also include Security Context Management (SCM). The SCM receives a key from the SEAF, which is used to export network-specific keys for access. The AMF 264 also includes functions for location service management for regulatory 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 the new RAN 220 and LMF 270, allocation of Evolved Packet System (EPS) bearer identifiers for interoperability with EPS, and notification of UE 204 mobility events. Furthermore, the AMF 264 also supports functions for non-3GPP (3rd Generation Partnership Project) access networks.

[0050] The functions of UPF 262 include: acting as an anchor point for intra / inter-RAT mobility (where applicable), acting as an external Protocol Data Unit (PDU) communication endpoint 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 control), lawful eavesdropping (user plane collection), traffic usage reporting, quality of service (QoS) processing for the user plane (e.g., uplink / downlink rate enforcement, reflected QoS marking in the downlink), uplink traffic verification (Service Data Stream (SDF) to QoS stream mapping), transport layer packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and sending and forwarding one or more "end markers" to the source RAN node. UPF 262 can also support the transmission of location service messages between UE 204 and a location server (such as Secure User Plane Location (SUPL) Location Platform (SLP) 272) on the user plane.

[0051] The functions of SMF 266 include communication period management, UE IP address allocation and management, selection and control of user plane functions, configuration of traffic control at UPF 262 to route traffic to appropriate destinations, control of policy enforcement and a portion of QoS, and downlink data notification. The interface on which SMF 266 communicates with AMF 264 is called the N11 interface.

[0052] Another alternative configuration may include an LMF 270, which can communicate with the 5GC 260 to provide location assistance for UE 204. The LMF 270 can be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each can correspond to a single server. The LMF 270 can be configured to support one or more location services for UE 204, which can connect to the LMF 270 via the core network, the 5GC 260, and / or via the Internet (not shown). SLP 272 can support similar functions to LMF 270. However, while LMF 270 can communicate with AMF 264, new RAN 220 and UE 204 above the control plane (e.g., using interfaces and protocols intended to transmit signals to deliver messages instead of voice or data), SLP 272 can communicate with UE 204 and external clients (not shown in Figure 2B) above the user plane (e.g., using protocols intended to carry voice and / or data, such as Transmission Control Protocol (TCP) and / or IP).

[0053] Figures 3A, 3B, and 3C illustrate several example components (represented by corresponding blocks) that can 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, location server 230, LMF 270, and SLP 272) to support file transfer operations as taught herein. It will be understood that these components may be implemented in different embodiments in different types of devices (e.g., in an ASIC, in a system-on-a-chip (SoC), etc.). The illustrated components can also be incorporated into other devices in a communication system. For example, other devices in the system may include components similar to those described as providing similar functionality. Additionally, a given device may include one or more of these 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.

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

[0055] In at least some cases, UE 302 and base station 304 also include wireless local area network (WLAN) transceivers 320 and 360, respectively. WLAN transceivers 320 and 360 can be connected to one or more antennas 326 and 366, respectively, and provide components (e.g., components for transmitting, components for receiving, components for measurement, components for tuning, components for avoiding transmission, etc.) for communicating with other network nodes such as other UEs, access points, base stations, etc., via at least one designated RAT through a wireless communication medium of interest. WLAN transceivers 320 and 360 can be configured differently to transmit and encode signals 328 and 368 (e.g., messages, indications, information, etc.) according to a designated RAT, and conversely, to receive and decode signals 328 and 368 (e.g., messages, indications, information, boot signals, etc.), respectively. Specifically, WLAN transceivers 320 and 360 include one or more transmitters 324 and 364 for transmitting and encoding signals 328 and 368 respectively, and one or more receivers 322 and 362 for receiving and decoding signals 328 and 368 respectively.

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

[0057] In at least some cases, UE 302 and base station 304 also include Satellite Positioning System (SPS) receivers 330 and 370. SPS receivers 330 and 370 may be connected to one or more antennas 336 and 376, respectively, and may provide components 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 may each include any suitable hardware and / or software for receiving and processing SPS signals 338 and 378. SPS receivers 330 and 370 may, as appropriate, request information and operation from other systems, and perform calculations necessary to determine the location of UE 302 and base station 304 using measurements obtained via any suitable SPS algorithm.

[0058] Base station 304 and network entity 306 each include at least one network interface 380 and 390, providing components for communicating with other network entities (e.g., components for transmitting, components for receiving, etc.). For example, 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 embodiments, network interfaces 380 and 390 can be implemented as transceivers configured to support wired or wireless signal-based communication. For example, this communication may involve sending and receiving messages, parameters, and / or other types of information.

[0059] 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 processor circuitry implementing processing system 332 for providing functions related to, for example, location operations, and for providing other processing functions. Base station 304 includes processing system 384 for providing functions related to, for example, location operations disclosed herein, and for providing other processing functions. Network entity 306 includes processing system 394 for providing functions related to, for example, location operations disclosed herein, and for providing other processing functions. Processing systems 332, 384, and 394 may therefore provide components for processing, such as components for determining, components for calculating, components for receiving, components for transmitting, components for indicating, etc. In one embodiment, 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 circuitry.

[0060] UE 302, base station 304, and network entity 306 each include memory circuitry implementing storage components 340, 386, and 396 (e.g., each including a memory device) for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Storage components 340, 386, and 396 can therefore provide components for storage, retrieval, maintenance, 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 a QoS allocation component 398. Components 342, 388, and 398 may be hardware circuitry that is 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 configurations, components 342, 388, and 398 may be external to processing systems 332, 384, and 394 (e.g., part of a modem processing system, integrated with another processing system, etc.). Alternatively, components 342, 388, and 398 may be memory modules (as shown in Figures 3A to 3C) stored in storage components 340, 386, and 396, respectively, which, when executed by processing systems 332, 384, and 394 (or a modem processing system, another processing system, etc.), enable UE 302, base station 304, and network entity 306 to perform the functions described herein.

[0061] UE 302 may include one or more sensors 344 coupled to processing system 332 to provide components for sensing or detecting motion and / or orientation information independent of motion data derived from signals received by WWAN transceiver 310, WLAN transceiver 320, and / or SPS receiver 330. For example, sensor 344 may include accelerometers (e.g., microelectromechanical systems (MEMS) devices), gyroscopes, geomagnetic sensors (e.g., compasses), altimeters (e.g., barometric altimeters), and / or any other type of motion detection sensor. Furthermore, sensor 344 may include a plurality of different types of devices and combinations of their outputs to provide motion information. For example, sensor 344 may use a combination of multi-axis accelerometers and orientation sensors to provide the ability to calculate position in 2D and / or 3D coordinate systems.

[0062] Additionally, UE 302 includes a user interface 346 that provides components for providing instructions to the user (e.g., auditory and / or visual instructions) and / or for receiving user input (e.g., when the user actuates sensing devices such as a keypad, touchscreen, microphone, etc.). Although not illustrated, base station 304 and network entity 306 may also include user interfaces.

[0063] Referring more specifically to processing system 384, in the downlink, IP packets from network entity 306 may be provided to processing system 384. Processing system 384 may implement functions targeting the RRC layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The processing system 384 can provide RRC layer functions associated with broadcasting system information (e.g., main blocks (MIB), system blocks (SIB)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), movement between RATs, and measurement configuration for UE measurement reports; 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 via automatic repeat request (ARQ), concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority processing, and logical channel priority allocation.

[0064] Transmitter 354 and receiver 352 implement Layer 1 (L1) functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection of the transmission channel, forward error correction (FEC) encoding / decoding of the transmission channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. Transmitter 354 processes the mapping to the signal cluster 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 encoded and modulated symbols can then be segmented into parallel streams. Each stream can then be mapped to an orthogonal frequency division multiplexing (OFDM) subcarrier, multiplexed with a reference signal (e.g., a pilot signal) in the time and / or frequency domains, and subsequently combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a stream of time-domain OFDM symbols. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. Channel estimates from the channel estimator can be used to determine the coding and modulation schemes and for spatial processing. The channel estimates can be derived based on reference signals transmitted by UE 302 and / or channel condition feedback. Each spatial stream can then be provided to one or more different antennas 356. The transmitter 354 can use its respective spatial stream to modulate an RF carrier for transmission.

[0065] At UE 302, receiver 312 receives signals via its respective antenna 316. Receiver 312 recovers the information modulated on the RF carrier and provides this information to processing system 332. Transmitter 314 and receiver 312 implement Layer 1 functions associated with various signal processing functions. Receiver 312 can perform spatial processing on the information to recover any spatial streams intended for UE 302. If multiple spatial streams are intended for UE 302, receiver 312 can combine these multiple spatial streams into a single OFDM symbol stream. Receiver 312 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the most probable signal cluster points transmitted by base station 304. These soft decisions can be based on channel estimates calculated by a channel estimator. Subsequently, the soft decision is decoded and deinterleaved to recover the data and control signals originally transmitted by base station 304 on the physical channel. The data and control signals are then provided to processing system 332, which implements Layer 3 (L3) and Layer 2 (L2) functions.

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

[0067] Similar to the functions described in conjunction with downlink transmissions performed by base station 304, 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 via ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs to transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via Hybrid Automatic Repeat Request (HARQ), priority processing, and logical channel priority allocation.

[0068] The channel estimate derived by the channel estimator from the reference signal or feedback transmitted by base station 304 can be used by transmitter 314 to select appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial stream generated by transmitter 314 can be provided to different antennas 316. Transmitter 314 can utilize the respective spatial streams to modulate the RF carrier for transmission.

[0069] Uplink transmissions are processed at base station 304 in a manner similar to that described in conjunction with the receiver function at UE 302. Receiver 352 receives signals via its respective antenna 356. Receiver 352 recovers the information modulated on the RF carrier and provides that information to processing system 384.

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

[0071] For convenience, UE 302, base station 304, and / or network entity 306 are illustrated in Figures 3A to 3C as including various components that can be configured according to the various examples described herein. However, it will be understood that the illustrated blocks may have different functions in different designs.

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

[0073] When a UE supporting multimedia (e.g., voice) services reaches the edge of network coverage (e.g., the edge of a WWAN such as LTE or NR networks), the network typically checks a handover threshold and determines whether to hand over 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, they have evolved to increasingly support real-time multimedia-based services, such as frameworks for Real-Time Uplink Streaming (FLUS), Multimedia Telephony Services for Internet Protocol (IP) Multimedia Subsystem (IMS) (MTSI), virtual reality, augmented reality, remote rendering, split rendering (in which case the network and UE share the image processing load), and so on.

[0074] Compared to downlink coverage, uplink coverage in some networks (e.g., LTE and NR networks) tends to be limited, or at least more limited. Consequently, the problem arises that uplink coverage from the UE to the base station (e.g., eNB, gNB) at the network edge tends to be weaker (e.g., leading to higher packet loss rate (PLR) or block error rate (BLER)). Therefore, thresholds are defined to switch multimedia-based communication periods to avoid further degradation in service due to increased packet loss. In such scenarios, the UE checks a handover threshold and determines when to hand over from one radio cell to a neighboring radio cell with similar radio access technology, such as, or to a different RAT (e.g., WLAN).

[0075] Typically, the delivery threshold can even change from one UE to another because the impact of packet loss on multimedia services can depend on various factors, such as the multimedia transcoder or transcoder mode being used by the service, the packet loss concealment (PLC) algorithm implemented at the receiving UE, and the signal interference (or de-interference) buffer management (JBM) implementation used at the receiving UE. For example, one type of multimedia transcoder that can be used is the self-adjusting multi-rate (AMR) audio transcoder, which uses link self-adjustment to select from one of eight different bitrates based on connection conditions, and is typically used in circuit-switched networks. Another multimedia transcoder is self-adjusting multi-rate broadband (AMR-WB), which is similar to the AMR transcoder, but differs in that it provides improved voice quality due to its wider voice bandwidth compared to the AMR audio transcoder. Another multimedia transcoder (Enhanced Voice Service (EVS)) offers higher robustness compared to 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 / decoding compared to the non-channel-aware mode of EVS or AMR / AMR-WB.

[0076] Furthermore, PLC algorithms such as zero-insertion, waveform replacement, and model-based methods can, to some extent, mask the impact of packet loss. This is because multimedia signals are transmitted over the network in packets, which may arrive at their destination via different routes, resulting in delayed arrival, corruption, out-of-order delivery, or failure to arrive at all. Relatedly, since packets may arrive at the decoder out of order or have random signal interference at arrival time, JBM implementations can use different techniques to absorb signal interference at packet arrival time so that multimedia packets can be fed to the decoder at uniformly spaced periodic intervals. Therefore, various factors can affect the tolerable packet loss for each UE in order to maintain high-quality multimedia communication.

[0077] One of the challenges in setting appropriate delivery thresholds, typically handled at mobile infrastructure in WWANs or other wireless networks (e.g., at gNBs in NR networks), is ensuring that the end-to-end (e2e) error rate across the transmission path from media sender to media receiver does not exceed the maximum packet loss that transcoders, PLCs, and JBMs can handle without causing a significant degradation in quality and / or resolveability. For example, Figure 4 illustrates an example end-to-end communication flow between two UEs participating in a multimedia-based communication session, according to various configurations of this disclosure. In the example of Figure 4, the multimedia transmission from UE 402-2 to UE 402-1 (which may correspond to any of the UEs described herein) is transmitted on uplink 432 from UE 402-2 to its serving gNB 422-2 (e.g., any of the base stations described herein). gNB 422-2 forwards the transmission to the serving gNB 422-1 (e.g., any other base station among the base stations described herein) for UE 402-1 via backhaul link 434. The serving gNB 422-1 then transmits the multimedia transmission to the receiving UE 402-1 on downlink 436. Similarly, in the opposite direction, the multimedia transmission from UE 402-1 to UE 402-2 is transmitted on uplink 442 from UE 402-1 to the serving gNB 422-1, which then forwards the transmission to the serving gNB 422-2 for UE 402-2 via backhaul link 444. The serving gNB 422-2 then transmits the multimedia transmission to the receiving UE 402-2 on downlink 446.

[0078] Assuming no packet loss or negligible packet loss occurs on backhaul links 434 and 444, for multimedia transmissions from UE 402-2 to UE 402-1, the sum of the PLRs on uplink 432 and downlink 436 should be less than or equal to the maximum PLR for the transcoder, PLC algorithm, and JBM implementation used at UE 402-1. Similarly, for multimedia transmissions from UE 402-1 to UE 402-2, the sum of the PLRs on uplink 442 and downlink 446 should be less than or equal to the maximum PLR for the transcoder, PLC algorithm, and JBM implementation used at UE 402-2.

[0079] FLUS implements real-time media streaming from a source entity (also referred to as a "FLUS source" or simply a "source") to a slot entity (also referred to as a "FLUS slot" or simply a "slot"). For example, referring to Figure 4, for a 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 slot entity. FLUS provides both IMS-based and non-IMS-based production entities. IMS / MTSI-based production entities implement the establishment of real-time media streaming within and across the service provider network between two UEs or between a source entity and a slot entity. Compared to MTSI (where a limited type of QoS is available for voice or video media), FLUS can provide a wider range of QoS operations, such as maximum latency, available bandwidth, or target PLR. In non-IMS-based production entities, it is possible to operate FLUS as a more general framework, controlled via a RESTful application programming interface (API) and supporting other media plane protocols (i.e., not based on IMS or MTSI). In addition to providing broader QoS operations over radio links, FLUS can offer other enhanced capabilities, such as signal transmission of immersive media (e.g., virtual reality, augmented reality) over existing networks.

[0080] FLUS source entities and FLUS slot entities support point-to-point transmission of voice / audio, video, and text. FLUS source entities can be embodied in a single UE or distributed across the UE and individual audiovisual capture devices, and can support all FLUS features or a subset of FLUS features. When used as a general framework, only the FC procedures (control procedures for source and slot) used to establish FLUS communication need to be supported by the source and slot entities. When provided as part of IMS / MTSI services, the source and slot entities should support IMS control plane and media plane procedures, and the quality of service is determined by the MTSI service policy.

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

[0082] Figure 5 illustrates an example uplink streaming service architecture 500 according to this disclosure. 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 slot 520 located in another UE or in a network. For example, the FLUS slot 520 may 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 capturing devices (e.g., a camera, microphone, etc.). As used herein, one or more capturing devices are considered part of the UE or connected to the UE.

[0083] When FLUS slot 520 is located in the UE, it forwards media content to decoding and rendering functions. When FLUS slot 520 is located in the network, it can forward media content to processing or distribution sub-functions. FLUS slot 520 can act as a Media Gateway (MGW) and / or Application Function (AF).

[0084] The "F" reference point connects FLUS source 510 and FLUS slot 520. The "F" reference point enables the establishment and control of individual FLUS communication sessions. It also allows FLUS slot 520 and FLUS source 510 to authenticate and authorize each other. FLUS source 510 and FLUS slot 520 are each divided into media source and slot (referred to as "FU" endpoints), control source and slot (referred to as "FC" endpoints), remote controller and remote control target (referred to as "F-RC" endpoints), and auxiliary sender and receiver (referred to as "FA" endpoints).

[0085] The UE, FLUS source 510, and FLUS slot 520 are considered logical functions and therefore do not require bits to be in the same physical device; they can be distributed across multiple physical devices and interconnected via other interfaces. Additionally, 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 slot 520 and depend on the services provided. The "F" reference point supports security functions for confidentiality protection across all sub-functions.

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

[0087] Instant uplink media streams (e.g., FLUS) can be added to and used within MTSI communication sessions. To add FLUS-specific media to MTSI communication sessions, and to provide that FLUS-specific media with the appropriate QoS processing suitable for instant uplink streams rather than general conversations, a method is needed to initiate the selection of appropriate QoS for the specific purpose of the FLUS. The initial QoS can be based on different 5G QoS Indicator (5QI) and / or QoS Category Identifier (QCI) values, attributed to its use with the instant uplink stream.

[0088] For the QoS requirements mentioned above, using "a = group:FLUS" is insufficient because there are at least five defined immediate uplink stream 5QI / QCIs to choose from. Furthermore, it is assumed that for network service providers, always selecting a single FLUS 5QI / QCI from the five FLUS 5QI / QCIs for some media for all FLUS applications would be neither desirable nor sufficient, as this would only apply to a subset of possible FLUS use cases, and at best suboptimal for others. It is also assumed that defining new, independent applications for different FLUS use cases would be impractical, even if it were part of an existing MTSI application, as maintaining a 1:1 mapping between 5QI / QCIs and (application, media type) tuples would be impossible.

[0089] As a solution to the problem of inadequate QoS specifications, a proposed approach is to include a non-authoritative QoS hint (e.g., one or more parameters indicating the desired QoS) for each media tagged with FLUS in the Communication Period Description Protocol (SDP) for FLUS communication periods. This hint is taken from the current settings in the FLUS application or from end-user settings by a device that knows the requirements for the current use case. This would allow the Policy Control Function (PCF) / Policy and Charging Rule Function (PCRF) in the core network to (authoritatively) select which 5QI / QCI to use, matching both the current user customization and the current usage of the FLUS device, assuming that the FLUS device itself should be usable in all FLUS use cases (e.g., from very low latency to fairly lenient but still "instantaneous" broadcast latency). The QoS hint could include "latency" attributes (such as "lowest," "low," "medium," "high," and "highest") that can be defined as an ordered list of values, and "missing" attributes (such as "lowest," "low," "medium," "high," and "highest") that can be similarly defined as an ordered list of values.

[0090] The "Loss" value describes the maximum expected packet loss rate for a FLUS communication period, expressed as a percentage via a zero-based integer or a non-zero real value. The "Lateness" value describes the maximum expected packet lateness for a FLUS communication period, expressed in milliseconds (ms) via a zero-based integer or a non-zero real value. Currently, under the assumption that the SDP proposer (e.g., the FLUS source or slot) and the responder (e.g., the other party in the FLUS source and slot) will share the packet loss budget equally, the "Loss" value included in the SDP proposal represents half of the expected maximum end-to-end packet loss. Under the assumption that the proposer and responder will share the packet latence budget equally, the "Lateness" value included in the SDP proposal typically represents half of the expected maximum end-to-end packet latence.

[0091] A "loss" value received in the SDP response that is exactly the same as the SDP proposal is considered as the SDP responder accepting equal sharing of the end-to-end packet loss budget, which is half of the maximum end-to-end packet loss as a result. A "loss" value received in the SDP response that is greater than the one in the SDP proposal is considered as the SDP responder not sharing the end-to-end packet loss budget equally, with the value in the SDP response representing the SDP responder's portion, and the total maximum end-to-end loss hint as a result equal to the sum of the "loss" parameters from both the SDP proposal and the SDP response.

[0092] A "latency" value received in the SDP response that is identical to the SDP proposal is considered as the SDP responder accepting equal sharing of the end-to-end packet latency budget, and this value is half of the maximum end-to-end packet latency as a result. A "latency" value received in the SDP response that is greater than the one in the SDP proposal is considered as the SDP responder not sharing the end-to-end packet latency budget equally, the value in the SDP response representing the SDP responder's portion, and the total maximum end-to-end latency hint as a result equal to the sum of the "latency" parameters from the SDP proposal and the SDP response.

[0093] Based on the loss and latency parameters in the QoS cues exchanged between the proposer and responder during SDP communication, the network assigns appropriate QoS processing (i.e., appropriate QCI / 5QI).

[0094] This QoS tipping solution can be used across all services providing uplink streaming services, such as FLUS and MTSI. The solution can even be extended to services where specific loss and latency requirements can vary significantly, such as conversational virtual reality and / or augmented reality, telepresence, split rendering, cloud rendering, and so on. Therefore, it is important to consider how to more commonly use QoS tips for these other services, and for future services.

[0095] When an SDP proposer proposes a QoS, it can select the QoS based on the user's customization, the type / quality of the service offered (e.g., instant news reporting versus live streaming on a social network), and the proposer's link requirements 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 implementation of the UE's features (such as JBM and PLC). Even if the UE is part of the same mobile network service provider's (MNO) network, such variations in implementation may require different target loss rates to achieve the same voice quality. This consideration has been addressed by allowing the media receiver to indicate the maximum e2e PLR ​​it can handle based on its specific implementation.

[0096] In some cases, such as if the UE's receive-decode-render processing chain (including the lack of asynchronous time warping / local reprojection capabilities) requires more time to render media within the end-to-end target latency for services more sensitive to latency, the SDP respondent may require a more stringent latency than offered. There may also be scenarios where the proposer has not requested the most stringent QoS allowed by its customization. For example, the UE and its customization might support semi-professional news reporting while also supporting social video sharing applications. Or a virtual reality head-mounted display (HMD) might support both cloud rendering and split rendering, each with very different latency requirements. In such scenarios, the respondent may be able to negotiate a more stringent QoS level allowed by the proposer's customization than what it has already offered. Accordingly, the respondent should be able to indicate the need for a more stringent QoS than what is offered.

[0097] When the FLUS slot is located in the core network and there is no radio link between the gNB / eNB and the FLUS slot (i.e., there is a wired connection between the gNB / eNB and the FLUS slot), the loss on that link can be considered practically zero, and the latency can be considered very low (if not zero). For the FLUS slot, it may be beneficial to indicate in the SDP response that this very low loss / latency is intended for the appropriate QoS resources to be reserved on the radio link to the FLUS source (i.e., the radio link between the UE acting as the FLUS source and the serving base station). Furthermore, if there is a use case where the network FLUS slot sends an SDP proposal, it would also be beneficial to indicate this very low loss / latency in that proposal.

[0098] Even for non-FLUS services, other scenarios may exist where one link 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 efficiently generated. For example, such scenarios could include MTSI or conversational AR / VR communication scenarios where one terminal is connected via cable or a very low loss / latency connection.

[0099] For SDP responders who need to request stricter QoS, various solutions exist. As a first solution, as mentioned above, the QoS hint can be half of the expected maximum end-to-end loss / latency. In this solution, as previously stated, under the assumption that the proposer and responder will share the packet loss budget equally, the "loss" value included in the SDP proposal represents half of the expected maximum end-to-end packet loss. Similarly, under the assumption that the proposer and responder will share the packet latency budget equally, the "latency" value included in the SDP proposal represents half of the expected maximum end-to-end packet latency.

[0100] However, while this solution provides the responder with the option to request a higher loss / latency value than what is offered, it does not provide the option to request a lower loss / latency value. This means that the end-to-end loss / latency will need to be at least twice that offered. Even if the solution were modified to allow the responder to request a lower loss / latency value than offered, the lowest loss / latency the responder could request would be zero, which would prevent the end-to-end loss / latency from being any lower than offered. For example, an SDP proposer (e.g., a FLUS slot) might offer 50 ms of latency on its radio link, but this latency might not be good enough for an SDP responder (e.g., a FLUS source), which might require an end-to-end latency of 30 ms. Even if the responder reduces its latency to 0 (which is unlikely), the end-to-end latency would still be 50 ms. Under this solution, the responder cannot indicate to the proposer that it needs a better latency.

[0101] Another challenge with this approach is addressing the issue of insufficient QoS in the proposal. If the FLUS source sends the proposal, this can lead to overly stringent QoS allocation. For example, if a FLUS source sends a proposal with half its desired end-to-end loss / latency, and the network FLUS slot responds with approximately zero loss / latency, the resulting total end-to-end loss / latency will be half that required by the FLUS source (because the FLUS source requires half). If the PCRF / PCF only considers the loss / latency value in the proposal (from the FLUS source on its network), it may choose overly stringent QoS processing.

[0102] Furthermore, if a network FLUS slot sends a proposal indicating a very low loss / latency, it appears to encourage the FLUS source (responder) to attempt to match that very low value to its own radio link. This could impose unnecessarily stringent QoS requirements on the FLUS source's radio link, when in fact, since the FLUS slot doesn't introduce any significant loss or latency, it might even be less stringent. Therefore, it's unclear how a network FLUS slot can indicate a very low loss / latency and encourage the FLUS source to adopt that very low loss / latency with a more lenient QoS on its radio link.

[0103] To address at least some of these issues, the responder can reject the proposed SDP INVITE and subsequently send a new proposal with lower loss / latency to satisfy its requirements. However, in some scenarios, having the responder reject the proposal and then send a re-proposal may be unacceptable. For example, if the proposer is a FLUS source and the responder is a FLUS slot (in the network or another UE), having the FLUS slot reject the proposal and subsequently propose a proposal for receiving the FLUS stream is a problematic use case.

[0104] Another approach is for the responder to reject an INVITE with an SDP 488 (unacceptable here) message, along with the expected (more stringent) QoS loss / latency. This will provide the proposing party with an indication of which QoS hint values ​​to include in the resubmission. However, this will still have some of the disadvantages described above.

[0105] Therefore, this disclosure provides a technique for enabling FLUS slots and sources to negotiate end-to-end loss / latency via SDP. In one instance, the definitions of "loss" and "latency" can be modified so that these SDP attributes represent end-to-end loss / latency as follows: Under the assumption that the proposer and responder will share the packet loss budget equally, the "loss" value included in the SDP proposal can represent the expected maximum end-to-end packet loss. Under the assumption that the proposer and responder will share the packet latency budget equally, the "latency" value included in the SDP proposal can represent the expected maximum end-to-end packet latency. In one instance, the loss value can describe the maximum expected packet loss rate as a percentage (but without the "%" symbol) using zero-based integers or non-zero real values. The latency value can describe the maximum expected packet latency in milliseconds, for example, using zero-based integers or non-zero real values. Based on this equivalent value, 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 (e.g., the radio link for the FLUS source and the radio link for the FLUS slot, both of which are UEs).

[0106] In some cases, problems may still arise when a network FLUS slot responds to a proposal from a FLUS source by sending an SDP reply. For example, in the first case, the FLUS slot might respond with an end-to-end loss latency value that is twice the value provided by the FLUS source, because it understands that its link will introduce negligible loss / latency, and that the PCF / PCRF will use half the end-to-end latency when selecting QCI / 5QI. However, if the proposing FLUS source deems twice the loss / latency it provides unacceptable for the service, it can terminate the communication period. As another example, in the second case, the FLUS slot might respond with an end-to-end loss latency value equal to the value provided by the FLUS source. In this case, the PCRF / PCF will select an overly restrictive QCI / 5QI, failing to meet half the provided loss / latency requirement.

[0107] Similar problems can arise if the network FLUS slot sends an SDP proposal. For example, in the first case, the FLUS slot might set the end-to-end loss / latency to the value actually expected by the service. However, when the PCF / PCRF sees this, it won't understand that the FLUS slot introduces negligible loss / latency and will choose an unnecessarily strict QCI / 5QI (specifically, half the end-to-end loss / latency). As another example, in the second case, the FLUS slot might set the end-to-end loss / latency to twice the value actually expected by the service. This would allow the PCF / PCRF to choose an appropriate QCI / 5QI (i.e., twice the expected loss / latency). However, it's possible that the responding client might determine that the (doubled) loss / latency in the SDP proposal is too high and attempt to lower the end-to-end value in the SDP response. This would result in the same overly strict QoS reservation for the radio link described in the first case.

[0108] Therefore, in some cases, it may still be necessary for the network FLUS slot to indicate to the PCF / PCRF: the network can allocate the entire end-to-end loss / latency to the radio link between the FLUS source and the base station, so there is no reliable way to avoid selecting an overly strict QCI / 5QI for the radio link.

[0109] Therefore, this disclosure provides an additional technique for negotiating end-to-end and per-link loss / latency between FLUS sources and slots via SDP. Similarly, in addition to the solution described above, optional parameters can be defined that will allow the proposer and responder to indicate how end-to-end loss / latency will be distributed across their radio links.

[0110] In one scenario, QoS prompts may include uplink prompt values ​​and downlink prompt values. The uplink prompt value indicates the expected loss / latency on the uplink of the proposing / responding party, and the downlink prompt value indicates the expected loss / latency on the downlink of the proposing / responding party. In this way, the network FLUS slot can use these optional uplink / downlink parameters to explicitly indicate near-zero loss / latency on its link, thereby enabling the network to allocate the entire expected loss / latency to the UE FLUS source. For example, the network FLUS slot may propose / respond with a downlink prompt value of "0" (to indicate near-zero loss / latency on its backhaul link from the base station to the FLUS slot). Alternatively, an uplink prompt value may be included to be applied to the backhaul link between the FLUS slot and the base station, assuming traffic is expected to be transmitted in that direction (e.g., TCP acknowledgments (ACKs) are transmitted in the opposite direction to the media transmission via TCP). The UE FLUS source can specify end-to-end loss / latency or a specific uplink loss / latency in its proposal / response, and optionally downlink loss / latency. The network can then allocate the entire loss / latency to the UE FLUS source's radio link, and not to the network FLUS slot.

[0111] Uplink and downlink values ​​are independently selectable. That is, it is not necessary to provide both in pairs. This is to take into account two scenarios: 1) the proposer or responder does not have any preference for one of the transmission directions, and / or 2) the QoS hint is used in a one-way "transmit-only" or "receive-only" stream, so setting uplink or downlink values ​​would be meaningless. For example, for an uplink-only stream that does not transmit traffic on the UE downlink, the FLUS source is not concerned, so there is no need to specify downlink parameters for the FLUS slot.

[0112] In one case, the uplink hint value is the QoS hint value on the uplink of the proposing / responding party, and can be represented by a zero-based integer, a non-zero real number, or a notation (e.g., an index value or a value to be expanded later). The downlink hint value is the QoS hint value on the downlink of the proposing / responding party, and can be represented by a zero-based integer, a non-zero real number, or a notation (e.g., an index value or a value to be expanded later).

[0113] It should be noted that the QoS cue parameters described above should appear only once in the proposal / response. If the QoS cue parameters are not included, it should be interpreted that the UE and application do not have a preference for any QoS value for those QoS cue parameters, and that anything the network can provide is equally acceptable.

[0114] Figure 6 illustrates an example call flow 600 between UE FLUS source 602 and network FLUS slot 604 according to various configurations disclosed herein. UE FLUS source 602 may correspond to any UE described herein, and network FLUS slot 604 may correspond to a base station (e.g., any base station described herein), a core network entity, an application server (e.g., application server 172), a remote client, etc. In the example of Figure 6, network FLUS slot 604 is the SDP proposer, and UE FLUS source 602 is the SDP responder; however, it should be understood that these roles may be reversed.

[0115] At 610, network FLUS slot 604 sends an SDP proposal to UE FLUS source 602. Since the proposer is the network FLUS slot, the proposal may include at least a downlink loss / latency QoS hint value, either as an alternative to or in addition to the end-to-end loss / latency QoS hint value. The downlink loss / latency QoS hint value may be "0" to indicate negligible loss / latency on the backhaul link between the base station (not shown) serving UE FLUS source 602 and network FLUS slot 604. The proposal may also include a zero uplink loss / latency QoS hint value for the backhaul link between FLUS slot 604 and the serving base station, if traffic (e.g., TCP ACK) is expected to be transmitted in that direction as well.

[0116] At 620, UE FLUS source 602 sends a response to network FLUS slot 604. In SDP, for a response to accept a proposal, it needs to include the same attributes as those in the proposal. If the responding party (i.e., UE FLUS source 602) accepts the end-to-end loss / latency in the proposal, it can include that value in its response, as well as the uplink loss / latency QoS hint value equal to the end-to-end loss / latency, because the reload downlink to network FLUS slot 604 will not introduce any loss / latency.

[0117] The response may also include a downlink loss / latency QoS indication value for the radio link between the serving base station (not shown) and UE FLUS slot 604, if the proposal indicates that traffic may exist in that direction. In this case, the response will indicate that the downlink loss / latency is equal to the end-to-end loss latency because the uplink latency on the reload from network FLUS slot 604 to the serving base station is zero. If the proposal does not include an uplink loss / latency QoS indication value, UE FLUS source 602 may include the indication and its preferred value in the response.

[0118] Alternatively, if the proposal includes end-to-end loss / latency QoS hint values ​​and downlink loss / latency QoS hint values, then UE FLUS source 602 can export the provided uplink loss / latency QoS hint value and determine whether to accept it. If UE FLUS source 602 accepts it, it can respond using the provided end-to-end loss / latency QoS hint value and uplink / downlink parameter values, as described above. If it does not accept it, it can respond using different end-to-end loss / latency QoS hint values ​​and different uplink / downlink parameter values.

[0119] Network FLUS slot 604 and UE FLUS source 602 can repeat operations 610 and 620 until they agree on the lost / latent QoS hint values. Alternatively, they can perform operations 610 and 620 only once, even if they disagree.

[0120] At 630, network 606 (e.g., PCF / PCRF) selects Q5I / QCI based at least in part on the lost / latent QoS cue value. If UE FLUS source 602 and downlink lost / latent QoS cue value agree on the lost / latent QoS cue value, network 606 can select the Q5I / QCI that best matches the agreed value.

[0121] At 640, network 606 allocates resources to the connection between UE FLUS source 602 and network FLUS slot 604 (specifically, the radio link between UE FLUS source 602 and its serving base station). Once the link is established using the selected Q5I / QCI, UE FLUS source 602 can begin streaming uplink media to network FLUS slot 604.

[0122] Figure 7 illustrates an example method 700 of wireless communication according to various embodiments of this disclosure. Method 700 can be performed by an SDP responder (e.g., a FLUS source / slot).

[0123] At 710, the responder receives from the proposer (e.g., FLUS source / slot) a first plurality of QoS parameters for the multimedia communication period (e.g., FLUS communication period) to be established between the proposer and the responder, as at 610 in FIG. 6. In one state, the first plurality of QoS parameters includes: a first loss parameter indicating the first expected maximum end-to-end packet loss for the multimedia communication period, a first latency parameter indicating the first expected maximum end-to-end packet latency for the multimedia communication period, or both. In one state, when the responder is a UE, operation 710 can be performed by WWAN transceiver 310, processing system 332, storage component 340, and / or uplink streaming service component 342, any one or all of which can be considered as components for performing the operation. In one state, when the responding party is a base station, operation 710 can be performed by the WWAN transceiver 350, the processing system 384, the storage unit 386, and / or the uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In another state, when the responding party is a network entity, operation 710 can be performed by the network interface 390, the processing system 394, the storage unit 396, and / or the QoS allocation unit 398, any one or all of which can be considered as components for performing the operation.

[0124] 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 communication period, the first expected maximum end-to-end packet latency is higher than the second expected maximum end-to-end packet latency for the multimedia communication period, or both. In one state, when the responder is a UE, operation 720 can be performed by the WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In another state, when the responder is a base station, operation 720 can be performed by the WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In one case, when the responder is a network entity, operation 720 can be performed by network interface 390, processing system 394, storage component 396 and / or QoS allocation component 398, any one or all of which can be considered as components for performing the operation.

[0125] At 730, as at 620 in Figure 6, the responder sends a second plurality of QoS parameters for the multimedia communication period to the proposer. In one state, the second plurality of QoS parameters includes: a second loss parameter indicating the second expected maximum end-to-end packet loss, a second latency parameter indicating the second expected maximum end-to-end packet latency, or both. In one state, when the responder is a UE, operation 730 can be performed by WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In one state, when the responder is a base station, operation 730 can be performed by WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In one case, when the responder is a network entity, operation 730 can be performed by network interface 390, processing system 394, storage component 396 and / or QoS allocation component 398, any one or all of which can be considered as components for performing the operation.

[0126] Figure 8 illustrates an example method 800 of wireless communication according to various embodiments of this disclosure. Method 800 can be performed by the proposer (e.g., FLUS source / slot).

[0127] At 810, the proposer sends a first plurality of QoS parameters to the responder (e.g., FLUS source / slot) for the multimedia communication period to be established between the proposer and the responder, as shown at 610 in FIG. 6. In one state, the first plurality of QoS parameters includes: a first loss parameter indicating the maximum expected end-to-end packet loss for the multimedia communication period, a first latency parameter indicating the maximum expected end-to-end packet latency for the multimedia communication period, or both. In one state, if the proposer is a UE, operation 810 can be performed by WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In one state, if the proposer is a base station, operation 810 can be performed by WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In one instance, when the proposer is a network entity, operation 810 can be performed by network interface 390, processing system 394, storage component 396 and / or QoS allocation component 398, any one or all of which can be considered as components for performing the operation.

[0128] At 820, the proposer receives a second plurality of QoS parameters for the multimedia communication period from the responder, as shown at 620 in Figure 6. In one state, the second plurality of QoS parameters includes: a second loss parameter indicating the second expected maximum end-to-end packet loss for the multimedia communication period, a second latency parameter indicating the second expected maximum end-to-end packet latency for the multimedia communication period, or both. In one state, when the proposer is a UE, operation 820 can be performed by WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In one state, when the proposer is a base station, operation 820 can be performed by WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In one instance, when the proposer is a network entity, operation 820 can be performed by network interface 390, processing system 394, storage component 396 and / or QoS allocation component 398, any one or all of which can be considered as components for performing the operation.

[0129] At point 830, the proposer determines whether it can establish a multimedia communication period with the responder based on a second plurality of QoS parameters for the multimedia communication period. In one state, when the proposer is a UE, operation 830 can be performed by the WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In another state, when the proposer is a base station, operation 830 can be performed by the WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In another state, when the proposer is a network entity, operation 830 can be performed by the network interface 390, processing system 394, storage unit 396, and / or QoS allocation unit 398, any one or all of which can be considered as components for performing the operation.

[0130] At point 840, a multimedia communication period is established between the proposer and the responder, the multimedia communication period having a second plurality of QoS parameters. In one state, when the proposer is a UE, operation 840 can be performed by WWAN transceiver 310, processing system 332, storage unit 340, and / or uplink streaming service unit 342, any one or all of which can be considered as components for performing the operation. In another state, when the proposer is a base station, operation 840 can be performed by WWAN transceiver 350, processing system 384, storage unit 386, and / or uplink streaming service unit 388, any one or all of which can be considered as components for performing the operation. In another state, when the proposer is a network entity, operation 840 can be performed by network interface 390, processing system 394, storage unit 396, and / or QoS allocation unit 398, any one or all of which can be considered as components for performing the operation.

[0131] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and methods. For example, data, instructions, commands, information, signals, bits, symbols, and chips mentioned in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0132] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the forms disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above in general terms of their functions. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functions in alternative ways for each specific application, but such implementation decisions should not be construed as departing from the scope of protection of this disclosure.

[0133] The various illustrative logic blocks, modules, and circuits described in connection with the states disclosed herein can be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device designed to perform the functions described herein, individual gate or transistor logic, individual hardware components, or any combination thereof. The general-purpose processor can be a microprocessor, or alternatively, the processor can be any general-purpose processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors with a DSP core, or any other such configuration.

[0134] The methods, sequences, and / or algorithms described herein can be directly embodied in hardware, a software module executed by a processor, or a combination of both. The software module can reside in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), electronically erasable programmable ROM (EEPROM), registers, hard disks, removable disks, CD-ROMs, or any other form of storage media known in the art. Example storage media can be coupled to a processor, allowing the processor to read information from and write information to the storage media. Alternatively, the storage media can be a component of the processor. The processor and storage media can reside in an ASIC. The ASIC can reside in a user terminal (e.g., a UE). Alternatively, the processor and storage media can reside as separate components in the user terminal.

[0135] In one or more example formats, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored on a computer-readable medium or transmitted via one or more instructions or codes on a computer-readable medium. Computer-readable media includes both computer storage media and communication media, including any media that facilitates the transfer of computer programs from one place to another. Storage media may be any available media that a computer can access. For example, but not limitingly, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to carry or store desired program code having an instruction or data structure and that can be accessed by a computer. Furthermore, any connection may be appropriately referred to as computer-readable media. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, magnetic disks and optical disks include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where magnetic disks typically reproduce data magnetically, while optical discs use lasers to optically reproduce data. Combinations of the above should also be included within the scope of protection for computer-readable media.

[0136] While the foregoing disclosure illustrates the illustrative nature of this disclosure, it should be noted that various changes and modifications may be made herein without departing from the scope of protection defined by the appended claims. The functions, steps, and / or actions of the method claims according to the various aspects of this disclosure described herein do not need to be performed in any particular order. Furthermore, although the elements of this disclosure are described or claimed in the singular, the plural form is contemplated unless expressly stated to be limited to the singular.

[0137] 100: Wireless Communication System 102:Base station 102': Small cell base platform 104:UE 110: Geographical coverage area 110': Geographical coverage area 120: Communication Link 122: Backload Link 134: Backload Link 150: Wireless Local Area Network (WLAN) Access Point (AP) 152: WLAN Station (STA) 154: Communication Link 164:UE 170: Core Network 172: Application Server 180:mmW base station 182:UE 184:mmW communication link 190:UE 192: D2D P2P Link 194: D2D P2P Link 200: Wireless Network Architecture 204:UE 210:5GC 212: User plane function 213:NG-U 214: Control Plane Functions 215: Control Plane Interface (NG-C) 220: New RAN 222:gNB 223: Reload Link 224:ng-eNB 230: Location Server 250: Wireless Network Structure 260:5GC 262: User Plane Function (UPF) 263: User Interface 264: Access and Mobility Management Functions (AMF) 265: Control Plane Interface 266: Communication Management Function (SMF) 270: Location Management Function (LMF) 272: Safe User Plane Positioning (SUPL) Positioning Platform (SLP) 302:UE 304:Base station 306: Network Entity 310: Wireless Wide Area Network (WWAN) Transceiver / Cube 312: Receiver 314: Transmitter 316: Antenna 318: Signal 320: Wireless Local Area Network (WLAN) Transceiver 322: Receiver 324: Launcher 326: Antenna 328: Signal 330: Satellite Positioning System (SPS) Receiver 332: Processing System 334: Data Bus 336: Antenna 338: SPS signal 340: Storage component 342: Uplink Streaming Service Component 344: Sensor 346: / square 350: Wireless Wide Area Network (WWAN) Transceiver 352: Receiver 354: Launcher 356: Antenna 358: Signal 360: Wireless Local Area Network (WLAN) Transceiver 362: Receiver 364: Launcher 366: Antenna 368: Signal 370: Satellite Positioning System (SPS) Receiver 376: Antenna 378: SPS signal 380: Network Interface 382: Data Bus 384: Processing System 386: Storage component 388: Uplink Streaming Service Component 390: Network Interface 392: Data Bus 394: Processing System 396: Storage components 398: QoS Allocation Component 402-1:UE 402-2:UE 422-1: Service gNB 422-2: Service gNB 432: Uplink 434: Backload Link 436: Downlink 442: Uplink 444: Backload Link 446: Downlink 500: Uplink Streaming Service Architecture 510:FLUS Source 520: FLUS slot 600: Call Stream 602:UE FLUS source 604: Network FLUS slot 606: Network 610: Operation 620: Operation 630: Operation 640: Operation 700: Method 710: Steps 720: Steps 730: Steps 800: Method 810: Steps 820: Steps 830: Steps 840: Steps F: Reference point

Claims

1. A method for performing wireless communication by a responder, comprising the steps of: receiving a proposal from a proposer, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposer and the responder, the first plurality of QoS parameters including a first latency parameter indicating, in milliseconds, a first desired maximum end-to-end packet latency for the multimedia communication period; determining that the first desired maximum end-to-end packet latency is higher than a second desired maximum end-to-end packet latency for the multimedia communication period; and sending a response to the proposer, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: A second latency parameter indicating the maximum end-to-end packet latency of the second expectation in milliseconds; Wherein (1) the proposer 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 proposer is the non-UE network node that initiates the proposal and the responder is the UE that initiates the response.

2. The method as described in 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 latency is distributed across a communication link between the responder and the proposer.

3. The method as described in claim 2, wherein the second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet latency is distributed across an uplink communication link of the responder.

4. The method as described in claim 3, wherein: The responder includes a frame for an instant uplink streaming (FLUS) source, and the proposer includes a FLUS slot, or the responder includes a FLUS slot and the proposer includes a FLUS source.

5. The method as described in claim 2, wherein the second plurality of QoS parameters also includes an indication of how to distribute the first desired maximum end-to-end packet latency value across the responder's downlink communication links.

6. The method as described in claim 5, wherein: The responder includes a FLUS slot and the proposer includes a FLUS source, or the responder includes a FLUS source and the proposer includes a FLUS slot.

7. The method as described in claim 1, wherein the first plurality of QoS parameters also includes one or more values ​​indicating how the first desired maximum end-to-end packet latency is distributed across a communication link between the proposer and the responder.

8. The method as described in claim 1, wherein the first plurality of QoS parameters also includes an indication of how to distribute the first desired maximum end-to-end packet latency value across the proposer's downlink communication links.

9. The method as described in claim 8, wherein: The proposer includes a FLUS slot and the responder includes a FLUS source, or the proposer includes a FLUS source and the responder includes a FLUS slot.

10. The method as described in claim 1, wherein the first plurality of QoS parameters also includes an uplink value indicating how the first desired maximum end-to-end packet latency is distributed across an uplink communication link of the proposer.

11. The method as described in claim 10, wherein: The proposer includes a FLUS source and the responder includes a FLUS slot, or the proposer includes a FLUS slot and the responder includes a FLUS source.

12. The method as described in claim 1, wherein: The first plurality of QoS parameters are received in a first communication period description protocol (SDP) message, and the second plurality of QoS parameters are sent in a second SDP message.

13. The method as described in claim 1, wherein the multimedia communication period includes a FLUS communication period, a Multimedia Telephony Service Multimedia Subsystem (IMS) (MTSI) communication period for Internet Protocol (IP), an Extended Reality communication period, a Telepresence communication period, or a Separate Rendering communication period.

14. The method as described in claim 1 also includes the steps of: receiving from the proposer an acceptance of the second plurality of QoS parameters for the multimedia communication period; and establishing the multimedia communication period with the proposer based on the receipt of the acceptance.

15. The method as described in claim 1 also includes the steps of: receiving from the proposer a rejection of the second plurality of QoS parameters for the multimedia communication period; and, based on the receipt of the rejection, discarding the multimedia communication period with the proposer.

16. A method for conducting wireless communication performed by a proposer, comprising the steps of: sending a response to a responder, the response including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposer and the responder, the first plurality of QoS parameters including a first latency parameter in milliseconds indicating a first desired maximum end-to-end packet latency for the multimedia communication period; receiving a response from the responder, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: A second latency parameter indicating the maximum end-to-end packet latency for a second expected multimedia communication period in milliseconds; determining whether the proposer can establish the multimedia communication period with the responder based on the multimedia communication period having the second plurality of QoS parameters; and establishing the multimedia communication period with the responder, the multimedia communication period having the second plurality of QoS parameters; wherein (1) the proposer is a user equipment (UE) that initiated the proposal and the responder is a non-UE network node that initiated the response, or (2) the proposer is the non-UE network node that initiated the proposal and the responder is the UE that initiated the response.

17. The method as described in 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 latency is distributed across a communication link between the responder and the proposer.

18. The method as described in claim 17, wherein the second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet latency is distributed across an uplink communication link of the responder.

19. The method as described in claim 18, wherein: The responder includes a frame for an instant uplink streaming (FLUS) source, and the proposer includes a FLUS slot, or the responder includes a FLUS slot and the proposer includes a FLUS source.

20. The method as described in claim 17, wherein the second plurality of QoS parameters also includes an indication of how to distribute the first desired maximum end-to-end packet latency value across the responder's downlink communication links.

21. The method as described in claim 20, wherein: The responder includes a FLUS slot and the proposer includes a FLUS source, or the responder includes a FLUS source and the proposer includes a FLUS slot.

22. The method as described in claim 16, wherein the first plurality of QoS parameters also includes an uplink value and a downlink value indicating how to distribute the first desired maximum end-to-end packet latency across a communication link between the proposer and the responder.

23. The method as described in claim 16, wherein the first plurality of QoS parameters also include an indication of how to distribute the first desired maximum end-to-end packet latency downlink value across the proposer's downlink communication links.

24. The method as described in claim 23, wherein: The proposer includes a FLUS slot and the responder includes a FLUS source, or the proposer includes a FLUS source and the responder includes a FLUS slot.

25. The method as described in claim 16, wherein the first plurality of QoS parameters also includes an uplink value indicating how the first desired maximum end-to-end packet latency is distributed across an uplink communication link of the proposer.

26. The method as described in claim 25, wherein: The proposer includes a FLUS source and the responder includes a FLUS slot, or the proposer includes a FLUS slot and the responder includes a FLUS source.

27. The method as described in claim 16, wherein: The first plurality of QoS parameters are sent in a first communication period description protocol (SDP) message, and the second plurality of QoS parameters are received in a second SDP message.

28. The method as described in claim 16, wherein the multimedia communication period includes a FLUS communication period, a Multimedia Telephony Service Multimedia Subsystem (IMS) (MTSI) communication period for Internet Protocol (IP), an Extended Reality communication period, a Telepresence communication period, or a Separate Rendering communication period.

29. The method as described in claim 16 also includes the step of: sending an acceptance to the responding party for the second plurality of QoS parameters for the multimedia communication period.

30. A responder device, comprising: One memory; A communication device; The device includes one or more processors communicatively coupled to the memory and the communication device, the processors being configured to: receive a proposal from a proposing device, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposing and responding devices, the first plurality of QoS parameters including a first latency parameter indicating a first desired maximum end-to-end packet latency for the multimedia communication period in milliseconds; determine that the first desired maximum end-to-end packet latency is higher than a second desired maximum end-to-end packet latency for the multimedia communication period; and cause the communication device to send a response to the proposing device, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second latency parameter indicating the second desired maximum end-to-end packet latency in milliseconds; Wherein (1) the proposer 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 proposer is the non-UE network node that initiates the proposal and the responder is the UE that initiates the response.

31. The responding device as described in 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 latency is distributed across a communication link between the responding device and the proposing device.

32. The responding device as described in claim 31, wherein the second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet latency is distributed across an uplink communication link of the responding device.

33. The responder device as described in claim 32, wherein: The responder device includes a frame for an instant uplink streaming (FLUS) source, and the proposer device includes a FLUS slot, or the responder device includes a FLUS slot and the proposer device includes a FLUS source.

34. The responding device as described in claim 31, wherein the second plurality of QoS parameters also includes an indication of how to distribute the first desired maximum end-to-end packet latency across the downlink communication links of the responding device.

35. The responder device as described in claim 34, wherein: The responder device includes a FLUS slot, and the proposer device includes a FLUS source, or the responder device includes a FLUS source and the proposer device includes a FLUS slot.

36. The responding device as described in claim 30, wherein the first plurality of QoS parameters also include one or more values ​​indicating how the first desired maximum end-to-end packet latency is distributed across a communication link between the proposing device and the responding device.

37. The responding device as described in claim 30, wherein the first plurality of QoS parameters also include an indication of how to distribute the first desired maximum end-to-end packet latency across the downlink communication links of the proposing device.

38. The responder device as described in claim 37, wherein: The proposing device includes a FLUS slot, and the responding device includes a FLUS source, or the proposing device includes a FLUS source, and the responding device includes a FLUS slot.

39. The responding device as described in claim 30, wherein the first plurality of QoS parameters also includes an uplink value indicating how the first desired maximum end-to-end packet latency is distributed across an uplink communication link of the proposing device.

40. The responder device as described in claim 39, wherein: The proposing device includes a FLUS source and the responding device includes a FLUS slot, or the proposing device includes a FLUS slot and the responding device includes a FLUS source.

41. The responder device as described in claim 30, wherein: The proposing device is a UE, and the responding device is the non-UE network node, and the communication device includes at least one network interface.

42. The responder device as described in claim 30, wherein: The proposing device is the non-UE network node, and the responding device is a UE, and the communication device includes at least one transceiver.

43. The responder device as described in claim 30, wherein: The first plurality of QoS parameters are received in a first communication period description protocol (SDP) message, and the second plurality of QoS parameters are sent in a second SDP message.

44. The responding device as described in claim 30, wherein the multimedia communication period includes a FLUS communication period, a Multimedia Telephony Service Multimedia Subsystem (IMS) (MTSI) communication period for Internet Protocol (IP), an extended reality communication period, a telepresence communication period, or a split-rendering communication period.

45. The responding device as described in claim 30, wherein the one or more processors are also configured to: receive from the proposing device an acceptance of the second plurality of QoS parameters for the multimedia communication period; and establish the multimedia communication period with the proposing device based on the receipt of the acceptance.

46. ​​The responding device as described in claim 30, wherein the one or more processors are also configured to: receive from the proposing device a rejection of the second plurality of QoS parameters for the multimedia communication period; and, based on the receipt of the rejection, discard the multimedia communication period with the proposing device.

47. A proposing device, comprising: One memory; A communication device; The device includes one or more processors communicatively coupled to the memory and the communication device, the processors being configured to: cause the communication device to send a proposal to a responding device, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposing device and the responding device, the first plurality of QoS parameters including a first latency parameter indicating, in milliseconds, a first desired maximum end-to-end packet latency for the multimedia communication period; receive a response from the responding device, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second latency parameter indicating, in milliseconds, a second desired maximum end-to-end packet latency for the multimedia communication period; determine, based on the multimedia communication period having the second plurality of QoS parameters, whether the proposing device is capable of establishing the multimedia communication period with the responding device; and establish the multimedia communication period with the responding device, the multimedia communication period having the second plurality of QoS parameters. Wherein (1) the proposing device is a user equipment (UE) that initiates the proposal and the responding device is a non-UE network node that initiates the response, or (2) the proposing device is the non-UE network node that initiates the proposal and the responding device is the UE that initiates the response.

48. The proposing device as described in 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 latency is distributed across a communication link between the responding device and the proposing device.

49. The proposing device as described in claim 48, wherein the second plurality of QoS parameters also includes an uplink value indicating how the second desired maximum end-to-end packet latency is distributed across an uplink communication link of the responding device.

50. The proposing device as described in claim 49, wherein: The responder device includes a frame for an instant uplink streaming (FLUS) source, and the proposer device includes a FLUS slot, or the responder device includes a FLUS slot and the proposer device includes a FLUS source.

51. The proposing device as described in claim 48, wherein the second plurality of QoS parameters also include an indication of how to distribute the first desired maximum end-to-end packet latency value across the downlink communication links of the responding device.

52. The proposing device as described in claim 51, wherein: The responder device includes a FLUS slot, and the proposer device includes a FLUS source, or the responder device includes a FLUS source and the proposer device includes a FLUS slot.

53. The proposing device as described in claim 47, wherein the first plurality of QoS parameters also include an uplink value and a downlink value indicating how to distribute the first desired maximum end-to-end packet latency across a communication link between the proposing and responding devices.

54. The proposing device as described in claim 47, wherein the first plurality of QoS parameters also include an indication of how to distribute the first desired maximum end-to-end packet latency across the downlink communication links of the proposing device.

55. The proposing device as described in claim 54, wherein: The proposing device includes a FLUS slot, and the responding device includes a FLUS source, or the proposing device includes a FLUS source, and the responding device includes a FLUS slot.

56. The proposing device as described in claim 47, wherein the first plurality of QoS parameters also includes an uplink value indicating how the first desired maximum end-to-end packet latency is distributed across an uplink communication link of the proposing device.

57. The proposing device as described in claim 56, wherein: The proposing device includes a FLUS source and the responding device includes a FLUS slot, or the proposing device includes a FLUS slot and the responding device includes a FLUS source.

58. The proposing device as described in claim 47, wherein: The proposing device is a UE, and the responding device is the non-UE network node, and the communication device includes at least one transceiver.

59. The proposing device as described in claim 47, wherein: The proposing device is the non-UE network node, and the responding device is a UE, and the communication device includes at least one network interface.

60. The proposing device as described in claim 47, wherein: The first plurality of QoS parameters are sent in a first communication period description protocol (SDP) message, and the second plurality of QoS parameters are received in a second SDP message.

61. The proposer apparatus as described in claim 47, wherein the multimedia communication period includes a FLUS communication period, a Multimedia Telephony Service Multimedia Subsystem (IMS) (MTSI) communication period for Internet Protocol (IP), an extended reality communication period, a telepresence communication period, or a separate rendering communication period.

62. The proposing device as described in claim 47, wherein the one or more processors are also configured to: cause the communication device to send an acceptance to the responding device for the second plurality of QoS parameters for the multimedia communication period.

63. A responder device, comprising: The device includes components for receiving a proposal from a proposing device, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposing device and the responding device, the first plurality of QoS parameters including a first latency parameter indicating, in milliseconds, a first desired maximum end-to-end packet latency for the multimedia communication period; components for determining that the first desired maximum end-to-end packet latency is higher than a second desired maximum end-to-end packet latency for the multimedia communication period; and components for sending a response to the proposing device, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second latency parameter indicating, in milliseconds, the second desired maximum end-to-end packet latency; wherein (1) the proposing device is a user equipment (UE) that initiated the proposal and the responding device is a non-UE network node that initiated the response, or (2) the proposing device is the non-UE network node that initiated the proposal and the responding device is the UE that initiated the response.

64. A proposing device, comprising: The device includes components for sending a proposal to a responding device, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposing device and the responding device, the first plurality of QoS parameters including a first latency parameter indicating, in milliseconds, a first desired maximum end-to-end packet latency for the multimedia communication period; components for receiving a response from the responding device, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including a second latency parameter indicating, in milliseconds, a second desired maximum end-to-end packet latency for the multimedia communication period; components for determining, based on the second plurality of QoS parameters, whether the proposing device is capable of establishing the multimedia communication period with the responding device; and components for establishing the multimedia communication period with the responding device, the multimedia communication period having the second plurality of QoS parameters. Wherein (1) the proposing device is a user equipment (UE) that initiates the proposal and the responding device is a non-UE network node that initiates the response, or (2) the proposing device is the non-UE network node that initiates the proposal and the responding device is the UE that initiates the response.

65. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by a respondent, causes the respondent to: receive a proposal from a proposer, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposer and the respondent, the first plurality of QoS parameters including a first latency parameter indicating, in milliseconds, a first desired maximum end-to-end packet latency for the multimedia communication period; determine that the first desired maximum end-to-end packet latency is higher than a second desired maximum end-to-end packet latency for the multimedia communication period; and send a response to the proposer, the response including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: A second latency parameter indicating the maximum end-to-end packet latency of the second expectation in milliseconds; Wherein (1) the proposer 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 proposer is the 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, which, when executed by a proposer, causes the proposer to: send a proposal to a responder, the proposal including a first plurality of Quality of Service (QoS) parameters for a multimedia communication period to be established between the proposer and the responder, the first plurality of QoS parameters indicating in milliseconds a first desired maximum end-to-end packet latency for the multimedia communication period; and receive a response from the responder including a second plurality of QoS parameters for the multimedia communication period, the second plurality of QoS parameters including: A second latency parameter indicating the maximum end-to-end packet latency for a second expected multimedia communication period in milliseconds; determining whether the proposer can establish the multimedia communication period with the responder based on the multimedia communication period having the second plurality of QoS parameters; and establishing the multimedia communication period with the responder, the multimedia communication period having the second plurality of QoS parameters; wherein (1) the proposer is a user equipment (UE) that initiated the proposal and the responder is a non-UE network node that initiated the response, or (2) the proposer is the non-UE network node that initiated the proposal and the responder is the UE that initiated the response.

Images