DOCSIS QoS – Quality of Service

DOCSIS 1.0 enabled data over coax with a “best effort” service using a data request-grant methodology.  DOCSIS 1.1 and subsequent specifications added guaranteed DOCSIS QoS – Quality of Service by providing Unsolicited Grant Synchronization (UGS) which means that a cable modem does not have to send a data request in order to receive a bandwidth grant from the CMTS.  The new UGS service is an enabling technology which has allowed cable operators to successfully deploy the highly revenue generating Voice-over-IP (VoIP) services. In the following sections I will illustrate the differences between best-effort (request-grant) and QoS (UGS) services.

By default, when a cable modem registers with a CMTS, it is almost always configured to operate in a best effort data service.  Even during registration the cable modem must use best effort to communicate with the DHCP and TFTP servers in order to complete its registration processes.  Best effort means that every time a cable modem has data in its buffer to transmit, it must send a bandwidth Request Frame (hereon referred to as REQ per the DOCSIS specification) to the CMTS.  The REQ will contain the number of mini-slots required to transmit the modem’s data.  The CMTS will process all incoming REQs and send out an Upstream Bandwidth Allocation Map (MAP) message.  The MAP messages tell each cable modem when they can transmit their data as well as when there are available contention time slots to transmit more REQ messages.

The following is an example REQ message:

IUC = 1 (Request)
Number bytes = 6
Upstream MAC type = Request
MAC FC (HEX) = C4
MAC PARM (HEX) = 46
MAC SID (HEX) = 0065
MAC HCS (HEX) = EF51

PDU bytes = 0

The first thing you will notice about the REQ frame is that it is very small.  This is important because cable modems transmit many REQ frames since their primary purpose is to transmit a lot of user data.  Every mouse click means that another REQ frame will be transmitted before the actual mouse click data is transmitted.  To help reduce overhead, the cable modem only needs to transmit its MAC SID (Service IDentifier) instead of its MAC address and cable modem IP address.  The CMTS does a reverse lookup of the SID against the MAC address.  This is an overhead savings of 3:1 (6 bytes for the MAC address vs. 2 bytes for the SID).  The REQ must specify the amount of data to be transmitted, in this case 6 bytes.

NOTE:  The DOCSIS spec defines the REQ to define the amount of data in mini-slots, but the protocol analyzer used for this example translates the number of mini-slots into bytes for a more user-friendly interface.

There is a MAC Header Check Sequence (HCS) that performes a bases CRC to ensure the REQ does not have any errors upon reception at the CMTS, but that is really all there is to a REQ.  It is a very simple message.

Upstream Bandwidth Allocation Map (MAP) messages (strictly called MAPs from here on out) are much more complicated on the other hand.  MAP messages are transmitted by the CMTS every 2 msec, contain much more information than a REQ and therefore utilize a measureable percentage of the downstream DOCSIS channel which is able to transmit subscriber data – this is called MAC overhead, since it is associated with the DOCSIS MAC layer.

The following is an example response to the above REQ from SID 0065:

Downstream MAC type = MAP
MAC FC (HEX) = C2
MAC PARM/EHDR length (HEX) = 00
MAC LEN (HEX) = 0034
MAC HCS (HEX) = D689
PDU bytes = 52
PDU DA (HEX) = 01E02F000001
PDU SA (HEX) = 00015C227A05
PDU Type/Len (HEX)= 0022
MMH Version (HEX)= 01

MMH Type (HEX)= 03

MMM Type: MAP
Upstream Channel ID (HEX): 0B
UCD Count: 5
Number of elements: 3
Alloc Start Time (HEX): 005B8974 (Time stamp (HEX) 2DC4BA00)
Ack Time (HEX): 005B87EA
Ranging Backoff Start: 2
Ranging Backoff End: 7
Data Backoff Start: 2
Data Backoff End: 8
SID (HEX): 0065, IUC: 6, Offset 0
SID (HEX): 3FFF, IUC: 1, Offset 70

SID (HEX): 0000, IUC: 7, Offset 192

The MAP message starts off with a MAC Management Message Header defined in the DOCSIS specification.  This contains such information as a MAC HCS (Header Check Sum) to verify that all data received is correct and not potentially corrupted during transmission.  The PDU DA and PDU SA.  The DA is once again the commonly known Broadcast MAC address as defined in Annex A and the SA is the MAC address of the physical RF port of the CMTS.  Once again, always remember to read the Annexes of the DOCSIS specification for this type of critical information.

Next, the MAP message must contain the Upstream Channel ID (0B) or channel 11.  The channel ID is needed because the MAP is a broadcast message to all modems listening on the downstream.  In this example, only modems on channel 0B (channel 11) will actively listen to this MAP while ignoring MAPs for all other upstream channels.

