KiNET Ethernet Protocol Whitepaper

KiNET is a lightweight UDP/IP based protocol used to communicate via Ethernet with Color Kinetics luminaires and power/data supplies.

During normal operation (light data output), the KiNET protocol utilizes UDP packets sent to port 6038. Some nonlight-data KiNET traffic, like Ethernet Keypad triggering, uses UDP ports 6039, 6041 and 6045. KiNET uses a mix of broadcast and unicast data, outlined later in this document.

Versions of KiNET

For light output, two generations of the KiNET protocol have been implemented.

KiNET v1

In the KiNET v1 protocol, a single universe (512 bytes) of light data can be sent to a single destination IP address (unicast or broadcast) using a “DMXOUT” KiNET packet. If the destination power/data supply has multiple output ports (for example, the CM-150 CA gen2, which has two output ports to connect to two strings of lights), the power/data supply splits the incoming DMXOUT packet across its output ports based on the number of lights it has associated with each port. This “node count” is stored on the power/data supply, typically at commissioning time by issuing a blinkscan command (by pressing the onboard blinkscan button or initiating a node count via QuickPlay Pro 2 or other software). KiNET devices that receive DMXOUT packets normally handle these packets in the same way that they handle data received by a DMX-512A link.

KiNET v2

In the KiNET v2 protocol, we add a port number field to the KiNET light data packet to create a “PORTOUT” KiNET packet. This field identifies the target output port on the receiving KiNET device to direct the packet to, and is independent of the port field in the IP header. With this, each output port on a given power/data supply can have a full universe worth of light data sent to it. The node count on each port is no longer used or needed to know which port to send what data to: the power/data supply just sends the data for a particular port number directly to that output port. This allows for a single power/data supply to have more than one universe associated with it.

Some power/data supplies support only KiNET v1, some support only KiNET v2, but most support both. (See chart below).

KiNET v3

A third generation of KiNET also exists. This version contains updates to the device query and configuration aspects of KiNET, but does not impact the communication of light data. All devices that support KiNET v3 for configuration also support KiNET v1 and KiNET v2 for the communication of light data.

KiNET light data support by device

* Base address is not supported in this mode

KiNET Universes

Similar to other digital lighting protocols like DMX512 and sACN, KiNET is based on universes of 512 8-bit control channels. KiNET packets contain a “universe” field that is used in combination with the destination IP address and (for KiNET v2) output port to uniquely identify the destination for a particular 512 channel universe. This is primarily useful in a broadcast environment, as in a unicast environment every destination IP already receives one or more unique universes. In a unicast environment, DMXOUT and PORTOUT packets are normally sent to the “Don’t care” value of -1, but can also be sent to the universe that the KiNET device is set to.

Unicast vs Broadcast

KiNET compatible power/data supplies accept incoming PORTOUT and DMXOUT packets sent to their specific unicast IP address, as well as packets sent to a broadcast address. For smaller installations with 1-2 universes of control, KiNET can be used in a broadcast configuration, utilizing the universe flag of the packet to separate the universes.

For larger installations, unicast KiNET should be used. This is the preferred method of control for a Color Kinetics lighting system and allows the protocol to scale to hundreds of thousands of control channels utilizing standard Ethernet switching hardware. Unicast KiNET requires the controller to know the destination IP addresses of the power/data supplies it wishes to communicate with. These IP addresses can be manually entered by the user, or can be discovered using the KiNET discovery protocols.

Broadcast communication is utilized for power/data supply discovery in applications such as QuickPlay Pro 2. KiNET does not use or support multicast.

PORTOUT SYNC

SYNC packets are an optional part of the KiNET v2/PORTOUT specification that can be used to synchronize light data being sent to a large number of lights. When PORTOUT sync is enabled, the Sync Wait flag is set in a PORTOUT packet. When a power/data supply receives such a packet, it will queue up data for the lights, but not output it, waiting for a sync packet to come and tell it to release the PORTOUT data to the lights.

Typically, supplies will have multiple output ports and the lighting controller will send a PORTOUT packet for each port on the supply. Once all the PORTOUT packets are sent for a given frame, a single SYNC packet is sent as a broadcast message to tell all supplies to send the queued data to the lights.

Data is sent to each port individually before a sync is sent.

Network Design Considerations

When designing a network for use with KiNET, several parameters have an impact on the overall system performance. These include throughput, latency, and packet delivery reliability. Additionally, for large systems, the number of devices on the network and the network configuration need to be considered.

Network Throughput: Network throughput refers to the total amount of data that the network can transport in a given period of time. If insufficient network throughput is available for the data that needs to be sent, network packets will get dropped, possibly resulting in visible artifacts.

A KiNET packet is comprised of two types of data: packet metadata, and light data. The metadata includes IP headers and other information used to direct the packet to an appropriate output. Light data is the information that is sent to the output on the device receiving KiNET. The metadata is a fixed length, while the light data is a variable length depending on the requirements of the receiving device. Receiving devices with greater control channel counts per output port make more efficient use of the network, although these efficiency differences are not generally significant in practice because systems with large channel counts per output port also tend to have a large overall channel count. Some sample data rates for common devices are given below:

Latency: Latency refers to the time delay between two reference points in a communications network. There are two types of latency that need to be considered for lighting networks, including for KiNET – absolute latency and relative latency.

Absolute latency is the amount of time it takes a packet to traverse the network from origin to destination. Having a consistent and known absolute latency is important for systems that must synchronize with other systems (e.g. for content that must synchronize with music), but for preprogrammed content, it is generally not critical that this absolute latency be small.

Relative latency is the difference in time between how long it takes a packet to traverse the network from the origin to one destination and how long it takes a packet to traverse the network from the origin to a different destination. As relative latency within a network affects all packet types (including SYNC packets), it tends to be more visible than absolute latency and so should be minimized. Strategies for minimizing relative latency primarily revolve around equalizing the number of switch hops from the controller to each KiNET receiver on the network.

Packet Delivery Reliability: Delivery reliability refers to the ability of a network to transport packets between endpoints in a timely manner, without dropping or excessively delaying packets. Factors influencing delivery reliability include network congestion (i.e. insufficient throughput capacity for the required traffic), link type and quality (e.g. wireless links, improperly terminated wired links), and network configuration (e.g. Quality of Service and other traffic shaping settings).

Excessive broadcast traffic: In addition to the throughput, reliability, and latency considerations, care needs to be taken to ensure that individual network endpoints are not overloaded. Endpoints in a KiNET system, as in many other systems comprised of embedded devices, may not be capable of operating at the full speed of the network backbone. The use of unicast (and multicast) traffic allows properly configured network switches to only forward traffic intended for an endpoint to that endpoint, normally keeping the traffic for any individual endpoint to a range that the endpoint can handle. Broadcast traffic, however, does not allow network switches to direct it only to specific endpoints, and excessive broadcast traffic on the network (either intentionally introduced or due to network misconfiguration) can lead to endpoint devices receiving more network traffic than they can process.

Network size: As KiNET systems typically have endpoints that require relatively low data rates and networks with very high data rates are commercially available, it is possible to create systems with very large numbers of KiNET devices without hitting data rate limits. Network switches and other network traffic management devices often have limits on the total number of network devices they can keep track of (the number of MAC addresses on the network, often expressed as “ARP table size” or “CAM table size”), and exceeding these limits can result in a network that does not function properly. Segmenting a large network may be required, and will require additional design considerations.