EVOLUTION STACK

REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/335,946 filed May 13, 2016, entitled "AVOIDING DISCARD OF CRITICAL VIDEO DATA IN MODEM LONG TERM EVOLUTION STACK", the contents of which are herein incorporated by reference in their entirety.

FIELD

[0002] The present disclosure relates to video streaming, and more specifically avoiding the discard of critical video data in a modem long term evolution (LTE) stack.

BACKGROUND

[0003] Wireless mobile communication technology uses various standards and protocols to transmit data between a node (e.g., a transmission station) and a wireless device (e.g., a mobile device), or a user equipment (UE). In 3GPP radio access network (RAN) LTE systems, an access node can be a combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) which communicates with the UE. The downlink (DL) transmission can be a communication from the node (e.g., eNB) to the UE, and the uplink (UL) transmission can be a communication from the wireless device to the node.

[0004] Various potential enhancements have been proposed for voice over long term evolution (VoLTE) as well as for video over long term evolution (ViLTE) at various RAN levels. For ViLTE there is a need resulting from various existing challenges. For example, unlike VoLTE data, the ViLTE decoder can be less robust against packet loss. The quality of the decoded frames depends on the preceding frames. For example in H264 encoding an l-frame is the key reference frame for a whole video sequence; the P-frames are the compressed frames attached to the l-frame and used during prediction. If an l-frame is lost or partially lost, the full video sequence is lost until a new l-frame is received, which is perceived by the end-user (e.g., UE) as a video freeze of typically a few seconds. If a P- frame is fully / completely lost, the prediction chain is broken and the video sequence becomes frozen until a new l-frame is received. However, if a P-frame is partially received, it can be attempted to be decoded and the next frames can be attempted to be decoded.

[0005] Furthermore, unlike VoLTE, the video bitrate can be variable and not constant, and so the size of video frames (after H264 encoding) can vary significantly. The typical Foreman video reference can shows a typical ratio l-frame/P-frame = 4 to 5 or even more. Therefore where the uplink (UL) radio conditions are not ideal, or when the eNB allocates scheduled grants for the ViLTE device or UE (in case the cell is highly loaded), the transmission time of an l-frame can be significantly longer than the average transmission time of the other frames.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a block diagram illustrating an example of a network device such as a user equipment (UE) or an evolved NodeB (eNB) useable in connection with various aspects described herein.

[0007] FIG. 2 is a block diagram of another example of a UE, an eNB, or other network device that operates to prevent video data loss according to various aspects described herein.

[0008] FIG. 3 is a block diagram of another example of a UE, an eNB, or other network device that operates to prevent video data loss according to various aspects described herein.

[0009] FIG. 4 illustrates a block diagram of an example video bearer queue in accordance with one or more aspects.

[0010] FIG. 5 illustrates a block diagram of a media access control control element (MAC CE) for communicating various indications or statuses of video data in accordance with one or more aspects.

[0011] FIG. 6 illustrates a block diagram of a packet data convergence protocol (PDCP) header for communicating various indications or statuses of video data in accordance with one or more aspects.

[0012] FIG. 7 illustrates an example process flow for avoiding a discard of critical video data in a modem long term evolution stack of a network device in accordance with one or more aspects described herein. [0013] FIG. 8 illustrates another example process flow in accordance with one or more aspects described herein.

DETAILED DESCRIPTION

[0014] The present disclosure will now be described with reference to the attached drawing figures, wherein like reference numerals are used to refer to like elements throughout, and wherein the illustrated structures and devices are not necessarily drawn to scale. As utilized herein, terms "component," "system," "interface," and the like are intended to refer to a computer-related entity, hardware, software (e.g., in execution), and/or firmware. For example, a component can be a processor (e.g., a microprocessor, a controller, or other processing device), a process running on a processor, a controller, an object, an executable, a program, a storage device, a computer, a tablet PC and/or a user equipment (UE) (e.g., mobile / wireless phone, etc.) with a processing device. By way of illustration, an application running on a server and the server can also be a component. One or more components can reside within a process, and a component can be localized on one computer and/or distributed between two or more computers. A set of elements or a set of other components can be described herein, in which the term "set" can be interpreted as "one or more."

[0015] Further, these components can execute from various computer readable storage media or computer readable medium having various data structures stored thereon such as with a module, for example. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network, such as, the Internet, a local area network, a wide area network, or similar network with other systems via the signal).

[0016] As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, in which the electric or electronic circuitry can be operated by a software application or a firmware application executed by one or more processors. The one or more processors can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts; the electronic components can include one or more processors therein to execute software and/or firmware that confer(s), at least in part, the functionality of the electronic

components.

[0017] Use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms "including", "includes", "having", "has", "with", or variants thereof are used in either the detailed description and the claims, such terms are intended to be inclusive in a manner similar to the term "comprising."

[0018] As used herein, the term "circuitry" may refer to, be part of, or include

an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor

(shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some

embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

OVERVIEW

[0019] In consideration of the above described deficiencies of wireless communication operations, various aspects for preventing the discard of ViLTE data over an LTE network by initiating a modification of the UL bandwidth, via an increase in the number of UL grants or an increase in the size of UL grants. For example, a network device can classify video packets to be transmitted over a long term evolution (LTE) network as critical or non-critical service data units (SDUs) (e.g., a critical packet data convergence protocol (PDCP) SDU) of a video bearer queue. A communication can be generated that identifies any SDU classified as critical and initiates a modification of an uplink (UL) bandwidth to avoid discarding video data of the video packets in response to the communication. The eNB can then enable an increase in a number of UL grants or an increase in a size of UL grants to the UE to facilitate the modification of UL bandwidth.

[0020] ViLTE data can be carried by a dedicated guaranteed bit rate (GBR) bearer configured in radio link control (RLC) unacknowledged mode (UM) and with a finite packet data convergence protocol (PDCP) discard timer (or SDU discard timer) = 150ms typically since it is a real-time traffic. This means that the life-time of real-time transport protocol (RTP) packets in the modem of the UE or the video bearer queue of the UE can be bounded, and under UL channel congestion, some RTP packets can be discarded because they are too old before being transmitted to the eNB or video sender. Therefore, the I- frames are the ones with the highest probability of packet discard because they are the longest frames.

[0021] In particular, video data of l-frames are the most critical data of the ViLTE bearer for the perceived video quality on the remote side at the UE. This video data is also the weakest among the video frames. Video bitrate adaptation does not necessarily resolve the challenge. Internet protocol multimedia subsystem (IMS) has defined some bitrate adaptation mechanisms where the video receiver can request bitrate adaptation based on statistical analysis of the received video flow (temporary max media bitrate (TMMBR) feedback carried in a real-time control transport protocol (RTCP) report). As an alternate embodiment, the video sender can also locally detect radio UL congestion and adapt its bitrate accordingly. However, the challenge of preventing PDCP discard of l-frame data remains unsolved. Additional aspects and details of the disclosure are further described below with reference to figures.

[0022] Embodiments described herein can be implemented into a system using any suitably configured hardware and/or software. FIG. 1 illustrates, for one embodiment, example components of a cell network device 100, such as a base station, a macro cell network device, a secondary cell network device, a small cell network device, an evolved / enhanced NodeB (eNB), or any other network device (e.g. a user equipment, pico cell, Femto cell or the like). In some embodiments, the cell network device 100 can include application circuitry 102, baseband circuitry 104, Radio Frequency (RF) circuitry 106, front- end module (FEM) circuitry 108 and one or more antennas 1 10, coupled together at least as shown.

[0023] The application circuitry 102 can include one or more application processors. For example, the application circuitry 102 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with and/or can include memory/storage and can be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system.

[0024] The baseband circuitry 104 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 104 can include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 106 and to generate baseband signals for a transmit signal path of the RF circuitry 106. Baseband processing circuity 104 can interface with the application circuitry 102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 106. For example, in some embodiments, the baseband circuitry 104 can include a second generation (2G) baseband processor 104a, third generation (3G) baseband processor 104b, fourth generation (4G) baseband processor 104c, and/or other baseband processor(s) 104d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 104 (e.g., one or more of baseband processors 104a-d) can handle various radio control functions that

enable communication with one or more radio networks via the RF circuitry 106. The radio control functions can include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments,

modulation/demodulation circuitry of the baseband circuitry 104 can include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping / demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 104 can include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and can include other suitable functionality in other embodiments.

[0025] In some embodiments, the baseband circuitry 104 can include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial

radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) elements, or other communication protocol layer components. A central processing unit (CPU) 104e of the baseband circuitry 104 can be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry can include one or more audio digital signal processor(s) (DSP) 104f. The audio DSP(s) 104f can be include elements for compression/decompression and echo cancellation and can include other suitable processing elements in other embodiments. Components of the baseband circuitry can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 104 and the application circuitry 102 can be implemented together such as, for example, on a system on a chip (SOC).

