KR20160082967A - M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 - Google Patents

Abstract

본 발명은 M2M(Machine-to-Machine) 시스템에서 자원 구독(resource subscription)을 위한 메시지 처리 방법 및 이를 위한 장치에 관한 것으로서, 제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며; 상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하는 단계; 상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하는 단계; 상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하는 단계; 및 상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하는 단계를 포함하되, 상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며, 상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함하는 방법 및 이를 위한 장치에 관한 것이다.

Description

M2M 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치{METHOD FOR SUBSCRIPTION AND NOTIFICATION IN M2M COMMUNICATION SYSTEM AND DEVICE THEREFOR}

본 발명은 M2M(Machine-to-Machine) 통신 시스템에 관한 것으로서, 보다 구체적으로 M2M 시스템에서 특정 자원을 구독하고 통지하는 방법 및 이를 위한 장치에 관한 것이다.

근래에 들어 M2M(Machine-to-Machine) 통신에 대한 관심이 높아지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미하며, MTC(Machine Type Communication) 또는 IoT(Internet of Things) 통신으로도 지칭된다. M2M 통신에 사용되는 단말을 M2M 디바이스(M2M device)라고 지칭하는데, M2M 디바이스는 일반적으로 낮은 이동성(low mobility), 시간 내성(time tolerant) 또는 지연 내성(delay tolerant), 작은 데이터 전송(small data transmission)등과 같은 특성을 가지며, 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용된다. 또한, M2M 디바이스가 서로 다른 통신 방식을 따라 연결되면, 통신 방식이 변경되는 구간에서 M2M 게이트웨이를 통해 M2M 디바이스와 M2M 서버가 연결되며, 이를 통해 전체 M2M 시스템이 구성된다. 해당 시스템을 기반으로 사물 추적(Tracking), 전력 계량(Metering), 자동 지불 시스템(Payment), 의료 분야 서비스, 원격 조정 등의 서비스가 제공될 수 있다.

본 발명은 M2M 시스템에 관한 것이다.

본 발명의 목적은 M2M 시스템에서 효율적으로 신호를 송수신하는 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 다른 목적은 M2M 시스템에서 권한 확인(privilege check)을 효율적으로 수행하는 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 또 다른 목적은 M2M 시스템에서 구독/통신 메커니즘을 이용한 악의적인 공격을 방지하기 위한 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 또 다른 목적은 M2M 시스템에서 특정 자원을 호스팅하는 장치의 권한에 대한 무단 도용을 방지하기 위한 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 또 다른 목적은 M2M 시스템에서 구독/통신 메커니즘의 악의적인 사용 또는 무단 도용을 방지함으로써 네트워크 부하 증가 및/또는 시스템 성능 저하를 방지하기 위한 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명에서 이루고자 하는 기술적 과제들은 상기 기술적 과제로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 양상으로, M2M(Machine-to-Machine) 디바이스에서 자원 구독(resource subscription)을 위한 메시지 처리 방법이 제공되며, 상기 방법은 제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며; 상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하는 단계; 상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하는 단계; 상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하는 단계; 및 상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하는 단계를 포함하되, 상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며, 상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함할 수 있다.

본 발명의 다른 양상으로, M2M(Machine-to-Machine) 디바이스가 제공되며, 상기 M2M 디바이스는 네트워크 인터페이스 유닛(Network Interface Unit); 및 상기 네트워크 인터페이스 유닛과 동작시 연결되는(operatively connected) 프로세서를 포함하며, 상기 프로세서는 제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하고, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며, 상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하고, 상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하고, 상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하고, 상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하도록 구성되며, 상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며, 상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함할 수 있다.

바람직하게는, 상기 제2 디바이스에 의한 권한 확인은 상기 M2M 디바이스가 상기 제2 디바이스로 통지 메시지를 전송할 수 있는 권한을 가지는지 여부를 확인하는 것을 포함할 수 있다.

바람직하게는, 상기 제2 디바이스에 의한 권한 확인은 상기 제1 디바이스가 상기 제2 디바이스로 통지 메시지를 전송하기 위한 구독을 설정할 수 있는 권한을 가지는지 여부를 확인하는 것을 더 포함할 수 있다.

바람직하게는, 상기 방법은 상기 제2 디바이스로 상기 통지 메시지를 전송하는 단계 전에, 상기 제1 디바이스로 상기 구독 요청 메시지에 대한 임시 수락 메시지를 전송하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 방법은 상기 제2 디바이스에 의한 권한 확인의 결과가 성공인지 여부를 판별하는 단계; 상기 권한 확인의 결과가 성공인 경우, 상기 제1 디바이스로 구독 승인 메시지를 전송하는 단계; 및 상기 권한 확인의 결과가 실패인 경우, 상기 자원 구독을 취소하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 방법은 상기 권한 확인 결과가 실패인 경우, 상기 자원 구독이 취소되었음을 알리는 메시지를 상기 제1 디바이스로 전송하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며, 상기 방법은 상기 구독 정보를 임시로 저장하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며, 상기 방법은 상기 구독 정보를 기반으로 구독 자원을 생성하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 제1 디바이스의 식별 정보는 상기 구독 자원의 생성자 속성 정보에 저장될 수 있다.

바람직하게는, 상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트가 발생되는 경우 생성되며, 상기 통지 이벤트는 상기 구독 대상 자원의 상태 변화를 포함할 수 있다.

바람직하게는, 상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트의 발생과 독립적으로 생성될 수 있다.

바람직하게는, 상기 제1 디바이스의 식별 정보는 상기 구독 요청 메시지의 발신자의 식별 정보를 지시하는 주소 정보를 포함하며, 상기 제2 디바이스의 식별 정보는 상기 통지 메시지의 통지 대상을 지시하는 주소 정보를 포함할 수 있다.

바람직하게는, 상기 자원은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타낼 수 있다.

바람직하게는, 상기 구독 요청 메시지에서 응답 메시지 타입 정보는 블록킹 요청, 동기식 논-블록킹 요청, 비동기식 논-블록킹 요청 중 하나를 지시할 수 있다.

본 발명에 의하면, M2M 시스템에서 효율적으로 신호를 송수신할 수 있다.

또한, 본 발명에 의하면, M2M 시스템에서 권한 확인(privilege check)을 효율적으로 수행할 수 있다.

또한, 본 발명에 의하면, M2M 시스템에서 구독/통신 메커니즘을 이용한 악의적인 공격을 방지할 수 있다.

또한, 본 발명에 의하면, M2M 시스템에서 특정 자원을 호스팅하는 장치의 권한에 대한 무단 도용을 방지할 수 있다.

또한, 본 발명에 의하면, M2M 시스템에서 구독/통신 메커니즘의 악의적인 사용 또는 무단 도용을 방지함으로써 네트워크 부하 증가 및/또는 시스템 성능 저하를 방지할 수 있다.

본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

첨부 도면은 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되며, 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 M2M 시스템을 예시한다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다.
도 4는 M2M 시스템의 구성을 예시한다.
도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.
도 6은 일반적인 M2M 시스템의 통신 흐름을 예시한다.
도 7과 도 8은 블록킹 요청(blocking request)을 기반으로 리소스를 액세스하기 위한 절차를 예시한다.
도 9와 도 10은 동기식 논-블록킹 요청을 기반으로 리소스를 액세스하기 위한 절차를 예시한다.
도 11은 비동기식 논-블록킹 요청을 기반으로 리소스를 액세스하기 위한 절차를 예시한다.
도 12는 구독 자원과 관련된 절차를 예시한다.
도 13은 통지를 위한 절차를 예시한다.
도 14는 구독-통지 절차와 관련된 문제를 예시한다.
도 15 내지 도 17은 본 발명에 따른 구독 및 통지 절차를 예시한다.
도 18는 본 발명이 적용될 수 있는 장치의 블록도를 예시한다.

본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시예를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시예를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 본 발명이 속하는 분야에서 통상의 기술자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서에서 동일한 구성요소에 대해 동일한 도면 부호가 사용될 수 있다.

본 명세서에서, M2M 디바이스(M2M device)는 M2M(Machine-to-Machine) 통신을 위한 디바이스를 지칭한다. M2M 디바이스는 고정되거나 이동성을 가질 수 있으며 M2M 서버와 통신하여 사용자 데이터 및/또는 제어 정보를 송수신할 수 있다. M2M 디바이스는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선 장치(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대 장치(handheld device) 등으로 지칭될 수 있다. 본 발명에 있어서, M2M 서버는 M2M 통신을 위한 서버를 지칭하며 고정국(fixed station) 또는 이동국(mobile station)으로 구현될 수 있다. M2M 서버는 M2M 디바이스들 및/또는 다른 M2M 서버와 통신하여 데이터 및 제어 정보를 교환할 수 있다. 또한, M2M 게이트웨이는 M2M 디바이스가 연결된 네트워크와 M2M 서버가 연결된 네트워크가 서로 다른 경우, 한 네트워크에서 다른 네트워크로 들어가는 연결점 역할을 수행하는 장치를 지칭한다. 또한, M2M 게이트웨이는 M2M 디바이스로서 기능을 수행할 수 있으며, 이외에 예를 들어 M2M 게이트웨이에 연결된 M2M 디바이스를 관리하거나, 하나의 메시지를 수신하여 연결된 M2M 디바이스들에게 동일 또는 변경된 메시지를 전달하거나(message fanout), 메시지 집적(message aggregation)하는 기능을 수행할 수 있다. M2M 디바이스라는 용어는 M2M 게이트웨이와 M2M 서버를 포함하는 개념으로 사용될 수 있고, 따라서 M2M 게이트웨이와 M2M 서버는 M2M 디바이스로 지칭될 수 있다.

또한, 본 명세서에서 “엔티티(entity)”라는 용어는 M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭하는 데 사용될 수 있고, 또는 아래에서 설명되는 M2M 애플리케이션 계층과 M2M (공통) 서비스 계층의 소프트웨어 컴포넌트(software component)를 지칭하는 데 사용될 수 있다.

이하에서, 본 발명은 M2M 시스템을 중심으로 설명되지만 본 발명은 M2M 시스템에만 제한적으로 적용되는 것은 아니며, 예를 들어 클라이언트-서버(또는 송신자-응답자(sender-responder)) 모델에 따른 시스템에도 동일/유사하게 적용될 수 있다.

도 1은 M2M 시스템을 예시한다. 도 1은 ETSI(European Telecommunications Standards Institute) 기술 규격(Technical Specification, TS)에 따른 M2M 시스템을 예시한다.

ETSI TS M2M 기술 규격에 따른 M2M 시스템은 다양한 M2M 애플리케이션(Application)을 위한 공통 M2M 서비스 프레임워크(Service Framework)를 정의한다. M2M 애플리케이션은 e헬스(e-Health), 도시 자동화(City Automation), 커넥티드 컨슈머(Connected Consumer), 오토모티브(Automotive)와 같은 M2M 서비스 솔루션을 구현하는 소프트웨어 컴포넌트(software component)를 지칭할 수 있다. M2M 시스템에서는 이러한 다양한 M2M 애플리케이션을 구현하기 위해 공통적으로 필요한 기능들을 제공되며, 공통적으로 필요한 기능들은 M2M 서비스 또는 M2M 공통 서비스라고 지칭될 수 있다. 이러한 M2M 공통 서비스를 이용하면 각 M2M 애플리케이션마다 기본 서비스 프레임워크를 다시 구성할 필요 없이 M2M 애플리케이션이 쉽게 구현될 수 있다.

M2M 서비스는 서비스 능력(Service Capability, SC)의 집합 형태로 제공되며, M2M 애플리케이션은 오픈 인터페이스(open interface)를 통해 SC(Service Capability)의 집합 또는 SC(Service Capability)에 접근하여 SC(Service Capability)가 제공하는 M2M 서비스 또는 기능을 이용할 수 있다. SC는 M2M 서비스를 구성하는 기능 (예, 디바이스 관리, 위치, 발견, 그룹 관리, 등록, 보안 등)을 제공할 수 있고, SC 계층(Service Capabilities Layer) 또는 SC 엔티티(Service Capability Entity)는 M2M 애플리케이션이 서비스 프레임워크 상에서 제공될 때 사용할 수 있는 M2M 서비스를 위한 기능(function)들의 집합이라고 할 수 있다.

SC(Service Capability)는 xSC로 표현될 수 있다. 여기서, x는 N/G/D 중의 하나로 표현될 수 있으며, SC(Service Capability)가 네트워크(Network)(및/또는 서버), 게이트웨이(Gateway), 디바이스(Device) 중 어디에 존재하는지를 나타낸다. 예를 들어, NSC는 네트워크 및/또는 서버 상에 존재하는 SC(Service Capability)를 나타내고, GSC는 게이트웨이 상에 존재하는 SC(Service Capability)를 나타낸다.

M2M 애플리케이션은 네트워크, 게이트웨이, 또는 디바이스 상에 존재할 수 있다. 네트워크 상에 존재하거나 서버와 직접 연결되어 존재하는 M2M 애플리케이션은 M2M 네트워크 애플리케이션(M2M Network Application)라고 지칭되며 간략히 NA(Network Application)로 나타낼 수 있다. 예를 들어, NA는 서버에 직접 연결되어 구현되는 소프트웨어이며, M2M 게이트웨이 또는 M2M 디바이스와 통신하고 이들을 관리하는 역할을 수행할 수 있다. 디바이스 상에 존재하는 M2M 애플리케이션은 M2M 디바이스 애플리케이션(M2M Device Application)이라고 지칭되며 간략히 DA(Device Application)로 나타낼 수 있다. 예를 들어, DA는 M2M 디바이스에서 구동되는 소프트웨어이며, 센서 정보 등을 NA에게 전달할 수도 있다. 게이트웨이 상에 존재하는 M2M 애플리케이션은 M2M 게이트웨이 애플리케이션(Gateway Application)이라고 지칭되며 간략히 GA(Gateway Application)로 나타낼 수 있다. 예를 들어, GA는 M2M 게이트웨이를 관리하는 역할도 할 수 있고 DA에게 M2M 서비스 또는 기능(예, SCs(Service Capabilities) 또는 SC(Service Capability))를 제공할 수도 있다. M2M 애플리케이션은 애플리케이션 엔티티(AE)와 애플리케이션 계층을 통칭할 수 있다.

도 1을 참조하면, M2M 시스템 아키텍처는 네트워크 도메인과 디바이스 및 게이트웨이 도메인으로 구분될 수 있다. 네트워크 도메인은 M2M 시스템 관리를 위한 기능(function)들과 네트워크 관리를 위한 기능(function)들을 포함할 수 있다. M2M 시스템 관리를 위한 기능은 디바이스 및 게이트웨이 도메인에 존재하는 디바이스들을 관리하는 M2M 애플리케이션과 M2M SCs(Service Capabilities)에 의해 수행될 수 있고, 네트워크 관리를 위한 기능은 코어 네트워크와 액세스 네트워크에 의해 수행될 수 있다. 따라서, 도 1의 예에서, 코어 네트워크와 액세스 네트워크는 M2M 기능을 수행한다기보다는 각 엔티티들 간의 연결을 제공한다. 코어 네트워크와 액세스 네트워크를 통해 네트워크 도메인과 디바이스 및 게이트웨이 도메인에서 M2M SCs(Service Capabilities) 간에 M2M 통신이 수행될 수 있으며, 각 도메인의 M2M 애플리케이션은 각 도메인의 M2M SCs(Service Capabilities)를 통해 신호 또는 정보를 주고 받을 수 있다.

액세스 네트워크(Access Network)는 M2M 디바이스 및 게이트웨이 도메인이 코어 네트워크와 통신을 가능하게 하는 엔티티이다. 액세스 네트워크의 예로는 xDSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax), 위성(satellite), GERAN, UTRAN, eUTRAN, 무선(Wireless) LAN, WiMAX 등이 있다.

