KR20170028878A - 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치 - Google Patents

Abstract

무선 통신 시스템에서 이종 시스템간의 요청 메시지를 처리하기 위한 방법으로서, 상기 방법은 게이트웨이 장치에 의해 수행되며, 제 1 시스템에 속한 제 1 노드로부터 제 1 노드의 서비스에 대한 광고 메시지를 수신하는 단계, 상기 광고 메시지가 상기 서비스가 제 2 시스템과 공유되는지에 대한 지시자를 포함하면, 상기 공유되는 서비스에 대응하는 자원 및 상기 공유되는 서비스에 대응하는 자원에 대한 접근 제어를 위한 자원을 생성하는 단계, 상기 제 2 시스템의 제 2 노드로부터 상기 생성된 자원에 대한 정보의 회수(retrieve)를 위한 요청 메시지를 수신하는 단계, 상기 제 2 노드가 상기 회수에 대한 접근 권한이 있으면, 상기 생성된 자원에 대한 정보를 상기 제 2 노드로 전송하는 단계, 상기 제 2 노드로부터 상기 생성된 자원의 정보에서 선택된 호출하고자 하는 서비스에 대응하는 자원을, 상기 생성된 자원의 자식 자원으로 생성하기 위한 요청 메시지를 수신하는 단계 및 상기 자식 자원의 생성에 대한 접근 권한을 체크하는 단계를 포함할 수 있다.

Description

무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치{METHOD FOR PROCESSING REQUEST MESSAGES IN WIRELESS COMMUNICATION SYSTEM, AND DEVICE FOR SAME}

본 발명은 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치에 관한 것이다.

