JP2017220796A - Client device and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to determine a bit rate to be required by more accurately grasping a situation of congestion in a network or to determine the bit rate to be required by considering impartiality with respect to utilization of a network resource.SOLUTION: A client device comprises: an acquisition unit that through a network, acquires segment data on a content that is divided into a plurality of segments, each of which has a bit rate capable of being designated so as to differ from those of the others, together with congestion information showing the degree of congestion in the network; and a determination unit that on the basis of the congestion information acquired by the acquisition unit, determines a bit rate for a segment to be required next.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a client apparatus and method.

  2. Description of the Related Art In recent years, a distribution form that dynamically changes a distribution bit rate typified by DASH (dynamic adaptive streaming over hypertext transfer protocol) type distribution has been widely adopted in online video distribution services (for example, see Non-Patent Documents 1 and 2). ). According to this method, by preparing data of different bit rates for content in advance and dividing the data into segments, it is possible to request content with optimum and highest quality according to network conditions. . Specifically, the content bit rate is compared with the latest measured throughput index, and a segment file with a bit rate in a range not exceeding the throughput is requested.

I. Sodagar, “The MPEG-DASH Standard for Multimedia Streaming Over the Internet,” IEEE MultiMedia, vol.18, pp.62-67, 2011. Z. Li et al., “Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale,” IEEE Journal on Selected Areas in Communications, vol.32, 719-733, 2014 W.-H. Wang et al., “Application-Oriented Flow Control: Fundamentals, Algorithms and Fairness,” IEEE / ACM Transactions on Networking, 2006, 14, 1282-1291

  However, since the throughput used for determining the bit rate in DASH is measured by the client device, it depends on the status of the client device and may not be accurate as an index of the network status. In addition, current DASH does not consider fairness in the use of network resources.

  The present invention has been made in view of these problems, and the purpose of the present invention is to determine the required bit rate by more accurately grasping the state of congestion in the network, or considering the fairness of the use of network resources. Providing distribution technology that can determine the required bit rate.

  One embodiment of the present invention relates to a client device. This client device is divided into a plurality of segments, an acquisition unit that acquires content segment data that can specify different bit rates for each segment together with congestion information indicating the degree of congestion in the network, and an acquisition unit And a determination unit that determines the bit rate of the next requested segment based on the congestion information acquired by the above.

  It should be noted that any combination of the above-described constituent elements, or those obtained by replacing the constituent elements and expressions of the present invention with each other between apparatuses, methods, systems, computer programs, recording media storing computer programs, and the like are also included in the present invention. It is effective as an embodiment of

  According to the present invention, the required bit rate can be determined by more accurately grasping the state of congestion in the network, or the required bit rate can be determined in consideration of fairness in the use of network resources.

