KR20180034603A - 서비스 요소 호스트 선택 - Google Patents

Abstract

사물 인터넷 서비스와 같은 서비스는 복수의 서비스 요소들을 가질 수 있다. 각각의 서비스 요소는 복수의 디바이스들 또는 가상 디바이스들(서비스 요소 호스트들)에 의해 제공될 수 있다. 서비스/서비스 요소는 수신인 계층에서 리소스로서 관리될 수 있다. 복수의 서비스 요소들을 갖는 서비스가 지원된다. 클라이언트로부터의 QoS 요구 사항에 기반하여, 서비스 요소 호스트 선택은 필요한 컨텍스트 정보를 이용하여 서비스 요소 호스트를 선택하는 결정을 내릴 수 있다. 클라이언트는 QoS 요구 사항을 수신인 호스트에 전송하도록 선택할 수 있으며, 수신인 호스트는 차례로 이를 서비스 요소 호스트 선택에 전달할 수 있다.

Description

서비스 요소 호스트 선택

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

본 출원은 "SERVICE ELEMENT HOST SELECTION"이라는 명칭으로 2015년 8월 4일에 출원된 미국 가특허 출원 제62/200,681호의 이득을 주장하며, 그 개시 내용은 본 명세서에 참조로서 포함된다.

IoT 서비스

사물 인터넷(IoT; Internet of Things)은 수십억 대의 디바이스가 공용 또는 사설 네트워크들을 통해 모두 상호 연결되어 정보를 감지, 전달 및 공유할 수 있는 세계이다. 이러한 상호 연결된 디바이스들은 데이터를 정기적으로 수집하고, 분석하며 동작 개시에 이용함으로써 풍부한 서비스들을 제공한다.

도 1은 IoT 시스템에서 애플리케이션들뿐만 아니라 디바이스들, 게이트웨이들, 라우터들 및 서버들의 배치를 도시한다. 본 명세서에서, 사용자, 클라이언트 및 애플리케이션이란 용어는 상호 교환적으로 이용되고, 서비스들을 요청하는 엔티티를 지칭한다. 클라이언트들은 애플리케이션들(예를 들면, AE)의 형식일 수 있다. 사용자는 전화기에 애플리케이션을 설치한 후 서비스에 액세스할 수 있다. 디바이스 애플리케이션 도메인(101)에서의 디바이스들은 데이터를 감지 및 수집하며, 데이터는 인터넷 서버들, 운영자 네트워크 또는 클라우드들뿐만 아니라 액세스 네트워크들에서의 디바이스들 자체에 또는 연결된 게이트웨이들에 저장되어 네트워크 애플리케이션 도메인(105)에서의 애플리케이션들 또는 사용자들에게 서비스들을 제공할 수 있다.

oneM2M 서비스 계층

개발중인 oneM2M 표준(전체적으로 참조로서 포함된 oneM2M-TS-0001 oneM2M Functional Architecture-V-1.6.1)은 공통 서비스 엔티티("Common Service Entity"(CSE))라고 지칭되는 서비스 계층(SL)을 정의한다. SL은 e-Health, 차량 관리 및 스마트 홈들과 같은 상이한 "수직" 기기간(machine-to-machine)(M2M) 시스템들 및 애플리케이션들에 의해 활용될 수 있는 "수평" 서비스들을 제공한다. 도 2에 도시된 바와 같이, CSE(110)는 복수의 기준점들을 지원한다. Mca 기준점(111)은 애플리케이션 엔티티(AE)(112)와 인터페이싱한다. Mcc 기준점(도시되지 않음)은 동일한 서비스 제공자 도메인 내에서 다른 CSE와 인터페이싱하고, Mcc' 기준점(114)은 상이한 서비스 제공자 도메인 내에서 다른 CSE(116)와 인터페이싱한다. Mcn 기준점(117)은 하위(underlying) 네트워크 서비스 엔티티(NSE)(118)와 인터페이싱한다. NSE(118)는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 하위 네트워크 서비스들을 CSE들에 제공한다.

oneM2M 아키텍처는 ASN(application service node), ADN(application dedicated node), MN(middle node) 및 IN(infrastructure node)을 가능하게 한다. ASN은 하나의 CSE를 포함하며 적어도 하나의 AE를 포함하는 노드이다. 물리적 매핑의 예는 M2M 디바이스에 존재하는 ASN이다. ADN은 적어도 하나의 AE를 포함하며 CSE를 포함하지 않는 노드이다. 물리적 매핑의 예는 제약된 M2M 디바이스에 존재하는 ADN이다. MN은 하나의 CSE를 포함하며 0개 이상의 AE를 포함하는 노드이다. MN에 대한 물리적 매핑의 예는 M2M 게이트웨이에 존재하는 MN이다. IN은 하나의 CSE를 포함하며 0개 이상의 AE를 포함하는 노드이다. IN에 대한 물리적 매핑의 예는 M2M 서비스 인프라스트럭처에 존재하는 IN이다. 또한, oneM2M 엔티티들(AE들도 아니고 CSE들도 아님)을 포함하지 않는 노드인 비-oneM2M 노드가 있을 수 있다. 이러한 노드들은 관리를 포함한 상호 연동 목적을 위해 oneM2M 시스템에 부착된 디바이스들을 나타낸다.

oneM2M에서의 리소스 구조

AE들, CSE들, 데이터 등과 같은 oneM2M 시스템(전체적으로 참조로서 포함된 oneM2M-TS-0001 oneM2M Functional Architecture-V-1.6.1)에서의 엔티티들은 리소스들로서 표현된다. 리소스 구조는 이러한 리소스들의 표현으로서 지정된다. 이러한 리소스들은 고유하게 어드레싱 가능하다.

리소스들은 도 3에 도시된 바와 같은 테이블 표기법을 통해 지정되며, 이하에서 보다 상세하게 설명된다. 리소스들(예를 들어, 리소스(121))은 CSE(110)와 연관되어 지정된다. 리소스들은 oneM2M 시스템 내의 구성요소들 및 요소들(elements)의 CSE(110)에서의 표현이다. 다른 CSE들, AE들, 센서들, 명령들 등을 나타내는 애플리케이션 데이터는 그 리소스 표현을 통해 CSE(110)에 알려진다. 리소스(121)는 oneM2M 아키텍처에서 고유하게 어드레싱 가능한 엔티티로서 설명될 수 있다. 리소스(121)는 자식 리소스들(예컨대, 자식 리소스(123)) 및 속성들(예컨대, 속성(122))을 포함할 수 있다. 자식 리소스(123)는 그 부모 리소스인 다른 리소스(리소스(121))의 서브-리소스로서 정의될 수 있다. 부모 리소스(리소스(121))는 자식 리소스들에 대한 참조들(references)을 포함한다. 속성(122)은 리소스 자체에 관한 정보를 저장한다.

그래픽 표현들은 속성들 및 자식 리소스들을 표현하는데 이용된다. 사각형 박스들은 리소스들(예를 들어, 리소스(121) 및 자식 리소스(123))에 이용되고, 둥근 모서리를 가진 사각형 박스들은 속성들(예를 들어, 속성(122))에 이용된다. <resourceType>에서의 속성들은 도 3에 도시된 바와 같을 수 있다. 알림 가능 <resourceType> 리소스에 대한 속성 테이블은 '<resourceTypeAnnc>에 대한 속성들'이라는 제목의 추가 열을 포함하고 그 <resourceType>에 대해 알려질 속성들을 표시한다.

속성들에 대한 액세스 모드들은 판독/기입(RW), 판독 전용(RO) 및 1회 기입(WO)과 같은 값들을 가정할 수 있다. RW와 관련하여, 속성의 값은 리소스가 기원자로부터의 정보(예를 들어, 콘텐츠 파라미터)에 기반하여 생성 또는 갱신될 때 설정된다. 이러한 속성들은 생성/갱신/검색/삭제/통지 동작들에 대해 허용된다. RO의 경우, 속성의 값은 호스팅 CSE에 의해 내부적으로 설정된다. 이러한 속성은 검색 동작에만 허용된다. 또한, WO에서, 속성의 값은 리소스가 기원자로부터의 정보(예를 들어, 콘텐츠 파라미터)에 기반하여 생성될 때 설정된다. 이러한 속성은 생성 후에 검색 동작에 대해 허용된다.

자식 리소스들과 속성들 모두에 대한 다중도는 상이하게 연관된 의미들을 갖는 값들을 가질 수 있다. "0"의 값은 자식 리소스/속성이 존재하지 않는다는 것을 표시한다. "1"의 값은 자식 리소스/속성이 존재한다는 것을 표시한다. "0..1"의 값은 자식 리소스/속성이 존재할 수 없다는 것을 표시한다. 자식 리소스/속성이 존재하는 경우, 하나의 인스턴스만을 가질 수 있다. "0..n"의 값은 자식 리소스가 존재할 수 없다는 것을 표시한다. 자식 리소스가 존재하는 경우, 복수의 인스턴스들이 지원된다. "1..n"의 값은 자식 리소스가 항상 존재한다는 것을 표시한다. 자식 리소스는 적어도 하나의 인스턴스를 가지며 복수의 인스턴스들을 가질 수 있다. (L)이 뒤에 부가된 속성 다중도는 그것이 값들의 리스트라는 것을 표시한다.

속성 표에서 <resourceTypeAnnc>에 대한 속성들은 다음의 값들의 세트를 가질 수 있다.

·MA(Mandatory Announced): 원래 리소스에서의 속성이 알려진 리소스에 알려진다. 이러한 알려진 속성들의 내용은 원래 속성의 내용과 동일하다.

·OA(Optional Announced): 원래 리소스에서의 속성이 원래 리소스에서의 announcedAttribute 속성의 내용들에 따라 알려진 리소스에 알려질 수 있다. 이러한 알려진 속성의 내용은 원래 속성의 내용과 동일하다.

·NA(Not Announced): 원래 속성은 알려진 리소스에 알려지지 않는다.

oneM2M 서비스 아키텍처

oneM2M Service Component Architecture, TS-0007 Service Component Architecture-V-0.7.0 (전체적으로 참고로서 포함됨)에 설명된 M2M 서비스 아키텍처는 M2M 애플리케이션 및 M2M 서비스 제공자들에게 제공되는 M2M 서비스들을 지정하여 oneM2M 기능 아키텍처를 보강한다. 도 2에 도시된 바와 같이, 서비스 노출 구성요소(113), 네트워크 서비스 이용 구성요소(115) 및 원격 서비스 노출 구성요소(119)와 같은 복수의 구성요소들이 존재할 수 있다. 서비스 노출 구성요소(113)는 AE들에 서비스들을 노출시킨다. 네트워크 서비스 이용 구성요소(115)는 NSE (118)로부터의 서비스들을 소비한다. 원격 서비스 노출(116)은 상이한 M2M 환경들로부터의 서비스들을 연결한다.

