WO2016123497A1 - Bandwidth prediction and prefetching for enhancing the qoe of applications over wireless networks - Google Patents

Abstract

Systems and methods for adaptively streaming video content to a wireless transmit/receive unit (WTRU) may comprise determining current information associated with the WTRU, the current information including at least one of a location, a speed, a time, a data throughput, and a day; comparing the current information with previously determined information for the WTRU; predicting a future location for the WTRU; predicting an available network bandwidth at the future location; and determining a bit rate for the WTRU to request for a content segment, based on the predicted available network bandwidth for the predicted future location.

Description

BANDWIDTH PREDICTION AND PREFETCHING FOR ENHANCIN G THE QOE OF APPLICATIONS OVER WIRELESS NETWORKS

CROSS REFERENCE TO RELATED APPLICATION

fOOOl] This application claims priority to U.S . prov isional patent application no. 62/109,590, filed January 29, 2015, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Video streaming clients, network access points (e.g., Access Points in a Wi-Fi network, eNB in an LTE network), and/or content delivery network (CDN) edge servers may use Dynam ic Adaptive Streaming over HTTP (DASH), where a video file is stored on an HTTP server, as a series of small video segments . Each video segment may contain several seconds of video content and may be encoded at different bit rates, e.g., video qualities . The video client may determine which bit rate of the subsequent video segment should be requested.

SUMMARY

[0003] Systems and m ethods for adaptive ly streaming video content to a wireless transmit/receive unit (WTRU) may comprise determining current information associated with 1 e WTRU, the current information including at least one of a location, a speed, a time, a data throughput, and a day; comparing the current information with previously determined information for the WTRU; predicting a future location for the WTRU; predicting an available network bandwidth at the future location; and determining a bit rate for the WTRU to request for a content segment, based on the predicted available network bandwidth for the predicted future location.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is an example diagram of collaborative bandwidth prediction.

[0005] FIG. 2 is an example diagram of standalone bandwidth prediction.

[0006] FIG. 3 is an example diagram of prediction and rate adaptation .

[0007] FIG. 4 is an example diagram of pre -fetching data.

[0008] FIG. 5 is an example diagram, of pre-fetched data. [Θ009] FIG. 6 is an example diagram of the effect of pre-fetehing on bit rate .

[0010] FIG. 7 is an example diagram of signaling between an edge server, client, and a

DASHmedia content provider.

[0011 J FIG. 8 is an example graph showing the cumulative distribution function (CDF) of the error of bandwidth prediction.

[0012] FIG. 9 is an example graph showing video bit rates for a WTRU.

[0013] FIG. 10 is an example graph showing video bit rates for a WTRU.

[0014] FIG. 1 1 is an example graph showing the CDF of the video bit rates.

[0015] FIG. 12A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0016] FIG. 12B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within die communications system illustrated in FIG. 12A.

[0017] FIG. 12C is a system diagram of an example radio access network and an example coie network that may be used within the communications system illustrated in FIG. 12A.

[0018] FIG 12D is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG.

12A.

[0019] FIG. 12E is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 12A.

DETAILED DESCRIPTION

[0020] A detailed description of illustrativ e embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be examples and in no way limit the scope of the application.

[0021] Systems and methods for adaptive ly streaming video content to a wireless transmit/receive unit may improve Qo E ("quality of experience") of applications by predicting the available bandwidth. This prediction may be based on the previou s measurements of the past and/or current trips, and/or pre-fetching data. Althougii the available bandwidth may change and may change quickly in wireless network s, the bandwidth s of the same location measured at the same time of a day and the same day of a week (e.g., or a weekday or opposed to a weekend) may exhibit significant similarity. This observation may provide an opportunity to predict the available bandwidth at the same locations in the future. With the prediction, systems may improve and/or optimize Sh e bit rate selection algorithm of DASH to improve the video quality in terms of video bit rate. This improvement and/or optimization may avoid rebuffering and/or may reduce the frequency of video bit rate switching. The prediction may be used for other applications and/or may be used to provide a user feedback for route selection . A current serving radio access point may inform the next radio access point which may then pre -fetch data for a wireless transmit receive unit (WTRU).

[0022] A standalone bandwidth prediction system that allows the video client (e.g., a WTRLl) to predict the bandwidth and/or the vehicle speed based on its own measurements made in the past and current trips may be provided.

[0023] An available bandwidth algorithm and/or a Kalman filter may be used . An offline algorithm may be used to determine the parameters in the Kalman filter's state transition models, and/or a prediction algorithm based on the Kalman filter. A vehicle speed prediction algorithm may be included which may be similar to that used to determine the parameters in the Kalman filter's state transition.

[0024] A video bit rate adaptation algorithm for DASHthat may improve and/or maximize tlie video quality, and/or avoid buffer underflows .

[0025] Route selection based on the available bandwidth of tlie WTRU route may be utilized .

[0026] A current serving radio access point may be used to inform the next radio access point which may then re -fetch data for the WTRU.

[0027] Multiple system architectures of bandwidth prediction for DASH are described. Howev er, the applications are not limited to DASH, and may include video telephony, web browsing, cloud gaming, cloud computing, augmented reality, and/or tlie like. One or more examples disclosed herein may relate to predicting tlie available bandwidth at a future location, improving a bit rate selection algorithm for DASH, and/o r data pre -fetching mechanisms for improving tlie "quality of experience'¹ (QoE) of applications, such as DASH-based video streaming, for example . One or more systems and methods may include a collaborative bandwidth prediction, where one or more users may share bandwidth measurements with a server, and the server may make tie prediction for a user. One or more systems and methods may include a standalone bandwidth prediction, where a user (e.g. , tlie mobile device of a user or WTRU) may make a prediction based on its own previous measurements.

[0028] One or more of the systems and metliods disclosed may be applied to many wireless networks (for example, Hotspot 2.0). The systems and methods may use a wireless

