configuration recommendations for docsis transport … › globalassets › resources ›...

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


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


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.


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.


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.


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.


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.


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


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


HomeVideoIPGatewayCacheMiss

IfthehomevideoIPgatewaydoesnothavetherequestedABRchunkfile,thenitbehavesverymuchliketheunicastABRcaseandforwardstheHTTPABRrequesttowardsthecachesandserversinthenetworkwhothenprovidethechunkfilebacktothehomevideoIPgateway.ThehomevideoIPgatewaythenforwardsthechunkfiletotheABRvideoclient.

HomeVideoIPGatewayMulticastJOINandCacheHit

WhenahomevideoIPgatewaynoticesthatoneoftheprogramstreamsthatitisservingbecomesavailableviaamulticastgroup,thenitmakesarequesttoJOINthecorrectmulticastgroupatitsgroupaddress.

OncethemulticastgrouppacketsbeginarrivingatthehomevideoIPgateway,itcanstopforwardingunicastABRrequestsintothenetworkandsimplyservetherequestedchunksoutofitsowncachememory.

MulticastController

Themulticastcontroller(runninginaservernorthoftheCCAP)decideswhichprogramstreamsaremadeavailabletothehomevideoIPgatewaysviamulticastanduponwhichgroupaddress.ItpublishesthislisttothehomevideoIPgateways.

HomeEquipmentClarificationThereissometimesanambiguityaboutwhichdeviceinahomeisbeingusedformanagedIPvideo.TheprimaryusecasewouldusehomeequipmentasshowninFigure4buttherearesomemanagedvideosystemsthatdeviatefromthisreferencearchitecture.


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


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


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


• 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


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


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


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)


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


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


• 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


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.


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.


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.


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].


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


(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


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


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


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


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.


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.


Priority2:SignalingandunicastABRIPvideo

JustbelowtheIPvideomulticastpacketsinpriorityisthesignalingandunicastABRIPvideotraffic.ThedynamicsizingnatureofABRwillallowthevideoservicetoadapttothecongestionthatmightexistinthenetwork.TheseserviceflowsshouldbeprovisionedwithaDOCSISprioritysettingbelowIPvideomulticastserviceflowsandabovenormalHSDserviceflowstokeepthemfromgettingdroppedorqueuedbehindHSDserviceflows.

Priority1:NormalHigh-speedData

ThenormalHSDdataservices(websurfing,etc.)mightbecarriedatadefaultDOCSISpriorityof1.

Priority0:Trafficmanagement“penaltybox”

Finally,someMSOsmayuseaDOCSIStrafficpriorityof0forpurposesofmanagingtrafficforsomeusers.


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.


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-


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


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


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.

http://www.arris.com/globalassets/resources/white-papers/arris_ipvideooverdocsis_paper.pdf

http://www.arris.com/globalassets/resources/white-papers/arris_ipvideooverdocsis_paper.pdf

http://www.arris.com/globalassets/resources/white-papers/arris_wp_qoe_monitoring_ip_vid.pdf

http://www.arris.com/globalassets/resources/white-papers/ncta13-smart_abr_future_mnged_video_services.pdf


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


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


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



• DOCSIS3.0o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (24SC-QAMDSand8SC-QAMUS)CMs&HomeGateways





Primary-capabledownstreamchannel-idsinthisexampleare0,4,24,and28(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels8-23.

ThisarrangementworkswelliftheMSOdesirestomulticastmanytelevisionprogramstreamsatthesametime.Thereisamplecapacityformanystreamsinthiscase.Meanwhile,allCMswhicharenotparticipatinginIPvideomayusetheunusedcapacityofthechannelswithoutimpactingtheIPvideoservice.


• DOCSIS3.0


o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (24SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (16SC-QAMDSand4SC-QAMUS)CMs&HomeGateways





Primary-capabledownstreamchannel-idsinthisexampleare0,4,16,and24(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels8-15.

Theuseof16DSCMsforIPvideoforcesamoreconstrictivearrangementthanispossiblewhenonlylargerCMsareused.InordertoleaveDSchannelspaceforotherservicesona16DSchannelCM,themulticastbondinggroup–BG15isonlyhalfwhattheexamplefor24channelandupCMscoulduse.ThismayormaynotbesufficientmulticastbandwidthtomeettheIPvideogoalsoftheMSO.Meanwhile,allCMswhicharenotparticipatinginIPvideomayusetheunusedcapacityofthechannelswithoutimpactingtheIPvideoservice.


• DOCSIS3.0o (32SC-QAMDSand8SC-QAMUS)CMs&HomeGateways


o (24SC-QAMDSand8SC-QAMUS)CMs&HomeGatewayso (16SC-QAMDSand4SC-QAMUS)CMs&HomeGatewayso (8SC-QAMDSand4SC-QAMUS)CMs&HomeGateways





Primary-capabledownstreamchannel-idsinthisexampleare0,8,12,16,20,24,and28(morecanbeconfiguredifpre-3.0CMpopulationpercentageishigh).AllDSGtunnels(ifany)areconfiguredontheprimary-capabledownstreamchannels.MulticasttrafficiscarriedonDSchannels4-7.

Thisarrangementworkswellifthenumberof8x4DOCSIS3.0CMsthatparticipateinIPvideoMulticastgroupsisrelativelylowasthe8x4CMswillbeconstrainedtousethefourmulticastchannelspluseitherthefourHSDchannelsimmediatelybelowtheminthespectrumorthefourHSDchannelsimmediatelyabovetheminthespectrum.ThisconstraintisduetothecapturebandwidthconstraintofthesmallerDOCSIS3.0CMs.

configuration recommendations for docsis transport … › globalassets › resources ›...

Documents