KR20180043385A - 서비스 인에이블러 기능 - Google Patents

Abstract

본 출원은 네트워크의 서비스 계층 기능에서 서비스를 갱신하기 위한 방법 및 장치를 기술한다. 특히, 서비스를 추가하기 위한 방법이 개시된다. 초기에, 서비스 계층 기능 내에 위치하는 서비스 인에이블러 기능에서 서비스를 추가하라는 요청이 수신된다. 요청된 서비스의 서비스 설명을 검토하여 그 능력을 이해한다. 검증 요청은 서비스 계층 기능 내에 위치하는 서비스 능력으로 전송된다. 또한, 요청된 서비스가 인에이블링하는 것이 다른 서비스 계층 기능 또는 애플리케이션에 통지된다.

Description

서비스 인에이블러 기능{SERVICE ENABLER FUNCTION}

<관련 출원들>

이 출원은 "Apparatus and Method for Service Enabler function"이라는명칭으로, 2014년 4월 9일에 출원된 미국 가출원 제61/977,382호에 대한 우선권을 주장하며, 그 내용은 전체가 본 명세서에 포함된다.

<본 출원의 분야>

본 출원은 시스템의 운용성(operability)에 영향을 주지 않고 서비스 계층 내의 서비스들을 개선하기 위한 장치들 및 방법들에 관한 것이다. 더 구체적으로, 본 출원은 서비스 인에이블러 기능을 이용하여 미들웨어 서비스 계층들 상의 서비스들을 개선하는 것에 관한 것이다.

최근에, 사용자들은 그들의 서비스 제공자들로부터 정적인 서비스들을 받는 것에 익숙해졌다. 정적인 서비스들은 새로운 서비스들이 시스템에 추가될 때 서비스 플랫폼이 갱신된 능력들 및 피처들과 재동기화될 때 발생한다. 즉, 서비스 플랫폼은 새로운 서비스를 시스템에 통합하기 위해 그것의 리소스들을 재조직화하고 그것의 능력들 및 피처들을 재구성할 필요가 있다. 더욱이, 서비스 플랫폼과 협력하는 모든 애플리케이션들 및 다른 서비스 플랫폼들도 그들의 구성들을 갱신 및/또는 재설정해야 한다. 예를 들어, M2M 시스템에서 새로운 서비스를 추가하는 데에는 사양에 대한 수정들을 필요로 하는 새로운 유형의 리소스를 정의하는 것이 필요할 수 있다. 이러한 추가적인 단계들은 사용자들에 대해 증가된 중지 시간(downtime) 및 비효율성을 야기할 수 있다.

더욱이, 기존의 디바이스 관리(DM) 프로토콜들은 소프트웨어 관리 기능성을 포함하지만, 이러한 DM 프로토콜들은 서비스 인식(service aware)이 아니다. 다시 말해서, 이러한 DM 프로토콜들은 디바이스들에의 소프트웨어 모듈들의 다운로딩 및 설치, 예를 들어, 소프트웨어 인에이블링을 지원하기 위해서만 구성된다. 그러나, 이러한 DM 프로토콜들은 소프트웨어 모듈에 의해 제공되는 서비스에 투명하다. 또한, 이러한 DM 프로토콜들은 서비스 계층의 클라이언트들이 사용하도록 서비스 계층에 서비스들을 구성/통합하기 위한 추가적인 관리 기능성이 없다.

하나의 애플리케이션에서, 예를 들어, 유니버설 플러그 앤 플레이(UPnP)는 네트워크 디바이스들이 서로를 심리스하게 발견하고 기능적 네트워크 서비스들을 설정할 수 있게 하는 프로토콜들의 세트를 포함한다. UPnP는 애플리케이션 계층 및 IP 계층에 집중하는 것으로 일반적으로 이해된다. UPnP는 플러그인 후에 어떻게 네트워크 디바이스가 다른 네트워크 디바이스들을 발견하고 또한 다른 네트워크 디바이스들에 의해 발견되는지에 대한 방법들을 포함한다. UPnP는 또한 어떻게 IP 주소를 새로운 플러그인 디바이스에 자동으로 할당하는지, 어떻게 새로운 디바이스가 구성을 자동으로 설정하는지, 및 어떻게 디바이스가 네트워크 서비스들을 인지하고 이용하는지를 포함한다. 그러나, UPnP는 모든 네트워크 클라이언트들이 새로운 서비스를 인지하고 이용할 수 있도록 서비스 계층에 새로운 서비스를 동적으로 통합하지는 못한다.

본 기술분야에서 요구되는 것은 서비스 계층에 새로운 서비스들을 구성 및 통합하기 위한 장치 및 방법이다.

본 기술분야에서 또한 요구되는 것은 시스템의 운용성에 영향을 주지 않고 서비스 계층에서 시스템에 서비스를 동적으로 추가하기 위한 장치 및 방법이다.

본 기술분야에서 또한 요구되는 것은 시스템의 운용성에 영향을 주지 않고 서비스 계층에서 시스템에서 서비스를 동적으로 제거 및/또는 비활성화하기 위한 장치 및 방법이다.

본 기술분야에서 또한 요구되는 것은 서비스 API를 관리하는 관리 기능성을 갖는 아키텍처이다.

이 요약은 아래의 상세한 설명에서 더 설명되는 개념들의 발췌를 간단한 형태로 소개하기 위해 제공된다. 이 요약은 청구된 주제의 범위를 제한하기 위한 것이 아니다. 상기한 요구들은 시스템 상호운용성에 영향을 주지 않고 서비스 계층에서 서비스를 동적으로 추가하고, 활성화하고, 비활성화하고, 제거하기 위한 프로세스 및 장치에 관련된 본 출원에 의해 대부분 충족된다.

본 출원의 하나의 양태는 네트워크 내의 서비스 계층에서 서비스를 추가하기 위한 방법에 관련된다. 상기 방법은 서비스 계층에 위치하는 서비스 인에이블러 기능에서 서비스를 추가하라는 요청을 수신하는 단계를 포함한다. 상기 방법은 또한 상기 요청된 서비스의 서비스 설명을 검토하여 그것의 능력들을 이해하는 단계를 포함한다. 다음으로, 상기 서비스 계층에 위치하는 서비스 능력에 검증 요청이 송신된다. 또한, 상기 요청된 서비스가 인에이블링되는 다른 서비스 계층들 또는 애플리케이션들이 통지된다. 일 실시예에서, 상기 서비스 설명은 서비스 제공자 ID, 서비스 ID, 종속 서비스들의 목록, 고유 서비스 API, 공통 서비스 API, 상기 서비스의 위치, 인증 방법, 허가 및 액세스 제어 정보, 소프트웨어 모듈 정보, 프로토콜 지원, 서비스 호환성, 과금 정책 및 이들의 조합들로부터 선택된다.

본 출원의 또 다른 양태는 서비스를 갱신하기 위해 네트워크의 서비스 계층에 위치하는 컴퓨터로 구현되는 서비스 인에이블러 장치에 관련된다. 상기 장치는 서비스 계층, 애플리케이션들, 또는 다른 서비스 계층들에서의 기존의 서비스 능력과의 처리 및 통신을 조정하도록 구성된 서비스 조정 기능(SCF)을 포함한다. 상기 장치는 또한 서비스 계층에서의 서비스의 상태 전이를 관리하도록 구성되는 서비스 상태 관리 및 구성 기능(SMCF)을 포함한다. 또한, 상기 장치는 서비스가 갱신될 때 서비스 API를 관리하도록 구성되는 서비스 API 관리 기능(SAMF)을 포함한다. 일 실시예에서, 상기 SCF, SMCF 및 SAMF는 서로 통신한다.

본 발명의 상세한 설명이 더 잘 이해될 수 있도록 하기 위해, 그리고 본 기술분야에의 본 발명의 기여가 더 잘 인식될 수 있도록 하기 위해 본 발명의 소정의 실시예들이 다소 광범위하게 약술되었다. 물론, 아래에 설명될 그리고 본 명세서에 첨부된 청구항들의 주제를 형성할 본 발명의 추가적인 실시예들이 존재한다.

이제 본 출원의 더 충실한 이해를 돕기 위해, 유사한 요소들이 유사한 번호들로 참조되는 첨부 도면들을 참조한다. 이 도면들은 본 출원을 제한하는 것으로 해석되어서는 안되며 단지 예시를 위한 것이다.
도 1a는 M2M(machine-to machine) 또는 IoT 통신 시스템의 실시예를 예시한다.
도 1b는 M2M 서비스 플랫폼의 실시예를 예시한다.
도 1c는 예시적인 M2M 디바이스의 시스템 다이어그램의 실시예를 예시한다.
도 1d는 예시적인 컴퓨팅 시스템의 블록도의 실시예를 예시한다.
도 2a는 본 출원의 실시예에 따른 새로운 서비스를 갱신하기 위한 구성의 사용자 인터페이스를 예시한다.
도 2b는 네트워크 내의 서비스 계층의 배치 시나리오의 실시예를 예시한다.
도 3은 하나 이상의 특정 유형들의 공통 서비스 기능들의 세트의 실시예를 예시한다.
도 4는 서비스 계층 아키텍처의 실시예를 예시한다.
도 5는 서비스 계층에서의 서비스 인에이블러 기능의 실시예를 예시한다.
도 6은 서비스에 대한 복수의 상태 전이의 실시예를 예시한다.
도 7은 서비스에 대한 서비스 API의 실시예를 예시한다.
도 8은 새로운 서비스를 추가하기 위한 방법의 실시예를 예시한다.
도 9는 서비스 인에이블러 기능이 새로운 서비스를 추가하는 방법의 실시예를 예시한다.
도 10은 서비스 계층에 새로운 서비스를 추가할 때 각각의 서비스에 대해 서비스 API를 관리하기 위한 실시예를 예시한다.
도 11은 서비스 계층으로부터 서비스를 제거하기 위한 방법의 실시예를 예시한다.
도 12는 서비스를 비활성화하기 위한 방법의 실시예를 예시한다.
도 13은 서비스 계층에서 서비스를 추가하거나, 활성화하거나, 비활성화하거나, 제거할 때 종속 문제를 다루기 위한 방법의 실시예를 예시한다.
도 14는 서비스 인에이블러 기능을 지원하는 oneM2M 기능적 아키텍처의 실시예를 예시한다.
도 15는 도 14에 따른 서비스 설명 리소스의 구조의 실시예를 예시한다.
도 16은 도 14에 예시된 oneM2M 서비스 계층에 제안된 서비스 인에이블러 CSF를 이용하여 새로운 서비스를 추가하기 위한 방법의 실시예를 예시한다.
도 17은 본 출원에 따른 새로운 서비스 리소스의 실시예를 예시한다.
도 18은 본 출원에 따른 확장 가능 리소스 구조의 실시예를 예시한다.
도 19는 하나의 M2M 서비스 컴포넌트에서의 서비스 인에이블러 기능의 아키텍처의 실시예를 예시한다.
도 20은 새로운 서비스를 추가하는 것에 의해 정보를 교환하기 위한 방법의 실시예를 예시한다.
도 21은 본 출원에 따른 새로운 서비스를 추가하기 위한 또 다른 방법의 실시예를 예시한다.
도 22는 서비스 제공자가 새로운 서비스를 정의할 때 새로운 서비스를 추가하는 방법의 실시예를 예시한다.
도 23은 DM 프로토콜을 통하여 작동하는 서비스 인에이블러 기능을 갖는 아키텍처의 실시예를 예시한다.

본 명세서에서 다양한 도면들, 실시예들 및 양태들에 관련하여 예시적인 실시예들의 상세한 설명이 논의될 것이다. 이 설명은 가능한 구현들의 상세한 예들을 제공하지만, 세부 사항은 예시를 위한 것이며 따라서 본 출원의 범위를 제한하는 것이 아니라는 점에 유의하여야 한다.

이 명세서에서 "일 실시예", "실시예", "하나 이상의 실시예", "양태" 또는 다른 유사한 것의 언급은 그 실시예와 관련해서 설명된 특정한 피처, 구조, 또는 특성이 본 개시의 적어도 하나의 실시예에 포함됨을 의미한다. 더욱이, 본 명세서의 다양한 곳에서의 용어 "실시예"는 반드시 모두가 동일한 실시예를 지칭하는 것은 아니다. 즉, 일부 실시예들에 의해서는 드러나지만 다른 실시예들에 의해서는 드러나지 않을 수 있는 다양한 피처들이 설명된다.

본 출원은 서비스 계층에 의해 호스팅되는 서비스들을 지원하는 M2M/IoT 네트워크들 내의 서비스 인에이블러 기능을 설명한다. 이 서비스 인에이블러 기능은 시스템 상호운용성에 영향을 주지 않고 서비스 또는 기존의 서비스의 버전을 동적으로 추가하고, 활성화하고, 비활성화하고, 제거하는 능력을 제공한다. 다시 말해서, 이 서비스 인에이블러 기능은 서비스를 정의 및/또는 생성하는 것보다는 서비스 계층에서 서비스들을 인에이블링하는 것에 집중한다.

아래에 더 상세히 설명되는 바와 같이, 서비스 계층에서 복수의 서비스들이 이용 가능하고, 이들은 상이한 요건들을 가지고, 상이한 시간들에 생성된다. 이러한 서비스들은 시스템 상호운용성에 영향을 주지 않고 동적으로 관리, 예를 들어, 추가, 활성화, 비활성화 및 제거될 수 있어야 한다. 일 실시예에 따르면, 서비스 계층에 의해 제공되는 서비스들을 현재 이용하는 애플리케이션들은 동적으로 설치되는 새로운 서비스들에 의해, 또는 갱신되는 기존의 서비스들에 의해 영향을 받지 않는다. 또 다른 실시예에 따르면, 상이한 클라이언트들이 서비스의 상이한 버전들을 동시에 이용할 수 있도록 서비스의 다수의 버전들이 지원된다. 또 다른 실시예에 따르면, 시스템으로부터 제거하고자 하는 서비스의 버전이 사용되지 않았을 때 어떤 액션도 요구되지 않는다.

이 출원의 전체에 걸쳐 사용될 일부 공통 용어들이 아래에 제공된다:

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

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

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

서비스 능력: 서비스 계층에 의해 지원되는 특정한 유형의 서비스

