KR20210041488A

KR20210041488A - M2m 시스템에서 주기적인 통지를 송수신하는 방법 및 장치

Info

Publication number: KR20210041488A
Application number: KR1020200122835A
Authority: KR
Inventors: 나영진; 이민병
Original assignee: 현대자동차주식회사; 기아 주식회사
Priority date: 2019-10-07
Filing date: 2020-09-23
Publication date: 2021-04-15
Also published as: US20210105240A1; US11470034B2

Abstract

본 개시는 M2M 시스템에서 주기적인 통지를 송수신하는 방법 및 장치에 대한 것이다. 보다 상세하게는, M2M 시스템에서, M2M 엔티티로부터 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지에 따라 상기 M2M 엔티티에 주기적으로 통지 메시지를 송신하는 단계를 포함하되, 상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 송신될 수 있다.

Description

M2M 시스템에서 주기적인 통지를 송수신하는 방법 및 장치{METHOD AND APPARATUS FOR RECEIVING AND TRANSMITTING PERIODIC NOTIFICATION IN MACHINE TO MACHINE SYSTEM}

본 개시는 M2M(Machine-to-Machine) 시스템에서 주기적인 통지를 송수신하는 방법 및 장치에 대한 것이다. 보다 구체적으로는, 본 개시는 M2M 시스템에서 자원의 변경 여부에 관계없이 주기적으로 통지 메시지를 송수신하는 방법 및 장치에 대한 것이다.

최근 M2M(Machine-to-Machine) 시스템에 대한 도입이 활발해지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미할 수 있다. M2M은 MTC(Machine Type Communication), IoT(Internet of Things) 또는 D2D(Device-to-Device)를 지칭할 수 있다. 다만, 하기에서는 설명의 편의를 위해 M2M로 통일하여 지칭하지만, 이에 한정되지 않는다. M2M 통신에 사용되는 단말은 M2M 단말(M2M device)일 수 있다. M2M 단말은 일반적으로 적은 데이터를 전송하면서 낮은 이동성을 갖는 디바이스일 수 있다. 이때, M2M 단말은 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용될 수 있다.

또한, M2M 단말은 사물 추적, 자동차 연동, 전력 계량 등과 같이 다양한 시스템에서 적용될 수 있다.

한편, M2M 단말과 관련하여, oneM2M 표준화 기구는 M2M 통신, 사물통신, IoT 기술을 위한 요구사항, 아키텍처, API(Application Program Interface) 사양, 보안 솔루션, 상호 운용성에 대한 기술을 제공하고 있다. oneM2M 표준화 기구의 사양은 스마트 시티, 스마트 그리드, 커넥티드 카, 홈 오토메이션, 치안, 건강과 같은 다양한 어플리케이션과 서비스를 지원하는 프레임워크를 제공하고 있다.

본 개시의 목적은 자원의 변경 여부에 관계없이 주기적으로 통지를 송수신하는 데 있다.

본 개시의 목적은 구독 자원을 기반으로 주기적인 통지를 송수신하는 데 있다.

본 개시의 목적은 새로운 자원 및 새로운 속성의 정의 없이 주기적인 통지를 송수신하는 데 있다.

본 개시의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있으며, 본 개시의 실시예에 의해 보다 분명하게 알게 될 것이다. 또한, 본 개시의 목적 및 장점들은 특허청구범위에 나타난 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.

본 개시의 일 실시 예에 따르면, M2M(Machine-to-Machine) 시스템에서 주기적인 통지를 송신하는 방법은, M2M 엔티티로부터 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지에 따라 상기 M2M 엔티티에 주기적으로 통지 메시지를 송신하는 단계를 포함하되, 상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 송신될 수 있다.

한편, 상기 구독 요청 메시지가 수신되면, 상기 특정 자원의 하위 자원으로 구독 자원이 생성되고, 상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함될 수 있다.

한편, 상기 구독 요청 메시지는 주기적인 통지를 위한 시작 시간, 종료 시간, 시간 간격을 포함할 수 있다.

한편, 상기 통지 메시지는 상기 시작 시간, 종료 시간, 시간 간격을 기반으로 송신될 수 있다.

한편, 상기 주기적인 통지는 상기 구독 자원의 속성으로 지시될 수 있다.

한편, 상기 속성은 <eventNotificationCriteria> 일 수 있다.

한편, 상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시되되 상기 컨디션 태그는 <notificationEventType>를 포함할 수 있다.

한편, 상기 시작 시간, 종료 시간, 시간 간격은 상기 구독 자원의 속성을 통해 표현될 수 있다.

한편, 상기 속성은 <eventNotificationCriteria> 일 수 있다.

한편, 상기 시작 시간, 종료 시간, 시간 간격은 상기 속성의 컨디션 태그로서 표현될 수 있다.

본 개시에 따른 M2M 시스템에서 주기적인 통지를 수신하는 방법은 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 생성하고 이를 다른 M2M 엔티티에 송신하는 단계, 상기 M2M 엔티티로부터 주기적으로 통지 메시지를 수신하는 단계를 포함하되, 상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 수신될 수 있다.

한편, 상기 통지 메시지는 상기 구독 요청 메시지에 의해 상기 특정 자원의 하위 자원으로 생성된 구독 자원을 기반으로 송신된 것일 수 있다.

한편, 상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함될 수 있다.

한편, 상기 통지 메시지는 상기 시작 시간, 종료 시간, 시간 간격을 기반으로 송신된 것일 수 있다.

한편, 상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시될 수 있다.

한편, 상기 속성은 <eventNotificationCriteria> 일 수 있다.

한편, 상기 구독 자원의 속성은 <eventNotificationCriteria> 일 수 있다.

본 개시에 따른 M2M 시스템에서 M2M 장치는 신호를 송수신하는 송수신부, 상기 송수신부를 제어하는 프로세서를 포함하되, 상기 프로세서는 M2M 엔티티로부터 특정 자원에 대한 구독 요청 메시지를 수신하고, 상기 M2M 엔티티에 주기적으로 통지 메시지를 송신하되 상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 송신될 수 있다.

본 개시에 따르면 M2M 시스템에서 자원의 변경 여부에 관계없이 주기적으로 통지를 송수신할 수 있다.

본 개시에 따르면 M2M 시스템에서 사용되는 자원이나 통지 절차의 변경을 최소화하여 주기적으로 통지를 송수신할 수 있다.

본 개시에 따르면 M2M 시스템에서 단일 이벤트에 의한 통지 시 이용되는 컨디션 태그(condition tag)와 동일한 컨디션 태그(condition tag)를 기반으로 주기적으로 통지를 송수신할 수 있다.

본 개시에 따르면 새로운 자원 및 새로운 속성의 정의 없이 주기적인 통지를 송수신할 수 있다.

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

도 1은 본 개시에 따른 M2M(Machine-to-Machine) 시스템의 계층 구조를 나타낸 도면이다.
도 2는 본 개시에 따른 M2M 시스템에서 기준점(reference point)을 나타낸 도면이다.
도 3은 본 개시에 따른 M2M 시스템에서 각각의 노드를 나타낸 도면이다.
도 4는 본 개시에 따른 M2M 시스템에서 공통 서비스 펑션을 나타낸 도면이다.
도 5는 본 개시에 따른 M2M 시스템에서 송신자 및 수신자가 메시지를 교환하는 방법을 나타낸 도면이다.
도 6은 본 개시의 일 실시예에 따른 M2M 시스템에서 구독 자원의 속성과 자식 자원을 나타낸 도면이다.
도 7은 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지가 수행되는 과정을 나타낸 도면이다.
도 8은 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지 송신 순서도를 나타낸 도면이다.
도 9는 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지 수신 순서도를 나타낸 도면이다.
도 10은 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지를 송수신하는 M2M 장치를 나타낸 도면이다.

이하에서는 첨부한 도면을 참고로 하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.

본 개시에 있어서, 제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용되며, 특별히 언급되지 않는 한 구성요소들간의 순서 또는 중요도 등을 한정하지 않는다. 따라서, 본 개시의 범위 내에서 일 실시 예에서의 제1 구성요소는 다른 실시 예에서 제2 구성요소라고 칭할 수도 있고, 마찬가지로 일 실시 예에서의 제2 구성요소를 다른 실시 예에서 제1 구성요소라고 칭할 수도 있다.

본 개시에 있어서, 어떤 구성요소가 다른 구성요소와 "연결", "결합" 또는 "접속"되어 있다고 할 때, 이는 직접적인 연결관계뿐만 아니라, 그 중간에 또 다른 구성요소가 존재하는 간접적인 연결관계도 포함할 수 있다. 또한 어떤 구성요소가 다른 구성요소를 "포함한다" 또는 "가진다"고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 배제하는 것이 아니라 또 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

본 개시에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시 예도 본 개시의 범위에 포함된다.

본 개시에 있어서, 다양한 실시 예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들은 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시 예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시 예도 본 개시의 범위에 포함된다. 또한, 다양한 실시 예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시 예도 본 개시의 범위에 포함된다.

본 개시의 실시 예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 개시에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

또한 본 명세서는 M2M(Machine-to-Machine) 통신에 기초한 네트워크에 대해 설명하며, M2M 통신 네트워크에서 이루어지는 작업은 해당 통신 네트워크를 관할하는 시스템에서 네트워크를 제어하고 데이터를 송신하는 과정에서 이루어질 수 있다.

또한, 본 명세서에서 M2M 단말은 M2M 통신을 수행하는 단말일 수 있으나, 호환성(Backward Compatibility)을 고려하여 무선 통신 시스템에서 동작하는 단말일 수 있다. 즉, M2M 단말은 M2M 통신 네트워크에 기초하여 동작될 수 있는 단말을 의미할 수 있으나, M2M 통신 네트워크로 한정되는 것은 아니다. M2M 단말은 다른 무선 통신 네트워크에 기초하여 동작하는 것도 가능할 수 있으며, 상술한 실시 예로 한정되지 않는다.

또한, M2M 단말은 고정되거나 이동성을 가질 수 있다. 또한, M2M 서버는 M2M 통신을 위한 서버를 지칭하며 고정국(fixed station) 또는 이동국(mobile station)일 수 있다.