개발중인 oneM2M 표준(oneM2M Functional Architecture)은, 도 4에 도시된 바와 같이, CSE라고 지칭되는 서비스 계층을 정의한다. Mca 기준점은 AE와 인터페이싱한다. Mcc 기준점은 동일한 서비스 제공자 도메인 내의 다른 CSE와 인터페이싱하고, Mcc' 기준점은 상이한 서비스 제공자 도메인에서의 다른 CSE와 인터페이싱한다. Mcn 기준점은 하위 NSE와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 하위 네트워크 서비스들을 CSE들에 제공한다. CSE는 "발견" 또는 "데이터 관리 & 저장소"와 같이 "CSF들(Common Service Functions)"로 지칭되는 복수의 논리 기능들을 포함한다. 도 5는 oneM2M에 대한 예시적인 CSF들을 도시한다.

oneM2M 아키텍처는 ASN, ADN, MN 및 IN을 가능하게 한다. ASN은 하나의 CSE를 포함하며 적어도 하나의 AE를 포함하는 노드이다. 물리적 매핑의 예는 M2M 디바이스에 존재하는 ASN이다. ADN은 적어도 하나의 AE를 포함하며 CSE를 포함하지 않는 노드이다. 물리적 매핑의 예는 제약된 M2M 디바이스에 존재하는 ADN이다. MN은 하나의 CSE를 포함하며 0개 이상의 AE를 포함하는 노드이다. MN에 대한 물리적 매핑의 예는 M2M 게이트웨이에 존재하는 MN이다. IN은 하나의 CSE를 포함하며 0개 이상의 AE를 포함하는 노드이다. IN에 대한 물리적 매핑의 예는 M2M 서비스 인프라스트럭처에 존재하는 IN이다.

이하는 oneM2M RESTful 아키텍처에 따른 추가적인 컨텍스트이다. CSF들(capability service functions)은 "리소스들"의 세트로 표현된다. 리소스는 oneM2M 아키텍처에서 고유하게 어드레싱 가능한 엔티티이다. 리소스는 CRUD(Create, Retrieve, Update 및 Delete)와 같은 RESTful 방법들을 통해 조작되고 전달될 수 있는 표현을 가지며, URI(uniform resource identifier)를 이용하여 어드레싱된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 자신의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모 리소스의 수명에 의해 제한될 수 있다. 각각의 리소스는 그 정보를 저장하는 "속성들"의 세트를 지원할 수 있다.

본 명세서에는 서비스 요소 호스트 선택 서비스(service element host selection service)(SEHS)를 위한 방법들, 시스템들 및 디바이스들이 개시되어 있다. 첫 번째 예에서, 클라이언트로부터의 QoS 요구 사항(requirement)에 기반하여, SEHS는 필요한 컨텍스트 정보를 이용하여 서비스 요소 호스트 선택에 대한 결정을 내릴 수 있다. 클라이언트는 QoS 요구 사항을 서비스 호스트로 전송하고, 이어서 이를 SEHS에 전달하도록 선택할 수 있다. SEHS는 서비스 요청을 유사하게 처리할 수 있다.

다른 예에서, SEHS는 클라이언트 불만족(예를 들어, 파라미터의 최소 임계 값을 충족시키지 못함) 등을 포함할 수 있는 컨텍스트 변경과 같은 시나리오들에서 서비스 요소 호스트(들)를 재선택할 수 있다. 다른 예에서, SEHS는 전환이 필요할 때 서비스 요소 호스트들의 복수의 후보들을 선택할 수 있다.

다른 예에서, SEHS는 클라이언트로부터 기원된 서비스 요소 검색의 시퀀스를 고려할 수 있으며, 이에 따라 클라이언트에 대한 서비스 요소 호스트 선택에 대해 더 정확한 결정을 내릴 수 있다.

특히 본 명세서에서 설명된 바와 같은 방법들, 시스템들 및 장치들은 서비스 호스트 선택 등을 위한 수단을 제공할 수 있다. 이하의 예에서, 방법, 시스템, 컴퓨터 판독가능 저장 매체 또는 장치는, 서비스에 대한 요청 및 서비스 품질 요구 사항을 포함하는 메시지를 수신하고, 이 메시지에 기반하여 서비스 요소 호스트를 결정하며, 그 요청을 서비스 요소 호스트에 전달하기 위한 수단을 갖는다. 이러한 메시지는 서비스의 식별자를 포함할 수 있다. 메시지는 서비스 호스트로부터 온다는 것을 표시할 수 있다. 메시지는 서비스가 구성되는 서비스 요소들의 수를 포함할 수 있다. 메시지는 각각의 서비스 요소에 대한 복수의 서비스 요소 호스트들의 표시자를 포함할 수 있다. 메시지는 제1 서비스에 대한 제1 서비스 요소를 처리하는 시퀀스의 표시자를 포함할 수 있다. 제1 서비스 요소는 온도 데이터일 수 있다.

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

