TW201633825A - 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

Enhanced bandwidth prediction and prefetching for wireless network applications QoE

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to US Provisional Patent Application No. 61/109,590, filed on Jan.

Video streaming client, network access point (eg, access point in WiFi network, eNB in LTE network) and/or content delivery network (CDN) edge server can use dynamics over HTTP Adaptive Streaming (DASH), in which video files are stored as a series of small video segments on an HTTP server. Each video segment can contain several seconds of video content and can be encoded by a different bit rate (eg, video quality). The video client can determine which bit rate of the subsequent video segment should be requested.

Systems and methods for adaptively streaming video content to a wireless transmit/receive unit (WTRU) may include determining current information associated with the WTRU, including current location, speed, time, data throughput, and date At least one; comparing the current information with information previously determined for the WTRU; pre-determining the future location of the WTRU; predicting available network bandwidth at the future location; and basing based on predicted availability for the predicted future location The network bandwidth determines the bit rate at which the WTRU requests content segmentation.

The illustrative embodiments are now described in detail with reference to the various drawings. While these descriptions provide specific examples of possible implementations, it should be noted that these details are not intended to be limiting, and do not limit the scope of the application. Systems and methods for adaptively streaming video content to a wireless transmit/receive unit (WTRU) can improve the QoE ("experience quality") of the application by predicting the available bandwidth. The prediction may be based on previous measurements of past and/or current itineraries, and/or prefetched data. Although the available bandwidth can be changed and can be changed quickly in a wireless network, the bandwidth at the same time of day and the same location measured on the same day of the week (or, for example, a weekday or weekend) can be Shows significant similarities. This observation can provide an opportunity to predict the available bandwidth for the same location in the future. Using this prediction, the system can improve and/or optimize the bit rate selection algorithm for DASH to improve video quality based on the video bit rate. This increase and/or optimization may avoid re-buffering and/or may reduce the frequency of video bit rate switching. This prediction can be used for other applications and/or can be used to provide user feedback for route selection. The serving radio access point can now notify the next radio access point, which can then prefetch the data for the wireless transmit/receive unit (WTRU). A separate bandwidth prediction system can be provided that allows a video consumer (e.g., a WTRU) to predict bandwidth and/or vehicle speed based on measurements made by itself in past and current trips. Available bandwidth algorithms and/or Kalman filters can be used. The offline algorithm can be used to determine parameters in the state transition model of the Kalman filter and/or prediction algorithms based on Kalman filters. A vehicle speed prediction algorithm may be included, which may be similar to the algorithm used to determine the parameters in the state transition of the Kalman filter. The video bit rate adaptation algorithm for DASH can improve and/or maximize video quality and/or avoid buffer underflow. Route selection based on the available bandwidth of the WTRU route may be utilized. The current serving radio access point can be used to notify the next radio access point, which can then prefetch the data for the WTRU. A number of system architectures for bandwidth prediction for DASH are described. However, applications are not limited to DASH, and may include video telephony, web browsing, cloud gaming, cloud computing, augmented reality, and the like. One or more examples disclosed herein may relate to predicting available bandwidth at future locations, improving bit rate selection algorithms for DASH, and/or data prefetch mechanisms for improving the "quality of experience" (QoE) of applications, such as , such as DASH-based video streaming. One or more systems and methods can include cooperative bandwidth prediction in which one or more users can share bandwidth measurements with a server and the server can predict for the user. One or more systems and methods may include separate bandwidth prediction, where a user (eg, a WTRU or a user's mobile device) may make predictions based on their own previous measurements. One or more of the disclosed systems and methods are applicable to many wireless networks (e.g., Hotspot 2.0). Systems and methods may use a wireless transmit/receive unit (WTRU) in a vehicle. Systems and methods may use WTRUs that are not in the vehicle. Systems and methods are available for WTRUs carried by passersby. For example, systems and methods are available for WTRUs carried by passersby walking around a shopping mall. The system and method can be used in a DASH environment and applied to other environments. Figure 1 is a diagram of an example of a Cooperative Broadband Prediction (CBP) system and method. In Figure 1, the DASH media server can store video segments generated from different encoded versions of the video content. The DASH Media Presentation Description (MPD) server may include an MPD file describing basic segmentation information including any of a URL, a video resolution, a bit rate, a codec, a time, and/or a duration. The CBP server collects user bandwidth measurements, including any of the following: time, device type information (eg, Long Term Evolution (LTE), Evolved High Speed Packet Access (HSPA+), antenna configuration, etc.) and wireless carrier Information (eg AT&T, Verizon, etc.). The CBP server may select a subset of users of the same wireless network at the location where the prediction is to be used or is being used. The CBP server can predict the user. Users in the network can periodically report their own bandwidth to the CBP server and can do so, for example, even if they are not in a video streaming session. Using this bandwidth information, the CBP server maintains a bandwidth map that includes real-time bandwidth at different locations. The DASH client can predict its own movement. The DASH client can request the available bandwidth at the location that it may arrive during the subsequent time from the CBP server. By using the predicted bandwidth, mobility, and/or MPD, the WTRU may determine the appropriate video segment and/or may request media material from the DASH media server. One advantage of the CBP method is that it can provide accurate and/or immediate predictions to the video client, including predictions at locations that have never been visited by the video client. The CBP server maintains a bandwidth map for a variety of consumer-end models because different user-side models can use different wireless networks or can have different technical specifications (eg, different numbers of antennas), which can Resulting in different bandwidths at the same time at the same location. The measurements made at the WTRU do not have to have the original form, for example, to save communication bandwidth. Measurements can include summary statistics. For example, if the raw distance interval for the measurement is d meters, the summary statistics may be within kd meters, where k is an integer greater than one. The application can be downloaded to the WTRU. The application can perform messaging between the WTRU and the CBP. The application can provide the consumer with an option to share its measurements, and can associate different pricing schemes with the selection. For example, if the user is sharing, the cost of using the service can be lower or free. Otherwise, the cost may be higher. The application can check the available bandwidth of the route the WTRU is using, and if the available bandwidth is not sufficient to maintain the quality of the application, it can suggest (eg, by making a suggestion on the GUI) that the user takes a different route. Figure 2 is a diagram of an example of a separate bandwidth prediction (SBP) system and method. In systems and methods that use Individual Bandwidth Prediction (SBP), a user (eg, a WTRU or a user's mobile device) makes predictions based on their own previous measurements. The difference between SBP and CBP is that there are no CBP servers in the SBP network. Using the SBP system, a DASH client (such as a WTRU) can measure its own bandwidth and can store bandwidth measurements and corresponding locations in its local storage area. For example, a DASH client (e.g., a WTRU) can measure its own bandwidth each time it accesses a location and can store bandwidth measurements and corresponding locations in its native storage area. The DASH client (e.g., the WTRU) may predict the bandwidth of the location before the next access to the location, such as after accessing the location several times. A DASH client (e.g., a WTRU) may request a suitable video segment from a DASH media presence server (e.g., similar to the CBP architecture) using the predicted bandwidth and/or movement. One advantage of the SBP approach is that it is easy to implement and does not require new nodes at the network in order to access the bandwidth information of the LTE network. In the SBP method, a DASH client (e.g., a WTRU) may need to know its bandwidth map, and during the learning phase, bandwidth prediction and/or DASH bit rate selection may be inaccurate. Figure 3 shows the architecture for local prediction and rate adaptation to improve and/or optimize video quality. The current position, time, speed and/or bandwidth is used to predict the speed and/or bandwidth of the upcoming location. Kalman filters can be used to predict speed and/or bandwidth. The state transition parameters can be determined from historical data. The bandwidth, speed prediction, and/or current buffer size can be fed into the bit rate adaptation algorithm to select the appropriate bit rate. Historical data may include the following information: network operator; available bandwidth and/or speed as a function of location and/or time. The local predictor can check the available bandwidth of the WTRU's route. If the available bandwidth is not sufficient to maintain the quality of the call, the local predictor can suggest (eg, by making a suggestion on the GUI) that the user takes a different route. Given the available bandwidth prediction, the WTRU may use the available bandwidth prediction in a variety of ways. If there is too much available bandwidth in some portions of the predicted path and the prediction indicates that the subsequent portion of the path did not have sufficient bandwidth before, the WTRU may use or may plan to use too much of the available portions The bandwidth is used to prefetch what will be used in the later part of the path (assuming the WTRU has sufficient buffer space). This will improve the quality of the content in the future. If there is not too much available bandwidth in some portions of the predicted path, for example, the available bandwidth is already fully used for content to be played in that portion, the WTRU may request that the bit rate reduced content be requested for the portion And this can make some of the available bandwidth unused, and these unused bandwidths can be used to prefetch content that will be played for future portions. This avoids re-buffering. The separate bandwidth prediction method can result in zero communication overhead, which is an advantage over the cooperative bandwidth prediction method. Figure 4 is an illustration of a diagram of a system and method for prefetching data. Current radio access points can predict the routes that the WTRU can take and can notify subsequent radio access points on the route. The notification may include one or more of the following: a predicted time at which the WTRU may enter a subsequent radio access point, a source of data being consumed by the WTRU, what data item the WTRU is consuming, and/or a WTRU is expected to consume in the future What kind of information object. These subsequent radio access points may prefetch data in anticipation that the WTRU will access their respective service areas in the future. The prefetched material may be cached and may be sent when the WTRU enters a service area of a radio access point that has cached the data. For example, Figure 4 shows the architecture of an LTE network. The eNB 1 may inform the eNB 2 when the WTRU may enter the service area of the eNB 2T . The eNB 1 may inform the eNB 2 of the source of the data that the WTRU may need, and the eNB 2 may prefetch the required data. To assist in the transition from eNB 1 to eNB 2, the data prefetched at eNB 2 may overlap with the data prefetched at eNB 1. When the WTRU enters the service area of eNB 2, the WTRU may download data directly from eNB 2, which may reduce RTT and may increase throughput. The WTRU can download data directly from eNB 2 instead of downloading data from the Internet. This method can be applied to, but not limited to, DASH. Content cached by one access point may overlap with content cached by the next access point, which may help to maintain continuity of the content. This can be beneficial if the prediction is inaccurate. The amount of overlap can be a function of prediction inaccuracy. As an example, for the network shown in FIG. 4, as shown in FIG. 5, the content may be divided according to the playback time (for example, in seconds). The first access point eNB 1 may prefetch content from the first second to the fifth second, and the second access point eNB 2 may prefetch content from the fifth second to the ninth second. As shown in Figure 5, the two prefetched content can overlap at the 5th second. Figure 6 is a diagram showing an example of a graph of the relationship between bit rate and time for a transition between eNB 1 and eNB 2 for a WTRU. As shown in Figure 6, assume the WTRU (which can be a DASH video player) at the momentT Enter the service area of eNB 2, and the data buffered by it is played to the timeT' . Without prefetching, the WTRU isT ' Then continue to play low quality video. If prefetching at eNB 2 is enabled, high bit rate video can be prefetched at eNB 2. Since high bit rate video has been prefetched and the high bit rate video is available at the access point, the amount of traffic to the WTRU may increase. Thereby improvingT ' The subsequent video bit rate. The throughput can be increased for the following reasons: The throughput of the TCP connection is determined by the following equation:(1) M is the maximum segment size, RTT is the round trip time, P is the probability of packet loss, and C is the constant determined by TCP implementation. The RTT is the sum of RTT_1 and RTT_2, which are the round-trip time between the UE and the eNB and the round-trip time between the eNB and the Internet server, respectively. For LTE networks, RTT_1 is typically between 30 and 60 milliseconds, and for 5G networks, it is proposed to be less than 1 millisecond. RTT is usually dominated by RTT_2, which can be hundreds of milliseconds when connected through an intercontinental route. When prefetching is enabled, the RTT is reduced to RTT_1, which will increase the throughput. Figure 7 is an illustration of a diagram of signaling between a client (e.g., a WTRU), a DASH media content provider, and a content distribution network (CDN) edge server. The edge server can be co-located with a wireless access point (such as an eNB). The content provider can predict the route based on information provided by the WTRU. The client may send a coverage update, which may include, for example, one or more of the following: an address of the video content (eg, the portion of the requested video content), a bit rate, a bandwidth, a location, and a speed, and / or phone number or other identifier. The client can periodically provide coverage updates to the media server. The content provider can predict the route of the client (e.g., WTRU), decide on the edge server to be pre-cached, and/or can send the address of these edge servers to the client (e.g., the WTRU). The content provider can suggest a bit rate for the client. The content provider can obtain the predicted route from a third party including a location service (such as Google, etc.). This location is available in a number of ways. For example, the phone number associated with the user terminal can be transmitted to a third party location service to query the location of the user terminal. For a single method, the consumer can predict its own movement and can send its future location to the content provider. The media server can pre-cache the media data to the corresponding edge server (eg, based on predicted route information provided by the user). Just a web approach can involve multiple content providers along the route. Cloud computing can be used to reduce delays including RTT, computation time of algorithms, and the like. The WTRU may use the same prediction algorithm and bit rate selection algorithm as described with reference to the SBP method. Historical data on the available bandwidth and speed of one or more WTRUs is stored in the network. The network may predict the future location of the WTRU and/or the time associated with the location. The network can decide which (or which) wireless access point can prefetch content that the WTRU is likely to use in the future. The network can provide the consumer with information about the quality and/or bit rate of the content to be requested. The client (eg, WTRU) can observe its current location, speed and available bandwidth, device type, and/or associated network operator (eg, AT&T or Verizon) and provide an entity to the network (network service) The enhanced node or NSEN) provides this information. NSEN can aggregate this information from one or more clients. NSEN can predict which access point the WTRU can access in the future. NSEN can direct the access point to prefetch content that will most likely be accessed by the WTRU in the future. The NSEN may provide the WTRU with information as to which quality level the WTRU will need in the future (eg, the bit rate of the video). This information can be used along with the available bandwidth observed by the WTRU locally to determine which quality level will be requested. NSEN can construct a graph of expected available bandwidth, for example, based on one or more of location, time, day of the week, network operator, device type. For a particular WTRU, NSEN may fine-grain the available bandwidth using, for example, one or more of the WTRU's current location, speed, available bandwidth, traffic requirements of other devices using the same network, and the number of other devices. Prediction. The available bandwidth and/or vehicle speed at future locations may be predicted based on measurements of current and/or previous trips. The prediction method and system can work in conjunction with both the CBP and SBP architectures. The prediction method and system can include motion prediction and/or bandwidth prediction that predict vehicle speed and available bandwidth at future locations, respectively. Algorithms for motion and bandwidth prediction can be similar. An example of a bandwidth prediction algorithm is described below. It is assumed that the travel route is given and divided into a plurality of segments having an equal length L, for example, L = 300 meters. Vi and Bi are used to represent random variables of vehicle speed and bandwidth at the i-th segment, respectively. Let the random variable bi be the bandwidth measured at the ith segment. Generally, measurements are inaccurate and contain random variations. If you repeat the itinerary to collect historical information, thenFor the first time during the tth tripi The bandwidth measured at each segment. Based on the currently measured bandwidth, with historical measurements, bandwidth prediction can produce a more accurate estimate of the bandwidth and can also predict the available bandwidth in subsequent segments. The prediction method is based on the Kalman filter, which is widely used in vehicle navigation. The bandwidth can be modeled as:(2) for alli ,FromToState transition parameter, andIs process noise, assuming that the process noise is from varianceThe zero-mean Gaussian distribution is extracted. assumedFor allversuswithindependent. In the firsti At the segment, the measurement of the bandwidth is obtained from the following model:(3) where ni is the measurement error, assuming it is extracted from a zero-mean Gaussian distribution with variance qi. It is assumed that ni is independent of all j and Bj, bj and Nj. The parameters in (1) and (2) can be determined from historical data before performing Kalman filtering.,with. The bandwidths bi+1, bi, and bi-1 measured from (1) and (2) can be expressed as:The mean of the measured bandwidth bi+1 can be written as:Due to the independence of the random variables Bi-1, Ni-1 and ni, the variance of the measured bandwidth bi can be obtained according to (4).Due to the independence of the random variables Bi, Ni and ni for all i, the following covariance can be obtained,See above, the mean of the measured bandwidth,varianceAnd covarianceSample mean value of historical data availableSample varianceSample covarianceTo estimate, among themmake. Then the equation becomes: assumedwithIt is known that in fact they can be obtained in the previous steps of the algorithm as described below. The left-hand side in equations (13)-(21) above can pass the function,,,,withTo represent. determine,withSimplify to solve the following optimization problems,The algorithm can be written as described below. The algorithm can be executed offline without increasing the complexity or latency of the DASH layer. parameter,withCan be provided to the DASH layer. In one example, the algorithm includes the following: Example Algorithm 1: Determining the state transition parameters of the noise Ni and ni, respectivelyAnd/or variancewith.Using this parameter, the system and method can use the Kalman filter to predict the bandwidth at the following segments. Let Ki be the Kalman gain at the i-th segment,To estimate the estimated error variance. When the measurement bi is available, the estimate can be updated by:among them,Yes noPrior estimateIs an updated estimate. The updated estimated error variance can be calculated as follows:An a priori estimate for the next segment can be calculated, and the predicted estimated error variance and Kalman gain for the next segment can be calculated:A Kalman filter can be used. Using the measurement of the bi of the i-th segment, the next segment can be predictedspeed. Similar to the bandwidth prediction described above, the vehicle speed can be modeled by the following equation:among them,Is the measurement speed at the i-th segment;FromToState transition parameters, andwithIs process noise and measurement noise, they are independent, and are assumed to have variances respectivelywithZero mean Gaussian distribution extraction. In the system and method, the current segmentation measurement can be predictedSpeed of the next segment. According to the above example algorithm 1 and Kalman filter, the prediction bandwidth of the next segment can be obtained.. Although the available bandwidth can vary and can change relatively quickly in a wireless network in some examples, the same location measured at the same time of day and the same day of the week (eg, or a working day as opposed to a weekend) The bandwidth at the location shows a certain similarity. Based on this observation, the system and method can select the same time of day and the same day of the week as historical data to calculate mi,withAnd optimize the above problem (Ai), Qi-1 and qi. The video bit rate adaptation algorithm can be applied to a variety of applications (eg, DASH or another application). Video bit rate adaptation may use predictions of available bandwidth and/or vehicle speed at future locations based on measurements of current and/or previous trips. For example, in video bit rate adaptation, assume the current segmentation measurementwithIs available and predicts for the next segmentwithIt's useful. The goal of the bit rate adaptation algorithm is to select the bit rate to improve and/or maximize video quality, and this can be achieved without buffer underflow. It is assumed that the length of the segment (for example, each segment) is L meters. In one example, the algorithm optimizes video quality for subsequent M segments. The current buffer size, which is measured instantaneously by the BS, is the video replay time of the buffered data. makewithThe predicted speed and predicted bandwidth for the i+jth segment (when the measurement before the i-th segment (for example, just measurement) is available separately), whereFor. Through the duration of the i+mth segment ()YesThe total information downloaded during the i+m segment isIf the buffer size BS is not greater than the lower bound BS_low, there is a significant probability that rebuffering occurs and the user end can be forced to switch to the lowest bit rate. Otherwise, to avoid re-buffering, use the following:, (36) againstWhere BR is the selected bit rate. According to the above inequality:whenWhen the selected bit rate has an upper bound,whenDo not apply any upper bounds to the BR. The bit rate adaptation algorithm can be as follows. In one example, the algorithm includes the following: __________________________________________________________________Sample algorithm 2 : Targeted Given the predicted speed And predictable available bandwidth And current buffer size BS , determining the upper bound of the video bit rate to avoid re-buffering, and / Or choose a bit rate to maximize video quality. __________________________________________________________________ The Media Presentation Description (MPD) may contain information about the media stream, such as the codec, the duration of the media segment, and/or the resolution and bandwidth of each representation. The maximum bit rate BR_max from Algorithm 2 above can be obtained. The next video representation having the highest bit rate no greater than BR_max can be selected. In the 13th line of the example algorithm 2, the maximum value can replace the available bit rate specified in the MPD file. For example, an MPD file can contain 10 bit rates as follows:Another application is video telephony. Using a video telephony, the WTRU can maintain measurements of available bandwidth and can share the measurement with other users via CBP. When the user makes a video call, the application can check the available bandwidth of the line along which the WTRU moves. If the available bandwidth is not sufficient to maintain the quality of the call, the application can suggest (eg, by making a suggestion on the GUI) that the user takes a different route. The systems and methods described herein can predict available bandwidth based on measurements of current and previous trips. Moreover, the system and method can include applying an algorithm to the video bit rate of the application, the application including DASH, which involves determining the predicted bandwidth and/or considering the current buffer size. The system and method can be implemented in an LTE network or other wireless network. In one example, the WTRU has a self-contained user end. For example, a WTRU may have an enhanced DASH client and/or may be algorithmically programmed to build a historical repository of locations and throughput. The historical database may include any or all of the following: record position history versus time, and recognition mode; record travel speed history and/or speed/position change, etc., and record bandwidth/conveyance history and time Relationship with location. A WTRU user may select video content for streaming (eg, via a website or DASH client or other streaming client) by using any or all of the following: the user obtains content information (eg, DASH) MPD) and begin to stream the content; the user end observes the position status (such as position, speed, progress...); the user end usage history (such as position/delivery mode), content information And/or positional state to predict (eg, and periodically update the predicted) path versus time and/or BW/delivery amount versus time. Using any or all of the foregoing, the user can plan ahead and perform predictive local caches (e.g., prefetch) to improve replay quality and prevent re-buffering. For example, if a portion along the WTRU path is predicted to not have sufficient bandwidth for high quality streaming, the UE may prefetch the high quality version of the required content segment in advance. For example, the WTRU may use too much available bandwidth in the previous portion of the path. This assumes that the WTRU has sufficient buffering for prefetching. Local cache management is considered in the process of implementing the algorithm. If a portion along the WTRU path is predicted not to have sufficient bandwidth for high quality streaming, the WTRU may prefetch the required content segments in advance if there is not too much available bandwidth in the previous portion of the path. Low quality version. No changes may be required on the network side and no special/additional communication between the WTRU and the network is required. This implementation can be implemented entirely within the WTRU via, for example, a downloadable app or an enhanced DASH client. Systems and methods include user-side path prediction using predictive caches in the network. The WTRU may have an enhanced DASH client that communicates with the network to enable predictive prefetching to cache elements (eg, the same location) associated with the network access point. The user terminal can be equipped to perform any or all of the following: record position history versus time, and recognition mode; record travel speed history, speed/position change, etc.; and record bandwidth/conveyance history and The relationship between time and location. The user can select the video content for streaming by using any or all of the following (for example, via a website or a DASH client or other streaming client): the user obtains content information (eg, dash mpd) And start streaming the content; the user observes the location state (such as location, speed, progress) as it passes through the route. . . User-side usage history (eg, location/delivery mode), content information, and/or location status to predict (eg, and periodically update predictions) path versus time; and the client sends to the network An update to the relationship between path and time. The network may determine improved and/or optimized prefetch locations for content segments (eg, specific caches that are co-located with the network access point) and time. The content can be prefetched for what is expected by the user when the user end is within the communication range of the network access point (based on the predicted path and time). The network may prefetch content to a particular network access point cache at a particular bit rate for a predicted available bandwidth of the WTRU at a time when the WTRU may go through the communication range of the network access point. The network may, for example, optionally provide a message to the WTRU indicating one or more preferred bit rates to be requested, which may be based on the network's knowledge and/or pair of available bandwidth at the access point. An understanding of the bit rate that has been predictively cached at the access point. As the WTRU walks through the path, the WTRU may send an update to the network regarding the predicted path and time. The WTRU may request content segmentation to acquire, decode, and replay the content. The WTRU may receive a message from the network indicating one or more preferred bit rates to be requested. The WTRU or network may determine a bit rate to be requested based on any or all of: information about the content (eg, DASH MPD), history of the WTRU's recorded location & bandwidth/delivery amount versus time, And/or based on one or more preferred bit rates transmitted by the network. The WTRU may have a standard DASH client that may not be aware of and will not have special signaling related to the location based prediction function of the network. The WTRU may report observations of location and/or available network bandwidth to entities in the network. This can be part of existing location services and network feedback; this is in contrast to the functionality of the enhanced DASH client. For example, many phones pre-set location services and related reports, or to support other applications. The network can record observations of the location and/or available network bandwidth (and associated observation times) for the consumer. The network aggregates available network bandwidth data from multiple consumers to build a graph of the estimated available network bandwidth. The map can be a function of location, time, and/or days of the week. The WTRU may request streaming content (eg, requesting an MPD; starting a DASH session). The network may predict the WTRU's path based on recorded observations of the WTRU's past location & time and/or based on the WTRU's current location, direction, and/or speed. The network can predict (eg, based on the current location/speed of the WTRU, and the current content segment that the WTRU is requesting) how to prefetch future content to the cache associated with the network access point along the predicted path of the WTRU. The content segment to be prefetched may be based on a prediction segment that the user may be in need of at a predicted time in the range of a particular network access point. The bit rate of the content segment to be acquired may be based on the estimated available network bandwidth at the predicted time and location. The network may, for example, optionally provide a message to the WTRU indicating the content segment and/or the bit rate that the WTRU should request (eg, its recommended WTRU requesting a suitable bit rate for the content segment). These content segments and/or bit rates may be based on a bit rate that the network has selected to prefetch to the cache at a given network access point. The message can be explicit signaling of the recommended bit rate. The message can take the form of an updated MPD. For example, an updated MPD may limit the available bit rate listed for a given content segment. The limited available bit rate of the updated MPD may reflect one or more bit rates of the content segments prefetched and available in the cache. Modifications may not be made to the DASH client on the WTRU. The WTRU may continue to travel along the path and may receive the required video segments as it travels. The WTRU may receive, decode, and replay video segments. The test was performed using an example of the SBP method (for example, as described with reference to Figure 2). In this test, the DASH MPD server is running on Ubuntu 14. The Apache web server on 04, which also hosts the Javascript program DASH. Sj. In this test, the WTRU is a Samsung Galaxy Tab 4 that accesses the Verizon LTE network. The video sequence "Big Buck Bunny" was used in the test, and the video sequence was passed through DASH. Sj program provided. The video sequence used has a duration of approximately 600 seconds, and the video segment (e.g., each video segment) contains approximately three seconds of video content. There are 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. In the experiment, two routes were selected in the San Diego area. Both routes have the same starting and ending points. Most of the first route is on the highway, while the other route is mainly on the local street. Between September 2014 and January 2015, more than thirty-five repeated experiments were conducted in both directions on both routes. The experiment was conducted in both peak and off-peak hours, and as a result, each lasted from about 20 minutes to about 50 minutes. Each route is divided into sections of approximately 300 meters. Historical data is collected (this mimics the accumulation of measurements), such as people commuting to work regularly. For each route, there is a corresponding collection of historical data. The data includes location and speed, which is provided by the GPS device on the user's side, with an accuracy of 4 meters. The data also includes the frequency obtained by dividing the size of the downloaded data by the duration between the request and the reception. width. In a segment, more than one measurement can be obtained, and if so, the average of all measurements in the segment is used as a measure for that segment. Using historical data, the above algorithm 1 can be run offline to determine the parameters in the state transition model and they are fed into the DASH player. By going to DASH. Js uses Kalman filters and bit rate adaptation algorithms to implement predictions. Evaluate performance. Consider the accuracy of the bandwidth prediction algorithm. In Fig. 8, a cumulative distribution function (CDF) showing the percentage of the difference between the predicted bandwidth and the measured bandwidth is shown. Almost 60% of the predicted errors are less than 20%. Because the video bit rate is quantized to 0. With 10 levels from 23Mbps to 6Mbps, the bit rate selection algorithm can still make the right decision with less than 20% error. In Figures 9 and 10, the video bit rate selected by the algorithm and the Thang algorithm is shown under the same channel implementation. The Thang algorithm calculates the moving average of the measured bandwidth as a prediction and then selects the maximum available bit rate that is not greater than the prediction. The performance of the Thang algorithm is obtained by analogy using historical data (available bandwidth as a function of time/segment) obtained from experiments run using the above highway data. The example of Fig. 10 shows that the average of the bit rates selected by the example of the algorithm is greater than the average of the bit rates selected by the Thang algorithm, and in Fig. 11, the two algorithms are adopted. The CDF of the video bit rate confirms this. The disclosed algorithm provides a smoother bit rate selection compared to the Thang algorithm, where the switching probability for the disclosed algorithm is 6. 1%, and for the Thang algorithm is 27. 8%. The system and method predict the available bandwidth and can do so based on measurements of current and previous trips. The system and method can provide a video bit rate adaptation algorithm for DASH. The system and method can consider the predicted bandwidth and/or the current buffer size. Tests conducted in an LTE network show how the disclosed system and method are effective in improving the QoE of the video client. FIG. 12A is a schematic diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 can enable multiple wireless users to access the content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can use 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. As shown in FIG. 12A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (generally or collectively referred to as WTRU 102), Radio Access Network (RAN) 103/104/ 105, core network 106/107/109, public switched telephone network (PSTN) 108, internet 110 and other networks 112, but it will be understood that the disclosed embodiments can implement any number of WTRUs, base stations , network and / or network components. 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), WTRUs, fixed or mobile subscriber units, pagers, mobile phones, personal digital assistants. (PDA), smart phones, portable computers, netbooks, personal computers, wireless sensors, consumer electronics, and more. The communication system 100 can also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b can be configured to have a wireless interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (eg, core network 106/ Any type of device of 107/109, Internet 110, and/or network 112). For example, base stations 114a, 114b may be base station transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, website controller, access point (AP), wireless router, and the like. Although base stations 114a, 114b are each depicted as a single component, base stations 114a, 114b may include any number of interconnected base stations and/or network elements. The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or networks such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. Road component (not shown). Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as cells (not shown). Cells can also be divided into cell sectors. For example, a cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. Base station 114a may use multiple input multiple output (MIMO) technology and may use multiple transceivers for each sector of the cell. The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the null planes 115/116/117, which may be any suitable wireless communication link ( For example, radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The null intermediaries 115/116/117 can be established using any suitable radio access technology (RAT). More specifically, as noted above, communication system 100 can be a multiple access system and can utilize one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 103/104/105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA ( WCDMA) to establish an empty intermediate plane 115/116/117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA). 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 use Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) Establish an empty intermediary plane 115/116/117. The base station 114a and the WTRUs 102a, 102b, 102c may implement such as IEEE 802. 16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856) Radio technologies such as Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN). The base station 114b in Figure 12A may be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and any suitable RAT may be used for facilitating in, for example, a business district, home, vehicle, campus A wireless connection to a local area of the class. In one embodiment, base station 114b and WTRUs 102c, 102d may implement such as IEEE 802. A radio technology such as 11 to establish a wireless local area network (WLAN). The base station 114b and the WTRUs 102c, 102d may implement such as IEEE 802. Radio technology such as 15 to establish a wireless personal area network (WPAN). Base station 114b and WTRUs 102c, 102d may use cell-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocell cells or femtocells. As shown in FIG. 12A, the base station 114b can have a direct connection to the Internet 110. Thus, base station 114b can access Internet 110 without going through core network 106/107/109. The RAN 103/104/105 can communicate with a core network 106/107/109, which can be configured to voice, data, application, and/or Voice over Internet Protocol (VoIP) services. Any type of network is provided to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 can provide call control, billing services, mobile location based services, prepaid calling, internetworking, video distribution, etc., and/or perform advanced security functions such as users. verification. Although not shown in FIG. 12A, the RAN 103/104/105 and/or the core network 106/107/109 may communicate directly or indirectly with other RANs that use the same RAN 103/104/105 RAT or different RAT. For example, in addition to being connected to the RAN 103/104/105, which may employ E-UTRA radio technology, the core network 106/107/109 may also be in communication with other RANs (not shown) that use GSM radio technology. The core network 106/107/109 can also be used 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 a circuit switched telephone network that provides Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use public communication protocols such as transmission control in a Transmission Control Protocol (TCP)/Internet Protocol (IP) Internet Protocol Suite. Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP). The network 112 can include a wireless or wired communication network that is owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same RAT as RAN 103/104/105 or a different RAT. Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may be configured to communicate with different wireless networks over different wireless links. Multiple transceivers for communication. For example, the WTRU 102c shown in FIG. 12A can be configured to communicate with a base station 114a that can use a cell-based radio technology and with a base station 114b that can use an IEEE 802 radio technology. FIG. 12B is a system diagram of an example WTRU 102. As shown in FIG. 12B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a numeric keypad 126, a display/trackpad 128, a non-removable memory 130, a removable memory. Body 132, power source 134, Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It will be understood that the WTRU 102 may include any subset of the above-described elements while remaining consistent with the embodiments. Likewise, embodiments may envision nodes (e.g., transceiver stations (BTS), Node Bs, website controllers, access points (APs), home node Bs) that base stations 114a and 114b and/or base stations 114a and 114b may represent. Evolved Home Node B (eNode B), Home Evolved Node B (HeNB), Home Evolved Node B Gateway, Proxy Server Node, etc. may include some or all of the elements of Figure 12B and the elements described herein. . The processor 118 can 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 associated with the DSP core, a controller, a micro control , dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), state machine, etc. The processor 118 can perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although processor 118 and transceiver 120 are depicted as separate components in FIG. 12B, processor 118 and transceiver 120 may be integrated together into an electronic package or wafer. The transmit/receive element 122 can be configured to transmit signals to or from the base station (e.g., base station 114a) via the null planes 115/116/117. For example, the transmit/receive element 122 can be an antenna configured to transmit and/or receive RF signals. Transmit/receive element 122 may be a transmitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. The transmit/receive element 122 can be configured to transmit and receive both RF signals and optical signals. The transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals. Although the transmit/receive element 122 is depicted as a single element in FIG. 12B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may use 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/or receiving wireless signals over the null intermediaries 115/116/117. The transceiver 120 can be configured to modulate a signal to be transmitted by the transmit/receive element 122 and configured to demodulate a signal received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802. 11. The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a numeric keypad 126, and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), And the user input data can be received from the above device. The processor 118 can also output user profiles to the speaker/microphone 124, the numeric keypad 126, and/or the display/trackpad 128. In addition, processor 118 can access information from any type of suitable memory and store the data in any type of suitable memory, such as non-removable memory 130 and/or removable memory. Body 132. The non-removable memory 130 can include random access memory (RAM), read only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 can include a Subscriber Identity Module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access data from memory that is not physically located on the WTRU 102 (e.g., on a server or a home computer (not shown), and store data in the memory. The processor 118 can receive power from the power source 134 and can be configured to distribute the power to other components in the WTRU 102 and/or to control power to other elements in the WTRU 102. Power source 134 can be any device suitable for powering WTRU 102. For example, the power source 134 may include one or more dry cells (nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like. The processor 118 may also be coupled to a GPS chipset 136 that may be configured to provide location information (eg, longitude and latitude) with respect to the current location of the WTRU 102. The WTRU 102 may receive information location information from or to replace the GPS chipset 136 from the base station (e.g., base station 114a, 114b) via the null plane 115/116/117, and/or based on two or more neighbors. The timing of the signal received by the base station determines its position. While remaining consistent with the embodiments, the WTRU 102 may obtain location information by any suitable location determination method. The processor 118 can also be coupled to other peripheral devices 138, which can include one or more software and/or hardware modules that provide additional features, functionality, and/or wireless or wired connections. For example, peripheral device 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, and a hands-free Headphones, Bluetooth® modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, and more. Figure 12C is a diagram of an example system of RAN 103 and core network 106, in accordance with one embodiment. As described above, the RAN 103 can communicate with the WTRUs 102a, 102b, and 102c over the null plane 115 using UTRA radio technology. The RAN 103 can also communicate with the core network 106. As shown in FIG. 12C, the RAN 103 may include Node Bs 140a, 140b, 140c, each of which may include one or more for communicating with the WTRUs 102a, 102b, 102c over the null plane 115. Transceiver. Each of Node Bs 140a, 140b, 140c can be associated with a particular cell (not shown) in RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be understood that the RAN 103 may include any number of Node Bs and RNCs while remaining consistent with the embodiments. As shown in Figure 12C, Node Bs 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c can communicate with respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b can communicate with each other via the Iur interface. Each of the RNCs 142a, 142b can be configured to control the respective Node Bs 140a, 140b, 140c to which they are connected. In addition, each of the RNCs 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like. 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. Although each of the foregoing elements is described as being part of the core network 106, any of these elements may be owned and/or operated by entities other than the core network operator. The RNC 142a in the RAN 103 can be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and conventional route communication devices. The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to, for example, the packet switched network of the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and the IP-enabled devices. As noted above, the core network 106 can also be connected to the network 112, which can include other wired or wireless networks owned and/or operated by other service providers. Figure 12D is a system diagram of RAN 104 and core network 107, in accordance with one embodiment. As described above, the RAN 104 can communicate with the WTRUs 102a, 102b, and 102c over the null plane 116 using E-UTRA radio technology. The RAN 104 can communicate with the core network 107. The RAN 104 may include eNodeBs 160a, 160b, 160c, it being understood that the RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each of the eNodeBs 160a, 160b, 160c can include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the null plane 116. The eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, in the uplink and/or downlink Schedule the user, etc. As shown in Fig. 12D, the eNodeBs 160a, 160b, 160c can communicate with each other on the X2 interface. The core network 107 shown in FIG. 12D may include a mobility management gateway (MME) 162, a service gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is described as being part of the core network 107, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator. The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating the users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular service gateway during initial attachment of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide control plane functionality for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA. The service gateway 164 can be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The service gateway 164 can generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The service gateway 164 may also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging, managing and storing the WTRUs 102a, 102b when downlink data is available to the WTRUs 102a, 102b, 102c , the context of 102c, and so on. The service gateway 164 may also be coupled to the PDN 166, which may access the WTRUs 102a, 102b, 102c to a packet switched network, such as the Internet 110, to facilitate the WTRUs 102a, 102b, 102c and IP-enabled devices. Communication between. The core network 107 can facilitate communication with other networks. For example, core network 107 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as PSTN 108, to facilitate communications between WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between core network 107 and PSTN 108 or may be in communication with the IP gateway. In addition, core network 107 can provide WTRUs 102a, 102b, 102c with access to network 112, which can include other wired or wireless networks that are owned and/or operated by other service providers. Figure 12E is a system diagram of RAN 105 and core network 109, in accordance with one embodiment. The RAN 105 can be utilizing IEEE 802. An access service network (ASN) in which the radio technology communicates with the WTRUs 102a, 102b, 102c over the null plane 117. As will be discussed further below, the communication links between the different functional entities in the WTRUs 102a, 102b, 102c, RAN 105, and core network 109 may be defined as reference points. As shown in FIG. 12E, the RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182, but it will be understood that the RAN 105 may include any number of base stations while remaining consistent with the embodiments. And ASN gateway. The base stations 180a, 180b, 180c are each 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 null plane 117 . In one embodiment, base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, base station 180a can use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 can act as a traffic aggregation point and can be responsible for paging, caching subscriber profiles, routing to the core network 109, and the like. The null interfacing plane 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined to implement IEEE 802. 16 specification R1 reference point. In addition, each of the WTRUs 102a, 102b, 102c can 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 can be defined as an R2 reference point that can be used for authentication, authorization, IP host configuration management, and/or mobility management. The communication link between each of the base stations 180a, 180b, 180c can be defined to include an R8 reference point for facilitating the agreement between the WTRU handover and the data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 can be defined as an R6 reference point. The R6 reference point can include an agreement to facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c. As shown in FIG. 12E, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined, for example, as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a Mobility IP Home Agent (MIP-HA) 184, an Authentication, Authorization, Accounting (AAA) server 186, and a gateway 188. While each of the above elements is described as being part of the core network 109, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator. 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 a packet switched network, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and support for user services. Gateway 188 facilitates interworking with other networks. For example, gateway 188 can provide WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as PSTN 108, to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. In addition, gateway 188 can provide access to network 112 to WTRUs 102a, 102b, 102c, which can include other wired or wireless networks that are owned or operated by other service providers. Although not shown in FIG. 12E, it should be understood that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and other ASNs may be defined as an R4 reference point, which may include a protocol for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between the core network 109 and other core networks can be defined as an R5 reference, which can include protocols for facilitating interworking between the home core network and the access core network. Although features and elements have been described above in a particular combination, those skilled in the art will understand that each feature or element can be used alone or in various combinations with other features and elements. Moreover, the methods described herein can 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 a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor storage devices, such as internal magnetic disks and removable disks. Magnetic media, magneto-optical media, and optical media (such as CD-ROM discs and digital versatile discs (DVD)). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host.

1, 2‧‧‧ users 100‧‧‧example communication system 102‧‧‧Wireless Transmitting/Receiving Unit (WTRU) 103, 104, 105‧‧‧ Radio Access Network (RAN) 106, 107, 109‧‧‧ core network 108‧‧‧Public Switched Telephone Network (PSTN) 110‧‧‧Internet 112‧‧‧Other networks 114, 180‧‧‧ base station 115, 116, 117‧‧ ‧ empty mediation 118‧‧‧Processor 120‧‧‧Transceiver 122‧‧‧transmit/receive components 124‧‧‧Speaker/Microphone 126‧‧‧Digital keyboard 128‧‧‧Display/Touchpad 130‧‧‧immovable memory 132‧‧‧Removable memory 134‧‧‧Power supply 136‧‧‧GPS chipset 138‧‧‧ Peripherals 140, 160‧‧‧e Node B 142‧‧‧ Radio Network Controller (RNC) 144‧‧‧Media Gateway (MGW) 146‧‧‧Mobile Exchange Center (MSC) 148‧‧‧Serving GPRS Support Node (SGSN) 150‧‧‧Gateway GPRS Support Node 162‧‧‧Mobility Management Gateway (MME) 164‧‧‧ service gateway 166‧‧‧ Packet Data Network (PDN) Gateway 182‧‧‧Access Service Network (ASN) Gateway 184‧‧‧Mobile IP Home Agent (MIP-HA) 186‧‧‧Authentication, Authorization, Accounting (AAA) Server 188‧‧ ‧ gateway CDF‧‧‧ cumulative distribution function DASH‧‧‧Dynamic adaptive streaming GPS‧‧‧Global Positioning System IP‧‧‧Internet Protocol IuCS, IuPS, iur, Iub, S1, X2‧‧ interface MPD‧‧‧DASH media presentation description R‧‧‧ reference point T‧‧‧ moments UE‧‧‧User equipment

Figure 1 is an example diagram of cooperative bandwidth prediction. Figure 2 is an example diagram of individual bandwidth prediction. Figure 3 is an example diagram of prediction and rate adaptation. Figure 4 is an illustration of prefetched data. Figure 5 is an illustration of the prefetched data. Figure 6 is an illustration of the effect of prefetching on the bit rate. Figure 7 is an exemplary diagram of signaling between the edge server, the consumer, and the DASH media content provider. Fig. 8 is a diagram showing an example of a cumulative distribution function (CDF) of the error of the bandwidth prediction. Figure 9 is a diagram showing an example of the WTRU's video bit rate. Figure 10 is a diagram showing an example of the WTRU's video bit rate. Figure 11 is an exemplary diagram showing the CDF of the video bit rate. Figure 12A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. Figure 12B is a system diagram of an example wireless transmit/receive unit (WTRU) that can be used in the communication system shown in Figure 12A. Figure 12C is a system diagram of an example radio access network and an example core network that can be used in the communication system shown in Figure 12A. Figure 12D is a system diagram of another example radio access network and example core network that may be used in the communication system shown in Figure 12A. Figure 12E is a system diagram of another example radio access network and example core network that may be used in the communication system shown in Figure 12A.

Claims (27)

A method for adaptively streaming video content using a wireless transmit/receive unit (WTRU), the method comprising: determining current information associated with the WTRU, the current information including a location, a speed, a time, At least one of a data throughput and a date; comparing the current information to information previously determined for the WTRU; predicting a future location of the WTRU; predicting an available network bandwidth at the future location; A one-bit rate at which the WTRU requests a content segment is determined based on the predicted available network bandwidth for the predicted future location. The method of claim 1, wherein the method further comprises requesting the content segment at the determined bit rate. The method of claim 1, wherein the method further comprises determining the current buffer size. The method of claim 1, further comprising: requesting additional content segments, and if the predicted future location will have a relatively small available network bandwidth, then caching the additional content for subsequent replays Segmentation. The method of claim 1, further comprising applying a Kalman filter to predict a future location of the WTRU. The method of claim 5, wherein the future location of the WTRU is predicted by predicting the speed. The method of claim 1, wherein the future of the WTRU is predicted based on at least one of a previously determined location and a speed, a time, and a date associated with the previously determined location position. The method of claim 7, wherein the WTRU determines at least the future location, the previously determined location, a speed associated with the previously determined location, a time, and a date. One. The method of claim 1, wherein the future location of the WTRU is adjusted based on a subsequent determination of a location and at least one of a speed, a time, and a date associated with the location . The method of claim 1, wherein the plurality of future locations of the WTRU are predicted. The method of claim 1, further comprising applying a Kalman filter to predict the available network bandwidth at the future location of the WTRU. The method of claim 1, wherein the method further comprises: drawing a map of the location and the reappearance pattern of the available network bandwidth. The method of claim 1, wherein the method further comprises transmitting an alert when predicting that the future location will have a relatively small available network bandwidth. A wireless transmit receive unit (WTRU), the WTRU comprising: a processor having executable instructions for: determining current information associated with the WTRU, the current information including a location, a speed, Predicting at least one of a time, a data throughput, and a date; comparing the current information to information previously determined for the WTRU; predicting a future location of the WTRU; predicting an available network at the future location a bandwidth; and determining a one-bit rate at which the WTRU requests a content segment based on the predicted available network bandwidth for the predicted future location. A WTRU as claimed in claim 14, wherein the processor has executable instructions for requesting the content segment at the determined bit rate. The WTRU of claim 14, wherein the processor has executable instructions for determining a current buffer size. A WTRU as claimed in claim 14, wherein the processor has executable instructions for requesting additional content segments, and if the future location is predicted to have a relatively small available network bandwidth, The additional content segment is cached for subsequent replays. A WTRU as claimed in claim 14, wherein the processor has executable instructions for applying a Kalman filter to predict a future location of the WTRU. A WTRU as claimed in claim 18, wherein the future location of the WTRU is predicted by predicting the speed. The WTRU of claim 14, wherein the future location of the WTRU is predicted based on at least one of a previously determined location and a speed, a time, and a date associated with the previously determined location. The WTRU as claimed in claim 20, wherein the WTRU determines at least one of the future location, the previously determined location, and a speed, a time, and a date associated with the previously determined location. . The WTRU of claim 14, wherein the future location of the WTRU is adjusted based on a subsequent determination of a location and at least one of a speed, a time, and a date associated with the location. The WTRU of claim 14, wherein the plurality of future locations of the WTRU are predicted. A WTRU as claimed in claim 14, wherein the processor has executable instructions for: applying a Kalman filter to predict the available network bandwidth at the future location of the WTRU . The WTRU as claimed in claim 14, wherein the processor has a map for executable instructions: a rendering location and a re-emergence mode of available network bandwidth. A WTRU as claimed in claim 14, wherein the processor has executable instructions for transmitting an alert when predicting that the future location will have a relatively small available network bandwidth. A method for adaptively streaming video content using a wireless transmit/receive unit (WTRU), the method comprising: predicting a future location of the WTRU; predicting based on information previously measured by the WTRU at the future location An available network bandwidth at the future location; and determining a one-bit rate at which the WTRU requests a content segment based on the predicted available network bandwidth for the future location.