[0026] In some embodiments, the baseband circuitry 104 can provide for

communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 104 can support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 104 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0027] RF circuitry 106 can enable communication with wireless networks

using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 106 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 106 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 108 and provide baseband signals to the baseband circuitry 104. RF circuitry 106 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry 104 and provide RF output signals to the FEM circuitry 108 for transmission.

[0028] In some embodiments, the RF circuitry 106 can include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 106 can include mixer circuitry 106a, amplifier circuitry 106b and filter circuitry 106c. The transmit signal path of the RF circuitry 106 can include filter circuitry 1 06c and mixer circuitry 106a. RF circuitry 106 can also include synthesizer circuitry 106d for synthesizing a frequency for use by the mixer circuitry 106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 106a of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 108 based on the synthesized frequency provided by synthesizer circuitry 106d. The amplifier circuitry 106b can be configured to amplify the down-converted signals and the filter circuitry 106c can be a low- pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 104 for further processing. In some embodiments, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 106a of the receive signal path can comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0029] In some embodiments, the mixer circuitry 106a of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 106d to generate RF output signals for the FEM circuitry 108. The baseband signals can be provided by the baseband circuitry 104 and can be filtered by filter circuitry 106c. The filter circuitry 106c can include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

[0030] In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a of the transmit signal path can include two or more mixers and can be arranged for quadrature down-conversion or up-conversion respectively. In some

embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a can be arranged for direct down-conversion or direct up-conversion, respectively. In some embodiments, the mixer circuitry 106a of the receive signal path and the mixer circuitry 106a of the transmit signal path can be configured for super-heterodyne operation.

[0031] In some embodiments, the output baseband signals and the input baseband signals can be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternate

embodiments, the RF circuitry 106 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 104 can include a digital baseband interface to communicate with the RF circuitry 106.

[0032] In some dual-mode embodiments, a separate radio IC circuitry can be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0033] In some embodiments, the synthesizer circuitry 106d can be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 106d can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

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

[0035] In some embodiments, frequency input can be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input can be provided by either the baseband circuitry 104 or the applications processor 102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the applications processor 102. [0036] Synthesizer circuitry 106d of the RF circuitry 106 can include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA). In some embodiments, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements can be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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

[0038] FEM circuitry 108 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 1 10, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 106 for further processing. FEM circuitry 108 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 106 for transmission by one or more of the one or more antennas 1 10.

[0039] In some embodiments, the FEM circuitry 108 can include a TX / RX switch to switch between transmit mode and receive mode operation, or operate

concurrently/simultaneously. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 106). The transmit signal path of the FEM circuitry 108 can include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 106), a processor and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1 10.

[0040] In some embodiments, the cell network device 100 can include additional elements such as, for example, one or more processors, memory/storage, display, camera, sensor, and/or input/output (I/O) interface.

[0041] Embodiments disclosed herein can be enabled or facilitated by one or more components (e.g., FEM circuitry 108, RF circuitry 106, baseband circuitry 104, or otherwise) of the cell network device 100 to enable the classification and communication of critical video SDUs within a video bearer queue (e.g., memory 224 of FIG. 2). These SDUs can be selected from among PDCP SDUs that carry a real-time transport protocol (RTP) packet of an l-frame, or that carry an RTCP feedback report, for example, or that carry any packet which is determined as critical for the perceived quality on the remote or on the sender device. However, l-frame data and some RTCP feedback packets are not usually able to have a preferred handling over P-frame data because they are carried by the same video bearer. Although embodiments disclosed herein can assist the eNB scheduling processes via the UL radio interface so that this critical video data is still transmitted on- time and the detriments from the discarding of such data are avoided.

[0042] In an aspect, the RTP video packets can be classified by components of the network device 100 as critical and non-critical SDUs. The video data of l-frames can be the most important ones for the perceived video quality (e.g., by the eNB or other network device) for the remote device. The quality of the received video on the local side or by the UE, for example, can depend on the successful transmission of some RTCP feedbacks, which can be carried by the same bearer as the video sent data. Hence, if a video bearer queue is highly full, some of these feedbacks can be discarded because their lifetime has expired. Some of these feedbacks (e.g., RTCP feedbacks reports) could be considered as critical data, especially, for example, with an RTCP full intra request (particularly true with dynamic instantaneous decoder refresh(es)), or some RTCP negative acknowledgements (NACKs) (with some NACK packets being more critical than others for visual perception).

[0043] In particular, l-frame data and some RTCP feedback packets do not typically have a preferred handling versus P-frame data because they are carried by the same bearer. However, the UL radio interface can be configured to transmit this critical data. Embodiments disclosed herein can help the eNB scheduling algorithm for UL grants so that these critical data are further ensured to be transmitted on-time.

[0044] In one embodiment, a media access control (MAC) control element can be configured to notify the eNB of a presence of critical data (l-frame or some critical RTCP feedback). The MAC control element can be further configured to indicate to the eNB of a level of satisfaction (or an estimation) with current UL grants or the most critical UL grants. For example, an indication of the MAC control element can indicate that that allocated UL grants are not sufficient to transmit the PDCP SDUs classified as critical data before their death or deletion, before an expiration of a discard time or whether the PDCP SDUs deemed critical have sufficient UL bandwidth to be transmitted. The network device (e.g., the UE 100) can be satisfied if it estimates that these critical data will be transmitted before their death. Death of the critical data can occur, for example, when a PDCP timer of the device expires. As a result of a timer expiration, the network device 100 can discard the critical data or critical PDCP SDUs, for example. As a result of the eNB receiving such communication of the MAC control element with these indications, the eNB can initiate a preferred allocation of more UL grants or larger UL grants until these critical data (either as PDCP SDUS of an l-frame, of PDCP SDUs of a RTCP feedback report) can be completely transmitted.

[0045] In another aspect, a set of reserved bits (e.g., two or more reserved bits, three reserved bits or more) of a PDCP Header (e.g., a 12 sequence number header) can be generated as in-band signaling communication to indicate whether the SDU (e.g., a PDCP SDU) is a critical one and in addition the number of consecutive critical PDCP SDUs following this critical PDCP SDU or on the same video frame, which by default can be zero unless indicated.

[0046] As such, the eNB communicating video data associated with ViLTE can be triggered or initiated to perform a packet inspection of data of the video GBR bearer by communications from the UE. If these communication bits indicate that there are a number N of critical PDCP frames just following the current frame, the eNB, for example, can constrain UL scheduling processes to anticipate the desire of larger or more frequent grants and thereby influence the LTE eNB scheduling of UL grants by taking into account the quantity of data per bearer as well as the classification (critical / non-critical).

[0047] FIG. 2 further illustrates an embodiment of a network device or system 200 to be employed in an eNB, a UE or other network device that facilitates or enables signaling mechanisms to prevent discarding of critical video data, including critical video SDUs of an l-frame, an RTCP feedback report, or both. System or device 200 can include the baseband circuitry component 104, the radio frequency (RF) circuitry component 106, or a front end module circuitry component 108 of FIG. 1 , as well as communication component or platform 208 with transmitter circuitry component(s) / receiver circuitry component 210, a processor 216 and memory 224.