The UCD Count is in important field if any changes are made to the CMTS either statically or dynamically which impact the characteristics of the upstream.  When this happens, the UCD has a field that it increments indicating that a change to the UCD has occurred.  In synchronization with this comes the UCD Count change in the MAP message.  Effectively, DOCSIS states that the CMTS must not transmit a MAP message before the the new UCD goes out without incrementing the UCD Count in the new MAP messages.  This requires 1 msec precession and updates in the CMTS MAC processor.  The objective is to ensure that all cable modems are made aware of the new changes, such as a new upstream frequency or symbol rate and do not accidentally transmit user information on the old frequency or symbol rate.

The Number of Elements tells the cable modems exactly how many SIDs are going to be addressed in the MAP, in this case there are three (3).  The Alloc Start Time in mini-slots is the effective start time from the CMTS initialization.  This provides the base counter to all cable modems from which they will calculate the proceeding offsets in order to transmit their data.  Essentially, the timing is relative to the CMTS’s counter.

I have previously stated that there are multiple contention windows provided in the DOCSIS specification for both Initial Ranging and REQs.  The Ack Time, Ranging Backoff Start, Ranging Backoff End, Data Backoff Start, and Data Backoff End and included in MAP messages in order to provide for Ethernet-like collision detection and contention back-off.  This means that packets will collide with each other during times of high network traffic (even during low traffic given random probability).  The CMTS and modem interaction will detect this and an algorithm will engage to cause the modems to back-off in a randomized fashion which will reduce the likely-hood for future collisions.

Finally come the MAP Information Elements (IEs).  These follow a SID, IUC, OFFSET format.  The SID is the Service IDentifier of the cable modem, eMTA or other DOCSIS-based device.  The IUC is the particular burst descriptor that the MAP grant is providing a timeslot or timeslots.    The offset is the time till the modem can transmit and must stop by the next SIDs offset.  So in this case, SID = 0065 can transmit its 6 bytes of data using IUC = 6 starting immediately (Offset: 0).  You may also notice a SID = 0000 at the end of the MAP message.  This is a NULL SID and uses a NULL IUC = 7.  This tells the cable modems that the end of the MAP has been reached and no further IEs will follow.

So how does DOCSIS improve on this rather slow REQ-MAP-send data process?  There are a number of ways which were introduced in DOCSIS 1.1.  When there is a lot of data to be sent, a REQ can be piggy-backed onto the data packet being transmitted by the cable modem.  This way there is a constant stream of REQs being sent by the cable modem with each packet being transmitted.  This is quite simply called “Piggyback Requests”.  A cable modem can also “concatenate” many packets of data together to form one large packet of data, for example a 12 Mbyte long packet of data, and send it all at once.  This is called concatenation.  Of course a CMTS may need to fragment a long packet of concatenated data in order to allow another modem’s priority data to go through, which is call fragmentation and it does so via the MAP message.  So we now have two new types of service, “concatenation” and “fragmentation”.  Perhaps the most widely used and effective method of achieving reliable QoS in the upstream is “Unsolicited Grant Synchronization” or UGS.  This occurs when the CMTS establishes a reserved rate of upstream data between a cable modem and itself.  The CMTS will then automatically send out the MAP messages to the cable modem on whatever interval is needed for the cable modem to transmit its data.  This is used most prevalently for Voice-over-IP (VoIP) communications.  For a VoIP call, packets are typically transmitted at a rate of 50 packets per second (pps) from the cable modem and they do not tolerate very much jitter without causing call impairments.  So this is a case where UGS is a perfect solution for this application because the packet size and rate of transmission is known in advance.

DOCSIS also allows for service flows to be established which assigns numbers, i.e. 1, 2, 3, … 7 in order to set the level of priority for a given traffic type.  This is often used to differentiate the priority of service between someone checking their email and someone dialing the digits on their phone to make a voice call.  While service flows do help to some extent in ensuring that one type of traffic is prioritized over another, it is not treated with the same level of committment that a UGS flow is treated.  The word of caution here is that if a CMTS is over-utilized there is no garuntee for service flows, it is fair game for all traffic.

Also see our other tutorials on DOCSIS

Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.

  • If you are watching this on youtube please hit the subscribe button!
  • Let us know what you think and remember to share!  
  • You can find slides at the bottom of the page and some on slideshare.  
  • Find out about events or articles by following us on TwitterLinkedIn or Facebook too.

Also available on iTunes, Google Podcasts, Spotifyvurbl see podcasts “get your tech on”.

Spotify  Vurbl