KR20130129811A - Ｍ２ｍ 장치간 스케줄 폴링 방법 및 그 장치 - Google Patents

Abstract

본 명세서는 M2M 장치간 스케줄 폴링 방법 및 그 장치에 관한 것이다. 본 명세서에 따른 M2M 장치 간 스케줄 폴링 방법은, 클라이언트로 동작하는 M2M 객체에 있어서, 서버로 동작하는 별개의 M2M 객체가 관리하는 M2M 자원을 수신하기 위한 요청을 전송하는 단계, 서버로부터 M2M 자원 관리와 관련된 스케줄 정보를 포함하는 응답을 수신하는 단계, 및 스케줄 정보에 따라 M2M 자원을 수신하기 위한 새로운 요청을 전송하는 단계를 포함한다.

Description

Ｍ２Ｍ 장치간 스케줄 폴링 방법 및 그 장치{M2M communication entities and Scheduled Polling Method therebetween}

본 발명은 Ｍ2Ｍ 장치간 스케줄 폴링 방법 및 그 장치에 관한 것으로, 특히 사물 또는 사물간 통신인 M2M 장치 간의 통신에 있어서, 다양한 정보의 요청 및 수신을 위해 구현되는 M2M 장치간 스케줄 폴링 방법 및 그 장치에 관한 것이다.

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

이러한 사물 통신은 통신이 항상 연결될 것을 요구하지는 않는다. 또한 정보의 송수신에 있어서도 일정한 경우 요구가 있을 경우에 한하여 해당 정보가 송신되기도 한다.

ETSI TS 102 690 v1.1.1에 기술된 M2M 서비스 구조에 따르면, 클라이언트와 서버 간 자원을 요청하고 수신하는 커뮤니케이션 방법으로 현재 쇼트 폴링(short polling)과 롱 폴링(long polling) 방식이 제시되어 있다.

이러한 쇼트 폴링이나 롱 폴링은 정보의 종류에 관계없이 정보를 요청하는 측에서 설정된 시간 기준으로 또는 시간과는 무관한 방식으로 정보를 요청한다.

즉 현재 사물 통신에서는 정보를 요청하는 측이 아니라 정보를 송신하는 측의 정보 전송 여건 또는 정보의 종류에 따라 정보 전송 여건이 달라지는 환경에 따른 통신 방식은 제시되지 않고 있다.

본 발명에 따라 M2M 장치간 새로운 커뮤니케이션 방식으로 스케줄 폴링 방법및 그 장치를 제공한다.

전술한 과제를 실시하기 위하여 본 명세서에서는 정보를 송신하는 측의 정보 전송 여건 또는 정보의 종류에 따른 정보 전송 여건을 고려한 폴링 방법으로서, 예를 들면 주기적 방식의 자료수집 혹은 이벤트의 발생시각이 예측가능한 M2M 환경 등에 적합한 스케줄 폴링(scheduled polling) 방법 및 그 장치가 제공된다.

본 명세서의 일 실시예에 의한 M2M 장치 간 스케줄 폴링 방법은, 클라이언트로 동작하는 M2M 객체에 있어서, 서버로 동작하는 별개의 M2M 객체가 관리하는 M2M 자원을 수신하기 위한 요청을 전송하는 단계; 상기 서버로부터 상기 M2M 자원 관리와 관련된 스케줄 정보를 포함하는 응답을 수신하는 단계, 및 상기 스케줄 정보에 따라 상기 M2M 자원을 수신하기 위한 새로운 요청을 전송하는 단계를 포함한다.

본 명세서의 다른 실시예에 의한 스케줄 폴링 방법을 구현하는 M2M 장치는, 별개의 M2M 객체가 관리하는 M2M 자원을 수신하기 위한 요청을 작성하고 상기 요청에 대한 상기 별개의 M2M 객체로부터 응답이 수신되면 상기 응답으로부터 상기 M2M 자원 관리와 관련된 스케줄 정보를 추출하는 M2M 모듈, 및 상기 제어부에서 작성된 상기 요청을 전송하고 상기 요청에 대한 상기 응답을 수신하는 통신 모듈을 포함하며, 상기 M2M 모듈은 상기 스케줄 정보에 따라 상기 M2M 자원을 수신하기 위한 새로운 요청을 작성하여 상기 통신 모듈을 통해 전송하는 것을 특징으로 한다.

본 발명에서는 쇼트 폴링(short polling)과 롱 폴링(long polling)의 단점을 보완하여 M2M 네트워크의 트래픽을 줄이고, 특히 주기적 방식의 자료수집 혹은 이벤트의 발생시각이 예측가능한 M2M 환경에서 트래픽 부하를 획기적으로 줄일 수 있는 스케줄 폴링(scheduled polling) 방법이 구현된다.

본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 주기적 방식을 통한 자료 수집시 롱 폴링(long polling) 방식보다 효율적으로 자료를 수집할 수 있다. 특히, M2M 센서로부터의 보고 주기가 수시로 변경되는 환경에서의 자료 수집할 때 매우 효율적이다. 주기적 방식의 자료수집은 스마트 미터링(smart metering), 이헬스(eHealth), 도시자동화(city automation) 등의 응용분야에서 많이 사용되고 있다.

스케줄 폴링(scheduled polling)은 이벤트 발생시각이 예측 가능한 이벤트 방식에서도 효율적으로 사용될 수 있다. 이벤트 발생시각이 예측 가능한 방법으로는 Hosting SCL에서 년간/월간/주간/일간 이벤트 발생 시각 데이터를 축적한 후 평균 event 발생시각 데이터를 예측가능하다.

스케줄 폴링(scheduled polling)은 온디맨드 방식(on-demand reporting) 에서 M2M 센서가 어떤 장애로 인해 즉시보고를 할 수 없지만 보고 주기가 정해져 있거나 보고시점이 예측 가능할 때 효율적으로 사용될 수 있다,

스케줄 폴링(scheduled polling)은 구조가 단순하여 구현이 용이하다.

도 1은 ETSI TS 102 690에 제시된 쇼트 폴링(short polling)방식을 도시한 도면이다.
도 2는 ETSI TS 102 690에 제시된 롱 폴링(long polling)방식을 도시한 도면이다.
도 3은 본 발명이 적용되는 M2M 서비스 구조를 설명하기 위한 도면이다.
도 4는 본 발명의 일 실시예에 따른 스케줄 폴링 방법을 설명하기 위한 도면이다.
도 5는 본 발명의 다른 실시예에 따른 스케줄 폴링 방법을 설명하기 위한 도면이다.
도 6은 본 발명의 또 다른 실시예에 따른 스케줄 폴링 방법을 설명하기 위한도면이다.
도 7은 스케쥴 폴링(scheduled polling) 방법이 적용되는 M2M 환경을 보다 상세히 설명하기 위한 도면이다.
도 8은 본 발명에 따른 스케쥴 폴링 방법을 설명하기 위한 도면이다.
도 9는 본 발명에 따른 스케줄 폴링 방법이 적용되는 경우의 M2M 자원 구조의 일 예를 도시한 도면이다.
도 10은 본 발명에 따른 스케줄 폴링 방법이 적용되는 경우의 M2M 자원 구조의 또 다른 예를 도시한 도면이다.
도 11은 본 발명에 따른 스케줄 폴링 방법을 구현하는 M2M 장치의 일 예를 도시한 도면이다.

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

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