첨부된 도면들과 연계하여 예에 의해 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 IoT 시스템에서 애플리케이션들 및 사용자들뿐만 아니라 디바이스들, 게이트웨이들, 라우터들 및 서버들의 예시적인 배치를 도시한다.
도 2는 예시적인 oneM2M 서비스 아키텍처를 도시한다.
도 3은 예시적인 <resourceType> 표현 관례를 도시한다.
도 4는 예시적인 oneM2M 기능 아키텍처를 도시한다.
도 5는 예시적인 oneM2M 공통 서비스 기능들을 도시한다.
도 6은 서비스 요소들의 이용을 포함하는 날씨 추론 서비스에 대한 예시적인 이용 사례를 도시한다.
도 7은 서비스 요소 호스트들 및 클라이언트들을 갖는 예시적인 네트워크를 도시한다.
도 8은 서비스, 서비스 요소 및 호스트 보고(이하, S-SEaH 보고)와 연관된 예시적인 메시지 흐름을 도시한다.
도 9는 서비스 호스트 선택의 예시적인 아키텍처를 도시한다.
도 10은 서비스 호스트 선택의 예시적인 아키텍처를 도시한다.
도 11은 도 9의 시나리오의 서비스 요소 호스트 선택을 갖는 QoS 기반 서비스 요청의 예시적인 메시지 흐름을 도시한다.
도 12는 도 10의 시나리오의 서비스 요소 호스트 선택을 갖는 QoS 기반 서비스 요청의 예시적인 메시지 흐름을 도시한다.
도 13은 서비스 요소 호스트 재선택의 예시적인 메시지 흐름을 도시한다.
도 14는 서비스 요소 호스트 재선택의 예시적인 메시지 흐름을 도시한다.
도 15는 서비스 요소 호스트들의 복수의 후보들을 갖는 서비스 요청의 예시적인 메시지 흐름을 도시한다.
도 16은 서비스 요소들의 시퀀스를 고려하는 예시적인 시나리오를 도시한다.
도 17은 서비스 요소들의 시퀀스를 고려하는 예시적인 시나리오를 도시한다.
도 18은 예시적인 oneM2M 서비스 요소 호스트 선택들의 공통 서비스 기능을 도시한다.
도 19는 oneM2M ROA에서의 예시적인 서비스 요청을 도시한다.
도 20은 <serviceRequest>의 예시적인 리소스 구조를 도시한다.
도 21은 서비스, 서비스 요소 보고, 서비스 요청의 예시적인 메시지 흐름을 도시하다.
도 22는 예시적인 oneM2M 서비스 요소 호스트 선택 서비스 구성요소를 도시한다.
도 23은 본 명세서에서 논의된 방법들 및 시스템들에 기반하여 생성될 수 있는 예시적인 디스플레이를 도시한다.
도 24a는 개시된 과제가 구현될 수 있는 예시적인 기기간(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 시스템도이다.
도 24b는 도 24a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 24c는 도 24a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다.
도 24d는 도 24a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

본 명세서에는 사물 인터넷(IoT)에 이용될 수 있는 서비스를 제공하기 위해 하나 이상의 서비스 요소를 이용하는 것이 개시되어 있다. 각각의 서비스 요소는 복수의 디바이스들 또는 가상 디바이스들(서비스 요소 호스트들)에 의해 제공될 수 있다. 본 명세서에서는 서비스, 서비스 호스트, 서비스 요소 및 서비스 요소 호스트와 같은 서비스 계층과 연관된 개념들이 더 상세히 논의된다. 서비스는 고객들이 관심을 갖고, 고객들의 의견에 기반하여 일련의 결과들 및 제품들을 제공할 수 있는 일련의 조치들, 기능들 또는 데이터로 간주될 수 있다. 애플리케이션의 형태일 수 있는 서비스들을 요청하는 엔티티가 클라이언트로 고려될 수 있다. 서비스 호스트는 서비스를 알리고 서비스에 액세스할 수 있는 인터페이스들을 고객들에게 제공할 수 있는 엔티티이다. 서비스 호스트는 서비스 요소들로부터 전체 서비스를 형성하여 이를 서비스 요청의 출처로 전달할 수 있다. 서비스 요소는 서비스가 구성되는 개별 구성요소로 간주될 수 있다. 서비스 요소는 대개 서비스를 제공하는데 이용되는 데이터(예를 들어, 물리적 세계로부터 감지된 데이터)이다. 예를 들어, 서비스 요소는 온도 또는 혈당 데이터일 수 있다. 마지막으로, 서비스 요소 호스트는 서비스 요소의 물리적 호스트로서 정의될 수 있다. 하나의 서비스 요소 호스트 상에 복수의 그리고 상이한 서비스 요소들(예를 들어, 온도 또는 습도)이 있을 수 있다.

도 6은 서비스 요소들의 이용을 포함하는 날씨 추론 서비스에 대한 이용 사례를 도시한다. 도 6에서, 이웃(130)은 서비스 요소들(예를 들어, 온도, 습도 및 CO2) 및 온도 센서(131), 습도 센서(132) 및 CO2 센서(134)와 같은 대응하는 서비스 요소 호스트들을 포함한다. 날씨 추론 서비스 호스트(133)는 다양한 디바이스들로부터 수집된 데이터에 기반하여 추론을 생성하고 그 서비스를 다른 이들에게 제공할 수 있다.

예를 들어, 도 6을 참조하면, 추론은 이웃(130)에서의 쾌적한 날인지의 여부 일 수 있으며, 이는 이웃(130)에 배치된 다양한 센서 디바이스들에 의해 수집된 온도, 습도 및 CO2(예를 들어, 대기 오염) 데이터에 기반할 수 있다. 도 6에 도시된 바와 같이, 다양한 센서 디바이스들은 파라미터들, 예컨대 온도, 습도 및 CO2 각각을 감지하도록 이웃(130)에 배치된다. 이 특정 날씨 추론 서비스는 서비스 호스트 인 게이트웨이(133)를 갖는다. 날씨 추론 서비스는 3개의 서비스 요소를 가지며, 이들 각각의 서비스 요소는 복수의 호스트들을 갖는다. 본 명세서에서는, 애플리케이션들 등이 적합한 액세스 권리들을 갖고 서비스 요소들을 요청하는 것이 허용되도록 서비스 호스트(예를 들어, 날씨 추론 서비스 호스트(133)) 및 서비스 요소 호스트(예를 들어, 온도 센서(131) 또는 습도 센서(132))와 등록 관계를 갖는 것으로 가정된다.

종래에는, 복수의 서비스 요소들로 구성된 (본 명세서에서 정의되는 바와 같은) 서비스를 지원하는 기능이 결여되어 있었다. 종래의 서비스 계층(예컨대, oneM2M 서비스 계층)은 이러한 서비스의 개념을 가지지 않으며, 서비스가 복수의 서비스 요소들로 구성될 수 있는 시나리오들을 지원하지 않는다. 종래의 서비스 계층에는 많은 리소스들이 정의되어 있지만 물리적인 세계로부터 수집된 데이터만을 저장한다. 클라이언트는 그 데이터를 검색하여 이를 로컬로 처리할 수 있을 것이다. 또한, 종래의 서비스 계층은 복수의 서비스 요소들로 구성될 수 있는 서비스의 정보를 처리 및 유지하는 방법들을 제공하지 않는다. 이러한 방법들이 없으면, 서비스 계층에서 서비스를 발견하거나 이용할 수 없다.

본 명세서에서 논의된 바와 같이, 서비스는 서비스 요소들이 모은 데이터에 기반하여 정보를 결정한다(이것은 종래의 서비스 계층들에서 행해졌던 것과 같이 데이터를 단지 저장하는 것이 아니다). 본 명세서에 개시된 서비스는 물리적인 세계를 감지함으로써 제공되는 데이터를 이용할 수 있다. 이 새로운 서비스는 클라이언트가 서비스를 발견하고 이용할 수 있게 하는 서비스 계층에 의해 제공될 수 있다. 예를 들어, 도 6을 참조하면, 본 명세서에 개시된 서비스는 쾌적한지 또는 이웃(130)과 관련하여 쾌적한지 추론할 수 있다. 다른 예는 혈압 데이터와 연관된다. 어떤 사람이 건강이 좋거나 또는 임의의 약물이 필요한지를 결정하는 서비스가 제공될 수 있다.

서비스 요소들(예를 들어, 온도, 습도 및 CO2 데이터)을 수신하는 클라이언트들(예를 들어, 애플리케이션들 등)은 센서 디바이스들(예를 들어, 서비스 요소 호스트들)의 상이한 조합들로부터 서비스 요소들을 수신할 수 있으며, 날씨 및 환경 조건들에 대한 사용자의 안락함 수준과 연관된 자체 정의들(예를 들어, 수용 가능한 결정/추론을 제공하는데 이용되는 하나 이상의 서비스 요소와 연관된 데이터의 최소 임계값)에 기반하여 추론들을 할 수 있다. 다른 예에서, 서비스 호스트(예를 들어, 게이트웨이(133))는 상이한 센서 디바이스들로부터 수신된 서비스 요소들에 기반하여 안락함의 전반적인 수준을 결정할 수 있다. 안락함의 전반적인 수준은 예를 들어 그 서비스 호스트 또는 서비스 호스트들의 그룹에 의해 모든 또는 거의 모든 서비스들과 연관될 수 있다.

클라이언트들은 도 7에 도시된 바와 같이 라우터들을 통해 네트워크에 연결된 상이한 물리적 위치들로부터 서비스를 요청할 수 있다. 일 예에서, 클라이언트들(예를 들어, 도 7에서의 클라이언트(141, 142, 143 또는 144)) 각각은 그 서비스를 수신하기 위한 자체 서비스 품질(QoS) 요구 사항을 가질 수 있다. QoS는 최단 총 거리, 최소 전체 응답 시간 등일 수 있다. 도 7에서, 서비스 호스트(155)는 일 예로서 게이트웨이 상에 있을 수 있다. 도시된 바와 같이, 이러한 서비스를 위한 3개의 서비스 요소가 있다: 서비스 요소 A, B, C는 다음과 같다.

·서비스 요소 A는 서비스 요소 호스트(146, 147 및 148)를 갖는다.

·서비스 요소 B는 서비스 요소 호스트(152 및 153)를 갖는다.

·서비스 요소 C는 서비스 요소 호스트(149, 150, 151 및 154)를 갖는다.

클라이언트(141) 및 클라이언트(144)가 최단 총 거리의 QoS를 갖는 요청을 전송하면, 서비스 요소 호스트(146, 152 및 154)가 서비스 요소 A, B 및 C를 클라이언트(141)에 제공하는 것이 최적이다. 클라이언트(144)에 대해서는, 서비스 요소 호스트(147, 153 및 149)가 서비스 요소 A, B 및 C를 제공하는 것이 최적이다. 다른 예에서, 클라이언트(151) 및 클라이언트(149)가 최소 전체 응답 시간의 QoS를 갖는 요청을 전송하면, 서비스 요소 호스트(146, 152, 149)가 서비스 요소 A, B, C를 클라이언트(142) 및 클라이언트(143)에게 제공하는 것이 최적이다(이 예에서는 다른 피어 서비스 요소 호스트들과 비교하여 응답 시간이 가장 짧다고 가정한다).

이러한 요청에서 QoS 요구 사항을 고려하여 서비스 요청에 응답하는 것이 중요할 수 있다. 종래의 시스템들은 서비스가 복수의/상이한 서비스 요소 호스트들에서 호스팅되는 복수의 서비스 요소들로 구성될 수 있다는 것을 이해하지 못했을 뿐만 아니라 관련 컨텍스트 정보를 이해하지 못했기 때문에 서비스 요소들을 효율적으로 이용하고 선택할 수 없었다. 종래의 시스템들은 잘 지원되지 않고, 본 명세서에서 논의되는 바와 같이 클라이언트로부터의 QoS 요구 사항을 만족시키기 위해 최상의 서비스 요소 호스트들을 찾도록 동작하지 않는다. 현재로는, 본 명세서에서 논의되는 바와 같은 이러한 요인들을 고려할 수 있는 서비스 요소 호스트 선택 기능이 부족하다.

제시된 개념들을 위해 oneM2M을 이용하여 구현된 oneM2M 예들 이외에, 서비스 계층이 복수의 서비스 요소들을 갖는 서비스를 지원하기 위한 능력들을 제공하는 방식들이 이하에 개시되어 있다. 특히 도 9 내지 도 15에 도시된 단계들을 수행하는 엔티티들은, 도 24c 또는 도 24d에 도시된 것들과 같은 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 점을 알 것이다. 즉, 특히 도 9 내지 도 15에 도시된 방법(들)은 도 24c 또는 도 24d에 도시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능 명령어들은 컴퓨팅 디바이스의 프로세서에 의해 실행될 때 특히 도 9 내지 도 15에 도시된 단계들을 수행한다. 일 예에서, M2M 디바이스들의 상호 작용에 관해 이하에서 더 상세히 설명하는 바와 같이, 도 8의 서비스 호스트(161)는 도 24a의 M2M 게이트웨이 디바이스(14)에 존재할 수 있는 반면에, 도 14의 클라이언트(170)는 도 24a의 M2M 디바이스(18)에 존재할 수 있다.

도 8은 서비스, 서비스 요소 및 호스트 보고(이하, S-SEaH 보고)와 연관된 예시적인 메시지 흐름을 도시한다. 서비스 계층(162)은 각각의 서비스에 대한 서비스, 서비스 요소 및 서비스 요소 호스트 기록을 구축하기 위해 S-SEaH 보고의 입력을 취한다. 본 명세서에서 논의된 바와 같이, 서비스는 하나 이상의 서비스 요소(들)로 구성된다. 각각의 서비스 및 각각의 서비스 요소에는 serviceID 또는 elementID가 각각 할당될 수 있다.

도 8을 참조하면, 단계(164)에서 서비스 계층(162)은 서비스 호스트(161)로부터 기인할 수 있는 S-SEaH 보고 메시지를 수신한다. 표 1은 S-SEaH 보고 메시지에 포함될 수 있는 내용의 예, 특히 새로운 서비스가 언제 이용 가능한지의 예를 제공한다.

[표 1]

이러한 S-SEaH 보고 메시지는 특히 serviceID, numOfElement, elementID, numOfElementHost, listOfElementHost 및 serviceElementOrder를 포함할 수 있다. serviceID는 서비스를 나타내고 구별할 수 있는 식별자이다. serviceID는 서비스 디렉토리와 같은 중심점에 의해 할당될 수 있으며, 각각의 서비스는 고유한 식별자를 갖는다. 일 예로서, serviceID는 자신을 다른 것들과 구별하는 몇몇 라벨들뿐만 아니라 서비스의 설명을 포함할 수 있거나, URI 등일 수 있다. numOfElement는 서비스가 구성되는 서비스 요소들의 수를 표시한다. 이어서, numOfElement 필드는 도시된 바와 같이 그 식별자, 요소 호스트의 수 및 대응하는 호스트 식별자들을 갖는 서비스 요소일 수 있다. numOfElement 필드는 단계(164)의 S-SEaH 보고 메시지에 포함된 elementID들의 수로부터 획득될 수 있다.

elementID는 이 서비스 내의 서비스 요소를 나타내고 구별할 수 있는 식별자이다. elementID는 serviceID로부터 확장될 수 있다. 표 2를 참조하면, 서비스는 3개의 서비스 요소를 갖는 DeduceService1의 serviceID를 갖는다. elementID들은 serviceID로부터 확장되며, DeduceService1.temperature, DeduceService1.humidity 및 DeduceService1.air이다. numOfElementHost는 각각의 서비스 요소에 대한 요소 호스트들의 수를 표시한다. numOfElementHost 필드는 listOfElementHost 필드를 고려하여 추론될 수 있다.

listOfElementHost는 각각의 서비스 요소에 대한 서비스 요소 호스트들의 리스트 또는 다른 표시자를 포함한다. 일 예에서, numOfElement 후에는, 후속하는 elementID, numOfElementHost, listOfElementHost의 복수의 조합이 있을 수 있다. 서비스 요소 호스트들은 서비스 호스트에 등록되거나 서비스 호스트에 의해 발견 된 서비스 요소 호스트에 의해 서비스 호스트에 알려지고 갱신된다. serviceElementOrder는 서비스를 요청할 때 서비스 요소들의 시퀀스의 인자(예를 들어, 표시자)를 고려한다. 즉, 서비스의 서비스 요소들은 전체 서비스를 얻기 위해 클라이언트들이 수신해야 하는 미리 결정된 오더들을 가질 수 있다. 그러한 오더 요건이 없다면, 이 필드는 S-SEaH 보고 메시지에서 제외될 수 있거나, S-SEaH 보고 내에 표시될 수 있다. 다른 필드들과 마찬가지로, serviceElementOrder는 검색될 수 있거나 클라이언트들에게 제공될 수 있다.

표 2는 메시지로부터 유도될 수 있는 예시적인 S-SEaH 기록을 도시한다. 이것은 또한 S-SEaH 기록 또는 보고 메시지에 대한 디스플레이 인터페이스(예를 들어, 디스플레이/터치 패드(42))상에 표시될 수 있는 것의 예일 수 있다. serviceElementOrder는 이 경우에 필요하지 않으므로 표 2에 도시되지 않는다. 표 2의 이러한 기록에 포함되고, 전체에 걸쳐 서비스, 서비스 요소 및 서비스 요소 호스트에 대한 식별자들은 예시적인 목적들을 위한 것이며, 다른 가능한 형태들, 예를 들어 IP 주소, MSISDN 또는 IMSI일 수 있다.

계속해서 도 8을 참조하면, 단계(165)에서, 서비스 계층(162)은 표 2에 도시 된 것과 유사할 수 있는 S-SEaH 기록을 생성한다. 표 2의 S-SEaH 기록은 단계(164)에서 서비스 호스트(161)로부터 제공되는 메시지와 같은 S-SEaH 보고 메시지에 기반한다. 서비스 계층(162)은 DeduceService1을 적합하게 공유하거나 게시(publish)할 수 있다. 이에 따라, 서비스 계층(162)은 표 1의 정보를 유지하기 위한 속성들을 갖는 서비스 리소스를 가질 것이고 게시할 수 있다. 서비스 계층 (162)은 (일부 경우들에서) 서비스 요소들 등을 가산하거나 감할 수 있는 갱신 정보만을 전송할 수 있다. 단계(166)에서, 서비스 계층(162)은 서비스 호스트(162)에 메시지를 전송한다. 단계(166)의 메시지는 기록이 그 서비스에 대해 성공적으로 생성되었음을 표시할 수 있다(또는 불완전하거나 상충되는 정보와 같은 이유들로 기록 생성이 실패하였음을 표시할 수 있다).

서비스 계층(162) 및 서비스 호스트(161)와 관련하여 더 명확히 하기 위해, 서비스 호스트(161)는 주로 서비스(예를 들어, DeduceService1)에 대해 알고 있다. 이에 따라, DeduceService1을 갖는 서비스 호스트(161)는 서비스 계층(162)에 DeduceService1을 게시하기를 원할 수 있다. 서비스 계층(162)에 의해 제공되는 기능 때문에, 클라이언트들은 서비스 호스트(161)의 DeduceService1(및 다른 서비스들)을 발견할 수 있다. 서비스 계층(161)은 서비스 호스트(161)에 의해 제공되는 서비스들이 발견되어 클라이언트에 의해 이용될 수 있도록 서비스(예를 들어, DeduceService1)의 정보를 관리할 수 있다.

본 명세서에는 서비스 요소 호스트 선택 서비스(SEHS)의 기능들이 개시되어 있다. 도 9 및 도 10은 각각 SEHS에 대한 별개의 시나리오를 도시한다. 제1 시나리오를 요약하면, 클라이언트는 QoS 기반 서비스 요청을 SEHS에 전송할 수 있다. SEHS는 이 요청을 처리하고, 클라이언트의 QoS에 기반하여 적합한 서비스 요소 호스트들을 선택하며, 이 서비스 요소 요청을 서비스 요소 호스트들에 발송(dispatch)한다. 제2 시나리오를 요약하면, 클라이언트는 QoS 기반 서비스 요청을 서비스 호스트에 직접 전송할 수 있으며, 서비스 호스트는 차례로 이 요청을 SEHS에 전달한다. 이 시나리오는 클라이언트가 상이한 서비스 요소 호스트들로부터의 서비스 요소들을 피어싱(piece)하여 전체 서비스를 함께 구성하고 서비스 호스트를 이용하여 이를 처리할 수 있는 능력을 가질 수 없는 리소스 제약 디바이스에 클라이언트가 있는 경우에 발생한다. 마찬가지로, SEHS는 이 요청을 처리하고, 클라이언트의 QoS에 기반하여 적합한 서비스 요소 호스트들을 선택하며, 이 서비스 요소 요청을 서비스 요소 호스트에 발송한다. 두 시나리오에 대해서는 본 명세서에서 보다 상세히 논의된다.

보다 상세하게는, 제1 시나리오에서, 도 9에 도시된 바와 같이, 단계(181)에서, SEHS(171)는 클라이언트(170)로부터 온다는 것을 표시할 수 있는 서비스 요청을 수신한다. 단계(182)에서, SEHS(171)는 서비스 요소 호스트 선택 응답을 클라이언트(170)에 전송하며, 이는 클라이언트(170)에게 모든 선택된 서비스 요소 호스트들을 알릴 수 있다. SEHS(171) 내에서는, 서비스 요청에 기반한 QoS의 처리(블록(176)), 관련 컨텍스트 정보의 수집/결정(블록(177)), 서비스 요소 호스트의 선택/조정, 및 선택된 서비스 요소 호스트들 각각으로의 서비스 요청들의 발송이 있을 수 있다. 단계(183)에서, SEHS(171)는 서비스 요소 요청을 서비스 요소 호스트(172)에 전송한다. 단계(184)에서, 클라이언트(170)는 서비스 요소 호스트(172)로부터 온다는 것을 표시하는 서비스 요소 응답을 수신하고, 단계(184)에서의 응답은 어떤 클라이언트(172)가 요청했는지에 대응하는 서비스 결과 또는 콘텐츠(예를 들어, 서비스 요소 호스트가 온도 센서 노드인 경우에는 온도값)를 포함할 수 있다.

제2 시나리오에서는, 도 10에 도시된 바와 같이, 단계(191)에서, 서비스 호스트(173)는 클라이언트(170)로부터 온다는 것을 표시할 수 있는 서비스 요청을 수신한다. 단계(192)에서, 서비스 호스트(173)는 단계(191)의 요청을 SEHS(171)에 전송한다. 단계(193)에서, 서비스 호스트(173)는 SEHS(171)로부터 온다는 것을 표시하고 선택된 서비스 요소 호스트들을 포함할 수 있는 서비스 요소 호스트 선택 응답을 수신한다. SEHS(171) 내에서는, 서비스 요청에 기반한 QoS의 처리(블록(176)), 관련 컨텍스트 정보의 수집/결정(블록(177)), 서비스 요소 호스트의 선택/조정, 및 선택된 서비스 요소 호스트들 각각으로의 서비스 요청들의 발송이 있을 수 있다. 단계(194)에서, 서비스 요소 호스트(172)는 SEHS(171)로부터 온다는 것을 표시하는 서비스 요소 요청을 수신한다. 단계(195)에서, 서비스 호스트(173)는 서비스 요소 호스트(172)로부터 온다는 것을 표시하는 서비스 요소 응답을 수신하고, 단계(195)에서의 응답은 어떤 서비스 호스트(173)가 요청했는지에 대응하는 서비스 결과 또는 콘텐츠(예를 들어, 서비스 요소 호스트가 온도 센서 노드인 경우에는 온도값)를 포함할 수 있다. 단계(196)에서, 서비스 호스트(173)는 클라이언트(170)에 서비스 응답을 전송하고, 단계(196)에서의 응답은 개별적으로 또는 결합된/집합된 모든 서비스 요소들로부터의 서비스 결과 또는 콘텐츠를 포함할 수 있다.

도 9 및 도 10에 도시된 시나리오들 중 어느 하나에서, QoS 요구 사항은 서비스 요청에서 임의적일 수 있다. 서비스 호스트(173) 또는 SEHS(171)는 요청된 서비스의 특성들 또는 다른 인자들에 기반하여 클라이언트(170)에 대한 QoS 요구 사항을 결정할 수 있다. 서비스 호스트(173)는 QoS 요구 사항을 SEHS(171)에 제공할 수 있거나, 또는 QoS 요구 사항은 SEHS(171)에서 준비(provision)될 수 있다.

두 시나리오에서, SEHS(171)는 유사한 방식으로 동작할 수 있다. SEHS(171)가 서비스 요청을 수신하면, 블록(176)의 "QoS 기반 서비스 요청 처리"는 요청 메시지를 분석하고(예를 들어, 단계(181) 또는 단계(192)), 적합한 컨텍스트 정보에 대해 블록(177)의 "관련 컨텍스트 정보 수집"으로부터 입력을 수신할 수 있다. 블록(178)의 "서비스 요소 호스트의 선택 또는 조정"은 요청 메시지 및 수집된 컨텍스트 정보에 기반하여 서비스 요소 호스트들(172)을 선택하거나 재선택하는 것을 담당한다. 서비스 요소 호스트들(172)이 선택되거나 재선택된 후에, 블록(179)의 "선택된 서비스 요소 호스트들 각각으로의 서비스 요청 발송"은 그 요청의 발송을 담당한다.

이하에서는 SEHS(171)의 상호 작용들에 대해 보다 상세히 논의된다. 다음은 SEHS(171)와 연관된 메시지 구조, 메시지 내용 및 메시징 흐름의 예들이다. 클라이언트(170)는 부착된 라우터, 게이트웨이, 기지국 등을 통해 액세스함으로써 서비스 요청(예를 들어, 단계(181))을 전송할 수 있다(뒤의 프록시 라우터 또는 프록시 게이트웨이는 표현의 간략화를 위해 이용된다). 라우터는 클라이언트들에 대한 서비스 요청들을 SEHS(171) 또는 서비스 호스트(173)로 전송하기 위한 프록시로서 동작할 수 있다(SEHS(171)가 라우터를 서비스 요청의 발신자로 간주할 수 있음). 일 예에서, SEHS(171)는 도 19에 도시된 바와 같이 CSF로서 CSE에 존재할 수 있다. 프록시 라우터의 주소를 알고 있는 SEHS(171)는 라우터로부터 서비스 요소 호스트들(172)까지의 거리와 같은 라우터로부터의 컨텍스트 정보를 검색하는데 도움을 줄 수 있다. 이 예에서, 라우터로부터 서비스 요소 호스트들(172)까지의 거리들은 비교를 수행할 때 클라이언트(170)로부터 서비스 요소 호스트들(172)까지의 거리들과 등가인 것으로 간주될 수 있다. 예시적인 서비스 요청 메시지(예를 들어, 단계(181))가 표 3에 도시되어 있다.

표 3에서의 클라이언트의 주소는 서비스를 요청한 클라이언트(170)의 주소이다. 도 9에 요약된 제1 시나리오에서, 표 3의 프록시의 주소는 클라이언트(170)를 인터넷과 같은 네트워크에 연결할 수 있는 클라이언트(170)의 프록시 게이트웨이(예를 들어, 도 11의 프록시 게이트웨이(169))의 주소이다. 프록시 게이트웨이(169)의 주소는 초기에 클라이언트(170)에게 알려지지 않을 수 있다. 프록시 게이트웨이(169)는 자신의 주소를 추가함으로써 클라이언트(170)의 요청 메시지를 재공식화할 수 있다. 프록시 게이트웨이(169)는 자신의 주소를 추가하기 위해 요청 메시지를 검사할 수 있다고 가정한다. 제2 시나리오에서, 표 3의 프록시의 주소는 본 명세서에서 보다 상세히 논의되는 바와 같이 프록시 게이트웨이(169)가 서비스 호스트(173) 그 자체가 되도록 서비스 호스트(173)에 의해 리셋된다. 표 3의 serviceID는 클라이언트(170)가 요청하고 있는 서비스의 식별자이다. 클라이언트(170)가 서비스를 요청하기 전에, 예를 들어 oneM2M 아키텍처에서 CSE에 존재할 수 있는 서비스 디렉토리로부터 서비스를 발견하고, 서비스들의 메타데이터 및 의미들을 저장할 수 있는 것이 고려된다. 표 3의 QoS 요구 사항은 클라이언트(170)가 서비스 호스트(173)로부터 원하는 QoS이다. "요구 사항"이라는 용어가 이용되지만, 본 명세서에서 QoS 옵션들은 조건들 및 우선 순위가 허용하는 바와 같은 우선 순위에 기반하여 우선 순위가 매겨지고 구현될 수 있다는 점이 고려된다. SEHS(171)는 분석하고 이해할 수 있는 QoS 요구 사항들의 리스트를 유지할 수 있다. 이 리스트는 클라이언트(170)의 요청들에 기반하여 학습(예를 들어, 패턴 결정)되고 지속적으로 갱신될 수 있다. 예들은 다음의 사항들, 즉 최단 총 거리, 디바이스들 간의 케이블들의 길이, 최소 지연, 최소 응답 시간, 신뢰성, 최소 슬립 시구간 등을 포함할 수 있다. 클라이언트(170)는 함께 고려될 수 있는 복수의 QoS 요청을 가질 수 있다. 다음에서는 예시 목적을 위해 최단 총 거리를 예로서 이용한다. 최단 총 거리는 이러한 예들에 대해 프록시 게이트웨이(169)로부터 서비스 요소 호스트들(172)까지의 거리들의 합으로서 일반적으로 정의될 수 있다.

도 11은 도 9에 개괄된 바와 같은 제1 시나리오에 기반한 SEHS의 예시적인 메시지 흐름을 도시한다. 단계(201)에서, SEHS(171)는 표 3에 도시된 바와 같은 QoS 요구 사항을 갖는 서비스 요청을 수신할 수 있다. 단계(201)의 서비스 요청은 프록시 게이트웨이(170)로부터 온다는 것을 표시할 수 있다. 표 2에 도시된 서비스를 예로 들면, 클라이언트(170)의 주소는 클라이언트(170) 자신의 주소이고, 프록시의 주소는 클라이언트(170)에 부착된 라우터의 주소이고, serviceID는 "DeduceService1"로 설정되고, QoS 요구 사항은 최단 총 거리로 설정된다. 예로서, 단계(201)의 서비스 요청은 개별 서비스 요소들 각각에 대한 가입 요청들일 수 있다. 이 예는 본 명세서에서 설명의 목적으로 이용될 것이다.

도 11을 계속 참조하면, 단계(202)에서, SEHS(171)에 의한 컨텍스트 검색이 있다. SEHS(171)는 서비스 요소 호스트의 선택을 하기 위해 관련 컨텍스트 정보를 검색한다. SEHS(171)는 컨텍스트 제공자(174)로부터 컨텍스트 정보를 검색할 수 있다. SEHS(171)는 표 4에 도시된 바와 같은 컨텍스트 요청 메시지를 전송할 수 있다. 컨텍스트 제공자(174)는 프록시 게이트웨이(169)일 수 있다. 일 예에서, 표 4의 컨텍스트 필드는 SEHS(171)가 요청자(예를 들어, 프록시 게이트웨이(169))로부터 서비스 요소 호스트들(172)로의 거리 정보를 요청한다는 것을 표시할 수 있다. 서비스 요소 호스트들(172)의 리스트는 표 4의 필드에 포함된다. 일 예에서, 콘텐츠 제공자(174)로서의 프록시 게이트웨이(169)는 디바이스들(예를 들어, GPS)의 위치, 프록시 게이트웨이(169)의 라우팅 테이블, 및 핑(ping), 추적 루트(traceroute)와 같은 다른 툴들 중 하나 이상에 기반하여 컨텍스트 정보를 획득할 수 있다. 컨텍스트 제공자(174)는 결정된 거리를 프록시 게이트웨이(169)로부터 나열된 서비스 요소 호스트들로 리턴한다. 일 예에서, SEHS(171)는 이전 트랜잭션들로부터의 컨텍스트 정보를 캐싱할 수 있고, 이에 따라 컨텍스트 제공자(174)로부터 컨텍스트 정보를 요청하지 않을 수 있다. 검색된 컨텍스트 정보는 표 5에 도시된 바와 같을 수 있다.

계속해서 도 11을 참조하면, 단계(203)에서, SEHS(171)는 QoS 요구 사항 및 획득된 컨텍스트 정보에 기반하여 서비스 요소 호스트들의 세트를 선택할 수 있다. 표 5에 기반한 이 예에서, SEHS(171)는 서비스 "DeduceService1"의 3개의 서비스 요소 각각을 클라이언트(170)에 제공하는 서비스 요소 호스트들(172)로서 "tempSensor1", "humiditySensor2" 및 "airSensor2"를 선택하는데, 이는 이들이 클라이언트(170)로의 최단 총 거리를 갖기 때문이다. 단계(204)에서, SEHS(171)는 단계(201)의 원래 서비스 요청을 진행 중인 서비스 리스트에 둔다. 단계(205)에서, SEHS(171)는 선택된 서비스 요소 호스트들(172) 각각에 발송될 서비스 요소 요청을 클라이언트(170)에 대해 공식화한다. 단계(205)에서 생성된 서비스 요소 요청에서는, 서비스 요소 호스트들(172)이 서비스 요소를 어디로 전송할지를 알 수 있도록 클라이언트(170)의 주소가 포함될 수 있다.

도 11을 계속 참조하면, 단계(206a)에서, SEHS(171)는 클라이언트(169) 대신에 서비스 요소 요청을 선택된 서비스 요소 호스트(172)에 발송한다. SEHS(171)는 클라이언트(170)의 주소, 단계(201)의 서비스 요청으로부터의 serviceID, 및 발송된 요청 메시지 내의 서비스 요소 호스트(172)에 대한 대응하는 serviceElementID를 포함할 수 있다. SEHS(171)는 클라이언트(170)와 서비스 요소 호스트들(172) 간에 신뢰하는 공통 지점일 수 있다. 단계(206a 또는 201)의 서비스 요소 요청 메시지는 클라이언트(170)와 통신할 때 이용될 수 있는 보안 크리덴셜을 포함할 수 있다. 단계(206b)에서, SEHS(171)는 요청된 서비스에 포함된 각각의 서비스 요소에 대한 확인 및 선택된 서비스 요소 호스트(172)를 포함할 수 있는 메시지를 전송한다. 보안 키들은 서비스 요소 호스트(172)와 클라이언트(170) 간의 보안 통신을 확립하기 위해 단계(206b)의 메시지에 포함될 수 있다. 또한, SEHS(171)는 표 6에 도시된 바와 같이 동일한 서비스 및 프록시 게이트웨이에 대응하는 선택된 서비스 요소 호스트들(172)을 저장할 수 있다. 앞서 언급한 내용은 다음 상황에서 유용할 수 있다. 예를 들어, 다른 클라이언트(도시되지 않음)가 클라이언트(170)와 동일한 프록시 게이트웨이(169)를 이용하여 동일한 QoS 요구 사항을 갖는 동일한 서비스에 대한 서비스 요청을 전송하는 경우, SEHS(171)는 단계(202) 및 단계(203)를 수행할 필요가 없을 수 있다. SEHS(171)는 이미 선택된 서비스 요소 호스트들(172)을 이용하여 그러한 요청들 및 다른 연관된 메시징을 발송할 수 있다.

계속해서 도 11을 참조하면, 단계(207)에서, 프록시 게이트웨이(169)는 단계(201)와 연관된 서비스 요소(예를 들어, 서비스 요소와 연관된 데이터)를 수신한다. 단계(207)의 메시지는 서비스 요소 호스트들(172)로부터 온다는 것을 표시할 수 있다. 단계(208)에서, 프록시 게이트웨이(169)는 각각의 서비스 요소 호스트(172)로부터 수신된 메시지들을 검사하고, 임계량의 서비스 요소들이 수신되었는지 여부를 결정할 수 있다. 단계(209)에서는, 임계량의 서비스 요소들이 프록시 게이트웨이(169)에 의해 수신되었다고 결정한 후, 서비스 완료 메시지를 SEHS(171)에 전송할 수 있다. 단계(210)에서, SEHS(171)는 진행 중인 리스트로부터 그 서비스 요청을 제거할 수 있으며, 이는 단계(201)의 서비스 요청이 완료되었음을 표시한다.

도 12는 도 10에 의해 개괄된 바와 같은 제2 시나리오에 기반한 SEHS의 예시적인 메시지 흐름을 도시한다. 단계(211)에서, 서비스 호스트(173)는 QoS 요구 사항과 함께 표 3에 도시된 바와 같은 서비스 요청을 수신한다. 이 서비스 요청은 서비스 호스트(173)로부터 온다는 것을 표시할 수 있다. 단계(212)에서, 서비스 호스트(173)는 요청 메시지에서의 프록시 주소를 프록시 게이트웨이(169)로부터 자신(서비스 호스트(173))으로 리셋하고, 서비스 요소 호스트들(172)은 서비스 요소를 서비스 호스트(173)로 전송한다. 단계(213)에서, 서비스 호스트(173)는 단계(211)의 서비스 요청을 SEHS(171)로 전달한다. 단계(214 내지 218a)는 도 11의 단계(202) 내지 단계(206a)와 유사하다. 도 12의 단계(218b)는 단계(218b)에서 SEHS(171)가 확인을 서비스 호스트(173)로 전송하는 것을 제외하고는 도 11의 단계(206b)와 유사하다.

도 12를 계속 참조하면, 단계(219)에서, 서비스 호스트(173)는 단계(211)와 연관된 서비스 요소를 수신한다. 단계(220)에서, 서비스 호스트(173)는 각각의 서비스 요소 호스트(172)로부터 수신된 메시지들을 검사하고, 임계량의 서비스 요소들이 수신되었는지 여부를 결정할 수 있다. 단계(221)에서, 서비스 호스트(173)는 임계량이 수신될 때 단계(219)의 수신된 서비스 요소들로부터 완전한 서비스를 형성한다. 예를 들어, 도 6의 추론 서비스의 경우, 수신된 온도, 습도 및 CO2 데이터로부터 추론함으로써 이 서비스가 공식화된다. 단계(222a)에서, 임계량의 서비스 요소들이 서비스 호스트(173)에 의해 수신되었다고 결정한 후에, 서비스 완료 메시지를 SEHS(171)에 전송할 수 있다. 단계(222b)에서, 서비스 호스트(173)는 전체 서비스를 프록시 게이트웨이(169)로 전송한다. 단계(223)에서, SEHS(171)는 진행 중인 리스트로부터 서비스 요청을 제거한다. 이 제거는 단계(211)의 서비스 요청이 완료되었음을 표시할 수 있다. 다른 클라이언트들(도시되지 않음)은 다른 클라이언트들에 대한 프록시로서 동작하는 서비스 호스트(173)에 요청들을 전송할 수 있기 때문에, 서비스 요소 선택은 동일한 QoS 요구 사항을 갖는 서비스 요청들에 대한 주요 이벤트(예를 들어, 전력 사이클, 에러들, 임계값 초과 등)를 제외하면 단지 한 번 발생할 수 있다.

서비스 요소 호스트 재선택은 현재 선택된 서비스 요소 호스트들(172)에 의해 제공되는 서비스의 클라이언트 불만족(예를 들어, 최소 임계값을 충족시키지 못함)을 포함할 수 있는 컨텍스트 변경으로 인해 SEHS(171)에서 발생할 수 있다. 서비스 요소 호스트 재선택의 예는 이하에서 논의된다. 이 예가 도 9의 제1 시나리오와 연관되어 있지만, 서비스 요소 호스트 재선택은 도 10의 제2 시나리오와 같은 다른 시나리오들에도 적용 가능하다. 또한, 본 명세서에서 제공되는 인자들 이외에 SEHS(171)에 의해 관리될 수 있는 서비스 요소 호스트들을 재선택하도록 SEHS(171)를 트리거링할 수 있는 인자들이 있을 수 있다.

도 13은 컨텍스트의 변경에 기반한 서비스 요소 호스트 재선택의 예시적인 메시지 흐름을 도시한다. 단계(231)에서, SEHS(171)는 컨텍스트 제공자(174)에 의해 제공되는 관심있는 컨텍스트에 가입한다. SEHS(171)에서 고려할 수 있는 상이한 컨텍스트 정보가 있다. 예를 들어, SEHS(171)는 신뢰있는 QoS 요구 사항에 기반하여 서비스 요소 호스트(172)의 배터리와 연관된 정보에 가입할 수 있다. 배터리 전력에 대한 임계값이 충족되면 SEHS(171)에 통지될 수 있다. 예를 들어, 디바이스들 간의 거리와 관련하여, 도 13의 흐름을 요청하는 컨텍스트가 있을 수 있다. SEHS(171)는 프록시 게이트웨이(169)로부터 서비스 요소 호스트들(172)까지의 거리에 대한 컨텍스트 정보에 가입할 수 있다. 단계(232)에서, SEHS(171)는 컨텍스트에서의 변경을 통지하기 위한 메시지를 수신한다. 단계(232)의 메시지는 컨텍스트 제공자(174)로부터 온다는 것을 표시할 수 있다. 일 예에서, 프록시 게이트웨이(169)로부터 서비스 요소 호스트 "humiditySensor1"까지의 거리는 3이다. 표 7에 도시된 3의 거리는 7과 같은 다른 숫자로부터 감소했을 수 있다.

계속해서 도 13을 참조하면, 단계(233)에서, 3으로의 humiditySensor1 거리의 변경은 SEHS(171)를 트리거링하여 표 6에 도시된 바와 같이 선택된 서비스 요소 호스트 이력에 저장된 관련 진행 중인 서비스 또는 서비스에 대한 서비스 요소 호스트 재선택을 수행하게 한다. SEHS(171)는 새로운 서비스 요소 호스트(175)로서 "humiditySensor1"을 선택하여 서비스 요소 "service1.humidity"를 제공할 수 있다. 단계(234)에서, SEHS(171)는 서비스 요소들 중 하나를 제공하는 새롭게 선택된 서비스 요소 호스트(175)의 통지를 프록시 게이트웨이(169)로 전송한다. 단계(235)에서, 프록시 게이트웨이(169)는 현재 상태와 함께 일반 서비스 요소 호스트 전환(switch)(또는 서비스 요소 호스트(175)로의 전환의 특정 언급)에 대한 변경의 통지를 수신한 것을 확인한다. 이 상태는 프록시 게이트웨이(169)가 서비스 요소를 어떤 단계에서 수신하는지를 나타낸다. 이 예에서, 프록시 게이트웨이(169)는 특정 시구간(예를 들어, 개별 서비스 요소 각각에 가입) 동안, 예컨대 10분 동안 서비스를 수신하기를 원할 수 있다. 그 결과, 이 상태에서, 프록시 게이트웨이(169)는 서비스를 수신한 시구간, 예를 들어 4분을 알려주므로 6분이 남는다. 단계(236)에서, SEHS(171)는 현재 서비스 요소 수신 상태와 함께 서비스 요소 요청을 프록시 게이트웨이(169)로부터 새롭게 선택된 서비스 요소 호스트(175)로 전송한다.

계속해서 도 13을 참조하면, 단계(237)에서, SEHS(171)는 서비스 요소 요청 취소를 이전 서비스 요소 호스트(172)로 전송한다. 예를 들어, 서비스 요소 호스트(172)는 표 6 및 표 7에 도시된 바와 같이 "humiditySensor2"일 수 있다. 단계(238)에서, 새로운 서비스 요소 호스트(175)는 미완료된 서비스 요소를 프록시 게이트웨이(169)에 제공한다. 이 예에서, 서비스 요소 호스트(175)("humiditySensor1")는 나머지 6분 동안 습도 데이터를 프록시 게이트웨이(169)로 전송한다. 단계(239)에서, 프록시 게이트웨이(169)는 시구간 내에 (원래 선택된 호스트들 및 새롭게 선택된 호스트들의 조합일 수 있는) 서비스 요소 호스트들로부터 (예를 들어, 시구간 마다의, 양 마다의 또는 그 조합의) 임계 수의 서비스 요소들을 수신했는지 여부를 결정한다. 단계(240)에서, 임계값에 도달한 후, 프록시 게이트웨이(169)는 SEHS(171)에 서비스 완료 확인을 전송한다. 단계(241)에서, SEHS(171)는 진행 중인 리스트로부터 그 서비스 요청을 제거한다. 이 제거는 프록시 게이트웨이(169)에 의해 요청된 바와 같은 서비스의 완료를 표시할 수 있다.

도 14는 클라이언트의 불만족(예를 들어, 최소 임계값을 충족시키지 못함)에 기반한 서비스 요소 호스트 재선택의 예시적인 메시지 흐름을 도시한다. 단계(251)에서, 클라이언트(270)는 만족스럽지 않은 임계값에 도달하는 QoS에 대해 경고된다. 이 경고는 예를 들어 패킷 손실 또는 다른 오류들과 같이 가입된 트리거링 이벤트의 구성에 따라 수신될 수 있다. SEHS(171)에 대한 경고가 수신되었을 수 있다. QoS는 클라이언트가 처음 요청한 요구 사항과 다를 수 있다. 예를 들어, 클라이언트(170)는 서비스 요소 호스트(172)(예를 들어, "tempSensor1")가 일정한 시간 동안 예상한 바와 같은 온도 데이터를 전송하지 않았음을 경고 받았거나 아니면 이와 같이 결정하였을 수 있다. 그 이유는 센서가 미리 결정된 스케줄에 기반하여 슬립 모드로 전환되었거나 아니면 이용가능하지 않을 수 있기 때문이다. 단계(252)에서, SEHS(171)는 클라이언트(170)에 대한 서비스 요소 호스트를 재선택하라는 요청을 수신할 수 있다. 이 요청은 클라이언트(170)로부터 온다는 것을 표시할 수 있으며, 서비스 요소 ID를 포함할 수 있다. 단계(253)에서, 단계(252)의 요청에 기반하여, SEHS(171)는 관련 진행 중인 서비스에 대한 서비스 요소 호스트의 재선택을 수행하도록 트리거링될 수 있다. 일 예에서, SEHS(171)는 서비스 요소 호스트(175)(예를 들어, "tempSensor2")가 서비스 요소 호스트(172)(예를 들어, "tempSensor1") 대신에, 요청된 서비스 요소를 제공하도록 선택되는 변경을 행할 수 있다.

계속해서 도 14를 참조하면, 단계에서, SEHS(171)는 요청된 서비스 요소(예를 들어, 온도)에 대해 새롭게 선택된 서비스 요소 호스트(175)를 알리는 메시지를 클라이언트(170)에게 전송한다. 단계(255)에서, 클라이언트(170)는 서비스 요소를 획득하는 것에 관한 요청을 서비스 요소 호스트(175)에 전송할 수 있다. 이 요청은 SEHS(171) 대신에 클라이언트(170)로부터 직접 발송된다. 이러한 직접 요청은 본 명세서에서 논의된 몇몇 다른 예들과는 상이하며 대안적이다. 단계(256)에서, SEHS(171)는 서비스 요소 호스트(172)에 서비스의 취소를 통지하기 위해 서비스 요소 호스트(172)에 메시지를 전송한다. 서비스 요소 호스트(172)는 확인 또는 이와 유사한 메시지로 SEHS(171)에 응답할 수 있다. 단계(257) 내지 단계(260)는 도 13의 단계들과 유사하다.

클라이언트가 QoS에서 임계값 변경(예를 들어, QoS 저하)이 있다고 결정할 때, 클라이언트가 다음 후보자로 자동 전환될 수 있는 식으로, SEHS가 클라이언트의 요청에 기반하여 서비스 요소 호스트들의 복수의 후보들을 어떻게 선택할 수 있는지에 관한 방법들에 대해 이하에서 논의된다. 표 3에서의 서비스 요청 메시지는 하나 이상의 백업 후보를 갖는 옵션을 표시하도록 추가된 필드를 가질 수 있다. 도 15는 서비스 요소 호스트들의 복수의 후보들을 갖는 서비스 요청의 예시적인 메시지 흐름을 도시한다. 단계(271) 및 단계(272)는 도 11의 단계(201) 및 단계(202)와 유사하다. 단계(273)에서, SEHS(171)는 QoS 요구 사항, 컨텍스트 정보 등에 기반하여 복수의 후보 그룹들을 선택할 수 있다. 일 예에서, SEHS(171)는 제1 후보로서 "tempSensor1", "humiditySensor2", "airSensor2", 제2 후보로서 "tempSensor1", "humiditySensor2", "airSensor3", 제3 후보로서 "tempSensor2", "humiditySensor2", "airSensor2" 등을 선택할 수 있다. 단계(274)에서, SEHS는 진행 중인 서비스 리스트에 원래 서비스 요청을 넣을 수 있다. 단계(275)에서, SEHS(171)는 서비스 요소에 대한 요청을 생성하라는 명령어를 제공한다. 단계(276a)에서, 서비스 요소에 대한 요청은 서비스 요소(예를 들어, 온도, 습도, CO2에 관한 데이터)를 수집하기 위한 서비스 요소 호스트로서의 선택을 위해 복수의 후보들 중 제1 후보일 수 있는 서비스 요소 호스트(172)에 발송될 수 있다. 단계(276b)에서, SEHS(171)는 클라이언트(170)에 메시지를 전송한다. 이 메시지는 서비스 요소 호스트(172)가 선택되었다는 확인을 포함할 수 있다. 이 메시지는 또한 서비스 요소 호스트들의 복수의 후보 그룹들의 리스트를 포함할 수 있다.

계속해서 도 15를 참조하면, 단계(277) 내지 단계(278)은 도 11의 단계(207) 및 단계(208)와 유사하다. 단계(279)는 도 14의 단계(251)와 유사하다. 단계(280)에서, 클라이언트(270)는 서비스 요소 "service1.temperature"를 제공하기 위한 서비스 요소 호스트로서 다른 후보(예를 들어, 제3 후보 - tempSensor2)로의 전환과 연관된 메시지들을 전송한다. 단계(280)의 메시지는 온도(예를 들어, tempSensor1)와 연관된 서비스 요소에 관하여 서비스 요소 호스트(172)에 대한 취소 메시지일 수 있다. 단계(281) 내지 단계(285)는 각각 도 14의 단계(256) 내지 단계(260)와 유사하다.

이하의 논의에서는 특히 서비스 요청시 서비스 요소들의 시퀀스를 고려한다. 즉, 서비스의 서비스 요소들은 완전한 서비스를 얻기 위해 클라이언트에 의해 수신되어야 하는 미리 결정된 순서를 가질 수 있다. 이하에서 논의되는 것은 서비스 요소들이 요청 클라이언트에 특정 순서로 도달하도록 요청하는 두 가지 예시적인 시나리오이다. 처리 순서(예를 들어, 순서를 벗어나 도달하지만, 특정 순서로 처리하는 것)에 관한 고려 사항들도 본 명세서에서 고려되지만, 이하에서 바로 언급되지는 않는다.

표 8 및 도 16에 도시된 바와 같이, 서비스 요소들의 시퀀스에 관한 제1 시나리오에서, 서비스 S1은 2개의 서비스 요소, 즉 A 및 B를 갖는다. 서비스 요소 A는 디바이스 1, 디바이스 4 및 디바이스 6으로 표지된 3개의 서비스 요소 호스트를 갖는다. 이 3개의 서비스 요소 호스트의 응답 시간들은 각각 11초, 5초 및 1초이다. 서비스 요소 B는 하나의 서비스 요소 호스트(디바이스 8)를 가지며, 그 응답 시간은 10초마다 변하고 20초 또는 1초 중 어느 하나이다. 이 예에서, 응답 시간은 서비스 요소 요청이 들어오고, 서비스 요소 A가 서비스 요소 B 이전에 제공되어야 하는 순간에 결정된다. 최소 총 응답 시간의 QoS 요구 사항을 갖는 요청이 SEHS(171)에 의해 수신될 수 있다.

서비스 요소들의 시퀀스에 관한 제1 시나리오를 계속 고려하면, 서비스 요소들의 시퀀스가 고려되지 않았다면, SEHS(171)는 디바이스 6이 다른 서비스 요소 호스트들 중에서 최단 응답 시간을 가지므로 디바이스 6을 선택하여 서비스 요소 A를 전달할 것이다. 또한, 서비스 요소 B를 제공하는 서비스 요소 호스트가 하나뿐이기 때문에, 디바이스 8이 대안없이 선택된다. 도 16에 도시된 바와 같이, 블록(291)(그 응답 시간이 20초인 경우)에서 디바이스 8의 비효율적인 구간 내에 요청이 오면, 서비스 요소 B의 응답 시간은 20초이다. 따라서, 디바이스 6이 선택되면, 서비스의 총 응답 시간은 max(1, 20) = 20초가 될 것이다. 그러나, 이 예시적인 제1 시나리오에서, 서비스 요소 A는 서비스 요소 B 이전에 요청 클라이언트(170)에 도달할 필요가 있다. 동일한 디바이스들(디바이스 6 및 디바이스 8)이 선택되면, 서비스의 총 응답 시간은 1 + 20 = 21초가 될 것이다.

서비스 요소들의 시퀀스에 관한 제1 시나리오를 계속 고려하면, 서비스 요소들의 시퀀스가 고려될 때, 디바이스 6 및 디바이스 8을 선택하는 것은 서비스 요소 호스트들의 가장 효율적인 조합이 아니다. 보다 효율적인 해결책은 SEHS(171)가 먼저 서비스 요소 A를 제공하기 위해 디바이스 1을 선택하는 것일 수 있다. 클라이언트(170)가 서비스 요소 A를 수신한 후, 서비스 요소 B에 대한 요청이 그 후에 디바이스 8에 발송된다. 그 시점에, 디바이스 8은 이미 효율적인 구간(1초)으로 전환되며, 총 응답 시간은 11 + 1 = 12초이다.

표 9 및 도 17에 도시된 바와 같이, 서비스 요소들의 시퀀스에 관한 제2 시나리오에서, 서비스 S2는 2개의 서비스 요소, 즉 C 및 D를 갖는다. 서비스 요소 C는 디바이스 2 및 디바이스 5로 표지된 2개의 서비스 요소 호스트를 갖는다. 이 2개의 서비스 요소 호스트의 응답 시간은 각각 10초 및 1초이다. 서비스 요소 D는 디바이스 6 및 디바이스 9로 표지된 2개의 서비스 요소 호스트를 갖는다. 2개의 서비스 요소 호스트의 응답 시간은 20초 및 1초이지만, 이들은 온라인/오프라인 스케줄들 또는 슬리핑 스케줄들을 갖는다. 이 시나리오에서, 최소 총 응답 시간의 QoS 요구 사항을 갖는 요청이 SEHS(171)에 의해 수신된다. 또한, 서비스 요소 C가 서비스 요소 D 이전에 요청 클라이언트(170)에 도달해야 하는 것이 필요하다.

서비스 요소들의 시퀀스에 관한 제2 시나리오를 계속 참조하면, SEHS(171)가 서비스 요소 A를 제공하기 위해 디바이스 5를 선택하면, 1초 후, 디바이스 6은 온라인이 되지만, 디바이스 9는 오프라인이 된다. 2개의 서비스 요소의 시퀀스를 고려할 때, 서비스의 총 응답 시간은 1 + 20 = 21초가 될 것이다. 디바이스 2가 서비스 요소 C를 제공하도록 허용하는 것과 같이 SEHS(171)에 의해 보다 효율적인 선택이 내려질 수 있다. 디바이스 2가 서비스 요소 C의 제공을 완료한 다음의 10초 후에 디바이스 9는 온라인이다. SEHS(171)는 서비스 요소 D를 제공하기 위해 디바이스 9를 선택하는 옵션을 갖는다. 이에 따라, 그 서비스의 총 응답 시간은 10 + 1 = 11초가 될 것이다.

도 18은 SEHS가 CSE에서 oneM2M SEHS CSF(294)로서 호스팅될 수 있는 예시적인 도면이다. oneM2M은 oneM2M 서비스 계층에 의해 지원되는 능력들을 정의한다. oneM2M 서비스 계층은 CSF(capability service functions)의 세트를 포함하는 CSE(capability services entity)로서 인스턴스화된다.

애플리케이션 엔티티(AE) 또는 CSE일 수 있는 클라이언트들(170)은 Mca 또는 Mcc 기준점을 통해 oneM2M SEHS CSF(294)와 통신하여 서비스들을 요청할 수 있다. oneM2M SEHS CSF(294)는 Mcn 기준점을 통해 하위 네트워크 서비스 엔티티들과 통신하여 관련 컨텍스트 정보를 검색할 수 있다. oneM2M SEHS CSF(294)는 각각의 서비스 요소 호스트(172)와 통신하여 Mca, Mcc/Mcc' 기준점을 통해 서비스 요청들을 발송할 수 있다.

도 19는 oneM2M RoA에 대한 서비스 요청의 예시적인 도면이다. 이 예에서, 서비스 호스트는 MN-CSE이다. 클라이언트인 AE(301)는 IN-CSE(302)에서의 SEHS CSF에 서비스 요청을 전송한다. 컨텍스트 제공자는 NSE(303)일 수 있다. IN-CSE(302)에서의 SEHS는 NSE(303)에 가입할 수 있고, NSE(303)로부터 컨텍스트 정보의 통지(또는 검색)를 얻을 수 있다. IN-CSE(302)는 서비스 요소 호스트인 ASN-CSE(304)로의 서비스 요소 요청들 및 응답들을 전송 및 수신할 수 있다.

본 명세서에서 논의된 바와 같은 메시지들에 기반하여, IN-CSE(302)는 정의 된 절차들, 즉 serviceRequest에 대한 RESTful 인터페이스를 제공하기 위해 그 리소스 구조에서 후속 리소스를 유지할 수 있다. 도 20은 <serviceRequest>의 리소스 트리 구조의 예시적인 도면이다. 표 10 및 표 11은 <serviceRequest> 리소스의 자식 리소스 및 속성들을 보여준다. 이러한 일반적인 속성들은 oneM2M-TS-0001 oneM2M Functional Architecture-V-1.6.1(이하, [1])에서 찾을 수 있다.

도 21은 oneM2M에서의 서비스 요청의 예시적인 메시지 흐름을 도시한다. 도 21의 메시지 흐름은 이전에 논의된 메시지 흐름들보다 더 간략화된다. 단계(311)에서, AE(301)(예를 들어, 클라이언트(170))는 <serviceRequest>를 생성하여 IN-CSE(302)(예를 들어, SEHS(171))에 서비스 요청을 전송한다. 단계(312)에서, IN-CSE(302)는 QoS 요구 사항에 기반하여 ASN-CSE(304)(예를 들어, 서비스 요소 호스트들(172))를 선택한다. 단계(313)에서, IN-CSE(302)는 <serviceRequest>를 ASN-CSE(304)에 전달한다. 단계(314)에서, ASN-CSE(304)는 AE(301)에 서비스 요소 응답을 전송한다.

도 22는 oneM2M 서비스 구성요소 아키텍처(SOA)에서의 예시적인 SEHS를 도시한다. AE(321) 또는 원격 서비스 노출 구성요소들(322)과 같은 형태들에서의 서비스 제공자들은 Mca 기준점(331) 또는 Msc 기준점(332)을 통해 서비스 요소 호스트 선택 서비스 구성요소(323)(예를 들어, SEHS(171))와 대화하여 서비스 요소들 및 그 대응하는 서비스 요소 호스트들(예를 들면, 서비스 요소 호스트들(172))을 보고 및 갱신할 수 있다. AE(321) 또는 원격 서비스 노출 구성요소(322)와 같은 형태들에서의 클라이언트들(예컨대, 클라이언트(170))은 Mca 기준점(331) 또는 Msc 기준점(332)을 통해 서비스 요소 호스트 선택 서비스 구성요소(323)와 통신하여 서비스들을 요청할 수 있다. 서비스 요소 호스트 선택 서비스 구성요소(323)는 네트워크 서비스 이용 구성요소(324)(예를 들어, 컨텍스트 제공자(174))를 통해 Msc 기준점(332)을 경유해 하위 네트워크 서비스 엔티티들과 통신하여 관련 컨텍스트 정보를 검색할 것이다. 서비스 요소 호스트 선택 서비스 구성요소(323)는 각각의 서비스 요소 호스트와 통신하여 Mca 기준점(331) 또는 Msc 기준점(332)을 통해 서비스 요청들을 발송할 수 있다.

도 23은 본 명세서에서 논의된 방법들 및 시스템들에 기반하여 생성될 수 있는 예시적인 디스플레이(예컨대, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(341)(예를 들어, 터치 스크린 디스플레이)는 표 2 내지 표 11의 파라미터들과 같은 서비스 요소 호스트 선택과 연관된 텍스트를 블록(342)에서 제공할 수 있다. 다른 예에서는, 본 명세서에서 논의된 단계들 중 임의의 단계의 진행(예를 들어, 도 9 내지 도 15에서의 전송된 메시지들 또는 단계들의 성공)이 블록(342)에서 표시될 수 있다. 또한, 그래픽 출력(343)은 디스플레이 인터페이스(341) 상에 표시될 수 있다. 그래픽 출력(343)은, 서비스 요소 호스트들(172) 또는 다른 서비스 요소 연관 디바이스들의 토폴로지 또는 그래픽 매핑(예를 들어, 도 6 및 도 7), 본 명세서에서 논의된 임의의 방법 또는 시스템들의 진행의 그래픽 출력 등일 수 있다.

도 24a는 특히 도 6 또는 도 7과 같이 서비스 요소들에 대한 시스템들 및 방법들과 연관된 하나 이상의 개시된 개념이 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 계층 등의 구성요소일 수 있다.

도 24a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크(예를 들어, 이더넷, 파이버, 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), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 24a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함한다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점을 이해할 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 전송 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비-셀룰러)뿐만 아니라 고정형 네트워크 M2M 디바이스들(예를 들어, PLC)이 통신 네트워크(12) 또는 직접 무선 링크와 같은 오퍼레이터 네트워크들을 통해 통신하게 한다. 예를 들어, M2M 디바이스들(18)은 데이터를 수집하고, 그 데이터를 통신 네트워크(12) 또는 직접 무선 링크를 통해 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 전송될 수 있고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 배선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 24b를 참조하면, 필드 도메인에서의 도시된 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 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인에서의 M2M 애플리케이션(20') 및 하위 통신 네트워크(12')에 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인에서의 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)에 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들과 통신할 수 있다는 점을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의한 서비스 계층과 상호 작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버, 컴퓨터들, 가상 머신들(예를 들어, 클라우드/컴퓨팅/스토리지 팜들, 기타 등등) 등에 의해 구현될 수 있다.

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

