U.S. patent application number 13/272127 was filed with the patent office on 2012-10-25 for methods and system for efficient data transfer over hybrid fiber coax infrastructure.
This patent application is currently assigned to Harmonic Inc.. Invention is credited to Lior Assouline, Amir Leventer.
Application Number | 20120271922 13/272127 |
Document ID | / |
Family ID | 40798281 |
Filed Date | 2012-10-25 |
United States Patent
Application |
20120271922 |
Kind Code |
A1 |
Assouline; Lior ; et
al. |
October 25, 2012 |
Methods and System for Efficient Data Transfer Over Hybrid Fiber
Coax Infrastructure
Abstract
The invention is directed to a method for providing
client-server data transfer over a Hybrid Fiber Coax network,
comprising interfacing, at a client, a channel, wherein the channel
is one of a video channel and a DOCSIS channel, intercepting a
content request made from an end-user computing device, notifying a
server of a relevant intercepted message via one of using an
interactive channel and tagging the request, selecting content sent
by the server over the channel, processing the content selected so
as to return it to its IP traffic format, and forwarding the
content in its IP traffic format to the end-user computing
device.
Inventors: |
Assouline; Lior; (Rishon
Lezion, IL) ; Leventer; Amir; (Kfar Saba,
IL) |
Assignee: |
Harmonic Inc.
San Jose
CA
|
Family ID: |
40798281 |
Appl. No.: |
13/272127 |
Filed: |
October 12, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12341785 |
Dec 22, 2008 |
8064479 |
|
|
13272127 |
|
|
|
|
12341513 |
Dec 22, 2008 |
|
|
|
12341785 |
|
|
|
|
61018602 |
Jan 2, 2008 |
|
|
|
Current U.S.
Class: |
709/219 |
Current CPC
Class: |
H04L 69/165 20130101;
H04N 21/64322 20130101; H04N 21/262 20130101; H04L 67/2814
20130101; H04N 7/17336 20130101; H04L 69/16 20130101; H04N 21/2221
20130101; H04L 69/08 20130101; H04L 67/2823 20130101; H04N 21/6118
20130101; H04L 12/2801 20130101; H04N 21/2381 20130101 |
Class at
Publication: |
709/219 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method for providing client-server data transfer over a Hybrid
Fiber Coax network, comprising: interfacing, at a client, a
channel, wherein the channel is one of a video channel and a DOCSIS
channel; intercepting a content request made from an end-user
computing device; notifying a server of a relevant intercepted
message via one of using an interactive channel and tagging the
request; selecting content sent by the server over the channel;
processing the content selected so as to return it to its IP
traffic format; and forwarding the content in its IP traffic format
to the end-user computing device.
2. The method of claim 1, further comprising: decapsulating a
DOCSIS MAC frame; rebuilding an IP frame; and forwarding the IP
frame to the end-user computing device.
3. The method of claim 1, wherein the interactive channel is a
DOCSIS channel.
4. The method of claim 1, wherein the client and the server are
proxies in a performance enhancing proxy (PEP) setup and are
configured to transform a windows ACK dependent protocol into a
windows ACK independent protocol connection over a last-mile
link.
5. The method of claim 4, wherein the windows ACK dependent
protocol is TCP and windows ACK independent protocol is UDP.
6. The method of claim 1, further comprising blocking ACK
originating from traffic reception.
7. The method of claim 1, further comprising sending ACK to the
server upon successful reception of a window of traffic.
8. The method of claim 1, wherein the client operates in a DOCSIS 3
CM.
9. The method of claim 8, wherein at least one of a plurality of
tuners is controlled by regular DOCSIS control and at least one of
the plurality of tuners is available for client control.
10. The method of claim 1, wherein the client operates in one of a
DOCSIS 2 CM and another compatible tuner, and CMTS registration is
performed prior to interfacing the channel.
11. The method of claim 1, wherein the client operates in a
pre-DOCSIS 3 CM, and wherein at least one of multiple DOCSIS 2 and
backward-compatible tuners are bonded together to effectively
provide DOCSIS 3 functionality.
12. The method of claim 1, further comprising tagging the content
request to indicate to the server where to send the request
response.
13. The method of claim 1, wherein the content and the relevant
intercepted message is of a type chosen from the group consisting
of P2P application type, Video application type, file transfer
application type, content over TCP protocol, and content over UDP
protocol.
14. The method of claim 1, further comprising preprocessing one of
the content and the relevant intercepted message.
15. The method of claim 1, further comprising altering one of the
content and the relevant intercepted message according to one of
the content destination, a key, and other end-user related
information.
16. The method of claim 1, wherein the processing includes
replacing a video frame and inserting an advert.
17. The method of claim 1, wherein the processing includes one of
encryption and decryption of the content.
18. The method of claim 1, wherein the network is of a type chosen
from the group consisting of cable, xDSL, and Satellite.
19. The method of claim 1, wherein the client-server data transfer
occurs over a high bandwidth, high latency channel.
20. The method of claim 1, further comprising intercepting a server
message sent by the server.
Description
RELATED APPLICATIONS
[0001] This application claims priority based on U.S. Provisional
Patent Application No. 61/018,602, filed on Jan. 2, 2008, entitled
"Methods and System for Efficient Data Transfer Over Hybrid Fiber
Cable Infrastructure." This application is also a
continuation-in-part of U.S. Non-Provisional patent application
Ser. No. 12/341,513, filed on Dec. 22, 2008, entitled "Methods and
System for Efficient Data Transfer Over Hybrid Fiber Coax
Infrastructure." This application is also a continuation of U.S.
Non-Provisional patent application Ser. No. 12/341,785, filed on
Dec. 22, 2008, entitled "Methods and System for Efficient Data
Transfer Over Hybrid Fiber Coax Infrastructure."
BACKGROUND
[0002] 1. Technical Field
[0003] The invention is related to acceleration of internet
protocol (IP) data content transfer and load balancing of IP
content between Data Over Cable Service (DOCSIS) and MPEG2
Transport (TS) video channels over a Hybrid Fiber Coax (HFC)
network and in particular to a system and methods to efficiently
and transparently, monitor and process regular IP over DOCSIS and
transfer relevant IP data (such as, but not limited to, Television
Encoded Media Content, Television Encoded Media Streaming,
Programs, Operating System Distribution Images etc. . . . ) to end
user computing devices (such as, but not limited to, Personal
Computer (PC), Set Top Boxes (STB), Over the Top boxes (OTT) or
Cable Modem (CM)), during periods where available bandwidth (BW) in
the MPEG2 Transport video channels at the HFC infrastructure exists
by rerouting & processing the relevant (mainly download) IP
flow from the regular low latency and expensive DOCSIS channels
direction into the high latency, much more reliable and relatively
inexpensive video channels. This is done by encapsulating the
content in a video-like transport packets, handle TCP
inefficiencies (in case it is TCP--if it isn't then encapsulation
is enough) related to high delay video channel by the use of
performance enhancing proxy at the sub IP level, send it over video
downlink only channels, extract and process the sent content from
the video channels at the end user computing device either to be
used immediately and taking care of TCP or any other transfer
protocol emulation or by using storage if existing in order to
cache the content for later demand by the computing device.
[0004] 2. Related Art
[0005] In recent years the internet traffic size has grown
exponentially. According to researchers, this growth is mainly
attributed to video files either being sent over P2P networks, file
downloads, or by direct streaming from Content delivery networks
(CDN). It is further expected that the distribution of video
content (in either delivery form) will further increase the
internet traffic.
[0006] P2P traffic, for example, is an "all that you can get"
traffic as opposed to bursts of data retrieval and mostly idles
connection (http). This fact as well as native large size of video
content puts a heavy load on the business model of any broadband
operator (such as Cable operator). DOCSIS channels are designed for
burst of traffic and not for a steady state traffic flow, as
operators resell the same bandwidth to multiple users relying on
statistical averaging to accommodate all users' BW requests in the
BW limited provided channels. The exponential growth attributed to
video traffic is forcing them to upgrade their cable plant with
expensive solutions (node splitting, spectrum overlays, more DOCSIS
QAM, to name few solutions, DSLAM upgrade, etc.)
[0007] Furthermore, in cables Hybrid Fiber Coax (HFC) plant, the
network media (implemented as DOCSIS protocol) is shared amongst
all users on a service group (SG). Therefore, a steady state,
always on, "all that you can get" download service, ruins the
statistical effect of uncorrelated networking requests and causes a
very negative customer satisfaction especially in the "rush hours"
of network capacity (typically at evenings). In addition, it is
well known that P2P or other video content tends to be highly
repetitive, i.e. several users are downloading the same content.
While the media is shared amongst all users on a SG, the connection
is individual, i.e. the same content is sent to multiple users on
the SG and there is currently no solution for this
inefficiency.
[0008] One solution for the DOCSIS channels overload is to use Deep
Packet Inspection (DPI) in order to reduce the priority and Quality
of Service (QoS) of the broadband application services (mainly
targeted at P2P traffic). This has the effect of both decreasing
the large pool of customer's running P2P application satisfaction
on one hand and on the other, promotes ways to hide the P2P
services such that DPI becomes irrelevant.
[0009] Another solution is to upgrade the cable plant capacity by
Spectrum overlay, freeing analog channels, node splitting, etc.
Since the video and other large file download applications are
using "all you can get", this solution (although very expensive to
implement) provides no real solution to the BW hungry traffic as it
quickly fills up the newly available BW again.
[0010] While the DOCSIS channels are sharing their BW with all
users on a SG, there are many video related services (such as Video
on Demand (VOD)) for which channel BW is provisioned but is not
used all the time. The BW allocated for those services is a
function of the peak usage expected and is indeed used only at
small portion of the day time.
[0011] Furthermore, a recent technological advance permits
assigning channels to switched services (Switched Digital Video
(SDV)) and therefore broadcasting and using their BW only when
requested to do so by users tuning to these specific services. It
is expected that more and more services will transition to switched
technology since it offers an opportunity to use the statistics in
order to free BW for services that are not required and provide a
much greater service offering without actually increasing the HFC
capacity. Again, the more switched services, the greater the amount
of free BW available at certain hours of the day. In a typical
current HFC installation, this amount of free BW sums up to
approximately 10 times the amount of BW offered in DOCSIS channels.
This factor is expected to grow as the transition to switched
services increases. A problem with this available BW, however, is
that it exists in video channels and there is currently no
connection between DOCSIS channels and video channels.
[0012] Another recent technological advance is the use of Docsis
Internet Protocol Television Bypass architecture which is using the
video channels in order to stream to end-user devices an UDP/IP
flow of video.
[0013] Another problem with video channel is that it uses a QAM
with longer interleaver (in order to provide error free video
transmission without retransmission as is implemented in the TCP/IP
world). In addition, most common QAMs also use a dejittering and
dedrifting buffers which add to the longer latency of the QAM.
Typical video QAM latency is in the order of .about. 25 msec.
Implementing the TCP protocol on these channels greatly reduces the
maximal throughput since the server has to wait for a longer delay
after transmitting the maximal TCP window in order to get an
acknowledgment and continue with the next window of data.
[0014] Therefore, what is needed is a system and methods to use the
available free BW in non DOCSIS channels (including, but not
limited to, VOD channels, MPEG Transport (TS) channels, SDV
channels) which are designed by worst case scenario, and use it to
transparently redirect IP traffic on a best effort basis and
bypassing the Cable Modem Termination System (CMTS). Such a system
should require a low cost hardware (as bypassing the CMTS core and
reuse of installed based equipment) or software addition to the
user computing device in order to transparently catch the bypassed
IP traffic and transfer the redirected IP content from the video
channels into the computing device. It should also provide
substantial increase in download speed for BW intensive content by
incorporating an adapted performance enhancement proxy (PEP) while
freeing the DOCSIS channel for interactive services such as http.
The system should further utilize the fact that most of the content
is repetitive, and thus send the content to multiple users and/or
CPEs (customer-premises equipment) at once (Multicasting), and even
push it to clients it expects will be requesting the content in the
future. The system should further not involve a massive upgrade in
the HFC plant, but rather an addition of a low cost redirecting
server with an interface to the HFC resource managers and switching
devices, and of software modifications to tuning devices at the
users' premises in order to interface the video channels and
capture the IP content sent and redirect it to the end-user
computing device as if it came from the regular DOCSIS
channels.
[0015] In order to solve many operational issues, the above
solution should be performed on simple SW upgrade of current CPEs
without any additional equipment or connectivity at the end-user
premises.
SUMMARY
[0016] A "LibraFlow" system and methods as described herein
provides a transparent IP traffic offloading from DOCSIS channels
into non-DOCSIS channels, and IP traffic acceleration by using
available free BW in non-DOCSIS channels, protocol enhancement
proxies at both ends of the last mile link, and potentially local
cache at the peer computing device. In addition, the content can be
altered according to specific parameters of the downloading
user.
[0017] The LibraFlow system is made of a LibraFlow Clients and
Server. The LibraFlow Client consists of a driver operating in the
user CM (or any other CPE) or even inside the computing device. The
LibraFlow server consists of a computing device operating at the
Cable premises typically at the Hub or Head-End.
[0018] The LibraFlow server is responsible for detecting LibraFlow
relevant IP traffic (either by itself or by information sent from
the CPE), prioritizing them, preprocessing them, building the
transmission content, interfacing the resource management at the
Cable plant in order to get the available free BW on non-DOCSIS
channels, notifying the LibraFlow client of the transmission path
chosen and finally transmitting the content in on the free BW
available in non-DOCSIS channels. Moreover, LibraFlow server is
responsible for any protocol conversions and/or manipulation in
order to contend with the challenges of high latency and/or high BW
in LibraFlow pipes.
[0019] The LibraFlow client (driver) is responsible for tuning on
the specific transmission frequency as notified by the LibraFlow
server, and extracting the LibraFlow-generated traffic out of the
transport mux flowing there. The traffic is either sent to the user
computing device or put on the local content cache for later
potential access. The LibraFlow client can create either seamless
or non-seamless added pipes to current regular broadband
connections.
[0020] When the end user computing device, CM, or any device
running the LibraFlow Client, is initialized, the LibraFlow driver
registers with the LibraFlow server over the DOCSIS channel or any
other bidirectional capable channel (such as, but not limited to,
Out Of Band (OOB) channel in a STB environment) in a potentially
secure connection (typically but not limited to secure socket
layer--SSL). In this registration, the user computing device is
assigned a LibraFlow Client ID and several Destination IDs. In
addition, the end user computing device is assigned a certain
number of keys to potentially be used in the decryption of the
LibraFlow generated traffic). Then, the LibraFlow driver
initializes the tuner device (which includes, but is not limited
to, a Cable modem tuner, a DVB-C tuner card, a DVB-C tuner external
device, a Set Top Box or Over the Top device connected to the local
area network (LAN) running a client that receives LibraFlow
generated traffic, or any other device that is able to tune to a
certain QAM frequency and enables running a small client that will
extract the LibraFlow generated traffic out of the received video
transport traffic). In another embodiment of this invention, the
end-user CPE is targeted using its MAC as a targeting address. In
this case the CPE MAC has been communicated to the LibraFlow server
in the registration process.
[0021] The LibraFlow client constantly listens for any transmission
notification issued by the LibraFlow server. The transmission
notification generally includes (but is not limited to) a QAM
frequency and a LibraFlow destination ID. Whenever such
notification is issued, the LibraFlow driver tunes the LibraFlow
tuner device to the frequency as notified and extracts (out of the
transport packets traffic) the LibraFlow generated traffic having
the LibraFlow destination ID or the MAC layer that matches one of
the destination IDs received in the registration stage. The traffic
is then decrypted and potentially processed. One example of such
processing is the insertion of targeted advertising in movies files
or replacement of existing adverts by other adverts sent
specifically to the user via another method, watermark insertion,
encryption and decryption. The content is then either sent to the
user computing device or indexed and placed in a local cache for
later retrieval.
[0022] The LibraFlow server constantly listens for requests from
end user computing devices made over DOCSIS channels (or in any
other upstream connectivity). It also monitors the amount of free
BW existing in the non DOCSIS QAMs and inserts the LibraFlow
generated traffic by numerous methods such as but not limited to
interfacing the resource manager of the cable plant and sending the
traffic in the form of a new video session, receiving all traffic
before it is being modulated (usually in internet protocol (IP)
packets form) and replacing the available BW of certain types of
packets (NULL TS packets, for example) with LibraFlow generated
traffic and outputting it to the modulators.
[0023] The LibraFlow server prioritizes the servicing of the
requests according to numerous criteria including, but not limited
to, the nature of the underlying traffic (such as a greater
priority for certain types of streaming traffic), various premium
accounts, various cable operator statistics such as the available
free BW, and various deals with content providers.
[0024] Before transmitting LibraFlow generated traffic to the
LibraFlow tuner devices, the LibraFlow server notifies the
LibraFlow drivers of the way the traffic should be extracted, which
may include but is not limited to tuning frequency, service ID, and
destination ID. This notification is sent through a channel such as
but not limited to regular IP over DOCSIS channel, preconfigured
video channels in the form of LibraFlow generated messages, OOB
channels, or any other channel.
[0025] The LibraFlow server might decide to send the same traffic
to multiple LibraFlow tuner devices (including to clients who have
not requested the traffic but are highly likely to do so in the
future, i.e. pushing IP traffic as opposed to servicing IP
requests) by using special "multicast" destination ID, and thus
further enhancing the efficiency of the transmission especially of
popular content. Pushing of content might further be performed
according to a profile of the end user preferences, built on the
server or on the client, with or without the client initiating the
session and/or content request.
[0026] The LibraFlow server and client may implement TCP
performance enhancing proxies (PEP) in order to overcome the longer
latency typically existing in video QAMs. There are many methods
for implementing PEP and any of them may be used without departing
from the original intent of this invention.
[0027] A method and system is presented for the bidirectional
transfer of data packets over a TCP communications system on long
delay video edge QAM transparently to the end users, replacing the
TCP over DOCSIS that accelerates the data delivery between end
users, and improving reliability of the data packet transmission.
The invention can eliminate the conventional TCP 3-way handshake
and other associated time-delay procedures, and replaces them with
an improved use of performance enhancing proxies at either end of
the HFC plant (LibraFlow Client on CPE and LibraFlow Server), data
buffer storage and packet header field arrangement among the design
features of a protocol method and system that accelerates data
packet transfer with more efficient link capacity use and greater
data throughput.
[0028] In view of the above summary, it is clear that the LibraFlow
System described herein provides a unique system and method for
providing a transparent IP traffic offloading from DOCSIS channels
into non DOCSIS channels and IP traffic acceleration by the use of
IP traffic cache and multicast pushing. Moreover, the LibraFlow
system overcomes challenges of transmitting data over video QAMs
such as high latency and high BW sessions. In addition to the
above-described benefits, other advantages of the LibraFlow system
will become apparent from the detailed description which follows
hereinafter when taken in conjunction with the accompanying drawing
figures.
DESCRIPTION OF THE DRAWINGS
[0029] The specific features, aspects and advantages of the present
invention will become better understood with regard to the
following description and accompanying drawings where:
[0030] FIG. 1. is a general system diagram depicting a general
purpose computing device constituting an exemplary system
implementing a "LibraFlow" as described herein.
[0031] FIG. 2. illustrates an exemplary peer-to-peer (P2P) network
for content downloading, as described herein.
[0032] FIG. 3. provides an exemplary architectural diagram which
illustrates program modules for implementing the "LibraFlow" with a
DVB-C tuning device, for example.
[0033] FIG. 4. provides an architectural system diagram
representing the LibraFlow client server environment.
[0034] FIG. 5. Provides an operation flow diagram which illustrates
the general operation of one embodiment of the LibraFlow as
described herein.
[0035] FIG. 6. illustrates the benefits in a specific embodiment in
which the invention is may be practiced.
[0036] FIG. 7. illustrates few messages format used in the
communication between the LibraFlow Server and Client.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0037] In the following description of the preferred embodiment of
the present invention, reference is made to the accompanying
drawings, which form a part hereof, and in which is shown by way of
illustration specific embodiments in which the invention is may be
practiced. It is understood that other embodiments may be utilized
and structural changes may be made without departing from the scope
of the present invention.
[0038] 1. Exemplary Operating Environment
[0039] The invention consists of at least three parts: a LibraFlow
(LF) server typically located in the Cable operator premises, a
LibraFlow client/driver typically located in a CPE such as Cable
Modem STB, OTT or a computing device at the end user premises and a
tuning device typically located at the end user premises inside a
CPE (such as but not limited to CM, STB, OTT) or a computing device
(such as, but not limited to, a DVB-C tuner). FIG. 1 illustrates an
example of a suitable computing system environment 100 on which
part of the invention may be implemented. The computing system
environment 100 is only one example of a suitable computing
environment and is not intended to suggest any limitation as to the
scope of use or functionality of the invention. Neither should the
computing environment 100 be interpreted as having any dependency
or requirement relating to any one or combination of components
illustrated in the exemplary operating environment 100.
[0040] The invention is operational with numerous other general
purpose or special purpose computing system environments or
configurations. Examples of well known computing systems,
environments, and/or configurations that may be suitable for use
with the invention include, but are not limited to, personal
computers, cable modem, server computers, hand-held, laptop or
mobile computer or communications devices such as cell phones and
PDA's, multiprocessor systems, microprocessor-based systems, set
top boxes (STB), over the top boxes (OTT), Residential Gateways,
programmable consumer electronics, network PCs, minicomputers,
mainframe computers, distributed computing environments that
include any of the above systems or devices, and the like.
[0041] Part of the invention may be described in the general
context of computer-executable instructions, such as program
modules, being executed by a computer in combination with hardware
modules, including components of a LibraFlow Tuner Device 115.
Generally, program modules include routines, programs, objects,
components, data structures, etc., that perform particular tasks or
implement particular abstract data types. The invention may also be
practiced in distributed computing environments where tasks are
performed by remote processing devices that are linked through a
communications network. In a distributed computing environment,
program modules may be located in both local and remote computer
storage media including memory storage devices. With reference to
FIG. 1, an exemplary system for implementing the invention includes
a general-purpose computing device in the form of a computer
103.
[0042] Components of computer 103 may include, but are not limited
to, a processing unit 104, a system memory 102, and a system bus
108 that couples various system components including the system
memory to the processing unit 104, a non-volatile memory 101, audio
interface 105, a keyboard 112, a mouse 113 or any other pointing
device connected thru an input/output interface 111, a monitor 107
or any other viewing device such as, but not limited to,
television, projector and the like connected thru a video interface
106.
[0043] The computer 110 may operate in a networked environment
using logical connections to one or more remote computers, such as
a remote computer 118. The remote computer 118 may be a personal
computer, a STB, a wireless Router, a CM, a server, a router, a
network PC, a peer device, or other common network node, and
typically includes many or all of the elements described above
relative to the computer 103. The logical connections depicted in
FIG. 1 include a wide area network (WAN) 117, but may also include
other networks such as local area network (LAN). Such networking
environments are commonplace in homes, offices, enterprise-wide
computer networks, intranets, and the Internet.
[0044] When used in a WAN networking environment, the computer 103
typically includes a modem 114. The modem 114, which may be
internal or external, may be connected to the system bus 108 via
the network interface 110, or other appropriate mechanism (such as
but not limited to a router, a switch, a hub, a gateway, a wireless
gateway etc. . . . ).
[0045] It will be appreciated that the network connections shown
are exemplary and other means of establishing a communications link
between the computers may be used.
[0046] The LibraFlow server generally consists of computer
executable instruction running on a computer similar to what's been
described above 122 but any other implementation might be done
without departing from the general scope of the server
activities.
[0047] The exemplary operating environment having now been
discussed, the remaining part of this description will be devoted
to a discussion of the program modules and processes embodying a
LibraFlow system which provides a transparent IP traffic offloading
from DOCSIS channels into video channels and IP traffic
acceleration, in part by the efficient (TCP protocol wise)
performance enhancement proxies usage, and the usage of free BW in
these video channels.
[0048] 2. Introduction
[0049] A "LibraFlow" system and methods as described herein
provides a IP traffic processing below the application level (and
might therefore be transparent to the user and IP application
level) and IP traffic offloading from DOCSIS networks into MPEG2 TS
network and IP traffic acceleration by using available free BW in
video channels in order to potentially multicast and push content
into local cache existing in the end user computing device or to be
used directly with any IP connected application (such as but not
limited to web explorer, media players, file downloader and the
like).
[0050] In one embodiment of the current invention, the LibraFlow
operates in P2P networks such as the network illustrated by FIG. 2.
Peers 202 are trading pieces of files according to prior knowledge
about the pieces locations. In one P2P networks example (BitTorrent
network), such knowledge might be available by a central computing
(tracker) device 203 and distributed/pulled/updated by any other
peer 202. Peers 202 requesting a certain piece of a file do so
directly from other peers. It should be noted that the peep to peer
communication is optional and in other P2P protocols peers might
download pieces of the content from central servers. All this P2P
communication is done over DOCSIS data protocol which is run over
dedicated DOCSIS channels shared by all peers on the HFC segment
213 that originates from the HUB/Head-End 210. There is currently
no way to use the fact that most of the content flow is repetitive
and the same content is sent separately to all requesting peers. In
addition, the high BW P2P content fills up the DOCSIS channel and
reduces customer's satisfaction as the available BW for interactive
activities such as web browsing.
[0051] At the same time, most of the switched channels (such as,
but not limited to, VOD, Switched Digital Video (SDV) Services,
etc. . . . ) are partially unused but, as they are not part of the
DOCSIS channel, they cannot be used for relieving the BW load
caused by P2P applications on DOCSIS channels.
[0052] LibraFlow solves all these issues. LibraFlow server
transparently monitors and intercepts the P2P messages (either
itself or with the help of the end-user device such as the CM,
software driver at the end-user computing device etc. . . . ) and
decides to forward them to other Peers or serve them out of its
local cache 510 in case the content has been pushed there earlier
or forward them from the WAN or the local network thru the video
channels by configuring the flow routing at the HE/HUB 210 switch
or router. In addition, the LibraFlow server might prepare for
future requests by pre-fetching and pushing the relevant content.
The local cache is being updated 516 by the LibraFlow server
according to certain priorities 519 statuses sent by the LibraFlow
(LF) driver 518.
[0053] In another embodiment, the application at the end-user
computing device 202 is requesting a file (such as but not limited
to, an *.avi, *.flv, *.sdp, *.mpg, *mp4, *.zip, *.img, *.rar etc. .
. . ) the CM thru which the request is made may decide (based on
any cretia such as but not limited to, size, type, interactivity,
http context, etc. . . . ) that this request should be serviced (if
possible) thru the LibraFlow channels and tag this choice in the IP
headers or by communicating with the LibraFlow server the requests
details in the upstream DOCSIS channel inb a separate request
before the application request is sent. This decision may also be
taken in the LibraFlow server (thru which all communication may be
passed for, among other tasks, monitoring) itself.
[0054] The LibraFlow server detects this flow characteristic and
configures the DOCSIS router or switch to route this flow thru the
LibraFlow server instead of the DOCSIS CMTS. The LibraFlow server
then transmits the data back to the end-user application thru the
LibraFlow channels via different manners described further below
(such as session init, NULL replacements and the like . . . . )
[0055] Since the WAN servers that transmit these files typically
implement a TCP protocol (in cases the transfer is done over TCP)
the networking stack at the server expects an ACK before
transmitting more than a TCP window (which size is changing and has
a certain maximum--typically 64 KB). Since the video channels over
which LibraFlow operates have a relatively large delay, the
effective BW that can be passed using TCP is relatively low and
does no make full usage of the possible free BW. In order to solve
that limitation, one implementation example may consists of the
LibraFlow server generates ACK to the WAN server and sends the data
to the end-user CPE without expecting any ACK. Since the last mile
i.e. the LibraFlow channel is very reliable (this is, in part, the
reason for the large delay) ACK-ing at the LibraFlow server is not
reducing the reliability of the transfer as a whole. The CPE at the
user premises is typically instructed to ignore the relevant flow
ACK originating form the user--user computing device networking TCP
stack. Another solution might be to implement a buffering at the
LibraFlow server (with buffer size equal to the amount of data sent
over the LibraFlow channel that still have not been acknowledged
(i.e. BW.times.Delay) and implement a TCP protocol between the
LibraFlow server and Client but with much larger TCP windows). It
should be noted that other implementations of performance
enhancement proxies (PEP) can be implemented without departing from
the general idea of the invention.
[0056] 3. System Architecture
[0057] The processes summarized above are illustrated by the
general system diagram of FIG. 4. In particular, the system diagram
of FIG. 4. illustrates the interrelationship between program (and
possible hardware) modules for implementing a LibraFlow, as
described herein.
[0058] 3.1. LibraFlow Client
[0059] In general, the LibraFlow Client driver are loaded by
default as part of the tuning device 414 initialization or the
end-user computing device 421 operating system loading or by
request of the user. Upon loading, The LibraFlow client registers
itself with the LibraFlow server and receive at least a client ID
and at least one destination IDs and potentially other parameters
(including, but not limited to DOCSIS MAC, encryption/decryption
keys, watermarks etc. . . . ). The client ID or DOCSIS MAC will
serve as identification as the source of the messages and
destination ID will serve to determine the destination of content
flowing from the server to the clients.
[0060] It should be noted that in some embodiments of the present
invention, the data is locally processed before being returned to
the application level. One such processing is, for example,
potentially personalized, advert insertion or replacing in content
type including, but not limited to, video, games etc. . . . ,
others include but are not limited to decryption and encryption of
the content according to a key received at some previous stage,
watermarking etc. . . .
[0061] Note that while the LibraFlow as described herein is
applicable for use in HFC networks, those skilled in the art will
understand that the above content processing embodiment offered by
LibraFlow driver is applicable to other network including but not
limited to wireless, ADSL, Satellite and the like or any other
environment with a combination of a fast link and a much broader
link with unused opportunities and a relatively high delay which
limits its use.
[0062] The LibraFlow Client driver (operating inside the CM in case
of a modified CM 415 or on a end-user computing device 421 in case
of STB 416 or DVB-C tuner 417) is interrupted by the LibraFlow
Tuner device Hardware (either internally in a CM 415 or externally
in case of a STB 416 or DVB-C Tuner 417 414) whenever there is
LibraFlow generated traffic to be inspected and processed. The
exact behavior is determined by the LibraFlow Hardware device. In
modified Cables Modems 415, the interface to the end-user computing
device is a regular Ethernet network interface 110 since the CM
modification is only at the DOCSIS level. The LibraFlow generated
traffic is sent to the LibraFlow client as regular DOCSIS MAC
frames or any other format (after being TS layer decapsulated by
the MAC Hardware usually existing in such CM 415). The DOCSIS MAC
is being decapsulated by the LibraFlow Client and sent via the
Ethernet interface to the end-user computing device, potentially
thru a router/switch/gateway where it is merged with traffic from
DOCSIS channels, as if it came from the regular DOCSIS channel.
Practically the same interface is used with STB 119, 416 running
a
[0063] LibraFlow client that extract the LibraFlow generated
traffic out of a video channel and send it over UDP/TCP/Raw to the
end user computing device via a network interface 110. A DVB-C
tuner 417 generally directly extracts the channel TS traffic
directly to the computing device memory 102. The LibraFlow Client,
in this case, decapsulate the TS and DOCSIS framing and insert the
IP directly in the Networking stack of the end-user computing
device as is depicted in FIG. 3 as if it came directly from the
DOCSIS channels.
[0064] In order to overcome the inefficiency of protocols such as
TCP over relatively high delay of the video channel (which is due
to dejittering buffer, dedrifting buffers, long interleaver etc. .
. . ) a Performance Enhancing Proxy (PEP) 450 or other similar
functionality is included at both sides of the video channels. 416,
451
[0065] The LibraFlow server determines which flow or session should
be delivered through the LibraFlow channels and whether it should
bypass the PEP mechanism or not. The LibraFlow server determines on
the nature of each flow by either deep packet inspection
functionality or by getting information from the Libra client.
[0066] 3.1.1. LibraFlow Tuning Device Hardware
[0067] Generally, the LibraFlow client listens for LibraFlow
traffic on preconfigured or dynamically chosen LibraFlow channels
and tunes the LibraFlow tuning device hardware 414 to that specific
frequency. The LibraFlow tuning device hardware might consist of a
DVB-C tuner 417 that captures and reads all data in a specific
frequency channel, a software modified Cable Modem 415 (software
modification is needed since the LibraFlow generated traffic is
sent over non DOCSIS channels and regular CM need to perform
various DOCSIS related operations before they can tune to a channel
as well as expects certain DOCSIS MAC framing or any other MAC
framing. In order for the CM to tune to a non DOCSIS channel and
extract all information from the channel, a special software that
skips the DOCSIS related steps (such as ranging, registration with
the CMTS etc. . . . ) or performs theme and then tune to the
LibraFlow frequency or perform them in one channel and let the
others tune for the LibraFlow traffic (e.g. in multi-tuners CPE
such as in DOCSIS-3 CM where a primary channel will be used for
registration and all DOCSIS control steps whereas all other
channels are free for LibraFlow activities), and is able to tune to
a certain frequency and decapsulate (from DOCSIS MAC or any other
encapsulation) and restructure (into IP) the received traffic and
send it to the computing device is needed. Typically, at least one
of the tuners in a DOCSIS 3 (or any backward compatibility) cable
modem for example, or a Set Top Box with a software that accept
commands from the LibraFlow client to tune to a certain channel
frequency, extract the transport packets, potentially encapsulate
then in some Ethernet framing (such as but not limited to UDP/TCP
and raw) and send them to the end user computing device to be
processed via various networking layers 312, 311 and 310. It is
understood that other embodiments that extract data from the video
channels may be utilized and structural changes may be made without
departing from the general idea just described. The data the
LibraFlow hardware reads from the frequency it is tuned to is
usually a Transport stream in the form of 701, The LibraFlow
hardware, in case of a DVB-C tuner, will then listen for LibraFlow
generated traffic 515 and extract the LibraFlow generated traffic
(TS packets encapsulating a DOCSIS MAC layer) which might either be
unicast (sent to a specific client) or multicast (in case the
content is sent to multiple clients). It should be noted that
various additional fields might have to be processed or discarded
such as, but not limited to, the PCR field in 705 which is needed
in order to send the LibraFlow generated traffic thru conventional
QAM device 413.
[0068] In some embodiment, the LibraFlow data 709 is extracted 713
and inserted in the local storage 516 cache 423 according to
preconfigured conditions (typically negotiated with the LibraFlow
server in order to provide a push to storage functionality, for
example.)
[0069] Regular keep-alive 517 notifications are potentially sent to
the LibraFlow server.
[0070] 3.2. LibraFlow Server
[0071] The LibraFlow content storage 409 is constantly updated by
the content ingesting, tagging and preprocessing module 403. This
module pre-fetches and caches the requested content from the WAN
401 (to which it is connected via typically a very broad
connection) and enables local injection of content (possibly
preprocessed for later adverts insertion at the client driver, for
example) for pushing into the LibraFlow client. In addition, this
module will be able to interface any external entity that will
assist it with any of its tasks. This module also enables placement
of content typically ahead of the content distribution in order to
ease the content distribution.
[0072] In one embodiment, the content ingesting, tagging and
preprocessing module 403, whenever it detects that the content
requested consists of a video content, preprocess the content in a
series of steps that include, but is not limited to, transcoding,
resolution change, frame rate change, and any other preprocessing
that will assist the content streaming to LibraFlow client over BW
restricted channel by adjusting the sent content to one or many of
the channel instantaneous properties (for example, available
BW).
[0073] The LibraFlow server 424 is listening for client request
messages either in form 702 or regular IP requests for data. Every
client request is potentially logged in the Session DB 408.
[0074] At periodical intervals 519, the prioritizing module 409
goes over all clients request and sort them according to specific
parameters that include, but is not limited to, request
characteristics such as popularity, urgency (real time streaming or
non-interactive download), size, requesting client service grade
(premium, regular etc. . . . ), various business related agreements
(such as files that are paid to be distributed to users via high
bandwidth channels), etc. . . . The LibraFlow transmission,
prioritizing and scheduling module 404 will then take the most
urgent requests, in one embodiment, interface the resource manager
405, in another embodiment interface the streamer 407 and
calculated the amount of free BW that is available for the next
transmission time slice (which can be of any duration). The
LibraFlow transmission, prioritizing and scheduling module 404
might decide, based on the available BW, for example, to send the
client a preprocessed version of its request (one such
preprocessing, for example, is encapsulation in DOCSIS MAC in order
for the traffic to pass the DOCSIS MAC layer of the target CM). It
will then schedule 520 the transmission of each of the LibraFlow
Transport packet traffic 701 and its relevant content 709 taken
from the LibraFlow storage 409 or rerouted into the streamer 407 by
controlling the switch 424 and configuring the output "leg" of
specific flows (that are received as a result of end-users IP
requests).
[0075] In one embodiment, the transmission details will be sent to
relevant LibraFlow clients in a LibraFlow message 714 over the
regular DOCSIS channel thru a typically TCP (or any other protocol,
such as but not limited to, UDP, raw Ethernet IP messages etc. . .
. ) connection with the LibraFlow client. The LibraFlow server will
then stream 407 the LibraFlow generated traffic into the
appropriate free BW channel 413. In other embodiment, the
transmission and frequency control will be sent along the video
channel along with other LibraFlow traffic.
[0076] In order to overcome the inefficiency of protocols such as
TCP over relatively high delay of the video channel (which is due
to dejittering buffer, dedrifting buffers, long interleaver etc. .
. . ) a Performance Enhancing Proxy (PEP) 450 or other similar
functionality is included at both sides of the video channels, 416,
451
[0077] 4. Operational Details of the LibraFlow System
[0078] 4.1. Topology Discovery
[0079] On each QAM channel that the LibraFlow server transmits its
data, it also transmits a dedicated message. The message that is
transmitted using a pre-defined multicast address is received by
each client that is tuned to a LibraFlow QAM channel. The message
contains two attributes:
[0080] 1. QAM channel Id: uniquely identifies the QAM channel among
all QAM channels in the system;
[0081] 2. IP address of the LibraFlow server.
[0082] The client sends messages to the server (for example, to
request specific content) using the IP address that it obtained
from the above message. The message sent by the client to the
server contains all the information needed by the server in order
to reach the client. This includes the IP and MAC addresses of the
user that requested content and the unique QAM channel id. The
server then uses the above information by using the IP and MAC
addresses when encapsulating the content as DOCSIS frames and by
delivering the DOCSIS frames on the appropriate QAM channel to
which the client is tuned. The server may alternatively discover
the serving area from the QAM channel ID and possibly tune the
client to another QAM channel.
[0083] 4.2. Client Capabilities Discovery
[0084] The client optionally transmits to the server, information
regarding its capabilities, such as but not limited to number of
tuners, number of QAMs channels per tuners, QAM channel bandwidth
(ITU-A, ITU-B), number of users (CPE) supported, and/or maximum
bitrate per CPE.
[0085] 4.3. Client Identification
[0086] The client optionally transmits to the server,
identification information such as but not limited to vendor ID,
model number, and/or serial number.
[0087] 4.4. Client Statistics
[0088] The server may aggregate one or more client events for
statistic analysis and illustration.
[0089] 4.5. Registration of Data Requests and Replies
[0090] All interactive LibraFlow Registration and message passing
from server to client and vice versa is done either over regular
DOCSIS channel or OOB since it requires a two way channel (upload
and download) but generally does not consume a lot of BW or via the
LibraFlow channel itself in case it is download only.
[0091] Data transfer replies and frequency change requests from the
LibraFlow server are done over video channels (when available BW
exists), potentially with the addressing tag (multicast/unicast)
used to target the destination tuners or with the regular DOCSIS
MAC and regular Ethernet headers. This traffic is generally of high
BW and of download direction only.
[0092] The messages flowing from the server into clients can be
changed in order to allow additional benefits including, but not
limited to, content encryption or DRM.
[0093] In one embodiment, the content is kept encrypted at the
LibraFlow server and the decryption is done at the LibraFlow client
using keys transmitted at earlier stage. In such embodiment, the
content provider has more control on users that are able to access
a clear version of their content. One such control would be to
decrypt the content at the LibraFlow Client and potentially insert
a watermark.
[0094] 4.6. LibraFlow Transmission
[0095] The available BW in the video channels can be allocated from
several sources: one such source is a Resource Manager 405
typically existing in switched digital video installations that
provisions all QAMs BW allocated for switched services and can
grant available BW upon request. Another method is by buffering the
video traffic (including VOD, and even broadcast video channels)
and replacing NULLs or other TS packets. Another way is to imitate
the Edge device and create from several Single Program Transport
Stream (SPTS) (including the LibraFlow generated traffic as one or
more SPTS services) a Multiple Program Transport Stream (MPTS) that
can be delivered to the Edge device.
[0096] In order to take advantage of video transport channels
existing modulators (i.e. not only DOCSIS modulator with all their
derived complexity), the LibraFlow generated traffic is
"encapsulated" as video transport traffic and sent on a DOCSIS pid
(typically 0x1ffe) so as to come thru DOCSIS MAC hardware in
end-user CPE or can be sent in any other MPEG TS level mechanism.
Generally, edge QAMs 413 uses the Program Clock Reference (PCR) in
order to calculate the Bit Rate (BR) with which to stream the
traffic to the physical HFC lines. In order to emulate video TS
traffic, PCR are inserted in the LibraFlow Transport packets at
regular interval (typically every tenth of milliseconds) and are
restamped according to the BR the LibraFlow generated traffic is
sent at. Typically, the PCR pid is on another PID than the DOCSIS
pid, in some cases PCR insertion may not be needed.
[0097] In cases there is no possibility to send a LibraFlow stream
to an edge QAM (including, but not limited to, cases where a VOD
server provides an already built video channel mux to be directly
modulated and transmitted by the edge QAM or broadcast channels
that are flowing out of muxing devices and contain available BW),
the LibraFlow generated traffic can be inserted by packet
replacement technique. In this method, all traffic originating from
the video source 406 is fed into LibraFlow content streamer 407
where it is subjected to a small fix time delay. While in this time
delay, LibraFlow generated traffic originating from 404 can be
inserted instead or in addition to the original video streams. It
should be noted that additional stream characteristic such as but
not limited to Program Specific Information (PSI) packets should be
updated to reflect the addition of the new service (including, but
not limited to, setting the LibraFlow generated traffic as a
private data in a new service so that no interference might occur
with the video services).
[0098] The LibraFlow server monitors, load balances and negotiates
available BW with the Resource Manager 405 for the LibraFlow
generated traffic between all video channels having available BW in
order to fully utilize the free BW in all video channels.
[0099] FIG. 6. provides the benefits in a preferred embodiment in
which the application may be used. It can be seen how in legacy HFC
network, the IP fills up the DOCSIS channel 604 while the video
channels 607 are mostly unused. Using LibraFlow, the IP requests
messages are transparently caught up in the CM 606 preprocessed and
sent to the LibraFlow server located at the cable operator premises
601 or directly caught up at the HE/HUB 601 in the LibraFlow
server. The IP traffic, whether brought in immediately from the WAN
or already existing at the server storage (since it was cached in
some earlier stage or pushed by a content provider or even
requested from another entity having the content in available form,
for example) at the Cable operator premises is either encapsulated
in LibraFlow generated traffic and is sent via the video channels
612 while they are unused (and thus enable much more BW available
to the end user while freeing DOCSIS channels for other more
interactive applications with less download characteristics) or
rerouted using a switch from the WAN into the Video channels thru
the LibraFlow streamer to be encapsulated in DOCSIS MAC and added
PCR pid. A LibraFlow tuning device 611 (software modified CM, DVB-C
tuner with special LibraFlow driver implementing the LibraFlow
Client), or a STB with a LibraFlow client 613 picks up the
LibraFlow generated traffic, process it (potentially adapting it to
the end user including, but not limited to content personalization
and targeted advertising) and transparently transfer it to the end
user computing device 606 to be placed in a local cache or used
immediately as part of the regular networking stack.
[0100] The foregoing description of the LibraFlow has been
presented for the purposes of illustration and description. It is
not intended to be exhaustive or to limit the invention to the
precise form disclosed. Many modifications and variations are
possible in light of the above teaching. Further, it should be
noted that any or all of the aforementioned alternate embodiments
may be used in any combination desired to form additional hybrid
embodiments of the LibraFlow.
* * * * *