KR20190104843A

KR20190104843A - 인터넷 접속이 단절된 사물통신 단말과 사물통신 서버의 통신 방법

Info

Publication number: KR20190104843A
Application number: KR1020180036133A
Authority: KR
Inventors: 김상언
Original assignee: 주식회사 케이티
Priority date: 2018-03-02
Filing date: 2018-03-28
Publication date: 2019-09-11

Abstract

본 개시는 M2M(Machine to Machine communication) 시스템에서 셀룰러 이동통신 기반의 단말장치가 사물통신 기능을 탑재하여 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 방법 및 그 장치에 관한 것이다. 일 실시예는 M2M(Machine to Machine communication) 장치가 사물통신을 수행하는 방법에 있어서, 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하는 단계를 포함하는 방법 및 장치를 제공한다.

Description

인터넷 접속이 단절된 사물통신 단말과 사물통신 서버의 통신 방법{Communication method for between M2M device which is not connect to Internet and M2M Server}

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, 셀룰러 이동통신 기반의 단말장치가 사물통신 기능을 탑재하여 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 방법 및 그 장치에 관한 것이다.

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

사물 통신은 통상적으로 사람이 직접적으로 통신과 응용 제어를 수행하지 않기 때문에, 사물 간에 메시지를 교환하기 위해서 송수신 방법과 절차와 필요하다. 또한, 사물통신을 위하여 단말장치가 인터넷 접속을 유지하여야 하는 필요성이 있다. 이와 반대로, 사물통신을 수행하는 단말장치는 소형의 가능성이 높으며, 장시간 동작을 수행하기 위해서 저전력이 요구될 수 있다. 따라서, 장시간 사물통신을 수행하기 위해서 절전 상태에서 인터넷 접속을 단절해야 하는 요구도 존재한다.

이와 같이, 사물통신을 위하여 단말장치가 인터넷 접속을 유지하여야 하는 요구와 장시간 사용하기 위하여 절전 상태에서 인터넷 접속을 단절하여야 하는 요구의 모순이 발생할 수 있다.

이러한 모순은 사물통신을 위한 단말 장치가 해결해야 할 필요가 있으나, 이에 대한 구체적인 동작 방법 및 기술적 해결방법이 제시되지 않고 있다.

전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to Machine communication) 장치가 사물통신을 수행하는 방법에 있어서, 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하는 단계를 포함하는 방법 및 장치를 제공한다.

도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 일 실시예에 따른 공통 서비스 개체의 기능적 구조를 도시한 도면이다.
도 5는 일 실시예에 따른 셀룰러 이동통신 기반의 단말장치에 도 4의 발신자가 공통서비스 개체를 탑재하거나, 도 1의 애플리케이션 개체를 탑재하거나, 공통서비스 개체와 애플리케이션을 모두 탑재하여 셀룰러 이동통신 네트워크(3GPP Trust Domain)를 통하여 사물통신을 수행하기 위한 기능적인 구조와 기능적인 장치간 인터페이스를 도시한 도면이다.
도 6은 일 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.
도 7은 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.
도 8은 또 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.
도 9는 또 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.
도 10은 일 실시예에 따른 단말 장치의 구성을 도시한 도면이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DIS(탐색) CSF는 주어진 범위와 주제 내에서 허락된 권한(M2M 서비스 구독에서 허락된 것을 포함)과 주어진 범위 내에서 발신자(Originator)의 요청에 해당하는 정보와 리소스를 검색하는 것을 책임진다. 발신자는 애플리케이션 또는 다른 CSE가 될 수 있다. 검색의 범위는 하나의 CSE가 되거나 다수의 CSE가 될 수 있다. 탐색 결과는 발신자에게 전달된다.

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

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

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

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

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

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

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

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

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

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

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

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

도 5는 일 실시예에 따른 셀룰러 이동통신 기반의 단말장치에 도 4의 발신자가 공통서비스 개체를 탑재하거나, 도 1의 애플리케이션 개체를 탑재하거나, 공통서비스 개체와 애플리케이션을 모두 탑재하여 셀룰러 이동통신 네트워크(3GPP Trust Domain)를 통하여 사물통신을 수행하기 위한 기능적인 구조와 기능적인 장치간 인터페이스를 도시한 도면이다.

도 5의 Field Domain은 도 2의 중계노드(200) 또는 응용서비스노드(210) 또는 응용서비스노드(220) 또는 응용전용노드(230, 240)를 의미하며, 이를 통칭하여 User Equipment (UE)라 한다. UE는 사물통신 기능을 처리하는 종단 장치 (Terminal Equipment: TE)와 셀룰러 이동통신 종단 장치 (Mobile Termination: MT)로 구성된다. TE와 MT는 참조점 R을 이용하여 인터페이스한다.

도 5의 3GPP Trust Domain은 도 2의 중계노드(200) 또는 응용서비스노드(210)와 기반노드(250)가 셀룰러 이동통신 네트워트를 이용하여 Mcc 인터페이스를 제공하는 구성요소와 인터페이스를 나타낸다.

UTRAN은 UMTS Terrestrial Radio Access Network를 의미하며, 광대역 부호 분할 다중 접속 (Wideband Code Division Multiple Access: W-CDMA) 기반의 무선 접속 기술을 지원하는 3세대 이동통신 시스템 (Universal Mobile Telecommunication System: UMTS) 무선 접속 네트워크이다.

E-UTRAN은 Evolved UMTS Terrestrial Radio Access Network를 의미하며, UTRAN에서 LTE (Long Term Evolution)를 사용할 수 있도록 진화된 무선 접속 네트워크이다.

SGSN은 Serving GPRS Support Node를 의미하며, W-CDMA에서 패킷 데이터를 처리하는 시스템이다.

C-SGN은 CIoT (Cellular Internet of Things) Serving Gateway Node를 의미하며, 사물통신에 필요한 MME, S-GW, P-GW의 기능을 수행한다. MME는 Mobility Management Entity를 의미하며 UE의 인증 및 UE가 인터넷을 사용하기 위한 논리적인 터널의 생성, 변경, 해지 등의 관리 및 UE의 이동성을 관리하는 시스템이다. S-GW는 Serving Gateway를 의미하며 E-UTRAN에서 발생하는 UE의 핸드오버시에 anchoring 기능 등을 처리한다. P-GW는 PDN (Packet Data Network) Gateway를 의미하며, UE에 IP (Internet Protocol) 주소를 할당하고, 핸드오버가 발생하는 경우 S-GW를 anchoring 기능 수행하며, UE별 QoS (Quality of Service)정책을 적용하는 등의 기능을 수행한다. 도 5의 C-SGN에서 M은 MME를 나타내고, S는 S-GW를 나타내고, P는 P-GW를 나타낸다.

SCEF는 Service Capability Exposure Function를 의미하며, 3GPP Trust Domain에서 제공하는 능력을 공개하는 기능을 제공한다.

SMS-SC는 Short Message Service - Service Center를 의미하며, SMS 메시지의 저장, 변환, 전달 등의 기능을 수행한다.

BM-SC는 Broadcast-Multicast Service Centre를 의미하며, MBMS 이용자 서비스 개통과 전달하는 기능을 수행한다.

MBMS-GW는 Multimedia Broadcast/Multicast Service gateway를 의미하며, MBMS 세션에 대한 서비스 시작. 종료 등의 제어 기능을 수행하며 무선 접속망에 인터넷 기반의 IP 멀티캐스트 전송방식을 이용하여 콘텐츠를 전달한다.

GMLC는 Gateway Mobile Location Centre를 의미하며, IN-CSE 기능을 수행하는 Service Capability Server　(SCS)에서 위치 서비스를 요청을 처리한다. GMLC는 SMLC (Serving Mobile Location center)와 통신하여 위치 정보를 받는다.

PCRF는 Policy Control and Charging Rules Function을 의미하며, UE 제어를 위한 정책 결정 및 과금 제어 기능을 제공하고, 정책을 위하여 생성된 규칙은 P-GW로 전달한다.

3GPP Trust Domain의 각 기능 요소들 사이의 기본적인 인터페이스는 다음과 같다.

- Uu: control plain and user plain between UE and UTRAN/E-UTRAN for EPS

- lu:control plane between UTRAN and SGSN