서비스 능력 계층: 서비스 계층에 대한 (ETSI) M2M(machine-to-machine) 용어.

공통 서비스 기능(CSF): 서비스 계층에 대한 하나의 M2M 용어.

공통 서비스 엔티티(CSE): 서비스 계층에 대한 하나의 M2M 용어.

플랫폼들

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

일반적인 아키텍처

도 1a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 M2M(machine-to machine) 또는 IoT 통신 시스템(10)의 다이어그램이다. 일반적으로, M2M 기술들은 IoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, 게이트웨이 또는 서비스 플랫폼이 IoT뿐만 아니라 IoT 서비스 계층, 등등의 컴포넌트일 수 있다.

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

도 1a에 도시된 바와 같이, M2M/IoT 통신 시스템(10)은 M2M 게이트웨이 디바이스(14), 및 M2M 단말 디바이스들(18)을 포함할 수 있다. M2M/IoT 통신 시스템(10)에는 원하는 대로 임의의 수의 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)이 포함될 수 있다는 것을 이해할 것이다. 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, 예를 들어, 지그비, 6LoWPAN, 블루투스, 직접 무선 링크, 및 예를 들어 와이어라인을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시된 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 서비스 플랫폼(22)은 또한 데이터를 수집하고 그 데이터를 상이한 유형들의 M2M 애플리케이션들(20)과 호환 가능하도록 변환할 수 있다. M2M 서비스 플랫폼(22)의 기능들은 다양한 방식으로, 예를 들어 웹 서버로서, 셀룰러 코어 네트워크에, 클라우드에, 등등으로 구현될 수 있다.

도 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 게이트웨이에, 등등으로 구현될 수 있다.

도 1b를 또한 참조하면, M2M 서비스 플랫폼은 전형적으로 서비스 계층(26), 예를 들어, 다양한 애플리케이션들 및 버티컬들이 이용할 수 있는 서비스 제공(service delivery) 능력들의 코어 세트를 제공하는, 네트워크 서비스 능력 계층(NSCL)을 구현한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20)이 디바이스들과 상호 작용하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링, 서비스/디바이스 발견 등등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 애플리케이션들에서 이러한 기능성들을 구현하는 부담을 없애어, 애플리케이션 개발을 단순화하고 출시를 위한 비용 및 시간을 감소시킨다. 서비스 계층(26)은 또한 M2M 애플리케이션들(20)이 서비스 계층(26)이 제공하는 서비스들과 관련하여 다양한 네트워크들(12)을 통하여 통신할 수 있게 한다. 일 실시예에서, 서비스 계층에서 인에이블링될 새로운 서비스를 나타내기 위해 사용자 인터페이스가 이용될 수 있다. 또 다른 실시예에서, 사용자 인터페이스는 서비스 계층에서 인에이블링된 새로운 서비스를 나타내기 위해 이용될 수 있다.

예시된 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')은, 제한 없이, 수송, 건강 및 보건, 연결된 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급한 바와 같이, M2M 서비스 계층은, 디바이스들, 게이트웨이들, 및 시스템의 다른 서버들에 걸쳐 실행되어, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱(geo-fencing), 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다. 더욱이, M2M 서비스 계층은 또한 이 출원에서 논의되고 도면들에서 예시된 바와 같은 모바일 디바이스들 및 M2M 서버들/게이트웨이들과 같은 다른 디바이스들과 인터페이스하도록 구성될 수 있다.

본 출원의 양태에 따르면, 등록을 관리하는 방법은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은 API(Application Programming Interface)들 및 기본적인 네트워킹 인터페이스들의 세트를 통하여 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M과 oneM2M 양쪽 모두는 이 방법을 포함할 수 있는 서비스 계층을 이용한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)라고 지칭된다. SCL은 M2M 디바이스(여기서 그것은 디바이스 SCL(DSCL)이라고 지칭된다), 게이트웨이(여기서 그것은 게이트웨이 SCL(GSCL)이라고 지칭된다) 및/또는 네트워크 노드(여기서 그것은 네트워크 SCL(NSCL)이라고 지칭된다) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF(Common Service Function)들, 예를 들어, 서비스 능력들의 세트를 지원한다. 하나 이상의 특정 유형들의 CSF들의 세트의 인스턴스 생성(instantiation)은 상이한 유형들의 네트워크 노드들, 예를 들어, 기반구조 노드, 미들 노드, 애플리케이션-특정 노드에서 호스팅될 수 있는 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)는 실시예와 일관성을 유지하면서 상기한 요소들의 임의의 부분 조합을 포함할 수 있다는 것을 이해할 것이다. 이 디바이스는 센서 유관 데이터의 내장된 시맨틱스 명명(embedded semantics naming)을 위해 개시된 시스템들 및 방법들을 이용하는 디바이스일 수 있다.

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

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

또한, 송신/수신 요소(36)는 단일 요소로서 도 1c에 묘사되지만, 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-이온) 등), 태양광 전지들, 연료 전지들, 및 다른 유사한 것을 포함할 수 있다.

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

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

도 1d는, 예를 들어 도 1a 및 도 1b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있으며, 컴퓨터 판독가능 명령어들은 소프트웨어의 형태로 어느 곳이나 있을 수 있거나, 어떤 수단에 의해서든 이러한 소프트웨어가 저장되거나 액세스된다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)이 작업할 수 있도록 중앙 처리 유닛(CPU)(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)를 포함할 수 있다.

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

서비스 계층

일 실시예에서, 도 2a에 예시된 것과 같은 그래픽 사용자 인터페이스가 새로운 서비스를 인에이블링하기 위해 이용될 수 있다. 새로운 서비스는, 예를 들어, Facebook 또는 eBAY 애플리케이션일 수 있다. 도시된 바와 같이, 서비스 인에이블먼트 정책 또는 서비스 설명은 새로운 서비스들, 예를 들어, 애플리케이션들을 위해 인에이블링될 수 있다. 일 실시예에서, 사용자 인터페이스는 새로운 서비스를 정의하는 소정의 피처들을 인에이블링 또는 디스에이블링하는 것으로 구현될 수 있다.

단순히 서비스 계층들이라고도 알려진, 서비스 계층 기능들은 일반적으로 본 기술분야에서 애플리케이션(들) 아래에 및 애플리케이션 프로토콜 계층, 예를 들어, HTTP, COAP, 등등의 위에 계층화되는 것으로 이해된다. 서비스 계층들은 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 서비스 계층들은 흔히 '미들웨어' 서비스들로서 분류된다. 실시예에 따르면, 도 2b는 시스템(200)의 네트워크 - 네트워크 서비스들 도메인(205) - 내에 서비스 계층(210)을 포함하는 시스템(200)의 배치 시나리오를 예시한다. 서비스 계층(210)은 네트워크 애플리케이션들, 웹, 인터넷, 사업자 네트워크들, 클라우드, 디바이스 애플리케이션들뿐만 아니라 네트워크 노드들 자체에 부가 가치 서비스들을 제공하기 위해 다양한 네트워크 노드들 - 게이트웨이들(215) 및 서버들(216) - 상에 배치된다. 도 2b에서, 게이트웨이들(215)은 셀룰러 네트워크들, WLAN/WPAN/WSN, RFID 네트워크들 및 유선 네트워크들(예를 들어 PLC, xDSL 및 PON)을 포함할 수 있다. 서버들(216)은 디렉터리 서버, 애플리케이션 서버, 스토리지 서버, 관리 서버 및 서비스 서버를 포함할 수 있다. 시스템(200)은 또한 센서들, 액추에이터들, RFID 태그들 및 가상 오브젝션들을 포함하는 디바이스 애플리케이션 도메인(DAD)(220)을 포함할 수 있다. 시스템(200)은 애플리케이션들 및 사용자들을 포함하는 네트워크 애플리케이션 도메인(230)을 포함할 수 있다.

일 실시예에서, M2M/loT 서비스 계층은 특별히 M2M/IoT 유형 디바이스들 및 애플리케이션들에 대한 부가 가치 서비스들을 제공하는 것을 목표로 하는 하나의 유형의 서비스 계층의 일례이다. 여러 산업 표준 단체들, 예를 들어, ETSI M2M 및 oneM2M은 M2M/IoT 유형들의 디바이스들 및 애플리케이션들을 인터넷/Web, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전적 과제들을 다루기 위해 M2M/IoT 서비스 계층들을 개발하고 있다.

M2M 서비스 계층은 애플리케이션들 및 디바이스들에게 서비스 계층에 의해 지원되는 M2M 중심 능력들의 컬렉션에의 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 연결 관리를 포함한다. 이 능력들은 M2M 서비스 계층에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용 가능하게 될 수 있다.

OneM2M 서비스 계층

또 다른 실시예에서, 다양한 하드웨어 및 소프트웨어 내에 쉽게 내장될 수 있는 공통 M2M 서비스 계층에 대한 필요들을 다루는 기술 사양들을 개발하기 위해 oneM2M이 이용된다. 또한, 실제 사용되고 있는 다양한 디바이스들을 전세계적으로 M2M 애플리케이션 서버들과 연결하기 위해 그것에 의존할 수 있다. 하나의 M2M 공통 서비스들 계층은 CSF(Common Service Function)들,예를 들어, 도 3에 도시된 바와 같은, 서비스 능력들의 세트를 지원한다. 하나 이상의 특정 유형들의 CSF들의 세트의 인스턴스 생성(instantiation)은 상이한 유형들의 네트워크 노드들, 예를 들어, 기반구조 노드, 미들 노드, 애플리케이션-특정 노드에서 호스팅될 수 있는 CSE(Common Services Entity)(301)라고 지칭된다. 도시된 바와 같이, CSE(301)는 필드 도메인(302) 및 기반구조 도메인(303)에서 호스팅된다.

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

한편, SoA 아키텍처 레거시 배치는 RESTful 기반이 아니다. 오히려, 그것은 도 4에 도시된 것과 대체로 동일한 서비스 계층 아키텍처(400)를 재사용한다. 여기서, CSE(301)는 점선으로 표시되어 있다. CSE는 예를 들어, 서비스 노출 컴포넌트(410), 서비스 컴포넌트 I(420), 서비스 컴포넌트 N(430), 네트워크 서비스 활용 컴포넌트(440) 및 원격 서비스 노출 컴포넌트(450)를 포함하는 다양한 M2M 서비스들을 포함한다. 기존의 참조 포인트들에 추가하여, CSE(301)는 서비스 간 참조 포인트(inter-service reference point) Msc(460)를 포함할 수 있다. Msc 참조 포인트를 무시하는 M2M 서비스 컴포넌트들 사이의 통신은 웹 서비스들 접근법, 예를 들어, 웹 서비스들 MEP(Message Exchange Patterns)를 이용한다.

범용 플러그-앤-플레이

다른 실시예에 따르면, 본 출원은 범용 플러그 앤 플레이(Universal Plug and Play)(UPnP) 아키텍처에 쉽게 적용할 수 있다. UPnP는, 예를 들어 개인용 컴퓨터들, 프린터들, 인터넷 게이트웨이들, Wi-Fi 액세스 포인트들 및 모바일 디바이스들과 같은 네트워킹된 디바이스들이 네트워크 상의 각각의 다른 존재를 심리스하게(seamlessly) 발견하고 데이터 공유, 통신 및 엔터테인먼트를 위한 기능 네트워크 서비스들을 확립하는 것을 허용하는 한 세트의 네트워킹 프로토콜들이다. UPnP는 엔터프라이즈급 디바이스가 없는 주택지 네트워크들을 위해 주로 의도되고, 디바이스를 동적으로 플러그-인하기 위해 IP 계층 및 애플리케이션 계층에 집중한다. UPnP는 보통 인터넷 기술들을 이용한다. 네트워크는 디바이스/서비스 설명(service description), 액션들, 데이터 전송 및 이벤팅을 제공하기 위해, 인터넷 프로토콜(IP)을 실행하고, 그 후 IP의 상부에서 HTTP, SOAP 및 XML을 레버리지화해야만 한다고 가정한다. UPnP 네트워킹은 다음과 같은 다수의 단계를 포함한다: IP 어드레싱, 발견, 설명(description), 제어, 이벤팅 및 프레젠테이션.

디바이스 관리(DM) 프로토콜들

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

다른 DM 프로토콜은 소프트웨어 컴포넌트 관리 객체(Software Component Management Object)(SCOMO)이다. SCOMO는 디바이스 내에서 원격 소프트웨어 컴포넌트 관리를 가능하게 한다. 관리는, 예를 들어 소프트웨어 컴포넌트(들)의 인벤토리(inventory)의 다운로딩, 설치, 갱신, 제거, 활성화/비활성화, 및 검색과 같은 기능들을 포함하지만 이에 제한되지는 않는다.

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

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

서비스 인에이블러 아키텍처

애플리케이션의 일 양태에 따르면, 도 5에 예시된 바와 같이, 예를 들어 서비스 계층(500)에는 서비스 인에이블러 기능(510)의 아키텍처 뷰가 있다. 이것은 다음과 같은 하이 레벨 기능성을 제공할 수 있다: (ⅰ) 모듈 인증을 체크하는 것; (ⅱ) 노드 리소스들을 체크하는 것; (ⅲ) 기존 모듈들과의 상호운용성을 체크하는 것; (ⅳ) 충돌을 어떻게 처리할지 결정하기 위한 정책 및 권한들을 체크하는 것, 예를 들어 새로운 모듈을 등록하지 않거나 기존 모듈을 등록 해제하는 것 등; (ⅴ) 새로운 모듈을 등록하는 것; (ⅵ) 새로운 모듈에 기인한 새로운 서비스(들)를 서비스들의 리스트에 추가하는 것; (ⅶ) 새로운 서비스 능력들을 반영하기 위해 API 지원을 수정하는 것; 및 (ⅷ) 새로운 모듈을 통합하기 위해 모듈간 통신을 수정하는 것. 일 실시예에서, 등록 및 보안 서비스들은 임의의 서비스를 추가/활성화/비활성화/제거하기 위해 이용될 수 있다. SEF는 네트워크 엔티티들과의 통신 및 하위 기능들, 예를 들어 참조점들을 통한, 서비스 능력, M2M 애플리케이션 및 M2M 서비스 계층들을 포함한다. 서비스 인에이블러 기능은 이하 더 상세히 설명되는 세가지(3) 주요 하위 기능을 포함한다.

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

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

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

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