It is a schematic diagram which shows an example of the network topology of the delivery system which concerns on embodiment. It is explanatory drawing of the content hold | maintained at a delivery server. It is a block diagram which shows the function and structure of a client apparatus which concern on embodiment. It is a graph which shows an example of a utility function. It is a flowchart which shows a series of processes in the client apparatus of FIG.

  Hereinafter, the same or equivalent components, members, and processes shown in the drawings are denoted by the same reference numerals, and repeated description is appropriately omitted. In addition, in the drawings, some of the members that are not important for explanation are omitted.

  FIG. 1 is a schematic diagram illustrating an example of a network topology of a distribution system 100 according to an embodiment. Distribution system 100 includes seven nodes. Each of the nodes 1 to 4 is a client device such as a desktop PC (Personal Computer), a laptop PC, or a portable terminal, and the node 7 is a distribution server serving as a content source. The node 5 is a network device such as a router, and the node 6 is a cache server serving as a content cache. In one example, the node 7 and the nodes 1 to 4 are connected via a network such as the Internet, and the nodes 5 and 6 are nodes included in this network.

  Below, the connection between nodes is called a link. Each link is associated with a congestion price indicating the degree of congestion in the link.

  The distribution server (node 7) holds contents such as movies, animations, and other moving images, and distributes them in a streaming format in response to requests from client devices (nodes 1 to 4).

  FIG. 2 is an explanatory diagram of content held in the distribution server. The distribution server holds one content at a plurality of bit rates (encoding speeds). The multiple bit rates include, but are not limited to, 300 kbps, 1.2 Mbps, and 5 Mbps. In the distribution server, one content is divided into N segments (N is a natural number of 2 or more). Each segment corresponds to a predetermined playback length or data amount. In the present embodiment, the segment corresponds to a playback length of 3 seconds, 5 seconds, or 10 seconds. Each segment has a segment file corresponding to each of a plurality of bit rates.

  FIG. 2 shows content divided into N segments with a playback length of 3 seconds. That is, the total playback length of this content is 3 · N seconds. For each segment, the amount of data in the segment file increases as the bit rate increases. As shown in FIG. 2, the distribution server prepares data with different bit rates for each segment, and can specify different bit rates for each segment. For example, a segment file 202 of 300 kbps for segment 1, a segment file 204 of 1.2 Mbps for segment 2, and a segment file 206 of 5 Mbps for segment 3 may be designated and distributed to the client device. The bit rate specification is included in the segment request from the client device.

  In the present embodiment, when determining the bit rate of the next segment requested by the client device, the degree of congestion in the network and the fairness of network resource usage among users are considered. Thereby, the state of network congestion can be more accurately reflected in the determination of the bit rate, and fairness among users can be ensured.

  FIG. 3 is a block diagram illustrating functions and configurations of the client device 106 according to the embodiment. Each block shown here can be realized by hardware such as a computer (CPU) (Central Processing Unit) and other elements and mechanical devices, and software can be realized by a computer program or the like. The functional block realized by those cooperation is drawn. Therefore, it is understood by those skilled in the art who have touched this specification that these functional blocks can be realized in various forms by a combination of hardware and software.

  The client device 106 acquires content via the network 104. The client device 106 sequentially reproduces the already buffered data while buffering the received data. The client device 106 includes an access client 108, a media engine 110, a control engine 112, a display 114, and a user operation reception unit 118.

  The access client 108 functions as an interface with the network 104. The access client 108 receives the data sent to the client device 106 via the network 104 and provides it to other members, and acquires data to be transmitted from the other members and transmits it to the network 104.

  The media engine 110 performs processing such as decryption for reproducing the content received by the client device 106 and causes the display 114 to display the content. Media engine 110 includes a buffer 136 for holding segment files of received content. The segment file transmitted from the distribution server is received by the access client 108 via the network 104, transmitted from the access client 108 to the media engine 110, and stored in the buffer 136 in the media engine 110. Further, the media engine 110 reads out the segment file to be reproduced from the buffer 136, processes it, and displays it on the display 114.

  The user operation accepting unit 118 is connected to an input device such as a touch panel (not shown), and accepts designation of content to be reproduced from the user. The user operation accepting unit 118 accepts a user operation related to content reproduction, for example, an instruction to start or stop content reproduction.

  The control engine 112 controls the content request to the distribution server and the reception of the content from the distribution server. The control engine 112 includes a segment request unit 126, a congestion information processing unit 128, a reference rate calculation unit 130, a filter unit 132, a bit rate determination unit 134, and a request schedule unit 138.

  The segment request unit 126 specifies the bit rate determined by the bit rate determination unit 134 and requests the next segment from the distribution server via the network 104. The segment request unit 126 generates a segment request signal including the ID of the next segment to be requested and the bit rate specified for the segment, and transmits the segment request signal to the distribution server via the access client 108 and the network 104. The distribution server transmits to the client device 106 a segment file having a bit rate specified by the received segment request signal. The media engine 110 acquires a segment file with a congestion value indicating the degree of congestion in the network 104 via the network 104. The buffer 136 holds the acquired segment file.

As shown in FIG. 1, in this embodiment, a segment file is transmitted from a distribution server (node 7) that is a content source to client devices (nodes 1 to 4) through a plurality of links. The congestion value is the cumulative congestion price in each of the plurality of links through which the segment file with the congestion value passes. For example, the congestion value corresponding to the segment file acquired by the node 1 from the node 7 is the congestion price λ _7,5 of the link between the node 7 and the node 5 and the congestion of the link between the node 5 and the node 1. The sum of the price λ _5,1 (λ _7,5 + λ _5,1 ). The source distribution server initializes the congestion value, that is, sets zero as the congestion value. The distribution server updates the congestion value to λ _7,5 when transmitting the corresponding segment file to the node 1. When receiving the segment file, the node 5 adds λ _5,1 to the congestion value when transferring the segment file to the node 1. That is, at each node on the segment file transmission path, the congestion price of the destination link is added to the congestion value when the segment file is transferred. The congestion price may be, for example, a queuing delay, a loss probability, or a parameter related to either.