- S1-MME: control plane between E-UTRAN and C-SGN (part of MME) for EPS

- S1-U: user plane between E-UTRAN and C-SGN (part of S-GW) for EPS

- S3: control plane between SGSN and C-SGN (part of MME)

- S4: control plane between SGSN and C-SGN (part of S-GW)

- S12: user plane between UTRAN and C-SGN (part of S-GW)

- T6a: control plane between C-SGN (part of MME) and SCEF

- T6b: control plane between SGSN and SCEF

- SGi: control and user plane between C-SGN (part of P-GW) and SCS

- T8: control plane between SCEF and SCS

- T4: interface between MTC-IWF and SMS-SC

도 4의 그룹 관리 (Group Management) 공통 기능을 처리하기 위한 3GPP Trust Domain의 각 기능 요소들 사이의 인터페이스는 다음과 같다.

- MB2: interface between BM-SC and SCEF

- SGi: interface between BM-SC and C-SGN (part of P-GW)

- SGmb: interface between BM-SC and MBMS-GW

- Sm: interface between MBMS-GW and C-SGN (part of MME)

- Sn: interface between MBMS-GW and SGSN

도 4의 위치 (Location) 공통 기능을 처리하기 위한 3GPP Trust Domain의 각 기능 요소들 사이의 인터페이스는 다음과 같다.

- Le: interface between GMLC and SCS

- SLg: interface between GMLC and C-SGN (part of MME)

- Lg/Lgd: interface between GMLC and SGSN. Lg is based on Mobile Application Part (MAP), Lgd is based on Diameter.

도 4의 공통 기능의 정책을 처리하기 위한 3GPP Trust Domain의 각 기능 요소들 사이의 인터페이스는 다음과 같다.

- Nt: interface between SCEF and PCRF [9]

- Gx: interface between PCRF and C-SGN (part of P-GW)

3GPP Trust Domain의 각 기능 요소들 사이의 단문 메시지 또는 장치 트리거 메시지를 처리하기 위한 인터페이스는 다음과 같다.

- SGd: interface between SMS-SC and C-SGN (part of MME)

- Gdd: interface between SMS-SC and SGSN based on Diameter

도 5의 Infrastructure Domain은 도 2의 기반노드(Infrastructure Node, 250)을 나타낸다. Service Capability Server　(SCS)는 IN-CSE (Infrastructure Node - Common Service Entity) 기능을 수행한다. Application Server (AS)는 Infrastructure Node의 Application Entity 기능 수행한다.

3GPP Trust Domain과 Infrastructure Node의 인터페이스는 다음과 같다.

- T8: interface between SCEF in 3GPP domain and SCS as an IN-CSE

- Le: interface between GMLC in 3GPP domain and SCS as an IN-CSE

- SGi: interface C-SGN as part of P-GW in 3GPP domain and SCS as an IN-CSE

도 5와 같이 구성된 시스템에서 사물통신 기능을 처리하기 위한 UE는 경우에 따라 1년 이상 또는 5년이나 10년 이상 장기간 사용하는 애플리케이션도 있다. 이 경우 UE는 통신 및 정보 처리에 필요한 전력을 절감하기 위하여 수면 모드 또는 휴지 상태를 유지한다. 즉 데이터의 처리 또는 통신 기능을 수행하지 않는 경우에는 절전 상태로 전환된다. UE가 절전 상태인 경우, 인터넷에 접속하기 위한 IP 주소도 사용하지 않게 되어 인터넷에서 접속이 불가능한 문제점이 있다. 그러나 UE는 본질적으로 사물통신을 인터넷을 통하여 수행하므로 인터넷이 접속된 상태를 유지하여야 한다.

본 발명은 사물통신을 위하여 인터넷 접속을 유지하여야 하는 요구와 장시간 사용하기 위하여 절전 상태에서 인터넷 접속을 단절하여야 하는 요구의 모순을 해결하기 위한 방법을 고안한 것이다.

이러한 문제점을 해결하기 위해서, 기반노드 또는 기반노드의 애플리케이션에서 인터넷 접속이 단절된 사물통신 단말과 사물통신 기능을 수행하는 방법을 제안하고자 한다.

도 6은 본 발명의 일 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 사물통신 기능을 탑재하여 인터넷 접속이 단절된 수면 모드 또는 휴지 상태 등의 절전 상태에서 사물통신 기능을 수행하기 못하는 종래의 문제점을 해결하여 처리하는 절차를 나타내는 도면이다.

도 6을 참조하면, IN-CSE는 ASN-CSE, MN-CSE 또는 AND-AE에 디바이스 트리거 요청 (Device Trigger Request: DTR)을 시작한다. ASN-CSE, MN-CSE 또는 AND-AE가 IN-CSE에 연결을 요청 또는 IN-CSE에 M2M 등록하기 위한 요청 (M2M Enrolment Functions: MEF) 또는 PoA (Point of Address)를 업데이트 하기 위한 요청 또는 특정 자원의 생성, 수정, 조회, 삭제 등의 동작을 요청하기 위하여 시작할 수 있다. IN-CSE는 DTR을 자체적으로 시작하거나, AE에서 DTR을 수신하여 시작할 수 있다.

1단계: 대상 ASN-CSE, MN-CSE 또는 AND-AE에 요청

AE는 ASN-CSE, MN-CSE 또는 AND-AE에 IN-CSE에 있는 <triggerRequest> 자원을 생성하거나 업데이트하여 DTR을 시작할 수 있다. 또는 AE가 IN-CSE에서 연결되어 있지 않은 ASN-CSE, MN-CSE 또는 AND-AE에 DTR을 요청한 경우, IN-CSE는 <triggerRequest> 자원을 생성할 수 있다.

2단계: 디바이스 트리거 필요 여부 결정

IN-CSE는 ASN-CSE, MN-CSE 또는 AND-AE에 DTR의 송신 여부를 결정한다.

3단계: (선택사항) DNS 조회/응답

SCEF에 DTR을 전송하기 위하여, IN-CSE는 SCEF의 IP 주소와 포트를 결정하기 위하여 트리거 대상이 되는 ASN-CSE, MN-CSE 또는 AND-AE에 할당된 M2M-Ext-ID (M2M External Identifier) 를 이용하여 DNS 조회를 수행할 수 있다.

4단계: oneM2M 요청 메시지를 이용한 디바이스 트리거 요청 (Device Trigger Request)

IN-CSE가 전송하는 DTR 요청 메시지는 다음과 같은 정보를 포함하여야 한다.

· External Identifier: ASN-CSE, MN-CSE 또는 AND-AE를 탑재한 대상 UE의 M2M-Ext-ID를 설정하여야 한다.

· SCS Identifier: 통신사업자와 M2M 서비스 제공자가 미리 정한 값을 설정하여야 한다.

· TTRI (T8 Transaction Reference ID): 이 요청 메시지와 후의 응답 메시지를 연관시키기 위하여 사용한다. 이 값은 IN-CSE의 내부 정책에 따라 설정한다.

· TLTRI (T8 Long Term Transaction Reference ID): 트리거 요청을 식별하는데 이용한다. 이 값은 IN-CSE의 내부 정책에 따라 설정한다. 나중에, 요청을 다시 사용하도록 명령할 때, 다시 사용하기 위한 요청을 참조하기 위하여 이 값을 이용한다.

· Trigger Reference Number: 이 값은 IN-CSE의 내부 정책에 따라 설정한다.

· Validity Period: 이 값은 AE가 트리거 요청을 한 경우 <triggerRequest> 자원의 triggerValidityTime 속성 정보를 설정하거나, IN-CSE의 내부 정책에 따라 설정한다.

· Priority: IN-CSE의 내부 정책에 따라 설정한다.

· Application Port ID: 트리거 대상이 되는 ASN-CSE, MN-CSE 또는 AND-AE의 Trigger-Recipient-ID로 설정한다.

· The Trigger Payload (if present): 표 1과 같은 정보가 포함되어야 한다.

5단계: 연동을 위한 oneM2M 메시지 처리

SCEF는 TS 29.337에서 정의한 Diameter 프로토콜을 사용하는 T4 인터페이스를 통하여 DTR (Device Trigger Request)을 SMS-SC에 전송한다. 이때 IN-CSE에서 원래의 요청 메시지를 확인하기 oneM2M 메시지와 Diameter 메시지를 연관시키는데 사용하는 TTRI 값을 포함한다.

