Patent Application
20080209489
1. Field of the Invention
The invention relates to the delivery of digital content, such as Internet Protocol Television (IPTV) video content, over cable systems using a standard protocol Data Over Cable System Interface Specification (DOCSIS). More particularly, the invention relates to transmitting digital content within systems involving Cable Modem Termination System (CMTS) architecture and processing.
2. Description of the Related Art
Most cable systems currently provide video (and data) content delivery services via digital broadcast. The video image is first digitized, and then compressed, e.g., via one of several digital algorithms or compression standards, such as the MPEG2 (Moving Pictures Expert Group) algorithm or the MPEG4 part 10 algorithm, where the latter also is known as the International Telecommunications Union (ITU) H.264 standard. These compression standards allow the same video content to be represented with fewer data bits. Using MPEG2, standard definition television currently can be transmitted at a rate of approximately 4 Megabits per second (Mbps). Using MPEG 4 Part 10, the same video content can be transmitted at a rate of approximately 2 Mbps. The digital video content typically is transmitted from a source at the cable headend to the end user's set-top box (or other suitable video processing device) via a digitally modulated radio frequency (RF) carrier, with the video content organized into a format known as an MPEG2 Transport Stream (MPEG2-TS).
Cable system operators are considering Internet Protocol (IP)-based methods for content delivery, such as IP-video and IP Television (IPTV), to supplement their current digital video delivery methods. The internet protocol is not required for MPEG2 Transport Streams. However, IP-based video delivery allows the possibility of new video sources, such as the Internet, and new video destinations, such as end user IPTV playback devices. If cable systems do include IP-based content delivery, it is quite possible and likely that relatively large amounts of bandwidth will be needed to deliver IPTV content to end users. Moreover, as end users continue to shift their viewing desires toward on-demand applications, a relatively large percentage of such on-demand content likely will be IPTV content.
To cope with the anticipated surge of IPTV viewing, the cable industry developed the Data Over Cable System Interface Specification (DOCSIS®) standard or protocol, including the DOCSIS 3.0 standard. In general, DOCSIS defines interface requirements for cable modems involved in high-speed data distribution over cable television system networks. The cable industry also developed the Cable Modem Termination System (CMTS) architecture and the Modular CMTS (M-CMTS™) architecture for this purpose. In general, a CMTS is a component, typically located at the headend or local office of a cable television company, that exchanges digital signals with cable modems on a cable network.
In general, an EdgeQAM (EQAM) or EQAM modulator is a headend or hub device that receives packets of digital content, such as video or data, re-packetizes the digital content into an MPEG transport stream, and digitally modulates the digital transport stream onto a downstream RF carrier using Quadrature Amplitude Modulation (QAM). EdgeQAMs are used for both digital broadcast, and DOCSIS downstream transmission. In a conventional IPTV network system arrangement using M-CMTS architecture, the EdgeQAMs are downstream DOCSIS modulators, and are separated from a core portion of the M-CMTS core. An IPTV server or other suitable content provider is coupled to a regional area or backbone network. This backbone network, in turn, is connected to a converged interconnect network (CIN) which also links the M-CMTS core and the EdgeQAMs. The CIN performs as one or more access routers, i.e., devices configured for routing data in an IP network. There is a Layer Two Tunneling Protocol version 3 (L2TPv3) tunnel from the M-CMTS core to the EdgeQAMs, this tunnel being identified as a Downstream External Physical Interface (DEPI). The IP-video is carried on the downstream DOCSIS RF carrier from the EdgeQAM to the end user video or multimedia content processing device, such as a DOCSIS set-top box or an Internet Protocol set-top box (IP-STB). An IP set-top box is a set-top box or other multimedia content processing device that can use a broadband network to connect to television data channels, video streams and other multimedia content. An upstream DOCSIS receiver is coupled to and receives data, such as on-demand commands, from the end user multimedia content processing device. Upstream DOCSIS receivers are combined with or contained within a core portion of the M-CMTS component.
Since the upstream DOCSIS receivers are combined with, or comprise a part of, the M-CMTS core and its processing, all packets traveling upstream or downstream typically travel through the M-CMTS core for appropriate forwarding to the correct network interface or DOCSIS carrier. However, since the downstream DOCSIS modulators (i.e., the EQAMs) are separate from the M-CMTS core, the downstream packets travel from the M-CMTS core, through the CIN, and to the EQAMs on special “tunnel” or “pseudo-wire” connections. These tunnels, which are defined by the Layer Two Tunneling Protocol (L2TP) version 3 (i.e., L2TPv3), are known within the DOCSIS 3.0 standard as Downstream External Physical Interface (DEPI) tunnels, and typically are in the form of gigabit Ethernet fiber links.
One of the features of the DOCSIS 3.0 specification intended to facilitate the use of IPTV content delivery is that the number of downstream EQAMs can be increased independently of the number of upstream DOCSIS data channels. Hence, the downstream DOCSIS capacity can be arbitrarily increased to whatever bandwidth is needed. However, as discussed, downstream IPTV content or data packet flow from the IPTV server to the end user DOCSIS set-top box conventionally is required to travel on a DEPI tunnel, from the M-CMTS core, then back through the CIN, and on to the EQAM. Such “hairpin” forwarding of downstream data packets back through the CIN requires a disproportionate amount of switching bandwidth and other resources compared to other portions of the system.
In the following description, like reference numerals indicate like components to enhance the understanding of the system bypass architecture and corresponding data transmission methods through the description of the drawings. Also, although specific features, configurations and arrangements are discussed herein below, it should be understood that such specificity is for illustrative purposes only. A person skilled in the relevant art will recognize that other steps, configurations and arrangements are useful without departing from the spirit and scope of the invention.
The methods and systems described herein involve direct tunneling of digital content, such as IPTV video content, from a content source to a downstream modulator, such as a downstream Edge QAM, (EQAM), in a manner that bypasses the modular Cable Modem Termination System (M-CMTS), including the M-CMTS core. In conventional system arrangements that use an M-CMTS, downstream IPTV content travels from the IPTV source or server to the converged interconnect network (CIN), via a regional area network, and then to the M-CMTS and the M-CMTS core. The IPTV content then travels back through the CIN and then to the downstream DOCSIS modulator (e.g., the EQAM) using a special “tunnel” or “pseudo-wire” connection, such as a Downstream External Physical Interface (DEPI) tunnel. By tunneling content directly to the downstream modulators, the bypass methods and systems described herein require or involve fewer M-CMTS components and less CIN switching bandwidth than conventional system arrangements. In this manner, the cost savings involved in bypassing relatively expensive CMTS components allows content providers to deliver relatively high-bandwidth content, such as IPTV video content, to end users at a cost that is comparable to the delivery of conventional video content using MPEG2 and other conventional content transmission methods.
Referring now to
Coupled to the regional area network 114 is a converged interconnect network (CIN) 118, which includes the routing and switching capability for connecting the regional area network 114 to a Cable Modem Termination System (CMTS), such as a modular CMTS (M-CMTS) 122. In general, as discussed hereinabove, the CIN typically performs as an access router for routing data in an IP network. The CIN typically has gigabit Ethernet interfaces and can perform layer 2/3/4 forwarding, i.e., routing of data in layers 2, 3 and 4 as defined according to the seven-layer Open Systems Interconnection (OSI) network protocol. In general, a CMTS or an M-CMTS is a component that exchanges digital signals with network elements (such as cable modems, set-top boxes and other content processing devices, and media terminal adapters) on a cable network. The CMTS or M-CMTS typically is located at the local office of a cable television company.
The M-CMTS 122 includes an M-CMTS core 124, which typically includes or contains one or more upstream receivers 126, such as an upstream DOCSIS receiver. The M-CMTS 122 also includes one or more downstream DOCSIS modulators, such as one or more EdgeQAMs (EQAMs) 128, which are external to and not part of the M-CMTS core 124. The M-CMTS 122 typically is connected to one or more network elements 132, such as an end user cable modem, a set-top box and/or a media terminal adapter (MTA). The M-CMTS 122 typically is connected to the network elements 132 via an end user network, which typically is Hybrid Fiber Coaxial (HFC) cable network 134 and/or other suitable end user network or network system.
The upstream receiver 126 is configured to receive upstream IP/DOCSIS transmissions, such as on-demand commands from an end user set-top box. The upstream data is transmitted to the upstream receiver 126 via the network 134 and an upstream data channel 142 coupled between the network 134 and the upstream receiver 126. The M-CMTS core 124, which includes the upstream receiver 126, converts the received upstream data to Internet Protocol (IP) packets, which then are sent to an IP router, or other suitable device or component, for transmission across the CIN 118 and the regional area network 114. For downstream data, the M-CMTS 122 uses one or more EQAMs 128 or other suitable downstream modulators to convert the IP packet data to a DOCSIS formatted transport stream or other suitable digital transport stream and modulate the digital transport stream onto a downstream RF carrier using Quadrature Amplitude Modulation (QAM) to the network elements 132. The downstream data is transmitted from the EQAM 28 to the network elements 132 via the network 134 and a downstream data channel 144 coupled between the EQAM 128 and the network 134.
One or more of the components within the M-CMTS 122, including one or more of the M-CMTS core 124, the upstream receiver 126 and the EQAM 128 can be comprised partially or completely of any suitable structure or arrangement, e.g., one or more integrated circuits. Also, it should be understood that the M-CMTS 122 includes other components, hardware and software (not shown) that are used for the operation of other features and functions of the M-CMTS 122 not specifically described herein. Also, the M-CMTS 122 can be partially or completely configured in the form of hardware circuitry and/or other hardware components within a larger device or group of components. Alternatively, the M-CMTS 122 can be partially or completely configured in the form of software, e.g., as processing instructions and/or one or more sets of logic or computer code. In such configuration, the logic or processing instructions typically are stored in a data storage device (not shown). The data storage device typically is coupled to a processor or controller (not shown). The processor accesses the necessary instructions from the data storage device and executes the instructions or transfers the instructions to the appropriate location within the M-CMTS 122.
A DOCSIS 3.0 cable modem and other network elements are able to receive multiple downstream channels 144. According to the DOCSIS 3.0 standard, there may be “primary” and “non-primary” downstream channels. Of these, one and only one will be the network elements' “primary” downstream channel. The network elements will only receive synchronization time-stamps, which are necessary for upstream operation and which are known as SYNC messages, on its primary downstream channel. Thus, the “primary” channel is also a “synchronized” channel. The network elements also rely on the “primary” channel for the delivery of Mac Domain Descriptor (MDD) messages, which enable the network elements to perform operations including plant topology resolution and initial upstream channel selection. During initialization, the network elements are only required to receive Upstream Bandwidth Allocation Maps (MAPs) and Upstream Channel Descriptors (UCDs) on its “primary” downstream channel.
In systems using M-CMTS architecture, the IP data packets traveling upstream or downstream typically travel through the M-CMTS core 124 for appropriate processing and subsequent forwarding to the correct network interface or data carrier, such as a DOCSIS carrier. Since the upstream receiver 126 is combined with the M-CMTS core 24 and its processing, upstream data received by the upstream receiver 126 can be transmitted directly from the upstream receiver 126 to the M-CMTS core 124 and then forwarded appropriately. However, since the downstream modulator (EQAM 128) is not part of the M-CMTS core 124, downstream data received by the M-CMTS 122 from the CIN 118 travels first through the M-CMTS core 124 for appropriate processing and then is directed to the EQAM 128 for appropriate conversion and modulation. Downstream data packets from the M-CMTS core 124 conventionally must travel back through the CIN 118 and then to the EQAM 128 using special “tunnel” or “pseudo-wire” connections, such as downstream or DOCSIS Downstream External Physical Interface (DEPI) tunnels. As discussed hereinabove, such “hairpin” forwarding from the M-CMTS core 124 back through the CIN 118 to the EQAM 128 will require a disproportionate amount of switching bandwidth for the M-CMTS core 124 and the CIN 118.
Referring now to
Also, alternatively, M-CMTS bypass architecture can be used in systems that include an integrated CMTS, rather than a more expensive M-CMTS. In this manner, the bypass architecture makes it possible to deploy an integrated CMTS with additional external DEPI EQAMs. The integrated CMTS includes a “synchronized” or “primary” downstream DOCSIS data channel from the integrated CMTS to the end user network elements, in addition to the downstream DOCSIS data channels from the EQAM to the end user network elements, which may be “synchronized” or “non-synchronized.” Referring now to
Because IPTV content can be delivered to DOCSIS cable modems and other network elements 32 using non-synchronized downstream data channels, the EQAM 28 can be used to deliver IPTV content, even when the EQAM 28 is not synchronized to the DOCSIS master clock with the DOCSIS Timing Interface (DTI) (not shown), which is part of the integrated CMTS 62. DOCSIS modems require DOCSIS master clock synchronization on only one synchronized data channel, the so-called “primary” downstream data channel. Therefore, such synchronization can be supplied by the integrated CMTS 62, via the “synchronized” downstream DOCSIS data channel 64. Alternatively, such synchronization can be supplied by a single M-CMTS EQAM that is synchronized to the DOCSIS master clock with the DOCSIS DTI.
By using the CMTS bypass architecture, the system 60 avoids the expense of the CMTS or the M-CMTS having to establish or generate both synchronized and non-synchronized downstream data channels for delivery of IPTV content. A single synchronized data channel from the integrated CMTS 62 or its core can provide the synchronization timestamps, and also provide other DOCSIS Media Access Control (MAC) functions, including instructing the network elements 32 when to transmit upstream and delivering other MAC layer messages for various network element functions, such as registration and maintenance. One or more non-synchronized DOCSIS data channels can be established or generated for one or more EQAMs 28. A non-synchronized DOCSIS data channel generated for an EQAM is less expensive than generating a synchronized DOCSIS data channel for an integrated CMTS or an M-CMTS. Also, with an integrated CMTS and no timestamps in the non-synchronized data channel, the DTI (which is required in the M-CMTS architecture) is not necessary in systems using CMTS bypass architecture.
Depending on the content source 12, the regional area network 14 and the CIN 18, as well as the type of EQAM 28, IPTV content delivery systems using CMTS bypass architecture can use many different tunneling techniques and therefore have many suitable bypass data encapsulations. Data encapsulation generally is the process of taking a packet of a particular format that contains data as its payload, and enveloping or encapsulating that entire packet as the payload of a new packet. The new packet is generally formed by adding additional header fields, of a different format, to the old packet, which becomes the payload. The outermost header must be compatible with the device receiving the data. If the EQAM 28 is an M-CMTS DEPI EQAM (DEPI EQAM), data encapsulation can occur using at least two DEPI tunneling techniques. Using either tunneling technique, the content source 12 generates or originates an L2TPv3 (DEPI) tunnel to the DEPI EQAM. In the first DEPI tunneling technique, known as the DOCSIS Packet Stream Protocol (PSP), IPTV content is encapsulated into DOCSIS MAC frames or data packets, i.e., DOCSIS frames are transported in the L2TPv3 tunnel payload (data). In general, the PSP allows DOCSIS frames to be appended together in a queue, using either concatenation (to increase network performance) or fragmentation (if tunneled packets are too large). The PSP DEPI tunneling technique allows the EQAM 28 to mix both IPTV content originated from the IPTV server 12 with non-IPTV content, such as VOIP (Voice over Internet Protocol) data originated from the M-CMTS core 24, on the same DOCSIS downstream data carrier.
in the second DEPI tunneling technique, known as DOCSIS MPEG Transport (D-MPT), multiple 188-byte MPEG2 Transport Stream (MPEG-TS) packets are transported in the L2TPv3 tunnel payload. In D-MPT, IPTV content is encapsulated into DOCSIS MAC frames and the DOCSIS MAC frames are encapsulated into MPEG-TS packets. All DOCSIS frames, including packet-based frames and any necessary MAC management-based frames, are included within the one D-MPT data flow. The EQAM searches the D-MPT payload for any DOCSIS SYNC messages and performs SYNC corrections. The EQAM then forwards the D-MPT packet to the RF interface, for transmission on the RF data carrier. Using the D-MPT tunneling technique, MPEG packets can be received by the EQAM and forwarded directly to the RF interface without having to terminate and regenerate the MPEG framing. The only manipulation of the D-MPT payload is the SYNC correction.
Alternatively, the EQAM 28 can be a standard MPEG2 Transport Stream (MPEG2-TS) EQAM. If the EQAM 28 is an MPEG2-TS EQAM, the IPTV server 12 can transmit IPTV content in PSP formatted data packets. In such case, a PSP/MPT converter is used to convert the data format into an MPEG2-TS format, which an MPEG2-TS EQAM can process. The PSP/MPT converter can be attached to or embedded within the CIN 18 or one or more networking devices within the CIN 18. Alternatively, the IPTV server 12 can directly generate and transmit IPTV in MPT formatted data packets, which the MPEG2-TS EQAM can process.
In the case of non-synchronized DOCSIS data channels, e.g., the non-synchronized DOCSIS downstream data channel 44 in the system 60 shown in
To describe these and other CMTS bypass architecture data format implementations, corresponding system diagrams are shown and described. Referring now to
The DEPI tunnel 65 carries the DOCSIS PSP data, in which the IPTV data is encapsulated into DOCSIS MAC frames. The PSP is a layer-3 convergence layer protocol, which allows packets to be consecutively streamed together and fragmented at arbitrary boundaries. The intent of the PSP mode is to facilitate Quality of Service. The PSP mode is to be used for transporting traditional DOCSIS data and signaling messages that use one or more Differentiated Services Code Point (DSCP) values. Each PSP flow is terminated, and the DOCSIS Frames within the flow are extracted. The DOCSIS frames are placed into corresponding output Quality of Service (QoS) queues. The queues are serviced-based upon the data forwarding behavior or per hop behavior (negotiated between the M-CMTS Core and EQAM) of the PSP flow, which carried the DOCSIS frames. The EdgeQAM places the resulting flow of DOCSIS frames into MPEG packets according to the requirements in the DOCSIS specification. The PSP allows the EQAM 28 to mix both IPTV traffic originated from the IPTV server 12 and non-IPTV frames (e.g., VOIP) from different sources.
The DEPI EQAM 28 terminates the DEPI tunnel 64, and inserts the DOCSIS SYNC messages. However, in some cases (e.g., with bonded data channels) the DEPI EQAM 28 can output a DOCSIS RF signal that does not carry timing information in the form of SYNC messages. Finally, the DEPI EQAM 28 does the encapsulation of the DOCSIS MAC messages into the MPEG2-TS format and generates the QAM carriers.
With respect to the corresponding data encapsulations shown in
In an alternative data encapsulation technique, the IPTV server 12 is left unchanged and the IPTV data traffic from the IPTV server 12 is intercepted in the CIN 18 and converted to PSP for transmission to the EQAM 28. Referring now to
In another alternative data encapsulation technique, the IPTV data traffic from the IPTV server 12 is intercepted in the CIN 18 and converted to D-MPT for transmission to the EQAM 28, e.g., a non-DEPI, MPEG EQAM. Referring now to
Alternatively, the IPTV server 12 can be modified to generate the complete IPTV MPT data encapsulation. Referring now to
In an alternative arrangement, the EQAM 28 is a DIBA (DOCSIS IPTV Bypass Architecture) EQAM that includes additional functionality for encapsulation. Referring now to
Referring now to
The method 70 also includes a step 74 of establishing one or more connections, such as tunnel connections, from the content server 12 to the EQAM 28, e.g., via the regional area network 14 and the CIN 18. As discussed hereinabove, the connections can be special “tunnel” or “pseudo-wire” connections, such as DEPI tunnels. For example, a direct tunnel connection can be established from the content server 12 to the EQAM 28 through the regional area network 14 and the CIN 18. Alternatively, a first tunnel connection can be established between the content server 12 and the regional area network 14, and a second tunnel connection can be established between the regional area network 14 and a second the CIN 18.
The method 70 also includes a step 76 of transmitting digital content from the content source to one or more networks, e.g., using the established tunnel connection(s) therebetween For example, the transmitting step 76 can include transmitting IPTV content from the content server 12 to the regional area network 14 and/or the CIN 18, using the established tunnel connections therebetween.
The method 70 can include a step 78 of converting the data format of the digital content prior to the content being transmitted to one or more networks and/or a step 82 of converting the data format of the digital content prior to the content being transmitted to the EQAM 28. Depending on the desired data format of the content that is transmitted to the EQAM 28, the content server 12 can be configured to convert content to one of several data formats or encapsulations. In this manner, the content server 12 performs the step 78 of converting the data format of the digital content prior to the content being transmitted to one or more networks, i.e., prior to the content server 12 transmitting the content to the regional area network 14 and the CIN 18.
Alternatively, depending on the desired data format of the content that is transmitted to the EQAM 28, one or more components located in or coupled to the CIN 18 can be configured to convert content to one of several data formats or encapsulations. For example, as discussed hereinabove, the interceptor 66 and/of the converter 68 can perform the step 82 of converting the data format of the digital content prior to the content being transmitted to the EQAM 28. In this manner, the content is converted to a data format that is suitable to be received by the EQAM 28.
The method 70 also includes a step 84 of transmitting digital content to the EQAM 28 in a manner that bypasses the M-CMTS 22, the M-CMTS core 24, or the integrated CMTS 62 that supports an external EdgeQAM. As discussed hereinabove, digital content is transmitted directly from the IPTV content server 12 to the EQAM 28, i.e., without passing through the M-CMTS 22 and the M-CMTS core 24. Bypassing the M-CMTS 22 reduces, if not eliminates, the involvement of M-CMTS components in the process of downstream content transmission and reduces the amount of CIN network switching bandwidth needed to transmit downstream content to the EQAM 28.
The method 70 also includes a step 86 of transmitting digital content from the EQAM 28 to the end user, e.g., to the network elements 32. As discussed hereinabove, content received by the EQAM 28 is formatted or encapsulated appropriately for transmission to and receipt by the network elements 32.
The CMTS bypass architecture described hereinabove is suitable for use with other IPTV digital content delivery system configurations, such as broadcast IPTV. That is, the CMTS bypass architecture described hereinabove can be used in systems that deliver broadcast video as an IP multicast. In conventional broadcast IPTV arrangements, the set-top boxes are not IP set-top boxes, so the EQAM (MPEG EQAM) joins the IP multicast group. The multicast group then is mapped to a particular QAM and PID, and it is the information as to the particular QAM and PID to which the multicast group is mapped that is forwarded to the set-top box to enable the set-top box to receive the MPEG2 video transport stream. Conventionally, because of cost, the DOCSIS format generally is not used to deliver broadcast IPTV content. However, using M-CMTS bypass architecture, providing DOCSIS bandwidth does not have to be cost prohibitive. Thus, an IP set-top box will be able to join the IP multicast group. The switched broadcast control plane determines which programs are multicast to which fiber node, consistent with the IP set-top boxes receiving which programs.
For broadcast IPTV, there are several tunneling options that are suitable for use, such as many of the tunneling configurations discussed hereinabove, including “interception,” in which SPTS/UDP/IP encapsulation is intercepted by a CIN multicast router (i.e., the IPTV Interceptor 66) and encapsulated into the PSP format. Another tunneling option is the transmission of PSP data directly from the IPTV server 12 to the DEPI EQAM. For bonded IP multicast, the IPTV Interceptor 66 can include a distributor component that distributes or “stripes” the IP data packet to a pre-configured DOCSIS 3.0 Downstream Bonding Group.
Also, broadcast IPTV is possible with both DOCSIS 2.0 and 3.0 network elements, including DOCSIS 2.0 and 3.0 cable modems. In either case, the IP set-top box sends an IGMP (Internet Group Management Protocol) join instruction to an IP multicast session for a particular program. The DOCSIS 2.0 modem uses a synchronized DOCSIS downstream data channel, while a DOCSIS 3.0 modem can receive content on a bonded data channel set or a downstream channel set. It may or may not be necessary to change DOCSIS data channels to change to a new IPTV “data channel.” However, any changing of DOCSIS data channels involves communication from the CMTS to the network elements in the form of a Dynamic Data channel Change (DOCSIS 2.0) or Dynamic Bonding Change (DOCSIS 3.0) instruction to change a tuner of one or more network elements to the new data channel.
The method shown in
It will be apparent to those skilled in the art that many changes and substitutions can be made to the bypass architecture systems and methods herein described without departing from the spirit and scope of the invention as defined by the appended claims and their full scope of equivalents.
This application claims priority to the filing date of a U.S. provisional patent application having Ser. No. 60/892,070, entitled “DOCSIS IP-Video Bypass Architecture”, filed on Feb. 28, 2007, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60892070 | Feb 2007 | US |
