R-PHY: What You Need to Know - Session 1
Time: 8 am PST / 11 am EST / 4 pm GMT
Everything You Always Wanted to Know About Remote PHY but Were Afraid to Ask
With Remote PHY now all over the news, most cable operators have plans in various stages of work. But, beyond the R-PHY working teams, there is still a lot of confusion and uncertainty about the technology. In this first part of a multi-webinar series, we will explain the business drivers behind R-PHY, how it will impact the access network in the short term, and what the evolving network will look like in the long term. We will introduce a recommended structure for R-PHY testing over the entire lifecycle. In the next two webinars, we will dive deeper into specific areas around headend/hub construction, fiber deployment, R-PHY turn-up & cutover, and ongoing maintenance of Distributed Access Architectures.
View additional sessions in the Remote Phy webinar series:
- Session 2 - DAA – Headend Considerations Before the First Remote Unit is Turned Up
- Session 3 - Crossing the R-PHY Finish Line – RPU Installation, Cutover and Ongoing Maintenance
Check out the full transcript of the R-PHY: What You Need to Know - Session 1 webinar.
| Alan Breznick: | Good day everyone. Welcome to today's latest Light Reading webinar, entitled Everything You Always Wanted to Know about Remote PHY but Were Afraid to Ask. As Kelly mentioned, my name is Alan Breznick, I'm the Cable Video Practice Leader for Light Reading and a Contributing Analyst at Heavy Reading, which is the research arm of Light Reading. I will be your moderator today. |
| Alan Breznick: | Based outside Toronto, I specialize in the cable video and broadband technology markets. I've put together this webinar in tandem with our sponsor, VIAVI Solutions and our service provider Comcast. |
| Alan Breznick: | We have an instructive program for you today, focusing on Remote PHY and distributed access architecture in general. In this first part of a three part webinar series, we will explore the reasons for deploying Remote PHY, the ways it will impact the cable HFC access network, lessons learned from early MSO trials and deployments and the outlook for the evolving HFC network in the long term. |
| Alan Breznick: | We will also examine the challenges posed by Remote PHY and present a recommended structure for Remote PHY testing over the entire lifecycle. Now, Kelly, before we get started, let me run through a few tips. Actually, Kelly already ran through them about how to optimize your experience today. Just as a reminder, we're gonna have two audience questions ... I'm going to have an audience question answer session at the end of the webinar, and you can take part in that at any time by asking questions. Just type your question into the Ask a Question area and click the submit button. |
| Alan Breznick: | During the webinar, we will also conduct two audience polls to learn your views on Remote PHY and DAA in general. And finally, we will address your questions at the end as I just mentioned. So it should be a pretty productive hour. If you run into any technical problems, please visit our webinar help guide by clicking on the help link below the presentation. |
| Alan Breznick: | In addition, you can contact our technical support helpline which is also located in the webinar help guide. Okay, so let's take a quick look at our two main speakers today. First up will be Jorge Salinger. Jorge is Vice President of Access Architecture at Comcast and one of the world's foremost experts on Remote PHY and DAA. He will join us today from Denver. |
| Alan Breznick: | Then right behind Jorge will be Dave Hering. Dave is Senior Product Line Manager at VIAVI Solutions Development and another Remote PHY expert. He will join us today from Indianapolis. Okay, let's quickly look at today's agenda. As usual, it's gonna be a pretty packed hour. |
| Alan Breznick: | First, we're gonna talk about DAA, we're gonna do a quick overview, give you the big picture on the different kinds of technologies involved. Second, we're gonna discuss the business drivers for DAA deployment. Then we're gonna have a couple of forecasts from our friends at SNL Kagan, who have some numbers about what they expected for this year and what they're expecting for next year. Then we'll get into the Comcast presentation, which is the biggest part of the presentation today. Jorge will take over and talk about Comcast experience with Remote PHY, what they've been learning about it and what their strategy is, where they're going with it. |
| Alan Breznick: | Then we'll move on to Dave Hering. Dave will talk about the challenges that are created by distributed access architecture and he'll also talk about the rollout and testing process considerations. Finally, we'll have a short wrap-up of everybody's presentation and then we'll get into your audience questions. So we have a lot to cover. Let me quickly go through what the big picture is. |
| Alan Breznick: | Here, this is a slide actually I borrowed from CableLabs from Jon Schnoor. It talks about what the different kinds of DAA are. I mean, the different kinds of deployment. It says Remote PHY which we'll be spending most of our time on today. There is Remote MACPHY which is another type of architecture and then there is related architectures that cable operates is also working on such as the full-duplex DOCSIS standard, new DOCSIS standard that's coming into play. There's the new coherent, full-duplex coherent Optics standard that's coming into play as you can see here. And also, with DOCSIS 3.1 there's proactive network maintenance. |
| Alan Breznick: | What we'll be focused on most of the time today is the second part here, the DCA distributed CCAP architecture, we're gonna be talking a lot about Remote PHY and a little bit about Remote MACPHY but most, as you can tell from the title of this webinar, the emphasis is on Remote PHY. |
| Alan Breznick: | Now, getting into the forecast. This was slides that Jeff Heynen, an analyst at SNL Kagan shared with us at our conference last March in Denver about what Kagan was expecting to see in terms of deployments this year. As Jeff will tell you himself, the forecasts are always pretty aggressive. In other words, it was seen that 2018 was gonna be a big year for DAA deployments. But in fact, 2018 has proven to be more of a prep year for DAA deployments with a lot of trials going on and some pilots and maybe a few commercial deployments by the end of the year. |
| Alan Breznick: | But going by this survey that was done here, actually 51% of survey respondents planned to begin DAA deployments this year, including 34% in this year. And another 29% planned to begin in 2019 or later. We'll have some numbers later on, I'm sure Kagan will be updating these numbers what 2018 has actually proven to be is more of a year for trials and pilots and tests and 2019 will be the year, first big year of deployments. |
| Alan Breznick: | Here is the slide, talking about what the business drivers are. Our two main speakers will be going into this in more detail but as you can see, it's not surprising what the business drivers are. It's not competition and it's not necessarily lower costs with the biggest drivers for rolling out DAA seem to be the network requirements and the bandwidth demands. As you can see the numbers here. The numbers are the highest for things like meeting facilities challenges, help rolling out fiber deeper and space considerations and customer demand for bandwidth. Our two speakers will go a lot more into that later on. |
| Alan Breznick: | In terms of 2019, we're expecting to see, and Kagan is expecting to see a lot more real deployments in 2019. Our two main speakers will go into that a lot in their presentations. As you can see from these slides, both Remote PHY and Remote MACPHY are both being explored right now. There should be deployments of both but most surveys, and research that we've been doing and talking to cable operators, Remote PHY clearly has the lead right now and the bulk of early deployments of these will be Remote PHY. |
| Alan Breznick: | So, with that general introduction, let's go into our first audience poll question. And here is that question. The question asks, what is your company's greatest driver for deploying DAA? Please take a look at your screens here and click one of these six choices that we're giving you. The six choices are, to increase network capacity, second choice is simplify outside plant maintenance. Third is improve end of line signal quality. Fourth is boost modulation and bit rates. Fifth is lower operational capital expenditures and six, we have a little mistake here. It's reduce head end power, space and cooling. Not coding. Cooling needs. So please click your response. As always, we'll take a few moments for the On 24 system to collect all the results. So remember, if you wanna ask our speakers a question while you're waiting to type your query, please use the Ask a Question function and click on the button there. |
| Alan Breznick: | In the meantime, let's bring in Jorge Salinger a little early before his presentation to talk about the poll question. Hi Jorge. |
| Jorge Salinger: | Good morning, Alan. |
| Alan Breznick: | Good morning. Thanks for joining us early from Denver today. |
| Jorge Salinger: | My pleasure. |
| Alan Breznick: | So while we're waiting ... great. So while we're waiting for the results, what's your prediction as to what will be the lead choice here? |
| Jorge Salinger: | I don't know what will be the lead choice. But I can tell you what our main driver has been. We have been working on Remote PHY, well, we've been working on distributor architecture but our focus has been on Remote PHY but we've been working on distributor architectures and all of their components that surround it for almost 10 years. Actually, I looked back at my notes and almost 10 years and that seems incredible it's been that long. |
| Alan Breznick: | Wow. |
| Jorge Salinger: | And there have been many reasons why distributor architectures is beneficial. You know, you have them all here, right? Outside plant maintenance. You know, the interface between the headend and the node becomes and even interface just a lot easier to maintain and operate. You are able to get, by moving the modulation and demodulation with either one of these through the node we get better MER performance at the end of the line and therefore we would be able to boost modulation profile and bit rates. |
| Jorge Salinger: | We expect that for definitely lower operational costs. I'm not sure yet about the capital cost. And increase network capacity with everyday we go into deeper and deeper into the network with nodes and therefore as a consequence of doing this we would get network capacity. But in the end the thing that move the needle the most, the thing that made us go pedal to the metal was the last one, reduced headend space, power and cooling, which is what that word is supposed to mean. |
| Alan Breznick: | Right. |
| Jorge Salinger: | That was the driver in the end that made us go as fast as possible, as deep into the development as we could. It was the last one, reduce headend space, power and cooling in that order. |
| Alan Breznick: | Interesting. |
| Jorge Salinger: | The other ones are benefits, it's just that was the driver. |
| Alan Breznick: | Interesting and that's what I thought that I poll would show be in the lead. Maybe 'cause I screwed up cooling and turned into coding and confused people. But turns out the lead choice by far here among our audience is increase network capacity, 49% picked that. So that's the first choice. And I think reduce headend power, space and cooling came in second at about 18%. |
| Alan Breznick: | So, thank you for taking part in the pool. Appreciate that and now I am going to turn things over to Jorge after introducing him earlier. So once again Jorge Salinger from Comcast, perhaps the world's foremost expert on distributed access architecture. |
| Alan Breznick: | Take it away Jorge. |
| Jorge Salinger: | I don't think so, I think there's people who have been working on this for a long time. I have been working on it for a long time. |
| Jorge Salinger: | Good morning everybody. I'm going to touch upon a couple of things first. Somebody is coughing not on mute. |
| Jorge Salinger: | I'm going to touch upon a couple of things real quick. Our focus from a capacity tools and components on the access architecture is based on five areas. We have been deploying DOCSIS 3.1 for quite some time. We're now at 100% penetration of DOCSIS 3.1 in cable service. We started deploying. We actually started deploying two years ago. Last year we deployed in a very massive way and we completed the deployment this year. |
| Jorge Salinger: | So, it's a hugely important part of our access network strategy. We have a new gateway picture shown there, that allows us to deploy gigabit per second service. So we have many, many, many customers now, I don't keep track any more of how many customers that we have. |
| Jorge Salinger: | Spectrum expansion has always been for 20 years, has been a driver for us. Over the years we progressed through different techniques for doing that. Always including service group splits, meaning that we've been making service groups smaller and smaller. Back many years ago service groups were in the thousands. More recently, five to ten years ago, all service groups were below a thousand. Now service groups are well below 500 and new strategy for deploying a fiber deeper into the network which we call XNET, we're going into a node plus zero architecture. It's a very special way of moving or migrating from current architecture node plus zero, that's why we call it XNET. It's different and just a strike node plus zero deployment. |
| Jorge Salinger: | With that the service groups are much smaller, about a tenth of what they used to be which is going to drive us to, I'm going to come back to this, it's going to drive us to distributor architectures. We have been deploying fiber to the premise for many years now. Many more than five years, ten years even. We started deploying fiber to the premise for commercial services but we have been deploying fiber to the premise for residential services as well. We're offering gigabit, multi gigabit services over both for residential and commercial applications over fiber. I'm going to come back to distributed architecture, it's a hugely important part of our strategy and it's the purpose of this discussion. |
| Jorge Salinger: | Let me just say that as a consequence of deploying fiber deep or XNET or n plus zero with a distributor architecture because of that it is that we consider full duplex DOCSIS as the fundamental component of our strategy, exit network strategy. It will allow us to complement the gigabit service downstream that we are able to get with DOCSIS 3.1 now with an equivalent gigabit per second upstream service here. So, not only will we be able to offer cable service downstream because of full duplex, we'll be able to offer gigabit per second and multi gigabit per second upstream as well. So we think it's a fundamental component of our architecture. |
| Jorge Salinger: | So the main purpose of this discussion is to talk about distributor architecture. Before that just a couple more words about XNET. It is now our primary HFC evolution tool. We have been deploying for a couple of years and we plan to deploy broadly. It will be a whole lot of years to drive fiber closer to the home and in some ways it's proactive service groups split strategy. In other words, instead of just being reactive and changing or splitting service groups as the meter rises, the idea is to be proactive about it, go to the areas where we do the most service group splits and proactively split the network into the ultimate smallest service groups that we probably would have, which depending on density could be between a few tens of homes to under a hundred home path area. So it's a fiber deeper or n plus zero architecture. The plan is definitely passive after the node, which allows us to have much more capacity on a per subscriber basis. Not only because service groups is smaller but because it's a consequence of the upgrade, we're expanding the downstream capacity up to 1.2 gigahertz and the upstream capacity to 85 megahertz. |
| Jorge Salinger: | This architecture enables us to deploy full duplex which is why we are not deploying a higher split, higher FDD split, instead we're going to deploy full duplex DOCSIS which will allow us to use a downstream spectrum for upstream transformations enabling us to do gigabit per second upstream. |
| Jorge Salinger: | So XNET is great but it has a problem and that's what the answer that I gave to Alan's question originally. The biggest problem that XNET presents us is space and power and cooling in the headend. Because we're splitting the service groups so much because we're ending up with 10 times as many service groups as we had. Even though the density of the equipment is becoming higher, we're at a density of equipment today is significantly higher than it was just a couple of years ago and certainly much higher than it was five and ten years ago. Even though the density of the equipment is increasing, it is not increasing fast enough for us to accommodate all of the equipment that we will need at the headend and therefore the migration to a distributed architecture. |
| Jorge Salinger: | So the driver again for us to deploy distributed access, even though there is a whole lot of other benefits became the space and power in the headend. |
| Jorge Salinger: | So, sorry I'm repeat this slide. I skip this slide. |
| Jorge Salinger: | So we decided to strategically pivot to distributed access architecture. Fundamentally, distributed access architecture takes components that you would have in an integrated CMTS on the headend and move them to the node. You can do this is different ways, therefore the difference in the distributed access technologies; Remote PHY is the one that moves the least amount of components from the head end to the node. Just moving the modulation and demodulation to the node. In the remote MACPHY, you're also moving the MAC to the node and there're other options that over the years that have decreased in interest. But over the years there have been others that have been investigated. |
| Jorge Salinger: | The two that stand out today are Remote PHY and Remote MACPHY. Of which the one that we are concentrating on is Remote PHY. And so the bottomline is you change the transport from the headend to the node to an ethernet interface, fiber reach becomes less of an issue. What I mean by that is, if you have 60, 80 or 100 kilometer analog modulated link there is limitations on the amount of capacity that you can support in that kind of distance and if you increase the distance considerably then you have even more of an issue. With ethernet you don't have this issue, increase reach. You actually increase the fiber efficiency as well because using DWDM you can get many more RDPs if you will, many more remote PHY devices in the same fiber using DWDM than you can with an analog modulated link. |
| Jorge Salinger: | We align our development of or deployment of Remote PHY with a migration to virtualization. So in SDN and therefore you'll see a couple of slides that I'll outline our complete redesign of our architecture of our access network. We think this gives us much better scalability of facilities. We can house a lot more service groups on the same headends that we have right now. Not only that, we can actually reduce a number of facilities that we have because we don't necessarily need as many hubs or we can go buy hubs with an optical link instead of having to have equipment in them. |
| Jorge Salinger: | In additional to that, the last mile becomes a bit of an access agnostic architecture. We could because link to the node is an unique interface we can have multiple types of access networks spinning off from that access network. |
| Jorge Salinger: | In a traditional Remote PHY architecture, the idea is to take the PHY the modulation and the demodulation from the CMTS core and moving it to the node. Our architecture is more radical than that as I mentioned before. I'll come back to that but let me point out a couple of things. |
| Jorge Salinger: | There are several aspects to the Remote PHY development. Of course there is the base implementation which includes the implementation of interfaces between the core which less than the headend is called the core and the remote PHY device. This applies by the way to Remote PHY and Remote MACPHY as well. So there's the base implementation of the architecture. |
| Jorge Salinger: | But then there are other aspects to this. Not in any particular order but a second one is the interoperability aspect, to be able to have remote devices from different vendors operate with cores from different vendors. So you can have vendor green to call it something, that produces a core and a RDP that interoperates with vendor red or vendor orange. In order to do that, you have to implement an additional features and functionality that allow you to do that. |
| Jorge Salinger: | A third aspect to this is that there are different use cases. New plant is different than a regular plant, especially in our case as we are going to a fiber deep deployment in which the Remote PHY device operates with much higher levels at 1.2 gigahertz the output power level is significantly higher than it would need to be at one gigahertz or at 750 or 860 which would be part of a node. So you have different applications, different use cases of the Remote PHY device. |
| Jorge Salinger: | In addition to that there is an implication of generations. We are in the process of deploying Gen 1 architecture right now. Gen 1 components right now but already Gen 2 devices are being developed especially to support FDX and Gen 3 devices are going to eventually be developed that will be optimized for space and power to allow more density in the nodes, etc. |
| Jorge Salinger: | So, our architecture is one that essentially changes everything. We are moving to an architecture in which the CMTS is virtualized. In which we move away from the traditional use of tools like SNP and TFDP and use instead of ... |
| Jorge Salinger: | Somebody is coughing. Somebody is not on mute. We hear the coughing. |
| Jorge Salinger: | So we are moving towards a telemetry approach instead of using SNP and PFTP for example. We are implementing a separate GCP principle which we call GCPP. So separating the GCP function from the CMTS itself. We have a separate video engine and OOB engine, and I'll go into more detail on that. And we've moved to an open architecture for our switching and our routing infrastructure. |
| Jorge Salinger: | So I'll go into a bit more detail. There's a lot of words on the slides, I think you will get the slides that explain what I just went over. |
| Jorge Salinger: | From a functional perspective those are the boxes that we use. We have a principle core this is software that talks to the RDP to configure it. We have a DOCSIS box, a device that provides all the DOCSIS functionality that's typically included in CMTS. We have a separate function of narrowcast video and broadcast video. Both of which are software. I'll talk about them in more detail in a minute. We have a separate implementation for out of band in the U.S. I know that there's several folks from Europe. This is for communication to our setup boxes which we use in North America using a legacy out-of-band implementation, either 55-1 which was originally implemented by Motorola and 55-2 originally implemented by Scientific-Atlanta later became Cisco. So those are the functional blocks. |
| Jorge Salinger: | From a GCP perspective there's only two devices that support GCP today. The principle core communicates to the RDP using GCP. This is general communications protocol that is part of the specifications that provides a configuration interface between the RDP, the remote PHY device and the principle core. So when the RDP first comes up, it gets an IP address like any other network device would do. Following that it gets time of day information from a time of day server and then as part of the information it gets from the ACP server, it gets told which one is a principle core. So it contacts the principle core and it gets all of it's configuration. |
| Jorge Salinger: | From the principle core, except in our implementation, except from DOCSIS. The principle core will then once all the videos configured, will tell the RDP to contact an auxiliary core, this is all part of the finishes of the cable specifications that the describe the Remote PHY protocols. So the principle core will tell the RDP to contact the first auxiliary core which is the DOCSIS core. The DOCSIS sore will communicate to the RDP all of the configuration information that corresponds to that RDP and if there are no other auxiliary cores, the RDP will get no further configuration then the RDP will synchronize timing with the timing server. Timing is a very important thing. I didn't go into it specifically but there is a timing server that the RDP will contact to get timing information and once all of the devices are synchronized to timing source then communications will start. |
| Jorge Salinger: | The CMPTS, the DOCSIS/HSD core will start sending maps to the RDPs so that cable modems can register the narrowcast video and the broadcast video engines. They're called engines because they do not have GCP, so they are not cores they're engines. The broadcast video engine and the narrowcast engine will start sending video to the RDP. The RDP does not know about the narrowcast engine or the broadcast video engine it just received data and will start receiving information from the outer band engines as well. |
| Jorge Salinger: | In our case, in our implementation we focus on 55-1 first because our penetration of 55-1 is much greater but we're now starting to focus on 55-2 as well. |
| Jorge Salinger: | Testing has become a very complex and interrelated thing. I don't mean to go over everything here but there are a bunch of components in our case we've essentially changed everything. We're developing internally all of the switching infrastructure, all the platform that support the CMTS, all the telemetry information, the back office in addition to the video core. All of that is internal development so all of those come from us but we get ... and also GCP is internal development as well. But the RDPs are not and so we have to test RDPs against all these components. We test different features and different labs. The Downington lab, it's a location where we test video. We test voice in the Moorestown labs another location. In Bishop's Gate we test CMTS functionality. |
| Jorge Salinger: | We have testing in different labs and all that needs to be integrated. Also issues are found in each one of these labs need to be propagated to the vendors from whom we get the different components. Many of which we produce and then the cycle starts again. So we're constantly on a constant integration, constant development. |
| Jorge Salinger: | So where are we at? In a nutshell, from an equipment perspective we have the DOCSIS core, the GCPP core the video engine both broadcast and narrowcast. They're all operational. We have interoperability of RDPs with the cores that we have. We have three different vendors. RDPs all of which interoperate without any major issues. We do come across issues every now and then but they're relatively minor in terms of implementation. So we have been working testing for quite some time and we are now in the implementation phase. |
| Jorge Salinger: | Just to go over a couple of details, we have implemented leakage detection, so we have leakage detection equipment from different companies and we have implemented that in the Remote PHY devices, so the leakage detection tones come out of the Remote PHY devices and support all the tools, we have tools from three different vendors, all of them are supported. And we are implementing a new way of upstreaming Spectrum Surveillance, that is not fully deployed, it is under development, but we are planning on doing that so we don't have to have upstreamed Spectrum Surveillance, we can't and we have to move Spectrum Surveillance so that we can do it from the node. |
| Jorge Salinger: | We have been testing in all labs, including physical and environmental testing and that is all done and we're working on new versions all the time. So, the equipment is in the initial trial locations. We have customers on them. We don't disclose how, the magnitude of this, but let me just say it's quite big of a deployment. It's far from our entire footprint but it's quite big of a deployment. We are planning like Alan was saying at the beginning to start scale deployments by the end of this year. In all our deployments of XNet starting next year, all of them will be with Remote PHY. |
| Jorge Salinger: | So that's the status of our plan and technologies, one quick reminder: all of this is a platform to deploy Full Duplex, we do plan on deploying Full Duplex extensively wherever we deploy Remote PHY and Fiber Deep or XNet, we are planning on deploying Full Duplex which is going to give us the ability to have symmetrical gigabit and multi-gigabit service. The pace of technology, I wanted to make this point, the pace of technology evolution is so fast these years. I don't know about you guys, but I am amazed at the amount of change that we experience on the network these days. We, just a few years ago, to not go back too much in time, just a few years ago, we were worried about one or two things at any one time. |
| Jorge Salinger: | Now, we're doing so many things at the same time and while we're doing, while we're getting deployments of Remote PHY underway, we're worrying about Full Duplex and starting to work on the development of RDP so that'll support Full Duplex and wireless and IoT, all of that is going affect the pace of innovation in the access network has never been as frantic as it is right now. I suppose you all see that, so I just wanted to make that point. |
| Jorge Salinger: | With that, Alan, I'll turn it over to you. |
| Alan Breznick: | Okay, excellent Jorge, thanks for very much for that rundown. I appreciate it. Can everybody hear me okay? Okay, good. So, after that we're going to move into our second audience poll question before we move on to Dave Hering from VIAVI and that second question should be on your screens now. The question is what concerns you most about future DAA plant maintenance? We've given you five choices I think this time, and hopefully there are no typos like there were the last time. |
| Alan Breznick: | First choice is potential disruption to existing tools and processes, second is blurring of responsibilities between field and head-end teams, third is increase complexity many architectural/vendor combinations, fourth more technicians performing fiber and Ethernet tests, and fifth, finally, PTP timing concerns as Remote PHY splits the MAC and PHY layers. |
| Alan Breznick: | Okay, while you're going through those results and letting us, going through the choices and letting us know what you think, I'm going to bring Dave Hering in here from VIAVI. Hi Dave. |
| Dave Hering: | Hi Alan. |
| Alan Breznick: | Good to have you here. |
| Dave Hering: | Thank you. |
| Alan Breznick: | So Dave, I want you to get ... you're welcome. I want to get your perspective on the first question that we asked about the different drivers for Remote PHY deployment. What was your thinking about the responses we saw? |
| Dave Hering: | Yeah, I thought it was very interesting that, you know, half the people said it was to increase the network capacity. And I think that might be a reflection of a lot of operators are looking at extending the upstream frequency ranges, essentially extending the downstream frequency ranges with the DOCSIS 3.1 and Remote PHY is kind of their trigger to do it because you have to go through and swap out equipment and plants or generally doing it in conjunction with a node split that would be going on anyway. So I think it might have been a trick question, a lot of people do a combo DOCSIS 3.1 and Remote PHY to go through and increase their capacity on both the upstream and the downstream. So, just a different perspective on that might explain that result. |
| Alan Breznick: | Okay, I appreciate that. Thanks for giving us that perspective. Let's take a look at the results now, I just put them up on the screen. It looks like the leading choice here was increased complexity, 47% of you said that increased complexity, many architectural and vendor combinations. The second biggest choice seems to be potential disruption to existing tools and processes, about 23%, a little less than a quarter of people out there said that. |
| Alan Breznick: | Dave, is this what you would have expected? Is this what you're hearing from your customers? |
| Dave Hering: | Yes, actually it is, and I think it's reflective of the turnout that we have for the seminar today. You know, when you need to go to expo and you look at the amount of people that attend the Remote PHY sessions and they are, everyone's trying to figure it out. And it is complex, and there's lots of options and changes, processes, so these results actually are pretty consistent with what we would have expected. |
| Alan Breznick: | Yeah, I'm not surprised by it either, the fact that you, I'm glad you mentioned the FCT pre-show thing that they're doing on DAA and, the last we've heard, over 600 people have already registered for that, coming early on Monday just for that and sure, I wouldn't be surprised if they hit 1,000, they're going to have use a big hall for that, so, thanks for that and thanks everybody for taking part in our two polls and now I'm going to turn things over to Dave Hering to take over and talk about testing considerations, so Dave, it's all yours. |
| Dave Hering: | Okay, thank you. So, yeah, so we want to ... as people are moving from the lab to the field, you know everybody's asking the questions, how do we go through and operationalize it? What does it mean to go through and put this into production so that I know the service is going to work reliably and keep working? So, we've been looking at this problem for a long time now, I mean this has been a while unfolding and the challenges that are created by the distributed access architecture are numerous. |
| Dave Hering: | The first thing that was pretty obvious to people was there's no RF in the hub. So how do I do things like upstream Spectrum Monitoring or Sweep or Leakage, and as Jorge mentioned the Remote PHY devices can go through and help with that, and they can embed some of the leakage technologies, but it doesn't provide answers for all of the test needs. |
| Dave Hering: | Another big issue is the demark disruption. So the hub and the headend have been the mainstay of cable, I mean that's where I'm gonna go through, I'm going to have, I'm going to put all my QAMs together, modulate them and I can check everything right there in the headend, it's kind of a self-contained environment. But now, we see all that processing being pushed further and further back into the plant, so operators want to go from having all the video processing for example in that hub, to the primary headends or maybe to data centers further back in the network where they can go through and operate on volumes of scale and really try to turn all this into a virtualized offering running on standard hardware. |
| Dave Hering: | So that creates a big change now, so if I have an issue with the service, is it because combining logically incorrectly back where I'm doing my video processing? Is it transport problems on the Metro network as I'm trying to get from where my CCAP is out to that Remote PHY device? Is it really a RF issue that I'm seeing in the HFC? So it starts to become a little bit trickier and it certainly creates the potential for a lot of finger-pointing where maybe you're chasing a problem thinking it's an HFC issue when it reality, it's a Metro transport problem, which kind of leads us into the next thing, fiber and Ethernet everywhere. |
| Dave Hering: | So, it's very analogous actually to business services, so as a lot of the operators and deployed business services over the years, they want to go through and push fiber straight out there and run Ethernet. Well now, all of the nodes are basically going to like look what was a business service installation before. So, it becomes the primary method for building the plant, so it's not just for specialists, because typically people would have had specialists for business services who would be responsible for going through and turning them up and maintaining and servicing them. |
| Dave Hering: | How do you get the tools and training for the masses of the workforce that are now needed to go through and deal with fiber and Ethernet everywhere and simplify it so the technicians can understand it? And then the last point was reflective once again of the poll question, it's complex and there can be lots of variations, so you know this seminar series is focused on Remote PHY, Remote MAC PHY is another technology people want to be able to go through and intermix the CCAP vendors and the Remote PHY to vendors, so it just creates a lot of complexities and proliferation of what the thing looks like and how do you deal with that in a standard manner so you're not dealing with this section of the plant differently than another section of the plant. |
| Dave Hering: | So, at a high level, those are some of the challenges that we see created in the DAA environment. Now as we've talked to operators globally, we're really trying to go through and help provide some clarity on what the real process is for ... excuse me, for rolling out and maintaining DAA and we could break it up into four logical groups, basically. |
| Dave Hering: | The first is the headend and the hub construction. So I want to go through and do the installation and commissioning of the network equipment. In the hub, the hub in many cases will just look like an optical switching center, so that means testing the Ethernet services to the hub, checking to make sure the fiber connectivity is correct. Much different tests than I would have done previously. The next step in the headend hub construction is very often to install a shelf RDP, so all this is is a rack-mounted Remote PHY device that looks like exactly what I'm going to deploy in the field. I can go through and set that up, you know, plug it in, look at the video on, using the set-top box and stuff, order the video on demand, do the sort of manual testing that I have done in the past, just to verify that my services are indeed working properly. |
| Dave Hering: | Next is to go through and do the fiber construction. So you're going to very oft ... you're going to re-use fiber, but this is often done in conjunction with node splits so you're pulling new fiber, but you need to go through and make sure that the physical connectivity of the fiber is correct, that it's hooked up between the endpoints where you think it is and that it's clean, that you don't have any issues that are going to affect the integrity of the fiber from an out-and-out fault that you'd see with a fiber break to degradation you'd see because you had a dirty surface when you went through and did the fiber connection. |
| Dave Hering: | Then you look at the installation cutover process, so I have everything laid out. I have my fiber in place, I want to go through and actually get that RDP turned on, installed and configured, so this is where I want to go through and cut my customers over to the live services, so very often this is done in these three steps exactly as we're doing it here, and sometimes it's done with different work groups as well, so you know in this part of it, you know, final verification that my fiber's good, I need to do the Ethernet testing. I need to do my timing test, we've talked about timing as I separate the MAC-level processing from the PHY layer, I need to make sure that the timing is respected, otherwise I'm going to have all sorts of problems that are going to look like HFC issues if I'm not aware of them. |
| Dave Hering: | And then it's running the standard tests that you would expect. Okay, I've turned it on, I now am pumping RF out of this Remote PHY device, I need to make sure that the RF is good, my DOCSIS is working properly, probably want to go through and do a check on Sweep and ingress suppression. And then the last piece is the maintenance of it, so that's the ongoing leakage, ingress suppression service assurance tests in general. So this is going to involve essentially everything that we've talked about up to this point are things that you would need to do to as elemental plant maintenance, depending on where faults are considered. |
| Dave Hering: | So it's a very complex topic, and it's not the intent on this call to go through and really go over this in detail. We will host a couple more sessions for DAA, so on November 27th, we'll cover the first two topics, so the considerations before the Remote PHY unit is turned up into production, so that it's customer-facing, and Arris and Nokia will be joining us on those calls. And then we'll have the third series will be on January 23rd, and that will talk about the actual cutover process and how the plant is maintained and ... excuse me, Cisco and Harmonic will be our partners for that webinar. So I appreciate your time this morning, and we'd like to entertain some questions, I think is the next step. |
| Alan Breznick: | Right. Okay, thank you very much Dave. Thanks for running through that, and yes and it's a good reminder that we are ... this is the first part of the three-part series and we'll be having two more webinars with VIAVI and its partners on Remote PHY testing considerations and deployment considerations and what the long-term future is for this technology in late November and in January. |
| Alan Breznick: | Okay, so with that, let's look at what our, some of our questions are, as we go into the Q&A session. So let me see what we have lined up here. I know a bunch of questions have come in, so let's get started on that. |
| Alan Breznick: | First question I think is for you, Jorge. It's about XNet, let me get it teed up here. Since XNet deployment is well ahead of DAA, Comcast has just deployed new fiber nodes over most of its footprint. How does the upgrade from a fiber node to an RFD work? Is it a plug-in replacement? Will the new nodes be fully depreciated before the upgrade? Multiple choices, there. Multiple questions there, Jorge. |
| Jorge Salinger: | Yeah, so leaving aside the depreciation aspect of this, yeah, that's true. So we are deploying XNet, analog XNet, let's call it that way, meaning that the link, at least the forward link is an analog-modulated link, and therefore we have an analog-fiber receiver, and in our case a digital return transmitter and we're changing that for a Remote PHY implementation, and yes the chassis, the node chassis is the same. |
| Jorge Salinger: | The nodes that we're deploying, the node chassis is the same, and so the migration from an analog XNet to a digital XNet is a modular replacement. We've already done those, we've already done a few of those, and that's how we're initially deploying the Remote PHY and moving forward, the deployments of Remote PHY will be on new nodes, so as we deploy more nodes for XNet, they'll be digital and at some point we'll go back to the current nodes that are analog and convert them to digital, but we don't have a plan to do that at this point. |
| Jorge Salinger: | The deployment that we've done for analog XNet is going to stay the way it is, but we could replace the modules for digital modules and upgrade the node if you will to a Remote PHY node, which we'll probably do in order to deploy . |
| Alan Breznick: | Okay, fair enough. Sort of a follow-up question for you Jorge, what's the biggest lesson that you've learned from the initial Remote PHY field work ahead of scaling your deployment? |
| Jorge Salinger: | There's so many lessons that we learned, you know, and it's hard to say which one ... but let me tell you a couple that really caught our eye. |
| Alan Breznick: | Sure. |
| Jorge Salinger: | One of them, huge lesson for me, for a whole bunch of people that I know is that a short power outage in the node is a long power outage for customers. In the past, in the past we have been removing power from the node for a second or for two seconds or 30 seconds to do something, many different reasons. Well now, if we remove power for one second, it's a five minute interruption of service because the RDP has to come up, has to get configured, it has to sync with the PTP server, and that causes a rather long outage. So that has been a huge lesson, we can't do that any more and it's a very big training process. |
| Jorge Salinger: | Another one is the whole turn-up process, right? Whenever we turned up a new line card or new CMTS or a new CCAP device and then we had equipment to test it and we were able to readily test the new equipment before we connected customers. That process becomes more complex now that we have the PHY in the field and we do have in trucks and we actually test the set-top box, cable modem, et cetera in the truck and we have a generator, but that process has to get optimized for Remote PHY deployment. Sorry, I'm moving my ... So, many lessons but those are two examples of things that we learned. |
| Jorge Salinger: | Training. Training is another one. Training is always a big thing, it is a big thing here too, how do to deal with the lights, the LEDs on the remote, just as we were having this call, as Dave was speaking, I was answering a question from a technician in the field, so training is a big thing. |
| Alan Breznick: | Okay, thanks for that answer, Dave I'll give you a shot at it too, what are you seeing as the biggest lessons learned from the work you've done so far with your customers? |
| Dave Hering: | The biggest thing that we've actually seen, beyond the obviously as a test equipment vendor is the testing and maintenance needs were not one of the upfront concerns. Everybody was much more concerned with passing packets, getting the video to work, getting the out-of-band carriers and stuff to work, and so we've been working on this stuff for multiple years, but customers didn't really start coming out until about a year ago and saying, “Well now, hold on. Now we're looking at getting this thing operationalized and we need to go through and figure out how to test it and how to maintain it.” |
| Dave Hering: | So really that was the biggest lesson learned is that that tended to be the lagging requirement from customers, and I think it actually created a little bit of a hiccup for the network equipment vendors because they kind of came to us and said, “Please tell me you've been working on stuff like Sweep and ingress suppression and that you have a solution for that because the customers are saying that we can't deploy without it.” So, fortunately it worked out well for everyone and, but that's definitely the observation. |
| Alan Breznick: | Okay, thanks to you both. Okay, we have time for a couple more questions before the end of the webinar, but before I ask anything else, I just pushed an evaluation form on your screens. Please complete this form so that we can get some feedback about what you liked and what you didn't like about this webinar, and please also tell us what you'd like us to cover in the future. To complete the form, just press the Submit Answer button at the bottom of the page. Thanks. |
| Alan Breznick: | Okay, so while you're doing that, so let's move on to another question. Not surprisingly, we have a lot of questions for Jorge. Jorge ... Harmonic is one of your suppliers around DAA. Can you comment on how Comcast sees vCCAP playing a role and is Harmonic a strategic supplier there to Comcast? |
| Jorge Salinger: | So, I won't comment about vendors, we don't do that, so hopefully you forgive me for not doing that. We are migrating to a virtual implementation of the CMTS, a virtual implementation of the video engine, a virtual implementation of out-of-band, so our migration to virtualization, it goes deep in our plans. We are working with a number of vendors on different parts, but I'll leave that to ... you know, it's a confidential discussion, so I can't comment on that. |
| Alan Breznick: | Sure, alright, we understand that. Next question is how about Sweep? What role does Sweep play in all of this? |
| Jorge Salinger: | So our implementation of fiber, using Remote PHY is in conjunction with the architecture, for which we have a passive network for which Sweep becomes much less of a need. As we move using Remote PHY for BAU, business as usual node splits, then we will need an implementation of Sweep, and like David said, we're working with vendors of tools, including VIAVI on the use of these tools. |
| Alan Breznick: | Okay, and speaking of VIAVI- |
| Dave Hering: | Yeah, I'll just put a little more color on that, I mean, definitely we see Sweep, we see business as usual node splits much more typical in Europe for example. They're not going after fiber deep and node plus-zero architecture, initially so all of the requirements for testing are still there and as we'll discuss in some of the other webinar series, we have tools to enable Sweep using the same instruments that we have in the field today. |
| Alan Breznick: | Okay, well that leads right into the next question for you, Dave. Will today's testing equipment be used in the new testing or will operators need to replace their existing PathTrak's equipment? |
| Dave Hering: | The answer is both actually, so the actual hardware that it has an RF receiver on it, it's going through and measuring return spectrum for example, I mean that information now comes from the Remote PHY that lies, so it's done with the software instead of a piece of iron, instead of a dedicated probe. But the software which provides that information to the technician is the same, and that's actually a very important point because training is very complicated and if it has to be different for this part of my plant versus that part of the plant, it just greatly increases the complexity for the operators. |
| Dave Hering: | So that's the philosophy we've taken is we've migrated tools to support Remote PHY. We've done it in such a way as to maintain the same workflow and the same tool or screen in front of that technician, so that it looks seamless to him, as they translate from centralized access to Remote PHY. |
| Alan Breznick: | Okay, thanks. Next question, is there any hope simply using IP encapsulation of the QAMs for leakage and Sweep between the headend and RDP? Or are you completely re-designing these functions? |
| Dave Hering: | So, let me answer that. So that would be one way to do it, it would be probably extremely inefficient to go through and transport that kind of data, so as we go through and develop test tools for this, we use standards like the narrow-band digital forward and return for communication with our instruments in the field for example, and pull information like spectrum from the Remote PHY device, so we can actually use the existing standards that are available today to support the kind of functions that everybody needs to build out and maintain these Remote PHY deployments. |
| Alan Breznick: | Okay, fair enough. Question's probably for Jorge. What is the typical number of actives after RDP that you'll deploy? |
| Jorge Salinger: | So, in our current implementation of Remote PHY we're focusing on the XNet nodes, and therefore there are no actives after the Remote PHY device, but when we move to BAU, business as usual node splits, then we will have actives, and the number will vary depending on the implementation, the HFC implementation. |
| Alan Breznick: | Okay. Alright, let's see what else we have here. We have time for one or two more. |
| Alan Breznick: | Is there a delay specification that limits the distance that Remote PHY nodes can be located away from the core? |
| Jorge Salinger: | So, the answer is really, no. This question comes up a lot. No. We have tested in a lab implementation, we have tested the separation between the Remote PHY device and the CMTS of 2,000 kilometers without having to change anything. You can separate them even more, in which case you would, for example manipulate the map advanced interval, there are tools in the MAC that will allow you to have enormous distances between the Remote PHY device and CMTS. We don't have anything, any distance like that, so we don't have to do anything with the MAC in order to facilitate a longer distance. Our distances are ... yeah, the longest we've done is under 100 kilometers, we plan to do over 100 kilometers. We could be doing 200 kilometers, 300 kilometers, but ... and we would not need to do any adjustments, so no, there aren't any specific limitations. Not any more than DOSCIS supports and because, in the end the separation between the CMTS and the modem is what becomes more critical. |
| Alan Breznick: | Okay, one last question, probably for Jorge but I'll let both of you have a shot at it. Where are we in terms of interoperability between different vendors when it comes to Remote PHY? |
| Jorge Salinger: | We have in our network today, CMTS and cable modems from different vendors, we work with three Remote PHY device vendors and all three of them work with our CMTS. |
Considering Remote Phy? Check out our Remote Phy resource page for more details.
Speakers
- Alan Breznick, Light Reading, Moderator
- Jorge Salinger, VP of Access Architecture, Comcast
- Dave Hering, Senior Product Line Manager, VIAVI