본 발명의 실시예들은 사물 통신을 중심으로 설명한다. 사물 통신은 앞서 살펴본 바와 같이 M2M, MTC, 스마트 디바이스 통신, 사물 지향 통신 등 다양한 분야를 포함하며, 본 명세서에서는 M2M을 중심으로 설명한다. 그러나 이러한 설명이 M2M에만 한정되는 것은 아니며, 기기간 통신, 즉 사물 통신을 제공하는 모든 시스템 및 구조와 이들 시스템에서 발생하는 통신에 적용 가능하다.

또한 이러한 사물 통신은 지능형 검침(Smart Meter), 전자 보건(e-Health), 통신 가전(Connected Consumer), 도시 자동화(City Automation), 차량 응용(Automotive Application) 등을 포함하는 다양한 분야에 적용될 수 있다.

도 1은 ETSI TS 102 690에 제시된 쇼트 폴링(short polling)방식을 보여주는 도면이다.

도면에서 보는 바와 같이 ETSI TS 102 690에서 M2M 클라이언트 서버간 비동기 방식 커뮤니케이션으로 제시된 쇼트 폴링(short polling) 방식은 요청된 자원(Resource or Information or Data)이 수신될 때까지 요청과 응답이 반복되는 구조이다.

따라서 그 전달 구조는 간단하지만, 실제 자원을 수신할 때까지 발생하는 빈번한 요청과 응답으로 인해 상당한 M2M 네트워크 트래픽 부하가 유발된다.

도 2는 ETSI TS 102 690에 제시된 롱 폴링(long polling)방식을 도시한 도면이다.

M2M 클라이언트 서버간 비동기 방식 커뮤니케이션으로 ETSI TS 102 690에서 제시된 롱 폴링(long polling) 방식은 이슈어가 수신자(Hosting SCL)(20)을 통해 통지 서버(Subscribed-to-SCL)(30)와 통지 채널(Notification channel)을 생성하고 이를 통해 롱 폴링을 요청하여 이에 대한 응답으로서 통지(notification)를 수신하는 구조이다.

자원을 요청하는 측인 이슈어(issuer)가 롱 폴링을 요청하면 서버인 수신자(Receiver)는 이에 대한 응답으로서 최종적으로 통지(Notification)를 전송한다.

이렇게 통지 채널이 형성되고 롱 폴링이 요청되고 나면 통지 서버(30)는 이슈어(issuer)의 자원 요청에 대해 응답하는 통지(Notificaton)가 가능해지는 시점이 될 때까지는 별도로 응답을 전송하지 않으며 이슈어(10) 또한 응답으로서 통지를 수신하기 위해 대기한다. 따라서, 쇼트 폴링(short polling)에 비해 M2M 네트워크 트래픽 부하가 작다는 장점이 있다.

그러나 이슈어(issuer)가 요청한 롱 폴링(long polling)에는 일정한 시간 제한이 있으며, 이로 인해 제한 시간 내에 통지(notification([도 2]의 011a))를 받지 못하면 이슈어(issuer)가 롱 폴링(long polling)을 다시 요청하여 도 2에 도시된 단계 004a~010을 처음부터 새로이 반복해야한다.

따라서 통지(notification)가 늦어질 경우에는 결국 네트워크 트래픽 부하가 유발되게 된다.

또한 이 경우 일정 시간 동안 대기 후, 롱 폴링(long polling)을 다시 요청해야하므로 실제 커뮤니케이션이 상당히 지연되는 문제도 있다.

또한 롱 폴링(long polling) 방식은 통지(notification) 메커니즘과 결합하여 작동해야 하므로 통지 충돌(notification conflict) 등의 문제를 갖는 복잡한 구조의 방식이다.

한편 자료를 수집하고 전송하는 측인 서버(SCL)에서 M2M 센서로부터 자료를 수집하는 방법으로는 주기적 방식(periodic reporting), 온디맨드 방식(on-demand reporting), 이벤트 방식(event-based reporting) 3가지가 있으며, 롱 폴링(long polling) 방식은 이벤트 방식 자료수집에 적합하다.

그러나 롱 폴링(long polling)은 자료의 특성상 일정한 주기에 따라 자료가 수집되므로 해당 주기 동안에는 통지가 지연될 수 밖에 없는 주기적 방식의 자료수집에는 부적합하다. 또한 롱 폴링 방식은 이벤트 방식으로 자료가 수집되는 경우와 같이 자료 수집 여건 상 통지(notification)가 늦어질 수 있는 경우에도 부적합한 방식이다.

본 발명에 따르면 상술한 쇼트 폴링(short polling)과 롱 폴링(long polling) 방식과는 전혀 다른 스케줄 폴링(scheduled polling) 방법을 제안한다. 본 발명에 따른 스케줄 폴링 방법에 따르면 자료를 수집하는 측인 서버의 자료 수집 상황을 고려하여 폴링, 즉 자료 요청 및 전송이 이루어질 수 있다.

이러한 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 상술한 쇼트 폴링(short polling)과 롱 폴링(long polling)에서 발생하는 문제점을 효율적으로 보완할 수 있다.

특히 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 주기적 방식의 자료수집 또는 이벤트의 발생시각이 예측가능한 M2M 환경에서 트래픽 부하를 획기적으로 줄일 수 있다.

도 3은 본 발명이 적용되는 M2M 서비스 구조의 일 예를 도시한 도면이다.

본 발명의 네트워크 구성은 기존의 M2M 구조와 동일한 구조로서 장치/게이트웨이 및 M2M 코어 플랫폼(Core Platform)에서 다수의 액세스 네트워크를 수용할 수 있는 기능을 제공하는 환경에서 적용된다.

M2M 서비스 구조는 도면의 우측에 도시된 네트워크/어플리케이션 도메인(Network and Application domain)과 도면의 좌측에 도시된 M2M 장치 도메인(M2M Device domain)으로 구성된다.

네트워크/어플리케이션 도메인은 M2M 서비스 능력인 M2M SC(M2M Service Capabilities)(SC1 내지 SC8)(112)에 접근하거나 서비스 로직을 제공하는 M2M 어플리케이션(M2M Application)(111)과 코어 네트워크(Core Network A and/or B), M2M SC(SC1 내지SC8)(112)를 포함한다.

