KR20170074861A

KR20170074861A - 무선 통신 시스템에서 제어 메시지의 동작을 보장하기 위한 방법 및 이를 위한 장치

Info

Publication number: KR20170074861A
Application number: KR1020177008870A
Authority: KR
Inventors: 안홍범; 김성윤; 정승명; 최희동
Original assignee: 엘지전자 주식회사
Priority date: 2014-10-27
Filing date: 2015-06-29
Publication date: 2017-06-30
Also published as: US20170311303A1; WO2016068442A1; US10085244B2

Abstract

무선 통신 시스템에서 제어 동작의 처리를 보장하기 위한 방법으로서, 상기 방법은 제 1 M2M(machine to machine)/IoT(Internet of Things) 장치에 의해 수행되며, 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스 생성 요청을 제 3 M2M/IoT 장치에 전송하는 단계, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고, 상기 리소스 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 지시자에 따른 상기 제어 동작의 처리 결과를 포함하는 제어 결과 통지를 상기 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 제어 결과 통지는 상기 리소스 생성 요청의 식별자를 포함하고, 그리고 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하는지 여부를 확인하는 단계를 포함할 수 있다.

Description

무선 통신 시스템에서 제어 메시지의 동작을 보장하기 위한 방법 및 이를 위한 장치

본 발명은 무선 통신 시스템에서 제어 메시지의 동작을 보장하기 위한 방법 및 이를 위한 장치에 관한 것이다.