6단계: 디바이스 트리거 요청 전달 절차

ASN-CSE, MN-CSE 또는 AND-AE를 탑재한 UE에 트리거 메시지를 전달한다. UE가 UTRAN을 통하여 연결된 경우, SMS-SC는 DTR을 SGSN에 전달한다. UE가 E-UTRAN을 통하여 연결된 경우, SMS-SC는 DTR을 MME의 역할을 하는 C-SGN에 전달한다. DTR은 UTRAN이나 E-UTRAN에서는 NAS를 통하여 전달될 수 있다.

7단계: oneM2M 메시지 변환을 위한 디바이스 트리거 요청 메시지의 처리

UE가 DTR 메시지를 수신하면, UE는 oneM2M 메시지를 추출하여 처리한다.

트리거에 페이로드가 없는 경우, ASN-CSE, MN-CSE 또는 AND-AE는 이미 알고 있는 주소의 IN-CSE와 연결을 설정하기 위한 것으로 동작한다.

트리거에 페이로드가 있는 경우, ASN-CSE, MN-CSE 또는 AND-AE는 페이로드의 triggerPurpose의 정보를 이용하여 다음 단계를 수행하기 위한 적절한 동작을 결정한다.

8단계: 디바이스 트리거 응답 전달 절차

UE는 oneM2M 메시지를 처리한 후, 디바이스 트리거 응답 (Device Trigger Answer: DTA) 메시지를 SCEF에 보낸다. DTA의 성공, 실패, 또는 알 수 없음 등은 TS 29.327을 따른다. DTA 메시지는 SGSN 또는 MME 기능을 처리하는 C-SGN을 통하여 SCEF로 보낸다. UE의 연결에 따라, DTA메시지는 US와 SGSN 또는 UE와 MME간에 NAS를 통하여 전달할 수 있다.

9단계: 연동을 위한 디바이스 트리거 응답 처리

SCEF가 TS 29.337에서 규정한 Diameter를 사용하는 T4 인터페이스를 통하여 SMS-SC로부터 DTA를 수신하면, SCEF는 oneM2M과 Diameter의 연동을 위하여 oneM2M 응답 메시지로 변환한다.

10단계: oneM2M 응답메시지를 이용한 디바이스 트리거 응답

SCEF에서 DTA를 처리한 후, SCEF는 oneM2M 응답메시지를 IN-CSE 역할을 하는 SCS의 발신자에게 보낸다.

11단계 (선택사항): oneM2M 요청 메시지를 이용한 전달 보고 요청

IN-CSE는 전달 보고 요청 (Delivery Report Request: DRR) 을 위한 oneM2M 요청 메시지를 보낼 수 있다. 이 요청 메시지는 표 1의 triggerPurpose 속성 값을 triggerDeliveryReport로 설정하여 <triggerRequest>를 구성한다.

12단계 (선택사항): 전달 요청 보고 메시지의 전달 절차

SCEF는 oneM2M 요청 메시지를 Diameter 기반의 전달 요청 보고 메시지로 변환하여 SMS-SC를 통하여 SGSN 또는 MME의 일부인 C-SGN으로 보낸다.

13단계 (선택사항): 전달 보고 응답 메시지의 전달 절차

SGSN 또는 MME의 일부인 C-SGN은 전달 보고 응답 메시지를 SCEF에 보낸다.

14단계 (선택사항): oneM2M 응답 메시지를 이용한 전달 보고 응답

SCEF에서 전달 보고 응답 메시지를 처리하고, SCEF는 oneM2M 응답 메시지를 발신자에게 보낸다.

Attributes of *<triggerRequest>*	Multiplicity	RW/ RO/ WO	Description
resourceType	1	RO	See clause 9.6.1.3.
resourceID	1	RO	See clause 9.6.1.3.
resourceName	1	WO	See clause 9.6.1.3.
parentID	1	RO	See clause 9.6.1.3.
creationTime	1	RO	See clause 9.6.1.3.
lastModifiedTime	1	RO	See clause 9.6.1.3.
expirationTime	1	RW	See clause 9.6.1.3.
accessControlPolicyIDs	0..1 (L)	RW	See clause 9.6.1.3.
Labels	0..1 (L)	RW	See clause 9.6.1.3.
dynamicAuthorizationConsultationIDs	0..1 (L)	RW	See clause 9.6.1.3.
M2M-Ext-ID	1	WO	M2M External Identifier of the device being triggered. See clause 7.1.8. This attribute shall be configured by the Originator when the resource is created.
Trigger-Recipient-ID	1	RW	Trigger-Recipient-ID of the ASN/MN-CSE or ADN-AE that is hosted on the device being triggered. See　clause 7.1.10. This attribute shall be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2.
triggerPurpose	1	RW	The purposeof the trigger. See　clause 8.3.3.2.1. This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. The allowed values are: establishConnection enrolmentRequest registrationRequest executeCRUD triggerDeliveryReport If not specified by the Originator, the default is "establishConnection".
triggerPayloadSerialization	1	RW	The type of serialization used to encode the trigger payload (i.e. XML, JSON or CBOR). This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2. If not specificied by the Originator, the default is "JSON".
triggerStatus	1	RO	The status of the trigger request. The Hosting CSE shall control the value of this attribute. The following values are valid values. · PROCESSING · ERROR-NSE-NOT-FOUND · TRIGGER-SUBMITTED · TRIGGER-DELIVERED · TRIGGER-FAILED · ABSENT-SUBSCRIBER · UE-MEMORY-CAPACITY-EXCEEDED · SUCCESSFUL-TRANSFER · VALIDITY-TIME-EXPIRED
triggerValidityTime	0..1	RW	The time durationfor which the trigger request is valid. After this time expires, the trigger shall be recalled (i.e. cancelled) by the Hosting CSE. This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2.
triggerInfoAE-ID	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the AE-ID of the ASN/MN-AE that should perform the CRUD operation. When this attribute is configured, the trigger originator shall also configure the triggerInfoAddress, triggerInfoOperation and targetedResouceType attributes.
triggerInfoAddress	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with an unstructured CSE-Relative-Resource-ID of the resource that the ASN/MN-AE should perform the CRUD operation on. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoOperation and targetedResouceType attributes.
triggerInfoOperation	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the CRUD operation that the ASN/MN-AE should perform on the targeted resource specified by triggerInfoAddress. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoAddress and targetedResouceType attributes.
targetedResourceType	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the resource type of the targeted resource specified by triggerInfoAddress. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoAddress and triggerInfoOperation attributes.
triggerReference	0..1	WO	This attribute is reference numberto trace Device Trigger Request and Delivery Report Request
triggerPriority	0..1	RW	This attribute is priority for Device Trigger Request either low priority or high priority.
triggerDeviceDiagnostic	0..1	RW	This attribute may use Delivery Report Request to check the reason for error.
triggerPortID	0..1	RW	This attribute is application port ID for device trigger.
t8TransactionRef	0..1	WO	This attribute is transaction reference identifier between IN-CSE for SCS and SCEF.

도 7은 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.

ASN/MN-CSE 또는 ADN-AE를 호스팅하는 UE는 연결 설정 방법의 onf를 사용하여 Device Trigger Request를 수신 할 수 있다.

1단계: 대상 ASN-CSE, MN-CSE 또는 AND-AE에 요청 - 1 단계는 선택적 사항

AE는 IN-CSE에서 호스트되는 <triggerRequest> 자원을 생성하거나 업데이트함으로써 ASN / MN-CSE 또는 ADN-AE에 대한 장치 트리거 요청을 시작할 수 있다. 또는, AE는 장치 트리거링을 필요로하는 IN-CSE에 요청을 발행함으로써 암시적으로 ASN / MN-CSE 또는 ADN-AE에 대한 장치 트리거 요청을 시작할 수 있다. 예를 들어, IN-CSE가 IN-CSE가 도달 할 수없는 ASN / MN-CSE 또는 ADN-AE를 대상으로 CRUD 작업을 수행하기위한 AE 요청을 수신하면 IN-CSE는 <triggerRequest> 자원을 생성 할 수 있다(An AE may initiate a Device Trigger Request to an ASN/MN-CSE or ADN-AE explicity by creating or updating a <triggerRequest> resource hosted on an IN-CSE as defined at clause 9.6.49 in TS-0001 [1]. Alternatively, an AE may initiate a Device Trigger Request to an ASN/MN-CSE or ADN-AE implicitly by issuing a request to an IN-CSE that requires device triggering. For example, if an IN-CSE receives an AE request to perform a CRUD operation targeting an ASN/MN-CSE or ADN-AE that is not reachable by the IN-CSE, the IN-CSE may generate a <triggerRequest>.).