네트워크/어플리케이션 도메인은 이외에도 M2M 장치 도메인과 통신을 가능하게 하는 액세스 네트워크(Access Network)(미도시), 그리고 M2M 관리 기능(M2M Management Functions)(미도시) 및 네트워크 관리 기능(Network Management Functions)(미도시)을 더 포함할 수 있다.

한편, M2M 장치 도메인은 M2M 장치(M2M Device) 또는 M2M 게이트웨이를 포함한다. 또한 M2M 장치 및 M2M 게이트웨이는 M2M 어플리케이션(121)을 포함하며, M2M SC(122)를 더 포함할 수 있다.

M2M 장치가 M2M SC(122)를 포함하는 경우에는 포함된 M2M SC(122)를 통해 네트워크/어플리케이션 도메인에서 동작(interworking and interconnection)할 수 있다.

또한 M2M 장치가 M2M SC(122)를 포함하지 않는 경우에는 M2M 게이트웨이에 포함된 M2M SC와의 인터페이스를 통해 네트워크/어플리케이션 도메인에서 동작(interworking and interconnection)할 수 있다.

M2M 장치는 네트워크 도메인의 기능을 이용하기 위해 M2M 어플리케이션을 구동하여 M2M 장치 또는 M2M 게이트웨이의 M2M SC(Service Capabilities)를 통해 네트워크/어플리케이션 도메인에서 동작(interworking and interconnection)할 수 있다.

한편 M2M 장치는 M2M 에어리어 네트워크(M2M Area Network)(미도시)를 통해 M2M 게이트웨이에 연결되어 동작할 수 있다.

M2M 게이트웨이는 M2M SC를 포함하며, M2M 장치들이 네트워크/어플리케이션 도메인에서 동작(interworking and interconnection)할 수 있도록 한다.

SC(Service Capabilities)는 상이한 어플리케이션들에 의하여 공유되는 기능을 제공하는 것을 의미하며, M2M 장치, M2M 게이트웨이, M2M 네트워크 도메인 등의 M2M 개체들은 하나 또는 복수의 특정한 SC를 포함할 수 있다.

이러한 M2M 장치 또는 M2M 게이트웨이의 SCL(Service Capability Layer)은 네트워크 도메인의 SCL(Service Capability Layer)과 특정 인터페이스를 형성하여 상호 통신하며 동작(interworking and interconnection)한다.

또한 네트워크 도메인의 SC들은 하나 또는 복수의 코어 네트워크와 인터페이스할 수 있으며, 이 경우 기존의 타 규격에 따라 공지된 인터페이스를 통해 코어 네트워크의 기능을 이용할 수 있다.

이하 상술한 바와 같은 M2M 환경에서 적용되는 본 발명에 따른 스케줄 폴링(scheduled polling) 방법에 대해 도면을 참조하여 보다 상세하게 설명한다.

또한 본 발명에 따른 스케줄 폴링 방법이 구현되는 실시 예로서, 이하 (1) 일반적인 주기적 방식(periodic reporting)을 통해 자료를 수집하는 경우, (2) 온디맨드 방식(on-demand reporting) 에서 M2M 센서가 어떤 장애로 인해 즉시보고를 할 수 없지만 보고 주기가 정해져 있거나 보고시점이 예측 가능한 경우 및 (3) 이벤트 방식(event-based reporting)에서 이벤트 발생시점이 예측 가능한 경우 등에 대해서도 설명한다.

사물 통신에서 M2M 센서 등의 M2M 장치에서 발생하는 자원은 해당 M2M 장치가 보고하는 서비스 능력 레이어(SCL)에 보고되어 저장되고 관리된다.

본 발명에 따른 스케줄 폴링 방법은 이슈어 측의 로컬 서비스 능력 레이어(Local SCL: Local Service capability layer)와 이슈어가 필요로 하는 자원을 관리하는 서버의 호스팅 서비스 능력 레이어(Hosting SCL: Service Capability Layer)가 서로 다른 경우에 적용된다.

이슈어는 예를 들면 어플리케이션 또는 SCL(서비스 능력 레이어)로서 상술한 바와 같이 이슈어가 필요로 하는 자원에 접근하기 위해 해당 자원을 저장 관리하는 서버 또는 상기 서버의 호스팅 SCL(Hosting SCL)을 수신자(receiver)로 하는 요청(Request)을 전송한다.

이슈어가 서비스 능력 레이어인 경우에는 직접, 그리고 이슈어가 어플리케이션인 경우에는 로컬 서비스 능력 레이어(Local SCL)을 통해 서버 또는 호스팅 SCL(Hosting SCL)로 요청을 전송하며 이에 따라 수신자는 성공 또는 실패 응답을 전송한다.

한편 이슈어가 어플리케이션 또는 서비스 능력 레이어인 경우라도 로컬 SCL과 호스팅 SCL 이외에 중계 SCL(Intermediate SCL)이 별도로 개입하는 경우, 즉 로컬과 중계 및 호스팅 SCL이 각각 서로 다른 경우에는 본 발명에 따른 스케줄 폴링 방법은 멀티홉 방식 예를 들면 2-hop을 거쳐 전송된다.

즉 이 경우 로컬 SCL은 최종 수신자인 호스팅 SCL과 직접 통신할 수 없으므로 이슈어는 로컬 SCL 및 로컬 SCL이 등록한(registered) 중계 SCL(Intermediate SCL)을 통해 수신자인 호스팅 SCL로 요청을 전송하고 응답 또한 반대의 과정을 거쳐 이슈어로 전달된다.

도 4는 본 발명의 일 실시예에 따른 스케줄 폴링 방법을 설명하기 위한 도면이다.

본 발명에 따른 스케줄 폴링 방법은 주기적 방식의 자료 수집, 예를 들면 M2M 센서로부터의 보고 주기가 수시로 변경되는 환경에서 자료를 수집하는 경우 네트워크 자원 및 트래픽 측면에서 매우 효율적인 방법이다.

도 4를 참조하면, 이슈어(Issuer)(210)가 자원(resource)(데이터 또는 정보)을 수신(read, retrieval or fetch)하기 위해 요청(request)을 송신한다(S311).

이슈어(210)는 송신을 요청하기 위한 요청 메시지를 작성하기 위해 해당 요청 자원의 속성(Announced Resource)을 참조할 수 있다. 이 경우 이슈어(210)는 임의의 SCL과 접촉하지 않고 해당 요청 자원을 관리하는 호스팅 SCL을 수신자로 하여 요청을 송신할 수 있다.

또한 이슈어(210)는 요청하는 자원을 저장하는 주소 또는 링크, 예를 들면 URI 식별자 및/또는 해당 요청 자원에 대한 접근 권한(Access Right)을 상기 요청 메시지에 포함시킬 수 있다. 이를 위해 요청자(210)는 자원 발견 속성 "Discovery resource" 등을 이용하여 소정의 조건에 맞는 자원의 목록을 탐색(retrieve)할 수도 있다.

