KR20170055530A - 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들 - Google Patents

Abstract

M2M 서비스 레이어는 제3자의 서비스들에 액세스하고 이러한 제3자들과 데이터를 교환하도록 확장된다. 다음으로 M2M 서비스 레이어는 M2M 디바이스들과 제3자 서비스들 사이의 프록시 역할을 할 수 있다. M2M 서비스 레이어는 단일의/일관된 인터페이스, 또는 API를, M2M 디바이스에 제공하고 제3자 서비스 제공자의 상세사항들을 M2M 디바이스로부터 숨길 수 있다.

Description

서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들{SYSTEMS AND METHODS FOR ENABLING ACCESS TO THIRD PARTY SERVICES VIA SERVICE LAYER}

<관련 출원들에 대한 상호 참조>

본 출원은 2014년 9월 17일자로 출원된 미국 임시 특허 출원 제62/051,561호에 대한 우선권을 주장하며, 그 개시내용은 전부가 본 명세서에 참조로 통합된다.

<배경기술>

WS(Web Service)는 네트워크를 통해 컴퓨터들 사이의 상호운용 가능한 상호작용(interoperable interactions)을 지원하도록 설계되는 소프트웨어 시스템을 구현하는 방법이다. WS는 다양한 플랫폼들 및 프레임워크들 상에서 실행되는 소프트웨어 애플리케이션들 사이의 상호운용의 표준 수단을 제공한다. 보다 정확히, WS는 RPC(Remote Procedure Call)의 구체적인 구현 기술이며, 이는 하나의 프로그램이 네트워크에서 상이한 컴퓨터에 위치되는 다른 프로그램으로부터 서비스를 요청할 수 있는 소프트웨어 운용 패러다임이다. WS들은, XML(Extensible Markup Language)의 사용으로 인해, 그들의 머신-판독가능 설명들 뿐만 아니라 그들의 큰 상호운용성 및 확장성을 특징으로 한다. WS들은 복잡한 동작들을 달성할 수 있도록 느슨하게 결합된 방식(loosely coupled way)으로 결합될 수 있어, 간단한 서비스들을 제공하는 프로그램들은 서로 상호작용하여 정교한 부가 가치 서비스들을 전달할 수 있다.

프로토콜 스택 관점에서 볼 때, 서비스 레이어들은 기존 네트워크 프로토콜 스택들의 상부에 통상적으로 계층화되고, 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 따라서 서비스 레이어들은 '미들웨어(middleware)' 서비스들로 종종 분류된다. 예를 들어, 도 1은 IP 네트워킹 스택(104)과 애플리케이션들(106) 사이에 계층화되는 예시적인 서비스 레이어(102)를 도시하는 도면이다.

도 2는 네트워크 내의 서비스 레이어 인스턴스들의 예시적인 배치 시나리오를 도시하는 도면이다. 이러한 예에서, 서비스 레이어 인스턴스들은 다양한 네트워크 노드들(게이트웨이들 및 서버들) 상에 배치되고 네트워크 노드들 자체뿐만 아니라 네트워크 애플리케이션들, 디바이스 애플리케이션들에 부가 가치 서비스들을 제공하는 것으로 도시된다.

M2M(Machine to Machine)/IOT(Internet of Things) 서비스 레이어는 M2M/IoT 타입 디바이스들 및 애플리케이션들에 대한 부가 가치 서비스들를 제공하는 것을 구체적으로 목표로 하는 일 타입의 서비스 레이어의 예이다. 최근에, 몇몇 산업 표준 기관들(예를 들어, ETSI M2M, oneM2M)은 M2M/IoT 타입의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M/IoT 서비스 레이어들을 개발해 왔다.

M2M 서비스 레이어는 애플리케이션들 및 디바이스들에게 서비스 레이어에 의해 지원되는 M2M 중심 능력들의 수집(collection)에 대한 액세스를 제공할 수 있다. 몇몇 예는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급, 및 접속성 관리를 포함한다. 이러한 능력들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용가능하게 된다.

서비스 레이어의 다른 예는 이동 네트워크 디바이스들에 대한 멀티미디어 서비스들을 제공하는 것을 구체적으로 목표로 하는 IMS(IP Multimedia Subsystem) 서비스 레이어이다.

oneM2M의 목적 및 목표는, 다양한 하드웨어 및 소프트웨어 내에 용이하게 내장되고 해당 분야에서의 매우 다양한 디바이스들을 전 세계의 M2M 애플리케이션 서버들과 접속시키는데 의존될 수 있는 공통 M2M 서비스 레이어에 대한 필요성에 대처하는 기술적 사양들을 개발하는 것이다.

도 3은 oneM2M 서비스 레이어(300)의 전체 아키텍처를 도시하는 도면이다. oneM2M 공통 서비스들 레이어는 한 세트의 CSF들(Common Service Functions)(즉, 서비스 능력들)을 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션-특정 노드) 상에서 호스팅될 수 있는 CSE(Common Services Entity)(302 및 304)라고 지칭된다.

oneM2M RESTful 아키텍처당, CSF들은 일 세트의 "리소스들"로서 표현된다. 리소스는 Create, Retrieve, Update, 및 Delete와 같은 RESTful 메소드들을 통해 조작될 수 있는 표현을 갖는 아키텍처 내의 고유하게 어드레스 지정 가능한 엔티티이다. 이러한 리소스들은 URI들(Universal Resource Identifiers)을 사용하여 어드레스 지정 가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 그의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스에 관한 정보를 저장하는 일 세트의 "속성들"을 지원한다.

도 4는 M2M 애플리케이션에 제공되는 M2M 서비스 및 M2M 서비스 제공자들을 명시함으로써 oneM2M 기능적 아키텍처를 보강하는 M2M 서비스 아키텍처(400)를 도시하는 도면이다. 서비스 노출 컴포넌트(402)는 서비스들을 AE들(Application Entities)(404)에 노출시킨다. 네트워크 서비스 이용 컴포넌트(406)는 NSE(Network Service Entity)(408)로부터의 서비스들을 소비한다. 원격 서비스 노출 컴포넌트(410)는 상이한 M2M 환경들로부터의 서비스들을 접속시킨다.

M2M 서비스 레이어는 제3자들의 서비스들에 액세스하고 이러한 제3자들과 데이터를 교환하도록 확장된다. M2M 서비스 레이어는 다음으로 M2M 디바이스들과 제3자 서비스들 사이의 프록시 역할을 할 수 있다. M2M 서비스 레이어는 단일의/일관된 인터페이스, 또는 API를, M2M 디바이스에 제공하고 제3자 서비스 제공자의 상세사항들을 M2M 디바이스로부터 숨길 수 있다.

디바이스들이 더 많은 서비스들에 액세스하고 더 많은 플랫폼들과 데이터를 교환하게 함으로써, 애플리케이션 및 디바이스 개발자들은 사물의 인터넷으로 구축될 수 있는 것의 관점에서 더 많은 가능성들을 제시받는다. 달리 말하면, 보다 많은 정보 교환이 가능할 것이고, 디바이스들은 더 많은 서비스들을 액세스할 수 있을 것이며, 더 광범위한 서비스들이 생성될 수 있다.

설명되는 방법들은 머신 대 머신 통신 또는 사물의 인터넷에 특정되지 않는 서비스 레이어들에도 적용될 수 있다.

M2M 서비스 레이어가 제3자 서비스 제공자들로부터의 부가 가치 서비스들을 통합하는 방법들은 프록시 메커니즘을 통해 사용되어, M2M 서비스 레이어 클라이언트들은 제3자 서비스와 통신하는 방법을 알 필요가 없다.

제3자 서비스 API는 M2M 서비스 레이어에 대해 특정, 정의 또는 제공될 수 있다.

서비스 레이어 클라이언트들은 M2M 서비스 레이어를 통해 이용가능한 제3자 서비스들을 발견할 수 있다. 이러한 서비스들이 호스트 M2M 서비스 레이어의 외부에 있다는 것을 서비스 레이어 클라이언트들이 알 필요는 없다.

서비스 레이어 클라이언트들은 제3자 서비스들에 대한 액세스를 요청하거나, 등록하거나, 공급받을 수 있다.

제3자 서비스는 M2M 서비스 레이어의 원래의 프로토콜과 일치하는 방식으로 서비스 레이어를 액세스할 수 있다.

M2M 기반 인터페이스는 제3자 API로 번역될 수 있고, 요청을 제3자 서비스에 프록시하고, 제3자 서비스로부터 응답을 수신하고, 요청의 발신자에게 원래의 응답을 전송한다.

본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들 선택을 단순화된 형태로 소개하도록 제공된다. 본 내용은 청구 대상의 주요한 특징들 또는 필수 특징들을 식별하기 위한 의도가 아니며, 청구 대상의 범위를 제한하기 위해 사용될 의도도 아니다. 또한, 청구 대상은 본 개시내용의 임의의 부분에서든 언급되는 임의의 또는 모든 단점들을 해결하는 제한 사항들에 제한되는 것은 아니다.

