The present document defines the RF characteristics required in the downstream transmitter(s) of DOCSIS 3.0 CMTSs
and EQAMs, sufficiently enough to permit vendors to build devices that meet the needs of cable operators around the
world.
In addition to defining these requirements for a DOCSIS 3.0 device, the present document could also be applicable to
other devices such as:
• an Edge QAM (EQAM) not being used for DOCSIS 3.0 services; or
• an integrated Cable Modem Termination System (CMTS) with multiple downstream channels per RF port
previous to DOCSIS 3.0.
There are differences in the cable spectrum planning practices adopted for different networks in the world. Therefore
two options for physical layer technology are included, which have equal priority and are not required to be
interoperable. One technology option is based on the downstream multi-program television distribution that is deployed
in North America using 6 MHz channelling. The other technology option is based on the corresponding European
multi-program television distribution. Both options have the same status, notwithstanding that the document structure
does not reflect this equal priority. The first of these options is defined in clauses 5, 6 and 7, whereas the second is
defined by replacing the content of those clauses with the content of annex A. Correspondingly, [4] and [2] apply only
to the first option, and EN 300 429 [8] only to the second. Compliance with the present document requires compliance
with the one or the other of these implementations, not with both. It is not required that equipment built to one option
will interoperate with equipment built to the other.
A DRFI-compliant device may be a single-channel only device, or it may be a multiple-channel device capable of
generating one or multiple downstream RF carriers simultaneously on one RF output port. An EQAM may be a module
of a modular cable modem termination system (M-CMTS) and be used for delivering a high-speed data service or it
may serve as a component of a digital video or Video-on-Demand (VoD) system, delivering high quality digital video
to subscribers. These specifications are crafted to enable an EQAM to be used without restriction in either or both
service delivery scenarios simultaneously. "Simultaneous" in the early deployments means that if a RF output port has
multiple QAM channels, some channel(s) may be delivering high-speed data while some other channel(s) may be
delivering digital video. The present document enables future uses, wherein a single QAM channel may share
bandwidth between high-speed data and digital video in the same MPEG transport stream.
Conceptually, an EQAM will accept input via an Ethernet link, integrate the incoming data into an MPEG transport
stream, modulate one of a plurality of RF carriers, per these specifications, and deliver the carrier to a single RF output
connector shared in common with all modulators. Conceivably, a single EQAM RF channel could be used for data and
video simultaneously. The reason that an EQAM RF channel can be used for either is that both digital video and
DOCSIS data downstream channels are based on ITU-T Recommendation J.83 [4], annex B for cable networks in North
America and EN 300 429 [8] for cable networks deployed in Europe. On downstream channels complying to ITU-T
Recommendation J.83 [4], annex B, typically, the only difference between an EQAM RF channel operating in a video
mode and an EQAM RF channel operating in DOCSIS data mode is the interleaver depth (see clauses 6.3.1 and 6.3.3).
DOCSIS data runs in a low latency mode using a shallow interleaver depth at the cost of some burst protection.
DOCSIS data can do this because if a transmission error occurs, the higher layer protocols will request re-transmission
of the missing data. For video, the sequence of frames in the program is both time sensitive and order sensitive and
cannot be re-transmitted. For this reason, video uses a deeper interleaver depth to provide more extensive burst
protection and deliver more of the program content without loss. The penalty video pays is in latency. The entire
program content is delayed by a few milliseconds, typically, and is invisible to the viewers of the program. The
conflicting demands for interleaver depth are what prevent a single EQAM RF channel from being used optimally for
video and DOCSIS data simultaneously. A traditional integrated CMTS, however, is used solely for DOCSIS data.
PUBLISHED
SSH EN 302 878-3 V1.1.1:2011
60.60
Standard published
May 24, 2016