The congestion information processing unit 128 extracts the congestion value from the segment file with the acquired congestion value. The congestion information processing unit 128 performs low-pass EWMA (Exponentially Weighted Moving Average) on the extracted congestion value in order to remove abnormal values. More specifically, the congestion information processing unit 128 calculates the following equation (1) from the congestion value q (t) acquired together with the segment file of the t-th segment (t is a natural number greater than 1 and less than N). Accordingly, the filtered congestion value Q (t) is calculated.
Q (t) = β · Q (t−1) + (1−β) · q (t) (1)
Here, β is a constant greater than or equal to 0 and less than 1.

…（２）
ここで、［・］^ｂ _ａは関数ｍａｘ（ｍｉｎ（・、ｂ）、ａ）を表す。また、Ｍはクライアント装置１０６が要求しうるビットレートの最大値、ｍはクライアント装置１０６が要求しうるビットレートの最小値であり、それぞれクライアント装置１０６の性能、特性により決まる。例えば、配信サーバにおいて０．１Ｍｂｐｓ、０．３５Ｍｂｐｓ、０．７Ｍｂｐｓ、１．３Ｍｂｐｓ、２．８Ｍｂｐｓ、４．５Ｍｂｐｓの６種類のビットレートのセグメントファイルが利用可能であっても、クライアント装置１０６のデコーダが３．０Ｍｂｐｓまでしか対応できない場合、Ｍは２．８Ｍｂｐｓとなる。 The reference rate calculation unit 130 acquires the filtered congestion value Q (t) from the congestion information processing unit 128, and calculates the bit rate reference value x (t + 1) based on the acquired congestion value Q (t). . When calculating the reference value x (t + 1), the reference rate calculation unit 130 adds a congestion value to a utility function U (x) indicating the relationship between the quality of service in the client device 106 and the bit rate. Q (t) is applied as an indicator of service quality. More specifically, the reference rate calculation unit 130 calculates the reference value x (t + 1) according to the following equation 2.

... (2)
Here, [·] ^b _a represents a function max (min (·, b), a). Further, M is the maximum value of the bit rate that can be requested by the client apparatus 106, and m is the minimum value of the bit rate that can be requested by the client apparatus 106, and is determined by the performance and characteristics of the client apparatus 106, respectively. For example, even if a distribution server can use segment files of six bit rates of 0.1 Mbps, 0.35 Mbps, 0.7 Mbps, 1.3 Mbps, 2.8 Mbps, and 4.5 Mbps, the decoder of the client device 106 Is capable of handling only up to 3.0 Mbps, M is 2.8 Mbps.

  The above Equation 2 is set aiming at fair use of network resources among users. In particular, Equation 2 is determined using the Utility Faireness Framework. Since the utility fair framework is described in detail in Non-Patent Document 3, the description thereof is omitted in this specification.

  FIG. 4 is a graph showing an example of the utility function U (x). The horizontal axis of the graph represents the bit rate x, and the vertical axis represents an index of service quality. The broken line indicates the utility function U (x). The utility function U (x) approximates the step function V (x) with a multilevel sigmoid function. Each step of the step function V (x) corresponds to one of a plurality of different bit rates (300 kbps, 1.2 Mbps, 5 Mbps) that can be specified for the next requested segment.

…（３）
のように表される。
ｙをユーティリティ値とするとき、上記のユーティリティ関数の逆関数Ｕ^−１ _ｎ（ｙ）は、

…（４）
のように表される。
なお、他のタイプのアプリケーションは異なる形状のユーティリティ関数を有する。例えば、ＦＴＰやＷｅｂアプリケーションは一般に対数関数的なユーティリティ関数を有する。 More generally, different can be specified relative to the next segment to request the number of possible different bit _{rates, r 1 <r 2 <...} <r K for the segment to be next request K When each of a plurality of bit rates, the utility function Un (x) for user n obtained by approximation using a multi-level logistic function is