이하의 표 1은 서비스 인에이블링 프로세스 동안 상이한 참조점들을 통해 교환된 메시지들을 요약한다. 서비스 인에이블링 프로세스는 서비스 계층에서 서비스를 추가하거나, 활성화하거나, 비활성화하거나, 제거하는 프로세스를 의미한다. M2M 애플리케이션들, 다른 M2M 서비스 계층들 및 기본 네트워크는 서비스 인에이블링 프로세스를 트리거하기 위해 서비스 인에이블링 요청을 서비스 인에이블러 기능에 송신할 수 있다. 이 경우에, 기본 네트워크가 서비스 인에이블링 프로세스를 트리거하고; 서비스 인에이블링 요청을 서비스 인에이블러 기능에 직접 송신할 수 있음에 유의해야 한다. 대안적으로, 또한, 서비스 인에이블링 요청을 디바이스 관리 SC에 먼저 송신하고, DM SC가 서비스 인에이블링 프로세스를 개시하기 위해 그 요청을 서비스 인에이블러 기능에 릴레이할 수 있다.

메시지	참조점	요청기	수신기	설명
서비스 능력 검증 요청	a	SCF	서비스 능력	SCF는 서비스 능력에게, 서비스 인에이블링 프로세스가 서비스 능력에 의해 허용되고 지원되는지를 검증하도록 요청한다.
서비스 능력 검증 응답	a	서비스 능력	SCF	서비스 능력이 검증의 결과를 SCF에 리턴한다.
서비스 인에이블링 요청	b	다른 M2M 서비스 계층	SCF	다른 서비스 계층은 이 서비스 계층에서 서비스를 추가하거나, 활성화하거나, 비활성화하거나, 제거하도록 요청한다.
서비스 인에이블링 통지	b	SCF	다른 M2M 서비스 계층	SCF는 다른 서비스 계층에게 서비스 인에이블링 프로세스의 결과를 통지하고, 이것은 다른 서비스 계층에 영향을 미칠 수 있다.
서비스 인에이블링 요청	c	애플리케이션	SCF	애플리케이션은 이 서비스 계층에서 서비스를 추가하거나, 활성화하거나, 비활성화하거나, 제거하도록 요청한다
서비스 인에이블링 통지	c	SCF	애플리케이션	SCF는 애플리케이션에게 서비스 인에이블링 프로세스의 결과를 통지하고, 이것은 애플리케이션에 영향을 미칠 수 있다.
서비스 인에이블링 요청	d	기본 네트워크	SCF	기본 네트워크는 이 서비스 계층에서 서비스를 추가하거나, 활성화하거나, 비활성화하거나, 제거하도록 요청한다.
서비스 인에이블링 통지	d	SCF	기본 네트워크	SCF는 기본 네트워크에게 서비스 인에이블링 프로세스의 결과를 통지한다
서비스 상태 갱신 요청	In	SCF	SMCF	SCF는 SMCF에게 서비스 상태를 갱신하도록 요청한다.
서비스 상태 갱신 응답	In	SMCF	SCF	SMCF는 서비스 상태를 갱신한 후 응답을 리턴한다.
서비스 설명 분석 요청	In	SCF	SMCF	SCF는 SMCF에게 서비스의 능력 및 피처를 이해하기 위해 서비스 설명을 분석하도록 요청한다. 주로 새로운 서비스 프로세스를 추가하기 위한 것이다.
서비스 설명 분석 응답	In	SMCF	SCF	SMCF는 서비스 설명을 분석한 결과를 SCF에 리턴한다. 주로 새로운 서비스 프로세스를 추가하기 위한 것이다.
서비스 API 관리 요청	In	SCF	SAMF	SCF는 SAMF에게 서비스 인에이블링 프로세스 동안 서비스 API를 갱신하도록 요청한다.
서비스 API 관리 응답	In	SAMF	SCF	SAMF는 서비스 API를 관리한 결과들을 SCF로 리턴한다.

표 2는 표 1에서 정의된 메시지들 각각에서 일부 핵심 정보를 강조한다. 표 2에서, 서비스 ID 및/또는 서비스 제공자 ID는 이들 ID가 메시지의 모든 타입에 공통이기 때문에 특정되지 않는다.

메시지	메시지 내의 핵심 정보
서비스 능력 검증 요청	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 서비스 능력이 고려하는 것, 예를 들어 과금, 보안 등 관련된 서비스 능력, 예를 들어 과금 모델, 과금 레이트, 과금 이벤트에 대한 서비스의 피처들 및 방법들
서비스 능력 검증 응답	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 검증 결과들: 서비스의 피처들 및 방법들이 서비스 계층에 의해 인에이블링되고 허용되는지를 나타낸다
서비스 인에이블링 요청	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 서비스 설명: 서비스의 능력 및 피처들을 설명하기 위한 템플릿 소프트웨어 모듈: 이는 옵션이다 소프트웨어 모듈을 다운로드하기 위한 링크(URL)
서비스 인에이블링 통지	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 서비스의 최신 상태 서비스의 능력 및 피처를 검색하기 위한 링크 또는 방법
서비스 상태 갱신 요청	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거
서비스 상태 갱신 응답	상태 관리 결과: 서비스의 새로운 상태
서비스 설명 분석 요청	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 서비스 설명: 서비스의 능력 및 피처들을 기술하기 위한 템플릿
서비스 설명 분석 응답	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거 서비스 설명을 분석하는 것에 의한 서비스의 능력 및 피처들
서비스 API	서비스 인에이블링 액션: 추가, 활성화, 비활성화 또는 제거
관리 요청	관리 액션: 서비스 API의 생성, 갱신 또는 제거 서비스 설명: 서비스의 능력 및 피처들을 기술하기 위한 템플릿. 새로운 서비스를 추가하기 위해서만 포함된다 관리 액션이 갱신하기 위한 것인 경우 콘텐츠가 서비스 API에서 갱신하는데 필요한 것 서비스 API에 액세스하기 위한 링크 또는 방법
서비스 API 관리 응답	서비스 API 관리가 성공적이거나 성공적이지 않다 갱신된 서비스 API에 액세스하기 위한 링크 또는 방법

서비스 상태 관리 및 구성 기능( SMCF )

SMCF의 주요 역할들 중 하나는 서비스 계층에서 서비스의 상태 전이를 관리하는 것이다. 도 6은 서비스 계층에서 서비스의 4가지 주요 상태와, 이들 4가지 상태 사이의 상태 전이를 기술한다. 상태들 중 하나가 '추가된(Added)'이다. '추가된' 상태에서는, 서비스가 처음에 시스템에 삽입되지만 사용할 준비는 되지 않는다. 이런 애플리케이션에 따르면, 추가는 서비스의 능력들 및 피처들이 그 서비스 계층 내의 엔티티들뿐만 아니라, 애플리케이션 및 다른 서비스 계층들과 같은 외부 엔티티들에 의해 인식되고/발견될 수 있다는 것을 의미한다. 서비스 계층은, 예를 들어 새로운 서비스를 추가하는 프로세스 동안, 새로운 서비스가 추가될 때까지 이것을 발견할 수 없거나, 또는 서비스 계층은 서비스 설명을 분석함으로써 새로운 서비스의 일부 지식을 획득한다. 새로운 서비스를 추가하는 요청은, 예를 들어 애플리케이션 및 제3자 서비스 제공자와 같은 외부 엔티티로부터 올 수 있다. 새로운 서비스를 추가하는 프로세스가 실패하면, 서비스가 성공적으로 추가되지 않고 서비스 계층에 의해 인식될 수 없기 때문에, 새로운 서비스에 대해 유지되는 상태가 없게 된다.

다른 상태는 '활성(Active)' 상태이다. 활성 상태에서, 서비스는 사용할 준비가 되어 있다. '활성화(activate)' 동작으로, 서비스의 상태는 '추가된' 또는 '비활성' 상태 중 어느 하나에서 '활성' 상태로 이동한다. 또 다른 상태는 '비활성(Inactive)' 상태이다. 비활성 상태에서, 서비스는 시스템에 이미 있지만 몇몇 이유로 사용할 준비가 되어 있지 않다. 예를 들어, 서비스의 더 오래된 버전은 새로운 버전으로 대체되고 업그레이드된다. 더 오래된 버전은 백업 및 추적 목적을 위해 이용될 수 있다. 다시 말해서 더 오래된 버전의 모든 정보가 유지된다. '비활성화(deactivate)' 동작으로, 서비스의 상태는 '추가된' 또는 '활성' 상태 중 어느 하나에서 '비활성' 상태로 이동한다. 추가적인 상태는 '제거된(Removed)' 상태이다. 제거된 상태에서, 서비스는 서비스 계층으로부터 완전히 제거되고, 이것은 외부 애플리케이션들 및 서비스 계층들이 서비스 발견 메커니즘을 통해 서비스를 발견할 수 없다는 것을 의미한다. '제거' 동작으로, 서비스의 상태는 3가지 상술한 상태 중 임의의 상태로부터 '제거된' 상태로 이동한다. 일 실시예에 따르면, 서비스의 상태 및 정보는 추적 및 통계의 목적을 위해 서비스 계층에 내부적으로 유지될 수 있다.

다른 실시예에서, SMCF의 주요 역할은 서비스를 기술하고 서비스의 능력들 및 피처들을 구성하는 것이며, 따라서 서비스가 클라이언트들, 예를 들어 애플리케이션들 및 다른 서비스 계층들에 의해 인식되고 이용될 수 있게 된다. 서비스 설명은 서비스의 핵심 정보를 제공할 수 있다. 이것은 소프트웨어 모듈로부터 분리된 것일 수 있다. 서비스 설명은 다음의 속성들 중 하나 이상을 포함할 수 있다: (ⅰ) 서비스 제공자 ID, (ⅱ) 서비스 ID; (iii) 종속 서비스들의 리스트; (ⅳ) 서비스들 API(고유 서비스 API 또는 공통 서비스 API); (v) 서비스의 위치; (ⅵ) 인증 방법; (vii) 인가 및 액세스 제어 정보; (viii) 소프트웨어 모듈 정보; (ⅸ) 프로토콜 지원; (x) 서비스 호환성; 및 (xi) 과금 정책. 각각의 속성의 설명은 아래 제공된다.

서비스 제공자 ID: 이 속성은 누가 서비스를 소유하고 제공하는지를 특정한다. 예를 들어, oneM2M 시스템에서, M2M 서비스 제공자는 M2M 서비스 제공자 식별자(M2M Service Provider Identifier)(M2M-SP-ID)에 의해 고유하게 식별된 글로벌이다. 이것은 서비스 제공자에게 할당된 정적 값이다.

서비스 ID: 이 속성은 서비스의 식별을 특정한다. 서비스 ID는 M2M 서비스 제공자 또는 애플리케이션에 의해 제공된 M2M 서비스의 식별자인데, 예를 들어 서비스 ID는 서비스를 제공하는 엔티티에 정의된다. 예를 들어, 서비스 ID는 3개의 세그먼트로 구성될 수 있다. 세그먼트 1은 서비스를 정의하는 것이 애플리케이션 또는 서비스 제공자인지를 나타낸다. 세그먼트 2는 애플리케이션 ID 또는 서비스 제공자 ID를 나타낸다. 세그먼트 3은, 예를 들어 소셜 네트워킹, 응급 또는 센서 기반의 서비스와 같은 서비스의 카테고리를 나타낸다.

종속 서비스들의 리스트: 이 속성은 이 서비스가 의존하는 서비스들/기능들의 리스트, 및 이 서비스가 호환되는 이들 서비스의 대응하는 버전을 특정한다.

서비스 API: 이 속성은 하나의 서비스에 대한 서비스 API가 2개의 부분으로 분할되는 것을 특정한다. 이것은 도 7의 실시예에 도시된다. 2개의 부분은 서비스 계층(700) 내의 공통 서비스 API(701) 및 고유 서비스 API(702)이다. 공통 서비스 API는 서비스의 일부 공통 능력 및 피처를 특정한다. '공통(Common)'은 서비스의 이러한 능력들 및 피처들이, 예를 들어 소프트웨어 모듈 관리, 과금 및 보안과 같은 다른 서비스의 것들과 동일하거나 유사하다는 것을 의미한다. 보통, 공통 서비스 API는 서비스 계층에 호스팅된 모든 서비스들의 능력들 및 피처들을 포함하고, 애플리케이션들은 공통 서비스 API를 이용하여 서비스에 대해 알고 이를 활용한다. 한편, 고유 서비스 API는 서비스의 일부 고유 능력 및 피처를 특정한다. 각각의 서비스는 다른 서비스가 갖지 않은 일부 고유 피처를 가질 수 있다. 예를 들어, 이미지 처리 서비스들은 특수한 기술에 따라 이미지를 압축하기 위해 고유 피처를 제공할 수 있다. 고유 서비스 API는 서비스 계층에 대한 능력 및 피처를 가질 수 있으며, 이것은 또한 기저 프로토콜 계층에 의해 제공되는 능력 및 피처들을 가질 수 있다. 예를 들어, oneM2M에서, 디바이스 관리 서비스는 기본 네트워크 서비스 엔티티(Network Service Entity)(NSE)에서 DM 프로토콜에 의해 제공되는 일부 능력을 갖는다. 이들 능력은 CSE 내의 DMG CSF를 통해 서비스 계층들에 노출된다.

일 실시예에서, 서비스를 이용하기 위해, 클라이언트는 서비스의 공통 서비스 API를 먼저 사용하여 일부 정보를 검색할 필요가 있고, 그 후 필요하다면 고유 서비스 API를 이용하여 서비스에 액세스하고/하거나 이를 활용한다. 공통 서비스 API는 클라이언트가 고유 서비스 API에 어떻게 액세스하고 어떻게 이용하는지에 대한 방법 또는 링크를 포함할 수 있다. 그러나 일부 경우에, 고유 서비스 API는 서비스 소비자들이 관심을 갖지 않는 일부 내부 능력을 포함할 수 있기 때문에, 클라이언트가 고유 서비스 API를 이용하는 것이 필요하지 않다. 이러한 경우에, 고유 서비스 API는 클라이언트를 위한 블랙 박스로서 역할을 한다. 예를 들어, 이미지 처리 서비스의 고유 서비스 API는 이미지 압축을 어떻게 할지를 나타내기 위해 일부 속성 또는 파라미터를 포함하지만, 그 서비스를 이용하는 클라이언트들은 이들 파라미터를 알 필요가 없고, 따라서 클라이언트들이 고유 서비스 API를 이용하지 않게 될 것이다. 다른 예에서, 서비스 계층에서의 디바이스 관리 서비스는 기저 DM 프로토콜에서 고유 서비스 API를 갖지만, DM 서비스를 이용하는 디바이스는 고유 서비스 API를 알 필요가 없다.

