NUST-SEECS & NEXTEK Services

SEECS- NEXTEK Services Joint Internship Program Summer-2011

Muhammad Faizan Khan

Ali Hussain

August 25, 2011

NUST-SEECS & NEXTEK Services

ACKNOWLEDGMENTS First and foremost, we would like to express our sincere gratitude to our advisor Mam Saba Zia for the continuous support of design and development of our internship Project, for her patience, motivation, enthusiasm, and immense knowledge. We are thankful to NEXTEK services for the provision of industrial project and guidance. Lastly, we offer our regards and blessings to all of those who supported us in any respect during the completion of the project.

NUST-SEECS & NEXTEK Services

Contents
ACKNOWLEDGMENTS ............................................................................................................................ 2 ABSTRACT.................................................................................................................................................. 5 CHAPTER 1 ................................................................................................................................................. 6 Introduction to Communication Protocols: ............................................................................................... 6 Basic requirements of protocols:............................................................................................................... 7 Protocol design.......................................................................................................................................... 8 The OSI Model ....................................................................................................................................... 8 OSI Stack Protocol Model; ................................................................................................................... 9 CHAPTER 2 ............................................................................................................................................... 10 HDLC Protocol: ...................................................................................................................................... 10 Types of HDLC Stations:........................................................................................................................ 10 Primary................................................................................................................................................ 10 Secondary............................................................................................................................................ 10 Combined ............................................................................................................................................ 11 Configurations of HDLC: ....................................................................................................................... 11 Unbalanced Configuration .................................................................................................................. 11 Balanced Configuration ...................................................................................................................... 11 Symmetrical Configuration ................................................................................................................. 12 HDLC Operation Modes; ........................................................................................................................ 12 1. 2. 3. Normal Response Mode (NRM) ................................................................................................. 12 Asynchronous Response Mode (ARM) ...................................................................................... 12 Asynchronous Balanced Mode (ABM) ....................................................................................... 12

HDLC Non-Operational Modes;............................................................................................................. 12 Protocol Structure - HDLC: High Level Data Link Control ................................................................... 13 Frame Format .......................................................................................................................................... 13 The Flag field ...................................................................................................................................... 13 Address field ....................................................................................................................................... 13

NUST-SEECS & NEXTEK Services

Control field : ...................................................................................................................................... 14 Information field .............................................................................................................................. 14 FCS .................................................................................................................................................. 14 Categories of Frames; ............................................................................................................................. 14 1. Unnumbered frames .................................................................................................................... 15