2단계: 디바이스 트리거 필요 여부 결정

IN-CSE는 대상 ASN / MN-CSE 또는 ADN-AE에 장치 트리거 요청을 보낼지 여부를 결정한다(The IN-CSE determines whether to send a Device Trigger Request to the targeted ASN/MN-CSE or ADN-AE. Further details are provided in clause 8.3.3.2.1 of oneM2M TS-0001　[1].).

3단계: oneM2M 요청 메시지에 의한 장치 트리거 요청

IN-CSE는 Device Trigger Request에 대한 요청 메시지를 전송한다. 전송되는 요청 메시지에는 다음과 같은 정보가 포함된다.

● externalId shall be set to the M2M-Ext-ID of the targeted UE hosting an ASN/MN-CSE or ADN-AE.

● scsAsId shall be set to a value that is prearranged between the Service Provider and MNO.

● tltrId is used to identify the trigger request. It shall be assigned based on internal IN-CSE polices and shall be different from other tltrIds issued by this IN-CSE during the lifetime of this request. Later, if the request needs to be recalled, this value will be used to reference the request that needs to be recalled.

● trigger-Reference-Number shall be set to a value assigned based on internal IN-CSE polices and shall be different from other triggers issued by this IN-CSE during the lifetime of this request.

● validity-Period shall be set to either the triggerValidityTime attribute of the <triggerRequest> resource if the trigger request is initiated by an AE or otherwise by IN-CSE internal policies.

● priority may be set to either PRIORITY or NO_PRIORITY per internal IN-CSE policies and/or agreements between the Service Provider and MNO.

● application-Port-ID shall be set to Trigger-Recipient-ID of the targeted ASN/MN-CSE or ADN-AE.

● trigger-Payload (if present) shall be configured as described in clause 9.6.49 of oneM2M TS 0001 [1] and clause 9.2.1 of TS-0004 [4]. An empty payload indicates that the targeted ASN/MN-CSE or ADN-AE shall re-establish connectivity with the IN-CSE.

4단계: 연동을 위한 oneM2M 메시지 처리

SCEF는 one M2M 메시지와 Diameter 프로토콜을 사용하는 Diameter 메시지 사이의 연동을 위한 요청 메시지를 변환해야한다. 예를 들어, The SCEF shall convert Request message for interworking between oneM2M [1] and Diameter [i.3].

5단계: 디바이스 트리거 요청 전달 절차

ASN-CSE, MN-CSE 또는 AND-AE를 탑재한 UE에 트리거 메시지를 전달한다. DTR은 NAS를 통해 전달할 수 있다.

6단계: ASN-CSE, MN-CSE 또는 ADN-AE 프로세스 트리거

UE가 DTR을 수신하면, UE는 oneM2M 메시지를 추출하고 처리한다. 트리거에 페이로드가 없으면, IN-CSE의 주소가 ASN-CSE, MN-CSE 또는 ADN-AE에 알려지지 않은 경우. ASN-CSE, MN-CSE 또는 ADN-AE는 IN-CSE와의 연결을 재설정해야한다(If the trigger has no payload, the ASN/MN-CSE or ADN-AE shall re-establish connectivity with the IN-CSE. If the address of the IN-CSE is not known to the ASN/MN-CSE or ADN-AE.).

7단계: 디바이스 트리거 응답 전달 절차

UE는 oneM2M 메시지를 처리한 후, 디바이스 트리거 응답 (Device Trigger Answer: DTA) 메시지를 SCEF에 보낸다. DTA의 성공, 실패, 또는 알 수 없음 등은 TS 29.327을 따른다. UE는 DTA 메시지를 SCEF로 전송한다.

8단계: 연동을 위한 디바이스 트리거 응답 처리

SCEF가 TS 29.337에 정의 된 Diameter를 사용하는 UE로부터 DTA를 수신하면, SCEF는 oneM2M과 Diameter 사이의 연동을위한 oneM2M 응답 메시지로 변환해야한다.

9단계: oneM2M 응답메시지를 이용한 디바이스 트리거 응답

SCEF에서 DTA를 처리한 후, SCEF는 oneM2M 응답메시지를 발신자에게 보낸다.

10단계 (선택사항): oneM2M 요청 메시지를 이용한 전달 보고 요청

IN-CSE 또는 AE는 전달 보고 요청 (Delivery Report Request: DRR) 을 위한 oneM2M 요청 메시지를 보낼 수 있다. 이 요청 메시지는 표 1의 triggerPurpose 속성 값을 triggerDeliveryReport로 설정하여 <triggerRequest>를 구성한다.

11단계 (선택사항): 전달 보고 요청 메시지의 전달 절차

SCEF는 oneM2M 요청 메시지를 Diameter 기반의 전달 보고 요청 메시지로 변환하여 적절한 3GPP 네트워크 개체로 보낸다.

12단계 (선택사항): 전달 보고 응답 메시지의 전달 절차

전달 보고 요청 메시지를 수신한 3GPP 네트워크 개체는 전달 보고 응답 메시지를 SCEF에 보낸다.

13단계 (선택사항): oneM2M 응답 메시지를 이용한 전달 보고 응답

SCEF에서 전달 보고 응답 메시지를 처리하고, SCEF는 oneM2M 응답 메시지를 발신자에게 보내야 한다.

14단계: ASN-CSE, MN-CSE 또는 ADN의 트리거 동작 수행

ASN-CSE, MN-CSE 또는 ADN-AE는 수신된 트리거 요청 유형에 기반하여 IN-CSE와의 연결성 확립, MEF 등록, IN-CSE에 등록, PoA 업데이트 또는 지정된 자원에 대한 CRUD 요청을 실행할 수 있습니다.

도 8은 또 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.

도 8을 참조하면, ASN-CSE, MN-CSE 또는 ADN-AE를 호스팅하는 UE는 연결 설정 방법을 사용하여 DTR (Device Trigger Request)을 수신 할 수 있다.

1단계(선택사항): ASN-CSE, MN-CSE 또는 ADN-AE를 대상으로 한 요청

AE는 IN-CSE에서 호스트되는 <triggerRequest> 자원을 생성하거나 업데이트함으로써 ASN-CSE, MN-CSE 또는 ADN-AE에 대한 DTR을 시작할 수 있다. 또는, AE는 장치 트리거링을 필요로하는 IN-CSE에 요청을 발행함으로써 암시적으로 ASN-CSE, MN-CSE 또는 ADN-AE에 대한 DTR을 개시 할 수 있다. 예를 들어, IN-CSE가 IN-CSE가 도달 할 수 없는 ASN-CSE, MN-CSE 또는 ADN-AE를 대상으로 CRUD 작업을 수행하기위한 AE 요청을 수신하면, IN-CSE는 트리거 요청을 생성 할 수 있다.

2단계: 장치 트리거링이 필요한지 결정

IN-CSE는 대상 ASN-CSE, MN-CSE 또는 ADN-AE로 DTR 메시지를 보낼지 여부를 결정한다. 자세한 내용은 oneM2M TS 0001의 8.3.3.2.1 절을 참조할 수 있다.

IN-CSE가 oneM2M 메시지를 수신하면 IN-CSE는 3GPP TS 29.122에 정의된 절차에 따라 one M2M 메시지를 T8 API로 대체해야 한다.

3단계: 장치 트리거링

IN-CSE는 아래에 나열된 정보가 포함되는 DTR 메시지를 전송한다.

● scsAsd는 서비스 제공 업체와 MNO간에 미리 정해진 값으로 설정됩니다.

● triggerReferenceNumber는 내부 IN-CSE 정책에 따라 할당 된 값으로 설정되어야하며 이 요청의 수명 또는 <triggerRequest> 리소스의 triggerReference 속성 중에이 IN-CSE가 발급한 다른 트리거와 달라야한다.