또한, 본 명세서에서 엔티티는 M2M 장치, M2M 단말, M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭할 수 있다. 또한, 일 예로, 엔티티는 M2M 시스템의 계층 구조에서 소프트웨어적인 구성을 지칭하는데 사용할 수 있으며, 상술한 실시 예로 한정되지 않는다.

또한, 일 예로, 본 발명은 M2M 시스템을 중심으로 설명되지만 본 발명은 M2M 시스템에만 제한적으로 적용되는 것은 아니다.

또한, M2M 서버는 M2M 단말 또는 다른 M2M 서버와 통신을 수행하는 서버일 수 있다. 또한, M2M 게이트웨이는 M2M 단말과 M2M 서버를 연결하는 연결점 역할을 수행할 수 있다. 일 예로, M2M 단말과 M2M 서버의 네트워크가 상이한 경우, M2M 게이트웨이를 통해 서로 연결될 수 있다. 이때, 일 예로, M2M 게이트웨이, M2M 서버 모두 M2M 단말일 수 있으며, 상술한 실시 예로 한정되지 않는다.

oneM2M은 에너지, 교통, 국방, 공공서비스 등 산업별로 종속적이고 폐쇄적으로 운영되는, 파편 화된 서비스 플랫폼 개발 구조를 벗어나 응용서비스 인프라(플랫폼) 환경을 통합하고 공유하기 위한 사물인터넷 공동서비스 플랫폼 개발을 위해 발족된 사실상 표준화 단체이다. oneM2M은 사물통신, IoT(Internet of Things) 기술을 위한 요구사항, 아키텍처, API(Application Program Interface) 사양, 보안 솔루션, 상호 운용성을 제공하고자 한다. 예를 들어, oneM2M의 사양은 스마트 시티, 스마트 그리드, 커넥티드 카, 홈 오토메이션, 치안, 건강과 같은 다양한 어플리케이션과 서비스를 지원하는 프레임워크를 제공한다. 이를 위해, oneM2M은 모든 어플리케이션들 사이에 데이터의 교환 및 공유를 위한 단일 수평 플랫폼을 정의하는 표준들의 집합을 개발해왔다. oneM2M에서 고려하는 어플리케이션들은 상이한 산업 부문들에 걸친 어플리케이션들도 포함할 수 있다. oneM2M은, 운영 체제처럼, 상이한 기술들과 연동하기 위한 프레임워크를 제공함으로써, 단일화를 촉진하는 분산된 소프트웨어 레이어를 생성하고 있다. 분산된 소프트웨어 레이어는 M2M 어플리케이션들과 데이터 전송을 제공하는 통신 HW(Hardware)/SW(Software) 사이에 위치하는 공통 서비스 계층에서 구현된다. 예를 들어, 공통 서비스 계층은 도 1과 같은 계층 구조의 일부를 차지할 수 있다.

도 1은 본 개시에 따른 M2M(Machine-to-Machine) 시스템의 계층 구조(layered structure)를 나타낸 도면이다.

도 1를 참조하면, M2M 시스템의 계층 구조는 어플리케이션 계층(110), 공통 서비스 계층(120), 네트워크 서비스 계층(120)으로 구성될 수 있다. 이때, 어플리케이션 계층(110)은 구체적인 어플리케이션에 기초하여 동작하는 계층일 수 있다. 일 예로, 어플리케이션은 차량 추적 어플리케이션(fleet tracking application), 원거리 혈당 모니터링 어플리케이션(remote blood sugar monitoring application), 전략 계량 어플리케이션(power metering application) 또는 제어 어플리케이션(controlling application) 등일 수 있다. 즉, 어플리케이션 계층은 구체적인 어플리케이션에 대한 계층일 수 있다. 이때, 어플리케이션 계층에 기초하여 동작하는 엔티티는 어플리케이션 엔티티(Application Entity, AE)일 수 있다.

공통 서비스 계층(120)은 공통 서비스 펑션(Common Service Function, CSF)에 대한 계층일 수 있다. 일 예로, 공통 서비스 계층(120)은 데이터 관리(Data Management), 단말 관리(Device Management), M2M 서비스 구독 관리(M2M Service Subscription Management), 위치 서비스(Location Services) 등과 같이 공통 서비스 제공에 대한 계층일 수 있다. 일 예로, 공통 서비스 계층(120)에 기초하여 동작하는 엔티티는 공통 서비스 엔티티(Common Service Entity, CSE)일 수 있다.

공통 서비스 계층(120)은 기능에 의해 CSF로 그룹화되는 서비스들의 집합을 제공할 수 있다. 다수의 인스턴스화 된 CSF들은 CSE들을 형성한다. CSE들은 어플리케이션들(예: oneM2M 명명법에서 어플리케이션 엔티티들 또는 AE들), 다른 CSE들 및 기저 네트워크들(예: oneM2M 명명법에서 네트워크 서비스 엔티티 또는 NSE)과 인터페이스할 수 있다.

네트워크 서비스 계층(120)은 장치 관리(device management), 위치 서비스(location service) 및 장치 트리거링(device triggering)과 같은 서비스들을 공통 서비스 계층(120)에 제공할 수 있다. 이때, 네트워크 계층(120)에 기초하여 동작하는 엔티티는 네트워크 서비스 엔티티(Network Service Entity, NSE)일 수 있다.

도 2는 본 개시에 따른 M2M 시스템에서 기준점(reference point)을 나타낸 도면이다.

도 2를 참조하면, M2M 시스템 구조는 필드 도메인(Field Domain) 및 인프라스트럭쳐 도메인(Infrastructure Domain)으로 구별될 수 있다. 이때, 각각의 도메인에서 각각의 엔티티들은 기준점(예: Mca, 또는 Mcc)을 통해 통신을 수행할 수 있다. 일 예로, 기준점(reference point)은 각각의 엔티티들 간의 통신 흐름을 나타낼 수 있다. 이때, 도 2를 참조하면, AE(210 또는 240)와 CSE(220 또는 250) 사이의 기준점인 Mca 기준점, 서로 다른 CSE 사이의 기준점인 Mcc 기준점 및 CSE(220 또는 250)와 NSE(230 또는 260) 사이의 기준점인 Mcn 기준점이 설정될 수 있다.

도 3은 본 개시에 따른 M2M 시스템에서 각각의 노드를 나타낸 도면이다.

도 3을 참조하면, 특정 M2M 서비스 제공자의 인프라스트럭쳐 도메인은 특정 인프라스트럭처 노드(310, Infrastructure Node, IN)를 제공할 수 있다. 이때, IN의 CSE는 다른 인프라스트럭쳐 노드의 AE와 Mca 기준점에 기초하여 통신을 수행할 수 있다. 이때, 하나의 M2M 서비스 제공자마다 하나의 IN이 설정될 수 있다. 즉, IN은 인프라스트럭쳐 구조에 기초하여 다른 인프라스트럭쳐의 M2M 단말과 통신을 수행하는 노드일 수 있다. 또한, 일 예로, 노드의 개념은 논리적 엔티티일 수 있으며, 소프트웨어적인 구성일 수 있다.

다음으로, 어플리케이션 지정 노드(320, Application Dedicated Node, ADN)는 적어도 하나의 AE를 포함하고, CSE를 포함하지 않는 노드일 수 있다. 이때, ADN은 필드 도메인에서 설정될 수 있다. 즉, ADN은 AE에 대한 전용 노드일 수 있다. 일 예로, ADN은 하드웨어적으로 M2M 단말에 설정되는 노드일 수 있다. 또한, 어플리케이션 서비스 노드(330, Application Service Node, ASN)는 하나의 CSE와 적어도 하나의 AE를 포함하는 노드일 수 있다. ASN은 필드 도메인에서 설정될 수 있다. 즉, AE 및 CSE를 포함하는 노드일 수 있다. 이때, ASN은 IN과 연결되는 노드일 수 있다. 일 예로, ASN은 하드웨어적으로 M2M 단말에 설정되는 노드일 수 있다.

또한, 미들 노드(340, Middle Node, MN)은 CSE를 포함하고, 0개 또는 그 이상의 AE를 포함하는 노드일 수 있다. 이때, MN은 필드 도메인에서 설정될 수 있다. MN은 다른 MN 또는 IN과 기준점에 기초하여 연결될 수 있다. 또한 일 예로, MN은 하드웨어적으로 M2M 게이트웨이에 설정될 수 있다.

또한, 일 예로, 논-M2M 단말 노드(350, Non-M2M device node, NoDN)은 M2M 엔티티들을 포함하지 않은 노드로서 M2M 시스템과 관리나 협업 등을 수행하는 노드일 수 있다.

도 4는 본 개시에 따른 M2M 시스템에서 공통 서비스 펑션을 나타낸 도면이다.

도 4를 참조하면, 공통 서비스 펑션들이 제공될 수 있다. 일 예로, 공통 서비스 엔티티는 어플리케이션 및 서비스 계층 관리(402, Application and Service Layer Management), 통신 관리 및 전달 처리(404, Communication Management and Delivery Handling), 데이터 관리 및 저장(406, Data Management and Repository), 장치 관리(408, Device Management), 발견(410, Discovery), 그룹 관리(412, Group Management), 위치(414, Location), 네트워크 서비스 노출/서비스 실행 및 트리거링(416, Network Service Exposure/ Service Execution and Triggering), 등록(418, Registration), 보안(420, Security), 서비스 과금 및 계산(422, Service Charging and Accounting), 서비스 세션 관리 기능(Service Session Management) 및 구독/통지(424, Subscription/Notification) 중 적어도 어느 하나 이상의 CSF을 제공할 수 있다. 이때, 공통 서비스 펑션에 기초하여 M2M 단말들이 동작할 수 있다. 또한, 공통 서비스 펑션은 다른 실시 예도 가능할 수 있으며, 상술한 실시 예로 한정되지 않는다.

어플리케이션 및 서비스 계층 관리(402) CSF는 AE들 및 CSE들의 관리를 제공한다. 어플리케이션 및 서비스 계층 관리(402) CSF는 CSE의 기능들을 구성하고, 문제 해결하고, 및 업그레이드하는 것뿐만 아니라, AE들을 업그레이드하는 능력들을 포함한다.