서비스의 위치: 이 속성은 서비스가 추가되는 장소를 특정한다. 이 속성은 클라이언트가 서비스의 위치를 찾고, 서비스 발견을 행하고 서비스를 이용하는 것을 돕는데 사용된다. 예를 들어, oneM2M 시스템에서, 서비스는 기반구조 노드 또는 미들 노드에 추가될 수 있다.

인증 방법: 이 속성은 2개의 목적을 위해 사용되는 인증 방법들을 특정한다. 제1 목적은 이 서비스를 이용하기를 원하는 클라이언트가 인증 방법을 수행하는 경우이다. 제2 목적은 서비스가 인에이블링하거나 디스에이블링할 때 서비스 계층이 인증 방법을 수행하는 경우이다.

인가 및 액세스 제어 정보: 이 속성은 클라이언트가 서비스를 이용하기를 원하는 서비스의 액세스 제어 정보 및 인증 방법을 특정한다.

소프트웨어 모듈 정보: 이 속성은, 예를 들어 소프트웨어 모듈 ID, 사이즈, 버전 및 사용자 명령과 같은, 서비스 계층 및/또는 기저 프로토콜 계층에서 서비스를 지원하는 데 사용되는 소프트웨어 모듈의 정보를 특정한다. 이 속성은 버전 제어 및 소프트웨어 모듈 관리 목적을 위해 사용된다.

프로토콜 지원: 이 속성은, 예를 들어 애플리케이션 프로토콜 계층에서의 HTTP/CoAP, 전송 계층에서의 TCP/UDP와 같은, 이런 서비스를 지원하기 위해 서비스 계층 및 기본 네트워크에 어떤 타입들의 프로토콜들이 요구되는지를 특정한다.

서비스 호환성: 이 속성은 이전 버전들에 대한 서비스의 버전의 호환성을 특정한다.

과금 정책: 이 속성은 서비스가, 예를 들어 과금 모델, 과금 이벤트 및 과금 레이트와 같은 과금 프로세스를 어떻게 수행하는지를 특정한다.

서비스 조정 기능(SCF)

실시예에 따르면, 서비스를 추가, 활성화, 비활성화 및 제거하는 프로세스 동안에, 서비스 인에이블러 기능은 기존의 서비스 능력들, 애플리케이션들 및/또는 다른 서비스 계층들과 통신할 필요가 있다. 표 1 및 2는 상이한 기준 포인트들 위의 SCF와 다른 엔티티들과의 사이의 메시지 교환을 요약한다. 특히, SCF는 서비스 계층에서 서비스의 임의의 갱신에 관한 다음과 같은 통신들을 구동 및 조정할 책임이 있다:

SCF는 서비스 인에이블러 기능 내에서 서비스 상태 관리 및 구성 기능(SMCF)과 서비스 API 관리 기능(SAMF)과 통신한다. 예를 들어, SCF는 서비스의 상태를 갱신하라는, 예를 들어, 추가, 활성화, 비활성화 또는 제거하라는 요청이 있는 경우 SMCF와 통신을 개시하여, SMCF가 서비스의 상태를 갱신하거나 서비스의 능력 및 피처를 구성할 수 있게 한다. SMCF는 구성 및 상태 관리의 결과를 SCF로 리턴하게 되는데, 이는 다음 단계의 동작들을 개시하기 위해 그 결과들을 이용하게 한다.

또한, SCF는 갱신되는 서비스에 대한 서비스 API를 갱신하기 위해, 예를 들어, 추가, 활성화, 비활성화 또는 제거하기 위해, SAMF와의 통신을 개시한다. SCF는 SAMF에 서비스 정보를 전송한다. 차례대로 SAMF는 그에 따라 서비스 API를 갱신한다.

또 다른 실시예에서, 통신들은 서비스 계층 내의 기존 서비스 능력들을 이용하여 수행될 수 있다. 그 목적은 상태 갱신이 서비스 계층의 정책들을 따르는 것을 확실히 하는 것이다. 또한, 상기 목적은 서비스의 능력 및 피처들이 서비스 계층에 의해 인에이블링되고 지원되는 것을 보장하는 것이다. 예를 들어, 새로운 버전이 있는 경우, SCF는 새로운 버전에 의해 이용되는 보안 알고리즘이 서비스 계층에서 지원되는 것을 검증하기 위해 보안 기능/서비스를 콘택트한다. SCF는 또한 소프트웨어 모듈 정보가 적절하게 관리되고 서비스와 연결될 수 있도록 소프트웨어 모듈 관리와 통신할 필요가 있다.

또 다른 실시예에서, SCF는 애플리케이션들 및 서비스 계층에 등록되는 다른 서비스 계층들과 통신한다. 그렇게 함으로써, 그들은 서비스의 갱신을 인식하게 된다. 예를 들어, 서비스가 유지 보수를 위해 비활성화되면, SCF는 그들 애플리케이션들 및 특정 서비스를 이용하거나 이용했던 다른 서비스 계층들에 통지할 필요가 있다.

또 다른 실시예에서, SCF는 서비스 인에이블러 기능에 의해 구동된 서비스 인에이블링 프로세스의 통지를 위한 기본 네트워크와 통신한다. 예를 들어, 새로운 서비스가 추가될 때, SCF는 기본 네트워크에 통지한다. 이렇게 함으로써, 기본 네트워크 내의 DM 프로토콜은 새로운 서비스를 지원하기 위해 소프트웨어 모듈을 다운로드 및 설치한다.

서비스 API 관리 기능(SAMF)

실시예에 따르면, SAMF는 서비스 계층에서 추가, 활성화, 비활성화 또는 제거되는 서비스의 서비스 API를 관리할 책임이 있다. 서비스 API를 관리함으로써, 서비스는 인식/발견 및 이용될 수 있다. 예를 들어, RoA에서, 리소스는 서비스의 능력들과 피처들을 나타낸다. 한편, SoA에서, 기능들은 서비스의 피처들을 검색하고 서비스를 이용하기 위해 호출될 수 있다.

각각의 서비스는 서비스를 제공하는 엔티티에 의해 정의된 그것의 별개의 서비스 API를 갖는다. 상술한 바와 같이, 서비스 API는 일반 서비스 API와 고유 서비스 API를 포함한다. SAMF는 클라이언트에 서비스를 볼 수 있게 하기 위해서 서비스에 대한 서비스 API들의 양쪽 타입들을 관리할 책임이 있다.

SAMF는 서비스 API(일반 및 고유 서비스 API)를 관리하기 위해 하나 이상의 다음과 같은 기능성들을 가질 수 있다. 하나의 기능성에 따라, SAMF는 서비스 API를 서비스 계층의 전체 API에 통합할 수 있다. 즉, 서비스가 시스템에 추가될 때, 그것의 일반 서비스 API는 서비스 계층의 전체 일반 API에 통합되어야 하며, 클라이언트들, 예를 들면, 애플리케이션들, 다른 서비스 계층들, 등에 의해 이용되어야 한다. 예를 들어, RoA 기반 서비스들에 대해서, 서비스 API는 리소스들일 수 있다. SAMF는 리소스들을 서비스 계층의 전체 리소스 트리에 링크할 수 있고, 리소스에 액세스하기 위해 링크를 제공할 수 있다. 한편, SoA 기반 서비스에 대해서, SAMF는 서비스 계층에 의해 유지된 일반 기능들을 수정할 수 있어, 서비스의 일반 서비스 능력들이 일반 서비스 계층 기능들에 의해 호출될 수 있게 한다. 통합은 고유 서비스 API가 서비스 계층에 통합되고, 적어도 서비스 계층을 통해 클라이언트들에게 보일 수 있다는 것을 의미하기도 한다.

또 다른 기능성에 따르면, SAMF 새로운 기능성을 추가하여 서비스 API를 보완할 수 있다. 서비스 API에 기초하여, SAMF는 서비스 자체에 의해 지원되지 않지만 오히려 서비스 계층에 의해 지원 또는 요구되는 서비스 API에 새로운 기능성을 추가할 수 있다. 예를 들어, 서비스 인에이블러 기능은 본래 지원하지 않는 서비스에 대해 액세스 제어를 제공할 수 있다. RoA 기반 서비스에 대한 예시적인 실시예에서, 액세스 제어는 서비스의 리소스에 추가된다. 액세스 제어는 기능 또는 기능 내의 일부 파라미터들을 통해 구현될 수 있다.

또 다른 기능성에 따르면, SAMF는 서비스 API를 변환할 수 있다. 예를 들어, 서비스들이 생성될 수 있고, 상이한 환경들에 제공될 수 있다. 서비스가 서비스 계층에 통합될 때, 서비스 계층은 서비스 API가 서비스 계층 내에 호스팅된 다른 서비스들과 호환가능하도록 서비스 API를 변환할 수 있다. 또한, 서비스 계층 내의 서비스들을 이용하는 애플리케이션들과 호환가능하다. 예시적인 실시예에서, 다수의 변환 타입들이 있을 수 있다. 예를 들어, 변환은 RoA 기반 리소스와 SoA 기반 기능들과의 사이에 있을 수 있고 이에 의해 서비스 계층에 의해 제공된 일반 API는 RoA 내의 서비스 리소스를 SoA 내의 서비스 기능들로 변환하고, 이와 반대도 가능하다. 변환은 또한 RESTful 리소스와 비-RESTful 리소스와의 사이에 있을 수 있고 이에 의해 서비스 계층 일반 API는 서비스의 RESTful 리소스를 서비스에 대한 비-RESTful 리소스로 변환하고, 이와 반대도 가능하다. 상술한 기능성들 각각은 서비스 계층에 의해 호스팅된 모든 서비스들에 적용될 수 있다. 예를 들어, 변환 기능성은 기능 'CommonTranslation', 예를 들어, 서비스 API, 오리지널 포맷, 타겟 포맷의 관점에 있을 수 있다. 이것은 일반 변환 기능이 '오리지널' 포맷, 예를 들면 SoA 기반 기능의 서비스 API들을 '타겟' 포맷, 예를 들면, RoA 기반 RESTful 리소스로 변환하는 것을 의미한다.

서비스 인에이블러 방법들

애플리케이션의 또 다른 양태에 따르면, M2M/IoT 네트워크들 내에서 서비스를 추가, 활성화, 비활성화 및/또는 제거하기 위한 하나 이상의 방법들이 설명된다. 하기에 좀 더 상세히 알 수 있는 바와 같이, 방법들은 상기 서비스 인에이블러 기능의 아키텍처를 채택한다.

실시예에 따르면, 새로운 서비스를 서비스 계층 내에 추가하기 위한 방법이 설명된다. 특히, 서비스 인에이블러 기능은 서비스 계층 내에서 그리고 예를 들어, 애플리케이션들과 다른 서비스 계층들과 같은 외부 엔티티들과의 통신을 조정한다. 이렇게 함으로써, 새로운 서비스는 원활하게 서비스 계층에 통합될 수 있다. 또한, 새로운 서비스는 애플리케이션들과 다른 서비스 계층들과 같은 클라이언트들에 의해 이용될 수 있다.

예시적인 실시예에 따르면, 도 8은 새로운 서비스를 추가하기 위한 정보 교환 동작들이 긴급한 애플리케이션과 관련하여 채택되는 방법을 설명한다. 도 8의 각 단계들은 숫자, 예컨대, 0, 1, 2 등으로 표시된다. 단계 0에서, 서비스 인에이블링 프로세스를 트리거할 수 있는 가능한 소스들이 설명된다. 새로운 서비스를 추가하기 위한 프로세스를 트리거할 수 있는 2가지 경우가 있다: 단계 0a에서, M2M 애플리케이션은 새로운 서비스를 정의하고 제공하기를 원한다. 이 경우, 애플리케이션은 도 5에 도시된 바와 같이 참조점 'c'을 통해 서비스 인에이블링 요청을 SCF에 전송하는데, 이는 서비스를 추가하는 요청된 액션을 포함할 수 있다. 대안적 실시예에서, 애플리케이션은, 소프트웨어 모듈을 다운로드 및 설치하기 위해서는, 소프트웨어 모듈, 임의의 프로토콜 또는 엔티티, 예를 들어, DM 프로토콜을 검색하기 위해 링크를 제공할 수 있다.

또 다른 실시예에 따르면, 그 대신, 또는 단계 0a와 함께, 서비스 제공자는 단계 0b에 도시된 바와 같이 새로운 서비스를 정의하고 서비스 소비자들에게 제공한다. 이 경우, SCF는 도 5에 도시된 바와 같이 참조점 'b'를 통해 다른 또 다른 서비스 계층으로부터 서비스 인에이블링 요청을 받을 수 있다. 선택적으로, SCF는 도 5에 도시된 바와 같이 참조점 'd'를 통해 기본 NSE로부터 서비스 인에이블링 요청을 받을 수 있다. 서비스 인에이블링 요청은 요청된 액션, 예를 들어, 서비스를 추가, 활성화, 비활성화 또는 제거하는 것을 나타내고, 서비스 설명을 포함할 수 있다.

다음에, 단계 1에서, SCF는 외부 엔티티들, 예를 들어, 애플리케이션 또는 서비스 제공자로부터 새로운 서비스를 추가하라는 요청을 수신한다. 새로운 서비스가 애플리케이션에 의해 정의되는 경우, 애플리케이션은 서비스 인에이블러 기능에 소프트웨어 모듈 및 서비스 설명을 모두 제공할 필요가 있다. 새로운 서비스가 서비스 제공자에 의해 정의되는 경우, 서비스 설명은 서비스 인에이블링 프로세스를 위해 요구된다. 서비스 제공자는 서비스 계층에 소프트웨어 모듈을 제공할 수 없다.

