KNXnet/IP와 멀티캐스트 패킷 구조 (1)

KNX는 유선 통신 기반 시스템입니다.

그리고 각 디바이스들이 서로 직접 통신을 하는 노드<->노드 구조로 통신을 하는데 노드 간의 통신을 물리적인 통신케이블이 연결되어 유선 통신 방식을 기본으로 전제합니다.

만약 규모가 비교적 큰 건물에 KNX를 구축한다고 하면 그만큼 통신 라인도 증가하면서 트래픽도 많아질 거고 사용하는 디바이스도 많아질 겁니다.

이때 사용되는 디바이스 중 KNX 라인 커플러가 있습니다.

물리적인 통신거리를 확장시키면서 트래픽을 분산시켜 관리할 수 있는 말 그대로 라인과 라인을 연결하는 커플러인 셈이죠.

만약 비교적 규모가 큰 두 개의 건물에 KNX 시스템을 통합 운영한다고 생각하면 물론 유선의 통신케이블을 첫 번째 건물에서 두 번째 건물까지 포설 후에 연결하면 서로 통신을 할 수 있지만 이미 첫 번째 건물과 두 번째 건물이 IP 네트워크단에서 연결이 되어 하나의 백본으로 운영된다면 IP 라우터란 디바이스로 서로를 연결할 수가 있습니다.

라인 커플러는 상위 하위 연결이 모두 TP 라인, 즉 KNX bus로 통신을 하게 되는데 IP 라우터는 상위는 IP 네트워크 하위는 TP 라인으로 구성되어 라우터 하위 KNX bus의 통신을 IP 네트워크로 라우팅을 해주는 차이가 있습니다.

예시를 2개의 건물로 들었지만 계층을 어떻게 나누고 계획하느냐에 따라서 구성하는 방법은 다양합니다. 1개 건물의 각 층마다 IP 라우터를 배치하고 한 층 안에서는 TP 라인으로 연결하고 각 층간의 연결은 IP 네트워크를 이용할 수도 있고 한 층 안에서도 영역을 나눠서 다수의 라우터를 활용할 수도 있습니다.

KNXnet/IP 프로토콜은 IP 네트워크를 활용할 때 사용이 됩니다. 기존의 TP 네트워크를 IP 기반의 네트워크에서 사용할 수 있게 만든 프로토콜이죠.

그럼 KNX IP 라우터의 주요 활용 목적과는 다르게 IP 라우터와 이 프로토콜을 이용하면 모던 스마트홈 플랫폼과 KNX를 연동할 수 있는 브릿지 역할을 할 수 있게 됩니다.

KNX IP 라우터는 UDP 멀티캐스트 통신을 합니다. 그룹 주소는 224.0.23.12를 쓰고 포트는 3671입니다.

IP 라우터와 비슷한 디바이스로 KNX IP 인터페이스가 있는데 이 제품 또한 TP 라인을 IP로 통신할 수 있게 하는 장치 중 하나이고 주로 KNX를 설정하는 ETS 프로그래밍에 사용되는데 역시 KNXnet/IP 프로토콜을 사용하니 역시 스마트홈 플랫폼과 연동할 수 있는 브릿지 역할도 가능합니다. 참고로 IP 인터페이스는 UDP 유니캐스트 통신을 합니다.

IP 인터페이스와 라우터는 통신 연결 방식의 차이도 있고 그렇기에 패킷 또한 다릅니다.

저는 라우터를 가지고 있어서 라우팅 패킷에 대해서 챗GPT와 함께 알아보며 별도로 정리해 볼겸 적어보았습니다.

• KNXnet/IP Header (6 bytes)

• 헤더길이 (1 byte)

가장 먼저 프레임의 처음 6바이트를 KNX Header로 채웁니다. 그리고 헤더 길이는 대부분 6바이트가 되는듯합니다. 그래서 가장 첫 단은 헤더의 길이인 0x06이 들어갑니다.

• 프로토콜버전 (1 byte)

프로토콜 버전은 여러 개가 있는지 파악은 못했지만 현재 저희 집 구성으로는 0x10이 들어갑니다.

• 서비스타입 (2 bytes)