통신 관리 및 전달 처리(404) CSF는 다른 CSE들, AE들, 및 NSE들과의 통신들을 제공한다. 통신 관리 및 전달 처리(404) CSF는 어떤 시간 및 어느 통신 연결로 통신들을 전달할지를 결정하고, 필요하고 허용되는 경우 그것들이 나중에 전달될 수 있도록 통신들 요청을 버퍼링하기로 결정한다.

데이터 관리 및 저장(406) CSF는 데이터 저장 및 중재 기능들(예: 집결을 위한 데이터 수집, 데이터 리포맷팅, 및 분석 및 시멘틱 처리를 위한 데이터 저장)을 제공한다.

장치 관리(408) CSF는 M2M 게이트웨이들 및 M2M 디바이스들 상에서 디바이스 능력들의 관리를 제공한다.

발견(410) CSF는 필터 기준들에 기초하여 어플리케이션들 및 서비스들에 대한 정보를 검색하는 기능을 제공한다.

그룹 관리(412) CSF는 그룹 관련 요청들의 처리를 제공한다. 그룹 관리(412) CSF는 M2M 시스템이 여러 디바이스들, 어플리케이션들 등에 대한 대량 작업들(bulk operations)을 지원하는 것을 가능하게 한다.

위치(414) CSF는 AE들이 지리적 장소 정보를 획득하는 것을 가능하게 하는 기능을 제공한다.

네트워크 서비스 노출/서비스 실행 및 트리거링(416) CSF는 네트워크 서비스 기능들에 액세스하기 위한 기저 네트워크들과의 통신들을 관리한다.

등록(418) CSF는 AE들(또는 다른 원격 CSE들)이 CSE에 등록하기 위한 기능을 제공한다. 등록(418) CSF는 AE들(또는 원격 CSE)이 CSE의 서비스들을 사용하는 것을 허용한다.

보안(420) CSF는 식별, 인증, 및 허가를 포함하는 액세스 제어와 같은 서비스 레이어에 대한 보안 기능들을 제공한다.

서비스 과금 및 계산(422) CSF는 서비스 레이어에 대한 과금 기능들을 제공한다.

구독/통지(424) CSF는 이벤트에 가입하는 것을 허용하고, 해당 이벤트가 발생할 때 통지되는 기능을 제공한다.

도 5는 본 개시에 따른 M2M 시스템에서 송신자 및 수신자가 메시지를 교환하는 방법을 나타낸 도면이다.

도 5를 참조하면, 송신자(Originator, 510)는 요청 메시지를 수신자(Receiver, 520)로 전송할 수 있다. 이때, 송신자(510)와 수신자(520)는 상술한 M2M 단말일 수 있다. 다만, M2M 단말에 한정되지 않고, 송신자(510)와 수신자(520)는 다른 단말일 수 있으며, 상술한 실시 예로 한정되지 않는다. 또한, 일 예로, 송신자(510) 및 수신자(520)는 상술한 노드, 엔티티, 서버 또는 게이트웨이일 수 있다. 즉, 송신자(510) 및 수신자(520)는 하드웨어적인 구성 또는 소프트웨어적인 구성일 수 있으며, 상술한 실시 예로 한정되지 않는다.

이때, 일 예로, 송신자(510)가 전송하는 요청 메시지에는 적어도 하나의 파라미터가 포함될 수 있다. 이때, 일 예로, 파라미터는 필수 파라미터 또는 선택 파라미터가 있을 수 있다. 일 예로, 송신단과 관련된 파라미터, 수신단과 관련된 파라미터, 식별 파라미터 및 동작 파라미터 등은 필수적인 파라미터일 수 있다. 또한, 그 밖에 다른 정보에 대해서는 선택 파라미터일 수 있다. 이때, 송신단 관련 파라미터는 송신자(510)에 대한 파라미터일 수 있다. 또한, 수신단 관련 파라미터는 수신자(520)에 대한 파라미터일 수 있다. 또한, 식별 파라미터는 상호 간의 식별을 위해 요구되는 파라미터일 수 있다.

또한, 동작 파라미터는 동작을 구분하기 위한 파라미터일 수 있다. 일 예로, 동작 파라미터는 생성(Create), 조회(Retrieve), 갱신(Update), 삭제(Delete) 및 통지(Notify) 중 적어도 어느 하나로 설정될 수 있다. 즉, 동작을 구별하기 위한 파라미터일 수 있다.

이때, 수신자(520)는 송신자(510)로부터 요청 메시지를 수신하면 해당 요청 메시지를 처리할 수 있다. 일 예로, 수신자(520)는 요청 메시지에 포함된 동작을 수행할 수 있으며, 이를 위해 파라미터가 유효한지 여부 및 권한이 있는지 여부 등을 판단할 수 있다. 이때, 수신자(520)는 파라미터가 유효하고, 권한이 있다면 요청 대상이 되는 자원 존재하는지 여부를 확인하고, 이에 기초하여 프로세싱을 수행할 수 있다.

일 예로, 이벤트가 발생하는 경우, 송신자(510)는 수신자(520)에게 통지에 대한 파라미터를 포함하는 요청 메시지를 전송할 수 있다. 수신자(520)는 요청 메시지에 포함된 통지에 대한 파라미터를 확인하고, 이에 기초하여 동작을 수행할 수 있으며, 응답 메시지를 송신자(510)로 다시 전송할 수 있다.

도 5와 같은 요청 메시지 및 응답 메시지를 이용한 메시지 교환 절차는 Mca 기준점에 기반하여 AE 및 CSE 간 또는 Mcc 기준점에 기반하여 CSE들 간 수행될 수 있다. 즉, 송신자(510)는 AE 또는 CSE이고, 수신자(520)는 AE 또는 CSE일 수 있다. 요청 메시지 내의 동작에 따라, 도 5와 같은 메시지 교환 절차는 AE 또는 CSE에 의해 시작될(initiated) 수 있다.

기준점 Mca 및 Mcc를 통한 요청자로부터 수신자로의 요청은 적어도 하나의 필수적인(mandatory) 파라미터를 포함하고, 적어도 하나의 선택적인(optional) 파라미터를 포함할 수 있다. 즉, 정의된 각 파라미터는 요청되는 동작(operation)에 따라 필수적이거나 선택적일 수 있다. 예를 들어, 응답 메시지는 이하 <표 1>에 나열된 파라미터들 중 적어도 하나를 포함할 수 있다.

Response message parameter/success or not

Response Status Code - successful, unsuccessful, ack

Request Identifier - uniquely identifies a Request message

Content - to be transferred

To - the identifier of the Originator or the Transit CSE that sent the corresponding non-blocking request

From - the identifier of the Receiver

Originating Timestamp - when the message was built

Result Expiration Timestamp - when the message expires

Event Category - what event category shall be used for the response message

Content Status

Content Offset

Token Request Information

Assigned Token Identifiers

Authorization Signature Request Information

Release Version Indicator - the oneM2M release version that this response message conforms to

요청 메시지 또는 응답 메시지에서 사용될 수 있는 필터 기준 조건(filter criteria condition)은 이하 <표 2> 및 <표 3>과 같이 정의될 수 있다.

Condition tag	Multip-licity	Description
Matching Conditions
createdBefore	0..1	The creationTime attribute of the matched resource is chronologically before the specified value.
createdAfter	0..1	The creationTime attribute of the matched resource is chronologically after the specified value.
modifiedSince	0..1	The lastModifiedTime attribute of the matched resource is chronologically after the specified value.
unmodifiedSince	0..1	The lastModifiedTime attribute of the matched resource is chronologically before the specified value.
stateTagSmaller	0..1	The stateTag attribute of the matched resource is smaller than the specified value.
stateTagBigger	0..1	The stateTag attribute of the matched resource is bigger than the specified value.
expireBefore	0..1	The expirationTime attribute of the matched resource is chronologically before the specified value.
expireAfter	0..1	The expirationTime attribute of the matched resource is chronologically after the specified value.
labels	0..1	The labels attribute of the matched resource matches the specified value.
labelsQuery	0..1	The value is an expression for the filtering of labels attribute of resource when it is of key-value pair format. The expression is about the relationship between label-key and label-value which may include equal to or not equal to, within or not within a specified set etc. For example, label-key equals to label value, or label-key within {label-value1, label-value2}. Details are defined in [3]
childLabels	0..1	A child of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3].
parentLabels	0..1	The parent of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3].
resourceType	0..n	The resourceType attribute of the matched resource is the same as the specified value. It also allows differentiating between normal and announced resources.
childResourceType	0..n	A child of the matched resource has the resourceType attribute the same as the specified value.
parentResourceType	0..1	The parent of the matched resource has the resourceType attribute the same as the specified value.
sizeAbove	0..1	The contentSize attribute of the <contentInstance> matched resource is equal to or greater than the specified value.
sizeBelow	0..1	The contentSize attribute of the <contentInstance> matched resource is smaller than the specified value.
contentType	0..n	The contentInfo attribute of the <contentInstance> matched resource matches the specified value.
attribute	0..n	This is an attribute of resource types (clause 9.6). Therefore, a real tag name is variable and depends on its usage and the value of the attribute can have wild card . E.g.　creator of container resource type can be used as a filter criteria tag as "creator=Sam", "creator=Sam", "creator=*Sam".
childAttribute	0..n	A child of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above.
parentAttribute	0..n	The parent of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above.
semanticsFilter	0..n	Both semantic resource discovery and semantic query use semanticsFilter to specify a query statement that shall be specified in the SPARQL query language [5]. When a CSE receives a RETRIEVE request including a semanticsFilter, and the Semantic Query Indicator parameter is also present in the request, the request shall be processed as a semantic query; otherwise, the request shall be processed as a semantic resource discovery.　 In the case of semantic resource discovery targeting a specific resource, if the semantic description contained in the <semanticDescriptor> of a child resource matches the semanticFilter, the URI of this child resource will be included in the semantic resource discovery result. 　 In the case of semantic query, given a received semantic query request and its query scope, the SPARQL query statement shall be executed over aggregated semantic information collected from the semantic resource(s) in the query scope and the produced output will be the result of this semantic query. 　 Examples for matching semantic filters in SPARQL to semantic descriptions can be found in [i.28].
filterOperation	0..1	Indicates the logical operation (AND/OR) to be used for different condition tags. The default value is logical AND.
contentFilterSyntax	0..1	Indicates the Identifier for syntax to be applied for content-based discovery.
contentFilterQuery	0..1	The query string shall be specified when contentFilterSyntax parameter is present.