● validityPeriod는 트리거 요청이 AE에 의해 초기화되거나 IN-CSE 내부 정책에 의해 초기화되는 경우 <triggerRequest> 리소스의 expirationTime 속성으로 설정됩니다.

● triggerPayload (있는 경우)는 oneM2M TS 0001의 9.6.49 절과 TS-0004의 9.2.1 절에 설명된대로 구성되어야합니다. 빈 페이로드는 대상 ASN-CSE, MN-CSE 또는 ADN-AE가 IN-CSE와의 연결을 다시 설정해야 함을 나타냅니다.

다음 정보가 포함될 수 있습니다.

● id는 ASN-CSE, MN-CSE 또는 ADN-AE를 호스팅하는 대상 UE의 M2M-Ext-ID로 설정할 수 있습니다.

● tltrId는 트리거 요청을 식별하는 데 사용됩니다. 이것은 내부 IN-CSE 정책을 기반으로 할당되며 이 요청이 지속되는 동안이 IN-CSE가 발급 한 다른 정보와는 다릅니다. 나중에 요청을 다시 호출해야하는 경우 이 값은 호출해야하는 요청을 참조하는데 사용됩니다.

● priority는 내부 IN-CSE 정책에 따라 PRIORITY 또는 NO_PRIORITY 또는 <triggerRequest> 리소스의 triggerPriority 속성으로 설정할 수 있습니다.

● applicationPortId는 대상 ASN-CSE, MN-CSE 또는 ADN-AE에 대한 <triggerRequest> 리소스의 triggerPortID 속성으로 설정할 수 있습니다.

● self는 IN-CSE의 <triggerRequest> 리소스의 resourceID로 설정할 수 있습니다.

● notificationDestination은 IN-CSE 식별자로 설정할 수 있습니다.

● requestTestNotification은 <triggerRequest>의 triggeRequestTestNotification으로 설정 될 수 있습니다.

● webSockNotifConfig는 <triggerRequest>의 triggeNotificationWebsocket으로 설정할 수 있습니다.

4단계: DeviceTriggeringDeliveryReportNotification 또는 DeviceTriggering

전술한 3단계를 확인하기 위해서 SCEF는 3GPP TS 29.122 [5]에 명시된 정보가 포함 된 DeviceTriggering을 보냅니다. 그러한 정보는 다음을 포함해야한다.

● scsAsId는 서비스 제공 업체와 MNO간에 미리 정해진 값으로 설정됩니다.

● triggerReferenceNumber는 내부 IN-CSE 정책을 기반으로 할당 된 값으로 설정되어야하며 이 요청의 수명 동안에 해당 IN-CSE가 발급한 다른 트리거 또는 <triggerRequest> 리소스의 triggerReference 속성과 달라야합니다.

● validityPeriod는 트리거 요청이 AE에 의해 초기화되거나 IN-CSE 내부 정책에 의해 시작된 경우, <triggerRequest> 리소스의 triggerValidityTime 속성으로 설정됩니다.

● triggerPayload (있는 경우)는 OneM2M TS-0004의 9.2.1 절 및 TS-0001의 8.3.3.2.1절의 설명에 따라 구성되어야합니다. 빈 페이로드는 대상 ASN-CSE, MN-CSE 또는 ADN-AE가 IN-CSE와의 연결을 다시 설정해야 함을 나타냅니다.

● deliveryResult는 3GPP TS 29.122에서 정의된 장치 트리거링 상태를 나타내는 HTTP 응답에 포함됩니다

또한, 다음 정보가 포함될 수 있습니다.

● tltrId는 트리거 요청을 식별하는데 사용됩니다. 이것은 내부 IN-CSE 정책을 기반으로 할당되며, 해당 요청이 지속되는 동안이 IN-CSE가 발급한 다른 tltrId과는 다릅니다. 나중에 요청을 다시 호출해야하는 경우 이 값은 호출해야하는 요청을 참조하는데 사용됩니다.

● priority는 내부 IN-CSE 정책 및/또는 서비스 제공 업체와 MNO 또는 <triggerRequest> 리소스의 triggerPriority 속성 간의 계약에 따라 PRIORITY 또는 NO_PRIORITY로 설정될 수 있습니다.

● notificationDestination은 SCEF가 Device Trigger 알림을 대상으로 지정할 수있는 URI로 구성 될 수 있습니다. 이 URI의 값은 내부 IN-CSE 정책 또는 IN-CSE 식별자를 기반으로합니다.

● requestTestNotification은 <triggerRequest>의 triggeRequestTestNotification으로 설정될 수 있습니다.

● webSockNotifConfig는 <triggerRequest>의 triggeNotificationWebsocket으로 설정될 수 있습니다.

5단계: 장치 트리거 요청 전달 절차

3GPP 네트워크 개체는 ASN-CSE, MN-CSE 또는 ADN-AE를 호스팅하는 UE에 DTR 메시지를 전달한다.

6단계: DeviceTriggeringDeliveryReportNotification

SCEF는 3GPP TS23.682에서 기술된 바와 같이 모바일 코어 네트워크와 함께 디바이스 트리거 요구를 처리한다. SCEF는 트리거 전달 결과를 나타 내기 위해 DeviceTriggeringDeliveryReportNotification을 IN-CSE로 전송한다. SCEF는 전달이 성공했는지, 알려지지 않았는지(unknown) 또는 실패했는지를 지시한다. 이 메시지는 3GPP TS 29.122에 정의되어 있으며 다음 정보를 포함해야한다.

● transactionId는 이 장치를 트리거하기 위해 SCEF가 선택한 식별자이다.

● transaction은 트랜잭션 리소스를 트리거하는 관련 장치에 대한 링크에 포함됩니다.

● result는 3GPP TS 29.122에서 정의된대로 OK, unknown 또는 다양한 오류에 대한 정보입니다.

또한, 다음 정보가 포함될 수 있습니다.

● tltrId는 요청 메시지와 동일하다.

7단계(선택사항) 및 8단계: IN-CSE는 <triggerRequest> 및 1a 또는 1b에 대한 응답을 업데이트

장치 트리거가 <triggerRequest> 리소스를 통해 AE에 의해 시작된 경우, IN-CSE는 트리거 상태 정보로 <triggerRequest> 리소스를 업데이트 할 수 있습니다.

9단계: ASN-CSE, MN-CSE 또는 ADN-AE가 트리거 동작 수행

트리거에 페이로드가 없으면, ASN-CSE, MN-CSE 또는 ADN-AE는 IN-CSE와의 연결을 재설정해야합니다. IN-CSE의 주소가 ASN-CSE, MN-CSE 또는 ADN에 알려지지 않은 경우.

ASN, MN-CSE 또는 ADN-AE는 수신된 트리거 요청 유형에 기반하여 IN-CSE와의 연결성 확립, MEF 등록, IN-CSE에 등록, PoA 업데이트, 또는 지정된 자원에 대해 CRUD 요청을 실행할 수 있습니다.

더 자세한 내용은 oneM2M TS-0004의 9.2.1 절 및 TS 0001의 8.3.3.2.1 절에 설명을 참조할 수 있습니다.

도 9는 또 다른 실시예에 따른 셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하기 위한 절차를 도시한 도면이다.

ASN / MN-CSE 또는 ADN-AE를 호스팅하는 UE는 연결 설정 방법 중 하나를 사용하여 장치 트리거를 수신할 수 있다.

도 9의 절차는 API의 응답 및 요청을 보다 상세하게 설명합니다. 예를 들어, DeviceTriggering 요청, DeviceTriggering에 대한 응답, 디바이스 트리거링 요청이 없기 때문에 DeviceTriggeringDeliveryReportNotification 알림, DeviceTriggering 응답, DeviceTriggeringDeliveryReportNotification 요청 및 DeviceTriggeringDeliveryReportNotification 응답 등을 상세하게 설명한다.

일 예로, 아래의 3a 단계는 deliveryResult 속성을 포함하지 않아야한다.

다른 예로, 아래의 3b 단계는 DeviceTriggering 메시지를 사용하여 수신 확인을 하기위한 것으로, 예외가 있는 deliveryResult 특성이 포함됩니다. 이것은 Tsp 인터페이스 인 Diameter 프로토콜에서의 Device Trigger Confirm 확인과 같습니다.

