KR20180039551A - Receiver CSE에서 효율적인 자원관리 위해 flexBlocking communication method를 처리하는 방법 - Google Patents

Abstract

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, Receiver CSE에서 효율적인 자원관리 위해 flexBlocking communication method를 처리하는 방법에 관한 것이다. 일 실시예는 M2M(Machine to machine communication) 장치가 요청 메시지를 수신하는 단계; 상기 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계; 및 상기 응답 유형 파라미터에 따라 응답 유형 파라미터를 결정하는 단계를 포함하되, 상기 응답 유형 파라미터는, 플렉스블럭킹(flexblocking)으로 설정되는 것을 특징으로 하는 방법 및 장치를 제공한다.

Description

Receiver CSE에서 효율적인 자원관리 위해 flexBlocking communication method를 처리하는 방법{Methods for processing flexBlocking communication method in Receiver CSE and Apparatuses thereof}

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, Receiver CSE에서 효율적인 자원관리 위해 flexBlocking communication method를 처리하는 방법에 관한 것이다.

사물 통신(M2M, "Machine to machine communication" 또는 MTC, "Machine type communication" 또는 스마트 디바이스 통신, "Smart Device communication" 또는 "Machine oriented communication" 또는 사물 인터넷, "Internet of Things")은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다. 최근 oneM2M에서 M2M과 관련된 논의가 이루어지고 있으나, oneM2M의 아키텍처(Architecture) 및 요구 사항(Requirement)을 충족시키는 기술적인 요소들이 제시되지 않은 상태이다.

전술한 배경에서 안출된 본 실시예는 M2M 장치가 flexBlocking communication method를 수신한 경우에도 이를 유연하게 처리할 수 있는 방법 및 장치를 제안하고자 한다.

전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to machine communication) 장치가 요청 메시지를 수신하는 단계; 상기 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계; 및 상기 응답 유형 파라미터에 따라 응답 유형 파라미터를 결정하는 단계를 포함하되, 상기 응답 유형 파라미터는, 플렉스블럭킹(flexblocking)으로 설정되는 것을 특징으로 하는 방법 및 장치를 제공한다.

이상에서 설명한 본 실시예는 M2M 장치가 flexBlocking communication method를 수신한 경우에도 이를 유연하게 처리하는 효과를 제공한다.