transmit receive unit (WTRU) in a v ehicle . The systems and metliods may use a WTRU that is not in a vehicle. The systems and methods may be used with a WTRU carried by a pedestriain . For example, the systems and methods may be used with a WTRU carried by a edestriain walking in a shopping mall. The systems and methods may be used in a DASH enviornemnt, and are applicable to other environments.

[0029] FIG. 1 is a diagram of an example of a collaborative bandwidth prediction (CBP) system and method, in FIG. 1, tiie DASHmedia server may store video segments generated from different encoding versions of a video content. A DASH media presentation description (MPD) server may comprise MPD files describing basic segment information, including any of URL, video resolution, bit rate, codec, time and/or duration. The CBP server may collect the users' bandwidth measurements, including any of time, device type information (e.g. , Long Term. Evolution (LTE), Evolved High-Speed Packet Access (HSPA+), antenna configuration, etc.), and wireless carrier infomiation (e.g ., AT&T, Verizon, etc. ). Th e CBP server may select a subset of users that used or are using the same wireless network at a location for which the prediction is to be made. The CBP server may make tiie prediction for users. Users in the network may report their own bandwidth to the CBP server periodically, and, for example, may do so even when they are not in a video streaming session. With this bandwidth infomiation, the CBP server may maintain a bandwidth map containing the real-time bandwidths at different locations. The DASH client may predict its own movement. The DASH client may request the available bandwidths of the locations where it may probably arrive in subsequent time durations from the CBP server. With the predicted bandwidth, movement, and/or MPD, the WTRU may determine the appropriate video segment and/or may request the media data from the DASH media server.

[0030] An advantage of the CBP approach is that it may provide accurate and /or real-time prediction to tiie video client, including at locations tiie video client has nev er been before. The CBP server may maintain a bandwidth map for multiple kinds of client models because different client models may use different wireless networks or may have different technical specifications (e.g. , different numbers of an tennas), which may result in different bandwidths at the same time at the same location .

[0031] The measurements taken at a WTRU may not have to be in the original form, for example, to save communication bandwidth . The measurements may include summary statistics . For example, if the original distance interval for the measurement is d meters, the summary statistics may be in kd meters, where k is an interger greater than 1.

[Θ032] An application may be downloaded to a WTRU. The application may cany out the messaging between the WTRU and the CBP . The application may provide she client the option to share its measurements or not, and different pricing schemes may be associated with the choice . For example, if the u ser shares, the cost of using this service may be lower or free. Otherwise, the cost may be higher.

[0033] The application may check the available bandwidth of the route the WTRU is taking, and if th e available bandwidth is not sufficient to maintain th e quality of the application, it may suggest that the user take a different route, for example, by prompting a suggestion on a GUI.

[0034] FIG. 2 is an example of a diagram of a standalone bandwidth prediction (SBP) system and method . In systems and methods using a standalone bandwidth prediction (SBP) a user (e.g. , ttie mobile device of a user or WTRU) makes a prediction based on its own previous measurements . A difference between SBP and CBP is that there may be no CBP server in the SBP network . With a SBP system, a DASH client (e.g. , WTRU) may measure its own bandwidth and may save the bandwidth measurement and the corresponding location at its local storage. For example, a DASH client (e.g., WTRU) may measure its own bandwidth each time it visits a location and may save the bandwidth measurement and the corresponding location at its local storage. The DASH client (e.g., WTRU) may predict the bandwidth of the location before it takes the next visit to that location, for example, after several visits to a location. A DASH client (e.g., WTRU) may request the appropriate video segments from a DASH media presentation server, for example, similar to the CBP architecture, with the predicted bandwidth and/or mo ement.

[0035] An advantage of the SBP approach may be easy implementation that a new node may not be required at the network to access t e bandwidth information of the LTE network . In the SBP approach, a DASH client (e.g., WTRU) may need to leam its bandwidth map, and during the learning phase, the bandwidth prediction and/or the DA SH bit rate selection may not be accurate .

[0036] FIG. 3 illu strates an arch itecture of a local prediction and rate adaptation to improve and/or optimize the video quality. Current location, time, speed and/or bandwidth are used to predict the speed and/or bandwidth of upcoming locations. A Kalman filter may be used to predict the speed and/or bandwidth. State transition parameters may be determined by historical data. The bandwidth, speed predictions, and/or the current buffer size may be fed to the bit rate adaptation algorithm to choose an appropriate bit rate .

[0037] The historical data may contain the following information: the network operator; the available bandwidth and/or the speed as a function of location and/or time .

[0038] The local predictor may check the available bandwidth of the route of the WTRU. If the available bandwidth is not sufficient to maintain the quality of the call, the local predictor may suggest that the user take a different route, for example, by prompting a suggestion on a GUI.

[0039] Given the available bandwidth prediction, the WTRU may use the available bandwidth prediction in different ways. If theiE is excess available bandwidth in some sections of the predicted path and the prediction indicates later sections of the path having insufficient bandwidth ahead, the WTRU may use or may plan to use the excess available bandwidt!i in some sections to pre-fetch content to be used in the later sections of the path, assuming that the WTRU has sufficient buffer space. This may improve the content quality for future sections.

[0040] If there is no excess available bandwidth in some sections of the predicted path, for example, the availabe bandwidth, is already fully utilized for the content to be played in the sections, the WTRU may request lower bitrate content for the sections and that may leave some available bandwidth unused, which may be used to pre-fetch the content to be played for future sections . This may avoid rebuffiering.

[0041] The standalone bandwidth prediction approach may incur zero communication overhead, which may be an advantage over the collaborative bandwidth prediction approach.

[0042] FIG. 4 is an example of a diagram of a system and method tor pre-fetehing data. The current radio access point may predict the route that a WTRU may take and may notify the subsequent radio access points on the route. The notification may include one or more of the following: the predicted time when the WTRU may enter the service area of the subsequent radio access points, the source of the data the WTRU is consuming, what data objects the WTRU is consuming, and /or what data, objects the WTRU is expected to consume in the future . These subsequent radio access points may pre-fetch data in anticipation that the WTRU may visit their respective service area in the future. The pre-fetch ed data may be cached and may be sent when the WTRU gets into the service area of the radio access point that caches the data.

[0043] As an example, Fig. 4 shows an architecture for an LTE network. eNB 1 may notify eNB 2 of the time T when the WTRU may probably enter the service area of eNB 2. eNBl may notice eNB2 of the source of data that the WTRU may require, and eNB 2 may pre-fetch the required data. To assist the transition from eNB 1 to eNB 2, the data pre-fetched at eNB 2 may overlap with that at eNB 1. When the WTRU enters tie service area of eNB 2, the WTRU may download th e data directly from eNB 2, which may reduce the RTT, and may increase the throughput The WTRU may download the data directly from eNB 2 instead of downloading data from the Internet. This method may be applied to, but is not limited to, DASH.

[0044] The content cached by one access point may overlap with the content cached by the next access point, which may assist in maintaining the continuity of the content. This may be beneficial if there is prediction inaccuracy. The amount of overlapping may be a function of prediction inaccuracy. As an example, for she network shown in FIG. 4, the content may be portioned in playback time (e.g., in seconds) as shown in FIG. 5. The first access point, eNBl, may pre -fetch the content from the first second to the fifth second, and the second access point, eNB2, may pre-fetch the content from the fifth second to the ninth second . The two pre-fetched contents may overlap in the 5th second, as shown in FIG. 5.

[0045] FIG. 6 is an example of a diagram showing the bit rate over time for a WTRU transitioning between eNB 1 and e NB 2. As illustrated in FIG. 6, assume that the WTRU, which may be a DASH video player, enters the service area of eNB 2 at time T, and its buffered data plays until time T '. Without pre-fetching, the WTRU continues to play low quality video after T'. If the pre-fetching at eNB 2 is enabled, high bit rate video may be pre-fetched at eNB 2. Because high bit rate video has been pre-fetched and is available at the access point, the throughput to the WTRU may be increased. Thus, the video bit rate after 7" may be improved .

[0046] The throughput may increase because of the following: the throughput of a TCP connection is upper bounded by:

Throughput < (1)

M is the maximum segment size, RTT is the round trip time, P is the probability of packet loss, and C is a constant determined by the TCP implementation . RTT is the sum of RTF 1 and RTT 2, which are the round trip times between the UE and the eNB, and between the eNB and the internet server, respectively. For LTE network, RTT__1 is usually between 30 to 60 msec, and is proposed to be less than 1 msec for 5G networks. RTT is usually dominated by RTT 2, which may be hundreds of milliseconds when the connection goes through intercontinental routes. When the pre-fetching is enabled, RTT reduces to RTT_1, which increases the throughput.

[0047] FIG. 7 is an example of a diagram of the signaling between the client (e.g., WTRU), a DASH media content provider, and a content distribution network (CDN) edge server. An edge server may be collocated at a wireless access point such as an eNB. The content provider may predict the route based on information provided by tie WTRU. The client may send the coverage update, which may include by way of example, one or more of the following: address of video content (e.g. , which part of tie video content under request), bit rate, bandwidth, location and speed, and/or phone number or o flier identifier. The client may provide the coverage update to the media server periodically. The content provider may predict the client's (e.g. , WTRU's) route, decide edge servers to be pre -cached, and/or may send the client (e.g. , WTRU) the address of such edge servers. Tl e content provider may suggest the bit rate for the client.

[0048] The content provider may obtain tlie predicted route from a third party including a location sendee, such as Google, etc. The location may be obtained in various ways. For example, tlie phone number associated with the client may be passed to the third -party location service to query about the location of tlie client.

[0049] For a standalone approach, tlie client may predict its own movement, and may send tlie content provider its future locations. Hie media server may pre-cache tlie media data to the corresponding edge servers (e.g., based on tlie predicted route information provided by tlie client). The network -only approach may involve multiple content providers along the route. Cloud computing may be applied to reduce t e delay including RTT, computing time of the algorithm, etc. The WTRU may use tlie same prediction algorithms and tlie bit rate selection algorithm that are described w ith respect to the SBP approach.

[0050] The historical data on the available bandwidth, and speed for one or more WTRUs are stored in tlie network. The network may predict the future locations of a WTRU and/or tlie times associated with the locations. The network may decide which wireless access point (or access points) may pre-fetch the content that the WTRU is likely to use in tlie future. The network may- provide to tlie client information about the quality and/or the bit rate of the content to be requested.

[0051] A client (e.g., WTRU) may observe its current location, speed, and available bandwidth, device type, and/or the associated network operator (e.g. , AT&T or Verizon) and provide she information to an entity (network service enhancing node or NSEN) in the network. The NSEN may aggregate such information from one or multiple clients .

[0052] The NSEN may p redict which access point a WTRU may visit in the future. The NSEN may instruct the access point to pre-fetch content that is likely to be used by the WTRU in die future.

[0053] The NSEN may provide tlie WTRU information about which quality' level (e.g. , bit rate of the v ideo) tie WTRU needs to request in die future. This information may be used together with the available bandwidth observed locally by the WTRU to decide which quality le el to be requested.

[0054] The NSEN may build a map of expected available bandwidth, e.g., as a function of one or more of location, time, day of week, network operator, device type. For a particular WTRU, the NSEN may refine the prediction of the available bandwidth using for example one or more of that WTRU's current location , speed, available bandwidth , the number of other devices and the traffic demand of other devices that use the same network.

[0055] The available bandwidth and/or vehicle speed at the future locations may be predicted based on the measurement of the current and/or previous tips. The prediction methods and systems may work cooperatively with both CBP and SEP architectures. The predictive methods and systems may contain movement prediction and/or bandwidth prediction, which predict the vehicle speed and the available bandwidth at future locations, respectively. The algorithms for die movement and bandwidth prediction may be similar.