또한 이슈어(210)는 요청된 자원을 관리하는 호스팅 SCL의 M2M 장치 ID를 상기 요청 메시지에 포함시킬 수도 있다. 또한 이슈어(210)는 검색어(Searchstrings)를 요청 메시지에 포함시킬 수도 있다.

요청을 수신한 서버 또는 호스팅 SCL(Hosting SCL)(220)는 요청된 자원의 보고 주기 또는 업데이트 시점에 대한 스케줄 정보를 확인하고(S313), 보고 주기 또는 다음번 업데이트 시점, 예를 들면 자원의 다음번 수정시각과 같은 자원에 대한 스케줄 정보를 포함하는 메시지를 송신하여 수신한 요청에 대해 응답한다(S315).

이슈어(Issuer)(210)는 스케줄 정보에 따라 다음번 스케줄 시간까지 오프라인 또는 휴지(sleep) 상태를 유지할 수 있다. 이후 이슈어(Issuer)(210)는 수신한 응답에 포함된 스케줄 정보에 맞추어, 예를 들면 다음번 수정시각에 새로운 요청 메시지를 전송하여 자원을 요청하고(S317) 이에 따라 서버 또는 호스팅 SCL(Hosting SCL)(220)는 요청된 자원을 이슈어(Issuer)(210)로 전송하여 응답한다(S319). 이때 응답을 송수신한 후 이슈어(Issuer)(210)와 호스팅 SCL(Hosting SCL)(220)간의 상호 통신은 종료된다.

여기서 이슈어(Issuer)(210)는 M2M 장치 또는 M2M 게이트웨이 또는 M2M 네트워크 도메인의 어플리케이션(Device Application: DA, Gateway Application: GA, Network Application) 또는 각 M2M 객체의 SCL(Service Capability Layer)이 될 수 있다. 또한 상술한 바와 같이 이러한 이슈어는 클라이언트가 될 수 있다.

또한 수신자인 호스팅 SCL(Hosting SCL)(220)은 이슈어(Issuer)(210)가 요청하는 자원을 관리하는 SCL(Service Capability Layer)로서, 다수의 M2M 장치로부터 생성된 리소스를 관리하는 M2M 게이트웨이 또는 M2M 네트워크의 SCL(Service Capability Layer) 등이 될 수 있다. 이러한 수신자는 서버가 될 수 있다.

수신자인 호스팅 SCL(220)은 다수의 M2M 장치로부터 리소스 생성에 대한 보고를 받으며 본 발명에서는 각 M2M 장치로부터 수신되는 보고에 대한 스케줄을 저장 및 관리한다.

이러한 자원 보고 스케줄은 보고 주기(reportingInterval), 보고 시작시간(reportingStartTime) 및 종료시간(reportingEndTime) 등을 포함할 수 있다.

본 발명의 스케줄 폴링(scheduled polling)이 M2M 환경에서 효과적으로 활용되기 위해서 ETSI TS 102 690에 기술된 Table B.59 <areaNwkDeviceInfoInstance> 자원 속성(attribute)은 아래의 표 1과 같이 해당 자원의 자원 보고 스케줄을 포함할 수 있다.

자원 속성(attribute)

AttributeName	Mandatory/Optional	Type	Description
expirationTime	M	RW	See clause 9.2.2.
accessRightID	M	RW	See clause 9.2.2.
searchStrings	M	RW	See clause 9.2.2.
creationTime	M	RO	See clause 9.2.2.
lastModifiedTime	M	RO	See clause 9.2.2.
originalMO	M	WO	See clause 9.2.3.22.
description	O	RW	the text-format description of this MO.
areaNwkID	M	RW	The reference to an <areaNwkInstance> which this device associates with.
sleepInterval	M	RW	The interval between two sleeps.
sleepDuration	M	RW	The time duration of each sleep.
status	M	RW	The status of the device (sleeping or waked up).
reportingInterval	O	RW	The interval for reporting to server
reportingStartTime	O	RW	The start time of reporting
reportingEndTime	O	RW	The end time of reporting

상기 표 1을 보면 <areaNwkDeviceInfoInstance> 자원 속성에 보고 주기(reportingInterval), 보고 시작시간(reportingStartTime) 및 종료시간(reportingEndTime) 을 포함한다.

도 9는 본 발명에 따른 스케줄 폴링 방법을 구현하는 데 있어서 적용되는 자원 구조의 또 다른 예를 도시한 도면이다.

본 발명의 스케줄 폴링(scheduled polling)이 M2M 환경에서 효과적으로 활용되기 위한 또 다른 방법으로서 ETSI TS 102 690에 기술된 Figure B.29 <areaNwkDeviceInfoInstance> 리소스의 서브 리소스로서 <reportingSchedule> 리소스가 도 9와 같이 구성될 수도 있다.

이 때, <reportingSchedule> 리소스 또는 자원은 아래 표 2와 같이 정의될 수 있다.

< reportingSchedule> 자원

AttributeName	Madatory /Optional	Type	Description
reportingScheduleID	M	RW	The identification of reporting schedule
reportingInterval	M	RW	The interval for reporting to server
reportingStartTime	M	RW	The start time of reporting
reportingEndTime	M	RW	The end time of reporting
sleepInterval	M	RW	The Interval between two sleeps of device
sleepDuration	M	RW	The time duration of each sleep of device
deviceStatus	M	RW	The status of the device(sleeping or wakeup)

표 2를 참조하면 <reportingSchedule> 리소스 또는 자원은 요청된 자원을 생성하는 M2M 장치와 관련된 보고 스케줄을 식별하기 위한 ID(reportingScheduleID), 보고 주기(reportingInterval), 보고 시작시간(reportingStartTime), 보고 종료시간(reportingEndTime), 요청된 자원을 생성하는 M2M 장치가 대기상태로 있는 시간(sleepDuration), 상기 M2M 장치의 대기 시간 발생 간격(sleepInterval), 상기 M2M 장치의 대기(sleep) 또는 동작(wakeup) 등의 상태(deviceStatus) 등의 속성을 포함할 수 있다. 또한 이러한 속성들은 읽기 및 쓰기가 모두 가능할 수 있다.

도 5는 본 발명의 다른 실시예에 따른 스케줄 폴링 방법을 설명하기 위한 도면이다.

본 발명에 따른 스케줄 폴링 방법은 예를 들면 온디맨드 방식(on-demand reporting) 에서 M2M 센서가 불특정의 장애로 인해 즉시 보고를 할 수 없지만 보고 주기가 정해져 있거나 보고 시점이 예측 가능한 경우 매우 효율적인 방법이다.

도 5를 참조하면, 이슈어(Issuer)(210)가 자원(데이터, 정보 또는 리소스)을 수신(retrieval or fetch)하기 위해 요청(request)을 송신한다(S321).