Condition tag	Multip-licity	Description
Filter Handling Conditions
filterUsage	0..1	Indicates how the filter criteria is used. If provided, possible values are 'discovery' and 'IPEOnDemandDiscovery'. If this parameter is not provided, the Retrieve operation is a generic retrieve operation and the content of the child resources fitting the filter criteria is returned. If filterUsage is 'discovery', the Retrieve operation is for resource discovery (clause 10.2.6), i.e. only the addresses of the child resources are returned. If filterUsage is 'IPEOnDemandDiscovery', the other filter conditions are sent to the IPE as well as the discovery Originator ID. When the IPE successfully generates new resources matching with the conditions, then the resource address(es) shall be returned. This value shall only be valid for the Retrieve request targeting an <AE> resource that represents the IPE.
limit	0..1	The maximum number of resources to be included in the filtering result. This may be modified by the Hosting CSE. When it is modified, then the new value shall be smaller than the suggested value by the Originator.
level	0..1	The maximum level of resource tree that the Hosting CSE shall perform the operation starting from the target resource (i.e. To parameter). This shall only be applied for Retrieve operation. The level of the target resource itself is zero and the level of the direct children of the target is one.
offset	0..1	The number of direct child and descendant resources that a Hosting CSE shall skip over and not include within a Retrieve response when processing a Retrieve request to a targeted resource.
applyRelativePath	0..1	This attribute contains a resource tree relative path (e.g. ../tempContainer/LATEST). This condition applies after all the matching conditions have been used (i.e. a matching result has been obtained). The attribute determines the set of resource(s) in the final filtering result. The filtering result is computed by appending the relative path to the path(s) in the matching result. All resources whose Resource-IDs match that combined path(s) shall be returned in the filtering result. If the relative path does not represent a valid resource, the outcome is the same as if no match was found, i.e. there is no corresponding entry in the filtering result.

기준점 Mca 및 Mcc를 통한 자원으로의 접근(accessing)에 대한 요청에 대응한 응답은 적어도 하나의 필수적인(mandatory) 파라미터를 포함하고, 적어도 하나의 선택적인(optional) 파라미터를 포함할 수 있다. 즉, 정의된 각 파라미터는 요청되는 동작(operation) 또는 필수 응답 코드(mandatory response code)에 따라 필수적이거나 선택적일 수 있다. 예를 들어, 요청 메시지는 이하 <표 4>에 나열된 파라미터들 중 적어도 하나를 포함할 수 있다.

Request message parameter
Mandatory	Operation - operation to be executed / CREAT, Retrieve, Update, Delete, Notify
	To - the address of the target resource on the target CSE
	From - the identifier of the message Originator
	Request Identifier - uniquely identifies a Request message
Operation dependent	Content - to be transferred
Operation dependent	Resource Type - of resource to be created
Optional	Originating Timestamp - when the message was built
	Request Expiration Timestamp - when the request message expires
	Result Expiration Timestamp - when the result message expires
	Operational Execution Time - the time when the specified operation is to be executed by the target CSE
	Response Type - type of response that shall be sent to the Originator
	Result Persistence - the duration for which the reference containing the responses is to persist
	Result Content - the expected components of the result
	Event Category - indicates how and when the system should deliver the message
	Delivery Aggregation - aggregation of requests to the same target CSE is to be used
	Group Request Identifier - Identifier added to the group request that is to be fanned out to each member of the group
	Group Request Target Members-indicates subset of members of a group
	Filter Criteria - conditions for filtered retrieve operation
	Desired Identifier Result Type - format of resource identifiers returned
	Token Request Indicator - indicating that the Originator may attempt Token Request procedure (for Dynamic Authorization) if initiated by the Receiver
	Tokens - for use in dynamic authorization
	Token IDs - for use in dynamic authorization
	Role IDs - for use in role based access control
	Local Token IDs - for use in dynamic authorization
	Authorization Signature Indicator - for use in Authorization Relationship Mapping
	Authorization Signature - for use in Authorization Relationship Mapping
	Authorization Relationship Indicator - for use in Authorization Relationship Mapping
	Semantic Query Indicator - for use in semantic queries
	Release Version Indicator - the oneM2M release version that this request message conforms to.
	Vendor Information

일반 자원(normal resource)은 관리될 정보의 기저(base)를 구성하는 데이터의 표현(representation)의 완전한 집합을 포함한다. 가상(virtual) 또는 선언된(announced)이 아닌 한, 본 문서에서 자원 종류(type)는 일반 자원으로 이해될 수 있다.

가상 자원(virtual resource)은 처리(processing) 및/또는 검색 결과(retrieve result)를 트리거링하기 위해 사용된다. 하지만, 가상 자원은 CSE 내에서 영구적인(permanent) 표현을 가지지 아니한다.

선언된 자원(announced resource)은 오리지널(original) 자원의 속성들(attributes)의 집합을 포함한다. 오리지널 자원이 변화할 때, 선언된 자원은 오리지널 자원의 호스팅 CSE에 의해 자동적으로 갱신된다. 선언된 자원은 오리지널 자원으로의 링크(link)를 포함한다.

자원 선언(resource announcement)은 자원 발견(resource discovery)을 가능하게 한다. 원격(remote) CSE에서의 선언된 자원은 원격 CSE에서, 오리지널 자원의 자식(children)으로서 존재하지(present) 아니하거나 선언된 자식이 아닌, 자식 자원(child resource)을 생성하기 위해 사용될 수 있다.

자원의 선언을 지원하기 위해, 자원 템플릿(template) 내의 추가적인 열(column)이 관련된 선언된 자원 타입 내의 포함을 위해 선언될 속성을 특정할 수 있다. 각 선언된 <resourceType>에 대하여, 오리지널 <resourceType>으로의 접미사 'Annc'의 추가가 관련된 선언된 자원 종류를 지시하기 위해 사용될 수 있다. 예를 들어, 자원 <containerAnnc>는 <container> 자원을 위한 선언된 자원 종류를 지시할 수 있고, <groupAnnc>는 <group>을 위한 선언된 자원 종류를 지시할 수 있다.

자원들은 CSE와 관련하여 특정된다. 자원들은 oneM2M 시스템 내의 구성요소(component)들 및 원소(element)들의 CSE 내의 표현(representation)이다. 다른 CSE들, AE들, 센서를 나타내는 어플리케이션 데이터, 명령(command)들 등은 자원 표현의 수단으로서 CSE에게 알려진다.

자원은 oneM2M 구조(architecture)에서 고유하게 주소를 가지는(uniquely addressable) 엔티티이다. 자원은 전달되며, CRUD(Create Retrieve Update Delete) 동작을 이용하여 다루어질(manipulated) 수 있다.

자식(child) 자원은 부모(parent) 자원인 다른 자원의 하위(sub)-자원이다. 부모 자원은 적어도 하나의 자식 자원에 대한 참조(reference)를 포함한다.

어트리뷰트(attribute)는 자원에 관련된 정보를 저장한다. 어트리뷰트들의 집합은, 모든 자원들에 대하여 공통되지 아니하면, 자원의 그래픽적 표현 내에서 열거되지 아니한다.

어트리뷰트는 유니버셜 어트리뷰트(universal attribute), 공통 어트리뷰트(common attribute), 자원-특정 어트리뷰트(resource-specific attribute)로 구분된다. 유니버셜 어트리뷰트는 모든 자원에서 나타나는(appear) 어트리뷰트이며, 공통 어트리뷰트는 복수의 자원들에서 나타나며, 어디에서 나타나든 동일한 의미를 가지는 어트리뷰트이다.

가상 또는 선언되지 아니한, 일반이면서 모든 자원 종류들에 대하여 보편적인(universal) 어트리뷰트들의 예는 이하 <표 5>와 같다.

Attribute Name	Description
resourceType	Resource Type. This Read Only (assigned at creation time. and then cannot be changed) attribute identifies the type of the resource as specified in clause　9.6. Each resource shall have a resourceType attribute.
resourceID	This attribute is an identifier for the resource that is used for 'non-hierarchical addressing method', i.e. this attribute shall contain the 'Unstructured-CSE-relative-Resource-ID' format of a resource ID as defined in table 7.2-1. This attribute shall be provided by the Hosting CSE when it accepts a resource creation procedure. The Hosting CSE shall assign a resourceID which is unique in that CSE.
resourceName	This attribute is the name for the resource that is used for 'hierarchical addressing method' to represent the parent-child relationships of resources. See clause 7.2 for more details.This attribute may be provided by the resource creator. The Hosting CSE shall use a provided resourceName as long as it does not already exist among child resources of the targeted parent resource. If the resourceName already exists, the Hosting CSE shall reject the request and return an error to the Originator. The Hosting CSE shall assign a resourceName if one is not provided by the resource creator.
parentID	This attribute is the resourceID of the parent of this resource. The value of this attribute shall be NULL for the <CSEBase> resource type.
creationTime	Time/date of creation of the resource.This attribute is mandatory for all resources and the value is assigned by the system at the time when the resource is locally created. Such an attribute cannot be changed.
lastModifiedTime	Last modification time/date of the resource.The lastModifiedTime value is set by the Hosting CSE when the resource is created, and the lastModifiedTime value is updated when the resource is updated.

가상 또는 선언되지 아니한, 일반이면서 모두가 아닌 복수의 자원 종류들에서 공통적으로(commonly) 사용되는 어트리뷰트들의 예는 이하 <표 6>과 같다.