도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 Generic procedure of Receiver를 도시한 도면이다.
도 5는 Resource handling procedure를 도시한 도면이다.
도 6은 Receiver CSE가 Response Type으로 blockingRequest를 선택하는 동작을 설명하기 위한 도면이다.
도 7은 Receiver CSE가 Response Type으로 nonBlockingRequestSynch를 선택하는 동작을 설명하기 위한 도면이다.
도 8은 Receiver CSE가 Response Type으로 nonBlockingRequestAsynch를 선택하는 동작을 설명하기 위한 도면이다.
도 9는 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestSynch를 선택하는 동작을 설명하기 위한 도면이다.
도 10은 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestAsynch를 선택하는 동작을 설명하기 위한 도면이다.
도 11은 1Hop CSE(Transit CSE)는 “blockingRequest” communication method만 수용 가능하나 2Hop CSE(Hosting CSE)가 “nonBlockingRequestSynch” communication method를 선택하는 동작을 설명하기 위한 도면이다.
도 12는 1Hop CSE(Transit CSE)는 “blockingRequest” communication method만 수용 가능하나 2Hop CSE(Hosting CSE)가 “nonBlockingRequestAsynch” communication method를 선택하는 동작을 설명하기 위한 도면이다.
도 13은 Resource handling procedure의 Forward 절차에 Response Type을 수정하는 프로세스 추가를 설명하기 위한 도면이다.
도 14는 Resource handling procedure의 Forward 절차에 Transit CSE가 blocking과 nonBlocking method를 모두 수용가능한지를 체크하는 프로세스 추가를 설명하기 위한 도면이다.
도 15는 일 실시예에 따른 수신측 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) 등이 될 수 있다(Application Entity (AE): Application Entity provides Application logic for the end-to-end M2M solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.). 공통 서비스 개체(Common Services Entity, CSE)(120)는 서비스 기능의 집합으로써, 이러한 서비스 기능은 M2M 환경에 공통적으로 사용하는 기능이다. 이러한 서비스 기능은 참조점(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로 기재할 수 있다. 또한, 본 명세서에서의 M2M 장치는 CSE 또는 AE를 의미하거나, CSE 또는 AE를 포함하는 장치를 의미할 수 있다.

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

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

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

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

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

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

본 실시예들은 에러 발생을 방지하기 위해서 필수적인 M2M 시스템에서의 요청 메시지 송신측의 응답 정보 수신 방법 및 절차에 관한 것이다.

예를 들면, 주택이나 아파트에서 전기, 가스, 수도 등의 사용량 정보를 월별 또는 일정한 주기로 사물통신을 통하여 제공한다. 이를 위해서는 전기계량기, 가스 검침기, 수도 계량기 등에서 정보를 수집하고 정보를 전송하여야 한다. 이 외에도, 에너지, 기업, 의료, 공공서비스, 주거, 소매, 교통 및 운송 등 다양한 응용을 사물통신에 적용할 수 있으며, 다양한 사물통신 응용 분야는 표 1과 같이 제시될 수 있으나 여기에 한정된 것은 아니다.

본 실시예는 이러한 다양한 분야의 M2M 장치 간에 정보를 송수신할 때, 개별 M2M 장치 또는 개별 요청 메시지의 응답 유형에 따라 응답 정보를 전달하는 절차를 구분하여 제공하여 응답 정보를 송수신하는 데에 발생할 수 있는 오류 발생을 방지하기 위한 것이다.

이를 위해서, 본 실시예는 발원자(Originator)가 요청 메시지를 구성하여 전송하고, 수신자(Receiver)의 응답 유형에 따라 발원자가 블럭킹, 동기식논블럭킹, 비동기식논블럭킹을 판단하는 방법을 제공한다. 또한, 응답 유형 파라미터가 동기식논블럭킹인 경우, 발원자는 수신자의 처리 결과를 조회하여 처리 완료 여부를 판단하고, 처리가 완료된 결과를 얻을 수 있다. 만약, 응답 유형 파라미터가 비동기식논블럭킹인 경우, 발원자는 수신자의 처리 결과 완료 통지 정보를 수신하고, 통지 정보를 이용하여 처리가 완료된 결과를 얻을 수 있다.

본 명세서에서의 발원자와 수신자는 모두 M2M 장치가 될 수 있으며, 요청 메시지를 전송하는 M2M 장치를 발원자로 기재하고, 요청 메시지를 수신하고 응답 정보를 생성하여 전송하는 M2M 장치를 수신자로 기재하여 설명할 수 있으나, 필요에 따라 용어는 변경될 수 있다.

도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.

도 3을 참조하면, 발원자(300)는 필요한 정보를 얻기 위해서 요청 메시지(Request message)를 전송한다(S320). 요청 메시지에는 필수적인 파라미터와 선택적인 파라미터가 포함될 수 있다. 예를 들어, 송신측 파라미터, 수신측 파라미터, 요청 식별 파라미터 및 동작 파라미터는 필수적인 파라미터로 포함된다. 송신측 파라미터는 메시지를 전송하는 발원자에 대한 정보를 포함하고, 수신측 파라미터는 메시지를 수신하는 수신자에 대한 정보를 포함한다. 요청 식별 파라미터는 해당 요청 메시지를 식별하기 위한 유일한 ID 정보를 포함한다. 또한, 동작 파라미터는 요청 메시지에서 요청하는 동작을 구분하기 위한 정보를 포함한다. 동작 파라미터는 생성, 조회, 삭제, 업데이트 및 통지 중 어느 하나로 설정될 수 있다.

수신자(310)는 요청 메시지를 수신하고, 이에 대한 응답 메시지(Response Message)를 생성하여 발원자(300)로 전송한다(S340). 다만, 수신자(310)는 설정에 따라서 응답 메시지를 전송하는 절차가 상이할 수 있다. 또는, 요청 메시지에 포함된 응답 유형 파라미터에 따라 응답 메시지는 다른 절차로 수신될 수 있다. 즉, 수신자(310)가 요청 메시지를 수신한 후 응답 메시지를 전송하는 절차는 상이할 수 있다.

따라서, 발원자(300)는 각각의 수신자(310)의 응답 메시지 처리 절차에 따라서 응답 메시지를 수신하기 위한 일반적인 프로시져를 진행한다(S330). 예를 들어, 발원자(300)는 요청 메시지의 응답 유형 파라미터를 확인하여, 응답 유형 파라미터 별로 다른 절차로 응답 메시지를 수신할 수 있다. 본 발명은 발원자(300)의 응답 메시지 수신 절차에 관한 것으로, 응답 유형 파라미터 별로 구분되는 응답 정보 수신 절차를 제안한다.

이하에서는, S330 단계와 관련하여 보다 구체적인 실시예를 중심으로 설명하며, 응답 유형 파라미터에 따른 응답 정보 수신 절차를 구분하여 설명한다.

예를 들어, M2M 장치는 요청 메시지를 전송하는 단계를 수행한다(S400). 요청 메시지는 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터 중 적어도 하나의 파라미터를 포함할 수 있다.

또한, M2M 장치는 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계를 수행한다. 예를 들어, 응답 유형 파라미터는 요청 메시지에 포함될 수 있다. 응답 유형 파라미터는 요청 메시지에 대한 응답 정보를 수신하는 절차에 따라 구분되어 설정될 수 있다. 예를 들어, 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정될 수 있다. 또는, 응답 유형 파라미터가 존재하지 않을 수도 있다.

또한, M2M 장치는 응답 유형 파라미터에 따라 응답 정보를 수신하는 단계를 수행한다. M2M 장치는 S402 단계에서 확인한 응답 유형 파라미터에 따라서 요청 메시지에 대한 응답 정보를 서로 다른 절차롤 통해서 수신할 수 있다.

일 예로, M2M 장치는 응답 유형 파라미터가 존재하지 않거나, 블럭킹으로 설정된 경우에 응답 정보가 수신될 때까지 대기한다. 즉, M2M 장치는 응답 정보를 포함하는 응답 메시지가 수신될 때까지 별도의 동작을 수행하지 않고 대기한다.

다른 예로, M2M 장치는 응답 유형 파라미터가 동기식 논블럭킹 또는 비동기식 논블럭킹으로 설정된 경우, 요청 메시지에 대한 수신 확인 메시지를 수신자로부터 수신하기 위해서 대기한다. 수신 확인 메시지는 요청 메시지에 대한 Ack 정보를 포함하는 것으로, 수신자가 요청 메시지를 수신하였음을 나타내는 정보를 포함할 수 있다.

또 다른 예로, M2M 장치는 응답 유형 파라미터가 동기식 논블럭킹으로 설정된 경우, 응답 정보를 수신하기 위한 조회 요청 메시지를 수신자로 전송한다. 조회 요청 메시지는 미리 설정된 주기 또는 일정 시간이 경과한 경우에 전송될 수 있다. M2M 장치는 조회 요청 메시지를 전송한 이후에 조회 요청 메시지에 대한 조회 응답 메시지를 수신한다. 조회 응답 메시지는 응답 상태 코드 파라미터, 요청 식별 파라미터 및 컨텐츠 파라미터를 필수적으로 포함할 수 있다. M2M 장치는 조회 응답 메시지가 수신되면 조회 응답 메시지에 포함되는 응답 상태 코드 파라미터 또는 컨텐츠 파라미터를 확인하고, 응답 정보의 포함 여부에 따라서 조회 요청 메시지를 재전송하거나, 조회 응답 메시지에서 응답 정보를 추출하거나, 에러 처리를 수행할 수 있다.

또 다른 예로, M2M 장치는 응답 유형 파라미터가 비동기식 논블럭킹으로 설정된 경우, 수신자로부터 통지 요청 메시지를 수신할 수 있다. 또한, M2M 장치는 통지 요청 메시지에 대한 통지 응답 메시지를 생성하여 수신자로 전송한다. 통지 요청 메시지는 동작 파라미터, 수신측 파라미터, 송신측 파라미터, 요청 식별 파라미터 및 켄턴츠 파라미터를 포함할 수 있다. 또한, 통지 응답 메시지는 응답 상태 코드 파라미터 및 요청 식별 파라미터를 포함할 수 있다. 통지 응답 메시지에 포함되는 요청 식별 파라미터는 통지 요청 메시지의 요청 식별 파라미터와 동일한 값으로 설정될 수 있다. 통지 요청 메시지는 수신자가 요청 메시지에 따른 응답 정보의 생성을 완료하여 M2M 장치로 전송하는 것으로, M2M 장치는 통지 요청 메시지에서 응답 정보를 추출하여 응답 정보를 획득할 수 있다.

정리하면, M2M 장치는 응답 유형 파라미터에 따라서 응답 정보가 수신될 때까지 기다리거나, 일정 주기로 조회 요청 메시지를 송신하여 응답 정보를 수신하거나, 통지 요청 메시지를 수신하여 응답 정보를 추출할 수 있다. 이러한 응답 정보 수신 절차의 구분은 응답 유형 파라미터에 따라 구분되며, M2M 장치는 요청 메시지를 송신함에 있어서 응답 유형 파라미터를 확인하여, 각 절차를 구분하여 수행할 수 있다.

이 외에도 응답 유형 파라미터는 flexblocking으로 설정될 수도 있다. flexblocking은 수신측 M2M 장치가 응답 유형 파라미터를 동적으로 결정할 수 있음을 나타낸다. 즉, flexblocking 응답 유형 파라미터를 수신하는 수신측 M2M 장치는 응답 유형 파라미터를 수신측 M2M 장치의 설정 또는 편의에 따라 선택할 수 있다.

이하에서는 전술한 바와 같이 송신측 M2M 장치의 요청 메시지가 flexblocking 응답 유형 파라미터로 설정되는 경우 수신측 M2M 장치의 동작에 대해서 설명한다.

문제점

Receiver CSE에서 수신한 request message parameter에서 communication method를 알려주는 “Response Type”이 “flexBlocking”일 경우에, resource handling procedure나 또는 resource-specific procedure에서 별도로 정의하고 있지 않으면 local context (memory, processing capability, etc.)를 기반으로 communication method를 결정하여 응답해야 한다.

(참조: TS-0001-V2.10.0의 8.1.2 Request의 Response Type의 flexBlocking {~} 부분, TS-0001-V1.9.0의 7.2.2.2 Generic request procedure for receiver의 Figure 7.2.2.2-1: Generic procedure of Receiver의 Recv-2.0 절차)

8.1.2 Request

~ Response Type: optional response message type: Indicates what type of response shall be sent to the issued request and when the response shall be sent to the Originator: ~

flexBlocking {optional list of notification targets}: When Response Type in the request received by the Receiver CSE is set to flexBlocking, it means that the Originator of the request has the capability to accept the following types of responses: nonBlockingRequestSynch, nonBlockingRequestAsynch and blockingRequest.

The Receiver CSE shall make the decision to respond using blocking or non-blocking based on its own local context (memory, processing capability, etc.) if not defined in the resource handling procedure.

If the Receiver CSE choose to respond using non-blocking mode, based on the presence of notification targets in the request:

- If the notification targets are provided in the request and the Recerver CSE is responding, the Receiver CSE shall notify the result using nonBlockingRequestAsynch.

- If notification targets are not provided, the Receiver CSE shall respond with the address of <request> resource using nonBlockingRequestSynch.

~

7.2.2.2 Generic request procedure for receiver

~ Figure 7.2.2.2-1: Generic procedure of Receiver ~

Recv-2.0 "Communication method?": The Receiver CSE checks whether a received request is blockingRequest, nonBlockingRequestSynch or nonBlockingRequestAsynch by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is blockingRequest or Response Type parameter is not included, it goes to step Recv-6.0 "Resource handling procedure". If the request is nonBlockingRequestSynch, it goes to step Recv-3.0 "Create <request> resource locally" If the request is nonBlockingRequestAsynch, it goes to step Recv-3.0 "Create <request> resource locally". If the request is flexBlocking, the Receiver CSE shall make the decision to respond using blocking or non-blocking based on its own local context (memory, processing capability, etc.) unless specified further in the resource-specific procedure.

~

전술한 8.1.2 Request의 내용을 보면, Originator가 Response Type = flexBlocking으로 설정하고 Request를 하였다면 이 Originator는 blockingRequest, nonBlockingRequestAsynch, nonblockingRequestSynch 3가지 communication method를 모두 수용할 수 있음을 가정하고 있다.

그렇지만, Request primitive가 2 Hop 이상을 거쳐야 하는 경우에 이 Request primitive를 FORWARD 해야 하는 Transit CSE에 대해서는 3가지 communication method를 모두 수용할 수 있음을 체크하는 절차가 없는 문제점이 있다. 따라서 Transit CSE가 communication method 중 수용 가능한 Response Type(들)에 따라 Hosting CSE에서 전달하는 Response primitive가 Originator까지 정상적으로 전달될 수도 있고 또는 Transit CSE에서 에러가 발생하여 전달되지 못할 수도 있음 또는 Transit CSE가 수용할 수 있는 communication method가 있음에도 에러가 발생하여 전달되지 못할 수 있다. 그리고 이로 인해 CSE의 자원을 낭비하는 경우가 발생할 수 있으므로 이를 해결해야 한다.

도 4는 Generic procedure of Receiver를 도시한 도면이다. 도 5는 Resource handling procedure를 도시한 도면이다. 수신측 M2M 장치(전달 M2M 장치 포함)는 도 4 및 도 5의 절차를 통해서 응답 메시지를 전달 및 전송할 수 있다.

이하에서는, “flexBlocking” communication method가 2 hop에서 정상적으로 처리되는 경우에 대해서 각각의 응답 유형 파라미터 타입(Response Type)을 선택하여 처리하는 절차를 도면을 참조하여 설명한다.

도 6은 Receiver CSE가 Response Type으로 blockingRequest를 선택하는 동작을 설명하기 위한 도면이다. 도 6과 같이 Receiver CSE가 으로 blockingRequest로 선택하여 응답 메시지를 처리할 수 있다.

도 7은 Receiver CSE가 Response Type으로 nonBlockingRequestSynch를 선택하는 동작을 설명하기 위한 도면이다.

도 8은 Receiver CSE가 Response Type으로 nonBlockingRequestAsynch를 선택하는 동작을 설명하기 위한 도면이다.

도 9는 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestSynch를 선택하는 동작을 설명하기 위한 도면이다.

도 10은 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestAsynch를 선택하는 동작을 설명하기 위한 도면이다.

이와 같이, 응답 메시지 전달 경로의 Receiver CSE(Transit CSE)가 동일한 Response Type을 선택하는 경우에 응답 메시지가 정상적으로 전달될 수 있다. 또한, 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestSynch를 선택하는 경우에도 정상적으로 응답 메시지가 처리될 수 있다. 또한, 1Hop의 Receiver CSE(Transit CSE)는 Response Type으로 blockingRequest를 선택하고 2Hop의 Receiver CSE(Hosting CSE)는 Response Type으로 nonBlockingRequestAsynch를 선택하는 경우에도 정상적으로 응답 메시지가 처리될 수 있다.

다만, 아래와 같은 경우에 응답 메시지 처리에 오류가 발생할 수 있다.

도 11은 1Hop CSE(Transit CSE)는 “blockingRequest” communication method만 수용 가능하나 2Hop CSE(Hosting CSE)가 “nonBlockingRequestSynch” communication method를 선택하는 동작을 설명하기 위한 도면이다. 도 11을 참조하면, Transit CSE는 “blockingRequest” communication method만 수용 가능하나 Hosting CSE가 “nonBlockingRequestSynch” communication method를 선택하였을 경우에 Registrar/Transit CSE는 blockingRequest에 대한 응답을 기다리고 있기 때문에 Hosting CSE가 전달한 nonBlockingReqeustSynch communication method의 response primitive를 수신하지 못하고 있다가, 이후 request primitive에 대한 응답을 받지 못하였기 때문에 REQUEST_TIMEOUT 에러를 발생시킨다.

도 12는 1Hop CSE(Transit CSE)는 “blockingRequest” communication method만 수용 가능하나 2Hop CSE(Hosting CSE)가 “nonBlockingRequestAsynch” communication method를 선택하는 동작을 설명하기 위한 도면이다. 도 12를 참조하면, Transit CSE는 “blockingRequest” communication method만 수용 가능하나 Hosting CSE가 “nonBlockingRequestAsynch” communication method를 선택하였을 경우, Registrar/Transit CSE는 blockingRequest에 대한 응답을 기다리고 있기 때문에 Hosting CSE가 전달한 nonBlockingReqeustAsynch communication method의 response primitive를 수신하지 못하고 있다가, 이후 request primitive에 대한 응답을 받지 못하였기 때문에 REQUEST_TIMEOUT 에러를 발생시킨다.

이와 같이, 응답 메시지 전달 경로 상의 Receiver CSE(Transit CSE) 중 일부가 다른 Receiver CSE(Transit CSE)와는 다른 Response Type을 선택하거나, 일부 Receiver CSE(Transit CSE)가 다른 Receiver CSE(Transit CSE)는 지원하지 않는 Response Type을 선택하는 경우에 Response Type을 지원하지 않는 문제점이 발생하여 응답 메시지가 정상적으로 전달되지 않을 수 있다.

이러한 문제를 해결하기 위해서, 도 4의 절차에서 Response Type이 flexblocking로 설정되는 경우에 Receiver CSE(Transit CSE)의 동작을 아래와 같이 제한할 필요가 있다.

7.2.2.2 Generic request procedure for receiver

The Receiver shall execute the following steps in order. In case of error in any of the steps below, the Receiver shall execute "Create an error response" (refer to clause 7.3.3.13 for details) and then "Send Response primitive" (refer to clause 7.3.2.4 for details). The corresponding Response code shall be included in the Response primitive.

Figure 7.2.2.2-1: Generic procedure of Receiver

Recv-1.0 "Check the validity of received request primitive": See clause 7.3.2.1 for details.

Recv-2.0 "Communication method?": The Receiver CSE checks whether a received request is blockingRequest, nonBlockingRequestSynch or nonBlockingRequestAsynch by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is blockingRequest or Response Type parameter is not included, it goes to step Recv-6.0 "Resource handling procedure". If the request is nonBlockingRequestSynch, it goes to step Recv-3.0 "Create <request> resource locally" If the request is nonBlockingRequestAsynch, it goes to step Recv-3.0 "Create <request> resource locally". If the request is flexBlocking, the Receiver CSE shall make the decision to respond using blocking or non-blocking based on its own local context (memory, processing capability, etc.) unless specified further in the resource-specific procedure.

If the request is flexBlocking and the Receiver CSE decided to respond using blocking, the Receiver CSE shall set that Response Type of the received request primitive is blockingRequest or not include.

If the request is flexBlocking and the Receiver CSE decided to respond using non-blocking, the Receiver CSE shall set that Response Type of the received request primitive is nonBlockingRequestAsync or nonBlockingRequestSynch.

Recv-3.0 "Create <request> resource locally": Please refer to clause 7.3.2.2 for details.

~

도 13은 Resource handling procedure의 Forward 절차에 Response Type을 수정하는 프로세스 추가를 설명하기 위한 도면이다. 전술한 문제점을 해결하기 위한 또 다른 방법으로 도 5의 절차를 도 13과 같이 수정할 수 있다. 즉, 도 13과 같이 Receiver CSE에서 수행하는 도 5의 Resource handling procedure Forward 절차에 Response Type을 수정하는 프로세스를 추가할 수 있다.

도 13의 경우에 추가되는 절차는 아래와 같이 될 수 있다.

도 4의 각 절차에서 아래 밑줄 친 Recv-2.0 절차 설명 부분에 Response Type을 수정하는 내용이 추가될 수 있다.

~

Recv -6.1.1 Response Type is flexBlocking ?: The Receiver CSE checks whether a received request is flexBlocking by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is flexBlocking , it goes to step Recv -6.1.2 “Change the Response Type”.

Recv -6.1.2 “Change the Response Type”: The Receiver CSE shall set the Response Type parameter of the received request primitive to the Communication Method decided by the Receiver CSE . The Communication Method may be one of blockingRequest or nonBlockingRequestAsynch or nonBlockingRequestSynch. And the request primitive be forwarded to other CSE shall include Response Type parameter or not.

Recv-3.0 "Create <request> resource locally": Please refer to clause 7.3.2.2 for details.

~

전술한 본 실시예에 따르면, “flexBlocking” communication의 경우에도 Transit CSE는 “blockingRequest”나 “nonBlockingRequest” communication과 같이 하나의 communication method만 수용할 수 있는 프로세스를 activation 시켜 놓으면 되기 때문에 Transit CSE의 리소스를 최적으로 사용할 수 있다. 즉, Garbage process들을 최소화 할 수 있다.

또한, Hosting CSE에 의해 정상적으로 처리된 결과인 Response primitive가 Transit CSE의 communication method 수용 능력의 이슈로 인해 Originator까지 전달되지 못하고 중간에 에러로 처리되는 경우를 방지할 수 있다.

따라서, 수신측 동작은 아래와 같이 결정될 수 있다.

7.2.2.1 Generic request procedure for originator

~ Figure 7.2.2.1-1: Generic procedure of Originator ~

Orig-3.0 "Check Response Type": In this step, the Originator checks that the communication method is either blockingRequest, nonBlockingRequestSynch, nonBlockingRequestAsynch or flexBlocking by using the Response Type parameter (see detail in clause 8.1.2 in the oneM2M TS-0001 [6]). If the Response Type parameter does not exist, the communication method is ‘blockingRequest’ as specified at clause 6.4.1.

If the Response Type is blockingRequest it waits for Response primitive and goes to step Orig-4.0. If the Response Type is nonBlockingRequestSync, it waits for acknowledgement of the Response primitive and goes to step Orig-4.1. If the Response Type is nonBlockingRequestAsynch, it waits for acknowledgement of Response primitive and goes to step Orig-4.1. If the Response Type is flexBlocking, the Originator shall wait for a Response primitive as in Orig-4.0 and Orig-4.1 below, If the Response primitive is an acknowledgement it shall proceed according to Orig-4.1

~

flexBlocking을 사용한 Originator or Transit CSE는 Receiver CSE로부터 결정한 Response Type을 포함한 Response를 수신할 때까지 항상 blockingRequest와 nonBlockingRequest communication method를 모두 수용할 수 있도록 관련된 모든 프로세스를 activation 시켜 놓아야 한다.

도 14는 Resource handling procedure의 Forward 절차에 Transit CSE가 blocking과 nonBlocking method를 모두 수용 가능한지를 체크하는 프로세스 추가를 설명하기 위한 도면이다.

도 14를 참조하면, Transit CSE는 blocking과 nonBlocking method를 모두 수용 가능한지를 체크할 수 있다.

도 5의 절차에서 도 14에서와 같이 응답 타입이 flex blocking인지를 검토하는 단계가 추가될 수 있다.

구체적으로, 도 14를 참조하여 아래 두 단계의 동작이 수행될 수 있다.

Recv-6.1.1 Response Type is flexBlocking?: The Receiver CSE checks whether a received request is flexBlocking by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is flexBlocking, it goes to step Recv-6.1.2 “Change the Response Type”.

Recv-6.1.2 “Check the capability of communication method” Please refer to clause 7.3.2.9 for details.

수신측 M2M 장치는 blockingRequest, nonBlockingRequestSync, nonBlockingRequestAsync communication methods를 모두 수용할 수 있는지 체크해야 한다.

만일 communication methods 중 어느 하나라도 수용하지 못한다면, it shall reject the request with a “FLEX_BLOCKING_REQUEST_NOT_SUPPORTED” Response Status Code parameter value and not forward the request.

표 2는 도 14의 체크 동작을 위해서, RSCs for Receiver error response class에 FLEX_BLOCKIG_REQUEST_NOT_SUPPORTED error code를 추가한 일 예를 나타낸 표이다.

Numeric Code	Description
5213	FLEX_BLOCKIG_REQUEST_NOT_SUPPORTED

전술한 본 실시예들의 전부 또는 일부를 모두 수행할 수 있는 M2M 장치에 대해서 도면을 참조하여 간략히 다시 설명한다.

도 15는 일 실시예에 따른 수신측 M2M 장치를 개략적으로 도시한 도면이다.

도 15를 참조하면, 또 다른 실시예에 의한 수신측 M2M 장치(1000)는 제어부(1010)과 송신부(1020), 수신부(1030)을 포함한다.

제어부(1010)는 전술한 본 발명을 수행하기에 필요한 수신측 동작을 수행하는 데에 따른 전반적인 수신측 M2M 장치의 동작을 제어한다.

송신부(1020)와 수신부(1030)는 전술한 본 발명을 수행하기에 필요한 신호나 메시지, 데이터를 송신측 또는 전달 M2M 장치와 송수신하는데 사용된다.

또한, 본 실시예들은 컴퓨터 프로그램으로 구현될 수 있다. 예를 들어, 전술한 각 단계 또는 구성은 컴퓨터 프로그램 코드를 이용하여 각 기능으로 구현될 수 있다. 해당 프로그램을 구성하는 코드 및 코드 세그먼트는 당해 분야의 컴퓨터 프로그래머에 의하여 용이하게 추론될 수 있다.　또한, 상기 작성된 프로그램은 컴퓨터가 읽을 수 있는 기록매체(정보저장매체)에 저장되고, 컴퓨터에 의하여 판독되고 실행됨으로써 본 실시예를 구현할 수 있다. 그리고 상기 기록매체는 컴퓨터가 판독할 수 있는 모든 형태의 기록매체를 포함한다. 따라서, 전술한 본 실시예들을 구현한 컴퓨터 프로그램 또는 컴퓨터 프로그램을 포함하는 저장매체는 본 실시예의 범위에 포함되는 것으로 해석되어야 한다.

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

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

Claims (1)

1. M2M(Machine to machine communication) 장치가 응답 정보를 전송하는 방법에 있어서,
   요청 메시지를 수신하는 단계;
   상기 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계; 및
   상기 응답 유형 파라미터에 따라 응답 유형 파라미터를 결정하는 단계를 포함하되,
   상기 응답 유형 파라미터는, 플렉스블럭킹(flexblocking)으로 설정되는 것을 특징으로 하는 방법.

Images