Patent Application
20140226476
The present disclosure is directed to communications and, more particularly, to packet communications and related methods, devices, and computer program products.
In a typical cellular radio system, wireless terminals (also referred to as user equipment unit nodes, UEs, and/or mobile stations) communicate via a radio access network (RAN) with one or more core networks. The RAN covers a geographical area which is divided into cell areas, with each cell area being served by a radio base station (also referred to as a RAN node, a “NodeB”, and/or enhanced NodeB “eNodeB”). A cell area is a geographical area where radio coverage is provided by the base station equipment at a base station site. The base stations communicate through radio communication channels with wireless terminals within range of the base stations.
With mobile networks evolving from circuit-switched (CS) only networks (e.g., according to GSM or Global System for Mobile Communications technologies), to hybrid circuit-switched and packet-switched (PS) networks (e.g., according to 3G/HSPA or Third Generation High-Speed Downlink Packet Access technologies) to packet-switched (PS) only networks (e.g., according to LTE or Long Term Evolution technologies), the delivery of telephony services over mobile networks is changing. Packet switched telephony services over LTE, for example, may use Voice over Internet Protocol (VoIP) for radiotelephone voice conversations. Maintenance of high quality voice communications in such a VoIP network may be desirable because users continue to expect quality similar to that of circuit-switched networks. Accordingly, VoIP quality monitoring of speech reproduction at wireless terminals may be desired so that proper action can be taken in the event that VoIP quality at the wireless terminal is not satisfactory.
In a VoIP packet-switched radiotelephone conversation, for example, a microphone at the transmitting device converts sound (e.g., voice) into an analog electrical signal, and an analog-to-digital converter converts the analog electrical signal into a digital signal. Segments of the digital signal are then separated into Internet Protocol (IP) data packets that are transmitted separately over the network (e.g., an LTE radiotelephone network) between the transmitting device and the receiving device (e.g., between two radiotelephone devices). Each IP data packet is transmitted separately, and different IP data packets may follow different paths between the transmitting and receiving devices. Accordingly, different IP data packets of the same VoIP signal may be subject to different delays through the network, so that the IP data packets are not received in a steady stream at the receiving device. Such differences in arrival times of IP data packets at the receiving device may be referred to as “jitter.”
In a packet-switched network, a receiving device may include a jitter buffer (also referred to as a de jitter buffer) that is used to counter jitter by providing a buffer or queue of received IP data packets so that a continuous (or more nearly continuous) play-out of received audio (or video) may be provided. Such a jitter buffer may thus compensate for variations of transmission delay through the network for different IP data packets received at the receiving device, but a jitter buffer may further delay play-out of each IP packet/frame at the receiving device, introducing an additional delay for end-to-end flow (also referred to as mouth-to-ear delay).
If a jitter buffer delays all IP data packets long enough to allow an IP data packet with a highest expected transport delay to arrive before its scheduled play-out time, the receiving device may properly reconstruct the intended analog signal. Applying a jitter buffer delay to accommodate a highest expected transport delay, however, may cause an undesirably long mouth-to-ear delay for a radiotelephone conversation. On the other hand, if a jitter buffer delay is too short (or non-existent), variations in network delay may cause some IP data packets to arrive too late for their respective scheduled play-out times resulting in interruptions of the reproduced speech.
Accordingly, a VoIP jitter buffer algorithm may be designed so that data packet play-out delay is reduced, while still allowing most IP data packets to arrive in time for their respective scheduled play-outs. IP data packets arriving too late for their scheduled play-out are referred to as late losses. Storing a greater number of IP data packets in a jitter buffer (i.e., increasing a size of the jitter buffer) may thus reduce a likelihood of late-losses, at the expense of increasing an overall mouth-to-ear delay. Conversely, storing a lesser number of IP data packets in a jitter buffer (i.e., reducing a size of the jitter buffer) may reduce an overall mouth-to-ear delay at the expense of increasing a likelihood of late-losses.
A size of a jitter buffer may define a number of IP data packets (also referred to as frames) that may be queued in the jitter buffer. A static jitter buffer may have a fixed size, while an adaptive jitter buffer may have a capability to dynamically adjust its size to balance the delay/late-loss tradeoff. An adaptive jitter buffer may continuously adjust its size according to measurements of jitter for previous IP data packets in the flow. An adaptive jitter buffer uses measurements of IP data packet arrival times and current jitter buffer status to determine a desired jitter buffer size. When increased jitter is detected, for example, jitter buffer size may be increased to reduce a likelihood of late-losses, and when reduced jitter is detected, jitter buffer size may be reduced to reduce voice-to-mouth delay. The reduction/increase of buffer size may be accomplished by compressing or expanding some speech data packets/frames during play-out (referred to as time scaling) at the expense of further impairments to the quality of the reproduced speech. Third Generation Partnership Project (3GPP) LTE standards define some minimum requirements for a jitter buffer algorithm in a wireless terminal for a Multimedia Telephony Service for IP Multimedia System (MTSI). An exact algorithm used by a wireless terminal, however, may not necessarily be defined by 3GPP LTE.
An end-user quality of a VoIP media flow (e.g., voice and/or video) may depend on multiple factors including packet/frame error rate, impairments due to time scaling, impairments due to end-to-end delay, impairments due to late-losses, etc. To determine a quality of a VoIP flow, packet/frame error rate, time scaling, late-losses, and/or end-to-end delay may be measured and used to generate a measure of quality according to a quality model. Moreover, such a measure of quality may be generated at the end user device (e.g., at the receiving wireless terminal) where error rates, time scaling, late-losses, and end-to-end delays may be most accurately determined.
Standardization of terminal reporting of VoIP quality parameters is discussed, for example, by Bernstein et al., in “DSLHome Provisioning Parameters for VoIP CPE,” DSL Forum, TR-104, September 2005. If no terminal measurements are available, network reports may be used to estimate VoIP quality. An eNB, for example, may provide reports based on numbers of packets lost and/or based on numbers of packets delivered later than a specified packet delay budget (i.e., a period of time allowed from the time that a packet arrives at the eNB until it is transmitted to the wireless terminal).
VoIP quality estimation based on terminal reporting may provide more accurate results, but terminal reporting is not a mandatory feature according to the LTE standard, and not all wireless terminals can be expected to report such measurements in the near future. Accordingly, network operators may have to rely on network measurements to estimate VoIP media quality. Measurements currently available at the network (e.g., packet loss, packet delays through the RAN, etc.) may not easily translate to an accurate VoIP quality score (such as a Mean Opinion Score or MOS).
By way of example, if the RAN delay budget (i.e., the time budgeted for data packet transmission through the RAN) is 80 ms and if all data packets are delayed by 100 ms, then all the data packets are delayed 20 ms over the budgeted delay, and 0% of the data packets will be delivered within the delay budget. This situation, however, is not likely to be a problem for VoIP voice reproduction at the receiving wireless terminal because the delay is constant. In another situation, if most packets are delivered with a 30 ms RAN delay but suddenly some packets are delivered with an 80 ms RAN delay, all data packets may be delivered within the delay budget, but the relatively high jitter may cause jitter buffer under-run at the wireless terminal so that the relatively delayed data packet(s) may be lost even though received within the time budget. Monitoring of data packet delay vs. budgeted delay may thus: incorrectly indicate low VoIP quality when all data packets are consistently delayed beyond the delay budget; and incorrectly indicate high VoIP quality when data packets delays are significantly variable but within the delay budget. Accordingly, packet delay monitoring at the network may provide unreliable estimates of VoIP quality.
It is therefore an object to address at least some of the above mentioned disadvantages and/or to improve performance in a communication system supporting VoIP communications.
According to some embodiments, packet communications may be provided over a wireless channel between a radio network node and a wireless terminal, and the wireless terminal may include a jitter buffer configured to reduce jitter resulting from different delays of data packets received at the wireless terminal. Operation of the jitter buffer for the wireless terminal may be emulated responsive to data packet transmissions from the radio network node to the wireless terminal. Responsive to emulating operation of the jitter buffer for the wireless terminal, a parameter of emulated operation of the jitter buffer may be provided including at least one of an emulated late packet loss occurrence, an emulated time scaling occurrence, an emulated jitter buffer fill level, and/or an emulated jitter buffer fill level threshold.
By emulating operation of the wireless terminal jitter buffer at a radio network node (such as a radio base station supporting the radio link with the wireless terminal), the radio access network may track a quality of communications received/reproduced at the wireless terminal without requiring wireless terminal reporting of such jitter buffer performance parameters. Moreover, network based jitter buffer emulation may allow tracking of wireless terminal jitter buffer performance without requiring increased radio channel traffic and/or wireless terminal operational overhead. Such information may be used at the radio access network to track performance/quality of particular communications with wireless terminals, to track aggregate radio access network performance, to modify data packet transmission scheduling to reduce jitter buffer under-run and/or time scaling at the wireless terminal, to modify network operations to improve aggregate network operations, to allocate network resources, etc.
According to other embodiments, a radio network node in a radio access network may include a transceiver and a processor. The transceiver may be configured to provide communications over a wireless channel between the radio network node and a wireless terminal with the wireless terminal including a jitter buffer configured to reduce jitter resulting from different delays of data packets received at the wireless terminal. The processor is coupled to the transceiver with the processor being configured to emulate operation of the jitter buffer for the wireless terminal responsive to data packet transmissions from the radio network node through the transceiver to the wireless terminal. The processor may be further configured to provide a parameter of emulated operation of the jitter buffer including at least one of an emulated late packet loss occurrence, an emulated time scaling occurrence, an emulated jitter buffer fill level, and/or an emulated jitter buffer fill level threshold responsive to emulating operation of the jitter buffer for the wireless terminal.
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiment(s) of the invention. In the drawings:
The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.
For purposes of illustration and explanation only, these and other embodiments of the present invention are described herein in the context of operating in a Radio Access Network (RAN) that communicates over radio communication channels with wireless terminals (also referred to as UEs). It will be understood, however, that the present invention is not limited to such embodiments and may be embodied generally in any type of communication network. As used herein, a wireless terminal or UE can include any device that receives data from a communication network, and may include, but is not limited to, a mobile telephone (“cellular” telephone), laptop/portable computer, pocket computer, hand-held computer, and/or desktop computer.
In some embodiments of a RAN, several base stations can be connected (e.g., by landlines or radio channels) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
The Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system, which evolved from the Global System for Mobile Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) technology. UTRAN, short for UMTS Terrestrial Radio Access Network, is a collective term for the Node B's and Radio Network Controllers which make up the UMTS radio access network. Thus, UTRAN is essentially a radio access network using wideband code division multiple access for UEs.
The Third Generation Partnership Project (3GPP) has undertaken to further evolve the UTRAN and GSM based radio access network technologies. In this regard, specifications for the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) are ongoing within 3GPP. The Evolved Universal Terrestrial Radio Access Network (E-UTRAN) comprises the Long Term Evolution (LTE) and System Architecture Evolution (SAE).
Note that although terminology from 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) is used in this disclosure to exemplify embodiments of the invention, this should not be seen as limiting the scope of the invention to only these systems. Other wireless systems, including WCDMA (Wideband Code Division Multiple Access), WiMax (Worldwide Interoperability for Microwave Access), UMB (Ultra Mobile Broadband), HSDPA (High-Speed Downlink Packet Access), GSM (Global System for Mobile Communications), etc., may also benefit from exploiting embodiments of the present invention disclosed herein.
Also note that terminology such as base station (also referred to as eNodeB or Evolved Node B) and wireless terminal (also referred to as UE or User Equipment) should be considering non-limiting and does not imply a certain hierarchical relation between the two. In general a base station (e.g., an “eNodeB”) and a wireless terminal (e.g., a “UE”) may be considered as examples of respective different communications devices that communicate with each other over a wireless radio channel. While embodiments discussed herein may focus on wireless transmissions in a downlink from an eNodeB to a UE, embodiments of the invention may also be applied, for example, in the uplink.
More particularly, base station 100 may be configured to support VoIP radiotelephone communications between wireless terminal 200 and another communications device. For example, the other communications device may be another wireless terminal in a coverage area of base station 100 that is wirelessly coupled to base station 100, the other communications device may be coupled to base station 100 through another base station and an X2 interface between the two base stations, the other communications device may be coupled to base station 100 through core network 70, etc. IP Data packets may thus be transmitted from the other communications device to wireless device 200 through base station 100, through another base station and base station 100, through core network 70 and base station 100, etc. Moreover, different IP data packets of the same VoIP communication may be received from the other communications device at wireless terminal 200 with different delays resulting in jitter.
Processor 201 of wireless terminal 200 may thus include jitter buffer 303 as discussed above to provide improve a quality of speech reproduction. Elements of processor 201 that may support adaptive jitter buffering (including jitter buffer 303 and related control elements) are illustrated in
Jitter buffer 303 unpacks incoming IP data packets (e.g., Real-Time Protocol or RTP payloads) from transceiver 209 and stores the received speech packets/frames. Moreover, the status (e.g., size, fill level, minimum/maximum fill level threshold, etc.) of jitter buffer 303 may be provided as input to adaptation control processor 305. In addition, jitter buffer 303 may be linked to speech decoder 307 to provide speech packets/frames for decoding when requested for decoding. Network analyzer 301 may monitor the stream of incoming IP data packets from transceiver 209 and generate reception statistics (e.g., jitter, packet late-losses, etc.) responsive to the stream of incoming data packets. As shown, the reception statistics may be provided to adaptation control processor 305 as input information used to control jitter buffer 303.
Adaptation control processor 305 may make decisions regarding buffering delay adjustments and/or playback delay responsive to jitter buffer status (e.g., average buffering delay, buffer fill level, buffer size, etc.) from jitter buffer 303 and reception statistics from network analyzer 301. Moreover, external control input can be used, for example, to enable inter-media synchronization or other external scaling requests. Adaptation control processor 305 may use different adaptation strategies such as providing fixed jitter buffer (without adaptation and time scaling), providing simple adaptation during comfort noise periods, and/or providing buffer adaptation also during active speech.
Speech decoder 307 may be implemented as an AMR (Adaptive Multi-Rate) or AMR-WB (Adaptive Multi-Rate WideBand) speech decoder. Moreover, speech decoder 307 may include error concealment and/or bad packet/frame handling functionality, and/or speech decoder 307 may be used with or without adaptation processor 309.
Adaptation processor 309 may shorten or extend an output signal length to provide time scaling according to scaling requests from adaptation control processor 305 to facilitate a relatively transparent adjustment of jitter buffer delay. Adaptation processor 309 may perform time scaling using packet/frame based or sample based time scaling on the output of speech decoder 307 during comfort noise periods only or during active speech and comfort noise. Adaptation control processor 305 may have a mechanism to limit a maximum scaling ratio. Providing a scaling window in which the targeted time scale modifications are performed may allow flexibility in allocation of a scaling request over several packets/frames.
To monitor a quality of VoIP speech reproduced at wireless terminal 200, base station processor 101 may include jitter buffer emulator 403 as shown in
As discussed in greater detail below, jitter buffer emulator 403 may initiate jitter buffer emulation (also referred to as providing a jitter buffer emulator) for each VoIP communication processed through base station 100. Stated in other words, jitter buffer emulator 403 may initiate a different jitter buffer emulator for each wireless terminal 200 receiving VoIP speech data packets from base station 100. Jitter buffer emulator 403 may thus provide a mirror of jitter buffer 303 of wireless terminal 200, and JBE 403 may thus provide emulation responsive to each VoIP data packet transmitted from base station 100 to wireless terminal 200. For example, JBE 403 may emulate/measure a packet late-loss rate as well as time scaling occurrences experienced at wireless terminal 200, and these measures may be used to provide reliable estimates of quality of VoIP speech reproduced at wireless terminal 200, and/or to schedule/reschedule subsequent VoIP data packet transmission to wireless terminal 200.
To emulate/monitor operation of jitter buffer 303 at wireless terminal 200, jitter buffer emulator 403 may be implemented at radio base station 100, which is the network node closest to wireless terminal 200. By providing jitter buffer emulator 403 at base station 100 with which wireless terminal 200 is communicating, jitter buffer emulation may be based on the most accurate and timely information that is available to RAN 70 (e.g., based on transmission of VoIP data packets from base station 100 to wireless terminal 200 and/or receipt of delivery notifications such as ACK/NACK messages from wireless terminal 200). While jitter buffer emulator 403 and/or functionality thereof may be provided in base station processor 101 according to some embodiments, jitter buffer emulator 403 and/or functionality thereof may be provided in base station 100 outside of processor 101, in RAN 70 outside of base station 100, etc.
As shown in
In a 3GPP LTE radio access network, for example, RAB handling processor 405 can determine when a radio link (e.g., an Evolved Radio Access Bearer or E-RAB) for wireless terminal 200 should be initiated/terminated. RAB handling processor 405, for example, may initiate a radio link with wireless terminal 200 responsive to a request from wireless terminal 200 to establish a new communication with another communication device, responsive to a request from another communication device to establish a new communication with wireless terminal 200 (currently in a service area of base station 100), responsive to a request from another base station (referred to as a source base station) to hand-off an ongoing communication with wireless terminal 200 to base station 100, etc. RAB handling processor 405 may terminate an ongoing communication between wireless terminal 200 and another communication device responsive to a termination request from wireless terminal 200, responsive to termination request from the other communication device, responsive to handing-off the ongoing communication to another base station (referred to as a destination base station), etc.
Responsive to initiating a communication with wireless terminal 200, RAB handling processor 405 may transmit a RAB setup notice to VoIP management processor 401, and a setup request (from wireless terminal 200, from the other communication device, from the other base station, etc.) may include a Quality of Service Class Identifier (QCI), that can be used to identify VoIP data communications. Upon receipt of a RAB setup notice and a QCI indicating that the communication is a VoIP communication, VoIP management processor 401 may determine whether to monitor a quality of this VoIP communication. Such a determination may be based on a service/subscription level of wireless terminal 200 (e.g., whether wireless terminal 200 has a service/subscription agreement guaranteeing a higher level of service that requires VoIP quality monitoring), a random decision (e.g., based on statistical sampling) to provide system level statistical monitoring based on a subset of all users, etc. If VoIP quality management processor 401 determines that the VoIP communication with wireless terminal 200 should be monitored, jitter buffer emulation at JBE 403 is initiated for wireless terminal 200 for the new VoIP communication.
If the communication with wireless terminal 200 is a new communication, jitter buffer emulation is initiated for wireless terminal 200 using an initial status based on a zero jitter buffer fill level. If the communication with wireless terminal 200 is a hand-off of an existing communication from another (source) base station, jitter buffer emulation is initiated based on a status (e.g., jitter buffer fill level, size, maximum/minimum fill level threshold, etc.) of jitter buffer emulation received from the other (source) base station. Stated in other words, jitter buffer emulation is initiated at base station 100 in a state corresponding to that of jitter buffer emulation from the source base station that originated the hand-off. VoIP quality management processor 401 may also configure how the jitter buffer emulation should collect performance parameters for the communication (e.g., with what time granularity statistics should be collected/reported).
JBE 403 may report performance information to VoIP quality management processor 401 over the course of the communication, and VoIP quality management processor 401 may forward this performance information (or information relating thereto) to another network node/element for generation of an objective media quality model for the VoIP communication with wireless terminal 200. Information estimating a quality/performance of the communication at wireless terminal 200 may be used, for example, to monitor performance of RAN 60, to modify operation of RAN 60, to schedule/reschedule data packet flows through RAN 60 and/or base station 100, to schedule/reschedule data packet transmissions of the VoIP communication from base station 100 to wireless terminal 200, etc.
Upon termination of the VoIP communication between wireless terminal 200 and base station 100, RAB handling processor 405 may transmit a RAB release message to VoIP quality management processor 401, and VoIP quality management processor 401 may terminate jitter buffer emulation for wireless terminal 200 at JBE 403. If the RAB release message is generated responsive to a hand-off of the ongoing communication with wireless terminal 200 to another (destination) base station, VoIP quality management processor 401 may collect current status information (e.g., jitter buffer size, fill level, minimum/maximum fill level threshold, etc.) of jitter buffer emulation for wireless terminal 200 and forward this status information to the other destination base station before terminating jitter buffer emulation.
JBE 403 may thus model/emulate jitter buffer 303 of wireless terminal 200 in real time. Because operation of wireless terminal jitter buffer 303 may be primarily responsive to reception times that VoIP data packets are received at wireless terminal 200, base station JBE 403 may be primarily responsive to times that the VoIP data packets are transmitted from base station 100 to wireless terminal 200. Accordingly, scheduling processor 407 (controlling operation of scheduling buffer 409) may provide packet delivery information (e.g., including data packet transmission times) and/or packet acknowledge/negative-acknowledge (or ACK/NACK) messages (e.g., Hybrid Automatic Repeat Request or HARQ ACK/NACK messages received from wireless terminal 200) to jitter buffer emulator JBE 403. Jitter buffer emulator 403 may this be informed when each data packet is transmitted to wireless terminal 200 (based on the data packet transmission times), and for each data packet, whether the data packet is received by the wireless terminal (e.g., as indicated by an ACK message) or lost (as indicated by a NACK message).
When a data packet is successfully received at jitter buffer 303 (of wireless terminal 200), its arrival time can be used by jitter buffer 303 (and/or network analyzer 301 and/or adaptation control processor 305) to calculate a maximum buffer size needed to reach a pre-configured target late-loss rate. Moreover, wireless terminal processor 201 may initiate transmission of an ACK message to base station 100 to acknowledge successful receipt of the packet. When the ACK message is received at base station 100 (from wireless terminal 200) indicating that a data packet was successfully received at wireless terminal 200, jitter buffer emulator 403 can use the transmission time for the data packet (when the data packet was transmitted from base station 100) to update the status information (e.g., emulated buffer size, fill level, minimum/maximum fill level threshold, etc.) of jitter buffer emulation for wireless terminal 200. The status information and/or elements thereof can then be added to a histogram. In contrast, when a data packet is not successfully received at wireless terminal 200 (e.g., because a number of errors exceeds a threshold), wireless terminal processor 201 may initiate transmission of a NACK message to base station 100, and base station scheduling processor 407 may attempt retransmission of the data packet. Scheduling processor 407 may thus withhold packet delivery information from JBE 403 until an ACK message is received acknowledging successful receipt of the data packet at wireless terminal 200. Once an ACK message is received for a data packet, scheduling processor 407 may forward packet delivery information for the data packet to JBE 403 (including a time that the packet was transmitted from base station 100).
When a radio link is established between base station 100 and wireless terminal 200, VoIP Quality Management Processor 401 instructs JBE 403 to initiate an emulator for wireless terminal 200, and the emulator for wireless terminal 200 is initialized using information provided by VoIP Quality Management Processor 401 (e.g., a zero fill level if the radio link is for a new communication or a fill level provided by a source base station if the radio link is for a hand-off of an ongoing communication). Moreover, the JBE 403 may configure the emulator for wireless terminal 200 to generate performance parameter measurements emulating performance parameters of jitter buffer 303 at wireless terminal 200.
Each time a VoIP data packet is successfully delivered to (and received at) wireless terminal 200 (as indicated to JBE 403 by packet delivery information from scheduling processor 407 of base station processor 101), the jitter buffer emulator for wireless terminal 200 updates its status in accordance with the applicable jitter buffer characteristics (corresponding to characteristics of wireless terminal jitter buffer 303). The jitter buffer emulator for wireless terminal 200 may also estimate if any buffer adjustment may be needed based, for example, on historic jitter distribution.
The jitter buffer emulator for wireless terminal 200 may also emulate consumption of speech frames by wireless terminal speech decoder 307 (without decoding or playing out any speech). The jitter buffer emulator for wireless terminal 200 may also emulate the need for any time scaling at wireless terminal 200, and/or jitter buffer under-run resulting in packet loss at wireless terminal jitter buffer 303 and/or speech decoder 307. The jitter buffer emulator for wireless terminal 200 may save emulated performance parameters (e.g., packet loss rate, time scaling occurrences, etc.) and/or report these emulated performance parameters to VoIP Quality Management Processor 401.
JBE 403 may be configured to implement different jitter buffer emulation types (e.g., algorithms) to match a particular jitter buffer type (e.g., algorithm) of wireless terminal jitter buffer 303. For example, a number of known wireless terminal jitter buffer types may be allowed/supported, and a unique jitter buffer identifier may be used to identify each of the types. Accordingly, wireless terminal 200 may transmit its jitter buffer identifier to base station 100 when the radio link is established, and JBE 403 may use this jitter buffer identifier when initiating jitter buffer emulation for wireless terminal 200 so that jitter buffer emulation for wireless terminal 200 matches the wireless terminal jitter buffer 303. According to other embodiments, JBE 403 may implement a single jitter buffer emulation type that is used for all wireless terminals. Even though different wireless terminals may implement slightly different jitter buffers, all such different jitter buffers may be compliant with 3GPP LTE so that differences may be relatively insignificant and a same jitter buffer emulation type/algorithm may be sufficient.
As discussed above, jitter buffer emulation at base station 100 may be used to provide VoIP quality estimation for speech reproduced at wireless terminal 200. According to some embodiments, jitter buffer emulation may be used to schedule/reschedule data packet transmissions from base station 100 to wireless terminal 200 and/or to other wireless terminals in communication with base station 100. VoIP quality at wireless terminal 200, for example, may be improved by increasing the number of data packets that are received at wireless terminal 200 in time for its scheduled play-out, and this timing is dependent on the current depth/size and fill level of jitter buffer 303, none of which are constant. At base station 100, transmission of data packets from scheduling buffer 409 to wireless terminal 200 and to other wireless terminals may normally be based on the respective times that the data packets have been delayed in scheduling buffer 409. Stated in other words, scheduling buffer 409 may operate as a first-in-first-out buffer so that data packets are transmitted in the same order that they are received at scheduling buffer 409. According to some embodiments, scheduling processor 407 may alter transmission scheduling priorities/orders of data packets in scheduling buffer responsive to status of jitter buffer emulations for wireless terminals 200 in communication with base station 100.
To increase a number of data packets that arrive at wireless terminal 200 in time for scheduled play-out, scheduling processor 407 may thus consider a status of the jitter buffer emulation for wireless terminal 200 when scheduling/rescheduling data packet transmissions to wireless terminal 200. In response to the jitter buffer emulation for wireless terminal 200 detecting an approaching under-run situation (e.g., with an insufficient number of data packets in jitter buffer 303), for example, scheduling processor 407 may reschedule a next data packet(s) in scheduling buffer for more immediate transmission to wireless terminal 200. Stated in other words, a next data packet for wireless terminal 200 may be moved ahead of data packets for other wireless terminals that were received at scheduling buffer 409 ahead of the next data packet for wireless terminal 200. According to other embodiments, scheduling processor 407 may proactively take action to increase a size and/or fill level of jitter buffer 303 before handing-off an ongoing communication with wireless terminal 200 to another base station. Accordingly, a likelihood of under-run (i.e., running out of data packets) during a hand-off outage may be reduced.
According to embodiments discussed herein, a quality of reproduction of VoIP communications received at a wireless terminal may be monitored with relatively high accuracy without requiring wireless terminal reporting. By emulating wireless terminal jitter buffering at the network, performance parameter measurements may be implemented at one place for all wireless terminals communication with a base station, and a relatively accurate objective quality model may be obtained. In addition, a VoIP scheduling buffer may schedule VoIP data packet transmissions to wireless terminals more efficiently based on jitter buffer emulation to reduce the likelihood of under-run situations and to reduce impact of hand-off outages.
Embodiments of the present invention will now be discussed with respect to the flow charts of
As shown in
Responsive to a request for either type of communication, RAB Handling Processor 405 may generate a radio link (e.g., E-RAB) setup notice at block 455 and establish a radio link (E-RAB) between base station 100 and wireless terminal 200 at block 457. As discussed in greater detail below, the radio link setup notice may be provided to VoIP Quality Management Processor 401. More particularly, the radio link setup notice may include an identification of the radio link and/or wireless terminal, a Quality of Service Class Identifier (QCI) identifying a type of communication (e.g., if the communication is a real time data packet communication such as a VoIP communication), an identification of a jitter buffer emulator type used by the wireless terminal, an existing jitter buffer status (if the communication is an ongoing communication being handed-off from a source base station), etc.
At block 459 RAB Handling Processor 405 may monitor for receipt of requests to terminate an ongoing communication between a wireless terminal and base station 100. At block 461, RAB handling processor 405 may monitor for requests to hand-off an ongoing communication with a wireless terminal to another destination base station. In response to a hand-off request at block 461, RAB handling processor 405 may initiate the hand-off to the destination station at block 463. In response to either a termination request at block 459 or a hand-off request at block 461, RAB handling processor 405 may terminate the radio link between base station 100 and the wireless terminal associated with the request at block 465, and RAB handling processor 405 may generate a radio link termination notice at block 467. As discussed in greater detail below, the termination notice may be provided to VoIP quality management processor 401, and responsive to the termination notice, VoIP quality management processor 401 may terminate jitter buffer emulation at JBE 403 for the wireless terminal associated with the termination notice. If the termination notice is the result of a hand-off, VoIP quality management processor 401 may also forward a status of jitter buffer emulation (e.g., including buffer size, fill level, minimum/maximum fill level thresholds, time for consumption of a next data packet/frame, etc.) to the destination base station.
RAB handling processor 405 may thus continuously monitor for requests to support new communications at base station 100 and to terminate existing communications with base stations. Responsive to these requests, RAB handling processor 405 may provide setup and termination notices to VoIP quality management processor 401 allowing VoIP quality management processor 401 to setup/maintain/terminate jitter buffer emulations for each wireless terminal conducting VoIP communications (or other real time data packet communications) through base station 100.
As shown in
As discussed above, a scheduling priority of one or more data packets in scheduling buffer 409 that are to be transmitted to wireless terminal 200 may be changed responsive to a status of jitter buffer emulation for wireless terminal 200 and/or responsive to jitter buffer emulation for another wireless terminal or terminals communicating with base station 100. If jitter buffer emulation for wireless terminal 100 indicates that jitter buffer 303 of wireless terminal 200 may be approaching an under-run condition (e.g., that its buffer fill level is below a minimum buffer fill level threshold), scheduling processor 407 may receive jitter buffer status information from JBE 403 indicating the approaching under-run condition for wireless terminal 200. At block 477, scheduling processor 407 may thus detect a need to change a scheduling priority for a data packet or packets to be transmitted to wireless terminal 200 in response to the approaching under-run condition, and at block 479, scheduling processor may change the scheduling priority for the next data packet or packets for transmission to wireless terminal 200 by advancing the packet or packets in the queue of scheduling buffer 409 relative to packets for transmission to other wireless terminals. In contrast, if jitter buffer emulation for another wireless terminal(s) indicates an approaching under-run condition at the other wireless terminal(s), scheduling processor 407 may advance packets for the other wireless terminal(s) effectively changing scheduling priorities for data packets for wireless terminal 200 by delaying their scheduled transmissions.
At block 481, scheduling buffer 409 determines if it is time to transmit a data packet to a wireless terminal (e.g., wireless terminal 200) in accordance with current scheduling priorities, and if so, the data packet is transmitted to the appropriate wireless terminal at block 483. When transmitting a data packet to wireless terminal 200, for example, wireless terminal 200 will respond with either an ACK message indicating that the data packet was successfully received or with a NACK message indicating that the data packet was not successfully received. Responsive to receiving an ACK message from wireless terminal 200 at base station 100, scheduling processor 407 may generate a packet delivery notification (including an identification of the transmitted data packet and the transmission time) that is provided to JBE 200 to allow updating of jitter buffer emulation for wireless terminal 200. Responsive to non-receipt of an ACK message for the data packet or responsive to receipt of a NACK message for the data packet, scheduling processor may schedule a retransmission of the data packet to wireless terminal 200. Scheduling processor 407 and/or scheduling buffer 409 may thus schedule/reschedule data packet transmissions to wireless terminal 200 responsive to jitter buffer emulation for wireless terminal 200 and other wireless terminals.
As shown in
If VoIP quality management processor 401 determines at blocks 501, 503, and 505 that the new radio link is for a VoIP (or other real time) data packet communication and that jitter buffer emulation should be used to monitor its quality, VoIP quality management processor 401 may then proceed with initiating jitter buffer emulation for the radio link. As discussed above according to some embodiments, different wireless terminals may use different jitter buffer types/algorithms and JBE 403 may support emulation using different emulation types/algorithms corresponding to the different jitter buffer types/algorithms used by the different wireless terminals. Accordingly, VoIP quality management processor 401 may be configured to receive a jitter buffer identifier at block 506 identifying a jitter buffer type/algorithm used by the wireless terminal for which the radio link is being established. Such a jitter buffer identifier may be received at base station 100 from the wireless terminal and RAB handling processor 405 may forward the jitter buffer identifier to VoIP quality management processor 401 with the radio link setup notice. According to other embodiments, block 506 may be omitted if only one emulator type is provided by JBE 403, either because all wireless terminals use a same jitter buffer type/algorithm or because different jitter buffer types/algorithms used by different wireless terminals are sufficiently similar.
At block 507, VoIP quality management processor 401 may determine if the new radio link is for a new communication or for a hand-off of an ongoing communication from another (source) base station. If the new radio link is for a new communication, VoIP quality management processor 401 may provide an initialized jitter buffer emulation status (e.g., with a jitter buffer fill level of zero) at block 509, and VoIP quality management processor 401 may instruct JBE 403 to initiate jitter buffer emulation for the new radio link using the initialized emulation status and the jitter buffer identifier at block 511. If the new radio link is for a hand-off of an ongoing communication from another source base station, VoIP quality management processor 401 may receive a jitter buffer emulation status (e.g., including jitter buffer size, fill level, minimum/maximum fill level threshold, time for consumption of a next data packet/frame, etc.) provided by the source base station at block 515, and VoIP quality management processor 401 may instruct JBE 403 to initiate jitter buffer emulation for the new radio link using the emulation status from the source base station and the jitter buffer identifier at block 517. Operations of
For each jitter buffer emulation that is initiated by VoIP quality management processor 401 according to operations of
Once a radio link has been established between base station 100 and wireless terminal 200 and jitter buffer emulation has been initiated at JBE 403 at block 601, VoIP quality management processor 401 may determine at block 603 whether performance parameters for the jitter buffer emulation should be reported. At each reporting interval, for example, VoIP quality management processor 401 may request performance parameters (e.g., including emulated late packet loss occurrences, emulated time scaling occurrences, emulated jitter buffer fill level, and/or emulated minimum/maximum jitter buffer fill level thresholds) at block 609, the requested performance parameters may be received from JBE 403 at block 610, and the emulated performance parameters may be reported to an objective quality monitor (which may be included as an element of base station processor 101, as an element of base station outside 100 processor 101, as an element of RAN 60 outside of base station 100, etc.) at block 611. According to other embodiments, VoIP quality management processor 401 may request performance parameters on an as needed basis. According to still other embodiments performance parameters may be pushed from JBE 403 without requiring a request from VoIP quality management processor 401. JBE 403, for example, may push performance parameters responsive to changes in one or more of the performance parameters and/or periodically.
If the radio link for wireless terminal 200 is to be handed-off from base station 100 (as a hand-off source base station) to another base station (as a hand-off destination base station) at block 605, VoIP quality management processor 401 may request a status (e.g., jitter buffer size, fill level, minimum/maximum fill level thresholds, time to next data packet consumption, etc.) of jitter buffer emulation for wireless terminal 200 at block 615. VoIP quality management processor 401 may then receive the status of jitter buffer emulation at block 616, report the status to the destination base station at block 617, and then terminate jitter buffer emulation for wireless terminal 200 at block 619. If the radio link for wireless terminal 200 is to be terminated (e.g., responsive to wireless terminal 200 hanging up) at block 607, jitter buffer emulation for wireless terminal 200 may be terminated at block 619.
When VoIP quality management processor 401 requests performance parameters (e.g., late packet loss occurrences, time scaling occurrences, jitter buffer fill level, minimum/maximum jitter buffer fill level threshold, etc.) of jitter buffer emulation for wireless terminal at block 709, JBE 403 may respond at block 721 by providing the requested parameters of emulated jitter buffer performance for wireless terminal 200. As discussed above, VoIP quality management processor 401 may request these parameters periodically, JBE 403 may push these parameters periodically, and/or JBE 403 may push these parameters responsive to changes in one or more of the performance parameters.
If VoIP quality management processor 401 requests a status of jitter buffer emulation for wireless terminal 200 at block 711 (e.g., in preparation for a hand-off to another destination base station), JBE 403 may respond at block 723 with the requested status (e.g., jitter buffer size, fill level, minimum/maximum fill level threshold, time until a next data packet/frame consumption, etc.). At block 715, JBE 403 may continue operations of jitter buffer emulation for wireless terminal 200 until VoIP quality management processor 401 provides an instruction that the emulation should be terminated (e.g., responsive to hand-off of wireless terminal 200 to another base station and/or termination of the communication with wireless terminal 200).
Operations of block 717 will now be discussed in greater detail below with respect to
Operations of block 719 will now be discussed in greater detail below with respect to
In the above-description of various embodiments of the present invention, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein. While VoIP data packet communications are discussed by way of example, embodiments may be implemented for other real time data packet communications such as audio and/or video streaming.
When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term “and/or” includes any and all combinations of one or more of the associated listed items.
As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation “e.g.”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e.”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.
Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).
These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.
It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of the invention. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.
Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present invention. All such variations and modifications are intended to be included herein within the scope of the present invention. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE2011/051204 | 10/7/2011 | WO | 00 | 3/20/2014 |