또 다른 예로, 아래의 5 단계는 3 단계의 응답을 위한 단계로, 단계 3b는 선택적이므로 IN CSE는 단계 3a의 결과를 알아야합니다. deliveryResult 속성은 3b 단계와 5 단계에서 서로 다릅니다.

deliveryResult의 값은 CONFIRMED, EXPIRED 및 UNCONFIRMED 중에서 4 단계에서 선택할 수 있습니다. 5b 단계에서 SUCCESS, UNKNOWN, FAILURE, EXPIRED가 가능합니다.

TS-0001은 자원 유형 triggerRequest에 대해 trigerStatus 값 중 하나에 대해 TRIGGER-DELIVERED가 9.6.49 절에 명확하게 지정되어 있습니다. 5 단계가 없으면 IN-CSE는 TRIGGER-DELIVERED에 대해 triggerStatus를 가질 수 없습니다.

구체적인 단계는 아래의 내용을 참조하여 설명한다.

도 9를 참조하면, 아래와 같은 순서에 따라 트리거 절차가 수행될 수 있다. 아래의 각 단계의 일부가 생략되거나, 특정 단계가 추가될 수도 있으며, 필요에 따라 그 순서가 바뀔 수도 있다.

제 1 단계(선택사항): Request targeted to ASN/MN-CSE or ADN-AE

AE는 OneM2M TS-0001의 9.6.49 절에 명시된대로 <triggerRequest> 자원을 생성하거나 업데이트함으로써, ASN / MN-CSE 또는 ADN-AE에 대한 장치 트리거를 명시 적으로 시작할 수 있습니다. 또는, AE는 장치 트리거링을 필요로하는 IN-CSE에 요청을 발행함으로써 암시적으로 ASN / MN-CSE 또는 ADN-AE에 대한 장치 트리거를 시작할 수 있습니다. 예를 들어, IN-CSE가 IN-CSE가 도달 할 수없는 ASN / MN-CSE 또는 ADN-AE를 대상으로 CRUD 작업을 수행하기위한 AE 요청을 수신하면, IN-CSE는 트리거 요청을 생성 할 수 있습니다.

제 2 단계: Determine if Device Triggering is required

IN-CSE는 타켓 ASN / MN-CSE 또는 ADN-AE에 장치 트리거를 보낼지 여부를 결정합니다. 자세한 내용은 oneM2M TS 0001의 8.3.3.2.1 절을 참조할 수 있다.

IN-CSE가 OneM2M 요청 메시지를 수신하면 IN-CSE는 3GPP TS 29.122에 정의 된 T8 API로 대체한다.

제 3a 단계: request for Device Triggering

IN-CSE는 3GPP TS 29.122에 명시된 정보가 포함된 DeviceTriggering 메시지를 보낸다.

예를 들어, 명시된 정보는 아래의 정보를 포함해야 한다.

● id는 ASN/MN-CSE 또는 ADN-AE를 탑재한 타겟 UE (User Equipment)의 M2M-Ext-ID로 설정한다.

● scsAsId는 서비스 제공 업체와 이동통신사업자(MNO: Mobile Network Operator)간에 미리 정해진 값으로 설정한다.

● triggerReferenceNumber는 내부 IN-CSE 정책에 따라 할당 된 값으로 설정하며 요청의 수명기간 동안에 IN-CSE가 발급한 다른 트리거 또는 <triggerRequest> 리소스의 triggerReference 속성으로 설정한다.

● tltrId는 트리거 요청을 식별하는데 이용한다. 이 값은 IN-CSE의 정책에 따라 할당하며, 이 요청의 수명 기간 또는 <triggerRequest> 리소스의 triggerReference 속성 중에 해당 IN-CSE가 발급한 다른 tltrId와 다르게 한다.

● validityPeriod는 트리거 요청이 AE에 의해 초기화되거나 IN-CSE 내부 정책에 의해 시작된 경우 <triggerRequest> 리소스의 triggerValidityTime 속성으로 설정한다.

● triggerPayload (있는 경우)는 oneM2M TS 0001의 8.3.3.2.1 절과 TS-0004의 9.2.1 절에 설명된대로 구성한다. 페이로드의 정보가 없는 경우에는 대상 ASN-CSE, MN-CSE 또는 ADN-AE가 IN-CSE와의 연결을 다시 설정해야 함을 나타낸다.

또한, 명시된 정보는 다음 정보를 포함할 수 있다.

● priority는 내부 IN-CSE 정책 및/또는 서비스 제공 업체와 MNO 또는 <triggerRequest> 리소스의 triggerPriority 속성 간의 계약에 따라 PRIORITY 또는 NO_PRIORITY로 설정될 수 있다.

● applicationPortID는 대상 ASN/MN-CSE 또는 ADN-AE에 대한 <triggerRequest> 리소스의 triggerPortID 속성으로 설정될 수 있다.

● notificationDestination은 SCEF가 Device Trigger notification을 대상으로 지정할 수있는 URI로 구성 될 수 있다. 이 URI의 값은 내부 IN-CSE 정책 또는 IN-CSE 식별자를 기반으로 한다.

● self는 IN-CSE의 <triggerRequest> 리소스의 resourceID로 설정될 수 있다.

● requestTestNotification은 <triggerRequest>의 triggeRequestTestNotification으로 설정될 수 있다.

● webSockNotifConfig는 <triggerRequest>의 triggeNotificationWebsocket으로 설정될 수 있다.

다만, 아래의 일반적인 예외사항이 적용될 수 있다.

SCEF는 IN-CSE가 DeviceTriggering 메시지를 보내려고 할 때 SCEF에 연결할 수 없는 경우, IN-CSE는 이전의 타임 아웃 기간(IN-CSEcse 로컬 정책) 후에 <triggerRequest>의 triggerStatus 속성을 ERROR_NSE_NOT_FOUND로 업데이트해야 한다.

제 3b 단계(선택사항): response to DeviceTriggering

단계 3a의 처리 확인을 위해 SCEF는 3GPP TS 29.122에 명시된 정보를 포함하는 DeviceTriggering 메시지를 IN-CSE로 보낼 수 있다.

해당 메시지는 아래의 정보를 포함해야 한다.

● scsAsId는 단계 3a의 scsAsId 값과 동일한 값으로 설정한다.

● triggerReferenceNumber는 단계 3a의 triggerReferenceNumber 값과 동일한 값으로 설정한다.

● validityPeriod는 단계 3a의 validityPeriod 값과 동일한 값으로 설정한다.

● triggerPayload (있는 경우)는 단계 3a의 triggerPayload 값과 동일하게 구성한다. 페이로드의 정보가 없는 경우에는 대상 ASN-CSE, MN-CSE 또는 ADN-AE가 IN-CSE와의 연결을 다시 설정하는 것을 나타낸다.

● id는이 DeviceTriggering 메시지에 대해 SCEF가 선택한 식별자입니다.

● tltrId는 단계 3a의 tltrId 값과 동일하게 설정한다.

● self는 요청을 위해 SCEF에 의해 생성 된 자원에 대한 링크로 구성한다.

● deliveryResult는 확인을 위한 아래 상태 중 하나를 나타내는 HTTP 응답에 포함된다.

- CONFIRMED : 장치 트리거링 요청 메시지를 전달하기 위한 준비가 완료된 것을 확인되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_CONFIRMED로 갱신해야 한다.

- EXPIRED: 장치 트리거링 요청 메시지의 전달을 시작하기 전에 유효 기간이 만료되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_EXPIRED로 갱신해야 한다.

- UNCONFIRMED : 장치 동작 요청 메시지를 전달하기 위한 준비가 확인되지 않음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_UNCONFIRMED로 업데이트해야 한다.

또한, 다음 정보가 포함될 수 있습니다.

● priority는 단계 3a의 요청 메시지의 priority 정보와 동일하게 설정할 수 있다.

● applicationPortID는 단계 3a의 요청 메시지의 applicationPortID 정보와 동일하게 설정할 수 있다.

● notificationDestination은 단계 3a의 요청 메시지의 notificationDestination 정보와 동일하게 설정할 수 있다.

● requestTestNotification은 단계 3a의 요청 메시지의 requestTestNotification 정보와 동일하게 설정할 수 있다.

