KR20130053202A - Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치 - Google Patents

Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치 Download PDF

Info

Publication number
KR20130053202A
KR20130053202A KR1020110118842A KR20110118842A KR20130053202A KR 20130053202 A KR20130053202 A KR 20130053202A KR 1020110118842 A KR1020110118842 A KR 1020110118842A KR 20110118842 A KR20110118842 A KR 20110118842A KR 20130053202 A KR20130053202 A KR 20130053202A
Authority
KR
South Korea
Prior art keywords
message
gateway
platform
function
result
Prior art date
Application number
KR1020110118842A
Other languages
English (en)
Other versions
KR101807317B1 (ko
Inventor
윤성숙
조수현
장덕문
김유선
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020110118842A priority Critical patent/KR101807317B1/ko
Publication of KR20130053202A publication Critical patent/KR20130053202A/ko
Application granted granted Critical
Publication of KR101807317B1 publication Critical patent/KR101807317B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/06—Testing, supervising or monitoring using simulated traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/02—Arrangements for increasing efficiency of notification or paging channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 명세서는 M2M 통신 개체간 통지 기능을 구현하는 방법 및 장치에 관한 것이다.
본 명세서의 일 실시예에 의한 M2M 통신 개체간 통지 기능을 구현하는 방법은 M2M 플랫폼(M2M Platform)이 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하는 단계, 및 상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 단계를 포함한다.

Description

Ｍ２Ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치{A Method and Apparatus of implementing notification capability between M2M communication entities}
사물 통신 또는 사물간 통신은 장치(Machine) 간에 이루어지는 통신을 의미한다. 이러한 사물 간의 통신은 다양한 정보를 특정한 패턴에 따라 다양하게 송수신하는 특징을 가진다는 점에서 통상적인 휴대폰 등의 통신과 상이하게 구현된다. 본 명세서에서는 이러한 사물 통신을 구현함에 있어 통지 기능을 구현하여, M2M 통신 개체간에 연결 또는 장애를 관리하는 방법 및 장치를 제공하고자 한다.
사물 통신은 M2M(Machine to Machine communication), MTC(Machine type communication), IoT(Internet of Thing), 스마트 디바이스 통신(Smart Device communication), 또는 사물 지향 통신(Machine oriented communication) 등으로 다양하게 불려지고 있다. 사물 통신은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다. 한편 사물 통신은 적용되는 마켓, 어플리케이션, 또는 이용하고자 하는 서비스에 따라 통신하는 패턴이 다양하다. 특히, 사물 통신은 항상 통신이 연결될 것을 요구하는 것은 아니며, 송수신되는 정보 역시 일정한 패턴을 가지고 송수신될 수도 있고, 패턴 없이 데이터를 송수신할 수도 있다. 이러한 사물 통신을 제공하는 네트워크에서 중요한 것은 각각의 장치들이 어떠한 상태에 있는지를 확인하는 것이다. 그러나, 이러한 확인을 하기 위해서는 M2M 개체들 간에 진단을 통지하거나, 이를 확인하는 기능이 필요하지만, 현재 사물 통신에서 제시되지 않고 있다.
본 발명은 종래 기술의 문제점을 해결하기 위하여 효과적이고 신뢰성 있는 M2M 게이트웨이 및 디바이스를 관리할 수 있도록, M2M 게이트웨이 및 M2M 디바이스에서 관련된 어플리케이션에서 통지 기능을 제공하며, 이러한 통지 기능에 기반하여 장애를 관리할 수 있도록 한다.
전술한 과제를 실시하기 위하여 본 명세서의 일 실시예에 의한 M2M 통신 개체간 통지 기능을 구현하는 방법은 M2M 플랫폼(M2M Platform)이 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하는 단계, 및 상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 단계를 포함한다.
본 명세서의 다른 실시예에 의한 M2M 통신 개체간 통지 기능을 구현하는 방법은 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)가 M2M 플랫폼(M2M Platform)으로부터 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 수신하는 단계, 상기 요청 메시지에 따라, 하위 모듈에 대한 진단을 수행하거나, 또는 하위 모듈의 기능 확인을 수행하는 단계, 및 상기 M2M 플랫폼에 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 상기 M2M 플랫폼에 송신하는 단계를 포함한다.
본 명세서의 또다른 실시예에 의한 M2M 통신 개체간 통지 기능을 구현하는 M2M 플랫폼은 M2M 서비스 운용자로부터 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)의 통지 기능 진단 명령을 수신하고, 상기 수신한 명령에 대한 M2M 게이트웨이 또는 M2M 장치의 진단 결과를 상기 M2M 서비스 운용자에게 통지하는 운용 환경 연동 모듈, 및 상기 통지 기능 진단 명령에 따라 M2M 게이트웨이 또는 M2M 장치에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하고, 상기 M2M 게이트웨이 또는 상기 M2M 장치에서 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 게이트웨이/장치 연동 모듈을 포함한다.
본 명세서의 또다른 실시예에 의한 M2M 통신 개체간 통지 기능을 구현하는 장치는 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)가 M2M 플랫폼(M2M Platform)으로부터 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 플랫폼 연동 모듈, 상기 요청 메시지에 따라, 하위 모듈에 대한 진단을 수행하는 진단 모듈, 및 하위 모듈의 기능 확인을 수행하거나 상기 진단 결과 또는 상기 기능 확인 결과를 상기 M2M 플랫폼에 송신하는 통지 모듈을 포함하며, 상기 플랫폼 연동 모듈 또는 상기 통지 모듈은 상기 M2M 플랫폼에 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 상기 M2M 플랫폼에 송신하는 것을 특징으로 한다.
M2M 통신 개체들 간, 예를 들어, M2M 게이트웨이 및 장치와 M2M 플랫폼 간에 통지 기능을 이용하여, M2M 게이트웨이 및 장치에서 플랫폼으로 송신하게 되는 통지 기능의 이상 유무를 확인하여, 보다 신뢰성 있는 통신 기능을 제공하고자 한다.
도 1은 본 명세서의 일 실시예에 의한 M2M 시스템의 구조를 보여주는 도면이다.
도 2는 본 명세서의 일 실시예에 의한 M2M 플랫폼(202)과 M2M 게이트웨이 또는 M2M 장치(203) 간에 통지기능을 수행하는 과정을 보여주는 도면이다.
도 3 은 본 명세서의 일 실시예에 의한 트랩(trap)을 위한 통지 기능 속에 진단 기능을 포함시키는 리소스의 구성을 보여주는 도면이다.
도 4 는 본 명세서의 다른 실시예에 의한 새로운 리소스를 통하여 통지 기능 진단 이벤트를 수행하는 예를 보여주는 도면이다.
도 5는 본 명세서의 일 실시예에 의한, 통지 기능 진단 과정을 보여주는 도면이다.
도 6 은 본 명세서의 일 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 수신 응답 및 진단 결과 통지가 별도의 과정으로 처리되는 예를 보여주는 도면이다.
도 7 은 본 명세서의 다른 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 수신 응답에 진단 결과 통지가 포함되며, 기능 확인 이벤트 통지가 별도의 과정으로 처리되는 예를 보여주는 도면이다.
도 8 은 본 명세서의 또다른 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 별도의 하위 모듈에 대한 진단이 없는 경우의 예를 보여주는 도면이다.
도 9는 본 명세서의 일 실시예에 의한, 도 6의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 수신 응답 및 진단 결과 통지가 별도의 과정으로 처리되는 도면이다.
도 10은 본 명세서의 다른 실시예에 의한, 도 7의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 수신 응답에 진단 결과 통지가 포함되며, 기능 확인 이벤트 통지가 별도의 과정으로 도면이다.
도 11은 본 명세서의 또다른 실시예에 의한, 도 8의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 별도의 하위 모듈에 대한 진단이 없는 경우를 보여주는 도면이다.
도 12는 본 명세서의 일 실시예에서 M2M 플랫폼이 M2M 통신 개체간 통지 기능을 구현하는 과정을 보여주는 도면이다.
도 13은 본 명세서의 일 실시예에서 M2M 게이트웨이 또는 M2M 장치가 M2M 통신 개체간 통지 기능을 구현하는 과정을 보여주는 도면이다.
도 14는 본 명세서의 일 실시예에 의한 M2M 게이트웨이와 M2M 장치, 그리고 M2M 플랫폼의 구성을 보여주는 도면이다.
이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.
또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.
본 명세서에서는 사물 통신을 중심으로 설명한다. 사물 통신은 앞서 살펴본 바와 같이 M2M, MTC, IOT, 스마트 디바이스 통신, 사물 지향 통신 등 다양한 분야로 나누어지며, 본 명세서에서는 M2M을 중심으로 설명한다. 그러나 이러한 설명이 M2M에 한정되는 것은 아니며, 기기간 통신, 즉 사물 통신을 제공하는 모든 시스템 및 구조와 이들 시스템에서 발생하는 통신에 적용 가능하다.
도 1은 본 명세서의 일 실시예에 의한 M2M 시스템의 구조를 보여주는 도면이다.
전체 구성은 네트워크/어플리케이션 도메인(Network and Application domain)(110)과 M2M 디바이스 도메인(M2M Device domain)(120)으로 구성되며, 네트워크/어플리케이션 도메인(110)은 M2M 서비스 능력인 M2M SC(M2M Service Capabilities)에서 접근하거나 서비스 로직을 제공하는 M2M 어플리케이션(M2M Application)(111), 코어 네트워크(Core Network)(114), M2M SC로(112), 그리고 M2M 디바이스 도메인(120)과 통신을 가능하게 하는 액세스 네트워크(Access Network)(115), 그리고 M2M 관리 기능(M2M Management Functions)(118) 및 네트워크 관리 기능(Network Management Functions)(119)로 구성되어 있다.
한편, M2M 디바이스 도메인(120)은 M2M 게이트웨이(M2M Gateway)(121), M2M 장치(M2M Device)(122, 125), M2M 에어리어 네트워크(M2M Area Network)(123)으로 구성된다. M2M 장치(122, 125)는 M2M SC와 네트워크 도메인의 기능을 이용하는 M2M 어플리케이션이 구동되는 장치이다. M2M 장치는 M2M 어플리케이션과 M2M SC가 있는 경우(122)와 그렇지 않은 경우(125)로 구분될 수 있다.
M2M 게이트웨이(121)는 M2M SC를 포함하며, M2M 장치들이 네트워크/어플리케이션 도메인(110)에서 동작(interworking and interconnection)할 수 있도록 한다.
SC(Service Capabilities)는 상이한 어플리케이션들에 의하여 공유되는 기능을 제공하는 것을 의미하며, M2M 개체들은 특정한 SC를 포함할 수 있다.
도 1의 구성에서, M2M 게이트웨이(121) 및 M2M 장치(M2M 디바이스) (122, 125)는 M2M SC(112)와 코어 네트워크(114)를 포함하는 M2M 플랫폼과 통신하며 M2M 플랫폼에서는 하위 계층에 있는 게이트웨이 및 장치를 관리한다. 이때 M2M 플랫폼에서 게이트웨이 및 장치를 관리하는 기능으로는 구성 관리(Configuration management), 장애 관리(fault management), 성능 관리(Performance management) 등이 있다. 이 중 장애 관리 기능 중 하나로, M2M 게이트웨이(121) 및 M2M 장치(122, 125)는 플랫폼으로 장애 정보 및 배터리 레벨이나 CPU 사용량 등의 상태 정보 변경 이벤트를 송신하는 기능이 필요하고, 플랫폼도 이러한 이벤트를 수신 하는 기능이 필요하다.
그런데 M2M 게이트웨이(121) 및 M2M 장치(122, 125)와 플랫폼간에 이러한 이벤트를 송수신 하려면, 해당 게이트웨이 및 장치로부터 플랫폼으로의 통지(notification) 기능이 정상적으로 동작하는 것이 전제되어야 한다. 게이트웨이 및 장치와 플랫폼간의 연결이 제대로 되지 않았을 경우 게이트웨이 및 장치에서 보내는 이벤트가 플랫폼으로 전달되지 않는 현상이 발생하고, 이럴 경우 해당 게이트웨이 및 장치에서 문제가 발생해도 상위 플랫폼이나 어플리케이션에서는 이를 제대로 관리하지 못하고 따라서 장애 관리도 제대로 이루어지지 못하게 된다.
또한, M2M 환경에서는 다양한 어플리케이션이 하나의 게이트웨이 및 장치를 사용할 수 있는데, 이때 각각의 어플리케이션에서 연결 상태 확인 시 다른 주기를 가질 경우, 연결 상태 확인 이벤트가 수시로 발생할 수 있다.
이에 따라, 주기적인 연결 상태 확인 이벤트를 이용하여 M2M 게이트웨이 및 장치와 플랫폼간의 연결 상태를 확인하는 방법이 있을 수 있으나, 이 방법은 지정된 주기가 너무 짧거나 해당 게이트웨이 및 장치가 너무 많을 경우, 많은 트래픽을 유발할 수 있다. 이러한 부분을 해결하기 위하여, 즉, 효과적이고 신뢰성 있는 M2M 게이트웨이 및 M2M 장치를 관리하기 위하여, M2M 플랫폼에서 온디맨드(on-demand) 방식으로 게이트웨이 및 장치의 통신 모듈 상태를 진단하기 위한 통지 명령을 내리고, 이 명령을 받는 게이트웨이 및 장치에서는 필요에 따라 해당 명령에 대한 응답을 플랫폼으로 보내는 프로세스를 구현하고자 한다. 이때, M2M 플랫폼에서는, 배터리 잔량 등, 게이트웨이 및 장치의 다른 부분에 대한 상태 정보를 요청할 수도 있다. 또한 이 명령을 받는 게이트웨이 및 장치에서는 해당 상태 정보에 대한 응답을 통신 모듈 상태 진단을 위한 통지를 통해 보낼 수도 있고, 플랫폼으로 보내는 응답을 통해 보낼 수도 있다. 게이트웨이 및 장치에서는 이러한 명령을 받은 후, 상태 진단 결과를 통지하는 방식을 구현한다.
이하, M2M 플랫폼에서 M2M 게이트웨이 또는 M2M 장치에게 통지 기능을 진단하기 위한 명령을 송신하고, 이 명령에 대한 응답과 진단 결과를 포함하는 정보를 M2M 게이트웨이 또는 M2M 장치로부터 수신하는 과정 또는 이를 위한 상세한 구성에 대해 살펴보고자 한다.
이는, M2M 게이트웨이 및 장치에서 플랫폼으로의 통지 기능에 대한 상태를 확인하기 위한 방법에 관한 것으로서, 보다 상세하게는 플랫폼에서 특정 게이트웨이 및 장치로 통지 기능 확인 명령을 송신하고, 해당 게이트웨이 및 장치에서는 이에 대한 응답으로, 통지 기능을 수행하는 모듈에서 미리 약속된 포맷에 따른 통지 기능 확인 이벤트를 플랫폼으로 송신하고, 플랫폼에서는 통지 기능 확인 이벤트 수신 여부를 모니터링하여 게이트웨이 및 장치 정보를 관련 어플리케이션 및 관련 시스템으로 통보함으로써 게이트웨이 및 장치의 통지 기능 정상 동작 여부를 확인하는 방법 및 이를 구현한 장치들에 대해 살펴보고자 한다.
이를 위해, 본 명세서의 일 실시예에서는 M2M 플랫폼을 구성하는 하위 모듈로, 플랫폼 운용자로부터 게이트웨이 및 장치에 대한 통지 기능을 진단하기 위한 명령을 받고, 이에 대한 응답을 운용자에게 보여주는 운용 환경 연동 모듈과, 해당 게이트웨이 및 장치로 통지 기능 진단 명령을 전송하고 이 명령에 대한 응답 및 통지 기능 진단을 위한 통지를 받는 게이트웨이/장치 연동 모듈로 구성된다.
도 2는 본 명세서의 일 실시예에 의한 M2M 플랫폼(202)과 M2M 게이트웨이 또는 M2M 장치(203) 간에 통지기능을 수행하는 과정을 보여주는 도면이다. 이하 M2M 게이트웨이/장치로 표시되는 것은 M2M 게이트웨이 또는 M2M 장치 중 어느 하나에 해당되는 것을 의미한다. 물론, M2M 게이트웨이 및 M2M 장치의 기능을 모두 제공하는 것도 이에 해당한다.
먼저, M2M 플랫폼(202)은 통지기능 진단 요청 메시지를 M2M 게이트웨이 또는 M2M 장치(203)에게 송신한다(S210). 통지기능 진단 요청 메시지(명령)에는 진단이 필요한 구성 요소를 지시하는 정보가 포함될 수 있으며, 이는 표 1과 같다. 즉, M2M 플랫폼에서는 게이트웨이 또는 장치의 상태를 진단하기 위하여 표 1 과 같은 내용에 대해서 진단 결과를 요청할 수 있다. 또는 상태 진단 없이 통지 기능 진단 이벤트 명령을 내릴 수도 있다.
속성값(attribute) 설명/값
firmware Firmware 상태 정보
battery 배터리 상태/현재 충전율
cpu 현재 cpu 부하율
Memory 현재 memory 부하율
process 현재 구동 중인 process list
센싱 모듈 장치(Device)로 보내는 경우에 해당.
해당 모듈의 정상 동작 여부, 모듈별로 별도 값으로 전송
하위 장치 정보 게이트웨이로 보내는 경우에 해당. 해당 게이트웨이의 하위에 있는 장치 ID list
통신 상태 플랫폼과의 통신을 포함한 통신 상태 정보. 게이트웨이의 경우 하위 장치와의 통신 상태 정보가 포함 될 수 있고, 장치의 경우 플랫폼과 무관한 서비스 통신 상태 정보가 포함 될 수 있음.
외부 인터페이스 모듈 USB 등 기타 외부 인터페이스 모듈의 상태 정보
표 1에서는 장치 또는 게이트웨이의 물리적 특성 또는 현재 소정의 기능을 처리함에 있어서의 상태 정보에 대한 정보를 제시하고 있으며, 이외에도, 장치 또는 게이트웨이의 특성에 따라 다양한 속성값(attribute)을 포함시킬 수 있다.
한편 표 1의 속성값은 비트맵 방식으로 구현할 수 있다. 예를 들어, 각 비트의 1은 진단을 요청하는 것을 의미하며, 0은 진단을 요청하지 않는 것으로 설정하고, 표 1의 속성값인 firmware, battery 등을 모두 9bit의 진단 요청 리소스를 지시하는 정보로 할 수 있다.
이 경우, "101000000"으로 진단 요청 리소스가 설정된 경우, 첫번째 비트와 세번째 비트가 1이며, 이는 각각 firmware, cpu에 대한 진단을 지시하게 된다.
한편, 표 1과 같이 구성요소에 대한 진단을 요청하는, S210의 통지기능 진단을 요청하는 메시지의 구성을 살펴보면, 표 2와 같이 구성된다.
상태 진단 요청 메시지의 구성예
attribute 설명
플랫폼 ID 통지 기능 진단 플랫폼 ID, 요청을 받는 게이트웨이/장치와 asynchronous하게 동작할 경우 필요
Target ID 진단 받을 게이트웨이/장치 ID
Diagnostic resource 상태 진단할 자원 리스트, 표 1을 참조
[도 8]의 경우는 필요없음
Flag 진단 결과를 받을 방식. 도 6 내지 도 8의 방식을 참조.
M2M 게이트웨이 또는 M2M 장치(203)는 S210에서 요청된 진단을 수행한다(S220). 그리고, S210의 메시지(명령)에서 요청하는 상태 진단에 대한 내용을 명령에 대한 응답으로 송신한다(S230). 이때, 게이트웨이나 장치의 종류에 따라, 플랫폼에서 내려온 명령에서 상태 진단할 내용이 없거나 상태 진단 내용을 진단 이벤트로 보내기로 한 경우에는 플랫폼과의 약속에 따라 응답 명령을 보내지 않을 수도 있다. 또는 특정 기능에 대한 확인 이벤트를 통지할 수도 있다. 응답을 보낼 경우, 게이트웨이나 장치는 해당 자원의 상태를 파악하여 표 3과 같이 응답 명령에 해당 내용을 보낸다.
한편 flag 부분은 향후 설명할 진단 결과를 받는 방식으로 도 6, 7, 8 등의 진단 결과를 받는 방식으로 설정할 수 있다. 본 명세서의 일 실시예에 의하여, 도 6의 방식으로 진단 결과를 받고자 할 경우, flag의 값을 0으로 설정하고, 도 7의 방식으로 진단 결과를 받고자 할 경우, flag의 값을 1로 설정하고, 도 8의 방식으로 진단 결과를 받고자 할 경우, flag의 값을 2로 설정하는 것으로 예를 들어 설명하고자 한다.
상태 진단 응답 메시지의 구성예
attribute 설명
Source ID 진단 결과를 보낼 게이트웨이/장치 ID
플랫폼 ID 통지 기능 진단 플랫폼 ID, 게이트웨이/장치와 asynchronous하게 동작할 경우 필요
Diagnostic result 자원별 진단 결과. 도 7의 경우 적용 가능함.
한편 M2M 게이트웨이 또는 M2M 장치(203)는 S230 단계에서 응답 메시지를 보내는 것과 별도로, S210의 메시지 수신이 성공했음을 M2M 플랫폼에게 알릴 수 있다.
도 2에서 살펴본, 통지 기능 진단 이벤트를 수행하기 위해서는 M2M 게이트웨이 또는 M2M 장치가 M2M 플랫폼에게 제공하는 리소스(resource)를 구성하는 실시예로, 트랩(trap)을 위한 통지 기능 속에 진단 기능을 포함시키거나, 혹은 별도로 리소스를 제공할 수 있다.
도 3은 본 명세서의 일 실시예에 의한 트랩(trap)을 위한 통지 기능 속에 진단 기능을 포함시키는 리소스의 구성을 보여주는 도면이다.
도 3은 트랩을 위한 리소스(resource)인 <trapInstance> (310)에 "diagnosticData"(320)라는 속성(attribute)이 추가된 것을 보여주고 있다. 통지 기능을 제공하기 위한 <trapInstance>의 "attribute"(315)의 구성을 살펴보면 표 4와 같다.
<trapInstance>의 "attribute"의 구성
AttributeName Mandatory/ Optional Type Description
accessRightID M RW access rights 리소스(resource)에 대한 URI (Uniform Resource Identifier) 정보
CreationTime M RO 리소스가 생성된 시각에 대한 정보
LastModifiedTime M RO 리소스가 마지막으로 변경된시각에 대한 정보
OriginalMO M WO 호스팅 SCL(hosting SCL)에서 <mgmtObj>에 의해 제시되는 리모트 엔티티에 대한 오리지널 MO 인스턴스의 로컬 패스(local path)를 포함함. (Contains the local path of the original MO instance on the remote entity which is represented by the <mgmtObj> resource in the hosting SCL.)
trapId M RW 트랩 이벤트(Trap even)의 의미를 명시하는 식별자 정보. 이 속성의 값은 하위의 관리 시스템에 종속적임(The identifier that specifies the meaning of the trap event. The content of this attribute is dependent on the underlying management system.)
eventOccured M RO 이벤트가 일어남을 지시하는 정보.
이 속성은 이벤트가 디바이스에서 생성되었음을 지시함. NREM은 이 속성값을 이용하여, 이벤트를 생성한 장치의 하위 관리 시스템에 의해 정보를 수신함. 이 속성의 내용은 하위 관리 시스템에 종속적임(Indicated the occurrence of the event. This attribute indicates that the event was raised in the device. The NREM has been informed by the underlying management system that the event was raised in the device and informs the Network Application by using this attribute. The content of this attribute is dependent on the underlying management system.)
trapActionStatus M RO 액션의 상태를 지시함(Indicates the status of the Action (including a progress indicator, a final state and a reminder of the requested action).)
diagnosticData O RW NREM에 의해 요청된 진단 결과를 지시함(Indicates diagnostic result that requested by NREM.)
도 3의 <trapInstance>에는 "diagnosticData"(320)가 추가된 것으로, 이 는 상위에서 게이트웨이나 장치에 기능 진단을 위한 통지를 받을 때 해당 진단 결과를 보내기 위한 속성(attribute)이다.
도 4는 본 명세서의 다른 실시예에 의한 새로운 리소스를 통하여 통지 기능 진단 이벤트를 수행하는 예를 보여주는 도면이다.
도 4에서는 새로운 리소스인 etsiNotificationEvent(410) 및 notificationInstance(420)를 정의한 것으로 게이트웨이 및 장치에서 통지 기능 진단에 따른 결과를 상위로 통지할 수 있는 구조를 제시한다.
먼저, etsiNotificationEvent(410)의 서브리소스(subresource)와 속성(attribute)는 표 5 및 표 6과 같다.
etsiNoticationEvent의 서브 리소스의 구조
SubResource Mandatory/ Optional Multiplicity Description
<notificationInstance> O 0..1 장치에 의해 지원되는 하나의 notificationEvent에 대한 서브리소스(The sub-resource that contains information about one notificationEvent supported by a device.)
subscriptions M 1 Subscribe-able한 parent의 차일드 리소스로 사용됨. Subscribe-able한 리소스에 대한 서브스크립션의 트랙을 유지함(For keeping track of subscriptions to a subscribe-able resource, the subscriptions-resource is used as a child resource of the subscribe-able parent.)
표 5에서는 etsiNotificationEvent의 subresource를 나타낸 것으로 하나의 notificationEvent에 대한 정보를 가지는 <notificationInstace>를 정의하고 있다. Subscriptions는 모든 리소스에 공통된 서브리소스이다.
etsiNoticationEvent의 속성(attribute)의 정보
AttributeName Mandatory/ Optional Type Description
expirationTime M RW 호스팅 SCL(hosting SCL)에 의해 해당 리소스가 삭제되는 절대적인 시각(Absolute time)
accessRightID M RW access rights 리소스(resource)에 대한 URI (Uniform Resource Identifier) 정보
searchStrings M RW 리소스를 발견(discovering) 하기 위한 키(Key)로 사용되는 토큰(Tokens)
creationTime M RO 리소스가 생성된 시각에 대한 정보
lastModifiedTime M RO 리소스가 마지막으로 변경된시각에 대한 정보
moID M WO <mgmtObj>에 대한 MO 데이터 모델을 유일하게 식별하는 URN 정보를 포함(Contains a URN that uniquely identifies the MO data model used for this <mgmtObj> resource as well as the manage function and version it represents.)
originalMO M WO 호스팅 SCL(hosting SCL)에서 <mgmtObj>에 의해 제시되는 리모트 엔티티에 대한 오리지널 MO 인스턴스의 로컬 패스(local path)를 포함함. (Contains the local path of the original MO instance on the remote entity which is represented by the <mgmtObj> resource in the hosting SCL.)
description O RW 해당 mgmtObj에 대한 텍스트 형식(text-format)의 기술(description)
표 6은 etsiNotificationEvent에 대한 attribute(도 4의 415)에 대하여 정의하였다. 모두 관리 객체(Management Object)에 대한 공통된 속성이다.
한편, 표 5에 제시된 바와 같이 <notificationInstance>는 도 4의 420과 같이 구성되며, <notificationInstance>의 상세한 서브리소스는 표 7에, <notificationInstance>의 속성은 표 8에 제시되어 있다.
<notificationInstance>의 서브리소스
SubResource Mandatory/ Optional Multiplicity Description
subscriptions M 1 Subscribe-able한 parent의 차일드 리소스로 사용됨. Subscribe-able한 리소스에 대한 서브스크립션의 트랙을 유지함(For keeping track of subscriptions to a subscribe-able resource, the subscriptions-resource is used as a child resource of the subscribe-able parent.)
표 7에서는 <notificationInstance>에 대한 서브리소스를 제시하고 있는데, 이는 모든 resource에 공통된 subscriptions에 대해서만 정의하였다.
<notificationInstance>의 속성 정보
AttributeName Mandatory/ Optional Type Description
accessRightID M RW access rights 리소스(resource)에 대한 URI (Uniform Resource Identifier) 정보
CreationTime M RO 리소스가 생성된 시각에 대한 정보
LastModifiedTime M RO 리소스가 마지막으로 변경된시각에 대한 정보
OriginalMO M WO 호스팅 SCL(hosting SCL)에서 <mgmtObj>에 의해 제시되는 리모트 엔티티에 대한 오리지널 MO 인스턴스의 로컬 패스(local path)를 포함함. (Contains the local path of the original MO instance on the remote entity which is represented by the <mgmtObj> resource in the hosting SCL.)
eventId M RW 트랩 이벤트의 의미를 명시하는 식별자임. 이 속성의 내용은 하위의 관리 시스템에 종속적임(The identifier that specifies the meaning of the trap event. The content of this attribute is dependent on the underlying management system.)
notificationActionStatus M RO 액션의 상태를 지시함(Indicates the status of the Action (including a progress indicator, a final state and a reminder of the requested action).)
diagnosticData O RW NREM에 의해 요청된 진단 결과를 지시함(Indicates diagnostic result that requested by NREM.)
표 8은 <notificationInstance>에 대한 속성(attribute)에 대해서 정의하였다. accessRightID, CreationTime,LastModifiedTime,OriginalMO는 공통된 속성이며, eventId, notificationActionStatus는 표 4의 <trapInstance>의 trapId, trapActionStatus와 같은 의미를 가진다. 본 명세서를 구현하기 위한 진단 결과는 430과 같이 diagnosticData로 해당 attribute에 진단 결과 내용을 담아서 상위로 통보할 수 있도록 한다.
통지 기능 진단 이벤트 기능을 수행하기 위해서는 도 3과 같이 트랩 이벤트를 수행하는 리소스 구조에 진단 결과를 포함하는 diagnostic Data(320)를 추가시키거나, 혹은 도 4와 같이 새로운 리소스를 정의하여 이러한 리소스 내에 진단 결과를 포함하는 diagnostic Data(430)를 추가시킬 수 있다. 도 3의 방식을 이용할 경우, 기존에 트랩(trap)을 통한 통지 기능에 진단 기능을 함께 제공하여, 진단 기능을 플랫폼으로 통보할 수 있는 장점이 있다.
상기의 리소스 또는 속성은 통지 기능 진단을 위한 일 실시예이며, 이외에도 다양한 리소스 또는 속성을 포함시킬 수 있다.
도 5는 본 명세서의 일 실시예에 의한, 통지 기능 진단 과정을 보여주는 도면이다.
M2M 서비스를 관리하는 운용자(501)는 플랫폼(502)에게 통지 기능 진단 명령을 전송한다(S510). 플랫폼(502)는 게이트웨이(503)/장치(504)에게 통지 기능 진단 명령을 전송하고, 이에 대한 응답을 수신한다(S520). 한편, 장치(504)는 통지 기능 진단 이벤트를 전송하게 된다(S530).
이후, 플랫폼(502)은 이벤트를 확인하고, 상태 정보를 점검하여(S540), 이에 대한 결과, 즉 해당 게이트웨이/장치의 진단 결과를 운용자(501)에게 통지한다(S550).
보다 상세히 살펴보면, M2M 플랫폼을 구성하며 본 명세서의 실시예들을 구현하기 위한 모듈로는 i) 운용 환경 연동 모듈과 ii) 게이트웨이/장치 연동 모듈이 있다. 물론, 이들 모듈은 해당 기능을 수행하는 것으로 다른 모듈 혹은 다른 구성 요소와 결합하거나, 다른 구성 요소에 포함될 수도 있다. 먼저, 운용 환경 연동 모듈은, 플랫폼 운용자(501)로부터 S510과 같이 통지 기능 진단 명령을 수신한다. 그리고, 운용 환경 연동 모듈은, 특정한 게이트웨이 또는 장치에 대하여 통지 기능 진단 이벤트를 플랫폼으로 전송하기 위한 명령을 게이트웨이/장치 연동 모듈로 보낸다. 이때, M2M 플랫폼에서는 게이트웨이 또는 장치의 상태를 진단하기 위하여 표 1과 같은 내용에 대해서 진단 결과를 요청할 수 있다. 또는 상태 진단 없이 통지 기능 진단 이벤트 명령을 내릴 수도 있다.
한편, 게이트웨이/장치 연동 모듈은 S520과 같이, 해당 게이트웨이 또는 장치를 찾아서 통지 기능 진단 이벤트 통지 명령을 표 2와 같은 내용으로 전달한다.
한편, 게이트웨이 또는 장치는 해당 명령을 수신한 후, 해당 명령에서 요청하는 상태 진단에 대한 내용을 명령에 대한 응답으로 보낸다. 이때, 게이트웨이나 장치의 종류에 따라, 플랫폼에서 내려온 명령에서 상태 진단할 내용이 없거나 상태 진단 내용을 진단 이벤트로 보내기로 한 경우에는 플랫폼과의 약속에 따라 응답 명령을 보내지 않을 수도 있다. 응답을 보낼 경우, 게이트웨이나 장치는 해당 자원의 상태를 파악하여 표 3과 같이 응답 명령에 해당 내용을 보낸다. 이는 S520에서 구현될 수 있다.
그리고나서, 게이트웨이 또는 장치는, 통지 기능 진단 이벤트를 플랫폼으로 전송한다. 이는 S530에서 구현될 수 있다. 이때, 게이트웨이나 장치의 종류에 따라, 플랫폼에서 내려온 명령에서 상태 진단할 내용을 이벤트로 통지하는 경우, 해당 자원의 상태를 파악하여 진단 이벤트에 해당 내용을 보낸다.
이하 도 6 내지 도 8에서는 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차에 대해서 예시를 나타내었다.
도 6은 본 명세서의 일 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 수신 응답 및 진단 결과 통지가 별도의 과정으로 처리되는 예를 보여주는 도면이다.
도 6은 게이트웨이/장치(gateway/device)의 xREM(Remote Entity Management)에서 수행되는 예를 보여주고 있다. xGC(Generic Communication)은 플랫폼과의 통신을 수행하는 기능(capability)로 게이트웨에는 GGC(Gateway Generic Communication), 장치는 DGC(Device Generic Communication)가 상기 기능을 수행할 수 있다. 이하, 도 7 및 도 8에서도 이와 동일하게 xREM, xGC가 포함된다.
통지 기능 처리를 위해서, 수신 프로세스(process)(601)는 플랫폼으로부터 통지 기능 진단을 요청하는 명령을 수신한다(S610). 이 진단 요청 명령이 특정한 모듈에 대한 진단을 요청한 경우, 진단 요청 명령 또는 진단 요청 정보를 진단 프로세스(process)(602)로 보내고(S621), 플랫폼으로 통지 기능 진단 요청을 수신하였음을 알리는 응답 또는 응답 메시지를 보낸다(S622).
한편, 진단 프로세스(process)(602)에서는 요청받은 모듈에 대한 진단을 수행하고(S630), 그 결과를 통지 프로세스(process)(603)로 보낸다(S640). 이는 진단된 결과를 플랫폼으로 통지할 것을 요청하는 것을 의미한다. 통지 프로세스(process)(603)는 진단 결과 내용을 수신하여, 그 결과를 플랫폼으로 통지한다(S650).
도 7은 본 명세서의 다른 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 수신 응답에 진단 결과 통지가 포함되며, 기능 확인 이벤트 통지가 별도의 과정으로 처리되는 예를 보여주는 도면이다. 즉, 도 7은 도 6과 달리, 진단 결과를 통지로 받지 않고 요청에 대한 응답으로 처리하는 경우를 보여주고 있다.
통지 기능 처리를 위해서, 수신 프로세스(process)(701)는 플랫폼으로부터 통지 기능 진단을 요청하는 명령을 수신한다(S710). 이 진단 요청 명령이 특정한 모듈에 대한 진단을 요청한 경우, 진단 요청 명령 또는 진단 요청 정보를 진단 프로세스(process)(702)로 보내고(S721), 통지 기능 진단 요청을 통지 프로세스(process)(703)로 보낸다(S722).
한편, 진단 프로세스(process)(702)에서는 요청받은 모듈에 대한 진단을 수행하고(S730), 그 결과를 수신 프로세스(process)(701)로 보낸다(S740). 수신 프로세스(process)(701)는 전달 받은 진단 내용을 앞서 S710 단계의 요청에 대한 응답으로 플랫폼으로 전달하고(S751), 통지 프로세스(process)(703)는 통지 프로세스(process)에 대한 기능 확인 이벤트를 플랫폼으로 통지한다(S752).
도 8은 본 명세서의 또다른 실시예에 의한, 게이트웨이 또는 장치에서 통지 기능 진단을 위한 처리 절차 중 별도의 하위 모듈에 대한 진단이 없는 경우의 예를 보여주는 도면이다.
통지 기능 처리를 위해서, 수신 프로세스(process)(801)는 플랫폼으로부터 통지 기능 진단을 요청하는 명령을 수신한다(S810). 수신 프로세스(process)(801)는 통지 기능 진단 요청을 통지 프로세스(process)로 보내고(S821), 플랫폼으로 통지 기능 진단 요청을 수신하였음을 알리는 응답 또는 응답 메시지를 보낸다(S822).
통지 프로세스(process)(803)는 통지 기능 진단 요청 정보를 수신 받고 해당 기능 확인 이벤트를 플랫폼으로 통지한다(S830).
한편, 개별 게이트웨이/장치에서는 수신, 진단, 통지 프로세스(process)가 통합되어 있거나, 수신/진단 프로세스(process) 또는 진단/통지 프로세스(process)가 통합되어 있을 수 있으며, 도 6에서 진단할 하위 모듈이 별도로 없을 경우, 수신 프로세스(process)에서 진단 통지 요청을 통지 프로세스(process)로 바로 보낼 수도 있다(S621 단계가 S821과 같이 진행됨).
도 6 내지 도 8에서 수신, 진단, 통지 프로세스(process)는 게이트웨이 및 장치에 따라 별도로 있을 수 있고 하나의 프로세스(process)로 존재하거나, 이 중 2가지 기능이 하나의 프로세스(process)에서 수행될 수도 있다. 물론, 이러한 프로세스(process)를 구현하는 모듈 역시 하나 또는 통합하여 존재할 수 있다.
도 9는 본 명세서의 일 실시예에 의한, 도 6의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 수신 응답 및 진단 결과 통지가 별도의 과정으로 처리되는 도면이다.
도 9에서 M2M 플랫폼(902)의 식별자는 P01이며, M2M 게이트웨이/장치(903)의 식별자는 DG01이다. M2M 플랫폼(902)은 통지기능 진단 요청 메시지를 송신한다(S910). 이때, 통지기능 진단 요청 메시지의 구성은 표 2를 적용할 경우, 플랫폼ID는 P01, TargetID는 DG01, 그리고 진단이 필요한 리소스에 대한 정보는 "110000001"로, 이는 앞서 표 1에서 살펴본 바와 같이, firmware, battery, 외부 인터페이스 모듈에 대한 진단을 필요로 함을 지시하고 있다. flag는 0으로 되어 있는데, 이는 앞서 표 2에서 살펴본 바와 같이, 진단 결과를 도 6의 방식으로 수신하는 것을 지시하고 있다. M2M 게이트웨이/장치(903)는 요청에 따라 상태 진단을 진행하며(S920), 이와 동시에 또는 시간차를 두고, 요청수신에 대한 응답 메시지를 전송한다(S930). S920과 S930은 순차적으로, 혹은 동시에 진행될 수 있으며, 순차적 진행시 그 순서는 S920/S930 또는 S930/S920 순으로 진행될 수 있다.
그리고, S920의 진단이 완료하면, 진단 결과를 통지하는데(S940), 이러한 진단 결과는 앞서 도 3, 4에서 살펴본 <trapInstance>의 diagnosticData에 포함되거나, <notificationInstance>의 diagnosticData에 포함될 수 있다. 물론, 진단 결과는 S910에서 "Diagnostic resource"에서 지시된 리소스에 대한 진단 정보이다.
도 10은 본 명세서의 다른 실시예에 의한, 도 7의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 수신 응답에 진단 결과 통지가 포함되며, 기능 확인 이벤트 통지가 별도의 과정으로 도면이다.
도 10에서 M2M 플랫폼(1002)의 식별자는 P01이며, M2M 게이트웨이/장치(1003)의 식별자는 DG01이다. M2M 플랫폼(1002)은 통지기능 진단 요청 메시지를 송신한다(S1010). 이때, 통지기능 진단 요청 메시지의 구성은 표 2를 적용할 경우, 플랫폼ID는 P01, TargetID는 DG01, 그리고 진단이 필요한 리소스에 대한 정보는 "110000001"로, 이는 앞서 표 1에서 살펴본 바와 같이, firmware, battery, 외부 인터페이스 모듈에 대한 진단을 필요로 함을 지시하고 있다. flag는 1로 되어 있는데, 이는 앞서 표 2에서 살펴본 바와 같이, 진단 결과를 도 7의 방식으로 수신하는 것을 지시하고 있다.M2M 게이트웨이/장치(1003)는 요청에 따라 상태 진단을 진행한다(S1020). 그리고, 진단이 완료하면, S1010의 요청 수신에 대한 응답 메시지 내에 진단 내용을 포함시켜 송신한다(S1030). 이에 대한 결과는 표 3을 예로 하여 SourceID에는 M2M 게이트웨이/장치(1003)의 식별자인 DG01이 포함되며, 플랫폼ID에는 M2M 플랫폼(1002)의 식별자인 P01이 포함되며, 진단 결과는 "Diagnostic result"에 포함된다. 또한, 별도로 기능 확인 이벤트를 통지하게 된다(S1040).
도 11은 본 명세서의 또다른 실시예에 의한, 도 8의 게이트웨이 또는 장치와 플랫폼 간에 통지 기능 진단을 위한 처리 절차 중 별도의 하위 모듈에 대한 진단이 없는 경우를 보여주는 도면이다.
도 11에서 M2M 플랫폼(1102)의 식별자는 P01이며, M2M 게이트웨이/장치(1103)의 식별자는 DG01이다. M2M 플랫폼(1102)은 통지기능 진단 요청 메시지를 송신한다(S1110). 이때, 통지기능 진단 요청 메시지의 구성은 표 2를 적용할 경우, 플랫폼ID는 P01, TargetID는 DG01, 그리고 진단이 필요한 리소스에 대한 정보는 "000000000"로, 이는 앞서 표 1에서 살펴본 바와 같이, 모든 하위 모듈(리소스)에 대한 진단을 수행하지 않는 경우, 모두 "0"으로 하는 실시예를 의미한다. flag는 2로 되어 있는데, 이는 앞서 표 2에서 살펴본 바와 같이, 진단 결과를 도 8의 방식으로 수신하는 것을 지시하고 있다.
그리고, M2M 게이트웨이/장치(1103)는 S1110의 요청을 수신하였음을 알리는 응답 메시지를 송신한다(S1130). 그리고 기능 확인 이벤트를 통지하게 된다(S1140).
도 12는 본 명세서의 일 실시예에서 M2M 플랫폼이 M2M 통신 개체간 통지 기능을 구현하는 과정을 보여주는 도면이다. 즉, M2M 플랫폼이 M2M 게이트웨이 또는 M2M 장치의 하위 모듈에 대한 진단 결과를 수신하거나 또는 상기 하위 모듈의 기능 확인 결과를 수신하는 과정을 보여주는 도면이다.
전체 구현 과정은 M2M 플랫폼(M2M Platform)이 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하는 단계와 상기 M2M 게이트웨이 또는 상기 M2M 장치에서 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 단계로 이루어진다.
보다 상세히 살펴보면 다음과 같다.
M2M 플랫폼은 M2M 게이트웨이 또는 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신한다(S1210). 그리고 상기 요청 메시지가 하위 모듈의 기능확인만을 요청하는 메시지인 경우(S1220), M2M 플랫폼은 M2M 게이트웨이 또는 M2M 장치로부터 상기 요청 메시지에 대한 응답 메시지를 수신하고(S1222), 이와 별도로 기능 확인 결과 메시지를 수신한다(S1224). S1224 단계는 도 8, 도 11에서 살펴본 바와 같이, 상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며, M2M 플랫폼은 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하게 된다.
한편, 요청 메시지가 진단 결과를 요청하는 메시지인 경우, 다시 이러한 진단 결과가 상기 요청메시지의 수신 응답 메시지에 포함되는지에 따라 응답 메시지 수신 과정이 나누어진다(S1230).
먼저, 도 6, 도 9에서 살펴본 바와 같이, 수신 응답 메시지에 진단 결과가 포함되지 않는 경우, M2M 플랫폼은 요청 메시지에 대한 응답 메시지를 수신하고(S1242), 진단 결과 메시지를 수신한다(S1244). 즉, M2M 플랫폼은 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 수신하며, 상기 응답 메시지는 단지 S1210 단계의 요청 메시지가 수신되었음을 알리는 내용만을 포함하도록 구현할 수 있다.
다음으로 도 7 및 도 10에서 살펴본 바와 같이, 수신 응답 메시지에 진단 결과가 포함되는 경우, M2M 플랫폼은 요청 메시지에 대한 응답 메시지(진단 결과 포함)를 수신하고(S1232), 기능확인 결과 메시지를 별도로 수신한다(S1234).
즉, M2M 플랫폼은 S1210 단계의 요청 메시지가 수신되었다는 내용과, 진단 결과가 응답 메시지 내에 모두 포함되며, 또한, 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하여, M2M 개채간의 통지 기능을 구현할 수 있다.
도 12에서 응답 메시지 수신과 기능 확인 결과 메시지 또는 진단 결과 메시지를 분리하여 수신하는 경우, 이들 메시지의 수신 순서는 미리 설정되지 않으며, M2M 게이트웨이 또는 M2M 장치에서 상기 메시지를 생성하여 송신하는 순서에 따라 설정될 수 있다. 또는, 응답 메시지를 먼저 수신하고, 다른 메시지들을 수신하도록 미리 설정할 수 있다. 이는 진단을 수행하거나, 기능을 확인하는 시간이 길어질 경우에 적용 가능하다.
M2M 플랫폼은 상기 진단 결과 또는 기능 확인 결과를 수신한 이후, M2M 게이트웨이/장치의 상태를 정검할 수 있고, 이러한 진단 결과를 M2M 서비스 운용자에게 제공할 수 있다.
도 13은 본 명세서의 일 실시예에서 M2M 게이트웨이 또는 M2M 장치가 M2M 통신 개체간 통지 기능을 구현하는 과정을 보여주는 도면이다. 즉, M2M 게이트웨이 또는 M2M 장치가 M2M 플랫폼으로부터 하위 모듈에 대한 진단 결과를 또는 상기 하위 모듈의 기능 확인을 요청받아 이에 대한 결과를 송신하는 과정을 보여주는 도면이다.
전체 구현 과정은 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)가 M2M 플랫폼(M2M Platform)으로부터 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 수신하고, 상기 요청 메시지에 따라, 하위 모듈에 대한 진단을 수행하거나, 또는 하위 모듈의 기능 확인을 수행한 후, 상기 M2M 플랫폼에 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 송신하는 과정으로 이루어져 있다.
보다 상세히 살펴보면 다음과 같다.
M2M 게이트웨이 또는 M2M 장치는 M2M 플랫폼으로부터 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 수신한다(S1310). 그리고 상기 요청 메시지가 하위 모듈의 기능확인만을 요청하는 메시지인 경우(S1320), M2M 게이트웨이 또는 M2M 장치는 상기 요청 메시지에 대한 응답 메시지를 송신하고(S1322), 이와 별도로 기능 확인 결과 메시지를 송신한다(S1324). S1324 단계는 도 8, 도 11에서 살펴본 바와 같이, 상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며, M2M 게이트웨이 또는 M2M 장치는 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 송신하게 된다.
한편, 요청 메시지가 진단 결과를 요청하는 메시지인 경우, M2M 게이트웨이 또는 M2M 장치는 해당 하위 모듈을 진단한다(S1330). 그리고, 이러한 진단 결과가 상기 요청메시지의 수신에 대한 응답 메시지에 포함되는지에 따라 응답 메시지 송신 과정이 나누어진다(S1340).
먼저, 도 6, 도 9에서 살펴본 바와 같이, 응답 메시지에 진단 결과가 포함되지 않는 경우, M2M 게이트웨이 또는 M2M 장치는 요청 메시지에 대한 응답 메시지를 송신하고(S1352), 진단 결과 메시지를 송신한다(S1354). 즉, M2M 게이트웨이 또는 M2M 장치는 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 송신하며, 상기 응답 메시지는 단지 S1310 단계의 요청 메시지가 수신되었음을 알리는 내용만을 포함하도록 구현할 수 있다.
다음으로 도 7 및 도 10에서 살펴본 바와 같이, 응답 메시지에 진단 결과가 포함되는 경우, M2M 게이트웨이 또는 M2M 장치는 요청 메시지에 대한 응답 메시지(진단 결과 포함)를 송신하고(S1342), 기능확인 결과 메시지를 별도로 수신한다(S1344).
즉, M2M 게이트웨이 또는 M2M 장치는 S1310 단계의 요청 메시지가 수신되었다는 내용과 진단 결과를 응답 메시지 내에 모두 포함시켜 송신하며, 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 송신하여, M2M 개채간의 통지 기능을 구현할 수 있다.
도 13에서 응답 메시지 송신과 기능 확인 결과 메시지 또는 진단 결과 메시지를 분리하여 송신하는 경우, 이들 메시지의 송신 순서는 미리 설정되지 않으며, M2M 게이트웨이 또는 M2M 장치에서 상기 메시지를 생성하여 송신하는 순서에 따라 설정될 수 있다. 또는, 응답 메시지를 먼저 송신하고, 다른 메시지들을 송신하도록 미리 설정할 수 있다. 이는 진단을 수행하거나, 기능을 확인하는 시간이 길어질 경우에 적용 가능하다.
도 14는 본 명세서의 일 실시예에 의한 M2M 게이트웨이와 M2M 장치, 그리고 M2M 플랫폼의 구성을 보여주는 도면이다.
M2M 플랫폼(1440)은 앞서 도 12의 통지 기능 구현 과정을 제공하며, M2M 장치(1410) 또는 M2M 게이트웨이(1420)는 도 13의 통지 기능 구현 과정을 제공한다.
도 14는 본 명세서의 일 실시예에 의한 M2M 플랫폼(platform), M2M 장치(device), M2M 게이트웨이(gateway)의 구성을 보여주는 도면이다. 도 14는 M2M 통신 개체간 통지 기능을 구현하는 경우를 중심으로 설명하고 있다. 도 14에서 메시지는 통지 기능을 구현하기 위해 M2M 플랫폼과 M2M 장치, 또는 M2M 플랫폼과 M2M 게이트웨이간에 송수신되는 정보를 총칭한다.
통지 기능을 구현하기 위해서, M2M 플랫폼(1440) 또는 M2M 플랫폼(1440)을 구성하는 하위 모듈로서, 운용 환경 연동 모듈(1442), 게이트웨이/장치 연동 모듈 (1446)을 포함한다. 각각의 모듈이 하는 기능을 살펴보면, 운용 환경 연동 모듈(1442)은 게이트웨이 및 장치에 대한 통지 기능을 확인하고, 상태 정보를 취합하기 위하여, M2M 서비스 운용자(1450)로부터 통지 기능 진단 명령을 포함하는 메시지를 수신하고 진단 결과 또는 통지 기능을 확인한 결과 등을 M2M 서비스 운용자(1450)에게 송신한다.
게이트웨이/장치연동 모듈 (1446)은 게이트웨이 및 장치로 하위 모듈 진단 또는 통지 기능 확인을 요청하는 메시지를 송신하고, 게이트웨이 및 장치로부터 진단 결과 메시지, 또는 기능 확인 결과 메시지와 응답 메시지를 수신한다.
통지 기능을 구현하기 위해서 M2M 장치(1410) 또는 M2M 장치(1410)를 구성하는 하위 모듈로, 플랫폼 연동 모듈(1412)와 진단 모듈(1414), 그리고 통지 모듈(1414)가 있다. 플랫폼 연동 모듈(1412)은 M2M 플랫폼(1440)으로부터 하위 모듈 진단 또는 통지 기능 확인을 요청하는 메시지를 수신하고, M2M 플랫폼(1440)에게 상기 메시지의 수신 여부를 알리는 응답 메시지를 송신한다. 한편, 진단 모듈(1414)은 통지 기능을 구현하기 위해 M2M 게이트웨이/장치의 하위 모듈에 대한 진단을 수행하며, 통지 모듈(1416)은 상기 진단된 결과 또는 기능 확인 결과를 M2M 플랫폼(1440)에 송신하는 역할을 수행한다. 한편, 상기 진단된 결과는 앞서 도 7 또는 도 10에서 응답 메시지 내에 포함될 수 있으며, 이 경우, 플랫폼 연동 모듈(1412)이 진단 결과를 M2M 플랫폼(1440)에 전송할 수 있다. 이와 달리, 통지 모듈(1416)이 응답 메시지 내에 진단 결과를 포함시켜 M2M 플랫폼(1440)에 전송하도록 구현할 수 있다.
M2M2 게이트웨이(1420)의 플랫폼 연동 모듈(1422), 진단 모듈(1424), 통지 모듈(1426)들은 상기 M2M 장치(1410)의 플랫폼 연동 모듈(1412), 진단 모듈(1414), 그리고 통지 모듈(1416)의 역할 또는 수행하는 기능과 동일하거나, 혹은 게이트웨이 고유의 기능들과 결합하여 통지 기능을 수행할 수 있다.
앞서 살펴본 통지 기능을 구현할 경우, 플랫폼 운용자의 필요에 따라 M2M 플랫폼을 통하여 게이트웨이 또는 장치로 통지 기능 진단 이벤트를 확인하는 명령을 내리고, 해당 게이트웨이 또는 장치에서는 통지 기능 진단 이벤트를 플랫폼으로 통지함으로써 망에 대한 부하를 유발하지 않으면서 해당 게이트웨이 및 장치로부터 전달되는 다른 이벤트들을 신뢰성 있게 관리하는 효과가 있다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시 예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시 예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
122, 125, 504, 1410 : M2M 장치(M2M device)
121, 503, 1420 : M2M 게이트웨이
203, 903, 1003, 1103 : M2M 게이트웨이/장치
202, 502, 902, 1002, 1102, 1440 : M2M 플랫폼
501, 1450: M2M 서비스 운용자