서비스 타입은 해당 패킷의 어느 유형인지 나타내는데 저는 라우터로 라우팅 된 메시지 패킷이므로 0x05, 0x30의 값을 갖고 만약 인터페이스의 터널링 메시지라면 0x04, 0x20의 값을 가집니다. 그 외 연결 요청, 연결 응답 장치 설정 요청 응답 등 여러 유형의 값이 있습니다.

• 패킷전체길이(2 bytes)

마지막 2바이트는 패킷의 전체 길이를 나타내는데 아래 실질적인 KNX 메시지 정보를 담고 있는 cEMI에 따라서 길이가 달라집니다.

• cEMI 필드

• 메시지코드 (1 byte)

메시지 코드는 메시지 유형을 나타내는데 라우팅 메시지는 대부분 0x29 (L_Data.ind) 값을 갖고 터널링 메시지에선 0x2E(L_Data.con)이나 0x11(L_Data.req) 값도 유형에 따라서 사용하는듯합니다.

• 추가정보 (1 byte)

추가 정보는 0x00입니다. 터널링 메시지에선 뭔가 따라붙는지 모르겠군요.

• 컨트롤필드 1, 2 (2 bytes)

컨트롤 필드 1과 2는 8비트씩 쪼개서 해석을 해야 됩니다. 우선순위나 라우팅 홉 카운트 ACK가 필요한지 등을 나타내는데 일반적으론 0xBC, 0xE0으로 구성돼있는듯합니다.

비트 7 : 확장프레임(0) 일반프레임(1)

비트 6 : reserved 항상 0

비트 5 : 에러시 반복설정 0은 반복 1은 반복안함

비트 4 : 시스템 브로드캐스트 0 브로드캐스트 1

비트 3~2 : 우선순위 0 시스템 1 노말 2 어전트 3 로우

비트 1 : ACK 요청유무 0 no ack 1 ack

비트 0 : 에러여부 0 노에러 1 에러

비트 7 : 0 개별주소(individual address) 1 그룹주소( group address)

비트 6~4 : 라우팅 홉 카운트

비트 3~0 : 확장 프레임 포맷 0 표준 프레임

• 출발지 어드레스 (2 bytes)

출발지 어드레스는 해당 메시지를 보낸 디바이스 주소입니다. 역시 비트 단위로 쪼개서 계산을 해야 되는데 2바이트를 “5비트. 3비트. 8비트” 형식으로 쪼개서 해당 값을 DEC로 반환하면 1.1.1 이런 형태의 KNX에서 사용하는 디바이스 주소를 가리킬 수 있습니다.

• 도착지 어드레스 (2 bytes)

도착지 어드레스는 KNX Bus 통신의 매개변수가 되는데 Group Address를 가리킵니다. 1/1/1 이런 형태를 가지고 있고 이 역시 2바이트를 “4비트/4비트/8비트” 형식으로 쪼개서 해당 값을 DEC로 반환하면 위와 같은 그룹 어드레스를 가리킬 수 있습니다.

• APDU

다음은 메시지의 실질적인 값(?)을 갖고 있는 APDU 구조입니다.

• 데이터길이 (1 byte)

여기서 말하는 데이터 길이는 TPCI와 APCI 비트를 제외한 길이입니다. APCI 하위 비트부터 데이터값으로 보는듯해서 실질적으론 1bit의 데이터라면 0x01을 가지고 1byte의 데이터라면 0x02가 길이가 되고 2bytes의 데이터라면 0x03을 가지면서 사실상 실제 패킷을 통해 전달되는 데이터값에 따라서 결정된다고 볼 수 있을 거 같습니다.

• TPCI/APCI 필드 (2 bytes)

TPCI라는 필드와 APCI라는 필드는 비트 단위로 쪼개서 TPCI의 하위 2비트와 APCI의 상위 2비트를 합쳐서 계산해야 하는데 GroupValueWrite, GroupValueRead, GroupValueResponse 등의 정보를 가지고 있습니다. 대부분 GroupValueWrite인 0010의 형태가 많은듯합니다. 그래서 대부분 0x00, 0x80의 형태를 보입니다.

0000 GroupValueRead
0001 GroupValueResponse
0010 GroupValueWrite
0011 IndividualAddr_Write
0100 IndividualAddr_Read
0101 IndividualAddr_Response

• 데이터 (n bytes)

마지막은 on/off, 0~100%, 0~255 등등 실질적인 전송 데이터입니다.

To be continue..