몇몇 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에서 논의된 바와 같이 서비스 요소들을 이용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아닌, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 전술한 바와 같이, M2M 서비스 계층, 디바이스들에 걸쳐 실행하는 것, 게이트웨이들, 및 시스템의 다른 서버들은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

본 발명의 서비스 요소 호스트 선택은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가 가치의 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. 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라고 지칭되며, 이는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 또한, 본 발명의 서비스 요소 호스트 선택은 서비스 지향 아키텍처(SOA) 또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현되어, 본 발명의 서비스 요소 호스트 선택과 같은 서비스들에 액세스할 수 있다.

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

도 24c는 예를 들어 M2M 단말 디바이스(18)(예컨대, 클라이언트(170)) 또는 M2M 게이트웨이 디바이스(14)(예컨대, SEHS(171))와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 24c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 트랜시버(34), 전송/수신 엘리먼트(element)(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시되는 주제와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 서브-조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, 프록시 게이트웨이(169), 클라이언트(170), 컨텍스트 제공자(174), 서비스 요소 호스트(172), SEHS(171) 및 다른 디바이스들)는 서비스 요소들에 대한 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

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

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

또한, 전송/수신 엘리먼트(36)가 단일 엘리먼트로서 도 24c에 묘사되지만, 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)는 본 명세서에서 설명된 일부 예들에서 서비스 요소 호스트 선택이 성공인지 실패인지(예를 들어, 서비스 요청들, 컨텍스트 검색 또는 컨텍스트 통지 등)에 응답하여 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들 또는 색상들을 제어하거나, 이와 달리 서비스 요소들 및 연관된 구성요소들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시자들(42) 상의 제어 조명 패턴들, 이미지들 또는 색상들은 방법 흐름들 중 임의의 흐름, 또는 본 명세서에서 도시되거나 논의된 표들 또는 도면들(예를 들어, 도 6, 도 7, 도 11 내지 도 15, 도 21 등)에서의 구성요소들의 상태를 반영할 수 있다. 서비스 요소들의 메시지들 및 절차들이 본 명세서에 개시되어 있다. 메시지들 및 절차들은 사용자들이 입력 소스(예로서, 스피커/마이크로폰(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 리소스 관련 리소스들을 요청하거나, 특히 디스플레이(42) 상에 표시될 수 있는 서비스 요소 연관 정보를 요청, 구성 또는 질의하게 하기 위한 인터페이스/API를 제공하도록 확장될 수 있다.

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

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

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

전송/수신 엘리먼트들(36)은, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기와 같은 차량 등의 다른 장치들 또는 디바이스들에 구현될 수 있다. 전송/수신 엘리먼트들(36)은, 주변 기기들(52) 중 하나를 포함할 수 있는 상호 접속 인터페이스와 같은 하나 이상의 상호 접속 인터페이스를 통해 이러한 장치들 또는 디바이스들의 다른 구성요소들, 모듈들 또는 시스템들에 접속될 수 있다.

도 24d는 예를 들어 도 24a 및 도 24b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예로서, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고 소프트웨어가 어디서든, 또는 무슨 수단에 의하든 저장되거나 액세스되는 그러한 소프트웨어의 형태일 수 있는 컴퓨터 판독가능 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(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(82) 및 ROM(93)을 포함한다. 이러한 메모리들은 정보가 저장되고 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 변경될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독되거나 또는 변경될 수 있다. RAM(82) 또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 주소들을 물리적 주소들로 변환하는 주소 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 사용자 처리들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 처리 가상 주소 공간에 의해 매핑되는 메모리만 액세스할 수 있고, 이것은 처리들 사이에 메모리 공유가 설정되지 않았다면 다른 처리의 가상 주소 공간 내의 메모리에 액세스할 수 없다.

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

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

또한, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)을 도 24a 및 도 24b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

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

본 명세서에 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어 또는, 적절한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 존재할 수 있다. 이러한 장치는 본 명세서에서 설명된 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 이용되는 바와 같이, 용어들 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 상호 교환 가능하게 이용될 수 있다.

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

특히 본 명세서에서 설명된 바와 같은 방법들, 시스템들 및 장치들은 서비스 호스트 선택 등을 위한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독가능 저장 매체 또는 장치는 서비스에 대한 요청 및 서비스 품질 요구 사항을 포함하는 메시지를 수신하고, 이러한 메시지에 기반하여 서비스 요소 호스트를 결정하며, 그 요청을 서비스 요소 호스트에 전달하기 위한 수단을 갖는다. 이러한 메시지는 서비스의 식별자를 포함할 수 있다. 메시지는 서비스 호스트로부터 온다는 것을 표시할 수 있다. 메시지는 서비스가 구성되는 서비스 요소들의 수를 포함할 수 있다. 메시지는 각각의 서비스 요소에 대한 복수의 서비스 요소 호스트들의 표시자를 포함할 수 있다. 메시지는 제1 서비스에 대한 제1 서비스 요소를 처리하는 시퀀스의 표시자를 포함할 수 있다. 제1 서비스 요소는 온도 데이터일 수 있다. (단계들의 제거 또는 추가를 포함하는) 이 단락의 모든 조합들은 본 상세한 설명의 다른 부분들과 일관되는 방식으로 고려된다.

Claims (20)

1. 장치로서,
   프로세서; 및
   상기 프로세서와 결합된 메모리를 포함하며,
   상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금
   서비스에 대한 요청 및 서비스 품질 요구 사항(requirement)을 포함하는 메시지를 수신하는 것,
   상기 메시지에 기반하여 서비스 요소 호스트를 결정하는 것, 및
   상기 요청을 상기 서비스 요소 호스트에 전달하는 것을 포함하는 동작들을 실행시키는 실행가능한 명령어들을 포함하는 장치.
2. 제1항에 있어서,
   상기 메시지는 서비스의 식별자를 포함하는 장치.
3. 제1항에 있어서,
   상기 메시지는 서비스 호스트로부터 온다는 것을 표시하는 장치.
4. 제1항에 있어서,
   상기 메시지는 서비스가 구성되는 서비스 요소들의 수(number)를 포함하는 장치.
5. 제1항에 있어서,
   상기 메시지는 각각의 서비스 요소에 대한 복수의 서비스 요소 호스트들의 표시자를 포함하는 장치.
6. 제1항에 있어서,
   상기 메시지는 제1 서비스에 대한 제1 서비스 요소를 처리하는 시퀀스의 표시자를 포함하는 장치.
7. 제1항에 있어서,
   제1 서비스 요소는 온도 데이터인 장치.
8. 시스템으로서,
   디스플레이; 및
   상기 디스플레이와 통신 접속된 디바이스를 포함하며,
   상기 디바이스는,
   프로세서와,
   상기 프로세서와 결합된 메모리를 포함하며,
   상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금
   서비스에 대한 요청을 포함하는 메시지를 수신하는 것,
   상기 메시지에 기반하여 서비스 요소 호스트를 결정하는 것,
   상기 요청을 상기 서비스 요소 호스트에 전달하는 것, 및
   상기 서비스 요소 호스트를 포함하는 기록을 상기 디스플레이에 게시(publish)하는 것을 포함하는 동작들을 실행시키는 실행가능한 명령어들을 포함하는 시스템.
9. 제8항에 있어서,
   상기 메시지는 서비스의 식별자를 포함하는 시스템.
10. 제8항에 있어서,
    상기 메시지는 서비스 호스트로부터 온다는 것을 표시하는 시스템.
11. 제8항에 있어서,
    상기 메시지는 서비스가 구성되는 서비스 요소들의 수를 포함하는 시스템.
12. 제8항에 있어서,
    상기 메시지는 각각의 서비스 요소에 대한 복수의 서비스 요소 호스트들의 표시자를 포함하는 시스템.
13. 제8항에 있어서,
    상기 메시지는 제1 서비스에 대한 제1 서비스 요소를 처리하는 시퀀스의 표시자를 포함하는 시스템.
14. 제8항에 있어서,
    상기 동작들은 지리 영역의 그래픽 표현 - 상기 그래픽 표현은 상기 서비스 요소 호스트의 위치를 표시하는 표시자들을 포함함 - 을 제공하는 것을 더 포함하는 시스템.
15. 제8항에 있어서,
    상기 동작들은 그래픽 표현 - 상기 그래픽 표현은 서비스 요소 요청의 수신 확인을 표시하는 표시자들을 포함함 - 을 제공하는 것을 더 포함하는 시스템.
16. 서비스에 대한 요청을 포함하는 메시지를 수신하는 단계;
    상기 메시지에 기반하여 서비스 요소 호스트를 결정하는 단계; 및
    상기 요청을 상기 서비스 요소 호스트에 전달하는 단계
    를 포함하는 방법.
17. 제16항에 있어서,
    상기 메시지는 서비스의 식별자를 포함하는 방법.
18. 제16항에 있어서,
    상기 메시지는 서비스 호스트로부터 온다는 것을 표시하는 방법.
19. 제16항에 있어서,
    상기 메시지는 서비스가 구성되는 서비스 요소들의 수를 포함하는 방법.
20. 제16항에 있어서,
    상기 메시지는 각각의 서비스 요소에 대한 복수의 서비스 요소 호스트들의 표시자를 포함하는 방법.
    
    
    
    
    
    
    

Images