IMPLEMENTATION OF INITIAL RANGING & TRANSFER OPERATIONAL
PARAMETERS PHASES OF A CABLE MODEM
Aakash Patel
B.E., U.V. Patel College of Engineering, India, 2007
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
SPRING
2012
IMPLEMENTATION OF INITIAL RANGING & TRANSFER OPERATIONAL
PARAMETERS PHASES OF A CABLE MODEM
A Project
by
Aakash Patel
Approved by:
__________________________________, Committee Chair
Chung-E Wang, Ph.D.
__________________________________, Second Reader
Du Zhang, Ph.D.
____________________________
Date
ii
Student: Aakash Patel
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit is to
be awarded for the Project.
__________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D.
Department of Computer Science
iii
________________
Date
Abstract
of
IMPLEMENTATION OF INITIAL RANGING & TRANSFER OPERATIONAL
PARAMETERS PHASES OF A CABLE MODEM
by
Aakash Patel
This project bestows an analysis of the lifecycle of a cable modem (CM). In order to
provide services to a customer, the CM goes through an initialization sequence consisted
of several stages. Among these several stages, Initial Ranging, IP Connectivity, Transfer
Operational Parameters & Registration with the Cable Modem Termination System
(CMTS) are main four stages. In the Initial Ranging phase, the CM acquires the
downstream and upstream channels. Acquisitions of these channels are important as they
provide a unique communication link between the CM and the CMTS. While in IP
connectivity phase, the CM acquires the IP address from the CMTS, which will give the
CM a unique identity among all other network elements. In the Transfer Operational
Parameters phase, the CM will obtain configuration file from the CMTS, which will
inform the about the services it has to provide to customer. In addition, in Registration
phase, the CM registers with the CMTS. After completion of this initialization sequence,
the CM comes online and it will be capable to provide voice, video and data services to
the customer. The main objective of this project is to demonstrate the two transition
phases pursued by a CM and these two phases are Initial Ranging and Transfer
Operational Parameters. The purpose behind this project is to implement state machine
iv
transition performed by the CM in order to achieve project goal. To achieve the goal a
dummy process has been created which will act as “cable modem termination system”
and which will be able to provide appropriate responses to the CM’s requests. Similarly,
a virtual modem will be created on the other end of the network, which will be able to
communicate with the dummy process. Moreover, in order to confirm and analyze the
output or to maintain and view the responses received from the “cable modem
termination system”, the CM logs the messages in a log file.
The CM uses Data Over Cable Services Interface Specification (DOCSIS) protocol to
transmit and receive packets from the CMTS head-end facility. DOCSIS 3.0 specification
provided by Cable Labs has been a great source of knowledge and has been followed as a
main guideline.
_______________________, Committee Chair
Chung-E Wang, Ph.D.
_______________________
Date
v
ACKNOWLEDGMENTS
I would like to express gratitude to my project advisor Dr. Chung-E Wang for his
direction and support to complete this project. Without the support of Dr. Wang, it would
have been utterly impossible for me to complete this project. I am thankful to Dr. Du
Zhang, my second reader, for his assistance and valuable inputs while drafting the project
report and advice in the form of his positive feedback.
I would like to thank Mr. Neel Jadia (Sac State Alumni) for his immense help and very
valuable inputs at every stage of this project.
vi
TABLE OF CONTENTS
Page
Acknowledgments....................................................................................................... vi
List of Figures ............................................................................................................. ix
Chapter
1. INTRODUCTION ……………. ………………………………………………… 1
1.1 Project Motivation ...................................................................................... 1
1.2 Project Background .................................................................................... 2
1.3 Goals ........................................................................................................... 2
1.4 Report Organization .................................................................................... 4
2. MODEM INITIALIZATION PROCESS .............................................................. 5
2.1 Scanning Downstream & Upstream Channels ............................................ 6
2.2 Ranging & Timing/Power Offset ............................................................... 8
2.3 Establish IP Connectivity............................................................................ 9
2.4 Establish Time of Day .............................................................................. 11
2.5 Transfer Operational Parameters .............................................................. 11
2.6 Register with the CMTS ........................................................................... 13
3. BACKGROUND AND LITERATURE REVIEW .............................................. 15
3.1 DOCSIS v3.0 ............................................................................................ 15
3.1.1 What is DOCSIS v3.0? .....................................................................15
3.1.2 DOCSIS System & Network Architecture ......................................16
3.1.3 Key Features .....................................................................................17
3.2 Trivial File Transfer Protocol (TFTP) ..................................................... 18
3.2.1 Overview of TFTP ........................................................................... 19
3.2.2 Workflow of TFTP Protocol ............................................................ 20
4. TECHNICAL OVERVIEW.................................................................................. 23
4.1 Architecture & Overview of Simulator..................................................... 23
vii
4.1.1 Architecture of the CMS ...................................................................24
4.1.2 CMS Threads ....................................................................................25
4.1.3 CMS Signal Handler .........................................................................26
4.1.4 CMS Libraries ...................................................................................26
4.2 Technical & Implementation Details of Initial Ranging............................27
4.2.1 Scan for Downstream Channel .........................................................27
4.2.2 Service Group Discovery & Initial Ranging .....................................28
4.2.3 Obtain Upstream Channel .................................................................31
4.2.4 Authentication ...................................................................................32
4.2.5 Implementation of Initial Ranging Phase in Project .........................32
4.3 Technical & Implementation Details of Transfer Operational Parameters35
4.3.1 Details of Transfer Operational Parameters Phase ...........................35
4.3.2 Implementation in Project ................................................................37
4.4 Conclusion ................................................................................................39
5. CONCLUSION AND FUTURE DEVELOPMENT .............................................41
References ....................................................................................................................42
viii
LIST OF FIGURES
Page
1.
Figure 2.1 Process Sequence Overview of Scanning DS & US Channels...…...…7
2.
Figure 2.2 Process Sequence Overview of Ranging & Timing/Power Offset …. .8
3.
Figure 2.3 Process Sequence Overview of Establishing IP Connectivity ………10
4.
Figure 2.4 Process Sequence Overview of Transfer Operational Parameters …..12
5.
Figure 2.5 Process Sequence Overview of Register with the CMTS ...……...….13
6.
Figure 3.1 DOCSIS v3.0 Network……………….…………………..…………..16
7.
Figure 3.2 Workflow of the TFTP [10]…………....……………………...……..21
8.
Figure 4.1 Architecture of the CMS [9]...………………………………………..24
9.
Figure 4.2 Resolve Cable Modem Service Group [4]……………………………29
ix
1
Chapter 1
INTRODUCTION
1.1 Project Motivation
While studying at California State University, Sacramento I attended a few classes,
related to the Computer Networks. During those classes, I gained knowledge about Cable
Modem (CM) & Data-Over Cable Service Interface Specification (DOCSIS). In addition,
while attending the Graduate Symposium I learned more about the Cable Modems as one
of the students had presented the project related to the Cable Modem. The CM is a
device, which has become more or less essential in our day-to-day life. It is a device,
which enables us to use data, voice and video services over a network of cables. A CM
uses and follows the DOCSIS protocol in order to communicate with the Cable Modem
Termination System (CMTS), which resides at the service provider’s facility. Using the
DOCSIS protocol, the CM can provide high bandwidth services in comparison to the
traditional CMs.
Therefore, the importance of a cable modem in our day-to-day life and my own interest in
understanding the different elements of the computer networks motivated me to pursue
this project as my Master’s Project.
2
1.2 Project Background
The intention behind this project is to understand and illustrate the life cycle of a CM
before it comes online and becomes ready to transmit the data, voice and the video for
and from the user. My focus is not to understand the whole initialization cycle rather my
focus is to understand and implement the Initial Ranging and the Transfer Operational
Parameters phases of the CM initialization sequence. To simplify understanding, let us
assume that a CM has been powered on and now in order to become operative; it has to
communicate with the CMTS to acquire necessary information and resources to bring the
CM to the online state.
The reason behind the availability of data, voice and video services over network is the
DOCSIS Mulpi v3.0. That is why the DOCSIS Mulpi v3.0 specification & a student
project “Establishing IPv6 Connectivity for a Cable Modem” by Neel Jadia are the main
resources and guide for this project.
1.3 Goals
The goal of this project is to understand details of the Initial Ranging phase, Transfer
Operational Parameters phase, to generate logs of communication between a CM and the
CMTS (a dummy process in the project) and to register the CM with the CMTS server
and bring the CM online. A dummy process will work as the CMTS, which will be able
3
to provide resources to the requesting modem and on the other side of the network a
Cable Modem Simulator will act as a modem and will create the request messages in the
process of initialization sequence. The CM uses and supports various network protocols
during its initialization life cycle. However, this project will illustrate and use the
DOCSIS v3.0 and the TFTP protocols.
In the Initial Ranging Phase, a CM performs below listed operations:

