Docsis Radio Frecuencia Especificaciones

Data-Over-Cable Service Interface Specifications
DOCSIS 2.0
Radio Frequency Interface Specification
CM-SP-RFIv2.0-C02-090422
CLOSED
SPECIFICATION
Notice
This DOCSIS specification is the result of a cooperative effort
undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. This document may
contain references to other documents not owned or controlled by
CableLabs. Use and understanding of this document may require
access to such other documents. Designing, manufacturing, distributing,
using, selling, or servicing products, or providing services, based on this
document may require intellectual property licenses from third parties for
technology referenced in this document.
Neither CableLabs nor any member company is responsible to any party
for any liability of any nature whatsoever resulting from or arising out of
use or reliance upon this document, or any document referenced herein.
This document is furnished on an "AS IS" basis and neither CableLabs
nor its members provides any representation or warranty, express or
implied, regarding the accuracy, completeness, noninfringement, or
fitness for a particular purpose of this document, or any document
referenced herein.
Copyright 1999-2009 Cable Television Laboratories, Inc.
All rights reserved.
CM-SP-RFIv2.0-C02-090422
Document Status Sheet

Document Control Number
Document Title
Revision History
Date
CM-SP-RFIv2.0-C02-090422
I01 - December 31, 2001
I02 - June 17, 2002
I03 - December 18, 2002
I04 - July 30, 2003
I05 - April 7, 2004
I06 - August 4, 2004
I07 - December 10, 2004
I08 - April 8, 2005
I09 - August 12, 2005
I10 - December 9, 2005
I11 - June 2, 2006
I12 - December 6, 2007
I13 - February 15, 2008
C01 - November 4, 2008
C02 - April 22, 2009
April 22, 2009
Status
Distribution Restrictions
Work in
Progress
Draft
Issued
Closed
Author Only
CL/Member
CL/ Member/
Public
Vendor
Key to Document Status Codes

Work in Progress
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

Members 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
CableLabs, DOCSIS, EuroDOCSIS, eDOCSIS, M-CMTS, PacketCable, EuroPacketCable,
PCMM, CableHome, CableOffice, OpenCable, OCAP, CableCARD, M-Card, DCAS, tru2way,
and CablePC are trademarks of Cable Television Laboratories, Inc.
ii
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table of Contents
1
RADIO FREQUENCY INTERFACE SPECIFICATION ..............................................................................1

1.1
Scope and Purpose.........................................................................................................................................1
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 ....................................................................................................3
1.3.4
Statement of Compatibility ....................................................................................................................4
1.4
Conventions for this Specification.................................................................................................................4
REFERENCES (NORMATIVE/INFORMATIVE) .........................................................................................5
GLOSSARY (INFORMATIVE) ......................................................................................................................10
FUNCTIONAL ASSUMPTIONS ....................................................................................................................25

4.1
Broadband Access Network ........................................................................................................................25
4.2
Equipment Assumptions..............................................................................................................................25
4.2.1
Frequency Plan....................................................................................................................................25
4.2.2
Compatibility with Other Services .......................................................................................................26
4.2.3
Fault Isolation Impact on Other Users................................................................................................26
4.2.4
Cable System Terminal Devices ..........................................................................................................26
4.3
RF Channel Assumptions ............................................................................................................................26
4.3.1
Transmission Downstream ..................................................................................................................26
4.3.2
Transmission Upstream .......................................................................................................................27
4.4
Transmission Levels ....................................................................................................................................28
4.5
Frequency Inversion ....................................................................................................................................28
COMMUNICATION PROTOCOLS ..............................................................................................................29

5.1
Protocol Stack..............................................................................................................................................29
5.1.1
CM and CMTS as Hosts ......................................................................................................................29
5.1.2
Data Forwarding Through the CM and CMTS ...................................................................................30
5.2
The MAC Forwarder ...................................................................................................................................33
5.2.1
Rules for Data-Link-Layer Forwarding ..............................................................................................34
5.3
Network Layer.............................................................................................................................................34
5.3.1
Requirements for IGMP Management.................................................................................................35
5.4
Above the Network Layer ...........................................................................................................................37
5.5
Data Link Layer...........................................................................................................................................37
5.5.1
LLC Sublayer.......................................................................................................................................38
5.5.2
Link-Layer Security Sublayer ..............................................................................................................38
5.5.3
MAC Sublayer......................................................................................................................................38
5.6
Physical Layer .............................................................................................................................................38
5.6.1
Downstream Transmission Convergence Sublayer .............................................................................38
5.6.2
PMD Sublayer .....................................................................................................................................39
PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION .........................................................40

6.1
Scope ...........................................................................................................................................................40
6.2
Upstream......................................................................................................................................................40
6.2.1
Overview..............................................................................................................................................40
6.2.2
Signal Processing Requirements .........................................................................................................41
6.2.3
Modulation Formats ............................................................................................................................43
04/22/09
CableLabs
iii
CM-SP-RFIv2.0-C02-090422
6.2.4
R-S Encode ..........................................................................................................................................44
6.2.5
R-S Frame Structure ............................................................................................................................44
6.2.6
TDMA Byte Interleaver........................................................................................................................46
6.2.7
Scrambler (Randomizer)......................................................................................................................49
6.2.8
TCM Encoder ......................................................................................................................................50
6.2.9
Preamble Prepend ...............................................................................................................................53
6.2.10 Modulation Rates.................................................................................................................................53
6.2.11 S-CDMA Framer and Interleaver........................................................................................................54
6.2.12 S-CDMA Framer .................................................................................................................................60
6.2.13 Symbol Mapping ..................................................................................................................................63
6.2.14 S-CDMA Spreader ...............................................................................................................................71
6.2.15 Transmit Pre-Equalizer .......................................................................................................................73
6.2.16 Spectral Shaping..................................................................................................................................75
6.2.17 Relative Processing Delays .................................................................................................................75
6.2.18 Transmit Power Requirements ............................................................................................................76
6.2.19 Burst Profiles .......................................................................................................................................81
6.2.20 Burst Timing Convention.....................................................................................................................86
6.2.21 Fidelity Requirements ..........................................................................................................................87
6.2.22 Upstream Demodulator Input Power Characteristics.........................................................................94
6.2.23 Upstream Electrical Output from the CM ...........................................................................................95
6.3
Downstream.................................................................................................................................................95
6.3.1
Downstream Protocol..........................................................................................................................95
6.3.2
Scalable Interleaving to Support Low Latency....................................................................................95
6.3.3
Downstream Frequency Plan ..............................................................................................................96
6.3.4
CMTS Output Electrical ......................................................................................................................96
6.3.5
Downstream Electrical Input to CM....................................................................................................97
6.3.6
CM BER Performance .........................................................................................................................97
6.3.7
CMTS Timestamp Jitter .......................................................................................................................98
6.3.8
CMTS Clock Generation......................................................................................................................99
6.3.9
CMTS Downstream Symbol Clock Jitter for Synchronous Operation...............................................100
6.3.10 CMTS Downstream Symbol Clock Drift for Synchronous Operation ...............................................101
7
DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ......................................................102

7.1
Introduction ...............................................................................................................................................102
7.2
MPEG Packet Format ................................................................................................................................102
7.3
MPEG Header for DOCSIS Data-Over-Cable ..........................................................................................103
7.4
MPEG Payload for DOCSIS Data-Over-Cable .........................................................................................103
7.4.1
stuff_byte............................................................................................................................................103
7.4.2
pointer_field.......................................................................................................................................103
7.5
Interaction with the MAC Sublayer...........................................................................................................104
7.6
Interaction with the Physical Layer ...........................................................................................................105
7.7
MPEG Header Synchronization and Recovery .........................................................................................105
MEDIA ACCESS CONTROL SPECIFICATION.......................................................................................106

8.1
Introduction ...............................................................................................................................................106
8.1.1
Overview............................................................................................................................................106
8.1.2
Definitions .........................................................................................................................................106
8.1.3
Future Use .........................................................................................................................................109
8.2
MAC Frame Formats.................................................................................................................................109
8.2.1
Generic MAC Frame Format ............................................................................................................109
8.2.2
Packet-Based MAC Frames...............................................................................................................113
8.2.3
ATM Cell MAC Frames .....................................................................................................................114
8.2.4
Reserved PDU MAC Frames.............................................................................................................114
8.2.5
MAC-Specific Headers ......................................................................................................................114
8.2.6
Extended MAC Headers ....................................................................................................................119
iv
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
8.2.7
Fragmented MAC Frames .................................................................................................................124
8.2.8
Error-Handling..................................................................................................................................125
8.3
MAC Management Messages....................................................................................................................127
8.3.1
MAC Management Message Header .................................................................................................127
8.3.2
Time Synchronization (SYNC) ...........................................................................................................129
8.3.3
Upstream Channel Descriptor (UCD)...............................................................................................130
8.3.4
Upstream Bandwidth Allocation Map (MAP)....................................................................................137
8.3.5
Ranging Request (RNG-REQ) ...........................................................................................................139
8.3.6
Ranging Response (RNG-RSP)..........................................................................................................141
8.3.7
Registration Request (REG-REQ) .....................................................................................................146
8.3.8
Registration Response (REG-RSP)....................................................................................................147
8.3.9
Registration Acknowledge (REG-ACK).............................................................................................151
8.3.10 Upstream Channel Change Request (UCC-REQ) .............................................................................152
8.3.11 Upstream Channel Change Response (UCC-RSP)............................................................................152
8.3.12 Dynamic Service Addition Request (DSA-REQ) ...........................................................................153
8.3.13 Dynamic Service Addition Response (DSA-RSP)..........................................................................155
8.3.14 Dynamic Service Addition Acknowledge (DSA-ACK)...................................................................157
8.3.15 Dynamic Service Change Request (DSC-REQ) ............................................................................158
8.3.16 Dynamic Service Change Response (DSC-RSP)...........................................................................159
8.3.17 Dynamic Service Change Acknowledge (DSC-ACK)....................................................................161
8.3.18 Dynamic Service Deletion Request (DSD-REQ)...........................................................................162
8.3.19 Dynamic Service Deletion Response (DSD-RSP)...........................................................................163
8.3.20 Dynamic Channel Change Request (DCC-REQ) ...........................................................................163
8.3.21 Dynamic Channel Change Response (DCC-RSP)..........................................................................170
8.3.22 Dynamic Channel Change Acknowledge (DCC-ACK)...................................................................172
8.3.23 Device Class Identification Request (DCI-REQ)...............................................................................172
8.3.24 Device Class Identification Response (DCI-RSP) .............................................................................173
8.3.25 Upstream Transmitter Disable (UP-DIS) MAC Management Message............................................175
8.3.26 Initial Ranging Request (INIT-RNG-REQ)........................................................................................176
8.3.27 Test Request (TST-REQ)....................................................................................................................178
9
MEDIA ACCESS CONTROL PROTOCOL OPERATION.......................................................................180

9.1
Upstream Bandwidth Allocation ...............................................................................................................180
9.1.1
The Allocation MAP MAC Management Message ............................................................................181
9.1.2
Information Elements.........................................................................................................................181
9.1.3
Requests .............................................................................................................................................183
9.1.4
Information Element Feature Usage Summary .................................................................................185
9.1.5
Map Transmission and Timing ..........................................................................................................185
9.1.6
Protocol Example ..............................................................................................................................186
9.1.7
MAP Generation Example - Two Logical Upstreams .......................................................................187
9.2
Support for Multiple Channels ..................................................................................................................187
9.3
Timing and Synchronization......................................................................................................................188
9.3.1
Global Timing Reference...................................................................................................................188
9.3.2
CM Channel Acquisition....................................................................................................................189
9.3.3
Ranging..............................................................................................................................................189
9.3.4
Timing Units and Relationships.........................................................................................................190
9.4
Upstream Transmission and Contention Resolution..................................................................................192
9.4.1
Contention Resolution Overview .......................................................................................................192
9.4.2
Transmit Opportunities......................................................................................................................193
9.4.3
CM Bandwidth Utilization .................................................................................................................194
9.5
Data Link Encryption Support...................................................................................................................194
9.5.1
MAC Messages ..................................................................................................................................194
9.5.2
Framing .............................................................................................................................................194
10
QUALITY OF SERVICE AND FRAGMENTATION ............................................................................195
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
10.1 Theory of Operation ..................................................................................................................................195

10.1.1 Concepts ............................................................................................................................................196
10.1.2 Object Model .....................................................................................................................................200
10.1.3 Service Classes ..................................................................................................................................201
10.1.4 Authorization .....................................................................................................................................202
10.1.5 Types of Service Flows ......................................................................................................................203
10.1.6 Service Flows and Classifiers............................................................................................................205
10.1.7 General Operation.............................................................................................................................206
10.2 Upstream Service Flow Scheduling Services ............................................................................................209
10.2.1 Unsolicited Grant Service..................................................................................................................210
10.2.2 Real-Time Polling Service .................................................................................................................211
10.2.3 Unsolicited Grant Service with Activity Detection ............................................................................211
10.2.4 Non-Real-Time Polling Service .........................................................................................................212
10.2.5 Best Effort Service .............................................................................................................................212
10.2.6 Other Services....................................................................................................................................212
10.2.7 Parameter Applicability for Upstream Service Scheduling...............................................................212
10.2.8 CM Transmit Behavior ......................................................................................................................213
10.3 Fragmentation............................................................................................................................................213
10.3.1 CM Fragmentation Support...............................................................................................................213
10.3.2 CMTS Fragmentation Support ..........................................................................................................216
10.3.3 Fragmentation Example ....................................................................................................................217
10.4 Payload Header Suppression .....................................................................................................................221
10.4.1 Overview............................................................................................................................................221
10.4.2 Example Applications ........................................................................................................................222
10.4.3 Operation...........................................................................................................................................222
10.4.4 Signaling............................................................................................................................................224
10.4.5 Payload Header Suppression Examples ............................................................................................225
11
CABLE MODEM - CMTS INTERACTION............................................................................................228
11.1 CMTS Initialization ...................................................................................................................................228

11.2 Cable Modem Initialization .......................................................................................................................228
11.2.1 Scanning and Synchronization to Downstream .................................................................................230
11.2.2 Obtain Upstream Parameters............................................................................................................232
11.2.3 Message Flows During Scanning and Upstream Parameter Acquisition .........................................235
11.2.4 Ranging and Automatic Adjustments.................................................................................................236
11.2.5 Device Class Identification................................................................................................................240
11.2.6 Establish IP Connectivity ..................................................................................................................240
11.2.7 Establish Time of Day........................................................................................................................241
11.2.8 Transfer Operational Parameters .....................................................................................................242
11.2.9 Registration .......................................................................................................................................242
11.2.10
Baseline Privacy Initialization.......................................................................................................247
11.2.11
Service IDs During CM Initialization............................................................................................248
11.2.12
Multiple-Channel Support .............................................................................................................248
11.3 Standard Operation ....................................................................................................................................249
11.3.1 Periodic Signal Level Adjustment......................................................................................................249
11.3.2 Changing Upstream Channel Descriptor Message Parameters .......................................................251
11.3.3 Changing Upstream Channels...........................................................................................................252
11.4 Dynamic Service........................................................................................................................................255
11.4.1 Dynamic Service Flow State Transitions...........................................................................................256
11.4.2 Dynamic Service Addition .................................................................................................................265
11.4.3 Dynamic Service Change...................................................................................................................276
11.4.4 Dynamic Service Deletion .................................................................................................................286
11.4.5 Dynamically Changing Downstream and/or Upstream Channels ....................................................291
11.5 Fault Detection and Recovery ...................................................................................................................315
11.5.1 Prevention of Unauthorized Transmissions.......................................................................................316
vi
CableLabs
04/22/09
12
CM-SP-RFIv2.0-C02-090422
SUPPORTING FUTURE NEW CABLE MODEM CAPABILITIES....................................................317
12.1
12.2
Downloading Cable Modem Operating Software .....................................................................................317

Future Capabilities.....................................................................................................................................317
ANNEX A
WELL-KNOWN ADDRESSES......................................................................................................318
A.1
MAC Addresses.........................................................................................................................................318
A.2
MAC Service IDs ......................................................................................................................................318
A.2.1
All CMs and No CM Service IDs .......................................................................................................318
A.2.2
Well-Known Multicast Service IDs....................................................................................................318
A.2.3
Priority Request Service IDs..............................................................................................................319
A.3
MPEG PID.................................................................................................................................................319
ANNEX B
PARAMETERS AND CONSTANTS ............................................................................................320
ANNEX C
COMMON RADIO FREQUENCY INTERFACE ENCODINGS..............................................322
C.1
Encodings for Configuration and MAC-Layer Messaging........................................................................322
C.1.1
Configuration File and Registration Settings ....................................................................................322
C.1.2
Configuration-File-Specific Settings .................................................................................................335
C.1.3
Registration-Request/Response-Specific Encodings..........................................................................340
C.1.4
Dynamic-Service-Message-Specific Encodings.................................................................................345
C.2
Quality-of-Service-Related Encodings ......................................................................................................346
C.2.1
Packet Classification Encodings .......................................................................................................346
C.2.2
Service Flow Encodings ....................................................................................................................354
C.3
Encodings for Other Interfaces..................................................................................................................370
C.3.1
Telephone Settings Option.................................................................................................................370
C.3.2
Baseline Privacy Configuration Settings Option...............................................................................370
C.4
Confirmation Code ....................................................................................................................................370
C.4.1
Confirmation Codes for Dynamic Channel Change..........................................................................372
C.4.2
Confirmation Codes for Major Errors...............................................................................................372
ANNEX D
CM CONFIGURATION INTERFACE SPECIFICATION........................................................374
D.1
CM IP Addressing .....................................................................................................................................374
D.1.1
DHCP Fields Used by the CM...........................................................................................................374
D.2
CM Configuration......................................................................................................................................375
D.2.1
CM Binary Configuration File Format .............................................................................................375
D.2.2
Configuration File Settings................................................................................................................376
D.2.3
Configuration File Creation ..............................................................................................................378
D.3
Configuration Verification ........................................................................................................................379
D.3.1
CMTS MIC Calculation.....................................................................................................................379
ANNEX E
THE DATA-OVER-CABLE SPANNING TREE PROTOCOL .................................................381
E.1
Background................................................................................................................................................381
E.2
Public Spanning Tree.................................................................................................................................381
E.3
Public Spanning Tree Protocol Details......................................................................................................382
E.4
Spanning Tree Parameters and Defaults....................................................................................................383
E.4.1
Path Cost ...........................................................................................................................................383
E.4.2
Bridge Priority...................................................................................................................................384
ANNEX F
EUROPEAN SPECIFICATION ADDITIONS.............................................................................385
F.1
Scope and Purpose.....................................................................................................................................385
F.2
References .................................................................................................................................................385
F.3
Glossary.....................................................................................................................................................385
F.4
Functional Assumptions ............................................................................................................................385
F.4.1
Broadband access network ................................................................................................................385
04/22/09
CableLabs
vii
CM-SP-RFIv2.0-C02-090422
F.4.2
Equipment Assumptions.....................................................................................................................386
F.4.3
RF Channel Assumptions...................................................................................................................386
F.4.4
Transmission Levels...........................................................................................................................388
F.4.5
Frequency Inversion ..........................................................................................................................388
F.5
Communication Protocols .........................................................................................................................388
F.6
Physical Media Dependent Sublayer Specification ...................................................................................389
F.6.1
Scope..................................................................................................................................................389
F.6.2
Upstream ...........................................................................................................................................389
F.6.3
Downstream.......................................................................................................................................405
F.7
Downstream transmission convergence sublayer ......................................................................................410
F.7.1
Introduction .......................................................................................................................................410
F.7.2
MPEG Packet format.........................................................................................................................410
F.7.3
MPEG Header for Euro-DOCSIS Data-Over-Cable ........................................................................410
F.7.4
MPEG Payload for Euro-DOCSIS Data-Over-Cable .......................................................................410
F.7.5
Interaction with the MAC sublayer....................................................................................................411
F.7.6
Interaction with the Physical layer....................................................................................................411
F.7.7
MPEG Header synchronization and recovery...................................................................................411
F.8
Media Access Control Specification..........................................................................................................411
F.8.1
Introduction .......................................................................................................................................411
F.8.2
MAC Frame Formats.........................................................................................................................411
F.8.3
MAC Management Messages ............................................................................................................411
ANNEX G
DOCSIS 2.0 AND 1.0/1.1 INTEROPERABILITY .......................................................................413
G.1
General Interoperability Issues ..................................................................................................................413
G.1.1
Provisioning.......................................................................................................................................413
G.1.2
Registration .......................................................................................................................................414
G.1.3
Dynamic Service Establishment.........................................................................................................415
G.1.4
Fragmentation ...................................................................................................................................415
G.1.5
Multicast Support ..............................................................................................................................416
G.1.6
Changing Upstream Channels...........................................................................................................416
G.2
Hybrid Devices ..........................................................................................................................................416
G.3
DOCSIS 2.0 TDMA Interoperability ........................................................................................................417
G.3.1
Mixed-mode operation with TDMA ...................................................................................................417
G.3.2
Interoperability & Performance ........................................................................................................418
G.4
DOCSIS 2.0 S-CDMA Interoperability.....................................................................................................418
G.4.1
Mixed mode operation with S-CDMA................................................................................................418
G.4.2
Interoperability & Performance ........................................................................................................418
ANNEX H
THE DOCSIS MAC/PHY INTERFACE (DMPI) ........................................................................419
H.1
Scope .........................................................................................................................................................419
H.2
Conventions ...............................................................................................................................................419
H.2.1
Terminology.......................................................................................................................................419
H.2.2
Ordering of Bits and Bytes ................................................................................................................419
H.2.3
Signal Naming Conventions ..............................................................................................................419
H.2.4
Active Clock Edge..............................................................................................................................419
H.2.5
Timing Specifications.........................................................................................................................419
H.3
Overview ...................................................................................................................................................420
H.3.1
Downstream Data..............................................................................................................................422
H.3.2
Upstream Data ..................................................................................................................................422
H.3.3
Upstream Control ..............................................................................................................................422
H.3.4
SPI Bus ..............................................................................................................................................422
H.4
Signals .......................................................................................................................................................423
H.4.1
Downstream Data..............................................................................................................................423
H.4.2
Upstream Data ..................................................................................................................................423
H.4.3
viii
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
H.4.4
SPI Bus ..............................................................................................................................................424
H.4.5
Parity .................................................................................................................................................425
H.4.6
Interrupts ...........................................................................................................................................425
H.5
Protocol......................................................................................................................................................426
H.5.1
Downstream Data (ITU-T Recommendations J.83 Annex A)............................................................426
H.5.2
Downstream Data (ITU-T Recommendations J.83 Annex B)............................................................427
H.5.3
Upstream Data ..................................................................................................................................427
H.5.4
H.5.5
SPI Bus ..............................................................................................................................................430
H.6
Electrical Specifications ............................................................................................................................430
H.6.1
DC Specifications ..............................................................................................................................430
H.7
Timing Specifications................................................................................................................................431
H.7.1
Downstream Data..............................................................................................................................431
H.7.2
Upstream Data ..................................................................................................................................431
H.7.3
H.7.4
SPI Bus ..............................................................................................................................................432
H.8
Data Format and Usage .............................................................................................................................432
H.8.1
Downstream Data..............................................................................................................................432
H.8.2
Upstream Data ..................................................................................................................................433
H.8.3
H.8.4
SPI Bus ..............................................................................................................................................440
APPENDIX I
MAC SERVICE DEFINITION..................................................................................................441
I.1
MAC Service Overview ............................................................................................................................441
I.1.1
MAC Service Parameters ..................................................................................................................442
I.2
MAC Data Service Interface .....................................................................................................................443
I.2.1
MAC_DATA.request ..........................................................................................................................443
I.2.2
MAC_DATA.indicate .........................................................................................................................444
I.2.3
MAC_GRANT_SYNCHRONIZE.indicate ..........................................................................................444
I.2.4
MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate.............................................................444
I.3
MAC Control Service Interface.................................................................................................................445
I.3.1
MAC_REGISTRATION_RESPONSE.indicate ..................................................................................445
I.3.2
MAC_CREATE_SERVICE_FLOW.request .......................................................................................445
I.3.3
MAC_CREATE_SERVICE_FLOW.response ....................................................................................446
I.3.4
MAC_CREATE_SERVICE_FLOW.indicate......................................................................................446
I.3.5
MAC_DELETE_SERVICE_FLOW.request.......................................................................................446
I.3.6
MAC_DELETE_SERVICE_FLOW.response ....................................................................................446
I.3.7
MAC_DELETE_SERVICE_FLOW.indicate......................................................................................447
I.3.8
MAC_CHANGE_SERVICE_FLOW.request......................................................................................447
I.3.9
MAC_CHANGE_SERVICE_FLOW.response ...................................................................................447
I.3.10
MAC_CHANGE_SERVICE_FLOW.indicate.....................................................................................447
I.4
MAC Service Usage Scenarios..................................................................................................................448
I.4.1
Transmission of PDUs from Upper Layer Service to MAC DATA Service .......................................448
I.4.2
Reception of PDUs to Upper Layer Service from MAC DATA Service.............................................448
I.4.3
Sample Sequence of MAC Control and MAC Data Services.............................................................448
APPENDIX II
II.1
II.2
EXAMPLE PREAMBLE SEQUENCE.................................................................................450
Introduction ...............................................................................................................................................450
Example Preamble Sequence.....................................................................................................................450
APPENDIX III
MULTIPLE UPSTREAM CHANNELS................................................................................452
III.1 Single Downstream and Single Upstream per Cable Segment ..................................................................452
III.2 Multiple Downstreams and Multiple Upstreams per Cable Segment........................................................454
III.2.1 Topologies .........................................................................................................................................455
III.2.2 Normal Operation..............................................................................................................................456
04/22/09
CableLabs
ix
CM-SP-RFIv2.0-C02-090422
III.2.3
III.2.4
Initial Ranging...................................................................................................................................457
Dynamic Channel Change.................................................................................................................457
APPENDIX IV
IV.1
IV.2
IV.3
IV.3.1
IV.3.2
IV.3.3
IV.3.4
IV.4
IV.4.1
IV.4.2
IV.4.3
DOCSIS TRANSMISSION AND CONTENTION RESOLUTION ...................................458
Introduction ...........................................................................................................................................458
Variable Definitions...............................................................................................................................459
State Examples.......................................................................................................................................459
Idle Waiting for a Packet to Transmit...........................................................................................459
Data Ack Pending Waiting for Data Ack only ..............................................................................460
Grant Pending Waiting for a Grant ..............................................................................................460
Deferring Determine Proper Transmission Timing & Transmit...................................................460
Function Examples ................................................................................................................................461
CalcDefer() Determine Defer Amount ..........................................................................................461
UtilizeGrant() Determine Best Use of a Grant .............................................................................461
Retry()................................................................................................................................................462
APPENDIX V
V.1
V.2
IGMP EXAMPLE ...................................................................................................................463
Events ........................................................................................................................................................463
Actions.......................................................................................................................................................464
APPENDIX VI
UNSOLICITED GRANT SERVICES ...................................................................................465
VI.1
Unsolicited Grant Service (UGS) ..........................................................................................................465
VI.1.1
Introduction .......................................................................................................................................465
VI.1.2
Configuration Parameters .................................................................................................................465
VI.1.3
Operation...........................................................................................................................................465
VI.1.4
Jitter...................................................................................................................................................466
VI.1.5
Synchronization Issues ......................................................................................................................466
VI.2
Unsolicited Grant Service with Activity Detection (UGS-AD).............................................................467
VI.2.1
Introduction .......................................................................................................................................467
VI.2.2
MAC Configuration Parameters........................................................................................................467
VI.2.3
Operation...........................................................................................................................................467
VI.2.4
Example .............................................................................................................................................468
VI.2.5
Talk Spurt Grant Burst ......................................................................................................................469
VI.2.6
Admission Considerations .................................................................................................................469
APPENDIX VII
VII.1
VII.2
VII.3
VII.4
S-CDMA FRAMING ..............................................................................................................471
Coded Subsymbol Numbering...............................................................................................................471

Uncoded Subsymbol Numbering...........................................................................................................471
Framer Output Numbering ....................................................................................................................472
Comments ..............................................................................................................................................472
APPENDIX VIII
AMBIENT TEMPERATURE AND WIND LOADING EFFECTS..................................473
VIII.1
Synchronization Tolerances to Plant Delay Variations .........................................................................473
VIII.2
Change in Propagation Delay Due to Temperature Changes ................................................................474
VIII.2.1
Fiber Delay Changes Due to Temperature....................................................................................474
VIII.2.2
Coaxial Cable Delay Changes Due to Temperature .....................................................................475
VIII.2.3
Delay Change Due to Wind ...........................................................................................................475
VIII.3
References .............................................................................................................................................475
APPENDIX IX
ACKNOWLEDGMENTS .......................................................................................................476
APPENDIX X
REVISIONS .............................................................................................................................477
X.1
X.2
X.3
ECNs included in SP-RFIv2.0-I02-020617...............................................................................................477

CableLabs
04/22/09
X.4
X.5
X.6
X.7
X.8
X.9
X.10
X.11
X.12
X.13
04/22/09
CM-SP-RFIv2.0-C02-090422

ECNs included in CM-SP-RFIv2.0-I06-040804 .......................................................................................480
ECNs included in CM-SP-RFIv2.0-I11-060602 ...................................................................................481
Corrections incorporated in CM-SP-RFIv2.0-C02-090422...................................................................481
CableLabs
xi
CM-SP-RFIv2.0-C02-090422
List of Figures
FIGURE 11 TRANSPARENT IP TRAFFIC THROUGH THE DATA-OVER-CABLE SYSTEM ...................................................2
FIGURE 12 DATA-OVER-CABLE REFERENCE ARCHITECTURE ......................................................................................3
FIGURE 51 PROTOCOL STACK ON THE RF INTERFACE ................................................................................................29
FIGURE 52 DATA FORWARDING THROUGH THE CM AND CMTS ...............................................................................30
FIGURE 53 EXAMPLE CONDITION FOR NETWORK LOOPS ............................................................................................31
FIGURE 54 MAC FORWARDER ...................................................................................................................................33
FIGURE 61 UPSTREAM SIGNAL-PROCESSING SEQUENCE .............................................................................................42
FIGURE 62 TDMA UPSTREAM TRANSMISSION PROCESSING ......................................................................................42
FIGURE 63 S-CDMA UPSTREAM TRANSMISSION PROCESSING ..................................................................................43
FIGURE 64 EXAMPLE FRAME STRUCTURES WITH FLEXIBLE BURST LENGTH MODE ...................................................45
FIGURE 65 BYTE INTERLEAVER OPERATION ..............................................................................................................47
FIGURE 66 INTERLEAVER OPERATION FOR LAST INTERLEAVER BLOCK (WITH SHORTENED LAST CODEWORD)............48
FIGURE 67 SCRAMBLER STRUCTURE ..........................................................................................................................50
FIGURE 68 CONVOLUTIONAL ENCODER ......................................................................................................................50
FIGURE 69 REPETITIVE PATTERNS OF BYTE MAPPING TO SYMBOL MAP BITS FOR TCM...............................................51
FIGURE 610 EXAMPLE BYTE TO BIT ASSIGNMENT FOR 64 QAM .................................................................................52
FIGURE 611 EXAMPLE OF RETURN TO ZERO BITS FOLLOWED BY 0 ..........................................................................53
FIGURE 612 TIMESTAMP SNAPSHOT ...........................................................................................................................55
FIGURE 613 MINI-SLOT MAPPING WITH TWO CODES PER MINI-SLOT, 128 ACTIVE CODES ........................................57
FIGURE 614 MINI-SLOT MAPPING WITH THREE CODES PER MINI-SLOT, 126 ACTIVE CODES .....................................57
FIGURE 615 S-CDMA AND SPREADER-OFF INTERVALS .............................................................................................59
FIGURE 616 SUBFRAME STRUCTURE ..........................................................................................................................61
FIGURE 617 SYMBOL NUMBERING WITHOUT TCM ...................................................................................................63
FIGURE 618 SYMBOL CONSTELLATIONS.....................................................................................................................66
FIGURE 619 QPSK GRAY AND DIFFERENTIAL SYMBOL MAPPING .............................................................................67
FIGURE 620 8QAM SYMBOL MAPPING ......................................................................................................................67
FIGURE 621 16QAM SYMBOL MAPPING ....................................................................................................................68
FIGURE 624 QPSK AND 8QAM TCM SYMBOL MAPPING ..........................................................................................69
FIGURE 625 16QAM AND 32QAM TCM SYMBOL MAPPING .....................................................................................70
FIGURE 626 64QAM AND 128QAM TCM SYMBOL MAPPING ...................................................................................70
FIGURE 627 CODE HOPPING RANDOM NUMBER GENERATOR ....................................................................................73
FIGURE 628 TRANSMIT PRE-EQUALIZER STRUCTURE ................................................................................................73
FIGURE 629 NOMINAL TDMA BURST TIMING ...........................................................................................................86
FIGURE 630 WORST-CASE TDMA BURST TIMING .....................................................................................................87
FIGURE 71 EXAMPLE OF INTERLEAVING MPEG PACKETS IN DOWNSTREAM ...........................................................102
FIGURE 72 FORMAT OF AN MPEG PACKET ..............................................................................................................102
FIGURE 73 PACKET FORMAT WHERE A MAC FRAME IMMEDIATELY FOLLOWS THE POINTER_FIELD .......................104
FIGURE 74 PACKET FORMAT WITH MAC FRAME PRECEDED BY STUFFING BYTES...................................................104
FIGURE 75 PACKET FORMAT SHOWING MULTIPLE MAC FRAMES IN A SINGLE PACKET ..........................................104
FIGURE 76 PACKET FORMAT WHERE A MAC FRAME SPANS MULTIPLE PACKETS ...................................................105
FIGURE 81 GENERIC MAC FRAME FORMAT.............................................................................................................109
FIGURE 82 UPSTREAM MAC/PMD CONVERGENCE .................................................................................................110
FIGURE 83 MAC HEADER FORMAT..........................................................................................................................111
FIGURE 84 ETHERNET/802.3 PACKET PDU FORMAT................................................................................................113
FIGURE 85 RESERVED PDU FORMAT .......................................................................................................................114
FIGURE 86 TIMING MAC HEADER ...........................................................................................................................115
FIGURE 87 MANAGEMENT MAC HEADER ................................................................................................................116
FIGURE 88 REQUEST FRAME FORMAT ......................................................................................................................116
FIGURE 89 FRAGMENTATION MAC HEADER FORMAT .............................................................................................117
FIGURE 810 CONCATENATION OF MULTIPLE MAC FRAMES ....................................................................................118
xii
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
FIGURE 811 CONCATENATION MAC HEADER FORMAT ...........................................................................................118

FIGURE 812 EXTENDED MAC FORMAT ....................................................................................................................119
FIGURE 813 FRAGMENTATION DETAILS ...................................................................................................................124
FIGURE 814 MAC HEADER AND MAC MANAGEMENT MESSAGE HEADER FIELDS ..................................................127
FIGURE 815 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER ...............................................................129
FIGURE 816 UPSTREAM CHANNEL DESCRIPTOR .......................................................................................................131
FIGURE 817 TOP-LEVEL ENCODING FOR BURST DESCRIPTORS ................................................................................134
FIGURE 818 EXAMPLE OF UCD ENCODED TLV DATA .............................................................................................136
FIGURE 819 MAP FORMAT ......................................................................................................................................137
FIGURE 820 MAP INFORMATION ELEMENT STRUCTURE ..........................................................................................138
FIGURE 821 PACKET PDU FOLLOWING THE TIMING HEADER ..................................................................................140
FIGURE 822 RANGING RESPONSE .............................................................................................................................141
FIGURE 823 GENERALIZED DECISION FEEDBACK EQUALIZATION COEFFICIENTS.....................................................144
FIGURE 824 EXAMPLE OF TLV DATA ......................................................................................................................145
FIGURE 825 REGISTRATION REQUEST ......................................................................................................................146
FIGURE 826 REGISTRATION RESPONSE FORMAT ......................................................................................................148
FIGURE 827 REGISTRATION ACKNOWLEDGMENT .....................................................................................................151
FIGURE 828 UPSTREAM CHANNEL CHANGE REQUEST .............................................................................................152
FIGURE 829 UPSTREAM CHANNEL CHANGE RESPONSE ............................................................................................153
FIGURE 830 DYNAMIC SERVICE ADDITION REQUEST ..........................................................................................153
FIGURE 831 DYNAMIC SERVICE ADDITION RESPONSE ........................................................................................155
FIGURE 832 DYNAMIC SERVICE ADDITION ACKNOWLEDGE................................................................................157
FIGURE 833 DYNAMIC SERVICE CHANGE REQUEST ............................................................................................158
FIGURE 834 DYNAMIC SERVICE CHANGE RESPONSE ...........................................................................................159
FIGURE 835 DYNAMIC SERVICE CHANGE ACKNOWLEDGE ..................................................................................161
FIGURE 836 DYNAMIC SERVICE DELETION REQUEST ..........................................................................................162
FIGURE 837 DYNAMIC SERVICE DELETION RESPONSE ........................................................................................163
FIGURE 838 DYNAMIC CHANNEL CHANGE REQUEST ...............................................................................................163
FIGURE 839 DYNAMIC CHANNEL CHANGE RESPONSE .............................................................................................170
FIGURE 840 DYNAMIC CHANNEL CHANGE ACKNOWLEDGE .....................................................................................172
FIGURE 841 DEVICE CLASS IDENTIFICATION REQUEST ............................................................................................173
FIGURE 842 DEVICE CLASS IDENTIFICATION RESPONSE ..........................................................................................174
FIGURE 843 UP-DIS MESSAGE FORMAT ...................................................................................................................175
FIGURE 844 PACKET PDU FOLLOWING THE TIMING HEADER ..................................................................................176
FIGURE 845 TEST REQUEST ......................................................................................................................................178
FIGURE 91 ALLOCATION MAP ..................................................................................................................................180
FIGURE 92 PROTOCOL EXAMPLE ..............................................................................................................................186
FIGURE 93 LOGICAL S-CDMA TDMA CHANNELS ..................................................................................................187
FIGURE 101 PROVISIONED AUTHORIZATION MODEL ENVELOPES.........................................................................197
FIGURE 102 DYNAMIC AUTHORIZATION MODEL ENVELOPES...............................................................................198
FIGURE 103 CLASSIFICATION WITHIN THE MAC LAYER ..........................................................................................199
FIGURE 104 THEORY OF OPERATION OBJECT MODEL ..............................................................................................201
FIGURE 105 REGISTRATION MESSAGE FLOW ...........................................................................................................206
FIGURE 106 DYNAMIC SERVICE ADDITION MESSAGE FLOW CM INITIATED .......................................................208
FIGURE 107 DYNAMIC SERVICE ADDITION MESSAGE FLOW CMTS INITIATED ...................................................209
FIGURE 108 CM FRAGMENTATION FLOWCHART ......................................................................................................215
FIGURE 109 EXAMPLE OF FRAGMENTING A SINGLE PACKET ....................................................................................219
FIGURE 1010 FRAGMENTED CONCATENATED PACKET EXAMPLE ............................................................................220
FIGURE 1011 PAYLOAD HEADER SUPPRESSION OPERATION ....................................................................................223
FIGURE 1012 PAYLOAD HEADER SUPPRESSION WITH MASKING ..............................................................................224
FIGURE 1013 PAYLOAD HEADER SUPPRESSION SIGNALING EXAMPLE .....................................................................225
FIGURE 1014 UPSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE .....................................................................225
FIGURE 1015 DOWNSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE ...............................................................226
FIGURE 111 CM INITIALIZATION OVERVIEW ...........................................................................................................229
FIGURE 112 SDL NOTATION ....................................................................................................................................230
04/22/09
CableLabs
xiii
CM-SP-RFIv2.0-C02-090422
FIGURE 113 OBTAINING UPSTREAM PARAMETERS ...................................................................................................234

FIGURE 114 MESSAGE FLOWS DURING SCANNING AND UPSTREAM PARAMETER ACQUISITION ..............................235
FIGURE 115 RANGING AND AUTOMATIC ADJUSTMENTS PROCEDURE ......................................................................236
FIGURE 116 INITIAL RANGING CM...........................................................................................................................237
FIGURE 117 UNICAST INITIAL RANGING - CM .........................................................................................................238
FIGURE 118 INITIAL RANGING - CMTS....................................................................................................................239
FIGURE 119 DEVICE CLASS IDENTIFICATION............................................................................................................240
FIGURE 1110 ESTABLISHING IP CONNECTIVITY .......................................................................................................241
FIGURE 1111 ESTABLISHING TIME OF DAY ..............................................................................................................241
FIGURE 1112 REGISTRATION CM ........................................................................................................................243
FIGURE 1113 WAIT FOR REGISTRATION RESPONSE CM ......................................................................................244
FIGURE 1114 REGISTRATION CMTS ...................................................................................................................246
FIGURE 1115 REGISTRATION ACKNOWLEDGMENT CMTS ..................................................................................247
FIGURE 1116 PERIODIC RANGING - CMTS...............................................................................................................250
FIGURE 1117 PERIODIC RANGING - CM VIEW..........................................................................................................251
FIGURE 1118 CHANGING UPSTREAM CHANNELS: CMTS VIEW ...............................................................................253
FIGURE 1119 CHANGING UPSTREAM CHANNELS: CM VIEW PART 1........................................................................254
FIGURE 1120 CHANGING UPSTREAM CHANNELS: CM VIEW PART 2........................................................................255
FIGURE 1121 DYNAMIC SERVICE FLOW OVERVIEW .................................................................................................256
FIGURE 1122 DYNAMIC SERVICE FLOW STATE TRANSITION DIAGRAM ...................................................................259
FIGURE 1123 DSALOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................................260
FIGURE 1124 DSAREMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .....................................261
FIGURE 1125 DSCLOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................................262
FIGURE 1126 DSCREMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM......................................263
FIGURE 1127 DSDLOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ........................................264
FIGURE 1128 DYNAMIC DELETION (DSD) - REMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM ..265
FIGURE 1129 DYNAMIC SERVICE ADDITION INITIATED FROM CM...........................................................................266
FIGURE 1130 DYNAMIC SERVICE ADDITION INITIATED FROM CMTS ......................................................................267
FIGURE 1131 DSALOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM .......................................268
FIGURE 1132 DSALOCALLY INITIATED TRANSACTION DSA-RSP PENDING STATE FLOW DIAGRAM..................269
FIGURE 1133 DSALOCALLY INITIATED TRANSACTION HOLDING STATE FLOW DIAGRAM ..................................270
FIGURE 1134 DSALOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM ...............271
FIGURE 1135 DSALOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ........272
FIGURE 1136 DSAREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ....................................273
FIGURE 1137 DSAREMOTELY INITIATED TRANSACTION DSA-ACK PENDING STATE FLOW DIAGRAM ..............274
FIGURE 1138 DSAREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ....................275
FIGURE 1139 DSAREMOTELY INITIATED TRANSACTION DELETING SERVICE STATE FLOW DIAGRAM ................275
FIGURE 1140 CM-INITIATED DSC ...........................................................................................................................277
FIGURE 1141 CMTS-INITIATED DSC.......................................................................................................................277
FIGURE 1142 DSCLOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM .......................................278
FIGURE 1143 DSCLOCALLY INITIATED TRANSACTION DSC-RSP PENDING STATE FLOW DIAGRAM ..................279
FIGURE 1144 DSCLOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM .......................280
FIGURE 1145 DSCLOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM ................281
FIGURE 1146 DSCLOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ........282
FIGURE 1147 DSCREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM.....................................283
FIGURE 1148 DSCREMOTELY INITIATED TRANSACTION DSC-ACK PENDING STATE FLOW DIAGRAM ..............284
FIGURE 1149 DSCREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM.....................285
FIGURE 1150 DSCREMOTELY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW DIAGRAM ......285
FIGURE 1151 DYNAMIC SERVICE DELETION INITIATED FROM CM...........................................................................286
FIGURE 1152 DYNAMIC SERVICE DELETION INITIATED FROM CMTS ......................................................................286
FIGURE 1153 DSDLOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM .......................................287
FIGURE 1154 DSDLOCALLY INITIATED TRANSACTION DSD-RSP PENDING STATE FLOW DIAGRAM..................288
FIGURE 1155 DSDLOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM .......................289
FIGURE 1156 DSDREMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ....................................290
FIGURE 1157 DSDREMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ....................291
xiv
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
FIGURE 1158 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 1 ............................................................297

FIGURE 1162 DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 1 .................................................................301
FIGURE 1163 DYNAMICALLY CHANNELS: CM VIEW PART 2 ...................................................................................302
FIGURE 1166 DCC EXAMPLE OPERATIONAL FLOW .................................................................................................307
FIGURE 1167 EXAMPLE COMBINING NETWORK 1 ....................................................................................................313
FIGURE 1168 EXAMPLE COMBINING NETWORK 2 ....................................................................................................315
FIGURE D1 BINARY CONFIGURATION FILE FORMAT ................................................................................................376
FIGURE D2 CREATE TLV ENTRIES FOR PARAMETERS REQUIRED BY THE CM .........................................................378
FIGURE D3 ADD CM MIC........................................................................................................................................378
FIGURE D4 ADD CMTS MIC ...................................................................................................................................378
FIGURE D5 ADD END OF DATA MARKER .................................................................................................................379
FIGURE E1 SPANNING TREE TOPOLOGY ...................................................................................................................381
FIGURE E2 SPANNING TREE ACROSS CMTSES ........................................................................................................382
FIGURE F3 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER ................................................................412
FIGURE H1 DMPI APPLICATION ..............................................................................................................................421
FIGURE H2 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83 ANNEX A OPERATION 426
FIGURE H3 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83 ANNEX B OPERATION 427
FIGURE H4 UPSTREAM DATA PROTOCOL .................................................................................................................427
FIGURE H5 COUNTER SYNCHRONIZATION ...............................................................................................................428
FIGURE H6 UPSTREAM CONTROL MESSAGE TRANSFER ...........................................................................................429
FIGURE H7 SPI BUS TRANSACTION..........................................................................................................................430
FIGURE III1 SINGLE DOWNSTREAM AND SINGLE UPSTREAM CHANNELS PER CM ...................................................453
FIGURE III2 MULTIPLE DOWNSTREAM AND MULTIPLE UPSTREAM CHANNELS PER CM ..........................................455
FIGURE IV1 TRANSMISSION & DEFERENCE STATE TRANSITION DIAGRAM ..............................................................458
FIGURE V1 IGMP SUPPORT CM PASSIVE MODE ....................................................................................................463
FIGURE VI1 EXAMPLE JITTER WITH MULTIPLE GRANTS PER SID ............................................................................466
FIGURE VI2 VAD START-UP AND STOP...................................................................................................................468
04/22/09
CableLabs
xv
CM-SP-RFIv2.0-C02-090422
List of Tables
TABLE 41 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1).........................27
TABLE 42 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1)...............................27
TABLE 61 BURST SIZE ................................................................................................................................................45
TABLE 62 INTERLEAVER OPERATING PARAMETERS ...................................................................................................47
TABLE 63 I/Q MAPPING .............................................................................................................................................64
TABLE 64 DEFINITION OF DIFFERENTIAL QUADRANT CODING ...................................................................................65
TABLE 65 MAXIMUM CHANNEL WIDTH .....................................................................................................................75
TABLE 66 CONSTELLATION GAINS AND POWER LIMITS .............................................................................................77
TABLE 67 BURST PROFILE ATTRIBUTES .....................................................................................................................82
TABLE 68 USER UNIQUE BURST PARAMETERS...........................................................................................................82
TABLE 69 SPURIOUS EMISSIONS .................................................................................................................................88
TABLE 610 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST POWER LEVEL .....89
TABLE 611 SPURIOUS EMISSIONS IN 5 TO 42 MHZ RELATIVE TO THE TRANSMITTED BURST POWER LEVEL..............89
TABLE 612 FILTER AMPLITUDE DISTORTION .............................................................................................................92
TABLE 613 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER................................94
TABLE 614 ELECTRICAL OUTPUT FROM CM ..............................................................................................................95
TABLE 615 INTERLEAVER CHARACTERISTICS ............................................................................................................95
TABLE 616 CMTS OUTPUT ........................................................................................................................................96
TABLE 617 ELECTRICAL INPUT TO CM ......................................................................................................................97
TABLE 618 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE CMTS
MASTER CLOCK .................................................................................................................................................100
TABLE 71 MPEG HEADER FORMAT FOR DOCSIS DATA-OVER-CABLE PACKETS...................................................103
TABLE 81 GENERIC MAC HEADER FORMAT ............................................................................................................111
TABLE 82 FC FIELD FORMAT ...................................................................................................................................112
TABLE 83 PACKET PDU FORMAT.............................................................................................................................113
TABLE 84 RESERVED PDU FORMAT ........................................................................................................................114
TABLE 85 MAC-SPECIFIC HEADERS AND FRAMES...................................................................................................115
TABLE 86 TIMING MAC HEADER FORMAT ..............................................................................................................115
TABLE 87 MAC MANAGEMENT FORMAT .................................................................................................................116
TABLE 88 REQUEST FRAME (REQ) FORMAT ............................................................................................................117
TABLE 89 FRAGMENTATION MAC FRAME (FRAG) FORMAT ..................................................................................117
TABLE 810 CONCATENATED MAC FRAME FORMAT ................................................................................................119
TABLE 811 EXAMPLE EXTENDED HEADER FORMAT ................................................................................................120
TABLE 812 EH ELEMENT FORMAT ...........................................................................................................................120
TABLE 813 EXTENDED HEADER TYPES ....................................................................................................................121
TABLE 814 FRAGMENTATION EXTENDED HEADER FORMAT ....................................................................................122
TABLE 815 PAYLOAD HEADER SUPPRESSION EHDR SUB-ELEMENT FORMAT .........................................................123
TABLE 816 UNSOLICITED GRANT SYNCHRONIZATION EHDR SUB-ELEMENT FORMAT ...........................................123
TABLE 817 MAC MANAGEMENT MESSAGE TYPES ..................................................................................................128
TABLE 818 CHANNEL TLV PARAMETERS ................................................................................................................132
TABLE 819 UPSTREAM PHYSICAL-LAYER BURST ATTRIBUTES ................................................................................135
TABLE 820 ALLOCATION MAP INFORMATION ELEMENTS (IE)................................................................................139
TABLE 821 RANGING RESPONSE MESSAGE ENCODINGS ..........................................................................................143
TABLE 822 CHANNEL TLV PARAMETERS ................................................................................................................179
TABLE 91 IE FEATURE COMPATIBILITY SUMMARY ..................................................................................................185
TABLE 92 EXAMPLE RELATING MINI-SLOTS TO TIME TICKS ...................................................................................190
TABLE 93 EXAMPLE OF MINI-SLOT CAPACITY IN S-CDMA MODE ..........................................................................191
TABLE 94 TRANSMIT OPPORTUNITY ........................................................................................................................193
TABLE 101 TFTP FILE CONTENTS ...........................................................................................................................207
TABLE 102 REGISTRATION REQUEST CONTENTS......................................................................................................207
TABLE 103 REGISTRATION RESPONSE CONTENTS ....................................................................................................208
TABLE 104 PARAMETER APPLICABILITY FOR UPSTREAM SERVICE SCHEDULING .....................................................213
xvi
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
TABLE 105 PAYLOAD HEADER SUPPRESSION DEFINITIONS ......................................................................................221

TABLE 111 FACTORS AFFECTING DCC PERFORMANCE ............................................................................................305
TABLE 112 RECOVERY PROCESS ON LOSS OF SPECIFIC MAC MESSAGES ................................................................316
TABLE C1 SAMPLE DOCSIS 1.0 CLASS OF SERVICE ENCODING ..............................................................................325
TABLE C1 VALUES USED IN REG-REQ AND REG-RSP MESSAGES ........................................................................356
TABLE C2 VALUES USED IN REG-REQ, REG-RSP, AND DYNAMIC SERVICE MESSAGES .......................................356
TABLE E1 CM PATH COST .......................................................................................................................................383
TABLE F1 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS FOR ANALOGUE TV AND SOUND
SIGNALS ..............................................................................................................................................................387
TABLE F2 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS....................................................388
TABLE F3 CONSTELLATION GAINS AND POWER LIMITS ...........................................................................................393
TABLE F4 BURST PROFILE ATTRIBUTES ...................................................................................................................397
TABLE F5 USER UNIQUE BURST PARAMETERS ........................................................................................................398
TABLE F6 SPURIOUS EMISSIONS...............................................................................................................................400
TABLE F7 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST POWER LEVEL .....401
TABLE F8 SPURIOUS EMISSIONS IN 5 TO 65 MHZ RELATIVE TO THE TRANSMITTED BURST POWER LEVEL .............402
TABLE F9 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER ...............................404
TABLE F10 ELECTRICAL OUTPUT FROM CM............................................................................................................405
TABLE F11 INTERLEAVER CHARACTERISTICS...........................................................................................................405
TABLE F12 CMTS OUTPUT ......................................................................................................................................406
TABLE F13 ELECTRICAL INPUT TO CM ....................................................................................................................406
TABLE F14 256QAM CM BER PERFORMANCE .......................................................................................................407
TABLE F15 QAM MODULATION ..............................................................................................................................408
TABLE F16 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE CMTS
MASTER CLOCK .................................................................................................................................................409
TABLE F17 MPEG HEADER FORMAT FOR EURO-DOCSIS DATA-OVER-CABLE PACKETS .......................................410
TABLE G1 REGISTRATION BEHAVIOR FOR A DOCSIS 2.0 CM.................................................................................415
TABLE G2 HYBRID MODE CONTROLS ......................................................................................................................417
TABLE H1 TIMING PARAMETERS..............................................................................................................................420
TABLE H2 DOWNSTREAM DATA INTERFACE SIGNALS .............................................................................................423
TABLE H3 UPSTREAM DATA INTERFACE SIGNALS ...................................................................................................423
TABLE H4 UPSTREAM CONTROL INTERFACE SIGNALS .............................................................................................424
TABLE H5 SPI BUS SIGNALS ....................................................................................................................................424
TABLE H6 TIMESTAMP COUNTER INITIALIZATION OPTIONS ....................................................................................428
TABLE H7 DC CHARACTERISTICS ............................................................................................................................431
TABLE H8 DS DATA INTERFACE TIMING .................................................................................................................431
TABLE H9 US DATA INTERFACE TIMING .................................................................................................................431
TABLE H10 UPSTREAM CONTROL INTERFACE TIMING .............................................................................................432
TABLE H11 SPI BUS TIMING ....................................................................................................................................432
TABLE H12 UPSTREAM DATA BLOCK FORMAT .......................................................................................................433
TABLE H13 UPSTREAM DATA BLOCK TYPES ...........................................................................................................433
TABLE H14 FIRST_DATA DATA FORMAT .............................................................................................................434
TABLE H15 MIDDLE_DATA DATA FORMAT ........................................................................................................434
TABLE H16 LAST_DATA DATA FORMAT ..............................................................................................................434
TABLE H17 PHY_STATUS DATA FORMAT ............................................................................................................435
TABLE H18 NO_BURST DATA FORMAT ................................................................................................................435
TABLE H19 CHANNEL DATA FORMAT ..................................................................................................................435
TABLE H20 UPSTREAM CONTROL MESSAGE FORMAT .............................................................................................438
TABLE H21 UPSTREAM MESSAGE TYPES .................................................................................................................438
TABLE H22 UPSTREAM CONTROL INTERVAL DESCRIPTION PAYLOAD FORMAT ...................................................438
TABLE H23 UCD CHANGE PAYLOAD FORMAT ....................................................................................................440
TABLE H24 SPI BUS TRANSACTION FORMAT ..........................................................................................................440
TABLE III1 MAC MESSAGES WITH CHANNEL IDS ...................................................................................................456
TABLE VI1 EXAMPLE REQUEST TO GRANT RESPONSE TIME ....................................................................................469
TABLE VI2 EXAMPLE EXTRA GRANTS FOR NEW TALK SPURTS ...............................................................................469
04/22/09
CableLabs
xvii
CM-SP-RFIv2.0-C02-090422
TABLE VIII1 ALLOWABLE PLANT TIMING DRIFT ......................................................................................................473
xviii
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
1 RADIO FREQUENCY INTERFACE SPECIFICATION

1.1
1.1.1
Scope and Purpose

Scope
This document defines the second generation of radio-frequency interface specifications for high-speed data-overcable 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, and
7, 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 inter-operate 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 downstream-based
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 [SCTE22-1], whereas the option of Annex F was not included
in [SCTE22-1] and therefore is not required to be backwards compatible with [SCTE22-1].
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].
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
1.2
Requirements
Throughout this document, the words that are used to define the significance of particular requirements are
capitalized. These words are:
MUST
This word or the adjective REQUIRED means that the item is an absolute requirement of this
specification.
MUST NOT
This phrase means that the item is an absolute prohibition of this specification.
SHOULD
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.
SHOULD NOT
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.
MAY
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.
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 nonmandatory features and parameter values is optional.
1.3
1.3.1
Background
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 11.
Wide-Area
Network
CMTS
Network Side
Interface
Cable
Modem
Termination
System
CMTS
Cable
Network
Cable Modem
(CM)
CM Customer Premises
Equipment Interface
Transparent IP Traffic Through the System
Customer
Premises
Equipment
Figure 11 Transparent IP Traffic Through the Data-Over-Cable System
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 dataover-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-customer-premisesequipment 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 12.
Note:
This architecture illustrates the North American frequency plans only and is not normative for European
applications. Refer to Section 1.1.1 for applicability.
Distribution Hub or Headend
Operations Support System
PSTN
Copper
Pairs,
DS1 or DS3
Data Over Cable System

OSS Interface, DOCS-OSSI
Telco Return
Access
Concentrator
(TRAC)
Cable Modem Termination System

Downstream RF Interface
WAN
Generic
Headend
Switch or
Backbone
Transport
Adapter
Cable Modem
Termination System
Video 2
.
Data
Rx
Demod
Data
Upstream
splitter
and filter
bank
Local
Server
Facility
Fiber
Cable
Modem
Coax
O/E
Node
Cable Modem to
RF Interface,
542MHz
Cable Modem to
CPE Interface,
CMCI
Baseline
Privacy Interface
(BPI)
Security &
Access
Controller
WAN
O/E
Node
Tx
Network
Termination
Customer
Premise
Equipment
O/E
Node
50860MHz
Mod
Backbone
Network
Distribution
Network
Video 1
Com biner
Cable Modem
Termination System
Network Side Interface,
CMTS-NSI
.
Cable Modem Termination System
Upstream RF Interface
Telco
return
Cable Modem
Telco Return
Interface, CMTRI
Remote
Server
Facility
Figure 12 Data-Over-Cable Reference Architecture
1.3.3
Categories of Interface Specification
The basic reference architecture of Figure 12 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].
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
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
Title
Cable Modem to Customer Premises Equipment Interface Specification
SP-CMTS-NSI
Cable Modem Termination System Network Side Interface Specification
SP-CMTRI
Cable Modem Telco Return Interface Specification
SP-OSSI
Operations Support System Interface Specification
SP-RFI
SP-BPI+
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 [SCTE22-1] and [SCTE23-1], 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.0-compliant
CMs MUST interoperate seamlessly with DOCSIS 1.x CMTSs, albeit in the 1.x mode, as the case may be. DOCSIS
2.0-compliant CMTSs 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.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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-C01-081104, November 4, 2008, Cable Television Laboratories, Inc.
[DOCSIS5]
Data-Over-Cable Service Interface Specifications, Operations Support System Interface Specification, CM-SPOSSIv2.0-C01-081104, November 4, 2008, Cable Television Laboratories, Inc.
[DOCSIS6]
Data-Over-Cable Service Interface Specifications, Cable Modem Telephony Return Interface Specification, SPCMTRI-I01-970804.
[DOCSIS8]
Data-Over-Cable Service Interface Specifications, Baseline Privacy Plus Interface Specification, CM-SP-BPI+C01-081104, November 4, 2008, Cable Television Laboratories, Inc.
[SCTE22-1]
ANSI/SCTE 22-1, Data-Over-Cable Service Interface Specification, Radio Frequency Interface (RFI).
[SCTE22-2]
ANSI/SCTE 22-2, DOCSIS Baseline Privacy Interface (BPI).
[SCTE23-1]
ANSI/SCTE 23-1, DOCSIS 1.1, Part 1: Radio Frequency Interface.
[DRFI]
Data-Over-Cable Service Interface Specifications, Downstream Radio Interface Specification, CM-CM-SP-DRFII06-080215, February 15, 2008, Cable Television Laboratories, Inc.
[DSG]
Data-Over-Cable Service Interface Specifications, Set-top Gateway (DSG) Interface Specification, CM-SP-DSGI12-080626, June 26, 2008, Cable Television Laboratories, Inc.
[EIA-S542]
EIA Standard 542 (1997), Cable Television Channel Identification Plan, May 1997.
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
[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.
[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]
CENELEC EN 60950: Safety of information technology equipment.
[FCC15]
Code of Federal Regulations, Title 47, Part 15, October 2000.
[FCC76]
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.
[IEEE802.1Q]
IEEE Standard 802.1Q. Virtual Bridged Local Area Networks. December 8, 1998.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
[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).
[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.
[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]
ITU-T Recommendation Z.100 (11/99) - CCITT Specification and description language (SDL).
[L2VPN]
Data-Over-Cable Service Interface Specifications, Business Services over DOCSIS, Layer 2 Virtual Private
Networks, CM-SP-L2VPN-I08-080522, May 22, 2008, Cable Television Laboratories, Inc.
[NCTA]
NCTA Recommended Practices for measurement on Cable Television Systems - National Cable Television
Association, Washington DC, 2nd Edition, revised October, 1993.
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
[PKT-MGCP]
PacketCable Specifications, Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-C01071129, November 11, 2007, Cable Television Laboratories, Inc.
[PKT-DQOS]
PacketCable Specifications, Dynamic Quality of Service Specification, PKT-SP-DQOS-C01-71129, November 11,
2007, Cable Television Laboratories, Inc.
[RFC-791]
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 RFC1042, 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 RFC1157, 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 RFC1633, 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.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
[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.
[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]
Fenner, W., Internet Group Management Protocol, Version 2, IETF RFC-2236, November 1997.
[RFC-2349]
Malkin, G. and Harkin, A., TFTP Timeout Interval and Transfer Size Options, IETF RFC-2349, May 1998.
[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 RFC2786, 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 Sub-option, IETF RFC-3256,
April 2002.
[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.
04/22/09
CableLabs
CM-SP-RFIv2.0-C02-090422
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)
A protocol of the IETF for converting network addresses to 48-bit Ethernet addresses.
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.
American National Standards Institute (ANSI)
A US standards body.
ANSI
See American National Standards Institute.
ARP
See Address Resolution Protocol.
Asynchronous Transfer Mode (ATM)
A protocol for the transmission of a variety of digital signals using uniform 53-byte cells.
ATM
See Asynchronous Transfer Mode.
A-TDMA
DOCSIS 2.0 TDMA mode (as distinguished from DOCSIS 1.x 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
The MAC Management Message that the CMTS uses to allocate transmission opportunities to CMs.
BPDU
See Bridge Protocol Data Unit.
Bridge Protocol Data Unit (BDU)
Spanning tree protocol messages as defined in [ISO/IEC10038].
10
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Broadcast Addresses
A predefined destination address that denotes the set of all data network service access points.
Burst
A single continuous RF signal from the upstream transmitter, from transmitter on to transmitter off.
Burst Error Second
Any Errored Second containing at least 100 errors.
Cable Modem (CM)
A modulator-demodulator at subscriber locations intended for use in conveying data communications on a cable
television system.
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)
The interface, defined in [DOCSIS3], between a CMTS and the equipment on its network side.
Cable Modem to CPE Interface (CMCI)
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.
Chip Duration
The time to transmit one chip of the S-CDMA spreading code. The inverse of the chip rate.
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.
04/22/09
CableLabs
11
CM-SP-RFIv2.0-C02-090422
CM
See Cable Modem.
CMCI
See Cable Modem to CPE Interface.
CMTS
See Cable Modem Termination System.
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 second-order non-linearities in cable system equipment.
Composite Triple Beat (CTB)
The peak of the average level of distortion components due to third-order non-linearities in cable system equipment.
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
Dynamic Channel Change.
DHCP
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.
12
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DOCSIS
Data-Over-Cable Service Interface Specifications.
DOCSIS 1.x
Abbreviation for DOCSIS 1.0 or 1.1.
Downstream
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)
An Internet protocol used for assigning network-layer (IP) addresses.
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
See Engineering Change Notice.
ECO
See Engineering Change Order.
ECR
See Engineering Change Request.
Electronic Industries Association (EIA)
A voluntary body of manufacturers which, among other activities, 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).
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.
04/22/09
CableLabs
13
CM-SP-RFIv2.0-C02-090422
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)
A fiber-based LAN standard.
Fiber Node
A point of interface between a fiber trunk and the coaxial distribution.
Forward Channel
The direction of RF signal flow away from the head-end toward the end user; equivalent to Downstream.
Frame
1
See MAC frame and S-CDMA 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
2
equal to the guard band 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
Protocol control information located at the beginning of a protocol data unit.
1
2
Revised this Glossary term per ECNRFIv2.0-N-05.0220-2 by GO on 6/22/05.

Guard Time entry revised, Guard Band entry added per RFI2-N-02085 by RKV on 10/28/02.
14
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
HFC
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.
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
See Internet Control Message Protocol.
IE
See Information Element.
IEEE
See Institute of Electrical and Electronic Engineers.
IETF
See Internet Engineering Task Force.
IGMP
See Internet Group Management Protocol.
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.
International Organization for Standardization (ISO)
An international standards body, commonly known as the International Standards Organization.
Internet Control Message Protocol (ICMP)
An Internet network-layer protocol.
04/22/09
CableLabs
15
CM-SP-RFIv2.0-C02-090422
Internet Engineering Task Force (IETF)

A body responsible, among other things, for developing standards used in the Internet.
Internet Group Management Protocol (IGMP)
A network-layer protocol for managing multicast groups on the Internet
Impulse Noise
Noise characterized by non-overlapping transient disturbances.
Information Element
The fields that make up a MAP and define individual grants, deferred grants, etc.
Internet Protocol (IP)
An Internet network-layer protocol.
Interval Usage Code
A field in MAPs and UCDs to link burst profiles to grants.
IP
See Internet Protocol.
IUC
See Interval Usage Code.
L2VPN
3
see Layer 2 Virtual Private Networking.
Latency
The time, expressed in quantity of symbols, taken for a signal element to pass through a device.
Layer
A subdivision of the Open System Interconnection (OSI) architecture, constituted by subsystems of the same rank.
Link Layer
See Data Link Layer.
LLC
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.
Added this item to the Glossary per ECN RFIv2.0-N-05.02221-4 by GO on 11/23/05.
16
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 Frame
MAC header plus optional PDU.
MAC Service Access Point
An attachment to a MAC-sublayer domain. Refer to Sections 5.2 and 8.1.2.2.
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 HeadEnd 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
The built-in hardware address of a device connected to a shared medium.
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.
04/22/09
CableLabs
17
CM-SP-RFIv2.0-C02-090422
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)
A voluntary body which develops standards for digital compressed moving pictures and associated audio.
MPEG
See Moving Picture Experts Group.
MSAP
See MAC Service Access Point.
Multipoint Access
User access in which more than one terminal equipment is supported by a single network 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)
Committee which defined the analog color television broadcast standard used today in North America.
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.
18
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
See Open Systems Interconnection.
OUI
See Organization Unique Identifier.
Packet Identifier (PID)
A unique integer value used to identify elementary streams of a program in a single- or multi-program MPEG-2
stream.
Partial Grant
A grant that is smaller than the corresponding bandwidth request from the CM.
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
See Payload Header Suppression.
PHY
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
See Packet Identifier.
PMD
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
04/22/09
CableLabs
19
CM-SP-RFIv2.0-C02-090422
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
See Program-Specific Information.
QAM
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.
Radio Frequency (RF)
In cable television systems, this refers to electromagnetic signals in the range 5 to 1000 MHz.
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/.
20
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
The direction of signal flow towards the head-end, away from the subscriber; equivalent to Upstream.
RFC
See Request for Comments.
Routing Information Protocol (RIP)
A protocol of the IETF for exchanging routing information about IP 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 SCDMA frame, the number of mini-slots is determined by the number of codes per mini-slot (c) and p, the number of
active codes in the S-CDMA frame. Each S-CDMA frame thus contains s mini-slots, where s=p/c, and each minislot 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
A Baseline Privacy security identifier between a CMTS and a CM.
Service Access Point (SAP)
The point at which services are provided by one layer, or sublayer to the layer immediately above it.
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.
04/22/09
CableLabs
21
CM-SP-RFIv2.0-C02-090422
Service Flow Identifier (SFID)

An identifier assigned to a service flow by the CMTS. [32 bits]
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.
Simple Network Management Protocol (SNMP)
A network management protocol of the IETF.
SMS
See Spectrum Management System.
SNAP
See Subnetwork Access Protocol.
SNMP
See Simple Network Management Protocol.
Spectrum Management System (SMS)
A system, defined in [SMS], for managing the RF cable spectrum.
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 spreaderoff 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 mini-slots 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 minislots 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.
22
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
Subnetwork
Subnetworks are physically formed by connecting adjacent nodes with transmission links.
Subnetwork Access Protocol (SNAP)
An extension of the LLC header to accommodate the use of 802-type 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.
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-to-end delivery of data packets without error.
04/22/09
CableLabs
23
CM-SP-RFIv2.0-C02-090422
Transmission Convergence Sublayer

A sublayer of the Physical Layer that provides an interface between the Data Link Layer and the PMD Sublayer.
Transmission Link
The physical unit of a subnetwork that provides the transmission connection between adjacent nodes.
Transmission Medium
The material on which information signals may be carried; e.g., optical fiber, coaxial cable, and twisted-wire pairs.
Transmission System
The interface and transmission medium through which peer physical layer entities transfer bits.
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.
UCC
Upstream Channel Change.
Upstream
The direction from the subscriber location toward the head-end.
Upstream Channel Descriptor (UCD)
The MAC Management Message used to communicate the characteristics of the upstream physical layer to the cable
modems.
24
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
4 FUNCTIONAL ASSUMPTIONS
This section describes the characteristics of cable television plant to be assumed for the purpose of operating a dataover-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. 4
At a propagation velocity in fiber of approximately 1.5 ns/ft, 100 miles of fiber in each direction results in a roundtrip delay of approximately 1.6 ms. For further information, see Appendix VIII. 5
4.2
4.2.1
Equipment Assumptions
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.
4
5
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.
04/22/09
CableLabs
25
CM-SP-RFIv2.0-C02-090422
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 dataover-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 41. 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 41 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.
26
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 41 Assumed Downstream RF Channel Transmission Characteristics (see note 1)

Parameter
Value
Frequency range
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.
RF channel spacing (design bandwidth)
6 MHz
Transit delay from head-end to most distant customer
<= 0.800 msec (typically much less)
Carrier-to-noise ratio in a 6-MHz band
Not less than 35 dB (see note 2,3)
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
3 dB within the design bandwidth (see note 2)
Group delay ripple in the spectrum occupied by the CMTS
75 ns within the design bandwidth (see note 2)
Micro-reflections bound for dominant echo
-20 dBc @ <= 1.5 sec, -30 dBc @ > 1.5 sec
-10 dBc @ <= 0.5 sec, -15 dBc @ <= 1.0 sec (see note 2)
Carrier hum modulation
Not greater than -26 dBc (5%) (see note 2)
Burst noise
Not longer than 25 sec at a 10 Hz average rate (see note 2)
Maximum analog video carrier level at the CM input
17 dBmV
Maximum number of analog carriers
121
Notes to Table:
1.
Transmission is from the head-end combiner to the CM input at the customer location.
2.
Measurement methods defined in [NCTA] or [CableLabs1].
3.
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 42. All conditions are present concurrently. No combination of the following parameters will exceed any
stated interface limit defined elsewhere in this specification.
Table 42 Assumed Upstream RF Channel Transmission Characteristics (see note 1)
Parameter
Value
Frequency range
5 to 42 MHz edge to edge
Transit delay from the most distant CM to the nearest CM or CMTS <= 0.800 msec (typically much less)
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
Not less than 25 dB (Note 2)
Not greater than -23 dBc (7.0%)
Burst noise
Not longer than 10 sec at a 1 kHz average rate for most cases
(Notes 3 and 4)
Amplitude ripple 5-42 MHz:
0.5 dB/MHz
Group delay ripple 5-42 MHz:
200 ns/MHz
Micro-reflections - single echo
-10 dBc @ <= 0.5 sec

-20 dBc @ <= 1.0 sec
-30 dBc @ > 1.0 sec
Seasonal and diurnal reverse gain (loss) variation
Not greater than 14 dB min to max
Notes to Table:
1.
Transmission is from the CM output at the customer location to the head-end.
04/22/09
CableLabs
27
CM-SP-RFIv2.0-C02-090422
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 10 dBc. The ratios are guaranteed only within the digital carrier channels.
3.
Amplitude and frequency characteristics sufficiently strong to partially or wholly mask the data carrier.
4.
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.
28
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 51. (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 51.
SNMP
TFTP
DHCP
UDP
IP, ICMP
ARP
LLC/DIX
Link
Security
MAC
Transmission
Convergence
(Downstream Only)
PMD
Figure 51 Protocol Stack on the RF Interface
04/22/09
CableLabs
29
CM-SP-RFIv2.0-C02-090422
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. 6 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
5.1.2.1
Data Forwarding Through the CM and CMTS

General
Data forwarding through the CMTS MAY be transparent bridging, 7 or MAY employ network-layer forwarding
(routing, IP switching) as shown in Figure 52.
Data forwarding through the CM is link-layer transparent bridging, as shown in Figure 52. 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
CM Stack
IP
IP
Forwarding 802.2/DIX LLC

Data
Link
Layer
PHY Layer
CMTS-NSI
Interface
to/from
Network
Equipment
Link Security
802.2/DIX LLC Transparent

Bridging
Link Security
802.2/DIX
LLC
Cable MAC
Cable MAC
802.3/DIX
MAC
DS TC
Upstrm
Layer
Cable
Cable
PMD
PMD
DS TC
Upstrm
Layer
Cable
Cable
PMD
PMD
802.3
10Base-T
Cable Network
Transmission
CMCI Interface
to/from
Customer
Premises
Equipment
Figure 52 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.
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 53.
6
7
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.
30
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Cable Network
CMTS
CM #1
Local
ISO8802
Network
CM #2
CPE
Figure 53 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. 8
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 CMTSNSI, 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.
Section 5.1.2.1, last paragraph added per RFI2-N-02171 by RKV on 10/29/02.
04/22/09
CableLabs
31
CM-SP-RFIv2.0-C02-090422
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. 9
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. 10
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.
10
32
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 11
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 54. It is responsible for delivering upstream frames to
One or more downstream channels
The MSAP interface
In Figure 54, 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
Host IP Stack,
incl. LLC
and 802.2/DIX
RFI-NSI Forwarding
Process
MAC Service
Access Point
(MSAP) Interface
CMTS
-NSI
MAC Forwarder
Link Security
MAC
Upstream and
Downstream Channels
Figure 54 MAC Forwarder
11
Section 5.1.2.3.2 updated per RFI2-N-02171 by RKV on 10/29/02.
04/22/09
CableLabs
33
CM-SP-RFIv2.0-C02-090422
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 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. 12
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, 13 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.
12
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.
13
All multicasts, including 802.1d/ISO 10038 Spanning Tree Bridge BPDUs, MUST be forwarded.
34
CableLabs
04/22/09
5.3.1
CM-SP-RFIv2.0-C02-090422
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 [SCTE23-1]. 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 IGMPProxy 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.
04/22/09
CableLabs
35
CM-SP-RFIv2.0-C02-090422
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.
36
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 14
Note:
5.4
Nothing in this section would prohibit the CM from being specifically configured to not forward certain
multicast traffic as a matter of network policy.
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
14
Added this bullet statement per ECN RFIv2.0-N-03.0120-2 by GO on 02/11/04.
04/22/09
CableLabs
37
CM-SP-RFIv2.0-C02-090422
Media Access Control (MAC) sublayer
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 4byte 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 payloads is arbitrary and controlled
by the CMTS.
The Downstream Transmission Convergence sublayer is defined in Section 7 of this document.
38
CableLabs
04/22/09
5.6.2
CM-SP-RFIv2.0-C02-090422
PMD Sublayer
The Physical Media Dependent sublayer is defined in Section 6.

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.
04/22/09
CableLabs
39
CM-SP-RFIv2.0-C02-090422
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.
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 SCDMA 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.
40
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 15
The PMD sublayer also supports a synchronous mode of transmission when using S-CDMA, wherein ramp-down 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. 16
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 signal-processing
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
Figure 62. For S-CDMA mode, the signal processing order for each burst packet type MUST follow the order of
steps in Figure 63.
15
16
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.
04/22/09
CableLabs
41
CM-SP-RFIv2.0-C02-090422
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 S-CDMA
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.
Burst
data in
RS
Encoder
Byte
Interleaver
(TDMA only)
Scrambler
TCM Encoder
(S-CDMA only)
Framer
(S-CDMA only)
Symbol
Mapper
Spreader
(S-CDMA only)
Preamble
Prepend
Transmit
Equalizer
Filter
Modulator
RF out
Figure 61 Upstream signal-processing sequence
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 67)
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 62 TDMA Upstream Transmission Processing
42
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 67)
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
Spread the Symbols. For spreader-off bursts on S-CDMA channels,

spreader can be turned off.
Transmit
Equalize
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 63 S-CDMA Upstream Transmission Processing
6.2.3
Modulation Formats
The upstream modulator MUST provide QPSK and 16 QAM differential encoded modulations for TDMA.
The upstream modulator MUST provide QPSK, 8 QAM, 16 QAM, 32 QAM, and 64 QAM modulations for TDMA
and S-CDMA channels.
The upstream modulator MUST provide QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM and 128 QAM TCM
encoded modulations for S-CDMA channels.
The upstream demodulator MAY support QPSK and 16 QAM differential modulation for TDMA.
The upstream demodulator MUST support QPSK, 16 QAM, and 64 QAM modulations for TDMA and S-CDMA
channels.
The upstream demodulator MAY support 8 QAM and 32 QAM modulation for TDMA and S-CDMA channels.
04/22/09
CableLabs
43
CM-SP-RFIv2.0-C02-090422
The upstream demodulator MAY support QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM, and 128 QAM TCM
encoded modulations for S-CDMA channels.
6.2.4
6.2.4.1
R-S Encode
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.
6.2.5
R-S Frame Structure
Figure 64 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.
44
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Example 1. Packet length = number of information bytes in codeword = k
One Codeword
Preamble
FEC
Parity
Packet Data
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
First k Bytes
of Packet
Guard
Time
Two Codewords
FEC
Parity
mini-slot
boundary
Last k Bytes k-k bytes of

of Packet
zero-fill
FEC
Parity
Figure 64 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 61 below.
Table 61 Burst Size
IUC
Burst Size
1, 3
2
4-6, 9-11
6.2.5.1.2
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.
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 61 above,
accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any).
04/22/09
CableLabs
45
CM-SP-RFIv2.0-C02-090422
6.2.5.1.3
Shortened Last Codeword
As shown in Table 64, 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 61 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 61 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 61 above, accounting for preamble, FEC parity, return-to-zero bits and guardtime 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). 17
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 62 determine the operation of the interleaver for every
burst.
17
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
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 62 Interleaver Operating Parameters

Parameter
Definition
Allowed Values
Nr
Interleaver Width (RS Codeword Length, k+2*T)
18 to 255
Ir
Interleaver Depth
0 - Dynamic Mode
1 - No Interleaving
2 to floor(2048/Nr) for Fixed Mode
Br
Interleaver Block Size
2*Nr to 2048
Nf
Packet Size (in bytes, including FEC)
18 bytes
The CMTS and CM MUST use the interleaver parameters within the allowed values in Table 62 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.
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 65.
Write
C1(1)
C1(2)
C1 (Nr)
C2(1)
C2(2)
C2 (Nr)
CIr(1)
CIr(2)
CIr (Nr)
Read
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)
Figure 65 Byte Interleaver Operation
04/22/09
CableLabs
47
CM-SP-RFIv2.0-C02-090422
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.
Write
C1(1)
C1(2)
C2(1)
C2(2)
C1(N')
C1(Nr)
C2(Nr)
Ci'-1(N')
CI'(1)
CI'(2)
Ci'-1(Nr)
CI'(N')
Read
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 66 Interleaver operation for last interleaver block (with shortened last codeword)
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 66) 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 Section Figure 65 (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 66 (except that there are Ir(Ns0)rows instead of I').
48
CableLabs
04/22/09
6.2.6.2.2.1
CM-SP-RFIv2.0-C02-090422
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:
0
I tot
= ceil ( N f / N r ) .
I r ,max = floor ( Br / N r ) .
Number of segments:
0
N s0 = ceil ( I tot
/ I r ,max )
Interleaver depth of first block:
0
I r1 = floor ( I tot
/ N s0 )
1
No. of blocks with depth of I r :
0
M = N s0 ( I r1 + 1) I tot
(i )
Then for segment i, I r
0
is calculated as follows ( i = 1...N s ):
6.2.7
(i )
r
I r1 ,
i = 1,..., M
= 1
I r + 1, i = M + 1,..., N s0
Scrambler (Randomizer)
The upstream modulator MUST implement a scrambler (shown in Figure 67) 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.
04/22/09
CableLabs
49
CM-SP-RFIv2.0-C02-090422
SEEDLOAD / FRAME RESET
SEED
LSB
SEED
MSB
N = 15
DELAY
ELEMENT
1
DELAY
ELEMENT
2
DELAY
ELEMENT
N-2
DELAY
ELEMENT
3
DELAY
ELEMENT
N-1
DELAY
ELEMENT
N
XOR
RANDOMIZER
DATA
OUTPUT
RANDOMIZER
DATA
INPUT
XOR
Figure 67 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, 8 QAM, 16 QAM, 32 QAM, 64 QAM, and 128 QAM constellations, respectively.
Support of TCM in the CMTS is optional.
Figure 68 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 rate1/2 coding.
im
xm+1
i3
x4
3
i2
i1
x2
s2
s1
S-CDMA
Framing
symbol
labels
s0=x1
Figure 68 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 68, after three symbols the state bits s2, s1, and s0 =
x1 will be zero. Tail symbols are extra symbols, which carry no information.
50
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 i2i1 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 69 for m=1 to 6. In the figure bit i m is at the top and bit i 1 is at the bottom. 18
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 610 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.
m = 6 (128QAM)
1 2
3
m = 5 (64QAM)
4
5
m = 4 (32QAM)
1
2
m = 3 (16QAM)
m = 2 (8QAM)
m = 1 (QPSK)
Figure 69 Repetitive patterns of byte mapping to symbol map bits for TCM
18
04/22/09
CableLabs
51
CM-SP-RFIv2.0-C02-090422
zero fill
bits
bits to return
to zero state
redundant
code bits
zero
final
state
0
zero
initial
state
msb
1
.........
.........
msb
6
msb
4
.........
msb
2
msb
3
msb
8
msb
5
msb
Nf -1
msb
Nf -2
.........
msb
Nf
x6
x5
x4
x3
x2
x1
.........
.........
n p preamble
symbols
n i TCM
symbols
.........
.........
msb
6
msb
1
msb
4
msb
Nf -2
0
msb
Nf -1
...............
msb
2
msb
3
nt = 2
tail symbols
msb
5
msb
8
..
msb
Nf
0
0
..
..
n i TCM symbols, no
tail symbols (n
t = 0)
Figure 610 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. 19
Figure 611 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.
19
Section 6.2.8.1, second-to-last paragraph updated per RFI2-N-02111 by RKV on 10/29/02.
52
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
x6
x5
x4
x3
x2
x1
u
u
0
0
0
Figure 611 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 819, 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 618 and
Figure 619) 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.
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.
04/22/09
CableLabs
53
CM-SP-RFIv2.0-C02-090422
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 613 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.
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 mini-slot
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 are described
in Section 8.3.2 and Section.8.3.3.)
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.
54
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
K spreading intervals
Mini-slot m+62
Mini-slot m+125
Mini-slot m+188
code 127
code 126
...
...
...
code 3
Mini-slot m
Mini-slot m+63
Mini-slot m+126
code 2
code 1
code 0
t
frame f
timestamp counts
frame f+1
t1
t2
t3
frame f+2
t4
timestamp count
minislot number
frame
number
32 bits
32 bits
8 bits
Included
in UCD
timestamp snapshot
Figure 612 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.
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 (modulo256) boundary, as defined in Section 6.2.14.1.
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.
04/22/09
CableLabs
55
CM-SP-RFIv2.0-C02-090422
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 minislots (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 614.
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.
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:
56
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.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 mini-slot
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.
Mini-slot m+63
Mini-slot m+127
Mini-slot m+191
code 127
code 126
...
...
...
code 3
Mini-slot m+1
Mini-slot m+65
Mini-slot m+129
Mini-slot m
Mini-slot m+64
Mini-slot m+128
code 2
code 1
code 0
frame f
frame f+1
frame f+2
Figure 613 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 614. 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).
Mini-slot m+41
Mini-slot m+83
Mini-slot m+125
code 127
code 126
code 125
...
...
...
code 7
code 6
Mini-slot m+1
Mini-slot m+43
Mini-slot m+85
Mini-slot m
Mini-slot m+42
Mini-slot m+84
code 5
code 4
code 3
code 2
code 1
code 0
frame f
frame f+1
frame f+2
Figure 614 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.
04/22/09
CableLabs
57
CM-SP-RFIv2.0-C02-090422
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.
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 spreaderon 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 mini-slots 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 mini-slots,
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. 20
20
This paragraph updated by RKV per RFI2-N-02135 on 10/29/02, per RFI2-N-02173 on 10/30/02.
58
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
128*K modulation intervals
code 127
Mini-slot m+63
Mini-slot m+191
Mini-slot m+127
Mini-slot m+69
Mini-slot m+68
Mini-slot m+67
Mini-slot m+66
Mini-slot m+1
Mini-slot m+65
code 3
Mini-slot m+64
code 126
Mini-slot m+129
code 2
code 1
Mini-slot m
Mini-slot m+128
code 0
frame f
frame f+1
frame f+2
Spreader-on frame
Spreader-off frame
Spreader-on frame
Figure 615 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 mini-slot (dead time), immediately after these
bursts, and before a spreader-on interval starts. 21
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.
6.2.11.6 Limiting the Number of Codes Assigned to a CM 22
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
21
22
Added last sentence to this paragraph per ECN RFI2-N-02227 by GO on 03/20/03.

Added this subsection per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.
04/22/09
CableLabs
59
CM-SP-RFIv2.0-C02-090422
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. To support 1.0 style configuration files, a CM and CMTS using the Maximum Scheduled Codes value
SHOULD support fragmentation in 1.0 mode. 23
If a UGS flow is requested to provide an Unsolicited Grant Size greater than the value permitted by the Maximum
Scheduled Codes value, the CMTS MUST reject the request for the UGS flow or change the CM's Maximum
Scheduled Codes value such that it would permit the UGS grants. 24
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. 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.
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 616 shows a subframe consisting of R rows and K spreading intervals
within an S-CDMA frame.
23
24
Revised this paragraph per ECN RFIv2.0-N-04.0203-2 by GO on 2/21/05.

60
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
frame length(K)
Number of Active
Codes (N)
R codes
Other subframes
Row R
Row 2
Row 1
Other subframes
Spreading Interval
(K-1)
Figure 616 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.
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 616 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.
04/22/09
CableLabs
61
CM-SP-RFIv2.0-C02-090422
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. 25
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.
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 non-zero
power. 26
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 617 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.
25
26
Section 6.2.12.2.1, numbered paragraph 6 updated per RFI2-N-02135 by RKV on 10/29/02.

Section updated per RFI2-N-02135 by RKV on 10/29/02.
62
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
3 rows
frame length
U1
C14
U3
C17
U6
C20
U8
C15
U11
C18
U14
C21
U16
C16
U19
C19
U22
C22
U0
C5
U2
C8
U5
C11
U7
C6
U10
C9
U13
C12
U15
C7
U18
C10
U21
C13
P0
P3
U4
C2
P1
U9
C0
U12
C3
P2
U17
C1
U20
C4
step=3
Figure 617 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 616, 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 63. In the table, x1 represents the LSB of each of the symbol maps and x2, x3, x4, 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 618. This defines each QAM symbol with 5-bit
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 618, 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.
04/22/09
CableLabs
63
CM-SP-RFIv2.0-C02-090422
Table 63 I/Q Mapping

QAM Mode
Input bit Definitions
QPSK
x2x1
8QAM
x3x2x1
16QAM
x4x3x2x1
32QAM
x5x4x3x2x1
64QAM
x6x5x4x3x2x1
128QAM
x7x6x5x4x3x2x1
The upstream symbol constellations MUST be as shown in Figure 618.

The upstream QPSK Gray-coded and differential symbol mapping MUST be as shown in Figure 619.
The upstream 8QAM symbol mapping MUST be as shown in Figure 620.
The upstream 16QAM Gray-coded symbol mapping MUST be as shown in Figure 621.
The upstream 16QAM differential symbol mapping MUST be as shown in Figure 621.
The upstream 32QAM symbol mapping MUST be as shown in Figure 622.
The upstream 64QAM Gray-coded symbol mapping MUST be as shown in Figure 623.
The TCM symbol mapping used for S-CDMA are shown in Figure 624 through Figure 626.
The upstream QPSK TCM symbol mapping MUST be as shown in Figure 624.
The upstream 8QAM TCM symbol mapping MUST be as shown in Figure 624.
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 64. 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 64, I(1)Q(1) refers to x2x1 and x4x3 from Table 63 for QPSK and 16QAM cases
respectively.
64
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 64 Definition of Differential Quadrant Coding
04/22/09
Current Input
Quadrant Phase
MSBs of Previously
MSBs for Currently
Bits I(1) Q(1)
Change
Transmitted Symbol
Transmitted Symbol
00
11
11
00
01
01
00
00
00
00
10
10
01
90
11
01
01
90
01
00
01
90
00
10
01
90
10
11
11
180
11
00
11
180
01
10
11
180
00
11
11
180
10
01
10
270
11
10
10
270
01
11
10
270
00
01
10
270
10
00
CableLabs
65
CM-SP-RFIv2.0-C02-090422
QPSK0: Eav = 128 (Gconst = -1.18 dB rel to 64QAM)

QPSK1: Eav = 288 (Gconst = +2.34 dB)
8QAM-DS: Eav = 160 (Gconst = -0.21 dB)
Imaginary part
(quadrature)
+15
+12
+12
QPSK1
+8
QPSK0
+4
Real part
(in-phase)
0
-4
-8
-12
-12
-15
-15 -12
-8
+8
+12 +15
-12
-4
+4
+12
32QAM-DS: Eav = 168 (Gconst = 0 dB)
16QAM-SQ: Eav = 160 (Gconst = -0.21 dB)
+14
+12
+10
+6
+4
+2
-2
-4
-6
-10
-12
-14
-12
-4
+4
+12
-14
64QAM-SQ: Eav = 168 (Gconst = 0 dB)
-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
+14
+10
+6
+2
-2
-6
-10
-14
-14
-10
-6
-2
+2
+6
+10
+14
-15-13-11 -9 -7 -5 -3 -1 +1 +3 +5 +7+9+11+13+15
Figure 618 Symbol Constellations
66
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Q
Label bits x2x1 (I,Q)
01
11
00
10
Figure 619 QPSK Gray and Differential Symbol Mapping
Q
Label bits x3x2x1
101
2
111
110
011
I
001
010
Gray-code
violation
100
000
Figure 620 8QAM Symbol Mapping
04/22/09
CableLabs
67
CM-SP-RFIv2.0-C02-090422
Label bits x4x3x2x1
0111
0101
1101
1111
0111
0110
1101
1111
0110
0100
1100
1110
0101
0100
1100
1110
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
Q
11010
10010
10111
11111
Label bits x5x4x3x2x1
11011
01010
10110
2
11101
01011
01110
11110
2
11001
11000
01001
01101
00110
00111
00010
01000
01111
01100
00101
00011
10000
00100
00001
10011
10100
10101
11100
00000
10001
68
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Binary labels x 3x2x1
Binary labels x 2x1
111
01
101
00
010
000
001
10
011
11
100
110
Figure 624 QPSK and 8QAM TCM Symbol Mapping
04/22/09
CableLabs
69
CM-SP-RFIv2.0-C02-090422
Octal labels o 2o1 (= bin. labels x 4 x3x2x1)
Octal labels o 2o1 (= bin. lab. x 5x4x3x2x1 )
23
13
16
07
12
04
01
00
15
17
02
03
06
10
05
14
11
26
31
34
15
10
07
33
20
24
00
04
37
32
03
06
17
12
21
05
01
25
Subset B0
16
02
36
13
11
14
35
30
27
22
Subset B1
Figure 625 16QAM and 32QAM TCM Symbol Mapping
64QAM: octal labels o 2o1

(= bin. lab. x 6x5x4x3x2x1)
128QAM: octal labels o 3o2o1

(= bin. lab. x 7x6x5x4x3x2x1 )
43
46
77
62
23
26
57
42
54
51
70
65
34
31
50
45
27
32
13
16
07
12
73
76
20
35
04
01
00
15
64
61
63
66
17
02
03
06
37
22
74
71
10
05
14
11
30
25
47
52
33
36
67
72
53
56
40
55
24
21
60
75
44
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
Subset B0
Subset B1
Figure 626 64QAM and 128QAM TCM Symbol Mapping
70
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 x127 x 2 1
c 127, 127 c127, 126 c127, 0
x2
C = c 126, 127 c126, 126 c126, 0 =

x 127
c 0, 127 c0, 126 c0, 0
1
x1 x 3 1
1
x126 x 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.
04/22/09
CableLabs
71
CM-SP-RFIv2.0-C02-090422
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 68).
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
C k = 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,
f (k , i ) =
mod ulo ((128 lsr _ out ( k )+1),128 ),

mod ulo ((126 lfsr _ out ( k )+1),127 ) +1
128 ActiveCodes
<128 ActiveCodes
0 i 127
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 627. 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. 27
(The description of the frame counter and the procedures for its synchronization are contained in Section 6.2.11.2).
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 (LFSR, spreading interval index) is advanced every
spreading interval (128 modulation intervals) in both spreader-on and spreader-off frames.
27
Text from In order to align to this footnote, updated per RFI2-N-02123 by RKV on 10/29/02.
72
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Initialization value (seed)
10
11
modulo(128) or
12
13
14
15
Random Offset
lfsr_out
modulo(127) +1
Figure 627 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 628, 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.
I-Q
Input
Z -1
F1
F2
Z -1
F3
Z -1
...
Z -1
F4
Z -1
F 17
...
Z -1
F18
F 24
...
...
Equalizer
Output
Figure 628 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).
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:
04/22/09
CableLabs
73
CM-SP-RFIv2.0-C02-090422
min ( 24 L
m+ 1
Fn
m+ 1
=
k = m ax (1 L
,n +L L
m+1
m+ 1
1)
F
m
,n+L L
m+ 1
m
m
n k +L L
m+ 1
F k + Lm + 1 ,
n=1...24
24 )
where:
m
F n are the coefficients prior to the convolution

m+1
Fn
are the coefficients after the convolution
F n are the coefficients sent from the CMTS

m
L is the main tap location prior to the convolution

L
m+1
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 preequalizer capabilities that the CMTS learned from the REG-REQ message modem capabilities field. See
Section 8.3.8.1.1 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 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.
74
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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 roll-off
factor alpha =0.25. The -30dB transmitted bandwidth MUST NOT exceed the Channel Width values in Table 65.
The Channel Width values are given analytically by:
ChannelWidth = ModulationRate*(1+alpha).
Table 65 Maximum Channel Width
Modulation Rate (kHz)
Channel Width (kHz)
160
200
320
400
640
800
1,280
1,600
2,560
3,200
5,120
6,400
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 68. 28
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.
28
Section 6.2.16.1, second paragraph updated per RFI2-N-02104 by RKV on 10/28/02.
04/22/09
CableLabs
75
CM-SP-RFIv2.0-C02-090422
The CM MAP processing delay, Dp, is given by the equations:

D
= 200 +
IrN r,
M =
B ,
r
M
sec,
5 . 12
Ir 0
Ir = 0
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 S-CDMA frame which contains the burst.
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 68.
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 66 (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.
76
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 66 Constellation Gains and Power Limits

Constellation
Constellation
Gain Gconst
Relative to
64QAM (dB)
Pmin
(dBmV)
Pmax
(dBmV)
TDMA
Pmax
(dBmV)
S-CDMA
Pmin Gconst
(dBmV)
Pmax Gconst
(dBmV)
TDMA
Pmax Gconst
(dBmV)
S-CDMA
QPSK
-1.18
58
53
9.18
59.18
54.18
8QAM
-0.21
55
53
8.21
55.21
53.21
16QAM
-0.21
55
53
8.21
55.21
53.21
32QAM
0.00
54
53
8.00
54.00
53.00
64QAM
0.00
54
53
8.00
54.00
53.00
128QAM
0.05
N/A
53
7.95
N/A
52.95
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. 29
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:
(1) Pr = Pr + P
//Add power level adjustment to reported power level
(2) Pr = min[Pr, Phi]

(3) Pr = max[Pr, Plow]
//Clip at max power limit

//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
29
Added this sentence per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.
04/22/09
CableLabs
77
CM-SP-RFIv2.0-C02-090422
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 Calculations 30
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)
(1) Pr = Pr + P


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
30
Revised this subsection per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.
78
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 31
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 68).
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 68)
Pmax_T = Maximum target transmit power permitted for the CM in TDMA mode (see Table 68) for the
constellation used in ranging.
Phi_T = min[Pmax_T - Gconst] over all spreader-off burst profiles used by the CM (see Table 68).
Pon = Pr clipped at the maximum spreader-on limit.
Psf = CM Power Shortfall per Section 8.3.5 and Section 8.3.26.
Phr = S-CDMA Power Headroom in dB. Equivalent to TLV-11 defined in Table 821 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:
(1) Psf = Pr + max[Gconst,i] - 53
powers 32
31
// Difference between spreader-off reported and max spreader-on target
First two sentences of this paragraph updated per RFI2-N-02105 by RKV on 10/28/02.
04/22/09
CableLabs
79
CM-SP-RFIv2.0-C02-090422
(2) Psf = max[Psf, 0]
// 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 = 10log
N alloc
10
Pt ,i /10
i =1
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:
N act
Peff = 10log 10 t ,i
P /10
i =1
= Pon + Phr + 10log
1
N act
N act
10
Gconst ,i /10
i =1
where the last term is the average constellation gain.

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
32
Revised this statement per ECN RFIv2.0-N-05.0237-2 by GO on 7/15/05.
80
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
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 818; these characteristics are shared by all users on a given channel. The Burst Profile Attributes are
listed in Table 67, and are further described in Section 8.3.3, Table 819; 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).
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). 33
33
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.
04/22/09
CableLabs
81
CM-SP-RFIv2.0-C02-090422
Table 67 Burst Profile Attributes

Burst Profile Attributes
Configuration Settings
Modulation
QPSK, 8 QAM, 16 QAM, 32 QAM, 64 QAM, 128 QAM(TCM Only)
Differential Encoding
On/Off
TCM Encoding
On/Off
Preamble Length
0-1536 bits (Note Section 6.2.9)
Preamble Value offset
0 to 1534
R-S FEC Error Correction (T)
0 to 16 (0 implies no R-S FEC. The number of codeword parity bytes is 2*T)
R-S FEC Codeword Information Bytes (k)
Fixed: 16 to 253 (assuming R-S FEC on)

Shortened: 16 to 253 (assuming R-S FEC on)
Scrambler Seed
15 bits
1
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
Fixed, shortened
Scrambler On/Off
On/Off
2
Byte Interleaver Depth (Ir)
0 to floor(2048/Nr)
4
Byte Interleaver Block Size (Br)
2*Nr to 2048
Preamble Type
QPSK0/QPSK1
5
S-CDMA Spreader
On/Off
5
S-CDMA Codes per Subframe
1 to 128
S-CDMA Interleaver Step

1
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.
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 68: 34
Table 68 User Unique Burst Parameters
User Unique Parameter
Power Level
Adjustment Command
Resulting Parameter Value
8-bit two's complement,

resolution = 0.25 dB
TDMA:
Offset Frequency
Range = 32 kHz, resolution = 1 Hz
Frequency Range per Section 6.2.16.1
Ranging Offset
Integer part: 32-bit two's complement,

resolution = (1 / 10.24 MHz) = 6.25 sec/64
= 97.65625 ns
Range: sufficient for maximum cable plant length

per Section 4.1.
Fractional part: unsigned 8-bit fractional

extension, resolution = 6.25 sec/(64*256) =
0.3814697265625 nsec
Resolution: TDMA: 6.25 sec/64. S-CDMA: 6.25

sec/(64*256)
+8 to +54 dBmV (32QAM, 64QAM)

+8 to +58 dBmV (QPSK) S-CDMA:
+8 to +53 dBmV (all modulations)
Resolution = 1 dB or better
34
Table 6-8 replaced per RFI2-N-02104 by RKV on 10/28/02.
82
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Adjustment Command
Burst Length (mini-slots) if

variable on this channel
(changes burst-to-burst)
N/A
1 to 255 mini-slots
Transmit Equalizer
Coefficients
DOCSIS 2.0 mode: 24 complex coefficients,

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

coefficients, 4 bytes per coefficient (2 real
and 2 imaginary), convolve mode only
DOCSIS 1.1 mode: up to 64 complex coefficients
(See Section 6.2.15.)
The CM MUST implement the Offset Frequency Adjustment to effect a change in upstream carrier frequency
within 10 Hz of the commanded change. 35
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.
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. 36
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
35
36
Section 6.2.19, last paragraph updated per RFI2-N-02104 by RKV on 10/28/02.

Section 6.2.19.1, all three paragraphs replaced per RFI2-N-02104 by RKV on 10/29/02.
04/22/09
CableLabs
83
CM-SP-RFIv2.0-C02-090422
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). 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.
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.
84
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
Modulation Rate
Timing Offset (in units of 1/64 time

ticks referenced to 5.12 MHz)
5.12 MHz
0 (reference)
2.56 MHz
1.28 MHz
24
0.64 MHz
72
0.32 MHz
168
0.16 MHz
360
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. 37
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. 38
37
38
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.
04/22/09
CableLabs
85
CM-SP-RFIv2.0-C02-090422
6.2.20 Burst Timing Convention
Figure 629 illustrates the nominal burst timing for TDMA channels.
Figure 629 Nominal TDMA Burst Timing
86
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Figure 630 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.
Burst N+1
Worst case Burst timing

input to CMTS
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 center of
Burst N+1, last symbol;
1.5 symbols early
8 symbol guard
band
1.5
5 symbols
1.5
Minislot
Boundary
Figure 630 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.
04/22/09
CableLabs
87
CM-SP-RFIv2.0-C02-090422
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 68.
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 69, Table 610, and Table 611.
In Table 69, 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 69, allowed to be excluded from
the Bands within 5 to 42 MHz Transmitting Burst specs of Table 611. 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 69 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.
Table 69 Spurious Emissions
Parameter
Transmitting Burst
Between Bursts
Inband
-40 dBc
The greater of -72 dBc or -59 dBmV
Adjacent Band
See Table 610.
3 or Fewer Carrier-Related Frequency Bands (such as

second harmonic, if < 42 MHz)
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)
See Table 611
42 to 54 MHz
54 to 60 MHz
60 to 88 MHz
88- to 860 MHz
max(-40 dBc, -26 dBmV)

-35 dBmV
-40 dBmV
-45 dBmV
-26 dBmV
-40 dBmV
-40 dBmV
2
max(-45 dBmV, -40 dB ref d/s )
88
CableLabs
CM Integrated Spurious Emissions Limits (all in 4 MHz,

1
includes discretes)
04/22/09
CM-SP-RFIv2.0-C02-090422
Parameter
Transmitting Burst
CM Discrete Spurious Emissions Limits
Between Bursts
42 to 54 MHz
54 to 88 MHz
88 to 860 MHz
-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.
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.
Table 610 Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level
Transmitted carrier
Specification in the
Specification in
Measurement interval and
Adjacent channel carrier
modulation rate
interval, Region 1
the interval,
distance from carrier edge
modulation rate
Region 2
All modulation rates
-47 dBc
-45 dBc
20 kHz to 180 kHz
160 kHz
-47 dBc
-45 dBc
40 kHz to 360 kHz
320 kHz
-46 dBc
-45 dBc
80 kHz to 720 kHz
640 kHz
-45 dBc
-44 dBc
160 kHz to 1440 kHz
1280 kHz
-44 dBc
-41 dBc
320 kHz to 2880 kHz
2560 kHz
-42 dBc
-38 dBc
640 kHz to 5760 kHz
5120 kHz
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 611 Spurious Emissions in 5 to 42 MHz Relative to the Transmitted Burst Power Level
Possible modulation rate in this
Initial measurement interval and distance
interval
interval, Region 1
interval, Region 2
from carrier edge
160 kHz
-54 dBc
-53 dBc
220 kHz to 380 kHz
320 kHz
-52 dBc
-50 dBc
240 kHz to 560 kHz
640 kHz
-50 dBc
-47 dBc
280 kHz to 920 kHz
1280 kHz
-48 dBc
-44 dBc
360 kHz to 1640 kHz
04/22/09
CableLabs
89
CM-SP-RFIv2.0-C02-090422
Possible modulation rate in this
Initial measurement interval and distance
interval
interval, Region 1
interval, Region 2
from carrier edge
2560 kHz
-46 dBc
-41 dBc
520 kHz to 3080 kHz
5120 kHz
-44 dBc
-38 dBc
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.
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:
Eav
MERsymb ( dB ) = 10 log10
1 N
e j 2
N j =1
where:
Eav is the average constellation energy for equally likely symbols (see Section 6.2.13 and Figure 618)
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 618.
For S-CDMA, MERsymb is averaged over all active codes.
90
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 Pk defined in Section 6.2.14.
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 computed by the
formula:
2
N
pj
j =1
MERchip ( dB ) = 10 log10 N
2
p j r j
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 68 for each modulation, each modulation rate, and over the full carrier frequency range, and for S-CDMA,
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
Case 1b: for modulation rate 5.12 MHz
MERsymb >= 27 dB over 15 to 30 MHz carrier frequency
Case 2: Flat channel, transmit equalization ON
04/22/09
CableLabs
91
CM-SP-RFIv2.0-C02-090422
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 42, 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 42 (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.
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 612.
Table 612 Filter Amplitude Distortion
Frequency
Amplitude Range
low
high
fc - 5Rs/8
-30dB
fc - Rs/2
-3.5dB
-2.5dB
fc - 3Rs/8 to fc - Rs/4
-0.5dB
+0.3dB
fc - Rs/4 to fc + Rs/4
-0.3dB
+0.3dB
fc + Rs/4 to fc + 3Rs/8
-0.5dB
+0.3dB
fc + Rs/2
-3.5dB
-2.5dB
fc + 5Rs/8
-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.
92
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normal
synchronous operation. 39
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 Modulation Timing Jitter
6.2.21.8.1 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.1-sec
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.
39
Section 6.2.21.5, text from The CM MUST provide to footnote updated per RFI2-N-02102
by RKV on 10/28/02.
04/22/09
CableLabs
93
CM-SP-RFIv2.0-C02-090422
6.2.21.8.2 Chip Timing Jitter for Synchronous Operation
All jitter specifications assume a downstream input to the CM per Sections 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.
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 613.
Table 613 Maximum Range of Commanded Nominal Receive Power in Each Carrier
Modulation Rate (kHz)
Maximum Range (dBmV)
160
-16 to +14
320
-13 to +17
640
-10 to +20
1,280
-7 to +23
2,560
-4 to +26
5,120
-1 to +29
The demodulator MUST operate within its defined performance specifications with received bursts within 6 dB of
the nominal commanded received power.
94
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
6.2.23 Upstream Electrical Output from the CM
The CM MUST output an RF modulated signal with the characteristics delineated in Table 614.
Table 614 Electrical Output from CM
Parameter
Value
Frequency
Level range (one channel)
TDMA:
+8 to +58 dBmV (QPSK)
S-CDMA:
+8 to +53 dBmV (all modulations)
Modulation Type
QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM
Modulation Rate (nominal)
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
75 ohms
Output Return Loss
> 6 dB (5-42 MHz)
Connector
F connector per [ISO-169-24] (common with the input)
6.3
Downstream
This DOCSIS 2.0 Downstream Specification applies only to a CMTS supporting exactly one QAM channel per RF
output port. A CMTS supporting more than one QAM channel per RF output port would instead conform to the
DOCSIS Downstream Radio Frequency Interface [DRFI] specification in lieu of this Downstream section.40
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 615. The table contains a subset of interleaver modes found in [ITU-T J.83-B].
Table 615 Interleaver Characteristics
I (Number of Taps)
J (Increment)
Burst Protection
Latency 64QAM/256QAM
64QAM/256QAM
40
16
5.9 sec/4.1 sec
0.22 msec/0.15 msec
16
12 sec/8.2 sec
0.48 msec/0.33 msec
Added this paragraph per ECN RFIv2.0-N-05.0227-2 by GO on 7/15/05.
04/22/09
CableLabs
95
CM-SP-RFIv2.0-C02-090422
I (Number of Taps)
J (Increment)
Burst Protection
64QAM/256QAM
32
24 sec/16 sec
0.98 msec/0.68 msec
64
47 sec/33 sec
2.0 msec/1.4 msec
128
95 sec/66 sec
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.
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 the table below.
Table 616 CMTS Output
Parameter
Value
1
Center Frequency (fc)
91 to 857 MHz 30 kHz
Level
Adjustable over the range 50 to 61 dBmV
Modulation Type
64 QAM and 256 QAM
Symbol Rate (nominal)

64QAM
5.056941 Msym/sec
256QAM
5.360537 Msym/sec
Nominal Channel Spacing
6 MHz
Frequency response
64QAM alpha
~0.18 Square Root Raised Cosine shaping
256QAM alpha
~0.12 Square Root Raised Cosine shaping
Total Discrete Spurious Inband (fc 3 MHz)
< -57 dBc
Inband Spurious and Noise (fc 3 MHz)
< -48 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.
Adjacent channel (fc 3.0 MHz) to (fc 3.75 MHz)
< -58 dBc in 750 kHz
Adjacent channel (fc 3.75 MHz) to (fc 9 MHz)
< -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
Next adjacent channel (fc 9 MHz) to (fc 15 MHz)
Less than the greater of -65 dBc or -12 dBmV in 6 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.
Other channels (47 MHz to 1,000 MHz)
< -12 dBmV 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 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
96
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Parameter
Value
50 kHz - 3 MHz: -51 dBc double sided noise power
Output Impedance
75 ohms
Output Return Loss
> 14 dB within an output channel up to 750 MHz; > 13 dB in an output

channel above 750 MHz
Connector
F connector per [ISO-169-24]
30 kHz includes an allowance of 25 kHz for the largest FCC frequency offset normally built into upconverters.
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 [EIA-S542]
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 617.
Table 617 Electrical Input to CM
Parameter
Value
Center Frequency
91 to 857 MHz 30 kHz
Level Range (one channel)
-15 dBmV to +15 dBmV
Modulation Type
64 QAM and 256 QAM
5.056941 Msym/sec (64QAM) and 5.360537 Msym/sec (256 QAM)
Bandwidth
6 MHz (alpha = 0.18 Square Root Raised Cosine shaping for 64 QAM and alpha = 0.12
Square Root Raised Cosine shaping for 256 QAM)
Total Input Power (40-900 MHz)
<30 dBmV
Input (load) Impedance
75 ohms
Input Return Loss
> 6 dB (88-860 MHz)
Connector
F connector per [ISO-169-24] (common with the output)
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.
04/22/09
CableLabs
97
CM-SP-RFIv2.0-C02-090422
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.
6.3.6.2
256QAM
6.3.6.2.1
when operating at a carrier to noise ratio (Es/No) as shown below.
Input Receive Signal Level
Es/No
-6 dBmV to +15dBmV
30dB or greater
Less than -6dBmV down to -15dBmV
33dB 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
Performance as described in Section 6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with a digital
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.
98
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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. 41 [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)
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.
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.
41
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.
04/22/09
CableLabs
99
CM-SP-RFIv2.0-C02-090422
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. 42
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 618 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 618 Downstream symbol rates and example parameters for synchronization with the CMTS Master
Clock
Downstream mode
Nominal
M/N
Specified Symbol
CMTS Master Clock
Downstream Symbol
Offset from
Rate, fm' (MHz)
Rate, fb' (MHz)
Nominal
Rate, fb (MHz)
Annex B, 64QAM
5.056941
401/812
10.239990...
5.056945...
0.95 ppm
Annex B, 256QAM
5.360537
78/149
10.240000...
5.360536...
0.02 ppm
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)
10 Hz to 100 Hz
100 Hz to 1 kHz
1 kHz to 10 kHz
10 kHz to 100 kHz
< [-30 + 20*log(fDS/5.057)] dBc (i.e., < 1 nsec RMS)
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:
42
Deleted (Sync mode = 0) from paragraph per ECN RFI2-N-02210, by GO, on 11/21/02.
100
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
101
CM-SP-RFIv2.0-C02-090422
7 DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER

7.1
Introduction
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 71 illustrates the interleaving of Data-Over-Cable (DOC) MAC bytes with other digital information (digital
video in the example shown).
header=DOC
DOC MAC payload
header=video
digital video payload
header=video
header=DOC
DOC MAC payload
header=video
header=DOC
DOC MAC payload
header=video
header=video
header=video
Figure 71 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 72. 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 72 Format of an MPEG Packet
102
CableLabs
04/22/09
7.3
CM-SP-RFIv2.0-C02-090422
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 71. 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 71. 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 71 MPEG Header Format for DOCSIS Data-Over-Cable Packets
Field
Length (bits)
Description
sync_byte
0x47; MPEG Packet Sync byte
transport_error_indicator
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
payload_unit_start_indicator
A value of one indicates the presence of a pointer_field as the first byte of the
payload (fifth byte of the packet)
transport_priority
Reserved; set to zero
PID
13
DOCSIS Data-Over-Cable well-known PID (0x1FFE)
transport_scrambling_control
Reserved, set to 00
adaptation_field_control
01; use of the adaptation_field is NOT ALLOWED on the DOCSIS PID
continuity_counter
cyclic counter within this PID
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.
04/22/09
CableLabs
103
CM-SP-RFIv2.0-C02-090422
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 73 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 73 Packet Format Where a MAC Frame Immediately Follows the pointer_field
Figure 74 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. Null MPEG 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. 43
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 74 Packet Format with MAC Frame Preceded by Stuffing Bytes
Figure 75 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 75 Packet Format Showing Multiple MAC Frames in a Single Packet
Figure 76 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.
43
104
CableLabs
04/22/09
MPEG Header
(PUSI = 1)
pointer_field
(= 0)
MPEG Header
(PUSI = 0)
MPEG Header
(PUSI = 1)
CM-SP-RFIv2.0-C02-090422
stuff_bytes
(0 or more)

(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)

(M bytes)
Figure 76 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.
04/22/09
CableLabs
105
CM-SP-RFIv2.0-C02-090422
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
8.1.2.1
Definitions
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.
106
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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).
Unicast flows on different logical upstreams that are attached to a single MAC-sublayer domain MAY be assigned
the same SID, as long as the SFIDs are unique. 44
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 mini-slot. 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 820 and allowed use is
defined in Section 8.3. The binding of these values to physical-layer parameters is defined in Table 818.
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.
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
44
Added this paragraph per ECN RFIv2.0-N-0226-2 by GO on 7/14/05.
04/22/09
CableLabs
107
CM-SP-RFIv2.0-C02-090422
codes, and number of spreading intervals configured for the upstream channel. 45 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 83), 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. 46
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 SCDMA 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
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.
45
46
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.
108
CableLabs
04/22/09
8.1.2.7
CM-SP-RFIv2.0-C02-090422
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 SCDMA 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
8.2.1
MAC Frame Formats

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 81. 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.
Figure 81 Generic MAC Frame Format
04/22/09
CableLabs
109
CM-SP-RFIv2.0-C02-090422
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 82.
Upper Layer
MAC Frame
MAC Frame
MAC Frame
MAC Sublayer
PMD Sublayer
Start of Burst at
Mini-slot
boundary
PMD
overhead
Data
FEC
Start of Burst at
Mini-slot
boundary
PMD
overhead
Data
PMD
overhead
FEC
Start of Burst at
Mini-slot
boundary
PMD
overhead
Data
FEC
Data
FEC
Data
FEC
PMD
overhead
PMD
overhead
Figure 82 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. 47
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.
47
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.
110
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 82, 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 TLV-tuples.
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 83.

FC
(1 byte)
FC TYPE
(2 bits)
MAC_PARM
(1 byte)
FC PARM
(5 bits)
LEN (SID)
(2 bytes)
EHDR
(0-240 bytes)
HCS
(2 bytes)
EHDR_ON
(1 bit)
Figure 83 MAC Header Format
All MAC Headers MUST have the general format as shown in Table 81. 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.
Table 81 Generic MAC Header Format
MAC Header Field
Usage
Size
FC
Frame Control: Identifies type of MAC Header
8 bits
MAC_PARM
Parameter field whose use is dependent on FC:
8 bits
if EHDR_ON=1; used for EHDR field length (ELEN)

else if for concatenated frames (see Table 810) 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.)
EHDR
Extended MAC Header (where present; variable size)
HCS
MAC Header Check Sequence
0-240 bytes
2 bytes
Length of a MAC Header
04/22/09
16 bits
6 bytes + EHDR
CableLabs
111
CM-SP-RFIv2.0-C02-090422
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 82.
Table 82 FC Field Format
FC Field
FC_TYPE
Usage
MAC Frame Control Type field:
Size
2 bits
00: Packet PDU MAC Header

01: ATM PDU MAC Header
10: Reserved PDU MAC Header
11: MAC Specific Header
FC_PARM
Parameter bits, use dependent on FC_TYPE.
5 bits
EHDR_ON
When = 1, indicates that EHDR field is present.
1 bit
[Length of EHDR (ELEN) determined by MAC_PARM field]
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 interoperable 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.
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 MACSpecific 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.
112
CableLabs
04/22/09
8.2.2
CM-SP-RFIv2.0-C02-090422
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 84 and
Table 83.
FC
(1 byte)
FC TYPE
= 00
MAC_PARM
(1 byte)
FC PARM
= 00000
LEN
(2 bytes)
EHDR_ON
=0
HCS
(2 bytes)
DA
(6 bytes)
SA
(6 bytes)
Packet PDU1
(18-1518 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 84 Ethernet/802.3 Packet PDU Format
Table 83 Packet PDU Format

Field
FC
Usage
FC_TYPE = 00; Packet MAC Header
Size
8 bits
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
MAC_PARM = x; MUST be set to zero if there is no EHDR;
8 bits
Otherwise set to length of EHDR

LEN
LEN = n+x; length of Packet PDU in bytes + length of EHDR
EHDR
Extended MAC Header, if present
16 bits
x (0-240) bytes
HCS
16 bits
Packet Data Packet PDU:
DA - 48 bit Destination Address
n bytes
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
Under certain circumstances (see Appendix 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.
04/22/09
CableLabs
113
CM-SP-RFIv2.0-C02-090422
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.
The format of the Reserved PDU without an extended header MUST be as shown in Table 84 and Figure 85.
FC
(1 byte)
FC TYPE
= 10
MAC_PARM
(1 byte)
FC PARM
= RRRRR
LEN
(2 bytes)
HCS
(2 bytes)
Reserved PDU
(n bytes)
EHDR_ON
=0
Figure 85 Reserved PDU Format
Table 84 Reserved PDU Format

Field
FC
Usage
Size
FC_TYPE = 10; Reserved PDU MAC Header
8 bits
FC_PARM[4:0]; reserved for future use

MAC_PARM
8 bits

LEN
LEN = n+x; length of Reserved PDU + length of EHDR in bytes
16 bits
EHDR
x (0-240) bytes
HCS
16 bits
Reserved Data PDU
n bytes
Length of Reserved PDU MAC frame
6 + x + n bytes
User Data
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 85 describes FC_PARM usage within the MAC Specific Header.
114
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 85 MAC-Specific Headers and Frames

FC_PARM
8.2.5.1
Header/Frame Type
00000
Timing Header
00001
MAC Management Header
00010
Request Frame
00011
Fragmentation Header
11100
Concatenation Header
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 86 and Table 86.
FC
(1 byte)
FC TYPE
= 11
MAC_PARM
(1 byte)
FC PARM
= 00000
LEN
(2 bytes)
HCS
(2 bytes)
Packet PDU
(various lengths)
EHDR_ON
=0
Figure 86 Timing MAC Header
Table 86 Timing MAC Header Format

Field
FC
Usage
Size
FC_TYPE = 11; MAC Specific Header
8 bits
FC_PARM[4:0] = 00000; Timing MAC Header

EHDR_ON = 0; Extended header prohibited for SYNC and RNG-REQ
MAC_PARM
Reserved for future use
8 bits
LEN
LEN = n; Length of Packet PDU in bytes
16 bits
EHDR
Extended MAC Header not present
0 bytes
HCS
2 bytes
Packet Data
MAC Management message:
n bytes
SYNC message (downstream only)

RNG-REQ (upstream only)
Length of Timing Message MAC frame
8.2.5.2
6 + n bytes
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 87 and Table 87.
04/22/09
CableLabs
115
CM-SP-RFIv2.0-C02-090422
FC
(1 byte)
FC TYPE
= 11
MAC_PARM
(1 byte)
FC PARM
= 00001
LEN
(2 bytes)
HCS
(2 bytes)
MAC mgmt msg

(24-1522 bytes)
EHDR_ON
=0
Figure 87 Management MAC Header

Table 87 MAC Management Format
Field
FC
Usage
Size
8 bits
FC_PARM[4:0] = 00001; Management MAC Header

MAC_PARM
8 bits

LEN
LEN = n+x; length of MAC management message + length of EHDR in bytes
EHDR
HCS
Packet Data
MAC management message
n bytes
Length of Packet MAC frame
6 + x + n bytes
8.2.5.3
16 bits
x (0-240) bytes
16 bits
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 the
Request MUST be as shown in Figure 88 and Table 88.
FC
(1 byte)
FC TYPE
= 11
MAC_PARM
(1 byte)
FC PARM
= 00010
SID
(2 bytes)
HCS
(2 bytes)
EHDR_ON
=0
Figure 88 Request Frame Format
116
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 88 Request Frame (REQ) Format 48

Field
FC
Usage
Size
FC_TYPE = 11; MAC-Specific Header
8 bits
FC_PARM[4:0] = 00010; MAC Header only; no data PDU following

EHDR_ON = 0; No EHDR allowed
MAC_PARM
REQ, total number of mini-slots requested
8 bits
SID
Service ID used for requesting bandwidth. For valid SID ranges, see Section 9.1.2.
16 bits
EHDR
Extended MAC Header not allowed
0 bytes
HCS
2 bytes
Length of a REQ MAC Header
6 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 89.
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. 49
FC
(1 byte)
FC TYPE
= 11
MAC_PARM
(1 byte)
FC PARM
= 00011
LEN
(2 bytes)
EHDR_ON
=1
EHDR
(6 bytes)
EH_TYPE
= 0011
HCS
(2 bytes)
EH_LEN
= 0101
Fragment
Data
FCRC
(4 bytes)
EH_VALUE
(5 bytes)
Figure 89 Fragmentation MAC Header Format

Table 89 Fragmentation MAC Frame (FRAG) Format
Field
FC
Usage
Size
FC_TYPE = 11; MAC-Specific Header
8 bits
FC_PARM [4:0] = 00011; Fragmentation MAC Header

EHDR_ON = 1; Fragmentation EHDR follows
MAC_PARM
ELEN = 6 bytes; length of Fragmentation EHDR
LEN
LEN = length of fragment payload + EHDR length + FCRC length
16 bits
EHDR
Refer to Section 8.2.6.2
6 bytes
HCS
2 bytes
Fragment Data
Fragment payload; portion of total MAC PDU being sent
n bytes
48
49
8 bits
Revised this table per ECN RFIv2.0-N-05.0226-2 by GO on 7/14/05.

Revised this paragraph per ECN RFI v2.0-N-04.0177-2 by GO on 10/18/04.
04/22/09
CableLabs
117
CM-SP-RFIv2.0-C02-090422
Field
FCRC
Usage
Size
CRC - 32-bit CRC over Fragment Data payload (as defined in Ethernet/[ISO8802-3])
Length of a MAC Fragment Frame
8.2.5.5
4 bytes
16 + n bytes
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 overhead 50 and the Concatenation MAC Header only occur
once. Concatenation of multiple MAC frames MUST be as shown in Figure 810. 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. 51
PHY
Overhead
MAC Hdr
(Concat)
MAC Frame 1
(MAC HDR +
optional PDU)
MAC Frame n
(MAC HDR +
optional PDU)
Figure 810 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 811 and Table 810.
FC
(1 byte)
FC TYPE
= 11
FC PARM
= 11100
MAC_PARM
(1 byte)
LEN
(2 bytes)
HCS
(2 bytes)
EHDR_ON
=0
Figure 811 Concatenation MAC Header Format
50
51
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.
118
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 810 Concatenated MAC Frame Format

Field
FC
Usage
Size
8 bits
FC_PARM[4:0] = 11100; Concatenation MAC Header

EHDR_ON = 0; No EHDR with Concatenation Header
MAC_PARM
CNT, number of MAC frames in this concatenation
8 bits
CNT = 0 indicates unspecified number of MAC frames

LEN
LEN = x +... + y; length of all following MAC frames in bytes
16 bits
EHDR
Extended MAC Header MUST NOT be used
0 bytes
HCS
2 bytes
MAC frame 1
First MAC frame: MAC Header plus OPTIONAL data PDU
x bytes
MAC frame n
Last MAC frame: MAC Header plus OPTIONAL data PDU
y bytes
Length of Concatenated MAC frame
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 concatenation burst.
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 812 and
Table 811.
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.
Note:
Extended Headers MUST NOT be used in Request Frames and Timing MAC Headers.
FC
(1 byte)
FC TYPE
= XX
FC PARM
(reserved)
MAC_PARM
(1 byte)
EHDR_ON
=1
LEN
(2 bytes)
EHDR
(1-240 bytes)
EH_TYPE
(4 bits)
EH_LEN
(4 bits)
HCS
(2 bytes)
EH_VALUE
(0-15 bytes)
data PDU
(optional)
repeat
Figure 812 Extended MAC Format
04/22/09
CableLabs
119
CM-SP-RFIv2.0-C02-090422
Table 811 Example Extended Header Format

Field
FC
Usage
FC_TYPE = XX; Applies to all MAC Headers
Size
8 bits
FC_PARM[4:0] = XXXXX; dependent on FC_TYPE

EHDR_ON = 1; EHDR present this example
MAC_PARM
ELEN = x; length of EHDR in bytes
8 bits
LEN
LEN = x + y; length of EHDR plus OPTIONAL data PDU in bytes
16 bits
EHDR
Extended MAC Header present this example
x bytes
HCS
2 bytes
PDU
OPTIONAL data PDU
y bytes
Length of MAC frame with EHDR
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 812.
Table 812 EH Element Format
EH Element Fields
Usage
Size
EH_TYPE
EH element Type Field
4 bits
EH_LEN
Length of EH_VALUE
4 bits
EH_VALUE
EH element data
0-15 bytes
The types of EH element defined in Table 813 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 MACsublayer 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 813.
120
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 813 Extended Header Types

EH_TYPE
EH_LEN
EH_VALUE
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]
3 (= BP_UP)
Upstream Privacy EH Element [DOCSIS8]
Upstream Privacy with Fragmentation
4 (= BP_DOWN)
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)
7-9
Reserved
10 - 14
Reserved [CM <-> CM]
15
8.2.6.1
XX
52
EH Element [DOCSIS8] (See Section 8.2.7.)
Extended EH Element: EHX_TYPE (1 byte), EHX_LEN (1 byte), EH_VALUE (length

determined by EHX_LEN)
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.
52
An Upstream Privacy with Fragmentation EH Element MUST only occur within a Fragmentation MAC- Specific Header. (Refer to
Section 8.2.5.4.)
04/22/09
CableLabs
121
CM-SP-RFIv2.0-C02-090422
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 814.
Table 814 Fragmentation Extended Header Format
EH Element
Fields
Usage
Size
EH_TYPE
Upstream Privacy EH element = 3
4 bits
EH_LEN
Length of EH_VALUE = 5
4 bits
EH_VALUE
Key_seq; same as in BP_UP
4 bits
Ver = 1; version number for this EHDR
4 bits
BPI_ENABLE
If BPI_ENABLE=0, BPI disabled
If BPI_ENABLE=1, BPI enabled
1 bit
Toggle bit; same as in BP_UP
1 bit
SID; Service ID associated with this fragment
14 bits
REQ; number of mini-slots for a piggyback request
8 bits
Reserved; must be set to zero
2 bits
First_Frag; set to one for first fragment only
1 bit
Last_Frag; set to one for last fragment only
1 bit
Frag_seq; fragment sequence count, incremented for each fragment.
4 bits
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.
A compliant CM MUST support Payload Header Suppression. 53 A compliant CMTS MUST support Payload
Header Suppression. 54
The Payload Header Suppression Extended Header sub-element has the following format:
53
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.
54
122
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 815 Payload Header Suppression EHDR Sub-Element Format

EH Element
Fields
EH_TYPE
Usage
Size
Service Flow EH_TYPE=5 for downstream and EH_TYPE=6 for upstream
4 bits
EH_LEN
4 bits
EH_VALUE
Indicates no payload header suppression on current packet.
8 bits
1-255
Payload Header Suppression Index (PHSI)
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.)
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. 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 816 Unsolicited Grant Synchronization EHDR Sub-Element Format
EH Element Fields
EH_TYPE
Usage
Size
Service Flow EH_TYPE = 6
4 bits
EH_LEN
EH_VALUE
Indicates no payload header suppression on current packet.
1-255
Payload Header Suppression Index (PHSI)
04/22/09
4 bits
8 bits [always present]
Queue Indicator
1 bit
Active Grants
7 bits
CableLabs
123
CM-SP-RFIv2.0-C02-090422
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.
Fragment Payload
Single Packet
MAC Frame
MAC HDR
HDR
FC
PARM
EHDR
LEN
HCS
PDU
PRV other
Fragment Payload
Concat of Multiple
MAC Frames
Concat
HDR
MAC
HDR1
PDU
1
CRC
1
MAC
HDR2
12 Bytes
MAC
HDRn
PDU
n
CRC
n
4 Bytes
FRAG HDR FHCS
Fragment #1
CRC
Frag Payload (first)
FHCS- Fragment HCS

FCRC- Fragment CRC
FCRC
Encrypted Portion for Baseline Privacy
FRAG HDR
Fragment #2
FHCS
Frag Payload (mid)
FCRC
FRAG HDR FHCS
Fragment #3
Frag Payload (last)
FCRC
1B
2B
6B
EHDR
LEN = 6
LEN
EHDR
1B
Fragmentation
Header
11
FC
XXFLSSSS
00011
Length of Frag
1B
1B
2B
35
Ver
SID
YYYY0001
1B
RQ
1B
RSV
ETXXXXXXXXXXXXXX
YYYY - Key Sequence number, default = 0000
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
E - Enable BPI: 1 = enable, 0 =

disable
T = Toggle: 1 = odd, 0 = Even,
default = 0
XXXXXXXXXXXXXX = 14 bit SID
Figure 813 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
124
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
arbitrarily selects a sequence number for the first fragment of a frame. 55 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.
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.
55
Frame always refers to either frames with a single Packet PDU or concatenated frame.
04/22/09
CableLabs
125
CM-SP-RFIv2.0-C02-090422
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.
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 fulfill 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.
126
CableLabs
04/22/09
8.3
8.3.1
CM-SP-RFIv2.0-C02-090422
MAC Management Messages

MAC Management Message Header
MAC Management Messages MUST be encapsulated in an LLC unnumbered information frame per [ISO8802-2],
which in turn is encapsulated within the cable network MAC framing, as shown in Figure 814. Figure 814 shows
the MAC Header and the MAC Management Message Header fields which are common across all MAC
Management Messages.
Bit
8
FC
16
24
MAC PARM
31
LEN
MAC header
HCS
DA
DA
SA
MAC
Management
Message
Header
SA
msg LEN
control
DSAP
SSAP
type
RSVD
version
Management
message payload
CRC
Figure 814 MAC Header and MAC Management Message Header Fields
The fields MUST be as defined below:

FC, MAC PARM, LEN, HCS
Common MAC frame header refer to Section 8.2.1.4 for details. All messages use a MAC-specific header.
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)
The MAC address of the source CM or CMTS system.
Msg Length
Length of the MAC message from DSAP to the end of the payload.
DSAP
The LLC null destination SAP (00) as defined by [ISO8802-2].
04/22/09
CableLabs
127
CM-SP-RFIv2.0-C02-090422
SSAP
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 817. 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.
Table 817 MAC Management Message Types 56
Type Value
Version
Message Name
SYNC
2 or 29
1 or 3
UCD
Message Description
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.)
56
MAP
Upstream Bandwidth Allocation
RNG-REQ
Ranging Request
RNG-RSP
Ranging Response
REG-REQ
Registration Request
REG-RSP
Registration Response
UCC-REQ
Upstream Channel Change Request
UCC-RSP
Upstream Channel Change Response
10
TRI-TCD
Telephony Channel Descriptor [DOCSIS6]
11
TRI-TSI
12
BPKM-REQ
Privacy Key Management Request [DOCSIS8]
13
BPKM-RSP
Privacy Key Management Response [DOCSIS8]
14
REG-ACK
Registration Acknowledge
15
DSA-REQ
Dynamic Service Addition Request
16
DSA-RSP
Dynamic Service Addition Response
17
DSA-ACK
Dynamic Service Addition Acknowledge
18
DSC-REQ
Dynamic Service Change Request
19
DSC-RSP
Dynamic Service Change Response
20
DSC-ACK
Dynamic Service Change Acknowledge
21
DSD-REQ
Dynamic Service Deletion Request
22
DSD-RSP
Dynamic Service Deletion Response
23
DCC-REQ
Dynamic Channel Change Request
24
DCC-RSP
Dynamic Channel Change Response
25
DCC-ACK
Dynamic Channel Change Acknowledge
26
DCI-REQ
Device Class Identification Request
27
DCI-RSP
28
UP-DIS
Termination System Information [DOCSIS6]
Device Class Identification Response

Upstream Transmitter Disable
Table updated per RFI2-N-02102 and RFIv2.0-N-04.0128-1 by RKV and GO on 10/28/02 and 3/15/04.
128
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Type Value
Version
Message Name
Message Description
29
30
INIT-RNG-REQ
Initial Ranging Request
31
TST-REQ
Test Request Message
32
DCD
(See entry for UCD.)
33255
Downstream Channel Descriptor [DSG]

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 Section 8.3.26 for setting this value
for these two messages. 57
Management Message Payload
Variable length. As defined for each specific management message.
CRC
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 817, 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 815.
Bit
~
~
16
24
31
~
~
CMTS Timestamp
Figure 815 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
57
Revised this statement per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.
04/22/09
CableLabs
129
CM-SP-RFIv2.0-C02-090422
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. 58
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 816). 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 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. 59
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 819 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.
58
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.
59
Section 8.3.3 text from The MAC management header to this footnote updated per RFI2-N-02089 by RKV on 10/28/02.
130
CableLabs
04/22/09
Bit
CM-SP-RFIv2.0-C02-090422
~
~
16
24
31
MAC Management
Message Header
Upstream
channel ID
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 816 Upstream Channel Descriptor
A CMTS MUST generate UCDs in the format shown in Figure 816, 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 TLV 60. 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 at startup, and is only unique within the MAC-Sublayer domain. Note: Upstream Channel ID = 0 is reserved
to indicate telephony return [DOCSIS6]. 61
Downstream Channel ID
The identifier of the downstream channel on which this message has been transmitted. This identifier is arbitrarily
chosen by the CMTS at startup, and is only unique within the MAC-Sublayer domain. 62
All other parameters are coded as TLV tuples. The type values used MUST be those defined in Table 818, for
channel parameters, and Table 819 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. 63
60
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 Upstream Channel ID per ECN RFIv2.0-N-04.0200-2 by GO on 2/21/05.
62
Revised Downstream Channel ID per ECN RFIv2.0-N-04.0200-2 by GO on 2/21/05.
61
04/22/09
CableLabs
131
CM-SP-RFIv2.0-C02-090422
Table 818 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 SCDMA mode is enabled then this parameter MUST have a value of 8,
16 or 32.
Frequency
Upstream center frequency (Hz)
Preamble Pattern
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)
May appear more than once; described below.
Burst Descriptor (DOCSIS 2.0)
May appear more than once; described below.
Extended Preamble Pattern
1-64
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 Enable
64
S-CDMA Spreading Intervals per

frame
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 twodimensional 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 Codes per Mini-slot
Number of consecutive codes mapped into a two-dimensional mini-slot.

(Value is 2 through 32).
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).
S-CDMA Code Hopping Seed
11
15-bit seed to initialize code hopping sequence. The value is leftjustified in the 2-byte field. Set seed = 0 to disable code hopping.
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.
63
Revised the table below per ECN RFIv2.0-N-04.0167-2, ECN RFIv2.0-N-05.0234-4, and ECN RFIv2.0-N- 05.0250-3 by GO on
10/15/04, 7/15/05, and 11/10/05.
64
CM MUST assume S-CDMA mode is off if TLV is not present.
132
CableLabs
04/22/09
Name
S-CDMA US ratio denominator
N
CM-SP-RFIv2.0-C02-090422
Type
(1 byte)
Length
(1 byte)
13
Value (Variable length)

The denominator (N) of the M/N ratio relating the downstream symbol
S-CDMA Timestamp Snapshot
65
14
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.
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.
Ranging Hold-Off Priority Field
18
Bit Field with values representing device classes, as defined in Annex

C.1.3.1.16 that should temporarily inhibit Initial Ranging.
The CMTS MAY include this TLV in the UCD message. The CM MUST
observe this TLV, as described in Section 11.2.2.
Channel Class ID
19
Bit Field with values representing device classes as defined in Annex

C.1.3.1.16 that are allowed to use the channel.
The CMTS MAY include this TLV in the UCD message. The CM MUST
observe this TLV, as described in Section 11.2.2.
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 820). The format of
the Burst Descriptors is shown in Figure 817.
65
Refer to Section 6.2.11.2 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.
04/22/09
CableLabs
133
CM-SP-RFIv2.0-C02-090422
8
Type = 4 or 5
burst descriptor
16
Length
(n)
24
31
Interval Usage
Code
TLV codes for PHY parameters

(n-1)
Figure 817 Top-Level Encoding for Burst Descriptors
In Figure 817:
Type
4 is for 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 820. The IUC is coded on the 4 least-significant bits. The 4 most-significant
bits are unused (=0).
TLV items
TLV parameters described in Table 818.
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 820. 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 819 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 820.
Within each Burst Descriptor is an unordered list of Physical-layer attributes, encoded as TLV values. These
attributes are shown in Table 819. 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). 66
66
Revised Table per ECN RFI2-N-03077 by GO on 07/03/03.
134
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 819 Upstream Physical-Layer Burst Attributes

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

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.
1 = on, 2 = off. (see Section 6.2.13).
Preamble Length
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.
Preamble Value Offset
The value must be an integral number of symbols (see Section 6.2.9).

Identifies the bits to be used in the preamble. This is specified as a
starting offset into the Preamble Super string (see Table 818). 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 62, and Figure 63), and is I1 in the first symbol of the burst
(see Section 6.2.13).
FEC Error Correction (T)
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)
Fixed: 16 to 253 (assuming FEC on) Shortened: 16 to 253 (assuming

FEC on) (Not used if no FEC, T=0)
Scrambler Seed
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)
Maximum Burst Size
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
67
use this configuration setting to do so.
Guard Time Size
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 mini-slots 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
68
TLV MUST NOT be present for S-CDMA channels.
10
1 = fixed; 2 = shortened
Scrambler on/off
11
1 = on; 2 = off
67
68
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.
04/22/09
CableLabs
135
CM-SP-RFIv2.0-C02-090422
Name
Type
(1 byte)
Length
(1 byte)
R-S Interleaver Depth (Ir)
12
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) (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 S-CDMA
channels or in descriptors encoded in a type 4 TLV.
R-S Interleaver Block Size (Br)
13
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.
Preamble Type
14
1 = QPSK0
2 = QPSK1
(Reference Figure 618, and Section 6.2.9) This TLV MUST NOT be
present in descriptors encoded in a type 4 TLV.
S-CDMA Spreader on/off
15
1 = on; 2 = off. 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.
16
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
S-CDMA Framer Interleaving Step

Size
17
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-S-CDMA channels or in descriptors encoded in a type 4
TLV.
TCM Encoding
18
1 = on; 2 = off. This TLV MUST be present for S-CDMA channels. This
8.3.3.1
Example of UCD Encoded TLV Data
An example of UCD encoded TLV data is given in Figure 818.
Figure 818 Example of UCD Encoded TLV Data
136
CableLabs
04/22/09
8.3.4
CM-SP-RFIv2.0-C02-090422
Upstream Bandwidth Allocation Map (MAP)
A CMTS MUST generate MAPs in the format shown in Figure 819.

Bit
16
24
31
MAC Management
Message Header
Upstream
Channel ID
UCD Count
Number of
elements
Reserved
Alloc Start Time
Ack Time
Ranging
Backoff
Start
Ranging
Backoff End
Data
Backoff
Start
Data
Backoff End
MAP Information Elements
Figure 819 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
Number of information elements in the map.
Reserved
Reserved field for alignment.
Alloc Start Time
Effective start time from CMTS initialization (in mini-slots) for assignments within this 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.
04/22/09
CableLabs
137
CM-SP-RFIv2.0-C02-090422
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).
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 820 and Table 820. Values for IUCs are defined in Table 820 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
17 18
13 14
31
first interval
SID
IUC
offset = 0
second interval
SID
IUC
offset
last interval
SID
IUC
offset
end-of-list (Null IE)
SID=0
IUC=7
offset = map
length
SID
IUC
offset = map
length
SID
IUC
offset =map
length
Acknowledgements
and Data Grants
Pending
Figure 820 MAP Information Element Structure
138
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 820 Allocation MAP Information Elements (IE)

1
IE Name
Interval Usage
Code (IUC)
(4 bits)
SID (14 bits)
Mini-slot Offset (14 bits)
Request
any
Starting offset of REQ region
REQ/Data (refer to Annex

A, for multicast definition)
multicast
Starting offset of IMMEDIATE Data region (well-known multicasts

define start intervals)
Initial Maintenance
broadcast or
unicast
Starting offset of MAINT region (used in Initial or Periodic Ranging)
Station Maintenance
Unicast
unicast
Short Data Grant
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.
Long Data Grant
unicast

If inferred length = 0, then it is a Data Grant Pending
Null IE
zero
Ending offset of the previous grant. Used to bound the length of the
last actual interval allocation.
unicast
CMTS sets to map length
Advanced PHY Short Data

Grant
unicast
Advanced PHY Long Data

Grant
10
unicast
Advanced PHY Unsolicited

Grant
11
unicast
Starting offset of Data Grant assignment
any
Reserved
expanded IUC
# of additional 32-bit words in this IE
Data Ack
5

Reserved
12-14
Expansion
15
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 low-order
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 REGRSP 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.
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 821.
04/22/09
CableLabs
139
CM-SP-RFIv2.0-C02-090422
Bit
~
~
16
24
31

Downstream
Channel ID
SID
~
~
Pending Till
Complete
Figure 821 Packet PDU Following the Timing Header
Parameters MUST be as follows:

SID
For RNG-REQ messages transmitted in Broadcast Initial Maintenance intervals: 69
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.
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 transmitting 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.
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
69
Deleted bullet statement Temporary SID... per ECN RFI2-N-03077 by GO on 07/03/03.
140
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 70
The format of the RSVD field is:
Bit 7: 1= S-CDMA Maximum Bits 6 to 5: CM Maximum Ratio of: Bit 4 to 0: CM power
Scheduled Codes Supported
shortfall (1/4 dB)
00 = 20
01 = 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
~
~
SID from request
Upstream
channel ID
TLV Encoded
Information
Figure 822 Ranging Response
A CMTS MUST generate Ranging Responses in the form shown in Figure 822, including all of the following
parameters:
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.
70
Added the preceding two paragraphs and the matrix below per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/ 04.
04/22/09
CableLabs
141
CM-SP-RFIv2.0-C02-090422
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 Appendix 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. (Table 68 and Section 6.2.19.1.) 71
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. 72
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.
71
72
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.
142
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 73
8.3.6.1
Encodings
The type values used MUST be those defined in Table 821 and Figure 823. 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 821 Ranging Response Message Encodings 74
Name
Type (1 byte) Length (1

byte)
Timing Adjust, Integer Part
TX timing offset adjustment (signed 32-bit, units of (6.25 microsec/64))
Power Level Adjust
TX Power offset adjustment (signed 8-bit, 1/4-dB units)
Offset Frequency Adjust
TX frequency offset adjustment (signed 16-bit, Hz units)
Transmit Equalization Adjust
TX equalization data to be convolved with current values (refer to

Section 6.2.15). See Figure 823 for details about representation.
This TLV MUST NOT be included in a RNG-RSP that includes a type
9 TLV.
Ranging Status
1 = continue, 2 = abort, 3 = success
Downstream frequency override
Center frequency of new downstream channel in Hz
Upstream channel ID override
Identifier of the new upstream channel.
Timing Adjust, Fractional Part
TX timing fine offset adjustment. 8-bit unsigned value specifying the

fine timing adjustment in units of 1/(256*10.24 MHz)
Transmit Equalization Set
TX equalization data to be loaded in place of current values (refer to

Section 6.2.15). See Figure 823 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.
S-CDMA Maximum Scheduled

Codes
10
A CMTS MAY send this TLV only if a CM indicated in the RNG-REQ

or INIT-RNG_REQ that it supports the S-CDMA 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
inactive for this CM, which MUST then use the S-CDMA Number of
Active Codes.
73
74
Added this and the preceding statement per ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04.
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-N02210, by GO, on 11/21/ 02. Revised Transmit Equalization Set value reference to Section 6.215, Transmit Pre-Equalizer per
ECN RFI 2-N-03077 by GO on 07/03/03. Added the S-CDMA Maximum Scheduled Codes, and S-CDMA Power Headroom per
ECN RFIv2.0-N-04.0167-2 by GO on 10/15/04. Revised S-CDMA Maximum Scheduled Codes and S-CDMA Power Headroom
per ECN RFIv2.0-N-04.0203-2 by GO on 2/21/05.
04/22/09
CableLabs
143
CM-SP-RFIv2.0-C02-090422
Name
Type (1 byte) Length (1

byte)
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
Note: A value of 0 for TLV-10 restricts the range to 0 for TLV-11.

Reserved
12-255
type
4
main tap
location
length
number of
forward taps (N)
number of forward
taps per symbol
number of
reverse taps (M)
first coefficient F1 (real)
first coefficient F1 (imag)
last coefficient FN (real)
last coefficient FN (imag)
first reverse coefficient D1

(real)
first reverse coefficient D1

(imag)
last reverse coefficient DM

(real)
last reverse coefficient DM

(imag)
Figure 823 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 628 depicts the operation of the equalizer.
144
CableLabs
04/22/09
8.3.6.2
CM-SP-RFIv2.0-C02-090422
Example of TLV Data
An example of TLV data is given in Figure 824.

Type
1
Length
4
Timing adjust
Type
2
Length
1
Power adjust
Type
3
Length
2
Frequency adjust information
Type
4
Length
x
x bytes of CM transmitter equalization information
Type
5
Length
1
Ranging status
Figure 824 Example of TLV Data
8.3.6.3
Overriding Channels Prior to Registration 75
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. 76
75
76
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.
04/22/09
CableLabs
145
CM-SP-RFIv2.0-C02-090422
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
~
~
SID
TLV Encoded
Information
Figure 825 Registration Request
A CM MUST generate Registration Requests in the form shown in Figure 825, 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 Annex D.3.1.
Enable 2.0 Mode
Downstream Channel List 77
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. 78
The following registration parameter MUST be included in the Registration Request.
77
78
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.
146
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.79
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.
79
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.
04/22/09
CableLabs
147
CM-SP-RFIv2.0-C02-090422
Bit
0
~
16
24
31
~
~
SID from corresponding

REG-REQ
Response
TLV Encoded
Information
Figure 826 Registration Response Format
A CMTS MUST generate Registration Responses in the form shown in Figure 826, 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/activated 80 MUST be expanded into the full set
of TLVs defining the Service Flow. Every upstream Service Flow that was admitted/activated MUST have a
80
The ActiveQoSParamSet or AdmittedQoSParamSet is non-null.
148
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Service Identifier assigned by the CMTS. A Service Flow that was only 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 REG-REQ, 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.)
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
The CMTS response to the capabilities of the modem (if present in the Registration Request)
Vendor-Specific Data
As defined in Annex C.
Vendor ID Configuration Setting (vendor ID of the CMTS)
Vendor-specific extensions
04/22/09
CableLabs
149
CM-SP-RFIv2.0-C02-090422
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.
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 REGRSP with a class-of-service failure response and no DOCSIS 1.0 Class-of-Service TLVs.
Type
Length
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
Length
Value
1.1
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
Length
Value
1.2
SID
150
CableLabs
04/22/09
8.3.9
CM-SP-RFIv2.0-C02-090422
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). 81 It confirms acceptance by the CM of the QoS parameters of the flow as reported by
the CMTS in its REG-RSP. The format of a REG-ACK MUST be as shown in Figure 827.
Bit
16
24
31
~
~
SID from corresponding

REG-RSP
Confirmation
Code
TLV Encoded
Information
Figure 827 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.
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.
81
The Registration-Acknowledge is a DOCSIS 1.1/2.0 message. Refer to Annex G for details of registration interoperability issues.
04/22/09
CableLabs
151
CM-SP-RFIv2.0-C02-090422

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.
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.) 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 828 below.
Bit
~
~
16
24
31
~
~
Upstream
channel ID
Figure 828 Upstream Channel Change Request 82

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 829.
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.
82
Revised Figure 8-28 to match Figure 8-29, per ECN RFI2-N-02210, by GO, on 11/21/02.
152
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
Bit
~
~
16
24
31
~
~

Upstream
channel ID
Figure 829 Upstream Channel Change Response

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
~
~
Transaction ID
TLV Encoded
Information
Figure 830 Dynamic Service Addition Request
A CM or CMTS MUST generate DSA-REQ messages in the form shown in Figure 830, including the following
parameter:
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.
04/22/09
CableLabs
153
CM-SP-RFIv2.0-C02-090422
The DSA-REQ message MUST contain:

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:
Specification of the rules to be used to classify packets into a specific Service Flow.
Specification of the payload header suppression rules to be used with an associated classifier.
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 HMAC-Digest. (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.
CMTS-initiated DSA-Requests for named Service Classes MUST include the QoS Parameter Set associated with
that Service Class.
154
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 831.
Bit
16
24
31
~
~
Transaction ID
Confirmation
Code
TLV Encoded
Information
Figure 831 Dynamic Service Addition Response

Transaction ID
Transaction ID from corresponding DSA-REQ.
Confirmation Code
The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding DSA-Request.

If the transaction is successful, the DSA-RSP MAY contain one or more of the following:
The CMTS MUST include the complete specification of the Classifier in the DSA-RSP, including a newly assigned
Classifier Identifier. The CM MUST NOT include the specification of the Classifier in the DSA-RSP.
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.
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.
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 DSARSP MUST contain at least one of the following:
04/22/09
CableLabs
155
CM-SP-RFIv2.0-C02-090422

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.
MUST be included for at least one failed Classifier in the corresponding DSA-REQ. Every Classifier Error Set
MUST be omitted if the entire DSA-REQ is successful.
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
HMAC-Digest
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.
156
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 832.
Bit
16
24
31
~
~
Confirmation
Code
Transaction ID
TLV Encoded
Information
Figure 832 Dynamic Service Addition Acknowledge

Transaction ID
Transaction ID from corresponding DSA-Response.
Confirmation Code
The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding DSA-Response. 83

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 HMAC-Digest. (Refer to Annex C.1.4.3)
HMAC-Digest
83
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).
04/22/09
CableLabs
157
CM-SP-RFIv2.0-C02-090422
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
~
16
24
31
~
~
Transaction ID
TLV Encoded
Information
Figure 833 Dynamic Service Change Request
A CM or CMTS MUST generate DSC-REQ messages in the form shown in Figure 833, including the following
parameters:
Transaction ID
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:
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:
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.
158
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422

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/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
HMAC-Digest
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 834.
Bit
16
24
31
~
~
Transaction ID
Confirmation
Code
TLV Encoded
Information
Figure 834 Dynamic Service Change Response

Transaction ID
Transaction ID from corresponding DSC-REQ.
Confirmation Code
The appropriate Confirmation Code (refer to Annex C.4) for the corresponding DSC-Request.
04/22/09
CableLabs
159
CM-SP-RFIv2.0-C02-090422
If the transaction is successful, the DSC-RSP MAY contain one or more of the following:
The CMTS MUST include the complete specification of the Classifier in the DSC-RSP, including a newly assigned
Classifier Identifier for new Classifiers. The CM MUST NOT include the specification of the Classifier in the DSCRSP.
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 DSC-RSP 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.
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 DSCRSP MUST contain at least one of the following:
MUST be included for at least one failed Classifier in the corresponding DSC-REQ. Every Classifier Error Set
MUST be omitted if the entire DSC-REQ is successful.
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.
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 DSCREQ is successful.
Regardless of success or failure, if Privacy is enabled for the CM the DSC-RSP MUST contain:
Key Sequence Number
160
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
HMAC-Digest
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 835.
Bit
16
24
31
~
~
Confirmation
Code
Transaction ID
TLV Encoded
Information
Figure 835 Dynamic Service Change Acknowledge

Transaction ID
Transaction ID from the corresponding DSC-REQ.
Confirmation Code
The appropriate Confirmation Code (refer to Annex C.4) for the entire corresponding DSC-Response. 84

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
84
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).
04/22/09
CableLabs
161
CM-SP-RFIv2.0-C02-090422
HMAC-Digest
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 836.
Bit
16
24
31
~
~
Transaction ID
Reserved
SFID
TLV Encoded
Information
Figure 836 Dynamic Service Deletion Request

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 nonzero, any SFIDs included in the TLVs MUST be ignored.
Transaction ID

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
HMAC-Digest
162
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 837.
Bit 0
~
~
16
24
31
~
~
Transaction ID
Confirmation
Code
Reserved
Figure 837 Dynamic Service Deletion Response

Transaction ID
Transaction ID from corresponding DSD-REQ.
Confirmation Code
The appropriate Confirmation Code (refer to Annex C.4) for the corresponding DSD-Request.
8.3.20 Dynamic Channel Change Request (DCC-REQ) 85
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
Transaction ID
TLV Encoded
Information
Figure 838 Dynamic Channel Change Request
85
Replaced this section and subsections per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.
04/22/09
CableLabs
163
CM-SP-RFIv2.0-C02-090422
A CMTS MUST generate DCC-REQ message in the form shown in Figure 838 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
The identifier of the upstream channel to which the CM is to switch for upstream transmissions.
Downstream Parameters
The frequency of the downstream channel to which the CM is to switch for downstream reception.
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
HMAC-Digest
MUST be the final Attribute in the Dynamic Channel Change messages Attribute list. (Refer to Annex 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
Length
Value
0-255: Upstream Channel ID
164
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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
Length
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
Length
Value
2.1
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
Length
Value
2.2
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
Length
2.3
Value
0 = 5.056941 Msym/sec
1 = 5.360537 Msym/sec
2 = 6.952 Msym/sec
3 - 255: reserved
04/22/09
CableLabs
165
CM-SP-RFIv2.0-C02-090422
8.3.20.1.2.4 Downstream Interleaver Depth

This TLV specifies the parameters I and J of the downstream interleaver.
Subtype
Length
Value
2.4
I: 0-255
J: 0-255
8.3.20.1.2.5 Downstream Channel Identifier
This TLV specifies the 8 bit downstream channel identifier of the new downstream channel.
Subtype
Length
Value
2.5
0-255: Downstream Channel ID.
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
Length
2.6
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).
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
166
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
Type
Length
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.
Option 1: If broadcast initial ranging is specified, operation on the new channel could be delayed by several Ranging
Intervals (see Annex B).
Option 2: If unicast ranging is specified, operation on the new channel could be delayed by the value of T4 (see Annex B).
Option 3: 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.
Option 4: 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.
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
Length
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.
04/22/09
CableLabs
167
CM-SP-RFIv2.0-C02-090422
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
Length
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
Length
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 Annex C.2.2.3.2 for usage details.
168
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
Value
7.1
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 Annex C.2.2.3.3 for usage details.
Subtype
Length
Value
7.2
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.
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 Annex 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 Annex C.2.2.6.8.
Subtype
Length
Value
7.5
new reference
If this TLV is absent, the current Unsolicited Grant Time Reference is retained. The CMTS MAY include 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
Length
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.
04/22/09
CableLabs
169
CM-SP-RFIv2.0-C02-090422
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 839.
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
Confirmation
Code
Transaction ID
TLV Encoded
Information
Figure 839 Dynamic Channel Change Response

Transaction ID
A 16-bit Transaction ID from corresponding DCC-REQ.
Confirmation Code
An 8-bit Confirmation Code as described in Annex C.4.1.
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 HMAC-Digest (refer to Annex C.1.4.3).
170
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
HMAC-Digest
MUST be the final Attribute in the Dynamic Channel Change messages Attribute list (refer to Annex C.1.4.1).
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
Length
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
Length
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
Length
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.
04/22/09
CableLabs
171
CM-SP-RFIv2.0-C02-090422
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 840.
Bit
16
24
31
Transaction ID
TLV Encoded
Information
Figure 840 Dynamic Channel Change Acknowledge

Transaction ID
A 16 bit Transaction ID from corresponding DCC-RSP.
If Privacy is enabled, the DCC-ACK message MUST contain:

Key Sequence Number
HMAC-Digest
MUST be the final Attribute in the Dynamic Channel Change messages Attribute list. (Refer to Annex C.1.4.1.)
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.
172
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
The DCI-REQ MUST be formatted as shown in Figure 841.

Bit 0
16
24
31
~
~
Device Class
SID
Device Class (con't)
TLV Encoded
Information
Figure 841 Device Class Identification Request

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.
04/22/09
CableLabs
173
CM-SP-RFIv2.0-C02-090422
The DCI-RSP MUST be formatted as shown in Figure 842.

Bit 0
16
24
31
~
~
Device Class
SID
Confirmation
Code
Device Class (con't)
TLV Encoded
Information
Figure 842 Device Class Identification Response

SID
The SID received in the associated DCI-REQ.
Device Class
The device class field as received in the associated DCI-REQ.
Confirmation Code
Refer to Annex C.4.
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. 86
86
Added reference [RFC-3256] to this paragraph per ECN RFI2-N-03063 by GO on 07/03/03.
174
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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 843.
Bit
16
24
31
UP-DIS Timeout Interval (0=Off Forever, FFFFFFFF=On)
Figure 843 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.
04/22/09
CableLabs
175
CM-SP-RFIv2.0-C02-090422
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.
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 UP-DIS
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 844.
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
~
16
24
31
~
~
SID
Downstream
Channel ID
Upsrtream
Channel ID
Figure 844 Packet PDU Following the Timing Header
176
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Parameters MUST be as follows: 87

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 SCDMA mode (see Section 11.2.1). 88
This is a 16-bit field of which the lower 14 bits define the SID with bits 14 and 15 defined to be 0.
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-RNG-REQ. 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 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.
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
89
Codes and S-CDMA Power Headroom for the CM.
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
87
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.
89
Added this paragraph, the subsequent paragraph, and the matrix below per ECN RFIv2.0-N-04.0167-2 by GO on 10/18/04.
88
04/22/09
CableLabs
177
CM-SP-RFIv2.0-C02-090422
8.3.27 Test Request (TST-REQ) 90
The Test Request is used to force a CM to enter or leave one of two test modes. The TST-REQ 91 message with
Mode!= 0 MUST NOT be sent by the CMTS except in response to an explicit command from the operator.
Bit
16
24
31
Mode
TLV-Encoded
Information for the Channel
Figure 845 Test Request

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.
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 845, including all of the parameters
coded as TLV multiples defined in Table 822.
90
91
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.
178
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 822 Channel TLV Parameters

Name
Modulation Rate
Type
(1 byte)
Length
(1 byte)
Value
(variable length)
Multiples of base rate of 160 kHz. (Value is 1, 2, 4, 8, 16, or 32.).
This TLV MUST be present if the test mode is 1.
Frequency
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.
The numerator (M) of the M/N ratio relating the downstream symbol
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.
04/22/09
CableLabs
179
CM-SP-RFIv2.0-C02-090422
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 91.
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
transmitted on downstream channel by the CMTS
permitted use of the upstream
mini-slots
CM tx opportunity request contention area
previous map
CM tx opportunity
maintenanc
as-yet
unmappe
tim
current
Figure 91 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).
CMs may issue requests to the CMTS for upstream bandwidth.
The CMTS MUST transmit allocation MAP PDUs on the downstream channel defining the allowed usage of each
mini-slot. The MAP is described below.
180
CableLabs
04/22/09
9.1.1
CM-SP-RFIv2.0-C02-090422
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 S-CDMA timestamp snapshot as described
in Section 6.2.11.2.
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 820.
Five types of Service IDs are defined: 92
1.
0x3FFF - Broadcast, intended for all stations.
2.
0x3E00-0x3FFE - Multicast, purpose is defined administratively. Refer to Annex A.
3.
0x2000-0x3DFF - Expanded Unicast, intended for a particular CM or a particular service within that CM, when
supported by both the CM and CMTS.
4.
0x0001-0x1FFF - Unicast, intended for a particular CM or a particular service within that CM.
5.
0x0000 - Null Address, addressed to no station.
A CM MUST support the Expanded Unicast SID space. A CMTS MAY support the Expanded Unicast SID space.
Unicast SIDs (including Expanded Unicast SIDs) MUST be unique on a given logical upstream. The CMTS MAY
support unicast SIDs assignments which overlap across multiple logical upstreams within a single MAC-sublayer
domain. 93
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). 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.)
92
93
Revised these Service IDs per ECN RFIv2.0-N-0226-2 by GO on 7/14/05.

Added this and the preceding paragraph per ECN RFIv2.0-N-0226-2 by GO on 7/14/05.
04/22/09
CableLabs
181
CM-SP-RFIv2.0-C02-090422
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 813).
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 and Section 8.3.26).
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).
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
182
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 and 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 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).
04/22/09
CableLabs
183
CM-SP-RFIv2.0-C02-090422
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. 94
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.
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.
94
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.
184
CableLabs
04/22/09
9.1.4
CM-SP-RFIv2.0-C02-090422
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 91 IE Feature Compatibility Summary
Information Element
Request IE
Request/Data IE
Transmit Request
Transmit
Transmit
Transmit RNG-
Transmit Any
Frame
Concatenated
Fragmented MAC
REQ
other MAC Frame
MAC Frame
Frame
MUST NOT
MUST NOT
MUST NOT
MUST NOT
MUST
MUST
MAY
MUST NOT
MUST NOT
MAY
Initial Maintenance IE
MUST NOT
MUST NOT
MUST NOT
MUST
MUST NOT
Station Maintenance IE
MUST NOT
MUST NOT
MUST NOT
MUST
MUST NOT
MAY
MUST
MUST
MUST NOT
MUST
Short Data Grant IE

Long Data Grant IE
MAY
MUST
MUST
MUST NOT
MUST
Adv PHY Short Data Grant IE
MAY
MUST
MUST
MUST NOT
MUST
Adv PHY Long Data Grant IE
MAY
MUST
MUST
MUST NOT
MUST
Adv PHY Unsolicited Grant IE
MAY
MUST
MUST
MUST NOT
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.
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
04/22/09
CableLabs
185
CM-SP-RFIv2.0-C02-090422
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
CMTS
t3
t1
Map PDU
CM
t2
t5 t6
t7
Request
Map PDU
t4
second map
t9
t8
t 11
data PDU
t 10
Figure 92 Protocol Example
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.
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.
186
CableLabs
04/22/09
9.1.7
CM-SP-RFIv2.0-C02-090422
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.
Null
SID
S-CDMA
logical channel
Null
SID
T3
null grant
Null
SID
Null SID
CM TDMA
logical channel
Minislot count
T7
Null SID
TDMA grant
T4
T8
Frame bounderies
S-CDMA frame
TDMA Mini-slots
T1
T2
T5 T 6
Figure 93 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.
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:
9.2
When switching from TDMA to S-CDMA there is no requirement for additional guard time.
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 co-exist on the same
upstream transmit center frequency.
04/22/09
CableLabs
187
CM-SP-RFIv2.0-C02-090422
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 S-CDMA 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.
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. 95
95
Section 9.3.1, third paragraph, last two sentences updated per RFI2-N-02178 by RKV on 10/30/03.
188
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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. 96
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 S-CDMA frames. Refer to
Section 6.2.11.5.
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
96
Section 9.3.3 updated per RFI2-N-02178 by RKV on 10/30/02.
04/22/09
CableLabs
189
CM-SP-RFIv2.0-C02-090422
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 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
9.3.4.1.1
TDMA Timing Units and Relationships

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 92 relates mini-slots to the SYNC time ticks (assuming
QPSK modulation).
Table 92 Example Relating Mini-Slots to Time Ticks
Parameter
Time tick
190
Example Value
6.25 microseconds
CableLabs
04/22/09
Bytes per mini-slot
CM-SP-RFIv2.0-C02-090422
16 (nominal, when using QPSK modulation)
Symbols/byte
4 (assuming QPSK)
Symbols/second
2,560,000
Mini-slots/second
40,000
Microseconds/mini-slot
25
Ticks/mini-slot
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.
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 mini-slot). 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. An example of the timing relationships (assuming
64QAM modulation) is shown in Table 93.
Table 93 Example of Mini-Slot Capacity in S-CDMA mode
Parameter
04/22/09
Example Value
Spreading intervals per frame
10
Active code length
128
Codes per mini-slot
Mini-slots per frame
32
Symbols per mini-slot
40
Bytes per mini-slot
30 (nominal, when using 64QAM modulation)
Bits/symbol
6 (assuming 64QAM)
Symbols/second
5,120,000
Mini-slots/second
128,000
Microseconds/mini-slot
7.8125
CableLabs
191
CM-SP-RFIv2.0-C02-090422
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.
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.
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-oftwo 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 MAP 97 currently in effect. 98
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. 99 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.
97
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.
99
Data Acknowledge IEs are intended for collision detection only and 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.
98
192
CableLabs
04/22/09
Note:
CM-SP-RFIv2.0-C02-090422
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 = 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, back-off
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. 100
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. 101
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 round-trip
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 94 Transmit Opportunity
Interval
100
101
SID Type
Transmit Opportunity
Request
Broadcast
# mini-slots required for a Request
Request
Multicast
# mini-slots required for a Request
Request/Data
Broadcast
Not allowed
Request/Data
Well-known Multicast
As defined by SID in Annex A
Added this paragraph per ECN RFI2-N-02215, by GO, on 12/02/02.

04/22/09
CableLabs
193
CM-SP-RFIv2.0-C02-090422
Request/Data
Multicast
Vendor specific algorithms
Initial Maint.
Broadcast
Entire interval is a single tx opp
Note:
Transmit Opportunity should not be confused with Burst Size. Burst Size requirements are specified in
102
Table 61.
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.
102
This Note added per RFI2-N-02135 by RKV on 10/29/02.
194
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
10 QUALITY OF SERVICE AND FRAGMENTATION

This specification introduces several new Quality of Service (QoS) related concepts not present in [SCTE22-1].
These include:
Packet Classification & Flow Identification
Service Flow QoS Scheduling
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).
04/22/09
CableLabs
195
CM-SP-RFIv2.0-C02-090422
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.
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 Concepts
10.1.1.1 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 CMTS.103 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 attributes: 104
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. 105
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.
103
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.
104
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.
105
The ProvisionedQoSParamSet is null when a flow is created dynamically.
196
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 101 and Figure 102. The
ActiveQoSParameterSet is always a subset 106 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 101 Provisioned Authorization Model Envelopes
106
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 is 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.
04/22/09
CableLabs
197
CM-SP-RFIv2.0-C02-090422
ProvQosParamSet
(SFID)
AuthQosParamSet
(CMTS only, not known by CM)
AdmitQosParamSet
(SFID & SID)
ActiveQosParamSet
(SFID & Active SID)
Figure 102 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 103 illustrates the mapping discussed above.
198
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Upper Layer Entity (e.g. bridge,

router, client)
Upper Layer Entity (e.g. bridge, router)
MAC
Mgmt
Msgs
(Optional)
Ingress
Classifier
Primary SFID
Downstream
Classifier
SFID 2
...
SFID n
Downstream
Service Flows
Upstream
Classifier
Downstream
MAC
Mgmt
Msgs
RF
Primary SID
SID 2
Upstream
Upstream
Classifier
...
SID n
CMTS
Upstream Service Flows
CM
Figure 103 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. 107
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.
107
Replaced this paragraph per ECN RFI2-N-02200, change #1, by GO, on 11/21/02.
04/22/09
CableLabs
199
CM-SP-RFIv2.0-C02-090422
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 104. 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.) 108
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 104. (Refer to Appendix I.)
108
Revised the first sentence of this paragraph per ECN RFIv2.0-N-04.0191-2 by GO on 11/19/04.
200
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Packet
LlcHeader
[lp Header]
[SCase]
[RulePriority]
[SFID]
Classifier
matches
Service Flow
SFID
ClassifierId
LlcPacketPattern
lpPacketPattern
RulePriority
0..65535
0,1
SFID
1 Direction
[SID]
[ProvQosParamSet]
[AdmittedQosParamSet]
ActiveQosParamSet]
1
N
0,3
Service Class
PayloadHeader
Suppression (PHS)
Service Class Name

QosParamSet
SFID
PHSI
Classifierld
PHSF
PHSM
PHSS
PHSV
0..255
Figure 104 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.
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.
04/22/09
CableLabs
201
CM-SP-RFIv2.0-C02-090422
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 DSCRSP). 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 by the
external policy server are permitted. Admission and activation requests from a CM that are not pre-signalled 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
202
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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-of-service
scenarios.
04/22/09
CableLabs
203
CM-SP-RFIv2.0-C02-090422
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 upper-layer 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 DSC-Request, 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-per-Interval equal four, and Active Grants-perInterval 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
requesting 109 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.
109
According to its Request/Transmission Policy (refer to Annex C.2.2.6.3.)
204
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
04/22/09
CableLabs
205
CM-SP-RFIv2.0-C02-090422
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, dynamically-added
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 General Operation

10.1.7.1 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
CM
tratio
Regis
Reg
n
uratio
n-Re
que
spo
n-Re
Provisioning Server
st
nse
CMTS
istra
tion
-A
ck
Figure 105 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
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.
206
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 101 TFTP File Contents

Items
Point To Service Flow
Service Flow
Service
Reference
Reference
Flow ID
1..m
None Yet
Service Flow Encodings

Provisioned for later activation requested, upstream
(m+1)..n
None Yet

Immediate activation requested, downstream
(n+1)..p
None Yet

Provisioned for later activation requested, downstream
(p+1)..q
None Yet
Upstream Classifiers
Each containing a Service Flow Reference (pointer)
1..n
Downstream Classifiers
(n+1)..q

Immediate activation requested, upstream
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 102 Registration Request Contents
Items
Point To Service Flow
Service Flow
Service
Reference
Reference
Flow ID

Immediate activation requested, upstream
May specify explicit attributes or service class name
1..m
None Yet

Provisioned for later activation requested, upstream
Explicit attributes or service class name
(m+1)..n
None Yet

Immediate activation requested, downstream
Explicit attributes or service name
(n+1)..p
None Yet

Provisioned for later activation requested, downstream
Explicit attributes or service name
(p+1)..q
None Yet
Upstream Classifiers
1..n
Downstream Classifiers
(n+1)..p
The Registration Response sets the QoS Parameter Sets according to the Quality of Service Parameter Set Type in
the Registration Request.
04/22/09
CableLabs
207
CM-SP-RFIv2.0-C02-090422
The Registration Response preserves the Service Flow Reference attribute, so that the Service Flow Reference can
be associated with SFID and/or SID.
Table 103 Registration Response Contents
Items
Service Flow
Service Flow
Reference
Identifier
1..m
SFID
SID
Provisioned Upstream Service Flows

Explicit attributes
(m+1)..n
SFID
Not Yet
Active Downstream Service Flows

Explicit attributes
(n+1)..p
SFID
N/A
Provisioned Downstream Service Flows

Explicit attributes
(p+1)..q
SFID
N/A
Active Upstream Service Flows

Explicit attributes
Service Identifier
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 106 and described in detail in Section 11.4.2.1.
DSA
-Re
CM
ques
t
e
pons
-Res
A
S
D
DSA
-Ac
k
CMTS
now
ledg
e
Figure 106 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.
208
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 107 and is described in detail in Section 11.4.2.2.
uest
-Req
DSA
CMTS
DSA
-Res
pons
e
CM
e
owl
ckn
A
DSA
dge
Figure 107 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.
04/22/09
CableLabs
209
CM-SP-RFIv2.0-C02-090422
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 (UGSAD), Non-Real-Time Polling Service (nrtPS) and Best Effort (BE) service. Table 104 shows the relationship
between the scheduling services and the related QoS parameters.
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
110
Interval.
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.
110
Replaced existing paragraph with the four previous paragraphs per ECN RFIv2.0-N-03.0110-2 by GO on 2/ 11/04.
210
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 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
04/22/09
CableLabs
211
CM-SP-RFIv2.0-C02-090422
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 Other Services
10.2.6.1 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.
10.2.7 Parameter Applicability for Upstream Service Scheduling
Table 104 summarizes the relationship between the scheduling services and key QoS parameters. A detailed
description of each QoS parameter is provided in Annex C.
212
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table 104 Parameter Applicability for Upstream Service Scheduling 111

Service Flow Param eter
Best Effort
Non-RealTime Polling
Real-Time
Polling
Unsolicited
Grant
Unsolicited
Grant with
Activity Det.
Optional
Default = 0
Optional
Optional
Default = 2
Optional
Default = 0
Optional
Default = 0
Optional
Mandatory
N/A a
N/A
N/A
Optional
Mandatory
N/A
Mandatory
N/A
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Default = 0
Optional
Dflt = 3044
Optional
Default = 0
Optional
Dflt = 3044
Optional
Default = 0
Optional
Dflt = 3044
N/A
N/A
N/A
N/A
Optional
Default = 0
Optional*
Optional
Default = 0
Optional*
Optional
Default = 0
Optional*
N/A
N/A
Optional*
Optional*
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
N/A
N/A
Optional*
N/A
Mandatory
Optional*
N/A
N/A
Optional
Optional*
Miscellaneous
Traffic Priority
Max Concatenated Burst
Upstream Scheduling
Service Type
Reques t/Transmission
Policy
Maximum Rate
Max Sustained Traffic Rate
Max Traffic Burst
Minimum Rate
Min Reserved Traffic Rate
Ass umed Minimum
Packet Size
Grants
Unsolicited Grant Size
Grants per Interval
Nominal Grant Interval
Tolerated Grant Jitter
Polls
Nominal Polling Interval
Tolerated Poll Jitter
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.
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.
111
Revised table Dflt = 1522 to Dflt = 3044 per ECN RFI2-N-02210 by GO, on 11/21/02.
04/22/09
CableLabs
213
CM-SP-RFIv2.0-C02-090422
The CM MUST perform fragmentation according to the flow diagram in Figure 108. 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, 112 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. 113
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.
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.
112
113
Frame always refers to either frames with a single Packet PDU or concatenated frames.
Last three sentences added per RFI2-N-02093 by RKV on 10/28/02.
214
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Start
Discard
untransmitted
portion of frame
Await Frame
Arrival
Backoff if
necessary and
request bandwidth
for Sid X
Yes
Retries
Exhausted?
No
Backoff and
re-request for
untransmitted
portion of frame
No
Yes
Ack Timer
Expired?
Process MAP
Information
Elements
Yes
No
Grant
Pending?
No
Send
untransmitted
portion of frame with
piggyback field(s)=0
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 108 CM Fragmentation Flowchart 114
114
Revised Figure per ECN RFI2-N-02215, by GO, on 12/02/02.
04/22/09
CableLabs
215
CM-SP-RFIv2.0-C02-090422
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. 115
10.3.2.1 Multiple Grant Mode 116
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 rerequest 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.
10.3.2.2 Piggyback Mode 117
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
115

Deleted previous first paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/21/04.
117
Deleted previous first paragraph per ECN RFIv2.0-N-04.0177-2 by GO on 10/21/04.
116
216
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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. 118
10.3.3 Fragmentation Example
10.3.3.1 Single Packet Fragmentation
Refer to Figure 108. 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 109, 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 no 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 109, the CM sends up a request for enough mini-slots to hold the POH plus 150 bytes
(1018-884+16). Go to step 6.
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
118
Last two sentences updated per RFI2-N-02093 by RKV on 10/28/02.
04/22/09
CableLabs
217
CM-SP-RFIv2.0-C02-090422
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 109, 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.
218
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Fragment Payload
Original Packet
with BPI EHDR
(1018 Bytes)
1B
1B
2B
4B
4B
2B
1000B
4B
FC
PARM
LEN
PRV
other EHDRs
HCS
PDU payload
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
FRAG HDR FHCS FC PARM
4B
2B
2B
4B
LEN
PRV other EHDRs HCS
870B
4B
PDU payload (first) FCRC
Encrypted under Baseline Privacy

1B
1B
EHDR
FC
LEN = 6
11
00011
2B
6B
LEN
BPI EHDR
1B
1B
2B
35
Ver E|T|OoS_SID RQ
1B
1B
Frag Cntl
Request for enough

minislots to fit 150
(130+4+16) bytes of MAC
info. This field would be
zero in multiple grant mode.
Second Grant can

fit 150 bytes of
MAC
information
10B
2B
130B
00100000
4B
4B
FRAG HDR FHCS PDU payload (cont) PCRC FCRC

Frag Cntl Bit Definition
11
FC
EHDR
LEN = 6
00011
LEN
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 frame,
rolling over as necessary
XX - Reserved, set to 00
BPI EHDR
1B
35
2B
1B
Ver E|T|OoS_SID RQ
Piggyback request for next

PDU (if applicable)
1B
Frag Cntl
00010001
Figure 109 Example of Fragmenting a Single Packet
04/22/09
CableLabs
219
CM-SP-RFIv2.0-C02-090422
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.
Original Concatenated Packet (287) Bytes
4B
68B
15B
6B
100B
6B
10B
4B
70B
4B
Concat. HDR MAC HDR1 PDU payload 1 PCRC1 MAC HDR2 PDU payload 2 PCRC2 MAC HDR3 PDU payload 3 PCRC3
1B
1B
EHDR
FC
LEN = 6
First Grant can
fit 125 bytes of
MAC
information
2B
2B
LEN
HCS
10B
1B
1B
2B
5B
4B
2B
FC PARM LEN PRV other EHDRs HCS
2B
6B
4B
68B
15B
6B
10B
4B
FRAG HDR FHCS Concat. HDR MAC HDR1 PDU payload 1 PCRC1 MAC HDR2 PDU payload 2 (part1) FCRC
1B
1B
EHDR
FC
LEN = 6
11
00011
2B
6B
LEN
BPI EHDR
1B
1B
35
01
2B
1B
1B
E|T|QoS_SID RQ
Frag Cntl
Request for enough minislots to fit

162 (287-109+16) bytes of MAC info.
This field would be zero in multiple
grant mode.
Second Grant can

fit 146 bytes of
MAC
information
10B
2B
FRAG HDR FHCS
1B
1B
EHDR
FC
LEN = 6
11
90B
00011
00100000
4B
26B
10B
PDU payld 2 (part) PCRC2 MAC HDR3 PDU payld 3 (part) FCRC
2B
6B
LEN
BPI EHDR
1B
1B
35
01
2B
1B
E|T|QoS_SID RQ
1B
Frag Cntl
Request for enough minislots to fit 64

(287-109-130+16) bytes of MAC info.
This field would be zero in multiple
grant mode.
Third Grant can

fit 64 bytes of
MAC
information
10B
1B
1B
EHDR
FC
LEN = 6
11
00011
2B
FRAG HDR FHCS
4B
44B
4B
00000001
4B
PDU payld 3 (part) PCRC3 FCRC
2B
6B
LEN
BPI EHDR
1B
1B
35
01
2B
1B
E|T|QoS_SID RQ
Request for packet
1B
Frag Cntl
00010010
Figure 1010 Fragmented Concatenated Packet Example
220
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 105 Payload Header Suppression Definitions
PHS
Suppressing an initial byte string at the sender and restoring the byte string at the
receiver.
PHS Rule
Payload Header Suppression Rule
A set of TLVs that apply to a specific PHS Index.
PHSF
Payload Header Suppression Field
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).
PHSI
Payload Header Suppression Index
An 8-bit value which references the suppressed byte string.
PHSM
Payload Header Suppression Mask
A bit mask which indicates which bytes in the PHSF to suppress, and which
bytes to not suppress.
PHSS
Payload Header Suppression Size
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
PHSV
Payload Header Suppression Verify
A flag which tells the sending entity to verify all bytes which are to be
suppressed.
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.
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.
04/22/09
CableLabs
221
CM-SP-RFIv2.0-C02-090422
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 1011 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.
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.
222
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Receiver PHS Start
Sender PHS Start
Packet Arrives
Packet Arrives
Classify Packet.
Retrieve PHSF, PHSI,
PHSM, PHSS, PHSV
Identify SID and

extract PHSI
Retrieve PHSF,
PHSM, PHSS
Verify?
Yes
Reconstruct
Header and
forward packet
Verify with
PHSF
No
Forward
Packet
Pass
Verify?
Yes
Suppress with
PHSM
Append PHSI
END
No
Forward
Packet
END
Figure 1011 Payload Header Suppression Operation
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.
04/22/09
CableLabs
223
CM-SP-RFIv2.0-C02-090422
Figure 1012 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.
Sender
PHSM
PHSF
A'
C'
E'
= Verify
= Assign
Cable
Network
Receiver
PHSM
PHSF
A'
C'
E'
C'
E'
A'
A - E = current header
A' - E' = cached header
X = don't care
PHSS = 5
Figure 1012 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.
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 1013 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.
224
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
CM
CMTS
Classifier ID +
Service Flow ID
DSC-REQ
CM
Classifier Reference/
ID + Service Flow ID
+ PHSS + PHSF
+ PHSI + PHSS + PHSF
DSC-REQ
PHSI
DSC-RSP
DSC-RSP
DSC-ACK
DSC-ACK
Figure 1013 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 ITUT 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.)
Figure 1014 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
14
20
12
10 to 160
IP
UDP
RTP
Voice Bytes
CRC
MAC OH BPI HCS Ethernet
values in bytes
14-34
FGPS
10 to 160
Voice Bytes
CRC
12
MAC OH BPI P HCS RTP
b. VolP with Header Suppression

Figure 1014 Upstream Payload Header Suppression Example
04/22/09
CableLabs
225
CM-SP-RFIv2.0-C02-090422
Figure 1014a. 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 1014b. 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.
Figure 1015 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

2
20
12
10 to 160
MAC OH BPI HCS DA SA T
IP
UDP
RTP
Voice Bytes
CRC
MAC OH BPI P HCS DA SA
12
10 to 160
RTP
Voice Bytes
values in bytes
CRC
b. VolP with Header Suppression

Figure 1015 Downstream Payload Header Suppression Example
Figure 1015a. 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, 6byte 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.
226
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Figure 1015b. 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.
04/22/09
CableLabs
227
CM-SP-RFIv2.0-C02-090422
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 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 111. 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
228
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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 111 CM Initialization Overview
04/22/09
CableLabs
229
CM-SP-RFIv2.0-C02-090422
State symbol
Input symbols
Internal
External
Task symbol
Internal
Output symbols
External
Decision symbol
Figure 112 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 reacquire 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 1117 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 1117 shows the procedure that MUST be followed by a cable
modem during standard operation.
230
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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-RNGREQ 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
119
timing requirements specified in Section 6.2.19.1 and Section 6.2.21.8.
119
Added this paragraph per ECN RFI2-N-03078 (supersedes RFI2-N-02227) by GO on 07/08/03.
04/22/09
CableLabs
231
CM-SP-RFIv2.0-C02-090422
11.2.2 Obtain Upstream Parameters 120
Refer to Figure 113 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. 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. If the UCD
message contains a Type 19 TLV, the CM MUST (except as noted below) perform a bitwise AND of its Ranging
Class ID with the TLV 19 Value. If the result of the bitwise AND is zero, the CM MUST consider the channel
unusable and try other channels until it finds a usable channel.
If the CM is obtaining upstream parameters prior to performing initial ranging with an assigned SID or in
preparation for ranging in response to a DCC-REQ, it MUST ignore TLV-19.
If the CM is not responding to a DCC-REQ and is going to be ranging with the Initialization SID and if the UCD
contains a Type 18 TLV, the CM performs a bitwise AND of its Ranging Class ID with the TLV 18 Value. If the
result of the bitwise AND is equal to the CM's Ranging Class ID, the CM MUST inhibit initial ranging and start the
T17 timer. If the UCD Change Count in the UCD message for the channel the CM is using, is incremented while the
T17 timer is active, the CM will re-inspect the TLV-18 value and re-start the T17 timer if necessary. If
the T17 timer expires or the TLV-18 value is updated to permit ranging for the CMs Ranging Class, the CM will
resume normal ranging. If the CM should undergo a Lost SYNC event while waiting for T17, it MUST re-initialize
the MAC. A CM that is performing initial ranging with an assigned SID MUST ignore TLV-18.
120
Revised this subsection per ECN RFIv2.0-N-05.0234-4 and ECN RFIv2.0-N-05.0250-3 by GO on 7/15/05 and 11/10/05.
232
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
After having transmitted at least one Initial Maintenance RNG-REQ message, the CM MUST ignore TLV-18 or
TLV-19 values in any new UCD message for the channel even if the new UCD contains a Ranging Required TLV.
The CM MUST wait for the next SYNC message and extract the upstream mini-slot timestamp from this message.
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 113. 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.
04/22/09
CableLabs
233
CM-SP-RFIv2.0-C02-090422
Collect UCD Messages
Build Channel List
Timeout T1
Yes
End of Channel List?
Scanning
Select First Channel
No
Select next Channel
UCD for Selected

Channel
Wait for SYNC
Yes
Does UCD contain a
TLV- 19 inhibiting
usage of channel?
SYNC
No
Does UCD contain a

TLV- 18 Inhibiting
Initial Ranging?
Extract Upstream minislot

timing
No
Wait for MAP for this

channel
Yes
Start T 17 Timer
MAP for selected

channel
UCD with incremented

change count
Lost SYNC
Timeout T17
Initial Ranging
No
Re- Init MAC

Initial Ranging
Successful?
Yes
Periodic Ranging
Figure 113 Obtaining Upstream Parameters 121
121
Replaced this figure per ECN RFIv2.0-N-05.0234-4 by GO on 7/15/05.
234
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 114.
CMTS
CM
clock time to send SYNC
----------------SYNC-------------------->
clock time to send UCD
----------------UCD---------------------->
|
|
----------------SYNC-------------------->
|
| Example of a UCD cycle
| prior to CM power-on
|
----------------SYNC-------------------->
|
|
|
|
----------------SYNC-------------------->
|
|
|
----------------SYNC-------------------->
----------------UCD---------------------->
----------------SYNC-------------------->
power on sequence complete
----------------SYNC-------------------->
establish PHY synchronization
& wait for UCD
----------------SYNC-------------------->
----------------SYNC-------------------->
----------------UCD---------------------->
obtain parameters for this
upstream channel to use for
initialization
----------------SYNC-------------------->
extract slot info for upstream &
wait for transmit opportunity to
perform ranging
----------------SYNC-------------------->
clock time to send MAP
----------------MAP---------------------->
start ranging process
Figure 114 Message Flows During Scanning and Upstream Parameter Acquisition
04/22/09
CableLabs
235
CM-SP-RFIv2.0-C02-090422
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 CMTSs. Refer to Figure 115 through Figure 118.
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-------
transmit ranging packet in contention

mode with Service ID parameter = 0
[receive recognizable ranging packet]

allocate temporary Service ID
send ranging response
----------RNG-RSP------->
add temporary Service ID to poll list
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
send ranging response
-----------MAP------------>
recognize own temporary Service ID

in map
<---------RNG-REQ-------
reply to Station Maintenance

opportunity poll or Unicast Initial
Maintenance opportunity poll
----------RNG-RSP------->
adjust local parameters
[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----------->
Figure 115 Ranging and Automatic Adjustments Procedure
Note:
236
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.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Wait for broadcast

maintenance
opportunity
Map with
maintenance
opportunity
Time out T2
Error
Re-initialize MAC
Backoff
completed?
No
Wait for
broadcast ranging
opportunity
Yes
Send
RNG-REQ
Wait for RNG-RSP
Error
Re-initialize MAC
Yes
Time out T3
RNG-RSP
Retries
exhausted?
Adjust local
parameters per
RNG-RSP
No
Adjust local power
Wait for
unicast maintenance
opportunity
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 116 Initial Ranging CM 122
122
Revised per ECN RFI2-N-02215 by GO on 12/02/02.
04/22/09
CableLabs
237
CM-SP-RFIv2.0-C02-090422
Wait for unicast

Maintenance
Opportunity
Map with
Maintenance
opportunity
Timeout T4
Send
RNG-REQ
Adjust transmit
power
No
Wait for
RNG-RSP
RNG-RSP
Timeout T3
No
Adjust
parameters
per
RNG-RSP
RNG-REQ
retries exceeded?
Abort ranging
from CMTS?
No
Ranging
Success
(Note 1)
Yes
Yes
Error:
Re-initialize MAC
Enable data
transfer
Establish IP
layer
1.
Ranging Request is within the tolerance of the CMTS.
Figure 117 Unicast Initial Ranging - CM
238
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Wait for
recognizable
INIT-RNG-REQ
or RNG-REQ
RNG-REQ
No
SID assigned to
this CM already?
Assign temporary
SID
Yes
Reset retry count
in poll list for this
CM
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
RNG-REQ
received
No
Retries Exhausted?
Good Enough?
(Note 1)
No
Send
RNG-RSP
(success)
Yes
Yes
Remove CM from
poll list
Yes
Retries Exhausted?
No
Send
RNG-RSP
(abort)
Send
RNG-RSP
(continue)
Wait for
recognizable
RNG-REQ
Wait for polled

RNG-REQ
Remove CM from
poll list
Start T9
Done
Figure 118 Initial Ranging - CMTS 123

1
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-till-complete expiry,
the good-enough test which follows receipt of a RNG-RSP MUST NOT judge the CMs transmit equalization until pending-tillcomplete expires.
123
Added diagram block Start T9 to per ECN RFI2-N-02210 by GO on 11/21/02.
04/22/09
CableLabs
239
CM-SP-RFIv2.0-C02-090422
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 RNGRSP 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 119.
CM
CMTS
Send identification
request to CMTS
DCI-REQ
Process request
DCI-RSP
Continue to establishing IP
connectivity
Figure 119 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.
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 1110.
240
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
CM
DHCP
send DHCP request to broadcast

address
----------------DHCP discover------------>
check CM MAC address &
respond
<--------------DHCP offer ----------------choose server
----------------DHCP request-------------->
process request
<--------------DHCP response-------------set up IP parameters from DHCP

response
Figure 1110 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). 124
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.
The protocol by which the time of day MUST be retrieved is defined in [RFC-868]. Refer to Figure 1111. 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 1111 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.
124
Added this paragraph per ECN RFI2-N-03085 by GO on 11/17/03.
04/22/09
CableLabs
241
CM-SP-RFIv2.0-C02-090422
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 [RFC-2349].
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. 125
If a modem downloads a configuration file containing the Enable 2.0 Mode TLV set to Disable (see 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 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 1112):
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.
125
242
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 115 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.
Time of Day
Request
Wait for Time of

Day Response
Time of Day
Response
Time of Day Retries are

asynchronous with registration
Timeout
Request
Config File
No
Retries
exceeded?
Wait for
Successful TFTP
Config File
Received
Scan for
Dowstream
Channel
Increment
Retry Counter
Timeout
Mandatory
items present?
Yes
No
Yes
CM MIC valid?
No
Yes
TLV type 11
errors?
Yes
No
Acquire
Operational
Parameters
Send RegReq
Wait for Reg-Rsp
Figure 1112 Registration CM
04/22/09
CableLabs
243
CM-SP-RFIv2.0-C02-090422
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 1113 shows the waiting procedure that MUST be followed by the CM.
Wai t for Reg Rsp
Timeout T6
No
Reg-Rsp
Retries
exhausted?
Response =
ok?
Error: Re-ini tialize

MAC
Wait for Reg Rsp
Implementation
Dependent
Yes
Yes
Send
Reg-Req
No
Yes
CM supports
all parameters
in Reg-Rsp?
No
Send Reg-Ack
with er ror sets
Setup Service
Flows & Activate
Operational
Parameters
Send
Reg-Ack
Switch to DOCSIS
1.1 mode
Yes
Yes
DOCSIS 2.0
enabled AND
Type 2
channel?
DOCSIS 2.0
enabled AND
Type 2
channel?
No
No
Switch to DOCSIS
2.0 mode
Registration
Complete
Reg-Rsp
Figure 1113 Wait for Registration Response CM 126
126
Refer to Section 11.2.2 for channel type definitions. Revised Figure per ECN RFI2-N-02239 by GO on 02/26/03.
244
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Note to Figure 1112 and Figure 1113: 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 REGACK 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 REG-ACK 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 1114 and
Figure 1115):
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 REGRSP. 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 Annex 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 rejectpermanent 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 1114. 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.
04/22/09
CableLabs
245
CM-SP-RFIv2.0-C02-090422
Waiting for RegReq
Reg-Req
Stop T9
Calculate MIC
over Reg-Req
CMTS MIC
Valid?
Send Reg-Rsp with

Response =
Authentication Failure
No
Yes
TFTP Server IP and/

or Timestamp Valid?
No
Send Reg-Rsp with

Response =
Authentication Failure &
Should Log Failure
Yes
Can the requested

service(s) ever be
supported?
Wait for Reg-Req
No
Send Reg-Rsp with

Response = Class of
Service Failure & Service
Not Available=Reason
Permanent
No
Send Reg-Rsp with

Response = Class of
Service Failure & Service
Not Available=Reason
Temporary
Yes
Can the requested

service(s) currently
be supported?
Set modem
capabilities
supported in
RegRsp
Create
Requested
Services
Send Reg-Rsp with

Response = ok
Waiting for RegAck
Figure 1114 Registration CMTS
246
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Waiting for RegAck
Reg-Ack
No
Adv. PHY
activated AND
Type 2
channel?
No
Reg-Ack
contains
Error Sets?
Yes
Timeout T6
Retries
Exhausted?
Yes
Destroy
Services
No
Send Reg-Rsp
with Response =
OK
Switch CM
operational state
to Adv PHY
Registration
Complete
Waiting for RegReq
Waiting for RegAck
Figure 1115 Registration Acknowledgment CMTS 127
11.2.10 Baseline Privacy Initialization 128
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
(Annex C.1.1.16) in the DOCSIS 1.1-style configuration file is explicitly/implicitly set to enable or the Baseline
Privacy Configuration Setting (Annex 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. 129
127
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.
129
Revise paragraph by adding a statement primary SID/SAID per ECN RFI2-N-03073 by GO on 07/03/03.
128
04/22/09
CableLabs
247
CM-SP-RFIv2.0-C02-090422
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. 130
The temporary SID assigned by the CMTS MUST be in the unicast SID space (see Section 9.1.2). DOCSIS 2.0
CMs MUST support the capability to transmit unicast traffic on the expanded SID space (see Section C.1.3.1.3). If a
CM supports the above capability the CMTS MAY assign SID numbers from the expanded unicast SID space in the
Registration Response. 131
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 class-of-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.
130
131
Revised this paragraph per ECN RFIv2.0-N-05.0226-2 and RFIv2.0-N-05.0239-1 by GO on 7/14/05 and 8/ 11/05.
Added this paragraph per ECN RFIv2.0-N-05.0226-2 by GO on 7/14/05. Revised this paragraph per ECN RFIv2.0-N-05.0239-1 by
GO on 8/11/05.
248
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
11.3 Standard Operation

11.3.1 Periodic Signal Level Adjustment 132
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.
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 1116 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. 133
132
133
Revised this section per ECN RFI2-N-03016 by GO on 02/27/03.

Added this paragraph per ECN RFI2-N-02227 by GO on 03/20/03.
04/22/09
CableLabs
249
CM-SP-RFIv2.0-C02-090422
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?
Good Enough?
(see Note 1 below)
Yes
No
Send
RNG-RSP
(success)
Yes
Retries Exhausted?
Yes
No
Send
RNG-RSP
(abort)
Remove CM from
poll list
Send
RNG-RSP
(continue)
Wait for polled

RNG-REQ
Remove CM from
poll list
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 1116 Periodic Ranging - CMTS
250
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Operational
RNG-RSP
Unicast
maintenance
opportunity
Timeout T3
Timeout T4
T3 Timer
started?
Start
T4 Timer
No
Send
RNG-REQ
RNG-REQ
retries exceeded?
Yes
Reset RNG-REQ
Retry Counter;
Clear T3 Timer
Abort ranging
from CMTS?
Yes
Increment
RNG-REQ
Retry Counter
Success ranging
from CMTS?
No
Yes
No
Clear
transmission
suspend
Start
T3 Timer
Error:
Re-initialize MAC
Suspend
transmission of
everything except
RNG-REQs
Adjust local
parameters per
RNG-RSP
Figure 1117 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 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
04/22/09
CableLabs
251
CM-SP-RFIv2.0-C02-090422
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 re-register. 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 1118 shows the procedure that MUST be followed by the CMTS. Figure 1119 and
Figure 1120 show the corresponding procedure at the CM.
252
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Figure 1118 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.
04/22/09
CableLabs
253
CM-SP-RFIv2.0-C02-090422
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?
No
CM UCC Failed
Yes
Perform broadcast
initial ranging
Ranging
Success?
The operational CM MUST base its

requests on IUCs 9 and 10 if available and
if DOCSIS 2.0 is enabled.
No
CM UCC Failed
Yes
CM Operational
Figure 1119 Changing Upstream Channels: CM View Part 1
254
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 1120 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.
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 1121.
04/22/09
CableLabs
255
CM-SP-RFIv2.0-C02-090422
DSD
Null
DSC
Operational
DSA
Figure 1121 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. 134
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. 135
11.4.1 Dynamic Service Flow State Transitions
The Dynamic Service Flow State Transition Diagram, Figure 1122, 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.
134
135

256
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 DSD-Local 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. 136
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:
DSA Succeeded
DSA Failed
DSA ACK Lost
DSA Erred
DSA Ended
136
Added sentence per ECN RFI2-N-02187, by GO, on 12/16/02. Revised sentence per ECN RFI2-N-03050 and RFI2-N-03075 by GO
on 06/04/03 & 07/03/03.
04/22/09
CableLabs
257
CM-SP-RFIv2.0-C02-090422
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.
258
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Null
Add / DSA-Local( SF Add )
Adding
Local
( DSA Failed / )
( Delete / SF Abort Add )
(DSA Erred/)
DSA Ended /
DSA-REQ /
DSA-Remote( DSA-REQ )
Add Failed
DSA Failed /
DSA Succeeded /
DSC-REQ / SF DSA-ACK Lost
Adding
Remote
DSA Succeeded /
( DSA Erred /
DSD-Local( SF Delete ) )
( Delete / SF Delete-Local,
Nominal
Change /
DSC-Local(
SF Change )
( DSC-REQ / [ CMTS Only ] )

( DSA ACK Lost /
SF DSC-REQ Lost )
( DSC ACK Lost /
SF DSC-REQ Lost )
DSC-REQ /
SF Change-Remote,
DSC-Remote( DSC-REQ )
New DSC-REQ /
SF DSC-ACK Lost
( DSC Succeeded /
SF Changed )
( DSC Failed /
SF Changed )
Delete /
SF Delete-Local,
DSD-Local( SF Delete )
Changing
Local
( DSC Succeeded /
SF Changed )
( DSC Failed /
SF Changed )
DSC-REQ / SF Change-Remote,
DSC-Remote( DSC-REQ ) [ CM Only ]
( DSC Erred / SF Delete-Local,

DSD Ended &&

Num Xacts == 0 /
( DSC-REQ / )
( DSA ACK Lost /
SF DSD-REQ Lost )
( DSC ACK Lost /
SF DSD-REQ Lost )
Changing
Remote
( DSC Erred /
Deleting
DSD-REQ / SF Delete-Remote, DSD-Remote( DSD-REQ )
( DSD Succeeded / SF Deleted )

( DSD Erred / SF Deleted )
DSD Succeeded / SF Deleted
Deleted
Figure 1122 Dynamic Service Flow State Transition Diagram
04/22/09
CableLabs
259
CM-SP-RFIv2.0-C02-090422
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 )

( SF Deleted / DSA Ended )
Timeout T10 /
DSA Erred, DSA Ended
SF Delete-Remote / DSA Ended
End
Figure 1123 DSALocally Initiated Transaction State Transition Diagram
260
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 )
( DSA-ACK / )
( SF Delete-Local / )
( SF Change-Remote / )
Holding
Down
Deleting
Service Flow

( SF Changed / DSA Ended )
End
Figure 1124 DSARemotely Initiated Transaction State Transition Diagram
04/22/09
CableLabs
261
CM-SP-RFIv2.0-C02-090422
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 )

( SF Deleted / DSC Ended )
Timeout T10 /
DSC Erred, DSC Ended
SF Delete-Remote / DSC Ended
End
Figure 1125 DSCLocally Initiated Transaction State Transition Diagram
262
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 )
( DSC-ACK / )
( SF Delete-Local / )
( SF Change-Remote / )
Holding
Down
Deleting
Service Flow

( SF Changed / DSC Ended )

End
Figure 1126 DSCRemotely Initiated Transaction State Transition Diagram
04/22/09
CableLabs
263
CM-SP-RFIv2.0-C02-090422
Begin
SF Delete / DSD-REQ
( Timeout T7 && Retries Available / DSD-REQ )

( SF DSD-REQ Lost && Retries Available / DSD-REQ )
( SF DSD-REQ Lost && Retries Exhausted / )
DSD-RSP
Pending
( 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 1127 DSDLocally Initiated Transaction State Transition Diagram
264
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Begin
DSD-REQ / DSD Succeeded, DSD-RSP
Holding
Down
DSD-REQ / DSD-RSP
( Timeout T10 / DSD Ended )

( SF Deleted / DSD Ended )
End
Figure 1128 Dynamic Deletion (DSD) - Remotely Initiated Transaction State Transition Diagram
11.4.2 Dynamic Service Addition

11.4.2.1 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).
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.
04/22/09
CableLabs
265
CM-SP-RFIv2.0-C02-090422
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)
137
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-RSP
<--DSA-RSP---
Send DSA-RSP
---DSA-ACK-->
Receive DSA-ACK
If ActiveQoSParamSet is non-null, Enable

transmission and/or reception of data on new
Service Flow(s)
Send DSA-ACK
If downstream ActiveQoSParamSet is nonnull, 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 1129 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 (DSAACK).
137
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.
266
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 non- null,
Create SID
If upstream ActiveQoSParamSet is non-null,
Enable reception of data on new upstream
Service Flow
Receive DSA-REQ
<--DSA-REQ---
Send DSA-REQ
---DSA-RSP-->
Receive DSA-RSP
Confirm CM can support Service Flow(s)

Add Downstream SFID (if present)
Enable reception on any new downstream
Service Flow
Send DSA-RSP
Enable transmission & reception of data on new

Service Flow(s)
Receive DSA-ACK
Send DSA-ACK
<--DSA-ACK---
Enable transmission on new upstream

Service Flow
Figure 1130 Dynamic Service Addition Initiated from CMTS
04/22/09
CableLabs
267
CM-SP-RFIv2.0-C02-090422
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 1131 DSALocally Initiated Transaction Begin State Flow Diagram
268
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSA-Local
DSA-RSP
Pending
Timeout T7
SF Delete-Remote
SF Abort Add
DSA-RSP
Retries
Available
?
Stop T7 Timer
Stop T7 Timer
Stop T7 Timer
No
Yes
Saved
DSA-REQ
Start T7 Timer
Save DSA-ACK
with Condition
Code 'reject-addaborted'
DSA Ended
Start T10 Timer
Okay ?
No
DSA-Local
End
Yes
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 1132 DSALocally Initiated Transaction DSA-RSP Pending State Flow Diagram
04/22/09
CableLabs
269
CM-SP-RFIv2.0-C02-090422
DSA-Local
Holding Down
SF Changed,
SF Change-Remote,
SF Delete-Remote
Timeout T10
Stop T10 Timer
SF Delete-Local
DSA-RSP
DSA-Local
Deleting
Service Flow
Saved
DSA-ACK
DSA ACK
Lost
DSA Ended
DSA-Local
Holding Down
DSA-Local
End
Figure 1133 DSALocally Initiated Transaction Holding State Flow Diagram
270
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSA-Local
Retries Exhausted
Timeout T10
SF Delete-Remote
SF Abort Add
DSA Erred
Stop T10 Timer
Save DSA-ACK
with Condition
Code 'reject-addaborted'
DSA-RSP
Okay ?
No
Yes
DSA Ended
Enable
service flow
DSA-Local
End
DSA Failed
DSA
Succeeded
Set Condition
Set Condition
Code to 'okay'
DSA-ACK
Save transmitted
DSA-ACK
DSA-Local
Holding Down
Figure 1134 DSALocally Initiated Transaction Retries Exhausted State Flow Diagram
04/22/09
CableLabs
271
CM-SP-RFIv2.0-C02-090422
DSA-Local
Deleting
Service Flow
SF Deleted,
SF Delete-Remote
Timeout T10
DSA-RSP
DSA ACK
Lost
Stop T10 Timer
DSA-Local
Deleting
Service Flow
DSA Ended
DSA-Local
End
Figure 1135 DSALocally Initiated Transaction Deleting Service Flow State Flow Diagram
272
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSA-Remote
Begin
DSA-REQ
Okay ?
No
Yes
DSA Failed
Set Condition
[ CM Only ]
Enable
downstream
service flow
[ CMTS Only ]
Enable
upstream
service flow
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 1136 DSARemotely Initiated Transaction Begin State Flow Diagram
04/22/09
CableLabs
273
CM-SP-RFIv2.0-C02-090422
Figure 1137 DSARemotely Initiated Transaction DSA-ACK Pending State Flow Diagram
274
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSA-Remote
Holding Down
SF Changed,
SF Deleted,
SF Delete-Remote
SF Delete-Local,
SF Change-Remote
Timeout T8
DSA-ACK
Stop T8 Timer
DSA-Remote
Holding Down
DSA Ended
DSA-Remote
End
Figure 1138 DSARemotely Initiated Transaction Holding Down State Flow Diagram
DSA-Remote
Deleting
Service Flow
SF Deleted,
SF Delete-Remote
DSA-REQ,
DSA-ACK
Timeout T10
DSA-Remote
Deleting
Service Flow
Stop T10 Timer
DSA Ended
DSA-Remote
End
Figure 1139 DSARemotely Initiated Transaction Deleting Service State Flow Diagram
04/22/09
CableLabs
275
CM-SP-RFIv2.0-C02-090422
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 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 CMTS-initiated 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:
276
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.
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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).
CMTS
CM
Service Flow Requires Modifying

Receive DSC-REQ
<--------- DSC-REQ ----------
Send DSC-REQ
---------- DSC-RSP --------->
Receive DSC-RSP
Validate Request
Modify Service Flow
Send DSC-RSP
Modify Service Flow

Receive DSC-ACK
<--------- DSC-ACK ----------
Send DSC-ACK
Figure 1140 CM-Initiated DSC
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
CM
Service Flow Requires Modifying

Send DSC-REQ
---------- DSC-REQ --------->
Receive DSC-REQ
Modify Service Flow
Receive DSC-RSP
<--------- DSC-RSP ----------
Send DSC-RSP
---------- DSC-ACK --------->
Receive DSC-ACK
Modify Service Flow

Send DSC-ACK
Figure 1141 CMTS-Initiated DSC
04/22/09
CableLabs
277
CM-SP-RFIv2.0-C02-090422
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 1142 DSCLocally Initiated Transaction Begin State Flow Diagram
278
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSC-Local
DSC-RSP
Pending
SF DSC-REQ
Lost
Timeout T7
Retries
Available
?
SF ChangeRemote
[ CM Only ]
No
SF DeleteRemote
SF DeleteLocal
DSC-RSP
Stop T7 Timer
Stop T7 Timer
Stop T7 Timer
Start T10 Timer

Yes
DSC Ended
Retries
Available
?
Saved
DSC-REQ
DSC-Local
End
Start T7 Timer
No
DSC-Local
Deleting
Service Flow
Start T10 Timer
DSC-Local
Retries Exhausted
No
Okay ?
Yes
Saved
DSC-REQ
Decrement
DSC-REQ
Retries Available
Yes
Restore
service flow
QoS State
DSC-Local
DSC-RSP
Pending
Modify
Service Flow
Parameters
DSC
Succeeded
DSC Failed
Set Condition
Set Condition
Code to 'okay'
DSC-ACK
Start T10 Timer
Save transmitted
DSC-ACK
DSC-Local
Holding Down
Figure 1143 DSCLocally Initiated Transaction DSC-RSP Pending State Flow Diagram
04/22/09
CableLabs
279
CM-SP-RFIv2.0-C02-090422
DSC-Local
Holding Down
SF Changed,
SF Change-Remote,
SF Delete-Remote
Timeout T10
Stop T10 Timer
SF Delete-Local
DSC-RSP
DSC-Local
Deleting
Service Flow
Saved
DSC-ACK
DSC ACK
Lost
DSC Ended
DSC-Local
Holding Down
DSC-Local
End
Figure 1144 DSCLocally Initiated Transaction Holding Down State Flow Diagram
280
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSC-Local
Retries Exhausted
Timeout T10
SF Delete-Remote
SF Delete-Local
DSC Erred
Stop T10 Timer
DSC-Local
Deleting
Service Flow
No
DSC Ended
DSC-RSP
Okay ?
Yes
DSC-Local
End
Restore
service flow
QoS state
Modify
Service Flow
parameters
DSC Failed
DSC
Succeeded
Set Condition
Set Condition
Code to 'okay'
DSC-ACK
Save transmitted
DSC-ACK
DSC-Local
Holding Down
Figure 1145 DSCLocally Initiated Transaction Retries Exhausted State Flow Diagram
04/22/09
CableLabs
281
CM-SP-RFIv2.0-C02-090422
DSC-Local
Deleting
Service Flow
SF Deleted,
SF Delete-Remote
Timeout T10
DSC-RSP
DSC ACK
Lost
Stop T10 Timer
DSC-Local
Deleting
Service Flow
DSC Ended
DSC-Local
End
Figure 1146 DSCLocally Initiated Transaction Deleting Service Flow State Flow Diagram
282
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSC-Remote
Begin
DSC-REQ
No
Okay?
Yes
Modify Service
Flow Parameters
Set Condition
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 1147 DSCRemotely Initiated Transaction Begin State Flow Diagram 138
138
Revised Figure 11-47 per ECN RFI2-N-03100 by GO on 11/17/03.
04/22/09
CableLabs
283
CM-SP-RFIv2.0-C02-090422
DSC-Remote
DSC-ACK
Pending
SF DSC-ACK
Lost
DSC-REQ
SF DeleteRemote
SF DeleteLocal
DSC-ACK
Stop T8 Timer
Stop T8 Timer
Stop T8 Timer
Timeout T8
Retries
Available
?
No
Yes
Start T10 Timer
Saved
DSC-RSP
DSC Erred
Retries
Available
?
DSC-Remote
Deleting
Service Flow
Start T8 Timer
No
Yes
Saved
DSC-RSP
DSC Ended
Decrement
DSC-RSP
Retries Available
DSC-Remote
End
No
Restore
service flow
DSC Failed
Okay ?
Yes
DSC
Succeeded
DSC-Remote
DSC-ACK
Pending
Start T8 Timer
DSC-Remote
Holding Down
Figure 1148 DSCRemotely Initiated Transaction DSC-ACK Pending State Flow Diagram 139
139
Revised Figure 11-48 per ECN RFI2-N-02210 by GO, on 11/22/02.
284
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSC-Remote
Holding Down
SF Changed,
SF Deleted,
SF Delete-Remote
SF Delete-Local,
SF Change-Remote
Timeout T8
DSC-ACK
Stop T8 Timer
DSC-Remote
Holding Down
DSC Ended
DSC-Remote
End
Figure 1149 DSCRemotely Initiated Transaction Holding Down State Flow Diagram
DSC-Remote
Deleting
Service Flow
SF Deleted,
SF Delete-Remote
DSC-REQ,
DSC-ACK
Timeout T10
DSC-Remote
Deleting
Service Flow
Stop T10 Timer
DSC Ended
DSC-Remote
End
Figure 1150 DSCRemotely Initiated Transaction Deleting Service Flow State Flow Diagram
04/22/09
CableLabs
285
CM-SP-RFIv2.0-C02-090422
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 reregisters. 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.
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
Receive DSD-RSP
<--DSD-RSP---
Send DSD-RSP
Figure 1151 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. 140
CM
CMTS
Service Flow(s) no longer needed

Determine associated CM for this
Service Flow(s)
Receive DSD-REQ
<---DSD-REQ---
Send DSD-REQ
---DSD-RSP-->
Receive DSD-RSP

Send DSD-RSP
Figure 1152 Dynamic Service Deletion Initiated from CMTS 141
140
141
text replaced per rfi n-00088, 12/6/00, po

(s) added per rfi n-00088, 12/6/00, po
286
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 1153 DSDLocally Initiated Transaction Begin State Flow Diagram
04/22/09
CableLabs
287
CM-SP-RFIv2.0-C02-090422
DSD-Local
DSD-RSP
Pending
SF DSD-REQ
Lost
Timeout T7
Retries
Available
?
Retries
Available
?
Yes
Yes
Saved
DSD-REQ
No
SF Delete-Remote
DSD-RSP
Stop T7 Timer
Stop T7 Timer
No
DSD
Succeeded
Saved
DSD-REQ
DSD Erred
Start T7 Timer
DSD Ended
Decrement
DSD-REQ
Retries Available
DSD-Local
End
Start T7 Timer
DSD-Local
Holding Down
DSD-Local
DSD-RSP
Pending
Figure 1154 DSDLocally Initiated Transaction DSD-RSP Pending State Flow Diagram
288
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSA-Local
Holding Down
SF Changed,
SF Change-Remote,
SF Delete-Remote
Timeout T10
Stop T10 Timer
SF Delete-Local
DSA-RSP
DSA-Local
Deleting
Service Flow
Saved
DSA-ACK
DSA ACK
Lost
DSA Ended
DSA-Local
Holding Down
DSA-Local
End
Figure 1155 DSDLocally Initiated Transaction Holding Down State Flow Diagram
04/22/09
CableLabs
289
CM-SP-RFIv2.0-C02-090422
DSD-Remote
Begin
DSD-REQ
Disable
service flow
DSD
Succeeded
DSD-RSP
Start T10 Timer
Save transmitted
DSD-RSP
DSD-Remote
Holding Down
Figure 1156 DSDRemotely Initiated Transaction Begin State Flow Diagram
290
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DSD-Remote
Holding Down
SF Deleted
Timeout T10
DSD-REQ
Saved
DSD-RSP
Stop T10 Timer
DSD-Remote
Holding Down
DSD Ended
DSD-Remote
End
Figure 1157 DSDRemotely Initiated Transaction Holding Down State Flow Diagram
11.4.5 Dynamically Changing Downstream and/or Upstream Channels 142

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 1158 through Figure 1161 shows the procedure that MUST be
followed by the CMTS when performing a dynamic channel change. Figure 1162 through Figure 1165 shows 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.
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.
142
Replaced this section and added subsections per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.
04/22/09
CableLabs
291
CM-SP-RFIv2.0-C02-090422
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 re-initialization, 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 DCCRSP (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. If in the process of a
dynamic channel change with a non-zero initialization technique the CMTS detects that the CM has re-initialized
the MAC before completing the channel change, the CMTS MAY de-allocate the resources that were previously
143
allocated to the modem on the new channel before the expiration of T15.
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.
143
292
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 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
CmJumpTime
Explanation and Value
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 DCCREQ 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.
04/22/09
CableLabs
293
CM-SP-RFIv2.0-C02-090422
11.4.5.1.2 Initialization Technique 144
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 sub-TLVs 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
Include the UCD substitution in the DCC message if the upstream channel is changing.
144
Deleted the last sentence in this section per ECN RFI2-N-03077 by GO on 07/08/03.
294
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 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.
04/22/09
CableLabs
295
CM-SP-RFIv2.0-C02-090422
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 DCCREQ 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-already-there, to the
CMTS (refer to Annex C.4.1).
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
296
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
11.4.5.3 DCC State Transition Diagrams
Previous CMTS
Operational
New CMTS
Operational
Channel
Change
Required
DCC-RSP
(<conf code>)
Initialization
Technique =
Reinitialize
the MAC?
ERROR:
Unknown
DCC
transaction
DCC beginning
(from old CMTS),
including DCCREQ parameters
DCC-RSP
(<conf code>)
Prepare new
channel(s) with
any appropriate
resource
assignments
ERROR:
Unknown
DCC
transaction
No
Yes
DCC beginning (to

new CMTS),
including DCCREQ parameters
Set DCC-REQ
retry counter to 0
Previous CMTS
Operational
New CMTS
Operational
Start T15
New CMTS DCC-RSP

(arrive) Pending
DCC
CMTS A
Other event
from old
CMTS
DCC-REQ
Ignore the event.
Start T11
Start T13
Previous CMTS DCCRSP (depart) Pending
New CMTS
Operational
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.
Figure 1158 Dynamically Changing Channels: CMTS View Part 1
04/22/09
CableLabs
297
CM-SP-RFIv2.0-C02-090422
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?
Stop T11
Stop T13
Yes
DCC-RSP
CM Jump
Time (to new
CMTS)
ERROR:
DCC-REQ
rejected
<reason>
Remove old
channel
resource
assignments.
ERROR:
CM not
responding
No
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
298
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Previous CMTS
DCC
T13 Pending
Timeout T13
CM Arrived
(from new
CMTS)
CM no longer
present on
old channel
DCC-RSP
(<conf code>)
ERROR:
Unknown
DCC
transaction
Stop T13
Previous CMTS
DCC
T13 Pending
Remove old
channel resource
assignments.
Previous CMTS
Operational
1 The mechanism to determine

this event is vendor-specific.
04/22/09
CableLabs
299
CM-SP-RFIv2.0-C02-090422
New CMTS DCC-RSP

(arrive) Pending
DCC-RSP
CM Jump
Time (from
old CMTS)
CM detected
on new
channel
Store Jump
Time
DCC-RSP
(arrive)
Timeout T15
DCC Aborted
(from old
CMTS)
DCC-ACK
ERROR:
CM not
arriving
ERROR:
DCC Aborted
Stop T15
Stop T15
Restart T15
New CMTS DCC-RSP

(arrive) Pending
Start T10
Remove new
channel resource
assignments.
Determination of this is CMTSspecific, but can include receiving

RNG-REQ or bandwidth requests
from the CM on the new channel.
CM Arrived
(to old CMTS)
New CMTS
Operational
New CMTS DCC

Hold-down
New CMTS DCC

Hold-down
DCC-RSP
(arrive)
Timeout T10
New CMTS
Operational
DCC-ACK
New CMTS DCC

Hold-down
300
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
CM Operational
DCC-REQ
Parse DCC-REQ
No
DCC-REQ
valid?
DCC-RSP
(reject<reason>)
Yes
ERROR: Bad
CMTS DCC
<reason>
Already using
US and DS
channels?
DCC-RSP
(rejectalready-there)
No
CM Operational
No
DCC-RSP
(reject<reason>)
Can jump be
made?
ERROR: Bad
CMTS DCC
already-there
Yes
DCC-RSP
(depart)
ERROR:
DCC-REQ
denied
Yes
CM Operational
Clean up internal
queues and other
housekeeping
CM Operational
Apply Id substitutions,
store UCD from
DCC-REQ (if present)
DCC
CM A
Figure 1162 Dynamically Changing Channels: CM View Part 1
04/22/09
CableLabs
301
CM-SP-RFIv2.0-C02-090422
DCC
CM A
Downstream
Change?
Yes
CM DCC
Downstream Change
Yes
Reset the MAC
No
Initialization
technique =
Re-init the
MAC?
Obtain Upstream
Parameters
No
Valid UCD for
target upstream
stored?
CM DCC
Acquire UCD
No
Yes
Wait for
SYNCs?
Yes
CM DCC
Acquire SYNC
No
CM DCC
Acquire MAP
No
CM DCC
Ranging
No
Valid MAP in
cache?
Yes
Initialization
technique =
Use-Directly?
Yes
Set DCC-RSP
(arrive) retry
counter to 0
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 1163 Dynamically Channels: CM View Part 2
302
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
CM DCC
Downstream Change
CM D CC
Acquire SYNC
Change tuner, attempt

downstream lock (using
hints provided by CMTS
in DCC-REQ, if any)
Successful
lock?
Wait for a SYNC

message (up to
Lost SYNC
Interval).
No
Yes
SYNC
acquired ?
CM DCC Failed
{Return to main
diagram}
Valid UCD
acquired?
Yes
Yes
C M DC C F ailed
{R eturn to main
diagram }
CM DCC
Acquire UCD
Wait for Valid UCD

for target
upstream channel
(or expiry of T1)
No
1
1
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.
No
CM DCC Failed
{Return to main
diagram}
CM DCC
Ranging
CM DCC
Acquire MAP
Perform ranging
as required (initial/
station).
Wait for a MAP

message.
Ranging
Success?
MAP
acquired?
Yes
No
No
Yes
CM DCC Failed
{Return to main
diagram}
{Return to main
diagram}
CM DCC Failed
2 See Figures 11-6

and 11-7 for details.
04/22/09
CableLabs
303
CM-SP-RFIv2.0-C02-090422
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 11-1.
304
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 DCC-REQ message. Each
of these factors is individually discussed in the table 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 DCCREQ message to the CM and completes when the CMTS receives the DCC-RSP (arrive) message from the CM.
Table 111 Factors affecting DCC performance
TLV Type
Initialization
Technique
Value
Explanation
Absent or 0
There are no performance requirements in this case. The CM will arrive on the destination
Reinitialize MAC CMTS after initialization occurs.
1
There are low performance expectations in this case because many factors affect the
Broadcast Initial performance, such as collisions and ranging backoff. The CM should arrive on the
destination CMTS as quickly as possible.
Ranging
The DCC transaction SHOULD complete within 1.5 seconds after the start of jump.
Unicast Ranging
3
The CMTS does not know which ranging technique the CM will utilize. The CM should arrive
on the destination CMTS as quickly as possible.
Broadcast or
Unicast Ranging
The DCC transaction SHOULD complete within one second after the start of jump.
Use Channel
Directly
DS Parameter
The CMTS SHOULD include the downstream parameter TLVs for station maintenance and
use directly initialization techniques that are expected to occur quickly.
UCD Substitution
The CMTS MUST set the UCD substitution TLV according to Section 11.4.5.1.2.
SYNC Substitution
The CMTS MUST set the SYNC substitution TLV according to Section 11.4.5.1.2.
CM Jump Time
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.
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.
11.4.5.5 Example Operation
11.4.5.5.1 Example Signalling
Figure 1166 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 re-requests 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.
04/22/09
CableLabs
305
CM-SP-RFIv2.0-C02-090422
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)
The CMTS issues a DCC-REQ command to the CM.
f)
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)
The CM searches for a UCD message unless it has been supplied with a copy.
j)
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)
The CMTS reserves the requested resources and responds with a DSA-RSP.
s)
The CM finishes with a DSA-ACK.
306
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
CMTS
DS #1
US #1
US #2
CM
DS #2
data traffic
data traffic
DSA-REQ
reserve resources
and duplicate
downstream traffic
DSA-RSP
DSA-ACK
data traffic
Start T14
data traffic
data traffic
DCC-REQ
Start T11, T13
DCC-RSP
CM changes channels
Sync of QAM, FEC,
MPEG
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 1166 DCC Example Operational Flow
The states for the old and new CMTSs are shown as separate flow diagrams, since the old and new CMTS may be
different. If the CMTSs 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 CMTSs have been carefully crafted to handle many error
conditions, such as:
04/22/09
CableLabs
307
CM-SP-RFIv2.0-C02-090422
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 Example Timing
11.4.5.5.2.1 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.
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.
308
CableLabs
04/22/09
Variable
CmJumpTime
CmtsRxRngReq
CM-SP-RFIv2.0-C02-090422
Value
Explanation
1.3 sec.
Since the CM did not include the optional jump time TLV, the CMTS will use the
default value of 1.3 seconds.
2.04 sec
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.
2 * (1 sec.) + 40 msec.
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 = 1.3 sec. + (10.04 sec.) = 11.34 sec.
Variable
Value
Explanation
CmJumpTime
1.3 sec.
Since the CM did not include the optional jump time TLV, the CMTS will use the
default value of 1.3 seconds.
CmtsRxRngReq
10.04 sec
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.
2 * (5 sec.) + 40 msec.
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.
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).
04/22/09
CableLabs
309
CM-SP-RFIv2.0-C02-090422
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 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.
310
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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.
04/22/09
CableLabs
311
CM-SP-RFIv2.0-C02-090422
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 REGREQ 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.
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
312
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 1167 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
1
H
L
US0
US1
H
L
2w
CMTS
US2
3
H
US3
US4
2w
2w
H
US5
2w
Figure 1167 Example Combining Network 1
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:
04/22/09
CableLabs
313
CM-SP-RFIv2.0-C02-090422
Load Balancing Group1:

Group ID:
1
Type:
General
Downstream Channels: DS
Upstream Channels: US1, US2
Load Balancing Group 2:
Group ID:
2
Type:
Restricted
Group ID:
3
Type:
Restricted
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 1168 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 aside for a
particular customer group (e.g., business customers), a Restricted Load Balancing Group is formed to allow load
balancing for those customers.
314
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
DS0
2w
2w
US00
Fiber Nodes
US01
1
H
US02
4w
US03
CMTS
2w
2w
US13
2
US12
H
4w
US11
US10
DS1
Figure 1168 Example Combining Network 2

Group ID:
Type:
Downstream Channels:
Upstream Channels:
Subgroup:
1
General
DS0, DS1
US00, US01, US12
DS0, US00, US01

Group ID:
2
Type:
General
Downstream Channels: DS0, DS1
Upstream Channels:
US10, US11, US02
Subgroup:
DS1, US10, US11
Group ID:
3
Type:
Restricted
Downstream Channels: DS0, DS1
11.5 Fault Detection and Recovery

Fault detection and recovery occurs at multiple levels.
04/22/09
CableLabs
315
CM-SP-RFIv2.0-C02-090422
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 112 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 112 Recovery Process on Loss of Specific MAC Messages
Message Name
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.
UCD
During CM initialization the CM MUST receive a usable 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.
MAP
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.
RNG-REQ
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.
RNG-RSP
REG-REQ
REG-RSP
UCC-REQ
UCC-RSP
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.
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.
316
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 interwork with the previous version in order to allow a gradual transition of units on the network.
12.2 Future Capabilities 145

If the CM indicates support for one or more CM capabilities defined in a higher-numbered version of DOCSIS, it
MUST implement them in a manner that complies with the specification in which the feature is defined.
145
Section added per RFIv2.0-N-07.0600-2 on 2/1/08 by KN.
04/22/09
CableLabs
317
CM-SP-RFIv2.0-C02-090422
Annex A
A.1
Well-Known Addresses
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 minislot.
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.).
318
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
319
CM-SP-RFIv2.0-C02-090422
Annex B
System
Parameters and Constants 146

Name
Time Reference
Minimum
Value
Default Value
Maximum
Value
200 msec
CMTS
Sync Interval
Nominal time between transmission of SYNC

messages (refer to Section 8.3.2)
CMTS
UCD Interval
Time between transmission of UCD messages

(refer to Section 8.3.3)
2 sec
CMTS
Max MAP Pending
The number of mini-slots that a CMTS is

allowed to map into the future (refer to Section
8.3.4)
4096 mini-slot
times
CMTS
Ranging Interval
Time between transmission of broadcast

Ranging requests (refer to Section 9.3.3)
CM
Lost Sync Interval
Time since last received Sync message before

synchronization is considered lost
CM
Contention Ranging
Retries
Number of Retries on contention Ranging

Requests (refer to Section 11.2.4)
16
Number of Retries on inviting Ranging

Requests (refer to Section 11.2.4)
16
Number of retries on bandwidth allocation

requests
16
CM, CMTS Registration Request/ Number of retries on registration requests/

Response Retries
responses
CM, CMTS Invited Ranging

Retries
CM
CM
Request Retries
2 sec
600 msec
Data Retries
Number of retries on immediate data

transmission
CMTS
CM MAP processing
time
Time provided between arrival of the last bit of (200 + M/ 5.12)

a MAP at a CM and effectiveness of that MAP s (ref Section
(refer to Section 9.1.5)
6.2.17)
CMTS
CM Ranging
Minimum time allowed for a CM following
Response processing receipt of a ranging response before it is
time
expected to reply to an invited ranging request
1 msec
CMTS
CM Configuration
The maximum time allowed for a CM, following

receipt of a configuration file, to send a
Registration Request to a CMTS.
30 sec
CM
T1
Wait for UCD timeout
CM
T2
Wait for broadcast ranging timeout
CM
T3
Wait for ranging response
CM
T4
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.
CMTS
T5
Wait for Upstream Channel Change response
2 sec
CM, CMTS T6
Wait for REG-RSP and REG-ACK
3 sec
CM, CMTS Mini-slot size for 1.x

channels.
Size of mini-slot for upstream transmission. For 32 modulation

channels that support DOCSIS 1.x CMs.
intervals
CM, CMTS Mini-slot size for

DOCSIS 2.0 Only
Channels.
Size of mini-slot for upstream transmission. For

channels that do not support DOCSIS 1.x CMs.
CM, CMTS Timebase Tick
System timing unit
CM, CMTS DSx Request Retries
Number of Timeout Retries on DSA/DSC/ DSD

Requests
146
16
5 * UCD
interval
maximum value
5 * ranging
interval
50 msec
200 msec
30 sec
200 msec
35 sec
16 symbols
6.25 sec
3
Added CM T17 per ECN RFIv2.0-N-05.0234-4 by GO on 7/15/05.
320
CableLabs
04/22/09
System
Name
CM-SP-RFIv2.0-C02-090422
Time Reference
Minimum
Value
CM, CMTS DSx Response Retries Number of Timeout Retries on DSA/DSC/ DSD
Responses
CM, CMTS T7
CM, CMTS T8
CM
Wait for DSA/DSC/DSD Response timeout
1 sec
Wait for DSA/DSC Acknowledge timeout
300 msec
Initial value for TFTP backoff
1sec
CM
TFTP Backoff End
Last value for TFTP backoff
16 sec
CM
TFTP Request Retries Number of retries on TFTP request
16
CM
TFTP Download
Retries
Number of retries on entire TFTP downloads
CM
TFTP Wait
The wait between TFTP retry sequences
CM
ToD Retries
Number of Retries per ToD Retry Period
CM
ToD Retry Period
Time period for ToD retries
5 min
T9
Registration Timeout, the time allowed

between the CMTS sending a RNG-RSP
(success) to a CM, and receiving a REG-REQ
from that same CM.
15 min
CM, CMTS T10
Maximum
Value
TFTP Backoff Start
CMTS
10 min
3
15 min
Wait for Transaction End timeout
3 sec
CMTS
T11
Wait for a DCC Response on the old channel
300 ms
300 ms
CM
T12
Wait for a DCC Acknowledge
CMTS
T13
Maximum holding time for QoS resources for

DCC on the old channel
CM
T14
Minimum time after a DSx reject-temp-DCC

and the next retry of DSx command
2 sec
CMTS
T15
Maximum holding time for QoS resources for

DCC on the new channel
2 sec
CM
T16
Maximum length of time CM remains in test

mode after receiving TST-REQ message.
CM
T17
Maximum Time that CM MUST inhibit

transmissions on a channel in response to its
Ranging Class ID matching a bit value in the
Ranging Hold-Off Priority Field.
CMTS
DCC-REQ Retries
Number of retries on Dynamic Channel

Change Request
CM
DCC-RSP Retries
Number of retries on Dynamic Channel

Change Response
CM
Lost DCI-REQ interval Time from sending DCI-REQ and not receiving
a DCI-RSP
CM
DCI-REQ retry
Number of retries of DCI-REQ before rebooting
CM
DCI Backoff start
Initial value for DCI backoff
1 sec
DCI Backoff end
Last value for DCI backoff
16 sec
CM UCD processing
time
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.)
CM
CMTS
147
Default Value
1 sec
35 sec
30 min.
147
300 sec
2 sec
16
1 ms
Row CM T16 added per RFI2-N-02102 by RKV on 10/28/02.
04/22/09
CableLabs
321
CM-SP-RFIv2.0-C02-090422
Annex C
C.1
Common Radio Frequency Interface Encodings
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. 148
Type
Length
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
Length
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
Length
On / Off
1 or 0
148
322
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
C.1.1.4.1
Value
Class ID
The value of the field specifies the identifier for the class of service to which the encapsulated string applies.
Type
Length
4.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.
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.
04/22/09
CableLabs
323
CM-SP-RFIv2.0-C02-090422
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
Length
4.2
Note:
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
Length
4.3
Note:
Value
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
Length
4.4
Value
Valid Range: 0 - 7
324
CableLabs
04/22/09
C.1.1.4.5
CM-SP-RFIv2.0-C02-090422
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
Length
4.5
C.1.1.4.6
Value
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.
This value does not include any physical layer overhead.
Note:
Type
Length
4.6
C.1.1.4.7
Value
Class-of-Service Privacy Enable
This configuration setting enables/disables Baseline Privacy on a provisioned CoS. See [SCTE22-2].
Type
Length
Enable / Disable
4.7 (= CoS_BP_ENABLE)
1 or 0
Table C1 Sample DOCSIS 1.0 Class of Service Encoding

Type
Length
28
C.1.1.5
Value
(sub)type
Length
Value
10,000,000
300,000
64,000
1518
5,000,000
300,000
32,000
min guaranteed 32 kb/sec
1,518
max. Tx burst of 1518 bytes
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
28
class of service configuration setting

service class 2
max. forward rate of 5 Mb/sec
max. return rate of 300 Mb/sec
return path priority of 3
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
Length
Value
16
d1, d2,... d16
04/22/09
CableLabs
325
CM-SP-RFIv2.0-C02-090422
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
Length
Value
16
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
Length
18
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
Length
Value
19
Number of seconds since 00:00 1 Jan 1900
Note:
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
Length
Value
20
IP Address
Note:
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
Length
22
326
Value
CableLabs
04/22/09
C.1.1.11
CM-SP-RFIv2.0-C02-090422
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
Length
23
C.1.1.12
Value
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
Length
24
C.1.1.13
Value
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
Length
25
C.1.1.14
Value
This field defines the parameters associated with Payload Header Suppression.
Type
Length
26
C.1.1.15
Value
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
Length
Value
28
Maximum number of active and inactive Classifiers associated with admitted or active
upstream Service Flows
The default value MUST be 0 no limit.

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
04/22/09
CableLabs
327
CM-SP-RFIv2.0-C02-090422
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
Length
Value
29
0 Disable
1 Enable
The default value of this parameter MUST be 1 privacy enabled.

C.1.1.17
DOCSIS Extension Field 149
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
Length
43
Value
C.1.1.17.1 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
Length
Value
43
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 redefined for any purpose as part of a Vendor-Specific Information encoding.
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.
149
Replaced this section and added subsections per ECN RFIv2.0-N-0125-5 by GO on 3/15/04.
328
CableLabs
04/22/09
Type
Length
Value
43.1
policy id
CM-SP-RFIv2.0-C02-090422
C.1.1.17.1.2 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
Length
Value
43.2
priority
C.1.1.17.1.3 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
Length
Value
43.3
group id
C.1.1.17.1.4 CM Ranging Class ID Extension 150

This config file setting is the CM Ranging Class ID Extension to be defined by the MSO. These bits will be
prepended to the CM's default Ranging Class ID as the most significant bits of the 32 bit Ranging Class ID value.
These bits will be sent in the REG-REQ as part of the CM's Ranging Class ID in the modem capabilities field. If the
TLV is not included in the configuration file, the CM will use zero for this value. These bits allow the user to define
special device classes that could be used to give those devices, or service types, preferential treatment with respect
to ranging after a massive outage. After successful registration, the CM MUST store the entire 32 bit value in nonvolatile memory and use it for ranging decisions after a reboot or a re-init MAC event.
Type
Length
Value
43.4
extended id
C.1.1.17.1.5 L2VPN Encoding 151

The L2VPN Encoding parameter is a multi-part encoding that configures how the CMTS performs Layer 2 Virtual
Private Network bridging for CPE packets. The subtypes of the L2VPN encoding are specified in [L2VPN]. The
CMTS MAY support the DOCSIS Layer 2 Virtual Private Network feature as defined in [L2VPN]. If the L2VPN
feature is not supported, the CMTS MUST ignore the information in the L2VPN configuration setting.
GEI-Encapsulated
L2VPN Encoding:
Type
Length
Value
43.5
L2VPN Encoding subtype/length/ value tuples
150
Added this subsection per ECN RFIv2.0-N-05.0234-4 by GO on 7/15/05; Revised this subsection per ECN RFIv2.0-N-0250-3 by GO
on 11/10/05.
151
04/22/09
CableLabs
329
CM-SP-RFIv2.0-C02-090422
C.1.1.17.2 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
Length
Value
43
per vendor definition
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
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
Length
Value
35
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
Length
Value
36
N (multiple of 4)
Ipa1, Ipa2, Ipa3, Ipa4
330
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
C.1.1.18.3 Subscriber Management Filter Groups 152

The Subscriber Management MIB allows an upstream and downstream filter group to be assigned to a CM and its associated CPEs
and one or more embedded Service/Application Functional Entities (eSAFEs). These filter groups are encoded in the configuration
file in a single TLV as follows:
Type
Length
Value
37
N (multiples of 4
bytes)
bytes 1,2: docsSubMgmtSubFilterDownstream group

bytes 3,4: docsSubMgmtSubFilterUpstream group
bytes 5,6: docsSubMgmtCmFilterDownstream group
bytes 7,8: docsSubMgmtCmFilterUpstream group
bytes 9,10: docsSubMgtPsFilterDownstream group
bytes 11,12: docsSubMgtPsFilterUpstream group
bytes 13,14: docsSubMgtMtaFilterDownstream group
bytes 15,16: docsSubMgtMtaUpstream group
bytes 17,18: docsSubMgtStbFilterDownstream group
bytes 19,20: docsSubMgtStbFilterUpstream group
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
Length
Value
39
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
Length
Value
40
0 Disable
1 Enable
C.1.1.21
Downstream Channel List 153
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 (Annex 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
152
153
Revised the filter group matrix below per ECN RFIv20.-N-05.0216-2 by GO on 6/20/05. Updated the prefix text per email
communication of July 20, 2005.
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-N04.0181-3 by GO on 11/8/04.
04/22/09
CableLabs
331
CM-SP-RFIv2.0-C02-090422
enforce a previously learned downstream channel list. The CM MAY, however, remember this list as an aid to
downstream channel acquisition.
Type
Length
Value
41
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.
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 subTLVs 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
Length
41.1
6 or 10
Value
C.1.1.21.1.1 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
Length
Value
41.1.1
Timeout
332
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
C.1.1.21.1.2 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
Length
Value
41.1.2
DSFrequency
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
Length
41.2
18 or 22
Value
C.1.1.21.2.1 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
Length
Value
41.2.1
Timeout
C.1.1.21.2.2 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
Length
Value
41.2.2
DSFrequencyStart
C.1.1.21.2.3 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.
04/22/09
CableLabs
333
CM-SP-RFIv2.0-C02-090422
Type
Length
Value
41.2.3
DSFrequencyEnd
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
Length
Value
41.2.4
DSFrequencyStep Size
C.1.1.21.3 Default Scanning 154
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
Length
Value
41.3
Timeout
C.1.1.21.4 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 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.
154
Revised this subsection and added the subsequent subsection per ECN RFIv2.0-N-04.0181-3 by GO on 11/9/ 04.
334
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.1.22
Downstream Unencrypted Traffic (DUT) Filtering Encoding 155
This parameter enables the CM to perform Downstream Unencrypted Traffic filtering as described in the DOCSIS
Layer 2 Virtual Private Network specification [L2VPN]. If the CM does not support the DUT Filtering Capability, it
MUST ignore the DUT Filtering Encoding TLV.
DUT Filtering Encoding:
Type
Length
45
Length/value tuples are specified in [L2VPN]
C.1.2
Value
Configuration-File-Specific Settings
These settings are found in only the configuration file. They MUST NOT be forwarded to the CMTS in the
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
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
155
04/22/09
CableLabs
335
CM-SP-RFIv2.0-C02-090422
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
Length
Value
filename
C.1.2.4
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
Length
Value
10
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. 156
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
Length
Value
11
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.
156
Revised this sentence per ECN RFI2-N-03077 by GO on 07/08/03.
336
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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).
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
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
Length
Value
14
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
Length
Value
21
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
Length
Value
34
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
Length
Value
34.1
2-16
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.
C.1.2.8.2
SnmpV3 Kickstart Manager Public Number
Type
Length
Value
34.2
Managers Diffie-Helman public number expressed as an octet string.
04/22/09
CableLabs
337
CM-SP-RFIv2.0-C02-090422
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
Length
Value
32
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 M-CVC 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
Length
Value
33
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 C-CVC 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
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
Length
Value
38
composite
C.1.2.11.1 SNMPv3 Notification Receiver IP Address
This sub-TLV specifies the IP address of the notification receiver.

Type
Length
Value
38.1
ip1, ip2, ip3, ip4
338
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
Value
38.2
UDP port number
C.1.2.11.3 SNMPv3 Notification Receiver Trap Type

Type
Length
Value
38.3
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
Length
Value
38.4
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
Length
Value
38.5
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 Universal
type 6 (Object Identifier) byte, then the ASN.1 length field, then the ASN.1 encoded object identifier components.
Type
Length
Value
38.6
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.
04/22/09
CableLabs
339
CM-SP-RFIv2.0-C02-090422
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
Length
Value
38.7
security name
C.1.2.12
Multicast MAC Address 157
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
Length
Value
42
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.
Note:
The sub-type fields defined are only valid within the encapsulated capabilities configuration setting string.
Type
Length
Value
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
Length
On / Off
5.1
1 or 0
157
Added this section per ECN RFIv2.0-N-04.0143-4 by GO on 7/8/04.
340
CableLabs
04/22/09
C.1.3.1.2
CM-SP-RFIv2.0-C02-090422
DOCSIS Version
DOCSIS version of this modem.

Type
Length
Value
5.2
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
Length
Value
5.3
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
Length
Value
5.4
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
Length
Value
5.5
1 or 0
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
Length
5.6
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.
04/22/09
CableLabs
341
CM-SP-RFIv2.0-C02-090422
Type
Length
Value
5.7
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
Length
Value
5.8
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
Length
Value
5.9
Packet Filtering Support Array

bit #0: 802.1P filtering
bit #1: 802.1Q filtering
bit #2-7: reserved, MUST be set to zero
Note:
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.
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
Length
Value
5.10
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/2spaced or T/4- spaced 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
Length
Value
5.11
8 to 64
342
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
C.1.3.1.12 DCC Support
The value is the DCC support of the CM.

Type
Length
Value
5.12
0 = DCC is not supported

1 = DCC is supported
C.1.3.1.13 IP Filters Support 158
This field shows the number of IP filters that are supported by the CM.
Type
Length
Value
5.13
16-65535
Note:
response.
C.1.3.1.14 LLC Filters Support 159
This field shows the number of LLC filters that are supported by the CM.
Type
Length
Value
5.14
10-65535
Note:
response.
C.1.3.1.15 Expanded unicast SID space 160
Indicate if the CM can support the expanded unicast SID space.

Type
Length
Value
5.15
0 = Expanded Unicast SID space is not supported

1 = Expanded Unicast SID space is supported
C.1.3.1.16 Ranging Hold-off Support 161
The CM indicates support for the Ranging Hold-Off Feature by reporting its Ranging Class ID in the value field.
The low order 16 bits of the Ranging Class ID is comprised of a static bit map which indicates the device type. The
CM sets the bits of the devices to 1 in the bit map. Only a stand-alone cable modem will set Bit#0. For example, a
standalone CM would report a value of 1; a CM with a CableHome PS would report a value of 2; a CM with a
PacketCable MTA, and an ePS would report a value of 6; an eSTB would report a value of 8 although it contained
158

161
159
160
04/22/09
CableLabs
343
CM-SP-RFIv2.0-C02-090422
an eCM. Bits 16 thru 31 are derived from the Configuration File as described in C.1.1.17.1.4. The Ranging Class ID
is not negotiable. The value field in the REG-RSP is ignored by the CM. 162.
Type
Length
Value
5.16
Ranging Class ID (bitmap)

Bit #0: CM
Bit #1: ePS
Bit #2: eMTA
Bit #3: DSG/eSTB
Bits 4 thru 15: Reserved
Bits 16 thru 31: CM Ranging Class ID Extension
C.1.3.1.17 L2VPN Capability 163
This capability indicates whether the CM is compliant with the DOCSIS Layer 2 Virtual Private Network feature as
defined in [L2VPN]. The CM MAY support the DOCSIS Layer 2 Virtual Private Network feature as defined in
[L2VPN].
Type
Length
5.17
Value
C.1.3.1.18 L2VPN eSAFE Host Capability
This capability encoding informs the CMTS of the type and MAC address of an eSAFE host embedded with a CM
that supports the L2VPN feature. A CM MUST NOT include L2VPN eSAFE Host Capability TLV in the
registration request or DHCP Option 60 if it does not indicate support for [L2VPN] via the L2VPN Capability
encoding.
Type
Length
5.18
Value
C.1.3.1.19 Downstream Unencrypted Traffic (DUT) Filtering 164
This capability indicates whether the CM supports the DUT Filtering feature as defined in the DOCSIS Layer 2
Virtual Private Network specification [L2VPN]. The CM MAY support DUT Filtering.
Type
Length
5.19
C.1.3.2
Value
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.
162
Added this subsection per ECN RFIv2.0-N-05.0234-4 by GO on 7/15/05. Corrected conflict between RFIv2.0-N-05.0226 and
RFIv2.0-N-0234 by GO on 8/8/05.
Added C.1.3.1.17 and C.1.3.1.18 per ECN RFIv2.0-N-05.0221-4 by GO on 11/28/05.
164
163
344
CableLabs
04/22/09
Type
Length
Value
v1, v2, v3
C.1.3.3
CM-SP-RFIv2.0-C02-090422
Modem IP Address
For backwards compatibility with DOCSIS v 1.0. Replaced by TFTP Server Provisioned Modem Address.
Type
Length
Value
12
IP Address
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
Length
Value
13
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
Length
Value
44
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).
04/22/09
CableLabs
345
CM-SP-RFIv2.0-C02-090422
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.
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
Length
Value
27
20
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 DSA-REQ
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
Length
Value
30
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
Length
Value
31
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.
346
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
All CMTSes MUST support classification of downstream packets based on IP header fields (Annex C.2.1.5).
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
Length
22
C.2.1.2
Value
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
Length
23
Value
C.2.1.3
General Packet Classifier Encodings
C.2.1.3.1
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
Length
Value
[22/23].1
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
Length
Value
[22/23].2
1 - 65535
C.2.1.3.3
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., CM-initiated
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
Length
Value
[22/23].3
1 - 65535
04/22/09
CableLabs
347
CM-SP-RFIv2.0-C02-090422
C.2.1.3.4
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 CMTS-initiated
DSA-REQ message, the Service Flow ID MUST be specified.
Type
Length
Value
[22/23].4
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
Length
[22/23].5
C.2.1.3.6
Value
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
Length
Value
[22/23].6
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
Length
Value
[22/23].7
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
Length
[22/23].8
348
Value
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 DSC-REQ
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
Length
Value
[22/23].8.1
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
Length
Value
[22/23].8.2
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
Length
Value
[22/23].8.3
Zero-terminated string of ASCII characters.
04/22/09
CableLabs
349
CM-SP-RFIv2.0-C02-090422
Note:
The length N includes the terminating zero.
Note:
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
Length
[22/23].9
C.2.1.5.1
Value
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
Length
Value
[22/23].9.1
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
Length
Value
[22/23].9.2
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
Length
Value
[22/23].9.3
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
Length
Value
[22/23].9.4
smask1, smask2, smask3, smask4
350
CableLabs
04/22/09
C.2.1.5.5
CM-SP-RFIv2.0-C02-090422
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
Length
Value
[22/23].9.5
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
Length
Value
[22/23].9.6
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
Length
Value
[22/23].9.7
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
Length
Value
[22/23].9.8
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
Length
Value
[22/23].9.9
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
Length
Value
[22/23].9.10
dporthigh1, dporthigh2
04/22/09
CableLabs
351
CM-SP-RFIv2.0-C02-090422
C.2.1.6
Ethernet LLC Packet Classification Encodings
This field defines the parameters associated with Ethernet LLC packet classification.
Type
Length
[22/23].10
C.2.1.6.1
Value
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
Length
Value
[22/23].10.1
12
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
Length
Value
[22/23].10.2
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.
352
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
Value
[22/23].10.3
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
Length
[22/23].11
C.2.1.7.1
Value
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 <= pri-high. 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
Length
Value
[22/23].11.1
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
Length
Value
[22/23].11.2
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.) 165
Type
Length Value
[22/23].43
165
04/22/09
CableLabs
353
CM-SP-RFIv2.0-C02-090422
C.2.2
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 network-byte
order, i.e., the octet containing the most-significant bits is the first transmitted on the wire.
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
Length
24
C.2.2.2
Value
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
Length
25
Value
C.2.2.3
General Service Flow Encodings
C.2.2.3.1
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
Length
Value
[24/25].1
1 - 65535
C.2.2.3.2
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 CMTS-initiated
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.
354
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
The configuration file MUST NOT contain this parameter.

Type
Length
Value
[24/25].2
1 - 4,294,967,295
C.2.2.3.3
Service Identifier 166
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
Length
Value
[24].3
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
Length
Value
[24/25].4
2 to 16
Note:
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 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.
166
Revised this section per ECN RFI2-N-02226 by GO on 02/26/03.
04/22/09
CableLabs
355
CM-SP-RFIv2.0-C02-090422
Any Service Flow Encoding that appears in a Dynamic Service Message MUST NOT specify the
ProvisionedQoSParameterSet.
Type
Length
Value
[24/25].6
Bit # 0 Provisioned Set

Bit # 1 Admitted Set
Bit # 2 Active Set
Table C1 Values Used in REG-REQ and REG-RSP Messages

Value
Messages
001
Apply to Provisioned set only
011
Apply to Provisioned and Admitted set, and perform admission control
101
Apply to Provisioned and Active sets, perform admission control on Admitted set in separate Service Flow Encoding,
and activate the Service flow.
111
Apply to Provisioned, Admitted, and Active sets; perform admission control and activate this Service Flow
Table C2 Values Used In REG-REQ, REG-RSP, and Dynamic Service Messages

Value
Messages
010
Perform admission control and apply to Admitted set
100
Check against Admitted set in separate Service flow Encoding, perform admission control if needed, activate this
Service Flow, and apply to Active set
110
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-unrecognized-configurationsetting.
C.2.2.4
Service Flow Error Encodings
This field defines the parameters associated with Service Flow Errors.
Type
Length
[24/25].5
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.
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.
356
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 REG-ACK,
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, DSA-ACK
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
Length
Value
[24/25].5.1
Service Flow Encoding Subtype in Error
C.2.2.4.2
Error Code
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
Length
Value
[24/25].5.2
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.
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
Length
Value
[24/25].5.3
Note:
The length N includes the terminating zero.
Note:
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.
04/22/09
CableLabs
357
CM-SP-RFIv2.0-C02-090422
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
Length
Value
[24/25].7
0 to 7 Higher numbers indicate higher priority
Note:
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. 167 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.
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.
167
The payload size includes every PDU in a Concatenated MAC Frame.
358
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Type
Length
Value
24.8
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
Length
Value
25.8
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 CRC. 168
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. 169
Type
Length
Value
[24/25].9
B (bytes)
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. 170
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 CRC. 171 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).
168

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.
170
Section C.2.2.5.3 second Note added per RFI2-N-02090 by RKV on 10/28/02.
171
169
04/22/09
CableLabs
359
CM-SP-RFIv2.0-C02-090422
This field is only applicable at the CMTS and MUST be enforced by the CMTS.
Type
Length
[24/25].10
Note:
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 CRC. 172 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. 173
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
Length
[24/25].11
C.2.2.5.6
Value
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.
Type
Length
Value
[24/25].12
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 Section 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.
172
173

Revised the last sentence in this paragraph per ECN RFI2-N-03093 by GO on 11/17/03.
360
CableLabs
04/22/09
Type
Length
Value
[24/25].13
seconds
CM-SP-RFIv2.0-C02-090422
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.) 174
Type
Length
[24/25].43
Value
C.2.2.6
Upstream-Specific QoS Parameter Encodings
C.2.2.6.1
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. 175
This field is only applicable at the CM. If defined, this parameter MUST be enforced at the CM.
This value does not include any physical layer overhead.
Type
Length
24.14
Value
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. 176
174

Second sentence updated per RFI2-N-02090 by RKV on 10/28/02.
176
Section C.2.2.6.1, last Note added per RFI2-N-02090 by RKV on 10/28/02.
175
04/22/09
CableLabs
361
CM-SP-RFIv2.0-C02-090422
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. 177
Type
Length
Value
24.15
0 Reserved
1
1 for Undefined (CMTS implementation-dependent )

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
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 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
Length
Value
24.16
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
12
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.
Note:
177
Data grants include both short and long data grants.
Revised Table Note 1 per ECN RFIv2.0-N-04.0125-5 by GO on 3/15/04.
362
CableLabs
04/22/09
C.2.2.6.4
CM-SP-RFIv2.0-C02-090422
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
Length
Value
24.17
sec
C.2.2.6.5
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
with this TLV and interval is the Nominal Poll Interval. The accuracy of the ideal poll times, ti, are measured
This parameter is only applicable at the CMTS. If defined, this parameter represents a service commitment (or
admission criteria) at the CMTS.
Type
Length
Value
24.18
sec
C.2.2.6.6
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
Length
24.19
Note:
Value
For UGS, this parameter should be used by the CMTS to compute the size of the unsolicited grant in minislots.
C.2.2.6.7
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.
04/22/09
CableLabs
363
CM-SP-RFIv2.0-C02-090422
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
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
Length
Value
24.20
sec
C.2.2.6.8
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.
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).
Type
Length
Value
24.21
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.
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.
Type
Length
Value
Valid Range
24.22
# of grants
0-127
364
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
Value
24.23
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
Length
Value
Valid Range
24.24
CMTS Timestamp
0-4,294,967,295
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
Downstream-Specific QoS Parameter Encodings
C.2.2.7.1
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
Length
Value
25.14
sec
C.2.2.8
This field defines the parameters associated with Payload Header Suppression.
Type
Length
26
Note:
Value
The entire Payload Header Suppression TLV MUST have a length of less than 255 characters.
04/22/09
CableLabs
365
CM-SP-RFIv2.0-C02-090422
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
Length
Value
26.1
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
Length
Value
26.2
1 - 65535
C.2.2.8.3
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
Length
Value
26.3
1 - 65535
C.2.2.8.4
The value of this field specifies the Service Flow Identifier that identifies the Service Flow to which the PHS rule
applies.
Type
Length
Value
26.4
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
Length
Value
26.5
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:
366
An attempt to Add a PHS Rule which already exists is an error condition.
CableLabs
04/22/09
C.2.2.9
CM-SP-RFIv2.0-C02-090422
Payload Header Suppression Error Encodings
This field defines the parameters associated with Payload Header Suppression Errors.
Type
Length
26.6
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.
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
Length
Value
26.6.1
Payload Header Suppression Encoding Subtype in Error
C.2.2.9.2
Error Code
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
Length
Value
26.6.2
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.
04/22/09
CableLabs
367
CM-SP-RFIv2.0-C02-090422
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
Length
Value
26.6.3
Note:
The length n includes the terminating zero.
Note:
The entire Payload Header Suppression Encoding message MUST have a total length of less than 256
characters.
C.2.2.10
Payload Header Suppression Rule Encodings
C.2.2.10.1 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 implementation
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
Length
Value
26.7
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
Length
Value
26.8
index value
368
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Length
Value
26.9
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
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
Length
Value
26.10
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
Length
Value
26.11
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.)
04/22/09
CableLabs
369
CM-SP-RFIv2.0-C02-090422
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.) 178
Type
Length
26.43
Value
C.3
Encodings for Other Interfaces
C.3.1
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
Value
15 (= TRI_CFG01) n
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
Length
17 (= BP_CFG)
C.4
Value
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)
178
370
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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)
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 endpoint does not view the transaction as being in process (i.e., the message is unexpected or out of order).
Reject-authentication-failure(11) the requested transaction was rejected because the message contained an
invalid HMAC-digest, CMTS-MIC, provisioned IP address or timestamp.
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.
Reject-PHS-rule-exists(17) indicates that the request to add a PHS rule contains an SFID/classifier ID pair for
which a PHS rule already exists.
04/22/09
CableLabs
371
CM-SP-RFIv2.0-C02-090422
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.
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. 179
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)
179
Revised bulleted statement per ECN RFI2-N-02238 by GO on 02/26/03.
372
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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.
04/22/09
CableLabs
373
CM-SP-RFIv2.0-C02-090422
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 inter-face
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)
374
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
A list of [RFC-868] time-servers from which the current time may be obtained (Time Server Option, option 4)
(non-critical)
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. 180
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).
180
Revised sentence per ECN RFI2-N-02216, by GO, on 12/02/02.
04/22/09
CableLabs
375
CM-SP-RFIv2.0-C02-090422
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. 181
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 D1:
Configuration Configuration
Setting 1
Setting 2
Configuration
Setting n
CM
MIC
CMTS
MIC
Figure D1 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

or
Upstream Service Flow Configuration Setting
Downstream Service Flow Configuration Setting
181
376
CableLabs
04/22/09
Note:
CM-SP-RFIv2.0-C02-090422
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
The following configuration settings MAY be included in the configuration file and if present MUST be supported
by all CMs.
Baseline Privacy Configuration Setting
Software Upgrade Filename Configuration Setting
Upstream Packet Classification Setting
Downstream Packet Classification Setting
SNMP MIB Object
Software Server IP Address
Privacy Enable Configuration Setting
Enable 2.0 Mode
Enable Test Modes 182
Static Multicast MAC Address 183
The following configuration setting MAY be included in the configuration file and if present, and applicable to this
type of modem, MUST be supported.
182
183
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.
04/22/09
CableLabs
377
CM-SP-RFIv2.0-C02-090422
The following configuration settings MAY be included in the configuration file and if present MAY be supported
by a CM.
DOCSIS Extension Field Configuration Settings 184
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 D2 through Figure D5.
Create the type/length/value entries for all the parameters required by the CM.
1.
type, length, value for parameter 1

type, length, value for parameter n

Figure D2 Create TLV Entries for Parameters Required by the CM
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.
2.


type, length, value for CM MIC
Figure D3 Add CM MIC
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.
3.


type, length, value for CMTS MIC
Figure D4 Add CMTS MIC
184
378
CableLabs
04/22/09
4.
CM-SP-RFIv2.0-C02-090422
Add the end of data marker.


type, length, value for CMTS MIC
end of data marker
Figure D5 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
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:
Network Access Configuration Setting
Baseline Privacy Configuration Setting
DOCSIS Extension Field Configuration Settings 185
CM MIC Configuration Setting
185
04/22/09
CableLabs
379
CM-SP-RFIv2.0-C02-090422
Upstream Packet Classification Setting
Downstream Packet Classification Setting
Upstream Service Flow Configuration Setting
Downstream Service Flow Configuration Setting
Privacy Enable Configuration Setting
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 (REGREQ).
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].
380
CableLabs
04/22/09
Annex E
CM-SP-RFIv2.0-C02-090422
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 data-overcable 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 dataforwarding 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 E1 illustrates the general topology.
Bridged Private Network

Cable
Modem
CMTS
Cable
Modem
Cable
Modem
Figure E1 Spanning Tree Topology
The task for the public spanning tree protocol, with reference to Figure E1, 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.
04/22/09
CableLabs
381
CM-SP-RFIv2.0-C02-090422
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 E2:
Link-X
CMTS
(bridge)
Cable
Modem
Switched/
Bridged
Headend
Network

Cable
Modem
CMTS
(bridge)
Figure E2 Spanning Tree Across CMTSes
In Figure E2, 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. 186
IEEE 802.1d BPDUs MUST be ignored and silently discarded.
186
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.
382
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 E1 provides the derived values.
Table E1 CM Path Cost
Modulation Rate
Default Path Cost
kHz
QPSK
16QAM
160
3125
1563
320
1563
781
640
781
391
1280
391
195
2560
195
98
For CMTSes, this formula is:

Path_Cost = 1000 / (Downstream_symbol_rate * bits_per_symbol)
04/22/09
CableLabs
383
CM-SP-RFIv2.0-C02-090422
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.
384
CableLabs
04/22/09
Annex F
CM-SP-RFIv2.0-C02-090422
European Specification Additions 187
This section applies to the second technology option referred to in Section 1 (Section 1.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 cablemodems. 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).
187
Annex F updated per RFIv2.0-N-07.0513-2 by ab on 10/18/2007.
04/22/09
CableLabs
385
CM-SP-RFIv2.0-C02-090422
F.4.2
F.4.2.1
Equipment Assumptions
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

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 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:
Examples of such CENELEC product safety standards are [EN 60950] and [EN 50083-1].
Note:
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 E1. This assumes nominal analogue video carrier
level (peak envelope power) in a 7/8 MHz channel bandwidth. All conditions are present concurrently.
386
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table F1 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.
RF channel spacing (design bandwidth)
7/8 MHz, 8 MHz channels are used for data communication
Transit delay from head-end to most distant customer
0.800 ms (typically much less)
Carrier-to-noise ratio in a 8 MHz band (analogue video level)
Carrier-to-interference ratio for total power (discrete and

broadband ingress signals)
Not less than 52 dB within the design bandwidth
Composite triple beat distortion for analogue modulated

carriers
Not greater than 57 dBc within the design bandwidth (Note 6 a)
Composite second-order distortion for analogue modulated

carriers
Not greater than 57 dBc within the design bandwidth (Note 6 b)
Cross-modulation level
Under consideration
Amplitude ripple
2.5 dB in 8 MHz
Group delay ripple in the spectrum occupied by the CMTS
100 ns over frequency range 0.5 4.43 MHz
Micro-reflections bound for dominant echo
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%)
Burst noise
Not longer than 25 s at a 10 Hz average rate
Seasonal and diurnal signal level variation
8 dB
Signal level slope, 85 - 862 MHz
Maximum slope of 12 dB in either the positive or negative direction
Maximum analogue video carrier level at the system outlet,

inclusive of above signal level variation
77 dBV (Note 6 c)
Lowest analogue video carrier level at the system outlet,

inclusive of above signal level variation
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
04/22/09
CableLabs
387
CM-SP-RFIv2.0-C02-090422
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 F2. All conditions are present concurrently.
Table F2 Assumed upstream RF channel transmission characteristics
Parameter
Value
Frequency range
5 up to 65 MHz edge to edge
Transit delay from the most distant CM to the nearest CM or

CMTS
0.800 ms (typically much less)
Carrier-to-noise ratio in active channel
Not less than 22 dB
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- Not less than 22 dB

path distortion and cross-modulation) ratio in active channel
Not greater than 23 dBc (7.0%)
Burst noise
Not longer than 10 s at a 1 kHz average rate for most cases

(Notes 3 and 4)
Amplitude ripple (maximum)
5-65 MHz: 2.5 dB in 2 MHz
Group delay ripple (maximum)
5-65 MHz: 300 ns in 2 MHz
Micro-reflections (maximum) - Single echo
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 carrierto-noise and carrier-to-interference ratios.
F.4.5
Frequency Inversion
F.5
Communication Protocols
Refer to Section 5.
388
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
F.6
Physical Media Dependent Sublayer Specification
F.6.1
Scope
This section applies to the second technology option referred to in Section 1.1 (Section 1.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

F.6.2.2
Signal Processing Requirements

F.6.2.3
Modulation Formats

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

F.6.2.5
R-S Frame Structure

F.6.2.5.1
R-S Codeword Length
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
F.6.2.5.1.3
Shortened Last Codeword
04/22/09
CableLabs
389
CM-SP-RFIv2.0-C02-090422
F.6.2.5.2
R-S FEC Disabled
Refer to Section 6.2.5.2 188

F.6.2.6
TDMA Byte Interleaver

F.6.2.6.1
Byte Interleaver Parameters

F.6.2.6.2
Interleaver Operating Modes
F.6.2.6.2.1
Fixed Mode
F.6.2.6.2.2
Dynamic Mode

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)

F.6.2.8
TCM Encoder

F.6.2.8.1
TCM R-S Bytes to Symbol Mapping

F.6.2.9
Preamble Prepend

F.6.2.10
Modulation Rates

F.6.2.11
S-CDMA Framer and Interleaver
F.6.2.11.1 S-CDMA Framing Considerations

188
Added Burst Size and R-S FEC Disabled per ECN RFI2-N-02210, by GO, on 11/22/02.
390
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
F.6.2.11.2 Mini-slot Numbering
F.6.2.11.2.1 Mini-slot Numbering Parameters in UCD

F.6.2.11.2.2 Mini-slot Numbering Examples

F.6.2.11.3 Transmission Time

F.6.2.11.4 Latency Considerations

F.6.2.11.5 Spreader-off Bursts for Maintenance on S-CDMA channel

F.6.2.11.6 Limiting the Number of Codes Assigned to a CM

F.6.2.12
S-CDMA Framer

F.6.2.12.1 Subframe Definition

F.6.2.12.2 Framer Operation
F.6.2.12.2.1 Rules for Preamble and Coded TCM Symbols

F.6.2.12.2.2 Rules for Uncoded Symbols and the Uncoded TCM Subsymbols
F.6.2.12.2.3 Subframe Example

04/22/09
CableLabs
391
CM-SP-RFIv2.0-C02-090422
F.6.2.12.2.4 Frame Transmission

F.6.2.13
Symbol Mapping

F.6.2.14
S-CDMA Spreader

F.6.2.14.1 Code Hopping

F.6.2.15
Transmit Pre-Equalizer

F.6.2.16
Spectral Shaping

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

F.6.2.17
Relative Processing Delays

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 F5.
392
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 F3 (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 F3 Constellation Gains and Power Limits
Constellation
Constellation
Gain Gconst
Relative to
64QAM (dB)
Pmin
(dBV)
Pmax
(dBV)
TDMA
Pmax
(dBV)
S-CDMA
Pmin Gconst
(dBV)
Pmax Gconst
(dBV)
TDMA
Pmax Gconst
(dBV)
S-CDMA
QPSK
-1.18
68
118
113
69.18
119.18
114.18
8QAM
-0.21
68
115
113
68.21
115.21
113.21
16QAM
-0.21
68
115
113
68.21
115.21
113.21
32QAM
0.00
68
114
113
68.00
114.00
113.00
64QAM
0.00
68
114
113
68.00
114.00
113.00
128QAM
0.05
68
N/A
113
67.95
N/A
112.95
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 F.6.2.18.1 and Section F.6.2.18.2.
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)
(1) Pr = Pr + P
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.
04/22/09
CableLabs
393
CM-SP-RFIv2.0-C02-090422
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
F.6.2.18.2.1 S-CDMA Transmit Power Calculations with Maximum Scheduled Codes 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)
(1) Pr = Pr + P
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., 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, the number of active codes is 128 and the number of
codes per mini-slot is 2, then Phi = 113 dBV and Plow = 87.24 dBV. The maximum permitted QPSK transmitted
power is 113 - 1.18 = 111.82 dBV when all active codes are transmitted, the minimum QPSK power is 87.24 1.18 - 10 log(128) + 10log(2) = 68 dBV 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 113 dBV when all active
codes are transmitted, and the minimum 64QAM power is 87.24 - 10 log(128) + 10 log(2) = 69.18 dBV with one
mini-slot transmitted. The minimum QPSK power permitted while transmitting, for example, 2 mini-slots is 71
dBV, and the minimum 64QAM power permitted while transmitting 2 mini-slots 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.
394
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.2.2 S-CDMA Transmit Power Calculations with Maximum Scheduled Codes 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[113 - Gconst] over all spreader-on burst profiles used by the CM (see above table)
Plow_S = max[68 - 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)
Pmax_T = maximum target transmit power permitted for the CM in TDMA mode (see above table) for the
constellation used in ranging.
Phi_T = min[Pmax_T - Gconst] over all spreader-off burst profiles used by the CM (see above table)
Pon = Pr clipped at the maximum spreader-on limit
Psf = CM Power Shortfall
Phr = S-CDMA Power Headroom
P = power level adjustment in dB sent from CMTS to CM
(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:
(1) Psf = Pr + max[Gconst,i] - 113 //Difference between spreader-off reported and max spreader-on target
powers
(2) Psf = max[Psf, 0] //Set Psf to 0 if Pt is less than 113 dBV
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 Codes 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
04/22/09
N alloc
10
Pt ,i / 10
i =1
CableLabs
395
CM-SP-RFIv2.0-C02-090422
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 mini-slot is 2, then Phi_S = 113 dBV, Plow_S = 87.24 dBV, and
Phi_T = 118 dBV. Assume the CM ranges at spreader-off target transmit power of 117 dBV. The CM reports Psf =
117 dBV - 113 dBV = 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
= 113 dBV + 0 dB - 21 dB + 6 dB //For a code with 64QAM modulation
= 98 dBV
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:
N act
Peff = 10 log 10
Pt ,i / 10
i =1
= Pon + Phr + 10 log
1
N act
N act
10
Gconst ,i / 10
i =1
where the last term is the average constellation gain.

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 = 113 dBV + 6 dB
= 119 dBV
Limiting the number of codes has given the CM an enhanced effective power of 119 dBV, which is 6 dB above the
normal maximum of 113 dBV, and 2 dB above the ranging power of 117 dBV. 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
Continuing the example, if the measured SNR in the last station maintenance was 17 dB using QPSK modulation
(Gconst,ranging = -1.18 dB), then the Effective SNR referenced to 64QAM modulation is:
effective_SNR = 17 dB - 4 dB + 6 dB + 1.18 dB = 20.18 dB
396
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 818; these characteristics are shared by all users on a given channel. The Burst Profile Attributes are
listed in Table F3 and are further described in Section 8.3.3, Table 819; 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 F5.
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).
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 F4 Burst Profile Attributes
Modulation
QPSK, 8 QAM, 16 QAM, 32 QAM,

64 QAM, 128 QAM(TCM Only)
On/Off
TCM Encoding
On/Off
Preamble Length
0-1536 bits (Note Annex F.6.2.9)
Preamble Value offset
0 to 1534
R-S FEC Error Correction (T)
0 to 16 (0 implies no R-S FEC. The number of codeword parity bytes is 2*T)
R-S FEC Codeword Information Bytes (k)
Fixed: 16 to 253 (assuming R-S FEC on)

Shortened: 16 to 253 (assuming R-S FEC on)
Scrambler Seed
15 bits
1
Maximum Burst Length (mini-slots)

Guard Time
0 to 255
4 to 255 modulation intervals
There is no guard time in S-CDMA.
Fixed, shortened
Scrambler On/Off
On/Off
Interleaver Width (Nr) (RS Codeword Length, k+2*T)
18 to 255
04/22/09
CableLabs
397
CM-SP-RFIv2.0-C02-090422
Byte Interleaver Depth (Ir)
0 to floor(2048/Nr)
4
Byte Interleaver Block Size (Br)
2*Nr to 2048
Interleaver Packet Size (Nf), (in bytes, including FEC)
18 bytes
Preamble Type
QPSK0/QPSK1
5
S-CDMA Spreader
On/Off
5
1 to 128
S-CDMA Interleaver Step
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.
Table F5 User Unique Burst Parameters

Power Level
Adjustment Command
8-bit two's complement,
resolution = 0.25 dB

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)
Resolution = 1 dB or better
Offset Frequency
Range = 32 kHz, resolution = 1 Hz
Frequency Range per Section F.6.2.16.1 Frequency Agility

and Range
Ranging Offset
Integer part: 32-bit two's complement,

resolution = (1 / 10.24 MHz) = 6.25
s/64 = 97.65625 ns
Range: sufficient for maximum cable plant length per Section

F.4.1 Broadband Access Network
Fractional part: unsigned 8-bit fractional

extension, resolution = 6.25 s/(64*256)
= 0.3814697265625 ns
Resolution: TDMA 6.25s/64.

S-CDMA: 6.25 s/(64*256)
Burst Length (mini-slots) if

variable on this channel
(changes burst-to-burst)
N/A
1 to 255 mini-slots
Transmit Equalizer
Coefficients
DOCSIS 2.0 mode: 24 complex

coefficients, 4 bytes per coefficient (2
real and 2 imaginary), load and
convolve modes
DOCSIS 2.0 mode: 24 complex coefficients
(See Section F.6.2.15

Transmit Pre-Equalizer)
DOCSIS 1.1 mode: up to 64 complex coefficients
DOCSIS 1.1 mode: up to 64 complex

coefficients, 4 bytes per coefficient (2
real and 2 imaginary), convolve mode
only
The CM MUST implement the Offset Frequency Adjustment to effect a change in upstream carrier frequency
within 10 Hz of the commanded change.
F.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
398
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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, 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 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 s
plus 1/2 symbol owing to resolution. As an example, for the maximum symbol rate of 5.12 Msym/s, 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 s 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 s / (64*256) ~= 0.3814
ns.
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 Mchips/s, the corresponding maximum resolution for
implementation of the timing correction would be (0.01)*195 ns or roughly 2 ns.
F.6.2.19.2 TDMA Reconfiguration Times

F.6.2.19.3 S-CDMA Reconfiguration Times

F.6.2.19.4 CM Timing Offsets When Changing Modulation Rate
Refer to Section 6.2.19.4. 189

F.6.2.20
Burst Timing Convention

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 F5, 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
189
Section F.6.2.19.4 added per RFI2-N-02178 by RKV on 10/30/02.
04/22/09
CableLabs
399
CM-SP-RFIv2.0-C02-090422
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 F6, Table F7, and Table F8.
In Table F6, 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 F6, allowed to be excluded from
the Bands within 5 to 65 MHz Transmitting Burst specs of Table F8. 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 F6 below 65 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.
Table F6 Spurious Emissions
Parameter
Transmitting Burst
Between Bursts
Inband.
-40 dBc
The greater of -72 dBc or +1 dBV
Adjacent Band
See Table F7.
3 or Fewer Carrier-Related Frequency Bands

(such as second harmonic, if < 65 MHz)
Region 1: -50 dBc for transmitted The greater of -72 dBc or +1 dBV
modulation rate = 320 kHz and
above; -47 dBc for transmitted
modulation rate = 160 kHz
Region 2: -47 dBc
Bands within 5 to 65 MHz (excluding assigned

channel, adjacent channels, and carrier-related
channels)
See Table F8.
30 dBV
1 dBV
max 40 dBc, 34 dBV
34 dBV
20 dBV
15 dBV
15 dBV
max (15 dBV, 40 dB ref d/s )
CM Integrated Spurious Emissions Limits (all in

250kHz, includes discretes)
87.5 to 108 MHz
CM Integrated Spurious Emissions Limits (all in
1
4.75 MHz, includes discretes )
65 to 87.5 MHz
108 to 136 MHz
136 to 862 MHz
400
CableLabs
04/22/09
Parameter
CM-SP-RFIv2.0-C02-090422
Transmitting Burst
Between Bursts
CM Discrete Spurious Emissions Limits )

65 to 87.5 MHz
max 50 dBc, 24 dBV
24 dBV
108 to 862 MHz
10 dBV
10 dBV
1. 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.
2. dB ref d/s is relative to the received downstream signal level. Some spurious outputs are proportional to the receive signal
level.
3. The frequencies from 108 to 136 MHz may be forbidden due to national regulations.
4. 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.
Table F7 Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level
Transmitted carrier
modulation rate
All modulation rates
Specification in the Specification Measurement interval and Adjacent channel carrier

interval, Region 1 in the interval,
distance from carrier
modulation rate
Region 2
edge
-47 dBc
-45 dBc
20 kHz to 180 kHz
160 kSymb/s
-47 dBc
-45 dBc
40 kHz to 360 kHz
320 kSymb/s
-46 dBc
-45 dBc
80 kHz to 720 kHz
640 kSymb/s
-45 dBc
-44 dBc
160 kHz to 1440 kHz
1280 kSymb/s
-44 dBc
-41 dBc
320 kHz to 2880 kHz
2560 kSymb/s
-42 dBc
-38 dBc
640 kHz to 5760 kHz
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.
04/22/09
CableLabs
401
CM-SP-RFIv2.0-C02-090422
Table F8 Spurious Emissions in 5 to 65 MHz Relative to the Transmitted Burst Power Level
Possible modulation
rate in this interval
interval, Region 1
interval, Region 2
Initial measurement interval

and distance from carrier edge
160 kSymb/s
-54 dBc
-53 dBc
220 kHz to 380 kHz
320 kSymb/s
-52 dBc
-50 dBc
240 kHz to 560 kHz
640 kSymb/s
-50 dBc
-47 dBc
280 kHz to 920 kHz
1280 kSymb/s
-48 dBc
-44 dBc
360 kHz to 1640 kHz
2560 kSymb/s
-46 dBc
-41 dBc
520 kHz to 3080 kHz
5120 kSymb/s
-44 dBc
-38 dBc
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.
F.6.2.21.3 Modulation Error Ratio (MER)
F.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 68 for each modulation, each modulation rate, and over the full carrier frequency range, and for S-CDMA,
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
402
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Case 1b: for modulation rate 5.12 MHz

MERsymb 27 dB over 15 to 47 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 42, 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 42 (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.
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 CMs pre-equalizer via ranging response message (both set and convolve modes).
Does not adjust the CM's frequency, timing of power.
F.6.2.21.4 Filter Distortion
F.6.2.21.4.1 Amplitude
F.6.2.21.4.2 Phase
F.6.2.21.5 Carrier Phase Noise

F.6.2.21.6 Channel Frequency Accuracy
04/22/09
CableLabs
403
CM-SP-RFIv2.0-C02-090422
F.6.2.21.7 Modulation Rate Accuracy

F.6.2.21.8 Modulation Timing Jitter
F.6.2.21.8.1 Symbol Timing Jitter for Asynchronous Operation

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.
The CM MUST provide a test mode in which it:
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 upstream symbol clock as in normal synchronous operation.
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.
The intended received power in each carrier MUST be within the values shown in Table F9.
Table F9 Maximum Range of Commanded Nominal Receive Power in Each Carrier
404
Modulation Rate
(kSymb/s)
Maximum Range
(dBV)
160
+44 to +74
320
+47 to +77
640
+50 to +80
1,280
+53 to +83
2,560
+56 to +86
5,120
+59 to +89
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 F10.
Table F10 Electrical Output from CM
Parameter
Value
Frequency
Level range (one channel)
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
QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM
Modulation Rate (nominal)
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
75 ohms
Output Return Loss
> 6 dB (5-65 MHz)
Connector
F connector per [ISO-169-24] (common with the input)
F.6.3
Downstream
This DOCSIS 2.0 Downstream Specification applies only to a CMTS supporting exactly one QAM channel per RF
output port. A CMTS supporting more than one QAM channel per RF output port would instead conform to the
European technology option of the DOCSIS Downstream Radio Frequency Interface as specified in Annex A of
[DRFI] in lieu of this Section.
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 F11. This
interleaver mode fully complies with [EN 300 429].
Table F11 Interleaver characteristics
I (Number of taps)
J (Increment)
Burst protection
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.
04/22/09
CableLabs
405
CM-SP-RFIv2.0-C02-090422
F.6.3.4
CMTS output electrical
The CMTS MUST output an RF modulated signal with the following characteristics defined in Table F12.
Table F12 CMTS output
Parameter
Value
Center Frequency (fc)
112 to 858 MHz 30 kHz
Level
Adjustable over the range 110 to 121 dBV
Modulation type
64QAM and 256QAM
Symbol rate (nominal)

64QAM
6.952 Msym/s
256QAM
6.952 Msym/s
Nominal channel spacing
8 MHz
Frequency response
64QAM
0.15 square root raised cosine shaping
256QAM
0.15 square root raised cosine shaping
Total discrete spurious In-band (fc 4 MHz)
< 57 dBc
In-band spurious and noise (fc 4 MHz)
< 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.
Adjacent channel
(fc 4.0 MHz) to (fc 4.75 MHz)
< 58 dBc in 750 kHz.
Adjacent channel
(fc 4.75 MHz) to (fc 12 MHz)
< 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.
Next adjacent channel

(fc 12 MHz) to (fc 20 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.
Other channels (80 MHz to 1000 MHz)
< 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
75 ohms
Output return loss
> 14 dB within an output channel up to 750 MHz; > 13 dB in an output channel

above 750 MHz
Connector
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 F13).
Table F13 Electrical input to CM
Parameter
Center Frequency
Level Range (one channel)
Value
112 to 858 MHz 30 kHz
43 to 73 dBV for 64QAM
47 to 77 dBV for 256QAM
Modulation Type
64QAM and 256QAM
6.952 Msym/s (64QAM) and 6.952 Msym/s (256QAM)
Bandwidth
8 MHz (alpha = 0.15 square root raised cosine shaping for 64QAM and alpha = 0.15
406
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Parameter
Value
square root raised cosine shaping for 256QAM)
< 90 dBV
Total Input Power (80-862MHz)

Input (load) Impedance
75 ohms
Input Return Loss
> 6 dB (85 to 862 MHz)
Connector
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
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
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
F.6.3.6.2
F.6.3.6.2.1
256QAM
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 F14.
Table F14 256QAM CM BER performance
F.6.3.6.2.2
Input receive signal level
Es/No
47 dBV to 54 dBV
34.5 dB
> 54 to +77 dBV
31.5 dB
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
04/22/09
CableLabs
407
CM-SP-RFIv2.0-C02-090422
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
Performance as described in Annex F.6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with digital
F.6.3.6.2.4
Additional specifications for QAM
The following additional specifications are given for the QAM-modulation.

Table F15 QAM Modulation
F.6.3.7
Parameter
Specification
I/Q Phase offset
< 1.0
I/Q crosstalk
-50 dB
I/Q Amplitude imbalance
0.05 dB max
I/Q timing skew
< 3.0 nsec
CMTS timestamp jitter

F.6.3.7.1
CMTS Master Clock Jitter for Asynchronous Operation

F.6.3.7.2
CMTS Master Clock Jitter for Synchronous Operation

F.6.3.7.3
CMTS Master Clock Frequency Drift for Synchronous Operation

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.
408
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 F16 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 F16 Downstream symbol rates and example parameters for synchronization with the CMTS Master
Clock
Downstream mode
Nominal Specified
Symbol Rate, fb (MHz)
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:
10 Hz to 100 Hz
100 Hz to 1 kHz
1 kHz to 10 kHz
10 kHz to 100 kHz
< [-27 + 20*log(fDS/6.952)] dBc (i.e., < 1 nsec RMS)
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.
04/22/09
CableLabs
409
CM-SP-RFIv2.0-C02-090422
F.6.3.10
Downstream Symbol Clock Drift for Synchronous Operation
F.7
Downstream transmission convergence sublayer
F.7.1
Introduction

F.7.2
MPEG Packet format

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 F17. 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 F17. 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 F17 MPEG Header format for Euro-DOCSIS Data-Over-Cable packets
Field
Length (bits)
Description
sync_byte
0x47; MPEG Packet Sync byte.
transport_error_indicator
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.
payload_unit_start_indicator
A value of one indicates the presence of a pointer_field as the first byte of the
payload (fifth byte of the packet)
transport_priority
Reserved; set to zero.
PID (see Note)
13
Euro-DOCSIS Data-Over-Cable well-known PID (0x1FFE)
transport_scrambling_control
Reserved; set to 00.
adaptation_field_control
01; use of the adaptation_field is NOT ALLOWED on the Euro-DOCSIS PID.
continuity_counter
Cyclic counter within this PID
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 Euro-DOCSIS 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.)
410
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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:
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

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

F.8.2
MAC Frame Formats

F.8.3
MAC Management Messages
F.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 F3.
04/22/09
CableLabs
411
CM-SP-RFIv2.0-C02-090422
Figure F3 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.
412
CableLabs
04/22/09
Annex G
CM-SP-RFIv2.0-C02-090422
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 and DOCSIS 2.0) 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. 190
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. 191
190
191

04/22/09
CableLabs
413
CM-SP-RFIv2.0-C02-090422
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 RegistrationRequest.
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 Registration-Acknowledgment 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 RegistrationRequest indicated that the CM was a 2.0 CM. The following table summarizes registration behavior for all cases
involving a DOCSIS 2.0 CM.
414
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table G1 Registration Behavior for a DOCSIS 2.0 CM

Configuration file
DOCSIS 1.0 CMTS
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
1.1/2.0-style configuration N/A

file that does not disable
DOCSIS 2.0 mode
CM sends 1.1/2.0-style REGCM sends 1.1/2.0-style REG-REQ.

REQ. CMTS sends 1.1/2.0-style CMTS sends 1.1/2.0-style REG-RESP
REG-RESP and CM responds
and CM responds with REG-ACK.
with REG-ACK.
1.0-style configuration file CM sends 1.0-style REGthat does not disable

REQ. CMTS sends 1.0-style
DOCSIS 2.0 mode.
REG-RESP. CM MUST NOT
send REG-ACK.
CM sends 1.0-style REG-REQ.

CMTS sends 1.0-style REGRESP. CM MUST NOT send
REG-ACK.
1.1/2.0-style configuration N/A

file that disables DOCSIS
2.0 mode.
CM sends 1.1/2.0-style REGCM sends 1.1/2.0-style REG-REQ.

REQ. CMTS sends 1.1/2.0-style CMTS sends 1.1/2.0-style REG-RESP
REG-RESP and CM responds
and CM responds with REG-ACK.
with REG-ACK.
1.0-style configuration file CM sends 1.0-style REGthat disables DOCSIS 2.0 REQ. CMTS sends 1.0-style
mode.
REG-RESP. CM MUST NOT
send REG-ACK.
CM sends 1.0-style REG-REQ.

CMTS sends 1.0-style REGRESP. CM MUST NOT send
REG-ACK.
CM sends 1.0-style REG-REQ. 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.0-style REG-REQ. 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
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.
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.
04/22/09
CableLabs
415
CM-SP-RFIv2.0-C02-090422
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. 192
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 DCCRequest 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 re-ranging 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.
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 G2. The
CMTS MAY provide switches, as indicated in Table G2, 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. 193
192
193

Revised this paragraph per ECN RFIv2.0-N-0167-2 by GO on 10/18/02.
416
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table G2 Hybrid Mode Controls

Concatenation Support
Fragmentation Support
Privacy Support
1.0 CM
allow/[deny]
allow/[deny]
allow BPI+/[force BPI]
1.1 or 2.0 CM in 1.0 mode
allow/[deny]
allow/[deny]
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
DOCSIS 2.0 TDMA Interoperability
G.3.1
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 1112).
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).
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.
04/22/09
CableLabs
417
CM-SP-RFIv2.0-C02-090422
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
DOCSIS 2.0 S-CDMA Interoperability
G.4.1
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.
418
CableLabs
04/22/09
Annex H
H.1
CM-SP-RFIv2.0-C02-090422
The DOCSIS MAC/PHY Interface (DMPI)
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.
H.2.5
Timing Specifications
The timing specs for DMPI use the following terminology:
04/22/09
CableLabs
419
CM-SP-RFIv2.0-C02-090422
Table H1 Timing Parameters

Parameter
Clock Frequency
Symbol
f
Clock Low Pulse Width
tlpw
Clock High Pulse Width
thpw
Description
The frequency of the interface clock.
The low time of the interface clock.
The high time of the interface clock.
Clock rise/fall time
trf
The transition time of the clock.
Input Setup Time to Clock
tsu
From when an interface signal is valid to the following rising clock edge.
Input Hold Time from Clock
th
From the rising clock edge to when an interface signal becomes invalid.
Clock to Signal Valid Delay
tcq
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.
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.
420
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 H1 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.
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
US PHY
UC_DV_N
UC_RDY_N
INT_N
SPI_SS1_N
SPI_CLK
TS_CLK
US_CLK
Figure H1 DMPI Application
04/22/09
CableLabs
421
CM-SP-RFIv2.0-C02-090422
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.
422
CableLabs
04/22/09
H.4
Signals
H.4.1
Downstream Data
CM-SP-RFIv2.0-C02-090422
The signals used for the Downstream Data Interface are defined in Table H2.
Table H2 Downstream Data Interface Signals
Signal
DS_CLK
Description
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 H3.
Table H3 Upstream Data Interface Signals
Signal
US_CLK
Description
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

indicates valid data on UD_DATA
UD_DATA[3:0]
Upstream Data
UD_DATAP
Upstream Data Parity

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.
04/22/09
CableLabs
423
CM-SP-RFIv2.0-C02-090422
H.4.3
Upstream Control
Table H4 lists the signals that are used for the Upstream Control Interface.
Table H4 Upstream Control Interface Signals
Signal
US_CLK
Description
Upstream Clock
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

TS_FS_N
Timestamp Frame Sync

Driven by the MAC
H.4.4
SPI Bus
Table H5 SPI Bus Signals
Signal Name
SPI_CLK
Description
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
424
CableLabs
04/22/09
H.4.5
CM-SP-RFIv2.0-C02-090422
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)
04/22/09
CableLabs
425
CM-SP-RFIv2.0-C02-090422
H.5
Protocol
H.5.1
Downstream Data (ITU-T Recommendations J.83 Annex A)
Figure H2 shows the protocol for ITU-T Recommendations J.83 Annex A operation.
DS_CLK
DS_MSYNC_N
DS_VALID_N
DS_DATA
SYNCH SYNCL
1H
1L
2H
2L
187H
187L
SYNCH SYNCL
DS_DATAP
Figure H2 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 packet transfer and then MUST de-assert
it for exactly 32 clocks following the transfer of the last nibble of the MPEG packet. 194
194
426
CableLabs
04/22/09
H.5.2
CM-SP-RFIv2.0-C02-090422
Downstream Data (ITU-T Recommendations J.83 Annex B)
Figure H3 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
SYNCH SYNCL
1H
1L
2H
187H
2L
187L
SYNCH SYNCL
DS_DATAP
Figure H3 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 H4 shows the signaling protocol for this interface.
US_CLK
UD_SOB_N
UD_DV_N
UD_DATA
B0H
B0L
B1H
B1L
BNH
BNL
B0H
B0L
UD_DATAP
Figure H4 Upstream Data Protocol
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.
04/22/09
CableLabs
427
CM-SP-RFIv2.0-C02-090422
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
H.5.4.1
Upstream Control
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 H6.
Table H6 Timestamp Counter Initialization Options
Upper Bits
Lower Bits
Frame Sync Interval
24
1638.4 ms
23
819.2 ms
10
22
409.6 ms
11
21
204.8 ms
12
20
102.4 ms
Figure H5 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 H5 Counter Synchronization
The MAC MUST assert TS_FS_N two 10.24 MHz clock periods prior to the lower bits of the MAC timestamp
counter equaling 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 H6. 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.
428
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 re-initialized 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 H6 shows a sample transaction.
US_CLK
UC_DV_N
UC_DATA
UC_RDY_N
Figure H6 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.
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
04/22/09
CableLabs
429
CM-SP-RFIv2.0-C02-090422
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. 195
H.5.5
SPI Bus
Figure H7 shows a SPI Bus transaction.
SPI_CLK
SPI_SSx_N
SPI_MOSI
MSB
SPI_MISO
Figure H7 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 deasserting 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.
H.6
Electrical Specifications
H.6.1
DC Specifications
Devices which connect to DMPI must meet the requirements listed in Table H7. Note that Output High Voltage
and Output High Current specifications do not apply to the INT_N output as it is open drain.
195
Replaced bulleted paragraph per ECN RFI2-N-02218, by GO on 12/03/02.
430
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Table H7 DC Characteristics
Parameter
Symbol
Min.
Input Capacitance
Max
Units
10
pf
0.8
0.4
Input Low Voltage
Vil
Input High Voltage
Vih
Output Low Voltage
Vol
Output High Voltage
Voh
2.4
Output Low Current
Iol
ma
Output High Current
Ioh
-4
ma
H.7
Timing Specifications
H.7.1
Downstream Data
2.0
Comments
Table H8 DS Data Interface Timing

Parameter
DS_CLK Frequency
Symbol
Min.
Max.
Units
25
MHz
DS_CLK Low Pulse Width
tlpw
10
ns
DS_CLK High Pulse Width
thpw
10
ns
DS_CLK rise/fall time
trf
ns
DS_CLK Jitter
tj
97.66
ns
Input Setup Time to DS_CLK
tsu
10
ns
Input Hold Time from DS_CLK
th
ns
DS_CLK to Signal Valid Delay
tcq
H.7.2
15
ns
Min.
Max.
Units
40.96
MHz
Upstream Data
Table H9 US Data Interface Timing
Parameter
US_CLK Frequency
Symbol
f
33
US_CLK Low Pulse Width
tlpw
6.5
US_CLK High Pulse Width
thpw
6.5
ns
ns
US_CLK rise/fall time
trf
Input Setup Time to US_CLK
tsu
ns
Input Hold Time from US_CLK
th
ns
US_CLK to Signal Valid Delay
tcq
04/22/09
CableLabs
12
ns
ns
431
CM-SP-RFIv2.0-C02-090422
H.7.3
Upstream Control
Table H10 Upstream Control Interface Timing
Parameter
Symbol
Min.
Max.
Units
Input Setup Time to US_CLK
tsu
ns
Input Hold Time from US_CLK
th
ns
US_CLK to Signal Valid Delay
tcq
12
ns
ns
TS_CLK rise/fall time
trf
Input Setup Time to TS_CLK
tsu
10
Input Hold Time from TS_CLK
th
TS_CLK to Signal Valid Delay
tcq
15
ns
Min.
Max.
Units
10.24
MHz
H.7.4
ns
ns
SPI Bus
Table H11 SPI Bus Timing
Parameter
Symbol
SPI_CLK Frequency
f
1
ns
ns
SPI_CLK Low Pulse Width
tlpw
43.9
SPI_CLK High Pulse Width
thpw
43.9
SPI_CLK rise/fall time
trf
SPI_MOSI or SPI_MISO Setup Time to SPI_CLK
tsu
SPI_MOSI or SPI_MISO Hold Time from SPI_CLK
ns
15
ns
th
ns
tsu
50
ns
SPI_SSx_N Setup Time to SPI_CLK falling
tsu
25
ns
SPI_SSx_N Hold Time from SPI_CLK
th
ns
tcq
SPI_SSx_N Setup Time to SPI_CLK rising
SPI_CLK to Signal Valid Delay
12
Can be achieved with a 45/55 duty cycle 10.24Mhz clock
Can be achieved with a 45/55 duty cycle 10.24Mhz clock
Applies to PHYs which sample SPI_SSx_N with the rising edge of SPI_CLK. Ignored otherwise.
Applies to PHYs which sample SPI_SSx_N with the falling edge of SPI_CLK. Ignored otherwise.
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 196
ns
The data which passes from the MAC to the PHY is a stream of MPEG packets. The start of the SYNC byte is
indicated by the assertion of the DS_MSYNC_N signal. Including the SYNC byte, each MPEG packet is 188 bytes
in length.
The MAC MUST generate null MPEG packets when there are no DOCSIS frames to be transmitted.
196
432
CableLabs
04/22/09
H.8.2
CM-SP-RFIv2.0-C02-090422
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 H12 (except for the CHANNEL Data
Block Type as indicated in Annex H.8.2.8.5).
Table H12 Upstream Data Block Format
Size (bytes)
Name
Description
Block Type
identifies the type of Block
Block Length
length of Block data field in bytes (N)
Block Data
Not present for CHANNEL Block Type

Block data
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 H13 gives a complete list of all Block Types.
Table H13 Upstream Data Block Types
Type
Name
0x00
Reserved
0x01
FIRST_DATA
Description
Reserved
First data of burst
contains 7 bytes of fixed format status data and first data of burst
0x02
MIDDLE_DATA
0x03
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
NO_BURST
0x06
CHANNEL
Used to indicate the channel to which the next Data Block belongs.
0x07-0xff
Reserved
Reserved
H.8.2.2
Indicates that no burst was received during a transmit opportunity
FIRST_DATA Block
Table H14 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.
04/22/09
CableLabs
433
CM-SP-RFIv2.0-C02-090422
Table H14 FIRST_DATA Data Format

Size (bytes)
1
Name
FIRST_STATUS
Description
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
H.8.2.3
START_MINISLOT
Derived from the Upstream Control Interval Description message parameters
BURST_DATA
First data of burst
MIDDLE_DATA Block
Table H15 shows the format of the MIDDLE_DATA Block. The MIDDLE_DATA block is used to transfer burst
data.
Table H15 MIDDLE_DATA Data Format
Size (bytes)
N
H.8.2.4
Name
BURST_DATA
Description
Middle data of burst
LAST_DATA Block
Table H16 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 H16 LAST_DATA Data Format
Size (bytes)
Name
Description
N-4
BURST_DATA
Last data of burst
LAST_STATUS
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

UNCORRECTED_FEC the number of uncorrected FEC blocks in the burst

434
CableLabs
04/22/09
H.8.2.5
CM-SP-RFIv2.0-C02-090422
PHY_STATUS Block
Table H17 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 H17 PHY_STATUS Data Format
Size (bytes)
N
H.8.2.6
Name
PHY_STATUS
Description
PHY specific status information such as channel characteristics (e.g., timing error, power
error, frequency error, EQ coefficients)
NO_BURST Block
Table H18 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 H18 NO_BURST Data Format
Size (bytes)
2
Name
SID_STATUS
Description
bit 15, collision, collision occurred
bit 14, no energy, no energy detected
bit 13:0, SID, taken from the Upstream Control Interval Description message
START_MINISLOT
IUC
Derived from the Upstream Control Interval Description message parameters

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 H19 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 H19 CHANNEL Data Format
Size (bytes)
1
Name
Description
CHANNEL

bit 2:0, Channel Number
H.8.2.8
Block Usage
H.8.2.8.1
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
04/22/09
CableLabs
435
CM-SP-RFIv2.0-C02-090422
defined in A.2.1). 197 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).
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).
197
Replaced sentence per ECN RFI2-N-02217, by GO, on 12/03/02.
436
CableLabs
04/22/09
H.8.2.8.3
CM-SP-RFIv2.0-C02-090422
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 noncontention 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 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
04/22/09
CableLabs
437
CM-SP-RFIv2.0-C02-090422
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 H20.
Table H20 Upstream Control Message Format
Size (bits)
Name
TYPE
Description
Message Type
CHANNEL
Logical Channel Number
PAYLOAD
Payload of Message
PARITY
Even parity for all bits in the Message (the number of 1s across all bits in {TYPE, CHANNEL,
PAYLOAD, PARITY} is even)
Table H21 shows the Message Type encoding.

Table H21 Upstream Message Types
Type
Name
Description
0x0
INTERVAL_DESC Describes an interval

RIPTION
0x1
UCD_CHANGE
Indicates a UCD change has occurred
Reserved
Reserved
0x2-0x7
H.8.3.1
Interval Description Message
Table H22 describes the format of the Interval Description Message Payload.
Table H22 Upstream Control Interval Description PAYLOAD Format
Size (bits)
438
Name
Description
14
SID
expected SID from MAP IE
IUC
IUC from MAP IE
14
LENGTH
length in mini-slots
32
START_MINISLOT starting mini-slot of interval (alloc start time + offset of IE)
PSC
PHY_STATUS Control
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 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
198
Acknowledgement IE's, or Data Grants Pending (since none of these is an Interval Allocation).
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.
198
Replaced paragraph per ECN RFI2-N-02217, by GO, on 12/03/02.
04/22/09
CableLabs
439
CM-SP-RFIv2.0-C02-090422
H.8.3.2
UCD Change Message
Table H23 describes the format of the UCD Change Message Payload.
Table H23 UCD Change PAYLOAD Format
Size (bits)
8
Name
CCC
Description
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.
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 H24 SPI Bus Transaction Format
Size (bits)
Name
Description
DEVICE_ID
Device ID
RSVD
Reserved
WRITE
1=Write, 0=Read
16
REGISTER_ADD
Register Address
N*8
WRITE_DATA
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.
440
CableLabs
04/22/09
Appendix I
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
441
CM-SP-RFIv2.0-C02-090422
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 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.
442
CableLabs
04/22/09
I.2
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
443
CM-SP-RFIv2.0-C02-090422
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.
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:
444
No parameters specified.
CableLabs
04/22/09
I.3
CM-SP-RFIv2.0-C02-090422
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.
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.
04/22/09
CableLabs
445
CM-SP-RFIv2.0-C02-090422
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.
flow.
flow.
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).
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:
446
CableLabs
04/22/09
I.3.7
CM-SP-RFIv2.0-C02-090422
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.
flow.
flow.
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.
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.
04/22/09
CableLabs
447
CM-SP-RFIv2.0-C02-090422
flow.
flow.
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 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 per-packet
service flow classification is required for traffic ingress from the RF.
Upper layer service receives PDUs from the MAC_DATA.indicate service.
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.
448
MAC_CHANGE_SERVICE_FLOW.request/response
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
449
CM-SP-RFIv2.0-C02-090422
Appendix II
II.1
Example Preamble Sequence
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 818), 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 819).
The first bit of the Preamble Pattern is designated by the Preamble Value Offset as described in Table 819, Section
8.3.3. The first bit of the Preamble Pattern is the first bit into the symbol mapper (Figure 62 and Figure 63), and is
the first symbol of the burst (see Section 6.2.13). As an example, per Table 819, 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 Appendix
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
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
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
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
1110 1110 1110 0010 0010 0010 1110 0010 1110 1110 1110 1110 0010 0010 1110 0010
450
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
1110 0010 0010 0010 1110 1110 0010 0010 0010 0010 1110 0010 0010 0010 0010 1110
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
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
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
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
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
04/22/09
CableLabs
451
CM-SP-RFIv2.0-C02-090422
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 III1, the
four upstream channels are on separate fibres serving four geographical communities of modems.
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.
452
CableLabs
04/22/09
CMTS
CM-SP-RFIv2.0-C02-090422
Downstream Laser &

Upstream Receiver
Fiber Nodes
CMs
fD0
fU0
fU1
fU2
fU3
Coax
Fiber
Coax
Figure III1 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.
04/22/09
CableLabs
453
CM-SP-RFIv2.0-C02-090422
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 III1, 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.
454
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
III.2.1 Topologies
Suppose two downstream channels are used in conjunction with four upstream channels as shown in Figure III2.
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.
CMTS
fD0
T
o
p
o
l
o
g
y
Downstream Laser &

Upstream Receiver
Fiber Nodes
CMs
fU0
fU1
fD1
fU2
#1
fU3
fD0
T
o
p
o
l
o
g
y
fU0
fU1
fD1
fU2
#2
fU3
fD0
T
o
p
o
l
o
g
y
fU0
fU1
fD1
fU2
#3
fU3
Coax
Fiber
Coax
Figure III2 Multiple Downstream and Multiple Upstream Channels per CM
04/22/09
CableLabs
455
CM-SP-RFIv2.0-C02-090422
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 III1 lists MAC messages that contain Channel IDs.

Table III1 MAC Messages with Channel IDs
MAC Message
Upstream Channel ID
UCD
Yes
Yes
MAP
No
Yes
RNG-REQ
Yes
No
RNG-RSP
No
Yes
DCC-REQ
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.
456
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
04/22/09
CableLabs
457
CM-SP-RFIv2.0-C02-090422
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. 199
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 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
Tx Resv. Data w/o

Piggyback OR
Too Many
Retries OR
(TX Frag w/o
Piggyback && L
Grant
Pendin
Retry
Data Ack
Pending
Retry
Grant
Pending
Tx Resv.
Request
Tx Resv.
Data w/Piggyback
Figure IV1 Transmission & Deference State Transition Diagram
199
This bulleted item added per RFI2-N-02093 by RKV on 10/28/02.
458
CableLabs
04/22/09
IV.2
CM-SP-RFIv2.0-C02-090422
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;
CalcDefer();
go to Deferring
04/22/09
/* Packet available to transmit */
CableLabs
459
CM-SP-RFIv2.0-C02-090422
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

if (Grant SID == my_SID)
/* Unsolicited Grant */
{
UtilizeGrant();
}
else if (unicast Request SID == my_SID)
/* Unsolicited Unicast Request */
{
transmit Request in reservation;
Tx_time = time;
}
else
{
go to state Grant Pending;
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)
else
go to state Data Ack Pending;
}
else
/* Send Request in contention */
{
transmit Request in contention;
460
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
Tx_time = time;
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

if (Grant size >= pkt size)
/* CM can send full pkt */
{
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;
}
else if (Grant size == 0)
/* 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)
/* multiple grant mode */
piggyback_size = 0
else
piggyback_size = pkt_size
/* piggyback mode */
04/22/09
CableLabs
461
CM-SP-RFIv2.0-C02-090422
if (piggyback_size > 0)
transmit fragment with piggyback request for remainder of packet
in reservation
else
transmit fragment in reservation;
}
}
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;
462
CableLabs
04/22/09
Appendix V
CM-SP-RFIv2.0-C02-090422
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
E1/A2
E5/A7
E4/A6
E2/A4
E1/A3
Joined
E6/A7
E3/A5
Figure V1 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 Failure 200
200
SA-MAP response returns an error code of 7 - not authorized for requested downstream traffic flow.
04/22/09
CableLabs
463
CM-SP-RFIv2.0-C02-090422
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 necessary; 201 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
201
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.
464
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Unsolicited Grant Service (UGS)
VI.1.1 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
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.
04/22/09
CableLabs
465
CM-SP-RFIv2.0-C02-090422
VI.1.4 Jitter
Figure VI1 shows the relationship between Grant Interval and Tolerated Grant Jitter, and shows an example of
jitter on subflows.
Max Tolerated
Jitter
Max Tolerated
Jitter
Max Tolerated
Jitter
Grants per SID

Subflows
1
t0
1
ti
ti'
ti+jitter
Figure VI1 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 VI1 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.
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.
466
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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
Unsolicited Grant Service with Activity Detection (UGS-AD)
VI.2.1 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:
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.
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.
04/22/09
CableLabs
467
CM-SP-RFIv2.0-C02-090422
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
0
10
20
30
40
50
ms
Voice
G.711
CODEC
Tx Queue
Polled Requests
Unsolicited Grants
Data on Upstream
Play Out
Figure VI2 VAD Start-Up and Stop
Figure VI2 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.
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.
468
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 VI1.
Table VI1 Example Request to Grant Response Time
Variable
Example Value
The time taken from when the voice packet was created to the time that voice packet
arrives in the CM upstream queue.
0-1
ms
The time until a polled request is received. The worst case time is the Polled Request
Interval.
0-5
ms
The Request-Grant response time of the CMTS. This value is affected by MAP length
and the number of outstanding MAPS.
5 - 15
ms
The round trip delay of the HFC plant including the downstream interleaving delay.
1-5
ms
6 - 26
ms
Total
This number will vary between CMTS implementations, but a reasonable number of extra grants to expect from the
example above would be:
Table VI2 Example Extra Grants for New Talk Spurts
UGS Interval
Extra Grants for New Talk Spurts
10 ms
20 ms
30 ms
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.
04/22/09
CableLabs
469
CM-SP-RFIv2.0-C02-090422
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.
470
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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)
}
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;
}
04/22/09
CableLabs
471
CM-SP-RFIv2.0-C02-090422
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 Appendix VII.2, the listing supports the case of a shortened sub-frame.
472
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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 VIII1 lists plant delay variations that can be accommodated in S-CDMA and
TDMA modes for a 1 dB degradation under example conditions.
Table VIII1 Allowable plant timing drift
Constellation
Es/No for 1e-8 BER(dB)
Allowable peak-peak plant

delay variation (ns)S-CDMA
mode
Allowable peak-peak plant

delay variation (ns)TDMA
mode
90
800
TCM QPSK
79
N/A
TCM 8QAM
12
57
N/A
Fully-coded QPSK
Uncoded QPSK
15
38
800
17.7
24
800
TCM 32QAM
19
18
N/A
Uncoded 16QAM
22
800
Uncoded 32QAM
25
800
TCM 128QAM
25
N/A
Uncoded 64QAM
28
800
Fully-coded 64QAM
04/22/09
CableLabs
473
CM-SP-RFIv2.0-C02-090422
Defined conditions:
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
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 42.
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. 202
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.
202
Revised this paragraph per ECN RFI2-N-03077 by GO on 07/08/03.
474
CableLabs
04/22/09
CM-SP-RFIv2.0-C02-090422
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.
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
04/22/09
CableLabs
475
CM-SP-RFIv2.0-C02-090422
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
476
CableLabs
04/22/09
Appendix X
X.1
CM-SP-RFIv2.0-C02-090422
Revisions
ECNs included in SP-RFIv2.0-I02-020617

ECN
Date Accepted
rfi2-n-02001
02/20/02
Author
Summary
Mark Tillinghast Provide consistent description for raised cosine filters.
rfi2-n-02002
02/13/02
Greg White
Replace sections 8 and 11.
rfi2-n-02004
02/13/02
Lisa Denney
Eliminate burst profile type mixing.
rfi2-n-02015
02/20/02
Greg White
Remove 2.0 mode TLV from CMTS MIC.
rfi2-n-02020
02/27/02
Ariel Yagil
Minor S-CDMA change.
rfi2-n-02025
04/17/02
Bruce Currivan Corrections to MER requirements.
rfi2-n-02026
03/06/02
Bruce Currivan Add test mode requirements.
rfi2-n-02027
04/03/02
Rusty Cashman Clarify amplitude flatness requirements.
rfi2-n-02028
03/06/02
Bruce Currivan Clarify preamble support in 1.x bursts.
rfi2-n-02029
03/06/02
Bruce Currivan Specify exactly placement of return-to-zero bits.
rfi2-n-02031
04/03/02
rfi2-n-02034
03/13/02
rfi2-n-02035
03/13/02
rfi2-n-02038
03/20/02
rfi2-n-02039
03/20/02
rfi2-n-02044
03/27/02
rfi2-n-02047
04/03/02
rfi2-n-02049
04/03/02
rfi2-n-02050
04/17/02
Paul Richardson Clarify the RS interleaver parameters.
rfi2-n-02052
05/01/02
Mike Grimwood Clarify transmit pre-EQ coeff. normalization.
rfi2-n-02055
04/10//02
Kaz Ozawa
Clarification of BPI/BPI+ provisioning.
rfi2-n-02056
04/03/02
Kaz Ozawa
Update CM REG-REQ config file settings.
Margo Dolas
Clarify symbol rate inconsistencies.
Greg White
Disable protocols on CPE port.
Hassan Yaghoobi Delete carrier phase randomization of contention bursts.

Bruce Currivan Define bit ordering in figures.
Margo Dolas
Delete initialization techniques.
Rusty Cashman Correct initial ranging channel selection.

Yael Barzilai
Bring consistency to authorization/authentication failure responses.
Rusty Cashman REG-ACK clarifications, chapter 11 clarification.

Kevin Marez
Clarify spreader on/off in station maintenance.
rfi2-n-02057
05/22/02
rfi2-n-02065
04/24/02
Efrat Zeharhary Clarify CM response to an incorrect DCC-REQ.
rfi2-n-02066
05/08/02
Rusty Cashman Clarify 2.0 mode registration details.
rfi2-n-02070
05/01/02
Margo Dolas
Clarifiy switch between 1.x and 2.0 IUCs.
rfi2-n-02095
05/29/02
Greg White
Corrections and clarifications.
rfi2-n-02096
05/22/02
Greg White
Add Test Mode config file TLV.
Dan Crocker
Replace Annex H.
rfi2-n-02100
05/22/02
rfi2-n-02103
05/29/02
04/22/09
Bruce Currivan Correct mini-slot minimum capacity.
CableLabs
477
CM-SP-RFIv2.0-C02-090422
X.2
478

ECN
Date Accepted
Author
Summary
rfi2-n-02085
06/12/02
rfi2-n-02089
07/24/02
rfi2-n-02090
06/12/02
rfi2-n-02093
07/31/02
Zvi Shteingart
rfi2-n-02102
08/07/02
Daniel Howard Create CM test mode for testing phase noise and jitter of CM carrier
and symbol timing.
rfi2-n-02104
07/03/02
Bruce Currivan Clarify description of user-unique burst parameters.
rfi2-n-02105
06/05/02
rfi2-n-02111
06/12/02
rfi2-n-02123
07/10/02
Margo Dolas
Clarify code hopper synchronization after a UCD change.
rfi2-n-02130
07/10/02
Margo Dolas
Correct typographical error in ECN# RFI2-N-02070.
rfi2-n-02135
08/14/02
Hassan Yaghoobi Address and clarify zero filling mechanism in CM transmitter when
R-S FEC is disabled.
rfi2-n-02137
08/14/02
Hans Wambach Replace Annex F, Euro-DOCSIS; editorial changes and one new
requirement.
rfi2-n-02161
08/21/02
Greg Nakanishi Clarify packet forwarding requirement.
rfi2-n-02145
8/14/02
Greg White
Correct editorial error in Figure 1148. NOTE: This ECN superseded

by rfi2-n-02171.
rfi2-n-02171
08/14/02
Greg White
Clarify CM forwarding rules, particularly for frames that arrive from a

higher-layer embedded application.
rfi2-n-02173
09/18/02
Greg White
Delete requirement to set Guard Time for SCDMA channels.
Andre Lejeune Resolve contradicting definitions of guard time.

Shane Keck
Explicitly state the burst descriptors that must be present in a valid

UCD.
Rusty Cashman Clarify what should happen if Maximum Traffic Burst is less than
Maximum Concatenated Burst.
Elias Nemer
Clarify use of Piggy Back requests during fragmentation and

concatenation.
Rectify inconsistency in CDMA transmit power example in Section

6.2.18.2.
Hassan Yaghoobi Clarify mechanism of RS zero filling in presence of TCM return-tozero bits.
rfi2-n-02178
10/09/02
Victor Hou
rfi2-n-02187
11/06/02
Joe Andonieh
Clarify reaction of DSx Dynamic state machines.
Specify CM timing offsets when making modulation rate changes.
rfi2-n-02200
11/20/02
Matt Schmitt
Apply classifier parameter requirement clarifications.
rfi2-n-02210
11/20/02
Greg White
Make corrections and clarifications.
rfi2-n-02215
11/27/02
Andre Lejeune Correct two figures that contradict the text by requiring backoff on
first transmission.
rfi2-n-02216
11/27/02
Andre Lejeune Allow for the absence of some non-critical options in a DHCP renew
or rebind.
rfi2-n-02217
11/27/02
Dan Crocker
Clarify/change functionality related to the use of Interval Description

Messages.
rfi2-n-02218
11/27/02
Dan Crocker
Specify the maximum latency of Interval Description Message

delivery.
CableLabs
04/22/09
X.3
CM-SP-RFIv2.0-C02-090422

ECN
Date Accepted
Author
Summary
RFI2-N-02226
12/11/02
David Pullen
Clarify that the Service Identifier (SID) TLV must not be included for
downstream service flows.
RFI2-N-02227
03/12/03
Yoav Hebron
Improve recovery time from a temporary loss of downstream signal

in SCDMA mode.
RFI2-N-02238
01/29/03
Efrat Zeharhary RFI2-N-02070 added a confirmation code that is unique to DCCRSP 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.
RFI2-N-02239
02/05/03
Rusty Cashman Clarify behavior of both the CM and CMTS between completion of
registration and completion of BPI initialization
RFI2-N-03016
02/26/03
Lisa Denney
This ECR clarifies the ranging continue operation of DOCSIS2.0

CMs and DOCSIS2.0 CMTSs to allow for PacketCable compatibility.
RFI2-N-03018
03/05/03
Ariel Yagil
Relax timing accuracy requirements after modulation rate change in

S-CDMA mode.
RFI2-N-03050
05/14/03
Lucy Pollak
Correct clarification of the DSx Dynamic state machines reaction
RFI2-N-03063
07/02/03
Greg White
A reference to RFC-3256 was omitted from the description of DCIRSP and the CMTS requirement for DHCP Option 82 support.
RFI2-N-03073
07/02/03
Shane Keck
The CM should not be required to wait for all keying material for all
SIDs/SAIDs to be obtained to forward CPE traffic.
RFI2-N-03075
07/02/03
Lina Nakhle
Correct Clarification of the DSx Dynamic state machines reaction.
RFI2-N-03077
07/02/03
Greg White
Corrections and clarifications
RFI2-N-03078
07/02/03
Greg White
Add requirements for CM recovery from loss of DS sync.
X.4

ECN
Date Accepted
Author
RFI2-N-03085
8/20/03
Greg White
RFI2-N-03093
10/8/03
Minnie Lu
RFI2-N-03100
10/29/03
Ian Wheelock
Insert the correct version of Fig 11-47, DSC Remotely Initiated

Transaction Begin State Flow Diagram.
RFIv2.0-N-03.0110-2
12/3/03
Matt Schmitt
Deterministic QI flag behavior for UGS Service Flows
RFIv2.0-N-03.0111-4
12/3/03
Matt Schmitt
UCD Substitution and same US channel IDs for DCC
RFIv2.0-N-03.0118-1
1/21/04
Yashun Bai
Make SID required for INIT-RNG-REQ match that for RNG-REQ in

the case that the CM is changing upstream channel before
registered
RFIv2.0-N-03.0119-2
1/21/04
Matt Schmitt
IGMP rules must still be supported, even when in 1.0 mode, by

adding a MUST statement to Annex G of the RFIv2.0.
RFIv2.0-N-03.0120-2
1/21/04
Matt Schmitt
Add a SHOULD statement for CMs in Active IGMP mode in order to

minimize potential interruptions in multicast services
RFIv2.0-N-03.0086-7
3/3/04
Matt Schmitt
This ECR introduces a new Config File TLV (Downstream Channel

List) to give the operator some control over CM scanning behavior.
04/22/09
Summary
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".
CableLabs
479
CM-SP-RFIv2.0-C02-090422
ECN
Date Accepted
Author
Summary
RFIv2.0-N-04.0125-5
3/10/04
Greg White
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.
RFIv2.0-N-04.0128-1
3/10/04
X.5
John T. Chapman 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
ECNs included in CM-SP-RFIv2.0-I06-040804

ECN
Date Accepted
Author
RFIv2.0-N-04.0143-4
7/7/04
Matt Schmitt
Static Provisioning of Multicast Traffic on CMs
RFIv2.0-N-04.0147-1
6/16/04
Lucy Pollak
Resolve spec hole issue in DSX state matching
X.6
Summary

ECN
Date Accepted
Author
RFIv2.0-N-04.0167-2
9/15/04
Greg White
Introduces MSC feature to increase power per code in certain

SCDMA scenarios
RFIv2.0-N-04.0177-2
10/13/04
Matt Schmitt
Mandatory CMTS support for Concat, Frag, and PHS
RFIv2.0-N-04.0181-3
11/3/04
Margo Dolas
Clarifications of Downstream Channel List
RFIv2.0-N-04.0191-2
11/11/04
Ben Bekele
Mandatory CMTS support for Service Class Name (SCN)
X.7
Summary

ECN
Date Accepted
Author
RFIv2.0-N-04.0189-5
12/1/04
Igor Stadnik
Modem capability encoding for the number of IP/LLC filters

supported
RFIv2.0-N-04.0200-2
2/9/05
Matt Schmitt
Configurable US/DS Channel IDs
RFIv2.0-N-04.0203-2
1/26/05
Lucy Pollak
Resolve spec issues in MSC feature
RFIv2.0-N-05.0206-2
2/16/05
Arun Prasad
An exception.to resource hold till T15 expiry at new-CMTS for DCC
X.8
Summary

ECN
Date Accepted
Author
RFIv2.0-N-05.0216-2
5/25/05
Rick Mayberry
RFIv2.0-N-05.0220-2
6/8/05
Matt Schmitt
Summary
TLV-37 changes for enhanced CMTS filtering.
Rectify incorrect usage of MPEG terms
RFIv2.0-N-05.0226-2
6/22/05
Alon Bernstein
SID Space Expansion
RFIv2.0-N-05.0227-2
7/14/05
William Kostka
Application of DRFI specification to DOCSIS 2.0 CMTS
RFIv2.0-N-05.0234-4
7/14/05
Roger Fish
RFIv2.0-N-05.0237-2
7/14/05
Margo Dolas
Ranging Hold-off
Clarification to MSC power shortfall
RFIv2.0-N-05.0238-1
8/8/05
Matt Schmitt
Modem capability conflict resolution
RFIv2.0-N-05.0239-1
8/10/05
Matt Schmitt
Editorial corrections for SID space expansion
480
CableLabs
04/22/09
X.9
CM-SP-RFIv2.0-C02-090422

ECN
Date Accepted
RFIv2.0-N-05.0221-4
11/23/05
Michael Patrick Layer 2 Virtual Private Network
RFIv2.0-N-05.0222-3
11/23/05
Michael Patrick Downstream Unencrypted Traffic (DUT) Filtering
RFIv2.0-N-05.0250-3
11/9/05
X.10
Author
Summary
Roger Fish
Clarification of Ranging Hold-Off Requirements

ECN
Date Accepted
Author
Summary
N/A
X.11
This version update corrects an error incurred during the

incorporation of ECN RFIv2.0-N-04.0189-5. The correction is in
Section C.1.3.1.14, LLC Filters Support, of this specification.

ECN
Date Accepted
Author
RFIv2.0-N-07.0513-2
08/22/2007
Volker Leisse
X.12
Alignment of (European) Annex F with main text of RFIv2.0

ECN
Date Accepted
Author
RFIv2.0-N-07.0600-2
01/16/2008
Greg White
X.13
Summary
Summary
Clarification for hybrid devices in RFI2.0
Corrections incorporated in CM-SP-RFIv2.0-C02-090422
Date
Summary of Change
04/22/2009 When converting the FrameMaker version to MS Word for C01, mathmetical symbols were lost, particularly in Annex F.
This unintentionally changed technical requirements. This C02 version corrects them back to their original values, and
also corrects some other lost formatting.
04/22/09
CableLabs
481

Docsis Radio Frecuencia Especificaciones

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Docsis Radio Frecuencia Especificaciones

Uploaded by

Copyright:

Available Formats

Data-Over-Cable Service Interface Specifications

Radio Frequency Interface Specification

Data-Over-Cable Service Interface Specifications

Document Status Sheet

Key to Document Status Codes

A document in specification format considered largely complete, but lacking review by

Radio Frequency Interface Specification

RADIO FREQUENCY INTERFACE SPECIFICATION ..............................................................................1

REFERENCES (NORMATIVE/INFORMATIVE) .........................................................................................5

GLOSSARY (INFORMATIVE) ......................................................................................................................10

FUNCTIONAL ASSUMPTIONS ....................................................................................................................25

COMMUNICATION PROTOCOLS ..............................................................................................................29

PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION .........................................................40

Data-Over-Cable Service Interface Specifications

DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ......................................................102

MEDIA ACCESS CONTROL SPECIFICATION.......................................................................................106

Radio Frequency Interface Specification

MEDIA ACCESS CONTROL PROTOCOL OPERATION.......................................................................180

QUALITY OF SERVICE AND FRAGMENTATION ............................................................................195

Data-Over-Cable Service Interface Specifications

10.1 Theory of Operation ..................................................................................................................................195

CABLE MODEM - CMTS INTERACTION............................................................................................228

11.1 CMTS Initialization ...................................................................................................................................228

Radio Frequency Interface Specification

SUPPORTING FUTURE NEW CABLE MODEM CAPABILITIES....................................................317

Downloading Cable Modem Operating Software .....................................................................................317

PARAMETERS AND CONSTANTS ............................................................................................320

COMMON RADIO FREQUENCY INTERFACE ENCODINGS..............................................322

CM CONFIGURATION INTERFACE SPECIFICATION........................................................374

THE DATA-OVER-CABLE SPANNING TREE PROTOCOL .................................................381

EUROPEAN SPECIFICATION ADDITIONS.............................................................................385

Data-Over-Cable Service Interface Specifications

DOCSIS 2.0 AND 1.0/1.1 INTEROPERABILITY .......................................................................413

THE DOCSIS MAC/PHY INTERFACE (DMPI) ........................................................................419

Radio Frequency Interface Specification

MAC SERVICE DEFINITION..................................................................................................441

EXAMPLE PREAMBLE SEQUENCE.................................................................................450

MULTIPLE UPSTREAM CHANNELS................................................................................452

DOCSIS TRANSMISSION AND CONTENTION RESOLUTION ...................................458

Data-Over-Cable Service Interface Specifications

IGMP EXAMPLE ...................................................................................................................463

UNSOLICITED GRANT SERVICES ...................................................................................465

S-CDMA FRAMING ..............................................................................................................471

Coded Subsymbol Numbering...............................................................................................................471

AMBIENT TEMPERATURE AND WIND LOADING EFFECTS..................................473

ECNs included in SP-RFIv2.0-I02-020617...............................................................................................477

Radio Frequency Interface Specification

ECNs included in SP-RFIv2.0-I05-040407...............................................................................................479

Data-Over-Cable Service Interface Specifications

Radio Frequency Interface Specification

FIGURE 811 CONCATENATION MAC HEADER FORMAT ...........................................................................................118

Data-Over-Cable Service Interface Specifications

FIGURE 113 OBTAINING UPSTREAM PARAMETERS ...................................................................................................234

Radio Frequency Interface Specification

FIGURE 1158 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 1 ............................................................297

Data-Over-Cable Service Interface Specifications

Radio Frequency Interface Specification

TABLE 105 PAYLOAD HEADER SUPPRESSION DEFINITIONS ......................................................................................221

Data-Over-Cable Service Interface Specifications

TABLE VIII1 ALLOWABLE PLANT TIMING DRIFT ......................................................................................................473

Radio Frequency Interface Specification

1 RADIO FREQUENCY INTERFACE SPECIFICATION

Scope and Purpose