Systems Integration Specialists Company, Inc.

6605 19 Mile Road, Sterling Heights, MI 48314-1408 Tel: +586-254-0020, Fax: +586-254-0053 E-mail: info@sisconet.com, Web: http://www.sisconet.com

Date: 2/1/2010

Version: 0.2

Disclaimer: The following is a draft framework/proposal of a potential communication profile that could be applied to IEC 61850-90-5. The technical information is incomplete and as such is not 100% correct and should not be used as a basis for implementation. There are known issues with this document. Additionally, the IEC 61850-90-5 team has not provided any feedback and as such has no basis within IEC.

SubSqNum Msg Num EOM Tot Msg Length IEC Hdr

Length of Segment

Secure HMAC N+1 PDU (APDU) PDUs Dst Mac Address Tunnel PDU

PDUType (Tunnel, )

UDP or Other IPv4 IPv6 Length GOOSE or SV

IP QOS to IEEE Priority and VLAN Mappings

The above figure represents the start of a thought process for a communication profile that could satisfy the NASPInet requirements. It is far from complete and I have put this together in my spare time. The profile is basically something like UDP (probably UDP), IP (v4 and/or V6), with a specification that maps IP QOS to IEEE Priorities. We may also need to map some IPv6 attributes to IEEE VLAN tags. The reason for this is that priority needs to be maintained through the intervening switches (e.g. between the implementation and the router). The idea would be to utilize UDP/IP to provide multicast or unicast capability (it is suggested that we concentrate on multicast). I have identified two specific use cases for this type of profile: The need to allow tunneling of the current GOOSE and SV packets (allowing a gateway to provide proxy information so that relays and PMUs can send information over NASPInet/new profile without modification. The need to allow implementations to embed the new profile.

That is the proposed purpose of the PDU Type (e.g. to differentiate the tunnel vs. embedded). In the case of a Tunneled PDU, the destination multicast address needs to be carried with the PDU in order to allow the PDU to be emitted with the same destination MAC address. At a minimum, the IEC Header (IEC Hdr) portion needs to contain:

Page 2

Draft Framework for T-Profile for IEC 61850 conveyance of Synchrophasors

The total message length: this is needed to allow a large message to be delivered (e.g. potentially Jumbo grams or other for IPv4). Msg Num: Message number so that duplicate delivery can be detected. SubSqNum (Sub sequence number of the total message): Needed to allow segmentation, reassembly, and delivery failure. Length of Segment: Allows the length of a segment to be conveyed. It is noteworthy that the current proposal allows multiple APDU packets to be carried in a segment (e.g. multiple tunneled or other. It is anticipate that such groupings of APDUs would be based upon destination address. EOM (End of Message): Needed to indicate that the packet is the last packet required to reassemble the Message (e.g. Msg Num).

Each APDU (Application Protocol Data Unit) is tagged with its type (e.g. Tunnel, GOOSE, SV, or other). Based upon the tagging, the Actual APDU is encapsulated in with specific information. As examples: Tunneled: Would require the conveyance of the Destination MAC address and the length of the actual tunneled packet (e.g. <1500 bytes). The Destination MAC address would be used by the receiving entity to transmit/reconstruct the actual multicast packet as if it were transmitted on the local network. Other: Would require the conveyance of the length of the packet.

Note: Due to the immaturity of this document, not all such parameters have been identified. Additionally, the proposal allows for multiple APDUs to be sent within a single TPDU. Questions and comments are welcome. Herbert Falk Systems Integration Specialists Company, Inc. Email: herb@sisconet.com Phone: 586-254-0020 x105