Attribute Name	Description
accessControlPolicyIDs	The attribute contains a list of identifiers for <accessControlPolicy> resources. The privileges defined in the <accessControlPolicy> resources that are referenced determine who is allowed to access the resource containing this attribute for a specific purpose (e.g.　Retrieve, Update, Delete, etc.). For an Update or Delete operation to a resource, the update or delete of the accessControlPolicyIDs attribute, if applicable, shall be performed prior to the update or delete of any other attributes of the resource. 　To update this attribute, a Hosting CSE shall check whether an Originator has Update privilege in any selfPrivileges, regardless of privileges, of the <accessControlPolicy> resources which this attribute originally references. After successful update of the accessControlPolicyIDs attribute, resource access checking for other attributes to be updated shall use the new privileges defined in the <accessControlPolicy> resource(s) that are referenced by the newly updated accessControlPolicyIDs attribute. 　Similarly, to delete this attribute, a Hosting CSE shall check whether an Originator has Updateprivilege in any selfPrivileges, regardless of privileges, of the <accessControlPolicy> resources which this attribute originally references. After successful deletion of the accessControlPolicyIDs attribute, resource access checking for other attributes to be deleted shall use the default access privileges as described in the following paragraphs. 　If a resource type does not have an accessControlPolicyIDs attribute definition, then the accessControlPolicyIDs for that resource is governed in a different way, for example, the accessControlPolicy associated with the parent may apply to a child resource that does not have an accessControlPolicyIDs attribute definition, or the privileges for access are fixed by the system. Refer to the corresponding resource type definitions and procedures to see how access control is handled in such cases. 　If a resource type does have an accessControlPolicyIDs attribute definition, but the (optional) accessControlPolicyIDs attribute value is not set in a resource instance, then the Hosting CSE shall apply the concept of the default access policy. The default policy shall provide unrestricted access only to the Originator of the successful resource creation request. All other entities shall be denied to access the resource. For that purpose, the Hosting CSE shall keep that Originator information of the resource. Note that how to keep that information is implementation specific. The default access policy is not applied to a resource which has a value assigned to the accessControlPolicyIDs　attribute. 　All resources are accessible if and only if the privileges (i.e. configured as privileges or selfPrivileges attribute of <accessControlPolicy> resource) allow it, therefore all resources shall have an associated accessControlPolicyIDs attribute, either explicitly (setting the attribute in the resource itself) or implicitly (either by using the parent privileges or the system default policies). Which means that the system shall provide default access privileges in case that the Originator does not provide a specific accessControlPolicyIDs during the creation of the resource.
expirationTime	Time/date after which the resource will be deleted by the Hosting CSE. This attribute can be provided by the Originator, and in such a case it will be regarded as a hint to the Hosting CSE on the lifetime of the resource. The Hosting CSE shall configure the expirationTime value. If the Hosting CSE configures the new expirationTime attribute value rather than the Originator suggested value, the new value can be sent back to the Originator depending on the Result Content value.The lifetime of the resource can be extended by providing a new value for this attribute in an UPDATE operation. Or by deleting the attribute value, e.g. by updating the attribute with NULL when doing a full UPDATE, in which case the Hosting CSE can decide on a new value. If the Originator does not provide a value in the CREATE operation the system shall assign an appropriate value depending on its local policies and/or M2M service subscription agreements. A resource is known as 'obsolete' when the resource contains the attribute "expirationTime" and the lifetime of this resource has reached the value of this attribute. If the ‘obsolete’ resource had a reference to an Application Entity Resource ID, the Hosting CSE shall send a NOTIFY request to the IN-CSE, requesting to delete the entry from the <AEContactList> resource.
stateTag	An incremental counter of modification on the resource. When a resource is created, this counter is set to 0, and it will be incremented on every modification of the resource (see notes　1 and 2).
announceTo	This attribute may be included in a CREATE or UPDATE Request in which case it contains a list of addresses/CSE-IDs where the resource is to be announced. For the case that CSE-IDs are provided, the announced-to CSE shall decide the location of the announced resources based on the rules described in clause 9.6.26.　For the original resource, this attribute shall only be present if it has been successfully announced to other CSEs. This attribute maintains the list of the resource addresses to the successfully announced resources. Updates on this attribute will trigger new resource announcement or de-announcement. 　If announceTo attribute includes resource address(s), the present document does not provide any means for validating these address(s) for announcement purposes. It is the responsibility of the Hosting-CSE referenced by the resource address(s) to validate the access privileges of the originator of the Request that triggers the announcement.
announcedAttribute	This attributes shall only be present at the original resource if some Optional Announced (OA) type attributes have been announced to other CSEs. This attribute maintains the list of the announced Optional Attributes (OA type attributes) in the original resource. Updates to this attribute will trigger new attribute announcement if a new attribute is added or de-announcement if the existing attribute is removed.
labels	Tokens used to add meta-information to resources.This attribute is optional. The value of the labels attribute is a list of individual labels, each of them being: - Either a standalone label-key, used as a simple "tag", that can be used for example for discovery purposes when looking for particular resources that one can "tag" using that label-key - Or a composite element made of a label-key and a label-value, separated by a special character defined in [3]. The list of allowed characters in a label (and in label-keys and label-values) and separator characters is defined in [3], clause 6.3.3.
e2eSecInfo	Present in a resource representing an AE or CSE. Indicates the end-to-end security capabilities supported by the AE or CSE. May indicate supported end-to-end security frameworks. May also contains a certificate or credential identifier used by the AE or CSE. May include random values for use in end-to-end security protocols. The details of this attributes are described in oneM2M TS-0003 [2].This attribute is optional and if not present it means that the represented entity does not support oneM2M end-to-end security procedures.
DynamicAuthorizationConsultationIDs	This attribute contains a list of identifiers of <dynamicAuthorizationConsultation> resources. The information defined in a <dynamicAuthorizationConsultation> resource is used by a CSE for initiating consultation-based dynamic authorization requests. Consultation-based dynamic authorization is only performed for a targeted resource if and only if it is linked to an enabled <dynamicAuthorizationConsultation> resource. If the attribute is not set or has a value that does not correspond to a valid <dynamicAuthorizationConsultation> resource(s), or it refers to an <dynamicAuthorizationConsultation> resource(s) that is not reachable, then the dynamicAuthorizationConsultationIDs associated with the parent may apply to the child resource if present, or a system default <dynamicAuthorizationConsultation> may apply if present.

한편, 도 5는 M2M 시스템에서 구독 자원과 관련된 절차에도 적용될 수 있다.

M2M 시스템(예를 들어, oneM2M)에서는 자원의 변화에 따라 해당 자원의 변화에 관심이 있는 엔티티(Entity)가 해당 변화에 대한 통지(notification)를 구독(subscription)할 수 있다. 이 경우, 통지의 대상이 되는 자원의 변화는 통지 이벤트 기준(notification event criteria)에 따를 수 있으며, 통지를 구독하기 위해서는, 즉 통지를 수신하기 위하여는 구독을 위한 자원이 설정되어야 한다. 구독을 위한 자원은 구독 자원 또는 <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> 자원)은 자원 또는 자원의 속성에 대한 블로킹 업데이트(blocking "UPDATE")를 수행할 수 있다. 이 경우 통지 대상(notification target)에 "UPDATE" 요청에 대한 결과로서 통지가 전송될 수 있다.

각각의 구독 자원(예를 들어, <subscription> 자원)은 어떤 통지가 언제, 어떻게 수행될 지를 특정하는 통지 정책(notification policy)을 포함할 수 있다. 통지 정책은 CMDH 정책(Communication Management and Delivery Handling Policy)와 동시에 적용될 수 있다.

구독 자원(예를 들어. <subscription> 자원)이 삭제되고 구독자(Subscriber)에 의해 <subscriberURI> 속성이 제공되는 경우, 통지는 <subscriberURI> 속성에 의해 지시되는 구독자에게 전송될 수 있다.

구독 자원(예를 들어, <subscription> 자원)은 다양한 속성과 자식 자원을 가질 수 있다. 예를 들어, 구독 자원(예를 들어, <subscription> 자원)은 하기와 같은 자식 자원을 가질 수 있다.

Child Resource of <subscription>	Child Resource Type	Description
notificationSchedule	<schedule>	In the context of the <subscription> resource, the notificationSchedule specifies when notifications may be sent by the Hosting CSE to the notificationURI(s).

한편, 상기 표에 나타난 바와 같이 구독 자원(예, <subscription> 자원)은 자식 자원으로서 스케줄링 정보를 포함하는 스케줄링 자원(예, <schedule>) 자원을 가질 수 있다. 스케줄링 자원의 기능, 역할 및 용도(usage)는 연관된 자원 타입에 따라 달라질 수 있다. 예를 들어, 스케줄링 자원이 <node> 자원의 자식 자원에 해당하면, 기저 네트워크(underlying network)를 통해 통신할 수 있는 시간 주기를 지시할 수 있다. 이 때, 다양한 기저 네트워크가 지원되는 경우에는, 각각의 기저 네트워크에는 스케줄링 자원이 최대 하나 존재할 수 있다. 단일의 스케줄링 자원은 복수의 기저 네트워크를 위하여 사용될 수 있다. 또한, <node> 자원의 자식 자원인 <cmdhNwAccessRule>의 <mgmtLink> 속성은 해당 <node> 자원의 다른 자식자원 <schedule>과 링크될 수 있으며, 스케줄링 자원이 자원 <CSEBase>의 자식 자원인 경우, CSE가 처리(processing)를 수행할 수 있을 것으로 예상되는 시간을 지시할 수 있다. 한편, 통지(notification) 대상(target)에 알림이 전송될 수 있을 때 구독 자원의 자식 자원인 스케줄링 자원은 시간 주기를 지시할 수 있다. 예를 들어, 스케줄링 자원(예를 들어, <schedule>)은 하기 표 8과 같은 속성(attribute)을 가질 수 있다.

Attributes of <schedule>	Multiplicity	RW/RO/WO	Description
scheduleElement	1 (L)	RW	Each item of the scheduleElement list shall be composed from seven fields of second, minute, hour, day of month, month, day of week and year.
networkCoordinated	0..1	RW	Indicates if IN-CSE shall perform schedule coordination with an Underlying Network. This attribute is only applicable when <schedule> is a child resource of <node>. The supported values are: - True: The IN-CSE shall perform schedule coordination. - False: The IN-CSE may not perform schedule coordination. NOTE: The schedule coordination is also subject to IN-CSE local policy.