이때 요청된 자원을 생성하여 보고하는 M2M 장치가 배터리 방전, 네트워크 장애 등의 각종 장애로 인해 보고가 불가능하게 되면(S323), 요청을 수신한 서버 또는 호스팅 SCL(Hosting SCL)(220)는 자원의 보고 주기 또는 업데이트 시점 등의 스케줄을 확인하거나 장애의 상황에 따른 각종 정보들을 검토하여 다음번 보고 시점 등의 스케줄을 예측한다(S325).

이에 따라 서버 또는 호스팅 SCL(Hosting SCL)(220)는 확인 또는 예측된 스케줄 정보를 포함하는 메시지를 송신하여 수신한 요청에 대해 응답한다(S327).

이슈어(Issuer)(210)는 스케줄 정보에 따라 다음번 스케줄 시간까지 오프라인 또는 휴지(sleep) 상태를 유지할 수 있다. 이후 이슈어(Issuer)(210)는 수신한 응답에 포함된 스케줄 정보에 맞추어 자원을 요청하고(S329) 스케줄 정보에 따라 M2M 장치(230)가 자원을 생성하여 보고하면(S331), 이에 따라 서버 또는 호스팅 SCL(Hosting SCL)(220)는 요청된 자원을 이슈어(Issuer)(210)로 전송하여 응답한다(S333). 이때 응답을 송수신한 후 이슈어(Issuer)(210)와 호스팅 SCL(Hosting SCL)(220)간의 상호 통신은 종료된다.

여기서 이슈어(Issuer)(210)는 전술한 바와 같이 M2M 장치 또는 M2M 게이트웨이 또는 M2M 네트워크 도메인의 어플리케이션(Device Application: DA, Gateway Application: GA, Network Application: NA) 또는 각 M2M 객체의 SCL(Service Capability Layer)가 될 수 있다.

또한 이러한 이슈어의 타입은 클라이언트가 될 수 있다.

그리고 서버 또는 호스팅 SCL(Hosting SCL)(220)는 전술한 바와 같이 이슈어(Issuer)(210)가 요청하는 자원을 갖고 있는 SCL(Service Capability Layer)로서, 센서와 같은 다수의 M2M 장치(230)로부터 생성된 리소스를 저장하고 관리하는 M2M 게이트웨이 또는 M2M 네트워크의 SCL(Service Capability Layer) 등이 될 수 있다.

도 6은 본 발명의 또 다른 실시 예에 따른 스케줄 폴링 방법을 설명하기 위한 도면이다.

본 발명의 스케줄 폴링 방법은 예를 들면 이벤트 방식(event-based reporting)에서 이벤트 발생시점이 예측 가능한 경우에도 효율적으로 구현될 수 있다.

도 6을 참조하면, 호스팅 SCL(Hosting SCL)(220)이 통지 서버(Notification Server) 또는 요청되는 자원을 관리하는 서버 측인 가입 SCL(Subscribed-to-SCL)(240)과 서로 다른 객체인 경우, 이슈어(Issuer)(210)는 중계 서버 또는 통지 채널(Notification Channel)을 생성하고 관리하는 호스팅 SCL(Hosting SCL)(220)을 통해 가입 SCL(Subscribed-to-SCL)(240)로의 통지 채널(Notification Channel)을 형성하여야 한다.

이러한 과정은 이슈어(210)인 클라이언트가 요청하고자 하는 자원에 대해 가입하고 있는 경우(subscribes to a resource)에 적용된다.

이를 위해 이슈어(210)는 통지채널을 생성하고 관리하는 호스팅 SCL(Hosting SCL)(220)를 통해 가입 SCL(Subscribed-to-SCL)(240)과의 통지 채널(Notification Channel) 자원 생성을 요청한다(S341).

이에 따라 중계 서버 또는 호스팅 SCL(Hosting SCL)(220)은 통지 채널 자원을 생성하고(S343) 가입 SCL(Subscribed-to-SCL)(240)에 스케줄 데이터를 요청한다(S345).

가입 SCL(Subscribed-to-SCL)(240)은 스케줄 데이터를 확인하고(S347) 중계 서버 또는 호스팅 SCL(Hosting SCL)(220)에 확인된 스케줄 정보를 포함하는 메시지를 송신하며(S349), 이를 수신한 중계 서버 또는 호스팅 SCL(Hosting SCL)(220)은 수신된 스케줄 정보를 포함하는 메시지를 이슈어(Issuer)(210)로 전송하여 응답한다(S351).

이 경우 가입 SCL(Subscribed-to-SCL)(240) 및 중계 서버인 호스팅 SCL(Hosting SCL)(220)은 확인된 스케줄 정보가 없으면 스케줄 정보가 없다는 응답을 전송할 수 있다.

스케줄 정보 요청에 대한 응답을 수신한 이슈어(S353)는 해당 응답 메시지에 요청한 자원에 대한 스케줄 정보가 존재하는 경우 해당 스케줄에 맞추어 자원 요청을 호스팅 SCL(Hosting SCL)(220)로 전송할 수 있다(S357).

이에 따라 호스팅 SCL(Hosting SCL)(220)은 수신된 요청을 가입 SCL(Subscribed-to-SCL)(240)로 전달하고(S359), 가입 SCL(Subscribed-to-SCL)(240)로부터 자원을 포함하는 응답이 수신되면(S361) 이를 이슈어(Issuer)(210)로 전송한다(S363).

한편 S351 단계에서 수신된 응답에 포함된 스케줄 정보가 없거나 다음번 업데이트 스케줄을 확인할 수 없는 경우 등 스케줄 폴링을 적용할 수 없는 경우에는 이슈어(Issuer)(210)는 롱 폴링 방법을 선택하여 도 2에 도시된 004a 내지 011b의 단계를 수행하여 자원을 요청할 수도 있다(S355).

한편 통지 채널이 형성되는 경우 스케줄 폴링 방식을 지원하기 위해 ETSI TS 102 690에 기술된 통지채널(notificationChannel) 자원(resources)은 예를 들면 아래의 표 3과 같이 구성될 수 있다.

통지 채널(notifcationChannel) 자원 속성(attribute)

AttributeName	Mandatory /Optional	Type	Description
channelType	M	RW	The type of the notificationChannel. longpolling or schdeduledPolling are supported
contactURI	M	RO	The URI that is used in subscriptions.
channelData	M	RO	The data associated with the channel. longPolling이면 longPolling URI를 표시하고 schdeduledPolling이면 schedule time을 표시한다.
creationTime	M	RO
lastModifiedTime	M	RO

표 3을 참조하면 통지 채널 자원(notificationChannel) 속성은 채널 타입(ChannelType), 등록시 사용된 접촉 URI(contactURI), 생성된 통지 채널과 관련된 데이터를 포함하는 채널 데이터(channelData), 채널 생성 시간(creationTime)과 최종 수정시간(lastModifiedTime)을 포함할 수 있다.

