Cisco, and the DOCSIS community in general, have been talking about Remote-PHY for a while now. Finally, we are getting somewhere!
Remote-PHY is very basically just about moving the PHY part of the CMTS to a remote location. To that end, you need a Remote-PHY Device (RPD) and you need to connect it to the CMTS. To do so, an IP network is needed to interconnect the CMTS and the Remote-PHY.
Usually the same fiber cabling used for the current fiber-nodes, can be used to connect the RPD to the CMTS, making the upgrade from traditional DOCSIS to Remote-PHY a rip-and-replace action.
Glenten, a Danish cable operator serving in a major city in Denmark, had looked at multiple ways to improve their infrastructure. The main issues being capacity and carrier-to-noise ratio.
DOCSIS3.1 has great improvements on the capacity part but did not solve the CNR challenge.
Costly upgrade of an old infrastructure!
Upgrading the existing HFC network to fully deliver DOCSIS3.1 would be very costly. All the optical-transmitters only supported 862MHz and would need to be replaced with new optical-transmitters supporting 1218MHz.
All the return-path receivers only supported 65MHz and would need to be replaced with new return-path receivers supporting 204MHz.
In some cases, you might have to split service-groups because of the bandwidth limitation of the fiber-node, which would mean deploying more downstream and upstream channels (added licensing costs).
So, what does R-PHY bring to the table?
For one, the Remote-Phy Device (RPD) is a single piece of hardware to replace both the fiber-node, the optical-transmitter and the return-path receiver. Moreover, it eradicates the loss normally seen between the optical-transmitter/return-path receiver and the fiber-node (in this case it was typically 3dBm, in most cases it will likely be more) by making the signal digital. Going from analogue to digital also greatly increases the distance that the CMTS can cover – ~80km without signal regeneration!
The CNR of both Upstream and Downstream is greatly improved!
The picture below shows the SNR(MER) levels and more of a modem connected to an RPD in the production network showing SNR(MER) of ~46dBm!
Admittedly, the example above is better than most of the modems but the improvement is evident on all modems!
A positive side effect of moving things out into the world and into these compact RPDs is the space it creates at the head-end. This is typically several racks of passive equipment and huge bundles of cables. All the Optical-transmitters, return-path receivers and all of the combining – all of it can go!
The picture below shows two racks of equipment (6 racks in total!) that was simply removed after converting to Remote-PHY.
In the street cabinets the Teleste DAN 300 RPD “just” replaces the fiber-node.
Cisco and Teleste?
Teleste DAN300 is a compact RPD with low heat development which fits the European market deployments. These factors fit well at Glenten and since Cisco had done some interop testing already, it seemed the right way to go.
We contacted Teleste and quickly got a lab installation up and running. At this time the Teleste RPD (DAN300) was still not in production and there were still a few interop issues with the Cisco cBR8, but nothing serious. All issues were mutually fixed within a couple of months.
With similar lab environments at Glenten and at Teleste we simulated customer requirements and shared different finding as soon as any discrepancies were discovered.
What does the RPD require?
For the RPD to work it needs an IP-address (of cause). Both the RPD and cBR8 need precise timing using a PTP Grand Master. The cBR8 is capable of being a PTP Grand Master and as such the RPDs need only be synced with the cBR8. In our case we decided on an external PTP Grand Master because the cBR8 software lacked support for PTP Grand Master at the time.
The RPD also needs Time of Day (ToD) (RFC 868) for timestamping and validation purposes. The ToD server IP is provided to the RPD via DHCP in the time-serves option.
Also, the RPD needs a DHCP option to point it to the CCAP-Core (cBR8) (option 43 sub-option 61 (ccap-cores)).
Finally, the RPD needs to be physically connected to the cBR8 (through a CIN network) so that it can reach the CCAP-Core IP via the D-PIC port on which it is configured.
What about the cBR8 line cards?
The 1st gen line cards can be reused! The RF part, called the RF-PIC card, cannot be reused. In order to connect to the CIN, we replace the RF-PIC with digital PIC (D-PIC), with Ethernet ports instead of RF port.
The line card simply needs to be configured for remote-phy and the newly installed D-PIC will start working.
What is a CIN network?
Converged Interconnect Network (CIN) is what you call the network that connects the RPDs with the CMTS.
There are many ways to go about it, but all you will ever read (except for this article) is how important it is to deploy a Distributed Access Architecture (DAA).
If you want to learn more about DAA, I suggest this light-read from Cisco: https://blogs.cisco.com/sp/remote-phy-why-cin-architectures-matter
We could go on for hours about the importance of doing the right design and what to be aware of, but the truth is that in many cases less is more!
If you are a small ISP, like Glenten, and all the fiber-nodes are connected to dark fibers that are terminated at a head-end where the CMTS is located, then you do not need to think DAA. The CIN could simply be a flat network comprised of layer 3 switches. It is however imperative that the network is able to deliver the high performance needed for both unicast and multicast traffic.
In short, the CIN network needs to connect a number of RPDs to a D-PIC port on the CMTS.
How do we connect the cBR8 D-PIC ports with the CIN network?
Basically, you group the RPDs and point them towards a D-PIC port using DHCP option 43 sub-option 61 (ccap-cores). This tells the RPD which IP-address to use as a CCAP-Core = the IP-address of the D-PIC port.
One way of doing this is to group the RPDs into subnets. Then it will be up to the DHCP server to provide a unique CCAP-Core IP per subnet.
If you use a flat CIN network with a layer 3 switch per 1-2 line card(s), you can even place the CCAP-Core in the same VLAN and subnet.
In larger networks the RPD subnets must be routed to the correct CCAP-Core (D-PIC) port and deploying the proper network architecture is critical.
How about VIDEO overlay?
You can choose to combine the TV channels on the back of the RPD. The Teleste DAN300 RPD actually has a fiber port for it!
However, this approach is costly. You need an analogue fiber for each RPD. You need an analogue network with fiber-transmitters etc. to get the signal to the RPD. You will also lose the benefit of improved CNR, because of the analogue fiber.
In Remote-Phy you can deliver the VIDEO overlay on the same fiber as the data. To do so, you need a VIDEO core which can be the cBR8, another cBR8 or some other solution.
Teleste has a VIDEO core solution that can do the job. At the time of implementation, it was not ready, so we chose to use the cBR8 itself.
The VIDEO content in this case was purely regular HD-TV channels placed in multiple SC-QAMs. There were no Video on-demand services or anything else.
The VIDEO content is received as MPTSs (a multicast containing multiple multicasts (SPTS)). In the cBR8 each MPTS is mapped to a DOCSIS channel and a D-PIC port (VIDEO core).
A downstream controller-profile maps the DOCSIS channels to frequencies and provides a pool of multicast addresses to use for the multicasts. In the cBR8 configuration of the RPD, the D-PIC port is set as an auxiliary core.
The cBR8 now maps the original MPTSs to addresses in the multicast pool provided in the downstream controller-profile, and the information about the new multicast addresses are passed on to the RPD. The RPD does a regular IGMPv2 join and the CIN network must then route the multicast from the cBR8 to the RPD.
Conclusion
Getting the Teleste RPD working with the Cisco cBR8 was easy in my opinion. The interop is great (thanks to CableLabs standards!) and both Teleste and Cisco are eager to help if needed.
Most of the difficulties we had were related to the services needed by the RPD (DHCP options, PTP and ToD), not the interop with the cBR8.
The guys at Teleste deserve a lot of credit for their level of commitment. They clearly want the customer experience to be as good as possible. They are a pleasure to work with.