Claims (18)

  1. M2M 플랫폼(M2M Platform)이 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하는 단계; 및
    상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  2. 제 1항에 있어서,
    상기 수신하는 단계는 상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 수신하는 단계를 포함하며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  3. 제 1항에 있어서,
    상기 응답 메시지 내에 상기 진단 결과가 포함되는 것을 특징으로 하며,
    상기 수신하는 단계는 상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  4. 제 1항에 있어서,
    상기 요청 메시지는 상기 하위 모듈의 기능 확인만을 요청하는 메시지이며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며,
    상기 수신하는 단계는 상기 M2M 게이트웨이 또는 상기 M2M 장치로부터 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  5. 제 1항에 있어서,
    상기 진단 결과 또는 기능 확인 결과는 트랩(trap)을 위한 통지 기능 메시지 내에 포함되는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  6. M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)가 M2M 플랫폼(M2M Platform)으로부터 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 수신하는 단계;
    상기 요청 메시지에 따라, 하위 모듈에 대한 진단을 수행하거나, 또는 하위 모듈의 기능 확인을 수행하는 단계; 및
    상기 M2M 플랫폼에 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 상기 M2M 플랫폼에 송신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  7. 제 6항에 있어서,
    상기 송신하는 단계는 상기 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 상기 M2M 플랫폼에 송신하는 단계를 포함하며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  8. 제 6항에 있어서,
    상기 응답 메시지 내에 상기 진단 결과가 포함되는 것을 특징으로 하며,
    상기 송신하는 단계는 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 상기 M2M 플랫폼에 송신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  9. 제 6항에 있어서,
    상기 요청 메시지는 상기 하위 모듈의 기능 확인만을 요청하는 메시지이며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며,
    상기 송신하는 단계는 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 상기 M2M 플랫폼에 송신하는 단계를 포함하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  10. 제 6항에 있어서,
    상기 진단 결과 또는 기능 확인 결과는 트랩(trap)을 위한 통지 기능 메시지 내에 포함되는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 방법.
  11. M2M 서비스 운용자로부터 M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)의 통지 기능 진단 명령을 수신하고, 상기 수신한 명령에 대한 M2M 게이트웨이 또는 M2M 장치의 진단 결과를 상기 M2M 서비스 운용자에게 통지하는 운용 환경 연동 모듈; 및
    상기 통지 기능 진단 명령에 따라 M2M 게이트웨이 또는 M2M 장치에 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 송신하고, 상기 M2M 게이트웨이 또는 상기 M2M 장치에서 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 수신하는 게이트웨이/장치 연동 모듈을 포함하는, M2M 통신 개체간 통지 기능을 구현하는 M2M 플랫폼.
  12. 제 11항에 있어서,
    상기 게이트웨이/장치 연동 모듈은 상기 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 수신하며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 M2M 플랫폼.
  13. 제 11항에 있어서,
    상기 응답 메시지 내에 상기 진단 결과가 포함되는 것을 특징으로 하며,
    상기 게이트웨이/장치 연동 모듈은 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 M2M 플랫폼.
  14. 제 11항에 있어서,
    상기 요청 메시지는 상기 하위 모듈의 기능 확인만을 요청하는 메시지이며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며,
    상기 게이트웨이/장치 연동 모듈은 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 수신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 M2M 플랫폼.
  15. M2M 게이트웨이(M2M gateway) 또는 M2M 장치(M2M device)가 M2M 플랫폼(M2M Platform)으로부터 상기 M2M 게이트웨이 또는 상기 M2M 장치의 하위 모듈에 대한 진단 또는 상기 하위 모듈의 기능 확인을 요청하는 요청 메시지를 플랫폼 연동 모듈;
    상기 요청 메시지에 따라, 하위 모듈에 대한 진단을 수행하는 진단 모듈; 및
    하위 모듈의 기능 확인을 수행하거나 상기 진단 결과 또는 상기 기능 확인 결과를 상기 M2M 플랫폼에 송신하는 통지 모듈을 포함하며,
    상기 플랫폼 연동 모듈 또는 상기 통지 모듈은 상기 M2M 플랫폼에 상기 요청 메시지의 수신을 알리는 응답 메시지 또는 상기 진단 결과 또는 기능 확인 결과를 알리는 메시지 중 어느 하나 이상을 상기 M2M 플랫폼에 송신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 장치.
  16. 제 15항에 있어서,
    상기 통지 모듈은 상기 응답 메시지와 분리하여 상기 진단 결과를 알리는 메시지를 송신하며,
    상기 플랫폼 연동 모듈은 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하는 응답 메시지를 상기 M2M 플랫폼에 송신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 장치.
  17. 제 15항에 있어서,
    상기 응답 메시지 내에 상기 진단 결과가 포함되는 것을 특징으로 하며,
    상기 통지 모듈은 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 상기 M2M 플랫폼에 송신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 장치.
  18. 제 15항에 있어서,
    상기 요청 메시지는 상기 하위 모듈의 기능 확인만을 요청하는 메시지이며,
    상기 응답 메시지는 상기 요청 메시지가 수신되었음을 알리는 내용만을 포함하며,
    상기 통지 모듈은 상기 응답 메시지와 분리하여 상기 기능 확인 결과를 알리는 메시지를 상기 M2M 플랫폼에 송신하는 것을 특징으로 하는, M2M 통신 개체간 통지 기능을 구현하는 장치.