이 경우 채널 데이터(channelData)는 롱 폴링 방식이 수행되면 롱 폴링 URI를 포함할 수 있으며 스케줄 폴링 방법이 수행되면 스케줄 시간 정보를 포함할 수 있다.

또한, 본 발명의 스케줄 폴링(scheduled polling)이 롱 폴링(long polling) 절차에서 활용될 경우 ETSI TS 102 690에 기술된 Table 9.59 <notificationChannel> 자원 속성(attribute)이 아래 표 4와 같이 구성될 수도 있다.

통지 채널(notifcationChannel) 자원 속성(attribute)

AttributeName	Mandatory /Optional	Type	Description
channelType	M	RW	The type of the notificationChannel. Currently only longPolling is supported.
contactURI	M	RO	The URI that is used in subscriptions.
channelData	M	RO	The data associated with the channel. The type of data may differ depending on the channelType. For the longPolling channelType, the channelData includes a URI on which the client can do the long polling request in order to get the notifications that were sent to the contactURI.
creationTime	M	RO	See clause 9.2.2 Common attributes.
lastModifiedTime	M	RO	See clause 9.2.2 Common attributes.
nextScheduledTime	O	RW	The scheduled time on which the next notification will be sent

표 4를 참조하면 통지 채널(notificationChannel) 자원 속성은 롱 폴링을 지원한다는 채널 타입(ChannelType), 등록시 사용된 접촉 URI(contactURI), 생성된 통지 채널과 관련된 데이터를 포함하는 채널 데이터(channelData), 채널 생성 시간(creationTime), 최종 수정시간(lastModifiedTime) 및 다음번 통지가 전송될 것으로 스케줄된 시간(nextScheduledTime)을 포함하는 스케줄 정보를 포함할 수 있다.

이 경우 채널 데이터(channelData)는 채널 타입에 따라 달라지며 롱 폴링 방식이 수행되면 등록시 사용된 접촉 URI로 전송된 통지를 획득하기 위해 롱 폴링을 요청할 수 있는 URI를 포함할 수 있다.

도 10은 본 발명에 따른 스케줄 폴링 방법을 구현하는 데 있어서 적용되는 자원 구조의 또 다른 예를 도시한 도면이다.

본 발명의 스케줄 폴링(scheduled polling)이 M2M 환경에서 효과적으로 활용되기 위한 또 다른 방법으로서 ETSI TS 102 690에 기술된 Figure 9.35 <notificationChannel> 자원 구조의 서브 리소스로서 <reportingSchedule> 리소스가 도 10과 같이 추가될 수도 있다.

이 때, 보고 스케줄 정보를 포함하는 <reportingSchedule> 리소스 또는 자원은 상술한 표 3과 같이 정의될 수 있다.

도 7은 스케쥴 폴링(scheduled polling) 방법이 적용되는 M2M 환경을 보다 상세히 설명하기 위한 도면이다.

도면을 참조하면, 오염 측정(pollution measurement), 바람 측정(wind measurement), 태양열 판(solar panel), 온도계(temparature measurement)와 같은 각종 센서노드 등의 M2M 장치(440)가 오염 측정, 풍속/풍향 측정, 태양 에너지 관측, 온도 등을 측정하여 측정 데이터를 주기적으로 SCL(430)에 보고하는 M2M 환경에서, 　

① 특정 네트워크 어플리케이션(NA)(410)이 풍속 데이터가 필요하여 13시42분에 이슈어가 되어 해당 SCL(430)에 자원을 요청하면(S511), ② 해당 SCL(430)은 보고 스케줄(reportingSchedule) 자원을 확인하여 풍속 측정 장치 D2(440)의 풍속데이터를 보고 주기가 1시간이므로 풍속 측정 장치(440)가 다음번에는 14시 정각에　다시　보고할 것임을 알 수 있고, 이에 따라 해당 SCL(430)은 이슈어인 네트워크 어플리케이션(NA)(410)에게 풍속 데이터의 갱신 예정시각이 14시임을 알려 준다(S513).

③ 이 후 풍속 측정 장치 D2(440)는 14시에 풍속 데이터를 갱신하며(S515), ④ 네트워크 어플리케이션(NA)(410)은 14시에 풍속 데이터를 다시 요청하여 데이터를 얻는다(S517).

이러한 과정을 위해 M2M 장치(440)들로부터 보고된 자원을 관리하는 SCL(430)은 각 M2M 장치(440)들의 보고 주기를 포함하는 보고 스케줄을 예를 들면 도 7에 도시한 보고 스케줄 표와 같은 형태로 저장할 수 있다.

도면에서 이슈어는 스케줄 폴링 방법에 따른 요청에 대한 응답을 받고 나면, 이후 리소스 요청을 반복하지 않고 응답 메시지에 포함된 데이터 갱신 예정 시각까지 오프라인 또는 휴지(sleep) 상태를 유지하다가 예정된 시간에 맞춰 리소스를 요청하여 데이터를 얻을 수 있다.

따라서 쇼트 폴링 방식에서와 같은 요청과 응답의 계속된 반복으로 인한 네트워크 자원 낭비와 혼잡을 방지할 수 있어 네트워크 자원의 효율적인 사용이 가능하다.

또한 본 발명에 따른 스케쥴 폴링(scheduled polling) 방법에 따르면 주기적 보고(periodic reporting) M2M 환경 또는 자원 보고 시각이 예측 가능한 경우 롱 폴링(long polling) 방식과 같이 별도의 통지 채널 형성이 필요 없을 뿐만 아니라 리소스 획득을 위한 메시지 교환 과정이 월등하게 간단하고 효율적인 방법임을 알 수 있다.

도 8은 본 발명에 따른 스케쥴 폴링 방법을 설명하기 위한 도면이다.

이슈어(Issuer)(610)가 자원(resource)을 수신(retrieval or fetch)하기 위해 요청(request)을 송신하면(S711), 요청을 수신한 수신자인 서버 또는 호스팅 SCL(Hosting SCL)(620)은 자원의 보고 주기 또는 업데이트 시점에 대한 스케줄을 확인한다(S713).

이를 위해, 정보 또는 리소스를 획득(retrieve)하기 위해 이슈어(610)가 전송한 요청을 수신한 서버 또는 호스팅 SCL(620)은 경험칙(heuristics) 또는 실제 구현에 따른 정보에 기초하여 요청된 리소스가 다음번에 언제 수정될 것인지 그 시간을 결정할 수 있다.

경험칙의 예로서, 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 이벤트 발생시각이 예측 가능한 이벤트 방식에서 발생 예측 시각을 스케줄 정보로서 이용할 수 있다. 이벤트 발생시각은, 예를 들면 호스팅 SCL(Hosting SCL)에서 년간/월간/주간/일간 이벤트 발생 시각 데이터를 축적한 후 평균 이벤트 발생시각 데이터를 산출하는 방식으로 예측할 수 있다.

