KR20190000817A - M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 - Google Patents

Abstract

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, 발신자가 보낸 요청 메시지를 수신자가 처리하기 위한 방법 및 그 장치에 관한 것이다. 일 실시예는 M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법 및 장치를 제공한다.

Description

M2M 시스템에서 메시지를 처리하는 방법 및 그 장치{Methods for processing a message in M2M system and Apparatuses thereof}

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, 발신자가 보낸 요청 메시지를 수신자가 처리하기 위한 방법 및 그 장치에 관한 것이다.

사물 통신(M2M, "Machine to machine communication" 또는 MTC, "Machine type communication" 또는 스마트 디바이스 통신, "Smart Device communication" 또는 "Machine oriented communication" 또는 사물 인터넷, "Internet of Things")은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다.

사물통신은 통상적으로 사람이 직접적으로 통신과 응용 제어를 수행하지 않기 때문에, 사물 간에 메시지를 교환하기 위해서 송수신 방법과 절차와 필요하다. 또한, M2M 장치 간의 원활한 메시지 교환을 위한 프로토콜이 필요하다.

특히, IoT 기기의 대중화에 따라서 다수의 사물 통신 장치가 가정 및 직장 내에서 사용되고 있으며, 동일 또는 유사한 기능을 수행하는 사물 통신 장치가 일정 목적을 위해서 다수 전개되는 상황이 존재한다.

이러한 상황에서 다수의 사물 통신 장치는 서로 다른 프로토콜을 사용하여 데이터를 저장, 관리 및 처리할 수 있다. 예를 들어, 각 사물통신 장치는 서로 다른 미디어 유형 또는 인코딩 유형 등을 사용하여 데이터를 관리하고 송수신할 수 있다. 따라서, 서로 다른 인코딩 유형 등을 사용하는 사물통신 장치 간에는 원활한 정보 교환이 어려울 수 있다.

즉, 서로 다른 데이터 처리 유형을 가지는 M2M 장치 간에 원활한 정보 교환을 위해서 데이터 처리 유형에 대한 정보 처리가 요구된다. 또한, 보다 빠르게 메시지에서 정보를 추출하기 위한 구체적인 기술이 요구되고 있는 실정이다.

전술한 배경에서 안출된 일 실시예는 M2M 장치가 다른 M2M 장치로부터 요청 메시지를 수신한 경우, 해당 요청 메시지에 따라 처리된 자원에 대한 데이터 유형 정보를 별도로 관리하여 정보 교환의 효율성을 높이기 위한 구체적인 방법 및 장치를 제안하고자 한다.

전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법을 제공한다.

또한, 일 실시예는 메시지를 처리하는 M2M(Machine to Machine communication) 장치에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부를 포함하는 M2M 장치를 제공한다.

본 개시는 서로 다른 M2M 장치 간에 송수신 되는 메시지를 통해서 보다 빠르고 효율적으로 데이터를 추출할 수 있는 효과를 제공한다.

또한, 본 개시는 데이터 처리 유형의 모호성에서 발생하는 M2M 시스템 전체의 오류 발생을 방지하는 효과를 제공한다.

도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 일 실시예에 따른 공통 서비스 개체의 기능적 구조를 도시한 도면이다.
도 5는 일 실시예에 따른 <timeSeriesInstance> 자원 생성을 위한 요청 메시지를 처리하는 절차를 설명하기 위한 도면이다.
도 6은 일 실시예에 따른 요청 메시지의 동작 파라미터에 따른 메시지 코드와 응답 메시지 코드를 예시적으로 도시한 도면이다.
도 7은 데이터 처리 방식에 따라서 다양하게 표현되는 컨텐츠 처리 방법을 설명하기 위한 도면이다.
도 8은 종래 요청 메시지에 따라 대상 자원을 처리하는 동작을 설명하기 위한 도면이다.
도 9는 일 실시예에 따른 대상 자원에 대한 조회를 요청하는 요청 메시지에 대한 처리 동작을 설명하기 위한 도면이다.
도 10은 일 실시예에 따른 <timeSeriesInstance> 자원 조회를 위한 요청 메시지의 코드를 예시적으로 도시한 도면이다.
도 11은 일 실시예에 따른 도 10의 요청 메시지에 대한 응답 메시지의 코드를 예시적으로 도시한 도면이다.
도 12는 종래 도 11의 응답 메시지를 통해서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 13은 일 실시예에 따른 M2M 장치의 동작을 설명하기 위한 도면이다.
도 14는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 자원의 구조를 예시적으로 도시한 도면이다.
도 15는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 인스탄스 자원의 구조를 예시적으로 도시한 도면이다.
도 16은 일 실시예에 따른 시계열 인스탄스 자원에 대한 조회 요청 메시지에 따른 응답 메시지에서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 17은 일 실시예에 따른 M2M 장치의 구조를 도시한 도면이다.

이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조 부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.

또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.

본 발명의 실시예들은 사물 통신을 중심으로 설명한다. 사물 통신은 M2M(Machine to Machine communication), MTC(Machine Type Communication), IoT(Internet of Things), 스마트 장치 통신(Smart Device Communication, SDC), 또는 사물 지향 통신(Machine Oriented Communication) 등으로 다양하게 불려질 수 있다. 최근 oneM2M에서 사물통신과 관련된 많은 기술적 사항을 제시하고 있다. 사물 통신은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 다양한 통신을 지칭한다. 사물 통신은 에너지(energy) 분야, 엔터프라이즈(enterprise) 분야, 헬스케어(Healthcare) 분야, 공공 서비스(Public Services) 분야, 주거(Residential) 분야, 소매(Retail) 분야, 운송(Transportation)분야, 그리고 기타 분야 등으로 나뉘어진다. 본 발명은 상기 분야를 포함하며, 그 외의 분야에도 적용 가능하다.

도 1은 일 실시예에 따른 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.

애플리케이션 개체(Application Entity, AE)(110)는 종단간(end-to-end) M2M 솔루션을 위한 응용 서비스 로직을 제공한다. 일 예로 차량 등의 집단적인 추적 애플리케이션(fleet tracking application), 원격 혈당 감시 애플리케이션(remote blood sugar monitoring application), 또는 원격 전력 검침과 제어 애플리케이션(remote power metering and controlling application) 등이 될 수 있다.

공통 서비스 개체(Common Services Entity, CSE)(120)는 에너지(energy) 분야, 엔터프라이즈(enterprise) 분야, 헬스케어(Healthcare) 분야, 공공 서비스(Public Services) 분야, 주거(Residential) 분야, 소매(Retail) 분야, 운송(Transportation)분야, 그리고 기타 분야 등에서 공통적으로 필요한 집합적인 서비스 기능이다.

이러한 서비스 기능은 참조점(Reference Points) Mca, Mcc를 통해 다른 기능으로 드러나며, 참조점 Mcn를 이용하여 기반 네트워크 서비스를 이용한다. 공통 서비스 개체의 일 예로는 데이터 관리(Data Management), 디바이스 관리(Device Management), M2M 구독 관리(M2M Subscription Management), 위치 서비스(Location Service) 등이 될 수 있다. CSE에 의해 제공되는 서브기능(subfunction)은 논리적으로 CSF(Common service function)으로 이해될 수 있다. oneM2M 노드의 CSE내에 CSF 중 일부는 필수적(mandatory)이 되며 일부는 선택적(optional)이 될 수 있다. 마찬가지로 CSF 내의 서브기능들 역시 필수적 또는 선택적이 될 수 있다.

기반 네트워크 서비스 기능(Underlying Network Services Function, NSF)(130)은 공통 서비스 개체에게 서비스를 제공한다. 서비스의 예로는 디바이스 관리, 위치 서비스(location services)와 디바이스 트리거링(device triggering)을 포함한다.

참조점(Reference Points)은 공통 서비스 개체(CSE)에서 지원되는 것으로 Mca 참조점은 애플리케이션 개체와 공통 서비스 개체 간의 사물통신을 제공하기 위한 참조점이다. Mcc 참조점은 두 공통 서비스 개체 간의 통신 사물통신을 제공하기 위한 참조점이다. Mcn 참조점은 공통 서비스 개체와 하나의 네트워크 서비스 개체간의 사물통신을 제공하기 위한 참조점이다.

보다 상세히, Mca 참조점은 하나의 애플리케이션 개체(AE)가 공통 서비스 개체에 의해 지원되는 서비스를 사용할 수 있도록 한다. Mca 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이며, 애플리케이션 개체와 공통 서비스 개체는 동일한 물리적 개체에 존재하거나 다른 물리적 개체에 따로 존재할 수 있다. Mcc 참조점은 필요한 기능을 제공하는 다른 공통 서비스 개체의 서비스를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 한다. Mcc 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이다. Mcc 참조점은 서로 다른 M2M 노드 간에 지원될 수 있다. Mcn 참조점은 필요한 기능을 제공하는 기반 네트워크의 서비스 개체를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 하며, 이는 전송과 연결 이외의 서비스를 제공한다. Mcn 참조점의 인스턴스(instance)는 기반 네트워크에서 제공되는 서비스에 의존적으로 구현된다. 두 개의 물리적 M2M 노드 간의 정보 교환은 기본 서비스를 제공하는 기반 네트워크의 전송(transport) 및 연결(connectivity) 서비스를 사용할 수 있다.

본 명세서에서는 공통 서비스 개체를 CSE로 기재할 수 있으며, 네트워크 서비스 개체를 NSE (Network Service Entity)로 기재할 수 있다. 또한, 본 명세서에서의 M2M 장치는 CSE 또는 AE를 의미하거나, CSE 또는 AE를 포함하는 장치를 의미하며, M2M 시스템을 구성하는 디바이스 또는 단말을 의미한다.

도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.

도 2를 참조하면, 기반노드(Infrastructure Node, 250)는 M2M 통신을 제공하는데 필수적인 서버 기능을 수행한다. 기반노드(250)는 기반노드 응용개체(AE, 252)와 기반노드 공통서비스개체(CSE, 254)로 구성된다. 기반노드 공통서비스 개체(254)는 다양한 자원을 이용하여 구성된다. 252와 254는 Mca 참조점을 통하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.

