Data-Over-Cable Service Interface Specifications DOCSIS 2.0 Radio Frequency Interface Specification CM-SP-RFIv2.

0-I07-041210

ISSUED SPECIFICATION

Notice
This document is a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry in general. Neither CableLabs nor any member company is responsible for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this specification by any party. This document is furnished on an AS IS basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding its accuracy, completeness, or fitness for a particular purpose. Copyright 1999-2004 Cable Television Laboratories, Inc. All rights reserved.

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Document Status Sheet

Document Control Number: Reference: Revision History:

CM-SP-RFIv2.0-I07-041210 Radio Frequency Interface Specification I01 First Issued Release, December 31, 2001 I02 Second Issued Release, June 17, 2002 I03 Third Issued Release, December 18, 2002 I04 Fourth Issued Release, July 30, 2003 I05 Fifth Issued Release, April 7, 2004 I06 Sixth Issued Release, August 4, 2004 I07 Seventh Issued Release, December 10, 2004

Date: Status Code:

December 10, 2004 Work in Process CableLabs only Draft Issued Closed

Distribution Restrictions:

CL Reviewers

CL Vendor

Public

Key to Document Status Codes

Work in Process: An incomplete document, designed to guide discussion and generate feedback, that may include several alternative requirements for consideration. Draft: A document in specification format considered largely complete, but lacking review by cable industry and vendors. Drafts are susceptible to substantial change during the review process. Issued: A stable document, which has undergone rigorous member and vendor review and is suitable for product design and development, cross-vendor interoperability, and for certification testing. Closed: A static document, reviewed, tested, validated, and closed to further engineering change requests to the specification through CableLabs.

Trademarks:

DOCSIS, eDOCSIS, PacketCable, CableHome, OpenCable, CableCARD, CableOffice , and CableLabs are trademarks of Cable Television Laboratories, Inc.

ii

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table of Contents
1 SCOPE AND PURPOSE.................................................................................................................................1 1.1 SCOPE ................................................................................................................................................................1 1.2 REQUIREMENTS .................................................................................................................................................2 1.3 BACKGROUND ...................................................................................................................................................2 1.3.1 Service Goals ..........................................................................................................................................2 1.3.2 Reference Architecture ...........................................................................................................................3 1.3.3 Categories of Interface Specification .....................................................................................................5 1.3.4 Statement of Compatibility .....................................................................................................................5 1.4 CONVENTIONS FOR THIS SPECIFICATION ...........................................................................................................5 2 3 4 REFERENCES (NORMATIVE/INFORMATIVE) .....................................................................................7 GLOSSARY (INFORMATIVE) ..................................................................................................................11 FUNCTIONAL ASSUMPTIONS.................................................................................................................23

4.1 BROADBAND ACCESS NETWORK ....................................................................................................................23 4.2 EQUIPMENT ASSUMPTIONS ..............................................................................................................................23 4.2.1 Frequency Plan.....................................................................................................................................23 4.2.2 Compatibility with Other Services........................................................................................................24 4.2.3 Fault Isolation Impact on Other Users.................................................................................................24 4.2.4 Cable System Terminal Devices ...........................................................................................................24 4.3 RF CHANNEL ASSUMPTIONS ...........................................................................................................................24 4.3.1 Transmission Downstream ...................................................................................................................24 4.3.2 Transmission Upstream ........................................................................................................................25 4.4 TRANSMISSION LEVELS ...................................................................................................................................26 4.5 FREQUENCY INVERSION ..................................................................................................................................26 5 COMMUNICATION PROTOCOLS ..........................................................................................................27 5.1.1 CM and CMTS as Hosts .......................................................................................................................27 5.1.2 Data Forwarding Through the CM and CMTS ....................................................................................28 5.2 THE MAC FORWARDER ..................................................................................................................................31 5.2.1 Rules for Data-Link-Layer Forwarding ...............................................................................................32 5.3 NETWORK LAYER ............................................................................................................................................32 5.3.1 Requirements for IGMP Management..................................................................................................33 5.4 ABOVE THE NETWORK LAYER ........................................................................................................................35 5.5 DATA LINK LAYER ..........................................................................................................................................35 5.5.1 LLC Sublayer ........................................................................................................................................36 5.5.2 Link-Layer Security Sublayer ...............................................................................................................36 5.5.3 MAC Sublayer.......................................................................................................................................36 5.6 PHYSICAL LAYER ............................................................................................................................................36 5.6.1 Downstream Transmission Convergence Sublayer ..............................................................................36

5.1 PROTOCOL STACK ...........................................................................................................................................27

iii

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

5.6.2 PMD Sublayer...................................................................................................................................... 37 6 PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION .................................................... 39

6.1 SCOPE ............................................................................................................................................................. 39 6.2 UPSTREAM ...................................................................................................................................................... 39 6.2.1 Overview .............................................................................................................................................. 39 6.2.2 Signal Processing Requirements ......................................................................................................... 40 6.2.3 Modulation Formats ............................................................................................................................ 44 6.2.4 R-S Encode........................................................................................................................................... 44 6.2.5 R-S Frame Structure ............................................................................................................................ 45 6.2.6 TDMA Byte Interleaver........................................................................................................................ 47 6.2.7 Scrambler (Randomizer)...................................................................................................................... 50 6.2.8 TCM Encoder....................................................................................................................................... 50 6.2.9 Preamble Prepend ............................................................................................................................... 53 6.2.10 Modulation Rates ............................................................................................................................... 54 6.2.11 S-CDMA Framer and Interleaver...................................................................................................... 54 6.2.12 S-CDMA Framer................................................................................................................................ 61 6.2.13 Symbol Mapping ................................................................................................................................ 64 6.2.14 S-CDMA Spreader ............................................................................................................................. 72 6.2.15 Transmit Pre-Equalizer ..................................................................................................................... 74 6.2.16 Spectral Shaping ................................................................................................................................ 76 6.2.17 Relative Processing Delays ............................................................................................................... 77 6.2.18 Transmit Power Requirements........................................................................................................... 78 6.2.19 Burst Profiles ..................................................................................................................................... 83 6.2.20 Burst Timing Convention ................................................................................................................... 89 6.2.21 Fidelity Requirements ........................................................................................................................ 90 6.2.22 Upstream Demodulator Input Power Characteristics....................................................................... 98 6.2.23 Upstream Electrical Output from the CM ......................................................................................... 98 6.3 DOWNSTREAM ................................................................................................................................................ 99 6.3.1 Downstream Protocol .......................................................................................................................... 99 6.3.2 Scalable Interleaving to Support Low Latency.................................................................................... 99 6.3.3 Downstream Frequency Plan ............................................................................................................ 100 6.3.4 CMTS Output Electrical .................................................................................................................... 100 6.3.5 Downstream Electrical Input to CM.................................................................................................. 101 6.3.6 CM BER Performance ....................................................................................................................... 101 6.3.7 CMTS Timestamp Jitter ..................................................................................................................... 102 6.3.8 CMTS Clock Generation.................................................................................................................... 104 6.3.9 CMTS Downstream Symbol Clock Jitter for Synchronous Operation .............................................. 105 6.3.10 CMTS Downstream Symbol Clock Drift for Synchronous Operation ............................................. 105 7 DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ................................................. 107

7.1 INTRODUCTION ............................................................................................................................................. 107 7.2 MPEG PACKET FORMAT .............................................................................................................................. 107

iv

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

7.3 MPEG HEADER FOR DOCSIS DATA-OVER-CABLE .....................................................................................108 7.4 MPEG PAYLOAD FOR DOCSIS DATA-OVER-CABLE ...................................................................................108 7.4.1 stuff_byte.............................................................................................................................................108 7.4.2 pointer_field........................................................................................................................................108 7.5 INTERACTION WITH THE MAC SUBLAYER ....................................................................................................109 7.6 INTERACTION WITH THE PHYSICAL LAYER ...................................................................................................110 7.7 MPEG HEADER SYNCHRONIZATION AND RECOVERY ..................................................................................110 8 MEDIA ACCESS CONTROL SPECIFICATION ...................................................................................111 8.1.1 Overview .............................................................................................................................................111 8.1.2 Definitions ..........................................................................................................................................111 8.1.3 Future Use ..........................................................................................................................................114 8.2 MAC FRAME FORMATS ................................................................................................................................114 8.2.1 Generic MAC Frame Format .............................................................................................................114 8.2.2 Packet-Based MAC Frames................................................................................................................118 8.2.3 ATM Cell MAC Frames ......................................................................................................................119 8.2.4 Reserved PDU MAC Frames..............................................................................................................119 8.2.5 MAC-Specific Headers .......................................................................................................................120 8.2.6 Extended MAC Headers .....................................................................................................................126 8.2.7 Fragmented MAC Frames ..................................................................................................................130 8.2.8 Error-Handling...................................................................................................................................132 8.3 MAC MANAGEMENT MESSAGES ..................................................................................................................133 8.3.1 MAC Management Message Header ..................................................................................................133 8.3.2 Time Synchronization (SYNC) ............................................................................................................136 8.3.3 Upstream Channel Descriptor (UCD)................................................................................................136 8.3.4 Upstream Bandwidth Allocation Map (MAP) ....................................................................................145 8.3.5 Ranging Request (RNG-REQ) ............................................................................................................147 8.3.6 Ranging Response (RNG-RSP)...........................................................................................................149 8.3.7 Registration Request (REG-REQ) ......................................................................................................154 8.3.8 Registration Response (REG-RSP).....................................................................................................155 8.3.9 Registration Acknowledge (REG-ACK)..............................................................................................158 8.3.10 Upstream Channel Change Request (UCC-REQ)............................................................................160 8.3.11 Upstream Channel Change Response (UCC-RSP) ..........................................................................160 8.3.12 Dynamic Service Addition Request (DSA-REQ) ..........................................................................161 8.3.13 Dynamic Service Addition Response (DSA-RSP) ........................................................................163 8.3.14 Dynamic Service Addition Acknowledge (DSA-ACK) .................................................................165 8.3.15 Dynamic Service Change Request (DSC-REQ) ...........................................................................166 8.3.16 Dynamic Service Change Response (DSC-RSP)..........................................................................167 8.3.17 Dynamic Service Change Acknowledge (DSC-ACK) ..................................................................169 8.3.18 Dynamic Service Deletion Request (DSD-REQ)..........................................................................170 8.3.19 Dynamic Service Deletion Response (DSD-RSP)..........................................................................171 8.3.20 Dynamic Channel Change Request (DCC-REQ) ..........................................................................171

8.1 INTRODUCTION ..............................................................................................................................................111

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.21 Dynamic Channel Change Response (DCC-RSP)........................................................................ 177 8.3.22 Dynamic Channel Change Acknowledge (DCC-ACK)................................................................. 179 8.3.23 Device Class Identification Request (DCI-REQ)............................................................................. 181 8.3.24 Device Class Identification Response (DCI-RSP) ........................................................................... 181 8.3.25 Upstream Transmitter Disable (UP-DIS) MAC Management Message ......................................... 182 8.3.26 Initial Ranging Request (INIT-RNG-REQ)...................................................................................... 184 8.3.27 Test Request (TST-REQ) .................................................................................................................. 185 9 MEDIA ACCESS CONTROL PROTOCOL OPERATION.................................................................. 189 9.1.1 The Allocation MAP MAC Management Message ............................................................................ 190 9.1.2 Information Elements......................................................................................................................... 190 9.1.3 Requests ............................................................................................................................................. 193 9.1.4 Information Element Feature Usage Summary ................................................................................. 194 9.1.5 Map Transmission and Timing .......................................................................................................... 194 9.1.6 Protocol Example .............................................................................................................................. 195 9.1.7 MAP Generation Example - Two Logical Upstreams ....................................................................... 196 9.2 SUPPORT FOR MULTIPLE CHANNELS ............................................................................................................ 197 9.3 TIMING AND SYNCHRONIZATION .................................................................................................................. 197 9.3.1 Global Timing Reference ................................................................................................................... 198 9.3.2 CM Channel Acquisition.................................................................................................................... 198 9.3.3 Ranging .............................................................................................................................................. 199 9.3.4 Timing Units and Relationships......................................................................................................... 200 9.4 UPSTREAM TRANSMISSION AND CONTENTION RESOLUTION ....................................................................... 201 9.4.1 Contention Resolution Overview ....................................................................................................... 202 9.4.2 Transmit Opportunities...................................................................................................................... 203 9.4.3 CM Bandwidth Utilization ................................................................................................................. 204 9.5 DATA LINK ENCRYPTION SUPPORT .............................................................................................................. 204 9.5.1 MAC Messages .................................................................................................................................. 204 9.5.2 Framing ............................................................................................................................................. 204 10 QUALITY OF SERVICE AND FRAGMENTATION.......................................................................... 205 10.1.1 Concepts........................................................................................................................................... 206 10.1.2 Object Model.................................................................................................................................... 210 10.1.3 Service Classes ................................................................................................................................ 211 10.1.4 Authorization ................................................................................................................................... 212 10.1.5 Types of Service Flows .................................................................................................................... 213 10.1.6 Service Flows and Classifiers.......................................................................................................... 215 10.1.7 General Operation ........................................................................................................................... 216 10.2 UPSTREAM SERVICE FLOW SCHEDULING SERVICES .................................................................................. 219 10.2.1 Unsolicited Grant Service................................................................................................................ 220 10.2.2 Real-Time Polling Service ............................................................................................................... 221

9.1 UPSTREAM BANDWIDTH ALLOCATION......................................................................................................... 189

10.1 THEORY OF OPERATION ............................................................................................................................. 205

vi

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10.2.3 Unsolicited Grant Service with Activity Detection...........................................................................221 10.2.4 Non-Real-Time Polling Service ........................................................................................................222 10.2.5 Best Effort Service ............................................................................................................................222 10.2.6 Other Services...................................................................................................................................222 10.2.7 Parameter Applicability for Upstream Service Scheduling..............................................................223 10.2.8 CM Transmit Behavior .....................................................................................................................223 10.3 FRAGMENTATION ........................................................................................................................................224 10.3.1 CM Fragmentation Support..............................................................................................................224 10.3.2 CMTS Fragmentation Support .........................................................................................................227 10.3.3 Fragmentation Example ...................................................................................................................228 10.4 PAYLOAD HEADER SUPPRESSION ................................................................................................................232 10.4.1 Overview ...........................................................................................................................................232 10.4.2 Example Applications .......................................................................................................................233 10.4.3 Operation..........................................................................................................................................233 10.4.4 Signaling ...........................................................................................................................................235 10.4.5 Payload Header Suppression Examples...........................................................................................236 11 CABLE MODEM - CMTS INTERACTION.........................................................................................239

11.1 CMTS INITIALIZATION................................................................................................................................239 11.2 CABLE MODEM INITIALIZATION..................................................................................................................239 11.2.1 Scanning and Synchronization to Downstream................................................................................241 11.2.2 Obtain Upstream Parameters...........................................................................................................242 11.2.3 Message Flows During Scanning and Upstream Parameter Acquisition ........................................245 11.2.4 Ranging and Automatic Adjustments................................................................................................246 11.2.5 Device Class Identification...............................................................................................................250 11.2.6 Establish IP Connectivity .................................................................................................................250 11.2.7 Establish Time of Day.......................................................................................................................251 11.2.8 Transfer Operational Parameters ....................................................................................................252 11.2.9 Registration ......................................................................................................................................253 11.2.10 Baseline Privacy Initialization .......................................................................................................258 11.2.11 Service IDs During CM Initialization.............................................................................................259 11.2.12 Multiple-Channel Support ..............................................................................................................259 11.3 STANDARD OPERATION ...............................................................................................................................259 11.3.1 Periodic Signal Level Adjustment.....................................................................................................259 11.3.2 Changing Upstream Channel Descriptor Message Parameters ......................................................262 11.3.3 Changing Upstream Channels..........................................................................................................263 11.4 DYNAMIC SERVICE ......................................................................................................................................267 11.4.1 Dynamic Service Flow State Transitions..........................................................................................268 11.4.2 Dynamic Service Addition ................................................................................................................276 11.4.3 Dynamic Service Change..................................................................................................................287 11.4.4 Dynamic Service Deletion ................................................................................................................298 11.4.5 Dynamically Changing Downstream and/or Upstream Channels ...................................................304 11.5 FAULT DETECTION AND RECOVERY ...........................................................................................................330

vii

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.5.1 Prevention of Unauthorized Transmissions..................................................................................... 330 12 SUPPORTING FUTURE NEW CABLE MODEM CAPABILITIES................................................. 331

12.1 DOWNLOADING CABLE MODEM OPERATING SOFTWARE .......................................................................... 331 ANNEX A WELL-KNOWN ADDRESSES................................................................................................. 333

A.1 MAC ADDRESSES ........................................................................................................................................ 333 A.2 MAC SERVICE IDS ...................................................................................................................................... 333 A.2.1 All CMs and No CM Service IDs....................................................................................................... 333 A.2.2 Well-Known Multicast Service IDs ................................................................................................... 333 A.2.3 Priority Request Service IDs ............................................................................................................. 334 A.3 MPEG PID .................................................................................................................................................. 334 ANNEX B ANNEX C PARAMETERS AND CONSTANTS........................................................................................ 335 COMMON RADIO FREQUENCY INTERFACE ENCODINGS......................................... 339

C.1 ENCODINGS FOR CONFIGURATION AND MAC-LAYER MESSAGING ............................................................ 339 C.1.1 Configuration File and Registration Settings ................................................................................... 339 C.1.2 Configuration-File-Specific Settings................................................................................................. 352 C.1.3 Registration-Request/Response-Specific Encodings ......................................................................... 357 C.1.4 Dynamic-Service-Message-Specific Encodings ................................................................................ 361 C.2 QUALITY-OF-SERVICE-RELATED ENCODINGS ............................................................................................. 362 C.2.1 Packet Classification Encodings....................................................................................................... 362 C.2.2 Service Flow Encodings .................................................................................................................... 370 C.3 ENCODINGS FOR OTHER INTERFACES .......................................................................................................... 387 C.3.1 Telephone Settings Option ................................................................................................................ 387 C.3.2 Baseline Privacy Configuration Settings Option .............................................................................. 387 C.4 CONFIRMATION CODE .................................................................................................................................. 387 C.4.1 Confirmation Codes for Dynamic Channel Change ......................................................................... 389 C.4.2 Confirmation Codes for Major Errors .............................................................................................. 389 ANNEX D CM CONFIGURATION INTERFACE SPECIFICATION................................................... 391

D.1 CM IP ADDRESSING .................................................................................................................................... 391 D.1.1 DHCP Fields Used by the CM.......................................................................................................... 391 D.2 CM CONFIGURATION ................................................................................................................................... 392 D.2.1 CM Binary Configuration File Format............................................................................................. 392 D.2.2 Configuration File Settings............................................................................................................... 393 D.2.3 Configuration File Creation ............................................................................................................. 394 D.3 CONFIGURATION VERIFICATION .................................................................................................................. 396 D.3.1 CMTS MIC Calculation .................................................................................................................... 396 ANNEX E THE DATA-OVER-CABLE SPANNING TREE PROTOCOL ............................................ 399

E.1 BACKGROUND .............................................................................................................................................. 399 E.2 PUBLIC SPANNING TREE .............................................................................................................................. 399

viii

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

E.3 PUBLIC SPANNING TREE PROTOCOL DETAILS ..............................................................................................400 E.4 SPANNING TREE PARAMETERS AND DEFAULTS ...........................................................................................401 E.4.1 Path Cost ............................................................................................................................................401 E.4.2 Bridge Priority ...................................................................................................................................402 ANNEX F EUROPEAN SPECIFICATION ADDITIONS .........................................................................403

F.1 SCOPE AND PURPOSE ....................................................................................................................................403 F.2 REFERENCES ..................................................................................................................................................403 F.3 GLOSSARY .....................................................................................................................................................403 F.4 FUNCTIONAL ASSUMPTIONS..........................................................................................................................403 F.4.1 Broadband access network.................................................................................................................403 F.4.2 Equipment Assumptions .....................................................................................................................404 F.4.3 RF Channel Assumptions ...................................................................................................................404 F.4.4 Transmission Levels ...........................................................................................................................406 F.4.5 Frequency Inversion...........................................................................................................................406 F.5 COMMUNICATION PROTOCOLS ......................................................................................................................407 F.6 PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION ..........................................................................407 F.6.1 Scope ..................................................................................................................................................407 F.6.2 Upstream ............................................................................................................................................407 F.6.3 Downstream .......................................................................................................................................421 F.7 DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ...........................................................................427 F.7.1 Introduction........................................................................................................................................427 F.7.2 MPEG Packet format .........................................................................................................................428 F.7.3 MPEG Header for Euro-DOCSIS Data-Over-Cable.........................................................................428 F.7.4 MPEG Payload for Euro-DOCSIS Data-Over-Cable .......................................................................428 F.7.5 Interaction with the MAC sublayer ....................................................................................................429 F.7.6 Interaction with the Physical layer ....................................................................................................429 F.7.7 MPEG Header synchronization and recovery ...................................................................................429 F.8 MEDIA ACCESS CONTROL SPECIFICATION ....................................................................................................429 F.8.1 Introduction........................................................................................................................................429 F.8.2 MAC Frame Formats .........................................................................................................................429 F.8.3 MAC Management Messages .............................................................................................................429 ANNEX G DOCSIS 2.0 AND 1.0/1.1 INTEROPERABILITY...................................................................431

G.1 GENERAL INTEROPERABILITY ISSUES ..........................................................................................................431 G.1.1 Provisioning.......................................................................................................................................431 G.1.2 Registration........................................................................................................................................432 G.1.3 Dynamic Service Establishment.........................................................................................................433 G.1.4 Fragmentation ...................................................................................................................................434 G.1.5 Multicast Support...............................................................................................................................434 G.1.6 Changing Upstream Channels...........................................................................................................434 G.2 HYBRID DEVICES ..........................................................................................................................................434 G.3 DOCSIS 2.0 TDMA INTEROPERABILITY .....................................................................................................435

ix

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

G.3.1 Mixed-mode operation with TDMA .................................................................................................. 435 G.3.2 Interoperability & Performance ....................................................................................................... 436 G.4 DOCSIS 2.0 S-CDMA INTEROPERABILITY ................................................................................................ 436 G.4.1 Mixed mode operation with S-CDMA............................................................................................... 436 G.4.2 Interoperability & Performance ....................................................................................................... 436 ANNEX H THE DOCSIS MAC/PHY INTERFACE (DMPI) ................................................................... 437

H.1 SCOPE .......................................................................................................................................................... 437 H.2 CONVENTIONS.............................................................................................................................................. 437 H.2.1 Terminology ...................................................................................................................................... 437 H.2.2 Ordering of Bits and Bytes................................................................................................................ 437 H.2.3 Signal Naming Conventions.............................................................................................................. 437 H.2.4 Active Clock Edge ............................................................................................................................. 437 H.2.5 Timing Specifications........................................................................................................................ 438 H.3 OVERVIEW ................................................................................................................................................... 438 H.3.1 Downstream Data ............................................................................................................................. 441 H.3.2 Upstream Data.................................................................................................................................. 441 H.3.3 Upstream Control ............................................................................................................................. 441 H.3.4 SPI Bus.............................................................................................................................................. 441 H.4 SIGNALS ....................................................................................................................................................... 442 H.4.1 Downstream Data ............................................................................................................................. 442 H.4.2 Upstream Data.................................................................................................................................. 442 H.4.3 Upstream Control ............................................................................................................................. 443 H.4.4 SPI Bus.............................................................................................................................................. 443 H.4.5 Parity................................................................................................................................................. 444 H.4.6 Interrupts........................................................................................................................................... 444 H.5 PROTOCOL ................................................................................................................................................... 445 H.5.1 Downstream Data (ITU-T Recommendations J.83 Annex A) ........................................................... 445 H.5.2 Downstream Data (ITU-T Recommendations J.83 Annex B) ........................................................... 446 H.5.3 Upstream Data.................................................................................................................................. 446 H.5.4 Upstream Control ............................................................................................................................. 447 H.5.5 SPI Bus.............................................................................................................................................. 449 H.6 ELECTRICAL SPECIFICATIONS ...................................................................................................................... 450 H.6.1 DC Specifications.............................................................................................................................. 450 H.7 TIMING SPECIFICATIONS .............................................................................................................................. 451 H.7.1 Downstream Data ............................................................................................................................. 451 H.7.2 Upstream Data.................................................................................................................................. 451 H.7.3 Upstream Control ............................................................................................................................. 451 H.7.4 SPI Bus.............................................................................................................................................. 452 H.8 DATA FORMAT AND USAGE ........................................................................................................................ 452 H.8.1 Downstream Data ............................................................................................................................. 452 H.8.2 Upstream Data.................................................................................................................................. 452 H.8.3 Upstream Control ............................................................................................................................. 458

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.8.4 SPI Bus...............................................................................................................................................460 APPENDIX I MAC SERVICE DEFINITION.............................................................................................461

I.1 MAC SERVICE OVERVIEW .............................................................................................................................461 I.1.1 MAC Service Parameters ....................................................................................................................462 I.2 MAC DATA SERVICE INTERFACE ..................................................................................................................463 I.2.1 MAC_DATA.request............................................................................................................................463 I.2.2 MAC_DATA.indicate...........................................................................................................................464 I.2.3 MAC_GRANT_SYNCHRONIZE.indicate ...........................................................................................464 I.2.4 MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate ..............................................................465 I.3 MAC CONTROL SERVICE INTERFACE ............................................................................................................465 I.3.1 MAC_REGISTRATION_RESPONSE.indicate ....................................................................................465 I.3.2 MAC_CREATE_SERVICE_FLOW.request ........................................................................................465 I.3.3 MAC_CREATE_SERVICE_FLOW.response ......................................................................................466 I.3.4 MAC_CREATE_SERVICE_FLOW.indicate .......................................................................................466 I.3.5 MAC_DELETE_SERVICE_FLOW.request ........................................................................................466 I.3.6 MAC_DELETE_SERVICE_FLOW.response ......................................................................................467 I.3.7 MAC_DELETE_SERVICE_FLOW.indicate .......................................................................................467 I.3.8 MAC_CHANGE_SERVICE_FLOW.request .......................................................................................467 I.3.9 MAC_CHANGE_SERVICE_FLOW.response.....................................................................................467 I.3.10 MAC_CHANGE_SERVICE_FLOW.indicate ....................................................................................468 I.4 MAC SERVICE USAGE SCENARIOS ................................................................................................................468 I.4.1 Transmission of PDUs from Upper Layer Service to MAC DATA Service ........................................468 I.4.2 Reception of PDUs to Upper Layer Service from MAC DATA Service..............................................468 I.4.3 Sample Sequence of MAC Control and MAC Data Services ..............................................................469 APPENDIX II EXAMPLE PREAMBLE SEQUENCE ..............................................................................471

II.1 INTRODUCTION .............................................................................................................................................471 II.2 EXAMPLE PREAMBLE SEQUENCE..................................................................................................................471 APPENDIX III MULTIPLE UPSTREAM CHANNELS ...........................................................................473

III.1 SINGLE DOWNSTREAM AND SINGLE UPSTREAM PER CABLE SEGMENT .....................................................473 III.2 MULTIPLE DOWNSTREAMS AND MULTIPLE UPSTREAMS PER CABLE SEGMENT ........................................475 III.2.1 Topologies.........................................................................................................................................475 III.2.2 Normal Operation.............................................................................................................................477 III.2.3 Initial Ranging ..................................................................................................................................478 III.2.4 Dynamic Channel Change................................................................................................................478 APPENDIX IV DOCSIS TRANSMISSION AND CONTENTION RESOLUTION ...............................479

IV.1 INTRODUCTION ............................................................................................................................................479 IV.2 VARIABLE DEFINITIONS ..............................................................................................................................480 IV.3 STATE EXAMPLES .......................................................................................................................................480 IV.3.1 Idle Waiting for a Packet to Transmit ..........................................................................................480 IV.3.2 Data Ack Pending Waiting for Data Ack only .............................................................................481

xi

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

IV.3.3 Grant Pending Waiting for a Grant ............................................................................................ 481 IV.3.4 Deferring Determine Proper Transmission Timing & Transmit................................................. 481 IV.4 FUNCTION EXAMPLES ................................................................................................................................ 482 IV.4.1 CalcDefer() Determine Defer Amount ........................................................................................ 482 IV.4.2 UtilizeGrant() Determine Best Use of a Grant............................................................................ 482 IV.4.3 Retry() .............................................................................................................................................. 483 APPENDIX V IGMP EXAMPLE ................................................................................................................ 485

V.1 EVENTS ........................................................................................................................................................ 485 V.2 ACTIONS ...................................................................................................................................................... 486 APPENDIX VI UNSOLICITED GRANT SERVICES .............................................................................. 487

VI.1 UNSOLICITED GRANT SERVICE (UGS)....................................................................................................... 487 VI.1.1 Introduction...................................................................................................................................... 487 VI.1.2 Configuration Parameters ............................................................................................................... 487 VI.1.3 Operation ......................................................................................................................................... 487 VI.1.4 Jitter ................................................................................................................................................. 488 VI.1.5 Synchronization Issues ..................................................................................................................... 488 VI.2 UNSOLICITED GRANT SERVICE WITH ACTIVITY DETECTION (UGS-AD) .................................................. 489 VI.2.1 Introduction...................................................................................................................................... 489 VI.2.2 MAC Configuration Parameters ...................................................................................................... 489 VI.2.3 Operation ......................................................................................................................................... 489 VI.2.4 Example............................................................................................................................................ 490 VI.2.5 Talk Spurt Grant Burst..................................................................................................................... 491 VI.2.6 Admission Considerations................................................................................................................ 492 APPENDIX VII S-CDMA FRAMING ........................................................................................................ 493

VII.1 CODED SUBSYMBOL NUMBERING............................................................................................................. 493 VII.2 UNCODED SUBSYMBOL NUMBERING ........................................................................................................ 494 VII.3 FRAMER OUTPUT NUMBERING ................................................................................................................. 494 VII.4 COMMENTS ............................................................................................................................................... 494 APPENDIX VIII AMBIENT TEMPERATURE AND WIND LOADING EFFECTS ........................... 495

VIII.1 SYNCHRONIZATION TOLERANCES TO PLANT DELAY VARIATIONS ......................................................... 495 VIII.2 CHANGE IN PROPAGATION DELAY DUE TO TEMPERATURE CHANGES ................................................... 496 VIII.2.1 Fiber Delay Changes Due to Temperature ................................................................................... 496 VIII.2.2 Coaxial Cable Delay Changes Due to Temperature..................................................................... 497 VIII.2.3 Delay Change Due to Wind........................................................................................................... 497 VIII.3 REFERENCES ............................................................................................................................................ 497 APPENDIX IX APPENDIX X ACKNOWLEDGMENTS .................................................................................................. 499 REVISIONS .......................................................................................................................... 501

X.1 ECNS INCLUDED IN SP-RFIV2.0-I02-020617 ............................................................................................. 501

xii

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

X.2 ECNS INCLUDED IN SP-RFIV2.0-I03-021218..............................................................................................502 X.3 ECNS INCLUDED IN SP-RFIV2.0-I04-030730..............................................................................................503 X.4 ECNS INCLUDED IN SP-RFIV2.0-I05-040407..............................................................................................504 X.5 ECNS INCLUDED IN CM-SP-RFIV2.0-I06-040804 ......................................................................................504 X.6 ECNS INCLUDED IN CM-SP-RFIV2.0-I07-041210 ......................................................................................505

xiii

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

xiv

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

List of Figures
FIGURE 1-1 FIGURE 1-2 FIGURE 5-1 FIGURE 5-2 FIGURE 5-3 FIGURE 5-4 FIGURE 6-1 FIGURE 6-2 FIGURE 6-3 FIGURE 6-4 FIGURE 6-5 FIGURE 6-6 FIGURE 6-7 FIGURE 6-8 FIGURE 6-9 FIGURE 6-10 FIGURE 6-11 FIGURE 6-12 FIGURE 6-13 FIGURE 6-14 FIGURE 6-15 FIGURE 6-16 FIGURE 6-17 FIGURE 6-18 FIGURE 6-19 FIGURE 6-20 FIGURE 6-21 FIGURE 6-22 FIGURE 6-23 FIGURE 6-24 FIGURE 6-25 FIGURE 6-26 FIGURE 6-27 FIGURE 6-28 FIGURE 6-29 FIGURE 6-30 FIGURE 7-1 FIGURE 7-2 FIGURE 7-3 FIGURE 7-4 TRANSPARENT IP TRAFFIC THROUGH THE DATA-OVER-CABLE SYSTEM ..................................2 DATA-OVER-CABLE REFERENCE ARCHITECTURE ......................................................................4 PROTOCOL STACK ON THE RF INTERFACE ................................................................................27 DATA FORWARDING THROUGH THE CM AND CMTS...............................................................28 EXAMPLE CONDITION FOR NETWORK LOOPS ...........................................................................29 MAC FORWARDER ....................................................................................................................31 UPSTREAM SIGNAL-PROCESSING SEQUENCE ..............................................................................41 TDMA UPSTREAM TRANSMISSION PROCESSING ......................................................................42 S-CDMA UPSTREAM TRANSMISSION PROCESSING ..................................................................43 EXAMPLE FRAME STRUCTURES WITH FLEXIBLE BURST LENGTH MODE..................................45 BYTE INTERLEAVER OPERATION ...............................................................................................48 INTERLEAVER OPERATION FOR LAST INTERLEAVER BLOCK (WITH SHORTENED LAST CODEWORD) .......................................................................................48 SCRAMBLER STRUCTURE ...........................................................................................................50 CONVOLUTIONAL ENCODER ......................................................................................................51 REPETITIVE PATTERNS OF BYTE MAPPING TO SYMBOL MAP BITS FOR TCM.............................52 EXAMPLE BYTE TO BIT ASSIGNMENT FOR 64 QAM ..................................................................52 EXAMPLE OF RETURN TO ZERO BITS FOLLOWED BY 0 ...........................................................53 TIMESTAMP SNAPSHOT ..............................................................................................................55 MINI-SLOT MAPPING WITH TWO CODES PER MINI-SLOT, 128 ACTIVE CODES.........................57 MINI-SLOT MAPPING WITH THREE CODES PER MINI-SLOT, 126 ACTIVE CODES......................58 S-CDMA AND SPREADER-OFF INTERVALS ...............................................................................60 SUBFRAME STRUCTURE .............................................................................................................62 SYMBOL NUMBERING WITHOUT TCM......................................................................................64 SYMBOL CONSTELLATIONS .......................................................................................................67 QPSK GRAY AND DIFFERENTIAL SYMBOL MAPPING ...............................................................68 8QAM SYMBOL MAPPING ........................................................................................................68 16QAM SYMBOL MAPPING ......................................................................................................69 32QAM SYMBOL MAPPING ......................................................................................................69 64QAM SYMBOL MAPPING ......................................................................................................70 QPSK AND 8QAM TCM SYMBOL MAPPING ............................................................................70 16QAM AND 32QAM TCM SYMBOL MAPPING.......................................................................71 64QAM AND 128QAM TCM SYMBOL MAPPING.....................................................................71 CODE HOPPING RANDOM NUMBER GENERATOR ......................................................................74 TRANSMIT PRE-EQUALIZER STRUCTURE ...................................................................................75 NOMINAL TDMA BURST TIMING .............................................................................................89 WORST-CASE TDMA BURST TIMING .......................................................................................90 EXAMPLE OF INTERLEAVING MPEG PACKETS IN DOWNSTREAM ..........................................107 FORMAT OF AN MPEG PACKET ..............................................................................................107 PACKET FORMAT WHERE A MAC FRAME IMMEDIATELY FOLLOWS THE POINTER_FIELD .....109 PACKET FORMAT WITH MAC FRAME PRECEDED BY STUFFING BYTES .................................109

xv

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

FIGURE 7-5 FIGURE 7-6 FIGURE 8-1 FIGURE 8-2 FIGURE 8-3 FIGURE 8-4 FIGURE 8-5 FIGURE 8-6 FIGURE 8-7 FIGURE 8-8 FIGURE 8-9 FIGURE 8-10 FIGURE 8-11 FIGURE 8-12 FIGURE 8-13 FIGURE 8-14 FIGURE 8-15 FIGURE 8-16 FIGURE 8-17 FIGURE 8-18 FIGURE 8-19 FIGURE 8-20 FIGURE 8-21 FIGURE 8-22 FIGURE 8-23 FIGURE 8-24 FIGURE 8-25 FIGURE 8-26 FIGURE 8-27 FIGURE 8-28 FIGURE 8-29 FIGURE 8-30 FIGURE 8-31 FIGURE 8-32 FIGURE 8-33 FIGURE 8-34 FIGURE 8-35 FIGURE 8-36 FIGURE 8-37 FIGURE 8-38 FIGURE 8-39 FIGURE 8-40 FIGURE 8-41

PACKET FORMAT SHOWING MULTIPLE MAC FRAMES IN A SINGLE PACKET ....................... 109 PACKET FORMAT WHERE A MAC FRAME SPANS MULTIPLE PACKETS................................. 110 GENERIC MAC FRAME FORMAT ............................................................................................ 114 UPSTREAM MAC/PMD CONVERGENCE ................................................................................. 115 MAC HEADER FORMAT ......................................................................................................... 116 ETHERNET/802.3 PACKET PDU FORMAT ............................................................................... 118 RESERVED PDU FORMAT ....................................................................................................... 120 TIMING MAC HEADER ........................................................................................................... 121 MANAGEMENT MAC HEADER ............................................................................................... 122 REQUEST FRAME FORMAT ...................................................................................................... 123 FRAGMENTATION MAC HEADER FORMAT ............................................................................ 124 CONCATENATION OF MULTIPLE MAC FRAMES ..................................................................... 125 CONCATENATION MAC HEADER FORMAT............................................................................. 125 EXTENDED MAC FORMAT ..................................................................................................... 126 FRAGMENTATION DETAILS ..................................................................................................... 131 MAC HEADER AND MAC MANAGEMENT MESSAGE HEADER FIELDS .................................. 134 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER ............................................... 136 UPSTREAM CHANNEL DESCRIPTOR ........................................................................................ 137 TOP-LEVEL ENCODING FOR BURST DESCRIPTORS ................................................................. 140 EXAMPLE OF UCD ENCODED TLV DATA .............................................................................. 144 MAP FORMAT ........................................................................................................................ 145 MAP INFORMATION ELEMENT STRUCTURE ........................................................................... 146 PACKET PDU FOLLOWING THE TIMING HEADER ................................................................... 148 RANGING RESPONSE ............................................................................................................... 149 GENERALIZED DECISION FEEDBACK EQUALIZATION COEFFICIENTS ..................................... 152 EXAMPLE OF TLV DATA ........................................................................................................ 153 REGISTRATION REQUEST ........................................................................................................ 154 REGISTRATION RESPONSE FORMAT ........................................................................................ 156 REGISTRATION ACKNOWLEDGMENT ...................................................................................... 159 UPSTREAM CHANNEL CHANGE REQUEST ............................................................................... 160 UPSTREAM CHANNEL CHANGE RESPONSE ............................................................................. 161 DYNAMIC SERVICE ADDITION REQUEST ........................................................................... 161 DYNAMIC SERVICE ADDITION RESPONSE ......................................................................... 163 DYNAMIC SERVICE ADDITION ACKNOWLEDGE................................................................. 165 DYNAMIC SERVICE CHANGE REQUEST ............................................................................. 166 DYNAMIC SERVICE CHANGE RESPONSE ............................................................................ 167 DYNAMIC SERVICE CHANGE ACKNOWLEDGE ................................................................... 169 DYNAMIC SERVICE DELETION REQUEST ........................................................................... 170 DYNAMIC SERVICE DELETION RESPONSE ......................................................................... 171 DYNAMIC CHANNEL CHANGE REQUEST ................................................................................ 171 DYNAMIC CHANNEL CHANGE RESPONSE ............................................................................... 178 DYNAMIC CHANNEL CHANGE ACKNOWLEDGE ...................................................................... 180 DEVICE CLASS IDENTIFICATION REQUEST ............................................................................. 181

xvi

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

FIGURE 8-42 FIGURE 8-43 FIGURE 8-44 FIGURE 8-45 FIGURE 9-1 FIGURE 9-2 FIGURE 9-3 FIGURE 10-1 FIGURE 10-2 FIGURE 10-3 FIGURE 10-4 FIGURE 10-5 FIGURE 10-6 FIGURE 10-7 FIGURE 10-8 FIGURE 10-9 FIGURE 10-10 FIGURE 10-11 FIGURE 10-12 FIGURE 10-13 FIGURE 10-14 FIGURE 10-15 FIGURE 11-1 FIGURE 11-2 FIGURE 11-3 FIGURE 11-4 FIGURE 11-5 FIGURE 11-6 FIGURE 11-7 FIGURE 11-8 FIGURE 11-9 FIGURE 11-10 FIGURE 11-11 FIGURE 11-12 FIGURE 11-13 FIGURE 11-14 FIGURE 11-15 FIGURE 11-16 FIGURE 11-17 FIGURE 11-18 FIGURE 11-19 FIGURE 11-20 FIGURE 11-21

DEVICE CLASS IDENTIFICATION RESPONSE ............................................................................182 UP-DIS MESSAGE FORMAT......................................................................................................183 PACKET PDU FOLLOWING THE TIMING HEADER ...................................................................184 TEST REQUEST .........................................................................................................................186 ALLOCATION MAP ...................................................................................................................189 PROTOCOL EXAMPLE ...............................................................................................................195 LOGICAL S-CDMA TDMA CHANNELS ...................................................................................196 PROVISIONED AUTHORIZATION MODEL ENVELOPES...........................................................207 DYNAMIC AUTHORIZATION MODEL ENVELOPES ................................................................208 CLASSIFICATION WITHIN THE MAC LAYER ............................................................................209 THEORY OF OPERATION OBJECT MODEL ................................................................................211 REGISTRATION MESSAGE FLOW ..............................................................................................216 DYNAMIC SERVICE ADDITION MESSAGE FLOW CM INITIATED ........................................218 DYNAMIC SERVICE ADDITION MESSAGE FLOW CMTS INITIATED ...................................219 CM FRAGMENTATION FLOWCHART ........................................................................................226 EXAMPLE OF FRAGMENTING A SINGLE PACKET .....................................................................230 FRAGMENTED CONCATENATED PACKET EXAMPLE ................................................................231 PAYLOAD HEADER SUPPRESSION OPERATION ........................................................................234 PAYLOAD HEADER SUPPRESSION WITH MASKING ..................................................................235 PAYLOAD HEADER SUPPRESSION SIGNALING EXAMPLE ........................................................236 UPSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE .........................................................237 DOWNSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE ...................................................238 CM INITIALIZATION OVERVIEW ..............................................................................................240 SDL NOTATION .......................................................................................................................241 OBTAINING UPSTREAM PARAMETERS .....................................................................................244 MESSAGE FLOWS DURING SCANNING AND UPSTREAM PARAMETER ACQUISITION ...............245 RANGING AND AUTOMATIC ADJUSTMENTS PROCEDURE ........................................................246 INITIAL RANGING - CM...........................................................................................................247 UNICAST INITIAL RANGING - CM ...........................................................................................248 INITIAL RANGING - CMTS ......................................................................................................249 DEVICE CLASS IDENTIFICATION ..............................................................................................250 ESTABLISHING IP CONNECTIVITY ...........................................................................................251 ESTABLISHING TIME OF DAY ..................................................................................................252 REGISTRATION CM.............................................................................................................254 WAIT FOR REGISTRATION RESPONSE CM .........................................................................255 REGISTRATION CMTS ........................................................................................................257 REGISTRATION ACKNOWLEDGMENT CMTS .......................................................................258 PERIODIC RANGING - CMTS ...................................................................................................261 PERIODIC RANGING - CM VIEW ..............................................................................................262 CHANGING UPSTREAM CHANNELS: CMTS VIEW ...................................................................264 CHANGING UPSTREAM CHANNELS: CM VIEW PART 1 ...........................................................265 CHANGING UPSTREAM CHANNELS: CM VIEW PART 2 ...........................................................266 DYNAMIC SERVICE FLOW OVERVIEW .....................................................................................267

xvii

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

FIGURE 11-22 FIGURE 11-23 FIGURE 11-24 FIGURE 11-25 FIGURE 11-26 FIGURE 11-27 FIGURE 11-28 FIGURE 11-29 FIGURE 11-30 FIGURE 11-31 FIGURE 11-32 FIGURE 11-33 FIGURE 11-34 FIGURE 11-35 FIGURE 11-36 FIGURE 11-37 FIGURE 11-38 FIGURE 11-39 FIGURE 11-40 FIGURE 11-41 FIGURE 11-42 FIGURE 11-43 FIGURE 11-44 FIGURE 11-45 FIGURE 11-46 FIGURE 11-47 FIGURE 11-48 FIGURE 11-49 FIGURE 11-50 FIGURE 11-51 FIGURE 11-52 FIGURE 11-53 FIGURE 11-54 FIGURE 11-55 FIGURE 11-56 FIGURE 11-57 FIGURE 11-58 FIGURE 11-59 FIGURE 11-60 FIGURE 11-61

DYNAMIC SERVICE FLOW STATE TRANSITION DIAGRAM ...................................................... 270 DSALOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 271 DSAREMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................ 272 DSCLOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 273 DSCREMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................ 274 DSDLOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 275 DYNAMIC DELETION (DSD) - REMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................................................................................................... 276 DYNAMIC SERVICE ADDITION INITIATED FROM CM ............................................................. 277 DYNAMIC SERVICE ADDITION INITIATED FROM CMTS......................................................... 278 DSALOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 279 DSALOCALLY INITIATED TRANSACTION DSA-RSP PENDING STATE FLOW DIAGRAM ... 280 DSALOCALLY INITIATED TRANSACTION HOLDING STATE FLOW DIAGRAM .................... 281 DSALOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM . 282 DSALOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ................................................................................................................................ 283 DSAREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM....................... 284 DSAREMOTELY INITIATED TRANSACTION DSA-ACK PENDING STATE FLOW DIAGRAM 285 DSAREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 286 DSAREMOTELY INITIATED TRANSACTION DELETING SERVICE STATE FLOW DIAGRAM .. 287 CM-INITIATED DSC ............................................................................................................... 289 CMTS-INITIATED DSC........................................................................................................... 289 DSCLOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 290 DSCLOCALLY INITIATED TRANSACTION DSC-RSP PENDING STATE FLOW DIAGRAM .... 291 DSCLOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ......... 292 DSCLOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM . 293 DSCLOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ................................................................................................................................ 294 DSCREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ....................... 295 DSCREMOTELY INITIATED TRANSACTION DSC-ACK PENDING STATE FLOW DIAGRAM 296 DSCREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 297 DSCREMOTELY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ................................................................................................................................ 298 DYNAMIC SERVICE DELETION INITIATED FROM CM ............................................................. 299 DYNAMIC SERVICE DELETION INITIATED FROM CMTS......................................................... 299 DSDLOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 300 DSDLOCALLY INITIATED TRANSACTION DSD-RSP PENDING STATE FLOW DIAGRAM ... 301 DSDLOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ......... 302 DSDREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM....................... 303 DSDREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 304 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 1............................................... 311 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 2............................................... 312 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 3............................................... 313 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 4............................................... 314

xviii

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

FIGURE 11-62 FIGURE 11-63 FIGURE 11-64 FIGURE 11-65 FIGURE 11-66 FIGURE 11-67 FIGURE 11-68 FIGURE D-1 FIGURE D-2 FIGURE D-3 FIGURE D-4 FIGURE D-5 FIGURE E-1 FIGURE E-2 FIGURE F-1 FIGURE H-1 FIGURE H-2 FIGURE H-3 FIGURE H-4 FIGURE H-5 FIGURE H-6 FIGURE H-7 FIGURE III-1 FIGURE III-2 FIGURE IV-1 FIGURE V-1 FIGURE VI-1 FIGURE VI-2

DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 1 ....................................................315 DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 2 ....................................................316 DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 3 ....................................................317 DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 4 ....................................................318 DCC EXAMPLE OPERATIONAL FLOW .....................................................................................321 EXAMPLE COMBINING NETWORK 1 ........................................................................................327 EXAMPLE COMBINING NETWORK 2 ........................................................................................329 BINARY CONFIGURATION FILE FORMAT .................................................................................393 CREATE TLV ENTRIES FOR PARAMETERS REQUIRED BY THE CM.........................................395 ADD CM MIC .........................................................................................................................395 ADD CMTS MIC.....................................................................................................................395 ADD END OF DATA MARKER ..................................................................................................396 SPANNING TREE TOPOLOGY ....................................................................................................399 SPANNING TREE ACROSS CMTSES .........................................................................................400 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER ................................................430 DMPI APPLICATION ................................................................................................................440 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83 ANNEX A OPERATION .............................................................................................................445 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83 ANNEX B OPERATION..............................................................................................................446 UPSTREAM DATA PROTOCOL ..................................................................................................446 COUNTER SYNCHRONIZATION .................................................................................................447 UPSTREAM CONTROL MESSAGE TRANSFER ............................................................................448 SPI BUS TRANSACTION ...........................................................................................................449 SINGLE DOWNSTREAM AND SINGLE UPSTREAM CHANNELS PER CM ....................................474 MULTIPLE DOWNSTREAM AND MULTIPLE UPSTREAM CHANNELS PER CM...........................476 TRANSMISSION & DEFERENCE STATE TRANSITION DIAGRAM ...............................................479 IGMP SUPPORT CM PASSIVE MODE.....................................................................................485 EXAMPLE JITTER WITH MULTIPLE GRANTS PER SID..............................................................488 VAD START-UP AND STOP .....................................................................................................490

xix

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

xx

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

List of Tables
TABLE 4-1 TABLE 4-2 TABLE 6-1 TABLE 6-2 TABLE 6-3 TABLE 6-4 TABLE 6-5 TABLE 6-6 TABLE 6-7 TABLE 6-8 TABLE 6-9 TABLE 6-10 TABLE 6-11 TABLE 6-12 TABLE 6-13 TABLE 6-14 TABLE 6-15 TABLE 6-16 TABLE 6-17 TABLE 6-18 TABLE 7-1 TABLE 8-1 TABLE 8-2 TABLE 8-3 TABLE 8-4 TABLE 8-5 TABLE 8-6 TABLE 8-7 TABLE 8-8 TABLE 8-9 TABLE 8-10 TABLE 8-11 TABLE 8-12 TABLE 8-13 TABLE 8-14 TABLE 8-15 TABLE 8-16 TABLE 8-17 TABLE 8-18 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1)......25 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1)............26 BURST SIZE ................................................................................................................................46 INTERLEAVER OPERATING PARAMETERS ..................................................................................47 I/Q MAPPING .............................................................................................................................65 DEFINITION OF DIFFERENTIAL QUADRANT CODING .................................................................66 MAXIMUM CHANNEL WIDTH ....................................................................................................76 CONSTELLATION GAINS AND POWER LIMITS ............................................................................78 BURST PROFILE ATTRIBUTES ....................................................................................................84 USER UNIQUE BURST PARAMETERS..........................................................................................85 SPURIOUS EMISSIONS ................................................................................................................92 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST POWER LEVEL ...........................................................................................................................93 SPURIOUS EMISSIONS IN 5 TO 42 MHZ RELATIVE TO THE TRANSMITTED BURST POWER LEVEL ...........................................................................................................................93 FILTER AMPLITUDE DISTORTION...............................................................................................96 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER...............98 ELECTRICAL OUTPUT FROM CM ...............................................................................................99 INTERLEAVER CHARACTERISTICS ..............................................................................................99 CMTS OUTPUT........................................................................................................................100 ELECTRICAL INPUT TO CM .....................................................................................................101 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE CMTS MASTER CLOCK ...........................................................................................................104 MPEG HEADER FORMAT FOR DOCSIS DATA-OVER-CABLE PACKETS .................................108 GENERIC MAC HEADER FORMAT ..........................................................................................117 FC FIELD FORMAT ..................................................................................................................117 PACKET PDU FORMAT ............................................................................................................119 RESERVED PDU FORMAT ........................................................................................................120 MAC-SPECIFIC HEADERS AND FRAMES .................................................................................120 TIMING MAC HEADER FORMAT .............................................................................................121 MAC MANAGEMENT FORMAT ................................................................................................122 REQUEST FRAME (REQ) FORMAT ...........................................................................................123 FRAGMENTATION MAC FRAME (FRAG) FORMAT .................................................................124 CONCATENATED MAC FRAME FORMAT .................................................................................125 EXAMPLE EXTENDED HEADER FORMAT .................................................................................126 EH ELEMENT FORMAT ............................................................................................................127 EXTENDED HEADER TYPES .....................................................................................................127 FRAGMENTATION EXTENDED HEADER FORMAT .....................................................................128 PAYLOAD HEADER SUPPRESSION EHDR SUB-ELEMENT FORMAT .........................................129 UNSOLICITED GRANT SYNCHRONIZATION EHDR SUB-ELEMENT FORMAT ...........................130 MAC MANAGEMENT MESSAGE TYPES ...................................................................................135 CHANNEL TLV PARAMETERS .................................................................................................138
xxi

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

TABLE 8-19 TABLE 8-20 TABLE 8-21 TABLE 8-22 TABLE 9-1 TABLE 9-2 TABLE 9-3 TABLE 9-4 TABLE 10-1 TABLE 10-2 TABLE 10-3 TABLE 10-4 TABLE 10-5 TABLE 11-1 TABLE 11-2 TABLE C-1 TABLE C-2 TABLE C-3 TABLE E-1 TABLE F-1 TABLE F-2 TABLE F-3 TABLE F-4 TABLE F-5 TABLE F-6 TABLE F-7 TABLE F-8 TABLE F-9 TABLE F-10 TABLE F-11 TABLE F-12 TABLE F-13 TABLE F-14 TABLE F-15 TABLE F-16 TABLE F-17 TABLE G-1 TABLE G-2 TABLE H-1 TABLE H-2

UPSTREAM PHYSICAL-LAYER BURST ATTRIBUTES ................................................................ 141 ALLOCATION MAP INFORMATION ELEMENTS (IE)................................................................ 147 RANGING RESPONSE MESSAGE ENCODINGS ..................................................................... 151 CHANNEL TLV PARAMETERS ................................................................................................. 186 IE FEATURE COMPATIBILITY SUMMARY ................................................................................ 194 EXAMPLE RELATING MINI-SLOTS TO TIME TICKS ................................................................. 200 EXAMPLE OF MINI-SLOT CAPACITY IN S-CDMA MODE........................................................ 201 TRANSMIT OPPORTUNITY ....................................................................................................... 203 TFTP FILE CONTENTS ............................................................................................................ 217 REGISTRATION REQUEST CONTENTS ...................................................................................... 217 REGISTRATION RESPONSE CONTENTS .................................................................................... 218 PARAMETER APPLICABILITY FOR UPSTREAM SERVICE SCHEDULING .................................... 223 PAYLOAD HEADER SUPPRESSION DEFINITIONS ...................................................................... 232 FACTORS AFFECTING DCC PERFORMANCE............................................................................. 319 RECOVERY PROCESS ON LOSS OF SPECIFIC MAC MESSAGES ............................................... 330 SAMPLE DOCSIS 1.0 CLASS OF SERVICE ENCODING ............................................................ 342 VALUES USED IN REG-REQ AND REG-RSP MESSAGES ...................................................... 372 VALUES USED IN REG-REQ, REG-RSP, AND DYNAMIC SERVICE MESSAGES .................... 372 CM PATH COST ...................................................................................................................... 401 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS FOR ANALOGUE TV AND SOUND SIGNALS ........................................................................................................ 405 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS ................................. 406 CONSTELLATION GAINS AND POWER LIMITS ......................................................................... 411 BURST PROFILE ATTRIBUTES ................................................................................................. 414 USER UNIQUE BURST PARAMETERS ....................................................................................... 415 SPURIOUS EMISSIONS............................................................................................................. 417 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST POWER LEVEL ..................................................................................................................................... 418 SPURIOUS EMISSIONS IN 5 TO 65 MHZ RELATIVE TO THE TRANSMITTED BURST POWER LEVEL .................................................................................................................................... 418 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER ............ 421 ELECTRICAL OUTPUT FROM CM ............................................................................................ 421 INTERLEAVER CHARACTERISTICS ........................................................................................... 422 CMTS OUTPUT ....................................................................................................................... 423 ELECTRICAL INPUT TO CM ..................................................................................................... 424 256QAM CM BER PERFORMANCE ........................................................................................ 425 QAM MODULATION ............................................................................................................... 425 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE CMTS MASTER CLOCK ......................................................................................................... 427 MPEG HEADER FORMAT FOR EURO-DOCSIS DATA-OVER-CABLE PACKETS ...................... 428 REGISTRATION BEHAVIOR FOR A DOCSIS 2.0 CM ............................................................... 433 HYBRID MODE CONTROLS ..................................................................................................... 435 TIMING PARAMETERS ............................................................................................................. 438 DOWNSTREAM DATA INTERFACE SIGNALS ............................................................................ 442

xxii

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

TABLE H-3 TABLE H-4 TABLE H-5 TABLE H-6 TABLE H-7 TABLE H-8 TABLE H-9 TABLE H-10 TABLE H-11 TABLE H-12 TABLE H-13 TABLE H-14 TABLE H-15 TABLE H-16 TABLE H-17 TABLE H-18 TABLE H-19 TABLE H-20 TABLE H-21 TABLE H-22 TABLE H-23 TABLE H-24 TABLE III-1 TABLE VI-1 TABLE VI-2 TABLE VIII-1 TABLE X-1 TABLE X-2 TABLE X-3 TABLE X-4 TABLE X-5 TABLE X-6

UPSTREAM DATA INTERFACE SIGNALS ...................................................................................442 UPSTREAM CONTROL INTERFACE SIGNALS.............................................................................443 SPI BUS SIGNALS ....................................................................................................................443 TIMESTAMP COUNTER INITIALIZATION OPTIONS ....................................................................447 DC CHARACTERISTICS ............................................................................................................450 DS DATA INTERFACE TIMING .................................................................................................451 US DATA INTERFACE TIMING .................................................................................................451 UPSTREAM CONTROL INTERFACE TIMING ..............................................................................451 SPI BUS TIMING ......................................................................................................................452 UPSTREAM DATA BLOCK FORMAT .........................................................................................452 UPSTREAM DATA BLOCK TYPES .............................................................................................453 FIRST_DATA DATA FORMAT ...............................................................................................453 MIDDLE_DATA DATA FORMAT ...........................................................................................454 LAST_DATA DATA FORMAT ................................................................................................454 PHY_STATUS DATA FORMAT ..............................................................................................454 NO_BURST DATA FORMAT ...................................................................................................455 CHANNEL DATA FORMAT ....................................................................................................455 UPSTREAM CONTROL MESSAGE FORMAT ...............................................................................458 UPSTREAM MESSAGE TYPES ...................................................................................................458 UPSTREAM CONTROL INTERVAL DESCRIPTION PAYLOAD FORMAT ....................................458 UCD CHANGE PAYLOAD FORMAT ......................................................................................459 SPI BUS TRANSACTION FORMAT ............................................................................................460 MAC MESSAGES WITH CHANNEL IDS ....................................................................................477 EXAMPLE REQUEST TO GRANT RESPONSE TIME ....................................................................491 EXAMPLE EXTRA GRANTS FOR NEW TALK SPURTS ...............................................................492 ALLOWABLE PLANT TIMING DRIFT ..........................................................................................495 INCORPORATED ECN TABLE ...................................................................................................501 INCORPORATED ECN TABLE ...................................................................................................502 INCORPORATED ECN TABLE ...................................................................................................503 INCORPORATED ECN TABLE ...................................................................................................504 INCORPORATED ECN TABLE ...................................................................................................504 INCORPORATED ECN TABLE ...................................................................................................505

xxiii

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

xxiv

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Radio Frequency Interface Specification 1 Scope and Purpose

1.1 Scope

This document defines the second generation of radio-frequency interface specifications for high-speed dataover-cable systems. They were developed by Cable Television Laboratories (CableLabs) for the benefit of the cable industry, including contributions by operators and vendors from North America, Europe, and other regions. There are differences in the cable spectrum planning practices adopted for different networks in the world. Therefore two options for physical layer technology are included, which have equal priority and are not required to be inter-operable. One technology option is based on the downstream multi-programme television distribution that is deployed in North America using 6 MHz channelling, and supports upstream transmission in the 5-42 MHz region. The other technology option is based on the corresponding European multi-programme television distribution and supports upstream in the 5-65 MHz region. Both options have the same status, notwithstanding that the document structure does not reflect this equal priority. The first of these options is defined in Sections 4, 6, 7, and Annex G and Annex C.1.1.1, whereas the second is defined by replacing the content of those sections with the content of Annex F. Correspondingly, [ITU-T J.83-B], [NCTA], and [SMS] apply only to the first option, and [EN 300 429] only to the second. Compliance with this document requires compliance with one or other of these implementations, not with both. It is not required that equipment built to one option shall interoperate with equipment built to the other. These optional physical-layer technologies allow operators some flexibility within any frequency planning, EMC and safety requirements that are mandated for their area of operation. For example, the 6 MHz downstreambased option defined by Sections 4, 6, and 7 might be deployable within an 8 MHz channel plan. Compliance with frequency planning and EMC requirements is not covered by this specification and remains the operators responsibility. In this respect, [FCC15], [FCC76], and [EIA-S542] are relevant to North America and [EN 50081-1], [EN 50082-1], [EN 50083-2], [EN 50083-7], and [EN 50083-10] are relevant to the European Community. The option of Sections 4, 6 and 7 together with Annex G and Annex C.1.1.1 is required to be backwards compatible with an earlier version of that technology [DOCSIS9], whereas the option of Annex F was not included in [DOCSIS9] and therefore is not required to be backwards compatible with [DOCSIS9]. Any reference in this document to the transmission of television in the forward channel that is not consistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable in European applications. Requirements for safety are outside the scope of the present document. Safety standards for European applications are published by CENELEC. Note 1: Examples of such CENELEC product safety standards are [EN 60950] and [EN 50083-1]. Note 2: For CENELEC safety categories of interfaces, see [EG 201 212].

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

1.2

Requirements

Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: MUST MUST NOT SHOULD This word or the adjective REQUIRED means that the item is an absolute requirement of this specification. This phrase means that the item is an absolute prohibition of this specification. This word or the adjective RECOMMENDED means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. This word or the adjective OPTIONAL means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

SHOULD NOT

MAY

This document defines many features and parameters, and a valid range for each parameter is usually specified. Equipment (CM and CMTS) requirements are always explicitly stated. Equipment must comply with all mandatory (MUST and MUST NOT) requirements to be considered compliant with this specification. Support of non-mandatory features and parameter values is optional.

1.3

Background

1.3.1 Service Goals As cable operators have widely deployed high-speed data services on cable television systems, the demand for upstream bandwidth has increased, particularly with the popularity of more symmetric data applications. To this end, CableLabs member companies have decided to add advanced modulation techniques to the DOCSIS specification, for the purpose of increasing channel capacity and improving noise immunity. The intended service will allow transparent bi-directional transfer of Internet Protocol (IP) traffic, between the cable system head-end and customer locations, over an all-coaxial or hybrid-fiber/coax (HFC) cable network. This is shown in simplified form in Figure 1-1.

Wide-Area Network CMTS Network Side Interface

Cable Modem Termination System CMTS

Cable Network

Cable Modem (CM)

CM Customer Premises Equipment Interface Customer Premises Equipment

Transparent IP Traffic Through the System

Figure 1-1 Transparent IP Traffic Through the Data-Over-Cable System

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The transmission path over the cable system is realized at the head-end by a Cable Modem Termination System (CMTS), and at each customer location by a Cable Modem (CM). At the head-end (or hub), the interface to the data-over-cable system is called the Cable Modem Termination System - Network-Side Interface (CMTS-NSI) and is specified in [DOCSIS3]. At the customer locations, the interface is called the cable-modem-to-customerpremises-equipment interface (CMCI) and is specified in [DOCSIS4]. The intent is for operators to transparently transfer IP traffic between these interfaces, including but not limited to datagrams, DHCP, ICMP, and IP Group addressing (broadcast and multicast). 1.3.2 Reference Architecture The reference architecture for the data-over-cable services and interfaces is shown in Figure 1-2.
Note: This architecture illustrates the North American frequency plans only and is not normative for European applications. Refer to Section 1.1 for applicability.

CM-SP-RFIv2.0-I07-041210

4
Distribution Hub or Headend
Operations Support System
Copper Pairs, DS1 or DS3

PSTN

Telco Return Access Concentrator (TRAC)

Data Over Cable System OSS Interface, DOCS-OSSI Cable Modem Termination System Downstream RF Interface

Cable Modem Termination System Network Side Interface, CMTS-NSI

Distribution Network
Video 1 Video 2 .

Cable Modem Termination System

50860MHz

O/E Node O/E Node Cable Modem

Coax

Customer Premise Equipment

Com biner

WAN

Generic Headend Switch or Backbone Transport Adapter

Data Mod Network Termination Demod Data . . . Baseline Privacy Interface (BPI) Upstream splitter and filter bank

Tx Rx Fiber O/E Node

Cable Modem to RF Interface, 542MHz Cable Modem to CPE Interface, CMCI Telco return

Backbone Network

Local Server Facility

Security & Access Controller

. Cable Modem Termination System Upstream RF Interface

Data-Over-Cable Service Interface Specifications

Cable Modem Telco Return Interface, CMTRI

WAN

Remote Server Facility

Figure 1-2 Data-Over-Cable Reference Architecture

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

1.3.3 Categories of Interface Specification The basic reference architecture of Figure 1-2 involves five interface categories. Data Interfaces - These are the CMCI [DOCSIS4] and CMTS-NSI [DOCSIS3], corresponding respectively to the cable-modem-to-customer-premises-equipment (CPE) interface (for example, between the customers computer and the cable modem), and the cable modem termination system network-side interface between the cable modem termination system and the data network. Operations Support Systems Interfaces - These are network element management layer interfaces between the network elements and the high-level OSSs (operations support systems) which support the basic business processes, and are documented in [DOCSIS5]. RF Interfaces - The RF interfaces defined in this document are the following:

Between the cable modem and the cable network Between the CMTS and the cable network, in the downstream direction (toward the customer) Between the CMTS and the cable network, in the upstream direction (traffic from the customer)
Security Interfaces - Baseline data-over-cable security is defined in [DOCSIS8]. 1.3.3.1 Data-Over-Cable Service Interface Documents

A list of the documents in the Data-Over-Cable Service Interface Specifications family is provided below. For updates, please refer to http://www.cablemodem.com/.
Designation SP-CMCI SP-CMTS-NSI SP-CMTRI SP-OSSI SP-RFI SP-BPI+ Title Cable Modem to Customer Premises Equipment Interface Specification Cable Modem Termination System Network Side Interface Specification Cable Modem Telco Return Interface Specification Operations Support System Interface Specification Radio Frequency Interface Specification Baseline Privacy Plus Interface Specification

1.3.4 Statement of Compatibility This document specifies an interface, commonly referred to as DOCSIS 2.0, which is the second generation of the interface specified in [DOCSIS9] and [DOCSIS11], commonly referred to as DOCSIS 1.x. DOCSIS 2.0 must be backward- and forward-compatible with equipment built to the previous specifications. DOCSIS 2.0compliant CMs MUST interoperate seamlessly with DOCSIS 1.x CMTSes, albeit in the 1.x mode, as the case may be. DOCSIS 2.0-compliant CMTSes MUST seamlessly support DOCSIS 1.x CMs. Refer to Annex G for further interoperability information.

1.4

Conventions for this Specification

In this specification the following convention applies any time a bit field is displayed in a figure. The bit field should be interpreted by reading the figure from left to right, then from top to bottom, with the MSB being the first bit so read and the LSB being the last bit so read.

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

2 References (normative/informative)
[CableLabs1] Digital Transmission Characterization of Cable Television Systems, Cable Television Laboratories, Inc., November, 1994. [DIX] Ethernet Protocol Version 2.0, Digital, Intel, Xerox, 1982.

[DOCSIS3] Data-Over-Cable Service Interface Specifications, Cable Modem Termination System - Network Side Interface Specification, SP-CMTS-NSI-I01-960702. [DOCSIS4] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premise Equipment Interface Specification, SP-CMCI-I09-030730. [DOCSIS5] Data-Over-Cable Service Interface Specifications, Operations Support System Interface Specification, SP-OSSIv2.0-I07-041210. [DOCSIS6] Data-Over-Cable Service Interface Specifications, Cable Modem Telephony Return Interface Specification, SP-CMTRI-I01-970804. [DOCSIS8] Data-Over-Cable Service Interface Specifications, Baseline Privacy Plus Interface Specification, SP-BPI+-I11-040407. [DOCSIS9] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification, SPRFI-C01-011119. [DOCSIS10] Data-Over-Cable Service Interface Specifications, Baseline Privacy Interface Specification, SPBPI-C01-011119. [DOCSIS11] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification v1.1, SP-RFIv1.1-I10-030730. [DSG] Data-Over-Cable Service Interface Specifications, Set-top Gateway (DSG) Interface Specification, SPDSG-I03-041124.1 [EIA-S542] EIA Standard 542 (1997), Cable Television Channel Identification Plan, May 1997.

[EG 201 212] ETSI EG 201 212: Electrical safety; Classification of interfaces for equipment to be connected to telecommunication networks. Also available from CENELEC as ROBT-002. [EN 300 429] ETSI EN 300 429 V1.2.1: Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for cable systems, April 1998. [EN 50081-1] CENELEC EN 50081-1 Electromagnetic compatibility generic emission standard Part 1: Residential, commercial and light industry. [EN 50082-1] CENELEC EN 50082-1 Electromagnetic compatibility generic immunity standard Part 1: Residential, commercial and light industry. [EN 50083-1] CENELEC EN 50083-1:1993: Cabled distribution systems for television, sound and interactive multimedia signals, Part 1: Safety requirements.

1.

Added this reference per ECN RFIv2.0-N-04.0128-1 by GO on 3/15/04.

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

[EN 50083-2] CENELEC EN 50083-2: 1995 Cabled distribution systems for television, sound and interactive multimedia signals, Part 2: Electromagnetic compatibility for equipment. [EN 50083-7] CENELEC EN 50083-7: Cable networks for television signals, sound signals and interactive services, Part 7: System performance. [EN 50083-10] CENELEC EN 50083-10: Cable networks for television signals, sound signals and interactive services, Part 10: System performance of return paths. [EN 60950] [FCC15] [FCC76] CENELEC EN 60950: Safety of information technology equipment.

Code of Federal Regulations, Title 47, Part 15, October 2000. Code of Federal Regulations, Title 47, Part 76, October 2000.

[ID-IGMP] Fenner W., et al., IGMP-based Multicast Forwarding (IGMP Proxying), IETF Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-00.txt [IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks: Overview and Architecture. IEEE Standard 802.1Q. Virtual Bridged Local Area Networks. December 8, 1998.

[IEEE802.1Q]

[IMA] Internet Assigned Numbers Authority, Internet Multicast Addresses, http://www.iana.org/assignments/multicast-addresses [ISO-169-24] ISO-169-24 F connector, female, indoor

[ISO/IEC8825-1] ISO/IEC 8825-1:2002 (ITU-T X.690) Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).1 [ISO8802-2] ISO/IEC 8802-2: 1994 (IEEE Std 802.2: 1994) - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 2: Logical link control [ISO8802-3] ISO/IEC 8802-3: 1996 (IEEE Std 802.3: 1996) - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical sublayer specifications. [ISO/IEC10038] ISO/IEC 10038 (ANSI/IEEE Std 802.1D): 1993, Information technology Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges. [ISO/IEC10039] ISO/IEC 10039:1991 Information technology Open Systems Interconnection Local area networks Medium Access Control (MAC) service definition. [ITU-T H.222.0] ITU-T Recommendation H.222.0 (2000) and ISO/IEC 13818-1:2000, Information technology - generic coding of moving pictures and associated audio information systems. [ITU-T J.83-B] Annex B to ITU-T Recommendation J.83 (4/97), Digital multi-programme systems for television sound and data services for cable distribution.
1.

Replaced reference per ECN RFI2-N-03077 by GO on 07/03/03.

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

[ITU-T X.25] ITU-T Recommendation X.25 (10/96), Interface between data terminal equipment and data circuit-terminating equipment for terminals operating in the packet mode and connected to public data networks by dedicated circuit. [ITU-T Z.100] (SDL). ITU-T Recommendation Z.100 (11/99) - CCITT Specification and description language

[NCTA] NCTA Recommended Practices for measurement on Cable Television Systems - National Cable Television Association, Washington DC, 2nd Edition, revised October, 1993. [PKT-MGCP] PacketCable Specifications, Network-Based Call Signaling Protocol Specification, PKT-SPEC-MGCP-I10-040402. [PKT-DQOS] 040721. [RFC-791] PacketCable Specifications, Dynamic Quality of Service Specification, PKT-SP-DQOS-I10-

Postel, J., Internet Protocol, IETF RFC-791 (MIL STD 1777), September, 1981.

[RFC-826] Plummer, D., Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48-bit Ethernet address for transmission on Ethernet hardware, November, 1982. [RFC-868] Harrenstien, K., and Postel, J., Time Protocol, IETF RFC-868, May 1983.

[RFC-1042] Postel, J., and Reynolds, J., A Standard for the Transmission of IP Datagrams over IEEE 802 Networks, IETF RFC-1042, February, 1988. [RFC-1058] Hedrick, C., Routing Information Protocol, IETF RFC-1058, June, 1988.

[RFC-1123] Braden, R., Requirements for Internet Hosts Application and Support, IETF RFC-1123, October 1989. [RFC-1157] Schoffstall, M., Fedor, M., Davin, J. and Case, J., A Simple Network Management Protocol (SNMP), IETF RFC-1157, May, 1990. [RFC-1350] Sollings, K., The TFTP Protocol (Revision 2), IETF RFC-1350, July, 1992.

[RFC-1493] Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, & K. McCloghrie. July 1993. (Obsoletes RFC1286) [RFC-1633] Braden, R., Clark, D., and Shenker, S., Integrated Services in the Internet Architecture: An Overview, IETF RFC-1633, June, 1994. [RFC-1812] Baker, F., Requirements for IP Version 4 Routers, IETF RFC-1812. June, 1995.

[RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., HMAC: Keyed-Hashing for Message Authentication, IETF RFC-2104, February, 1997. [RFC-2131] Droms, R., Dynamic Host Configuration Protocol, IETF RFC-2131, March, 1997.

[RFC-2132] Alexander, S., and Droms, R., DHCP Options and BOOTP Vendor Extensions, IETF RFC-2132, March, 1997. [RFC-2210] Wroclawski, J., The Use of RSVP with the IETF Integrated Services, IETF RFC-2210, September, 1997.
9

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

[RFC-2211] Wroclawski, J., Specification of the Controlled-Load Network Element Service, IETF RFC-2211, September, 1997. [RFC-2212] Shenker, S., Partridge, C., and Guerin, R., Specification of Guaranteed Quality of Service, IETF RFC-2212, September, 1997. [RFC-2236] [RFC-2349] May 1998. Fenner, W., Internet Group Management Protocol, Version 2, IETF RFC-2236, November 1997. Malkin, G. and Harkin, A., TFTP Timeout Interval and Transfer Size Options, IETF RFC-2349,

[RFC-2669] St. Johns, M., DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems, IETF RFC-2669, August 1999. [RFC-2786] St. Johns, M., Diffie-Helman [sic] USM Key Management Information Base and Textual Convention, IETF RFC-2786, March, 2000. [RFC-3046] Patrick, M., DHCP Relay Agent Information Option, IETF RFC-3046, January, 2001.

[RFC-3256] Jones, D. & Woundy, R., The DOCSIS Device Class DHCP Relay Agent Information Suboption, IETF RFC-3256, April 2002.1 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

[SMS] The Spectrum Management Application (SMA) and the Common Spectrum Management Interface (csmi), Time Warner Cable, December 24, 1995.

1.

Added reference per ECN RFI2-N-03063 by GO on 07/03/03.

10

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

3 Glossary (informative)
Active Service Flow An admitted Service Flow from the CM to the CMTS which is available for packet transmission. Address Resolution Protocol (ARP) Ethernet addresses. A protocol of the IETF for converting network addresses to 48-bit

Admitted Service Flow A Service Flow, either provisioned or dynamically signaled, which is authorized and for which resources have been reserved but is not active. Allocation A group of contiguous mini-slots in a MAP which constitute a single transmit opportunity. A US standards body.

American National Standards Institute (ANSI) ANSI ARP See American National Standards Institute. See Address Resolution Protocol.

Asynchronous Transfer Mode (ATM) uniform 53-byte cells. ATM

A protocol for the transmission of a variety of digital signals using

See Asynchronous Transfer Mode. DOCSIS 2.0 TDMA mode (as distinguished from DOCSIS 1.x TDMA).

A-TDMA

Authorization Module The authorization module is an abstract module that the CMTS can contact to authorize Service Flows and Classifiers. The authorization module tells the CMTS whether the requesting CM is authorized for the resources it is requesting. Availability In cable television systems, availability is the long-term ratio of the actual RF channel operation time to scheduled RF channel operation time (expressed as a percent value) and is based on a bit error rate (BER) assumption. Bandwidth Allocation Map opportunities to CMs. BPDU The MAC Management Message that the CMTS uses to allocate transmission

See Bridge Protocol Data Unit. Spanning tree protocol messages as defined in [ISO/IEC10038].

Bridge Protocol Data Unit (BDU) Broadcast Addresses points. Burst

A predefined destination address that denotes the set of all data network service access

A single continuous RF signal from the upstream transmitter, from transmitter on to transmitter off. Any Errored Second containing at least 100 errors.

Burst Error Second

Cable Modem (CM) A modulator-demodulator at subscriber locations intended for use in conveying data communications on a cable television system.

11

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Cable Modem Termination System (CMTS) Cable modem termination system, located at the cable television system head-end or distribution hub, which provides complementary functionality to the cable modems to enable data connectivity to a wide-area network. Cable Modem Termination System - Network Side Interface (CMTS-NSI) [DOCSIS3], between a CMTS and the equipment on its network side. Cable Modem to CPE Interface (CMCI) The interface, defined in

The interface, defined in [DOCSIS4], between a CM and CPE.

Carrier Hum Modulation The peak-to-peak magnitude of the amplitude distortion relative to the RF carrier signal level due to the fundamental and low-order harmonics of the power-supply frequency. Carrier-to-Noise Ratio (C/N or CNR) The ratio of signal power to noise power in the defined measurement bandwidth. For digital modulation, CNR = Es/N0, the energy-per-symbol to noise-density ratio; the signal power is measured in the occupied bandwidth, and the noise power is normalized to the modulation-rate bandwidth. For video, the measurement bandwidth is 4 MHz. CCCM CPE Controlled Cable Modem. Refer to the DOCSIS Cable Modem to Customer Premise Equipment Interface (CMCI) specification. Channel The frequency spectrum occupied by a signal. Usually specified by center frequency and bandwidth parameters. Chip Each of the 128 bits comprising the S-CDMA spreading codes. The time to transmit one chip of the S-CDMA spreading code. The inverse of the chip rate.

Chip Duration

Chip Rate The rate at which individual chips of the S-CDMA spreading codes are transmitted. (1280 to 5120 kHz) Classifier A set of criteria used for packet matching according to TCP, UDP, IP, LLC, and/or 802.1P/Q packet fields. A classifier maps each packet to a Service Flow. A Downstream Classifier is used by the CMTS to assign packets to downstream service flows. An Upstream Classifier is used by the CM to assign packets to upstream service flows. CM See Cable Modem. See Cable Modem to CPE Interface. See Cable Modem Termination System.

CMCI CMTS

CMTS-NSI See Cable Modem Termination System - Network Side Interface. Code Hopping Matrix A shifted version of the reference code matrix (see below) that is used when code hopping is employed to vary the codes used by each CM. The Code Hopping Matrix is either 128 rows by 128 columns (when all 128 codes are active) or is 127 rows by 128 columns (when less than 128 codes are active in the S-CDMA spreader-on frame). When less than 128 codes are active, Code 0 (all ones) is deleted from the matrix, but all remaining codes are still cycled through even if less than 127 codes are active in a frame. Composite Second Order Beat (CSO) The peak of the average level of distortion products due to secondorder non-linearities in cable system equipment. Composite Triple Beat (CTB) The peak of the average level of distortion components due to third-order nonlinearities in cable system equipment.
12

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CPE

See Customer Premises Equipment.

Cross-Modulation A form of television signal distortion where modulation from one or more television channels is imposed on another channel or channels. Customer See End User.

Customer Premises Equipment (CPE) Equipment at the end users premises; MAY be provided by the end user or the service provider. Data Link Layer Layer 2 in the Open System Interconnection (OSI) architecture; the layer that provides services to transfer data over the transmission link between open systems. DCC DHCP Dynamic Channel Change. See Dynamic Host Configuration Protocol.

Distribution Hub A location in a cable television network which performs the functions of a head-end for customers in its immediate area, and which receives some or all of its television program material from a Master Head-end in the same metropolitan or regional area. DOCSIS Data-Over-Cable Service Interface Specifications. DOCSIS 1.x Downstream Abbreviation for DOCSIS 1.0 or 1.1. In cable television, the direction of transmission from the head-end to the subscriber.

Drop Cable Coaxial cable that connects to a residence or service location from a directional coupler (tap) on the nearest coaxial feeder cable. Dynamic Host Configuration Protocol (DHCP) addresses. An Internet protocol used for assigning network-layer (IP)

Dynamic Range The ratio between the greatest signal power that can be transmitted over a multichannel analog transmission system without exceeding distortion or other performance limits, and the least signal power that can be utilized without exceeding noise, error rate or other performance limits. ECN ECO ECR See Engineering Change Notice. See Engineering Change Order. See Engineering Change Request. A voluntary body of manufacturers which, among other activities,

Electronic Industries Association (EIA) prepares and publishes standards.

End User A human being, organization, or telecommunications system that accesses the network in order to communicate via the services provided by the network. Engineering Change Notice The final step in the procedure to change specifications.

Engineering Change Order The second step in the procedure to change specifications. DOCSIS posts ECO to web site EC table and ECO page (with indication of ECO Comment Deadline). DOCSIS issues ECO announcement to DOCSIS-announce and working group mail lists (with indication of ECO Comment Deadline).
13

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Engineering Change Request The first step in the procedure to change specifications. DOCSIS issues ECR number, posts to web site EC table and ECR page. DOCSIS sends ECR to subject area working group mail list (and author). Errored Second Any 1-sec interval containing at least one bit error.

Extended Subsplit A frequency division scheme that allows bidirectional traffic on a single coaxial cable. Reverse path signals come to the head-end from 5 to 42 MHz. Forward path signals go from the head-end from 50 or 54 MHz to the upper frequency limit. FDDI See Fiber Distributed Data Interface.

Feeder Cable Coaxial cables that run along streets within the served area and connect between the individual taps which serve the customer drops. Fiber Distributed Data Interface (FDDI) Fiber Node A fiber-based LAN standard.

A point of interface between a fiber trunk and the coaxial distribution. The direction of RF signal flow away from the head-end toward the end user; equivalent to

Forward Channel Downstream. Frame

See MAC frame, S-CDMA frame, and MPEG frame.

Group Delay The difference in transmission time between the highest and lowest of several frequencies through a device, circuit or system. Guard Band Minimum time allocated between bursts in the upstream referenced from the symbol center of the last symbol of a burst to the symbol center of the first symbol of the following burst. The guard band should be at least the duration of five symbols plus the maximum system timing error. Guard Time The term guard time is similar to the guard band, except that it is measured from the end of the last symbol of one burst to the beginning of the first symbol of the preamble of an immediately following burst. Thus, the guard time is equal to the guard band 1.1 Harmonic Related Carrier (HRC) A method of spacing television channels on a cable television system in exact 6-MHz increments, with all carrier frequencies harmonically related to a common reference. Head-end The central location on the cable network that is responsible for injecting broadcast video and other signals in the downstream direction. See also Master Head-End, Distribution Hub. Header HFC Protocol control information located at the beginning of a protocol data unit.

See Hybrid Fiber/Coax (HFC) System.

High Frequency (HF) Used in this document to refer to the entire subsplit (5-30 MHz) and extended subsplit (5-42 MHz) band used in reverse channel communications over the cable television network. High Return A frequency division scheme that allows bi-directional traffic on a single coaxial cable. Reverse channel signals propagate to the head-end above the downstream passband.

1.

Guard Time entry revised, Guard Band entry added per RFI2-N-02085 by RKV on 10/28/02.

14

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Hum Modulation Undesired modulation of the television visual carrier by the fundamental or low-order harmonics of the power supply frequency, or other low-frequency disturbances. Hybrid Fiber/Coax (HFC) System A broadband bidirectional shared-media transmission system using fiber trunks between the head-end and the fiber nodes, and coaxial distribution from the fiber nodes to the customer locations. ICMP IE See Internet Control Message Protocol.

See Information Element. See Institute of Electrical and Electronic Engineers. See Internet Engineering Task Force. See Internet Group Management Protocol.

IEEE IETF IGMP

Incremental Related Carriers (IRC) A method of spacing NTSC television channels on a cable television system in which all channels except 5 and 6 correspond to the standard channel plan, used to reduce composite triple beat distortions. Institute of Electrical and Electronic Engineers (IEEE) A voluntary organization which, among other things, sponsors standards committees and is accredited by the American National Standards Institute. International Electrotechnical Commission (IEC) An international standards body. An international standards body, commonly known

International Organization for Standardization (ISO) as the International Standards Organization. Internet Control Message Protocol (ICMP)

An Internet network-layer protocol.

Internet Engineering Task Force (IETF) A body responsible, among other things, for developing standards used in the Internet. Internet Group Management Protocol (IGMP) the Internet A network-layer protocol for managing multicast groups on

Impulse Noise Noise characterized by non-overlapping transient disturbances. Information Element Internet Protocol (IP) Interval Usage Code IP IUC The fields that make up a MAP and define individual grants, deferred grants, etc. An Internet network-layer protocol. A field in MAPs and UCDs to link burst profiles to grants.

See Internet Protocol. See Interval Usage Code. The time, expressed in quantity of symbols, taken for a signal element to pass through a device.

Latency

Layer A subdivision of the Open System Interconnection (OSI) architecture, constituted by subsystems of the same rank

15

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Link Layer LLC

See Data Link Layer.

See Logical Link Control (LLC) procedure.

Local Area Network (LAN) A non-public data network in which serial transmission is used for direct data communication among data stations located on the users premises. Logical Link Control (LLC) procedure In a local area network (LAN) or a Metropolitan Area Network (MAN), that part of the protocol that governs the assembling of data link layer frames and their exchange between data stations, independent of how the transmission medium is shared. Logical (Upstream) Channel A MAC entity identified by a unique channel ID and for which bandwidth is allocated by an associated MAP message. A physical upstream channel may support multiple logical upstream channels. The associated UCD and MAP messages completely describe the logical channel. MAC See Media Access Control (MAC) procedure. MAC header plus optional PDU. An attachment to a MAC-sublayer domain. Refer to Sections 5.2 and 8.1.2.2.

MAC Frame

MAC Service Access Point MAP

See Bandwidth Allocation Map.

Master Head-End A head-end which collects television program material from various sources by satellite, microwave, fiber and other means, and distributes this material to Distribution Hubs in the same metropolitan or regional area. A Master Head-End MAY also perform the functions of a Distribution Hub for customers in its own immediate area. Mean Time to Repair (MTTR) In cable television systems, the MTTR is the average elapsed time from the moment a loss of RF channel operation is detected up to the moment the RF channel operation is fully restored. Media Access Control (MAC) address medium. The built-in hardware address of a device connected to a shared

Media Access Control (MAC) procedure In a subnetwork, that part of the protocol that governs access to the transmission medium independent of the physical characteristics of the medium, but taking into account the topological aspects of the subnetworks, in order to enable the exchange of data between nodes. MAC procedures include framing, error protection, and acquiring the right to use the underlying transmission medium. Media Access Control (MAC) sublayer The part of the data link layer that supports topology-dependent functions and uses the services of the Physical Layer to provide services to the logical link control (LLC) sublayer. Micro-reflections Echoes in the forward transmission path due to departures from ideal amplitude and phase characteristics. Mid Split A frequency division scheme that allows bi-directional traffic on a single coaxial cable. Reverse channel signals propagate to the head-end from 5 to 108 MHz. Forward path signals go from the head-end from 162 MHz to the upper frequency limit. The diplex crossover band is located from 108 to 162 MHz. Mini-Slot A mini-slot is an integer multiple of 6.25-microsecond increments. The relationship between mini-slots, bytes and time ticks is described in Section 9.3.4.

16

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Modulation Rate The signaling rate of the upstream modulator (1280 to 5120 kHz). In S-CDMA, the chip rate. In TDMA, the channel symbol rate. Moving Picture Experts Group (MPEG) moving pictures and associated audio. MPEG MSAP A voluntary body which develops standards for digital compressed

See Moving Picture Experts Group. See MAC Service Access Point. User access in which more than one terminal equipment is supported by a single network

Multipoint Access termination.

Multipoint Connection A connection among more than two data network terminations. NACO Network Access Control Object.

National Cable Television Association (NCTA) A voluntary association of cable television operators which, among other things, provides guidance on measurements and objectives for cable television systems in the USA. National Television Systems Committee (NTSC) broadcast standard used today in North America. Committee which defined the analog color television

Network Layer Layer 3 in the Open Systems Interconnection (OSI) architecture; the layer that provides services to establish a path between open systems. Network Management The functions related to the management of data link layer and physical layer resources and their stations across the data network supported by the hybrid fiber/coax system. Number Of Allocated Codes The total number of codes which a single CM uses in a single S-CDMA frame. This number is determined by the size of the grants in minislots and the mapping of these minislots to S-CDMA frames (note that a CM may receive multiple grants which are mapped to a single S-CDMA frame). The number of allocated codes can be in the range of the number of Codes per Mini-slot to the number of active codes, and may vary from frame to frame, but is constant within an S-CDMA frame. Open Systems Interconnection (OSI) A framework of ISO standards for communication between different systems made by different vendors, in which the communications process is organized into seven different categories that are placed in a layered sequence based on their relationship to the user. Each layer uses the layer immediately below it and provides a service to the layer above. Layers 7 through 4 deal with end-to-end communication between the message source and destination, and layers 3 through 1 deal with network functions. Organizationally Unique Identifier (OUI) A 3-octet IEEE assigned identifier that can be used to generate Universal LAN MAC addresses and Protocol Identifiers per ANSI/IEEE Std 802 for use in Local and Metropolitan Area Network applications. OSI OUI See Open Systems Interconnection. See Organization Unique Identifier.

Packet Identifier (PID) A unique integer value used to identify elementary streams of a program in a singleor multi-program MPEG-2 stream. Partial Grant A grant that is smaller than the corresponding bandwidth request from the CM.

17

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Payload Header Suppression The suppression of the header in a payload packet. (e.g., the suppression of the Ethernet header in forwarded packets) Payload Unit Start Indicator (PUSI) A flag in an MPEG header. A value of 1 indicates the presence of a pointer field as the first byte of the payload. PHS PHY See Payload Header Suppression. See Physical (PHY) Layer.

Physical (PHY) Layer Layer 1 in the Open System Interconnection (OSI) architecture; the layer that provides services to transmit bits or groups of bits over a transmission link between open systems and which entails electrical, mechanical and handshaking procedures. Physical Media Dependent (PMD) Sublayer A sublayer of the Physical Layer which is concerned with transmitting bits or groups of bits over particular types of transmission link between open systems and which entails electrical, mechanical and handshaking procedures. PID PMD See Packet Identifier. See Physical Media Dependent (PMD) Sublayer.

Primary Service Flow All CMs have a Primary Upstream Service Flow and a Primary Downstream Service Flow. They ensure that the CM is always manageable and they provide a default path for forwarded packets that are not classified to any other Service Flow Program-Specific Information (PSI) In MPEG-2, normative data necessary for the demultiplexing of Transport Streams and the successful regeneration of programs. Program Stream In MPEG-2, a multiplex of variable-length digital video and audio packets from one or more program sources having a common time-base. Protocol A set of rules and formats that determines the communication behavior of layer entities in the performance of the layer functions. Provisioned Service Flow A Service Flow that has been provisioned as part of the Registration process, but has not yet been activated or admitted. It may still require an authorization exchange with a policy module or external policy server prior to admission. PSI QAM See Program-Specific Information. See Quadrature Amplitude Modulation.

QoS Parameter Set The set of Service Flow Encodings that describe the Quality of Service attributes of a Service Flow or a Service Class. (Refer to Annex C.2.2.5) QPSK See Quadrature Phase-Shift Keying.

Quadrature Amplitude Modulation (QAM) A method of modulating digital signals onto a radio-frequency carrier signal involving both amplitude and phase coding. Quadrature Phase-Shift Keying (QPSK) A method of modulating digital signals onto a radio-frequency carrier signal using four phase states to code two digital bits.

18

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Radio Frequency (RF) 1000 MHz.

In cable television systems, this refers to electromagnetic signals in the range 5 to

Reference Code Matrix A 128-by-128 element matrix formed by stacking successive spreading codes on top of each other, i.e., the bottom row of the reference code matrix is Code 0 (all ones) and the top row is Code 127. The code elements are placed in the matrix from right to left, i.e., the right-most column of the code matrix is the first element of each code, and the left-most column is the last element of each code. Request For Comments (RFC) A technical policy document of the IETF; these documents can be accessed on the World Wide Web at http://www.rfc-editor.org/. Return Loss The parameter describing the attenuation of a guided wave signal (e.g., via a coaxial cable) returned to a source by a device or medium resulting from reflections of the signal generated by the source. Reverse Channel Upstream. RFC The direction of signal flow towards the head-end, away from the subscriber; equivalent to

See Request for Comments. A protocol of the IETF for exchanging routing information about IP

Routing Information Protocol (RIP) networks and subnets. SAID

See Security Association Identifier.

S-CDMA Frame A two dimensional representation of mini-slots, where the dimensions are codes and time. An S-CDMA frame is composed of p active codes in the code dimension and K spreading intervals in the time dimension. Within the S-CDMA frame, the number of mini-slots is determined by the number of codes per minislot (c) and p, the number of active codes in the S-CDMA frame. Each S-CDMA frame thus contains s minislots, where s=p/c, and each mini-slot contains c*K information (QAM) symbols. S-CDMA Subframe A subframe is a vertically-smaller subset of an S-CDMA frame over which interleaving is performed, where the vertical dimension is R' codes, where R' p (the number of active codes). A subframe is generally used to constrain the interleaving region to be of a similar size to the Reed-Solomon codeword in order to provide protection from impulse noise. Security Association Identifier Service Access Point (SAP) immediately above it. A Baseline Privacy security identifier between a CMTS and a CM.

The point at which services are provided by one layer, or sublayer to the layer

Service Class A set of queuing and scheduling attributes that is named and that is configured at the CMTS. A Service Class is identified by a Service Class Name. A Service Class has an associated QoS Parameter Set. Service Class Name An ASCII string by which a Service Class may be referenced in modem configuration files and protocol exchanges. Service Data Unit (SDU) Information that is delivered as a unit between peer service access points Service Flow A MAC-layer transport service which:

Provides unidirectional transport of packets from the upper layer service entity to the RF; Shapes, polices, and prioritizes traffic according to QoS traffic parameters defined for the Flow.
Service Flow Identifier (SFID) An identifier assigned to a service flow by the CMTS. [32 bits]
19

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Service Flow Reference A message parameter in Configuration Files and Dynamic Service MAC messages used to associate Classifiers and other objects in the message with the Service Flow Encodings of a requested Service Flow. Service Identifier (SID) A Service Flow Identifier assigned by the CMTS (in addition to a Service Flow Identifier) to an Active or Admitted Upstream Service Flow. [14 bits] SID See Service Identifier. A network management protocol of the IETF.

Simple Network Management Protocol (SNMP) SMS See Spectrum Management System. SNAP SNMP See Subnetwork Access Protocol.

See Simple Network Management Protocol. A system, defined in [SMS], for managing the RF cable spectrum.

Spectrum Management System (SMS)

Spread Symbol Or Spreading Interval At the output of the spreader, a group of 128 chips which comprise a single S-CDMA spreading code, and are the result of spreading a single information (QAM) symbol. One spread symbol = one spreading interval = 128 chips = one information (QAM) symbol. Spreader-Off S-CDMA Burst A transmission from a single CM in a spreader-off frame on an S-CDMA channel defined by the time in which the CMs transmitter turns on to the time it turns off. There will generally be several spreader off bursts in a spreader-off frame. Spreader-Off S-CDMA Frame TDMA mini-slots on an S-CDMA channel in which the spreader is turned off. These are differentiated from TDMA bursts on a TDMA channel in that, for example, the number of minislots per spreader-off SCDMA burst frame is constrained to be the same as the number of mini-slots in a spreader-on SCDMA frame (s). This number of mini-slots will be less than the number of TDMA mini-slots in a TDMA channel over the same time interval if the number of active codes is significantly less than 128. Spreading Interval Time to transmit a single complete S-CDMA spreading code, equal to the time to transmit 128 chips. Also, time to transmit a single information (QAM) symbol on an S-CDMA channel. See also Spread Symbol. Sub-Channel A logical channel sharing same upstream spectrum (RF center frequency and RF channel) with other logical channels. Sublayer A subdivision of a layer in the Open System Interconnection (OSI) reference model. Subnetworks are physically formed by connecting adjacent nodes with transmission links. An extension of the LLC header to accommodate the use of 802-type

Subnetwork

Subnetwork Access Protocol (SNAP) networks as IP networks. Subscriber See End User.

Subsplit A frequency-division scheme that allows bi-directional traffic on a single cable. Reverse path signals come to the head-end from 5 to 30 (up to 42 on Extended Subsplit systems) MHz. Forward path signals go from the head-end from 50 or 54 MHz to the upper frequency limit of the cable network.

20

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Subsystem An element in a hierarchical division of an Open System that interacts directly with elements in the next higher division or the next lower division of that open system. System Clock Period The period of the 10.24 MHz system clock, nominally 97.65625 ns.

Systems Management Functions in the application layer related to the management of various open systems Interconnection (OSI) resources and their status across all layers of the OSI architecture. TFTP See Trivial File-Transfer Protocol.

Tick 6.25-microsecond time intervals that are the reference for upstream mini-slot definition and upstream transmission times. Tilt Maximum difference in transmission gain of a cable television system over a given bandwidth (typically the entire forward operating frequency range). TLV See Type/Length/Value.

Transit Delay The time difference between the instant at which the first bit of a PDU crosses one designated boundary, and the instant at which the last bit of the same PDU crosses a second designated boundary. Transmission Control Protocol (TCP) A transport-layer Internet protocol which ensures successful end-toend delivery of data packets without error. Transmission Convergence Sublayer A sublayer of the Physical Layer that provides an interface between the Data Link Layer and the PMD Sublayer. Transmission Link adjacent nodes. The physical unit of a subnetwork that provides the transmission connection between

Transmission Medium The material on which information signals may be carried; e.g., optical fiber, coaxial cable, and twisted-wire pairs. Transmission System transfer bits. The interface and transmission medium through which peer physical layer entities

Transmit On/Off Ratio In multiple-access systems, the ratio between the signal powers sent to line when transmitting and when not transmitting. Transport Stream In MPEG-2, a packet-based method of multiplexing one or more digital video and audio streams having one or more independent time bases into a single stream. Trivial File-Transfer Protocol (TFTP) An Internet protocol for transferring files without the requirement for user names and passwords that is typically used for automatic downloads of data and software. Trunk Cable Cables that carry the signal from the head-end to groups of subscribers. The cables can be either coaxial or fiber depending on the design of the system. Type/Length/Value (TLV) An encoding of three fields, in which the first field indicates the type of element, the second the length of the element, and the third field the value.

21

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

UCC

Upstream Channel Change The direction from the subscriber location toward the head-end.

Upstream

Upstream Channel Descriptor (UCD) The MAC Management Message used to communicate the characteristics of the upstream physical layer to the cable modems.

22

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

4 Functional Assumptions
This section describes the characteristics of cable television plant to be assumed for the purpose of operating a data-over-cable system. It is not a description of CMTS or CM parameters. The data-over-cable system MUST be interoperable within the environment described in this section. This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option, refer to Annex F. Whenever any reference in this section to frequency plans or compatibility with other services conflicts with any legal requirement for the area of operation, the latter shall take precedence. Any reference to NTSC analogue signals in 6 MHz channels does not imply that such signals are physically present.

4.1

Broadband Access Network

A coaxial-based broadband access network is assumed. This may take the form of either an all-coax or hybridfiber/coax (HFC) network. The generic term cable network is used here to cover all cases. A cable network uses a shared-medium, tree-and-branch architecture with analog transmission. The key functional characteristics assumed in this document are the following:

Two-way transmission. A maximum optical/electrical spacing between the CMTS and the most distant CM of 100 miles in each
direction, although typical maximum separation may be 10-15 miles.

A maximum differential optical/electrical spacing between the CMTS and the closest and most distant
modems of 100 miles in each direction, although this would typically be limited to 15 miles.1 At a propagation velocity in fiber of approximately 1.5 ns/ft, 100 miles of fiber in each direction results in a round-trip delay of approximately 1.6 ms. For further information, see VIII.2

4.2

Equipment Assumptions

4.2.1 Frequency Plan In the downstream direction, the cable system is assumed to have a passband with a lower edge between 50 and 54 MHz and an upper edge that is implementation-dependent but is typically in the range of 300 to 864 MHz. Within that passband, NTSC analog television signals in 6-MHz channels are assumed to be present on the standard, HRC or IRC frequency plans of [EIA-S542], as well as other narrowband and wideband digital signals. In the upstream direction, the cable system may have a subsplit (5-30 MHz) or extended subsplit (5-40 or 5-42 MHz) passband. NTSC analog television signals in 6-MHz channels may be present, as well as other signals.

1. 2.

Phrase in each direction added to second and third bulleted items per RFI2-N-02104 by RKV on 10/28/02. Section 4.1, last paragraph added per RFI2-N-02104 by RKV on 10/28/02.

23

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

4.2.2 Compatibility with Other Services The CM and CMTS MUST coexist with the other services on the cable network. In particular, a) They MUST be interoperable in the cable spectrum assigned for CMTS-CM interoperation while the balance of the cable spectrum is occupied by any combination of television and other signals; and

b) They MUST NOT cause harmful interference to any other services that are assigned to the cable network in spectrum outside of that allocated to the CMTS. The latter is understood as

No measurable degradation (highest level of compatibility), No degradation below the perceptible level of impairments for all services (standard or medium level of compatibility), or

No degradation below the minimal standards accepted by the industry (for example, FCC for analog video
services) or other service provider (minimal level of compatibility). 4.2.3 Fault Isolation Impact on Other Users As the data-over-cable system is a shared-media, point-to-multipoint system, fault-isolation procedures should take into account the potential harmful impact of faults and fault-isolation procedures on numerous users of the data-over-cable and other services. For the interpretation of harmful impact, see Section 4.2.2 above. 4.2.4 Cable System Terminal Devices The CM MUST meet and SHOULD exceed all applicable regulations for Cable System Termination Devices and Cable Ready Consumer Equipment as defined in FCC Part 15 [FCC15] and Part 76 [FCC76]. None of these specific requirements may be used to relax any of the specifications contained elsewhere within this document.

4.3

RF Channel Assumptions

The data-over-cable system, configured with at least one set of defined physical-layer parameters (e.g., modulation, forward error correction, modulation rate, etc.) from the range of configuration settings described in this specification, MUST be interoperable on cable networks having characteristics defined in this section in such a manner that the forward error correction provides for equivalent operation in a cable system both with and without the impaired channel characteristics described below. 4.3.1 Transmission Downstream The RF channel transmission characteristics of the cable network in the downstream direction are described in Table 4-1. These numbers assume total average power of a digital signal in a 6-MHz channel bandwidth for carrier levels unless indicated otherwise. For impairment levels, the numbers in Table 4-1 assume average power in a bandwidth in which the impairment levels are measured in a standard manner for cable TV system. For analog signal levels, the numbers in Table 4-1 assume peak envelope power in a 6-MHz channel bandwidth. All conditions are present concurrently. No combination of the following parameters will exceed any stated interface limit defined elsewhere in this specification.

24

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 4-1 Assumed Downstream RF Channel Transmission Characteristics (see note 1)

Parameter Frequency range Value Cable system normal downstream operating range is from 50 MHz to as high as 860 MHz. However, the values in this table apply only at frequencies >= 88 MHz. 6 MHz <= 0.800 msec (typically much less) Not less than 35 dB (see note 2,3) Not less than 41 dB (see note 2,3) Not less than 41 dB (see note 2,3) Not less than 41 dB (see note 2,3) Not less than 41 dB (see note 2,3) 3 dB within the design bandwidth (see note 2) 75 ns within the design bandwidth (see note 2) -20 dBc @ <= 1.5 sec, -30 dBc @ > 1.5 sec -10 dBc @ <= 0.5 sec, -15 dBc @ <= 1.0 sec (see note 2) Not greater than -26 dBc (5%) (see note 2) Not longer than 25 sec at a 10 Hz average rate (see note 2) 17 dBmV 121

RF channel spacing (design bandwidth) Transit delay from head-end to most distant customer Carrier-to-noise ratio in a 6-MHz band Carrier-to-Composite triple beat distortion ratio Carrier-to-Composite second order distortion ratio Carrier-to-Cross-modulation ratio Carrier-to-any other discrete interference (ingress) Amplitude ripple Group delay ripple in the spectrum occupied by the CMTS Micro-reflections bound for dominant echo

Carrier hum modulation Burst noise Maximum analog video carrier level at the CM input Maximum number of analog carriers Notes to Table 4-1: 1. 2. 3.

Transmission is from the head-end combiner to the CM input at the customer location. Measurement methods defined in [NCTA] or [CableLabs1]. Measured relative to a QAM signal that is equal to the nominal video level in the plant.

4.3.2 Transmission Upstream The RF channel transmission characteristics of the cable network in the upstream direction are described in Table 4-2. All conditions are present concurrently. No combination of the following parameters will exceed any stated interface limit defined elsewhere in this specification.

25

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table 4-2 Assumed Upstream RF Channel Transmission Characteristics (see note 1)

Parameter Frequency range Transit delay from the most distant CM to the nearest CM or CMTS Carrier-to-interference plus ingress (the sum of noise, distortion, common-path distortion and cross-modulation and the sum of discrete and broadband ingress signals, impulse noise excluded) ratio Carrier hum modulation Burst noise Amplitude ripple 5-42 MHz: Group delay ripple 5-42 MHz: Micro-reflections single echo Value 5 to 42 MHz edge to edge <= 0.800 msec (typically much less) Not less than 25 dB (Note 2)

Not greater than -23 dBc (7.0%) Not longer than 10 sec at a 1 kHz average rate for most cases (Notes 3 and 4) 0.5 dB/MHz 200 ns/MHz -10 dBc @ <= 0.5 sec -20 dBc @ <= 1.0 sec -30 dBc @ > 1.0 sec Not greater than 14 dB min to max

Seasonal and diurnal reverse gain (loss) variation Notes to Table 4-2: 1. 2. 3. 4.

Transmission is from the CM output at the customer location to the head-end. Ingress avoidance or tolerance techniques may be used to ensure operation in the presence of time-varying discrete ingress signals that could be as high as 10 dBc. The ratios are guaranteed only within the digital carrier channels. Amplitude and frequency characteristics sufficiently strong to partially or wholly mask the data carrier. Impulse noise levels more prevalent at lower frequencies (< 15 MHz).

4.3.2.1

Availability

Typical cable network availability is considerably greater than 99%.

4.4

Transmission Levels

The nominal power level of the downstream CMTS signal(s) within a 6-MHz channel is targeted to be in the range -10 dBc to -6 dBc relative to analog video carrier level and will normally not exceed analog video carrier level. The nominal power level of the upstream CM signal(s) will be as low as possible to achieve the required margin above noise and interference. Uniform power loading per unit bandwidth is commonly followed in setting upstream signal levels, with specific levels established by the cable network operator to achieve the required carrier-to-noise and carrier-to-interference ratios.

4.5

Frequency Inversion

There will be no frequency inversion in the transmission path in either the downstream or upstream directions, i.e., a positive change in frequency at the input to the cable network will result in a positive change in frequency at the output.

26

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

5 Communication Protocols
This section provides a high-level overview of the communication protocols that must be used in the data-overcable system. Detailed specifications for the physical media dependent, downstream transmission, and media access control sublayers are provided in Section 6, Section 7, and Section 8, respectively.

5.1

Protocol Stack

The CM and CMTS operate as forwarding agents and also as end-systems (hosts). The protocol stacks used in these modes differ as shown below. The principal function of the cable modem system is to transmit Internet Protocol (IP) packets transparently between the head-end and the subscriber location. Certain management functions also ride on IP, so that the protocol stack on the cable network is as shown in Figure 5-1 (this does not restrict the generality of IP transparency between the head-end and the customer). These management functions include, for example, supporting spectrum management functions and the downloading of software. 5.1.1 CM and CMTS as Hosts CMs and CMTSes operate as IP and LLC hosts in terms of IEEE Standard 802 [IEEE802] for communication over the cable network. The protocol stack at the CM and CMTS RF interfaces is shown in Figure 5-1.

SNMP

TFTP

DHCP

UDP

IP, ICMP

ARP

LLC/DIX

Link Security

MAC

Transmission Convergence (Downstream Only)

PMD

Figure 5-1 Protocol Stack on the RF Interface

27

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM and CMTS MUST function as IP hosts. As such, the CM and CMTS MUST support IP and ARP over DIX link-layer framing (see [DIX]). The CMTS MUST NOT transmit frames that are smaller than the DIX 64 byte minimum on a downstream channel.1 However, the CM MAY transmit frames that are smaller than the DIX 64 byte minimum on an upstream channel. The CM and CMTS MAY also support IP and ARP over SNAP framing [RFC-1042]. The CM and CMTS also MUST function as LLC hosts. As such, the CM and CMTS MUST respond appropriately to TEST and XID requests per [ISO8802-2]. 5.1.2 Data Forwarding Through the CM and CMTS 5.1.2.1 General

Data forwarding through the CMTS MAY be transparent bridging,2 or MAY employ network-layer forwarding (routing, IP switching) as shown in Figure 5-2. Data forwarding through the CM is link-layer transparent bridging, as shown in Figure 5-2. Forwarding rules are similar to [ISO/IEC10038] with the modifications described in Section 5.1.2.2 and Section 5.1.2.3. This allows the support of multiple network layers.

CMTS Stack IP Forwarding 802.2/DIX LLC Data Link Layer Link Security Cable MAC
DS TC Upstrm Layer Cable Cable PMD PMD

CM Stack IP 802.2/DIX LLC Transparent Bridging Link Security Cable MAC

DS TC Upstrm Layer Cable Cable PMD PMD

802.2/DIX LLC 802.3/DIX MAC 802.3 10Base-T

PHY Layer

CMTS-NSI Interface to/from Network Equipment

Cable Network Transmission

CMCI Interface to/from Customer Premises Equipment

Figure 5-2

Data Forwarding Through the CM and CMTS

Forwarding of IP traffic MUST be supported. Other network layer protocols MAY be supported. The ability to restrict the network layer to a single protocol such as IP MUST be supported. The 802.1d spanning tree protocol of [ISO/IEC10038] with the modifications described in Annex E MAY be supported by CMs intended for residential use. CMs intended for commercial use MUST support this version of spanning tree. CMs and CMTSes MUST include the ability to filter (and disregard) 802.1d BPDUs.
1. 2.

Except as a result of Payload Header Suppression. Refer to Section 10.4. With the exception that for packet PDUs less than 64 bytes to be forwarded from the upstream RFI, a CMTS MUST pad out the packet PDU and recompute the CRC.

28

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

This specification assumes that CMs intended for residential use will not be connected in a configuration which would create network loops such as that shown in Figure 5-3.

CMTS

Cable Network

CM #1

CM #2

Local ISO8802 Network

CPE

Figure 5-3

Example Condition for Network Loops

Although provisions exist in this specification for frames to be passed from a higher-layer entity to be forwarded by the cable modem, these frames MUST be treated identically to frames arriving at the CPE port. In particular, all of the forwarding rules defined in Section 5.1.2.3 MUST apply to these frames.1 5.1.2.2 CMTS Forwarding Rules

At the CMTS, if link-layer forwarding is used, then it MUST conform to the following general 802.1d guidelines:

Link-layer frames MUST NOT be duplicated. Stale frames (those that cannot be delivered in a timely fashion) MUST be discarded. Link-layer frames, on a given Service Flow (refer to Section 8.1.2.3), MUST be delivered in the order they
are received. The address-learning and -aging mechanisms used are vendor-dependent. If network-layer forwarding is used, then the CMTS should conform to IETF Router Requirements [RFC-1812] with respect to its CMTS-RFI and CMTS-NSI interfaces. Conceptually, the CMTS forwards data packets at two abstract interfaces: between the CMTS-RFI and the CMTS-NSI, and between the upstream and downstream channels. The CMTS MAY use any combination of link-layer (bridging) and network-layer (routing) semantics at each of these interfaces. The methods used at the two interfaces need not be the same. Forwarding between the upstream and downstream channels within a MAC layer differs from traditional LAN forwarding in that:

A single channel is simplex, and cannot be considered a complete interface for most protocol (e.g., 802.1d
spanning tree, Routing Information Protocol per [RFC-1058]) purposes.

Upstream channels are essentially point-to-point, whereas downstream channels are shared-media. Policy decisions may override full connectivity.

1.

Section 5.1.2.1, last paragraph added per RFI2-N-02171 by RKV on 10/29/02.

29

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

For these reasons, an abstract entity called the MAC Forwarder exists within the CMTS to provide connectivity between stations within a MAC domain (see Section 5.2). 5.1.2.3 CM Forwarding Rules

Data forwarding through the CM is link-layer bridging with the following specific rules. 5.1.2.3.1 CPE MAC Address Acquisition

The CM MUST acquire Ethernet MAC addresses of connected CPE devices, either from the provisioning
process or from learning, until the CM acquires its maximum number of CPE MAC addresses (a devicedependent value). Once the CM acquires its maximum number of CPE MAC addresses, then newly discovered CPE MAC addresses MUST NOT replace previously acquired addresses. The CM must support acquisition of at least one CPE MAC address.

The CM MUST allow configuration of CPE addresses during the provisioning process (up to its maximum
number of CPE addresses) to support configurations in which learning is not practical nor desired.

Addresses provided during the CM provisioning MUST take precedence over learned addresses. CPE addresses MUST NOT be aged out. In order to allow modification of user MAC addresses or movement of the CM, addresses are not retained in
non-volatile storage. On a CM reset (e.g., power cycle), all provisioned and learned addresses MUST be discarded. 5.1.2.3.2 Forwarding

CM forwarding in both directions MUST conform to the following general 802.1d guidelines:

Link-layer frames MUST NOT be duplicated. Stale frames (those that cannot be delivered in a timely fashion) MUST be discarded. Link-layer frames MUST be delivered in the order that they are received on a given Service Flow (refer to
Section 8.1.2.3). In the upstream direction, the CM may perform one or more frame/packet processing functions on frames received from the CMCI prior to classifying them to a Service Flow. In the downstream direction, the CM may perform one or more frame/packet processing functions on frames received from the HFC prior to transmitting them on the CMCI. Example processing functions include: DOCSIS protocol filtering as specified in [DOCSIS5] section 7.3, a policy-based filtering service as described in Section 10.1.6.1 and Appendix I, and priority-based queuing to support 802.1P/Q services.1 Cable-Network-to-CMCI forwarding MUST follow the following specific rules:

Frames addressed to unknown destinations MUST NOT be forwarded from the cable port to the CPE ports. Broadcast frames MUST be forwarded to the CPE ports, unless they are from source addresses which are
provisioned or learned as supported CPE devices, in which case they MUST NOT be forwarded.

The forwarding of multicast is controlled by administratively set filters and by either IGMP (refer to Section
5.3.1) or static provisioning (refer to Annex C.1.2.12). Multicast frames MUST NOT be forwarded unless both filtering and either IGMP or static multicast provisioning are in a permissive state.2

1. 2.

This bulleted item updated per RFI2-N-02161 by RKV on 10/29/02. Revised this bullet statement per ECN RFIv2.0-N-04.0143-4 by GO on 7/8/04.

30

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CMCI-to-Cable-Network forwarding MUST follow the following specific rules:

Frames addressed to unknown destinations MUST be forwarded from all CPE ports to the cable port. Broadcast frames MUST be forwarded to the cable port. Multicast frames MUST be forwarded to the cable port in accordance with filtering configuration settings
specified by the cable operators operations and business support systems.

Frames from source addresses other than those provisioned or learned as supported CPE devices MUST NOT
be forwarded.

Other (non-supported) CPE source addresses MUST be learned from all CPE ports and this information used
to filter local traffic as in a traditional learning bridge.

Frames addressed to destination addresses that are learned from all CPE ports MUST be filtered as local
traffic.1

5.2

The MAC Forwarder

The MAC Forwarder is a MAC sublayer that resides on the CMTS just below the MAC service access point (MSAP) interface, as shown in Figure 5-4. It is responsible for delivering upstream frames to

One or more downstream channels The MSAP interface

In Figure 5-4, the LLC sublayer and link security sublayers of the upstream and downstream channels on the cable network terminate at the MAC Forwarder. The MSAP interface user may be the NSI-RFI Forwarding process or the CMTSs host protocol stack.

CMTS RFI-NSI Forwarding Process Host IP Stack, incl. LLC and 802.2/DIX MAC Service Access Point (MSAP) Interface CMTS -NSI MAC Forwarder Link Security MAC

Upstream and Downstream Channels

Figure 5-4 MAC Forwarder

Delivery of frames may be based on data-link-layer (bridging) semantics, network-layer (routing) semantics, or some combination. Higher-layer semantics may also be employed (e.g., filters on UDP port numbers). The CMTS MUST provide IP connectivity between hosts attached to cable modems, and must do so in a way that meets the expectations of Ethernet-attached customer equipment. For example, the CMTS must either forward

1.

Section 5.1.2.3.2 updated per RFI2-N-02171 by RKV on 10/29/02.

31

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

ARP packets or it must facilitate a proxy ARP service. The CMTS MAC Forwarder MAY provide service for non-IP protocols. Note that there is no requirement that all upstream and downstream channels be aggregated under one MSAP as shown above. The vendor could just as well choose to implement multiple MSAPs, each with a single upstream and downstream channel. 5.2.1 Rules for Data-Link-Layer Forwarding The requirements in this section apply if the MAC Forwarder is implemented using only data-link-layer semantics. Delivery of frames is dependent on the Destination Address within the frame. The means of learning the location of each address is vendor-dependent, and MAY include:

Transparent-bridging-like source-address learning and aging Gleaning from MAC Registration Request messages Administrative means
If the destination address of a frame is unicast, and that address is associated with a particular downstream channel, then the frame MUST be forwarded to that channel.1 If the destination address of a frame is unicast, and that address is known to reside on the other (upper) side of the MSAP interface, then the frame MUST be delivered to the MSAP interface. If the destination address is broadcast, multicast,2 or unknown, the frame MUST be delivered to both the MSAP and to all downstream channels (with the exception of the 5.3.1.2 multicast forwarding rules). Delivery rules are similar to those for transparent bridging:

Frames MUST NOT be duplicated. Frames that cannot be delivered in a timely fashion MUST be discarded. The Frame Check Sequence SHOULD be preserved rather than regenerated. Frames, on a given Service Flow (refer to Section 8.1.2.3), MUST be delivered in the order they are received.

5.3

Network Layer

As stated above, the purpose of the data-over-cable system is to transport IP traffic transparently through the system. The Network Layer protocol is the Internet Protocol (IP) version 4, as defined in [RFC-791], and migrating to IP version 6. This document imposes no requirements for reassembly of IP packets.

1.

Vendors may implement extensions, similar to static addresses in 802.1d/ISO 10038 bridging, that cause such frames to be filtered or handled in some other manner. All multicasts, including 802.1d/ISO 10038 Spanning Tree Bridge BPDUs, MUST be forwarded.

2.

32

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

5.3.1 Requirements for IGMP Management There are two basic modes of IGMP capability that are applicable to a DOCSIS 2.0 device (CMTS and CM). The first mode is a passive operation in which the device selectively forwards IGMP based upon the known state of multicast session activity on the subscriber side (an example of this is described in Appendix V). In passive mode, the device derives its IGMP timers based on the rules specified in section 3.3.1.1 of [DOCSIS11]. The second mode is an active operation in which the device terminates and initiates IGMP based upon the known state of multicast session activity on the subscriber side. One example of the latter, active, mode is commonly referred to as an IGMP-Proxy implementation side (as described in [ID-IGMP]). A more complete example of an active IGMP device is that of a Multicast Router. Active and Passive IGMP devices MUST support IGMPv2 [RFC-2236]. 5.3.1.1 IGMP Timer Requirements

The following IGMP timer requirements apply only when the device (CMTS / CM) is operating in passive IGMP mode:

The device MUST NOT require any specific configuration for the associated multicast timer values and
MUST be capable of adhering to the timers specified in this section.

The device MAY provide configuration control that overrides the default values of these timers. The device MUST derive the Membership Query Interval by looking at the inter-arrival times of the Membership Query messages. Formally: If n < 2, MQI = 125 else MQI = MAX (125, MQn- MQn-1), where MQI is the Membership Query Interval in seconds, n is the number of Membership Queries seen, and MQn is the epoch time at which the nth Membership Query was seen to the nearest second.

The Query Response Interval is carried in the Membership Query packet. The Query Response Interval
MUST be assumed to be 10 seconds if not otherwise set (or set to 0) in the Membership Query packet. 5.3.1.2 CMTS Rules

If link-layer forwarding of multicast packets is used, the CMTS MUST forward all Membership Queries on
all downstream channels using the appropriate 802.3 multicast group (e.g., 01:00:5E:xx:xx:xx where xx:xx:xx are the low order 23 bits of the multicast address expressed in hex notation. Refer to [IMA].).

The CMTS MUST forward the first copy of Solicited and Unsolicited Membership Reports for any given
group received on its upstream RF interface to all of its downstream RF interfaces. However, if membership is managed on a per downstream RF interface basis, Membership Reports and IGMP v2 Leave messages MAY be forwarded only on the downstream interface to which the reporting CPEs CM is connected.

The CMTS SHOULD suppress the transmission of additional Membership Reports (for any given group)
downstream for at least the Query Response Interval. If the CMTS uses data-link-layer forwarding, it MUST also forward the Membership Report out all appropriate Network Side Interfaces.

The CMTS SHOULD suppress the downstream transmission of traffic to any IP multicast group that does not
have subscribers on that downstream RF interface (subject to any administrative controls).

If the CMTS performs network-layer forwarding of multicast packets, it MUST support Active IGMP mode. If link-layer forwarding of multicast packets is used, the CMTS SHOULD support Passive IGMP mode and
MAY support Active IGMP mode.

33

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

5.3.1.3

CM Rules

The CM MUST support IGMP with the cable-specific rules specified in this section. The CM MUST implement the passive IGMP mode. Additionally, the CM MAY implement the active IGMP mode. If it implements the active IGMP mode, the CM MUST support a capability to switch between modes. 5.3.1.3.1 Multicast Forwarding Requirements

The following requirements apply to both passive and active modes of IGMP operations:

The CM MUST NOT forward Membership Queries from its CPE interface to its RF interface. The CM MUST NOT forward Membership Reports or IGMP v2 Leaves received on its RF interface to its
CPE interface.

The CM MUST NOT forward multicast traffic from its RF interface to its CPE interface unless a device on its
CPE interface is a member of that IP multicast group.

The CM MUST forward multicast traffic from its CPE interface to its RF interface unless administratively
(via configuration or other mechanism) prohibited.

As a result of receiving a Membership Report on its CPE interface, the CM MUST begin forwarding traffic
for the appropriate IP multicast group. The CM MUST stop forwarding multicast traffic from the RF to the CPE side whenever the CM has not received a Membership Report from the CPE side for more than the Membership Interval, which is (2 * MQI) + QRI, where MQI is the Membership Query Interval and QRI is the Query Response Interval.

The CM MAY stop forwarding traffic from the RF to the CPE side for a particular multicast group prior to the
expiration of the Membership Interval (see above) if it can determine (for example, via an IGMP LEAVE message and the appropriate protocol exchange) that there are no CPE devices subscribed to that particular group. The following requirements apply only when the CM is operating in passive IGMP mode:

The CM MUST forward traffic for the ALL-HOSTS multicast group from its RF interface to its CPE interface unless administratively prohibited. The CPE MUST always be considered a member of this group. In particular, the CM MUST forward ALL-HOSTS Group Queries that pass permit filters on its RF interface to its CPE interface.

Upon receiving a Membership Report on its CPE interface, the CM MUST start a random timer between 0
and 3 seconds. During this time period, the CM MUST discard any additional Membership Reports received in its CPE interface for the associated multicast group. If the CM receives a Membership Report on its HFC interface for the associated multicast group, the CM MUST discard the Membership Report received on its CPE interface. If the random timer expires without the reception of a Membership Report on the CMs HFC interface, the CM MUST transmit the Membership Report received on its CPE interface. The following requirements apply only when the CM is operating in active IGMP mode:

The CM MUST implement the Host portion of the IGMP v2 protocol [RFC-2236] on its RF interface for
CPEs with active groups and MUST NOT act as a Querier on its RF interface.

The CM MUST act as an IGMPv2 Querier on its CPE interface. If the CM has received a Membership Report on its downstream RF interface for groups active on the CMs
CPE interface within the Query Response Interval, it MUST suppress transmission on its upstream RF interface of such Membership Reports.

34

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The CM MUST suppress all subsequent Membership Reports for this group until such time as the CM
receives a Membership Query (General or Specific to this Group) on its RF interface or a IGMPv2 Leave is received for this group from the CPE interface.

The CM MUST treat Unsolicited Membership Reports (IGMP JOINs) from its CPE interface as a response to
a Membership Query received on its RF interface. Upon receipt of this unsolicited JOIN from its CPE interface, the CM MUST start a random timer according to the Host State Diagram, specified in [RFC-2236], and MUST use a Query Response Interval of 3 seconds. As specified above, if the CM receives a Membership Report on its RF interface for this group during this random time period, it MUST suppress transmission of this Join on its upstream RF interface.

On startup, the CM SHOULD send one or more General Queries on its CPE interface (as described in [RFC2236]) in order to quickly and reliably determine membership information for attached CPEs.1
Note: Nothing in this section would prohibit the CM from being specifically configured to not forward certain multicast traffic as a matter of network policy.

5.4

Above the Network Layer

The subscribers will be able to use the transparent IP capability as a bearer for higher-layer services. Use of these services will be transparent to the CM. In addition to the transport of user data, there are several network management and operation capabilities which depend upon the Network Layer. These include:

SNMP (Simple Network Management Protocol, [RFC-1157]), MUST be supported for network management. TFTP (Trivial File Transfer Protocol, [RFC-1350]), a file transfer protocol, MUST be supported for downloading operational software and configuration information, as modified by TFTP Timeout Interval and Transfer Size Options [RFC-2349].

DHCP (Dynamic Host Configuration Protocol, [RFC-2131]), a framework for passing configuration information to hosts on a TCP/IP network, MUST be supported.

Time of Day Protocol, [RFC-868], MUST be supported to obtain the time of day.
DHCP, TFTP, and ToD client messages generated by the CM MUST only be sent via the RF Interface. DHCP, TFTP and ToD client messages include DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPRELEASE, DHCPINFORM, TFTP-RRQ, TFTP-ACK, and ToD request. The CMs DHCP, TFTP, and ToD client MUST ignore DHCP, TFTP, and ToD server messages received on the CMCI port. DHCP, TFTP, and ToD server messages include: DHCPOFFER, DHCPACK, DHCPNAK, TFTPDATA, and ToD time message.

5.5

Data Link Layer

The Data Link Layer is divided into sublayers in accordance with [IEEE802], with the addition of Link-Layer security in accordance with [DOCSIS8]. The sublayers, from the top, are:

Logical Link Control (LLC) sublayer (Class 1 only) Link-Layer Security sublayer Media Access Control (MAC) sublayer

1.

Added this bullet statement per ECN RFIv2.0-N-03.0120-2 by GO on 02/11/04.

35

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

5.5.1 LLC Sublayer The LLC sublayer MUST be provided in accordance with [ISO/IEC10039]. Address resolution MUST be used as defined in [RFC-826]. The MAC-to-LLC service definition is specified in [ISO/IEC10039]. 5.5.2 Link-Layer Security Sublayer Link-layer security MUST be provided in accordance with [DOCSIS8]. 5.5.3 MAC Sublayer The MAC sublayer defines a single transmitter for each downstream channel - the CMTS. All CMs listen to all frames transmitted on the downstream channel upon which they are registered and accept those where the destinations match the CM itself or CPEs reached via the CMCI port. CMs can communicate with other CMs only through the CMTS. The upstream channel is characterized by many transmitters (CMs) and one receiver (the CMTS). Time in the upstream channel is slotted, providing for Time Division Multiple Access at regulated time ticks. The CMTS provides the time reference and controls the allowed usage for each interval. Intervals may be granted for transmissions by particular CMs, or for contention by all CMs. CMs may contend to request transmission time. To a limited extent, CMs may also contend to transmit actual data. In both cases, collisions can occur and retries are used. Section 8 describes the MAC-sublayer messages from the CMTS which direct the behavior of the CMs on the upstream channel, as well as messaging from the CMs to the CMTS. 5.5.3.1 MAC Service Definition

The MAC sublayer service definition is in Appendix I.

5.6

Physical Layer

The Physical (PHY) layer is comprised of two sublayers:

Transmission Convergence sublayer (present in the downstream direction only) Physical Media Dependent (PMD) sublayer
5.6.1 Downstream Transmission Convergence Sublayer The Downstream Transmission Convergence sublayer exists in the downstream direction only. It provides an opportunity for additional services over the physical-layer bitstream. These additional services might include, for example, digital video. Definition of any such additional services is beyond the scope of this document. This sublayer is defined as a continuous series of 188-byte MPEG [ITU-T H.222.0] packets, each consisting of a 4-byte header followed by 184 bytes of payload. The header identifies the payload as belonging to the data-overcable MAC. Other values of the header may indicate other payloads. The mixture of payloads is arbitrary and controlled by the CMTS. The Downstream Transmission Convergence sublayer is defined in Section 7 of this document.

36

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

5.6.2 PMD Sublayer The Physical Media Dependent sublayer is defined in Section 6, Physical Media Dependent Sublayer Specification, on page 39. 5.6.2.1 Interface Points

Three RF interface points are defined at the PMD sublayer: a) Downstream output on the CMTS

b) Upstream input on the CMTS c) Cable in/out at the cable modem

Separate downstream output and upstream input interfaces on the CMTS are required for compatibility with typical downstream and upstream signal combining and splitting arrangements in head-ends.

37

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

38

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6 Physical Media Dependent Sublayer Specification

6.1 Scope

This specification defines the electrical characteristics and signal processing operations for a cable modem (CM) and cable modem termination system (CMTS). It is the intent of this specification to define an interoperable CM and CMTS such that any implementation of a CM can work with any CMTS. It is not the intent of this specification to imply any specific implementation. This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option, refer to Annex F. Whenever any reference in this section to spurious emissions conflicts with any legal requirement for the area of operation, the latter shall take precedence.

6.2

Upstream

6.2.1 Overview The upstream Physical Media Dependent (PMD) sublayer uses a FDMA/TDMA (herein called TDMA mode) or FDMA/TDMA/S-CDMA (herein called S-CDMA mode) burst type format, which provides six modulation rates and multiple modulation formats. The use of TDMA or S-CDMA mode is configured by the CMTS via MAC messaging. FDMA (frequency division multiple access) indicates that multiple RF channels are assigned in the upstream band. A CM transmits on a single RF channel unless reconfigured to change channels. TDMA (time division multiple access) indicates that upstream transmissions have a burst nature. A given RF channel is shared by multiple CMs via the dynamic assignment of time slots. S-CDMA (synchronous code division multiple access) indicates that multiple CMs can transmit simultaneously on the same RF channel and during the same TDMA time slot, while being separated by different orthogonal codes. In this document, the following naming conventions are used. For TDMA, the term modulation rate refers to the RF channel symbol rate (160 to 5120 ksps). For S-CDMA, the term chip rate, which is the modulation rate (1280 to 5120 kHz) of a single bit of the S-CDMA spreading code, may be used interchangeably with modulation rate. The modulation interval is the symbol period (TDMA mode) or chip period (S-CDMA mode) and is the reciprocal of the modulation rate. At the output of the spreader, a group of 128 chips which comprise a single S-CDMA spreading code, and are the result of spreading a single information (QAM constellation) symbol is referred to as a spread symbol. The period of a spread symbol (128 chips) is called a spreading interval. A burst is a physical RF entity that contains a single preamble plus data, and (in the absence of preceding and following bursts) exhibits RF energy ramp-up and ramp-down. In some cases logical zeros are used to pad data blocks; this indicates data with zero-valued binary bits, which result in non-zero transmitted RF energy. In other cases a numerical zero is used; this denotes, for example, symbols which result in zero transmitted RF energy (after ramp-up and ramp-down are taken into account). The modulation format includes pulse shaping for spectral efficiency, is carrier-frequency agile, and has selectable output power level. Each burst supports a flexible modulation order, modulation rate, preamble, randomization of the payload, and programmable FEC encoding.

39

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

All of the upstream transmission parameters associated with burst transmission outputs from the CM are configurable by the CMTS via MAC messaging. Many of the parameters are programmable on a burst-by-burst basis. The PMD sublayer can support a near-continuous mode of transmission, wherein ramp-down of one burst MAY overlap the ramp-up of the following burst, so that the transmitted envelope is never zero. In TDMA mode, the system timing of the TDMA transmissions from the various CMs MUST provide that the center of the last symbol of one burst and the center of the first symbol of the preamble of an immediately following burst are separated by at least the duration of five symbols. The guard band MUST be greater than or equal to the duration of five symbols plus the maximum timing error. Timing error is contributed by both the CM and CMTS. CM timing performance is specified in Section 6.2.19. Maximum timing error and guard band may vary with CMTSs from different vendors. The term guard time is similar to the guard band, except that it is measured from the end of the last symbol of one burst to the beginning of the first symbol of the preamble of an immediately following burst. Thus, the guard time is equal to the guard band 1.1 The PMD sublayer also supports a synchronous mode of transmission when using S-CDMA, wherein rampdown of one burst MAY completely overlap the ramp-up of the following burst, so that the transmitted envelope is never zero. There is no guard time for transmission on S-CDMA channels. The system timing of the S-CDMA transmissions from the various CMs MUST provide adequate timing accuracy so that different CMs do not appreciably interfere with each other. S-CDMA utilizes precise synchronization so that multiple CMs can transmit simultaneously.2 The upstream modulator is part of the cable modem which interfaces with the cable network. The modulator contains the electrical-level modulation function and the digital signal-processing function; the latter provides the FEC, preamble prepend, symbol mapping, and other processing steps. At the Demodulator, similar to the Modulator, there are two basic functional components: the demodulation function and the signal processing function. The Demodulator resides in the CMTS and there is one demodulation function (not necessarily an actual physical demodulator) for each carrier frequency in use. The demodulation function receives all bursts on a given frequency. The demodulation function of the Demodulator accepts a varying-level signal centered around a commanded power level and performs symbol timing and carrier recovery and tracking, burst acquisition, and demodulation. Additionally, the demodulation function provides an estimate of burst timing relative to a reference edge, an estimate of received signal power, may provide an estimate of signal-to-noise ratio, and may engage adaptive equalization to mitigate the effects of a) echoes in the cable plant, b) narrowband ingress and c) group delay. The signal-processing function of the Demodulator performs the inverse processing of the signal-processing function of the Modulator. This includes accepting the demodulated burst data stream and decoding, etc. The signalprocessing function also provides the edge-timing reference and gating-enable signal to the demodulators to activate the burst acquisition for each assigned burst slot. The signal-processing function may also provide an indication of successful decoding, decoding error, or fail-to-decode for each codeword and the number of corrected Reed-Solomon symbols in each codeword. For every upstream burst, the CMTS has a prior knowledge of the exact burst length in modulation intervals (see Sections 6.2.19, 6.2.5.1, and Annex A.2). 6.2.2 Signal Processing Requirements The signal processing order for each burst packet type MUST be compatible with the sequence shown in Figure 6-1. For TDMA mode, the signal processing order for each burst packet type MUST follow the order of steps in

1. 2.

Last five sentences of this paragraph updated per RFI2-N-02085 by RKV on 10/28/02. This paragraph updated per RFI2-N-02173 by RKV on 10/30/02.

40

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Figure 6-2. For S-CDMA mode, the signal processing order for each burst packet type MUST follow the order of steps in Figure 6-3. The blocks used only in S-CDMA consist of a TCM encoder, S-CDMA framer, and S-CDMA spreader. The TCM encoder provides trellis modulation encoding of data symbols and is described in Section 6.2.8. The SCDMA framer maps mini-slots into code resources and provides interleaving of data symbols and is described in Section 6.2.11. The S-CDMA spreader spreads S-CDMA framed symbols for transmission and is described in Section 6.2.14, S-CDMA Spreader, on page 72.

Burst data in

RS Encoder

Byte Interleaver (TDMA only)

Scram bler

T CM Encoder (S-CDM A only)

Fram er (S-CDM A only)

Sym bol M apper

Spreader (S-CDM A only)

Pream ble Prepend

Transm it Equalizer

Filter

M odulator

RF out

Figure 6-1

Upstream signal-processing sequence

41

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Packet Stream Input Block the Data Separate Packet into Information Blocks (=data bytes in one codeword) R-S Encode R-S (Reed-Solomon) Encode each Information Block, using shortened codeword for last block if needed. R-S FEC can be turned off. Byte Interleave R-S Byte Interleave. R-S Byte interleaver can be turned off. Scramble Scramble (see Figure 6-7) Preamble Prepend Prepend Preamble Symbols Symbol Map Map the Data Stream into Modulator Symbols Transmit Equalize Pre-Equalize the Symbol Stream Filter Filter Symbol Stream for Spectral Shaping Modulate Modulate at Precise Times (QPSK; 8 QAM; 16 QAM; 32 QAM; 64 QAM) Output RF Waveform Bursts
Figure 6-2 TDMA Upstream Transmission Processing

42

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Packet Stream Input Block the Data Separate Packet into Information Blocks (=data bytes in one codeword) R-S Encode R-S (Reed-Solomon) Encode each Information Block, using shortened codeword for last block if needed. R-S FEC can be turned off. Scramble Scramble (see Figure 6-7) TCM Encode TCM (Trellis Coded Modulation) Encode the bytes. TCM can be turned off. Preamble Prepend Prepend Preamble Symbols S-CDMA Framer Frame and Interleave the Data into Mini-Slots. Symbol Map Map the Data Stream into Modulator Symbols S-CDMA Spreader Transmit Equalize Spread the Symbols. For spreader-off bursts on SCDMA channels, spreader can be turned off. Pre-Equalize the Signal Stream Filter Filter Signal for Spectral Shaping Modulate Modulate at Precise Times (QPSK; 8 QAM; 16 QAM; 32 QAM; 64 QAM; 128 QAM/TCM only) Output RF Waveform Bursts
Figure 6-3 S-CDMA Upstream Transmission Processing

43

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.3 Modulation Formats The upstream modulator MUST provide QPSK and 16QAM differential encoded modulations for TDMA. The upstream modulator MUST provide QPSK, 8QAM, 16QAM, 32QAM, and 64QAM modulations for TDMA and S-CDMA channels. The upstream modulator MUST provide QPSK, 8QAM, 16QAM, 32QAM, 64QAM and 128QAM TCM encoded modulations for S-CDMA channels. The upstream demodulator MAY support QPSK and 16QAM differential modulation for TDMA. The upstream demodulator MUST support QPSK, 16QAM, and 64QAM modulations for TDMA and S-CDMA channels. The upstream demodulator MAY support 8QAM and 32QAM modulation for TDMA and S-CDMA channels. The upstream demodulator MAY support QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM TCM encoded modulations for S-CDMA channels. 6.2.4 R-S Encode 6.2.4.1 R-S Encode Modes

The upstream modulator MUST be able to provide the following selections: Reed-Solomon codes over GF(256) with T = 1 to 16 or no R-S coding. The following Reed-Solomon generator polynomial MUST be supported: g(x) = (x+0) (x+1)...(x+2T-1) where the primitive element alpha is 0x02 hex The following Reed-Solomon primitive polynomial MUST be supported: p(x) = x8 + x4 + x3+ x2 + 1 The upstream modulator MUST provide codewords from a minimum size of 18 bytes (16 information bytes [k] plus two parity bytes for T = 1 error correction) to a maximum size of 255 bytes (k-bytes plus parity-bytes). The minimum uncoded word size MUST be one byte. In Shortened Last Codeword mode, the CM MUST provide the last codeword of a burst shortened from the assigned length of k data bytes per codeword as described in Section 6.2.5.1.3. The value of T MUST be configured in response to the Upstream Channel Descriptor from the CMTS. 6.2.4.2 R-S Bit-to-Symbol Ordering

The input to the Reed-Solomon Encoder is logically a serial bit stream from the MAC layer of the CM, and the first bit of the stream MUST be mapped into the MSB of the first Reed-Solomon symbol into the encoder. The MSB of the first symbol out of the encoder MUST be mapped into the first bit of the serial bit stream fed to the Scrambler.
Note: The MAC byte-to-serial upstream convention calls for the byte LSB to be mapped into the first bit of the serial bit stream per Section 8.2.1.3.

44

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.5 R-S Frame Structure Figure 6-4 shows two examples of the R-S frame structure: one where the packet length equals the number of information bytes in a codeword, and another where the packet length is longer than the number of information bytes in one codeword, but less than in two codewords. Example 1 illustrates the fixed codeword-length mode, and Example 2 illustrates the shortened last codeword mode. These modes are defined in Section 6.2.5.1.

Example 1. Packet length = number of information bytes in codeword = k

One Codeword
Preamble Packet Data FEC Parity Guard Time Empty up to Next Mini-Slot Boundary

k + k 2k Example 2. Packet length = k + remaining information bytes in 2nd codeword = k + k Preamble Two Codewords Guard Time mini-slot boundary

First k Bytes of Packet

FEC Parity

Last k Bytes k-k bytes of of Packet zero-fill

FEC Parity

Figure 6-4

Example Frame Structures with Flexible Burst Length Mode

6.2.5.1

R-S Codeword Length

When R-S FEC is enabled, the CM operates in either fix-length codeword mode or in shortened-last codeword mode. The minimum number of information bytes in a codeword in either mode is 16. Shortened-last codeword mode only provides a benefit when the number of bytes in a codeword is greater than the minimum of 16 bytes. The intent of the following sections is to define rules and conventions such that CMs request the proper number of mini-slots and the CMTS PHY knows what to expect regarding the R-S FEC framing in both fixed codeword length and shortened last codeword modes. Shortened last codeword mode MUST NOT be used for Initial Maintenance (broadcast or unicast). 6.2.5.1.1 Burst Size

For an allocation of mini-slots (in both contention and non-contention regions), the requirements of Sections 6.2.5.1.2 and 6.2.5.1.3 apply to a burst transmitted in that allocation. Regardless of the size of the allocation, the size of the burst MUST be as specified in Table 6-1 below.

45

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table 6-1
IUC 1, 3 2 4-6, 9-11 Burst Size

Burst Size

Minimum number of mini-slots required for message transmission including burst overhead. Burst overhead includes pre-amble, R-S parity bytes, TCM return-to-zero bits, and guard time if applicable. Number of mini-slots specified in the Well-Known Multicast SID (refer to Annex A). Number of mini-slots allocated.

6.2.5.1.2

Fixed Codeword Length

With the fixed-length codewords, after all the data are encoded, zero-fill will occur in this codeword if necessary to reach the assigned k data bytes per codeword. Additionally, zero-fill MUST continue up to the point when no additional fixed-length codewords can be inserted before the end of the burst specified in Table 6-1 above, accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any). 6.2.5.1.3 Shortened Last Codeword

As shown in Table 6-4, let k = the number of information bytes that remain after partitioning the information bytes of the burst into full-length (k burst data bytes) codewords. The value of k is less than k. Given operation in a shortened last codeword mode, let k = the number of burst data bytes plus zero-fill bytes in the shortened last codeword. In shortened codeword mode, the CM MUST encode the data bytes of the burst (including MAC Header) using the assigned codeword size (k information bytes per codeword) until 1) all the data are encoded, or 2) a remainder of data bytes is left over which is less than k. Shortened last codewords MUST NOT have less than 16 information bytes, and this is to be considered when CMs make requests of mini-slots. In shortened last codeword mode, the CM MUST zero-fill data if necessary up to the Burst Size specified in Table 6-1 above accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any). Therefore, in many cases, only k - k zero-fill bytes are necessary with 16 <= k <= k and k <= k. More generally, the CM MUST zero-fill data until the point when no additional fixed-length codewords can be inserted before the end of the burst specified in Table 6-1 above, accounting for preamble, FEC parity, return-tozero bits and guard-time symbols (if any), and then, if possible, a shortened last codeword of zero-fill MUST be inserted to fit into the last mini-slot. If, after zero-fill of additional codewords with k information bytes, there are less than 16 bytes remaining before the end of the burst specified in Table 6-1 above, accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any), then the CM shall not create this last shortened codeword. 6.2.5.2 R-S FEC Disabled

When T = 0 (no FEC parity bytes), the RS encoder SHOULD zero-fill in full bytes to the end of the burst specified in Section 6.2.5.1.1 above, accounting for preamble, return-to-zero bits, and guard-time symbols (if any).1

1.

Sections 6.2.5.1, 6.2.5.1.1, 6.2.5.1.2, 6.2.5.1.3, and 6.2.5.2 updated and/or added per RFI2-N-02135 by RKV on 10/29/02.

46

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.6 TDMA Byte Interleaver R-S codeword interleaving in a byte (R-S symbol) format MUST be performed after R-S encoding on a TDMA channel. The byte interleaver changes the order of the bytes at the R-S encoder output, i.e., it performs an operation of byte permutation. At the receiver side, the original order of bytes is restored prior to the R-S decoding. Therefore, if some consecutive bytes were corrupted by burst noise, they are spread between various R-S codewords, averaging the number of erroneous bytes in each codeword. The interleaver is a block interleaver type, i.e., the permutation is achieved by filling a table row-wise (one row per R-S codeword), and reading it column-wise. The total memory size allocated for the table is 2048 bytes. The byte interleaver is disabled when the R-S encoder is turned off (T = 0). 6.2.6.1 Byte Interleaver Parameters

The interleaver operating parameters described in Table 6-2 determine the operation of the interleaver for every burst.
Table 6-2
Parameter Nr Ir

Interleaver Operating Parameters

Definition Allowed Values 18 to 255 0 - Dynamic Mode 1 - No Interleaving 2 to floor(2048/Nr) for Fixed Mode

Interleaver Width (RS Codeword Length, k+2*T) Interleaver Depth

Br Nf

Interleaver Block Size Packet Size (in bytes, including FEC)

2*Nr to 2048

18 bytes

The CMTS and CM MUST use the interleaver parameters within the allowed values in 6-2 with the following additional restrictions: 1. Nr and Ir MUST be chosen such that NrIr<= 2048 (in other words, for a given Nr, the maximal value of Ir is Ir,max=floor(2048/Nr)). 2. Nr MUST be identical to the R-S codeword length (i.e. k+2T). 3. Br is effective only when Ir=0. This mode is called dynamic mode. 4. When Ir=1, interleaving is disabled. Nr, Ir, and Br are specified in the burst profile, and Nf is implied in the MAP message. 6.2.6.2 Interleaver Operating Modes

The interleaver MUST support both an operating mode in which the block size is fixed, as well as, a dynamic mode in which the interleaver depth is determined based on the burst size. 6.2.6.2.1 Fixed Mode

The RS encoded data bytes of the packet are first divided into interleaver blocks of NrIr bytes (i.e., blocks of Ir RS codewords each). The size of the last interleaver block may be smaller when the packet length is not an integer multiple of NrIr. Each interleaver block is interleaved separately.

47

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Each interleaver block is filled into a table with Ir rows and Nr columns. The data is written row by row (from left to right). Therefore, each row corresponds to one RS codeword. The bytes are read column by column (from top to bottom). The interleaver operation is demonstrated in Figure 6-5.

Write

C1(1) C2(1)

C1(2) C2(2)

C1 (Nr) C2 (Nr)

CIr(1)

CIr(2)

CIr (Nr)

Input sequence: C1(1),...C1 (Nr),C 2(1),....C2 (Nr),C 3(1).....CIr (Nr) Output sequence: C1(1),C2(1)...CIr(1),C1(2),....CIr(2),C1(3).....CIr (Nr)

The last interleaver block might have fewer rows than Ir. If the shortened last codeword mode is applied, then the last row might have fewer elements than Nr. In these cases, the interleaver table is read column by column, skipping the empty elements of the table. The interleaver operation for the last interleaver block is demonstrated in Figure 6-6.

Read
Figure 6-5 Byte Interleaver Operation

Write

C1(1) C2(1)

C1(2) C2(2)

C1(N')

C1(Nr) C2(Nr)

Ci'-1(N') CI'(1) CI'(2) CI'(N')

Ci'-1(Nr)

Input sequence: C1(1),...C1 (Nr),C 2(1),....C2 (Nr),C 3(1).....CI'(1)......CI'(N') Output sequence: C1(1),C2(1)...CI'(1),C1(2)...CI'(2)...C1(N')...CI'(N'),C1(N'+1)....CI'-1(N'+1),C1(N'+2)...Ci'-1(N'+2)...C1 (Nr)...C I'-1 (Nr)
Figure 6-6 Interleaver operation for last interleaver block (with shortened last codeword)

Read

48

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.6.2.2

Dynamic Mode

In the fixed mode, the interleaving depth of the last interleaving block of a packet (I' in Figure 6-6) may be as small as one, resulting in low burst noise robustness for this block. In the dynamic mode, the depths of the interleaver blocks are chosen such that all blocks have approximately the same depth to achieve nearly optimal burst noise robustness (for the given block size). The RS encoded data bytes of the packet are first divided into Ns0 interleaver blocks. The size of the ith interleaver block is Nr*Ir(i) bytes (i.e. a block of Ir(i) RS codewords). The size of the last interleaver block may be smaller in the shortened last codeword mode. Each interleaver block is interleaved separately (see the equations for Ns0 and Ir(i) in Section 6.2.6.2.2.1). The ith interleaver block is filled into a table with Ir(i) rows and Nr columns. The data is written row-wise (from left to right). Therefore, each row corresponds to one RS codeword. The bytes are read column-wise (from top to bottom). The interleaver operation is demonstrated in 6-5 (except that there are Ir(i) rows instead of Ir). If the shortened last codeword mode is applied, then the last row might have fewer elements than Nr. In this case, the interleaver table is read column by column, skipping the empty elements of the table. The interleaver operation for the last interleaver block is demonstrated in Figure 6-6 (except that there are Ir(Ns0)rows instead of I'). 6.2.6.2.2.1 Dynamic Mode Calculations

N s0 and I r(i ) are determined by the following equations:

Total number of interleaver rows: Maximal number of rows per segment: Number of segments: Interleaver depth of first block:
0 I tot = ceil ( N f / N r ) .

I r ,max = floor ( Br / N r ) .
0 N s0 = ceil ( I tot / I r ,max ) 1 0 Ir = floor ( I tot / N s0 ) 1 0 M = N s0 ( I r + 1) I tot

1 No. of blocks with depth of I r : Then for segment i, I r

(i )

0 is calculated as follows ( i = 1...N s ):

1 i = 1,..., M I r , I r( i ) = 1 0 I r + 1, i = M + 1,..., N s

49

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.7 Scrambler (Randomizer)

The upstream modulator MUST implement a scrambler (shown in Figure 6-7) where the 15-bit seed value MUST be arbitrarily programmable. At the beginning of each burst, the register is cleared and the seed value is loaded. The seed value MUST be used to calculate the scrambler bit which is combined in an XOR with the first bit of data of each burst (which is the MSB of the first symbol following the last symbol of the preamble). The scrambler seed value MUST be configured in response to the Upstream Channel Descriptor from the CMTS. The polynomial MUST be x15 + x14 + 1.

SEED LSB

SEEDLOAD / FRAME RESET

SEED MSB

N = 15 DELAY ELEMENT 1 DELAY ELEMENT 2 DELAY ELEMENT 3 DELAY ELEMENT N-2 DELAY ELEMENT N-1 DELAY ELEMENT N

XOR

RANDOMIZER DATA INPUT XOR

RANDOMIZER DATA OUTPUT

Figure 6-7

Scrambler Structure

6.2.8 TCM Encoder

RS symbol interleaving is commonly included between the TCM and RS blocks to preserve coding gain in the presence of bursty errors produced at the output of the TCM decoder. This interleaver was not included in the original baseline S-CDMA proposal to reduce memory requirements at the expense of coding gain. In S-CDMA mode the CM MUST support trellis coded modulation for transmission of m = 1, 2, 3, 4, 5, and 6 bits per symbol with QPSK0, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM constellations, respectively. Support of TCM in the CMTS is optional. Figure 6-8 shows the employed 8-state TCM encoder. The encoding operation causes a mapping of m input bits into m+1 output bits for input into the symbol mapping block. The systematic convolutional encoder adds the coded bit x1 = s0 to the input bits im , i3 ,i2 ,i1 . For m = 1, only input bit i1 is used (i2 = 0), and encoding is reduced to rate-1/2 coding.

50

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

im : i3 i2 i1

xm+1 : x4 x3 x2 S-CDMA Framing symbol labels

s2

s1

s0=x1

Figure 6-8

Convolutional encoder

The initial state of the TCM encoder MUST be the zero state. The zero state MUST be reached again with the last encoded symbol. To return to the zero state from all possible Trellis paths, if m = 1 (QPSK) three tail symbols (nt = 3) MUST be generated with input bit i1 set to i1 = s1 . By inspection of Figure 6-8, after three symbols the state bits s2 , s1 , and s0 = x1 will be zero. Tail symbols are extra symbols, which carry no information. If m = 2, to return to the zero state from all possible Trellis paths, two tail symbols (nt=2) MUST be generated. The input bits i2 i1 MUST be set such that the zero state is reached after two symbols. If the first symbol is set to i2 = 0, i1 = s1 , and the second (final) symbol to i2 = s2 , i1 = s1 after these two symbols the state bits s2 , s1 , and s0 = x1 will be zero. If m 3, the uncoded bits im ,...,i3 MUST be used for information encoding, when this is possible. Otherwise, uncoded bits MUST be set to zero. The number of tail symbols carrying no information depends on the ending conditions and can vary between zero and two (0 nt 2).
6.2.8.1 Byte to TCM Symbol Mapping

The mapping of bytes to TCM symbols is done such that each byte is mapped entirely to the uncoded bits i m,...,i 3, or entirely to the convolutional encoder input bits i 2 i 1. The decision is made sequentially for each byte using the rule that the byte assignment should lead to the shortest packet of symbols including tail symbols, if the current byte were the last byte to be encoded. This rule results in the repetitive patterns of byte assignments to label bits shown in Figure 6-9 for m=1 to 6. In the figure bit i m is at the top and bit i 1 is at the bottom.1 The MSB (im) MUST be the first bit in the serial data fed into the uncoded input bits (i.e. im to i3). The MSB (i2) MUST be the first bit in the serial data fed into the coded input bits. Figure 6-10 illustrates the byte assignments for Trellis-coded 64QAM modulation by two examples. Notice that bytes are assigned in a repetitive pattern of five bytes. In the first example, Nf is divisible by five. In this case two tail symbols are appended. In the second example, Nf is not divisible by five and no tail symbols are required. The bits needed for returning to the zero state are available in symbols still carrying information.

1.

This paragraph updated per RFI2-N-02135 by RKV on 10/29/02.

51

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

m = 6 (128QAM)

1 2 3

m = 5 (64QAM)

1 3 1 2

4 5

m = 4 (32QAM)

m = 3 (16QAM) m = 2 (8QAM) m = 1 (QPSK)

1 1
1

3 2

Figure 6-9 Repetitive patterns of byte mapping to symbol map bits for TCM

zero fill bits 0 zero initial state

bits to return to zero state

redundant code bits zero final state

msb 1 msb 4 msb 2 msb 3 msb 5

msb 6

......... ......... .........

msb Nf-2

0
msb Nf-1

0 0 0

0 0 0

msb 8

......... ......... .........

msb Nf

x6 x5 x4 x3 x2 x1

np preamble symbols
msb 1 msb 4 msb 2 msb 3 msb 5 msb 8 msb 6

ni TCM symbols ......... ......... ............... .. .. ..

msb Nf msb Nf-2

nt = 2 tail symbols

0
msb Nf-1

0 0

ni TCM symbols, no tail symbols (nt = 0)

Figure 6-10

Example byte to bit assignment for 64 QAM

The CM MUST place the return-to-zero bits right after the last coded data sub-symbol, that is, the last coded subsymbol corresponding to the parity bytes of the last shortened or fixed codeword including any zero-filled codeword in the grant. The rest of the coded bits MUST be filled with zeros.1
52

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Figure 6-11 illustrates the placing of return-to-zero bits for 64QAM when the last transmitted byte is #1. The first two pairs of x2 and x3 are the return to zero bits, and the last empty coded pair is zero filled.

Uncoded bits u Zero fill bits 0 Bits to return to zero state r i5 i4 i3 i2 i1 u u u 0 r u u u r r u u 0 0 0 x6 x5 x4 x3 x2 x1

Figure 6-11 Example of return to zero bits followed by 0

6.2.9 Preamble Prepend

The upstream PMD sublayer MUST support a variable-length preamble field that is prepended to the data after they have been randomized, Reed-Solomon encoded, and TCM encoded. The first bit of the Preamble Pattern is the first bit into the symbol mapper (see Section 6.2.13). The first bit of the Preamble Pattern is designated by the Preamble Value Offset as described in Table 8-19, Section 8.3.3. The preamble is interleaved by the framer in S-CDMA mode. The preamble sequence MUST be programmable. For DOCSIS 2.0 bursts (bursts encoded using a Type 5 burst descriptor per Section 8.3.3), the preamble MUST use the QPSK0 or QPSK1 constellation (per Figure 6-18 and Figure 6-19) with preamble length 0, 2, 4, 6,..., or 1536 bits (maximum 768 QPSK symbols). For DOCSIS 1.x compatible bursts (Type 4 burst descriptor) that use QPSK modulation, the preamble and data MUST use the QPSK0 constellation with preamble length 0, 2, 4, 6,..., or 1024 bits (maximum 512 QPSK symbols). For DOCSIS 1.x compatible bursts (Type 4 burst descriptor) that use 16QAM modulation, the preamble and data MUST use the 16QAM constellation with preamble length 0, 4, 8, 12,..., or 1024 bits (maximum 256 16QAM symbols). The preamble length and value MUST be configured in response to the Upstream Channel Descriptor message transmitted by the CMTS.

1.

Section 6.2.8.1, second-to-last paragraph updated per RFI2-N-02111 by RKV on 10/29/02.

53

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.10

Modulation Rates

In TDMA mode, the CM upstream modulator MUST provide all modulations at 160, 320, 640, 1280, 2560 and 5120 ksym/sec. In S-CDMA mode, the CM upstream modulator MUST provide all modulations at 1280, 2560 and 5120 ksym/ sec. In TDMA mode, the CMTS upstream demodulator MUST be able to support demodulation at 160, 320, 640, 1280, 2560 and 5120 ksym/sec. In S-CDMA mode, the CMTS upstream demodulator MUST be able to support demodulation at 1280, 2560 and 5120 ksym/sec. This variety of modulation rates, and flexibility in setting upstream carrier frequencies, permits operators to position carriers in gaps in the pattern of narrowband ingress, as discussed in Annex G. The modulation rate for each upstream channel is defined in an Upstream Channel Descriptor (UCD) MAC message. All CMs using that upstream channel MUST use the defined modulation rate for upstream transmissions.
6.2.11 S-CDMA Framer and Interleaver

6.2.11.1 S-CDMA Framing Considerations

The S-CDMA mode of the PHY layer accepts data presented to it for transmission from the MAC layer. This data is presented as bursts of n mini-slots. These bursts are mapped within the PHY layer to a combination of spreading codes and time slots, in order to exploit the multi-dimensional spreading of information by the S-CDMA mode. There are various adjustable parameters in the upstream channel parameters and upstream burst attributes that allow controlling the mini-slot to physical layer mapping, as well as tuning the channel to accommodate a variety of channel conditions, noise characteristics, capacities, reliability levels, and latency requirements. When operating in S-CDMA mode, data is transmitted in two dimensions: codes and time. For this reason, data to be transmitted must be grouped into two-dimensional rectangular frames prior to transmission. At the physical layer, data is sent over an array of up to 128 spreading codes. There is a programmable number of spreading intervals per frame, as shown in Figure 6-13 below. A spreading interval is the time required to transmit one symbol per code across all 128 codes in S-CDMA mode. Note that the specific codes which are used and the details of the spreading operation are described in detail in Section 6.2.14, S-CDMA Spreader, on page 72. A burst from a particular CM may be transmitted on two or more codes in one or more frames. A frame may contain bursts transmitted simultaneously from multiple CMs (each on a separate subset of the codes) as defined by the MAP message.
6.2.11.2 Mini-slot Numbering

In normal operation, the MAC will request the PHY to transmit a burst of length n mini-slots, starting at minislot m, as defined by the MAP. All CMs and the CMTS MUST have a common protocol of how mini-slots are numbered, and how they are mapped onto the physical layer framing structure. This common protocol is obtained from information in the SYNC and Upstream Channel Descriptor (UCD) messages. (These messages

54

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

are described in Section 8.3.2, Time Synchronization (SYNC), on page 136, and Section 8.3.3, Upstream Channel Descriptor (UCD), on page 136.) Mini-slots are mapped onto frames starting at the first active code (usually code number 0), are numbered sequentially through the remainder of the frame (code number 127), and then wrap to the next sequential frame. Mini-slots are mapped onto a group of consecutive codes. The CMTS and the CMs require a common protocol for mini-slot numbering. For operation on a TDMA channel, this is achieved solely through recovery of the timestamp. Since the time duration of an S-CDMA frame is not necessarily a power-of-2 multiple of the 10.24 MHz reference, the timestamp rollover (at 232 counts) is not necessarily at an S-CDMA frame boundary. Therefore, an additional synchronization step is required. The CMTS MUST identify frame boundaries relative to the timestamp counter on a periodic basis. This is called the timestamp snapshot and must be sent in the UCD for each upstream S-CDMA channel. The CMTS MUST maintain a frame counter and a mini-slot counter, and MUST sample these values along with the timestamp, on a frame boundary, as shown below. The CMTS MUST obtain a new sample prior to sending each UCD message.

K spreading intervals code 127 Mini-slot m+62 code 126

K spreading intervals

K spreading intervals

Mini-slot m+125

Mini-slot m+188

...
code 3 Mini-slot m code 2 code 1 code 0 t

...
Mini-slot m+63

...
Mini-slot m+126

frame f

frame f+1

frame f+2

timestamp counts

t1

t2

t3

t4

timestamp count

minislot number

frame number

Included in UCD

32 bits

32 bits timestamp snapshot

8 bits

Figure 6-12 Timestamp Snapshot

Each CM MUST maintain a timestamp counter, mini-slot counter, and frame counter functionally identical to the CMTS. From the UCD message, the CM receives the CMTS timestamp snapshot and parameters from which it can calculate the number of time counts per S-CDMA frame. Using modulo arithmetic, the CM can then calculate accurate values for timestamp, mini-slot, and frame counters at any point into the future.

55

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM can then update its local mini-slot and frame counters at an appropriate timestamp counter value. At this point, the CM representation of mini-slots and frames are aligned with those in the CMTS. The CMTS and CM MUST implement a 32-bit timestamp counter, a 32-bit mini-slot counter, and an 8-bit frame counter, as follows:

The mini-slot counter MUST contain the value of the first mini-slot of the frame when it is sampled. It MAY
be incremented by the number of mini-slots per frame, once per frame interval. The mini-slot counter will use all 32 bits and mini-slot numbers will therefore range from 0 to 232 -1.

The only specified function for the frame counter is to reset the code hopping sequence at the frame 0 (modulo-256) boundary, as defined in Section 6.2.14.1, Code Hopping, on page 73. The frame structure above relates to the entire upstream and not necessarily to the transmission from a single CM. The codes are resources which are allocated to CMs over each S-CDMA frame. The assignment of codes to CMs is performed by the framer as it assigns a burst of symbols a particular order in the two-dimensional matrix of codes and time. This symbol sequencing is described in detail in Section 6.2.12.
6.2.11.2.1 Mini-slot Numbering Parameters in UCD

There are three parameters specified in the UCD that define mini-slot mapping: spreading intervals per frame, codes per mini-slot, and number of active codes.
Spreading intervals per frame The number of spreading intervals per frame, K, (along with the signaling rate), 1/Ts, define the time duration of an S-CDMA frame, Tfr.

Tfr = K * 128 * Ts Note that the code length in the above equation is always 128, regardless of how many codes are currently active. The valid range of the spreading intervals per frame parameter is 1 to 32.
Codes per mini-slot In conjunction with the spreading intervals per frame parameter, the codes per mini-slot (Cms) parameter defines the total number of symbols per mini-slot and therefore the mini-slot capacity. The mini-slot capacity, Sms, is given in symbols by the following expression:

Sms = K * Cms The lower limit on mini-slot capacity is 16 symbols (refer to Annex B). However, the mini-slot must also be large enough to allow the transmission of the largest-sized data PDU (including physical layer overhead) in 255 mini-slots (see Section 8.3.3). The upper limit on mini-slot capacity is not specifically constrained, but in general is governed by channel efficiency and MAC performance issues. The valid range of the codes per mini-slot parameter is 2 to 32.
Number of active codes The number of active codes parameter allows the number of codes used to carry data to be less than or equal to 128. When the number of active codes is less than 128, low numbered codes starting with code 0 are not used, as shown in Figure 6-14.

There are several reasons why it may be desirable to reduce the number of active codes:

Code 0 does not have the same spreading properties as the other codes and therefore under certain colored
noise conditions will degrade performance.

In extremely noisy plant conditions, a reduction in the number of active codes (along with the corresponding
increase in power per code for the remaining codes), can allow reliable operation at reduced capacities. Reduction in active codes from 128 to 64 results in a 3 dB improvement in SNR.
56

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The number of mini-slots per S-CDMA frame MUST be an integer. Therefore the codes per mini-slot and
number of active codes parameters MUST be chosen to result in an integral number of mini-slots per frame. The valid range of the number of active codes parameter is 64 to 128. A CMTS MUST support 126 and 128 active codes. A CM MUST support any non-prime number of active codes in the range of 64 to 128, inclusive.
Note: When the number of active codes is 64 or greater, the S-CDMA frame must consist of more than 1 mini-slot, since the number of codes per mini-slot must be in the range 2 to 32. This implies that the number of active codes must be non-prime. The prime numbers between 64 and 128 are 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, and 127.

6.2.11.2.2

Mini-slot Numbering Examples

A typical mini-slot numbering example is shown in Figure 6-13. In this example, there are two codes per minislot defined. The number of codes per mini-slot is an adjustable parameter (via the UCD) to allow flexibility in determining the effective capacity of each mini-slot.

K spreading intervals code 127 Mini-slot m+63 code 126

K spreading intervals

K spreading intervals

Mini-slot m+127

Mini-slot m+191

...
code 3 Mini-slot m+1 code 2 code 1 Mini-slot m code 0

...
Mini-slot m+65 Mini-slot m+64

...
Mini-slot m+129 Mini-slot m+128

frame f

frame f+1

frame f+2

Figure 6-13 Mini-slot Mapping with Two Codes per Mini-slot, 128 Active Codes

A second example, using three codes per mini-slot, is shown in Figure 6-14. Since it is required that there be an integral number of mini-slots per frame, the number of active codes has been restricted to 126 codes. In this example, a trade-off has been made to increase mapping flexibility at the expense of a small reduction in channel capacity (2/128).

57

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

K spreading intervals code 127 code 126 code 125 Mini-slot m+41

K spreading intervals

K spreading intervals

Mini-slot m+83

Mini-slot m+125

...
code 7 code 6 code 5 code 4 code 3 code 2 code 1 code 0 Mini-slot m Mini-slot m+1

...
Mini-slot m+43

...
Mini-slot m+85

Mini-slot m+42

Mini-slot m+84

frame f

frame f+1

frame f+2

Figure 6-14 Mini-slot Mapping with Three Codes per Mini-slot, 126 Active Codes

There is no implication that physical layer processing is performed on a per mini-slot basis. As in a TDMA channel, the physical layer is concerned only with the burst start time (mini-slot number) and the burst length.
6.2.11.3 Transmission Time

Ideally, all the mini-slots contained in one S-CDMA frame are received simultaneously. These mini-slots may be transmitted from a single CM or may be transmitted from multiple CMs, as defined by the bandwidth allocation MAP message and the mini-slot mapping configuration settings (from the UCD). Note that a single CM may have more than one allocation active in a single S-CDMA frame.
6.2.11.4 Latency Considerations

S-CDMA frame timing is derived directly from (is phase locked to) the 10.24 MHz CMTS master clock. Based on the allowable signaling rates and the fact that there are 128 signaling periods in a spreading interval, the S-CDMA frame time MUST always be a multiple of 25 sec. Selecting the number of spreading intervals per frame and the signaling rate therefore exactly define the S-CDMA frame duration. As a specific example, a burst profile defined with 10 spreading intervals per frame with a signaling rate of 2.56 Mbaud would result in a frame duration of 500 sec. The amount of additional upstream latency added by the use of S-CDMA mode is approximately one S-CDMA frame with the exact value described in Section 6.2.17.

58

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.11.5

Spreader-off Bursts for Maintenance on S-CDMA channel

Spreader-off bursts are defined as bursts on an S-CDMA channel whose attributes specify that the spreader be turned off. For a spreader-off burst, both the S-CDMA framer and S-CDMA spreader are bypassed. The Initial Maintenance burst type MUST be specified (via UCD) to use spreader-off bursts. The Station Maintenance burst type MAY be specified (via UCD) to use spreader-off or spreader-on bursts. The CM MUST support both spreader-on and spreader-off modes for Station Maintenance bursts. All remaining IUC burst types MUST be specified (via UCD) to use spreader-on bursts. The S-CDMA channel will be programmed (via UCD) for Cms codes per mini-slot, p number of active codes, K spreading intervals per S-CDMA frame, and a resultant s minislots per frame, where s=p/Cms. Then each S-CDMA frame, where a transmission with the spreader off is to occur, will contain exactly s minislots, where each mini-slot consists of Cms*K symbols. In the case where the number of active codes (p) is less than 128, the frame will still contain exactly s mini-slots, where each mini-slot consists of Cms*K symbols. The first mini-slot of a frame will start with the first symbol of the frame. If a burst spans multiple frames, the burst will start relative to the first frame and continue without interruption into the next frame. Spreader-off bursts for Station Maintenance Regions (IUC 4) MUST be padded with zero data symbols from the end of the R-S encoded data until the end of the burst as defined by the burst boundaries of Section 6.2.5.1.1. Spreader-off bursts for Initial Maintenance Regions (IUC3) MUST be padded with zero data symbols from the end of the R-S encoded data until the end of the burst as defined by the burst boundaries of Section 6.2.5.1.1. Differential encoding and R-S byte interleaving MUST NOT be used with spreader-off bursts on S-CDMA channels.1

1.

This paragraph updated by RKV per RFI2-N-02135 on 10/29/02, per RFI2-N-02173 on 10/30/02.

59

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

K spreading intervals code 127 Mini-slot m+63 code 126

128*K modulation intervals

K spreading intervals

Mini-slot m+191

code 3 Mini-slot m+1 code 2 code 1 Mini-slot m code 0

Mini-slot m+127

Mini-slot m+64

Mini-slot m+65

Mini-slot m+66

Mini-slot m+67

Mini-slot m+68

Mini-slot m+69

Mini-slot m+129

Mini-slot m+128

frame f Spreader-on frame

frame f+1 Spreader-off frame

frame f+2 Spreader-on frame

Figure 6-15 S-CDMA and Spreader-off Intervals

The CMTS scheduler MUST ensure that the spreader-off interval is aligned to the start of an S-CDMA frame, occurs completely within one or more S-CDMA frames, and MUST ensure that no spreader-on bursts are scheduled during these same frames. The CMTS scheduler MUST grant at most one spreader-off burst per CM per frame. It is the responsibility of the CMTS to allocate mini-slots to the NULL SID, as required to prevent interference between bursts (i.e., before and after spreader-off bursts when the CM might not be sufficiently synchronized). Specifically, the CMTS MUST issue a NULL grant (to the NULL SID) of 1 mini-slot immediately before each spreader-off burst, which corresponds to either Station Maintenance, or Unicast Initial Maintenance, and MUST also issue a NULL grant (to the NULL SID) of 1 mini-slot or guarantee a quiet minislot (dead time), immediately after these bursts, and before a spreader-on interval starts.1 During spreader-off bursts on S-CDMA channels when less than 128 active codes are in use, the spreader-off frame will contain quiet mini-slots (dead time) equal to the number of inactive codes.

1.

Added last sentence to this paragraph per ECN RFI2-N-02227 by GO on 03/20/03.

60

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.11.6

Limiting the Number of Codes Assigned to a CM 1

In certain situations, it may be useful for a CMTS to limit the number of codes that a single CM is required to simultaneously transmit. By doing so, the CM can divide its transmit power across a smaller number of codes than it would otherwise, which results in a higher power per code. This can be especially useful when a population of CMs is subject to an unusually high upstream attenuation, such that the CMs are transmitting at the maximum total transmit power. When the value of Maximum Scheduled Codes is set less than the Number of Active Codes, the CMTS MUST ensure that each compliant CM will not, via scheduled grants or multicast IEs with IUC=1, exceed its assigned Maximum Scheduled Codes transmission limit in any S-CDMA frame. To accomplish this, the CMTS must avoid scenarios that would potentially cause the CM to attempt to transmit on more codes than its Maximum Scheduled Code limit would allow. For instance, the CMTS must manage the number of codes assigned to contention IEs with IUC=1 in all frames. In frames where IEs with IUC=1 could not be inserted by a CMTS because of a CM's Maximum Scheduled Codes, the CMTS MAY provide multicast IEs with IUC=2 for contention request opportunities. CMs with Maximum Scheduled Codes enabled MUST be configurable via SNMP to control usage of IEs with IUC=2 [DOCSIS5]. By default, CMs with Maximum Scheduled Codes Enabled MUST NOT use IEs with IUC=2. Maximum Scheduled Codes MUST be equivalent to an integer number of minislots. A CM MUST NOT concatenate packets beyond the size permitted by the S-CDMA Maximum Scheduled Codes, if Maximum Scheduled Codes specified in the RNG-RSP is not 0. This is in order to reduce fragmentation overhead, which can become significant as the number of codes reduces. A CM receiving a Maximum Scheduled Codes value MUST be capable of fragmenting any MAC frame, including frames transmitted prior to completing the registration process. If the CM is using a Maximum Scheduled Codes value, the CM MUST fragment when necessary on the primary service flow even if the Request/Transmission Policy in the configuration file disallows fragmentation on the primary service flow. To support 1.0 style configuration files, a CM and CMTS using the Maximum Scheduled Codes value SHOULD support fragmentation in 1.0 mode. If the CM requests a UGS flow to provide unsolicited grants sized greater than the value permitted by the Maximum Scheduled Codes value, the CMTS SHOULD reject the UGS flow. If a UGS flow is requested to provide unsolicited grants sized greater than the value permitted by the Maximum Scheduled Codes value, the CM SHOULD reject the UGS flow.
6.2.12 S-CDMA Framer

The S-CDMA framer maps mini-slots to spreading codes and spreading intervals by arranging them as symbols within an S-CDMA frame. It also performs an interleaving function, to provide protection against impulse noise. The S-CDMA framer's function of mapping mini-slots to spreading codes and spreading intervals is illustrated in Section 6.2.11, S-CDMA Framer and Interleaver, on page 54. As previously described, an S-CDMA frame is defined by the number of spreading intervals per frame, codes per mini-slot, and number of active codes. The framer uses this information to map the mini-slots of a transmission into frames. The framer maps complete grants so that any interleaving which is performed is not constrained by individual mini-slot boundaries. The framer MUST align transmissions to begin and end on mini-slot boundaries. Within a transmission, the framer numbers the symbols or bits and allocates them to codes and spreading intervals independent of the mini-slot mapping. When using TCM encoding, the TCM encoded symbols from the TCM encoder are split into two subsymbols consisting of the coded subsymbol which is the two bits and the parity generated from the convolution encoder, and the uncoded subsymbol consisting of the rest of the bits. When TCM is off, the randomizer output is treated as a continuous bit stream ignoring byte boundaries, as specified in Section 6.2.13, Symbol Mapping, on page 64."

1.

Added this subsection per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.

61

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.12.1

Subframe Definition

The S-CDMA framer performs interleaving independently of mini-slots. Interleaving is constrained by subframe boundaries, where a subframe is a rectangular subset of an S-CDMA frame over which interleaving is performed. A subframe is normally an integer number of Reed-Solomon codewords to enhance protection from impulse noise. Given an S-CDMA frame which is N active codes by K spreading intervals, a subframe is defined to be a group of R contiguous rows, where R is an integer in the range from 1 to N. A subframe is defined to exist entirely within a single frame and does not span multiple frames. Each subframe contains R*K locations and each location holds one symbol used for mapping and spreading. Each transmission MUST start with a new subframe. The last subframe of a frame MUST be shortened to fit entirely within a single S-CDMA frame, and the last subframe of a transmission MUST be shortened to fit within the granted mini-slots. In both of these cases the subframe will be only R' rows instead of R rows where R'R. Figure 6-16 shows a subframe consisting of R rows and K spreading intervals within an S-CDMA frame.

frame length(K)
Other subframes

Number of Active Codes (N) R codes

Row R

Row 2 Row 1

Other subframes

(K-1)

Spreading Interval

Figure 6-16

Subframe structure

The parameters that define a subframe and the numbering within a subframe are codes per subframe and interleaver step size. These two parameters are specified as part of the burst attributes and can vary between burst profiles. These parameters determine the size of the subframe, and also how the subframe is filled with symbols. The valid range for codes per subframe is from 1 to the number of active codes in use. The parameter interleaver step size is used while putting TCM coded subsymbols and preamble symbols into the frame. Both of these types of symbols fill in subframes first along a row, and the interleaver step size parameter indicates the spreading interval increment to be used while filling in the symbols.
6.2.12.2 Framer Operation

The symbols entering the framer MUST be placed into the framer according to the following sets of rules. There are two sets of rules which apply to different types of input symbols. Preamble symbols and coded TCM subsymbols follow one set of rules, while non-TCM encoded symbols and uncoded TCM subsymbols follow the second set of rules. The rules are specified in the following sections.

62

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.12.2.1

Rules for Preamble and Coded TCM Symbols

The preamble (whether TCM is on or off) and the coded TCM subsymbols MUST fill in the frame according to the following rules. 1. The first symbol or subsymbol MUST be placed in the first spreading interval of the first row of the granted mini-slot. In Figure 6-16, Subframe structure, on page 62 this would be row 1, spreading interval 0 assuming that this is the start of the first mini-slot of the grant. 2. Subsequent symbols MUST be placed at the next available spreading interval Interleaver Step Size away from the previous. For instance if the previous symbol was placed at spreading interval X, the next symbol is placed at X + Interleaver Step Size. 3. If the addition of the Interleaver Step Size results in the next location being beyond the end of the frame, the next location MUST be located modulo the frame length. For instance if J + Interleaver Step Size = K+1, then the next location would be spreading interval 1. 4. If the next location is already occupied, then the spreading interval MUST be incremented by 1 until the next unoccupied spreading interval is located. For instance if the desired location is spreading interval X and spreading interval X is occupied, but not X+1, then X+1 would be used. 5. After filling all of the spreading intervals of a single row, the operation is repeated starting with the next row and step 1 above. 6. After placing all of the preamble and data symbols into the frame, the remaining symbols in the burst, as defined by the burst boundaries of Section 6.2.5.1.1, MUST be filled with zero data symbols which will be mapped to non-zero power.1 7. Any locations that have only a TCM uncoded subsymbol MUST be filled with zero bits in the coded subsymbol portion before mapping and spreading.
6.2.12.2.2 Rules for Uncoded Symbols and the Uncoded TCM Subsymbols

Symbols without TCM encoding and uncoded TCM subsymbols MUST fill subframes according to the following rules. 1. The first symbol MUST be placed in the first available code of the first available spreading interval of the subframe after the preamble has been placed into the frame. The symbols are filled from row 1 through row R and after filling a spreading interval, the next spreading interval is filled from row 1 through row R. 2. Uncoded symbols and the uncoded portion of TCM symbols MUST NOT be placed in the same frame location (spreading interval, code) as a preamble symbol. For instance if there is a preamble symbol in row X, spreading interval Y; and row (X+1), spreading interval Y is unused, the symbol should be placed into row (X+1), spreading interval Y. 3. Subsequent symbols MUST be placed in the next available row of the first available spreading interval of the current subframe. This causes the subframe to be filled column-wise bottom to top and then from left to right. For instance if row 1 through row R of spreading interval X is already occupied, the next symbol would be placed into the first available row of spreading interval X+1. 4. After completely filling a subframe, the next subframe MUST begin as specified in step 1 above. 5. The number of rows contained in the last subframe of a frame MUST be reduced to fit entirely within the frame if there is not adequate space for a full subframe.

1.

Section 6.2.12.2.1, numbered paragraph 6 updated per RFI2-N-02135 by RKV on 10/29/02.

63

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6. The number of rows contained in the last subframe of a grant of mini-slots, MUST be reduced to fit entirely within the granted mini-slots if there is not adequate space for a full subframe within the grant. 7. After placing all of the data symbols into the frame, the remaining symbols in the burst, as defined by the burst boundaries of Section 6.2.5.1.1, MUST be filled with zero data symbols which will be mapped to nonzero power.1 8. Any locations that have only a TCM coded subsymbol MUST be filled with zero bits in the uncoded subsymbol portion before mapping and spreading.
6.2.12.2.3 Subframe Example

Figure 6-17 below shows an example which follows the above specified rules. Each box in the figure represents a symbol which can contain either a preamble symbol, an uncoded symbol when not using TCM, or an uncoded and coded subsymbol when using TCM. In this example there are 9 spreading intervals in the frame, 3 rows for the subframe, an Interleaver Step Size of 3, and the preamble is 4 symbols. Based on these parameters the subframe would be filled as shown. If the data is TCM encoded, the Cs would represent locations of the coded subsymbols and the Us represent the locations of the uncoded subsymbols. If the TCM is not used, then the symbols would be placed according to the Us only.

frame length 3 rows

U1 C14 U0 C5 P0 U3 C17 U2 C8 P3 U6 C20 U5 C11 U4 C2 U8 C15 U7 C6 P1 U11 C18 U10 C9 U9 C0 U14 C21 U13 C12 U12 C3 U16 C16 U15 C7 P2 U19 C19 U18 C10 U17 C1 U22 C22 U21 C13 U20 C4

step=3
Figure 6-17 Symbol Numbering Without TCM

6.2.12.2.4

Frame Transmission

Once a frame is completed and ready for transmission, the symbols MUST be mapped and spread in spreading interval order. This means that spreading interval 0, as described in Figure 6-16, MUST be the first spreading interval on the wire. For TCM encoded data, the coded and uncoded subsymbols from each location in the frame MUST be combined to create complete symbols before mapping and spreading. This corresponds to creating a new symbol where the coded portion of the symbol is Ci and the uncoded portion is Uj. The preamble symbols remain intact.
6.2.13 Symbol Mapping

The modulation mode is configurable via MAC messages. Differential encoded QPSK and 16QAM are available for TDMA channels. QPSK, 8QAM, 16QAM, 32QAM, and 64QAM are available for TDMA and S-CDMA channels. TCM encoded QPSK, 8QAM, 16QAM, 32QAM, 64QAM and 128QAM are available for S-CDMA channels. The symbols transmitted in each mode and the mapping of the input bits to the I and Q constellation MUST be as defined in Table 6-3. In the table, x1 represents the LSB of each of the symbol maps and x2, x3, x4,

1.

Section 6.2.12.2.2, numbered paragraph 7 updated per RFI2-N-02135 by RKV on 10/29/02.

64

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

x5, x6 and x7 represents the MSB for QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM respectively. The MSB MUST be the first bit in the serial data into the symbol mapper and it MUST be mapped to the MSB of the symbol map. The number of data bytes may not map into an integer number of symbols. In this case, the last symbol MUST be padded with zero bits in the LSB locations after all data bits are processed. All constellations are defined on a common integer grid in Figure 6-18. This defines each QAM symbol with 5bit values on each (I and Q) axis. The relative symbol amplitudes defined by the grid MUST be maintained across all constellations. Different constellations may be used, for example, in different burst profiles, in preamble and data symbols within the same burst, and in modulating different spreading codes within a frame. In Figure 6-18, Eav denotes the average constellation energy for equally likely symbols. For each constellation the integer values of Eav and differences in dB compared to 64QAM, Gconst, are given. The QPSK0 constellation is employed for low-power preamble and QPSK data symbols. Use of QPSK1 is restricted to high-power preamble symbols.
Table 6-3
QAM Mode QPSK 8QAM 16QAM 32QAM 64QAM 128QAM x2x1 x3x2x1 x4x3x2x1 x5x4x3x2x1 x6x5x4x3x2x1 x7x6x5x4x3x2x1

I/Q Mapping
Input bit Definitions

The upstream symbol constellations MUST be as shown in Figure 6-18. The upstream QPSK Gray-coded and differential symbol mapping MUST be as shown in Figure 6-19 The upstream 8QAM symbol mapping MUST be as shown in Figure 6-20. The upstream 16QAM Gray-coded symbol mapping MUST be as shown in Figure 6-21. The upstream 16QAM differential symbol mapping MUST be as shown in Figure 6-21. The upstream 32QAM symbol mapping MUST be as shown in Figure 6-22. The upstream 64QAM Gray-coded symbol mapping MUST be as shown in Figure 6-23. The TCM symbol mapping used for S-CDMA are shown in Figure 6-24 through Figure 6-26. The upstream QPSK TCM symbol mapping MUST be as shown in Figure 6-24. The upstream 8QAM TCM symbol mapping MUST be as shown in Figure 6-24. The upstream 16QAM TCM symbol mapping MUST be as shown in Figure 6-25. The upstream 32QAM TCM symbol mapping MUST be as shown in Figure 6-25. The upstream 64QAM TCM symbol mapping MUST be as shown in Figure 6-26.

65

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The upstream 128QAM TCM symbol mapping MUST be as shown in Figure 6-26. If differential quadrant encoding is enabled, then the currently-transmitted symbol quadrant is derived from the previously transmitted symbol quadrant and the current input bits via Table 6-4. If differential quadrant encoding is enabled, the upstream PMD sublayer MUST apply these differential encoding rules to all transmitted symbols (including those that carry preamble bits). Differential quadrant encoding is only available for QPSK and 16QAM on TDMA channels. In Table 6-4, I(1)Q(1) refers to x2x1 and x4x3 from Table 6-3 for QPSK and 16QAM cases respectively.
Table 6-4 Definition of Differential Quadrant Coding
Current Input Bits I(1) Q(1) 00 00 00 00 01 01 01 01 11 11 11 11 10 10 10 10 0 0 0 0 90 90 90 90 180 180 180 180 270 270 270 270

Quadrant Phase Change

MSBs of Previously Transmitted Symbol 11 01 00 10 11 01 00 10 11 01 00 10 11 01 00 10

MSBs for Currently Transmitted Symbol 11 01 00 10 01 00 10 11 00 10 11 01 10 11 01 00

66

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

QPSK0: Eav = 128 (Gconst = -1.18 dB rel to 64QAM) QPSK1: Eav = 288 (Gconst = +2.34 dB)
Imaginary part (quadrature) +15 +12 +8 +12

8QAM-DS: Eav = 160 (Gconst = -0.21 dB)

QPSK1 QPSK0

Real part (in-phase) 0

+4

-4 -8 -12 -15 -15 -12 -8 0 +8 +12 +15 -12 -4 +4 +12 -12

16QAM-SQ: Eav = 160 (Gconst = -0.21 dB)

+12

32QAM-DS: Eav = 168 (Gconst = 0 dB)

+14 +10 +6 +2 -2 -4 -6 -10 -12 -14

+4

-12

-4

+4

+12

-14

-10

-6

-2

+2

+6

+10

+14

64QAM-SQ: Eav = 168 (Gconst = 0 dB)

+14 +10 +6 +2 -2 -6 -10 -14 -14 -10 -6 -2 +2 +6 +10 +14

128QAM-DS: Eav = 170 (Gconst = 0.05 dB)

+15 +13 +11 +9 +7 +5 +3 +1 -1 -3 -5 -7 -9 -11 -13 -15 -15-13-11 -9 -7 -5 -3 -1 +1 +3 +5 +7+9+11+13+15

Figure 6-18 Symbol Constellations

67

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Q
Label bits x2x1 (I,Q) 01 11

00

10

Figure 6-19 QPSK Gray and Differential Symbol Mapping

Q
Label bits x3x2x1 111 101

110

011

I
010 001

Gray-code violation

100

000

Figure 6-20

8QAM Symbol Mapping

68

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Label bits x4x3x2x1

Q
0111 0101 1101 1111 0111 0110

Q
1101 1111

0110

0100

1100

1110

0101

0100

1100

1110

I
0010 0000 1000 1010 0010 0000 1000 1001

0011

0001

1001

1011

0011

0001

1010

1011

(a) Gray-Coded Mapping (I,Q,I,Q)

(b) Mapping for Differential Encoding

Figure 6-21 16QAM Symbol Mapping

Q
11111 11101 11010

Label bits x5x4x3x2x1

10010
2

10111

11011

01010

10110
2

11001 11000

01011

01110

11110
2

01001

01111

00110 00010

01000 10000
2

01101

00111

01100
2

00101

00011 10011

10100 10101

00100
2

00001

11100

00000

10001

2 Gray-code violation

Figure 6-22 32QAM Symbol Mapping

69

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Label bits x6x5x4x3x2x1 (I,Q,I,Q,I,Q)

011100 011110 010110 010100 110100 110110 111110 111100

011101 011111 010111 010101 110101 110111 111111 111101

011001 011011 010011 010001 110001 110011 111011 111001

011000 011010 010010 010000 110000 110010 111010 111000

I
001000 001010 000010 000000 100000 100010 101010 101000

001001 001011 000011 000001 100001 100011 101011 101001

001101 001111 000111 000101 100101 100111 101111 101101

001100 001110 000110 000100 100100 100110 101110 101100

Figure 6-23

64QAM Symbol Mapping

Binary labels x 2x1

Binary labels x 3x2x1

111 01 00 010 000

101

001 10 11 100 110

011

Figure 6-24

QPSK and 8QAM TCM Symbol Mapping

70

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Octal labels o 2o1 (= bin. labels x 4 x3x2x1)

Octal labels o 2o1 (= bin. lab. x 5x4x3x2x1 )

23 13 16 07 12 26 15 04 01 00 15 10 33 17 02 03 06 36 25 10 05 14 11 20 12 04 02 34

31 16 07 00 01 06 17 30

13 24 05 32 03 14 35 22

21

37

11

27

Subset B0

Subset B1

Figure 6-25 16QAM and 32QAM TCM Symbol Mapping

64QAM: octal labels o 2o1 (= bin. lab. x 6x5x4x3x2x1)

128QAM: octal labels o 3o2o1 (= bin. lab. x 7x6x5x4x3x2x1 ) 42 45 76 61 22 25 56 41

103 111 173 141 043 051 133 101 106 114 176 144 046 054 136 104 135 127 165 157 075 067 125 117 130 122 160 152 070 062 120 112 053 061 023 031 013 021 163 171 056 064 026 034 016 024 166 174 045 077 015 007 005 037 155 147 040 072 010 002 000 032 150 142 143 151 033 001 003 011 073 041 146 154 036 004 006 014 076 044 175 167 025 017 035 027 065 057 170 162 020 012 030 022 060 052 113 121 063 071 153 161 123 131 116 124 066 074 156 164 126 134 105 137 055 047 145 177 115 107 100 132 050 042 140 172 110 102

43 54 27 20 63 74 47 40

46 51 32 35 66 71 52 55

77 70 13 04 17 10 33 24

62 65 16 01 02 05 36 21

23 34 07 00 03 14 67 60

26 31 12 15 06 11 72 75

57 50 73 64 37 30 53 44

Subset B0

Subset B1

Figure 6-26 64QAM and 128QAM TCM Symbol Mapping

71

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.14

S-CDMA Spreader

The basis of signal transmission with S-CDMA is direct-sequence spread-spectrum modulation. S-CDMA employs a family of orthogonal digital code words, called spreading codes, to simultaneously transmit up to 128 modulation symbols. In each spreading interval, a vector, Pk, is transmitted such that: Pk = Sk*C, where Sk is a vector, [sk,127, sk,126,..., sk,0], of modulation symbols on the integer grid of Section 6.2.13 to be transmitted in spreading interval k, and C is a matrix, x 1 x 127 x2 = x1

c 127, 127 c 127, 126 c 127, 0 C = c 126, 127 c 126, 126 c 126, 0
c 0, 0

x2 1 x3 1 x1 1 1 1

c 0, 127

c 0, 126

x 127 x 126 1 1 1

where the rows of C are the 128 spreading codes such that Code(j) = [cj,127, cj,126,..., cj,0]. The result of the spreading operation is the transmission vector Pk which has 128 elements, [pk,127, pk,126,..., pk,0], where each element is transmitted at the signaling rate, with element pk,0 transmitted first in time. The first element S0 into the spreader is defined as follows. As a point of reference, for 128 allocated codes, and considering the first column of the framer (k = 0), S0 is the first symbol in time to enter the framer, occupies the lower left element of the framer, and is the first element into the spreader. The set of orthogonal codes used for the spreading operation is quasi-cyclic and consists of values which are either +1 or -1. Code(0) consists of 128 elements all of which have value of +1. For each of the other spreading codes Code(j), the element cj,0 is -1 and the remaining elements are obtained by a cyclic shift of a sequence x as is shown in the above matrix in this section. The sequence xi is defined such that the elements corresponding to the following set of indices are equal to -1: {2 3 4 5 6 7 9 10 11 13 16 17 18 19 20 21 25 26 28 30 31 33 34 35 37 39 40 41 49 51 52 55 56 59 60 61 65 66 67 69 72 73 74 77 78 79 81 84 90 92 94 97 100 101 103 106 109 110 111 114 117 119 121}; The remaining elements of Code(1) have a value of +1. Each Code(j) is obtained by cyclic shift to the left (in the direction of increasing indices) of Code(j-1) where the element, cj,0, has a value of -1 and does not take part in the cyclic shift. Although each code is defined to have equal power, the spread symbols may have slightly unequal power since the symbols at the input to the spreader have varying values of Eav according to the integer symbol grid of Section 6.2.13. If a CM has not been assigned to use a particular code, j, at a spreading time interval, k, then in its computation of its transmission vector Pk, it will set sk,j to numerical zero. The assignment of codes to the CM is performed by the framer as it assigns a burst of symbols a particular order in the two-dimensional space of codes and time. This symbol sequencing is described in detail in Section 6.2.12. The I and Q components of the symbols are spread using the same spreading code.

72

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

It is also important to note that in the matrix multiply of the equation above and subsequent CM processing prior to the D/A, there is an essential clipping operation wherein --- as an example --- filtered (pulse shaped) elements of Pk in excess of some vendor-specific absolute value are clipped (retaining complex angle) to this absolute value. This non-linear operation, deviating from the equation above and the subsequent linear processing prior to the D/A, is essential for meeting spurious emission and MER requirements safely and efficiently while operating at the highest CM average transmit power levels (see Table 6-8, User Unique Burst Parameters, on page 85).
6.2.14.1 Code Hopping

Code hopping refers to a systematic re-ordering of the rows of the spreading matrix, C, at each spreading interval, k. The code-hopping algorithm uses a pseudo-random number, lfsr_out(k), to determine a cyclic shift of the rows of the matrix C. When the number of active codes equals 128, the code hopping algorithm uses all codes. When the number of active codes is less than 128, the code hopping algorithm hops only over the cyclic codes (Code(0), the all 1s code, is excluded). The generalization of the spreading matrix at spreading interval, k, is given by (where matrix elements, cj,i are as defined above in Section 6.2.14): c f ( k, 127 ), 127 c f ( k, 127 ), 126 c f ( k, 127 ), 0 Ck = c f ( k, 126 ), 127 c f ( k, 126 ), 126 c f ( k, 126 ), 0
c f ( k, 0 ), 127 c f ( k, 0 ), 126 c f ( k, 0 ), 0

where,

128 Active Codes 0 i 127 mod ulo((128 lfsr _ out (k ) + i ),128), f (k , i) = mod ulo (( 126 lfsr _ out ( k ) i ), 127 ) 1 128 Active Codes 1 i 127 + + <
In S-CDMA mode, the CM MUST support code-hopping. Note that when the number of active codes is less than 128, the unused codes are those starting with matrix index 0. In this case, the code hopping continues to hop over all of the codes except for Code(0), even if the number of active codes is less than 127. The pseudo-random number generator which determines the spreading matrix reordering is the linear-feedback shift register (LFSR) which is shown in Figure 6-27. In order to align the CM's code-hopping pseudo-random sequence with that at the CMTS, the pseudo random generator must output the following value at the first spreading interval of each frame: lfsr_out(frame_number * spreading_interval_per_frame) where lfsr_out(k) is the value of lfsr_out after k shifts following the code hopping seed load into the LFSR.1 (The description of the frame counter and the procedures for its synchronization are contained in Section 6.2.11.2, Mini-slot Numbering on page 54). At this reset, a 15-bit initialization value (seed) is loaded into the shift register and is used at the first spreading interval. Then at each subsequent spreading interval, k, a new bit is shifted into the LFSR producing a new 7-bit value, lfsr_out(k). This value is used, with bit 7 as the MSB, to compute the spreading matrix indices as given by the equation above. Note that the code hopping mechanism

1.

Text from In order to align to this footnote, updated per RFI2-N-02123 by RKV on 10/29/02.

73

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

(LFSR, spreading interval index) is advanced every spreading interval (128 modulation intervals) in both spreader-on and spreader-off frames.

Initialization value (seed)

10

11

12

13

14

15

lfsr_out modulo(127) +1

modulo(128) or

Random Offset

Figure 6-27

Code Hopping Random Number Generator

The 15-bit seed value is configured in response to the Upstream Channel Descriptor message from the CMTS.
6.2.15 Transmit Pre-Equalizer

A transmit pre-equalizer of a linear equalizer structure, as shown in Figure 6-28, MUST be configured by the CM in response to the Ranging Response (RNG-RSP) message transmitted by the CMTS. There are two modes of operation for the pre-equalizer of a CM: DOCISIS 1.1 mode, and DOCSIS 2.0 mode. In DOCSIS 1.1 mode, the CM MUST support a (T)-spaced equalizer structure with 8 taps; the pre-equalizer MAY have 1, 2 or 4 samples per symbol, with a tap length longer than 8 symbols. In DOCSIS 1.1 mode, for backwards compatibility, the CMTS MAY support fractionally spaced equalizer format (T/2 and T/4). In DOCSIS 2.0 mode, the pre-equalizer MUST support a symbol (T)-spaced equalizer structure with 24 taps. In DOCSIS 1.x-only logical channels the CM and the CMTS MUST use DOCSIS 1.1 mode. In DOCSIS 2.0-only logical channels the CM and the CMTS MUST use DOCSIS 2.0 mode. In DOCSIS 1.x/2.0 mixed logical channels the CM and the CMTS MUST use DOCSIS 1.1 mode from initial ranging until DOCSIS 2.0 is activated in the registration process (if it is activated), and MUST use DOCSIS 2.0 mode after DOCSIS 2.0 is activated.

74

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

I-Q I-Q Input Input

F1

Z-R

Z-R

Z-R

Z -1

Z -1

Z -1

...
F4

Z-R

Z-R

Z -1

Z -1

...
F6

Z-R

Z -1

F2

F3

F5

FN

F1

F2

F3

F4

F 17

F 18

F 24

I-Q Output

R = T, T/2, T/4

...

...

Equalizer Output

Figure 6-28

Transmit Pre-Equalizer Structure

The RNG-RSP MAC message carries the CM transmit equalization information, and may instruct the CM to either convolve the equalizer coefficients or (in DOCSIS 2.0 mode only) load them directly (refer to Section 8.3.6.1, Encodings, on page 151). When the CM is instructed to convolve the transmit equalizer coefficients, it MUST convolve the coefficients sent by the CMTS in the RNG-RSP with the existing coefficients to get the new coefficients. After convolving, the CM MUST truncate the convolution result such that 24 taps (8 taps in DOCSIS 1.1 mode) remain after the truncation, with the main tap located at the tap designated by the last RNG-RSP received by the CM. The operation of the convolution is formulized by the following equation:
min ( 24 L m+1 Fn
m+1

,n+L L

m+1

1) m Fn k + Lm Lm + 1 F m+1 , k+L

=
k = max ( 1 L

m+1

n=1...24

,n+L L

m+1

24 )

where: F n are the coefficients prior to the convolution are the coefficients after the convolution Fn are the coefficients sent from the CMTS F n L is the main tap location prior to the convolution L
m+1 m m+1 m

is the main tap location after the convolution as dictated by the CMTS

When the CM is instructed to load the transmit equalizer coefficients it MUST load the coefficients sent by the CMTS into the pre-equalizer coefficients after proper normalization, if necessary. In DOCSIS 1.x-only channels, in response to an initial ranging request and periodic ranging requests prior to CM registration, when the CMTS sends the pre-equalizer coefficients, the CMTS MUST compute and send them with an equalizer length of 8 and in T-spaced format, where T is the modulation interval. After registration, the CMTS MAY use a fractionally spaced equalizer format (T/2- or T/4-spaced) with a longer tap length to match the CM pre-equalizer capabilities that the CMTS learned from the REG-REQ message modem capabilities field. See Section 8.3.8.1.1, Modem Capabilities, on page 158 for proper use of the modem capabilities field. In DOCSIS 2.0-only channels, the CMTS MUST compute and send the pre-equalizer coefficients with an equalizer length of 24 and in T-spaced format at all times. In DOCSIS 1.x/2.0 mixed logical channels, in response to an initial ranging request and periodic ranging requests prior to CM registration, when the CMTS sends the pre-equalizer coefficients, the CMTS MUST compute and send them with an equalizer length of 8 and in T-spaced format. After registration, if the DOCSIS 1.1 mode is activated, the CMTS MAY use a fractionally spaced equalizer format (T/2- or T/4-spaced) with a

75

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

longer tap length to match the CM pre-equalizer capabilities that the CMTS learned from the REG-REQ message modem capabilities field. If DOCSIS 2.0 is activated, the CMTS MUST use a T-spaced equalizer structure with 24 taps. If the first update of the pre-equalizer after the activation of DOCSIS 2.0 uses convolve mode, the CM MUST zero-pad the existing 8-tap filter to a 24-tap filter, and then convolve according to the rules above. Prior to making an initial ranging request and whenever the upstream channel frequency or upstream channel modulation rate changes, the CM MUST initialize the coefficients of the pre-equalizer to a default setting in which all coefficients are zero except the real coefficient of the first tap (i.e., F1). Whenever the main location is changed, the CM, not the CMTS, MUST compensate for the delay (ranging offset) due to a shift from the previous main tap location to a new main tap location of the equalizer coefficients sent by the CMTS (in both convolve and load operations). The pre-equalizer coefficients are then updated through the subsequent ranging process (unicast initial ranging and periodic ranging). In DOCSIS 1.1 mode, the CMTS MUST NOT move the main tap location during periodic ranging. In DOCSIS 1.1 mode, the CMTS MUST NOT instruct the CM to load the transmit equalizer coefficients. In DOCSIS 2.0 mode, the CMTS MAY move the main tap location during unicast initial ranging or periodic ranging. Equalizer coefficients may be included in every RNG-RSP message, but typically they only occur when the CMTS determines the channel response has significantly changed. The frequency of equalizer coefficient updates in the RNG-RSP message is determined by the CMTS. The CM MUST normalize the transmit equalizer coefficients in order to guarantee proper operation (such as not to overflow or clip). The CM MUST NOT change its target transmit power due to gain or loss of the new coefficients in both convolve and load operations. The target power is defined in Section 6.2.18, Transmit Power Requirements, on page 78. In DOCSIS 1.1 mode, if the CM equalizer structure implements the same number of coefficients as assigned in the RNG-RSP message, then the CM MUST NOT change the location of the main tap in the RNG-RSP message. If the CM equalizer structure implements a different number of coefficients than defined in the RNG-RSP message, the CM MAY shift the location of the main tap value. Again, in doing so, the CM MUST adjust its ranging offset, in addition to any adjustment in the RNG-RSP message, by an amount that compensates for the movement of the main tap location.
6.2.16 Spectral Shaping

The upstream transmitter MUST approximate a Nyquist square-root raised-cosine pulse-shaping filter with rolloff factor alpha =0.25. The -30dB transmitted bandwidth MUST NOT exceed the Channel Width values in Table 6-5. The Channel Width values are given analytically by: ChannelWidth = ModulationRate*(1+alpha).
Table 6-5 Maximum Channel Width
Channel Width (kHz) 200 400 800 1,600 3,200 6,400

Modulation Rate (kHz) 160 320 640 1,280 2,560 5,120

76

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.16.1

Upstream Frequency Agility and Range

The upstream PMD sublayer MUST support operation over the frequency range of 5-42 MHz edge to edge. Offset frequency commands MUST be supported per Table 6-8.1
6.2.16.2 Spectrum Format

The upstream modulator MUST provide operation with the format s(t) = I(t)*cos(t) - Q(t)*sin(t), where t denotes time and denotes angular frequency.
6.2.17 Relative Processing Delays

The CM MAP processing delay is the time provided between arrival of the last bit of a MAP message at a CM and the effectiveness of this MAP. During this time, the CM should process the MAP message and fill its interleavers (or its framer, in S-CDMA mode) with encoded data. The CMTS MUST transmit the MAP message early enough to allow the CM MAP processing delay specified below. The CM MAP processing delay, Dp, is given by the equations:

= 200 +

M sec, 5 . 12 Ir 0 Ir = 0

IrN r, M = B , r

where M is the number of elements in the CM interleavers (in the case of TDMA), or framer (in the case of S-CDMA). In DOCSIS 1.x mode, M = 0. Note that in the above equations, the values for Br and Ir*Nr are taken to be the maximum from all of the specified burst types in a particular UCD. In S-CDMA mode, M = 128(K+1), where K is the number of spreading intervals per frame. This is the time required for processing an S-CDMA frame plus an extra spreading interval. For example in the case of K = 32, which corresponds to the maximum framer size, the CM MAP processing time is 1025 sec, assuming a modulation rate of 5.12 MHz.
Note: The CM MAP processing delay does not include downstream FEC de-interleaving delay.

Note: The effectiveness of the MAP relates to the beginning of the burst frame at the RF output of the CM. In the S-CDMA mode, effectiveness of the MAP relates to the beginning (at the RF output of the CM) of the first spreading interval of the SCDMA frame which contains the burst.

1.

Section 6.2.16.1, second paragraph updated per RFI2-N-02104 by RKV on 10/28/02.

77

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.18

Transmit Power Requirements

The CM MUST support varying the amount of transmit power. Requirements are presented for 1) range of reported transmit power, 2) step size of power commands, 3) step size accuracy (actual change in output power compared to commanded change), and 4) absolute accuracy of CM output power. The protocol by which power adjustments are performed is defined in Section 11.2.4. Such adjustments by the CM MUST be within the ranges of tolerances described below. A CM MUST confirm that the transmit power limits are met after a RNG-RSP is received or after a UCD change. Transmit power is defined as the average RF power in the occupied bandwidth (channel width) transmitted in the data symbols of a burst, assuming equally likely QAM symbols, measured at the F-connector of the CM. Maximum and minimum transmit power level requirements refer to the CMs target transmit power level, defined as the CMs estimate of its actual transmit power. The actual transmitted power MUST be within 2 dB of the target power. The target transmit power MUST be variable over the range specified in Table 6-8. Transmit power as reported by the CM in the MIB is referenced to the 64QAM constellation. When transmitting with other constellations, a slightly different transmit power will result, depending on the constellation gain in Table 6-6 (see Section 6.2.13). As an example, if the reported power is 30 dBmV, 64QAM will be transmitted with a target power of 30 dBmV, while QPSK will be transmitted with 28.82 dBmV.
Table 6-6
Constellation Gain Gconst Relative to 64QAM (dB) -1.18 -0.21 -0.21 0.00 0.00 0.05

Constellation Gains and Power Limits

Pmax (dBmV) TDMA 58 55 55 54 54 N/A Pmax (dBmV) S-CDMA 53 53 53 53 53 53 Pmin Gconst (dBmV) 9.18 8.21 8.21 8.00 8.00 7.95 Pmax Gconst (dBmV) TDMA 59.18 55.21 55.21 54.00 54.00 N/A Pmax Gconst (dBmV) S-CDMA 54.18 53.21 53.21 53.00 53.00 52.95

Pmin (dBmV) 8 8 8 8 8 8

Constellation QPSK 8QAM 16QAM 32QAM 64QAM 128QAM

The actual transmitted power within a burst MUST be constant to within 0.1 dB peak to peak. This excludes the amplitude variation theoretically present due to QAM amplitude modulation, pulse shaping, pre-equalization, and for S-CDMA, spreading and varying number of allocated codes. The CM MUST support the transmit power calculations defined in Section 6.2.18.1 and Section 6.2.18.2.1

1.

Added this sentence per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.

78

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.18.1

TDMA Transmit Power Calculations

In TDMA mode, the CM determines its target transmit power Pt as follows. Define: Pr = Reported power level (dBmV) of CM in MIB (refers to 64QAM constellation) P = Power level adjustment (dB); for example, as commanded in ranging response message Gconst = Constellation gain (dB) relative to 64QAM constellation (see above table) Pmin = Minimum target transmit power permitted for the CM per Section 6.2.21.1 (see above table) Pmax = Maximum target transmit power permitted for the CM per Section 6.2.21.1 (see above table) Phi = min(Pmax - Gconst) over all burst profiles used by the CM (see above table) Plow = max(Pmin - Gconst) over all burst profiles used by the CM (see above table) Pt = Target transmit power level (dBmV) of CM (actual transmitted power as estimated by CM) The CM updates its reported power by the following steps: //Add power level adjustment to reported power level (1) Pr = Pr + P (2) Pr = min[Pr, Phi] //Clip at max power limit (3) Pr = max[Pr, Plow] //Clip at min power limit The CM then transmits with target power Pt = Pr + Gconst, i.e., the reported power plus the constellation gain. Usually the reported power level is a relatively constant quantity, while the transmitted power level varies dynamically as different burst profiles, with different constellation gains, are transmitted. A CMs target transmit power MUST never be below Pmin or above Pmax. This implies that in some cases the extreme transmit power levels (e.g., 58 dBmV for QPSK and 8 dBmV) may not be permitted if burst profiles with multiple constellations are active. Also, if only QPSK is used, the reported power may be greater than 58 dBmV, although the target transmit power will not exceed 58 dBmV. For example, if only QPSK and 64QAM burst profiles are active, Phi = 54 dBmV and Plow = 9.2 dBmV. The maximum permitted QPSK transmitted power is 54 - 1.2 = 52.8 dBmV, the minimum QPSK power is 9.2 - 1.2 = 8 dBmV, the maximum 64QAM power is 54 dBmV, and the minimum 64QAM power is 9.2 dBmV.
6.2.18.2 S-CDMA Transmit Power Calculations1

In S-CDMA mode the power calculations depend on whether the Maximum Scheduled Codes feature is enabled.
6.2.18.2.1 S-CDMA Transmit power Calculations When Maximum Scheduled Codes is Not Enabled

In S-CDMA mode when Maximum Scheduled Codes is not enabled, the CM determines its target transmit power Pt as follows. Define: Pr = reported power level (dBmV) of CM in MIB (refers to 64QAM constellation and all active codes transmitted) Phi = min[Pmax - Gconst] over all burst profiles used by the CM (see above table) Plow = max[Pmin - Gconst] + 10 log(number_active_codes / number_of_codes_per_mini-slot) where the maximum is over all burst profiles used by the CM (see above table) The CM updates its reported power by the following steps:

1.

Revised this subsection per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.

79

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

(1) Pr = Pr + P //Add power level adjustment to reported power level //Clip at max power limit (2) Pr = min[Pr, Phi] (3) Pr = max[Pr, Plow] //Clip at min power limit In a spreader-on frame, the CM then transmits each code i with target power Pt,i = Pr + Gconst,i - 10 log(number_active_codes) i.e., the reported power plus the constellation gain Gconst,i of that code, less a factor taking into account the number of active codes. The total transmit power Pt in a frame is the sum of the individual transmit powers Pt,i of each code, where the sum is performed using absolute power quantities (non-dB domain). In a spreader-off frame, the CM target transmit power is Pt = Pr + Gconst. The transmitted power level varies dynamically as the number of allocated codes varies, and as different burst profiles, with different constellation gains, are transmitted. A CMs target transmit power MUST never be below Pmin or above Pmax, including over all numbers of allocated codes and all burst profiles. This implies that in some cases the extreme transmit power levels (e.g., 8 and 53 dBmV) may not be permitted. Also if, for example, only QPSK is used, the reported power may be greater than 53 dBmV, although the target transmit power will not exceed 53 dBmV. If, for example, QPSK and 64QAM burst profiles are active, the number of active codes is 128 and the number of codes per mini-slot is 2, then Phi = 53 dBmV and Plow = 27.24 dBmV. The maximum permitted QPSK transmitted power is 53 1.18 = 51.82 dBmV when all active codes are transmitted. The minimum QPSK power is 27.24 1.18 10log(128) + 10log(2) = 8 dBmV, when one mini-slot is transmitted. The last term in the sum is the result of summing the individual powers over 2 codes. Similarly, the maximum 64QAM power is 53 dBmV when all active codes are transmitted and the minimum 64QAM power is 27.24 10log(128) + 10log(2) = 9.18 dBmV when one mini-slot is transmitted. The minimum QPSK power permitted while transmitting, for example, 2 minislots is 11 dBmV, and the minimum 64QAM power permitted while transmitting 2 minislots is 12.2 dBmV.1 The CM needs to implement some form of clipping on the transmitted waveform at the higher output powers in order to prevent peak to average ratio (PAR) issues. The power received at the CMTS in a spreader-on frame will sometimes be less than the nominal power of a spreader-off frame because of such factors as 1) broadcast opportunities not used by any CM, 2) unicast grants not used by one or more CMs, or 3) mini-slots assigned to the NULL SID.
6.2.18.2.2 S-CDMA Transmit Power Calculations When Maximum Scheduled Codes is Enabled.

In S-CDMA mode on channels on which Maximum Scheduled Codes is enabled, the CM determines its target transmit power Pt as follows. Define: Pr = reported power level (dBmV) of CM in MIB (operational transmit power of the spreader-off ranging burst referenced to 64QAM modulation) Phi_S = min[53 - Gconst] over all spreader-on burst profiles used by the CM (see Table 6-6). Plow_S = max[8 - Gconst] + 10 log(number_active_codes / number_of_codes_per_mini-slot) where the maximum is over all burst profiles used by the CM (see Table 6-6)

1.

First two sentences of this paragraph updated per RFI2-N-02105 by RKV on 10/28/02.

80

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Pmax_T = Maximum target transmit power permitted for the CM in TDMA mode (see Table 6-6) for the constellation used in ranging. Phi_T = min[Pmax_T - Gconst] over all spreader-off burst profiles used by the CM (see Table 6-6). Pon = Pr clipped at the maximum spreader-on limit. Psf = CM Power Shortfall per Section 8.3.5 & Section 8.3.26. Phr = S-CDMA Power Headroom in dB. Equivalent to TLV-11 defined in Table 8-21 divided by 4. P = power level adjustment in dB sent from CMTS to CM The CM updates its power by the following steps: 1. Pr = Pr + P //Add power level adjustment to reported power level 2. Pr = min[Pr, Phi_T] //Clip at max TDMA power limit 3. Pr = max[Pr, Plow_S] //Clip at min S-CDMA power limit 4. Pon = min[Pr, Phi_S] //Clip at max S-CDMA power limit In spreader-off frames, the CM transmits with target power Pt = Pr + Gconst Based on the spreader-off transmit power, the CM updates its power shortfall according to the following steps: Psf = Pt - 53 Psf = max[Psf, 0] // Difference between spreader-off and max spreader-on target powers // Set Psf to 0 if Pt is less than 53 dBmV

In spreader-on frames, the CM transmits each code i with target power Pt, i = Pon + Gconst, i - 10 log(number_active_codes) + Phr i.e., the clipped reported power plus the constellation gain Gconst, i of that code, less a factor taking into account the number of active codes, plus the Power Headroom Phr. Phr is the power (in dB) added to account for CMs that have a maximum scheduled code limit and can transmit additional power per code. The total transmit power Pt in a frame is the sum of the individual transmit powers Pt, i of each code, where the sum is performed over all Nalloc allocated codes using absolute power quantities (non-dB domain).

Pt = 10 log

N alloc i =1

10

Pt ,i /10

81

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

If, for example, the burst profile contains QPSK for IUCs 1,2,3, and 4 and 64QAM for IUCs 9 and 10, the number of active codes is 128, and the number of codes per minislot is 2, then Phi_S = 53 dBmV, Plow_S = 27.24 dBmV, and Phi_T = 58 dBmV. Assume the CM ranges at spreader-off target transmit power of 57 dBmV. The CM reports Psf = 57 dBmV - 53 dBmV = 4 dB. The CMTS uses Psf to set (using its vendor-specific algorithm) max_scheduled_codes = 32 and Phr = 6 dB. (The S-CDMA power headroom may differ from the power shortfall, at the discretion of the CMTS.) The CM sets its transmitted power per code to: Pt, i = Pon + Gconst, i - 10 log (number_active_codes) + Phr = 53 dBmV + 0 dB - 21 dB + 6 dB // For a code with 64QAM modulation = 38 dBmV A parameter that may be used to illustrate the effect of increased power per code is the Effective Transmit Power, Peff, the power that would result hypothetically if all Nact active codes were transmitted. It is computed as:

Peff = 10log 10 t ,i
i =1

N act

P /10

1 = Pon + Phr + 10 log N act

where the last term is the average constellation gain.

10
i =1

N act

Gconst ,i /10

For a reference case with all codes transmitted using 64QAM modulation (Gconst = 0 dB), the effective transmit power reduces to: Peff = Pon + Phr Continuing the above example, the result is: Peff = 53 dBmV + 6 dB = 59 dBmV Limiting the number of codes has given the CM an enhanced effective power of 59 dBmV, which is 6 dB above the normal maximum of 53 dBmV, and 2 dB above the ranging power of 57 dBmV. In this example, the CMTS used its discretion to ask for 2 dB more enhancement than was needed (Phr = 6 dB vs Psf, = 4 dB), perhaps due to some known impairment in the channel. The effective_SNR is an SNR estimate for a given code corresponding to the effective transmit power. It is defined as the measured SNR at the last station maintenance, minus the CM power shortfall, plus the power headroom, plus the difference in constellation gain between the ranging burst and the code under consideration. Its equation is: effective_SNR = measured_SNR - Psf + Phr + (Gconst, i - Gconst, ranging) Where Gconst, ranging is the constellation gain of the ranging burst that resulted in the SNR measurement. In the MIB, effective_SNR corresponds to a reference case with 64QAM modulation (Gconst, i = 0 dB): effective_SNR = measured_SNR - Psf + Phr - Gconst, ranging

82

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Continuing the example, if the measured SNR in the last station maintenance was 17 dB using QPSK modulation (Gconst, ranging = -1.2 dB) then the effective SNR referenced to 64QAM modulation is: effective_SNR = 17dB - 4dB + 6dB + 1.2 dB = 20.2 dB
6.2.18.3 Transmit Power Step Size

The step resolution in transmit power MUST be 1dB or less. When a CM is commanded with finer resolution than it can implement, it MUST round to the nearest supported step size. If the commanded step is half way between two supported step sizes, the CM MUST choose the smaller step. For example, with a supported step resolution of 1 dB, a command to step 0.5 dB would result in no step, while a command to step 0.75 dB would result in a 1 dB step. The step size accuracy MUST be within 0.4 dB. For example, the actual power increase resulting from a command to increase the power level by 1 dB in a CM's next transmitted burst MUST be between 0.6 dB and 1.4 dB. A relaxation in step size accuracy to 1.4 dB is allowed for one gain change when changing the power throughout the full power control range in either direction (from low-end to high-end power and vice versa). The locations of these two gain changes with relaxed accuracy MUST be at least 2 dB apart, thus enabling the use of large step attenuators in the coverage of the full power control range (hysteresis effect).
6.2.19 Burst Profiles

The transmission characteristics are separated into three portions: a) Channel Parameters, b) Burst Profile Attributes, and c) User Unique Parameters. The Channel Parameters include i) the modulation rate (six rates from 160 ksym/sec to 5.12 Msym/sec in octave steps), ii) the center frequency (Hz), iii) the 1536-bit Preamble Superstring, and iv) the S-CDMA channel parameters. The Channel Parameters are further described in Section 8.3.3, Table 8-18; these characteristics are shared by all users on a given channel. The Burst Profile Attributes are listed in Table 6-7, and are further described in Section 8.3.3, Table 8-19; these parameters are the shared attributes corresponding to a burst type. The CM MUST generate each burst at the appropriate time as conveyed in the mini-slot grants provided by the CMTS MAPs (Section 8.3.4).

83

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM MUST support all burst profiles commanded by the CMTS via the Burst Descriptors in the UCD (Section 8.3.3), and subsequently assigned for transmission in a MAP (Section 8.3.4).1 2 3
Table 6-7
Burst Profile Attributes Modulation Differential Encoding TCM Encoding Preamble Length Preamble Value offset R-S FEC Error Correction (T) R-S FEC Codeword Information Bytes (k)

Burst Profile Attributes

Configuration Settings QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM, 128 QAM(TCM Only) On/Off On/Off 0-1536 bits (Note Section 6.2.9) 0 to 1534 0 to 16 (0 implies no R-S FEC. The number of codeword parity bytes is 2*T) Fixed: 16 to 253 (assuming R-S FEC on) Shortened: 16 to 253 (assuming R-S FEC on) 15 bits
1

Scrambler Seed Maximum Burst Length (mini-slots) Guard Time

0 to 255 4 to 255 modulation intervals There is no guard time in S-CDMA

Last Codeword Length Scrambler On/Off Byte Interleaver Depth (Ir)2 Byte Interleaver Block Size (Br)4 Preamble Type S-CDMA Spreader5 S-CDMA Codes per Subframe5 S-CDMA Interleaver Step5
1.

Fixed, shortened On/Off 0 to floor(2048/Nr)3 2*Nr to 2048 QPSK0/QPSK1 On/Off 1 to 128 1 to (spreading intervals per frame - 1)

A burst length of 0 mini-slots in the Channel Profile means that the burst length is variable on that channel for that burst type. The burst length, while not fixed, is granted explicitly by the CMTS to the CM in the MAP. If depth=1, no interleaving; if depth=0, dynamic mode. Nr is the R-S codeword size k+2T as defined in Section 6.2.6.1. Used only in dynamic mode Used only for S-CDMA channels.

2. 3. 4. 5.

1. 2.

Range changed from 5 - 255 to 4 - 255 per RFI2-N-02085 by RKV on 10/28/02. 1 for S-CDMA channels changed to There is no guard time in S-CDMA per RFI2-N-02210 by GO on 11/22/02. Added row text per ECN RFI2-N-02210 by GO on 11/21/02.

3.

84

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The User Unique Parameters may vary for each user even when using the same burst type on the same channel as another user (for example, Power Level), and are listed in Table 6-8:1
Table 6-8
User Unique Parameter Power Level

User Unique Burst Parameters

Adjustment Command Resulting Parameter Value TDMA: +8 to +54 dBmV (32QAM, 64QAM) +8 to +55 dBmV (8QAM, 16QAM) +8 to +58 dBmV (QPSK) S-CDMA: +8 to +53 dBmV (all modulations) Resolution = 1 dB or better

8-bit two's complement, resolution = 0.25 dB

Offset Frequency

Range = 32 kHz, resolution = 1 Hz

Frequency Range per Section 6.2.16.1 Upstream Frequency Agility and Range, on page 77 Range: sufficient for maximum cable plant length per Section 4.1, Broadband Access Network, on page 23 Resolution: TDMA: 6.25 sec/64. SCDMA: 6.25 sec/(64*256) 1 to 255 mini-slots

Ranging Offset

Integer part: 32-bit two's complement, resolution = (1 / 10.24 MHz) = 6.25 sec/64 = 97.65625 ns Fractional part: unsigned 8-bit fractional extension, resolution = 6.25 sec/(64*256) = 0.3814697265625 nsec

Burst Length (mini-slots) if variable on this channel (changes burst-toburst) Transmit Equalizer Coefficients (See Section 6.2.15, Transmit PreEqualizer, on page 74)

N/A

DOCSIS 2.0 mode: 24 complex coefficients, 4 bytes per coefficient (2 real and 2 imaginary), load and convolve modes DOCSIS 1.1 mode: up to 64 complex coefficients, 4 bytes per coefficient (2 real and 2 imaginary), convolve mode only

DOCSIS 2.0 mode: 24 complex coefficients DOCSIS 1.1 mode: up to 64 complex coefficients

The CM MUST implement the Offset Frequency Adjustment to effect a change in upstream carrier frequency within 10 Hz of the commanded change.2
6.2.19.1 Ranging Offset

Ranging Offset is the time difference between the CM upstream frame time base and the CMTS upstream frame time base. It is an advancement equal to roughly the round-trip delay between the CM and the CMTS, and is needed to synchronize upstream transmissions in the TDMA and S-CDMA schemes. The CMTS MUST provide the CM with feedback adjustments of this offset, based on reception of one or more successfully received bursts (i.e., satisfactory result from each technique employed: error correction and/or CRC). The CMTS sends these Timing Adjust commands to the CM in the Ranging Response MAC message (see Section 8.3.6), where a negative value implies the Ranging Offset is to be decreased, resulting in later times of transmission at the CM.

1. 2.

Table 6-8 replaced per RFI2-N-02104 by RKV on 10/28/02. Section 6.2.19, last paragraph updated per RFI2-N-02104 by RKV on 10/28/02.

85

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

For TDMA channels the CM MUST implement the Timing Adjust command with resolution of at most 1 symbol duration (of the symbol rate in use for a given burst), and (other than a fixed bias) with accuracy within 0.25 sec plus 1/2 symbol owing to resolution. As an example, for the maximum symbol rate of 5.12 Msps, the corresponding symbol period would be 195 ns, the corresponding maximum resolution for the Timing Adjust MUST be 195 ns, and the corresponding minimum accuracy MUST be 348 ns. The accuracy of CM burst timing of 0.25 sec plus 1/2 symbol is relative to the mini-slot boundaries derivable at the CM based on an ideal processing of the timestamp signals received from the CMTS. The resolution of the integer part of the Timing Adjust parameter, which is used for TDMA channels, is (1 / 10.24 MHz) = 6.25 sec/64 ~= 97.66 ns. For S-CDMA channels the CMTS provides an additional fractional field in the Timing Adjust command, with resolution of 1/16384 of the frame tick increment = (6.25 sec/ (64*256) ~= 0.3814 nsec. For S-CDMA channels, the CM MUST implement the Timing Adjust to within 0.01 of the nominal chip period. As an example, for the maximum chip rate of 5.12 Mcps, the corresponding maximum resolution for implementation of the timing correction would be (0.01)*195 ns or roughly 2 ns.1
6.2.19.2 TDMA Reconfiguration Times

The CM MUST be capable of switching burst profiles with no reconfiguration time required between bursts except for changes in the following parameters: 1) Output Power, 2) Symbol Rate, 3) Offset Frequency, 4) Channel Frequency, and 5) Ranging Offset. For Output Power changes; If Output Power is to be changed by 1 dB or less, the CM MUST be able to implement the change between bursts as long as the CMTS allocates at least 96 symbols plus 5 sec between the last symbol center of one burst and the first symbol center of the following burst. If Output Power is to be changed by more than 1 dB, the CM MUST be able to implement the change between bursts as long as the CMTS allocates at least 96 symbols plus 10 sec between the last symbol center of one burst and the first symbol center of the following burst. The maximum reconfiguration time of 96 symbols should compensate for the ramp down time of one burst and the ramp up time of the next burst as well as the overall transmitter delay time including the pipeline delay and optional pre-equalizer delay. The Output Power of the CM MUST be settled to within 0.1 dB of its final output power level a) within 5 sec from the beginning of a change of 1 dB or less, and b) within 10 sec from the beginning of a change of greater than 1 dB. Output Power MUST NOT be changed until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted. For Symbol Rate changes, the CM MUST be able to transmit consecutive bursts as long as the CMTS allows the required time between bursts for UCD parameter changes (see Section 11.3.2, Changing Upstream Channel Descriptor Message Parameters, on page 262). Symbol Rate MUST NOT be changed until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted. For Offset Frequency changes, the CM MUST be able to transmit consecutive bursts as long as the CMTS allocates at least 96 symbols in between the last symbol center of one burst and the first symbol center of the following burst. The maximum reconfiguration time of 96 symbols should compensate for the ramp down time of one burst and the ramp up time of the next burst as well as the overall transmitter delay time including the pipeline delay and optional pre-equalizer delay. Offset frequency MUST NOT be changed until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted.

1.

Section 6.2.19.1, all three paragraphs replaced per RFI2-N-02104 by RKV on 10/29/02.

86

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

For Channel Frequency changes, then the CM MUST be able to implement the change between bursts as long as the CMTS allocates at least 96 symbols plus 100 msec between the last symbol center of one burst and the first symbol of the following burst. The Channel Frequency of the CM MUST be settled within the phase noise and accuracy requirements of Section 6.2.21.5 and Section 6.2.21.6 within 100 msec from the beginning of the change. Channel Frequency MUST NOT be changed until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted. For Ranging Offset changes, the CM MUST be able to transmit consecutive bursts as long as the CMTS allocates at least 96 symbols in between the last symbol center of one burst and the first symbol center of the following burst. The maximum reconfiguration time of 96 symbols should compensate for the ramp down time of one burst and the ramp up time of the next burst as well as the overall transmitter delay time including the pipeline delay and optional pre-equalizer delay. Ranging Offset MUST NOT be changed until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted. For modulation type changes, the CM MUST be able to transmit consecutive bursts with no reconfiguration time between them (except for the minimum guard time). The modulation MUST NOT change while more than -30 dB of any symbols energy of the previous burst remains to be transmitted, or more than -30 dB of any symbols energy of the next burst has been transmitted, EXCLUDING the effect of the transmit equalizer (if present in the CM). [This is to be verified with the transmit equalizer providing no filtering; delay only, if that. Note that if the CMTS has decision feedback in its equalizer, it may need to provide more than the 96 symbol gap between bursts of different modulation type which the same CM may use; this is a CMTS decision.]
6.2.19.3 S-CDMA Reconfiguration Times

In S-CDMA mode, for changes in Output Power per mini-slot, Offset Frequency, Pre-equalizer coefficients, and/ or Ranging Offset, the CM MUST be able to transmit consecutive bursts as long as the CMTS allocates the time duration of at least one frame in between the bursts. For all other burst profile parameter changes, no reconfiguration is required beyond what is provided by the MAC for such changes.
6.2.19.4 CM Timing Offsets When Changing Modulation Rate

When making a modulation rate change the CM MUST employ the following timing offsets when changing modulation rates. The offsets in the table correspond to the contribution of DOCSIS 1.0 and 1.1 legacy upstream receivers to changes in latency when making modulation rate changes. These offsets are maintained into DOCSIS 2.0 but with the addition of including in the table the highest modulation rate. The timing offset to apply is the difference between the entry in the table corresponding to the new modulation rate and the entry corresponding to the original modulation rate. The offsets are referenced to the center of the first symbol in the burst, which is the reference point for burst timing as stated in Section 6.2.20. Specification of these offsets is needed so that CMs apply uniform adjustments to their ranging offsets and so that CMTSs can appropriately handle CMs that apply these offsets when making modulation rate changes.
Timing Offset (in units of 1/64 time ticks referenced to 5.12 MHz) 0 (reference) 0 24 72 168 360

Modulation Rate 5.12 MHz 2.56 MHz 1.28 MHz 0.64 MHz 0.32 MHz 0.16 MHz

87

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

As an example, suppose a CM is on an upstream channel operating at a modulation rate of 1.28 MHz. Now, suppose the UCD message from the CMTS changes the modulation rate of the channel to 0.32 MHz. The CM applies an additional timing offset of 168 24 = 144 to its ranging offset to compensate for this modulation rate change. The value of 144 is positive, and thus, the CM will add to its ranging offset so that it effectively transmits earlier by 144 units of 1/64 time ticks. Furthermore, in changing modulation rates, if a CM has its own contribution to a change in latency, the CM MUST also compensate for this CM-specific latency difference. This is in addition to the offset applied from the values in the table above, which result from legacy CMTS upstream receiver contributions to changes in latency. The requirements for CM burst timing accuracy found earlier in this section for TDMA mode, referenced to the modulation rate that is the lower of the original, and the new modulation rate, apply after the modulation rate change, with the required timing offsets above considered. Specifically, the CM MUST implement the timing adjustments with accuracy within 0.25 sec plus 1/2 symbol, in both TDMA and S-CDMA modes.1 A CMTS that does not apply the same internal physical delay offsets as the legacy DOCSIS upstream CMTS receiver implementation is capable of receiving a CM burst after a modulation rate change in any of the following ways but is not limited necessarily to only these ways: a) The CMTS may implement the internal physical delay offset, as specified in the above table.

b) The CMTS may implement an internal timing compensation based on the expected offset in the above table. c) The CMTS may increase the guard time.

d) The CMTS may send an unsolicited RNG-RSP to each CM to adjust the delay offset. As discussed in Section 6.3.6, the CM is expected to be capable of adjusting its timing offset at any time with the accuracy specified within this section.2

1. 2.

Revised this paragraph per RFI2-N-03018 by GO on 03/21/03. Section 6.2.19.4 added per RFI2-N-02178 by RKV on 10/30/02.

88

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.2.20

Burst Timing Convention

Figure 6-29 illustrates the nominal burst timing for TDMA channels.

Figure 6-29 Nominal TDMA Burst Timing

Figure 6-30 indicates worst-case burst timing for a TDMA channel. In this example, burst N arrives 1.5 symbols late, and burst N+1 arrives 1.5 symbols early, but separation of 5 symbols is maintained; 8-symbol guardband shown.

89

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Worst case Burst timing input to CMTS

Burst N+1

Time equal to 5 symbols separates the first symbol center of burst N+1 and the last symbol center of burst N Burst N

Symbol center of Burst N, last symbol; 1.5 symbols late

Symbol Symbolcenter center of of Burst N+1, symbol; 1.5 Burstfirst N+1, last symbol; symbols early 1.5 symbols early

8 symbol guard band 1.5 5 symbols 1.5

Minislot Boundary
Figure 6-30 Worst-Case TDMA Burst Timing

At a symbol rate of Rs, symbols occur at a rate of one each Ts = 1/Rs seconds. Ramp Up and Ramp Down are the spread of a symbol in the time domain beyond Ts duration owing to the symbol-shaping filter and any residual effect from the transmit equalizer. If only one symbol were transmitted, its duration would be longer than Ts due to the shaping filter impulse response being longer than Ts. The spread of the first and last symbols of a burst transmission effectively extends the duration of the burst to longer than N * Ts, where N is the number of symbols in the burst. For S-CDMA channels, the bursts from all CMs are synchronized. This means that the ramp down of one burst may occur at the same time as the ramp up of the subsequent burst. The CM MUST meet the ranging and synchronization requirements of S-CDMA to assure that the ramp down and ramp up of bursts are aligned.
6.2.21 Fidelity Requirements

The following requirements assume that any pre-equalization is disabled unless otherwise noted.
6.2.21.1 Spurious Emissions

The spurious emissions specifications are separated into two regions based on the transmit power. Region 1 is defined to have a power range of +14 dBmV to (Pmax - 3), i.e., the central region. Region 2 is defined from +8 dBmV to +14 dBmV and (Pmax - 3) to Pmax, i.e., the low and high ends of the transmit power. Pmax is defined in Table 6-8, User Unique Burst Parameters, on page 85.

90

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

For S-CDMA mode, when a modem is transmitting fewer than 4 spreading codes, the region 2 specifications are used for all transmit power levels. Otherwise, for all other numbers of spreading codes (e.g., 4 to 128) or for TDMA mode, the spurious emissions specifications are used according to the power ranges defined for regions 1 and 2 above. In addition, for S-CDMA, the spurious emission specifications for S-CDMA MUST be met for any number_allocated_codes, as defined in Section 6.2.19. The noise and spurious power MUST NOT exceed the levels given in Table 6-9, Table 6-10, and Table 6-11. In Table 6-9, Inband spurious includes noise, carrier leakage, clock lines, synthesizer spurious products, and other undesired transmitter products. It does not include ISI. The measurement bandwidth for Inband spurious is equal to the modulation rate (e.g., 160 to 5120 kHz). All requirements expressed in dBc are relative to the actual transmit power that the CM emits. The measurement bandwidth for the three (or fewer) Carrier-Related Frequency Bands (below 42 MHz) is 160 kHz, with up to three 160 kHz bands, each with no more than the value given in Table 6-9, allowed to be excluded from the Bands within 5 to 42 MHz Transmitting Burst specs of Table 6-11. Carrier-related spurious emissions include all products whose frequency is a function of the carrier frequency of the upstream transmission, such as but not limited to carrier harmonics. The measurement bandwidth is also 160 kHz for the Between Bursts specs of Table 6-9 below 42 MHz. The Transmitting Burst specs apply during the mini-slots granted to the CM (when the CM uses all or a portion of the grant), and for 32 modulation intervals before and after the granted mini-slots. The Between Bursts specs apply except during a used grant of mini-slots, and the 32 modulation intervals before and after the used grant. In TDMA mode, a mini-slot may be as short as 32 modulation intervals, or 6.25 microseconds at the 5.12 Msym/ sec rate, or as short as 200 microseconds at the 160 ksym/sec rate.

91

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table 6-9 Spurious Emissions

Parameter Inband Adjacent Band 3 or Fewer Carrier-Related Frequency Bands (such as second harmonic, if < 42 MHz) Transmitting Burst -40 dBc See Table 6-10 Region 1: -50 dBc for transmitted modulation rate = 320 ksps and above; -47 dBc for transmitted modulation rate = 160 ksps Region 2: -47 dBc Bands within 5 to 42 MHz (excluding assigned channel, adjacent channels, and carrier-related channels) CM Integrated Spurious Emissions Limits (all in 4 MHz, includes discretes)1 42 to 54 MHz 54 to 60 MHz 60 to 88 MHz 88- to 860 MHz CM Discrete Spurious Emissions Limits1 42 to 54 MHz 54 to 88 MHz 88 to 860 MHz
1.

Between Bursts The greater of -72 dBc or -59 dBmV The greater of -72 dBc or -59 dBmV The greater of -72 dBc or -59 dBmV

See Table 6-11

The greater of -72 dBc or -59 dBmV

max(-40 dBc, -26 dBmV) -35 dBmV -40 dBmV -45 dBmV

-26 dBmV -40 dBmV -40 dBmV max(-45 dBmV, -40 dB ref d/s2)

-max(-50 dBc, -36 dBmV) -50 dBmV -50 dBmV

-36 dBmV -50 dBmV -50 dBmV

These spec limits exclude a single discrete spur related to the tuned received channel; this single discrete spur MUST be no greater than -40 dBmV. dB ref d/s is relative to the received downstream signal level. Some spurious outputs are proportional to the receive signal level.

2.

6.2.21.1.1

Adjacent Channel Spurious Emissions

Spurious emissions from a transmitted carrier may occur in an adjacent channel which could be occupied by a carrier of the same or different modulation rate. The following table lists the required adjacent channel spurious emission levels for all combinations of transmitted carrier modulation rates and adjacent channel modulation rates. The measurement is performed in an adjacent channel interval that is of appropriate bandwidth and distance from the transmitted carrier based on the modulation rates of the transmitted carrier and the carrier in the adjacent channel.

92

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 6-10 Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level
Specification in the interval, Region 2 -45 dBc -45 dBc -45 dBc -44 dBc -41 dBc -38 dBc

Transmitted carrier modulation rate

Specification in the interval, Region 1 -47 dBc -47 dBc

Measurement interval and distance from carrier edge 20 kHz to 180 kHz 40 kHz to 360 kHz 80 kHz to 720 kHz 160 kHz to 1440 kHz 320 kHz to 2880 kHz 640 kHz to 5760 kHz

Adjacent channel carrier modulation rate 160 kHz 320 kHz 640 kHz 1280 kHz 2560 kHz 5120 kHz

All modulation rates

-46 dBc -45 dBc -44 dBc -42 dBc

6.2.21.1.2

Spurious Emissions in 5 to 42 MHz

Spurious emissions, other than those in an adjacent channel or carrier related emissions listed above, may occur in intervals (frequency bands) that could be occupied by other carriers of the same or different modulation rates. To accommodate these different modulation rates and associated bandwidths, the spurious emissions are measured in an interval equal to the bandwidth corresponding to the modulation rate of the carrier that could be transmitted in that interval. This interval is independent of the current transmitted modulation rate. The following table lists the possible modulation rates that could be transmitted in an interval, the required spurious level in that interval, and the initial measurement interval at which to start measuring the spurious emissions. Measurements should start at the initial distance and be repeated at increasing distance from the carrier until the upstream band edge, 5 MHz or 42 MHz, is reached. Measurement intervals should not include the three or fewer carrier related emission bands excluded above.
Table 6-11 Spurious Emissions in 5 to 42 MHz Relative to the Transmitted Burst Power Level
Specification in the interval, Region 1 -54 dBc -52 dBc -50 dBc -48 dBc -46 dBc -44 dBc Specification in the interval, Region 2 -53 dBc -50 dBc -47 dBc -44 dBc -41 dBc -38 dBc

Possible modulation rate in this interval 160 kHz 320 kHz 640 kHz 1280 kHz 2560 kHz 5120 kHz

Initial measurement interval and distance from carrier edge 220 kHz to 380 kHz 240 kHz to 560 kHz 280 kHz to 920 kHz 360 kHz to 1640 kHz 520 kHz to 3080 kHz 840 kHz to 5960 kHz

6.2.21.2

Spurious Emissions During Burst On/Off Transients

Each transmitter MUST control spurious emissions, prior to and during ramp up and during and following ramp down, before and after a burst. On/off spurious emissions, such as the change in voltage at the upstream transmitter output due to enabling or disabling transmission, MUST be no more than 100 mV, and such a step MUST be dissipated no faster than 2 s of constant slewing. This requirement applies when the CM is transmitting at +55 dBmV or more; at backed-off transmit levels, the maximum change in voltage MUST decrease by a factor of 2 for each 6-dB decrease of power level from +55 dBmV, down to a maximum change of 7 mV at 31 dBmV and below. This requirement does not apply to CM power-on and power-off transients.

93

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.2.21.3

Modulation Error Ratio (MER)

MER measures the cluster variance caused by the transmit waveform. It includes the effects of ISI, spurious, phase noise, and all other transmitter degradations.
6.2.21.3.1 Definitions

Symbol MER: MERsymb is defined as follows for TDMA or S-CDMA symbols. The transmitted RF waveform (after appropriate down conversion) is applied to the ideal receive symbol matched filter and is sampled once per symbol. For TDMA, the matched filter is a square-root raised cosine filter with alpha = 0.25. For S-CDMA, the matched filter is a square-root raised cosine filter with alpha = 0.25, convolved with the time-reversed spreading code sequence. (In this convolution, the spreading code sequence is expressed as a weighted impulse train spaced at the chip period.) No external noise (AWGN) is added to the signal. The carrier frequency offset, carrier phase offset, symbol timing and gain may be adjusted during each burst to maximize MERsymb. Equalization of the received waveform is not permitted. For cases where the CM transmit equalizer is ON, the transmit equalizer coefficients may be adjusted to maximize MERsymb. MERsymb is defined at the F connector of the CM, except that when an echo channel is inserted, MERsymb is defined at the output of the echo channel. MERsymb is computed by the formula E av ----------------------------- MER symb ( dB ) = 10 log 1 N 10 --e j 2 N j=1

where: Eav is the average constellation energy for equally likely symbols (see Section 6.2.13 and Figure 6-18) N is the number of symbols averaged ej is the error vector from the jth received symbol to the ideal transmitted QAM symbol on the grid of Figure 6-18 For S-CDMA, MERsymb is averaged over all active codes. MER of composite chips: MERchip is specified for composite S-CDMA chips to ensure that high SNR is maintained, especially for a small number of allocated codes, to prevent noise funneling effects when many modems transmit simultaneously. A composite S-CDMA chip is defined as the output of the spreader during one chip interval, that is, an element of the transmission vector P k defined in Section 6.2.14, S-CDMA Spreader, on page 72. MERchip is defined as follows. The transmitted RF waveform (after appropriate down conversion) is applied to the ideal receive chip matched filter and is sampled once per chip. The matched filter is a square-root raised cosine filter with alpha = 0.25. No external noise (AWGN) is added to the signal. The carrier frequency offset, carrier phase offset, timing and gain may be adjusted during each burst to maximize MERchip. Equalization of the received waveform is not permitted. For cases where the CM transmit equalizer is ON, the transmit equalizer coefficients may be adjusted to maximize MERchip. MERchip is defined at the F connector of the CM. MERchip is

94

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

computed by the formula

2 pj j=1 - MER chip ( dB ) = 10 log --------------------------10 N 2 pj rj j=1

where: pj is the jth ideal transmitted composite chip rj is the jth received composite chip N is the number of composite chips observed
6.2.21.3.2 Requirements

Unless otherwise stated, the MER MUST meet or exceed the following limits over the full transmit power range of Table 6-8 for each modulation, each modulation rate, and over the full carrier frequency range, and for SCDMA, over any valid number of active and allocated codes. The 5-42 MHz carrier frequency range refers more precisely to [5 MHz + modulation rate * 1.25 / 2] to [42 MHz - modulation rate * 1.25 / 2]. At the break points between regions, the higher MER specification applies.
Case 1: Flat channel, transmit equalization OFF

Case 1a: for modulation rates 2.56 MHz and below MERsymb >= 30 dB over 15 to 30 MHz carrier frequency MERsymb >= 27 dB over 10 MHz to 15 MHz and 30 MHz to 35 MHz carrier frequency MERsymb >= 23 dB over 5 MHz to 10 MHz and 35 MHz to 42 MHz carrier frequency Case 1b: for modulation rate 5.12 MHz MERsymb >= 27 dB over 15 to 30 MHz carrier frequency MERsymb >= 24 dB over 10 MHz to 15 MHz and 30 MHz to 35 MHz carrier frequency MERsymb >= 20 dB over 5 MHz to 10 MHz and 35 MHz to 42 MHz carrier frequency
Case 2: Flat channel, transmit equalization ON

Case 2a: for TDMA/QPSK, MERsymb >= 30 dB. Case 2b: for S-CDMA and all TDMA modulations except QPSK, MERsymb >= 35 dB. Case 2c: for S-CDMA, MERchip >= 33 dB.
Case 3: Echo channel, transmit equalization ON

Case 3a: In the presence of a single echo selected from the channel micro-reflections defined in Table 4-2 on page 26, the measured MERsymb MUST be >= 30 dB for TDMA/QPSK, and >= 33 dB for S-CDMA and all TDMA modulations except QPSK. Case 3b: In the presence of two or three of the echoes defined in Table 4-2 (at most one of each specified magnitude and delay), the measured MERsymb MUST be >= 29 dB.

95

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Since the table does not bound echo delay for the -30 dBc case, for testing purposes it is assumed that the time span of the echo at this magnitude is less than or equal to 1.5 s. The CMTS MUST provide a test mode in which it:

Accepts equalizer coefficients via an external interface, e.g., Ethernet. Sends the coefficients to the CM's pre-equalizer via ranging response message (both set and convolve
modes).

Does not adjust the CM's frequency, timing or power.

6.2.21.4 Filter Distortion

The following requirements assume that any pre-equalization is disabled.

6.2.21.4.1 Amplitude

The spectral mask MUST be the ideal square-root raised-cosine spectrum with alpha = 0.25, within the ranges given in Table 6-12.
Table 6-12 Filter Amplitude Distortion
Frequency low fc - 5Rs/8 fc - Rs/2 fc - 3Rs/8 to fc - Rs/4 fc - Rs/4 to fc + Rs/4 fc + Rs/4 to fc + 3Rs/8 fc + Rs/2 fc + 5Rs/8 -3.5dB -0.5dB -0.3dB -0.5dB -3.5dB Amplitude Range high -30dB -2.5dB +0.3dB +0.3dB +0.3dB -2.5dB -30dB

Where fc is the center frequency, Rs is the modulation rate, and the spectral density is measured with a resolution bandwidth of 10 kHz or less.
6.2.21.4.2 Phase

fc - 5Rs/8 Hz to fc + 5Rs/8 Hz: Group Delay Variation MUST NOT be greater than 100 nsec.
6.2.21.5 Carrier Phase Noise

The upstream transmitter total integrated phase noise (including discrete spurious noise) MUST be less than or equal to -46 dBc summed over the spectral regions spanning 200 Hz to 400 kHz above and below the carrier. The upstream transmitter total integrated phase noise (including discrete spurious noise) MUST be less than or equal to -44 dBc summed over the spectral regions spanning 8 kHz to 3.2 MHz above and below the carrier. The CM MUST provide a test mode in which:

A continuous (non-bursted), unmodulated (CW) upstream signal is transmitted at the commanded carrier
frequency, modulation rate and level. This is equivalent to replacing the chip sequence at the spreader output with the constant sequence (1, 1, 1, 1, 1, 1,...) at nominal amplitude, equal on both I and Q.

96

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normal
synchronous operation.1
6.2.21.6 Channel Frequency Accuracy

The CM MUST implement the assigned channel frequency within 50 parts per million over a temperature range of 0 to 40 degrees C up to five years from date of manufacture.
6.2.21.7 Modulation Rate Accuracy

For TDMA mode, the upstream modulator MUST provide an absolute accuracy of symbol rates 50 parts per million over a temperature range of 0 to 40 degrees C up to five years from date of manufacture. For S-CDMA mode, the upstream modulator MUST lock the upstream chip rate to the downstream symbol rate, subject to the symbol timing jitter requirements of Section 6.2.21.8.
6.2.21.8 6.2.21.8.1 Modulation Timing Jitter Symbol Timing Jitter for Asynchronous Operation

For TDMA mode, peak-to-peak symbol jitter, referenced to the previous symbol zero-crossing, of the transmitted waveform, MUST be less than 0.02 of the nominal symbol duration over a 2-sec period. In other words, the difference between the maximum and the minimum symbol duration during the 2-sec period shall be less than 0.02 of the nominal symbol duration for each of the five upstream symbol rates. For TDMA mode, the peak-to-peak cumulative phase error, referenced to the first symbol time and with any fixed symbol frequency offset factored out, MUST be less than 0.04 of the nominal symbol duration over a 0.1sec period. In other words, the difference between the maximum and the minimum cumulative phase error during the 0.1-sec period shall be less than 0.04 of the nominal symbol duration for each of the five upstream symbol rates. Factoring out a fixed symbol frequency offset is to be done by using the computed mean symbol duration during the 0.1 sec.
6.2.21.8.2 Chip Timing Jitter for Synchronous Operation

All jitter specifications assume a downstream input to the CM per 6.3.5, 6.3.6, 6.3.7.2, 6.3.7.3, 6.3.9, and 6.3.10. For S-CDMA mode, upstream chip clock timing error (with the mean error subtracted out) relative to the CMTS master clock MUST be less than 0.005 RMS of the chip period over a 35-second measurement interval. This applies 1) to the worst-case jitter and frequency drift specified for the CMTS Master clock and the CMTS downstream symbol clock in the requirements above and 2) for any round-trip propagation delay up to the maximum allowed. The CM upstream chip clock SHOULD track the jitter components below 10 Hz in the input downstream symbol clock with an error transfer function below -25 dB. The CM upstream chip clock SHOULD attenuate the jitter components in the input downstream symbol clock above 200 Hz.

1.

Section 6.2.21.5, text from The CM MUST provide to footnote updated per RFI2-N-02102 by RKV on 10/28/02.

97

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM MUST provide a test mode in which:

A continuous (non-bursted) upstream signal is transmitted at the commanded carrier frequency, modulation
rate and level.

The chip sequence at the spreader output is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1,...)
at nominal amplitude, equal on both I and Q.

The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normal
synchronous operation.
6.2.22 Upstream Demodulator Input Power Characteristics

The maximum total input power to the upstream demodulator MUST NOT exceed 35 dBmV in the 5-42 MHz frequency range of operation. The intended received power in each carrier MUST be within the values shown in Table 6-13.
Table 6-13 Maximum Range of Commanded Nominal Receive Power in Each Carrier
Modulation Rate (kHz) 160 320 640 1,280 2,560 5,120 Maximum Range (dBmV) -16 to +14 -13 to +17 -10 to +20 -7 to +23 -4 to +26 -1 to +29

The demodulator MUST operate within its defined performance specifications with received bursts within 6 dB of the nominal commanded received power.
6.2.23 Upstream Electrical Output from the CM

The CM MUST output an RF modulated signal with the characteristics delineated in Table 6-14.

98

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 6-14
Parameter Frequency Level range (one channel)

Electrical Output from CM

Value 5 to 42 MHz edge to edge TDMA: +8 to +54 dBmV (32QAM, 64QAM) +8 to +55 dBmV (8QAM, 16QAM) +8 to +58 dBmV (QPSK) S-CDMA: +8 to +53 dBmV (all modulations)

Modulation Type Modulation Rate (nominal)

QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM TDMA: 160, 320, 640, 1280, 2560 and 5120 kHz S-CDMA: 1280, 2560 and 5120 kHz

Bandwidth

TDMA: 200, 400, 800, 1600, 3200 and 6400 kHz S-CDMA: 1600, 3200 and 6400 kHz

Output impedance Output Return Loss Connector

75 ohms > 6 dB (5-42 MHz) F connector per [ISO-169-24] (common with the input)

6.3

Downstream

6.3.1 Downstream Protocol

The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, Annex B for Low-Delay Video Applications [ITU-T J.83-B], with the exceptions called out in Section 6.3.2.
Note: Any reference in this document to the transmission of television in the forward channel that is not consistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable in European applications. See Section 1 (1.1 Scope).

6.3.2 Scalable Interleaving to Support Low Latency

The downstream PMD sublayer MUST support a variable-depth interleaver with the characteristics defined in Table 6-15. The table contains a subset of interleaver modes found in [ITU-T J.83-B].
Table 6-15 Interleaver Characteristics
I (Number of Taps) 8 16 32 64 128 J (Increment) 16 8 4 2 1 Burst Protection 64QAM/256QAM 5.9 sec/4.1 sec 12 sec/8.2 sec 24 sec/16 sec 47 sec/33 sec 95 sec/66 sec Latency 64QAM/256QAM 0.22 msec/0.15 msec 0.48 msec/0.33 msec 0.98 msec/0.68 msec 2.0 msec/1.4 msec 4.0 msec/2.8 msec

The interleaver depth, which is coded in a 4-bit control word contained in the FEC frame synchronization trailer, always reflects the interleaving in the immediately-following frame. In addition, errors are allowed while the interleaver memory is flushed after a change in interleaving is indicated. Refer to [ITU-T J.83-B] for the control bit specifications required to specify which interleaving mode is used.

99

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.3.3 Downstream Frequency Plan

The downstream frequency plan should comply with Harmonic Related Carrier (HRC), Incremental Related Carrier (IRC) or Standard (STD) North American frequency plans per [EIA-S542]. However, operation below a center frequency of 91 MHz is not required.
6.3.4 CMTS Output Electrical

The CMTS MUST output an RF modulated signal with the following characteristics defined in Table 6-16.
Table 6-16 CMTS Output
Parameter Center Frequency (fc) Level Modulation Type Symbol Rate (nominal) 64QAM 256QAM Nominal Channel Spacing Frequency response 64QAM alpha 256QAM alpha Total Discrete Spurious Inband (fc 3 MHz) Inband Spurious and Noise (fc 3 MHz) ~0.18 Square Root Raised Cosine shaping ~0.12 Square Root Raised Cosine shaping < -57dBc < -48dBc; where channel spurious and noise includes all discrete spurious, noise, carrier leakage, clock lines, synthesizer products, and other undesired transmitter products. Noise within +- 50kHz of the carrier is excluded. < -58 dBc in 750 kHz < -62 dBc, in 5.25 MHz, excluding up to 3 spurs, each of which must be <-60 dBc when measured in a 10 kHz band Less than the greater of -65 dBc or -12dBmV in 6MHz, excluding up to three discrete spurs. The total power in the spurs must be < -60dBc when each is measured with 10 kHz bandwidth. < -12dBmV in each 6 MHz channel, excluding up to three discrete spurs. The total power in the spurs must be < -60dBc when each is measured with 10kHz bandwidth. 1 kHz - 10 kHz: -33dBc double sided noise power 10 kHz - 50 kHz: -51dBc double sided noise power 50 kHz - 3 MHz: -51dBc double sided noise power Output Impedance Output Return Loss Connector
1.

Value 91 to 857 MHz 30 kHz 1 Adjustable over the range 50 to 61 dBmV 64QAM and 256QAM

5.056941 Msym/sec 5.360537 Msym/sec 6 MHz

Adjacent channel (fc 3.0 MHz) to (fc 3.75 MHz) Adjacent channel (fc 3.75 MHz) to (fc 9 MHz) Next adjacent channel (fc 9 MHz) to (fc 15 MHz)

Other channels (47 MHz to 1,000 MHz)

Phase Noise

75 ohms > 14 dB within an output channel up to 750 MHz; > 13 dB in an output channel above 750 MHz F connector per [ISO-169-24]

30 kHz includes an allowance of 25 kHz for the largest FCC frequency offset normally built into upconverters.

100

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.3.5 Downstream Electrical Input to CM

The CM MUST be able to locate and accept RF modulated signals located within channels defined in [EIAS542] for Harmonic Related Carrier (HRC), Incremental Related Carrier (IRC), and Standard (STD) North American frequency plans. Operation below a center frequency of 91 MHz is not required. The signals will have the characteristics defined in Table 6-17, Electrical Input to CM, on page 101.
Table 6-17
Parameter Center Frequency Level Range (one channel) Modulation Type Symbol Rate (nominal) Bandwidth Total Input Power (40-900 MHz) Input (load) Impedance Input Return Loss Connector 91 to 857 MHz 30 kHz -15 dBmV to +15 dBmV 64QAM and 256QAM 5.056941 Msym/sec (64QAM) and 5.360537 Msym/sec (256QAM) 6 MHz (alpha = 0.18 Square Root Raised Cosine shaping for 64QAM and alpha = 0.12 Square Root Raised Cosine shaping for 256QAM) <30 dBmV 75 ohms > 6 dB (88-860 MHz) F connector per [ISO-169-24] (common with the output)

Electrical Input to CM
Value

6.3.6 CM BER Performance

The bit-error-rate performance of a CM MUST be as described in this section. The requirements apply to the I = 128, J = 1 mode of interleaving.
6.3.6.1 6.3.6.1.1 64QAM 64QAM CM BER Performance

Implementation loss of the CM MUST be such that the CM achieves a post-FEC BER less than or equal to 10-8 when operating at a carrier to noise ratio (Es/No) of 23.5 dB or greater.
6.3.6.1.2 64QAM Image Rejection Performance

Performance as described in Section 6.3.6.1.1 MUST be met with analog or digital signal at +10 dBc in any portion of the RF band other than the adjacent channels.
6.3.6.1.3 64QAM Adjacent Channel Performance

Performance as described in Section 6.3.6.1.1 MUST be met with a digital signal at 0 dBc in the adjacent channels. Performance as described in Section 6.3.6.1.1 MUST be met with an analog signal at +10 dBc in the adjacent channels. Performance as described in Section 6.3.6.1.1, with an additional 0.2-dB allowance, MUST be met with a digital signal at +10 dBc in the adjacent channels.

101

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.3.6.2 6.3.6.2.1

256QAM 256QAM CM BER Performance

Implementation loss of the CM MUST be such that the CM achieves a post-FEC BER less than or equal to 10-8 when operating at a carrier to noise ratio (Es/No) as shown below. Input Receive Signal LevelEs/No -6 dBmV to +15dBmV30dB or greater Less than -6dBmV down to -15dBmV33dB or greater
6.3.6.2.2 256QAM Image Rejection Performance

Performance as described in Section 6.3.6.2.1 MUST be met with an analog or a digital signal at +10 dBc in any portion of the RF band other than the adjacent channels.
6.3.6.2.3 256QAM Adjacent Channel Performance

Performance as described in Section 6.3.6.2.1 MUST be met with an analog or a digital signal at 0 dBc in the adjacent channels. Performance as described in Section 6.3.6.2.1, with an additional 0.5-dB allowance, MUST be met with an analog signal at +10 dBc in the adjacent channels. Performance as described in Section 6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with a digital signal at +10 dBc in the adjacent channels.
6.3.7 CMTS Timestamp Jitter

The CMTS timestamp jitter MUST be less than 500 nsec peak-to-peak at the output of the Downstream Transmission Convergence Sublayer. This jitter is relative to an ideal Downstream Transmission Convergence Sublayer that transfers the MPEG packet data to the Downstream Physical Media Dependent Sublayer with a perfectly continuous and smooth clock at the MPEG packet data rate. Downstream Physical Media Dependent Sublayer processing MUST NOT be considered in timestamp generation and transfer to the Downstream Physical Media Dependent Sublayer. Thus, any two timestamps N1 and N2 (N2 > N1) which were transferred to the Downstream Physical Media Dependent Sublayer at times T1 and T2 respectively must satisfy the following relationship: | (N2-N1)/fCMTS - (T2-T1) | < 500x10-9 In the equation, the value of (N2-N1) is assumed to account for the effect of rollover of the timebase counter, and T1 and T2 represent time in seconds. fCMTS is the actual frequency of the CMTS master timebase and may include a fixed frequency offset from the nominal frequency of 10.24 MHz. This frequency offset is bounded by a requirement further below in this section. The jitter includes inaccuracy in timestamp value and the jitter in all clocks. The 500 nsec allocated for jitter at the Downstream Transmission Convergence Sublayer output MUST be reduced by any jitter that is introduced by the Downstream Physical Media Dependent Sublayer.

102

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The CM is expected to meet the burst timing accuracy requirements in Section 6.2.19 when the time stamps contain this worst-case jitter.
Note: Jitter is the error (i.e., measured) relative to the CMTS Master Clock. (The CMTS Master Clock is the 10.24 MHz clock used for generating the timestamps.)

6.3.7.1

CMTS Master Clock Jitter for Asynchronous Operation

The CMTS 10.24 MHz Master Clock MUST have frequency accuracy of 5 ppm, drift rate 10-8 per second, and edge jitter of 10 nsec peak-to-peak (5 nsec) over a temperature range of 0 to 40 degrees C up to ten years from date of manufacture.1 [The drift rate and jitter requirements on the CMTS Master Clock implies that the duration of two adjacent segments of 10,240,000 cycles will be within 30 nsec, due to 10 nsec jitter on each segments duration, and 10 nsec due to frequency drift. Durations of other counter lengths also may be deduced: adjacent 1,024,000 segments, 21 nsec; 1,024,000 length segments separated by one 10,240,000 cycle segment, 30 nsec; adjacent 102,400,000 segments, 120 nsec. The CMTS Master Clock MUST meet such test limits in 99% or more measurements.]
6.3.7.2 CMTS Master Clock Jitter for Synchronous Operation

In addition to the requirements in Section 6.3.7.1, the 10.24 MHz CMTS master clock MUST meet the following double sideband phase noise requirements over the specified frequency ranges: < [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) < [-58 + 20*log(fMC/10.24)] dBc (i.e., < 0.02 nsec RMS) < [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) < [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 10 kHz 10 kHz to fMC/2

where fMC is the frequency of the measured master clock in MHz. The value of fMC MUST be either an integral multiple or divisor of 10.24 MHz. For example, if a 20.48 MHz oscillator is used as the master clock frequency source, and there is no explicit 10.24 MHz clock to test, the 20.48 MHz clock may be used with fMC equal to 20.48 in the above expressions.
6.3.7.3 CMTS Master Clock Frequency Drift for Synchronous Operation

The frequency of the master clock MUST NOT drift more than 1e-8 per second.

1.

This specification MAY also be met by synchronizing the CMTS Master Clock oscillator to an external frequency reference source. If this approach is used, the internal CMTS Master Clock MUST have frequency accuracy of 20ppm over a temperature range of 0 to 40 degrees C up to 10 years from date of manufacture when no frequency reference source is connected. The drift rate and edge jitter MUST be as specified above.

103

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6.3.8 CMTS Clock Generation

The CMTS has the following three options related to the synchronization of the CMTS Master Clock and the Downstream Symbol Clock: 1. Not locked. 2. Downstream Symbol Clock locked to CMTS Master Clock. 3. CMTS Master Clock locked to Downstream Symbol Clock. For S-CDMA operation the Master Clock and the Downstream Symbol Clock MUST be locked using either option 2 or 3. Let fb' represent the rate of the Downstream Symbol Clock which is locked to the CMTS Master Clock and let fm' represent the rate of the CMTS Master Clock locked to the Downstream Symbol Clock. Let fb represent the nominal specified downstream symbol rate and let fm represent the nominal CMTS Master Clock rate (10.24 MHz). With the Downstream Symbol Clock locked to the CMTS Master Clock the following equation MUST hold: fb' = fm*M/N With the CMTS Master Clock locked to the Downstream Symbol Clock the following equation MUST hold: fm' = fb*N/M M and N MUST be unsigned integer values each representable in 16 bits. (These are specified in the channel TLV parameters of the UCD). When the Downstream Symbol Clock and the CMTS Master Clock are not locked together, the values of M and N are not valid and are ignored by the CM.1 The values of M and N MUST result in a value of fb' or fm' which is not more than +/-1 ppm from its specified nominal value. Table 6-18 lists the downstream modes of operation, their associated nominal symbol rates, fb, example values for M and N, the resulting synchronized clock rates, and their offsets from their nominal values.
Table 6-18 Downstream symbol rates and example parameters for synchronization with the CMTS Master Clock
Nominal Specified Symbol Rate, fb (MHz) 5.056941 5.360537

Downstream mode Annex B, 64QAM Annex B, 256QAM

M/N 401/812 78/149

CMTS Master Clock Rate, fm' (MHz) 10.239990... 10.240000...

Downstream Symbol Rate, fb' (MHz) 5.056945... 5.360536...

Offset from Nominal 0.95 ppm 0.02 ppm

1.

Deleted (Sync mode = 0) from paragraph per ECN RFI2-N-02210, by GO, on 11/21/02.

104

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6.3.9 CMTS Downstream Symbol Clock Jitter for Synchronous Operation

The downstream symbol clock MUST meet the following double sideband phase noise requirements over the specified frequency ranges: < [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) < [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) < [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) < [-36 + 20*log(fDS/5.057)] dBc (i.e., < 0.5 nsec RMS) < [-30 + 20*log(fDS/5.057)] dBc (i.e., < 1 nsec RMS) 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 10 kHz 10 kHz to 100 kHz 100 kHz to (fDS /2)

where fDS is the frequency of the measured clock in MHz. The value of fDS MUST be an integral multiple or divisor of the downstream symbol clock. For example, an fDS = 20.227764 MHz clock may be measured if there is no explicit 5.056941 MHz clock available. The CMTS MUST provide a test mode in which:

The downstream QAM symbol sequence is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1,...)
at nominal amplitude, on both I and Q.

The CMTS generates the downstream symbol clock from the 10.24 MHz reference clock as in normal synchronous operation. If an explicit downstream symbol clock which is capable of meeting the above phase noise requirements is available (e.g., a smooth clock without clock domain jitter), this test mode is not required.
6.3.10 CMTS Downstream Symbol Clock Drift for Synchronous Operation

The frequency of the downstream symbol clock MUST NOT drift more than 1e-8 per second.

105

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

106

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

7 Downstream Transmission Convergence Sublayer

7.1 Introduction

This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option, refer to Annex F. In order to improve demodulation robustness, facilitate common receiving hardware for both video and data, and provide an opportunity for the possible future multiplexing of video and data over the PMD sublayer bitstream defined in Section 6, a sublayer is interposed between the downstream PMD sublayer and the Data-Over-Cable MAC sublayer. The downstream bitstream is defined as a continuous series of 188-byte MPEG [ITU-T H.222.0] packets. These packets consist of a 4-byte header followed by 184 bytes of payload. The header identifies the payload as belonging to the Data-Over-Cable MAC. Other values of the header may indicate other payloads. The mixture of MAC payloads and those of other services is optional and is controlled by the CMTS. Figure 7-1 illustrates the interleaving of Data-Over-Cable (DOC) MAC bytes with other digital information (digital video in the example shown).

header=DOC header=video header=video header=DOC header=video header=DOC header=video header=video header=video

DOC MAC payload digital video payload digital video payload DOC MAC payload digital video payload DOC MAC payload digital video payload digital video payload digital video payload

Figure 7-1 Example of Interleaving MPEG Packets in Downstream

7.2

MPEG Packet Format

The format of an MPEG Packet carrying DOCSIS data is shown in Figure 7-2. The packet consists of a 4-byte MPEG Header, a pointer_field (not present in all packets) and the DOCSIS Payload.

MPEG Header (4 bytes)

pointer_field (1 byte)

DOCSIS Payload (183 or 184 bytes)

Figure 7-2

Format of an MPEG Packet

107

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

7.3

MPEG Header for DOCSIS Data-Over-Cable

The format of the MPEG Transport Stream header is defined in section 2.4 of [ITU-T H.222.0]. The particular field values that distinguish Data-Over-Cable MAC streams are defined in Table 7-1. Field names are from the ITU specification. The MPEG Header consists of 4 bytes that begin the 188-byte MPEG Packet. The format of the header for use on a DOCSIS Data-Over-Cable PID is restricted to that shown in Table 7-1. The header format conforms to the MPEG standard, but its use is restricted in this specification to NOT ALLOW inclusion of an adaptation_field in the MPEG packets.
Table 7-1
Field sync_byte transport_error_indicator

MPEG Header Format for DOCSIS Data-Over-Cable Packets

Length (bits) 8 1 Description 0x47; MPEG Packet Sync byte Indicates an error has occurred in the reception of the packet. This bit is reset to zero by the sender, and set to one whenever an error occurs in transmission of the packet A value of one indicates the presence of a pointer_field as the first byte of the payload (fifth byte of the packet) Reserved; set to zero DOCSIS Data-Over-Cable well-known PID (0x1FFE) Reserved, set to 00 01; use of the adaptation_field is NOT ALLOWED on the DOCSIS PID cyclic counter within this PID

payload_unit_start_indicator transport_priority PID transport_scrambling_control adaptation_field_control continuity_counter

1 1 13 2 2 4

7.4

MPEG Payload for DOCSIS Data-Over-Cable

The MPEG payload portion of the MPEG packet will carry the DOCSIS MAC frames. The first byte of the MPEG payload will be a pointer_field if the payload_unit_start_indicator (PUSI) of the MPEG header is set.
7.4.1 stuff_byte

This standard defines a stuff_byte pattern having a value (0xFF) that is used within the DOCSIS payload to fill any gaps between the DOCSIS MAC frames. This value is chosen as an unused value for the first byte of the DOCSIS MAC frame. The FC byte of the MAC Header will be defined to never contain this value. (FC_TYPE = 11 indicates a MAC-specific frame, and FC_PARM = 11111 is not currently used and, according to this specification, is defined as an illegal value for FC_PARM.)
7.4.2 pointer_field

The pointer_field is present as the fifth byte of the MPEG packet (first byte following the MPEG header) whenever the PUSI is set to one in the MPEG header. The interpretation of the pointer_field is as follows: The pointer_field contains the number of bytes in this packet that immediately follow the pointer_field that the CM decoder must skip past before looking for the beginning of an DOCSIS MAC Frame. A pointer field MUST be present if it is possible to begin a Data-Over-Cable MAC Frame in the packet, and MUST point to either: 1. the beginning of the first MAC frame to start in the packet, or 2. to any stuff_byte preceding the MAC frame.
108

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

7.5

Interaction with the MAC Sublayer

MAC frames may begin anywhere within an MPEG packet, MAC frames may span MPEG packets, and several MAC frames may exist within an MPEG packet. The following figures show the format of the MPEG packets that carry DOCSIS MAC frames. In all cases, the PUSI flag indicates the presence of the pointer_field as the first byte of the MPEG payload. Figure 7-3 shows a MAC frame that is positioned immediately after the pointer_field byte. In this case, pointer_field is zero, and the DOCSIS decoder will begin searching for a valid FC byte at the byte immediately following the pointer_field.

MPEG Header (PUSI = 1)

pointer_field (= 0)

MAC Frame (up to 183 bytes)

stuff_byte(s) (0 or more)

Figure 7-3 Packet Format Where a MAC Frame Immediately Follows the pointer_field

Figure 7-4 shows the more general case where a MAC Frame is preceded by the tail of a previous MAC Frame and a sequence of stuffing bytes. In this case, the pointer_field still identifies the first byte after the tail of Frame #1 (a stuff_byte) as the position where the decoder should begin searching for a legal MAC sublayer FC value. This format allows the multiplexing operation in the CMTS to immediately insert a MAC frame that is available for transmission if that frame arrives after the MPEG header and pointer_field have been transmitted. In order to facilitate multiplexing of the MPEG packet stream carrying DOCSIS data with other MPEG-encoded data, the CMTS SHOULD NOT transmit MPEG packets with the DOCSIS PID which contain only stuff_bytes in the payload area. MPEG null packets SHOULD be transmitted instead. Note that there are timing relationships implicit in the DOCSIS MAC sublayer which must also be preserved by any MPEG multiplexing operation.

MPEG Header (PUSI = 1)

pointer_field (= M)

Tail of MAC Frame #1 (M bytes)

stuff_byte(s) (0 or more)

Start of MAC Frame #2

Figure 7-4

Packet Format with MAC Frame Preceded by Stuffing Bytes

Figure 7-5 shows that multiple MAC frames may be contained within the MPEG packet. The MAC frames may be concatenated one after the other or be separated by an optional sequence of stuffing bytes.

MPEG Header (PUSI = 1)

pointer_field (= 0)

MAC Frame #1

MAC Frame #2

stuff_byte(s) (0 or more)

MAC Frame #3

Figure 7-5

Packet Format Showing Multiple MAC Frames in a Single Packet

109

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Figure 7-6 shows the case where a MAC frame spans multiple MPEG packets. In this case, the pointer_field of the succeeding frame points to the byte following the last byte of the tail of the first frame.

MPEG Header (PUSI = 1) MPEG Header (PUSI = 0) MPEG Header (PUSI = 1)

pointer_field (= 0)

stuff_bytes (0 or more)

Start of MAC Frame #1 (up to 183 bytes)

Continuation of MAC Frame #1 (184 bytes) pointer_field (= M) Tail of MAC Frame #1 (M bytes) stuff_byte(s) (0 or more) Start of MAC Frame #2 (M bytes)

Figure 7-6

Packet Format Where a MAC Frame Spans Multiple Packets

The Transmission Convergence sublayer must operate closely with the MAC sublayer in providing an accurate timestamp to be inserted into the Time Synchronization message (refer to Section 8.3.2 and Section 9.3).

7.6

Interaction with the Physical Layer

The MPEG-2 packet stream MUST be encoded according to [ITU-T J.83-B], including MPEG-2 transport framing using a parity checksum as described in [ITU-T J.83-B].

7.7

MPEG Header Synchronization and Recovery

The MPEG-2 packet stream SHOULD be declared in frame (i.e., correct packet alignment has been achieved) when five consecutive correct parity checksums, each 188 bytes from the previous one, have been received. The MPEG-2 packet stream SHOULD be declared out of frame, and a search for correct packet alignment started, when nine consecutive incorrect parity checksums are received. The format of MAC frames is described in detail in Section 8.

110

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8 Media Access Control Specification

8.1 Introduction

8.1.1 Overview

This section describes version 2.0 of the DOCSIS MAC protocol. Some of the MAC protocol highlights include:

Bandwidth allocation controlled by CMTS A stream of mini-slots in the upstream Dynamic mix of contention- and reservation-based upstream transmit opportunities Bandwidth efficiency through support of variable-length packets Extensions provided for future support of ATM or other Data PDU Quality-of-service including:

Support for Bandwidth and Latency Guarantees Packet Classification Dynamic Service Establishment Extensions provided for security at the data link layer Support for a wide range of data rates
8.1.2 Definitions 8.1.2.1 MAC-Sublayer Domain

A MAC-sublayer domain is a collection of upstream and downstream channels for which a single MAC Allocation and Management protocol operates. Its attachments include one CMTS and some number of CMs. The CMTS MUST service all of the upstream and downstream channels; each CM accesses one logical upstream and one downstream channel at a time. The CMTS MUST police and discard any packets received that have a source MAC address that is not a unicast MAC address. The upstream channels may be any combination of DOCSIS 1.x or 2.0 formats. A single upstream channel MAY transport DOCSIS 1.x and 2.0 bursts.
8.1.2.2 MAC Service Access Point

A MAC Service Access Point (MSAP) is an attachment to a MAC-sublayer domain. (Refer to Section 5.2)
8.1.2.3 Service Flows

The concept of Service Flows is central to the operation of the MAC protocol. Service Flows provide a mechanism for upstream and downstream Quality of Service management. In particular, they are integral to bandwidth allocation. A Service Flow ID defines a particular unidirectional mapping between a CM and the CMTS. Active Upstream Service Flow IDs also have associated Service IDs or SIDs. Upstream bandwidth is allocated to SIDs, and hence to CMs, by the CMTS. Service IDs provide the mechanism by which upstream Quality of Service is implemented.

111

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CMTS MAY assign one or more Service Flow IDs (SFIDs) to each CM, corresponding to the Service Flows required by the CM. This mapping can be negotiated between the CMTS and the CM during CM registration or via dynamic service establishment (refer to Section 11.4). In a basic CM implementation, two Service Flows (one upstream, one downstream) could be used, for example, to offer best-effort IP service. However, the Service Flow concept allows for more complex CMs to be developed with support for multiple service classes while supporting interoperability with more basic modems. With these more complex modems, it is possible that certain Service Flows will be configured in such a way that they cannot carry all types of traffic. That is, they may have a maximum packet size limitation or be restricted to small fixed size unsolicited grants. Furthermore it might not be appropriate to send other kinds of data on Service Flows that are being used for Constant Bit Rate (CBR)-type applications. Even in these complex modems, it is necessary to be able to send certain upstream packets needed for MAC management, SNMP management, key management, etc. For the network to function properly, all CMs MUST support at least one upstream and one downstream Service Flow. These Service Flows MUST always be provisioned to allow the CM to request and to send the largest possible unconcatenated MAC frame (refer to Section 8.2.2). These Service Flows are referred to as the upstream and downstream Primary Service Flows. The SID assigned to the upstream Primary Service Flow is referred to as the Primary SID. The Primary SID MUST always be assigned to the first provisioned upstream Service Flow during the registration process (which may or may not be the same temporary SID used for the registration process). The Primary Service Flows MUST be immediately activated at registration time. The Primary SID MUST always be used for periodic ranging after registration. The Primary Service Flows MAY be used for traffic. All unicast Service Flows MUST use the security association defined for the Primary Service Flow. (Refer to [DOCSIS8]) All Service Flow IDs are unique within a single MAC-sublayer domain. The mapping of a unicast Service Identifier to an active/admitted Service Flow MUST be unique within a single MAC-sublayer domain. The length of the Service Flow ID is 32 bits. The length of the Service ID is 14 bits (although the Service ID is sometimes carried in the low-order bits of a 16-bit field).
8.1.2.4 Upstream Intervals, Mini-Slots and 6.25-Microsecond Increments

The upstream transmission time-line is divided into intervals by the upstream bandwidth allocation mechanism. Each interval is an integral number of mini-slots. A mini-slot is the unit of granularity for upstream transmission opportunities. There is no implication that any PDU can actually be transmitted in a single minislot. Each interval is labelled with a usage code which defines both the type of traffic that can be transmitted during that interval and the physical-layer modulation encoding. The usage code values are defined in Table 8-20 and allowed use is defined in Section 8.3. The binding of these values to physical-layer parameters is defined in Table 8-18.
8.1.2.4.1 TDMA mode

For DOCSIS 1.x channels, a mini-slot is a power-of-two multiple of 6.25s increments, i.e., 2, 4, 8, 16, 32, 64, or 128 times 6.25s. For DOCSIS 2.0 TDMA, a mini-slot is a power-of-two multiple of 6.25s increments: 1, 2, 4, 8, 16, 32, 64, or 128 times 6.25s. The relationship between mini-slots, bytes, and time ticks is described further in Section 9.3.4.

112

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.1.2.4.2

S-CDMA mode

For DOCSIS 2.0 S-CDMA channels, a mini-slot is not restricted to be a power-of-two multiple of 6.25s increments. Instead a mini-slot is a unit of capacity that is dependent on the modulation rate, number of spreading codes, and number of spreading intervals configured for the upstream channel.1 While the channel may be configured such that the time duration of a mini-slot is a power-of-two multiple of 6.25s increments, there is no special significance to 6.25s time ticks for S-CDMA channels. The relationship between mini-slots and S-CDMA framing is described further in Section 6.2.11. The relationship between mini-slots, bytes, and time ticks is described further in Section 9.3.4.
8.1.2.5 MAC Frame

A MAC layer frame is a unit of data exchanged between two (or more) entities at the Data Link Layer. A MAC frame consists of a MAC Header (beginning with a Frame Control byte; see Figure 8-3), and may incorporate a variable-length data PDU. The variable-length PDU includes a pair of 48-bit addresses, data, and a CRC. In special cases, the MAC Header may encapsulate multiple MAC frames (see Section 8.2.5.5) into a single MAC frame. The MAC layer definition of a frame is different from any physical layer or MPEG layer definition of a frame.
8.1.2.6 Logical Upstream Channels

The MAC layer deals with logical upstreams. A logical upstream is identified with an upstream channel ID which is unique within the MSAP. A logical upstream consists of a contiguous stream of mini-slots which are described and allocated by the UCD and MAP messages associated with a channel ID. A CM can only register to operate on a single logical upstream channel. There are 4 distinct types of logical upstream:

Type 1: DOCSIS 1.x upstreams that support no DOCSIS 2.0 TDMA features. Type 2: Mixed upstreams that support DOCSIS 1.x and DOCSIS 2.0 TDMA bursts. Type 3A: DOCSIS 2.0 TDMA only upstreams that cannot support DOCSIS 1.x CMs. Type 3S: S-CDMA upstreams that support only CMs operating in S-CDMA mode.2
All valid logical upstreams fall into one of these 4 categories. In DOCSIS 2.0 it is possible for multiple logical upstreams to share the same spectrum. When this occurs the logical upstreams sharing the same spectrum are time domain multiplexed and only one is active at any time.The only exception to this rule is that it is possible for the Broadcast Initial Maintenance regions to be simultaneous. When a logical upstream channel is inactive its mini-slots are allocated to the NULL SID by its associated MAP messages. Having multiple logical upstreams that share the same spectrum is the only way to have modems operating in S-CDMA mode share the same upstream spectrum with modems not operating in S-CDMA mode. The CMTS MUST support all four logical upstream channel types individually, and MUST also support the following three combinations of two logical upstream channels sharing the same upstream spectrum:

One DOCSIS 1.x-only logical channel plus one S-CDMA logical channel with the same modulation rate on
both logical channels
1.

This relationship holds true on an S-CDMA channel even if the burst parameters for a particular IUC have the spreader disabled. Revised these four bulleted statements per ECN RFI2-N-02210, by GO, on 11/21/02.

2.

113

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

One mixed DOCSIS 1.x and A-TDMA logical channel plus one S-CDMA logical channel with the same
modulation rate on both logical channels

One A-TDMA-only logical channel plus one S-CDMA logical channel with the same modulation rate on
both logical channels The CMTS MAY support other combinations of logical channels sharing the same upstream spectrum, including combinations of logical channels with different modulation rates.
8.1.2.7 DOCSIS 2.0 Only Logical Upstreams

DOCSIS 2.0 Only Logical Upstreams have operational parameters in their associated UCD messages that prevent the operation of DOCSIS 1.x CMs. See Section 8.3.3 for a detailed description of which parameter values make a channel a DOCSIS 2.0 Only Upstream. The UCD messages for DOCSIS 2.0 Only Logical Upstreams use a different MAC management message type (see Section 8.3.1) than do UCD messages for channels that can support 1.x CMs. This prevents 1.x CMs from attempting to use DOCSIS 2.0 Only Upstreams or from being confused by UCD messages for those channels. A logical upstream is a DOCSIS 2.0 Only upstream if and only if it is an S-CDMA upstream or a DOCSIS 2.0 TDMA only upstream.
8.1.3 Future Use

A number of fields are defined as being for future use or Reserved in the various MAC frames described in this document. These fields MUST NOT be interpreted or used in any manner by this version (2.0) of the MAC protocol.

8.2

MAC Frame Formats

8.2.1 Generic MAC Frame Format

A MAC frame is the basic unit of transfer between MAC sublayers at the CMTS and the cable modem. The same basic structure is used in both the upstream and downstream directions. MAC frames are variable in length. The term frame is used in this context to indicate a unit of information that is passed between MAC sublayer peers. This is not to be confused with the term framing that indicates some fixed timing relationship. There are three distinct regions to consider, as shown in Figure 8-1. Preceding the MAC frame is either PMD sublayer overhead (upstream) or an MPEG transmission convergence header (downstream). The first part of the MAC frame is the MAC Header. The MAC Header uniquely identifies the contents of the MAC frame. Following the header is the optional Data PDU region. The format of the Data PDU and whether it is even present is described in the MAC Header.
PMD Overhead (upstream)

MAC Header

Data PDU (optional)

(see Figure 8-3)

MPEG PSI Header (downstream)

(see Figure 8-4)

(see Table 7-1)

MAC Frame

Figure 8-1

Generic MAC Frame Format

114

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.2.1.1

PMD Overhead

In the upstream direction, the PHY layer indicates the start of the MAC frame to the MAC sublayer. From the MAC sublayers perspective, it only needs to know the total amount of overhead so it can account for it in the Bandwidth Allocation process. More information on this may be found in the PMD Sublayer section of this document (Section 6). The FEC overhead is spread throughout the MAC frame and is assumed to be transparent to the MAC data stream. The MAC sublayer does need to be able to account for the overhead when doing Bandwidth Allocation. More information on this may be found in the Upstream Bandwidth Allocation section of this document (refer to Section 9.1).
8.2.1.2 MAC Frame Transport

The transport of MAC frames by the PMD sublayer for upstream channels is shown in Figure 8-2.
Upper Layer

MAC Frame

MAC Frame

MAC Frame

MAC Sublayer

PMD Sublayer
Start of Burst at Mini-slot boundary Start of Burst at Mini-slot boundary Start of Burst at Mini-slot boundary

PMD overhead

Data

FEC

PMD overhead

Data

FEC

PMD overhead

Data

FEC

Data

FEC

Data

FEC

PMD overhead

PMD overhead

PMD overhead

Figure 8-2

Upstream MAC/PMD Convergence

The layering of MAC frames over MPEG in the downstream channel is described in Section 7. Note that the CMTS PHY ensures that the CMTS MAC receives upstream MAC frames in the same order the CM mapped the MAC frames onto mini-slots. That is to say that if MAC frame X begins in mini-slot n and MAC frame Y begins in mini-slot n+m, then the CMTS MAC will receive X before it receives Y. This is true even when, as is possible with S-CDMA, mini-slots n and n+m are actually simultaneously transmitted within the PHY layer.
8.2.1.3 Ordering of Bits and Octets

Within an octet, the least-significant bit is the first transmitted on the wire. This follows the convention used by Ethernet and [ISO8802-3]. This is often called bit-little-endian order.1
1.

This applies to the upstream channel only. For the downstream channel, the MPEG transmission convergence sublayer presents an octet-wide interface to the MAC, so the MAC sublayer does not define the bit order.

115

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Within the MAC layer, when numeric quantities are represented by more than one octet (i.e., 16-bit and 32-bit values), the octet containing the most-significant bits is the first transmitted on the wire. This is sometimes called byte-big-endian order. This section follows the textual convention that when bit-fields are presented in tables, the most-significant bits are topmost in the table. For example, in Table 8-2, FC_TYPE occupies the two most-significant bits and EHDR_ON occupies the least-significant bit.
8.2.1.3.1 Representing Negative Numbers

Signed integer values MUST be transmitted and received in twos complement format.
8.2.1.3.2 Type-Length-Value Fields

Many MAC messages incorporate Type-Length-Value (TLV) fields. TLV fields are unordered lists of TLVtuples. Some TLVs are nested (see Annex C). All TLV Length fields, except for EH_LEN (see Section 8.2.6), MUST be greater than zero. Unless otherwise specified, Type is one byte and Length is one byte. Using this encoding, new parameters may be added which some devices cannot interpret. A CM or CMTS which does not recognize a parameter type MUST skip over this parameter and MUST NOT treat the event as an error condition.
8.2.1.4 MAC Header Format

The MAC Header format MUST be as shown in Figure 8-3.

FC (1 byte)

MAC_PARM (1 byte)

LEN (SID) (2 bytes)

EHDR (0-240 bytes)

HCS (2 bytes)

FC TYPE (2 bits)

FC PARM (5 bits)

EHDR_ON (1 bit)

Figure 8-3 MAC Header Format

All MAC Headers MUST have the general format as shown in Table 8-1. The Frame Control (FC) field is the first byte and uniquely identifies the rest of the contents within the MAC Header. The FC field is followed by 3 bytes of MAC control; an OPTIONAL Extended Header field (EHDR); plus a Header Check Sequence (HCS) to ensure the integrity of the MAC Header.

116

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-1 Generic MAC Header Format

MAC Header Field FC MAC_PARM Usage Frame Control: Identifies type of MAC Header Parameter field whose use is dependent on FC: if EHDR_ON=1; used for EHDR field length (ELEN) else if for concatenated frames (see Table 8-10) used for MAC frame count else (for Requests only) indicates the number of mini-slots requested LEN (SID) The length of the MAC frame. The length is defined to be the sum of the number of bytes in the extended header (if present) and the number of bytes following the HCS field. (For a REQ Header, this field is the Service ID instead) Extended MAC Header (where present; variable size). MAC Header Check Sequence Length of a MAC Header 16 bits Size 8 bits 8 bits

EHDR HCS

0-240 bytes 2 bytes 6 bytes + EHDR

The HCS field is a 16-bit CRC that ensures the integrity of the MAC Header, even in a collision environment. The HCS field coverage MUST include the entire MAC Header, starting with the FC field and including any EHDR field that may be present. The HCS is calculated using CRC-CCITT (x16 + x12 + x5 + 1) as defined in [ITU-T X.25]. The FC field is broken down into the FC_TYPE sub-field, FC_PARM sub-field and an EHDR_ON indication flag. The format of the FC field MUST be as shown in Table 8-2.
Table 8-2
FC Field FC_TYPE MAC Frame Control Type field: 00: Packet PDU MAC Header 01: ATM PDU MAC Header 10: Reserved PDU MAC Header 11: MAC Specific Header FC_PARM EHDR_ON Parameter bits, use dependent on FC_TYPE. When = 1, indicates that EHDR field is present. [Length of EHDR (ELEN) determined by MAC_PARM field] 5 bits 1 bit

FC Field Format
Usage Size 2 bits

The FC_TYPE sub-field is the two MSBs of the FC field. These bits MUST always be interpreted in the same manner to indicate one of four possible MAC frame formats. These types include: MAC Header with Packet PDU; MAC Header with ATM cells; MAC Header reserved for future PDU types; or a MAC Header used for specific MAC control purposes. These types are spelled out in more detail in the remainder of this section. The five bits following the FC_TYPE sub-field is the FC_PARM sub-field. The use of these bits are dependent on the type of MAC Header. The LSB of the FC field is the EHDR_ON indicator. If this bit is set, then an Extended Header (EHDR) is present. The EHDR provides a mechanism to allow the MAC Header to be extensible in an inter-operable manner. The Transmission Convergence Sublayer stuff-byte pattern is defined to be a value of 0xFF. This precludes the use of FC byte values which have FC_TYPE = 11 and FC_PARM = 11111.

117

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The MAC_PARM field of the MAC Header serves several purposes depending on the FC field. If the EHDR_ON indicator is set, then the MAC_PARM field MUST be used as the Extended Header length (ELEN). The EHDR field may vary from 0 to 240 bytes. If this is a concatenation MAC Header, then the MAC_PARM field represents the number of MAC frames (CNT) in the concatenation (see Section 8.2.5.5). If this is a Request MAC Header (REQ) (see Section 8.2.5.3), then the MAC_PARM field represents the amount of bandwidth being requested. In all other cases, the MAC_PARM field is reserved for future use. The third field has two possible uses. In most cases, it indicates the length (LEN) of this MAC frame. In one special case, the Request MAC Header, it is used to indicate the cable modems Service ID since no PDU follows the MAC Header. The Extended Header (EHDR) field provides extensions to the MAC frame format. It is used to implement data link security as well as frame fragmentation, and can be extended to add support for additional functions in future releases. Initial implementations SHOULD pass this field to the processor. This will allow future software upgrades to take advantage of this capability. (Refer to Section 8.2.6 for details.)
8.2.1.5 Data PDU

The MAC Header may be followed by a Data PDU. The type and format of the Data PDU is defined in the Frame Control field of the MAC Header. The FC field explicitly defines a Packet Data PDU, an ATM Data PDU, a MAC-Specific Frame and a reserved code point (used as an escape mechanism for future extensions). All CMs MUST use the length in the MAC Header to skip over any reserved data.
8.2.2 Packet-Based MAC Frames 8.2.2.1 Variable-Length Packets

The MAC sublayer MUST support a variable-length Ethernet/[ISO8802-3]-type Packet Data PDU. With the exception of packets which have been subject to Payload Header suppression, the Packet PDU MUST be passed across the network in its entirety, including its original CRC. In the case where Payload Header Suppression has been applied to the Packet PDU, all bytes except those suppressed MUST be passed across the network and the CRC covers only those bytes actually transmitted (Refer to Section 8.2.6.3.1). A unique Packet MAC Header is appended to the beginning. The frame format without an Extended header MUST be as shown in Figure 8-4 and Table 8-3.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

HCS (2 bytes)

Packet PDU1 (18-1518 bytes)

FC TYPE = 00

FC PARM = 00000

EHDR_ON =0

DA (6 bytes)

SA (6 bytes)

Type/Len (2 bytes)

User Data 0-1500

CRC (4 bytes)

1 Frame size is limited to 1518 bytes in the absence of VLAN tagging. Cooperating devices which implement IEEE 802.1Q VLAN tagging MAY use a frame size up to 1522 bytes.

Figure 8-4 Ethernet/802.3 Packet PDU Format

118

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-3 Packet PDU Format

Field FC Usage FC_TYPE = 00; Packet MAC Header FC_PARM[4:0] = 00000; other values reserved for future use and ignored EHDR_ON = 0 if there is no extended header, 1 if there is an EHDR MAC_PARM LEN EHDR HCS Packet Data Packet PDU: MAC_PARM = x; MUST be set to zero if there is no EHDR; Otherwise set to length of EHDR LEN = n+x; length of Packet PDU in bytes + length of EHDR Extended MAC Header, if present MAC Header Check Sequence DA - 48 bit Destination Address SA - 48 bit Source Address Type/Len - 16 bit Ethernet Type or [ISO8802-3] Length Field User Data (variable length, 0-1500 bytes) CRC - 32-bit CRC over packet PDU (as defined in Ethernet/[ISO8802-3]) Length of Packet MAC frame 6 + x + n bytes 16 bits x (0-240) bytes 16 bits n bytes 8 bits 8 bits Size

Under certain circumstances (see VI) it may be necessary to transmit a packet PDU MAC frame without an actual PDU. This is done so that the extended header can be used to carry certain information about the state of the service flow. This could also happen as a result of PHS (see Section 8.2.6.3.1). Such a frame will have the length field in MAC header set to the length of the extended header and will have no packet data, and therefore no CRC. This can only happen with frames transmitted on the upstream as frames transmitted on the downstream always have at least the DA and SA fields of the packet PDU.
8.2.3 ATM Cell MAC Frames

The FC_TYPE 0x01 is reserved for future definition of ATM Cell MAC Frames. This FC_TYPE field in the MAC Header indicates that an ATM PDU is present. This PDU MUST be silently discarded by MAC implementations of this version (2.0) of the specification. Compliant version 2.0 implementations MUST use the length field to skip over the ATM PDU
8.2.4 Reserved PDU MAC Frames

The MAC sublayer provides a reserved FC code point to allow for support of future (to be defined) PDU formats. The FC field of the MAC Header indicates that a Reserved PDU is present. This PDU MUST be silently discarded by MAC implementations of this version (2.0) of the specification. Compliant version 2.0 implementations MUST use the length field to skip over the Reserved PDU.

119

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The format of the Reserved PDU without an extended header MUST be as shown in Figure 8-5 and Table 8-4.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

HCS (2 bytes)

Reserved PDU (n bytes)

FC TYPE = 10

FC PARM = RRRRR

EHDR_ON =0

Figure 8-5

Reserved PDU Format

Table 8-4 Reserved PDU Format

Field FC Usage FC_TYPE = 10; Reserved PDU MAC Header FC_PARM[4:0]; reserved for future use EHDR_ON = 0 if there is no extended header, 1 if there is an EHDR MAC_PARM LEN EHDR HCS User Data MAC_PARM = x; MUST be set to zero if there is no EHDR; Otherwise set to length of EHDR LEN = n+x; length of Reserved PDU + length of EHDR in bytes Extended MAC Header, if present MAC Header Check Sequence Reserved Data PDU Length of Reserved PDU MAC frame 16 bits x (0-240) bytes 16 bits n bytes 6 + x + n bytes 8 bits

Size
8 bits

8.2.5 MAC-Specific Headers

There are several MAC Headers which are used for very specific functions. These functions include support for downstream timing and upstream ranging/power adjust, requesting bandwidth, fragmentation and concatenating multiple MAC frames. Table 8-5 describes FC_PARM usage within the MAC Specific Header.
Table 8-5 MAC-Specific Headers and Frames
FC_PARM 00000 00001 00010 00011 11100 Header/Frame Type Timing Header MAC Management Header Request Frame Fragmentation Header Concatenation Header

120

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.2.5.1 Timing Header

A specific MAC Header is identified to help support the timing and adjustments required. In the downstream, this MAC Header MUST be used to transport the Global Timing Reference to which all cable modems synchronize. In the upstream, this MAC Header MUST be used as part of the Ranging message needed for a cable modems timing and power adjustments. The Timing MAC Header is followed by a Packet Data PDU. The format MUST be as shown in Figure 8-6 and Table 8-6.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

HCS (2 bytes)

Packet PDU (various lengths)

FC TYPE = 11

FC PARM = 00000

EHDR_ON =0

Figure 8-6 Timing MAC Header Table 8-6 Timing MAC Header Format
Field FC Usage FC_TYPE = 11; MAC Specific Header FC_PARM[4:0] = 00000; Timing MAC Header EHDR_ON = 0; Extended header prohibited for SYNC and RNG-REQ MAC_PARM LEN EHDR HCS Packet Data Reserved for future use LEN = n; Length of Packet PDU in bytes Extended MAC Header not present MAC Header Check Sequence MAC Management message: SYNC message (downstream only) RNG-REQ (upstream only) Length of Timing Message MAC frame 6 + n bytes 8 bits 16 bits 0 bytes 2 bytes n bytes Size 8 bits

121

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.2.5.2

MAC Management Header

A specific MAC Header is identified to help support the MAC management messages required. This MAC Header MUST be used to transport all MAC management messages (refer to Section 8.3). The format MUST be as shown Figure 8-7 and Table 8-7.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

HCS (2 bytes)

MAC mgmt msg (24-1522 bytes)

FC TYPE = 11

FC PARM = 00001

EHDR_ON =0

Figure 8-7 Management MAC Header

Table 8-7
Field FC

MAC Management Format

Usage

Size
8 bits

FC_TYPE = 11; MAC Specific Header FC_PARM[4:0] = 00001; Management MAC Header EHDR_ON = 0 if there is no extended header, 1 if there is an EHDR

MAC_PARM LEN EHDR HCS Packet Data

MAC_PARM = x; MUST be set to zero if there is no EHDR; Otherwise set to length of EHDR LEN = n+x; length of MAC management message + length of EHDR in bytes Extended MAC Header, if present MAC Header Check Sequence MAC management message Length of Packet MAC frame

8 bits 16 bits x (0-240) bytes 16 bits n bytes 6 + x + n bytes

8.2.5.3

Request Frame

The Request Frame is the basic mechanism that a cable modem uses to request bandwidth. As such, it is only applicable in the upstream. There MUST be no Data PDUs following the Request Frame. The general format of

122

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

the Request MUST be as shown in Figure 8-8 and Table 8-8.

FC (1 byte)

MAC_PARM (1 byte)

SID (2 bytes)

HCS (2 bytes)

FC TYPE = 11

FC PARM = 00010

EHDR_ON =0

Figure 8-8 Request Frame Format

Table 8-8
Field

Request Frame (REQ) Format

Usage Size

FC

FC_TYPE = 11; MAC-Specific Header FC_PARM[4:0] = 00010; MAC Header only; no data PDU following EHDR_ON = 0; No EHDR allowed

8 bits

MAC_PARM SID EHDR HCS

REQ, total number of mini-slots requested Service ID (0...0x1FFF) Extended MAC Header not allowed MAC Header Check Sequence Length of a REQ MAC Header 6 bytes

8 bits 16 bits 0 bytes 2 bytes

Because the Request Frame does not have a Data PDU following it, the LEN field is not needed. The LEN field MUST be replaced with an SID. The SID MUST uniquely identify a particular Service Flow within a given CM. The bandwidth request, REQ, MUST be specified in mini-slots. The REQ field MUST indicate the current total amount of bandwidth requested for this service queue including appropriate allowance for the PHY overhead.
8.2.5.4 Fragmentation Header

The Fragmentation MAC Header provides the basic mechanism to split a larger MAC PDU into smaller pieces that are transmitted individually and then re-assembled at the CMTS. As such, it is only applicable in the upstream. The general format of the Fragmentation MAC Header MUST be as shown in Figure 8-9. A compliant CM MUST support fragmentation. A compliant CMTS MUST support fragmentation. To decrease the burden on the CMTS and to reduce unnecessary overhead, fragmentation headers MUST NOT be used on unfragmented frames.1

1.

Revised this paragraph per ECN RFI v2.0-N-04.0177-2 by GO on 10/18/04.

123

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

EHDR (6 bytes)

HCS (2 bytes)

Fragment Data

FCRC (4 bytes)

FC TYPE = 11

FC PARM = 00011

EHDR_ON =1

EH_TYPE = 0011

EH_LEN = 0101

EH_VALUE (5 bytes)

Figure 8-9

Fragmentation MAC Header Format

Table 8-9
Field

Fragmentation MAC Frame (FRAG) Format

Usage Size

FC

FC_TYPE = 11; MAC-Specific Header FC_PARM [4:0] = 00011; Fragmentation MAC Header EHDR_ON = 1; Fragmentation EHDR follows

8 bits

MAC_PARM LEN EHDR HCS Fragment Data FCRC

ELEN = 6 bytes; length of Fragmentation EHDR LEN = length of fragment payload + EHDR length + FCRC length Refer to Section 8.2.6.2 MAC Header Check Sequence Fragment payload; portion of total MAC PDU being sent CRC - 32-bit CRC over Fragment Data payload (as defined in Ethernet/[ISO8802-3]) Length of a MAC Fragment Frame 16 + n bytes

8 bits 16 bits 6 bytes 2 bytes n bytes 4 bytes

8.2.5.5

Concatenation Header

A Specific MAC Header is defined to allow multiple MAC frames to be concatenated. This allows a single MAC burst to be transferred across the network. The PHY overhead1 and the Concatenation MAC Header only occur once. Concatenation of multiple MAC frames MUST be as shown in Figure 8-10. Concatenation of multiple MAC frames is the only method by which the CM can transmit more than one MAC frame in a single transmit opportunity. A compliant CM MUST support concatenation. A compliant CMTS MUST support concatenation. Concatenation only applies to upstream traffic. Concatenation MUST NOT be used on downstream traffic.2

1.

This includes the preamble, guard time, and possibly zero-fill bytes in the last codeword. The FEC overhead recurs for each codeword. Revised this and the subsequent paragraph per ECN RFIv2.0-N-0177-2 by GO on 10/18/04.

2.

124

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

PHY Overhead

MAC Hdr (Concat)

MAC Frame 1 (MAC HDR + optional PDU)

MAC Frame n (MAC HDR + optional PDU)

Figure 8-10 Concatenation of Multiple MAC Frames

Only one Concatenation MAC Header MUST be present per MAC burst. Nested concatenation MUST NOT be allowed. Immediately following the Concatenation MAC Header MUST be the MAC Header of the first MAC frame. Information within the MAC Header indicates the length of the first MAC Frame and provides a means to find the start of the next MAC Frame. Each MAC frame within a concatenation MUST be unique and MAY be of any type. This means that Packet and MAC-specific Frames MAY be mixed together. However, all frames in a concatenation MUST be assigned to the same Service Flow. The CMTS MUST support concatenations containing multiple frame types, including both Packet and MAC-specific frames. The embedded MAC frames MAY be addressed to different destinations and MUST be delivered as if they were transmitted individually. The format of the Concatenation MAC Header MUST be as shown in Figure 8-11 and Table 8-10.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

HCS (2 bytes)

FC TYPE = 11

FC PARM = 11100

EHDR_ON =0

Figure 8-11

Concatenation MAC Header Format

Table 8-10 Concatenated MAC Frame Format

Field Usage Size

FC

FC_TYPE = 11; MAC Specific Header FC_PARM[4:0] = 11100; Concatenation MAC Header EHDR_ON = 0; No EHDR with Concatenation Header

8 bits

MAC_PARM

CNT, number of MAC frames in this concatenation CNT = 0 indicates unspecified number of MAC frames

8 bits

LEN EHDR HCS MAC frame 1 MAC frame n

LEN = x +... + y; length of all following MAC frames in bytes Extended MAC Header MUST NOT be used MAC Header Check Sequence First MAC frame: MAC Header plus OPTIONAL data PDU Last MAC frame: MAC Header plus OPTIONAL data PDU Length of Concatenated MAC frame

16 bits 0 bytes 2 bytes x bytes y bytes 6 + LEN bytes

The MAC_PARM field in the Concatenation MAC header provides a count of MAC frames as opposed to EHDR length or REQ amount as used in other MAC headers. If the field is non-zero, then it MUST indicate the total count of MAC Frames (CNT) in this concatenantion burst.

125

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.2.6 Extended MAC Headers

Every MAC Header, except the Timing, Concatenation MAC Header and Request Frame, has the capability of defining an Extended Header field (EHDR). The presence of an EHDR field MUST be indicated by the EHDR_ON flag in the FC field being set. Whenever this bit is set, then the MAC_PARM field MUST be used as the EHDR length (ELEN). The minimum defined EHDR is 1 byte. The maximum EHDR length is 240 bytes. A compliant CMTS & CM MUST support extended headers. The format of a generic MAC Header with an Extended Header included MUST be as shown in Figure 8-12 and Table 8-11.
Note: Extended Headers MUST NOT be used in a Concatenation MAC Header, but MAY be included as part of the MAC Headers within the concatenation.

Extended Headers MUST NOT be used in Request Frames and Timing MAC Headers.

FC (1 byte)

MAC_PARM (1 byte)

LEN (2 bytes)

EHDR (1-240 bytes)

HCS (2 bytes)

data PDU (optional)

FC TYPE = XX

FC PARM (reserved)

EHDR_ON =1

EH_TYPE (4 bits)

EH_LEN (4 bits)

EH_VALUE (0-15 bytes)

repeat

Figure 8-12 Table 8-11

Field

Extended MAC Format

Example Extended Header Format

Usage Size

FC

FC_TYPE = XX; Applies to all MAC Headers FC_PARM[4:0] = XXXXX; dependent on FC_TYPE EHDR_ON = 1; EHDR present this example

8 bits

MAC_PARM LEN EHDR HCS PDU

ELEN = x; length of EHDR in bytes LEN = x + y; length of EHDR plus OPTIONAL data PDU in bytes Extended MAC Header present this example MAC Header Check Sequence OPTIONAL data PDU Length of MAC frame with EHDR

8 bits 16 bits x bytes 2 bytes y bytes 6 + x + y bytes

Since the EHDR increases the length of the MAC frame, the LEN field MUST be increased to include both the length of the Data PDU and the length of the EHDR. The EHDR field consists of one or more EH elements. Each EH element is variable sized. The first byte of the EH element MUST contain a type and a length field. Every CM MUST use this length to skip over any unknown EH elements. The format of an EH element MUST be as shown in Table 8-12.

126

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-12 EH Element Format

EH Element Fields Usage Size

EH_TYPE EH_LEN EH_VALUE

EH element Type Field Length of EH_VALUE EH element data

4 bits 4 bits 0-15 bytes

The types of EH element defined in Table 8-13 MUST be supported. Reserved and extended types are undefined at this point and MUST be ignored. The first ten EH element types are intended for one-way transfer between the cable modem and the CMTS. The next five EH element types are for end-to-end usage within a MAC-sublayer domain. Thus, the information attached to EHDR elements 10-14 on the upstream MUST also be attached when the information is forwarded within a MAC-sublayer domain. The final EH element type is an escape mechanism that allows for more types and longer values, and MUST be as shown in Table 8-13.
Table 8-13
EH_TYPE EH_LEN

Extended Header Types

EH_VALUE

0 1 2 3 (= BP_UP)

0 3 2 4 5

Null configuration setting; may be used to pad the extended header. The EH_LEN MUST be zero, but the configuration setting may be repeated. Request: mini-slots requested (1 byte); SID (2 bytes) [CM --> CMTS] Acknowledgment requested; SID (2 bytes) [CM --> CMTS] Upstream Privacy EH Element [DOCSIS8] Upstream Privacy with Fragmentation1 EH Element [DOCSIS8] (See Section 8.2.7) Downstream Privacy EH Element [DOCSIS8] Service Flow EH Element; Payload Header Suppression Header Downstream. Service Flow EH Element; Payload Header Suppression Header Upstream Service Flow EH Element; Payload Header Suppression Header Upstream (1 byte), Unsolicited Grant Synchronization Header (1 byte) Reserved Reserved [CM <-> CM]

4 (= BP_DOWN) 5 6

4 1 1 2

7-9 10 - 14 15
1.

XX

Extended EH Element: EHX_TYPE (1 byte), EHX_LEN (1 byte), EH_VALUE (length determined by EHX_LEN)

An Upstream Privacy with Fragmentation EH Element MUST only occur within a Fragmentation MACSpecific Header. (Refer to Section 8.2.5.4)
8.2.6.1 Piggyback Requests

Several Extended Headers can be used to request bandwidth for subsequent transmissions. These requests are generically referred to as piggyback requests. They are extremely valuable for performance because they are not subject to contention as Request Frames generally are. (Refer to Section 9.4) Requests for additional bandwidth can be included in Request, Upstream Privacy and Upstream Privacy with Fragmentation Extended Header elements.

127

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.2.6.2

Fragmentation Extended Header

Fragmented packets use a combination of the Fragmentation MAC header and a modified version of the Upstream Privacy Extended header. Section 8.2.5.4 describes the Fragmentation MAC header. The Upstream Privacy Extended Header with Fragmentation, also known as the Fragmentation Extended Header, MUST be as shown in Table 8-14.
Table 8-14
EH Element Fields

Fragmentation Extended Header Format

Usage Size

EH_TYPE EH_LEN EH_VALUE

Upstream Privacy EH element = 3 Length of EH_VALUE = 5 Key_seq; same as in BP_UP Ver = 1; version number for this EHDR BPI_ENABLE If BPI_ENABLE=0, BPI disabled If BPI_ENABLE=1, BPI enabled Toggle bit; same as in BP_UP1 SID; Service ID associated with this fragment REQ; number of mini-slots for a piggyback request Reserved; must be set to zero First_Frag; set to one for first fragment only Last_Frag; set to one for last fragment only Frag_seq; fragment sequence count, incremented for each fragment.

4 bits 4 bits 4 bits 4 bits 1 bit

1 bit 14 bits 8 bits 2 bits 1 bit 1 bit 4 bits

1.

Refer to [DOCSIS8]

8.2.6.3

Service Flow Extended Header

The Service Flow EH Element is used to enhance Service Flow operations. It may consist of one or two bytes in the EH_VALUE field. The Payload Header Suppression Header is the only byte in a one byte field or the first byte in a two byte field. The Unsolicited Grant Synchronization Header is the second byte in a two byte field.
8.2.6.3.1 Payload Header Suppression Header

In Payload Header Suppression (PHS), a repetitive portion of the payload headers following the HCS is suppressed by the sending entity and restored by the receiving entity. In the upstream, the sending entity is the CM and the receiving entity is the CMTS. In the downstream, the sending entity is the CMTS and the receiving entity is the CM. For small payloads, Payload Header Suppression provides increased bandwidth efficiency without having to use compression. Payload Header Suppression may be separately provisioned in the upstream and downstream, and is referenced with an extended header element.

128

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A compliant CM MUST support Payload Header Suppression.1 A compliant CMTS MUST support Payload Header Suppression.2 The Payload Header Suppression Extended Header sub-element has the following format:
Table 8-15 Payload Header Suppression EHDR Sub-Element Format
EH Element Fields Usage Size

EH_TYPE EH_LEN EH_VALUE

Service Flow EH_TYPE=5 for downstream and EH_TYPE=6 for upstream Length of EH_VALUE = 1 0 1-255 Indicates no payload header suppression on current packet. Payload Header Suppression Index (PHSI)

4 bits 4 bits 8 bits

The Payload Header Suppression Index is unique per SID in the upstream and unique per CM in the downstream. Payload Header Suppression is disabled if this Extended Header element is omitted or, if included, with the PHSI value set to 0. The Payload Header Suppression Index (PHSI) references the suppressed byte string known as a Payload Header Suppression Field (PHSF).
Note: While PHS signaling allows for up to 255 Payload Header Suppression Rules per Service Flow, the exact number of PHS rules supported per Service Flow is implementation dependent. Similarly, PHS signaling allows for PHS Sizes of up to 255 bytes, however, the maximum PHS Size supported is implementation dependent. For interoperability, the minimum PHS Size that MUST be supported is 64 bytes for any PHS rule supported. As with any other parameter requested in a Dynamic Service Request, a PHS-related DSx request can be denied because of a lack of resources.

The Upstream Suppression Field MUST begin with the first byte following the MAC Header Checksum. The Downstream Suppression Field MUST begin with the thirteenth byte following the MAC Header Checksum. This allows the Ethernet SA and DA to be available for filtering by the CM. The operation of Baseline Privacy (refer to [DOCSIS8]) is not affected by the use of PHS. When Fragmentation is inactive, Baseline Privacy begins encryption and decryption with the thirteenth byte following the MAC Header checksum. Unless the entire Packet PDU is suppressed, the Packet PDU CRC is always transmitted, and MUST be calculated only on the bytes transmitted. The bytes that are suppressed MUST NOT be included in the CRC calculation.
8.2.6.3.2 Unsolicited Grant Synchronization Header

The Unsolicited Grant Synchronization Header may be used to pass status information regarding Service Flow scheduling between the CM and CMTS. It is currently only defined for use in the upstream with Unsolicited Grant and Unsolicited Grant with Activity Detection scheduling services. (Refer to Section 10.2.3, Unsolicited Grant Service with Activity Detection, on page 221.) This extended header is similar to the Payload Suppression EHDR except that the EH_LEN is 2, and the EH_VALUE has one additional byte which includes information related to Unsolicited Grant Synchronization.

1.

This is not intended to imply that the CM must be capable of determining when to invoke Payload Header Suppression. Payload Header Suppression support is only required for the explicitly signalled case. Revised this paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/18/04.

2.

129

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

For all other Service Flow Scheduling Types, the field SHOULD NOT be included in the Extended Header Element generated by the CM. The CMTS MAY ignore this field.
Table 8-16
EH Element Fields

Unsolicited Grant Synchronization EHDR Sub-Element Format

Usage Size

EH_TYPE EH_LEN EH_VALUE

Service Flow EH_TYPE = 6 Length of EH_VALUE = 2 0 1-255 Indicates no payload header suppression on current packet. Payload Header Suppression Index (PHSI)

4 bits 4 bits 8 bits [always present]

Queue Indicator Active Grants

1 bit 7 bits

8.2.7 Fragmented MAC Frames

When enabled, fragmentation is initiated any time the grant length is less than the requested length. This normally occurs because the CMTS chooses to grant less than the requested bandwidth.

130

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Fragment Payload Single Packet MAC Frame HDR MAC HDR EHDR HCS PDU CRC

FC

PARM

LEN

PRV other

Concat of Multiple MAC Frames Concat HDR MAC HDR1 PDU 1

Fragment Payload

CRC 1

MAC HDR2

MAC HDRn

PDU n

CRC n

12 Bytes Fragment #1 FRAG HDR FHCS Frag Payload (first)

Encrypted Portion for Baseline Privacy

4 Bytes FCRC
FHCS- Fragment HCS FCRC- Fragment CRC

Fragment #2

FRAG HDR

FHCS

Frag Payload (mid)

FCRC

Encrypted Portion for Baseline Privacy

Fragment #3

FRAG HDR

FHCS

Frag Payload (last)

FCRC

Encrypted Portion for Baseline Privacy

1B Fragmentation Header FC

1B
EHDR LEN = 6

2B LEN

6B EHDR
XXFLSSSS
F - Set on First fragment, clear otherwise L - Set on Last fragment, clear otherwise SSSS - 4 bit sequence number, increments on each fragment of a packet, rolling over as necessary. XX - Reserved, set to 00

11

00011

1B Length of Frag 35

1B Ver

2B SID

1B RQ

1B RSV

YYYY0001

ETXXXXXXXXXXXXXX

YYYY - Key Sequence number, default = 0000

E - Enable BPI: 1 = enable, 0 = disable T = Toggle: 1 = odd, 0 = Even, default = 0 XXXXXXXXXXXXXX = 14 bit SID

Figure 8-13

Fragmentation Details

The CM MAC calculates how many bytes of the original frame, including overhead for a fragmentation header and CRC, can be sent in the received grant. The CM MAC generates a fragmentation header for each fragment. Fragmented frames use the MAC Message type (FC = 11). The FC parameter field is set to (00011), in order to uniquely identify the fragmentation header from other MAC Message types. A four bit sequence field is used in the last byte of the Extended Header field to aid in reassembly and to detect dropped or missing fragments. The CM arbitrarily selects a sequence number for the first fragment of a frame.1 Once the sequence number is selected for the first fragment, the CM MUST increment the sequence number by one for each fragment transmitted for that frame. There are two flags associated with the sequence number, F and L, where F is set to indicate the first fragment and L is set to indicate the last fragment. Both are cleared for middle fragments. The CMTS stores the sequence number of the first fragment (F bit set) of each frame. The CMTS MUST verify that the fragment sequence field increments (by one) for each fragment of the frame.

1.

Frame always refers to either frames with a single Packet PDU or concatenated frame.

131

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The REQ field in the fragmentation header is used by the fragmentation protocol for First and Middle fragments (refer to Section 10.3). For the Last fragment, the REQ field is interpreted as a request for bandwidth for a subsequent frame. Fragmentation headers are fixed size and MUST contain only a Fragmentation extended header element. The extended header consists of a Privacy EH element extended by one byte to make the fragment overhead an even 16 bytes. A Privacy EH element is used whether the original packet header contained a Privacy EH element or not. If privacy is in use, the following fields, Version, Enable bit, and SID, in the fragment EH element are the same with those of BP EH element inside the original MAC frame. If privacy is not in use, the Privacy EH element is used but the enable bit is cleared. The SID used in the fragment EH element MUST match the SID used in the Partial Grant that initiated the fragmentation. A separate CRC MUST be calculated for each fragment (note that each MAC frame payload will also contain the CRC for that packet). A packet CRC of a reassembled packet MAY be checked by the CMTS even though an FCRC covers each fragment. The CMTS MUST make certain that any fragmentary grant it makes is large enough to hold at least 17 bytes of MAC layer data. This is to ensure that the grant is large enough to accommodate fragmentation overhead plus at least 1 byte of actual data. The CMTS may want to enforce an even higher limit as small fragments are extremely inefficient. When Fragmentation is active, Baseline Privacy encryption and decryption begin with the first byte following the MAC Header checksum.
8.2.7.1 Considerations for Concatenated Packets and Fragmentation

MAC Management Messages and Data PDUs can occur in the same concatenated frame. Without fragmentation, the MAC Management Messages within a concatenated frame would be unencrypted. However, with fragmentation enabled on the concatenated frame, the entire concatenated frame is encrypted based on the Privacy Extended Header Element. This allows Baseline Privacy to encrypt each fragment without examining its contents. Clearly, this only applies when Baseline Privacy is enabled. To ensure encryption synchronization, if fragmentation, concatenation and Baseline Privacy are all enabled, a CM MUST NOT concatenate BPKM MAC Management messages. This ensures that BPKM MAC Management messages are always sent unencrypted.
8.2.8 Error-Handling

The cable network is a potentially harsh environment that can cause several different error conditions to occur. This section, together with Section 11.5, describes the procedures that are required when an exception occurs at the MAC framing level. The most obvious type of error occurs when the HCS on the MAC Header fails. This can be a result of noise on the network or possibly by collisions in the upstream channel. Framing recovery on the downstream channel is performed by the MPEG transmission convergence sublayer. In the upstream channel, framing is recovered on each transmitted burst, such that framing on one burst is independent of framing on prior bursts. Hence, framing errors within a burst are handled by simply ignoring that burst; i.e., errors are unrecoverable until the next burst. A second exception, which applies only to the upstream, occurs when the Length field is corrupted and the MAC thinks the frame is longer or shorter than it actually is. Synchronization will recover at the next valid upstream data interval. For every MAC transmission, The HCS MUST be verified. When a bad HCS is detected, the MAC Header and any payload MUST be dropped.

132

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

For Packet PDU transmissions, a bad CRC may be detected. Since the CRC only covers the Data PDU and the HCS covers the MAC Header; the MAC Header is still considered valid. Thus, the Packet PDU MUST be dropped, but any pertinent information in the MAC Header (e.g., bandwidth request information) MAY be used.
8.2.8.1 Error Recovery During Fragmentation

There are some special error handling considerations for fragmentation. Each fragment has its own fragmentation header complete with an HCS and its own FCRC. There may be other MAC headers and CRCs within the fragmented payload. However, only the HCS of the fragment header and the FCRC are used for error detection during fragment reassembly. If the HCS for a fragment fails the CMTS MUST discard that fragment. If the HCS passes but the FCRC fails, the CMTS MUST discard that fragment, but MAY process any requests in the fragment header. The CMTS SHOULD process such a request if it is performing fragmentation in Piggyback Mode. (Refer to Section 10.3.2.2) This allows the remainder of the frame to be transmitted as quickly as possible. If a CMTS is performing fragmentation in Multiple Grant Mode (refer to Section 10.3.2.1) it SHOULD complete all the grants necessary to fulfil the CMs original request even if a fragment is lost or discarded. This allows the remainder of the frame to be transmitted as quickly as possible. If any fragment of a non-concatenated MAC frame is lost or discarded the CMTS MUST discard the rest of that frame. If a fragment of a concatenated MAC frame is lost or discarded the CMTS MAY forward any frames within the concatenation that have been received correctly or it MAY discard all the frames in the concatenation. A CMTS MUST terminate fragment reassembly if any of the following occurs for any fragment on a given SID:

The CMTS receives a fragment with the L bit set. The CMTS receives an upstream fragment, other than the first one, with the F bit set. The CMTS receives a packet PDU frame with no fragmentation header. The CMTS deletes the SID for any reason.

In addition, the CMTS MAY terminate fragment reassembly based on implementation dependent criteria such as a reassembly timer. When a CMTS terminates fragment reassembly it MUST dispose of (either by discarding or forwarding) the reassembled frame(s).
8.2.8.2 Error Codes and Messages

SP-OSSIv2.0 [DOCSIS5] Annex D lists CM and CMTS error codes and messages. When reporting error conditions, these codes MUST be used as indicated in [DOCSIS5] and MAY be used for reporting errors via vendor-specific interfaces. If the error codes are used, the error messages MAY be replaced by other descriptive messages.

8.3

MAC Management Messages

8.3.1 MAC Management Message Header

MAC Management Messages MUST be encapsulated in an LLC unnumbered information frame per [ISO88022], which in turn is encapsulated within the cable network MAC framing, as shown in Figure 8-14. Figure 8-14 shows the MAC Header and the MAC Management Message Header fields which are common across all MAC

133

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Management Messages.

Bit

0 FC

8 MAC PARM HCS

16

24 LEN

31

MAC header

DA DA SA msg LEN control version DSAP type SSAP RSVD SA MAC Management Message Header

Management message payload

CRC

Figure 8-14

MAC Header and MAC Management Message Header Fields

The fields MUST be as defined below:

FC, MAC PARM, LEN, HCS use a MAC-specific header.

Common MAC frame header -refer to Section 8.2.1.4 for details. All messages

Destination Address (DA) MAC management frames will be addressed to a specific CM unicast address or to the DOCSIS management multicast address. These DOCSIS MAC management addresses are described in Annex A. Source Address (SA) Msg Length DSAP SSAP

The MAC address of the source CM or CMTS system.

Length of the MAC message from DSAP to the end of the payload.

The LLC null destination SAP (00) as defined by [ISO8802-2]. The LLC null source SAP (00) as defined by [ISO8802-2].

Control Unnumbered information frame (03) as defined by [ISO8802-2]. Version & Type Each 1 octet. Refer to Table 8-17. Messages with a version number of 1 are understood by all CMs and CMTSes compliant with all versions of the DOCSIS specification. Messages with a version number of 2 are understood by DOCSIS 1.1 and 2.0 equipment, and messages with a version number of 3 are understood by DOCSIS 2.0 equipment. DOCSIS 2.0 compliant CMs and CMTSes MUST silently discard any message with a version number greater than 3.
134

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-17
Type Value Version

MAC Management Message Types1

Message Description

Message Name

1 2 or 29

1 1 or 3

SYNC UCD

Timing Synchronization Upstream Channel Descriptor A UCD for a DOCSIS 2.0 Only Channel uses a type of 29 and a version of 3. All other UCDs use a type of 2 and a version of 1. (see Section 8.3.3)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33255

1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

MAP RNG-REQ RNG-RSP REG-REQ REG-RSP UCC-REQ UCC-RSP TRI-TCD TRI-TSI BPKM-REQ BPKM-RSP REG-ACK DSA-REQ DSA-RSP DSA-ACK DSC-REQ DSC-RSP DSC-ACK DSD-REQ DSD-RSP DCC-REQ DCC-RSP DCC-ACK DCI-REQ DCI-RSP UP-DIS

Upstream Bandwidth Allocation Ranging Request Ranging Response Registration Request Registration Response Upstream Channel Change Request Upstream Channel Change Response Telephony Channel Descriptor [DOCSIS6] Termination System Information [DOCSIS6] Privacy Key Management Request [DOCSIS8] Privacy Key Management Response [[DOCSIS8] Registration Acknowledge Dynamic Service Addition Request Dynamic Service Addition Response Dynamic Service Addition Acknowledge Dynamic Service Change Request Dynamic Service Change Response Dynamic Service Change Acknowledge Dynamic Service Deletion Request Dynamic Service Deletion Response Dynamic Channel Change Request Dynamic Channel Change Response Dynamic Channel Change Acknowledge Device Class Identification Request Device Class Identification Response Upstream Transmitter Disable (See entry for UCD)

INIT-RNG-REQ TST-REQ DCD

Initial Ranging Request Test Request Message Downstream Channel Descriptor [DSG] Reserved for future use

RSVD 1 octet. This field is used to align the message payload on a 32-bit boundary. Set to 0 for this version for all messages other than the RNG-REQ and INIT-RNG-REQ. See section 8.3.5 and 8.3.26 for setting this value for these two messages.2

1.

Table 8-17, last two rows updated per RFI2-N-02102 and RFIv2.0-N-04.0128-1 by RKV and GO on 10/28/02 and 3/15/04.

135

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Management Message Payload CRC

Variable length. As defined for each specific management message.

Covers message including header fields (DA, SA,...). Polynomial defined by [ISO8802-3].

A compliant CMTS or CM MUST support the MAC management message types listed in Table 8-17, except messages specific to Telephony Return devices which MAY be supported.
8.3.2 Time Synchronization (SYNC)

Time Synchronization (SYNC) MUST be transmitted by CMTS at a periodic interval to establish MAC sublayer timing. This message MUST use an FC field with FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header. This MUST be followed by a Packet PDU in the format shown in Figure 8-15.

Bit

16

24

31

~ ~

MAC Management Message Header

~ ~

CMTS Timestamp

Figure 8-15 Format of Packet PDU Following the Timing Header

The parameters shall be as defined below:

CMTS Timestamp MHz master clock.

The count state of an incrementing 32 bit binary counter clocked with the CMTS 10.24

The CMTS timestamp represents the count state at the instant that the first byte (or a fixed time offset from the first byte) of the Time Synchronization MAC Management Message is transferred from the Downstream Transmission Convergence Sublayer to the Downstream Physical Media Dependent Sublayer as described in Section 6.3.7. The CMTS MUST NOT allow a SYNC message to cross an MPEG packet boundary.1
8.3.3 Upstream Channel Descriptor (UCD)

An Upstream Channel Descriptor MUST be transmitted by the CMTS at a periodic interval to define the characteristics of an logical upstream channel (Figure 8-16). A separate message MUST be transmitted for each logical upstream that is currently available for use. The MAC management header for this message has 2 possible values for the type field and for the version field. For DOCSIS 2.0 Only Upstreams the CMTS MUST use a value of 29 for the type field and MUST use a value of

2. 1.

Revised this statement per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04. Since the SYNC message applies to all upstream channels within this MAC domain, units were chosen to be independent of the modulation rate of any particular upstream channel. See Section 9.3.4 for time-unit relationships.

136

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

3 for the version field. For all other logical upstreams the CMTS MUST use a value of 2 for the type field and a value of 1 for the version field. A CMTS MUST NOT use type 5 TLVs to encode IUCs 1-6 in a UCD with a message type of 2. A CMTS MUST use type 5 TLVs to encode all burst profiles in a UCD with a message type of 29. A type 2 UCD MUST contain type 4 burst descriptors for IUCs 3 and 4, a type 4 burst descriptor for requests and a type 4 burst descriptor for data. The burst descriptors for requests and data MUST use 1.x TDMA. To describe a 1.x/2.0 mixed logical channel the UCD MUST additionally contain a type 5 burst descriptor for 2.0 TDMA data opportunities. A type 29 UCD MUST contain a type 5 burst descriptor for IUC 3, a type 5 burst descriptor for requests, and a type 5 burst descriptor for data. A CMTS MUST NOT include burst descriptors for IUCs 5 or 6 in a UCD message for a DOCSIS 2.0 Only Upstream. For interoperability a CMTS SHOULD provide: - burst descriptors for IUCs 1, 5 and 6 in a type 2 UCD describing a 1.x only channel. - burst descriptors for IUCs 1, 5, 6, 9 and 10 in a type 2 UCD describing a 1.x/2.0 mixed logical channel. - burst descriptors for IUCs 1, 9 and 10 in a type 29 UCD.1 The CMTS MUST treat an upstream as a DOCSIS 2.0 Only Upstream if any of the following is true about the channel wide parameters: S-CDMA mode is enabled, the Mini-slot size is 1 time tick, or the value of the Modulation Rate parameter is 32. The CMTS MUST treat an upstream as a DOCSIS 2.0 Only Upstream if any of the following is true about any of IUCs 1-4: A modulation type other than QPSK or 16QAM is used, the FEC Error Correction (T) parameter is greater than 10, any portion of the extended preamble is used, any attribute from Table 8-19, Upstream Physical-Layer Burst Attributes, on page 141 with a type greater than 11 is present in the descriptor. Note that none of these conditions can ever be true for IUCs 5 or 6. To provide for flexibility the message parameters following the channel ID MUST be encoded in a type/length/ value (TLV) form in which the type and length fields are each 1 octet long.
Bit 0 8 16 24 31

~ ~
Upstream channel ID

MAC Management Message Header

Configuration Change Count

Mini-Slot Size

Downstream channel ID

TLV-encoded information for the overall channel TLV-encoded Burst Description TLV-encoded information for the subsequent burst descriptors

Figure 8-16

Upstream Channel Descriptor

1.

Section 8.3.3 text from The MAC management header to this footnote updated per RFI2-N-02089 by RKV on 10/28/02.

137

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

A CMTS MUST generate UCDs in the format shown in Figure 8-16, including all of the following parameters:
Configuration Change Count Incremented by one (modulo the field size) by the CMTS whenever any of the values of this channel descriptor change, excluding the S-CDMA snapshot TLV1. If the value of this count in a subsequent UCD remains the same, the CM can quickly decide that the channel operating parameters have not changed, and may be able to disregard the remainder of the message. This value is also referenced from the MAP. Mini-Slot Size The size T of the Mini-Slot for this upstream channel in units of the Timebase Tick of 6.25 s. For channels that can support DOCSIS 1.x CMs the allowable values are T = 2M, M = 1,...7. That is, T = 2, 4, 8, 16, 32, 64 or 128.

For DOCSIS 2.0 Only Channels the relationship between M and T remains the same, but the allowable values are M = 0,1,7, with T = 1, 2, 4, 8, 16, 32, 64, or 128. If the value of T is 1 then the channel MUST be treated as a DOCSIS 2.0 Only Channel. On S-CDMA channels, this parameter will not have any effect.
Upstream Channel ID The identifier of the upstream channel to which this message refers. This identifier is arbitrarily chosen by the CMTS and is only unique within the MAC-Sublayer domain. Note: Upstream Channel ID = 0 is reserved to indicate telephony return [DOCSIS6]. Downstream Channel ID The identifier of the downstream channel on which this message has been transmitted. This identifier is arbitrarily chosen by the CMTS and is only unique within the MAC-Sublayer domain.

All other parameters are coded as TLV tuples. The type values used MUST be those defined in Table 8-18 2, for channel parameters, and Table 8-19, for upstream physical layer burst attributes. Burst descriptors (type 4 and/or type 5) MUST appear in the UCD message after all other channel-wide parameters.

Table 8-18 Channel TLV Parameters

Name Type (1 byte) Length (1 byte) Value (Variable length)

Modulation Rate

Multiples of base rate of 160 kHz. (Value is 1, 2, 4, 8, 16, or 32.) A value of 32 means that this is a DOCSIS 2.0 Only Upstream. If S-CDMA mode is enabled then this parameter MUST have a value of 8, 16 or 32. Upstream center frequency (Hz)

Frequency

1.

Refer to Section 6.2.11.2 for a description of the Timestamp Snapshot. The periodic update of the snapshot association does not represent a change in the operating parameters of the channel, hence the UCD configuration change count will not be incremented. Revised this table per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.

2.

138

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-18
Preamble Pattern 3

Channel TLV Parameters (Continued)

1-128 The Value field defines the first portion of the Preamble Superstring. If there is no Extended Preamble Pattern parameter, then this parameter defines the entire Preamble Superstring. All burst-specific preamble values are chosen as bit-substrings of the Preamble Superstring. The first byte of the Value field contains the first 8 bits of the superstring, with the first bit of the preamble superstring in the MSB position of the first Value field byte, the eighth bit of the preamble superstring in the LSB position of the first Value field byte; the second byte in the Value field contains the second eight bits of the superstring, with the ninth bit of the superstring in the MSB of the second byte and sixteenth bit of the preamble superstring in the LSB of the second byte, and so forth.

Burst Descriptor (DOCSIS 1.x) Burst Descriptor (DOCSIS 2.0) Extended Preamble Pattern

4 5 6

n n 1-64

May appear more than once; described below. May appear more than once; described below. 512 Bit Preamble Superstring extension. The value field is concatenated to the end of the value field of the Preamble Pattern to complete the Preamble Superstring. This Parameter MUST NOT be included unless the length of the Preamble Pattern parameter is 128 bytes. Therefore the MSB of the first byte of the value field of this parameter always follows the LSB of the 128th byte of the value field of the Preamble Pattern parameter in the Preamble Superstring.

S-CDMA Mode Enable1

1 = on; 2 = off, If parameter is on, the upstream will operate in S-CDMA mode. Otherwise it operates in TDMA mode. If this parameter is set to on, this is a DOCSIS 2.0 Only Upstream. Number of consecutive spreading intervals mapped onto a two-dimensional frame. (Value is 1 through 32). This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

S-CDMA Spreading Intervals per frame

S-CDMA Codes per Mini-slot

Number of consecutive codes mapped into a twodimensional mini-slot. (Value is 2 through 32). This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

S-CDMA Number of Active Codes

10

Number of codes available to carry data payload. (Value is 64 through 128). This value MUST be a multiple of Codes per Mini-slot (TLV type 9). This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

S-CDMA Code Hopping Seed

11

15-bit seed to initialize code hopping sequence. The value is left-justified in the 2-byte field. Set seed = 0 to disable code hopping. This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

S-CDMA US ratio numerator M

12

The numerator (M) of the M/N ratio relating the downstream symbol clock to the upstream modulation clock. This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

S-CDMA US ratio denominator N

13

The denominator (N) of the M/N ratio relating the downstream symbol clock to the upstream modulation clock. This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

139

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table 8-18
S-CDMA Timestamp Snapshot2 14

Channel TLV Parameters (Continued)

9 Snapshot of the timestamp, mini-slot, and S-CDMA frame taken at an S-CDMA frame boundary at the CMTS. A new value MUST be sampled and sent with each UCD message. Refer to Section 6.2.11.2, Mini-slot Numbering, on page 54. This TLV MUST be present if S-CDMA Mode is enabled, and MUST NOT be present if it is not.

Maintain Power Spectral Density

15

1=on;2=off. If this value is on and the modulation rate is different from the previous UCD, the CM MUST change its transmit power level to keep the power spectral density as close as possible to what it was prior to the modulation rate change. If this value is off or this parameter is omitted then the CM maintains the same power level that it was using prior to the modulation rate change. In any case the effect of this parameter only lasts until the CM receives a power adjustment in a RNG-RSP.

Ranging Required

16

0= no ranging required 1= unicast initial ranging required 2= broadcast initial ranging required If this value is non-zero and the UCD change count does not match the UCD currently in effect, the CM MUST perform ranging as specified by this TLV before using any other transmit opportunities with the new UCD parameters. If ranging is required, and the CM is already registered, then it MUST maintain its SIDs and not re-register. If this value is 0 or this TLV is omitted, no ranging is required.

S-CDMA Maximum Scheduled Codes enabled

17

1=Maximum Scheduled Codes is enabled. 2=Maximum Scheduled Codes is disabled. CMs that implement the S-CDMA Maximum Scheduled Codes MUST set the RSVD field in the Ranging Requests as described in Section 8.3.5 and Section 8.3.26. If S-CDMA mode is disabled on this channel, this TLV MUST NOT be present.

1. 2.

CM MUST assume S-CDMA mode is off if TLV is not present. Refer to Section 6.2.11.2, Mini-slot Numbering, on page 54 for a description of the Timestamp Snapshot. A change solely in this parameter for a particular UCD does not represent a change in overall channel operating parameters, hence the UCD channel change count will not be incremented.

Burst Descriptors are composed of an upstream Interval Usage Code, followed by TLV encodings that define, for each type of upstream usage interval, the physical-layer characteristics that are to be used during that interval. The upstream interval usage codes are defined in the MAP message (see Section 8.3.4 and Table 8-20). The format of the Burst Descriptors is shown in Figure 8-17, Top-Level Encoding for Burst Descriptors, on page 140.

0 Type = 4 or 5 burst descriptor

8 Length (n)

16 Interval Usage Code

24

31

TLV codes for PHY parameters (n-1)

Figure 8-17

Top-Level Encoding for Burst Descriptors

140

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

In Figure 8-17:
Type 4For Burst Descriptors intended for DOCSIS 1.x and/or DOCSIS 2.0 modems. 5 is for Burst Descriptors intended for DOCSIS 2.0 modems only. Length

The number of bytes in the overall object, including the IUC and the embedded TLV items.

IUC Interval Usage code defined in Table 8-20. The IUC is coded on the 4 least-significant bits. The 4 mostsignificant bits are unused (=0). TLV items

TLV parameters described in Table 8-18, Channel TLV Parameters, on page 138.

Two different type values are used to describe Burst Descriptors. Type 4 Burst Descriptors MUST be understood by all modems and MUST only be used to describe IUCs 1 through 6 from Table 8-20. Type 5 Burst Descriptors MUST be understood by DOCSIS 2.0 modems. A type 5 burst descriptor MUST be used to describe any IUC if any of the following is true: a modulation type other than QPSK or 16QAM is used, the FEC Error Correction (T) attribute is greater than 10, any portion of the Extended Preamble is used, or any attribute from Table 8-19, Upstream Physical-Layer Burst Attributes, on page 141 with a type greater than 11 is present in the descriptor. Type 5 burst descriptors MUST NOT be used to describe IUC 5 or IUC 6. Type 5 burst descriptors MUST be used to describe IUCs 9-11. A Burst Descriptor MUST be included for each Interval Usage Code that is to be used in the allocation MAP. The Interval Usage Code MUST be one of the values from Table 8-20. Within each Burst Descriptor is an unordered list of Physical-layer attributes, encoded as TLV values. These attributes are shown in Table 8-19. The CMTS MUST ensure that the set of burst attributes for all the burst descriptors in the UCD allow any CM on the upstream to be able to request enough mini-slots to be able to transmit a maximum size PDU (see Section 8.2.2, Packet-Based MAC Frames, on page 118).1

Table 8-19
Name

Upstream Physical-Layer Burst Attributes

Length (1 byte) Value (Variable Length)

Type (1 byte)

Modulation Type

1 = QPSK 2 = 16QAM 3 = 8QAM 4 = 32QAM 5 = 64QAM 6 = 128QAM (S-CDMA only) Values greater than 2 MUST NOT be used in a descriptor encoded in a type 4 TLV.

Differential Encoding

1 = on, 2 = off. (see Section 6.2.13, Symbol Mapping, on page 64).

1.

Revised Table 8-19, Name S-CDMA Framer Interleaving Step Size (32 to 31) per ECN RFI2-N-03077 by GO on 07/03/03.

141

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table 8-19 Upstream Physical-Layer Burst Attributes (Continued)

Preamble Length 3 2 Up to 1536 bits for burst descriptors encoded in a type 5 TLV. Up to 1024 bits for descriptors encoded in a type 4 TLV. If this descriptor is encoded in a type 4 TLV then the substring of the Preamble Superstring defined by this parameter and the Preamble Value Offset MUST NOT include any bits from the Extended Preamble Pattern. The value must be an integral number of symbols (see Section 6.2.9, Preamble Prepend, on page 53) Preamble Value Offset 4 2 Identifies the bits to be used in the preamble. This is specified as a starting offset into the Preamble Super string (see Table 8-18). That is, a value of zero means that the first bit of the preamble for this burst type is the value of the first bit of the Preamble Superstring. A value of 100 means that the preamble is to use the 101st and succeeding bits from the Preamble Superstring. This value must be a multiple of the symbol size. The first bit of the preamble is the first bit into the symbol mapper (see Figure 6-2, TDMA Upstream Transmission Processing, on page 42, and Figure 6-3, S-CDMA Upstream Transmission Processing, on page 43), and is I1 in the first symbol of the burst (see Section 6.2.13, Symbol Mapping, on page 64). FEC Error Correction (T) 5 1 0-16 for descriptors encoded in a type 5 TLV. 0-10 for descriptors encoded in a type 4 TLV. (0 implies no FEC. The number of codeword parity bytes is 2*T) FEC Codeword Information Bytes (k) Scrambler Seed 6 1 Fixed: 16 to 253 (assuming FEC on) Shortened: 16 to 253 (assuming FEC on) (Not used if no FEC, T=0) The 15-bit seed value left justified in the 2 byte field. Bit 15 is the MSB of the first byte and the LSB of the second byte is not used. (Not used if scrambler is off) The maximum number of mini-slots that can be transmitted during this burst type. Absence of this configuration setting implies that the burst size is limited elsewhere. When the interval type is Short Data Grant (IUC 5) or Advanced PHY Short Data Grant (IUC 9), this value MUST be present and greater than zero. (See Section 9.1.2.5) If the CMTS needs to limit the maximum length of concatenated frames it SHOULD use this configuration setting to do so.1 For TDMA channels, the number of modulation intervals measured from the end of the last symbol of one burst to the beginning of the first symbol of the preamble of an immediately following burst. In Type 4 burst descriptors, the CMTS MUST choose the parameters such that the number of bytes that fit into any valid number of minislots will not change if the guard time is increased by 1. For S-CDMA channels, there is no guard time, and hence the CM MUST ignore this value. This TLV MUST NOT be present for S-CDMA channels.2 1 = fixed; 2 = shortened 1 = on; 2 = off

Maximum Burst Size

Guard Time Size

Last Codeword Length Scrambler on/off

10 11

1 1

142

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-19 Upstream Physical-Layer Burst Attributes (Continued)

R-S Interleaver Depth (Ir) 12 1 Reed-Solomon block interleaving depth. A depth of 0 indicates Dynamic Mode; a depth of 1 indicates RS Interleaving Disabled (see Section 6.2.6, TDMA Byte Interleaver, on page 47) (0 through 2048 ( K + 2T ) ). This TLV MUST be present for burst descriptors encoded in type 5 TLVs on DOCSIS 2.0 TDMA channels. This TLV MUST NOT be present for SCDMA channels or in descriptors encoded in a type 4 TLV. R-S Interleaver Block Size (Br) 13 2 Reed-Solomon block interleaving size in Dynamic Mode. (2*Nr through 2048 where Nr=k+2T). This TLV MUST be present in burst descriptors encoded in type 5 TLVs for DOCSIS 2.0 TDMA channels. This TLV MUST NOT be present on S-CDMA channels or in descriptors encoded in a type 4 TLV. 1 = QPSK0 2 = QPSK1 (Reference Figure 6-18, Symbol Constellations, on page 67, and Section 6.2.9, Preamble Prepend, on page 53) This TLV MUST NOT be present in descriptors encoded in a type 4 TLV. S-CDMA Spreader on/off 15 1 1 = on; 2 = off. This TLV MUST be present for S-CDMA channels. This TLV MUST NOT be present for non-SCDMA channels or in descriptors encoded in a type 4 TLV. Number of codes per sub-frame used in the S-CDMA framer. (1 through 128). This TLV MUST be present for S-CDMA channels. This TLV MUST NOT be present for non-S-CDMA channels or in descriptors encoded in a type 4 TLV. Size of interleaving steps used in S-CDMA framer. (1 through 31). This TLV MUST be present for S-CDMA channels. This TLV MUST NOT be present for non-SCDMA channels or in descriptors encoded in a type 4 TLV. 1 = on; 2 = off. This TLV MUST be present for S-CDMA channels. This TLV MUST NOT be present for non-SCDMA channels or in descriptors encoded in a type 4 TLV.

Preamble Type

14

S-CDMA Codes per Subframe

16

S-CDMA Framer Interleaving Step Size

17

TCM Encoding

18

1. 2.

Maximum Burst Size row, Value cell, last sentence added per RFI2-N-02090 by RKV on 10/28/02. Guard Time Size row, Value cell, entire text updated per RFI2-N-02085 superseded per RFI2-N-02173 by RKV on 10/30/02.

143

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.3.1

Example of UCD Encoded TLV Data

An example of UCD encoded TLV data is given in Figure 8-18.

Type 1 Type 2 Type 3 Type 6 Type 4 Type 4 Type 5 Type 5 Length 1 Length 4 Length 1-128 Length 1-64 Length N Length N Length N Length N Modulation Rate

Frequency Preamble Pattern Extended Preamble Pattern First Burst Descriptor Second Burst Descriptor Third Burst Descriptor Fourth Burst Descriptor

Figure 8-18 Example of UCD Encoded TLV Data

144

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.4 Upstream Bandwidth Allocation Map (MAP)

A CMTS MUST generate MAPs in the format shown in Figure 8-19.

Bit

16 MAC Management Message Header

24

31

Upstream Channel ID

UCD Count

Number of elements

Reserved

Alloc Start Time

Ack Time Ranging Backoff Start Data Backoff Start

Ranging Backoff End

Data Backoff End

MAP Information Elements

Figure 8-19

MAP Format

The parameters MUST be as follows:

Upstream Channel ID The identifier of the upstream channel to which this message refers. UCD Count Matches the value of the Configuration Change Count of the UCD which describes the burst parameters which apply to this map. See Section 11.3.2. Number Elements Reserved

Number of information elements in the map.

Reserved field for alignment. Effective start time from CMTS initialization (in mini-slots) for assignments within this

Alloc Start Time map.

Ack Time Latest time, from CMTS initialization, (mini-slots) processed in upstream. This time is used by the CMs for collision detection purposes. See Section 9.4. Ranging Backoff Start Initial back-off window for initial ranging contention, expressed as a power of two. Values range 0-15 (the highest order bits must be unused and set to 0). Ranging Backoff End Final back-off window for initial ranging contention, expressed as a power of two. Values range 0-15 (the highest order bits must be unused and set to 0).

145

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Data Backoff Start Initial back-off window for contention data and requests, expressed as a power of two. Values range 0-15 (the highest order bits must be unused and set to 0). Data Backoff End Final back-off window for contention data and requests, expressed as a power of two. Values range 0-15 (the highest order bits must be unused and set to 0). MAP Information Elements MUST be in the format defined in Figure 8-20 and Table 8-20. Values for IUCs are defined in Table 8-20 and are described in detail in Section 9.1.2.
Note:

Refer to Section 9.1.1 for the relationship between Alloc Start/Ack Time and the timebase.

Bit first interval

0 SID

13 14 IUC

17 18 offset = 0

31

second interval

SID

IUC

offset

last interval

SID

IUC

offset offset = map length offset = map length

end-of-list (Null IE)

SID=0

IUC=7

SID Acknowledgements and Data Grants Pending SID

IUC

IUC

offset =map length

Figure 8-20 MAP Information Element Structure

146

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-20 Allocation MAP Information Elements (IE)

Interval Usage Code (IUC) (4 bits)

IE Name1

SID (14 bits)

Mini-slot Offset (14 bits)

Request REQ/Data (refer to Annex A, for multicast definition) Initial Maintenance2 Station Maintenance Short Data Grant4 Long Data Grant

1 2

any multicast

Starting offset of REQ region Starting offset of IMMEDIATE Data region (well-known multicasts define start intervals) Starting offset of MAINT region (used in Initial or Periodic Ranging) Starting offset of MAINT region (used in Periodic Ranging) Starting offset of Data Grant assignment; If inferred length = 0, then it is a Data Grant pending.

3 4 5

broadcast or unicast unicast3 unicast

unicast

Starting offset of Data Grant assignment; If inferred length = 0, then it is a Data Grant Pending

Null IE Data Ack Advanced PHY Short Data Grant Advanced PHY Long Data Grant Advanced PHY Unsolicited Grant Reserved Expansion
1. 5

7 8 9

zero unicast unicast

Ending offset of the previous grant. Used to bound the length of the last actual interval allocation. CMTS sets to map length Starting offset of Data Grant assignment; If inferred length = 0, then it is a Data Grant pending.

10

unicast

Starting offset of Data Grant assignment; If inferred length = 0, then it is a Data Grant pending.

11 12-14 15

unicast any expanded IUC

Starting offset of Data Grant assignment Reserved # of additional 32-bit words in this IE

Each IE is a 32-bit quantity, of which the most significant 14 bits represent the SID, the middle 4 bits the IUC, and the loworder 14 bits the mini-slot offset. The CMTS MUST NOT use a unicast SID with an initial maintenance IUC on any upstream that is not a DOCSIS 2.0 Only Upstream. The SID used in the Station Maintenance IE MUST be a Temporary SID, or the Primary SID that was assigned in the REG-RSP message to a CM. The distinction between long and short data grants is related to the amount of data that can be transmitted in the grant. A short data grant interval may use FEC parameters that are appropriate to short packets while a long data grant may be able to take advantage of greater FEC coding efficiency. The Advanced PHY types are provided for channels carrying a combination of DOCSIS 1.x and DOCSIS 2.0 bursts and also for channels carrying DOCSIS 2.0 bursts only.

2.

3.

4.

5.

8.3.5 Ranging Request (RNG-REQ)

A Ranging Request MUST be transmitted by a CM at initialization on an upstream other than a DOCSIS 2.0 Only Upstream, and periodically on request from CMTS to determine network delay and request power adjustment. On a DOCSIS 2.0 Only Upstream the CM transmits a INIT-RNG-REQ (see Section 8.3.26) message at initialization instead, but uses the RNG-REQ for all unicast maintenance opportunities provided by the CMTS. This message MUST use an FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header. This MUST be followed by a Packet PDU in the format shown in Figure 8-21.

147

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bit

16

24

31

~ ~

MAC Management Message Header Downstream Channel ID Pending Till Complete

~ ~

SID

Figure 8-21 Packet PDU Following the Timing Header

Parameters MUST be as follows:

SID

For RNG-REQ messages transmitted in Broadcast Initial Maintenance intervals: 1

Initialization SID if modem is attempting to join the network Initialization SID if modem has not yet registered and is changing upstream, downstream, or both
downstream and upstream channels as directed by a downloaded parameter file

Primary SID (previously assigned in REG-RSP) if modem is registered and is changing upstream
channels, or if the CM is redoing initial ranging as a result of a DCC, UCC, or UCD change (see Sections 8.3.3 and 11.3.2) For RNG-REQ messages transmitted in Unicast Initial Maintenance or Station Maintenance intervals:

Temporary SID if modem has not yet registered Primary SID (previously assigned in REG-RSP) if modem is registered or is redoing initial ranging
as a result of DCC, UCC, or UCD change This is a 16-bit field of which the lower 14 bits define the SID, with bits 14 and 15 defined to be 0.
Downstream Channel ID The identifier of the downstream channel on which the CM received the UCD which described this upstream. This is an 8-bit field. Pending Till Complete If zero, then all previous Ranging Response attributes have been applied prior to transmittting this request. If non zero then this is time estimated to be needed to complete assimilation of ranging parameters. Note that only equalization can be deferred. Units are in unsigned centiseconds (10 msec).

A CM MUST set the RSVD field of the MAC Management Message Header to report support of the S-CDMA Maximum Scheduled Codes if and only if the CMTS indicated that it supports the S-CDMA Maximum Scheduled Codes from TLV-17 of the UCD for the upstream channel on which the CM is ranging. In this case, the CM MUST report the maximum ratio of number of active codes to Maximum Scheduled Codes that the CM can support; this ratio is indicated by a bit mask in the reserved field as shown below. For example, if the number of active codes on the channel is 128 and the CM supports a minimum of 64 scheduled codes (the minimum number of allowed active codes), the CM would report a ratio of 2. The CMTS will use this value in calculating an appropriate value for Maximum Scheduled Codes to assign to the CM. The CM SHOULD support a Maximum Ratio of 32.

1.

Deleted bullet statement Temporary SID... per ECN RFI2-N-03077 by GO on 07/03/03.

148

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

When the CM reports support for the SCDMA Maximum Scheduled Codes, the CM MUST also report its current transmit power shortfall (in dB). The CM power shortfall is the difference between the current target transmit power of the ranging request and the maximum SCDMA spreader-on transmit power of 53 dBmV. The CM MUST report a power shortfall of 0 if the current target transmit power of the ranging request is less than or equal to 53 dBmV. This value will be used by the CMTS for calculating appropriate values for S-CDMA Maximum Scheduled Codes and S-CDMA Power Headroom for the CM. 1 The format of the RSVD field is:
Bit 7: 1= S-CDMA Maximum Scheduled Codes Supported Bits 6 to 5: CM Maximum Ratio of: Bit 4 to 0: CM power shortfall (1/4 dB)

00 = 20 1=8 10 = 16 11 = 32

8.3.6 Ranging Response (RNG-RSP)

A Ranging Response MUST be transmitted by a CMTS in response to received RNG-REQ or INIT-RNG-REQ. The state machines describing the ranging procedure appear in Section 11.2.4. In that procedure it may be noted that, from the point of view of the CM, reception of a Ranging Response is stateless. In particular, the CM MUST be prepared to receive a Ranging Response at any time, not just following a Ranging Request. To provide for flexibility, the message parameters following the Upstream Channel ID MUST be encoded in a type/length/value (TLV) form.

Bit

0 ~ ~

16

24

31 ~ ~

MAC Management Message Header Upstream channel ID

SID from request

TLV Encoded Information

Figure 8-22

Ranging Response

A CMTS MUST generate Ranging Responses in the form shown in Figure 8-22, including all of the following parameters:

1.

Added the preceding two paragraphs and the matrix below per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/ 04.

149

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

SID If the modem is being instructed by this response to move to a different channel, this is initialization SID. Otherwise, this is the SID from the corresponding RNG-REQ to which this response refers, except that if the corresponding RNG-REQ was an initial ranging request specifying a initialization SID, then this is the assigned temporary SID. Upstream Channel ID The identifier of the upstream channel on which the CMTS received the RNG-REQ or INIT-RNG-REQ to which this response refers. On the first ranging response received by the CM during initial ranging, this channel ID may be different from the channel ID the CM used to transmit the range request (see III). Thus, the CM MUST use this channel ID for the rest of its transactions, not the channel ID from which it initiated the range request.

All other parameters are coded as TLV tuples.

Ranging Status

Used to indicate whether upstream messages are received within acceptable limits by CMTS.

Timing Adjust, Integer Part The amount by which to change the Ranging Offset of the burst transmission so that bursts arrive at the expected mini-slot time at the CMTS. The units are (1 / 10.24 MHz) = 97.65625 ns. A negative value implies the Ranging Offset is to be decreased, resulting in later times of transmission at the CM. (See Table 6-8 and Section 6.2.19.1, Ranging Offset," on page 85)1 Power Adjust Information Specifies the relative change in transmission power level that the CM is to make in order that transmissions arrive at the CMTS at the desired power. Frequency Adjust Information Specifies the relative change in transmission frequency that the CM is to make in order to better match the CMTS. (This is fine-frequency adjustment within a channel, not re-assignment to a different channel) CM Transmitter Equalization Information

This provides the equalization coefficients for the pre-equalizer.

Downstream Frequency Override An optional parameter. The downstream frequency with which the modem should redo initial ranging. (See Section 8.3.6.3) Upstream Channel ID Override An optional parameter. The identifier of the upstream channel with which the modem should redo initial ranging. (See Section 8.3.6.3) Timing Adjust, Fractional Part Higher resolution timing adjust offset to be appended to Timing Adjust, Integer Part. The units are (1 / (256*10.24 MHz)) = 0.3814697265625 ns. This parameter provides finer granularity timing offset information for transmission in S-CDMA mode. This TLV MUST be present for S-CDMA channels.2 S-CDMA Maximum Scheduled Codes The value that the CMTS uses to limit the number of codes scheduled to a CM in an S-CDMA frame. CMs that implement the S-CDMA Maximum Scheduled Codes use this value to limit the maximum size of a concatenated burst in an S-CDMA Frame. S-CDMA Power Headroom CMs that implement the S-CDMA Maximum Scheduled Codes MUST use this value to control transmit power as per Section 6.2.18.2.3

1.

Timing Adjust Information changed to Timing Adjust, Integer Part per RFI2-N-02104 by RKV on 10/28/02. Fine Timing Adjust Extension changed to Timing Adjust, Fractional Part per RFI2-N-02104 by RKV on 10/28/02.

2.

150

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.6.1

Encodings

The type values used MUST be those defined in Table 8-21 and Figure 8-23. These are unique within the ranging response message but not across the entire MAC message set. The type and length fields MUST each be 1 octet in length.
Table 8-21 Ranging Response Message Encodings1 2 3 4 5 6
Type (1 byte) Length (1 byte) Value (Variable Length)

Name

Timing Adjust, Integer Part Power Level Adjust Offset Frequency Adjust Transmit Equalization Adjust

1 2 3 4

4 1 2 n

TX timing offset adjustment (signed 32-bit, units of (6.25 microsec/64)) TX Power offset adjustment (signed 8-bit, 1/4-dB units) TX frequency offset adjustment (signed 16-bit, Hz units) TX equalization data to be convolved with current values (refer to Section 6.2.15, Transmit Pre-Equalizer, on page 74). See Figure 8-23 for details about representation. This TLV MUST NOT be included in a RNG-RSP that includes a type 9 TLV. 1 = continue, 2 = abort, 3 = success Center frequency of new downstream channel in Hz Identifier of the new upstream channel. TX timing fine offset adjustment. 8-bit unsigned value specifying the fine timing adjustment in units of 1/(256*10.24 MHz) TX equalization data to be loaded in place of current values (refer to Section 6.2.15, Transmit Pre-Equalizer, on page 74). See Figure 8-23 for details about representation. This TLV MUST NOT be included in a RNG-RSP to a DOCSIS 1.x CM, and MUST NOT be included in a RNG-RSP that includes a type 4 TLV. Reserved for future use A CMTS MAY send this TLV only if a CM indicated in the RNG-REQ or INIT-RNG_REQ that it supports the SCDMA Maximum Scheduled Codes. A value of 0 means no code limit. Other possible values range from 4 to number_active_codes inclusive. Maximum Scheduled codes must be an integer multiple of codes_per_minislots. If S-CDMA mode is disabled, this TLV MUST NOT be present. Absence of this TLV indicates that Maximum Scheduled Codes is disabled for this CM which MUST then use the S-CDMA Number of Active Codes.

Ranging Status Downstream frequency override Upstream channel ID override Timing Adjust, Fractional Part

5 6 7 8

1 4 1 1

Transmit Equalization Set

Reserved S-CDMA Maximum Scheduled Codes

10-255 10

n 1

S-CDMA Power Headroom

11

A CMTS MUST send this TLV to a CM in conjunction with TLV-10. If S-CDMA mode is disabled, this TLV MUST NOT be present. The units are dB. The range of this TLV is from 0 to 4*10log (

3.

Added this and the preceding statement per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.

151

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

type 4 or 49 number of forward taps (N)

length number of reserved reverse taps (M)

main tap location

number of forward taps per symbol

first coefficient F1 (real)

first coefficient F1 (imag)

last coefficient FN (real) first reverse coefficient D1 (real)

last coefficient FN (imag) first reverse coefficient D1 (imag)

Figure 8-23 Generalized Decision Feedback Equalization Coefficients

The number of taps per modulation interval T MUST be either 1, 2, or 4. The main tap location refers to the position of the zero delay tap, between 1 and N. For a T-spaced equalizer, the number of taps per modulation interval field MUST be set to 1. The total number of taps MAY range up to 64. Each tap consists of a real and imaginary coefficient entry in the table. If more than 255 bytes are needed to represent equalization information, then several type 4 or 9 elements MAY be used. Data MUST be treated as if byte-concatenated, that is, the first byte after the length field of the second type 4 or 9 element is treated as if it immediately followed the last byte of the first type 4 or 9 element. Figure 6-28, Transmit Pre-Equalizer Structure, on page 75 depicts the operation of the equalizer.
8.3.6.2 Example of TLV Data

An example of TLV data is given in Figure 8-24.

1.

Timing Adjust Information row changed to Timing Adjust, Integer Part per RFI2-N-02104 by RKV on 10/28/02. Replaced word below with Figure 8-23, per ECN RFI2-N-02210, by GO, on 11/21/02 Fine Timing Adjust Extension row changed to Timing Adjust, Fractional Part per RFI2-N-02104 by RKV on 10/28/02. Replaced word below with Figure 8-23, per ECN RFI2-N-02210, by GO, on 11/21/02. Revised Transmit Equalization Set value reference to Section 6.215, Transmit Pre-Equalizer per ECN RFI2-N-03077 by GO on 07/03/03. Added the S-CDMA Maximum Scheduled Codes, and S-CDMA Power Headroom per ECN RFIv2.0-N04.0167-2 by GO on 10/15/04.

2. 3.

4. 5.

6.

152

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Type 1 Type 2 Type 3 Type 4 Type 5

Length 4 Length 1 Length 2 Length x Length 1

Timing adjust

Power adjust Frequency adjust information x bytes of CM transmitter equalization information Ranging status

Figure 8-24 Example of TLV Data

8.3.6.3

Overriding Channels Prior to Registration1

The RNG-RSP message allows the CMTS to instruct the modem to move to a new downstream and/or upstream channel and to repeat initial ranging. However, the CMTS may do this only in response to an initial ranging request from a modem that is attempting to join the network, or in response to any of the unicast ranging requests that take place immediately after this initial ranging and up to the point where the modem successfully completes periodic ranging. If a downstream frequency override is specified in the RNG-RSP, the modem MUST reinitialize its MAC (Section 11.2) using initial ranging with the specified downstream center frequency as the first scanned channel. For the upstream channel, the modem selects its channel based on received UCD messages as per Section 11.2.2. If an upstream channel ID override is specified in the RNG-RSP, the modem MUST reinitialize its MAC (see Section 11.2) using initial ranging with the upstream channel specified in the RNG-RSP for its first attempt and the same downstream frequency on which the RNG-RSP was received. If both downstream frequency and upstream channel ID overrides are present in the RNG-RSP, the modem MUST reinitialize its MAC (refer to Section 11.2) using initial ranging with the specified downstream frequency and upstream channel ID for its first attempt. Note that when a modem with an assigned temporary SID is instructed to move to a new downstream and/or upstream channel and to redo initial ranging, the modem MUST consider the temporary SID to be deassigned. The modem MUST redo initial ranging using the Initialization SID. Configuration file settings for upstream channel ID and downstream frequency(s) are optional, but if specified in the config file they take precedence over the ranging response parameters. Once ranging is complete, only the Annex C.1.1.2, UCC-REQ, and DCC-REQ mechanisms are available for moving the modem to a new upstream channel, and only the Annex C.1.1.1, Annex C.1.1.21, and DCC-REQ mechanisms are available for moving the modem to a new downstream channel.2

1. 2.

Revised cross-references in this section per ECN RFI2-N-03077 by GO on 07/08/03. Revised this paragraph per ECN RF!v2.0-N-03.0086-7 by GO on 3/12/04.

153

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.7 Registration Request (REG-REQ)

A Registration Request MUST be transmitted by a CM at initialization after receipt of a CM parameter file, except as outlined in Sections 11.2.8 and 11.2.9. To provide for flexibility, the message parameters following the SID MUST be encoded in a type/length/value form.

Bit

16

24

31

~ ~

MAC Management Message Header

~ ~

SID

TLV Encoded Information

Figure 8-25 Registration Request

A CM MUST generate Registration Requests in the form shown in Figure 8-25, including the following parameters:
SID

Temporary SID for this CM.

All other parameters are coded as TLV tuples as defined in Annex C. Registration Requests can contain many different TLV parameters, some of which are set by the CM according to its configuration file and some of which are generated by the CM itself. If found in the Configuration File, the following Configuration Settings MUST be included in the Registration Request. Configuration File Settings:

All configuration settings included in the CMTS MIC calculation as specified in Section D.3.1 Enable 2.0 Mode Downstream Channel List1 CMTS MIC Configuration Setting
Note: The CM MUST forward DOCSIS Extension Field configuration settings to the CMTS in the same order in which they were received in the configuration file to allow the message integrity check to be performed.2

1. 2.

Added this bullet statement per ECN RFIv2.0-N-03.0086-7 by GO on 3/15/04. Revised this note per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

154

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The following registration parameter MUST be included in the Registration Request. Vendor Specific Parameter:

Vendor ID Configuration Setting (Vendor ID of CM)

The Modem Capabilities Encodings registration parameter MUST also be included in the Registration Request.1 The following registration parameters MAY also be included in the Registration Request.

Modem IP Address Vendor Specific Capabilities

The Vendor Specific Capabilities field is for vendor specific information not included in the configuration file. The following Configuration Settings MUST NOT be forwarded to the CMTS in the Registration Request.

Software Upgrade Filename Software Upgrade TFTP Server IP Address SNMP Write-Access Control SNMP MIB Object SNMPv3 Kickstart Value CPE Ethernet MAC Address HMAC Digest End Configuration Setting Pad Configuration Setting Telephone Settings Option SNMPv3 Notification Receiver

8.3.8 Registration Response (REG-RSP)

A Registration Response MUST be transmitted by the CMTS in response to a received REG-REQ. To provide for flexibility, the message parameters following the Response field MUST be encoded in a TLV format.

1.

The CM MUST specify all of its Modem Capabilities in its Registration Request subject to the restrictions in Annex C.1.3.1. The CMTS MUST NOT assume any Modem Capability which is defined but not explicitly indicated in the CMs Registration Request.

155

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bit

0 ~ ~

16

24

31 ~ ~

MAC Management Message Header

SID from corresponding REG-REQ

Response

TLV Encoded Information

Figure 8-26

Registration Response Format

A CMTS MUST generate Registration Responses in the form shown in Figure 8-26, including both of the following parameters:
SID from Corresponding REG-REQ SID from corresponding REG-REQ to which this response refers. (This acts as a transaction identifier) Response For REG-RSP to a modem registering as a 1.0 modem (i.e., REG-REQ contains DOCSIS 1.0 Class of Service Encodings)

0 = Okay 1 = Authentication Failure 2 = Class of Service Failure For REG-RSP to a modem registering as a 1.1 or 2.0 modem (i.e., REG-REQ contains Service Flow Encodings), this field MUST contain one of the Confirmation Codes in Annex C.4 and Annex C.4.2.
Note: Failures apply to the entire Registration Request. Even if only a single requested Service Flow or DOCSIS 1.0 Service Class is invalid or undeliverable the entire registration is failed.

If the REG-REQ was successful, and contained Service Flow Parameters, Classifier Parameters, or Payload Header Suppression Parameters, the REG-RSP MUST contain, for each of these:
Classifier Parameters All of the Classifier Parameters from the corresponding REG-REQ, plus the Classifier Identifier assigned by the CMTS. Service Flow Parameters All the Service Flow Parameters from the REG-REQ, plus the Service Flow ID assigned by the CMTS. Every Service Flow that contained a Service Class Name that was admitted/activated1 MUST be expanded into the full set of TLVs defining the Service Flow. Every upstream Service Flow that was admitted/activated MUST have a Service Identifier assigned by the CMTS. A Service Flow that was only

1.

The ActiveQoSParamSet or AdmittedQoSParamSet is non-null.

156

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

provisioned will include only those QoS parameters that appeared in the REG-REQ, plus the assigned Service Flow ID.
Payload Header Suppression Parameters All the Payload Header Suppression Parameters from the REGREQ, plus the Payload Header Suppression Index assigned by the CMTS.

If the REG-REQ failed due to Service Flow Parameters, Classifier Parameters, or Payload Header Suppression Parameters, and the Response is not one of the major error codes in Annex C.4.2, the REG-RSP MUST contain at least one of the following:
Classifier Error Set A Classifier Error Set and identifying Classifier Reference and Service Flow Reference MUST be included for at least one failed Classifier in the corresponding REG-REQ. Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the corresponding Classifier. Service Flow Error Set A Service Flow Error Set and identifying Service Flow Reference MUST be included for at least one failed Service Flow in the corresponding REG-REQ. Every Service Flow Error Set MUST include at least one specific failed QoS Parameter of the corresponding Service Flow. Payload Header Suppression Error Set A PHS Error Set and identifying Service Flow Reference and Classifier Reference pair MUST be included for at least one failed PHS Rule in the corresponding REG-REQ. Every PHS Error Set MUST include at least one specific failed PHS Parameter of the corresponding failed PHS Rule.

Service Class Name expansion always occurs at admission time. Thus, if a Registration-Request contains a Service Flow Reference and a Service Class Name for deferred admission/activation, the Registration-Response MUST NOT include any additional QoS Parameters except the Service Flow Identifier. (Refer to Section 10.1.3, Service Classes, on page 211.) If the corresponding Registration Request contains DOCSIS 1.0 Service Class TLVs (refer to Annex C.1.1.4), the Registration Response MUST contain the following TLV tuples:
DOCSIS 1.0 Service Class Data Returned when Response = Okay. This is a Service ID / service class tuple for each class of service granted.
Note:

Service class IDs MUST be those requested in the corresponding REG-REQ.

Service Not Available Returned when Response = Class of Service Failure. If a service class cannot be supported, this configuration setting is returned in place of the service class data.

All other parameters are coded TLV tuples.

Modem Capabilities Request) Vendor-Specific Data

The CMTS response to the capabilities of the modem (if present in the Registration

As defined in Annex C

Vendor ID Configuration Setting (vendor ID of the CMTS) Vendor-specific extensions

8.3.8.1 Encodings

The type values used MUST be those shown below. These are unique within the Registration Response message but not across the entire MAC message set. The type and length fields MUST each be 1 octet.

157

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.8.1.1

Modem Capabilities

This field defines the CMTS response to the modem capability field in the Registration Request. The CMTS MUST respond to the modem capability to indicate whether they may be used. If the CMTS does not recognize a modem capability, it MUST return the TLV with the value zero (off) in the Registration Response. Only capabilities set to on in the REG-REQ may be set on in the REG-RSP as this is the handshake indicating that they have been successfully negotiated. Capabilities set to off in the REG-REQ MUST also be set to off in the REG-RSP. Encodings are as defined for the Registration Request.
8.3.8.1.2 DOCSIS 1.0 Service Class Data

A DOCSIS 1.0 Service Class Data parameter MUST be present in the Registration Response for each DOCSIS 1.0 Class of Service parameter (refer to Annex C.1.1.4) in the Registration Request. This encoding defines the parameters associated with a requested class of service. It is somewhat complex in that it is composed from a number of encapsulated type/length/value fields. The encapsulated fields define the particular class of service parameters for the class of service in question. Note that the type fields defined are only valid within the encapsulated service class data configuration setting string. A single service class data configuration setting MUST be used to define the parameters for a single service class. Multiple class definitions MUST use multiple service class data configuration setting sets. Each received DOCSIS 1.0 Class of Service parameter must have a unique Class ID in the range 1..16. If no Class ID is present for any single DOCSIS 1.0 Class-of-Service TLV in the REG-REQ, the CMTS MUST send a REG-RSP with a class-of-service failure response and no DOCSIS 1.0 Class-of-Service TLVs.
Type 1 Length n Value Encoded service class data

Class ID The value of the field MUST specify the identifier for the class of service to which the encapsulated string applies. This MUST be a class which was requested in the associated REG-REQ, if present.
Type 1.1 Length 1 Value from REG-REQ

Valid Range: The class ID MUST be in the range 1 to 16. Service ID: The value of the field MUST specify the SID associated with this service class.
Type 1.2 Length 2 Value SID

8.3.9 Registration Acknowledge (REG-ACK)

A Registration Acknowledge MUST be transmitted by the CM in response to a REG-RSP from the CMTS with a confirmation code of ok (0).1 It confirms acceptance by the CM of the QoS parameters of the flow as reported

158

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

by the CMTS in its REG-RSP. The format of a REG-ACK MUST be as shown in Figure 8-27.
Bit 0 ~ ~ SID from corresponding REG-RSP Confirmation Code 8 16 24 31 ~ ~

MAC Management Message Header

TLV Encoded Information

Figure 8-27 Registration Acknowledgment

The parameter MUST be as follows:

SID from Corresponding: REG-RSP SID from corresponding REG-RSP to which this acknowledgment refers. (This acts as a transaction identifier) Confirmation Code The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding Registration Response.

The CM is required to send all provisioned Classifiers, Service Flows and Payload Header Suppression Rules to the CMTS in the REG-REQ (see Section 6.3.7). The CMTS will return them with Identifiers, expanding Service Class Names if present, in the REG-RSP (see Section 6.3.8). Since the CM may be unable to support one or more of these provisioned items, the REG-ACK includes Error Sets for all failures related to these provisioned items. If there were any failures of provisioned items, the REG-ACK MUST include the Error Sets corresponding to those failures. The Error Set identification is provided by using Service Flow ID and Classifier ID from corresponding REG-RSP. If a Classifier ID or SFID was omitted in the REG-RSP, the CM MUST use the appropriate Reference (Classifier Reference, SF Reference) in the REG-ACK.
Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service Flow Reference/Identifier pair MUST be included for at least one failed Classifier in the corresponding REG-RSP. Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the corresponding Classifier. This parameter MUST be omitted if the entire REG-REQ/RSP is successful. Service Flow Error Set A Service Flow Error Set of the REG-ACK message encodes specifics of failed Service Flows in the REG-RSP message. A Service Flow Error Set and identifying Service Flow Reference/ Identifier MUST be included for at least one failed QoS Parameter of at least one failed Service Flow in the corresponding REG-RSP message. This parameter MUST be omitted if the entire REG-REQ/RSP is successful.

1.

The Registration-Acknowledge is a DOCSIS 1.1/2.0 message. Refer to Annex G for details of registration interoperability issues.

159

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Payload Header Suppression Error Set A PHS Error Set and identifying Service flow Reference/Identifier and Classifier Reference/Identifier pair MUST be included for at least one failed PHS Rule in the corresponding REG-RSP. Every PHS Error Set MUST include at least one specific failed PHS of the failed PHS Rule. This parameter MUST be omitted if the entire REG-REQ/RSP is successful.

Per Service Flow acknowledgment is necessary not just for synchronization between the CM and CMTS, but also to support use of the Service Class Name. (Refer to Section 10.1.3, Service Classes, on page 211) Since the CM may not know all of the Service Flow parameters associated with a Service Class Name when making the Registration Request, it may be necessary for the CM to NAK a Registration Response if it has insufficient resources to actually support this Service Flow.
8.3.10 Upstream Channel Change Request (UCC-REQ)

An Upstream Channel Change Request MAY be transmitted by a CMTS to cause a CM to change the upstream channel on which it is transmitting. The format of an UCC-REQ message is shown in Figure 8-28.

Bit

16

24

31

~ ~
Upstream channel ID

MAC Management Message Header

~ ~

Figure 8-28

Upstream Channel Change Request1

Parameters MUST be as follows:

Upstream Channel ID The identifier of the upstream channel to which the CM is to switch for upstream transmissions. This is an 8-bit field.

Upon receipt of a UCC-REQ message, the CM MUST perform ranging with broadcast initial maintenance.
8.3.11 Upstream Channel Change Response (UCC-RSP)

An Upstream Channel Change Response MUST be transmitted by a CM in response to a received Upstream Channel Change Request message to indicate that it has received and is complying with the UCC-REQ. The format of an UCC-RSP message is shown in Figure 8-29. Before it begins to switch to a new upstream channel, a CM MUST transmit a UCC-RSP on its existing upstream channel. A CM MAY ignore an UCC-REQ message while it is in the process of performing a channel change. When a CM receives a UCC-REQ message requesting that it switch to an upstream channel that it is already using, the CM MUST respond with a UCC-RSP message on that channel indicating that it is already using the correct channel. After switching to a new upstream channel, a CM MUST re-range using broadcast initial ranging, and then MUST proceed without re-performing registration. The full procedure for changing channels is described in Section 11.3.3.

1.

Revise Figure 8-28 to match Figure 8-29, per ECN RFI2-N-02210, by GO, on 11/21/02.

160

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Bit

16

24

31

~ ~
Upstream channel ID

MAC Management Message Header

~ ~

Figure 8-29 Upstream Channel Change Response

Parameters MUST be as follows:

Upstream Channel ID The identifier of the upstream channel to which the CM is to switch for upstream transmissions. This MUST be the same Channel ID specified in the UCC-REQ message. This MUST be an 8-bit field. 8.3.12 Dynamic Service Addition Request (DSA-REQ)

A Dynamic Service Addition Request MAY be sent by a CM or CMTS to create a new Service Flow.

Bit

0 ~ ~

16

24

31 ~ ~

MAC Management Message Header

Transaction ID

TLV Encoded Information

Figure 8-30 Dynamic Service Addition Request

A CM or CMTS MUST generate DSA-REQ messages in the form shown in Figure 8-30 including the following parameter:

161

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Transaction ID

Unique identifier for this transaction assigned by the sender.

All other parameters are coded as TLV tuples as defined in Annex C. A DSA-REQ message MUST NOT contain parameters for more than one Service Flow in each direction, i.e., a DSA-REQ message MUST contain parameters for either a single upstream Service Flow, or for a single downstream Service Flow, or for one upstream and one downstream Service Flow. The DSA-REQ message MUST contain:
Service Flow Parameters Specification of the Service Flows traffic characteristics and scheduling requirements.

The DSA-REQ message MAY contain classifier parameters and payload header suppression parameters associated with the Service Flows specified in the message:
Classifier Parameters Specification of the rules to be used to classify packets into a specific Service Flow. Payload Header Suppression Parameters with an associated classifier.

Specification of the payload header suppression rules to be used

If Privacy is enabled, the DSA-REQ message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1) 8.3.12.1 CM-Initiated Dynamic Service Addition

CM-initiated DSA-Requests MUST use the Service Flow Reference to link Classifiers to Service Flows. Values of the Service Flow Reference are local to the DSA message; each Service Flow within the DSA-Request MUST be assigned a unique Service Flow Reference. This value need not be unique with respect to the other service flows known by the sender. CM-initiated DSA-Request MUST use the Classifier Reference and Service Flow Reference to link Payload Header Suppression Parameters to Classifiers and Service Flows. A DSA-request MUST use the Service Flow Reference to link Classifier to Service Flow. Values of the Classifier Reference are local to the DSA message; each Classifier within the DSA-request MUST be assigned a unique Classifier Reference. CM-initiated DSA-Requests MAY use the Service Class Name (refer to Annex C.2.2.3.4) in place of some, or all, of the QoS Parameters.
8.3.12.2 CMTS-Initiated Dynamic Service Addition

CMTS-initiated DSA-Requests MUST use the Service Flow ID to link Classifiers to Service Flows. Service Flow Identifiers are unique within the MAC domain. CMTS-initiated DSA-Requests for Upstream Service Flows MUST also include a Service ID. CMTS-initiated DSA-Requests which include Classifiers, MUST assign a unique Classifier Identifier on a per Service Flow basis.

162

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CMTS-initiated DSA-Requests for named Service Classes MUST include the QoS Parameter Set associated with that Service Class.
8.3.13 Dynamic Service Addition Response (DSA-RSP)

A Dynamic Service Addition Response MUST be generated in response to a received DSA-Request. The format of a DSA-RSP MUST be as shown in Figure 8-31.

Bit

0 ~ ~

16

24

31 ~ ~

MAC Management Message Header

Transaction ID

Confirmation Code

TLV Encoded Information

Figure 8-31

Dynamic Service Addition Response

Parameters MUST be as follows:

Transaction ID

Transaction ID from corresponding DSA-REQ. The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding

Confirmation Code DSA-Request.

All other parameters are coded as TLV tuples as defined in Annex C. If the transaction is successful, the DSA-RSP MAY contain one or more of the following:
Classifier Parameters The CMTS MUST include the complete specification of the Classifier in the DSARSP, including a newly assigned Classifier Identifier. The CM MUST NOT include the specification of the Classifier in the DSA-RSP. Service Flow Parameters The CMTS MUST include the complete specification of the Service Flow in the DSA-RSP, including a newly assigned Service Flow Identifier and an expanded service class name if applicable. The CM MUST NOT include the specification of the Service Flow in the DSA-RSP. Payload Header Suppression Parameters The CMTS MUST include the complete specification of the PHS Parameters in the DSA-RSP, including a newly assigned PHS Index, a Classifier Identifier, and a Service Flow Identifier. The CM MUST NOT include the specification of the PHS Parameters.

163

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

If the transaction is unsuccessful due to Service Flow Parameters, Classifier Parameters, or Payload Header Suppression Parameters, and the Confirmation Code is not one of the major error codes in Annex C.4.2, the DSA-RSP MUST contain at least one of the following:
Service Flow Error Set A Service Flow Error Set and identifying Service Flow Reference/Identifier MUST be included for at least one failed Service Flow in the corresponding DSA-REQ. Every Service Flow Error Set MUST include at least one specific failed QoS Parameter of the corresponding Service Flow. This parameter MUST be omitted if the entire DSA-REQ is successful. Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service Flow Reference/Identifier pair MUST be included for at least one failed Classifier in the corresponding DSA-REQ. Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the corresponding Classifier. This parameter MUST be omitted if the entire DSA-REQ is successful. Payload Header Suppression Error Set A PHS Error Set and identifying Classifier Reference/Identifier and Service Flow Reference/Identifier pair MUST be included for at least one failed PHS Rule in the corresponding DSA-REQ. Every PHS Error Set MUST include at least one specific failed PHS Parameter of the corresponding failed PHS Rule. This parameter MUST be omitted if the entire DSA-REQ is successful.

If Privacy is enabled, the DSA-RSP message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1) 8.3.13.1 CM-Initiated Dynamic Service Addition

The CMTSs DSA-Response for Service Flows that are successfully added MUST contain a Service Flow ID. The DSA-Response for successfully Admitted or Active upstream QoS Parameter Sets MUST also contain a Service ID. If the corresponding DSA-Request uses the Service Class Name (refer to Annex C.2.2.3.4) to request service addition, a DSA-Response MUST contain the QoS Parameter Set associated with the named Service Class. If the Service Class Name is used in conjunction with other QoS Parameters in the DSA-Request, the CMTS MUST accept or reject the DSA-Request using the explicit QoS Parameters in the DSA-Request. If these Service Flow Encodings conflict with the Service Class attributes, the CMTS MUST use the DSA-Request values as overrides for those of the Service Class. If the transaction is successful, the CMTS MUST assign a Classifier Identifier to each requested Classifier and a PHS Index to each requested PHS Rule. The CMTS MUST use the original Classifier Reference(s) and Service Flow Reference(s) to link the successful parameters in the DSA-RSP. If the transaction is unsuccessful, the CMTS MUST use the original Classifier Reference(s) and Service Flow Reference(s) to identify the failed parameters in the DSA-RSP.
8.3.13.2 CMTS-Initiated Dynamic Service Addition

If the transaction is unsuccessful, the CM MUST use the Classifier Identifier(s) and Service Flow Identifier(s) to identify the failed parameters in the DSA-RSP.

164

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.14

Dynamic Service Addition Acknowledge (DSA-ACK)

A Dynamic Service Addition Acknowledge MUST be generated in response to a received DSA-RSP. The format of a DSA-ACK MUST be as shown in Figure 8-32.
Bit 0 ~ ~ Transaction ID Confirmation Code 8 16 24 31 ~ ~

MAC Management Message Header

TLV Encoded Information

Figure 8-32 Dynamic Service Addition Acknowledge

Parameters MUST be as follows:

Transaction ID

Transaction ID from corresponding DSA-Response. The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding

Confirmation Code DSA-Response.1

All other parameters are coded TLV tuples.

Service Flow Error Set The Service Flow Error Set of the DSA-ACK message encodes specifics of failed Service Flows in the DSA-RSP message. A Service Flow Error Set and identifying Service Flow Reference/ Identifier MUST be included for at least one failed QoS Parameter of at least one failed Service Flow in the corresponding DSA-REQ. This parameter MUST be omitted if the entire DSA-REQ is successful.

If Privacy is enabled, the DSA-RSP message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1)

1.

The confirmation code is necessary particularly when a Service Class Name (refer to Section 10.1.3) is used in the DSA-Request. In this case, the DSA-Response could contain Service Flow parameters that the CM is unable to support (either temporarily or as configured).

165

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.15

Dynamic Service Change Request (DSC-REQ)

A Dynamic Service Change Request MAY be sent by a CM or CMTS to dynamically change the parameters of an existing Service Flow. DSCs changing classifiers MUST carry the entire classifier TLV set for that new classifier.
Bit 0 ~ ~ Transaction ID 8 16 24 31 ~ ~

MAC Management Message Header

TLV Encoded Information

Figure 8-33

Dynamic Service Change Request

A CM or CMTS MUST generate DSC-REQ messages in the form shown in Figure 8-33 including the following parameters:
Transaction ID

Unique identifier for this transaction assigned by the sender.

All other parameters are coded as TLV tuples as defined in Annex C. A DSC-REQ message MUST NOT carry parameters for more than one Service Flow in each direction, i.e., a DSC-REQ message MUST contain parameters for either a single upstream Service Flow, or for a single downstream Service Flow, or for one upstream and one downstream Service Flow. A DSC-REQ MUST contain at least one of the following:
Classifier Parameters Specification of the rules to be used to classify packets into a specific service flow this includes the Dynamic Service Change Action TLV which indicates whether this Classifier should be added, replaced or deleted from the Service Flow (refer to Annex C.2.1.3.7). If included, the Classifier Parameters MUST contain the Dynamic Change Action TLV, a Classifier Reference/Identifier and a Service Flow Identifier: Service Flow Parameters Specification of the Service Flows new traffic characteristics and scheduling requirements. The Admitted and Active Quality of Service Parameter Sets in this message replace the Admitted and Active Quality of Service Parameter Sets currently in use by the Service Flow. If the DSC message is successful and it contains Service Flow parameters, but does not contain replacement sets for both Admitted and Active Quality of Service Parameter Sets, the omitted set(s) MUST be set to null. If included, the Service Flow Parameters MUST contain a Service Flow Identifier. Payload Header Suppression Parameters Specification of the rules to be used for Payload Header Suppression to suppress payload headers related to a specific Classifierthis includes the Dynamic Service Change Action TLV which indicates whether this PHS Rule should be added, set or deleted from the Service Flow or whether all the PHS Rules for the Service Flow specified should be deleted (refer to Annex C.2.2.8.5). If included, the PHS parameters MUST contain the Dynamic Service Change Action TLV, a Classifier Reference/

166

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Identifier, and a Service Flow Identifier, unless the Dynamic Service Change Action is Delete all PHS Rules. If the Dynamic Service Change Action is Delete all PHS Rules, the PHS Parameters MUST contain a Service Flow Identifier along with the Dynamic Service Change Action, and no other PHS parameters need be present in this case. However, if other PHS parameters are present, in particular Payload Header Suppression Index, they MUST be ignored by the receiver of the DSC-REQ message. If Privacy is enabled, a DSC-REQ MUST also contain:
Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1) 8.3.16 Dynamic Service Change Response (DSC-RSP)

A Dynamic Service Change Response MUST be generated in response to a received DSC-REQ. The format of a DSC-RSP MUST be as shown in Figure 8-34
Bit 0 ~ ~ Transaction ID Confirmation Code 8 16 24 31 ~ ~

MAC Management Message Header

TLV Encoded Information

Figure 8-34 Dynamic Service Change Response

Parameters MUST be as follows:

Transaction ID

Transaction ID from corresponding DSC-REQ The appropriate Confirmation Code (refer to Annex C.4) for the corresponding DSC-

Confirmation Code Request.

All other parameters are coded as TLV tuples as defined in Annex C. If the transaction is successful, the DSC-RSP MAY contain one or more of the following:

167

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Classifier Parameters The CMTS MUST include the complete specification of the Classifier in the DSCRSP, including a newly assigned Classifier Identifier for new Classifiers. The CM MUST NOT include the specification of the Classifier in the DSC-RSP. Service Flow Parameters The CMTS MUST include the complete specification of the Service Flow in the DSC-RSP, including an expanded service class name if applicable. The CMTS MUST include a SID in the DSCRSP if a Service Flow Parameter Set contained an upstream Admitted QoS Parameter Set and this Service Flow does not have an associated SID. If a Service Flow Parameter set contained a Service Class Name and an Admitted QoS Parameter Set, the CMTS MUST include the QoS Parameter Set corresponding to the named Service Class in the DSC-RSP. If specific QoS Parameters were also included in the classed Service Flow request, the CMTS MUST include these QoS Parameters in the DSC-RSP instead of any QoS Parameters of the same type of the named Service Class. The CM MUST NOT include the specification of the Service Flow in the DSC-RSP. Payload Header Suppression Parameters The CMTS MUST include the complete specification of the PHS Parameters in the DSC-RSP, including a newly assigned PHS Index for new PHS rules, a Classifier Identifier and a Service Flow Identifier. The CM MUST NOT include the specification of the PHS Parameters.

If the transaction is unsuccessful due to Service Flow Parameters, Classifier Parameters, or Payload Header Suppression Parameters, and the Confirmation Code is not one of the major error codes in Annex C.4.2, the DSC-RSP MUST contain at least one of the following:
Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service Flow Reference/Identifier pair MUST be included for at least one failed Classifier in the corresponding DSC-REQ. Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the corresponding Classifier. This parameter MUST be omitted if the entire DSC-REQ is successful. Service Flow Error Set A Service Flow Error Set and identifying Service Flow ID MUST be included for at least one failed Service Flow in the corresponding DSC-REQ. Every Service Flow Error Set MUST include at least one specific failed QoS Parameter of the corresponding Service Flow. This parameter MUST be omitted if the entire DSC-REQ is successful. Payload Header Suppression Error Set A PHS Error Set and identifying Service Flow Reference/Identifier and Classifier Reference/Identifier pair MUST be included for at least one failed PHS Rule in the corresponding DSC-REQ, unless the Dynamic Service Change Action is Delete all PHS Rules. If the Dynamic Service Change Action is Delete all PHS Rules the PHS Error Set(s) MUST include an identifying Service Flow ID. Every PHS Error Set MUST include at least one specific failed PHS Parameter of the corresponding failed PHS Rule. This parameter MUST be omitted if the entire DSC-REQ is successful.

Regardless of success or failure, if Privacy is enabled for the CM the DSC-RSP MUST contain:
Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1)

168

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.17

Dynamic Service Change Acknowledge (DSC-ACK)

A Dynamic Service Change Acknowledge MUST be generated in response to a received DSC-RSP. The format of a DSC-ACK MUST be as shown in Figure 8-35.
Bit 0 ~ ~ Transaction ID Confirmation Code 8 16 24 31 ~ ~

MAC Management Message Header

TLV Encoded Information

Figure 8-35

Dynamic Service Change Acknowledge

Parameters MUST be as follows:

Transaction ID

Transaction ID from the corresponding DSC-REQ The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding

Confirmation Code DSC-Response.1

All other parameters are coded TLV tuples.

Service Flow Error Set The Service Flow Error Set of the DSC-ACK message encodes specifics of failed Service Flows in the DSC-RSP message. A Service Flow Error Set and identifying Service Flow Identifier MUST be included for at least one failed QoS Parameter of at least one failed Service Flow in the corresponding DSC-REQ. This parameter MUST be omitted if the entire DSC-REQ is successful.

If Privacy is enabled, the DSC-ACK message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1)

1.

The Confirmation Code and Service Flow Error Set are necessary particularly when a Service Class Name is (refer to Section 10.1.3) used in the DSC-Request. In this case, the DSC-Response could contain Service Flow parameters that the CM is unable to support (either temporarily or as configured).

169

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

8.3.18

Dynamic Service Deletion Request (DSD-REQ)

A DSD-Request MAY be sent by a CM or CMTS to delete a single existing Upstream Service Flow and/or a single existing Downstream Service Flow. The format of a DSD-Request MUST be as shown in Figure 8-36.

Bit

0 ~ ~

16

24

31 ~ ~

MAC Management Message Header

Transaction ID

Reserved

SFID

TLV Encoded Information

Figure 8-36 Dynamic Service Deletion Request

Parameters MUST be as follows:

Service Flow Identifier If this value is non-zero, it is the SFID of a single Upstream or single Downstream Service Flow to be deleted. If this value is zero, the Service Flow(s) to be deleted will be identified by SFID(s) in the TLVs. If this value is non-zero, any SFIDs included in the TLVs MUST be ignored. Transaction ID

Unique identifier for this transaction assigned by the sender.

All other parameters are coded as TLV tuples as defined in Annex C.

Service Flow Identifier The SFID(s) to be deleted, which MUST be encoded per Annex C.2.2.3.2. The Service Flow Identifier TLV MUST be the only Service Flow Encoding sub-TLV used.

If Privacy is enabled, the DSD-REQ MUST include:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. (Refer to Annex C.1.4.1)

170

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.19

Dynamic Service Deletion Response (DSD-RSP)

A DSD-RSP MUST be generated in response to a received DSD-REQ. The format of a DSD-RSP MUST be as shown in Figure 8-37.

Bit 0 ~ ~

16

24

31
~ ~

MAC Management Message Header

Transaction ID

Confirmation Code

Reserved

Figure 8-37

Dynamic Service Deletion Response

Parameters MUST be as follows:

Transaction ID

Transaction ID from corresponding DSD-REQ. The appropriate Confirmation Code (refer to Annex C.4) for the corresponding DSD-

Confirmation Code Request. 8.3.20

Dynamic Channel Change Request (DCC-REQ)1

A Dynamic Channel Change Request MAY be transmitted by a CMTS to cause a CM to change the upstream channel on which it is transmitting, the downstream channel on which it is receiving, or both.

Bit

16

24

31

MAC Management Message Header

Transaction ID

TLV Encoded Information

Figure 8-38

Dynamic Channel Change Request

1.

Replaced this section and subsections per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

171

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

A CMTS MUST generate DCC-REQ message in the form shown in Figure 8-38 including the following parameter:
Transaction ID

A 16-bit unique identifier for this transaction assigned by the sender.

The following parameters are optional and are coded as TLV tuples.
Upstream Channel ID transmissions Downstream Parameters downstream reception

The identifier of the upstream channel to which the CM is to switch for upstream

The frequency of the downstream channel to which the CM is to switch for

Initialization Technique Directions for the type of initialization, if any, that the CM should perform once synchronized to the new channel(s) UCD Substitution Provides a copy of the UCD for the new channel. This TLV occurs as many times as necessary to contain one UCD. SAID Substitution A pair of Security Association Identifiers (SAID) which contain the current SAID and the new SAID for the new channel. This TLV occurs once if the SAID requires substitution. Service Flow Substitution A group of sub-TLVs which allows substitution in a Service Flow of the Service Flow Identifier and Service Identifier. This TLV is repeated for every Service Flow which has parameters requiring substitution.

If Privacy is enabled, a DCC-REQ MUST also contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Section C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Channel Change messages Attribute list. (Refer to Section C.1.4.1) 8.3.20.1 Encodings

The type values used MUST be those shown below. These are unique within the Dynamic Channel Change Request message, but not across the entire MAC message set.
8.3.20.1.1 Upstream Channel ID

When present, this TLV specifies the new upstream channel ID that the CM MUST use when performing a Dynamic Channel Change. It is an override for the current upstream channel ID. The CMTS SHOULD ensure that the Upstream Channel ID for the new channel is different than the Upstream Channel ID for the old channel. This TLV MUST be included if the upstream channel is changed, even if the UCD substitution TLV is included.
Type 1 Length 1 Value 0-255: Upstream Channel ID

If this TLV is missing, the CM MUST NOT change its upstream channel ID. The CMTS MAY include this TLV. The CM MUST observe this TLV.

172

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.20.1.2

Downstream Parameters

When present, this TLV specifies the operating parameters of the new downstream channel. The value field of this TLV contains a series of sub-types.
Type 2 Length n Value

The CMTS MUST include this TLV when specifying a downstream channel change. If this TLV is missing, the CM MUST NOT change its downstream parameters.
8.3.20.1.2.1 Downstream Frequency

This TLV specifies the new receive frequency that the CM MUST use when performing a Dynamic Channel Change. It is an override for the current downstream channel frequency. This is the center frequency of the downstream channel in Hz and is stored as a 32-bit binary number. The downstream frequency MUST be a multiple of 62,500 Hz.
Subtype 2.1 Length 4 Value Rx Frequency

The CMTS MUST include this sub-TLV. The CM MUST observe this sub-TLV.
8.3.20.1.2.2 Downstream Modulation Type

This TLV specifies the modulation type that is used on the new downstream channel.
Subtype 2.2 Length 1 Value 0 = 64 QAM 1 = 256 QAM 2 - 255: reserved

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV.
8.3.20.1.2.3 Downstream Symbol Rate

This TLV specifies the symbol rate that is used on the new downstream channel.
Subtype 2.3 Length 1 Value 0 = 5.056941 Msym/sec 1 = 5.360537 Msym/sec 2 = 6.952 Msym/sec 3 - 255: reserved

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV.
8.3.20.1.2.4 Downstream Interleaver Depth

This TLV specifies the parameters I and J of the downstream interleaver.

Subtype 2.4 Length 2 Value I: 0-255 J: 0-255

173

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV.
8.3.20.1.2.5 Downstream Channel Identifier

This TLV specifies the 8 bit downstream channel identifier of the new downstream channel.
Subtype 2.5 Length 1 Value 0-255: Downstream Channel ID.

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV.
8.3.20.1.2.6 SYNC Substitution

When present, this TLV allows the CMTS to inform the CM to wait or not wait for a SYNC message before proceeding. The CMTS MUST have synchronized timestamps between the old and new channel(s) if it instructs the CM not to wait for a SYNC message before transmitting on the new channel. Synchronized timestamps implies that the timestamps are derived from the same clock and contain the same value.
Type 2.6 Length 1 Value 0 = acquire SYNC message on the new downstream channel before proceeding 1 = proceed without first obtaining the SYNC message 2 - 255: reserved

If this TLV is absent, the CM MUST wait for a SYNC message on the new channel before proceeding. If the CM has to wait for a new SYNC message when changing channels, then operation may be suspended for a time up to the SYNC Interval (see Annex B) or longer, if the SYNC message is lost or is not synchronized with the old channel(s). The CM MUST observe this TLV.
8.3.20.1.3 Initialization Technique

When present, this TLV allows the CMTS to direct the CM as to what level of re-initialization, if any, it MUST perform before it can commence communications on the new channel(s). The CMTS can make this decision based upon its knowledge of the differences between the old and new MAC domains and the PHY characteristics of their upstream and downstream channels. Typically, if the move is between upstream and/or downstream channels within the same MAC domain, then the connection profile values may be left intact. If the move is between different MAC domains, then a complete initialization may be performed. If a complete re-initialization is not required, some re-ranging may still be required. For example, areas of upstream spectrum are often configured in groups. A DCC-REQ to an adjacent upstream channel within a group may not warrant re-ranging. Alternatively, a DCC-REQ to a non-adjacent upstream channel might require unicast initial ranging whereas a DCC-REQ from one upstream channel group to another might require broadcast initial ranging. Re-ranging may also be required if there is any difference in the PHY parameters between the old and new channels.

174

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Type 3

Length 1

Value 0 = Reinitialize the MAC 1 = Perform broadcast initial ranging on new channel before normal operation 2 = Perform unicast ranging on new channel before normal operation 3 = Perform either broadcast or unicast ranging on new channel before normal operation 4 = Use the new channel(s) directly without re-initializing or ranging 5 - 255: reserved

The CM MUST first select the new upstream and downstream channels based upon the Upstream Channel ID TLV (refer to Section 8.3.20.1.1) and the Downstream Frequency TLV (refer to Section 8.3.20.1.2.1). The CM MUST follow the directives of these TLVs. For option 0, the CM MUST begin with the Initialization SID. For options 1 to 4 the CM MUST continue to use the primary SID for ranging. A SID Substitution TLV (see Section 8.3.20.1.6.2) may specify a new primary SID for use on the new channel (refer to Section 8.3.20.1.6.2).
Option 0:

This option directs the CM to perform all the operations associated with initializing the CM (refer to Section 11.2). This includes all the events after acquiring downstream QAM, FEC, and MPEG lock and before Standard Operation (refer to Section 11.3), including obtaining a UCD, ranging, establishing IP connectivity, establishing time of day, transfer of operational parameters, registration, and baseline privacy initialization. When this option is used, the only other TLVs in DCC-REQ that are relevant are the Upstream Channel ID TLV and the Downstream Parameters TLV. All other DCC-REQ TLVs are irrelevant. If broadcast initial ranging is specified, operation on the new channel could be delayed by several Ranging Intervals (see Annex B). If unicast ranging is specified, operation on the new channel could be delayed by the value of T4 (see Annex B). This value authorizes a CM to use an initial maintenance or station maintenance region, whichever the CM selects. This value might be used when there is uncertainty when the CM may execute the DCC command and thus a chance that it might miss station maintenance slots. This option provides for the least interruption of service. The CM may continue its normal operation as soon as it has achieved synchronization on the new channel.

Option 1: Option 2: Option 3:

Option 4:

If this TLV is absent, the CM MUST re-initialize the MAC. The CMTS MAY include this TLV. The CM MUST observe this TLV.
8.3.20.1.4 UCD Substitution

When present, this TLV allows the CMTS to send an Upstream Channel Descriptor message to the CM. This UCD message is intended to be associated with the new upstream and/or downstream channel(s). The CM stores this UCD message in its cache, and uses it after synchronizing to the new channel(s).
Type 4 Length n Value UCD for the new upstream channel

This TLV includes all parameters for the UCD message as described in Section 8.3.3 except for the MAC Management Message Header. The CMTS MUST ensure that the change count in the UCD matches the change count in the UCDs of the new channel(s). The CMTS SHOULD ensure that the Upstream Channel ID for the new channel is different than the Upstream Channel ID for the old channel. If the Upstream Channel IDs for the old and new channels are identical, the CMTS MUST include this TLV. The Ranging Required parameter in the new UCD does not apply in this context, since the functionality is covered by the Initialization Technique TLV.

175

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

If the length of the UCD exceeds 254 bytes, the UCD MUST be fragmented into two or more successive Type 4 elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the UCD Substitution by concatenating the contents (Value of the TLV) of successive Type 4 elements in the order in which they appear in the DCC-REQ message. For example, the first byte following the length field of the second Type 4 element is treated as if it immediately follows the last byte of the first Type 4 element. If the CM has to wait for a new UCD message when changing channels, then operation may be suspended for a time up to the UCD Interval (see Annex B) or longer, if the UCD message is lost. The CM MUST observe this TLV, even if the Upstream Channel ID and the UCD change count match the old channel.
8.3.20.1.5 Security Association Identifier (SAID) Substitution

When present, this TLV allows the CMTS to replace the Security Association Identifier (SAID) in the current Service Flow with a new Security Association Identifier. The baseline privacy keys associated with the SAID MUST remain the same. The CM does not have to simultaneously respond to the old and new SAID.
Type 6 Length 4 Value current SAID (lower-order 14 bits of a 16-bit field), new SAID (lower-order 14 bits of a 16-bit field)

If this TLV is absent, the current Security Association Identifier assignment is retained. The CMTS MAY include this TLV. The CM MUST observe this TLV.
8.3.20.1.6 Service Flow Substitutions

When present, this TLV allows the CMTS to replace specific parameters within the current Service Flows on the current channel assignment with new parameters for the new channel assignment. One TLV is used for each Service Flow that requires changes in parameters. The CMTS may choose to do this to help facilitate setting up new QoS reservations on the new channel before deleting QoS reservations on the old channel. The CM does not have to simultaneously respond to the old and new Service Flows. This TLV allows resource assignments and services to be moved between two independent ID value spaces and scheduling entities by changing the associated IDs and indices. ID value spaces that may differ between the two channels include the Service Flow Identifier and the Service ID. This TLV does not allow changes to Service Flow QoS parameters. The Service Class Names used within the Service Flow ID should remain identical between the old and new channels.
Type 7 Length n Value list of subtypes

If this TLV is absent for a particular Service Flow, then current Service Flow and its attributes are retained. The CMTS MAY include this TLV. The CM MUST observe this TLV.
8.3.20.1.6.1 Service Flow Identifier Substitution

This TLV allows the CMTS to replace the current Service Flow Identifier (SFID) with a new Service Flow Identifier. Refer to Section C.2.2.3.2 for usage details.

176

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

This TLV MUST be present if any other Service Flow subtype substitutions are made. If this TLV is included and the Service Flow ID is not changing, then the current and new Service Flow ID will be set to the same value.
Subtype 7.1 Length 8 Value current Service Flow ID, new Service Flow ID

The CMTS MUST include this Sub-TLV. The CM MUST observe this Sub-TLV.
8.3.20.1.6.2 Service Identifier Substitution

When present, this TLV allows the CMTS to replace the Service Identifier (SID) in the current upstream Service Flow with a new Service Identifier. Refer to Section C.2.2.3.3 for usage details.
Subtype 7.2 Length 4 Value current SID (lower-order 14 bits of a 16-bit field), new SID (lower-order 14 bits of a 16-bit field)

If this TLV is absent, the current Service Identifier assignments are retained. The CMTS MAY include this TLV. The CM MUST observe this TLV.
8.3.20.1.6.3 Unsolicited Grant Time Reference Substitution

When present, this TLV allows the CMTS to replace the current Unsolicited Grant Time Reference with a new Unsolicited Grant Time Reference. Refer to Section C.2.2.6.11 for usage details. This TLV is useful if the old and new upstream use different time bases for their time stamps. This TLV is also useful if the Unsolicited Grant transmission window is moved to a different point in time. Changing this value may cause operation to temporarily exceed the jitter window specified by Section C.2.2.6.8.
Subtype 7.5 Length 4 Value new reference

If this TLV is absent, the current Unsolicited Grant Time Reference is retained. The CMTS MAY include this TLV. The CM MUST observe this TLV.
8.3.20.1.7 CMTS MAC Address

When present, this TLV allows the current CMTS to send the MAC address of the destination CMTS corresponding to the target downstream frequency.
Type 8 Length 6 Value MAC Address of Destination CMTS

The CMTS MUST include this TLV if the CM is changing downstream channels and UCD substitution is specified or if the CM is changing downstream channels and using initialization technique 4. The CM SHOULD observe this TLV.
8.3.21 Dynamic Channel Change Response (DCC-RSP)

A Dynamic Channel Change Response MUST be transmitted by a CM in response to a received Dynamic Channel Change Request message to indicate that it has received and is complying with the DCC-REQ. The format of a DCC-RSP message MUST be as shown in Figure 8-39.

177

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Before it begins to switch to a new upstream or downstream channel, a CM MUST transmit a DCC-RSP on its existing upstream channel. When a CM receives a DCC-REQ message requesting that it switch to an upstream and downstream channel that it is already using or requesting that it switch to only an upstream or downstream channel that it is already using, the CM MUST respond with a DCC-RSP message on that channel indicating that it is already using the correct channel. A CM MAY ignore a DCC-REQ message while it is in the process of performing a channel change. After switching to a new channel, if the MAC was not re-initialized per DCC-REQ Initialization TLV, option 0, the CM MUST send a DCC-RSP message to the CMTS. A DCC-RSP MUST NOT be sent if the CM reinitializes its MAC. The full procedure for changing channels is described in Section 11.4.5.

Bit

16

24

31

MAC Management Message Header

Transaction ID

Confirmation Code

TLV Encoded Information

Figure 8-39

Dynamic Channel Change Response

Parameters MUST be as follows:

Transaction ID

A 16-bit Transaction ID from corresponding DCC-REQ An 8-bit Confirmation Code as described in Annex C.4.1

Confirmation Code

The following parameters are optional and are coded as TLV tuples.
CM Jump Time

Timing parameters describing when the CM will make the jump

Regardless of success or failure, if Privacy is enabled for the CM the DCC-RSP MUST contain:
Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest (refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Channel Change messages Attribute list. (Refer to Annex C.1.4.1)

178

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.21.1

Encodings

The type values used MUST be those shown below. These are unique within the Dynamic Channel Change Response message, but not across the entire MAC message set.
8.3.21.1.1 CM Jump Time

When present, this TLV allows the CM to indicate to the CMTS when the CM plans to perform its jump and be disconnected from the network. With this information, the CMTS MAY take preventative measures to minimize or to eliminate packet drops in the downstream due to the channel change.
Type 1 Length n Value

The time reference and units of time for these sub-TLVs is based upon the same 32-bit time base used in the SYNC message on the current downstream channel. This timestamp is incremented by a 10.24 MHz clock The CM SHOULD include this TLV. The CMTS SHOULD observe this TLV.
8.3.21.1.1.1 Length of Jump

This TLV indicates to the CMTS the length of the jump from the previous channel to the new channel. Specifically, it represents the length of time that the CM will not be able to receive data in the downstream.
Subtype 1 Length 4 Value length (based upon timestamp)

The CM MUST include this sub-TLV.

8.3.21.1.1.2 Start Time of Jump

When present, this TLV indicates to the CMTS the time in the future that the CM is planning on making the jump.
Subtype 2 Length 8 Value start time (based upon timestamp), accuracy of start time (based upon timestamp)

The 32-bit, 10.24 MHz time base rolls over approximately every 7 minutes. If the value of the start time is less than the current timestamp, the CMTS will assume one roll-over of the timestamp counter has elapsed. The accuracy of the start time is an absolute amount of time before and after the start time. The potential jump window is from (start time - accuracy) to (start time + accuracy + length). The CM SHOULD include this TLV.
8.3.22 Dynamic Channel Change Acknowledge (DCC-ACK)

A Dynamic Channel Change Acknowledge MUST be transmitted by a CMTS in response to a received Dynamic Channel Change Response message on the new channel with its Confirmation Code set to arrive(1). The format of a DCC-ACK message MUST be as shown in Figure 8-40.

179

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bit

16

24

31

MAC Management Message Header

Transaction ID

TLV Encoded Information

Figure 8-40 Dynamic Channel Change Acknowledge

Parameters MUST be as follows:

Transaction ID

A 16 bit Transaction ID from corresponding DCC-RSP.

If Privacy is enabled, the DCC-ACK message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMACDigest. (Refer to Annex C.1.4.3) HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). The HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Channel Change messages Attribute list. (Refer to Annex C.1.4.1)

180

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

8.3.23

Device Class Identification Request (DCI-REQ)

A CM MAY implement the DCI-REQ message. When implemented, a CM MUST transmit a DCI-REQ immediately following receipt of a ranging complete indication from the CMTS. A CM MUST NOT continue with initialization until a DCI-RSP message is received from the CMTS. Timeout and retry information is provided in Annex B. The DCI-REQ MUST be formatted as shown in Figure 8-41.

Bit 0 ~

16

24

31 ~

MAC Management Message Header ~ SID Device Class (con't) Device Class ~

TLV Encoded Information

Figure 8-41 Device Class Identification Request

Parameters MUST be as follows:

SID

The temporary SID assigned during Ranging

Device Class This is a 32-bit field where individual bits represent individual attributes of the CM. Bit #0 is the LSB of the field. Bits are set to 1 to select the attributes defined below.

bit #0 CPE Controlled Cable Modem (CCCM) bits #1-31 reserved and must be set to zero
8.3.24 Device Class Identification Response (DCI-RSP)

A DCI-RSP MUST be transmitted by a CMTS in response to a received DCI-REQ. The DCI-RSP MUST be formatted as shown in Figure 8-42.

181

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bit 0 ~

16

24

31 ~

MAC Management Message Header ~ SID Device Class (con't) Device Class Confirmation Code ~

TLV Encoded Information

Figure 8-42 Device Class Identification Response

Parameters MUST be as follows:

SID

The SID received in the associated DCI-REQ The device class field as received in the associated DCI-REQ Refer to Annex C.4.

Device Class

Confirmation Code

The CMTS MUST use only one of 3 confirmation codes in the DCI-RSP.

If the response is reject-temporary(3), the CM MUST reset its DCI-REQ retry counter to zero and MUST
resend the DCI-REQ and wait for the DCI-RSP before proceeding.

If the response is reject-permanent(4), the CM MUST abort this registration attempt and MUST begin rescanning for a different downstream channel. The CM MUST NOT retry this channel until it has tried all other DOCSIS downstream channels on the network.

If the response is success(0), the CM MUST continue with registration.

The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device class information as specified in [RFC-3256] and MUST insert this tuple in the DHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server.1
8.3.25 Upstream Transmitter Disable (UP-DIS) MAC Management Message

The UP-DIS message provides additional functionality to permanently or temporarily disable the modem, as well as to disable the modem for a specified period of time. It is used to control the admission of certain modem types and groups to the network as early as immediately before registration. It can also be used for network troubleshooting, disabling modems that violate network policies, or for avoiding request floods in a large network when the CMTS goes on-line.
1.

Added reference [RFC-3256] to this paragraph per ECN RFI2-N-03063 by GO on 07/03/03.

182

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

This message is stateless and can be issued by the CMTS at any time. The UP-DIS message is sent from a CMTS to a CM; there is no response from the CM transmitted back to the CMTS. UP-DIS messages may be unicast, in which case the destination address in the MAC header is the address of the selected CM, or multicast, in which case the destination address is a well-known MAC multicast address (see Annex A for details on well-known addresses). The CMTS MUST be capable of transmitting the UP-DIS message. The CMTS can transmit UP-DIS messages either as a result of a triggering event detected by the CMTS internally, or in response to a remote management command. Mechanisms for setting up, detecting, and reporting situations where the transmission of an UP-DIS message might be appropriate are implementation dependent. Similarly, signaling, which remotely instructs the CMTS to transmit a UP-DIS message, is outside the scope of this specification. One of the possible implementations may be SNMP commands sent to the CMTS over the network. CMs SHOULD support the UP-DIS message in order to ease network management. Since the UP-DIS mechanism at the CM is stateless and the CMs do not retain disabled status after a power cycle, the CMTS MAY incorporate mechanisms to track disabled CMs by their MAC addresses. The CMTS would resend an UP-DIS message as appropriate to the modems that were permanently disabled by the network operator, and then power cycled by the user in an attempt to re-register. However, the same function may also be implemented by the provisioning infrastructure on modem registration; therefore, if the CMTS is unable to track disabled modems autonomously, it SHOULD be able to send a UP-DIS in response to an external command. The UP-DIS message MUST be formatted as shown in Figure 8-43.

Bit

16

24

31

MAC Management Message Header

UP-DIS Timeout Interval (0=Off Forever, FFFFFFFF=On)

Figure 8-43

UP-DIS message format

The only parameter is UP-DIS TimeoutTST-REQ Interval, which MUST be encoded as follows. UP-DIS Timeout Interval is a 32-bit, unsigned integer representing the disable timeout interval in milliseconds. There are two special values defined: 00000000 permanently disables the upstream of the modem, as described below. FFFFFFFF remotely reinitializes the MAC, which resumes the normal operation of the modem. The CM MUST autonomously disable its upstream transmitter immediately upon receipt of an UP-DIS message with UP-DIS Timeout Interval = 0, regardless of any other transaction state (refer to Section 11), or the state of its control program. The modem stops all transmissions, but continues to listen to the MAC messages sent in the downstream. Once disabled, the CM upstream transmitter MUST only be re-enabled by power cycling the CM, or by an UP-DIS message with UP-DIS Timeout Interval = FFFFFFFF. All other UP-DIS messages MUST be ignored when the upstream is disabled.

183

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

If supported, the CM MUST autonomously reset its upstream transmitter upon receipt of an UP-DIS message with UP-DIS Timeout Interval = FFFFFFFF, regardless of any other transaction state (refer to Section 11), or the state of its control program. Resetting allows the modem to resume transmissions. Additional non-zero time out values in the UP-DIS message SHOULD be supported. If supported, the CM MUST autonomously disable its upstream transmitter immediately upon receipt of an UP-DIS message with UPDIS Timeout Interval T > 0 for a period of T milliseconds, regardless of any other transaction state (refer to Section 11), or the state of its control program. Although the time out T is specified in milliseconds, the CM MAY extend the specified time out by up to 100 msec. When time out expires, the CM SHOULD reinitialize the MAC as appropriate, starting with the initial ranging process and registration, because there is no guarantee that the CMTS has not de-registered it. In the disabled state, all other UP-DIS messages MUST be ignored, except for an UP-DIS message with UP-DIS Timeout Interval = FFFFFFFF or 00000000.
8.3.26 Initial Ranging Request (INIT-RNG-REQ)

A Ranging Request MUST be transmitted by a CM at initialization to determine network delay and request power adjustment. This message MUST use an FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header. This MUST be followed by a Packet PDU in the format shown in Figure 8-44. The INIT-RNG-REQ differs from the RNG-REQ in that it is only transmitted in Broadcast Initial Ranging Opportunities and MUST NOT be transmitted on a logical Upstream that is not a DOCSIS 2.0-only Upstream. It also has an upstream channel ID in place of the Pending Till Complete field in a RNG-REQ.
Bit 0 ~ ~ SID Downstream Channel ID 8 16 24 31 ~ ~

MAC Management Message Header

Upstream Upsrtream Channel ID Channel ID

Figure 8-44 Packet PDU Following the Timing Header

Parameters MUST be as follows:1

SID

Initialization SID if modem is attempting to join the network Initialization SID if modem has not yet registered and is changing upstream, downstream, or both
downstream and upstream channels, as directed by a downloaded parameter file

Primary SID (previously assigned in REG-RSP) if modem is registered and is changing upstream
channels, if the CM is redoing initial ranging as a result of a DCC, UCC, or UCD change (see Section 8.3.3 and Section 11.3.2), or if the CM is redoing initial ranging as a result of a temporary loss of downstream signal, while in S-CDMA mode (see Section 11.2.1).2 This is a 16-bit field of which the lower 14 bits define the SID with bits 14 and 15 defined to be 0.

1. 2.

Revised the bullet statements per ECN RFIv2.0-N-03.0118-1 by GO on 02/11/04. Revised this bullet statement per ECN RFI2-N-02227 by GO on 03/20/03.

184

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Downstream Channel ID The identifier of the downstream channel on which the CM received the UCD which described this upstream. This is an 8-bit field. Upstream Channel ID The Upstream Channel ID from the UCD the CM is using to transmit this INIT-RNGREQ. In the case where multiple logical upstreams are sharing the same spectrum, and the Broadcast Initial Ranging Opportunities of some of these logical channels are aligned, this allows the CMTS to know which logical channel the CM is using.

A CM MUST set the RSVD field of the MAC Management Message Header to report support of the S-CDMA Maximum Scheduled Codes if and only if the CMTS indicated that it supports the S-CDMA Maximum Scheduled Codes from TLV-17 of the UCD for the upstream channel on which the CM is ranging. In this case, the CM MUST report the maximum ratio of number of active codes to Maximum Scheduled Codes that the CM can support; this ratio is indicated by a bit mask in the reserved field as shown in Figure 8-x. For example, if the number of active codes on the channel is 128 and the CM supports a minimum of 64 scheduled codes (the minimum number of allowed active codes), the CM would report a ratio of 2. The CMTS will use this value in calculating an appropriate value for Maximum Scheduled Codes to assign to the CM. The CM SHOULD support a Maximum Ratio of 32. When the CM reports support for the SCDMA Maximum Scheduled Codes, the CM MUST also report its current transmit power shortfall (in dB). The CM power shortfall is the difference between the current target transmit power of the ranging request and the maximum SCDMA spreader-on transmit power of 53 dBmV. The CM MUST report a power shortfall of 0 if the current target transmit power of the ranging request is less than or equal to 53 dBmV. This value will be used by the CMTS for calculating appropriate values for S-CDMA Maximum Scheduled Codes and S-CDMA Power Headroom for the CM.1 The format of the RSVD field is:
Bit 7: 1= S-CDMA Maximum Scheduled Codes Supported Bits 6 to 5: CM Maximum Ratio of Bit 4 to 0: CM power shortfall (1/4 dB)

00 = 2 01 = 8 10 = 16 11 = 32

8.3.27

Test Request (TST-REQ)2

The Test Request is used to force a CM to enter or leave one of two test modes. The TST-REQ3 message with Mode!= 0 MUST NOT be sent by the CMTS except in response to an explicit command from the operator.

1.

Added this paragraph, the subsequent paragraph, and the matrix below per ECN RFIv2.0-N-04.0167-2 by GO on 10/18/04. Section 8.3.27 added per RFI2-N-02102 by RKV on 10/28/02. Change TEST to TST-REQ, per ECN RFI2-N-02210, by GO, on 11/21/02.

2. 3.

185

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bit

16

24

31

MAC Management Message Header

Mode TLV-Encoded Information for the Channel

Figure 8-45

Test Request

Parameters MUST be as follows:

Mode

0 = Disable all test modes and reboot 1 = Transmit a continuous (non-bursted) upstream signal at the commanded modulation rate, carrier frequency, and power level. The chip sequence at the spreader output is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1,...) at nominal amplitude, equal on I and Q. The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normal synchronous operation. 2 = Transmit a continuous (non-bursted), unmodulated (CW) upstream signal at the commanded carrier frequency, modulation rate and power level. This is equivalent to replacing the chip sequence at the spreader output with the constant sequence (1, 1, 1, 1, 1, 1,...) at nominal amplitude, equal on both I and Q. The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normal synchronous operation. This page intentionally left blank.

In normal operation, the CM MUST ignore any TST-REQ message it receives subsequent to receiving the first SYNC message. Note that this makes it less convenient to use this test mode with a CMTS, since the CMTS may send a SYNC message before the CM sees a TST-REQ message. After acquiring a downstream signal, and prior to receiving a SYNC message, if the CM receives a TST-REQ message (either unicast to the CM itself, or broadcast) with Mode != 0, the CM MUST begin the test mode indicated in the Mode parameter, using the channel parameters included in the TST-REQ message. In test mode, if the CM receives a TST-REQ message (either unicast to the CM itself, or broadcast) with Mode = 0, the CM MUST reboot. The CM MUST reboot after the expiration of the T16 timer, a 30 minute test mode timer. The TST-REQ message MUST be generated in the format shown in Figure 8-45, including all of the parameters coded as TLV multiples defined in Table 8-22.
Table 8-22 Channel TLV Parameters
Name Type (1 byte) Length (1 byte) Value (variable length)

Modulation Rate

Multiples of base rate of 160 kHzc. (Value is 1, 2, 4, 8, 16, or 32.). This TLV MUST be present if the test mode is 1.

186

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table 8-22
Frequency 2

Channel TLV Parameters (Continued)

4 Upstream carrier frequency (Hz). This TLV MUST be present if the test mode is 1 or 2.

Power

This TLV specifies the power (unsigned 8-bit, dBmV units) at which the CM MUST transmit the TST-REQ message. This TLV MUST be present if the test mode is 1 or 2.

S-CDMA US ratio numerator M

The numerator (M) of the M/N ratio relating the downstream symbol clock to the upstream modulation clock. This TLV MUST be present if the test mode is 1. This TLV MUST be present if the test mode is 2 and the operation is synchronous.

S-CDMA US ratio denominator N

The denominator (N) of the M/N ratio relating the downstream symbol clock to the upstream modulation clock. This TLV MUST be present if the test mode is 1. This TLV MUST be present if the test mode is 2 and the operation is synchronous.

187

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

188

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

9 Media Access Control Protocol Operation

9.1 Upstream Bandwidth Allocation

The upstream channel is modeled as a stream of mini-slots. The CMTS MUST generate the time reference for identifying these slots. It MUST also control access to these slots by the cable modems. For example, it MAY grant some number of contiguous slots to a CM for it to transmit a data PDU. The CM MUST time its transmission so that the CMTS receives it in the time reference specified. This section describes the elements of protocol used in requesting, granting, and using upstream bandwidth. The basic mechanism for assigning bandwidth management is the allocation MAP. Please refer to Figure 9-1. The allocation MAP is a MAC Management message transmitted by the CMTS on the downstream channel which describes, for some interval, the uses to which the upstream mini-slots MUST be put. A given MAP MAY describe some slots as grants for particular stations to transmit data in, other slots as available for contention transmission, and other slots as an opportunity for new stations to join the link. Many different scheduling algorithms MAY be implemented in the CMTS by different vendors; this specification does not mandate a particular algorithm. Instead, it describes the protocol elements by which bandwidth is requested and granted.

Map PDU

transmitted on downstream channel by the CMTS

permitted use of the upstream channel

mini-slots

CM tx opportunity request contention area CM tx opportunity

maintenance as-yet unmapped time

previous map

current map

Figure 9-1

Allocation Map

The bandwidth allocation includes the following basic elements:

Each CM has one or more short (14-bit) service identifiers (SIDs) as well as a 48-bit address. Upstream bandwidth is divided into a stream of mini-slots. Each mini-slot is numbered relative to a master
reference maintained by the CMTS. The master reference is distributed to the CMs by means of SYNC and UCD packets (See Section 6.2.11.2, Mini-slot Numbering, on page 54).

CMs may issue requests to the CMTS for upstream bandwidth.

189

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CMTS MUST transmit allocation MAP PDUs on the downstream channel defining the allowed usage of each mini-slot. The MAP is described below.
9.1.1 The Allocation MAP MAC Management Message

The allocation MAP is a varying-length MAC Management message that is transmitted by the CMTS to define transmission opportunities on the upstream channel. It includes a fixed-length header followed by a variable number of information elements (IEs) in the format shown in Section 8.3.4. Each information element defines the allowed usage for a range of mini-slots.
Note: For TDMA channels, it should be understood by both CM and CMTS that the lower (26-M) bits of alloc start and ack times MUST be used as the effective MAP start and ack times, where M is defined in Section 8.3.4. The relationship between alloc start/ack time counters and the timestamp counter is further described in Section 9.3.4. For DOCSIS 2.0 S-CDMA channels the alloc start/ack time counters are defined in mini-slots which are related to the timestamp counter, frame counter, and SCDMA timestamp snapshot as described in Section 6.2.11.2, Mini-slot Numbering, on page 54.

9.1.2 Information Elements

Each IE consists of a 14-bit Service ID, a 4-bit type code, and a 14-bit starting offset as defined in Section 8.3.4. Since all stations MUST scan all IEs, it is critical that IEs be short and relatively fixed format. IEs within the MAP are strictly ordered by starting offset. For most purposes, the duration described by the IE is inferred by the difference between the IEs starting offset and that of the following IE. For this reason, a Null IE MUST terminate the list. Refer to Table 8-20. Four types of Service IDs are defined: 1. 0x3FFF - broadcast, intended for all stations 2. 0x2000-0x3FFE - multicast, purpose is defined administratively. Refer to Annex A. 3. 0x0001-0x1FFF - unicast, intended for a particular CM or a particular service within that CM 4. 0x0000 - null address, addressed to no station All of the Information Elements defined below MUST be supported by conformant CMs. Conformant CMTSes MAY use any of these Information Elements when creating Bandwidth Allocation Maps.
9.1.2.1 The Request IE

The Request IE provides an upstream interval in which requests MAY be made for bandwidth for upstream data transmission. The character of this IE changes depending on the class of Service ID. If broadcast, this is an invitation for CMs to contend for requests. Section 9.4 describes which contention transmit opportunity may be used. If unicast, this is an invitation for a particular CM to request bandwidth. Unicasts MAY be used as part of a Quality of Service scheduling scheme (refer to Section 10.2, Upstream Service Flow Scheduling Services, on page 219). Packets transmitted in this interval MUST use the Request MAC Frame format (refer to Section 8.2.5.3). A small number of Priority Request SIDs are defined in Annex A.2.3. These allow contention for Request IEs to be limited to service flows of a given Traffic Priority. (Refer to Annex C.2.2.5.1)

190

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

9.1.2.2

The Request/Data IE

The Request/Data IE provides an upstream interval in which requests for bandwidth or short data packets MAY be transmitted. This IE is distinguished from the Request IE in that:

It provides a means by which allocation algorithms MAY provide for immediate data contention under
light loads, and a means by which this opportunity can be withdrawn as network loading increases.

Multicast Service IDs MUST be used to specify maximum data length, as well as allowed random starting
points within the interval. For example, a particular multicast ID may specify a maximum of 64-byte data packets, with transmit opportunities every fourth slot. A small number of well-known multicast Service IDs are defined in Annex A. Others are available for vendorspecific algorithms. Since data packets transmitted within this interval may collide, the CMTS MUST acknowledge any that are successfully received. The data packet MUST indicate in the MAC Header that a data acknowledgment is desired (see Table 8-13).
9.1.2.3 The Initial Maintenance IE

The Initial Maintenance IE, when used with the Broadcast SID, provides an interval in which new stations may join the network. A long interval, equivalent to the maximum round-trip propagation delay plus the transmission time of a Ranging Request (RNG-REQ) message (see Section 9.3.3), MUST be provided to allow new stations to perform initial ranging. Packets transmitted in this interval MUST use the RNG-REQ or the INIT-RNG-REQ MAC Management message format (refer to Section 8.3.5, Ranging Request (RNG-REQ), on page 147, and Section 8.3.26, Initial Ranging Request (INIT-RNG-REQ), on page 184). On DOCSIS 2.0 Only Upstream Channels, the Initial Maintenance IE MAY be used with a unicast SID. This is done to provide Unicast Initial Maintenance opportunities in place of Station Maintenance opportunities at the discretion of the CMTS. This may be useful if the first unicast ranging opportunity on an S-CDMA channel needs to have Spreader Off just like initial maintenance, but it is not desirable to impose the overhead of having the Spreader Off on routine Station Maintenance. Unicast Initial Maintenance Opportunities only need to be large enough to allow transmission of the ranging request. The CMTS MUST NOT provide unicast Initial Maintenance opportunities on any logical upstream which is not a DOCSIS 2.0 Only Upstream.
9.1.2.4 The Station Maintenance IE

The Station Maintenance IE provides an interval in which stations are expected to perform some aspect of routine network maintenance, such as ranging or power adjustment. The CMTS MAY request that a particular CM perform some task related to network maintenance, such as periodic transmit power adjustment. In this case, the Station Maintenance IE is unicast to provide upstream bandwidth in which to perform this task. Packets transmitted in this interval MUST use the RNG-REQ MAC Management message format (see Section 8.3.5).
9.1.2.5 Short and Long Data Grant IEs

The Short and Long Data Grant IEs provide an opportunity for a CM to transmit one or more upstream PDUs. These IEs are issued either in response to a request from a station, or because of an administrative policy providing some amount of bandwidth to a particular station (see class-of-service discussion below). These IEs MAY also be used with an inferred length of zero mini slots (a zero length grant), to indicate that a request has been received and is pending (a Data Grant Pending).

191

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Short Data Grants are used with intervals less than or equal to the maximum burst size for this usage specified in the Upstream Channel Descriptor. If Short Data burst profiles are defined in the UCD, then all Long Data Grants MUST be for a larger number of mini-slots than the maximum for Short Data. The distinction between Long and Short Data Grants may be exploited in physical-layer forward-error-correction coding; otherwise, it is not meaningful to the bandwidth allocation process. If this IE is a Data Grant Pending (a zero length grant), it MUST follow the NULL IE. This allows cable modems to process all actual allocations first, before scanning the Map for data grants pending and data acknowledgments.
9.1.2.6 Data Acknowledge IE

The Data Acknowledge IE acknowledges that a data PDU was received. The CM MUST have requested this acknowledgment within the data PDU (normally this would be done for PDUs transmitted within a contention interval in order to detect collisions). This IE MUST follow the NULL IE. This allows cable modems to process all actual interval allocations first, before scanning the Map for data grants pending and data acknowledgments.
9.1.2.7 Expansion IE

The Expansion IE provides for extensibility, if more than 16 code points or 32 bits are needed for future IEs.
9.1.2.8 Null IE

A Null IE terminates all actual allocations in the IE list. It is used to infer a length for the last interval. All Data Acknowledge IEs and All Data Grant Pending IEs (Data Grants with an inferred length of 0) must follow the Null IE.
9.1.2.9 Advanced PHY Short and Long Data Grant IEs

These IEs are the Advanced PHY channel equivalent of the Short and Long Data Grant IEs in Section 9.1.2.5. In addition, these IEs allow DOCSIS 2.0 modems operating in DOCSIS 2.0 TDMA mode to share the same upstream channel with DOCSIS 1.x modems. Modems registered in DOCSIS 1.x mode MUST NOT use these intervals. For upstream channels supporting a mixture of DOCSIS 1.x and DOCSIS 2.0 TDMA CMs, the CMTS MUST use the SID in the request and the operational state of the CM to distinguish between requests for IUC 5 & 6 data grants and requests for IUC 9 & 10 data grants. (Refer to Section 11.2.9 for additional information). Once this distinction has been made, the CMTS then uses the request size to distinguish between a long grant and a short grant. Once a CMTS has received a REG_ACK from a 2.0 CM on a type 2 channel, the CMTS MUST NOT send data grants using IUCs 5 or 6 if either IUC 9 or 10 is defined for that upstream channel. This restriction allows the CM to support only 7 burst profiles simultaneously.
9.1.2.10 Advanced PHY Unsolicited Grant IE

This IE can be used by the CMTS to make unsolicited grants of bandwidth to DOCSIS 2.0 CMs. If a significant portion of the traffic for an upstream is going to consist of unsolicited grants of a particular size, this IE provides a way for the CMTS to provide a set of physical layer parameters (such as code word length and FEC length) well tailored to that traffic, without compromising the general usefulness of the Advanced PHY Short or
192

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Advanced PHY Long Data Grant IEs. It is never used by the CM to calculate the size of a bandwidth request. The CMTS MUST NOT use it to make grants to DOCSIS 1.x CMs.
9.1.3 Requests

Requests refer to the mechanism that CMs use to indicate to the CMTS that it needs upstream bandwidth allocation. A Request MAY come as a stand-alone Request Frame transmission (refer to Section 8.2.5.3) or it MAY come as a piggyback request in the EHDR of another Frame transmission (refer to Section 8.2.6). The Request Frame MAY be transmitted during any of the following intervals:

Request IE Request/Data IE Short Data Grant IE Long Data Grant IE Adv PHY Short Data Grant IE Adv PHY Long Data Grant IE Adv PHY Unsolicited Grant IE

A piggyback request MAY be contained in the following Extended Headers:

Request EH element Upstream Privacy EH element Upstream Privacy EH element with Fragmentation
The request MUST include:

The Service ID making the request The number of mini-slots requested

The CM MUST request the number of mini-slots needed to transmit an entire frame, or a fragment containing the entire remaining portion of a frame that a previous grant has caused to be fragmented. The frame may be a single MAC frame, or a MAC frame that has been formed by the concatenation of multiple MAC frames (see Section 8.2.5.5). The request from the CM MUST be large enough to accommodate the entire necessary physical layer overhead (see Section 6.2) for transmitting the MAC frame or fragment. The CM MUST NOT make a request that would violate the limits on data grant sizes in the UCD message (see Section 8.3.3) or any limits established by QOS parameters associated with the Service Flow.1 The CM MUST NOT request more mini-slots than are necessary to transmit the MAC frame. This means that if the CM is using Short and Long Data IUCs to transmit data and the frame can fit into a Short Data Grant, the CM MUST use the Short Data Grant IUC attributes to calculate the amount of bandwidth to request and MUST make a request less than or equal to the Short Data maximum Burst size. If the CM is using Advanced PHY Short and Long Data IUCs to transmit data and the frame can fit into an Advanced PHY Short Data Grant, the CM MUST use the Advanced PHY Short Data Grant IUC attributes to calculate the amount of bandwidth to request and MUST make a request less than or equal to the Advanced PHY Short Data maximum Burst size.

1.

This paragraph updated per RFI2-N-02090, superseding RFI2-N-02085 and RFI2-N-02111. This paragraph separated from the paragraph after it by RKV, all on 10/29/02.

193

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM MUST have only one request outstanding at a time per Service ID. If the CMTS does not immediately respond with a Data Grant, the CM is able to unambiguously determine that its request is still pending because the CMTS MUST continue to issue a Data Grant Pending in every MAP that has an ACK Time indicating the request has already been processed until the request is granted or discarded. In MAPs, the CMTS MUST NOT make a data grant greater than 255 mini-slots to any assigned Service ID. This puts an upper bound on the grant size the CM has to support.
9.1.4 Information Element Feature Usage Summary

The following table summarizes what types of frames the CM can transmit using each of the MAP IE types that represent transmit opportunities. A MUST entry in the table means that, if appropriate, a compliant CM implementation has to be able to transmit that type of frame in that type of opportunity. A MAY entry means that compliant CM implementation does not have to be able to transmit that type of frame in that type of opportunity but that it is legal for it to do so, if appropriate. A MUST NOT entry means that a compliant CM will never transmit that type of frame in that type of opportunity.
Table 9-1 IE Feature Compatibility Summary
Transmit Concatenated MAC Frame Transmit Fragmented MAC Frame Transmit Any other MAC Frame

Information Element

Transmit Request Frame

Transmit RNGREQ

Request IE Request/Data IE Initial Maintenance IE Station Maintenance IE Short Data Grant IE Long Data Grant IE Adv PHY Short Data Grant IE Adv PHY Long Data Grant IE Adv PHY Unsolicited Grant IE

MUST MUST MUST NOT MUST NOT MAY MAY MAY MAY MAY

MUST NOT MAY MUST NOT MUST NOT MUST MUST MUST MUST MUST

MUST NOT MUST NOT MUST NOT MUST NOT MUST MUST MUST MUST MUST

MUST NOT MUST NOT MUST MUST MUST NOT MUST NOT MUST NOT MUST NOT MUST NOT

MUST NOT MAY MUST NOT MUST NOT MUST MUST MUST MUST MUST

9.1.5 Map Transmission and Timing

The allocation MAP MUST be transmitted in time to propagate across the physical cable and be received and handled by the receiving CMs. As such, it MAY be transmitted considerably earlier than its effective time. The components of the delay are:

Worst-case round-trip propagation delay may be network-specific, but on the order of hundreds of microseconds

Queuing delays within the CMTS implementation-specific Processing delays within the CMs MUST allow a minimum processing time by each CM as specified in
Annex B (CM MAP Processing Time), which has to include any upstream delays caused by the DOCSIS 2.0 TDMA

Downstream delays caused by the PMD-layer framer and the FEC interleaver
Within these constraints, vendors may wish to minimize this delay so as to minimize latency of access to the upstream channel.

194

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The number of mini-slots described MAY vary from MAP to MAP. At minimum, a MAP MAY describe a single mini-slot. This would be wasteful in both downstream bandwidth and in processing time within the CMs. At maximum, a MAP MAY stretch to tens of milliseconds. Such a MAP would provide poor upstream latency. Allocation algorithms MAY vary the size of the maps over time to provide a balance of network utilization and latency under varying traffic loads. At minimum, a MAP MUST contain two Information Elements: one to describe an interval and a null IE to terminate the list. At a maximum, a MAP MUST be bounded by a limit of 240 information elements. Maps are also bounded in that they MUST NOT describe more than 4096 mini-slots into the future. The latter limit is intended to bound the number of future mini-slots that each CM is required to track. A CM MUST be able to support multiple outstanding MAPs. Even though multiple MAPs may be outstanding, the sum of the number of mini-slots they describe MUST NOT exceed 4096. The set of all MAPs, taken together, MUST describe every mini-slot in the upstream channel. If a CM fails to receive a MAP describing a particular interval, it MUST NOT transmit during that interval.
9.1.6 Protocol Example

This section illustrates the interchange between the CM and the CMTS when the CM has data to transmit (Figure 9-2). Suppose a given CM has a data PDU available for transmission.

slots mapped by first Map PDU

second map

CMTS

t1
Map PDU

t3

t5 t6
Request

t7
Map PDU

t9

t 11
data PDU

CM

t2

t4
Figure 9-2

t8
Protocol Example

t 10

Description steps: 1. At time t1, the CMTS transmits a MAP whose effective starting time is t3. Within this MAP is a Request IE which will start at t5. The difference between t1 and t3 is needed to allow for all the delays discussed in Section 9.1.5. 2. At t2, the CM receives this MAP and scans it for request opportunities. In order to minimize request collisions, it calculates t6 as a random offset based on the Data Backoff Start value in the most recent Map (see Section 9.4, also the multicast SID definitions in Annex A.2). 3. At t4, the CM transmits a request for as many mini-slots as needed to accommodate the PDU. Time t4 is chosen based on the ranging offset (see Section 9.3.3) so that the request will arrive at the CMTS at t6. 4. At t6, the CMTS receives the request and schedules it for service in the next MAP. (The choice of which requests to grant will vary with the class of service requested, any competing requests, and the algorithm used by the CMTS.) 5. At t7, the CMTS transmits a MAP whose effective starting time is t9. Within this MAP, a data grant for the CM will start at t11.

195

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

6. At t8, the CM receives the MAP and scans for its data grant. 7. At t10, the CM transmits its data PDU so that it will arrive at the CMTS at t11. Time t10 is calculated from the ranging offset as in step 3. Steps 1 and 2 need not contribute to access latency if CMs routinely maintain a list of request opportunities. At Step 3, the request may collide with requests from other CMs and be lost. The CMTS does not directly detect the collision. The CM determines that a collision (or other reception failure) occurred when the next MAP with an ACK time indicating that the request would have been received and processed fails to include an acknowledgment of the request. The CM MUST then perform a back-off algorithm and retry. (Refer to Section 9.4.1) At Step 4, the CMTS scheduler MAY fail to accommodate the request within the next MAP. If so, it MUST reply with a zero-length grant in that MAP or discard the request by giving no grant at all. It MUST continue to report this zero-length grant in all succeeding maps until the request can be granted or is discarded. This MUST signal to the CM that the request is still pending. So long as the CM is receiving a zero-length grant, it MUST NOT issue new requests for that service queue.
9.1.7 MAP Generation Example - Two Logical Upstreams

This section illustrates the timing requirements for scheduling an S-CDMA and a TDMA logical channel on the same physical channel. For simplicity it is assumed that:

The duration of the S-CDMA frames is an integral multiple of the duration of the TDMA Mini-slots. Both TDMA and S-CDMA maps begin and end on frame boundaries. For the duration of the example there are no S-CDMA bursts with the Spreader Off, and there are no
Broadcast Initial Ranging regions where both channels are active.

S-CDMA logical channel

Null SID

Null SID

T3
Null SID

T7
Null SID

Minislot count null grant TDMA grant Frame bounderies S-CDMA frame
Null SID

CM TDMA logical channel TDMA Mini-slots

T4

T8

T1

T2

T5 T6

Figure 9-3

Logical S-CDMA TDMA channels

Description: 1. The example begins at T1 and the first MAP discussed takes effect at T3. 2. At time T1, the CMTS transmits a S-CDMA map whose effective starting time is T3 and end time is T7. 3. At time T2, the CMTS transmits a TDMA map whose effective starting time is T4 and end time is T8.

196

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

4. At time T3 the S-CDMA map has three frames of S-CDMA grants. The CMTS upstream scheduler must not allow TDMA transmissions to occur at the same time. To prevent the two channels from interfering with each other the scheduler will mute the TDMA upstream (by granting mini-slots to the NULL SID for the TDMA channel) during the time S-CMDA is active. 5. At time T4, on a frame boundary, the TDMA channel becomes active. In this example it has one empty minislot (NULL SID) to guarantee sufficient guard time for the following TDMA burst. Then it proceeds with usable TDMA grants. At the same time the S-CDMA upstream is muted by granting mini-slots to the NULL SID in every frame. 6. At T5 and T6 the TDMA logical channel and S-CDMA logical channel transmit the next map for the upstream. Note that the figure above does not continue to detail the complete maps beginning at T7 and T8. 7. At time T7 the S-CDMA map sends a group of S-CDMA grants in a frame.
Note:

When switching from TDMA to S-CDMA there is no requirement for additional guard time.

9.2

Support for Multiple Channels

Vendors may choose to offer various combinations of upstream and downstream channels within one MAC service access point. The upstream bandwidth allocation protocol allows for multiple upstream channels to be managed via one or many downstream channels. Some or all of these multiple upstream channels may even coexist on the same upstream transmit center frequency. If multiple upstream channels are associated with a single downstream channel, then the CMTS MUST send one allocation MAP per upstream channel. The MAPs channel identifier, taken with the Upstream Channel Descriptor Message (see Section 8.3.3), MUST specify to which channel each MAP applies. There is no requirement that the maps be synchronized across channels. Appendix III provides an example. If multiple logical upstream channels are associated with the same upstream center frequency on the same cable segment, then the CMTS MUST ensure that the MAP allocations to each logical upstream channel sharing the same spectrum do not coincide with the potential transmit opportunities of the other logical upstream channels with the possible exception of Broadcast Initial Ranging opportunities. When sharing the upstream between SCDMA and TDMA channels, the CMTS MUST take into account the lack of guard time on the synchronous physical layer upstreams. Annex G provides more information on the co-existence of DOCSIS 1.x and DOCSIS 2.0 channels. If multiple downstream channels are associated with a single upstream channel, the CMTS MUST ensure that the allocation MAP reaches all CMs. That is, if some CMs are attached to a particular downstream channel, then the MAP MUST be transmitted on that channel. This may necessitate that multiple copies of the same MAP be transmitted. The Alloc Start Time in the MAP header MUST always relate to the timebase reference on the downstream channel on which it is transmitted. If multiple downstream channels are associated with multiple upstream channels, the CMTS may need to transmit multiple copies of multiple maps to ensure both that all upstream channels are mapped and that all CMs have received their needed maps.

9.3

Timing and Synchronization

One of the major challenges in designing a MAC protocol for a cable network is compensating for the large delays involved. These delays are an order of magnitude larger than the transmission burst time in the upstream. To compensate for these delays, the cable modem MUST be able to time its transmissions precisely to arrive at the CMTS at the start of the assigned mini-slot.

197

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

To accomplish this, two pieces of information are needed by each cable modem:

a global timing reference sent downstream from the CMTS to all cable modems. a timing offset, calculated during a ranging process, for each cable modem.
9.3.1 Global Timing Reference

For TDMA channels, the CMTS MUST create a global timing reference by transmitting the Time Synchronization (SYNC) MAC management message downstream at a nominal frequency. The message contains a timestamp that exactly identifies when the CMTS transmitted the message. Cable modems MUST then compare the actual time the message was received with the timestamp and adjust their local clock references accordingly. For S-CDMA channels, the CMTS also creates a global timing reference by transmitting the Time Synchronization (SYNC) and Upstream Channel Descriptor (UCD) MAC messages downstream at a nominal frequency. See Section 6.2.11.2. The Transmission Convergence sublayer must operate closely with the MAC sublayer to provide an accurate timestamp for the SYNC message. As mentioned in the Ranging section below (Section 9.3.3), the model assumes that the timing delays through the remainder of the PHY layer MUST be relatively constant with the exception of the timing offsets specified in Section 6.2.19.4 related to modulation rate changes to accommodate a legacy DOCSIS upstream receiver implementation. For TDMA, any variation in the PHY delays MUST be accounted for in the guard time of the PHY overhead.1 It is intended that the nominal interval between SYNC messages be tens of milliseconds and the nominal interval between UCD messages be no more than 2 seconds. This imposes very little downstream overhead while letting cable modems acquire their global timing synchronization quickly.
9.3.2 CM Channel Acquisition

Any cable modem MUST NOT use the upstream channel until it has successfully synchronized to the downstream. First, the cable modem MUST establish PMD sublayer synchronization. This implies that it has locked onto the correct frequency, equalized the downstream channel, recovered any PMD sublayer framing and the FEC is operational (refer to Section 11.2.2). At this point, a valid bit stream is being sent to the transmission convergence sublayer. The transmission convergence sublayer performs its own synchronization (see Section 7). On detecting the well-known DOCSIS PID, along with a payload unit start indicator per [ITU-T H.222.0], it delivers the MAC frame to the MAC sublayer. The MAC sublayer MUST now search for the Timing Synchronization (SYNC) MAC management messages. For TDMA channels, the cable modem achieves MAC synchronization once it has received at least two SYNC messages and has verified that its clock tolerances are within specified limits. For S-CDMA channels, the cable modem achieves MAC synchronization once it has received at least two SYNC messages, received one UCD message, and has locked to the downstream symbol clock and verified that its clock tolerances are within specified limits A cable modem remains in SYNC as long as it continues to successfully receive the SYNC messages. If the Lost SYNC Interval (refer to Annex B) has elapsed without a valid SYNC message, a cable modem MUST NOT use the upstream and MUST try to re-establish synchronization again.
1.

Section 9.3.1, third paragraph, last two sentences updated per RFI2-N-02178 by RKV on 10/30/03.

198

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

9.3.3 Ranging

Ranging is the process of acquiring the correct timing offset such that the cable modems transmissions are aligned to the correct mini-slot boundary. The timing delays through the PHY layer MUST be relatively constant with the exception of the timing offsets specified in Section 6.2.19.4 related to modulation rate changes to accommodate a legacy DOCSIS upstream receiver implementation. For TDMA, any variation in the PHY delays MUST be accounted for in the guard time of the upstream PMD overhead.1
9.3.3.1 Broadcast Initial Ranging

First, a cable modem MUST synchronize to the downstream and learn the upstream channel characteristics through the Upstream Channel Descriptor MAC management message. At this point, the cable modem MUST scan the Bandwidth Allocation MAP message to find a Broadcast Initial Maintenance Region. Refer to Section 9.1.2.4. The CMTS MUST make a Broadcast Initial Maintenance region large enough to account for the variation in delays between any two CMs. On S-CDMA channels, the CMTS MUST schedule Broadcast Initial Maintenance transmit opportunities such that they align with S-CDMA frames and span an integral number of SCDMA frames. Refer to Section 6.2.11.5, Spreader-off Bursts for Maintenance on S-CDMA channel, on page 59. The cable modem MUST put together either an Initial Ranging Request message or a Ranging Request message to be sent in a Broadcast Initial Maintenance region. An INIT-RNG-REQ MUST be transmitted if the upstream is a DOCSIS 2.0 Only Upstream, which can be determined from the UCD. Otherwise a RNG-REQ MUST be transmitted. The SID field MUST be set to the non-initialized CM value (zero), unless this initial ranging is a result of a UCD ranging required TLV or a DCC or UCC request in which the CM has been instructed to retain its existing SIDs. The CM MUST set its initial timing offset to the amount of internal fixed delay equivalent to putting this CM next to the CMTS. This amount includes delays introduced through a particular implementation, and MUST include the downstream PHY interleaving latency.When the Broadcast Initial Maintenance transmit opportunity occurs, the cable modem MUST send the INIT-RNG-REQ or RNG-REQ message. Thus, the cable modem sends the message as if it was physically right at the CMTS. Once the CMTS has successfully received the RNG-REQ OR INIT-RNG-REQ message, it MUST return a Ranging Response message addressed to the individual cable modem. Within the Ranging Response message MUST be a temporary SID assigned to this cable modem (unless the CM has retained a previous Primary SID during a UCC, DCC, or UCD change) until it has completed the registration process. The message MUST also contain information on RF power level adjustment and offset frequency adjustment as well as any timing offset corrections. Ranging adjusts each CMs timing offset such that it appears to be located right next to the CMTS.
9.3.3.2 Unicast Initial Ranging

The cable modem MUST now wait for an individual Station Maintenance or Unicast Initial Maintenance region assigned to its temporary SID (or previous primary SID if ranging as a result of a UCC, DCC, or UCD change). It MUST now transmit a ranging Request message at this time using the temporary SID (or previous primary SID) along with any power level and timing offset corrections. The CMTS MUST return another Ranging Response message to the cable modem with any additional fine tuning required. The ranging request/response steps MUST be repeated until the response contains a Ranging Successful notification or the CMTS aborts ranging. Once successfully ranged, the cable modem MUST join normal data traffic in the upstream. See Section 11 for complete details on the entire initialization sequence. In
1.

Section 9.3.3 updated per RFI2-N-02178 by RKV on 10/30/02.

199

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

particular, state machines and the applicability of retry counts and timer values for the ranging process are defined in Section 11.2.4.
Note: The burst type to use for any transmission is defined by the Interval Usage Code (IUC). Each IUC is mapped to a burst type in the UCD message.

9.3.4 Timing Units and Relationships

The SYNC message conveys a time reference with a resolution of 6.25/64 microseconds (10.24 MHz) to allow the CM to track the CMTS clock with a small phase offset. Since this timing reference is decoupled from particular upstream channel characteristics, a single SYNC time reference may be used for all upstream channels associated with the downstream channel. The bandwidth allocation MAP uses time units of mini-slots. A mini-slot represents the time needed for transmission of a fixed number of symbols. For some modulations (ex QPSK) an integer number of bytes can be transmitted in a mini-slot. For these channels, the mini-slot is expected to represent 16 byte-times, although other values could be chosen. A mini-slot is the unit of granularity for upstream transmission opportunities; there is no implication that any PDU can actually be transmitted in a single mini-slot.
9.3.4.1 TDMA Timing Units and Relationships 9.3.4.1.1 Mini-Slot Capacity

On TDMA channels, the size of the mini-slot, expressed as a multiple of the SYNC time reference, is carried in the Upstream Channel Descriptor. The example in Table 9-2 relates mini-slots to the SYNC time ticks (assuming QPSK modulation):
Table 9-2
Parameter

Example Relating Mini-Slots to Time Ticks

Example Value

Time tick Bytes per mini-slot Symbols/byte Symbols/second Mini-slots/second Microseconds/mini-slot Ticks/mini-slot

6.25 microseconds 16 (nominal, when using QPSK modulation) 4 (assuming QPSK) 2,560,000 40,000 25 4

Note that the symbols/byte is a characteristic of an individual burst transmission, not of the channel. A mini-slot in this instance could represent a minimum of 16 or a maximum of 48 bytes, depending on the modulation choice. In a channel allocated exclusively to DOCSIS 2.0 TDMA modems, the Mini-slot Size field of the UCD MAY take on the value 0, in which case the Mini-slot size is 1 Timebase Tick. If a channel is to be accessible to both DOCSIS 1.x and 2.0 TDMA Cable Modems, the UCD MUST follow the DOCSIS 1.x requirements for timing units and relationships.

200

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

9.3.4.1.2

Mini-Slot Numbering

The MAP counts mini-slots in a 32-bit counter that normally counts to (232 - 1) and then wraps back to zero. The least-significant bits (i.e., bit 0 to bit 25-M) of the mini-slot counter MUST match the most-significant bits (i.e., bit 6+M to bit 31) of the SYNC timestamp counter. That is, mini-slot N begins at timestamp reference (N*T*64), where T = 2M is the UCD multiplier that defines the mini-slot (i.e., the number of timeticks per minislot). Note: The unused upper bits of the 32-bit mini-slot counter (i.e., bit 26-M to bit 31) are not needed by the CM and MAY be ignored.
Note: The constraint that the UCD multiplier be a power of two has the consequence that the number of bytes per mini-slot must also be a power of two.

9.3.4.2 9.3.4.2.1

S-CDMA Timing Units and Relationships Mini-Slot Capacity

On S-CDMA channels, the size of the mini-slot is dependent on the modulation rate, the codes per mini-slot, and the spreading intervals per frame, which are all carried in the Upstream Channel Descriptor. The timing units and relationships for S-CDMA are covered in detail in Section 6.2.11, S-CDMA Framer and Interleaver, on page 54. An example of the timing relationships (assuming 64QAM modulation) is shown in Table 9-3:
Table 9-3 Example of Mini-Slot Capacity in S-CDMA mode
Example Value

Parameter

Spreading intervals per frame Active code length Codes per mini-slot Mini-slots per frame Symbols per mini-slot Bytes per mini-slot Bits/symbol Symbols/second Mini-slots/second Microseconds/mini-slot

10 128 4 32 40 30 (nominal, when using 64QAM modulation) 6 (assuming 64QAM) 5,120,000 128,000 7.8125

9.3.4.2.2

Mini-Slot Numbering

Mini-slot numbering in S-CDMA mode is described in detail in Section 6.2.11.2, Mini-slot Numbering, on page 54.

9.4

Upstream Transmission and Contention Resolution

The CMTS controls assignments on the upstream channel through the MAP and determines which mini-slots are subject to collisions. The CMTS MAY allow collisions on either Requests or Data PDUs. This section provides an overview of upstream transmission and contention resolution. For simplicity, it refers to the decisions a CM makes, however, this is just a pedagogical tool. Since a CM can have multiple upstream Service Flows (each with its own SID) it makes these decisions on a per service queue or per SID basis. Refer to Appendix IV for a state transition diagram and more detail.

201

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

9.4.1 Contention Resolution Overview

The mandatory method of contention resolution which MUST be supported is based on a truncated binary exponential back-off, with the initial back-off window and the maximum back-off window controlled by the CMTS. The values are specified as part of the Bandwidth Allocation Map (MAP) MAC message and represent a power-of-two value. For example, a value of 4 indicates a window between 0 and 15; a value of 10 indicates a window between 0 and 1023. Every time a CM wants to transmit in a contention region, it MUST enter the contention resolution process by setting its internal backoff window equal to the Data Backoff Start defined in the MAP1 currently in effect.2 The CM MUST randomly select a number within its back-off window. This random value indicates the number of contention transmit opportunities which the CM MUST defer before transmitting. A CM MUST only consider contention transmit opportunities for which this transmission would have been eligible. These are defined by either Request IEs or Request/Data IEs in the MAP.
Note:

Each IE can represent multiple transmission opportunities.

As an example, consider a CM whose initial back-off window is 0 to 15 and it randomly selects the number 11. The CM must defer a total of 11 contention transmission opportunities. If the first available Request IE is for 6 requests, the CM does not use this and has 5 more opportunities to defer. If the next Request IE is for 2 requests, the CM has 3 more to defer. If the third Request IE is for 8 requests, the CM transmits on the fourth request, after deferring for 3 more opportunities. After a contention transmission, the CM waits for a Data Grant (Data Grant Pending) or Data Acknowledge in a subsequent MAP. Once either is received, the contention resolution is complete. The CM determines that the contention transmission was lost when it finds a MAP without a Data Grant (Data Grant Pending) or Data Acknowledge for it and with an Ack time more recent than the time of transmission.3 The CM MUST now increase its back-off window by a factor of two, as long as it is less than the maximum back-off window. The CM MUST randomly select a number within its new back-off window and repeat the deferring process described above. This re-try process continues until the maximum number of retries (16) has been reached, at which time the PDU MUST be discarded.
Note: The maximum number of retries is independent of the initial and maximum back-off windows that are defined by the CMTS.

If the CM receives a unicast Request or Data Grant at any time while deferring for this SID, it MUST stop the contention resolution process and use the explicit transmit opportunity. The CMTS has much flexibility in controlling the contention resolution. At one extreme, the CMTS may choose to set up the Data Backoff Start and End to emulate an Ethernet-style back-off with its associated simplicity and distributed nature, but also its fairness and efficiency issues. This would be done by setting Data Backoff Start =
1.

The MAP currently in effect is the MAP whose allocation start time has occurred but which includes IEs that have not occurred. Revised paragraph per ECN RFI2-N-02215, by GO, on 12/02/02. Data Acknowledge IEs are intended for collision detection only and is not designed for providing reliable transport (that is the responsibility of higher layers). If a MAP is lost or damaged, a CM waiting for a Data Acknowledge MUST assume that its contention data transmission was successful and MUST NOT retransmit the data packet. This prevents the CM from sending duplicate packets unnecessarily.

2. 3.

202

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

0 and End = 10 in the MAP. At the other end, the CMTS may make the Data Backoff Start and End identical and frequently update these values in the MAP so all cable modems are using the same, and hopefully optimal, backoff window. A CM transmitting a RNG-REQ in the Initial Maintenance IE MUST perform truncated binary exponential backoff using the Ranging Backoff Start and Ranging Backoff End to control the backoff window. The algorithm works similarly to data transmissions, except of the calculation of transmit opportunities which is described in the next section.1
9.4.2 Transmit Opportunities

A Transmit Opportunity is defined as any mini-slot in which a CM may be allowed to start a transmission. Transmit Opportunities typically apply to contention opportunities and are used to calculate the proper amount to defer in the contention resolution process. The number of Transmit Opportunities associated with a particular IE in a MAP is dependent on the total size of the region as well as the allowable size of an individual transmission. As an example, assume a contention REQ IE defines a region of 12 mini-slots. If the UCD defines a REQ Burst Size that fits into a single mini-slot then there are 12 Transmit Opportunities associated with this REQ IE, i.e., one for each mini-slot. If the UCD defines a REQ that fits in two mini-slots, then there are six Transmit Opportunities and a REQ can start on every other mini-slot.2 As another example, assume a REQ/Data IE that defines a 24 mini-slot region. If it is sent with an SID of 0x3FF4 (refer to Annex A), then a CM can potentially start a transmit on every fourth mini-slot; so this IE contains a total of six Transmit Opportunities (TX OP). Similarly, a SID of 0x3FF6 implies four TX OPs; 0x3FF8 implies three TX OPs; and 0x3FFC implies two TX OPs. For a Broadcast Initial Maintenance IE, a CM MUST start its transmission in the first mini-slot of the region; therefore it has a single Transmit Opportunity. The remainder of the region is used to compensate for the roundtrip delays since the CM has not yet been ranged. Station Maintenance IEs, Short/Long Data Grant IEs, Adv PHY Short/Long Data Grant IEs, Adv PHY Unsolicited Grant IEs, unicast Initial Maintenance, and unicast Request IEs are unicast and thus are not typically associated with contention Transmit Opportunities. They represent a single dedicated, or reservation based, Transmit Opportunity. In summary:
Table 9-4 Transmit Opportunity
Interval SID Type Transmit Opportunity

Request Request Request/Data Request/Data Request/Data Initial Maint.

Note:

Broadcast Multicast Broadcast Well-known Multicast Multicast Broadcast

# mini-slots required for a Request # mini-slots required for a Request Not allowed As defined by SID in Annex A Vendor specific algorithms Entire interval is a single tx opp.

Transmit Opportunity should not be confused with Burst Size. Burst Size requirements are specified in Table 6-1.3

1. 2.

Added this paragraph per ECN RFI2-N-02215, by GO, on 12/02/02. This paragraph updated per RFI2-N-02135 by RKV on 10/29/02.

203

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

9.4.3 CM Bandwidth Utilization

The following rules govern the response a CM makes when processing maps.
Note:

These standard behaviors can be overridden by the CMs Request/Transmission Policy (refer to Annex C.2.2.6.3):

1. A CM MUST first use any Grants assigned to it. Next, the CM MUST use any unicast REQ for it. Finally, the CM MUST use the next available broadcast/multicast REQ or REQ/Data IEs for which it is eligible. 2. A CM MUST NOT have more than one Request outstanding at a time for a particular Service ID. 3. If a CM has a Request pending, it MUST NOT use intervening contention intervals for that Service ID.

9.5

Data Link Encryption Support

The procedures to support data link encryption are defined in [DOCSIS8]. The interaction between the MAC layer and the security system is limited to the items defined below.
9.5.1 MAC Messages

MAC Management Messages (Section 8.3) MUST NOT be encrypted, except for certain cases where such a frame is included in a fragmented concatenated burst on the upstream. (Refer to Section 8.2.7.1)
9.5.2 Framing

The following rules MUST be followed when encryption is applied to a data PDU:

Privacy EH element of [DOCSIS8] MUST be in the extended header and MUST be the first EH element of
the Extended Header field (EHDR).

Encrypted data are carried as Data PDUs to the Cable MAC transparently.

3.

This Note added per RFI2-N-02135 by RKV on 10/29/02.

204

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10 Quality of Service and Fragmentation

This specification introduces several new Quality of Service (QoS) related concepts not present in [DOCSIS9]. These include:

Packet Classification & Flow Identification Service Flow QoS Scheduling Dynamic Service Establishment Fragmentation Two-Phase Activation Model

10.1 Theory of Operation

The various DOCSIS protocol mechanisms described in this document can be used to support Quality of Service (QoS) for both upstream and downstream traffic through the CM and the CMTS. This section provides an overview of the QoS protocol mechanisms and their part in providing end-to-end QoS. The requirements for Quality of Service include:

A configuration and registration function for pre-configuring CM-based QoS Service Flows and traffic
parameters.

A signaling function for dynamically establishing QoS-enabled Service Flows and traffic parameters A traffic-shaping and traffic-policing function for Service Flow-based traffic management, performed on traffic arriving from the upper layer service interface and outbound to the RF.

Utilization of MAC scheduling and traffic parameters for upstream Service Flows. Utilization of QoS traffic parameters for downstream Service Flows. Classification of packets arriving from the upper layer service interface to a specific active Service Flow. Grouping of Service Flow properties into named Service Classes, so upper layer entities and external applications (at both the CM and CMTS) can request Service Flows with desired QoS parameters in a globally consistent way.

The principal mechanism for providing enhanced QoS is to classify packets traversing the RF MAC interface into a Service Flow. A Service Flow is a unidirectional flow of packets that is provided a particular Quality of Service. The CM and CMTS provide this QoS by shaping, policing, and prioritizing traffic according to the QoS Parameter Set defined for the Service Flow. The primary purpose of the Quality of Service features defined here is to define transmission ordering and scheduling on the Radio Frequency Interface. However, these features often need to work in conjunction with mechanisms beyond the RF interface in order to provide end-to-end QoS or to police the behavior of cable modems. For example, the following behaviors are permitted:

Policies may be defined by CM MIBs which overwrite the TOS byte. Such policies are outside the
scope of the RFI specification. In the upstream direction the CMTS polices the TOS byte setting regardless of how the TOS byte is derived or by whom it is written (originator or CM policy).

The queueing of Service Flow packets at the CMTS in the downstream direction may be based on
the TOS byte.

Downstream Service Flows can be reclassified by the CM to provide enhanced service onto the
subscriber-side network.

205

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Service Flows exist in both the upstream and downstream direction, and may exist without actually being activated to carry traffic. Service Flows have a 32-bit Service Flow Identifier (SFID) assigned by the CMTS. All Service Flows have an SFID; active and admitted upstream Service Flows also have a 14-bit Service Identifier (SID). At least two Service Flows must be defined in each configuration file: one for upstream and one for downstream service. The first upstream Service Flow describes the Primary Upstream Service Flow, and is the default Service Flow used for otherwise unclassified traffic, including both MAC Management messages and Data PDUs. The first downstream Service Flow describes service to the Primary Downstream Service Flow. Additional Service Flows defined in the Configuration file create Service Flows that are provided QoS services. Conceptually, incoming packets are matched to a Classifier that determines to which QoS Service Flow the packet is forwarded. The Classifier can examine the LLC header of the packet, the IP/TCP/UDP header of the packet or some combination of the two. If the packet matches one of the Classifiers, it is forwarded to the Service Flow indicated by the SFID attribute of the Classifier. If the packet is not matched to a Classifier, it is forwarded on the Primary Service Flow.
10.1.1 10.1.1.1 Concepts Service Flows

A Service Flow is a MAC-layer transport service that provides unidirectional transport of packets either to upstream packets transmitted by the CM or to downstream packets transmitted by the CMTS1. A Service Flow is characterized by a set of QoS Parameters such as latency, jitter, and throughput assurances. In order to standardize operation between the CM and CMTS, these attributes include details of how the CM requests upstream mini-slots and the expected behavior of the CMTS upstream scheduler. A Service Flow is partially characterized by the following attributes2:

ServiceFlowID: exists for all service flows ServiceID: only exists for admitted or active upstream service flows ProvisionedQosParamSet: defines a set of QoS Parameters which appears in the configuration file
and is presented during registration. This MAY define the initial limit for authorizations allowed by the authorization module. The ProvisionedQosParamSet is defined once when the Service Flow is created via registration.3

AdmittedQosParamSet: defines a set of QoS parameters for which the CMTS (and possibly the
CM) are reserving resources. The principal resource to be reserved is bandwidth, but this also includes any other memory or time-based resource required to subsequently activate the flow.

ActiveQosParamSet: defines set of QoS parameters defining the service actually being provided to
the Service Flow. Only an Active Service Flow may forward packets.

1.

A Service Flow, as defined here, has no direct relationship to the concept of a flow as defined by the IETFs Integrated Services (intserv) Working Group [RFC-2212]. An intserv flow is a collection of packets sharing transport-layer endpoints. Multiple intserv flows can be served by a single Service Flow. However, the Classifiers for a Service Flow may be based on 802.1P/Q criteria, and so may not involve intserv flows at all. Some attributes are derived from the above attribute list. The Service Class Name is an attribute of the ProvisionedQoSParamSet. The activation state of the Service Flow is determined by the ActiveQoSParamSet. If the ActiveQoSParamSet is null then the service flow is inactive. The ProvisionedQoSParamSet is null when a flow is created dynamically.

2.

3.

206

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A Service Flow exists when the CMTS assigns a Service Flow ID (SFID) to it. The SFID serves as the principal identifier in the CM and CMTS for the Service Flow. A Service Flow which exists has at least an SFID, and an associated Direction. The Authorization Module is a logical function within the CMTS that approves or denies every change to QoS Parameters and Classifiers associated with a Service Flow. As such it defines an envelope that limits the possible values of the AdmittedQoSParameterSet and ActiveQoSParameterSet. The relationship between the QoS Parameter Sets is as shown in Figure 10-1 and Figure 10-2. The ActiveQoSParameterSet is always a subset1 of the AdmittedQoSParameterSet which is always a subset of the authorized envelope. In the dynamic authorization model, this envelope is determined by the Authorization Module (labelled as the AuthorizedQoSParameterSet). In the provisioned authorization model, this envelope is determined by the ProvisionedQoSParameterSet. (Refer to Section 10.1.4 for further information on the authorization models)

AuthQosParamSet = ProvisionedQosParamSet (SFID) AdmittedQosParamSet (SFID & SID) ActiveQosParamSet (SFID & Active SID)

Figure 10-1 Provisioned Authorization Model Envelopes

1.

To say that QoS Parameter Set A is a subset of QoS Parameter Set B, the following MUST be true for all QoS Parameters in A and B: If a smaller QoS parameter value indicates less resources (e.g., Maximum Traffic Rate), A is a subset of B if the parameter in A less than or equal to the same parameter in B. If a larger QoS parameter value indicates less resources (e.g., Tolerated Grant Jitter), A is a subset of B if the parameter in A is greater than or equal to the same parameter in B. If the QoS parameter specifies a periodic interval (e.g., Nominal Grant Interval), A is a subset of B if the parameter in A is an integer multiple of the same parameter in B. If the QoS parameter is not quantitative (e.g., Service Flow Scheduling Type), A is a subset of B if the parameter in A is equal to the same parameter in B.

207

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

ProvQosParamSet (SFID) AuthQosParamSet (CMTS only, not known by CM) AdmitQosParamSet (SFID & SID) ActiveQosParamSet (SFID & Active SID)

Figure 10-2 Dynamic Authorization Model Envelopes

It is useful to think of three types of Service Flows:

Provisioned: this type of Service Flow is known via provisioning through the configuration file, its AdmittedQoSParamSet and ActiveQoSParamSet are both null. A Provisioned Service Flow may or may not have associated Classifiers. If a Provisioned Service Flow has associated Classifiers, the Classifiers MUST NOT be used to classify packets onto the flow, regardless of the Classifiers Activation State.

Admitted: this type of Service Flow has resources reserved by the CMTS for its AdmittedQoSParamSet, but
these parameters are not active (its ActiveQoSParamSet is null). Admitted Service Flows may have been provisioned or may have been signalled by some other mechanism. Generally, Admitted Service Flows have associated Classifiers, however, it is possible for Admitted Service Flows to use policy-based classification. If Admitted Service Flows have associated Classifiers, the classifiers MUST NOT be used to classify packets onto the flow, regardless of the classifiers activation state.

Active: this type of Service Flow has resources committed by the CMTS for its QoS Parameter Set, (e.g., is
actively sending MAPs containing unsolicited grants for a UGS-based service flow). Its ActiveQoSParamSet is non-null. Generally, Active Service Flows have associated Classifiers, however, it is possible for Active Service Flows to use policy-based classification. Primary Service Flows may have associated Classifiers(s), but in addition to any packets matching such Classifiers, all packets that fail to match any Classifier will be sent on the Primary Service Flow for that direction.
10.1.1.2 Classifiers

A Classifier is a set of matching criteria applied to each packet entering the cable network. It consists of some packet matching criteria (destination IP address, for example), a classifier priority, and a reference to a service flow. If a packet matches the specified packet matching criteria, it is then delivered on the referenced service flow. Several Classifiers may all refer to the same Service Flow. The classifier priority is used for ordering the application of Classifiers to packets. Explicit ordering is necessary because the patterns used by Classifiers may overlap. The priority need not be unique, but care must be taken within a classifier priority to prevent ambiguity in classification. (Refer to Section 10.1.6.1) Downstream Classifiers are applied by the CMTS to packets it is transmitting, and Upstream Classifiers are applied at the CM and may be applied at the CMTS to police the classification of upstream packets. Figure 10-3 illustrates the mapping discussed above.

208

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Upper Layer Entity (e.g. bridge, router)

Upper Layer Entity (e.g. bridge, router, client)

MAC Mgmt Msgs Primary SFID

Downstream Classifier

SFID 2

(Optional) Ingress Classifier Downstream

...
SFID n

Downstream Service Flows Upstream Classifier

RF
SID 2

MAC Mgmt Msgs Primary SID

Upstream Classifier

Upstream

...
SID n

CMTS

Upstream Service Flows

CM

Figure 10-3 Classification within the MAC Layer

CM and CMTS Packet Classification consists of multiple Classifiers. Each Classifier contains a priority field which determines the search order for the Classifier. The highest priority Classifier MUST be applied first. If a Classifier is found that has at least one relevant parameter and all relevant parameters match the packet, the Classifier MUST forward the packet to the corresponding Service Flow (irrelevant parameters - as defined in C.2.1 - have no impact on packet classification decisions). If a Classifier contains no relevant parameters for a given packet (i.e., all parameters are irrelevant), then that packet cannot match the Classifier, and the Classifier MUST NOT forward the packet to the corresponding Service Flow. If a packet does not match any Classifier and as a result has not been classified to any other flow, then it MUST be classified to the Primary Service Flow.1 The packet classification table contains the following fields:

Priority determines the search order for the table. Higher priority Classifiers are searched before lower
priority Classifiers.

IP Classification Parameters zero or more of the IP classification parameters (IP TOS Range/Mask, IP
Protocol, IP Source Address/Mask, IP Destination Address/Mask, TCP/UDP Source Port Start, TCP/UDP Source Port End, TCP/UDP Destination Port Start, TCP/UCP Destination Port End)

LLC Classification Parameters zero or more of the LLC classification parameters (Destination MAC
Address, Source MAC Address, Ethertype/SAP)

IEEE 802.1P/Q Parameters zero or more of the IEEE classification parameters (802.1P Priority Range,
802.1Q VLAN ID)

Service Flow Identifier identifier of a specific flow to which this packet is to be directed

1.

Replaced this paragraph per ECN RFI2-N-02200, change #1, by GO, on 11/21/02.

209

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Classifiers can be added to the table either via management operations (configuration file, registration) or via dynamic operations (dynamic signaling, DOCSIS MAC sublayer service interface). SNMP-based operations can view Classifiers that are added via dynamic operations, but can not modify or delete Classifiers that are created by dynamic operations. The format for classification table parameters defined in the configuration file, registration message, or dynamic signaling message is contained in Annex C. Classifier attributes include an activation state (see Annex C.2.1.3.6). The inactive setting may be used to reserve resources for a classifier which is to be activated later. The actual activation of the classifier depends both on this attribute and on the state of its service flow. If the service flow is not active then the classifier is not used, regardless of the setting of this attribute.
10.1.2 Object Model

The major objects of the architecture are represented by named rectangles in Figure 10-4. Each object has a number of attributes; the attribute names which uniquely identify the object are underlined. Optional attributes are denoted with brackets. The relationship between the number of objects is marked at each end of the association line between the objects. For example, a Service Flow may be associated with from 0 to 65535 Classifiers, but a Classifier is associated with exactly one Service flow. The Service Flow is the central concept of the MAC protocol. It is uniquely identified by a 32-bit Service Flow ID (SFID) assigned by the CMTS. Service Flows may be in either the upstream or downstream direction. A unicast Service Identifier (SID) is a 14-bit index, assigned by the CMTS, which is associated with one and only one Admitted Upstream Service Flow. Typically, an outgoing user data Packet is submitted by an upper layer protocol (such as the forwarding bridge of a CM) for transmission on the Cable MAC interface. The packet is compared against a set of Classifiers. The matching Classifier for the Packet identifies the corresponding Service Flow via the Service Flow ID (SFID). In the case where more than one Classifier matches the packet, the highest Priority Classifier is chosen. The Classifier matching a packet may be associated with a Payload Header Suppression Rule. A PHS Rule provides details on how header bytes of a Packet PDU can be omitted, replaced with a Payload Header Suppression Index for transmission and subsequently regenerated at the receiving end. PHS Rules are indexed by the combination of {SFID, PHSI} (refer to Section 10.4). When a Service Flow is deleted, all Classifiers and any associated PHS Rules referencing it MUST also be deleted. The Service Class is an object that MUST be implemented at the CMTS. It is referenced by an ASCII name which is intended for provisioning purposes. A Service Class is defined in the CMTS to have a particular QoS Parameter Set. A Service Flow may contain a reference to the Service Class Name that selects all of the QoS parameters of the Service Class. The Service Flow QoS Parameter Sets may augment and even override the QoS parameter settings of the Service Class, subject to authorization by the CMTS. (Refer to Annex C.2.2.5)1 If a Packet has already been determined by upper layer policy mechanisms to be associated with a particular Service Class Name/Priority combination, that combination associates the packet with a particular Service Flow directly (refer to Section 10.1.6.1). The upper layer may also be aware of the particular Service Flows in the MAC Sublayer, and may have assigned the Packet directly to a Service Flow. In these cases, a user data Packet is considered to be directly associated with a Service Flow as selected by the upper layer. This is depicted with the dashed arrow in Figure 10-4. (Refer to Appendix I)

1.

Revised the first sentence of this paragraph per ECN RFIv2.0-N-04.0191-2 by GO on 11/19/04.

210

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Packet LlcHeader [lp Header] [SCase] [RulePriority] [SFID] matches

Classifier SFID ClassifierId LlcPacketPattern lpPacketPattern RulePriority 0,1 0..65535

Service Flow SFID 1 Direction [SID] [ProvQosParamSet] [AdmittedQosParamSet] ActiveQosParamSet] 1 N 0,3

PayloadHeader Suppression (PHS) SFID PHSI Classifierld PHSF PHSM PHSS PHSV

Service Class Service Class Name QosParamSet

0..255

Figure 10-4

Theory of Operation Object Model

10.1.3

Service Classes

The QoS attributes of a Service Flow may be specified in two ways: either by explicitly defining all attributes, or implicitly by specifying a Service Class Name. A Service Class Name is a string which the CMTS associates with a QoS Parameter Set. It is described further below. The Service Class serves the following purposes: 1. It allows operators, who so wish, to move the burden of configuring service flows from the provisioning server to the CMTS. Operators provision the modems with the Service Class Name; the implementation of the name is configured at the CMTS. This allows operators to modify the implementation of a given service to local circumstances without changing modem provisioning. For example, some scheduling parameters may need to be tweaked differently for two different CMTSes to provide the same service. As another example, service profiles could be changed by time of day. 2. It allows CMTS vendors to provide class-based-queuing if they choose, where service flows compete within their class and classes compete with each other for bandwidth. 3. It allows higher-layer protocols to create a Service Flow by its Service Class Name. For example, telephony signaling may direct the CM to instantiate any available Provisioned Service Flow of class G711. 4. It allows packet classification policies to be defined which refer to a desired service class, without having to refer to a particular service flow instance of that class.

211

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note: The Service Class is optional: the flow scheduling specification may always be provided in full; a service flow may belong to no service class whatsoever. CMTS implementations MAY treat such unclassed flows differently from classed flows with equivalent parameters.

Any Service Flow MAY have each of its QoS Parameter Sets specified in any of three ways:

By explicitly including all traffic parameters By indirectly referring to a set of traffic parameters by specifying a Service Class Name By specifying a Service Class Name along with modifying parameters
The Service Class Name is expanded to its defined set of parameters at the time the CMTS successfully admits the Service Flow. The Service Class expansion can be contained in the following CMTS-originated messages: Registration Response, DSA-REQ, DSC-REQ, DSA-RSP and DSC-RSP. In all of these cases, the CMTS MUST include a Service Flow Encoding that includes the Service Class Name and the QoS Parameter Set of the Service Class. If a CM-initiated request contained any supplemental or overriding Service Flow parameters, a successful response MUST also include these parameters. When a Service Class name is given in an admission or activation request, the returned QoS Parameter Set may change from activation to activation. This can happen because of administrative changes to the Service Class QoS Parameter Set at the CMTS. If the definition of a Service Class Name is changed at the CMTS (e.g., its associated QoS Parameter Set is modified), it has no effect on the QoS Parameters of existing Service Flows associated with that Service Class. A CMTS MAY initiate DSC transactions to existing Service Flows which reference the Service Class Name to affect the changed Service Class definition. When a CM uses the Service Class Name to specify the Admitted QoS Parameter Set, the expanded set of TLV encodings of the Service Flow will be returned to the CM in the response message (REG-RSP, DSA-RSP, or DSC-RSP). Use of the Service Class Name later in the activation request may fail if the definition of the Service Class Name has changed and the new required resources are not available. Thus, the CM SHOULD explicitly request the expanded set of TLVs from the response message in its later activation request.
10.1.4 Authorization

Every change to the Service Flow QoS Parameters MUST be approved by an authorization module. This includes every REG-REQ or DSA-REQ message to create a new Service Flow, and every DSC-REQ message to change a QoS Parameter Set of an existing Service Flow. Such changes include requesting an admission control decision (e.g., setting the AdmittedQoSParamSet) and requesting activation of a Service Flow (e.g., setting the ActiveQoSParameterSet). Reduction requests regarding the resources to be admitted or activated are also checked by the authorization module, as are requests to add or change the Classifiers. In the static authorization model, the authorization module receives all registration messages, and stores the provisioned status of all deferred Service Flows. Admission and activation requests for these provisioned service flows will be permitted, as long as the Admitted QoS Parameter Set is a subset of the Provisioned QoS Parameter Set, and the Active QoS Parameter Set is a subset of the Admitted QoS Parameter Set. Requests to change the Provisioned QoS Parameter Set will be refused, as will requests to create new dynamic Service Flows. This defines a static system where all possible services are defined in the initial configuration of each CM. In the dynamic authorization model, the authorization module not only receives all registration messages, but also communicates through a separate interface to an independent policy server. This policy server may provide to the authorization module advance notice of upcoming admission and activation requests, and specifies the proper authorization action to be taken on those requests. Admission and activation requests from a CM are then checked by the Authorization Module to ensure that the ActiveQoSParameterSet being requested is a subset of the set provided by the policy server. Admission and activation requests from a CM that are signalled in advance

212

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

by the external policy server are permitted. Admission and activation requests from a CM that are not presignalled by the external policy server may result in a real-time query to the policy server, or may be refused. During registration, the CM MUST send to the CMTS the authenticated set of TLVs derived from its configuration file which defines the Provisioned QoS Parameter Set. Upon receipt and verification at the CMTS, these are handed to the Authorization Module within the CMTS. The CMTS MUST be capable of caching the Provisioned QoS Parameter Set, and MUST be able to use this information to authorize dynamic flows which are a subset of the Provisioned QoS Parameter Set. The CMTS SHOULD implement mechanisms for overriding this automated approval process (such as described in the dynamic authorization model). For example:

Deny all requests whether or not they have been pre-provisioned Define an internal table with a richer policy mechanism but seeded by the configuration file information Refer all requests to an external policy server
10.1.5 Types of Service Flows

It is useful to think about three basic types of Service Flows. This section describes these three types of Service Flows in more detail. However, it is important to note that there are more than just these three basic types. (Refer to Annex C.2.2.3.5)
10.1.5.1 Provisioned Service Flows

A Service Flow may be Provisioned but not immediately activated (sometimes called deferred). That is, the description of any such service flow in the TFTP configuration file contains an attribute which provisions but defers activation and admission (refer to Annex C.2.2.3.5). During Registration, the CMTS assigns a Service Flow ID for such a service flow but does not reserve resources. The CMTS MAY also require an exchange with a policy module prior to admission. As a result of external action beyond the scope of this specification (e.g., [PKT-MGCP]), the CM MAY choose to activate a Provisioned Service Flow by passing the Service Flow ID and the associated QoS Parameter Sets. The CM MUST also provide any applicable Classifiers. If authorized and resources are available, the CMTS MUST respond by assigning a unique unicast SID for the upstream Service Flow. The CMTS MAY deactivate the Service Flow, but SHOULD NOT delete the Service Flow during the CM registration epoch. As a result of external action beyond the scope of this specification (e.g., [PKT-MGCP]), the CMTS MAY choose to activate a Service Flow by passing the Service Flow ID as well as the SID and the associated QoS Parameter Sets. The CMTS MUST also provide any applicable Classifiers. The CMTS MAY deactivate the Service Flow, but SHOULD NOT delete the Service Flow during the CM registration epoch. Such a Provisioned Service Flow MAY be activated and deactivated many times (through DSC exchanges). In all cases, the original Service Flow ID MUST be used when reactivating the service flow.
10.1.5.2 Admitted Service Flows

This protocol supports a two-phase activation model which is often utilized in telephony applications. In the twophase activation model, the resources for a call are first admitted, and then once the end-to-end negotiation is completed (e.g., called partys gateway generates an off-hook event) the resources are activated. Such a twophase model serves the purposes of a) conserving network resources until a complete end-to-end connection has been established, b) performing policy checks and admission control on resources as quickly as possible, and, in particular, before informing the far end of a connection request, and c) preventing several potential theft-ofservice scenarios.

213

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

For example, if an upper layer service were using unsolicited grant service, and the addition of upper-layer flows could be adequately provided by increasing the Grants Per Interval QoS parameter, then the following might be used. When the first upper-layer flow is pending, the CM issues a DSA-Request with the Admit Grants Per Interval parameter equal one, and the Activate Grants Per Interval parameter equal zero. Later when the upperlayer flow becomes active, it issues a DSC-Request with the instance of the Activate Grants-per-Interval parameter equal to one. Admission control was performed at the time of the reservation, so the later DSCRequest, having the Activate parameters within the range of the previous reservation, is guaranteed to succeed. Subsequent upper-layer flows would be handled in the same way. If there were three upper-layer flows establishing connections, with one flow already active, the Service Flow would have Admit(ted) Grants-perInterval equal four, and Active Grants-per-Interval equal one. An activation request of a Service Flow where the new ActiveQoSParamSet is a subset of the AdmittedQoSParamSet and no new classifiers are being added MUST be allowed (except in the case of catastrophic failure). An admission request where the AdmittedQoSParamSet is a subset of the previous AdmittedQoSParamSet, so long as the ActiveQoSParamSet remains a subset of the AdmittedQoSParameterSet, MUST succeed. A Service Flow that has resources assigned to its AdmittedQoSParamSet, but whose resources are not yet completely activated, is in a transient state. A time out value MUST be enforced by the CMTS that requires Service Flow activation within this period. (Refer to Annex C.2.2.5.7) If Service Flow activation is not completed within this interval, the assigned resources in excess of the active QoS parameters MUST be released by the CMTS. It is possible in some applications that a long-term reservation of resources is necessary or desirable. For example, placing a telephone call on hold should allow any resources in use for the call to be temporarily allocated to other purposes, but these resources must be available for resumption of the call later. The AdmittedQoSParamSet is maintained as soft state in the CMTS; this state must be refreshed periodically for it to be maintained without the above timeout releasing the non-activated resources. This refresh MAY be signalled with a periodic DSC-REQ message with identical QoS Parameter Sets, or MAY be signalled by some internal mechanism within the CMTS outside of the scope of this specification (e.g., by the CMTS monitoring RSVP refresh messages). Every time a refresh is signaled to the CMTS, the CMTS MUST refresh the soft state.
10.1.5.3 Active Service Flows

A Service Flow that has a non-NULL set of ActiveQoSParameters is said to be an Active Service Flow. It is requesting1 and being granted bandwidth for transport of data packets. An admitted Service Flow may be made active by providing an ActiveQoSParameterSet, signaling the resources actually desired at the current time. This completes the second stage of the two-phase activation model. (Refer to Section 10.1.5.2) A Service Flow may be Provisioned and immediately activated. This is the case for the Primary Service Flows. It is also typical of Service Flows for monthly subscription services, etc. These Service Flows are established at registration time and MUST be authorized by the CMTS based on the CMTS MIC. These Service Flows MAY also be authorized by the CMTS authorization module. Alternatively, a Service Flow may be created dynamically and immediately activated. In this case, two-phase activation is skipped and the Service Flow is available for immediate use upon authorization.

1.

According to its Request/Transmission Policy (refer to Annex C.2.2.6.3)

214

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10.1.6

Service Flows and Classifiers

The basic model is that the Classifiers associate packets into exactly one Service Flow. The Service Flow Encodings provide the QoS Parameters for treatment of those packets on the RF interface. These encodings are described in Annex C.2. In the upstream direction, the CM MUST classify upstream packets to Active Service Flows. The CMTS MUST classify downstream traffic to Active Downstream Service Flows. There MUST be a default downstream service flow for otherwise unclassified broadcast and multicast traffic. The CMTS polices packets in upstream Service Flows to ensure the integrity of the QoS Parameters and the packets TOS value. When the rate at which packets are sent is greater than the policed rate at the CMTS, then these packets MAY be dropped by the CMTS (refer to Annex C.2.2.5.2). When the value of the TOS byte is incorrect, the CMTS (based on policy) MUST police the stream by overwriting the TOS byte (refer to Annex C.2.2.6.10). It may not be possible for the CM to forward certain upstream packets on certain Service Flows. In particular, a Service Flow using unsolicited grant service with fragmentation disabled cannot be used to forward packets larger than the grant size. If a packet is classified to a Service Flow on which it cannot be transmitted, the CM MUST either transmit the packet on the Primary Service Flow or discard the packet depending on the Request/ Transmission Policy of the Service Flow to which the packet was classified. MAC Management messages may only be matched by a classifier that contains a Annex C.2.1.6.3 Ethertype/ DSAP/MacType parameter encoding and when the type field of the MAC Management Message Header (Section 8.3.1) matches that parameter. One exception is that the Primary SID MUST be used for periodic ranging, as specified in Section 8.1.2.3, even if a classifier matches the upstream RNG-REQ message of periodic ranging. In the absence of any classifier matching a MAC Management message, it SHOULD be transmitted on the Primary Service Flow. Other than those MAC message types precluded from classification in Annex C.2.1.6.3, a CM or CMTS MAY forward an otherwise unclassified MAC message on any Service Flow in an implementation-specific manner. Although MAC Management messages are subject to classification, they are not considered part of any service flow. Transmission of MAC Management messages MUST NOT influence any QoS calculations of the Service Flow to which they are classified. Delivery of MAC Management messages is implicitly influenced by the attributes of the associated service flow.
10.1.6.1 Policy-Based Classification and Service Classes

As noted in Appendix I, there are a variety of ways in which packets may be enqueued for transmission at the MAC Service Interface. At one extreme are embedded applications that are tightly bound to a particular Payload Header Suppression Rule (refer to Section 10.4) and which forego more general classification by the MAC. At the other extreme are general transit packets of which nothing is known until they are parsed by the MAC Classification rules. Another useful category is traffic to which policies are applied by a higher-layer entity and then passed to the MAC for further classification to a particular service flow. Policy-based classification is, in general, beyond the scope of this specification. One example might be the docsDevFilterIpPolicyTable defined in the Cable Device MIB [RFC-2669]. Such policies may tend to be longerlived than individual service flows and MAC classifiers and so it is appropriate to layer the two mechanisms, with a well-defined interface between policies and MAC Service Flow Classification. The interface between the two layers is the addition of two parameters at the MAC transmission request interface. The two parameters are a Service Class Name and a Rule Priority that is applied to matching the

215

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

service class name. The Policy Priority is from the same number space as the Packet Classifier Priority of the packet-matching rules used by MAC classifiers. The MAC Classification algorithm is now: MAC_DATA.request(PDU, ServiceClassName, RulePriority) TxServiceFlowID = FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName) SearchID = SEARCH_CLASSIFIER_TABLE (All Priority Levels) IF (SearchID not NULL and Classifier.RulePriority >= MAC_DATA.RulePriority) TxServiceFlowID = SearchID IF (TxServiceFlowID = NULL) TRANSMIT_PDU (PrimaryServiceFlowID) ELSE TRANSMIT_PDU (TxServiceFlowID) While Policy Priority competes with Packet Classifier Priority and its choice might in theory be problematic, it is anticipated that well-known ranges of priorities will be chosen to avoid ambiguity. In particular, dynamicallyadded classifiers MUST use the priority range 64-191. Classifiers created as part of registration, as well as policy-based classifiers, may use zero through 255, but SHOULD avoid the dynamic range.
Note: Classification within the MAC sublayer is intended to simply associate a packet with a service flow. If a packet is intended to be dropped it MUST be dropped by the higher-layer entity and not delivered to the MAC sublayer.

10.1.7 10.1.7.1

General Operation Static Operation

Static configuration of Classifiers and Service Flows uses the Registration process. A provisioning server provides the CM with configuration information. The CM passes this information to the CMTS in a Registration Request. The CMTS adds information and replies with a Registration Response. The CM sends a Registration Acknowledge to complete registration.

ig Conf TFTP
Regis tratio

uratio

Provisioning Server

n-Re

ques t

CM
Re tion gistra

p -Res

ons e

Reg istra tio

CMTS
n- A ck

Figure 10-5 Registration Message Flow

A TFTP configuration file consists of one or more instances of Classifiers and Service Flow Encodings. Classifiers are loosely ordered by priority. Each Classifier refers to a Service Flow via a service flow

216

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

reference. Several Classifiers may refer to the same Service Flow. Additionally, more than one Classifier may have the same priority, and in this case, the particular classifier used is not defined.
Table 10-1 TFTP File Contents
Point To Service Flow Reference Service Flow Reference Service Flow ID

Items Upstream Classifiers Each containing a Service Flow Reference (pointer) Downstream Classifiers Each containing a Service Flow Reference (pointer) Service Flow Encodings Immediate activation requested, upstream Service Flow Encodings Provisioned for later activation requested, upstream Service Flow Encodings Immediate activation requested, downstream

1..n (n+1)..q 1..m (m+1)..n (n+1)..p (p+1)..q None Yet None Yet None Yet None Yet

Service Flow Encodings Provisioned for later activation requested, downstream

Service Flow Encodings contain either a full definition of service attributes (omitting defaultable items if desired) or a service class name. A service class name is an ASCII string which is known at the CMTS and which indirectly specifies a set of QoS Parameters. (Refer to Sections 10.1.3 and Annex C.2.2.3.4)
Note: At the time of the TFTP configuration file, Service Flow References exist as defined by the provisioning server. Service Flow Identifiers do not yet exist because the CMTS is unaware of these service flow definitions.

The Registration Request packet contains Downstream Classifiers (if to be immediately activated) and all Inactive Service Flows. The configuration file, and thus, the Registration Request, generally does not contain a Downstream Classifier if the corresponding Service Flow is requested with deferred activation. This allows for late binding of the Classifier when the Flow is activated.
Table 10-2 Registration Request Contents
Point To Service Flow Reference Service Flow Reference Service Flow ID

Items Upstream Classifiers Each containing a Service Flow Reference (pointer) Downstream Classifiers Each containing a Service Flow Reference (pointer) Service Flow Encodings Immediate activation requested, upstream May specify explicit attributes or service class name Service Flow Encodings Provisioned for later activation requested, upstream Explicit attributes or service class name Service Flow Encodings Immediate activation requested, downstream Explicit attributes or service name Service Flow Encodings Provisioned for later activation requested, downstream Explicit attributes or service name

1..n (n+1)..p 1..m None Yet

(m+1)..n

None Yet

(n+1)..p

None Yet

(p+1)..q

None Yet

The Registration Response sets the QoS Parameter Sets according to the Quality of Service Parameter Set Type in the Registration Request.
217

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The Registration Response preserves the Service Flow Reference attribute, so that the Service Flow Reference can be associated with SFID and/or SID.
Table 10-3 Registration Response Contents
Service Flow Reference Service Flow Identifier Service Identifier

Items

Active Upstream Service Flows Explicit attributes Provisioned Upstream Service Flows Explicit attributes Active Downstream Service Flows Explicit attributes Provisioned Downstream Service Flows Explicit attributes

1..m (m+1)..n (n+1)..p (p+1)..q

SFID SFID SFID SFID

SID Not Yet N/A N/A

The SFID is chosen by the CMTS to identify a downstream or upstream service Flow that has been authorized but not activated. A DSC-Request from a modem to admit or activate a Provisioned Service Flow contains its SFID. If it is a downstream Flow then the Downstream Classifier is also included.
10.1.7.2 Dynamic Service Flow Creation CM Initiated

Service Flows may be created by the Dynamic Service Addition process, as well as through the Registration process outlined above. The Dynamic Service Addition may be initiated by either the CM or the CMTS, and may create one upstream and/or one downstream dynamic Service Flow(s). A three-way handshake is used to create Service Flows. The CM-initiated protocol is illustrated in Figure 10-6 and described in detail in Section 11.4.2.1.

D SA

-R eq

uest

CM
-Re DSA

se s pon

DSA

CMTS
-Ac k now ledg e

Figure 10-6 Dynamic Service Addition Message Flow CM Initiated

A DSA-Request from a CM contains Service Flow Reference(s), QoS Parameter set(s) (marked either for admission-only or for admission and activation) and any required Classifiers.
10.1.7.3 Dynamic Service Flow Creation CMTS Initiated

A DSA-Request from a CMTS contains Service Flow Identifier(s) for one upstream and/or one downstream Service Flow, possibly a SID, set(s) of active or admitted QoS Parameters, and any required Classifier(s). The protocol is as illustrated in Figure 10-7 and is described in detail in Section 11.4.2.2.

218

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

D SA

u -Req

est

CMTS
D SA -Res pons

CM
kn -Ac DSA edg ow l e

Figure 10-7 Dynamic Service Addition Message Flow CMTS Initiated

10.1.7.4

Dynamic Service Flow Modification and Deletion

In addition to the methods presented above for creating service flows, protocols are defined for modifying and deleting service flows. Refer to Section 11.4.3 and Section 11.4.4. Both provisioned and dynamically created Service flows are modified with the DSC message, which can change the Admitted and Active QoS Parameter sets of the flow. The DSC can also add, replace, or delete classifiers, and add, add parameters to, or delete PHS rules. A successful DSC transaction changes a Service Flows QoS parameters by replacing both the Admitted and Active QoS parameter sets. If the message contains only the Admitted set, the Active set is set to null and the flow is deactivated. If the message contains neither set (000 value used for Quality of Service Parameter Set type, see Annex C.2.2.3.5) then both sets are set to null and the flow is de-admitted. When the message contains both QoS parameter sets, the Admitted set is checked first and, if admission control succeeds, the Active set in the message is checked against the Admitted set in the message to ensure that it is a subset (see Section 10.1.1.1). If all checks are successful, the QoS parameter sets in the message become the new Admitted and Active QoS parameter sets for the Service Flow. If either of the checks fails, the DSC transaction fails and the Service Flow QoS parameter sets are unchanged.

10.2 Upstream Service Flow Scheduling Services

The following sections define the basic upstream Service Flow scheduling services and list the QoS parameters associated with each service. A detailed description of each QoS parameter is provided in Annex C. The section also discusses how these basic services and QoS parameters can be combined to form new services, such as, Committed Information Rate (CIR) service. Scheduling services are designed to improve the efficiency of the poll/grant process. By specifying a scheduling service and its associated QoS parameters, the CMTS can anticipate the throughput and latency needs of the upstream traffic and provide polls and/or grants at the appropriate times. Each service is tailored to a specific type of data flow as described below. The basic services comprise: Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), Unsolicited Grant Service with Activity Detection (UGS-AD), Non-Real-Time Polling Service (nrtPS) and Best Effort (BE) service. Table 10-4 shows the relationship between the scheduling services and the related QoS parameters.

219

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

10.2.1

Unsolicited Grant Service

The Unsolicited Grant Service (UGS) is designed to support real-time service flows that generate fixed size data packets on a periodic basis, such as Voice over IP. The service offers fixed size grants on a real-time periodic basis, which eliminate the overhead and latency of CM requests and assure that grants will be available to meet the flows real-time needs. The CMTS MUST provide fixed size data grants at periodic intervals to the Service Flow. In order for this service to work correctly, the Request/Transmission Policy (refer to Annex C.2.2.6.3) setting MUST be such that the CM is prohibited from using any contention request or request/data opportunities and the CMTS SHOULD NOT provide any unicast request opportunities. The Request/Transmission Policy MUST also prohibit piggyback requests. This will result in the CM only using unsolicited data grants for upstream transmission. All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service parameters are the Unsolicited Grant Size, the Nominal Grant interval, the Tolerated Grant Jitter and the Request/ Transmission Policy. (Refer to Appendix VI) The Unsolicited Grant Synchronization Header (UGSH) in the Service Flow EH Element (refer to Section 8.2.6.3.2) is used to pass status information from the CM to the CMTS regarding the state of the UGS Service Flow. The most significant bit of the UGSH is the Queue Indicator (QI) flag. When the QI flag is set it indicates a rate overrun condition for the Service Flow. When the QI flag is clear it indicates a rate non-overrun condition for the Service Flow. The QI flag allows the CMTS to provide a dynamic rate-compensation function by issuing additional grants. The CM MUST set the QI flag when it detects that the packet reception rate is greater than the upstream transmission rate. The CM MUST clear the QI flag when it detects that the packet reception rate is equal to or less than the upstream transmission rate and the queued packet backlog is cleared. The number of packets already queued for upstream transmission is a measure of the rate differential between received and transmitted packets. The CM SHOULD set the QI flag when the number of packets queued is greater than the number of Grants per interval parameter of the Active QoS set. The CM SHOULD clear the QI flag when the number of packets queued is less than or equal to the number of Grants per interval parameter of the Active QoS set. The QI flag of each packet MAY be set either at the time the packet is received and queued or at the time the packet is dequeued and transmitted. The CM MAY set/clear the QI flag using a threshold of two times the number of Grants per Interval parameter of the Active QoS set. Alternatively, the CM MAY provide hysteresis by setting the QI flag using a threshold of two times the number of Grants per Interval, then clearing it using a threshold of one times the number of Grants per Interval.1 The CMTS MUST NOT allocate more grants per Nominal Grant Interval than the Grants Per Interval parameter of the Active QoS Parameter Set, excluding the case when the QI bit of the UGSH is set. In this case, the CMTS SHOULD grant up to 1% additional bandwidth for clock rate mismatch compensation. If the CMTS grants additional bandwidth, it MUST limit the total number of bytes forwarded on the flow during any time interval to Max(T), as described in the expression Max(T) = T * (R*1.01) + 3B Where Max(T) is the maximum number of bytes transmitted on the flow over a time T (in units of seconds), R = (grant_size * grants_per_interval)/nominal_grant_interval, and B = grant_size*grants_per_interval.

1.

Replaced existing paragraph with the four previous paragraphs per ECN RFIv2.0-N-03.0110-2 by GO on 2/ 11/04.

220

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The active grants field of the UGSH is ignored with UGS service. The CMTS policing of the Service Flow remains unchanged.
10.2.2 Real-Time Polling Service

The Real-Time Polling Service (rtPS) is designed to support real-time service flows that generate variable size data packets on a periodic basis, such as MPEG video. The service offers real-time, periodic, unicast request opportunities, which meet the flows real-time needs and allow the CM to specify the size of the desired grant. This service requires more request overhead than UGS, but supports variable grant sizes for optimum data transport efficiency. The CMTS MUST provide periodic unicast request opportunities. In order for this service to work correctly, the Request/Transmission Policy setting (refer to Annex C.2.2.6.3) SHOULD be such that the CM is prohibited from using any contention request or request/data opportunities. The Request/Transmission Policy SHOULD also prohibit piggyback requests. The CMTS MAY issue unicast request opportunities as prescribed by this service even if a grant is pending. This will result in the CM using only unicast request opportunities in order to obtain upstream transmission opportunities (the CM could still use unsolicited data grants for upstream transmission as well). All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service parameters are the Nominal Polling Interval, the Tolerated Poll Jitter and the Request/Transmission Policy.
10.2.3 Unsolicited Grant Service with Activity Detection

The Unsolicited Grant Service with Activity Detection (UGS/AD) is designed to support UGS flows that may become inactive for substantial portions of time (i.e., tens of milliseconds or more), such as Voice over IP with silence suppression. The service provides Unsolicited Grants when the flow is active and unicast polls when the flow is inactive. This combines the low overhead and low latency of UGS with the efficiency of rtPS. Though USG/AD combines UGS and rtPS, only one scheduling service is active at a time. The CMTS MUST provide periodic unicast grants, when the flow is active, but MUST revert to providing periodic unicast request opportunities when the flow is inactive. [The CMTS can detect flow inactivity by detecting unused grants. However, the algorithm for detecting a flow changing from an active to an inactive state is dependent on the CMTS implementation]. In order for this service to work correctly, the Request/Transmission Policy setting (refer to Annex C.2.2.6.3) MUST be such that the CM is prohibited from using any contention request or request/data opportunities. The Request/Transmission Policy MUST also prohibit piggyback requests. This results in the CM using only unicast request opportunities in order to obtain upstream transmission opportunities. However, the CM will use unsolicited data grants for upstream transmission as well. All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service parameters are the Nominal Polling Interval, the Tolerated Poll Jitter, the Nominal Grant Interval, the Tolerated Grant Jitter, the Unsolicited Grant Size and the Request/Transmission Policy. In UGS-AD service, when restarting UGS after an interval of rtPS, the CMTS SHOULD provide additional grants in the first (and/or second) grant interval such that the CM receives a total of one grant for each grant interval from the time the CM requested restart of UGS, plus one additional grant. (Refer to Appendix VI) Because the Service Flow is provisioned as a UGS flow with a specific grant interval and grant size, when restarting UGS, the CM MUST NOT request a different sized grant than the already provisioned UGS flow. As with any Service Flow, changes can only be requested with a DSC command. If the restarted activity requires

more than one grant per interval, the CM MUST indicate this in the Active Grants field of the UGSH beginning with the first packet sent.
The Service Flow Extended Header Element allows for the CM to dynamically state how many grants per interval are required to support the number of flows with activity present. In UGS/AD, the CM MAY use the
221

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Queue Indicator Bit in the UGSH. The remaining seven bits of the UGSH define the Active Grants field. This field defines the number of grants within a Nominal Grant Interval that this Service Flow currently requires. When using UGS/AD, the CM MUST indicate the number of requested grants per Nominal Grant Interval in this field. The Active Grants field of the UGSH is ignored with UGS without Activity Detection. This field allows the CM to signal to the CMTS to dynamically adjust the number of grants per interval that this UGS Service Flow is actually using. The CM MUST NOT request more than the number of Grants per Interval in the ActiveQoSParameterSet. If the CMTS allocates additional bandwidth in response to the QI bit, it MUST use the same rate limiting formula as UGS, but the formula only applies to steady state periods where the CMTS has adjusted the grants_per_interval to match the active_grants requested by the CM. When the CM is receiving unsolicited grants and it detects no activity on the Service Flow, it MAY send one packet with the Active Grants field set to zero grants and then cease transmission. Because this packet may not be received by the CMTS, when the Service Flow goes from inactive to active the CM MUST be able to restart transmission with either polled requests or unsolicited grants.
10.2.4 Non-Real-Time Polling Service

The Non-Real-Time Polling Service (nrtPS) is designed to support non real-time service flows that require variable size data grants on a regular basis, such as high bandwidth FTP. The service offers unicast polls on a regular basis which assures that the flow receives request opportunities even during network congestion. The CMTS typically polls nrtPS SIDs on an (periodic or non-periodic) interval on the order of one second or less. The CMTS MUST provide timely unicast request opportunities. In order for this service to work correctly, the Request/Transmission Policy setting (refer to Annex C.2.2.6.2) SHOULD be such that the CM is allowed to use contention request opportunities. This will result in the CM using contention request opportunities as well as unicast request opportunities and unsolicited data grants. All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service parameters are Nominal Polling Interval, Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Request/Transmission Policy and Traffic Priority.
10.2.5 Best Effort Service

The intent of the Best Effort (BE) service is to provide efficient service to best effort traffic. In order for this service to work correctly, the Request/Transmission Policy setting SHOULD be such that the CM is allowed to use contention request opportunities. This will result in the CM using contention request opportunities as well as unicast request opportunities and unsolicited data grants. All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service parameters are the Minimum Reserved Traffic Rate, the Maximum Sustained Traffic Rate, and the Traffic Priority.
10.2.6 10.2.6.1 Other Services Committed Information Rate (CIR)

A Committed Information Rate (CIR) service can be defined a number of different ways. For example, it could be configured by using a Best Effort service with a Minimum Reserved Traffic Rate or a nrtPS with a Minimum Reserved Traffic Rate.

222

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10.2.7

Parameter Applicability for Upstream Service Scheduling

Table 10-4 summarizes the relationship between the scheduling services and key QoS parameters. A detailed description of each QoS parameter is provided in Annex C.
Table 10-4 Parameter Applicability for Upstream Service Scheduling1
Service Flow Parameter Best Effort Non-RealTime Polling Real-Time Polling N/Aa Optional Mandatory Mandatory Unsolicited Grant Unsolicited Grant with Activity Det. N/A N/A Mandatory Mandatory

Miscellaneous Traffic Priority Max Concatenated Burst Upstream Scheduling Service Type Request/Transmission Policy Maximum Rate Max Sustained Traffic Rate Max Traffic Burst Minimum Rate Min Reserved Traffic Rate Assumed Minimum Packet Size Grants Unsolicited Grant Size Grants per Interval Nominal Grant Interval Tolerated Grant Jitter Polls Nominal Polling Interval Tolerated Poll Jitter

Optional Default = 0 Optional Optional Default = 2 Optional Default = 0 Optional Default = 0 Optional Dflt = 3044 Optional Default = 0 Optional*

Optional Default = 0 Optional Mandatory Mandatory

N/A N/A Mandatory Mandatory

Optional Default = 0 Optional Dflt = 3044 Optional Default = 0 Optional*

Optional Default = 0 Optional Dflt = 3044 Optional Default = 0 Optional*

N/A N/A

N/A N/A

N/A Optional*

N/A Optional*

N/A N/A N/A N/A N/A N/A

N/A N/A N/A N/A Optional* N/A

N/A N/A N/A N/A Mandatory Optional*

Mandatory Mandatory Mandatory Mandatory N/A N/A

Mandatory Mandatory Mandatory Mandatory Optionalb Optional*

a N/A means not applicable to this service flow scheduling type. If included in a request for a service flow of this service flow scheduling type, this request MUST be denied. b Default is same as Nominal Grant Interval * Default is CMTS-specific
10.2.8 CM Transmit Behavior

In order for these services to function correctly, all that is required of the CM in regards to its transmit behavior for a service flow, is for it to follow the rules specified in Section 9.4.3 and the Request/Transmission Policy specified for the service flow.

1.

Revised row nine of table Dflt = 1522 to Dflt = 3044, per ECN RFI2-N-02210, by GO, on 11/21/02.

223

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

10.3 Fragmentation
Fragmentation is an upstream CM modem capability. The CMTS MUST enable or disable this capability on a per-modem basis with a TLV in the Registration Response. The per-modem basis provides compatibility with DOCSIS1.0 CMs. Once fragmentation is enabled for a DOCSIS 1.1 modem, fragmentation is enabled on a perService Flow basis via the Request/Transmission Policy Configuration Settings. When enabled for a Service Flow, fragmentation is initiated by the CMTS when it grants bandwidth to a particular CM with a grant size that is smaller than the corresponding bandwidth request from the CM. This is known as a Partial Grant.
10.3.1 CM Fragmentation Support

Fragmentation is essentially encapsulation of a portion of a MAC Frame within a fixed size fragmentation header and a fragment CRC. Concatenated PDUs, as well as single PDUs, are encapsulated in the same manner. Baseline Privacy, if enabled, is performed on each fragment as opposed to the complete original MAC frame. The CM MUST perform fragmentation according to the flow diagram in Figure 10-8. The phrase untransmitted portion of packet in the flow diagram refers to the entire MAC frame when fragmentation has not been initiated and to the remaining untransmitted portion of the original MAC frame when fragmentation has been initiated.
10.3.1.1 Fragmentation Rules:

1. Any time fragmentation is enabled and the grant size is smaller than the request, the CM MUST fill the partial grant it receives with the maximum amount of data (fragment payload) possible accounting for fragmentation overhead and physical layer overhead. 2. The CM MUST send up a piggyback request any time there is no later grant or grant pending for that SID in MAPs that have been received at the CM. 3. If the CM is fragmenting a frame,1 any piggyback request for the next fragment MUST be made in the BPI EHDR portion of the fragment header. Any piggyback request for a subsequent frame SHOULD be made in the BPI EHDR portion of the last fragment, but MAY be made in one of the extended headers inside the original frame. However, the same request MUST NOT be made in more than one place. Because the CMTS could ignore a request inside the original frame, making the request in the original frame may cause a loss of the request.2 4. In calculating bandwidth requests for the remainder of the frame (concatenated frame, if concatenated) that has been fragmented, the CM MUST request enough bandwidth to transmit the entire remainder of the frame plus the 16-byte fragment overhead and all associated physical layer overhead. 5. If the CM does not receive a grant or grant pending within the ACK time of sending a request, the CM MUST backoff and re-request for the untransmitted portion of the frame until the bandwidth is granted or the CM exceeds its retry threshold. 6. If the CM exceeds its retry threshold while requesting bandwidth, the CM discards whatever portion of the frame was not previously transmitted. 7. The CM MUST set the F bit and clear the L bit in the first fragment of a frame. 8. The CM MUST clear the F and L bits in the fragment header for any fragments that occur between the first and last fragments of a frame. 9. The CM MUST set the L bit and clear the F bit in the last fragment of a frame.

1. 2.

Frame always refers to either frames with a single Packet PDU or concatenated frames. Rule 3), last three sentences added per RFI2-N-02093 by RKV on 10/28/02.

224

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10. The CM MUST increment the fragment sequence number sequentially for each fragment of a frame transmitted. 11. If a frame is to be encrypted and the frame is fragmented, the frame is encrypted only at the fragment layer with encryption beginning immediately after the fragment header HCS and continuing through the fragment CRC. 12. Frames sent in immediate data (request/data) regions MUST NOT be fragmented.

225

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Start Discard untransmitted portion of frame Await Frame Arrival

Yes Backoff and re-request for untransmitted portion of frame

Backoff if necessary and request bandwidth for Sid X

Retries Exhausted?

No

Process MAP Information Elements No Yes Yes No Send untransmitted portion of frame with piggyback field(s)=0

Ack Timer Expired?

Grant Pending?

No

Grant for Sid X?

Yes No Grant smaller than Request or Request Remainder? No Another frame in queue? Yes Send untransmitted portion of frame with request for next frame in piggyback field

Yes

Fragmentation allowed for this SID?

No

Discard Grant or Send up request in granted slot

Yes Calculate amount to fragment and bandwidth needed to transmit remainder (Request Remainder)

Another Grant or Grant Pending in MAP queue?

No

Send fragment with piggyback field set to request remainder

Yes Send fragment with zero in the piggyback field

Figure 10-8 CM Fragmentation Flowchart1

1.

Revised Figure 10-8 per ECN RFI2-N-02215, by GO, on 12/02/02.

226

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

10.3.2

CMTS Fragmentation Support

At the CMTS, the fragment is processed similarly to an ordinary packet with the exception that the baseline privacy encryption starts just after the fragmentation header as opposed to being offset by 12 bytes. The CMTS has two modes it can use to perform fragmentation. The Multiple Grant Mode assumes that the CMTS retains the state of the fragmentation. This mode allows the CMTS to have multiple partial grants outstanding for any given SID. The Piggybacking Mode assumes the CMTS does NOT retain any fragmentation state. Only one partial grant is outstanding, so that the CM inserts the remaining amount into the Piggyback field of the fragment header. The type of mode being used is determined by the CMTS. In all cases, the CM operates with a consistent set of rules. A CMTS MUST support Multiple Grant Mode or Piggyback Mode for performing fragmentation. A CMTS MAY support both fragmentation modes.1
10.3.2.1 Multiple Grant Mode2

Multiple Grant Mode allows the CMTS to break a request up into two or more grants in a single or over successive maps and it calculates the additional overhead required in the remaining partial grants to satisfy the request. In Multiple Grant Mode, if the CMTS cannot grant the remainder in the current MAP, it MUST send a grant pending (zero length grant) in the current MAP and all subsequent MAPs to the CM until it can grant additional bandwidth. If there is no grant or grant pending in subsequent MAPs, the CM MUST re-request for the remainder. This re-request mechanism is the same as that used when a normal REQ does not receive a grant or grant pending within the ACK time. If a CM receives a grant pending IE along with a fragment grant, it MUST NOT piggyback a request in the extended header of the fragment transmitted in that grant. In the case where the CM misses a grant and re-requests the remaining bandwidth, the CMTS MUST recover without dropping the frame. Due to the imprecision of the mini-slot to byte conversion process the CMTS may not be able to calculate exactly the number of extra mini-slots needed to allow for fragmentation overhead. Also because it is possible for a CM to have missed a map with a partial grant, and thus to be requesting to send an unsent fragment rather than a new PDU, the CMTS can not be certain whether the CM has already accounted for fragmentation overhead in a request. Therefore the CMTS MUST make sure that any fragment payload remainder is at least one mini-slot greater than the number of mini-slots needed to contain the overhead for a fragment (16 bytes) plus the physical layer overhead necessary to transmit a minimum sized fragment. Failure to do this may cause the CMTS to issue a grant that is not needed as the CM has completed transmission of the fragment payload remainder using the previous partial grant. This may cause the CM to get out of sync with the CMTS by inadvertently starting a new fragmentation. Also the CMTS needs to deal with the fact that with certain sets of physical layer parameters, the CM may request one more mini-slot than the maximum size of a short data grant, but not actually need that many mini-slots. This happens in the case where the CM needs to push the request size beyond the short data grant limit. The CMTS needs a policy to ensure that fragmenting such requests in multiple grant mode does not lead to unneeded fragmentary grants.

1. 2.

Added this paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/21/04. Deleted previous first paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/21/04.

227

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

10.3.2.2

Piggyback Mode1

If the CMTS does not put another partial grant or a grant pending in the MAP in which it initiates fragmentation on a SID, the CM MUST automatically piggyback for the remainder. The CM calculates how much of a frame can be sent in the granted bandwidth and forms a fragment to send it. The CM utilizes the piggyback field in the fragment extended header to request the bandwidth necessary to transfer the remainder of the frame. Since the CMTS did not indicate a multiple grant in the first fragment MAP, the CM MUST keep track of the remainder to send. The request length, including physical-layer and fragmentation overhead, for the remainder of the original frame is inserted into the piggyback request byte in the fragmentation header. If the fragment HCS is correct, the piggybacked request, if present, is passed on to the bandwidth allocation process while the fragment itself is enqueued for reassembly. Once the complete MAC frame is reassembled and it has been determined that the HCS is correct, the CMTS processes the frame as though it had been received unfragmented except that the CMTS MUST ignore the decryption related portion of any privacy EHDRs. However, the bandwidth requests in privacy EHDRs and request EHDRs of such frame SHOULD be processed, but they MAY be ignored also.2
10.3.3 10.3.3.1 Fragmentation Example Single Packet Fragmentation

Refer to Figure 10-8. Assume that fragmentation has been enabled for a given SID. 1. (Requesting State)- CM wants to transmit a 1018 byte packet. CM calculates how much physical layer overhead (POH) is required and requests the appropriate number of mini-slots. CM makes a request in a contention region. Go to step 2. 2. (Waiting for Grant)- CM monitors MAPs for a grant or grant pending for this SID. If the CMs ACK time expires before the CM receives a grant or grant pending, the CM retries requesting for the packet until the retry count is exhausted - then the CM gives up on that packet. Go to step 3. 3. (First Fragment)- Prior to giving up in step 2, the CM sees a grant for this SID that is less than the requested number of mini-slots. The CM calculates how much MAC information can be sent in the granted number of mini-slots using the specified burst profile. In the example in Figure 10-9, the first grant can hold 900 bytes after subtracting the POH. Since the fragment overhead (FRAG HDR, FHCS, and FCRC) is 16 bytes, 884 bytes of the original packet can be carried in the fragment. The CM creates a fragment composed of the FRAG HDR, FHCS, 884 bytes of the original packet, and an FCRC. The CM marks the fragment as first and prepares to send the fragment. Go to step 4. 4. (First Fragment, multiple grant mode)- CM looks to see if there are any other grants or grant pendings enqueued for this SID. If so, the CM sends the fragment with the piggyback field in the FRAG HDR set to zero and awaits the time of the subsequent grant to roll around. Go to step 6. If there are not any grants or grant pendings, go to step 5. 5. (First Fragment, piggyback mode)- If there are no other grants or grant pendings for this SID in this MAP, the CM calculates how many mini-slots are required to send the remainder of the fragmented packet, including the fragmentation overhead, and physical layer overhead, and inserts this amount into the piggyback field of the FRAG HDR. The CM then sends the fragment and starts its ACK timer for the piggyback request. In the example in Figure 10-9, the CM sends up a request for enough mini-slots to hold the POH plus 150 bytes (1018-884+16). Go to step 6.

1. 2.

Deleted previous first paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/21/04. Last two sentences updated per RFI2-N-02093 by RKV on 10/28/02.

228

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

6. (Waiting for Grant)- The CM is now waiting for a grant for the next fragment. If the CMs ACK timer expires while waiting on this grant, the CM should send up a request for enough mini-slots to send the remainder of the fragmented packet, including the fragmentation overhead, and physical layer overhead. Go to step 7. 7. (Receives next fragment grant)- Prior to giving up in step 6, the CM sees another grant for this SID. The CM checks to see if the grant size is large enough to hold the remainder of the fragmented packet, including the fragmentation overhead and physical layer overhead. If so, go to step 10. If not, go to step 8. 8. (Middle Fragment, multiple grant mode)- Since the remainder of the packet (plus overhead) will not fit in the grant, the CM calculates what portion will fit. The CM encapsulates this portion of the packet as a middle fragment. The CM then looks for any other grants or grant pendings enqueued for this SID. If either are present, the CM sends the fragment with the piggyback field in the FRAG HDR set to zero and awaits the time of the subsequent grant to roll around. Go to step 6. If there are not any grants or grant pendings, go to step 9. 9. (Middle Fragment, piggyback mode) - The CM calculates how many mini-slots are required to send the remainder of the fragmented packet, including the fragmentation overhead and physical layer overhead, and inserts this amount into the piggyback field of the FRAG HDR. The CM then sends the fragment and starts its ACK timer for the piggyback request. Go to step 6. 10. (Last Fragment) - The CM encapsulates the remainder of the packet as a last fragment. If there is no other packet enqueued or there is a another grant or a grant pending enqueued for this SID, the CM places a zero in the REQ field of the FRAG HDR. If there is another packet enqueued with no grant of grant pending, the CM calculates the number of mini-slots required to send the next packet and places this number in the REQ field in the FRAG HDR. The CM then transmits the packet. Go to step 11. In the example in Figure 10-9, the grant is large enough to hold the remaining 150 bytes plus POH. 11. (Normal operation)- The CM then returns the normal operation of waiting for grants and requesting for packets. If at any time fragmentation is enabled and a grant arrives that is smaller than the request, the fragmentation process starts again as in step 2.

229

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Fragment Payload Original Packet with BPI EHDR (1018 Bytes) 1B FC 1B PARM 2B LEN 4B PRV 4B other EHDRs 2B HCS 1000B PDU payload 4B PCRC

884 (900-16) Bytes sent in first fragment 134 (1018-884) Bytes sent in last fragment

First Grant can fit 900 bytes of MAC information

10B

2B

1B

1B

2B LEN

4B

4B

2B

870B

4B

FRAG HDR FHCS FC PARM

PRV other EHDRs HCS

PDU payload (first) FCRC

Encrypted under Baseline Privacy 1B FC 1B EHDR LEN = 6 2B LEN 6B BPI EHDR

11

00011

1B 35

1B

2B

1B

1B Frag Cntl

Ver E|T|OoS_SID RQ

Request for enough minislots to fit 150 (130+4+16) bytes of MAC info. This field would be zero in multiple grant mode.

00100000

Second Grant can fit 150 bytes of MAC information

10B

2B

130B

4B

4B

FRAG HDR FHCS PDU payload (cont) PCRC FCRC Encrypted under Baseline Privacy Frag Cntl Bit Definition XXFLSSSS

FC

EHDR LEN = 6

LEN

BPI EHDR

F - Set on First fragment, clear otherwise L - Set on Last fragment, clear otherwise SSSS - 4 bit sequence number, increments on each fragment of a frame, rolling over as necessary XX - Reserved, set to 00

11

00011

1 35

1B

2B

1B

1B Frag Cntl

Ver E|T|OoS_SID RQ

Piggyback request for next PDU (if applicable)

00010001

Figure 10-9

Example of Fragmenting a Single Packet

10.3.3.2

Concatenated Packet Fragmentation

After the CM creates the concatenated packet, the CM treats the concatenated packet as a single PDU. Figure 1010 shows an example of a concatenated packet broken into 3 fragments. Note that the packet is fragmented without regard to the packet boundaries within the concatenated packet.

230

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Original Concatenated Packet (287) Bytes 6B 15B 68B 4B 6B 100B 4B 10B 70B 4B

Concat. HDR MAC HDR1 PDU payload 1 PCRC1 MAC HDR2 PDU payload 2 PCRC2 MAC HDR3 PDU payload 3 PCRC3 1B FC 1B EHDR LEN = 6 2B LEN 10B 2B HCS 1B 5B 2B

1B

2B

4B

FC PARM LEN PRV other EHDRs HCS 6B 68B 4B 6B 10B 4B

First Grant can fit 125 bytes of MAC information 1B

2B

15B

FRAG HDR FHCS Concat. HDR MAC HDR1 PDU payload 1 PCRC1 MAC HDR2 PDU payload 2 (part1) FCRC Encrypted under Baseline Privacy

1B EHDR FC LEN = 6

2B LEN

6B BPI EHDR 1B 1B 01 2B 1B 1B Frag Cntl

11

00011

1 35 E|T|QoS_SID RQ
Request for enough minislots to fit 162 (287-109+16) bytes of MAC info. This field would be zero in multiple grant mode.

00100000

Second Grant can fit 146 bytes of MAC information 1B

10B

2B

90B

4B

10B

26B

4B

FRAG HDR FHCS 2B LEN

PDU payld 2 (part) PCRC2 MAC HDR3 PDU payld 3 (part) FCRC 6B BPI EHDR 1B 1B 01 2B 1B 1B Frag Cntl Encrypted under Baseline Privacy

1B EHDR FC LEN = 6

11

00011

35

E|T|QoS_SID RQ

Request for enough minislots to fit 64 (287-109-130+16) bytes of MAC info. This field would be zero in multiple grant mode.

00000001

Third Grant can fit 64 bytes of MAC information 1B FC

10B

2B

44B

4B

4B

FRAG HDR FHCS 1B EHDR LEN = 6 2B LEN

PDU payld 3 (part) PCRC3 FCRC 6B BPI EHDR 1B 1B 01 2B 1B 1B Frag Cntl Encrypted under Baseline Privacy

11

00011

35

E|T|QoS_SID RQ

Request for packet

00010010

Figure 10-10

Fragmented Concatenated Packet Example

231

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

10.4 Payload Header Suppression

The overview section explains the principles of Payload Header Suppression. The subsequent sections explain the signaling for initialization, operation, and termination. Finally, specific upstream and downstream examples are given. The following definitions are used:
Table 10-5 Payload Header Suppression Definitions

PHS PHS Rule PHSF

Payload Header Suppression Payload Header Suppression Rule Payload Header Suppression Field

Suppressing an initial byte string at the sender and restoring the byte string at the receiver. A set of TLVs that apply to a specific PHS Index. A string of bytes representing the header portion of a PDU in which one or more bytes will be suppressed (i.e., a snapshot of the uncompressed PDU header inclusive of suppressed and unsuppressed bytes). An 8-bit value which references the suppressed byte string. A bit mask which indicates which bytes in the PHSF to suppress, and which bytes to not suppress. The length of the Suppressed Field in bytes. This value is equivalent to the number of bytes in the PHSF and also the number of valid bits in the PHSM A flag which tells the sending entity to verify all bytes which are to be suppressed.

PHSI PHSM PHSS

Payload Header Suppression Index Payload Header Suppression Mask Payload Header Suppression Size

PHSV

Payload Header Suppression Verify

10.4.1

Overview

In Payload Header Suppression, a repetitive portion of the payload headers following the Extended Header field is suppressed by the sending entity and restored by the receiving entity. In the upstream, the sending entity is the CM and the receiving entity is the CMTS. In the downstream, the sending entity is the CMTS and the receiving entity is the CM. The MAC Extended Header contains a Payload Header Suppression Index (PHSI) which references the Payload Header Suppression Field (PHSF). Although PHS may be used with any Service Flow Type, it has been designed for use with the Unsolicited Grant Service (UGS) Scheduling Type. UGS works most efficiently with packets of a fixed length. PHS works well with UGS because, unlike other header compression schemes sometimes used with IP data, PHS always suppresses the same number of bytes in each packet. PHS will always produce a fixed length compressed packet header. The sending entity uses Classifiers to map packets into a Service Flow. The Classifier uniquely maps packets to its associated Payload Header Suppression Rule. The receiving entity uses the Service Identifier (SID) and the PHSI to restore the PHSR. Once the PHSF and PHSS fields of a rule are known, the rule is considered fully defined and none of its fields can be changed. If modified PHS operation is desired for packets classified to the flow, the old rule must be removed from the Service Flow, and a new rule must be installed. When a classifier is deleted, any associated PHS rule MUST also be deleted.

232

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

PHS has a PHSV option to verify or not verify the payload before suppressing it. PHS also has a PHSM option to allow select bytes not to be suppressed. This is used for sending bytes which change such as IP sequence numbers, and still suppressing bytes which do not change. PHS rules are consistent for all scheduling service types. Requests and grants of bandwidth are specified after suppression has been accounted for. For Unsolicited Grant Services, the grant size is chosen with the Unsolicited Grant Size TLV. The packet with its header suppressed may be equal to or less than the grant size. The CMTS MUST assign all PHSI values just as it assigns all SID values. Either the sending or the receiving entity MAY specify the PHSF and PHSS. This provision allows for pre-configured headers, or for higher level signaling protocols outside the scope of this specification to establish cache entries. PHS is intended for unicast service, and is not defined for multicast service. It is the responsibility of the higher-layer service entity to generate a PHS Rule which uniquely identifies the suppressed header within the Service Flow. It is also the responsibility of the higher-layer service entity to guarantee that the byte strings being suppressed are constant from packet to packet for the duration of the Active Service Flow.
10.4.2 Example Applications

A Classifier on an upstream Service Flow which uniquely defines a Voice-over-IP (VoIP) flow by specifying
Protocol Type of UDP, IP SA, IP DA, UDP Source Port, UDP Destination Port, the Service Flow Reference, and a PHS Size of 42 bytes. A PHS Rule references this Classifier providing a PHSI value which identifies this VoIP media flow. For the upstream case, 42 bytes of payload header are verified and suppressed, and a 2 byte extended header containing the PHSI is added to every packet in that media flow.

A Classifier which identifies the packets in a Service Flow, of which 90% match the PHSR. Verification is
enabled. This may apply in a packet compression situation where every so often compression resets are done and the header varies. In this example, the scheduling algorithm would allow variable bandwidth, and only 90% of the packets might get their headers suppressed. Since the existence of the PHSI extended header will indicate the choice made, the simple SID/PHSI lookup at the receiving entity will always yield the correct result.

A Classifier on an upstream Service Flow which identifies all IP packets by specifying Ethertype of IP, the
Service Flow ID, a PHSS of 14 bytes, and no verification by the sending entity. In this example, the CMTS has decided to route the packet, and knows that it will not require the first 14 bytes of the Ethernet header, even though some parts such as the Source Address or Destination Address may vary. The CM removes 14 bytes from each upstream frame (Ethernet Header) without verifying their contents and forwards the frame to the Service Flow.
10.4.3 Operation

To clarify operational packet flow, this section describes one potential implementation. CM and CMTS implementations are free to implement Payload Header Suppression in any manner as long as the protocol specified in this section is followed. Figure 10-11 illustrates the following procedure. A packet is submitted to the CM MAC Service Layer. The CM applies its list of Classifier rules. A match of the rule will result in an Upstream Service Flow, SID, and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM, PHSS, and PHSV. If PHSV is set to zero, or is not present, the CM will compare the bytes in the packet header with the bytes in the PHSF that are to be suppressed as indicated by the PHSM. If they match, the CM will suppress all the bytes in the Upstream Suppression Field except the bytes masked by PHSM. The CM will then insert the PHSI into the PHS_Parm field of the Service Flow EH Element, and queue the packet on the Upstream Service Flow.

233

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

When the packet is received by the CMTS, the CMTS will determine the associated SID either by internal means or from other Extended Headers elements such as the BPI Extended Header. The CMTS uses the SID and the PHSI to look up PHSF, PHSM, and PHSS. The CMTS reassembles the packet and then proceeds with normal packet processing. The reassembled packet will contain bytes from the PHSF. If verification was enabled, then the PHSF bytes will equal the original header byes. If verification was not enabled, then there is no guarantee that the PHSF bytes will match the original header bytes.

Sender PHS Start

Receiver PHS Start

Packet Arrives

Packet Arrives

Classify Packet. Retrieve PHSF, PHSI, PHSM, PHSS, PHSV

Identify SID and extract PHSI

Verify?

Retrieve PHSF, PHSM, PHSS

Yes Verify with PHSF Reconstruct Header and forward packet

No Pass Verify? Forward Packet

Yes Suppress with PHSM Append PHSI No END

Forward Packet

END

Figure 10-11 Payload Header Suppression Operation

234

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A similar operation occurs in the downstream. The CMTS applies its list of Classifiers. A match of the Classifier will result in a Downstream Service Flow and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM, PHSS, and PHSV. If PHSV is set to zero, or is not present, the CMTS will verify the Downstream Suppression Field in the packet with the PHSF. If they match, the CMTS will suppress all the bytes in the Downstream Suppression Field except the bytes masked by PHSM. The CMTS will then insert the PHSI into the PHS_Parm field of the Service Flow EH Element, and queue the packet on the Downstream Service Flow. The CM will receive the packet based upon the Ethernet Destination Address filtering. The CM then uses the PHSI to lookup PHSF, PHSM, and PHSS. The CM reassembles the packet and then proceeds with normal packet processing. Figure 10-12 demonstrates packet suppression and restoration when using PHS masking. Masking allows only bytes which do not change to be suppressed. Note that the PHSF and PHSM span the entire Suppression Field, including suppressed and unsuppressed bytes.

B 0 X

C 1 C'

D 0 X

E 1 = Verify E' = Assign

Sender

PHSM PHSF

1 A'

Cable Network

D A - E = current header A' - E' = cached header X = don't care PHSS = 5

PHSM

1 A' A'

0 X B

1 C' C'

0 X D

1 E' E'

Receiver

PHSF

Figure 10-12 Payload Header Suppression with Masking

10.4.4

Signaling

Payload Header Suppression requires the creation of three objects:

Service Flow Classifier Payload Header Suppression Rule

These three objects MAY be created in separate message flows, or MAY be created simultaneously.

235

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

PHS Rules are created with Registration, DSA, or DSC messages. The CMTS MUST define the PHSI when the PHS Rule is created. PHS Rules are deleted with the DSC or DSD messages. The CM or CMTS MAY define the PHSS and PHSF. Figure 10-13 shows the two ways to signal the creation of a PHS Rule. It is possible to partially define a PHS rule (in particular the size of the rule) at the time a Service Flow is created. As an example, it is likely that when a Service Flow is first provisioned the size of the header field to be suppressed will be known. The values of some items within the field (e.g., IP addresses, UDP port numbers, etc.) may not be known and would be provided in a subsequent DSC as part of the activation of the Service Flow (using the Set PHS Rule DSC Action). A PHS rule is partially defined when the PHSF and PHSS field values are not both known. Once both PHSF and PHSS are known, the rule is considered fully defined, and MUST NOT be modified via DSC signaling. PHSV and PHSM fields have default values, thus are not required to fully define a PHS rule. If PHSV and PHSM are not known when the rule becomes fully defined, their default values are used, and MUST NOT be modified via DSC signaling. Each step of the PHS rule definition, whether it is a registration request, DSA or a DSC, MUST contain Service Flow ID (or reference), Classifier ID (or reference) to uniquely identify the PHS rule being defined. A PHS Index and Service ID pair is used to uniquely identify the PHS rule during upstream packet transfer. A PHS Index is enough to uniquely identify the PHS rule used in downstream packet transfer.
10.4.5 Payload Header Suppression Examples CMTS Initiated CM Initiated

CMTS
Classifier ID + Service Flow ID
DSC-REQ + PHSI + PHSS + PHSF

CM

CMTS
Classifier Reference/ ID + Service Flow ID + PHSS + PHSF
PHSI

CM

DSC-REQ

DSC-RSP

DSC-RSP

DSC-ACK

DSC-ACK

Figure 10-13 Payload Header Suppression Signaling Example

10.4.5.1

Upstream Example

A Service Class with the Service Class Name of G711-US-UGS-HS-42 is established which is intended for ITU-T Recommendation G.711 VoIP traffic in the upstream with Unsolicited Grant Service. When Classifiers are added to the flow, a PHSS value of 42 is included which explicitly states that the first 42 bytes following the MAC Extended Header on all packets in that flow must be verified, suppressed, and restored. In this example, the Service Class is configured such that any packet which does not verify correctly will not have its header suppressed and will be discarded since it will exceed the Unsolicited Grant Size. (Refer to Annex C.2.2.6.3)

236

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Figure 10-14 shows the encapsulation used in the upstream with and without Payload Header Suppression. An RTP Voice over IP Payload without IPsec is used as a specific example to demonstrate efficiency.

a. VolP with Normal Encapsulation

14-34 FGPS 4 5 2 14 20 IP 8 UDP 12 RTP 10 to 160 Voice Bytes 4 CRC

MAC OH BPI HCS Ethernet

values in bytes 14-34 FGPS 4 5 2 2 12 10 to 160 Voice Bytes 4 CRC

MAC OH BPI P HCS RTP

b. VolP with Header Suppression

Figure 10-14 Upstream Payload Header Suppression Example

Figure 10-14a. shows a normal RTP packet carried on an upstream channel. The beginning of the frame represents the physical layer overhead (FGPS) of FEC, guard time, preamble, and stuffing bytes. Stuffing bytes occur in the last code word and when mapping blocks to mini-slots. Next is the MAC layer overhead including the 6 byte MAC header with a 5 byte BPI Extended Header, the 14 byte Ethernet Header, and the 4 byte Ethernet CRC trailer. The VoIP payload uses a 20 byte IP header, an 8 byte UDP header, and a 12 byte RTP header. The voice payload is variable and depends upon the sample time and the compression algorithm used. Figure 10-14b. shows the same payload with Payload Header Suppression enabled. In the upstream, Payload Header Suppression begins with the first byte after the MAC Header Checksum. The 14 byte Ethernet header, the 20 byte IP header, and the 8 byte UDP header have been suppressed, and a 2 byte PHS Extended Header element has been added, for a net reduction of 40 bytes. In this example of an established VoIP connection, these fields remain constant from packet to packet, and are otherwise redundant.
10.4.5.2 Downstream Example

A Service Class with the Service Class Name of G711-DS-HS-30 is established which is intended for G.711 VoIP traffic in the downstream. When Classifiers are added to the Service Flow, a PHSS value of 30 is included which explicitly indicates that 30 bytes of the payload header on all packets must be processed for suppression and restoration according to the PHSM. Any packet which does not verify correctly will not have its header suppressed but will be transmitted subject to the traffic shaping rules in place for that Service Flow.

237

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Figure 10-15 shows the encapsulation used in the downstream with and without Payload Header Suppression. An RTP Voice over IP Payload without IPsec is used as a specific example to demonstrate efficiency.

a. VolP with Normal Encapsulation

4 5 2 6 6 2 20 IP 8 UDP 12 RTP 10 to 160 Voice Bytes 4 CRC

MAC OH BPI HCS DA SA T

12 RTP

10 to 160 Voice Bytes

4 CRC

values in bytes

MAC OH BPI P HCS DA SA

b. VolP with Header Suppression

Figure 10-15 Downstream Payload Header Suppression Example

Figure 10-15a. shows a normal RTP packet carried on a downstream channel. The Layer 2 overhead includes the 6 byte MAC header with a 5 byte BPI Extended Header, the 14-byte Ethernet Header (6-byte Destination Address, 6-byte Source Address, and 2-byte EtherType field), and the 4-byte Ethernet CRC trailer. The Layer 3 VoIP payload uses a 20-byte IP header, an 8 byte UDP header, and a 12-byte RTP header. The voice payload is variable and depends upon the sample time and the compression algorithm used. Figure 10-15b. shows the same payload with Payload Header Suppression enabled. In the downstream, Payload Header Suppression begins with the thirteenth byte after the MAC Header Checksum. This retains the Ethernet Destination Address and Source Address which is required so that the CM may filter and receive the packet. The remaining 2 bytes of the Ethernet Header, the 20-byte IP header, and the 8-byte UDP header have been suppressed, and a 2 byte PHS Extended Header element has been added, for a net reduction of 28-bytes. In this example of an established VoIP connection, these fields remain constant from packet to packet, and are thus redundant.

238

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11

Cable Modem - CMTS Interaction

This section covers the key requirements for the interaction between a CM and a CMTS. It only covers interaction between a CM and CMTS that are both compliant with this version of the specification, and only in the case where the CM is using a configuration file with QOS parameters compliant with this version of the specification. Issues involving interoperability with equipment and configuration files compliant with previous versions of this specification are discussed in Annex G. The interaction can be broken down into five basic categories: initialization, authentication, configuration, authorization, and signaling.

11.1

CMTS Initialization

The mechanism utilized for CMTS initialization (local terminal, file download, SNMP, etc.) is described in [DOCSIS5]. It MUST meet the following criteria for system interoperability.

The CMTS MUST be able to reboot and operate in a stand-alone mode using configuration data retained in
non-volatile storage.

If valid parameters are not available from non-volatile storage or via another mechanism such as the Spectrum Management System (see [SMS]), the CMTS MUST NOT generate any downstream messages (including SYNC). This will prevent CMs from transmitting.

The CMTS MUST provide the information defined in Section 8, Media Access Control Specification, on
page 111 to CMs for each upstream channel.

11.2

Cable Modem Initialization

The procedure for initialization of a cable modem MUST be as shown in Figure 11-1. This figure shows the overall flow between the stages of initialization in a CM. This shows no error paths, and is simply to provide an overview of the process. The more detailed finite state machine representations of the individual sections (including error paths) are shown in the subsequent figures. Timeout values are defined in Annex B. The procedure for initializing a cable modem and for a CM to reinitialize its MAC can be divided into the following phases:

Scanning and synchronization to downstream Obtain upstream parameters Ranging and automatic adjustments Device Class Identification (optional) Establish IP connectivity Establish time of day Transfer operational parameters Registration Baseline Privacy initialization, if CM is provisioned to run Baseline Privacy

Each CM contains the following information when shipped from the manufacturer:

A unique IEEE 802 48-bit MAC address which is assigned during the manufacturing process. This is used to
identify the modem to the various provisioning servers during initialization.

Security information as defined in [DOCSIS8] (e.g., X.509 certificate) used to authenticate the CM to the
security server and authenticate the responses from the security and provisioning servers.

239

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The SDL (Specification and Description Language) notation used in the following figures is shown in Figure 112 (refer to ITU-T Recommendation Z.100 [ITU-T Z.100])
.

Scan for Downstream Channel

Time of Day Established

Downstream Sync Established

Transfer Operational Parameters

Obtain Upstream Parameters

Transfer Complete

Upstream Parameters Aquired

Register with CMTS

Ranging & Automatic Adjustments

Registration Complete

Ranging & Auto Adj Complete

No

*1

*1:

Baseline Privacy enabled

Yes

Device Class Identification (optional)

Baseline Privacy Initialization

Establish IP Connectivity

Baseline Privacy Initialized

IP Complete

Operational

Establish Time of Day

Figure 11-1

CM Initialization Overview

240

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

State symbol

Input symbols

Internal

External

Task symbol

Internal Output symbols External

Decision symbol

Figure 11-2

SDL Notation

11.2.1

Scanning and Synchronization to Downstream

On initialization or a Reinitialize MAC operation, the cable modem MUST acquire a downstream channel. The CM MUST have non-volatile storage in which the last operational parameters are stored and MUST first try to re-acquire this downstream channel. If this fails, it MUST begin to continuously scan the 6-MHz channels of the downstream frequency band of operation until it finds a valid downstream signal. A downstream signal is considered to be valid when the modem has achieved the following steps:

synchronization of the QAM symbol timing synchronization of the FEC framing synchronization of the MPEG packetization recognition of SYNC downstream MAC messages

While scanning, it is desirable to give an indication to the user that the CM is doing so. In order to support redundant CMTS architectures, when a CM in the Operational state detects that the downstream signal is invalid (i.e., does not meet the four criteria above), the CM MUST NOT immediately perform a Reinitialize MAC operation. It must instead attempt to re-establish synchronization on the current downstream channel (see Section 11.5). Such re-establishment attempts MUST continue until the operation of Periodic Ranging as specified in Figure 11-17 of Section 11.3.1 calls for a Re-initialize MAC operation after the expiration of Timeout T4 or 16 expirations of Timeout T3. Figure 11-17 shows the procedure that MUST be followed by a cable modem during standard operation.
241

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

An interruption of downstream signal occurs when the following conditions are met -

The interruption occurs on a downstream that is valid (per sections 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9
and 6.3.10) before and after the loss.

The interruption is defined as an instantaneous loss of signal and after a predetermined delay, an
instantaneous return to the original signal fidelity.

The restored downstream signal is the original signal transmitted from the original source. The carrier frequency, physical plant, and path delays remain the same before and after the
interruption.

There are no changes in any downstream signaling parameter, including the modulation and the M/
N ratio, from before to after the interruption. When a CM in the Operational state in S-CDMA mode receives an interruption of downstream signal less than or equal to 5 msec, the CM MUST recover from the outage such that its fixed timing error is not greater than 0.02 of the nominal modulation interval (in addition to the allowed jitter defined in Section 6.2.21.8). When a CM in the Operational state in TDMA mode receives an interruption of downstream signal less than or equal to 5 msec, the CM MUST recover from the outage such that the first upstream transmission after the CM resumes normal operation is performed within an accuracy of +/- 250 nanoseconds plus +/- 0.5 symbols (refer to Section 6.2.19.1). In either mode, the CM MUST continue with normal operation within 2 sec from the end of the interruption. The CM is not required to continue normal operation if it receives a second interruption of downstream signal prior to the first receipt of a RNG-RSP with status "success". When a CM in the Operational state receives an interruption of downstream signal greater than 5 msec but less than the Lost Sync Interval (see Annex B), the CM MAY continue with normal operation as long as it recovers within 2 sec:

with a fixed timing error not greater than 0.02 of the nominal modulation interval (in addition to the
allowed jitter defined in Section 6.2.21.8) if the CM is in S-CDMA mode.

within the accuracy of Section 6.2.19.1 if the CM is in TDMA mode.

If the CM cannot recover according to the preceding recovery time, timing and jitter specifications, the CM MUST re-acquire upstream timing to an accuracy of at least 1 usec and be ready to respond to a ranging opportunity within 2 seconds, and MUST receive a RNG-RSP message with status "success" before resuming its upstream transmission. For the ranging process, the CM MAY use Broadcast or Unicast Initial Maintenance intervals, or Station Maintenance intervals, although a CM in S-CDMA mode MUST NOT use spreader-on Station Maintenance. For the ranging process, the CM MUST use its Primary SID in the INIT-RNG-REQ or RNG-REQ message and MUST use its known timing offset. After completing this ranging process by receiving RNG-RSP with the ranging status set to "success", the CM MUST return to normal operation. A CMTS MUST process INIT-RNG-REQ messages with a Primary SID from any CM that is in normal operation. If the Primary SID used by the CM in INIT-RNG-REQ is no longer valid, the CMTS SHOULD send a RNG-RSP message to the CM with the ranging status set to "abort". In all cases, after the first successful ranging opportunity subsequent to the interruption, the CM MUST meet the timing requirements specified in sections Section 6.2.19.1 and Section 6.2.21.8.1
11.2.2 Obtain Upstream Parameters

Refer to Figure 11-3. After synchronization, the CM MUST wait for an upstream channel descriptor message (UCD) from the CMTS in order to retrieve a set of transmission parameters for a possible upstream channel.

1.

Added this paragraph per ECN RFI2-N-03078 (supersedes RFI2-N-02227) by GO on 07/08/03.

242

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

These messages are transmitted periodically from the CMTS for all available upstream channels and are addressed to the MAC broadcast address. The CM MUST determine whether it can use the upstream channel from the channel description parameters. The CM MUST collect all UCDs with different channel ID fields to build a set of usable channel IDs. If no channel can be found after a suitable timeout period, the CM MUST continue scanning to find another downstream channel. The CM MUST determine whether it can use the upstream channel from the channel description parameters. If the channel is not suitable, the CM MUST try other channels until it finds a usable channel. Before attempting initial ranging on an upstream, the CM categorizes the available upstreams into the following types based on the UCD for each channel: 1. With a UCD (MAC management message type 2) offering DOCSIS 1.x burst descriptors only. 2. With a UCD (MAC management message type 2) offering both DOCSIS 2.0 TDMA and DOCSIS 1.x burst descriptors. 3. With a UCD (MAC management message type 29) for a DOCSIS 2.0 Only Upstream. The CM MUST have non-volatile storage in which channel ID of the last upstream on which the CM successfully completed registration is stored. If multiple upstreams are available, the CM MUST attempt to use the one that matches this stored channel ID. If none of the available upstreams match that stored ID, or if the CM is unable to successfully complete initial ranging on the matching channel, then the CM MUST preferentially select upstream channels in the following order. Type 3 channels are first, followed by type 2 channels, and type 1 channels are last. The CM MUST NOT begin initial ranging on a type 1 or type 2 upstream until it has allowed sufficient time, at least the UCD Interval (refer to Annex B), to determine if a type 3 upstream is available. If initial ranging fails on a type 3 upstream, the CM MUST ensure that it has allowed sufficient time to detect any other type 3 upstreams that are available before moving on to a type 2 or type 1 upstream. Of course, once the CM has waited enough time to ensure that it knows about any available type 3 upstreams, it will also know about any available type 2 upstreams and it MUST try them in preference to any type 1 upstreams. If the channel is suitable, the CM MUST extract the parameters for this upstream from the UCD. It then MUST wait for the next SYNC message and extract the upstream mini-slot timestamp from this message.1 The CM then MUST wait for a bandwidth allocation map for the selected channel. It may begin transmitting upstream in accordance with the MAC operation and the bandwidth allocation mechanism. The CM MUST perform initial ranging at least once, in accordance with Figure 11-6. If initial ranging is not successful, the next channel ID is selected, and the procedure restarted from UCD extraction. When there are no more channel IDs to try, the CM MUST continue scanning to find another downstream channel.

1.

Alternatively, since the SYNC message applies to all upstream channels, the CM may have already acquired a time reference from previous SYNC messages. If so, it need not wait for a new SYNC.

243

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Collect UCD Messages

Build channel list

Timeout T1 Yes End of channel list?

Select first channel

Scanning Select next channel Wait for usable UCD

Good upstream descriptor

Wait for SYNC

SYNC

Extract upstream minislot timing No

Wait for map for this channel

Map for selected channel

Initial Ranging

Initial Ranging Successful ?

Yes

Periodic Station Ranging Maintenance

Figure 11-3

Obtaining Upstream Parameters

244

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.2.3

Message Flows During Scanning and Upstream Parameter Acquisition

The CMTS MUST generate SYNC and UCD messages on the downstream at periodic intervals within the ranges defined in Annex B. These messages are addressed to all CMs. Refer to Figure 11-4.

CMTS

CM

clock time to send SYNC clock time to send UCD clock time to send SYNC

----------------SYNC--------------------> ----------------UCD----------------------> ----------------SYNC-------------------->

| | | | | Example of a UCD cycle | prior to CM power-on |

clock time to send SYNC

----------------SYNC-------------------->

| | | |

clock time to send SYNC

----------------SYNC-------------------->

| | |

clock time to send SYNC clock time to send UCD

----------------SYNC--------------------> ----------------UCD---------------------->

clock time to send SYNC

----------------SYNC--------------------> power on sequence complete

clock time to send SYNC

----------------SYNC--------------------> establish PHY synchronization & wait for UCD

clock time to send SYNC

----------------SYNC-------------------->

clock time to send SYNC clock time to send UCD

----------------SYNC--------------------> ----------------UCD----------------------> obtain parameters for this upstream channel to use for initialization

clock time to send SYNC

----------------SYNC--------------------> extract slot info for upstream & wait for transmit opportunity to perform ranging

clock time to send SYNC clock time to send MAP

----------------SYNC--------------------> ----------------MAP----------------------> start ranging process

Figure 11-4 Message Flows During Scanning and Upstream Parameter Acquisition

245

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.2.4

Ranging and Automatic Adjustments

The ranging and adjustment process is fully defined in Section 8 and in the following sections. The message sequence chart and the finite state machines on the following pages define the ranging and adjustment process which MUST be followed by compliant CMs and CMTSes. Refer to Figure 11-5 through Figure 11-8.
Note:

MAPs are transmitted as described in Section 8.

CMTS CM

[time to send the Initial Maintenance opportunity] send map containing Initial Maintenance information element with a broadcast/multicast Service ID -----------MAP------------>

<---------RNG-REQ or INITRNG-REQ------[receive recognizable ranging packet] allocate temporary Service ID send ranging response add temporary Service ID to poll list ----------RNG-RSP------->

transmit ranging packet in contention mode with Service ID parameter = 0

store temporary Service ID & adjust other parameters

[time to send the next map] send map with Station Maintenance information element or Unicast Initial Maintenance element to modem using temporary SID -----------MAP------------> recognize own temporary Service ID in map

<---------RNG-REQ------send ranging response [time to send an Initial Maintenance opportunity] send map containing Initial Maintenance information element with a broadcast/multicast Service ID send periodic transmit opportunity to broadcast address ------------MAP-----------> ----------RNG-RSP------->

reply to Station Maintenance opportunity poll or Unicast Initial Maintenance opportunity poll adjust local parameters

Figure 11-5

Ranging and Automatic Adjustments Procedure

Note: The CMTS MUST allow the CM sufficient time to have processed the previous RNG-RSP (i.e., to modify the transmitter parameters) before sending the CM a specific ranging opportunity. This is defined as CM Ranging Response Time in Annex B.

246

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Wait for broadcast maintenance opportunity

Time out T2

Map with maintenance opportunity

Error Re-initialize MAC

Backoff completed?

No

Wait for broadcast ranging opportunity

Yes Send RNG-REQ

Wait for RNG-RSP

Time out T3

RNG-RSP

Error Re-initialize MAC

Yes

Retries exhausted?

Adjust local parameters per RNG-RSP

No Wait for unicast maintenance opportunity

Adjust local power

Wait for broadcast ranging opportunity

Note: Timeout T3 may occur because the RNG-REQs from multiple modems collided. To avoid these modems repeating the loop in lockstep, a ramdom backoff is required. This is a backoff over the ranging window specified in the MAP. T3 timeouts can also occur during multi-channel operation. On a system with multiple upstream channels, the CM MUST attempt initial ranging on every suitable upstream channel, before moving to the next available downstream channel.

Figure 11-6
1.

Initial Ranging - CM1

Revised Figure 11-6 per ECN RFI2-N-02215 by GO on 12/02/02.

247

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Wait for unicast Maintenance Opportunity

Map with Maintenance opportunity Timeout T4 Send RNG-REQ Adjust transmit power No Wait for RNG-RSP

Timeout T3 No

RNG-RSP

Adjust parameters per RNG-RSP RNG-REQ retries exceeded? Abort ranging from CMTS? No Ranging Success (Note 1)

Yes

Yes Enable data transfer

Error: Re-initialize MAC

Establish IP layer

1.

Ranging Request is within the tolerance of the CMTS.

Figure 11-7

Unicast Initial Ranging - CM

248

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Wait for recognizable INIT-RNG-REQ or RNG-REQ

RNG-REQ

No SID assigned to this CM already? Yes Reset retry count in poll list for this CM Assign temporary SID

Add CM to poll list for future maps

Send RNG-RSP (continue)

Map will be sent per allocation algorithm and pending till complete. (see Note 2 below)

Wait for polled RNG-REQ

RNG-REQ not received RNG-REQ

No Retries Exhausted? No Yes

Good Enough? (Note 1)

Yes Send RNG-RSP (success)

Retries Exhausted? Yes Send RNG-RSP (abort) No Send RNG-RSP (continue) Remove CM from poll list

Remove CM from poll list

Start T9

Wait for recognizable RNG-REQ

Wait for polled RNG-REQ

Done

Figure 11-8
1. 2.

Initial Ranging - CMTS1

Means ranging is within the tolerable limits of the CMTS. RNG-REQ pending-till-complete was nonzero, the CMTS SHOULD hold off the station maintenance opportunity accordingly unless needed, for example, to adjust the CMs power level. If opportunities are offered prior to the pending-tillcomplete expiry, the good-enough test which follows receipt of a RNG-RSP MUST NOT judge the CMs transmit equalization until pending-till-complete expires.

1.

Added diagram block Start T9 to Figure 11-8, per ECN RFI2-N-02210 by GO on 11/21/02.

249

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.2.4.1 Ranging Parameter Adjustment

Adjustment of local parameters (e.g., transmit power) in a CM as a result of the receipt (or non-receipt) of an RNG-RSP is considered to be implementation-dependent with the following restrictions (refer to Section 8.3.6):

All parameters MUST be within the approved range at all times. Power adjustment MUST start from the minimum value unless a valid power is available from non-volatile
storage, in which case this MUST be used as a starting point.

Power adjustment MUST be capable of being reduced or increased by the specified amount in response to
RNG-RSP messages.

If, during initialization, power is increased to the maximum value (without a response from the CMTS) it
MUST wrap back to the minimum.

For multi-channel support, the CM MUST attempt initial ranging on every suitable upstream channel before
moving to the next available downstream channel.

For multi-channel support, the CM MUST use the upstream channel ID of the range response as specified in
Section 8.3.6 and in Appendix III.
11.2.5 Device Class Identification

After Ranging is complete and before establishing IP connectivity, the CM MAY identify itself to the CMTS for use in provisioning. Refer to Figure 11-9.

CM Send identification request to CMTS DCI-REQ

CMTS

Process request DCI-RSP Continue to establishing IP connectivity

Figure 11-9

Device Class Identification

If implemented, the CM MUST use an adaptive time out for device class identification based on binary exponential backoff, similar to that used for TFTP. Refer to Section 11.2.8, Transfer Operational Parameters, on page 252 for details.
11.2.6 Establish IP Connectivity

At this point, the CM MUST invoke DHCP mechanisms [RFC-2131] in order to obtain an IP address and any other parameters needed to establish IP connectivity (refer to Annex D). The DHCP response MUST contain the name of a file which contains further configuration parameters. Refer to Figure 11-10.

250

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM send DHCP request to broadcast address ----------------DHCP discover------------>

DHCP

check CM MAC address & respond <--------------DHCP offer ----------------choose server ----------------DHCP request--------------> process request <--------------DHCP response-------------set up IP parameters from DHCP response

Figure 11-10 Establishing IP Connectivity

As required in [RFC-2131], the CM MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The backoff algorithm SHOULD use a backoff start value of 4 seconds, a backoff end value of 64 seconds and randomized value of +/- 1 second. The CM MUST limit the number of retransmissions. The CM SHOULD limit the number of retransmissions (excluding the first transmission) to a maximum retries value of 5 but MAY implement less than the maximum retries value. The CM SHOULD also implement a different retransmission strategy for the RENEWING and REBINDING states, as recommended in [RFC-2131], which is based on one-half of the remaining lease time. Upon failure of obtaining or rebinding an IP address, the CM MUST attempt to establish communication on another upstream channel (see Section 11.2.2) or resume scanning to find another downstream channel (see Section 11.2.1).1
11.2.7 Establish Time of Day

The CM and CMTS need to have the current date and time. This is required for time-stamping logged events which can be retrieved by the management system. This need not be authenticated and need only be accurate to the nearest second.

1.

Added this paragraph per ECN RFI2-N-03085 by GO on 11/17/03.

251

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The protocol by which the time of day MUST be retrieved is defined in [RFC-868]. Refer to Figure 11-11. The request and response MUST be transferred using UDP. The time retrieved from the server (UTC) MUST be combined with the time offset received from the DHCP response to create the current local time.
CM Time Server

send request to time server ----------------time of day request------------> process request <--------------time of day response-------------set up / correct time of day from response

Figure 11-11 Establishing Time of Day

The DHCP server may offer a CM multiple Time of Day server IP addresses to attempt. The CM MUST attempt all Time of Day servers included in the DHCP offer until local time is established. Successfully acquiring the Time of Day is not mandatory for a successful registration, but it is necessary for ongoing operation. If a CM is unable to establish time of day before registration it MUST log the failure, generate an alert to management facilities, then proceed to an operational state and retry periodically. The specific timeout for Time of Day Requests is implementation dependent. However, for each server defined the CM MUST NOT exceed more than 3 Time of Day requests in any 5 minute period. At minimum, the CM MUST issue at least 1 Time of Day request per 5 minute period for each server specified until local time is established.
11.2.8 Transfer Operational Parameters

After DHCP is successful, the modem MUST download the parameter file using TFTP, as shown in Figure 1112. The TFTP configuration parameter server is specified by the siaddr field of the DHCP response. The CM MUST use an adaptive time out for TFTP based on binary exponential backoff. Refer to [RFC-1123] and [RFC2349]. The parameter fields required in the DHCP response and the format and content of the configuration file MUST be as defined in Annex D. Note that these fields are the minimum required for interoperability. If a modem downloads a configuration file containing an Upstream Channel ID Configuration Setting (Annex C.1.1.2) different from what the modem is currently using, the modem MUST NOT send a Registration Request message to the CMTS. Likewise, if a modem downloads a configuration file containing a Single Downstream Channel Frequency (Annex C.1.1.21.1.2) and/or Downstream Frequency Range (Annex C.1.1.21.2) that does not include the downstream frequency the modem is currently using, or a Downstream Frequency Configuration Setting (Annex C.1.1.1) different from what the modem is currently using and no Downstream Channel List, the modem MUST NOT send a Registration Request message to the CMTS. In either case, the modem MUST redo initial ranging using the configured upstream channel and/or downstream frequency(s) per Section 8.3.6.3.1 If a modem downloads a configuration file containing the Enable 2.0 Mode TLV set to Disable (see section Annex C.1.1.19), then it MUST NOT operate in 2.0 Mode until it registers again and downloads a configuration file which does not have this TLV set to Disable. This is true no matter what type of upstream the CM is using at
1.

Revised this paragraph per ECN RFIv2.0-N-03.0086-7 by GO on 3/15/04.

252

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

the time it is attempting registration. If it is using a Type 3 channel (as described in Section 11.2.2), it MUST NOT send a Registration Request message to the CMTS. The modem MUST redo initial ranging using a Type 1 or Type 2 channel. If no such upstream channel is available (or if the modem is unable to range successfully on one) the modem MUST scan for a new downstream, at which point 2.0 mode is no longer disabled. If the modem downloads a configuration file that does not disable 2.0 Mode, then, regardless of what kind of upstream it is using at the time of registration it will continue to operate with 2.0 mode enabled until it is no longer registered. This means that if a modem registers on type 1 channel with a configuration file that enables 2.0 mode operation, and then ends up on a type 2 or type 3 upstream without going through re-registration, the CM would immediately start operating in 2.0 mode.
11.2.9 Registration

A CM MUST be authorized to forward traffic into the network once it is initialized and configured. The CM is authorized to forward traffic into the network via registration. To register with a CMTS, the CM MUST forward its configured class of service and any other operational parameters in the configuration file (refer to Section 8.3.7) to the CMTS as part of a Registration Request. The CM MUST perform the following operations before registration (refer to Figure 11-12):

Check configuration file mandatory items (refer to Annex D.2.2). The CM MUST reject a configuration file
if it lacks any mandatory items.

Calculate a MIC per Annex D.2.3.1 and compare it to the CM MIC included in the configuration file. If the
MIC is invalid, the CM MUST reject the configuration file.

If the configuration file contains TLV-11 encoding, the CM MUST follow the configuration process defined
in Section 3.4 of [DOCSIS5]. The CM MUST reject a configuration file in the case of TLV-11 processing failure. Figure 11-12 shows the procedure that MUST be followed by the CM. The configuration parameters downloaded to the CM MUST include a network access control object (see Annex C.1.1.3). If this is set to no forwarding, the CM MUST NOT forward data from attached CPE to the network, yet the CM MUST respond to network management requests. This allows the CM to be configured in a mode in which it is manageable but will not forward data.

253

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Time of Day Request

Wait for Time of Day Response

Time of Day Response

Timeout

Time of Day Retries are asynchronous with registration

Request Config File No Wait for Successful TFTP Retries exceeded? Yes Scan for Dowstream Channel

Config File Received

Timeout

Increment Retry Counter

Mandatory items present?

No

Yes

CM MIC valid?

No

Yes

TLV type 11 errors?

Yes

No Acquire Operational Parameters Send RegReq

Wait for Reg-Rsp

Figure 11-12

Registration CM

Once the CM has sent a Registration Request to the CMTS it MUST wait for a Registration Response to authorize it to forward traffic to the network. Figure 11-13 shows the waiting procedure that MUST be followed by the CM.
254

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Wait for Reg Rsp

Timeout T6

Reg-Rsp

No

Retries exhausted?

Response = ok?

No

Implementation Dependent

Yes

Yes

Send Reg-Req

Error: Re-initialize MAC

Yes

CM supports all parameters in Reg-Rsp?

No

Send Reg-Ack with error sets

Wait for Reg Rsp

Setup Service Flows & Activate Operational Parameters

Send Reg-Ack

Switch to DOCSIS 1.1 mode

Yes DOCSIS 2.0 enabled AND Type 2 channel? DOCSIS 2.0 enabled AND Type 2 channel?

Yes

No

No Switch to DOCSIS 2.0 mode Registration Complete Reg-Rsp

Figure 11-13 Wait for Registration Response CM1 2

255

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note to Figure 11-12 and Figure 11-13: A type 2 upstream supports both DOCSIS 1.1 and DOCSIS 2.0 TDMA bursts (see Section 11.2.2). On such an upstream, it is necessary that the CMTS know whether the CM has calculated a request to transmit data based on the DOCSIS 2.0 TDMA data IUCs (9, 10) or on the DOCSIS 1.x IUCs (5, 6). On these upstreams, the CM calculates all requests up to and including the request to transmit the REG-ACK based on the DOCSIS 1.x IUCs. If the CM is enabled to operate in 2.0 mode (see Annex C.1.1.19), all requests to transmit data on such an upstream, subsequent to the transmission of the REG-ACK, are calculated based on the DOCSIS 2.0 TDMA data IUCs. If the CMTS indicates that it did not receive the REGACK by retransmitting the REG-RSP, a CM using such an upstream MUST revert to the DOCSIS 1.x data IUCs to request bandwidth for retransmitting the REG-ACK. The CMTS MUST perform the following operations to confirm the CM authorization (refer to Figure 11-14 and Figure 11-15):

Calculate a MIC per Annex D.3.1 and compare it to the CMTS MIC included in the Registration Request. If
the MIC is invalid, the CMTS MUST respond with an Authentication Failure.

If present, check the TFTP Server Timestamp field. If the CMTS detects that the time is different from its
local time by more than CM Configuration Processing Time (refer to Annex B), the CMTS MUST indicate authentication failure in the REG-RSP. The CMTS SHOULD also make a log entry stating the CM MAC address from the message.

If present, check the TFTP Server Provisioned Modem Address field. If the Provisioned Modem Address
does not match the requesting modems actual address, the CMTS MUST indicate authentication failure in the REG-RSP. The CMTS SHOULD also make a log entry stating the CM MAC address from the message.

If the Registration Request contains DOCSIS 1.0 Class of Service encodings, verify the availability of the
class(es) of service requested. If unable to provide the class(es) of service, the CMTS MUST respond with a Class of Service Failure and the appropriate Service Not Available response code(s). (refer to Annex C.1.3.4)

If the Registration Request contains Service Flow encodings, verify the availability of the Quality of Service
requested in the provisioned Service Flow(s). If unable to provide the Service Flow(s), the CMTS MUST respond with either a reject-temporary or a reject-permanent (see App. C.4) and the appropriate Service Flow Response(s).

If the Registration Request contains DOCSIS 1.0 Class of Service encodings and Service Flow encodings, the
CMTS MUST respond with a Class of Service Failure and a Service Not Available response code set to reject-permanent for all DOCSIS 1.0 Classes and Service Flows requested.

Verify the availability of any Modem Capabilities requested. If unable or unwilling to provide the Modem
Capability requested, the CMTS MUST turn that Modem Capability off (refer to Section 8.3.8.1.1).

Assign a Service Flow ID for each class of service supported. Reply to the modem in a Registration Response. If the Registration Request contains Service Flow encoding and the REG-RESP sent with a confirmation
code of ok (0), the CMTS MUST wait for a Registration Acknowledgment as shown in Figure 11-14. If the Registration Request contains DOCSIS 1.0 Class of Service encodings, the CMTS MUST NOT wait for a Registration Acknowledgment.

In a channel that supports both DOCSIS 1.x and DOCSIS 2.0 TDMA burst types (see Section 11.2), the
CMTS MUST change the operational state of the DOCSIS 2.0 enabled CM (see Annex C.1.1.19) to DOCSIS 2.0 TDMA after the Registration Acknowledgement message is received from the CM.

If timer T9 expires, the CMTS MUST both de-assign the temporary SID from that CM and make some provision for aging out that SID.

1. 2.

Refer to Section 11.2.2 for channel type definitions. Revised Figure 11-13 per ECN RFI2-N-02239 by GO on 02/26/03.

256

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Waiting for RegReq

Reg-Req

Stop T9

Calculate MIC over Reg-Req

CMTS MIC Valid?

No

Send Reg-Rsp with Response = Authentication Failure

Yes

TFTP Server IP and/ or Timestamp Valid?

No

Send Reg-Rsp with Response = Authentication Failure & Should Log Failure

Yes

Wait for Reg-Req

Can the requested service(s) ever be supported?

No

Send Reg-Rsp with Response = Class of Service Failure & Service Not Available=Reason Permanent

Yes Send Reg-Rsp with Response = Class of Service Failure & Service Not Available=Reason Temporary

Can the requested service(s) currently be supported?

No

Set modem capabilities supported in RegRsp

Create Requested Services

Send Reg-Rsp with Response = ok

Waiting for RegAck

Figure 11-14

Registration CMTS

257

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Waiting for RegAck

Reg-Ack

Timeout T6

No

Reg-Ack contains Error Sets?

Yes

Retries Exhausted?

No

Adv. PHY activated AND Type 2 channel?

Yes

Destroy Services

Send Reg-Rsp with Response = OK

No Registration Complete

Switch CM operational state to Adv PHY Waiting for RegReq Waiting for RegAck

Figure 11-15 Registration Acknowledgment CMTS1

11.2.10 Baseline Privacy Initialization2

Following registration, if the CM is provisioned to run Baseline Privacy, the CM MUST initialize Baseline Privacy operations, as described in [DOCSIS8]. A CM is provisioned to run Baseline Privacy if the Privacy Enable TLV (Section C.1.1.16) in the DOCSIS 1.1-style configuration file is explicitly/implicitly set to enable or the Baseline Privacy Configuration Setting (Section C.3.2) is contained in the DOCSIS 1.0-style configuration file as specified in Sections A.1.1 and C.2 of the BPI+ specification [DOCSIS8]. Note that the Secure Software Download is required regardless of whether the CM is provisioned to run Baseline Privacy or not as specified in Appendix D of the BPI+ specification [DOCSIS8]. If the CM has been provisioned to run Baseline Privacy, it MUST NOT forward traffic from any attached CPE device to the HFC network from the time registration completes until after the initialization of Baseline Privacy operations completes for its primary SID/SAID. The CMTS MAY stop forwarding data traffic to a CM that has been provisioned to run Baseline Privacy from the time registration completes until after the CM has successfully completed initializing Baseline Privacy.3

1. 2. 3.

Revised Figure 11-15 per ECN RFI2-N-02239 by GO on 02/26/03. Replaced paragraph in this section per ECN RFI2-N-02239 by GO on 02/26/03. Revise paragraph by adding a statement primary SID/SAID per ECN RFI2-N-03073 by GO on 07/03/03.

258

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.2.11

Service IDs During CM Initialization

After completion of the Registration process (Section 11.2.9), the CM will have been assigned Service Flow IDs (SFIDs) to match its provisioning. However, the CM must complete a number of protocol transactions prior to that time (e.g., Ranging, DHCP, etc.), and requires a temporary Service ID in order to complete those steps. On reception of an Initial Ranging Request, the CMTS MUST allocate a temporary SID and assign it to the CM for initialization use. The CMTS MAY monitor use of this SID and restrict traffic to that needed for initialization. It MUST inform the CM of this assignment in the Ranging Response. On receiving a Ranging Response addressed to it, the CM MUST use the assigned temporary SID for further initialization transmission requests until the Registration Response is received. On receiving a Ranging Response instruction to move to a new downstream frequency and/or upstream channel ID, the CM MUST consider any previously assigned temporary SID to be deassigned, and must obtain a new temporary SID via initial ranging. It is possible that the Ranging Response may be lost after transmission by the CMTS. The CM MUST recover by timing out and re-issuing its Initial Ranging Request. Since the CM is uniquely identified by the source MAC address in the Ranging Request, the CMTS MAY immediately re-use the temporary SID previously assigned. If the CMTS assigns a new temporary SID, it MUST make some provision for aging out the old SID that went unused (see Section 8.3.8). When assigning provisioned SFIDs on receiving a Registration Request, the CMTS may re-use the temporary SID, assigning it to one of the Service Flows requested. If so, it MUST continue to allow initialization messages on that SID, since the Registration Response could be lost in transit. If the CMTS assigns all-new SIDs for classof-service provisioning, it MUST age out the temporary SID. The aging-out MUST allow sufficient time to complete the registration process in case the Registration Response is lost in transit.
11.2.12 Multiple-Channel Support

In the event that more than one downstream signal is present in the system, the CM MUST operate using the first valid downstream signal that it encounters when scanning. It will be instructed via the parameters in the configuration file (see Annex C) to shift operation to different downstream and/or upstream frequencies if necessary. Both upstream and downstream channels MUST be identified where required in MAC management messages using channel identifiers.

11.3
11.3.1

Standard Operation
Periodic Signal Level Adjustment1

The CMTS MUST provide each CM a Periodic Ranging opportunity at least once every T4 seconds. The CMTS MUST send out Periodic Ranging opportunities at an interval sufficiently shorter than T4 so that a MAP could be missed without the CM timing out. The size of this "subinterval" is CMTS dependent. The CM MUST reinitialize its MAC after T4 seconds have elapsed without receiving a Periodic Ranging opportunity.
1.

Revised this section per ECN RFI2-N-03016 by GO on 02/27/03.

259

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Remote RF signal level adjustment at the CM is performed through a periodic ranging function using the RNGREQ and RNG-RSP MAC messages. This is similar to initial ranging and is shown in Figure 11-16 and Figure 11-17. On receiving a RNG-RSP, the CM MUST NOT transmit until the RF signal has been adjusted in accordance with the RNG-RSP and has stabilized (refer to Section 6). When operating in 2.0 mode, the CM MUST NOT transmit anything other than RNG-REQs, if it has been suspended by receiving a RNG-RSP with a ranging status of CONTINUE, until such time as it receives a RNG-RSP with a ranging status of SUCCESS. When operating in 1.x mode, the CM should continue normal operation and MUST NOT suspend on-going data transmission if it receives a RNG-RSP with a ranging status of CONTINUE. The CMTS SHOULD NOT send a ranging status of CONTINUE in a RNG-RSP to any CMs in 2.0 mode unless the ranging parameters measured on the corresponding RNG-REQ are insufficient for the CMTS to guarantee proper reception of all burst types available to that CM. Additionally, upon sending a RNG-RSP with ranging status of CONTINUE to a CM in 2.0 mode, the CMTS SHOULD schedule another Periodic Ranging opportunity for the CM quickly so that the CM can return to a ranging status of SUCCESS as quickly as possible. As described in Section 11.2.1, during normal operation in the S-CDMA mode, if a CM temporarily loses synchronization to the downstream signal, it is required to perform a ranging process before returning to normal operation. To facilitate this recovery, if the CMTS does not receive a RNG-REQ message from a CM during a Station Maintenance interval, the CMTS MAY schedule unicast Initial Maintenance opportunities, or it MAY temporarily reduce the time between unicast spreader-off Station Maintenance opportunities.1

1.

Added this paragraph per ECN RFI2-N-02227 by GO on 03/20/03.

260

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

On periodic timer add CM to poll list for future maps

Map will be sent per allocation algorithm and pending till complete (see Note 2 below)

Wait for polled RNG-REQ

RNG-REQ not received

RNG-REQ

No Retries Exhausted? No Yes

Good Enough? (see Note 1 below)

Yes

Retries Exhausted? Yes No Send RNG-RSP (abort) Send RNG-RSP (continue)

Send RNG-RSP (success)

Remove CM from poll list

Remove CM from poll list

Wait for polled RNG-REQ

Done

Destroy SIDs associated with this CM

Done

Note 1: Means Ranging Request is within the tolerance limits of the CMTS for power and transmit equalization (if supported) Note 2: RNG-REQ pending-till-complete was nonzero, the CMTS SHOULD hold off the station maintenance opportunity accordingly unless needed, for example, to adjust the CM's power level. If opportunities are offered prior to the pending-till-complete expiry, the "good-enough" test which follows receipt of a RNG-RSP MUST NOT judge the CM's transmit equalization until pending-till-complete expires.

Figure 11-16 Periodic Ranging - CMTS

261

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Operational

RNG-RSP Unicast maintenance opportunity Timeout T3 Timeout T4

Start T4 Timer

T3 Timer started?

Yes Reset RNG-REQ Retry Counter; Clear T3 Timer

No Send RNG-REQ

RNG-REQ retries exceeded?

Abort ranging from CMTS?

Yes Increment RNG-REQ Retry Counter Yes No Start T3 Timer Clear transmission suspend Suspend transmission of everything except RNG-REQs Success ranging from CMTS? No

Error: Re-initialize MAC

Adjust local parameters per RNG-RSP

Figure 11-17 Periodic Ranging - CM View

11.3.2

Changing Upstream Channel Descriptor Message Parameters

Whenever the CMTS is to change any of the upstream burst characteristics specified in the Upstream Channel Descriptor (UCD) message (see Section 8.3.3), it must provide for an orderly transition from the old values to the new values by all CMs. Whenever the CMTS is to change any of the upstream characteristics, it MUST announce the new values in an UCD message, and the Configuration Change Count field in that UCD message MUST be incremented to indicate that a value has changed. After transmitting one or more UCD messages with the new value, the CMTS transmits a MAP message with a UCD Change Count matching the new Configuration Change Count. The first interval in the MAP MUST be a data grant of at least 1 millisecond to the null Service ID (zero). In the case of S-CDMA channels, that grant to the null Service ID MUST be at least the longer of 1ms or the duration of 2 S-CDMA frames to allow for the latency of the S-CDMA framing, and the Start Time of the MAP with the new UCD Change Count MUST correspond to the beginning of an S-CDMA frame. The CMTS MUST allow this time for cable modems to
262

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

change their PMD sublayer parameters to match the new set. This time is independent of the lead time the CMTS needed to allow for in transmitting the MAP (see Section 9.1.5). The CMTS MUST transmit the new UCD message early enough that the CM receives the UCD message at least the UCD Processing Time (see Annex B) prior to the time the first MAP using the new UCD parameters arrives at the CM. With the following exceptions the CM MUST be able to transmit normally on the first grant following the grant to the NULL SID. The exceptions are the case where the new UCD message has changed the S-CDMA Enable parameter, or the S-CDMA US Ratio Numerator or Denominator. In these cases the CM MAY redo initial ranging to establish timing synchronization for the new mode of operation before it resumes normal transmissions. If the CM was already registered with the CMTS, and it redoes initial ranging for this reason it MUST use its Primary SID instead of the initialization SID for the initial ranging process and it MUST NOT reregister. Using the Ranging Required parameter in the new UCD message, the CMTS can force the CM to perform ranging prior to making any other transmissions using the parameters in the new UCD message. In certain cases, channel wide parameter changes (in particular, Modulation Rate or Center Frequency) may invalidate pre-equalization and synchronization parameters and normal operation may not be possible without re-ranging. If the CMTS changes the Modulation Rate or Center Frequency on an S-CDMA channel, it MUST force re-ranging using the Ranging Required parameter. In the case of an S-CDMA channel, the first UCD message with a new Configuration Count and any subsequent UCD messages that may be sent prior to the first MAP with the new UCD Change Count MUST have an updated timestamp snapshot corresponding to the start time of that first MAP with the new UCD Change Count. Also on an S-CDMA channel the CMTS MUST maintain the continuity of the mini-slot and S-CDMA frame counters during the change in UCD parameters even if the size of a mini-slot is changed. The CMTS MUST NOT transmit MAPs with the old UCD Change Count after transmitting the new UCD message. The CM MUST use the parameters from the UCD message corresponding to the MAPs UCD Change Count for any transmissions it makes in response to that MAP. If the CM has, for any reason, not received the corresponding UCD message, it cannot transmit during the interval described by that MAP. It is possible for the change in upstream parameters to cause the upstream to change from a Type 1 upstream (see Section 11.2.2) to a Type 2 upstream or a Type 3 upstream. If this happens, and the CM registered with a configuration file that enables 2.0 Mode (see Section 11.2.8), then the CM MUST operate in 2.0 Mode. If the upstream has changed to a Type 2 upstream this means that any request the CM transmits in an opportunity in the MAP with the new Configuration Change Count or any subsequent MAP MUST be calculated in terms of IUCs 9 and 10, rather than IUCs 5 and 6, and the CMTS MUST issue grants using IUCs 9 and 10. However, if the CM registered with a configuration file that disabled 2.0 Mode, then the CM MUST continue to calculate requests in terms of IUCs 5 and 6, and the CMTS MUST issue grants using IUCs 5 and 6. If the CM registered with a configuration file that disables 2.0 Mode, and the new parameters have changed the upstream to a Type 3 upstream, then the CM MUST immediately reinitialize the MAC layer and attempt registration. It should be understood by the network operator that changing a Type 1 upstream to a Type 3 upstream will cause a significant disruption of service for any CMs with 2.0 Mode disabled as well as any DOCSIS 1.x CMs that are using the channel. Also such CMs will only be able to resume operation if there is a Type 1 or Type 2 upstream available to them.
11.3.3 Changing Upstream Channels

At any time after registration, the CMTS may direct the CM to change its upstream channel. This may be done for traffic balancing, noise avoidance, or any of a number of other reasons which are beyond the scope of this specification. Figure 11-18 shows the procedure that MUST be followed by the CMTS. Figures 11-19 and 11-20 show the corresponding procedure at the CM.

263

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Decide to switch CM to new upstream channel

UCC-REQ

Wait for UCCRSP

Timeout T5

UCC-RSP

Done Retries Exhausted? No Yes

CM is unreachable

Figure 11-18 Changing Upstream Channels: CMTS View

Note that if the CMTS retries the UCC-REQ, the CM may have already changed channels (if the UCC-RSP was lost in transit). Consequently, the CMTS MUST listen for the UCC-RSP on both the old and the new channels.

264

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM Operational

UCC-REQ

Yes

Already using this channel?

No

UCC-RSP (rejectalready-there)

UCC-RSP

Switch to new channel

Valid UCD for target upstream stored?

1. If DOCSIS 2.0 is enabled, a valid UCD describes either a type 1, 2, or 3 channel. 2. If DOCSIS 2.0 is NOT enabled, a valid UCD describes a type 1 or type 2 channel. Yes

No Wait for valid UCD for target upstream channel (or expiry of T1)

Valid UCD acquired? Yes Perform broadcast initial ranging

No CM UCC Failed

Ranging Success? Yes The operational CM MUST base its requests on IUCs 9 and 10 if available and if DOCSIS 2.0 is enabled. CM Operational

No CM UCC Failed

Figure 11-19 Changing Upstream Channels: CM View Part 1

265

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

CM UCC Failed

ERROR: UCC failed <reason>

Return to old upstream

Re-initialize MAC Reset the MAC

Obtain Upstream Parameters

The state Obtain Upstream Parameters links to the state machine in Figure 11-1.

Figure 11-20 Changing Upstream Channels: CM View Part 2

Upon synchronizing with the new upstream channel, the CM MUST perform broadcast initial ranging on the new upstream channel. If the CM has previously established ranging on the new channel, and if that ranging on that channel is still current (T4 has not elapsed since the last successful ranging), then the CM MAY use cached ranging information and omit ranging. The CM SHOULD cache UCD information from multiple upstream channels to eliminate waiting for a UCD corresponding to the new upstream channel. The CM MUST NOT perform re-registration, since its provisioning and MAC domain remain valid on the new channel. If a DOCSIS 2.0-enabled CM is moved from a Type 1 channel to a Type 2 channel via a UCC, the CM MUST operate in 2.0 mode on the destination channel, basing its requests on IUCs 9 and 10 instead of IUCs 5 and 6. If a CM in which DOCSIS 2.0 is disabled in registration is moved from a Type 1 channel to a Type 2 channel via a UCC, the CM MUST continue to base its requests on the destination channel on IUCs 5 and 6.

266

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4

Dynamic Service

Service Flows may be created, changed or deleted. This is accomplished through a series of MAC management messages referred to as Dynamic Service Addition (DSA), Dynamic Service Change (DSC) and Dynamic Service Deletion (DSD). The DSA messages create a new Service Flow. The DSC messages change an existing Service Flow. The DSD messages delete a single existing Upstream and/or a single existing Downstream Service Flow. This is illustrated in Figure 11-21.

DSD

DSC

Null

Operational

DSA

Figure 11-21 Dynamic Service Flow Overview

The Null state implies that no Service Flow exists that matches the SFID and/or TransactionID in a message. Once the Service Flow exists, it is operational and has an assigned SFID. In steady state operation, a Service Flow resides in a Nominal state. When Dynamic Service messaging is occurring, the Service Flow may transition through other states, but remains operational. Since multiple Service Flows may exist, there may be multiple state machines active, one for every Service Flow. Dynamic Service messages only affect those state machines that match both the SFID and Transaction ID or SFID only. A Transaction ID which is reused for other SFID(s) indicates that the other side terminated the previous transaction. If a Dynamic Service request message is received which refers to the same Transaction ID as one that has already been processed, but service flow(s) other then those locked in this transaction, the device MAY trigger a DSx Ended input to the state machine(s) of SF(s) involved in the previous transaction. If privacy is enabled, both the CM and CMTS MUST verify the HMAC digest on all dynamic service messages before processing them, and discard any messages that fail.1 Service Flows created at registration time effectively enter the SF_operational state without a DSA transaction. TransactionIDs are unique per transaction and are selected by the initiating device (CM or CMTS). To help prevent ambiguity and provide simple checking, the TransactionID number space is split between the CM and CMTS. The CM MUST select its TransactionIDs from the first half of the number space (0x0000 to 0x7FFF). The CMTS MUST select its TransactionIDs from the second half of the number space (0x8000 to 0xFFFF). Each dynamic service message sequence is a unique transaction with an associated unique transaction identifier. To help support transaction identifier uniqueness between 2 devices in different states, the transaction initiating device SHOULD change the transaction identifier for each new initiated transaction. It MUST wait at least T10 to re-use the transaction identifier. The DSA/DSC transactions consist of a request/response/acknowledge sequence. The DSD transactions consist of a request/response sequence. The response messages MUST contain a confirmation code of okay unless some exception condition was detected. The acknowledge messages MUST include the confirmation code in the response unless a new exception condition arises. A more detailed state diagram, including transition states, is shown below. The detailed actions for each transaction will be given in the following sections.2

1. 2.

Revised this paragraph per ECN RFIv2.0-N-04.0147-1 by GO on 7/8/04. Revised this paragraph per ECN RFIv2.0-N-04.0147-1 by GO on 7/8/04.

267

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.4.1

Dynamic Service Flow State Transitions

The Dynamic Service Flow State Transition Diagram, Figure 11-22, is the top-level state diagram and controls the general Service Flow state. As needed, it creates transactions, each represented by a Transaction state transition diagram, to provide the DSA, DSC, and DSD signaling. Each Transaction state transition diagram only communicates with the parent Dynamic Service Flow State Transition Diagram. The top-level state transition diagram filters Dynamic Service messages and passes them to the appropriate transaction based on Service Flow Identifier (SFID), Service Flow Reference number, and TransactionID. If a single Dynamic Service message affects a pair of service flows, a single transaction is initiated which communicates with both parent Dynamic Service Flow State Transition Diagrams. In this case, both service flows MUST remain locked in the same state until they receive the DSx Succeeded or DSx Failed input from the DSx Transaction State Transition Diagram. During that lock interval, if a message is received which refers to only one of the two service flows, it MUST be treated as if it refers to both service flows, so that both service flows stay in the same state. If a DSD-REQ message is received during the lock interval which refers to only one of the two service flows, the device MUST handle the event normally, by sending the SF Delete-Remote to the ongoing DSx Transaction and by initiating a DSD-Remote transaction, and in addition, it MUST initiate a DSDLocal transaction to delete the second service flow of the locked pair. If a DSC Request is received which refers to two service flows locked in different transactions, and they are in different states, the device MUST reject the request without affecting the ongoing transactions.1 There are six different types of transactions: locally initiated or remotely initiated for each of the DSA, DSC and DSD messages. Most transactions have three basic states: pending, holding and deleting. The pending state is typically entered after creation and is where the transaction is waiting for a reply. The holding state is typically entered once the reply is received. the purpose of this state is to allow for retransmissions in case of a lost message, even though the local entity has perceived that the transaction has completed. The deleting state is only entered if the Service Flow is being deleted while a transaction is being processed. The flow diagrams provide a detailed representation of each of the states in the Transaction state transition diagrams. All valid transitions are shown. Any inputs not shown should be handled as a severe error condition. With one exception, these state diagrams apply equally to the CMTS and CM. In the Dynamic Service Flow Changing-Local state, there is a subtle difference in the CM and CMTS behaviors. This is called out in the state transition and detailed flow diagrams.
Note: The Num Xacts variable in the Dynamic Service Flow State Transition Diagram is incremented every time the top-level state diagram creates a transaction and is decremented every time a transaction terminates. A Dynamic Service Flow MUST NOT return to the Null state until its deleted and all transactions have terminated.

The inputs for the state diagrams are identified below. Dynamic Service Flow State Transition Diagram inputs from unspecified local, higher-level entities:

Add Change Delete

Dynamic Service Flow State Transition Diagram inputs from DSx Transaction State Transition diagrams:

1.

Added sentence per ECN RFI2-N-02187, by GO, on 12/16/02. Revised sentence per ECN RFI2-N-03050 & RFI2-N-03075 by GO on 06/04/03 & 07/03/03.

268

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSA Succeeded DSA Failed DSA ACK Lost DSA Erred DSA Ended DSC Succeeded DSC Failed DSC ACK Lost DSC Erred DSC Ended DSD Succeeded DSD Erred DSD Ended

DSx Transaction State Transition diagram inputs from the Dynamic Service Flow State Transition Diagram:

SF Add SF Change SF Delete SF Abort Add SF Change-Remote SF Delete-Local SF Delete-Remote SF DSA-ACK Lost SF-DSC-REQ Lost SF-DSC-ACK Lost SF DSD-REQ Lost SF Changed SF Deleted

The creation of DSx Transactions by the Dynamic Service Flow State Transition Diagram is indicated by the notation DSx-[ Local | Remote ] ( initial_input ) where initial_input may be SF Add, DSA-REQ, SF Change, DSC-REQ, SF Delete, or DSD-REQ depending on the transaction type and initiator.

269

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Null

Add / DSA-Local( SF Add )

DSA Ended /

DSA-REQ / DSA-Remote( DSA-REQ )

DSC-REQ / SF DSA-ACK Lost

Adding Local

( DSA Failed / ) ( Delete / SF Abort Add ) (DSA Erred/)

Add Failed
DSA Failed /

Adding Remote

DSA Succeeded /

DSA Succeeded /

( DSA Erred / DSD-Local( SF Delete ) ) ( Delete / SF Delete-Local, DSD-Local( SF Delete ) )

Nominal
Change / DSC-Local( SF Change ) DSC-REQ / SF Change-Remote, DSC-Remote( DSC-REQ )

( DSC-REQ / [ CMTS Only ] ) ( DSA ACK Lost / SF DSC-REQ Lost ) ( DSC ACK Lost / SF DSC-REQ Lost )

New DSC-REQ / SF DSC-ACK Lost ( DSC Succeeded / SF Changed ) ( DSC Failed / SF Changed ) ( DSC Succeeded / SF Changed ) ( DSC Failed / SF Changed )

DSD Ended && Num Xacts == 0 /

Delete / SF Delete-Local, DSD-Local( SF Delete )

Changing Local

DSC-REQ / SF Change-Remote, DSC-Remote( DSC-REQ ) [ CM Only ]

Changing Remote

( DSC Erred / SF Delete-Local, DSD-Local( SF Delete ) ) ( Delete / SF Delete-Local, DSD-Local( SF Delete ) )

( DSC-REQ / ) ( DSA ACK Lost / SF DSD-REQ Lost ) ( DSC ACK Lost / SF DSD-REQ Lost )

( DSC Erred / DSD-Local( SF Delete ) ) ( Delete / SF Delete-Local, DSD-Local( SF Delete ) )

Deleting
DSD-REQ / SF Delete-Remote, DSD-Remote( DSD-REQ )

( DSD Succeeded / SF Deleted ) ( DSD Erred / SF Deleted ) DSD Succeeded / SF Deleted

Deleted

Figure 11-22 Dynamic Service Flow State Transition Diagram

270

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Begin

SF Add / DSA-REQ

DSA-RSP Pending

Timeout T7 && Retries Available / DSA-REQ

Timeout T7 && Retries Exhausted /

( DSA-RSP / DSA Succeeded, DSA-ACK ) ( DSA-RSP / DSA Failed, DSA-ACK ) ( SF Abort Add / )

DSA-RSP / DSA ACK Lost DSA-RSP / DSA-ACK, DSA ACK Lost

Retries Exhausted

( DSA-RSP / DSA Succeeded, DSA-ACK ) ( DSA-RSP / DSA Failed, DSA-ACK ) ( SF Abort Add / )

Holding Down

SF Delete-Local /

Deleting Service Flow

( Timeout T10 / DSA Ended ) ( SF Changed / DSA Ended ) ( SF Change-Remote / DSA Ended )

Timeout T10 / DSA Erred, DSA Ended

( Timeout T10 / DSA Ended ) ( SF Deleted / DSA Ended )

SF Delete-Remote / DSA Ended

End

Figure 11-23

DSALocally Initiated Transaction State Transition Diagram

271

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Begin

( DSA-REQ / DSA-RSP ) ( DSA-REQ / DSA Failed, DSA-RSP ) ( Timeout T8 && Retries Available / DSA-RSP ) ( DSA-REQ && Retries Available / DSA-RSP ) ( DSA-REQ && Retries Exhausted / ) ( SF DSA-ACK Lost && Retries Available / DSA-RSP ) ( SF DSA-ACK Lost && Retries Exhausted / )

DSA-ACK Pending

SF Delete-Local /

( DSA-ACK / DSA Succeeded ) ( DSA-ACK / DSA Failed )

( DSA-REQ / ) ( DSA-ACK / )

( Timeout T8 && Retries Exhausted / DSA Erred, DSA Ended ) ( SF Delete-Remote / DSA Ended )

Holding Down

( DSA-ACK / ) ( SF Delete-Local / ) ( SF Change-Remote / )

Deleting Service Flow

( Timeout T8 / DSA Ended ) ( SF Changed / DSA Ended ) ( SF Deleted / DSA Ended ) ( SF Delete-Remote / DSA Ended ) ( Timeout T10 / DSA Ended ) ( SF Deleted / DSA Ended ) ( SF Delete-Remote / DSA Ended )

End

Figure 11-24 DSARemotely Initiated Transaction State Transition Diagram

272

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Begin

SF Change / DSC-REQ ( Timeout T7 && Retries Available / DSC-REQ ) ( SF DSC-REQ Lost && Retries Available / DSC-REQ ) ( SF DSC-REQ Lost && Retries Exhausted / ) DSC-RSP Pending

SF Change-Remote / DSC Ended [ CM Only ]

Timeout T7 && Retries Exhausted /

( DSC-RSP / DSC Succeeded, DSC-ACK ) ( DSC-RSP / DSC Failed, DSC-ACK )

SF Delete-Local /

DSC-RSP / DSC ACK Lost

Retries Exhausted

( DSC-RSP / DSC Succeeded, DSC-ACK ) ( DSC-RSP / DSC Failed, DSC-ACK )

Holding Down

DSC-RSP / DSC-ACK, DSC ACK Lost

Deleting Service Flow

( Timeout T10 / DSC Ended ) ( SF Changed / DSC Ended ) ( SF Change-Remote / DSC Ended )

Timeout T10 / DSC Erred, DSC Ended

( Timeout T10 / DSC Ended ) ( SF Deleted / DSC Ended )

SF Delete-Remote / DSC Ended

End

Figure 11-25

DSCLocally Initiated Transaction State Transition Diagram

273

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Begin

DSC-REQ / DSC-RSP ( Timeout T8 && Retries Available / DSC-RSP ) ( DSC-REQ && Retries Available / DSC-RSP ) ( DSC-REQ && Retries Exhausted / ) ( SF DSC-ACK Lost && Retries Available / DSC-RSP ) ( SF DSC-ACK Lost && Retries Exhausted / )

DSC-ACK Pending

SF Delete-Local /

( DSC-ACK / DSC Succeeded ) ( DSC-ACK / DSC Failed )

( DSC-REQ / ) ( DSC-ACK / )

( Timeout T8 && Retries Exhausted / DSC Erred, DSC Ended ) ( SF Delete-Remote / DSC Ended )

Holding Down

( DSC-ACK / ) ( SF Delete-Local / ) ( SF Change-Remote / )

Deleting Service Flow

( Timeout T8 / DSC Ended ) ( SF Changed / DSC Ended ) ( SF Deleted / DSC Ended ) ( SF Delete-Remote / DSC Ended )

( Timeout T10 / DSC Ended ) ( SF Deleted / DSC Ended ) ( SF Delete-Remote / DSC Ended )

End

Figure 11-26 DSCRemotely Initiated Transaction State Transition Diagram

274

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Begin

SF Delete / DSD-REQ

DSD-RSP Pending

( Timeout T7 && Retries Available / DSD-REQ ) ( SF DSD-REQ Lost && Retries Available / DSD-REQ ) ( SF DSD-REQ Lost && Retries Exhausted / )

( DSD-RSP / DSD Succeeded ) ( SF Delete-Remote / )

Timeout T7 && Retries Exhausted / DSD Erred, DSD Ended

Holding Down

( DSD-RSP / DSD Succeeded ) ( SF Deleted / )

Timeout T7 / DSD Ended

End

Figure 11-27

DSDLocally Initiated Transaction State Transition Diagram

275

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Begin

DSD-REQ / DSD Succeeded, DSD-RSP

Holding Down

DSD-REQ / DSD-RSP

( Timeout T10 / DSD Ended ) ( SF Deleted / DSD Ended )

End

Figure 11-28

Dynamic Deletion (DSD) - Remotely Initiated Transaction State Transition Diagram

11.4.2 11.4.2.1

Dynamic Service Addition CM Initiated Dynamic Service Addition

A CM wishing to create an upstream and/or a downstream Service Flow sends a request to the CMTS using a dynamic service addition request message (DSA-REQ). The CMTS checks the CMs authorization for the requested service(s) and whether the QoS requirements can be supported and generates an appropriate response using a dynamic service addition response message (DSA-RSP). The CM concludes the transaction with an acknowledgment message (DSA-ACK).

276

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

In order to facilitate a common admission response, an upstream and a downstream Service Flow can be included in a single DSA-REQ. Both Service Flows are either accepted or rejected together. CM CMTS

New Service Flow(s) needed Check if resources are available

Send DSA-REQ

---DSA-REQ-->

Receive DSA-REQ Check if CM authorized for Service(s)1 Check Service Flow(s) QoS can be supported Create SFID(s) If upstream AdmittedQoSParamSet is non-null, Create SID If upstream ActiveQoSParamSet is non-null, Enable reception of data on new upstream Service Flow

Receive DSA-RSP If ActiveQoSParamSet is non-null, Enable transmission and/or reception of data on new Service Flow(s) Send DSA-ACK

<--DSA-RSP---

Send DSA-RSP

---DSA-ACK-->

Receive DSA-ACK If downstream ActiveQoSParamSet is non-null, Enable transmission of data on new downstream Service Flow

1.

Note: authorization can happen prior to the DSA-REQ being received by the CMTS. The details of CMTS signalling to anticipate a DSA-REQ are beyond the scope of this specification.
Figure 11-29 Dynamic Service Addition Initiated from CM

11.4.2.2

CMTS Initiated Dynamic Service Addition

A CMTS wishing to establish an upstream and/or a downstream dynamic Service Flow(s) with a CM performs the following operations. The CMTS checks the authorization of the destination CM for the requested class of service and whether the QoS requirements can be supported. If the service can be supported the CMTS generates new SFID(s) with the required class of service and informs the CM using a dynamic service addition request message (DSA-REQ). If the CM checks that it can support the service and responds using a dynamic service addition response message (DSA-RSP). The transaction completes with the CMTS sending the acknowledge message (DSA-ACK).

277

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

CM

CMTS

New Service Flow(s) required for CM Check CM authorized for Service(s) Check Service Flow(s) QoS can be supported Create SFID(s) If upstream AdmittedQoSParamSet is nonnull, Create SID If upstream ActiveQoSParamSet is non-null, Enable reception of data on new upstream Service Flow Receive DSA-REQ Confirm CM can support Service Flow(s) Add Downstream SFID (if present) Enable reception on any new downstream Service Flow Send DSA-RSP

<--DSA-REQ---

Send DSA-REQ

---DSA-RSP-->

Receive DSA-RSP Enable transmission & reception of data on new Service Flow(s)

Receive DSA-ACK Enable transmission on new upstream Service Flow

Figure 11-30

<--DSA-ACK---

Send DSA-ACK

Dynamic Service Addition Initiated from CMTS

278

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4.2.3

Dynamic Service Addition State Transition Diagrams

DSA-Local Begin

SF Add

DSA-REQ

Start T7 Timer

Save transmitted DSA-REQ

Set DSA-REQ Retries Available to 'DSx Request Retries'

DSA-Local DSA-RSP Pending

Figure 11-31

DSALocally Initiated Transaction Begin State Flow Diagram

279

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSA-Local DSA-RSP Pending

Timeout T7

SF Delete-Remote

SF Abort Add

DSA-RSP

Retries Available ?

Stop T7 Timer No

Stop T7 Timer

Stop T7 Timer

Yes

DSA Ended

Save DSA-ACK with Condition Code 'reject-addaborted' No

Okay ?

Saved DSA-REQ

Start T10 Timer DSA-Local End

Yes

Start T7 Timer

DSA-Local Retries Exhausted

Enable service flow

Decrement DSA-REQ Retries Available

DSA Failed

DSA Succeeded

DSA-Local DSA-RSP Pending

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSA-ACK

Save transmitted DSA-ACK

Start T10 Timer

DSA-Local Holding Down

Figure 11-32 DSALocally Initiated Transaction DSA-RSP Pending State Flow Diagram

280

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSA-Local Holding Down

SF Changed, SF Change-Remote, SF Delete-Remote

Timeout T10

SF Delete-Local

DSA-RSP

Stop T10 Timer

DSA-Local Deleting Service Flow

Saved DSA-ACK

DSA ACK Lost DSA Ended

DSA-Local Holding Down DSA-Local End

Figure 11-33

DSALocally Initiated Transaction Holding State Flow Diagram

281

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSA-Local Retries Exhausted

Timeout T10

SF Delete-Remote

SF Abort Add

DSA-RSP

DSA Erred

Stop T10 Timer

Save DSA-ACK with Condition Code 'reject-addaborted' No

Okay ?

Yes

DSA Ended

Enable service flow

DSA-Local End

DSA Failed

DSA Succeeded

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSA-ACK

Save transmitted DSA-ACK

DSA-Local Holding Down

Figure 11-34 DSALocally Initiated Transaction Retries Exhausted State Flow Diagram

282

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSA-Local Deleting Service Flow

SF Deleted, SF Delete-Remote

Timeout T10

DSA-RSP

Stop T10 Timer

DSA ACK Lost

DSA-Local Deleting Service Flow DSA Ended

DSA-Local End

Figure 11-35

DSALocally Initiated Transaction Deleting Service Flow State Flow Diagram

283

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSA-Remote Begin

DSA-REQ

No

Okay ?

Yes

DSA Failed

[ CM Only ] Enable downstream service flow

[ CMTS Only ] Enable upstream service flow

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSA-RSP

Start T8 Timer

Save transmitted DSA-RSP

Set DSA-RSP Retries Available to 'DSx Response Retries'

DSA-Remote DSA-ACK Pending

Figure 11-36 DSARemotely Initiated Transaction Begin State Flow Diagram

284

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSA-Remote DSA-ACK Pending

DSA-REQ

SF DSA-ACK Lost

Timeout T8

SF DeleteRemote

SF DeleteLocal

DSA-ACK

Retries Available ?

Stop T8 Timer No

Stop T8 Timer

Stop T8 Timer

Yes

Start T10 Timer

Saved DSA-RSP Retries Available ? Start T8 Timer Yes

DSA Erred DSA-Remote Deleting Service Flow

No

DSA Ended Decrement DSA-RSP Retries Available DSA-Remote End

No

Okay ?

Saved DSA-RSP

Yes

DSA-Remote DSA-ACK Pending

Disable service flow

[ CM Only ] Enable upstream service flow

[ CMTS Only ] Enable downstream service flow

DSA Failed

DSA Succeeded

Start T8 Timer

DSA-Remote Holding Down

Figure 11-37

DSARemotely Initiated Transaction DSA-ACK Pending State Flow Diagram

285

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSA-Remote Holding Down

SF Changed, SF Deleted, SF Delete-Remote

Timeout T8

SF Delete-Local, SF Change-Remote

DSA-ACK

Stop T8 Timer DSA-Remote Holding Down

DSA Ended

DSA-Remote End

Figure 11-38

DSARemotely Initiated Transaction Holding Down State Flow Diagram

286

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSA-Remote Deleting Service Flow

SF Deleted, SF Delete-Remote

Timeout T10

DSA-REQ, DSA-ACK

Stop T10 Timer

DSA-Remote Deleting Service Flow

DSA Ended

DSA-Remote End

Figure 11-39 DSARemotely Initiated Transaction Deleting Service State Flow Diagram

11.4.3

Dynamic Service Change

The Dynamic Service Change (DSC) set of messages is used to modify the flow parameters associated with a Service Flow. Specifically, DSC can:

Modify the Service Flow Specification Add, Delete or Replace a Flow Classifier Add, Delete or Set PHS elements
A single DSC message exchange can modify the parameters of one downstream service flow and/or one upstream service flow. To prevent packet loss, any required bandwidth change must be sequenced between the application generating the data and the bandwidth parameters of the Service Flow carrying the data. Because MAC messages can be lost, the timing of Service Flow parameter changes can vary, and it occurs at different times in the CM and CMTS. Applications should reduce their transmitted data bandwidth before initiating a DSC to reduce the Service Flow bandwidth, and should not increase their transmitted data bandwidth until after the completion of a DSC increasing the Service Flow bandwidth. The CMTS controls both upstream and downstream scheduling. Scheduling is based on data transmission requests and is subject to the limits contained in the current Service Flow parameters at the CMTS. The timing of Service Flow parameter changes, and any consequent scheduling changes, is independent of both direction and

287

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

whether there is an increase or decrease in bandwidth. The CMTS always changes Service Flow parameters on receipt of a DSC-REQ (CM-initiated transaction) or DSC-RSP (CMTS-initiated transaction). The CMTS also controls the downstream transmit behavior. The change in downstream transmit behavior is always coincident with the change in downstream scheduling (i.e., CMTS controls both and changes both simultaneously). The CM controls the upstream transmit requests, subject to limits contained in the current Service Flow parameters at the CM. The timing of Service Flow parameter changes in the CM, and any consequent CM transmit request behavior changes, is a function of which device initiated the transaction. For a CM-initiated DSC-REQ, the Service Flow parameters are changed on receipt of the DSC-RSP from the CMTS. For a CMTSinitiated DSC-REQ, the Service Flow parameters are changed on receipt of the DSC-REQ from the CMTS. Any service flow can be deactivated with a Dynamic Service Change command by sending a DSC-REQ message, referencing the Service Flow Identifier, and including a null ActiveQoSParameterSet. However, if a Primary Service Flow of a CM is deactivated that CM is de-registered and MUST re-register. Therefore, care should be taken before deactivating such Service Flows. If a Service Flow that was provisioned during registration is deactivated, the provisioning information for that Service Flow MUST be maintained until the Service Flow is reactivated. A CM MUST have only one DSC transaction outstanding per Service Flow. If it detects a second transaction initiated by the CMTS, the CM MUST abort the transaction it initiated and allow the CMTS initiated transaction to complete. A CMTS MUST have only one DSC transaction outstanding per Service Flow. If it detects a second transaction initiated by the CM, the CMTS MUST abort the transaction the CM initiated and allow the CMTS initiated transaction to complete.
Note: Currently anticipated applications would probably control a Service Flow through either the CM or CMTS, and not both. Therefore the case of a DSC being initiated simultaneously by the CM and CMTS is considered as an exception condition and treated as one.

11.4.3.1

CM-Initiated Dynamic Service Change

A CM that needs to change a Service Flow definition performs the following operations. The CM informs the CMTS using a Dynamic Service Change Request message (DSC-REQ). The CMTS MUST decide if the referenced Service Flow can support this modification. The CMTS MUST respond with a Dynamic Service Change Response (DSC-RSP) indicating acceptance or rejection. The CM reconfigures the Service Flow if appropriate, and then MUST respond with a Dynamic Service Change Acknowledge (DSC-ACK).

288

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CMTS

CM

Service Flow Requires Modifying Receive DSC-REQ Validate Request Modify Service Flow Send DSC-RSP ---------- DSC-RSP ---------> Receive DSC-RSP Modify Service Flow Receive DSC-ACK <--------- DSC-ACK ---------Figure 11-40 CM-Initiated DSC

<--------- DSC-REQ ----------

Send DSC-REQ

Send DSC-ACK

11.4.3.2

CMTS-Initiated Dynamic Service Change

A CMTS that needs to change a Service Flow definition performs the following operations. The CMTS MUST decide if the referenced Service Flow can support this modification. If so, the CMTS informs the CM using a Dynamic Service Change Request message (DSC-REQ). The CM checks that it can support the service change, and MUST respond using a Dynamic Service Change Response (DSC-RSP) indicating acceptance or rejection. The CMTS reconfigures the Service Flow if appropriate, and then MUST respond with a Dynamic Service Change Acknowledgment (DSC-ACK).

CMTS Service Flow Requires Modifying Send DSC-REQ ---------- DSC-REQ --------->

CM Receive DSC-REQ Modify Service Flow

Receive DSC-RSP Modify Service Flow Send DSC-ACK

<--------- DSC-RSP ----------

Send DSC-RSP

---------- DSC-ACK --------->

Figure 11-41 CMTS-Initiated DSC

Receive DSC-ACK

289

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.4.3.3 Dynamic Service Change State Transition Diagrams

DSC-Local Begin

SF Change

Save service flow QoS state

[ CM Only ] If decrease upstream bandwidth, modify transmission

DSC-REQ

Start T7 Timer

Save transmitted DSC-REQ

Set DSC-REQ Retries Available to 'DSx Request Retries'

DSC-Local DSC-RSP Pending

Figure 11-42

DSCLocally Initiated Transaction Begin State Flow Diagram

290

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSC-Local DSC-RSP Pending

SF DSC-REQ Lost

Timeout T7

SF ChangeRemote [ CM Only ]

SF DeleteRemote

SF DeleteLocal

DSC-RSP

Stop T7 Timer Retries Available ?

Stop T7 Timer

No

Stop T7 Timer

Start T10 Timer Yes DSC Ended DSC-Local Deleting Service Flow DSC-Local End DSC-Local Retries Exhausted

Retries Available ?

Saved DSC-REQ

Start T10 Timer

Start T7 Timer No Yes

No

Okay ?

Saved DSC-REQ

Decrement DSC-REQ Retries Available

Yes Restore service flow QoS State

Modify Service Flow Parameters

DSC-Local DSC-RSP Pending DSC Failed

DSC Succeeded

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSC-ACK

Start T10 Timer

Save transmitted DSC-ACK

DSC-Local Holding Down

Figure 11-43 DSCLocally Initiated Transaction DSC-RSP Pending State Flow Diagram

291

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSC-Local Holding Down

SF Changed, SF Change-Remote, SF Delete-Remote

Timeout T10

SF Delete-Local

DSC-RSP

Stop T10 Timer

DSC-Local Deleting Service Flow

Saved DSC-ACK

DSC ACK Lost DSC Ended

DSC-Local Holding Down DSC-Local End

Figure 11-44 DSCLocally Initiated Transaction Holding Down State Flow Diagram

292

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSC-Local Retries Exhausted

Timeout T10

SF Delete-Remote

SF Delete-Local

DSC-RSP

DSC Erred

Stop T10 Timer

DSC-Local Deleting Service Flow

DSC Ended

No

Okay ?

Yes DSC-Local End Restore service flow QoS state

Modify Service Flow parameters

DSC Failed DSC Succeeded

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSC-ACK

Save transmitted DSC-ACK

DSC-Local Holding Down

Figure 11-45 DSCLocally Initiated Transaction Retries Exhausted State Flow Diagram

293

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSC-Local Deleting Service Flow

SF Deleted, SF Delete-Remote

Timeout T10

DSC-RSP

Stop T10 Timer

DSC ACK Lost

DSC-Local Deleting Service Flow DSC Ended

DSC-Local End

Figure 11-46

DSCLocally Initiated Transaction Deleting Service Flow State Flow Diagram

294

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSC-Remote Begin

DSC-REQ

No

Okay?

Yes Modify Service Flow Parameters

Set Condition Code to 'reject-xxx'

Set Condition Code to 'okay'

DSC-RSP

Start T8 Timer

Save Transmitted DSC-RSP

Set DSC-RSP Retries Available to 'DSx Response Retries'

DSC-Remote DSC-ACK Pending

Figure 11-47

DSCRemotely Initiated Transaction Begin State Flow Diagram1

1.

Revised Figure 11-47 per ECN RFI2-N-03100 by GO on 11/17/03.

295

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSC-Remote DSC-ACK Pending

DSC-REQ

SF DSC-ACK Lost

Timeout T8

SF DeleteRemote

SF DeleteLocal

DSC-ACK

Retries Available ?

Stop T8 Timer No

Stop T8 Timer

Stop T8 Timer

Yes

Start T10 Timer

Saved DSC-RSP Retries Available ? No Yes Start T8 Timer

DSC Erred DSC-Remote Deleting Service Flow

DSC Ended Decrement DSC-RSP Retries Available DSC-Remote End

No

Okay ?

Saved DSC-RSP

Restore service flow

Yes

DSC Failed DSC-Remote DSC-ACK Pending

DSC Succeeded

Start T8 Timer

DSC-Remote Holding Down

Figure 11-48 DSCRemotely Initiated Transaction DSC-ACK Pending State Flow Diagram1

1.

Revised Figure 11-48 per ECN RFI2-N-02210 by GO, on 11/22/02.

296

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSC-Remote Holding Down

SF Changed, SF Deleted, SF Delete-Remote

Timeout T8

SF Delete-Local, SF Change-Remote

DSC-ACK

Stop T8 Timer DSC-Remote Holding Down

DSC Ended

DSC-Remote End

Figure 11-49

DSCRemotely Initiated Transaction Holding Down State Flow Diagram

297

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSC-Remote Deleting Service Flow

SF Deleted, SF Delete-Remote

Timeout T10

DSC-REQ, DSC-ACK

Stop T10 Timer

DSC-Remote Deleting Service Flow

DSC Ended

DSC-Remote End

Figure 11-50 DSCRemotely Initiated Transaction Deleting Service Flow State Flow Diagram

11.4.4

Dynamic Service Deletion

Any service flow can be deleted with the Dynamic Service Deletion (DSD) messages. When a Service Flow is deleted, all resources associated with it are released, including classifiers and PHS. However, if a Primary Service Flow of a CM is deleted, that CM is de-registered and MUST re-register. Also, if a Service Flow that was provisioned during registration is deleted, the provisioning information for that Service Flow is lost until the CM re-registers. However, the deletion of a provisioned Service Flow MUST NOT cause a CM to re-register. Therefore, care should be taken before deleting such Service Flows.
11.4.4.1 CM Initiated Dynamic Service Deletion

A CM wishing to delete an upstream and/or a downstream Service Flow generates a delete request to the CMTS using a Dynamic Service Deletion-Request message (DSD-REQ). The CMTS removes the Service Flow(s) and generates a response using a Dynamic Service Deletion-Response message (DSD-RSP). Only one upstream and/ or one downstream Service Flow can be deleted per DSD-Request.

298

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM

CMTS

Service Flow(s) no longer needed Delete Service Flow(s) Send DSD-REQ ---DSD-REQ--> Receive DSD-REQ Verify CM is Service Flow(s) owner Delete Service Flow(s)
Receive DSD-RSP
Figure 11-51

<--DSD-RSP---

Send DSD-RSP

Dynamic Service Deletion Initiated from CM

11.4.4.2

CMTS Initiated Dynamic Service Deletion

A CMTS wishing to delete an upstream and/or a downstream dynamic Service Flow generates a delete request to the associated CM using a Dynamic Service Deletion-Request message (DSD-REQ). The CM removes the Service Flow(s) and generates a response using a Dynamic Service Deletion-Response message (DSD-RSP). Only one upstream and/or one downstream Service Flow can be deleted per DSD-Request.1 CM CMTS

Service Flow(s) no longer needed Delete Service Flow(s) Determine associated CM for this Service Flow(s) Receive DSD-REQ Delete Service Flow(s) Send DSD-RSP ---DSD-RSP--> Receive DSD-RSP <---DSD-REQ--Send DSD-REQ

Figure 11-52 Dynamic Service Deletion Initiated from CMTS2

1. 2.

text replaced per rfi n-00088, 12/6/00, po (s) added per rfi n-00088, 12/6/00, po

299

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.4.4.3 Dynamic Service Deletion State Transition Diagrams

DSD-Local Begin

SF Delete

Disable service flow

DSD-REQ

Start T7 Timer

Save transmitted DSD-REQ

Set DSD-REQ Retries Available to 'DSx Request Retries'

DSD-Local DSD-RSP Pending

Figure 11-53

DSDLocally Initiated Transaction Begin State Flow Diagram

300

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSD-Local DSD-RSP Pending

SF DSD-REQ Lost

Timeout T7

SF Delete-Remote

DSD-RSP

Retries Available ?

Retries Available ? No

Stop T7 Timer

Stop T7 Timer

Yes

Yes DSD Succeeded

Saved DSD-REQ

No

Saved DSD-REQ

DSD Erred

Start T7 Timer Start T7 Timer DSD Ended

Decrement DSD-REQ Retries Available

DSD-Local End

DSD-Local Holding Down

DSD-Local DSD-RSP Pending

Figure 11-54 DSDLocally Initiated Transaction DSD-RSP Pending State Flow Diagram

301

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSD-Local Holding Down

Timeout T7

SF Deleted

DSD-RSP

DSD Ended

DSD Succeeded

DSD-Local End DSD-Local Holding Down

Figure 11-55 DSDLocally Initiated Transaction Holding Down State Flow Diagram

302

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

DSD-Remote Begin

DSD-REQ

Disable service flow

DSD Succeeded

DSD-RSP

Start T10 Timer

Save transmitted DSD-RSP

DSD-Remote Holding Down

Figure 11-56 DSDRemotely Initiated Transaction Begin State Flow Diagram

303

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DSD-Remote Holding Down

SF Deleted

Timeout T10

DSD-REQ

Stop T10 Timer

Saved DSD-RSP

DSD-Remote Holding Down DSD Ended

DSD-Remote End

Figure 11-57

DSDRemotely Initiated Transaction Holding Down State Flow Diagram

11.4.5

Dynamically Changing Downstream and/or Upstream Channels1

11.4.5.1 DCC General Operation

At any time after registration, the CMTS MAY use the DCC-REQ message to direct the CM to change its upstream and/or downstream channel. The CMTS MUST be capable of performing DCC operations to trigger upstream and/or downstream channel changes within a MAC domain and between MAC domains. Physical layer conditions permitting, the CMTS MUST be capable of executing such channel changes using all Initialization Techniques (see Section 11.4.5.1.2). This may be done for load balancing (as described in Section 11.4.5.6), noise avoidance, or other reasons that are beyond the scope of this specification. In addition, the CMTS MUST support DCC operations triggered via SNMP (see [DOCSIS5]). Figure 11-58 through Figure 11-61 show the procedure that MUST be followed by the CMTS when performing a dynamic channel change. Figure 11-62 through Figure 11-65 show the corresponding procedure that MUST be followed by a CM when performing a dynamic channel change. The DCC command can be used to change only the upstream frequency, only the downstream frequency, or both the upstream and downstream frequencies. When only the upstream or only the downstream frequency is changed, the change is typically within a MAC domain. When both the upstream and downstream frequencies are changed, the change may be within a MAC domain, or between MAC domains.

1.

Replaced this section and added subsections per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

304

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The Upstream Channel ID SHOULD be unique between the old and new channels. In this context, the old channel refers to the channel that the CM was on before the jump, and the new channel refers to the channel that the CM is on after the jump. Upon synchronizing with the new upstream and/or downstream channel, the CM MUST use the technique specified in the DCC-REQ Initialization Technique TLV, if present, to determine if it should perform reinitialization, only ranging, or neither. If this TLV is not present in DCC-REQ, the CM MUST re-initialize its MAC on the new channel assignment. (Refer to Section 11.2). If the CM has been instructed to re-initialize, then the CMTS MUST NOT wait for a DCC-RSP to occur on the new channel. If the CM is being moved within a MAC domain, a re-initialization may not be required. If the CM is being moved between MAC domains, a re-initialization may be required. Re-initializing, if requested, is done with the new upstream and downstream channel assignments. It includes obtaining upstream parameters, establish IP connectivity, establish time of day, transfer operational parameters, register, and initialize baseline privacy. If reinitialization is performed, the CM MUST NOT send a DCC-RSP on the new channel. The decision to re-range is based upon the CMTSs knowledge of any path diversity that may exist between the old and new channels, or if any of the fundamental parameters of the upstream or downstream channel such as modulation rate, modulation type, or mini-slot size have changed. When DCC-REQ does not involve re-initialization or re-ranging, the design goal of the CM will typically be to minimize the disruption of traffic to the end user. To achieve this goal, a CM MAY choose to continue to use QoS resources (such as bandwidth grants) on its current channel after receiving a DCC-REQ and before actually executing the channel change. The CM might also need this time to flush internal queues or reset state machines prior to changing channels. The CM MAY continue to use QoS resources on the old channel, including the transmission and reception of packets, after sending a DCC-RSP (depart) message and prior to the actual jump. The CM MAY use QoS resources on the new channel, including the transmission and reception of packets, after the jump and prior to sending a DCC-RSP (arrive) message. The CMTS MUST NOT use the DCC-RSP (depart) message to remove QoS resources on the old channel. The CMTS MUST NOT wait for a DCC-RSP (arrive) message on the new channel before allowing QoS resources to be used. This provision is to allow the Unsolicited Grant Service to be used on the old and new channel with a minimum amount of disruption when changing channels. The CMTS MUST hold the QoS resources on the old channel until a time of T13 has passed after the last DCCREQ that was sent, or until it can internally confirm the presence of the CM on the new channel assignment. The CM MUST execute the departure from the old channel before the expiry of T13. The CM MAY continue to use QoS resources on the old channel after responding with DCC-RSP and before the expiry of T13. If the CM is commanded to perform initial or station maintenance or to use the channel directly, the destination CMTS MUST hold the QoS resources on the new channel until a time of T15 has passed after the last DCC-REQ was sent if the CM has not yet been detected on the new channel. If the CM is commanded to re-initialize the MAC, then QoS resources are not reserved on the destination CMTS, and T15 does not apply. The T15 timer represents the maximum time period for the CM to complete the move to the destination CMTS, and is based on the TLV encodings (i.e. initialization technique TLV) included in the DCC-REQ message and the local configuration of the destination CMTS. The destination CMTS SHOULD calculate and limit T15 based on internal policy according to the guidelines in Section 11.4.5.1.1. If initialization technique of initial ranging is utilized and if the CM arrives after T15 has passed, attempting to use resources on the new channel that have been removed (ranging or requesting bandwidth on a SID that has

305

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

been deleted), the CMTS MUST send a Ranging Abort to the CM in order to cause the DCC transaction to fail, ensuring that the CM and CMTS states remain in sync. When a CM is moved between downstream channels on different IP subnets using initialization techniques other than re-initialize the MAC, a network connectivity issue may occur because no DHCP process is indicated as part of the DCC operation. The CM MAY implement a vendor-specific feature to deal with this situation. The CMTS SHOULD take this issue into account when sending a DCC-REQ and SHOULD direct the CM to use the appropriate initialization technique TLV to ensure no IP connectivity loss as a result of DCC. Once the CM changes channels, all previous outstanding bandwidth requests made via the Request IE or Request/Data IE are invalidated, and the CM MUST re-request bandwidth on the new channel. In the case of Unsolicited Grant Service in the upstream, the grants are implicit with the QoS reservations, and do not need to be re-requested.
11.4.5.1.1 Derivation of T15 Timer

The maximum value noted for the T15 timer denotes the maximum amount of time that the CMTS should reserve resources on the new channel. This value is not to be used to represent acceptable performance. The equation below describes the method for calculating the value of T15. T15 = CmJumpTime + CmtsRxRngReq Each of the variables in the equation calculating the T15 timer is explained in the table below.

Variable

Explanation and Value

CmJumpTime

This is the CMs indication to the CMTS of when it intends to start the jump and how long it will take to jump. For a downstream change, it includes the time for the CM to synchronize to the downstream parameters on the destination channel, such as QAM symbol timing, FEC framing, and MPEG framing. It incorporates CM housecleaning on the old channel. It also incorporates one T11 period for the CM to process and receive the DCC-REQ message. This optional value is computed by the CM and returned in DCC-RSP (depart). If the CM does not specify the Jump Time TLVs, then the destination CMTS assumes that the value is 1.3 seconds. This recognizes the fact that the CM may continue to use the old channel until the expiry of the T13 timer. If the CM specifies the Jump Time TLVs, then the destination CMTS uses the specified value.

CmtsRxRngReq

This variable represents the time for the CM to receive and use a ranging opportunity, and for the CMTS to receive and process the RNG-REQ. For the initialization technique of use directly, this value is two times the CMTS time period between unicast ranging opportunities plus 20 - 40 milliseconds for MAP and RNG-REQ transmission time and CMTS RNG-REQ processing time. For the initialization technique of station maintenance, this value is two times the CMTS time period between unicast ranging opportunities plus 20 - 40 milliseconds for MAP and RNG-REQ transmission time and CMTS RNG-REQ processing time. For the initialization technique of initial maintenance, this value is 30 seconds. Because the variables involved in initial maintenance are not strictly under the control of the CMTS, the computation of this factor is uncertain.

The minimum value of the T15 timer is four seconds; this was derived by quadrupling the value of the T13 timer. The maximum value of the T15 timer is 35 seconds.

306

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4.5.1.2

Initialization Technique1

There are many factors that drive the selection of an initialization technique when commanding a dynamic channel change. While it is desirable to provide the minimum of interruption to existing QoS services such as voice over IP or streaming video sessions, a CM will not be able to successfully execute a channel change given an initialization technique that is unsuitable for the cable plant conditions. In some cases, a CM will impair the new channel given an unsuitable initialization technique. For instance, consider the use of initialization technique 4 (use the new channel(s) directly without re-initializing or performing initial or station maintenance) when there is a significant difference in propagation delay between the old and new channel. Not only will the CM be unable to communicate with the CMTS after the channel change, but its transmissions may also interfere with the transmissions of other CMs using the channel. Careful consideration must be given to the selection of an initialization technique. Some restrictions are listed below. This list is not exhaustive, but is intended to prevent the use of a particular initialization technique under conditions where its use could prevent the CM from successfully executing the channel change. Packets may be dropped under some conditions during channel changes; applications that are running over the DOCSIS path should be able to cope with the loss of packets that may occur during the time that the CM changes channels. If a CM performs a channel change without performing a re-initialization (as defined in Section 8.3.20.1.3), all the configuration variables of the CM MUST remain constant (BPI keys, IP address, Classifiers, PHS Rules, etc.), with the exception of the configuration variables which are explicitly changed by the DCC-REQ message encodings (as defined in Section 8.3.20.1.1 through Section 8.3.20.1.7). The CM will not be aware of any configuration changes other than the ones that have been supplied in the DCC command, so consistency in provisioning between the old and new channels is important. Note that regardless of the initialization technique, the CPE will not be aware of any configuration changes and will continue to use its existing IP address.
11.4.5.1.2.1 Initialization Technique Zero

The use of initialization technique 0 (reinitialize the MAC) results in the longest interruption of service. The CMTS MUST signal the use of this technique when QoS resources will not be reserved on the new channel(s).
11.4.5.1.2.2 Initialization Technique One

The use of initialization technique 1 (broadcast initial ranging) may also result in a lengthy interruption of service. However, this interruption of service is mitigated by the reservation of QoS resources on the new channel(s). The service interruption can be further reduced if the CMTS supplies downstream parameter subTLVs and the UCD substitution TLV in the DCC-REQ in addition to providing more frequent initial ranging opportunities on the new channel.
11.4.5.1.2.3 Initialization Technique Two

The use of initialization technique 2 (unicast ranging) offers the possibility of only a slight interruption of service. In order to use this technique, the CMTS MUST:

Synchronize timestamps (and downstream symbol clocks for S-CDMA support) across the downstream
channels involved and specify SYNC substitution sub-TLV with a value of 1 if the downstream channel is changing

1.

Deleted the last sentence in this section per ECN RFI2-N-03077 by GO on 07/08/03.

307

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Include the UCD substitution in the DCC message if the upstream channel is changing.
However, the CMTS MUST NOT use this technique if:

The DCC-REQ message requires the CM to switch between S-CDMA and TDMA. Propagation delay differences between the old and new channels will cause the CM burst timing to exceed the
ranging accuracy requirements of Section 6.2.19.1.

Attenuation or frequency response differences between the old and new upstream channels will cause the
received power at the CMTS to be outside the limits of reliable reception.
11.4.5.1.2.4 Initialization Technique Three

The use of initialization technique 3 (initial ranging or periodic ranging) offers the possibility of only a slight interruption of service. This value might be used when there is uncertainty when the CM may execute the DCC command and thus a chance that it might miss station maintenance slots. However, the CMTS MUST NOT use this technique if the conditions for using techniques 1 and 2 are not completely satisfied.
11.4.5.1.2.5 Initialization Technique Four

The use of initialization technique 4 (use the new channel without re-initialization or ranging) results in the least interruption of service. In order to use this technique, the CMTS MUST:

Synchronize timestamps (and downstream symbol clocks for S-CDMA support) across the downstream channels involved and specify SYNC substitution sub-TLV with a value of 1 if the downstream channel is changing.

Include the UCD substitution in the DCC message if the upstream channel is changing.
However, the CMTS MUST NOT use this technique if:

The CM is operating in S-CDMA mode and any of the following parameters are changing: Modulation Rate S-CDMA US ratio numerator M S-CDMA US ratio denominator N Downstream channel The DCC-REQ message requires the CM to switch between S-CDMA and TDMA. Propagation delay differences between the old and new channels will cause the CM burst timing to exceed the
ranging accuracy requirements of Section 6.2.19.1.

Attenuation or frequency response differences between the old and new upstream channels will cause the
received power at the CMTS to be outside the limits of reliable reception.

Micro-reflections on the new upstream channel will result in an unacceptable PER (greater than 1%) with the
pre-equalizer coefficients initialized according to Section 6.2.15.

308

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4.5.2

DCC Exception Conditions

If a CM issues a DSA-REQ or DSC-REQ for more resources, and the CMTS needs to do a DCC to obtain those resources, the CMTS will reject the DSA or DSC command without allocating any resources to the CM. The CMTS includes a confirmation code of reject-temporary-DCC (refer to Annex C.1.3.1) in the DSC-RSP message to indicate that the new resources will not be available until a DCC is received. The CMTS will then follow the DSA or DSC transaction with a DCC transaction. After the CM jumps to a new channel and completes the DCC transaction, the CM retries the DSA or DSC command. If the CM has not changed channels after the expiry of T14, as measured from the time that the CM received DSA-RSP or DSC-RSP from the CMTS, then the CM MAY retry the resource request. If the CMTS needs to change channels in order to satisfy a resource request other than a CM initiated DSA or DSC command, then the CMTS should execute the DCC command first, and then issue a DSA or DSC command. If the provisioning system default is to specify the upstream channel ID, the downstream frequency, and/or a downstream channel list in the configuration file, care should be taken when using DCC, particularly when using initialization technique 0 (re-initialize MAC). If a CMTS does a DCC with re-initialize, the config file could cause the CM to come back to the original channel. This would cause an infinite loop. The CMTS MUST NOT issue a DCC command if the CMTS has previously issued a DSA, or DSC command, and that command is still outstanding. The CMTS MUST NOT issue a DCC command if the CMTS is still waiting for a DSA-ACK or DSC-ACK from a previous CM initiated DSA-REQ or DSC-REQ command. The CMTS MUST NOT issue a DSA or DSC command if the CMTS has previously issued a DCC command, and that command is still outstanding. If the CMTS issues a DCC-REQ command and the CM simultaneously issues a DSA-REQ or DSC-REQ then the CMTS command takes priority. The CMTS responds with a confirmation code of reject-temporary (refer to Annex C.1.3.1). The CM proceeds with executing the DCC command. If the CM is unable to achieve communications with a CMTS on the new channel(s), it MUST return to the previous channel(s) and re-initialize its MAC. The previous channel assignment represents a known good operating point which should speed up the re-initialization process. Also, returning to the previous channel provides a more robust operational environment for the CMTS to find a CM that fails to connect on the new channel(s). If the CMTS sends a DCC-REQ and does not receive a DCC-RSP within time T11, it MUST retransmit the DCC-REQ up to a maximum of DCC-REQ Retries (Annex B) before declaring the transaction a failure. Note that if the DCC-RSP was lost in transit and the CMTS retries the DCC-REQ, the CM may have already changed channels. If the CM sends a DCC-RSP on the new channel and does not receive a DCC-ACK from the CMTS within time T12, it MUST retry the DCC-RSP up to a maximum of DCC-RSP Retries (Annex B). If the CM receives a DCC-REQ with the Upstream Channel ID TLV, if present, equal to the current Upstream Channel ID, and the Downstream Frequency TLV, if present, is equal to the current downstream frequency, then the CM MUST consider the DCC-REQ as a redundant command. The remaining DCC-REQ TLV parameters MUST NOT be executed, and the CM MUST return a DCC-RSP, with a confirmation code of reject-alreadythere, to the CMTS (refer to Annex C.4.1).

309

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

If a DOCSIS 2.0-enabled CM is moved from a Type 1 channel to a Type 2 channel via a DCC using an initialization technique other than re-initialize the MAC, the CM MUST operate in 2.0 mode on the destination channel, basing its requests on IUCs 9 and 10 instead of IUCs 5 and 6. If a CM in which DOCSIS 2.0 is disabled in registration is moved from a Type 1 channel to a Type 2 channel via a DCC with initialization technique other than re-initialize the MAC, the CM MUST continue to base its requests on the destination channel on IUCs 5 and 6. A CM in which DOCSIS 2.0 is disabled in registration MUST consider a Type 3 channel to be invalid for any DCC using initialization technique other than re-initialize the MAC. If the CM is moved via a DCC using the initialization technique of re-initialize the MAC, the previous 2.0 enable setting is not applicable. If DOCSIS 2.0 was previously disabled and the target upstream channel is Type 2 or Type 3, the 2.0 disable setting is discarded and the CM MUST use the target upstream channel; however, after reinitialization, the CM MUST operate in the 2.0 mode defined in the config file acquired in the re-initialization process.

310

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4.5.3

DCC State Transition Diagrams

Previous CMTS Operational

New CMTS Operational

Channel Change Required

DCC-RSP (<conf code>)

DCC beginning (from old CMTS), including DCCREQ parameters

DCC-RSP (<conf code>)

Initialization Technique = Reinitialize the MAC? No DCC beginning (to new CMTS), including DCCREQ parameters

ERROR: Unknown DCC transaction

Prepare new channel(s) with any appropriate resource assignments

ERROR: Unknown DCC transaction

Previous CMTS Operational

Start T15

New CMTS Operational

Yes

Set DCC-REQ retry counter to 0

DCC CMTS A

New CMTS DCC-RSP (arrive) Pending

Other event from old CMTS DCC-REQ Ignore the event. Start T11 Start T13

New CMTS Operational

Previous CMTS DCCRSP (depart) Pending

Note that the new CMTS is not informed of the DCC if the CM will Reset the MAC, and it will ignore other events that are sent by the old CMTS in other states.
Dynamically Changing Channels: CMTS View Part 1

Figure 11-58

311

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Previous CMTS DCCRSP (depart) Pending

DCC-RSP (depart)

DCC-RSP (reject<reason>)

Timeout T11

CM Arrived (from new CMTS)

Stop T11

Stop T11

DCC-REQ Retries Exhausted? Yes

Stop T11 Stop T13

DCC-RSP CM Jump Time (to new CMTS)

ERROR: DCC-REQ rejected <reason>

ERROR: CM not responding No

Remove old channel resource assignments.

Previous CMTS DCC T13 Pending

ERROR: DCC-RSP (depart) lost Stop T13 Previous CMTS Operational DCC Aborted (to new CMTS) Increment DCC-REQ retries counter

Previous CMTS Operational

DCC CMTS A

Figure 11-59 Dynamically Changing Channels: CMTS View Part 2

312

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Previous CMTS DCC T13 Pending

Timeout T13

CM Arrived (from new CMTS)

CM no longer present on old channel

1
DCC-RSP (<conf code>)

Stop T13

ERROR: Unknown DCC transaction

Remove old channel resource assignments.

Previous CMTS DCC T13 Pending

Previous CMTS Operational

1 The mechanism to determine

this event is vendor-specific.

Figure 11-60

Dynamically Changing Channels: CMTS View Part 3

313

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

New CMTS DCC-RSP (arrive) Pending

DCC-RSP CM Jump Time (from old CMTS)

CM detected on new channel

1
DCC-RSP (arrive) Timeout T15

DCC Aborted (from old CMTS)

Store Jump Time

DCC-ACK

ERROR: CM not arriving

ERROR: DCC Aborted

Stop T15 Restart T15 Stop T15

New CMTS DCC-RSP (arrive) Pending

Start T10 Remove new channel resource assignments. CM Arrived (to old CMTS) New CMTS Operational New CMTS DCC Hold-down

Determination of this is CMTSspecific, but can include receiving RNG-REQ or bandwidth requests from the CM on the new channel.

New CMTS DCC Hold-down

Timeout T10

DCC-RSP (arrive)

New CMTS Operational

DCC-ACK

New CMTS DCC Hold-down

Figure 11-61 Dynamically Changing Channels: CMTS View Part 4

314

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM Operational

DCC-REQ

Parse DCC-REQ

No DCC-RSP (reject<reason>)

DCC-REQ valid?

Yes

ERROR: Bad CMTS DCC <reason>

Already using US and DS channels?

Yes DCC-RSP (rejectalready-there)

No CM Operational Can jump be made? Yes DCC-RSP (depart) ERROR: DCC-REQ denied Clean up internal queues and other housekeeping CM Operational Apply Id substitutions, store UCD from DCC-REQ (if present)

No DCC-RSP (reject<reason>)

ERROR: Bad CMTS DCC already-there

CM Operational

DCC CM A

Figure 11-62 Dynamically Changing Channels: CM View Part 1

315

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DCC CM A

Downstream Change? No Initialization technique = Re-init the MAC? No Valid UCD for target upstream stored? Yes Wait for SYNCs? No Valid MAP in cache? Yes Initialization technique = Use-Directly? Yes Set DCC-RSP (arrive) retry counter to 0

Yes

CM DCC Downstream Change

Yes

Reset the MAC

Obtain Upstream Parameters CM DCC Acquire UCD

No

Yes

CM DCC Acquire SYNC

No

CM DCC Acquire MAP

No

CM DCC Ranging

DCC CM B

DCC-RSP (arrive)

Start T12

1 The state Obtain

CM DCC-ACK pending

Upstream Parameters links to the state machine in Figure 11-1.

Figure 11-63 Dynamically Changing Channels: CM View Part 2

316

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM DCC Downstream Change

CM DCC Acquire SYNC

Change tuner, attempt downstream lock (using hints provided by CMTS in DCC-REQ, if any)

Wait for a SYNC message (up to Lost SYNC Interval).

Successful lock? Yes {Return to main diagram}

No

SYNC acquired? Yes {Return to main diagram}

No

CM DCC Failed

CM DCC Failed

CM DCC Acquire UCD

1 1

Wait for Valid UCD for target upstream channel (or expiry of T1)

1. If DOCSIS 2.0 is enabled, a valid UCD describes either a type 1, 2, or 3 channel. 2. If DOCSIS 2.0 is NOT enabled, a valid UCD describes a type 1 or type 2 channel.

Valid UCD acquired? Yes {Return to main diagram}

No

CM DCC Failed

CM DCC Acquire MAP

CM DCC Ranging

Wait for a MAP message.

Perform ranging as required (initial/ station).

MAP acquired? Yes {Return to main diagram}

No

Ranging Success? Yes {Return to main diagram}

No

CM DCC Failed

CM DCC Failed

2 See Figures 11-6

and 11-7 for details.

Figure 11-64 Dynamically Changing Channels: CM View Part 3

317

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

CM DCC-ACK pending

Timeout T12

DCC-ACK

DCC-RSP retries exhausted? No Increment DCC-RSP (arrive) retry counter Yes

Parse DCC-ACK

DCC-ACK valid?

No ERROR: Bad CMTS DCCACK

Yes

DCC CM B

ERROR: DCC-ACK not received

Stop T12

CM DCC-ACK pending

CM Operational

CM DCC Failed

ERROR: DCC failed <reason>

Return to old upstream/ downstream.

Reset the MAC

Obtain Upstream Parameters

The state Obtain Upstream Parameters links to the state machine in Figure 9-1.

Figure 11-65

Dynamically Changing Channels: CM View Part 4

318

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

11.4.5.4

DCC Performance

The purpose of a DCC is to move the CM to a new upstream and/or downstream channel with little interruption of service. There are many factors that affect the performance of a DCC transaction including CM housecleaning, initialization technique, and the number of TLV hints given by the current CMTS in the DCCREQ message. Each of these factors is individually discussed in Table 11-1 below. The DCC transaction is defined from the perspective of both the CM and the CMTS for the discussion on performance in the following table. From the perspective of the CM, the DCC transaction begins when the CM receives the DCC-REQ message from the CMTS and completes when the CM receives the DCC-ACK message from the CMTS. From the perspective of the CMTS, the DCC transaction begins when the CMTS sends the DCC-REQ message to the CM and completes when the CMTS receives the DCC-RSP (arrive) message from the CM.
Table 11-1 Factors affecting DCC performance
TLV Type Value Explanation

Initialization Technique

Absent or 0 Reinitialize MAC 1 Broadcast Initial Ranging 2 Unicast Ranging 3 Broadcast or Unicast Ranging 4 Use Channel Directly

There are no performance requirements in this case. The CM will arrive on the destination CMTS after initialization occurs.

There are low performance expectations in this case because many factors affect the performance, such as collisions and ranging backoff. The CM should arrive on the destination CMTS as quickly as possible. The DCC transaction SHOULD complete within 1.5 seconds after the start of jump.

The CMTS does not know which ranging technique the CM will utilize. The CM should arrive on the destination CMTS as quickly as possible.

The DCC transaction SHOULD complete within one second after the start of jump.

DS Parameter

The CMTS SHOULD include the downstream parameter TLVs for station maintenance and use directly initialization techniques that are expected to occur quickly. The CMTS MUST set the UCD substitution TLV according to Section 11.4.5.1.2. The CMTS MUST set the SYNC substitution TLV according to Section 11.4.5.1.2. The length of jump TLV SHOULD be less than one second for downstream channel changes that include the downstream parameter TLVs or for upstream only channel changes.

UCD Substitution SYNC Substitution CM Jump Time

When the DCC-REQ does not contain UCD Substitution TLVs and/or specifies an Initialization Technique of Initial Maintenance, Station Maintenance, or use directly, the destination CMTS SHOULD increase the probability that the CM will arrive quickly by using the CM Jump Time TLVs specified in the DCC-RSP (depart) to adjust the transmission of UCDs and ranging opportunities such that they coincide with the time when CM has estimated that it will arrive, and SHOULD increase the frequency of UCDs and/or ranging opportunities during this period.

319

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.4.5.5 Example Operation 11.4.5.5.1 Example Signalling

Figure 11-66 shows an example of the use of DCC and its relation to the other DOCSIS MAC messages. In particular, this example describes a scenario where the CM attempts to allocate new resources with a DSA message. The CMTS temporarily rejects the request, tells the CM to change channels, and then the CM rerequests the resources. This example (not including all exception conditions) is described below. Refer to Section 11.2 for more detail. a) An event occurs, such as the CM issuing a DSA-REQ message.

b) The CMTS decides that it needs the CM to change channels in order to service this resource request. The CMTS responds with a DSA-RSP message which includes a confirmation code of reject-temporary-DCC (refer to Annex C.1.3.1) in the DSC-RSP message to indicate that the new resources are not available until a DCC is received. The CMTS now rejects any further DSA or DSC messages until the DCC command is executed. c) The CMTS initiates QoS reservations on the new upstream and/or downstream channels. The QoS reservations include the new resource assignment along with all the current resource assignments assigned to the CM. In this example, both the upstream and downstream channels are changed.

d) To facilitate a near-seamless channel change, since the CMTS is not sure exactly when the CM will switch channels, the CMTS duplicates the downstream packet flow on the old and new downstream channels. e) f) The CMTS issues a DCC-REQ command to the CM. The CM cleans up its queues and state machines as appropriate, sends a DCC-RSP (depart) and changes channels.

g) If there was a downstream channel change, the CM synchronizes to the QAM symbol timing, synchronizes the FEC framing, and synchronizes with the MPEG framing. h) If the CM has been instructed to re-initialize, it does so with the new upstream and/or downstream channel assignment. The CM exits from the flow of events described here, and enters the flow of events described in Section 11.2 starting with the recognition of a downstream SYNC message. i) j) The CM searches for a UCD message unless it has been supplied with a copy. The CM waits for a downstream SYNC message unless it has been instructed not to wait for one.

k) The CM collects MAP messages unless it already has them available in its cache. l) The CM performs ranging if required by the initialization technique TLV.

m) The CM resumes normal data transmission with its new resource assignment. n) The CM sends a DCC-RSP (arrive) message to the CMTS. o) The CMTS responds with a DCC-ACK. p) The CMTS removes the QoS reservations from the old channels. If the downstream packet flow was duplicated, the packet duplication would also be removed on the old downstream channel. q) The CM re-issues its DSA-REQ command. r) s) The CMTS reserves the requested resources and responds with a DSA-RSP. The CM finishes with a DSA-ACK.

320

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CMTS

DS #1

US #1

CM

US #2

DS #2

data traffic data traffic

DSA-REQ DSA-RSP DSA-ACK Start T14 data traffic data traffic DCC-REQ Start T11, T13 DCC-RSP CM changes channels Sync of QAM, FEC, MPEG data traffic reserve resources and duplicate downstream traffic

Optional re-initialize and exit from flow UCD (optional) SYNC (optional) MAP (optional)

Optional re-range data traffic data traffic data traffic DCC-RSP release resources and stop traffic duplication Start T12 DCC-ACK DSA-REQ DSA-RSP DSA-ACK

Figure 11-66 DCC Example Operational Flow

321

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The states for the old and new CMTSes are shown as separate flow diagrams, since the old and new CMTS may be different. If the CMTSes are the same (e.g., the same MAC domain), the CMTS will need to run both sets of state machines concurrently. The flow diagrams show points where explicit signaling between the old and new CMTS is desirable, especially for near-seamless operation. The mechanism for this signaling is beyond the scope of this specification. Note that the flow diagrams for both old and new CMTSes have been carefully crafted to handle many error conditions, such as:

If the CM does not respond to the DCC-REQ (or responds with a reject conf code) and does not move, then it
will be allowed to remain on the old channel. Resources on the new channel will be released (old CMTS signals DCC aborted to the new CMTS).

If the CM DCC-RSP (depart) is lost, but the CM moves and arrives on the new CMTS, the new CMTS will
signal that the CM has arrived to the old CMTS, allowing it to remove resources.

If the CM DCC-RSP (depart) is received and the CM DCC-RSP (arrive) is lost, but the new CMTS otherwise
detects the presence of the CM, the DCC transaction is considered successful, and the CM is allowed to remain on the new channel.

If the CM DCC-RSP (depart) and (arrive) are lost, but the new CMTS otherwise detects the presence of the
CM, the new CMTS will signal that the CM has arrived to the old CMTS, allowing it to remove resources, and the CM is allowed to remain on the new channel.

If the CM DCC-RSP (depart) is received, but the CM never arrives, the new CMTS will detect this and
remove resources after T15 expires.

If the CM DCC-RSP (depart) is lost and the CM never arrives, the old CMTS will signal DCC aborted to the
new CMTS, allowing it to remove resources. The old CMTS will use a different mechanism outside the scope of the DCC flow diagrams (such as ranging time out) to remove resources on the old channels.

If the CMTS DCC-ACK is lost and the DCC-RSP retry counter is expired, the CM will log and error and continue to the operational state. There is a race condition that is not addressed in the flow diagrams; if the CM DCC-RSP (depart) is lost, the old CMTS will signal DCC aborted to the new CMTS. If the CM is in the process of moving, but has not yet arrived, the new CMTS will remove resources. This will prevent the CM from arriving successfully, unless it is able to complete the jump and arrive in approximately 1.2 seconds (3 retries of the DCC-REQ).
11.4.5.5.2 11.4.5.5.2.1 Example Timing Upstream and Downstream Change (Use Channel Directly: CMTS Supplies All TLV Hints)

In this example, the current CMTS sends a DCC-REQ message requesting that the CM switch both upstream and downstream channels. The DCC-REQ message includes the UCD substitution TLV, the SYNC substitution TLV, the downstream parameter TLVs, and the initialization technique TLV of 4 (use channel directly). The CM does not include the CM jump time TLV in the DCC-RSP. The destination CMTS has the following local parameters: UCD interval 1 second SYNC interval 10 msec. Unicast ranging interval 1 sec. The destination CMTS calculates the T15 timer value. The definition of the formula used to determine T15 is shown below. The variables used in calculating T15 are explained in the table below.

322

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

T15 = CmJumpTime + CmtsRxRngReq T15 = 1.3 sec. + (2.04 sec.) = 3.34 sec Since 3.34 sec is less than the minimum value of the T15 timer, the CMTS sets the T15 timer to the minimum value for 4 seconds.
Variable Value Explanation

CmJumpTime CmtsRxRngReq

1.3 sec. 2.04 sec 2 * (1 sec.) + 40 msec.

Since the CM did not include the optional jump time TLV, the CMTS will use the default value of 1.3 seconds. Two times the CMTS time period between unicast ranging opportunities plus 20 - 40 milliseconds for MAP and RNGREQ transmission time and CMTS RNG-REQ processing time.

The CM synchronizes to the downstream parameters on the new channel, applies the UCD supplied in the DCCREQ, collects MAP messages on the new channel, and resumes normal data transmission on the destination channels. This occurs within the recommended performance of 1 second.
11.4.5.5.2.2 Upstream and Downstream Change (Station maintenance: CMTS Supplies No TLV Hints)

In this example, the current CMTS sends a DCC-REQ message requesting that the CM switch both upstream and downstream channels. The DCC-REQ message includes the initialization technique TLV of 2 (perform station maintenance). It also includes the required UCD substitution TLV and SYNC substitution sub-TLV. The CM does not include the CM jump time TLV in the DCC-RSP. The destination CMTS has the following local parameters: UCD interval 1 second SYNC interval 10 msec. Unicast ranging interval 5 sec. The destination CMTS starts scheduling the CM immediately after it sends the DCC-REQ. The destination CMTS calculates the T15 timer value. The definition of the formula used to determine T15 is shown below. The variables used in calculating T15 are explained in the table below. T15 = CmJumpTime + CmtsRxRngReq T15 = 1.3 sec. + (10.04 sec.) = 11.34 sec.
Variable Value Explanation

CmJumpTime CmtsRxRngReq

1.3 sec. 10.04 sec 2 * (5 sec.) + 40 msec.

Since the CM did not include the optional jump time TLV, the CMTS will use the default value of 1.3 seconds. Two times the CMTS time period between unicast ranging opportunities plus 20 - 40 milliseconds for MAP and RNGREQ transmission time and CMTS RNG-REQ processing time.

The CM should synchronize to the downstream parameters on the new channel, apply the UCD message provided, collect MAP messages on the destination channel without waiting for a downstream SYNC on the destination channel, perform station maintenance on the destination channel, and resume normal data transmission on the destination channels.

323

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

These events occur in less than two seconds; this is within the acceptable performance criteria. The DCC transaction occurred within the recommended four second sum of CM jump time and two ranging intervals (0 + 2 sec. = 2 sec.)
11.4.5.6 Autonomous Load Balancing

The CMTS MUST be capable of autonomous load balancing of CMs across all of its upstream and downstream channels using the DCC-REQ message, plant configuration permitting. Load balancing is manageable on a per-CM basis. The CMTS assigns each CM:

to a set of channels (a Load Balancing Group) among which it can be moved by the CMTS; a policy which governs if and when the CM can be moved; a priority value which can be used by the CMTS in order to select CMs to move.
11.4.5.6.1 Load Balancing Groups

A Load Balancing Group is a cluster of downstream and associated upstream physical channels among which modems can be autonomously load balanced. The operator must define Load Balancing Groups to be consistent with the physical plant topology. Load Balancing Groups can be defined in order to cater to a specific class of service (e.g. residential or business). There are two types of Load Balancing Groups, General Load Balancing Groups and Restricted Load Balancing Groups. A Restricted Load Balancing Group is associated with a specific, provisioned set of cable modems, while General Load Balancing Groups are open for CMs which are not provisioned into a Restricted Load Balancing Group. General Load Balancing Groups can only be used when the plant topology allows the location of CMs to be unambiguously determined by the upstream channel on which they have registered. Restricted Load Balancing Groups are used to accommodate a topology specific or provisioning specific restriction (such as a set of channels reserved for business customers). A Restricted Load Balancing Group could be a subset of one or more General Load Balancing Groups. The CMTS MUST NOT associate an upstream channel with more than one General Load Balancing Group. The CMTS can associate an upstream channel with any number of Restricted Load Balancing Groups (and potentially a single General Load Balancing Group as well). The CMTS can associate a downstream channel with any number of Load Balancing Groups, General and/or Restricted. The CMTS assigns modems to General Load Balancing Groups based on the upstream channel on which they are operating. The CMTS will assign a modem to a Restricted Load Balancing Group only if it is explicitly provisioned (via SNMP or configuration file TLV) to be a member of that group. The CMTS MUST NOT assign a CM to more than one Load Balancing Group. When the CMTS receives a REG-REQ message, the CMTS MUST identify whether this CM has been assigned to a Restricted Load Balancing Group via SNMP (see [DOCSIS5]). If the CM is not assigned to a Restricted Load Balancing Group via SNMP, the CMTS MUST check for the presence of the CM Load Balancing Group TLV in the REG-REQ message to identify assignment to a Restricted Load Balancing Group. If the CM is assigned to a Restricted Load Balancing Group via SNMP, the CMTS MUST ignore the CM Load Balancing Group TLV in the REG-REQ message. If the REG-REQ contains a General Load Balancing Group ID or a group ID that is not defined on the CMTS, the CMTS MUST ignore the group ID. If the CM has been assigned to a Restricted Load Balancing Group (either via SNMP or via the Config File), and the CMTS detects that the CM is registering on a channel pair that is not associated with the assigned Load Balancing Group, when registration completes, the CMTS MUST initiate a DCC-REQ to move the CM to the appropriate channel(s) in the assigned group. If the CM has not been assigned to a Restricted Load Balancing
324

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Group via SNMP or the Config File, the CMTS MUST assign it to the General Load Balancing Group that corresponds to the upstream channel on which it registered. If the upstream channel is not associated with a General Load Balancing Group, the CMTS MUST NOT assign the CM to any Load Balancing Group. As part of autonomous load balancing operations, the CMTS MUST adhere to the following restrictions:

The CMTS MUST NOT direct a CM to move to a channel outside the Load Balancing Group to
which it is assigned.

If a CM is not assigned to a Load Balancing Group, the CMTS MUST NOT move the CM. The CMTS MUST NOT move a DOCSIS 1.0 or DOCSIS 1.1 compliant CM, or a DOCSIS 2.0
compliant CM that has 2.0 mode disabled, to a type 3 upstream channel. If, during normal operation, the CMTS is directed (via SNMP or otherwise) to move a CM to a channel that is outside the Load Balancing Group to which it is assigned, the CMTS MUST assign the CM to the appropriate General Load Balancing Group based on the new upstream channel, or to no Load Balancing Group if the new upstream channel is not associated with a General Load Balancing Group. Note that a CM provisioned into a Restricted Load Balancing Group will (unless the provisioning is changed) be returned to its provisioned group by the CMTS upon a re-initialize MAC operation. Thus, a manual DCC operation which moves a CM outside of its Restricted Load Balancing Group will generally be only a temporary move, until the CM re initializes. Further, specifying initialization technique zero in the DCC request would result in the CM being returned immediately to its provisioned group.
11.4.5.6.2 Initialization Techniques

The description of a Load Balancing Group includes the initialization technique(s) that could be used when autonomously load balancing a cable modem within the group. The initialization technique definition for each Load Balancing Group is represented in the form of a bit map, with each bit representing a specific technique (bits 0-4). The CMTS MUST support, via SNMP, the override of this initialization technique for channel changes between specific pairs of logical upstream channels. If an override is present for a particular pair of channels, the CMTS MUST use the initialization technique for the channel pair. Otherwise, the CMTS MUST use the default initialization technique definition for the Load Balancing Group.
11.4.5.6.3 Load Balancing Policies

Load balancing policies allow control over the behavior of the autonomous load balancing process on a per-CM basis. A load balancing policy is described by a set of conditions (rules) that govern the autonomous load balancing process for the CM. When a load balancing policy is defined by multiple rules, all of the rules apply in combination. Load balancing rules and the load balancing policy definition mechanism have been created to allow for specific vendor-defined load balancing actions. However, there are two basic rules that the CMTS is required to support. The CMTS MUST support the following basic rules:

Prohibit load balancing using a particular CM Prohibit load balancing using a particular CM during certain times of the day
The policy ID value of zero is reserved to indicate the CMTS's basic load balancing mechanism, which does not need to be defined by a set of rules.

325

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Each Load Balancing Group has a default load balancing policy. During the registration process, the CMTS MUST assign the CM a load balancing policy ID. The policy ID may be assigned to a cable modem via the cable modem config file. The CMTS MUST assign the CM the load balancing policy ID provisioned in the Config File and sent in the REG-REQ, if it exists. Otherwise, the CMTS MUST assign the CM the default policy ID defined for the Load Balancing Group. The per-CM load balancing policy ID assignment can be modified at any time while the CM is in the operational state via SNMP or internal CMTS processes, however the policy ID is always overwritten upon receipt of a REG-REQ message.
11.4.5.6.4 Load Balancing Priorities

A Load Balancing priority is an index that defines a rank or level of importance, which is used to apply differential treatment between CMs in the CMTS's load balancing decision process. In general, a lower load balancing priority indicates a higher likelihood that a CM will be moved due to load balancing operations. The CMTS MAY take many factors into account when selecting a CM to move, of which priority is only one. When other factors are equal, the CMTS SHOULD preferentially move a CM with lower load balancing priority over one with higher load balancing priority. The CMTS MUST associate each cable modem with a load balancing priority. Priority may be assigned to a cable modem via the cable modem config file. The CMTS MUST assign the CM the load balancing priority provisioned in the config File and sent in the REG-REQ, if it exists. If a Cable Modem has not been assigned a priority, the cable modem is associated with the default (lowest) load balancing priority value of zero. The per-CM load balancing priority assignment can be modified at any time while the CM is in the operational state via SNMP or internal CMTS processes as dictated by a specific load balancing policy; however, the priority assignment is always overwritten upon receipt of a REG-REQ message.
11.4.5.6.5 Load Balancing and Multicast

The IGMP protocol requires hosts to suppress IGMP messages that are not necessary for the router to maintain multicast group membership state. Section 5.3.1 of this specification extends these IGMP requirements to the DOCSIS access network by requiring CMs to suppress messages that are deemed to be superfluous for the CMTS. As a result, the CMTS is not guaranteed to be aware of multicast group membership on a per-CM basis. For an active multicast group, there could be any number of CMs that have group members and that are actively forwarding multicast traffic, but that have not sent a Membership Report to the CMTS. This lack of CMTS awareness can create a situation in which load balancing and multicast conflict. In order to efficiently manage multicast traffic and balance load across a Load Balancing Group, it is reasonable to expect that the CMTS might attempt to reduce the amount of duplicated multicast traffic by consolidating all members for a specific multicast group to a single downstream channel in the Load Balancing Group. More generally, a load balancing algorithm will perform more effectively if it takes into account both the unicast and multicast traffic load for each CM when making decisions on where and when to move CMs. This is made difficult when the CMTS is unaware of which CMs have multicast group members and which don't. If a CM with active multicast sessions is moved from its current downstream to a new downstream that is not carrying the multicast traffic, the session will be interrupted until the CM or CPE sends a Membership Report. In order to reduce the interruption of multicast service, CMs that implement active IGMP mode (see Section 5.3.1) SHOULD send a Membership Report for all active multicast groups upon completion of a DCC operation that involves a downstream channel change.

326

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The multicast issues are alleviated to some degree when BPI+ is enabled, and are alleviated further when multicast traffic is encrypted using dynamic security associations (see [DOCSIS8]). When BPI+ is enabled, a CM will, upon receiving an IGMP "join" message on its CPE interface, send a SA Map Request message to the CMTS. Since this message is only sent at the moment multicast group membership begins, it does not provide any indication of ongoing membership. Because multicast group membership can be transient, the past receipt of a Map Request for a particular multicast group, although necessary, is not a sufficient condition to alert the CMTS that the CM currently has members for that multicast group. The absence of a Map Request is sufficient evidence that the CM does not have members for the multicast group. If the multicast traffic for a particular multicast group is encrypted using a dynamic security association, the CMTS can monitor the reception of TEK Key Requests and gain knowledge of multicast group membership. Since it is optional functionality for a CM to stop the TEK state machine (and discontinue sending Key Requests) when there are no longer members for multicast groups mapped to a particular security association, the continued receipt of Key Requests by the CMTS does not necessarily indicate continued multicast group membership. The lack of continuing Key Requests, however, does indicate lack of members.
11.4.5.6.6 Examples Demonstrating Autonomous Load Balancing

Figure 11-67 shows an example combining network which illustrates the definition of General Load Balancing Groups and the use of Restricted Load Balancing Groups to resolve topological ambiguities.
Fiber Nodes DS
4w H 1

US0

US1
2w

H L

CMTS

US2
3 H

US3
2w

US4

2w H 2w L

US5

Figure 11-67 Example Combining Network 1

327

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

In this example, there are six upstream channels (US0 - US5) that are members of a single MAC domain. All six upstream channels are associated with a single downstream channel (DS). The downstream is split over all four fiber nodes, while the six upstreams return from the four nodes via the combining network shown, such that each upstream channel is not physically connected to each fiber node. In particular, fiber node 1 connects to US0 only, fiber node 2 connects to both US1 and US2, fiber node 3 connects to both US3 and US4, and fiber node 4 connects to both US4 and US5. In this situation, the Load Balancing Groups could be defined as follows:
Load Balancing Group1:
Group ID: Type: Downstream Channels: Upstream Channels: 1 General DS US1, US2

Load Balancing Group 2:

Group ID: Type: Downstream Channels: Upstream Channels: 2 Restricted DS US3, US4

Load Balancing Group 3:

Group ID: Type: Downstream Channels: Upstream Channels: 3 Restricted DS US4, US5

Note that a REG-REQ on either upstream channel US1 or US2 uniquely identifies the Load Balancing Group to which a CM can be assigned, hence those two channels form the General Load Balancing Group 1. Upstream channels US3 - US5 have a more complex topology, since US4 is shared across two fiber nodes. To resolve the topological ambiguities that would arise by a REG-REQ received on US4, two Restricted Load Balancing Groups have been defined (Group IDs 2 & 3). In order to be load balanced, each CM that is attached to fiber node 3 would need to be provisioned to be a member of Restricted Load Balancing Group 2, while each CM attached to fiber node 4 would need to be provisioned into Restricted Load Balancing Group 3. If a CM were to register on one of these channels without having been provisioned into the appropriate Restricted Load Balancing Group, the CMTS would not associate the CM with any Load Balancing Group (which results in the CM not being load balanced). Also, note that US0 is not a member of any Load Balancing Group. CMs which register on that upstream channel will not be load balanced to another channel. Figure 11-68 shows a second example, in which two MAC domains are shared across two fiber nodes in a complex combining network. In this example, a pair of upstream channels (one from each MAC domain) are set

328

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

aside for a particular customer group (e.g. business customers), a Restricted Load Balancing Group is formed to allow load balancing for those customers.

DS0
2w 2w

US00 Fiber Nodes US01 US02

4w H L 1

US03 CMTS US13

2 2w 2w

US12 US11 US10 DS1

4w

H L

Figure 11-68 Example Combining Network 2

Load Balancing Group 1:

Group ID: Type: Downstream Channels: Upstream Channels: Subgroup: 1 General DS0, DS1 US00, US01, US12 DS0, US00, US01

Load Balancing Group 2:

Group ID: Type: Downstream Channels: Upstream Channels: Subgroup: 2 General DS0, DS1 US10, US11, US02 DS1, US10, US11

Load Balancing Group 3:

Group ID: Type: Downstream Channels: Upstream Channels: 3 Restricted DS0, DS1 US03, US13

329

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

11.5

Fault Detection and Recovery

Fault detection and recovery occurs at multiple levels.

At the physical level, FEC is used to correct errors where possible refer to Section 6 for details. The MAC protocol protects against errors through the use of checksum fields across both the MAC Header
and the data portions of the packet - refer to Section 8 for details.

All MAC management messages are protected with a CRC covering the entire message, as defined in Section
8. Any message with a bad CRC MUST be discarded by the receiver. Table 11-2 shows the recovery process that MUST be taken following the loss of a specific type of MAC message. SP-OSSIv2.0 [DOCSIS5] appendix F contains a list of error codes with more useful information as to the failure of the PHY and MAC layers. Refer to Section 8.2.8 for additional information.
Table 11-2
Message Name

Recovery Process on Loss of Specific MAC Messages

Action Following Message Loss

SYNC

The CM can lose SYNC messages for a period of the Lost SYNC interval (see Annex B) before it has lost synchronization with the network. A CM that has lost synchronization MUST NOT use the upstream and MUST try to re-establish synchronization. During CM initialization the CM MUST receive a usable1 UCD before transmitting on the upstream. When in the Obtain Upstream Parameters state of CM initialization process, if the CM doesnt receive a usable UCD within the T1 timeout period, the CM MUST NOT transmit on the upstream and MUST scan for another downstream channel. After receiving a usable UCD, whenever the CM receives an unusable UCD or a MAP with a UCD Count that doesnt match the Configuration Change Count of the last UCD received, the CM MUST NOT transmit on the upstream and MUST start the T1 timer. If the T1 timer expires under these circumstances, the CM MUST reset and reinitialize its MAC connection. A CM MUST NOT transmit without a valid upstream bandwidth allocation. If a MAP is missed due to error, the CM MUST NOT transmit for the period covered by the MAP. If a CM fails to receive a valid ranging response within a defined time out period after transmitting a request, the request MUST be retried a number of times (as defined in Annex B). Failure to receive a valid ranging response after the requisite number of attempts MUST cause the modem to reset and reinitialize its MAC connection. If a CM fails to receive a valid registration response within a defined time out period after transmitting a request, the request will be retried a number of times (as defined in Annex B). Failure to receive a valid registration response after the requisite number of attempts will cause the modem to reset and reinitialize its MAC connection. If a CMTS fails to receive a valid upstream channel change response within a defined time out period after transmitting a request, the request MUST be retried a number of times (as defined in Annex B). Failure to receive a valid response after the requisite number of attempts MUST cause the CMTS to consider the CM as unreachable.

UCD

MAP RNG-REQ RNG-RSP

REG-REQ REG-RSP

UCC-REQ UCC-RSP

1.

A usable UCD is one that contains legal profiles that the modem can understand. The CM MAY also require that the UCD Count of the MAPs received match the Configuration Change Count field of the last received UCD before it considers the UCD as usable.

Messages at the network layer and above are considered to be data packets by the MAC Sublayer. These are protected by the CRC field of the data packet and any packets with bad CRCs are discarded. Recovery from these lost packets is in accordance with the upper layer protocol.
11.5.1 Prevention of Unauthorized Transmissions

A CM SHOULD include a means for terminating RF transmission if it detects that its own carrier has been on continuously for longer than the longest possible valid transmission.
330

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

12 Supporting Future New Cable Modem Capabilities

12.1 Downloading Cable Modem Operating Software
A CMTS SHOULD be capable of being remotely reprogrammed in the field via a software download over the network. The cable modem MUST be capable of being remotely reprogrammed in the field via a software download over the network. This software download capability MUST allow the functionality of the cable modem to be changed without requiring that cable system personnel physically revisit and reconfigure each unit. It is expected that this field programmability will be used to upgrade cable modem software to improve performance, accommodate new functions and features (such as enhanced class of service support), correct any design deficiencies discovered in the software, and to allow a migration path as the Data Over Cable Interface Specification evolves. The mechanism used for download MUST be TFTP file transfer. The mechanism by which transfers are secured and authenticated is in [DOCSIS8]. The transfer MUST be initiated in one of two ways:

An SNMP manager requests the CM to upgrade. If the Software Upgrade File Name in the CMs configuration file does not match the current software image
of the CM, the CM MUST request the specified file via TFTP from the Software Server.
Note: The Software Server IP Address is a separate parameter. If present, the CM MUST attempt to download the specified file from this server. If not present, the CM MUST attempt to download the specified file from the configuration file server.

The CM MUST verify that the downloaded image is appropriate for itself. If the image is appropriate, the CM MUST write the new software image to non-volatile storage. Once the file transfer is completed successfully, the CM MUST restart itself with the new code image. If the CM is unable to complete the file transfer for any reason, it MUST remain capable of accepting new software downloads (without operator or user interaction), even if power or connectivity is interrupted between attempts. The CM MUST log the failure and MAY report it asynchronously to the network manager. Following upgrade of the operational software, the CM MAY need to follow one of the procedures described above in order to change channels to use the enhanced functionality. If the CM is to continue to operate in the same upstream and downstream channels as before the upgrade, then it MUST be capable of inter-working with other CMs which may be running previous releases of software. Where software has been upgraded to meet a new version of the specification, then it is critical that it MUST inter-work with the previous version in order to allow a gradual transition of units on the network.

331

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

332

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex A Well-Known Addresses

A.1 MAC Addresses
MAC addresses described here are defined using the Ethernet/ISO8802-3 [ISO8802-3] convention as bit-littleendian. The following multicast address MUST be used to address the set of all CM MAC sublayers; for example, when transmitting Allocation Map PDUs: 01-E0-2F-00-00-01 The addresses in the range 01-E0-2F-00-00-02 through 01-E0-2F-00-00-0F are reserved for future definition. Frames addressed to any of these addresses SHOULD NOT be forwarded out of the MAC-sublayer domain.

A.2 MAC Service IDs

The following MAC Service IDs have assigned meanings. Those not included in this table are available for assignment, either by the CMTS or administratively.
A.2.1 All CMs and No CM Service IDs

The following Service IDs are used in MAPs for special purposes or to indicate that any CM can respond in the corresponding interval. 0x0000 is addressed to no CM. This address is typically used when changing upstream burst parameters so that CMs have time to adjust their modulators before the new upstream settings take effect. This is also the Initialization SID used by the CM during initial ranging. 0x3FFF is addressed to all CMs. It is typically used for broadcast Request intervals or Initial Maintenance intervals.
A.2.2 Well-Known Multicast Service IDs

The following Service IDs are only used for Request/Data IEs. They indicate that any CM can respond in a given interval, but that the CM must limit the size of its transmission to a particular number of mini-slots (as indicated by the particular multicast SID assigned to the interval). 0x3FF1-0x3FFE is addressed to all CMs. IDs in this range are available for small data PDUs, as well as requests (used only with request/data IEs). The last digit indicates the frame length and transmission opportunities as follows: 0x3FF1: Within the interval specified, a transmission may start at any mini-slot, and must fit within one mini-slot. 0x3FF2: Within the interval specified, a transmission may start at every other mini-slot, and must fit within two mini-slots (e.g., a station may start transmission on the first mini-slot within the interval, the third mini-slot, the fifth, etc.).

333

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

0x3FF3: Within the interval specified, a transmission may start at any third mini-slot, and must fit within three mini-slots (e.g., starts at first, fourth, seventh, etc.). 0x3FF4: Starts at first, fifth, ninth, etc. ... 0x3FFD: Starts at first, fourteenth (14th), twenty-seventh (27th), etc. 0x3FFE: Within the interval specified, a transmission may start at any 14th mini-slot, and must fit within 14 mini-slots.
A.2.3 Priority Request Service IDs

The following Service IDs (0x3Exx) are reserved for Request IEs (refer to Annex C.2.2.5.1). If 0x01 bit is set, priority zero can request. If 0x02 bit is set, priority one can request. If 0x04 bit is set, priority two can request. If 0x08 bit is set, priority three can request. If 0x10 bit is set, priority four can request. If 0x20 bit is set, priority five can request. If 0x40 bit is set, priority six can request. If 0x80 bit is set, priority seven can request. Bits can be combined as desired by the CMTS upstream scheduler for any Request IUCs.

A.3 MPEG PID

All DOCSIS data MUST be carried in MPEG-2 packets with the header PID field set to 0x1FFE.

334

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex B Parameters and Constants

System Name Time Reference Minimum Value Default Value Maximum Value

CMTS CMTS CMTS

Sync Interval UCD Interval Max MAP Pending

Nominal time between transmission of SYNC messages (refer to Section 8.3.2) Time between transmission of UCD messages (refer to Section 8.3.3) The number of mini-slots that a CMTS is allowed to map into the future (refer to Section 8.3.4) Time between transmission of broadcast Ranging requests (refer to Section 9.3.3) Time since last received Sync message before synchronization is considered lost Number of Retries on contention Ranging Requests (refer to Section 11.2.4) Number of Retries on inviting Ranging Requests (refer to Section 11.2.4) Number of retries on bandwidth allocation requests Number of retries on registration requests/responses Number of retries on immediate data transmission Time provided between arrival of the last bit of a MAP at a CM and effectiveness of that MAP (refer to Section 9.1.5) Minimum time allowed for a CM following receipt of a ranging response before it is expected to reply to an invited ranging request The maximum time allowed for a CM, following receipt of a configuration file, to send a Registration Request to a CMTS. Wait for UCD timeout 16 16 16 3

200 msec 2 sec 4096 minislot times 2 sec 600 msec

CMTS CM CM CM, CMTS CM CM CMTS CM CMTS

Ranging Interval Lost Sync Interval Contention Ranging Retries Invited Ranging Retries Request Retries Registration Request/ Response Retries Data Retries CM MAP processing time

16 (200 + M/ 5.12) s (ref Section 6.2.17) 1 msec

CMTS

CM Ranging Response processing time CM Configuration

CMTS

30 sec

CM

T1

5 * UCD interval maximum value 5 * ranging interval 50 msec 30 sec 200 msec 200 msec 35 sec

CM CM CM

T2 T3 T4

Wait for broadcast ranging timeout Wait for ranging response Wait for unicast ranging opportunity. If the pending-till-complete field was used earlier by this modem, then the value of that field must be added to this interval. Wait for Upstream Channel Change response Wait for REG-RSP and REG-ACK Size of mini-slot for upstream transmission. For channels that support DOCSIS 1.x CMs. 32 modulation intervals

CMTS CM CMTS CM CMTS

T5 T6 Mini-slot size for 1.x channels.

2 sec 3 sec

335

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

System

Name

Time Reference

Minimum Value

Default Value

Maximum Value

CM CMTS CM CMTS CM CMTS CM CMTS CM CMTS CM CMTS CM CM CM CM CM CM CM CMTS

Mini-slot size for DOCSIS 2.0 Only Channels. Timebase Tick

Size of mini-slot for upstream transmission. For channels that do not support DOCSIS 1.x CMs. System timing unit

16 symbols

6.25 sec

DSx Request Retries DSx Response Retries T7

Number of Timeout Retries on DSA/DSC/ DSD Requests Number of Timeout Retries on DSA/DSC/ DSD Responses Wait for DSA/DSC/DSD Response timeout Wait for DSA/DSC Acknowledge timeout

1 sec

T8

300 msec

TFTP Backoff Start TFTP Backoff End TFTP Request Retries TFTP Download Retries TFTP Wait ToD Retries ToD Retry Period T9

Initial value for TFTP backoff Last value for TFTP backoff Number of retries on TFTP request Number of retries on entire TFTP downloads The wait between TFTP retry sequences Number of Retries per ToD Retry Period Time period for ToD retries Registration Timeout, the time allowed between the CMTS sending a RNG-RSP (success) to a CM, and receiving a REGREQ from that same CM. Wait for Transaction End timeout

1sec 16 sec 16 3 10 min 3 5 min 15 min 15 min

CM CMTS CMTS CM CMTS CM CMTS CM

T10

3 sec

T11 T12 T13 T14 T15 T16

Wait for a DCC Response on the old channel Wait for a DCC Acknowledge Maximum holding time for QoS resources for DCC on the old channel Minimum time after a DSx reject-tempDCC and the next retry of DSx command Maximum holding time for QoS resources for DCC on the new channel Maximum length of time CM remains in test mode after receiving TST-REQ message. Number of retries on Dynamic Channel Change Request Number of retries on Dynamic Channel Change Response Time from sending DCI-REQ and not receiving a DCI-RSP Number of retries of DCI-REQ before rebooting 3 3 2 sec 2 sec

300 ms 300 ms 1 sec

35 sec 30 min.1

CMTS CM CM CM

DCC-REQ Retries DCC-RSP Retries Lost DCI-REQ interval DCI-REQ retry

2 sec 16

336

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

System

Name

Time Reference

Minimum Value

Default Value

Maximum Value

CM CM CMTS

DCI Backoff start DCI Backoff end CM UCD processing time

Initial value for DCI backoff Last value for DCI backoff Time between the transmission of the last bit of a UCD with a new Change Count and the transmission time of the first bit of the first MAP using the new UCD. (See Section 11.3.2)

1 sec 16 sec 1 ms

1.

Row CM T16 added per RFI2-N-02102 by RKV on 10/28/02.

337

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

338

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex C Common Radio Frequency Interface Encodings

C.1 Encodings for Configuration and MAC-Layer Messaging
The following type/length/value encodings MUST be used in both the configuration file (see Annex D), in CM registration requests and in Dynamic Service Messages. All multi-octet quantities are in network-byte order, i.e., the octet containing the most-significant bits is the first transmitted on the wire. The following configuration settings MUST be supported by all CMs which are compliant with this specification.
C.1.1 Configuration File and Registration Settings

These settings are found in the configuration file and, if present, MUST be forwarded by the CM to the CMTS in its Registration Request.
C.1.1.1 Downstream Frequency Configuration Setting

The receive frequency to be used by the CM unless a Downstream Channel List is present. It is an override for the channel selected during scanning. This is the center frequency of the downstream channel in Hz stored as a 32-bit binary number.1
Type 1 Length 4 Value Rx Frequency

Valid Range: The receive frequency MUST be a multiple of 62500 Hz.

C.1.1.2 Upstream Channel ID Configuration Setting

The upstream channel ID which the CM MUST use. The CM MUST listen on the defined downstream channel until an upstream channel description message with this ID is found. It is an override for the channel selected during initialization.
Type 2 Length 1 Value Channel ID

C.1.1.3

Network Access Control Object

If the value field is a 1, CPEs attached to this CM are allowed access to the network, based on CM provisioning. If the value of this field is a 0, the CM MUST NOT forward traffic from attached CPE to the RF MAC network, but MUST continue to accept and generate traffic from the CM itself. The value of this field does not affect CMTS service flow operation and does not affect CMTS data forwarding operation.
Type 3 Length 1 On / Off 1 or 0

1.

Revised this paragraph per ECN RFIv2.0-N-03.0086-7 by GO on 3/15/04.

339

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The intent of NACO = 0 is that the CM does not forward traffic from any attached CPE onto the cable network. (A CPE is any client device attached to that CM, regardless of how that attachment is implemented.) However, with NACO = 0, management traffic to the CM is not restricted. Specifically, with NACO off, the CM remains manageable, including sending/receiving management traffic such as (but not limited to):

ARP: allow the modem to resolve IP addresses, so it can respond to queries or send traps. DHCP: allow the modem to renew its IP address lease. ICMP: enable network troubleshooting for tools such as ping and traceroute. ToD: allow the modem to continue to synchronize its clock after boot. TFTP: allow the modem to download either a new configuration file or a new software image. SYSLOG: allow the modem to report network events. SNMP: allow management activity

In DOCSIS v1.1, with NACO off, the primary upstream and primary downstream service flows of the CM remain operational only for management traffic to and from the CM. With respect to DOCSIS v1.1 provisioning, a CMTS should ignore the NACO value and allocate any service flows that have been authorized by the provisioning server.
C.1.1.4 DOCSIS 1.0 Class of Service Configuration Setting

This field defines the parameters associated with a DOCSIS 1.0 class of service. Any CM registering with a DOCSIS 1.0 Class of Service Configuration Setting MUST be treated as a DOCSIS 1.0 CM. Refer to Section 8.3.8. This field defines the parameters associated with a class of service. It is somewhat complex in that is composed from a number of encapsulated type/length/value fields. The encapsulated fields define the particular class of service parameters for the class of service in question. Note that the type fields defined are only valid within the encapsulated class of service configuration setting string. A single class of service configuration setting is used to define the parameters for a single service class. Multiple class definitions use multiple class of service configuration setting sets.
Type 4 Length n Value

C.1.1.4.1 Class ID

The value of the field specifies the identifier for the class of service to which the encapsulated string applies.
Type 4.1 Length 1 Value

Valid Range: The class ID MUST be in the range 1 to 16.

C.1.1.4.2 Maximum Downstream Rate Configuration Setting

For a single SID modem, the value of this field specifies the maximum downstream rate in bits per second that the CMTS is permitted to forward to CPE unicast MAC addresses learned or configured as mapping to the registering modem.

340

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

For a multiple SID modem, the aggregate value of these fields specifies the maximum downstream rate in bits per second that the CMTS is permitted to forward to CPE unicast MAC addresses learned or configured as mapping to the registering modem. This is the peak data rate for Packet PDU Data (including destination MAC address and the CRC) over a onesecond interval. This does not include MAC packets addressed to broadcast or multicast MAC addresses. The CMTS MUST limit downstream forwarding to this rate. The CMTS MAY delay, rather than drop, over-limit packets.
Type 4.2
Note:

Length 4

Value

This is a limit, not a guarantee that this rate is available.

C.1.1.4.3 Maximum Upstream Rate Configuration Setting

The value of this field specifies the maximum upstream rate in bits per second that the CM is permitted to forward to the RF Network. This is the peak data rate for Packet PDU Data (including destination address and the CRC) over a one-second interval. The CM MUST limit all upstream forwarding (both contention and reservation-based), for the corresponding SID, to this rate. The CM MUST include Packet PDU Data packets addressed to broadcast or multicast addresses when calculating this rate. The CM MUST enforce the maximum upstream rate. It SHOULD NOT discard upstream traffic simply because it exceeds this rate. The CMTS MUST enforce this limit on all upstream data transmissions, including data sent in contention. The CMTS SHOULD generate an alarm if a modem exceeds its allowable rate.
Type 4.3 Length 4 Value

Note: The purpose of this parameter is for the CM to perform traffic shaping at the input to the RF network and for the CMTS to perform traffic policing to ensure that the CM does not exceed this limit.

The CMTS could enforce this limit by any of the following methods: a) discarding over-limit requests.

b) deferring (through zero-length grants) the grant until it is conforming to the allowed limit. c) discarding over-limit data packets.

d) Reporting to a policy monitor (for example, using the alarm mechanism) that is capable of incapacitating errant CMs.
Note:

This is a limit, not a guarantee that this rate is available.

C.1.1.4.4 Upstream Channel Priority Configuration Setting

The value of the field specifies the relative priority assigned to this service class for data transmission in the upstream channel. Higher numbers indicate higher priority.
Type 4.4 Length 1 Value

Valid Range: 0 - 7
341

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.1.4.5 Guaranteed Minimum Upstream Channel Data Rate Configuration Setting

The value of the field specifies the data rate in bit/sec which will be guaranteed to this service class on the upstream channel.
Type 4.5 Length 4 Value

C.1.1.4.6 Maximum Upstream Channel Transmit Burst Configuration Setting

The value of the field specifies the maximum transmit burst (in bytes) which this service class is allowed on the upstream channel. A value of zero means there is no limit.
Note:

This value does not include any physical layer overhead. Length 2 Value

Type 4.6

C.1.1.4.7 Class-of-Service Privacy Enable

This configuration setting enables/disables Baseline Privacy on a provisioned CoS. See [DOCSIS10].
Type 4.7 (= CoS_BP_ENABLE) Length 1 Enable / Disable 1 or 0

Table C-1
Value (sub)type

Sample DOCSIS 1.0 Class of Service Encoding

Type

Length

Length

Value

28 1 2 3 4 5 6 1 4 4 1 4 2 1 10,000,000 300,000 5 64,000 1518

class of service configuration setting service class max. downstream rate of 10 Mb/sec max. upstream rate of 300 kbps return path priority of 5 min guaranteed 64 kb/sec max. Tx burst of 1518 bytes class of service configuration setting 1 2 3 4 5 6 1 4 4 1 4 2 2 5,000,000 300,000 3 32,000 1,518 service class 2 max. forward rate of 5 Mb/sec max. return rate of 300 Mb/sec return path priority of 3 min guaranteed 32 kb/sec max. Tx burst of 1518 bytes

28

C.1.1.5

CM Message Integrity Check (MIC) Configuration Setting

The value field contains the CM message integrity check code. This is used to detect unauthorized modification or corruption of the configuration file.
Type 6 Length 16 Value d1, d2,... d16

342

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.1.6

CMTS Message Integrity Check (MIC) Configuration Setting

The value field contains the CMTS message integrity check code. This is used to detect unauthorized modification or corruption of the configuration file.
Type 7 Length 16 Value d1, d2,... d16

C.1.1.7

Maximum Number of CPEs

The maximum number of CPEs that can be granted access through a CM during a CM epoch. The CM epoch is (from Section 5.1.2.3.1) the time between startup and hard reset of the modem. The maximum number of CPEs MUST be enforced by the CM.
Note: This parameter should not be confused with the number of CPE addresses a CM may learn. A modem may learn Ethernet MAC addresses up to its maximum number of CPE addresses (from Section 5.1.2.3.1). The maximum number of CPEs that are granted access through the modem is governed by this configuration setting.

Type 18

Length 1

Value

The CM MUST interpret this value as an unsigned integer. The non-existence of this option, or the value 0, MUST be interpreted as the default value of 1.
Note: This is a limit on the maximum number of CPEs a CM will grant access to. Hardware limitations of a given modem implementation may require the modem to use a lower value.

C.1.1.8

TFTP Server Timestamp

The sending time of the configuration file in seconds. The definition of time is as in [RFC-868].
Type 19
Note:

Length 4

Value Number of seconds since 00:00 1 Jan 1900

The purpose of this parameter is to prevent replay attacks with old configuration files.

C.1.1.9

TFTP Server Provisioned Modem Address

The IP Address of the modem requesting the configuration file.

Type 20
Note:

Length 4

Value IP Address

The purpose of this parameter is to prevent IP spoofing during registration.

C.1.1.10

Upstream Packet Classification Configuration Setting

This field defines the parameters associated with one entry in an upstream traffic classification list. Refer to Annex C.2.1.1.
Type 22 Length n Value

343

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.1.11 Downstream Packet Classification Configuration Setting

This field defines the parameters associated with one Classifier in an downstream traffic classification list. Refer to Annex C.2.1.2.
Type 23 Length n Value

C.1.1.12

Upstream Service Flow Encodings

This field defines the parameters associated with upstream scheduling for one Service Flow. Refer to Annex C.2.2.1.
Type 24 Length n Value

C.1.1.13

Downstream Service Flow Encodings

This field defines the parameters associated with downstream scheduling for one Service Flow. Refer to Annex C.2.2.2.
Type 25 Length n Value

C.1.1.14

Payload Header Suppression

This field defines the parameters associated with Payload Header Suppression.
Type 26 Length n Value

C.1.1.15

Maximum Number of Classifiers

This is the maximum number of Classifiers associated with admitted or active upstream Service Flows that the CM is allowed to have. Both active and inactive Classifiers are included in the count. This is useful when using deferred activation of provisioned resources. The number of provisioned Service Flows may be high and each Service Flow might support multiple Classifiers. Provisioning represents the set of Service Flows the CM can choose between. The CMTS can control the QoS resources committed to the CM by limiting the number of Service Flows that are admitted. However, it may still be desirable to limit the number of Classifiers associated with the committed QoS resources. This parameter provides that limit.
Type 28 Length 2 Value Maximum number of active and inactive Classifiers associated with admitted or active upstream Service Flows

The default value MUST be 0 no limit.

344

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.1.16

Privacy Enable

This configuration setting enables/disables Baseline Privacy [DOCSIS8] on the Primary Service Flow and all other Service Flows for this CM. If a DOCSIS 2.0 CM receives this setting in a configuration file, the CM is required to forward this setting as part of the registration request (REG-REQ) as specified in Section 8.3.7, regardless of whether the configuration file is DOCSIS 1.1-style or not, while this setting is usually contained only in a DOCSIS 1.1-style configuration file with DOCSIS 1.1 Service Flow TLVs.
Type 29 Length 1 Value 0 Disable 1 Enable

The default value of this parameter MUST be 1 privacy enabled.

C.1.1.17 DOCSIS Extension Field1

The DOCSIS Extension Field is used to extend the capabilities of the DOCSIS specification, through the use of new and/or vendor-specific features. The DOCSIS Extension Field MUST be encoded using TLV 43 and MUST include the Vendor ID field (refer to Annex C.1.3.2) to indicate whether the DOCSIS Extension Field applies to all devices, or only to devices from a specific vendor. The Vendor ID MUST be the first TLV embedded inside the DOCSIS Extension Field. If the first TLV inside the DOCSIS Extension Field is not a Vendor ID, then the TLV MUST be discarded. In this context, the Vendor ID of 0xFFFFFF is reserved to signal that this DOCSIS Extension Field contains general extension information (see Annex C.1.1.17.1), otherwise the DOCSIS Extension Field contains vendor-specific information (see Annex C.1.1.17.2). This configuration setting MAY appear multiple times. This configuration setting MAY be nested inside a Packet Classification Configuration Setting, a Service Flow Configuration Setting, or a Service Flow Response. The same Vendor ID MAY appear multiple times. However, there MUST NOT be more than one Vendor ID TLV inside a single TLV 43. The CM MUST ignore any DOCSIS Extension Field that it cannot interpret, but MUST still include the TLV in the REG-REQ message. The CM MUST NOT initiate the DOCSIS Extension Field TLVs. Type 43
C.1.1.17.1

Length Value n

General Extension Information

When using the DOCSIS Extension Field (TLV 43) to encode general extension information, the Vendor ID of 0xFFFFFF MUST be used as the first sub-TLV inside TLV 43. Type 43 Length Value n 8, 3, 0xFFFFFF, followed by general extension information

The following sub-TLVs are defined only as part of the General Extension Information. The type values may be re-defined for any purpose as part of a Vendor-Specific Information encoding.

1.

Replaced this section and added subsections per ECN RFIv2.0-N-0125-5 by GO on 3/15/04.

345

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.1.17.1.1

CM Load Balancing Policy ID

The CMTS load balancing algorithm uses this config file setting as the CM load balancing policy id. If present, this value overrides the default group policy assigned by the CMTS (see Section 11.4.5.6). This configuration setting should only appear once in a configuration file. This configuration setting MUST only be used in configuration files and REG-REQ messages, and MUST NOT be nested inside a Packet Classification Configuration Setting, a Service Flow Configuration Setting, or a Service Flow Response. Type 43.1
C.1.1.17.1.2

Length Value 4 policy id

CM Load Balancing Priority

This config file setting is the CM load balancing priority to be used by the CMTS load balancing algorithm. If present, this value overrides the default priority assigned by the CMTS (see Section 11.4.5.6). This configuration setting should only appear once in a configuration file. This configuration setting MUST only be used in configuration files and REG-REQ messages, and MUST NOT be nested inside a Packet Classification Configuration Setting, a Service Flow Configuration Setting, or a Service Flow Response. Type 43.2
C.1.1.17.1.3

Length Value 4 priority

CM Load Balancing Group ID

This config file setting is the Restricted Load Balancing Group ID defined at the CMTS. If present, this value overrides the general load balancing group. If no Restricted Load Balancing Group is defined that matches this group id, the value is ignored by the CMTS (see Section 11.4.5.6). This configuration setting should only appear once in a configuration file. This configuration setting MUST only be used in configuration files and REG-REQ messages, and MUST NOT be nested inside a Packet Classification Configuration Setting, a Service Flow Configuration Setting, or a Service Flow Response. Type 43.3
C.1.1.17.2

Length Value 4 group id

Vendor-Specific Information

Vendor-specific configuration information, if present, is encoded in the DOCSIS Extension Field (code 43) using the Vendor ID field (refer to Section C.1.3.2) to specify which TLV tuples apply to which vendor's products. Type 43 Example: Configuration with vendor A specific fields and vendor B specific fields: VSIF (43) + n (number of bytes inside this VSIF) 8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor A Vendor A Specific Type #1 + length of the field + Value #1 Length Value n per vendor definition

346

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Vendor A Specific Type #2 + length of the field + Value #2 VSIF (43) + m (number of bytes inside this VSIF) 8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor B Vendor B Specific Type + length of the field + Value
C.1.1.18 Subscriber Management TLVs

The information in these TLVs is not used by the CM; rather, the information is used by the CMTS to populate the Subscriber Management MIB for this CM. If present in the configuration file, the CM MUST include these TLVs in the subsequent REG-REQ to be used by the CMTS to populate the Subscriber Management MIB for this CM. If present in the configuration file, the CM MUST include these TLVs in the CMTS MIC.
C.1.1.18.1 Subscriber Management Control

This three byte field provides control information to the CMTS for the Subscriber Management MIB. The first two bytes represent the number of IP addresses permitted behind the CM. The third byte is used for control fields.
Type 35 Length 3 Value byte 1,2 docsSubMgtCpeControlMaxCpeIP (low-order 10 bits) byte 3, bit 0: docsSubMgtCpeControlActive byte 3, bit 1: docsSubMgtCpeControlLearnable byte 3, bits #2-7: reserved, must be set to zero

C.1.1.18.2

Subscriber Management CPE IP Table

This field lists the IP Addresses used to populate docsSubMgtCpeIpTable in the Subscriber Management MIB at the CMTS.
Type 36 Length N (multiple of 4) Value Ipa1, Ipa2, Ipa3, Ipa4

C.1.1.18.3

Subscriber Management Filter Groups

The Subscriber Management MIB allows filter groups to be assigned to a CM and CPE attached to that CM. These include two CM filter groups, upstream and downstream, and two CPE filter groups, upstream and downstream. These four filter groups are encoded in the configuration file in a single TLV as follows:
Type 37 Length 8 Value bytes 1,2: docsSubMgtSubFilterDownstream group bytes 3,4: docsSubMgtSubFilterUpstream group bytes 5,6: docsSubMgtCmFilterDownstream group bytes 7,8: docsSubMgtCmFilterUpstream group

347

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.1.19

Enable 2.0 Mode

This configuration setting enables/disables DOCSIS 2.0 mode for a CM registering with a DOCSIS 2.0 CMTS. The default value of this parameter MUST be 1 - 2.0 Mode Enabled.
Type 39 Length 1 Value 0 - Disable 1 - Enable

C.1.1.20

Enable Test Modes

This configuration setting enables/disables certain test modes for a CM which supports test modes. The definition of the test modes is beyond the scope of this specification. If this TLV is not present, the default value MUST be 0 Test modes disabled.
Type 40 Length 1 Value 0 Disable 1 Enable

C.1.1.21

Downstream Channel List1

A list of receive frequencies to which the CM is allowed to tune during scanning operations. When the Downstream Channel List is provided in a configuration file, the CM MUST NOT attempt to establish communications using a downstream channel that is absent from this list unless specifically directed to do so by the CMTS. When both the Downstream Channel List and the Downstream Frequency Configuration Setting (C.1.1.1) are included in the configuration file, the CM MUST ignore the Downstream Frequency Configuration Setting. This list can override the last operational channel stored in NVRAM as defined in section 11.2.1. The CM MUST retain and employ this list of channels whenever the CM performs a re-initialize MAC or continue scanning operation. The CM MUST replace or remove the list by subsequent config file downloads. Upon power cycle, the CM MUST NOT enforce a previously learned downstream channel list. The CM MAY, however, remember this list as an aid to downstream channel acquisition. Type 41 Length Value n List of Allowed Rx Frequencies

The list of allowed downstream frequencies is composed of an ordered series of sub-TLVs (Single Downstream Channel, Downstream Frequency Range, and Default Scanning) as defined below. When scanning for a downstream channel (except after a power-cycle), the CM MUST scan through this ordered list and attempt to establish communications on the specified channel(s). The scanning is initialized as follows:

If the CM is in an operational state, and then undergoes a re-initialize MAC operation (except due to
a Dynamic Channel Change), it MUST first scan the last operational frequency and then restart scanning at the beginning of the ordered list.

If, while scanning this ordered list, the CM fails to become operational and is forced to re-initialize
MAC, the CM MUST continue scanning from the next applicable frequency in the ordered list.

1.

Added this section and subsections per ECN RFIv2.0-N-03.0087-7 by GO on 3/15/04; Updated this subsection per ECN RFIv2.0-N-04.0181-3 by GO on 11/8/04.

348

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

If it reaches the Default Scanning TLV (TLV 41.3) in the config file, the CM begins its default
scanning algorithm, completing initial ranging and DHCP and receiving a new config file via TFTP on the first valid frequency it sees. If the new config file does not contain TLV 41, the CM MUST continue with registration. If the new config file contains TLV 41, the CM MUST confirm that the current downstream frequency is explicitly listed in the Downstream Channel List. If the current downstream channel is not explicitly listed in the Downstream Channel List, the CM MUST NOT register on the current downstream channel and MUST restart scanning according to the Downstream Channel List contained in the configuration file. Upon reaching the end of the List, the CM MUST begin again with the first sub-TLV in the List. The CM MUST be capable of processing a Downstream Channel List that contains up to 16 sub-TLVs. This configuration setting MAY appear multiple times. If this configuration setting appears multiple times, all sub-TLVs MUST be considered part of a single Downstream Channel List in the order in which they appear in the configuration file. In other words, the sub-TLVs from the first instance of this configuration setting would comprise the first entries in the ordered series, the second instance would comprise the next entries, etc
C.1.1.21.1 Single Downstream Channel

Upon reaching this sub-TLV in the Downstream Channel List, the CM MUST attempt to acquire a downstream signal on the specified Frequency for a period of time specified by Timeout. If a signal is acquired, and it is determined to be unusable by the CM, the CM MAY move on to the next sub-TLV in the Downstream Channel List without waiting for the Timeout to expire. The CM MUST be capable of processing a Downstream Channel List that contains multiple Single Downstream Frequency TLVs. Type 41.1
C.1.1.21.1.1

Length Value 6 or 10
Single Downstream Channel Timeout

Timeout is specified in seconds (unsigned). A value of 0 for Timeout means no time out, i.e. the CM attempts to acquire a signal on the specified Frequency, and if unsuccessful moves immediately to the next sub-TLV in the Downstream Channel List. This is an optional parameter in a Single Downstream Channel TLV. If the Single Downstream Channel Timeout is omitted, the CM MUST use a default time out of 0. Type 41.1.1
C.1.1.21.1.2

Length Value 2 Timeout

Single Downstream Channel Frequency

Single Downstream Channel Frequency is a required parameter in each Single Downstream Channel TLV, the CM MUST ignore any Single Downstream Channel TLV which lacks this parameter. The DSFrequency MUST be a multiple of 62,500 Hz. Type 41.1.2 Length Value 4 DSFrequency

349

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.1.21.2

Downstream Frequency Range

Upon reaching this sub-TLV in the Downstream Channel List, the CM MUST begin scanning with DSFrequencyStart and progress in steps as indicated by DSFrequencyStepSize until reaching DSFrequencyEnd, and then repeat for a period of time specified by Timeout. If the value of Timeout is less than the time necessary for the CM to complete one full scan of all channels in the Downstream Frequency Range, the CM MUST complete one full scan and then move on to the next sub-TLV in the Downstream Channel List. Note, DSFrequencyEnd may be less than DSFrequencyStart, which indicates scanning in the downward direction. If a signal has been acquired on all available channels between DSFrequencyStart and DSFrequencyEnd (inclusive), and all channels have been determined to be unusable by the CM, the CM MAY move on to the next sub-TLV in the Downstream Channel List without waiting for the Timeout to expire. The CM MUST be capable of processing a Downstream Channel List that contains multiple Downstream Frequency Range TLVs. Type 41.2
C.1.1.21.2.1

Length 18 or 22

Value

Downstream Frequency Range Timeout

Timeout is specified in seconds (unsigned). A value of 0 for Timeout means no time out, i.e. the CM attempts to acquire a signal once on each frequency within the defined range, and if unsuccessful moves immediately to the next sub-TLV in the Downstream Channel List. This is an optional parameter in a Downstream Frequency Range TLV. If the Downstream Frequency Range Timeout is omitted, the CM MUST use a default time out of 0. Type 41.2.1
C.1.1.21.2.2

Length Value 2 Timeout

Downstream Frequency Range Start

Downstream Frequency Range Start is a required parameter in each Downstream Frequency Range TLV; the CM MUST ignore any Downstream Frequency Range TLV which lacks this parameter. Downstream Frequency Range Start MUST be a multiple of 62,500 Hz. Type 41.2.2
C.1.1.21.2.3

Length Value 4 DSFrequencyStart

Downstream Frequency Range End

Downstream Frequency Range End is a required parameter in each Downstream Frequency Range TLV; the CM MUST ignore any Downstream Frequency Range TLV which lacks this parameter. Downstream Frequency Range End MUST be a multiple of 62,500 Hz. Type 41.2.3 Length Value 4 DSFrequencyEnd

350

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.1.21.2.4

Downstream Frequency Range Step Size

Downstream Frequency Range Step Size is a required parameter in each Downstream Frequency Range TLV; the CM MUST ignore any Downstream Frequency Range TLV which lacks this parameter. Downstream Frequency Range Step Size specifies the increments in Hz by which the CM MUST scan through the Downstream Frequency Range. The CM MUST support a minimum Downstream Frequency Step Size of 6,000,000 Hz. The CM MAY support Downstream Frequency Step Sizes less than 6,000,000 Hz. Type 41.2.4
C.1.1.21.3

Length Value 4 DSFrequencyStepSize

Default Scanning1

Upon reaching this sub-TLV in the Downstream Channel List, the CM MUST begin scanning according to its default scanning algorithm, (which may be vendor dependent), and repeat for a period of time specified by Timeout. When the CM reaches a valid downstream frequency during default scanning, the CM completes initial ranging and DHCP, and receives a new config file, via TFTP. If the config file does not contain TLV 41, the CM continues with registration. If the config file contains TLV 41 and the current downstream channel is not explicitly listed in the Downstream Channel List, the CM restarts scanning according to the Downstream Channel List contained in the configuration file. Timeout is specified in seconds (unsigned). If the value of Timeout is less than the time necessary for the CM to complete one full scan of all channels in the default scanning algorithm, the CM MUST complete one full scan and move on to the next sub-TLV in the Downstream Channel List. A value of 0 for Timeout means no time out, i.e., the CM scans all available frequencies once, then moves to the next sub-TLV in the Downstream Channel List. The CM MUST be capable of processing a Downstream Channel List that contains multiple Default Scanning TLVs. Type 41.3
C.1.1.21.4

Length Value 2 Timeout

Examples Illustrating Usage of the Downstream Channel List

Assume that a modem has been provisioned to receive a config file with a Downstream Channel List consisting of several single downstream channel (TLV 41.1) entries, a downstream frequency range (TLV 41.2) entry, a default scanning (TLV 41.3) entry, and no timeout entries. When the modem first boots up, it locks onto the first downstream channel it can find and goes through initial ranging. After completing the ranging process, the modem downloads the config file with the Downstream Channel List. The modem then checks its current downstream frequency against the frequencies explicitly listed in the single downstream channel (TLV 41.1) entries and the downstream frequency range entry (TLV 41.2) of the Downstream Channel List, ignoring the default scan (TLV 41.3) entry at this point. If the current channel is

1.

Revised this subsection and added the subsequent subsection per ECN RFIv2.0-N-04.0181-3 by GO on 11/9/ 04.

351

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

not explicitly in the single downstream channel entries in the list or within the downstream frequency range entry in the list, the modem moves to the first sub-TLV in the TLV 41 list and attempts to lock onto that channel. If the modem is able to lock onto that frequency, it again tries to range and download a config file. Assuming that the modem receives the same config file, the modem would then proceed with registration. If the modem is not able to lock on the first sub-TLV in the Downstream Channel List, it moves onto the next entry in the list and so on. If it reaches the downstream frequency range TLV, it will begin scanning at the downstream frequency range start, incrementing the frequency by the downstream frequency step size, and ending at the downstream frequency range end. If the CM finds a valid downstream frequency within the downstream frequency range, the modem ranges and downloads a config file. Assuming that the config file has not changed, the modem continues with registration on that channel. However, if it reaches the default scanning sub-TLV without successfully registering, the modem starts its "default scan" process. If during the course of its default scan, the modem finds a DS channel that it can lock onto, is able to complete ranging, and is able to download a config file, it will do so. However, at that point, the modem once again checks which Downstream Channels are explicitly in the list and acts accordingly. As a second, less likely example, assume that a modem has been provisioned to receive a config file with a Downstream Channel List containing only a default scanning (TLV 41.3) entry. When the modem first boots up, it locks onto the first downstream channel it can find and goes through initial ranging. After completing the ranging process, the modem downloads the config file with the Downstream Channel List. Since the default scanning is the only parameter in the Downstream Channel List, the downstream frequency on which the CM locked is not explicitly included so the CM continues to scan according to its algorithm. The CM will not register on a channel until it receives a config file with a downstream frequency explicitly listed in the Downstream Channel List or a config file with no Downstream Channel List.
C.1.2 Configuration-File-Specific Settings

These settings are found in only the configuration file. They MUST NOT be forwarded to the CMTS in the Registration Request.
C.1.2.1 End-of-Data Marker

This is a special marker for end of data. It has no length or value fields.
Type 255

C.1.2.2

Pad Configuration Setting

This has no length or value fields and is only used following the end of data marker to pad the file to an integral number of 32-bit words.
Type 0

352

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.2.3

Software Upgrade Filename

The file name of the software upgrade file for the CM. The file name is a fully qualified directory-path name. The file is expected to reside on a TFTP server identified in a configuration setting option defined in Annex D.2.2. See also Section 12.1.
Type 9 Length n Value filename

C.1.2.4

SNMP Write-Access Control

This object makes it possible to disable SNMP Set access to individual MIB objects. Each instance of this object controls access to all of the writeable MIB objects whose Object ID (OID) prefix matches. This object may be repeated to disable access to any number of MIB objects.
Type 10 Length n Value OID prefix plus control flag

Where n is the size of the ASN.1 Basic Encoding Rules [ISO/IEC8825-1] encoding of the OID prefix plus one byte for the control flag.1 The control flag may take values: 0 - allow write-access 1 - disallow write-access Any OID prefix may be used. The Null OID 0.0 may be used to control access to all MIB objects. (The OID 1.3.6.1 will have the same effect.) When multiple instances of this object are present and overlap, the longest (most specific) prefix has precedence. Thus, one example might be someTable: disallow write-access someTable.1.3: allow write-access This example disallows access to all objects in someTable except for someTable.1.3.
C.1.2.5 SNMP MIB Object

This object allows arbitrary SNMP MIB objects to be Set via the TFTP-Registration process.
Type 11 Length n Value variable binding

The value is an SNMP VarBind as defined in [RFC-1157]. The VarBind is encoded in ASN.1 Basic Encoding Rules, just as it would be if part of an SNMP Set request. The cable modem MUST treat this object as if it were part of an SNMP Set Request with the following caveats:

It MUST treat the request as fully authorized (it cannot refuse the request for lack of privilege).

1.

Revised this sentence per ECN RFI2-N-03077 by GO on 07/08/03.

353

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

SNMP Write-Control provisions (see previous section) do not apply. No SNMP response is generated by the CM.
This object MAY be repeated with different VarBinds to Set a number of MIB objects. All such Sets MUST be treated as if simultaneous. Each VarBind MUST be limited to 255 bytes.
C.1.2.6 CPE Ethernet MAC Address

This object configures the CM with the Ethernet MAC address of a CPE device (see Section 5.1.2.3.1). This object may be repeated to configure any number of CPE device addresses.
Type 14 Length 6 Value Ethernet MAC Address of CPE

C.1.2.7

Software Upgrade TFTP Server

The IP address of the TFTP server, on which the software upgrade file for the CM resides. See Section 12.1 and Annex C.1.2.3.
Type 21 Length 4 Value ip1,ip2,ip3,ip4

C.1.2.8

SnmpV3 Kickstart Value

Compliant CMs MUST understand the following TLV and its sub-elements and be able to kickstart SNMPv3 access to the CM regardless of whether the CMs are operating in 1.0 mode or 1.1 mode
Type 34 Length n Value Composite

Up to 5 of these objects may be included in the configuration file. Each results in an additional row being added to the usmDHKickstartTable and the usmUserTable and results in an agent public number being generated for those rows.
C.1.2.8.1 SnmpV3 Kickstart Security Name
Type 34.1 Length 2-16 Value UTF8 Encoded security name

For the ASCII character set, the UTF8 and the ASCI I encodings are identical. Normally, this will be specified as one of the Docsis built-in USM users, e.g., docsisManager, docsisOperator, docsisMonitor, docsisUser. The security name is NOT zero terminated. This is reported in the usmDHKickStartTable as usmDHKickStartSecurityName and in the usmUserTable as usmUserName and usmUserSecurityName.

354

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.2.8.2 SnmpV3 Kickstart Manager Public Number

Type 34.2 Length n Value Managers Diffie-Helman public number expressed as an octet string.

This number is the Diffie-Helman public number derived from a privately (by the manager or operator) generated random number and transformed according to [RFC-2786]. This is reported in the usmDHKickStartTable as usmKickstartMgrPublic. When combined with the object reported in the same row as usmKickstartMyPublicit can be used to derive the keys in the related row in the usmUserTable.
C.1.2.9 Manufacturer Code Verification Certificate

The Manufacturers Code Verification Certificate (M-CVC) for Secure Software Downloading specified by the appendix D of [DOCSIS8]. The CM config file MUST contain this M-CVC and/or C-CVC defined in Annex C.1.2.10 in order to allow the 1.1-compliant CM to download the code file from the TFTP server whether or not the CM is provisioned to run with BPI, BPI+, or none of them. See appendix D of [DOCSIS8] for details.
Type 32 Length n Value Manufacturer CVC (DER-encoded ASN.1)

If the length of the M-CVC exceeds 254 bytes, the M-CVC MUST be fragmented into two or more successive Type 32 elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the MCVC by concatenating the contents (Value of the TLV) of successive Type 32 elements in the order in which they appear in the config file. For example, the first byte following the length field of the second Type 32 element is treated as if it immediately follows the last byte of the first Type 32 element.
C.1.2.10 Co-signer Code Verification Certificate

The Co-signers Code Verification Certificate (C-CVC) for Secure Software Downloading specified by the appendix D of [DOCSIS8]. The CM config file MUST contain this C-CVC and/or M-CVC defined in Annex C.1.2.9 in order to allow the 1.1-compliant CM to download the code file from TFTP server whether or not the CM is provisioned to run with BPI, BPI+, or none of them. See [DOCSIS8] appendix D for details.
Type 33 Length n Value Co-signer CVC (DER-encoded ASN.1)

If the length of the C-CVC exceeds 254 bytes, the C-CVC MUST be fragmented into two or more successive Type 33 elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the CCVC by concatenating the contents (Value of the TLV) of successive Type 33 elements in the order in which they appear in the config file. For example, the first byte following the length field of the second Type 33 element is treated as if it immediately follows the last byte of the first Type 33 element.
C.1.2.11 SNMPv3 Notification Receiver

This TLV specifies a Network Management Station that will receive notifications from the modem when it is in Coexistence mode. Up to 10 of these elements may be included in the configuration file.
Type 38 Length n Value composite

355

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.1.2.11.1

SNMPv3 Notification Receiver IP Address

This sub-TLV specifies the IP address of the notification receiver.

Type 38.1 Length 4 Value ip1, ip2, ip3, ip4

C.1.2.11.2

SNMPv3 Notification Receiver UDP Port Number

This sub-TLV specifies the UDP port number of the notification receiver. If this sub-TLV is not present, the default value of 162 should be used.
Type 38.2 Length 2 Value UDP port number

C.1.2.11.3
Type 38.3

SNMPv3 Notification Receiver Trap Type

Length 2 Value trap type

This sub-TLV specifies the type of trap to send. The trap type may take values: 1 = SNMP v1 trap in an SNMP v1 packet 2 = SNMP v2c trap in an SNMP v2c packet 3 = SNMP inform in an SNMP v2c packet 4 = SNMP v2c trap in an SNMP v3 packet 5 = SNMP inform in an SNMP v3 packet
C.1.2.11.4 SNMPv3 Notification Receiver Timeout

This sub-TLV specifies the timeout value to use when sending an Inform message to the notification receiver.
Type 38.4 Length 2 Value time in milliseconds

C.1.2.11.5

SNMPv3 Notification Receiver Retries

This sub-TLV specifies the number of times to retry sending an Inform message if an acknowledgement is not received.
Type 38.5 Length 2 Value number of retries

C.1.2.11.6

SNMPv3 Notification Receiver Filtering Parameters

This sub-TLV specifies the ASN.1 formatted Object Identifier of the snmpTrapOID value that identifies the notifications to be sent to the notification receiver. SNMP V3 allows the specification of which Trap OIDs are to be sent to a trap receiver. This object specifies the OID of the root of a trap filter sub-tree. All Traps with a Trap OID contained in this trap filter sub-tree MUST be sent to the trap receiver. This object starts with the ASN.1

356

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Universal type 6 (Object Identifier) byte, then the ASN.1 length field, then the ASN.1 encoded object identifier components.
Type 38.6 Length n Value filter OID

C.1.2.11.7

SNMPv3 Notification Receiver Security Name

This sub-TLV specifies the V3 Security Name to use when sending a V3 Notification. This sub-TLV is only used if Trap Type is set to 4 or 5. This name must be a name specified in a config file TLV Type 34 as part of the DH Kickstart procedure. The notifications will be sent using the Authentication and Privacy Keys calculated by the modem during the DH Kickstart procedure. This sub-TLV is not required for Trap Type = 1, 2, or 3 above. If it is not supplied for a Trap type of 4 or 5, then the V3 Notification will be sent in the noAuthNoPriv security level using the security name @config.
Type 38.7 Length n Value security name

C.1.2.12

Multicast MAC Address1

This object configures the CM with a Static Multicast MAC Address that is being provisioned into the CM. This object may be repeated to configure any number of Static Multicast MAC Addresses. The CM MUST support a minimum of 10 Static Multicast MAC addresses. The CM MUST forward any multicast frames that match the Static Multicast MAC Address from the cable network to the CMCI subject to the provisions of Section 5.1.2.3.2. IGMP has no impact on this forwarding.
Type 42 Length 6 Value

Static Multicast MAC Address

C.1.3 Registration-Request/Response-Specific Encodings

These encodings are not found in the configuration file, but are included in the Registration Request and option 60 of the DHCP request. Some encodings are also used in the Registration Response. The CM MUST include all Modem Capabilities Encodings that are subject to negotiation with the CMTS in its Registration Request. Modem Capabilities Encodings that are not subject to negotiation with the CMTS are explicitly stated in the description of the particular modem capability. The CMTS MUST include Modem Capabilities in the Registration Response.
C.1.3.1 Modem Capabilities Encoding

The value field describes the capabilities of a particular modem, i.e., implementation dependent limits on the particular features or number of features which the modem can support. It is composed from a number of encapsulated type/length/value fields. The encapsulated sub-types define the specific capabilities for the modem in question.

1.

Added this section per ECN RFIv2.0-N-04.0143-4 by GO on 7/8/04.

357

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note:

The sub-type fields defined are only valid within the encapsulated capabilities configuration setting string. Length n Value

Type 5

The set of possible encapsulated fields is described below. All these capabilities are to be included in both the registration request and option 60 of the DHCP request unless the description of the capability explicitly prohibits this.
C.1.3.1.1 Concatenation Support

If the value field is a 1 the CM requests concatenation support from the CMTS.
Type 5.1 Length 1 On / Off 1 or 0

C.1.3.1.2

DOCSIS Version

DOCSIS version of this modem.

Type 5.2 Length 1 Value 0: DOCSIS v1.0 1: DOCSIS v1.1 2: DOCSIS v2.0 3-255: Reserved

If this tuple is absent, the CMTS MUST assume DOCSIS v1.0 operation. The absence of this tuple or the value DOCSIS 1.0 does not necessarily mean the CM only supports DOCSIS 1.0 functionality the CM MAY indicate it supports other individual capabilities with other Modem Capability Encodings. (Refer to Annex G.2). This capability is provided by the CM for the benefit of the CMTS, the operation of the CM is not affected by the value returned by the CMTS.
C.1.3.1.3 Fragmentation Support

If the value field is a 1 the CM requests fragmentation support from the CMTS.
Type 5.3 Length 1 Value 1 or 0

C.1.3.1.4 Payload Header Suppression Support

If the value field is a 1 the CM requests payload header suppression support from the CMTS.
Type 5.4 Length 1 Value 1 or 0

C.1.3.1.5 IGMP Support

If the value field is a 1 the CM supports DOCSIS 1.1-compliant IGMP.

Type 5.5 Length 1 Value 1 or 0

358

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Note: This CM capability is not subject to negotiation with the CMTS. The CM MUST include this capability in the DHCP request, but MUST NOT include this capability in the registration request. If a CMTS does receive this capability with in a registration request it MUST return the capability with the same value in the registration response.

C.1.3.1.6

Privacy Support

The value indicates the BPI support of the CM.

Type 5.6 Length 1 Value 0: BPI Support 1: BPI Plus Support 2 - 255: Reserved

C.1.3.1.7

Downstream SAID Support

This field shows the number of Downstream SAIDs the modem can support.
Type 5.7 Length 1 Value Number of Downstream SAIDs the CM can support.

If the number of SAIDs is 0, the Modem can support only 1 SAID.

C.1.3.1.8 Upstream SID Support

This field shows the number of Upstream SIDs the modem can support.
Type 5.8 Length 1 Value Number of Upstream SIDs the CM can support.

If the number of SIDs is 0 that means the Modem can support only 1 SID.
C.1.3.1.9 Optional Filtering Support

This field shows the optional filtering support in the modem.

Type 5.9 Length 1 Value Packet Filtering Support Array bit #0: 802.1P filtering bit #1: 802.1Q filtering bit #2-7: reserved, MUST be set to zero

Note: This CM capability is not subject to negotiation with the CMTS. The CM MUST include this capability in the DHCP request, but MUST NOT include this capability in the registration request. If a CMTS does receive this capability with in a registration request it MUST return the capability with the same value in the registration response.

C.1.3.1.10

Transmit Equalizer Taps per Modulation Interval

This field shows the maximal number of pre-equalizer taps per modulation interval T supported by the CM.

359

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note: All CMs MUST support T-spaced equalizer coefficients. CM support of 2 or 4 taps per modulation interval is optional. If this tuple is missing, it is implied that the CM only supports T spaced equalizer coefficients. A CM MUST include this capability in the registration request and its value MUST be 1.

Type 5.10

Length 1

Value 1, 2 or 4

C.1.3.1.11

Number of Transmit Equalizer Taps

This field shows the number of equalizer taps that are supported by the CM
Note: All CMs MUST support an equalizer length of at least 8 symbols. CM support of up to 64 T-spaced, T/2-spaced or T/4spaced taps is optional. If this tuple is missing, it is implied that the CM only supports an equalizer length of 8 taps. A CM MUST include this capability in the registration request and its value MUST be 24.

Type 5.11

Length 1

Value 8 to 64

C.1.3.1.12

DCC Support

The value is the DCC support of the CM.

Type 5.12 Length 1 Value 0 = DCC is not supported 1 = DCC is supported

C.1.3.2

Vendor ID Encoding

The value field contains the vendor identification specified by the three-byte vendor-specific Organization Unique Identifier of the CM MAC address. The Vendor ID MUST be used in a Registration Request, but MUST NOT be used as a stand-alone configuration file element. It MAY be used as a sub-field of the Vendor Specific Information Field in a configuration file. When used as a sub-field of the Vendor Specific Information field, this identifies the Vendor ID of the CMs which are intended to use this information. When the vendor ID is used in a Registration Request, then it is the Vendor ID of the CM sending the request.
Type 8 Length 3 Value v1, v2, v3

C.1.3.3

Modem IP Address

For backwards compatibility with DOCSIS v 1.0. Replaced by TFTP Server Provisioned Modem Address.
Type 12 Length 4 Value IP Address

360

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.1.3.4

Service(s) Not Available Response

This configuration setting MUST be included in the Registration Response message if the CMTS is unable or unwilling to grant any of the requested classes of service that appeared in the Registration Request. Although the value applies only to the failed service class, the entire Registration Request MUST be considered to have failed (none of the class-of-service configuration settings are granted).
Type 13 Length 3 Value Class ID, Type, Confirmation Code

Class ID is the class-of-service class from the request which is not available Type is the specific class-of-service object within the class which caused the request to be rejected Confirmation Code (Refer to Annex C.4.)
C.1.3.5 Vendor-Specific Capabilities

Vendor-specific data about the CM, that is to be included in the REG-REQ, but which is not part of the configuration file, if present, MUST be encoded in the vendor specific capabilities (VSC) (code 44) using the Vendor ID field (refer to Annex C.1.3.2) to specify which TLV tuples apply to which vendors products. The Vendor ID MUST be the first TLV embedded inside VSC. If the first TLV inside VSIF is not a Vendor ID, then the TLV MUST be discarded. This configuration setting MAY appear multiple times. The same Vendor ID MAY appear multiple times. There MUST NOT be more than one Vendor ID TLV inside a single VSC.
Type 44 Length n Value per vendor definition

Example: Configuration with vendor A specific fields and vendor B specific fields: VSC (44) + n (number of bytes inside this VSC) 8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor Vendor Specific Type #1 + length of the field + Value #1 Vendor Specific Type #2 + length of the field + Value #2
C.1.4 Dynamic-Service-Message-Specific Encodings

These encodings are not found in the configuration file, nor in the Registration Request/Response signaling. They are only found in DSA-REQ, DSA-RSP, DSA-ACK, DSC-REQ, DSC-RSP, DSC-ACK, and DSD-REQ messages (Section 8.3.12 through Section 8.3.18).
C.1.4.1 HMAC-Digest

The HMAC-Digest setting is a keyed message digest. If privacy is enabled, the HMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service messages Attribute list. The message digest is performed over the all of the Dynamic Service parameters (starting immediately after the MAC Management Message Header and up to, but not including the HMAC Digest setting), other than the HMAC-Digest, in the order in which they appear within the packet.

361

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Inclusion of the keyed digest allows the receiver to authenticate the message. The HMAC-Digest algorithm, and the upstream and downstream key generation requirements are documented in [DOCSIS8]. This parameter contains a keyed hash used for message authentication. The HMAC algorithm is defined in [RFC2104]. The HMAC algorithm is specified using a generic cryptographic hash algorithm. Baseline Privacy uses a particular version of HMAC that employs the Secure Hash Algorithm (SHA-1), defined in [SHA]. A summary of the HMAC-Digest Attribute format is shown below. The fields are transmitted from left to right.
Type 27 Length 20 Value A 160-bit (20-octet) keyed SHA hash

C.1.4.2

Authorization Block

The Authorization Block contains an authorization "hint". The specifics of the contents of this "hint" are beyond the scope of this specification, but include [PKT-DQOS]. The Authorization Block MAY be present in CM-initiated DSA-REQ and DSC-REQ messages, and CMTSinitiated DSA-RSP and DSC-RSP messages. This parameter MUST NOT be present in CMTS-initiated DSAREQ and DSC-REQ messages, nor CM-initiated DSA-RSP and DSC-RSP messages. The Authorization Block information applies to the entire content of the message. Thus, only a single Authorization Block per message MAY be present. The Authorization Block, if present, MUST be passed to the Authorization Module in the CMTS. The Authorization Block information is only processed by the Authorization Module.
Type 30 Length n Value Sequence of n octets

C.1.4.3

Key Sequence Number

The value shows the key sequence number of the BPI+ Authorization Key which is used to calculate the HMACDigest in case that the Privacy is enabled.
Type 31 Length 1 Value Auth Key Sequence Number (0 - 15)

C.2 Quality-of-Service-Related Encodings

C.2.1 Packet Classification Encodings

The following type/length/value encodings MUST be used in both the configuration file, registration messages, and Dynamic Service messages to encode parameters for packet classification and scheduling. All multi-octet quantities are in network-byte order, i.e., the octet containing the most-significant bits is the first transmitted on the wire. A classifier MUST contain at least one encoding from Annex C.2.1.5, Annex C.2.1.6, or Annex C.2.1.7. The following configuration settings MUST be supported by all CMs which are compliant with this specification. All CMTSes MUST support classification of downstream packets based on IP header fields (Annex C.2.1.5).

362

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.2.1.1

Upstream Packet Classification Encoding

This field defines the parameters associated with an upstream Classifier. Note that the same subtype fields defined are valid for both the encapsulated upstream and downstream packet classification configuration setting string. These type fields are not valid in other encoding contexts.
Type 22 Length n Value

C.2.1.2

Downstream Packet Classification Encoding

This field defines the parameters associated with a downstream Classifier. Note that the same subtype fields defined are valid for both the encapsulated upstream and downstream flow classification configuration setting string. These type fields are not valid in other encoding contexts.
Type 23 Length n Value

C.2.1.3 C.2.1.3.1

General Packet Classifier Encodings Classifier Reference

The value of the field specifies a reference for the Classifier. This value is unique per Dynamic Service message, configuration file, or Registration Request message.
Type [22/23].1 Length 1 Value 1 - 255

C.2.1.3.2 Classifier Identifier

The value of the field specifies an identifier for the Classifier. This value is unique to per Service Flow. The CMTS assigns the Packet Classifier Identifier.
Type [22/23].2 Length 2 Value 1 - 65535

C.2.1.3.3

Service Flow Reference

The value of the field specifies a Service Flow Reference that identifies the corresponding Service Flow. In all Packet Classifier TLVs that occur in any message where the Service Flow ID is not known (e.g., CMinitiated DSA-REQ and REG-REQ) this TLV MUST be included. In all Packet Classifier TLVs that occur in a DSC-REQ and CMTS-initiated DSA-REQ messages the Service Flow Reference MUST NOT be specified.
Type [22/23].3 Length 2 Value 1 - 65535

363

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.2.1.3.4 Service Flow Identifier

The value of this field specifies the Service Flow ID that identifies the corresponding Service Flow. In Packet Classifier TLVs where the Service Flow ID is not known, and this TLV MUST NOT be included (e.g., CM-initiated DSA-REQ and REG-REQ). In Packet Classifier TLVs that occur in a DSC-REQ and CMTSinitiated DSA-REQ message, the Service Flow ID MUST be specified.
Type [22/23].4 Length 4 Value 1 - 4,294,967,295

C.2.1.3.5

Rule Priority

The value of the field specifies the priority for the Classifier, which is used for determining the order of the Classifier. A higher value indicates higher priority. Classifiers that appear in Configuration files and Registration messages MAY have priorities in the range 0 - 255 with the default value 0. Classifiers that appear in DSA/DSC message MUST have priorities in the range 64-191, with the default value 64.
Type [22/23].5 Length 1 Value

C.2.1.3.6 Classifier Activation State

The value of this field specifies whether this classifier should become active in selecting packets for the Service Flow. An inactive Classifier is typically used with an AdmittedQoSParameterSet to ensure resources are available for later activation. The actual activation of the classifier depends both on this attribute and on the state of its service flow. If the service flow is not active then the classifier is not used, regardless of the setting of this attribute.
Type [22/23].6 Length 1 Value 0 Inactive 1 Active

The default value is 1 activate the classifier.

C.2.1.3.7 Dynamic Service Change Action

When received in a Dynamic Service Change Request, this indicates the action that should be taken with this classifier.
Type [22/23].7 Length 1 Value 0 DSC Add Classifier 1 DSC Replace Classifier 2 DSC Delete Classifier

C.2.1.4

Classifier Error Encodings

This field defines the parameters associated with Classifier Errors.

Type [22/23].8 Length n Value

364

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A Classifier Error Encoding consists of a single Classifier Error Parameter Set which is defined by the following individual parameters: Errored Parameter, Confirmation Code and Error Message. The Classifier Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages to indicate the reason for the recipients negative response to a Classifier establishment request in a REG-REQ, DSA-REQ or DSCREQ message. On failure, the REG-RSP, DSA-RSP or DSC-RSP MUST include one Classifier Error Encoding for at least one failed Classifier requested in the REG-REQ, DSA-REQ or DSC-REQ message. A Classifier Error Encoding for the failed Classifier MUST include the Confirmation Code and Errored Parameter and MAY include an Error Message. If some Classifier Sets are rejected but other Classifier Sets are accepted, then Classifier Error Encodings MUST be included for only the rejected Classifiers. On success of the entire transaction, the RSP or ACK message MUST NOT include a Classifier Error Encoding. Multiple Classifier Error Encodings may appear in a REG-RSP, DSA-RSP or DSC-RSP message, since multiple Classifier parameters may be in error. A message with even a single Classifier Error Encoding MUST NOT contain any other protocol Classifier Encodings (e.g. IP, 802.1P/Q). A Classifier Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQ messages.
C.2.1.4.1 Errored Parameter

The value of this parameter identifies the subtype of a requested Classifier parameter in error in a rejected Classifier request. A Classifier Error Parameter Set MUST have exactly one Errored Parameter TLV within a given Classifier Error Encoding.
Subtype [22/23].8.1 Length n Value Classifier Encoding Subtype in Error

If the length is one, then the value is the single-level subtype where the error was found, e.g., 7 indicates an invalid Change Action. If the length is two, then the value is the multi-level subtype where there error was found e.g., 9-2 indicates an invalid IP Protocol value.
C.2.1.4.2 Error Code

This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code as described in Annex C.4. A Classifier Error Parameter Set MUST have exactly one Error Code within a given Classifier Error Encoding.
Subtype [22/23].8.2 Length 1 Value Confirmation code

A value of okay (0) indicates that the Classifier request was successful. Since a Classifier Error Parameter Set applies only to errored parameters, this value MUST NOT be used.
C.2.1.4.3 Error Message

This subtype is optional in a Classifier Error Parameter Set. If present, it indicates a text string to be displayed on the CM console and/or log that further describes a rejected Classifier request. A Classifier Error Parameter Set MAY have zero or one Error Message subtypes within a given Classifier Error Encoding.
SubType [22/23].8.3 Length n Value Zero-terminated string of ASCII characters.

365

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note: Note:

The length N includes the terminating zero. The entire Classifier Encoding message MUST have a total length of less than 256 characters.

C.2.1.5

IP Packet Classification Encodings

This field defines the parameters associated with IP packet classification.

Type [22/23].9 Length n Value

C.2.1.5.1

IP Type of Service Range and Mask

The values of the field specify the matching parameters for the IP ToS byte range and mask. An IP packet with IP ToS byte value ip-tos matches this parameter if tos-low <= (ip-tos AND tos-mask) <= tos-high. If this field is omitted, then comparison of the IP packet ToS byte for this entry is irrelevant.
Type [22/23].9.1 Length 3 Value tos-low, tos-high, tos-mask

C.2.1.5.2

IP Protocol

The value of the field specifies the matching value for the IP Protocol field [RFC-1700]. If this parameter is omitted, then comparison of the IP header Protocol field for this entry is irrelevant. There are two special IP Protocol field values: 256 matches traffic with any IP Protocol value, and 257 matches both TCP and UDP traffic. An entry that includes an IP Protocol field value greater than 257 MUST be invalidated for comparisons (i.e., no traffic can match this entry).
Type [22/23].9.2 Length 2 Value prot1, prot2

Valid Range: 0 - 257

C.2.1.5.3 IP Source Address

The value of the field specifies the matching value for the IP source address. An IP packet with IP source address ip-src matches this parameter if src = (ip-src AND smask), where smask is the parameter from Annex C.2.1.5.4. If this parameter is omitted, then comparison of the IP packet source address for this entry is irrelevant.
Type [22/23].9.3 Length 4 Value src1, src2, src3, src4

C.2.1.5.4

IP Source Mask

The value of the field specifies the mask value for the IP source address, as described in Annex C.2.1.5.3. If this parameter is omitted, then the default IP source mask is 255.255.255.255.
Type [22/23].9.4 Length 4 Value smask1, smask2, smask3, smask4

366

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.2.1.5.5

IP Destination Address

The value of the field specifies the matching value for the IP destination address. An IP packet with IP destination address ip-dst matches this parameter if dst = (ip-dst AND dmask), where dmask is the parameter from Annex C.2.1.5.6. If this parameter is omitted, then comparison of the IP packet destination address for this entry is irrelevant.
Type [22/23].9.5 Length 4 Value dst1, dst2, dst3, dst4

C.2.1.5.6

IP Destination Mask

The value of the field specifies the mask value for the IP destination address, as described in Annex C.2.1.5.5. If this parameter is omitted, then the default IP destination mask is 255.255.255.255.
Type [22/23].9.6 Length 4 Value dmask1, dmask2, dmask3, dmask4

C.2.1.5.7

TCP/UDP Source Port Start

The value of the field specifies the low-end TCP/UDP source port value. An IP packet with TCP/UDP port value src-port matches this parameter if sportlow <= src-port <= sporthigh. If this parameter is omitted, then the default value of sportlow is 0. This parameter is irrelevant for non-TCP/UDP IP traffic.
Type [22/23].9.7 Length 2 Value sportlow1, sportlow2

C.2.1.5.8

TCP/UDP Source Port End

The value of the field specifies the high-end TCP/UDP source port value. An IP packet with TCP/UDP port value src-port matches this parameter if sportlow <= src-port <= sporthigh. If this parameter is omitted, then the default value of sporthigh is 65535. This parameter is irrelevant for non-TCP/UDP IP traffic.
Type [22/23].9.8 Length 2 Value sporthigh1, sporthigh2

C.2.1.5.9

TCP/UDP Destination Port Start

The value of the field specifies the low-end TCP/UDP destination port value. An IP packet with TCP/UDP port value dst-port matches this parameter if dportlow <= dst-port <=dporthigh. If this parameter is omitted, then the default value of dportlow is 0. This parameter is irrelevant for non-TCP/UDP IP traffic.
Type [22/23].9.9 Length 2 Value dportlow1, dportlow2

C.2.1.5.10

TCP/UDP Destination Port End

The value of the field specifies the high-end TCP/UDP destination port value. An IP packet with TCP/UDP port value dst-port matches this parameter if dportlow <= dst-port <= dporthigh. If this parameter is omitted, then the default value of dporthigh is 65535. This parameter is irrelevant for non-TCP/UDP IP traffic.
Type [22/23].9.10 Length 2 Value dporthigh1, dporthigh2

367

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.2.1.6

Ethernet LLC Packet Classification Encodings

This field defines the parameters associated with Ethernet LLC packet classification.
Type [22/23].10 Length n Value

C.2.1.6.1

Destination MAC Address

The values of the field specifies the matching parameters for the MAC destination address. An Ethernet packet with MAC destination address etherdst matches this parameter if dst = (etherdst AND msk). If this parameter is omitted, then comparison of the Ethernet MAC destination address for this entry is irrelevant.
Type [22/23].10.1 Length 12 Value dst1, dst2, dst3, dst4, dst5, dst6, msk1, msk2, msk3, msk4, msk5, msk6

C.2.1.6.2

Source MAC Address

The value of the field specifies the matching value for the MAC source address. If this parameter is omitted, then comparison of the Ethernet MAC source address for this entry is irrelevant.
Type [22/23].10.2 Length 6 Value src1, src2, src3, src4, src5, src6

C.2.1.6.3 Ethertype/DSAP/MacType

Type, eprot1, and eprot2 indicate the format of the layer 3 protocol ID in the Ethernet packet as follows: If type = 0, the rule does not use the layer 3 protocol type as a matching criterion. If type = 0, eprot1, eprot2 are ignored when considering whether a packet matches the current rule. If type = 1, the rule applies only to frames which contain an Ethertype value. Ethertype values are contained in packets using the DEC-Intel-Xerox (DIX) encapsulation or the [RFC-1042] Sub-Network Access Protocol (SNAP) encapsulation formats. If type = 1, then eprot1, eprot2 gives the 16-bit value of the Ethertype that the packet must match in order to match the rule If type = 2, the rule applies only to frames using the IEEE 802.2 encapsulation format with a Destination Service (DSAP) other than 0xAA (which is reserved for SNAP). If type = 2, the lower 8 bits of the eprot1, eprot2, MUST match the DSAP byte of the packet in order to match the rule. If type = 3, the rule applies only to MAC Management Messages (FC field 1100001x) with a type field of its MAC Management Message header (6.3.1) between the values of eprot1 and eprot2, inclusive. As exceptions, the following MAC Management message types MUST NOT be classified, and are always transmitted on the primary service flow: Type 4: RNG_REQ Type 6: REG_REQ Type 7: REG_RSP Type 14: REG_ACK If type = 4, the rule is considered a catch-all rule that matches all Data PDU packets. The rule does not match MAC Management Messages. The value of eprot1 and eprot2 are ignored in this case.

368

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

If the Ethernet frame contains an 802.1P/Q Tag header (i.e., Ethertype 0x8100), this object applies to the embedded Ethertype field within the 802.1P/Q header. Other values of type are reserved. If this TLV is omitted, then comparison of either the Ethertype or IEEE 802.2 DSAP for this rule is irrelevant.
Type [22/23].10.3 Length 3 Value type, eprot1, eprot2

C.2.1.7

IEEE 802.1P/Q Packet Classification Encodings

This field defines the parameters associated with IEEE 802.1P/Q packet classification.
Type [22/23].11 Length n Value

C.2.1.7.1

IEEE 802.1P User_Priority

The values of the field specify the matching parameters for the IEEE 802.1P user_priority bits. An Ethernet packet with IEEE 802.1P user_priority value priority matches these parameters if pri-low <= priority <= prihigh. If this field is omitted, then comparison of the IEEE 802.1P user_priority bits for this entry is irrelevant. If this parameter is specified for an entry, then Ethernet packets without IEEE 802.1Q encapsulation MUST NOT match this entry. If this parameter is specified for an entry on a CM that does not support forwarding of IEEE 802.1Q encapsulated traffic, then this entry MUST NOT be used for any traffic.
Type [22/23].11.1 Length 2 Value pri-low, pri-high

Valid Range is 0 7 for pri-low and pri-high

C.2.1.7.2 IEEE 802.1Q VLAN_ID

The value of the field specify the matching value for the IEEE 802.1Q vlan_id bits. Only the first (i.e., mostsignificant) 12 bits of the specified vlan_id field are significant; the final four bits MUST be ignored for comparison. If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant. If this parameter is specified for an entry, then Ethernet packets without IEEE 802.1Q encapsulation MUST NOT match this entry. If this parameter is specified for an entry on a CM that does not support forwarding of IEEE 802.1Q encapsulated traffic, then this entry MUST NOT be used for any traffic.
Type [22/23].11.2 Length 2 Value vlan_id1, vlan_id2

C.2.1.7.3 Vendor Specific Classifier Parameters

This allows vendors to encode vendor-specific classifier parameters using the DOCSIS Extension Field. The Vendor ID MUST be the first TLV embedded inside Vendor Specific Classifier Parameters. If the first TLV inside Vendor Specific Classifier Parameters is not a Vendor ID, then the TLV MUST be discarded. (Refer to Annex C.1.1.17)1
Type [22/23].43 Length Value n

369

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.2.2 Service Flow Encodings

The following type/length/value encodings MUST be used in the configuration file, registration messages, and Dynamic Service messages to encode parameters for Service Flows. All multi-octet quantities are in networkbyte order, i.e., the octet containing the most-significant bits is the first transmitted on the wire. The following configuration settings MUST be supported by all CMs which are compliant with this specification.
C.2.2.1 Upstream Service Flow Encodings

This field defines the parameters associated with upstream scheduling for a Service Flow. It is somewhat complex in that is composed from a number of encapsulated type/length/value fields. Note that the encapsulated upstream and downstream Service Flow configuration setting strings share the same subtype field numbering plan, because many of the subtype fields defined are valid for both types of configuration settings. These type fields are not valid in other encoding contexts.
Type 24 Length n Value

C.2.2.2

Downstream Service Flow Encodings

This field defines the parameters associated with downstream scheduling for a Service Flow. It is somewhat complex in that is composed from a number of encapsulated type/length/value fields. Note that the encapsulated upstream and downstream flow classification configuration setting strings share the same subtype field numbering plan, because many of the subtype fields defined are valid for both types of configuration settings except Service Flow encodings. These type fields are not valid in other encoding contexts.
Type 25 Length n Value

C.2.2.3 C.2.2.3.1

General Service Flow Encodings Service Flow Reference

The Service Flow Reference is used to associate a packet classifier encoding with a Service Flow encoding. A Service Flow Reference is only used to establish a Service Flow ID. Once the Service Flow exists and has an assigned Service Flow ID, the Service Flow Reference MUST no longer be used. The Service Flow Reference is unique per configuration file, Registration message exchange, or Dynamic Service Add message exchange.
Type [24/25].1 Length 2 Value 1 - 65535

1.

Revised this paragraph per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

370

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.2.2.3.2

Service Flow Identifier

The Service Flow Identifier is used by the CMTS as the primary reference of a Service Flow. Only the CMTS can issue a Service Flow Identifier. It uses this parameterization to issue Service Flow Identifiers in CMTSinitiated DSA-Requests and in its REG/DSA-Response to CM-initiated REG/DSA-Requests. The CM specifies the SFID of a service flow using this parameter in a DSC-REQ message. Both the CM and CMTS MAY use this TLV to encode Service Flow IDs in a DSD-REQ. The configuration file MUST NOT contain this parameter.
Type [24/25].2 Length 4 Value 1 - 4,294,967,295

C.2.2.3.3 Service Identifier1

The value of this field specifies the Service Identifier assigned by the CMTS to a Service Flow with a non-null AdmittedQosParameterSet or ActiveQosParameterSet. This is used in the bandwidth allocation MAP to assign upstream bandwidth. This field MUST be present in CMTS-initiated DSA-REQ or DSC-REQ message related to establishing an admitted or active upstream Service Flow. This field MUST also be present in REG-RSP, DSARSP, and DSC-RSP messages related to the successful establishment of an admitted or active upstream Service Flow. This field MUST NOT be present in settings related to downstream Service Flows; the Service Identifier only applies to upstream Service Flows. Even though a Service Flow has been successfully admitted or activated (i.e., has an assigned Service ID) the Service Flow ID MUST be used for subsequent DSx message signaling as it is the primary handle for a service flow. If a Service Flow is no longer admitted or active (via DSC-REQ) its Service ID MAY be reassigned by the CMTS.
SubType [24].3 Length 2 Value SID (low-order 14 bits)

C.2.2.3.4

Service Class Name

The value of the field refers to a predefined CMTS service configuration to be used for this Service Flow.
Type [24/25].4
Note:

Length 2 to 16

Value Zero-terminated string of ASCII characters.

The length includes the terminating zero.

When the Service Class Name is used in a Service Flow encoding, it indicates that all the unspecified QoS Parameters of the Service Flow need to be provided by the CMTS. It is up to the operator to synchronize the definition of Service Class Names in the CMTS and in the configuration file.
C.2.2.3.5 Quality of Service Parameter Set Type

This parameter MUST appear within every Service Flow Encoding, with the exception of Service Flow Encodings in the DSD-REQ where the Quality of Service Parameter Set Type has no value. It specifies the proper application of the QoS Parameter Set or Service Class Name: to the Provisioned set, the Admitted set, and/or the Active set. When two QoS Parameter Sets are the same, a multi-bit value of this parameter MAY be
1.

Revised this section per ECN RFI2-N-02226 by GO on 02/26/03.

371

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

used to apply the QoS parameters to more than one set. A single message MAY contain multiple QoS parameter sets in separate type 24/25 Service Flow Encodings for the same Service Flow. This allows specification of the QoS Parameter Sets when their parameters are different. Bit 0 is the LSB of the Value field. For every Service Flow that appears in a Registration-Request or Registration-Response message, there MUST be a Service Flow Encoding that specifies a ProvisionedQoSParameterSet. This Service Flow Encoding, or other Service Flow Encoding(s), MAY also specify an Admitted and/or Active set. Any Service Flow Encoding that appears in a Dynamic Service Message MUST NOT specify the ProvisionedQoSParameterSet.
Type [24/25].6 Length 1 Value Bit # 0 Provisioned Set Bit # 1 Admitted Set Bit # 2 Active Set

Table C-2 Values Used in REG-REQ and REG-RSP Messages

Value Messages

001 011 101 111

Apply to Provisioned set only Apply to Provisioned and Admitted set, and perform admission control Apply to Provisioned and Active sets, perform admission control on Admitted set in separate Service Flow Encoding, and activate the Service flow. Apply to Provisioned, Admitted, and Active sets; perform admission control and activate this Service Flow

Table C-3
Value

Values Used In REG-REQ, REG-RSP, and Dynamic Service Messages

Messages

010 100 110

Perform admission control and apply to Admitted set Check against Admitted set in separate Service flow Encoding, perform admission control if needed, activate this Service Flow, and apply to Active set Perform admission control and activate this Service Flow, apply parameters to both Admitted and Active sets

The value 000 is used only in Dynamic Service Change messages. It is used to set the Active and Admitted sets to Null (see Section 10.1.7.4). A CMTS MUST handle a single update to each of the Active and Admitted QoS parameter sets. The ability to process multiple Service Flow Encodings that specify the same QoS parameter set is NOT required, and is left as a vendor-specific function. If a DSA/DSC contains multiple updates to a single QoS parameter set and the vendor does not support such updates, then the CMTS MUST reply with error code 2, reject-unrecognizedconfiguration-setting.
C.2.2.4 Service Flow Error Encodings

This field defines the parameters associated with Service Flow Errors.
Type [24/25].5 Length n Value

A Service Flow Error Encoding consists of a single Service Flow Error Parameter Set which is defined by the following individual parameters: Errored Parameter, Confirmation Code and Error Message.
372

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The Service Flow Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages to indicate the reason for the recipients negative response to a Service Flow establishment request in a REG-REQ, DSA-REQ or DSC-REQ message. The Service Flow Error Encoding is returned in REG-ACK, DSA-ACK and DSC-ACK messages to indicate the reason for the recipients negative response to the expansion of a Service Class Name in a corresponding REGRSP, DSA-RSP or DSC-RSP. On failure, the REG-RSP, DSA-RSP or DSC-RSP MUST include one Service Flow Error Encoding for at least one failed Service Flow requested in the REG-REQ, DSA-REQ or DSC-REQ message. On failure, the REGACK, DSA-ACK or DSC-ACK MUST include one Service Flow Error Encoding for at least one failed Service Class Name expansion in the REG-RSP, DSA-RSP or DSC-RSP message. A Service Flow Error Encoding for the failed Service Flow MUST include the Confirmation Code and Errored Parameter and MAY include an Error Message. If some Service Flow Parameter Sets are rejected but other Service Flow Parameter Sets are accepted, then Service Flow Error Encodings MUST be included for only the rejected Service Flow. On success of the entire transaction, the RSP or ACK message MUST NOT include a Service Flow Error Encoding. Multiple Service Flow Error Encodings MAY appear in a REG-RSP, DSA-RSP, DSC-RSP, REG-ACK, DSAACK or DSC-ACK message, since multiple Service Flow parameters may be in error. A message with even a single Service Flow Error Encoding MUST NOT contain any QoS Parameters. A Service Flow Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQ messages.
C.2.2.4.1 Errored Parameter

The value of this parameter identifies the subtype of a requested Service Flow parameter in error in a rejected Service Flow request or Service Class Name expansion response.A Service Flow Error Parameter Set MUST have exactly one Errored Parameter TLV within a given Service Flow Error Encoding.
Subtype [24/25].5.1 Length 1 Value Service Flow Encoding Subtype in Error

C.2.2.4.2 Error Code

This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code as described in Annex C.4. A Service Flow Error Parameter Set MUST have exactly one Error Code within a given Service Flow Error Encoding.
Subtype [24/25].5.2 Length 1 Value Confirmation code

A value of okay(0) indicates that the Service Flow request was successful. Since a Service Flow Error Parameter Set only applies to errored parameters, this value MUST NOT be used.

373

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.2.2.4.3 Error Message

This subtype is optional in a Service Flow Error Parameter Set. If present, it indicates a text string to be displayed on the CM console and/or log that further describes a rejected Service Flow request. A Service Flow Error Parameter Set MAY have zero or one Error Message subtypes within a given Service Flow Error Encoding.
SubType [24/25].5.3
Note: Note:

Length n

Value Zero-terminated string of ASCII characters.

The length N includes the terminating zero. The entire Service Flow Encoding message MUST have a total length of less than 256 characters.

C.2.2.5

Common Upstream and Downstream Quality-of-Service Parameter Encodings

The remaining Type 24 & 25 parameters are QoS Parameters. Any given QoS Parameter type MUST appear zero or one times per Service Flow Encoding.
C.2.2.5.1 Traffic Priority

The value of this parameter specifies the priority assigned to a Service Flow. Given two Service Flows identical in all QoS parameters besides priority, the higher priority Service Flow SHOULD be given lower delay and higher buffering preference. For otherwise non-identical Service Flows, the priority parameter SHOULD NOT take precedence over any conflicting Service Flow QoS parameter. The specific algorithm for enforcing this parameter is not mandated here. For upstream service flows, the CMTS SHOULD use this parameter when determining precedence in request service and grant generation, and the CM MUST preferentially select contention Request opportunities for Priority Request Service IDs (refer to A.2.3) based on this priority and its Request/Transmission Policy (refer to Annex C.2.2.6.3).
Type [24/25].7
Note:

Length 1

Value 0 to 7 Higher numbers indicate higher priority

The default priority is 0.

C.2.2.5.2

Maximum Sustained Traffic Rate

This parameter is the rate parameter R of a token-bucket-based rate limit for packets. R is expressed in bits per second, and MUST take into account all MAC frame data PDU of the Service Flow from the byte following the MAC header HCS to the end of the CRC.1 The number of bytes forwarded (in bytes) is limited during any time interval T by Max(T), as described in the expression Max(T) = T * (R / 8) + B, (1) where the parameter B (in bytes) is the Maximum Traffic Burst Configuration Setting (refer to Annex C.2.2.5.3).
Note:

This parameter does not limit the instantaneous rate of the Service Flow.

Note: The specific algorithm for enforcing this parameter is not mandated here. Any implementation which satisfies the above equation is conformant.

1.

The payload size includes every PDU in a Concatenated MAC Frame.

374

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Note: If this parameter is omitted or set to zero, then there is no explicitly-enforced traffic rate maximum. This field specifies only a bound, not a guarantee that this rate is available.

C.2.2.5.2.1

Upstream Maximum Sustained Traffic Rate

For an upstream Service Flow, the CM MUST NOT request bandwidth exceeding the Max(T) requirement in (1) during any interval T because this could force the CMTS to fill MAPs with deferred grants. The CM MUST defer upstream packets that violate (1) and rate shape them to meet the expression, up to a limit as implemented by vendor buffering restrictions. The CMTS MUST enforce expression (1) on all upstream data transmissions, including data sent in contention. The CMTS MAY consider unused grants in calculations involving this parameter. The CMTS MAY enforce this limit by any of the following methods: (a) discarding over-limit requests, (b) deferring (through zero-length grants) the grant until it is conforming to the allowed limit, or (c) discarding over-limit data packets. A CMTS MUST report this condition to a policy module. If the CMTS is policing by discarding either packets or requests, the CMTS MUST allow a margin of error between the CM and CMTS algorithms.
Type 24.8 Length 4 Value R (in bits per second)

C.2.2.5.2.2

Downstream Maximum Sustained Traffic Rate

For a downstream Service Flow, this parameter is only applicable at the CMTS. The CMTS MUST enforce expression (1) on all downstream data transmissions. The CMTS MUST NOT forward downstream packets that violates (1) in any interval T. The CMTS SHOULD rate shape the downstream traffic by enqueuing packets arriving in excess of (1), and delay them until the expression can be met. This parameter is not intended for enforcement on the CM.
Type 25.8 Length 4 Value R (in bits per second)

C.2.2.5.3

Maximum Traffic Burst

The value of this parameter specifies the token bucket size B (in bytes) for this Service Flow as described in expression (1). This value is calculated from the byte following the MAC header HCS to the end of the CRC1. The minimum value of B is 1522 bytes. If this parameter is omitted, the default value for B is 3044 bytes. This parameter has no effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter. For an upstream service flow, if B is sufficiently less than the Maximum Concatenated Burst parameter, then enforcement of the rate limit equation will limit the maximum size of a concatenated burst.2
Type [24/25].9 Length 4 Value B (bytes)

1. 2.

The payload size includes every PDU in a Concatenated MAC Frame. Section C.2.2.5.3 text from The minimum value of B to this footnote, updated per RFI2-N-02090 by RKV on 10/28/02.

375

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Note: The specific algorithm for enforcing this parameter is not mandated here. Any implementation which satisfies the above equation is conformed. Note: The value of this parameter effects the trade-off between the data latency perceived by an individual application, and the traffic engineering requirements of the network. A large value will tend to reduce the latency introduced by rate limiting for applications with bursty traffic patterns. A small value will tend to spread out the bursts of data generated by such applications, which may benefit traffic engineering within the network.1

C.2.2.5.4

Minimum Reserved Traffic Rate

This parameter specifies the minimum rate, in bits/sec, reserved for this Service Flow. The CMTS SHOULD be able to satisfy bandwidth requests for a Service Flow up to its Minimum Reserved Traffic Rate. If less bandwidth than its Minimum Reserved Traffic Rate is requested for a Service Flow, the CMTS MAY reallocate the excess reserved bandwidth for other purposes. The aggregate Minimum Reserved Traffic Rate of all Service Flows MAY exceed the amount of available bandwidth. This value of this parameter is calculated from the byte following the MAC header HCS to the end of the CRC2. If this parameter is omitted, then it defaults to a value of 0 bits/sec (i.e., no bandwidth is reserved for the flow by default). This field is only applicable at the CMTS and MUST be enforced by the CMTS.
Type [24/25].10
Note:

Length 4

Value

The specific algorithm for enforcing the value specified in this field is not mandated here.

C.2.2.5.5

Assumed Minimum Reserved Rate Packet Size

The value of this field specifies an assumed minimum packet size (in bytes) for which the Minimum Reserved Traffic Rate will be provided. This parameter is defined in bytes and is specified as the bytes following the MAC header HCS to the end of the CRC3. If the Service flow sends packets of a size smaller than this specified value, such packets will be treated as being of the size specified in this parameter for calculating the Minimum Reserved Traffic Rate.4 The CMTS MUST apply this parameter to its Minimum Reserved Traffic Rate algorithm. This parameter is used by the CMTS to estimate the per packet overhead of each packet in the service flow. If this parameter is omitted, then the default value is CMTS implementation dependent.
Type [24/25].11 Length 2 Value

C.2.2.5.6 Timeout for Active QoS Parameters

The value of this parameter specifies the maximum duration resources remain unused on an active Service Flow. If there is no activity on the Service Flow within this time interval, the CMTS MUST change the active and admitted QoS Parameter Sets to null. The CMTS MUST signal this resource change with a DSC-REQ to the CM.
1. 2. 3. 4.

Section C.2.2.5.3 second Note added per RFI2-N-02090 by RKV on 10/28/02. The payload size includes every PDU in a Concatenated MAC Frame. The payload size includes every PDU in a Concatenated MAC Frame. Revised the last sentence in this paragraph per ECN RFI2-N-03093 by GO on 11/17/03.

376

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Type [24/25].12

Length 2

Value seconds

This parameter MUST be enforced at the CMTS and SHOULD NOT be enforced at the CM. The parameter is processed by the CMTS for every QoS set contained in Registration messages and Dynamic Service messages. If the parameter is omitted, the default of 0 (i.e., infinite timeout) is assumed. The value specified for the active QoS set must be less than or equal to the corresponding value in the admitted QoS set which must be less than or equal to the corresponding value in the provisioned/authorized QoS set. If the requested value is too large, the CMTS MAY reject the message or respond with a value less than that requested. If the Registration or Dynamic Service message is accepted by the CMTS and acknowledged by the CM, the Active MQoS Timeout timer is loaded with the new value of the timeout. The timer is activated if the message activates the associated Service Flow. The timer is deactivated if the message sets the active QoS set to null.
C.2.2.5.7 Timeout for Admitted QoS Parameters

The value of this parameter specifies the duration that the CMTS MUST hold resources for a Service Flows Admitted QoS Parameter Set while they are in excess of its Active QoS Parameter Set. If there is no DSC-REQ to activate the Admitted QoS Parameter Set within this time interval, and there is no DSC to refresh the QoS parameter sets and restart the timeout (see 8.1.5.2), the resources that are admitted but not activated MUST be released, and only the active resources retained. The CMTS MUST set the Admitted QoS Parameter Set equal to the Active QoS Parameter Set for the Service Flow and initiate a DSC-REQ exchange with the CM to inform it of the change.
Type [24/25].13 Length 2 Value seconds

This parameter MUST be enforced at the CMTS and SHOULD NOT be enforced at the CM. The parameter is processed by the CMTS for every QoS set contained in Registration messages and Dynamic Service messages. If the parameter is omitted, the default of 200 seconds is assumed. A value of 0 means that the Service Flow can remain in the admitted state for an infinite amount of time and MUST NOT be timed out due to inactivity. However, this is subject to policy control by the CMTS. The value specified for the active QoS set must be less than or equal to the corresponding value in the admitted QoS set which must be less than or equal to the corresponding value in the provisioned/authorized QoS set. If the requested value is too large, the CMTS MAY reject the message or respond with a value less than that requested. If the Registration or Dynamic Service message containing this parameter is accepted by the CMTS and acknowledged by the CM, the Admitted QoS Timeout timer is loaded with the new value of the timeout. The timer is activated if the message admits resources greater than the active set. The timer is deactivated if the message sets the active QoS set and admitted QoS set equal to each other.
C.2.2.5.8 Vendor Specific QoS Parameters

This allows vendors to encode vendor-specific QoS parameters using the DOCSIS Extension Field. The Vendor ID MUST be the first TLV embedded inside Vendor Specific QoS Parameters. If the first TLV inside Vendor Specific QoS Parameters is not a Vendor ID, then the TLV MUST be discarded. (Refer to Annex C.1.1.17)1
Type [24/25].43 Length n Value

1.

Revised this paragraph per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

377

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

C.2.2.6 C.2.2.6.1

Upstream-Specific QoS Parameter Encodings Maximum Concatenated Burst

The value of this parameter specifies the maximum concatenated burst (in bytes) which a Service Flow is allowed. This parameter is calculated from the FC byte of the Concatenation MAC Header to the last CRC in the concatenated MAC frame. A value of 0 means there is no limit. If this parameter is omitted the default value is 1522.1 This field is only applicable at the CM. If defined, this parameter MUST be enforced at the CM.
Note:

This value does not include any physical layer overhead. Length 2 Value

Type 24.14

Note: This applies only to concatenated bursts. It is legal and, in fact, it may be useful to set this smaller than the maximum Ethernet packet size. Of course, it is also legal to set this equal to or larger than the maximum Ethernet packet size. Note: The maximum size of a concatenated burst can also be limited by the enforcement of a rate limit, if the Maximum Traffic Burst parameter is small enough, and by limits on the size of data grants in the UCD message.2

C.2.2.6.2

Service Flow Scheduling Type

The value of this parameter specifies which upstream scheduling service is used for upstream transmission requests and packet transmissions. If this parameter is omitted, then the Best Effort service MUST be assumed. This parameter is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.3
Type 24.15 Length 1 Value 0 Reserved 1 for Undefined (CMTS implementation-dependent1) 2 for Best Effort 3 for Non-Real-Time Polling Service 4 for Real-Time Polling Service 5 for Unsolicited Grant Service with Activity Detection 6 for Unsolicited Grant Service 7 through 255 are reserved for future use
1.

The specific implementation dependent scheduling service type could be defined in the 24.43 Vendor Specific QoS Parameters. (Refer to Annex C.2.2.5.8).

C.2.2.6.3

Request/Transmission Policy

The value of this parameter specifies which IUC opportunities the CM uses for upstream transmission requests and packet transmissions for this Service Flow, whether requests for this Service Flow may be piggybacked with data and whether data packets transmitted on this Service Flow can be concatenated, fragmented, or have their
1. 2. 3.

Second sentence updated per RFI2-N-02090 by RKV on 10/28/02. Section C.2.2.6.1, last Note added per RFI2-N-02090 by RKV on 10/28/02. Revised Table Note 1 per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

378

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

payload headers suppressed. For UGS, it also specifies how to treat packets that do not fit into the UGS grant. See Section 10.2 for requirements related to settings of the bits of this parameter for each Service Flow Scheduling Type. This parameter is required for all Service Flow Scheduling Types except Best Effort. If omitted in a Best Effort Service Flow QoS parameter Set, the default value of zero MUST be used. Bit #0 is the LSB of the Value field. Bits are set to 1 to select the behavior defined below:
Type 24.16 Length 4 Value Bit #0 The Service Flow MUST NOT use all CMs broadcast request opportunities. Bit #1 The Service Flow MUST NOT use Priority Request multicast request opportunities. (Refer to Annex A.2.3) Bit #2 The Service Flow MUST NOT use Request/Data opportunities for Requests Bit #3 The Service Flow MUST NOT use Request/Data opportunities for Data Bit #4 The Service Flow MUST NOT piggyback requests with data. Bit #5 The Service Flow MUST NOT concatenate data. Bit #6 The Service Flow MUST NOT fragment data Bit #7 The Service Flow MUST NOT suppress payload headers Bit #8 The Service Flow MUST drop packets that do not fit in the Unsolicited Grant Size 1 2 All other bits are reserved.
1.

This bit only applies to Service Flows with the Unsolicited Grant Service Flow Scheduling Type, if this bit is set on any other Service Flow Scheduling type it MUST be ignored Packets that classify to an Unsolicited Grant Service Flow and are larger than the Grant Size associated with that Service Flow are normally transmitted on the Primary Service Flow. This parameter overrides that default behavior. Data grants include both short and long data grants.

2.

Note:

C.2.2.6.4

Nominal Polling Interval

The value of this parameter specifies the nominal interval (in units of microseconds) between successive unicast request opportunities for this Service Flow on the upstream channel. This parameter is typically suited for RealTime and Non-Real-Time Polling Service. The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmission times ti = t0 + i*interval. The actual poll times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval is the value specified with this TLV, and jitter is Tolerated Poll Jitter. The accuracy of the ideal poll times, ti, are measured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3). This field is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.
Type 24.17 Length 4 Value sec

C.2.2.6.5

Tolerated Poll Jitter

The values in this parameter specifies the maximum amount of time that the unicast request interval may be delayed from the nominal periodic schedule (measured in microseconds) for this Service Flow. The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired poll times ti = t0 + i*interval. The actual poll, t'i MUST be in the range ti <= t'i <= ti + jitter, where jitter is the value specified
379

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

with this TLV and interval is the Nominal Poll Interval. The accuracy of the ideal poll times, ti, are measured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3). This parameter is only applicable at the CMTS. If defined, this parameter represents a service commitment (or admission criteria) at the CMTS.
Type 24.18 Length 4 Value sec

C.2.2.6.6

Unsolicited Grant Size

The value of this parameter specifies the unsolicited grant size in bytes. The grant size includes the entire MAC frame data PDU from the Frame Control byte to end of the MAC frame. This parameter is applicable at the CMTS and MUST be enforced at the CMTS.
Type 24.19
Note:

Length 2

Value

For UGS, this parameter should be used by the CMTS to compute the size of the unsolicited grant in mini-slots.

C.2.2.6.7

Nominal Grant Interval

The value of this parameter specifies the nominal interval (in units of microseconds) between successive data grant opportunities for this Service Flow. This parameter is required for Unsolicited Grant and Unsolicited Grant with Activity Detection Service Flows. The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmission times ti = t0 + i*interval. The actual grant times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval is the value specified with this TLV, and jitter is the Tolerated Grant Jitter. When multiple grants per interval are requested, all grants MUST be within this interval, thus the Nominal Grant Interval and Tolerated Grant Jitter MUST be maintained by the CMTS for all grants in this Service Flow. The accuracy of the ideal grant times, ti, are measured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3). This field is mandatory for Unsolicited Grant and Unsolicited Grant with Activity Detection Scheduling Types. This field is only applicable at the CMTS, and MUST be enforced by the CMTS.
Type 24.20 Length 4 Value sec

C.2.2.6.8

Tolerated Grant Jitter

The values in this parameter specifies the maximum amount of time that the transmission opportunities may be delayed from the nominal periodic schedule (measured in microseconds) for this Service Flow. The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmission times ti = t0 + i*interval. The actual transmission opportunities, t'i MUST be in the range ti <= t'i <= ti + jitter, where jitter is the value specified with this TLV and interval is the Nominal Grant Interval. The accuracy of the ideal grant times, ti, are measured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3).

380

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

This field is mandatory for Unsolicited Grant and Unsolicited Grant with Activity Detection Scheduling Types. This field is only applicable at the CMTS, and MUST be enforced by the CMTS.
Type 24.21 Length 4 Value sec

C.2.2.6.9 Grants per Interval

For Unsolicited Grant Service, the value of this parameter indicates the actual number of data grants per Nominal Grant Interval. For Unsolicited Grant Service with Activity Detection, the value of this parameter indicates the maximum number of Active Grants per Nominal Grant Interval. This is intended to enable the addition of sessions to an existing Unsolicited Grant Service Flow via the Dynamic Service Change mechanism, without negatively impacting existing sessions. The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmission times ti = t0 + i*interval. The actual grant times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval is the Nominal Grant Interval, and jitter is the Tolerated Grant Jitter. When multiple grants per interval are requested, all grants MUST be within this interval, thus the Nominal Grant Interval and Tolerated Grant Jitter MUST be maintained by the CMTS for all grants in this Service Flow. This field is mandatory for Unsolicited Grant and Unsolicited Grant with Activity Detection Scheduling Types. This field is only applicable at the CMTS, and MUST be enforced by the CMTS.
Type 24.22 Length 1 Value # of grants Valid Range 0-127

C.2.2.6.10

IP Type of Service Overwrite

The CMTS MUST overwrite IP packets with IP ToS byte value orig-ip-tos with the value new-ip-tos, where new-ip-tos = ((orig-ip-tos AND tos-and-mask) OR tos-or-mask). If this parameter is omitted, then the IP packet ToS byte is not overwritten. This parameter is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.
Type 24.23 Length 2 Value tos-and-mask, tos-or-mask

C.2.2.6.11

Unsolicited Grant Time Reference

For Unsolicited Grant Service and Unsolicited Grant Service with Activity Detection, the value of this parameter specifies a reference time t0 from which can be derived the desired transmission times ti = t0 + i*interval, where interval is the Nominal Grant Interval (Refer to Annex C.2.2.6.7). This parameter is applicable only for messages transmitted from the CMTS to the CM, and only when a UGS or UGS-AD service flow is being made active. In such cases this is a mandatory parameter.
Type 24.24 Length 4 Value CMTS Timestamp Valid Range 0-4,294,967,295

381

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The timestamp specified in this parameter represents a count state of the CMTS 10.24 MHz master clock. Since a UGS or UGS-AD service flow is always activated before transmission of this parameter to the modem, the reference time t0 is to be interpreted by the modem as the ideal time of the next grant only if t0 follows the current time. If t0 precedes the current time, the modem can calculate the offset from the current time to the ideal time of the next grant according to:
interval - (((current time - t0)/10.24) modulus interval)

where interval is in units of microseconds, and current time and t0 are in 10.24 MHz units.
C.2.2.7 C.2.2.7.1 Downstream-Specific QoS Parameter Encodings Maximum Downstream Latency

The value of this parameter specifies the maximum latency between the reception of a packet by the CMTS on its NSI and the forwarding of the packet to its RF Interface. If defined, this parameter represents a service commitment (or admission criteria) at the CMTS and MUST be guaranteed by the CMTS. A CMTS does not have to meet this service commitment for Service Flows that exceed their minimum downstream reserved rate.
Type 25.14 Length 4 Value sec

C.2.2.8

Payload Header Suppression

This field defines the parameters associated with Payload Header Suppression.
Type 26
Note:

Length n

Value

The entire Payload Header Suppression TLV MUST have a length of less than 255 characters.

C.2.2.8.1

Classifier Reference

The value of the field specifies a Classifier Reference that identifies the corresponding Classifier. (Refer to Annex C.2.1.3.1)
Type 26.1 Length 1 Value 1 - 255

C.2.2.8.2

Classifier Identifier

The value of the field specifies a Classifier Identifier that identifies the corresponding Classifier. (Refer to Annex C.2.1.3.2)
Type 26.2 Length 2 Value 1 - 65535

382

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.2.2.8.3

Service Flow Reference

The value of the field specifies a Service Flow Reference that identifies the corresponding Service Flow. (Refer to Annex C.2.2.3.1)
Type 26.3 Length 2 Value 1 - 65535

C.2.2.8.4

Service Flow Identifier

The value of this field specifies the Service Flow Identifier that identifies the Service Flow to which the PHS rule applies.
Type 26.4 Length 4 Value 1 - 4,294,967,295

C.2.2.8.5 Dynamic Service Change Action

When received in a Dynamic Service Change Request, this indicates the action that MUST be taken with this payload header suppression byte string.
Type 26.5 Length 1 Value 0 Add PHS Rule 1 Set PHS Rule 2 Delete PHS Rule 3 Delete all PHS Rules

The Set PHS Rule command is used to add specific TLVs to a partially defined payload header suppression rule. A PHS rule is partially defined when the PHSF and PHSS values are not both known. A PHS rule becomes fully defined when the PHSF and PHSS values are both known. Once a PHS rule is fully defined, Set PHS Rule MUST NOT be used to modify existing TLVs. The Delete all PHS Rules command is used to delete all PHS Rules for a specified Service Flow. See Section 8.3.15 for details on DSC-REQ required PHS parameters when using this option.
Note:

An attempt to Add a PHS Rule which already exists is an error condition.

C.2.2.9

Payload Header Suppression Error Encodings

This field defines the parameters associated with Payload Header Suppression Errors.
Type 26.6 Length n Value

A Payload Header Suppression Error Encoding consists of a single Payload Header Suppression Error Parameter Set which is defined by the following individual parameters: Errored Parameter, Confirmation Code and Error Message. The Payload Header Suppression Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages to indicate the reason for the recipients negative response to a Payload Header Suppression Rule establishment request in a REG-REQ, DSA-REQ or DSC-REQ message.

383

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

On failure, the REG-RSP, DSA-RSP, or DSC-RSP MUST include one Payload Header Suppression Error Encoding for at least one failed Payload Header Suppression Rule requested in the REG-REQ, DSA-REQ or DSC-REQ message. A Payload Header Suppression Error Encoding for the failed Payload Header Suppression Rule MUST include the Confirmation Code and Errored Parameter and MAY include an Error Message. If some Payload Header Suppression Rule Sets are rejected but other Payload Header Suppression Rule Sets are accepted, then Payload Header Suppression Error Encodings MUST be included for only the rejected Payload Header Suppression Rules. On success of the entire transaction, the RSP or ACK message MUST NOT include a Payload Header Suppression Error Encoding. Multiple Payload Header Suppression Error Encodings MAY appear in a REG-RSP, DSA-RSP or DSC-RSP message, since multiple Payload Header Suppression parameters may be in error. A message with even a single Payload Header Suppression Error Encoding MUST NOT contain any other protocol Payload Header Suppression Encodings (e.g., IP, 802.1P/Q). A Payload Header Suppression Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQ messages.
C.2.2.9.1 Errored Parameter

The value of this parameter identifies the subtype of a requested Payload Header Suppression parameter in error in a rejected Payload Header Suppression request. A Payload Header Suppression Error Parameter Set MUST have exactly one Errored Parameter TLV within a given Payload Header Suppression Error Encoding.
Subtype 26.6.1 Length 1 Value Payload Header Suppression Encoding Subtype in Error

C.2.2.9.2 Error Code

This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code as described in Annex C.4. A Payload Header Suppression Error Parameter Set MUST have exactly one Error Code within a given Payload Header Suppression Error Encoding.
Subtype 26.6.2 Length 1 Value Confirmation code

A value of okay(0) indicates that the Payload Header Suppression request was successful. Since a Payload Header Suppression Error Parameter Set only applies to errored parameters, this value MUST NOT be used.
C.2.2.9.3 Error Message

This subtype is optional in a Payload Header Suppression Error Parameter Set. If present, it indicates a text string to be displayed on the CM console and/or log that further describes a rejected Payload Header Suppression request. A Payload Header Suppression Error Parameter Set MAY have zero or one Error Message subtypes within a given Payload Header Suppression Error Encoding.
SubType 26.6.3
Note: Note:

Length n

Value Zero-terminated string of ASCII characters.

The length n includes the terminating zero. The entire Payload Header Suppression Encoding message MUST have a total length of less than 256 characters.

384

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.2.2.10 C.2.2.10.1

Payload Header Suppression Rule Encodings Payload Header Suppression Field (PHSF)

The value of this field are the bytes of the headers which MUST be suppressed by the sending entity, and MUST be restored by the receiving entity. In the upstream, the PHSF corresponds to the string of PDU bytes starting with the first byte after the MAC Header Checksum. For the downstream, the PHSF corresponds to the string of PDU bytes starting with the 13th byte after the MAC Header Checksum. This string of bytes is inclusive of both suppressed and unsuppressed bytes of the PDU header. The value of the unsuppressed bytes within the PHSF is implentation dependent. The ordering of the bytes in the value field of the PHSF TLV string MUST follow the sequence: Upstream MSB of PHSF value = 1st byte of PDU 2nd MSB of PHSF value = 2nd byte of PDU ... nth byte of PHSF (LSB of PHSF value) = nth byte of PDU Downstream MSB of PHSF value = 13th byte of PDU 2nd MSB of PHSF value = 14th byte of PDU ... nth byte of PHSF (LSB of PHSF value) = (n+13)th byte of PDU
Type 26.7 Length n Value string of bytes suppressed

The length n MUST always be the same as the value for PHSS.
C.2.2.10.2 Payload Header Suppression Index (PHSI)

The Payload Header Suppression Index (PHSI) has a value between 1 and 255 which uniquely references the suppressed byte string. The Index is unique per Service Flow in the upstream direction and unique per CM in the downstream direction. The upstream and downstream PHSI values are independent of each other.
Type 26.8 Length 1 Value index value

C.2.2.10.3

Payload Header Suppression Mask (PHSM)

The value of this field is used to interpret the values in the Payload Header Suppression Field. It is used at both the sending and receiving entities on the link. The PHSM allows fields such as sequence numbers or checksums which vary in value to be excluded from suppression with the constant bytes around them suppressed.
Type 26.9 Length n Value bit 0: 0 = dont suppress first byte of the suppression field 1 = suppress first byte of the suppression field bit 1: 0 = dont suppress second byte of the suppression field 1 = suppress second byte of the suppression field bit x: 0 = dont suppress (x+1) byte of the suppression field 1 = suppress (x+1) byte of the suppression field

385

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The length n is ceiling(PHSS/8). Bit 0 is the MSB of the Value field. The value of each sequential bit in the PHSM is an attribute for the corresponding sequential byte in the PHSF. If the bit value is a 1 (and verification passes or is disabled), the sending entity MUST suppress the byte, and the receiving entity MUST restore the byte from its cached PHSF. If the bit value is a 0, the sending entity MUST NOT suppress the byte, and the receiving entity MUST restore the byte by using the next byte in the packet. If this TLV is not included, the default is to suppress all bytes.
C.2.2.10.4 Payload Header Suppression Size (PHSS)

The value of this field is the total number of bytes in the Payload Header Suppression Field (PHSF) for a Service Flow that uses Payload Header Suppression.
Type 26.10 Length 1 Value number of bytes in the suppression string

This TLV is used when a Service Flow is being created. For all packets that get classified and assigned to a Service Flow with Payload Header Suppression enabled, suppression MUST be performed over the specified number of bytes as indicated by the PHSS and according to the PHSM. If this TLV is included in a Service Flow definition with a value of 0 bytes, then Payload Header Suppression is disabled. A non-zero value indicates Payload Header Suppression is enabled. Until the PHSS value is known, the PHS rule is considered partially defined, and suppression will not be performed. A PHS rule becomes fully defined when both PHSS and PHSF are known.
C.2.2.10.5 Payload Header Suppression Verification (PHSV)

The value of this field indicates to the sending entity whether or not the packet header contents are to be verified prior to performing suppression. If PHSV is enabled, the sender MUST compare the bytes in the packet header with the bytes in the PHSF that are to be suppressed as indicated by the PHSM.
Type 26.11 Length 1 Value 0 = verify 1 = dont verify

If this TLV is not included, the default is to verify. Only the sender MUST verify suppressed bytes. If verification fails, the Payload Header MUST NOT be suppressed. (Refer to Section 10.4.3)
C.2.2.10.6 Vendor Specific PHS Parameters

This allows vendors to encode vendor-specific PHS parameters using the DOCSIS Extension Field. The Vendor ID MUST be the first TLV embedded inside Vendor Specific PHS Parameters. If the first TLV inside Vendor Specific PHS Parameters is not a Vendor ID, then the TLV MUST be discarded. (Refer to Annex C.1.1.17)1
Type 26.43 Length n Value

1.

Revised this paragraph per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

386

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

C.3 Encodings for Other Interfaces

C.3.1 Telephone Settings Option

This configuration setting describes parameters which are specific to telephone return systems. It is composed from a number of encapsulated type/length/value fields. See [DOCSIS6].
Type Length 15 (= TRI_CFG01) n Value

C.3.2 Baseline Privacy Configuration Settings Option

This configuration setting describes parameters which are specific to Baseline Privacy. It is composed from a number of encapsulated type/length/value fields. See [DOCSIS8].
Type 17 (= BP_CFG) Length n Value

C.4 Confirmation Code

The Confirmation Code (CC) provides a common way to indicate failures for Registration Response, Registration Ack, Dynamic Service Addition-Response, Dynamic Service Addition-Ack, Dynamic Service Delete-Response, Dynamic Service Change-Response, Dynamic Service Change-Ack and Dynamic Channel Change-Response MAC Management Messages. The confirmation codes in this section are used both as message Confirmation Codes and as Error Codes in Error Set Encodings which may be carried in these messages. Confirmation Code is one of the following: okay / success(0) reject-other(1) reject-unrecognized-configuration-setting(2) reject-temporary / reject-resource(3) reject-permanent / reject-admin(4) reject-not-owner(5) reject-service-flow-not-found(6) reject-service-flow-exists(7) reject-required-parameter-not-present(8) reject-header-suppression(9) reject-unknown-transaction-id(10) reject-authentication-failure (11) reject-add-aborted(12) reject-multiple-errors(13) reject-classifier-not-found(14) reject-classifier-exists(15) reject-PHS-rule-not-found(16) reject-PHS-rule-exists(17) reject-duplicate-reference-ID-or-index-in-message(18) reject-multiple-upstream-service-flows(19) reject-multiple-downstream-service-flows(20) reject-classifier-for-another-service-flow(21) reject-PHS-for-another-service-flow(22)

387

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

reject-parameter-invalid-for-context(23) reject-authorization-failure(24) reject-temporary-DCC(25) The Confirmation Codes MUST be used in the following way:

Okay or success(0) means the message was received and successful. Reject-other(1) is used when none of the other reason codes apply. Reject-unrecognized-configuration setting(2) is used when a configuration setting is not recognized or when
its value is outside of the specified range.

Reject-temporary(3), also known as reject-resource, indicates that the current loading of the CMTS or CM
prevents granting the request, but that the request might succeed at another time.

Reject-permanent(4), also known as reject-admin, indicates that, for policy, configuration, or capabilities reasons, the request would never be granted unless the CMTS or CM were manually reconfigured or replaced.

Reject-not-owner(5) the requester is not associated with this service flow. Reject-service-flow-not-found(6) the Service Flow indicated in the request does not exist. Reject-service-flow-exists(7) the Service Flow to be added already exists. Reject-required-parameter-not-present(8) a required parameter has been omitted. Reject-header-suppression(9) the requested header suppression cannot be supported for whatever reason. Reject-unknown-transaction-id(10) the requested transaction continuation is invalid because the receiving end-point does not view the transaction as being in process (i.e., the message is unexpected or out of order). invalid HMAC-digest, CMTS-MIC, provisioned IP address or timestamp.

Reject-authentication-failure(11) the requested transaction was rejected because the message contained an Reject-add-aborted(12) the addition of a dynamic service flow was aborted by the initiator of the Dynamic
Service Addition.

Reject-multiple-errors (13) is used when multiple errors have been detected. Reject-classifier-not-found (14) is used when the request contains an unrecognized classifier ID. Reject-classifier-exists (15) indicates that the ID of a classifier to be added already exists. Reject-PHS-rule-not-found (16) indicates that the request contains an SFID/classifier ID pair for which no PHS rule exists. for which a PHS rule already exists.

Reject-PHS-rule-exists (17) indicates that the request to add a PHS rule contains an SFID/classifier ID pair Reject-duplicate-reference-ID-or-index-in-message (18) indicates that the request used an SFR, classifier reference, SFID, or classifier ID twice in an illegal way.

Reject-multiple-upstream-service-flows (19) is used when DSA/DSC contains parameters for more than one
upstream flow.

Reject-multiple-downstream-service-flows (20) is used when DSA/DSC contains parameters for more than
one downstream flow.

Reject-classifier-for-another-service-flow (21) is used in DSA-RSP when the DSA-REQ includes classifier

parameters for a SF other than the new SF(s) being added by the DSA.

Reject-PHS-for-another-service-flow (22) is used in DSA-RSP when the DSA-REQ includes a PHS rule for a
SF other than the new SF(s) being added by the DSA.

Reject-parameter-invalid-for-context(23) indicates that the parameter supplied cannot be used in the encoding in which it was included, or that the value of a parameter is invalid for the encoding in which it was included. Reject-authorization-failure(24) the requested transaction was rejected by the authorization module.
388

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Reject-temporary-DCC(25) indicates that the requested resources are not available on the current channels at
this time, and the CM should re-request them on new channels after completing a channel change in response to a DCC command which the CMTS will send. If no DCC is received, the CM must wait for a time of at least T14 before re-requesting the resources on the current channels.
C.4.1 Confirmation Codes for Dynamic Channel Change

The CM may return in the DCC-RSP message an appropriate rejection code from C.4. It may also return one of the following Confirmation Codes which are unique to DCC-RSP. The Confirmation Codes MUST be used in the following way:

depart(180) indicates the CM is on the old channel and is about to perform the jump to the new channel. arrive(181) indicates the CM has performed the jump and has arrived at the new channel. reject-already-there(182) indicates that the CMTS has asked the CM to move to a channel that it is already
occupying.

reject-20-disable(183) indicates that the CMTS has asked a CM with 2.0 mode disabled to move to a Type 3
channel that it cannot use, and a UCD substitution was sent in the corresponding DCC-REQ.1
C.4.2 Confirmation Codes for Major Errors

These confirmation codes MUST be used only as message Confirmation Codes in REG-ACK, DSA-RSP, DSAACK, DSC-RSP, or DSC-ACK messages, or as the Response code in REG-RSP messages for 1.1 CMs. In general, the errors associated with these confirmation codes make it impossible either to generate an error set that can be uniquely associated with a parameter set in the REG-REQ, DSA-REQ, or DSC-REQ message, or to generate a full RSP message. reject-major-service-flow-error(200) reject-major-classifier-error(201) reject-major-PHS-rule-error(202) reject-multiple-major-errors(203) reject-message-syntax-error(204) reject-primary-service-flow-error(205) reject-message-too-big(206) reject-invalid-modem-capabilities(207) The Confirmation Codes MUST be used only in the following way:

Reject-major-service-flow-error(200) indicates that the REQ message did not have either a SFR or SFID in a
service flow encoding, and that service flow major errors were the only major errors.

Reject-major-classifier-error(201) indicates that the REQ message did not have a classifier reference, or did
not have both a classifier ID and a Service Flow ID, and that classifier major errors were the only major errors.

Reject-major-PHS-rule-error(202) indicates that the REQ message did not have a both a Service Flow Reference/Identifier and a Classifier Reference/Identifier, and that PHS rule major errors were the only major errors.

Reject-multiple-major-errors(203) indicates that the REQ message contained multiple major errors of types
200, 201, 202.

1.

Revised bulleted statement per ECN RFI2-N-02238 by GO on 02/26/03.

389

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Reject-message-syntax-error(204) indicates that the REQ message contained syntax error(s) (e.g., a TLV
length error) resulting in parsing failure.

Reject-primary-service-flow-error(205) indicates that a REG-REQ or REG-RSP message did not define a

required primary Service Flow, or a required primary Service Flow was not specified active.

Reject-message-too-big(206) is used when the length of the message needed to respond exceeds the maximum allowed message size.

Reject-invalid-modem-capabilities(207) indicates that the REG-REQ contained either that in invalid combination of modem capabilities or modem capabilities that are inconsistent with the services in the REG-REQ.

390

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex D CM Configuration Interface Specification

D.1 CM IP Addressing
D.1.1 DHCP Fields Used by the CM

The following fields MUST be present in the DHCP request from the CM and MUST be set as described below:

The hardware type (htype) MUST be set to 1 (Ethernet). The hardware length (hlen) MUST be set to 6. The client hardware address (chaddr) MUST be set to the 48 bit MAC address associated with the RF interface of the CM.

The client identifier option MUST be included, with the hardware type set to 1, and the value set to the
same 48 bit MAC address as the chaddr field.

Option code 60 (Vendor Class Identifier) to allow for the differentiation between DOCSIS 2.0 and DOCSIS 1.x CM requests, a compliant CM MUST send the following ASCII coded string in Option code 60, docsis2.0:xxxxxxx. Where xxxxxxx MUST be an ASCII representation of the hexadecimal encoding of the Modem Capabilities; refer to Annex C.1.3.1. For example, the ASCII encoding for the first two TLVs (concatenation and DOCSIS Version) of a DOCSIS 2.0 modem would be 05nn010101020102. Note that many more TLVs are required for a DOCSIS2.0 modem and the field nn will contain the length of all the TLVs. This example shows only two TLVs for simplicity.

The parameter request list option MUST be included. The option codes that MUST be included in the list
are:

Option code 1 (Subnet Mask) Option code 2 (Time Offset) Option code 3 (Router Option) Option code 4 (Time Server Option) Option code 7 (Log Server Option)

The following fields are expected in the DHCP response returned to the CM. Fields identified as critical MUST be present in the DHCP response, and fields identified as non critical SHOULD be present. The CM MUST configure itself with the critical fields from the DHCP response, and, if present, with the non-critical fields.

The IP address to be used by the CM (yiaddr) (critical) The IP address of the TFTP server for use in the next phase of the bootstrap process (siaddr) (critical) If the DHCP server is on a different network (requiring a relay agent), then the IP address of the relay agent
(giaddr). Note: this may differ from the IP address of the first hop router (non-critical)

The name of the CM configuration file to be read from the TFTP server by the CM (file) (critical) The subnet mask to be used by the CM (Subnet Mask, option 1) (non-critical) The time offset of the CM from Universal Coordinated Time (UTC) (Time Offset, option 2). This is used by
the CM to calculate the local time for use in time-stamping error logs. (non-critical)

A list of addresses of one or more routers to be used for forwarding CM-originated IP traffic (Router Option,
option 3). The CM is not required to use more than one router IP address for forwarding, but MUST use at least one. (non-critical)

A list of [RFC-868] time-servers from which the current time may be obtained (Time Server Option,
option 4) (non-critical)

391

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

A list of SYSLOG servers to which logging information may be sent (Log Server Option, option 7); see
[DOCSIS5] (non-critical) If a critical field is missing, or is invalid in the DHCP response during initialization, the CM MUST log an error and re initialize its MAC and continue channel scanning. If a non-critical field is missing or is invalid in the DHCP response during initialization, the CM MUST log a warning, ignore the field and go operational, with the following considerations:

If the subnet mask is missing or is invalid, the CM MUST use the default for the IP of Class A, B or C as
defined in [RFC-791].

If the time server is missing or is invalid, the CM MUST initialize the time for the events to Jan 1, 1970,
0h00. If the IP address field is missing or is invalid in the DHCP response during renew or rebind, the CM MUST log an error and re initialize its MAC and continue channel scanning. If any other critical or non-critical field is missing or is invalid in the DHCP response during renew or rebind, the CM MUST log a warning, ignore the field if it is invalid and stay operational.1 To assist the DHCP server in differentiating a CM discovery request from a CPE-side LAN discovery request, a CMTS MUST implement the following:

All CMTSes MUST support the DHCP relay agent information option [RFC-3046]. Specifically, the CMTS
MUST include the 48 bit MAC address of the RF side interface of the CM generating or bridging the DHCP discovery request in the agent remote ID sub-option field before relaying the discovery to a DHCP server.

If the CMTS is a router, it MUST use a giaddr field to differentiate between CM and CPE side station if they
are provisioned to be in different IP subnets. Bridging CMTSes SHOULD also provide this functionality.

D.2 CM Configuration
D.2.1 CM Binary Configuration File Format

The CM-specific configuration data MUST be contained in a file which is downloaded to the CM via TFTP. This is a binary file in the same format defined for DHCP vendor extension data [RFC-2132]. It MUST consist of a number of configuration settings (1 per parameter) each of the form Type Length Value Type is a single-octet identifier which defines the parameter. Length is a single octet containing the length of the value field in octets (not including type and length fields) Value is from one to 254 octets containing the specific value for the parameter The configuration settings MUST follow each other directly in the file, which is a stream of octets (no record markers).

1.

Revised sentence per ECN RFI2-N-02216, by GO, on 12/02/02.

392

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Configuration settings are divided into three types:

Standard configuration settings which MUST be present Standard configuration settings which MAY be present DOCSIS Extension Field configuration settings.1
CMs MUST be capable of processing all standard configuration settings. CMs MUST ignore any configuration setting present in the configuration file which it cannot interpret. To allow uniform management of CMs conformed to this specification, conformed CMs MUST support a 8192-byte configuration file at a minimum. Authentication of the provisioning information is provided by two message integrity check (MIC) configuration settings, CM MIC and CMTS MIC.

CM MIC is a digest which ensures that the data sent from the provisioning server were not modified en route.
This is NOT an authenticated digest (it does not include any shared secret).

CMTS MIC is a digest used to authenticate the provisioning server to the CMTS during registration. It is
taken over a number of fields one of which is a shared secret between the CMTS and the provisioning server. Use of the CM MIC allows the CMTS to authenticate the provisioning data without needing to receive the entire file. Thus the file structure is of the form shown in Figure D-1:

Configuration Configuration Setting 1 Setting 2

Configuration Setting n

CM MIC

CMTS MIC

Figure D-1

Binary Configuration File Format

D.2.2 Configuration File Settings

The following configuration settings MUST be included in the configuration file and MUST be supported by all CMs. The CM MUST NOT send a REG-REQ based on a configuration file that lacks these mandatory items.

Network Access Configuration Setting CM MIC Configuration Setting CMTS MIC Configuration Setting End Configuration Setting

DOCSIS 1.0 Class of Service Configuration Setting or Upstream Service Flow Configuration Setting

Downstream Service Flow Configuration Setting

Note: A DOCSIS 1.0 CM must be provided with a DOCSIS 1.0 Class of Service Configuration. A CM conformant with this specification should only be provisioned with DOCSIS 1.0 Class of Service Configuration information if it is to behave as a DOCSIS 1.0 CM; otherwise, it should be provisioned with Service Flow Configuration Settings

1.

Revised this bullet statement per ECN RFIv2.0-N-03.0125-5 by GO on 3/15/04.

393

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The following configuration settings MAY be included in the configuration file and if present MUST be supported by all CMs.

Downstream Frequency Configuration Setting Upstream Channel ID Configuration Setting Baseline Privacy Configuration Setting Software Upgrade Filename Configuration Setting Upstream Packet Classification Setting Downstream Packet Classification Setting SNMP Write-Access Control SNMP MIB Object Software Server IP Address CPE Ethernet MAC Address Maximum Number of CPEs Maximum Number of Classifiers Privacy Enable Configuration Setting Payload Header Suppression TFTP Server Timestamp TFTP Server Provisioned Modem Address Pad Configuration Setting SNMPv3 Notification Receiver Enable 2.0 Mode

Enable Test Modes1 Static Multicast MAC Address2

The following configuration setting MAY be included in the configuration file and if present, and applicable to this type of modem, MUST be supported.

Telephone Settings Option

The following configuration settings MAY be included in the configuration file and if present MAY be supported by a CM.

DOCSIS Extension Field Configuration Settings3

Note: There is a limit on the size of registration request and registration response frames (see Section 8.2.5.2). The configuration file should not be so large as to require the CM or CMTS to exceed that limit.

D.2.3 Configuration File Creation

The sequence of operations required to create the configuration file is as shown in Figure D-2 through Figure D5.
1. 2. 3.

Added this bullet statement to the list per ECN RFI2-N-02210, by GO, on 11/22/02. Added this bullet statement to the list per ECN RFIv2.0-N-04.0143-4, by GO, on 7/8/04. Revised this bullet statement per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

394

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

1. Create the type/length/value entries for all the parameters required by the CM.

type, length, value for parameter 1 type, length, value for parameter 2

type, length, value for parameter n

Figure D-2 Create TLV Entries for Parameters Required by the CM

2. Calculate the CM message integrity check (MIC) configuration setting as defined in Section D.2.3.1 and add to the file following the last parameter using code and length values defined for this field.

type, length, value for parameter 1 type, length, value for parameter 2

type, length, value for parameter n type, length, value for CM MIC

Figure D-3

Add CM MIC

3. Calculate the CMTS message integrity check (MIC) configuration setting as defined in Section D.3.1 and add to the file following the CM MIC using code and length values defined for this field.

type, length, value for parameter 1 type, length, value for parameter 2

type, length, value for parameter n type, length, value for CM MIC type, length, value for CMTS MIC

Figure D-4 Add CMTS MIC

4. Add the end of data marker.

395

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

type, length, value for parameter 1 type, length, value for parameter 2

type, length, value for parameter n type, length, value for CM MIC type, length, value for CMTS MIC end of data marker

Figure D-5 Add End of Data Marker

D.2.3.1

CM MIC Calculation

The CM message integrity check configuration setting MUST be calculated by performing an MD5 digest over the bytes of the configuration setting fields. It is calculated over the bytes of these settings as they appear in the TFTPed image, without regard to TLV ordering or contents. There are two exceptions to this disregard of the contents of the TFTPed image: 1. The bytes of the CM MIC TLV itself are omitted from the calculation. This includes the type, length, and value fields. 2. The bytes of the CMTS MIC TLV are omitted from the calculation. This includes the type, length, and value fields. On receipt of a configuration file, the CM MUST recompute the digest and compare it to the CM MIC configuration setting in the file. If the digests do not match then the configuration file MUST be discarded

D.3 Configuration Verification

It is necessary to verify that the CMs configuration file has come from a trusted source. Thus, the CMTS and the configuration server share an Authentication String that they use to verify portions of the CMs configuration in the Registration Request.
D.3.1 CMTS MIC Calculation

The CMTS message integrity check configuration setting MUST be calculated by performing an MD5 digest over the following configuration setting fields, when present in the configuration file, in the order shown:

Downstream Frequency Configuration Setting Upstream Channel ID Configuration Setting Network Access Configuration Setting DOCSIS 1.0 Class of Service Configuration Setting Baseline Privacy Configuration Setting

DOCSIS Extension Field Configuration Settings1

1.

Revised this bullet statement per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.

396

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

CM MIC Configuration Setting Maximum Number of CPEs TFTP Server Timestamp TFTP Server Provisioned Modem Address Upstream Packet Classification Setting Downstream Packet Classification Setting Upstream Service Flow Configuration Setting Downstream Service Flow Configuration Setting Maximum Number of Classifiers Privacy Enable Configuration Setting Payload Header Suppression Subscriber Management Control Subscriber Management CPE IP Table Subscriber Management Filter Groups Enable Test Modes

The bulleted list specifies the order of operations when calculating the CMTS MIC over configuration setting Type fields. The CMTS MUST calculate the CMTS MIC over TLVs of the same Type in the order they were received. Within Type fields, the CMTS MUST calculate the CMTS MIC over the Subtypes in the order they were received. To allow for correct CMTS MIC calculation by the CMTS, the CM MUST NOT reorder configuration file TLVs of the same Type or Subtypes within any given Type in its Registration-Request message. All configuration setting fields MUST be treated as if they were contiguous data when calculating the CM MIC. The digest MUST be added to the configuration file as its own configuration setting field using the CMTS MIC Configuration Setting encoding. The authentication string is a shared secret between the provisioning server (which creates the configuration files) and the CMTS. It allows the CMTS to authenticate the CM provisioning. The authentication string is to be used as the key for calculating the keyed CMTS MIC digest as stated in the following section D.3.1.1. The mechanism by which the shared secret is managed is up to the system operator. On receipt of a configuration file, the CM MUST forward the CMTS MIC as part of the registration request (REG-REQ). On receipt of a REG-REQ, the CMTS MUST recompute the digest over the included fields and the authentication string and compare it to the CMTS MIC configuration setting in the file. If the digests do not match, the registration request MUST be rejected by setting the authentication failure result in the registration response status field.
D.3.1.1 Digest Calculation

The CMTS MIC digest field MUST be calculated using HMAC-MD5 as defined in [RFC-2104].

397

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

398

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex E The Data-Over-Cable Spanning Tree Protocol

Section 5.1.2.1 requires the use of the spanning tree protocol on CMs that are intended for commercial use and on bridging CMTSes. This annex describes how the 802.1d spanning tree protocol is adapted to work for dataover-cable systems.

E.1

Background

A spanning tree protocol is frequently employed in a bridged network in order to deactivate redundant network connections; i.e., to reduce an arbitrary network mesh topology to an active topology that is a rooted tree that spans all of the network segments. The spanning tree algorithm and protocol should not be confused with the data-forwarding function itself; data forwarding may follow transparent learning bridge rules, or may employ any of several other mechanisms. By deactivating redundant connections, the spanning tree protocol eliminates topological loops, which would otherwise cause data packets to be forwarded forever for many kinds of forwarding devices. A standard spanning tree protocol [IEEE 802.1d] is employed in most bridged local area networks. This protocol was intended for private LAN use and requires some modification for cable data use.

E.2

Public Spanning Tree

To use a spanning tree protocol in a public-access network such as data-over-cable, several modifications are needed to the basic IEEE 802.1d process. Primarily, the public spanning tree must be isolated from any private spanning tree networks to which it is connected. This is to protect both the public cable network and any attached private networks. Figure E-1 illustrates the general topology.

Bridged Private Network Cable Modem CMTS Cable Modem Cable Modem

Bridged Private Network

Figure E-1

Spanning Tree Topology

399

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The task for the public spanning tree protocol, with reference to Figure E-1, is to:

Isolate the private bridged networks from each other. If the two private networks merge spanning trees then
each is subject to instabilities in the others network. Also, the combined tree may exceed the maximum allowable bridging diameter.

Isolate the public network from the private networks spanning trees. The public network must not be subject
to instabilities induced by customers networks; nor should it change the spanning tree characteristics of the customers networks.

Disable one of the two redundant links into the cable network, so as to prevent forwarding loops. This should
occur at the cable modem, rather than at an arbitrary bridge within the customers network. The spanning tree protocol must also serve the topology illustrated in Figure E-2:

Link-X

CMTS (bridge) Cable Modem

Switched/ Bridged Headend Network CMTS (bridge)

Bridged Private Network Cable Modem

Figure E-2

Spanning Tree Across CMTSes

In Figure E-2, in normal operation the spanning tree protocol should deactivate a link at one of the two cable modems. It should not divert traffic across the private network. Note that in some circumstances, such as deactivation of Link-X, spanning tree will divert traffic onto the private network (although limits on learned MAC addresses will probably throttle most transit traffic). If this diversion is undesirable, then it must be prevented by means external to spanning tree; for example, by using routers.

E.3

Public Spanning Tree Protocol Details

The Data over Cable Spanning Tree algorithm and protocol is identical to that defined in [IEEE 802.1d], with the following exceptions:

When transmitting Configuration Bridge Protocol Data Units (BPDUs), the Data over Cable Spanning Tree
Multicast Address 01-E0-2F-00-00-03 MUST be used rather than that defined in IEEE 802.1d. These BPDUs will be forwarded rather than recalculated by ordinary IEEE 802.1d bridges.

When transmitting Configuration BPDUs, the SNAP header AA-AA-03-00-E0-2F-73-74 MUST be used
rather than the LLC 42-42-03 header employed by 802.1d. This is to further differentiate these BPDUs from those used by IEEE 802.1d bridges, in the event that some of those bridges do not correctly identify multicast MAC addresses.1

1.

It is likely that there are a number of spanning tree bridges deployed which rely solely on the LSAPs to distinguish 802.1d packets. Such devices would not operate correctly if the data-over-cable BPDUs also used LSAP=0x42.

400

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

IEEE 802.1d BPDUs MUST be ignored and silently discarded. Topology Change Notification (TCN) PDUs MUST NOT be transmitted (or processed). TCNs are used in
IEEE networks to accelerate the aging of the learning database when the network topology may have changed. Since the learning mechanism within the cable network typically differs, this message is unnecessary and may result in unnecessary flooding.

CMTSes operating as bridges must participate in this protocol and must be assigned higher priorities (more
likely to be root) than cable modems. The NSI interface on the CMTS SHOULD be assigned a port cost equivalent to a link speed of at least 100 Mbps. These two conditions, taken together, should ensure that (1) a CMTS is the root, and (2) any other CMTS will use the head-end network rather than a customer network to reach the root.

The MAC Forwarder of the CMTS MUST forward BPDUs from upstream to downstream channels, whether
or not the CMTS is serving as a router or a bridge. Note that CMs with this protocol enabled will transmit BPDUs onto subscriber networks in order to identify other CMs on the same subscriber network. These public spanning tree BPDUs will be carried transparently over any bridged private subscriber network. Similarly, bridging CMTSes will transmit BPDUs on the NSI as well as on the RFI interface. The multicast address and SNAP header defined above are used on all links.

E.4

Spanning Tree Parameters and Defaults

Section 4.10.2 of [IEEE 802.1d] specifies a number of recommended parameter values. Those values should be used, with the exceptions listed below:
E.4.1 Path Cost

In [IEEE 802.1d], the following formula is used: Path_Cost = 1000 / Attached_LAN_speed_in_Mb/s For CMs, this formula is adapted as: Path_Cost = 1000 / (Upstream_modulation_rate * bits_per_symbol_for_long_data_grant) That is, the modulation type (QPSK or 16QAM) for the Long Data Grant IUC is multiplied by the raw modulation rate to determine the nominal path cost. Table E-1 provides the derived values.
Table E-1
Modulation Rate

CM Path Cost

Default Path Cost

kHz 160 320 640 1280 2560

QPSK 3125 1563 781 391 195

16QAM 1563 781 391 195 98

For CMTSes, this formula is: Path_Cost = 1000 / (Downstream_symbol_rate * bits_per_symbol)

401

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

E.4.2

Bridge Priority

The Bridge Priority for CMs SHOULD default to 36864 (0x9000). This is to bias the network so that the root will tend to be at the CMTS. The CMTS SHOULD default to 32768, as per 802.1d. Note that both of these recommendations affect only the default settings. These parameters, as well as others defined in 802.1d, SHOULD be manageable throughout their entire range through the Bridge MIB [RFC-1493], or other means.

402

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex F European Specification Additions1

This section applies to the second technology option referred to in Section 1 (Section 1.1, Scope). For the first option, refer to Sections 4, 6 and 7. This annex describes the physical layer specifications required for what are generally called Euro-DOCSIS cable-modems. This is an optional annex and in no way affects certification of North American, DOCSIS 1.x and DOCSIS 2.0 modems. The numbering of the paragraphs has been made so that the suffix after the F refers to the part of the specification which has changed. As a consequence some paragraphs are missing in this annex, because no change is required.

F.1 Scope and Purpose

No change required.

F.2 References
See Section 2.

F.3 Glossary
See Section 3.

F.4 Functional Assumptions

This section describes the characteristics of cable television plants to be assumed for the purpose of operating a data-over-cable-system. It is not a description of CMTS or CM parameters. The data-over-cable system MUST be interoperable with the environment described in this section.
F.4.1 Broadband access network

A coaxial-based broadband access network is assumed. This may take the form of either an all-coax or HybridFiber/Coax (HFC) network. The generic term cable network is used here to cover all cases. A cable network uses a shared-medium, tree-and-branch architecture with analogue transmission. The key functional characteristics assumed in this document are the following:

Two-way transmission. A maximum optical/electrical spacing between the CMTS and the most distant customer terminal of 160 km
(route meters).

A maximum differential optical/electrical spacing between the CMTS and the closest and most distant
modems of 160 km (route meters).

1.

Annex F rewritten per RFI2-N-02137 by RKV on 10/29/02.

403

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.4.2

Equipment Assumptions

F.4.2.1 Frequency plan

In the downstream direction, the cable system is assumed to have a passband with a typical lower edge between 47 and 87.5 MHz and an upper edge which is implementation-dependent but is typically in the range of 300 to 862 MHz. Within that passband, PAL/SECAM analogue television signals in 7/8 MHz channels, FM-radio signals, as well as other narrow band and wideband digital signals are assumed to be present. In the upstream direction, the cable system is assumed to have a passband with a lower edge at 5 MHz and an upper edge which is implementation-dependent but is typically in the range of 25 to 65 MHz.
F.4.2.2 Compatibility with Other Services

Refer to Section 4.2.2.

F.4.2.3 Fault Isolation Impact on Other Users

Refer to Section 4.2.3.

F.4.2.4 Cable System Terminal Devices

Compliance with EMC requirements is not covered by this specification. The protection requirements with respect to electromagnetic compatibility are contained in harmonized standards published in the Official Journal of the European Communities. Any reference in the present document to the transmission of television in the forward channel that is not consistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multiprogram TV distribution by cable in European applications. Requirements for safety are outside the scope of the present document. Safety standards for European applications are published by CENELEC.
Note: Note:

Examples of such CENELEC product safety standards are [EN 60950] and [EN 50083-1]. For CENELEC safety categories of interfaces, see [EG 201 212].

F.4.3

RF Channel Assumptions

Refer to Section 4.3.

F.4.3.1 Transmission Downstream

The RF channel transmission characteristics of the cable network in the downstream direction assumed for the purposes of minimal operating capability are described in Table F-1. This assumes nominal analogue video carrier level (peak envelope power) in a 7/8 MHz channel bandwidth. All conditions are present concurrently.

404

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table F-1

Assumed downstream RF channel transmission characteristics for analogue TV and sound signals
Parameter Value

Frequency range

Cable system normal downstream operating range is from 47 MHz to as high as 862 MHz. However the operating range for data communication is from 108 to 862 MHz. The use of frequencies between 108 and 136 MHz may be forbidden due to national regulation with regard to interference with aeronautical navigation frequencies. 7/8 MHz, 8 MHz channels are used for data communication
0.800 ms (typically much less)

RF channel spacing (design bandwidth) Transit delay from head-end to most distant customer Carrier-to-noise ratio in a 8 MHz band (analogue video level) Carrier-to-interference ratio for total power (discrete and broadband ingress signals) Composite triple beat distortion for analogue modulated carriers Composite second-order distortion for analogue modulated carriers Cross-modulation level Amplitude ripple Group delay ripple in the spectrum occupied by the CMTS Micro-reflections bound for dominant echo Carrier hum modulation Burst noise Seasonal and diurnal signal level variation Signal level slope, 85 - 862 MHz Maximum analogue video carrier level at the system outlet, inclusive of above signal level variation Lowest analogue video carrier level at the system outlet, inclusive of above signal level variation

Not less than 44 dB (Note 4) Not less than 52 dB within the design bandwidth Not greater than 57 dBc within the design bandwidth (Note 6 a) Not greater than 57 dBc within the design bandwidth (Note 6 b) Under consideration 2.5 dB in 8 MHz 100 ns over frequency range 0.5 4.43 MHz 10 dBc @ 0.5 s, 15 dBc @ 1.0 s 20 dBc @ 1.5 s, 30 dBc @ > 1.5 s Not greater than 46 dBc (0.5%) Not longer than 25 s at a 10 Hz average rate 8 dB Maximum slope of 12 dB in either the positive or negative direction 77 dBV (Note 6 c) 60 dBV (Note 6 d)

NOTE 1 Transmission is from the head-end combiner to the CM input at the customer location. NOTE 2 For measurements above, the normal downstream operating frequency band (except hum), impairments are referenced to the highest-frequency PAL/SECAM carrier level. NOTE 3 For hum measurements above, the normal downstream operating frequency band, a continuous-wave carrier is sent at the test frequency at the same level as the highest-frequency PAL/SECAM carrier. NOTE 4 This presumes that the average digital carrier is operated at analogue peak carrier level. When the digital carrier is operated below the analogue peak carrier level, this C/N may be less. NOTE 5 Measurements methods are defined in [EN 50083-7]. NOTE 6 For SECAM systems the following values apply a) Not greater than -52 dBc within the design bandwidth b) Not greater than -52 dBc within the design bandwidth c) 74 dBV d) 57 dBV

405

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.4.3.2 Transmission Upstream

The RF channel transmission characteristics of the cable network in the upstream direction assumed for the purposes of minimal operating capability are described in Table F-2. All conditions are present concurrently.
Table F-2 Assumed upstream RF channel transmission characteristics
Value

Parameter

Frequency range Transit delay from the most distant CM to the nearest CM or CMTS Carrier-to-noise ratio in active channel Carrier-to-ingress power (the sum of discrete and broadband ingress signals) ratio in active channel Carrier-to-interference (the sum of noise, distortion, common-path distortion and cross-modulation) ratio in active channel Carrier hum modulation Burst noise Amplitude ripple (maximum) Group delay ripple (maximum) Micro-reflections (maximum) Single echo

5 up to 65 MHz edge to edge

0.800 ms (typically much less)

Not less than 22 dB Not less than 22 dB (Note 2) Not less than 22 dB Not greater than 23 dBc (7.0%) Not longer than 10 s at a 1 kHz average rate for most cases (Notes 3 and 4) 5-65 MHz: 2.5 dB in 2 MHz 5-65 MHz: 300 ns in 2MHz 10 dBc @ 0.5 s 20 dBc @ 1.0 s 30 dBc @ > 1.0 s

Seasonal and diurnal signal level variation

Not greater than 12 dB min to max

NOTE 1 Transmission is from the CM output at the customer location to the head-end. NOTE 2 Ingress avoidance or tolerance techniques MAY be used to ensure operation in the presence of time-varying discrete ingress signals that could be as high as 0 dBc. NOTE 3 Amplitude and frequency characteristics sufficiently strong to partially or wholly mask the data carrier. NOTE 4 Impulse noise levels more prevalent at lower frequencies (<15 MHz).

F.4.3.2.1

Availability

Refer to Section 4.3.2.1.

F.4.4 Transmission Levels

The nominal average power level of the downstream CMTS QAM signal(s) within an 8 MHz channel is targeted to be in the range 13 dBc to 0 dBc relative to the analogue peak video carrier level and will normally not exceed the analogue peak video carrier level (typically between 10 to 6 dBc for 64QAM, and between 6 to 4 dBc for 256QAM). The nominal power level of the upstream CM signal(s) will be as low as possible to achieve the required margin above noise and interference. Uniform power loading per unit bandwidth is commonly followed in setting upstream signal levels, with specific levels established by the cable network operator to achieve the required carrier-to-noise and carrier-to-interference ratios.
F.4.5 Frequency Inversion

Refer to Section 4.5.

406

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

F.5 Communication Protocols

Refer to Section 5.

F.6 Physical Media Dependent Sublayer Specification

F.6.1 Scope

This section applies to the second technology option referred to in Section 1 (Section 1.1, Scope). In those cases where the requirement for both technology options are identical, a reference is provided to the main text. Whenever any reference in this section to spurious emissions conflicts with any legal requirement for the area of operation, the latter shall take precedence.
F.6.2 Upstream

F.6.2.1 Overview

Refer to Section 6.2.1.

F.6.2.2 Signal Processing Requirements

Refer to Section 6.2.2.

F.6.2.3 Modulation Formats

Refer to Section 6.2.3.

F.6.2.4 R-S Encode F.6.2.4.1 R-S Encode Modes

Refer to Section 6.2.4.1.

F.6.2.4.2 R-S Bit-to-Symbol Ordering

Refer to Section 6.2.4.2.

F.6.2.5 R-S Frame Structure

Refer to Section 6.2.5.

F.6.2.5.1 R-S Codeword Length

Refer to Section 6.2.5.1.

407

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.2.5.1.1

Burst Size

Refer to Section 6.2.5.1.1.

F.6.2.5.1.2 Fixed Codeword Length

Refer to Section 6.2.5.1.2.

F.6.2.5.1.3 Shortened Last Codeword

Refer to Section 6.2.5.1.3.

F.6.2.5.2 R-S FEC Disabled

Refer to Section 6.2.5.2.1

F.6.2.6 TDMA Byte Interleaver

Refer to Section 6.2.6.

F.6.2.6.1 Byte Interleaver Parameters

Refer to Section 6.2.6.1.

F.6.2.6.2 Interleaver Operating Modes

Refer to Section 6.2.6.2.

F.6.2.6.2.1 Fixed Mode

Refer to Section 6.2.6.2.1.

F.6.2.6.2.2 Dynamic Mode

Refer to Section 6.2.6.2.2.

F.6.2.6.2.2.1 Dynamic Mode Calculations

Refer to Section 6.2.6.2.2.1.

F.6.2.7 Scrambler (Randomizer)

Refer to Section 6.2.7.

1.

Added Burst Size and R-S FEC Disabled per ECN RFI2-N-02210, by GO, on 11/22/02.

408

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

F.6.2.8 TCM Encoder

Refer to Section 6.2.8.

F.6.2.8.1 TCM R-S Bytes to Symbol Mapping

Refer to Section 6.2.8.1.

F.6.2.9 Preamble Prepend

Refer to Section 6.2.9.

F.6.2.10 Modulation Rates

Refer to Section 6.2.10.

F.6.2.11 F.6.2.11.1 S-CDMA Framer and Interleaver S-CDMA Framing Considerations

Refer to Section 6.2.11.1.

F.6.2.11.2 Mini-slot Numbering

Refer to Section 6.2.11.2.

F.6.2.11.2.1 Mini-slot Numbering Parameters in UCD

Refer to Section 6.2.11.2.1.

F.6.2.11.2.2 Mini-slot Numbering Examples

Refer to Section 6.2.11.2.2.

F.6.2.11.3 Transmission Time

Refer to Section 6.2.11.3.

F.6.2.11.4 Latency Considerations

Refer to Section 6.2.11.4.

F.6.2.11.5 Spreader-off Bursts for Maintenance on S-CDMA channel

Refer to Section 6.2.11.5.

F.6.2.12 S-CDMA Framer

Refer to Section 6.2.12.

409

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.2.12.1

Subframe Definition

Refer to Section 6.2.12.1.

F.6.2.12.2 Framer Operation

Refer to Section 6.2.12.2.

F.6.2.12.2.1 Rules for Preamble and Coded TCM Symbols

Refer to Section 6.2.12.2.1.

F.6.2.12.2.2 Rules for Uncoded Symbols and the Uncoded TCM Subsymbols

Refer to Section 6.2.12.2.2.

F.6.2.12.2.3 Subframe Example

Refer to Section 6.2.12.2.3.

F.6.2.12.2.4 Frame Transmission

Refer to Section 6.2.12.2.4.

F.6.2.13 Symbol Mapping

Refer to Section 6.2.13.

F.6.2.14 S-CDMA Spreader

Refer to Section 6.2.14.

F.6.2.14.1 Code Hopping

Refer to Section 6.2.14.1.

F.6.2.15 Transmit Pre-Equalizer

Refer to Section 6.2.15.

F.6.2.16 Spectral Shaping

Refer to Section 6.2.16.

410

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

F.6.2.16.1

Upstream Frequency Agility and Range

The upstream PMD sublayer MUST support operation over the frequency range of 5-65 MHz edge to edge. Offset frequency resolution MUST be supported having a range of 32 kHz (increment = 1 Hz; implement within 10 Hz).
F.6.2.16.2 Spectrum Format

Refer to Section 6.2.16.2.

F.6.2.17 Relative Processing Delays

Refer to Section 6.2.17.

F.6.2.18 Transmit Power Requirements

The CM MUST support varying the amount of transmit power. Requirements are presented for 1) range of reported transmit power, 2) step size of power commands, 3) step size accuracy (actual change in output power compared to commanded change), and 4) absolute accuracy of CM output power. The protocol by which power adjustments are performed is defined in Section 11.2.4. Such adjustments by the CM MUST be within the ranges of tolerances described below. A CM MUST confirm that the transmit power limits are met after a RNG-RSP is received or after a UCD change. Transmit power is defined as the average RF power in the occupied bandwidth (channel width) transmitted in the data symbols of a burst, assuming equally likely QAM symbols, measured at the F-connector of the CM. Maximum and minimum transmit power level requirements refer to the CMs target transmit power level, defined as the CMs estimate of its actual transmit power. The actual transmitted power MUST be within 2 dB of the target power. The target transmit power MUST be variable over the range specified in Table F-5. Transmit power as reported by the CM in the MIB is referenced to the 64QAM constellation. When transmitting with other constellations, a slightly different transmit power will result, depending on the constellation gain in Table F-3 (see Section 6.2.13). As an example, if the reported power is 90 dBV, 64QAM will be transmitted with a target power of 90 dBV, while QPSK will be transmitted with 88.82 dBV.

Table F-3
Constellation Gain Gconst Relative to 64QAM (dB)

Constellation Gains and Power Limits

Pmax (dBV) TDMA Pmax (dBV) S-CDMA Pmin Gconst (dBV) Pmax Gconst (dBV) TDMA Pmax Gconst (dBV) S-CDMA

Pmin (dBV)

Constellation

QPSK 8QAM 16QAM 32QAM 64QAM 128QAM

-1.18 -0.21 -0.21 0.00 0.00 0.05

68 68 68 68 68 68

118 115 115 114 114 N/A

113 113 113 113 113 113

69.18 68.21 68.21 68.00 68.00 67.95

119.18 115.21 115.21 114.00 114.00 N/A

114.18 113.21 113.21 113.00 113.00 112.95

411

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.2.18.1 TDMA Transmit Power Calculations

In TDMA mode, the CM determines its target transmit power Pt as follows. Define: Pr = Reported power level (dBV) of CM in MIB (refers to 64QAM constellation) P = Power level adjustment (dB); for example, as commanded in ranging response message Gconst = Constellation gain (dB) relative to 64QAM constellation (see above table) Pmin = Minimum target transmit power permitted for the CM per Section 6.2.21.1 (see above table) Pmax = Maximum target transmit power permitted for the CM per Section 6.2.21.1 (see above table) Phi = min(Pmax - Gconst) over all burst profiles used by the CM (see above table) Plow = max(Pmin - Gconst) over all burst profiles used by the CM (see above table) Pt = Target transmit power level (dBV) of CM (actual transmitted power as estimated by CM) The CM updates its reported power by the following steps: //Add power level adjustment to reported power level (1) Pr = Pr + P (2) Pr = min[Pr, Phi] //Clip at max power limit (3) Pr = max[Pr, Plow] //Clip at min power limit The CM then transmits with target power Pt = Pr + Gconst, i.e., the reported power plus the constellation gain. Usually the reported power level is a relatively constant quantity, while the transmitted power level varies dynamically as different burst profiles, with different constellation gains, are transmitted. A CMs target transmit power MUST never be below Pmin or above Pmax. This implies that in some cases the extreme transmit power levels (e.g., 118 dBV for QPSK and 68 dBV) may not be permitted if burst profiles with multiple constellations are active. Also, if only QPSK is used, the reported power may be greater than 118 dBV, although the target transmit power will not exceed 118 dBV. For example, if only QPSK and 64QAM burst profiles are active, Phi = 114 dBV and Plow = 69.2 dBV. The maximum permitted QPSK transmitted power is 114 - 1.2 = 112.8 dBV, the minimum QPSK power is 69.2 - 1.2 = 68 dBV, the maximum 64QAM power is 114 dBV, and the minimum 64QAM power is 69.2 dBV.
F.6.2.18.2 S-CDMA Transmit Power Calculations

In S-CDMA mode, the CM determines its target transmit power Pt as follows. Define: Phi = min[Pmax - Gconst] over all burst profiles used by the CM (see above table) Plow = max[Pmin - Gconst] + 10 log(number_active_codes / number_of_codes_per_mini-slot) where the maximum is over all burst profiles used by the CM (see above table) The CM updates its reported power by the following steps: //Add power level adjustment to reported power level (1) Pr = Pr + P (2) Pr = min[Pr, Phi] //Clip at max power limit (3) Pr = max[Pr, Plow] //Clip at min power limit In a spreader-on frame, the CM then transmits each code i with target power Pt,i = Pr + Gconst,i - 10 log(number_active_codes) i.e., the reported power plus the constellation gain Gconst,i of that code, less a factor taking into account the number of active codes. The total transmit power Pt in a frame is the sum of the individual transmit powers Pt,i of each code, where the sum is performed using absolute power quantities (non-dB domain).
412

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

In a spreader-off frame, the CM target transmit power is Pt = Pr + Gconst. The transmitted power level varies dynamically as the number of allocated codes varies, and as different burst profiles, with different constellation gains, are transmitted. A CMs target transmit power MUST never be below Pmin or above Pmax, including over all numbers of allocated codes and all burst profiles. This implies that in some cases the extreme transmit power levels (e.g., 68 and 113 dBV) may not be permitted. Also if, for example, only QPSK is used, the reported power may be greater than 113 dBV, although the target transmit power will not exceed 113 dBV. If, for example, QPSK and 64QAM burst profiles are active, Phi = 113 dBV and Plow = 69.2 dBV. The maximum permitted QPSK transmitted power is 113 - 1.2 = 111.8 dBV when all active codes are transmitted, the minimum QPSK power is 69.2 - 1.2 = 68 dBV when one mini-slot is transmitted, the maximum 64QAM power is 113 dBV when all active codes are transmitted, and the minimum 64QAM power is 69.2 dBV with one mini-slot transmitted. The minimum QPSK power permitted while transmitting, for example, 2 minislots is 71 dBV, and the minimum 64QAM power permitted while transmitting 2 minislots is 72.2 dBV. The CM needs to implement some form of clipping on the transmitted waveform at the higher output powers in order to prevent peak to average ratio (PAR) issues. The power received at the CMTS in a spreader-on frame will sometimes be less than the nominal power of a spreader-off frame because of such factors as 1) broadcast opportunities not used by any CM, 2) unicast grants not used by one or more CMs, or 3) mini-slots assigned to the NULL SID.
F.6.2.18.3 Transmit Power Step Size

The step resolution in transmit power MUST be 1dB or less. When a CM is commanded with finer resolution than it can implement, it MUST round to the nearest supported step size. If the commanded step is half way between two supported step sizes, the CM MUST choose the smaller step. For example, with a supported step resolution of 1 dB, a command to step 0.5 dB would result in no step, while a command to step 0.75 dB would result in a 1 dB step. The step size accuracy MUST be within 0.4 dB. For example, the actual power increase resulting from a command to increase the power level by 1 dB in a CM's next transmitted burst MUST be between 0.6 dB and 1.4 dB. A relaxation in step size accuracy to 1.4 dB is allowed for one gain change when changing the power throughout the full power control range in either direction (from low-end to high-end power and vice versa). The locations of these two gain changes with relaxed accuracy MUST be at least 2 dB apart, thus enabling the use of large step attenuators in the coverage of the full power control range (hysteresis effect).
F.6.2.19 Burst Profiles

The transmission characteristics are separated into three portions: a) Channel Parameters, b) Burst Profile Attributes, and c) User Unique Parameters. The Channel Parameters include: 1) the modulation rate (six rates from 160 ksym/sec to 5.12 Msym/sec in octave steps); 2) the center frequency (Hz); 3) the 1536-bit Preamble Superstring, and iv) the S-CDMA channel parameters. The Channel Parameters are further described in Section 8.3.3 Table 8-18; these characteristics are shared by all users on a given channel. The Burst Profile Attributes are listed in Table F-4 and are further described in Section 8.3.3 Table 8-19; these parameters are the shared attributes corresponding to a burst type. The User Unique Parameters may vary for each user even when using the same burst type on the same channel as another user (for example, Power Level), and are listed in Table F-5. The CM MUST generate each burst at the appropriate time as conveyed in the mini-slot grants provided by the CMTS MAPs (Section 8.3.4).
413

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CM MUST support all burst profiles commanded by the CMTS via the Burst Descriptors in the UCD (Section 8.3.3), and subsequently assigned for transmission in a MAP (Section 8.3.4).
Table F-4
Burst Profile Attributes

Burst Profile Attributes

Configuration Settings

Modulation Differential Encoding TCM Encoding Preamble Length Preamble Value offset R-S FEC Error Correction (T)

QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM, 128 QAM(TCM Only) On/Off On/Off 0-1536 bits (Note Annex F.6.2.9) 0 to 1534 0 to 16 (0 implies no R-S FEC. The number of codeword parity bytes is 2*T) Fixed: 16 to 253 (assuming R-S FEC on) Shortened: 16 to 253 (assuming FEC on) 15 bits 0 to 255 4 to 255 modulation intervals 1 for S-CDMA channels

R-S FEC Codeword Information Bytes (k) Scrambler Seed Maximum Burst Length (mini-slots)1 Guard Time

Last Codeword Length Scrambler On/Off Interleaver Width (Nr) (RS Codeword Length, k+2*T) Byte Interleaver Depth (Ir)2

Fixed, shortened On/Off 18 to 255 0 - Dynamic Mode 1 - No Interleaving 2 to floor(2048/Nr)3 for Fixed Mode

Byte Interleaver Block Size (Br)

2*Nr to 2048

Interleaver Packet Size (Nf), (in bytes, including FEC) S-CDMA Spreader5 S-CDMA Codes per Subframe5 S-CDMA Interleaver Step5
1.

18 bytes
On/Off 1 to 128 1 to (spreading intervals per frame - 1)

A burst length of 0 mini-slots in the Channel Profile means that the burst length is variable on that channel for that burst type. The burst length, while not fixed, is granted explicitly by the CMTS to the CM in the MAP. If depth=1, no interleaving; if depth=0, dynamic mode. Nr is the R-S codeword size k+2T as defined in Annex F.6.2.6.1. Used only in dynamic mode Used only for S-CDMA channels.

2. 3. 4. 5.

414

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table F-5

User Unique Burst Parameters

Configuration Settings

User Unique Parameter

Power Level

TDMA: +68 to +114 dBV (32QAM, 64QAM) +68 to +115 dBV (8QAM, 16QAM) +68 to +118 dBV (QPSK) S-CDMA: +68 to +113 dBV (all modulations) 1-dB steps

Offset Frequency1 Ranging Offset

Range = 32 kHz; increment = 1 Hz; implement within 10 Hz Integer part: 0 to (216 - 1), increments of 6.25 sec/64 Fractional part: unsigned 8-bit fractional extension, units of 6.25 sec/(64*256) = 0.38146973 nsec

Burst Length (mini-slots) if variable on this channel (changes burst-to-burst) Transmit Equalizer Coefficients

1 to 255 mini-slots Up to 64 coefficients; 4 bytes per coefficient: 2 real, 2 imaginary

1.

The CM MUST implement the Offset Frequency to within 10 Hz.

F.6.2.19.1

Ranging Offset

Ranging Offset is the delay correction applied by the CM to the CMTS Upstream Frame Time derived at the CM. It is an advancement equal to roughly the round-trip delay of the CM from the CMTS, and is needed to synchronize upstream transmissions in the TDMA and S-CDMA schemes. The CMTS MUST provide feedback correction for this offset to the CM, based on reception of one or more successfully received bursts (i.e., satisfactory result from each technique employed: error correction and/or CRC), with resolution of 1/16384 of the frame tick increment (6.25 sec/(64*256) = 0.381469726 nsec). The CMTS sends adjustments to the CM, where a negative value implies the Ranging Offset is to be decreased, resulting in later times of transmission at the CM. For TDMA channels the CM MUST implement the correction with resolution of at most 1 symbol duration (of the symbol rate in use for a given burst), and (other than a fixed bias) with accuracy within 0.25 sec plus 1/2 symbol owing to resolution. As an example, for the maximum symbol rate of 5,120 ksps, the corresponding symbol period would be 195 ns, the corresponding maximum resolution for the timing correction MUST be 195 ns, and the corresponding minimum accuracy MUST be 348 ns. The accuracy of CM burst timing of 0.25 sec plus 1/2 symbol is relative to the mini-slot boundaries derivable at the CM based on an ideal processing of the timestamp signals received from the CMTS. For S-CDMA channels the CM MUST implement the ranging offset correction to within 0.01 of the nominal chip period. As an example, for the maximum chip rate of 5,120 kHz, the corresponding maximum resolution for the timing correction would be 195 ns * (0.01) or roughly 2ns.
F.6.2.19.2 TDMA Reconfiguration Times

Refer to Section 6.2.19.2.

415

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.2.19.3

S-CDMA Reconfiguration Times

Refer to Section 6.2.19.3.

F.6.2.19.4 CM Timing Offsets When Changing Modulation Rate

Refer to Section 6.2.19.4.1

F.6.2.20 Burst Timing Convention

Refer to Section 6.2.20.

F.6.2.21 Fidelity Requirements

The following requirements assume that any pre-equalization is disabled unless otherwise noted.
F.6.2.21.1 Spurious Emissions

The spurious emissions specifications are separated into two regions based on the transmit power. Region 1 is defined to have a power range of +74 dBV to (Pmax - 3), i.e., the central region. Region 2 is defined from +68 dBV to +74 dBV and (Pmax - 3) to Pmax, i.e., the low and high ends of the transmit power. Pmax depends on the modulation order, per Table F-5, as follows: for TDMA, +118 dBV for QPSK, +115 dBV for 8QAM/16QAM, +114 dBV for 32QAM/64QAM, and +113 dBV for all modulations of S-CDMA. For S-CDMA mode, when a modem is transmitting fewer than 4 spreading codes, the Region 2 specifications are used for all transmit power levels. Otherwise, for all other numbers of spreading codes (e.g., 4 to 128) or for TDMA mode, the spurious emissions specifications are used according to the power ranges defined for Regions 1 and 2 above. In addition, for S-CDMA, the spurious emission specifications for S-CDMA MUST be met for any number_allocated_codes, as defined in Annex F.6.2.19. The noise and spurious power MUST NOT exceed the levels given in Table F-6, Table F-7, and Table F-8. In Table F-6, in-band spurious includes noise, carrier leakage, clock lines, synthesizer spurious products, and other undesired transmitter products. It does not include ISI. The measurement bandwidth for Inband spurious is equal to the modulation rate (e.g., 160 to 5120 kHz). All requirements expressed in dBc are relative to the actual transmit power that the CM emits. The measurement bandwidth for the three (or fewer) Carrier-Related Frequency Bands (below 65 MHz) is 160 kHz, with up to three 160 kHz bands, each with no more than the value given in Table F-6, allowed to be excluded from the Bands within 5 to 65 MHz Transmitting Burst specs of Table F-8. Carrier-related spurious emissions include all products whose frequency is a function of the carrier frequency of the upstream transmission, such as but not limited to carrier harmonics. The measurement bandwidth is also 160 kHz for the Between Bursts specs of Table F-6 below 65 MHz.

1.

Section F.6.2.19.4 added per RFI2-N-02178 by RKV on 10/30/02.

416

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The Transmitting Burst specs apply during the mini-slots granted to the CM (when the CM uses all or a portion of the grant), and for 32 modulation intervals before and after the granted mini-slots. The Between Bursts specs apply except during a used grant of mini-slots, and the 32 modulation intervals before and after the used grant. In TDMA mode, a mini-slot may be as short as 32 modulation intervals, or 6.25 microseconds at the 5.12 Msym/ sec rate, or as short as 200 microseconds at the 160 ksym/sec rate.
Table F-6
Parameter

Spurious Emissions
Transmitting Burst Between Bursts

Inband. Adjacent Band 3 or Fewer Carrier-Related Frequency Bands (such as second harmonic, if < 65 MHz)

-40 dBc See Table F-7 Region 1: -50 dBc for transmitted modulation rate = 320 kHz and above; -47 dBc for transmitted modulation rate = 160 kHz Region 2: -47 dBc

The greater of -72 dBc or +1 dBV The greater of -72 dBc or +1 dBV The greater of -72 dBc or +1 dBV

Bands within 5 to 65 MHz (excluding assigned channel, adjacent channels, and carrier-related channels) CM Integrated Spurious Emissions Limits (all in 250 kHz, includes discretes) 87.5 to 108 MHz CM Integrated Spurious Emissions Limits (all in 4.75 MHz, includes discretes 1) 65 to 87.5 MHz

See Table F-8

The greater of -72 dBc or +1 dBV

30 dBV

1 dBV

max 40 dBc, 34 dBV

34 dBV

108 to 136 MHz 136 to 862 MHz CM Discrete Spurious Emissions Limits 1) 65 to 87.5 MHz 108 to 862 MHz 1. 2. 3. 4.

20 dBV 15 dBV

15 dBV max (15 dBV, 40 dB ref d/s 2)

max 50 dBc, 24 dBV 10 dBV

24 dBV 10 dBV

These spec limits exclude a single discrete spur related to the tuned received channel; this single discrete spur MUST NOT be greater than 20 dBV. dB ref d/s is relative to the received downstream signal level. Some spurious outputs are proportional to the receive signal level. The frequencies from 108 to 136 MHz may be forbidden due to national regulations. These specification limits exclude three or fewer discrete spurs. Such spurs must not be greater than 20 dBV.

F.6.2.21.1.1

Adjacent Channel Spurious Emissions

Spurious emissions from a transmitted carrier may occur in an adjacent channel which could be occupied by a carrier of the same or different modulation rate. The following table lists the required adjacent channel spurious emission levels for all combinations of transmitted carrier modulation rates and adjacent channel modulation rates. The measurement is performed in an adjacent channel interval that is of appropriate bandwidth and distance from the transmitted carrier based on the modulation rates of the transmitted carrier and the carrier in the adjacent channel.

417

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table F-7

Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level
Specification in the interval, Region 2

Transmitted carrier modulation rate

Specification in the interval, Region 1

Measurement interval and distance from carrier edge

Adjacent channel carrier modulation rate

-47 dBc -47 dBc All modulation rates -46 dBc -45 dBc -44 dBc -42 dBc

-45 dBc -45 dBc -45 dBc -44 dBc -41 dBc -38 dBc

20 kHz to 180 kHz 40 kHz to 360 kHz 80 kHz to 720 kHz 160 kHz to 1440 kHz 320 kHz to 2880 kHz 640 kHz to 5760 kHz

160 kSymb/s 320 kSymb/s 640 kSymb/s 1280 kSymb/s 2560 kSymb/s 5120 kSymb/s

F.6.2.21.1.2

Spurious Emissions in 5 to 65 MHz

Spurious emissions, other than those in an adjacent channel or carrier related emissions listed above, may occur in intervals (frequency bands) that could be occupied by other carriers of the same or different modulation rates. To accommodate these different modulation rates and associated bandwidths, the spurious emissions are measured in an interval equal to the bandwidth corresponding to the modulation rate of the carrier that could be transmitted in that interval. This interval is independent of the current transmitted modulation rate. The following table lists the possible modulation rates that could be transmitted in an interval, the required spurious level in that interval, and the initial measurement interval at which to start measuring the spurious emissions. Measurements should start at the initial distance and be repeated at increasing distance from the carrier until the upstream band edge, 5 MHz or 65 MHz, is reached. Measurement intervals should not include the three or fewer carrier related emission bands excluded above.
Table F-8 Spurious Emissions in 5 to 65 MHz Relative to the Transmitted Burst Power Level
Specification in the interval, Region 1 Specification in the interval, Region 2

Possible modulation rate in this interval

Initial measurement interval and distance from carrier edge

160 kSymb/s 320 kSymb/s 640 kSymb/s 1280 kSymb/s 2560 kSymb/s 5120 kSymb/s

-54 dBc -52 dBc -50 dBc -48 dBc -46 dBc -44 dBc

-53 dBc -50 dBc -47 dBc -44 dBc -41 dBc -38 dBc

220 kHz to 380 kHz 240 kHz to 560 kHz 280 kHz to 920 kHz 360 kHz to 1640 kHz 520 kHz to 3080 kHz 840 kHz to 5960 kHz

F.6.2.21.2

Spurious Emissions During Burst On/Off Transients

Each transmitter MUST control spurious emissions, prior to and during ramp up and during and following ramp down, before and after a burst. On/off spurious emissions, such as the change in voltage at the upstream transmitter output due to enabling or disabling transmission, MUST be no more than 100 mV, and such a step MUST be dissipated no faster than 2 s of constant slewing. This requirement applies when the CM is transmitting at +115 dBV or more; at backed-off transmit levels, the maximum change in voltage MUST decrease by a factor of 2 for each 6-dB decrease of power level from +115 dBV, down to a maximum change of 7 mV at +91 dBV and below. This requirement does not apply to CM power-on and power-off transients.

418

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

F.6.2.21.3

Modulation Error Ratio (MER)

MER measures the cluster variance caused by the transmit waveform at the output of the ideal receive matched filter. It includes the effects of ISI, spurious, phase noise, and all other transmitter degradations. For TDMA the matched filter is a square-root raised cosine filter with an alpha = 0.25. For S-CDMA, the matched filter is a square-root raised cosine filter with alpha = 0.25, convolved with the time-reversed spreading code sequence. MER includes the effects of ISI, spurious, phase noise, and all other transmitter degradations.
F.6.2.21.3.1 Definitions

Symbol MER: MERsymb is defined in Section 6.2.21.3.1, Definitions.

F.6.2.21.3.2 Requirements

Unless otherwise stated, the MER MUST meet or exceed the following limits over the full transmit power range of Table 6-8 for each modulation, each modulation rate, and over the full carrier frequency range, and for SCDMA, over any valid number of active and allocated codes. The 5-65 MHz carrier frequency range refers more precisely to [5 MHz + modulation rate * 1.25 / 2] to [65 MHz - modulation rate * 1.25 / 2]. At the break points between regions, the higher MER specification applies. Case 1: Flat Channel, transmit equalization OFF Case 1a: for modulation rates 2.56 MHz and below MERsymb 30 dB over 15 to 47 MHz carrier frequency MERsymb 27 dB over 10 MHz to 15 MHz and 47 MHz to 54 MHz carrier frequency MERsymb 23 dB over 5 MHz to 10 MHz and 54 MHz to 65 MHz carrier frequency Case 1b: for modulation rate 5.12 MHz MERsymb 27 dB over 15 to 47 MHz carrier frequency MERsymb 24 dB over 10 MHz to 15 MHz and 47 MHz to 54 MHz carrier frequency MERsymb 20 dB over 5 MHz to 10 MHz and 54 MHz to 65 MHz carrier frequency Case 2: Flat channel, transmit equalization ON Case 2a: for TDMA/QPSK, MERsymb 30 dB. Case 2b: for S-CDMA and all TDMA modulations except QPSK, MERsymb 35 dB. Case 2c: for S-CDMA, MERchip 33 dB. Case 3: Echo channel, transmit equalization ON Case 3a: In the presence of a single echo selected from the channel micro-reflections defined in Table 4-2, the measured MERsymb MUST be 33 dB for TDMA/QPSK, and 33 dB for S-CDMA and all TDMA modulations except QPSK. Case 3b: In the presence of two or three of the echoes defined in Table 4-2 (at most one of each specified magnitude and delay), the measured MERsymb MUST be 29 dB. Since the table does not bound echo delay for the -30 dBc case, for testing purposes it is assumed that the time span of the echo at this magnitude is less than or equal to 1.5 s.
419

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.2.21.4

Filter Distortion

Refer to Section 6.2.21.4.

F.6.2.21.4.1 Amplitude

Refer to Section 6.2.21.4.1.

F.6.2.21.4.2 Phase

Refer to Section 6.2.21.4.2.

F.6.2.21.5 Carrier Phase Noise

Refer to Section 6.2.21.5.

F.6.2.21.6 Channel Frequency Accuracy

Refer to Section 6.2.21.6.

F.6.2.21.7 Modulation Rate Accuracy

Refer to Section 6.2.21.7.

F.6.2.21.8 F.6.2.21.8.1 Modulation Timing Jitter Symbol Timing Jitter for Asynchronous Operation

Refer to Section 6.2.21.8.1.

F.6.2.21.8.2 Chip Timing Jitter for Synchronous Operation

All jitter specifications assume a downstream input to the CM per Annex F.6.3.5, Annex F.6.3.6, Annex F.6.3.7.2, Annex F.6.3.7.3, Annex F.6.3.9, and Annex F.6.3.10. For S-CDMA mode, upstream chip clock timing error (with the mean error subtracted out) relative to the CMTS master clock MUST be less than 0.005 RMS of the chip period over a 35-second measurement interval. This applies 1) to the worst-case jitter and frequency drift specified for the CMTS Master clock and the CMTS downstream symbol clock in the requirements above and 2) for any round-trip propagation delay up to the maximum allowed. The CM upstream chip clock SHOULD track the jitter components below 10 Hz in the input downstream symbol clock with an error transfer function below -25 dB. The CM upstream chip clock SHOULD attenuate the jitter components in the input downstream symbol clock above 200 Hz.
F.6.2.22 Upstream Demodulator Input Power Characteristics

The maximum total input power to the upstream demodulator MUST NOT exceed 95 dBV in the 5-65 MHz frequency range of operation.

420

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

The intended received power in each carrier MUST be within the values shown in Table F-9.
Table F-9 Maximum Range of Commanded Nominal Receive Power in Each Carrier
Modulation Rate (kSymb/s) Maximum Range (dBV)

160 320 640 1,280 2,560 5,120

+44 to +74 +47 to +77 +50 to +80 +53 to +83 +56 to +86 +59 to +89

The demodulator MUST operate within its defined performance specifications with received bursts within 6 dB of the nominal commanded received power.
F.6.2.23 Upstream Electrical Output from the CM

The CM MUST output an RF modulated signal with the characteristics delineated in Table F-10.
Table F-10
Parameter

Electrical Output from CM

Value

Frequency Level range (one channel)

5 to 65 MHz edge to edge TDMA: +68 to +114 dBV (32QAM, 64QAM) +68 to +115 dBV (8QAM, 16QAM) +68 to +118 dBV (QPSK) S-CDMA: +68 to +113 dBV (all modulations of S-CDMA)

Modulation Type Modulation Rate (nominal)

QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM TDMA: 160, 320, 640, 1280, 2560 and 5120 kSymb/s S-CDMA: 1280, 2560 and 5120 kSymb/s

Channel Bandwidth

TDMA: 200, 400, 800, 1600, 3200 and 6400 kHz S-CDMA: 1600, 3200 and 6400 kHz

Nominal Output impedance Output Return Loss Connector

75 ohms > 6 dB (5-65 MHz) F connector per [ISO-169-24] (common with the input)

F.6.3

Downstream

F.6.3.1 Downstream protocol

The downstream PMD sub layer MUST conform to [EN 300 429].
F.6.3.2 Interleaving

The downstream PMD sub layer MUST support the interleaver with the characteristics defined in Table F-11. This interleaver mode fully complies with [EN 300 429].

421

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table F-11
I (Number of taps) J (Increment)

Interleaver characteristics
Burst protection 64QAM/256QAM Latency 64QAM/256QAM

12

17

18 s/14 s

0.43 ms/0.32 ms

F.6.3.3 Downstream frequency plan

The downstream frequency plan will include all center frequencies between 112 and 858 MHz on 250 kHz increments. It is up to the operator to decide which frequencies to use to meet national and network requirements.
F.6.3.4 CMTS output electrical

The CMTS MUST output an RF modulated signal with the following characteristics defined in Table F-12.

422

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table F-12
Parameter

CMTS output
Value

Center Frequency (fc) Level Modulation type Symbol rate (nominal) 64QAM 256QAM Nominal channel spacing Frequency response 64QAM 256QAM Total discrete spurious In-band (fc 4 MHz) In-band spurious and noise (fc 4 MHz)

112 to 858 MHz 30 kHz Adjustable over the range 110 to 121 dBV 64QAM and 256QAM

6.952 Msym/s 6.952 Msym/s 8 MHz

0.15 square root raised cosine shaping 0.15 square root raised cosine shaping < 57 dBc < 46.7 dBc; where channel spurious and noise includes all discrete spurious, noise, carrier leakage, clock lines, synthesizer products, and other undesired transmitter products. Noise within 50 kHz of the carrier is excluded. < 58 dBc in 750 kHz. < 60.6 dBc in 7.25 MHz, excluding up to 3 spurs, each of which must be < 60 dBc when each is measured with 10 kHz bandwidth.

Adjacent channel (fc 4.0 MHz) to (fc 4.75 MHz) Adjacent channel (fc 4.75 MHz) to (fc 12 MHz) Next adjacent channel (fc 12 MHz) to (fc 20 MHz) Other channels (80 MHz to 1000 MHz)

Less than the greater of 63.7 dBc or 49.3 dBV in 8 MHz, excluding up to three discrete spurs. The total power in the spurs must be < 60 dBc when each is measured with 10 kHz bandwidth.
< 49.3 dBV in each 8 MHz channel, excluding up to three discrete spurs. The total power in the spurs must be < 60 dBc when each is measured with 10 kHz bandwidth.

Phase noise

1 kHz-10 kHz: 33 dBc double sided noise power 10 kHz-50 kHz: 51 dBc double sided noise power 50 kHz-3 MHz: 51 dBc double sided noise power

Output impedance Output return loss Connector

75 ohms
> 14 dB within an output channel up to 750 MHz; > 13 dB in an output channel above 750 MHz

F connector per [ISO-169-24]

F.6.3.5 Downstream electrical input to CM

The CM MUST accept an RF modulated signal with the following characteristics (see Table F-13).

423

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Table F-13
Parameter

Electrical input to CM
Value

Center Frequency Level Range (one channel)

112 to 858 MHz 30 kHz 43 to 73 dBV for 64QAM 47 to 77 dBV for 256QAM

Modulation Type Symbol Rate (nominal) Bandwidth Total Input Power (80-862 MHz) Input (load) Impedance Input Return Loss Connector

64QAM and 256QAM 6.952 Msym/s (64QAM) and 6.952 Msym/s (256QAM) 8 MHz (alpha = 0.15 square root raised cosine shaping for 64QAM and alpha = 0.15 square root raised cosine shaping for 256QAM)
< 90 dBV

75 ohms
> 6 dB (85 to 862 MHz)

F connector per [ISO-169-24] (common with the output)

F.6.3.6 CM BER performance

The bit-error-rate performance of a CM MUST be as described in this section. The requirements apply to the I = 12, J = 17 mode of interleaving.
F.6.3.6.1 F.6.3.6.1.1 64QAM 64QAM CM BER Performance

Implementation loss of the CM MUST be such that the CM achieves a post-FEC BER less than or equal to 10-8 when operating at a carrier to noise ratio (Es/No) of 25.5 dB or greater.
F.6.3.6.1.2 64QAM image rejection performance

Performance as described in Annex F.6.3.6.1.1 MUST be met with analogue or digital signal at +10 dBc in any portion of the RF band other than the adjacent channels.
F.6.3.6.1.3 64QAM Adjacent channel performance

Performance as described in Annex F.6.3.6.1.1 MUST be met with digital signal at 0 dBc in the adjacent channels. Performance as described in Annex F.6.3.6.1.1 MUST be met with analogue signal at +10 dBc in the adjacent channels. Performance as described in Annex F.6.3.6.1.1, with an additional 0.2-dB allowance, MUST be met with digital signal at +10 dBc in the adjacent channels.

424

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

F.6.3.6.2 F.6.3.6.2.1

256QAM 256QAM CM BER Performance

Implementation loss of the CM MUST be that the CM achieves a post-FEC BER less than or equal to 10-8 when operating at a carrier to noise ratio (Es/No) as shown in Table F-14.
Table F-14
Input receive signal level

256QAM CM BER performance

Es/No

47 dBV to 54 dBV > 54 to +77 dBV

34.5 dB 31.5 dB

F.6.3.6.2.2

256QAM image rejection performance

Performance as described in Annex F.6.3.6.2.1 MUST be met with analogue or digital signal at +10 dBc in any portion of the RF band other than the adjacent channels.
F.6.3.6.2.3 256QAM adjacent channel performance

Performance as described in Annex F.6.3.6.2.1 MUST be met with analogue or digital signal at 0 dBc in the adjacent channels. Performance as described in Annex F.6.3.6.2.1, with an additional 0.5-dB allowance, MUST be met with analogue signal at +10 dBc in the adjacent channels. Performance as described in Annex F.6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with digital signal at +10 dBc in the adjacent channels.
F.6.3.6.2.4 Additional specifications for QAM

The following additional specifications are given for the QAM-modulation.

Table F-15 QAM Modulation
Parameter Specification

I/Q Phase offset I/Q crosstalk I/Q Amplitude imbalance I/Q timing skew

< 1.0 -50 dB 0.05 dB max < 3.0 nsec

F.6.3.7 CMTS timestamp jitter

Refer to Section 6.3.7.

F.6.3.7.1 CMTS Master Clock Jitter for Asynchronous Operation

Refer to Section 6.3.7.1.

425

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.6.3.7.2

CMTS Master Clock Jitter for Synchronous Operation

Refer to Section 6.3.7.2.

F.6.3.7.3 CMTS Master Clock Frequency Drift for Synchronous Operation

Refer to Section 6.3.7.3.

F.6.3.8 CMTS Clock Generation

The CMTS has the following three options related to the synchronization of the CMTS Master Clock and the Downstream Symbol Clock: 1. Not locked. 2. Downstream Symbol Clock locked to CMTS Master Clock. 3. CMTS Master Clock locked to Downstream Symbol Clock. For S-CDMA operation the Master Clock and the Downstream Symbol Clock MUST be locked using either option 2 or 3. Let fb' represent the rate of the Downstream Symbol Clock which is locked to the CMTS Master Clock and let fm' represent the rate of the CMTS Master Clock locked to the Downstream Symbol Clock. Let fb represent the nominal specified downstream symbol rate and let fm represent the nominal CMTS Master Clock rate (10.24 MHz). With the Downstream Symbol Clock locked to the CMTS Master Clock the following equation MUST hold: fb' = fm*M/N With the CMTS Master Clock locked to the Downstream Symbol Clock the following equation MUST hold: fm' = fb*N/M M and N MUST be unsigned integer values each representable in 16 bits. (These are specified in the channel TLV parameters of the UCD). When the Downstream Symbol Clock and the CMTS Master Clock are not locked together (Sync mode = 0), the values of M and N are not valid and are ignored by the CM. The values of M and N MUST result in a value of fb' or fm' which is not more than 1 ppm from its specified nominal value. Table F-16 lists the downstream modes of operation, their associated nominal symbol rates, fb, example values for M and N, the resulting synchronized clock rates, and their offsets from their nominal values.

426

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table F-16

Downstream symbol rates and example parameters for synchronization with the CMTS Master Clock
Nominal Specified Symbol Rate, fb (MHz)

Downstream mode

M/N

CMTS Master Clock Rate, fm' (MHz)

Downstream Symbol Rate, fb' (MHz)

Offset from Nominal

Annex A, 64QAM and 256QAM (8 MHz)

6.952

869/1280

10.24

6.952

0 ppm

F.6.3.9 Downstream Symbol Clock Jitter for Synchronous Operation

The downstream symbol clock MUST meet the following double sideband phase noise requirements over the following frequency ranges: < [-50 + 20*log(fDS/6.952)] dBc (i.e., < 0.07 nsec RMS) < [-50 + 20*log(fDS/6.952)] dBc (i.e., < 0.07 nsec RMS) < [-50 + 20*log(fDS/6.952)] dBc (i.e., < 0.07 nsec RMS) < [-33 + 20*log(fDS/6.952)] dBc (i.e., < 0.5 nsec RMS) < [-27 + 20*log(fDS/6.952)] dBc (i.e., < 1 nsec RMS) 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 10 kHz 10 kHz to 100 kHz 100 kHz to (fDS /2)

where fDS is the frequency of the measured clock in MHz. The value of fDS MUST be an integral multiple or divisor of the downstream symbol clock. For example, an fDS = 27.808 MHz clock may be measured if there is no explicit 6.952 MHz clock available. The CMTS MUST provide a test mode in which:

The downstream QAM symbol sequence is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1,...)
at nominal amplitude, on both I and Q.

The CMTS generates the downstream symbol clock from the 10.24 MHz reference clock as in normal
synchronous operation. If an explicit downstream symbol clock which is capable of meeting the above phase noise requirements is available (e.g., a smooth clock without clock domain jitter), this test mode is not required.
F.6.3.10 Downstream Symbol Clock Drift for Synchronous Operation

Refer to Section 6.3.10.

F.7 Downstream transmission convergence sublayer

F.7.1 Introduction

Refer to Section 7.1.

427

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

F.7.2

MPEG Packet format

Refer to Section 7.2.

F.7.3 MPEG Header for Euro-DOCSIS Data-Over-Cable

The format of the MPEG Transport Stream Header is defined in section 2.4 of [ITU-T H.222.0]. The particular field values that distinguish Data-Over-Cable MAC streams are defined in Table F-17. Field names are from the ITU specification. The MPEG Header consists of 4 bytes that begin the 188-byte MPEG Packet. The format of the header for use on an Euro-DOCSIS Data-Over-Cable PID is restricted to that shown in Table F-17. The header format conforms to the MPEG standard, but its use is restricted in this specification to NOT ALLOW inclusion of an adaptation_field in the MPEG packets.
Table F-17
Field

MPEG Header format for Euro-DOCSIS Data-Over-Cable packets

Length (bits) Description

sync_byte transport_error_indicator

8 1

0x47; MPEG Packet Sync byte. Indicates an error has occurred in the reception of the packet. This bit is reset to zero by the sender, and set to one whenever an error occurs in transmission of the packet. A value of one indicates the presence of a pointer_field as the first byte of the payload (fifth byte of the packet) Reserved; set to zero. Euro-DOCSIS Data-Over-Cable well-known PID (0x1FFE) Reserved; set to 00. 01; use of the adaptation_field is NOT ALLOWED on the Euro-DOCSIS PID. Cyclic counter within this PID

payload_unit_start_indicator transport_priority PID (see Note) transport_scrambling_control adaptation_field_control continuity_counter

1 1 13 2 2 4

F.7.4

MPEG Payload for Euro-DOCSIS Data-Over-Cable

The MPEG Payload portion of the MPEG Packet will carry the Euro-DOCSIS MAC frames. The first byte of the MPEG payload will be a pointer_field if the payload_unit_start_indicator (PUSI) of the MPEG Header is set.
stuff_byte This standard defines a stuff_byte pattern having a value (0xFF) that is used within the EuroDOCSIS Payload to fill any gaps between the Euro-DOCSIS MAC frames. This value is chosen as an unused value for the first byte of the Euro-DOCSIS MAC frame. The FC byte of the MAC Header will be defined to never contain this value. (FC_TYPE = 11 indicates a MAC-specific frame, and FC_PARM = 11111 is not currently used and, according to this specification, is defined as an illegal value for FC_PARM.) pointer_field The pointer_field is present as the fifth byte of the MPEG packet (first byte following the MPEG header) whenever the PUSI is set to one in the MPEG header. The interpretation of the pointer_field is as follows:

The pointer_field contains the number of bytes in this packet that immediately follow the pointer_field that the CM decoder must skip past before looking for the beginning of an Euro-DOCSIS MAC Frame. A pointer field MUST be present if it is possible to begin a Data-Over-Cable MAC Frame in the packet, and MUST point to either:

428

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

1. the beginning of the first MAC frame to start in the packet; or 2. any stuff_byte preceding the MAC frame.
F.7.5 Interaction with the MAC sublayer

Refer to Section 7.5.

F.7.6 Interaction with the Physical layer

The MPEG-2 packet stream MUST be encoded according to [EN 300 429].
F.7.7 MPEG Header synchronization and recovery

The MPEG-2 packet stream SHOULD be declared in frame (i.e., correct packet alignment has been achieved) when five consecutive correct sync bytes, each 188 bytes from the previous one, have been received. The MPEG-2 packet stream SHOULD be declared out of frame, and a search for correct packet alignment started, when nine consecutive incorrect sync bytes are received. The format of MAC frames is described in detail in Section 8.

F.8 Media Access Control Specification

F.8.1 Introduction

Refer to Section 8.1.

F.8.2 MAC Frame Formats

Refer to Section 8.2.

F.8.3 MAC Management Messages

F.8.3.1 MAC Management Message Header

Refer to Section 8.3.1.

F.8.3.2 Time Synchronization (SYNC)

Time Synchronization (SYNC) MUST be transmitted by CMTS at a periodic interval to establish MAC sub layer timing. The message MUST use an FC field with FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header. This MUST be followed by a Frame PDU in the format shown in Figure F-1.

429

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Figure F-1 Format of Packet PDU Following the Timing Header

The parameters shall be as defined below:

CMTS Timestamp The count state of an incrementing 32 bit binary counter clocked with the CMTS 10.24 MHz master clock.

The CMTS timestamp represents the count state at the instant that the first byte (or a fixed time offset from the first byte) of the Time Synchronization MAC Management Message is transferred from the Downstream Transmission Convergence Sublayer to the Downstream Physical Media Dependent Sublayer as described in Section 6.3.7. A CMTS MUST always put the SYNC-message at the start of an MPEG-packet. This is required for compatibility with certain CM implementations.

430

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex G DOCSIS 2.0 and 1.0/1.1 Interoperability

DOCSIS 2.0 is the third generation of the DOCSIS specification. The terms DOCSIS 2.0, DOCSIS 1.1, and DOCSIS 1.0 refer to these three different specifications. The DOCSIS 2.0 specification primarily aims at enhancing the limited upstream physical layer performance of a DOCSIS 1.0- or 1.1-based cable access system. Two new MAC Management Message Types have been defined, and several new parameter encodings have been defined in the existing MAC messages. A DOCSIS 2.0 CMTS is capable of supporting a higher upstream throughput for a given channel bandwidth as well as increased tolerance to noise experienced in the upstream. As well as supporting DOCSIS 2.0 capable CMs, the DOCSIS 2.0 CMTS must be backwards compatible with DOCSIS 1.0 and DOCSIS 1.1 CMs. Furthermore, it is necessary for a DOCSIS 2.0 CM to function like a 1.0 CM when interoperating with a 1.0 CMTS and to function like a 1.1 CM when interoperating with a 1.1 CMTS. This section describes the interoperability issues and trade-offs involved when the operator wishes to support DOCSIS 1.0 and/or DOCSIS 1.1 CMs as well as DOCSIS 2.0 CMs on the same cable access channel.

G.1

General Interoperability Issues

This section addresses the general DOCSIS 1.x/2.0 interoperability issues that do not depend on the modulation type used for the upstream channel.
G.1.1 Provisioning

The parameters of the TFTP configuration file for a DOCSIS 2.0 CM are (except for the addition of one optional TLV) identical to those for a DOCSIS 1.1 CM, and are a superset of those for a DOCSIS 1.0 CM. Configurationfile editors that support DOCSIS 1.1 may need to be modified to support the new TLV defined in DOCSIS 2.0. A TFTP configuration file containing Class of Service TLVs is considered a DOCSIS 1.0 style configuration file. A TFTP configuration file containing Service Flow TLVs is considered a DOCSIS 1.1/2.0 style configuration file. A TFTP configuration file containing both Class of Service and Service Flow TLVs will be rejected by the CMTS (see Section 11.2.9). If a DOCSIS 2.0 CM is provisioned with a DOCSIS 1.0-style TFTP configuration file, it will register as specified in Annex G.1.2, although in the REG-REQ it MUST still specify DOCSIS 2.0 in the DOCSIS Version Modem Capability and MAY specify additional advanced (i.e., DOCSIS 1.1) Modem Capabilities that it supports. Thus, a DOCSIS 2.0 CM can be provisioned to work seamlessly on either a DOCSIS 1.0, a DOCSIS 1.1, or a DOCSIS 2.0 network. However, a DOCSIS 2.0 modem on a DOCSIS 1.x network would be clearly unable to support any DOCSIS 2.0-specific features. A DOCSIS 2.0 CM operating on an S-CDMA channel with the Maximum Scheduled Codes feature enabled (see Section 8.3.3), and provisioned with a DOCSIS 1.0-style configuration file, SHOULD support fragmentation and indicate that support in the Modem Capabilities Encoding in the REG-REQ message. If a DOCSIS 2.0 CM supports certain advanced capabilities when registered as a DOCSIS 1.0 CM (as indicated by the Modem Capabilities Encoding), those features MUST function according to the requirements defined in the DOCSIS 2.0 specifications.1

1.

Revised this paragraph per ECN RFIv2.0-N-04.0167-2 by GO on 10/18/04.

431

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

On the other hand, DOCSIS 1.0 CMs do not recognize (and ignore) many of the new TLVs in a DOCSIS 1.1/2.0 style config file, and will be unable to register successfully if provisioned with a DOCSIS 1.1/2.0 configuration file. To prevent any functionality mismatches, a DOCSIS 2.0 CMTS MUST reject any Registration Request with DOCSIS 1.1/2.0-specific configuration parameters that are not supported by the associated Modem Capabilities encoding in the REG-REQ (see Annex C.1.3.1).
G.1.2 Registration

A DOCSIS 2.0 CMTS is designed to handle the registration TLVs from DOCSIS 1.0 CMs as well as the TLVs from DOCSIS 1.1 (TLV types 22 to 38) or DOCSIS 2.0 (TLV types 22 to 39) CMs. Furthermore a DOCSIS 2.0 CM can handle any TLVs in a configuration file usable by a DOCSIS 1.0 CM. There is a slight difference in the registration-related messaging procedure when the DOCSIS 2.0 CMTS is responding to a DOCSIS 1.1 or 2.0 CM as opposed to a DOCSIS 1.0 CM (or a DOCSIS 1.1 CM using a 1.0-style configuration file). There is a further difference in the way a DOCSIS 2.0 CMTS handles registration from a DOCSIS 2.0 CM using a 1.0-style configuration file depending on whether the upstream on which the registration is occurring has DOCSIS 2.0 features. A DOCSIS 1.1 or 2.0 CM could be configured to use the Service Class Name which is statically defined at the CMTS instead of explicitly asking for the service class parameters. When the DOCSIS 2.0 CMTS receives such a Registration-Request, it encodes the actual parameters of that service class in the Registration-Response and expects the Registration-Acknowledge MAC message from the CM. If the detailed capabilities in the Registration-Response message exceed those the CM is capable of supporting, the CM is required to indicate this to the CMTS in its Registration-Acknowledge. When a DOCSIS 1.0 CM (or a 1.1 CM using a 1.0-style configuration file) registers with the same CMTS, the absence of Service Class Names eliminates the need for the DOCSIS 2.0 CMTS to explicitly specify the service class parameters in the Registration-Response using DOCSIS 1.1 or 2.0 TLVs. The Registration-Request from a DOCSIS 1.0 CM explicitly requests all non-default service class parameters in the Registration-Request per its provisioning information. When a DOCSIS 2.0 CMTS receives a Registration-Request containing DOCSIS 1.0 Class of Service Encodings, it will respond with the DOCSIS 1.0-style Registration-Response and, if the CM is a DOCSIS 1.x CM, not expect the CM to send the Registration-Acknowledge MAC message. A DOCSIS 1.0 CM can be further identified by the absence of the DOCSIS Version Modem Capabilities encoding in the Registration-Request. In the case where a DOCSIS 2.0 CM is using a DOCSIS 1.0-style configuration file there is an additional consideration. This is because in the case where the upstream is a type 2 upstream (see Section 11.2.2) and therefore supports both TDMA and A-TDMA features the Registration-Acknowledge message is also used to synchronize switching from TDMA (DOCSIS 1.x) operation to A-TDMA (DOCSIS 2.0) operation. It is important that this switch be coordinated correctly between the CM and the CMTS in order for the CMTS to be able to correctly interpret bandwidth requests from the CM (see Section 11.2.9). Therefore, when a DOCSIS 2.0 CM registers using a 1.0-style configuration file on a type 2 or type 3 upstream, it transmits a RegistrationAcknowledgment with a confirmation code of OK/SUCCESS (since 1.0-style registration does not allow for the CM to reject the Registration-Response). The CMTS knows to expect this because the modem capabilities field in the Registration-Request indicated that the CM was a 2.0 CM. The following table summarizes registration behavior for all cases involving a DOCSIS 2.0 CM.

432

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Table G-1 Registration Behavior for a DOCSIS 2.0 CM

DOCSIS 2.0 CMTS with a type 1 upstream or a DOCSIS 1.1 CMTS DOCSIS 2.0 CMTS with a type 2 or type 3 upstream

Configuration file

DOCSIS 1.0 CMTS

1.1/2.0-style configuration file that does not disable DOCSIS 2.0 mode

N/A

CM sends 1.1/2.0-style REG-REQ. CMTS sends 1.1/2.0-style REG-RESP and CM responds with REG-ACK. CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESp. CM MUST NOT send REG-ACK.

CM sends 1.1/2.0-style REG-REQ. CMTS sends 1.1/2.0-style REG-RESP and CM responds with REG-ACK. CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESP. CM MUST send REG-ACK with SUCCESS confirmation code. CMTS MUST wait for REG-ACK. CM sends 1.1/2.0-style REG-REQ. CMTS sends 1.1/2.0-style REG-RESP and CM responds with REG-ACK. CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESP. CM MUST NOT send REG-ACK.

1.0-style configuration file that does not disable DOCSIS 2.0 mode.

CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESP. CM MUST NOT send REG-ACK.

1.1/2.0-style configuration file that disables DOCSIS 2.0 mode.

N/A

CM sends 1.1/2.0-style REG-REQ. CMTS sends 1.1/2.0-style REG-RESP and CM responds with REG-ACK. CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESP. CM MUST NOT send REG-ACK.

1.0-style configuration file that disables DOCSIS 2.0 mode.

CM sends 1.0-style REGREQ. CMTS sends 1.0-style REG-RESP. CM MUST NOT send REG-ACK.

Another minor issue is that a DOCSIS 1.0 CM will request for a bi-directional (with Upstream/Downstream parameters) service class from the CMTS using a Class-of-Service Configuration Setting. Since a DOCSIS 2.0 CMTS typically operates with unidirectional service classes, it can easily translate a DOCSIS 1.0 Class-of-Service Configuration Setting into DOCSIS 1.1 or 2.0 Service Flow Encodings for setting up unidirectional service classes in local QoS implementation. However, for DOCSIS 1.0 modems, the DOCSIS 2.0 CMTS MUST continue to maintain the QoSProfile table (with bi-directional Class parameters) for backward compatibility with the DOCSIS 1.0 MIB. Thus, if properly provisioned, a DOCSIS 1.0, a DOCSIS 1.1, and a DOCSIS 2.0 CM can all successfully register with the same DOCSIS 2.0 CMTS, and a DOCSIS 2.0 CM can register with a 1.0 CMTS. Furthermore, a DOCSIS 2.0 CM can use a DOCSIS 1.0-style configuration file, register on a DOCSIS 2.0 CMTS and still use DOCSIS 2.0 enhanced physical-layer features with DOCSIS 1.0 class-of-service features.
G.1.3 Dynamic Service Establishment

There are 8 MAC messages that relate to Dynamic Service Establishment. A DOCSIS 1.0 CM will never send them to any CMTS since they are unsupported. A DOCSIS 1.1 or 2.0 CM will never send them to a DOCSIS 1.0 CMTS because (a) to register successfully it has to be provisioned as a DOCSIS 1.0 CM and (b) when provisioned as a DOCSIS 1.0 CM it acts identically. When a DOCSIS 1.1 or 2.0 CM is connected to a DOCSIS 1.1 or 2.0 CMTS these messages work as expected.

433

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

G.1.4

Fragmentation

Fragmentation is initiated by the CMTS. Thus, a DOCSIS 1.0 CMTS will never initiate fragmentation since it knows nothing about it. A DOCSIS 1.1 or 2.0 CMTS can only initiate fragmentation for DOCSIS 1.1 or 2.0 CMs. A DOCSIS 1.1 or 2.0 CMTS MUST NOT attempt to fragment transmissions from a DOCSIS v1.0 CM that has not indicated a Modem Capabilities encoding for Fragmentation Support with a value of 1.
G.1.5 Multicast Support

It is mandatory for DOCSIS 1.0 CMs to support forwarding of multicast traffic. However, the specification is silent on IGMP support. The only standard mechanism for controlling IP-multicast on DOCSIS 1.0 CMs is through SNMP and packet filters. Designers of DOCSIS 1.0 networks will have to deal with these limitations and expect no different from DOCSIS 1.0 CMs on a DOCSIS 2.0 network. DOCSIS 2.0 CMs in 1.0 mode MUST still comply with the requirements for IGMP and the forwarding of multicast traffic as per Section 5.1.2.3.2 and Section 5.3.1 of this specification.1
G.1.6 Changing Upstream Channels

A DOCSIS 2.0 CMTS is capable of specifying the level of re-ranging to be performed only when it issues a DCC-Request to the CM. This re-ranging technique parameter is specified by the DOCSIS 2.0 CMTS using a TLV in the DCC-Request MAC message. DOCSIS 1.1 or 2.0 CMs can benefit by only re-ranging to the level specified by this TLV. This can help in reducing the re initialization time following a DCC, for the DOCSIS 1.1 or 2.0 CM carrying a voice call. A DOCSIS 2.0 CMTS is aware of the type of CM to which it is issuing the channel change request. It MUST refrain from sending a DCC-Request for DOCSIS 1.0 CMs, instead choosing to send a UCC-Request. If a DOCSIS 2.0 CMTS sends the UCC-Request, the DOCSIS 1.0 CMs will perform the default DOCSIS 1.0 reranging from start (Initial-Ranging) with its existing non-zero primary sid.

G.2

Hybrid Devices

Some DOCSIS 1.0 CM designs may be capable of supporting individual DOCSIS 1.1 features via a software upgrade. Similarly, some DOCSIS 1.0 CMTSes may be capable of supporting individual DOCSIS 1.1 features. To facilitate these hybrid devices, the majority of DOCSIS 1.1 features are individually enumerated in the Modem Capabilities. DOCSIS 1.0 hybrid CMs MAY request DOCSIS 1.1 features via this mechanism. However, unless a CM is fully DOCSIS 1.1 compliant (i.e., not a hybrid), it MUST NOT send a DOCSIS Version Modem Capability which indicates DOCSIS 1.1. Similarly, unless a CM is fully DOCSIS 2.0 compliant, it MUST NOT send a DOCSIS Version Modem Capability which indicates DOCSIS 2.0. If a hybrid CM intends to request such 1.1 capabilities from the CMTS during registration, it MUST send the ASCII coded string in Option code 60 of its DHCP request, docsis1.0:xxxxxxx. Where xxxxxxx MUST be an ASCII representation of the hexadecimal encoding of the Modem Capabilities. Refer to Annex C.1.3.1 and Annex D.1.1 for details. The DHCP server MAY use such information to determine what configuration file the CM is to use.

1.

Added this paragraph per ECN RFIv2.0-N-03.0119-2 by GO on 02/11/04.

434

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

In order to control the hybrid operation of modems, if a DOCSIS 2.0 CMTS receives a 1.0-style Registration Request message from a CM, the CMTS MUST, by default, force the modem to operate in a pure 1.0 mode with respect to certain features by disabling those features via the Modem Capabilities Encoding in the Registration Response. Specifically, the CMTS MUST support the six default values given in square brackets in Table G-2. The CMTS MAY provide switches, as indicated in Table G-2, for the operator to selectively allow certain hybrid features to be enabled. As an exception to these defaults, the DOCSIS 2.0 CMTS SHOULD allow the use of fragmentation for DOCSIS 2.0 CMs registering in DOCSIS 1.0 mode on an S-CDMA channel that has the Maximum Scheduled Codes feature (see Section 8.3.3) enabled.1
Table G-2 Hybrid Mode Controls

Concatenation Support 1.0 CM 1.1 or 2.0 CM in 1.0 mode allow/[deny] allow/[deny]

Fragmentation Support allow/[deny] allow/[deny]

Privacy Support allow BPI+/[force BPI] allow BPI+/[force BPI]

Normally, a DOCSIS 1.0 CMTS sets all unknown Modem Capabilities to Off in the Registration Response indicating that these features are unsupported and MUST NOT be used by the CM. A DOCSIS 1.0 hybrid CMTS MAY leave supported Modem Capabilities set to On in the Registration Response. However, unless a CMTS is fully DOCSIS 1.1- or 2.0-compliant (i.e., not a hybrid), it MUST still set all DOCSIS Version Modem Capabilities to DOCSIS 1.0. As always, any Modem Capability set to Off in the Registration Response must be viewed as unsupported by the CMTS and MUST NOT be used by the CM.

G.3
G.3.1

DOCSIS 2.0 TDMA Interoperability

Mixed-mode operation with TDMA

In mixed-mode operation with both DOCSIS 1.x and DOCSIS 2.0 TDMA, a single channel is defined with a single UCD that contains both type 4 and type 5 burst descriptors. DOCSIS 1.x and 2.0 modems use the type 4 burst descriptors; DOCSIS 2.0 modems MUST also use the type 5 burst descriptors. DOCSIS 2.0 modems will use IUCs 9 and 10. The following rules of operation apply: 1. Prior to and during registration a DOCSIS 2.0 TDMA capable modem operating on a channel of type 1 or 2 (refer to Section 11.2.2) MUST calculate its request size based on DOCSIS 1.x IUC parameters, and the CMTS MUST make all grants using DOCSIS 1.x IUCs. 2. On a type 2 channel, a DOCSIS 2.0 TDMA CM MUST switch to DOCSIS 2.0 TDMA mode after transmission of the Registration Acknowledgement (REG-ACK) message. If the CM receives a Registration Response (REG-RSP) message after transmission of the REG-ACK message, the CM MUST switch back to DOCSIS 1.1 mode before it continues with the registration process (see Figure 11-12). 3. A CM in DOCSIS 2.0 TDMA mode MUST calculate its request size based on IUC types 9 & 10. The CMTS MUST make grants of IUC types 9 & 10 to that CM after it receives the Registration Acknowledgement message from the CM (see Section 11.2.9).

1.

Revised this paragraph per ECN RFIv2.0-N-0167-2 by GO on 10/18/02.

435

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

4. On a type 2 channel, the CM MUST ignore grants with IUCs that are in conflict with its operational mode (e.g., the CM receives a grant with IUC 5 when it is in DOCSIS 2.0 TDMA mode). 5. On a type 3 channel, the CMTS MUST use type 5 burst descriptors in order to prevent DOCSIS 1.x modems from attempting to use the channel. All data grants are in IUC types 9 & 10. 6. On a type 2 channel, only Advanced PHY Short (IUC 9) and Advanced PHY Long (IUC 10) bursts may be classified as burst descriptor type 5. 7. A DOCSIS 1.x modem that does not find appropriate type 4 burst descriptors for long or short data grant intervals MUST consider the UCD, and the associated upstream channel, unusable.
G.3.2 Interoperability & Performance

This section addresses the issue of performance impact on the upstream channel when DOCSIS 1.x CMs are provisioned to share the same upstream MAC channel as DOCSIS 2.0 TDMA CMs. Since the Initial maintenance, Station maintenance, Request, and Request/Data IUCs are common to both DOCSIS 2.0 TDMA and DOCSIS 1.x CMs, the overall channel will experience reduced performance compared to a dedicated DOCSIS 2.0 TDMA upstream channel. This is due to broadcast/contention regions not being capable of taking advantage of improved physical layer parameters.

G.4
G.4.1

DOCSIS 2.0 S-CDMA Interoperability

Mixed mode operation with S-CDMA

In mixed mode operation with both TDMA and S-CDMA, two logically separate upstream channels are allocated by the CMTS, one for TDMA modems, and another for DOCSIS 2.0 modems operating in S-CDMA mode. Each channel has its own upstream channel ID, and its own UCD. However, these two channels are both allocated the same RF center frequency on the same cable plant segment. The CMTS controls allocation to these two channels in such a way that the channel is shared between the two groups of modems. This can be accomplished by reserving bandwidth through the scheduling of data grants to the NULL SID on all channels other than the channel which is to contain the potential transmit opportunity. Using this method, an upstream channel can support a mixture of differing physical layer DOCSIS modems, with each type capitalizing on their individual strengths. The channel appears as a single physical channel that provides transmission opportunities for both 1.x and DOCSIS 2.0 modems. The mixed-mode configuration of the channel will be transparent to the CMs. The following rule of operation applies: 1. The CMTS MUST use only type 5 burst descriptors on the S-CDMA channel in order to prevent DOCSIS 1.x modems from attempting to use the channel.
G.4.2 Interoperability & Performance

This section addresses the issue of performance impact on the S-CDMA upstream channel when the upstream center frequency is shared with an upstream TDMA channel. Due to the lack of ability to share the upstream transmit opportunities, the channels will not experience the statistical multiplexing benefits during contention regions across the CMs. Dedicated Initial Maintenance regions will be required on both logical MAC channels slightly reducing the overall performance available. Request and Request/Data regions will also not be capable of being shared although an intelligent CMTS scheduler will be able to reduce most performance impact.

436

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Annex H The DOCSIS MAC/PHY Interface (DMPI)

H.1 Scope
Integrated circuit (IC) chip sets with separate MAC and PHY chips used in the implementation of a CMTS SHOULD implement DMPI. DMPI does not apply to IC chip sets which integrate MAC and PHY components together into one chip. Any usage of MUST, SHOULD, or MAY within the DMPI specification applies only if DMPI is implemented.

H.2 Conventions
H.2.1 Terminology

Throughout this annex, the terms MAC and PHY are used extensively. MAC is used to refer to the device which provides the interface between the PHY devices and the system. The term PHY refers to the device which performs the physical layer processing for a single RF channel. It is important to note that both of these terms refer to physical devices as opposed to layers in the IP protocol stack. For the purposes of this specification, integrated circuit chips which handle multiple RF channels simultaneously are considered to contain multiple PHY devices.
H.2.2 Ordering of Bits and Bytes

The following rules control the order of transmission of bits and bytes over all the interfaces specified in the document. In all cases, fields of Data Blocks are transmitted in the order in which they appear in the Data Block format description.

Multibyte quantities are transmitted most significant byte first (big endian byte ordering). This byte ordering
applies regardless of the width of the interface (byte, nibble, single bit).

On nibble wide interfaces, the most significant nibble (bits 7:4) is transmitted first. On bit wide interfaces, the most significant bit of each field is transmitted first.
H.2.3 Signal Naming Conventions

Signal names which end with an _N are active low. Signals without this suffix are active high.
H.2.4 Active Clock Edge

All signals are driven and sampled on the rising edge of the clock except where otherwise noted.

437

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.2.5 Timing Specifications

The timing specs for DMPI use the following terminology:

Table H-1 Timing Parameters
Parameter Symbol Description

Clock Frequency Clock Low Pulse Width Clock High Pulse Width Clock rise/fall time Input Setup Time to Clock Input Hold Time from Clock Clock to Signal Valid Delay

f tlpw thpw trf tsu th tcq

The frequency of the interface clock. The low time of the interface clock. The high time of the interface clock. The transition time of the clock. From when an interface signal is valid to the following rising clock edge. From the rising clock edge to when an interface signal becomes invalid. From the rising edge of the interface clock to an interface signal becoming valid.

Following are some usage notes for these timing parameters:

Setup and hold time specifications are given from the point of view of the DMPI Interface and not from the
point of view of a device on the DMPI Interface. The clock to output, on the other hand, specifies the timing requirement of a DMPI device.

The tsu parameter specifies the minimum guaranteed amount of setup time provided by the DMPI interface
measured at the receiving device. Therefore, inputs on DMPI devices should require no more than this amount of setup time.

The th parameter specifies the minimum guaranteed amount of hold time provided by the DMPI interface
measured at the receiving device. Therefore, inputs on DMPI devices should require no more than this amount of hold time.

The tcq parameter specifies the minimum and maximum clock to output time at the driving device. The purpose of the minimum specification is to allow for clock skew between the driving and receiving DMPI device. For example, a 1ns minimum spec and a 0ns DMPI hold time requirement allows for at most 1ns of clock skew between devices. The maximum specification is to allow for the settling time of signals from the driving device to the receiving device and clock skew between devices.

H.3 Overview
This annex describes the DOCSIS MAC/PHY Interface (DMPI). DMPI is used to connect a DOCSIS MAC device to DOCSIS downstream and upstream PHY devices. While DMPI is a single interface, for the purposes of clarity, DMPI signals have been grouped into four separate groups. Each group serves a specific purpose and is independent of the others. For this reason, each group of signals is also referred to as an interface. A Downstream PHY MUST include a Downstream Data Interface and an SPI Bus Interface. An Upstream PHY must include an Upstream Data Interface, an Upstream Control Interface, and an SPI Bus Interface. PHY Chips which integrate multiple PHYs into a single package MUST have one set of interfaces for each PHY which has been integrated with the following exception: An integrated PHY device MAY use a single select and a single SPI Bus for all internal PHYs (using the SPI Bus protocol described in Annex H.8.4). An integrated Upstream PHY device MAY have only one TS_CLK input and only one US_CLK input.

438

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A MAC MUST include one Downstream Data Interface for each Downstream PHY it supports and one set of Upstream Interfaces (Upstream Data and Upstream Control) for each Upstream PHY it supports. It MUST include at least one SPI Bus Interface. DMPI has been defined with the following goals in mind:

Vendor independence Flexibility for future growth and vendor differentiation Minimization of PHY specific logic in the MAC
Figure H-1 shows an example application of DMPI. Note that this figure shows the connections required for a single DS PHY and a single US PHY. Obviously, other applications with multiple DS and US PHYs are possible.

439

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

DS_DATA[3:0] DS_DATAP DS_VALID_N DS_MSYNC_N DS_CLK DS PHY INT_N SPI_MOSI SPI_MISO SPI_SS0_N

UD_DATA[3:0] UD_DATAP MAC UD_SOB_N UD_DV_N

TS_FS_N UC_DATA UC_DV_N UC_RDY_N US PHY

INT_N SPI_SS1_N

SPI_CLK TS_CLK US_CLK Figure H-1 DMPI Application

440

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.3.1 Downstream Data

The Downstream Data Interface carries data from the MAC to the PHY for transmission on the Downstream. All signals on the interface are synchronous with respect to a clock driven by the PHY and received by the MAC. Four bits of data are transferred on each clock. The frequency of this clock is proportional to the Downstream bit rate. Its precise frequency is a function of the Downstream Symbol Rate, the modulation type (64QAM or 256QAM), and the physical layer framing in use (ITU-T Recommendations J.83 Annex A or ITU-T Recommendations J.83 Annex B).
H.3.2 Upstream Data

The Upstream Data Interface carries data from the PHY to the MAC which has been received on the Upstream. The interface is synchronous to a dedicated interface clock whose frequency is not directly related to the upstream bit rate. Data is transferred over the interface using a mixture of TLVs and TVs (a TLV for which the length is implied by the type). Along with the DOCSIS burst data, certain status information about the burst is also transferred to the MAC. There is also a TLV which allows the PHY to indicate that it didnt receive a burst when one was expected.
H.3.3 Upstream Control

The Upstream Control Interface is used for two purposes. The first is to initialize the PHYs timestamp counter, frame counter, and mini-slot counter and to check that the PHYs timestamp counter remains synchronized to the MACs during operation. The second is to allow the MAC to pass information to the PHY regarding upcoming bursts. This interface uses two clocks. The clock used for the counter synchronization is the 10.24 MHz CMTS master clock. A single signal, that is synchronized to this clock, is used to perform this counter synchronization. The other clock used for this interface is shared with the Upstream Data Interface and has a frequency unrelated to the upstream modulation clock or the 10.24 MHz CMTS master clock. This clock, along with an associated set of signals, is used to transfer descriptions of future bursts.
H.3.4 SPI Bus

The Serial Peripheral Interconnect (SPI) Bus is used to read and write registers in the PHYs. The system MAY use one or more SPI Buses to provide register access to the PHYs. The number of SPI Buses in the system is a function of the systems SPI Bus performance requirements. Each SPI Bus has a single master device which MAY be the MAC. Alternatively, an SPI Bus master MAY be some other device in the system (e.g., a microprocessor). References to the SPI Bus in this specification assume that the MAC is the master. The PHYs MUST only be slave devices. Each PHY MUST have one SPI Bus Interface. Multiple PHYs MAY share the same SPI Bus. The SPI Bus definition includes an interrupt signal (INT_N). Each PHY MUST drive an interrupt. The interrupt signals MAY be received by an SPI Bus master or they MAY be received by some other device in the system which provides the ability to monitor their state.

441

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.4 Signals
H.4.1 Downstream Data

The signals used for the Downstream Data Interface are defined in Table H-2.
Table H-2
Signal

Downstream Data Interface Signals

Description

DS_CLK

DS transmit clock Driven by the Downstream PHY see Annex H.5.1 and Annex H.5.2 for detailed requirements for this clock

DS_MSYNC_N

Downstream MPEG Sync Driven by the MAC marks first nibble of sync byte; active low

DS_VALID_N

Downstream Data Valid Driven by the MAC indicates that valid data is present on DS_DATA

DS_DATA[3:0]

DS transmit data Driven by the MAC

DS_DATAP

Downstream Parity Driven by the MAC Even parity for DS_DATA (the number of 1s across DS_DATA and DS_DATAP is even) DS_DATA and its corresponding DS_DATAP are driven on the same clock. Parity is not delayed a clock as it is in some interfaces.

H.4.2 Upstream Data

The signals used for the Upstream Data Interface are defined in Table H-3.
Table H-3
Signal

Upstream Data Interface Signals

Description

US_CLK

Upstream Data/Control Clock Driven by external clock source (input to MAC and PHY)

UD_SOB_N

Upstream Data Start of Data Block Driven by Upstream PHY asserted when the first nibble or first byte of the Data Block is on UD_DATA

UD_DV_N

Upstream Data Valid Driven by Upstream PHY indicates valid data on UD_DATA

UD_DATA[3:0]

Upstream Data Driven by Upstream PHY

UD_DATAP

Upstream Data Parity Driven by Upstream PHY Even parity for UD_DATA (the number of 1s across UD_DATA and UD_DATAP is even) UD_DATA and its corresponding UD_DATAP are driven on the same clock. Parity is not delayed a clock as it is in some other interfaces.

442

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.4.3 Upstream Control

Table H-4 lists the signals that are used for the Upstream Control Interface.
Table H-4
Signal

Upstream Control Interface Signals

Description

US_CLK

Upstream Clock Driven by external clock source (input to MAC and PHY)

UC_DV_N

Upstream Control Data Valid Driven by the MAC Indicates valid Upstream Control Message data on UC_DATA

UC_DATA

Upstream Control Data Driven by the MAC

UC_RDY_N

Upstream Control Ready Driven by the PHY Indicates that the PHY is ready to receive an Interval Description Message

TS_CLK

10.24 MHz master clock Driven by external clock source (input to MAC and PHY)

TS_FS_N

Timestamp Frame Sync Driven by the MAC

H.4.4 SPI Bus

Table H-5
Signal name

SPI Bus Signals

Description

SPI_CLK

SPI Bus Clock Driven by a source external to the MAC and PHY or driven by the MAC

SPI_MOSI

Master out/Slave in Serial data from the MAC to the PHY

SPI_MISO

Slave out/Master in Serial data from the PHY to the MAC MAY be driven by the PHY from the falling edge of SPI_CLK.

SPI_SSx_N

Slave Select Selects a slave for a transaction. One Slave Select signal is provided by the MAC for each PHY (x = 1 to N). Addressing of devices within a package is provided by the protocol layer described in Annex H.8.4 MAY be sampled by the PHY on the falling edge of SPI_CLK

INT_N

Interrupt Driven by PHYs Open drain

443

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.4.5 Parity

The Downstream Data, Upstream Data, and Upstream Control Interfaces use parity to maintain data integrity on the interface. Parity SHOULD be implemented. The SPI Bus does not have parity. Parity is even and covers only the data lines of the interface. Specific rules for parity checking are detailed in the following sections.
H.4.5.1 Downstream Data

Parity must be checked by the Downstream PHY and covers DS_DATA. Since the Downstream transmit data is protected (DOCSIS frame HCS and CRC), detection of a parity error is not considered fatal and MUST NOT cause the processing of transmit data to halt. The PHY must generate an interrupt to the system when it detects a parity error so that the system can be made aware of its occurrence. Parity checking on this interface provides a way to distinguish between data errors on the interface and those in other parts of the data path.
H.4.5.2 Upstream Data

Parity is checked by the MAC and covers UD_DATA. Since the Upstream receive data is protected (DOCSIS frame HCS and CRC), detection of a parity error is not considered fatal and MUST NOT cause the processing of receive data to halt. The MAC must generate an interrupt to the system when it detects a parity error so that the system can be made aware of its occurrence. Parity checking on this interface provides a way to distinguish between data errors on the interface and those in other parts of the data path.
H.4.5.3 Upstream Control

Parity is checked by the Upstream PHY and covers the entire Upstream Control Message. A parity error on this interface is considered a fatal error. The PHY MUST NOT process the Upstream Control message which was received with a parity error as well as any subsequently received message. The PHY MAY process any Upstream Control messages received prior to the occurrence of the parity error. This processing MAY include the passage of various types of Upstream Data Blocks to the MAC.
H.4.6 Interrupts

Various places in the specification make reference to the assertion of an interrupt by the PHY. The characteristics of this interrupt MUST be as follows:

One active low interrupt line of level type Driven open drain Cause of interrupt line assertion determined by software read(s) of PHY register(s) which contains one bit for
each interrupt source

No hardware prioritization of interrupt sources Each interrupt source separately cleared by software write(s) to PHY register(s) Asserted until all interrupt source bits are cleared (interrupt line is a simple OR of all interrupt sources)

444

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.5 Protocol
H.5.1 Downstream Data (ITU-T Recommendations J.83 Annex A)

Figure H-2 shows the protocol for ITU-T Recommendations J.83 Annex A operation.

DS_CLK DS_MSYNC_N DS_VALID_N DS_DATA DS_DATAP

187H 187L

SYNCH SYNCL

1H

1L

2H

2L

SYNCH SYNCL

Figure H-2 Downstream Data Signal Protocol for ITU-T Recommendations J.83 Annex A Operation

The following behavior of DS_CLK and DS_VALID_N is required:

DS_CLK MUST NOT be gapped (it must have a constant frequency) DS_CLK frequency MUST be 1/4 of the Downstream Line Rate. The DS Line Rate is the data rate including
the ITU-T Recommendations J.83 Annex A framing overhead.

The MAC MUST assert DS_VALID_N for the entire 188 byte MPEG frame transfer and then MUST deassert it for exactly 32 clocks following the transfer of the last nibble of the MPEG frame

445

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.5.2 Downstream Data (ITU-T Recommendations J.83 Annex B)

Figure H-3 shows the protocol used to transfer data across this interface for ITU-T Recommendations J.83 Annex B operation.

DS_CLK DS_MSYNC_N DS_VALID_N DS_DATA DS_DATAP

SYNCH SYNCL

1H

1L

2H

2L

187H

187L

SYNCH SYNCL

Figure H-3 Downstream Data Signal Protocol for ITU-T Recommendations J.83 Annex B Operation

The following behavior of DS_CLK and DS_VALID_N is required:

DS_CLK MUST NOT be gapped (it must have a constant frequency) DS_CLK frequency MUST be 1/4 of the Downstream Payload Rate. The Downstream Payload Rate is the
data rate excluding the ITU-T Recommendations J.83 Annex B framing overhead.

The MAC MUST keep DS_VALID_N always asserted

H.5.3 Upstream Data

Figure H-4 shows the signaling protocol for this interface.

US_CLK UD_SOB_N UD_DV_N UD_DATA UD_DATAP

B0H

B0L

B1H

B1L

BNH

BNL

B0H

B0L

Figure H-4

Upstream Data Protocol

446

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

It is a very simple protocol in which the Upstream PHY indicates the presence of valid data on UD_DATA by asserting UD_DV_N. The MAC has no ability to control the flow of data and is required to sample UD_DATA on every rising clock edge on which UD_DV_N is asserted. The start of a Data Block is indicated by the PHYs assertion of UD_SOB_N. This signal MUST be asserted when the first nibble of the first byte of the Data Block is driven onto UD_DATA. The MAC MUST keep track of length of each Data Block as it relates to the assertion of UD_SOB_N. If UD_SOB_N is asserted before the entire previous Data Block has been transferred, the MAC MUST drop the associated burst and generate an interrupt. If the FIRST_STATUS byte indicates the absence of a PHY_STATUS Data Block but the PHY transfers one, the PHY_STATUS Data Block MUST be discarded by the MAC and an error MUST be signaled to the system.
H.5.4 Upstream Control H.5.4.1 Counter Synchronization

The master timestamp counter MUST reside in the MAC. The master mini-slot counter and master frame counter MUST reside in the PHY. The PHY MUST capture a timestamp snapshot on every frame boundary. When the system needs a Timestamp Snapshot for a UCD, it MUST read this snapshot using a single SPI bus transaction. The PHY MUST ensure that the timestamp snapshot does not change during the SPI Bus read transaction. A common timestamp clock, TS_CLK, MUST be externally provided to the upstream PHYs and the MACs. The frequency of this timestamp clock MUST be 10.24 MHz 5 ppm. The MAC MUST synchronize all PHYs to the timestamp value of the MAC. To accomplish this, the MAC MUST provide a frame sync pulse, TS_FS_N, to the PHYs that is synchronous to the positive edge of TS_CLK and has a pulse width equal to one period of TS_CLK. The 32 bit timestamp counter consists of a group of upper bits and a group of lower bits. The MAC and PHY MUST provide at least the following choices of upper and lower bit boundaries shown in Table H-6.
Table H-6 Timestamp Counter Initialization Options
Upper Bits Lower Bits Frame Sync Interval

8 9 10 11 12

24 23 22 21 20

1638.4 ms 819.2 ms 409.6 ms 204.8 ms 102.4 ms

Figure H-5 shows an example of the proper assertion of the TS_FS_N signal. Note that the TIMESTAMP is shown for reference and is not part of the Upstream Control Interface. In this example, Upper Bits = 8.

TS_CLK TS_FS_N TIMESTAMP

XXFFF8 XXFFF9 XXFFFA XXFFFB XXFFFC XXFFFD XXFFFE XXFFFF XX0000 XX0001

Figure H-5 Counter Synchronization

447

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The MAC MUST assert TS_FS_N two 10.24 MHz clock periods prior to the lower bits of the MAC timestamp counter equalling all zeros. The MAC SHOULD provide some sort of maskable indication to the system when TS_FS_N occurs so that the system will have time to program the registers of the PHYs prior to the next assertion of TS_FS_N. The period of TS_FS_N is a function of the timestamp bit time and the number of lower bits from Table H-6. The variation of the TS_FS_N period is to allow the system designer to trade off system response time versus the time available to initialize a PHY chip. The PHY MUST provide all combinations of the following three initialization options when TS_FS_N is asserted:

the upper bits of the timestamp counter are specified and the lower bits are set to zero the full 8 bits of the frame counter are specified the full 32 bits of the mini-slot counter are specified
The specification of these counters is supplied across the SPI Bus prior to the next frame sync pulse. Two TS_CLK clock cycles after TS_FS_N occurs, the PHY chip MUST initialize the specified counters. These counters are loaded at configuration time, and not on every assertion of TS_FS_N. A single PHY may be reinitialized without the need to re-initialize or otherwise interrupt the operation of other PHYs or the MAC. During normal operation, the PHY MUST check that the lower bits of the PHY timestamp counter are exactly all zeros two 10.24 MHz clock cycles following every assertion of TS_FS_N. If the check is negative, the PHY MUST generate an interrupt and MUST provide status accessible over the SPI bus.
H.5.4.2 Upstream Control Messages

Figure H-6 shows a sample transaction.

US_CLK UC_DV_N

UC_DATA UC_RDY_N

Figure H-6 Upstream Control Message Transfer

The Upstream Control Interface is used to transfer time critical configuration information (messages) to the PHY. The most common type of message is an Interval Description message. This message informs the PHY of the arrival time and characteristics of an upcoming burst. The protocol of this interface is very simple. Following is a description of how this interface works:

A transaction transfers a single Upstream Control message. UC_DV_N MUST remain asserted for the entire duration of the Upstream Control message transfer. The length of each Upstream Control message is inferred by its type. UC_DV_N MUST be de-asserted for a minimum of one US_CLK clock period to indicate the end of a transaction.

448

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

UC_RDY_N MAY be used to stop and start the flow of Interval Description messages. UC_RDY_N does not
affect the transfer of other message types. If the PHY is receiving an interval description and does not want to receive a subsequent interval description, the PHY MUST de-assert UC_RDY_N at least two clock cycles of US_CLK prior to the end of the current interval description. This de-assertion behavior is shown in Figure H6. The MAC MUST transfer a new Interval Description Message within 10 US_CLK periods of the assertion of UC_RDY_N if a new Interval Description Messages is available.1
H.5.5 SPI Bus

Figure H-7 shows a SPI Bus transaction.

SPI_CLK SPI_SSx_N SPI_MOSI SPI_MISO

MSB

Figure H-7 SPI Bus Transaction

A transaction proceeds as follows:

The master asserts the select (SPI_SSx_N) of the desired slave device. The master drives SPI_MOSI with the appropriate command and data as described in Annex H.8.4. For write commands, the first byte of data driven on SPI_MOSI is written to the register specified by the
address in the command. The second byte of data (if it exists), is written to the next higher numbered address. Writes continue in this way until the master terminates the transaction by de-asserting SPI_SSx_N.

For read commands, the slave drives the read data on SPI_MISO which is indicated by the address in the
command. The first bit of this read data is driven one clock after the last bit of the command has been sampled. Read data from consecutively numbered addresses is driven until the master terminates the transaction by de-asserting SPI_SSx_N. SPI_CLK MUST be driven (oscillate) for at least one clock period prior to the assertion of SPI_SSx_N, during the entire SPI Bus transaction, and for one clock after the deassertion of SPI_SSx_N. SPI_CLK MAY be driven high or low at all other times.

1.

Replaced bulleted paragraph per ECN RFI2-N-02218, by GO, on 12/03/02.

449

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.6 Electrical Specifications

H.6.1 DC Specifications

Devices which connect to DMPI must meet the requirements listed in Table H-7. Note that Output High Voltage and Output High Current specifications do not apply to the INT_N output as it is open drain.
Table H-7
Parameter Symbol

DC Characteristics
Min. Max Units Comments

Input Capacitance Input Low Voltage Input High Voltage Output Low Voltage Output High Voltage Output Low Current Output High Current Vil Vih Vol Voh Iol Ioh 2.4 4 -4 2.0

10 0.8

pf v v

0.4

v v ma ma

450

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.7 Timing Specifications

H.7.1 Downstream Data
Table H-8
Parameter

DS Data Interface Timing

Symbol Min. Max. Units

DS_CLK Frequency DS_CLK Low Pulse Width DS_CLK High Pulse Width DS_CLK rise/fall time DS_CLK Jitter Input Setup Time to DS_CLK Input Hold Time from DS_CLK DS_CLK to Signal Valid Delay

f tlpw thpw trf tj tsu th tcq 10 0 1 10 10

25

MHz ns ns

4 97.66

ns ns ns ns

15

ns

H.7.2 Upstream Data

Table H-9
Parameter

US Data Interface Timing

Symbol Min. Max. Units

US_CLK Frequency US_CLK Low Pulse Width US_CLK High Pulse Width US_CLK rise/fall time Input Setup Time to US_CLK Input Hold Time from US_CLK US_CLK to Signal Valid Delay

f tlpw thpw trf tsu th tcq

33 6.5 6.5

40.96

MHz ns ns

3 6 0 1 12

ns ns ns ns

H.7.3 Upstream Control

Table H-10
Parameter

Upstream Control Interface Timing

Symbol Min. Max. Units

Input Setup Time to US_CLK Input Hold Time from US_CLK US_CLK to Signal Valid Delay TS_CLK rise/fall time Input Setup Time to TS_CLK Input Hold Time from TS_CLK TS_CLK to Signal Valid Delay

tsu th tcq trf tsu th tcq

6 0 1 12 3 10 0 1 15

ns ns ns ns ns ns ns

451

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.7.4 SPI Bus

Table H-11
Parameter

SPI Bus Timing

Min. Max. Units

Symbol

SPI_CLK Frequency SPI_CLK Low Pulse Width SPI_CLK High Pulse Width SPI_CLK rise/fall time SPI_MOSI or SPI_MISO Setup Time to SPI_CLK SPI_MOSI or SPI_MISO Hold Time from SPI_CLK SPI_SSx_N Setup Time to SPI_CLK rising3 SPI_SSx_N Setup Time to SPI_CLK falling4 SPI_SSx_N Hold Time from SPI_CLK SPI_CLK to Signal Valid Delay
1. 2.
5

f tlpw thpw trf tsu th tsu tsu th tcq 15 0 50 25 0 1 43.91 43.92

10.24

MHz ns ns

ns ns ns ns ns ns

12

ns

Can be achieved with a 45/55 duty cycle 10.24Mhz clock Can be achieved with a 45/55 duty cycle 10.24Mhz clock 3. Applies to PHYs which sample SPI_SSx_N with the rising edge of SPI_CLK. Ignored otherwise. 4. Applies to PHYs which sample SPI_SSx_N with the falling edge of SPI_CLK. Ignored otherwise. 5. For SPI_MISO, this timing is referenced to the driving edge of the clock (rising or falling, depending on the device).

H.8 Data Format and Usage

H.8.1 Downstream Data

The data which passes from the MAC to the PHY is a stream of MPEG frames. The start of the SYNC byte is indicated by the assertion of the DS_MSYNC_N signal. Including the SYNC byte, each MPEG frame is 188 bytes in length. The MAC MUST generate NULL MPEG frames when there are no DOCSIS frames to be transmitted.
H.8.2 Upstream Data H.8.2.1 Block Format

Data is passed from the Upstream PHY to the MAC using a combination variable sized units called Upstream Data Blocks. Each of these Data Blocks has the generic format described in Table H-12 (except for the CHANNEL Data Block Type as indicated in Annex H.8.2.8.5).
Table H-12
Size (bytes) Name

Upstream Data Block Format

Description

1 2

Block Type Block Length

identifies the type of Block length of Block data field in bytes (N) Not present for CHANNEL Block Type

Block Data

Block data

452

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

As can be seen from this table, each Data Block starts with a Data Block type. This type is used by the MAC to determine which type of Data Block data is being transferred. The Data Block length field contains the length in bytes of the Data Block data and is used by the MAC to find the end of the Data Block data field. In most cases, the Data Block type determines the format of the Data Block data field. The exception to this is the PHY_STATUS type where the format of the Data Block data field is PHY specific. Table H-13 gives a complete list of all Block Types.
Table H-13 Upstream Data Block Types
Type Name Description

0x00 0x01

Reserved FIRST_DATA

Reserved First data of burst contains 7 bytes of fixed format status data and first data of burst

0x02 0x03

MIDDLE_DATA LAST_DATA

Middle data of burst Last data of burst contains 4 bytes of fixed format status data and last data of burst

0x04

PHY_STATUS

Status which should be passed to software The maximum length of this Block is 128 bytes

0x05 0x06 0x07-0xff

NO_BURST CHANNEL Reserved

Indicates that no burst was received during a transmit opportunity Used to indicate the channel to which the next Data Block belongs. Reserved

H.8.2.2

FIRST_DATA Block

Table H-14 shows the format of the FIRST_DATA Block. The FIRST_DATA Block is used by the PHY to transfer the beginning of a received burst. This block MUST contain the seven bytes of status information defined in the table. It MAY contain burst data as well. The Block Length of the FIRST_DATA block MUST NOT be less than seven. Note that N=7 is allowed.
Table H-14
Size (bytes) Name

FIRST_DATA Data Format

Description

FIRST_STATUS

bit 7:6, reserved, MUST be zero bit 5, New UCD, 1=> First burst received on new UCD bit 4, PHY_STATUS Data Block present, 1=> PHY_STATUS Data Block present bit 3:0, IUC, taken from the Upstream Control Interval Description message

SID

bit 15:14, reserved, MUST be zero bit 13:0, SID, taken from the Upstream Control Interval Description message

4 N-7

START_MINISLOT BURST_DATA

Derived from the Upstream Control Interval Description message parameters First data of burst

453

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.8.2.3

MIDDLE_DATA Block

Table H-15 shows the format of the MIDDLE_DATA Block. The MIDDLE_DATA block is used to transfer burst data.
Table H-15 MIDDLE_DATA Data Format
Size (bytes) Name Description

BURST_DATA

Middle data of burst

H.8.2.4

LAST_DATA Block

Table H-16 shows the format of the LAST_DATA Block. The LAST_DATA block is used to transfer burst data. This block MUST contain the four bytes of status information defined in the table. It MAY also contain burst data. The Block Length of the LAST_DATA block MUST NOT be less than four. Note that N=4 is allowed.
Table H-16
Size (bytes) Name

LAST_DATA Data Format

Description

N-4 1

BURST_DATA LAST_STATUS

Last data of burst bit 7:3, reserved, must be zero bit 2, internal PHY error, 1=> internal PHY error bit 1, low energy; indicates that the burst power was below the desired threshold, 1 => low energy bit 0, high energy; indicates that the burst power was above the desired threshold, 1 => high energy

GOOD_FEC

the number of good FEC blocks in the burst must stop incrementing when count reaches 255 must be zero if FEC is disabled for associated interval

CORRECTED_FEC

the number of corrected FEC blocks in the burst must stop incrementing when count reaches 255 must be zero if FEC is disabled for associated interval

UNCORRECTED_FEC

the number of uncorrected FEC blocks in the burst must stop incrementing when count reaches 255 must be zero if FEC is disabled for associated interval

H.8.2.5

PHY_STATUS Block

Table H-17 shows the format of the PHY_STATUS Block. The PHY_STATUS block is used to transfer PHY unique status to the MAC. The contents of this block are vendor unique and are unrestricted.
Table H-17
Size (bytes) Name

PHY_STATUS Data Format

Description

PHY_STATUS

PHY specific status information such as channel characteristics (e.g. timing error, power error, frequency error, EQ coefficients)

454

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.8.2.6

NO_BURST Block

Table H-18 shows the format of the NO_BURST Block. This block is used by the PHY to indicate that a valid burst was not received when one was expected. Absence of a valid burst may be caused by either no transmitter, multiple transmitters, or a noise corrupted transmission. DMPI does not specify the criteria by which the PHY distinguishes between these cases.
Table H-18 NO_BURST Data Format
Size (bytes) Name Description

SID_STATUS

bit 15, collision, collision occurred bit 14, no energy, no energy detected bit 13:0, SID, taken from the Upstream Control Interval Description message

4 1

START_MINISLOT IUC

Derived from the Upstream Control Interval Description message parameters bit 7:5, reserved, must be zero bit 4: New UCD, 1=> First NO_BURST block received on new UCD bit 3:0, IUC, taken from the Upstream Control Interval Description message

LENGTH

Taken from the Upstream Control Interval Description message Note that for Contention Intervals, this is the length of the interval and not the length of each individual transmit opportunity in the interval.

H.8.2.7

CHANNEL Block

Table H-19 shows the format of the CHANNEL Block. The Channel Block is used by the PHY to indicate to which logical channel subsequent blocks belong.
Table H-19 Size (bytes)
1

CHANNEL Data Format Description

Name
CHANNEL

bit 7:3, reserved, must be zero bit 2:0, Channel Number

H.8.2.8 H.8.2.8.1

Block Usage Overview

At least one Data Block MUST be transferred for every Transmit Opportunity. If a burst is received during a transmit opportunity, the appropriate series of Data Blocks MUST be transferred to the MAC (FIRST_DATA, MIDDLE_DATA, LAST_DATA, PHY_STATUS). If no burst is received, a NO_BURST Data Block MUST be transferred unless the region was allocated to a SID which the system has reserved for no CM (e.g. the null SID as defined in A.2.1).1 Note that since contention regions have multiple transmit opportunities, more than one set of Data Blocks will likely be transferred to over the interface for each region (interval).

1.

Replaced sentence per ECN RFI2-N-02217, by GO, on 12/03/02.

455

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The minimum amount of payload in a Data Block (the length of the Block Data field) MUST be 16 bytes with the following exceptions:

Data Blocks for bursts which are less than 16 bytes in length Any LAST_DATA Data Block
The Upstream PHY SHOULD minimize the number of Data Blocks required to transfer a burst so as to minimize the amount of overhead on DMPI. However, nothing specific other than what is mentioned above is required. For Non-contention Intervals, the START_MINISLOT MUST be equal to the START_MINISLOT which was passed to the PHY in the corresponding Interval Description Message (described in Annex H.8.3). For Contention Intervals (IE types REQ and REQ/Data), the PHY MUST calculate an accurate START_MINISLOT value and return it in the appropriate Data Block (FIRST_DATA or NO_BURST). In general terms, this means that PHY MUST calculate the START_MINISLOT for each Data Block by taking into account the number of mini-slots which have passed since the start of the Interval. Specifically, the Upstream PHY SHOULD use the IUC and SID in the Upstream Control Interval Description message to calculate a burst start offset from the original START_MINISLOT value received in this message. The offset is then added to this START_MINISLOT and returned to the MAC as the START_MINISLOT in the appropriate Upstream Data Block.
H.8.2.8.2 Burst Data Transfer

The transfer of a burst MUST be accomplished by transferring the following Data Blocks in the following order:

one FIRST_DATA Block zero to N MIDDLE_DATA Blocks one LAST_DATA Block zero or one PHY_STATUS Block

The only Data Block type which MAY be transferred after a FIRST_DATA Data Block and before a LAST_DATA Data Block is a MIDDLE_DATA Data Block. Any other Data Block transferred between these two Data Blocks MUST be discarded by the MAC. In general, each Data Block will contain one FEC block of data. However, there is no specific requirement as to which Data Block types contain which parts of the burst data. The data MAY be distributed between the various Data Block types at the discretion of the PHY as long as the Data Block ordering shown above is maintained and the minimum block length requirements are respected. A Data Block type with a length of zero is also allowed. Every burst, regardless of size, MUST be transferred to the MAC using at least a FIRST_DATA Block and a LAST_DATA Data Block. The PHY_STATUS Data Block is optional with its presence indicated in the FIRST_STATUS byte in the FIRST_DATA Data Block. The MIDDLE_DATA Data Block is optional. Typically, there will be some arbitrary delay between the transfer of one Data Block and the transfer of the next. It is the PHYs responsibility to assure that these delays do not interfere with the PHYs ability to keep up with the incoming data rate. Note that this series of Data Blocks is passed to the MAC any time a burst is received regardless of the type of interval in which the burst was received (contention or non-contention).

456

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

H.8.2.8.3

No Burst Status Transfer

It is sometimes useful for the system to know when no usable burst was received during a transmit opportunity. This can happen when there is no transmitter (no energy) in the opportunity, there is more than one transmitter (a collision), or noise corrupted a transmission. For a contention region, knowledge of unused opportunities or those with collisions helps software optimize its scheduling of contention regions (their duration and frequency). For non-contention regions, these same events could be an indication of a problem with a CM. Or, they could be a result of illegal or malicious use of the US bandwidth. The NO_BURST Data Block contains two status bits. The one called collision indicates that a collision occurred during the transmit opportunity. The other, called no energy, indicates that there was no energy detected during the transmit opportunity. If neither is set, it means that there was energy but that no preamble was found. Both of these bits must not be set at the same time.
H.8.2.8.4 UCD Change Indication

In order to allow the system to properly size grants for bandwidth requests which were received prior to a UCD change but are granted after such a UCD change, the MAC needs to be notified that a new UCD is in effect. This notification is achieved via New UCD status bits in the NO_BURST and FIRST_DATA Data Blocks. The PHY MUST set the New UCD bit of the first Data Block sent to the MAC after a UCD change (FIRST_DATA or NO_BURST, whichever is sent first). The New UCD bit of these Data Blocks MUST be zero at all other times.
H.8.2.8.5 Logical Channel Support

For Upstream PHYs which support multiple logical channels, a Data Block Type called CHANNEL is used to specify to which logical channel each Data Block belongs. This Data Block contains a single byte of payload which is the channel number (zero to seven inclusive). Since the Data Block is a fixed length and is potentially required for every other Data Block transferred, the length bytes are omitted from the normal Data Block format and only the Data Block Type and Block Data are transferred. So, a CHANNEL Block is always two bytes long (including the Type byte). It is important to note that the Channel Data Block is only used to distinguish between data received on logical channels within the same RF channel. Since each PHY has its own DMPI interface, the RF channel to which data belongs is inferred by the PHYs connection to the MAC. The CHANNEL Data Block is used as follows:

The CHANNEL Data Block sets the current channel for transmitted Data Blocks. After reset, the MAC
must set the current channel to zero.

The current channel is always the channel number contained in the most recently transmitted CHANNEL
Data Block. For this reason, transmission of a CHANNEL Data Blocks is only required when a change in the current channel is desired. Since the MAC sets the current channel to zero prior to receipt of any CHANNEL Data Blocks, PHYs which support a single channel are not required to support this Data Block Type. In cases where multiple CHANNEL Data Blocks are transferred in succession, the last one received prior to the transfer of one of the other Data Blocks will be considered valid and the others that preceded it will be ignored. NO_BURST Data Blocks may be preceded by a CHANNEL Data Block. If a series of NO_BURST Data Blocks for the same channel are transmitted to the MAC, only one CHANNEL Data Block is required (transferred prior to the first NO_BURST Data Block). All Data Blocks associated with a single burst MUST be transferred contiguously over the Upstream Data interface. Specifically, this would mean that FIRST_DATA, MIDDLE_DATA, LAST_DATA, PHY_STATUS
457

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

would all be transferred for a given burst of a given channel before any other Data Blocks were transferred for another channel. A CHANNEL Data Block MUST precede the first Data Block (NO_BURST or FIRST_DATA) that belongs to a channel which is different than the one which preceded it. The PHY MAY transfer a CHANNEL Data Block prior to the FIRST_DATA block of every burst. CHANNEL Data Blocks MUST NOT be transferred immediately before any of the other Data Block associated with a burst.
H.8.3 Upstream Control

The Upstream Control Interface carries two different messages. One of them is used to describe upcoming bursts. The other is used to indicate UCD changes. The format of an Upstream Control Message is shown in Table H-20.
Table H-20
Size (bits) Name

Upstream Control Message Format

Description

3 3 N 1

TYPE CHANNEL PAYLOAD PARITY

Message Type Logical Channel Number Payload of Message Even parity for all bits in the Message (the number of 1s across all bits in {TYPE, CHANNEL, PAYLOAD, PARITY} is even)

Table H-21 shows the Message Type encoding.

Table H-21
Type Name

Upstream Message Types

Description

0x0 0x1 0x2-0x7

INTERVAL_DESCRIPTION UCD_CHANGE Reserved

Describes an interval Indicates a UCD change has occurred Reserved

H.8.3.1

Interval Description Message

Table H-22 describes the format of the Interval Description Message Payload.
Table H-22 Upstream Control Interval Description PAYLOAD Format
Size (bits) Name Description

14 4 14 32 3

SID IUC LENGTH START_MINISLOT PSC

expected SID from MAP IE IUC from MAP IE length in mini-slots starting mini-slot of interval (alloc start time + offset of IE) PHY_STATUS Control

The MAC builds these Interval Description Messages from the information present in the DOCSIS MAPs that have been generated for the logical channels which the PHY is servicing. The MAC MUST transfer only one Interval Description Message to the PHY for an Interval Allocation which might describe an interval which has more than one transmit opportunity (e.g. REQ, REQ/DATA). The MAC MAY generate Interval Description Messages for Interval Allocations to the NULL SID, but MUST NOT generate Interval Description Messages for Interval Allocations for the NULL SID if they overlap with Interval Allocations for non-NULL SIDs on other logical channels being serviced by the same PHY. Interval Description Messages for the NULL SID MAY be associated with any currently active logical channel. In contrast to MAP messages, the set of all Interval Description Messages from the MAC taken together need not describe every minislot on the logical channels in question; the MAC MAY refrain from sending Interval Description messages to describe inactive time periods on any or all logical channels. So as to minimize the complexity and buffering requirements of the PHY, the
458

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

MAC MUST sort the Interval Descriptions from all logical channels, putting them into chronological order, and deliver them to the PHY in this order. Note that Interval Description Messages MUST NOT be transferred for the NULL IE, Data Acknowledgement IE's, or Data Grants Pending (since none of these is an Interval Allocation).1 The system is allowed to schedule the Initial Maintenance regions of all logical channels of a physical channel to occur simultaneously. This type of overlap MUST be handled as follows:

The MAC MUST transfer an Interval Description for only one of the logical channels The Interval Description which is transferred MUST be the one with the earliest start time. If more than one
Interval Description has the earliest start time, the MAC MAY choose any of these overlapping interval descriptions to pass to the PHY

The PHY MUST accept any of the logical channel numbers it supports for this interval description
The system software is responsible for knowing that bursts received during initial ranging could be from CMs on any of the logical channels. It is possible for there to be illegal overlap of intervals for the logical channels. An illegal overlap is defined to be an overlap of intervals other than Initial Maintenance. The PHY MAY detect these illegal overlaps. If the PHY performs this function, it MUST generate an interrupt to alert the system of such an event. It MUST capture the illegally overlapped Interval Description and hold it in SPI Bus accessible registers until software acknowledges its receipt. The PSC field of the Interval Description Message is used to control the contents of the PHY_STATUS block. The usage of this field is summarized below:

If PSC = 000, the contents of the PHY_STATUS block is determined through PHY programmable registers. If PSC is any other value, the contents of the PHY_STATUS block are vendor specific
The MAC and PHY MUST support PSC = 000. The MAC and PHY MAY support other values.
H.8.3.2 UCD Change Message

Table H-23 describes the format of the UCD Change Message Payload.
Table H-23 UCD Change PAYLOAD Format
Size (bits) Name Description

CCC

Configuration Change Count from the MAP

The MAC MUST send this message before sending the first Interval Description message after a UCD change. This message MUST NOT be sent at any other time.

1.

Replaced paragraph per ECN RFI2-N-02217, by GO, on 12/03/02.

459

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

H.8.4 SPI Bus

In order to perform an SPI Bus transaction, the master MUST drive SPI_MOSI with a bitstream of the following format:
Table H-24 SPI Bus Transaction Format
Size (bits) Name Description

4 3 1 16 N*8

DEVICE_ID RSVD WRITE REGISTER_ADD WRITE_DATA

Device ID Reserved 1=Write, 0=Read Register Address Write Data; ignored for Reads

The DEVICE_ID is used to address PHY devices which are integrated into the same physical package and share a single SPI select. DEVICE_ID MUST be zero for accesses to single PHY devices.

460

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix I MAC Service Definition

This section is informative. In case of conflict between this section and any normative section of this specification, the normative section takes precedence.

I.1

MAC Service Overview

The DOCSIS MAC provides a protocol service interface to upper-layer services. Examples of upper-layer services include a DOCSIS bridge, embedded applications (e.g., Packetcable/VOIP), a host interface (e.g., NIC adapter with NDIS driver), and layer three routers (e.g., IP router). The MAC Service interface defines the functional layering between the upper layer service and the MAC. As such it defines the functionality of the MAC which is provided by the underlying MAC protocols. This interface is a protocol interface, not a specific implementation interface. The following data services are provided by the MAC service interface:

A MAC service exists for classifying and transmitting packets to MAC service flows. A MAC service exists for receiving packets from MAC service flows. Packets may be received with suppressed headers.

A MAC service exists for transmitting and receiving packets with suppressed headers. The headers of transmitted packets are suppressed based upon matching classifier rules. The headers of received suppressed packets are regenerated based upon a packet header index negotiated between the CM and CMTS.

A MAC service exists for synchronization of grant timing between the MAC and the upper layer service. This
clock synchronization is required for applications such as embedded Packetcable VOIP clients in which the packetization period needs to be synchronized with the arrival of scheduled grants from the CMTS.

A MAC service exists for synchronization of the upper layer clock with the CMTS Controlled Master Clock.
It should be noted that a firewall and policy based filtering service may be inserted between the MAC layer and the upper layer service, but such a service is not modeled in this MAC service definition. The following control services are provided by the MAC service interface:

A MAC service exists for the upper layer to learn of the existence of provisioned service flows and QoS traffic parameter settings at registration time.

A MAC service exists for the upper layer to create service flows. Using this service the upper layer initiates
the admitted/activated QoS parameter sets, classifier rules, and packet suppression headers for the service flow.

A MAC service exists for the upper layer to delete service flows. A MAC service exists for the upper layer to change service flows. Using this service the upper layer modifies
the admitted/activated QoS parameter sets, classifier rules, and packet suppression headers.

A MAC service exists for controlling the classification of and transmission of PDUs with suppressed headers. At most a single suppressed header is defined for a single classification rule. The upper layer service is responsible for defining both the definition of suppressed headers (including wild-card dont-suppress fields) and the unique classification rule that discriminates each header. In addition to the classification rule, the MAC service can perform a full match of all remaining header bytes to prevent generation of false headers if so configured by the upper layer service.

A MAC service exists for controlling two-phase control of QoS traffic resources. Two phase activation is
controlled by the upper layer service provide both admitted QoS parameters and active QoS parameters within the appropriate service request. Upon receipt of an affirmative indication the upper layer service

461

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

knows that the admitted QoS parameter set has been reserved by the CMTS, and that the activated QoS parameter set has been activated by the CMTS. Barring catastrophic failure (such as resizing of the bandwidth of the upstream PHY), admitted resources will be guaranteed to be available for activation, and active resources will be guaranteed to be available for use in packet transmission. A control function for locating an unused service flow and binding it or a specific identified service flow to a specific upper layer service may also exist. The details of such a function are not specified and are implementation dependent. Other control functions may exist at the MAC service interface, such as functions for querying the status of active service flows and packet classification tables, or functions from the MAC service to the upper layer service to enable the upper layer service to authorize service flows requested by the peer MAC layer service, but those functions are not modeled in this MAC service definition. Other MAC services that are not service flow related also exist, such as functions for controlling the MAC service MAC address and SAID multicast filtering functions, but those functions are not modeled in this MAC service definition.
I.1.1 MAC Service Parameters

The MAC service utilizes the following parameters. For a full description of the parameters consult the Theory of Operation and other relevant sections within the body of the RFI specification.

Service Flow QoS Traffic Parameters

MAC activate-service-flow and change-service-flow primitives allow common, upstream, and downstream QoS traffic parameters to be provided. When such parameters are provided they override whatever values were configured for those parameters at provisioning time or at the time the service flow was created by the upper layer service.

Active/Admitted QoS Traffic Parameters

If two-phase service flow activation is being used, then two complete sets of QoS Traffic Parameters are controlled. The admitted QoS Parameters state the requirements for reservation of resources to be authorized by the CMTS. The activated QoS Parameters state the requirements for activation of resources to be authorized by the CMTS. Admitted QoS parameters may be activated at a future time by the upper layer service. Activated QoS parameters may be used immediately by the upper layer service.

Service Flow Classification Filter Rules

Zero or more classification filter rules may be provided for each service flow that is controlled by the upper layer service. Classifiers are identified with a classifier identifier.

Service Flow PHS Suppressed Headers

Zero or more PHS suppressed header strings with their associated verification control and mask variables may be defined for each service flow. When such headers are defined, they are associated 1-to-1 with specific classification rules. In order to regenerate packets with suppressed headers a payload header suppression index is negotiated between the CM and CMTS.

462

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

I.2

MAC Data Service Interface

MAC services are defined for transmission and reception of data to and from service flows. Typically an upper layer service will utilize service flows for mapping of various classes of traffic to different service flows. Mappings to service flows may be defined for low priority traffic, high priority traffic, and multiple special traffic classes such as constant bit rate traffic which is scheduled by periodic grants from the CMTS at the MAC layer. The following specific data service interfaces are provided by the MAC service to the upper layer service. These represent an abstraction of the service provided and do not imply a particular implementation: MAC_DATA.request MAC_DATA.indicate MAC_GRANT_SYNCHRONIZE.indicate MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate
I.2.1 MAC_DATA.request

Issued by the upper-layer service to request classification and transmission of an IEEE 802.3 or [DIX] formatted PDU to the RF. Parameters:

PDU - IEEE 802.3 or [DIX] encoded PDU including all layer two header fields and optional FCS. PDU is the
only mandatory parameter.

padding - is used when the PDU is less than 60 bytes and it is desired to maintain [ISO8802-3] transparency. ServiceFlowID - if included the MAC service circumvents the packet classification function and maps the
packet to the specific service flow indicated by the ServiceFlowID value.

ServiceClassName, RulePriority - if included this tuple identifies the service class name of an active service
flow to which the packet is to be mapped so long as a classifier does not exist at a rule priority higher than the rule priority supplied. Expanded Service Description: Transmit a PDU from upper-layer service to MAC/PHY. The only mandatory parameter is PDU. PDU contains all layer-2 headers, layer-3 headers, data, and (optional) layer-2 checksum. If PDU is the only parameter, the packet is subjected to the MAC packet classification filtering function in order to determine how the packet is mapped to a specific service flow. The results of the packet classification operation determine on which service flow the packet is to be transmitted and whether or not the packet should be transmitted with suppressed headers. If the parameter ServiceFlowID is supplied the packet can be directed to the specifically identified service flow. If the parameter tuple ServiceClassName, RulePriority is supplied the packet is directed to the first active service flow that matches the service class name so long as a classifier does not exist at a rule priority higher than the rule priority supplied. This service is used by upper layer policy enforcers to allow zero or more dynamic rules to be matched for selected traffic (e.g., voice) while all other traffic is forced to a service flow within the named ServiceFlowClass. If no active service flow with the Service Class Name exists, then the service perform normal packet classification. In all cases, if no classifier match is found, or if none of the combinations of parameters maps to a specific service flow, the packet will be directed to the primary service flow.

463

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The following pseudo code describes the intended operation of the MAC_DATA.request service interface: MAC_DATA.request PDU [ServiceFlowID] [ServiceClassName, RulePriority] FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName) returns ServiceFlowID of first service flow whose ServiceClassName equals the parameter of the procedure or NULL if no matching service flow found. SEARCH_CLASSIFIER_TABLE (PriorityRange) searches all rules within the specified priority range and returns either the ServiceFlowID associated with the rule or NULL if no classifier rule found. TxServiceFlowID = NULL IF (ServiceFlowID DEFINED) TxServiceFlowID = MAC_DATA.ServiceFlowID ELSEIF (ServiceClassName DEFINED and RulePriority DEFINED) TxServiceFlowID = FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName) SearchID = SEARCH_CLASSIFIER_TABLE (All Priority Levels) IF (SearchID not NULL and ClassifierRule.Priority >= MAC_DATA.RulePriority) TxServiceFlowID = SearchID ELSE [PDU only] TxServiceFlow = SEARCH_CLASSIFIER_TABLE (All Priority Levels) IF (TxServiceFlowID = NULL) TRANSMIT_PDU (PrimaryServiceFlowID) ELSE TRANSMIT_PDU (TxServiceFlowID)
I.2.2 MAC_DATA.indicate

Issued by the MAC to indicate reception of an IEEE 802.3 or [DIX] PDU for the upper-layer service from the RF. Parameters:

PDU - IEEE 802.3 or [DIX] encoded PDU including all layer two header fields and FCS.
I.2.3 MAC_GRANT_SYNCHRONIZE.indicate

Issued by the MAC service to the upper layer service to indicate the timing of grant arrivals from the CTMS. It is not stated how the upper layer derives the latency if any between the reception of the indication and the actual arrival of grants (within the bounds of permitted grant jitter) from the CMTS. It should be noted that in UGS applications it is expected that the MAC layer service will increase the grant rate or decrease the grant rate based upon the number of grants per interval QoS traffic parameter. It should also be noted that as the number of grants per interval is increased or decreased that the timing of grant arrivals will change also. It should also be noted that when synchronization is achieved with the CMTS downstream master clock, this indication may only be required once per active service flow. No implication is given as to how this function is implemented.

464

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Parameters:

ServiceFlowID - unique identifier value for the specific active service flow receiving grants.
I.2.4 MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate

Issued by the MAC service to the upper layer service to indicate the timing of the CMTS master clock. No implication is given as to how often or how many times this indication is delivered by the MAC service to the upper layer service. No implication is given as to how this function is implemented. Parameters:

No parameters specified.

I.3

MAC Control Service Interface

A collection of MAC services are defined for control of MAC service flows and classifiers. It should be noted that an upper layer service may use these services to provide an upper layer traffic construct such as connections or subflows or micro-flows. However, except for the ability to modify individual classifiers, no explicit semantics is defined for such upper layer models. Thus control of MAC service flow QoS parameters is specified in the aggregate. The following specific control service interface functions are provided by the MAC service to the upper layer service. These represent an abstraction of the service provided and do not imply a particular implementation: MAC_REGISTRATION_RESPONSE.indicate MAC_CREATE_SERVICE_FLOW.request/response/indicate MAC_DELETE_SERVICE_FLOW.request/response/indicate MAC_CHANGE_SERVICE_FLOW.request/response/indicate
I.3.1 MAC_REGISTRATION_RESPONSE.indicate

Issued by the DOSCIS MAC to the upper layer service to indicate the complete set service flows and service flow QoS traffic parameters that have been provisioned and authorized by the registration phase of the MAC. Subsequent changes to service flow activation state or addition and deletion of service flows are communicated to the upper layer service with indications from the other MAC control services. Parameters:

Registration TLVs - any and all TLVs that are needed for service flow and service flow parameter
definition including provisioned QoS parameters. See the normative body of the specification for more details.
I.3.2 MAC_CREATE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request the creation of a new service flow within the MAC service. This primitive is not issued for service flows that are configured and registered, but rather for dynamically created service flows. This primitive may also define classifiers for the service flow and supply admitted and activated QoS parameters. This function invokes DSA signaling. Parameters:

ServiceFlowID - unique id value for the specific service flow being created.

465

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

ServiceClassName - service flow class name for the service flow being created. Admitted QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Activated QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Service Flow Payload Header Suppression Rules - Zero or more PHS rules for each service flow that
is controlled by the upper layer service.

Service Flow Classification Filter Rules - Zero or more classification filter rules for each service
flow that is controlled by the upper layer service. Classifiers are identified with a classifier identifier.
I.3.3 MAC_CREATE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to create a service flow. Parameters:

ServiceFlowID - unique identifier value for the specific service flow being created. ResponseCode - success or failure code
I.3.4 MAC_CREATE_SERVICE_FLOW.indicate

Issued by the MAC service to notify the upper-layer service of the creation of a new service flow within the MAC service. This primitive is not issued for service flows that have been administratively pre-configured, but rather for dynamically defined service flows. In this draft of the specification this notification is advisory only. Parameters:

ServiceFlowID - unique id value for the specific service flow being created. ServiceClassName - service flow class name for the service flow being created. Admitted QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Activated QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Service Flow Payload Header Suppression Rules - Zero or more PHS rules for each service flow that
is controlled by the upper layer service.

Service Flow Classification Filter Rules - Zero or more classification filter rules for each service
flow that is controlled by the upper layer service. Classifiers are identified with a classifier identifier.
I.3.5 MAC_DELETE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request the deletion of a service flow and all QoS parameters including all associated classifiers and PHS rules. This function invokes DSD signaling. Parameters:

ServiceFlowID(s) - unique identifier value(s) for the deleted service flow(s).

466

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

I.3.6 MAC_DELETE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to delete a service flow. Parameters:

ResponseCode - success or failure code

I.3.7 MAC_DELETE_SERVICE_FLOW.indicate

Issued by the MAC service to notify the upper-layer service of deletion of a service flow within the MAC service. Parameters:

ServiceFlowID(s) - unique identifier value(s) for the deleted service flow(s).

I.3.8 MAC_CHANGE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request modifications to a specific created and acquired service flow. This function is able to define both the complete set of classifiers and incremental changes to classifiers (add/remove). This function defines the complete set of admitted and active QoS parameters for a service flow. This function invokes DSC MAC-layer signaling. Parameters:

ServiceFlowID - unique identifier value for the specific service flow being modified. zero or more packet classification rules with add/remove semantics and LLC, IP, and 802.1pq
parameters.

Admitted QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Activated QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Service Flow Payload Header Suppression Rules - Zero or more PHS rules for each service flow that
is controlled by the upper layer service.
I.3.9 MAC_CHANGE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to change a service flow. Parameters:

ServiceFlowID - unique identifier value for the specific service flow being released. ResponseCode - success or failure code

467

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

I.3.10 MAC_CHANGE_SERVICE_FLOW.indicate

Issued by the DOSCIS MAC service to notify upper-layer service of a request to change a service flow. In this specification the notification is advisory only and no confirmation is required before the service flow is changed. Change-service-flow indications are generated based upon DSC signaling. DSC signaling can be originated based upon change-service-flow events between the peer upper-layer service and its MAC service, or based upon network resource failures such as a resizing of the total available bandwidth at the PHY layer. How the upper layer service reacts to forced reductions in admitted or reserved QoS traffic parameters is not specified. Parameters:

ServiceFlowID - unique identifier for the service flow being activated. packet classification rules with LLC, IP, and 802.1pq parameters, and with zero or more
PHS_CLASSIFIER_IDENTIFIERs.

Admitted QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Activated QoS Parameters - zero or more upstream, downstream, and common traffic parameters for
the service flow.

Service Flow Payload Header Suppression Rules - Zero or more PHS rules for each service flow that
is controlled by the upper layer service.

I.4

MAC Service Usage Scenarios

Upper layer entities utilize the services provided by the MAC in order to control service flows and in order to send and receive data packets. The partition of function between the upper-layer-service and the MAC service service is demonstrated by the following scenarios.
I.4.1 Transmission of PDUs from Upper Layer Service to MAC DATA Service

Upper layer service transmits PDUs via the MAC_DATA service. MAC_DATA service classifies transmitted PDUs using the classification table, and transmits the PDUs on
the appropriate service flow. The classification function may also cause the packet header to be suppressed according to a header suppression template stored with the classification rule. It is possible for the upper layer service to circumvent this classification function.

MAC_DATA service enforces all service flow based QoS traffic shaping parameters. MAC_DATA service transmits PDUs on DOCSIS RF as scheduled by the MAC layer.
I.4.2 Reception of PDUs to Upper Layer Service from MAC DATA Service

PDUs are received from the DOCSIS RF. If a PDU is sent with a suppressed header, the header is regenerated before the packet is subjected to further processing. In the CMTS, the MAC_DATA service classifies the PDUs ingress from the RF using the classification table and then polices the QoS traffic shaping and validates addressing as performed by the CM. In the CM, no perpacket service flow classification is required for traffic ingress from the RF. Upper layer service receives PDUs from the MAC_DATA.indicate service.

468

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

I.4.3 Sample Sequence of MAC Control and MAC Data Services

A possible CM-oriented sequence of MAC service functions for creating, acquiring, modifying, and then using a specific service flow is as follows:

MAC_REGISTER_RESPONSE.indicate
Learn of any provisioned service flows and their provisioned QoS traffic parameters.

MAC_CREATE_SERVICE_FLOW.request/response
Create new service flow. This service interface is utilized if the service flow was learned as not provisioned by the MAC_REGISTER_RESPONSE service interface. Creation of a service flow invokes DSA signaling.

MAC_CHANGE_SERVICE_FLOW.request/response
Define admitted and activated QoS parameter sets, classifiers, and packet suppression headers. Change of a service flow invokes DSC signaling.

MAC_DATA.request
Send PDUs to MAC service for classification and transmission.

MAC_DATA.indication
Receive PDUs from MAC service.

MAC_DELETE_SERVICE_FLOW.request/response
Delete service flow. Would likely be invoked only for dynamically created service flows, not provisioned service flows. Deletion of a service flow uses DSD signaling.

469

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

470

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix II Example Preamble Sequence

II.1 Introduction

A programmable preamble superstring, up to 1536 bits long, is part of the channel-wide profile or attributes, common to the all burst profiles on the channel (Section 8.3.3, Table 8-18), but with each burst profile able to specify the start location within this sequence of bits and the length of the preamble (Section 8.3.3, Table 8-19). The first bit of the Preamble Pattern is designated by the Preamble Value Offset as described in Table 8-19, Section 8.3.3. The first bit of the Preamble Pattern is the first bit into the symbol mapper (Figure 6-2 and Figure 6-3), and is the first symbol of the burst (see Section 6.2.13). As an example, per Table 8-19, for Preamble Offset Value = 100, the 101st bit of the preamble superstring is the first bit into the symbol mapper, and the 102nd bit is the second bit into the mapper, and is mapped to Q1, and so. An example 1536-bit-long preamble superstring is given in II.2.

II.2

Example Preamble Sequence

The following is the example1536-bit preamble sequence: Bits 1 through 128: 1100 0011 1111 0000 0011 0011 1111 1100 0011 0011 0000 0011 1100 0000 0011 0000 0000 1110 1101 0001 0001 1110 1110 0101 0010 0101 0010 0101 1110 1110 0010 1110 Bits 129 through 256: 0010 1110 1110 0010 0010 1110 1110 1110 1110 1110 0010 0010 0010 1110 1110 0010 1110 1110 1110 0010 1110 0010 1110 0010 0010 0010 0010 1110 0010 0010 1110 0010 Bits 257 through 384: 0010 1010 0110 0110 0110 1110 1110 1110 0010 1110 0010 1110 0010 1110 0110 1010 0010 1110 1110 1010 0110 1110 0110 0010 0110 1110 1010 1110 0010 1010 0110 0010 Bits 385 through 512: 0010 1110 0110 1110 0010 1010 1010 0110 0010 1110 0110 0110 1110 0010 0010 0110 0010 1110 0010 1010 0010 1110 0110 0010 0010 1010 0010 0110 0010 1010 0010 1010 Bits 513 through 640: 0010 1110 0110 1110 0110 0110 1110 0010 0110 1010 0110 0010 1110 1110 1010 0010 1110 1110 0010 1110 1110 1110 0010 1110 1110 0010 1110 0010 0010 1110 0010 0010

471

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Bits 641 through 768: 1110 1110 1110 0010 0010 0010 1110 0010 1110 1110 1110 1110 0010 0010 1110 0010 1110 0010 0010 0010 1110 1110 0010 0010 0010 0010 1110 0010 0010 0010 0010 1110 Bits 769 through 896: 0011 0000 1111 1100 0000 1100 1111 1111 0000 1100 1100 0000 1111 0000 0000 1100 0000 0000 1111 1111 1111 0011 0011 0011 1100 0011 1100 1111 1100 1111 0011 0000 Bits 897 through 1024: 1100 0011 1111 0000 0011 0011 1111 1100 0011 0011 0000 0011 1100 0000 0011 0000 0000 1110 1101 0001 0001 1110 1110 0101 0010 0101 0010 0101 1110 1110 0010 1110 Bits 1025 through 1152: 0010 1110 1110 0010 0010 1110 1110 1110 1110 1110 0010 0010 0010 1110 1110 0010 1110 1110 1110 0010 1110 0010 1110 0010 0010 0010 0010 1110 0010 0010 1110 0010 Bits 1153 through 1280: 0010 0010 1110 1110 1110 1110 1110 1110 0010 1110 0010 1110 0010 1110 1110 0010 0010 1110 1110 0010 1110 1110 1110 0010 1110 1110 0010 1110 0010 0010 1110 0010 Bits 1281 through 1408 1100 1100 1111 0000 1111 1111 1100 0000 1111 0011 1111 0011 0011 0000 0000 1100 0011 0000 0011 1111 1111 1100 1100 1100 1111 0000 1111 0011 1111 0011 1100 1100 Bits 1409 through 1536: 0011 0000 1111 1100 0000 1100 1111 1111 0000 1100 1100 0000 1111 0000 0000 1100 0000 0000 1111 1111 1111 0011 0011 0011 1100 0011 1100 1111 1100 1111 0011 0000

472

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix III Multiple Upstream Channels

This section is informative. In case of conflict between this section and any normative section of this specification, the normative section takes precedence. Section 9.2 describes support for multiple upstream and multiple downstream channels within a DOCSIS domain. The permutations that a CM may see on the cable segment it is attached to include:

single downstream and single upstream per cable segment single downstream and multiple upstreams per cable segment multiple downstreams and single upstream per cable segment multiple downstreams and multiple upstreams per cable segment

A typical application that will require one upstream and one downstream per CM is web browsing. Web browsing tends to have asymmetrical bandwidth requirements that match closely to the asymmetrical bandwidth of DOCSIS. A typical application that will require access to one of multiple upstreams per CM is IP Telephony. IP Telephony tends to have symmetrical bandwidth requirements. If there is a large concentration of CMs in a geographical area all served by the same fiber node, more than one upstream may be required in order to provide sufficient bandwidth and prevent call blocking. A typical application that will require access to one of multiple downstreams per CM is IP streaming video. IP streaming video tends to have extremely large downstream bandwidth requirements. If there is a large concentration of CMs in a geographical area all served by the same fiber node, more than one downstream may be required in order to provide sufficient bandwidth and to deliver multiple IP Video Streams to multiple CMs. A typical application that will require multiple downstreams and multiple upstreams is when the above applications are combined, and it is more economical to have multiple channels than it is to physically subdivide the HFC network. The role of the CM in these scenarios would be to be able to move between multiple upstreams and between multiple downstreams. The role of the CMTS would be to manage the traffic load to all attached CMs, and balance the traffic between the multiple upstreams and downstreams by dynamically moving the CMs based upon their resource needs and the resources available. This appendix looks at the implementation considerations for these cases. Specifically, the first and last application are profiled. These examples are meant to illustrate one topology and one implementation of that topology.

III.1 Single Downstream and Single Upstream per Cable Segment

This section presents an example of a single downstream channel and four upstream channels. In Figure III-1, the four upstream channels are on separate fibres serving four geographical communities of modems.

473

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

The CMTS has access to the one downstream and all four upstreams, while each CM has access to the one downstream and only one upstream.

CMTS

Downstream Laser & Upstream Receiver fD0 fU0

Fiber Nodes

CMs

fU1

fU2

fU3

Coax

Fiber

Coax

Figure III-1

Single Downstream and Single Upstream Channels per CM

In this topology, the CMTS transmits Upstream Channel Descriptors (UCDs) and MAPs for each of the four upstream channels related to the shared downstream channel. Unfortunately, each CM cannot determine which fiber branch it is attached to because there is no way to convey the geographical information on the shared downstream channel. At initialization, the CM randomly picks a UCD and its corresponding MAP. The CM then chooses an Initial Maintenance opportunity on that channel and transmits a Ranging Request. The CMTS will receive the Ranging Request and will redirect the CM to the appropriate upstream channel identifier by specifying the upstream channel ID in the Ranging Response. The CM MUST then use the channel ID of the Ranging Response, not the channel ID on which the Ranging Request was initiated. This is necessary only on the first Ranging Response received by the CM. The CM SHOULD continue the ranging process normally and proceed to wait for station maintenance IEs. From then on, the CM will be using the MAP that is appropriate to the fiber branch to which it is connected. If the CM ever has to redo initial ranging, it may start with its previous known UCD instead of choosing one at random.

474

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

A number of constraints are imposed by this topology:

All Initial Maintenance opportunities across all fiber nodes must be aligned. If there are multiple logical
upstreams sharing the same spectrum on a fiber, then the Initial Maintenance opportunities for each of the logical upstreams MUST align with the initial Maintenance opportunity of at least one logical upstream with the same center frequency on each fiber node.When the CM chooses a UCD to use and then subsequently uses the MAP for that channel, the CMTS must be prepared to receive a Ranging Request at that Initial Maintenance opportunity. Note that only the initialization intervals must be aligned. Once the CM is successfully ranged on an upstream channel, its activities need only be aligned with other users on the same upstream channel. In Figure III-1, ordinary data transmission and requests for bandwidth may occur independently across the four upstream channels.

All of the upstream channels on different nodes should operate at the same frequency or frequencies unless it
is known that no other upstream service will be impacted due to a CM transmission of a Ranging Request on a wrong frequency during an Initial Maintenance opportunity. If the CM chooses an upstream channel descriptor arbitrarily, it could transmit on the wrong frequency if the selected UCD applied to an upstream channel on a different fiber node. This could cause initial ranging to take longer. However, this might be an acceptable system trade-off in order to keep spectrum management independent between cable segments.

All of the upstream channels may operate at different modulation rates. However, there is a trade-off involved
between the time it takes to acquire ranging parameters and flexibility of upstream channel modulation rate. If upstream modulation rates are not the same, the CMTS would be unable to demodulate the Ranging Request if it was transmitted at the wrong modulation rate for the particular upstream receiver of the channel. The result would be that the CM would retry as specified in the RFI specification and then would eventually try other upstream channels associated with the currently used downstream. Increasing the probability of attempting ranging on multiple channels increases CM initialization time but using different modulation rates on different fiber nodes allows flexibility in setting the degree of burst noise mitigation.

All Initial Maintenance opportunities on different channels may use different burst characteristics so that the
CMTS can demodulate the Ranging Request. Again, this is a trade-off between time to acquire ranging and exercising flexibility in setting physical layer parameters among different upstream channels. If upstream burst parameters for Initial Maintenance are not the same, the CMTS would be unable to demodulate the Ranging Request if it was transmitted with the wrong burst parameters for the particular channel. The result would be that the CM would retry the Ranging Request as specified in the RFI specification and then would eventually try other upstream channels associated with the currently used downstream. Increasing the probability of attempting ranging on multiple channels increases CM initialization time but using different burst parameters for Initial Maintenance on different fiber nodes allows the ability to set parameters appropriate for plant conditions on a specific node.

III.2 Multiple Downstreams and Multiple Upstreams per Cable Segment

This section presents a more complex set of examples of CMs which are served by several downstream channels and several upstream channels and where those upstream and downstream channels are part of one MAC domain. The interaction of initial ranging, normal operation, and Dynamic Channel Change are profiled, as well as the impact of the multiple downstreams using synchronized or unsynchronized timestamps. Synchronized timestamps refer to both downstream paths transmitting a time stamp that is derived from a common clock frequency and have common time bases. The timestamps on each downstream do not have to be transmitted at the same time in order to be considered synchronized.
III.2.1 Topologies

Suppose two downstream channels are used in conjunction with four upstream channels as shown in Figure III-2. In all three topologies, there are two geographical communities of modems, both served by the same two downstream channels. The difference in the topologies is found in their upstream connectivity.
475

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

CMTS fD0

Downstream Laser & Upstream Receiver

Fiber Nodes

CMs

T o p o l o g y #1

fU0 fU1

fD1 fU2 fU3

fD0

T o p o l o g y #2

fU0 fU1

fD1 fU2 fU3

fD0

T o p o l o g y #3

fU0 fU1

fD1 fU2 fU3 Coax Fiber Coax

Figure III-2

Multiple Downstream and Multiple Upstream Channels per CM

476

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Topology #1 has the return path from each fiber node connected to a dedicated set of upstream receivers. A CM will see both downstream channels, but only one upstream channel which is associated with one of the two downstream channels. Topology #2 has the return path from each fiber node combined and then split across all upstream receivers. A CM will see both downstream channels and all four upstream channels in use with both downstream channels. Topology #3 has the return path from each fiber node split and then sent to multiple upstream receivers, each associated with a different downstream channel. A CM will see both downstream channels, and one upstream channel associated with each of the two downstream channels. Topology #1 is the typical topology in use. Movement between downstreams can only occur if the timestamps on both downstreams are synchronized. Topology #2 and Topology #3 are to compensate for downstreams which have unsynchronized timestamps, and allow movement between downstream channels as long as the upstream channels are changed at the same time. The CMs are capable of single frequency receive and single frequency transmit.
III.2.2 Normal Operation

Table III-1 lists MAC messages that contain Channel IDs.

Table III-1 MAC Messages with Channel IDs
MAC Message Downsteam Channel ID Upstream Channel ID

UCD MAP RNG-REQ RNG-RSP DCC-REQ

Yes No Yes No Yes

Yes Yes No Yes Yes

With unsynchronized timestamps:

Since upstream synchronization relies on downstream timestamps, each upstream channel must be associated
with the time stamp of one of the downstream channels.

The downstream channels should only transmit MAP messages and UCD messages that pertain to their associated upstream channels. With synchronized timestamps:

Since upstream synchronization can be obtained from either downstream channel, all upstreams can be associated with any downstream channel.

All MAPs and UCDs for all upstream channels should be sent on all downstream channels. The UCD messages contains a Downstream Channel ID so that the CMTS can determine with the RNG-REQ message which downstream channel the CM is on. Thus the UCD messages on each downstream will contain different Downstream Channel IDs even though they might contain the same Upstream Channel ID.

477

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

III.2.3 Initial Ranging

When a CM performs initial ranging, the topology is unknown and the timestamp consistency between downstreams is unknown. Therefore, the CM chooses either downstream channel and any one of the UCDs sent on that downstream channel. In both cases:

The upstream channel frequencies within a physical upstream or combined physical upstreams must be different.

The constraints specified in Section III.1 apply.

III.2.4 Dynamic Channel Change

With unsynchronized timestamps:

When a DCC-REQ is given, it must contain new upstream and new downstream frequency pairs that are both
associated with the same timestamp.

When the CM resynchronizes to the new downstream, it must allow for timestamp resynchronization without
re-ranging unless instructed to do so with the DCC-REQ command.

Topology #1 will support channel changes between local upstream channels present within a cable segment,
but will not support changes between downstream channels. Topology #2 and #3 will support upstream and downstream channel changes on all channels within the fiber node as long as the new upstream and downstream channel pair are associated with the same timestamp. With synchronized timestamps:

Downstream channel changes and upstream channel changes are independent of each other.
Topologies #1, #2, and #3 will support changes between all upstream and all downstream channels present within the cable segment.

478

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix IV DOCSIS Transmission and Contention Resolution

IV.1 Introduction
This appendix clarifies how the DOCSIS transmission and contention-resolution algorithms work. It contains a few minor simplifications and assumptions, but should be useful to help clarify this area of the specification. The simplifications include:

The text does not explicitly discuss packet arrivals while deferring or waiting for pending grants, nor the
sizing of piggyback requests.

The CM always sends a Piggyback Request for the next frame in the last fragment and not inside one of the
headers of the original frame.1

Much of this applies to concatenation, but no attempt is made to address all the subtleties of that situation.
The assumptions include, among others:

The assumption is made that a Request always fits in any Request/Data region. When a piggyback request is sent with a contention data packet, the state machine only checks for the Grant
to the Request and assumes the Data Ack for the contention data packet was supplied by the CMTS.

Idle
Data Acked OR Too Many Retries OR Map Lost Tx Resv. Data w/o Piggyback

!Queue_Empty Map: Defer Tx Resv. Data w/o Piggyback OR Too Many Retries OR (TX Frag w/o Piggyback && Last)

Tx Cont. Data w/o Piggyback

Deferring TX Frag w/Piggyback OR

(TX Frag w/o Piggyback & !Last) OR Tx Request OR Tx Resv./Cont. Data w/Piggyback OR Grant Pending Retry

Data Ack Pending

Retry Tx Resv. Request

Grant Pending

Grant Pending

Tx Resv. Data w/Piggyback

Figure IV-1 Transmission & Deference State Transition Diagram

1.

This bulleted item added per RFI2-N-02093 by RKV on 10/28/02.

479

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

IV.2 Variable Definitions

Start = Data Backoff Start field from Map currently in effect End = Data Backoff End field from Map currently in effect Window = Current backoff window Random[n] = Random number generator that selects a number between 0 and n-1 Defer = Number of Transmit Opportunities to defer before transmitting Retries = Number of transmissions attempted without resolution Tx_time = Saved time of when Request or Request/Data was transmitted Ack_time = Ack Time field from current Map Piggyback = Flag set whenever a piggyback REQ is added to a transmit pkt Queue_Empty = Flag set whenever the data queue for this SID is empty Lost_Map = Flag set whenever a MAP is lost & were in state Data Ack Pending my_SID = Service ID of the queue that has a packet to transmit pkt size = Data packet size including MAC and physical layer overhead (including piggyback if used) frag_size = Size of the fragment Tx_Mode = {Full_Pkt; First_Frag; Middle_Frag; Last_Frag} min_frag = Size of the minimum fragment

IV.3 State Examples

IV.3.1 Idle Waiting for a Packet to Transmit

Window = 0; Retries = 0; Wait for!Queue_Empty; /* Packet available to transmit */ CalcDefer(); go to Deferring

480

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

IV.3.2

Data Ack Pending Waiting for Data Ack only

Wait for next Map; if (Data Acknowledge SID == my_SID) /* Success! CMTS received data packet */ go to state Idle; else if (Ack_time > Tx_time) /* COLLISION!!! or Pkt Lost or Map Lost */ { if (Lost_Map) go to state Idle; /* Assume pkt was acked to avoid sending duplicates */ else Retry(); } stay in state Data Ack Pending;

IV.3.3

Grant Pending Waiting for a Grant

Wait for next Map; while (Grant SID == my_SID) UtilizeGrant(); if (Ack_time > Tx_time) /* COLLISION!!!!! or Request denied/lost or Map Lost */ Retry(); stay in state Grant Pending

IV.3.4

Deferring Determine Proper Transmission Timing & Transmit

/* Unsolicited Grant */

if (Grant SID == my_SID) { UtilizeGrant(); } else if (unicast Request SID == my_SID) { transmit Request in reservation; Tx_time = time;

/* Unsolicited Unicast Request */

go to state Grant Pending; } else { for (each Request or Request/Data Transmit Opportunity) { if (Defer!= 0) Defer = Defer - 1; /* Keep deferring until Defer = 0 */ else { if (Request/Data tx_op) and (Request/Data size >= pkt size) /* Send data in contention */ { transmit data pkt in contention; Tx_time = time; if (Piggyback) go to state Grant Pending; else go to state Data Ack Pending; } else { transmit Request in contention; /* Send Request in contention */

481

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

Tx_time = time; go to state Grant Pending; } } } } Wait for next Map; stay in state Deferring

IV.4 Function Examples

IV.4.1 CalcDefer() Determine Defer Amount

if (Window < Start) Window = Start; if (Window > End) Window = End; Defer = Random[2^Window];

IV.4.2

UtilizeGrant() Determine Best Use of a Grant

/* CM can send full pkt */

if (Grant size >= pkt size) { transmit packet in reservation; Tx_time = time; Tx_mode = Full_pkt if (Piggyback) go to state Grant Pending else go to state Idle;

} else if (Grant size < min_frag && Grant Size > Request size) /* Cant send fragment, but can send a Request */ { transmit Request in reservation; Tx_time = time; go to state Grant Pending; } else if (Grant size == 0) /* Grant Pending */ go to state Grant Pending; else { while (pkt_size > 0 && Grant SID == my_SID) { if (Tx_mode == Full_Pkt) Tx_mode = First_frag; else Tx_mode = Middle_frag; pkt_size = pkt_size - frag_size; if (pkt_size == 0) Tx_mode = Last_frag; if (another Grant SID == my_SID) piggyback_size = 0 else /* multiple grant mode */

482

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

piggyback_size = pkt_size

/* piggyback mode */

if (piggyback_size > 0) transmit fragment with piggyback request for remainder of packet in reservation else transmit fragment in reservation; } go to state Grant Pending; }

IV.4.3

Retry()

Retries = Retries + 1; if (Retries > 16) { discard pkt, indicate exception condition go to state Idle; } Window = Window + 1; CalcDefer(); go to state Deferring;

483

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

484

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix V IGMP Example

Section 5.3.1 defines the requirements for CMTS and CM support of IGMP signaling. This appendix provides an example CM passive-mode state machine for maintaining membership of a single multicast group.

Idle (No members)

E6/A7

E1/A1

Joining
E5/A7

E1/A2

E4/A6

E2/A4

E1/A3

Joined

E6/A7 E3/A5

Figure V-1

IGMP Support CM passive mode

V.1

Events

E1: MR received on CPE I/f E2: M1 timer expired E3: MQ received on RF I/f E4: MR received on RF I/f E5: M2 timer expired E6: Auth Failure1

1.

SA-MAP response returns an error code of 7 - not authorized for requested downstream traffic flow
485

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

V.2

Actions

A1: MQI= 125 sec; QRI = 10 sec; Start M1 timer with random value between 0 and 3 sec; start M2 timer = 2*MQI+QRI; start TEK machine, if necessary1; add multicast addr to multicast filter A2: discard MR packet A3: reset M2 timer = 2*MQI+QRI; start M1 timer with random value between 0 and 3 sec A4: transmit MR on RF I/f; set I = current time A5: recompute MQI = MAX(125, current time I); set I = current time, forward MQ on CPE i/f A6: cancel M1 timer A7: delete multicast addr from multicast filter

1.

If the multicast traffic is encrypted, a TEK machine needs to be started to decrypt the encrypted multicast packets. To determine whether the multicast is encrypted, the CM makes a SA-MAP request to the CMTS to get the associated SAID of the multicast group address. If the SA-MAP response returns an SAID, then a TEK machine is started. No TEK machine is necessary, if the SA-MAP response indicates that the multicast traffic is not encrypted. The SA-MAP response may also indicate that the CM is not authorized to receive this multicast traffic. In which case, the CM terminates the multicast state machine and stops forwarding the multicast traffic.

486

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix VI Unsolicited Grant Services

This appendix discusses the intended use of the Unsolicited Grant Service (UGS) and Unsolicited Grant Service with Activity Detection (UGS-AD) and includes specific examples.

VI.1
VI.1.1

Unsolicited Grant Service (UGS)

Introduction

Unsolicited Grant Service is an Upstream Flow Scheduling Service Type that is used for mapping constant bit rate (CBR) traffic onto Service Flows. Since the upstream is scheduled bandwidth, a CBR service can be established by the CMTS scheduling a steady stream of grants. These are referred to as unsolicited because the bandwidth is predetermined, and there are no ongoing requests being made. The classic example of a CBR application of interest is Voice over Internet Protocol (VoIP) packets. Other applications are likely to exist as well. Upstream Flow Scheduling Services are associated with Service Flows, each of which is associated with a single Service ID (SID). Each Service Flow may have multiple Classifiers. Each Classifier may be associated with a unique CBR media stream. Classifiers may be added and removed from a Service Flow. Thus, the semantics of UGS must accommodate single or multiple CBR media streams per SID. For the discussion within this appendix, a Subflow will be defined as the output of a Classifier. Since a VoIP session is identified with a Classifier, a Subflow in this context refers to a VoIP session.
VI.1.2 Configuration Parameters

Nominal Grant Interval Unsolicited Grant Size Tolerated Grant Jitter Grants per Interval

Explanations of these parameters and their default values are provided in Annex C.
VI.1.3 Operation

When a Service Flow is provisioned for UGS, the Nominal Grant Interval is chosen to equal the packet interval of the CBR application. For example, VoIP applications with 10 ms packet sizes will require a Nominal Grant Interval of 10 ms. The size of the grant is chosen to satisfy the bandwidth requirements of the CBR application and relates directly to the length of the packet. When multiple Subflows are assigned to a UGS service, multiple grants per interval are issued. There is no explicit mapping of Subflows to grants. The multiple grants per interval form a pool of grants in which any subflow can use any grant. It is assumed in this operational example the default UGS case of no concatenation and no fragmentation.

487

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

VI.1.4

Jitter

Figure VI-1 shows the relationship between Grant Interval and Tolerated Grant Jitter, and shows an example of jitter on subflows.

Nominal Grant Grant Interval Interval

Nominal Grant Grant Interval Interval

Nominal Grant Grant Interval Interval

Max Tolerated Jitter Jitter Grants per SID Subflows 1 t0 2 3 ti

Max Tolerated Jitter Jitter

Max Tolerated Jitter Jitter

1 ti'

2 ti+jitter ti+jitter

Figure VI-1 Example Jitter with Multiple Grants per SID

For only one Grant per Interval, the Tolerated Grant Jitter is the maximum difference between the actual grant time (ti) and the nominal grant time (ti). For multiple Grants per Interval, the Tolerated Grant Jitter is the maximum difference between the actual time of the last grant in the group of grants and the nominal grant time (ti). If the arrival of any grant is at ti, then ti <= ti <= ti+jitter. Figure VI-1 demonstrates how a Subflow will be jittered even though the individual grants may not move from their relative position. During the first interval, three VoIP sessions are established, and they happen fall on the three grants. In the second interval, VoIP session 3 has been torn down. Since the CMTS does not know which Subflow is associated with which grant, it decides to remove the first grant. The remaining two calls shift to the other two grants. In the third interval, a new VoIP session 4 and a new grant have been added. The new call happens to fall on the new grant. The net effect is that the Subflows may move around within their jitter interval. The advantage of a small jitter interval is that the VoIP receive jitter buffer may be kept small. The disadvantage is that this places a scheduling constraint on the CMTS. The boundary of a Nominal Grant Interval is arbitrary and is not communicated between the CMTS and the CM.
Note: More dramatic events like the loss of a downstream MAP, or the frequency hopping of an upstream may cause subflows to jitter outside of this jitter window.

VI.1.5

Synchronization Issues

There are two synchronization problems that occur when carrying CBR traffic such as VoIP sessions across a network. The first is a frequency mismatch between the source clock and the destination clock. This is managed by the VoIP application, and is beyond the scope of this specification. The second is the frequency mismatch between the CBR source/sinks, and the bearer channel that carries them. Specifically, if the clock that generates the VoIP packets towards the upstream is not synchronized with the clock at the CMTS which is providing the UGS service, the VoIP packets may begin to accumulate in the CM. This could also occur if a MAP was lost, causing packets to accumulate.

488

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

When the CM detects this condition, it asserts the Queue Indicator in the Service Flow EH Element. The CMTS will respond by issuing an occasional extra grant so as to not exceed 1% of the provisioned bandwidth. (This corresponds to a maximum of one extra grant every one hundred grants). The CMTS will continue to supply this extra bandwidth until the CM deasserts this bit. A similar problem occurs in the downstream. The far end transmitting source may not be frequency synchronized to the clock which drives the CMTS. Thus the CMTS SHOULD police at a rate slightly higher than the exact provisioned rate to allow for this mismatch and to prevent delay buildup or packet drops at the CMTS.

VI.2
VI.2.1

Unsolicited Grant Service with Activity Detection (UGS-AD)

Introduction

Unsolicited Grant Service with Activity Detection (UGS-AD) is an Upstream Flow Scheduling Service Type. This section describes one application of UGS-AD which is the support for Voice Activity Detection (VAD). VAD is also known as Silence Suppression and is a voice technique in which the transmitting CODEC sends voice samples only when there is significant voice energy present. The receiving CODEC will compensate for the silence intervals by inserting silence or comfort noise equal to the perceived background noise of the conversation. The advantage of VAD is the reduction of network bandwidth required for a conversation. It is estimated that 60% of a voice conversation is silence. With that silence removed, that would allow a network to handle substantially more traffic. Subflows in this context will be described as active and inactive. Both of these states of within the MAC Layer QOS state known as Active.
VI.2.2 MAC Configuration Parameters

The configuration parameters include all of the normal UGS parameters, plus:

Nominal Polling Interval Tolerated Poll Jitter

Explanation of these parameters and their default values are provided in Annex C.
VI.2.3 Operation

When there is no activity, the CMTS sends polled requests to the CM. When there is activity, the CMTS sends Unsolicited Grants to the CM. The CM indicates the number of grants per interval which it currently requires in the active grant field of the UGSH in each packet of each Unsolicited Grant. The CM may request up to the maximum active Grants per Interval. The CM constantly sends this state information so that no explicit acknowledgment is required from the CMTS. It is left to the implementation of the CM to determine activity levels. Implementation options include:

Having the MAC layer service provide an activity timer per Classifier. The MAC layer service would mark a
Subflow inactive if packets stopped arriving for a certain time, and mark a Subflow active the moment a new packet arrived. The number of Grants requested would equal the number of active Subflows.

Having a higher layer service entity such as an embedded media client which indicates activity to the MAC
layer service.

489

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

When the CM is receiving polled requests and it detects activity, the CM requests enough bandwidth for one Grant per Interval. If activity is for more than one Subflow, the CM will indicate this in the active grant field of the UGSH beginning with the first packet it sends. When the CM is receiving Unsolicited Grants, then detects new activity, and asks for one more grant, there will be a delay in time before it receives the new grant. During that delay, packets may build up at the CM. When the new Unsolicited Grant is added, the CMTS will burst extra Grants to clear out the packet buildup. When the CM is receiving Unsolicited Grants, then detects inactivity on a Subflow and asks for one less grant, there will be a delay in time before the reduction in Grants occurs. If there has been any build up of packets in the upstream transmit queue, the extra grants will reduce or empty the queue. This is fine, and keeps system latency low. The relationship of which Subflow is getting which specific grant will also change. This effect appears as low frequency jitter that the far end must manage. When the CM is receiving Unsolicited Grants and detects no activity on any of its Subflows, it will send one packet with the active grants field of the UGSH set to zero grants, and then cease transmission. The CMTS will switch from UGS mode to Real Time Polling mode. When activity is again detected, the CM sends a request in one of these polls to resume delivery of Unsolicited Grants. The CMTS ignores the size of the request and resumes allocating Grant Size grants to the CM. It is not necessary for the CMTS to separately monitor packet activity since the CM does this already. Worst case, if the CMTS misses the last packet which indicated zero grants, the CMTS and CM would be back in sync at the beginning of the next talk spurt. Because of this scenario, when the CM goes from inactive to active, the CM must be able to restart transmission with either Polled Requests or Unsolicited Grants.
VI.2.4 Example

10

20

30

40

50

ms

Voice G.711 CODEC Tx Queue Polled Requests Unsolicited Grants Data on Upstream Play Out

Figure VI-2 VAD Start-Up and Stop

Figure VI-2 shows an example of a single G.711 (64 kbps) voice call with a packet size of 10 ms, and a receive jitter buffer that requires a minimum of 20 ms of voice (thus 2 packets) before it will begin playout.

490

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Assume voice begins at time zero. After a nominal processing delay and a 10 ms packetization delay, the DSP CODEC generates voice packets which are then transferred to the upstream transmit queue. The next Polled Request is used which results in the start of the Unsolicited Grants some time later. Additional Unsolicited Grants are immediately issued to clear out the upstream queue. These packets traverse the network and arrive at the receive jitter buffer. The 20 ms minimum jitter buffer is met when the second packet arrives. Because the packets arrived close together, only an additional few milliseconds of latency has been added. After a nominal processing delay, playout begins. When the voice spurt ends, the CM sends one remaining packet with no payload and with the active grants field of the UGSH set to zero grants. Some time later, UGS stops, and Real Time Polling begins.
VI.2.5 Talk Spurt Grant Burst

The extra burst of Unsolicited Grants when a flow becomes active is necessary because the jitter buffer at the receiving CODEC typically waits to have a minimum amount of voice samples before beginning the playout. Any delay between the arrival of these initial packets will add to the final latency of the phone call. Thus, the sooner the CMTS recognizes that the CM has packets to send and can empty the CMs buffer, the sooner those packet will reach the receiver, and the lower the latency that will be incurred in the phone call. It is an indeterminate problem as to how many grants must be burst. When the CM makes its request for an additional grant, one voice packet has already accumulated. The CM has no idea how many extra grants to request as it has no idea of the round trip response time it will receive from the CMTS, and thus how many packets may accumulate. The CMTS has a better idea, although it does not know the far end jitter buffer requirements. The solution is for the CMTS to choose the burst size, and burst these grants close together at the beginning of the talk spurt. This occurs when moving from Real Time Polling to UGS, and when increasing the number of UGS Grants per Interval. A typical start-up latency that will be introduced by the Request to Grant response time is shown in Table VI-1.
Table VI-1 Example Request to Grant Response Time

Variable 1. The time taken from when the voice packet was created to the time that voice packet arrives in the CM upstream queue. The time until a polled request is received. The worst case time is the Polled Request Interval. The Request-Grant response time of the CMTS. This value is affected by MAP length and the number of outstanding MAPS. The round trip delay of the HFC plant including the downstream interleaving delay.

Example Value 0-1 ms

2. 3.

0-5 5 - 15

ms ms

4.

1-5 6 - 26

ms ms

Total

491

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This number will vary between CMTS implementations, but a reasonable number of extra grants to expect from the example above would be:
Table VI-2 Example Extra Grants for New Talk Spurts
Extra Grants for New Talk Spurts

UGS Interval

10 ms 20 ms 30 ms

2 1 0

Once again it is worth noting that the CMTS and CM cannot and do not associate individual Subflows with individual grants. That means that when current Subflows are active and a new Subflow becomes active, the new Subflow will immediately begin to use the existing pool of grants. This potentially reduces the start up latency of new talk spurts, but increases the latency of the other Subflows. When the burst of grants arrives, it is shared with all the Subflows, and restores or even reduces the original latency. This is a jitter component. The more Subflows that are active, the less impact that adding a new Subflow has.
VI.2.6 Admission Considerations

Note that when configuring the CMTS admission control, the following factors must be taken into account. VAD allows the upstream to be over provisioned. For example, an upstream that might normally handle 24 VoIP sessions might be over provisioned as high as 36 (50%) or even 48 (100%). Whenever there is over provisioning, there exists the statistical possibility that all upstream VoIP sessions may become active. At that time, the CMTS may be unable to schedule all the VoIP traffic. Additionally, the talk spurt grant bursts would be stretched out. CM implementations of VAD should recognize this possibility, and set a limit as to how many packets they will allow to accumulate on its queue. Occasional saturation of the upstream during VAD can be eliminated by provisioning the maximum number of permitted VoIP sessions to be less than the maximum capacity of the upstream with all voice traffic (24 in the previous example). VAD would cause the channel usage to drop from 100% to around 40% for voice, allowing the remaining 60% to be used for data and maintenance traffic.

492

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix VII S-CDMA Framing

This appendix is informative. In case of conflict between this section and any normative section of this specification, the normative section takes precedence. Please note that the pseudo-code below is specific to the case of a single burst using all spreading codes.

VII.1 Coded Subsymbol Numbering

The following code sample contains a short algorithmic description of the operation of the address generator for the coded subsymbols. The address generator for the coded subsymbols fills rows first using the interleaver step size parameter (step in the listing) to step through the spreading intervals within a row. Each step is performed using a modified modulo algorithm which allows the use of interleaver step size and spreading intervals per frame with common divisors. After each row is filled, the next row is begun with the first spreading interval. In the following listings, the index i is initialize to the value 1 and coded_col0 is defined as 0.
for(row = FIRST_ROW; row <= LAST_ROW; row++) { coded_col = 0; store_coded( row, coded_col ); /* Store the coded portion of the symbol (or preamble) to (row,coded_col) */ for( i = 1; i < framelen; i++ ) { coded_col = coded_col + Interleaver_step_size; if( mod( i, framelen / gcd( step, framelen ) ) == 0 ) coded_col = coded_col + 1; /* gcd is greatest common divisor */ coded_col = mod( coded_col, framelen ); store_coded( row, coded_col ); /* Store the coded portion of the symbol (or preamble) to (row,coded_col) */ } }

493

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

VII.2 Uncoded Subsymbol Numbering

The following is a short algorithmic description of the operation of the address generator for uncoded subsymbols. The generator fills columns within a subframe first. The row index increments by one for each uncoded subsymbol. At the end of the subframe, the column index is incremented and the row index set to the first row of the subframe. After completing a subframe, the next subframe begins with the next uncoded subsymbol.
uncoded_col = 0; uncoded_row = FIRST_ROW; while( uncoded_row <= LAST_ROW) { if( ( uncoded_row + R ) > LAST_ROW ) Rprime = LAST_ROW - uncoded_row + 1; else Rprime = R; for( i = 0; i < Rprime; i++) { /* Check whether (uncoded_row,uncoded_col) is a preamble location. * If it is, go to next location */ if( not_preamble( uncoded_row, uncoded_col ) ) store_uncoded( uncoded_row, uncoded_col, unc_sym ); uncoded_row = uncoded_row + 1; } uncoded_row = uncoded_row - Rprime; uncoded_col = uncoded_col + 1; if (uncoded_col >= framelen) { uncoded_col = 0; uncoded_row = uncoded_row + R; } }

FIRST_ROW and LAST_ROW are, respectively, the first and last row (i.e., code) in each frame spanned by the grant. FIRST_ROW can be between 0 and 127 in the first frame of the allocation and is 0 in any other frames that the grant may span (if any). LAST_ROW can be between 0 to 127 in the last frame of the burst and is 127 for any other frame (if any).

VII.3 Framer Output Numbering

The following code sample contains a short algorithmic description of the operation of the address generator for the output symbols. The address generator for the output symbols is used to access both the coded and uncoded subsymbol memories. The output address generator accesses all of the rows (codes) of a spreading interval first followed by subsequent spreading intervals.
for( col=0; col < framelen; col++ ) for( row=0; row < ACTIVE_CODES; row++ ) outsym = get_data( row, col );

VII.4 Comments
In all of the samples, the number of iterations for the loop is not always correct since an allocation can be less than the number of codes. In VII.2, the listing supports the case of a shortened sub-frame.

494

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix VIII Ambient Temperature and Wind Loading Effects

This appendix discusses possible ambient temperature change and dynamic wind loading effects relevant to operating a system with DOCSIS 2.0 CMs and CMTSes. The intent of this appendix is to describe possible approaches for dealing with these issues. The relationships between the timing variation of the received upstream signal and the rate of change of these ambient plant conditions is discussed. However, measured field data providing the statistics of the ambient conditions used in these relationships is not available, so it is not possible at the time of writing to determine the magnitude or frequency of occurrence of these conditions on operational cable systems. This appendix is not intended to be an exhaustive discussion of either these issues or solutions. The following issues are discussed in this appendix:

Synchronization tolerances to plant delay variations Changes in propagation delay due to temperature changes Changes in propagation delay due to wind in the case of aerial cable plant

VIII.1 Synchronization Tolerances to Plant Delay Variations

The CMTS receiver synchronization requirements for S-CDMA and Advanced TDMA are identical for the same signal constellation and symbol rates. However, for S-CDMA, burst synchronization is accomplished to a fine degree through the ranging process, while for TDMA, burst synchronization is accomplished to a coarse degree through the ranging process and then to a fine degree through a receiver burst timing recovery process. In both cases, the degree of timing accuracy required in the receiver is tighter for higher symbol rates and higher-order constellations. Because S-CDMA requires a fine degree of timing accuracy to be accomplished solely by the ranging process, it is more sensitive to changes in the propagation delay of the cable plant between ranging intervals, which can be as much as 30 seconds apart. Table VIII-1 lists plant delay variations that can be accommodated in S-CDMA and TDMA modes for a 1 dB degradation under example conditions. Table VIII-1 Allowable plant timing drift
Allowable peak-peak plant delay variation (ns)S-CDMA mode Allowable peak-peak plant delay variation (ns)TDMA mode

Constellation

Es/No for 1e-8 BER(dB)

Fully-coded QPSK TCM QPSK TCM 8QAM Uncoded QPSK Fully-coded 64QAM TCM 32QAM Uncoded 16QAM Uncoded 32QAM TCM 128QAM Uncoded 64QAM
Defined conditions:

5 9 12 15 17.7 19 22 25 25 28

90 79 57 38 24 18 9 6 6 2

800 N/A N/A 800 800 N/A 800 800 N/A 800

1 dB degradation at 1e-8 BER Uniform ranging offset over 1/64 chip 63 CMs, each with 2 codes Es/No numbers are ideal theoretical values, not including implementation effects
495

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

5.12 MHz modulation rate Timing variation over 30-second period TDMA receiver accepts 2 symbol coarse timing offset (implementation-dependent)
This channel impairment should be considered along with all of the other upstream channel characteristics highlighted in Table 4-2. DOCSIS requires station maintenance at least every 30 seconds (T4 time out has a maximum value of 35 seconds). For S-CDMA at a given modulation and symbol rate, if there exists a rapid propagation delay variation such that the resulting delay change cannot be tracked by station maintenance, then one or more of the following performance trade-offs and/or system changes may be enacted: (1) decrease the station maintenance period, (2) decrease the constellation order, (3) decrease the modulation rate, (4) apply additional error correction, (5) apply some combination of 1 through 4, or (6) change the channel to operate in Advanced TDMA mode.1 The following sections discuss the relationship of temperature changes and wind loading on the propagation delay in coaxial and HFC cable plants.

VIII.2 Change in Propagation Delay Due to Temperature Changes

VIII.2.1 Fiber Delay Changes Due to Temperature

In HFC plant design, the number of amplifiers in cascade in the coax portion is kept low in order to keep signal degradation to an acceptable level. As a result, long runs of cable plant are mainly comprised of fiber. A typical value for propagation delay variation due to temperature change of the fiber is 44 picoseconds per km per degree C [1]. The delay variation comes mostly from the change in refractive index of the glass with temperature, not the change in fiber length. It is assumed that changes in optical cable length due to stretching or expansion will be a negligible factor because optical cables are built to isolate the fiber from stresses in the cable itself. The fiber usually sits loosely in a tube inside the cable and quite a bit of relative movement is possible. This construction allows normal cable handling and aerial deployment without resulting in high stress on the optical fiber. Assuming 44 picoseconds per km per degree C, any product of optical cable length and temperature change which equals 50 results in approximately a 2 nanosecond change in the fiber propagation delay. For example, 25 km fiber and a 2 degree temperature change will result in a 2 ns change in propagation delay. For the maximum distance between CMTS and CM specified in DOCSIS of 100 miles or roughly 160 km, the temperature change needed for a 2 ns second change in one-way propagation delay is 0.3 degree C. Obviously, the issue is how fast the cable core (where the fiber is) will heat up under ambient temperature changes. For buried or underground cable, there is no issue. For aerial cable solar loading changes should be considered. Black sheathed cable has interior temperatures quite a bit higher than ambient in sunlight, but data is currently unavailable. When the rising sun hits aerial cable on a cold morning, one would expect a temperature change. Similarly, sunlight appearing out of cloud cover may have a similar impact although the size of the shadow of the cloud moving out of the way has to be considered. The numerical examples above suggest that only long aerial cable runs may have a problem under some combinations of time-of-day and weather.

1.

Revised this paragraph per ECN RFI2-N-03077 by GO on 07/08/03.

496

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

VIII.2.2

Coaxial Cable Delay Changes Due to Temperature

The coaxial cable has a blown foam between the center conductor and the solid shield, and nominal propagation velocity is about 87% of free space velocity [2]. Propagation velocity does not vary markedly with temperature. Given the relatively short lengths of coaxial cable in most HFC plant (a few miles) this seems unlikely to be a significant source of delay variation.
VIII.2.3 Delay Change Due to Wind

Aerial cable stretches with wind loading, so it is possible to estimate a propagation delay from the change in length under various wind loads. As mentioned, the construction of optical cable makes it tolerant of stretching, so it is assumed that optical cable stretching due to wind loading can be ignored. Wind loading will affect aerial coaxial cables. Wind loading is a difficult to deal with analytically because it is unlikely to be uniform along the cable. A delay model derived from a significant body of measured data is needed to investigate this further. Wind loading may be a source of fast delay variation and station maintenance may not occur at intervals small enough for the ranging mechanism to track this variation accurately. The effects of wind loading on typical cable was investigated with a publicly available program from a coaxial cable manufacturer [3]. These calculations showed that length changes in the range 0.01% and 0.05% are possible for various amounts of wind loading. This converts to significant propagation delay variation. As an example, with 5 miles (8 km) and 0.02% length variation, the change in propagation delay is: (8/3e5)*(1/0.87)*2e-4 seconds = 6 nanoseconds This is a peak value, but the length of coax is quite short and the wind load is moderate. While the time duration over which this delay variation occurs is unspecified, it may be noted that wind gust data is readily available for most cities, and wind gust will be the primary mechanism for wind-based timing changes on cable plants. For example, in New York City at the time of this writing, wind gusts of up to 40 mph are reported while average wind speed is about 10 mph. Hence, over a period of 1 to 4 seconds (the typical wind gust measurement interval), the wind speed changed by 30 mph. Much stronger wind gusts are frequently measured in locations prone to windy conditions.

VIII.3 References
[1] P.R. Trischitta and E.L. Varma, "Jitter in Digital Transmission Systems," Artech House, Norwood, MA, 1989. [2] CommScope catalog for Parameter III cable. (QR cable is listed as 88%.) [3] SpanMaster, available at www.commscope.com/html/community_access_cable.shtml

497

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

498

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix IX Acknowledgments
On behalf of CableLabs I would like to thank the following key contributors to DOCSIS 2.0 for their outstanding and superb contributions to this valuable program. Victor Hou of Juniper Networks (formerly Pacific Broadband) and Yoav Hebron of Conexant led the Physical Layer working groups that rewrote RFI Section 6, and wrote RFI Appendix VII. Ariel Yagil of Texas Instruments, Mike Grimwood of Imedia, Bruce Currivan and Tom Kolze of Broadcom, Hikmet Sari and David Munro of Juniper Networks, David Hull and Shimon Tzukerman of Conexant, Elias Nemer and Hassan Yaghoobi of Intel, and Jack Moran of Motorola participated in those groups. Dan Crocker of Cisco Systems wrote Annex H with contributions from Niki Pantelias of Broadcom, Guy Cohen and Ariel Yagil of Texas Instruments, Rob Fanfelle and Hunter Donahue of Imedia, and John T. Chapman of Cisco Systems. Rich Prodan of Terayon led the OSS working group that developed the new MIB for DOCSIS 2.0 as well as reworking the OSSI specification. Aviv Goren of Terayon, David Raftus of Imedia, Greg Nakanishi of Motorola, Adi Shaliv of Intel, Rich Woundy of Cisco, and Jason Schnitzer of Stargus contributed to that group. Rusty Cashman of Correlant led the MAC layer working group that reworked much of RFI Sections 8, 9, and 11. Jeff Hoffman of Intel; Lisa Denney of Broadcom; Alon Bernstein of Cisco; Gordon Li of Conexant; Asaf Matatyaou of Terayon; Robert Fanfelle of Imedia; David Doan, Christiaan Prins, Leo Zimmerman and Simon Brand of Philips contributed to that working group. Clive Holborow of Motorola led the System Capabilities working group which rewrote RFI Section 3 and Annex G, and contributed to RFI Sections 6, 9, and 11. Daniel Howard of Broadcom, Noam Geri of TI, and Doug Jones of YAS contributed to that group. Clive Holborow of Motorola, Victor Hou of Juniper Networks, Mike Grimwood of Imedia, Bruce Currivan and Daniel Howard of Broadcom, Rich Prodan of Terayon, and Hal Roberts of ADC wrote the informational material in RFI Appendix VIII. David Hull of Conexant, Luc Martens and Wim De Ketelaere of tComLabs, the engineers at UPC, and the EuroDOCSIS Certification Board for their contributions to RFI Annex F. The engineers at Terayon, Imedia, Broadcom, Texas Instruments, and Conexant, as well as the members of the IEEE 802.14a Hi-PHY working group (chaired by Roger Durant of Cabletron (now Riverstone)) developed the technology proposals that became DOCSIS 2.0. George Hart of Rogers Cable, Oleh Sniezko of AT&T Broadband, Dan Rice of Stargus for their guidance and contributions on behalf of CableLabs member companies. I would also like to recognize Greg White, Mukta Kar, John Eng, Doug Jones, Eduardo Cardona, Dorothy Raymond, Alex Ball, and Cynthia Metsker from CableLabs for their leadership and first class work. CableLabs and the cable industry as a whole are grateful to these individuals and organizations for their outstanding, first class contributions.

Rouzbeh Yassini CEO of YAS ventures, LLC Exec Consultant to CableLabs

499

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

This page intentionally left blank.

500

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

Appendix X Revisions
X.1 ECNs included in SP-RFIv2.0-I02-020617
Table X-1 Incorporated ECN Table
ECN Date Accepted Author Summary

rfi2-n-02001 rfi2-n-02002 rfi2-n-02004 rfi2-n-02015 rfi2-n-02020 rfi2-n-02025 rfi2-n-02026 rfi2-n-02027 rfi2-n-02028 rfi2-n-02029 rfi2-n-02031 rfi2-n-02034 rfi2-n-02035 rfi2-n-02038 rfi2-n-02039 rfi2-n-02044 rfi2-n-02047 rfi2-n-02049 rfi2-n-02050 rfi2-n-02052 rfi2-n-02055 rfi2-n-02056 rfi2-n-02057 rfi2-n-02065 rfi2-n-02066 rfi2-n-02070 rfi2-n-02095 rfi2-n-02096 rfi2-n-02100 rfi2-n-02103

02/20/02 02/13/02 02/13/02 02/20/02 02/27/02 04/17/02 03/06/02 04/03/02 03/06/02 03/06/02 04/03/02 03/13/02 03/13/02 03/20/02 03/20/02 03/27/02 04/03/02 04/03/02 04/17/02 05/01/02 04/10//02 04/03/02 05/22/02 04/24/02 05/08/02 05/01/02 05/29/02 05/22/02 05/22/02 05/29/02

Mark Tillinghast Greg White Lisa Denney Greg White Ariel Yagil Bruce Currivan Bruce Currivan Rusty Cashman Bruce Currivan Bruce Currivan Greg White Hassan Yaghoobi Bruce Currivan Margo Dolas Rusty Cashman Yael Barzilai Rusty Cashman Kevin Marez Paul Richardson Mike Grimwood Kaz Ozawa Kaz Ozawa Margo Dolas Efrat Zeharhary Rusty Cashman Margo Dolas Greg White Greg White Dan Crocker Bruce Currivan

Provide consistent description for raised cosine filters. Replace sections 8 and 11. Eliminate burst profile type mixing. Remove 2.0 mode TLV from CMTS MIC. Minor S-CDMA change. Corrections to MER requirements. Add test mode requirements. Clarify amplitude flatness requirements. Clarify preamble support in 1.x bursts. Specify exactly placement of return-to-zero bits. Disable protocols on CPE port. Delete carrier phase randomization of contention bursts. Define bit ordering in figures. Delete initialization techniques. Correct initial ranging channel selection. Bring consistency to authorization/authentication failure responses. REG-ACK clarifications, chapter 11 clarification. Clarify spreader on/off in station maintenance. Clarify the RS interleaver parameters. Clarify transmit pre-EQ coeff. normalization. Clarification of BPI/BPI+ provisioning. Update CM REG-REQ config file settings. Clarify symbol rate inconsistencies. Clarify CM response to an incorrect DCC-REQ. Clarify 2.0 mode registration details. Clarifiy switch between 1.x and 2.0 IUCs. Corrections and clarifications. Add Test Mode config file TLV. Replace Annex H. Correct mini-slot minimum capacity.

501

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

X.2

ECNs included in SP-RFIv2.0-I03-021218

Table X-2 Incorporated ECN Table
ECN Date Accepted Author Summary

rfi2-n-02085 rfi2-n-02089 rfi2-n-02090 rfi2-n-02093 rfi2-n-02102 rfi2-n-02104 rfi2-n-02105 rfi2-n-02111 rfi2-n-02123 rfi2-n-02130 rfi2-n-02135 rfi2-n-02137 rfi2-n-02161 rfi2-n-02145 rfi2-n-02171 rfi2-n-02173 rfi2-n-02178 rfi2-n-02187 rfi2-n-02200 rfi2-n-02210 rfi2-n-02215 rfi2-n-02216 rfi2-n-02217 rfi2-n-02218

06/12/02 07/24/02 06/12/02 07/31/02 08/07/02 07/03/02 06/05/02 06/12/02 07/10/02 07/10/02 08/14/02 08/14/02 08/21/02 8/14/02 08/14/02 09/18/02 10/09/02 11/06/02 11/20/02 11/20/02 11/27/02 11/27/02 11/27/02 11/27/02

Andre Lejeune Shane Keck Rusty Cashman Zvi Shteingart Daniel Howard Bruce Currivan Elias Nemer Hassan Yaghoobi Margo Dolas Margo Dolas Hassan Yaghoobi Hans Wambach Greg Nakanishi Greg White Greg White Greg White Victor Hou Joe Andonieh Matt Schmitt Greg White Andre Lejeune Andre Lejeune Dan Crocker Dan Crocker

Resolve contradicting definitions of guard time. Explicitly state the burst descriptors that must be present in a valid UCD. Clarify what should happen if Maximum Traffic Burst is less than Maximum Concatenated Burst. Clarify use of Piggy Back requests during fragmentation and concatenation. Create CM test mode for testing phase noise and jitter of CM carrier and symbol timing. Clarify description of user-unique burst parameters. Rectify inconsistency in CDMA transmit power example in section 6.2.18.2. Clarify mechanism of RS zero filling in presence of TCM returnto-zero bits. Clarify code hopper synchronization after a UCD change. Correct typographical error in ECN# RFI2-N-02070. Address and clarify zero filling mechanism in CM transmitter when R-S FEC is disabled. Replace Annex F, Euro-DOCSIS; editorial changes and one new requirement. Clarify packet forwarding requirement. Correct editorial error in Figure 11-48. NOTE: This ECN superseded by rfi2-n-02171. Clarify CM forwarding rules, particularly for frames that arrive from a higher-layer embedded application. Delete requirement to set Guard Time for SCDMA channels. Specify CM timing offsets when making modulation rate changes. Clarify reaction of DSx Dynamic state machines. Apply classifier parameter requirement clarifications. Make corrections and clarifications. Correct two figures that contradict the text by requiring backoff on first transmission. Allow for the absence of some non-critical options in a DHCP renew or rebind. Clarify/change functionality related to the use of Interval Description Messages. Specify the maximum latency of Interval Description Message delivery.

502

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

X.3

ECNs included in SP-RFIv2.0-I04-030730

Table X-3 Incorporated ECN Table
ECN Date Accepted Author Summary

RFI2-N-02226 RFI2-N-02227 RFI2-N-02238

12/11/02 03/12/03 01/29/03

David Pullen Yoav Hebron Efrat Zeharhary

Clarify that the Service Identifier (SID) TLV must not be included for downstream service flows. Improve recovery time from a temporary loss of downstream signal in SCDMA mode. RFI2-N-02070 added a confirmation code that is unique to DCC-RSP and is not possible to send on the target channel in a normal DCC operation. This restricts the sending of this message to a possible scenario. Clarify behavior of both the CM and CMTS between completion of registration and completion of BPI initialization This ECR clarifies the ranging continue operation of DOCSIS2.0 CMs and DOCSIS2.0 CMTSs to allow for PacketCable compatibility. Relax timing accuracy requirements after modulation rate change in S-CDMA mode. Correct clarification of the DSx Dynamic state machines reaction A reference to RFC-3256 was omitted from the description of DCI-RSP and the CMTS requirement for DHCP Option 82 support. The CM should not be required to wait for all keying material for all SIDs/SAIDs to be obtained to forward CPE traffic. Correct Clarification of the DSx Dynamic state machines reaction. Corrections and clarifications Add requirements for CM recovery from loss of DS sync.

RFI2-N-02239 RFI2-N-03016

02/05/03 02/26/03

Rusty Cashman Lisa Denney

RFI2-N-03018 RFI2-N-03050 RFI2-N-03063

03/05/03 05/14/03 07/02/03

Ariel Yagil Lucy Pollak Greg White

RFI2-N-03073 RFI2-N-03075 RFI2-N-03077 RFI2-N-03078

07/02/03 07/02/03 07/02/03 07/02/03

Shane Keck Lina Nakhle Greg White Greg White

503

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

X.4

ECNs included in SP-RFIv2.0-I05-040407

Table X-4 Incorporated ECN Table
ECN Date Accepted Author Summary

RFI2-N-03085 RFI2-N-03093

8/20/03 10/8/03

Greg White Minnie Lu

The DHCP retry mechanism was not clearly stated in the RFI specification. When calculating service flow bytes count, use the actual size of packet sent or received even when the size of packet is smaller than "Assumed Minimum Reserved Rate Packet Size". Insert the correct version of Fig 11-47, DSC Remotely Initiated Transaction Begin State Flow Diagram. Deterministic QI flag behavior for UGS Service Flows UCD Substitution and same US channel IDs for DCC Make SID required for INIT-RNG-REQ match that for RNGREQ in the case that the CM is changing upstream channel before registered IGMP rules must still be supported, even when in 1.0 mode, by adding a MUST statement to Annex G of the RFIv2.0. Add a SHOULD statement for CMs in Active IGMP mode in order to minimize potential interruptions in multicast services This ECR introduces a new Config File TLV (Downstream Channel List) to give the operator some control over CM scanning behavior. Clarified post-registration group re-assignment. Prohibited the CMTS from sending a non-2.0 capable CM to a 2.0-only channel; Clarified that load balancing config file TLVs are not to be nested; Clarified that a 2.0 CM with 2.0 disabled will reject a DCC-REQ that sends it to a Type 3 channel (unless init tech=0); Moved DCC state transition diagrams to a separate subsection; Added PICs, and added some minor clarifications to the text. A new DSG ECR defines a DSG Advanced Mode which uses a new DOCSIS MAC management message called DCD. The DSG spec contains all the operating information for DCD, but the DOCSIS spec has to be modified to define the value of the message

RFI2-N-03100 RFIv2.0-N03.0110-2 RFIv2.0-N03.0111-4 RFIv2.0-N03.0118-1 RFIv2.0-N03.0119-2 RFIv2.0-N03.0120-2 RFIv2.0-N03.0086-7 RFIv2.0-N04.0125-5

10/29/03 12/3/03 12/3/03 1/21/04

Ian Wheelock Matt Schmitt Matt Schmitt Yashun Bai

1/21/04 1/21/04 3/3/04

Matt Schmitt Matt Schmitt Matt Schmitt

3/10/04

Greg White

RFIv2.0-N04.0128-1

3/10/04

John T. Chapman

X.5

ECNs included in CM-SP-RFIv2.0-I06-040804

Table X-5 Incorporated ECN Table
ECN Date Accepted Author Summary

RFIv2.0-N04.0143-4 RFIv2.0-N04.0147-1

7/7/04 6/16/04

Matt Schmitt Lucy Pollak

Static Provisioning of Multicast Traffic on CMs Resolve spec hole issue in DSX state matching

504

Radio Frequency Interface Specification

CM-SP-RFIv2.0-I07-041210

X.6

ECNs included in CM-SP-RFIv2.0-I07-041210

Table X-6 Incorporated ECN Table
ECN Date Accepted Author Summary

RFIv2.0-N04.0167-2 RFIv2.0-N04.0177-2 RFIv2.0-N04.0181-3 RFIv2.0-N04.0191-2

9/15/04 10/13/04 11/3/04 11/11/04

Greg White Matt Schmitt Margo Dolas Ben Bekele

Introduces MSC feature to increase power per code in certain SCDMA scenarios Mandatory CMTS support for Concat, Frag, and PHS Clarifications of Downstream Channel List Mandatory CMTS support for Service Class Name (SCN)

505

CM-SP-RFIv2.0-I07-041210

Data-Over-Cable Service Interface Specifications

506