코어 네트워크(Core Network)는 IP(Internet Protocol) 연결, 서비스와 네트워크 제어, 상호연결, 로밍(roaming) 등의 기능을 제공하는 엔티티이다. 코어 네트워크는 3GPP(3rd Generation Partnership Project) 코어 네트워크, ETSI TISPAN(Telecommunications and Internet converged Services and Protocols for Advanced Networking) 코어 네트워크와 3GPP2 코어 네트워크 등을 포함한다.

M2M SC(Service Capability)는 여러 M2M 네트워크 애플리케이션들에서 공유될 수 있는 M2M 공통 서비스 기능(Common Service Function, CSF)을 제공하고 M2M 서비스를 오픈 인터페이스(open interface)를 통해 노출하여 M2M 애플리케이션들이 M2M 서비스를 이용할 수 있게 한다. M2M SCL(Service Capability Layer)은 이러한 M2M SC 엔티티들 또는 M2M 공통 서비스 기능들을 포함하는 계층을 지칭할 수 있다.

M2M 애플리케이션은 서비스 로직(service logic)을 동작시키고, 오픈 인터페이스를 통해 M2M SCs(Service Capabilities)를 사용할 수 있는 엔티티이다. M2M 애플리케이션 계층은 이러한 M2M 애플리케이션 및 관련 동작 로직(operational logic)을 포함하는 계층을 지칭할 수 있다.

M2M 디바이스는 M2M SCs(Service Capabilities)를 통해 M2M 디바이스 애플리케이션을 동작시키는 엔티티이다. M2M 디바이스는 직접 네트워크 도메인의 M2M 서버와 통신할 수도 있으며, M2M 게이트웨이를 통해서 네트워크 도메인의 M2M 서버와 통신할 수도 있다. M2M 게이트웨이를 통해서 연결될 경우에는 M2M 게이트웨이는 프록시(proxy)와 같이 동작한다. M2M 디바이스는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.

M2M 영역 네트워크(M2M area network)는 M2M 디바이스와 M2M 게이트웨이 간의 연결(connectivity)을 제공한다. 이 경우, M2M 게이트웨이와 M2M 서버 간 네트워크와 M2M 디바이스와 M2M 게이트웨이 간 네트워크가 서로 상이할 수 있다. 예를 들어, M2M 영역 네트워크는 IEEE802.15.1, 지그비(Zigbee), 블루투스(Bluetooth), IETF ROLL, ISA100.11a와 같은 PAN(Personal Area Network) 기술과 PLC(Power Line Communication), M-BUS, 무선 M-BUS, KNX와 같은 로컬 네트워크 기술을 이용하여 구현될 수 있다.

M2M 게이트웨이는 M2M SCs(Service Capabilities)를 통해 M2M 애플리케이션을 관리하고 M2M 애플리케이션에 대해 서비스를 제공하는 엔티티이다. M2M 게이트웨이는 M2M 디바이스와 네트워크 도메인간의 프록시 역할을 수행하고 ETSI 비-호환(non-compliant) M2M 디바이스에도 서비스를 제공하는 역할을 수행할 수 있다. M2M 게이트웨이는 M2M 디바이스들 중 게이트웨이 기능을 갖는 엔티티를 지칭할 수 있다. M2M 게이트웨이는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.

도 1에 예시된 M2M 시스템 아키텍처는 예시에 불과하고 각 엔티티의 명칭은 달라질 수 있다. 예를 들어, M2M SC(Service Capability)는 M2M 공통 서비스 기능(common service function, CSF)로 지칭될 수 있고, SCL(Service Capability Layer)는 공통 서비스 계층(Common Service Layer, CSL) 또는 공통 서비스 엔티티(Common Service Entity, CSE)으로 지칭될 수 있다. 또한, M2M 애플리케이션은 애플리케이션 엔티티(application entity, AE)로 지칭될 수 있고, M2M 애플리케이션 계층은 간략히 애플리케이션 계층으로 지칭될 수 있다. 마찬가지로, 각 도메인의 명칭 또한 달라질 수 있다. 예를 들어, oneM2M 시스템에서 네트워크 도메인은 인프라스트럭처 도메인(infrastructure domain)으로 지칭될 수 있고, 디바이스 및 게이트웨이 도메인은 필드 도메인(field domain)으로 지칭될 수 있다.

도 1에 예시된 바와 같이, M2M 시스템은 M2M 통신을 위해 M2M 애플리케이션 계층과 M2M SC(Service Capability) 계층을 포함하는 계층 구조로서 이해될 수 있다.

도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.

도 2를 참조하면, M2M 시스템은 애플리케이션 계층(202), 공통 서비스 계층(204), 기저 네트워크 서비스 계층(underlying network services layer)(206)을 포함할 수 있다. 앞서 설명된 바와 같이, 애플리케이션 계층(202)은 M2M 애플리케이션 계층에 대응되고, 공통 서비스 계층(204)은 M2M SCL에 대응될 수 있다. 기저 네트워크 서비스 계층(206)은 코어 네트워크에 존재하는 장치 관리(device management), 위치 서비스(location service), 및 장치 트리거링(device triggering)과 같은 서비스들을 공통 서비스 계층(204)에 제공한다.

도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다. 기능적인 측면에서 M2M 시스템 아키텍처는 애플리케이션 엔티티(application entity, AE)(302), 공통 서비스 엔티티(common service entity, CSE)(304), 기저(underlying) 네트워크 서비스 엔티티(network service entity, NSE)(306)를 포함할 수 있다. 각 엔티티들(302, 304, 306)은 공통 서비스 엔티티(304)가 지원하는 기준점(reference point)을 통해 통신할 수 있다. 기준점(reference point)은 각 엔티티들(302, 304, 306) 간의 통신 흐름(communication flow)를 지정하는 역할을 한다. 기준점은 Mcx로 표현될 수 있고 Mc는 “M2M communications”을 의미한다. 본 명세서에서 Mca 기준점, Mcc 기준점, Mcn 기준점은 각각 Mca, Mcc, Mcn으로 표기될 수 있다.

도 3을 참조하면, Mca 기준점(312)은 애플리케이션 엔티티(AE)(302)와 공통 서비스 엔티티(CSE)(304)의 통신 흐름을 지정한다. Mca 기준점(312)은 AE(302)가 CSE(304)에 의해 제공되는 서비스를 이용할 수 있게 하고 CSE(304)가 AE(302)와 통신할 수 있게 한다. Mca 기준점(312)은 M2M 애플리케이션 계층과 M2M 공통 서비스 계층(또는 엔티티) 간의 인터페이스를 지칭할 수 있다.

Mcc 기준점(314)은 서로 다른 공통 서비스 엔티티(CSE)(304)들 간의 통신 흐름을 지정한다. Mcc 기준점(314)은 CSE(304)가 필요한 기능들을 제공할 때 다른 CSE의 서비스를 이용할 수 있게 한다. Mcc 기준점(314)을 통해 제공되는 서비스는 CSE(304)가 지원하는 기능들에 의존적일 수 있다. Mcc 기준점(314)은 M2M 공통 서비스 계층들 간의 인터페이스를 지칭할 수 있다.

Mcn 기준점(316)은 CSE(304)와 기저 네트워크 서비스 엔티티(NSE)(306) 간의 통신 흐름을 지정한다. Mcn 기준점(316)은 CSE(304)가 요구된 기능들을 제공하기 위해 기저 NSE(306)가 제공하는 서비스를 이용할 수 있게 한다. Mcn 기준점(316)은 M2M 공통 서비스 계층과 M2M 기저 네트워크 계층 간의 인터페이스를 지칭할 수 있다.

또한, 도 3의 예에서, CSE(304)는 다양한 공통 서비스 기능(common service function, CSF)들을 제공할 수 있다. 예를 들어, CSE(304)는 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management) 기능, 통신 관리 및 전달 처리(Communication Management and Delivery Handling) 기능, 데이터 관리 및 저장(Data Management and Repository) 기능, 장치 관리(Device Management) 기능, 그룹 관리(Group Management) 기능, 발견(Discovery) 기능, 위치(Location) 기능, 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering) 기능, 등록(Registration) 기능, 보안(Security) 기능, 서비스 과금 및 계산(Service Charging and Accounting) 기능, 서비스 세션 관리 기능(Service Session Management), 구독/통지(Subscription/Notification) 기능 중에서 적어도 하나를 포함할 수 있다. CSE(304)는 상기 공통 서비스 기능들의 인스턴스(instance)를 가리키며, M2M 애플리케이션들이 사용하고 공유할 수 있는 공통 서비스 기능들의 서브세트를 제공한다. 공통 서비스 기능들을 개략적으로 설명하면 다음과 같다.

- 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management, ASM): AE들과 CSE들의 관리 기능을 제공한다. 예를 들어, ASM 기능은 CSE들의 기능을 설정(configure)하고 문제점을 해결(troubleshoot)하고 업그레이드(upgrade)할 뿐만 아니라 AE들의 기능을 업그레이드할 수 있다.

- 통신 관리 및 전달 처리(Communication Management and Delivery Handling, CMDH): 다른 CSE들, AE들, NSE들과의 통신을 제공한다. 예를 들어, CMDH 기능은 CSE-CSE 통신(CSE-to-CSE communication)을 위한 연결(connection)을 언제 어떻게 사용할지를 결정하고 특정 요청들이 지연 전달될 수 있도록 제어할 수 있다.

- 데이터 관리 및 저장(Data Management and Repository, DMR): M2M 애플리케이션들이 데이터를 교환, 공유할 수 있게 한다. 예를 들어, DMR 기능은 대량의 데이터를 수집(collecting)/병합(aggregating)하고 데이터를 특정 포맷으로 변환(converting)하고 저장(storing)할 수 있다.

- 장치 관리(Device Management, DMG): M2M 게이트웨이 및 M2M 디바이스 뿐만 아니라 M2M 영역 네트워크에 존재하는 디바이스들에 대한 디바이스 기능을 관리한다. 예를 들어, DMG 기능은 애플리케이션 설치 및 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 네트워크 토폴로지(Topology) 관리 등을 수행할 수 있다.

- 발견(Discovery, DIS): 주어진 범위 및 조건 내에서 요청에 따라 정보 및 리소스(resource)와 같은 정보를 검색(searching)한다.

- 그룹 관리(Group Management, GMG): 예를 들어 리소스(resource), M2M 디바이스, 또는 M2M 게이트웨이를 묶어 그룹을 생성할 수 있는데 그룹 관련 요청을 핸들링(handling)한다.

- 위치(Location, LOC): M2M 애플리케이션이 M2M 디바이스 또는 M2M 게이트웨이의 위치 정보를 획득하는 역할을 수행한다.

- 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering, NSSE): 기저 네트워크의 통신을 가능하게 하고 기저 네트워크가 제공하는 서비스 또는 기능을 사용할 수 있게 한다.

- 등록(Registration, REG): M2M 애플리케이션 또는 다른 CSE가 특정 CSE에 등록을 처리하는 역할을 수행한다. 등록은 특정 CSE의 M2M 서비스 기능을 사용하기 위해 수행된다.

- 보안(Security, SEC): 보안 키와 같은 민감한 데이터 핸들링, 보안 연관 관계(Association) 설립, 인증(Authentication), 권한 부여(Authorization), ID(Identity) 보호 등의 역할을 수행한다.

- 서비스 과금 및 계산(Service Charging and Accounting, SCA): AE 또는 CSE에 과금 기능을 제공하는 역할을 수행한다.

- 서비스 세션 관리(Service Session Management, SSM): 단대단(end-to-end) 통신을 위한 서비스 계층의 M2M 세션을 관리하는 역할을 수행한다.

- 구독/통지(Subscription/Notification, SUB): 특정 리소스(resource)에 대한 변경을 구독(Subscription)하면 해당 리소스(resource)이 변경되면 이를 통지(notification)하는 역할을 수행한다.

도 4는 M2M 시스템의 구성을 예시한다. 본 명세서에서, 노드(node)는 하나 이상의 M2M 애플리케이션을 포함하는 엔티티 또는 하나의 CSE와 0개 이상의 M2M 애플리케이션을 포함하는 엔티티를 의미한다.

애플리케이션 전용 노드(Application Dedicated Node, ADN)는 적어도 하나의 애플리케이션 엔티티(AE)를 가지지만 공통 서비스 엔티티(CSE)를 가지지 않는 노드를 지칭할 수 있다. ADN은 Mca를 통해 하나의 중간 노드(Middle Node, MN) 또는 하나의 인프라스트럭처 노드(Infrastructure Node, IN)와 통신할 수 있다. ADN은 제한된 능력을 갖는 M2M 디바이스(M2M device having a constrained capability)로 지칭될 수 있는데, 제한된 능력을 갖는 M2M 디바이스는 공통 서비스 계층(common service layer) 또는 공통 서비스 엔티티(CSE)를 포함하지 않는 M2M 디바이스를 지칭할 수 있다. 제한된 능력을 갖는 M2M 디바이스는 간략히 제한적인 M2M 디바이스(constrained M2M device)라고 지칭될 수 있다.

애플리케이션 서비스 노드(Application Service Node, ASN)는 적어도 하나의 공통 서비스 엔티티(CSE)를 가지고 적어도 하나의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. ASN은 Mcc를 통해 하나의 중간 노드(Middle Node) 또는 하나의 인프라스트럭처 노드(Infrastructure Node)와 통신할 수 있다. ASN은 M2M 디바이스로 지칭될 수 있다.

중간 노드(Middle Node, MN)는 하나의 공통 서비스 엔티티(CSE)와 0개 이상의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. MN은 Mcc를 통해 하나의 인프라스트럭처 노드(IN) 또는 다른 중간 노드(MN)와 통신할 수 있으며, 혹은 Mcc를 통해 IN/MN/ASN과 통신할 수 있으며, 혹은 Mca를 통해 ADN과 통신할 수 있다. MN은 M2M 게이트웨이로 지칭될 수 있다.

인프라스트럭처 노드(Infrastructure Node, IN)는 하나의 공통 서비스 엔티티(CSE)를 가지고 0개 이상의 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. IN은 Mcc를 통해 적어도 하나의 중간 노드(MN)와 통신할 수 있고, 및/또는 적어도 하나의 ASN과 통신할 수 있다. 혹은 IN은 Mca를 통해 하나 이상의 ADN과 통신할 수 있다. IN은 M2M 서버로 지칭될 수 있다.

