The controller area network (CAN) communication protocol, initially developed for the automotive industry as the prime choice of all new automotive applications is becoming increasingly popular technology for the wireless industry. The protocol's error management, fault isolation, and fault tolerance capabilities provide some nice benefits to design engineers building base transceiver station (BTS) and mobile switching center (MSC) equipment for emerging third-generation wireless networks.
In this article, we'll provide an overview of the CAN protocol and its impact on the development of cellular equipment. The article will also examine some changes that will make CAN even more useful in wireless designs.
Opening the CAN
CAN, a serial communication network, was originally designed and developed by Robert Bosch GmbH in the late 1980s for the automotive industry for an in-vehicle networking. CAN is for embedded distributed systems what LAN/WAN is for computing.
CAN is the network for microprocessor based systems. It is an ISO 11898 standard communication protocol, which covers layers 1 (physical) and 2 (data link) of the OSI model. For the physical layer, a twisted pair multi-drop cable is specified with a length ranging from 1000 meters at to bit rate of 40 kbit/s to 40 meters at the bit rate of 1 Mbit/s. It is a half-duplex network system suited for "high-speed" applications using short messages.
The CAN protocol incorporates a data cyclic redundancy check (CRC), message error tracking, and fault node confinements as means to improve network reliability. The network itself is a single differential line continuously monitored by all nodes on the link (Figure 1). A clock signal is not necessary.
Click here for Figure 1
Figure 1: Diagram of the CAN bus network.
The media access control (MAC) layer is based on a carrier sense multiple access with collision detection and resolution (CSMA-CD/CR/CA) scheme. Message arbitration is accomplished 1 bit at the time. As each node transmits a bit, it checks to see if the bus is the same state that it transmitted. If it is, it continues. If not, then another node has transmitted a dominant bit. The first node then knows that it has lost arbitration and stops message transmitting soon after. This makes it similar in some respects to the Ethernet protocol, except that the "CAN-sending-node" does not have to stop message transmission when the network detects a collision.
The messaging principle of the CAN communication protocol is short data messages8 bytes maximum. This principle is transmitted from any node on the bus using a multicast technique (Figure 2). The message is not intended to any specific node; however, each transaction's content is labeled by an identifier, which is unique across the network. This unique identifier also determines the priority of the messages it has labeled.1
Click here for Figure 2
Figure 2: Diagram of the CAN data frame.
The Fault Tolerance Advantage
There is no doubt that the telecom industry's (or any other industry which has decided to use CAN) most poignant reason to use CAN is the protocol's reliable error detection as well as signaling and fault confinement mechanism.
Historically, BTS designs have employed differential bus technologies (RS485, RS422, LVDS, and others). However, the implementation of these buses in a wireless architecture is a questionable choice. Designers have implemented these differential buses in a point-to-point configuration network architecture even though many can be implemented in a multi-drop architecture configuration fashion. Since some of these protocols offer a multi-drop capability, designers may create a design that can cause a whole network of nodes to go down if a fault occurs on a single node. With operators demanding five nines (99.999%) reliability, the potential for multi-drop operation is forcing designers to evaluate other bus options.
Under the CAN approach, embedded nodes remove themselves from the network when an error or fault occurs. By doing this, the CAN network prevents the potential collapsing situation by a single node as described above. Thus, by using the CAN protocol, wireless designers can create an embedded network between all the field replacement cards (PCBs) that can operate even in the light of error conditions. This network can be managed by a controller card (the card playing the role of master) that directly communicates with any card within the BTS via short messages.
The CAN protocol implements five different error types. These are bit, stuff, CRC, acknowledgement, and form errors. Whenever any node on the network detects any of these errors, that node immediately aborts transmission by sending an Error Flag, 6 consecutives dominant bit, at the next bit time.
To facilitate fault confinement, CAN also implements two types of error counters; transmit error counter (TEC) and receive error counter (REC). When an error occurs, the sending node increment its TEC by 8 while the receiving node increment their REC by 1. When the TEC reaches above 255, the node goes on the "Bus Off" state. The weighing factor is clearly higher for the transmit node because it is desired that the node sending bad messages on the network be the one removed. A bus-off node is not allowed to have any influence on the bus (e.g., output drivers switched off). This feature of the CAN protocol has made it attractive for cellular infrastructure designers to whom the fear to use a multi-drop network thing of the past.
In addition, different PHY layer implementations of CAN exist where the network is made to work in certain fault condition such as bus short to ground, bus short the Vcc, as well as CAN differential lines short to each other. One should note that this has been possible mostly for low speed (125 kbit/s) network implementation.
Implementing CANs in BTS/MSC Design
The CAN bus speed is function of the length of the network's backbone (the distance between the two farthest nodes). A bus speed of 1 Mbit/s will typically be achieved for a CAN bus length of 30 meters (used in most telecom applications). The automotive industry uses different slower speeds; mostly 125 kbit/s (500 meter of bus length), 250 kbit/s (250 meters of bus length), and 500 kbit/s (100 meter of bus length) for serve programming.
Many designers will argue that the CAN bus speed is not fast enough to handle the critical information processing tasks required in MSC and BTS designs. These tasks include call setup and processing (BTS / Subscriber Unit), visitor location registry, services switching point (SSP) interfaces, as well as interface to the PSTN (MSC).
In reality, a CAN network clearly offers the ability to handle the information required in a wireless equipment designs. Through CAN, all the PCBs of the MSC node or the BTS can be used (and is used in certain cases) to transfer important information to the controller card from any other card. The controller card is also able to obtain information about any card from any card within the system. Since the cards are connected in a network fashion, the controller card can immediately register a new card when it is hot-swapped in to replace an old or malfunctioning card; hot-swapped PCB has a means to register with the site controller as soon as they are connected.
To support high-availability, the CAN protocol also provides a way for cards to exchange information such as alarms, advanced presence detection (the card is not only present, but it is functional), card proprietary EPROM/Flash data (software versions, PCB number, last PCB reset causes, etc) and any other non-call processing message.
An alarm signals a specific defect with specific cards. All the alarm information can be funneled to a card on the BTS, which plays the role of on-board diagnostic card. This can be a selling feature to the cellular operators. The CAN protocol also facilitates the programming of cards with new software releases, as well as the means to load new calibration data into the system.
Upper Layer Protocols Needed
To build a CAN network, designers must also implement some higher-layer protocols. CAN (2-layer) is implemented with higher layer protocols. Several higher layer protocols already exist, including J1939 (Truck), CANopen, DSS, DeviceNet, and others. Each of these higher layer protocols, however, is an industry specific network solution. Thus, they are developed using the defined requirements for the physical layer, address structure, data structure, and application/network interface for that industry.2
To date, an upper-layer protocol has not been developed for implementing CANs in wireless and other telecommunication networks. That leaves designers with several options. The first is to develop a proprietary CAN network interface based on your own distributed product strategy. While time consuming, when done right,
Designers can also look to tap into existing protocols in the market. Parts of these protocols can be reused for the types of message exchanges seen between the cards of a BTS or and MSC.
The final approach is to turn to BOSCH for help. Up to this point, BOSCH has only focused its efforts on making CAN a viable solution for a few sectors, in particular automotive.
However, through some tweaks, BOSCH can also make the CAN protocol an easier solution for the telecom sector to implement. These include:
- CAN chip operating voltage of VCC= 3.3 V and VCC= 1.8 V (reduces the need for an additional 5-V power supply as 3.3 V has become the supply voltage for most micro-controller and digital signal processors).
- Increase CAN bit timing for speeds beyond 1 Mbit/s.
- Single IC solution to include CAN transceiver and controller (for even shorter distance between the farthest nodes on the network).
- Strong ESD protection may not be necessary since many telecom systems communicate via a backplane.
The issue is will BOSCH make the tweaks. So far, BOSCH has leaned away from adapting CAN for a telecom implementation. Thus, designers looking to implement CAN technology in wireless designers are forced to develop their own upper-layer protocol or adapt an existing protocol on the market.
1. CAN Protocolhttp://www.algonet.se/~staffann/developer/can2spec.pdf.
About the Author
Hamed Sanogo is a senior staff engineer in Motorola's Cellular Infrastructure Group. He holds a BSEE from the University of Alabama, Birmingham; an MSEE from the University of Michigan; and an MBA from the University of Dallas. Hamed can be reached at firstname.lastname@example.org.