첨부 도면들과 연계하여 예에 의해 주어지는 이하의 설명으로부터 더 상세한 이해를 가질 수 있을 것이다.
도 1은 IP 네트워킹 스택과 애플리케이션들 사이의 계층화된 예시적인 서비스 레이어를 도시하는 도면이다.
도 2는 네트워크 내의 서비스 레이어 인스턴스들의 예시적인 배치 시나리오를 도시하는 도면이다.
도 3은 oneM2M 서비스 레이어의 전체 아키텍쳐를 도시하는 도면이다.
도 4는 M2M 애플리케이션에게 제공되는 M2M 서비스 및 M2M 서비스 제공자들을 명시함으로써 oneM2M 기능적 아키텍처를 보강하는 M2M 서비스 아키텍처를 도시하는 도면이다.
도 5는 제3자 서비스들을 요청하기 위해 대역 외 통신들의 사용을 도시하는 도면이다.
도 6은 M2M 서비스 레이어가 제3자들의 서비스들에 액세스하고 제3자들과 데이터를 교환하게 하는 시스템을 도시하는 도면이다.
도 7은 서비스 레이어 클라이언트들이 제3자 서비스를 액세스하게 하는 단계들을 요약하는 도면이다.
도 8은 oneM2M RoA(Resource-Oriented Architecture) 실시예를 보여주는 흐름도이다.
도 9는 SAE(Service Access Enablement) 컴포넌트를 도시하는 도면이다.
도 10은 <service object> 리소스를 도시하는 도면이다.
도 11은 <service instance> 오브젝트를 도시하는 도면이다.
도 12는 oneM2M 서비스들 아키텍쳐 내의 서비스 액세스 인에이블먼트 컴포넌트뿐만 아니라 새로운 레퍼런스 포인트 Mcs의 정의를 도시하는 도면이다.
도 13은 MQTT(Message Queue Telemetry Transport) 실시예를 도시하는 흐름도이다.
도 14는 일 실시예의 그래픽 사용자 인터페이스의 도면이다.
도 15a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 M2M(machine-to-machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템의 도면이다.
도 15b는 도 15a에 도시되는 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 15c는 도 15a에 도시되는 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도면이다.
도 15d는 도 15a의 통신 시스템의 양상들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

M2M 서비스 레이어들은 제약될 수 있는 디바이스들 또는 센서들 및 데이터 속도, 데이터 소비 제한들 및 계산 복잡성들과 관련하여 제한들을 가질 수 있는 애플리케이션들을 지원하는 요건을 갖고 배치되고 있다. 그들의 제약된 특성으로 인해 이러한 서비스 레이어 클라이언트들은 디바이스 또는 애플리케이션 외부에서 가능한 많은 처리를 수행할 필요가 있을 것이다. 클라이언트들은 처리를 수행하기 위해 서비스 레이어에 종종 의존한다. M2M 서비스 레이어는 일부 부가 가치 처리 서비스들을 원래 지원할 수 있다; 그러나 일반적으로 M2M 서비스 레이어는 배치된 디바이스들, 센서들 및 애플리케이션들이 필요로 하거나 원할 수 있는 가능한 모든 애플리케이션 특정 서비스들 또는 기능성들을 지원하지 못할 수 있다. M2M 서비스 레이어가 원하는 서비스나 기능성을 원래 지원하지 않는 경우, 서비스 레이어 클라이언트들은 이러한 특징들 자체를 구현하거나 제3자 서비스들로부터 이러한 서비스들을 요청할 필요가 있다.

M2M 표준들에는, M2M 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 요청하는 지원이 없다. 따라서, M2M 서비스 레이어와 관련된 디바이스들, 센서들 및 애플리케이션들은 대신 도 5에 도시되는 바와 같이 이러한 서비스를 요청하기 위해 대역 외 통신 프로시저들을 사용해야 한다. 도 5는 대역 외 통신을 사용하여 제3자 서비스들을 요청하는 것을 보여주는 도면이다.

"센서들"(502) 및 "애플리케이션들"(504)이 M2M 서비스 레이어(506)를 통해 서로 접속되고 M2M 서비스 레이어가 정의한 프로토콜들을 사용하여 통신하는 예시적인 배치가 도 5에 도시된다. 이러한 예는 보안 시스템일 것이다.

소형 보안 카메라(도 5의 센서들(502))는 사진들을 촬영하고 그 이미지들을 그들이 저장되는 서비스 레이어(506)에 전송한다. 원본 이미지들 외에도, 보안 시스템은 다음과 같은 특징들을 또한 제공한다:

1. 이미지에 움직임 검출 알고리즘을 적용하고 그 결과를 서비스 레이어에 저장함.

2. 움직임이 검출되면 사용자의 모바일 디바이스에 SMS 경보를 생성함.

3. 대역폭 요건들을 감소시키도록 압축된 버전의 이미지를 제공함.

4. 이미지에서 사람을 식별하는 안면 인식을 제공함.

기존 M2M 서비스 레이어들(506)을 사용하여 이러한 보안 시스템을 구현하기 위해서는, 시스템 분석 및 트레이드 오프들에 기초하여 다음 옵션들 중 임의의 것이 구현될 수 있다:

1. 각각의 원하는 특징들이 디바이스 상에 구현되도록 센서(502)를 구축함.

2. 제3자 서비스들(508)을 통해 이러한 특징들을 요청할 수 있도록 센서(502)를 구축함.

3. 최종 사용자 애플리케이션에서 원하는 특징들 중 일부를 수행함.

4. 제3자 서비스들을 통해 이러한 특징들을 요청할 수 있도록 최종 사용자 애플리케이션을 구축함.

이러한 접근방식의 몇몇 문제점들이 있다(도 5에서 번호가 매겨진 항목들은 이하의 목록에 대응함):

1) M2M/IoT 디바이스들 또는 센서들(502)은 매우 제약적인 디바이스들인 것으로 의도되거나 예상된다. 이러한 디바이스들 또는 센서들이, 제3자 서비스들(508)을 액세스하기 위해, 계산적으로 복잡한 동작들을 수행하거나 또는 M2M 서비스 레이어에 대한 인터페이스 외에 다른 인터페이스를 구현해야 한다면, 이러한 디바이스들 또는 센서들의 크기, 복잡성 및 비용을 증가시킬 것이다.

2) 마찬가지로 제약될 수 있는 최종 사용자 애플리케이션들(504)은 하나 이상의 제3자 서비스들(508)과 인터페이스하고 이들로부터 응답들을 조정하여야 한다. 이는 이러한 애플리케이션들에 대한 복잡성을 추가한다.

3) 제3자 서비스들(508)은 제3자 서비스(508)에 대한 복잡성 및 확장성 문제점들을 야기할 수 있는 디바이스들, 센서들 및 애플리케이션들로부터 여러 더 많은 접속들을 지원해야 할 것이다. 추가적으로, 다수의 애플리케이션들이 동일한 데이터 상에서 서비스를 요청하면, 주어진 제3자 서비스들(508)은 동일한 데이터 상의 서비스들을 다수 회 수행하고 있을 수 있다. 예를 들어, 다수 최종 사용자 애플리케이션들이 동일한 이미지의 압축을 요청하면, 더 큼 수의 요청들 때문에 응답을 취득하기 전에 요청들이 더 긴 대기 시간들을 가질 수 있으므로, 동일한 데이터 상의 다수 요청들은 불량한 품질의 서비스로 이어질 수 있다.

4) 디바이스들, 센서들(502) 및 애플리케이션들(504)은 외부 서비스들에 더 많은 API들을 지원할 것이 요구되며, 이러한 추가적 API들은 디바이스가 주기적으로 소프트웨어 업데이트들을 요구할 가능성을 증가시킨다. 예를 들어, 제3자 서비스 제공자가 자신의 API에 변경을 행하면, 이는 모든 배치된 디바이스들, 센서들 및 애플리케이션들에 대한 업데이트를 요구할 수 있다.

도 6은 M2M 서비스 레이어(604)이 제3자들의 서비스들을 액세스하고 제3자들(606)과 데이터를 교환하게 하는 시스템의 사용을 도시하는 도면이다. M2M 서비스 레이어(604)는 다음으로 센서(602) 및 애플리케이션(608)과 같은 M2M 디바이스들과 제3자 서비스들 사이의 프록시 역할을 할 수 있다. M2M 서비스 레이어는 단일의/일관된 인터페이스, 또는 API를, M2M 디바이스에 제공하고 제3자 서비스(606)의 상세사항들을 M2M 디바이스로부터 숨길 수 있다.

도 6은 예시적인 보안 시스템이 M2M 배치에서 이러한 프로시저들로부터 어떻게 이익을 얻는지를 도시한다. 소형 보안 카메라(612)는 사진을 촬영하고 이미지들을 그것이 저장되는 서비스 레이어(604)에 전송한다. 각각의 이미지가 서비스 레이어(604)에 도달할 때, 그것은 M2M 서비스 레이어(604)에 의해 제3자 서비스(606)에 또한 전송되며, 여기서 이러한 이미지 상에 움직임 검출이 수행되고 그 결과가 서비스 레이어(604)에 또한 저장된다. 그 결과가 동작이 있다는 것을 나타내는 경우, SMS 경보가 사용자의 모바일 디바이스에 시그널링된다. 사용자 애플리케이션(608)이 이러한 이미지를 검색할 때, (원본의 전체 해상도 이미지보다는 오히려) 원본 이미지의 압축된 버전이 응답으로서 전송된다. 사용자 애플리케이션(608)은 이미지 내의 사람을 식별하는데 사용되는 안면 인식 서비스들의 결과들에 대한 액세스를 또한 갖는다.

본 명세서에서 정의되는 방법들을 사용함으로써, 이러한 시스템에서 다양한 당사자들에게 많은 이점들이 제공된다.

디바이스 및 센서 제조업자들은 구체적인 감지 기능에 전용인 센서들(602)을 구축할 수 있고, 제3자 서비스들(606)에 의해 제공되는 추가 처리를 수행하기 위한 추가적인 하드웨어 및 소프트웨어 능력들을 추가해야 하는 것은 아니다. 이것은 덜 복잡함, 더 작은 크기, 더 짧은 스케줄들 및 절감된 비용들로 바로 이어진다.

디바이스 및 센서 제조업자들은 기존 M2M 서비스 레이어(604) 프로토콜들을 사용하여 제3자 서비스들(606)을 액세스할 수 있고 다른 웹 서비스 프로토콜들을 지원하는데 요구될 수 있는 추가적 하드웨어 및/또는 소프트웨어를 추가할 필요가 없다. 이것은 덜 복잡함, 더 작은 크기, 더 짧은 스케줄들 및 절감된 비용들로 바로 이어진다.

디바이스 및 센서 제조업자들은 일부 타입의 디바이스 관리 기능성을 사용하기보다는 오히려 M2M 서비스 레이어(604)에서 구성들을 변경함으로써 제3자들에 의해 제공되는 특징들에 대한 업데이트들을 제공할 수 있다. 이것은 덜 복잡함, 더 작은 크기, 더 짧은 스케줄들 및 절감된 비용들로 바로 이어진다.

애플리케이션들(608)은 M2M 서비스 레이어(604)를 통해 이용가능한 제3자 서비스들(606)을 사용함으로써 훨씬 덜 복잡하게 더 많은 특징이 풍부한 기능들을 제공할 수 있다. 이는 애플리케이션의 더 우수한 성능 및 유지보수성으로 바로 이어질 것이다.

애플리케이션들(608)이 이용가능한 특징들을 사용하기 위해 개별 제3자 서비스 프로토콜들을 인식할 필요는 없다. 이것은 애플리케이션에서의 덜 복잡함으로 바로 이어질 것이다.

서비스 레이어(604)가 서비스 레이어 클라이언트들에 대한 '프록시'이기 때문에 제3자 서비스들(606)은 더 적은 수의 접속들을 통해 더 많은 수의 클라이언트들에 그들의 서비스를 제공할 수 있다. 이것은 감소된 복잡성, 향상된 성능 및 더 우수한 확장성으로 바로 이어진다.

제3자 서비스들은 서비스들의 디렉토리로부터 M2M 서비스 레이어의 내장형 특징들로서 광고될 수 있다.

디바이스, 센서 및 애플리케이션 개발자들은 지원되는 서비스들을 발견하고, 서비스들을 선택하고, 아마도 새로운 서비스들을 요청하거나 또는 심지어 새로운 서비스들에 대한 필요성을 식별하는데 서비스들의 디렉토리 특징을 사용할 수 있다. 이것은 모든 당사자들에게 제공되는 향상된 능력들로 바로 이어진다.

M2M 서비스 레이어(604)는 내부적으로 개발할 필요없이 더욱 진보된 서비스들을 제공할 수 있다. 이것은 감소된 복잡성으로 바로 이어진다.

본 개시내용은 서비스 레이어 클라이언트들이 정상적인 서비스 레이어 API 호출들을 통해 제3자 서비스들(606)에 액세스하게 하기 위해 이러한 프로시저들이 oneM2M 서비스 레이어에서 어떻게 구현될 수 있는지에 대한 실시예를 또한 정의한다.

세 가지 주요 방법들이 정의된다:

- 제3자 서비스(606)을 액세스하는 방법에 대한 상세사항들을 M2M 서비스 레이어(604)에 공급함.

- M2M 서비스 레이어 클라이언트들이 이러한 이용가능한 제3자 서비스들(606)을 발견할 수 있게 함.

- 제3자 서비스(606)에 대한 요청을 트리거하는 M2M 서비스 레이어 인터페이스를 구현함.

도 7은 서비스 레이어 클라이언트들(602)이 제3자 서비스(606)을 액세스하게 하는 단계들을 요약하는 도면이고, 단계 1은 제3자 서비스 API 및 프로토콜이 M2M 서비스 레이어에 의해 알려지게 되는 방법이다. 이러한 정보가 서비스 레이어에 이용가능하게 되면, 단계 2는 서비스 레이어 클라이언트들(또는 그들의 개발자들)이 이러한 제3자 서비스들(606)에 관한 정보를 발견하는 방식이다. 제3자 서비스를 사용하기 원하는 서비스 레이어 클라이언트는 단계 3에서 기존 서비스 레이어 프로토콜들과 일치하는 방식으로 사용 파라미터들을 셋업할 필요가 있다. 그 지점에서, 단계 4에서, 서비스 레이어 클라이언트가 제3자 서비스(606)에 대한 M2M 서비스 레이어 인터페이스를 액세스할 때, 서비스 레이어(604)는 단계 5에서 이러한 요청을 제3자 서비스(606)로 번역하거나 또는 프록시하며, 이는 제3자 서비스(606)로부터 출력 응답을 취득하고 단계 6에서 그 응답을 본래의 요청자 또는 M2M 서비스 레이어 또는 서비스 레이어 클라이언트에 의해 정의되는 바와 같은 다른 목적지에 다시 제공하는데 필요한 모든 통신들을 취급하는 것을 포함한다.

제3자 서비스(606)에 대해 또는 그에 의해 생성될 수 있는 서비스 오브젝트. 서비스 오브젝트들은 서비스 레이어에 통상적으로 위치되며, 예를 들어, oneM2M 실시예에서, 서비스 오브젝트들은 새로운 리소스들로서 표현된다. 이들은 제3자 서비스가 제공하는 것 및 제3자 서비스와 인터페이스하는 방법의 상세사항들을 포함할 수 있다. 서비스 오브젝트를 실제로 표현하는 방법은 구현에 따라 다르다. 일부 예시적인 구현들은 Java 또는 C ++ 클래스들 또는 구조들, 데이터베이스 레코드들, xml 문서들, 또는 서비스 레이어 리소스들 같은 프로그래밍 언어 구문들일 수 있다.

주어진 서비스 레이어에서 그것이 어떻게 구현되는지에 관계없이, 서비스 오브젝트는 M2M 서비스 레이어 클라이언트들이 오브젝트에 의해 설명되는 제3자 서비스들을 발견, 구성 및 사용하게 하는데 필요한 정보의 세트뿐만 아니라, 오브젝트 상에서 또는 이에 의해 수행되는 방법들 또는 프로시저들이다.

서비스 오브젝트의 설명은 (반드시 이에 제한되는 것은 아니지만) 3가지 타입들의 정보로 그룹화될 수 있다. 서비스 오브젝트가 여기서 처음으로 정의되고, 다음으로 서비스 오브젝트의 정의는 본 개시내용의 방법들이 설명됨에 따라 확장된다.

서비스 오브젝트 정보는 제3자 서비스 정보, 당사자 서비스 발견 및 액세스 정보, 및 서비스 인터페이스 정보를 포함할 수 있다.

제3자 서비스 정보는 서비스 레이어(604)와 제3자 서비스(606) 사이에서 통신하는데 필요한 정보를 포함할 수 있다. 이것은 (WSDL와 같이) 제3자 서비스에 의해 사용되는 설명 언어 또는 다른 표준 또는 비표준 인터페이스 메소드들을 포함할 수 있다. 이것은 주문형 통신 프로토콜의 사양을 또한 포함할 수 있다. 도 7의 단계들 1 및 5는 이것을 보여준다.

제3자 서비스 발견 및 액세스 정보는 M2M 서비스 레이어가 M2M 서비스 레이어 클라이언트들 또는 엔티티들에 서비스를 광고하거나 또는 공지하는데 사용하는 정보를 포함할 수 있다. 이것은 특징들의 일반적인 고 수준 설명들, 특징들의 비용, 제3자 서비스 제공자의 명칭, 서비스 사용 방법에 대한 정보로의 링크들 등을 포함할 수 있다. 또한, 이것은 이러한 제3자 서비스들(606)을 사용하기 위한 액세스를 요청하는 수단을 포함할 수 있다. 도 7의 단계들 1 및 2는 이것을 보여준다.

서비스 인터페이스 정보는 M2M 서비스 레이어에 특정될 수 있다. 이것은 M2M 서비스 레이어 클라이언트들이 제3자 서비스 호출에 필요한 모든 파라미터들 및 입력들과 함께 제3자 서비스(606)로의 번역 또는 프록시 호출을 트리거하는 요청들 또는 호출들을 행하는 방법을 설명한다. 도 7의 단계들 3, 4 및 6은 이것을 보여준다.

이러한 서비스 오브젝트는 직접 사용을 위해 서비스 레이어 클라이언트들에 바로 이용가능하게 될 수 있다. 대안적으로 서비스 오브젝트의 일부들만이 이용가능하게 되어, '서비스 레이어' 호환 인터페이스만 노출시킨다.

다음 섹션들은 서비스 오브젝트 정보에 대해 수행되는 프로시저들을 설명한다.

제3자 인터페이스를 공급하는 것의 상세사항들. 웹 서비스들(606)은 그들의 이용가능한 서비스들을 액세스하기 위한 임의의 수의 상이한 프로토콜들을 가질 수 있다. 본 개시내용에 설명되는 방법들을 통해, 그들은, 이용가능하다면, 그들이 이미 사용하는 웹 서비스 프로토콜에 대응하는 설명 언어로 그들의 인터페이스의 설명을 제공할 수 있다.

서비스 레이어(604)는 이 정보를 사용하여 서비스 레이어 클라이언트들(608)을 대신하여 제3자 서비스(606)를 액세스할 수 있다. 서비스 레이어(604)는 제3자 서비스(606)의 프로토콜을 사용하여 제3자 서비스(606)와 통신하고, 그로 인해 제3자 서비스(606)가 요청의 발신자에 의해 사용된 서비스 레이어 프로토콜를 "인식하지 않은" 상태로 남게 한다. 이러한 정보를 저장하기 위해 서비스 오브젝트에 대한 추가 상세사항들이 정의된다.

서비스 오브젝트 제3자 서비스 정보는 서비스 API를 가질 수 있다. 제3자 서비스 API는 명시된 서비스를 요청하는 제3자 서비스에 메시지를 전송하기 위해 M2M 서비스 레이어가 필요로 하는 정보이다. 이것은 M2M 서비스 레이어(604)와 제3자 서비스(606) 사이에 필요한 호출 흐름들을 포함한다. 어드레싱 정보(FQDN 또는 IP 어드레스 및 포트), 전송 프로토콜들(UDP, TCP 등) 및 메시지 포맷들(XML, png 등)이 또한 포함된다.

제3자 서비스 정보를 제공하는 방법은 다양한 구체적인 구현들을 가질 수 있다. 예시적인 구현은 정보가 수동으로 또는 비-자동 방식으로 서비스 오브젝트 데이터베이스 또는 저장 디바이스/프로시저에 입력되는 공급 단계일 수 있다. 다른 예는 제3자 서비스(606)에 의해 그 인터페이스를 정의하기 위해 서비스 설명 언어가 사용될 수 있는 API의 개발일 수 있다. 이러한 경우에 API는 예 1에 도시되는 WSDL과 같은 임의의 수의 프로토콜 설명들을 지원할 수 있다. 다른 예는 M2M 서비스 레이어가 제3자 서비스(606)의 이용가능한 설명의 검색을 착수하는 방법일 수 있다.

예 1 -WSDL 문서 구조:

다음의 예 2는 원래의 M2M 서비스 레이어 프로토콜들로 파싱 및 매핑될 수 있는 샘플 WSDL 문서를 보여준다.

예 2- 온도 변환 서비스 설명:

예 2에서의 WSDL 문서는 하나의 측정 단위에서 다른 것으로 온도들을 변환하는 서비스에 대한 API를 설명한다. WDSL 문서는 필요한 API 파라미터들을 M2M 서비스 레이어에 대응하는 파라미터들에 매핑하기 위해 M2M 서비스 레이어에서 필요로 하는 다음과 같은 필수 정보들을 추출하기 위해 파싱될 수 있다.

이러한 서비스 설명 문서에 의해 정의되는 M2M 서비스 레이어(604)로부터의 샘플 요청이 예 3에 보여진다:

예 3: 온도 변환 요청

M2M 서비스는 ConvertTemp 데이터 타입으로부터 예 3에 보여지는 WSDL 문서로부터 이러한 요청에서의 3개의 파라미터를 식별할 수 있다. 이러한 입력들로부터 M2M ServiceLayer 타입들로의 매핑의 타입이 이러한 문서로부터 파생될 수 있으며, 여기서 "web:Temperature" 파라미터는 "s:double" 및 "web:FromUnit"으로서 정의되고, "web:ToUnit" 파라미터들은 "tns:TemperatureUnit"에 정의되는 세트로부터의 값들의 선택으로서 정의된다.

제3자 서비스(606)을 액세스하는 방법의 설명을 취득하는 것에 추가하여, 서비스 레이어(604)는 제3자 서비스(606)를 액세스하는데 필요한 자격 증명을 명시하는 수단을 취득한다. 예를 들어, M2M 서비스 레이어(604)는 M2M 서비스 레이어(604)의 자격 증명을 사용하여 모든 서비스 레이어 클라이언트들(608)이 제3자 서비스(606)를 액세스하게 하는 자격 증명을 확보하는 것이 가능할 수 있다. 이러한 경우에 M2M 서비스 레이어(604)는 M2M 서비스 레이어 클라이언트들(608)로 전달되거나 부가 가치 서비스로서 제공될 수 있는 서비스들의 사용을 위한 청구에 대해 합의를 수립하였을 것이다. 다른 예는, M2M 서비스 레이어(608) 클라이언트가 이러한 서비스를 사용하기 위한 자신의 자격 증명을 가지며, 제3자 서비스 제공자에 의해 제조업자에게 제공되는 구체적인 자격증명을 특정 제조업자의 모든 디바이스들이 사용하는 것과 같이, 서비스의 각각의 사용에 대해 이러한 정보를 제공할 필요가 있는 것일 수 있다. 이러한 경우에 청구는 데이터 사용 또는 다른 합의된 약정 이외에 M2M 서비스 레이어(604)의 범위 밖에 있을 수 있다.

제3자 서비스들 인터페이스 정의들이 서비스 레이어(604)에 의해 저장되면, 이러한 서비스들을 알려서 서비스 레이어 클라이언트들에게 액세스 가능하게 하는 방법이 있다. 서비스 레이어(604)는 이러한 서비스들을 서비스 레이어 클라이언트들(608)에 "광고"할 수 있고 제3자 서비스(606)에 요청을 트리거하는 서비스 레이어(604) 정의 인터페이스를 "설명한다".

서비스 레이어(604)는 서비스 레이어 클라이언트(608)가 판독할 수 있는 서비스들의 디렉토리를 제공하여 어떤 서비스들이 이용가능한지를 이해하고, 이러한 서비스들을 어떻게 사용하는지의 상세사항들을 요청한다. 이러한 정보를 저장하기 위해 서비스 오브젝트에 대한 추가 상세사항들이 정의된다.

서비스 오브젝트 제3자 서비스 발견 및 액세스 정보는 제공되는 서비스의 설명인 서비스 설명을 가질 수 있다. 이것의 콘텐츠 및 포맷은 다양한 구체적인 구현들을 가질 수 있다. 예를 들어, 개발 또는 장비/애플리케이션 셋업 동안 제공되는 서비스를 설명하기 위해 개발자들 또는 최종 사용자들이 보게 되는 HTML 설명일 수 있다. 이것은 특징들, 비용, 사용 요건들 등에 관련되는 임의 타입의 정보를 포함할 수 있다. 서비스 설명 정보은 키들 또는 색인들을 정의하는 방법을 또한 포함하여, 서비스 레이어 클라이언트들은 특정 타입의 검색을 찾기 위한 검색들을 수행할 수 있으며, 예를 들어,

GET 서비스? type = image_compression.

위에 제공된 정보를 사용하여, 서비스 레이어 클라이언트 개발자들은 그들 자신의 능력들에 가치를 부가할 수 있는 서비스들을 검색할 수 있고, 원래의 서비스 레이어 프로토콜들을 통해 그 서비스를 사용하기 위한 승인을 요청할 수 있다.

M2M 서비스 레이어 클라이언트들(608)이 제3자 서비스(606)를 사용하기를 원할 때, M2M 서비스 레이어(604)는 제3자 서비스(606)에 대한 메시지 또는 메시지들을 적절히 형성하기 위해 서비스 API 정보를 사용한다. 본 개시내용에 설명되는 방법들을 통해 서비스 레이어(604)는 서비스 레이어 클라이언트들(608)이 서비스 레이어에 고유한 프로토콜들을 사용하여 제3자 서비스들(606)을 액세스하게 하는 인터페이스를 정의한다.

서비스 오브젝트에 대한 추가적 상세사항들은 이러한 정보를 저장하도록 정의된다. 서비스 오브젝트 제3자 서비스 인터페이스 정보는 서비스 레이어 클라이언트들이 제3자 서비스(606)에 액세스하는데 사용할 서비스 레이어 정의 인터페이스를 포함할 수 있다. 이러한 정보는 입력 파라미터들, 출력 파라미터들, 액세스 자격 증명, 및 제3자 서비스(606)가 필요로 하는 임의의 다른 정보를 지정하는 방법을 포함한다. 이러한 정보는 서비스 레이어 클라이언트를 대신하여 제3자 서비스 요청을 착수하거나 행하도록 서비스 레이어(604)를 트리거하는 방법을 또한 명시한다. 서비스 레이어(604)는 서비스 API 정보를 평가하거나 파싱하고 각각의 API 파라미터들을 원래의 서비스 레이어 인터페이스 또는 속성에 매핑함으로써 이러한 인터페이스를 정의한다, 예를 들어, 이미지를 입력 파라미터로서 요구하는 제3자 서비스 API는 제3자 서비스가 검색할 수 있는 이미지의 URI에 매핑될 수 있다. M2M 서비스 레이어 애플리케이션 개발자는 이러한 정보를 사용하여 제3자 서비스(606)에 액세스할 수 있다.

제3자 서비스(606)와 인터페이스하는 방법의 상세사항들을 사용하여, 서비스 레이어(604)는 원래의 서비스 레이어 오브젝트들 또는 리소스들을 제3자 서비스 특정 입력들에 매핑하고, 제3자 서비스(606)에 의해 지원되는 웹 서비스 프로토콜을 사용하여 요청을 전송한다. 서비스 레이어(604)는 제3자 서비스(606)로부터의 결과 또는 응답을 또한 취급하고 그것을 적절한 원래의 서비스 레이어 응답에 다시 매핑한다.

도 8은 oneM2M RoA 실시예를 도시하는 흐름도이다. 이러한 도면은 본 개시내용에 설명되는 방법들 및 프로시저들이 oneM2M 아키텍처에서 구현될 수 있는 한 가지 방식을 도시한다.

oneM2M 서비스 오브젝트 공급 툴(802)은 본 실시예에서 정의되는 서비스 오브젝트를 공급하기 위한 유틸리티일 수 있다. 이러한 애플리케이션은 웹 서비스 API 및 설명을 oneM2M 서비스 레이어에 전송하는 것을 지원하는 oneM2M 애플리케이션이다. 이러한 예에서, Puny PNG 웹 서비스(804)의 발견이 행해진다. 이것은 웹 검색을 통해 발견된 서비스일 수 있거나, 또는 이것은 이러한 서비스를 사용하는 애플리케이션 엔티티들에 특정한 주문형 구현 서비스일 수 있다, 예를 들어, 보안 카메라 제조업자는 자신의 카메라들만 액세스하는 웹 서비스를 호스팅할 수 있다. oneM2M 서비스 오브젝트 공급 툴(802)은 Mca 레퍼런스 포인트를 통해 CSE와 통신할 수 있다.

이러한 예에서, Puny PNG 웹 서비스(804)는 png 포맷의 이미지에 대한 제한된 무료 압축 및 가입비에 대한 추가 서비스들을 제공하는 활성 웹 서비스이다. Puny PNG 웹 서비스(804)는 계정을 생성하여 당신이 취득하는 액세스 키를 사용하도록 요구할 수 있다. Puny PNG 웹 서비스(804)는 제3자 서비스에 고유한 프로토콜들을 통해 CSE(806)와 통신할 수 있다. 이것은 oneM2M 아키텍처에서의 새로운 레퍼런스 포인트가 될 수 있다. 이 새로운 레퍼런스 포인트 Mcs는 도 12에 도시된다.

CSE(806)는 본 개시내용 및 본 실시예에서 정의되는 방법들을 지원하는 oneM2M 공통 서비스들 엔티티의 인스턴스이다.

애플리케이션 엔티티 # 1(808)은 이미지들을 oneM2M CSE(806)에 배치하는 디바이스 또는 애플리케이션이다. 이러한 예에서, 그것은 서비스 오브젝트 발견 및 셋업 프로시저들을 수행한다. 이러한 단계는 하드웨어 또는 디바이스들을 종종 수반하는 셋업 애플리케이션과 같은 별도의 엔티티에 의해 행해졌을 수 있다. 애플리케이션 엔티티 # 1(808)은 구성된 속도로 사진들을 촬영하는 원격 보안 카메라일 수 있다. 애플리케이션 엔티티 # 1(808)은 Mca 레퍼런스 포인트를 통해 CSE(806)와 통신할 수 있다.

애플리케이션 엔티티 # 2(810)는 애플리케이션 엔티티 # 1(808)에 의해 제공되는 이미지들의 압축된 버전들을 검색하는 애플리케이션일 수 있다. 애플리케이션 엔티티 # 2(810)는 oneM2M CSE(806)로부터 최신 이미지들을 주기적으로 취득하는 웹 기반 애플리케이션일 수 있다. 애플리케이션 엔티티 # 2(810)는 Mca 레퍼런스 포인트를 통해 CSE(806)와 통신할 수 있다.

도 8에는, oneM2M 서비스 레이어 아키텍처를 사용하는 액터들에 대해 본 개시에서 설명되는 방법들 및 프로시저들이 도시된다. 각각의 주 메시지들은 그 특정 메시지의 상세한 설명에 대응하는 위 첨자로 주석이 달린다.

도 8의 단계 1에서, 서비스 오브젝트 공급 툴(802)은 서비스 오브젝트 리소스의 인스턴스 및 PunyPNG 웹 서비스(804)에 대한 인스턴스를 생성한다. 생성 프리미티브는 서비스 API 정보뿐만 아니라 서비스 설명 정보를 포함한다.

이러한 예에서, 서비스 자격 증명은, 서비스 레이어 클라이언트들이 제3자 서비스 정의 프로시저들을 사용하여 그들 자신의 API_KEY를 요청할 것을 요구하는 서비스 레이어에 공급되지 않는다. 이것은 서비스 레이어와 제3자 서비스 사이의 배치 결정이다. 다른 배치 옵션에서, oneM2M 서비스 레이어는 서비스 레이어가 모든 클라이언트들에 대해 단일 키를 사용하게 하는 제3자 서비스와의 배치를 가질 수 있다. 이것은 아래에 보여지는 결과들 중 일부를 경미하게 변경할 수 있지만, 프로세스는 변경되지 않는다.

oneM2M 서비스 레이어는 요청에 제공되는 서비스 API를 분석하여 서비스 레이어에서의 <serviceInterface> 리소스에 매핑한다. 매핑 프로세스는 서비스 레이어에서 웹 서비스 설명 언어들 또는 수동 구성을 사용하여 행해질 수 있다. 예시적인 요청/응답 쌍들은 다음의 서비스 레이어 정보를 생성할 수 있다:

이러한 제3자 서비스 API에는, 서비스 레이어 인터페이스에 매핑되는 2개의 입력 파라미터들 및 6개의 출력 파라미터들을 생성하는 2개의 요청/응답 쌍들이 있다. 추가적 입력 파라미터는 어느 작업의 구성이 서비스를 트리거할 수 있는지 허용하도록 서비스 레이어에 의해 명시된다.

이러한 포인트에서 서비스 레이어는 서비스 레이어 클라이언트들에 의해 사용될 준빅 된 이러한 제3자 서비스에 대한 서비스 오브젝트 인스턴스를 갖는다.

도 8의 단계 2에서, 서비스 레이어 클라이언트는 공개된 서비스를 발견한다. 애플리케이션 개발자는 서비스 레이어 발견 프로시저들을 사용하여 이미지 압축을 수행하는 서비스를 발견한다. 발견 요청의 결과는 원하는 특징을 수행하는 서비스들의 URI들을 포함하는 한편 제2 요청은 서비스의 설명을 취득한다. 이것은 다음과 같이 HTML 뷰어에서 디스플레이될 수 있다:

도 8의 단계 3에서, 서비스 레이어 클라이언트는 공개된 서비스에 대한 액세스를 요청한다. 서비스 레이어 클라이언트가 자신의 필요성을 충족하는 서비스를 찾으면, 클라이언트는 공개된 서비스에 대한 액세스를 요청한다. 이러한 예시적인 실시예에서, oneM2M 서비스 레이어는 이러한 리소스에 대한 READ 액세스를 허용하여, 정의되는 바와 같이, 모든 클라이언트들이 적절한 인터페이스를 구현하면 액세스를 갖는다. 서비스 레이어 클라이언트들은 제3자 서비스가 액세스될 수 있는 방법을 명시하는 인터페이스 설명을 검색한다.

도 8의 단계 4에서, 서비스 레이어 클라이언트는 제3자 서비스에 대한 사용을 셋업한다. 인터페이스 설명으로부터의 정보를 사용하여, 애플리케이션 엔티티는 oneM2M 서비스 레이어에 의해 정의되는 인터페이스를 구현하는데 필요한 파라미터들로 <serviceInstance> 리소스를 생성한다. 이러한 예에서 서비스 레이어 클라이언트는 제3자 서비스에 의해 압축될 수 있는 이미지들의 위치(컨테이너)를 명시할 필요가 있다. 서비스 레이어 클라이언트의 API_KEY 및, 이 경우에는 압축된 이미지들인 제3자 서비스의 결과들에 대한 위치가 또한 필요하다.

도 8의 단계 5에서, 서비스 레이어 클라이언트는 제3자 서비스의 사용을 트리거한다. 이러한 예에서, 애플리케이션 엔티티 #1은 /cesbase/myPictures에서 이미지들을 생성한다(CREATES). 타겟 URI 상의 OPERATION과 함께 이미지의 타겟 URI는 제3자 서비스에 액세스하는 서비스 레이어 프로시저들을 시작하기 위한 트리거이다. 이러한 예에서 리소스가 /cesbase/myPictures에 성공적으로 생성되면(CREATED) 서비스 레이어는 프로세스를 시작할 수 있다.

도 8의 단계 6에서, 서비스 레이어는 사용자 데이터를 제3자 서비스에 프록시한다. 서비스 레이어 클라이언트에 의해 생성되는 <serviceInstance> 리소스는 원본 <serviceObject> 리소스를 지목한다. CREATE <serviceObject>(1 단계)에서 제공되는 serviceAPI는 웹 서비스 요청의 콘텐츠 및 포맷을 명시한다. 서비스 레이어는 <serviceInstance> 리소스에서 제공되는 데이터를 사용하여 명시되는 시퀀스의 요청들 및 응답들을 수행한다. 이 때, 서비스 레이어는 서비스를 액세스하고 있는 서비스 레이어 및/또는 서비스 클라이언트를 식별하는데 웹 서비스가 사용할 수 있는 과금 식별자를 웹 서비스에 제공할 수 있다.

서비스 레이어는 결과(들)를 서비스 레이어 클라이언트의 <serviceInstance>에 의해 명시되는 위치들에 배치한다. 선택적으로, 서비스 레이어는 통지 또는 응답 메시지를 서비스 레이어 클라이언트에 전송하여 결과들이 준비되었음을 알릴 수 있다. (이러한 옵션은 위 도면에 도시되지 않는다).

도 8의 단계 7에서, 서비스 레이어 클라이언트들은 제3자 서비스의 결과에 대한 액세스를 갖는다. 서비스 레이어가 결과들을 명시된 출력 URI에 배치하면, 다른 클라이언트들이 결과에 대한 액세스를 가질 수 있다. 이러한 예에서, AE #2는 원본 이미지 대신에 압축된 이미지를 검색(RETRIEVE)할 수 있다.

도 8에 도시되는 단계들을 수행하는 엔티티들은 도 15c 또는 도 15d(우리의 2개의 환경 도면들)에 도시되는 것들 중 하나와 같은 디바이스, 서버, 또는 다른 컴퓨터 시스템의 메모리에 저장되고, 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 점이 이해된다. 즉, 도 8에 도시되는 방법(들)은, 예를 들어 도 15c 또는 도 15d에 도시되는 디바이스 또는 컴퓨터 시스템과 같은, 컴퓨팅 디바이스의 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능 명령어들은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 8에 도시되는 단계들을 수행한다.

oneM2M 서비스 레이어에서의 이러한 실시예는 2개의 새로운 리소스 정의들: <serviceObject> 및 <serviceInstance>를 정의한다.

본 문헌에서 제안되는 기능들은 기존 oneM2M 기능적 아키텍처에 대한 추가로서 새로 정의되는 CSF 실시예에서 구현될 수 있다. 도 9는 CSE(904) 내의 새로운 CSF인 SAE(Service Access Enablement)(902)를 도시하는 도면이다.

도 10은 <service object> 리소스(1002)를 도시하는 도면이다. <service object> 리소스(1002)는 oneM2M 서비스 레이어에 제3자 서비스들에 대한 인터페이스 정의를 저장하기 위한 컨테이너를 나타낸다. 이것은 서비스 레이어 클라이언트들에 대한 서비스 설명과 제3자 서비스를 셋업하고 액세스하기 위한 인터페이스를 제공하는데 또한 사용된다.

도 11은 <service instance> 오브젝트(1102)를 도시하는 도면이다. <service instance> 리소스(1102)는 서비스 인터페이스 정보를 저장하기 위한 컨테이너를 나타낸다. 이러한 리소스는 <serviceObject> 리소스들(1102)에 정의되는 제3자 서비스를 사용하기 원하는 서비스 레이어 클라이언트들에 의해 생성된다. <serviceObject>로 링크되는 속성(1104) 및 서비스 레이어에 의해 '매핑된' 입력들 및 출력들 각각에 대한 속성들이 있다. 서비스 레이어는 이러한 입력들을 제3자 서비스 요청(들)에 대한 파라미터들로서 사용할 수 있다. 서비스 레이어는 제3자 서비스의 결과들을 저장할 위치에 대해 이러한 리소스에서 명시되는 출력들을 또한 사용할 수 있다.

oneM2M RoA 실시예에 대해 위에 논의된 아이디어들 및 프로시저들은 oneM2M SoA(Service Oriented Architecture)에서 또한 구현될 수 있다.

도 12는 새로운 레퍼런스 포인트 Mcs의 정의뿐만 아니라 oneM2M 서비스 아키텍쳐(1200) 내의 서비스 액세스 인에이블먼트 컴포넌트(1202)를 도시하는 도면이다. 이러한 리소스들은 도 9에서의 것들과 유사한다.

도 13은 MQTT(Message Queue Telemetry Transport) 실시예의 흐름도이다. MQTT는 TCPIP 프로토콜의 상부에서 사용하기 위한 공개-가입 기반 "경량" 메시징 프로토콜이다. 공개-가입 메시징 패턴은 메시지 토픽에 기초하여 관심있는 클라이언트들에게 메시지들을 배포하는 것을 담당하는 MQTT 브로커를 사용한다. 본 실시예는 본 개시내용에 설명되는 방법들 및 프로시저들이 MQTT 아키텍처를 사용하여 구현될 수 있는 하나의 방식을 보여준다. 본 실시예는 다음의 예시적인 시나리오로 예시된다.

MQTT 브로커(1302)는 본 개시내용 및 본 실시예에서 정의되는 방법들을 지원하는 oneM2M 공통 서비스들 엔티티의 인스턴스이다.

기본 MQTT 프로토콜은 메시지 전달을 지원한다. 기본 프로토콜의 MQTT 브로커 확장들은 HiveMQ와 같은 주문형 수정들을 지원할 수 있는 구현을 요구한다. 서비스 오브젝트 확장(1306)은 웹 서비스 API 및 설명을 수신하는 것을 지원하는 브로커 확장이다. 서비스 오브젝트 확장(1306)은 정의된 토픽 패턴으로 공개된 메시지들을 수신하고 서비스에 관련된 서비스 레이어 기능들을 수행할 수 있다.

토픽 디렉토리 확장(1310)은 서비스 오브젝트 토픽들의 발견을 지원하는 브로커 확장이다. 이것은 다른 토픽들의 발견을 지원하기 위해 마찬가지로 일반화될 수 있는데 그 이유는 기본 MQTT 프로토콜의 특징이 아니기 때문이다.

Puny PNG 웹 서비스(1312)는 png 포맷의 이미지에 대한 제한된 무료 압축 및 가입비에 대한 추가 서비스들을 제공하는 활성 웹 서비스이다. Puny PNG 웹 서비스(1312)는 계정을 생성하여 당신이 취득하는 액세스 키를 사용하도록 요구할 수 있다. Puny PNG 웹 서비스(1312)는 제3자 서비스에 고유한 프로토콜들을 통해 MQTT 브로커 서비스 오브젝트 확장과 통신한다.

서비스 오브젝트 공급 툴(1314)은 웹 서비스 API 및 설명을 MQTT 브로커에 전송하는 것을 지원하는 애플리케이션이다. 서비스 오브젝트 공급 툴(1314)은 본 실시예에서 정의되는 서비스 오브젝트를 공급하기 위한 유틸리티일 수 있다. 본 실시예에서, Puny PNG 웹 서비스의 발견은 본 개시내용의 범위를 벗어나서 발생한다. 이것은 웹 검색을 통해 발견된 서비스일 수 있거나, 또는 이것은 이러한 서비스를 사용하는 애플리케이션 엔티티들에 특정한 주문형 구현 서비스일 수 있다, 예를 들어, 보안 카메라 제조업자는 자신의 카메라들만 액세스하는 웹 서비스를 호스팅할 수 있다.

MQTT 클라이언트 센서(1316)는 이미지들을 MQTT 브로커에 배치하는 디바이스 또는 애플리케이션이다. 이러한 예에서, 그것은 서비스 오브젝트 발견 및 셋업 프로시저들을 수행한다. 이러한 단계는 하드웨어 또는 디바이스들을 종종 수반하는 셋업 애플리케이션과 같은 별도의 엔티티에 의해 행해졌을 수 있다. MQTT 클라이언트 센서(1316)는 구성된 속도로 사진들을 촬영하는 원격 보안 카메라일 수 있다.

MQTT 클라이언트 애플리케이션(1318)은 MQTT 클라이언트 센서에 의해 제공되는 이미지들의 압축된 버전들에 가입하는 애플리케이션이다.

도 13에는, 본 개시내용에서 설명되는 방법들 및 프로시저들이 MQTT 브로커(1302)를 사용하는 액터에 대해 도시된다.

도 13의 단계 1은 제3자 서비스를 제공/발행/구성하는 단계이다. 서비스 오브젝트 공급 툴(1314)은 PunyPNG 웹 서비스(1312)에 대한 서비스 오브젝트의 인스턴스를 생성한다. PUB 토픽은 서비스 오브젝트로서 이것을 식별하기 위해 MQTT 브로커 확장(1306)에 의해 사용된다. 메시지 페이로드는 서비스 API 정보뿐만 아니라 서비스 설명 정보를 포함한다. 이러한 예에서, 서비스 자격 증명은, 서비스 레이어 클라이언트들이 제3자 서비스 정의 프로시저들을 사용하여 그들 자신의 API_KEY를 요청할 것을 요구하는 서비스 레이어에 공급되지 않는다. 이것은 서비스 레이어와 제3자 서비스 사이의 배치 결정이다.

이러한 실시예에서 토픽들에 대한 협약은 serviceobject.<third_party_service_name>.<service_description>이다. 이러한 협약은 상이할 수 있다.

MQTT 서비스 오브젝트 확장(1314)은 명시된 토픽 협약, 본 경우 토픽 명칭에 "serviceobject"를 포함하는 모든 메시지들과 일치하는 공개된 메시지들을 인터셉트한다.

MQTT 서비스 오브젝트 확장(1314)은 요청에서 제공되는 서비스 API를 분석하여 섹션에서 설명되는 바와 같은 페이로드 포맷 및 토픽 명명 협약에 매핑한다.

매핑 프로세스는 서비스 레이어에서 웹 서비스 설명 언어들 또는 수동 구성을 사용하여 행해질 수 있다. 예시적인 요청/응답 쌍들은 다음의 서비스 레이어 정보를 생성할 수 있다:

이러한 제3자 서비스 API에는, MQTT 토픽 협약에 매핑되는 2개의 입력 파라미터들 및 6개의 출력 파라미터들을 생성하는 2개의 요청/응답 쌍들이 있다.

이러한 포인트에서, MQTT 서비스 오브젝트 확장(1306)은 서비스 레이어 클라이언트들에 의해 사용할 준비가 된 이러한 제3자 서비스에 대한 서비스 오브젝트 인스턴스를 갖는다.

도 13의 단계 2에서, 서비스 레이어 클라이언트는 공개된 서비스를 발견한다. 이러한 애플리케이션은 MQTT 토픽 발견 확장(1306)을 사용하여 이미지 압축을 수행하는 서비스들을 발견한다. 토픽 발견 확장(1306)은 토픽 토큰 "발견"을 SUB 메시지의 시작에 덧붙임으로써 트리거된다. 발견 요청의 결과는 원하는 특징과 일치하는 서비스들의 토픽들을 포함한다.

애플리케이션은 반환되는 서비스들의 설명들을 선택적으로 요청한다. 예시적인 설명은 HTML 뷰어에서 다음과 같이 디스플레이될 수 있다:

도 13의 단계 3에서, 서비스 레이어 클라이언트(1316)는 공개된 서비스에 대한 액세스를 요청한다. MQTT 클라이언트(1316)가 자신의 필요성을 충족하는 서비스를 찾으면, 클라이언트는 공개된 서비스에 대한 액세스를 요청한다. 이러한 예시적인 실시예에서, 서비스 레이어 클라이언트(1316)는 제3자 서비스가 액세스될 수 있는 방법을 명시하는 인터페이스 설명을 검색한다.

도 13의 단계 4에서, 서비스 레이어 클라이언트(1316)는 제3자 서비스에 대한 사용을 셋업한다. 인터페이스 설명으로부터의 정보를 사용하여, MQTT 클라이언트 센서는 서비스 인터페이스에서 정의되는 토픽들에 공개되는 메시지들을 생성한다. 이러한 예에서 이것은 다음과 같을 수 있다:

여기서, "serviceobject" 및 "punyPngService"는 2개의 요구되는 토픽들이고,

"256"은 outputsize 파라미터이고,

"AKU1FYY1GBDKJRB"는 API_KEY 파라미터이고,

"myHouse.frontdoor"는 output_topics이다.

그리고 이러한 메시지의 페이로드는 "png" 포맷의 이미지여야 한다.

도 13의 단계 5에서, 서비스 레이어 클라이언트(1316)는 제3자 서비스의 사용을 트리거한다. 이러한 예에서의 MQTT 클라이언트 센서는 위에 설명된 포맷에 따라 이미지를 공개한다.

도 13의 단계 6에서, 서비스 레이어는 사용자 데이터를 제3자 서비스에 프록시한다. "serviceobject" 토픽은 이러한 메시지를 서비스 오브젝트 확장으로 지향하는데 사용된다. "punyPngService" 토픽은 제3자 서비스에 대한 서비스 오브젝트 API를 찾는데 사용된다. 토픽 명칭의 나머지에서의 파라미터들은 제3자 서비스 API에 의해 요구되는 파라미터들에 매핑된다. 서비스 오브젝트 확장은 공개된 메시지에서 제공되는 데이터를 사용하여 명시되는 시퀀스의 요청들 및 응답들을 수행한다. 서비스 오브젝트는 결과를 "output_topics"에 공개한다.

도 13의 단계 7에서, 서비스 레이어 클라이언트(1616)는 제3자 서비스의 결과에 대한 액세스를 갖는다. 이러한 토픽들을 수신하기 원하는 클라이언트 앱은 "output_topics"에 가입하여 제3자 서비스로부터 온 압축 이미지들을 수신할 수 있다.

도 13에 도시되는 단계들을 수행하는 엔티티들은 도 15c 또는 도 15d(우리의 2개의 환경 도면들)에 도시되는 것들 중 하나와 같은 디바이스, 서버, 또는 다른 컴퓨터 시스템의 메모리에 저장되고, 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 점이 이해된다. 즉, 도 13에 도시되는 방법(들)은, 예를 들어 도 15c 또는 도 15d에 도시되는 디바이스 또는 컴퓨터 시스템과 같은, 컴퓨팅 디바이스의 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능 명령어들은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 13에 도시되는 단계들을 수행한다.

GUI들(Graphical User Interfaces)과 같은 인터페이스들은 사용자가 서비스 레이어를 통해 제3자 서비스에 대한 액세스를 가능하게 하는 것에 관련된 기능성들을 제어 및/또는 구성하는 것을 돕는데 사용될 수 있다. GUI들은 대응하는 M2M SL 원래의 프로토콜에서 제3자 서비스의 API를 명시하고, 제3자 서비스들의 발견을 지원하고, 서비스들의 설명을 제공하고, 서비스들에 대한 액세스 요청을 허용하는 방법을 정의하는 제3자 서비스들을 지원할 수 있다. 도 14는 예시적인 인터페이스들(1402, 1404 및 1406)을 도시하는 도면이다. 인터페이스(1402)는 사용자들이 제공된 서비스에 관한 설명 또는 추가 정보를 입력하게 한다. 인터페이스(1404)는 사용자가 요청 API를 입력하고 예상되는 응답을 나타내게 한다. 인터페이스(1406)는 제3자 서비스에 대한 검색을 허용한다. 인터페이스들(1402, 1404 및 1406)은 이하에 설명되는 도 15c 내지 도 15d에 도시된 것들과 같은 디스플레이들 사용하여 생성될 수 있다는 점이 이해되어야 한다.

예시적인 M2M / IoT / WoT 통신 시스템

도 15a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼이 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 레이어 등의 컴포넌트 또는 노드일 수 있다. 통신 시스템(10)은 개시되는 실시예들의 기능성을 구현하는데 사용될 수 있고, 외부 서비스들(606)과 같은 기능성 및 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들을 포함할 수 있다.

도 15a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크(예를 들어, Ethernet, Fiber, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등)일 수 있거나, 또는 이종 네트워크들 중 하나의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 사용자들에게 제공하는 다수의 액세스 네트워크들로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법들을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 영역 네트워크, 융합형 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 15a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 보통은 M2M 게이트웨이의 배후에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인은 양자 모두 다양하고 상이한 네트워크 노드들(예를 들어, 서버들, 게이트웨이들, 디바이스 등)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 바에 따라 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해, 통신 회로를 사용하여, 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비-셀룰러)뿐만 아니라 고정형 네트워크 M2M 디바이스들(예를 들어, PLC)가 통신 네트워크(12) 또는 직접 무선 링크와 같은 오퍼레이터 네트워크들을 통해서 통신하게 한다. 예를 들어, M2M 단말 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집할 수 있고, M2M 애플리케이션(20) 또는 다른 M2M 디바이스들(18)에 데이터를 보낼 수 있다. M2M 단말 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 단말 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 아래 설명되는 것처럼 M2M 서비스 레이어(22)를 통해 M2M 애플리케이션(20)에 송신될 수 있고 및 그로부터 수신될 수 있다. M2M 단말 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

예시적인 M2M 단말 디바이스들(18)은, 이에 제한되는 것은 아니지만, 태블릿들, 스마트 폰들, 의료 기기들, 온도 및 날씨 모니터들, 접속된 차량들, 스마트 미터들, 게임 콘솔들, 개인 휴대 정보 단말기들, 건강 및 운동 모니터들, 조명들, 온도 조절기들, 가전 제품들, 차고 문들 및 기타 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 아웃렛들을 포함한다.

도 15b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)는 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 대한 서비스들을 제공한다. 통신 네트워크(12)는 개시되는 실시예들의 기능성을 구현하는데 사용될 수 있고, 외부 서비스들(606)과 같은 기능성 및 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들을 포함할 수 있다. M2M 서비스 레이어(22)는 예를 들어 이하 설명되는 도 15c 및 도 15d에 도시되는 디바이스들을 포함하는 하나 이상의 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예를 들어, 클라우드/스토리지 팜들 등) 등에 의해 구현될 수 있다. M2M 서비스 레이어(22)는 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들(14), M2M 단말 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 레이어(22)는 네트워크의 하나 이상의 노드들에 의해 구현될 수 있으며, 이는 서버들, 컴퓨터들, 디바이스들 등을 포함할 수 있다. M2M 서비스 레이어(22)는 M2M 단말 디바이스들(18), M2M 게이트웨이들(14), 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 레이어(22)의 기능들은 다양한 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등으로 구현될 수 있다.

도시되는 M2M 서비스 레이어(22)와 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 레이어(22')가 있다. M2M 서비스 레이어(22')는 인프라스트럭처 도메인에서 M2M 애플리케이션(20') 및 기본 통신 네트워크(12')를 위한 서비스들을 제공한다. M2M 서비스 레이어(22')는 또한 필드 도메인에서 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22')는 임의 수의 M2M 애플리케이션들, M2M 게이트웨이들 및 M2M 디바이스들과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 레이어(22')는 상이한 서비스 제공자에 의해 서비스 레이어와 상호작용할 수 있다. M2M 서비스 레이어(22')는 서버들, 컴퓨터들, 디바이스들, 또는 가상 머신들(예를 들어, 클라우드 컴퓨팅/스토리지 팜들, 기타 등등) 또는 이와 유사한 것을 포함할 수 있는, 네트워크의 하나 이상의 노드들에 의해 구현될 수 있다.

도 15b를 또한 참조하면, M2M 서비스 레이어(22 및 22')는 다양한 애플리케이션들 및 버티컬들이 영향력을 행사할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20, 20')이 디바이스들과 상호작용하고 또한 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 과금, 서비스/디바이스 발견 등과 같은 기능들을 수행하는 것을 가능하게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능성들을 구현하는 애플리케이션들의 부담을 없애고, 따라서 애플리케이션 개발을 간단화하고 마케팅하기 위한 비용 및 시간을 줄인다. 서비스 레이어(22 및 22')는 또한 M2M 애플리케이션들(20 및 20')이 서비스 레이어(22 및 22')가 제공하는 서비스들과 관련하여 다양한 네트워크들(12 및 12')을 통해 통신하는 것을 가능하게 한다.

본 출원의 방법들은 서비스 레이어(22 및 22')의 일부로서 구현될 수 있다. 서비스 레이어(22 및 22')는 한 세트의 API들(Application Programming Interfaces) 및 기본 네트워킹 인터페이스들을 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. ETSI M2M과 oneM2M 양자 모두는 본 출원의 접속 방법들을 포함할 수 있는 서비스 레이어를 사용한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(Device SCL)이라고 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(여기서 이것은 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 한 세트의 CSF들(Common Service Functions)(즉, 서비스 능력들)을 지원한다. CSF들 중의 한 세트의 하나 이상의 특정 타입들의 인스턴스화는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션 특정적 노드)상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭된다. 또한, 본 출원의 접속 방법들은, 본 출원의 접속 방법들과 같은 서비스들을 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시되는 시스템들 및 방법들과 관련하여 사용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 다른 개시된 시스템들 및 방법들과 관련하여 사용될 수 있다.

일 실시예에서, 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들은, 도 15b에 도시되는 바와 같이, M2M 서버, M2M 게이트웨이 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 레이어 인스턴스 내에서 호스팅될 수 있다. 예를 들어, 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들은 M2M 서비스 레이어 인스턴스 내에 또는 기존 서비스 능력 내의 서브-기능으로서 개별 서비스 능력을 포함할 수 있다.

M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 건강관리, 접속된 홈, 에너지 관리, 자산 추적, 및 보안과 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다.

일반적으로, 서비스 레이어들(22 및 22')은 API들(Application Programming Interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어를 정의한다. ETSI M2M 및 oneM2M 아키텍처들 양자 모두는 서비스 레이어를 정의한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양하고 상이한 노드들에 구현될 수 있다. 예를 들어, 서비스 레이어의 인스턴스는 M2M 디바이스(여기서, 이것은 디바이스 SCL(DSCL)이라고 지칭됨), 게이트웨이(여기서 이것은 게이트웨이 SCL(GSCL)이라고 지칭됨) 및/또는 네트워크 노드(여기서 이것은 네트워크 SCL(NSCL)이라고 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 레이어는 한 세트의 CSF들(Common Service Functions)(즉, 서비스 능력들)을 지원한다. CSF들 중의 한 세트의 하나 이상의 특정 타입들의 인스턴스화는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션 특정적 노드)상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭될 수 있다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)를 위한 아키텍처를 정의하였다. 그러한 아키텍처에서, 이것이 제공하는 서비스 레이어와 서비스 능력들은 SCS(Service Capability Server)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL 또는 NSCL에서, 3GPP MTC 아키텍처의 SCS(Service Capability Server)에서, 또는 oneM2M 아키텍처의 CSF 또는 CSE에서, 또는 네트워크의 일부 다른 노드에서 구현되든 간에, 서비스 레이어의 인스턴스는 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들 포함하는, 네트워크에서의 하나 이상의 독립형 노드들 상에서 실행되는 논리적 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서, 또는 하나 이상의 기존 노드들의 일부로서 구현될 수 있다. 예로서, 서비스 레이어 또는 그 컴포넌트의 인스턴스는 이하 설명되는 도 15c 또는 도 15d에 도시되는 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어 형태로 구현될 수 있다.

또한, 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들은 본 출원의 서비스들을 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 15c는 M2M 디바이스(18), M2M 게이트웨이 디바이스(14), M2M 서버 등과 같은 M2M 네트워크 노드(30)의 예시적 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들을 실행하거나 또는 포함할 수 있다. 디바이스(30)는 도 15a 및 도 15b에 도시된 바와 같은 M2M 네트워크의 일부 또는 비-M2M 네트워크의 일부일 수 있다. 도 15c에 도시되는 바와 같이, M2M 노드(30)는 프로세서(32), 비-이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치 패드, 및/또는 표시자들(42), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 송수신기(34) 및 송신/수신 엘리먼트(36)와 같은 통신 회로를 또한 포함할 수 있다. M2M 노드(30)는 실시예와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 부분 조합을 포함할 수 있다는 점이 이해될 것이다. 이러한 노드는 본 명세서에 설명되는 SMSF 기능성을 구현하는 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 연관되는 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 IC(integrated circuit), 상태 머신 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 요구되는 기능들을 수행하기 위해 노드의 메모리(예를 들어, 메모리(44) 및/또는 메모리(46))에 저장되는 컴퓨터 실행가능 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션 레이어 프로그램들(예를 들어, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 예를 들어, 액세스 레이어 및/또는 애플리케이션 레이어에서와 같이, 인증, 보안 키 합의, 및/또는 암호화 작업들과 같은 보안 작업들을 또한 수행할 수 있다.

도 15c에 도시되는 바와 같이, 프로세서(32)는 그것의 통신 회로(예를 들어, 송수신기(34) 및 송신/수신 엘리먼트(36))에 연결된다. 프로세서(32)는, 컴퓨터 실행가능 명령어들의 실행을 통해서, 노드(30)로 하여금 그것이 접속되는 네트워크를 통해 다른 노드들과 통신하게 하도록 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서 및 청구범위에서 설명되는 송신 및 수신 단계들을 수행하도록 통신 회로를 제어할 수 있다. 도 15c가 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 묘사하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 점이 이해될 것이다.

송신/수신 엘리먼트(36)는 신호들을 M2M 서버들, 게이트웨이들, 디바이스 등을 포함하는 다른 M2M 노드들에 송신하거나, 또는 이들로부터 수신하도록 구성될 수 있다. 예를 들어, 실시예에서, 송신/수신 엘리먼트(36)는 RF 신호들을 송신 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 엘리먼트(36)는 WLAN, WPAN, 셀룰러 등과 같이, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 실시예에서, 송신/수신 엘리먼트(36)는, 예를 들어 IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 엘리먼트(36)는 RF 신호 및 광 신호 양자 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 송신/수신 엘리먼트(36)가 단일 엘리먼트로서 도 15c에 묘사되지만, M2M 노드(30)는 임의의 수의 송신/수신 엘리먼트들(36)을 포함할 수 있다. 보다 구체적으로, M2M 노드(30)는 MIMO 기술을 이용할 수 있다. 따라서, 실시예에서, M2M 노드(30)는 무선 신호들을 송신 및 수신하기 위한 2개 이상의 송신/수신 엘리먼트들(36)(예를 들어, 다수의 안테나들)을 포함할 수 있다.

송수신기(34)는 송신/수신 엘리먼트(36)에 의해 송신될 신호들을 변조하고, 송신/수신 엘리먼트(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 전술된 바와 같이, M2M 노드(30)는 멀티-모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는, M2M 노드(30)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT들을 통해 통신할 수 있게 하기 위한 다수의 송수신기들을 포함할 수 있다.

프로세서(32)는 비-이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적합한 메모리로부터 정보를 액세스하거나 거기에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 위에 설명된 바와 같이 그 메모리에 세션 콘텍스트를 저장할 수 있다. 비-이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터 상에서와 같이, M2M 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터 정보를 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 레이어 세션 마이그레이션 또는 공유의 상태를 반영하거나 또는 사용자로부터 입력을 획득하거나 또는 노드의 세션 마이그레이션 또는 공유 능력들 또는 설정들에 관한 정보를 사용자에게 디스플레하기 위해 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 보여줄 수 있다. 본 개시내용은 oneM2M 실시예에서 RESTful 사용자/애플리케이션 API를 정의한다. 디스플레이 상에 보여질 수 있는 그래픽 사용자 인터페이스는 본 명세서에 설명되는 기본 서비스 레이어 세션 기능성을 통해 사용자가 E2E 세션, 또는 그것의 마이그레이션 또는 공유를 대화식으로 수립하고 관리하게 하도록 API 위에 층을 이룰 수 있다.

프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, M2M 노드(30)의 다른 컴포넌트들에게 전력을 분배 및/또는 제어하도록 구성될 수 있다. 전원(48)은 M2M 노드(30)에 전력을 공급하기 적합한 임의의 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리들(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.

프로세서(32)는 또한 GPS 칩셋(50)에 연결될 수 있으며, 이것은 M2M 노드(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된다. M2M 노드(30)는 실시예와 일관성을 유지하면서 임의의 적합한 위치-결정 방법에 의해 위치 정보를 취득할 수 있다는 점이 이해될 것이다.

프로세서(32)는 다른 주변기기들(52)에 또한 결합될 수 있으며, 이러한 주변기기들은, 추가적인 특징들, 기능성, 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈들을 포함할 수 있다. 예를 들어, 주변기기들(52)은 가속도계, e-나침반, 위성 송수신기, 센서, (사진들 또는 비디오를 위한) 디지털 카메라, USB(universal serial bus) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 15d는 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드와 같은 M2M 네트워크의 하나 이상의 노드들을 구현하는데 또한 사용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 이러한 소프트웨어가 어디에 또는 어떤 수단에 의해 저장되고 액세스되든 간에, 소프트웨어의 형태일 수 있는 컴퓨터 판독가능 명령어들에 의해 주로 제어될 수 있다. 컴퓨팅 시스템(90)은 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들을 실행하거나 또는 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어 M2M 디바이스, 사용자 장비, 게이트웨이, UE/GW 또는 모바일 케어 네트워크의 노드들을 포함하는 임의의 다른 노드들, 서비스 레이어 네트워크 애플리케이션 제공자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 동작하게 하도록 CPU(central processing unit)(91)와 같은 프로세서 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 또는 CPU(91)를 보조하는, 주 CPU(91)와는 별개인, 선택적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 세션 자격증명을 수신하거나 세션 자격증명을 기반으로 인증하는 것과 같이, E2E M2M 서비스 레이어 세션들에 대해 개시되는 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

동작에 있어서, CPU(91)는 명령어들을 페치, 디코드, 및 실행하고, 컴퓨터의 주 데이터 이송 경로인 시스템 버스(80)를 통해 다른 리소스들로/로부터 정보를 이송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90) 내의 컴포넌트들을 접속하고, 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는데이터를 전송하기 위한 데이터 라인들, 어드레스들을 전송하기 위한 어드레스 라인들, 및 인터럽트들을 전송하고 시스템 버스를 동작시키기 위한 제어 라인들을 통상적으로 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.

시스템 버스(80)에 연결되는 메모리 디바이스들은 RAM(random access memory)(82) 및 ROM(read only memory)(93)을 포함한다. 이러한 메모리들은 정보가 저장 및 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 어드레스들을 물리적 어드레스들로 변환하는 어드레스 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 사용자 프로세스들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑되는 메모리만 액세스할 수 있고; 이것은 프로세스들 사이의 메모리 공유가 마련되지 않는 한 다른 프로세스의 가상 어드레스 공간 내의 메모리를 액세스할 수 없다.

또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변기기들로 명령어들을 통신하는 것을 담당하는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 디스플레이하는데 사용된다. 이러한 시각적 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다.

또한, 컴퓨팅 시스템(90)은 도 15a 및 도 15b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하여, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는데 사용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.

본 명세서에 설명되는 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모든 것은 컴퓨터 판독가능 스토리지 매체에 저장된 컴퓨터 실행가능 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있다는 점이 이해되며, 이 명령어들은, 예를 들어 M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크의 노드들, 서비스 레이어 또는 네트워크 애플리케이션 제공자 중 임의의 것의 작업들을 포함하는, 위에 설명된 단계들, 작업들 또는 기능들 중 임의의 것이 그러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 외부 서비스들(606)과 같은 논리적 엔티티들, 센서(602), M2M 서비스 레이어(604), 애플리케이션(608), CSE(806), 웹 서비스(804 및 1312), oneM2M 서비스 오브젝트 공급 툴(802), 서비스 액세스 인에이블먼트(902), 서비스 컴포넌트 서비스 액세스 인에블먼트(1202), MQTT 클라이언트 센서(1316), 서비스 오브젝트 MQTT 확장(1306), MQTT 브로커(1302), 토픽 디렉토리 MQTT 확장(1310), MQTT 클라이언트 애플리케이션(1318), 및 서비스 오브젝트 공급 툴(1314)에 대한 논리적 엔티티들뿐만 아니라 인터페이스들(1402, 1404 및 1406)과 같은 인터페이스들을 생성하기 위한 논리적 엔티티들은 컴퓨터 판독가능 스토리지 매체 상에 저장되는 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능 스토리지 매체는 정보의 저장을 위한 임의의 비-일시적(즉, 유형의 또는 물리적) 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비-이동식 매체를 포함하지만, 이러한 컴퓨터 판독가능 스토리지 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능 스토리지 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있는 그리고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형의 또는 물리적 매체를 포함한다.

도면들에 도시되는 바와 같이, 본 개시내용의 주제의 바람직한 실시예들을 설명함에 있어서, 구체적인 용어가 명료성을 위해 채택된다. 그러나, 청구되는 주제는 그와 같이 선택되는 구체적인 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 구체적인 엘리먼트가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 할 것이다.

본 작성 명세서는 최상의 모드를 포함하는 본 발명을 개시하고, 또한 관련분야에서의 임의의 숙련된 자가 임의의 디바이스들 또는 시스템들을 제작하고 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예를 사용한다. 본 발명의 특허를 받을 수 있는 범주는 청구범위에서 정의되며, 관련분야에서의 숙련된 자들에게 발생하는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 청구항들의 문자 그대로의 표현과 상이하지 않은 엘리먼트들을 가지는 경우, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가적 엘리먼트들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (18)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 노드로서,
   서버가 자신의 통신 회로를 통해 통신 네트워크에 접속되고, 상기 노드는 상기 노드의 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하며, 상기 컴퓨터 실행가능 명령어들은, 상기 서버의 프로세서에 의해 실행될 때, 상기 노드로 하여금:
   서비스 레이어를 사용하여 외부 서비스에 대한 액세스를 제공하게 하고;
   상기 서비스 레이어를 통해 상기 외부 서비스로부터 애플리케이션에 서비스를 제공하게 하는- 상기 애플리케이션은 상기 외부 서비스를 독립적으로 접촉하지 않음 - 노드.
2. 제1항에 있어서,
   상기 서비스 레이어는 oneM2M 서비스 레이어인 노드.
3. 제2항에 있어서,
   상기 oneM2M 서비스 레이어는 CSE(Common Services Entity)에서의 서비스 액세스 인에이블먼트 CSF(Common Service Function)을 사용하는 노드.
4. 제1항에 있어서,
   상기 노드는 상기 외부 서비스에 의해 제공되는 API(Application Programming Interface)를 상기 서비스 레이어에서의 서비스 레이어 리소스에 매핑하는 노드.
5. 제4항에 있어서,
   상기 서비스 레이어 리소스는 상기 애플리케이션에 의해 액세스되는 노드.
6. 제1항에 있어서,
   상기 노드는 상기 애플리케이션에 대한 상기 서비스 레이어로부터 상기 외부 서비스에 데이터를 프록시하는 노드.
7. 제6항에 있어서,
   상기 노드는 상기 서비스 레이어에서 상기 외부 서비스로부터의 결과들을 수신하고 상기 결과들을 상기 애플리케이션에 이용가능하게 하는 노드.
8. 제1항에 있어서,
   상기 노드는 상기 서비스 레이어에서 외부 서비스들의 발견을 허용하는 노드.
9. 네트워크에 접속되는 서버에 의한 사용을 위한 방법으로서- 상기 서버는 프로세서 및 메모리를 포함하고, 상기 서버는 상기 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하며, 상기 컴퓨터 실행가능 명령어들은, 상기 프로세서에 의해 실행될 때, 상기 네트워크에서의 서버의 기능들을 수행함 -,
   서비스 레이어를 사용하여 외부 서비스에 대한 액세스를 제공하는 단계; 및
   상기 서비스 레이어를 통해 상기 외부 서비스로부터 애플리케이션에 서비스를 제공하는 단계- 상기 애플리케이션은 상기 외부 서비스를 독립적으로 접촉하지 않음 -를 더 포함하는 방법.
10. 제9항에 있어서,
    상기 서비스 레이어는 oneM2M 서비스 레이어인 방법.
11. 제10항에 있어서,
    상기 oneM2M 서비스 레이어는 CSE(Common Services Entity)에서의 서비스 액세스 인에이블먼트 CSF(Common Service Function)을 사용하는 방법.
12. 제9항에 있어서,
    상기 외부 서비스에 의해 제공되는 API(Application Programming Interface)를 상기 서비스 레이어에서의 서비스 레이어 리소스에 매핑하는 단계를 더 포함하는 방법.
13. 제12항에 있어서,
    상기 서비스 레이어 리소스는 상기 애플리케이션에 의해 액세스되는 방법.
14. 제9항에 있어서,
    상기 애플리케이션에 대한 상기 서비스 레이어로부터 상기 외부 서비스에 데이터를 프록시하는 단계를 더 포함하는 방법.
15. 제14항에 있어서,
    상기 서비스 레이어에서 상기 외부 서비스로부터의 결과들을 수신하는 단계 및 상기 결과들을 상기 애플리케이션에 이용가능하게 하는 단계를 더 포함하는 방법.
16. 제9항에 있어서,
    상기 서비스 레이어에서 외부 서비스들의 발견을 허용하는 단계를 더 포함하는 방법.
17. 프로세서, 메모리, 및 통신 회로를 포함하는 노드로서,
    상기 노드는 자신의 통신 회로를 통해 통신 네트워크에 접속되고, 상기 노드는 상기 노드의 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하며, 상기 컴퓨터 실행가능 명령어들은, 서버의 프로세서에 의해 실행될 때, 상기 서버로 하여금:
    서비스 레이어를 사용하여 외부 서비스에 액세스하고;
    상기 서비스 레이어를 통해 상기 외부 서비스로부터 데이터를 수신하는 애플리케이션을 구현하게 하는 노드.
18. 네트워크에 접속되는 노드에 의한 사용을 위한 방법으로서- 상기 노드는 프로세서 및 메모리를 포함하고, 상기 노드는 상기 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하며, 상기 컴퓨터 실행가능 명령어들은, 상기 프로세서에 의해 실행될 때, 상기 네트워크에서의 애플리케이션의 기능들을 수행함 -,
    서비스 레이어를 사용하여 외부 서비스에 액세스하는 단계; 및
    상기 서비스 레이어를 통해 상기 외부 서비스로부터 데이터를 수신하는 단계
    를 포함하는 방법.

Images