KR1020110118842A 2011-11-15 2011-11-15 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치 KR101807317B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020110118842A KR101807317B1 (ko) 2011-11-15 2011-11-15 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020110118842A KR101807317B1 (ko) 2011-11-15 2011-11-15 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20130053202A true KR20130053202A (ko) 2013-05-23
KR101807317B1 KR101807317B1 (ko) 2017-12-08

Family

ID=48662499

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020110118842A KR101807317B1 (ko) 2011-11-15 2011-11-15 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치

Country Status (1)

Country Link
KR (1) KR101807317B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101466210B1 (ko) * 2013-09-27 2014-11-27 에스케이 텔레콤주식회사 Ｍ2ｍ 단말기로 장문 메시지를 전달하는 방법 및 장치
CN109997114A (zh) * 2016-10-07 2019-07-09 康维达无线有限责任公司 用于通用互通和可扩展性的服务层资源管理

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101466210B1 (ko) * 2013-09-27 2014-11-27 에스케이 텔레콤주식회사 Ｍ2ｍ 단말기로 장문 메시지를 전달하는 방법 및 장치
CN109997114A (zh) * 2016-10-07 2019-07-09 康维达无线有限责任公司 用于通用互通和可扩展性的服务层资源管理
CN109997114B (zh) * 2016-10-07 2023-09-29 康维达无线有限责任公司 用于通用互通和可扩展性的服务层资源管理
US11799711B2 (en) 2016-10-07 2023-10-24 Convida Wireless, Llc Service layer resource management for generic interworking and extensibility