Scanning and synchronization to downstream

Service group determination and ranging

Scanning and synchronization to upstream

Authentication
While in the Transfer Operational Parameters phase, the CM must obtain a configuration
file using the Trivial File Transfer Protocol (TFTP). This file contains the data on which a
CM decides whether the CM should send a registration request or not to the CMTS.
The CM must reject a configuration file with the characteristics listed below:

Lacks one or more mandatory items, which are explained in the later chapters.

Has one or more Type/Length/Value (TLV) – 11 encodings that cannot be
processed and cause rejection of the file.
Moreover, in the Registration phase, if the CM has received the correct configuration file
than the CM must register with the CMTS by sending the registration request to the
4
CMTS. If the CMTS receives the proper request than, it replies back to the CM and
register the CM.
1.4 Report Organization
Chapter 2 provides an insight in the initialization process of the CM. This chapter will
look into the CM initialization process from a high level. Chapter 3 presents literature
and background overview of the DOCSIS v3.0 specifications and the TFTP protocol.
This chapter does not provide detail specification of the DOCSIS v3.0 rather it provides
an overview of the DOCSIS architecture and its key features, which is necessary to
understand the importance of the DOCSIS. This chapter also includes the general
workflow of the Transfer Operational Parameters (TFTP) in order to understand the
TFTP’s role and the communication process between the CM and the CMTS. Chapter 4
is all about technical overview. We understand the overall architecture of the simulator
system, details of the initial ranging and the transfer operational parameters phase and we
will have a look at these stages’ implementation details. Chapter 5 concludes the project
details and gives the direction for further research and development.
5
Chapter 2
MODEM INITIALIZATION PROCESS
This chapter provides theoretical background of all the phases of the Cable Modem
(CM). In general, this section focuses more on the general understanding of a CM’s
initialization sequence. Once powered on, the CM goes through several stages listed and
then explained below.

Scanning Downstream Channels

Scanning Upstream Channels

Adjusting Timing Offset and Power Level

Establishing IP Connectivity

Establishing Time of Day

Transfer Operational Parameters

Register with the CMTS
In order to become online, a CM communicates with a Cable Modem Termination
System (CMTS), a dummy process in the project, which resides at the service provider’s
head end facility. The CM establishes a link between the CMTS and itself via co-axial
cable or fiber optics, however in the project the role of the CM has been replaced with the
Cable Modem Simulation (CMS) system due to unavailability of the resources. Upon
successful completion of these phases, a CM will be able to provide voice, data and video
services to the customer. Following detailed description will explain all the operational
6
phases of the DOCSIS v3.0. These phases are the pre requisite for the CMs that provide
or support the DOCSIS services.
2.1 Scanning Downstream & Upstream Channels
When the CM is powered on, the very first step it takes is to scan the network for
appropriate downstream and upstream channel. A downstream channel is a unidirectional
link from the CMTS to a CM. The CMTS always uses this downstream channel in order
to communicate with a CM. In order to obtain a downstream channel the CM scans all
the downstream channels available and provided by the CMTS. To select the downstream
channel a CM has specific requirements of QAM signal timing, downstream media
access control (MAC) messages and forward error correction. The CM terminates the
scanning for the downstream channel once it receives the proper downstream channel and
then starts scanning for an upstream channel. The CM requires an upstream channel in
order to create a communication link from a CM to the CMTS. With the help of this
upstream channel, the CM will be able to send any requests to the CMTS during its
initialization sequence. All the downstream channels have the upstream parameters,
which helps a CM in deciding proper an upstream channel according to its downstream
channel. If the received upstream parameters from the downstream channel are not
appropriate then the CM starts rescanning for a valid downstream channel again. Without
acquiring proper downstream and upstream channel, the CM cannot proceed to the next
stage.
7
CMTS
CABLE MODEM
Next Freq.
Sync Broadcast
Scan DS Freq.
YES
NO
NO
Wait for Sync
YES
UCD Broadcast
Wait for UCD
MAP Broadcast
Wait for MAP
NO
Figure 2.1 Process Sequence Overview of Scanning DS & US Channels
Above figure will give the actual idea of the process of scanning downstream and
upstream channels. Initially the CMTS continuously sends SYNC frame over the
network, which has the timestamp based on a clock in the CMTS. After receiving this
frame, the CM adjusts its clock to account for latency in the network. Then the CM starts
the scanning for the downstream frequency. Until the CM receives the proper
downstream, it checks from the entire pool of downstream channels. Once the CM locks
onto the appropriate downstream channel it will terminate the scanning for the
downstream channel and moves to the next step in the process. After achieving the
downstream channel, the CMTS broadcasts the Upstream Channel Descriptor (UCD)
message, which will let the CM on the downstream channel know how to use the
associated upstream channel. The UCD includes information such as Upstream
8
Frequency, Upstream Channel ID, Downstream ID, Mini-slot size. After confirming the
downstream and the upstream channels, the CMTS broadcasts a MAP message, which
defines the transmit opportunity of each CM in upstream channel. This tells the amount
of time each CM is allowed to use the upstream channel during its initialization sequence.
2.2 Ranging & Timing/Power Offset
This stage is executed after successfully completing the stages described above. We can
call this stage an important stage because the CM has to receive certain parameters before
it can initiate the communication with CMTS.
CMTS
RNG-RSP
Ranging Response contains
 Timing Offset
 Power Offset
Cable Modem(CM)
RNG-REQ
Initial Ranging Request
Wait for RNG-RSP
YES
Adjust Timing Offset & Power Offset
Figure 2.2 Process Sequence Overview of Ranging & Timing/Power Offset
In this phase, the CM generates a ranging request for the CMTS requesting timing offset
and power offset. The CM waits until it receives ranging response from the CMTS. The
CMTS’s ranging response contains timing and power offset parameters. Once it receives
9
the ranging response, the CM adjusts its timing and power offset. The CM requires
timing parameter to keep sync with the CMTS while the power offset is required to
maintain the minimum required strength to sustain the upstream channels.
After completing this stage, the CM goes into the next stage and establishes the IP
connectivity. We can assume that “Scanning Downstream & Upstream channels” and
“Ranging & Timing/Power Offset” stages are prerequisite for the IP Connectivity phase.
2.3 Establish IP Connectivity
“Establishing IP Connectivity” stage is followed by the “Scanning Downstream &
Upstream Channel” & “Ranging & Timing/Power Offset” stages. This stage is quite
significant in the life cycle of a CM. In this stage, a CM tries to acquire the network
connection information and an IP address. In this stage, a CM communicates with a
DHCP server, a TFTP server and a Time of Day (TOD) server, which are connected to
the CMTS head end facility. To understand this process let us consider the figure given
on the next page.
10
CMTS
Cable Modem(CM)
DHCP Discover
DHCP Reply
DHCP offers an IP
DHCP Request
ACKS Initial IP & requests
Default GW, ToD Server, TOD
offset, TFTP server addr.,TFTP
Boot Config File Name
DHCP ACK (Response)
Contains IP plus additional
information
ToD Request
ToD Response
Contains Time of Day
Figure 2.3 Process Sequence Overview of Establishing IP Connectivity
From this figure, in simple words, we can conclude that in this phase a CM broadcasts a
request for the DHCP server, which is called “DHCP Discover”. This CM request is
forwarded to a DHCP server by the CMTS. In response to this, the DHCP server returns
the available IP addresses to the CMTS who then forwards it to the CM.
A CM can accept IPv4 or IPv6 address from the DHCP server in order to establish the IP
connectivity. There are four different ways to acquire the IP address.