Unnumbered Format Commands and responses (U-Frame ................................................................ 15 2. 3. Information frames ...................................................................................................................... 16 Supervisory frames ..................................................................................................................... 16

The Poll/Final Bit (P/F) ...................................................................................................................... 17 CHAPTER 3 ............................................................................................................................................... 18 Protocol Operation .................................................................................................................................. 18 Link management................................................................................................................................ 18 Data transfer ........................................................................................................................................ 18 Transparency ........................................................................................................................................... 19 Bit stuffing and removal ..................................................................................................................... 19 FSM of Transparency: ........................................................................................................................ 20 Hardware Implementation: ..................................................................................................................... 20 Detailed Design:.................................................................................................................................. 20 Requirements: ..................................................................................................................................... 21 Framing: .............................................................................................................................................. 21 Design: ................................................................................................................................................ 22 De-Framing: ........................................................................................................................................ 23 Modem Sharing Device: ......................................................................................................................... 23 Modem: ................................................................................................................................................... 24 Data Reception: ....................................................................................................................................... 27 Chapter 4: .................................................................................................................................................... 28 Reception: ............................................................................................................................................... 28

NUST-SEECS & NEXTEK Services

ABSTRACT In the current era networking has played an important role in bringing scientific revolution to mankind. The whole Computer networks are based on reference model. The data link layer is responsible for link management and frame transmission. This project briefly explains the higher level data link layer protocol and its operation as well as its implementation. Chapter 1 is related to basics of communication protocols. The detailed description is given in the second chapter where all the terminologies have been discussed. Types of stations used in HDLC are can be of three types which are generally detected with the help of frames. There are different types of frames as well and they affect the operation of protocol. Chapter 3 gives detailed design of protocol implementation and operation. This includes hardware details and requirements such as modem and modem sharing device. In the last chapter Verilog code is given for data reception at the monitoring end.

NUST-SEECS & NEXTEK Services

CHAPTER 1 Introduction to Communication Protocols: A communications protocol is a formal description of digital message formats and the rules for exchanging those messages in or between computing systems and in telecommunications. Protocols may include signaling, authentication and error detection and correction capabilities. A protocol defines the syntax, semantics, and synchronization of communication, and the specified behavior is typically independent of how it is to be implemented. A protocol can therefore be implemented as hardware or software or both. In computer science the word algorithm is a synonym for the word procedure so a protocol is to communications what an algorithm is to mathematics. Communicating systems use well-defined formats for exchanging messages. Each message has an exact meaning intended to provoke a defined response of the receiver. A protocol therefore describes the syntax, semantics, and synchronization of communication. A programming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communications what programming languages are to computations. (A less technical reader might appreciate this similar analogy: protocols are to communications what grammar is to writing.) The communications protocols in use on the Internet are designed to function in very complex and diverse settings. To ease design, communications protocols are structured using a layering scheme as a basis. Instead of using a single universal protocol to handle all transmission tasks, a set of cooperating protocols fitting the layering scheme is used. The layering scheme in use on the Internet is called the TCP/IP model. The actual protocols are collectively called the Internet protocol suite. The group responsible for this design is called the Internet Engineering Task Force (IETF). The information exchanged between devices on a network or other communications medium is governed by rules or conventions that can be set out in a technical specification called a communication protocol standard. The nature of the communication, the actual data exchanged and any state-dependent behaviors are defined by the specification. Communicating systems have to communicate with each other using shared transmission media, because there is no common memory. Transmission is not necessarily reliable and can involve different hardware and operating systems on different systems. To implement a networking protocol, the protocol software modules are interfaced with a framework implemented on the machine's operating system. This framework implements the networking functionality of the operating system. The best known frameworks are the TCP/IP model and the OSI model. In communications, message values are transferred using transmission media. By analogy, the equivalent of a store would be a collection of transmission media, instead of a collection of memory locations. A valid assignment in a protocol (as an analog of programming language) could be Ethernet:='message' , meaning a message is to be broadcast on the local Ethernet.

NUST-SEECS & NEXTEK Services

On a transmission medium there can be many receivers. For instance a mac-address identifies an ether network card on the transmission medium (the 'ether'). In our imaginary protocol, the assignment Ethernet[mac-address]:=message value could therefore make sense. Basic requirements of protocols: Messages are sent and received on communicating systems to establish communications. Protocols should therefore specify rules governing the transmission. In general, much of the following should be addressed. Data formats for data exchange. Digital message bit strings are exchanged. The bit strings are divided in fields and each field carries information relevant to the protocol. Conceptually the bit string is divided into two parts called the header area and the data area. The actual message is stored in the data area, so the header area contains the fields with more relevance to the protocol. Bit strings longer than the maximum transmission unit (MTU) are divided in pieces of appropriate size. Address formats for data exchange. Addresses are used to identify both the sender and the intended receiver(s). The addresses are stored in the header area of the bitstrings, allowing the receivers to determine whether the bitstrings are intended for themselves and should be processed or should be ignored. A connection between a sender and a receiver can be identified using an address pair (sender address, receiver address). Usually some address values have special meanings. An all-1s address could be taken to mean an addressing of all stations on the network, so sending to this address would result in a broadcast on the local network. The rules describing the meanings of the address value are collectively called an addressing scheme. Address mapping. Sometimes protocols need to map addresses of one scheme on addresses of another scheme. For instance to translate a logical IP address specified by the application to an Ethernet hardware address. This is referred to as address mapping. Routing. When systems are not directly connected, intermediary systems along the route to the intended receiver(s) need to forward messages on behalf of the sender. On the Internet, the networks are connected using routers. This way of connecting networks is called internetworking. Detection of transmission errors is necessary on networks which cannot guarantee error-free operation. In a common approach, CRCs of the data area are added to the end of packets, making it possible for the receiver to detect differences caused by errors. The receiver rejects the packets on CRC differences and arranges somehow for retransmission. Acknowledgements of correct reception of packets is required for connection oriented communication. Acknowledgements are sent from receivers back to their respective senders. Loss of information - timeouts and retries. Packets may be lost on the network or suffer from long delays. To cope with this, under some protocols, a sender may expect an acknowledgement of correct reception from the receiver within a certain amount of time. On timeouts, the sender must assume the packet was not received and retransmit it. In case of a permanently broken link, the retransmission has no effect so the number of retransmissions is limited. Exceeding the retry limit is considered an error. Direction of information flow needs to be addressed if transmissions can only occur in one direction at a time as on half-duplex links. This is known as Media Access Control. Arrangements have to be made to accommodate the case when two parties want to gain control at the same time. Sequence control. We have seen that long bitstrings are divided in pieces, that are send on the network individually. The pieces may get lost or delayed or take different routes to their destination on some types of networks. As a result pieces may arrive out of sequence. Retransmissions can result duplicate pieces. By marking the pieces with sequence information at the sender, the receiver can determine what was lost or duplicated, ask for necessary retransmissions and reassemble the original message.

NUST-SEECS & NEXTEK Services

Flow control is needed when the sender transmits faster than the receiver or intermediate network equipment can process the transmissions. Flow control can be implemented by messaging from receiver to sender. Getting the data across a network is only part of the problem for a protocol. The data received has to be evaluated in the context of the progress of the conversation, so a protocol has to specify rules describing the context. These kind of rules are said to express the syntax of the communications. Other rules determine whether the data is meaningful for the context in which the exchange takes place. These kind of rules are said to express the semantics of the communications. Both intuitive descriptions as well as more formal specifications in the form of finite state machine models are used to describe the expected interactions of the protocol. Formal ways for describing the syntax of the communications are Abstract Syntax Notation One (a ISO standard) or Augmented Backus-Naur form (a IETF standard). Protocol design Communicating systems operate in parallel. The programming tools and techniques for dealing with parallel processes are collectively called concurrent programming. Concurrent programming only deals with the synchronization of communication. The syntax and semantics of the communication governed by a low-level protocol usually have modest complexity, so they can be coded with relative ease. High-level protocols with relatively large complexity could however merit the implementation of language interpreters. An example of the latter case is the HTML language. Concurrent programming has traditionally been a topic in operating systems theorie texts. Formal verification seems indispensable, because concurrent programs are notorious for the hidden and sophisticated bugs they contain. A mathematical approach to the study of concurrency and communication is referred to as Communicating Sequential Processes (CSP). Concurrency can also be modelled using finite state machines like Mealy- and Moore machines. Mealy- and Moore machines are in use as design tools in digital electronics systems, which we encounter in the form of hardware used in telecommunications or electronic devices in general. This kind of design can be a bit of a challenge to say the least, so it is important to keep things simple. For the Internet protocols, in particular and in retrospect, this meant a basis for protocol design was needed to allow decomposition of protocols into much simpler, cooperating protocols The OSI Model The Open Systems Interconnection (OSI) is a seven-layer protocol stack model used as a reference throughout the computer industry. The ISO was developed as a functional reference model only. One must note that some well known protocols such as TCP/IP and Signaling System 7 (SS7) were developed before the OSI model, and therefore do not exactly align with the defined OSI boundaries, where protocol stacks like IBMs SNA have a very close relationship. However, when used as a reference, the OSI model gives us a general idea of what to expect from the various layers of a given protocol stack.

NUST-SEECS & NEXTEK Services

OSI Stack Protocol Model;

NUST-SEECS & NEXTEK Services

CHAPTER 2 HDLC Protocol: HDLC (High Level Data Link Control) is one of the most common data link layer (layer 2) protocols. Many other common layer 2 protocols are heavily based on HDLC, particularly its framing structure. The HDLC protocol is defined by ISO for use on both point-to-point and multipoint (multidrop) data links. It supports full duplex transparent-mode operation and is now extensively used in both multipoint and computer networks. The rule of HDLC is to ensure that the data has been received without any loss or errors and in the correct order. HDLC has a flow control function which ensures that the data is transmitted as fast as the receiver can receive it. High-level Data Link Control (HDLC) is an enhanced derivative of SDLC from IBM. HDLC is the default serial link protocol for Cisco routers. Nearly all other routers on the market use PPP for link control. HDLC is a Data Link layer protocol. These protocols allow computers on either end of a physical connection (end stations) to communicate. There are two distinct HDLC implementations: HDLC NRM (also known as SDLC) and HDLC Link Access Procedure Balanced (LAPB), the later is a more popular implementation. HDLC is usually used by X.25. LAPB is a bit-oriented synchronous protocol that provides complete data transparency in a full-duplex point-to-point operation. It supports a peer-to-peer link in that neither end of the link plays the role of the permanent master station. HDLC NRM, on the other hand, has a permanent primary station with one or more secondary stations. HDLC LAPB is a very efficient protocol, which requires a minimum of overhead to ensure flow control, error detection and recovery. If data is flowing in both directions (full duplex), the data frames themselves carry all the information required to ensure data integrity. The concept of a frame window is used to send multiple frames before receiving confirmation that the first frame has been correctly been received. This means that data can continue to flow in situations where there may be long "turn-around" time lags without stopping to wait for an acknowledgement. This kind of situation occurs, for instance in satellite communication. Types of HDLC Stations: Primary Primary stations manage the connection to all secondary sessions by sending commands. Primary stations open and close connections and poll remote stations for data, or availability. Primary stations are used primarilly in multi-point networks or with mainframe applications where the mainframe is the primary station. The primary station uses unbalanced mode to communicate with the secondary stations. The primary station is responsible for all error detection, line control and data flow control. Secondary Secondary machines respond to commands sent from the Primary. Secondary stations are usually terminals attatched to mainframes. Communication between secondary stations and

10

NUST-SEECS & NEXTEK Services

primary stations is in unbalanced mode. The secondary station can only respond to the primary station and only when signaled to do so by the primary station. Combined Combined stations can establish and tear down their own connections. A combined station has the capabilities of both primary and secondary stations. These station types are usually used in point-to-point serial links such as a V.35 link to a CSU/DSU or between routers connected by a T1 or frame relay. Communication between two combined stations is in balanced mode. Configurations of HDLC: HDLC also defines three types of configurations for the three types of stations. The word configuration refers to the relationship between the hardware devices on a link. Following are the three configurations defined by HDLC: Unbalanced Configuration Balanced Configuration Symmetrical Configuration Unbalanced Configuration The unbalanced configuration in an HDLC link consists of a primary station and one or more secondary stations. The unbalanced condition arises because one station controls the other stations. In an unbalanced configuration, any of the following can be used: Full-Duplex or Half-Duplex operation Point to Point or Multi-point networks An example of an unbalanced configuration can be found below in Fig

Balanced Configuration The balanced configuration in an HDLC link consists of two or more combined stations. Each of the stations has equal and complimentary responsibility compared to each other. Balanced configurations can use only the following:

11

NUST-SEECS & NEXTEK Services

Full - Duplex or Half - Duplex operation Point to Point networks An example of a balanced configuration can be found below in Fig

Symmetrical Configuration This third type of configuration is not widely in use today. It consists of two independent pointto-point, unbalanced station configurations as shown in Fig.In this configuration, each station has a primary and secondary status. Each station is logically considered as two stations. HDLC Operation Modes; HDLC has three operational modes: 1. Normal Response Mode (NRM) Normal Response Mode is used in unbalanced configurations, a configuration is which there is only one primary, controlling station. In this mode, slave stations (or secondary) can only transmit when specially instructed by the master (primary station). The link may be point-to-point or multipoint. In the latter case only one primary station is allowed. 2. Asynchronous Response Mode (ARM) Asynchronous Response Mode is used in unbalanced configurations. It allows a secondary station to initiate a transmission without receiving permission from the primary station. This mode is normally used with point-to-point configurations and full duplex links and allows the secondary station to send frames asynchronously with respect to the primary station. 3. Asynchronous Balanced Mode (ABM) The Asynchronous Balanced Mode (ABM) is used mainly on full duplex point-to-point links for computer to computer communications and for connections between a computer and a packed switched data network, in this case each station has an equal status and performs the role of both primary and secondary functions. This mode is used in the protocol set known as X.25. HDLC Non-Operational Modes; HDLC also defines three non-operational modes. These three non-operational modes are: Normal Disconnected Mode (NDM) Asynchronous Disconnected Mode (ADM) Initialization Mode (IM)

12

NUST-SEECS & NEXTEK Services

The two disconnected modes (NDM and ADM) differ from the operational modes in that the secondary station is logically disconnected from the link (note the secondary station is not physically disconnected from the link). The IM mode is different from the operations modes in that the secondary station's data link control program is in need of regeneration or it is in need of an exchange of parameters to be used in an operational mode. Protocol Structure - HDLC: High Level Data Link Control Frame Format The standards frame of the HDLC protocol handles both data and control messages. It has the following format: Flag Address Control Information FCS Flag 1 Byte 1-2 Bytes 1 Byte variable 2 Bytes 1 Byte The Flag field Every frame on the link must begin and end with a flag sequence field (F). Stations attached to the data link must continually listen for a flag sequence. The flag sequence is an octet looking like 01111110. Flags are continuously transmitted on the link between frames to keep the link active. Two other bit sequences are used in HDLC as signals for the stations on the link. These two bit sequences are: Seven 1's, but less than 15 signal an abort signal. The stations on the link know there is a problem on the link. 15 or more 1's indicate that the channel is in an idle state. The time between the transmissions of actual frames is called the interframe time fill. The interframe time fill is accomplished by transmitting continuous flags between frames. The flags may be in 8 bit multiples. HDLC is a code-transparent protocol. It does not rely on a specific code for interpretation of line control. This means that if a bit at position N in an octet has a specific meaning, regardless of the other bits in the same octet. If an octet has a bit sequence of 01111110, but is not a flag field, HLDC uses a technique called bit-stuffing to differentiate this bit sequence from a flag field as we have discussed in the previous lesson. At the receiving end, the receiving station inspects the incoming frame. If it detects 5 consecutive 1's it looks at the next bit. If it is a 0, it pulls it out. If it is a 1, it looks at the 8th bit. If the 8th bit is a 0, it knows an abort or idle signal has been sent. It then proceeds to inspect the following bits to determine appropriate action. This is the manner in which HDLC achieves code-transparency. HDLC is not concerned with any specific bit code inside the data stream. It is only concerned with keeping flags unique. Address field The address of the secondary station which is sending the frame or the destination of the frame sent by the primary station. The address field contains Service Access Point (6bits), a Command/Response bit to indicate whether the frame relates to information frames (I-frames) being sent from the node or received by the node, and an address extension bit which is usually set to true to indicate that the address is of

13

NUST-SEECS & NEXTEK Services

length one byte. When set to false it indicates an additional byte follows. The address field may be extended to more than one byte by agreement between the involved parties. Control field : It identifies the type of the frame. In addition, it includes sequence numbers, control features and error tracking according to the frame type. Information field Data is transmitted in the information field, which can vary in length depending upon the protocol using the frame. Layer 3 frames are carried in the information field. FCS The Frame Check Sequence (FCS) is in most cases - 16 bit wide and serves for errors detection, the generator polynomial used is normally CRC-CCITT: x^16+x^12+x^5+1 . HDLC uses zero insertion/deletion process (commonly known as bit stuffing) to ensure that the bit pattern of the delimiter flag does not occur in the fields between flags. The HDLC frame is synchronous and therefore relies on the physical layer to provide method of clocking and synchronizing the transmission and reception of frames. Field Name Size(in bits) Flag Field( F ) 8 bits Address Field( A ) 8 bits Control Field( C ) 8 or 16 bits Information Field( I ) OR Data Variable; Not used in some frames Frame Check Sequence( FCS ) 16 or 32 bits Closing Flag Field( F ) 8 bits Categories of Frames; There are three categories of frames: Information framestransport data across the link and may encapsulate the higher layers of the OSI architecture. Supervisory framesperform the flow control and error recovery functions. Unnumbered framesprovide the link initialization and termination.

In the HDLC protocol three classes of frames are used:

14

NUST-SEECS & NEXTEK Services

1. Unnumbered frames Unnumbered frames are used for link management. . SNRM and SABM frames, for example, are used both to set up logical link between the primary and the secondary station and to inform the secondary station of the mode of operation to be used. A logical link is subsequently cleared by the primary station sending a DISC frame. The UA frame is used as an acknowledgment to the other frames in this class.

Unnumbered Format Commands and responses (U-Frame) The unnumbered format commands and responses are used to extend the number of data link control functions. The unnumbered format frames have 5 modifier bits, which allow for up to 32 additional commands and 32 additional response functions. Below, 13 command functions, and 8 response functions are described. Set Normal Response Mode (SNRM) places the secondary station into NRM. NRM does not allow the secondary station to send any unsolicited frames. Hence the primary station has control of the link. Set Asynchronous Response Mode (SARM) allows a secondary station to transmit frames without a poll from the primary station. Set Asynchronous Balanced Mode (SABM) sets the operational mode of the link to ABM. Disconnect (DISC) places the secondary station in to a disconnected mode. Set Normal Response Mode Extended (SNRME) increases the size of the control field to 2 octets instead of one in NRM. This is used for extended sequencing. The same applies for SARME and SABME. Set Initialization Mode (SIM) is used to cause the secondary station to initiate a station-specific procedure(s) to initialize its data link level control functions. Unnumbered Poll (UP) polls a station without regard to sequencing or acknowledgment. Unnumbered Information (UI) is used to send information to a secondary station. Exchange Identification (XID) is used to cause the secondary station to identify itself and provide the primary station identifications characteristics of itself.

15

NUST-SEECS & NEXTEK Services

Reset (RSET) is used to reset the receive state variable in the addressed station. Test (TEST) is used to cause the addressed secondary station to respond with a TEST response at the first response opportunity. It performs a basic test of the data link control. Unnumbered Acknowledgment (UA) is used by the secondary station to acknowledge the receipt and acceptance of an SNRM, SARM, SABM, SNRME, SARME, SABME, RSET, SIM, or DISC commands. Disconnected Mode (DM) is transmitted from a secondary station to indicate it is in disconnected mode(non-operational mode.) Request Initialization Mode (RIM) is a request from a secondary station for initialization to a primary station. Once the secondary station sends RIM, it can only respond to SIM, DSIC, TEST or XID commands. Request Disconnect (RD) is sent by the secondary station to inform the primary station that it wishes to disconnect from the link and go into a non-operational mode(NDM or ADM). Frame Reject (FRMR) is used by the secondary station in an operation mode to report that a condition has occurred in transmission of a frame and retransmission of the frame will not correct the condition. 2. Information frames Information frames are those who carry the actual data. The Information frames can be used to piggyback acknowledgment information relating to the flow of Information frames in the reverse direction when the link is being operated in ABM or ARM.

3. Supervisory frames Supervisory frames are use for error and flow control. They contain, send and receive sequence numbers. There are four types of supervisory frames but only RR and RNR are used in both NRM and ABM. These frames are used both to indicate the willingness of a secondary station to receive an information frame from the primary station, and for acknowledgment purposes. REJ and SREJ frames are used only in ABM which permits simultaneous two-way communication across a point to point link. The two frames are used to indicate to the other station that a sequence error has occurred, that is an information frame containing an out of sequence N(s) has been received. The SREJ frame is used with a selective repeat transmission procedure, whereas the REJ frame is used with a go back N procedure.

Supervisory Format commands and responses are as follows:

16

NUST-SEECS & NEXTEK Services

Receive Ready (RR) is used by the primary or secondary station to indicate that it is ready to receive an information frame and/or acknowledge previously received frames. Receive Not Ready (RNR) is used to indicate that the primary or secondary station is not ready to receive any information frames or acknowledgments. Reject (REJ) is used to request the retransmission of frames. Selective Reject (SREJ) is used by a station to request retransmission of specific frames. An SREJ must be transmitted for each erroneous frame; each frame is treated as a separate error. Only one SREJ can remain outstanding on the link at any one time. In a Nutshell; Information Transfer Format Commands I - Information Supervisory Format Commands RR - Receive ready RNR - Receive not ready REJ - Reject SREJ - Selective reject Unnumbered Format Commands SNRM - Set Normal Response Mode SARM - Set Asynchronous Response Mode SABM - Set Asynchronous Balanced Mode DISC - Disconnect SNRME - Set Normal Response Mode Extended SARME - Set Asynchronous Response Mode Extended SABME - Set Asynchronous Balanced Mode Extended SIM - Set Initialization Mode UP - Unnumbered Poll UI - Unnumbered Information XID - Exchange identification RSET - Reset TEST - Test

Information Transfer Format Responses I - Information Supervisory Format Responses RR - Receive ready RNR - Receive not ready REJ - Reject SREJ - Selective reject Unnumbered Format Commands UA - Unnumbered Acknowledgment DM - Disconnected Mode RIM - Request Initialization Mode RD - Request Disconnect UI - Unnumbered Information XID - Exchange Identification FRMR - Frame Reject TEST - Test

The Poll/Final Bit (P/F) The 5th bit position in the control field is called the poll/final bit, or P/F bit. It can only be recognized when it is set to 1. If it is set to 0, it is ignored. The poll/final bit is used to provide dialogue between the primary station and secondary station. The primary station uses P=1 to acquire a status response from the secondary station. The P bit signifies a poll. The secondary station responds to the P bit by transmitting a data or status frame to the primary station with the P/F bit set to F=1. The F bit can also be used to signal the end of a transmission from the secondary station under Normal Response Mode.

17

NUST-SEECS & NEXTEK Services

CHAPTER 3 Protocol Operation The two basic functions in the protocol are link management and data transfer (which includes error and flow control). Link management Prior to any kind of transmission (either between two stations connected by a point to point link or between a primary and secondary station connected with a multidrop link) a logical connection between the two communication parties must be established. A logical connection between the two communication parties is accomplished by the exchange of two unnumbered frames. The procedure for setting a logical connection (In a multidrop link) is given below: The SNRM is first sent by the primary station with the poll bit set to 1 and the address of the appropriate secondary in the address field. The secondary responds with a UA frame with the final bit set and its own address in the address field. After all the data has been transferred, the link is cleared by the primary sending a DISC frame and the secondary responding with a UA. Data transfer In NRM all data (information frames) is transferred under the control of the primary station. The unnumbered poll frame with the P bit set to 1 is normally used by the primary to poll a secondary. If the secondary has no data to transmit, it returns an RNR frame with the F bit set. If data is waiting, it transmits the data, typically as a sequence of information frames. The two most important aspects associated with the data transfer phase are error control and flow control. Essentially, error control uses a continuous RQ procedure with either a selective repeat or a go back N transmission strategy, while flow controls based on a window mechanism.

18

NUST-SEECS & NEXTEK Services

Transparency The flag sequence must never occur within the content of a frame otherwise it could be confused with an intentionally sent flag. A technique known as 0-bit insertion is used to prevent random data synthesising a flag. The technique is said to make HDLC transparent, since any stream of bits may be present between the open and closing flag of a frame. The transparency is achieved by encoding the data by inserting a 0bit after any sequence of 5 consecutive 1's within the payload, as shown:

Insertion of a "zero-bit" into the content of a frame to ensure transparency Bit stuffing and removal

19

NUST-SEECS & NEXTEK Services

FSM of Transparency:

Hardware Implementation:
HDLC protocol finds its application in vast. It can be used with fax machines. Fax machine needs proper communication between two ends. The data is being transferred and received is continuously monitored so that to avoid loss in information and effective operation of protocol. For this HDLC controller is preferred. Detailed Design: Here is a detailed design for HDLC protocol operation. In this design we want to monitor the data transmitted from both end. As it is clear HDLC is single and multipoint communication protocol so modem are typically used for proper data management and modem sharing device(MSD) is used to distribute data among multipoint. These behave like cluster controllers. We can transmit data serially through to the modem from two computers as well as we can use two FPGA. Using two FPGAs is difficult to implement because it needs extensive programming, cost, circuitry and maintenance. So better approach is by using computers and sending data serially. Data is de-framed for reception where it is to be monitored. This process is already defined above. Just for this we need and FPGA interfaced with computer.

20

NUST-SEECS & NEXTEK Services

Requirements: Computers FPGA Virtex 5 Modem CX86500 Modem sharing Device 3010

Framing: The data from transmitting end is framed and send via link. Here is simple FSM of the framing.

21

NUST-SEECS & NEXTEK Services

Design:

Master

Modem

Modem

Slave

Deframing

FPGA

Serial Interface with PC for monitoring

22

NUST-SEECS & NEXTEK Services

De-Framing: De-framing is done on the monitoring end.

Modem Sharing Device: The Model 3010 Three Port Modem Sharing Device allows three POS terminals, ATMs or similar RS232 devices to share a single RS-232 modem or multiplexer. The Model 3010 requires no AC power or batteries, operates asynchronously or synchronously and is small enough to plug directly into the DB-25 serial port on a modem or multiplexer. The Model 3010 operates by allowing the modem to pass data and control signals to all three DTE devices in parallel. Concurrently, the Model 3010 monitors each DTE device to see if it has data to send to the modem. When a terminal has data to send, it raises RTS and all its data and control signals are routed to the modem. As soon as that terminal is finished sending data, the Model 3010 resumes monitoring. If two or three terminals raise RTS simultaneously, the Model 3010 prioritizes the inputs: DTE channel one has priority over channel two, and channel two has priority over channel three. The Model 3010 has three DB-25 female DTE ports and on DB-25 male modem port. Either all connected devices must be asynchronous or they must all be synchronous: The Model 301 performs no data conversion. The DTE ports are labeled DTE #1, DTE #2 and DTE #3. The modem port is labeled MODEM. As figure (below) illustrates, input port DTE #1 is on one end of the unit. DTE ports DTE #2 and DTE #3 are on top when the Model 3010 is oriented in a normal fashion.

23

NUST-SEECS & NEXTEK Services

DTE Device

Modem

2 (TD) ------------------------------------------2 (RD) 4 (RTS) ----------------------------------------4 (RTS) 5 (CTS) ----------------------------------------5 (CTS) 20 (DTR) --------------------------------------20 (DTR) Modem: The typical Modem is CX86500. The CX86500 modem, packaged in a 28-pin TSSOP and 38-pin TSSOP, includes a Microcontroller (MCU), a Modem Data Pump (MDP), internal ROM, internal RAM, and SmartDAA interface functions. The modem connects to host via a logical V.24 (EIA/TIA232-E) serial DTE interface or a parallel 16550 UART-compatible host interface (38-pin only). The modem MCU/DSP performs the command processing, host interface functions and telephone line signal modulation/demodulation which reduces computational load on the host processor. The SmartDAA Interface communicates with, and supplies power and clock to the LSD through the DIB. It has following features. Modulations and protocols ITU-T V.92 Modem-on-Hold (MOH) Quick connect (QC) PCM upstream V.90/V.34/V.32bis/V.32 V.22bis/V.22/V.23/V.21

V.23 reverse, V.23 half-duplex Bell 212A/Bell 103 V.29 FastPOS V22bis fast connect V.80 Synchronous Access Mode Data compression V.44/V.42bis/MNP5

Error correction V.42/MNP 4/MNP 2 Call Waiting (CW) detection Type I and Type II Caller ID (CID) decoding DTE/host interface Serial DTE interface

24

NUST-SEECS & NEXTEK Services

Parallel 16550 UARTcompatible host interface (38-pin version) Direct Mode Synchronous Mode Asynchronous Mode No external memory required Sixty-three embedded and upgradeable country profiles Serial NVRAM interface for optional permanent country profile storage (38-pin version) Embedded AT commands Full-duplex Voice PassThrough Mode Mu-Law, A-Law (serial and parallel host interface) 14-bit PCM (parallel host interface only) SmartDAA Extension pick-up detection Digital line protection Line reversal detection Line-in-use detection Remote hang-up detection Worldwide compliance Selectable 28.224 MHz or 27.000 MHz frequency of operation Low power and voltage Single +3.3V supply Low power consumption mode +3.3V I/O level Compact, robust board design Small, low-profile modem packages SmartDAA and DIB technologies

25

NUST-SEECS & NEXTEK Services

Some of the applications of modem are: Set top boxes Point-of-Sale terminals ATM machines Metering terminals Video game consoles Internet appliances

26

NUST-SEECS & NEXTEK Services

Data Reception:

27

NUST-SEECS & NEXTEK Services

Chapter 4 Reception: `timescale 1ns / 1ps ////////////////////////////////////////////////////////////////////////////////// // Company: // Engineer: // // Create Date: 05:37:42 08/24/2011 // Design Name: // Module Name: hdlc_recv // Project Name: // Target Devices: // Tool versions: // Description: // // Dependencies: // // Revision: // Revision 0.01 - File Created // Additional Comments: // ////////////////////////////////////////////////////////////////////////////////// module hdlc_recv(ihdlc_RXD, ihdlc_RXCLK, ihdlc_RESET, ohdlc_TXD, ohdlc_TXCLK, ohdlc_TXDS ); /**************************************************************************/ ///*** input signals define ***/// /**************************************************************************/ input ihdlc_RXD; input ihdlc_RXCLK; input ihdlc_RESET; /**************************************************************************/ ///*** outputs define ***/// /**************************************************************************/ output ohdlc_TXCLK;

28

NUST-SEECS & NEXTEK Services

output [7:0] ohdlc_TXD; output [2:0] ohdlc_TXDS; reg ohdlc_TXCLK; reg [7:0] ohdlc_TXD; reg [2:0] ohdlc_TXDS; reg [2:0] ohdlc_TXDS_tmp; /**************************************************************************/ ///*** inner signals define ***/// /**************************************************************************/ reg error; // illegal byte detectived when equal 1 reg error_wire; reg error_flag; reg delete_zero; // 5 "1" detectived when equal 1 reg delete_zero_wire; reg frame_end; // end of a normal frame reg flag_7e; // "7e" detectived when equal 1 reg [3:0] bit_counter; reg [6:0] byte_counter; reg [7:0] shifter1; reg [7:0] shifter2; reg [2:0] byte_rst_counter; reg byte_rst_counter_start; /**************************************************************************/ ///*** 5 "1"& illegal frame detectiver state machine define ***/// /**************************************************************************/ reg [6:0] flagdetc_cur_state; reg [6:0] flagdetc_next_state; parameter idle = 7'b000_0001, flag1 = 7'b000_0010, flag2 = 7'b000_0100, flag3 = 7'b000_1000, flag4 = 7'b001_0000, flag5 = 7'b010_0000, flag6 = 7'b100_0000;

/**************************************************************************/ ///*** series shifter ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET)

29

NUST-SEECS & NEXTEK Services

begin shifter2[7:0] <= 8'b0; end else begin if(delete_zero_wire) begin shifter2[7:0] <= shifter2[7:0]; end else begin shifter2[7:0] <= {shifter2[6:0],shifter1[7]}; end end end always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin shifter1[7:0] <= 8'b0; end else begin if(flag_7e) begin shifter1[7:0] <= {shifter1[6:0],ihdlc_RXD}; end else begin shifter1[7:0] <= {shifter1[6:0],ihdlc_RXD}; end end end

/**************************************************************************/ ///*** "7E" detectiver ***/// /**************************************************************************/ always @(shifter1[7:0] or byte_counter[6:0] or bit_counter[3:0] or byte_rst_counter_start) begin if(shifter1[7:0]==8'h7e) begin if(byte_counter[6:0]!=0) begin if(bit_counter[3:0]==4'b1111||bit_counter[3:0]==4'b0111)

30

NUST-SEECS & NEXTEK Services

flag_7e = 1'b1; else flag_7e = 1'b0; end else begin flag_7e = 1'b1; end end else begin flag_7e = 1'b0; end end /**************************************************************************/ ///*** detectiver state machine ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin delete_zero <= 1'b0; error <= 1'b0; flagdetc_cur_state <= idle; end else begin flagdetc_cur_state <= flagdetc_next_state; delete_zero <= delete_zero_wire; error <= error_wire; end end /*************************************************************************/ //*** 5 "1"series & illegal frame detective ***// /*************************************************************************/ always @(flagdetc_cur_state or shifter1[7]) begin case (flagdetc_cur_state) idle : begin error_wire = 1'b0; delete_zero_wire = 1'b0; if(shifter1[7]==1'b0) begin

31

NUST-SEECS & NEXTEK Services

flagdetc_next_state = idle; end else begin flagdetc_next_state = flag1; end end flag1 : //////////////////////////////////1 "1" begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag2; end else begin flagdetc_next_state = idle; end end flag2 : //////////////////////////////////2 "1" begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag3; end else begin flagdetc_next_state = idle; end end flag3 : //////////////////////////////////3 "1" begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag4; end else begin flagdetc_next_state = idle; end end flag4 : ///////////////////////////////////4 "1" begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag5; end

32

NUST-SEECS & NEXTEK Services

else begin flagdetc_next_state = idle; end end flag5 : ////////////////////////////////////5 "1" begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag6; end else begin flagdetc_next_state = idle; delete_zero_wire = 1'b1; end end flag6 : ////////////////////////////////////6 "1" and more begin if(shifter1[7]==1'b1) begin flagdetc_next_state = flag6; if(bit_counter==4'b1101) //for test error_wire = 1'b1; end else begin flagdetc_next_state = idle; //if(bit_counter==4'b1101) error_wire = 1'b1; // for test end end default: begin flagdetc_next_state = idle; end endcase end /**************************************************************************/ ////** State Machine end **// /**************************************************************************/

33

NUST-SEECS & NEXTEK Services

/**************************************************************************/ ///*** byte_reset counter ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin byte_rst_counter[2:0] <= 3'b0; end else begin if(byte_rst_counter_start) byte_rst_counter[2:0] <= byte_rst_counter[2:0] + 1; else byte_rst_counter[2:0] <= 3'b0; end end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin byte_rst_counter_start <= 1'b0; end else begin if(byte_rst_counter[2:0]==3'b111) byte_rst_counter_start <= 1'b0; else if(flag_7e) byte_rst_counter_start <= 1'b1; end end /**************************************************************************/ ///*** bit_counter & byte_counter ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) // bit_counter begin if(!ihdlc_RESET) begin bit_counter[3:0] <= 4'b0; end else begin if(flag_7e||(shifter1[7:0]==8'b1111_1111&&(byte_counter==7'b0&&bit_counter<=4'b1000))) begin

34

NUST-SEECS & NEXTEK Services

bit_counter[3:0] <= 4'b0; end else begin if(bit_counter!=4'b1111) begin if(delete_zero_wire!=1'b1) bit_counter[3:0] <= bit_counter[3:0] + 1; end else begin if(delete_zero_wire!=1'b1) bit_counter[3:0] <= 4'b1000; end end end end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) // byte_counter begin if(!ihdlc_RESET) begin byte_counter[6:0] <= 7'b0; end else begin if(byte_rst_counter[2:0]==3'b111) begin byte_counter[6:0] <= 7'b0; end else begin if(bit_counter==4'b1111&&delete_zero!=1'b1) begin if(byte_counter[6:0]!=7'b111_1111) byte_counter[6:0] <= byte_counter[6:0] + 1; else byte_counter[6:0] <= byte_counter[6:0] ; end end end end

/**************************************************************************/

35

NUST-SEECS & NEXTEK Services

///*** TXData Status ***/// /**************************************************************************/ always @(byte_counter[6:0] or error_flag or frame_end or error_wire) begin if(frame_end) begin if(error_flag||error_wire) ohdlc_TXDS_tmp[2:0] = 3'b000; // illegal frame_end else if(byte_counter>64||byte_counter==64&&!delete_zero) ohdlc_TXDS_tmp[2:0] = 3'b001; // long frame_end else if(byte_counter<=2||byte_counter==3&&delete_zero) ohdlc_TXDS_tmp[2:0] = 3'b010; // short frame_end else if(byte_counter!=0) ohdlc_TXDS_tmp[2:0] = 3'b011; // normal frame_end else ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data end else begin if(!error_flag) begin if(byte_counter==1) ohdlc_TXDS_tmp[2:0] = 3'b110; // first byte else if(byte_counter==2) ohdlc_TXDS_tmp[2:0] = 3'b101; // second byte else if(byte_counter!=0) ohdlc_TXDS_tmp[2:0] = 3'b100; // other byte else ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data end else ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data end end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin ohdlc_TXDS <= 3'b111; end else begin if(byte_rst_counter_start!=1'b1||flag_7e) ohdlc_TXDS <= ohdlc_TXDS_tmp; end end

36

NUST-SEECS & NEXTEK Services

/**************************************************************************/ ///*** Output CLK Generator ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin ohdlc_TXCLK <= 1'b1; end else begin if(bit_counter[3:0]==4'b1111||ohdlc_TXDS==3'b111||error||error_flag) begin ohdlc_TXCLK <= 1'b1; end else if((bit_counter[3:0]==4'b1011||byte_rst_counter[2:0]==3'b100)&&ohdlc_TXDS!=3'b111) begin ohdlc_TXCLK <= 1'b0; end else ohdlc_TXCLK <= ohdlc_TXCLK; end end /**************************************************************************/ ///*** output Data load ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if(!ihdlc_RESET) begin ohdlc_TXD[7:0] <= 8'b0; end else begin if(bit_counter[3:0]==4'b1111) ohdlc_TXD[7:0] <= shifter2[7:0]; end end /**************************************************************************/ ///*** frame_end signal generator ***/// /**************************************************************************/ always @(shifter1[7:0] or bit_counter[3:0]) begin begin if(shifter1[7:0]==8'h7e&&bit_counter[3:0]==4'b1111) begin

37

NUST-SEECS & NEXTEK Services

frame_end = 1'b1; end else begin frame_end = 1'b0; end end end /**************************************************************************/ ///*** error_flag generater ***/// /**************************************************************************/ always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) begin if (!ihdlc_RESET) begin error_flag <= 1'b0 ; end else begin if(byte_rst_counter[2:0]==3'b111) begin error_flag <= 1'b0 ; end else begin if(error_wire&&byte_counter[6:0]!=7'b0) error_flag <= 1'b1; else if(error_wire&&bit_counter[3:0]==4'b1101) //for test error_flag <= 1'b1; // for test else error_flag <= error_flag; end end end endmodule

38