따라서 요청을 수신한 서버 또는 호스팅 SCL(620)은 보고 주기 또는 다음번 업데이트 시점에 대한 정보를 포함하는 메시지를 송신하여 수신한 요청에 대해 응답한다(S715).

또한 이슈어(610)가 통지 채널 생성 등의 방식을 통해 리소스에 가입 또는 등록(subscribe)하는 경우에도 리소스의 다음번 수정에 따라 다음번 통지가 언제 전송될 것인지에 대한 예측이 가능한 경우에는 다음번 통지 예측 시각과 같은 예측 스케줄 표시 정보가 통지 메시지에 포함될 수 있다.

따라서 단순 자원 요청이든 통지 채널을 생성한 경우에 있어서든 이슈어(610)는 이러한 정보에 따라 다음번 스케줄 시간까지 오프라인 또는 휴지(sleep) 상태로 유지할 수 있으며 이에 따라 배터리(battery)로 운영되는 장치의 경우 배터리(battery) 절감 효과를 얻을 수 있다.

다만 통지 채널을 생성한 경우, 요청된 자원이 표시된 스케줄 시간 이전에 수정되면 이슈어(610)인 장치 또는 게이트웨이에게 예를 들면 웨이크업 메카니즘(wakeup mechanism)을 수행할 수 있다.

이후 이슈어(Issuer)(610)는 수신한 응답에 포함된 스케줄 정보에 맞추어 자원을 요청하는 새로운 요청을 전송할 수 있고(S717) 이에 따라 요청을 수신한 서버 또는 호스팅 SCL(Hosting SCL)(620)은 요청된 자원을 이슈어(Issuer)(610)로 전송하여 응답한다(S719). 이때 응답을 송수신한 후 이슈어(610)와 호스팅 SCL(Hosting SCL)(620)간의 상호 통신은 종료된다.

본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 주기적 방식을 통한 자료수집시 롱 폴링(long polling) 방식보다 효율적으로 처리할 수 있으며, 특히, M2M 센서로부터의 보고 주기가 수시로 변경되는 환경에서 자료를 수집할 때 매우 효율적이다. 주기적 방식의 자료수집은 스마트 미터링(smart metering), 이헬스(eHealth), 도시 자동화(city automation) 등의 응용분야에서 많이 사용되고 있다.

또한 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 이벤트 발생시각이 예측 가능한 이벤트 방식에서도 효율적으로 사용될 수 있다. 이벤트 발생시각이 예측 가능한 방법으로는 호스팅 SCL(Hosting SCL)에서 년간/월간/주간/일간 이벤트 발생 시각 데이터를 축적한 후 평균 event 발생시각 데이터를 예측가능하다.

또한 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 온디맨드 방식(on-demand reporting) 에서 M2M 센서가 어떤 장애로 인해 즉시보고를 할 수 없지만 보고 주기가 정해져 있거나 보고시점이 예측 가능할 때 효율적으로 사용될 수 있다.

또한 본 발명에 따른 스케줄 폴링(scheduled polling) 방법은 메시지 전송 구조가 단순하여 구현이 용이하다.

도 11은 본 발명의 일 실시예에 따른 M2M 객체의 구성을 도시한 도면이다.

도면에는 본 발명에 따른 스케줄 폴링 방법을 구현하기 위한 요소를 중심으로 표시하고 있다.

도시한 M2M 객체는 M2M 장치, M2M 게이트 웨이 또는 M2M 네트워트 도메인으로 동작하도록 각각 구현될 수 있다.

도면을 참조하면 M2M 객체는 M2M 어플리케이션 모듈(121)과 M2M 서비스 능력 모듈(Service Capabilities Module)(122) 및 통신 모듈(Communication Module)(125)를 포함한다.

도면에서 M2M 어플리케이션 모듈(121)과 M2M 서비스 능력 모듈(122)은 별개의 요소로 구현되는 것으로 표시하였으나 이들을 각각 별개의 프로세서로서 구현되거나 하나의 프로세서 내에 구현될 수도 있다.

M2M 어플리케이션 모듈(121)과 M2M 서비스 능력 모듈(122)은 상호 연동하여 동작하며 본 발명에 따른 스케줄 폴링 기능을 구현하기 위해 M2M 객체 내의 장치 요소들을 통합 제어할 수 있다. 이 경우 M2M 어플리케이션 모듈(121) 및/또는 M2M 서비스 능력 모듈(122)은 통합 제어부 또는 M2M 서비스 모듈(123)로서 구현될 수 있으며 하나의 프로세서로서 구현될 수 있다.

스케줄 폴링 방법을 구현하기 위해 M2M 어플리케이션 모듈(121)과 M2M 서비스 모듈(122)은, 요청을 수신할 대상인 M2M 객체 또는 요청을 전송한 M2M 객체에 대한 정보를 취합하여 송수신하기 위한 요청과 응답 메시지를 작성하며, 통신 모듈(125)을 제어하여 이를 통해 상술한 요청 메시지를 송수신하고 이에 따른 상술한 응답 메시지를 송수신한다.

또한 M2M 어플리케이션 모듈(121)과 M2M 서비스 모듈(122)은 수신한 메시지를 해석하여 필요한 정보를 추출하고 스케줄 정보에 따라 일정 시간 메시지 송신을 중지하는 등 필요한 경우 장치 요소들을 오프라인 또는 휴지(sleep) 상태로 유지할 수 있으며 이에 따라 배터리(battery)로 운영되는 장치의 경우 배터리(battery) 절감 효과를 얻을 수 있다.

이외에도 M2M 객체가 호스팅 SCL로서 구현되는 경우 M2M 어플리케이션 모듈(121)과 M2M 서비스 모듈(122)은 연결된 각종 M2M 장치들로부터 수신되는 정보를 분석하고 자원으로서 저장하는 기능을 수행한다.

한편 통신 모듈(125)은 M2M 객체 간 M2M 통신이 수행될 수 있도록 상호 연결을 수행하며 이를 위해 기존의 지역 네트워크(Area Network) 또는 코어 네트워크를 통해 연결된다. 통신 모듈(125)은 이러한 기능을 제공하기 위해 IEEE 802.15.1 [i.3], Zigbee, Bluetooth, IETF ROLL, ISA100.11a, 또는 PLC, M-BUS, Wireless M-BUS 및 KNX와 같은 로컬 네트워크 또는 지역 네트워크(Area Network) 통신 모듈 및/또는 xDSL, HFC, 위성 통신, GERAN, UTRAN, eUTRAN, W-LAN and WiMAX와 같은 코어 네트워크 통신 모듈을 탑재할 수 있다.

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

Claims (22)