IPv4 only provisioning mode: Supporting only IPv4 protocol and requesting an
IPv4 address.
11

IPv6 only provisioning mode: Supporting only IPv6 protocol and requesting an
IPv6 address.

Alternate provisioning mode: Supports either IPv4 protocol or IPv6 protocol at
one point of time.

Dual stack mode: Supports both IPv4 address and IPv6 address at the same time.
2.4 Establish Time of Day
This is the stage where a CM requests the time of day from the CMTS. This stage is
required to the CM to adjust to the system time. With the help of this time, a CM logs an
event with the time stamp. This is the only stage whose failure does not affect the life
cycle of a CM. In a situation of a failure, the CM generates an alert message and then
moves to the next stage.
2.5 Transfer Operational Parameters
After the time of day stage, the CM goes to the transfer operational parameters stage
where it requests for the configuration file to the CMTS. However, this file usually
resides on the TFTP server but in this project, the CMTS works as a mediator, who
forwards the CM’s request for the configuration file to the TFTP server.
The
configuration file contains the parameters, which determines the services that a CM will
12
be able to provide to the user. Below is the list of few parameters, which are generally
found in the configuration file.

Upstream and downstream rate limits.

Specific operating frequencies for a CM.

Number of Customer Premises Equipment (CPE) devices allowed at the customer
site behind a CM.

IP filters.

Port filters.

MAC / LLC filters.

Vendor-specific settings.

Software version installed.
CMTS
CM (Cable Modem)
TFTP Boot File Transfer
TFTP Boot Request
Validate File & Implement Config
Figure 2.4 Process Sequence Overview of Transfer Operational Parameters
After receiving the configuration file, the CM validates the received file. In addition, if
the CM finds the received file and the parameters in order than it will use the received
13
parameters to set up the services for the user. On successful completion of this stage, CM
moves to the registration phase of the life cycle.
2.6 Register with the CMTS
This is the last phase of the CM’s life cycle where CM seeks registration with the CMTS
in order to start communication and provide services to the user.
CMTS
CM (Cable Modem)
Registration Request
Registration Response
Registration Acknowledge
Figure 2.5 Process Sequence Overview of Register with the CMTS
In this stage, a CM sends the registration request to the CMTS, which has QoS
parameters, to begin this phase. In response, the CMTS sends out the response, which
informs the CM that it has been registered and will be allowed to forward the network
traffic from the user. To complete this process after receiving response from the CMTS,
the CM forwards the acknowledge message to the CMTS.
14
When a CM registers with a CMTS, it will have the following parameters, which will
enable it to transfer the network traffic.

CM locks onto CMTS downstream signal.

CM receives the transmission parameters.

CM will have IP configuration provided by DHCP

Time of day assigned.

DOCSIS configuration info downloaded into CM.
15
Chapter 3
BACKGROUND AND LITERATURE REVIEW
This chapter provides the basic background of the Data Over Cable Services Interface
Specification (DOCSIS) v3.0 and the Trivial File Transfer Protocol (TFTP). These two
protocols are the important part of this project so it is necessary and helpful to have the
basic understanding of them.
3.1 DOCSIS v3.0
3.1.1 What is DOCSIS v3.0?
Today requirement of high-speed data services over the cable networks is very high. To
meet this demand, CableLabs and member companies have developed the Data Over
Cable Service Interface Specification (DOCSIS) which allows the addition of high speed
data transfer to an existing network. This specification is defining the interface for the
MAC and the Upper Layer Protocols. In general, DOCSIS specification provides 1)
Increased channel capacity, 2) enhanced network security, 3) extended addressability of
network elements and 4) deploying new server offerings.
16
3.1.2 DOCSIS Network and System Architecture
Below figure shows all the elements that participate in creating the basic architecture,
which enables the DOCSIS services:
Figure 3.1 DOCSIS v3.0 Network
The Cable Modem (CM) and the Cable Modem Termination System (CMTS) are the
main elements of the DOCSIS architecture. The CM connects to the customer and the
CMTS via means of the HFC network. We can consider a CM as a bridge between the
user and the CMTS, which allows network traffic. While CMTS is an element, which is
connected to the Provisioning Systems and the NMS on one side and on the other side it
17
is connected to the CM through the HFC network. The main function of the CMTS is to
forward requests of the CM to the NMS and the Provisioning Systems.
The Provisioning systems and the NMS include:

Provisioning Systems:
o The DHCP server, which provides a CM with initial configuration
information.
o The TFTP server is used to provide configuration files to a CM when they
boot. This configuration file contains parameters, which will enable a CM
to provide services to the customer.
o The time protocol server provides current time of the day to the a CM.

Network Management System (NMS):
o The syslog server collects messages pertaining to the operations of
devices.
o The SNMP Manager allows the operator to configure and monitor the
SNMP agents. In our case, the SNMP agents are a CM and a CMTS.
3.1.3 Key Features
DOCSIS v3.0 introduces number of key features [4] for the MAC and the Upper Layer
Protocols Interface.

