JP2015516702A - Mobile video distribution - Google Patents

Abstract

A method and apparatus method for mobile video delivery, including a computer program product, includes a request for initiating progressive download of a video object in a mobile network comprising at least a core element and one or more evolved Node Bs (eNBs). , Dividing the requested video object into self-contained independent video segments, translating each of the self-contained independent video segments for different rates, Delivering segments from rate buckets that meet current network conditions determined by width estimation. [Selection] Figure 3

Description

  The present invention relates generally to wireless networks, and more specifically to mobile video delivery.

  In general, progressive download refers to video delivered by a regular Hypertext Transfer Protocol (HTTP) web server rather than a streaming server. In most cases, the video delivered using this technique is stored on the viewer's hard drive as it is received, which is then played from the hard drive. ,. In contrast, streaming video is usually not stored locally (also called a cache), so the viewer can smooth it as if the viewer cannot read and play it in real time. Can not play at all.

  HTTP progressive download is the most common form of delivering video from the Internet today. Unfortunately, this delivery method does not respond to changing network conditions, which can affect the end user experience. Consider the case where an HTTP PD video object is encoded in 720p. If the network conditions are bad, the video will take a long time to download and the video player will be choked while waiting for additional frames. . For such conditions, the object must be coded at a lower rate (probably 360p). Similarly, if the network conditions improve, the streamer must begin sending higher quality video segments.

  The following presents a simplified summary of the innovation in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. This is not intended to identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

  The present invention provides a method and apparatus including a computer program product for mobile video delivery.

  In general, in one aspect, the invention is required to receive a request to initiate a progressive download of a video object in a mobile network comprising at least a core element and one or more evolved Node Bs (eNBs). Splitting the video object into self-contained independent video segments, translating each of the self-contained independent video segments to a different rate, and current determination as determined by bandwidth estimation Delivering a segment from a rate bucket that matches network conditions.

  In another aspect, the invention is a server in a mobile network, one or more central processing units (CPUs) and a memory, the memory including an operating system (OS) and a mobile video delivery process. The mobile video delivery process receives a request to initiate progressive download of a video object, divides the requested video object into self-contained independent video segments, and for different rates Translating each of the self-contained independent video segments and delivering the segments from a rate bucket that matches current network conditions determined by bandwidth estimation Features a server.

  Other features and advantages of the invention will be apparent from the following description and the claims.

  The invention will be more fully understood by reference to the following detailed description, taken in conjunction with the following drawings, in which:

It is a block diagram. It is a block diagram. It is a flowchart. It is a block diagram.

  The subject innovation will now be described with reference to the drawings, wherein like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.

  As used in this application, the terms “component”, “system”, “platform”, etc. refer to computer-related components, or components related to an operable machine having one or more specific functionalities. Can point. The components disclosed herein can be either hardware, a combination of hardware and software, software, or running software. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may exist in the course of execution and / or threads, components may be localized on one computer and / or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. A component may include one or more data packets (e.g., interoperating with other components in a local system, distributed system, and / or communicating with other systems via signals through a network such as the Internet, May communicate via local and / or remote processes, such as following a signal having data from one component).

  In addition, the term “or / or” is intended to mean an inclusive “or / or” rather than an exclusive “or / or”. That is, unless otherwise specified or apparent from the context, “X adopts A or / or B” is intended to mean any natural inclusive substitution. That is, when X employs A, X employs B, or X employs both A and B, "X employs A or / or B" Is also satisfied under. Furthermore, the articles “a” and “an”, as used in the subject specification and accompanying drawings, generally refer to “one or more” unless otherwise specified or apparent from the context. Should be interpreted to mean.

  In addition, terms such as “user equipment”, “mobile station”, “mobile”, “subscriber station”, “communication device”, “access terminal”, “terminal”, “handset”, and similar terminology, A wireless device (e.g., a mobile phone, utilized by a subscriber or user of a wireless communication service to receive or communicate data, control, voice, video, sound, games, or virtually any data or signal stream Smart phone, computer, personal digital assistant (PDA), set top box, Internet protocol television (IPTV), electronic game device, printer, etc.). The foregoing terms are used interchangeably in the subject specification and the associated drawings. Similarly, the terms “access point”, “base station”, “node B”, “evolved node B”, “home node B (HNB)”, etc. are used interchangeably in the subject application, and data, Refers to a wireless network component or device that supplies or receives control, voice, video, sound, games, or virtually any data or signal stream from a series of subscriber stations. Data and signal streams can be packetized or flow in frames.

  Further, the terms “user”, “subscriber”, “customer”, etc. are used interchangeably throughout the subject specification unless the context requires specific distinction (s) between the terms. .

  The invention described herein is independent of access technologies, including Global System for Mobile (GSM), Code Division Multiple Access (CDMA), Long Term Evolution (LTE), WiMAX, etc. Applies to all wireless networks. For ease of explanation, the present invention is described in a 4G network environment.

  As shown in FIG. 1, an exemplary mobile network 10 includes user equipment (UE) 12, such as a smartphone. Other examples of US12 include mobile phones, computers, personal digital assistants (PDAs), set-top boxes, Internet protocol television (IPTV), electronic game devices, printers, tablets, WiFi hotspots, etc. It is not limited. The UE 12 is wirelessly linked to the evolved Node B (eNB) 14. The eNB 14 is a radio part of the cell site. A single eNB may contain several radio transmitters, receivers, control sections, and a power source. The eNB 14 is backhauled to the metro Ethernet ring 16, which includes a mobility management entity (MME) 18 and a serving gateway (SGW) 20. Backhaul is the process of transferring a packet or communication signal over a relatively long distance to a separate location for processing. The SGW 20 routes and forwards user data packets while also acting as a mobility anchor for the user plane during handover between eNodeBs.

  The SGW 20 is linked to the Internet Protocol (IP) backbone 22. The IP backbone 22 includes links to an online charging system (OCS) 24, an offline charging subsystem (OFCS) 26, and a policy control and charging function (PCRF) 28. In general, OCS 24 is a series of interconnected network elements that allow billing identification, evaluation, and posting in real time (or near real time). The OFCS 26 receives billing data in the form of call detail records (CDRs) and Diameter accounting messages from the network elements after the subscriber has incurred network resource usage costs.

  The IP backbone 22 includes a network server 30 that implements a virtual open wireless service software architecture for 3G and 4G mobile networks. The network server 30 is linked to a web server 32 through an Internet service provider (ISP) 34.

  As shown in FIG. 2, the network server 30 includes at least a central processing unit (CPU) 50 and a memory 52. The memory 52 includes at least an operating system (OS) 54, such as Linux, and a mobile video delivery process 100 described below.

  As shown in FIG. 3, the mobile video delivery process 100 includes receiving a request to initiate progressive download of a video object (102).

  The mobile video delivery process 100 divides the requested video object into self-contained independent video segments (104).

  The mobile video delivery process 100 translates each of the self-contained independent video segments for different rates (106).

  The mobile video delivery process 100 delivers segments from rate buckets that match current network conditions determined by bandwidth estimation (108).

  As described above, the mobile video distribution process 100 is a unit in which each segment can play multimedia content such as flash video (FLV video) (ie, starting from a key frame such as an I frame). Divide into smaller chunks (104). Different bit rate versions (types) for each segment are created so that the media server can select the appropriate version (type) for segment transmission as the available bandwidth changes, Registered on the media server.

  For example, for FLV video streaming over Hypertext Transfer Protocol (HTTP), the FLV video header has a video file size based on the highest bit rate content. This size is also used for the content size header field of the HTTP response header if chunked encoding is not supported by the HTTP server or client. At each segment transmission interval, the HTTP server uses bandwidth estimation techniques to estimate the available bandwidth of the Transmission Control Protocol (TCP) link and best fits the estimated TCP link bandwidth. Select the segment version you want.

  The HTTP media server functions as an HTTP media proxy server deployed in the 3G, 4G access network (AN) behind the PGW or PDSN as part of the AN infrastructure, and more information about client devices or service plans And the upper limit of content for the device can be determined accordingly. For example, due to the limited screen size of the device, there is no need to stream HD quality video to a smartphone. Thus, the media server is able to use, but not even attempt to supply, high resolution (HD) quality media segments.

  Bandwidth estimation can include one of several methods. For example, the bandwidth estimation may be a TCP-based bandwidth estimation method that is independent of the wireless access protocol. In this example, bandwidth estimation is performed by the media server without the assistance of the media player on the other side by monitoring the TCP socket queue length of the media server. The proxy server can use any of the following data and techniques in determining the bandwidth of the client's TCP connection. First, the TCP socket queue length is obtained periodically to determine the drain rate. Second, at the socket queue length, an active queue management (AQM) process such as a RED or Pi controller is run to detect upcoming congestion on the TCP link and estimate the bandwidth.

  This TCP link bandwidth estimation technique is guaranteed to be useful for the AN HTTP media proxy server, since the TCP connection is terminated at the mobile device, which is not the case for a generic HTTP media server outside the AN. . FIG. 4 depicts the behavior of the server.

  Another bandwidth estimation process that can be employed is X2 interface based bandwidth estimation for LTE networks. The method may be used by core elements such as SGW / PGW / video optimizer to determine cell load on an eNB (base station) in an LTE network. Typically, congestion occurs on the air interface, so this information reflects a relatively accurate picture of the bandwidth available in the access network. The LTE architecture does not specify any way in which this information is exchanged between the access and core networks, so the present invention takes advantage of the X2 Application Protocol (X2AP) interface on the eNB where cell loading information is exchanged. Either of the two methods can be used. In the first method, the core network element implements the X2AP protocol with the eNB. In the second method, the core network element functions as a router, and all communication between any eNBs passes through the core network element. The core network element then intercepts X2 traffic between eNBs to determine cell loading.

  In general, the X2AP protocol runs between any two eNBs. X2AP addresses global procedures and user equipment (UE) mobility procedures within E-UTRAN and provides the following functions:

  Function: Mobility management

  Basic procedures: (a) handover preparation, (b) SN state transfer, (c) UE context release, and (d) handover cancellation

  Function: Load management

  Basic procedure: (a) Load instruction, (b) Resource status report start, and (c) Resource status report

  Function: Report general error conditions

  Basic procedure: Error indication

  Function: Reset X2

  Basic procedure: Reset

  Function: Setup X2

  Basic procedure: X2 setup

  Function: eNB configuration update

  Basic procedure: (a) eNB configuration update and (b) cell activation

  Function: Mobility parameter management

  Basic procedure: Changing mobility settings

  Function: Mobility robustness optimization

  Basic procedure: (a) Radio link failure indication, and (b) Handover report

  Function: Energy saving

  Basic procedure: (a) eNB configuration update and (b) cell activation

  In the first method, the core network element establishes an X2AP protocol with each eNB of interest. The protocol of interest is load management, and the following messages are of interest:

  Load instruction: The eNB initiates the procedure by sending a LOAD information message to the eNB controlling the in-frequency neighbor cell. The IE of interest is the “UL interference overload indication IE”, which indicates the level of interference experienced by the indicated cell on all resource blocks.

  Resource status reporting start: This is the procedure used by an eNB to request a report of load measurements to another eNB.

  In the request message, the requester can request a radio resource load, a hardware load, and an S1 load IE that contains the appropriate load information experienced on the cell. The load state is either low load, medium load, high load, or overload.

  These responses can be generated periodically based on the registration scheme set in the request message and can be canceled if necessary.

  In the second method, all X1AP messages are routed through the core network element, i.e. the core network element is used to provide connectivity across eNBs. The message of interest is intercepted and the rest is passed. Cell loading information is obtained by intercepting these messages.

  Various implementations of the systems and techniques described herein may be implemented in digital electronic circuits, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. Can be done. These various implementations are dedicated or general purpose, coupled to receive and transmit data and instructions to and from the storage system, at least one input device, and at least one output device. Possible implementations may include implementations in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor.

  These computer programs (also known as programs, software, software applications or code) contain machine instructions for programmable processors, in high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages Can be implemented. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to a machine-readable medium that receives machine instructions as a machine-readable signal. Any computer program product, apparatus, and / or device (eg, magnetic disk, optical disk, memory, programmable logic device (used to provide machine instructions and / or data to a programmable processor) The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

  In order to provide user interaction, the systems and techniques described herein include a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user. It can be implemented on a computer with a keyboard and pointing device (eg, a mouse or trackball) that can provide input to the computer. Other types of devices can also be used to provide interaction with the user, for example, the feedback provided to the user can be any form of sensory feedback (eg, visual feedback, audio feedback, or Tactile feedback) and input from the user can be received in any form, including acoustic, spoken language, or tactile input.

  The systems and techniques described herein include a back-end component (eg, a data server), or include a middleware component (eg, an application server), or a front-end component (eg, through which a user may Any of the backend, middleware, or frontend components in a computing system, including a graphical user interface or a client computer with a web browser) that can interact with the system and technology implementation described in FIG. Can be implemented in combination. The components of the system can be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

  The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship between the client and the server is caused by a computer program that runs on each computer and has a client-server relationship with each other.

  The above description is not intended to be a comprehensive list of all possible implementations consistent with this disclosure or all possible variations of the described implementations. Several implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the systems, devices, methods, and techniques described herein. For example, the various forms of flow shown above can be used with sorted, added, or deleted steps. Accordingly, other implementations are within the scope of the following claims.

Claims (18)

Receiving a request to initiate progressive download of a video object in a mobile network comprising at least a core element and one or more evolved Node Bs (eNBs);
Dividing the requested video object into self-contained independent video segments;
Translating each of the self-contained independent video segments for different rates;
Delivering a segment from a rate bucket that matches a current network condition determined by bandwidth estimation.
The method of claim 1, wherein each of the self-contained independent video segments is a playable unit.
Translating each of the self-contained independent video segments for different rates allows the media server to select the appropriate version for segment transmission as the available bandwidth changes. The method of claim 1, further comprising: registering each of the different bit rate versions with the media server so that
The method of claim 1, wherein the bandwidth estimation comprises bandwidth estimation based on a transmission control protocol (TCP).
The method of claim 4, wherein TCP based bandwidth estimation comprises monitoring a media server's TCP socket queue length.
Monitoring the TCP socket queue length of the media server is
Periodically obtaining the TCP socket queue length to determine the drain rate;
6. The method of claim 5, comprising performing an active queue management (AQM) process on the TCP socket length to detect upcoming congestion on a TCP link.
The method of claim 1, wherein the bandwidth estimation comprises a bandwidth estimation based on an X2 interface for a long term evolution (LTE) network.
Bandwidth estimation based on the X2 interface for LTE networks is:
Establishing an X2AP protocol with each eNB;
Starting a load instruction;
Starting a resource status report;
Determining the resource status report.
Bandwidth estimation based on the X2 interface for LTE networks is:
Routing all X1AP messages through the core network element;
Initiating load instructions and resource status reporting for messages of interest;
Determining the resource status report.
A server in a mobile network,
One or more central processing units (CPUs);
A memory comprising an operating system (OS) and a mobile video delivery process, the mobile video delivery process comprising:
Receiving a request to initiate a progressive download of a video object;
Dividing the requested video object into self-contained independent video segments;
Translating each of the self-contained independent video segments for different rates;
Delivering a segment from a rate bucket that matches a current network condition determined by bandwidth estimation.
11. The server of claim 10, wherein each of the self-contained independent video segments is a playable unit.
Translating each of the self-contained independent video segments for different rates allows the media server to select the appropriate version for segment transmission as the available bandwidth changes. 11. The server of claim 10, further comprising registering each of the different bit rate versions with the media server so that
The server of claim 10, wherein the bandwidth estimation includes bandwidth estimation based on a transmission control protocol (TCP).
The server of claim 13, wherein the bandwidth estimation based on TCP comprises monitoring a TCP socket queue length of the media server.
Monitoring the TCP socket queue length of the media server is
Periodically obtaining the TCP socket queue length to determine the drain rate;
15. The server of claim 14, comprising performing an active queue management (AQM) process on the TCP socket length to detect upcoming congestion on a TCP link.
The server of claim 10, wherein the bandwidth estimation comprises a bandwidth estimation based on an X2 interface for a long term evolution (LTE) network.
Bandwidth estimation based on the X2 interface for LTE networks is:
Establishing an X2AP protocol with each eNB;
Starting a load instruction;
Starting a resource status report;
17. The server of claim 16, comprising determining a resource status report.
Bandwidth estimation based on the X2 interface for LTE networks is:
Routing all X1AP messages through the core network element;
Initiating load instructions and resource status reporting for messages of interest;
17. The server of claim 16, comprising determining a resource status report.

Images