단계 2에서, SCF는 도 5에 도시된 바와 같이 서비스 인에이블러 기능 내에서 참조점 'In'을 통해 요청 메시지를 SMCF에 전송한다. 요청된 메시지는 서비스 상태 갱신 요청과 서비스 설명 분석 요청을 결합한다. 서비스 상태 갱신 요청에 따르면, SCF는 새로운 상태를 나타낸다. 이 경우에, 새로운 서비스를 추가하는 것이다. 또한, 서비스 설명 분석 요청은 새로운 서비스의 서비스 설명을 포함한다.

단계 3에서, SMCF는 새로운 서비스의 상태를 'Added'로 갱신한다. SMCF는 그 다음 새로운 서비스의 능력들과 피처들을 이해하기 위해 서비스 설명을 분석한다. 예를 들어, SMCF는 새로운 서비스가 서비스 ID 속성을 분석함으로써 기존 서비스의 갱신된 버전인지를 이해하고 결정한다. 또한, SMCF는 인증 및 액세스 제어 정보 속성을 분석함으로써 소프트웨어 모듈 정보 및 액세스 제어 정책을 분석한다.

다음, 단계 4에서, SMCF는 서비스 인에이블러 기능 내에서 참조점 'In'을 통해 서비스 상태 갱신 응답과 서비스 설명 분석 응답을 조합하는 단일 응답 메시지를 SCF에 전송한다(도 5에 도시됨). 서비스 상태 갱신 응답은 서비스 상태가 요구된 상태, 예를 들어, 'Added'로 이미 갱신된 것을 나타내고, 서비스 설명 분석 응답은 새로운 서비스의 능력들과 피처들을 포함한다.

다음에, SCF 및 서비스 능력들은 단계 5에 따른 서비스 계층 내에서 참조점 'a'(도 5에 도시됨)를 통해 서비스 능력 검증 요청과 응답을 교환한다. SCF는 SMCF로부터 정보를 판독하고, 그 다음 상이한 서비스 능력(SC)과의 다중 통신들을 개시한다. 일 실시예에 따르면, 통신들은 서비스 계층 구성을 포함할 수 있다. 여기서, 서비스 노드는 새로운 서비스를 인에이블링할 때 제공하는 기능성들의 구성을 갱신한다. 이러한 정보는 서비스 ID 및 프로토콜 지원과 같은 서비스 설명에서의 속성들의 결합으로부터 추출될 수 있다.

또 다른 실시예에 따르면, 통신은 소프트웨어 관리 상세를 포함할 수 있다. 여기서, 서비스 계층은 새로운 서비스를 지원하는 소프트웨어 모듈의 정보를 유지할 수 있다. 이러한 정보는 소프트웨어 모듈 ID, 사이즈, 버전 및 사용자 명령 중 하나 이상을 포함하는 서비스 설명 내의 소프트웨어 모듈 정보 속성으로부터 비롯된다.

또 다른 실시예에서, 통신은 보안 상세를 포함할 수 있다. 보안 상세는 인증 방법과 인증 및 액세스 제어 정보로부터 유도된 정보에 기초한다. 여기서, SCF는 요구된 보안 관련 방법/알고리즘이 지원되는 경우, 예를 들면 새로운 서비스에 의해 요구된 민감한 데이터에 대한 보안 알고리즘이 지원되는지 여부를 알기 위해 보안 SC를 콘택트하고, 인증 및 허가 방법들은 서비스 계층에서 인에이블링된다. 이러한 방법들 또는 알고리즘들 중 임의의 것이 아직 인에이블링되지 않은 경우, 보안 SC는 요구된 보안 방법을 인에이블링하게 되고 요구된 보안 방법이 이미 인에이블링되어 있음을 나타내기 위해 보안 프로파일을 갱신한다.

추가의 실시예에서, 통신은 과금 정책들을 포함할 수 있다. 과금 정책 속성은 과금 모델, 과금 이벤트 및 과금 레이트와 같은 필요한 정보의 대부분을 포함한다. 즉, SCF는 새로운 서비스의 과금 정보를 과금 SC에 전송하여, 서비스 소비자들이 새로운 서비스를 이용할 때 과금 SC가 정보를 기록할 수 있게 하고 서비스 소비자들을 과금하게 하는 방법을 알 수 있게 한다.

또 다른 추가의 실시예에서, 통신은 등록 프로토콜을 포함할 수 있다. 즉, 새롭게 인에이블링된 서비스는 다른 엔티티들, 예를 들어, 서비스 계층에 등록되어 있는 애플리케이션들 및 관리 엔티티들에 대해 잠재적인 영향을 가질 수 있다. 예를 들어, 애플리케이션은 새로운 피처들을 제공하고 이전 버전에서의 일부 버그들을 수정하기 위해 구 버전으로부터 새로운 버전으로 업그레이드할 때 통지 받을 수 있다. 특히, SCF는 새로운 서비스를 인에이블링한 후 어떤 외부 엔티티들이 통지해야 하는지를 결정한다. SCF는 서비스 설명에 서비스 ID 속성들과 서비스 리스트 속성들을 포함하는 필요한 정보에의 등록 SC에 요청 메시지를 전송한다. 등록 SC는 새로운 서비스의 영향을 받은 임의의 서비스를 이용하는 엔티티들을 찾기 위해 이러한 서비스 계층에 등록된 엔티티들의 리스트를 체크한다. 그 후, 통지하기 위한 엔티티들의 리스트를 리턴한다.

또 다른 추가의 실시예에서, 통신은 DM 프로토콜들을 포함할 수 있다. 새로운 서비스가 애플리케이션에 의해 정의되는 경우, 애플리케이션은 소프트웨어 모듈을 서비스 계층에 제공한다. 그런 다음, 서비스 계층은 소프트웨어 모듈을 설치하기 위해 기본 DM 프로토콜에 소프트웨어 모듈을 푸시 다운할 수 있다. 서비스 인에이블러 기능은 새로운 서비스를 인에이블링하기 위해 DM SC와 협력할 필요가 있는 경우를 결정한다. 예시적인 실시예에서, 이것은 소프트웨어 모듈이 애플리케이션으로부터인지를 결정하기 위해 서비스 설명에서의 서비스 ID 및 소프트웨어 모듈 정보 속성들을 분석함으로써 수행될 수 있다. 이 경우, SCF는 소프트웨어 모듈의 설치를 위한 DM SC에 서비스 ID 및 소프트웨어 모듈 정보뿐만 아니라 소프트웨어 모듈 자체를 전송한다.

도 8의 단계 6에 대하여, SCF는 서비스 인에이블러 기능 내에서 참조점 'In'(도 5에 도시됨)을 통해 서비스 API 관리 요청을 SAMF에 전송한다. 즉, SCF는 요청에서 서비스 API를 SAMF에 전달한다. SAMF는 서비스가 애플리케이션들 및 다른 서비스 계층들에 의해 인식 및 이용될 수 있도록 서비스 API를 서비스 계층에 통합한다. 또한, SAMF는 서비스 API가 서비스 계층에 호스팅된 다른 서비스들과 호환되도록 서비스 API를 변환할 수 있다. 또한, 새로운 서비스 자체에 의해서가 아닌 서비스 계층에 의해 지원된 일부 새로운 기능성을 추가할 수가 있다.

다음, 단계 7에서, SAMF는 서비스 인에이블러 기능 내에서 참조점 'In'을 통해 서비스 API 관리 응답을 SCF에 전송한다. SAMF는 새로운 서비스에 대한 서비스 API 관리를 완료한 다음, 새로운 서비스에 대한 SCF에 서비스 API 링크 또는 방법을 리턴한다. RoA 기반 서비스를 설명하는 예시적인 실시예에서, 응답은 새로운 서비스를 나타내기 위해 리소스들의 리스트에의 URI 또는 링크를 포함한다. SoA 기반 서비스를 설명하는 또 다른 실시예에서, 응답은 새로운 서비스에 의해 제공된 기능들을 설명하는 파라미터들을 갖는 기능들의 리스트를 호출하기 위해 인터페이스 또는 일반 기능을 포함한다.

단계 8에서, SCF는 어느 엔티티들이 새로운 서비스에 대해 통지될 필요가 있는지를 결정한다. 상이한 기준들은 엔티티가 통지될 필요가 있는지를 결정하는데 이용될 수 있다. 이들은 이에 한정되지 않지만 다음을 포함할 수 있다: (ⅰ) 엔티티가 서비스 계층에 등록되어 있는지의 여부; (ii) 엔티티가 서비스 계층에 등록되고 잠재적으로 새로운 서비스를 이용하는지의 여부; 및 (iii) 엔티티가 새로운 서비스가 서비스 계층에 추가된 경우 통보를 수신하도록 가입하는지의 여부. 이 경우, 가입은 서비스에 고유하다. 즉, 엔티티가 상이한 서비스들에 대한 수신 통지들에 가입하는 경우 엔티티는 여러 번 통지될 수 있다.

이어서, SCF는 서비스 인에이블링 통지를, 단계 9에서 참조점 'b'를 통해 다른 서비스 계층들에, 그리고 참조점 'c'를 통해 애플리케이션들(도 5에 도시됨)에 전송한다. 통지는 최신 동작, 예를 들어, 서비스 인에이블러 기능에 의해 수행된 서비스를 추가하고, 활성화하고, 비활성화하고 또는 제거하는 것을 포함할 수 있다. 예를 들어, 통지는 새로운 서비스가 추가되는 것을 나타내고, 새로운 서비스 정보를 검색하기 위한 링크/방법을 나타내어, 애플리케이션들과 다른 서비스 계층들이 새로운 서비스를 인식 및 이용할 수 있게 한다.

도 8에 도시된 바와 같이, 다른 실시예에 따르면, 더 많은 정보가 새로운 서비스에 대해 교환될 수 있다(단계 10). 이는 다른 서비스 계층들을 위한 참조점 'b', 및 애플리케이션들을 위한 참조점 'c'를 통해 발생한다(도 5에 도시됨). 새로운 서비스에 대한 통지를 받은 후, 외부 엔티티들, 예를 들어, 애플리케이션들 및 다른 서비스 계층들은 더 자세한 정보를 요청하기 위해 SCF와의 통신들의 여러 라운드들을 가질 수 있다. 예를 들어, 애플리케이션이 서비스의 새로운 버전으로 전환하는 것으로 결정되는 경우, 보안, 과금, 가입, 등에 관한 좀 더 구체적인 정보에 대해 SCF에 요청할 수 있다.

도 8에 도시된 바와 같이, 또 다른 실시예에 따르면, 서비스 인에이블링 통지는 서비스 인에이블러 기능으로부터 NSE1에 전송될 수 있다(단계 11). 예를 들어, 새로운 서비스가 소프트웨어 모듈을 제공하는 애플리케이션에 의해 정의되는 경우에, 소프트웨어 모듈을 제공하기 위해 서비스 인에이블러 기능이 기본 NSE와 통신하는 것이 필요하다. 이는 소프트웨어 모듈을 검색하기 위해 소프트웨어 모듈 또는 링크를 제공할 수 있어, 기본 NSE는 기본 네트워크에서 새로운 서비스를 인에이블링하기 위해 소프트웨어 모듈을 다운로드하여 설치할 수 있게 한다.

새로운 서비스를 추가하는 프로세스가 특정 단계에서 실패하는, 즉, 새로운 서비스를 지원하기 위해 소프트웨어 모듈을 설치하는 것이 실패하는 경우에는, SCF는 새로운 서비스를 추가하는 프로세스를 트리거하는 엔티티에 보고한다. 보고는 실패의 이유를 포함한다. 엔티티의 트리거링은 새로운 서비스를 다시 추가할지 여부를 결정하기 위해 추가 단계들을 취할 것입니다. 또한, 서비스 인에이블링 요청이 다수의 서비스들 또는 서비스들의 다수의 버전들을 한 번에 추가, 활성화, 비활성화 또는 제거하도록 요청하는 애플리케이션에 따라 예상된다. 이러한 애플리케이션에서 제안된 방법들 및 절차들은 요청에 따라 한번에 하나의 서비스 또는 서비스의 버전을 처리하기 위해 반복될 수 있다.

애플리케이션의 일 실시예에서, 서비스 인에이블러 기능은 새로운 서비스를 추가하기 위한 프로세스를 구동하는 메인 기능으로서 설명된다. 도 9는 서비스 인에이블러 기능이 새로운 서비스를 추가하기 위한 방법의 예시적인 실시예이다. 도 9의 각 단계들은 숫자, 예를 들면, 0, 1, 2 등으로 표시된다. 먼저, 서비스(단계 0)를 추가하기 위한 트리거가 있다. 다음, SCF는 서비스 인에이블링 프로세스(단계 1)의 프로세스에서 트리거된 제1 기능일 수 있다. SMCF는 서비스 설명을 분석하고 어떤 능력들 및 피처들을 새로운 서비스가 제공하는지를 이해한다. SMCF는 SCF로부터 서비스 설명을 취한다(단계 2). 다음, 새로운 서비스가 기존 서비스의 새로운 버전인지 여부가 결정된다(단계 3a). 이 경우, SMCF는 소프트웨어 모듈 버전과 같은 기존 버전들의 정보, 능력과 피처들 및 과금 정보를 검색한다(단계 3b). 그렇지 않으면, 다음 단계로 진행한다. 구체적으로, 새로운 서비스가 새로운 버전인지의 여부를 결정하기 위해, SMCF는 서비스 ID, 소프트웨어 모듈 정보, 서비스 API와 같은 서비스 설명 속성들을 참조할 수 있다. 구 버전의 정보는 기존 서비스 API 또는 일부 서비스 저장소로부터 검색될 수 있다. 다음, 서비스 설명을 분석함으로써, SMCF는 새로운 서비스의 능력들과 피처들의 구성을 생성한다(단계 4). 새로운 서비스가 기존의 서비스의 새로운 버전인 경우, 서비스 인에이블러 기능은 새로운 버전과 구 버전(들) 간의 주요 차이점을 나타낼 필요가 있고, 또는 구 버전(들)의 정보를 검색하기 위한 방법/링크를 제공한다. SMCF는 그리고 나서 새로운 서비스 정보를 SCF에 전송한다. 이어서, SCF는 서비스 계층에서 새로운 서비스에 의해 요구된 방법들, 알고리즘들 또는 모델들이 인에이블링되고 지원되는지 체크하기 위해 서비스 계층 내에서 여러 SC들과 통신한다(단계 5). 새로운 서비스에 대한 일부 알고리즘들, 예를 들어, 민감한 데이터에 대한 보안 알고리즘이, 현시점에서 서비스 계층에서 지원되지 않는 경우, 서비스 인에이블러 기능은 새로운 서비스를 서비스 계층에 통합하기 위한 서비스 계층의 능력의 구성을 갱신한다. 그 다음, SAMF는 새로운 서비스에 대한 서비스 API를 관리한다(단계 6). 새로운 서비스를 서비스 계층에 추가한 후, SCF는 새로운 서비스의 서비스 API를 외부 애플리케이션들과 다른 서비스 계층들에 통지하여, 새로운 서비스가 인식 및 이용될 수 있게 한다(단계 7). 예를 들어, RoA 기반 서비스에 대해서, SCF는 새로운 서비스의 리소스에의 링크를 나타낼 수 있다. 한편, SoA 기반 서비스에 대해서, SCF는 새로운 서비스를 이용하기 위한 기능들 및 파라미터들을 특정할 수 있다.

