A solution that delivers the OOB streams to the RPD via the same Ethernet carriers that the rest of the services traverse
is necessary. This solution is necessary to facilitate the delivery of OOB streams from the headend to the customer-facing CPE using the Remote PHY (R-PHY) architecture. The following sections describe 55–1 OOB approaches to this transport:
For downstream:
-
Ethernet from the out-of-band Modulator (OM) device: The OM processes OOB source streams as per SCTE-55-1 and outputs datagrams
via IP multicast.
-
CCAP-Core forward as virtual OM.: The CCAP joins and processes streams from the OM device as per SCTE-55-1 and forwards them
downstream to the RPD.
For upstream:
-
ATM from STB: The STB sends augmented ATM upstream packet to RPD according to SCTE-55-1. RPD builds up upstream packet as
per ARPD protocol (version 2) and forwards it to the CCAP core.
-
CCAP-Core forward as virtual ARPD: The CCAP receives 55–1 packet via UEPI and forwards them upstream to the Network Controller
(NC).
The out-of-band Modulator (OM) handles receiving of OOB source data streams and creating multiplexed signal according to OOB
55–1. The MPEG transport stream, containing the OOB is IP multicast using the UDP to the CCAP Core over an Ethernet link.
Each OM can output only a single OOB multiplex. Hence, a CCAP Core may receive OOB streams from multiple OMs. Each of these
streams is intended for a different set of RPDs.
OM2000 does not include null frames in its Ethernet output stream. The OM outputs nonnull packets in its Ethernet output transport
streams. Hence, the downstream QPSK modulator must insert nulls when necessary. The Remote PHY device inserts null packets
as necessary to maintain the required module rate of the OOB 55–1 downstream QPSK channel. The downstream modulator need not
maintain precise interpacket timing. The modulator can effectively insert null packets wherever necessary without checking
for excessive data packet displacement.
Each virtual ARPD uses a unique source IP address and a unique destination UDP port in packets that are sent to the NC. The
NC relies on IP addresses and UDP ports to identify the ARPD from which the traffic is arriving.
Using GCP, the CCAP Core configures the attached RPDs with the appropriate ARPD source ID, RF port ID, and demodulator ID
corresponding to each UEPI tunnel. The RPD uses this information when forming the ARPD datagram.
From Cisco IOS XE Amsterdam 17.3.1x release, the CCAP core can merge 55–1 upstream data-path traffic from both physical RF ports of an RPD before forwarding to the NC. You can do this by configuring the same profile (ARPD source ID, RF port ID, and demodulator ID) to both Upstream physical RF ports in an RPD. This feature enables service providers to
expand the 55-1 service group on to the second US port without the need for extra hardware for 55-1 headend.
The RPD aggregates multiple physical demodulators into a single virtual ARPD demodulator ID.
The RPD supports power level settings in the range of -7 to 0 dBc relative to the 256-QAM level in 0.2-dB steps for the OOB
55–1 FDC.
From cBR 17.6.1w, support for 55d1 Out of Band virtual-om configuration has been increased from 10 to 20. This provides for
increased scalability of the virtual-om.
Feedback