한편, 구독 자원(예를 들어, <subscription> 자원)은 하기와 같은 표 9의 속성(attribute)을 가질 수 있다.

Attribute Name	Description
resourceType	Resource Type.
resourceID	This attribute is an identifier for the resource that is used for 'non-hierarchical addressing method', i.e. this attribute shall contain the 'Unstructured-CSE-relative-Resource-ID' format of a resource ID as defined in table 7.2-1. This attribute shall be provided by the Hosting CSE when it accepts a resource creation procedure. The Hosting CSE shall assign a resourceID which is unique in that CSE.
parentID	The system shall assign the value to this attribute according to the parameters given in the CREATE Request.
expirationTime	Time/date after which the resource will be deleted by the hosting CSE. This attribute can be provided by the issuer, and in such a case it will be regarded as a hint to the hosting CSE on the lifetime of the resource.
creationTime	Time/date of creation of the resource.
lastModifiedTime	Last modification time/date of the resource.
accessControlPolicyIDs	The attribute contains a list of identifiers (either an ID or a URI depending if it is a local resource or not) of an <accessControlPolicy> resource. The privileges defined in the <accessControlPolicy> resource that are referenced determine who is allowed to access the resource containing this attribute for a specific purpose (e.g., Retrieve, Update, Delete, etc).
notificationCriteria	When notification events happen on the subscribed-to resource, the list of notification events that match the notification criteria shall be sent as a Notify request.
expirationCounter	When the number of notifications becomes the same as this counter, the <subscription> resource shall be deleted. This attribute (notification policy) indicates that the subscriber wants to set the life of this subscription to a limit of a maximum number of notifications. When the number of notifications sent reaches the count of this counter, the <subscription> resource shall be deleted, regardless of any other policy.
notificationURI	List of URI(s) where the resource subscriber will receive notifications. This list of URI(s) may not represent the resource subscriber entity.
aggregationURI	URI to aggregate notifications from group members of a <group> resource.
batchNotify	Indicates that notifications should be batched for delivery. When set, notification events are temporarily stored until either a specified number is ready to send or until a duration after the first notification event has expired.
rateLimit	Indicates that notifications should be rate-limited. When set, notification events that exceed a specified number within a specified time are temporarily stored then sent when the number of events sent per specified time falls below the limit.
priorSubscriptionNotify	Indicates that when this subscription is created, whether notification events prior to subscription should be sent, e.g. send prior "n" notifications, if available.
notificationStoragePriority	Indicates a priority for this subscription relative to other subscriptions belonging to this same subscriber for retention of notification events when storage is congested.
notificationStructure	Type of information that shall be contained in notifications. E.g., modified attribute only of a subscribed-to resource, a whole subscribed-to resource, and/or URI of a corresponding <subscription> resource.
subscriberURI	URI that the <subscription> created entity can get notification from the <subscription> hosting CSE. <subscription> deletion shall be notified if this URI is provided.
eventNotificationCriteria	This attribute (notification policy) indicates the event criteria for which a notification is to be generated. When no eventNotificationCriteria attribute is present in a <subscription> resource, the Hosting CSE shall trigger notifications for this subscription when any of the attributes of the subscribed-to resource is modified.

표 9은 오로지 예시일 뿐이며 구독 자원의 속성은 표 9과 다르게 구성될 수 있다.

이 때, 상기 표 9의 속성 중 <eventNotificationCriteria>는 하기와 같은 <표 10>의 컨디션 태그(condition tag)를 가질 수 있다.

Condition tag	Matching Condition
createdBefore	The creationTime attribute of the resource is chronologically before the specified value.
createdAfter	The creationTime attribute of the resource is chronologically after the specified value.
modifiedSince	The lastModifiedTime attribute of the resource is chronologically after the specified value.
unmodifiedSince	The lastModifiedTime attribute of the resource is chronologically before the specified value.
stateTagSmaller	The stateTag attribute of the resource is smaller than the specified value.
stateTagBigger	The stateTag attribute of the resource is bigger than the specified value.
expireBefore	The expirationTime attribute of the resource is chronologically before the specified value.
expireAfter	The expirationTime attribute of the resource is chronologically after the specified value.
sizeAbove	The contentSize attribute of the <contentInstance> resource is equal to or greater than the specified value.
sizeBelow	The contentSize attribute of the <contentInstance> resource is smaller than the specified value.
notificationEventType	The type of event that shall trigger a notification. If multiple notificationEventType tags are present, a notification shall be triggered if any of the configured events occur. Note that not all permutations of event type are meaningful. Possible notification event type values are: A. Update to attributes of the subscribed-to resource B. Deletion of the subscribed-to resource, C. Creation of a direct child of the subscribed-to resource, D. Deletion of a direct child of the subscribed-to resource E. An attempt to retrieve a <contentInstance> direct-child-resource of a subscribed-to <container> resource is performed while this <contentInstance> child resource is an obsolete resource or the reference used for retrieving this resource is not assigned. This retrieval is performed by a RETRIEVE request targeting the subscribed-to resource with the Result Content parameter set to either "child-resources" or "attributes+child-resources". This value for the eventNotificationType tag implies that the subscribed-to resource shall be an <container> resource. Otherwise this setting is not valid. F Trigger Received targeting the MN/ASN-AE associated with the <AE> parent resource. This implies that the subscribed-to resource shall be an <AE> resource instance. Otherwise this setting is not valid.
G. Update to attributes of the subscribed-to resource with blocking of the triggering UPDATE operation. For this eventNotificationType value setting, only one single Notification Target shall be present in the notificationURI attribute - see notificationURI attribute definition. This value for the eventNotificationType tag shall not be combined with any other eventNotificationType tag value. This value for notificationEventType establishes a subscription that is triggered for the same events as for the value “Update to attributes of the subscribed-to resource”. However, upon occurrence of a triggering UPDATE operation that has been validated and results in an authorized UPDATE operation, the triggering UPDATE operation shall be blocked by the Hosting CSE until a notification request was sent out and a corresponding response message was received or a timeout happens. When the response status code of the notification response message indicates a successful notification reception in combination with a successful notification action taken by the Notification Target entity, the triggering UPDATE operation shall be completed with a successful update of the targeted attribute(s). If the notification response message indicates an unsuccessful notification reception or a successful notification reception with unsuccessful notification action by the targeted entity or times out, the blocked UPDATE operation shall be completed with no success and no change of the targeted attribute(s). For any subscribed-to resource there shall exist a maximum of one subscription with this setting of notificationEventType. All other notification policies shall not be allowed when this setting of notificationEventType is used. The notificationContentType shall be “modified attibutes”. When an UPDATE operation has been blocked due to triggering this type of notification, any other occurring UPDATE or DELETE requests to the same resource shall be handled only after the blocked UPDATE operation has been completed.

표 10은 오로지 예시일 뿐이며 <eventNotificationCriteria>의 컨디션 태그는 표 10과 다르게 구성될 수 있다.

도 6은 본 개시의 일 실시예에 따른 구독 자원의 속성과 자식 자원을 나타낸 도면이다. 보다 상세하게는, 상기에서 설명한 구독 자원과 그의 자식 자원 및 관련한 속성을 일 실시예로서 표현한 도면이다.

일 실시예로서 구독 자원(예를 들어, <subscription>)은 부모 자원일 수 있으며, 속성(attribute)으로서 통지가 수행될 수 있는 이벤트 타입을 나타내는 <eventNotificationCriteria> 속성과 <expirationCounter> 속성을 포함할 수 있다. 자식 자원으로서 스케줄링 자원(예를 들어, <schedule>)을 포함할 수 있으며, 스케줄링 자원(예를 들어, <schedule>)은 속성으로서 <scheduleElement>을 포함할 수 있다.

통지(notification)는 상기에서 언급한 바와 같은 특정 이벤트 기준에 부합하는 이벤트가 발생하는 경우에 수행될 수 있고, 어떠한 변화에도 불구하고 일정 주기로 이루어지는 경우에도 수행될 수 있다. 그럼에도 불구하고, 현재의 구독 자원(예를 들어, <subscription>)과 스케줄링 자원(예를 들어, <schedule>)은 통지 기준에 부합하는 자원의 변화 여부에 관계없는 주기적인 통지는 지원하지 못하고 있다.

일 실시예로서, 구독 자원(예를 들어, <subscription>)의 속성(attribute) 중 하나가 될 수 있는 <eventNotificationCriteria>는 구독 대상 자원(subscribed-to)의 변화가 발생하였음을 지시할 수 있다. 이 경우, 발생한 변화가 통지가 발생하는 이벤트 기준에 부합하는 경우에만, 통지 대상(notification target)으로의 통지(notification)가 발생할 수 있어, 주기적인 통지(periodic notification)를 기대하기 어렵다. 또한, 현재의 자식 자원인 스케줄링 자원(예를 들어, <schedule>)은 통지 대상으로의 통지가 가능한 시간 주기만을 지시할 수 있으며, 주기적인 통지를 지원하는 것은 아니다.

이에 따라, 본 개시에서는 M2M 시스템에서 주기적인 통지를 송수신하는 기술에 대하여 제안하고자 한다.

이하, 도면을 참조하여 하기에서 상세히 설명할 것이다.

도 7은 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지가 이루어지는 절차를 나타낸 도면이다.

일 실시예로서, M2M 시스템에는 M2M 엔티티 1(701), M2M 엔티티 2(702)가 포함될 수 있으며 엔티티 번호는 임의로 붙여진 것일 수 있다.

먼저, M2M 엔티티 1(701)는 주기적인 통지를 요청하는 메시지를 송신(710)할 수 있다. 상기의 주기적인 통지를 요청하는 메시지는 M2M 엔티티 2(702)에 송신될 수 있으며, 특정 자원에 대한 구독 요청 메시지에 포함될 수 있다. 구독 요청 메시지는 주기적인 통지를 요청하는 경우 주기적인 통지의 시작 시간(예를 들어, 오전 9시), 종료 시간(예를 들어, 오후 3시), 통지 간격(예를 들어, 매시간) 등을 포함할 수 있다.