서비스 API를 관리하는 방법

본 출원의 다른 실시예에 따르면, 도 10에 예시된 바와 같은 서비스 계층에 새로운 서비스를 추가할 때 각각의 서비스에 대한 서비스 API를 관리하기 위한 방법에 제공된다. 본 방법은 상술한 바와 같은 서비스 인에이블러 기능내에 SAMF에 의해 수행된다. 구체적으로, SAMF는 SCF로부터, 서비스 설명에서의 속성인 서비스 API를 수신한다(단계 1). 다음으로, API 변환이 요구되었는지를 결정한다(단계 2a). 그렇다면, SAMF는 서비스 계층에 의해 지원되는 서비스 API와 공통 API들에 기초하여 API 변환을 수행한다(단계 2b). 그렇지 않다면, SAMF는 다음 단계로 진행한다. 변환이 요구되는지를 결정하기 위해, SAMF는 첫번째로 서비스가 RoA-기반인지 또는 SoA-기반인지를 결정한다. 그 이후에, SAMF는 서비스 계층에 호스팅되는 다른 서비스들과 호환 가능한지를 결정한다. 예를 들어, 서비스가 SoA-기반이지만, 서비스 계층만이 RoA-기반 리소스를 지원하는 경우, 변환이 요구된다. 하나의 예시적인 실시예에서, 서비스가 RESTful 서비스이고 서비스 계층이 비-RESTful 서비스들만을 지원하는 경우, 변환이 요구될 수도 있다. 다음으로, 일부 새로운 기능성이 요구되는지를 결정한다(단계 3a). 그렇다면, SAMF는 오리지널 서비스 API에 의해 지원되지 않는 일부 새로운 기능성을 추가한다(단계 3b). 그렇지 않다면, SAMF는 다음 단계로 진행한다. 즉, 일부 기능성은 서비스에 의해 기본적으로 지원되지 않지만, 서비스 계층에 의해 요구된다. 일례에서, 액세스 제어 정보는 서비스 API에 의해 특정되지 않을 수 있지만, 서비스 계층에 호스팅되는 모든 서비스들이 액세스 제어 정보를 특정하는 것이 요구된다. 액세스 제어가 오리지널 서비스 API에 의해 특정되지 않는 경우, 서비스 계층은 새로운 서비스에 대한 디폴트 액세스 제어 규칙을 이용할 것이다. 또한, SAMF가 서비스 API를 서비스 계층에 통합하여, 새로운 서비스가 인식되어 활용될 수 있게 한다(단계 4). RoA-기반 서비스의 경우, 그것의 리소스는 서비스 계층의 리소스 트리에 링크될 수 있다. 다른 한편으로는, SoA-기반 서비스의 경우, 그것의 기능들은 서비스 계층의 공통 기능들에 의해 호출될 수 있다.

서비스를 제거하기 위한 방법

본 출원의 다른 실시예에 따르면, 서비스 계층으로부터 서비스를 제거하는 것을 담당하는 서비스 인에이블러 기능이 기술된다. 서비스를 제거하는 여러 이유가 있을 수 있다. 예를 들어, 서비스는 새로운 시스템에 호환 가능하지 않을 수 있다. 따라서, 클라이언트는 결코 그것을 활용할 수 없다. 게다가, 서비스는 일부 새로운 필수 정책을 따르지 않을 수 있다. 또한, 오리지널 서비스 제공자는 서비스를 제거하기로 결정한다. 본 출원의 목적을 위해, 서비스를 제거하는 결정이 이미 이루어졌다고 가정된다. 따라서, 서비스를 제거하는 것이 서비스 계층에 의해 허락될 것인지를 체크할 필요가 없다.

도 11에 나타낸 바와 같은 예시적인 실시예에 따르면, 서비스 계층으로부터 서비스를 제거하는 절차가 기술되어 있다. 도 11에서의 각각의 단계들은 수치, 예를 들어 0, 1, 2, 등으로 표시된다. 구체적으로, SCF는 일부 엔티티들, 예를 들어 서비스 능력들, 애플리케이션 또는 서비스 제공자로부터 서비스를 제거하기 위한 요청을 수신한다(단계 1). 무슨 서비스가 제거될 것인지와 어느 버전(들)이 제거될 것인지를 정확하게 식별하기 위해, 서비스 설명에서의 다음 속성들 중 하나 이상이 특정될 필요가 있다: (i) 서비스 제공자 ID; (ii) 서비스 ID; (iii) 소프트웨어 모듈 정보; 및 (iv) 서비스 API. 다음으로, 서비스 상태 갱신 요청은 서비스 인에이블러 기능에서 SCF로부터 SMCF로 전달된다(단계 2). 이것은 도 5에 나타낸 바와 같은 서비스 인에이블러 기능 내의 참조점 'In'에 걸쳐 일어난다. 서비스를 제거하기 위한 요청이 수신되었다면, SCF는 무슨 서비스와 어느 버전을 제거할지를 식별하기 위한 정보를 SMCF에 전달한다. 다음으로, SMCF는 SCF로부터의 정보에 기초하여 제거된 서비스의 구성을 관리한다(단계 3). 구체적으로, 서비스가 서비스의 버전을 제거하기 위한 것이라면, SMCF는 버전에 의해 제공되는 능력들 및 피처들을 제거함으로써 서비스의 능력들 및 피처들의 구성을 갱신할 것이다. 서비스가 완벽하게 제거되면, 예를 들어, 모든 버전이 제거되면; SMCF는 서비스의 구성 기록 제거한다. 예시적인 실시예에서, 서비스 계층은 서비스 제공자, 버전 번호 및 소프트웨어 모듈 버전과 같은 일부 기본 정보로, 제거된 서비스에 대한 기록을 유지할 수 있다. 이것은 장래에 최신 버전이 서비스에 추가될 경우에 유용한 것으로 판명될 수 있다. SMCF가 확인을 위한 이 단계 이후에 SCF로 확인할 필요가 없으며, 이 이유는 서비스를 제거하기로 결정되었다고 가정되었기 때문이다. SMCF는 또한 피드백을 SCF에게 제공할 필요가 없다. 즉, SCF는 이 단계의 동작 및 결과를 안다. 예시적인 실시예에서, 다음으로, SAMF는 서비스 API를 제거하거나 갱신하기 위해 SCF로부터 요청을 수신한다(단계 4). 요청시, SCF는 서비스 ID, 서비스 API 링크 또는 기능들과 같은, 제거 대상 서비스의 정보를 특정한다. 제거된 서비스가 버전인 경우, SAMF는 특정 버전에 대한 서비스 API에서 대응하는 콘텐츠를 제거하고, 서비스 API에서 다른 콘텐츠를 유지할 것이다. 또한, SAMF는 서비스 API를 제거하고/제거하거나 갱신하기 위해 요청에서의 정보를 따른다(단계 5). SAMF가 하나 이상의 서비스를 위한 여러 버전을 제거하고/제거하거나 갱신하기 위해 요구되는 것이 가능하다. 본 출원에서는 단계들 2 및 3이, SCF가 동시에 SMCF와 SAMF를 접촉할 경우에, 각각 단계들 4 및 5와 나란히 발생할 수 있다는 것이 예상된다.

다음으로, SCF는 상이한 SC들과 여러 통신을 시작하여 서비스 또는 서비스의 버전(들)이 제거된다는 것을 통보한다(단계 6). 이것은 도 5에 따라 서비스 계층 내의 참조점 'a'에 걸쳐 일어난다. 이 SC들은 따라서 그들의 구성을 갱신할 수 있다. 게다가, SCF는 애플리케이션들 및 서비스가 제거되는 다른 서비스 계층들에게 통보한다. SCF는 서비스를 제거하는 것에 의해 아마도 영향을 받는 모든 엔티티들에게 통보할 필요가 있다(단계 7). 이것은 도 5에 따른 다른 서비스 계층들에 대한 참조점 'b'와 애플리케이션들에 대한 참조점 'c'에 걸쳐 일어난다.

서비스를 비활성화시키기 위한 방법

본 출원의 또 다른 실시예에서, 서비스를 비활성화하기 위한 방법이 설명된다. 일반적으로, 서비스를 비활성화시키는 것은 서비스를 추가하거나 제거하는 것과 비교할 때 상대적으로 간단하다. 즉, 비활성시키는 것은 서비스 계층에서 서비스의 상태 갱신을 제외하고 어떠한 변경도 필요하지 않다. 서비스를 비활성화시킬 경우, SMCF는 서비스의 상태를 '비활성(Inactive)'으로 변경하고나서, 동작들을 비활성화시킴으로써 영향을 받을 수 있는 외부 엔티티들에게 통보한다.

예시적인 실시예에서, 도 12는 서비스를 비활성화시키기 위한 절차를 나타낸다. 도 12에서의 각각의 단계는 참조 번호, 예를 들어 0, 1, 2, 등으로 표시된다. 첫번째로, SCF는 서비스를 비활성화시키기 위해 요청을 수신한다(단계 1). 요청은 내부 서비스 능력, 외부 애플리케이션 또는 다른 서비스 계층으로부터 유래할 수 있다.

서비스 비활성화 프로세스를 트리거하는 다수의 이벤트가 있을 수 있다. 예를 들어, 서비스는 서비스가 오동작이면 비활성화된다. 서비스는 또한 서비스가 일부 정책 및 서비스 계층의 규칙들을 어기면, 예를 들어 위치 서비스가 서비스 계층의 개인 정보 보호 정책을 어기면 클라이언트들의 위치를 다른 클라이언트들에게 폭로함으로써 비활성화될 수 있다. 서비스는 또한 서비스가 클라이언트에 의해 이용되지 않고 백업 목적으로만 유지되는 경우에도 비활성화될 수 있다. 단계 2에서, SCF는 서비스를 비활성화시키기 위한 상태 갱신을 관리하기 위해 요청을 SMCF에 전달한다. 이것은 도 5에 나타낸 바와 같은 서비스 인에이블러 기능내의 참조점 'In'에 걸쳐 일어난다.

다음으로, SMCF는 서비스의 상태를 '비활성(Inactive)'으로 갱신한다(단계 3). 이 단계 이후에 SMCF가 SCF로 확인할 필요가 없을 수 있다. SCF는 이 단계의 동작 및 결과를 안다. 다음으로, 서비스 API 관리 요청은 SCF로부터 SAMF로 전달된다(단계 4). 차례로, SAMF는 이용가능성 정보와 같은, 비활성화된 서비스의 서비스 API를 갱신한다(단계 5). SCF는 서비스가 비활성화되는 것을 통보하기 위해 상이한 SC들과 여러 통신을 시작한다(단계 6). 이것은 도 5에 따른 서비스 계층 내의 참조점 'a'에 걸쳐 일어난다. 단계 7에서, SCF는 서비스가 비활성화되는 애플리케이션들 및 다른 서비스 계층들, 예를 들어 서비스 인에이블링 통지를 통보한다. 이것은 도 5에 따른 다른 서비스 계층들에 대한 참조점 'b', 및 애플리케이션들에 대한 참조점 'c'에 걸쳐 일어난다.

실시예에 따르면, 서비스를 비활성화시킬 때, 트리거링 엔티티는 비활성화의 지속 시간을 특정할 수 있다. 즉, 특정된 시간 간격 이후에, 서비스는 활성화되고 이용을 위해 준비 상태에 있을 것이다. 이러한 경우에, 서비스를 활성화시키는 동작은 더 간단하게 될 것이며, 그 이유는 서비스 소비자들이 서비스가 언제 활성화되게 될 것인지를 알기 때문이다. 게다가, 서비스의 비활성화에 관한 엔티티들을 통보할 때, 서비스 인에이블러 기능은 서비스 계층에 의해 제공되는, 대안과 일부 유사한 서비스들을 추천받을 수 있다. 비활성화가 영구적이면, 장래에 서비스의 정보를 검색하기 위한 방법/링크가 제공될 수 있다.

서비스를 활성화하기 위한 방법

본 출원의 또 다른 실시예에 따르면, 서비스를 활성화하기 위한 방법이 설명된다. 서비스를 활성화하는 것은 서비스를 비활성화시키기 위해 상술한 것과 유사한 절차를 따른다. 그러나, 서비스의 상태는 '활성(Active)'으로 변경된다. 일 실시예에서, 활성화가 서비스를 추가하는 것, 예를 들어 새로운 서비스를 추가하고 그 서비스를 즉시 활성화하는 것과 함께 발생하는 경우, 활성화 프로세스는 새로운 서비스를 추가하는 프로세스에 통합될 수 있다. 다른 한편으로는, 새로운 서비스가 새로운 서비스를 추가한 후에 개별 프로세스에서 활성화되는 경우, 서비스 인에이블러 기능은 새로운 서비스의 상태를 '활성(Active)'으로 변경하고나서 엔티티들, 예를 들어 서비스 능력들, 애플리케이션들 및 서비스 계층들을 통보한다.

대안적인 실시예에서, 기존 서비스의 활성화는 비활성화된 것으로부터 발생한다. 여기에서, 서비스 인에이블러 기능은 새로운 서비스의 상태를 '활성(Active)'으로 변경하고나서 외부 엔티티들, 예를 들어 서비스 능력들, 애플리케이션들 및 서비스 계층들을 통보한다.