유비쿼터스 시대에 접어들면서 M2M(Machine to Machine) 통신 기술이 각광 받고 있다. M2M 통신 기술은 TIA, ATIS, ETSI, oneM2M 등 많은 표준화 개발 기구(SDO: Standard Development Organization)에서 연구 중에 있다. M2M 환경에서는 여러 M2M 관련 애플리케이션(Network Application/Gateway Application/Device Application)간의 통신이 발생하고, M2M 플랫폼 또는 프레임워크(예컨대, 공통 서비스 엔티티(Common Service Entity; CSE)과 네트워크 측 애플리케이션(예컨대, Network Application)를 운용하는 주체가 다를 수 있다.

또한, M2M 통신을 효율성을 위해 또는 또다른 목적 또는 효과를 위해 서로 다른 M2M 시스템(즉, 이종 시스템)에 속한 M2M 장치 사이로 확장하고자 하는 시도가 있다. 최근에 이와 관련하여 서로 다른 M2M 시스템 간 연동 조합이 이루어지고 있다.

따라서, 본 발명은 이종의 M2M 시스템 간의 연동을 위한 방안을 제안하고자 한다. 특히, 서로 다른 API(application program interface) 스타일을 사용하는 시스템 간의 연동을 위한 방안을 제안하고자 한다.

본 발명은 이종의 시스템 간 연동을 위한 방안을 제안하고자 하며, 좀더 상세하게는, 이종의 시스템 간 요청 메시지의 처리 방안에 대해 제안하고자 한다.

본 발명이 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 이하의 발명의 상세한 설명으로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 실시예에 따른 무선 통신 시스템에서 이종 시스템간의 요청 메시지를 처리하기 위한 방법으로서, 상기 방법은 게이트웨이 장치에 의해 수행되며, 제 1 시스템에 속한 제 1 노드로부터 제 1 노드의 서비스에 대한 광고 메시지를 수신하는 단계, 상기 광고 메시지가 상기 서비스가 제 2 시스템과 공유되는지에 대한 지시자를 포함하면, 상기 공유되는 서비스에 대응하는 자원 및 상기 공유되는 서비스에 대응하는 자원에 대한 접근 제어를 위한 자원을 생성하는 단계, 상기 제 2 시스템의 제 2 노드로부터 상기 생성된 자원에 대한 정보의 회수(retrieve)를 위한 요청 메시지를 수신하는 단계, 상기 제 2 노드가 상기 회수에 대한 접근 권한이 있으면, 상기 생성된 자원에 대한 정보를 상기 제 2 노드로 전송하는 단계, 상기 제 2 노드로부터 상기 생성된 자원의 정보에서 선택된 호출하고자 하는 서비스에 대응하는 자원을, 상기 생성된 자원의 자식 자원으로 생성하기 위한 요청 메시지를 수신하는 단계, 및 상기 자식 자원의 생성에 대한 접근 권한을 체크하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 광고 메시지는 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 광고 메시지가 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 포함하지 않으면, 제 2 시스템의 모든 노드에게 상기 서비스가 연동될 수 있다.

추가적으로 또는 대안적으로, 상기 제 2 노드가 상기 자식 자원의 생성에 대한 접근 권한이 있으면, 상기 방법은 상기 자식 자원을 생성하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 자식 자원이 생성되면, 상기 방법은 상기 자식 자원에 대응하는 서비스의 수행을 상기 제 1 노드로 호출하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 방법은 상기 호출한 서비스의 처리 결과를 상기 제 1 노드로부터 수신하고, 상기 결과를 상기 생성된 자원의 특정 자식 자원에 업데이트하는 단계를 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 방법은 상기 선택된 호출하고자 하는 서비스의 처리 결과를 통지받기 위한 자원을 생성하기 위한 요청을 수신하는 단계를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 제 1 시스템은 제 1 인터페이스 타입을 사용하고, 상기 제 2 시스템은 제 2 인터페이스 타입을 사용할 수 있다.

추가적으로 또는 대안적으로, 상기 제 1 인터페이스 타입은 RPC(remote procedure call) API(application program interface)이고, 상기 제 2 인터페이스 타입은 리소스(resource) API 일 수 있다.

본 발명의 또다른 일 실시예에 따른 무선 통신 시스템에서 요청 메시지를 처리하도록 구성된 M2M 장치에 있어서, 상기 장치는 무선 주파수(radio frequency, RF) 유닛 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되, 상기 프로세서는 제 1 시스템에 속한 제 1 노드로부터 제 1 노드의 서비스에 대한 광고 메시지를 수신하고, 상기 광고 메시지가 상기 서비스가 제 2 시스템과 공유되는지에 대한 지시자를 포함하면, 상기 공유되는 서비스에 대응하는 자원 및 상기 공유되는 서비스에 대응하는 자원에 대한 접근 제어를 위한 자원을 생성하고, 상기 제 2 시스템의 제 2 노드로부터 상기 생성된 자원에 대한 정보의 회수(retrieve)를 위한 요청 메시지를 수신하고, 상기 제 2 노드가 상기 회수에 대한 접근 권한이 있으면, 상기 생성된 자원에 대한 정보를 상기 제 2 노드로 전송하고, 상기 제 2 노드로부터 상기 생성된 자원의 정보에서 선택된 호출하고자 하는 서비스에 대응하는 자원을, 상기 생성된 자원의 자식 자원으로 생성하기 위한 요청 메시지를 수신하고, 상기 자식 자원의 생성에 대한 접근 권한을 체크하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 광고 메시지는 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 더 포함할 수 있다.

추가적으로 또는 대안적으로, 상기 광고 메시지가 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 포함하지 않으면, 제 2 시스템의 모든 노드에게 상기 서비스가 연동될 수 있다.

추가적으로 또는 대안적으로, 상기 제 2 노드가 상기 자식 자원의 생성에 대한 접근 권한이 있으면, 상기 프로세서는 상기 자식 자원을 생성하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 자식 자원이 생성되면, 상기 프로세서는 상기 자식 자원에 대응하는 서비스의 수행을 상기 제 1 노드로 호출하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 프로세서는 상기 호출한 서비스의 처리 결과를 상기 제 1 노드로부터 수신하고, 상기 결과를 상기 생성된 자원의 특정 자식 자원에 업데이트하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 프로세서는 상기 선택된 호출하고자 하는 서비스의 처리 결과를 통보받기 위한 자원을 생성하기 위한 요청을 수신하도록 구성될 수 있다.

추가적으로 또는 대안적으로, 상기 제 1 시스템은 제 1 인터페이스 타입을 사용하고, 상기 제 2 시스템은 제 2 인터페이스 타입을 사용할 수 있다.

추가적으로 또는 대안적으로, 상기 제 1 인터페이스 타입은 RPC(remote procedure call) API(application program interface)이고, 상기 제 2 인터페이스 타입은 리소스(resource) API 일 수 있다.

상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며, 본 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.

본 발명의 일 실시예에 따르면, 이종의 무선 통신 시스템 간 요청 메시지 처리를 원활하게 그리고 효율적으로 수행할 수 있다.

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

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1 은 M2M 통신 시스템에서의 기능 구조를 도시한다.
도 2 는 M2M 기능 구조에 기반하여 M2M 통신 시스템이 지원하는 구성을 도시한다.
도 3 은 M2M 통신 시스템에서 제공되는 공통 서비스 기능을 도시한다.
도 4 는 M2M 애플리케이션 서비스 노드와 M2M 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.
도 5 는 M2M 애플리케이션 서비스 노드(예컨대, M2M 디바이스)와 M2M 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.
도 6 은 M2M 통신 시스템에서 사용하는 요청 및 응답 메시지를 주고받는 절차를 도시한다.
도 7 은 M2M 통신 시스템에서 등록 절차를 도시한다.
도 8 은 리소스 API 와 관련된 동작을 도시한다.
도 9 는 RPC API 와 관련된 동작을 도시한다.
도 10 은 AllJoyn 프레임워크의 구성도를 도시한다.
도 11 은 이종 시스템의 서비스 범위에 따른 차이점을 도시한다.
도 12 는 AllJoyn 시스템과 oneM2M 시스템 연동에 따른 구조 및 정보 불일에 따른 문제점을 도시한다.
도 13 은 본 발명의 일 실시예에 따른 이종 시스템의 상호 연결 구조를 도시한다.
도 14 는 본 발명의 일 실시예에 따른 자원 구조를 도시한다.
도 15 및 도 16 은 본 발명의 실시예예 따른 절차를 도시한다.
도 17 은 특정 자원에 대한 접근 권한을 체크하는 절차를 도시한다.
도 18 은 본 발명의 실시예(들)을 수행하도록 구성된 장치의 블록도를 도시한다.

이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시 형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명한다.

본 발명에 있어서, 기기간 통신을 위한 디바이스 즉, M2M 디바이스는 고정되거나 이동성을 가질 수 있으며, 기기간 통신을 위한 서버 즉, M2M 서버와 통신하여 사용자데이터 및/또는 각종 제어정보를 송수신하는 각종 기기들이 이에 속한다. 상기 M2M 디바이스는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선기기(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대기기(handheld device) 등으로 불릴 수 있다. 또한, 본 발명에 있어서, M2M 서버는 일반적으로 M2M 디바이스들 및/또는 다른 M2M 서버와 통신하는 고정된 지점(fixed station)을 말하며, M2M 디바이스들 및/또는 다른 M2M 서버와 통신하여 각종 데이터 및 제어정보를 교환한다.

이하에서는 본 발명과 관련된 기술에 대해 설명한다.

M2M 애플리케이션

서비스 로직을 실행하고 개방 인터페이스를 통해 접근 가능한(accessible) 공통 서비스 엔티티(Common Service Entity; CSE)를 사용하는 애플리케이션. M2M 애플리케이션은 M2M 디바이스, M2M 게이트웨이 또는 M2M 서버에 설치 또는 탑재될 수 있다.

M2M 공통 서비스

표준화된 인터페이스들을 통해 M2M CSE 가 이용가능하게 하는 기능들의 집합

oneM2M 은 다양한 M2M 애플리케이션(또는 애플리케이션 엔티티(Application Entity; AE)) 들을 위한 공통 M2M 서비스 프레임워크(또는 서비스 플랫폼, 공통 서비스 엔티티(CSE) 등)를 정의한다. M2M 애플리케이션이라고 하면, e-Health, City Automation, Connected Consumer, Automotive 등의 서비스 로직을 구현한 소프트웨어라고 볼 수 있으며, 이러한 다양한 M2M 애플리케이션들을 구현하기 위해, 공통적으로 필요한 기능들을 oneM2M 서비스 프레임워크는 포함하고 있다. 따라서, oneM2M 서비스 프레임워크를 이용하면, 다양한 M2M 애플리케이션들마다 필요한 각각의 프레임워크를 구성할 필요 없이, 이들 M2M 애플리케이션들을 쉽게 구현할 수 있다. 이는 현재 Smart Building, Smart Grid, e-Health, Transportation, Security 등 여러 M2M 버티컬(Vertical)들로 분열되어 있는 M2M 시장을 공통 oneM2M 서비스 프레임워크를 중심으로 통합할 수 있으며, 이는 M2M 시장을 크게 촉진할 것으로 기대된다.

도 1 은 M2M 통신 시스템에서의 기능 구조를 도시한다. 각 엔티티를 설명하도록 한다.

애플리케이션 엔티티 (AE, 101): 애플리케이션 엔티티는 단대단 M2M 솔루션을 위한 애플리케이션 로직을 제공한다. AE 의 예로는 화물 추적, 원격 혈당 모니터링, 원격 전력 측정 및 제어 애플리케이션이 있다. (Application Entity provides Application logic for the end-to-end M2M solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.) 보다 쉬운 이해를 위해, AE 는 M2M 애플리케이션으로 지칭될 수 있다.

공통 서비스 엔티티 (CSE, 102): CSE 는 M2M 환경에 공통적인 oneM2M 에서 정의된 서비스 기능들로 이루어져 있다. 이러한 서비스 기능들은 레퍼런스 포인트 Mca, Mcc 를 통해 노출되어 등록된(연결된) AE 와 타 CSE 에 의해 사용될 수 있다. 레퍼런스 포인트 Mcn 는 언더라잉 네트워크의 서비스를 접근하는데 사용된다. (A Common Services Entity comprises the set of "service functions" that are common to the M2M environments and specified by oneM2M. Such service functions are exposed to other entities through Reference Points Mca and Mcc. Reference point Mcn is used for accessing Underlying Network Service Entities.)

CSE 에서 제공하는 서비스 기능들의 예로는 데이터 관리, 디바이스 관리, M2M 구독(subscription) 관리, 위치 서비스 등이 있다. 이러한 기능들은 논리적으로 CSF(Common Services Functions)로 나뉘어 질 수 있다. CSE 안의 몇몇 CSF 는 필수적으로 존재하여야 하고, 몇몇은 선택적으로 존재 가능하다. 또한 CSF 안의 몇몇 기능은 필수적으로 존재하여야 하고, 몇몇 기능은 선택적으로 존재 가능하다. (예, "디바이스 관리" CSF 안에, 애플리케이션 소프트웨어 설치, 펌웨어 업데이트, 로깅, 모니터링 중 몇몇은 필수 기능이며, 몇몇은 선택 기능이다.)

언더라잉 네트워크 서비스 엔티티 (NSE, 103): NSE 는 CSE 에 서비스를 제공하는데, 이러한 서비스의 예로는 디바이스 관리, 위치 서비스, 디바이스 트리거링 등이 있다. NSE 는 특정 기술로 한정하지 않으며, 네트워크가 기본적으로 제공해주는 트랜스포트(transport)의 경우 NSE 의 서비스로 생각하지 않는다.(An Underlying Network Services Entity provides services to the CSEs. Examples of such services include device management, location services and device triggering. No particular organization of the NSEs is assumed. Note: Underlying Networks provide data transport services between entities in the oneM2M system. Such data transport services are not included in the NSE.)

아울러, 도 1 에 도시된 각 레퍼런스 포인트에 대해 설명하도록 한다.

Mca 레퍼런스 포인트

Mca 레퍼런스 포인트는 AE 와 CSE 간의 레퍼런스 포인트이다. Mca 레퍼런스 포인트는 AE 가 CSE 가 제공하는 서비스를 사용할 수 있도록, AE 가 CSE 와 통신할 수 있도록 한다. (This is the reference point between an Application Entity and a CSE. The Mca reference point shall allow an Application Entity to use the services provided by the CSE, and for the CSE to communicate with the Application Entity.)

Mca 레퍼런스 포인트를 통해 제공되는 서비스들은 CSE 에서 제공하는 기능들에 의존한다. AE 와 CSE 는 같은 물리적 장치에 있을 수도 있으며, 다른 물리적 장치에 있을 수도 있다. (The services offered via the Mca reference point are thus dependent on the functionality supported by the CSE. The Application Entity and the CSE it invokes may or may not be co-located within the same physical entity.)

Mcc 레퍼런스 포인트

Mcc 레퍼런스 포인트는 두 CSE 간의 레퍼런스 포인트이다. Mcc 레퍼런스 포인트는 CSE 가 다른 CSE 의 필요한 기능의 서비스를 사용할 수 있도록 한다. Mcc 레퍼런스 포인트를 통해 제공되는 서비스들은 CSE 에서 제공하는 기능들에 의존한다. (This is the reference point between two CSEs. The Mcc reference point shall allow a CSE to use the services of another CSE in order to fulfill needed functionality. Accordingly, the Mcc reference point between two CSEs shall be supported over different M2M physical entities. The services offered via the Mcc reference point are dependent on the functionality supported by the CSEs)

Mcn 레퍼런스 포인트

Mcn 레퍼런스 포인트는 CSE 와 NSE 간의 레퍼런스 포인트이다. Mcn 레퍼런스 포인트는 CSE 가 NSE 가 제공하는 서비스들을 사용할 수 있도록 한다. (This is the reference point between a CSE and the Underlying Network Services Entity. The Mcn reference point shall allow a CSE to use the services (other than transport and connectivity services) provided by the Underlying Network Services Entity in order to fulfill the needed functionality. ) NSE 가 제공하는 서비스는 전송(transport)과 접속(connectivity) 서비스 같은 단순한 서비스 이외의 것을 뜻하며, 디바이스 트리거링(device triggering), 스몰 데이터 전송(small data transmission), 위치 결정(positioning)과 같은 서비스가 그 예이다.

Mcc' 레퍼런스 포인트

Mcc' 레퍼런스 포인트는 서로 다른 M2M 서비스 제공자에게 속하는 CSE 간의 통신을 위해 사용된다. Mcc' 레퍼런스 포인트는 Mcc 레퍼런스 포인트와 CSE 를 서로 연결한다는 점에서 비슷할 수 있으나, 기존 Mcc 레퍼런스 포인트가 단일 M2M 서비스 제공자 내의 통신으로 국한되어 있었다면 Mcc' 레퍼런스 포인트는 서로 다른 M2M 서비스 제공자로 Mcc 를 확장한다는 개념으로 볼 수 있다.

도 2 는 M2M 기능 구조에 기반하여 M2M 통신 시스템이 지원하는 구성을 도시한다. M2M 통신 시스템은 도시된 구성에 국한되지 않고 더 다양한 구성을 지원할 수 있다. 상기 도시된 구성을 이해하는데 중요한 노드(Node)라는 개념에 대해 먼저 설명하도록 한다.

애플리케이션 전용 노드(Application Dedicated Node; ADN): CSE 가 존재하지 않고, 적어도 하나의 AE 를 갖는 노드 (An Application Dedicated Node is a Node that contains at least one Application Entity and does not contain a Common Services Entity). Mca 레퍼런스 포인트를 통해 하나의 미들 노드 또는 하나의 인프라스트럭쳐 노드와 연결될 수 있다. ADN 은 M2M 디바이스에 존재할 수 있다.

애플리케이션 서비스 노드(Application Service Node; ASN): 하나의 CSE 가 존재해야 하고, 적어도 하나의 AE 를 갖는 노드(An Application Service Node is a Node that contains one Common Services Entity and contains at least one Application Entity). Mcc 레퍼런스 포인트를 통해 하나의 미들 노드 또는 하나의 인프라스트럭쳐 노드에 연결될 수 있다. ASN 은 M2M 디바이스에 존재할 수 있다.

미들 노드(Middle Node; MN): 하나의 CSE 가 존재해야 하고, AE 를 가질 수도 있는 노드(A Middle Node is a Node that contains one Common Services Entity and may contain Application Entities). Mcc 레퍼런스 포인트를 통해서 아래 다른 카테고리에 속하는 두 노드와 연결되어야 함 (A Middle Node communicates over a Mcc references point with at least two other Nodes among either (not exclusively)):

- 하나 이상의 애플리케이션 서비스 노드(ASN)들;

- 하나 이상의 미들 노드(MN)들;

- 하나 인프라스트럭쳐 노드(IN).

또한, MN 은 ADN 과 Mca 레퍼런스 포인트를 통해 연결될 수 있다. MN 은 M2M 게이트웨이에 존재할 수 있다.

인프라스트럭쳐 노드(Infrastructure Node; IN): 하나의 CSE 가 존재해야 하고, AE 를 가질 수도 있는 노드 (An Infrastructure Node is a Node that contains one Common Services Entity and may contain Application Entities). IN 은 M2M 서버에 존재할 수 있다.

인프라스트럭쳐 노드는 MN 또는 ASN 과 Mcc 레퍼런스 포인트를 통해 다음 노드들과 통신할 수 있다. (An Infrastructure Node communicates over a Y reference point with either:

- 하나 이상의 미들 노드(들);

- 및/또는 하나 이상의 애플리케이션 서비스 노드(들)

인프라스트럭쳐 노드는 ADN 과 Mca 레퍼런스 포인트를 통해 통신할 수 있다. (An Infrastructure Node may communicate with one or more Application Dedicated Nodes over one or more respective Mca reference points.)

도 3 은 M2M 통신 시스템에서 제공되는 공통 서비스 기능을 도시한다.

M2M 통신 시스템이 제공하는 M2M 서비스 기능(즉, 공통 서비스 기능)으로는 도 3 에 도시된 것처럼 'Communication Management and Delivery Handling' , 'Data Management and Repository' , 'Device Management' , 'Discovery' , 'Group Management' , 'Addressing and Identification' , 'Location' , 'Network Service Exposure, Service Execution and Triggering' , 'Registration' , 'Security' , 'Service Charging and Accounting' , 'Session Management' , 'Subscription and Notification' 이 있다.

아래는 각 기능의 간략한 소개이다.

Communication Management and Delivery Handling (CMDH): 타 CSE 들, AE 들, NSE 들과의 통신을 제공하고 어떻게 메시지를 전달할 지의 역할을 수행한다.

Data Management and Repository (DMR): M2M 애플리케이션이 데이터를 교환, 공유할 수 있도록 하는 역할을 수행한다.

Device Management (DMG): M2M 디바이스/게이트웨이를 관리하기 위한 역할을 수행한다. 세부 기능을 살펴보면, 애플리케이션 설치 및 세팅, 설정값 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 토폴로지(Topology) 관리 등이 있다.

Discovery (DIS): 조건에 기반한 리소스 및 정보를 찾을 수 있도록 하는 역할을 수행한다.

Group Management (GMG): 리소스, M2M 디바이스, 또는 게이트웨이를 묶어 그룹을 생성할 수 있는데, 그룹과 관련된 요청을 처리하는 역할을 수행한다.

Addressing and Identification (AID): 물리 또는 논리 리소스를 식별 및 어드레싱(addressing)하는 역할을 수행한다.

Location (LOC): M2M 애플리케이션들이 M2M 디바이스 또는 게이트웨이의 위치 정보를 획득하도록 하는 역할을 수행한다.

Network Service Exposure, Service Execution and Triggering (NSE): 언더라잉 네트워크의 통신을 가능하게 하고, 언더라잉 네트워크가 제공하는 기능을 사용할 수 있도록 한다.

Registration (REG): M2M 애플리케이션 또는 다른 CSE 가 특정 CSE 에 등록을 처리하는 역할을 수행한다. 등록은 특정 CSE 의 M2M 서비스 기능을 사용하기 위해 수행된다.

Security (SEC): 보안 키와 같은 민감한 데이터 핸들링, 보안 관계(Association) 설립, 인증(Authentication), 인가(Authorization), 식별(Identity) 보호 등의 역할을 수행한다.

Service Charging and Accounting (SCA): CSE 에 요금 부가 기능을 제공하는 역할을 수행한다.

Session Management (SM): 단대단(end-to-end) 통신을 위한 M2M 세션을 관리하는 역할을 수행한다.

Subscription and Notification (SUB): 특정 리소스에 대한 변경을 구독(Subscription)하면 해당 리소스가 변경되면 이를 알리는 역할을 수행한다.

이러한 M2M 공통 서비스 기능은 CSE 를 통해 제공되며, AE(혹은, M2M 애플리케이션들)이 Mca 레퍼런스 포인트를 통해, 또는 타 CSE 가 Mcc 레퍼런스 포인트를 통해 해당 공통 서비스 기능들을 이용할 수 있다. 또 이러한 M2M 공통 서비스 기능은 언더라잉 네트워크(Underlying Network)(또는 언더라잉 네트워크 엔티티(Underlying Network Service Entity; NSE), 예: 3GPP, 3GPP2, WiFi, Bluetooth)와 연동하여 동작할 수 있다.

모든 디바이스/게이트웨이/인프라스트럭쳐가 상위 기능을 다 가지는 것은 아니다. 해당 기능들 중 필수 기능들과 선택 기능들 몇몇을 가질 수 있다.

M2M 통신 시스템에서 리소스는 M2M 통신 시스템에서 정보를 구성 및 표현하기 위한 것으로 URI 로 식별될 수 있는 모든 것을 의미한다. 상기 리소스는 일반적인 리소스, 가상 리소스 및 어나운스된 리소스(announced resource)로 분류할 수 있다. 각 리소스에 대한 정의는 다음과 같다.

가상 리소스: 가상 리소스는 특정 프로세싱을 트리거하거나 그리고/또는 결과를 리트리브(retrieve)하는데 사용되나, CSE 에 영구적으로 존재하지 않는다.

어나운스된 리소스: 어나운스된 리소스는 어나운스된(또는 통지된) 원본 리소스에 연결된 원격 CSE 에 있는 리소스이다. 어나운스된 리소스는 원본 리소스의 특징 중 일부를 유지한다. 리소스 어나운스먼트는 리소스 탐색 또는 발견(discovery)를 원활하게 한다. 원격 CSE 에 있는 어나운스된 리소스는 상기 원격 CSE 에서 원본 리소스의 자식으로서 존재하지 않거나 원본 리소스의 어나운스된 자식이 아닌 자식 리소스들을 생성하기 위해 사용된다.

일반 리소스: "가상" 또는 "어나운스된" 중 하나로 명시되지 않으면, 해당 리소스는 일반 리소스이다.

도 4 는 M2M 애플리케이션 서비스 노드와 M2M 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.

M2M 통신 시스템은 다양한 리소스(또는 자원)를 정의하는데, 이 리소스를 조작해서, 애플리케이션을 등록하고, 센서 값을 읽어 오는 등의 M2M 서비스를 수행할 수 있다. 상기 리소스는 하나의 트리 구조로 구성이 되며, CSE 과 논리적으로 연결 또는 CSE 에 저장되어 M2M 디바이스, M2M 게이트웨이, 네트워크 도메인 등에 저장될 수 있다. 이러한 측면에서, CSE 는 리소스를 관리하는 엔티티로 지칭될 수 있다. 상기 리소스는 ＜cseBase＞를 트리 루트로 가지며, 대표적인 리소스는 아래와 같다.

＜cseBase＞ 리소스: 트리로 구성된 M2M 리소스의 루트 리소스이며, 다른 모든 리소스를 포함한다.

＜remoteCSE＞ 리소스: ＜cseBase＞ 하위에 존재하는 리소스로써 해당 CSE 에 등록(연결)된 타 CSE 의 정보가 포함된다.

＜AE＞ 리소스: ＜cseBase＞ 나 ＜remoteCSE＞ 리소스 하위에 존재하는 리소스로써, ＜cseBase＞ 의 하위에 존재할 경우 해당 CSE 에 등록(연결)된 애플리케이션들의 정보가 저장되며, ＜remoteCSE＞ 하위에 존재할 경우 타 CSE(CSE 이름을 가진)에 등록된 애플리케이션들의 정보가 저장된다.

＜accessControlPolicy＞ 리소스: 특정 리소스에 대한 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여, 인증(authorization)이 이루어지게 된다.

＜container＞ 리소스: CSE 별, 또는 AE 마다 데이터를 저장하는 리소스이다.

＜group＞ 리소스: 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공하는 리소스이다.

＜subscription＞ 리소스: 리소스의 값 등의 상태가 변경되는 것을 통지(notification)을 통해 알려주는 기능을 수행하는 리소스이다.

도 5 는 M2M 애플리케이션 서비스 노드(예컨대, M2M 디바이스)와 M2M 인프라스트럭쳐 노드에 존재하는 리소스 구조를 도시한다.

예를 들어, M2M 인프라스트럭쳐 노드에 등록된 AE(application2)가 M2M 디바이스의 센서 값을 읽어오는 방법에 대해 설명한다. 상기 센서는 보통 물리적인 장치를 가리키며, M2M 디바이스 상에 존재하는 AE(application1)은 이 센서에서 값을 읽어 자신이 등록한 CSE(CSE1)에 container 리소스 형태로 읽은 값을 저장한다. 해당 M2M 디바이스 상에 존재하는 AE 는 이를 위해 M2M 디바이스에 존재하는 CSE 에 먼저 등록되어야 하며, 등록이 완료되면, 도 5 에서와 같이 cseBaseCSE1/application1 리소스의 형태로 등록된 M2M 애플리케이션 관련 정보가 저장된다.

cseBaseCSE1/application1 리소스 하위의 container 리소스에 센서 값이 M2M 디바이스상에 존재하는 AE 에 의해 저장되면, 인프라스트럭쳐 노드에 등록된 AE 가 해당 값에 접근이 가능할 수 있다. 접근이 가능하게 하기 위해서는 상기 인프라스트럭쳐 노드에 등록된 AE 도 역시 상기 인프라스트럭쳐 노드의 CSE(CSE2)에 등록이 되어있어야 하며, 이는 application1 가 CSE1 에 등록하는 방법과 같이 cseBaseCSE2/application2 리소스에 application2 에 대한 정보를 저장함으로써 이루어진다. 또, application1 는 application2 와 직접 통신하는 것이 아니라 중간의 CSE1 과 CSE2 을 통해 통신하게 되는데, 이를 위해 먼저 CSE1 는 CSE2 에 등록되어 있어야 한다. CSE1 이 CSE2 에 등록되게 되면, cseBaseCSE2 리소스 하위에 CSE1 관련 정보(예컨대, Link)가 ＜remoteCSE＞ 리소스 형태로 저장된다. 즉, ＜remoteCSE＞는 등록된 CSE 에 대한 CSE 타입, 접근 주소(IP 주소 등), CSE ID, reachability 정보 등을 제공해 준다.

한편, 리소스 탐색(resource discovery)이란 원격의 CSE 에 있는 리소소를 탐색하는 과정을 말한다. 리소스 탐색은 리트리브(RETRIEVE) 요청을 통해 이루어지며 리소스 탐색을 위해 리트리브 요청은 아래의 내용을 포함한다.

＜startURI＞: URI 을 지시하며, 이 URI 는 리소스 탐색을 행할 리소스의 범위를 제한하는데 사용될 수 있다. 만약 ＜startURI＞가 리소스의 루트인 ＜cseBase＞를 가리킨다면, 본 리트리브 요청을 받은 수신자의 전 리소스를 대상으로 리소스 탐색을 수행하게 된다. 수신자는 ＜startURI＞가 지칭하는 리소스와 그 하위 리소스를 대상으로만 리소스 탐색을 수행하게 된다.

filterCriteria: 이 정보에는 탐색할 리소스와 관련된 정보가 기술된다. 수신자는 ＜startURI＞가 정의한 리소스 탐색 범위 안의 리소스 중에서 filterCriteria 를 만족시키는 리소스만을 검색하여 본 요청의 요청자에게 전송하게 된다.

도 4 또는 도 5 에 도시된 것처럼 M2M 시스템에서는 리소스가 트리 구조로서 표현될 수 있으며, 루트 리소스의 타입은 ＜CSEBase＞로 표현된다. 따라서, ＜CSEBase＞ 리소스 타입은 공통 서비스 엔티티(CSE)가 있는 경우에는 반드시 존재해야 한다.

도 6 은 Mca 및 Mcc 레퍼런스 포인트들 상의 일반적인 통신 플로우를 도시한다. M2M 시스템의 동작은 데이터 교환을 기반으로 수행된다. 예를 들어, 제 1 장치가 제 2 장치의 특정 동작을 멈추기 위한 명령을 전송 또는 수행하기 위해서 상기 제 1 장치는 해당 명령을 데이터 형태로 상기 제 2 장치에 전달해야한다. M2M 시스템에서는 어플리케이션(또는 CSE)와 CSE 간의 연결에서 요청 및 응답 메시지들로 데이터를 교환할 수 있다.

요청(Request) 메시지에는 다음과 같은 정보가 포함된다.

·Operation: 실행될 동작의 형태 (Create/Retrieve/Update/Delete/Notify 중 택일)

·To: 요청을 수신할 엔티티의 ID(즉, 수신자의 ID)

·From: 요청을 생성한 발신자의 ID

·Request Identifier: 요청 메시지의 ID(요청 메시지를 구분하기 위해 사용되는 ID)

·Content: 전달되는 리소스의 내용

응답(Response) 메시지에는 다음과 같은 정보가 포함된다. 우선 해당 요청 메시지가 성공적으로 처리된 경우에는, 상기 응답 메시지는

·To: 요청을 생성한 발신자의 ID

·From: 요청을 수신한 수신자의 ID

·Request Identifier: 요청 메시지의 ID(요청 메시지를 구분하기 위해 사용되는 ID)

·Result content: 요청의 처리 결과 (예를 들어, Okay, Okay and Done, Okay and in progress)

·Content: 전달되는 리소스의 내용 (결과값(rs)만 전달될 수 있음)

를 포함하고, 요청 메시지의 처리가 실패한 경우 상기 응답 메시지는

·To: 요청을 생성한 발신자의 ID

·From: 요청을 수신한 수신자의 ID

·Request Identifier: 요청 메시지의 ID(요청 메시지를 구분하기 위해 사용되는 ID)

·rs: 요청의 처리 결과 (예를 들어, Not Okay)

를 포함할 수 있다.

한편, 다음의 표와 같은 다양한 리소스 타입이 존재한다.

[표 1]

각 리소스 타입은 해당 리소스 타입의 부모 리소스 타입(Parent Resource Type) 아래 위치할 수 있으며, 자식 리소스 타입(Child Resource Type)을 가질 수도 있다. 또한 각각의 리소스 타입은 속성(Attribute)들을 가지며, 속성에 실제 값들이 저장된다.

다음으로 아래 표 2 은 ＜container＞ 리소스 타입의 속성(Attribute)들을 정의한 것이다. 실제 값들이 저장되는 속성은 Multiplicity 를 통하여 반드시 설정( '1' )되거나, 선택적으로 설정( '0..1' )될 수 있다. 또한 해당 속성들은 생성시 특성에 따라 RO(Read Only), RW(Read and Write), WO(Write Only)와 같이 설정된다. 한편, 표 1 에 나타낸 것처럼, ＜container＞ 리소스는 자식 리소스로서 ＜container＞, ＜contentInstance＞ 및 ＜subscription＞를 가질 수 있다.

[표 2]

엔티티 등록(Entity Registration)

M2M 엔티티는 필드 도메인에 있든 인프라스트럭쳐 도메인에 있든 자기 주변의 엔티티와 등록(Registration) 과정을 수행하여 시스템/서비스를 이용할 준비를 마친다. 이러한 등록은 등록대상자(Registree)의 요청에 의해 동작이 수행되며 결과로써 일반적으로 등록대상자의 정보를 등록담당자(Registrar)에 저장한다.

이러한 등록 과정이 끝난 후 비로서 oneM2M 엔티티는 도 3 과 같이 CSE 가 제공하는 공통 기능들을 이용해서 M2M 서비스를 이용할 수 있다.

oneM2M 엔티티에는 AE 와 CSE 가 있고, 이에 따라 상기 등록 과정은 AE 등록과 CSE 등록으로 나눌 수 있으며, 이 때 AE 와 CSE 는 모두 등록대상자를 의미하고 등록담당자는 CSE 이다. CSE 등록의 경우 추가적으로 등록담당자 CSE 의 정보를 등록대상자 CSE 에도 저장한다.

도 7 은 AE 등록 과정과 CSE 등록 과정을 도시한다. 도 7 의 (a)은 AE 등록 과정을 도시하며, 등록하고자 하는 AE1 은 등록담당자인 CSE1 에게 ＜AE＞ 생성 요청을 하며(S71-1), 이에 CSE1 은 상기 AE1 의 정보를 이용하여 ＜AE＞ 자원을 생성할 수 있다(S72-2). 그리고나서, CSE1 은 상기 등록 과정에 대한 결과를 포함한 응답을 AE1 에게 전송할 수 있다(S73-2).

도 7 의 (b)는 CSE 등록 과정을 도시한다. 도 7 의 (b)는 등록하고자 하는 주체가 CSE1 이고 등록담당자가 CSE2 인 것과 CSE2 가 CSE1 의 등록 요청에 대한 결과를 전송(S73-2)하면, CSE1 은 CSE2 의 정보를 이용하여 ＜remoteCSE＞ 자원을 생성(S74-2)하는 것만 제외하고는 도 7 의 (a)와 동일하다.

M2M 서비스 인터페이스

기술적으로 '서비스' 라는 개념은 시스템에서 파일에 접근하는 것과 같은 비즈니스 작업 또는 로그인 및 권한 체크와 같은 일반적인 기능(Function)을 수행하는 소프트웨어적 기능을 의미한다. 추가적으로 해당 서비스를 어떻게 연결(interface)되는지가 중요하다. 본 명세서에서 다루고자 하는 두 가지 기술(oneM2M 및 AllJoyn)은 서로 다른 인터페이스로 연결된다. 본 명세서에선 상기 구체적인 두 가지 기술에 대해 설명하지만, 본 명세서에서 제안하고자 하는 것은 상기 구체적인 두 가지 기술에 제약되지 않고 일반적으로 이종의 시스템 또는 기술 등에 적용될 수 있을 것이다.

웹을 통한 리소스 API(application program interface)

oneM2M 시스템에서 채택한 서비스 연결(service interface) 기술은 웹(web) 상에서 제공되는 리소스 API 이다. 기본적으로, 리소스는 앞서 언급한 "리소스" 또는 "자원" 이라는 용어와 동일한 의미를 갖는다. 리소스는 URI 형태로 모든 자원을 정의하고, HTTP/CoAP 등과 같이 기존에 웹에서 사용되는 표준 기술을 기반으로 서비스를 호출하는 것을 의미한다.

도 8 은 리소스 API 와 관련된 동작을 도시한다. 리소스로 연결된 서비스 인터페이스 시스템에서, 클라이언트(요청자)는 서버에 존재하는 호출하고자 하는 URI 에 미디어 타입(예컨대, XML 또는 JSON) 메시지를 추가한 후, HTTP 동작(GET, PUT, POST, DELETE 등) 중에서 하나의 동작을 추가하여 자신이 받고자하는 서비스를 요청할 수 있다. 해당 요청을 수신한 서버는 해당 서비스를 호출하여 상기 요청에 대한 결과를 상기 클라이언트가 인식할 수 있는 미디어 타입으로 변환하여 수행 상태 코드를 포함하여 응답할 수 있다.

이러한 리소스 API 는 웹에서 널리 사용되는 HTTP 프로토콜과 표준화된 미디어 타입을 활용하여 서비스를 호출하고 응답한다는 측면에서 서비스 인터페이스를 낮은 비용으로 구현할 수 있다는 장점과, 추가적으로 자원들이 모두 웹 상에서 고유의 URI 를 갖는다는 측면에서 웹의 성공과 같이 파급력을 가질 수 있는 장점을 가지고 있어 최근 M2M 서비스 플랫폼 기반 기술로 이용되고 있다.

RPC(remote procedure call) API

전통적으로 RPC 는 분산 처리 환경에서 요청자의 외부에 존재하는 서비스를 호출하는 가장 직관적인 방법이다. 이는 AllJoyn 시스템에서 채택한 서비스 연결 기술이다.

도 9 는 RPC API 와 관련된 동작을 도시한다. 클라이언트는 서버가 제공하는 서비스를 사용하기 위해 해당 서비스에 정의된 함수 중에 필요한 함수를 호출 호출(function call)하는 동작과 같이 함수의 이름(function name)과 인자 값(function arguments)을 포함하여, 클라이언트가 호출하고자 하는 서비스(즉, 기능)를 호출하고, 서비스를 구현하고 있는 서버는 요청받은 서비스를 동작하여 나온 결과를 요청자에게 제공할 수 있다.

RPC API 의 특징은 기본적으로 리소스 API 와 다르게 특정한 호출 메시지의 형태가 표준화되거나 규격화되지 않았다는 점이다. 시스템 내에서 동일한 프로토콜 메시지를 사용하면 이를 기반으로 시스템 동작이 가능하다.

AllJoyn 시스템의 구성

AllJoyn 시스템은 서로 다른 성능의 단말에 분산된 M2M 애플리케이션 간 연결성 제공을 통해 M2M 서비스를 제공하기 위한 시스템이다. 이하, AllJoyn 시스템 또는 프레임워크가 해당 연결성을 위해 제공하는 기능을 설명하도록 한다.

도 10 은 AllJoyn 프레임워크의 구성도를 도시한다.

AllJoyn 시스템에서 제공하는 부분은 도 10 에 도시된 것 중에 "Base Service Frameworks" 와 "AllJoyn Core Framework" 이다. 상세하게는, AllJoyn Core Framework 는 시스템에서 제공하는 주요 기능을 명시하고, 상단의 Base Service Frameworks 는 하위 AllJoyn Core Framework 를 기반으로 M2M 애플리케이션에서 공통적으로 필요한 필수 M2M 애플리케이션의 최소화된 기능을 제공한다고 볼 수 있다. oneM2M 명시된 내용을 기반으로 본다고 하면, 시스템에서 제공하는 서비스는 기본적으로 AllJoyn Core Frameworkrk 제공하는 서비스와 동일하다고 불 수 있고, 해당 서비스를 일부 조합하여 M2M 애플리케이션이 쓸 수 있는 기능의 세트로 구성한 것을 Base Service Frameworks 라고 볼 수 있겠다.

AllJoyn 시스템에서 제공하는 AllJoyn Core Frameworks 는 다음과 같다.

1. Service Advertisement and Discovery: 해당 AllJoyn 프레임워크가 설치된 장치의 M2M 애플리케이션 기능을 타 장치에 광고(advertise)하는 기능 및 해당 광고된 내용을 인식하여, M2M 애플리케이션 간 연결을 지원하는 기능

2. Network Management: 다양한 액세스 네트워크와의 연동을 관리함. 와이파이, 블루투스와 연동하여 자동적으로 필요한 네트워크와의 연동을 지원함.

3. Security: 프레임워크에 연결된 M2M 애플리케이션 간 연결 및 메시지 전송에 대한 인증 및 보안 기능 지원

4. Connection Management: 프레임워크에 연결된 M2M 애플리케이션간 연결에 대한 세션 관리 기능 지원

AllJoyn 시스템은 oneM2M 시스템과 구성 및 목적이 유사하지만, 두 시스템 간에는 차이점이 있다. 도 11 은 두 시스템의 서비스 범위에 따른 차이점을 도시한다. 일반적으로, 와이파이 및 블루투스를 액세스 네트워크로 사용하는 AllJoyn 시스템은 서비스 영역이 상기 액세스 네트워크가 커버(cover) 가능한 지역으로 제한된다. 이는 기본적으로 AllJoyn 프레임워크가 설치된 단말이 제공하는 서비스를 우선 광고하고, 타 단말이 이를 발견(discover)하여 상호 연결된다. 여기서 광고를 하는 기능은 주로 와이파이 및 블루투스에 의해 커버가능한 지역 범위 내에서 브로트캐스팅 또는 멀티캐스팅 메시지를 전달함으로써 진행되므로, 서비스 영역은 액세스 네트워크의 커버링 지역을 벗어날 수 없다. 만약, 서비스 영역이 액세스 네트워크 커버링 지역을 벗어나면, 상기 브로드캐스팅 또는 멀티캐스팅 메시지가 인터넷 백본망(Backbone Network)으로 흘러가게 되며, 해당 메시지는 인터넷 백본망을 훼손할 수 있다. 결론적으로, AllJoyn 시스템은 능동적인 광고/발견하는 방식을 채택했고, 이는 서비스를 페어링(pairing)하는데 이점이 있다.

반면, oneM2M 시스템이 서비스를 광고하고 발견하는 방식은 AllJoyn 과 다른 방식과 다르다. oneM2M 시스템은 기본적으로 웹에서 자원을 발견하는 방식을 활용한다. 이는 간략하게 자원의 정보를 AllJoyn 시스템처럼 액세스 네트워크의 프로토콜 기술(브로드캐스팅)을 사용하여 광고하지 않고, 자원을 발견하는 동작만을 지원한다. 이는 언급했던 바와 같이 광역 구조로 된 네트워크에서 브로드캐스팅을 활용해서 특정 서비스를 광고하게 되면, 네트워크 부하를 일으키기 때문이다.

서비스 측면으로 보면, 도 11 에 도시된 병원 서비스 시스템 관리자가 AllJoyn 시스템을 적용한 댁내 혈압계를 제어하기 위해서는 병원 서비스-M2M 서버-홈 게이트웨이(Home G/W)까지 oneM2M 시스템 기반의 프로토콜을 사용하고, 홈게이트웨이에서 혈압계 까지는 AllJoyn 시스템 기반의 프로토콜을 사용해야 하며, 따라서 홈 게이트웨이가 AllJoyn 시스템과 oneM2M 시스템의 호환을 위해 상호간 프로토콜, 즉 메시지의 변환을 할 수 있어야 한다.

도 12 는 AllJoyn 과 oneM2M 시스템 연동에 따른 구조 및 정보 불일치에 따른 문제점을 도시한다.

서로 다른 서비스 연결 구조, 좀더 상세하게는 리소스 API 를 사용하는 oneM2M 시스템에서는 장치간 서비스 연결을 위해서는 리소스를 사용한다. 하지만, AllJoyn 은 RPC(Remote Procedure Call) API 를 사용하는 시스템으로써 장치간 서비스 연결을 위해서는 상기 언급한 원격 함수 호출을 사용한다. 결론적으로, 도 12 와 같이 oneM2M 노드 C(40)는 oneM2M-Enabled 장치로써, 게이트웨이(30)까지는 oneM2M 에서 정의한 프로토콜로 메시지를 전송한다. 예를 들어, 어떤 리소스에 저장된 정보를 회수(RETRIEVE)하거나, 어떤 리소스에 특정 정보를 생성(CREATE)할 수 있다. 하지만, AllJoyn 노드 A(10)와 B(20)는 기본적으로 원격에 존재하는 함수를 직접 호출하는 프로토콜을 사용하여, 리소스를 매개체로 활용하는 시스템과는 연동될 수 없다.

도 12 에서는 AllJoyn 및 oneM2M 모두를 지원하는 게이트웨이가 AllJoyn Node A 와 B 가 제공하는 서비스와 모두 연결되었지만, API 형태의 상이함으로 인하여 oneM2M 노드 C 는 어떤 서비스가 AllJoyn 네트워크에 존재하는지, 어떤 리소스를 활용해야 하는지, 어떻게 정보를 주고받고 하는지를 알 수가 없다.

앞서 설명한, oneM2M 시스템 및 AllJoyn 시스템은 일 예일뿐, 각각 리소스 API 및 RPC API 를 사용하는 다른 시스템에도 동일한 내용이 적용될 수 있다. 또한, 후술될 본 발명의 실시예들 역시 리소스 API 및 RPC API 를 사용하는 시스템 간에서 적용될 수 있다.

도 13 은 본 발명의 일 실시예에 따른 이종 시스템의 상호 호환 방식을 도시한다.

도 13 을 참조하면, 게이트웨이(200)가 두 이종 시스템(oneM2M 과 AllJoyn) 간의 호환을 담당하는 것을 확인할 수 있다. 즉, 상기 게이트웨이(200)는 리소스 API 를 제공하는 개체(MN-CSE)와 RPC API 를 제공하는 개체(AJ 라우팅 노드)를 포함하며, 상기 리소스 API 를 제공하는 개체와 RPC API 를 제공하는 개체 상호간을 연동 및 변환(translate)하는 기능을 제공하는 IPE(Interworking Proxy Entity)를 포함할 수 있다.

상기 MN-CSE 는 M2M 환경의 공통 서비스 기능의 집합의 객체화(instantiation)을 나타내며, 이러한 서비스 기능들은 Mca 및 Mcc 레퍼런스 포인트들을 통해 다른 엔티티들에게 노출된다. 상기 AJ 라우팅 노드는 P2P 광고/발견, 접속 설정, 브로드캐스팅 시그널링 및 제어/데이터 메시지 라우팅을 포함한 AllJoyn 프레임워크의 코어 기능을 제공한다. 상기 IPE 는 AllJoyn 서비스를 oneM2M 를 지원하는 엔티티에게 노출하기 위해 그리고 oneM2M 서비스를 AllJoyn 를 지원하는 엔티티에게 노출하기 위해, MN-CSE 와 AJ 라우팅 노드에 연결되어야 한다.

상기 IPE 의 AllJoyn 서비스를 oneM2M 을 지원하는 엔티티에게 노출하기 위해, AllJoyn 서비스를 나타내는 자원 구조를 제안하도록 한다. 이러한 자원 구조는 도 14 에 도시된다.

[표 3]

또한, 상기 자원 구조는 다음과 같은 자식 자원을 가질 수 있다.

[표 4]

이하, 본 명세서에서 제안되는 동작을 도면을 참조하여 설명하도록 한다.

도 15 는 RPC API 기반의 노드(예, AllJoyn 노드)가 자신의 서비스를 광고하고 이에 따라 RPC API 와 리소스 API(예, oneM2M)를 모두 지원하는 게이트웨이가 상기 RPC API 기반의 노드의 서비스에 대한 자원을 생성하는 절차를 도시한다. 이렇게 상기 게이트웨이가 자원을 생성함으로써 상기 리소스 API 기반의 노드(예, oneM2M 노드)가 상기 RPC API 기반의 노드의 서비스를 탐색할 수 있도록 한다.

AllJoyn 노드 A(1510)는 게이트웨이(1520) 또는 상기 게이트웨이의 AJ 라우팅 노드(1521)로 자신이 제공할 수 있는 서비스에 대한 광고 메시지를 전송할 수 있다(S1510). 상기 광고 메시지는 a)해당 서비스가 상기 리소스 API 기반의 네트워크 또는 엔티티들에게 공유, 노출(exposure) 또는 제공되는 건지에 대한 여부를 지시하는 지시자 및/또는 b) 상기 지시자에 의해 지시되는 서비스가 공유, 노출 또는 제공될 특정 리소스 API 기반의 엔티티의 식별자를 포함할 수 있다. 만약, 상기 식별자가 상기 광고 메시지에 포함되지 않는 경우, 상기 지시자에 의해 지시되는 서비스가 엔티티에 대한 제한없이 모든 엔티티들에게 공유, 노출 또는 제공되는 것을 의미한다.

이에, 상기 게이트웨이 또는 상기 AJ 라우팅 노드는 상기 AllJoyn 노드와 세션을 설정할 수 있다(S1520). 이를 통해, 상기 게이트웨이 또는 상기 AJ 라우팅 노드는 상기 AllJoyn 노드 A 가 제공하는 서비스에 대한 정보를 보유할 수 있다.

상기 게이트웨이 또는 상기 AJ 라우팅 노드는 상기 광고 메시지를 확인하여 리소스 API 기반의 네트워크 또는 엔티티들에게 공유, 노출 또는 제공될 서비스가 있는지를 확인할 수 있다(S1530). 공유, 노출 또는 제공될 서비스가 없다면, 도 15 에 도시된 절차는 종료한다.

공유, 노출 또는 제공될 서비스가 있으면, 상기 AJ 라우팅 노드는 MN-AE 또는 IPE(1522)와 공유, 노출 또는 제공되어야 하는 서비스에 대한 정보를 교환할 수 있다(S1540). 이러한 정보 교환은 일반 데이터 전달의 형태를 따르는데, 일반적으로 서비스에 대한 정보, 그리고 서비스에 대한 정보의 접근 및 보안에 대한 정보가 교환될 수 있다.

이에, 상기 MN-AE 또는 상기 IPE 는 윗 단계에서 교환된 정보를 자원으로 생성할 수 있다(S1550). 이 단계에서 생성되는 자원은 위에서 설명한 표 3 및 표 4 에 해당한다. 상기 자원은 MN-CSE(1523)에 생성되며, 상기 MN-CSE 는 상기 MN-AE 또는 상기 IPE 로 자원 생성에 대한 응답을 전송할 수 있다(S1560). 상기 S1550 및 S1560 은 앞서 도 6 과 관련하여 설명한 요청-응답 프로시져에 따라 수행된다.

도 16 은 도 15 에서 설명된 절차에 따라 RPC API 기반의 노드의 서비스가 리소스 API 기반의 엔티티로 공유, 노출 또는 제공되고 난 후, 즉 상기 서비스와 관련된 자원이 생성되고 난 후, 상기 리소스 API 기반의 엔티티가 해당 서비스를 호출하는 동작을 예시한다.

리소스 API 기반의 엔티티(예, oneM2M 노드 C(1630))가 등록되어있는 외부의 RPC API 기반의 서비스를 호출할 필요가 있는지 여부를 체크할 수 있다(S1611). 해당 동작은 상기 리소스 API 기반의 엔티티에 연결된 애플리케이션에서 사용자의 요청에 의해 결정될 수 있다. 여기서, 상기 oneM2M 노드 C 는 앞서 언급한 ADN, MN 또는 IN 일 수 있다. 만약, 상기 RPC API 기반의 서비스가 호출될 필요가 있다면, 상기 리소스 API 기반의 엔티티는 MN-CSE(1623)에 생성되어 있는 상기 RPC API 기반의 서비스에 대한 자원(예, ＜allJoynService＞)을 회수(retrieve)를 요청할 수 있다(S1612).

이에, 상기 MN-CSE 는 접근 제어 정책(Access Control Policy)에 따라 상기 자원에 저장된 속성(attribute)을 상기 리소스 API 기반의 엔티티로 응답할 수 있다(S1613). 해당 동작에서는, oneM2M 노드 C 가 연결된 RPC API 기반의 서비스의 구성을 알 수 있다. 예를 들어, serviceStatus 및 interfaceInfo 를 통해 RPC API 기반의 서비스의 동작 여부와 해당 서비스를 구성하는 함수(즉, method) 및 변수(즉, property)들을 확인할 수 있다. 추가로, 상기 MN-CSE 는 사전에 설정된 접근 제어 정책에 따라 상기 oneM2M 노드 C 의 요청에 대한 응답 또는 거절이 될 수 있다.

상기 리소스 API 기반의 엔티티는 호출하고자 하는 RPC 기반의 서비스에 정의된 함수(즉, method)를 상기 MN-CSE 의 ＜allJoynSerivce＞ 의 자식 자원인 ＜methods＞ 자원에 신규 ＜method＞ 자식 자원의 생성 요청을 전송한다(S1614). 해당 생성 과정에서는 우선 ＜method＞ 자원은 필수 인자 값(function arguments)를 속성으로 포함하고, 추가적으로 상기 리소스 API 기반의 엔티티가 명시적으로 생성된 ＜method＞ 자원에 ＜subscription＞ 자원을 생성하여 자원 생성을 MN-AE 또는 IPE(1622)에게 통보하거나, 또는 MN-CSE 가 해당 자동적으로 ＜method＞ 자원 생성시 해당 자원 생성을 MN-AE 또는 IPE(1622)에 통보할 수 있다. 또한, 상기 리소스 API 기반의 엔티티는 상기 MN-CSE 의 ＜allJoynSerivce＞ 의 자식 자원인 ＜properties＞에 대해 ＜subscription＞ 자원을 생성할 수 있다.

상기 MN-CSE 는 상기 리소스 API 기반의 엔티티의 상기 자원 생성과 관련된 접근 권한을 체크할 수 있다(S1615). 이러한 접근 권한에 대한 설명은 별도의 도면(도 17)을 참조하여 후술하도록 한다.

상기 자원에 대한 접근이 허용되지 않으면(즉, 상기 oneM2M 노드 C 가 상기 자원 생성과 관련된 접근 권한이 없으면), 도 16 과 관련된 절차는 종료한다.

상기 자원에 대한 접근이 허용되면(즉, 상기 oneM2M 노드 C 가 상기 자원 생성과 관련된 접근 권한이 있으면), 상기 MN-CSE 는 상기 자식 자원을 생성할 수 있다(S1616). 그리고나서, 상기 MN-CSE 는 상기 MN-AE 또는 상기 IPE 로 상기 생성된 자식 자원에 대한 정보를 통보할 수 있다(S1617).

상기 MN-AE 또는 상기 IPE 는 상기 생성된 자식 자원이 지시하는 정보(즉, 호출하고자 하는 서비스의 기능)를 AJ 라우팅 노드(1621)와 교환할 수 있다(S1618). 상기 정보는 상기 생성된 자식 자원에 대한 정보, 예컨대 method 와 arguments 를 포함할 수 있다.

상기 AJ 라우팅 노드는 상기 생성된 자식 자원에 대한 정보, 즉 상기 method(서비스)를 RPC 기반의 노드(예, AllJoyn 노드 A(1610))에 요청할 수 있다(S1619). 이에, 상기 RPC 기반의 노드는 해당 method 를 수행하고(S1620), 그에 대한 결과를 상기 AJ 라우팅 노드에 전달할 수 있다(S1621).

상기 method 수행의 결과로 인해 properties 와 같은 정보가 변경될 수 있다. 상기 AJ 라우팅 노드는 상기 변경이 있는지 여부를 체크할 수 있다(S1622). 상기 AJ 라우팅 노드는 상기 MN-AE 또는 상기 IPE 와 상기 method 수행의 결과 또는 상기 변경된 정보를 교환할 수 있다(S1623).

이에, 상기 MN-AE 또는 상기 IPE 는 상기 변경된 정보 또는 상기 method 수행의 결과를 상기 MN-CSE 에 있는 ＜allJoynSerivce＞ 자원 하위의 ＜properties＞ 자원에 업데이트할 수 있다(S1624).

또한, 상기 ＜properties＞에 대해 ＜subscription＞ 자원이 생성된 경우, 해당 자원에 대한 통지가 구독되었기 때문에, 해당 변경에 대해 상기 MN-CSE 는 상기 리소스 API 기반의 노드로 통보할 수 있다(S1625).

이하, 자원 API 기반 또는 RPC API 기반 시스템 또는 서비스의 접근 제한 또는 제어 방식에 대해 설명하도록 한다.

자원 API 기반 시스템의 일례로써 oneM2M 시스템을 예로 들어 접근 제한 또는 제어를 설명하도록 한다.

oneM2M 시스템에서는 일반적으로 자원에 대한 접근 제어 정책(access control policy)이 권한(privileges)으로 표현된다. 그리고, 권한은 특정 접근 모드로 접근이 가능한 엔티티로 표현될 수 있다. 상세하게는, 권한의 세트는 권한의 그룹으로 표현될 수 있고 이는 별개 권한의 합으로 표현될 수 있다.

특정 접근 모드는 일반적으로 아래의 표와 같이 oneM2M 에서 명시한 동작에 대한 표현으로 대체된다.

[표 5]

자기 권한(SelfPrivilege)이라는 개념은 추가적으로 상기 명시된 권한을 변경할 수 있는 권한을 의미한다.

자원에 대한 접근 제어 정책에 명시된 권한은 위치나 시간의 범위, IP 어드레스에 따라 변경되는 값일 수 있다. 상기 접근 제어 정책이 자원과 연결되는 방식은 우선 자원에 접근 제어 정보를 포함하는 접근 제어 정책 자원(＜accessControlPolicy＞)을 생성한 후, 해당 접근 제어 정책 자원에 대한 링크 정보(예, URI)를 해당 자원의 속성(attribute)인 accessControlPolicyID 에 포함시키는 것이다.

다음의 표는 ＜accessControlPolicy＞ 자원의 속성을 나타낸다.

[표 6]

상기 자원은 공통 속성 값을 포함하고, privileges 와 selfPrivileges 를 더 포함한다.

아울러, privileges 와 selfPrivilegessms 다음과 같은 정보를 포함한다.

[표 7]

상기 originatorPrivileges 는 아래의 표와 같은 정보를 포함한다.

[표 8]

표 7 의 contexts 는다음의 표와 같은 정보를 포함한다.

[표 9]

표 7 의 operationFlags 는 위의 표 5 에 열거된 동작에 대한 표현을 명시할 수 있다.

앞서 설명한 자원 접근 제어 정책 자원(＜accessControlPolicy＞)에 기반한 접근 제어 절차가 도 17 에 도시된다.

발신자(1710)가 호스팅 CSE(즉, 접근하고자 하는 자원을 가지고 있는 엔티티, 1720)에 객체화(Instantiated) 또는 저장된 특정 자원의 접근/생성 요청을 전송할 수 있다(S1710). 상기 호스팅 CSE 은 해당 요청을 수신한 후, 우선적으로 상기 특정 자원의 접근 권한을 파악하기 위해서 상기 특정 자원에 연결된 ＜accessControlPolicy＞ 자원에 명시된 속성 'privileges' 를 파악할 수 있다(S1720). 좀더 상세하게는, ' privileges ' 속성에 명시된, 'originatorPrivileges' , 'contexts' , 'operationFlags' 를 읽어서 해당 요청이 명시된 값에 부합하는지 파악한다.

만약, 상기 요청이 상기 언급한 'privileges' 에 부합하지 않는 경우, 상기 호스팅 CSE 는 요청 거절 메시지를 상기 발신자에게 전송할 수 있다(S1730). 만약, 상기 요청이 상기 언급한 'privileges' 에 부합하는 경우, 상기 발신자에 의한 상기 특정 자원에 대한 접근이 허락된 경우이므로, 상기 호스팅 CSE 는 상기 요청을 수행할 수 있다(S1740-1). 그리고나서, 상기 호스팅 CSE 는 상기 수행의 결과를 상기 발신자로 전송할 수 있다(S1740-2).

위에서 자원 API 기반 시스템의 접근 제한에 대해 설명하였다. 그와 달리, RPC API 기반 시스템의 접근 제한은 좀더 상세한 정보들에 대하여 정의되어야 한다. 예를 들어, 어떤 객체가 어떤 서비스에서 제안된 기능을 상세하게 사용할 수 있는지에 대한 것이 정의되어야 한다.

해당 제안하는 발명에서는 ＜accessControlPolicy＞가 ＜allJoynServices＞ 자원과 연결된 경우에 추가적으로 'priviliege' 에서는 InterfacePrivileges 가 상세하게 기술 될 수 있다.

- interfacePrivileges: ＜allJoynServices＞ 자원 타입이 연결된 경우, 해당 AllJoyn 서비스(인터페이스)에 명시( 'interfaceInfo' 속성)된 methods, signals 중에서 어떤 기능을 쓸 수 있는지를 명시한다.

예를 들어, 'interfaceInfo' 속성에서 해당 AllJoyn 서비스에서 제공하는 method 가 method_a, method_b, method_c 등록되어있다고 가정하면, 해당 interfacePrivileges 에 어떤 발신자(즉, 요청자)가 정의된 method 중에서 어떤 method 를 사용할 수 있는지 명시한다.

예를 들어, oneM2M 노드 A 가 method_a 를 사용할 수 있다고 하면, ＜method_a＞를 생성하는 CREATE 명령에 대해 허가를 줄 수 있다.

도 18 은 본 발명의 실시예(들)을 수행하도록 구성된 장치의 블록도를 도시한다. 전송장치(10) 및 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작적으로 연결되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.

메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 임시 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다.

프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.

본 발명의 실시예들에 있어서, 애플리케이션 (엔티티) 또는 리소스 관린 엔티티 등은 각각 그들이 설치되어 있거나 탑재되어 있는 장치들, 즉 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.

이와 같은, 수신장치 또는 전송장치로 애플리케이션 (엔티티) 또는 리소스 관린 엔티티 등의 구체적인 구성은, 도면과 관련하여 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 둘 이상의 실시예가 동시에 적용되도록 구현될 수 있다.

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

본 발명은 무선 이동 통신 시스템의 단말기, 기지국, 서버 또는 기타 다른 장비에 사용될 수 있다.

Claims (18)

1. 무선 통신 시스템에서 이종 시스템간의 요청 메시지를 처리하기 위한 방법으로서, 상기 방법은 게이트웨이 장치에 의해 수행되며,
   제 1 시스템에 속한 제 1 노드로부터 제 1 노드의 서비스에 대한 광고 메시지를 수신하는 단계;
   상기 광고 메시지가 상기 서비스가 제 2 시스템과 공유되는지에 대한 지시자를 포함하면, 상기 공유되는 서비스에 대응하는 자원 및 상기 공유되는 서비스에 대응하는 자원에 대한 접근 제어를 위한 자원을 생성하는 단계;
   상기 제 2 시스템의 제 2 노드로부터 상기 생성된 자원에 대한 정보의 회수(retrieve)를 위한 요청 메시지를 수신하는 단계;
   상기 제 2 노드가 상기 회수에 대한 접근 권한이 있으면, 상기 생성된 자원에 대한 정보를 상기 제 2 노드로 전송하는 단계;
   상기 제 2 노드로부터 상기 생성된 자원의 정보에서 선택된 호출하고자 하는 서비스에 대응하는 자원을, 상기 생성된 자원의 자식 자원으로 생성하기 위한 요청 메시지를 수신하는 단계; 및
   상기 자식 자원의 생성에 대한 접근 권한을 체크하는 단계를 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
2. 제 1 항에 있어서,
   상기 광고 메시지는 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 더 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
3. 제 1 항에 있어서,
   상기 광고 메시지가 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 포함하지 않으면, 제 2 시스템의 모든 노드에게 상기 서비스가 연동되는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
4. 제 1 항에 있어서,
   상기 제 2 노드가 상기 자식 자원의 생성에 대한 접근 권한이 있으면, 상기 자식 자원을 생성하는 단계를 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
5. 제 4 항에 있어서,
   상기 자식 자원이 생성되면, 상기 자식 자원에 대응하는 서비스의 수행을 상기 제 1 노드로 호출하는 단계를 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
6. 제 5 항에 있어서, 상기 호출한 서비스의 처리 결과를 상기 제 1 노드로부터 수신하고, 상기 결과를 상기 생성된 자원의 특정 자식 자원에 업데이트하는 단계를 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
7. 제 1 항에 있어서, 상기 선택된 호출하고자 하는 서비스의 처리 결과를 통지받기 위한 자원을 생성하기 위한 요청을 수신하는 단계를 더 포함하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
8. 제 1 항에 있어서,
   상기 제 1 시스템은 제 1 인터페이스 타입을 사용하고, 상기 제 2 시스템은 제 2 인터페이스 타입을 사용하는 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
9. 제 1 항에 있어서,
   상기 제 1 인터페이스 타입은 RPC(remote procedure call) API(application program interface)이고, 상기 제 2 인터페이스 타입은 리소스(resource) API 인 것을 특징으로 하는, 이종 시스템간 요청 메시지 처리 방법.
10. 무선 통신 시스템에서 요청 메시지를 처리하도록 구성된 M2M 장치에 있어서,
    무선 주파수(radio frequency, RF) 유닛; 및
    상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되,
    상기 프로세서는:
    제 1 시스템에 속한 제 1 노드로부터 제 1 노드의 서비스에 대한 광고 메시지를 수신하고,
    상기 광고 메시지가 상기 서비스가 제 2 시스템과 공유되는지에 대한 지시자를 포함하면, 상기 공유되는 서비스에 대응하는 자원 및 상기 공유되는 서비스에 대응하는 자원에 대한 접근 제어를 위한 자원을 생성하고,
    상기 제 2 시스템의 제 2 노드로부터 상기 생성된 자원에 대한 정보의 회수(retrieve)를 위한 요청 메시지를 수신하고,
    상기 제 2 노드가 상기 회수에 대한 접근 권한이 있으면, 상기 생성된 자원에 대한 정보를 상기 제 2 노드로 전송하고,
    상기 제 2 노드로부터 상기 생성된 자원의 정보에서 선택된 호출하고자 하는 서비스에 대응하는 자원을, 상기 생성된 자원의 자식 자원으로 생성하기 위한 요청 메시지를 수신하고,
    상기 자식 자원의 생성에 대한 접근 권한을 체크하도록 구성되는, M2M 장치.
11. 제 10 항에 있어서,
    상기 광고 메시지는 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 더 포함하는 것을 특징으로 하는, M2M 장치.
12. 제 10 항에 있어서,
    상기 광고 메시지가 상기 공유되는 서비스가 공유되는 제 2 시스템의 노드의 식별자를 포함하지 않으면, 제 2 시스템의 모든 노드에게 상기 서비스가 연동되는 것을 특징으로 하는, M2M 장치.
13. 제 10 항에 있어서,
    상기 제 2 노드가 상기 자식 자원의 생성에 대한 접근 권한이 있으면, 상기 프로세서는 상기 자식 자원을 생성하도록 구성되는 것을 특징으로 하는, M2M 장치.
14. 제 13 항에 있어서,
    상기 자식 자원이 생성되면, 상기 프로세서는 상기 자식 자원에 대응하는 서비스의 수행을 상기 제 1 노드로 호출하도록 구성되는 것을 특징으로 하는, M2M 장치.
15. 제 14 항에 있어서, 상기 프로세서는 상기 호출한 서비스의 처리 결과를 상기 제 1 노드로부터 수신하고, 상기 결과를 상기 생성된 자원의 특정 자식 자원에 업데이트하도록 구성되는 것을 특징으로 하는, M2M 장치.
16. 제 10 항에 있어서, 상기 프로세서는 상기 선택된 호출하고자 하는 서비스의 처리 결과를 통보받기 위한 자원을 생성하기 위한 요청을 수신하도록 구성되는 것을 특징으로 하는, M2M 장치.
17. 제 10 항에 있어서,
    상기 제 1 시스템은 제 1 인터페이스 타입을 사용하고, 상기 제 2 시스템은 제 2 인터페이스 타입을 사용하는 것을 특징으로 하는, M2M 장치.
18. 제 10 항에 있어서,
    상기 제 1 인터페이스 타입은 RPC(remote procedure call) API(application program interface)이고, 상기 제 2 인터페이스 타입은 리소스(resource) API 인 것을 특징으로 하는, M2M 장치.

Images