[0048] In various aspects, system 200 can be included within an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (Evolved Node B, eNodeB, or eNB), other base station, network access point, a secondary cell network device (e.g., a small cell, or WiFi network device) or other cell network component/device (e.g., UE) in a wireless communications network. Memory 224 also can include instructions that can be implemented by processor 216, transmitter circuitry 210, or receiver circuitry 210 to implement various aspects described herein.

[0049] Memory 224 can comprise one or more machine-readable medium / media including instructions that, when performed by a machine or component herein cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to embodiments and examples described herein. It is to be understood that aspects described herein can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium (e.g., the memory described herein or other storage device). Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media or a computer readable storage device can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other tangible and/or non-transitory medium, that can be used to carry or store desired information or executable instructions. Also, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and 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 medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. As described in greater detail below, system 200.

[0050] Access equipment (e.g., eNB, network entity, or the like), UE or software related to access of the network device 200 can receive and transmit signal(s) from and to wireless devices, wireless ports, wireless routers, etc. through segments 202 202 _B (B is a positive integer). Segments 202 202 _B can be internal and/or external to access equipment and/or software related to access of a network, and can be controlled by a monitor component 204 and an antenna component 206. Monitor component 204 and antenna component 206 can couple to communication component 208, which can include electronic components and associated circuitry that provide for processing and manipulation of received signal(s) and other signal(s) to be transmitted.

[0051] In an aspect, communication component 208 includes the receiver/transmitter 210 that can convert analog signals to digital signals upon reception of the analog signals, and can convert digital signals to analog signals upon transmission. In addition, receiver / transmitter 210 can divide a single data stream into multiple, parallel data streams, or perform the reciprocal operation. Coupled to receiver/transmitter 210 can be a multiplexer / demultiplexer 212 that can facilitate manipulation of signals in time and frequency space. Multiplexer / demultiplexer 212 can multiplex information (data/traffic and control/signaling) according to various multiplexing schemes such as time division multiplexing, frequency division multiplexing, orthogonal frequency division multiplexing, code division multiplexing, space division multiplexing. In addition, multiplexer / demultiplexer component 212 can scramble and spread information (e.g., codes, according to substantially any code known in the art, such as Hadamard-Walsh codes, Baker codes, Kasami codes, polyphase codes, and so forth).

[0052] A modulator / demodulator 214 can also be a part of communication component / platform 208, and can modulate information according to multiple modulation techniques, such as frequency modulation, amplitude modulation (e.g., M-ary quadrature amplitude modulation, with M a positive integer); phase-shift keying; and so forth).

[0053] Access equipment and/or software related to access of a network also includes a processor 216 configured to confer, at least in part, functionality to substantially any electronic component in access equipment and/or software. In particular, processor 216 can facilitate configuration of access equipment and/or software through, for example, monitor component 204, antenna component 206, and one or more components therein. Additionally, access equipment and/or software can include display interface 218, which can display functions that control functionality of access equipment and/or software or reveal operation conditions thereof. In addition, display interface 218 can include a screen to convey information to an end user. In an aspect, display interface 218 can be a liquid crystal display, a plasma panel, a monolithic thin-film based electrochromic display, and so on. Moreover, display interface 218 can include a component (e.g., speaker) that facilitates communication of aural indicia, which can also be employed in connection with messages that convey operational instructions to an end user. Display interface 218 can also facilitate data entry (e.g., through a linked keypad or through touch gestures), which can cause access equipment and/or software to receive external commands (e.g., restart operation).

[0054] Broadband network interface 220 facilitates connection of access equipment or software to a service provider network (not shown) that can include one or more cellular technologies (e.g., third generation partnership project universal mobile telecommunication system, global system for mobile communication, and so on) through backhaul link(s) (not shown), which enable incoming and outgoing data flow. Broadband network interface 220 can be internal or external to access equipment and/or software and can utilize display interface 218 for end-user interaction and status information delivery.

[0055] Processor 216 can be functionally connected to communication platform 208 and can facilitate operations on data (e.g., symbols, bits, or chips) for multiplexing/demultiplexing, such as effecting direct and inverse fast Fourier transforms, selection of modulation rates, selection of data packet formats, inter-packet times, and so on. Moreover, processor 216 can be functionally connected, through data, system, or an address bus 222, to display interface 218 and broadband network interface 220, to confer, at least in part, functionality to each of such components.

[0056] In access equipment and/or software memory 224 can retain location and/or coverage area (e.g., macro sector, identifier(s)) access list(s) that authorize access to wireless coverage through access equipment and/or software sector intelligence that can include ranking of coverage areas in the wireless environment of access equipment and/or software, radio link quality and strength associated therewith, or the like. Memory 2164 also can store data structures, code instructions and program modules, system or device information, code sequences for scrambling, spreading and pilot transmission, access point configuration, and so on. Processor 216 can be coupled (e.g., through a memory bus), to memory 224 in order to store and retrieve information used to operate and/or confer functionality to the components, platform, and interface that reside within access equipment and/or software.

[0057] The network device 200, system, component or device herein can be

incorporated into or otherwise part of, an eNB, a UE, or some other type of electronic device in accordance with various embodiments. Specifically, the electronic device or components or interfaces described herein can be logic and/or circuitry that can be at least partially implemented in one or more of hardware, software, and/or firmware. In

embodiments, the electronic device logic can include radio transmit logic and receive logic (e.g., 210) coupled to control logic (e.g., processor 216). In embodiments, the transmit and/or receive logic can be elements or modules of transceiver logic 210. The electronic device and/or the components, circuitry or interfaces of such electronic device can be configured to perform operations similar to those described elsewhere in this disclosure.

[0058] In an embodiment, the network device 200 further includes a classification component 226 that can be configured to identify or classify video packets from among video packets of a video bearer queue (e.g., the memory 224). The classification

component 226 can operate to label, tag or otherwise distinguish critical video packets from non-critical video packets to be transmitted over an LTE network or ViLTE network. The determination of criticality can be derived from a packet inspection process from a packet transfer mode protocol or other layer that performs such type of packet inspection for other purposes, and so can extend classification to video packets for determining a level of criticality (critical or non-critical) based on various criteria (e.g., UL discard time, video buffer queue congestion, or other criteria).

[0059] Additionally or alternatively, the classification component 226 can be configured to tag, or otherwise designate RTP packets of an l-frame, at least a portion / part of RTCP feedbacks, or both in metadata. For example, an RTP packet, a video PDCP SDU, or an RTCP feedback datum / report can be tagged as critical or non-critical.

[0060] In another embodiment, the classification component 226 can be further configured to determine a number of critical video SDUs (or video PDCP SDUs) that follow the critical video PDCP SDU related to an l-frame or a critical RTCP feedback. For example, a number of critical video SDUs can default as none, and if any critical video SDUs follow the critical video SDU on the same frame or up to the next l-frame, the amount or number of following video SDUs can be determined. By determining number of SDUs with video data (e.g., PDCP SDUs) following a critical PDCP SDU, this number can communicated (via UE) or processed (via eNB) in order to initiate UL grants (either by an increased size or increase in number of UL grants) to accommodate transmission of the critical video data stored in the video bearer queue (e.g., memory 224) based on the number of SDUs following the first identified critical video SDU.

[0061] The communication component 208 can be configured to generate a

communication comprising an indication that identifies the video packet that is classified as the critical video SDU. The communication component 208 can configure the