종속 문제를 취급하기 위한 방법

본 출원의 다른 실시예에 따르면, 서비스 계층에서 서비스를 추가하고, 활성화하고, 비활성화하거나 제거할 때 종속 문제들을 취급할 경우에 쟁점들이 발생할 수 있다. 예를 들어, 위치 서비스에 의지하는 주유소 검색 서비스에 대해 고려한다. 위치 서비스가 일시적으로 비활성화되거나 영구적으로 제거되면, 애플리케이션은 가까운 주유소의 정보를 제공할 수 없을 것이다. 다른 예에서, 방의 온도를 미리 설정된 온도로 자동적으로 제어하는 서비스에 대해 고려한다. 서비스는 방의 현재 온도를 자동적으로 보고하는 한 세트의 센서에 의존한다. 센서들이 온도를 감지하고 보고하는 것을 멈추면, 온도를 제어하는 서비스에 문제가 발생한다.

심지어 서비스를 추가하거나 활성화시키는 것도 이슈를 유발할 수 있다. 예를 들어, 온도-제어 서비스의 센서들이 온도 이외에, 습도를 보고하기 위한 새로운 서비스를 제공하는 경우, 온도를 제어하는 서비스는 오래된 서비스를 지속할 것인지 또는 새로운 서비스로 전환할 것인지를 결정할 필요가 있다. 애플리케이션에 따르면, 서비스가 의존하는 서비스들의 세트가 결정될 수 있다.

도 13은 서비스 계층에서 서비스를 추가하고, 활성화하고, 비활성화하거나, 제거할 때 종속 문제를 취급하기 위한 방법의 예시적인 실시예를 나타낸다. 각각의 단계는 도면에서 단계 '#'로 표시된다. 서비스가 추가되고, 활성화되고, 비활성화되거나 제거되었다고 하는 통지가 수신되면, 서비스 인에이블러 기능은 어떤 다른 서비스가 영향을 받는지를 찾기 시작한다(단계 1). 종속 문제를 찾기 위해, 도 5에 나타낸 바와 같은 서비스 인에이블러 기능은 통보로부터 정보를 추출할 수 있다. 일 실시예에서, 통지는 트리거링 이벤트, 예를 들어 추가, 활성화, 비활성화 또는 제거와, 예를 들어 서비스 ID 및 서비스 리스트와 같은 서비스 설명으로부터의 일부 속성들을 포함한다. 단계 2에서, 종속 문제가 있는지가 결정된다. 즉, 서비스 인에이블러 기능은 트리거링 이벤트, 예를 들어 서비스를 추가, 활성화, 비활성화 또는 제거하는 것에 기초하여 추가적인 액션을 결정할 것이다. 종속 문제가 있다고 가정하면, 서비스 인에이블러 기능은 서비스를 제거한 것으로 인한 것인지를 체크한다. 종속 문제가 서비스로 인한 것이 아닐 때의 방법론은 이하 보다 상세히 논의될 것이다.

단계 4에 따르면, 제거된 서비스가 핵심인지가 결정된다. '핵심 서비스'는 다른 서비스가 일시적으로 의존될 수 있는 서비스를 의미하며, 그 반면에 일부 서비스가 제공되지 않을 수 있다. 예를 들어, 빌링 서비스(billing service)는 핵심 서비스이다. 본 출원의 이 섹션에 따르면, '서비스를 제거하는 것'의 결정이 이미 행해졌다는 것이 이해된다. 다음으로, 서비스 인에이블러 기능은 제거된 서비스가 핵심인 것으로 결정되면 대안적인 서비스를 찾기 위해 서비스 발견 메커니즘을 수행한다(단계 5). 본 출원에서는 어떤 서비스 발견 메커니즘이 적용될 수 있는지가 일반적으로 이해된다. 또한, 영향을 받은 서비스와 제거된/비활성화된 서비스 간의 관계는 제거된/비활성화된 서비스가 비-핵심인 것으로 결정되지 않으면 종료된다(단계 6). 비-핵심(Non-critical)은 영향을 받은 서비스가 제거된/비활성화된 서비스 없이 활용될 수 있다는 것을 의미한다.

종속 문제가 서비스로 인한 것이 아닐 때의 방법론(단계 3으로의 네거티브 응답)이 지금 논의될 것이다. 즉, 종속 문제가 서비스를 비활성화하는 것으로 인한 것인지를 체크한다(단계 7). 종속 문제가 서비스를 비활성화하는 것으로 인한 것이라면, 비활성화가 영구적인지를 결정한다(단계 8). 비활성화가 영구적이면, 서비스 인에이블러 기능은 비활성화된 서비스가 핵심인지를 체크한다(단계 9). 비활성화가 영구적이지 않다면, 서비스 인에이블러 기능은 서비스가 활성화될 때까지 대기한다(단계 10). 대기 시간 동안, 비활성화된 서비스가 핵심인 경우, 영향을 받은 서비스들은 일시 정지될 수 있으며, 그 반면에 영향을 받은 서비스들이 비활성화된 서비스 없이 제공될 수 있다.

다른 실시예에 따르면, 서비스 인에이블러 기능은 종속 문제가 서비스를 추가하거나 활성화하는 것으로 인한 것인지를 체크한다(단계 11). 그렇다면, 새롭게 추가되거나 활성화된 서비스를 이용할 것인지가 결정된다.

oneM2M 서비스 계층 실시예

본 출원의 다른 양태에 따르면, oneM2M RESTful 기능적 아키텍처가 설명된다. 예를 들어, 도 14는 서비스 인에이블러 기능을 지원하기 위해 기존 oneM2M 기능적 아키텍처를 개선하기 위한 예시적인 실시예를 나타낸다. 도시된 바와 같이, 서비스 인에이블러 기능은 CSE에서 새로운 CSF일 수 있다. CSF는 CSE내에서 서비스를 추가하고, 활성화하고, 비활성화하거나 제거하는 것을 조정한다. CSF는 또한 각각 AE들, 다른 CSF들 및 CSE들과 통신한다. 게다가, 도 14에 나타낸 실시예는 도 5에 예시된 일반적인 아키텍처와 oneM2M 간의 참조점 매핑을 제공한다.

새로운 서비스의 개시자, 예를 들어 도 14에 나타낸 AE2 또는 CSE1는 CSE1 내에 위치하는 서비스 인에이블러 CSF에 서비스 설명을 전달한다. 개시자는 새로운 서비스를 정의하는데 필요한 정보를, RESTful 리소스들의 형태로 포함한다. 리소스 표현은 서비스 사용 인에이블링 요청 메시지에 포함된다. 특히, 도 15는 <serviceDescription>(1500) 리소스의 구조를 나타낸다. <serviceDescription>(1500) 리소스는 위에서 설명한 일반적인 서비스 설명에 대응한다. 'M2M-SP-ID', 'M2M-CSF-ID', 'protocolRequired' 및 'serviceCompatabilty'는 각각 속성들이다. 또한, <CommonServiceAP>, <UniqueServiceAPI>, <DependentServiceList>, <accessControlMethods>, <softwareModule>, <chargingPolicy> 및 <serviceLocation>은 각각 하위 리소스이다. 하위 리소스는 속성에 의해 추가적으로 정의될 수 있다.

도 16에 도시된 바와 같은 실시예에서는, 제안된 서비스 인에이블러 CSF를 도 14에 도시된 oneM2M 서비스 계층에 추가하는 새로운 서비스를 추가하는 기술이 설명된다. 도시된 바와 같이, 새로운 서비스는 AE에 의해 개시된다. 도 16에서의 각 단계는, 번호, 예를 들어 1, 2 등으로 표시된다. 먼저, AE는 서비스 인에이블링 요청을 서비스 인에이블러 CSF에 송신한다(단계 1). 이 메시지에는 CREATE 요청이 사용될 수 있다. CREATE 요청은 새로운 서비스에 대한 <serviceDescription> 리소스 표현을 포함한다.

요청을 수신하면, 서비스 인에이블러 CSF는 본원에서 앞서 제공한 설명에 따라 동작한다. 주로 서비스 인에이블러 CSF는 서비스 설명을 분석할 것이다(단계 2). 서비스 설명에 정의된 정보에 기초하여, 새로운 서비스에 의해 제공된 서비스 능력, 이 새로운 서비스에 관련된 다른 서비스와 같은, 새로운 서비스에 관한 핵심 정보를 찾을 것이다. 서비스 인에이블러 CSF는 다음 단계에서 설명된 바와 같이, 새로운 서비스를 이용하기 위해 다른 CSF가 수반된 일련의 동작을 개시할 것이다. 다른 CSF와의 상호 작용은 CSF간 참조점을 통해 이루어진다.

서비스 인에이블러 CSF는, 제공되는 액세스 제어 방법들(예를 들어, 인증 방법, 인가 및 액세스 제어 정보)에 기초하여, 새로운 서비스를 인증하기 위해 보안 CSF에 접촉할 수 있다(단계 3). 보안 CSF는 인증을 승인할 수 있다(단계 4). 다음으로, 서비스 인에이블러 CSF는 새로운 서비스에 대한 등록 프로세스를 트리거한다(단계 5). 다음으로, 새로운 서비스의 리소스들은 본원에서 논의된 바와 같이 생성될 수 있으며, 기존 발견 CSF를 이용하여 발견할 수 있다(단계 6). 기존 등록 프로세스를 재사용할 수 있다(단계 7).

서비스 인에이블러 CSF는 서비스 설명에 제공된 "관련 서비스 리스트" 정보에 기초하여 다른 CSF와의 상호 작용을 개시한다. 예를 들어, 과금 CSF와 상호작용하여 새로운 서비스에 의해 제공되는 새로운 과금 정책을 추가할 수 있다(단계 8). 과금 정책 리소스는 과금 CSF에 의해 갱신된다(단계 9). 또한, 새로운 서비스에 대한 과금 정책은 성공적으로 생성되어 서비스 인에이블러 CSF로 다시 릴레이된다(단계 10). 단계 11에 따르면, 다른 CSF와의 상호작용이 있다. 마지막으로, 다른 CSF들, 예를 들어 DMG CSF, 애플리케이션 및 서비스 계층 관리 CSF와 상호작용이 성공적으로 완료되면, 서비스 인에이블러 CSF는 새로운 서비스가 추가되어 서비스 계층에 성공적으로 통합되었음을 표시하는 서비스 사용 가능 응답 메시지를 리턴시킨다(단계 12).

또 다른 실시예에 따르면, 도 17은 제안된 새로운 <service>(1700) 리소스를 나타내며, 이는 본 출원에서 설명된 공통 서비스 API에 대응한다. 설명을 위해, 속성들만이 제공된다. oneM2M이 정의된 공통 속성은 나타나 있지 않다. 새로운 서비스가 생성될 때, <service> 리소스의 새로운 인스턴스가 서비스 계층에서 생성된다. serviceState는 이 본원에서 상술한 바와 같이 상태 정보를 표시한다. "제거된" 서비스는 추적 및 통계와 같은 목적으로 서비스 계층에 인스턴스를 가질 수 있다는 점에 유의해야 한다. serviceLink는 새로운 서비스에 특정된 리소스 또는 데이터 구조를 가리킨다. 이러한 데이터 구조는 이전 호출 흐름에서 언급한 바와 같이 소프트웨어 모듈로서 업로드될 수 있다. <service> 리소스의 새로운 인스턴스가 생성되면, 새로운 서비스를 생성하려는 작성자가 제공한 <serviceDescription>이 인스턴스와 함께 저장된다.

또 다른 실시예에서, 도 18은 확장 가능한 리소스 구조에 대한 일반적인 템플릿을 나타낸다. 템플릿은 oneM2M 서비스 계층에 대한 임의의 기존 및 향후 리소스에 적용될 수 있다. 여기서, 유형은 <existingResourceType>(1800)이다. 리소스 구조에 2개의 표시자가 공통 속성으로서 추가된다. 하나의 표시자는 속성이 변경되었는지의 여부를 표시한다. 다른 표시자는 하위 리소스가 변경되었는지를 표시한다. 디폴트로, 이러한 표시자들은 "아니오"로 설정된다. 새로운 리소스의 추가로 인해 생성된 새로운 속성 또는 하위 리소스가 있다면, 서비스 인에이블러 CSF가 기존 CSF와 상호작용할 때 표시자는 "예"로 변경된다. 다른 CSF, CSE 및 AE는 관심있는 임의의 기존 리소스에 대한 변경을 통지하기 위해 표시자에 가입할 수 있다. 이러한 표시자가 "예"로 변경되면, 새로운 리소스 발견 절차를 수행하여(oneM2M 서비스 계층에 의해 지원되는 기존 리소스 발견이 이용될 수 있음) 속성 및 하위 리소스에 대한 변경을 발견할 수 있다.

oneM2M 서비스 컴포넌트(SoA) 아키텍처 실시예

본원의 다른 실시예에 따르면, 도 19에 도시된 바와 같이, oneM2M 서비스 컴포넌트 아키텍처 내의 서비스 인에이블러 기능의 2개의 잠재적 구현 아키텍처가 설명된다. 일 실시예에서, 서비스 인에이블러 기능은 각각의 서비스 컴포넌트, 예로서 서비스 컴포넌트 1 및 서비스 컴포넌트 N 내에 기능으로서 위치한다. 이것은 서비스 컴포넌트가 하나 이상의 서비스를 제공하는 엔티티이어서 다른 서비스 컴포넌트들과 느슨하게 결합되는 것에 기인할 수 있다. 이와 같이, 각각의 서비스 컴포넌트는 서비스 컴포넌트 내에 서비스를 추가, 활성화, 비활성화 및 제거하는 프로세스를 독립적으로 수행할 수 있다. 대안 실시예에서, 서비스 인에이블러 기능은 '서비스 인에이블러 컴포넌트'라고 하는 개별 서비스 컴포넌트를 삽입함으로써 구현된다. 임의의 서비스 컴포넌트가 서비스를 추가, 활성화, 비활성화 및 제거하기를 원할 경우, 'Msc' 기준 포인트를 통해 서비스 인에이블러 컴포넌트와 협력하는 것이 필요하다.