● webSockNotifConfig는 단계 3a의 요청 메시지의 webSockNotifConfig 정보와 동일하게 설정할 수 있다.

다만, 아래의 일반적인 예외사항이 적용될 수 있다.

SCEF는 오류 발생시 응답 코드를 전송한다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_UNCONFIRMED로 업데이트할 수 있다.

- 잘못된 요청(Bad Request) : 잘못된 매개 변수가 요청에 포함되면 SCEF는 이 응답을 보내야 한다.

- Unauthorized: IN-CSE로부터 요청을 받으면 SCEF는 서비스에 액세스하기위한 인증 자격 증명에 대한 권한을 포함하여 IN-CSE가 인증되었는지 여부를 확인합니다. 인증이 실패하면 SCEF는이 응답을 보내야 한다.

- Forbidden: IN-CSE로부터 요청을 받으면 인증 후 SCEF는 IN-CSE가 서비스를 호출 할 권한이 있는지 여부를 확인합니다. 승인이 실패하면 SCEF는이 응답을 보내야 한다.

- Not Found: 자원 URI가 틀리면 SCEF는이 응답을 보내야 한다.

- Conflict: 자원의 현재 상태에서 작업을 수행 할 수 없습니다. 이 응답은 IN-CSE 식별자와 옵션인 tltrId를 가진 자원의 생성이 요청하고 동일한 식별자를 가진 자원이 이미 존재하는데 삭제되지 않은 경우에 사용한다. 또는 자원의 현재 상태와의 충돌로 인해 변경을 수행 할 수 없는 경우에 사용한다.

- Precondition Failed: IN-CSE가 필요한 기능을 광고 할 때 SCEF는 IN-CSE가 통지하는 필수 기능 중 적어도 하나를 지원하지 않습니다.

제 4 단계: Device Trigger Delivery procedure

장치 트리거 메시지는 ASN / MN-CSE 또는 ADN-AE를 호스팅하는 UE로 전달한다.

제 5 단계: response to DeviceTriggering

3 단계에 대한 응답을 위해 SCEF는 3GPP TS 29.122에 명시된 정보가 포함된 DeviceTriggering 메시지에 응답한다. 이 정보는 다음을 포함해야한다.

● scsAsId는 단계 3a의 scsAsId 값과 동일한 값으로 설정한다.

● triggerPayload (있는 경우)는 단계 3a의 triggerPayload 값과 동일하게 구성한다. 페이로드의 정보가 없는 경우에는 대상 ASN / MN-CSE 또는 ADN-AE가 IN-CSE와의 연결을 다시 설정해야 함을 나타낸다.

● id는 DeviceTriggering 메시지에 대해 SCEF가 선택한 식별자입니다.

● tltrId는 단계 3a의 tltrId 값과 동일하게 설정한다. 나중에 요청을 다시 호출해야하는 경우이 값은 호출해야하는 요청을 참조하는 데 사용한다.

한편, 전술한 3b 단계의 수행 및 생략에 따라 정보가 구분되어 구성될 수도 있다.

예를 들어, 전술한 제 3b 단계가 생략된 경우에 아래와 같이 정보가 구성될 수 있다.

● deliveryResult는 전달 상태 중 하나를 나타내는 HTTP 응답에 포함한다. 예를 들어, 전달 상태는 아래와 같은 상태 중에서 선택할 수 있다.

- CONFIRMED: 장치 트리거링 요청 메시지를 전달하기 위한 준비가 완료된 것을 확인되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_CONFIRMED로 갱신해야 한다.

- EXPIRED(유효 기간 만료): 장치 트리거링 요청 메시지의 처리 유효 기간이 만료되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_EXPIRED로 갱신해야 한다.

- UNCONFIRMED: 장치 동작 요청 메시지를 전달하기 위한 준비가 확인되지 않음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_UNCONFIRMED로 업데이트해야 한다.

- SUCCESS: 장치 트리거링 전달이 성공적으로 완료되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_DELIVERED로 갱신해야 한다.

- UNKNOWN: 지정되지 않은 오류를 나타낸다.

- FAILURE: 트리거링 메시지를 전달하거나 처리하는 도중 오류가 발생하여 영구적으로 배달 할 수 없는 것으로 간주한다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_FAILED로 업데이트해야 한다.

- TERMINATE: 장치 트리거링 요청의 전달이 IN-CSE에 의해 종료됨을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_TERMINATED로 갱신해야 한다.

다른 예를 들어, 전술한 제 3b 단계가 수행된 경우에 아래와 같이 정보가 구성될 수 있다.

● deliveryResult는 전달 상태 중 하나를 나타내는 HTTP 응답에 포함됩니다. 예를 들어, 전달 상태는 아래와 같은 상태 중에서 선택할 수 있다.

- SUCCESS: 장치 트리거링 전달이 성공적으로 완료되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_DELIVERED로 업데이트해야 한다.

- UNKNOWN: 지정되지 않은 오류를 나타낸다.

- EXPIRED (유효 기간 만료): 장치 트리거링 요청 메시지의 처리 유효 기간이 만료되었음을 나타낸다. 이 경우, IN-CSE는 <triggerRequest>의 triggerStatus 속성을 TRIGGER_EXPIRED로 갱신해야 한다.

한편, 제5단계의 정보는 아래의 정보를 포함할 수 있다.

● notificationDestination은 단계 3a의 요청 메시지의 notificationDestination 정보와 동일하게 설정될 수 있다.

● requestTestNotification은 단계 3a의 요청 메시지의 requestTestNotification 정보와 동일하게 설정될 수 있다.

제 6 단계: report on DeviceTriggeringDeliveryReportNotification

SCEF는 DeviceTriggeringDeliveryReportNotification 메시지를 보내 트리거 전달 결과를 IN-CSE로 보고합니다. 이 메시지는 3GPP TS 29.122에 정의되어 있으며 다음을 포함해야 한다.

● transactionId는 트랜잭션 자원을 트리거하는 장치의 식별자로 구성한다.

● transaction 은 이 통지와 관련된 트랜잭션 리소스를 트리거하는 관련 장치에 대한 링크로 구성한다.

● result 는 장치 트리거링의 전달 상태로 구성한다.

또한, 다음 정보가 포함될 수 있습니다.

● tltrId는 단계 3a의 tltrId 값과 동일하게 설정한다

제 7 단계(선택사항) 및 제 8 단계: IN-CSE Updates <triggerRequest> and Response to 1a or 1b

장치 트리거가 <triggerRequest> 리소스를 통해 AE에 의해 시작된 경우, IN-CSE는 <triggerRequest> 리소스를 트리거 상태 정보로 업데이트 할 수 있다.

제 9 단계: ASN/MN-CSE or ADN-AE performs triger actions

트리거에 페이로드가 없으면 ASN / MN-CSE 또는 ADN-AE는 IN-CSE와의 연결을 재설정한다. IN-CSE의 주소가 ASN / MN-CSE 또는 ADN에 알려지지 않은 경우, IN-CSE의 주소는 DeviceTriggering 메시지의 scsAsId 속성 값으로 사용한다.

ASN / MN-CSE 또는 ADN-AE는 수신 된 트리거 요청 유형에 기반하여 IN-CSE와의 연결성을 설정하고, MEF에 등록하고, IN-CSE에 등록하고, PoA를 업데이트하고, 또는 지정된 자원에 대해 생성, 조회, 삭제, 갱신 (CRUD:Create, Retrieve, Delete. Update) 요청을 실행할 수 있다.

한편, 전술한 실시예들에서 사용되는 정보는 아래의 표 2 내지 표 5 중 적어도 하나에 의해서 설명될 수 있다.

Definition of type DeviceTriggering