메시지를 수신한 M2M 엔티티 2(702)는 로컬 프로세싱(711)을 수행할 수 있다. 일 실시예로서, 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신한 엔티티 2(702)는 로컬 프로세싱 단계에서 특정 자원의 자식 자원(혹은 하위 자원)으로서 구독 자원(예를 들어, <subscription>)을 생성할 수 있다. 생성된 구독 자원은 통지 정책을 지시하는 속성(attribute)을 포함할 수 있으며 예를 들어 <eventNotificationCriteria> 속성일 수 있다. 일 실시예로서, 상기 통지 정책을 지시하는 속성은 주기적인 통지 및 주기적인 통지가 이루어지는 주기에 대한 정보(예를 들어, 시작 시간, 종료 시간, 통지 간격)를 컨디션 태그(condition tag)로서 표현할 수 있다. 생성된 구독 자원은 통지를 받을 대상 및 구독 대상이 되는 정보의 정확한 범위를 포함할 수 있다.

로컬 프로세싱을 수행한 엔티티 2(702)는 엔티티 1(701)에 주기적으로 통지(통지 메시지)를 송신(712, 714, 715, 716)할 수 있다. 예를 들어, 통지 메시지(712, 714, 715, 716)는 상기에서 설명한 주기적인 통지의 시작 시간, 종료 시간, 통지 간격을 기반으로 송신될 수 있으며, 통지 간격(713)은 각 통지 메시지(712, 714, 715, 716)간 동일하게 유지될 수 있다.

한편, 엔티티 별, 즉 주체 별로 주기적인 통지가 수신되고 송신되는 방법 및 장치에 대하여는 하기에서 도 8 내지 도 10을 참조하여 더욱 상세하게 설명할 것이다.

도 8은 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지를 수행(송신)하는 방법에 대하여 나타낸 도면이다. 일 실시예로서, 상기 방법은 M2M 엔티티 간에 이루어지는 것일 수 있다.

일 실시예로서, 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신(S801)할 수 있다. 상기에서 언급한 바와 같이 특정 자원에 대한 구독 요청 메시지는 주기적인 통지를 요청하는 메시지를 포함할 수 있다. 또한 구독 요청 메시지는 주기적인 통지를 요청하는 경우 주기적인 통지의 시작 시간(예를 들어, 오전 9시), 종료 시간(예를 들어, 오후 3시), 통지 간격(예를 들어, 매시간) 등을 포함할 수 있다.

주기적으로 통지 메시지를 송신하기 전에, 상기 구독 요청 메시지가 수신되면, 상기 특정 자원의 하위 자원으로 구독 자원(예를 들어, <subscription>)을 생성할 수 있다. 상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함될 수 있다. 이는 생성된 구독 자원(예를 들어, <subscription>)의 속성(예를 들어, <eventNotificationCriteria>)의 컨디션 태그(condition tag)로서 표현될 수 있다. 이에 대하여는, 하기의 도 9에서 더욱 상세하게 설명할 것이다.

일 실시예로서, 상기 구독 요청 메시지에 따라 주기적으로 통지 메시지를 송신(S802)할 수 있다. 주기적인 통지 메시지는 구독 대상 자원(subscribed-to resource)에 대한 정보를 포함할 수 있으며, 구독 대상 자원에 변화가 발생하지 않더라도 송신될 수 있다. 또한, 상기에서 언급한 바와 같이 상기 통지 메시지는 상기 시작 시간, 종료 시간, 시간 간격을 기반으로 송신될 수 있다. 상기 주기적인 통지(통지 메시지)는 상기 구독 자원의 속성으로 지시될 수 있으며 예를 들어 <eventNotificationCriteria> 일 수 있다. 상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시되되 상기 컨디션 태그는 <notificationEventType>를 포함할 수 있다. 이에 대하여는, 하기의 도 9에서 더욱 상세하게 설명할 것이다.

한편, 상기에서 언급한 속성이나 자원, 컨디션 태그 등의 이름은 일 실시예에 해당하므로, 이에 한정되는 것은 아니다.

도 9는 본 개시의 일 실시예에 따른 M2M 시스템에서 주기적인 통지를 수신하는 방법에 대하여 나타낸 도면이다. 일 실시예로서, 상기 방법은 M2M 엔티티 간에 이루어지는 것일 수 있다.

일 실시예로서, 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 송신(S901)할 수 있다. 상기 구독 요청 메시지는 상기에서 언급한 바와 동일한 것일 수 있으며, 주기적인 통지 요청 메시지를 포함할 수 있으며, 상기 특정 자원의 하위 자원으로 구독 자원(예를 들어, <subscription>)을 생성할 수 있다. 또한, 상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함될 수 있다. 상기 구독 요청 메시지로 주기적인 통지가 요청되었음은 생성된 구독 자원(예를 들어, <subscription>)의 속성(에를 들어, <eventNotificationCriteria>)의 컨디션 태그(condition tag)(예를 들어, <notificationEventType>)로서 표현될 수 있다. 또한, 구독 요청 메시지에 포함될 수 있는 주기적인 통지의 시작 시간(예를 들어, 오전 9시), 종료 시간(예를 들어, 오후 3시), 통지 간격(예를 들어, 매시간)는, 생성된 구독 자원(예를 들어, <subscription>)의 속성(예를 들어, <eventNotificationCriteria>)의 컨디션 태그(condition tag)(예를 들어, periodNoti)로서 표현될 수 있다. 일 실시예로서, 컨디션 태그는 하기의 표 11와 같을 수 있다.

Condition tag	Matching condition
notificationEventType	The type of event that shall trigger a notification. If multiple notificationEventType tags are present, a notification shall be triggered if any of the configured events occur. Note that not all permutations of event type are meaningful. Possible notification event type values are: A. Update to attributes of the subscribed-to resource B. Deletion of the subscribed-to resource, C. Creation of a direct child of the subscribed-to resource, D. Deletion of a direct child of the subscribed-to resource E. An attempt to retrieve a <contentInstance> direct-child-resource of a subscribed-to <container> resource is performed while this <contentInstance> child resource is an obsolete resource or the reference used for retrieving this resource is not assigned. This retrieval is performed by a RETRIEVE request targeting the subscribed-to resource with the Result Content parameter set to either "child-resources" or "attributes+child-resources". This value for the eventNotificationType tag implies that the subscribed-to resource shall be an <container> resource. Otherwise this setting is not valid. F. Trigger Received targeting the MN/ASN-AE associated with the <AE> parent resource. This implies that the subscribed-to resource shall be an <AE> resource instance. Otherwise this setting is not valid. G. Update to attributes of the subscribed-to resource with blocking of the triggering UPDATE operation. For this eventNotificationType value setting, only one single Notification Target shall be present in the notificationURI attribute - see notificationURI attribute definition. This value for the eventNotificationType tag shall not be combined with any other eventNotificationType tag value. This value for notificationEventType establishes a subscription that is triggered for the same events as for the value "Update to attributes of the subscribed-to resource". However, upon occurrence of a triggering UPDATE operation that has been validated and results in an authorized UPDATE operation, the triggering UPDATE operation shall be blocked by the Hosting CSE until a notification request was sent out and a corresponding response message was received or a timeout happens. When the response status code of the notification response message indicates a successful notification reception in combination with a successful notification action taken by the Notification Target entity, the triggering UPDATE operation shall be completed with a successful update of the targeted attribute(s). If the notification response message indicates an unsuccessful notification reception or a successful notification reception with unsuccessful notification action by the targeted entity or times out, the blocked UPDATE operation shall be completed with no success and no change of the targeted attribute(s). For any subscribed-to resource there shall exist a maximum of one subscription with this setting of notificationEventType. All other notification policies shall not be allowed when this setting of notificationEventType is used. The notificationContentType shall be "modified attibutes". When an UPDATE operation has been blocked due to triggering this type of notification, any other occurring UPDATE or DELETE requests to the same resource shall be handled only after the blocked UPDATE operation has been completed. H. periodic reporting
periodNoti	The periodNoti includes three values: start time, end time and interval of periodic reporting. This condition tag is only applicable when notificationEventtype has a value of periodic reporting.

일 실시예로서, 구독 요청 메시지가 주기적인 통지를 요청함은 상기 <표 11>의 컨디션 태그 <notificationEventType>를 통해 표현될 수 있으며, 주기적인 통지의 시작 시간, 종료 시간, 통지 간격은 상기 <표 11>의 컨디션 태그 <periodNoti>로 표현될 수 있다. 이 경우 <periodNoti>는 <notificationEventType>가 주기적인 통지를 지시하는 경우에만 유효할 수 있다.

일 실시예로서, 상기 구독 요청 메시지에 따라 주기적으로 통지 메시지를 수신(S902)할 수 있다. 상기 통지 메시지는 상기 구독 요청 메시지에 의해 상기 특정 자원의 하위 자원으로 생성된 구독 자원을 기반으로 송신된 것일 수 있다. 또한, 상기 도 7 및 도 8에서 언급한 바와 같이 주기적인 통지 요청을 포함한 구독 요청 메시지를 수신한 M2M 엔티티는 구독 자원을 생성할 수 있는데, 상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함될 수 있다. 상기에서 언급한 바와 같이, 상기 통지 메시지는 상기 시작 시간, 종료 시간, 시간 간격을 기반으로 송신된 것일 수 있으며, 상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시될 수 있다.

도 10은 본 개시의 일 실시예에 따른 M2M 시스템에서 M2M 장치를 나타낸 도면이다. 보다 상세하게는, 도 10은 본 개시의 일 실시예로서 상기에서 언급한 주기적인 통지 메시지를 송수신하는 방법을 실행할 수 있는 M2M 장치이자, 주기적인 통지 메시지를 송수신하는 방법 및 장치를 실행하는 컴퓨팅 시스템을 도시한 것이다.