[0056] An example of the bandwidth prediction algorithm is described below. Assume that the travel route is given and is partitioned into segments of equal length L, for example, L=300 meters . Denote by V_t and B_ the random variables of the vehicle speed and the bandwidth at the i^'-th segment, respectively. Let the random variable hi be the measured bandwidth at z^'-th segment. Generally, the measurement is not accurate and contains random vanations. If repeated trips are conducted to collect the historical data, let h_i be the measured bandwidth at the i-th segment during the t-th trip. Based on the current measured bandwidth, with the help of the historical measurements, the bandwidth prediction may generate a more precise estimate of the bandwidth and may also predict the available bandwidths in the subsequent segments. The prediction method is based on a Kalman filter, which is widely applied in vehicle nav igation. The bandwidth may be modeled in the following form:

Β_Μ = Β_{! +}Ν, (2) for ail /, where _ι is the state transition parameter from. B_i to B_j+l , and N₍- is the process noise which is assumed to be drawn from a zero mean Gaussian distribution with variance Assume that N_; is independent of B, and b . foi all j . At the Mh segment, the measurement of the bandwidth is obtained from the following model:

/). B + n (3) where ft is the measurement error which is assumed to be drawn from a zero mean Gaussian distribution with variance ¾ . Assume that n_i is independent of 5_; , h , and N, for all j .

[0057] Before performing the Kalman filter, the parameters φ, , Q, and ¾ in (1) and (2) may be determined from historical data. From (1) and (2), the measured bandwidth h_j+j , ¾ and b_M may be expressed as: b. , />' , +«.,.

^φ_ιΒ_ι+Ν_ι -i-n^

= φ_ιφ_ι_β_ί__ι + _ιΝ_ί__ι + Ν_ί+^η _Μ (4) ft = i +¾

= ¾¾ + ^,+« (5)

^¾' i /^' ,+'* . (6)

The mean of the measured bandwidth b_j+l may be written as

F¾J = E[i?.₊₁] = ffi] = ^E[/J (7)

[0059] Because of the independence of the random variables B_j , N_M and /¾, the variance of the measured bandwidth b_i is obtained from (4),

Var¾ ] = ^V^'aij f , ] + Q_ + ¾ (8)

Vai[Z>_M] = Va-[5_I_₁]-i-¾_₁ (9)

[0060] Because of the mdependence of B_i . N. and n_t for all /, the following covariances from are obtained,

Co¾^_₁] = ^_₁Vai?J (11)

Referring to the above equations, the mean h[b_t ] , variance Var[6. ]_; and covariance Cov , J of the measured bandwidths may be estimated by the sample mean m_i , samp le variance of and sample covariance <x,. · of tie historical data, where

Let β_ι == Vaffi J . Then the equations become:

¾-^^=:° (16) * I </ (18)

^«\ . Φ :β ^{> (21)

[0063] Assume that <_Μ and φ_ί are known, which may actually be obtained in the previous steps of the algorithm as shown below. The left hand side of the above equations (13)-(21) may be denoted by functions φ). j⁽0_: ,.^ί/_;.# ,). /^' _:j( >/ ,). fM>Q-i >$-i), fs(≠,>fi-i) ^and /₍.(/'>, ;). Determining φ, Q and ¾ reduces to solving the following optimization problem,

6

minimize ./^'(<¾ , , ¾ , _. ) = Y

(22) subject to _ί,(_ί-ι,<ϊ_ί,β_ί-ι >0.

|0064] The algorithm may be written as described below. This algorithm may be performed offline and may not increase the complexity or latency of the DASHplayer. The parameters φ,

Q and < maybe provided to fee DASHplayer. in an example, the algorithm includes the following:

Example Algorithm 1 : Determine the state transition paremeier φ_; and/or the variances Q_; and qi of the noises Ni and n_;, respectively.

1. Initialize <*i and ¾;

2. FOR - ~ to N

3. Solve the optimization problem A ito obtain Q_, and ¾;

4. END FOR

[0065] With the parameters, the sy stems and methods may predict the bandwidih at the following segments using the Kalman filter. Let A_;. be the Kalman gain at the i-th segment and

If be the predicted estimate error variance. When a measurement h. is available, the estimate may be updated by:

li_\ =!i, + K:(i): - ! ) (23) where B_i is a prior estimate without , and B; is the updated estimate. The error variance fer tile updated estimate may be computed:

