SDP 이후 SAP(supportedAppProtocol)를 먼저 수행하는 이유

"SDP에서 이미 SECC를 찾아서 TCP 접속까지 했는데, 왜 또 프로토콜 협상을 해야 하는가?"라는 의문이 생길 수 있습니다.
이에 대한 내용을 아래와 같이 정리합니다.

SDP가 알려주는 정보의 한계

SDP(SECC Discovery Protocol)는 다음 정보만 제공합니다.

SDP Response:
  ├─ SECC IP Address    (IPv6)
  ├─ SECC Port          (TCP 포트 번호)
  └─ Security           (TLS 사용 여부: TLS / No-TLS)

SDP는 "SECC가 어디에 있고 어떻게 접속하는가" 만 알려줄 뿐, "SECC가 어떤 V2G 프로토콜 버전을 지원하는가" 는 전혀 알려주지 않습니다.

---

SAP가 필요한 근본 이유들

이유 1. 다중 표준 공존 환경

현실의 충전 인프라에서는 여러 표준이 혼재합니다.

EVCC가 지원 가능한 프로토콜:
  ├─ urn:iso:15118:2:2013:MsgDef   (ISO 15118-2)
  ├─ urn:iso:15118:20:2022:MsgDef  (ISO 15118-20)
  └─ urn:din:70121:2012:MsgDef     (DIN SPEC 70121)

SECC가 지원하는 프로토콜:
  ├─ urn:iso:15118:2:2013:MsgDef   공통
  └─ urn:din:70121:2012:MsgDef     공통

SDP만으로는 SECC가 어떤 프로토콜을 지원하는지 알 수 없으므로, TCP 연결 후 첫 번째 대화로 공통 프로토콜을 협상 해야만 합니다.

---

이유 2. EXI 스키마 확정의 필요성

V2G 메시지는 EXI(Efficient XML Interchange) 형식으로 인코딩됩니다. EXI 인코딩/디코딩은 스키마에 완전히 종속적입니다.

협상 전:
  수신 바이트열 → 어떤 스키마로 디코딩? → 알 수 없음 → 파싱 불가

협상 후 (예: ISO 15118-2 결정):
  수신 바이트열 → urn:iso:15118:2:2013:MsgDef 스키마로 디코딩 → 정상 파싱

SAP 협상 완료 = 이후 모든 메시지의 EXI 스키마 확정 이므로, SAP 없이는 어떤 V2G 메시지도 올바르게 해석할 수 없습니다.

---

이유 3. SchemaID 할당

SAP 협상 결과로 SchemaID 가 결정됩니다.

supportedAppProtocolRes:
  ├─ ResponseCode = Success_Negotiation
  └─ SchemaID = 10   ← SECC가 선택한 프로토콜에 부여한 ID
                       (EVCC가 제안한 AppProtocol의 SchemaID 중 선택)

이후 모든 V2G 메시지 헤더:
  └─ SchemaID = 10   ← 이 값으로 메시지 파싱 스키마를 식별

SchemaID 값은 SECC가 선택한 프로토콜을 EVCC에 알리는 용도입니다.

---

이유 4. 설계 계층의 분리 원칙

계층	프로토콜	역할
물리/전기	IEC 61851	CP 신호, 에너지 전달
탐색	SDP (UDP)	SECC 위치 및 접속 정보 탐색
전송	TCP / TLS	신뢰성 있는 연결 수립
협상	SAP	사용할 V2G 프로토콜 버전 협상
애플리케이션	ISO 15118-2 / 15118-20 / DIN	실제 충전 제어 메시지

각 계층은 자신의 역할만 담당하도록 설계되어 있으며, SDP에 V2G 프로토콜 협상 기능을 넣지 않은 것은 계층 분리 원칙 을 따른 의도적인 설계입니다.

---

이유 5. 미래 확장성 확보

SAP 구조 덕분에 새로운 V2G 프로토콜 버전이 나와도 대응할 수 있습니다.

기존 EVCC + 신규 SECC:
  EVCC: [15118-2, DIN]        제안
  SECC: [15118-2, 15118-20]   지원
  결과: 15118-2로 협상 성공 → 하위 호환 유지

신규 EVCC + 신규 SECC:
  EVCC: [15118-20, 15118-2]   제안
  SECC: [15118-20, 15118-2]   지원
  결과: 15118-20으로 협상 성공 → 최신 프로토콜 활용

SDP를 변경하거나 새로운 탐색 메커니즘 없이도 SAP 협상만으로 새로운 프로토콜 버전을 자연스럽게 수용 할 수 있습니다.

---

전체 흐름에서의 역할 정리

SDP        → "SECC 어디 있어?"        → IP:Port 획득
TCP/TLS    → "연결 맺자"              → 신뢰성 있는 채널 확보
SAP        → "무슨 언어로 얘기할까?"  → EXI 스키마 및 SchemaID 확정
15118-2    → "이제 충전 협상 시작"    → 실제 V2G 애플리케이션 동작

---

맺는말

SAP가 필요한 이유를 한 문장으로 표현하면 다음과 같습니다.

SDP는 SECC를 찾는 절차이고, SAP는 찾은 SECC와 어떤 언어(스키마)로 대화할지 결정하는 절차이기 때문입니다.

SDP가 아무리 성공해도 EXI 스키마가 확정되지 않으면 이후 어떤 V2G 메시지도 올바르게 인코딩/디코딩할 수 없으므로, SAP는 V2G 통신의 실질적인 출발점입니다.