... (3)
It is expressed as
When y is a utility value, the inverse function U ⁻¹ _n (y) of the above utility function is

(4)
It is expressed as
Note that other types of applications have utility functions of different shapes. For example, FTP and Web applications generally have logarithmic utility functions.

Returning to FIG. 3, the filter unit 132 low-passes the reference value x (t + 1) calculated by the reference rate calculation unit 130 in order to remove the fluctuation component from the reference value of the bit rate used for determining the bit rate. Perform EWMA. More specifically, the filter unit 132 calculates the filtered reference value X (t + 1) from the reference value x (t + 1) calculated by the reference rate calculation unit 130 according to the following equation (5).
X (t + 1) = (1−α) · X (t) + α · x (t + 1) (5)
Here, α is a constant greater than 0 and less than or equal to 1.

  By setting α to 1, the filter unit 132 can be invalidated. When the reference value calculated by the reference rate calculation unit 130 converges quickly, α may be set to 1 or the filter unit 132 may not be provided.

The bit rate determination unit 134 determines the bit rate to be designated for the next requested segment according to the filtered reference value X (t + 1) calculated by the filter unit 132. When determining the bit rate, the bit rate determining unit 134 compares the filtered reference value X (t + 1) with a plurality of different bit rates that can be specified for the next requested segment. More specifically, the bit rate determination unit 134 is equal to or less than the filtered reference value X (t + 1) from among a plurality of different bit rates that can be specified for the next requested segment. Select the bit rate. That is, if the p-th bit rate r _p counted from the lower is selected,
r _p ≦ X (t + 1) <r _{p + 1} (6)
Is established.

  The request scheduling unit 138 controls the next segment request timing so that the remaining amount of the buffer 136 is between the minimum value Bmin and the maximum value Bmax. When the remaining amount B of the current buffer 136 is lower than Bmax, the request schedule unit 138 causes the segment request unit 126 to request the next segment as soon as the bit rate is determined by the bit rate determination unit 134. When the remaining amount B of the current buffer 136 is equal to or greater than Bmax, the request scheduling unit 138 suspends the request for the next segment for Δt (= B−Bmax + τ). Here, the units of B, Bmax, and Bmin are all reproduction lengths, and τ is the reproduction length of one segment.

The operation of the client device 106 configured as above will be described.
FIG. 5 is a flowchart showing a series of processing in the client device 106. The client device 106 acquires the segment file and the associated congestion value from the distribution server via the network 104 (S502). The client device 106 extracts a congestion value from the acquired information (S504). The client device 106 smoothes the extracted congestion value (S506). The client device 106 calculates a reference value of the bit rate from the congestion value using a calculation formula set to realize fairness among users regarding the use of network resources (S508). The client device 106 smoothes the obtained reference value by EWMA (S510). The client device 106 determines the bit rate of the next requested segment from the reference value (S512). The client device 106 compares the current remaining buffer capacity B with the maximum value Bmax (S514). If B ≧ Bmax (YES in S514), the client device 106 waits for Δt (S516). After waiting in step S516, or when B <Bmax (NO in S514), the client device 106 requests the next segment from the distribution server by designating the determined bit rate via the network 104 (S518). .

  Based on the description of the present embodiment, each unit temporarily stores a CPU (not shown), an installed application program module, a system program module, and the contents of data read from the hard disk. It will be understood by those skilled in the art who have touched this specification that it can be realized by a semiconductor memory or the like.

  According to the client device 106 according to the present embodiment, a fair bit rate reference value is determined according to the utility fair framework by using a congestion value that is feedback about congestion. Therefore, since many client devices operate cooperatively under the guidance of congestion feedback, fairness can be ensured and the utility of the entire system can be maximized.

  Further, according to the client device 106 according to the present embodiment, it is possible to optimize service quality and fairness among many users. In particular, when a plurality of users share a network bottleneck, the congestion value of these users becomes equivalent because the congestion price at the bottleneck dominates. Therefore, fairness among those users can be ensured.

  In the client device 106 according to the present embodiment, a multilevel sigmoid function is used as a utility function. Since the multi-level sigmoid function is more conservative with respect to the bit rate increase than the step function, the probability of underrun of the buffer 136 can be further reduced.