Pi = (l - KdPr (24) The prio r estimate for the next segment may be computed, and the predicted estimate error variance and the Kalman gain for the next segment may be computed:

li , - φι Β, (25)

A , --;r^' ------ (2^?

[0066] A Kalman filter may be used. With the measuremetn of b, of the i -th segment, the speed of the next segment B_i ^' _{+ 1} may be predicted.

[0067] Similar to the above bandwidth prediction, the vehicle speed may be modeled by the following equations:

v_i = V_i + w_i (28) ν_Μ = Ψ , (29) where v. is the measured speed at the /-th segment; ψ_ι is the state transition parameter from V, to I ^' .. . and W_i and w_t are the process noise and the measurement noise, which are independent and are assumed to be drawn from zero mean Gaussian distribution with variance 1 and /^* , respectively. In the systems and methods, the speed V[₊ ^~ ₁ of the next segment from the

measurement ^"H of the current segment may be predicted. Following Example Algorithm 1 above and the Kalman filter, the predicted bandwidth _Λ for the next segment may be obtained .

[0068] Although the available bandwidth may change and in some instances may change relatively quickly in wireless networks, the bandwidttis of the same location measured at the same time of a day and the same day of a week (e.g., or weekday as opposed to weekend) show some similarity. Based on this observation, the systems and methods may select measurements at the same time of a day and the same day of a week as historical data to calcu late mi, a and σ_{ί ;}·, and optimize and ^i Problem ( 1_έ) referenced above.

[0069] A video bit rate adaption algorithm may apply in various applications (for example, DASHor another application). The video bit rate adapation may use the predictions of available bandwidth and/or vehicle speed at the future locations based on the measu rement of the current and/or previous trips. For an example, of the video bit rate adapation, assume that the measurements of the current segment, v and b. are available and the predictions of the next segment, V _l and B^~ , are available. An aim of the bit rate adaption algorithm is to choose the bit rate to improve and/or maximize th e video quality, and this may be done so while avoiding buffer underflow. Assume that the length of a segment (e.g. , every segment) is L meters. In one example, the algoirthm optimizes the video quality for the subsequent M segments. Denote by BS the current buffer size measured in real time, which is the video playback time of the buffered data. Let . , and B, be the predicted speed and the predicted bandwidth at the ( + j)

-th segment, when the measurements (e.g. only the measurements) before the /-th segment are available, respectively, where

A. , ir _: (31) ν,,^ ^Φ^ - ,^ (^¾)

B, * = ΨΜΨΙ -Ι ~ ^' Ψ, +&+Ι (33) for 2 < k≤M. The time duration traveling through the ( + m) -th segment, l≤m≤M, is

/^·, (34)

The total data downloaded during the (i + m ) -th segment is

H J.

^ - B,J,^ -f^~ (35)

[0070] If the buffer size BS is no more than a lower bound BS low, then rebuffering may occur with a significant probability, and the client may be forced to switch to the lowest bit rate. Otherwise, to avoid rebuffering, the following may be used:

∑^m D

^__,T_k≤BS+~^-^, (36)

BR

for 1≤m <M , where BR is the chosen bit rate. From the above inequality:

∑" ,D ,

~^~^≥∑^m^T_{i k} -BS (37) BR

When∑"l_jl- _k > BS , the selected bit rate has an upper bound, When∑™_=lT_{l k}≤ BS, no upper bound may be imposed on BR .

[0071] The bit rate adaptation algoritlim may be written as described below. In an example, the algorithm includes the following:

Example Algorithm 2: Given the predicted speed V. and the predicted available bandwidth

B for 1 < m≤M and the current buffer size BS , determine the upper bound for the video bit rate to avoid the rebuffering. and/or choose the bit rate to maximize the video quality. l . IF BS > BS_l0W

2. Initialize T_siim = 0 , D_sum = 0 , =∞; to M T_m!ll = T_m!ll + ~~

i,m

T T +

*- sum *- sum . -A1:... ·■>

V■

6. IF∑™

10. END IF

1 1.

12. I

13. Choose the maximum bit rate, which is no more than BR_!ax.

14. ELSE Choose the minimum bit rate.

15. END IF

[0072 J The media presentation description (MPD) may contain information of media streams, e.g., codec, duration of a media segment, and/or resolution and bandwidth of each representation. The maximum bit rate BR_max from above Algorithm 2 may obtained. The next video rep esentation with tie highest bit rate no greater than BR max may be selected.

[0073] in line 13 of Example Algorithm 2, tlie maximum may take over tlie available bit rates specified in the MPD file. As an example, an MPD file may contain 10 bit rates as follows:

<?xml version="l .0" en coding=" t - 8 " ? >

<MFD xmlns="um : mpeg : dash : schema :mpd : 2011 "

xnilris : xsi="http : //www. w3. org/2001/XMLSchema-instance "

ofiles=" urn:mpeg : das uprofile : is off--li e: 2011" type=" static" medi aPresentatlonD rat ion== "PT9M56.453 S "

mi tiBu fferTime--"PT4S "XPe iodXAdap t t.ion Set id="l " groups" 1"

prof iles=" ccff" bits eam3witching="true " s egmentAlignme t="t rue " contentType=" ideo " mimeType="video/m 4 " codecs=" vol , 640028"

maxWidth■==" 1920 " maxHei ght="1080 "

s tartWi

timescale=="l 0000000 "

edi a="QualityLevels (■? Bandwidth$ ) / Fragments ( video=$Time$, format=m pd-time-cs f ) "

initialization-"0u3.1ityLeveis ( $ 3aridwidth$ ) /Fragments !video-i, form at==mpd-time-csf) "><Seamen tTimelineXS d== "30000000 " r="197 " / x s ---"24166667 "/></ SegmentTimeline / Segmen;:Template>

< Rep res entation id="l V video 1" bandwidth= "6000000 "

width=="1920*'height==*'1080"/>

<Rep res entati on id="l_V_video_2 " b ndwidth= "5027000"

idth=" 1600 "height=" 00"/>

<Representation id-"l V video 3" bandwidth^ "2962000" width-" 1280 " height-"720"/>

<Re resentation id="l_V_video_4 " band idth=== "2056000 " width=" 92 " height="560"/>

<Re esentation id="l V video 5" bandwidth= "1427000 " width="768" height="432 "/>

<Representation id="l_V_video_6 " bandwidth= "9 1000 " width="5 2" heic ht= " 332"/ >

<Representation id="l V video 7" bandwidth^ "688000" width="448" height=="252"/>

< epresentation id="l_V_video_8" bandwidth= "477000" width="368" height="208" >

< e resentation id="l V video 9" bandwidth= "331000 " width="2S4" height-"160"/>

<Representation id="l v video 10" bandwidth="230000 " width="224" height="128"/> [0074] Another application is video telephony. With video telephony, a WTRU may maintain measurements of available bandwidth and may share the measurements with other users via the CBP . When a user is making a video call, the application may check the available bandwidth of the route the WTRU is moving along. If the available bandwidth is not sufficient to maintain she quality of the call, the application may suggest that the user take a different route, for example, by prompting a suggestion on a GUI.

[0075] The systems and methods described herein may predict the available bandwidth based on the measurements of the current and previous trips. In addition, the systems and methods may include a video bit rate adaptation algorithm for applications, including DASH, that involve determining the predicted bandwidth and/or considering the current buffer size. Th e systems and mthods may be implemented in an LTE network or other wireless networks. In one example, a

WTRU has a self-contained client. The WTRU for example may have an enhanced DASH client and/or may be programmed with, algorithms to build a historical database of location & throughput. The historical database may include any or all off the following: recording location history vs. time, and recognizing patterns; recording travel speed history and/or changes of speed/location, etc., and recording bandwidth/throughput history vs. time and location. A

WTRU user may select video content to stream (e.g., via web site or DASH client or oilier streaming client) by using any or all of the following: the client obtains content info {e.g., DASH

MPD) and begins streaming content; the client observes location state as the route is traversed

{e.g. , location, speed, progress ...); the client uses history (e.g. , location/throughput patterns), content info, and/or location state to predict (e.g. , and periodically update prediction of) path vs. time and/or BW/throughput vs . time . Using any or all of the foregoing, the client may plan in advance and may perform predictive local caching (e.g., pre-fetohing) in order to improve playback quality and prevent rebuffering. For example, if a section along a WTRU path is predic ted to not have sufficient bandwidth for high quality streaming, the client may pre-fetch the high quality version of the required content segments in advance . For example, the WTRU may use excess availabie bandwidth in previous sections of the path. This assumes that the

WTRU has sufficient buffer to do pre-fetching. Local cache management is considered in implementing the algorithm. If a section along the WTRU path is predicted to not have sufficient bandwidth for high quality streaming, the WTRU might pre-fetch the low quality version of the required consent segments in advance, if there is no excess available bandwidth in previous sections of the ath. There may be no change needed on the network side, and no special/added communication between the WTRU and the network. Implementation may be done entirely within the WTRU for example via a downloadable app or an enhanced DASH client.

[0076] The systems and methods include client path prediction with predictive caching in a network . A WTRU may have an. e hanced DASH client which communicates with, a network in order to implement predictive pre-fetching to cache elements associated with, for example co- located with, network access points. The client may be equipped to do any or all of the following: recording location history vs. time, and recognizing patterns; recording travel speed history, changes of s eed/location, etc; and recording bandwidth/throughput history vs. time and location. A user may select video content to stream (e.g. , via web site or DASH client or other streaming client) by using any or all of the following: client obtains content info (e.g. , dash mpd) and begins streaming content; client observes location state as she route is traversed (e.g. , location, speed, progress... ); client uses history (e.g. , location/throughput patterns), content info, and/or location state to predict (e.g., and periodically update prediction of) path vs. time; and client sends updates of path vs. time to network .

[0077] The network may determine impro ved and/or optimal pre-fetching positions (e.g., specific caches collocated with network access points) and times for content segments. For contents which (based on the predicted path vs. time) are expected to be needed by the client when the client is passing within communication range of the network access points, content can be pie-fetched. The network may pre-fetch content at a certain bit rate to the cache of a certain network access point based on the expected available bandwidth for that WTRU at th e time the WTRU may pass within communication range of a network access point. The network may (e.g. , optionally) provide a message to the WTRU which indicates a preferred bit rate(s) to request, which may be based on the network's knowledge of available bandwidth at Sh access point and/or the knowledge of which bit rates have been predictively cached at the access point. As the WTRU travels the path, the WTRU may send updates of the predicted path vs. time to the network . The WTRU may request content segments in older to obtain, decode, and play back the content. The WTRU may receive messages from the network which indicate the preferred bit rate(s) to request. The WTRU or the network may determine the bit rate to request based on any or all of: information about the content (e.g., DASH MPD), the WTRU's recorded history of location & bandwidth/throughput vs. time, and/or based on the preferred bit rate(s) signaled by the network.

[0078] A WTRU may have a standard DASH client which may not be aware of nor have any special signaling related to tie location based prediction functions of the network. The WTRU may report observations of location and/or available network, bandwidth to an entity in the network , This may be part of existing location services and network feedback; as opposed to being functionality of an enhanced DASH client. For example, many phones hav e location services and associated reporting turned on by default, or to support other applications. The network may record the observatio ns of location and available network bandwidth (along with associated observation times) for the client. The network may aggregate the available netwoik bandwidth data from multiple clients in order to build a map of expected available netwoik bandwidth . This map may be a function of location, time, and/or day of week . The WTRU may request streaming content (e.g. , request an MPD; start a DASFI session). The network may predict a patli for the WTRU based on the recorded observations of the past locations & times of the WTRU, and/or based on the current location, direction, and/or speed of the WTRU. The network may predict (e.g., based on current location/s eed of WTRU, and current content segments the WTRU is requesting) how to pre-fetch future content to the caches associated with network access points along the predicted patli of the WTRU. The content segment to pre-fetch may be based on the pred icted segment to be needed at the predicted time th at the u ser may be in range of a particular netwoik access point. The bit rate of the content segment to pre-fetch may be based on the expected available network bandwidth at the predicted time and location. The network may (e.g., optionally) provide messages to the WTRU which indicate content segments and/or bit rates that the WTRU should request (e.g.. which recommend that the WTRU to request the pro er bit rate of a content segment). These content segments and/or bit rates may be based on the bit rate the network has chosen to pre-fetch to the cache at a given network access point. The message may be explicit signaling that recommends a bit rate. The message may take the fonn of an updated MPD. For example, the updated MPD may limit the available bit rates listed for the giv en content segment. The limited available bit rates in the updated MPD may reflect one or more bit rates of content segments pre-fetched and available in a cache . There may be no modification of the DASH client on tie WTRU. The WTRU may continue traveling along the path and may request and receive the needed video segments as it travels. The WTRU may receive, decode, and play back the video segments.

[0079] Tests were conducted using an example of an SBP approach (e.g., described above with reference to FIG. 2). In the tests, the DASH MPD server was an Apache web server running on Ubuntu 14.04, which also hosts the Javascript program DASH.sj . In the tests, the WTRU was a Samsung Galaxy Tab 4 accessing a Verizon LTE network . The video sequence "Big Buck Bunny" was used in the tests and was provided by the DASH.sj program. The video sequence used was approximately 600 seconds in duration and a video segment (e.g. , every video segment) contained about three seconds of video content. There were ten video bit rates : 0.23, 0.33, 0.45, 0.67, 0.99, 1.43, 2.06, 2.96, 5.03, and 6 Mbps .

[0080] In the experiment, two routes were selected in the San Diego area. The routes had the same starting and ending points. The first route traveled mostly on highways, while the other route was mainly on local streets . More than thirty-five repeated experiments were conducted along these two routes in both directions from September, 2014 to January, 2015. The experiments were performed during both peak and off-peaii hours, and as a result, each lasted for about 20 to about 50 minutes . Each route was partitioned into segments of approximate 300 meters .

[0081] Historical data was collected, which imitated the accumulation of measurements, for example, a per commutes regularly to work. For each route, there was a corresponding set of historical data. This data contained the location and speed, which are provided by the GPS device on tie client with an accuracy of 4 meters, as well as the bandwidth obtained by dividing the size of the download data by th e duration between the request and the reception . In a segment, more than one measurement may be obtained and if so the average of all measurements in tfie segment was used as the measurement for that segment. With the historical data.

Algorithm 1 described above was run offline to determine the parameters in the state transition models, and they were fed to the DASH player. Predictions were implemented using the Kalman filter and the bit rate adaptation algorithm to the DASHjs.

[0082] Perfo rman ce was evaluated. The accuracy of the bandwidth prediction algo rithm was considerd. In FIG. 8, the cumulative distribution function (CDF) of the percentage of the difference between the predicted and the measured bandwidth. Almost 60% of the predictions have errors less than 20%. Since the video bit rates are quantized into 10 levels from 0.23 Mbps to 6 Mbps, the bit rate selection algorithm may still make the right decision with with errors being less than 20%.

[0083] In FIGS. 9 and 10, the video bit rates selected by she algorithm and Thang's algorithm under the same chanel realization are shown . Thang's algorithm calculates a moving average of tlie measured bandwidth as the prediction, and then selects the maximum available bit rate which is not greater than the prediction. The performance of Thang's algorithm was obtained by simulations using the historical data (available bandwidth as a function of time/segment) obtained from the experiment run with the highway data described above. FIG. 10 is an example that shows that the bit rates selected by an example of the algorithm has a greater average than those selected by Thang's algorithm, which is confirmed by the CDFs of tlie video bit rates for these two algorithms in FIG. 1 1. The disclosed algorithm provides a smoother bit rate selection than Thang's algorithm, where the switching probability for the disclosed algorithm is 6.1 % compared to 27.8% for Thang's algorithm.

[0084] The systems and methods predict the available bandwidth and may do so based on the measurements of current and/or previous trips. The systems and methods may provide a video bit rate adaptation algorithm for DASH. The systems and methods may consider the predicted bandwidth and/or the current buffer size. The tests conducted in an LTE network how that the disclosed systems and methods may be effective in improving the QoE to the video client.

[0085] FIG. 12A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data., video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0086] As shown in FIG. 12A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a WTRU, a fixed or mobile subscriber unit a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0087] The communications systems 100 may also include a base station 114a and a base station 1 14b . Each of the base stations 1 14a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 1 12. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single εΐεηιεηζ it will be appreciated that the base stations 114a, 1 14b may include any number of interconnected base stations and/or network elements.

