This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 025-2 Hybrid Fiber Coax Outside Plant Status Monitoring - MAC Layer Spec v1.0 (2008).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ENGINEERING COMMITTEE Hybrid Management Sub-Layer Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 25-2 2008 Hybrid Fiber Coax Outside Plant Status Monitoring – Media Access Control (MAC) Layer Specification v1.0 NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non- member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards. Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 2008 140 Philips Road Exton, PA 19341 1 TABLE OF CONTENTS LIST OF FIGURES ...................................................................................................................... 5 LIST OF TABLES ........................................................................................................................ 6 DOCUMENT HISTORY ............................................................................................................. 7 1.1 SCOPE .............................................................................................................................. 7 1.2 TRANSPONDER TYPE CLASSIFICATIONS ........................................................................... 7 1.3 HMS REFERENCE ARCHITECTURE FORWARD AND RETURN CHANNEL SPECIFICATIONS . 9 1.4 HMS SPECIFICATION DOCUMENTS ................................................................................ 10 2 MEDIA ACCESS CONTROL LAYER SPECIFICATION ........................................... 11 2.1 INTRODUCTION .............................................................................................................. 11 2.1.1 Overview ................................................................................................................... 11 2.1.2 Definitions and Conventions ..................................................................................... 11 2.1.2.1 Separate Forward and Return Channels ............................................................ 11 2.1.2.2 Single Forward and Return Path Channels per MAC Layer Domain ............... 11 2.1.2.3 Network Element (NE) Term Usage................................................................. 12 2.1.2.4 Packet ................................................................................................................ 12 2.1.2.5 Most Significant Byte ....................................................................................... 12 2.1.2.6 Byte Number Representation ............................................................................ 12 2.1.2.7 Reserved Bits .................................................................................................... 12 2.2 MAC PACKET TRANSPORT ............................................................................................ 13 2.2.1 Byte Transmission Format ........................................................................................ 13 2.2.2 Byte Transmission Order .......................................................................................... 13 2.2.3 Bit Transmission Order............................................................................................. 13 2.2.4 Transmission Timing................................................................................................. 13 2.2.4.1 Forward Channel Packets ................................................................................. 13 2.2.4.1.1 Timing ......................................................................................................... 13 2.2.4.2 Return Channel Packets .................................................................................... 14 2.2.4.2.1 Front Porch .................................................................................................. 14 2.2.4.2.2 Timing ......................................................................................................... 14 2.3 MAC PACKET STRUCTURE ............................................................................................ 14 2.3.1 Synch ......................................................................................................................... 14 2.3.2 Control ...................................................................................................................... 15 2.3.2.1 Protocol (Bits 3:0) ............................................................................................. 15 2.3.2.2 RSVDx (Bits 7:4).............................................................................................. 15 2.3.3 Address...................................................................................................................... 16 2.3.3.1 Unicast .............................................................................................................. 17 2.3.3.2 Broadcast........................................................................................................... 17 2.3.3.3 Multicast ........................................................................................................... 17 2.3.4 Sequence ................................................................................................................... 17 2.3.4.1 MSGSEQ (Bits 6:0) .......................................................................................... 18 2.3.4.2 SYN (Bit 7) ....................................................................................................... 19 2 2.3.5 Length ....................................................................................................................... 19 2.3.6 Payload ..................................................................................................................... 20 2.3.7 Frame Check Sequence (FCS) .................................................................................. 20 2.4 MAC PACKET DELIMITERS............................................................................................ 20 2.4.1 Packet Start ............................................................................................................... 20 2.4.2 Packet End ................................................................................................................ 20 2.4.3 Synch Byte Padding .................................................................................................. 21 2.5 MAC PROTOCOL DATA UNITS (PDUS) ......................................................................... 22 2.5.1 NAK ........................................................................................................................... 23 2.5.2 ACK ........................................................................................................................... 23 2.5.3 STATRQST ................................................................................................................ 24 2.5.4 STATRESP ................................................................................................................ 24 2.5.4.1 CHNLRQST (Bit 0) .......................................................................................... 25 2.5.4.2 CNTNRM (Bit 1) .............................................................................................. 25 2.5.4.3 CNTCUR (Bit 2) ............................................................................................... 25 2.5.4.4 MAJOR (Bit 3) ................................................................................................. 25 2.5.4.5 MINOR (Bit 4) .................................................................................................. 26 2.5.4.6 RSVDx (Bit 7:5) ............................................................................................... 26 2.5.5 TALKRQST ............................................................................................................... 26 2.5.6 TALK ......................................................................................................................... 27 2.5.7 CONTMODE............................................................................................................. 27 2.5.7.1 CONTMODE:MODE ....................................................................................... 28 2.5.7.2 CONTMODE:DURATION .............................................................................. 29 2.5.8 REG_REQ ................................................................................................................. 30 2.5.9 SET_ADDR ............................................................................................................... 30 2.5.10 REG_END ............................................................................................................. 31 2.5.10.1 REG_END:STATUS .................................................................................... 31 2.5.10.2 REG_END:TOD ........................................................................................... 32 2.5.11 CHNLDESC .......................................................................................................... 32 2.5.12 INVCMD ............................................................................................................... 33 2.5.12.1 INVCMD:REASON ..................................................................................... 33 2.5.13 TIME ..................................................................................................................... 34 2.5.13.1 TIME:TOD ................................................................................................... 34 3 MAC PROTOCOL OPERATION .................................................................................... 35 3.1 NON-VOLATILE PARAMETERS ....................................................................................... 35 3.2 DUPLEX CAPABILITIES ................................................................................................... 35 3.3 PACKET PRIORITIES ....................................................................................................... 35 3.4 PACKET RECEPTION ....................................................................................................... 35 3.5 NE RESPONSES .............................................................................................................. 36 3.5.1 NE Processing Times – Broadcast and Multicast Messages .................................... 36 3.5.2 NE Response Times – Unicast Messages .................................................................. 36 3.6 MESSAGE SEQUENCE NUMBERS AND TRANSACTION SYNCHRONIZATION ...................... 36 3.7 SOLICITED MESSAGES.................................................................................................... 37 3.8 AUTONOMOUS (UNSOLICITED) MESSAGES .................................................................... 38 3.8.1 NE Contention State .................................................................................................. 38 3 3.8.2 Collisions .................................................................................................................. 39 3.8.3 HE Collision Detection ............................................................................................. 39 3.8.4 NE Collision Indication ............................................................................................ 40 3.8.5 Backoff Algorithm ..................................................................................................... 40 3.8.6 Backoff State Machine Description .......................................................................... 40 3.8.7 Backoff Reset ............................................................................................................. 41 3.8.8 Parameters ................................................................................................................ 42 3.9 RETURN CHANNEL TRANSMISSIONS .............................................................................. 42 3.10 MAC STATE MACHINES ................................................................................................ 44 3.10.1 Contention State Machine ..................................................................................... 44 3.10.2 Backoff State Machine .......................................................................................... 45 REFERENCES............................................................................................................................ 46 4 NORMATIVE REFERENCES ......................................................................................... 46 4.1 SCTE REFERENCES........................................................................................................ 46 4.2 STANDARDS FROM OTHER ORGANIZATIONS ................................................................... 46 5 INFORMATIVE REFERENCES ..................................................................................... 46 5.1 PUBLISHED MATERIALS ................................................................................................. 46 APPENDIX A. OPERATIONAL DETAILS ...................................................................... 47 A.1 INTRODUCTION .............................................................................................................. 47 A.2 TIME OF DAY................................................................................................................. 47 A.2.1 Integer Representation .......................................................................................... 47 A.3 FIRMWARE DOWNLOADS ............................................................................................... 47 A.4 NE ADDRESSING ............................................................................................................ 47 A.4.1 Direct Addressing Using Individual IP Address................................................... 47 A.4.2 Proxy Addressing Using Common IP Address ..................................................... 48 A.5 ALARM PROCESSING HMS MAC PROTOCOL................................................................. 48 A.5.1 Managed Parameter Properties ........................................................................... 48 A.5.2 Alarm Thresholds and Operation ......................................................................... 50 A.5.3 Alarms MIB Information ....................................................................................... 51 A.5.4 NE Alarm Processing............................................................................................ 51 A.5.5 Alarm Notification and Retrieval .......................................................................... 51 A.5.5.1 Notification – Polled Mode ................................................................................... 52 A.5.5.2 Notification – Contention Mode............................................................................ 52 A.5.5.3 Retrieval ................................................................................................................ 52 A.5.5.4 Alarm and Message Flows .................................................................................... 53 A.6 AUTOMATIC CHANNEL DISCOVERY ............................................................................... 55 A.7 AUTO-REGISTRATION .................................................................................................... 55 A.8 CONFIGURATION CHANGES AND SNMP TRAP GENERATION ......................................... 57 APPENDIX B. GLOSSARY................................................................................................. 59 APPENDIX C. LIST OF ACRONYMS .............................................................................. 61 4 LIST OF FIGURES FIGURE 1: HMS REFERENCE ARCHITECTURE DIAGRAM ......................................................9 FIGURE 2: BIT TRANSMISSION ORDER ..................................................................................13 FIGURE 3: MAC PACKET STRUCTURE ..................................................................................14 FIGURE 4: MAC HEADER CONTROL BYTE – BIT DEFINITION .............................................15 FIGURE 5: MAC HEADER SEQUENCE BYTE – BIT DEFINITION............................................18 FIGURE 6: MAC PDU STRUCTURE........................................................................................22 FIGURE 7: STATRESP STATUS BYTE – BIT DEFINITION ..................................................24 FIGURE 8: RETURN CHANNEL TRANSMISSION PERMITTED .................................................43 FIGURE 9: CONTENTION STATE DIAGRAM ............................................................................44 FIGURE 10: BACKOFF STATE DIAGRAM ................................................................................45 FIGURE 11: SCTE HMS PROPERTY MIB USAGE .................................................................49 5 LIST OF TABLES TABLE 1: TRANSPONDER TYPE CLASSIFICATIONS ..................................................................8 TABLE 2: HMS DOCUMENT FAMILY .....................................................................................10 TABLE 3: GENERIC MAC PACKET STRUCTURE ...................................................................14 TABLE 4: PROTOCOL FIELD VALUES .....................................................................................15 TABLE 5: MAC PDUS ............................................................................................................22 TABLE 6: POSSIBLE MAC PROTOCOL TRANSACTIONS ........................................................23 TABLE 7: NAK PDU FORMAT ...............................................................................................23 TABLE 8: ACK PDU FORMAT ...............................................................................................23 TABLE 9: STATRQST PDU FORMAT ...................................................................................24 TABLE 10: STATRESP PDU FORMAT .................................................................................24 TABLE 11: CHNLRQST BIT SETTINGS ................................................................................25 TABLE 12: CNTNRM BIT SETTINGS .....................................................................................25 TABLE 13: CNTCUR BIT SETTINGS......................................................................................25 TABLE 14: MAJOR BIT SETTINGS ........................................................................................26 TABLE 15: MINOR BIT SETTINGS ........................................................................................26 TABLE 16: TALKRQST PDU FORMAT ................................................................................26 TABLE 17: TALK PDU FORMAT ...........................................................................................27 TABLE 18: CONTMODE PDU FORMAT ..............................................................................28 TABLE 19: CONTMODE:MODE SETTINGS ........................................................................28 TABLE 20: NE MESSAGE RETRIEVAL EXAMPLE ..................................................................29 TABLE 21: REG_REQ PDU FORMAT ...................................................................................30 TABLE 22: SET_ADDR PDU FORMAT .................................................................................30 TABLE 23: REG_END PDU FORMAT ...................................................................................31 TABLE 24: REG_END:STATUS SETTINGS .........................................................................31 TABLE 25: CHNLDESC PDU FORMAT ................................................................................32 TABLE 26: INVCMD PDU FORMAT .....................................................................................33 TABLE 27: INVCMD:REASON CODES ...............................................................................34 TABLE 28: TIME PDU FORMAT ...........................................................................................34 TABLE 29: NON-VOLATILE PARAMETERS .............................................................................35 TABLE 30: MAC SEQUENCE FIELD EXAMPLE (NON-CONTENTION MODE) ........................37 TABLE 31: CONTENTION STATE SETTINGS VERSUS FORWARD CHANNEL PACKETS ...........39 TABLE 32: BACKOFF STATE MACHINE PARAMETERS ..........................................................42 TABLE 33: HMS PROPERTIES ................................................................................................50 TABLE 34: ALARM NOTIFICATION AND RETRIEVAL – POLLED MODE ................................53 TABLE 35: ALARM NOTIFICATION AND RETRIEVAL – CONTENTION MODE .......................54 TABLE 36: AUTO-REGISTRATION IMPLEMENTATION EXAMPLE ..........................................57 6 Introduction The Hybrid Fiber Coax (HFC) Outside Plant (OSP) Media Access Control (MAC) Layer Specification is part of the suite of specifications developed by the Hybrid Management Sub- Layer (HMS) subcommittee under the SCTE. The purpose of the HMS specifications is to support the design and implementation of interoperable management systems for evolving HFC cable networks. The HMS Media Access Control (MAC) Layer Specification describes the messaging and protocols implemented at the Data Link Layer (DLL), Layer 2 in the 7-layer ISO- OSI reference model, that support reliable and efficient communications between HMS- compliant transponders interfacing to managed OSP network elements (NEs) and a centralized headend element (HE). 1.1 Scope This specification describes the MAC layer protocols that must be implemented between all Type 2 and Type 3 compliant OSP HMS transponders on the HFC plant and the controlling equipment in the headend to support bandwidth management and reliable communications. Any exceptions to compliance with this specification will be specifically noted in this document as necessary. Refer to Table 1 for a full definition of the Type Classifications. 1.2 Transponder Type Classifications Transponder type classifications referenced within the HMS suite of specifications are defined in Table 1. 7 Table 1: Transponder Type Classifications Type Description Application • This transponder interfaces with legacy network Refers to legacy transponder equipment through proprietary means. Type 0 equipment which is incapable of • This transponder could be managed through the same supporting the HMS specifications. management applications as the other types through proxies or other means at the headend. • This transponder interfaces with legacy network Refers to stand-alone transponder equipment through proprietary means. equipment (legacy or new) which can • Type 1 is a standards-compliant transponder (either Type 1 be upgraded to support the HMS manufactured to the standard or upgraded) that specifications. connects to legacy network equipment via a proprietary interface. • This transponder interfaces with network equipment designed to support the electrical and physical Refers to a stand-alone, HMS- specifications defined in the HMS standards. Type 2 compliant transponder. • It can be factory or field-installed. • Its RF connection is independent of the monitored NE. • This transponder interfaces with network equipment designed to support the electrical specifications defined in the HMS standards. Refers to a stand-alone or embedded, • It may or may not support the physical specifications Type 3 defined in the HMS standards. HMS-compliant transponder. • It can be factory-installed. It may or may not be field- installed. • Its RF connection is through the monitored NE. 8 1.3 HMS Reference Architecture Forward and Return Channel Specifications The reference architecture for the HMS suite of specifications is illustrated in Figure 1. Figure 1: HMS Reference Architecture Diagram Fiber Node RF Optical RF RF TRANSMITER Laser Receiver Splitter RECEIVER RF Amplifier Chain Headend Status Status Monitoring Diplexer * Monitoring Device Equipment RF Optical RF RF Receiver Laser Combiner RECEIVER TRANSMITER B C A * The diplexer filter may be included as part of the network element to which the transponder interfaces, or it may be added separately by the network operator. All quantities relating to forward channel transmission or reverse channel reception are measured at point A in Figure 1. All quantities relating to forward channel reception or reverse channel transmission are measured at point B for two-port devices and point C for single-port devices as shown in Figure 1. 9 1.4 HMS Specification Documents A list of documents in the HMS specifications family is provided in Table 2. Table 2: HMS Document Family HMS Notation Title SCTE HMS PHY HMS Outside Plant Status Monitoring – Physical (PHY) Layer Specification HMS Outside Plant Status Monitoring – Media Access Control (MAC) SCTE HMS MAC Layer Specification HMS Outside Plant Status Monitoring – Power Supply to Transponder SCTE HMS PSTIB Interface Bus (PSTIB) Specification SCTE HMS ALARMS MIB HMS Alarms Management Information Base SCTE HMS COMMON MIB HMS Common Management Information Base SCTE HMS FIBERNODE MIB HMS Fiber Node Management Information Base SCTE HMS PROPERTY MIB HMS Alarm Property Management Information Base SCTE HMS PS MIB HMS Power Supply Management Information Base SCTE ROOT MIB SCTE Root Management Information Base SCTE HMS GEN MIB HMS Power Supply Generator Management Information Base SCTE HMS TIB MIB HMS Transponder Interface Bus Management Information Base SCTE HMS DOWNLOAD MIB HMS Transponder Firmware Download Management Information Base SCTE HMS TREE MIB HMS Root Object Identifiers Management Information Base 10 2 Media Access Control Layer Specification 2.1 Introduction 2.1.1 Overview This section describes version 1.0 of the SCTE HMS MAC protocol. Some of the SCTE HMS MAC protocol features include: • Support for transaction-based message exchange over the HFC forward and return RF channels. Transactions can be initiated by either the HE or the NE. • Support for transport of multiple network PDU types over the HFC forward and return RF channels including, but not limited to, IP over Serial and SNMP over Serial. • Extensions provided to support future transport of other network PDU types. • Efficient use of HFC forward and return RF spectrum through central HE management of NE transmission opportunities. 2.1.2 Definitions and Conventions 2.1.2.1 Separate Forward and Return Channels The one-way communication channel from the HE to a managed OSP NE is referred to as the forward channel. The one-way communication channel from a managed OSP NE to the HE is referred to as the return channel. Both the forward and the return channels are placed on specific center frequencies. The forward and return channels’ center frequencies are different. Since the NEs only listen to the forward channel, they cannot listen to return channel transmissions from other NEs. This channel separation is a result of the sub-band split between the forward and return portions of the typical HFC plant spectrum. 2.1.2.2 Single Forward and Return Path Channels per MAC Layer Domain To keep management of carrier frequencies simple, each HMS-based status monitoring system has a single forward channel and a single return channel. This does not preclude the use of multiple monitoring systems, each with its own individual forward and return RF channels. A MAC layer domain consists of a single forward RF channel and a single return RF channel over which a single HMS MAC layer bandwidth allocation and management protocol operates. It includes a centralized HE and multiple HMS-compliant transponders interfacing to managed OSP NEs. The centralized HE may support multiple HMS-based status monitoring systems, i.e.: multiple MAC layer domains. Each OSP NE must only access a single forward channel and its associated single return channel; i.e.: it must only operate within a single HMS MAC layer domain. 11 2.1.2.3 Network Element (NE) Term Usage The HMS MAC layer supports bandwidth management and reliable communications between a HE and multiple HMS-compliant transponders that interface to managed OSP NEs. Throughout this document, the terms “HMS-compliant transponder”, “transponder”, and “NE” are used interchangeably when describing the MAC processes that support the exchange of data or other information between two or more entities at the DLL. 2.1.2.4 Packet A packet is a unit of data exchanged between the HE and any of a number of managed OSP NEs at the DLL. Packets are strings of bytes that can be sent contiguously or be separated by periods of silence. Document SCTE 25-1 HMS Outside Plant Status Monitoring – Physical (PHY) Layer Specification v1.0 describes specific byte transmission modes that must be implemented in both forward and return channels. A MAC packet consists of a MAC header, a variable-length payload, and a frame check sequence (see Section 2.3). 2.1.2.5 Most Significant Byte Unless otherwise specified, it is assumed throughout this document that the left-most entry in any numeric value is the most significant, i.e.: for the address represented as 12-34-56-78-9A-BC the left-most entry ‘12’ is the most significant value. 2.1.2.6 Byte Number Representation Throughout this document, bits labeled ‘0’ are the least significant bits (LSBs) and bits labeled ‘7’ are the most significant bits (MSBs). The bits in a given byte will be described with bit 7 (MSB) at the left and bit 0 (LSB) at the right. This convention has been adopted for presentation purposes only and has no effect on the actual bit transmission order. Bit transmission order details are provided in Section 2.2 of this specification. 2.1.2.7 Reserved Bits A number of bits are indicated with the word “Reserved” or the abbreviation “RSVD” in the various MAC packets described in this document. Any receiving NE must ignore these bits when implementing this version (1.0) of the HMS MAC protocol. 12 2.2 MAC Packet Transport 2.2.1 Byte Transmission Format Bytes transmitted over both forward and return channels are ten bits in length. They contain one start bit, eight bits of data, and one stop bit. The start bit has binary value ‘0’, and the stop bit has binary value ‘1.’ 2.2.2 Byte Transmission Order Fields consisting of multiple bytes, i.e.: a MAC address, will have the most significant byte transmitted first. Any exceptions to this rule will be specifically noted in this document as necessary. 2.2.3 Bit Transmission Order The LSB of a single byte, bit 0, is always transmitted first following the start bit. The MSB of a single byte, bit 7, is always transmitted last followed by the stop bit. The transmission order is summarized in Figure 2. Figure 2: Bit Transmission Order 2.2.4 Transmission Timing 2.2.4.1 Forward Channel Packets 2.2.4.1.1 Timing Forward channel packets must be transmitted in a manner such that, 1. No two bytes within a packet are separated by more than 3 ms, AND 2. The entire packet must be transmitted within 120% of the shortest time for that frame. The shortest time is defined as the time for transmission of the packet with no gaps between bytes. 13 2.2.4.2 Return Channel Packets 2.2.4.2.1 Front Porch NE transmission of the first byte of a message shall begin within a window of two and five byte times after the transmitter power reaches 90% of its final value. Until the first byte is transmitted, the frequency will rest on the ‘mark’ frequency. This is standard Universal Asynchronous Receiver/Transmitter (UART) transmission. The front porch ensures that the receiving UART can be cleared of all framing errors prior to the start of reception of valid data. 2.2.4.2.2 Timing Return channel packets must be transmitted in a manner such that no two bytes within a packet are separated by more than 260 μs (1 byte time). All bits within a single byte shall be immediately contiguous; there shall be no gaps at bit boundaries within a byte. 2.3 MAC Packet Structure MAC packets consist of a MAC header, a variable-length payload, and a two-byte frame check sequence. Packet structure and sizes are identical for both forward and return channel packets. MAC packet structure is illustrated in Figure 3. Figure 3: MAC Packet Structure Start End Synch Control Address Sequence Length Payload FCS All MAC packets must have the general format as described in Table 3. Table 3: Generic MAC Packet Structure Field Name Length (bits) Section Synch 8 2.3.1 Control 8 2.3.2 Address 48 2.3.3 Sequence 8 2.3.4 Length 16 2.3.5 Payload N 2.3.6 FCS 16 2.3.7 2.3.1 Synch The Synch field consists of a single byte and identifies the start of the MAC layer packet. It shall be set to 0xA5. 14 2.3.2 Control The Control field consists of a single byte and defines the type and format of the Payload field. The bit definition of the Control byte is shown in Figure 4. The Control field also serves, in conjunction with the Synch, Length and FCS fields, as a packet delimiter as described in Section 2.4. Figure 4: MAC Header Control Byte – Bit Definition Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 RSVD3 RSVD2 RSVD1 RSVD0 Protocol 2.3.2.1 Protocol (Bits 3:0) The four-bit protocol field indicates the type of protocol to be used to interpret the payload field of the MAC layer packet. In addition, the protocol field allows the message service handler to pass messages with alternative protocol values to other upper layer processes without having to unravel the entire message. The value represented by the protocol field shall be as assigned in Table 4. Table 4: Protocol Field Values Description Binary Value MAC Management Message 0000 SNMP over Serial (see note below) 0001 IP over Serial 0010 SNMP Trap over Serial 0011 Available for Future Use 0100 to 1111* *Protocol 0101 is not allowed to prevent accidental creation of a Synch byte (0xA5). Note This is SNMPv1 as defined by RFC 1157. However, the UDP and IP protocols are not used for this implementation. Thus, all references by RFC 1157 to UDP are not relevant. Section 3.2.4 of RFC 1157 explains how the SNMP mechanisms are suitable over different transport protocols. Sections 4 and 4.1 of RFC 1157 explain this further. In fact, in Section 4.1, the RFC states: “Other transport services may be used to support the SNMP.” 2.3.2.2 RSVDx (Bits 7:4) The bits identified as RSVD are reserved for future use. They must be set to 0. 15 2.3.3 Address The Address field consists of six bytes. It is used to address devices on a unicast, multicast, or broadcast basis. The address field follows the IEEE Organizationally Unique Identifier (OUI) Std 802 usage for a Universal address. For clarity, this document conforms to the address documentation suggested by the IEEE as follows: 1. Each byte is represented as a two digit hexadecimal numeral (with no radix identification) using leading zeroes where the first (left-most) digit of the pair is the most significant. 2. Each byte is separated by hyphens, with the most significant byte in the left-most position. An example address is 00-AA-BB-00-43-21. A Universal address is a sequence of six bytes. The first three take the values of the three bytes of the OUI in order. The last three bytes are administered by the assignee. The binary representation of an address is formed by taking each byte in order and expressing it as a sequence of eight bits, LSB to MSB, left to right. For example, the OUI AC-DE-48 could be used to generate the address AC-DE-48-00-00-80 Whose binary representation is: First Byte Second Byte Third Byte of OUI of OUI of OUI 0011 0101 0111 1011 0001 0010 0000 0000 0000 0000 0000 0001 | I/G Address Bit | | | | | | | | | | | | LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB C A E D 8 4 0 0 0 0 0 8 The first (left-most) bit in the binary representation of the MAC address is the I/G (Individual/Group) Address Bit. This bit is the LSB of the most significant byte. When set to 0 as shown above, it indicates an individual address. It may be set to 1 in an address allocated by the assignee to indicate that that address is a group address. For example, the same OUI above could be used to generate the Group Address AD-DE-48-00-00-80 First Octet Second Octet Third Octet of OUI of OUI of OUI 1011 0101 0111 1011 0001 0010 0000 0000 0000 0000 0000 0001 | I/G Address Bit | | | | | | | | | | | | LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB D A E D 8 4 0 0 0 0 0 8 16 The address shall be transmitted most significant byte first and least significant byte last. 2.3.3.1 Unicast The Unicast address is the unique address assigned to a particular NE. An NE transmitting a message places its unicast address in the Address field, most significant byte first. This address is completely unique across all manufacturers. By definition, the I/G bit is set to 0. Each vendor shall obtain an address prefix, or OUI, from the IEEE and assign a unique address using this prefix to each HMS-compliant transponder at time of manufacture. This is the Unicast address for that NE. This document places no restriction on the number of OUIs a single manufacturer may obtain as the IEEE governs that. An OUI assignment allows the assignee to generate approximately 16 million addresses by varying the last three octets. 2.3.3.2 Broadcast A message with a Broadcast address is intended for all NEs that receive it. All NEs must support the Broadcast address. The Broadcast address is FF-FF-FF-FF-FF-FF. 2.3.3.3 Multicast The Multicast address follows the IEEE Std 802 for indicating a Group Address; i.e., the I/G Address Bit is set to 1. A Multicast address defines a group to which zero, one, or more than one NE has been assigned by a higher level management system. A NE maintains a list of multicast addresses to which it will respond. A NE is a member of a particular multicast group if at least one of its provisioned multicast addresses matches that particular multicast address. The assignment and usage of multicast addresses is out of the scope of this specification. However, examples might be fault isolation, frequency changes, and firmware downloads. All NEs must support a minimum of four (4) multicast addresses not counting the Broadcast address. This specification places no maximum limit on the number of multicast address groups a NE may support. Multicast addresses are not assigned at manufacture. The network provider provisions multicast addresses into the NE. The method for this provisioning is out of the scope of this specification. To avoid accidental assignment to the wrong multicast address, all multicast addresses held at the NE shall default to the Broadcast address prior to provisioning. 2.3.4 Sequence The HMS MAC protocol is transaction-based; i.e., every originating message from a “requestor” has a corresponding response from the “responder” regardless of which device originated the message. The Sequence field consists of a single byte and defines a message sequence number to ensure message exchanges are synchronized. In order to handle possible loss of messages in either the forward or the return channel, and to avoid duplication of messages at the application 17 layer, all messages have a sequence number. The bit definition of the Sequence byte is shown in Figure 5. Figure 5: MAC Header Sequence Byte – Bit Definition Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 SYN MSGSEQ 2.3.4.1 MSGSEQ (Bits 6:0) The 7-bit MSGSEQ field indicates the message sequence number. Sequence numbers are generated by either the HE or NE. Sequence number generation, modification and elicited behavior must conform to the following rules: 1. HE-originated transactions will have bit 6 of the MSGSEQ field set to 1. Thus, the range for HE-generated sequence numbers is 0x40 through 0x7F with wraparound to 0x40. 2. The HE shall generate and track sequence numbers per unicast address. 3. HE-generated messages directed to broadcast or multicast addresses; i.e., where the I/G bit is set to 1, shall have a sequence number of 0 since this field is ignored by the NE for multicast and broadcast messages. Upon receiving a valid broadcast or multicast message from the HE, the NE shall not change the last received HE sequence number. The NE shall always process broadcast or multicast messages regardless of sequence number. 4. NE-originated transactions will have bit 6 of the MSGSEQ field set to 0. Thus, the range for the NE is 0x00 through 0x3F with wraparound to 0x00. 5. As a requestor, the NE can have only a single originating message requiring a response outstanding at any time (see Section 3.8). Thus, the NE only needs to track the sequence number for this single value. 6. The MSGSEQ field is incremented by the originator of the number. The sequence number shall be incremented only: a. When a response is received with a matching sequence number (excluding the SYN bit, see Section 2.3.4.2); or b. When a requestor’s maximum allowed number of MAC layer transmission retries has been exceeded. The MSGSEQ shall not change if a message must be retransmitted at the MAC layer, which occurs only when a response or acknowledgement has not been received within a pre-determined timeout window, and the maximum allowed number of MAC layer transmission retries for this message has not been exceeded. See Section 3 of this specification for additional details on MAC protocol operation. 18 7. The responding entity shall save the sequence number of the last received message directed to its unicast address and perform one of the following: a. If the MSGSEQ field is different from the last one seen, the responder should process the message, form a response if one is required, and send it. The responding entity shall take the value of the sequence number in the MSGSEQ field from the request and place it in the MSGSEQ field of its response. b. If the MSGSEQ field is the same as the last one seen, the responder knows that its last response was not received and it should resend the response. The responder should not process the message again. It must simply resend the previously transmitted message. The responding entity shall take the value of the sequence number in the MSGSEQ field from the request and place it in the MSGSEQ field of its response. 8. If the responding entity has been reset, it shall process the first received message directed to its unicast address regardless of the value in the MSGSEQ field. Note: A possible implementation refinement to ensure subsequent message exchanges are synchronized is to initialize the “last sequence number” to an out-of-range value that a requestor cannot possibly support. This would guarantee that the first message from a responder after a reset always has a unique sequence number associated with it that forces the requestor to re-issue the original request thus ensuring message exchange re-synchronization. 2.3.4.2 SYN (Bit 7) The following rules govern the selection of the SYN bit value and elicited behavior: 1. After a device (HE or NE) is reset, it shall set the SYN bit to 1 in every packet it originates and sends to a given responder until the first correct response is received from that responder. When the SYN bit is set to 1 by a requestor, the responder is not to verify the MSGSEQ field in the message. The MSGSEQ field contained within the packet is to be used by the requestor as the last received value. This will synchronize the responder to the current requestor sequence number. 2. The SYN bit shall always be set to 0 when responding to a request. When the SYN bit is set to 0 by a requestor, the responder is to verify the MSGSEQ field in the packet. Section 3 of this specification provides additional information on the use of the Sequence field. It also includes a sample message exchange for illustration purposes. 2.3.5 Length The Length field consists of two bytes and specifies the number of bytes in the payload field of the MAC layer packet. Although the theoretical maximum payload length is 65,535 bytes, the absolute maximum message length that may be transmitted (including all message overhead and Synch byte padding) will be determined by the maximum duration of return channel transmissions before automatic RF transmission cutoff is invoked. Document SCTE 25- HMS 19 Outside Plant Status Monitoring – Physical (PHY) Layer Specification v1.0 requires that HMS- compliant transponders support automatic RF transmission cutoff on the return channel to shut down transponders that have failed with their transmitter ON. An implementation of this protocol need not accept messages whose length exceeds 484 bytes. However, it is recommended that implementations support larger messages whenever feasible. Synch bytes inserted in the payload do not count towards the message length. See Section 2.4.3. 2.3.6 Payload The payload field contains the data delivered to/from the higher layer protocols. 2.3.7 Frame Check Sequence (FCS) The FCS field consists of two bytes. It is CCITT CRC-16 as documented in RFC 1662, appendices C.1 and C.2. The CRC calculation is performed over the entire packet, excluding the Synch field, but including the Control, Address, Sequence, Length, and Payload fields. Synch byte insertions for achieving transparent throughput of all data (see Section 2.4.3) are NOT included in the CRC calculation. The final value obtained from the CRC calculation is complemented and transmitted least significant byte first. The following example illustrates this convention (sample forward path message, all values in HEX): A5 00 00 10 3F 00 43 21 49 00 01 02 1D 1C The FCS for this message is calculated to be 0xE3E2. When complemented, the value is 0x1C1D. This is then transmitted least significant byte first (0x1D, 0x1C). 2.4 MAC Packet Delimiters The Synch, Control, Length and FCS fields are used to delimit a packet and indicate its integrity. 2.4.1 Packet Start Detection of a Synch byte followed by a non-Synch byte will identify the start of a packet. Characters received after the end of a packet (see Section 2.4.2) but prior to detection of a new Synch byte and a non-Synch byte combination shall be discarded. 2.4.2 Packet End The exact location of the FCS and the end of the packet can be calculated from the Length byte. The integrity of the packet is checked using the FCS. Packets with an invalid FCS shall be discarded. Packets with a valid FCS, but with invalid content will also be discarded. 20 2.4.3 Synch Byte Padding In order to ensure message synchronization and obtain data transparency in the message, it is necessary to distinguish a true Synch byte from any other byte in the payload that has the same value. To accomplish this, a transmitting device (NE or HE) will insert the synch byte after any data byte having a value of 0xA5. This rule shall apply to the Address, Sequence, Length, Payload, and FCS fields but not to the Synch and Control fields. This ensures that the Synch byte and non-Synch byte combination will never be found together in the remainder of the packet. After detection of the start of a packet, the receiver of the packet will remove one synch byte from any two-byte sequence that contains back-to-back synch bytes [0xA5, 0xA5]. If a single synch byte is detected within the packet, the data up to that point shall be discarded and the receiver shall begin the packet delimitation process again, using the newly received 0xA5 as the start of packet indicator. Synch bytes added for data transparency are not counted toward the length of the packet, and are not included in the FCS calculation for a packet by either the sender or the receiver. 21 2.5 MAC Protocol Data Units (PDUs) MAC PDUs are contained in the Payload field of the message. MAC PDU structure is illustrated in Figure 6. Figure 6: MAC PDU Structure Payload Payload+1 Payload+n CMD Data Data Data Data Data The presence of the Data fields depends on the PDU. The PDUs defined for the MAC layer are listed in Table 5. Since all MAC layer messages are transaction-based, a list of possible transactions is shown in Table 6. Table 5: MAC PDUs PDU Name CMD Section NAK 0x00 2.5.1 ACK 0x01 2.5.2 STATRQST 0x02 2.5.3 STATRESP 0x03 2.5.4 TALKRQST 0x04 2.5.5 TALK 0x05 2.5.6 CONTMODE 0x06 2.5.7 REG_REQ 0x07 2.5.8 SET_ADDR 0x08 2.5.9 REG_END 0x09 2.5.10 CHNLDESC 0x0A 2.5.11 INVCMD 0x0B 2.5.12 TIME 0x0C 2.5.13 22 Table 6: Possible MAC Protocol Transactions Originator PDU Responder Possible Responses HE STATRQST NE STATRESP HE CONTMODE NE ACK or INVCMD HE TALK NE NAK REG_REQ INVCMD Non-MAC protocol message HE SET_ADDR NE ACK INVCMD HE REG_END NE ACK or INVCMD HE CHNLDESC NE ACK or INVCMD HE TIME NE ACK NE TALKRQST HE ACK All of these MAC transactions can be processed by the NE before the NE is registered. The only message restriction at this time is that SNMP traps shall not be transmitted by the NE prior to registration completion as signaled by reception of a successful REG_END PDU from the HE (see Section 2.5.10). Additionally, there is no restriction on SNMP Get, GetNext, and Set requests. 2.5.1 NAK The NAK PDU is a possible NE response to the HE TALK PDU. The NAK PDU has the format shown in Table 7. Description of the use of this message can be found in Appendix A, Section A.5.5. Table 7: NAK PDU Format Field Size (bytes) Value CMD 1 0x00 2.5.2 ACK The ACK PDU can be originated by the HE or the NE. The ACK PDU has the format shown in Table 8. Table 8: ACK PDU Format Field Size (bytes) Value CMD 1 0x01 23 Only unicast addresses can be used with the ACK PDU. Additional details on the use of the ACK PDU can be found in Appendix A, Section A.5.5. 2.5.3 STATRQST The STATRQST PDU is originated by the HE. The expected response is a STATRESP PDU. The STATRQST PDU has the format shown in Table 9. Table 9: STATRQST PDU Format Field Size (bytes) Value CMD 1 0x02 Only unicast addresses can be used with the STATRQST PDU. 2.5.4 STATRESP The STATRESP PDU is the NE response to a HE STATRQST PDU. The STATRESP PDU has the format shown in Table 10. The STATRESP PDU has a one-byte STATUS Data field associated with it. The STATUS Data field bit definition is shown in Figure 7. Table 10: STATRESP PDU Format Field Size (bytes) Value CMD 1 0x03 STATUS 1 See Figure 7 Figure 7: STATRESP STATUS Byte – Bit Definition Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 RSVD3 RSVD2 RSVD1 MINOR MAJOR CNTCUR CNTNRM CHNLRQST Note that this STATUS byte is identical to the commonNEStatus variable defined in document SCTE 38-3, HMS Common Management Information Base. 24 2.5.4.1 CHNLRQST (Bit 0) The CHNLRQST bit indicates when the NE has unsolicited messages it wants to transmit to the HE. See Table 11 for the bit value definitions. See Figure 9 for the state diagram governing the actions and usage of contention. Table 11: CHNLRQST Bit Settings Value Meaning 0 NE has no unsolicited messages to transmit. 1 NE has unsolicited messages that will be transmitted when the return channel is allocated a transmit opportunity with a TALK PDU, as permitted by the registration state. Until a NE is registered, only a REG_REQ PDU can be generated (see Section 2.5.8). After successful registration (REG_END with SUCCESS status, see Section 2.5.10), the CHNLRQST bit shall be set for any non-MAC messages that are to be transmitted (e.g., SNMP Traps). 2.5.4.2 CNTNRM (Bit 1) The CNTNRM bit indicates the “normal” state of contention, as set by the last CONTMODE PDU message (see Section 2.5.7). See Table 12 for the bit value definitions. Table 12: CNTNRM Bit Settings Value Meaning 0 The “normal” mode of contention is OFF for this NE. 1 The “normal” mode of contention is ON for this NE. 2.5.4.3 CNTCUR (Bit 2) The CNTCUR bit indicates the “current” state of contention, as set by the last CONTMODE PDU message (see Section 2.5.7). See Table 13 for the bit value definitions. Table 13: CNTCUR Bit Settings Value Meaning 0 Contention is OFF for this NE. 1 Contention is ON for this NE. 2.5.4.4 MAJOR (Bit 3) The MAJOR bit indicates whether alarms with a major severity are present in the NE or in the equipment monitored by the NE. See Table 14 for the bit value definitions. 25 Table 14: MAJOR Bit Settings Value Meaning 0 No alarms with MAJOR severity are present. 1 Alarms with MAJOR severity are present. 2.5.4.5 MINOR (Bit 4) The MINOR bit indicates whether alarms with a minor severity are present in the NE or in the equipment monitored by the NE. See Table 15 for the bit value definitions. Table 15: MINOR Bit Settings Value Meaning 0 No alarms with MINOR severity are present. 1 Alarms with MINOR severity are present. 2.5.4.6 RSVDx (Bit 7:5) The bits identified as RSVD are reserved for future use. They must be set to 0. 2.5.5 TALKRQST The TALKRQST PDU is originated by a NE. The expected HE response is the ACK PDU. The TALKRQST PDU has the format shown in Table 16. Table 16: TALKRQST PDU Format Field Size (bytes) Value CMD 1 0x04 The TALKRQST is transmitted by the NE only under the following conditions: 1. The NE must have unsolicited messages that it wants to transmit. 2. Contention mode must be in the ON state for the NE (CC = 1). See Section 2.5.7. Once an ACK PDU response has been received, the TALKRQST PDU can be transmitted again in either of two cases: 1. The current contention mode of the NE has been toggled OFF then ON again using the CONTMODE PDU (effectively a new contention period, see Section 2.5.7). In this case, the TALKRQST PDU can be transmitted again since the CHNLRQST bit (Bit 0 in Status byte of the STATRESP PDU) is still set; or 26 2. The NE transmitted a NAK PDU in response to a TALK PDU; i.e., the last time the NE was given permission to transmit it had no more messages to send (see Section 2.5.6). In this case the NE, which previously had no more messages to transmit, now has new outstanding messages and is permitted to generate a new TALKRQST PDU. 2.5.6 TALK The TALK PDU is originated by the HE. The expected NE responses are: 1. NAK PDU (no more messages to transmit). 2. Non-MAC protocol message (e.g., SNMP Trap over Serial). 3. REG_REQ PDU (NE requesting registration, see Section 2.5.8). The TALK PDU has the format shown in Table 17. The TALK PDU has a one-byte ACKSEQ Data field associated with it. Table 17: TALK PDU Format Field Size (bytes) Value CMD 1 0x05 ACKSEQ 1 See text The TALK PDU gives the addressed NE access to the return channel to transmit a single message. In typical usage, the HE issues a CONTMODE PDU to turn off contention mode, then issues the TALK PDU to give the clear return channel to the NE. See the transaction example illustrated in Table 20. The ACKSEQ field of the TALK PDU contains the sequence number of a previous message that this packet is acknowledging. In the situation where the HE has no previous message to acknowledge, the ACKSEQ field shall be 0xFF. If the message sequence number in the ACKSEQ data field of the TALK PDU does not match the expected number, the NE shall respond with the INVCMD PDU using the “Invalid parameter” error code (see Section 2.5.12). The expected HE behavior would then be to re-issue a TALK PDU. The ACKSEQ byte in the TALK PDU will have a sequence number of 0xFF to indicate that the HE lost track of the sequence numbers. This will cause the NE to retransmit its last response to the HE TALK PDU allowing the HE to resynchronize correctly. 2.5.7 CONTMODE The CONTMODE PDU is originated by the HE. The CONTMODE PDU has the format shown in Table 18. The CONTMODE PDU has two Data fields associated with it: the MODE field and the DURATION field both of which are one byte in length. 27 Table 18: CONTMODE PDU Format Field Size (bytes) Value CMD 1 0x06 MODE 1 See Table 19 DURATION 1 Time duration of CC = 1 2.5.7.1 CONTMODE:MODE The MODE field determines the contention state for the addressed NEs. The expected NE response to the CONTMODE PDU is an ACK PDU only if a unicast address is used and the MODE value is one of those in Table 19 (even if the MODE value is not applicable). An INVCMD PDU response shall be transmitted if a unicast address is used and the mode value is not one of those shown in Table 19. Table 19: CONTMODE:MODE Settings Value Meaning 0 (OFF) Contention is turned OFF for the addressed NEs. CN = 0, CC = 0. DURATION has no effect. 1 (ON) Contention is turned ON for the addressed NEs. CN = 1, CC = 1. DURATION is meaningful. 2 (INH) Contention is inhibited for the addressed NEs. CN = unchanged, CC = 0. DURATION has no effect. 3 (RES) Contention is restored for the addressed NEs. CN = unchanged, CC = CN. DURATION is meaningful for NEs with CN = 1. 4 (REG) Contention is enabled for non-registered NEs. CN = 0, CC = 1. DURATION is meaningful for these NEs. Contention is inhibited for all registered NEs. CN = unchanged, CC = 0. DURATION has no effect for these NEs. Cc: Contention mode “current” – the setting of this flag controls whether or not contention is currently enabled or disabled for the NE. A value of 0 means that the NE is not permitted to send the TALKRQST PDU. CN: Contention mode “normal” – the setting is restored with the MODE value of 3. This flag is changed only with the OFF and ON MODE values. Upon NE power up for the first time or NE reset, the state of these flags shall be CN = 0, CC = 0 Figure 9 in section 3.10.1 illustrates the applicable state machine diagrams and describes how these modes are to be used in the NE. If a MODE value is valid, but not applicable in a given state (as shown in the state diagram), it shall not be processed. However, if the NE was addressed using a unicast address it shall respond with an ACK PDU. Table 20 illustrates the use of the CONTMODE PDU in the case of a NE with three messages to send. The value in parentheses for the TALK PDU is the value of the ACKSEQ field. 28 Table 20: NE Message Retrieval Example HE Message To/From NE Message MODE Sequence Sequence Value Number Number CONTMODE ON 00 -> * 1 <- A TALKRQST 15 1 ACK 15 -> A 1 CONTMODE INH 00 -> * 0 TALK (0xFF) 43 -> A 0 <- A SNMP Trap 1 43 0 CONTMODE RES 00 -> 1 1 <- A TALKRQST 16 1 ACK 16 -> A 1 TALK (0x43) 44 -> A 1 <- A SNMP Trap 2 44 1 TALK (0x44) 45 -> A 1 <- A SNMP Trap 3 45 1 TALK (0x45) 46 -> A 1 <- A NAK 46 1 New alarm occurs 1 2 <- A TALKRQST 17 1 ACK 17 -> A 1 Case 1: New contention window 2 Case 2: New alarms after a NAK, same contention window 2.5.7.2 CONTMODE:DURATION When a CONTMODE PDU is issued which changes the state of CC to 1, the DURATION field specifies the number of seconds that this mode will be active. Specifically, the DURATION field has meaning for the ON, RES, and REG modes. This field has no meaning when the state of CC will be set to 0. Note that if a RES mode is issued and CC is set to 0, the DURATION field, though valid, has no effect. A value of 0 in the DURATION field indicates unlimited time. If the duration timer is active; i.e., a previous CONTMODE PDU with MODE setting and DURATION value has started the timer, and a new CONTMODE PDU with a new MODE setting and DURATION field is received, the timer is restarted using the new DURATION field value. The duration timer acts as a “master shutoff” meaning that once the DURATION period expires a state change to CC = 0 occurs. This action is identical to using all MAC layer transmission retries (see Section 3). When this occurs, the NE shall not transmit any further TALKRQST packets. Note that any CONTMODE PDU which explicitly sets CC = 0 prior to the expiration of the DURATION period will have the same effect. The DURATION field protects against the possibility of the HE transmitting a CONTMODE PDU setting CC = 0 that is not received by the NE. In this case, the DURATION field and timer- 29 activated shutoff action provides a NE-based failsafe backup mechanism to prevent unwanted transmissions. 2.5.8 REG_REQ The REG_REQ PDU can be generated by a NE in response to the TALK PDU. The REG_REQ PDU has the format shown in Table 21. The REG_REQ PDU has a four-byte IP_ADDRESS Data field associated with it. Table 21: REG_REQ PDU Format Field Size (bytes) Value CMD 1 0x07 IP_ADDRESS 4 IP Address programmed into the NE (IPv4 only) The NE transmits the REG_REQ only after it “boots” (power-up, hard or soft reset, etc.) The NE uses this message to register it in the system. This message may be transmitted only when the contention state is non-REG (see Figure 9). Note that if a REG_END PDU is received when this message is waiting to be transmitted, it will cause the NE to cancel the transmission of this message (see Section 2.5.10). See Section A.7 for more details about the Auto-Registration process. 2.5.9 SET_ADDR The SET_ADDR PDU is originated by the HE. The expected NE response is the ACK PDU. The SET_ADDR PDU has the format shown in Table 22. The SET_ADDR PDU has a four- byte IP_ADDRESS Data field associated with it. Table 22: SET_ADDR PDU Format Field Size (bytes) Value CMD 1 0x08 IP_ADDR 4 Appropriate The HE transmits the SET_ADDR command to set the IP address of the NE. The value for IP_ADDR can be either: 1. Address 0.0.0.0 for a NE in a proxy system; or 2. A real IP address. How this IP address is determined or obtained by the HE is beyond the scope of this document. This could be the IP address received with the REG_REQ PDU; i.e., the HE is setting the NE to the IP address already programmed into the NE; or 3. The IP address of the HE (only in a proxy system). 30 The following ranges of IP addresses are reserved and define sets of invalid IP addresses for the NEs: 1. 224.0.0.0 – 239.255.255.255. This address range is reserved for IP multicast addresses (Class D); and 2. 240.0.0.0 – 255.255.255.255. This address range is reserved for future use (Class E). The IP address of the NE must not be set within any of the above ranges. Only unicast MAC addresses may be used with this command. The NE must discard a SET_ADDR command if a MAC multicast address or the MAC broadcast address is used. The NE shall respond with an INVCMD PDU if any of the following occurs: 1. If the NE was unable to set its IP address as indicated, the NE shall respond with an INVCMD PDU with the “Undefined error” value (see Section 2.5.12). Note that this does not imply anything about the validity of the IP address, but rather the ability of the NE to save the IP address in non-volatile memory; or 2. If the NE is commanded to set its IP address to an invalid IP address, the NE shall respond with an INVCMD PDU with the “Invalid parameter” value (see Section 2.5.12). 2.5.10 REG_END The REG_END PDU is originated by the HE. The expected NE response is the ACK PDU. The REG_END PDU has the format shown in Table 23. The REG_END PDU has two data fields associated with it: a one-byte STATUS field and a four-byte TOD field. Table 23: REG_END PDU Format Field Size (bytes) Value CMD 1 0x09 STATUS 1 See Table 24 TOD 4 Time of day in POSIX format, most significant byte first 2.5.10.1 REG_END:STATUS The REG_END PDU is transmitted by the HE upon completion of NE registration. The STATUS field indicates NE registration status. Defined STATUS field settings are shown in Table 24. Table 24: REG_END:STATUS Settings Value Meaning 0 SUCCESS. Registration succeeded. The NE shall continue its startup sequence. 31 1 DENIED. Registration has been denied. The NE may optionally use the CHNLDESC PDU mechanism (see Section 2.5.11) to search for another channel, or it may request registration on this channel again. 2 FAILED. Registration failed. The NE must wait until the next registration opportunity (CONTMODE REG). 3 PENDING. Registration is pending. The NE has found the correct HE but the HE is not yet ready to process this NE. The NE shall not send any further registration requests. The NE shall not send any SNMP Traps or perform alarm processing. Receipt of the REG_END PDU with a STATUS value of 0 (SUCCESS) shall change the contention state to REG (see Table 19 and Figure 9). Additionally, if the NE has a pending REG_REQ PDU waiting to be transmitted, receipt of the REG_END will clear this pending request. The NE shall be permitted to send SNMP Traps and may perform alarm processing only upon receiving a STATUS of 0 (SUCCESS). If a REG_END PDU with STATUS of 3 (PENDING) is received by the NE, the NE must still wait for reception of a REG_END PDU message with STATUS of 0 (SUCCESS). Upon reception of a REG_END PDU with a status of PENDING, the NE shall remain in that state for a maximum period of one hour. At the end of that time, if the NE is still in that state, it shall return to the non-registered OFF state. Upon reception of a REG_END PDU with a status of SUCCESS, the NE shall not recognize any further REG_END PDU commands. If a unicast address was used, the transponder shall respond with an INVCMD PDU with the “Invalid parameter” error code (see Section 2.5.12). 2.5.10.2 REG_END:TOD The TOD field shall contain the time in POSIX format (see Section A.2) with the most significant byte first. The NE is required to synchronize its internal time-of-day clock to this time. This field is always valid regardless of the value of the STATUS field. 2.5.11 CHNLDESC The CHNLDESC PDU is originated by the HE. The expected NE response (unicast address only) is the ACK PDU. The CHNLDESC PDU has the format shown in Table 25. The CHNLDESC PDU has two Data fields associated with it: the FORWARD field and the RETURN field both of which are four bytes in length. Table 25: CHNLDESC PDU Format Field Size (bytes) Value CMD 1 0x0A FORWARD 4 Forward channel frequency in use for this channel (center frequency in Hz) 32 RETURN 4 Return channel frequency in use for this channel (center frequency in Hz) The CHNLDESC is transmitted by the HE under any of the following conditions: 1. Periodically, at least every 30 seconds, with a +5 second tolerance, using the broadcast address. This is used by the NE to automatically find the proper forward and return channels in use. 2. Anytime forward or return channel frequencies are changed. In this case, it is recommended that the message be transmitted several times in sequence. There are no address restrictions in this mode. If a unicast address is used, the NE must send an ACK PDU in response. The NE shall always process this PDU if it belongs to the addressed group. If either of the frequencies specified in the PDU are invalid for the NE, then: 1. The NE shall not change either frequency; and 2. If a unicast address was used, the NE will reply with the INVCMD PDU using the “Invalid parameter” error code (see Section 2.5.12). The NE shall implement a failsafe mechanism to recover from loss of forward channel frequency due to a requested frequency change. The recovery method used shall be determined by the vendor. The method used to determine loss of forward frequency shall also be determined by the vendor. 2.5.12 INVCMD The INVCMD PDU can be originated by the NE in response to a command from the HE. This message is transmitted only if a unicast address was used in the original message. The INVCMD PDU has the format shown in Table 26. The INVCMD PDU has a one-byte REASON Data field associated with it. Table 26: INVCMD PDU Format Field Size (bytes) Value CMD 1 0x0B REASON 1 Reason code (see Table 27) 2.5.12.1 INVCMD:REASON This message is transmitted by the NE with the REASON field indicating various error conditions. Defined REASON field codes are listed in Table 27. 33 Table 27: INVCMD:REASON Codes Value Meaning Response To 0x00 Undefined error CHNLDESC: Unable to execute* SET_ADDR: Unable to execute* 0x01 Invalid parameter CHNLDESC: Invalid frequencies CONTMODE: Invalid MODE TALK: Invalid ACKSEQ number REG_END: Invalid STATUS SET_ADDR: Invalid IP address *Parameters are valid but the transponder cannot execute the command for other reasons (e.g., non-volatile write did not succeed) 2.5.13 TIME The TIME PDU is originated by the HE at its discretion. The expected NE response is an ACK PDU only if a unicast address is used. The TIME PDU has the format shown in Table 28. The TIME PDU has a four-byte TOD Data field associated with it. Table 28: TIME PDU Format Field Size (bytes) Value CMD 1 0x0C TOD 4 Time of day in POSIX format, most significant byte first 2.5.13.1 TIME:TOD The TOD field shall contain the time in POSIX format (see Section A.2) with the most significant byte first. The NE is required to synchronize its internal time-of-day clock to this time. 34 3 MAC Protocol Operation This section covers key operational characteristics to support the interaction between HMS- compliant transponders that interface to OSP NEs and a centralized HE. These procedures are critical to ensure interoperability among multiple NEs. 3.1 Non-Volatile Parameters The parameters listed in Table 29 must be stored in non-volatile memory for proper initialization of the NE after a power failure. Note that this list is not exhaustive; it simply gives the minimal parameters required for operation after a reset. Table 29: Non-Volatile Parameters Parameter Forward channel frequency Return channel frequency Return channel power MAC Address IP Address k parameter (to calculate backoff period before attempting a new transmission in contention mode, see Section 3.8.5) The IP Address is inserted into the SNMP Trap message in the appropriate field. 3.2 Duplex Capabilities All NEs shall support half-duplex operation. There is no requirement for full-duplex operation. 3.3 Packet Priorities The MAC layer shall treat all packets with equal priority regardless of protocol. Both the HE and the NEs shall transmit packets on a first-in, first-out (FIFO) basis. 3.4 Packet Reception The receiving device (NE or HE) looks for a proper Synch byte followed by a non-Synch byte combination to indicate the start of a packet. Data is discarded until a proper packet start is found. Once a proper packet start is identified, packet length is determined using the Length field, reception is completed and the FCS is calculated on the incoming data. The calculated FCS is compared to the transmitted FCS. If they match, the packet is declared valid and passed on to the appropriate higher layer protocol. If the calculated FCS does not match the transmitted FCS, the packet is discarded. If the FCS is valid, but subsequent decoding of the message shows invalid contents, the packet is discarded. Synch bytes added for data transparency are not counted toward the length of the packet, and are not included in the FCS calculation for a packet by either the sender or the receiver. 35 3.5 NE Responses 3.5.1 NE Processing Times – Broadcast and Multicast Messages The NE shall never respond to any message containing a MAC address with the I/G Address Bit set to 1. This indicates either a multicast addresses or the broadcast address. However, if the contention state for the NE is turned ON as a result of such a message, the NE is permitted to send TALKRQST messages until the contention state is reset. Processing times for messages received at the NE must conform to the following rules: 1. A NE must be able to process a packet 250 ms after reception of a MAC packet with the I/G Address Bit set to 1. See Section 2.3.3 for details about addresses. 2. A NE must be able to process a packet 5 s after reception of a SNMP packet with the I/G Address Bit set to 1. 3.5.2 NE Response Times – Unicast Messages When a NE receives a MAC PDU management message (protocol identifier 0000) addressed to its unicast address and that requires a response, the NE shall begin to respond within 15 ms; i.e., transmit the first byte of its response. This interval begins following the receipt of a valid forward channel packet and ends when transmission of the response begins on the return channel. If a NE does not respond to a MAC management message within 15 ms; i.e.: it times out, the HE can assume that the NE will not respond to this particular message. The HE may then initiate an error handling procedure which may attempt to contact the NE again or other NEs around it in the network, or it may invoke other such actions that the HE vendor deems appropriate. Any time the NE receives a non-MAC PDU management message; i.e., a message with protocol identifier other than 0000, addressed to its MAC unicast address and that requires a response, the NE shall begin to respond within five seconds, i.e.: the timeout period shall be five seconds. 3.6 Message Sequence Numbers and Transaction Synchronization The HMS MAC protocol is transaction-based; i.e., every originating message from a “requestor” has a corresponding response from the “responder” regardless of which device originated the message. The Sequence field in all HMS MAC packet headers consists of a single byte and defines a message sequence number to ensure message exchanges are synchronized. In order to handle possible loss of messages in either the forward or the return channel, and to avoid duplication of messages at the application layer, all messages have a sequence number. The Sequence field in all HMS MAC packet headers and the rules governing its use are described in detail in Section 2.3.4. In addition, this HMS MAC specification also defines a one-byte ACKSEQ Data field associated with the MAC TALK PDU (see Section 2.5.6). The ACKSEQ field in the TALK PDU identifies 36 the sequence number of a previous message that this packet is acknowledging. The HE uses the TALK PDU to give the addressed NE access to the return channel to transmit a single message while also acknowledging reception of the previous message the NE transmitted. Table 30 illustrates an example of the usage of the Sequence field in the HMS MAC packet headers and the ACKSEQ Data field associated with the MAC TALK PDU. The Event column is for reference only. The value in parentheses for the TALK PDU is the value of the ACKSEQ field. Table 30: MAC Sequence Field Example (Non-Contention Mode) Event HE Message NE Message Sequence Sequence Number Number 1 STATRQST x40 -> 2 <- STATRESP x40 CHNLRQST = 1 4 3 TALK (0xFF) x41 -> 4 <- SNMP Trap 1 x41 1 5 TALK (0x41) x42 -> 1 6 <- SNMP Trap 2 x42 2 7 TALK (0x42) x43 -> Forward path message lost 2 8 Timeout 2 9 TALK (0x42) x43 -> 10 <- SNMP Trap 3 x43 11 TALK (0x43) x44 -> 3 12 Return path <- SNMP Trap 4 x44 message lost 3 13 Timeout 3 14 TALK (0x43) x44 -> 15 <- SNMP Trap 4 x44 16 TALK (0x44) x45 -> 17 <- NAK x45 1 Normal case: The sequence number is different from the last one seen, so the NE will increment its internal pointer to the next message to be transmitted. 2 The NE did not see this message at all, so the transaction does not complete. The HE must retransmit its message using the same sequence number. 3 The Trap was lost in the return path. The HE times out, but does not know which message (forward path or the return path) was lost. Retry of the TALK is required. The NE will see that the sequence number is the same as the last one, so it will simply resend its last message. 4 The HE has no previous message to acknowledge, so the value of the ACKSEQ field is 0xFF 3.7 Solicited Messages Solicited messages are packets that are sent in response to a HE query. The HE does not transmit an ACK PDU in response to these packets. 37 3.8 Autonomous (Unsolicited) Messages Autonomous, or unsolicited messages, are packets that are generated automatically by the NE; e.g., the result of an unexpected alarm condition occurring at the NE. A NE must signal the HE with the TALKRQST PDU when the NE Contention state is ON (CC = 1). Only the TALKRQST PDU is permitted when the NE Contention state is ON and no alarm information is transmitted since delivery to the HE is not guaranteed (collisions may occur). The HE must send an ACK message back to the NE when it receives a TALKRQST PDU. Only a single packet requiring an ACK response may be outstanding at the NE at any time. Retry packets are retransmissions of previously sent autonomous messages for which an ACK PDU was not received. Sections 3.8.1 through 3.8.7 describe how autonomous messages and collisions are handled in this MAC. 3.8.1 NE Contention State Each NE has a Contention state (CC). The Contention state indicates the following: 1. Contention state is ON: The NE is permitted to transmit unsolicited messages on the return channel. 2. Contention state is OFF: The NE may transmit only solicited messages. It cannot transmit unsolicited messages. At NE boot, the NE Contention state is initialized to OFF. The Contention state for a NE is determined by: 1. The address used to access this NE (unicast, multicast, or broadcast); and 2. The value of the MODE field in the CONTMODE PDU that addressed this NE. Refer to Section 2.5.7. The contention state setting is persistent across forward path transmissions. See Table 31. 38 Table 31: Contention State Settings versus Forward Channel Packets Forward Path CONTMODE NE Contention State CC Message Address MODE Value NE X NE Y NE Z 1 Broadcast 0 (off) OFF OFF OFF 2 Unicast X 0 (off) OFF OFF OFF 3 Unicast X 1 (on) ON OFF OFF 4 Unicast Y 0 (off) ON OFF OFF 5 Unicast Y 1 (on) ON ON OFF 5 Multicast (X,Y) 0 (off) OFF OFF OFF 6 Multicast (Y,Z) 1 (on) OFF ON ON 7 Broadcast 2 (inh) OFF OFF OFF 8 Broadcast 3 (res) OFF ON ON 9 Multicast (X,Y) 1 (on) ON ON ON 10 Multicast (Y,Z) 0 (off) ON OFF OFF 11 Broadcast 1 (on) ON ON ON 12 Broadcast 0 (off) OFF OFF OFF ON – The NE is permitted to send any unsolicited messages it has for any protocol. OFF – The NE is NOT permitted to send any unsolicited messages. 3.8.2 Collisions A collision is defined as multiple unsolicited messages from different NEs arriving at the HE receiver simultaneously such that none of the messages is received properly. True collisions should occur only during a period when multiple NEs on the same return path have the Contention State ON. It is also possible that improper reception of an unsolicited message from the NE is a result of message corruption during transmission due to noisy conditions in the return channel such as ingress or impulse noise. Although message corruption in the latter case is not a direct result of a collision, both conditions will force re-transmission of the corrupted message. 3.8.3 HE Collision Detection The HE may declare a collision. How this is done is at the vendor’s discretion. This specification does not describe what a HE should do in the event of a collision. However, the following collision detection techniques are possible: 1. Received Signal Strength Indication (RSSI) higher than “normal.” Since the arriving return channel packets have a variable size and arrival time, the HE may utilize a power detector on a receiver to roughly detect the beginning and the end of the received packet on the return channel; 2. Bytes not received in time (inter-byte gaps), or entire packet not received in time; 3. Framing errors; 4. Improper protocol; and 5. Invalid FCS. 39 3.8.4 NE Collision Indication The HE must respond with an ACK message to all return channel packets that require it within a predetermined timeout period. Currently, only the TALKRQST PDU requires an ACK. Collisions on the return channel are indicated to the originating NEs by the lack of the required ACK message from the HE because no specific indication of a collision is provided at the MAC layer. The non-receipt of the HE ACK message within the timeout period indicates to the NE that something; e.g., a collision, excessive ingress noise, or other unknown condition, has prevented the proper reception of the return channel packet at the HE, and the NE must retransmit the message (see Section 3.8.5). This collision detection mechanism is part of the general technique known as ALOHA to support multiple user access to a common transmission channel. 3.8.5 Backoff Algorithm The “Backoff” state is defined as the contention state when CC = 1 and the NE is waiting for a random delay period Y to elapse, after which it will attempt to send a message again. The backoff or random delay Y is calculated using the following formula: Y = random[ 1, 2k ] * BackoffPeriod, where Y = Period of time to wait in ms (backoff) k = 0 to 15 (default value of 6, default maximum is 15, absolute maximum is 15) random[ ] = Random number in range of 1 to 2k BackoffPeriod = Variable in milliseconds for incremental backoff time to wait. Default value is 6 ms, for a maximum backoff Y of approximately 197 seconds. 3.8.6 Backoff State Machine Description When the NE has a packet to be transmitted for the first time when CC = 1, the NE must first enter the “Backoff” state. For this first backoff, the initial value of k currently set is used (default value is 6). When the calculated backoff period Y has elapsed, the NE may then send the packet. After the NE sends a packet requiring an ACK, the NE waits for the ACK PDU from the HE to determine if the transmission was successful. If the NE receives the ACK PDU within the predetermined timeout period following the transmission of the reverse channel packet, it declares a successful transmission and discards the successful packet. Note that if the packet was successfully transmitted without a collision, then the HE received the packet while it was being transmitted. Therefore, the time required to receive the required ACK 40 packet is equal to [processing time of the HE] + [time required to transmit ACK packet] + [propagation delay]. If the transmission was not successful, as indicated by non-receipt of the ACK packet within the timeout period, the NE will delay for a new backoff period Y. In this case, the NE increments k by 1 (increasing the random number range by a factor of 2) to a maximum of 15 (or the value currently set in SCTE 38-3, HMS Common Management Information Base), calculates a new backoff period Y, enters the “Backoff” state again until period Y expires, then retransmits the packet. It then waits again to see if the retransmitted packet reaches the HE successfully (confirmed by reception of the ACK PDU within the timeout period). This process continues until any of the following conditions occur: 1. An ACK PDU is received for this packet (indicating the packet was received successfully); or 2. The maximum allowed number of MAC layer transmission retries is exceeded; or 3. CC is set to 0. After the maximum allowed number of MAC layer transmission retries has been exceeded, the NE gives up this attempt and no further transmissions are permitted until a backoff reset occurs (see Section 3.8.7). When the backoff state machine is reset, the NE may attempt to send this packet again. If the correct ACK PDU is received late during the “Backoff” state the ACK is accepted and it is assumed that the original packet was received successfully. If CC is explicitly set to 0 by a new CONTMODE message or after expiration of the duration timer (see Section 2.5.7), then retries are cancelled. This also resets the backoff state machine to its initial starting point. IMPORTANT NOTE Although the term “random” has been used in this section, it is recognized that it is extremely difficult to implement a true random number generator. Because of this difficulty, it is incumbent upon the vendors of OSP monitoring equipment to implement the best possible pseudo-random number generator available. This specification cannot and does not dictate how this pseudo-random number generator works. 3.8.7 Backoff Reset The backoff state machine is reset in the NE upon any of the following conditions: 1. When the NE has a new/different packet to be transmitted for the first time when CC = 1; or 2. Upon expiration of the duration timer (see Section 2.5.7); or 41 3. Upon receipt of any CONTMODE PDU; or 4. When the NE responds with a NAK PDU in response to a TALK PDU. The resetting of the backoff state machine includes the timers and other logic in use for the transmission of unsolicited messages and implementation of the backoff algorithm. The resetting of the state machine permits the NE to attempt to resend a message that had previously failed due to exceeding the allowed MAC layer transmission retry limit. 3.8.8 Parameters The parameters controlling autonomous message transmission for the HMS MAC layer are defined explicitly in Table 32. See also the latest revision of document SCTE HMS COMMON MIB, HMS Common Management Information Base. Table 32: Backoff State Machine Parameters Parameter Name Description Value AckTimeout Time that NE waits for a HE ACK 15 ms (HE processing time) message after completing a return + 3 ms (time to transmit ACK message) channel packet transmission + 1 ms (propagation delay) Default: 19 ms BackoffPeriod Basic unit of time that NE waits after 6 ms (see Section 3.8.5) not receiving an HE ACK message prior to message re-transmission k Controls the size of the random number Default value: 6 window Absolute maximum value: 15 Default maximum value: 15 MaxMACLayerRetries Number of times the NE will attempt to This parameter shall default to a value transmit its autonomous message of 16 Y Backoff time resulting from backoff Calculated algorithm calculation 3.9 Return Channel Transmissions There are two times when a NE is permitted to transmit: 1. Contention state in the NE is OFF The NE may transmit a single return channel packet any time following the reception of a valid forward channel packet requiring NE response until NE access is turned OFF by a subsequent packet that disables its access. For example, a forward channel packet addressing a different NE. See Figure 8. 42 Figure 8: Return Channel Transmission Permitted Forward Channel Forward Channel Return channel message can be transmitted 2. Contention state in the NE is ON The NE may transmit a return channel packet any time following the reception of a valid CONTMODE PDU that turns the Contention state ON in the NE until its access is turned OFF by either a subsequent CONTMODE PDU that disables its access, or expiration of the duration timer for CC = 1 (as set by the CONTMODE PDU). Note that return channel packet transmission in this case must follow the rules of contention and backoff. 43 3.10 MAC State Machines The NE shall implement the state diagrams included in this section. 3.10.1 Contention State Machine Figure 9 illustrates the state diagram for the contention state machine. Figure 9: Contention State Diagram From ANY NR-* state: Boot OR REG_END Registration (pending) Timeout CONTMODE (reg) (duration) CONTMODE (reg) NR-PEND NR-OFF NR-REG (duration) NON REG NON REG NON REG CC = 0 CC = 0 CC = 1 CN = 0 CN = 0 CN = 0 1 Hour Timeout CONTMODE (off, inh, res) or timeout REG_END (ok) Mode values which are not shown for a particular state OFF are IGNORED when in that REG state! CC = 0 CN = 0 Where (duration) is CONTMODE (off) indicated, the DURATION field in the CONTMODE CONTMODE CONTMODE (off) PDU has meaning. The (on, duration) duration timer is restarted with the new value. ON State NAME in bubbles is REG for reference only. CONTMODE(on,res) CC = 1 (duration) CN = 1 CC, CN - Contention mode bits CR - CHNLRQST bit CONTMODE Mode Values CONTMODE(inh,reg) OFF: 0 CONTMODE(on,res) or timeout ON: 1 (duration) INH: 2 RES: 3 REG: 4 INH REG CC = 0 CN = 1 44 3.10.2 Backoff State Machine Figure 10 illustrates the state diagram for the backoff state machine. Figure 10: Backoff State Diagram If messages, From all states Send one Set CC = 0 due to: a) CONTMODE IDLE b) DURATION expired TALK c) Retries exceeded Any State Msgs to Send Wait For CC == 1 If no messages Calc Y send NAK "k" initial value Reset Contention State Machine ACK Timeout k=k+1 Calc new Y Backoff ACK Wait Wait Y Backoff Complete TALKRQST ACK Late ACK Ready To Send 45 REFERENCES 4 Normative references The following documents contain provisions, which, through reference in this text, constitute provisions of this standard. At the time of subcommittee approval, the editions indicated were valid. All standards are subject to revision, and parties to agreement based on this standard are encouraged to investigate the possibility of applying the most recent editions of the documents listed below. 4.1 SCTE References • SCTE 38-3 2002, Hybrid Fiber/Coax Outside Plant Status Monitoring SCTE-HMS-COMMON- MIB Management Information Base (MIB) Definition. Exton, PA: Society of Cable Telecommunications Engineers, Inc. • SCTE 25-1 2008 , Hybrid Fiber Coax Outside Plant Status Monitoring – Physical (PHY) Layer Specification v1. Exton, PA: Society of Cable Telecommunications Engineers, Inc. 4.2 Standards from other Organizations • IEEE. Std 802-1990, IEEE Standards for Local and Metropolitan Area Network: Overview and Architecture. The Institute of Electrical and Electronics Engineers, Inc. • IETF RFC 1157. A Simple Network Management Protocol (SNMP). • IETF RFC 1662. PPP in HDLC-like Framing. 5 Informative References The following documents may provide valuable information to the reader but are not required when complying with this standard. 5.1 Published Materials • Stallings. 1993. Local and Metropolitan Area Networks, Fourth Edition. Prentice- Hall, Inc. 46 Appendix A. Operational Details A.1 Introduction This appendix addresses various operational aspects concerning implementation of the HMS MAC protocol. Neither the main section of these specifications nor RFC 1157, A Simple Network Management Protocol (SNMP), specifically addresses these issues. A.2 Time Of Day The NE is required to maintain a time of day clock so that alarms may be time-stamped. However, the NE is not required to have a real-time hardware clock. After NE power-up, the clock shall begin at 0 (midnight January 1, 1970) and will maintain time from there until the time is synchronized by the management system. Vendors shall specify the accuracy for their clock. A resolution of 1 second is required. The drift of the clock (unsynchronized) shall be no more than 30 seconds over a 24-hour period. A.2.1 Integer Representation Any MIB variable specifying time in an Integer format will use the POSIX standard format of the number of seconds since January 1, 1970 and requires a 32-bit integer at a minimum. See also document SCTE HMS COMMON MIB, HMS Common Management Information Base. A.3 Firmware Downloads Remote NE firmware downloads; i.e., downloads performed over the RF serial link, shall be accomplished via SNMP. The exact mechanism is detailed in document SCTE HMS DOWNLOAD MIB, HMS Transponder Firmware Download Management Information Base. A.4 NE Addressing Each NE is assigned a unique IEEE MAC address as specified in Section 2.3.3 of this document. However, for addressing the NE in a system, two approaches are possible. Neither has any effect on the NE since the NE responds only to MAC addresses. A.4.1 Direct Addressing Using Individual IP Address Element Management Systems (EMSs) that support assignment of individual IP addresses to each NE within a MAC layer domain may find this a suitable approach. A unique IP address is assigned to each NE through the registration mechanism. The NE may then be addressed directly by IP address with the HE acting as a router or bridge. SNMP Trap messages with NE alarms will have the IP address of the NE in the Trap. The NE is not required to have a full IP protocol stack, however this specification does provide for a mechanism to support such implementations (see Section 2.3.2). 47 A.4.2 Proxy Addressing Using Common IP Address EMSs that assign a common IP addresses to support communications to all NEs within a MAC layer domain may find this a suitable approach. A common IP address is used to channel all communications between a HE and multiple NEs. Assignment and management of individual IP addresses for each NE is not required. The HE serves as an SNMP proxy agent for the NEs. All SNMP messages sent to the HE contain the MAC address of the NE in the community string of the SNMP PDU. The format of this string does not matter as long as it uniquely identifies the NE to the HE. A recommended format for identifying a NE with MAC address 12-34-56-78-9A-BC is “123456789ABC”. The HE then performs a lookup function in an internal database using this community string to find the NE MAC address and sends the new SNMP PDU to the NE that was identified. The community string has a maximum size of 64 bytes. See also document SCTE HMS COMMON MIB, HMS Common Management Information Base. A NE shall ignore the community string in SNMP packets it receives. The NE shall set the SNMP packet community string for the GetResponse PDU to the same value it received for the originating PDU; i.e., a GetRequest PDU. A.5 Alarm Processing HMS MAC Protocol A.5.1 Managed Parameter Properties Document SCTE HMS PROPERTY MIB, HMS Alarm Property Management Information Base defines the properties that may be associated with each managed NE parameter. The properties defined in the SCTE HMS PROPERTY MIB can be applied to any parameter because the index to the MIB is the object identifier of the parameter. See Figure 11. In this example, the property analogAlarmLO is associated with managed NE parameter psOutputVoltage. 48 Figure 11: SCTE HMS Property MIB Usage SetRequest (psOutputVoltage LO alarm threshold) 1.3.6.1.4.1.5591.1.1.1.1.8. 13. 1.3.6.1.4.1.5591.1.4.2.1.22.1 Value 850 1.3.6.1.4.1.5591.1.1.1.1.8 = Property analogAlarmLO Transponder internal 13. = Length of parameter OID 850 variable associated to follow with psOutputVoltage, LO alarm 1.3.6.1.4.1.5591.1.4.2.1.22.1 = OSP PS MIB, device #1 psOutputVoltage It is up to the vendor to indicate which properties apply to any given parameter. See Table 33 for a list of properties that can be applied. For example, analog properties need not apply to a digital parameter (e.g., tamper switch). Note NE vendors may, at their discretion, support additional properties for parameters through a vendor-specific property MIB. This specification recommends that the same mechanism described here be used to associate the additional properties with each managed NE parameter. 49 Table 33: HMS Properties Property Name Description LOLO Alarm threshold for the extreme low condition LO Alarm threshold for the low condition HI Alarm threshold for the high condition HIHI Alarm threshold for the extreme high condition Deadband Deadband that applies to all alarm thresholds. After an alarm occurs, the parameter value must pass back over the alarm threshold by this amount for the alarm to be cleared. Alarm Enable Permits enabling and disabling of specific alarms: Bit 0: LOLO alarm Bit 1: LO alarm Bit 2: HI alarm Bit 3: HIHI alarm Bit 4: Reserved Bit 5: Reserved Bit 6: Reserved Bit 7: Reserved Note: Nothing in this specification implies the severity of any particular alarm. See document SCTE HMS PROPERTY MIB, HMS Alarm Property Management Information Base for complete details about each field. The thresholds and the deadband for any parameter must be of the same precision as the parameter. For example, if battery voltage is presented in units of 0.01VDC, then the thresholds and deadband must also be presented in units of 0.01VDC. A.5.2 Alarm Thresholds and Operation In the event that an alarm condition is detected, the alarm thresholds function as follows: 1. LOLO: When a parameter value crosses this threshold (value < threshold), the alarm will be indicated. The parameter returns from alarm when (value > threshold + deadband). 2. LO: When a parameter value crosses this threshold (value < threshold), the alarm will be indicated. The parameter returns from alarm when (value > threshold + deadband). Note Note: If a parameter value crosses directly to the LOLO alarm state, a LO alarm should not be triggered. For example, consider a parameter having LOLO and LO thresholds of 5 and 10 respectively and a deadband of 1. The parameter value is quiescent at a value of 15. Suddenly, the value drops to 2 with no intermediate values sensed. In this case, only the LOLO alarm should be triggered. If the value subsequently rises to a value of 7, the LO alarm should then be triggered. Conversely, if a LO alarm occurs first and the value progresses over the LOLO alarm threshold, that alarm should then be triggered. 50 3. HI: When a parameter value crosses this threshold (value > threshold), the alarm will be indicated. The parameter returns from alarm when (value < threshold - deadband). 4. HIHI: When a parameter value crosses this threshold (value > threshold), the alarm will be indicated. The parameter returns from alarm when (value < threshold - deadband). Just as in the case of LO and LOLO, an excursion past the HI threshold directly to the HIHI alarm level will cause only a HIHI alarm. Only one alarm state shall be active at any time. In the note above for the LO alarm, only the LO or the LOLO alarm is active and not both at the same time. In all cases, disabling the alarm while the alarm is active shall generate the following actions: 1. The alarm is reset to the nominal state and a trap is issued; 2. The alarm is deleted from the current alarm table; and 3. The alarm remains in the alarm log table (this is a history table). A.5.3 Alarms MIB Information Document SCTE HMS ALARMS MIB, HMS Alarms Management Information Based, is simple and provides for organized and effective alarm retrieval. The contents of the NE alarm list are defined and transferred as an octet string containing all of the recorded information for a particular alarm. This permits the efficient retrieval of all the information for a given alarm. The alarm list acts as a simple circular first in first out (FIFO), wrapping around and overwriting alarms in the list. Alarms are not removed from the list. A.5.4 NE Alarm Processing The NE shall not send any SNMP traps or perform alarm processing (detection, etc.) until a REG_END PDU is received with STATUS of 0 (SUCCESS). At that time, alarm processing is governed by the commonAlarmDetectionControl variable as defined in document SCTE HMS COMMON MIB, HMS Common Management Information Base as well as all other applicable MIB variables. Upon detecting an event, the NE stores it in an internal list for transmission later. Alarm notification and retrieval mechanisms and relevant examples are described in Section A.5.5. A.5.5 Alarm Notification and Retrieval The MAC layer provides a “notify and gather” mechanism where the HE is notified that a NE wants to transmit unsolicited messages. The HE can retrieve these messages by permitting the NE to send the messages reliably in a non-contention environment. The HE may then forward these messages via SNMP Trap mechanism to a higher layer EMS or cache them. Note that there is no requirement to perform message retrieval in a contention-free environment; however, that method is recommended. 51 There are two methods for determining that a NE has alarms to be transferred. These are described in the sections A.5.5.1 and A.5.5.2. A.5.5.1 Notification – Polled Mode The STATRESP PDU serves as the message notification mechanism via the CHNLRQST bit (see Section 2.5.4). In a strictly poll-based implementation of the HMS MAC protocol, the STATRQST/STATRESP transaction supports background polling and alarm notification. When the HE receives a STATRESP PDU message from a NE with the CHNLRQST bit in the STATUS field set to 1, it should add this NE to a list of NEs requesting permission to transmit unsolicited messages and process this list at its convenience. If the list is empty, the NE can be processed immediately; i.e.: it can be granted immediate access to the return channel to transmit a single message. A.5.5.2 Notification – Contention Mode The TALKRQST PDU originated from a NE serves as the message notification mechanism when contention mode is in the ON state (see Section 2.5.5). When the HE receives a TALKRQST PDU message, it must respond with the ACK PDU to signal the NE that the message has been received and that no additional TALKRQST PDU is necessary. Only the TALKRQST PDU is permitted when the NE contention state is ON (see Section 3.8) and no alarm information is transmitted until after the HE explicitly grants the NE access to the return channel. A.5.5.3 Retrieval To retrieve unsolicited messages from a NE, the HE can at its discretion first ensure that return channel contention is turned OFF for all NEs within the particular MAC layer domain through generation of the CONTMODE PDU with MODE value of OFF or INH (see Section 2.5.7). Following this, the HE must: 1. Transmit a TALK PDU to the NE to grant it immediate access to the return channel for transmission of a single message (packet); 2. Process the received packet from the NE. Typically, this packet will be of protocol type SNMP Trap Over Serial; and 3. Repeat sequence 1 and 2 at its discretion until the NE has no more messages to send. At this point, the NE response to the HE TALK PDU is a NAK PDU. Note that steps 1 and 2 constitute a single HMS MAC protocol transaction. This specification does not state in what order the NE alarms should be sent. However, for consistency, it is highly recommended that the alarms be transmitted in the order in which they occurred. See the Section A.5.3 for additional detail on alarm retrieval during alarm overflow situations. 52 A.5.5.4 Alarm and Message Flows Table 34 illustrates the expected message flow between HE and NE in a poll-based implementation of the HMS MAC protocol. In this instance, HE reception of a STATRESP PDU message with the CHNLRQST bit in the STATUS field set to 1 signals the HE that the NE has one or more messages to transmit. The HE immediately grants the NE access to the return channel via the TALK PDU to transmit a single message at a time until the NE generates a NAK PDU in response to the HE TALK PDU to signal it no longer has any outstanding messages to transmit. The value in parentheses for the TALK PDU is the value of the ACKSEQ field. Table 35 illustrates the potential message flow between HE and NE in a contention-based implementation of the HMS MAC protocol. This example assumes contention has been enabled on the return channel and one or multiple NEs signals the HE via the TALKRQST PDU that it has one or more messages to transmit. The HE acknowledges each TALKRQST PDU via an ACK PDU back to each of the NEs. Note in Table 35 that for NEs B and C, even though initial transmissions over the return channel result in a collision, the TALKRQST PDUs are successfully transmitted after invoking the HMS MAC backoff and retransmission algorithm (see Section 3.8). Following transmission of ACK PDUs, the HE in this example turns return channel contention OFF via the CONTMODE PDU first. It then grants each NE access to the return channel via the TALK PDU to transmit a single message at a time until the NE generates a NAK PDU in response to the HE TALK PDU to signal it no longer has any outstanding messages to transmit. The process continues until all outstanding NE transmissions have been completed. Table 34: Alarm Notification and Retrieval – Polled Mode HE Message To/From NE Message CHNLRQST Contention Sequence Sequence Bit Number Number STATRQST 41 -> A 0 0 <- A STATRESP 41 0 0 Alarm detected 1 0 STATRQST 42 -> A 1 0 1 <- A STATRESP 42 1 0 CHNLRQST = 1 TALK (0xFF) 43 -> A 1 0 2 <- A SNMP Trap 43 1 0 TALK (0x43) 44 -> A 1 0 2 <- A SNMP Trap 44 1 0 TALK (0x44) 45 -> A 0 0 3 <- A NAK 45 0 0 1 Notification 2 The HE is simply giving permission for the NE to transmit uninterrupted. The actual message could be any protocol. 3 This is used to indicate that the NE has no more messages to be transmitted. 53 Table 35: Alarm Notification and Retrieval – Contention Mode HE Message To/From NE Message CHNLRQST Contention Sequence Sequence Bit Number Number CONTMODE 0 -> * 0 1 ON 1 <- A TALKRQST 15 A=1 1 ACK 15 -> A A=1 1 1 <- B TALKRQST 25 A,B,C=1 1 1 <- C TALKRQST 35 A,B,C=1 1 B&C A,B,C=1 1 collide, backoff Time passes A,B,C=1 1 1 <- B TALKRQST 25 A,B,C=1 1 ACK 25 -> B A,B,C=1 1 1 <- C TALKRQST 35 A,B,C=1 1 ACK 35 -> C A,B,C=1 1 CONTMODE 0 -> * Disables contention A,B,C=1 0 OFF for this return path TALK(0xFF) 43 -> A A,B,C=1 0 2 <- A SNMP Trap 43 A,B,C=1 0 TALK(0x43) 44 -> A A,B,C=1 0 2 (message <- A SNMP Trap 44 A,B,C=1 0 garbled) Timeout A,B,C=1 0 occurs TALK (0x43) 44 -> A Retry A,B,C=1 0 2 <- A SNMP Trap 44 A,B,C=1 0 TALK (0x44) 45 -> A A,B,C=1 0 2 <- A SNMP Trap 45 A,B,C=1 0 TALK (0x45) 46 -> A A has no more A=0 0 alarms to send B,C=1 3 <- A NAK 46 B,C=1 0 Repeat B B,C=1 0 sequence 1 Notification 2 The HE is simply giving permission for the NE to transmit uninterrupted. The actual message could be any protocol. 3 This is used to indicate that the NE has no more messages to be transmitted. 54 A.6 Automatic Channel Discovery This version (1.0) of the HMS MAC protocol defines a CHNLDESC PDU (see Section 2.5.11) that the HE originates to communicate forward and return channel frequencies in use to the NE. This can support optional implementation of an automatic channel discovery feature in the NE. At the vendor’s discretion, the NE may be configured to automatically search for the forward and return channel frequencies currently in use. Since the HE is required to periodically transmit the CHNLDESC PDU, the following mechanism is suggested: 1. The NE starts by choosing a forward path channel and monitors it for valid forward path messages over a pre-determined time interval. This document does not specify how a forward channel may be chosen or how long a NE must stay tuned to a particular forward channel. 2. Once the NE has found a forward path channel with valid MAC messages, it listens for the CHNLDESC PDU for up to 35 seconds. If no PDU is heard, the NE may move onto a different forward path channel at its discretion. This document does not specify how another forward channel may be chosen. 3. After hearing a CHNLDESC PDU with valid forward and return channel frequencies, the NE should tune its return path transmitter to the frequency specified and attempt the Auto-Registration procedure described in section A.7. 4. If the Auto-Registration procedure fails, the NE may attempt to try another valid forward path channel at its discretion. This document does not specify what the NE should do. A.7 Auto-Registration This version (1.0) of the HMS MAC protocol requires that NEs register with the HE and provides the procedure and mechanisms to perform this function. Following NE reboot either by power-up, watchdog reset, commanded reset, manual reset, or other method, it shall perform any required internal initialization. After internal initialization is complete, the NE may use an Automatic Channel Discovery mechanism similar to the one described in section A.6 to search for the forward and return channel frequencies currently in use. Alternatively, the NE may use frequencies already provisioned. Once the NE has found a valid set of frequencies, it requests registration. The following sequence and the example in Table 36 illustrate a potential implementation of the auto- registration process: 1. The HE periodically transmits a CONTMODE PDU with MODE value of 4 (REG). Only those NEs that are not yet registered may respond. 2. The NE indicates it has messages to transmit by transmitting a TALKRQST PDU. 3. The HE transmits an ACK PDU to indicate to the NE that its TALKRQST PDU was received. 55 4. The HE eventually transmits a CONTMODE PDU with MODE value of INH to turn off registration requests. 5. The HE eventually transmits a TALK PDU to the NE. 6. The NE transmits a REG_REQ message with the IP address of the NE as it is currently configured. Refer to Section 2.5.8 of this specification. 7. The HE transmits a TALK PDU to the NE with the sequence number of the transaction in steps 5 and 6. The NE responds with a NAK indicating no more messages. 8. The HE determines the correct IP address for the NE. How the correct IP address is determined is beyond the scope of this document. 9. Optionally, the HE transmits a SET_ADDR PDU to the NE with the correct IP address. The NE transmits an ACK PDU back to the HE upon successful processing of the SET_ADDR PDU. Refer to Section 2.5.9 of this specification. Note that this transaction is not required if the HE determines that the NE is already configured. 10. The HE transmits a REG_END PDU with the appropriate status value (SUCCESS, DENIED, FAILED, or PENDING). The NE responds with an ACK PDU. Refer to Section 2.5.10 of this specification. 11. If the NE registration request was denied, the NE may opt to use the CHNLDESC PDU mechanism to search for another channel, or it may request registration on the current return channel again. If the registration request failed, the NE must wait until the next registration opportunity. If the registration request is pending, the NE shall not send any further registration requests. The NE shall not send any SNMP Traps or perform alarm processing (detection, etc.) until a REG_END PDU is received with STATUS of 0 (SUCCESS). 12. The HE restores the contention mode of the system using the CONTMODE PDU with MODE value of RES. 13. If the HE wants the contention mode of the NE turned ON, the HE transmits the CONTMODE PDU with MODE value of ON to the NE. This should be done using the unicast address of the NE. The NE shall respond with an ACK PDU. 14. When ready, the NE shall generate a SNMP trap. The mechanisms described in Section A.5.5 must be implemented for alarm notification and retrieval. No SNMP Traps are permitted until the REG_END transaction is completed. 15. The HE performs any other configuration required by the NE. 56 Table 36: Auto-Registration Implementation Example HE Message To/From NE Message CHNLRQST Contention Sequence Sequence Bit Number Number CONTMODE 00 -> * 0 1 REG 1 <- A TALKRQST 1 1 1 ACK 1 -> A 1 1 CONTMODE -> * 1 0 INH1 TALK (0xFF) 42 -> A 1 0 <- A REG_REQ 42 0 0 TALK (0x42) 43 -> A 0 0 <- A NAK 43 0 0 SET_ADDR 44 -> A 0 0 <- A ACK 44 0 0 REG_END (0) 45 -> A 0 0 <- A ACK 45 0 0 CONTMODE 00 -> * RES CONTMODE 46 -> A ON2 <- A ACK 46 1 This is required to turn OFF the registration contention mode. 2 This transaction is optional and it depends on whether the HE wants the NE in contention mode or not. A.8 Configuration Changes and SNMP Trap Generation The NE must be capable of recognizing configuration changes and notifying the upstream EMS of this event. To accomplish this, the NE shall maintain a check code value of 32 bits in size. See also SNMP commonCheckCode variable definition in document SCTE HMS COMMON MIB, HMS Common Management Information Base. The algorithm and data used to calculate this check code is vendor-specific. One suggested approach is CCITT CRC-16 as implemented for HMS MAC layer packets (see Section 2.3.7). The check code is calculated under any of the following conditions: 1. Upon NE reset (power-up or other reset); 2. An SNMP request for the check code; or 3. At the vendor’s discretion. The NE shall keep track of the last check code it calculated. It shall generate appropriate hmsColdStart and hmsWarmStart SNMP Traps as defined in document SCTE HMS COMMON MIB, HMS Common Management Information Base. 57 The NE shall generate the hmsColdStart SNMP Trap under any of the following conditions: 1. The NE has been reset and the calculated check code differs from the last saved check code; or 2. The check code was calculated at the vendor’s discretion and it differs from the last saved check code. The NE shall generate the hmsWarmStart SNMP Trap under the following conditions: 1. The NE has been reset and the calculated check code is the same as the last saved check code. The hmsColdStart and hmsWarmStart Traps will not be generated by a simple SNMP Get of the check code. Once the appropriate SNMP trap has been generated, the newly calculated check code shall be stored in non-volatile memory. 58 Appendix B. Glossary Data Link Layer (DLL) Layer 2 in the Open System Interconnection (OSI) architecture; the layer that provides services to transfer data over the physical transmission link between open systems. Forward Spectrum This term refers to the passband of frequencies in HFC cable systems with a lower edge of between 48 MHz and 87.5 MHz, depending on the particular geographical area, and an upper edge that is typically in the range of 300 MHz to 860 MHz depending on implementation. Full Spectrum This term refers to the combined forward and return spectrums in HFC cable systems and excludes any guard band. Guard Band This term refers to the unused frequency band between the upper edge of the usable return spectrum and the lower edge of the usable forward spectrum in HFC cable systems. Network Element (NE) In the context of this specification, a network element is an active element in the outside plant (OSP) that is capable of receiving commands from a headend element (HE) in the headend and, as necessary, providing status information and alarms back to the HE. Open System Interconnection (OSI) A framework of International Organization for Standardization (ISO) standards for communication between multi-vendor systems that organizes the communication process into seven different categories that are placed in a layered sequence based on the relationship to the user. Each layer uses the layer immediately below it and provides services to the layer above. Layers 7 through 4 deal with end-to-end communication between the message source and destination, and layers 3 through 1 deal with network functions. Organizationally Unique Identifier (OUI) A 3-octet IEEE assigned identifier that can be used to generate Universal LAN MAC addresses and Protocol Identifiers per ANSI/IEEE Std 802 for use in Local and Metropolitan Area Network applications. 59 Physical (PHY) Layer Layer 1 in the Open System Interconnection (OSI) architecture; the layer that provides services to transmit bits or groups of bits over a transmission link between open systems and which entails electrical, mechanical and handshaking procedures. Return Spectrum This refers to the passband of frequencies in HFC cable systems with a lower edge of 5 MHz and an upper edge that is typically in the range of 42 MHz to 65 MHz depending on the particular geographical area. Transponder A device that interfaces to outside plant (OSP) NEs and relays status and alarm information to the HE. It can interface with an active NE via an arrangement of parallel analog, parallel digital and serial ports. 60 Appendix C. List of Acronyms CRC........................................Cyclic Redundancy Code DLL ........................................Data Link Layer EMS .......................................Element Management System FCS ........................................Frame Check Sequence HE ..........................................Headend Element HFC ........................................Hybrid Fiber Coax HMS .......................................Hybrid Management Sub-Layer IEEE .......................................Institute of Electrical and Electronics Engineers IP ............................................Internet Protocol ISO .........................................International Organization for Standardization LSB ........................................Least Significant Bit MSB .......................................Most Significant Bit NE ..........................................Network Element MAC ......................................Media Access Control OSP ........................................Outside Plant OSI .........................................Open System Interconnection OUI ........................................Organizationally Unique Identifier PDU........................................Protocol Data Unit PHY........................................Physical POSIX ....................................Portable Operating System Interface RF...........................................Radio Frequency SCTE ......................................Society of Cable Telecommunications Engineers SNMP.....................................Simple Network Management Protocol UART.....................................Universal Asynchronous Receiver/Transmitter 61