유비쿼터스 시대에 접어들면서 M2M(Machine to Machine) 또는 IoT(Internet of Things) 통신 기술이 각광 받고 있다. M2M/IoT 통신 기술은 TIA, ATIS, ETSI, oneM2M/IoT 등 많은 표준화 개발 기구(SDO: Standard Development Organization)에서 연구 중에 있다. M2M/IoT 환경에서는 여러 M2M/IoT 관련 애플리케이션(Network Application/Gateway Application/Device Application)간의 통신이 발생하고, M2M/IoT 플랫폼 또는 프레임워크(예컨대, 공통 서비스 엔티티(Common Service Entity; CSE)과 네트워크 측 애플리케이션(예컨대, Network Application)를 운용하는 주체가 다를 수 있다.

한편, M2M/IoT 시스템은 리소스 기반의 서비스를 지원한다. 이에, 특정 M2M/IoT 장치에 대한 제어 동작 역시 그와 관련된 리소스 또는 그 하위의 속성 값의 변경을 통해 이루어질 것이다.

하지만, 이러한 리소스 기반의 제어 동작은 상기 제어 동작의 결과를 나타내는 리소스 또는 그의 속성 값이 상기 제어 동작의 실제 결과와 동일하다는 것을 보장하지는 않는다. 예컨대, 특정 M2M/IoT 장치의 상태를 변경하고자 하는 제어가 요청된 경우, 상기 특정 M2M/IoT 장치의 상태를 나타내는 리소스와 실제 상기 특정 M2M/IoT 장치의 상태는 반드시 일치하지는 않는다.

따라서, M2M/IoT 시스템에서 특정 M2M/IoT 장치의 제어와 관련된 리소스와 해당 제어와의 일치를 보장하기 위한 방안이 제안될 필요가 있다.

본 발명은 스케줄 정보 변경 방법 및 이를 위한 장치를 제안하고자 한다.

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

본 발명의 일 실시예에 따른 무선 통신 시스템에서 제어 동작의 처리를 보장하기 위한 방법으로서, 상기 방법은 제 1 M2M(machine to machine)/IoT(Internet of Things) 장치에 의해 수행되며, 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스 생성 요청을 제 3 M2M/IoT 장치에 전송하는 단계, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고; 상기 리소스 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로부터 수신하는 단계; 상기 지시자에 따른 상기 제어 동작의 처리 결과를 포함하는 제어 결과 통지를 상기 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 제어 결과 통지는 상기 리소스 생성 요청의 식별자를 포함하고; 및 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하는지 여부를 확인하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 지시자는 상기 제어 동작의 처리 보장을 위해 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스의 생성을 트리거할 수 있다.

추가적으로 또는 대안적으로, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하면, 상기 방법은 상기 제어 결과 통지의 내용을 상기 제 1 M2M/IoT 장치의 상태에 반영하는 단계를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하지 않으면, 상기 방법은 상기 리소스 생성 요청을 상기 제 3 M2M/IoT 장치로 재전송하는 단계를 더 포함할 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 제어 동작의 처리를 보장하기 위한 방법으로서, 상기 방법은 제 1 M2M(machine to machine)/IoT(Internet of Things) 장치에 의해 수행되며, 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스(이하, "전달 리소스" 로 지칭함)의 생성 요청을 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고; 상기 리소스 생성 요청에 따라 상기 전달 리소스를 생성하는 단계; 상기 전달 리소스의 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로 전송하는 단계; 상기 생성된 전달 리소스에 상기 지시자가 존재하는지 여부를 판단하는 단계; 상기 생성된 전달 리소스에 상기 지시자가 존재하면, 상기 제어 동작의 처리 보장을 위한 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스를 생성하는 단계; 상기 제 2 M2M/IoT 장치로부터 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청이 수신되면, 상기 제어 동작의 처리 결과를 포함하는 리소스를 생성하는 단계; 및 상기 생성된 구독 리소스에 따라 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지를 상기 제 3 M2M/IoT 장치로 전송하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 방법은 사전에 생성된 구독(subscription) 리소스에 따라 상기 제어 메시지의 내용 또는 상기 지시자를 포함하는 제어 동작을 지시하기 위한 통지 메시지를 상기 제 2 M2M/IoT 장치로 전송하는 단계; 및 상기 통지 메시지에 따른 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 상기 제 2 M2M/IoT 장치로부터 수신하는 단계를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 지시자는 상기 제 2 M2M/IoT 장치에게 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 추가로 지시할 수 있다.

추가적으로 또는 대안적으로, 상기 방법은 상기 구독 리소스를 생성하는 단계는 상기 리소스 생성 요청의 식별자와 상기 구독 리소스를 맵핑하는 단계를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 구독 리소스를 생성하는 단계는 상기 제어 동작과 관련된 리소스의 변경의 통지를 1 회로 제한하는 단계를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지의 전송에 대한 응답을 상기 제 3 M2M/IoT 장치로부터 수신하면, 상기 방법은 상기 생성된 구독 리소스를 삭제하는 단계를 더 포함할 수 있다.

본 발명의 또다른 일 실시예에 따르 ㄴ무선 통신 시스템에서 제어 동작의 처리를 보장하도록 구성된 M2M(machine to machine)/IoT(Internet of Things) 장치로서, 상기 M2M/IoT 장치는 무선 주파수(Radio Frequency; RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하고, 상기 프로세서는 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스 생성 요청을 제 3 M2M/IoT 장치에 전송하고, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고; 상기 리소스 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로부터 수신하고; 상기 지시자에 따른 상기 제어 동작의 처리 결과를 포함하는 제어 결과 통지를 상기 제 3 M2M/IoT 장치로부터 수신하고, 상기 제어 결과 통지는 상기 리소스 생성 요청의 식별자를 포함하고; 그리고 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하는지 여부를 확인하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하면, 상기 프로세서는 상기 제어 결과 통지의 내용을 상기 제 1 M2M/IoT 장치의 상태에 반영하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하지 않으면, 상기 프로세서는 상기 리소스 생성 요청을 상기 제 3 M2M/IoT 장치로 재전송하도록 구성될 수 있다.

본 발명의 또다른 일 실시예에 따른 무선 통신 시스템에서 제어 동작의 처리를 보장하도록 구성된 M2M(machine to machine)/IoT(Internet of Things) 장치로서, 상기 M2M/IoT 장치는 무선 주파수(Radio Frequency; RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하고, 상기 프로세서는 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스(이하, "전달 리소스" 로 지칭함)의 생성 요청을 제 3 M2M/IoT 장치로부터 수신하고, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고; 상기 리소스 생성 요청에 따라 상기 전달 리소스를 생성하고; 상기 전달 리소스의 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로 전송하고; 상기 생성된 전달 리소스에 상기 지시자가 존재하는지 여부를 판단하며; 상기 생성된 전달 리소스에 상기 지시자가 존재하면, 상기 제어 동작의 처리 보장을 위한 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스를 생성하고; 상기 제 2 M2M/IoT 장치로부터 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청이 수신되면, 상기 제어 동작의 처리 결과를 포함하는 리소스를 생성하며; 그리고 상기 생성된 구독 리소스에 따라 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지를 상기 제 3 M2M/IoT 장치로 전송하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 프로세서는 사전에 생성된 구독(subscription) 리소스에 따라 상기 제어 메시지의 내용 또는 상기 지시자를 포함하는 제어 동작을 지시하기 위한 통지 메시지를 상기 제 2 M2M/IoT 장치로 전송하고; 그리고 상기 통지 메시지에 따른 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 상기 제 2 M2M/IoT 장치로부터 수신하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 프로세서는 상기 구독 리소스를 생성함에 있어서 상기 리소스 생성 요청의 식별자와 상기 구독 리소스를 맵핑하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 프로세서는 상기 구독 리소스를 생성함에 있어서 상기 제어 동작과 관련된 리소스의 변경의 통지를 1 회로 제한하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지의 전송에 대한 응답을 상기 제 3 M2M/IoT 장치로부터 수신하면, 상기 프로세서는 상기 생성된 구독 리소스를 삭제하도록 구성될 수 있다.

상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며, 본 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.

본 발명의 일 실시예에 따르면, 무선 통신 시스템에서 스케줄 정보를 변경하여 해당 애플리케이션의 동작의 효율성을 제고할 수 있다.

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

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1 은 M2M/IoT 통신 시스템에서의 기능 구조를 도시한다.
도 2 는 M2M/IoT 기능 구조에 기반하여 M2M/IoT 통신 시스템이 지원하는 구성을 도시한다.
도 3 은 M2M/IoT 통신 시스템에서 제공되는 공통 서비스 기능을 도시한다.
도 4 는 M2M/IoT 애플리케이션 서비스 노드와 M2M/IoT 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.
도 5 는 M2M/IoT 애플리케이션 서비스 노드(예컨대, M2M/IoT 디바이스)와 M2M/IoT 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.
도 6 은 M2M/IoT 통신 시스템에서 사용하는 요청 및 응답 메시지를 주고받는 절차를 도시한다.
도 7 은 REST(representation state transfer) 시스템을 도시한다.
도 8 은 M2M/IoT 시스템에서 장치를 제어하는 방식을 설명하기 위한 도면이다.
도 9 는 복수의 제어기로부터의 특정 장치의 상태를 변경하기 위한 요청이 발생하는 상황을 도시한다.
도 10 은 스마트 그리드 서비스를 통해 발생되는 정상적인 동시다발적 장치 제어를 위한 메시지가 네트워크에 미치는 영향을 도시한다.
도 11 은 일반적인 소물 기기(Hardware Constraint Device)가 사용하는 하드웨어 컴포넌트를 도시한다.
도 12 는 본 발명의 일 실시예에 따른 시스템의 구조를 도시한다.
도 13 은 본 발명의 일 실시예에 따른 엔티티의 구성을 도시한다.
도 14 는 본 발명의 일 실시예에 따른 장치 제어 요청에 따른 해당 장치의 물리적 상태의 변환을 보장하기 위한 방안을 도시한다.
도 15 는 도 14 의 방안을 좀더 상세하게 도시한다.
도 16 은 본 발명의 또다른 실시예로써 장치 제어를 위한 메시지의 중복을 회피하면서 상기 장치 제어를 보장하는 방안을 도시한다.
도 17 은 본 발명의 실시예(들)을 수행하도록 구성된 장치의 블록도를 도시한다.

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

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

본 발명에 있어서, 기기간 통신을 위한 디바이스 즉, M2M/IoT 디바이스는 고정되거나 이동성을 가질 수 있으며, 기기간 통신을 위한 서버 즉, M2M/IoT 서버와 통신하여 사용자데이터 및/또는 각종 제어정보를 송수신하는 각종 기기들이 이에 속한다. 상기 M2M/IoT 디바이스는 단말(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/IoT 서버는 일반적으로 M2M/IoT 디바이스들 및/또는 다른 M2M/IoT 서버와 통신하는 고정된 지점(fixed station)을 말하며, M2M/IoT 디바이스들 및/또는 다른 M2M/IoT 서버와 통신하여 각종 데이터 및 제어정보를 교환한다.

이하에서는 본 발명과 관련된 기술에 대해 설명한다.

M2M/IoT 애플리케이션

서비스 로직을 실행하고 개방 인터페이스를 통해 접근 가능한(accessible) 공통 서비스 엔티티(Common Service Entity; CSE)를 사용하는 애플리케이션. M2M/IoT 애플리케이션은 M2M/IoT 디바이스, M2M/IoT 게이트웨이 또는 M2M/IoT 서버에 설치 또는 탑재될 수 있다.

M2M/IoT 서비스

표준화된 인터페이스들을 통해 M2M/IoT CSE 가 이용가능하게 하는 기능들의 집합

oneM2M/IoT 은 다양한 M2M/IoT 애플리케이션(또는 애플리케이션 엔티티(Application Entity; AE)) 들을 위한 공통 M2M/IoT 서비스 프레임워크(또는 서비스 플랫폼, 공통 서비스 엔티티(CSE) 등)를 정의한다. M2M/IoT 애플리케이션이라고 하면, e-Health, City Automation, Connected Consumer, Automotive 등의 서비스 로직을 구현한 소프트웨어라고 볼 수 있으며, 이러한 다양한 M2M/IoT 애플리케이션들을 구현하기 위해, 공통적으로 필요한 기능들을 oneM2M/IoT 서비스 프레임워크는 포함하고 있다. 따라서, oneM2M/IoT 서비스 프레임워크를 이용하면, 다양한 M2M/IoT 애플리케이션들 마다 필요한 각각의 프레임워크를 구성할 필요 없이, 이들 M2M/IoT 애플리케이션들을 쉽게 구현할 수 있다. 이는 현재 Smart Building, Smart Grid, e-Health, Transportation, Security 등 여러 M2M/IoT 버티컬(Vertical)들로 분열되어 있는 M2M/IoT 시장을 공통 oneM2M/IoT 서비스 프레임워크를 중심으로 통합할 수 있으며, 이는 M2M/IoT 시장을 크게 촉진할 것으로 기대된다.

도 1 은 M2M/IoT 통신 시스템에서의 기능 구조를 도시한다. 각 엔티티를 설명하도록 한다.

애플리케이션 엔티티 (AE, 101): 애플리케이션 엔티티는 단대단 M2M/IoT 솔루션을 위한 애플리케이션 로직을 제공한다. AE 의 예로는 화물 추적, 원격 혈당 모니터링, 원격 전력 측정 및 제어 애플리케이션이 있다. (Application Entity provides Application logic for the end-to-end M2M/IoT solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.) 보다 쉬운 이해를 위해, AE 는 M2M/IoT 애플리케이션으로 지칭될 수 있다.

공통 서비스 엔티티 (CSE, 102): CSE 는 M2M/IoT 환경에 공통적인 oneM2M/IoT 에서 정의된 서비스 기능들로 이루어져 있다. 이러한 서비스 기능들은 레퍼런스 포인트 Mca, Mcc 를 통해 노출되어 등록된(연결된) AE 와 타 CSE 에 의해 사용될 수 있다. 레퍼런스 포인트 Mcn 는 언더라잉 네트워크의 서비스를 접근하는데 사용된다. (A Common Services Entity comprises the set of "service functions" that are common to the M2M/IoT environments and specified by oneM2M/IoT. Such service functions are exposed to other entities through Reference Points Mca and Mcc. Reference point Mcn is used for accessing Underlying Network Service Entities.)

CSE 에서 제공하는 서비스 기능들의 예로는 데이터 관리, 디바이스 관리, M2M/IoT 구독(subscription) 관리, 위치 서비스 등이 있다. 이러한 기능들은 논리적으로 CSF(Common Services Functions)로 나뉘어 질 수 있다. CSE 안의 몇몇 CSF 는 필수적으로 존재하여야 하고, 몇몇은 선택적으로 존재 가능하다. 또한 CSF 안의 몇몇 기능은 필수적으로 존재하여야 하고, 몇몇 기능은 선택적으로 존재 가능하다. (예, "디바이스 관리" CSF 안에, 애플리케이션 소프트웨어 설치, 펌웨어 업데이트, 로깅, 모니터링 중 몇몇은 필수 기능이며, 몇몇은 선택 기능이다.)

언더라잉 네트워크 서비스 엔티티 (NSE, 103): NSE 는 CSE 에 서비스를 제공하는데, 이러한 서비스의 예로는 디바이스 관리, 위치 서비스, 디바이스 트리거링 등이 있다. NSE 는 특정 기술로 한정하지 않으며, 네트워크가 기본적으로 제공해주는 트랜스포트(transport)의 경우 NSE 의 서비스로 생각하지 않는다.(An Underlying Network Services Entity provides services to the CSEs. Examples of such services include device management, location services and device triggering. No particular organization of the NSEs is assumed. Note: Underlying Networks provide data transport services between entities in the oneM2M/IoT system. Such data transport services are not included in the NSE.)

아울러, 도 1 에 도시된 각 레퍼런스 포인트에 대해 설명하도록 한다.

Mca 레퍼런스 포인트

Mca 레퍼런스 포인트는 AE 와 CSE 간의 레퍼런스 포인트이다. Mca 레퍼런스 포인트는 AE 가 CSE 가 제공하는 서비스를 사용할 수 있도록, AE 가 CSE 와 통신할 수 있도록 한다. (This is the reference point between an Application Entity and a CSE. The Mca reference point shall allow an Application Entity to use the services provided by the CSE, and for the CSE to communicate with the Application Entity.)

Mca 레퍼런스 포인트를 통해 제공되는 서비스들은 CSE 에서 제공하는 기능들에 의존한다. AE 와 CSE 는 같은 물리적 장치에 있을 수도 있으며, 다른 물리적 장치에 있을 수도 있다. (The services offered via the Mca reference point are thus dependent on the functionality supported by the CSE. The Application Entity and the CSE it invokes may or may not be co-located within the same physical entity.)

Mcc 레퍼런스 포인트

Mcc 레퍼런스 포인트는 두 CSE 간의 레퍼런스 포인트이다. Mcc 레퍼런스 포인트는 CSE 가 다른 CSE 의 필요한 기능의 서비스를 사용할 수 있도록 한다. Mcc 레퍼런스 포인트를 통해 제공되는 서비스들은 CSE 에서 제공하는 기능들에 의존한다. (This is the reference point between two CSEs. The Mcc reference point shall allow a CSE to use the services of another CSE in order to fulfill needed functionality. Accordingly, the Mcc reference point between two CSEs shall be supported over different M2M/IoT physical entities. The services offered via the Mcc reference point are dependent on the functionality supported by the CSEs)

Mcn 레퍼런스 포인트

Mcn 레퍼런스 포인트는 CSE 와 NSE 간의 레퍼런스 포인트이다. Mcn 레퍼런스 포인트는 CSE 가 NSE 가 제공하는 서비스들을 사용할 수 있도록 한다. (This is the reference point between a CSE and the Underlying Network Services Entity. The Mcn reference point shall allow a CSE to use the services (other than transport and connectivity services) provided by the Underlying Network Services Entity in order to fulfill the needed functionality. ) NSE 가 제공하는 서비스는 전송(transport)과 접속(connectivity) 서비스 같은 단순한 서비스 이외의 것을 뜻하며, 디바이스 트리거링(device triggering), 스몰 데이터 전송(small data transmission), 위치 결정(positioning)과 같은 서비스가 그 예이다.

Mcc' 레퍼런스 포인트

Mcc' 레퍼런스 포인트는 서로 다른 M2M/IoT 서비스 제공자에게 속하는 CSE 간의 통신을 위해 사용된다. Mcc' 레퍼런스 포인트는 Mcc 레퍼런스 포인트와 CSE 를 서로 연결한다는 점에서 비슷할 수 있으나, 기존 Mcc 레퍼런스 포인트가 단일 M2M/IoT 서비스 제공자 내의 통신으로 국한되어 있었다면 Mcc' 레퍼런스 포인트는 서로 다른 M2M/IoT 서비스 제공자로 Mcc 를 확장한다는 개념으로 볼 수 있다.

도 2 는 M2M/IoT 기능 구조에 기반하여 M2M/IoT 통신 시스템이 지원하는 구성을 도시한다. M2M/IoT 통신 시스템은 도시된 구성에 국한되지 않고 더 다양한 구성을 지원할 수 있다. 상기 도시된 구성을 이해하는데 중요한 노드(Node)라는 개념에 대해 먼저 설명하도록 한다.

애플리케이션 전용 노드(Application Dedicated Node; ADN): CSE 가 존재하지 않고, 적어도 하나의 AE 를 갖는 노드 (An Application Dedicated Node is a Node that contains at least one Application Entity and does not contain a Common Services Entity). Mca 레퍼런스 포인트를 통해 하나의 미들 노드 또는 하나의 인프라스트럭쳐 노드와 연결될 수 있다. ADN 은 M2M/IoT 디바이스에 존재할 수 있다.

애플리케이션 서비스 노드(Application Service Node; ASN): 하나의 CSE 가 존재해야 하고, 적어도 하나의 AE 를 갖는 노드(An Application Service Node is a Node that contains one Common Services Entity and contains at least one Application Entity). Mcc 레퍼런스 포인트를 통해 하나의 미들 노드 또는 하나의 인프라스트럭쳐 노드에 연결될 수 있다. ASN 은 M2M/IoT 디바이스에 존재할 수 있다.

미들 노드(Middle Node; MN): 하나의 CSE 가 존재해야 하고, AE 를 가질 수도 있는 노드(A Middle Node is a Node that contains one Common Services Entity and may contain Application Entities). Mcc 레퍼런스 포인트를 통해서 아래 다른 카테고리에 속하는 두 노드와 연결되어야 함 (A Middle Node communicates over a Mcc references point with at least two other Nodes among either (not exclusively)):

- 하나 이상의 애플리케이션 서비스 노드(ASN)들;

- 하나 이상의 미들 노드(MN)들;

- 하나 인프라스트럭쳐 노드(IN).

또한, MN 은 ADN 과 Mca 레퍼런스 포인트를 통해 연결될 수 있다. MN 은 M2M/IoT 게이트웨이에 존재할 수 있다.

인프라스트럭쳐 노드(Infrastructure Node; IN): 하나의 CSE 가 존재해야 하고, AE 를 가질 수도 있는 노드 (An Infrastructure Node is a Node that contains one Common Services Entity and may contain Application Entities). IN 은 M2M/IoT 서버에 존재할 수 있다.

인프라스트럭쳐 노드는 MN 또는 ASN 과 Mcc 레퍼런스 포인트를 통해 다음 노드들과 통신할 수 있다. (An Infrastructure Node communicates over a Y reference point with either:

- 하나 이상의 미들 노드(들);

- 및/또는 하나 이상의 애플리케이션 서비스 노드(들)

인프라스트럭쳐 노드는 ADN 과 Mca 레퍼런스 포인트를 통해 통신할 수 있다. (An Infrastructure Node may communicate with one or more Application Dedicated Nodes over one or more respective Mca reference points.)

도 3 은 M2M/IoT 통신 시스템에서 제공되는 공통 서비스 기능을 도시한다.

M2M/IoT 통신 시스템이 제공하는 M2M/IoT 서비스 기능(즉, 공통 서비스 기능)으로는 도 3 에 도시된 것처럼 'Communication Management and Delivery Handling' , 'Data Management and Repository' , 'Device Management' , 'Discovery' , 'Group Management' , 'Addressing and Identification' , 'Location' , 'Network Service Exposure, Service Execution and Triggering' , 'Registration' , 'Security' , 'Service Charging and Accounting' , 'Session Management' , 'Subscription and Notification' 이 있다.

아래는 각 기능의 간략한 소개이다.

Communication Management and Delivery Handling (CMDH): 타 CSE 들, AE 들, NSE 들과의 통신을 제공하고 어떻게 메시지를 전달할 지의 역할을 수행한다.

Data Management and Repository (DMR): M2M/IoT 애플리케이션이 데이터를 교환, 공유할 수 있도록 하는 역할을 수행한다.

Device Management (DMG): M2M/IoT 디바이스/게이트웨이를 관리하기 위한 역할을 수행한다. 세부 기능을 살펴보면, 애플리케이션 설치 및 세팅, 설정값 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 토폴로지(Topology) 관리 등이 있다.

Discovery (DIS): 조건에 기반한 리소스 및 정보를 찾을 수 있도록 하는 역할을 수행한다.

Group Management (GMG): 리소스, M2M/IoT 디바이스, 또는 게이트웨이를 묶어 그룹을 생성할 수 있는데, 그룹과 관련된 요청을 처리하는 역할을 수행한다.

Addressing and Identification (AID): 물리 또는 논리 리소스를 식별 및 어드레싱(addressing)하는 역할을 수행한다.

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

Network Service Exposure, Service Execution and Triggering (NSE): 언더라잉 네트워크의 통신을 가능하게 하고, 언더라잉 네트워크가 제공하는 기능을 사용할 수 있도록 한다.

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

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

Service Charging and Accounting (SCA): CSE 에 요금 부가 기능을 제공하는 역할을 수행한다.

Session Management (SM): 단대단(end-to-end) 통신을 위한 M2M/IoT 세션을 관리하는 역할을 수행한다.

Subscription and Notification (SUB): 특정 리소스에 대한 변경을 구독(Subscription)하면 해당 리소스가 변경되면 이를 알리는 역할을 수행한다.

이러한 M2M/IoT 공통 서비스 기능은 CSE 를 통해 제공되며, AE(혹은, M2M/IoT 애플리케이션들)이 Mca 레퍼런스 포인트를 통해, 또는 타 CSE 가 Mcc 레퍼런스 포인트를 통해 해당 공통 서비스 기능들을 이용할 수 있다. 또 이러한 M2M/IoT 공통 서비스 기능은 언더라잉 네트워크(Underlying Network)(또는 언더라잉 네트워크 엔티티(Underlying Network Service Entity; NSE), 예: 3GPP, 3GPP2, WiFi, Bluetooth)와 연동하여 동작할 수 있다.

모든 디바이스/게이트웨이/인프라스트럭쳐가 상위 기능을 다 가지는 것은 아니다. 해당 기능들 중 필수 기능들과 선택 기능들 몇몇을 가질 수 있다.

M2M/IoT 통신 시스템에서 리소스는 M2M/IoT 통신 시스템에서 정보를 구성 및 표현하기 위한 것으로 URI 로 식별될 수 있는 모든 것을 의미한다. 상기 리소스는 일반적인 리소스, 가상 리소스 및 어나운스된 리소스(announced resource)로 분류할 수 있다. 각 리소스에 대한 정의는 다음과 같다.

가상 리소스: 가상 리소스는 특정 프로세싱을 트리거하거나 그리고/또는 결과를 리트리브(retrieve)하는데 사용되나, CSE 에 영구적으로 존재하지 않는다.

어나운스된 리소스: 어나운스된 리소스는 어나운스된(또는 통지된) 원본 리소스에 연결된 원격 CSE 에 있는 리소스이다. 어나운스된 리소스는 원본 리소스의 특징 중 일부를 유지한다. 리소스 어나운스먼트는 리소스 탐색 또는 발견(discovery)를 원활하게 한다. 원격 CSE 에 있는 어나운스된 리소스는 상기 원격 CSE 에서 원본 리소스의 자식으로서 존재하지 않거나 원본 리소스의 어나운스된 자식이 아닌 자식 리소스들을 생성하기 위해 사용된다.

일반 리소스: "가상" 또는 "어나운스된" 중 하나로 명시되지 않으면, 해당 리소스는 일반 리소스이다.

도 4 는 M2M/IoT 애플리케이션 서비스 노드와 M2M/IoT 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.

M2M/IoT 통신 시스템은 다양한 리소스(또는 자원)를 정의하는데, 이 리소스를 조작해서, 애플리케이션을 등록하고, 센서 값을 읽어 오는 등의 M2M/IoT 서비스를 수행할 수 있다. 상기 리소스는 하나의 트리 구조로 구성이 되며, CSE 과 논리적으로 연결 또는 CSE 에 저장되어 M2M/IoT 디바이스, M2M/IoT 게이트웨이, 네트워크 도메인 등에 저장될 수 있다. 이러한 측면에서, CSE 는 리소스를 관리하는 엔티티로 지칭될 수 있다. 상기 리소스는 ＜cseBase＞를 트리 루트로 가지며, 대표적인 리소스는 아래와 같다.

＜cseBase＞ 리소스: 트리로 구성된 M2M/IoT 리소스의 루트 리소스이며, 다른 모든 리소스를 포함한다.

＜remoteCSE＞ 리소스: ＜cseBase＞ 하위에 존재하는 리소스로써 해당 CSE 에 등록(연결)된 타 CSE 의 정보가 포함된다.

＜AE＞ 리소스: ＜cseBase＞ 나 ＜remoteCSE＞ 리소스 하위에 존재하는 리소스로써, ＜cseBase＞ 의 하위에 존재할 경우 해당 CSE 에 등록(연결)된 애플리케이션들의 정보가 저장되며, ＜remoteCSE＞ 하위에 존재할 경우 타 CSE(CSE 이름을 가진)에 등록된 애플리케이션들의 정보가 저장된다.

＜accessControlPolicy＞ 리소스: 특정 리소스에 대한 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여, 인증(authorization)이 이루어지게 된다.

＜container＞ 리소스: CSE 별, 또는 AE 마다 데이터를 저장하는 리소스이다.

＜group＞ 리소스: 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공하는 리소스이다.

＜subscription＞ 리소스: 리소스의 값 등의 상태가 변경되는 것을 통지(notification)을 통해 알려주는 기능을 수행하는 리소스이다.

도 5 는 M2M/IoT 애플리케이션 서비스 노드(예컨대, M2M/IoT 디바이스)와 M2M/IoT 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.

예를 들어, M2M/IoT 인프라스트럭쳐 노드에 등록된 AE(application2)가 M2M/IoT 디바이스의 센서 값을 읽어오는 방법에 대해 설명한다. 상기 센서는 보통 물리적인 장치를 가리키며, M2M/IoT 디바이스 상에 존재하는 AE(application1)은 이 센서에서 값을 읽어 자신이 등록한 CSE(CSE1)에 container 리소스 형태로 읽은 값을 저장한다. 해당 M2M/IoT 디바이스 상에 존재하는 AE 는 이를 위해 M2M/IoT 디바이스에 존재하는 CSE 에 먼저 등록되어야 하며, 등록이 완료되면, 도 5 에서와 같이 cseBaseCSE1/application1 리소스의 형태로 등록된 M2M/IoT 애플리케이션 관련 정보가 저장된다.

cseBaseCSE1/application1 리소스 하위의 container 리소스에 센서 값이 M2M/IoT 디바이스상에 존재하는 AE 에 의해 저장되면, 인프라스트럭쳐 노드에 등록된 AE 가 해당 값에 접근이 가능할 수 있다. 접근이 가능하게 하기 위해서는 상기 인프라스트럭쳐 노드에 등록된 AE 도 역시 상기 인프라스트럭쳐 노드의 CSE(CSE2)에 등록이 되어있어야 하며, 이는 application1 가 CSE1 에 등록하는 방법과 같이 cseBaseCSE2/application2 리소스에 application2 에 대한 정보를 저장함으로써 이루어진다. 또, application1 는 application2 와 직접 통신하는 것이 아니라 중간의 CSE1 과 CSE2 을 통해 통신하게 되는데, 이를 위해 먼저 CSE1 는 CSE2 에 등록되어 있어야 한다. CSE1 이 CSE2 에 등록되게 되면, cseBaseCSE2 리소스 하위에 CSE1 관련 정보(예컨대, Link)가 ＜remoteCSE＞ 리소스 형태로 저장된다. 즉, ＜remoteCSE＞는 등록된 CSE 에 대한 CSE 타입, 접근 주소(IP 주소 등), CSE ID, reachability 정보 등을 제공해 준다.

한편, 리소스 탐색(resource discovery)이란 원격의 CSE 에 있는 리소소를 탐색하는 과정을 말한다. 리소스 탐색은 리트리브(RETRIEVE) 요청을 통해 이루어지며 리소스 탐색을 위해 리트리브 요청은 아래의 내용을 포함한다.

＜startURI＞: URI 을 지시하며, 이 URI 는 리소스 탐색을 행할 리소스의 범위를 제한하는데 사용될 수 있다. 만약 ＜startURI＞가 리소스의 루트인 ＜cseBase＞를 가리킨다면, 본 리트리브 요청을 받은 수신자의 전 리소스를 대상으로 리소스 탐색을 수행하게 된다. 수신자는 ＜startURI＞가 지칭하는 리소스와 그 하위 리소스를 대상으로만 리소스 탐색을 수행하게 된다.

filterCriteria: 이 정보에는 탐색할 리소스와 관련된 정보가 기술된다. 수신자는 ＜startURI＞가 정의한 리소스 탐색 범위 안의 리소스 중에서 filterCriteria 를 만족시키는 리소스만을 검색하여 본 요청의 요청자에게 전송하게 된다.

도 4 또는 도 5 에 도시된 것처럼 M2M/IoT 시스템에서는 리소스가 트리 구조로서 표현될 수 있으며, 루트 리소스의 타입은 ＜CSEBase＞로 표현된다. 따라서, ＜CSEBase＞ 리소스 타입은 공통 서비스 엔티티(CSE)가 있는 경우에는 반드시 존재해야 한다.

도 6 은 Mca 및 Mcc 레퍼런스 포인트들 상의 일반적인 통신 플로우를 도시한다. M2M/IoT 시스템의 동작은 데이터 교환을 기반으로 수행된다. 예를 들어, 제 1 장치가 제 2 장치의 특정 동작을 멈추기 위한 명령을 전송 또는 수행하기 위해서 상기 제 1 장치는 해당 명령을 데이터 형태로 상기 제 2 장치에 전달해야한다. M2M/IoT 시스템에서는 어플리케이션(또는 CSE)와 CSE 간의 연결에서 요청 및 응답 메시지들로 데이터를 교환할 수 있다.

요청(Request) 메시지에는 다음과 같은 정보가 포함된다.

·op: 실행될 동작의 형태 (Create/Retrieve/Update/Delete/Notify 중 택일)

·to: 요청을 수신할 엔티티의 ID(즉, 수신자의 ID)

·fr: 요청을 생성한 발신자의 ID

·ri: 요청 메시지의 ID(요청 메시지를 구분하기 위해 사용되는 ID)

·mi: 해당 요청에 대한 추가 정보 (meta information)

·cn: 전달되는 리소스의 내용

응답(Response) 메시지에는 다음과 같은 정보가 포함된다. 우선 해당 요청 메시지가 성공적으로 처리된 경우에는, 상기 응답 메시지는

·to: 요청을 생성한 발신자의 ID

·fr: 요청을 수신한 수신자의 ID

·mi: 해당 요청에 대한 추가 정보 (meta information)

·rs: 요청의 처리 결과 (예를 들어, Okay, Okay and Done, Okay and in progress)

·ai: 추가적인 정보

·cn: 전달되는 리소스의 내용 (결과값(rs)만 전달될 수 있음)

를 포함하고, 요청 메시지의 처리가 실패한 경우 상기 응답 메시지는

·to: 요청을 생성한 발신자의 ID

·fr: 요청을 수신한 수신자의 ID

·mi: 해당 요청에 대한 추가 정보 (meta information)

·rs: 요청의 처리 결과 (예를 들어, Not Okay)

·ai: 추가적인 정보

를 포함할 수 있다.

한편, 다음의 표와 같은 다양한 리소스 타입이 존재한다.

[표 1]

각 리소스 타입은 해당 리소스 타입의 부모 리소스 타입(Parent Resource Type) 아래 위치할 수 있으며, 자식 리소스 타입(Child Resource Type)을 가질 수도 있다. 또한 각각의 리소스 타입은 속성(Attribute)들을 가지며, 속성에 실제 값들이 저장된다.

다음으로 아래 표 2 은 ＜container＞ 리소스 타입의 속성(Attribute)들을 정의한 것이다. 실제 값들이 저장되는 속성은 Multiplicity 를 통하여 반드시 설정( '1' )되거나, 선택적으로 설정( '0..1' )될 수 있다. 또한 해당 속성들은 생성시 특성에 따라 RO(Read Only), RW(Read and Write), WO(Write Only)와 같이 설정된다. 한편, 표 1 에 나타낸 것처럼, ＜container＞ 리소스는 자식 리소스로서 ＜container＞, ＜contentInstance＞ 및 ＜subscription＞를 가질 수 있다.

[표 2]

도 7 은 REST(representation state transfer) 시스템을 도시한다. REST 시스템의 특징은 통신 매체를 통해 특정 리소스의 상태를 전달하는 것에 있다. 도 7 에 도시된 것처럼, 제어기(controller)와 제어 대상 장치(controlled device)가 있는 경우, 요청 발신자(request originator)는 리소스를 가지고 있는 리소스 호스트(resource host)로 리소스의 상태의 변경을 요청하고, 상기 리소스 호스트는 상기 요청에 대한 응답을 전송한다.

결론적으로 해당 리소스의 상태 변경을 요청하는 행위가 실제 장치의 물리적인 상태를 변화시키는 것이 목적이라면, REST 시스템이 통신 매체를 통해 리소스의 상태 전달 뿐만 아니라, 해당 물리적인 상태의 변화까지 감지하고 이를 변경을 보장하는 것에 그 목적이 있다.

도 8 은 M2M/IoT 시스템에서 장치를 제어하는 방식을 설명하기 위한 도이다. 특히, ＜container＞ 리소스와 그것이 객체화된 containerInstance 를 기반으로 리소스를 제어하는 방식을 설명한다.

AE-1(81) 및 AE-2(82)는 AE-3(84)를 제어하기 위한 제어기(또는 제어 장치)에 설치되거나 포함된 애플리케이션을 지칭하고, AE-3 는 상기 제어기에 의해 제어되는 장치에 설치되거나 포함된 애플리케이션을 지칭한다. MN-CSE(83)는 AE-1, AE-2 및 AE-3 가 등록된 게이트웨이에 설치되거나 포함된 애플리케이션을 지칭한다. AE-3 를 포함하는 장치는 도 8 과 관련된 예에서 조명 장치(light)로 예시하기로 한다.

S81: AE-3 는 제어가 가능한 장치의 서비스 로직으로 구성되어 있다. AE-3 의 서비스 로직은 최초에 상기 MN-CSE 와 연결되면, 등록 절차를 수행하고 AE 의 상태를 외부의 요청에 따라 변경하기 위해 MN-CSE 에 ＜container＞와 ＜contentInstance＞를 생성하기 위한 요청을 전송할 수 있다. 도 8 과 관련된 예로, ＜container＞ 및 ＜contentInstance＞는 lightStatus 와 14-10-29_5-45 로 객체화 되어 저장되며, ＜contentInstance＞의 content 속성에 상기 조명 장치의 상태를 명시할 수 있다. 여기서 상기 조명 장치의 최초의 상태는 'off' 로 설정된다.

S82: 상기 MN-CSE 는 상기 AE-3 의 요청에 따라 리소스를 생성하고, AE-1 또는 AE-2 가 해당 리소스를 변경 가능하도록 접근 제어 관련 정보를 설정할 수 있다. 실제로, 접근 제어 관련 정보는 서비스 제공자의 설정에 따라 결정될 수 있다.

S83: AE-3 은 외부 제어 요청에 관한 알림을 제공받을 수 있도록 상기 생성한 조명 장치의 상태를 명시하는 ＜container＞ 리소스에 ＜subscription＞을 등록한다. 즉, AE-3 는 상기 ＜container＞ 리소스를 구독한다.

상기 구독 동작은 S81 및 S82 가 끝난 후에, AE-3 및 외부에서 제어를 원하는 다른 AE 들(도 8 의 예에서는 AE-1 과 AE-2)이 수행할 수 있다. 이는 외부에서는 상기 조명 장치의 상태를 파악하여 자신들이 GUI(Graphic User Interface)등으로 상기 상태를 표시할 필요가 있기 때문이다.

S84: AE-2 는 AE-3(즉, 상기 조명 장치)의 상태를 변경할 필요가 있어, 이를 위해서 신규한 ＜contentInstance＞의 생성 요청을 상기 MN-CSE 에 전송할 수 있다. 즉, 상기 AE-2 는 ＜contentInstance＞의 content 속성에 상기 조명 장치의 변경된 상태(예, 'on' )를 명시하기 위해 상기 content 속성이 포함된 lightStatus/14-10-29_5-45 리소스의 생성을 상기 MN-CSE 에 요청할 수 있다.

S85: S83 과정의 구독 동작의 결과에 따라 상기 변경된 상태가 상기 ＜container＞ 리소스를 구독한 AE-1, AE-2, 및 AE-3 에 통지된다.

S86: 상기 변경된 상태가 전달되면, 이에 따라 상기 AE-1 또는 상기 AE-2 는 서비스 로직에 따라 UI 등을 변경하고, 상기 AE-3 은 상기 조명 장치의 물리적 상태를 변경할 수 있다.

도 8 에서, 상기 AE-1 및 상기 AE-2 의 UI 등은 S85 의 통지에 의해 상기 조명 장치의 상태가 변경된 것을 표시하며, 실제적인 상기 조명 장치의 상태 변경은 상기 AE-3 가 상기 S85 의 통지를 수신하고나서 이루어진다. 만약, 상기 AE-3 가 상기 조명 장치의 상태 변경에 실패하면(예컨대, 상기 MN-CSE 와 AE 간의 통신 문제, 물리적인 고장 등), 상기 AE-1 및 상기 AE-2 의 UI 등은 잘못된 정보를 표시하게 되는 문제점이 있다. 즉, S85 의 통지가 상기 조명 장치의 제어의 성공을 보장하지 못한다. 이러한 문제점의 원인은 REST 기반의 리소스-기반 구조에서 요청/응답의 통신 구조로 실제 (하드웨어) 장치의 상태를 변경하기 위한 메시지 흐름에서, 상기 요청과 그에 따른 응답은 단지 해당 리소스의 값을 변경하기 위한 것이지 실제 장치의 상태의 변경을 보장하는 것은 아니기 때문이다.

도 9 는 복수의 제어기로부터의 특정 장치의 상태를 변경하기 위한 요청이 발생하는 상황을 도시한다. 상기 요청을 위한 메시지의 전송과는 다르게, 상기 특정 장치의 상태를 변경하는데에는 상대적으로 많은 시간이 소요될 수 있다. 이러한 상황에서, AE-2(92)가 장치 제어를 위한 메시지(S91)를 MN-CSE(93)로 전송하고, 이에 따라 상기 MN-CSE 가 AE-3 로 장치 제어 알림을 전송할 수 있다(S92). 이에, 상기 AE-3 는 상기 장치 제어를 수행할 것이다. 상기 AE-3 가 장치 제어를 수행하는 동안 복수의 AE 들(AE-1)로부터 또다른 장치 제어를 위한 메시지(S93-1, S93-2, S93-3)가 수신된다면, 상기 AE-3 는 상기 장치 제어를 위한 메시지들을 제대로 처리할 수 없을 것이다.

한편, 도 9 에 도시된 것처럼, 정상적인 장치 제어를 위한 메시지가 수신될 수도 있고, 또는 악의적인 목적으로 장치 제어를 위한 메시지가 수신될 수도 있다.

도 10 은 스마트 그리드 서비스에서 확인할 수 있는 시간대 별 발생한 동시다발적 장치 제어 메시지가 네트워크에 미치는 영향을 도시한다. 도 10 의 좌측 그림의 수직축은 부하량(number of event packet)에 해당한다. 정상적인 동시다발적 장치 제어를 위한 메시지라 해도, 상기 장치 제어의 대상 장치의 성능 또는 용량으로 인해 장치 제어가 보장되지 않을 수 있다. 예를 들어, 상기 장치 제어의 대상 장치의 용량 부족으로 인해 동시 다발적 메시지가 장치에 메모리 버퍼(Buffer)에 저장되지 않아 장치 제어가 보장되지 않을 수 있다.

도 11 은 일반적인 소물 기기(Hardware Constraint Device)가 사용하는 하드웨어 컴포넌트를 도시한다.

상기 소물 기기(1110)는 장치 제어 및 전체 AE 의 동작을 제어하는 MCU(Micro Controller Unit, 1111)와 AE 의 서비스 로직 및 OS(Operating System)가 저장되어 있는 SRAM(1112)과 통신(예, Bluetooth, Zigbee 등)을 통해 메시지를 송/수신할 수 있는 트랜시버(1113) 로 구성되고, 상기 트랜시버는 외부에서 수신하는 또는 MCU 에서 수신하는 메시지를 임시적으로 저장하는 데이터 버퍼를 포함할 수 있다. 또한, Light On/off (1120)는 상기 소물 기기(예컨대, 조명 장치)의 상태, 즉 켜졌는지 꺼졌는지를 표시하기 위한 사용자 인터페이스를 위한 장치 또는 모듈에 해당한다.

상기 데이터 버퍼는 하드웨어 컴포넌트 또는 사용하고자 하는 목적에 따라 그 크기가 달라질 수 있다. 예를 들어, 저전력 및 소형 크기가 필수 요구사항인 소물 기기(예, 조명 장치)는 상대적으로 굉장히 작은 크기의 데이터 버퍼를 트랜시버에서 지원한다. 협대역(Narrowband) 타입의 장치는 일반적으로 상대적으로 작은 크기의 데이터 버퍼를 구비한다. 특정 장치는 트랜시버에서 데이터 버퍼를 지원하지 않을 수도 있다. 이런 경우에는 일반적으로 DMA(Direct Memory Access)를 기법을 이용하여 MCU 에 존재하는 메모리에 직접 접근하는 경우도 존재하지만, 소물 기기를 위한 MCU 도 제한적인 메모리를 장착하고 있고, MCU 의 처리 속도가 메모리 또는 트랜시버의 데이터 버퍼의 처리 속도를 초과하게끔 메시지가 유입되는 경우에는 일정 요청은 처리가 되지 않을 수 있다.

이에 본 발명은 상기 언급한 문제점들을 해결하기 위한 방안을 제안하고자 한다.

도 12 는 본 발명의 일 실시예에 따른 시스템의 구조를 도시한다.

AE-C(1210)은 AE-T(1230)를 사용자의 입력에 따라 제어하고자 하는 서비스 로직을 포함한 엔티티로써, 일반적으로는 GUI 형태로 프로그래밍 된다. 상기 AE-C 는 일반적으로 도 13 과 같이 그래픽 객체로써 AE-T 의 현재 상태(Status of AE-T, 1311)와 상태를 변경하기 위한 명령(Control Command, 1312)이 표현된다. 상기 상태를 변환하기 위한 명령을 표시하는 그래픽 객체를 선택(푸쉬, 터치 또는 클릭 등)하면, 상기 AE-C 로부터 상기 AE-T 의 상태를 표현하는 리소스를 갱신하는 요청이 CSE(1220)로 송신되며, 이는 다시 상기 AE-T 로 전달될 것이다.

도 14 는 본 발명의 일 실시예에 따른 장치 제어 요청에 따른 해당 장치의 물리적 상태의 변환을 보장하기 위한 방안을 도시한다. 도 14 와 관련하여 설명할 실시예는 제어의 대상 장치(예, 조명 장치)(또는 해당 장치에 설치 또는 저장된 AE)는 자신이 등록된 CSE 에 ＜container＞ 리소스를 생성하고 그에 대한 변경 정보를 획득하기 위해 ＜subscription＞ 리소스를 등록한 것을 가정한다.

도 14 는 도 12 의 구조에 따라 설명되며, AE-C 는 제어기 내의 AE 이고 AE-T 는 제어의 대상인 장치 내의 AE 에 해당한다.

상기 AE-C 는 AE-T 를 위한 장치 제어 메시지와 장치 제어의 보장을 요구하는 표시자를 포함한 ＜contentInstance＞ 리소스의 생성을 상기 CSE 에 요청할 수 있다(S1401). 상기 ＜contentInstance＞ 리소스는 상기 CSE 의 ＜container＞ 리소스의 자식 리소스로서 생성되어야 한다. 다음의 표는 ＜contentInstance＞ 리소스의 속성을 정의한다.

[표 3]

상기 장치 제어 메시지는 'content' 속성에 포함되며, 상기 장치 제어의 보장을 요구하는 표시자는 'operationCheck' 속성에 포함된다. 상기 장치 제어 메시지는 간략하게 1, 0 으로 표현되거나 또는 1_30_2_40 등과 같이 복잡한 방식으로 표현될 수 있는데, 이는 서비스 제공자의 정책에 따른다. 상기 장치 제어의 보장을 요구하는 표시자는 TRUE 또는 FALSE 로 표현되며, 명시되지 않으면 FALSE 로 간주할 수 있다.

상기 AE-T 가 등록된 상기 CSE 는 상기 AE-C 가 요청한 ＜contentInstance＞ 리소스를 생성할 수 있다(S1402). 이 때, 상기 AE-C 는 해당 생성의 성공 응답에 따라 상기 장치가 정상적으로 제어되었다고 판단하지 않는다.

상기 CSE 는 상기 생성된 ＜contentInstance＞ 리소스에 정의된 'operationCheck' 속성이 TRUE 로 명시되었는지를 확인할 수 있다(S1403).

상기 'operationCheck' 속성이 TRUE 로 명시된 경우, S1404 를 수행하고, 그렇지 않으면 S1411 을 수행한다.

상기 CSE 는 향후 장치 제어의 결과를 상기 AE-C 에게 전달하기 위해 ＜contentInstance＞ 리소스의 부모 ＜container＞ 리소스에 추가 ＜subscription＞ 리소스를 생성할 수 있다(S1404). 상기 CSE 는 해당 ＜subscription＞ 리소스의 'notificationURI' 속성은 상기 AE-C 로 지정하고, 'expriationCounter' 속성은 1 로 설정한다. 다음의 표는 'expirationCounter' 속성을 정의한다.

[표 4]

상기 CSE 는 상기 AE-C 의 요청으로 생성된 ＜contentInstance＞ 리소스로 인한 통지 메시지를 상기 AE-T 에 전달할 수 있다(S1405). 이 동작은 앞서 설명한 해당 subscription 이 사전에 등록된 본 실시예의 가정에 근거한다. 상기 통지 메시지는 그 기반 리소스인 상기 ＜contentInstance＞ 리소스의 'content' 속성 값을 포함하되, 상기 장치 제어의 보장을 요구하는 TRUE 로 명시된 상기 ＜contentInstance＞ 리소스의 'operationCheck' 속성 값을 포함하도록 한다.

상기 AE-T 는 S1405 에서 수신된 통지 메시지를 기반으로 상기 장치를 제어할 수 있다(S1406).

상기 AE-T 는 S1405 에서 수신된 통지 메시지에 명시된 장치 제어의 보장을 요구하는 표시자에 따라 S1406 의 수행 결과(즉, 상기 장치 제어와 관련된 리소스 값 변경이 아닌 상기 장치 제어의 실제 결과)를 포함한 신규 ＜contentInstance＞ 리소스의 생성을 상기 CSE 에 요청한다(S1407). 이러한 신규 ＜contentInstance＞ 리소스는 상기 CSE 의 ＜container＞ 리소스의 자식 리소스로서 생성되어야 한다. 이는 S1404 에 따른 subscription 에 따라 상기 AE-C 에게 상기 S1406 의 수행 결과가 저장된(또는 포함된) 리소스가 생성되었음을 통지할 수 있도록 하기 위함이다.

상기 CSE 는 S1407 의 리소스 생성 요청에 따라 S1406 의 수행 결과를 포함한 ＜contentInstance＞ 리소스를 생성할 수 있다(S1408).

상기 CSE 는 S1404 에서 생성된 subscription 설정에 따라, S1408 에서 생성된 ＜contentInstance＞ 리소스의 정보를 상기 AE-C 에 전달할 수 있다(S1409).

상기 CSE 는 상기 전달에 대한 정상 응답을 수신한 후, S1404 에서 생성된 subscription 에서 설정된 'expirationTime' 속성 값이 1 로 설정되어 있기 때문에 해당 subscription 을 삭제할 수 있다(S1410).

한편, S1403 에서 'operationCheck' 속성이 TRUE 로 명시되지 않은 경우에 대해 설명하도록 한다.

상기 CSE 는 상기 AE-C 의 요청으로 생성된 ＜contentInstance＞로 인하여 통지 메시지를 상기 AE-T 에 전달할 수 있다(S1411). 이 동작은 앞서 설명한 본 실시예의 가정한 사항에 해당한다.

상기 AE-T 는 S1411 에서 수신된 통지 메시지를 기반으로 상기 장치를 제어할 수 있다(S1412).

도 15 는 도 14 의 절차를 좀더 상세하게 도시한다. 따라서, 앞서 도 14 의 실시예에서 가정한 사항이 그대로 유지된다.

AE-C(1510)은 AE-T(1530)의 장치 제어를 위한 메시지와 장치 제어의 보장을 요구하는 표시자(예컨대, TRUE 로 명시된 'operationCheck' 속성)를 포함한 ＜contentInstance＞ 리소스의 생성을 CSE(1520)에 요청하기 위한 요청 메시지를 전송할 수 있다(S1501). 상기 ＜contentInstance＞ 리소스는 상기 CSE 의 ＜container＞ 리소스의 자식 리소스로서 생성되어야 한다. 상기 요청 메시지는 요청 식별자(request Identifier; ri)를 포함할 수 있다.

상기 CSE 는 상기 AE-C 가 요청한 ＜contentInstance＞ 리소스를 생성할 수 있다(S1502).

상기 CSE 는 S1502 의 리소스 생성 요청 또는 그의 결과에 대한 응답 메시지를 상기 AE-C 로 전송할 수 있다(S1503). 이 때, 상기 AE-C 는 해당 생성의 성공 응답에 따라 상기 장치가 정상적으로 제어되었다고 판단하지 않는다.

상기 CSE 는 상기 생성된 ＜contentInstance＞ 리소스에 상기 장치 제어의 보장을 요구하는 표시자가 포함되어 있는지 여부를 판단할 수 있다(S1504). 예컨대, 상기 CSE 는 상기 생성된 ＜contentInstance＞ 리소스의 'operationCheck' 속성이 TRUE 로 명시되어 있는지를 판단할 수 있다. 상기 'operationCheck' 속성이 TRUE 로 명시되어 있으면 S1505 로 진행하고, 그렇지 않으면 S1515 로 진행한다.

상기 CSE 는 향후 장치 제어의 결과를 상기 AE-C 로 전달하기 위해 ＜contentInstance＞ 리소스의 부모인 ＜container＞ 리소스에 추가 ＜subscription＞ 리소스를 생성할 수 있다(S1505). 해당 ＜subscription＞ 리소스의 'notificationURI' 속성은 상기 AE-C 로 지정되고, 'expriationCounter' 속성은 1 로 지정된다.

이때, 상기 CSE 는 S1501 에서 수신된 요청 메시지의 요청 식별자와 그에 따라 생성된 ＜subscription＞ 리소스(예컨대, 'subscription Reference' 속성 값)를 맵핑하는 정보를 생성할 수 있다.

상기 AE-C 의 요청으로 생성된 ＜contentInstance＞ 리소스로 인하여 통지 메시지를 상기 AE-T 로 전달할 수 있다(S1506). 이 동작은 앞서 설명한 해당 subscription 이 사전에 등록된 본 실시예의 가정에 근거한다. 또한, S1506 은 S1503, S1504 또는 S1505 보다 먼저 또는 그와 동시에 수행될 수 있다.

상기 통지 메시지를 전송할 때, 상기 통지 메시지는 상기 통지 메시지의 기반 리소스인 상기 생성된 ＜contentInstance＞ 리소스의 'content' 속성 값(즉, 상기 장치 제어를 위한 메시지)을 포함하되, 상기 장치 제어의 보장을 요구하는 표시자인 TRUE 로 명시된 'operationCheck' 속성 값을 포함하도록 한다.

상기 AE-T 는 상기 통지 메시지에 대한 응답을 상기 CSE 로 전송할 수 있다(S1507).

상기 AE-T 는 S1505 에서 수신된 통지 메시지를 기반으로 상기 AE-T 의 장치를 제어할 수 있다(S1508). 이 단계에서, 실제적인 장치 제어가 이루어지는 것이다.

상기 AE-T 는 S1505 에서 수신된 통지 메시지에 명시된 장치 제어의 보장을 요구하는 표시자에 따라 S1508 의 수행 결과(즉, 상기 장치 제어의 결과)를 포함하는 신규 ＜contentInstance＞ 리소스의 생성을 상기 CSE 에 요청할 수 있다(S1509).

이러한 신규 ＜contentInstance＞ 리소스는 상기 CSE 의 ＜container＞ 리소스의 자식 리소스로서 생성되어야 한다. 이는 S1505 에 따른 subscription 에 따라 상기 AE-C 에게 상기 S1508 의 수행 결과가 저장된(또는 포함된) 리소스가 생성되었음을 통지할 수 있도록 하기 위함이다.

상기 CSE 는 S1509 의 리소스 생성의 요청에 따라 상기 S1508 의 결과를 포함한 ＜contentInstance＞ 리소스를 생성할 수 있다(S1510). 또한, 상기 CSE 는 상기 리소스 생성에 대한 응답을 상기 AE-T 로 전송할 수 있다(S1511).

상기 CSE 는 S1505 에서 생성된 ＜subscription＞ 리소스에 따라, S1509 에 대응하여 생성된 ＜contentInstance＞ 리소스의 정보를 상기 AE-C 로 통지 메시지를 전송할 수 있다(S1512). 상기 CSE 는 S1505 에서 생성된 상기 맵핑 정보를 통해, 상기 통지 메시지를 발생시킨 ＜subscription＞ 리소스가 상기 요청 식별자와 연관된다는 것을 파악하여, 상기 통지 메시지에 상기 요청 식별자를 포함시킬 수 있다. 그리하여, 상기 AE-C 는 상기 통지 메시지가 S1501 에서 자신이 전송한 요청 메시지와 관련된 메시지임을 판단할 수 있다.

상기 AE-C 는 S1511 에 대한 응답 메시지를 상기 CSE 로 전송할 수 있다(S1513).

상기 CSE 는 상기 응답 메시지를 수신한 후, S1504 에서 생성된 ＜subscription＞ 리소스에서 설정된 'expirationTime' 속성 값의 1 로 설정되어 있기 때문에 해당 ＜subscription＞ 리소스를 삭제할 수 있다(S1514).

한편, 상기 AE-C 는 S1512 의 통지 메시지의 내용과 S1501 의 요청 메시지의 내용이 동일한지 여부를 판단할 수 있다(S1515).

S1514 과 S1515 는 동시에, 또는 반대의 순서로 수행될 수 있다.

S1512 의 통지 메시지의 내용과 S1501 의 요청 메시지의 내용이 동일한 경우에는 S1519 를 수행하고, S1512 의 통지 메시지의 내용과 S1501 의 요청 메시지의 내용이 동일하지 않으면 S1520 을 수행한다.

S1512 의 통지 메시지의 내용과 S1501 의 요청 메시지의 내용이 동일하면, 상기 장치 제어의 결과를 반영할 수 있다(S1519). 좀더 상세하게는, 상기 AE-C 는 요청한 내용(즉, S1501 의 요청 메시지의 내용)이 정상적으로 반영되었음을 파악하고, 이에 따라 그와 관련된 AE-T 의 상태를 상기 요청 메시지의 내용대로 반영할 수 있다. 반영한다는 것은 상기 AE-C 가 외부 인터페이스로 전달되는 내용을 수정한다는 의미이다. 예를 들어, 상기 AE-T 가 조명 장치의 AE 이고, 해당 조명 장치를 켜는 것이 S1501 의 요청 메시지의 내용이었다면, S1512 의 통지 메시지를 통해 상기 조명 장치가 켜진 것을 파악하고, 조명이 켜진 상태를 표현하는 그래픽 객체를 외부로 전달하는 것이다. 도 13 의 예에선, AE-T 의 상태(1311)를 상기 장치 제어의 수행 결과대로 변경하는 것을 의미한다.

S1512 의 통지 메시지의 내용과 S1501 의 요청 메시지의 내용이 동일하지 않으면, 상기 AE-C 는 S1501 의 요청에 대한 처리에 오류가 있음을 파악하고, S1501 의 요청 메시지를 다시 전송할 수 있다. 즉, 다시 S1501 로 돌아갈 수 있다.

한편, S1501 의 요청 메시지에 포함된 'operationCheck' 속성 값이 TRUE 가 아닌 경우에 대해 설명한다.

상기 CSE 는 상기 AE-C 의 요청으로 생성된 ＜contentInstance＞ 리소스로 인해 통지 메시지를 상기 AE-T 에 전달할 수 있다(S1516). 이 동작은 앞서 설명한 해당 subscription 이 사전에 등록된 본 실시예의 가정에 근거한다.

상기 통지 메시지는 S1501 의 요청 메시지에 포함된 'content' 속성(즉, 장치 제어 메시지의 내용)을 포함하고, TRUE 로 명시된 'operationCheck' 속성을 포함할 수 있다. S1501 의 요청 메시지가 TRUE 로 명시되지 않은 'operationCheck' 속성을 포함함에도 상기 통지 메시지가 TRUE 로 명시된 'operationCheck' 속성을 포함하는 것은, 상기 장치 제어를 보장하기 위함이다.

상기 AE-T 는 S1516 에 대한 응답 메시지를 상기 CSE 로 전송할 수 있다(S1517). 그리고나서, 상기 AE-T 는 S1516 에서 수신된 통지 메시지를 기반으로 상기 AE-T 의 장치를 제어할 수 있다(S1518).

도 16 은 본 발명의 또다른 실시예로써 장치 제어를 위한 메시지의 중복을 회피하면서 상기 장치 제어를 보장하는 방안을 도시한다. 이는, 도 9 와 도 10 에서 설명한 동시다발적인 요청이 발생하는 경우의 해결 방안이 될 수 있다.

도 16 과 관련하여 설명할 실시예는 제어의 대상 장치(즉, 타깃 장치)(또는 해당 장치에 설치 또는 저장된 AE-T(1630))는 자신이 등록된 CSE(1620)에 ＜containter＞ 리소스를 생성하고 그에 대한 변경 정보를 획득하기 위해 ＜subscription＞ 리소스를 생성한 것을 가정한다. 추가적으로, 상기 타깃 장치(또는 그에 설치 또는 저장된 AE)는 최초에 CSE 에 등록할 때, 자신의 하드웨어에 따라 연속적인 요청을 지원하는지 여부를 알리도록 하며(S1601), 이는 ＜AE＞ 리소스의 속성 중 'consecutiveRequestSupport' 속성에 포함된다.

다음 표는 ＜AE＞ 리소스의 속성을 정의한다.

[표 5]

타깃 장치를 제어 하고자 하는 AE-C(1610)는 상기 타깃 장치를 제어하기 위한 메시지를 포함한 ＜contentInstance＞ 리소스를 생성하기 위한 요청 메시지를 상기 타깃 장치가 등록되어 있는 CSE(1620)(즉, 상기 타깃 장치의 AE 가 등록된 CSE)에 전송할 수 있다(S1602). 상기 요청 메시지는 상기 장치 제어를 위한 메시지( 'content' 속성 값)와 상기 장치 제어의 보장을 위한 표시자( 'operationCheck' 속성 값)를 포함할 수 있다.

추가적으로 상기 요청 메시지는 상기 장치 제어의 요청에 따른 요청 식별자(Request ID)를 포함할 수 있다.

상기 CSE 는 S1602 의 요청 메시지에 따라 ＜contentInstance＞ 리소스를 생성할 수 있다(S1603).

S1603 에서 상기 리소스의 생성을 정상적으로 완료한 CSE 는 상기 AE-C 에게 상기 요청 메시지의 처리를 정상적으로 완료했음을 지시하는 응답 메시지를 전송할 수 있다(S1604).

그리고나서, 상기 CSE 는 S1603 에서 생성된 ＜contentInstance＞ 리소스의 'operationCheck' 속성 값과 ＜AE-T＞ 리소스의 'consecutiveRequestSupport' 속성 값을 확인할 수 있다(S1605).

상기 'operationCheck' == TRUE 이고, 상기 'consecutiveRequestSupport' == FALSE 인 경우에는 다음과 같이 동작한다.

상기 CSE 는 상기 AE-C 가 향후 상기 장치 제어의 결과를 통지받을 수 있도록 ＜subscription＞ 리소스를 생성할 수 있다(S1606). 이때, 'notificationURI' 속성 값은 상기 AE-C 로 지정되고, 'expriationTime' 속성 값은 1 로 설정된다.

또한, 상기 CSE 는 상기 AE-T(1630)만 ＜container＞ 리소스에 접근이 가능하도록 상기 AE-T 의 접근 제어 정책(access control policy; ACP) 속성을 갱신할 수 있다(S1607). 이때, 상기 CSE 는 상기 AE-T 의 설정에 따라 selfPrivilege 권한을 가진 엔티티이다.

상기 CSE 는 이미 생성된 ＜subscription＞ 리소스에 따라 리소스 변경 이벤트(즉, S1603 의 ＜contentInstance＞ 리소스 생성)가 발생했으므로, 이에 대한 통지 메시지를 상기 AE-T 에 전송할 수 있다(S1608). 상기 통지 메시지는 상기 타깃 장치를 제어하기 위한 메시지 및/또는 S1602 의 요청 메시지의 요청 식별자를 포함하고, TRUE 로 지정된 'operationCheck' 속성 값을 포함하도록 한다.

상기 AE-T 는 상기 통지 메시지에 대한 응답 메시지를 상기 CSE 로 전송할 수 있다(S1609). 그리고, 상기 AE-T 는 상기 통지 메시지의 요청에 따라 장치를 제어할 수 있다(S1610).

S1607 의 통지 메시지에 TRUE 로 설정된 'operationCheck' 속성을 포함하기 때문에, 상기 AE-T 는 장치 제어의 결과를 상기 CSE 에 보고해야 한다. 즉, 상기 AE-T 는 상기 장치 제어의 결과를 보고하기 위해 상기 CSE 의 ＜contentInstance＞ 리소스를 생성하기 위한 요청 메시지를 전송하며(S1611), 상기 요청 메시지의 'ri' 파라미터는 S1608 에서 수신된 요청 식별자로 설정되고 'content' 파라미터는 장치 제어의 결과(성공 또는 실패, 상세하게는 S1602 의 요청 메시지의 내용이 그대로 표시 되어 있으면 성공, 그와 반대 또는 다른 결과를 작성하면 서비스 공급자의 정책에 따라 상기 AE-C 가 이를 인식할 수 있다)를 포함하되, 'operationCheck' 속성은 상기 장치 제어가 종료되었다는 표시로 DONE 으로 표기될 수 있다.

이에, 상기 CSE 는 ＜contentInstance＞ 리소스를 생성할 수 잇다(S1612)

상기 CSE 는 상기 요청 메시지에 대한 응답 메시지를 상기 AE-T 에게 전송할 수 있다(S1613).

상기 CSE 는 S1611 의 요청 메시지의 'operationCheck' 속성 값이 DONE 으로 표기되어 있기 때문에, 상기 장치 제어가 종료된 것을 파악하고, 'accessControlPolicy' 속성을 기존 속성 값으로 되돌릴 수 있다(roll-back)(즉, S1607 이전의 상태로 되돌림)(S1614). 이러한 동작을 통해서 리소스 접근이 가능한 타 AE 가 상기 AE-T 를 제어할 수 있도록 한다.

상기 CSE 는 S1611 의 요청 메시지에 따라 신규 리소스가 생성되었으므로, S1606 의 subscription 으로 인한 통지 발생 조건을 만족하므로, 이에 대한 통지 메시지를 상기 AE-C 로 전송할 수 있다(S1615). 상기 통지 메시지는 상기 요청 메시지와 DONE 으로 표기된 'operationCheck' 속성을 포함한다.

'operationCheck' 이 DONE 인 것으로 확인될 것이므로, 상기 AE-C 는 상기 AE-T 가 상기 장치 제어에 대한 물리적 동작이 완료(성공/실패)되었음을 확인하고, 이를 기반으로 장치 제어 결과를 반영할 수 있다 (S1616). 즉, 예를 들어 상기 AE-C 는 UI 를 제어할 수 있다.

상기 AE-C 는 S1615 의 통지 메시지에 대한 응답 메시지를 상기 CSE 로 전송할 수 있다(S1617).

상기 CSE 는 S1615 의 통지 메시지를 상기 AE-C 가 정상적으로 수신하였음을 파악하고, 일회성 제어를 위한 S1606 에서 생성한 ＜subscription＞ 리소스를 삭제할 수 있다(S1618).

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

메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 임시 저장할 수 있다. 메모리(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) 또는 수신장치(20)로 동작할 수 있다.

이와 같은, 수신장치 또는 전송장치로 애플리케이션 (엔티티) 또는 리소스 관린 엔티티 등의 구체적인 구성은, 도면과 관련하여 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 둘 이상의 실시예가 동시에 적용되도록 구현될 수 있다.

상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.

본 발명은 무선 이동 통신 시스템의 단말기, 기지국, 서버 또는 기타 다른 장비에 사용될 수 있다.

Claims

무선 통신 시스템에서 제어 동작의 처리를 보장하기 위한 방법으로서, 상기 방법은 제 1 M2M(machine to machine)/IoT(Internet of Things) 장치에 의해 수행되며,
제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스 생성 요청을 제 3 M2M/IoT 장치에 전송하는 단계, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고;
상기 리소스 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로부터 수신하는 단계;
상기 지시자에 따른 상기 제어 동작의 처리 결과를 포함하는 제어 결과 통지를 상기 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 제어 결과 통지는 상기 리소스 생성 요청의 식별자를 포함하고; 그리고
상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하는지 여부를 확인하는 단계를 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 1 항에 있어서, 상기 지시자는 상기 제어 동작의 처리 보장을 위해 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스의 생성을 트리거하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 1 항에 있어서, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하면, 상기 제어 결과 통지의 내용을 상기 제 1 M2M/IoT 장치의 상태에 반영하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 1 항에 있어서, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하지 않으면, 상기 리소스 생성 요청을 상기 제 3 M2M/IoT 장치로 재전송하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
무선 통신 시스템에서 제어 동작의 처리를 보장하기 위한 방법으로서, 상기 방법은 제 1 M2M(machine to machine)/IoT(Internet of Things) 장치에 의해 수행되며,
제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스(이하, "전달 리소스" 로 지칭함)의 생성 요청을 제 3 M2M/IoT 장치로부터 수신하는 단계, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고;
상기 리소스 생성 요청에 따라 상기 전달 리소스를 생성하는 단계;
상기 전달 리소스의 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로 전송하는 단계;
상기 생성된 전달 리소스에 상기 지시자가 존재하는지 여부를 판단하는 단계;
상기 생성된 전달 리소스에 상기 지시자가 존재하면, 상기 제어 동작의 처리 보장을 위한 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스를 생성하는 단계;
상기 제 2 M2M/IoT 장치로부터 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청이 수신되면, 상기 제어 동작의 처리 결과를 포함하는 리소스를 생성하는 단계; 및
상기 생성된 구독 리소스에 따라 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지를 상기 제 3 M2M/IoT 장치로 전송하는 단계를 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 5 항에 있어서,
사전에 생성된 구독(subscription) 리소스에 따라 상기 제어 메시지의 내용 또는 상기 지시자를 포함하는 제어 동작을 지시하기 위한 통지 메시지를 상기 제 2 M2M/IoT 장치로 전송하는 단계; 및
상기 통지 메시지에 따른 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 상기 제 2 M2M/IoT 장치로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 5 항에 있어서,
상기 지시자는 상기 제 2 M2M/IoT 장치에게 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 추가로 지시하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 5 항에 있어서, 상기 구독 리소스를 생성하는 단계는:
상기 리소스 생성 요청의 식별자와 상기 구독 리소스를 맵핑하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 5 항에 있어서, 상기 구독 리소스를 생성하는 단계는:
상기 제어 동작과 관련된 리소스의 변경의 통지를 1 회로 제한하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
제 5 항에 있어서,
상기 제어 동작의 처리 결과를 포함한 제어 결과 통지의 전송에 대한 응답을 상기 제 3 M2M/IoT 장치로부터 수신하면, 상기 생성된 구독 리소스를 삭제하는 단계를 더 포함하는 것을 특징으로 하는, 제어 동작 처리 보장 방법.
무선 통신 시스템에서 제어 동작의 처리를 보장하도록 구성된 M2M(machine to machine)/IoT(Internet of Things) 장치로서, 상기 M2M/IoT 장치는:
무선 주파수(Radio Frequency; RF) 유닛; 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하고,
상기 프로세서는 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스 생성 요청을 제 3 M2M/IoT 장치에 전송하고, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고;
상기 리소스 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로부터 수신하고;
상기 지시자에 따른 상기 제어 동작의 처리 결과를 포함하는 제어 결과 통지를 상기 제 3 M2M/IoT 장치로부터 수신하고, 상기 제어 결과 통지는 상기 리소스 생성 요청의 식별자를 포함하고; 그리고
상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하는지 여부를 확인하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 11 항에 있어서, 상기 지시자는 상기 제어 동작의 처리 보장을 위해 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스의 생성을 트리거하는 것을 특징으로 하는, M2M/IoT 장치.
제 11 항에 있어서, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하면, 상기 프로세서는 상기 제어 결과 통지의 내용을 상기 제 1 M2M/IoT 장치의 상태에 반영하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 11 항에 있어서, 상기 제어 메시지의 내용과 상기 제어 결과 통지의 내용이 일치하지 않으면, 상기 프로세서는 상기 리소스 생성 요청을 상기 제 3 M2M/IoT 장치로 재전송하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
무선 통신 시스템에서 제어 동작의 처리를 보장하도록 구성된 M2M(machine to machine)/IoT(Internet of Things) 장치로서, 상기 M2M/IoT 장치는:
무선 주파수(Radio Frequency; RF) 유닛; 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하고,
상기 프로세서는 제 2 M2M/IoT 장치의 제어 동작을 지시하기 위한 제어 메시지를 전달하기 위한 리소스(이하, "전달 리소스" 로 지칭함)의 생성 요청을 제 3 M2M/IoT 장치로부터 수신하고, 상기 리소스 생성 요청은 상기 제어 메시지의 내용, 상기 제어 동작의 처리 보장을 요구하는 지시자 또는 상기 리소스 생성 요청의 식별자를 포함하고;
상기 리소스 생성 요청에 따라 상기 전달 리소스를 생성하고;
상기 전달 리소스의 생성 요청에 대한 리소스 생성 응답을 상기 제 3 M2M/IoT 장치로 전송하고;
상기 생성된 전달 리소스에 상기 지시자가 존재하는지 여부를 판단하며; 상기 생성된 전달 리소스에 상기 지시자가 존재하면, 상기 제어 동작의 처리 보장을 위한 상기 제어 동작과 관련된 리소스의 변경의 통지를 가능하게 하는 구독(subscription) 리소스를 생성하고;
상기 제 2 M2M/IoT 장치로부터 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청이 수신되면, 상기 제어 동작의 처리 결과를 포함하는 리소스를 생성하며; 그리고
상기 생성된 구독 리소스에 따라 상기 제어 동작의 처리 결과를 포함한 제어 결과 통지를 상기 제 3 M2M/IoT 장치로 전송하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 15 항에 있어서, 상기 프로세서는:
사전에 생성된 구독(subscription) 리소스에 따라 상기 제어 메시지의 내용 또는 상기 지시자를 포함하는 제어 동작을 지시하기 위한 통지 메시지를 상기 제 2 M2M/IoT 장치로 전송하고; 그리고
상기 통지 메시지에 따른 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 상기 제 2 M2M/IoT 장치로부터 수신하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 15 항에 있어서,
상기 지시자는 상기 제 2 M2M/IoT 장치에게 상기 제어 동작의 처리 결과를 포함하는 리소스의 생성 요청을 추가로 지시하는 것을 특징으로 하는, M2M/IoT 장치.
제 15 항에 있어서, 상기 프로세서는 상기 구독 리소스를 생성함에 있어서 상기 리소스 생성 요청의 식별자와 상기 구독 리소스를 맵핑하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 15 항에 있어서, 상기 프로세서는 상기 구독 리소스를 생성함에 있어서 상기 제어 동작과 관련된 리소스의 변경의 통지를 1 회로 제한하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.
제 15 항에 있어서,
상기 제어 동작의 처리 결과를 포함한 제어 결과 통지의 전송에 대한 응답을 상기 제 3 M2M/IoT 장치로부터 수신하면, 상기 프로세서는 상기 생성된 구독 리소스를 삭제하도록 구성되는 것을 특징으로 하는, M2M/IoT 장치.