[0088] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors . Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. The base station 114a may employ multiple- input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0089] The base stations 114a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 1 15/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/1 16/117 may be established using any suitable radio access technology (RAT) .

[0090] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or mo e channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 15/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HS A) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSU A).

[0091] The base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 1 15/1 16/1 17 using Long Term Evolution (LTE) and /or LTE-Advanced (LTE- A).

[0092] The base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access

(WiMAX)), CDMA2000, CDMA2000 I X, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (TS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0093] The base station 114b in FIG. 12A may be a wireless router. Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). The base station 114b and the W RUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 1 14b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTEA, etc. ) to establish a icocell or ferntocell. As shown in FIG. 12A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the core network 106/107/109.

[0094] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) sen-ices to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing sen' ices, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 12A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0095] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0096] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g. the WTRUs 102a, 102b , 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links . For example, the WTRU 102c shown in FIG. 12A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0097] FIG. 12B is a system diagram of an example WTRU 102. As shown in FIG. 12B, the WTRU 102 may include a processor 1 18, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /tou chpad .128, non -removable memory 1 30, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embod iment. Also, embodiments contemplate that the base stations 1 14a and 1 14b, and/or the nodes that base stations 1 14a and 114b may represent, for example, a transceiv er station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may- include some or all of the elements depicted in FIG. 12B and described herein .

[0098] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any oth er type of integrated circuit (IC), a state machine, and the like . The processo r 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables she WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. 12B depicts the processor 1 18 and fie transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip .

[0099] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over she air interface 115/116/1 17. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals . The transmit receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example . The transmit receive element 122 may be configured to tran smit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals,

[0100] In addition, although the transmit/receiv e element 122 is depicted in FIG. 12B as a single element the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the W RU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/1 16/117.

[0101] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit receive element 122 and to demodulate the signals that are received by the transmit/recei e element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1, for example.

[0102] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit) . The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 1 32. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a haid disk, or any other type of memory storage device . The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In oth er embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0103] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc. ), solar cells, fuel cells, and the like .

[0104] The processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 15/116/117 from a base station {e.g., base stations 1 14a, 114b) and/or determine its location based on the timing of the signals being received from, two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0105] The processor 1 18 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may- include an accelerometer, an e-compass, a satellite transceiver, a d igital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (EM) radio unit, a digital music player, a media player, a video game player module, an internet browser, and the like .

[0106] FIG. 12C is a system diagram of the RAN 103 and the core network 106 accord ing to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 15. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 12C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown.) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may- include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0107] As shown in FIG. 12C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected . In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encr ption, and the like .

[0108] The core network 106 shown in FIG. 12C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. Wh ile each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[01091 The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface . The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0110] The RNC 142a in the RAN 103 may also be connected to she SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled dev ices.

