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 Twitter, LinkedIn or Facebook too.
Also available on iTunes, Google Podcasts, Spotify, vurbl see podcasts “get your tech on”.
“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. ”
Would you caveat this with the implementation of Service Flow Admission Control as a way to proportion a percentage of b/w dedicated to specific traffic types (voice) during times of high utilization?
Okinawajoe,
You are absolutely correct. Some cable operators will dedicate a small amount of dedicated static service flows (say 10 kbps) for each eMTA. While this is a bit of extra overhead that cannot be used for anything else, it will always ensure that VoIP subscribers will always have a QoS for dialing phone numbers and setting up calls with the Call Management Server (CMS).
Regards,
-Brady
Hello Brady,
First of all thank you for the amazing website!!
How CMTS changed the Service Flow ID or add a new SFID?
The CMTS create a new configuration file with a new SFID and use the message “Dynamic Service Change” ?
Thanks
Alon
Hi Alon,
The CMTS assigns the cable modem a SID during registration. The configuration file may contain addition static service flows as desired by the cable operator. For example one North American MSO assigns a small 10 kbps service flow per cable modem to ensure that digits dialed on eMTAs for phone calls get a quality of service (QoS). But in most cases additional service flows are assigned dynamically through DSC and DSA messages as you suggested. This is often handled by PacketCable to help ensure an added level of security and integration with other devices. The SFIDs are then torn down at the end of the needed activity, say a phone call, so that the SFID and bandwidth can be used later when needed.
-Brady
Belated Happy New Year Brady! I read the QoS article for DOCSIS and Cable Modems and have an unlearned question for ya. As a first line help desk type we often experience many scenarios where our customers question the upload and download speeds they are getting with us.
Say we are provisioning a certain service offering for 2.0 megs download and 1.0 megs upload. A customer using that offering is on one of our outer islands, say somewhere in the Abacos. They want to see if they are getting what they are paying for; so off they go to a site like Speakeasy (speakeasy.net) and chose the Atlanta test server. and test their “speeds”.
We provision them here in The Bahamas for 2down/1up; what keeps that provisioning in force so that on a distant connection that throughput could be reasonably determined (our Abaco customer would actually see the 2/1 speeds on a server in Atlanta)? I was under the impression that what we would provision our subs would be more relevant in our domain.
By the way work continues on our upgrade to 3.0!!!
Hi Keith,
Always good to hear from you and a Happy New Year to you as well.
You are experiencing a very common symptom that many cable operators see. You provision a speed on your DOCSIS network and your subscriber tests those speeds against a server located somewhere out of your control. There are a couple of things to keep in mind and then one recommendation I will make.
1) When you provision your speeds, say 1MB up and 2MB down, keep in mind that those speeds include the IP and DOCSIS overhead which can be as much as 12% depending upon your CMTS configuration and if you have BPI turned on. So it is recommended that you do an internal speed test and then adjust the actual up and down speeds accordingly (say 2.2MB down and 1.1MB up as an example) to ensure actual usable speed are obtained.
2) You will need to educate your subscriber that when they do a speed test to the Atlanta server they are not only testing the speed of the DOCSIS network, but also the speed of the backbone connection from the Bahamas to the States and then to the IP host that is hosting the server. There is no QoS to the server in Atlanta and congestion can skew the speed test results This is when it is very beneficial to have a piece of test equipment that can perform a DOCSIS-only speed test such as those made by JDSU, VeEX and Sunrise Telecom to show results to the subscriber.
Finally, as my suggestion, you can host your own speed test server locally. Companies sell these or you can even build one on a Linux platform and then advertise the test service to your customers who complain about the “Speakeasy” or “Speedtest.net” throughput. If you do this, you are likely better off with a professional looking service such as so your customers feel their test is valid. This will demonstrate you are offering the service provided at least to your local backbone.
-Brady
Hello Brady,
great, informative website!
Since this was the only page which somewhat touches on UGS channels, and since I have a question on these channels, I’m posing it here :o).
The 3.0 spec has a sentence that’s been bugging me: “””UGS does not allow for the fragmenting of packets””” (see IV.3).
This actually makes sense from a logical point of view: UGS(-AD) is tailored/invented for CBR applications, such as VoIP. If you fragment such data, you’ll introduce non-acceptable jitter.
However, I’d really like to find some confirmation in the spec that fragmentation really is not allowed on UGS-channels. Can you help out? Where is this explicitly stated? Do note that the R/T Policy field has the “DO NOT fragment” flag, yet I can set this flag to ‘0’ on our CMTS for UGS channels, without even getting a warning. The CM happily obliges, and fragments the packets on the UGS channel.
Hoping to hear from you soon,
Jimbo.
Hi Jimbo,
You are correct in your assumption that UGS does not get fragmented. I don’t recall anywhere in the standards where “do not fragment” is specified, but not every corner case is always covered – that is not the intention. UGS is provided so that grants are automatically provided for a service flow such as VoIP without the modem being required to make a REQuest. In this case, fraqmentation and concatenation are not applicable in the UGS profile as all flows are managed by the CMTS for that IUC. Fragmentation is required for short and long data grants so that larger data packets can be broken up to ensure the UGS flow can go through the network with as little jitter / delay interruption as possible. The fact that you can configure fragmentation in the service flow you are configuring is because it is an allowable parameter, but not one that will be implemented for UGS directly.
I suspect you already were heading down this trail, but were just looking for some confirmation.
-Brady
Hi Brady
How Can I set the Strict Priority Queue paramter in cable modem configure file? In addition, Can I use UGS for video stream service ?
Regards,
Liang
Hi Liangzhou,
You can set the priority QoS in the config file, but it depends on the config file editor. There is a free one from Excentis (search my blog and you’ll find a link). You can also use UGS for the video stream service if all packet sizes will be the same (assuming its UDP and CBR traffic). However this is always fairly complicated to setup. You will need to have a constant destination port and IP, say of your video content server.
This is rather involved project and much more than I can include in a comment.
Good luck.
-Brady
Firsta of all, thanks a lot for such an excellent information! My question is:
I haven an IP camera connected to a cable-modem (DOCSIS 2.0). The camera sends video data to a static IP and port (server that store the video). Initially, with the US channel configured with 3.2 Mhz wide and QPSK the quality was awful, lot of delay and freezes. It’s important to note that the US channel it was not congested.
Later, I configured the US channel in 6.4 MHz QPSK and now the quality was great (the IP camera is limited to 2 Mbps bitrate), almost no delay and no freezes.
Later, because we need more US speed (because the number of users has increased), I change the channel to 6.4 MHz 16QAM and everything works great. I even tested configure the IP camera on 4Mbps and it works fine too.
In this scenario it seem that I have nothing to do (the camera works fine), but I have been tried time ago to configure a cable modem with UGS service flow but I did not succeed. Tell me please if I’m wrong, but in this case I first need to configure at least one service flow with best effort and then one with UGS and their respective classifier (based on destination IP and port). Is this ok? Do you recommend UGS in this case? Is best to configure a best effort SF with max priority and reserved CBR insted of use UGS?
Thanks a lot in advance and again, thanks for such an excellent information on DOCSIS related.
Mauro.
Hi Mauro,
Using UGS (Unsolicited Grant Service) for a video camera is possible, but may not be the ideal scenario. USG was intended for voice and video communications where real-time delivery of UDP traffic was essential with minimal delay and jitter. Your scenario is a bit different if I understand it correctly. You are using an IP camera likely for video surveillance and not two-way communication. In this case I would recommend setting up a static flow in the modem’s config file just for this camera’s IP source and destination along with its port. This will be way easier than trying to dynamically bring up a USG flow, which requires PacketCable. Static flows are fairly simple to implement. And as you have stated you do need the best effort flow first for standard traffic and then a second flow for the IP camera.
-Brady
Hello Brady,
Greetings!
I’d like to understand a specific behavior in DOCSIS networks.
I have a 40 Mbps Max Sus Rate configured for my primary US SF. Now, if a dynamic service flow for voice comes up with 150kbps Max Sus Rate, would the CMTS ensure that the Cable Modem overall gets 40 Mbps Upstream or would it be 40 Mbps + 150kbps(VoIP)? If the latter is true(I believe that this is true), how do I ensure that only 40 Mbps cap is given to US for the DOCSIS 3.0 Cable Modem such that any service flow that comes up uses up from the cap?
Thanks
Hi Prabha,
Each flow has its own setting, so the UGS is guaranteed in the scheduler and does not “eat” into your BE flow of 40 Mbps. Voip is a drop in the bucket compared to 40 Mbps! Also check out https://volpefirm.com/intx-the-internet-television-expo-review/
Does dns requests from endpoints are tagged with any priority in cm..so that the request are not dropped in between at any case.thanks a lot in advance
Hi Natarajan,
The cable modem is a layer 2 device (OSI Model) and does not inspect any user traffic. Therefore, it does not know DNS traffic from from email. So no, there is no priority given to it and has no idea what DNS traffic is.