도 4를 참조하면, 예 1은 ADN과 IN 간의 통신을 예시한다. ADN은 제한된 능력을 갖는 M2M 디바이스일 수 있다. 이 경우, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 Mca를 통해 IN의 CSE와 통신할 수 있다. 또한, 이 경우, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, 예 1에서 ADN의 AE 또는 애플리케이션 계층에서 생성된 데이터는 IN의 CSE에 저장되어 공유될 수 있다.

예 2는 ADN과 MN 간의 통신을 예시한다. ADN도 제한된 능력을 갖는 M2M 디바이스일 수 있다. 따라서, ADN이 MN의 CSE과 통신한다는 점을 제외하고 예 1과 유사하게 동작할 수 있다. 즉, ADN은 Mca를 통해 MN의 CSE와 통신할 수 있다. 또한, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, ADN의 AE 또는 애플리케이션 계층에서 생성된 데이터는 MN의 CSE에 저장되어 공유될 수 있다.

한편, 예 2에서 MN은 MN을 거쳐 IN과 통신할 수 있다. 이 경우 MN과 MN, 그리고 MN과 IN은 Mcc를 통해 통신할 수 있다. MN이 MN을 거치지 않고 직접 IN과 통신하는 것도 가능하다.

예 3은 ASN과 MN 간의 통신을 예시한다. 예 1 또는 예 2와 달리, ASN은 CSE 또는 공통 서비스 계층을 가지므로 ASN의 AE 또는 애플리케이션 계층에서 생성된 데이터를 자신의 CSE 또는 공통 서비스 계층에 저장할 수 있다. 또한, ASN의 AE는 ASN의 CSE를 통해 MN의 CSE와 통신할 수 있다.

예 4는 ASN과 MN 간의 통신을 예시한다. 예 3과 비교하여, ASN의 CSE는 MN을 거치지 않고 직접 IN의 CSE와 통신할 수 있다.

IN은 인프라스트럭처 도메인 또는 네트워크 도메인에 위치할 수 있고 하나의 CSE를 포함하고 0개 이상의 AE를 포함할 수 있다. IN들은 Mcc를 통해 서로 통신할 수 있다.

도 5는 M2M 시스템에서 사용되는 자원 또는 리소스(resource)를 예시한다.

M2M 시스템에서 애플리케이션 엔티티(AE), CSE, 데이터 등은 리소스(resource)로서 표현될 수 있다. M2M 시스템에서 리소스는 고유한 주소(예, URI(Universal Resource Identifier 또는 Uniform Resource Identifier))를 이용하여 고유하게 어드레싱 가능한 엔티티(uniquely addressable entity)를 지칭한다. 예를 들어, URI는 HTTP/COAP 등의 프로토콜 정보를 포함하는 주소 정보를 지칭한다. M2M 시스템에서 리소스는 특정 데이터 구조로서 표현되며 각 리소스는 서로 논리적으로 연결될 수 있다. 리소스는 CSE 또는 공통 서비스 계층에 의해 관리되고 저장될 수 있다. 따라서, M2M 디바이스, M2M 게이트웨이, M2M 서버의 CSE 또는 공통 서비스 계층에서는 이러한 리소스를 가질 수 있다. 반면, M2M 시스템의 AE 또는 애플리케이션 계층에서는 이러한 리소스 구조를 가질 수 없다. 각 리소소는 자녀 리소스와 속성을 가질 수 있으며 자녀 리소스와 속성들도 역시 고유하게 어드레싱 가능하다. M2M 리소스에서 루트(Root) 리소스는 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 예를 들어, 리소스는 트리 구조로서 표현될 수 있다. 예를 들어, 루트 리소스의 타입은 <baseURI> 또는 <CSEBase>로 표시될 수 있다. 리소스의 타입은 “<”과 “>”에 의해 표시될 수 있다.

M2M 시스템에서는 다양한 리소스 타입이 정의되는데 M2M 애플리케이션들은 리소스 타입이 실체화(Instantiation)된 리소스를 기반으로 통신을 수행할 수 있다. 예를 들어, 애플리케이션을 등록하고 센서 값을 읽어 오는 등의 M2M 서비스를 수행하는 데 사용될 수 있다. 각각의 리소스는 해당 리소스 타입의 인스턴스가 생성될 때 고유한 주소 정보(예, URI)가 주어지며, 루트 리소스와 동일하게 속성 및 자녀 리소스를 가질 수 있으며 각 리소스들은 고유한 주소 정보를 이용하여 어드레싱될 수 있다. 특정 리소스 타입은 해당 리소스가 실체화(Instantiation)되었을 때 가질 수 있는 자식 리소스와 속성을 정의한다. 특정 리소스 실체화(Instantiation) 시 리소스는 해당 리소스의 리소스 타입에 정의된 속성과 자식 리소스를 가질 수 있다.

속성은 리소스 자체에 대한 정보를 저장하며 자녀 리소스를 가질 수 없다. 자녀 리소스는 자신의 속성과 자신의 자녀 리소스를 가질 수 있으며, 예를 들어 자녀 리소스에는 원격 CSE 리소스, 애플리케이션 엔티티 리소스, 접근 제어 리소스, 컨테이너 리소스, 그룹 리소스, 구독 리소스 등이 있다.

- 원격 CSE 리소스는 해당 CSE에 등록(연결)된 다른 CSE의 정보를 포함한다. 예를 들어, 원격 CSE 리소스의 타입은 <entity> 또는 <remoteCSE>으로 표시될 수 있다.

- 애플리케이션 엔티티 리소스: 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>) 또는 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재하는 리소스이며, 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>)의 하위에 존재할 경우 해당 CSE에 등록(연결)된 애플리케이션 엔티티의 정보가 저장되며, 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재할 경우 특정 원격 CSE에 등록된 애플리케이션 엔티티들의 정보를 저장한다. 예를 들어, 애플리케이션 엔티티 리소스의 타입은 <application> 또는 <AE>로 표시될 수 있다.

- 접근 제어 리소스: 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여 권한 부여(authorization)가 이루어질 수 있다. 예를 들어, 접근 제어 리소스의 타입은 <accessRight> 또는 <accessControlPolicy>으로 표시될 수 있다.

- 컨테이너 리소스: CSE 또는 AE 별로 생성되는 데이터를 저장한다. 예를 들어, 컨테이너 리소스의 타입은 <container>로 표시될 수 있다.

- 그룹 리소스: 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공한다. 예를 들어, 그룹 리소스의 타입은 <group>으로 표시될 수 있다.

- 구독 리소스: 구독 대상 리소스의 상태가 변경되는 것을 통지(Notification)를 통해 알려주는 기능을 수행한다. 예를 들어, 구독 리소스의 타입은 <subscription>으로 표시될 수 있다.

도 6은 일반적인 M2M 시스템의 통신 흐름을 예시한다. 일반적으로 M2M 시스템의 동작은 데이터 교환을 기반으로 수행된다. 예를 들어, 특정 디바이스가 다른 디바이스의 동작을 멈추기 위해 해당 명령을 데이터 형태로 다른 장치에 전달할 수 있다. 디바이스 내에서 데이터를 저장하기 위해 특정 형태의 데이터 구조가 이용되는데 이러한 데이터 구조는 자원(Resource, 리소스)이라고 지칭될 수 있다. 자원은 고유의 주소(예, URI)를 이용하여 액세스할 수 있다.

도 6을 참조하면, AE와 CSE 간의 연결에서 또는 CSE들 간의 연결에서 요청 및 응답 방식(Request and Response Scheme)이 사용된다. 발신자(originator)는 수신자(receiver)에 저장된 자원(resource)을 요청하기 위해 요청 메시지를 전송하고 그에 대한 응답으로 응답 메시지를 수신할 수 있다. 마찬가지로, 수신자는 발신자로부터 자원을 요청하는 메시지를 수신하고 그에 대한 응답으로 응답 메시지를 발신자로 전송할 수 있다. 본 명세서에서, 요청 메시지는 요청으로 약칭될 수 있고 응답 메시지는 응답으로 약칭될 수 있다. 발신자에서 수신자로 전송되는 요청 메시지는 다음과 같은 정보를 포함할 수 있다.

- op: 실행되는 동작(Operation)의 형태. 생성(Create)/회수(Retrieve)/갱신(Update)/삭제(Delete)/통지(Notify) 중 하나일 수 있다. 본 명세서에서 동작에 해당하는 정보는 명령(command)라고 지칭될 수 있다. op가 생성으로 설정되는 경우 생성 요청 메시지(또는 생성 메시지 또는 생성 요청)라고 지칭될 수 있고, op가 회수로 설정되는 경우 회수 요청 메시지(또는 회수 메시지 또는 회수 요청)라고 지칭될 수 있고, op가 갱신으로 설정되는 경우 갱신 요청 메시지(또는 갱신 메시지 또는 갱신 요청)라고 지칭될 수 있고, op가 삭제로 설정되는 경우 삭제 요청 메시지(또는 삭제 메시지 또는 삭제 요청)라고 지칭될 수 있고, op가 통지로 설정되는 경우 통지 요청 메시지(또는 통지 메시지 또는 통지 요청)라고 지칭될 수 있다.

- to: 동작의 대상이 되는 리소스의 주소 정보(예, URI(Uniform Resource Identifier))

- fr: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID), 수신자가 액세스 권한 검증(access privilege verification)을 위해 발신자 식별 정보를 검사하는 데 이용될 수 있다. 발신자의 식별 정보는 발신자의 주소 정보(예< URI)를 포함할 수 있다.

- cn: 요청 메시지를 통해 전달되는 리소스 내용(resource content)

- rt: 응답 메시지 타입. 요청에 대하여 어떤 유형의 응답이 요청 발신자에게로 전송될 것인지 및 언제 응답이 요청 발신자에게로 전송될 것인지를 지시한다. 응답 메시지 타입은 예를 들어 동기식 논-블록킹 요청(Synchronous non-blocking request), 비동기식 논-블록킹 요청(asynchronous non-blocking request), 블록킹 요청(blocking request) 중 하나를 지시할 수 있다.

■ 응답 메시지 타입이 동기식 논-블록킹 요청을 지시하는 경우(예, rt = nonBlockingRequestSynch), 요청 수신자는 해당 요청을 수신한 후 해당 요청을 처리할 것을 확인(confirm)하는 확인응답(acknowledgement)을 포함하는 응답 메시지를 요청자로 전송할 수 있다. 요청 수신자는 요청의 상태 및 요청된 동작의 결과를 액세스하는 데 이용될 수 있는 레퍼런스(reference)를 응답 메시지에 포함시킬 수 있다. 동기식 논-블록킹 요청에 대해서는 도 9 및 도 10을 참조하여 더욱 자세히 설명한다.

■ 응답 메시지 타입이 비동기식 논-블록킹 요청을 지시하는 경우(예, rt = nonBlockingRequestAsynch), 요청 수신자는 해당 요청을 수신한 후 해당 요청을 처리할 것을 확인(confirm)하는 확인응답(acknowledgement)을 포함하는 응답 메시지를 요청자로 전송할 수 있다. 이 경우, 통지 대상(notification target)의 리스트가 선택사항(option)으로서 요청 메시지에 포함될 수 있다. 만일 통지 타겟의 리스트가 요청 메시지에 포함하는 경우 요청된 동작의 결과는 통지 타겟들로의 통지 메시지에 포함되어 전송될 수 있다. 만일 통지 타겟의 리스트가 요청 메시지에 포함되지 않는 경우 요청된 동작의 결과는 요청 발신자에게 전송될 수 있다. 비동기식 논-블록킹 요청에 대해서는 도 11을 참조하여 더욱 자세히 설명한다.

■ 응답 메시지 타입이 블록킹 요청을 지시하는 경우(예, rt = blockingRequest), 요청 수신자는 해당 요청을 통해 요청된 동작을 완료한 후 요청된 동작의 결과와 함께 응답 메시지를 전송할 수 있다. 블록킹 요청에 대해서는 도 7과 도 8을 참조하여 더욱 자세히 설명한다.

요청 메시지의 수신자는 요청된 동작(예, op에 설정된 동작)을 수행한 후 응답 메시지를 요청 메시지의 발신자에게로 전송할 수 있다. 응답(Response) 메시지는 다음과 같은 정보를 포함할 수 있다. 응답 메시지는 아래 정보 중에서 적어도 하나를 포함할 수 있으며, 또는 결과값(rs) 및 요청 식별자(ri)만을 포함할 수도 있다.

- rs: 응답 코드(response code)로서, 요청된 동작이 성공적으로 수행되었는지 여부 또는 확인응답(acknowledgement)을 지시한다. 응답 코드는 예를 들어 성공, 비성공, 확인응답 중 하나를 지시할 수 있다. 응답 코드가 성공을 지시하는 경우(예, rs = successful), 요청된 동작이 수신자(또는 호스팅 엔티티)에 의해 성공적으로 실행되었음을 나타낸다. 응답 코드가 비성공을 지시하는 경우(예, rs = unsuccessful), 요청된 동작이 수신자(또는 호스팅 엔티티)에 의해 성공적으로 실행되지 못했음을 나타낸다. 응답 코드가 확인응답을 지시하는 경우(예, rs = acknowledgement), 수신자가 요청 발신자로부터 직접적으로 요청을 수신하고 수락하였으며 아직 요청된 동작을 실행하지 않았음을 나타낸다. 이 경우 요청된 동작의 실행이 성공인지 실패인지 여부는 나중에 전송될 수 있다.

- ri: 요청 식별자(request identifier)로서, 응답 메시지와 대응되는 요청의 요청 식별자와 매칭된다.

- to: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID)

- fr: 요청(Request)을 수신한 수신자(receiver)의 식별 정보(또는 ID)

- cn: 응답 메시지를 통해 전달되는 리소스 내용

본 명세서에서, 발신자는 발신자 디바이스 또는 발신자 엔티티(또는 그 안의 CSE 또는 AE)을 나타내고, 수신자는 수신자 디바이스 또는 수신자 엔티티(또는 그 안의 CSE 또는 AE)를 나타낼 수 있다. 또한, 요청된 동작의 대상 자원(target resource)을 가지고 있는 디바이스(또는 그 안의 CSE)를 호스팅 디바이스 또는 호스팅 엔티티(또는 호스팅 CSE)라고 지칭할 수 있다. 호스팅 디바이스 또는 엔티티가 아닌 수신자를 중계(transit) 디바이스 또는 엔티티(또는 그 안의 CSE)라고 지칭할 수 있다. 중계 디바이스 또는 엔티티는 수신된 메시지를 중간에서 중계하여 수신자 디바이스에게 전달하는 역할을 수행할 수 있다. 또한, 다른 디바이스(또는 그 안의 CSE 또는 AE)가 등록되어 있는 디바이스 또는 엔티티를 등록 디바이스 또는 엔티티(registrar device or entity)라고 지칭할 수 있다.