Downstream Channel Bonding with Multiple Receive Channels: Downstream
channel bonding refers to the ability at the MAC layer to schedule packets for a
18
single service flow across multiple channels. This provides a single CM with the
significant high downstream data rate.

Upstream Channel Bonding with Multiple Transmitted Channels: Upstream
channel bonding refers to the ability to schedule the traffic for a single upstream
service flow across those multiple channels. This provides higher upstream data
rate.

IPv6: DOCSIS v3.0 introduces built-in support for the IPv6. The CMs can be
provisioned with the IPv4, IPv6 or both.

Multicast QoS: DOCSIS v3.0 defines a standard mechanism for configuring the
Quality of Service for IP multicast sessions. This introduces the concept of
“Group Service Flow” for multicast traffic that defines the QoS parameters for the
service flow.
3.2 Trivial File Transfer Protocol (TFTP)
The Trivial File Transfer Protocol is a file transfer protocol, which is used for automated
transfer of the configuration and the boot files between the customer and the provisioning
systems. In this project, this protocol’s significance is notable as it provides a CM with a
configuration file through which the CM will recognize the services to be provided to the
customer. In this project, the TFTP will provide two different files to the CM, which are
explained below.
19
1) DOCSIS Configuration File
After a CM has acquired the IP address and attempted to contact the ToD server,
the CM uses a TFTP server through the CMTS to download a DOCSIS
configuration file from the authorized TFTP server. The DHCP server is
responsible for providing the name of the DOCSIS configuration file and the IP
address of the TFTP server.
2) Software Upgrade File
If the DOCSIS configuration file specifies that the CM must be running a specific
version of the software, and the CM is already not running that version than the
CM must download the required version from it or another TFTP server.
3.2.1 Overview of TFTP
The TFTP is a protocol, which has been developed and implemented on top of the User
Datagram Protocol using port number 69. Basic role of the TFTP is to read and write files
from/to a remote server.
In the TFTP, to begin transfer, host needs to send a request to read or write a file, which
also serves to request a connection to the server. If the server grants the request, the
connection is established and the file is sent in fixed length blocks of 512 bytes. After
sending the blocks of data host waits for the acknowledge message. If the host receives
the acknowledge message before the time out, it sends the next block. To terminate the
20
connection, the host must send a block of data whose size should be less than 512 bytes.
In the TFTP, one simple mechanism is implemented to manage the erroneous situations.
If a packet gets lost in the network, the receiver will face the time-out and will have to
last message, thus causing the sender of the lost packet to retransmit the lost packet.
The TFTP uses the UDP to serve the purpose of a transport protocol. However, it is not a
requirement to use UDP always. In general, TFTP uses port 69 for the data transfer.
3.2.2 Workflow of TFTP Protocol
To understand the workflow of the TFTP, let us know about the messages TFTP uses to
communicate with a client. The TFTP uses five types of messages to communicate with
the host. Those five messages are shown and explained briefly below.

RRQ: Read Request
The client to establish a connection for reading data from the server uses this
message.

WRQ: Write Request
The client to establish a connection for writing data to the server uses this
message.

DATA:
The client or the server to send the blocks of data uses the data message.

ACK: Acknowledge
21
The acknowledge message is used by the client or the server to acknowledge the
receipt of the data.

ERROR:
The client or the server when a connection cannot be established or when there is
a problem in data transmission uses this message.
The client and server for the successful data transmission use these five messages.
Let us take an example to understand the workflow of TFTP.
Figure 3.2 Workflow of the TFTP [10]
In this example, a client starts the process of reading a file by sending a request for it to
the server (RRQ message in above figure). The server acknowledges the request by
22
immediately sending a DATA message carrying 512 bytes of data. The client
acknowledges this with the ACK message for received block. The TFTP client and the
server repeat the same steps to transmit more data. But as shown in the figure DATA
Block # 3 has only 176 bytes of data while client should have 512 bytes of data. But this
means that it is the last block of the data and now the client is allowed to terminate the
connection to the TFTP server.
In this project, the TFTP protocol has been used in a similar way to receive the
configuration file for the CM. The next chapter will provide detailed explanation of
TFTP’s role in transmitting configuration file to the CM.
23
Chapter 4
TECHNICAL OVERVIEW
This chapter will provide complete technical overview of the project. It will shade light
over the framework of cable modem simulator (CMS) system, technical &
implementation details of initial ranging and transfer operational parameters phases.
Topics covered in this chapter are:

Architecture & Overview of simulator

Technical details and implementation of Initial Ranging phase

Technical details and implementation of Transfer Operational Parameters phase
The focus of this project is to implement the Initial Ranging and Transfer operational
parameters phases. Thus, it has been assumed that the stages between these stages are
successfully performed.
4.1 Architecture & Overview of Simulator
This section will provide a high level view of the CMS system. Formally, the CMS is a
Linux based application who is responsible to act as a CM and which will generate all the
necessary requests for resources on behalf of the CM. The CMS will send all its requests
to the CMTS, which in this project is a dummy process.
24
This project is the extension of a previous project completed by Neel Jadia and this part
of the project thoroughly follows the guidelines and architecture provided by the project
report “Establishing IPv6 Connectivity For A Cable Modem”[9].
4.1.1 Architecture of the CMS
State
Machine
Event Queue
Event Queue
event
State Machine
Library
Figure 4.1 Architecture of the CMS [9]
Queue Library
List Library
Timer Library
Lock Library
event
DOCSIS Library
event
IP Library
Msg Library
Debug Library
Sockets
UDP
File I/O
Logging Details
Dummy Head-end
Process
State
Machine
25
CMS is a process, which is built with multiple threads who share the set of common
libraries. From the figure, we can divide the CMS in below listed blocks:

Threads

Signal Handler

Generic Libraries
In the subsection of this section all the building blocks are explained briefly and for the
detailed and thorough explanation please refer the Section 4.2 of [9].
4.1.2 CMS Threads
CMS contains a few POSIX thread for parallel execution of CMS actions. Some of the
threads are created dynamically while some of the threads perform the basic CMS
operations. When the state machine is installed in the CMS, a new thread will be created
who is responsible for executing the events from the event queue (state machine table in
the project). Below is the list of threads:

Message TX Thread: Responsible for transmitting simulation messages to a
dummy process.

Message RX Thread: Responsible for receiving simulation messages from the
dummy process.

State Machine Thread: Contains all the available and necessary state events to
perform the modem initialization process.
26
4.1.3 CMS Signal Handler
The signal handlers are used to notify a CMS thread about particular event such as timer
expiration. In this project, only one signal handler is used whose role is to signal the CMS
on the expiration of timer.
4.1.4 CMS Libraries
The majority of the code in CMS lives in the generic libraries. Below is the list of a few
important libraries, which are part of the CMS.

Message Library: Routine required for sending and receiving messages from the
dummy process.

Init Ranging Library: This library is responsible for providing the routines to
create all possible ranging messages.

TFTP Library: This library is responsible for providing the routines to create all
TFTP request messages.

State Machine Library: This library is responsible for providing a mechanism to
execute various state machine methods.
27
4.2 Technical & Implementation Details of Initial Ranging
In the Initial Ranging phase, a CM goes through certain number of steps to acquire the
downstream and the upstream channels. These are steps are as below:

Scan for Downstream Channel

Service Group Discovery

Obtain Upstream Parameters

Authentication
4.2.1 Scan for Downstream Channel
On initial power-on, the CM must set its initialization reason to POWER_ON. On
initialization, the CM must obtain the downstream channel. Unless redirected otherwise,
the CM seeks for the last operational parameters as those parameters may still be
available for the CM and by using previously used parameters, the CM can quickly
obtain the downstream channel. If this fails, the CM must continuously scan the channels
of entire downstream frequency band until it finds a valid downstream channel.
A downstream channel is considered valid for the CM when the modem has achieved the
synchronization of the Physical Media Dependent and Transmission Convergence sub
layer as defined in PHY layer of DOCSIS and on CM’s recognition of SYNC
downstream MAC message [4].
28
Once a candidate primary downstream channel has been identified, the CM should
remember where it left off in the scanning process so that it may continue where it left
off. In case a CM determines that the currently available channels are unsuitable, the CM
must resume scanning downstream spectrum for suitable downstream channel.
4.2.2 Service Group Discovery and Initial Ranging
In the second step of the Initial Ranging phase, the CM must determine its service group
of downstream and upstream channels in order to achieve initial ranging.
The initial ranging phase and its sub phase are described in details in section 10.2.3 of
[4]. Let us look at the high-level design of Service Group Discovery and Initial Ranging.
29
Resolve CM-SG & Range Begin
Read MDD
MDD NOT
Collected
MDD Collected
Set D3.0 Initialization
Set D2.0 Initialization
Determine MD-DS-SG
Obtain Upstream
Parameters
MD-DS-SG
Complete
Upstream
Parameters
Obtained
Determine MD-US-SG
MD-US-SG
Complete
Broadcast Initial
Ranging
Unicast Initial Ranging
Ranging & Auto
Adj. Complete
CM-SG Resolution
COmplete
End
Figure 4.2 Resolve Cable Modem Service Group [4]
30
The CMTS must determine the service group of a DOCSIS 3.0 CM for channel bonding
and load balancing. In order to acquire service group, the CM should be able identify its
MAC Domain Downstream Service Group ID (MD-DS-SG-ID). In general, MD-DS-SG
may contain the set of downstream channels, each of which has a unique upstream
channel. If the CM is successful in determining the MD-DS-SG-ID then it should forward
the Bonded Initial Ranging Request to the CMTS. However, if the CM is unable to
determine the MD-DS-SG-ID then it should send Bonded Initial Ranging Request with
the MD-DS-SG-ID set to ZERO (0), which would let the CMTS know that the CM was
unable to acquire the MD-DS-SG-ID. After acquisition of MD-DS-SD-ID the CMTS
replies with the Ranging Response (RNG-RSP). Now in order to resolve the upstream
channel service group, the CMTS may include upstream channel adjustment in the RNGRSP. This will let the CM know of its upstream channel. Once the CM obtains the
upstream and downstream channels it will move to the next state and will try to establish
the IP Connectivity and then register with the CMTS.
However, in a scenario where the CM is unable to obtain MDD, it will not abort the
initial ranging phase rather it would switch to the older version of the DOCSIS and it will
try to obtain the downstream and upstream channel parameters and will attempt to
continue to the next coming stages.
31
General Information of MAC Domain Descriptor (MDD)
A DOCSIS 3.0 compliant CMTS transmit MDD message on all the downstream channels
of a DOCSIS 3.0 MAC Domain periodically. This MDD contains the following
information:

Information for each MD-DS-SG-ID

Channel parameters for each downstream channel in MAC Domain.

List of Active Upstream Channel

Upstream Frequency Range

Downstream Ambiguity Resolution Frequency List containing a list of
downstream frequencies
4.2.3 Obtain Upstream Channel
After determining the MD-DS-SG and MD-US-SG, the CM must wait for an upstream
channel descriptor from the CMTS in order to obtain a possible upstream parameter.
These upstream channel descriptor messages are transmitted periodically by the CMTS
which are addressed to CM MAC multicast address. The CM must determine whether it
can use any of the upstream channels from the received upstream parameters. If the
channel is suitable from the received upstream channel descriptor then CM must extract
the parameters for this upstream channel. However, in case the received parameters are
not suitable to CM then it must find suitable and appropriate upstream parameters.
32
4.2.4 Authentication
When the CM acquires the appropriate downstream and upstream channel, the CM goes
for authentication before it continues further initialization. Authenticating the CM
provides confidentiality between the CM and the CMTS and prevents unauthorized CMs
from accessing the IP provisioning servers.
4.2.5 Implementation of Initial Ranging Phase in Project
In the project, Initial Ranging phase is dived in the five different events. After passing
through these five stages successfully, we will be able to achieve initial ranging.
Five states:
1) INIT_RNG_START_EVENT
In plain words, this event is called “Modem Initial Ranging Initialization Action
State”.
This event is a very first step towards initial ranging stage. In this event, the value
of ranging retry, ranging response timeout and ranging response timer will be
set/initialized. In simple words, we tell the CM that how many retries it has to
complete this stage, how much time it should wait in order to receive response
from CMTS. In any case, if this event fails then modem goes into the reset state
and starts the initial ranging phase again.
33
2) INIT_RNG_SEND_REQ_EVENT
This event is called “Send Initial Ranging Request Message from CM”.
In this event, we send the Initial Ranging request to the CMTS in order to receive
the valid downstream and upstream channels. If we are powering on the CM for
the very first time then we set the downstream channel id and upstream channel id
to ZERO (0) so the CMTS can know that modem is being initialized for the first
time and it does not have any records of previously used downstream or upstream
channel ids. After setting the downstream and upstream channel ids, we need to
transmit a DOCSIS message to the CMTS so CMTS can recognize the CM’s
request and provide appropriate response. This message mainly contains the
downstream, upstream channel ids and modem system id so CMTS can
understand which modem has made the request. Here also we use the timer to
receive the response from the CMTS. If the timer is expired then CM will start the
ranging process again from the first step and will transmit the other request
message.
3) INIT_RNG_RESPONSE_EVENT
This event is called “Processing the Initial Ranging Response”.
In this event, CM processes the response received by the CMTS and updates the
different headers. Ideally, this response contains the downstream and upstream
channel ids, system id, message type and length. The CM will process this data to
complete Initial Ranging. Upon successfully receiving all the data it will move on
34
to complete the Initial Ranging but if it doesn’t receive the proper data then it will
go for the aborting the initial ranging and will go into the reset state where it will
start the initial ranging again.
4) INIT_RNG_COMPLETE_EVENT
This is event is executed upon successful processing of initial ranging response
and is called “Complete the Initial Ranging”.
Here the CM simply goes into the next state which DHCPv4 state in order to
acquire the IP address.
5) INIT_RNG_ABORT_EVENT
This event is called “Initial Ranging Abort Action”.
The CM goes into this event if CM is unable to execute any of the above
explained event. The role of this event is to put the CM on the RESET state where
it will start the initial ranging state again.
35
4.3 Technical and Implementation Details of Transfer Operational Parameters
4.3.1 Details of Transfer Operational Parameters Phase
After acquiring the IP address and Time of Day, the CM must download a configuration
file using the TFTP. The CM learns about the TFTP server from the DHCP server, which
was used in obtaining the IP address.
In order to receive the operational parameters, the CM looks for the address of the TFTP
server in the TFTP Server Address option, and the fname field of the DHCPOFFER and
the DHCPACK message. This server address will tell the CM where the TFTP server is
located and from where it can download the appropriate configuration file. This
configuration file will provide all the operational parameters to the CM and will
configure the CM according to customer’s service requirements. In order to get the
configuration file, the CM sends a TFTP read request for configuration file to the TFTP
server. This request will establish a connection between the CM and the TFTP server. If
the CM cannot download a valid configuration file from the TFTP server, either because
of the connection fail to the TFTP server or an invalid configuration file then CM must
retry to connect to the TFTP server and download the suitable configuration file from the
server. However, before reattempting the download, the CM must wait for certain amount
of time.
36
After receiving the configuration file, the CM must validate the configuration file, and
must reject the configuration file in case of invalid configuration file. A valid
configuration file must have these characteristics:

Downstream Frequency Configuration Setting

Upstream Channel ID Configuration Setting

Baseline Privacy Configuration Setting

Software Upgrade Filename Configuration Setting

Upstream Packet Classification Setting

Downstream Packet Classification Setting

SNMP Write-Access Control

SNMP MIB Object

Software Server IP Address

CPE Ethernet MAC Address

Maximum Number of CPEs

Maximum Number of Classifiers

Privacy Enable Configuration Setting

Payload Header Suppression

TFTP Server Timestamp

TFTP Server Provisioned Modem Address

Enable 2.0 Mode

Enable Test Modes
37