communication to initiate a modification of the UL bandwidth to avoid discarding video data of the video packets in the video bearer queue. This modification can be a switching from a regularly scheduled UL grant to one that is increased in size or in number of UL grants being scheduled, which can be based on the communication being generated, for example. The communication generated by the communication component 208 can also include an identification of the critical video data as associated with the PDCP SDU of an l-frame, an RTCP feedback, or both. [0062] In other embodiments, the communication can be generated with a media access control (MAC) control element or in a PDCP header. For example, a MAC control element can include various bits where at least one bit indicates the presence of a critical PDCP SDU in the video bearer queue 224, and at least one other bit indicates an estimation that the critical PDCP SDU is to be discarded before being transmitted based on the received UL grants (current UL grants or most critical UL grants), which can be utilized as factor for determining an amount of increase in UL grants or UL grant sizes, for example.

[0063] In another example, a PDCP header can utilize a set of reserve bits (e.g., about three or more bits) where at least one bit of the reserved bits can indicate a presence of the critical video PDCP SDU in the video bearer queue. Other bits (e.g., two bits or more) can provide an indication of the number of critical PDCP SDUs in the video bearer queue that follow the critical video PDCP SDU.

[0064] By one or more of these embodiments or aspects, an eNB (e.g., the network device 200 can do packet inspection of data of the video bearer (e.g., a video GBR bearer). If the indications or bits indicate that there are N critical PDCP frames sequentially or subsequently following the current frame, it can constrain its UL scheduling processes to anticipate the desire of larger or more frequent grants. These indications, for example, can play a similar role as DiffServ bits of an IP header: DiffServ bits can influence the

processing of the concerned IP packet in the IP network. As such, reserve bits or other bits of a MAC control element or a PDCP header can influence the LTE eNB scheduler, and the eNB (e.g., 200) can take into account the quantity of critical data per video bearer.

[0065] Referring to FIG. 3, illustrated is another example of a network device or system 300 to be employed in an eNB, a UE or other network device that facilitates or enables signaling mechanisms to prevent discarding of critical video data, including critical video SDUs of an l-frame, an RTCP feedback report, or both. The network device 300, for example, includes similar components as the network device 200 of FIG. 2, and further includes a partition component 302, a determination component 304, a discard component 306 and an optional scheduling component 308.

[0066] The partition component 302 can operate to partition the video bearer queue between non-critical PDCP SDU and critical PDCP SDU by tagging a real-time transport protocol (RTP) packet of an l-frame, a real-time control transport protocol (RTCP) feedback, or both. The partition component 302 of the network device 300 can separate the classified packets which it receives from the video stack in the video bearer queue 224 as critical SDUs (of l-frames and some critical RTCP feedbacks) and non-critical SDUs.

[0067] For example, referring briefly to FIG. 4, the data store or memory 224 can be split via the partition component 302 into different sections 41 0 and 41 0, which can include a non-critical data section 41 0 and a critical data section 420. The video data as video packets within frames can be inspected in the modem upper layers: including a layer (e.g., the classification component 226) above the PDCP, which can receive the UL data from the connectivity and dispatch them in different bearer queues 410 and 420, for example. The layer can perform additional processing relying on packet inspection to optimize the overall traffic management with the video bearer queue 224. This packet-traffic-layer can extend its processing to this type of classification. Alternatively, the video stack (e.g., SDUs 0-4) could have a means (e.g., the partition component 302) to tag the RTP packets of an I- frame and some critical RTCP feedbacks in metadata.

[0068] The partition component 302, for example, can separate SDUs (e.g., SDUs 0-4) of the video bearer queue 224 into the two queues41 0 and 420. SDU 4 and SDU 0, for example, can be separate video frames within a sequence of video data frames. SDUs 1 -3 can be video packets on a same frame, for example. The first critical SDU can be identified as SDU 1 , for example. Additionally, SDUs 2 and 3 could be identified as contiguous linked list of video SDUs as critical on the same frame or following the first identified critical SDU (e.g., SDU 1 ). The last critical SDUs can be indexed with N=1 corresponding to SDU 3 of the frame 404, for example.

[0069] In one example, Q can represent the quantity of video data from a beginning of the video bearer queue critical data partition 420 up to SDU _N1 , in which Q

=∑^ _Q SD U size (k) ; where NO can be the index of the first critical SDU in the queue 1 24, and N1 can be the index of the last critical SDU of a contiguous linked list of critical SDUs (e.g., N1 = SDU 3).

[0070] Referring back to FIG. 3, the determination component 304 can generate a determination of whether a critical SDU is estimated to be discarded prior to being transmitted from the video bearer queue 224 based on at least one of: a remaining time to discard of the critical PDCP SDU or an estimated transmission time of the critical PDCP SDU. In response to the determination, the communication component 208 can generate the communication (e.g., from UE 100 to eNB 200) with an additional indication that the critical PDCP SDU is estimated to be discarded prior to the transmission, which is a function of or based on current or the most high level UL grants presently provided at the UE.

[0071] Additionally or alternatively, in an attempt to transmit the critical data, if the determination component 304 of the network device 300 estimates that there is a high risk or likelihood that the critical video data (e.g., a PDCP SDU classified as critical) could not be transmitted or communicated within a time, or before an expiration of the SDU discard timer (e.g., discard component 306), which can be at about 150 ms or other time range, then the discard component 306 can discard the preceding data of P-frame(s) up to the first critical video data / PDCP SDU in the video bearer queue 224. This discarding can then operate to enable the next UL grants to be used to transmit the critical video data to the eNB (e.g., 100 or 200), for example. Further, the communication component 208 can generate the communication with additional indication that non-critical PDCP SDUs have been deleted. As such, the eNB's scheduler or scheduling component 308 can take into account that non-critical PDCP SDUs have been deleted in medication of the UL grants when determining whether to increase the size or the number of UL grants to the UE for UL transmissions.

[0072] The scheduling component 308 can operate to schedule UL grants to a UE communicatively coupled to the LTE network by switching between a modified UL bandwidth via an increase in a number of UL grants or a size of UL grants, and a regular UL bandwidth that is smaller than the modified UL bandwidth, either smaller in number or size. For example, a UE (e.g., 100) can transmit an indication of critical video data (a critical PDCP SDU and RTCP feedback report), an identification of the video data, as well as other identifications of subsequent critical video data, and whether there has been a discarding of non-critical video data (e.g., P-frames) or an amount of non-critical data from the video bearer queue 224. In response to receiving any portion of this data, the scheduling component 308 can take these indications into consideration when determining the size or number of UL grants to modified for the UE's further transmission. [0073] Referring to FIG. 5 illustrates an example of a MAC control element 500 that can be generated by the communication component 208 in accordance with one or more aspects or embodiments described herein. The communication component 208 of FIG. 3 can operate to generate communications with indication(s) of one or more critical video PDCP SDUs within the video bearer queue 224. This communication can be generated with a MAC control element (MAC CE) 500 comprising a byte (e.g., Video_MAC_CE).

[0074] The MAC CE 500 can include a critical video data indication 506 (e.g., CrDPr), which can comprise a single bit indicating that a critical SDU is present in the video bearer queue 224. The LCID indications 502 and 504 can comprise identification(s) of a particular video bearer. A happy indication 508 can be generated within the MAC CE 500 to indicate that, with latest / current UL grant allocation, the critical video SDU classified within the video bearer queue 224 will be dead before being transmitted. For example, the indication 508 can provide whether a discard timer (e.g., discard component 306) is estimated to expire before transmission of the particular critical video data (e.g., critical PDCP SDU or related RTCP feedback data). Additional bits can also indicate other information related to the critical PDCP SDU as one of ordinary skill in the art can appreciate, such as related to non-critical SDU preceding the first critical SDU tagged, for example.

[0075] When a MAC layer or communication component 208 of the MAC layer has a MAC PDU to build, it can check if there are any critical SDUs in the video bearer queue 224. If yes, it can then transmit a Video_MAC_CE 500 with CrDPr as True. When all the critical SDUs are transmitted (e.g., by a UE 100, 200 or 300), the communication

component 208 will then no longer transmit or generate any more Video MAC CEs. By this means, the scheduling component 308 of an eNB (e.g., 100, 200 or 300) can know that critical video data are ready to be transmitted. As a consequence, the scheduling component 308 can take this knowledge into account in its scheduling processes and can then attempt to allocate either large enough UL grants or more frequent UL grants to the UE. When the above Video MAC-CE is not transmitted, generated, received or processed, the scheduling component can switch back to the regular scheduling or standard UL grants that can be either less in number or smaller in size, for example.

[0076] In another embodiment, the communication component 208 or discard

component 306 can operate at the MAC layer to compute a remaining time to discard of the critical video data, called RemainingTimeToDiscard (RTTD) as well as an estimated transmission time of the critical video SDU, called

estimatedTransmissionTimeofCriticalSDU (eTTC). For example, RTTD = SDUNI Discard time - Current time and eTTC = (Q + amount of more critical data) /(latest UL grant/ΔΤ); wherein as indicated above with respect to FIG. 4, Q =∑%=o SDU size (k), where N1 can be the index of the last critical SDU of a contiguous linked list of critical SDUs (e.g., N1 = SDU 3).

[0077] In addition, an amount of more critical data can be the current buffer status report (BSR) value of signaling radio bearers (SRBs) or audio bearers, and the latest UL grant / ΔΤ can further determine the latest UL bitrate (ΔΤ being the interval between 2 last successive UL grants). In some embodiments, the considered UL radio bitrate can be an estimated UL bitrate using a first order filter (with a forgetting factor to be tuned) or an average UL bitrate sliding window and the past (UL grant _η /ΔΤ _η ). The eTTC can be determined when the latest critical SDU would be transmitted if the eNB assigned the same grant as the latest grant at a periodicity = ΔΤ. SRB and audio data can be subtracted at each evaluation because they can be more critical and can take a portion of the UL grant, for example.

[0078] If the equation eTTC «RTTD is satisfied, the network device or component (e.g., discard component 306) can estimate that the critical video SDUs would be sent on time if the eNB assigns the same grant and same periodicity to the device. As such, indication 508 can be set as true (e.g., the Happy bit = True). If the previous equation is not satisfied (e.g., eTTC >RTTD), then network device or component (e.g., the discard component 306) can estimate that the transmission of critical video SDUs is at risk if the eNB does not assign a larger UL grant, or if it does not assign more grants (smaller ΔΤ), and the indication 508 can be false (e.g., set the Happy bit = False). Both flags or indications 506 and 508 (Happy and CrDPr) can thus trigger or influence the eNB

scheduler 308 so that it does its best to get these critical video data of the video bearer queue 224 transmitted on-time.

[0079] Referring to FIG. 6, illustrated is an example of a PDCP header 600 in

accordance with various aspects or embodiments. The communication component 208 of FIG. 3 can operate to generate communications with indication(s) of one or more critical video PDCP SDUs within the video bearer queue 224 by additionally or alternatively configuring a PDCP header. This communication can be generated by the communication component 208 as a set of bits 602-606 (e.g., three reserve (R) bits) of the PDCP header 600 according to a PDCP data protocol data unit (PDU) format, which can be used for data resource blocks (DRBs) using a 12 bit sequence number (SN) 608 as in-band signaling, for example, arranged in octets (Oct).

[0080] Video packets cam be classified as critical SDUs and non-critical SDUs via the classification component 226 as discussed above. The PDCP layer of a video stack or communication layer can use this information to fill in-band signaling based on the R bits 602-606 of PDCP header. R0 602 can indicate whether the video packet belongs to a critical video data or not. The R1 -R2 bits 604, 606 can indicate the number or a range of consecutive critical SDUs following the current critical video PDCP SDU and belonging to the same frame.

[0081] In one example, the values of R1 -R2 bits 604-606, for example can be as follows: 00: no critical SDU; 01 : 1 critical SDU; 10: 2 critical SDUs; and 1 1 : more than 2 critical SDUs. Based on the example video bearer queue 224 of FIG. 4, SDU0 can be designated as R0 = 0 and R1 -R2 = 00. SDU1 can be designated with R0 = 1 and R1 -R2 = 10 to indicate there are 2 critical packets of the same frame 404 after this one. SDU2 can be designated as R0 = 1 and R1 -R2 = 01 to indicate there is one critical packet of the same frame 404 after this one. SDU3 can be designated as R0 = 1 and R1 -R2 = 00 so there is no critical packets of the same frame 404 after this one. SDU4 can be designated as R0=0 and R1 -R2 = 00 to indicate it is not a critical packet, and by default no critical packets following it on the same frame 406. Alternatively or additionally, R1 -R2 604 and 606 bits can be used as tabulated values to indicate the size of consecutive critical data following a particular SDU.

[0082] When the eNB PDCP layer or communication component 208 extracts and analyzes the PDCP header 600, for example, it can read the R bits 602-606 for the guaranteed bitrate video bearer (e.g., GBR bearer). If R0=1 , the SDU can be designated a critical SDU. This can notify the eNB UL scheduler (e.g., scheduling component 308) of the presence of a critical SDU and about the number of critical video SDUs (or about the size of critical data following this SDU) still not received. The eNB MAC layer via the scheduling component 308 can then constrain its scheduling processes to provide / communicate either larger grants or more frequent grants to the device, in which the grant size increase or the grant frequency increase step could depend on the value of R1 -R2 bits. The higher the R1 -R2 bits are, the larger the grant increase step or the grant frequency increase step can be for the UE (e.g., 100, 200 or 300).

[0083] As such, the eNB would not anticipate the need for higher UL bandwidth if the transmission of critical video SDUs is delayed by already queued non-critical SDUs. It also could assume that at least one critical SDU of a critical video frame is successfully transmitted with enough headroom or bandwidth before the death / discard by timer of the following SDUs. It may better suit the case of critical large l-frame causing the late transmission of any critical SDUs, either latest SDUs belonging to itself or queuing after it.

[0084] Lastly, if the eNB (e.g., 100, 200, or 300) does not provide large enough UL grants or not enough UL grants, the device (e.g., via the classification component 226) could determine that the critical data are at high risk. As a consequence, the

communication component 208 could further decide to skip the latest non critical data (e.g., SDU classified as non-critical) and directly send the first critical video data (e.g., critical PDCP SDU, or PDCP feedback). So when the RLC layer (e.g., via communication component 208) builds a RLC PDU, the determination component 304 can check whether the following condition is being satisfied: RTTD < predefined threshold. If this condition is met, RLC could fetch the critical SDUs and discard the remaining non critical SDUs (e.g., SDU 0 of FIG. 4).

[0085] While the methods described within this disclosure are illustrated in and described herein as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts may occur in different orders or concurrently with other acts or events apart from those illustrated or described herein. In addition, not all illustrated acts may be required to implement one or more aspects or embodiments of the description herein. Further, one or more of the acts depicted herein may be carried out in one or more separate acts or phases.

[0086] Referring to Fig. 7, illustrated is a process flow 700 for signaling mechanisms to avoid discard of critical video data in a modem or communication LTE stack protocol in accordance with various aspects or embodiments herein. The method 700 initiates at 702 with classifying (e.g., via the classification component 226) video packets (e.g., SDUs 0-4) associated with ViLTE or a ViLTE network within a video bearer queue (e.g., 224) as either a critical PDCP SDU or a non-critical PDCP SDU. In other words, the video packets can be classified as critical and non-critical within the queue. At 704, the method further comprises generating a communication comprising an indication of the critical PDCP SDU within the video bearer queue.

[0087] The method 700 can further include configuring the communication to initiate a modification of a UL bandwidth on the ViLTE network to avoid discarding video data within the video bearer queue based on an increase in a number of UL grants or an increase in a size of a UL grant. The communication can also be generated with an identification of critical video data associated with at least one of: the critical PDCP SDU or an RTCP feedback in a video bearer, by communicating the communication in a media access control (MAC) control element or in a packet data convergence protocol (PDCP) header.

[0088] The method 700 can also include generating a determination of whether the critical PDCP SDU is estimated to be discarded prior to transmission of the communication based on at least one of: a remaining time to discard of the critical PDCP SDU or an estimated transmission time of the critical PDCP SDU. In response to the determination indicating that the critical PDCP SDU is to be discarded, an additional indication can be generated in the communication that the critical PDCP SDU is estimated to be discarded prior to a transmission of the critical PDCP SDU.

[0089] Further, the method 700 can include deleting one or more non-critical PDCP SDUs in the video bearer queue in response to a determination that the critical PDCP SDU is to be discarded prior to a transmission of the communication. A further indication in the communication can indicate to the eNB for scheduling, for example that the non-critical PDCP SDU has been deleted.

[0090] These acts or process flow phases of the method 700 can also be carried on tangible computer readable media or medium comprising executable instructions that, in response to execution, cause an apparatus for video streaming over a ViLTE network of an eNB or UE comprising one or more processors configured to perform operations. [0091] Referring to FIG.8, illustrated is a process flow 800 for signaling mechanisms to avoid discard of critical video data in a modem or communication LTE stack protocol in accordance with various aspects or embodiments herein. The method 800 initiates at 802 with identifying a critical video PDCP SDU in a communication associated with video data of the ViLTE or a ViLTE network (e.g., via a classification component 226). At 804, the method includes processing one or more indications from the communication that identifies the critical video PDCP SDU (e.g., via the communication component 208). At 806, the method further includes initiating a modification of a UL bandwidth being scheduled (e.g., via the scheduling component 308) to avoid a discarding of video data based on the one or more indications.

[0092] In other embodiment, the method 800 can further include processing a MAC control element with the one or more indications to determine a presence of the critical video PDCP SDU in a video bearer queue (e.g., 224) and whether to increase at least one of: a number of UL grants or a size of a UL grant for the modification of the UL bandwidth based on the communication. The communication component 208 of an eNB (e.g., 100, 200 or 300) can further process an increase in the number of UL grants or the size of a UL grant in response to the indications of the MAC control element indicating that the critical video PDCP SDU of the video bearer queue is estimated to be discarded based on a discard timer.

[0093] The scheduling component 308 can further operate to switch between a modified UL bandwidth via an increase in a number of UL grants or via a size of a UL grant, and a regular UL bandwidth that is smaller than the modified UL bandwidth.

[0094] Operations of the eNB or UE by one or more components described herein can further include determining a number of consecutive critical packet data convergence protocol (PDCP) SDUs that follow the critical video PDCP SDU from the communication, and allocating one or more UL grants based on the number of consecutive critical PDCP SDUs, and whether a non-critical video PDCP SDU has been deleted in a video bearer queue.

[0095] As used herein, the term "circuitry" may refer to, be part of, or include

an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor

(shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some

embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[0096] As it employed in the subject specification, the term "processor" can refer to substantially any computing processing unit or device including, but not limited to including, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit, a digital signal processor, a field programmable gate array, a programmable logic controller, a complex programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any

combination thereof designed to perform the functions and/or processes described herein. Processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of mobile devices. A processor may also be implemented as a combination of computing processing units.

[0097] In the subject specification, terms such as "store," "data store," data storage," "database," and substantially any other information storage component relevant to operation and functionality of a component and/or process, refer to "memory components," or entities embodied in a "memory," or components including the memory. It is noted that the memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory.

[0098] By way of illustration, and not limitation, nonvolatile memory, for example, can be included in a memory, non-volatile memory (see below), disk storage (see below), and memory storage (see below). Further, nonvolatile memory can be included in read only memory, programmable read only memory, electrically programmable read only memory, electrically erasable programmable read only memory, or flash memory. Volatile memory can include random access memory, which acts as external cache memory. By way of illustration and not limitation, random access memory is available in many forms such as synchronous random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, enhanced synchronous dynamic random access memory, Synchlink dynamic random access memory, and direct Rambus random access memory. Additionally, the disclosed memory components of systems or methods herein are intended to include, without being limited to including, these and any other suitable types of memory.

[0099] Examples can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including instructions that, when performed by a machine cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to embodiments and examples described herein.

[00100] Example 1 is an apparatus to be employed in a user equipment (UE),

comprising: one or more processors configured to execute one or more executable components comprising: a classification component configured to classify, from among video packets to be transmitted over a long term evolution (LTE) network within a video bearer queue, a video packet as a critical packet data convergence protocol (PDCP) service data unit (SDU) and another video packet as a non-critical PDCP SDU; and a communication component configured to generate a communication comprising an indication that identifies the video packet as the critical PDCP SDU, and initiate a

modification of an uplink (UL) bandwidth to avoid discarding video data of the video packets based on the communication.

[00101] Example 2 includes the subject matter of Example 1 , wherein the executable components further comprise a partition component configured to partition the video bearer queue between the non-critical PDCP SDU and the critical PDCP SDU by tagging at least one of: a real-time transport protocol (RTP) packet of a reference video frame (e.g., an I- frame), or a real-time control transport protocol (RTCP) feedback.

[00102] Example 3 includes the subject matter of any of Examples 1 -2, including or omitting any elements, wherein the indication is configured to indicate one or more critical data of the video bearer queue comprising at least one of: a PDCP SDU that carries a realtime transport protocol (RTP) packet of a reference video frame (e.g., an l-frame), or carries an RTCP feedback report.

[00103] Example 4 includes the subject matter of any of Examples 1 -3, including or omitting any elements, wherein the communication component is further configured to generate the communication with a media access control (MAC) control element

comprising at least one bit indicating a presence of the critical PDCP SDU in the video bearer queue, and at least one other bit indicating an estimation that the critical PDCP SDU is to be discarded based on UL grants.

[00104] Example 5 includes the subject matter of any of Examples 1 -4, including or omitting any elements, wherein the communication component is further configured to generate the indication to initiate an increase in a number of UL grants or a size of UL grants received via the LTE network, and further communicate an identification of critical video data associated with at least one of: the critical PDCP SDU or an RTCP feedback in a video bearer queue, by generating the communication of the identification with a media access control (MAC) control element or in a PDCP header.

[00105] Example 6 includes the subject matter of any of Examples 1 -5, including or omitting any elements, wherein the executable components further comprise: a

determination component configured to generate a determination of whether the critical PDCP SDU is estimated to be discarded prior to being transmitted based on at least one of: a remaining time to discard of the critical PDCP SDU or an estimated transmission time of the critical PDCP SDU; wherein, in response to the determination, the communication component is further configured to generate the communication with an additional indication that the critical PDCP SDU is estimated to be discarded prior to the transmission.

[00106] Example 7 includes the subject matter of any of Examples 1 -6, including or omitting any elements, wherein the communication component is further configured to generate the communication with a media access control (MAC) control element

comprising the indication and an additional indication of whether to modify at least one of: a number of UL grants or a size of UL grants for the modification of the uplink (UL) bandwidth to avoid discarding the video data of the critical PDCP SDU.

[00107] Example 8 includes the subject matter of any of Examples 1 -7, including or omitting any elements, wherein the executable components further comprise: [00108] a determination component configured to determine whether the non-critical PDCP SDU in the video bearer queue will be transmitted prior to a transmission of the indication of the critical PDCP SDU; and a discarding component configured to delete the non-critical PDCP SDU in response to a determination that the critical PDCP SDU is to be discarded prior to a transmission of the communication; wherein the communication component is further configured to communicate or generate the communication with a further indication that the non-critical PDCP SDU has been deleted.

[00109] Example 9 includes the subject matter of any of Examples 1 -8, including or omitting any elements, wherein the communication component is further configured to generate the communication with a PDCP packet comprising the indication by embedding within a PDCP header one or more bits that indicate that the video packet is the critical PDCP SDU and a number of consecutive critical PDCP SDUs in the video bearer queue that follow the critical PDCP SDU in the video bearer queue.

[00110] Example 10 is an apparatus to be employed in an evolved NodeB (eNB), comprising one or more processors configured to execute one or more executable components comprising: a classification component configured to identify a critical video packet data convergence protocol (PDCP) service data unit (SDU) in a video bearer queue of a long term evolution (LTE) network; and a communication component configured to process one or more communications comprising one or more indications that identify the critical video PDCP SDU and initiate a modification of an uplink (UL) bandwidth to avoid a discarding of video data based on the one or more communications.

[00111] Example 1 1 includes the subject matter of Example 10, wherein the

communication component is further configured to process the one or more

communications including a media access control (MAC) control element with the one or more indications of the critical video PDCP SDU and one or more other indications of whether to increase at least one of: a number of UL grants or a size of a UL grant for the modification of the UL bandwidth to avoid the discarding of the video data.

[00112] Example 12 includes the subject matter of any of Examples 10-1 1 , including or omitting any elements, wherein the communication component is further configured to process an increase in the number of UL grants or the size of the UL grant in response to the one or more other indications of the MAC control element indicating that the critical video PDCP SDU of the video bearer queue is estimated to be discarded based on a SDU discard timer.

[00113] Example 13 includes the subject matter of any of Examples 10-12, including or omitting any elements, wherein the one or more indications of the critical video PDCP SDU further identify a criticality of one or more of: a real-time transport protocol (RTP) packet of a reference video frame (e.g., an l-frame) of the video data, or a real-time control transport protocol (RTCP) feedback report, in the video bearer queue of the LTE network.

[00114] Example 14 includes the subject matter of any of Examples 10-13, including or omitting any elements, wherein the one or more executable components further comprise: a scheduling component configured to schedule UL grants to a user equipment (UE) communicatively coupled to the LTE network by switching between a modified UL bandwidth via an increase in a number of UL grants or via a size of UL grants, and a regular UL bandwidth that is smaller than the modified UL bandwidth.

[00115] Example 15 includes the subject matter of any of Examples 10-14, including or omitting any elements, wherein the classification component is further configured to determine a number of consecutive critical PDCP SDUs that follow the critical video PDCP SDU from the one or more communications, and wherein the apparatus further comprises:

[00116] a scheduling component configured to allocate one or more UL grants based on the number of consecutive critical PDCP SDUs.

[00117] Example 16 includes the subject matter of any of Examples 10-15, including or omitting any elements,, wherein the classification component is further configured to extract a PDCP header from a PDCP SDU of the one or more communications, and determine whether the critical video PDCP SDU is present in the video bearer queue and a number of critical PDCP SDUs on a same video frame as the critical video PDCP SDU based on the PDCP header.

[00118] Example 17 includes the subject matter of any of Examples 10-16, including or omitting any elements, wherein the critical video PDCP SDU is based on one or more of: a real-time transport protocol (RTP) packet of a reference video frame (e.g., an l-frame) of the video data, or a real-time control transport protocol (RTCP) feedback report.

[00119] Example 18 includes the subject matter of any of Examples 10-17, including or omitting any elements, wherein the classification component is further configured to determine, based on the one or more communications, that a non-critical video PDCP SDU has been deleted in the video bearer queue.

[00120] Example 19 includes the subject matter of any of Examples 10-18, including or omitting any elements, wherein the one or more indications comprise at least three reserved bits, and wherein at least one bit of the at least three reserved bits indicates a presence of the critical video PDCP SDU in the video bearer queue, and at least two bits of the at least three reserved bits indicate a number of critical PDCP SDUs in the video bearer queue that follow the critical video PDCP SDU, or wherein the one or more indications are included in a media access control (MAC) control element comprising at least one bit indicating the presence of the critical PDCP SDU in the video bearer queue, and at least one other bit indicating an estimation that the critical PDCP SDU is to be discarded before being transmitted based on received UL grants.

[00121] Example 20 is a computer readable media comprising executable instructions that, in response to execution, cause an apparatus for video streaming over a video over long term evolution network (ViLTE) of a user equipment (UE) comprising one or more processors configured to perform operations comprising: classifying video packets, associated with the ViLTE network, within a video bearer queue as either a critical packet data convergence protocol (PDCP) service data unit (SDU) or a non-critical PDCP SDU; and generating a communication comprising an indication of the critical PDCP SDU within the video bearer queue.

[00122] Example 21 includes the subject matter of Example 20, wherein the operations further comprise: configuring the communication to initiate a modification of an uplink (UL) bandwidth on the ViLTE network to avoid discarding video data within the video bearer queue based on an increase in a number of UL grants or an increase in a size of a UL grant.

[00123] Example 22 includes the subject matter of any of Examples 20-21 , including or omitting any elements, wherein the operations further comprise: communicating an identification of critical video data associated with at least one of: the critical PDCP SDU or an RTCP feedback in a video bearer, by communicating the communication in a media access control (MAC) control element or in a packet data convergence protocol (PDCP) header. [00124] Example 23 includes the subject matter of any of Examples 20-22, including or omitting any elements, wherein the operations further comprise: generating a determination of whether the critical PDCP SDU is estimated to be discarded prior to transmission of the communication based on at least one of: a remaining time to discard of the critical PDCP SDU or an estimated transmission time of the critical PDCP SDU; and in response to the determination indicating that the critical PDCP SDU is to be discarded, generating an additional indication that the critical PDCP SDU is estimated to be discarded prior to a transmission of the critical PDCP SDU.

[00125] Example 24 includes the subject matter of any of Examples 20-23, including or omitting any elements, wherein the operations further comprise: deleting the non-critical PDCP SDU in the video bearer queue in response to a determination that the critical PDCP SDU is to be discarded prior to a transmission of the communication; and generating a further indication in the communication that the non-critical PDCP SDU has been deleted.

[00126] Example 25 includes the subject matter of any of Examples 20-24, including or omitting any elements, wherein the operations further comprise: generating the

communication with a PDCP packet comprising the indication by embedding within a PDCP header one or more bits that indicate that a video packet is the critical PDCP SDU and a number of consecutive critical PDCP SDUs within the same video frame as the critical SDU.

[00127] Example 26 is a computer readable media comprising executable instructions that, in response to execution, cause an apparatus for video streaming over a video over long term evolution network (ViLTE) of an evolved NodeB (eNB) comprising one or more processors configured to perform operations comprising: identifying a critical video packet data convergence protocol (PDCP) service data unit (SDU) in a communication associated with video data of the ViLTE network; processing a plurality of indications from the communication that identifies the critical video PDCP SDU; and initiating a modification of an uplink (UL) bandwidth being scheduled to avoid a discarding of video data based on the plurality of indications.

[00128] Example 27 includes the subject matter of Example 26, wherein the operations further comprise: processing a media access control (MAC) control element with the plurality of indications to determine a presence of the critical video PDCP SDU in a video bearer queue and whether to increase at least one of: a number of UL grants or a size of a UL grant for the modification of the UL bandwidth based on the communication.

[00129] Example 28 includes the subject matter of any of Examples 26-27, including or omitting any elements, wherein the operations further comprise: processing an increase in the number of UL grants or the size of a UL grant in response to the plurality of indications of the MAC control element indicating that the critical video PDCP SDU of the video bearer queue is estimated to be discarded based on a discard timer.

[00130] Example 29 includes the subject matter of any of Examples 26-28, including or omitting any elements, wherein the operations further comprise: switching between a modified UL bandwidth via an increase in a number of UL grants or via a size of a UL grant, and a regular UL bandwidth that is smaller than the modified UL bandwidth.

[00131] Example 30 includes the subject matter of any of Examples 26-29, including or omitting any elements, wherein the operations further comprise: determining a number of consecutive critical packet data convergence protocol (PDCP) SDUs that follow the critical video PDCP SDU from the communication; and allocating one or more UL grants based on the number of consecutive critical PDCP SDUs, and whether a non-critical video PDCP SDU has been deleted in a video bearer queue.

[00132] Example 31 is an apparatus for video streaming over a video over long term evolution network (ViLTE) of a user equipment (UE) comprising: means for classifying video packets, associated with the ViLTE network, within a video bearer queue as either a critical packet data convergence protocol (PDCP) service data unit (SDU) or a non-critical PDCP SDU; and means for generating a communication comprising an indication of the critical PDCP SDU within the video bearer queue.

[00133] Example 32 includes the subject matter of Examples 31 , further comprising:

means for configuring the communication to initiate a modification of an uplink (UL) bandwidth on the ViLTE network to avoid discarding video data within the video bearer queue based on an increase in a number of UL grants or an increase in a size of a UL grant.

[00134] Example 33 includes the subject matter of any of Examples 31 -32, including or omitting any elements, further comprising: means for communicating an identification of critical video data associated with at least one of: the critical PDCP SDU or an RTCP feedback in a video bearer, by communicating the communication in a media access control (MAC) control element or in a packet data convergence protocol (PDCP) header.

[00135] Example 34 includes the subject matter of any of Examples 31 -33, including or omitting any elements, further comprising: means for generating a determination of whether the critical PDCP SDU is estimated to be discarded prior to transmission of the

communication based on at least one of: a remaining time to discard of the critical PDCP SDU or an estimated transmission time of the critical PDCP SDU; and means for

generating an additional indication that the critical PDCP SDU is estimated to be discarded prior to a transmission of the critical PDCP SDU in response to the determination indicating that the critical PDCP SDU is to be discarded.

[00136] Example 35 includes the subject matter of any of Examples 31 -34, including or omitting any elements, further comprising: means for deleting the non-critical PDCP SDU in the video bearer queue in response to a determination that the critical PDCP SDU is to be discarded prior to a transmission of the communication; and means for generating a further indication in the communication that the non-critical PDCP SDU has been deleted.

[00137] Example 36 includes the subject matter of any of Examples 31 -35, including or omitting any elements, further comprising: means for generating the communication with a PDCP packet comprising the indication by embedding within a PDCP header one or more bits that indicate that a video packet is the critical PDCP SDU and a number of consecutive critical PDCP SDUs within the same video frame as the critical SDU.

[00138] Example 37 is an apparatus for video streaming over a video over long term evolution network (ViLTE) of an evolved NodeB (eNB) comprising: means for identifying a critical video packet data convergence protocol (PDCP) service data unit (SDU) in a communication associated with video data of the ViLTE network; means for processing a plurality of indications from the communication that identifies the critical video PDCP SDU; and means for initiating a modification of an uplink (UL) bandwidth being scheduled to avoid a discarding of video data based on the plurality of indications.

[00139] Example 38 includes the subject matter of Example 37, further comprising:

means for processing a media access control (MAC) control element with the plurality of indications to determine a presence of the critical video PDCP SDU in a video bearer queue and whether to increase at least one of: a number of UL grants or a size of a UL grant for the modification of the UL bandwidth based on the communication.

[00140] Example 39 includes the subject matter of any of Examples 37-38, including or omitting any elements, further comprising: means for processing an increase in the number of UL grants or the size of a UL grant in response to the plurality of indications of the MAC control element indicating that the critical video PDCP SDU of the video bearer queue is estimated to be discarded based on a discard timer.

[00141] Example 40 includes the subject matter of any of Examples 37-39, including or omitting any elements, further comprising: means for switching between a modified UL bandwidth via an increase in a number of UL grants or via a size of a UL grant, and a regular UL bandwidth that is smaller than the modified UL bandwidth.

[00142] Example 41 includes the subject matter of any of Examples 37-40, including or omitting any elements, further comprising: means for determining a number of consecutive critical packet data convergence protocol (PDCP) SDUs that follow the critical video PDCP SDU from the communication; and means for allocating one or more UL grants based on the number of consecutive critical PDCP SDUs, and whether a non-critical video PDCP SDU has been deleted in a video bearer queue.

[00143] Example 42 is an apparatus to be employed in a user equipment (UE), comprising: one or more processors configured to: classify, from among video packets to be transmitted over a long term evolution (LTE) network within a video bearer queue, a video packet as a critical packet data convergence protocol (PDCP) service data unit (SDU) and another video packet as a non-critical PDCP SDU; and generate a

communication comprising an indication that identifies the video packet as the critical PDCP SDU, and initiate a modification of an uplink (UL) bandwidth to avoid discarding video data of the video packets based on the communication.

[00144] Example 43 is an apparatus to be employed in an evolved NodeB (eNB), comprising one or more processors configured to: identify a critical video packet data convergence protocol (PDCP) service data unit (SDU) in a video bearer queue of a long term evolution (LTE) network; and process one or more communications comprising one or more indications that identify the critical video PDCP SDU and initiate a modification of an uplink (UL) bandwidth to avoid a discarding of video data based on the one or more communications. [00145] It is to be understood that aspects described herein can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media or a computer readable storage device can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other tangible and/or non- transitory medium, that can be used to carry or store desired information or executable instructions. Also, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and 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 medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[00146] Various illustrative logics, logical blocks, modules, and circuits described in connection with aspects disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform functions described herein. A general-purpose processor can be a microprocessor, but, in the alternative, processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a

microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor can comprise one or more modules operable to perform one or more of the s and/or actions described herein.

[00147] For a software implementation, techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform functions described herein. Software codes can be stored in memory units and executed by processors.

Memory unit can be implemented within processor or external to processor, in which case memory unit can be communicatively coupled to processor through various means as is known in the art. Further, at least one processor can include one or more modules operable to perform functions described herein.

[00148] Techniques described herein can be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. A CDMA system can implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA1800, etc. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Further, CDMA1800 covers IS-1800, IS-95 and IS-856 standards. A TDMA system can implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system can implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.1 1 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.18, Flash- OFDM□, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on downlink and SC-FDMA on uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). Additionally, CDMA1800 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). Further, such wireless communication systems can additionally include peer-to-peer {e.g., mobile-to- mobile) ad hoc network systems often using unpaired unlicensed spectrums, 802. xx wireless LAN, BLUETOOTH and any other short- or long- range, wireless communication techniques.

