5 min read

NGAP와 함께 보는 ASN.1 - 3rd

NGAP와 함께 보는 ASN.1 - 3rd
Photo by Jorge Salvador / Unsplash

Information Object

프로토콜을 설계할 때, 주고 받는 메시지의 용도에 따라 정보 요소의 묶음이 몇 가지 범주로 구분될 수 있다. 서로 비슷비슷한 형식의 메시지 구조를 반복하여 정의하는 대신, 그 틀을 미리 선언하여 정의하는 것이 작성해야 할 명세서의 분량도 줄이고 작성 중에 발생할 수 있는 오류의 수도 줄일 수 있다. 주고받는 정보 요소들을 information object라고 부르며, 그 선언 및 정의에 따라 class와 set이 추가된다.

  • Information Object Class: information object에 들어갈 정보 요소들을 템플릿으로 정의한 내용
  • Information Object: information object class에 따라 정의한 인스턴스
  • Information Object Set: information object들의 묶음

당장은 와닿기가 쉽지 않은 개념이다. 먼저 CLASS 선언부터 보자.

NGAP-PROTOCOL-IES Information Object Class

이제 NGAP-Containers.asn 분석을 시작한다. 다음은 asn.1 information object class를 사용한 정의이다.

NGAP-PROTOCOL-IES ::= CLASS {
  &id           ProtocolIE-ID UNIQUE,
  &criticality  Criticality,
  &Value,
  &presence     Presence
}
WITH SYNTAX {
  ID           &id
  CRITICALITY  &criticality
  TYPE         &Value
  PRESENCE     &presence
}

이 코드는 NGAP-PROTOCOL-IES라는 asn.1 information object class를 정의하는데 NGAP 메시지를 채우는 각 NGAP IE (Information Element)에 대한 것이다. CLASS {...} 내부의 필드들에 대한 설명은 다음과 같다.

  1. &id: ProtocolIE-ID 타입의 각 IE 고유 식별자
  2. &criticality: 해당 IE의 처리 실패 시 얼마나 critical하게 처리해야 하는지 지정
  3. &Value: IE의 실제 데이터로, 특정 타입을 정의하지 않음
  4. &presence: mandatory 또는 optional 여부 지정

WITH SYNTAX 키워드를 사용하여 클래스의 구문을 정의하는데, 해당 클래스에 속하는 information object를 선언할 때 어떤 형태로 필드를 표현할지 나타낸다. 이 경우, 다음과 같이 각 필드를 나타낼 수 있다.

ID           &id
CRITICALITY  &criticality
TYPE         &Value
PRESENCE     &presence

& 기호는 클래스 필드의 파라미터를 참조한다는 뜻이다. 클래스에 정의된 필드 앞에 & 기호를 붙여 사용하면 해당 필드의 값을 참조할 수 있다.

CLASS로 선언한 information object class의 내용에 따라 구현한 인스턴스인 information object의 한 예이다.

{  ID  id-RAN-UE-NGAP-ID    CRITICALITY  reject    TYPE  RAN-UE-NGAP-ID    PRESENCE  mandatory  }

그리고 다음은 위 information object를 포함한 information object set의 예이다. 위 RAN UE NGAP ID IE와 같은 정보 요소가 총 16개가 들어있다.