Static Multicast MAC Address
4.3.2 Implementation in Project
The Transfer Operational Parameters phase has been divided in six different events. After
executing these seven events, the CM will be able to obtain configuration specifications
and these specifications will allow the CM to provide certain services. All the seven
events have been described below.
1) TFTP_START_EVENT
This event is called “Modem’s Initialization Action for TFTP”.
In this event, the CMS will provide the information of TFTP and will check for
the current state of the CMS. The reason behind this check is to evaluate the
current state. After this check, if CM is entering this event from another state then
retry counter for this state will initialized to zero.
2) TFTP_SEND_REQ_EVENT
This event is called “Send TFTP Request Message”.
In this event, the CMS will generate a request message for CMTS. This message
will have requests for TFTP server address, TFTP server’s communication port
and request for the configuration file. This request message will also contain the
CM’s address & CM’s communication port, which will tell TFTP server who has
made the request and where to send the requested information.
38
3) TFTP_SEND_ACK_EVENT
Simple term for this event is “Send TFTP Acknowledge Message”.
This event’s implementation is quite significant for this phase as the CM will
receive the important information in order to communicate with the TFTP server.
In this event, the CMTS will send the TFTP server’s address and its
communication port address. After receiving this information from the CMTS,
CM will then try to gain the configuration file from the TFTP server. If the CM is
successful in downloading the file from the TFTP server then it will release that
information for other states so they can configure modem according to received
information. We can assume that this is event almost concludes this phase.
However before the CM goes for the ending this phase it still has to process the
response in order to provide user with certain services.
4) TFTP_RESPONSE_EVENT
This event is called “Process the Received Response”.
This is event is very simple as it only checks the received message and process
the received data. This event will inform the CM about the available service for
the particular modem.
5) TFTP_COMPLETE_EVENT
This event is called “Complete the TFTP event”.
39
This event marks the TFTP phase’s success, which will let the CMTS know that
the CM has received all the required data, and is ready for another event.
6) TFTP_ABORT_EVENT
This event is called “TFTP phase’s Abort Action”.
This is the phase where the CM will let the CMTS know that it has concluded the
transfer operational parameters phase is not ready to go to another state. This
event is also used in case of failures and the CM has exhausted all of its retry
attempts. When called, this event will terminate the transfer operational
parameters phase and will start from the very begging of this phase and will
attempt to acquire new information from the CMTS.
4.4 Conclusion
After obtaining enough information from previous sections of this chapter, we can
assume that once completing initial ranging and transfer operational parameters phase,
the CM will now be able to move to the next and final phase of its life cycle. This final
phase is called Registration Phase where the CM will register itself with the CMTS. To
register, it will provide the CMTS all the information it has obtained while performing
the above-explained phases. Of course, this project does not include and implement all
the phases of the CM’s life cycle; we will assume that they have also been successfully
completed. After performing all the phases of the CM’s life cycle, the CM will be able to
40
go online, will be able to transmit all the network traffic, and will be able to provide
DOCSIS services.
41
Chapter 5
CONCLUSION AND FUTURE DEVELOPMENT
This project and combined with the project report represents the two main important
phases of the CM’s initialization life cycle. While researching and implementing this
project, Data-Over-Cable Specification by CableLabs has been followed as the main
guide. As this project is an enhancement of the project completed by a fellow student, the
implementation of this project follows the guidelines provided by the previous project.
After completion of this project, future development of the CM’s initialization life cycle
includes other phases such as Adjusting Timing/Power Offset, Time of Day, Registration
phase and applications built on top of it.
My journey of learning through this project has been outstanding as this project allowed
me to learn some of the aspects of computer networks and professional coding which can
only be gained by the experience. I also became aware of the fact that how the service
providers are able to provide users with the faster and enhancing network every time.
42
REFERENCES
[1]
Cisco Systems. DPC2203 and EPC 2203 VoIP Cable Modem Installation and
Operation Guide. 2008.
http://www.cisco.or.at/en/US/docs/video/at_home/Cable_Modems/2200_Series/4
011044_A.pdf
[2]
Simon Amor. Introduction to network functions in C. September 2008.
http://shoe.bocks.com/net/#intro
[3]
Douglas E. Comer, David L. Stevens. Internetworking with TCP/IP Volume III:
Client Server Programming and Applications. Prentice Hall, 1996.
[4]
Cable Television Laboratories, Data-Over-Cable Service Interface Specification
DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification. July 2010.
http://www/cablelabs.com/specifications/CM-SP-MULPIv3.0-14-101008.pdf
[5]
DOCSIS Pocket Expert
http://www.sunrisetelecom.com/support/DOCSIS_Pocket_Expert.pdf
[6]
DOCSIS Overview
http://www.ieee802.org/3/efm/public/jul01/presentations/gummalla_1_0701.pdf
[7]
IP Over DOCSIS
http://www.scte-rockymountain.org/Documents/Seminars/SCTE%20%20IP%20over%20docsis.pdf
[8]
DOCSIS Cable Modem Connection Process
http://www.cascaderange.org/presentations/
43
[9]
Establishing IPv6 Connectivity For A Cable Modem
http://csus-dspace.calstate.edu/xmlui/bitstream/handle/10211.9/887/
Neel_Report_Grad_Submit.pdf?sequence=1
[10]
TCP/IP Guide
http://www.tcpipguide.com/free/diagrams/tftpread.png