Attribute name	Data type	Cardinality	Description	Applicability (NOTE)
id	string	0..1	SCEF-chosen identifier of this device triggering transaction. Shall be absent in POST requests to create a resource, and shall be present otherwise.
scsAsId	ScsAsId	1	Identifies the SCS/AS
tltrId	TltrId	0..1	SCS/AS-chosen correlator. May be provided by the SCS/AS in the request to create a resource. Shall be provided in the body of all subsequent request and response if it was present in the body of the resource creation request.
self	Id	0..1	Link to this resource. This parameter shall be supplied by the SCEF in HTTP responses that include an object of DeviceTriggering type
triggerReferenceNumber	integer	1	The reference number is allocated by the initiator of a transaction and is used in all subsequent messages related to that transaction.
validityPeriod	DurationSec	1	The validity time in seconds for the specific action requested.
priority	Priority	0..1	Identifies the priority of the device trigger.
applicationPortId	Port	0..1	This is used to uniquely identify the triggering application addressed in the device.
triggerPayload	binary	1	The device triggering payload.
notificationDestination	Link	0..1	A URI indicating the notification destination for T8 notifications.
requestTestNotification	boolean	0..1	Set to true by the SCS/AS to request the SCEF to send a test notification as defined in subclause　5.2.5.3. Set to false or omitted otherwise.	Notification_test_event
websockNotifConfig	WebsockNotifConfig	0..1	Configuration parameters to set up notification delivery over Websocket protocol as defined in subclause　5.2.5.4.	Notification_websocket
deliveryResult	DeliveryResult	0..1	The delivery result shall be included in the HTTP responses that indicate the delivery status of the device triggering.
NOTE: Properties marked with a feature as defined in subclause　5.7.4 are applicable as described in subclause　5.2.7. If no feature are indicated, the related property applies for all the features.

Definition of type DeviceTriggeringDeliveryReportNotification

Attribute name	Data type	Cardinality	Description	Applicability (NOTE)
transactionId	string	1	Identifier of the related device triggering transaction resource, as defined by the "id" attribute of the "DeviceTriggering" data type.
transaction	Link	1	Link to the related device triggering transaction resource to which this notification is related.
tltrId	TltrId	0..1	SCS/AS-chosen correlator for the related device triggering transaction resource. Shall be present if it was provided when the related device triggering transaction resource was created.
result	DeliveryResult	1	OK, unknown or diverse failures
NOTE: Properties marked with a feature as defined in subclause　5.3.4 are applicable as described in subclause　5.2.7. If no feature are indicated, the related property applies for all the features.

한편, <triggerRequest> 리소스는 장치 트리거 요청을 시작하는 데 사용됩니다. 이 자원 유형은 IN-CSE에서만 인스턴스화되어야한다.

<triggerRequesst> 리소스의 성공적인 생성은 IN-CSE가 타겟 디바이스 (예를 들어, 3GPP UE)에 트리거 요청을 개시하게 한다. 보류중인 트리거 요청은 <triggerRequestst> 리소스를 업데이트하여 새 트리거 요청으로 바꿀 수 있습니다. 보류중인 트리거 요청은 <triggerRequesst> 리소스를 삭제하여 취소 할 수 있습니다.

<triggerRequest> 자원은 표 4에 명시된 하위 자원을 포함해야한다.

Child resources of <triggerReqeust> resource

Child Resources of *<trafficPattern>*	Child Resource Type	Multiplicity	Description
[variable]	<subscription>	0..n	See clause 9.6.8 of TS-0001

<triggerRequest> 자원은 표 5에 명시된 속성을 포함해야한다.

Attributes of *<triggerRequest>*	Multiplicity	RW/ RO/ WO	Description
resourceType	1	RO	See clause 9.6.1.3.
resourceID	1	RO	See clause 9.6.1.3.
resourceName	1	WO	See clause 9.6.1.3.
parentID	1	RO	See clause 9.6.1.3.
creationTime	1	RO	See clause 9.6.1.3.
lastModifiedTime	1	RO	See clause 9.6.1.3.
expirationTime	1	RW	See clause 9.6.1.3.
accessControlPolicyIDs	0..1 (L)	RW	See clause 9.6.1.3.
Labels	0..1 (L)	RW	See clause 9.6.1.3.
dynamicAuthorizationConsultationIDs	0..1 (L)	RW	See clause 9.6.1.3.
M2M-Ext-ID	1	WO	M2M External Identifier of the device being triggered. See clause 7.1.8. This attribute shall be configured by the Originator when the resource is created.
Trigger-Recipient-ID	1	RW	Trigger-Recipient-ID of the ASN/MN-CSE or ADN-AE that is hosted on the device being triggered. See　clause 7.1.10. This attribute shall be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2.
triggerPurpose	1	RW	The purpose of the trigger. See　clause 8.3.3.2.1. This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. The allowed values are: ·establishConnection ·enrolmentRequest ·registrationRequest ·executeCRUD If not specified by the Originator, the default is "establishConnection".
triggerPayloadSerialization	1	RW	The type of serialization used to encode the trigger payload (i.e. XML, JSON or CBOR). This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2. If not specificied by the Originator, the default is "JSON".
triggerStatus	1	RO	The status of the trigger request. The Hosting CSE shall control the value of this attribute. The following values are valid values. ·PROCESSING ·ERROR-NSE-NOT-FOUND ·TRIGGER-CONFIRMED .TRIGGER-UNCONFIRMED ·TRIGGER-DELIVERED ·TRIGGER-FAILED .TRIGGER-TERMINATED .TRIGGER-EXPIRED
triggerValidityTime	0..1	RW	The time duration for which the trigger request is valid. After this time expires, the trigger shall be recalled (i.e. cancelled) by the Hosting CSE. This attribute may be configured by the Originator when the resource is created and may also be updated when performing a trigger replace procedure. See clause 8.3.3.2.2.
triggerInfoAE-ID	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the AE-ID of the ASN/MN-AE that should perform the CRUD operation. When this attribute is configured, the trigger originator shall also configure the triggerInfoAddress, triggerInfoOperation and targetedResouceType attributes.
triggerInfoAddress	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with an unstructured CSE-Relative-Resource-ID of the resource that the ASN/MN-AE should perform the CRUD operation on. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoOperation and targetedResouceType attributes.
triggerInfoOperation	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the CRUD operation that the ASN/MN-AE should perform on the targeted resource specified by triggerInfoAddress. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoAddress and targetedResouceType attributes.
targetedResourceType	0..1	RW	When the triggerPurpose is "executeCRUD", this attribute is mandatory otherwise it is not applicable. This attribute is configured with the resource type of the targeted resource specified by triggerInfoAddress. When this attribute is configured, the trigger originator shall also configure the triggerInfoAE-ID, triggerInfoAddress and triggerInfoOperation attributes.
triggerReference	0..1	WO	This attribute is reference number which is allocated by the Originator of a transaction and is used in all subsequent messages related to that transaction to support 3GPP TS 29.122.
triggerPriority	0..1	RW	This attribute is priority for Device Trigger either PRIORITY or NO_PRIORITY to support 3GPP TS 29.122.
triggerPortID	0..1	RW	This attribute is application port ID for device triggerto uniquely identify the triggering application addressed in the device to support 3GPP 29.122.
triggeRequestTestNotification	0..1	RW	This attribute is TRUE or FALSE, When the value is TRUE, it shall be used to test event. The FALSE shall not provide test event to support 3GPP TS 29.122.
websockNotifConfig	0..1	RW	This attribute is for upgrade to Websocket. It consists of destination information (websocketUri) and source information (requestWebsocketUri) to support 3GPP TS 29.122.

이하에서는 도 1 내지 도 9를 참조하여 설명한 본 실시예들의 동작을 모두 또는 일부 수행할 수 있는 M2M 장치에 대한 구성을 설명한다. 도 10에서의 구성은 기능적 측면으로 구분되는 것으로, M2M 장치의 프로세서 또는 저장장치와 연동되어 동작할 수도 있다.

도 10은 일 실시예에 따른 M2M 장치의 구성을 도시한 도면이다.

도 10을 참조하면, 제어부(710)는 전술한 인터넷 접속이 단절된 수면 모드 또는 휴지 상태 등의 절전 상태에서 사물통신 기능을 수행하기 위한 M2M 장치(700)의 전반적인 동작을 제어할 수 있다.

한편, 송신부(720) 및 수신부(730)는 다른 M2M 장치 또는 M2M 시스템 구성 장치 또는 3GPP 단말 또는 기지국과 같은 3GPP 기반 이동통신 시스템의 각 구성장치와 데이터를 송수신하는 데에 사용된다.

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

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

Claims

M2M(Machine to Machine communication) 장치가 사물통신을 수행하는 방법에 있어서,
셀룰러 이동통신 기반의 단말장치가 수면 모드 또는 휴지 상태에서 사물통신 기능을 수행하는 단계를 포함하는 방법.