1. 클라이언트로 동작하는 M2M 객체에 있어서,
   서버로 동작하는 별개의 M2M 객체가 관리하는 M2M 자원을 수신하기 위한 요청을 전송하는 단계;
   상기 서버로부터 상기 M2M 자원 관리와 관련된 스케줄 정보를 포함하는 응답을 수신하는 단계; 및
   상기 스케줄 정보에 따라 상기 M2M 자원을 수신하기 위한 새로운 요청을 전송하는 단계;를 포함하는 M2M 장치 간 스케줄 폴링 방법.
   
2. 제 1 항에 있어서,
   상기 스케줄 정보는 상기 M2M 자원의 다음번 수정 시각을 포함하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
3. 제 2 항에 있어서,
   상기 스케줄 정보에 따른 새로운 요청 전송 단계에서는, 상기 다음번 수정 시각에 상기 새로운 요청을 전송하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
4. 제 3 항에 있어서,
   클라이언트로 동작하는 상기 M2M 객체는 상기 다음번 수정 시각까지 오프라인 또는 휴지(sleep) 상태를 유지하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
5. 제 1 항에 있어서,
   상기 스케줄 정보는 서버로 동작하는 상기 별개의 M2M 객체에 의해 결정되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
6. 제 1 항에 있어서,
   클라이언트로 동작하는 상기 M2M 객체가 상기 자원에 대해 가입하고 있는 경우에는, 상기 자원 요청에 대한 응답으로서 통지 메시지를 수신하며 상기 통지 메시지는 다음번 통지 메시지가 전송될 예측 스케줄 시각에 대한 표시를 포함하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
7. 제 6 항에 있어서,
   클라이언트로 동작하는 상기 M2M 객체는 상기 다음번 통지 메시지가 전송될 스케줄 시각까지 오프라인 또는 휴지(sleep) 상태를 유지하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
8. 제 1 항에 있어서,
   상기 응답 수신 단계 이후, 상기 스케줄 정보에 따른 새로운 요청과 이에 대한 응답을 상기 서버와 송수신한 이후에는 상기 M2M 객체 간 상호 통신이 종료되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
9. 제 1 항에 있어서,
   상기 스케줄 정보는, M2M 자원 중 <areaNwkDeviceInfoInstance> 자원 속성(attribute)으로서 저장되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
   
10. 제 9 항에 있어서,
    상기 <areaNwkDeviceInfoInstance> 자원 속성(attribute)은 보고 주기(reportingInterval), 보고 시작시간(reportingStartTime) 및 종료시간(reportingEndTime) 중 적어도 하나를 포함하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
11. 제 1 항에 있어서,
    상기 스케줄 정보는, M2M 자원 중 <areaNwkDeviceInfoInstance> 자원의 서브 자원인 <reportingSchedule> 자원으로서 저장되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
12. 제 11 항에 있어서,
    상기 <reportingSchedule> 자원 속성은, 요청된 자원을 생성하는 M2M 장치의 보고 스케줄을 식별하기 위한 ID(reportingScheduleID), 보고 주기(reportingInterval), 보고 시작 시간(reportingStartTime), 보고 종료시간(reportingEndTime), 상기 M2M 장치가 대기상태로 있는 시간(sleepDuration), 상기 M2M 장치의 대기 시간 발생 간격(sleepInterval), 상기 M2M 장치의 대기(sleep) 또는 동작(wakeup) 등의 상태(deviceStatus) 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
13. 제 1 항에 있어서,
    상기 스케줄 정보는, M2M 자원 중 통지 채널 자원 <notificationChannel> 속성으로서 저장되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
14. 제 1 항에 있어서,
    상기 스케줄 정보는, M2M 자원 중 통지 채널 자원 <notificationChannel> 자원의 서브 자원인 <reportingSchedule> 자원으로서 저장되는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
15. 제 14 항에 있어서,
    상기 <reportingSchedule> 자원 속성은, 요청된 자원을 생성하는 M2M 장치의 보고 스케줄을 식별하기 위한 ID(reportingScheduleID), 보고 주기(reportingInterval), 보고 시작 시간(reportingStartTime), 보고 종료시간(reportingEndTime), 상기 M2M 장치가 대기상태로 있는 시간(sleepDuration), 상기 M2M 장치의 대기 시간 발생 간격(sleepInterval), 상기 M2M 장치의 대기(sleep) 또는 동작(wakeup) 등의 상태(deviceStatus) 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
16. 제 1 항에 있어서,
    상기 스케줄 정보는, 년간, 월간, 주간 또는 일간 중 적어도 하나에 따른 주기적 이벤트 발생 시각 데이터를 축적하여 평균한 이벤트 발생시각으로 결정하는 것을 특징으로 하는 M2M 장치 간 스케줄 폴링 방법.
    
17. 서버로 동작하는 별개의 M2M 객체가 관리하는 M2M 자원을 수신하기 위한 요청을 작성하고 상기 요청에 대한 상기 별개의 M2M 객체로부터 응답이 수신되면 상기 응답으로부터 상기 M2M 자원 관리와 관련된 스케줄 정보를 추출하는 M2M 모듈; 및
    상기 제어부에서 작성된 상기 요청을 전송하고 상기 요청에 대한 상기 응답을 수신하는 통신 모듈을 포함하며,
    상기 M2M 모듈은 상기 스케줄 정보에 따라 상기 M2M 자원을 수신하기 위한 새로운 요청을 작성하여 상기 통신 모듈을 통해 전송하는 것을 특징으로 하는 M2M 장치.
    
18. 제 17 항에 있어서,
    상기 스케줄 정보는 상기 M2M 자원의 다음번 수정 시각을 포함하며, 상기 M2M 모듈은 상기 새로운 요청을 상기 다음번 수정 시각에 맞춰 상기 통신 모듈을 통해 전송하는 것을 특징으로 하는 M2M 장치.
    
19. 제 18 항에 있어서,
    상기 M2M 모듈은 상기 다음번 수정 시각까지 오프라인 또는 휴지(sleep) 상태를 유지하는 것을 특징으로 하는 M2M 장치.
    
20. 제 17 항에 있어서,
    상기 M2M 모듈은, 상기 자원에 대해 가입하고 있는 경우 상기 자원 요청에 대한 응답으로서 통지 메시지를 수신하며 상기 통지 메시지는 다음번 통지 메시지가 전송될 예측 스케줄 시각에 대한 표시를 포함하는 것을 특징으로 하는 M2M 장치.
21. 제 20 항에 있어서,
    상기 M2M 모듈은 상기 다음번 통지 메시지가 전송될 스케줄 시각까지 오프라인 또는 휴지(sleep) 상태를 유지하는 것을 특징으로 하는 M2M 장치.
    
22. 제 17 항에 있어서,
    상기 응답 수신 이후, 상기 M2M 모듈은 상기 스케줄 정보에 따른 새로운 요청과 이에 대한 응답을 상기 서버와 송수신한 이후에는 상기 통신 모듈을 통한 통신을 종료하는 하는 것을 특징으로 하는 M2M 장치.

Images