도 7과 도 8은 블록킹 요청(blocking request)을 기반으로 리소스를 액세스하기 위한 절차를 예시한다. 블록킹 요청은 요청 메시지의 응답 메시지 타입 정보(예, rt)가 블록킹 요청을 지시하도록 설정된 경우(예, rt = blockingRequest)를 나타낸다(도 6 관련 설명 참조). 본 명세서에서 블록킹 요청을 기반으로 리소스를 액세스하는 동작 모드를 블록킹 모드라고 지칭할 수 있다. 도 7과 도 8에서 “홉(hop)”이라는 용어는 발신자로부터 수신자(또는 호스팅 엔티티)까지 요청을 전달한 중계 엔티티의 개수를 지칭할 수 있다. 예를 들어, 메시지를 수신한 디바이스 또는 엔티티는 요청 메시지에 설정된 동작 대상 리소스의 주소 정보(예, to)를 참조하여 어드레싱되는 리소스가 자신에게 저장되어 있는지 여부를 판별할 수 있다. 만일 어드레싱된 리소스가 자신에게 있지 않으면 다음 엔티티 또는 디바이스로 전달할 수 있으며, 이 경우 메시지를 수신하여 전달하는 디바이스 또는 엔티티는 중계 디바이스 또는 엔티티에 해당하고 홉은 1만큼 증가한다. 또한, 블록킹 요청의 경우, 수신자는 요청된 동작을 실행한 후 그 결과와 함께 응답 메시지를 전송할 수 있다. 따라서, 요청 발신자는 요청된 동작이 완료된 후 요청에 대한 응답을 받기까지 충분한 시간을 기다릴 수 있다고 가정한다. 요청 발신자의 입장에서 이는 계류중인 요청(pending request)에 대한 응답을 받을 때까지의 시간을 알 수 없거나 잠재적으로 긴 것을 의미한다.

도 7을 참조하면, 홉이 없는 경우(no hop, 홉 = 0) 리소스를 액세스하기 위한 절차가 예시되어 있다. 도 7의 예에서, 발신자(originator)(702)는 수신자-1(receiver-1)(704)에 등록되어 있다고 가정하며, 따라서 수신자-1(704)은 등록 엔티티 또는 디바이스(registrar entity or device)에 해당할 수 있다. 또한, 수신자-1(704)은 어드레싱되는 리소스를 저장하고 있다고 가정하며(S702), 따라서 수신자-1(704)은 호스팅 엔티티 또는 디바이스(hosting entity or device)에 해당할 수 있다. 홉이 없는 경우 등록 엔티티(또는 CSE)는 호스팅 엔티티(또는 CSE)와 동일한 엔티티일 수 있다.

도 7의 예에서, 요청 발신자(request originator)(702)는 수신자-1(704)의 리소스를 액세스하기 위해 요청을 전송할 수 있다(S704). 예를 들어, 요청은 애플리케이션 엔티티(또는 애플리케이션 계층) 또는 CSE(또는 공통 서비스 계층)에서 생성되어 전송될 수 있다. 수신자-1(704)은 요청을 수신한 다음 발신자(702)가 어드레싱된 리소스에 대한 액세스 권한(access rights)을 가지는지 여부를 검증할 수 있다(S706). S706 단계는 예를 들어 수신자-1(704)의 CSE에서 수행될 수 있다. 액세스 권한을 검증한 결과 리소스에 대한 액세스가 허용되는 경우, 수신자-1(704)은 자원을 액세스하고 성공 또는 실패 응답으로 응답 메시지를 생성할 수 있다(S708). 그런 다음, 수신자-1(704)은 응답 메시지를 발신자(702)로 전송할 수 있다(S710).

도 8을 참조하면, 홉이 1인 경우(hop = 1), 리소스를 액세스하기 위한 절차가 예시되어 있다. 도 8의 예에서, 발신자(originator)(702)는 수신자-1(receiver-1)(704)에 등록되어 있다고 가정하며, 따라서 수신자-1(704)은 등록 엔티티 또는 디바이스(registrar entity or device)에 해당할 수 있다. 또한, 수신자-2(706)는 어드레싱되는 리소스를 저장하고 있다고 가정하며(S802), 따라서 수신자-2(706)는 호스팅 엔티티 또는 디바이스(hosting entity or device)에 해당할 수 있다. 홉이 1인 경우 등록 엔티티(또는 CSE)는 중계 엔티티에 해당하며 호스팅 엔티티와 서로 다른 엔티티일 수 있다.

도 8의 예에서, 요청 발신자(request originator)(702)는 수신자-2(704)의 리소스를 액세스하기 위해 요청을 수신자-1(704)로 전송할 수 있다(S804). 예를 들어, 요청은 애플리케이션 엔티티(또는 계층) 또는 CSE(또는 공통 서비스 계층)에서 생성되어 전송될 수 있다. 수신자-1(704)은 어드레싱된 리소스를 가지고 있지 않으므로(S806) 수신자-1이 등록된 엔티티 중에서 어드레싱된 리소스를 가지고 있는 호스팅 엔티티로 수신된 요청을 전달할 수 있다(S808). 도 8의 예에서, 호스팅 엔티티는 수신자-2(706)이므로 수신자-1(704)은 요청을 수신자-2(706)로 전송하여 리소스를 액세스할 수 있다(S810). 수신자-2(706)는 요청을 수신한 후 어드레싱된 리소스에 대한 액세스 권한(access rights)을 가지는지 여부를 검증할 수 있다(S812). 액세스 권한을 검증한 결과 리소스에 대한 액세스가 허용되는 경우, 수신자-2(706)는 자원을 액세스하고 성공 또는 실패 응답으로 응답 메시지를 생성할 수 있다(S814). 그런 다음, 수신자-2(706)는 응답 메시지를 수신자-1(704)로 전송할 수 있으며(S816), 수신자-1(704)은 응답 메시지를 발신자(702)로 전달할 수 있다.

도 8의 예는 멀티 홉인 경우(홉이 1보다 큰 경우)에도 동일/유사하게 확장될 수 있다. 멀티 홉인 경우, 수신자-2(706)는 어드레싱된 리소스를 가지고 있지 않을 수 있으며 중계 엔티티 또는 디바이스에 해당할 수 있다. 따라서, 수신자-2(706)는 자신이 등록되어 있는 다른 디바이스 또는 엔티티로 요청을 전달할 수 있다. 만일 자신이 등록되어 있는 엔티티 중에 호스팅 엔티티가 있는 경우 수신자-2(706)는 요청을 호스팅 엔티티로 전송할 수 있다. 하지만, 호스팅 엔티티에 등록되어 있지 않은 경우 수신자-2(706)는 자신이 등록되어 있는 또 다른 엔티티에게 요청을 전달할 수 있다. 이 경우, 만일 수신자-2(706)가 IN(또는 IN-CSE)에 등록된 경우 IN(또는 IN-CSE)로 요청을 전송할 수 있다. 요청이 호스팅 엔티티에 도달한 경우 호스팅 엔티티는 어드레싱된 리소스에 대한 액세스 권한(access rights)을 가지는지 여부를 검증할 수 있다. 액세스 권한을 검증한 결과 리소스에 대한 액세스가 허용되는 경우, 자원을 액세스하고 성공 또는 실패 응답으로 응답 메시지를 생성/전송할 수 있다. 응답 메시지는 요청 메시지가 전달된 순서의 역순으로 발신자(702)로 전달될 수 있다.

한편, 요청 발신자가 응답으로서 요청의 확인응답(acknowledgement)과 요청된 동작에 대한 결과에 대한 레퍼런스(reference)를 요구한 경우(예, 동기식 논-블록킹 요청 또는 비동기식 논-블록킹 요청), 요청 발신자가 요청된 동작의 결과를 나중에 회수(retrieve)할 수 있도록 요청 수신자는 등록 엔티티 상의 내부 리소스 또는 다른 리소스에 대한 레퍼런스와 함께 즉각적인 응답을 제공할 필요가 있다. 상기 레퍼런스는 요청에 대한 응답 메시지에서 제공될 수 있다. 요청된 동작의 결과를 요청 발신자가 회수할 수 있도록 하는 방식에 따라 동기식 논-블록킹 요청과 비동기식 논-블록킹 요청으로 구분될 수 있다. 동기식 논-블록킹 요청(synchronous non-blocking request)은 요청 메시지의 응답 메시지 타입 정보(예, rt)가 동기식 논-블록킹 요청을 지시하도록 설정된 경우(예, rt = nonBlockingRequestSynch)를 나타낸다. 비동기식 논-블록킹 요청(asynchronous non-blocking request)은 요청 메시지의 응답 메시지 타입 정보(예, rt)가 동기식 논-블록킹 요청을 지시하도록 설정된 경우(예, rt = nonBlockingRequestAsynch)를 나타낸다. 본 명세서에서 동기식 논-블록킹 요청을 기반으로 리소스를 액세스하는 동작 모드를 동기식 논-블록킹 모드라고 지칭하고, 비동기식 논-블록킹 요청을 기반으로 리소스를 액세스하는 동작 모드를 비동기식 논-블록킹 모드라고 지칭할 수 있다. 동기식 논-블록킹 모드와 비동기식 논-블록킹 모드는 논-블록킹 모드라고 통칭될 수 있다.

도 9와 도 10은 동기식 논-블록킹 요청을 기반으로 리소스를 액세스하기 위한 절차를 예시한다. 도 9와 도 10의 예에서, 수신자-1(704)은 어드레싱되는 리소스를 가지고 있다고 가정한다(S902). 따라서, 이들 예에서, 수신자-1(704)은 등록 엔티티이며 호스팅 엔티티에 해당할 수 있다.

동기식 논-블록킹 요청의 경우, 요청 발신자는 비동기식 메시지(asynchronous message)를 수신할 수 없다고 가정한다. 따라서, 동기식 논-블록킹 요청의 경우, 발신자와 등록 엔티티 간의 모든 정보 교환은 발신자에 의해 개시(initiate)될 필요가 있다. 또한, 동기식 논-블록킹 요청의 경우, 요청된 동작의 결과를 요청 발신자가 레퍼런스를 이용하여 회수한다. 이 경우, 요청된 동작의 결과를 회수하는 시점에 따라 정보의 흐름이 도 9와 도 10에 예시된 바와 같이 달라질 수 있다.

도 9를 참조하면, 발신자가 요청 동작의 결과를 회수하기 전에 수신자가 요청 동작을 완료한다고 가정한다. 구체적으로, 발신자(702)는 자원을 액세스하기 위한 요청을 수신자-1(704)로 전송할 수 있다(S904). 수신자-1(704)은 액세스 권한(access privilege)을 검증하고, 요청을 수락하고, 요청된 동작의 결과를 저장할 리소스(예, <request> 리소스)를 생성하고 그에 대한 레퍼런스(예, Req-Ref)를 제공할 수 있다(S906). 수신자-1(704)은 레퍼런스를 응답 메시지에 포함시켜 발신자에게로 전송할 수 있다(S908). 그런 다음, 수신자-1(704)은 동작 대상 리소스를 액세스하고 동작을 실행한 후 동작의 상태 및 결과를 S906에서 생성된 리소스(예, <request> 리소스)에 기록할 수 있다(S910). 발신자(702)는 S908에서 수신된 레퍼런스를 회수(retrieve)하기 위해 요청 메시지를 수신자-1(704)에게 전송할 수 있다(S912). 수신자-1(704)는 액세스 권한(access privilege)을 검증하고, 동작 결과가 기록된 리소스(예, <request> 리소스)의 내용을 포함하여 응답 메시지를 생성할 수 있다(S914). 수신자-1(704)는 동작 결과를 포함하는 응답 메시지를 발신자(702)로 전송할 수 있다(S916).

도 10을 참조하면, 발신자가 요청 동작의 결과를 회수하기 위한 요청을 보낸 후에 수신자가 요청 동작을 완료할 수 있다. 구체적으로, S902 내지 S908은 도 9를 참조하여 설명한 것과 동일하므로 도 9에 관한 설명을 원용한다. S1002에서, 수신자-1(704)은 동작 대상 리소스를 액세스하여 요청된 동작을 시작하지만 완료하는 데까지 시간이 더 필요할 수 있다. 동작이 완료되기 전에, 발신자(702)는 요청된 동작의 결과를 회수하기 위해 요청 메시지를 수신자-1(704)로 전송할 수 있다(S1004). 수신자-1(704)은 S906에서 생성된 리소스(예, <request> 리소스)에 따라 응답 메시지를 생성할 수 있다(S1006). 이 경우, 수신자-1(704)이 아직 요청 동작을 완료하지 못한 상태이므로 결과는 요청 동작이 완료되지 않았음을 지시할 수 있다. 수신자-1(704)은 결과(예, op not completed)를 포함하는 응답 메시지를 발신자(S702)로 전송할 수 있다(S1008). S1010에서, 수신자-1(704)은 요청된 동작을 완료하고, 동작 상태 및 결과를 S906에서 생성된 리소스(예, <request> 리소스)에 기록할 수 있다. 발신자는 도 9를 참조하여 설명한 것과 동일한 방식으로 동작 결과를 회수할 수 있다(S912 내지 S916).

도 11은 비동기식 논-블록킹 요청을 기반으로 리소스를 액세스하기 위한 절차를 예시한다. 도 11의 예에서, 수신자-1(704)은 어드레싱되는 리소스를 가지고 있지 않고 수신자-2(706)가 어드레싱되는 리소스를 가지고 있다고 가정한다(S1102). 따라서, 이들 예에서, 수신자-1(704)은 등록 엔티티에 해당하고 수신자-2(706)는 호스팅 엔티티에 해당할 수 있다.

비동기식 논-블록킹 요청의 경우, 요청 발신자 또는 요청 결과에 대해 알 필요가 있는 다른 엔티티는 통지 메시지를 수신할 수 있다. 요청된 동작을 수행하는 엔티티는 하나 이상의 통지 대상(notification target)에게 요청된 동작의 상태 및 결과를 보내기 위해 임의의 시간(arbitrary time)에 발신자 또는 다른 지시된 엔티티들에게 메시지를 전송할 수 있다. 이 경우 전송되는 통지 메시지는 자원에 대한 구독이 트리거링된 후에 전송되는 통지 메시지와 동일한 방식으로 동작할 수 있다. 또한, 비동기식 논-블록킹 요청의 경우, 수신자(예, 수신자-1 704)가 동작 결과를 기록할 리소스 타입(예, <request> 리소스)을 지원하지 않는 경우 해당 리소스에 대한 레퍼런스 없이 확인응답(acknowledgement)으로 요청에 대해 응답할 수 있다.

도 11를 참조하면, 발신자(702)는 2개의 통지 대상(notification target)을 지시하는 요청 메시지를 수신자-1(704)로 전송할 수 있다(S1104). 따라서, 요청 동작의 결과가 가용하거나 요청이 실패한 경우 통지 메시지가 발신자(702)와 다른 통지 대상(708)으로 전송될 수 있다. 수신자-1(704)은 요청을 수락하지만 요청 동작의 대상 리소스를 가지고 있지 않다(S1106). 따라서, 수신자-1(704)은 요청 동작 결과가 기록될 리소스(예, <request> 리소스)에 대한 레퍼런스(예, Req-Ref)를 포함하는 응답 메시지를 발신자(702)에게로 전송할 수 있다(S1108). S1108에서 수신자-1(704)가 <request> 리소스 타입을 지원하지 않는 경우 레퍼런스 정보는 포함되지 않을 수 있다. S1110에서, 수신자-1(704)과 수신자-2(706)는 호스팅 엔티티로 요청을 전달하기 위한 메시지 흐름을 수행할 수 있다. 도 11의 예에서, 수신자-2(706)가 호스팅 엔티티이므로 통지 대상들로의 통지 메시지를 트리거링할 수 있다(S1112). 수신자-2(706)는 통지 메시지를 수신자-1(704)과 다른 통지 대상(708)으로 전송할 수 있고(S1114), 수신자-1(704)은 통지 메시지를 발신자(702)로 전송할 수 있다(S1116). 발신자(702)는 수신된 통지 메시지에 대한 응답 메시지를 수신자-1(704)로 전송할 수 있고(S1118), 수신자-1(704)과 다른 통지 대상(708)은 각각 응답 메시지를 수신자-2(706)로 전송할 수 있다(S1120).

도 12은 구독 자원과 관련된 절차를 예시한다.

M2M 시스템(예, oneM2M)에서는 자원의 변화에 따라 해당 자원의 변화에 관심이 있는 엔티티(Entity)가 해당 변화에 대한 통지(notification)를 구독(subscription)할 수 있다. 이 경우, 통지를 구독하기 위해서는 구독을 위한 자원이 설정되어야 한다. 구독을 위한 자원은 구독 자원 또는 <subscription> 자원으로 지칭될 수 있다. 구독 자원이 생성/설정된 경우, 구독 자원이 설정된 디바이스(또는 엔티티)는 구독 자원에 설정된 조건을 만족하는 수정/변화가 구독 대상 자원(subscribed-to resource 또는 subscribed resource)에서 발생하는 경우 구독 자원에 설정된 주소(예, notificationURI 또는 contact 속성)로 통지를 전송할 수 있다. 구독 자원에 설정된 주소 정보(예, notificationURI 또는 contact 속성)는 통지 대상의 식별 정보로서 사용될 수 있다. 구독 자원이 설정되거나 및/또는 구독 대상 자원을 포함하는 디바이스(또는 엔티티)를 호스팅 디바이스(또는 호스팅 엔티티)라고 지칭한다. 예를 들어, M2M 게이트웨이의 CSE에 구독 대상 자원이 존재할 수 있으며 이 경우 M2M 게이트웨이를 호스팅 디바이스라고 지칭하고 M2M 게이트웨이의 CSE를 호스팅 CSE라고 지칭할 수 있다.

구독 자원을 이용하여 자원 지향적인 방식(resource-oriented manner)으로 구독 절차를 수행할 수 있다. 예를 들어, 특정 구독 대상 자원에 대하여 구독하기 위해 구독 자원을 생성할 수 있고, 구독 자원을 수정함으로써 구독을 위한 조건을 변경할 수 있으며, 구독을 더 이상 원치 않을 경우에는 구독 자원을 삭제할 수 있다.

구독 자원(subscription resource)은 구독 대상 자원(subscribed-to resource)에 대한 정보를 포함한다. 구독 대상 자원과 구독 자원 간의 관계는 부모-자식 관계로서 표현될 수 있다. 예를 들어, 구독 대상 자원을 포함하는 <container> 자원은 자식 자원으로서 <subscription> 자원을 가질 수 있다. 부모 구독 대상 자원이 삭제될 때 <subscription> 자원은 삭제될 수 있다.

구독(subscription) 자원이 자식 자원인 경우에는 구독 자원의 설정(속성 설정)에 따라 부모 자원의 상태 변화를 지시하는 통지(notification)가 구독 자원 내의 주소 정보(예, notificationURI 또는 contact 속성)에 명시된 엔티티에게 전달될 수 있다. 발신자가 구독가능한 자원에 대한 RETRIEVE(또는 READ) 권한(permission)을 가지는 경우 발신자는 구독 자원을 생성할 수 있다. 자원 구독자는 구독 요청의 발신자이거나 또 다른 엔티티일 수 있다. 구독 대상 자원에 대한 수정이 있는 경우 그 수정을 특정 속성(예, notificationCriteria attribute)과 비교하여 통지가 자원 구독자로 전송될 지를 결정한다.

구독 자원(예, <subscription> 자원)은 다양한 속성과 자식 자원을 가질 수 있다. 예를 들어, 구독 자원(예, <subscription> 자원)은 표 1의 속성들을 가질 수 있다. 표 1에서 R/W는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY 또는 WRITE ONCE(WO) 중 하나일 수 있다. 표 1은 오로지 예시일 뿐이며 구독 자원의 속성은 표 1과 다르게 구성될 수 있다.

표 1의 예에서, 필터링 속성(예, notificationCriteria)은 구독 대상 자원의 수정/변화에 대한 조건들의 리스트이며, 각 조건들은 논리적 AND 관계에 있을 수 있다. 예를 들어, 필터링 속성(예, notificationCriteria)이 2개의 조건을 포함하는 경우, 구독 대상 자원의 수정/변화가 2개의 조건을 모두 만족하는 경우 통지가 전송될 수 있다. 구독 자원에 필터링 속성을 설정함으로써 통지 메시지의 양을 조절할 수 있으며, 설정한 필터링 속성을 만족 시에 통지 대상 엔티티(notification target entity)에게 통지가 전송되도록 하여 통지 메시지가 넘쳐나는 문제를 방지할 수 있다. 표 2는 필터링 속성에 포함될 수 있는 조건들을 예시한다.

도 12을 참조하면, 엔티티 1(1210)은 엔티티 2(1220)의 특정 자원을 구독하기 위해 도 6에 예시된 절차를 수행할 수 있다. 엔티티 1(1210)은 구독 대상 자원의 변화에 따른 통지를 받는 대상일 수도 있고 아닐 수도 있다. 도 12의 예에서, 특정 자원은 구독 대상 자원에 해당하며, 엔티티 2(1220)는 구독 대상 자원을 포함하고 있으므로 호스팅 디바이스(또는 엔티티)에 해당할 수 있다.

S1202 단계에서, 엔티티 1(1210)은 특정 자원을 구독하기 위해 구독 자원에 대한 요청을 엔티티 2(1220)로 전송할 수 있다. 예를 들어, 구독 자원에 대한 요청은 구독 자원의 생성 요청, 회수 요청, 삭제 요청, 갱신 요청 중에서 어느 하나일 수 있다. 각 요청은 도 6을 참조하여 설명된 요청-응답 방식에 따른 요청 메시지의 형태를 가질 수 있다. 예를 들어, S1202의 요청이 생성 요청인 경우, 구독 자원에 대한 요청은 C(Create)를 가지는 op 정보, 구독 자원의 속성 정보(예, notificationURI, filterCriteria, creator 등)를 포함하는 cn 정보, 엔티티 1(1210)의 식별 정보를 가지는 fr 정보, 및/또는 대상 자원(target resource)의 식별 정보를 가지는 to 정보를 포함할 수 있다. 다른 예로, S1202의 요청이 삭제 또는 갱신 요청인 경우, 구독 자원에 대한 요청은 도 6을 참조하여 설명된 정보들의 전부 또는 일부를 포함할 수 있다. 본 명세서에서 구독 자원의 생성 요청은 구독 생성 요청, 구독 자원의 회수 요청은 구독 회수 요청, 구독 자원의 삭제 요청은 구독 삭제 요청, 구독 자원의 갱신 요청은 구독 갱신 요청이라고 지칭될 수 있다. 구독 자원과 관련된 요청들은 구독 요청이라고 통칭될 수 있다.

S1204 단계에서, 엔티티 2(1220)는 구독 자원에 대한 요청을 처리할 수 있는지 검사(validate)하여 처리할 수 있는 경우 해당 요청을 처리한다. 예를 들어, 엔티티 2(1220)가 생성 요청을 수신하는 경우, to 정보에 지정된 구독 대상 자원이 구독 가능한지 여부, 요청 발신자(예, 엔티티 1)이 구독 대상 자원에 대해 RETRIEVE 권한(permission)을 가지는지 여부를 검사(validate)한다. 이들 모두를 만족하는 경우, 엔티티 2(1220)는 to 정보에 지정된 구독 대상 자원(subscribed-to resource) 아래에 구독 자원을 생성할 수 있다.

다른 예로, 엔티티 2(1220)가 삭제 요청을 수신하는 경우, 엔티티 2(1220)는 요청 발신자(예, 1310)가 DELETE 권한(permission)을 가지는지 여부를 검사(validate)하며, 이를 만족하는 경우 구독 자원을 삭제한다.

S1206 단계에서, 엔티티 2(1220)는 구독 자원에 대한 요청을 처리한 다음 응답 메시지를 엔티티 1(1210)로 전송할 수 있다. S1206의 응답 메시지는 도 6을 참조하여 설명된 응답 메시지와 동일/유사한 형태를 가질 수 있다. 또한, 회수 요청의 경우 응답 메시지는 반환될 정보를 포함할 수 있다.

도 13은 통지를 위한 절차를 예시한다. 통지를 위한 절차에서 발신자는 구독 자원을 호스팅하고 있는 디바이스 또는 엔티티(예, 엔티티 2)일 수 있다. 또한, 수신자는 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 디바이스(또는 엔티티)일 수 있다. 통지를 위한 절차를 위해 소정의 정책 정보가 설정될 수 있으며, 이러한 정책 정보를 만족할 때 발신자가 통지 메시지(예, NOTIFY)를 전송하도록 설정될 수 있다. 통지 메시지는 op가 NOTIFY로 설정된 요청 메시지를 지칭할 수 있다.

통지 메시지(예, NOTIFY)는 통지 이벤트(예, 구독 대상 자원의 상태 변화)가 발생할 때 생성될 수 있다. 통지 이벤트는 구독 자원에 의해 트리거링될 수 있다. 예를 들어, 통지 메시지는 구독 자원을 자식 자원으로서 포함하는 구독 대상 자원의 변화가 구독 자원에 설정된 필터링 속성(예, notificationCriteria)을 만족하는 경우 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 수신자로 전송될 수 있다. 통지 메시지의 수신자는 구독 자원의 설정에 따라 구독 자원을 생성/설정한 디바이스 또는 엔티티와 동일할 수도 있고 서로 다를 수 있다. 예를 들어, 엔티티 1(1210)은 엔티티 3(1230)과 동일한 엔티티일 수도 있고 서로 다른 엔티티일 수 있다. 통지 메시지는 다음과 같은 정보를 포함할 수 있다.

- fr: 발신자(예, 엔티티 2)의 식별정보 또는 ID

- to: 구독 자원에 설정된 주소 정보(예, notificationURI)

- cn: 구독 대상 자원의 수정 내용(modified content)을 나타내는 데이터 및/또는 이 통지 메시지를 생성한 구독 참조(subscription reference) 정보(예, 해당 구독 자원의 URI) 및/또는 기타 부가 정보

도 13을 참조하면, S1302 단계에서 발신자(예, 엔티티 2)는 구독 대상 자원의 변화를 검출/감지할 수 있다. 구독 대상 자원은 구독 자원의 부모 자원이며, 구독 대상 자원 아래에서 구독 자원과 동일한 레벨에 있는 자원 또는 속성이 수정/변화되는 경우 발신자(예, 엔티티 2)(예를 들어, SUB CSF 또는 CSE 도 3 참조)는 구독 대상 자원의 변화로서 인지할 수 있다. 구독 대상 자원의 변화가 검출/감지되는 경우 통지 이벤트가 생성될 수 있다.

구독 대상 자원의 변화가 검출되는 경우, S1304 단계에서, 발신자(예, 엔티티 2)는 해당 변화가 구독 자원에 설정된 특정 속성(예, notificationCriteria)과 매칭되는지 여부를 확인한다. 특정 속성은 예를 들어 표 2에 예시된 속성들 중 적어도 하나를 포함할 수 있다. 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들을 모두 만족하지 않는 경우 발신자(예, 엔티티 2)는 해당 변화를 무시할 수 있다.

만일 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들을 모두 만족하는 경우, S1306 단계에서, 발신자(예, 엔티티 2)는 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 엔티티 3(1230)에게 통지 메시지를 전송할 수 있다. S1306의 통지 메시지는 예를 들어 발신자(예, 엔티티 2)의 식별정보, 구독 대상 자원의 변경 내용을 나타내는 데이터, 및/또는 통지 메시지를 생성한 구독 참조 정보를 포함할 수 있다. 만일 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들 중 어느 하나라도 만족하지 않는 경우, 발신자(예, 엔티티 2)는 생성된 통지 메시지를 전송하지 않을 수 있다.

도 14는 구독-통지 절차와 관련된 문제를 예시한다.

앞서 설명된 바와 같이, 구독 요청에 대해서 요청 수신자(예, 엔티티 2)는 요청 발신자(예, 엔티티 1)가 구독 자원 또는 구독 대상 자원에 대한 권한(또는 액세스 권한)을 가지는지 여부를 검증할 수 있다. 만일 요청 발신자(예, 엔티티 1)가 구독 자원 또는 구독 대상 자원에 대한 권한(또는 액세스 권한)을 가지지 않는 경우 구독 요청은 거절되고 응답 메시지는 실패 결과를 포함할 수 있다. 하지만, 이러한 검증이 수행되더라도 구독 검증(subscription verification)과 관련된 문제가 존재할 수 있다. 본 명세서에서 구독 검증은 구독 요청에 대한 권한(또는 액세스 권한)을 검증하는 동작을 지칭할 수 있다. 또한, 본 명세서에서 구독 요청자(subscription requester)는 요청 발신자(request originator)로 지칭될 수 있고, 구독 호스트(subscription host)는 호스팅 엔티티(hosting entity)로 지칭될 수 있다.

도 14를 참조하면, S1202에서 요청 발신자(예, 엔티티 1)는 통지 수신자(예, 엔티티 3)를 구독자로하여 호스팅 엔티티(예, 엔티티 2)에 구독 자원을 설정할 수 있다. 이 경우, S1204에서 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, 엔티티 1)가 구독 대상 자원 또는 구독 자원에 대한 권한을 가지는지 여부를 확인할 수 있다. 예를 들어, 호스팅 엔티티(예, 엔티티 2)는 자신이 가지고 있는 구독 대상 자원에 대해 요청 발신자(예, 엔티티 1)가 RETRIEVE할 액세스 권한이 있는지 여부를 확인할 수 있다. 만일 액세스 권한 확인이 성공하면 S1206에서 구독 요청을 승인하는 응답 메시지를 요청 발신자(예, 엔티티 1)로 전송할 수 있다.

기존의 구독/통지 메커니즘에 따르면, 요청 발신자(예, 엔티티 1)가 호스팅 엔티티(예, 엔티티 2)에 대한 액세스 권한을 가지는 경우 통지 메시지를 통지 수신자(예, 엔티티 3)로 전송하도록 구독 자원을 설정할 수 있다. 이 경우 요청 발신자(예, 엔티티 1)가 악의적인 의도(malicious intention)을 가지고 구독 자원을 설정하는 경우 통지 수신자(예, 엔티티 3)는 원치 않는 통지 메시지를 수신하여야 하므로 통지 수신자(예, 엔티티 3)에 부하를 증가시킬 수 있다. 특히, 요청 발신자(예, 엔티티 1)가 DDoS 공격과 같은 악의적인 공격을 의도할 경우 통지 수신자(예, 엔티티 3) 뿐만 아니라 호스팅 엔티티(예, 엔티티 2)도 시스템 부하가 증가할 수 있으며 이로 인해 전체 시스템이 다운되는 결과 발생할 수 있다.

또한, 요청 발신자(예, 엔티티 1)가 악의적인 의도를 가지고 있지 않는 경우에도 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지 메시지를 보낼 권한이 있는 경우에는 또 다른 엔티티에 의해 악용될 가능성이 있다. 예를 들어, 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지 메시지를 보낼 권한이 있다고 가정할 때, 호스팅 엔티티(예, 엔티티 2)에 액세스 권한을 가지는 또 다른 엔티티(예, 엔티티 4)가 호스팅 엔티티(예, 엔티티 2)에 별도의 구독 자원을 설정할 수 있다. 이 경우, 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지 메시지를 보낼 권한을 가지므로, 엔티티 4에 의해 설정된 구독 자원을 통해 생성된 통지 메시지는 호스팅 엔티티(예, 엔티티 2)의 액세스 권한을 도용하여 통지 수신자(예, 엔티티 3)로 전송될 수 있다. 따라서, 이러한 경우에도 호스팅 엔티티(예, 엔티티 2)와 통지 수신자(예, 엔티티 3)는 악의적인 공격에 노출될 수 있다.

이러한 문제를 방지하기 위해, 본 발명에서는 구독 및 통지를 위한 권한 확인(privilege check) 방법을 제안한다. 본 발명에서는 다음과 같이 2개의 추가적인 권한 확인을 제안한다.

- 호스팅 디바이스 또는 엔티티(예, 엔티티 2)가 구독 자원의 주소 정보(예, notificationURI)에 지정된 엔티티 또는 디바이스(예, 엔티티 3)로 통지를 보낼 권한(privilege)(또는 액세스 권한(access rights))을 가지는지 여부

- 요청 발신자(예, 엔티티 1)가 통지 메시지 수신자(예, 엔티티 3)를 통지 대상(notification target)으로 하는 구독 자원을 설정할 수 있는 권한(또는 액세스 권한)을 가지는지 여부. 혹은, 요청 발신자(예, 엔티티 1)가 통지 메시지 수신자(예, 엔티티 3)의 주소 정보를 구독 자원의 주소 정보(예, notificationURI)에 지정하여 구독 자원을 설정할 수 있는 권한(또는 액세스 권한)을 가지는지 여부. 혹은, 요청 발신자(예, 엔티티 1)가 구독 자원의 주소 정보(예, notificationURI)에 지정된 엔티티 또는 디바이스(예, 엔티티 3)로 통지를 보낼 권한(또는 액세스 권한)을 가지는지 여부.

본 발명에 따른 권한 확인은 요청 발신자(예, 엔티티 1)와 통지 수신자(예, 엔티티 3)가 상이한 경우에 수행될 수 있다. 예를 들어, 구독 자원의 주소 정보(예, notificationURI)가 요청 발신자(예, 엔티티 1)를 가리키지 않는 경우에 수행될 수 있다.

본 명세서에서, 통지를 보낼 수 있는 권한(privilege) 또는 구독 자원을 설정할 수 있는 권한은 NOTIFY/SUBSCRIBE permission/privilege 등으로 나타낼 수 있고 서로 혼용될 수 있다. 예를 들어, 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)를 통지 대상으로 하는 구독 자원을 설정할 수 있는 권한은 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에게 통지 메시지를 전송할 수 있는 권한과 같은 의미로 사용될 수 있다. 혹은, 예를 들어, 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에게 통지 메시지를 전송하기 위한 구독을 설정할 수 있는 권한은 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에게 통지 메시지를 전송할 수 있는 권한과 같은 의미로 사용될 수 있다. 해당 권한은 요청 발신자(예, 엔티티 1)가 호스팅 엔티티(예, 엔티티 2)로 구독 자원 생성을 요청하기 전에 설정될 수 있다. 따라서, 요청 발신자(예, 엔티티 1)는 통지 수신자(예, 엔티티 3)에 대한 충분한 권한을 가지고 있을 수 있다.

이후 요청 발신자(예, 엔티티 1)가 호스팅 엔티티(예, 엔티티 2)에 구독을 요청하면서 통지 대상을 통지 수신자(예, 엔티티 3)로 설정하는 경우, 호스팅 엔티티(예, 엔티티 2)는 통지 수신자(예, 엔티티 3)에 대한 요청 발신자(예, 엔티티 1)와 호스팅 엔티티(예, 엔티티 2)의 권한을 확인할 수 있다. 호스팅 엔티티(예, 엔티티 2)는 본 발명에 따른 권한 확인이 성공적인 경우에만 요청 발신자(예, 엔티티 1)의 구독 요청을 승인(grant)할 수 있다.

본 명세서에서, 디바이스 또는 엔티티의 식별 정보는 디바이스 또는 엔티티를 지시하는 주소 정보(예, URI)를 포함할 수 있다. 혹은, 디바이스 또는 엔티티의 식별 정보는 디바이스 또는 엔티티가 가지고 리소스를 지시하는 주소 정보(예, URI)를 포함할 수 있다.

본 발명에 따른 구독 검증(Subscription Verification)은 호스팅 엔티티(예, Entity 2)가 통지 대상(notification target)의 권한을 확인할 수 있는 경우에 가능하다. 예를 들어 통지 대상의 권한을 확인할 수 없는 경우 검증(Verification)은 수행될 수 없다. 통지 대상의 권한을 확인하는 방법에는 여러가지 방법이 있을 수 있다. 예를 들어, 통지 대상의 권한과 관련된 정보를 요청 발신자(예, Entity 1)가 호스팅 엔티티(예, Entity 2)에게 구독 요청과 함께 알려줄 수 있다. 또는 요청 발신자(예, Entity 1)가 통지 대상의 권한과 관련된 정보를 제공하지 않더라도 호스팅 엔티티(예, Entity 2)에서 통지 대상의 권한을 확인할 수 있는지 여부를 판단하여 검증 관련 동작을 수행할 수 있다. 다른 예로, 통지 대상의 권한을 확인할 수 있는지 여부와 상관 없이 검증 요청 및 실제 동작을 시도할 수 있다. 통지 대상의 권한을 확인할 수 있는 경우 검증을 성공적으로 수행하여 결과를 확인할 수 있는 반면, 통지 대상의 권한을 확인할 수 없는 경우 일반적인 오류 응답을 전달하거나 아니면 아예 응답을 전달하지 않음으로써 검증이 성공적으로 수행되지 않았다는 사실을 확인할 수 있다.

방법 1 (Subscription host performs verification)

본 발명에 따른 방법 1에서는 종래 기술과 비교하여 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)에게 통지 메시지를 전송하기 위한 액세스 권한을 가지는지 여부를 검증하는 과정을 추가한다. 요청 발신자(예, Entity 1)가 악의적인 의도가 없고 통지 수신자(예, Entity 3)에 대한 적절한 권한을 가진다면, 구독 설정 요청 전에 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에게 통지를 전송할 수 있는 권한을 사전에 설정할 수 있다. 따라서, 구독 요청을 받은 호스팅 엔티티(예, Entity 2)는 자신이 통지 수신자(예, Entity 3)에게 통지를 전송할 수 있는 권한이 있는지 확인한 다음, 권한이 없는 경우 요청 발신자(예, Entity 1)가 통지 수신자(예, Entity 3)에 대한 권한이 없는 것으로 간주하고 구독 요청(subscription request)을 거절할 수 있다.

도 15는 본 발명에 따른 구독 및 통지 절차를 예시한다. 도 15는 본 발명에 따른 방법 1이 적용되는 예를 예시한다.

도 15을 참조하면, 설명한 구독/통지 절차의 문제점(예, 도 14 참조)을 해결하기 위해 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지를 전송할 수 있는 권한을 가지는지 여부를 추가적으로 검증한다(S1506). 따라서, 호스팅 엔티티(예, 엔티티 2)가 요청 발신자(예, 엔티티 1)로부터 구독 요청을 수신하면, 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, 엔티티 1)가 호스팅 엔티티(예, 엔티티 2)를 구독할 수 있는 권한이 있는지 여부를 확인할 뿐만 아니라(S1204), 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지를 전송할 수 있는 권한을 가지는지 여부도 검증한다(S1506). 도 15의 예에서, S1504, S1506 순으로 수행되는 것으로 예시되어 있지만, 이는 오로지 예시일 뿐이며 각 단계의 순서는 어느 하나로 제한되지 않는다. 따라서, S1504, S1506는 필요에 따라 서로 다른 순서로 수행될 수 있다. S1502, S1508, S1510, S1512 단계는 각각 S1202, S1206, S1302, S1306 단계에 대응될 수 있다. 따라서, 도 12 및 도 13에 관한 설명을 원용한다.

요청 발신자(예, 엔티티 1)가 악의적인 의도를 가지더라도 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지를 전송할 권한이 없는 경우 구독 요청은 승인될 수 없다. 따라서, 본 발명에 따른 방법 1이 적용될 경우, 요청 발신자(예, 엔티티 1)가 악의적인 의도를 가지고 호스팅 엔티티(예, 엔티티 2)와 통지 수신자(예, 엔티티 3)를 공격함으로써 네트워크 부하가 증가되거나 시스템 성능이 저하되는 문제를 방지할 수 있다.

방법 2 (Subscription host performs verification)

본 발명에 따른 방법 1을 적용할 경우, 요청 발신자(예, Entity 1)가 통지 수신자(예, Entity 3)의 설정을 변경할 수 있는 권한이 없는 악의적인 엔티티인 경우를 방지할 수 있다. 하지만 요청 발신자(예, Entity 1)의 구독 요청과는 상관 없이 혹은 통지 수신자(예, Entity 3)에 대한 설정 변경 권한을 가진 다른 엔티티에 의해 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 통지를 전송할 수 있는 권한을 가지는 경우도 발생할 수 있다. 예를 들어, 방법 1만 적용할 경우, 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지를 보낼 수 있는 권한을 가지면 호스팅 엔티티(예, Entity 2)는 통지 수신자(예, Entity 3)에 통지를 전송할 수 있다. 하지만 예를 들어, 통지 수신자(예, Entity 3)에 대한 설정 변경 권한을 가진 다른 엔티티(예, Entity 4)에 의해 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 통지를 전송할 수 있는 권한을 획득했을 수 있다. 따라서, 요청 발신자(예, 엔티티 1)는 또 다른 엔티티(예, 엔티티 4)의 요청에 의해 획득된 권한을 도용할 수 있는 가능성이 있다. 이 경우 호스팅 엔티티(예, Entity 2)가 해당 요청을 거절할 수 있게 하는 방안이 필요하다.

이러한 문제를 해결하기 위해, 본 발명에 따른 방법 2에서는 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에 대한 권한(또는 액세스 권한)(예, NOTIFY/CREATE/UPDATE 권한 등)을 가지는지 여부를 호스팅 엔티티(예, Entity 2)가 검증하는 과정을 추가한다. 만일 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에 대한 권한(또는 액세스 권한)을 가지지 못하는 경우 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, 엔티티 1)로부터의 구독 요청을 거절하고 실패 결과를 포함하는 응답 메시지를 요청 발신자(예, 엔티티 1)로 전송할 수 있다. 이와 반대로, 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에 대한 액세스 권한을 가지는 경우, 호스팅 엔티티(예, 엔티티 2)는 구독 요청을 승인하고 성공 결과를 포함하는 응답 메시지를 요청 발신자(예, 엔티티 1)로 전송할 수 있다.

다른 예로, 통지 수신자(예, Entity 3)가 통지를 수신하기 위해 구독을 대신하여 설정하는 권한 등이 있는지를 검증할 수 있다.

도 16은 본 발명에 따른 구독 및 통지 절차를 예시한다. 본 발명에 따른 방법 1과 방법 2는 필요에 따라 함께 적용될 수 있다. 도 16은 본 발명에 따른 방법 1과 방법 2가 함께 적용되는 예를 예시한다. 하지만, 이는 오로지 예시일 뿐이며, 본 발명에 따른 방법 1과 방법 2를 독립적으로 적용하는 것도 가능하다.

도 16을 참조하면, 앞서 설명한 구독/통지 절차의 문제점을 해결하기 위해 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에 대한 권한을 가지는지 여부를 추가적으로 검증한다(S1607). 따라서, 호스팅 엔티티(예, 엔티티 2)가 요청 발신자(예, 엔티티 1)로부터 구독 요청을 수신하면, 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, 엔티티 1)가 호스팅 엔티티(예, 엔티티 2)를 구독할 수 있는 권한이 있는지 여부를 확인할 뿐만 아니라(S1504), 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지를 전송할 수 있는 권한을 가지는지 여부를 검증하고(S1506), 또한 요청 발신자(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)에 대한 권한(또는 통지 메시지를 전송할 수 있는 권한 또는 통지 메시지를 전송하기 위한 구독을 설정할 수 있는 권한)을 가지는지 여부도 검증할 수 있다(S1607). S1506에 따른 검증과 S1607에 따른 검증은 요청 발신자(예, 엔티티 1)와 통지 수신자(예, 엔티티 3)가 상이한 경우에 수행될 수 있다. 도 16의 예에서, S1504, S1506, S1607 순으로 수행되는 것으로 예시되어 있지만, 이는 오로지 예시일 뿐이며 각 단계의 순서는 어느 하나로 제한되지 않는다. 따라서, S1504, S1506, S1607는 필요에 따라 서로 다른 순서로 수행될 수 있다.

방법 1과 방법 2가 함께 적용되는 경우, 요청 발신자(예, Entity 1)는 통지 수신자(예, 엔티티 3)로 통지를 전송하기 위한 구독 자원을 호스팅 엔티티(예, 엔티티 2)에게 설정하기 위해, 요청 발신자(예, Entity 1)는 사전에 통지 수신자(예, Entity 3)에 두 가지 권한을 설정할 수 있다. 첫 번째는 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 통지를 보낼 수 있는 권한이고, 두 번째는 요청 발신자(예, Entity 1)가 통지 수신자(예, Entity 3)를 통지 대상으로 설정할 수 있는 권한(예, Entity 1에 대한 통지 요청 권한)을 설정할 수 있다. 또한, 호스팅 엔티티(예, Entity 2)는 위에서 서술한 바와 같이 요청 발신자(예, Entity 1)와 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 대한 권한을 가지는지 여부를 확인한 다음 구독을 승인할 수 있다. 호스팅 엔티티(예, 엔티티 2)는 통지 수신자(예, Entity 3)가 가진 권한 정보를 통해 요청 발신자(예, Entity 1)와 통지 수신자(예, Entity 3)의 권한을 확인할 수 있다.

본 발명에 따른 방법 2가 적용될 경우, 호스팅 엔티티(예, 엔티티 2)에 이미 설정되어 있는 통지 수신자(예, 엔티티 3)에 대한 권한을 요청 발신자(예, 엔티티 1 또는 또 다른 엔티티)가 무단으로 도용하는 문제를 방지할 수 있다. 따라서, 이러한 도용으로 인해 호스팅 엔티티(예, 엔티티 2)와 통지 수신자(예, 엔티티 3) 간에 네트워크 부하가 증가되거나 시스템 성능이 저하되는 문제를 방지할 수 있다.

또한, 본 발명에 따른 방법 1 및/또는 방법 2를 적용할 경우 구독 요청 시 요청 발신자(예, Entity 1)와 통지 수신자(예, Entity 3)가 상이할 경우 구독/통지 메커니즘이 악의적으로 사용되는 것을 방지할 수 있다.

방법 3 (Subscription Verification by Notification Receiver)

본 발명에 따른 방법 1과 방법 2의 경우, 검증 과정(예, S1506, S1607)을 추가적으로 수행하기 위해 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 설정된 권한 정보를 획득하는 과정이 필요하므로 효율적이지 못할 수 있다. 본 발명에 따른 방법 3에서는 이러한 문제를 개선하기 위해 호스팅 엔티티(예, Entity 2)가 추가적인 검증 과정(예, S1506, S1607)을 수행하지 않고 통지 수신자(예, Entity 3)에 추가적인 검증 과정을 요청하고, 통지 수신자(예, Entity 3)는 추가적인 검증 과정을 수행한 후 해당 결과를 호스팅 엔티티(예, Entity 2)로 반환하는 것을 제안한다.

방법 1 및 방법 2에 따른 호스팅 엔티티(예, Entity 2)에 의한 권한 확인은 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 대한 최신 권한 정보를 성공적으로 획득했을 경우만 가능하다. 해당 정보를 획득하지 못할 경우 성공적인 검증을 수행할 수 없으며 통지 수신자(예, Entity 3)에 대한 권한 정보의 습득 과정이 호스팅 엔티티(예, Entity 2)에는 부담으로 작용할 수 있다. 따라서, 방법 1 및/또는 방법 2를 적용할 경우 호스팅 엔티티(예, Entity 2)(Notification 송신자)에 의한 검증 수행 시 해당 권한 정보를 획득하지 못하거나 해당 권한 획득/확인에 대한 부하(overload)가 발생할 수 있다. 반면, 방법 3을 적용할 경우 해당 권한 정보를 가진 통지 수신자(예, Entity 3)가 검증을 수행하므로 더욱 효율적일 수 있다.

통지 수신자(예, 엔티티 3)는 미리 권한 정보가 설정되어 있다고 가정한다. 통지 메시지는 요청 메시지(예, NOTIFY 요청)이므로 통지 메시지를 생성하여 전송하는 호스팅 엔티티(예, 엔티티 2)의 식별 정보(예, fr)를 포함할 수 있다. 따라서, 통지 메시지에 포함된 호스팅 엔티티(예, 엔티티 2)의 식별 정보와 미리 설정된 권한 정보를 기반으로 통지 수신자(예, 엔티티 3)는 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)로 통지 메시지를 보낼 수 있는 권한을 가지는지 여부를 검증할 수 있다. 이를 통해, 본 발명의 방법 1에 대응되는 동작을 통지 수신자(예, 엔티티 3)가 수행할 수 있다.

또한, 본 발명의 방법 2에 대응되는 동작을 통지 수신자(예, 엔티티 3)가 수행할 수 있도록 통지 메시지는 구독 생성자(또는 요청 발신자)(예, 엔티티 1)의 식별 정보를 포함할 수 있다. 또한, 통지 메시지에 포함될 구독 생성자(또는 요청 발신자)의 식별 정보를 저장하는 속성 정보를 구독 자원에 추가할 수 있다. 예를 들어, 구독 자원은 자신을 생성한 엔티티 또는 디바이스의 식별 정보를 지시하는 속성 정보(예, creator 속성)를 포함할 수 있다. 본 명세서에서 설명의 편의를 위해 구독 자원을 생성한 엔티티 또는 디바이스의 식별 정보를 지시하는 속성 정보(예, creator 속성)는 생성자 속성 정보라고 지칭될 수 있다. 예를 들어, 생성자 속성 정보는 자신을 생성한 엔티티 또는 디바이스의 주소 정보(예, URI)를 포함할 수 있다. 따라서, 구독 생성자(또는 요청 발신자)(예, 엔티티 1)가 구독 요청 메시지를 호스팅 엔티티(예, 엔티티 2)에게 전송하면, 호스팅 엔티티(예, 엔티티 2)는 구독 요청 메시지에 포함된 구독 생성자(또는 요청 발신자)(예, 엔티티 1)의 식별 정보(예, fr)를 기반으로 생성자 속성 정보(예, creator 속성)를 설정할 수 있다. 그런 다음, 호스팅 엔티티(예, 엔티티 2)는 통지 메시지를 전송할 때 구독 생성자(또는 요청 발신자)(예, 엔티티 1)의 식별 정보를 통지 메시지에 포함시켜 전송할 수 있다. 따라서, 통지 메시지에 포함된 구독 생성자(또는 요청 발신자)(예, 엔티티 1)의 식별 정보와 미리 설정된 권한 정보를 기반으로 통지 수신자(예, 엔티티 3)는 구독 생성자(또는 요청 발신자)(예, 엔티티 1)가 통지 수신자(예, 엔티티 3)로 통지 메시지를 보낼 수 있는 권한을 가지는지(또는 자신에 대한 액세스 권한을 가지는지 또는 자신에게 통지 메시지를 보내기 위한 구독을 설정할 수 있는 권한을 가지는지) 여부를 검증할 수 있다. 이를 통해, 본 발명의 방법 2에 대응되는 동작을 통지 수신자(예, 엔티티 3)가 수행할 수 있다.

본 발명에 따른 방법 3에서, 통지 수신자(예, 엔티티 3)로 전송되는 통지 메시지는 통지 이벤트 발생에 의해 생성되어 전송될 수도 있고, 통지 이벤트 발생과 무관하게 호스팅 엔티티(예, 엔티티 2)가 검증 요청을 위해 생성한 것일 수도 있다. 요청 발신자(예, 엔티티 1)와 통지 수신자(예, 엔티티 3)가 상이한 경우, 통지 수신자(예, 엔티티 3)로 전송되는 통지 메시지는 본 발명에 따른 권한 확인을 위한 검증 요청을 지시하는 파라미터 정보(예, verificationRequest)를 포함할 수 있다. 예를 들어, 통지 수신자(예, 엔티티 3)가 본 발명의 방법 3에 따라 통지 메시지를 전송하는 경우 상기 파라미터 정보(예, verificationRequest)는 일정한 값(예, TRUE)으로 설정될 수 있다.

도 17은 본 발명에 따른 구독 및 통지 절차를 예시한다. 도 17은 본 발명에 따른 방법 3의 예를 예시한다. 도 17의 예에서는 호스팅 엔티티(예, 엔티티 2)가 검증을 위해 통지 수신자(예, 엔티티 3)로부터 적어도 하나의 통지 메시지(또는 NOTIFY 요청)에 대한 응답을 수신할 수 있다. 예를 들어, 수신되는 응답은 구독 승인 이후 처음 수신되는 통지 메시지의 응답 메시지일 수 있다. 도 15 및 도 16의 예와 비교하여, 도 17의 예에서는 호스팅 엔티티(예, 엔티티 2)가 요청 발신자(예, 엔티티 1)의 권한 확인(예, 요청 발신자(예, 엔티티 1)가 구독 대상 자원 또는 구독 자원에 대한 권한을 가지는지 확인)을 성공적으로 수행한 후(S1704) 호스팅 엔티티(예, 엔티티 2)는 바로 구독 요청에 대한 확인응답(acknowledgement)를 요청 발신자(예, 엔티티 1)으로 전송할 수 있다(S1706). S1706의 확인응답은 호스팅 엔티티(예, 엔티티 2)가 임시로 구독 요청을 수락했음을 나타낼 수 있다. 이후 호스팅 엔티티(예, 엔티티 2)는 통지 수신자(예, 엔티티 3)으로부터 수신된 응답이 성공적인 검증 결과를 포함하는지 확인할 때까지(S1716) 해당 구독 요청을 임시로 승인하거나 관련 정보를 내부적으로 저장할 수 있다.

S1706에서, 호스팅 엔티티(예, 엔티티 2)는 구독 승인 절차의 상태 정보를 요청 발신자(예, 엔티티 1)에게 알려줄 수 있다. 예를 들어, 논-블록킹 모드의 경우(예, 도 9 내지 도 11 관련 설명 참조), S1706에서 호스팅 엔티티(예, 엔티티 2)가 구독을 생성/승인하고 S1718에서 검증 성공 이후 이를 재확인해주거나, S1720에서 검증 실패 이후 구독 삭제/거절/취소할 수 있다. 다른 예로, 블록킹 모드의 경우(예, 도 7 및 도 8 관련 설명 참조), S1706에서 호스팅 엔티티(예, 엔티티 2)가 구독 승인을 보류하고 S1718에서 검증 성공 이후 이를 승인하거나, S1720에서 검증 실패 이후 구독 승인을 거절할 수 있다. S1706 단계는 선택적(optional)일 수 있다.

S1708에서 호스팅 엔티티(예, 엔티티 2)는 통지 대상인 통지 수신자(예, 엔티티 3)에게 통지 메시지를 전송할 수 있다. 앞서 설명된 바와 같이, S1708에서 통지 수신자(예, 엔티티 3)로 전송되는 통지 메시지는 통지 이벤트 발생에 의해 생성되어 전송될 수도 있고, 통지 이벤트 발생과 무관하게 호스팅 엔티티(예, 엔티티 2)가 검증 요청을 위해 생성한 것일 수도 있다. 호스팅 엔티티(예, 엔티티 2)는 통지 수신자(예, 엔티티 3)에게 통지 메시지를 보내면서 이에 대한 응답을 요청할 수 있다. 이 경우 통지 수신자(예, 엔티티 3)는 호스팅 엔티티(예, 엔티티 2)가 자신에게 통지를 보낼 수 있는 권한이 있는지 확인하고, 그렇지 않은 경우 실패 응답 메시지를 S1714에서 전송할 수 있다. 이 경우에 호스팅 엔티티(예, 엔티티 2)는 실패 응답 메시지를 통해 이를 확인하고 해당 구독 자원을 추후에 삭제할 수 있다. 해당 구독 자원의 삭제는 요청 발신자(예, 엔티티 1)에 알려질 수 있다.

S1708 단계에서, 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, Entity 1)와 통지 수신자(예, 엔티티 3)가 동일한지 여부를 판별할 수 있다. 예를 들어, 호스팅 엔티티(예, 엔티티 2)는 요청 발신자(예, Entity 1)의 식별 정보(또는 주소 정보)와 통지 수신자(예, 엔티티 3)의 식별 정보(또는 주소 정보)를 기반으로 두 엔티티의 동일성 여부를 판별할 수 있다. 예를 들어, 요청 발신자(예, Entity 1)의 식별 정보(또는 주소 정보)는 구독 요청의 fr 정보로부터 획득할 수 있다. 예를 들어, 통지 수신자(예, 엔티티 3)의 식별 정보(또는 주소 정보)는 구독 자원의 통지 대상 속성 정보(예, notificationURI 속성)로부터 획득하거나 추출/유추할 수 있다. 요청 발신자(예, Entity 1)와 통지 수신자(예, 엔티티 3)가 상이한 경우 호스팅 엔티티(예, 엔티티 2)는 통지 메시지를 전송할 수 있다.

S1708에서, 호스팅 엔티티(예, 엔티티 2)는 통지 대상이 요청 발신자(예, Entity 1)이 아닌 경우(또는 요청 발신자(예, Entity 1)와 통지 수신자(예, Entity 3)가 상이한 경우), 통지 이벤트(Notification Event) 발생에 의한 통지 메시지(예, Notify 요청 메시지)에 통지 전송자인 호스팅 엔티티(예, 엔티티 2)의 식별 정보(예, ID 등) 뿐만 아니라 요청 발신자(또는 구독 생성자)(예, 엔티티 1)의 식별 정보를 함께 포함시킬 수 있다. 이를 위해 요청 발신자(또는 구독 생성자)(예, 엔티티 1)의 식별 정보는 구독 자원의 일부(예, 생성자 속성 정보 또는 creator 속성)로 호스팅 엔티티(예, 엔티티 2)에 저장될 수 있다. S1708에서 통지 메시지(또는 NOTIFY 요청 메시지)는 실제로 통지 이벤트(Notification Event)가 발생하는 경우에만 전송될 수 있는 것은 아니며 검증을 위해 임의로 전송될 수 있다. 또한, 예를 들어, S1708은 S1706 이후에 수행될 수 있다.

S1708에서, 호스팅 엔티티(예, 엔티티 2)는 통지 대상이 요청 발신자(예, Entity 1)이 아닌 경우(또는 요청 발신자(예, Entity 1)와 통지 수신자(예, Entity 3)가 상이한 경우), 통지 메시지는 본 발명에 따른 권한 확인을 위한 검증 요청을 지시하는 파라미터 정보(예, verificationRequest)를 더 포함할 수 있다. 예를 들어, 파라미터 정보(예, verificationRequest)는 일정한 데이터 타입(예, boolean)을 가질 수 있다. 또한, 예를 들어, 호스팅 엔티티(예, 엔티티 2)가 통지 수신자(예, 엔티티 3)에게 구독 검증을 위해 권한 확인을 요청하는 통지 메시지를 전송하는 경우 상기 파라미터 정보는 일정한 값(예, TRUE)으로 설정될 수 있다. 예를 들어, 상기 파라미터 정보(예, verificationRequest)가 특정 값(예, TRUE)으로 설정된 경우 통지 수신자(예, 엔티티 3)는 통지 메시지를 검증 요청으로서 인식할 수 있다. 다른 예로, 상기 파라미터 정보(예, verificationRequest)가 특정 값(예, FALSE)으로 설정된 경우 통지 수신자(예, 엔티티 3)는 통지 메시지를 일반적인 통지 절차에 따른(예, 통지 이벤트 발생에 의한) 요청 메시지로서 인식할 수 있다.

통지 수신자(예, Entity 3)는 호스팅 엔티티(예, 엔티티 2)가 자신에게 통지 메시지를 보낼 수 있는 권한을 가지는지 여부 및/또는 구독 생성자(또는 요청 발신자)(예, 엔티티 1)가 자신에게 통지 메시지를 보낼 수 있는 권한(또는 자신에게 통지 메시지를 보내기 위한 구독을 설정할 수 있는 권한)을 가지는지 여부를 검증할 수 있다(S1710, S1712). 이들 검증 과정은 도 15 및 도 16에 예시된 S1506 및 S1607에 대응될 수 있다. 도 17에서 S1710과 S1712의 순서는 필요에 따라 서로 바뀔 수 있다.

S1716에서 통지 수신자(예, Entity 3)에 의한 검증 결과가 성공임을 확인하기 전까지 호스팅 엔티티(예, Entity 2)는 S1706 과정을 임시 승인 또는 구독 요청의 성공적 수신으로 판단하여 통지 이벤트가 발생하더라도 통지 메시지(또는 Notify 요청)을 통지 수신자(예, Entity 3)에게 보내지 않을 수 있다. 예를 들어, 호스팅 엔티티(예, 엔티티 2)가 구독 요청을 수신하고 구독 자원을 생성한 다음 S1708 단계에서 통지 메시지를 전송할 수 있다. 이 경우, 생성된 구독 자원으로 인해 통지 이벤트가 발생할 수 있다. 하지만, 구독 요청에 대한 권한 확인이 완료된 상태가 아니기 때문에 발생된 통지 이벤트에 의해 통지 메시지가 생성되더라도 무시하거나 통지 수신자(예, Entity 3)로 전송하지 않을 수 있다. 이와 같은 구독 승인 상태에 대한 정보는 구독 자원의 일부로 호스팅 엔티티(예, Entity 2)에 저장될 수 있다.

S1714에서 검증 성공 결과를 포함한 응답을 수신하는 경우, S1716에서 호스팅 엔티티(예, Entity 2)는 해당 구독 검증(Subscription Verification)을 성공으로 판단할 수 있다. 만일 S1706에서 임시로 구독 요청을 승인하였거나 내부적으로 구독 정보를 유지하고 있는 경우에는 해당 구독 정보를 명시적으로 생성/저장할 수 있다. S1718에서, 호스팅 엔티티(예, Entity 2)는 최종 구독 승인 확인을 구독 생성자(또는 요청 발신자)(예, Entity 1)에 전달할 수 있다.

반면 S1714에서 검증 실패 결과를 포함하는 응답을 수신하거나, S1714의 응답 메시지의 타임아웃(timeout), 또는 통지 수신자(예, Entity 3)가 S1708의 요청을 인식할 수 없어 검증을 수행할 수 없는 경우, 단순한 요청 메시지 수신의 의미로써 일반적인 성공 응답을 전달한 경우(검증 성공 결과 포함하지 않음) 등의 경우에는 호스팅 엔티티(예, Entity 2)는 구독 검증(Subscription Verification)을 실패로 인식하고 S1720에서 해당 구독 절차를 취소할 수 있다. 다른 예로, 통지 수신자(예, Entity 3)가 검증 성공 결과를 포함한 응답 메시지를 전송하더라도 네트워크 문제 등으로 인해 호스팅 엔티티(예, Entity 2)에서 타임아웃(timeout)으로 인식되는 경우가 생길 수 있다. 따라서, 타임아웃의 경우 호스팅 엔티티(예, Entity 2)는 해당 구독 절차를 취소하지 않고 S1708 과정을 반복할 수도 있다.

S1706 이전에 호스팅 엔티티(예, Entity 2)가 구독 정보(또는 구독 자원)을 명시적으로 생성/저장하는 경우 S1720 과정은 생성된 구독 정보(또는 구독 자원)을 삭제하는 과정일 수 있다. 반면 호스팅 엔티티(예, Entity 2)가 구독 정보(또는 구독 자원)를 임시/내부적으로 유지하고 있는 경우 S1720 과정은 이러한 임시/내부 정보를 취소/삭제하는 과정일 수 있다. S1722에서 호스팅 엔티티(예, Entity 2)는 구독 취소/삭제를 구독 생성자(또는 요청 발신자)(예, Entity 1)에 알릴 수 있다.

추가적으로, S1702에서 구독 요청이 다수의 통지 대상을 포함할 수 있으며 S1708에서 통지 메시지가 복수의 엔티티 또는 디바이스에 전송될 수 있다. 이 경우 S1714의 응답에 따라 호스팅 엔티티(예, Entity 2)는 S1720에서 적절한 조치를 취할 수 있다. 예를 들어, 해당 구독 전체를 삭제/취소하거나 전체 통지 대상 중 선택적으로 통지 대상을 삭제할 수 있다. 이러한 처리 결과는 S1722에서 구독 생성자(또는 요청 발신자)(예, Entity 1)에 전달될 수 있다.

S1708의 요청 메시지는 실제 통지 이벤트(Notification Event) 발생 시 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)에 전송하는 Notify 요청 메시지에 해당할 수 있다. 하지만 S1714에서 해당 구독 절차가 무효한 것으로 판명될 경우 S1706과 S1716 사이에 불필요한 구독 정보를 생성/저장해야 하는 문제점이 있을 수 있다. 또한 S1708에서 매우 큰 사이즈의 Notify 요청 메시지가 전송되고 이후 S1714에서 검증이 실패했다고 판명된다면 S1708에서 불필요한 네트워크 자원 소모 등의 문제를 야기할 수 있다. 따라서 S1708 단계는 반드시 실제 통지 이벤트 발생에 의한 Notify 요청 메시지일 필요는 없으며 도면에 표기된 것과 같이 호스팅 엔티티(예, Entity 2)의 검증 요청(verify request)을 통지 수신자(예, Entity 3)가 인식할 수 있는 어떠한 메시지라도 가능하다. 이러한 요청 메시지는 Verify 요청 메시지라고 지칭될 수 있다. 예를 들어, Verify 요청 메시지는 Notify 요청 메시지에서 구독 대상 자원에 대한 내용이 없는 경우에 해당할 수 있다. 따라서 실제 통지 이벤트가 발생하지 않아도 Notify 메시지 형식으로 검증을 요청하는 것 또한 가능하다.

호스팅 엔티티(예, Entity 2)가 검증을 요청하였고 검증이 성공적일 경우 통지 수신자(예, Entity 3)는 이 결과를 호스팅 엔티티(예, Entity 2)에 반환할 수 있다. S1708의 메시지 타입이 응답을 반드시 전송하지 않아도 되거나 또는 이 메시지가 명시적으로 응답을 요구하지 않더라도 통지 수신자(예, Entity 3)는 무조건 응답을 반환할 수 있다.

구독 생성자(또는 요청 발신자)(예, Entity 1)은 S1702에서 본 발명에 따른 방법 3에 의한 호스팅 엔티티(예, 엔티티 2)의 검증 요청에 대한 결과 메시지가 통지 수신자(예, 엔티티 3)으로부터 호스팅 엔티티(예, Entity 2)에 특정 시간 내에 도달할 수 있도록 시간을 지정할 수 있다. 시간 내에 도달하지 않은 경우 호스팅 엔티티(예, Entity 2)는 이를 인식하고 구독 생성자(또는 요청 발신자)(예, Entity 1)에게 알려줄 수 있다.

S1718 또는 S1722의 메시지 전송은 동기식 논-블록킹(Non-blocking) 모드에서 응답 메시지를 통해 그리고 비동기식 논-블록킹(Non-blocking) 모드에서 요청 메시지를 통해 가능하다. 메시지 형식은 다를 수 있지만 구독이 승인되었는지 취소 되었는지의 정보가 전달되는 것은 동일하다.

방법 1 및/또는 방법 2을 적용할 경우, 구독 검증(Subscription Verification) 수행 시 호스팅 엔티티(예, Entity 2)의 권한만 확인하는 과정에서 발생할 수 있는 다른 엔티티의 구독 관련 권한 무단 도용을 방지할 수 있다. 또한, 구독 승인을 위한 권한 확인을 강화함으로써 구독/통지 메커니즘의 통지에 의한 공격(예, DDoS 공격)을 방지할 수 있다.

방법 3의 경우, 호스팅 엔티티(예, Entity 2)에 의한 구독 검증의 장점을 포함한다. 이와 더불어, 통지 수신자(예, Entity 3)가 권한 확인을 직접 수행하므로, 호스팅 엔티티(예, Entity 2)는 통지 수신자(예, Entity 3)가 가지고 있는 권한 정보를 획득할 필요가 없다. 따라서, 호스팅 엔티티(예, Entity 2)가 해당 권한 정보를 획득하지 못하는 경우 검증 수행이 불가능한 상황을 방지할 수 있다. 또한, 호스팅 엔티티(예, Entity 2)가 구독 요청 시 마다 이 과정을 수행하는 부담을 각각의 통지 수신자(예, Entity 3)로 분산시킬 수 있다. 또한, 구독 생성 이후에 통지 수신자(예, Entity 3)의 권한이 변경되어 검증 실패로 인한 구독 취소가 발생할 수 있다. 이를 위해, 방법 2에서는 호스팅 엔티티(예, Entity 2)가 통지 수신자(예, Entity 3)의 권한 정보를 별도의 과정을 통해 항상 최신으로 유지함으로써 검증 과정을 수행할 수 있다. 반면, 방법 3에서는 호스팅 엔티티(예, Entity 2)가 별도의 과정 없이 통지 메시지 전송 시마다 통지 수신자(예, Entity 3)로부터 통지 응답을 통해 현재 권한 정보에 기반한 검증 결과를 수신할 수 있다.

도 18은 본 발명이 적용될 수 있는 장치의 블록도를 예시한다. 본 발명에 있어서, M2M 게이트웨이, M2M 서버 또는 M2M 디바이스는 각각 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.

전송장치(10)와 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작시 연결(operatively connected)되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.

메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다. 또한, 메모리(12, 22)는 각종 설정 정보와 데이터를 포함하는 리소스를 저장하는 데 사용될 수 있다.

프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.

전송장치(10)의 프로세서(11)는 상기 프로세서(11) 또는 상기 프로세서(11)와 연결된 스케줄러로부터 스케줄링되어 외부로 전송될 신호 및/또는 데이터에 대하여 소정의 부호화(coding) 및 변조(modulation)를 수행한 후 RF 유닛(13)에 전송한다. 수신장치(20)의 신호 처리 과정은 전송장치(10)의 신호 처리 과정의 역으로 구성된다. 프로세서(21)의 제어 하에, 수신장치(20)의 RF 유닛(23)은 전송장치(10)에 의해 전송된 무선 신호를 수신한다. 상기 프로세서(21)는 수신 안테나를 통하여 수신된 무선 신호에 대한 복호(decoding) 및 복조(demodulation)를 수행하여, 전송장치(10)가 본래 전송하고자 했던 데이터를 복원할 수 있다.

RF 유닛(13, 23)은 하나 이상의 안테나를 구비한다. 안테나는, 프로세서(11, 21)의 제어 하에 본 발명의 일 실시예에 따라, RF 유닛(13, 23)에 의해 처리된 신호를 외부로 전송하거나, 외부로부터 무선 신호를 수신하여 RF 유닛(13, 23)으로 전달하는 기능을 수행한다. 도 18에서 송신장치와 수신장치가 각각 RF 유닛을 통해 통신하는 것으로 도시되어 있지만 송신장치와 수신장치가 유선 네트워크를 통해 통신하는 것도 가능하다. 이 경우, RF 유닛은 네트워크 인터페이스 유닛(network interface unit, NIU)으로 대체될 수 있다.

이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 문서에서 기지국에 의해 수행된다고 설명된 특정 동작은 경우에 따라서는 그 상위 노드(upper node)에 의해 수행될 수 있다. 즉, 기지국을 포함하는 복수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. 기지국은 고정국(fixed station), Node B, eNode B(eNB), 액세스 포인트(access point) 등의 용어에 의해 대체될 수 있다. 또한, 단말은 UE(User Equipment), MS(Mobile Station), MSS(Mobile Subscriber Station) 등의 용어로 대체될 수 있다.

본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태를 포함하는 소프트웨어 코드 또는 명령어(instruction)로 구현될 수 있다. 소프트웨어 코드 또는 명령어는 컴퓨터 판독가능한 매체에 저장되어 프로세서에 의해 구동될 수 있으며 프로세서에 의해 구동될 때 본 발명에 따른 동작들을 수행할 수 있다. 상기 컴퓨터 판독가능한 매체는 상기 프로세서 내부 또는 외부에 위치하거나 원격으로 네트워크를 통해 상기 프로세서와 연결될 수 있으며, 상기 프로세서와 데이터를 주고 받을 수 있다.

본 발명은 본 발명의 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

본 발명은 단말, 서버, 게이트웨이 등과 같은 통신 장치에 사용될 수 있다.

Claims (15)

1. M2M(Machine-to-Machine) 디바이스에서 자원 구독(resource subscription)을 위한 메시지 처리 방법으로서,
   제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며;
   상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하는 단계;
   상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하는 단계;
   상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하는 단계; 및
   상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하는 단계를 포함하되,
   상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며,
   상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함하는, 방법.
2. 제1항에 있어서,
   상기 제2 디바이스에 의한 권한 확인은 상기 M2M 디바이스가 상기 제2 디바이스로 통지 메시지를 전송할 수 있는 권한을 가지는지 여부를 확인하는 것을 포함하는, 방법.
3. 제1항에 있어서,
   상기 제2 디바이스에 의한 권한 확인은 상기 제1 디바이스가 상기 제2 디바이스로 통지 메시지를 전송하기 위한 구독을 설정할 수 있는 권한을 가지는지 여부를 확인하는 것을 더 포함하는, 방법.
4. 제1항에 있어서,
   상기 제2 디바이스로 상기 통지 메시지를 전송하는 단계 전에, 상기 제1 디바이스로 상기 구독 요청 메시지에 대한 임시 수락 메시지를 전송하는 단계를 더 포함하는, 방법.
5. 제1항에 있어서,
   상기 제2 디바이스에 의한 권한 확인의 결과가 성공인지 여부를 판별하는 단계;
   상기 권한 확인의 결과가 성공인 경우, 상기 제1 디바이스로 구독 승인 메시지를 전송하는 단계; 및
   상기 권한 확인의 결과가 실패인 경우, 상기 자원 구독을 취소하는 단계를 더 포함하는, 방법.
6. 제5항에 있어서,
   상기 권한 확인 결과가 실패인 경우, 상기 자원 구독이 취소되었음을 알리는 메시지를 상기 제1 디바이스로 전송하는 단계를 더 포함하는, 방법.
7. 제1항에 있어서,
   상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며,
   상기 방법은 상기 구독 정보를 임시로 저장하는 단계를 더 포함하는, 방법.
8. 제1항에 있어서,
   상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며,
   상기 방법은 상기 구독 정보를 기반으로 구독 자원을 생성하는 단계를 더 포함하는, 방법.
9. 제8항에 있어서,
   상기 제1 디바이스의 식별 정보는 상기 구독 자원의 생성자 속성 정보에 저장되는, 방법.
10. 제8항에 있어서,
    상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트가 발생되는 경우 생성되며,
    상기 통지 이벤트는 상기 구독 대상 자원의 상태 변화를 포함하는, 방법.
11. 제1항에 있어서,
    상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트의 발생과 독립적으로 생성되는, 방법.
12. 제1항에 있어서,
    상기 제1 디바이스의 식별 정보는 상기 구독 요청 메시지의 발신자를 지시하는 주소 정보를 포함하며,
    상기 제2 디바이스의 식별 정보는 상기 통지 메시지의 통지 대상을 지시하는 주소 정보를 포함하는, 방법.
13. 제1항에 있어서,
    상기 자원은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, 방법.
14. 제1항에 있어서,
    상기 구독 요청 메시지에서 응답 메시지 타입 정보는 블록킹 요청, 동기식 논-블록킹 요청, 비동기식 논-블록킹 요청 중 하나를 지시하는, 방법.
15. M2M(Machine-to-Machine) 디바이스에 있어서, 상기 M2M 디바이스는
    네트워크 인터페이스 유닛(Network Interface Unit); 및
    상기 네트워크 인터페이스 유닛과 동작시 연결되는(operatively connected) 프로세서를 포함하며, 상기 프로세서는
    제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하고, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며,
    상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하고,
    상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하고,
    상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하고,
    상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하도록 구성되며,
    상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며,
    상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함하는, M2M 디바이스.

Images