도 10을 참고하면, M2M 장치(1010)는 장치를 제어하는 프로세서(1012) 및 신호를 송수신하는 송수신부(1014)를 포함할 수 있다. 이때, 프로세서(1012)는 송수신부(1014)를 제어할 수 있다. 또한, M2M 장치(1010)는 다른 M2M 장치(1020)와 통신을 수행할 수 있다. 다른 M2M 장치(1020)도 프로세서(1024) 및 송수신부(1022)를 포함할 수 있으며, 프로세서(1024) 및 송수신부(1022)는 프로세서(1012) 및 송수신부(1014)와 동일한 기능을 수행할 수 있다.

일 실시예로서, 송수신부(1014, 1022)는 통신 모듈(communication module), 통신 유닛(communication unit)일 수 있으며, 제3자 엔티티, 즉 M2M 엔티티와 신호를 통신하는 기능을 수행할 수 있다. 이 때, 송수신부(1014, 1022)는 신호를 수신하는 기능만을 수행하거나, 송신하는 기능만을 수행할 수 있고, 송수신하는 기능 모두를 수행하는 것도 가능할 수 있다. 송수신 기능을 모두 수행하는 것으로 구현되는 경우, 통신부는 송신부, 수신부로 나뉘어 구현되는 것도 가능하며, 하나의 송수신부로 구현되는 것도 가능할 것이다.

또한, 프로세서(1012, 1024)는 송수신부 혹은 통신부를 제어하되, 다른 M2M 장치에 송신할 요청 메시지를 생성하고, 상기 생성된 요청 메시지를 상기 다른 M2M 장치로 송신하고, 상기 다른 M2M 장치로부터 상기 요청 메시지에 대한 응답 메시지를 수신할 수 있다. 이 때, 상기 요청 메시지는 다른 M2M 장치에 주기적인 통지를 요청하는 것일 수 있으며 응답 메시지는 주기적인 통지 메시지일 수 있다. 상기 요청 메시지가 주기적인 통지를 요청하는 경우, 상기 스케줄링 자원은 구독 자원의 자식 자원일 수 있다. 이는, 상기에서 언급한 바와 동일할 수 있다.

또한, 도 10의 장치들(1010 및 1020)은 다른 M2M 장치일 수 있다. 일 예로, 도 10의 장치들(1010 및 1020)은 통신을 수행하는 터미널, 단말, 장치, 자동차 또는 기지국, M2M 플랫폼에 위치한 장치 등과 같은 장치일 수 있다. 즉, 도 10의 장치들(1010 및 1020)은 통신을 수행할 수 있는 장치를 지칭하는 것으로 상술한 실시 예로 한정되지 않는다.

또한, 일 실시예로서, 도 10에는 생략되었으나, 보다 상세하게는, 도 10의 각 M2M 장치에는 RAM(Random Access Memory) 및 ROM(Read Only Memory) 을 포함하는 메모리와 프로세서, 사용자 인터페이스 입력 장치, 사용자 인터페이스 출력 장치, 스토리지, 네트워크 인터페이스, 버스를 포함할 수 있다.

본 개시에 따른 M2M 시스템에서 주기적인 통지를 송수신하는 방법, 장치 및 컴퓨팅 시스템에 의하면 단일 이벤트가 발생하여 통지 시 이용하는 자원, 속성, 컨디션 태그를 최대한 활용할 수 있다. 보다 상세하게는, 현재의 M2M 통신에서 사용되는 각종 사양(specification), 사용되는 데이터 및 절차의 변경을 최소화할 수 있다.

이에 따르면 주기적인 통지를 송수신할 때에도 단일 이벤트가 발생하는 경우의 통지 기준과 동일한 기준을 적용할 수 있어, 경제적이며 효율적이다.

또한, 주기적인 통지를 위한 별도의 새로운 자원을 정의 시 발생할 수 있는 문제점을 방지할 수 있다. 예를 들어, 별도의 자원이 정의되면 자원이 생성 및 이용되는 절차, 자원 업데이트 절차, 자원 검색, 조회 및 삭제 절차 등도 새로이 정립되어야 할 수 있다. 이는 각종 사양의 변경을 필요로 하여 비효율적일 수 있으나, 본 개시에서는 새로운 자원을 정의하지 않고 기 정의된 자원을 이용하는 바, 보다 효율적이다. 또한, 새로운 자원에 대한 새로운 속성 및/혹은 공통 속성 등을 정의하여야 할 필요가 없으므로, 추가적인 부담도 발생하지 않는다.

본 개시의 다양한 실시 예는 모든 가능한 조합을 나열한 것이 아니고 본 개시의 대표적인 양상을 설명하기 위한 것이며, 다양한 실시 예에서 설명하는 사항들은 독립적으로 적용되거나 또는 둘 이상의 조합으로 적용될 수도 있다.

또한, 본 개시의 다양한 실시 예는 하드웨어, 펌웨어(firmware), 소프트웨어, 또는 그들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 범용 프로세서(general processor), 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다. 예를 들어, 종단 혹은 엣지에서 사용될 수 있는 비 일시적 컴퓨터 판독가능한 매체에 저장된 프로그램의 형식이나, 엣지 혹은 클라우드에서 사용될 수 있는 비 일시적 컴퓨터 판독 가능한 매체에 저장된 프로그램의 형식으로도 구현될 수 있음은 자명하다.

본 개시의 범위는 다양한 실시 예의 방법에 따른 동작이 장치 또는 컴퓨터 상에서 실행되도록 하는 소프트웨어 또는 머신-실행 가능한 명령들(예를 들어, 운영체제, 애플리케이션, 펌웨어(firmware), 프로그램 등), 및 이러한 소프트웨어 또는 명령 등이 저장되어 장치 또는 컴퓨터 상에서 실행 가능한 비-일시적 컴퓨터-판독가능 매체(non-transitory computer-readable medium)를 포함한다.

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

그리고 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수 있다.

또한, 본 발명에 대하여 그 바람직한 실시 예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시 예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

1010: M2M 장치
1012: 프로세서
1014: 송수신부
1020: M2M 장치
1022: 송수신부
1024: 프로세서

Claims

M2M 시스템에서 주기적인 통지를 송신하는 방법에 있어서,
M2M 엔티티로부터 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신하는 단계;
상기 구독 요청 메시지에 따라 상기 M2M 엔티티에 주기적으로 통지 메시지를 송신하는 단계;를 포함하되,
상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 송신되는, 주기적인 통지를 송신하는 방법.
제1 항에 있어서,
상기 구독 요청 메시지가 수신되면,
상기 특정 자원의 하위 자원으로 구독 자원이 생성되고,
상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함되는, 주기적인 통지를 송신하는 방법.
제1 항에 있어서,
상기 구독 요청 메시지는 주기적인 통지를 위한 시작 시간, 종료 시간, 통지 간격을 포함하는, 주기적인 통지를 송신하는 방법.
제3 항에 있어서,
상기 통지 메시지는 상기 시작 시간, 종료 시간, 통지 간격을 기반으로 송신되는, 주기적인 통지를 송신하는 방법.
제2 항에 있어서,
상기 주기적인 통지는 상기 구독 자원의 속성으로 지시되는, 주기적인 통지를 송신하는 방법.
제5 항에 있어서,
상기 속성은 <eventNotificationCriteria> 인, 주기적인 통지를 송신하는 방법.
제6 항에 있어서,
상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시되되, 상기 컨디션 태그는 <notificationEventType>를 포함하는, 주기적인 통지를 송신하는 방법.
제3 항에 있어서,
상기 시작 시간, 종료 시간, 통지 간격은 상기 구독 자원의 속성을 통해 표현되는, 주기적인 통지를 송신하는 방법.
제8 항에 있어서,
상기 속성은 <eventNotificationCriteria> 인, 주기적인 통지를 송신하는 방법.
제9 항에 있어서,
상기 시작 시간, 종료 시간, 통지 간격은 상기 속성의 컨디션 태그로서 표현되는, 주기적인 통지를 송신하는 방법.
M2M 시스템에서 주기적인 통지를 수신하는 방법에 있어서,
특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 생성하고 M2M 엔티티에 송신하는 단계;
상기 M2M 엔티티로부터 주기적으로 통지 메시지를 수신하는 단계;를 포함하되,
상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 수신되는, 주기적인 통지를 수신하는 방법.
제11 항에 있어서,
상기 통지 메시지는 상기 구독 요청 메시지에 의해 상기 특정 자원의 하위 자원으로 생성된 구독 자원을 기반으로 송신된 것인, 주기적인 통지를 수신하는 방법.
제12 항에 있어서,
상기 구독 자원에는 상기 M2M 엔티티에 대한 정보와 구독 범위에 대한 정보가 포함되는, 주기적인 통지를 수신하는 방법.
제13 항에 있어서,
상기 구독 요청 메시지는 주기적인 통지를 위한 시작 시간, 종료 시간, 통지 간격을 포함하는, 주기적인 통지를 수신하는 방법.
제14 항에 있어서,
상기 통지 메시지는 상기 시작 시간, 종료 시간, 통지 간격을 기반으로 송신된 것인, 주기적인 통지를 수신하는 방법.
제15 항에 있어서,
상기 주기적인 통지는 상기 속성의 컨디션 태그(condition tag)로 지시되는, 주기적인 통지를 수신하는 방법.
제16 항에 있어서,
상기 속성은 <eventNotificationCriteria> 인, 주기적인 통지를 수신하는 방법.
제17 항에 있어서,
상기 시작 시간, 종료 시간, 통지 간격은 상기 구독 자원의 속성을 통해 표현되는, 주기적인 통지를 수신하는 방법.
제18 항에 있어서,
상기 구독 자원의 속성은 <eventNotificationCriteria> 인, 주기적인 통지를 수신하는 방법.
M2M 시스템에서 M2M 장치에 있어서,
신호를 송수신하는 송수신부;
상기 송수신부를 제어하는 프로세서;
를 포함하되,
상기 프로세서는
M2M 엔티티로부터 특정 자원에 대한 주기적인 통지를 요청하는 구독 요청 메시지를 수신하고,
상기 M2M 엔티티에 주기적으로 통지 메시지를 송신하되
상기 통지 메시지는 상기 특정 자원의 변경 여부에 관계없이 주기적으로 송신되는, M2M 장치.