Also Published As

Publication number Publication date
KR101807317B1 (ko) 2017-12-08

Similar Documents

Publication Publication Date Title
WO2018196685A1 (zh) 通信方法、网络设备和系统
US9553831B2 (en) Adaptive publish/subscribe system
KR102059257B1 (ko) 강화된 효율성을 위해 서비스 레이어 가입들 및 통지들을 분석하고 그룹화하는 방법들 및 장치들
CN104242465B (zh) 一种基于b/s的变电站远程监控系统及方法
EP3060018B1 (en) Registration method and system for common service entity
CN102938770B (zh) 一种实现多协议消息统一接口的方法及相关装置、系统
US20150304120A1 (en) Video Conference Scheduling Method and Apparatus
CN105723788A (zh) 用于在m2m通信系统中进行订阅和通知的方法及其设备
US11095747B2 (en) Method and apparatus for receiving response information in M2M system
CN104092774A (zh) 软件定义网络连接建立控制方法及装置
EP3062544B1 (en) Method, node and system for managing resources of machine type communication application
KR20190030116A (ko) Dds 미들웨어를 이용한 마이크로그리드 에너지관리시스템
KR102500594B1 (ko) 통신 네트워크에서의 서비스 계층 메시지 템플릿들
KR101807317B1 (ko) Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치
KR20120124345A (ko) 연결 상태 확인 이벤트에 기반하여 ｍ2ｍ 통신 개체간 연결을 관리하는 방법 및 장치
US20220330303A1 (en) Network monitoring in service enabler architecture layer (seal)
CN103490915A (zh) 故障分析方法及装置
CN103166779A (zh) 一种基于移动终端的告警确认和处理方法及装置
US10880411B2 (en) Interdevice communications
EP3905763A1 (en) Communication method and network device
US10013366B2 (en) Standardized hot-pluggable transceiving unit and method for controlling the unit through a web server function
CN105263163A (zh) 一种通知消息的发送方法、装置和系统
CN111431894A (zh) 一种通用服务协议在透明访问框架中的实现方法
CN102244657B (zh) 多点控制单元级联会议的注册方法及系统
JP2018074526A (ja) 携帯端末、電気錠制御システム、携帯端末の制御方法、制御プログラム、および記録媒体

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant