KR20170141746A - M2m 서비스를 추가하기 위한 디바이스 및 방법 - Google Patents

Abstract

본 출원은 서비스를 추가하도록 구성되는 네트워크 상의 디바이스에 관한 것이다. 이러한 디바이스는 프로세서에 동작 가능하게 연결되는 메모리를 포함한다. 이러한 프로세서는 서비스 인에이블먼트 정책을 구성하도록 적응된다. 이러한 프로세서는 서비스 제공자로부터 서비스를 추가하라는 요청을 수신하도록 또한 적응된다. 이러한 프로세서는 서비스를 추가하기 위한 서비스 인에이블먼트 정책을 체크하도록 적응된다. 이러한 프로세서는 서비스 인에이블먼트 정책과 호스트 선택 기준을 조화시키기 위해 다른 디바이스와 협력하도록 또한 적응된다. 또한, 이러한 프로세서는 서비스 제공자에게 회신을 전송하도록 적응된다. 본 출원은 또한 서비스를 추가하기 위한 방법에 관한 것이다.

Description

M2M 서비스를 추가하기 위한 디바이스 및 방법

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

본 출원은 2015년 4월 23일자 출원된 미국 임시 출원 제62/151,841호에 대한 우선권을 주장하며, 그 개시내용은 전부가 본 명세서에 참조로 원용된다.

<기술분야>

본 출원은 서비스를 추가할 서비스 노드를 선택하기 위한 장치들 및 방법들에 관한 것이다. 보다 특정하게는, 본 출원은 서비스 인에이블먼트 정책들 및/또는 서비스 노드 선택 기준에 기초하여 서비스의 추가를 향상시키는 것에 관한 것이다.

일반적으로, M2M 게이트웨이들은 신규 서비스를 추가하라는 ASP(Application Service Provider)로부터의 요청을 거절한다. 이것은 M2M 게이트웨이들이 특정 서비스 기능성을 지원할 수 없기 때문이다. 결국, ASP들은 2개의 선택사항들을 갖는다. 이들은 M2M에 머무르고 M2M이 서비스 기능성을 갖는 기존 서비스들을 호스팅하거나, 또는 신규 서비스의 기능성을 지원하는 신규 M2M 게이트웨이에 등록할 수 있다. 그러나, M2M 게이트웨이가 등록되는 M2M 서버는 신규 서비스를 호스팅할 수 있을 것이다. M2M 게이트웨이가 M2M 서버에 요청을 전달하도록 안내하는데 도움이 되는 프로토콜들이 없다.

어떤 서비스 레이어 엔티티가 ASP에 의해 요청된 신규 서비스를 추가해야 하는지 평가하기 위해서는 다양한 인자들이 고려되어야 한다. 이것은 다수의 신규 서비스들이 요청될 때 더욱 관련이 있다. 현재, 하나 이상의 ASP들이 하나 이상의 M2M 게이트웨이들에서 서비스들을 추가할 것을 요청할 때, 각각의 M2M 게이트웨이는 신규 서비스만 추가할 수 있다. 그러나, 특정 M2M 게이트웨이는 액세스의 용이성 및 신규 서비스의 이용을 포함하는 인자들에 기초하는 최적의 선택이 아닐 수 있다. 그러나, 상이한 인자들을 고려하여 신규 서비스를 추가하기 위해 서비스 레이어 엔티티를 선택하기 위한 프로토콜들이 없다.

본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들의 선택을 단순화된 형태로 소개하도록 제공된다. 본 내용은 청구된 주제의 범위를 제한하려고 의도되는 것은 아니다. 전술한 요구들은, 하나 이상의 인자들을 고려하여 신규한 것을 추가하기 위해 하나 이상의 서비스 노드들을 선택하기 위한 장치, 시스템 및 방법에 관한 본 출원에 의해, 크게 충족될 것이다.

본 출원의 일 양상에서는, 사용자 디바이스가 설명된다. 이러한 디바이스는 서비스 제공자로부터의 서비스를 추가하기 위한 명령어들을 저장하는 비-일시적 메모리를 포함한다. 이러한 디바이스는 메모리에 동작 가능하게 연결되는 프로세서를 포함한다. 이러한 프로세서는 서비스 인에이블먼트 정책을 구성하도록 적응된다. 이러한 프로세서는 서비스 제공자로부터 서비스를 추가하라는 요청을 수신하도록 또한 적응된다. 이러한 프로세서는 서비스를 추가하기 위한 서비스 인에이블먼트 정책을 체크하도록 적응된다. 이러한 프로세서는 서비스 인에이블먼트 정책과 호스트 선택 기준을 조화시키기 위해 다른 디바이스와 협력하도록 적응된다. 또한, 이러한 프로세서는 서비스 제공자에게 회신을 전송하도록 적응된다.

본 출원은 또한 서비스를 추가하기 위한 방법에 관한 것이다. 본 방법은 서비스 인에이블먼트 정책을 구성하는 단계를 포함한다. 본 방법은 서비스 제공자로부터 서비스를 추가하라는 요청을 수신하는 단계를 또한 포함한다. 본 방법은 서비스를 추가하기 위한 서비스 인에이블먼트 정책을 체크하는 단계를 또한 포함한다. 또한, 본 방법은 서비스 제공자에게 회신을 전송하는 단계를 포함한다. 일 실시예에 따르면, 본 방법은 서비스 노드 선택을 용이하게 하기 위한 기준을 수신하는 단계를 더 포함한다. 다른 실시예에 따르면, 본 방법은 서비스 인에이블먼트 정책과 기준을 조화시키는 단계를 포함한다. 또 다른 실시예에서, 본 방법은 서비스 인에이블먼트 정책과 기준을 충족하는 서비스 노드를 결정하는 단계를 포함한다.

본 발명의 상세한 설명이 더 잘 이해될 수 있도록 하기 위해, 그리고 관련분야에 대한 본 발명의 기여가 더 잘 인식될 수 있도록 하기 위해, 본 발명의 특정 실시예들이 다소 광범위하게 이와 같이 약술되었다.

본 출원의 보다 견고한 이해를 용이하게 하기 위해서, 동일한 엘리먼트들은 동일한 번호들로 참조되는 첨부 도면들에 대한 참조가 이제 이루어진다. 이러한 도면들은 본 출원을 제한하는 것으로 해석되어서는 안 되며, 단지 예시적인 것으로 의도된다.
도 1a는 M2M(machine-to machine) 또는 IoT 통신 시스템의 실시예를 도시한다.
도 1b는 M2M 서비스 플랫폼의 본 출원의 실시예를 도시한다.
도 1c는 예시적인 M2M 디바이스의 시스템 도면의 본 출원의 실시예를 도시한다.
도 1d는 예시적인 컴퓨팅 시스템의 블록도의 본 출원의 실시예를 도시한다.
도 2는 본 출원의 실시예에 따른 네트워크 내의 서비스 레이어 배치를 도시한다.
도 3은 본 출원의 실시예에 따른 oneM2M 서비스 레이어 기능적 아키텍처(RoA)를 도시한다.
도 4는 본 출원의 oneM2M 서비스 아키텍처(SoA)를 도시한다.
도 5는 본 출원의 실시예에 따른 SEF(service enabler function) 아키텍처를 도시한다.
도 6a는 본 출원의 실시예에 따른 공통 서비스 엔티티에서의 인에이블러 기능들을 도시한다.
도 6b는 본 출원의 실시예에 따른 서비스 인에이블러 기능에 의해 신규 서비스를 추가하기 위한 프로시저를 도시한다.
도 7은 본 출원의 다른 실시예에 따른 애플리케이션 서비스 제공자에 의해 제공되는 신규 서비스를 추가하기 위한 프로시저를 도시한다.
도 8은 본 출원의 다른 실시예에 따른 서비스 제공자에 의해 제공되는 신규 서비스를 추가하기 위한 프로시저를 도시한다.
도 9는 본 출원의 실시예에 따른 서비스 제공자에 의해 서비스 인에이블먼트 정책을 구성/업데이트하기 위한 프로시저를 도시한다.
도 10은 본 출원의 실시예에 따른 서비스 레이어 네트워크를 도시한다.
도 11은 본 출원의 실시예에 따른 협력을 위한 프로시저를 도시한다.
도 12는 본 출원의 실시예에 따라 인에이블되지 않을 때 협력을 위한 프로시저를 도시한다.
도 13은 본 출원의 실시예에 따른 신규 서비스를 위한 호스팅 노드를 선택하는 방법을 도시한다.
도 14는 본 출원의 실시예에 따른 사후 서비스 노드 선택을 위한 방법을 도시한다.
도 15a는 본 출원의 실시예에 따른 다수의 신규 서비스를 추가하기 위한 프로시저들을 종합하기 위한 방법을 도시한다.
도 15b는 본 출원의 다른 실시예에 따른 다수의 신규 서비스를 추가하기 위한 프로시저들을 종합하기 위한 방법을 도시한다.
도 16은 본 출원의 실시예에 따른 oneM2M 기능적 아키텍처에서의 협력 및 서비스 노드 선택 기능들을 도시한다.
도 17은 본 출원의 실시예에 따른 서비스 인에이블먼트 정책 리소스 구조들을 도시한다.
도 18은 본 출원의 실시예에 따른 oneM2M 서비스 아키텍처에서의 협력 및 서비스 노드 선택 기능들을 도시한다.
도 19는 본 출원의 실시예에 따른 다른 서비스 인에이블먼트 정책 리소스의 구조를 도시한다.
도 20은 본 출원의 실시예에 따른 신규 서비스를 인에이블하기 위한 구성의 사용자 인터페이스를 도시한다.

예시적인 실시예의 상세한 설명이 본 명세서에서 다양한 도면들, 실시예들 및 양상들을 참조하여 논의될 것이다. 이러한 설명이 가능한 구현들의 상세한 예들을 제공하더라도, 이러한 상세사항들은 예들로 의도되는 것이고 따라서 본 출원의 범위를 제한하지 않는다는 점이 이해되어야 한다.

본 명세서에서 "일 실시예(one embodiment)", "실시예(an embodiment)", "하나 이상의 실시예들(one or more embodiments)", "양상(an aspect)" 등에 대한 지칭은 그 실시예와 연계하여 설명되는 특정한 특징, 구조, 또는 특성이 본 개시내용의 적어도 하나의 실시예에 포함된다는 점을 의미한다. 더욱이, 본 명세서의 다양한 곳들에서의 "실시예(embodiment)"라는 용어가 반드시 동일한 실시예를 지칭하는 것은 아니다. 즉, 일부 실시예들에 의해서는 드러나지만 다른 실시예에 의해서는 그렇지 않을 수 있는 다양한 특징들이 설명된다.

본 출원은 하나 이상의 인자들을 고려하여 신규 서비스를 추가하기 위해 하나 이상의 서비스 노드들을 선택하기 위한 시스템 및 기술들을 설명한다. 일 실시예에 따르면, 하나 이상의 규칙들을 포함하는 서비스 인에이블먼트 정책에 기초하여 서비스가 추가된다. 하나의 특정 실시예에서, 정책은 협력을 수반한다. 다른 특정 실시예에서, 정책은 서비스 노드 선택을 수반한다. 또 다른 특정 실시예에서, 정책은 종합을 수반한다. 또 다른 특정 실시예에서, 정책은 서비스 공급을 수반한다. 위에 설명된 정책들은 OneM2M에서의 애플리케이션 엔티티일 수 있는 ASP에 의해 정의될 수 있다. 대안적으로, 정책들은 OneM2M에서의 CSE(common service entity)에 의해 정의될 수 있다.

다른 실시예에 따르면, 서비스 노드 선택은 신규 서비스를 추가하기 위한 하나 이상의 기준을 포함할 수 있다. 예를 들어, 이러한 기준은 서비스 발견의 용이성, 이용의 용이성, 로드 밸런스 등 중 하나 이상을 포함할 수 있다. 또 다른 실시예에 따르면, 본 출원은 서비스 제공자에 의해 소유되는 서비스 레이어 내의 서비스 레이어 엔티티들 사이의 동적인 정책 구성 프로시저들을 설명한다. 다른 실시예에서, 본 출원은 ASP와, 예를 들어, 서비스 레이어 플랫폼의 소유자와 같은, 서비스 제공자 사이의, 그리고 서비스 레이어 엔티티들 사이의 협력 프로시저들을 설명한다.

또 다른 실시예에서, 본 출원은 서비스 노드 선택 프로토콜들을 설명한다. 이러한 프로토콜들은 신규 서비스를 추가하기 위한 서비스 노드를 선택하는데 이용된다. 이것은 위에 언급된 정책들에 기초할 수 있다. 이러한 선택은 또한 서비스 노드 선택 기준에 기초할 수 있다.

또 다른 실시예에 따르면, 신규 서비스들을 추가하는 성능을 더욱 최적화하기 위해 메시지들을 종합하기 위한 프로토콜들이 설명된다.

두문자어들 (Acronyms)

아래의 표 1에 제공되는 바와 같이 본 출원 전반적으로 이하의 두문자어들이 사용될 것이다.

이하의 용어들은 본 출원 전반적으로 사용될 것이고, 관련분야에서 이해되는 바와 같은 그들의 관례적이고 통상적인 정의들이 아래에 제공된다:

M2M 애플리케이션 서비스: M2M 애플리케이션의 서비스 로직을 통해 실현되고, 사용자 또는 M2M 애플리케이션 서비스 제공자에 의해 동작됨.

M2M 애플리케이션 서비스 제공자: 예를 들어, OneM2M에서의 Mca를 통해 ASP와 서비스 제공자 사이에 상호작용을 제공하는 회사 또는 애플리케이션인 엔티티.

M2M 서비스(서비스): 하나 이상의 M2M 애플리케이션 서비스들 및 하나 이상의 M2M 공통 서비스들을 포함함. M2M 서비스는 서비스라고도 지칭될 수 있다.

네트워크 노드: 네트워크 내의 어드레스 지정 가능한 네트워크. 네트워크 노드는 네트워크에서의 물리적인, 예를 들어, 디바이스, 게이트웨이 또는 서버, 또는 가상의 엔티티, 예를 들어 VM일 수 있음.

서비스 노드: 하나 이상의 서비스 능력들을 지원하는 서비스 레이어를 호스팅하는 네트워크 노드.

서비스 레이어: API들(Application Programming Interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어.

서비스 레이어 엔티티: 서비스 레이어에서 서비스 능력들의 세트가 있는 미들웨어를 나타내는 논리적 오브젝트.

서비스 능력: 서비스 레이어에 의해 지원되는 특정 타입의 서비스.

서비스 능력 레이어: 서비스 레이어에 대한 ETSI M2M 용어.

공통 서비스 기능: 서비스 능력에 대한 OneM2M 용어.

공통 서비스 엔티티: 서비스 레이어에 대한 OneM2M 용어.

서비스 노드 선택: 신규 서비스를 호스팅하기 위한 하나 이상의 다수의 서비스 노드들을 선택하기 위한 프로세스. 선택된 서비스 노드(들)는 다른 서비스 레이어 엔티티들에 대한 액세스 및 신규 서비스를 이용하기 위한 애플리케이션을 제공할 것이다.

서비스 레이어 클라이언트(Service Layer Client): 서비스 레이어에 의해 제공되는 서비스들을 액세스하고 이들을 이용하도록 구성되는 엔티티. 클라이언트는 애플리케이션, 예를 들어, oneM2M 서비스 레이어에서의 AE, 또는 서비스 레이어 엔티티, 예를 들어, oneM2M 용어로 CSE일 수 있음.

M2M 서비스 제공자: 예를 들어, M2M 공통 서비스들을 M2M 애플리케이션 서비스 제공자 또는 사용자에게 제공하는 회사인 엔티티. 서비스 제공자는 CSE들과 같은 서비스 플랫폼들을 소유하고 제어함. 동작은 Mcc 및 Mcc'를 통함.

플랫폼들

본 출원은 AEP들(application enablement platforms) 및 CDP들(connected device platforms) 양자 모두에 대한 플랫폼 기능성 및 지원을 커버하도록 의도된다. AEP들은 애플리케이션 인에블먼트 레이어 및 World Wide Web과 인터넷을 포함하는 서비스 레이어를 포함한다. 애플리케이션 인에블먼트 레이어는 이에 제한되는 것은 아니지만 이하를 포함한다: (i) 서비싱 API들, 규칙들/스크립팅 엔진; (ii) SDK 프로그래밍 인터페이스; 및 (iii) 엔터프라이즈 시스템들 통합. 애플리케이션 인에블먼트 레이어는 이에 제한되는 것은 아니지만 발견, 분석, 콘텍스트 및 이벤트들을 포함하는 부가 가치 서비스들을 또한 포함할 수 있다. 월드 와이드 웹 및 인터넷을 포함하는 서비스 레이어는, 예를 들어, 분석, 과금(billing), 원시 API들, 웹 서비스 인터페이스들, 시멘틱 데이터 모델들, 디바이스/서비스 발견, 디바이스 관리, 보안, 데이터 수집, 데이터 적응, 종합, 이벤트 관리, 콘텍스트 관리, 최적화된 접속성 및 전송, M2M 게이트웨이, 및 어드레싱 및 식별을 포함할 수 있다. CDP들은 접속성 분석, 사용 분석/보고/경고들, 정책 제어, 자동화된 공급, SIM 활성화/비활성화, 및 가입 활성화/비활성화를 포함할 수 있다.

일반적 아키텍처

도 1a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 적으로, M2M 기술들은 IoT/WoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, 게이트웨이 또는 서비스 플랫폼은 IoT/WoT의 컴포넌트 뿐만 아니라 IoT/WoT 서비스 레이어 등일 수 있다.

도 1a에 도시되는 바와 같이, 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), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 1a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 프록시가 있는 백본 라우터와 같은 M2M 게이트웨이들(14), 및 LLN 디바이스들과 같은 단말 디바이스들(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)에 전송될 수 있고 그로부터 수신될 수 있다. 일 실시예에서, 서비스 레이어(22)는 PCE일 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN, 예를 들어, Zigbee, 6LoWPAN, Bluetooth, 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 1b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)는 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22)는 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 레이어(22)는 하나 이상의 서버들, 컴퓨터들 등에 의해 구현될 수 있다. M2M 서비스 레이어(22)는 M2M 단말 디바이스들(18), M2M 게이트웨이 디바이스들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 레이어(22)의 기능들은 다양한 방식들로 구현될 수 있다. 예를 들어, M2M 서비스 레이어(22)는 웹 서버에서, 셀룰러 코어 네트워크에서, 클라우드, M2M 게이트웨이에서 등으로 구현될 수 있다.

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

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

M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 동작하는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geo-fencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다. 또한, M2M 서비스 레이어는 본 출원에서 논의되고 도면에 도시되는 바와 같이 모바일 디바이스들 및 M2M 서버들/게이트웨이들과 같은 다른 디바이스들과 인터페이스하도록 또한 구성될 수 있다.

본 출원의 양상에 따르면, 등록을 관리하는 방법이 서비스 레이어의 일부로서 구현될 수 있다. 이러한 서비스 레이어는 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 네트워크의 일부로서 구현될 수 있다.

도 1c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적 M2M 디바이스(30)의 시스템 도면이다. 도 1c에 도시되는 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드/표시기(들)(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(40)는 실시예와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. 이러한 디바이스는 센서 데이터(sensory data)의 내장된 의미론적 명명을 위해 개시된 시스템들 및 방법들을 사용하는 디바이스일 수 있다. M2M 디바이스(30)는 또한, 예를 들어 본 출원에서 설명되고 도면에 도시되는 바와 같은 모바일 디바이스들을 포함하는 다른 디바이스들과 함께 사용될 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 관련되는 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 IC(integrated circuit), 상태 머신 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 송수신기(34)에 연결될 수 있고, 이는 송신/수신 엘리먼트(36)에 연결될 수 있다. 도 1c가 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 묘사하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 점이 이해될 것이다. 프로세서(32)는 애플리케이션-레이어 프로그램, 예를 들어 브라우저들, 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신을 수행할 수 있다. 프로세서(32)는, 예를 들어 액세스-레이어 및/또는 애플리케이션 레이어에서와 같이, 인증, 보안 키 합의, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

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

또한, 도 1c에는 송신/수신 엘리먼트(36)가 단일 엘리먼트로서 묘사되지만, 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)와 같은 임의의 타입의 적합한 메모리로부터 정보를 액세스하거나 거기에 데이터를 저장할 수 있다. 비-이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터 정보를 액세스하거나 거기에 데이터를 저장할 수 있다.

프로세서(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) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 1d는, 예를 들어, 도 1a 및 도 1b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독 가능 명령어들에 의해 제어될 수 있으며, 이들은 소프트웨어의 형태로 있을 수 있거나, 어디에든, 또는 어떤 수단에 의해서든 이러한 소프트웨어가 저장되거나 액세스된다. 이러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 행하게 하도록 CPU(central processing unit)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 지원하는, 메인 CPU(91)와는 별개인 선택적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 내장된 의미론적 명칭들이 있는 센서 데이터에 대한 쿼리들 같은, 내장된 의미론적 명명을 위한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성, 및 처리할 수 있다.

동작에 있어서, 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)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다. 디스플레이(86)는, 내장된 의미론적 명칭들을 사용하여 파일들 또는 폴더들에 센서 데이터를 디스플레이할 수 있다. 또한, 컴퓨팅 시스템(90)은 도 1a 및 도 1b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다. 디스플레이(86)는, 예를 들어, 이하 보다 상세히 설명되는 도 20에 도시되는 GUI와 같은, GUI(graphical user interface)를 포함할 수 있다.

본 명세서에 설명되는 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모든 것은 컴퓨터 판독 가능 저장 매체에 저장되는 컴퓨터 실행 가능 명령어들(예를 들어, 프로그램 코드)의 형태로 구현될 수 있다는 점이 이해되며, 이러한 명령어들은, 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행될 때, 본 명세서에 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행 가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독 가능 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비-이동식 매체를 포함하지만, 이러한 컴퓨터 판독 가능 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독 가능 저장 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD ROM, DVD(digital versatile disks) 또는 다른 광 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다.

서비스 레이어

"서비스 레이어(service layer)"라는 용어는 네트워크 서비스 아키텍처 내의 기능 레이어를 의미한다. 서비스 레이어들은 통상적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 레이어 위에 있으며 클라이언트 애플리케이션들에 부가 가치 서비스를 제공한다. 서비스 레이어는, 예를 들어, 제어 레이어 및 전송/액세스 레이어와 같은 하위 리소스 레이어에서 코어 네트워크들에 대한 인터페이스를 또한 제공한다. 서비스 레이어는 서비스 정의, 서비스 런타임인 에이블먼트, 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 다수 카테고리들의 (서비스) 능력들 또는 기능성들을 지원한다. 최근에, 여러 산업 표준 기관들, 예를 들어, oneM2M은 M2M 타입들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈 및 홈 네트워크들과 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M 서비스 레이어들을 개발해 왔다. M2M 서비스 레이어는 애플리케이션들 및/또는 다양한 디바이스들에 CSE 또는 SCL이라고 지칭될 수 있는, 서비스 레이어에 의해 지원되는, 위에서 언급된 능력들 또는 기능성들의 수집 또는 세트에 대한 액세스를 제공할 수 있다. 몇 가지 예들은, 이에 제한되는 것은 아니지만, 다양한 애플리케이션들에 의해 흔히 사용될 수 있는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급 및 접속성 관리를 포함한다. 이러한 능력들 또는 기능성들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 사용하는 API들을 통해 이러한 다양한 애플리케이션들에 이용 가능하게 된다. CSE 또는 SCL은, 하드웨어 및/또는 소프트웨어에 의해 구현될 수 있고, 다양한 애플리케이션들 및/또는 디바이스들(즉, 이러한 기능적 엔티티들 사이의 기능적 인터페이스)에 노출되는 능력들 또는 기능성들을 제공하는 기능적 엔티티로, 이들이 이러한 능력들 또는 기능성들을 사용하기 위한 것이다.

실시예에 따르면, 도 2는 시스템(200)의 네트워크- 네트워크 서비스들 도메인(205) - 내에 서비스 레이어(210)를 포함하는 시스템(200)의 배치 시나리오를 도시한다. 서비스 레이어는 다양한 네트워크 노드들- 게이트웨이들 및 서버들 - 상에 배치되어 네트워크 애플리케이션들, 웹, 인터넷, 오퍼레이터 네트워크들, 클라우드, 디바이스 애플리케이션들에 뿐만 아니라 네트워크 노드들 자체에 부가 가치 서비스들을 제공한다. 도 2에서, 게이트웨이들은 셀룰러 네트워크들, WLAN/WPAN/WSN, RFID 네트워크들 및 PLC, xDSL 및 PON과 같은 유선 네트워크들을 포함할 수 있다. 서버들은 디렉토리 서버, 애플리케이션 서버, 스토리지 서버, 관리 서버 및 서비스 서버를 포함할 수 있다. 시스템(200)은 센서들, 액추에이터들, RFID 태그들 및 가상 오브젝션들을 포함하는 DAD(device application domain)(220)을 또한 포함할 수 있다. 시스템(200)은 애플리케이션들 및 사용자들을 포함하는 네트워크 애플리케이션 도메인(230)을 포함할 수 있다.

일 실시예에서, M2M/loT 서비스 레이어는 M2M/IoT 유형 디바이스들 및 애플리케이션들에 대한 부가 가치 서비스들을 제공하는 것을 구체적으로 목표로 하는 일 타입의 서비스 레이어의 예이다. 여러 산업 표준 기관들, 예를 들어, ETSI M2M 및 oneM2M은 M2M/IoT 타입들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M/IoT 서비스 레이어들을 개발해 왔다. M2M 서비스 레이어는 애플리케이션들 및 디바이스들에게 서비스 레이어에 의해 지원되는 M2M 중심 능력들의 수집(collection)에 대한 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급, 및 접속성 관리를 포함한다. 이러한 능력들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용 가능하게 된다.

OneM2M 서비스 레이어

다른 실시예에서, oneM2M은 다양한 하드웨어 및 소프트웨어 내에 용이하게 내장될 수 있는 공통 M2M 서비스 레이어에 대한 요구들을 대처하는 기술 사양들을 개발하는데 이용된다. 또한, 이것은 관련분야에서의 광범위한 디바이스들을 전 세계의 M2M 애플리케이션 서버들과 접속하는 것에 의존될 수 있다. 하나의 M2M 공통 서비스 레이어들은, 도 3에 도시되는 바와 같이, CSF들(Common Service Functions), 예를 들어, 서비스 능력들의 세트를 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화(instantiation)는, 상이한 타입들의 네트워크 노드들, 예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션-특정적 노드 상에 호스팅될 수 있는 CSE(Common Services Entity)라고 지칭된다. 도시되는 바와 같이, CSE는 필드 도메인 및 인프라스트럭처 도메인에서 호스팅된다.

다른 실시예에 따르면, OneM2m은 2개의 아키텍처 접근방식들- RoA(Resource Oriented Architecture) 및 SoA(Service Oriented Architecture) -로 서비스 레이어를 개발하고 있다. oneM2M RoA RESTful 아키텍처에서 CSF들은 "리소스들(resources)"의 세트로서 표현된다. 리소스는 Create, Retrieve, Update, 및 Delete와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처에서의 고유하게 어드레스 지정 가능한 엘리먼트로서 정의된다. 이러한 리소스들은 URI들(Universal Resource Identifiers)을 사용하여 어드레스 지정 가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 자신의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들(attributes)"의 세트를 지원한다.

한편, SoA 아키텍처 레거시 배치는 RESTful 기반이 아니다. 오히려, 이는 도 4에 도시되는 것과 동일한 서비스 레이어 아키텍처를 주로 재-사용한다. 여기서, CSE는 점선으로 표시된다. CSE는, 예를 들어, 서비스 노출 컴포넌트, 서비스 컴포넌트 I, 서비스 컴포넌트 N, 네트워크 서비스 이용 컴포넌트 및 원격 서비스 노출 컴포넌트를 포함하는 다양한 M2M 서비스들을 포함한다. 기존의 참조 포인트들 외에도, CSE는 서비스간 참조 포인트 Msc를 포함할 수 있다. Msc 참조 포인트를 통과하는 M2M 서비스 컴포넌트들 사이의 통신은 웹 서비스들 접근방식, 예를 들어, Web Services MEP(Message Exchange Patterns)를 이용한다.

DM(Device Management) 프로토콜들

관련분야에서 일반적으로 이해되는 바와 같이, DM 프로토콜들은, 디바이스 상의 펌웨어 관리 및 소프트웨어 모듈 관리와 같은, 동적 디바이스 관리 기능들을 제공한다. 예를 들어, OM ADM은 Open Mobile Alliance에 의해 설계된 디바이스 관리를 위한 프로토콜이다. 이것은 모바일 디바이스들의 원격 관리에 널리 사용된다. 이것은 프로토콜, 아키텍처, 기본 네트워크 바인딩 등을 포함하는 다수의 사양으로 구성된다. 가장 흔한 시나리오에서, OMA DM 사양을 구현함으로써, DM 서버는 예를 들어 모바일 폰들과 같이 DM 클라이언트들이 있는 디바이스들 상의 원격 관리를 행할 수 있다. 이러한 디바이스들은 센서들, 액추에이터들, 및 게이트웨이들을 또한 포함할 수 있다. 관리 오브젝트 및 DM 클라이언트의 구현으로, DM 서버는 디바이스들 상의 원격 관리를 수행할 수 있다.

다른 DM 프로토콜들은 SCOMO(Software Component Management Object)이다. SCOMO는 디바이스 내의 원격 소프트웨어 컴포넌트 관리를 인에이블한다. 관리는 이에 제한되는 것은 아니지만 소프트웨어 컴포넌트(들)의 목록의 다운로딩, 설치, 업데이팅, 제거, 활성화/비-활성화 및 검색과 같은 기능들을 포함할 수 있다.

또 다른 DM 프로토콜은 BBF TR-069이다. 이러한 프로토콜은 CPE(Customer Premises Equipment)와 ACS(Auto-Configuration Server) 사이의 CWMP 프로토콜을 정의한다. ACS는 네트워크 내의 중앙집중 서버(centralized server)이고, 한편 CPE는 가정용 라우터들, 셋톱 박스들, 및 엔드 디바이스들을 포함할 수 있다. CWMP는 이에 제한되는 것은 아니지만 다음 기능들을 포함하는 CPE 디바이스들 세트를 관리한다: (i) 자동 구성 및 동적 서비스 공급; (ii) 소프트웨어/펌웨어 이미지 관리; (iii) 상태 및 성는 모니터링; 및 (iv) 진단. 소프트웨어 모듈 관리는 소프트웨어 모듈 설치, 업데이트, 삭제 및 통지를 포함하는, 모듈식 소프트웨어 및 실행 환경의 관리를 인에이블한다. 소프트웨어 모듈 관리는 CPE 상의 애플리케이션들을 시작 및 중지하고, 실행 환경들을 인에이블 및 디스에이블하며, 디바이스 상의 이용 가능한 소프트웨어 모듈을 목록화하는 능력을 또한 갖는다.

추가의 DM 프로토콜은 CSE에서의 DMG(Device Management) CSF를 포함한다. 이것은 M2M 영역 네트워크 내에 있는 디바이스들 뿐만 아니라 중간 노드들(M2M 게이트웨이들), 애플리케이션 서비스 노드들 및 애플리케이션 전용 노드들(M2M 디바이스들) 상의 디바이스 능력들의 관리를 제공하는 것을 담당한다. DMG는, Mcc 참조 지점을 가로지르는 CSE의 관리 이외에도, 기존 디바이스 관리 기술들, 예를 들어, TR-069 및 OMA-DM을 이용할 수 있다. 변환 및 적응 기능들을 수행하기 위해, DMG는 관리 어댑터라 불리우는 기능적 컴포넌트를 갖는다. 관리 어댑터는 기본 NSE에서 DMG와 관리 서버들(또는 관리 클라이언트) 사이의 적응을 수행한다.

M2M 영역 네트워크 내에 있는 디바이스들 뿐만 아니라 중간 노드들(예를 들어, M2M 게이트웨이들), 애플리케이션 서비스 노드들 및 애플리케이션 전용 노드들(예를 들어, M2M 디바이스들) 상의 디바이스 능력들의 관리를 제공하는 것을 담당하는 DMG(Device Management) CSF가 CSE에 존재한다. DMG는, Mcc 참조 포인트를 가로지르는 CSE의 관리 이외에도, 기존 디바이스 관리 기술들(예를 들어, BBF TR-069 및 OMA DM)을 이용할 수 있다. 변환 및 적응 기능들을 수행하기 위해 DMG는 관리 어댑터라고 불리우는 기능적 컴포넌트를 갖는다. DMG에서의 관리 어댑터는 기본 NSE에서 DMG와 관리 서버들(또는 관리 클라이언트들) 사이의 적응을 수행한다.

oneM2M에서의 서비스 확장 인에블러

본 출원의 일 양상에 따르면, 도 5에 도시되는 바와 같이, 예를 들어, 서비스 레이어(500)에 서비스 인에이블러 기능(510)의 아키텍처 뷰가 존재한다. 이것은 다음과 같은 하이 레벨 기능성들을 제공할 수 있다: (i) 모듈 인증을 체크함; (ii) 노드 리소스들을 체크함; (iii) 기존 모듈들과의 상호 운용성을 체크함; (iv) 충돌들을 취급하는 방법을 결정하는 정책 및 권한을 체크함, 예를 들어, 신규 모듈을 등록하지 않거나 기존 모듈을 등록 취소하지 않음; (v) 신규 모듈을 등록함; (vi) 신규 모듈로인한 신규 서비스(들)를 서비스들의 리스트에 추가함; (vii) 신규 서비스 능력들을 반영하도록 API 지원을 수정함; 및 (viii) 신규 모듈을 통합하도록 모듈간 통신을 수정함. 일 실시예에서, 등록 및 보안 서비스들은 임의의 서비스를 추가/활성화/비활성화/제거하는데 이용될 수 있다. SEF는, 참조 지점들을 통해, 하위 기능들 및 네트워크 엔티티들과의 통신, 예를 들어, 서비스 능력, M2M 애플리케이션들 및 M2M 서비스 레이어들을 포함한다. 서비스 인에이블러 기능은 이하 보다 상세히 설명되는 세가지(3) 주요 하위 기능들을 포함한다.

제1 하위 기능은 SMCF(Service State Management and Configuration Function)(511)이다. SMCF의 역할은 서비스의 상태 전이를 서비스 레이어에서 유지하고, 서비스의 능력들 및 특징들을 구성하는 것이다. 서비스의 다수의 버전들이 존재하면, SMCF는 서비스의 각각의 버전의 상태 및 구성을 관리하는 것을 담당한다.

제2 하위 기능은 SCF(Service Coordination Function)(512)이다. SCF의 역할은, 서비스 인에이블러 기능이 서비스를 추가, 활성화, 비활성화 또는 제거하기 위한 노력을 이끌 때, 서비스 인에이블러 기능 및 서비스 능력들, M2M 애플리케이션들 및 다른 M2M 서비스 레이어들 사이에서 프로세스 및 통신을 조정하는 것이다. 추가로, SCF는 서비스 인에이블러 기능 내의 SMCF 및 SAMF와 협력한다.

제3 하위 기능은 SAMF(Service API Management Function)(513)이다. SAMF의 역할은 서비스가 추가되거나, 활성화되거나, 비활성화되거나, 또는 제거될 때, 서비스 API를 동적으로 관리하는 것이다. 서비스 API는 서비스의 기능성 및 특징들을 암시한다. 예를 들어, 애플리케이션 또는 다른 서비스 레이어들과 같은 클라이언트들은, 서비스 API로부터 정보를 검색하는 것에 의해 서비스를 인식하고, 서비스 API를 액세스하는 것에 의해 서비스를 이용할 수 있다. 상이한 서비스들은 상이한 서비스 API들을 가질 수 있으며, 이들은 서비스를 제공하는 엔티티에 의해 정의된다. 일 실시예에서, 서비스 API를 액세스하는 것과 서비스 API가 존재하는 곳을 결정하는 것은 서비스 API 자체에 의해서가 아니라 서비스 레이어에 의해 수행된다.

예를 들어, SoA 기반의 온도 보고 서비스의 서비스 API는 파라미터들로서 위치 및 시간과 함께 온도를 검색하도록 구성될 수 있다. 추가로, 서비스 API는 평균 온도를 계산하고 파라미터들로서 시작 및 종료 시간과 함께 최고/최저 온도를 리턴하는 기능을 또한 제공할 수 있다. 다른 예는 RoA 기반의 위치 서비스이고, 서비스 API는 리소스들의 리스트를 제공하며 여기서 액세스 제어 속성은 위치 정보를 검색하도록 허용되는 사용자들의 세트를 정의하고, 주파수 속성은 최근 위치를 얼마나 자주 보고하고 업데이트하는지 표시한다.

도 6에 도시되는 바와 같은 다른 실시예에 따르면, CSE(620)는 CSF(621), 서비스 확장 인에이블러(622) 및 다른 인에이블러 기능들(623)을 포함한다. CSE는 Mca 참조 지점(615)을 통해 애플리케이션 엔티티(610)와 통신한다. CSE(620)는 Mcn 참조 지점(625)을 통해 기본 네트워크 서비스 엔티티(630)와 또한 통신한다.

신규 서비스 추가

본 출원의 양상에 따르면, 신규 서비스를 추가하기 위해 서비스 레이어 엔티티/노드를 선택하기 위한 프로토콜들이 설명된다. 이러한 프로토콜은 정책 구성, 협력 및 서비스 노드 선택 프로세스들을 포함한다. 본 명세서에 보다 상세히 설명되는 바와 같이, 서비스 인에이블먼트 정책들 및 서비스 노드 선택 기준은 이러한 프로세스들을 용이하게 하기 위해 정의된다. 일 실시예에 따르면, 신규 서비스들을 서비스 레이어에 추가하기 위한 프로세스가 도 7에 도시된다. 구체적으로, ASP(application service provider)에 의해 애플리케이션 서비스가 정의되고, SLE(service layer entity) 2는 서비스 제공자의 네트워크 내의 정책 구성들을 착수하고 서비스 노드 선택을 수행한다. SLE 3은 서비스 레이어에서 신규 서비스를 추가하기 위해 선택된다. 도 7에서 로마 숫자들로 표기되는 바와 같이 다음의 주요 프로세스들 수행될 수 있다. 프로세스 1은 서비스 레이어 내의 정책 구성을 설명한다. 서비스 제공자의 네트워크인 서비스 레이어에서 서비스 인에이블먼트 정책을 구성하는 것이 목적이다. 이렇게 함으로써, 각각의 서비스 레이어 엔티티는 서비스 제공자의 정책을 유지하며, 이는 모든 서비스들에 대해 일반적이다. ASP와 서비스 제공자 양자 모두 정책을 정의할 수 있다. 이러한 프로세스는 서비스 레이어에서만 발생한다는 점이 주목된다. 즉, 서비스 제공자는 자신이 소유하는 서비스 레이어 전반적으로 자신의 정책을 구성한다.

다른 실시예에 따르면, 프로세스 2는 도 7에 도시되는 협력 프로토콜들을 설명한다. 구체적으로, 일단 SLE(Service Layer Entity) 1이 ASP로부터 신규 서비스를 추가하라는 요청을 수신하면, ASP에 의해 명시되는 서비스인 에이블 정책 및 선택 기준이 충돌할 수 있으므로 SLE 2와의 협력 프로토콜을 시작한다. 따라서, SLE 1 및/또는 2는 충돌을 해결하기 위해 서비스 인에이블먼트 정책 및 선택 기준을 조화시킬 수 있다. 또한, SLE 2는 더 많은 정보를 얻기 위해 SLE 3와 협력할 수 있다. 정보는 신규 서비스를 추가할 서비스 노드를 선택하기 이전에 신규 서비스를 추가하고 호스팅하는 SLE 3의 능력 및 의지를 포함할 수 있다. 일 실시예에 따르면, 정책들의 교환은 ASP와 SLE 1 사이에서 발생한다. 다음 서비스 노드 선택 기준 협력이 착수된다. 여기서, 서비스 노드 선택 기준은 신규 서비스를 추가할 서비스 노드를 선택하는데 사용되는 선호도들/규칙들의 세트로서 정의된다. ASP와 서비스 제공자 양자 모두 선택 기준을 정의할 수 있다. 또한, 협력 프로시저들은 다른 서비스 레이어 엔티티들의 정보 검색을 또한 포함한다. 획득된 정보는 서비스 노드 선택 프로세스에 의해 사용될 것이며, 이는 신규 서비스를 추가하기 위한 서비스 노드의 더 나은 선택을 초래할 수 있다.

또 다른 실시예에 따르면, 프로세스 3은 호스팅 노드 선택 프로세스를 설명한다. 이것은 협력 프로세스를 통해 획득되는 정보에 기초한다. 구체적으로, SLE 2는 신규 서비스를 추가할 서비스 노드를 선택하는 서비스 노드 선택 프로세스를 수행한다. 또 다른 실시예에서, 도 7에 도시되는 바와 같은 프로세스 4는, SLE 3이 신규 서비스를 서비스 레이어 플랫폼에 추가하는 신규 서비스를 추가하는 단계이다. 각각의 프로세스는 여러 단계들로 구성될 수 있으며, 독립형 프로세스로서 또는 함께 수행될 수 있다는 점이 주목된다. 도 7에 도시되는 바와 같이, 신규 서비스는 애플리케이션, 예를 들어 ASP에 의해 정의되므로, ASP와 서비스 제공자에 의해 소유되는 서비스 레이어 사이의 잠재적인 정책 및 선택 기준 충돌들을 해결하기 위해 협력이 요구된다. 본 출원에 따르면 충돌들이 해결될 필요가 있을 때 인스턴스들이 발생할 수 있다는 것은 이하 보다 상세히 설명될 바와 같이 해결될 필요가 있을 것이라고 예상된다.

다른 실시예에 따르면, 서비스 제공자 자체가 신규 서비스를 정의할 수 있다. 예를 들어, 도 8에 도시되는 바와 같이, 서비스 레이어를 소유하는 서비스 제공자에 의해 신규 서비스를 추가하기 위한 프로세스가 제공된다. 서비스 제공자는 서비스 레이어의 소유자 및 관리자이기 때문에, 신규 서비스를 정의하는 엔티티는 프로세스 1을 통해 이미 구성된 정책 및 기준을 명시하지 않을 것이다. 따라서, 협력 프로세스 동안의 조화는 필요하지 않다. 예를 들어 ASP를 포함하는 실시예에 따르면, ASP가 신규 서비스를 제공하고 또한 신규 서비스를 호스팅하는 한편 서비스 레이어가 신규 서비스를 액세스하고 이를 이용하기 위해 ASP와 서비스 레이어 클라이언트 사이의 프록시 역할을 하는 것이 가능하다.

서비스 인에이블 정책

다른 실시예에 따르면, 서비스 인에이블먼트 정책은 신규 서비스를 추가하는 프로세스 동안 모든 서비스 레이어 엔티티가 따라야 할 규칙들의 세트로서 정의된다. 이것은, 예를 들어, 도 7 및 도 8에 도시된다. 이것은 ASP 및/또는 서비스 제공자에 의해 정의되고 서비스 제공자의 네트워크 내에서 SLE에 의해 유지되는 정책을 포함될 수 있다. 이것은 정책을 구성하는 2개의 단계들을 포함될 수 있다. 제1 단계는, 예를 들어, 하나 이상의 서비스 레이어 엔티티들 상의 정책을 구성하는 서비스 제공자를 포함할 수 있다. 이것은 처음부터 미리 구성되는 방식으로 일반적으로 발생한다. 제2 단계는 ASP가 일부 정책들을 명시하고 신규 서비스를 정의할 때 협력 프로세스 동안 정책을 조화시키는 서비스 제공자 네트워크에서의 서비스 레이어 엔티티들을 포함할 수 있다. 본 출원에 따르면, 조화는 ASP와 서비스 제공자 양자 모두가 서로 충돌하는 정책들을 명시할 때 정책을 수정하는 동작들을 의미한다.

서비스 인에이블먼트 정책은 4개 타입들로서 분류될 수 있다. 예들이 아래 표 2에 제공된다.

타입 1은 협력을 위한 정책이다. 이러한 타입의 정책은, 이에 제한되는 것은 아니지만, 다음 콘텐츠를 포함할 수 있는 협력 프로세스를 안내하기 위해 구성된다:

협력 인에이블먼트 표시: 서비스 레이어 엔티티들 사이의 협력이 신규 서비스를 서비스 레이어 플랫폼에 추가하기 위해 인에이블되는지 표시함. 때때로, 서비스 제공자/애플리케이션 서비스 제공자가 전체 네트워크 전반적으로 서비스 정보를 노출하기를 원하지 않을 수 있다. 달리 말하면, 서비스는 네트워크의 서브세트 내에서만 발견될 수 있다. 예를 들어, 게이트웨이에 등록된 로컬 클라이언트들에 신규 데이터 스토리지 서비스가 제공되고, 따라서 범위를 벗어나는 정보를 공개할 필요가 없다. 표시가 인에이블된 것으로서 설정되면, 애플리케이션 서비스 제공자가 등록하는 서비스 레이어 엔티티는 정책 및 서비스 노드 기준과 관련하여 협력 프로세스를 착수할 것이다.

적격 협력 엔티티 타입: 협력 프로세스에 포함될 수 있는 서비스 레이어 엔티티의 타입을 명시함.

협력 범위: 협력 프로세스가 발생할 수 있는 범위를 표시함. 협력 인에이블먼트 표시가 "참(true)"으로 설정되면, 이것은 협력의 범위를 정의한다.

협력 콘텐츠: 어떤 타입의 콘텐츠/정보가 협력 프로세스 동안 교환될 수 있는지 표시함.

협력 트리거 조건들: 협력 프로세스를 트리거할 수 있는 일부 시나리오들을 표시함.

타입 2는 서비스 노드 선택을 위한 정책이다. 이러한 정책은, 이에 제한되는 것은 아니지만, 다음 콘텐츠를 포함하는 서비스 노드 선택 프로세스에 대해 정의되어 사용된다:

서비스 노드 범위: 신규 서비스를 추가할 서비스 노드가 선택될 수 있는 범위/서비스 도메인을 표시함.

적격 서비스 노드 타입: 신규 서비스를 추가하기에 적격인 서비스 노드의 타입을 표시함

최대 서비스 노드 수: 서비스 레이어에서 신규 서비스를 추가할 수 있는 서비스 노드들의 최대 수를 표시함.

최소 서비스 노드 수: 신규 서비스를 추가하는 서비스 노드들의 최소 수를 표시함

서비스 제공자/애플리케이션 서비스 제공자까지의 최대 거리: 신규 서비스를 서비스 제공자/애플리케이션 서비스 제공자에 추가하는 노드로부터의 거리의 상한을 표시함. "거리(distance)"는 상이한 방식들, 예를 들어, 홉들의 수로 명시될 수 있어, 많은 홉들 멀리 데이터를 전송하지 않고도 데이터 리포트가 보다 용이하거나, 너무 많은 홉들을 갖는 것을 회피한다.

서비스 레이어 클라이언트들까지의 최대 거리: 신규 서비스를 서비스 레이어 클라이언트들, 즉, 서비스 소비자에 추가하는 노드로부터의 거리의 상한을 표시함.

서비스 노드 선택 인에이블: 신규 서비스에 대해 서비스 노드 선택이 인에이블되는지 여부를 표시함.

적격 선택 엔티티: 서비스 노드 선택 프로세스를 수행하기에 적격인 엔티티의 타입을 명시함.

서비스 제공자 확인: 일부 서비스 노드들이 서비스 노드 선택 프로세스에 의해 신규 서비스를 추가하도록 선택된 후 애플리케이션 서비스 제공자/서비스 제공자가 서비스 노드 선택 결과들을 확인할 필요가 있는지 표시함.

타입 3은 다수의 신규 서비스들을 추가하는 메시지들을 종합하기 위한 정책이다. 이러한 카테고리의 정책은, 신규 서비스들을 추가할 때 메시지들의 종합에 대해 정의되고 유지되며, 이는, 이에 제한되는 것은 아니지만, 다음 콘텐츠를 포함한다:

종합 인에이블: 다수의 신규 서비스들을 추가할 때 종합이 인에이블되는지 표시함.

적격 종합 엔티티: 어떤 타입의 서비스 레이어 엔티티가 종합을 행할 자격이 있는지 표시함. 예를 들어, M2M 서버만이 그렇게 하도록 허용되거나, 또는 인프라스트럭처 노드만이 종합을 행하도록 허용된다.

종합 윈도우: 기간을 표시하여, 종합 윈도우 동안 수신되는 요청들이 종합에 대해 고려될 수 있음.

인에이블된 종합 시나리오: 어떤 타입들의 종합 동작들이 인에이블되는지 표시함. 달리 말하면, 이러한 파라미터는 종합이 인에이블되는 시나리오들 세트를 명시한다.

타입 4는 신규 서비스를 액세스하기/이용하기 위한 정책이다. 이러한 카테고리의 정책은 신규 서비스를 액세스하고 이를 이용하기 위해 정의되고 유지 관리되며, 이는, 이에 제한되는 것은 아니지만, 다음의 콘텐츠를 포함할 수 있다:

서비스 공급 범위: 신규 서비스가 제공해야 하는 범위를 표시함. 달리 말하면, 이것은 명시된 범위 내의 클라이언트들만이 서비스를 액세스하고 이용할 수 있음을 표시한다. 이것은 협력의 범위와 상이할 수 있다. 예를 들어, 신규 근접 광고 서비스가 로컬 영역 내에 제공되어, 신규 서비스를 추가하는 모든 정보 및 처리는, 대응하는 로컬 네트워크에 머무르는, 엔티티, 예를 들어, 게이트웨이 및 서버에 의해 취급될 수 있다.

액세스 권한이 있는 클라이언트들의 리스트: 신규 서비스를 액세스하는/이용하는 것이 허용되는 서비스 레이어 클라이언트들의 리스트 또는 클라이언트들의 카테고리들의 리스트를 표시함. 이러한 리스트는 개별 클라이언트들의 여러 서비스 레이어 식별자들을 포함될 수 있거나, 또는 일반적인 타입들의 클라이언트, 예를 들어, 인프라스트럭처 서버를 포함할 수 있다.

다른 실시예에 따르면, 도 7 및 도 8에서 프로세스 1로서 도시되는 정책 구성의 제1 단계 동안, 각각의 서비스 제공자는 자신의 서비스 레이어 플랫폼에서의 서비스 레이어 엔티티들 사이에 서비스 인에이블먼트 정책을 구성할 것이다. 이러한 프로세스는 서비스 레이어 착수 단계, 및 서비스 제공자가 도 9에 도시되는 바와 같이 임의의 서비스 인에이블먼트 정책을 업데이트하기를 원하는 시간 동안 발생할 수 있다. 서비스 제공자는 정책들의 세트를 SLE 2에 사전 공급한다고 가정되며, 다음으로 이는 사전 구성된 정책을 서비스 제공자에 의해 소유되는 서비스 레이어 전반적으로 이동시킨다. 대부분, 서비스 제공자는 인프라스트럭처 필드에서 서비스 레이어 엔티티를 먼저 사전 구성할 것이다. 본 출원에 따르면, 정책 구성 요청은 각각의 SLE의 역할에 의존하여 서비스 제공자의 서비스 인에이블먼트 정책의 서브세트를 운반할 수 있다. 예를 들어, oneM2M에서, SLE 2가 인프라스트럭처 도메인에서의 IN-CSE이고, 한편 SLE 1이 필드 도메인에서의 ASN-CSE이면, SLE 2는 필드 도메인에서의 ASN-CSE에 보여지도록 허용되는 요청에 서비스 인에이블먼트 정책의 서브세트를 포함시킬 수 있다

서비스 노드 선택 기준

또 다른 실시예에 따르면, 서비스 노드 선택 기준은 신규 서비스를 추가할 서비스 노드를 선택하기 위한 규칙들의 세트로서 정의된다. 애플리케이션 서비스 제공자는 서비스 노드 선택 프로세스를 용이하게 하기 위해 신규 서비스에 대한 기준의 세트를 명시할 수 있다. ASP에 의해 명시되는 기준이 존재하지 않으면, 서비스 노드 선택 프로세스를 수행하는 SLE, 즉, 서비스 제공자는 일부 디폴트 기준을 따를 것이다. 이에 기초하여, 서비스 제공자의 SLE들 사이에는 일부 사전 정의되고 이동되는 기준이 존재하고, 이는 그 서비스 도메인 내의 모든 서비스들에 대해 일반적이다. 선택 기준을 구성하고 이동하는 프로시저는 위에 설명된 서비스 인에이블먼트 정책에 대한 것과 유사하다. 또한, ASP와 서비스 레이어, 예를 들어, 서비스 제공자 사이의 잠재적인 충돌들을 해결하기 위해 선택 기준의 조화가 이하 보다 상세히 제시될 것이다.

또 다른 실시예에 따르면, 서비스 노드 선택 기준은 다음의 양상들 중 하나 이상에 관련될 수 있다:

서비스 노드 위치: 신규 서비스를 추가할 잠재적인 서비스 노드에 대한 위치 요건, 즉 어디에 잠재적인 서비스 노드가 있을 수 있는지 표시함. 예를 들어, 서비스 제공자는 서비스 노드가 서비스 제공자로부터 2 홉들 내에 머물러야 한다는 것을 명시적으로 요구할 수 있다.

서비스 도메인 요건: 어떤 서비스 도메인에서 신규 서비스를 추가할 서비스 노드가 선택될 수 있는지 표시함.

액세스 제어: 서비스 노드를 선택할 때 액세스 제어 요건을 표시함. 예를 들어, 서비스 제공자는 서비스 노드가 완전한 액세스 권한, 예를 들어, CRUDN을 자신에게 부여해야 한다고 요구할 수 있다. 다른 예는 서비스 노드가 크로스-도메인 클라이언트들에게 적어도 RETRIEVE 권한을 부여할 것을 서비스 제공자가 요구하는 것이며, 예를 들어, 신규 서비스가 이러한 클라이언트들에 의해 발견될 수 있다.

기본 네트워크 프로토콜: 서비스 노드를 선택할 때 기본 네트워크 프로토콜에 대한 선호도/요건으로서 기준을 표시함. 예를 들어, 신규 서비스를 추가할 서비스 노드는 CoAP 및/또는 MQTT 프로토콜을 지원할 것이 요구될 수 있다.

디바이스 관리: 디바이스 관리 프로토콜의 면에서 서비스 노드에 대한 요건을 표시함. 이것은 미래의 잠재적인 서비스 업데이트에 관련될 수 있다. 예를 들어, 신규 데이터 분석 서비스는 향후에 여러 업데이트된 버전들을 예상하고, 따라서 OMA DM 프로토콜 또는 BBF TR-069 프로토콜에 의해 정의되는 소프트웨어 모듈 업그레이드 기능성을 호스트가 지원하는 것을 선호할 수 있다.

로드 밸런스: 서비스 노드를 선택하기 위한 로드 밸런스 요건을 표시함. 예를 들어, 잠재적인 호스트는 현재 초 당 2GB보다 많지 않은 데이터를 처리할 것이 요구될 수 있거나, 또는 그 계산 용량이 현재 50%보다 적지 않은 유휴 상태일 것이 요구될 수 있다.

서비스 노드 타입: 신규 서비스를 추가하기에 적격인 서비스 레이어 엔티티의 타입들(예를 들어, M2M 게이트웨이 및/또는 M2M 서버)을 표시함. 이러한 기준은 크로스-도메인 서비스 노드가 신규 서비스를 추가할 수 있는지를 또한 표시할 수 있다. 서비스 제공자는 신규 서비스의 능력 및 보안 요건을 고려하여 이러한 규칙을 구성한다. 예를 들어, 신규 데이터 분석 서비스는 많은 양의 스토리지 및 계산 리소스를 요구하고, 따라서 많은 스토리지 및 강력한 계산 능력이 있는 서버가 신규 서비스를 호스팅하기 위한 프록시 게이트웨이보다 선호된다.

API 지원: 신규 서비스를 액세스하고 이용하기 위해 API의 면에서 호스트 후보들에 대한 선호도를 표시함. 예를 들어, 서비스 제공자는 RESTful API를 지원하는 서비스 노드들을 선호한다고 표시할 수 있다.

보안: 잠재적 서비스 노드에 대한 보안 요건을 표시함. 이것은 인증 및 인가와 같은 다양한 양상들로부터일 수 있음.

데이터 스토리지: 신규 서비스를 추가할 서비스 노드에 대한 데이터 스토리지 관점으로부터의 요건을 표시함. 이것은, 얼마나 많은 쿼리들이 데이터베이스에서 초 당 행해질 수 있는지와 같이, 데이터 스토리지의 크기, 사용되는 데이터베이스 기술, 및 관련 파라미터들을 정의할 수 있다.

종합 선호도: 다수의 신규 서비스들을 추가할 때 종합 능력이 있는 서비스 노드가 선호되는지 여부를 표시함.

본 출원에 따르면, 서비스 노드 선택 기준은 상이한 서비스들에 대해 위애 언급된 양상들의 일부만을 포함할 수 있으며, 이는 상이한 특징들 및 기능성들을 갖는다. 아래에 도시되는 표 3은 신규 데이터 분석 서비스에 대한 서비스 노드 선택 기준의 예이며, 서비스 제공자에 의한 높은 계산 능력 및 전체 액세스 권한을 요구한다. 이러한 필수적 기준이 충족되어야 하는 한편, 서비스 노드를 선택할 때 선택적 태그들이 선호된다는 점에 주목한다.

협력의 프로시저

또 다른 실시예에 따르면, 도 10은 ASP들, 예를 들어, M2M 애플리케이션들 1 및 2, 2개의 서비스 제공자들의 네트워크들에서의 SLE들, 예를 들어, M2M 게이트웨이들 및 M2M 서버들, 및 서비스 레이어 클라이언트들로 구성되는 서비스 레이어 네트워크의 예를 나타낸다. 본 실시예에 따르면, M2M 서버(1e) 및 M2M 서버(2a)는 2개의 서비스 도메인들 사이의 도메인간 트래픽을 운반하는 책임이 있다. 또한, 본 실시예는 신규 서비스를 추가하기 이전에 서비스 제공자들의 네트워크에서 ASP 및 SLE들 사이의 협력의 동작들을 나타낸다. 협력은 다음 중 하나 이상을 포함할 수 있다:

정책 협력: 서비스 인에이블먼트 정책을 교환하고, 애플리케이션 서비스 제공자에 의해 명시되는 정책이 서비스 레이어 엔티티들에 의해 유지되는, 예를 들어, 서비스 제공자에 의해 설정되는 것들과 상이하면 충돌을 해결함.

서비스 노드 선택 기준 협력: 신규 서비스를 추가하기 위해 서비스 노드를 선택하기 위한 선택 기준을 교환하고, 애플리케이션 서비스 제공자에 의해 명시되는 기준이 서비스 레이어 엔티티들에 의해 유지되는 것들과 충돌하면 충돌을 해결함.

다른 서비스 레이어 엔티티들의 정보 검색: 획득되는 정보는 서비스 노드 선택 프로세스에서 사용될 것이며, 이는 결과적으로 더 나은 선택을 초래할 수 있음.

다른 실시예에 따르면, 도 11은 도 10의 네트워크에 기초하는 협력의 예시적인 프로시저를 도시한다. 예시적인 실시예에 따르면, M2M 애플리케이션(1)은 신규 서비스를 정의하기를 원할 것이고, M2M 서버(1c)는 서비스 노드 선택 프로세스를 수행하려고한다고 가정될 수 있다. 협력 프로시저는 도 11에서 로마 숫자들로 표기되는 다음의 단계들을 포함한다. 단계 1에 따르면, ASP, 예를 들어, M2M 애플리케이션(1)은 신규 서비스를 추가하기 위해 M2M 게이트웨이(1a)에 대해 요청을 착수한다. 요청 메시지에는 다음 정보를 포함할 수 있다: 서비스 설명, 서비스 인에이블먼트 정책, 및 서비스 노드 선택 기준.

구체적으로, 서비스 설명은 신규 서비스를 설명하는 일부 정보를 제공할 수 있다. 이것은, 예를 들어, 신규 서비스의 주요 기능성, 애플리케이션 서비스 제공자 ID, 서비스 ID, 소프트웨어 모듈 정보, 프로토콜 지원, 및 과금 방법을 포함할 수 있다. 별도로, 서비스 인에이블먼트 정책은 ASP의 의도를 반영하는 신규 서비스를 추가하기 위해 모든 프로세스들을 안내하는 정책들을 제공할 수 있다. 또한, 서비스 노드 선택 기준은 서비스 노드 선택 프로세스에 대해 기준의 세트를 제공한다.

다음으로, 단계 2에 따르면, 요청 수신시, M2M 게이트웨이(1a)는 애플리케이션 서비스 제공자에 의해 명시되는 서비스 인에이블먼트 정책 및 서비스 노드 선택 기준을 초기에 처리할 수 있다. 달리 말하면, 게이트웨이(1a)는 인식된 또는 실제의 충돌이 존재하면 정책들과 기준을 조화시킬 것이다. 예를 들어, 신규 과금 서비스의 ASP는 크로스-도메인 협력 및 크로스-도메인 서비스 노드들이 신규 서비스를 호스팅하는 것을 허용하기를 원할 것이다. 그러나, M2M 게이트웨이(1a)는, 도 9에 도시되는 바와 같이, 정책 구성 단계 동안 서비스 제공자에 의해 임의의 과금 관련 서비스에 대해 크로스-도메인 서비스 노드들이 금지되는 것을 알고 있다. 따라서, M2M 게이트웨이(1a)는 정책 구성에서 크로스-도메인 서비스 노드를 디스에이블한다. 일 예에서, 신규 데이터 스토리지 서비스는 서비스 노드가 관계형 및 비-관계형 데이터베이스 양자 모두를 지원할 것을 요구할 수 있으며, 이는 M2M 게이트웨이(1a)에 의해 수락되고 업데이트될 것이다.

일반적으로, 이하 논의될 바와 같이 조화의 프로세스 동안 규칙들이 지켜지거나 사용될 수 있다. 첫째, 서비스 제공자에 의해 설정되고 서비스 제공자의 서비스 레이어에서의 서비스 레이어 엔티티에 의해 유지되는 모든 정책들은 ASP가 이러한 것들과 충돌하는 일부 정책을 명시하더라도 시행되어야 한다. 둘째, 서비스 제공자가 정책을 갖고 있지 않은 특정 영역에 관련되는 일부 정책을 ASP가 명시하면, 서비스 레이어 엔티티는 서비스 제공자의 정책을 체크하여 ASP-정책이 서비스 제공자의 정책과 잠재적으로 충돌하는지 알아볼 필요가 있다. 예를 들어, ASP는 위치 서비스의 동시 사용을 요구하는 신규 서비스를 정의하고, 한편 서비스 제공자는, 예를 들어, 서비스 제공자가 공통 위치 서비스를 제공한다고 가정하면, 자신의 위치 서비스와 제3자 서비스의 동시 사용이 인에이블되는지 여부를 명시하는 정책을 갖지 않는다. 잠재적인 충돌이 존재하면, 서비스 레이어 엔티티는 여전히 SP의 정책을 적용하고 나중에 ASP에 통보할 필요가 있다. 잠재적인 충돌이 없으면, 서비스 레이어 엔티티는 ASP의 정책을 신규 서비스에 대해 구체적인 서비스 인에이블먼트 정책의 세트에 통합할 수 있다.

다음으로, 단계 3에서, M2M 게이트웨이(1a)는 협력이 허용되는지 체크한다. 인에이블되면, M2M 게이트웨이는 협력 프로시저를 계속 진행할 것이다. 단계 4에 따르면, M2M 게이트웨이(1a)는 정책 및 선택 기준을 교환하기 위해 자신의 등록된 M2M 서버(1c)에 협력 요청을 전송한다. 요청 메시지는 서비스 설명, 조화된 정책 및 서비스 노드 선택 기준을 포함함다. 이러한 요청에 포함되는 정책 및 선택 기준이 단계 2에서 언급되는 바와 같이 M2M 게이트웨이(1a)에 의해 이미 업데이트되었으며, 이는 애플리케이션 서비스 제공자에 의해 명시되는 원래의 것들과 다를 수 있다는 점을 주목할 가치가 있다. 단계 5에서, M2M 서버(1c)는 수신된 정책과 선택 기준을 추가로 조화시킬 것이다. 그 이유는 M2M 서버(1c)가, 상이한 서비스 도메인들에서의 클라이언트들에 대한 액세스 정책과 같이, M2M 게이트웨이(1a)보다 네트워크 상태에 대한 더 넓은 지식을 가질 수 있기 때문이다.

단계 6에 따르면, M2M 서버(1c)는 서비스 노드 선택을 수행하는 것으로 가정되기 때문에, 다른 SLE들, 예를 들어, M2M 서버(1d, 1e 또는 2a)에 협력 요청들 전송하여 더 많은 정보를 검색할 것이다. 이러한 요청은 서비스 설명 정보, 조화된 정책 및 선택 기준, 및, 서비스 레이어 엔티티에 의해 사용되는 보안 방법, 신규 서비스를 추가하려는 의지, 또는 데이터 스토리지 능력과 같은, 요청된 엔티티 정보의 타입을 포함할 것이다.

다음으로, 단계 7에서, 협력 요청 수신시, SLE들은 정책 및 선택 기준이 그들이 유지한 것들과 충돌하는지 결정하고, 서비스 설명에 기초하여 요구되는 정보를 제공할 것이다. 예를 들어, 서비스 설명에 기초하여, M2M 서버(1d)는 계산 능력 및 다량의 데이터 스토리지의 높은 요건으로 인해 신규 데이터 분석 서비스를 추가하기를 원하지 않을 수 있다. 8 단계에서, 요구되는 정보가 있는 응답이 M2M 서버(1c)에 리턴된다. 단계 9에서, M2M 서버(1c)는 모든 정보를 통합하고, ASP의 확인을 위해 M2M 게이트웨이(1a)에 응답을 전송한다. 단계 10에서, M2M 게이트웨이(1a)는 협력 결과들, 예를 들어, 조화된 정책 및 선택 기준을 애플리케이션 서비스 제공자에게 전송하며, 이는 이러한 정보를 검토할 것이 요청된다.

단계 11a에 따르면, ASP가 모든 결과들에 양호한 경우, 이는 단지 M2M 게이트웨이(1a) 및 M2M 서버(1c)에 확인 응답을 전송한다. 이것은 서비스 노드 선택 프로세스를 트리거할 것이다. 또한 단계 11b에서, ASP가 일부 정책들 또는 기준에 양호하지 않으면, 이것은 정책 또는 기준을 M2M 게이트웨이(1a)에 추가로 업데이트하는 일부 피드백을 제공할 것이다. 단계 2는 추가 협력을 위해 반복될 수 있다.

또 다른 실시예에 따르면, 도 11은 협력이 인에이블되는 것을 가정한다. 각각의 단계들은 도 11에서 로마 숫자들로 표현된다. 본 출원의 내용에 따르면 협력이 또한 디스에이블될 수 있다는 점이 예상된다. 이러한 경우, M2M 게이트웨이(1a)는 신규 서비스를 추가할 것으로 예상된다. 그러나, M2M 게이트웨이(1a)가 신규 서비스를 추가할 수 없으면, 이것은 신규 서비스에 관한 정보를 자신의 등록된 엔티티, 즉 M2M 서버(1c)에 전달할 것이다. 그러면 M2M 서버(1c)는 신규 서비스를 직접 추가할 것이다. 도 12는 협력이 인에이블되지 않은 경우에서의 프로시저를 도시하며, 협력이 디스에이블되면 서비스 노드 선택이 디스에이블되는 것으로 가정된다.

서비스 노드 선택

본 발명의 다른 양상에 따르면, 신규 서비스를 추가하기 위한 하나 또는 다수의 서비스 노드(들)를 선택하는 방법이 개시된다. 서비스 노드 선택 프로세스의 3개의 가능한 결과들이 아래에서 논의된다. 제1 결과에서는, 신규 서비스에 대해 하나의 서비스 노드만 선택된다. 이것은 1개의 서비스 노드만이 허용된다는 정책에 의해, 또는 1개의 서비스 노드만이 모든 정책들 및 서비스 노드 선택 기준을 충족시키는 경우로 인해 결정될 수 있다. 제2 가능한 결과에서는 신규 서비스를 추가하기 위해 다수의 서비스 노드들이 선택된다. 예를 들어, M2M 서버(1c), M2M 서버(1d) 및 크로스-도메인 M2M 서버(2a)는 신규 서비스를 추가하도록 선택되어 이러한 신규 서비스를 이용하기에 보다 편리하고 및/또는 효율적인 방식을 인에이블할 수 있다. 제3 가능한 결과에서는, 서비스 제공자의 네트워크에서의 서비스 노드들 중 어느 것도 모든 기준을 충족하지 못한다. 따라서, 선택 프로세스를 수행하는 엔티티는 기준을 조정하거나 신규 서비스를 추가하는 것을 중지하기 위해 협력 프로세스를 시작할 것이다.

M2M 서버(1c)가 서비스 노드 선택 프로세스를 수행한다고 가정하면, 도 13은 신규 서비스를 추가하기 위한 서비스 노드 선택 흐름을 도시한다. 도 13은 로마 숫자들로 표현되는 하나 이상의 단계들을 포함한다. 단계 1에 따르면, M2M 서버(1c)는 협력 프로세스가 행해졌다고 결정할 때 서비스 노드 선택 프로세스를 착수한다. 요청 메시지가 선택 프로세스의 시작을 트리거하는 것이 또한 예상된다. 요청 메시지는 서비스 설명, 조화된 정책 및 서비스 노드 선택 기준을 포함할 수 있다. 단계 2에서, 신규 서비스를 추가하도록 잠재적으로 선택될 수 있는 몇몇 서비스 노드들을 포함하는 초기 후보 세트가 수립된다. 초기 후보 세트는 상이한 방식들을 통해 수립될 수 있다. 예를 들어, M2M 서버는 등록되는 모든 게이트웨이들 및 서버들을 포함하거나, 또는 동일한 서비스 도메인 내의 모든 서버들을 포함할 수 있다. 이것은 하나의 가능한 방식으로서 리소스 발견에 의해 달성될 수 있다.

단계 3에서, M2M 서버(1c)는 후보 리스트 및 조화된 서비스 노드 선택 기준에 기초하여 신규 서비스를 추가할 서비스 노드들의 순위화된 리스트를 계산한다. 그것을 행하는 하나의 방식은 M2M 서버에 의해 필수 서비스 노드 선택 기준과 일치하지 않는 후보를 제거하고, 다음으로 정책 및 선택 기준에 기초하여 나머지 후보들을 순위화하는 것이다. 이렇게 함으로써, 이러한 단계의 결과는 서비스 노드들의 순위화된 리스트이다.

단계 4에 따르면, 서비스 노드들의 순위화된 리스트와 함께, M2M 서버(1c)는 하나 이상의 요청들을 리스트의 상단에 순위화되는 서비스 노드(들)에 전송한다. 요청들의 수는 선택 정책에 따라 결정된다. 예를 들어, 하나의 서비스 노드만이 신규 서비스를 추가하는 것이 허용되면, M2M 서버(1c)는 제1 순위화된 서비스 노드에 요청을 전송할 것이다. 그러나, 4개의 서비스 노드들이 허용되면, 4가 최소가 될 것이다.

단계 5에서는, 임의의 선택된 호스트들이 신규 서비스를 추가할 것이고 호스팅하는지에 대한 쿼리에 기초하는 결정이 행해진다. 예이면, 선택 프로세스가 종료된다. 그렇지 않으면, 흐름도는 요청을 재-전송하기 이전에 단계 6으로 진행된다. 단계 6에서는, 서비스 노드가 단계 4에서 전송된 요청을 수락하지 않으면, 선택 프로세스로부터의 결과인 순위화된 리스트에 남아 있는 서비스 노드가 존재하는지 M2M 서버(1c)가 먼저 체크한다. 예이면, 단계 4로 되돌아간다. 달리 말하면, M2M 서버(1c)는 순위화된 리스트에서 남아 있는 서비스 노드에 요청을 재전송할 것이다. 예를 들어, M2M 서버(1c)가 단계 4에서 리스트에서의 처음 2개의 서비스 노드들에 요청을 전송하더라도, 어느 것도 이러한 요청을 수락하지 않는다. M2M 서버(1c)는 순위화된 리스트에서 세 번째 및 네 번째에 머무르는 다음 2개의 서비스 노드들에 요청을 전송할 것이다. 이것은 일부 서비스 노드가 신규 서비스를 추가하려고 할 때까지 반복될 것이다.

단계 7에서는, 리스트에 남아있는 서비스 노드가 존재하지 않는다면, 예를 들어, 모든 순위화된 서비스 노드들이 신규 서비스를 추가하라는 요청들을 수락하지 않으면, M2M 서버(1c)는 애플리케이션 서비스 제공자와 연락하여 다음 액션을 협상하려고 시도할 것이다. 일 예에서, 이러한 협상은 신규 서비스를 추가하기 위해 선택 기준 또는 ASP 스위치들을 다른 서비스 제공자들에 대해 조정하는 것이다. 따라서, 이것은 선택 프로세스가 종료되고 협력 프로세스가 트리거될 수 있음을 의미한다.

또 다른 실시예에 따르면, 서비스 노드 선택을 수행하는 SLE는 신규 서비스를 추가하도록 잠재적으로 선택될 수 있는 서비스 노드들의 정보를 가질 수 있다. 즉, 서비스 노드 선택 프로세스 이후, 선택을 수행하는 엔티티는 신규 서비스를 추가하기 위해 선택된 서비스 노드를 통보할 필요가 있다. 예를 들어, 도 14에 따르면, 서비스 노드 선택 프로세스를 착수하고 수행하기 위한 프로시저가 설명된다. 일 실시예에서는, SLE 2가 서비스 노드 선택 프로세스를 수행하고, SLE 1은 신규 서비스를 추가하도록 선택된다. 단계들 각각은 도 14에서 로마 숫자로 표기된다. 특히, 단계 1에서는, SLE 2가 서비스 노드 선택 프로세스를 수행한다. 결과들은 서비스 노드 후보들의 순위화된 리스트를 포함할 수 있다. 단계 2에서는, SLE 2가 신규 서비스를 추가하기 위한 요청을 SLE 1에 전송한다. 요청 메시지는 다음 정보를 포함할 수 있다: (i) 서비스 노드 선택 결과들; (ii) 조화된 서비스 인에이블먼트 정책; 및 (iii) 신규 서비스를 액세스하고 이용하기 위한 구성.

사례 1에 따르면, SLE 1이 신규 서비스를 추가할 수 있다. 사례 1에서는, ASP가 SLE로부터 요청을 수신한다. 즉, 게이트웨이는 애플리케이션 서비스 제공자에게 요청을 전송할 것이며, 이는 서비스 노드 선택 결과들을 확인할 것이 요구된다. 요청 메시지는 서비스 노드 선택 프로세스의 결과들을 포함한다. 다음으로, 단계 4에서는, ASP가 SLE1 또는 서비스 제공자에게 선택 결과들을 확인하는 응답을 다시 전송한다. ASP가 결과들에 동의하지 않으면, 요구되는 업데이트가 있는 응답을 전송할 수 있다. 이것은 도 12에 도시되는 협력 프로시저들을 트리거할 것이다. 다음으로, SLE 1은 위에 개시되는 기존 메커니즘 프로시저들에 따라 서비스 레이어 플랫폼에 신규 서비스를 추가한다. 후속하여 단계 6에서는, 신규 서비스를 추가한 후, SLE 1이 신규 서비스의 표현이 있는 응답을 SLE 2에 전송한다. 응답은 신규 서비스를 액세스하는/이용하는 방법을 또한 포함한다. 즉, 기능성을 나타내는 리소스의 URI(uniform resource identifier)가 신규로 추가된 리소스에 대해 제공된다. 단계 7에서는, SLE 1이 신규 서비스의 표현을 포함하는 응답을 ASP에 전송하고, 신규 서비스를 액세스하는/이용하는 방법을 전송한다.

사례 2에 따르면, SLE 1은 신규 서비스를 추가할 수 없다. 이러한 경우, SLE 1은 거절 응답을 전송하여 신규 서비스를 추가하라는 요청을 거절할 것이다(단계 3). 이것은 거절의 이유를 또한 포함할 것이다. 그 이유는, 예를 들어, 충분한 계산 능력 또는 데이터 스토리지의 부족을 포함할 수 있기 때문이다. 따라서, 선택 프로세스 이전에 협력이 발생되더라도, 선택 프로세스를 수행하고 있었을 때를 SLE 2가인식하지 못하는 일부 최신 정보를 SLE 1이 갖는 것이 여전히 가능하다. 거절 응답의 수신시, SLE 2는 선택 결과들을 다시 방문하고, 신규 서비스를 추가하기 위한 요청을 리스트에 남겨진 다른 서비스 노드들에 전송한다(단계 4). 추가의 실시예에 따르면, 후속 동작들은 신규로 선택된 서비스 노드가 신규 서비스를 추가할 수 있는지의 여부에 의존하여 위에 설명된 사례 1 또는 사례 2에서의 단계들을 반복할 수 있다.

본 출원에서는, 선택된 서비스 노드가 그렇게 할 수 있으면 신규 서비스를 추가하라는 요청을 항상 수락한다고 가정된다. 그러나, 선택된 서비스 노드는 그렇게 할 수 있더라도 신규 서비스를 추가하라는 요청을 거절할 수 있다. 이것은 특정 이유들 때문일 수 있다. 예를 들어, 선택된 서비스 노드가 최신 트래픽 로드로 인해 신규 서비스를 추가하지 않으려고 하기 때문일 수 있다. 선택된 서비스 노드는 도 14에서 위에 설명된 사례 2에서의 동작들을 따를 것이다. SLE 2는 선택 프로세스로부터의 결과인 순위화된 리스트에서의 다음 서비스 노드에 요청을 전송할 것이며, 이는 도 13에 상세화된다. 모든 선택된 서비스 노드들이 신규 서비스를 추가할 수 없거나 신규 서비스를 추가하려고 하지 않는다면, 애플리케이션 서비스 제공자는 통지를 받을 것이고, 예를 들어, 선택 기준을 조정하거나 신규 서비스를 추가하는 요청을 취소하는 추가의 액션들이 취해질 것이다. 본 출원에 따르면, 다수의 서비스 노드들이 선택되면, 서비스 노드 선택 프로세스를 수행하는 SLE 2가 이들 각각에 요청을 각각 전송할 것이다. 요청들이 모든 서비스 노드들에 공통적이면 각각의 선택된 서비스 노드에 대한 요청들이 종합될 수 있다. 또한, 다수의 신규 서비스들을 추가하기 위해 서비스 노드가 선택되면, 선택된 서비스 노드는 보다 효율적인 처리를 위해 각각의 신규 서비스를 추가하는 프로시저들을 종합할 수 있다.

다수의 신규 서비스들을 추가하는 종합 프로시저들

본 발명의 다른 양상에 따르면, 서비스 노드는 효율성을 향상시키기 위해 각각의 신규 서비스를 추가하는 다수의 프로시저들을 종합하려고 시도할 수 있다. 일반적으로, 이러한 종합은 신규 서비스를 추가하는 프로세스 이전에, 그리고 협력 및 서비스 노드 선택 프로세스들 이후에 수행된다. 다수의 신규 서비스들을 추가하는 프로시저 종합은 통신 효율성을 향상시킬 수 있다. 예를 들어, 일 실시예에서, 상이한 신규 서비스들을 추가하는 몇몇 요청들이 동일한 서비스 노드에 예정될 수 있다. 달리 말하면, 다수의 신규 서비스들을 추가하기 위해 SLE가 선택되고, 따라서 각각의 신규 서비스를 추가하라는 요청들이 종합되어 선택된 노드에 전송된다. 따라서, 선택된 엔티티는 모든 신규 서비스들을 추가하는 하나의 프로시저를 수행할 수 있을 것이다.

다른 실시예에 따르면, 신규 서비스를 추가하는 하나의 공통 요청이 다수의 서비스 노드들에 예정될 수 있다. 달리 말하면, 다수의 서비스 레이어 엔티티들이 신규 서비스를 추가하도록 선택된다. 따라서, 신규 서비스를 추가하기 위해 모든 노드들에 하나의 요청이 전송된다.

양자 모두의 경우, 서비스 노드 선택 프로세스를 수행하는 SLE는 요청들을 종합할 수 있는지 조사할 것이다. 또한, 선택된 서비스 노드는 신규 서비스들을 추가하는 다수의 프로시저들을 종합할 수 있는지 조사할 것이다.

도 15a는 위에 언급된 실시예들을 고려하여 종합의 프로시저들을 도시한다. 즉 도 15b는 M2M 애플리케이션(1 및 2)에 의해 각각 2개의 신규 서비스들이 제공되고, M2M 서버(1c)가 서비스 노드 선택을 수행하고, 양쪽 신규 서비스들 모두를 추가하기 위해 M2M 서버(1d)를 선택하는 종합 프로시저들을 도시한다. 단계들 각각은 도 15a에서 로마 숫자로 표기된다. 단계 1에서는, 협력 및 서비스 노드 선택 프로세스 이후, M2M 서버(1c)가 종합이 가능한지 조사한다. 즉, 이것은 2개의 양상들에 대해 체크할 것이다. 첫째는 다수 메시지들 대 하나의 목적지 서비스 노드이다. 둘째는 하나의 공통 메시지 대 다수의 서비스 노드들이다. 이러한 경우, M2M 서버(1c)는 양쪽 신규 서비스들을 추가하라는 요청들이 동일한 M2M 서버(1d)에 예정된다고 결정한다. 이와 같이, 2개의 요청들을 종합하기로 결정한다. 단계 2에서는, 종합된 요청 메시지가 M2M 서버(1d)에 전송된다. 요청 메시지는 양쪽 서비스들의 서비스 정보, 양쪽 서비스들의 정책들 및 선택 결과들을 포함할 수 있다. 단계 3에서, 신규 서비스들을 추가하기 이전에, M2M 서버(1d)가 2개의 신규 서비스들을 추가하는 프로세스를 종합할 수 있는지 체크한다. 또한, M2M 서버(1d)는 2개의 신규 서비스들을 1개의 프로세스를 통해 추가한다(단계 4).

도 15b에 도시되는 바와 같은 다른 실시예에 따르면, 신규 서비스가 M2M 애플리케이션(1)에 의해 제공되고, M2M 서버(1c)는 M2M 게이트웨이(1a), M2M 서버(1d 및 1e)를 선택하여 신규 서비스를 추가하는 서비스 노드 선택을 수행하는 것으로 가정된다. 단계 1에서는, 협력 및 서비스 노드 선택 프로세스 이후, M2M 서버(1c)가 사례 1에 대한 단계 1과 동일한 방식을 따라 종합이 가능한지 조사한다. 신규 서비스를 추가하는 공통 요청이 다수 서비스 노드들에 예정된다. 단계 2에서는, M2M 서버(1c)가 상이한 서비스 노드들에 요청을 종합하기로 결정하며, 이들은 신규 서비스를 추가하도록 요청된다. 요청 메시지에는, 모든 목적지 서비스 노드의 ID들이 포함된다. 단계 3에서는, 각각의 선택된 서비스 노드가, 기존의 메커니즘들, 예를 들어 위에 설명된 방법들에 따라, 각각 신규 서비스를 추가한다. 종합 프로세스는 서비스 노드 선택 프로세스 이후에 발생하지만, 종합은 서비스 노드 선택 프로세스에 의해 고려되는 인자들 중 하나일 수 있다. 다시 말해서, 종합은 신규 서비스들을 추가할 서비스 노드를 선택할 때 성능을 최적화하는 기준 중 하나일 수 있다.

OneM2M RESTful(RoA) 기능적 아키텍처 실시예

도 16은 협력 및 서비스 노드 선택 기능성을 지원하기 위해 기존 oneM2M 기능적 아키텍처를 강화하기 위한 예시적인 실시예를 도시하며, CSNS(Collaboration and Service Node Selection) 기능들이 SEF(Service Enabler Function)의 일부로서 구현된다. 이러한 2개의 기능들이 CSE 내부의 독립형 CSF들로서 제공되는 것이 또한 가능할 수 있다. 협력 정책 및 서비스 노드 선택 기준과 함께, 착수자는, RESTful 리소스들의 포맷으로, 신규 서비스를 추가하는데 필요한 정보를 포함한다. 둥근 모서리가 있는 사각형은 속성들을 표시한다. "<>"는 서브-리소스로서 정의된 정보를 표시한다. 서브-리소스는 속성들에 의해 추가로 정의될 수 있다. 도 17은 <serviceEnablementPolicy> 리소스의 구조를 도시하며, 이는 신규 서비스를 추가하는 협력에 관한 상이한 양상들로 구성된다.