InitialUEMessage-IEs NGAP-PROTOCOL-IES ::= {
  { ID id-RAN-UE-NGAP-ID                        CRITICALITY reject  TYPE RAN-UE-NGAP-ID                        PRESENCE mandatory  }|
  { ID id-NAS-PDU                               CRITICALITY reject  TYPE NAS-PDU                               PRESENCE mandatory  }|
  { ID id-UserLocationInformation               CRITICALITY reject  TYPE UserLocationInformation               PRESENCE mandatory  }|
  { ID id-RRCEstablishmentCause                 CRITICALITY ignore  TYPE RRCEstablishmentCause                 PRESENCE mandatory  }|
  { ID id-FiveG-S-TMSI                          CRITICALITY reject  TYPE FiveG-S-TMSI                          PRESENCE optional   }|
  { ID id-AMFSetID                              CRITICALITY ignore  TYPE AMFSetID                              PRESENCE optional   }|
  { ID id-UEContextRequest                      CRITICALITY ignore  TYPE UEContextRequest                      PRESENCE optional   }|
  { ID id-AllowedNSSAI                          CRITICALITY reject  TYPE AllowedNSSAI                          PRESENCE optional   }|
  { ID id-SourceToTarget-AMFInformationReroute  CRITICALITY ignore  TYPE SourceToTarget-AMFInformationReroute  PRESENCE optional   }|
  { ID id-SelectedPLMNIdentity                  CRITICALITY ignore  TYPE PLMNIdentity                          PRESENCE optional   }|
  { ID id-IABNodeIndication                     CRITICALITY reject  TYPE IABNodeIndication                     PRESENCE optional   }|
  { ID id-CEmodeBSupport-Indicator              CRITICALITY reject  TYPE CEmodeBSupport-Indicator              PRESENCE optional   }|
  { ID id-LTEM-Indication                       CRITICALITY ignore  TYPE LTEM-Indication                       PRESENCE optional   }|
  { ID id-EDT-Session                           CRITICALITY ignore  TYPE EDT-Session                           PRESENCE optional   }|
  { ID id-AuthenticatedIndication               CRITICALITY ignore  TYPE AuthenticatedIndication               PRESENCE optional   }|
  { ID id-NPN-AccessInformation                 CRITICALITY reject  TYPE NPN-AccessInformation                 PRESENCE optional   },
  ...
}

SQL에 비유하자면, information object class는 CREATE를 이용한 DB 테이블 선언이고 CLASS 안의 각 필드는 테이블의 각 컬럼에 매칭된다. information object는 한 row에, information object set은 여러 개의 row에 해당된다고 이해하면 될 것 같다.

SEQEUNCE, SEQUENCE OF

SEQUENCE와 SEQUENCE OF는 (OF 하나 차이지만) 전혀 다른 타입을 정의한다.

SEQUENCE는 여러 요소로 구성된 복합 데이터 타입을 나타낸다. 즉, 각 요소가 순서 대로 나열되어 있으며, 각 요소는 서로 다른 타입일 수 있다. C 언어의 struct 구조체와 유사한 개념으로 생각할 수 있다.

ProtocolIE-Field {NGAP-PROTOCOL-IES : IEsSetParam} ::= SEQUENCE {
  id           NGAP-PROTOCOL-IES.&id           ({IEsSetParam}),
  criticality  NGAP-PROTOCOL-IES.&criticality  ({IEsSetParam}{@id}),
  value        NGAP-PROTOCOL-IES.&Value        ({IEsSetParam}{@id})
}

SEQUENCE ... OF는 동일한 데이터 타입의 요소가 순차적으로 나열된 배열 또는 리스트를 나타낸다. 요소는 모두 같은 타입이어야 하지만 배열의 크기는 가변적일 수 있다. 배열 또는 리스트와 유사한 개념으로 생각할 수 있다.

ProtocolIE-Container {NGAP-PROTOCOL-IES : IEsSetParam} ::=
  SEQUENCE (SIZE (0..maxProtocolIEs)) OF
    ProtocolIE-Field {{IEsSetParam}}

NGAP-PROTOCOL-IES 클래스를 사용하여 정의된 ProtocolIE-Field IE의 시퀀스(배열)를 담는 컨테이너이다. 시퀀스의 크기는 0에서 maxProtocolIEs까지이다.

ProtocolIE-ContainerProtocolIE-Field는 NGAP 메시지의 주요 요소를 정의하는데 사용되는 핵심 구조이다. 매개변수화된 NGAP-PROTOCOL-IES 클래스를 사용하여 다양한 IE들을 나타낼 수 있다.

ProtocolIE-Field {} 정의의 경우 SEQUENCE를 사용하여 여러 필드로 구성된 구조를 정의하는 반면, ProtocolIE-Container {}에서는 SEQUENCE OF를 사용하여 동일한 타입의 여러 ProtocolIE-Field 요소를 포함하는 배열을 정의하고 있다.

— END OF POST.