CONFIGURATIONRECOMMENDATIONSFORDOCSISTRANSPORTOFMANAGEDIPVIDEOSERVICE
WILLIAMT.HANKSWith special thanks to the following contributors:
Jim Allen, Tom Cloonan, Michael Dehm, Amit Eshet, J.R. Flesch, Dwain Frieh, Will Jennings, Tal Laufer, Tushar Mathur, Dan Torbet, John Ulm, Bill Ward, and Ian Wheelock
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 2
TABLEOFCONTENTSINTRODUCTION.............................................................................................4TARGETAUDIENCE.........................................................................................4VENDORANDPRODUCTAGNOSTICISM........................................................4TECHNOLOGYBACKGROUND........................................................................5VideoServices.................................................................................................................5
LinearBroadcastTVvs.On-demandContent.............................................................5
TelevisionChannelViewership...................................................................................5
TVChannelChangeExpectations...............................................................................8
InternetProtocol(IP)......................................................................................................8
Connection-Orientedvs.Connectionless...................................................................8
IPMulticast–OneStream,MultipleDestinations.....................................................9
IPUnicast–OneStream,SingleDestination..............................................................9
AdaptiveBitrateVideo....................................................................................................9
IPUnicastABRVideo..................................................................................................9
Multicast-assistedABRVideo...................................................................................10
HomeEquipmentClarification......................................................................................11
CableModem...........................................................................................................12
HomeGateway.........................................................................................................12
IPVideoPlayer..........................................................................................................12
SmartTV...................................................................................................................13
Console.....................................................................................................................13
Tablet&PCs..............................................................................................................13
IPVideoClientw/multicast......................................................................................13
DataoverCableSystemInterfaceSpecification...........................................................14
CableModemCapabilities........................................................................................14
ChannelandFlowAssignment..................................................................................15
ServiceFlowTypes....................................................................................................17
MACManagementDynamicServicesTransactions.................................................18
QualityofService......................................................................................................19
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 3
Primary-CapableDownstreamChannels..................................................................21
UpstreamSupervision..............................................................................................22
EnergyManagement................................................................................................22
IPMulticast...............................................................................................................23
QoSControlPlaneSignaling.....................................................................................23
NACK-OrientedReliableMulticast(NORM)..................................................................26
RECOMMENDATIONS-TYINGITALLTOGETHER.........................................26CMCapabilities.............................................................................................................27
ChannelAssignmenttoCMs.........................................................................................27
ConsolidateMulticastProgramStreams..................................................................27
Load-BalanceRemainderofChannels......................................................................30
CMUnicastIPVideoServiceFlowQoSParameters......................................................30
Downstream.............................................................................................................31
Upstream..................................................................................................................32
QoSSettingsacrossDifferentServices.....................................................................32
CONCLUSION...............................................................................................34ABBREVIATIONS&DEFINITIONS..................................................................35RELATEDREADINGS.....................................................................................38REFERENCES................................................................................................39APPENDIX:SAMPLEIPVIDEOCONFIGURATIONS........................................40Minimum32DSChannelCMs/HGsforIPVideo...........................................................41
Minimum24DSChannelCMs/HGsforIPVideo...........................................................42
Minimum16DSChannelCMs/HGsforIPVideo...........................................................42
Minimum8DSChannelCMs/HGsforIPVideo.............................................................43
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 4
INTRODUCTIONTheinternetprotocol(IP)hasbeenusedtotransporttelevision(TV)programinginsomeformforoveradecade.ThetelcocompanieshavebeenusingIPtocommerciallydistributetelevisionoverDigitalSubscriberLine(DSL)technologyforatleastthepastfiveyears.Inordertodoso,thenetworkandsubscribertechnologieshavebeenrefinedtoprovideaveryacceptablevideoserviceoveranIPtransportnetwork–generallywithoutregardtotheintricaciesoftheaccessnetworkinthelastmiletothesubscriber.
PrimarilyduetotheirsignificantinvestmentinMotionPicturesExpertGroup(MPEG)-basedvideotechnology,cabletelevisioncompanieshavebeenmuchslowertoadoptanIPvideoarchitecture.However,itseemslikenearlyalloftheseMultipleSystemOperators(MSOs)haveplansto“eventually”replaceMPEGtransporttechnologywithIPtransporttechnologytoprovideamanagedvideoservicefortheirsubscriberbase.ThepredominantwaytotransportIPoveracabletelevisionnetworkistouseequipmentthatsupportstheDataOverCableSystemInterfaceSpecification(DOCSIS).UnlikeDSL,DOCSISusesasharedmediumbutprovidesarichsetoftoolstoensureQualityofService(QoS)toeachsubscriber.ThispaperwilladdresssomeoftheissuesinusingDOCSIStotransportIPvideo.
TARGETAUDIENCEThisdocumentisintendedtobereadbypeoplewithawidevarietyofbackgroundsandexperience.Whilesomeoftheaudiencemayhaveabroadunderstandingofthetechnologies,othersmayhavedeepexperiencewithcertainpartsbuthavelittleexperiencewithothers.Stillothersmaybenewtomostofthesetopics.
Thefirstseveralsectionswilltrytoprovideeveryonewiththerequisiteinformationtounderstandtherecommendationsandthereasoningforthem.Ifoneormoreofthebackgroundsectionsarealreadyunderstoodbythereader,pleasefeelfreetoskiptothenextsection.
VENDORANDPRODUCTAGNOSTICISMTheideasandrecommendationsexpressedinthisworkarebelievedbytheauthorstobeapplicableonmostproductsfrommostindustryvendors.Somebackgroundassertionsmayprovetobeuntrueonsomeproductsandsomerecommendationsmaybeunrealizableonsomeproducts.IfissuesarisewhenattemptingtotuneanIPvideosystem,pleaserefertoproductinformationandcontactsfromthecomponentequipmentvendors.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 5
TECHNOLOGYBACKGROUNDVideoServices
LinearBroadcastTVvs.On-demandContent
Sincetheveryfirsttelevisionnetworkbroadcastovertheair,televisionhasfollowedthelinearTVmodel–thatisthattheprogramlineuphasbeenpre-scheduledsothatanaudiencemusttuneintoaparticulartelevisionchannelataparticulartimetoviewaparticularprogram.ThisisalsoknownasappointmentTV.Fromatransmissiontechnologystandpoint,alargenumberofviewerswereabletoviewthesameprogramatthesametimebecausetheprogramwas(andcontinuestobe)broadcastviaradiofrequency(RF)carrierstoallusersintheviewingareaatonce.Oncethesetransmissionsweredistributedviaacableservice,thecableTV(onceknownascommunityantennatelevision)companiesfollowedthismodelbybroadcastingthereceivedsignalstoallsubscribers.
Overtime,somecablecontentcompaniescameupwiththeideaofon-demandtelevision.Inthismodel,asinglesubscriberrequestsaparticularprogramtobesent.Basedontheideathateachviewerwantstobeincontrolofthetimingoftheirviewingexperience(nottomentionbeingabletocontrolthe“trickmodes”ofpause,rewind,skip,fast-forward,etc.),eachon-demandsessionispresentedasifitwereunicast;regardlessofthetransmissiontechnologyusedtodeliverit.Thus,twoviewersincloseproximitywhoarewatchingthesameon-demandprogramareeachlikelytobeviewingadifferenttransmissioncopyofthecontent.
TelevisionChannelViewership
Thefollowinggraphs(Figures1and2)showasnapshotoftheactualobservedTVviewershipforaU.S.majormetropolitanareaduringDecember2015.Figure1showsthatabout95%oftheviewerswerewatchingatotalofonlytenTVchannels.WhenanadditionaltenTVchannelsareaddedtothefirstten,onlyabout2.5%more(seeFigure2)oftheviewerscanbeserved.Tenmorechannelscapturesonlyanadditional1%oftheviewers.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 6
Figure1:TVviewershipvs.numberofchannelsviewed
Figure1pointstoanopportunitytooptimizeasmallnumber(ten)ofTVchannelstobecarriedina“broadcastfashion”suchthatallviewershaveaccesstotheseTVchannelsatalltimes.Furthermore,wheneveraviewertunestoanewchannel,thereisabouta95%chancethattheywilltunetooneofthesetenchannels.Inhistoricvideocircles,thissmallgroupofchannelswouldbereferredtoasthe“shorttail”astheyareasmallnumberofchannelswiththebulkoftheviewers.Fartotherightofthegraph,asmorechannelsareincluded,averysmallpercentageofsubscriberscanbeservicedbyaddingmanyadditionalTVchannels–thusthenotionofa“longtail”.Somewherebetweentheshorttailandthelongtailwouldbeconsideredthe“mediumtail”.Thegraphshownheredoesnothavemuchofamediumtail.
Figure2:TVviewershipvs.numberofchannelsviewed(firsttenremovedforscalemagnification)
Thegraphshereshowtheviewingpatternsofaparticularaudiencewithaparticulardemographic.Whilethepatterntendstobethesameacrossgroupsofsubscribers,amorediverseaudiencemayproduceamore“flattened”viewershipgraphwithasmallershort-tailandlargermedium-tailandlong-tailcomponents.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 7
ShortTail:Linear,MultipleViewers(Broadcast)
Historically,allcabletelevisionvideoareservedbyasetofMPEGstreamsthatwerecarriedonasinglequadratureamplitudemodulation(QAM)channelperstream.ThissetofMPEGstreamsisbroadcasttoeverytelevisionvieweratalltimes.Theviewer’sset-topbox(STB)tunestoadifferentpreexistingQAMchannelfrequencywhentheviewerchangestheTVprogramontheset-topbox.EveryQAMchannelisalwaysavailableandthereisnoneedforprogramchangesignalingtothenetwork.Thissortofbroadcastapproach(albeitmodifiedforIPmulticast)mightstillbeusefultocarrytheshorttailcontent–especiallytruewhentheshorttailcontentmightbecarriedonasfewastenTVprogramstreams.
MediumTail:Linear,MultipleViewers(SDV)
LinearMPEGvideoservicetookastepforwardinconservingbandwidthwiththeinnovativeapproachknownasSwitchedDigitalVideo(SDV).ThistechnologymightbedescribedasswitchedbroadcastlineartelevisioninthataprogramstreamisassignedtoaQAMchannelwithinavideoservicegroup(SG)onlywhenaSTBrequeststheprogramstreamfromanSDVcontroller.OncetheprogramstreamisassignedtoaQAMchannel,theSTBretunesareceivertotheQAMchannelanddeliversthevideo.Inthiswaythelinearvideostreamisdeliveredon-demandbutsubsequentrequestersforthesameprogramstreamfromthesamevideoSGcanlistentothesameexactbroadcastMPEGstreambytuningtothesameQAMchannel.Thissharingofthelinearbuton-demandstreamgreatlyreducestheamountofbandwidthcapacityusedtodelivertheprogramstreamtomultipleviewersoverthebandwidththatwouldbeneededtotransmittoeachrequesterindividually.Thiseconomycomesatthepriceofsubscribercontrol(nostart,stop,ortrickmodes)oftheon-demandstream.Ofequalimportanceisthefactthatthisapproachtoprogramdeliveryalso“turnsoff”theprogramstreamtothevideoSGwheneverthesystemhasdetectedthatthelastvieweroftheprogramstreamhastunedtoanotherprogram-asaresult,bandwidthonthecableplantisnotwastedbydeliveringun-viewedprograms.
LongTail:On-demand,SingleViewer(VOD)
On-demandvideohaslongbeenassociatedwithhomeviewingofsingleprogramcontent(i.e.movies).However,thesametechnologycanbeusedtoserveindividualsubscriberswhowishtoviewspecialinterestorsignificantlytime-shifted(longerthannormaljitterbuffers)linearcontent.IntheMPEGvideoworld,arequestedprogramstreammightbeplacedontoanamountofpreviouslyunallocatedQAMchannelbandwidthforusebyasinglesubscriber.Suchatechnologymightallowtheuseoftrickmodesonthestreamtoprovidetheinterfaceasonemightfindonahomevideoplayer.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 8
TVChannelChangeExpectations
Videosubscribersexpecttheirvideoservicestoberesponsivetotheirinputs.Whileanumberofarticlesindicatethatacceptablechannelchangetimesareontheorderofacoupleofseconds,onestudyofviewerbehaviorconcludedthatinordertoguaranteeanacceptablequalityofserviceforchannelzapping,thezappingtime(timefromstimulustochangeachanneluntilvideoandaudiofornewchannelappear)needstobelessthanhalfasecond(430milliseconds[1]).
InternetProtocol(IP)Theinternetprotocol(IP)wascreatedtogetpacketsfromoneplacetoanother,possiblythroughmultipledevicesor“hops”.IPdoesnotguaranteethatpacketswillnotbelost.IPdoesnotguaranteethatpacketswillarriveinorder.IPdoesnotguaranteethatanapplicationwillonlyreceivethepacketsthatareusefultothatapplication.Alloftheseextrafeaturesarelefttothenexthigherlayers–eithertransmissioncontrolprotocol(TCP)oruserdatagramprotocol(UDP).
Connection-Orientedvs.Connectionless
BothTCPandUDPwillproperlyroutepacketstotheproperdestinationapplication(andfilterthepacketsfromotherapplications).However,otherfeaturesdependonwhetherthereisacontrolledvirtualconnectionbetweenthesenderandreceiverorwhetherthereisanuncontrolledmassofpacketsbeingtransferred.
TransmissionControlProtocol(TCP)
TCPisaconnection-orientedprotocol.Ithastheabilitytoensurereliable,in-ordertransportfromasendingapplicationtoadestinationapplication.Thesefeaturesareaccommodatedbytheuseofsequencenumbers,resequencingbuffers,acknowledgements,andretransmissions.TCPconnectionstypicallypresentastreamoftransferredpayloadbytestothereceiverwithoutanyindicationofwheretheactualtransportpacketboundariesmayhaveoccurred.
UserDatagramProtocol(UDP)
UDPisaconnectionlessprotocol.ItcanproperlyroutetransportpacketstotheproperapplicationbutitdoesnotsharethereliabilityorpacketorderingfeaturesofTCP.Italsotendstopresenttransportpacketsaspackets–headerandall-tothereceivingapplication.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 9
IPMulticast–OneStream,MultipleDestinations
Whileinternetprotocolversion4(IPv4)doessupporttheconceptofabroadcastdestinationaddress,andthisbroadcastaddressisusedbyBOOTPandDHCP,broadcastdestinationaddressusebyotherprotocolsistypicallynotfound.Instead,multicastgroupaddressingtendstobeusedinplaceofbroadcastaddressing.Infact,wheninternetprotocolversion6(IPv6)wasdefined,theconceptofabroadcastdestinationIPaddresswasreplacedwithmulticastdestinationaddressingtotheall-hostsmulticastgroup.Whilethedistinctionissubtle,thereistheadvantagethatbandwidthdoesnotneedtobeconsumedforgrouptrafficunlessagroupmemberispresent(similarfunctionalitytoSDV).IfaTVprogramstreamisbeingtransmittedtomultipleviewersusingmulticastaddressing,thenthereisanopportunitytohaveallviewersreceivethesamecopyoftheTVprogramstream(alsosimilarfunctionalitytoSDV).Whilethismodecanleadtosomecomplicatedretransmissionrequestscenarios,itisoverallthemostefficientIP-basedtransmissionmechanismintermsofbandwidthused.Multicastisbestusedforshort-tailprogrammingwheremanyviewersarereceivingthesameprogramstream.Itmayalsobeusedformedium-tailprogramminginanefforttosharemediastreamsacrossmultipleviewers.MulticasttransmissionusuallyusesUDPtransport.
IPUnicast–OneStream,SingleDestination
ThedestinationaddressingmodeusedmostofteninIP(bothIPv4andIPv6)istheunicastorsingle-hostaddress.AsinglehostwouldbeassignedthisaddressandanyIPpacketswiththishost’sdestinationIPaddressshouldbeignoredbyallhostsexcepttheonethathasbeenassignedtheunicastaddress(exceptforafewspecialcasesinwhichpacketsarebeingsnooped).Thus,unicasttrafficcannotbesharedacrossdestinations.IfaTVprogramstreamisbeingtransmittedtomultipleviewersusingunicastaddressing,theneachviewergetsitsowncopyoftheTVprogramstream.Duetotheone-to-oneservice,thisformofIPcommunicationsiseasytocontrolandtheuseofaTCP(seesection:TransmissionControlProtocol(TCP))canguaranteetransmissionofthemediastream,albeitattheexpenseofreplicasofsingle-userstreams.UnicastdestinationIPaddressing(a.k.a.IPunicast)isbestusedforlong-tailprogrammingorevenmediumtailprogrammingiftherearenotmanyviewers.UnicastusuallyusesTCPtransport,butUDPisalsosometimesused.
AdaptiveBitrateVideo
IPUnicastABRVideo
Adaptivebitrate(ABR)technologyrequirestheencodingofasingleprogramintomultiplestreamsofdecreasingresolution(andthereforeaveragebitrate).Eachstreamisbrokenintochunksofconstanttimethataligntothesamequanta.Allofthechunk
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 10
filescorrespondingtothesameinstantintimearelistedinamanifestfile.Allofthesechunksofeachoftheresolutionsandtheirmanifestfilearestoredinfilesonthevideoservernetwork.WhenanABRclientstartsplayingaprogram,itrequestsamanifestfileandusuallystartsbyrequestingthefile(usuallyanHTTPrequest)withthelowestresolutionchunk(althoughsomesystemsstartwiththehighestresolutionchunk).Itlooksatthenextmanifestfileandimmediatelyrequeststhefileforthesecondchunk.Ifthe2ndchunkfilearriveslongbeforeitisneeded,thentheplayermaydecidetorequestaslightlyhigherresolutionforthe3rdchunkfile.Theplayerwillplayprogressivelyhigherresolutionsperchunkuntiliteitherreachedthemaximumresolutionorthenextchunkfiletakeslongerthanexpected;inwhichcasetheplayermaystepdowninresolutionforthenextchunk.
Figure3:UnicastAdaptiveBitrateTransmission
Multicast-assistedABRVideo
Multicast-assistedABR(M-ABR)wascreatedtoleverageIPunicastABRadvantagesinconjunctionwiththebandwidth-savingsofIPmulticast.StandardABRvideoplayersmakeHTTPrequeststotheirhomevideoIPgatewayforABRvideocontent.ThehomevideoIPgatewayisadevicewhichisplacedbetweentheDOCSISnetworkandthehomeIPnetwork.ThehomeIPgatewaymayhavealocaldatacache(flashdiskorsimilar)wherebyitmaystorecontentthatitreceivesoveramulticastdistributionservice.ThiscontentmaybeprovidedviaunicastHTTPprotocolstostandardABRplayers.Meanwhile,thehomevideoIPgatewayjoinsanyavailablemulticastgroupsfortherequestedvideocontentsothatthecontentcanbeprepositionedintothelocaldatacacheinanticipationofarequestforthenextvideochunks.Ideally,themulticastprepositioningofthevideochunksinthehomevideoIPgatewaylocaldatacachecanbeperformedatareasonablyhighresolutionwithgoodQoSsoastoprovideagooddisplayfortheABRclientsinthehome.
Multi
Bit Ra
te Re
solut
ion Pr
ofiles
Time
ABR1
00:3000:20 01:2000:40 00:50 01:1000:10 01:00
Network Bandwidth Network Congestion
ABR2
ABR3
ABR4
Conte
nt Pre
parat
ion
Transcoder
Packager OriginServer
Conn
ected
IP De
vices
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 11
HomeVideoIPGatewayCacheMiss
IfthehomevideoIPgatewaydoesnothavetherequestedABRchunkfile,thenitbehavesverymuchliketheunicastABRcaseandforwardstheHTTPABRrequesttowardsthecachesandserversinthenetworkwhothenprovidethechunkfilebacktothehomevideoIPgateway.ThehomevideoIPgatewaythenforwardsthechunkfiletotheABRvideoclient.
HomeVideoIPGatewayMulticastJOINandCacheHit
WhenahomevideoIPgatewaynoticesthatoneoftheprogramstreamsthatitisservingbecomesavailableviaamulticastgroup,thenitmakesarequesttoJOINthecorrectmulticastgroupatitsgroupaddress.
OncethemulticastgrouppacketsbeginarrivingatthehomevideoIPgateway,itcanstopforwardingunicastABRrequestsintothenetworkandsimplyservetherequestedchunksoutofitsowncachememory.
MulticastController
Themulticastcontroller(runninginaservernorthoftheCCAP)decideswhichprogramstreamsaremadeavailabletothehomevideoIPgatewaysviamulticastanduponwhichgroupaddress.ItpublishesthislisttothehomevideoIPgateways.
HomeEquipmentClarificationThereissometimesanambiguityaboutwhichdeviceinahomeisbeingusedformanagedIPvideo.TheprimaryusecasewouldusehomeequipmentasshowninFigure4buttherearesomemanagedvideosystemsthatdeviatefromthisreferencearchitecture.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 12
Figure4:Homenetworkwithhomegateway
CableModem
ThecablemodemprovidesabridginginterfacetotheDOCSISnetwork.Cablemodemsmaybeeitherembedded(asinthecaseoftheHomeGateway)ortheymaybestand-alone.Eitherway,theCMbehavesthesamewayforthepurposesofitsDOCSISconfiguration.Alloftheforthcomingrecommendationsmaybeappliedtoembeddedaswellasstand-aloneCMs.
HomeGateway
TheHomeGateway(HG)isawhole-homeappliancewhichprovidesmultipleservicesoverDOCSISviatheembeddedmulti-channelDOCSIScablemodem.TheseservicesmayincludebutarenotlimitedtomanagedIPvideo,telephony,high-speeddata(HSD),homealarmandWi-Fihotspot.TheHGisusuallyplacedinaninconspicuouslocationasitusuallydoesnotincludeavideoplayer(i.e.itisconsideredtobe“headless”).IftheHGdoescontainavideoplayerthenitwouldnormallybeplacednearthemaintelevisionofthehome.TheHGshouldcontainsomeamountofbufferingspaceforshort-termvideostorage.
IPVideoPlayer
ThevideoplayerisanIPdevicethattypicallyusesHTTPtorequestvideochunksfromaserver(inthiscase,theHG)torenderthevideoforadisplaydevice(likeatelevisionset).Thevideoplayermayhavebufferingspacethatisusedtosmoothoutjitterinthehomenetwork.
HGCM
IPVideoPlayer
SmartTV
Tablet
ConsolePC
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 13
SmartTV
AsmartTVisonewhichiscapableofreceivingover-the-top(OTT)IPvideoandotherservicesviatheinternet(HSDservice).Itusuallydoesnotperformtheroleofvideoplayerbyrequestingchunksfromthehomegateway.
Console
ManymoderngamingconsolesarecapableofservingasclientstoOTTvideoservices.IfusedthiswaytheyoperateinawaysimilartosmartTVs.
Tablet&PCs
Tablets,mobilephones,andPCscontainvideoplayerapplications.TheseapplicationsmayworkwiththemanagedIPvideoservice(inwhichcasetheybehavelikeanIPvideoplayertorequestvideochunksfromtheHG)ortheymayworkwithOTTvideo.
Figure5:Homenetworkwithoutahomegateway
IPVideoClientw/multicastSomecableprovidersmaychoosetonotdeployhomegatewaysandinsteadchoosetodeploymoresophisticatedIPvideoclients.Inthiscase,multicastsessionsareinitiatedbythevideoclient.Furthermore,themulticastIPsessionsflowallofthewaytotheIPvideoclient.Thevideoclientitselfwouldberesponsibleforanyandallprogrambuffering.
CM
IPVideoClientw/multicast
SmartTV
Tablet
ConsolePC
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 14
DataoverCableSystemInterfaceSpecificationVersionI01oftheDataoverCableSystemInterfaceSpecification(DOCSIS)wasfirstpublishedonMarch26,1997withtheintentofdeployinghigh-speeddatacommunicationsovercabletelevisionsystems.CableTelevisionLaboratories,Inc.(CableLabs),anditsmemberandvendorcompanies,preparedaseriesofspecificationsthatpermitthedefinition,design,development,anddeploymentofdata-over-cablesystemsonauniform,consistent,open,non-proprietary,multi-vendorinteroperablebasis.Theserviceallowstransparentbi-directionaltransferofIPtrafficbetweenthecablesystemheadendandcustomerlocations,overanall-coaxialorhybridfiber-coaxHFCcablenetwork.
CableModemCapabilitiesTheDOCSISprotocolhaspublisheditsfifthgeneration(includingDOCSIS1.0,1.1,2.0,3.0,and3.1)ofspecificationsinnineteenyears.Astheprotocolhasevolved,sohasthehardwarethatrunsit.However,duetoverycarefulplanningbyboththeMSOsandvendors,eachgenerationoftheDOCSISprotocolhasalwaysmaintainedtheabilitytocoexistwithearliergenerationsofDOCSISequipment.Oneoftheprimarytoolstopreservingthatabilityisthenotionofacapabilitiesnegotiationbetweenthecablemodems(CMs)andthenetworkequipment.
Duetotrafficengineeringconcerns,theauthorsdonotrecommendthatCMs/HGswithfewerthan24SC-QAMdownstreamchannelreceiversbeusedforIPvideoservices.
NumberofCMReceiversandTransmitters
Pre-3.0DOCSISCMs
Theveryfirstcommercialcablemodemssupportedonedownstream(DS)single-channelQAM(SC-QAM)andoneupstream(US)single-channelQAM(SC-QAM).ThismodelprevailedthruDOCSIS1.0,DOCSIS1.1,andDOCSIS2.0.
• 1DSSC-QAMreceiverx1USSC-QAMtransmitter
DOCSIS3.0CMs
CablemodemswitheachofthesecombinationsweresupportedintheDOCSIS3.0specificationswheremultipledownstreamSC-QAMandmultipleupstreamSC-QAMchannelsupportwascoupledwithchannelbondinginboththedownstreamandupstreamdirections.
• 4DSSC-QAMchannelreceiversx4USSC-QAMchanneltransmitters• 8DSSC-QAMchannelreceiversx4USSC-QAMchanneltransmitters• 16DSSC-QAMchannelreceiversx4USSC-QAMchanneltransmitters
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 15
• 24DSSC-QAMchannelreceiversx8USSC-QAMchanneltransmitters• 32DSSC-QAMchannelreceiversx8USSC-QAMchanneltransmitters
DOCSIS3.1CMs
TheDOCSIS3.1specificationsbuiltuponthemultipleSC-QAMchannelandchannelbondingcapabilitiesofDOCSIS3.0byaddingOFDMdownstreamandOFDMAupstreamchannels.Whenconfiguredfortheirmaximumsettings,theseOFDMandOFDMAchannelsarecapableofsupportingmuchmorebandwidththantheirSC-QAMcounterparts.
• 32DSSC-QAM+2DSOFDMchannelreceiversx8USSC-QAM+2USOFDMAchanneltransmitters
NumberofDownstreamServiceIdentifiers
DOCSIS3.0introducedthedownstreamserviceidentifier(DSIDs)asacontexttagthatisinsertedintotheDOCSISdownstreamextendedheaderofallpacketsthatbelongtoadownstreambondedserviceflowand/oramulticastgroupserviceflow.ADOCSIS3.0CMisrequiredtosupportatleastsixteenresequencingDSIDs(andassociatedbondingcontexts)andatleastsixteenmulticastDSIDs(andassociatedmulticastcontexts).DOCSIS3.1CMsareexpectedtosupportmorethanthisminimumnumberofDSIDsbutthespecificationminimumremainsthesame.
ChannelandFlowAssignmentDOCSIS3.0introducedtheconceptofattribute-basedresourceassignment.Aserviceflowcreationrequest–whetherfromaCMconfigurationfileorsomeformofdynamicserviceflowsignaling–canindicatethattheresourcesusedtoservicetherequestneedtohaveaspecificcombinationofattributes.Thisspecificcombinationofresourceattributesiscomparedbythecablemodemterminationsystemorconvergedcableaccessplatform(CMTS/CCAP)totheresourcemasksofalloftheavailablesinglechannelsandbondinggroups.
AttributeMaskBitDefinition
Thehigh-orderhalfofthemask(16bits)isreservedforDOCSISspecificationuse;3bitsarecurrentlydefinedinDOCSIS3.0andDOCSIS3.1:
• Bonded–Highestorderbit;inaserviceflowcreationrequestattributemask,thisbitindicateswhethertheserviceflowshouldbebonded.Inaresourceattributemask,thisbitindicateswhethertheresourceisasinglechannelorabondinggroup.
• LowLatency–2ndhighestorderbit;inaserviceflowcreationrequestattributemask,thisbitindicateswhethertheserviceflowshoulduseresourcesthatallowforalowlatencypath.Inaresourceattributemask,thisbitindicateswhether
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 16
theresourceallowsfora(relatively)lowlatencypath.ThedefinitionofexactlywhatlowlatencymeansinthiscontextislefttotheCMTS/CCAPvendor.
• HighAvailability–3rdhighestorderbit;Inaserviceflowcreationrequestattributemask,thisbitindicateswhethertheserviceflowshoulduseresourcesthatallowforhigh-availabilitypath.Inaresourceattributemask,thisbitindicateswhethertheresourceallowfora(relatively)high-availabilitypath.Thedefinitionofexactlywhathigh-availabilitymeansinthiscontextislefttotheCMTS/CCAPvendor.
Thelow-order16bitsofattributemasksareavailableforMSOdefinitionanduse.
SomepossiblesuggestedassignmentsforMSO-definedattributebits:
• IPVideoservice
• IPVideomulticast(mightbeasubsetofchannelsthatsupportIPVideoserviceabove)
• Telephony
ServiceFlowRequestAttributeMasks
EachserviceflowcreationrequestisassociatedwiththreeAttributeMasks:
• RequiredAttributeMask-TheCMTSonlyuseschannelsorbondinggroupswiththesebitssetintheattributemask
• ForbiddenAttributeMask-TheCMTSonlyuseschannelsorbondinggroupswiththesebitsNOTsetintheattributemask
• AttributeAggregationRuleMask-IftheCMTS/CCAPiscapableandconfiguredtodoso,theCMTS/CCAPcreatesabondinggroupthatisalogicalcombinationoftheattributesthatcorrespondtothesebitpositions
o A‘1'inthismaskforanattributemeansthateachchannelmusthavethisattribute
o A‘0'inthismaskforanattributemeansthatatleastonechannelmusthavethisattribute
Theseserviceflowcreationrequestattributemasksmaybeeitherdirectlysignaledintherequestitself(astheymightbeinaPacketCableMultimediagate)ortheymaybedefinedaspartofaprovisionedserviceclassontheCMTS/CCAP(astheymightbeforasignaledmulticastJOIN).
ResourceAttributeMasks
Everyconfiguredresource(i.e.channelsandbondinggroups)inthesystemhasaresourceattributemaskdenotingthecapabilitiesofthatresource.Thisresourceattributemaskiscomparedtotheattributemasksoftheserviceflowrequest.Thechannelandbondinggroupattributesarenotconnected;theattributemaskofasingle
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 17
channelandtheattributemaskofaconfiguredbondinggroupwhichincludesthechannelmaynothavematchingattributebits.
ResourceMaskMatchingforAssignment
TheCMTS/CCAPattemptstoassignserviceflowstochannelsorbondinggroupssuchthatallrequiredattributesarepresentandnoforbiddenattributesarepresent.Inthisway,resourcesmaybeconfiguredsuchthatcertainservices(likeIPVideo)maybesteeredtowardtheresourceorawayfromtheresource.
ServiceFlowTypesAserviceflowisaMAC-layertransportservicethatprovidesunidirectionaltransportofpacketseitherupstreamtotheCMTS/CCAPfromtheCMordownstreamtotheCMfromtheCMTS/CCAP.Thefollowingheadingsdenotedifferentwaysinwhichserviceflowsmightbedescribed.Thesetypesareorthogonalinnatureandthuscanbecombinetodescribeaparticularserviceflow(e.g.anunbondeddynamicserviceflowmightbeusedfortelephonywhereasabondedstaticserviceflowmightbeusedtocarryunicastIPvideo).
Unbondedvs.Bonded
Abondedserviceflowisoneinwhichthedataoftheserviceflowistransportedacrossthechannelsofabondinggroup.Abondinggroup,inturn,isasetofsinglechannelsassociatedwithasingleMACDomainwhichreachesacommonsetofcablemodemsandwhichtransportsatleastonebondedserviceflow.Bondedserviceflowsmayeitherbesequenced,inwhichcasethepacketsareguaranteedtonotarriveoutoforder(withinsomesequencinginterval);ortheymaybeunsequenced,inwhichcasetheapplicationmustnotconsiderorderimportant.Mostbondedserviceflowsaresequenced.BondinggroupsmaybeconfiguredortheymaybedynamicallycreatedwhentherequestisreceivedbytheCMTS/CCAPasguidedbytheserviceflowrequestAttributeAggregationRuleMask.
AnunbondedserviceflowisoneinwhichthedataoftheserviceflowistransportedononlyasinglechannelassociatedwithaMACDomainwhichreachesacommonsetofcablemodems.Unbondedserviceflowsmayhavelesslatencythanbondedandsequencedserviceflowsduetononeedforresequencing.
Staticvs.Signaled
Serviceflowsmaybeeitherstaticallycreatedviaprovisioningordynamicallycreatedduringruntime.ServiceflowsmaybestaticallycreatedatCMregistrationtimebythebackofficeprovisioningserverplacingserviceflowdefinitionsintoaCMconfigurationfilewhichisdownloadedbytheCMaspartoftheinitializationprocess.Aserviceflow
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 18
mightalsobedynamically-createdasaresultofapplicationsignaling(Ex.IGMP,PacketCableMultimedia,etc.)duringruntime.
MACManagementDynamicServicesTransactionsTheDOCSISprotocolhasgottenevermorecomplexoveritsalmost20-yearhistory.TheprocessthatstartedasasimpleQoSenginecontrolledviaastaticconfigurationfilehasmorphedintoacomplicateddynamicservicesenginewithmultipletransactionsperservicerequest.Theresultisthatservicerequestscantakealongtimetoprocessandtheyhavemanymorewaystofailthantheyoncedid.
TheDOCSISprotocolusesa3-waytransactionforcriticalsignalingoperationsbetweenaninitiatorandatarget.Inmanycases,theCMTS/CCAPMACDomainistheinitiatorandtheCMisthetargetbuttherearesometransactionsinwhichtheCMmightbetheinitiator.A3-waytransactiontypicallytakestheformoftheinitiatortransmittingarequest(withparameters)tothetarget(andrunningatimerwhilewaitingforaresponse),thetargetperforminganactionandtransmittingaresponse(withresults)backtotheinitiator(andrunningatimerwhilewaitingforanacknowledgement),andthentheinitiatortransmittingafinalacknowledgement(ideallywithnoimportantparameters)tothetargettoinformthetargetthattheresponsewasreceived.Ifoneofthetimersexpiresthenthecorrespondingmessagetransmissionisretried(uptoacertainnumberoftotaltransmissions)andthetimerisrunagain.Typicallytheremaybeasmanyasthreeretransmissionsofeithertherequestortheresponse.Theacknowledgementhasnocriticaldatasonotimerisrun.
ADOCSISMACManagementDynamicServicestransactionisnecessaryforanyofthefollowingactions:
• DynamicServicesAddition(DSA):Createaserviceflow(3-waytransaction)
• DynamicServicesChange(DSC):Changeanexistingserviceflow(3-waytransaction)
• DynamicServicesDeletion(DSD):Deleteanexistingserviceflow(2-waytransactiononly)
• DynamicChannelChange(DCC):reassignthechannelsetofaCMwithreboot(3-waytransaction)
• DynamicBondingChange(DBC):modifychannelorbondingparameters(3-waytransaction)
o ModificationstoCMTransmitChannelConfiguration(TCC)
o ModificationstoServiceIdentifier(SID)Clusterparametersforupstreambonding
o ModificationstoCMReceiveChannelConfiguration(RCC)
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 19
o Modificationstodownstreamserviceidentifiers(DSIDs)parametersfordownstreammulticastfilteringand/orbonding
o ModificationsofSecurityAssociations(SA)
Sometypesofservicerequestsmayrequirethechainingofmultipletypesofthesetransactions.Forexample,inherentintheprocessofcreating/modifying/deletingaunicastserviceflowinonedirectionisaDOCSISMACManagementDynamicBondingChangetransactiontocreate/change/deletetheparametersnecessaryforabondedorserviceflowfollowedbyaDOCSISMACManagementDynamicServicesAdd/Change/Deletetransaction.PertheDOCSISprotocol,theCMcanonlyhandleonlyoneDynamicServicesMACManagementtransactionatatimesothesetwotransactionsmustbedoneserially.
EachoftheseDOCSISMACManagementtransactionsinvolvesignalingoverapossiblynoisyandcongestedRFPlantwherebyuptofourmessagetransmissions(at1-secondtimeoutintervals)mayberequiredforeachmessage.
QualityofServiceClassifiersassociatepacketsintoexactlyoneServiceFlow.TheServiceFlowEncodingsprovidetheQoSParametersfortreatmentofthosepacketsontheRFinterface.
Classifier
AClassifierisasetofmatchingcriteriaappliedtoeachpacketenteringthecablenetworkwhichconsistsofsomepacketmatchingcriteria(destinationIPaddress,forexample)andaclassifierpriority.AQoSClassifieradditionallyconsistsofareferencetoaserviceflow.IfapacketmatchesthespecifiedpacketmatchingcriteriaofaQoSClassifier,itisthendeliveredonthereferencedserviceflow[8].
Thefollowingarealloptionsforuseinclassifiers:
• Priority:determinesthesearchorderforthetable.Ifapacketmatchesmorethanoneclassifier,theclassifierwiththehighestpriorityisusedtodeterminewhichserviceflowwillcarrythepacket.
• Source
o MACAddress
o IPaddress
o IPaddressmask
o TCP/UDPSourcePortStart,TCP/UDPSourcePortEnd
• Destination
o MACAddress
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 20
o IPaddress
o IPaddressmask
o TCP/UDPDestinationPortStart,TCP/UDPDestinationPortEnd
• Ethertype/ServiceAccessPoint(SAP)
• Protocol
• IPTOS/DSCPRange/Mask
• 802.1PPriorityRange
• 802.1QVLANID
QoSParameters
TheQoSParametersofaserviceflowconsistsofthreesetsofServiceFlowEncodings–oneforeithertheConfigured/AuthorizedSet,onefortheAdmittedsetandonefortheActiveset.ServiceFlowEncodingswhicharedefinedinaCMconfigurationfileorwhicharesignaledasauthorizedareconsideredtheConfigured/AuthorizedSet.TheServiceFlowEncodingwhichcorrespondstoresourcesthathavebeenreservedforusebyaserviceflowareconsideredtobetheAdmittedset.TheServiceFlowEncodingwhichcorrespondstotheresourcesthathavebeenactivatedfortheserviceflowisconsideredtheactiveset.
Aserviceflowencodingconsistsofthefollowingparameters
• ServiceClassName–usedasakeytoidentifyapredefinedserviceflowencodingontheCMTS/CCAP.Ifusedinaconfiguredorsignaledserviceflowrequest,thenthedefinitionofthepredefinedserviceflowencodingontheCMTS/CCAPisusedastheserviceflowencodingoftherequestedserviceflow.Someparametersofthepredefinedserviceflowencodingmaybeoverriddenintheserviceflowrequest
• ServiceFlowRequiredAttributeMask–seesection:ServiceFlowRequestAttributeMasks
• ServiceFlowForbiddenAttributeMask–seesection:ServiceFlowRequestAttributeMasks
• ServiceFlowAttributeAggregationRuleMask–seesection:ServiceFlowRequestAttributeMasks
• TrafficPriority-0to7—highernumbersindicatehigherpriority.Thedefaultpriorityis0(lowest)
• MaximumSustainedTrafficRate–(a.k.a.Tmax)atoken-bucket-basedratelimitforpackets;doesnotlimittheinstantaneousrateoftheServiceFlow.Ifthisparameterissettozero,thenthereisnoexplicitly-enforcedtrafficratemaximum
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 21
• MaximumTrafficBurst-tokenbucketsize(inbytes)forthisServiceFlow.Theminimumvalueis1522bytes.Thedefaultvalueis3044bytes.Thisparameterhasnoeffectunlessanon-zerovaluehasbeenprovidedfortheMaximumSustainedTrafficRateparameter
• MinimumReservedTrafficRate-(a.k.a.Tmin)aCMTS/CCAPshouldscheduleforwardingofallserviceflows'trafficsuchthateachreceivesatleastitsMinimumReservedTrafficRatewhentransmittingpacketswiththeAssumedMinimumReservedRatePacketSize.Thisparameterdefaultstoavalueof0bits/sec(i.e.,nobandwidthisreservedfortheflowbydefault)
• AssumedMinimumReservedRatePacketSize-IftheserviceflowsendspacketsofasizesmallerthantheAssumedMinimumReservedRatePacketSize,suchpacketswillbetreatedasbeingoftheAssumedMinimumReservedRatePacketSizeforcalculatingtherateforwardedfromtheserviceflowforpurposesofmeetingtheMinimumReservedTrafficRate
• PeakTrafficRate-(a.k.a.Tpeak)rateparameterPofatoken-bucket-basedpeakratelimiterforpacketsofaserviceflow.ConfiguringthispeakrateparameterpermitsanoperatortodefineaMaximumTrafficBurstvaluefortheMaximumSustainedTrafficRatemuchlargerthanamaximumpacketsize,butstilllimittheburstofpacketsconsecutivelytransmittedforaserviceflow.Ifthisparameterhasavalueof0,peaktrafficrateisnotlimitedbytheQoSengineandislimitedonlybythelinerateofthechannelorbondinggroup
AdmissionControl
TheDOCSISprotocolsupportsatwo-phaseactivationmodelinwhichauthorizedresourcesforanapplicationarefirst"admitted,"andthen(perhapsafteranend-to-endservicenegotiationiscompleted)theresourcesare"activated",althoughthesetwophasesmaybeandoftenareperformedsimultaneously.Thismodelservesthepurposesof:
• conservingnetworkresourcesforotherusesuntilacompleteend-to-endservicenegotiationhasbeenestablished
• performingpolicychecksandidentifyingavailableresourcesasquicklyaspossiblebeforecommittinganyresourcesfortheservice
Atahighlevel,admissioncontrolisaCMTS/CCAPfunctionthatisusedtodeterminewhenadequateresourcesareavailabletopermitanewserviceflowtobeestablished.Ifadequateresourcesarenotavailable,thenewserviceflowcannotbeadmitted(oractivated).
Primary-CapableDownstreamChannelsADOCSIScablemodemmustreceivecertainpiecesofinformationfromitsCMTS/CCAPMACDomaininordertoenterandremaininservice.Thisinformationisprimarilytiming
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 22
information(SYNCmessagesfromSC-QAMDSchannels,PHY-LinkChannel(PLC)timestampfromOFDMDSchannels)butitalsoincludesdownstreamandupstreamtopologyambiguityresolutioninformationfromMACdomaindescriptor(MDD)messages(helpstoidentifywhichchannelsaCMisexpectedtobeabletouse),aswellasupstreamchanneldescriptor(UCD)andUpstreamBandwidthAllocation(MAP)messagesforatleastoneupstreamchannelineachoftheservicegroupsthatthedownstreamchannelreaches.Adownstreamchannel(whetherSC-QAMorOFDM)thatcarriesthisinformationisknownasprimarycapablebecausethechanneliscapableofbeingusedbytheCMasitsprimarychanneltimingandinformationsource.
DifferentgenerationsofCMshaveslightlydifferentrequirementswithregardtotheirdownstreamprimarychannelrequirements.Pre-3.0DOCSISCMshaveonlyonedownstreamchannelreceiversothedownstreamchannelthatisassignedtothemmustbeprimarycapable.Amultiple-downstream-channelDOCSIS3.0orlaterCMneedonlybeassignedoneprimarycapabledownstreamalthoughoftentheyreceivemultipleprimarycapabledownstreamchannelsandaretoldwhichchanneltouseastheCM’sprimarychannel.DOCSIS3.1CMsallowtheoptionofbeingprovidedaprioritizedlistofprimarycapabledownstreamchannelssuchthattheCMmaytakefaultrecoveryactionsiftheCM’sprimarydownstreamweretoeverfail.Judicious(i.e.sparse)assignmentofprimarycapabilitycansavebandwidthacrosstheservicegroup.
UpstreamSupervisionTheUpstreamChannelDescriptor(UCD)andUpstreamBandwidthAllocation(MAP)DOCSISMACManagementmessagesforasingleupstreamchannelaresometimesreferredtoasupstreamchannelsupervision.Asindicatedinsection0,upstreamsupervisionforatleastoneupstreamchannelmustbecarriedoneachprimarycapablechannel.
Whilesupervisionforeveryupstreamchannelmustbecarriedonatleastonedownstreamchannel,noteveryupstreamchannel’ssupervisionneedbecarriedonaprimarydownstreamforaDOCSIS3.0orlaterCMtousetheupstream.Inthiscase,eachCMmustbeabletoreceivesupervisionforeachassignedupstreamchannelononeofitsdownstreamchannels.Judiciousassignmentofupstreamchannelsupervisioncansaveasignificantamount(0.5to1MbpsperUSchannelsupervision)ofdownstreambandwidththatmaybeusedforservicessuchasIPVideo.
EnergyManagementDOCSIS3.0andlaterCMssupportanenergymanagement1x1modewherebytheCMmonitorstrafficflowand,uponsensingalowutilization,requeststhattheCMTS/CCAPreduceitsactivechannelsettooneupstreamandonedownstream.Obviously,suchareductionwouldprecludethereceptionofabondedunicastormulticastIPvideoflow.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 23
DOCSIS3.1CMssupportanenergymanagementDOCSISLightSleep(DLS)modewherebytheCMmonitorstrafficflowand,uponsensingalowutilization,requeststhattheCMTS/CCAPplacetheCMintoatemporarysleepmode.Obviously,thismodewouldprecludethereceptionofabondedunicastormulticastIPvideoflow.
InordertopreventaCMfromrequestingenergymanagement1x1orDLSoperation,thetype,length,value(TLV)parameteroftheenergymanagementDownstreamEntryBitrateThreshold(TLV74.2.1.1)intheCM’sconfigurationfilemustbeeithersetbelowtheminimumbitrateofasingleIPVideoprogramorsettoavalueofzerotodisableenergymanagementactivitydetection.
IPMulticast
Static
Seesection:UnicastFlows.
Signaled
Multicastclientprotocolsignaling(eg.IGMPv3foranIPv4networkorMLDv3foranIPv6network)istheusualmethodusedtojoinclientstomulticastgroupstreams.Seesection:In-bandMulticastProtocolSignaling.
ThePacketCableMultimedia(PCMM)protocolhasextensionsformanagingIPmulticastgroupserviceflows.Seesection:PacketCableMultimedia.
QoSControlPlaneSignaling
CableModemConfigurationFile
Duringinitialization,eachCMmustdownloadacablemodemconfigurationfile.ThatCMconfigurationfilemaycontainmanypiecesofinformationthatdeterminehowtheCMbehaves.ManyofthesepiecesofinformationaresenttotheCMTS/CCAPaspartoftheregistrationprocess.UnicastpacketclassifiersandserviceflowdefinitionsarethemainpiecesusedtocontrolQoS.OnceinstalledaspartoftheCMregistrationprocess,thesedefinitionscannotbechangedwithoutaCMreinitialization.
UnicastFlows
Aunicastflowandtheassociatedclassifier(s)maybecreatedinthecablemodem’sconfigurationfile.Thisistheprimarymethodthatisusedtocreatetheunicastserviceflowsthatareusedforcachemissesformulticastassistedadaptivebitrate(M-ABR)IPvideo.Ifcreatedviathismethod,theclassifierdefinitionmustaccommodatealltrafficthatisexpectedfortheflowasitcannotbechangedtoaccommodatedynamicservices.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 24
Multicastflows
WhensupportedbytheCMTS/CCAP,oneormoreCMTSStaticMulticastSessionEncoding(TLV64)parametersmaybeconfiguredintheCMconfigurationfiletocausethehomegatewaytostaticallyJOINthemostpopularmulticaststreamsatCMregistrationtime.WhentheCMTS/CCAPseestheCMTSStaticMulticastSessionEncodingintheregistrationrequestmessage,itwillperformalloftheprocessingnecessarytoaddtheCMtothemulticastgroupasiftheCMhadissuedamulticastsignaledJOIN.TheregistrationresponsemessagewillcontainalloftheDSIDinformationnecessaryfortheCMtoreceivethemulticastgroupsession.Thisway,theHomeGatewaywillnotneedtoissuemulticastsignaling(IGMPorMLD)requestsforthesestaticallyJOINedgroupsessions.TheHomeGatewaymaychoosetoeitherstoreordiscardtrafficforthesesessionswhenanotherprogramisbeingviewed.
ThegroupIPmulticastaddresswouldbeprovisionedastheStaticMulticastGroupEncoding(TLV64.1)Itisrecommendedwhereverpossiblethatsource-specificmulticast(SSM)beusedbyspecifyingtheStaticMulticastSourceEncoding(TLV64.2)foreachCMTSStaticMulticastSessionEncoding.TheStaticMulticastCMIMEncoding(TLV64.3)mustbesettoforwardpacketstotheeSTB-IPinterface[Bit17(0x000040)].
AllDOCSIS3.0orlaterCMssupportaminimumof16StaticMulticastMACaddresses.
PacketCableMultimedia
ThePacketCableMultimedia(PacketCableMultimediaprotocolisonewaythatiscurrentlydefinedtosignalthecreation,modification,anddeletionofdynamicunicastandgroupserviceflowsandassociatedclassifier(s)forcertainapplicationssuchastelephony.
ThePacketCableMultimediaprotocolconsistsofanapplicationmanagersendingan“applicationrequestgate”containinginformationaboutCMidentity,flowclassifiers,QoSsettings,etc.toapolicyserverwhothen“authorizes”(accordingtosomelocalpolicy)and“normalizes”(modifiestoproperlyprioritizeamongstpossiblymultipleapplications)therequestbeforesendingthegatetotheCMTS/CCAPasadirective.
IfthegatefromthepolicyserverisdeemedtobeacceptablebytheCMTS/CCAP(i.e.passedaccesscontrolchecks,etc.),thentheCMTS/CCAPmustinstallthegatebycreating/modifying/deletingaserviceflowinonedirectionandthenreplyingtothepolicyservicewithatransactionstatusandpossiblyidentifyinginformationabouttheserviceflow.Thisreplyisforwardedbacktotheapplicationmanager.
Inherentintheprocessof“creating/modifying/deletingaserviceflowinonedirection”istheDOCSISMACManagementDynamicServicestransactionprocessingbetweentheCMTSandtheCMthatisdescribedinsection0.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 25
Thefastestpossiblesuccessful“Gate-Set”transactionwithallitsunderlyingDOCSIStransactionsmayrequirefiftymilliseconds.IfDOCSISMACmanagementrequestorresponsemessagesarelost(perhapsduetonoise?)thentheywilltypicallyberetransmittedthreemoretimes(eachwithatimeout)untilthetransmittingdevicereceivestheresponsefromtheotherdevice.IftheDOCSISMACManagementtransactionseachcatchonlythelastretransmissionofeachofthemessagesthenthesuccessfulgatesetcouldtakeaslongassevensecondsforthesuccessfulcase.ItwouldbesafesttoassumethatatleastonemessagegetslostduringeachGate-Settransactionsoweshouldassumea“normal“channelchangetimeofabout1.25seconds.AnunsuccessfulGate-Setwouldlikelytakeabout5secondssincetheDOCSISDynamicServicestransactionscannotbeinterrupted.
Meanwhile,ifthesubscribertunestoanotherchannelwhilewaitingsomewherebetweenfiftymillisecondsandfivesecondsforthepreviouschannelchangetooccur,sincetheDOCSIStransactionscannotbeinterrupted,theywouldneedtocompletebeforehandlinganewGate-SetforanewchannelforthesameCM.IftheGate-Setgetstriggeredbyatrio(becausemostmulticastIPVideoapplicationsassumethatthreerequestsarealwayssaferthanone)ofmulticastprotocolLEAVEsfortheoldprogramchannelfollowedbythreeJOINsforthenewprogramchannel,theneachindividualrequestwilllooklikeaseparatechannelchangetotheCMTS/CCAPdeviceandwillresultinaDOCSIStransactionlogjam.
Duetothepossibility(likelihood?)ofrapidchannelchangebehaviorcausingthisDOCSIStransactionlogjam,thePCMMarchitectureisnotrecommendedforanIPvideosystem.
In-bandMulticastProtocolSignaling
AnIPmulticastsignalingprotocolsuchasIGMP(forIPv4)orMLDv2(forIPv6)maybeusedbyahomegatewaytodynamicallyJOINandLEAVEIPmulticastgroupsessions.TheDOCSISmulticastsessionestablishmentisinitiatedbythefirsthomegatewaytoJOINthesessionandthemulticastsessionisterminatedsometimeafterthelasthomegatewayhasissuedaLEAVEforthesession.
WhenanIPvideoplayerswitchesTVchannels,thereisagoodpossibilitythatnewTVchannelisavailableviaamulticastsessionaswell.ThisresultsinthehomegatewayissuingaLEAVEfortheoldchannelfollowedbyaJOINforthenewchannel.EachJOINorLEAVEwillresultina3-wayDOCSISMACManagementDynamicBondingChangetransactiontocreate/change/deletetheparametersnecessaryforabondedgroupserviceflow(but,unlikewhatwouldbenecessaryforaunicastflow,thereisnoneedfora3-wayDOCSISMACManagementDynamicServicesAdd/Change/Deletetransaction).ItisnecessaryforthehomegatewaytoalwaysissuetheLEAVEbecausetheCMhasalimitednumberofbondedmulticastDSIDcontexts[seesection:NumberofDownstreamServiceIdentifiers].
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 26
Asmightbeexpected,whentelevisionprogramschangeeveryhalfhour,theremaybelargenumberofprogramchannelchangesencounteredbyanIPvideosystem.Inkind,thiswouldcreateafloodofLEAVEandJOINmulticastsignalingfortheIPvideosystemtoprocess.Worseyet,withtheM-ABRarchitecture,eachtimethatahomegatewayisaskedforaIPvideochunkthatitdoesnothave,itwillissueaunicastHTTPrequesttotheIPvideoserverstoretrievethemissingsegmentfile.ThisactionwillcausetemporarybloomsinunicastIPactivityontheDOCSISandbackbonenetworksuntilthehomegatewaycanstartfillingrequestswithvideosegmentsthathavebeenreceivedoveranIPmulticastgroupsession.Sometechniques(suchastheuseofstaticmulticastforshorttailTVstreams)maybeusedtomitigatethisfloodofsignaling.
NACK-OrientedReliableMulticast(NORM)TheNACK-OrientedReliableMulticast(NORM)wasdevelopedbyUnitedStatesNavalResearchLaboratory(NRL)ProtocolEngineeringAdvancedNetworking(PROTEAN)ResearchGrouptoservemulticastsegmentstogateways.NORMutilizescontent-levelforwarderrorcorrection(FEC)tominimizethepotentialforlossandhastheabilitytoretransmitovermulticastincasemultiplereceiversmissedthesamecontenttransmission-atthecostoflatency.
NORMhasbeenidentifiedbyIPvideoindustryexpertsworkingthruCableLabsastheprotocolofchoicefordeliveryofM-ABRvideo.TheprimaryreasonforthisisthatNORMisextremelyflexible.Forexample,itcanbeutilizedtotransferdatastreamsorfiles,withorwithoutFECandwithjusterrordetectionoralsomulticastretransmission.Operatorswhowantmaximalmulticastefficiencymaywanttoretransmitovermulticastatthecostoflatency,butotheroperatorsmaybewillingtoacceptreducedmulticastefficiencytominimizelatency.
Theoptimalconfigurationmaynotonlyvarybetweenoperators,butmightevenvaryacrossregionswithinthesameoperator.
Seereference3inconjunctionwithreference6formoredetails.
RECOMMENDATIONS-TYINGITALLTOGETHERADOCSISIPvideodistributionsystemshouldbedeployedinsuchawayastomaximizestabilityandefficiencyandminimizelatencyandperturbationstothesystem.Allresourcesshouldbeconfiguredonceasearlyaspossible(ideally,atinitialization)andservicerequestactivitysuchasaTVprogramchannelchangeshould,wheneverandwhereverpossible,notcausethereconfigurationofresources(channelassignments,bondinggroupchanges,etc.)inthesystem.Thesetypesofoperations,whilesupported
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 27
(oratleastnotdisallowed)bytheDOCSISprotocol,canresultinexcessivelatencyandsignificantopportunityforsystemerrorwhenidealconditionsarenotpresent.Furthermore,systemconfigurationshouldleveragetheadvantagesoftheavailabletechnologiesasmuchaspossibletominimizetheresourcesusedtoprovideservicetothesubscriberbase.
Thisoverarchingphilosophyisastrongmotivatorofmanyofthefollowingrecommendations.
CMCapabilitiesTheauthorsrecommendthatonlyCMsandhomegatewaysthatarecapableofreceivingatleasttwenty-four(preferably32)SC-QAMdownstreamchannelsbeusedforIPvideoservice.Thisrecommendation(seeFigure6)isbasedontherelativelylowpenetrationofOFDM-capableCMandhome-gatewaydevicesatthepresenttime(mid-2016).Inaddition,aCMdeviceofthissizeallowsforamulticastIPbondinggroup,anencompassingunicast-ABRbondinggroup,andanencompassinghigh-speeddatabondinggroup.
Figure6:Exampledownstreamchannelassignmentfor32DSdevice
ChannelAssignmenttoCMs
ConsolidateMulticastProgramStreams
WhiletheauthorsdonotrecommendthatCMswithfewerthantwenty-fourSC-QAMdownstreamreceiversbeusedforIPvideoservices,someMSOsmightignorethisrecommendationanduseCMswithasmallernumberofdownstreamreceivers.Similarly,inthefuture,CMsareexpectedtoincreaseincapabilitysotoday’stwenty-fourSC-QAMdownstreamCMsmaybecometheleastcapableCMsinthefuture.Ineithercase,inordertomaximizethemulticastbenefit(andminimizebandwidth)withouthavingtoretuneCMreceiverchannelconfigurationanddownstreambondinggroupconfigurationduringTVchannel-zappingtime,theauthorsrecommendthatallIPvideomulticastgroupsessionsbeconsolidatedontoanumberofDOCSISSC-QAM
IPvideoCM/homegateway
1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
multicastIPvideoDSbonding group
unicastIPvideoDSbonding group
High-speed dataDSbonding group
(OFDM)33
25
26
27
28
29
30
31
32
(OFDM)34
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 28
downstreamchannelsthatis(ideally,much)smallerthanthenumberofdownstreamSC-QAMreceiversoftheleastcapableCMthatwillbeusedforIPvideoservices.Furthermore,abondinggroupforallmulticastsessionscanbecreatedforthisentiresetofchannelstoallowformaximumbandwidthwithminimumlatency.AllCMswhicharetobeusedforIPvideoserviceshouldbeassignedtothissameIPvideodownstreambondinggroup.
Asanexample,(seeFigure1)ifaMSOchoosestouseCMswithsixteen,twenty-four,andthirty-twoSC-QAMreceivers,therecommendationistolimit(bycarefultrafficplanning)thetotalamountofIPvideomulticastsessiontraffictofitinarelativelysmallIPmulticastdownstreambondinggroup(DSBG),inthisexample,eightchannels.Also,bycarefullyapplyingDOCSISQoSparameters(priority,attributebits,etc.),multipleunicastIPvideobondinggroupscanbedefinedwhichincludesthesamechannelsoftheIPvideomulticastbondinggroup.Furthermoremultiplehigh-speeddatabondinggroupscanbedefinedwhichoverlapsalloftheseIPvideobondinggroupsplusanyOFDMchannels(ifavailable).
Figure1:ExampleconfigurationofDSchannelsacrossCMswithdifferentnumbersofreceivers
InFigure1theentireoneandonlymulticastIPvideodownstreambondinggroupisassignedtoallCMswhichareparticipatinginIPVideo.ThenaunicastIPvideobondinggroupisdefinedforeachCMsizewhichusesthechannelsofthemulticastIPvideodownstreambondinggroupaswellasotherdownstreamchannelstocarrythe(lowerpriority)unicastIPvideotraffic.ThiswaytheIPvideounicasttrafficcanuseanyextracapacityleftonthemulticastIPvideodownstreambondinggroupwhilenotimpactingthemulticastIPvideotraffic.Finally,alargeunicastbondinggroupisdefinedforeachCMsizeforotherservices(suchashigh-speeddata)atalowerprioritythanunicastIP
DSRFPort
Rx:16SC-QAM Rx:24SC-QAM Rx:32SC-QAM Rx:32SC-QAM+2OFDM
8channelmulticastIPvideoDSbondinggroup
UnicastIPvideochannels
12SC-QAMDSBG
16SC-QAMDSBG
UnicastHSDchannels
16SC-QAMDSBG
8SC-QAMDSBG
8SC-QAMDSBG
24SC-QAMDSBG
32SC-QAMDSBG
24SC-QAMDSBG
8SC-QAMDSBG
32SC-QAM+
2OFDMDSBG
24SC-QAMDSBG
8SC-QAMDSBG
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 29
videotrafficandtheseservicesmayuseallofthechannelsoftheCMwhilenotimpactingthehigherprioritytraffic.
StaticMulticastforIPvideoDelivery
IfsomenumberoflinearTVstreamscanbeidentifiedthatarenearlyalwaysviewedbyarelativelylargenumberofviewersatanyonetime,thentheseTVstreamsareexcellentcandidatestobecarriedoverstaticallyprovisionedmulticastgroupsviatheuseoftheDOCSISCMTSStaticMulticastSessionEncoding(TLVType64inaCMconfigurationfile).Staticallyconfiguringthesegroupswillhelptoalleviatetheneedformulticast(IGMPorMLD)signaling;therebysavingbandwidth,signalingtime,andlatency.
Forexample,intherealworldobservationexampleofFigure1,alltenofthemostpopularlinearTVstreamsmightbeconfiguredasstaticmulticastjoinsbyusingtheCMTSStaticMulticastSessionEncoding(TLVtype64)intheCMs’configurationfiles.Forthisparticularsystem,doingsomighteliminateupto95%ofthemulticastsignalingthatmayotherwiseoccurwithIPvideochannelchanges.
SignaledMulticastforIPvideoDelivery
IfTVprogramstreampopularityisvolatile,thenanMSOmaychoosetonotincludeitinasetofstaticallyassignedmulticaststreams.However,forprogramstreamswhicharepopularatleastpartofthetime,asignificantbandwidthsavingsintheaccessnetworkcanbeachievedbyallowingtheseprogramstobecarriedasasignaledgroupIPmulticastsession.Thisway,thehomegatewayofeachviewerofaprogramstreamwillsignalwhenthevieweriswatchingthestreamsothatthenetworkresourcesareonlyassignedwhentheyareneeded.Inaddition,singlemulticastIPgroupsessionscanbesharedamongstallviewers’homegateways(whenthereismorethanone)atonce.Itiscertainlypossiblethatallprogramstreamsthatarenotincludedinthesetofstaticallyassignedmulticaststreamscouldusethesignaledmulticastapproachdescribedinthissection.AnMSOmaychoosethisapproachiftheywishtominimizebandwidthutilizationresultingfromIPvideodelivery,becausethesignaledmulticastapproachensuresthatanyprogramstreamviewedbyoneormoreviewerswithinaservicegroupwilltypicallybetransmittedonlyoncewithinthatparticularservicegroup.Alternatively,theMSOcouldchoosetousethesignaledmulticastapproachformedium-tailprograms,andthenusetheunicastapproach(ofthefollowingsection)forlong-tailprograms.
UnicastforIPvideoDelivery
IfaparticularsetofTVprogramstreamsareofthespecialinterestvariety(i.e.notverypopularacrosstheentiresubscriberbase)andonlyviewedbyasmallnumberofviewersatanygiventime,thenanMSOmaychoosetonotincludethespecialty
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 30
programsinthesetofstaticallyassignedmulticaststreamsandalsonotincludetheminthesetofsignaledmulticaststreams.ThisimpliesthatthehomegatewayswillalwayshavetouseunicastABRrequeststoreceivetheseprogramstreams.ThisapproachmaybeappealingtoMSOswhodonotwishtocomplicatetheirnetworkswithallsignaledmulticasting.Theseunicaststreamswouldtypicallybeplannedaspartofthenormalhigh-speeddatachannelsmentionedbelow.
Load-BalanceRemainderofChannels
OncethesetofSC-QAMchannelsthatareneededforshortandmediumtailmulticastIPvideohavebeenallocated,alloftheremainingresourcesshouldbeconsideredunicasthigh-speeddata(HSD)resourcesandmaybeusedforloadbalancingallnon-multicasttraffic(includingunicastABR).Dependingontheconfiguration,thisloadbalancingmaybeperformedatCMregistrationtimeviatheCMTS/CCAPload-balancingmechanisms.
Primarydownstreamassignment
ADOCSIS3.0orlaterCMneedsonlyoneprimarydownstreamchannelbutmaybeassignedmanyprimary-capabledownstreamchannels.BecauseprimarycapabledownstreamchannelscarrymoreDOCSISsignalingoverheadthannon-primarycapabledownstreamchannels,thedownstreamchannelsthatareusedtocarrytheIPmulticastIPvideoprogramstreamsshouldnotbeconfiguredtobeprimarycapable.
Asfortheremaininghigh-speeddata(HSD)channels,unlessthepopulationofpre-3.0DOCSISCMsishigh,onlyasmallhandfulofthesechannelsshouldbeconfiguredtobeprimary-capable.Ideally,ifsetsofchannelsarecreatedasdescribedabove,onlyoneortwochannelsfromeachsetwouldbeconfiguredasprimarycapable.
Upstreamsupervision
Formanyofthesamereasonscitedinsection0aboutprimarycapability,thedownstreamchannelsthatcomprisetheIPmulticastbondinggroupshouldnotbeprovisionedtocarrysupervisionforanyupstreamchannel.
Asfortheremaininghigh-speeddata(HSD)channels,anypre-3.0CMmustbeabletoreceivesupervisionforeveryupstreamchanneltowhichitisassigned.Forthisreason,allsupervisionforupstreamchannelstowhichapre-3.0CMistobeassignedshouldonlybecarriedonprimary-capabledownstreamchannels.SupervisionforupstreamchannelsonwhichonlyDOCSIS3.0orlaterCMsaretobeassignedneednotbecarriedmorethanonceineachdownstreamchannelsetthatisassignedtoaD3.0orlaterCM.
CMUnicastIPVideoServiceFlowQoSParametersModelingandsimulationhasresultedinarecommendationthataunicastDOCSISserviceflowwhichistocarryanadaptivebitrate(unicast)IPvideostreamshouldbe
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 31
constrainedtonolessthantwicethemaximumbitrateofthehighestresolutionversionofthestream.Thismaximumbitratewillaccommodatethemajorityofburstymediatrafficandallowthestreamtorefillvideoplayerjitterbuffersinthefaceofanytransientcableplantnoise.
Downstream
Unicast
AbesteffortdownstreamserviceflowforusebyIPvideounicastserviceshouldbecreatedintheCMconfigurationfilewithaslightlyhigherprioritythanthenormalhigh-speeddataserviceflow.ThisIPvideodownstreamunicastserviceflowshouldhaveamaximumsustainedbitrateequaltoatleasttwicethemaximumbitrateofthehighestresolutionofasinglestreammultipliedbytheintegernumberofunicastprogramstreamstobesimultaneouslyservedtoahousehold(whichwillallbecarriedwithinthatdownstreamunicastserviceflow).
Ahigh-prioritydownstreamclassifiershouldbecreatedintheCMconfigurationfiletoreferencetheIPvideodownstreamunicastserviceflow.TheclassificationfieldspecificsaredifferentfromMSOtoMSOandpossiblyevenfromsystemtosystemwithinthesameMSO.SomeMSOsmaydedicateaTOS/DSCPmarkingtoallunicastIPvideopackets.SomeMSOsmaydefineanexpectedsourcehostorsubnetforallunicastIPvideopackets.TheMSOmustdefinetheclassifiersothattheIPvideounicastpacketscanbeidentifiedandclassifiedbyaDOCSISclassifier.
Multicast
EachIPmulticastgroupofanM-ABRarchitectureisconcernedonlywithtransferringasingleresolutionoftheprogramstreaminquestion.ItisrecommendedthatasinglemulticastprogramstreambeassociatedwithasingleIPmulticastgroup,sothetransferofanumberofmulticastprogramstreamstoaparticularservicegroupwillrequirethatsamenumberofIPmulticastgroupsbetransportedtothatservicegroup.UsingNORM(seesection:NACK-OrientedReliableMulticast(NORM)),theremaybeextradatatransferredintheformofFECtorecovernack’edframes.IfusingproactiveFEC,anIPvideodownstreamNORM-Basedmulticastserviceflowshouldhaveamaximumsustainedbitrateequaltoabout150%ofthemaximumbitrateoftheprogramstreamtoaccountforNORMFECoverhead.TheCableLabsM-ABRdocument[3]recommendsunicastrepairusingHTTPRange-Requests(anHTTPtermforaccessingpiecesofavideochunk)forrepairingmissingvideosegmentdatabeusedinthesmallnumberofcaseswhereproactiveFECcannotcorrectthesegment.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 32
Upstream
AbesteffortupstreamserviceflowforusebyIPvideounicastservicewithaslightlyhigherprioritythanthenormalhigh-speeddataserviceflowshouldbecreatedintheCMconfigurationfile.ThisIPvideoupstreamunicastserviceflowshouldhaveamaximumsustainedbitrateequaltoabout5%ofthemaximumrateofthecorrespondingdownstreamIPvideounicastserviceflow.ThisIPvideounicastserviceflowwillcarryallforwardedHTTPrequestsandallmulticastsignaling.
Ahigh-priorityupstreamclassifiershouldbecreatedintheCMconfigurationfiletoreferencetheIPvideoupstreamunicastserviceflowtohelpensurelow-latencydeliveryofHTTPGETsandmulticastJOINs.ThisclassifierisusedattheCMtodetermineuponwhichflowtosendthesignalingandTCPacknowledgements.Theper-fieldspecificsfortheclassifieraredifferentfromMSOtoMSOandpossiblyevenfromsystemtosystemwithinthesameMSO.SomeMSOsmaydedicateaTOS/DSCPmarkingtoallunicastIPvideopackets.SomeMSOsmaydefineanexpecteddestinationhostorsubnetforallupstreamunicastIPvideopackets.TheMSOmustdefinetheclassifiersothattheIPvideounicastpacketscanbeidentified.
QoSSettingsacrossDifferentServices
TheIPvideomulticaststreamswillbetheprimarytransportforvideotothemajorityofthesubscriberssotheintegrityoftheseserviceflowsisconsideredveryimportant.
Priority5:VoIP
VoiceoverIP(VoIP)traffictendstobealow-bandwidthservicethatisextremelysensitivetobothlatencyandpacketloss.ThedefaultpriorityforPacketCableVoIPservicestendstobeprettyhighataDOCSISpriorityof5.SinceVoIPisaveryhighpriority,VoIPservicesshouldnotnormallybecarriedonDOCSISchannelsthatareusedforIPvideomulticastflows.Ifthisisabsolutelynecessary,thenadmissioncontrolshouldbeusedtoensurethatthesetwohigh-priorityservicesdonotinterferewithoneanother.
Priority3:MulticastIPvideo
TheDOCSIStrafficpriorityofIPvideomulticasttrafficshouldbesuchthatnoothertraffic(perhapswiththeexceptionofVoIP)shouldbehighersothatincasesofcongestiononthesechannels,theIPvideopacketswillalwaysgetthrough.Forthisreason,aDOCSISpriorityof3maybeappropriate.Also,byprioritizingmulticastIPvideoontheDOCSISchannelsthatcarryit,anyexcesscapacityofthesechannelscanbeusedbylowerpriorityserviceswithoutimpactingmulticastIPvideo.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 33
Priority2:SignalingandunicastABRIPvideo
JustbelowtheIPvideomulticastpacketsinpriorityisthesignalingandunicastABRIPvideotraffic.ThedynamicsizingnatureofABRwillallowthevideoservicetoadapttothecongestionthatmightexistinthenetwork.TheseserviceflowsshouldbeprovisionedwithaDOCSISprioritysettingbelowIPvideomulticastserviceflowsandabovenormalHSDserviceflowstokeepthemfromgettingdroppedorqueuedbehindHSDserviceflows.
Priority1:NormalHigh-speedData
ThenormalHSDdataservices(websurfing,etc.)mightbecarriedatadefaultDOCSISpriorityof1.
Priority0:Trafficmanagement“penaltybox”
Finally,someMSOsmayuseaDOCSIStrafficpriorityof0forpurposesofmanagingtrafficforsomeusers.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 34
CONCLUSIONTheDOCSISprotocolusesasharedmediumbutprovidesarichsetoftoolstoensureQualityofService(QoS)toeachsubscriber.ThispaperhasdescribedsomeoftheissuesinusingDOCSIStotransportIPvideo.
Lineartelevisionviewershipcontinuestofollowviewershippatternsthatsuitaone-to-many(broadcastormulticast)transmissionmedium.ThepopularitycurveFigure1showsthatthevastmajorityofsubscriberscanbesatisfiedwitharelativelysmallnumberofprogramstreams.ThisfitsinwellwiththeDOCSISshared-mediumarchitectureifthesystemisconfiguredproperly.Tothisend,theauthorsrecommendaconfigurationwherebyallCMsparticipatingintheIPvideoserviceshareacommonbondinggroupthatisdedicatedtocarryingpopularprogramstreamsinIPmulticastgroups.Thesededicatedchannelsshouldbedesignedtosupportmaximumutilizationtocreatethesmallestpossiblesharedmulticastbondinggrouptogainbandwidthefficiency.
TheDOCSISMACManagementDynamicServicesfacilityisbothpowerfulinitscapabilitiesandcumbersomeinitsrealization.InthenameofbackwardcompatibilitytheDOCSISprotocolcontainsartifactsofhistoricaldevelopmentthathaveledtoincreasedlatencyandtransactionerroropportunitiesduetoserializationofnecessarytransactions.Infact,theeffectsoftheseartifactshavemadethePacketCableMultimediaprotocolineffectiveinhandlingahightransactionrate(suchasmightoccurduringTVchannelzapping)forasinglesubscriberdeviceandthus,PacketCableMultimediaisnotrecommendedasacontrolplanearchitectureforIPvideo.
SomeexamplesofpossibleconfigurationsforaMAC-DomainDownstreamBondinggrouptosupportCMsofdifferingsizesareshownintheAppendixofthisdocument.Thereadermayusetheserecommendationsdirectlyormaytailorthemtosuitanyspecialcircumstancesinherentinaparticulardeployment.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 35
ABBREVIATIONS&DEFINITIONSABR Adaptivebitratebondedserviceflow Aserviceflowwhichistransportedacrossthechannelsofa
bondinggroupbondinggroup AsetofsinglechannelsassociatedwithasingleMACDomain
whichreachesacommonsetofcablemodemsandwhichtransportsatleastonebondedserviceflow
bps BitspersecondCableLabs CableTelevisionLaboratories,Inc.CCAP Convergedcableaccessplatform;adevicethatperformsboth
EQAMandCMTSfunctionalityclassifier AsetofcriteriausedforpacketmatchingaccordingtoTCP,
UDP,IP,LLC,and/or802.1P/Qpacketfields.AclassifiermapseachpackettoasingleServiceFlow.
CM CablemodemCMTS CablemodemterminationsystemDBC DynamicbondingchangeDOCSIS DataovercablesysteminterfacespecificationDS DownstreamDSA DynamicservicesadditionDSBG DownstreambondinggroupDSC DynamicserviceschangeDSD DynamicservicesdeletionDSG DOCSISset-topgatewayDSID DownstreamserviceidentifierDSL DigitalsubscriberlineEQAM Edge-QAM;adevicethatsupportsbroadcastdigitalvideo
and/orswitcheddigitalvideo;and/orvideoondemandFEC ForwarderrorcorrectionFIFO First-in,first-outHFC Hybridfiber-coaxHD Highdefinitionhomegateway ADOCSISappliancethatservesasaunicastHTTPsourceforIP
videocontenttoclientswithinthehomenetworkHz HertzHTTP HypertexttransferprotocolIGMP InternetgroupmanagementprotocolIP InternetProtocol;maydenoteeitherIPv4orIPv6orbothIPv4 InternetProtocol,version4;ThisearlierversionofIPusesa32-
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 36
bitaddressspace,typicallywrittenasfourintegersbetween0and255separatedbydots.IPv4doesnativelysupportIPbroadcastingbutdoesnotnativelysupportamulticastsignalingprotocol
IPv6 InternetProtocol,version6;ThislaterversionofIPusesa128-bitaddressspace,typicallywrittenassequencesofuptofourhexadecimaldigitsandseparatedbycolons.IPv6doesnotsupportIPbroadcastingbutdoesnativelysupportamulticastsignalingprotocol
ISBE InternationalSocietyofBroadbandEngineersjitterbuffer AFIFOmemorybufferusedtostoreacertainamount
(correspondingtoadelayintime)ofmediadatabeforethemediaisusedinreal-time;thisbufferservestoisolatethereal-timeplayerfromthevariancesinreceptiondelay(i.e.Jitter)thatarecommoninpacket-basednetworks
JOIN Asignaledmulticastprotocolcommandtojoinamulticastgroup
linear(TV) Aprogramstreamwherebytheprogramlineuphasbeenpre-scheduledsothatanaudiencemusttuneinataparticulartimetoviewaparticularprogram;alsoknownasappointmentTV
long-tailprogramming Aset(ofnon-determinantsize)ofthespecial-interest(leastpopular)videoprogramstreams;theseprogramstreamsaremorelikelytobeunicasttoeachrequestinguser
LEAVE AsignaledmulticastprotocolrequesttoleaveamulticastgroupM-ABR Multicast-assistedadaptivebitrateMAC MediaaccessMACdomain AlogicalsubcomponentofaCMTSthatprovidesdata
forwardingservicestoasetofCMsoverasetofdownstreamandupstreamchannels
MAP UpstreambandwidthallocationMDD MACdomaindescriptormedium-tailprogramming Aset(ofnon-determinantsize)ofthevideoprogramstreams
thatareneithershort-tailorlong-tailMLD MulticastlistenerdiscoveryMPEG MovingpictureexpertsgroupNORM NACK-orientedreliablemulticastNRL NavalresearchlaboratoryOFDM OrthogonalfrequencydivisionmultiplexingOFDMA OrthogonalfrequencydivisionmultiplexingwithmultipleaccessPCMM PacketCableMultimediaPHY Physicallayer
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 37
PLC PHYlinkchannelofanOFDMdownstreamchannelPROTEAN ProtocolengineeringadvancednetworkingQAM QuadratureamplitudemodulationQoS QualityofserviceRCC ReceivechannelconfigurationRF RadiofrequencySA SecurityassociationSAP ServiceaccesspointSC-QAM Single-channelQAM;atermcoinedduringtheDOCSIS3.1
specificationefforttodenotepre-3.1DOCSISQAMchannelsanddifferentiationthemfromOFDM/OFDMAchannels
SCTE SocietyofCableTelecommunicationsEngineersSDV Switcheddigitalvideosequenced Astreaminwhichpacketsareguaranteedtonotarriveoutof
order(withinsomesequencinginterval)SG Servicegroupshort-tailprogramming Aset(ofnon-determinatesize)ofthemostpopularvideo
programstreams;theseprogramstreamsaremorelikelytobebroadcasttoallusergroups
SID ServiceidentifierSTB Set-topboxTCC TransmitchannelconfigurationTCP TransmissioncontrolprotocolTLV Type,lengthvalue;adatastructureusedtopassoperational
parametersintheDOCSISprotocoltrickmodes Asetoffeaturescommonlyfoundonahomevideoplayerthat
allowaviewertocontrolavideostream;thesefeaturesincludebutarenotlimitedtoplay,pause,rewind,skip,fast-forward,stop,etc.
TV TelevisionUCD UpstreamchanneldescriptorUDP Userdatagramprotocolunbondedserviceflow Aserviceflowinwhichthedataistransportedononlyasingle
channelassociatedwithaMACDomainwhichreachesacommonsetofcablemodems
unsequenced Astreaminwhichpacketsmayarriveinadifferentorderthantheywereoriginallytransmitted
US UpstreamVoIP VoiceoverIP
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 38
RELATEDREADINGS• MigratingtoIPVideooverDOCSIS–TheChallenges,Requirementsand
TechnologiesattheForefrontofChange–Formanyserviceproviders,IPvideoisonthenearhorizon.Butgettingthererequirescarefulplanning.Inthiswhitepaper,CornelCiocirlanoutlinestheneedforaphasedspectrumevolutionplananddiscussesseveralnewtechnologiesthatcanhelpserviceproviderssmooththistransition.
• MethodologiesforQoEMonitoringofIPVideoServices–thispaperdiscussesthedifferencesbetweenQoEandQoSandbetweenQoEandvideoqualityandthencomparesdifferentmethodologiesforvideoqualityandQoEmonitoring.ItalsoincludesareviewofalternativesforembeddingQoEprobesintheend-to-endIPVideoarchitectureandtheirabilitytocollecttrueandeffectiveQoEinformation.
• SmartABR:TheFutureofManagedIPVideoServices–ThispapercomparesindetailtheSABRsystemistotraditionalunmanagedABRdeliveryaswellasasystemwithenhancedCMTSQoS.WithSABR,operatorscansignificantlyincreasetheirIPVideocapacitywhilegracefullyhandlingcongestionandprovidinganimproveduserexperience.
MEETOUREXPERT:WilliamT.HanksBillHanksservesasDirectorofSystemsEngineeringundertheARRISofficeofCTO-Networkswithafocusonbroadbandapplicationsolutions.Mostrecently,BillhasbeenoneoftheARRISrepresentativestotheCableLabsDOCSIS3.1specificationeffortandhaspreviouslybeenontheDOCSIS3.0,DOCSISM-CMTS,DOCSISDSG,PacketCableMultimedia,andPacketCable1.5specificationteams.BillhasbeenwithARRISsincetheCadantacquisitioncirca2002andwaswithbothCadantandMotoroladuringtheprevious15years.BillhassevenissuedpatentswithseveralmorependingandisagraduateoftheUniversityofIllinoisatUrbana-Champaign.
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 39
REFERENCES(1) Kooij,Robertet.al.;“PerceivedQualityofChannelZapping”;ProceedingsoftheFifthLastedInternationalConference;CommunicationSystemsandNetworks;August28-30,2006.https://www.nas.ewi.tudelft.nl/people/Rob/telecom/iasted.pdf
(2) B.Dekeris,L.Narbutaite;“IPvideoChannelZapTimeAnalysis”;ElectronicsandElectricalEngineering.–Kaunas:Technologija;2010.–No.10(106).–P.117–120.http://www.ee.ktu.lt/journal/2010/10/26__ISSN_1392-1215_IPvideo%20Channel%20Zap%20Time%20Analysis.pdf
(3) “VideoIPMulticastIPMulticastAdaptiveBitRateArchitectureTechnicalReport“;OC-TR-IP-MULTI-ARCH-V01-141112;http://www.cablelabs.com/wp-content/uploads/specdocs/OC-TR-IP-MULTI-ARCH-V01-1411121.pdf
(4) White,Gerry;“TopTenReasonsCableNeedsAdaptiveBitRateStreaming”;ARRISblog;June19,2012;http://www.arriseverywhere.com/2012/06/top-ten-reasons-cable-needs-adaptive-bit-rate-streaming/
(5) Allen,Jimet.al.;“ARRISWhitePaper:AchievingHighChannelUtilizationwithDOCSISVideo-over-IP”;October26,2010.
(6) B.Adamson,C.Bormann,M.Handley,J.Macker,“NACK-OrientedReliableMulticast(NORM)TransportProtocol”,IETFRFC5740,November2009.
(7) “Data-Over-CableServiceInterfaceSpecifications:DOCSIS1.0RadioFrequencyInterface(RFI)”;SocietyofCableTelecommunicationsEngineers:DataStandardsSubcommittee;AmericanNationalStandardSCTE22-12012;http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%2022-1%202012.pdf
(8) “Data-Over-CableServiceInterfaceSpecifications:DOCSIS3.0MACandUpperLayerProtocolsInterfaceSpecification”;CM-SP-MULPIv3.1-I08-151210;CableTelevisionLaboratories,Inc.;2006-2015;http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-MULPIv3.1-I08-151210.pdf
(9) “Data-Over-CableServiceInterfaceSpecifications:DOCSIS3.0MACandUpperLayerProtocolsInterfaceSpecification”;CM-SP-MULPIv3.1-I08-151210;CableTelevisionLaboratories,Inc.;2006-2015;http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-MULPIv3.1-I08-151210.pdf
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 40
APPENDIX:SAMPLEIPVIDEOCONFIGURATIONSIneachofthefollowingexamples,theDOCSISMAC-DomainDownstreamServiceGroup(MD-DS-SG)consistsof32SC-QAMdownstreamchannelsandoneOFDMdownstreamchannel.Forpurposesofdrawingease,thechannelsarealldrawnasbeingadjacentbutthisisnotnecessarysolongastheDSchannelsthatareassignedtoeachCMcanbesimultaneouslyreceived(fitwithinthecapturebandwidthwindow)bythatCM.ChannelidentifiersintheseexamplesareconsideredtobelogicalinnatureandtheactualconfiguredDOCSISchannelidentifiersmaybedifferentfromwhatisshownhere.
Allupstreamchannelsupervisionthatisusedbypre-3.0DOCSISCMsissentontheprimary-capableSC-QAMdownstreamchannels.Supervisionforupstreamchannelsthatareusedonlybymulti-channelDOCSISCMsmaybecarriedonthenon-primary-capableSC-QAMdownstreamchannels.SupervisionforupstreamchannelswhichareusedonlybyDOCSIS3.1CMsmaybecarriedontheOFDMDSchannel.
TheDSchannelsareconfiguredwithaMcastIPvideoattribute(whichcanbedesignatedbytheMSOtobeanyoneoftheuser-definedbitsoftheresourceattributemask–seesection:AttributeMaskBitDefinition)ofvalue0or1.DownstreamchannelswithaMcastIPvideovalueof1areforallservices(perhapsexcludingVOIP)includingmulticastIPvideo.DownstreamchannelswithMcastIPvideovalueof0areforservicesotherthanmulticastIPvideo.Iftelephonyflowsaretobesteeredtonon-multicast-IPvideochannelsthenanotherattributemaskbitmaybeusedforthispurposebutthistopicisnotinscopeforthispaper.
Dynamicdownstreamchannelassignmentanddynamicdownstreamchannelbondingisnotusedintheseexamples.EachCMisassignedthelargestbondinggroupthatitcansupportplusanysmallerbondinggroupsthattheMSOwishestoassignfortheservicestobeprovided.Inmanycasestherearemultiplebondinggroupsofthesamesizedepicted.TheCMTS/CCAPshouldbeconfiguredtoloadbalanceacrossbondinggroupsofthesamesize.
MulticasttrafficissteeredtoDSchannelsusingamulticastserviceclasswitharequiredattributemaskthatincludesboththebondingandMcastIPvideoattributesset.Otherservicesonbondedserviceflows(HSD,unicastIPvideo,signalingforservices,etc.)canalsobecarriedonthemulticastDSchannelsbutwillbenaturally“pushed”tonon-multicast-IPvideochannelsbytheCMTS/CCAPbondeddownstreampacketschedulerasthehigherprioritymulticastIPvideotrafficincreases.ThemulticastgroupserviceflowsmusthaveahigherDOCSISpriority(perhaps3)thanothertraffic.UnicastsignalingflowsandunicastABRdataflowswillgetthenexthighestpriority(perhaps2).NormalhighspeeddataflowsshouldgetalowerDOCSISpriority(perhaps1);thussupportinga
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 41
bandwidthpenaltybox(withpriority0)forpolicyenforcementpurposesbyMSOs.TheseprioritieswillnotaffectVOIPflowsattheirdefaultDOCSISprioritysettingof5,thusgivinglow-bandwidthbutlatency-sensitiveVOIPflowspriorityonthenon-multicast-IPvideochannels.
Eachoftheseconfigurationscanbeusedasabaselineandtweakedtosuitspecificsystemneeds.
Minimum32DSChannelCMs/HGsforIPVideoCMtypesparticipatinginallservices(includingIPvideo):
• DOCSIS3.0o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGateways
• DOCSIS3.1o (32SC-QAM+2OFDMDSand8SC-QAM+2OFDMAUS)CMs&Home
GatewaysCMtypesnotparticipatinginIPvideo:
• AllotherCMs&Set-TopBoxes
Figure8:IPvideoconfigurationwithminimum32DSchannelCMs/HGsforIPvideo
Primary-capabledownstreamchannel-idsinthisexampleare7,8,23,and24(morecanbeconfiguredifthepre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheSC-QAMprimary-capabledownstreamchannels.MulticasttrafficiscarriedonmulticastbondinggroupBG14(DSchannels0-5,10-21,and26-31).
ThisarrangementworkswelliftheMSOdesirestomulticastmanytelevisionprogramstreamsatthesametime.Thereisamplecapacityformanymulticaststreamsinthiscase.Meanwhile,allCMswhicharenotparticipatinginIPvideomayusetheunusedcapacityofthechannelswithoutimpactingtheIPvideoservice.
P=Primary Cap DS; N= Non-primary Cap DS; O=OFDM Channel 1 – Attribute for Mcast IPTV; 0 – no Mcast IPTV
BG 11 BG 12
BG 6
03
N
1
02
N
1
04
N
1
05
N
1
06
N
0
07
P
0
08 P
0
09
N
0
11
N
1
10
N
1
12
N
1
13
N
1
14
N
1
15
N
1
16
N
1
17
N
1
19
N
1
18
N
1
20
N
1
21
N
1
22
N
0
23
P
0
24
P
0
25
N
0
27
N
1
26
N
1
28
N
1
29
N
1
30
N
1
31
N
1
32
O, P
0
00
N
1
01
N
1
BG 4
BG 2
BG 1
BG 12
BG 10
BG 3
BG 5
BG 7
BG 13
BG 9BG 8
BG 14 BG 14 BG 14
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 42
Minimum24DSChannelCMs/HGsforIPVideoCMtypesparticipatinginallservices(includingIPvideo):
• DOCSIS3.0o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (24SC-QAMDSand8SC-QAMUS)CMs&HomeGateways
• DOCSIS3.1o (32SC-QAM+2OFDMDSand8SC-QAM+2OFDMAUS)CMs&Home
GatewaysCMtypesnotparticipatinginIPvideo:
• AllotherCMs&Set-TopBoxes
Figure9:IPvideoconfigurationwithminimum24DSchannelCMs/HGsforIPvideo
Primary-capabledownstreamchannel-idsinthisexampleare0,4,24,and28(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels8-23.
ThisarrangementworkswelliftheMSOdesirestomulticastmanytelevisionprogramstreamsatthesametime.Thereisamplecapacityformanystreamsinthiscase.Meanwhile,allCMswhicharenotparticipatinginIPvideomayusetheunusedcapacityofthechannelswithoutimpactingtheIPvideoservice.
Minimum16DSChannelCMs/HGsforIPVideoCMtypesparticipatinginallservices(includingIPvideo):
• DOCSIS3.0
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 43
o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (24SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (16SC-QAMDSand4SC-QAMUS)CMs&HomeGateways
• DOCSIS3.1o (32SC-QAM+2OFDMDSand8SC-QAM+2OFDMAUS)CMs&Home
GatewaysCMtypesnotparticipatinginIPvideo:
• AllotherCMs&Set-TopBoxes
Figure10:IPvideoconfigurationwithminimum16DSchannelCMs/HGsforIPvideo
Primary-capabledownstreamchannel-idsinthisexampleare0,4,16,and24(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels8-15.
Theuseof16DSCMsforIPvideoforcesamoreconstrictivearrangementthanispossiblewhenonlylargerCMsareused.InordertoleaveDSchannelspaceforotherservicesona16DSchannelCM,themulticastbondinggroup–BG15isonlyhalfwhattheexamplefor24channelandupCMscoulduse.ThismayormaynotbesufficientmulticastbandwidthtomeettheIPvideogoalsoftheMSO.Meanwhile,allCMswhicharenotparticipatinginIPvideomayusetheunusedcapacityofthechannelswithoutimpactingtheIPvideoservice.
Minimum8DSChannelCMs/HGsforIPVideoCMtypesparticipatinginallservices(includingIPvideo):
• DOCSIS3.0o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGateways
Copyright2016–ARRISEnterprisesLLC.Allrightsreserved. 44
o (24SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (16SC-QAMDSand4SC-QAMUS)CMs&HomeGatewayso (8SC-QAMDSand4SC-QAMUS)CMs&HomeGateways
• DOCSIS3.1o (32SC-QAM+2OFDMDSand8SC-QAM+2OFDMAUS)CMs&Home
GatewaysCMtypesnotparticipatinginIPvideo:
• AllotherCMs&Set-TopBoxes
Figure11:IPvideoconfigurationwithminimum8DSchannelCMs/HGsforIPvideo
Primary-capabledownstreamchannel-idsinthisexampleare0,8,12,16,20,24,and28(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels4-7.
Thisarrangementworkswellifthenumberof8x4DOCSIS3.0CMsthatparticipateinIPvideoMulticastgroupsisrelativelylowasthe8x4CMswillbeconstrainedtousethefourmulticastchannelspluseitherthefourHSDchannelsimmediatelybelowtheminthespectrumorthefourHSDchannelsimmediatelyabovetheminthespectrum.ThisconstraintisduetothecapturebandwidthconstraintofthesmallerDOCSIS3.0CMs.