[0111] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/o r operated by other service providers.

[0112] FIG. 12D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-^'UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0113] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent wish an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MLMO technology. Thus, th e eNode-B 160a, tor example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0114] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 12D, the eNode-Bs 160a, 160b, 160c may communicate wish one another over an X2 interface .

[0115] The core network 107 shown in FIG. 12D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0116] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0117] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 1 60c in the RAN 104 via the S I interface. The serving gateway 164 may generally route and forward user data packets to/from she WTRUs 102a, 102b, 102c. The serving gateway 1 64 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like .

[0118] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0119] The core network 107 may facilitate communications with other networks . For example, the core network 107 may provide the WTRUs 102a, 1 02b , 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land -line communications devices. For example, the core network 107 may include, or m ay communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, fie core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0120] FIG. 12E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to commun icate with the WTRUs 102a, 102b, 102c over the air interface 1 17. As will be further discussed below, she communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may^¬ be defined as reference points. [Θ121] As shown in FIG. 12E, Sh e RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 17. In one embodiment, the base stations 180a, 180b, 180c may implement Ml MO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobilit ⁷ management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0122] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may^¬ be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0123] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0124] As shown in FIG. 12E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 1 9 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator. [Θ125] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and I -enabled devices . The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate i terworking with oilier networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102 b, 102c and traditional land -line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by oilier service pro iders.

[0126] Although not shown in FIG. 12E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the coie network 109 and the o flier core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0127] Although features and elements are described above in particular combinations, one of ordinaiy skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program., software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal haid disks and removable disks, magneto -optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method for adaptively streaming video content using a wireless transmit/receive unit (WTRU), comprising:

determining current information associated with the WTRU, the current information including at least one of a location, a speed, a time, a data throughput, and a day:

comparing the current information with previously determined information for the WTRU;

predicting a future location for the WTRU;

predicting an available network bandwidth at the future location; and

determining a bit rate for the WTRU to request for a content segment, based on the predicted available network bandwidth for the predicted future location.

2. The method of claim 1, further comprising requesting the content segment at the determined bit rate.

3. The method of claim 1, further comprising determining the current buffer size .

4. The method of claim 1 , further comprising requesting additional content segments and caching the additional content segments for subsequent playback if the future location is predicted to have relatively less available network bandwidth.

5. The method of claim 1, further comprising applying a Ka!man filter to predict the WTRU's future location.

6. The method of claim 5, wherein the future location for the WTRU is predicted by predicting the speed.

7. The method of claim 1, wherein the future location for she WTRU is predicted based on previously determined locations and at least one of a speed , a time, and a day associated with the previously determined locations.

8. The method of claim 7, wh erein the fiiture location, previously determined locations, at least one of a speed, a time, and a day associated with the previously determined locations are determined solely by the WTRU.

9. The method of claim 1, wherein the fixture location for tie WTRU is adjusted based on subsequent determinations of location and at least one of a speed, a time, and a day associated with the location.

10. The method of claim 1, wherein multiple future locations for the WTRU are predicted.

1 1 . The method of claim 1 , furth er comprising applying a Kalman filter to predict the available network bandwidth at the future location for the WTRU.

12. The method of claim 1, further comprising mapping reoccurring patterns of location and available network bandwidth .

13. The method of claim 1, further comprising sending an alert when the future location is predicted to have relatively less available network bandwidth.

14. A wireless transmit receive unit (WTRU), comprising:

a processor with executable instructions for:

determining current information associated with the WTRU, the current information including at least one of a location, a speed , a time, a data tliroughput, and a day;

comparing the current information with previously determined information for the WTRU;

predicting a future location for the WTRU;

predicting an available network bandwidth at the future location; and determining a bit rate for the WTRU to request for a content segment based on the predicted available network bandwidth for the predicted future location.

15. The WTRU of claim 14, wherein the processor has executable instructions for requesting the content segment at the determined bit rate .

16. The WTRU of claim 14, wherein she processor has executable instructions for determining the current buffer size.

17. The WTRU of claim 14, wherein the processor has executable instructions for requesting additional content segments and caching the additional content segments for subsequent playback if the fiiiure location is predicted to have relatively less available network bandwidth .

18. The WTRU of claim 14, wherein the processor has executable instructions for applying a Kalman filter to predict the WTRU's future location.

1 . The WTRU of claim 18, wherein the future location for the WTRU is predicted by predicting the speed.

20. The WTRU of claim 14, wherein the future location for the WTRU is predicted based on previously determined locations and at least one of a speed, a time, and a day associated with the previously determined locations.

21. The WTRU of claim 20, wherein the future location, previously determined locations, at least one of a speed, a time, and a day associated with the previously determined locations are determined solely by the WTRU.

22. The WTRU of claim 14, wherein the future location for the WTRU is adjusted based on subsequent determinations of location and at least one of a speed, a time, and a day associated with the location.

23. The WTRU of claim 14, wherein multiple future locations for the WTRU are predicted.

24. The WTRU of claim 14, wherein the processor has executable instructions for applying a Kalman filter to predict the available network bandwidtli at the future location for the WTRU.

25. The WTRU of claim 14, wherein the processor has executable instructions for mapping reoccurring patterns of location and available network bandwidtli.

26. The WTRU of claim 14, wherein she processor has executable instructions for sending an alert when the future location is predicted to have relatively less available network bandwidtli.

27, A method for adaptively streaming video content using a wireless transmit/receive unit (WTRU), comprising:

predicting a future location for the WTRU;

predicting an available network bandwidth at the future location, based upon information previously measured at the future location by she WTRU; and

determining a bit rate for the WTRU to request for a content segment, based on the pred icted available network bandwidth for the future location.