[00149] Single carrier frequency division multiple access (SC-FDMA), which utilizes single carrier modulation and frequency domain equalization is a technique that can be utilized with the disclosed aspects. SC-FDMA has similar performance and essentially a similar overall complexity as those of OFDMA system. SC-FDMA signal has lower peak-to- average power ratio (PAPR) because of its inherent single carrier structure. SC-FDMA can be utilized in uplink communications where lower PAPR can benefit a mobile terminal in terms of transmit power efficiency.

[00150] Moreover, various aspects or features described herein can be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include but are not limited to magnetic storage devices {e.g., hard disk, floppy disk, magnetic strips, etc.), optical disks {e.g., compact disk (CD), digital versatile disk (DVD), etc.), smart cards, and flash memory devices {e.g., EPROM, card, stick, key drive, etc.). Additionally, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data. Additionally, a computer program product can include a computer readable medium having one or more instructions or codes operable to cause a computer to perform functions described herein.

[00151] Communications media embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term "modulated data signal" or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[00152] Further, the actions of a method or algorithm described in connection with aspects disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or a combination thereof. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium can be coupled to processor, such that processor can read information from, and write information to, storage medium. In the alternative, storage medium can be integral to processor. Further, in some aspects, processor and storage medium can reside in an ASIC. Additionally, ASIC can reside in a user terminal. In the alternative, processor and storage medium can reside as discrete components in a user terminal. Additionally, in some aspects, the s and/or actions of a method or algorithm can reside as one or any combination or set of codes and/or instructions on a machine- readable medium and/or computer readable medium, which can be incorporated into a computer program product.

[00153] The above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.

[00154] In this regard, while the disclosed subject matter has been described in connection with various embodiments and corresponding Figures, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[00155] In particular regard to the various functions performed by the above described components (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a "means") used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component {e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.