It is All about Traffic, and Programming
0 visitors online now
0 guests, 0 members


Adaptive Signal Control for Diamond Interchanges

A new adaptive signal control deployment for a total of 15 intersections at freeway diamond interchanges go live yesterday Oct 10, 2014, in Staten Island of New York.

Diamond interchange is characterized by two closely spaced intersections, with left turns on the common approach connecting the two intersections. The common approach generally is a short block fed by movements from various phases.

Traffic signal control at diamond interchange can be viewed as a special type of over-saturated control with unique geometric features. The primary goal is to facilitate vehicle movements, while preventing queuing back to other approaches and ensuring pedestrian safety. Generally small cycles are preferred over long cycles.

Conventionally, adaptive traffic signal control primarily targets progression optimization or delay minimization in unsaturated conditions, with its insufficiency dealing with over-saturated traffic.

This system is powered by the ACDSS adaptive control technology developed by KLD, integrated with TransCore TransSuite TCS.  Thanks to its unique design of the so-called Signal Optimization Repository,  ACDSS is capable of  addressing the real time signal optimization for diamond Interchanges, urban CBD grid, arterials, and cluster of intersections.  It can be either running as cycle-based, or second-by-second (cycle-free).

The same system has been deployed controlling more 300 intersections in Manhattan of New York City, and being installed in other states including California as well.

Dissecting NTCIP 1202/SNMP Message – Part 1

The National Transportation Communication for ITS Protocol (NTCIP) is a family of standards for electronic traffic control equipment.  For traffic engineers, or professionals that have to deal with traffic signal control,  NTCIP 1202 is of particular relevance as it defines the data elements and conformance requirements for actuated traffic signal controllers (ASC).

NTCIP 1202 specification document and accompanied MIBs can be downloaded from

Looking at NTCIP 1202 spec,  various objects are defined in the document in a descriptive, high-level language.  However, in order to do actual NTCIP 1202 related programming and implementation either as a application developer or system architect/designer, or some other signal control hardware-related work,  a *detailed* binary-level understanding of SNMP message is in order. 

This article serves as a personal study note on some of the key points for understanding NTCIP 1202 SNMP messages.  I have had some sort of solid years of experience in computer engineering (hardware and software), and have been working in Traffic Engineering/ITS industry for a couple of years. So I guess this post would be most helpful for someone that has a similar background , while wishing to grab a jump start to some low-level programming and development work dealing with 1202/SNMP messages.

Also I would like to thank Mr. Kenneth Vaughn (an NTCIP expert, of Trevilon Corporation) from LinkedIn NTCIP group, for some of his clarifications and explanations that had helped me a lot while I educated myself on this subject.

To start with,  let’s check out the big picture  about NTCIP framework, which is best exemplified in Figure 1. As shown in this Figure,  the framework has several levels, from the bottom physical levels up to  the topmost information level.  From top most level to the bottom level,  lower level will always add some wrappers (headers) to the higher level information.  We are only interested to levels up to Application Level, which, in the context of this post, is NTCIP 1202 SNMP message.

(Figure 1: NTCIP Framework. source:

(Figure 2: Fields in SNMP Message.  Source:

(Figure 3: A sample SNMP Message.  Source:

An  SNMP message contains a sequence of raw binary bytes, formalized in a well-defined structure (which contains several fields), as exemplified in the above Figure 2.   Figure 3 shows an actual sample of SNMP message:

1. A message starts with 0x30, indicating this is a “Sequence” type message

2.For encoding OID, the node is encoded using the 7 low-order bits of each byte. The high-order bit indicates whether there are more bytes to follow within the node number.

For example, 0x89 0x36, => 1000 1001 (high bit set, look for another byte) 0011 0110 (high bit not set, this is end). Removing high order bits, we get 000 1001 011 0110.
Putting back into two bytes 0000 0100 1011 0110, which is 0x04 0xB6 = 1206 decimal
(thanks to Kenneth Vaughn for explaining and clarifying these to me)

3. The second byte, if the highest bit is not set, i.e., 0, then the byte itself would indicate the Length (number of bytes) that follows in this message. If the highest bit is set as 1, then the low 7 bits indicate the number of bytes that follows which specify the Length of the message.

The length field is encoded as a BER length. The maximal value for this encoding is a length field that starts with the value 0xFE (0xFF is reserved) so the maximal length would be defined by a 126 byte integer, or 2^1008 – 1. (thanks to Kenneth Vaughn for explaining and clarifying these to me).

For example, 0x2C means a total of 44 bytes will follow (the entire length of the whole message, would be 44 + 2 = 46 bytes considering the first 2 bytes 0x30 0x2C)

0x82 0x01 0xB0 would indicate the length is expressed in 2 subsequent bytes, since with 0x82 the highest bit is set as 1. And that gives 0x01B0 = 432 bytes, and therefore the total number of this SNMP message would be 432 + 4 = 435 bytes.

4. Then we have the part on SNMP Version, following the format Type, Length, Value

For example, 0x02 0x01 0x00 means, Integer Type, of 1 byte, value is 0, i.e., SNMP version 1.

5. The following lists the common ASN.1 data types, relevant to SNMP:

Primitive Types


Complex Types






Octet String


GetRequest PDU




GetResponse PDU


Object ID


SetRequest PDU