In addition, according to the client device 106 according to the present embodiment, the bit rates of the next segments specified by a plurality of client devices that receive the segment file through the same or similar route are often the same. Therefore, the capacity required for the cache provided on the path can be reduced. For example, in the topology shown in FIG. 1, consider a case where the nodes 2, 3, 4 request the same content from the node 7 at the same time. The congestion values at the nodes 2, 3 and 4 are (λ _7,6 + λ _6,2 ), (λ _7,6 + λ _6,3 ), and (λ _7,6 + λ _6,4 ), respectively. When the congestion prices λ _6,2 , λ _6,3 , λ _6,4 of the links from the node 6 to the nodes 2, ₃ , ₄ are equivalent, the congestion values at the nodes 2, ₃ , ₄ are also equivalent Therefore, the specified bit rate is the same. In this case, since the cache (node 6) only needs to cache the segment files having the same specified bit rate, the required capacity can be reduced compared to the case where the specified bit rates are different.

  In addition, the utility fair framework is used in the client device 106 according to the present embodiment. The framework supports networks that mix inelastic applications (eg, streaming) and elastic applications (eg, FTP, Web, download). Accordingly, distribution system 100 can also support such a network.

  The configuration and operation of the client device 106 according to the embodiment has been described above. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to each component and combination of processes, and such modifications are within the scope of the present invention.

  In the embodiment, the case where the reference value of the bit rate is calculated based on the congestion value has been described. However, the present invention is not limited to this, and the bit rate of the segment to be requested next based on the congestion information indicating the degree of congestion in the network. May be determined. In this case, the congestion information may reflect the accumulated congestion price in each of the plurality of links. Alternatively, the congestion information may include information indicating the congestion status in the network such as ECN (Explicit Congestion Notification) which is an extended function of TCP / IP.

  In the embodiment, the case where the starting point of the accumulated congestion price is the distribution server (source) has been described. However, the present invention is not limited to this. For example, a cache may be used as the starting point of the accumulation.

  The distribution system 100 according to the embodiment may be implemented in an HTTP (Hypertext Transfer Protocol) environment. Alternatively, the distribution system 100 may be realized in a UDP (User Datagram Protocol) environment or a CCN (Content-Centric Networks) environment.

  100 distribution system, 104 network, 106 client device, 108 access client, 110 media engine, 112 control engine.

Claims (8)

An acquisition unit that acquires segment data of content that is divided into a plurality of segments and that can specify different bit rates for each segment, together with congestion information that indicates the degree of congestion in the network, and
A client device comprising: a determination unit that determines a bit rate of a segment to be requested next based on the congestion information acquired by the acquisition unit. A calculation unit that calculates a reference value of the bit rate based on the congestion information acquired by the acquisition unit;
The client device according to claim 1, wherein the determination unit determines a bit rate by comparing the reference value calculated by the calculation unit with a plurality of different bit rates that can be specified for a next requested segment.   The calculation unit calculates a reference value by applying congestion information acquired by the acquisition unit as a service quality index to a utility function indicating a relationship between service quality and bit rate in the client device. 3. The client device according to 2.   4. The client apparatus according to claim 3, wherein the utility function approximates a step function, and each step of the step function corresponds to one of a plurality of different bit rates that can be specified for a next requested segment.   5. The client device according to claim 1, further comprising a requesting unit that requests the next segment via the network by designating the bit rate determined by the determining unit. Segment data is transmitted from the content source or cache to the client device through multiple links,
The client apparatus according to claim 1, wherein the congestion information acquired by the acquisition unit reflects a cumulative degree of congestion in each of the plurality of links. Obtaining segment data of content that is divided into a plurality of segments and that can specify different bit rates for each segment together with congestion information indicating the degree of congestion in the network;
Determining a bit rate of a next requested segment based on the acquired congestion information. A function for acquiring segment data of content that is divided into a plurality of segments and that can specify different bit rates for each segment together with congestion information indicating the degree of congestion in the network, and
A computer program for causing a computer to realize a function of determining a bit rate of a segment to be requested next based on the acquired congestion information.

Images