<serviceEnablementPolicy> 리소스의 속성들은 아래 표 4에서 추가로 설명된다.

신규 속성 "serviceNodeSelectionCriteria"는 아래 표 5에서 설명된다. 이러한 신규 속성은, 예를 들어, <AE> 및 <CSEBase> 리소스들과 같은, 다양한 타입들의 리소스들 하에 추가될 수 있다.

본 출원에 따르면, 본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 전부는 컴퓨터 판독 가능 저장 매체에 저장되는 컴퓨터 실행 가능 명령어들, 예를 들어, 프로그램 코드의 형태로 구현될 수 있으며, 이러한 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행될 때, 본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 점이 이해된다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행 가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독 가능 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비-이동식 매체를 포함하지만, 이러한 컴퓨터 판독 가능 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독 가능 저장 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD ROM, DVD(digital versatile disks) 또는 다른 광 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다.

본 출원의 또 다른 양상에 따르면, 컴퓨터 판독 가능 또는 실행 가능 명령어들을 저장하기 위한 비-일시적 컴퓨터 판독 가능 또는 실행 가능 저장 매체가 개시된다. 이러한 매체는 도 6 내지 도 9, 도 11 내지 도 13 및 도 14 내지 도 15에 따른 복수의 호출 흐름들에 위에 개시된 것과 같은 하나 이상의 컴퓨터 실행 가능 명령어들을 포함할 수 있다. 이러한 컴퓨터 실행 가능 명령어들은 도 1c 및 도 1d에서 위에 개시된 메모리에 저장되고 프로세서에 의해 실행될 수 있으며, 서비스 노드, 게이트웨이 및 서버를 포함하는 디바이스들에서 이용될 수 있다. 일 실시예에서는, 도 1c 및 도 1d에서 위에 설명된 바와 같이, 비-일시적 메모리 및 이에 동작 가능하게 연결되는 프로세서를 갖는 컴퓨터 구현 UE가 개시된다. 구체적으로, 비-일시적 메모리는 oneM2M 서비스를 추가하기 위한 명령어들을 저장한다. 프로세서는 다음 명령어들 중 하나 이상을 수행하도록 구성된다: (i) 서비스 인에이블먼트 정책을 구성함; (ii) 서비스 제공자로부터 서비스를 추가하라는 요청을 수신하함; (iii) 서비스를 추가하기 위해 서비스 인에이블먼트 정책을 체크함; (iv) 서비스 제공자에게 회신을 전송함.

OneM2M SOA(Service Oriented Architecture) 실시예들

본 섹션은 제안된 메커니즘들과 정보를 oneM2M SoA 시스템에 어떻게 적용하는지 보여주는 실시예를 제시한다. 도 18은 협력 및 서비스 노드 선택 기능들을 oneM2M SoA(service component architecture)에 적용하는 아키텍처를 도시하며, CSNS(Collaboration and Service Node Selection)는 서비스 인에이블러 컴포넌트들의 일부로서 구현된다. RoA에 대해 위에서 제안된 프로시저들이 SoA 아키텍처에 적용될 수 있다.

oneM2M ROA에 기초하는 DM(Device Management) 실시예들

본 섹션은 제안된 메커니즘들과 정보를 oneM2M 기능적 아키텍처에 기초하여 기본 디바이스 관리 프로토콜에 어떻게 적용하는지 보여주는 실시예를 제시한다.

신규 서비스를 추가하기 위해, 기본 디바이스 관리 프로토콜(예를 들어, OMA DM 또는 BBF TR-069)은 서비스 능력을 제공하는 소프트웨어를 설치하여 신규 서비스를 추가하는 것을 관리할 수 있다. 신규 서비스를 추가하기 위한 DM 프로토콜을 용이하게 하기 위해, oneM2M 서비스 레이어는 충분한 정보, 예를 들어, 신규 서비스에서 정의되는 서비스 인에이블먼트 정책 및 서비스 노드 선택 기준을 제공하는 것을 담당한다. oneM2M 기능적 아키텍처에 기초하여, 예를 들어, 리소스 <mgmtObj>는 이러한 정보를 유지하는데 사용될 수 있어, 기본 DM 기술이 리소스에서의 정보를 그것이 사용하는 데이터 모델로 변환할 수 있다.

구체적으로, [serviceEnablementPolicy]는 도 19에 도시되는 바와 같이 서비스 노드 상에 신규 서비스를 추가하는 정책에 관한 정보를 공유하도록 정의된다. [serviceEnablementPolicy]의 리소스 타입은 <mgmtObj> 리소스이다. [serviceEnablementPolicy] 리소스의 속성들은 위에 설명된다.

이러한 파라미터들은 서비스 인에이블먼트 정책/선택 기준 및 서비스 설명에 관한 신규 서비스를 인에이블하기 위해 정의된다. 사용자 인터페이스는, 신규 서비스를 정의하기 위한 특정 특징들을 인에이블하기 위한 또는 디스에이블하기 위한 제어 스위치들 뿐만 아니라, 디폴트 값들로서 이러한 파라미터들을 구성하기 위해 또는 프로그래밍하기 위해 구현될 수 있다. 예시적인 사용자 인터페이스가 도 20에 도시된다. 도 20의 그래픽 사용자 인터페이스는 도 1c에 도시되는 디스플레이(42) 또는 도 20에 도시되는 디스플레이(86)에 디스플레이될 수 있다. 이렇게 함으로써, 사용자들은 그래픽 사용자 인터페이스를 통해 특징들을 제어할 수 있다.

시스템들 및 방법들이 현재 구체적인 양상들인 것으로 고려되는 것의 면에서 설명되었지만, 본 출원이 개시된 양상들에 제한될 필요는 없다. 청구항들의 사상 및 범위 내에 포함되는 다양한 수정들 및 유사한 배열들을 포함하도록 의도되며, 그 범위는 모든 이러한 수정들 및 유사한 구조들을 포괄하도록 가장 넓은 해석에 따라야 한다. 본 개시내용은 다음의 청구항들의 임의의 그리고 모든 양상들을 포함한다.

Claims (20)

1. 네트워크 상의 디바이스로서,
   서비스를 추가하기 위해 실행 가능한 명령어들을 포함하는 비-일시적 메모리; 및
   상기 메모리에 동작 가능하게 연결되는 프로세서
   를 포함하고, 상기 프로세서는,
   서비스 제공자로부터 상기 서비스를 추가하라는 요청을 수신하도록;
   상기 서비스를 추가하기 위해 서비스 인에이블먼트 정책 및 호스트 선택 기준을 체크하도록;
   상기 서비스 인에이블먼트 정책과 상기 호스트 선택 기준을 조화시키기 위해 다른 디바이스와 협력하도록; 그리고
   상기 서비스 제공자에게 회신을 전송하도록
   적응되는 디바이스.
2. 제1항에 있어서,
   상기 서비스 인에이블먼트 정책은 협력 인에이블먼트 표시, 적격 협력 엔티티 타입, 협력 범위, 협력 콘텐츠, 협력 트리거 조건들, 서비스 노드 범위, 적격 서비스 노드 타입, 최대 서비스 노드 수, 최소 서비스 노드 수, 서비스 제공자까지의 최대 거리, 서비스 레이어 클라이언트들까지의 최대 거리, 서비스 노드 선택 인에이블먼트, 적격 타입의 선택 엔티티, 서비스 제공자 확인, 종합 인에이블먼트, 적격 타입의 종합 엔티티, 종합 윈도우, 인에이블된 종합 시나리오, 서비스 공급 범위, 액세스 권한이 있는 클라이언트들의 리스트, 및 이들의 조합으로부터 선택되는 디바이스.
3. 제1항에 있어서,
   상기 프로세서는 서비스 노드 선택을 용이하게 하기 위한 기준을 수신하도록 추가로 구성되는 디바이스.
4. 제3항에 있어서,
   상기 기준은 서비스 노드 위치, 서비스 도메인 요건, 액세스 제어, 기본 네트워크 프로토콜, 디바이스 관리, 로드 밸런스, 서비스 노드 타입, 지원되는 API, 보안, 데이터 스토리지, 종합 선호도, 및 이들의 조합으로부터 선택되는 디바이스.
5. 제3항에 있어서,
   상기 프로세서는 상기 서비스 인에이블먼트 정책 및 상기 기준을 조화시키도록 추가로 구성되는 디바이스.
6. 제3항에 있어서,
   상기 프로세서는 상기 서비스 제공자로부터 수신되는 상기 요청에 협력하도록 추가로 구성되는 디바이스.
7. 제6항에 있어서,
   상기 프로세서는 상기 서비스 인에이블먼트 정책 및 상기 기준을 충족시키는 서비스 노드를 결정하도록 추가로 구성되는 디바이스.
8. 제7항에 있어서,
   상기 프로세서는 상기 서비스를 추가하라는 요청을 상기 서비스 노드에 전송하도록 추가로 구성되는 디바이스.
9. 제3항에 있어서,
   상기 프로세서는 상기 서비스 노드로부터 수락을 수신하도록 추가로 구성되는 디바이스.
10. 제8항에 있어서,
    상기 프로세서는,
    복수의 신규 서비스들의 종합이 가능한지 체크하도록; 그리고
    상기 복수의 서비스들을 추가하라는 요청을 상기 서비스 노드에 전송하도록
    추가로 구성되는 디바이스.
11. 제1항에 있어서,
    서버, 단말 디바이스 또는 M2M 게이트웨이 디바이스로부터 선택되는 디바이스.
12. 서비스를 추가하기 위한 방법으로서,
    서비스 인에이블먼트 정책을 구성하는 단계;
    서비스 제공자로부터 상기 서비스를 추가하라는 요청을 수신하는 단계;
    상기 서비스를 추가하기 위해 상기 서비스 인에이블먼트 정책을 체크하는 단계;
    상기 서비스 인에이블먼트 정책과 호스트 선택 기준을 조화시키기 위해 다른 디바이스와 협력하는 단계; 및
    상기 서비스 제공자에게 회신을 전송하는 단계
    를 포함하는 방법.
13. 제12항에 있어서,
    서비스 노드 선택을 용이하게 하기 위한 기준을 수신하는 단계를 더 포함하는 방법.
14. 제13항에 있어서,
    상기 서비스 인에이블먼트 정책과 상기 기준을 조화시키는 단계를 더 포함하는 방법.
15. 제14항에 있어서,
    상기 서비스 인에이블먼트 정책 및 상기 기준을 충족시키는 서비스 노드를 결정하는 단계를 더 포함하는 방법.
16. 제14항에 있어서,
    상기 서비스를 추가하라는 요청을 상기 서비스 노드에 전송하는 단계를 더 포함하는 방법.
17. 제16항에 있어서,
    복수의 신규 서비스들의 종합이 가능한지 체크하는 단계; 및
    상기 복수의 서비스들을 추가하라는 요청을 상기 서비스 노드에 전송하는 단계
    를 더 포함하는 방법.
18. 제13항에 있어서,
    프로세서는 상기 서비스 제공자로부터 수신되는 상기 요청에 협력하도록 추가로 구성되는 방법.
19. 제12항에 있어서,
    상기 서비스 인에이블먼트 정책은 협력 인에이블먼트 표시, 적격 협력 엔티티 타입, 협력 범위, 협력 콘텐츠, 협력 트리거 조건들, 서비스 노드 범위, 적격 서비스 노드 타입, 최대 서비스 노드 수, 최소 서비스 노드 수, 서비스 제공자까지의 최대 거리, 서비스 레이어 클라이언트들까지의 최대 거리, 서비스 노드 선택 인에이블먼트, 적격 타입의 선택 엔티티, 서비스 제공자 확인, 종합 인에이블먼트, 적격 타입의 종합 엔티티, 종합 윈도우, 인에이블된 종합 시나리오, 서비스 공급 범위, 액세스 권한이 있는 클라이언트들의 리스트, 및 이들의 조합으로부터 선택되는 방법.
20. 제12항에 있어서,
    상기 기준은 서비스 노드 위치, 서비스 도메인 요건, 액세스 제어, 기본 네트워크 프로토콜, 디바이스 관리, 로드 밸런스, 서비스 노드 타입, 지원되는 API, 보안, 데이터 스토리지, 종합 선호도, 및 이들의 조합으로부터 선택되는 방법.

Images