중계노드(200)는 응용서비스노드(220)와 기반노드(250)의 M2M 통신 또는 Internet of Things, 사물통신 기능을 중계한다. 중계노드(200)는 중계노드 응용개체(202)와 중계노드 공통서비스개체(204)로 구성된다. 중계노드 공통서비스개체 (204)는 다양한 자원을 이용하여 구성된다. 202와 204는 Mca 참조점을 통하여 구분하며, 254와 204는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회(retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.

응용서비스노드(210)는 응용개체(212)와 중계노드 공통서비스개체(214)로 구성할 수 있다. 응용개체(212)는 기기의 목적상 요구되는 응용 기능을 처리한다. 응용서비스노드(210)의 공통서비스개체(214)는 다양한 자원을 이용하여 구성한다. 212와 214는 Mca 참조점을 통하여 구분하며, 214와 254는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성(create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답 메시지의 구성과 처리에 사용한다. 한편, 응용서비스노드(220)는 중계노드(200)를 통하여 기반노드(250)와 사물통신 기능을 수행할 수도 있다. 210과 220의 차이점은 노드를 구성하는 통신 인터페이스가 다른 것이 특징이다. 예를 들어, 220은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다. 이에 반해, 210은 3G, LTE, 5G, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 250과 통신한다.

응용전용노드(230, 240)는 공통서비스개체를 가지지 않고, 응용개체(242)만을 가지고 사물통신을 하는 경우를 대상으로 한다. 230은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 250과 통신하는 경우이고, 240은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 250과 통신한다.

도 2에서 설명한 바와 같이, M2M 시스템은 기반노드, 중계노드, 응용 서비스 노드 및 응용전용 노드 중 적어도 하나 이상의 노드로 구성될 수 있으며, 각 노드는 CSE 또는 AE를 포함하여 구성될 수 있다. CSE와 AE는 각각의 참조점을 통해서 타 CSE 또는 AE와 통신을 수행할 수 있다.

도 3을 참조하면, 발신자(Originator, 300)는 요청 메시지를 수신자(Receiver, 310)로 전송한다(S320). 발신자(300)와 수신자(310)는 각각 M2M 장치일 수 있으며, 전술한 바와 같이 CSE 또는 AE일 수 있다. 또한, 발신자(300)와 수신자(310)는 CSE 또는 AE를 포함하는 노드 또는 서버 또는 장치일 수 있다.

요청 메시지는 하나 이상의 파라미터를 포함할 수 있다. 예를 들어, 요청 메시지에는 필수적인 파라미터와 선택적인 파라미터가 포함될 수 있다. 예를 들어, 송신 (From) 측 파라미터, 수신측 (To) 파라미터, 요청 식별 정보 (Request Identifier) 파라미터 및 동작 (Operation) 파라미터는 필수적인 파라미터로 포함된다. From 파라미터는 메시지를 전송하는 발원자에 대한 정보를 포함하고, To 파라미터는 메시지를 수신하는 수신자에 대한 정보를 포함한다. Request Identifier 파라미터는 해당 요청 메시지를 식별하기 위한 유일한 식별 정보를 포함한다. 또한, Operation 파라미터는 요청 메시지에서 요청하는 동작을 구분하기 위한 정보를 포함한다. 동작 파라미터는 생성(Create), 조회(Retrieve), 갱신(Update), 삭제(Delete), 통지(Notify) 중 어느 하나로 설정될 수 있다. 또한, 요청 메시지의 다양한 동작을 제어하기 위하여 선택적인 파라미터를 부가할 수 있다. 예를 들어 응답 유형 (Response Type)의 선택적인 파라미터는 수신자의 처리 방식을 블록킹 (blockingRequest) 방식, 동기화된 넌블록킹 (nonBlockingRequestSynch) 방식, 비동기화된 넌블록킹 (nonBlockingRequestAsynch) 방식, 수신자 맞춤형 (flexBlocking) 방식으로 지정할 수 있다.

수신자(310)는 요청 메시지가 수신되면, 해당 요청 메시지를 처리하기 위한 동작을 수행한다(S330). 예를 들어, 수신자(310)는 요청메시지(Request Message)를 송신한 발신자(300)가 해당 요청에 대한 권한을 가지고 있는지를 확인할 수 있다. 발신자(300)가 요청에 대한 권한을 가지고 있다고 판단되는 경우, 요청의 대상이 되는 리소스(requested resource)의 존재 여부를 확인한 후 요청 메시지를 처리한다. 또는, 수신자(310)는 요청 메시지의 동작 파라미터에 따라 해당하는 동작을 수행할 수 있다. 예를 들어, 동작 파라미터가 생성으로 설정되고, 특정 데이터의 변경, 추가, 삭제 등이 발생할 경우에 이를 발신자(300)측으로 알려주도록 지시하는 구독 기능이 설정되는 경우에 수신자(310)는 구독 정보를 생성하고, 해당 구독 정보에 해당하는 데이터에 변경, 추가, 삭제 등의 이벤트가 발생하는 경우에 이를 발신자(300) 측으로 통지할 수 있다.

수신자(310)는 요청 동작에 따른 처리 결과 정보를 생성하여 이를 응답메시지에 포함하여 발신자(300)로 전송한다(S340). S340 단계는 S330 단계 이전에 수행될 수도 있다. 즉, 수신자(310)는 요청 메시지를 수신하면, 이에 대한 단순 수신을 나타내는 ACK 응답 메시지를 생성하여 발신자(300)측으로 전송하고, 이후 S330 단계를 수행하여 요청 메시지를 처리할 수도 있다.

도 4는 본 발명의 일 실시예에 의한 공통 서비스 개체를 구성하는 도면이다. 도 4에서는 식별 정보의 처리 기능을 포함한다.

공통 서비스 개체가 제공하는 기능을 도 4와 같이 정리하면 식별(Addressing & Identification), 어플리케이션/서비스 계층 관리(Application and Service Layer Management), 데이터 관리 및 저장(Data Management & Repository), 위치(Location), 보안(Security), 통신 관리/전달 핸들링(Communication Management / Delivery Handling), 등록(Registration), 서비스 세션 관리(Service Session Management), 디바이스 관리(Device Management), 구독/알림(Subscription/Notification), 연결 관리(Connectivity Management), 디스커버리(Discovery), 서비스 과금/정산(Service Charging/Accounting), 네트워크 서비스 표출/서비스 실행 및 트리거링(Network Service Exposure / Service execution and triggering ), 그룹 관리(Group Management) 등이 있다.

물론, 상기 기능 이외에도 시맨틱스(Semantics), 데이터 분석(Data Analytics), 어플리케이션 인에이블먼트(Application Enablement), 네트워크 서비스 기능 관리(Network Service Function Management)등도 포함할 수 있다.

각각의 기능에 대해 살펴보면 다음과 같다.

ASM(Application and Service Layer Management)는 ADN, ASN, MN, IN의 AE와 CSE를 관리하는 것을 담당하며, 이는 CSE의 설정(configure), 트러블슈팅(troubleshoot), 업그레이드 기능과 AE의 업그레이드를 포함한다.

CMDH(Communication Management and Delivery Handling)는 다른 CSE, AE, NSE간의 통신을 책임진다. CMDH는 어느 시각에 어떤 통신 연결을 이용하여 통신을 전달할 것인지(CSE-CSE간 통신), 언제 필요하고 언제 허가되는지, 그리고 통신의 전달이 이후로 미루어질 때 통신 요청을 저장하는 것을 책임진다. CMDH는 통신에 대한 각 요청에 특화된 프로비전된 정책과 전달 핸들링 파라미터에 따라 수행된다. 기반 네트워크 데이터 전송 서비스를 이용한 통신에서 기반 네트워크는 동일한 전달 핸들링 기능을 지원할 수 있다. 이 경우 CMDH는 기반 네트워크를 사용할 수 있으며, 기반 네트워크에 동일한 전달 핸들링 기능을 액세스하는 프런트엔드로 동작할 수 있다.

DMR(Data Management and Repository)은 M2M 어플리케이션이 다른 개체와 데이터를 교환할 수 있도록 한다. DMR CSF는 데이터 저장 공간을 제공하고 이를 조정하는 기능을 제공한다. 또한 대량의 데이터를 수집하고 결합하거나, 데이터를 특정한 포맷으로 변환하거나, 또는 데이터를 분석 및 시맨틱 프로세싱을 위해 저장하는 기능을 포함한다. "데이터"라는 것은 M2M 디바이스로부터 투명하게 추출되는 로우 데이터(raw data)를 의미하거나 M2M 개체에 의해 계산 또는 결합되어 프로세싱된 데이터를 의미할 수 있다. 대량의 데이터를 수집하는 것은 빅데이터 저장 기능으로 알려진 것을 구성한다.

DMG(Device Management) CSF는 MN과 디바이스 노드 및 M2M 에어리어 네트워크에 있는 디바이스들의 디바이스 기능의 관리를 담당한다. 다음의 기능을 하나 이상 제공하는 디바이스 관리를 가능하게 한다. 어플리케이션 소프트웨어의 설치 및 세팅, 설정 세팅 및 프로비저닝, 펌웨어 업데이트, 로깅과 모니터링과 분석, 에어리어 네트워크의 토폴로지 관리, 그리고 에어리어 네트워크 관리 내의 디바이스를 포함한다.

DIS(디스커버리) CSF는 주어진 범위와 주제 내에서 허락된 권한(M2M 서비스 구독에서 허락된 것을 포함)과 주어진 범위 내에서 오리지네이터(Originator)로부터의 요청에 해당하는 정보와 리소스를 검색하는 것을 책임진다. 오리지네이터는 어플리케이션 또는 다른 CSE가 될 수 있다. 검색의 범위는 하나의 CSE가 되거나 다수의 CSE가 될 수 있다. 디스커버리 결과는 오리지네이터에게 리턴된다.

GMG(Group Management)는 요청과 관련된 그룹을 핸들링한다. 요청은 그룹과 그룹의 멤버십의 관리를 위해 전송되며 또한 그룹에 의해 지원되는 벌크 오퍼레이션도 담당한다. 그룹에 멤버를 추가 또는 삭제할 경우, 멤버가 그룹의 목적에 순응하는지를 확인할 필요가 있다. 벌크 오퍼레이션은 읽기, 쓰기, 구독하기, 알리기, 디바이스 관리 등을 포함한다. 요청 또는 구독은 그룹을 통하여 이루어지고, 그룹이 이러한 요청과 알림을 결합하는 것을 책임진다. 그룹의 멤버는 리소스에 대한 접근 권한에 대해 동일한 역할을 가진다. 이 경우, 접근 제어는 그룹에 의해 이루어진다. 기반 네트워크가 브로드캐스팅과 멀티캐스팅 기능을 제공할 경우, GMG CSF는 이러한 기능을 이용해야 한다.

LOC(Location) CSF는 위치 기반 서비스를 위해 M2M 노드(예를 들어 ASN, MN)의 지리적 위치 정보를 M2M AE가 습득할 수 있도록 한다. 동일한 또는 상이한 M2M 노드 내에 존재하는 M2M AE로부터 이러한 위치 정보가 요청될 수 있다.

NSE(Network Service Exposure) CSF는 M2M 어플리케이션을 대신하여 M2M 시스템으로부터의 서비스 요청에 대한 사용 가능하거나 지원 가능한 방식을 Mcn 참조점을 통하여 네트워크 서비스 기능을 액세스 하기 위해 기반 네트워크와의 통신을 관리한다. NSE CSF는 다른 CSF와 AF를 기반 네트워크에서 지원되는 특정한 기술과 메커니즘으로부터 은폐한다. 기반 네트워크로부터 제공되는 네트워크 서비스 기능은 디바이스 트리거링, 스몰 데이터 전송, 위치 알림, 폴리시 룰 셋팅, 위치 질의, IMS 서비스, 디바이스 관리 등을 포함하지만 이에 한정되지는 않는다. 이러한 기능들은 일반적인 전송 서비스를 포함하지 않는다.

REG(Registration)는 어플리케이션 또는 다른 CSE가 CSE에 등록하도록 핸들링하는 것을 담당하는데, 이는 CSE에서 제공되는 서비스를 사용하려는 개체의 등록을 허락하기 위함이다. REG CSF는 CSE에 대한 디바이스의 등록 뿐만 아니라 디바이스의 특성/속성의 등록도 핸들링한다.

SEC(Security)는 주의를 요하는(센서티브) 데이터 핸들링 기능, 보안 운영 기능, 보안 결합 설정 기능, 권한 부여와 액세스 제어 기능, 식별 보호 기능을 제공한다. SEC CSF가 제공하는 센서티브 데이터 핸들링 기능은 저장과 조작 과정에서 보안이 필요한 로컬 크리덴셜을 보호하는 기능을 제공한다. 센서티브 데이터 핸들링 기능 역시 보안 알고리즘을 사용한다. 이 기능은 다양한 암호기법이 분리된 보안 환경을 지원한다. 보안 운영 기능은 다음의 기능을 제공하는데, 먼저 센서티브 데이터 핸들링 기능에 의해 지원되도록 전용된 보안 환경의 생성과 운영 기능을 제공한다. 또한 보안 환경에서 보호되는 루트 크리덴셜의 포스트 프로비저닝을 지원하며, M2M 서비스와 M2M 어플리케이션 서비스와 관련된 구독의 프로비저닝과 운영을 지원한다. 보안 결합 설정 기능은 M2M 노드들 간의 보안 결합을 설정하여 기밀성, 통합성, 인증, 권한 부여가 가능하도록 한다. 권한 부여와 액세스 제어 기능은 프로비전된 보안 정책과 할당된 롤에 따라 권한 부여된 개체로의 서비스와 데이터 접근을 제어한다. 개체의 유일한 식별자가 권한 부여에 사용되며, 식별 보호 기능은 개체 또는 사용자와 결합된 실제 식별 정보와 링크되지 않도록 임시의 식별자로 기능하는 익명을 제공할 수 있다.

SCA(Service Charging and Accounting)는 서비스 계층의 과금 기능을 제공한다. 온라인 과금과 오프라인 과금을 포함하는 상이한 과금 모델들을 지원한다. SCA CSF는 과금 가능한 이벤트를 확보하고, 정보를 저장하며, 과금 기록과 과금 정보를 생성한다. SCA CSF는 기반 네트워크의 과금 시스템과 상호작용 할 수 있다. 그러나 SCA CSF는 최종 서비스 레벨의 과금 정보를 생성하고 기록할 책임을 가진다. 기반 노드 또는 서비스 계층 과금 서버의 SCA CSF는 과금을 위한 과금 정보를 핸들링하는 것을 책임진다.

SSM(Service Session Management) CSF는 단대단 서비스 계층 연결인 M2M 서비스 세션을 관리한다. SSM CSF는 M2M 어플리케이션들 간의, 또는 M2M 어플리케이션과 CSE 간의, 또는 CSE들 간의 M2M 서비스 세션을 관리한다. M2M 서비스 세션의 관리는 세션 상태의 관리, 세션 인증과 설립, 세션과 관련된 기반 네트워크 연결 및 서비스의 관리, CSE의 멀티 홉인 cse의 세션 확장의 조정, 세션 종단간의 정보의 교환, 그리고 세션의 종료를 포함한다. 주어진 M2M 서비스 세션내에서 다음 홉의 CSE 또는 어플리케이션으로/부터의 메시지 송수신을 위해 SSM CSF는 로컬 CSE 내의 CMDH CSF를 이용한다. SSM CSF는 세션 참가자의 보안 크리덴셜과 인증과 관련된 세션 관리를 위해 SEC CSF를 이용한다. SSM CSF는 세션에 특화된 과금 이벤트를 생성하며 로컬 CSE 내의 SCA CSF와도 통신한다.

SUB(Subscription and Notification)는 구독을 유지하는 알림을 제공하며, 리소스의 변화(예를 들어 리소스의 삭제)를 트래킹한다. 리소스의 구독은 M2M AE 또는 CSE에 의해 시작되며, 호스팅 CSE에 의해 접근 권한이 그랜트된다. 활성화된 구독 중에 호스팅 CSE는 구독된 리소스의 변화가 발생하는 경우 리소스 구독자가 수신하길 원하는 주소로 알림을 전송한다.

도 4 및 그에 대한 설명은 공통 서비스 개체를 구현하는 실시예들이며 본 발명이 이에 한정되지는 않는다.

한편, 본 실시예들에 적용될 수 있는 식별자(identifier)를 살펴보면 다음과 같다. M2M 식별자로는 M2M-SP-ID(M2M Service Provider Identifier), App-Inst-ID(Application Instance Identifier), App-ID(Application Identifier), CSE-ID(CSE Identifier), M2M-Node-ID(M2M Node Identifier/Device Identifier), M2M-Sub-ID(M2M Service Subscription Identifier), M2M-Request-ID(Request Identifier) 등이 있다.

oneM2M은 시스템을 구현하기 위해 충족시켜야 할 요구사항으로 전반적인 시스템 요구사항(Overall System Requirements), 관리 요구사항(Management Requirements), 데이터 모델과 의미 요구사항(Data Model & Semantics Requirements), 보안 요구사항(Security Requirements), 과금 요구사항(Charging Requirements), 운영 요구사항(Operational Requirements)을 제시하고 있다.

본 명세서에서는 M2M 시스템 기술, 특히 oneM2M 서비스 플랫폼 기술을 중심으로 설명한다. 그러나 이러한 설명이 M2M 서비스 플랫폼 기술에만 한정되는 것은 아니며, 기기간 통신, 즉 사물 통신을 제공하는 모든 시스템 및 구조와 이들 시스템에서 발생하는 통신 동작에 적용 가능하다.

또한, 본 명세서에서의 발신자, 발원자, 오리지네이터 등은 메시지를 전송하는 M2M 장치를 의미하는 것이며, 수신자, 리시버, 호스팅 CSE 등은 메시지를 수신하는 M2M 장치를 의미할 수 있다. 다만, 수신자도 응답 메시지를 전송할 수 있고, 발신자도 응답 메시지를 수신할 수 있다. 따라서, 특정 절차에서 요청 메시지를 최초로 전송하는 M2M 장치를 발신자 또는 Originator 또는 발원자로 기재하여 설명하고, 전송된 요청 메시지를 수신하는 M2M 장치를 수신자 또는 Receiver 또는 Hosting CSE로 기재하여 설명한다. 물론, 전술한 바와 같이, 발신자와 수신자 모두 메시지를 송수신할 수 있다.

또한, 본 명세서에서의 M2M 장치는 전술한 AE, CSE, NSE 등을 포함하는 다양한 노드를 의미하는 명칭으로 기재하여 설명하며, 이해의 편의를 위하여 호스팅 CSE를 중심으로 설명을 진행하나 이에 한정되는 것은 아니다. 즉, M2M 장치는 M2M 시스템을 구성하는 일 구성 장치를 의미하며, 요청 메시지를 수신하여 이에 대한 처리를 수행하고 응답 메시지를 전송하는 다양한 노드, 장치, 개체 등을 의미한다.

M2M 시스템에서 M2M 시스템을 구성하는 각 M2M 장치 및 해당 M2M 장치의 정보를 이용하여 사용자에게 응용 프로그램을 제공하는 어플리케이션 등은 서로 필요한 정보를 교환한다. 예를 들어, M2M 장치는 필요한 정보에 대한 생성, 조회, 삭제, 갱신 및 통지의 동작을 수행할 수 있으며, 다른 M2M 장치 및 어플리케이션 등은 해당 동작을 요청할 수 있다.

다만, M2M 시스템은 다수의 M2M 장치에 의해서 구성될 수 있으며, 개별 M2M 장치는 서로 다른 제조사나 오퍼레이터에 의해서 생산 및 동작될 수 있다. 또한, M2M 정보를 이용하는 어플리케이션의 경우에도 다양한 플랫폼에 기반하여 구성될 수 있다. 따라서, M2M 장치 간 또는 M2M 장치와 어플리케이션 간에 서로 다른 데이터 관리 정책(데이터 유형, 인코딩 방식 등)이 적용될 수 있다.

이와 같이, 서로 다른 데이터 관리 정책이 적용되는 경우에 다른 데이터 관리 정책을 사용하는 M2M 장치의 데이터를 빠르고 정확하게 디코딩하여 획득 및 사용하는 데에 문제점이 발생할 수 있다. 예를 들어, 서로 다른 인코딩 유형을 수행하는 M2M 장치 간에는 교환된 정보가 어떠한 유형으로 인코딩되었는지를 확인할 수 없을 수 있다. 따라서, 정보를 수신한 M2M 장치는 해당 정보에 대한 디코딩 동작을 자신의 장치에 적용된 인코딩 유형에 따라 수행하는 경우, 정보가 디코딩되지 않아서 정보를 획득할 수 없는 문제점이 존재한다.

아래에서는 이러한 문제점이 발생하는 상황을 M2M 장치 간의 데이터 송수신 동작을 중심으로 설명한다. 다만, 위에서 설명한 바와 같이 어플리케이션이 M2M 장치의 정보를 활용하는 경우에도 본 개시가 동일하게 적용될 수 있다.

한편, 본 명세서에서의 시계열 자원은 M2M 장치가 관리하는 데이터의 일 예일 뿐 다양한 자원에 동일하게 본 개시가 적용될 수 있다. 즉, 시계열 자원은 상수도 사용량, 전기 사용량과 같이 시계열적으로 수집 및 저장되는 데이터에 대한 자원을 의미하며, 본 개시는 시계열 자원 뿐만 아니라 M2M 장치가 저장하여 관리하는 모든 자원에 동일하게 적용될 수 있다. 아래에서는 필요에 따라 시계열 자원을 <timeSeries> 자원으로 기재하여 설명하며 시계열 자원의 부속자원으로 <timeSeriesInstance> 자원을 예시적으로 설명한다.

한편, M2M 장치는 각 자원에 대해서 부속자원 및 속성정보를 포함할 수 있으며, 부속자원과 속성정보는 그 목적에 따라 구분되어 저장 및 관리될 수 있다.

도 5는 일 실시예에 따른 <timeSeriesInstance> 자원 생성을 위한 요청 메시지를 처리하는 절차를 설명하기 위한 도면이다.

도 5를 참조하면, 발신자(300)는 시계열 인스탄스 자원에 대한 생성을 요청하는 요청 메시지를 수신자(310)로 전송할 수 있다(S310). 예를 들어, 요청 메시지는 필수적 파라미터와 선택적 파라미터를 요청 메시지에 포함시킬 수 있다. 일 예로, 요청 메시지는 송신측 파라미터와 수신측 파라미터, 동작 파라미터와 요청 식별 파라미터를 필수적으로 포함한다. 또한, 요청 메시지는 선택적으로 응답 유형 파라미터를 포함할 수 있다.

S510 단계의 경우에 시계열 인스탄스 자원에 대한 생성을 요청하는 요청 메시지이므로, 동작 파라미터는 생성을 지시하는 값으로 설정되고, 자원 타입은 시계열 인스탄스 자원을 지시하는 값으로 설정된다. 한편, 컨텐츠 파라미터는 생성하고자 하는 컨텐츠 정보를 포함한다.

수신자(310)는 요청 메시지를 수신하고, 해당 요청 메시지의 각 파라미터를 확인하여 지시된 동작을 수행함으로써, 요청 메시지를 처리한다(S520). 예를 들어, 수신자(310)는 시계열 자원의 부속자원으로 시계열 인스탄스 자원을 생성하고, 해당 시계열 인스탄스 자원에 요청 메시지에 포함된 컨텐츠 정보를 저장한다.

이후, 수신자(310)는 S520 단계의 처리 결과에 따라 응답 메시지를 발신자(300)에게 전송한다(S530). 예를 들어, 응답 메시지는 응답 상태 코드 정보 및 요청 식별 파라미터 정보를 포함할 수 있다. 일 예로, 요청 식별 파라미터 정보는 S510 단계의 요청 식별 파라미터 정보와 동일한 값으로 설정되어, 해당 응답 메시지가 어떤 요청 메시지에 대한 응답인지를 나타낸다. 다른 예로, 응답 상태 코드는 성공, 실패, 기타 유형을 지시하는 값으로 설정될 수 있으며, 해당 요청 메시지에 대한 처리가 성공하였는지, 실패하였는지 또는 기타 미리 설정된 유형의 동작이 발생하였는지를 지시한다.

이러한 동작을 통해서 발신자(300)는 수신자(310)에게 특정 자원의 생성을 요청할 수 있으며, 동일 또는 유사한 동작을 통해서 특정 자원에 대한 갱신, 조회, 삭제를 요청할 수도 있다. 또는 수신자(310)는 필요에 따라 특정 자원을 통지할 수도 있다.

도 6은 일 실시예에 따른 요청 메시지의 동작 파라미터에 따른 메시지 코드와 응답 메시지 코드를 예시적으로 도시한 도면이다.

도 6을 참조하면, 도 5의 생성 요청 메시지의 경우에 다양한 방식으로 전송될 수 있다.

일 예로, 도 5의 요청 메시지는 600과 같이 각 파라미터에 대한 값을 포함하여 전송될 수 있다. "to"는 수신측 파라미터로 해당 요청 메시지의 타켓 수신자를 지시한다. "from"은 송신측 파라미터로 요청 메시지를 전송하는 발신자를 지시한다. "op"는 동작 파라미터로 생성, 조회, 갱신, 삭제, 통지 중 어느 하나를 지시하도록 설정된다. 본 예에서는 생성을 지시하는 1로 설정된 경우를 개시하였다. "rqi"는 요청 식별 파라미터로 특정 값으로 설정될 수 있다. "pc"는 컨텐츠를 지시하는 것으로 본 예에서는 자동차, 속도, 날짜, 상태 등에 대한 정보를 포함한다.

요청 메시지는 JSON (JavaScript Object Notation) 형식으로 전송될 수 있으며, 600은 JSON 형식의 자료 구성 방식이다. 또한, 600은 인코딩 유형과 전송하는 데이터를 암호화하지 않는 경우, 즉 컨텐츠 보안이 없음을 암시적으로 나타낸다.

600의 요청 메시지를 수신한 수신자는 해당 요청 메시지 처리 동작을 수행하고 605 형식의 응답 메시지를 전송한다. 예를 들어, "rsc"는 응답 상태 코드 파라미터로 처리 성공(2001)을 지시하는 값으로 설정될 수 있으며, 요청 식별 파라미터는 600의 "rqi"와 동일한 값으로 설정된다. 발신자는 605 응답 메시지를 수신하여, 600의 요청 메시지에 따라 자원이 성공적으로 생성되었음을 인지한다.

한편, 650과 655는 동작 파라미터가 조회로 설정된 경우의 요청 메시지와 응답 메시지의 JSON 형식의 자료 구성 방식을 예시적으로 나타낸다.

650의 경우 동작 파라미터가 2로 설정되어, 조회를 지시하는 값으로 설정될 수 있으며, 특정 자원에 대한 조회 동작을 요청하는 것으로 600과 같이 컨텐츠는 포함하지 않을 수 있다.

수신자는 650 요청 메시지를 수신하면, 컨텐츠에 해당 요청된 자원의 정볼를 포함하여 응답 메시지를 655와 같이 구성하여 전송한다.

650과 655의 경우에도 각 메시지는 JSON (JavaScript Object Notation) 형식으로 전송될 수 있으며, JSON 형식의 자료 구성 방식을 도시하였다. 또한, 650과 655는 인코딩 유형과 전송하는 데이터를 암호화하지 않는 경우, 즉 컨텐츠 보안이 없음을 암시적으로 나타낸다.

다만, 데이터에 대한 미디어 유형, 인코딩 유형, 및 컨텐츠 보안 유형에 따라서 컨텐츠를 표현하는 방법은 매우 다양할 수 있다.

도 7은 데이터 처리 방식에 따라서 다양하게 표현되는 컨텐츠 처리 방법을 설명하기 위한 도면이다. 도 7을 참조하면, 도 6의 요청 메시지 및 응답 메시지와 동일한 컨텐츠라고 하더라도 도 7의 표와 같이 매우 다양한 케이스로 표현될 수 있다.

예를 들어, 미디어 유형은 XML, JSON, CBOR(Concise Binary Object Representation) 세 가지가 존재할 수 있으며, 인코딩 유형도 Plan, Base64와 같이 다양하게 존재할 수 있다. 또한, 도 7에는 개시되지 않았으나, 컨텐츠 보안 유형도 다양하게 설정도리 수 있다.

따라서, 미디어 유형이 3가지이고, 인코딩 유형이 3가지, 컨텐츠 보안 유형이 7가지인 경우에 동일한 컨텐츠 데이터를 표현하는 방법은 63가지의 경우의 수가 발생할 수 있다. 이와 같이, 도 7 이외에도 매우 다양한 형태의 표현 방식이 존재할 수 있다.

이와 같이, 특정 자원에 대해서는 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보가 정의될 수 있다.

일 예로, 미디어 유형 정보는 RFC6838에 정의되고 있으며, 특정 관리주체(예를 들어, https://www.iana.org/assignments/media-types/media-types.xhtml)에서 관리될 수 있다.

다른 예로, 인코딩 유형 정보는 인코딩을 하지 않는 유형, 문자열과 같은 string data에 대한 Base64 인코딩 유형 및 binary data에 대한 Base64 인코딩 유형 등으로 아래 표 1과 같이 구분될 수 있다.

인코딩 유형 지시 값	인코딩 유형
0	Plain - no transfer encoding is applied
1	base64 encoding is applied on string data
2	base64 encoding is applied on binary data

또 다른 예로, 컨텐츠 보안 유형 정보는 아래 표 2와 같이 구분될 수 있다.

컨텐츠 보안 유형 지시 값	컨텐츠 보안 유형
0	ESData has not been applied to the content data.
1	ESData using JWE and/or JWS with Compact Serialization has been applied to the content data with no subsequent transfer encoding.
2	ESData using JWE and/or JWS with JSON Serialization has been applied to the content data with no subsequent transfer encoding.
3	ESData using JWE and/or JWS with JSON Serialization has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.
4	ESData using XML encryption and/or XML-Signature has been applied to the content data has been applied with no subsequent transfer encoding.
5	ESData using XML encryption and/or XML-Signature has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.

위에서 설명한 각 유형은 일부 예를 들어 표시한 것으로 이 외에도 설정에 따라 다양한 유형이 적용될 수 있다. 이와 같이, 다양한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형이 적용될 수 있으므로, 특정 컨텐츠에 대해서 M2M 장치 또는 어플리케이션이 접근하는 경우에 어떤 유형인지를 사전에 인지할 수 없어서 원활한 정보 교환이 이루어지지 못하는 문제점이 발생할 수 있다.

즉, 해당 요청 메시지 또는 응답 메시지를 수신한 M2M 장치는 수신된 컨텐츠 정보가 어떤 미디어 유형, 인코딩 유형, 컨텐츠 보안 유형이 적용되었는지 확인할 수 없고, 프로토콜 규격에 정의된 각각의 유형에 대한 경우의 수(최대 63번)를 모두 조합하여 디코딩을 수행해야하는 문제점이 있다.

도 8은 종래 요청 메시지에 따라 대상 자원을 처리하는 동작을 설명하기 위한 도면이다.

도 8을 참조하면, 요청 메시지를 수신한 M2M 장치는 해당 장치에 미리 설정된 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형을 적용하여 대상 자원을 생성처리할 수 있다. 즉, 요청 메시지를 전송한 발신자 또는 해당 대상 자원을 사용할 가능성이 있는 어플리케이션과는 무관하게 대상 자원을 처리한다.

예를 들어, M2M 장치는 시계열 인스탄스 자원(<timeSeriesInstance> resource)의 생성을 요청하는 요청 메시지를 수신하면, 해당 요청 메시지의 요청 파라미터를 확인한다(S800). 요청 파라미터 확인에 실패하는 경우, 어떤 요청 메시지인지 확인이 되지 않으므로, M2M 장치는 에러 처리를 수행한다(S810). 이 경우, M2M 장치는 에러 상태에 미리 매핑되어 설정된 응답 상태 코드를 생성하고(S880), 응답 상태 코드를 포함하는 응답 메시지를 전송한다(S890).

한편, 요청 파라미터에 대한 확인이 성공하면, M2M 장치는 시계열 자원의 하위 속성정보에 포함되는 최대 인스탄스 숫자와 현재 저장된 인스탄스 숫자를 비교한다(S820). maxNrOfInstances는 시계열 자원의 최대 인스탄스 숫자를 나타내는 속성정보이고, currentNrOfInstances는 현재 인스탄스 숫자를 나타내는 속성정보이다. 현재 인스탄스 숫자는 요청 메시지에 의해서 지시된 인스탄스의 수를 제외하고 설정될 수도 있고, 포함하여 설정될 수도 있다.

현재 인스탄스 숫자가 최대 인스탄스 숫자를 초과하지 않는 경우에 M2M 장치는 시계열 자원의 하위 속성정보에 포함되는 최대 바이트 사이즈와 현재 바이트 사이즈를 비교한다(S830). CurrentByteSize는 현재 시계열 자원의 바이트 사이즈를 나타내는 속성정보이고, maxByteSize는 시계열 자원에 설정된 최대 바이트 사이즈를 나타내는 속성정보이다.

만약, 현재 바이트가 최대 바이트 사이즈를 초과하지 않는 경우에 M2M 장치는 요청 메시지에 의해서 지시된 시계열 인스탄스 자원을 생성한다(S850). 시계열 인스탄스 자원은 시계열 자원의 하위 부속자원으로 생성될 수 있다.

이와 달리, S820 및 S830 단계 중 어느 하나의 단계에서 현재 인스탄스 숫자 또는 현재 바이트 사이즈가 최대값을 초과하는 경우에 M2M 장치는 해당 요청 메시지를 처리할 수 없음을 지시할 수 없음으로 실패 처리를 수행한다(S840). 이 경우, M2M 장치는 해당 실패 처리 유형에 따라 미리 설정된 응답 상태 코드를 생성하고(S880), 응답 상태 코드를 포함하는 응답 메시지를 전송한다(S890).

S850 단계 이후에 M2M 장치는 시계열 인스탄스 자원이 추가로 생성되었으므로, 시계열 자원의 하위 속성정보 중 currentNrOfInstances 속성정보와 CurrentByteSize 속성정보의 값을 생성된 인스탄스 자원을 반영하여 갱신한다(S860).

이후, M2M 장치는 요청 메시지에 대해서 성공 처리를 수행하고(S870), 성공 처리에 매핑되어 설정된 응답 상태 코드를 생성하여(S880), 응답 메시지에 포함한 후 전송한다(S890).

이러한 일련의 동작을 통해서 M2M 장치는 요청 메시지를 처리한다. 다만, 종래에는 S850 단계에서 별도의 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 내용을 확인하지 않고, M2M 장치에 설정된 정책에 따라 적용하였다. 즉, 종래에는 암묵적으로 대상 자원을 생성할 때 도 7의 케이스 중 어느 하나의 케이스를 적용하여 처리할 수 있다.

예를 들어, M2M 장치가 도 7의 CASE B의 형식을 적용하여 대상 자원을 생성한 경우에 다른 M2M 장치(AE 또는 CSE)는 대상 자원을 탐색하거나 및 사용하려면 선택적 파라미터인 자원 이름 속성 정보 및 라벨 속성정보를 이용하여야 한다. 왜냐하면 다른 M2M 장치는 Base64로 인코딩 된 컨텐츠로 자동차를 탐색 수 없기 때문이다. 만약, 대상 자원을 생성한 M2M 장치가 "자동차"로 라벨 속성정보를 생성하면, 다른 M2M 장치는 해당 라벨 속성정보를 이용하여 대상 자원을 찾을 수 있다. 그러나, 대상 자원에 대한 조회를 요청하는 새로운 발신자는 대상 자원의 컨텐츠 또는 컨텐츠 속성정보인 "ew0KCSJ0aGluZyI6ICJjYXIiLA0KCSJzdGF0dXMiOiAiZHJpdmUiLA0KCSJzcGVlZCI6ICIxMDAiDQp9"을 이해하거나 해석할 수 없다. 이는 대상 자원의 컨텐츠 또는 속성정보가 어떤 유형에 따라 인코딩 되었는지 알 수 없기 때문이다.

이러한 문제점은 대상 자원에 대한 조회를 요청하는 경우에도 유사하게 발생한다.

도 9는 일 실시예에 따른 대상 자원에 대한 조회를 요청하는 요청 메시지에 대한 처리 동작을 설명하기 위한 도면이다.

도 9를 참조하면, 발신자(300)는 특정 자원에 대한 조회(Retrieve) 동작을 요청하는 요청 메시지를 전송할 수 있다(S910). 예를 들어, 요청 메시지는 전술한 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 필수적으로 포함할 수 있다. 여기서, 동작 파라미터는 조회를 나타내는 값으로 설정된다.

수신자(310)는 요청 메시지를 수신하면, 요청된 동작 파라미터의 동작을 수행하여 조회 동작을 수행한다(S920).

이후, 수신자(310)는 조회된 대상 자원의 컨텐츠를 포함하여 응답 메시지를 발신자(300)에게 전송한다(S1030). 응답 메시지의 요청 식별 파라미터는 요청 메시지의 요청 식별 파라미터와 동일한 값으로 설정될 수 있다. 또한, 수신자(310)는 조회 요청에 대한 처리가 성공한 경우에 이를 지시하는 응답 상태 코드의 값(예를 들어, 2000)을 설정하여 응답 메시지에 포함하여 전송할 수 있다.

도 10과 도 11을 참조하여 도 9에서의 요청 메시지와 응답 메시지의 코드를 설명한다.

도 10은 일 실시예에 따른 <timeSeriesInstance> 자원 조회를 위한 요청 메시지의 코드를 예시적으로 도시한 도면이다.

도 10을 참조하면, 요청 메시지는 동작 파라미터가 2로 설정되어 대상 자원에 대한 조회를 요청하며, 송신측 파라미터, 수신측 파라미터가 포함된다. 또한, 요청 식별 파라미터가 특정 값으로 설정된다.

도 11은 일 실시예에 따른 도 10의 요청 메시지에 대한 응답 메시지의 코드를 예시적으로 도시한 도면이다.

도 11을 참조하면, 응답 메시지는 응답 상태 코드를 통해서 해당 요청 메시지에 대한 처리가 성공적으로 이루어졌음을 나타낸다. 또한, 요청 식별 파라미터는 요청 메시지의 값과 동일하게 설정된다. 컨텐츠 정보에는 조회의 대상이 되는 대상 자원에 대한 정보가 포함된다. 특히, 컨텐츠 정보의 "con"은 해당 자원에 대한 코드가 포함되며, 전술한 바와 같이 수신자가 해당 대상 자원을 저장한 도 7의 CASE B 형태로 포함될 수 있다.

도 12는 종래 도 11의 응답 메시지를 통해서 정보를 추출하는 동작을 설명하기 위한 도면이다.

도 12를 참조하면, 도 11의 응답 메시지 코드를 수신한 요청 메시지 발신자는 수신된 응답 메시지의 응답 상태 코드를 체크한다(S1200). 응답 상태 코드가 요청 메시지의 처리 성공을 지시하는 값으로 설정되면, 발신자는 요청 식별 파라미터가 요청 메시지의 요청 식별 파라미터와 동일한지 체크한다(S1210). S1200과 S1210은 그 순서가 바뀔 수 있다.

발신자는 S1210 단계의 판단 결과 동일한 것으로 판단되면, 컨텐츠가 존재하는지 판단한다(S1220). 컨텐츠가 존재하는 것으로 판단되면, 발신자는 해당 컨텐츠 파라미터에서 컨텐츠 정보를 추출한다(S1230). 다만, 도 11에서와 같이 컨텐츠 정보는 응답 메시지를 전송한 수신자의 데이터 관리 유형에 따라 포함되므로, 발신자는 추출된 컨텐츠 정보가 미리 설정된 발신자의 포맷에 일치하는지를 판단한다(S1240).

또한, S1200, S1210 및 S1220의 각 단계에서 응답 상태 코드가 실패로 지시되거나, 요청 식별 파라미터가 일치하지 않거나, 컨텐츠가 존재하지 않는 경우에 발신자는 에러 처리 동작을 수행한다(S1205).

한편, 발신자는 컨텐츠 정보를 발신자의 데이터 관리 유형을 적용하여 디코딩을 수행한다. 만약, 수신자와 발신자가 서로 다른 데이터 관리 유형을 사용하는 경우에 디코딩은 실패하게 된다. 또는, 발신자는 모든 데이터 관리 유형에 대해서 순차적으로 디코딩을 시도할 수도 있다.

다만, 컨텐츠 정보가 존재하고, 추출도 완료하였으나 포맷을 발신자가 알지 못해서 발신자가 디코딩에 실패하거나, 모든 경우의 수를 순차적으로 적용하여 디코딩을 수행하는 것은 정보 전달 기능에서 치명적인 문제점으로 작용할 수 있다. 즉, 정보가 제대로 교환되지 않거나, 교환된 정보의 획득에 불필요한 리소스가 사용되는 문제점이 있다.

이러한 문제점을 해결하기 위해서 도출된 본 개시는 대상 자원의 하위 속성정보에 데이터 유형에 대한 정보를 추가하여 정보 교환이 원활하게 이루어지도록 하고자 한다.

도 13은 일 실시예에 따른 M2M 장치의 동작을 설명하기 위한 도면이다.

도 13을 참조하면, M2M(Machine to Machine communication) 장치는 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계를 수행한다(S1300).

예를 들어, 요청 메시지는 필수적 파라미터로 발신자를 지시하는 송신측 파라미터, 수신자를 지시하는 수신측 파라미터, 동작 유형을 지시하는 동작 파라미터와 요청과 응답을 식별하기 위한 요청 식별 파라미터를 포함한다. 또한, 각 동작 파라미터에 따라 선택적으로 컨텐츠 파라미터를 더 포함할 수도 있다. 예를 들어, 생성, 갱신 등의 동작을 지시하는 요청 메시지의 경우에 생성될 대상 자원, 갱신할 컨텐츠에 대한 컨텐츠 파라미터를 포함할 수 있다.

또한, M2M 장치는 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계를 수행한다(S1310). 예를 들어, M2M 장치는 요청 메시지를 수신하면, 동작 파라미터에 기초하여 대상 자원을 처리한다.

예를 들어, 속성정보는 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함할 수 있다. 즉, 속성정보는 대상 자원에 적용된 미디어 유형 정보, 인코디 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나에 대한 정보를 포함할 수 있다.

또한, 대상 자원은 시계열 자원 또는 시계열 자원의 하위 부속자원인 시계열 인스탄스 자원일 수 있다. 또는, 대상 자원은 컨텐츠 인스탄스 자원일 수 있다. 즉, 대상 자원은 M2M 장치가 저장 및 관리하는 자원이거나, 해당 자원의 하위 부속자원일 수 있다.

예를 들어, 속성정보는 대상 자원의 하위 속성정보로 Contentinfo 속성정보일 수 있으며, Contentinfo 속성정보는 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함할 수 있다.

한편, M2M 장치는 대상 자원을 동작 파라미터에 따라 처리함에 있어서 속성정보를 이용할 수 있다.

일 예로, M2M 장치는 동작 파라미터가 생성을 지시하는 경우, 대상 자원에 적용된 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 Contentinfo 속성정보에 포함하고, Contentinfo 속성정보를 대상 자원의 하위 속성정보로 구성하여 대상 자원을 생성할 수 있다.

다른 예로, M2M 장치는 동작 파라미터가 조회를 지시하는 경우, 발신자가 요청한 조회 대상 자원을 특정하고, 해당 대상 자원에 적용되는 속성정보인 Contentinfo 속성정보를 응답 메시지에 포함할 정보로 특정할 수 있다.

이와 같이, 대상 자원과 해당 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 속성정보로 관리함으로써, M2M 장치 간 또는 어플리케이션이 해당 대상 자원에 대한 유형 정보를 명확하게 확인할 수 있다.

또한, M2M 장치는 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 수행한다(S1320). 예를 들어, M2M 장치는 동작 파리미터가 조회 또는 통지를 지시하는 경우, 대상 자원 및 속성정보를 포함하여 응답 메시지를 전송한다. 한편, 응답 메시지는 응답 상태 코드를 포함할 수 있으며, 동작 파라미터가 생성, 삭제 등을 지시하는 경우에 해당 동작의 처리 성공, 실패 등을 지시하는 값으로 응답 상태 코드가 설정될 수 있다.

또한, 응답 메시지는 요청 메시지에 포함된 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함한다.

이 외에도, 응답 메시지는 요청 메시지의 응답 모드가 플렉스 블럭킹으로 지시된 경우에 M2M 장치가 처리한 응답 모드에 따라 개별 매핑되는 응답 상태 코드를 포함할 수 있다. 응답 모드는 해당 요청 메시지를 처리하는 동작을 구분하기 위한 것으로, 블럭킹, 동기식 넌블럭킹, 비동기식 넌블럭킹 및 플렉스 블럭킹으로 구분된다. 이 중 플렉스 블럭킹 모드는 수신자가 응답 모드를 결정하는 것으로, 발신자는 수신자가 선택한 응답 모드를 알 수 없다. 따라서, 응답 상태 코드의 성공 처리를 지시하는 값을 각 응답 모드에 따라 구분된 값으로 설정함으로써, 발신자는 응답 메시지를 수신하여 어떤 응답 모드에 따라 요청 메시지에 대한 응답 처리 동작을 수행하면 되는지 인지할 수 있다.

아래에서는 대상 자원이 시계열 자원인 경우와 시계열 인스탄스 자원인 경우의 속성정보 및 부속자원의 구성을 예시적으로 나타낸다.

도 14는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 자원의 구조를 예시적으로 도시한 도면이다.

도 14를 참조하면, 시계열 자원(<timeseries> resource)는 contentInfo 속성정보를 포함하여 다양한 속성정보와 시계열 인스탄스 자원 등의 부속자원을 포함하여 구성될 수 있다.

예를 들어, contentInfo 속성 정보를 포함하는 <timeSeries> 자원은 표 3과 같이 구성될 수 있다.

Attributes of <timeSeries>	Multiplicity	RW/ RO/ WO	Description	<timeSeriesAnnc> Attributes
resourceType	1	RO	See clause 9.6.1.3.	NA
resourceID	1	RO	See clause 9.6.1.3.	NA
resourceName	1	WO	See clause 9.6.1.3.	NA
parentID	1	RO	See clause 9.6.1.3.	NA
expirationTime	1	RW	See clause 9.6.1.3	MA
accessControlPolicyIDs	0..1 (L)	RW	See clause 9.6.1.3. If no accessControlPolicyIDs value is configured, the accessControlPolicyIDs of the parent resource shall be applied for privilege checking.	MA
labels	0..1 (L)	RW	See clause 9.6.1.3.	MA
creationTime	1	RO	See clause 9.6.1.3.	NA
lastModifiedTime	1	RO	See clause 9.6.1.3.	NA
stateTag	1	RO	See clause 9.6.1.3.	OA
announceTo	0..1 (L)	RW	See clause 9.6.1.3.	NA
announcedAttribute	0..1 (L)	RW	See clause 9.6.1.3.	NA
dynamicAuthorizationConsultationIDs	0..1 (L)	RW	See clause 9.6.1.3.	OA
creator	1	RO	See clause 9.6.1.3.	NA
maxNrOfInstances	0..1	RW	Maximum number of direct child <timeSeriesInstance> resources in the <timeSeries> resource.	OA
maxByteSize	0..1	RW	Maximum size in bytes of data that is allocated for the <timeSeriesInstance> resource for all direct child<timeSeriesInstance> resources.	OA
maxInstanceAge	0..1	RW	Maximum age of a direct child <timeSeriesInstance> resource in the <timeSeries> resource. The value is expressed in seconds.	OA
currentNrOfnstances	1	RO	Current number of direct child <timeSeriesInstance> resource in the <timeSeries> resource. It is limited by the maxNrOfInstances. The currentNrOfInstances attribute of the <timeSeries> resource shall be updated on successful creation or deletion of direct child < timeSeriesInstance > resource of <timeSeries > resource.	OA
currentByteSize	1	RO	Current size in bytes of data stored in all direct child <timeSeriesInstance> resources of a <timeSeries> resource. It is limited by the maxByteSize. The currentByteSize attribute of the <timeSeries> resource shall be updated on successful creation or deletion of direct child < timeSeriesInstance > resource of <timeSeries > resource.	OA
periodicInterval	0..1	WO	If the Time Sereis Data is periodic, this attribute shall contain the expected amount of time between two instances of Time Series Data.	OA
missingDataDetect	0..1	WO	Indicates whether the Receiver shall detect the missing Time Series Data if it is periodic.	NA
ontologyRef	0..1	RW	A reference (URI) of the ontology used to represent the information that is stored in the child <timeSeriesInstance> resources of the present <timeSeriesData> resource (see note).	OA
missingDataMaxNr	0..1	RW	Maximum number of entries in the missingDataList if the periodicInterval is set and the missingDataDetect is TRUE.	OA
missingDataCurrentNr	0..1	RO	Current number of the missing Time Series Data in the missingDataList.	OA
missingDataList	0..1(L)	RO	The list of the dataGenerationTime value representing the missing Time Series Data in descending order by time if the periodicInterval is set and the missingDataDetect is TRUE.	OA
missingDataDetectTimer	0..1	RW	The missingDataDetectTimer after which a missing Time Series Data shall be considered lost by the hosting CSE. Note that the setting of this value may not apply in certain transports such as TCP, and as such the hosting CSE may reject proposed values or suggest different values.	OA
contentInfo	0..1	WO	This attribute contains information to understand the contents of the content attribute of <timeSeriesInstance>. It shall be composed of two mandatory components consisting of an Internet Media Type (as defined in the IETF RFC 6838) and an encoding type. In addition, an optional content security component may also be included. The format of this attribute is defined in oneM2M TS-0004　[3]. If not present, the default shall be a media type of XML, an encoding type of plain text and no optional content security.	OA
NOTE: The access to this URI is out of scope of oneM2M.

위 표 3에서는 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다.

도 15는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 인스탄스 자원의 구조를 예시적으로 도시한 도면이다.

도 15를 참조하면, 시계열 인스탄스 자원(<timeSeriesInstance> resource)도 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 등을 지시하는 정보를 포함하는 contentInfo 속성정보를 포함할 수 있다.

예를 들어, <timeSeriesInstance> 자원은 <timeSeries> 자원의 데이터 객체를 나타낸다. <timeSeriesInstance> 자원은 일단 생성되면 수정할 수 없으며, 응용 객체(AE)는 명시적으로 <timeSeriesInstance> 자원을 삭제할 수 있어야 하며 정책에 따라 플랫폼에서 삭제할 수 있다. 플랫폼에 <timeSeriesInstance> 자원 보존에 대한 정책이 있는 경우에 해당 정책은 <timeSeries> 자원의 maxByteSize, maxNrOfInstances, maxInstanceAge 또는 이러한 속성정보의 조합으로 표현된다. 여러 정책이 시행되는 경우 가장 엄격한 정책이 적용된다. <timeSeriesInstance> 자원은 상위 <timeSeries> 자원과 동일한 액세스 제어 정책을 상속받으며, 자체 accessControlPolicyIDs 속성정보를 갖지 않는다는 점에서 차이점이 있다.

한편, <timeSeriesInstance> 자원은 표 4에 지정된 하위 부속자원을 포함할 수 있다.

Child Resources of < timeSeriesInstance >	Child Resource Type	Multiplicity	Description	<timeSeriesInstanceAnnc> Child Resource Types
[variable]	<semanticDescriptor>	0..n	See clause 9.6.30	<semanticDescriptor>, <semanticDescriptorAnnc>

위 표 4에서는 설명의 편의를 위하여 설명 부분을 "See clause 9.6.30."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다.

또한, <timeSeriesInstance> 자원은 표 5에 명시된 속성정보를 포함한다.

Attributes of <timeSeriesInstance>	Multiplicity	RW/ RO/ WO	Description	<timeSeriesInstanceAnnc> Attributes
resourceType	1	RO	See clause 9.6.1.3.	NA
resourceID	1	RO	See clause 9.6.1.3.	NA
resourceName	1	WO	See clause 9.6.1.3.	NA
parentID	1	RO	See clause 9.6.1.3.	NA
labels	0..1 (L)	WO	See clause 9.6.1.3.	MA
creationTime	1	RO	See clause 9.6.1.3.	NA
expirationTime	1	WO	See clause 9.6.1.3.	NA
announceTo	0..1 (L)	RW	See clause 9.6.1.3.	NA
announcedAttribute	0..1 (L)	RW	See clause 9.6.1.3.	NA
lastModifiedTime	1	RO	See clause 9.6.1.3.	NA
contentInfo	1	WO	This attribute is an information to understand the contents of content attribute. It shall be composed by three elements of Internet Media Type (as defined in the IETF RFC 6838), encoding type and content security. The delimeter shall be used ':' character as defined in oneM2M TS-0004　[3].	OA
dataGenerationTime	1	WO	This attribute contains the time when the data was generated by the AE/CSE.	OA
content	1	WO	This attribute contains the data generated by the AE/CSE.	OA
sequenceNr	0..1	WO	This attribute contains the data sequence number generated by the AE/CSE	OA

표 3과 같이 표 5에서는 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다.

이와 같이, <timeSeriesInstance> 자원은 contentInfo 속성정보를 포함할 수 있다. contentInfo 속성정보는 컨텐츠 속성정보의 컨텐츠를 이해하기 위한 정보를 포함할 수 있다. 예를 들어, contentInfo 속성정보는 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형의 3가지 요소로 구성될 수 있다. 또한, 속성정보를 구분하는 기호(delimeter)는 ':' 문자를 사용한다.

이와 같이, <timeSeries> 자원은 부속자원으로 <timeSeriesInstance> 자원을 가질 수 있다. 전술한 바와 같이 <timeSeriesInstance> 자원도 미디어 유형 등을 지시하는 속성정보를 별도로 포함할 수 있으나, <timeSeriesInstance> 자원에서 생성하는 속성정보는 생성되는 시간에 따라 컨텐츠 속성정보의 값이 달라질 수 있다. 다만, 속성정보를 구성하는 항목은 동일하므로 <timeSeries> 자원에서 contentInfo 속성정보를 포함하는 경우에 <timeSeriesInstance> contentInfo 속성을 이용하는 경우에 비하여, <timeSeriesInstance> 자원을 전달하는데 있어서 통신량을 줄이는 효과가 있다. 또한, 저장 및 관리 측면에서도 데이터의 양을 줄일 수 있으며, 대규모로 <timeSeriesInstance> 자원 정보를 조회하여 추출하는 경우, 처리 방법을 단순화 할 수 있다.

따라서, <timeSeriesInstance> 자원에서 전술한 유형 정보를 포함하는 속성정보가 구성될 수도 있고, 필요에 따라 상위 자원인 <timeSeries> 자원에서 전술한 유형 정보를 포함하는 속성정보가 구성될 수도 있다.

한편, 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형을 지시하는 속성정보는 컨텐츠 인스탄스 자원의 속성정보로 구성될 수도 있다.

예를 들어, 종래에는 일반적인 데이터를 표현하는 <contentInstance> 자원을 구성하는데 있어서, contentInfo 속성정보가 컨텐츠 보안에 대한 정보가 없어서, 암호화된 데이터를 처리할 수 없는 문제점이 있었다. 즉, <contentInstance> 자원의 content 속성정보의 내용이 암호화 하는 경우, 수신자가 콘텐츠의 내용을 정확히 이해하기 위해서는 최소 7가지의 가능성을 확인하여야 내용을 알 수 있었다. 특히 의료 등 전문적인 데이터는 관계자만 데이터를 열람할 수 있으므로 반드시 데이터의 저장 또는 전송 단계에서 암호화가 필요하다. 따라서 암호화된 일반적인 데이터를 이용하여 응용 서비스 개발을 위한 정보를 획득도 매우 어려웠다.

따라서, 일반적인 데이터 <contentInstance> 자원에 대해서도 전술한 본 개시가 적용되어 일반적인 데이터 <contentInstance> 자원에서도 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 정보를 포함하는 contentInfo 속성정보가 구성될 수 있다. 즉, <contentInstance> 자원을 구성하는 contentInfo 속성정보는 미디어 유형, 인코딩 유형 및 컨텐츠 보안의 3가지 요소로 구성될 수 있다. 또한, 속성정보를 구분하는 기호(delimeter)는 ':' 문자를 사용할 수 있다.

예를 들어, 표 6과 같이 contentInfo 속성정보를 포함하는 <contentInstance> 자원은 다양한 속성정보를 포함할 수 있다.

Attributes of <contentInstance>	Multiplicity	RW/ RO/ WO	Description	<contentInstanceAnnc> Attributes
resourceType	1	RO	See clause 9.6.1.3.	NA
resourceID	1	RO	See clause 9.6.1.3.	NA
resourceName	1	WO	See clause 9.6.1.3.	NA
parentID	1	RO	See clause 9.6.1.3.	NA
labels	0..1 (L)	WO	See clause 9.6.1.3.	MA
expirationTime	1	WO	See clause 9.6.1.3.	NA
creationTime	1	RO	See clause 9.6.1.3.	NA
lastModifiedTime	1	RO	See clause 9.6.1.3.	NA
stateTag	1	RO	See clause 9.6.1.3. The stateTag attribute of the parent resource should be incremented first and copied into this stateTag attribute when a new instance is added to the parent resource.	OA
announceTo	0..1 (L)	WO	See clause 9.6.1.3.	NA
announcedAttribute	0..1 (L)	WO	See clause 9.6.1.3.	NA
dynamicAuthorizationConsultationIDs	0..1 (L)	RW	See clause 9.6.1.3.	OA
creator	0..1	RO	See clause 9.6.1.3.	NA
contentInfo	0..1	WO	This attribute contains information to understand the contents of content attribute. It shall be composed of two mandatory components consisting of Internet Media Type (as defined in the IETF RFC 6838) and an encoding type. In addition, an optional content security component may also be included. The format of this attribute is defined in oneM2M TS-0004　[3]. If not present, the default shall be a media type of XML, an encoding type of plain text and no optional content security.	OA
contentSize	1	RO	Size in bytes of the content attribute.	OA
contentRef	0..1	RW	This attribute contains a list of name-value pairs. Each entry expresses and associative reference to a <contentInstance> resource. The name of the entry indicates the relationship and the value of the entry the indicates reference (URI) to the resource.	OA
ontologyRef	0..1	WO	A reference (URI) of the ontology used to represent the information that is stored in the contentInstances resources of the <container> resource. If this attribute is not present, the contentInstance resource inherits the ontologyRef from the parent <container> resource if present (see　note).	OA
content	1	WO	Actual content of a contentInstance. This content may be opaque data for understandable with the help of the contentInfo. This may, for example, be an image taken by a security camera, or a temperature measurement taken by a temperature sensor.	OA
NOTE: Access to this URI is out of scope of oneM2M.

표 6에서도 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다.

전술한 바와 같이 본 개시의 경우에 컨텐츠를 M2M 장치가 응답 메시지에 포함하여 전송함에 있어서, 해당 조회의 대상이 되는 대상 자원 컨텐츠의 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 포함하는 속성정보를 함께 전송한다. 딸다서, 요청 메시지를 전송한 발신자는 응답 메시지를 이용하여 디코딩 실패 또는 디코딩에 많은 자원을 낭비하는 문제점이 발생하지 않는다.

아래에서는 본 개시를 적용한 경우에 컨텐츠를 포함하는 응답 메시지를 수신한 발신자의 동작에 대해서 도면을 참조하여 설명한다.

도 16은 일 실시예에 따른 시계열 인스탄스 자원에 대한 조회 요청 메시지에 따른 응답 메시지에서 정보를 추출하는 동작을 설명하기 위한 도면이다.

도 16을 참조하면, 응답 메시지를 수신한 요청 메시지 발신자는 수신된 응답 메시지의 응답 상태 코드를 체크한다(S1600). 응답 상태 코드가 요청 메시지의 처리 성공을 지시하는 값으로 설정되면, 발신자는 요청 식별 파라미터가 요청 메시지의 요청 식별 파라미터와 동일한지 체크한다(S1610). S1600과 S1610은 그 순서가 바뀔 수 있다.

발신자는 S1610 단계의 판단 결과 동일한 것으로 판단되면, 컨텐츠가 존재하는지 판단한다(S1620). 컨텐츠가 존재하는 것으로 판단되면, 발신자는 해당 컨텐츠의 대상 자원에 대한 속성정보를 체크한다(S1630).

일 예로, 대상 자원인 시계열 자원인 경우에 시계열 자원의 ContentInfo 속성정보를 확인하여 시계열 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.

다른 예로, 대상 자원인 시계열 인스탄스 자원인 경우에 시계열 인스탄스 자원의 ContentInfo 속성정보 또는 상위자원인 시계열 자원의 ContentInfo 속성정보를 확인하여 시계열 인스탄스 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.

또 다른 예로, 대상 자원인 컨텐츠 인스탄스 자원인 경우에 컨텐츠 인스탄스 자원의 ContentInfo 속성정보 또는 상위자원인 컨텐츠 자원의 ContentInfo 속성정보를 확인하여 컨텐츠 인스탄스 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.

이후, 발신자는 확인된 속성정보의 유형 정보에 따라 컨텐츠 정보를 추출한다(S1640). 즉, 전술한 속성정보에 의해서 특정된 미디어 유형 또는 인코딩 유형 또는 컨텐츠 보안 유형을 이용하여 컨텐츠 정보를 디코딩함으로써, 디코딩 실패 또는 디코딩에 자원이 낭비되는 현상을 방지할 수 있다.

또한, S1600, S1610 및 S1620의 각 단계에서 응답 상태 코드가 실패로 지시되거나, 요청 식별 파라미터가 일치하지 않거나, 컨텐츠가 존재하지 않는 경우에 발신자는 에러 처리 동작을 수행한다(S1605).

이상에서 설명한 바와 같이, 대상 자원은 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 속성정보로 포함하고, M2M 장치는 해당 속성정보를 이용하여 대상 자원을 디코딩함으로써, 디코딩 실패 및 불필요한 자원의 낭비를 방지할 수 있다.

이하에서는 도 1 내지 도 16을 참조하여 설명한 본 실시예를 모두 실시할 수 있는 M2M 장치의 구성을 도면을 참조하여 다시 한 번 설명한다.

도 17은 일 실시예에 따른 M2M 장치의 구조를 도시한 도면이다.

도 17을 참조하면, M2M(Machine to Machine communication) 장치(1700)는 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부(1730)와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부(1710) 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부(1720)를 포함할 수 있다.

예를 들어, 요청 메시지는 필수적 파라미터로 발신자를 지시하는 송신측 파라미터, 수신자를 지시하는 수신측 파라미터, 동작 유형을 지시하는 동작 파라미터와 요청과 응답을 식별하기 위한 요청 식별 파라미터를 포함한다. 또한, 요청 메시지는 각 동작 파라미터에 따라 선택적으로 컨텐츠 파라미터를 더 포함할 수도 있다. 예를 들어, 생성, 갱신 등의 동작을 지시하는 요청 메시지의 경우에 생성될 대상 자원, 갱신할 컨텐츠에 대한 컨텐츠 파라미터를 포함할 수 있다.

또한, 제어부(1710)는 요청 메시지를 수신하면, 동작 파라미터에 기초하여 대상 자원을 처리한다.

예를 들어, 속성정보는 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함할 수 있다. 즉, 속성정보는 대상 자원에 적용된 미디어 유형 정보, 인코디 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나에 대한 정보를 포함할 수 있다.

또한, 대상 자원은 시계열 자원 또는 시계열 자원의 하위 부속자원인 시계열 인스탄스 자원일 수 있다. 또는, 대상 자원은 컨텐츠 인스탄스 자원일 수 있다. 즉, 대상 자원은 M2M 장치가 저장 및 관리하는 자원이거나, 해당 자원의 하위 부속자원일 수 있다.

예를 들어, 속성정보는 대상 자원의 하위 속성정보로 Contentinfo 속성정보일 수 있으며, Contentinfo 속성정보는 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함할 수 있다.

한편, 제어부(1710)는 대상 자원을 동작 파라미터에 따라 처리함에 있어서 속성정보를 이용할 수 있다.

일 예로, 제어부(1710)는 동작 파라미터가 생성을 지시하는 경우, 대상 자원에 적용된 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 Contentinfo 속성정보에 포함하고, Contentinfo 속성정보를 대상 자원의 하위 속성정보로 구성하여 대상 자원을 생성할 수 있다.

다른 예로, 제어부(1710)는 동작 파라미터가 조회를 지시하는 경우, 발신자가 요청한 조회 대상 자원을 특정하고, 해당 대상 자원에 적용되는 속성정보인 Contentinfo 속성정보를 응답 메시지에 포함할 정보로 특정할 수 있다.

송신부(1720)는 동작 파리미터가 조회 또는 통지를 지시하는 경우, 대상 자원 및 속성정보를 포함하여 응답 메시지를 전송한다. 한편, 응답 메시지는 응답 상태 코드를 포함할 수 있으며, 동작 파라미터가 생성, 삭제 등을 지시하는 경우에 해당 동작의 처리 성공, 실패 등을 지시하는 값으로 응답 상태 코드가 설정될 수 있다.

이 외에도, 제어부(1710)는 본 실시예에 따른 대상 자원에 연계하여 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 정보를 속성정보로 관리하는 데에 따른 전반적인 M2M 장치(1700)의 동작을 제어한다.

또한, 송신부(1720) 및 수신부(1730)는 발신자, 타 M2M 장치, M2M 시스템을 구성하는 다른 노드 및 어플리케이션 사용자 단말기 중 적어도 하나와 본 실시예를 수행하는 데에 필요한 메시지, 신호 및 데이터를 송수신하는 데에 사용된다.

본 명세서에서의 "시스템", "프로세서", "컨트롤러", "컴포넌트", "모듈", "인터페이스", "모델", "유닛" 등의 용어는 일반적으로 컴퓨터 관련 엔티티 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어 또는 실행 중인 소프트웨어를 의미할 수 있다. 예를 들어, 전술한 구성요소는 프로세서에 의해서 구동되는 프로세스, 프로세서, 컨트롤러, 제어 프로세서, 개체, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만 이에 국한되지 않는다. 예를 들어, 컨트롤러 또는 프로세서에서 실행 중인 애플리케이션과 컨트롤러 또는 프로세서가 모두 구성 요소가 될 수 있습니다. 하나 이상의 구성 요소가 프로세스 및/또는 실행 스레드 내에 있을 수 있으며 구성 요소는 한 시스템에 위치하거나 두 대 이상의 시스템에 배포될 수 있다.

전술한 실시예에서 언급한 표준내용 또는 표준문서들은 명세서의 설명을 간략하게 하기 위해 생략한 것으로 본 명세서의 일부를 구성한다. 따라서, 위 표준내용 및 표준문서들의 일부의 내용을 본 명세서에 추가하거나 청구범위에 기재하는 것은 본 발명의 범위에 해당하는 것으로 해석되어야 한다.

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 발명의 기술사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (16)

1. M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서,
   동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계;
   자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 상기 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계; 및
   상기 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법.
2. 제 1 항에 있어서,
   상기 속성정보는,
   상기 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
3. 제 1 항에 있어서,
   상기 대상 자원은,
   시계열 자원 또는 시계열 인스탄스 자원인 것을 특징으로 하는 방법.
4. 제 1 항에 있어서,
   상기 대상 자원은,
   컨텐츠 인스탄스 자원인 것을 특징으로 하는 방법.
5. 제 1 항에 있어서,
   상기 속성정보는,
   Contentinfo 속성정보이며,
   상기 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함하는 것을 특징으로 하는 방법.
6. 제 5 항에 있어서,
   상기 처리하는 단계는,
   상기 동작 파라미터가 생성을 지시하는 경우, 상기 대상 자원에 적용된 상기 미디어 유형 정보, 상기 인코딩 유형 정보 및 상기 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 상기 Contentinfo 속성정보에 포함하고,
   상기 Contentinfo 속성정보를 상기 대상 자원의 하위 속성정보로 구성하여 상기 대상 자원을 생성하는 것을 특징으로 하는 방법.
7. 제 5 항에 있어서,
   상기 응답 메시지는,
   상기 동작 파리미터가 조회 또는 통지를 지시하는 경우, 상기 대상 자원 및 속성정보를 포함하는 것을 특징으로 하는 방법.
8. 제 1 항에 있어서,
   상기 응답 메시지는,
   상기 요청 메시지에 포함된 상기 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함하는 것을 특징으로 하는 방법.
9. 메시지를 처리하는 M2M(Machine to Machine communication) 장치에 있어서,
   동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부;
   자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 상기 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부; 및
   상기 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부를 포함하는 M2M 장치.
10. 제 9 항에 있어서,
    상기 속성정보는,
    상기 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 M2M 장치.
11. 제 9 항에 있어서,
    상기 대상 자원은,
    시계열 자원 또는 시계열 인스탄스 자원인 것을 특징으로 하는 M2M 장치.
12. 제 9 항에 있어서,
    상기 대상 자원은,
    컨텐츠 인스탄스 자원인 것을 특징으로 하는 M2M 장치.
13. 제 9 항에 있어서,
    상기 속성정보는,
    Contentinfo 속성정보이며,
    상기 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함하는 것을 특징으로 하는 M2M 장치.
14. 제 13 항에 있어서,
    상기 제어부는,
    상기 동작 파라미터가 생성을 지시하는 경우, 상기 대상 자원에 적용된 상기 미디어 유형 정보, 상기 인코딩 유형 정보 및 상기 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 상기 Contentinfo 속성정보에 포함하고,
    상기 Contentinfo 속성정보를 상기 대상 자원의 하위 속성정보로 구성하여 상기 대상 자원을 생성하는 것을 특징으로 하는 M2M 장치.
15. 제 13 항에 있어서,
    상기 응답 메시지는,
    상기 동작 파리미터가 조회 또는 통지를 지시하는 경우, 상기 대상 자원 및 속성정보를 포함하는 것을 특징으로 하는 M2M 장치.
16. 제 9 항에 있어서,
    상기 응답 메시지는,
    상기 요청 메시지에 포함된 상기 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함하는 것을 특징으로 하는 M2M 장치.

Images