또 다른 실시예에 따르면, AE가 새로운 서비스를 제공할 때 새로운 서비스를 추가함으로써 정보를 교환하기 위한 방법이 도 20에 도시된다. 단계들 각각은 번호, 예로서 1, 2 등으로 표시된다. 먼저, AE는 CSE(서비스 계층)에서 새로운 서비스를 서비스 인에이블러 컴포넌트로 전송한다(단계 1). "새로운 서비스"는 서비스 설명 및 소프트웨어 모듈을 포함한다. 이어서, 서비스 인에이블러 컴포넌트는 새로운 서비스를 oneM2M 시스템에 추가하며, 여기서 서비스 능력은 서비스 컴포넌트에 대응하고, M2M 애플리케이션은 AE에 대응하고, 서비스 계층은 CSE에 대응한다(단계 2). 이 단계는 서비스 계층에서 발생하는 서비스 인에이블링 프로세스이다. 서비스 설명은 새로운 서비스에 대한 모든 정보를 포함하며, 따라서 서비스 인에이블러 컴포넌트는 서비스 인에이블러 컴포넌트가 이전에 서비스를 알지 못한 경우에도 서비스 설명을 분석할 수 있다. 새로운 서비스를 추가한 후, 서비스 인에이블러 컴포넌트는 소프트웨어 모듈을 DMG 컴포넌트로 전달한다(단계 3). 또한, DM 컴포넌트는 새로운 서비스에 대한 소프트웨어 모듈을 기본 NSE 내의 관련 DMS로 포워딩한다(단계 4). 마지막으로, 기본 NSE 내의 DMS는 새로운 서비스에 대한 소프트웨어 모듈을 DM 클라이언트 내의 oneM2M CSE에 설치하며, 따라서 새로운 서비스가 인에이블링된다(단계 5). 이 단계에 따라, DMS는 DM 프로토콜에서 정의되는 바와 같은 소프트웨어 인에이블링 프로세스를 완료하지만, DMS는 예로서 서비스의 서비스 ID, 능력 및 피처, 및 서비스 리소스를 포함하는 서비스 계층 정보를 알지 못한다.

대안 실시예에서, 도 21은 AE에 의해 개시되는 새로운 서비스를 추가하기 위한 다른 기술을 나타낸다. 도 21의 단계들 각각은 번호, 예로서 1, 2 등으로 표시된다. 서비스 인에이블링 요청이 서비스 인에이블러 컴포넌트로 전송된다(단계 1). 이어서, 새로운 서비스가 oneM2M 시스템에 추가된다(단계 2). 도 20과 달리, AE는 새로운 서비스를 추가하는 프로세스 동안 소프트웨어 모듈에 액세스하기 위한 링크/URI만을 제공한다(단계 3). 기본 네트워크 내의 DMS는 링크를 이용하여 소프트웨어 모듈을 획득하고(단계 4), 새로운 서비스를 지원하기 위해 소프트웨어 모듈을 설치한다(단계 5).

추가 실시예에 따르면, 서비스 제공자가 새로운 서비스를 정의할 때 새로운 서비스를 제공하는 것과 관련된 정보 교환이 도 22에 도시된다. 도 22의 단계들 각각은 참조 번호, 예로서 1, 2 등으로 표시된다. 이 예에서, 기본 NSE 내의 DMS는 먼저 소프트웨어 모듈을 설치한다(단계 1). 이는 서비스 제공자가 새로운 서비스를 정의하고, 먼저 DM 프로토콜과 접촉하기 때문이다. 그러나, DM 프로토콜은 서비스 계층 정보에 투명한데, 예로서 DM 프로토콜은 서비스 설명을 읽고 새로운 서비스가 무엇인지를 이해하지 못한다. 이어서, DMS는 서비스 설명을 CSE 내의 DM 컴포넌트로 투명하게 전송한다(단계 2). 이는 DMS가 서비스 설명과 무관하고, 서비스 계층으로 전송하도록 서비스 제공자에 의해 트리거링되기 때문이다. 이어서, DM 컴포넌트는 새로운 서비스의 서비스 설명을 서비스 인에이블러 컴포넌트로 투명하게 포워딩한다(단계 3). 또한, 서비스 인에이블러 컴포넌트는 새로운 서비스를 oneM2M 시스템에 추가한다(단계 4).

oneM2M 기능 아키텍처에 기초하는 DM

또 다른 실시예에 따르면, 도 23은 DM 프로토콜 및 oneM2M 시스템을 통해 동작하는 서비스 인에이블러 기능의 아키텍처(2300)를 나타낸다. 구체적으로, 서비스 인에이블러 기능의 3개의 기능성이 CSE 내의 상이한 엔티티들에서 구현된다. 예로서, CSF(2305)는 DMG CSF(2310) 내에 위치한다. 이 점에서, DMG CSF는 서비스를 추가, 활성화, 비활성화 또는 제거하는 절차의 구동 및 조정을 담당한다. 더욱이, SMCF 및 SAMF는 인에이블러 기능들의 일부로서 구현되는 기능들이다. 서비스 인에이블러 기능의 3개의 하위 기능이 상이한 물리 위치들에서 구현되는 경우, 기준 포인트 'In'은 이러한 하위 기능들 간의 메시지 교환을 위해 사용될 것이다.

또한, 서비스 인식 기능(SAF)(2315)이 기본 DM 프로토콜의 DMS(2320) 내에 삽입된다. 현재의 DM 프로토콜은 서비스를 인식하지 못하므로, 예로서 DM 프로토콜은 서비스 계층 관점에서 서비스에 대해 아무 것도 모르므로, SAF는 서비스 계층에서 서비스 인에이블러 기능을 트리거링하는 것이 필요한지를 지시하기 위해 DM 메시지 내의 새로운 지시 필드를 요구한다. 소프트웨어 모듈을 갱신 또는 설치할 때, SAF는 소프트웨어 모듈을 제공하는 엔티티에 의해 셋업될 새로운 지시 필드를 체크할 것이다.

본원의 또 다른 양태에 따르면, 컴퓨터 판독 가능 또는 실행 가능 명령어들을 저장하기 위한 비일시적 컴퓨터 판독 가능 또는 실행 가능 저장 매체가 개시된다. 매체는 위에서 도 8-13, 16 및 20-22에 따른 복수의 호출 흐름에서 개시된 바와 같은 하나 이상의 컴퓨터 실행 가능 명령어를 포함할 수 있다. 컴퓨터 실행 가능 명령어들은 메모리 내에 저장될 수 있으며, 위에서 도 1c 및 1d에서 개시되고 서버, 게이트웨이 및 OneM2M 디바이스를 포함하는 디바이스들에서 사용되는 프로세서에 의해 실행될 수 있다. 일 실시예에서, 도 1c 및 1d에서 전술한 바와 같은 비일시적 메모리 및 프로세서가 동작 가능하게 결합된 컴퓨터 구현 UE가 개시된다. 구체적으로, 비일시적 메모리는 네트워크에서 서비스를 갱신, 예로서 추가하기 위한 명령어들을 저장하고 있다. 프로세서는 (i) 서비스 계층 내에 위치하는 서비스 인에이블러 기능에서 서비스를 추가하기 위한 요청을 수신하고; (ii) 요청된 서비스의 서비스 설명을 검토하여 그의 능력을 이해하고; (iii) 검증 요청을 서비스 계층 내에 위치하는 서비스 능력으로 전송하고; (iv) 요청된 서비스가 인에이블링되는 것을 애플리케이션 또는 다른 서비스 계층에 통지하는 명령어들을 실행하도록 구성된다.

다른 실시예에서, 비일시적 메모리는 네트워크로부터 서비스를 갱신, 예로서 제거하기 위한 명령어들을 저장하고 있다. 프로세서는 (i) 서비스 계층 내에 위치하는 서비스 인에이블러 기능에서 서비스를 제거하기 위한 요청을 수신하고; (ii) 제거될 서비스를 식별하고; (iii) 서비스 상태 갱신 요청을 서비스 상태 관리 및 구성 기능으로 전송하고; (iv) 요청된 서비스가 제거되었다는 것을 애플리케이션 또는 다른 서비스 계층에 통지하는 명령어들을 실행하도록 구성된다.

방법들, 시스템들 및 소프트웨어 애플리케이션들이 현재 구체적인 양태들인 것으로 간주되는 것과 관련하여 설명되었지만, 본 개시내용은 개시된 양태들로 한정될 필요는 없다. 본 개시내용은 청구항들의 사상 및 범위 내에 포함되는 다양한 변경들 및 유사한 배열들을 커버하는 것을 의도하며, 그의 범위는 모든 그러한 변경들 및 유사한 구조들을 포함하도록 가장 넓게 해석되어야 한다. 본 개시내용은 아래의 청구항들의 임의의 그리고 모든 양태들을 포함한다.

Claims (20)

1. 네트워크에서 서비스를 관리하기 위한, 컴퓨터에 의해 구현되는 방법으로서,
   서비스 계층 기능 내에서 서비스 API를 통해 서비스를 관리하라는 요청을 수신하는 단계;
   상기 서비스의 서비스 설명을 검토하여 그의 능력을 이해하는 단계;
   상기 서비스 계층 기능 내에 위치하는 서비스 능력에, 상기 서비스 능력이 상기 서비스를 관리하는 것을 허용하고 지원하는지 여부를 검증하기 위한 요청을 전송하는 단계; 및
   상기 서비스가 관리되는 것을 애플리케이션 또는 다른 서비스 계층 기능에 통지하는 단계
   를 포함하는 방법.
2. 제1항에 있어서,
   상기 서비스 API를 상기 서비스 계층 기능 내에 통합하여, 상기 서비스가 상기 다른 서비스 계층 기능 또는 애플리케이션에 의해 발견 및 이용될 수 있게 하는 단계를 더 포함하고,
   상기 서비스 API는 RESTful인, 방법.
3. 제1항 또는 제2항에 있어서,
   상기 서비스 계층 기능은 상기 서비스 API를 상기 서비스 계층 기능에서 호스팅되는 다른 서비스들과 호환되도록 변환하는 방법.
4. 제1항 또는 제2항에 있어서,
   상기 서비스 설명은 서비스 제공자 ID, 서비스 ID, 종속 서비스들의 리스트, 고유 RESTful 서비스 API, 공통 RESTful 서비스 API, 상기 서비스의 위치, 인증 방법, 허가 및 액세스 제어 정보, 소프트웨어 모듈 정보, 프로토콜 지원, 서비스 호환성, 과금 정책 및 이들의 조합들로부터 선택되는 방법.
5. 제1항 또는 제2항에 있어서,
   상기 서비스가 기존 서비스의 갱신 버전인지 또는 새로운 서비스인지를 결정하는 단계를 더 포함하는 방법.
6. 제5항에 있어서,
   상기 결정하는 단계는 서비스 상태 관리 및 구성 기능에 의해 수행되는 방법.
7. 제1항 또는 제2항에 있어서,
   상기 서비스 능력으로부터 상기 새로운 서비스가 인에이블링된다는 응답을 수신하는 단계를 더 포함하는 방법.
8. 제1항 또는 제2항에 있어서,
   상기 다른 서비스 계층 기능 또는 상기 애플리케이션 중 어느 것이 상기 서비스에 대해 통지할지를 결정하는 단계를 더 포함하는 방법.
9. 제8항에 있어서,
   상기 결정하는 단계는 서비스 조정 기능에 의해 수행되는 방법.
10. 네트워크에서 서비스의 제거를 관리하기 위한, 컴퓨터에 의해 구현되는 방법으로서,
    서비스 계층 기능 내에서 서비스 API를 통해 서비스의 제거를 관리하기 위한 요청을 수신하는 단계;
    제거될 상기 서비스를 식별하는 단계;
    서비스 상태 갱신 요청을 서비스 상태 관리 및 구성 기능에 전송하는 단계; 및
    상기 서비스가 제거되었다는 것을 애플리케이션 또는 다른 서비스 계층 기능에 통지하는 단계
    를 포함하는 방법.
11. 제10항에 있어서,
    상기 요청은 서비스 제공자 ID, 서비스 ID, 소프트웨어 모듈 정보, RESTful 서비스 API 및 이들의 조합들로부터 선택된 서비스 설명 속성을 포함하는 방법.
12. 제10항 또는 제11항에 있어서,
    상기 서비스의 한 버전 또는 상기 서비스 전체가 제거되는지를 결정하는 단계를 더 포함하는 방법.
13. 제12항에 있어서,
    상기 결정하는 단계는 서비스 상태 관리 및 구성 기능에 의해 수행되는 방법.
14. 제10항 또는 제11항에 있어서,
    상기 서비스의 상기 서비스 API를 제거하라는 요청을 서비스 API 관리 기능에 전송하는 단계를 더 포함하는 방법.
15. 제10항 또는 제11항에 있어서,
    상기 서비스가 제거되었다는 것을 상기 서비스 계층 기능 내의 서비스 능력에 통지하는 단계를 더 포함하는 방법.
16. 제14항에 있어서,
    상기 결정하는 단계는 서비스 조정 기능에 의해 수행되는 방법.
17. 네트워크 상의 컴퓨터로 구현되는 장치로서,
    서비스 API를 통해 서비스를 관리하기 위한 실행 가능 명령어들을 포함하는 비일시적 메모리; 및
    상기 메모리에 동작 가능하게 결합되는 프로세서
    를 포함하고,
    상기 프로세서는
    서비스 능력을 포함하는 서비스 계층 기능을 포함하고, 상기 서비스 계층 기능은 상기 서비스 및 상기 서비스 능력을 관리하도록 구성되고,
    상기 서비스 계층 기능은
    상기 서비스의 처리 및 통신을 상기 서비스 능력, 애플리케이션 또는 다른 서비스 계층 기능과 조정하도록 구성되는 서비스 조정 기능; 및
    상기 서비스의 서비스 API를 관리하도록 구성되는 서비스 API 관리 기능
    을 포함하는 장치.
18. 제17항에 있어서,
    상기 서비스 계층 기능은 상기 서비스를 추가, 활성화, 비활성화 또는 제거함으로써 상기 서비스를 관리하는 장치.
19. 제17항에 있어서,
    상기 장치는 네트워크 노드인 장치.
20. 네트워킹된 시스템으로서,
    제17항 내지 제19항 중 어느 한 항의 장치; 및
    애플리케이션 도메인
    을 포함하는 시스템.

Images