KR101880456B1

KR101880456B1 - 자원 시멘틱의 인에이블링

Info

Publication number: KR101880456B1
Application number: KR1020167024190A
Authority: KR
Inventors: 리쥔 둥; 윌리엄 로버트 4세 플린; 데일 앤 시드; 폴 엘. 주니어 러셀
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2014-02-07
Filing date: 2015-02-03
Publication date: 2018-07-23
Also published as: US11238073B2; EP3103270B1; WO2015119901A1; EP3103270A1; WO2015119901A8; CN106165455A; JP2017514321A; US20220107970A1; JP6370915B2; JP2018196126A; KR20180085054A; US20150227618A1; US11741138B2; KR20160117554A; CN106165455B

Abstract

기기간 시스템들에서 시멘틱 지원을 제공하는 시멘틱 노드 기능을 위한 방법 및 시스템이 개시된다. 일 예에서, 시멘틱 노드는 다른 장치들에 의해 탐색, 검색, 또는 검증될 수 있는 시멘틱 자원들을 관리할 수 있다. 다른 예에서, 시멘틱 노드는 다른 노드들에 의해 탐색될 수 있고, 시멘틱 자원들은 가입 메커니즘으로 탐색될 수 있다.

Description

자원 시멘틱의 인에이블링{ENABLING RESOURCE SEMANTICS}

관련 출원에 대한 상호 참조

본 출원은 2014년 2월 7일자로 출원되었으며, 명칭이 "ENABLE RESOURCE SEMANTICS IN M2M SYSTEMS"인 미국 가특허출원 제61/937,209호의 이익을 주장하는, 2015년 1월 28일자로 출원되었으며, 명칭이 ENABLING RESOURCE SEMANTICS인 미국 특허 출원 제14/607,648호에 관한 것으로, 그 내용은 본 명세서에서 참고로서 포함된다.

물리적 환경에 배치된 네트워크 기반 장치 및 센서의 급속한 수적인 증가는 통신 네트워크를 변화시키고 있다. 향후 10년 내에 수십억의 장치가 스마트 그리드, 스마트 홈, e-헬스, 자동차, 운송, 물류, 및 환경 모니터링과 같은 다양한 분야에서 서비스 제공자에 의한 많은 애플리케이션 및 서비스를 위해 수많은 실세계 데이터를 생성할 것이라고 예측된다. 실세계 데이터 및 서비스를 현재의 정보 네트워킹 기술에 통합하는 것을 가능하게 하는 관련 기술 및 솔루션은 종종 사물 인터넷(IoT; Internet of things) 또는 기기간(M2M; machine-to-machine) 통신이라는 포괄적 용어 하에서 기술된다. 장치들에 의해 생성되는 많은 양의 데이터로 인해, 이러한 데이터를 식별 및 쿼리하기 위한 효율적인 방식이 필요하다.

도 1은 통합 포인트로서 액추에이터를 이용하는 콤팩트 생의학 무선 센서 모트(compact biomedical wireless sensor motes)를 이용하여 환자의 병원 또는 재활 센터에 의해 제공될 수 있는 일례의 환자 모니터링 애플리케이션을 예시한다. 액추에이터는 데이터를 네트워크로 전송한다. 자원이 제한된 이러한 소형 웨어러블 장치는 특히 혈압 및 혈류, 심부 체온(core temperature), 산소 포화도, 모션(motion), 심박수, 청력, 및 시력과 같은 생체 신호를 지속적으로 모니터하기 위해 환자에 배치될 수 있는 M2M 장치의 예이다. M2M 장치에 의해 수집된 다양한 종류의 M2M 데이터는 도 1에 도시된 바와 같이 환자의 의사, (예를 들어, 24시간 피트니스에서) 개인 트레이너, 및/또는 앰뷸런스 서비스에 의해 사용될 수 있다. 의사, 개인 트레이너, 및 앰뷸런스 서비스가 그 M2M 장치로부터 생성된 데이터를 이용 가능하게 하기 위해서는, 그 자원의 시멘틱(semantics)도 이용가능 할 필요가 있다. 시멘틱은 데이터의 포맷 및 구조를 이해할 수 있도록 데이터의 기술적인 정의를 제공한다(즉, 시멘틱은 데이터의 의미를 제공한다).

그러나, 드래프트 ETSI TS 102 690 및 TS 102 921에 기술된 ETSI M2M 아키텍처와 같은 현재의 M2M 시스템은 시멘틱을 지원하는 메커니즘을 정의하지 않는다(예를 들어, ETSI M2M 정의 컨테이너 자원 내에 저장된 데이터는 그와 함께 저장될 수 있는 어떠한 시멘틱 정보도 갖지 않는다). 그 결과, 장치 및 애플리케이션은 포함된 데이터뿐만 아니라 교환된 컨테이너의 일반적인 정의에 미리 동의할 필요가 있다. 이것은 현재의 M2M 시스템에서 서로 다른 애플리케이션에 걸쳐 M2M 데이터의 재사용을 어렵게 만든다.

시멘틱 개념은 시멘틱 웹의 분야에 일반적으로 알려져 있으며, 이는 월드 와이드 웹 콘소시엄(W3C)으로 알려진 국제 표준 단체에 의해 유도된 협력 운동이다. 표준은 월드 와이드 웹 상에서 일반 데이터 포맷들을 증진한다. 웹 페이지들 내의 시멘틱 콘텐츠의 포함을 장려함으로써, 시멘틱 웹은 구조화되지 않은 및 절반 구조화된 문서들에 의해 지배되는 현재의 웹을 "데이터의 웹"으로 변환하는 것을 목표로 한다. 시멘틱 웹 스택은 W3C의 자원 설명 프레임워크(RDF)를 만들어 낸다.

개발하에 있는 oneM2M 표준은 도 2b에 도시된 바와 같이 CSE(Common Service Entity)"라고 지칭되는 서비스 계층을 정의한다. 서비스 계층의 목적은 상이한 '수직' M2M 사일로 시스템과 e-건강, 차량군 관리, 및 스마트 홈과 같은 애플리케이션에 의해 이용될 수 있는 "수평" 서비스를 제공하는 것이다. CSE는 도 2a에 도시된 바와 같이 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 연결된다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인내의 다른 CSE와 연결되고 Mcc' 참조 포인트는 상이한 서비스 제공자 도메인내의 다른 CSE와 연결된다. Mcn 참조 포인트는 기본적 네트워크 서비스 엔티티(NSE)와 연결된다. NSE는 장치 관리, 위치 서비스 및 장치 트리거링과 같은, 기본적인 네트워크 서비스를 CSE에게 제공한다. CSE는 도 2b에서의 발견(701) 및 데이터 관리 및 저장소(702)와 같은, "CSF(Common Service Function)들"로 지칭되는 다중 논리 함수를 포함한다. 도 2b는 oneM2M에서 개발하에 있는 CSF들을 예시한다.

oneM2M 전에, ETSI M2M은 ETSI TS 102 690 기기간 통신(M2M) 기능적 아키텍처 V2.1.1에 정의되어 있는 바와 같은, 그 자신의 서비스 계층 배향 M2M 표준을 발표했다. oneM2M의 아키텍처는 ETSI M2M 아키텍처와 유사하다. ETSI M2M은 서비스 기능으로 지칭되는 다양한 서비스 모듈로 구성되는 서비스 기능 계층 엔티티를 정의했다.

추가 배경으로, http://www.w3.org/TR/rdf-concepts/에 기술되는 자원 기술 프레임워크(RDF; Resource Description Framework)는 웹에서 정보를 표현하기 위한 프레임워크이다. RDF는 근본적으로 데이터-모델이다. 그의 기본적인 빌딩 블록은 스테이트먼트로 지칭되는 삼종 자원-속성-값(resource-property-value triple)이다. RDF에는 XML의 구문이 주어졌다.

RDF는 자원, 속성, 값, 및 스테이트먼트의 개념을 포함한다. 자원은 객체 또는 "사물"로 간주될 수 있다. 자원은 저자, 책, 출판사, 장소, 사람, 호텔, 객실, 및 검색 쿼리 등일 수 있다. 자원은 범용 자원 식별자(URI)를 갖는다. URI는 통합 자원 로케이터(URL), 웹 주소, 또는 어떤 다른 종류의 고유 식별자일 수 있다. 이러한 식별자는 반드시 자원에 액세스 가능한 것은 아니다. URI 방식은 웹 위치뿐만 아니라, 전화번호, ISBN 번호, 및 지리적 위치와 같은 다양한 객체에 대해 정의되었다. 속성은 특별한 종류의 자원이 고려되고, 자원들, 예를 들어 "지은이", "나이", 및 "제목" 등 간의 관계를 기술할 수 있다. RDF에서 속성들은 역시 URI들에 의해 식별된다.

값은 자원 또는 문자일 수 있다. 문자는 원자값(문자열)이다. 예를 들어, "나이"라는 속성을 갖는 자원은 "20"이라는 문자값을 가질 수 있다. 스테이트먼트는 자원의 속성을 나타낸다. 스테이트먼트는 자원, 속성, 및 값으로 이루어진 삼중 자원-속성-값이다. RDF에서 기본적인 표현 구조는 각각이 자원, 속성, 및 값으로 이루어진 삼중 집합이다. 각각의 삼중은 링크되는 노드들로 나타낸 사물들 간의 관계에 대한 스테이트먼트를 표현한다.

RDF는 도메인에 독립적인 것으로, 여기서는 특정한 사용 도메인에 대해 임의의 가정도 이루어지지 않는다. 이것은 사용자가 이들 자신의 용어를 RDF 스키마(RDFS; RDF Schema)로 불리는 스키마 언어로 정의하는 것에 달려 있다. RDFS는 RDF 데이터 모델에 사용되는 어휘를 정의한다. RDFS에서 어휘를 정의하고, 어느 속성이 어떤 종류의 객체에 적용되는지 및 이들이 취할 수 있는 값을 지정하고, 객체들 간의 관계를 기술할 수 있다.

W3C에 의해 정의되는 코어 클래스는

o rdfs:Resource, 모든 자원의 클래스

o rdfs:Class, 모든 클래스의 클래스. 클래스에 속하는 개인들의 그룹은 동일한 속성을 공유한다.

o rdfs:Literal, 모든 문자(문자열)의 클래스

o rdf:Property, 모든 속성의 클래스.

o rdf:Statement, 모든 정의되는 스테이트먼트의 클래스

W3C에 의해 정의되는 코어 속성은

o rdf:type, 이것은 그것의 클래스와 자원을 관련시킨다. 자원은 그 클래스의 인스턴스인 것으로 선언된다.

o rdfs:subClassOf, 이것은 그것의 상위 클래스들(super-classes) 중 하나와 클래스를 관련시킨다. 클래스의 인스턴스는 그것의 상위 클래스의 인스턴스이다.

o rdfs:subPropertyOf, 속성을 그의 상위 속성들(super-properties) 중 하나와 관련시키는 것.

o rdfs:domain, 이것은 속성 P의 도메인, 또는 그 삼중에서 그 속성의 지정된 제목을 지정하는 것이다.

o rdfs:range, 이것은 속성 P의 범위를 지정하는 것이다. 그 자원들의 클래스는 술어(predicate) P를 갖는 삼중에서의 값으로서 나타날 수 있다.

M2M 시스템과 RDF 및 RDFS를 배경으로 한 전술한 논의에 따라, 본 출원은 M2M 시스템에서의 시멘틱 지원 및 관리를 위한 시스템 및 방법에 관한 것이다.

<발명의 요약>

기기 간(M2M) 시스템에서 시멘틱 지원을 제공하는 시멘틱 노드 기능을 위한 방법, 장치, 시스템이 본 명세서에 개시된다. 시멘틱 노드를 가진 M2M 아키텍처는 시멘틱 노드의 아키텍처와 마찬가지로 제안된다. 본 개시는 특히, 시멘틱 노드 참조 포인트들(sIs, sIe, sIc), 시멘틱 노드 절차, 및 시멘틱 노드 메시지를 정의한다.

게다가, 복잡한 데이터 유형에 관한 문제는 시멘틱 관련 자원과 자원들을 링크 및 연관시킴으로써 자원들에 시멘틱을 가능하게 하는 방법과 시멘틱 관련 자원의 구조 및 표현에 의해 본 명세서에서 논의될 수 있다. 다른 양태에서, 본 문제는 복잡한 데이터 유형의 필드가 추출되고 해석될 수 있도록, 제한/양상 유닛 및 설명을 가진 XSD의 확장을 가능하게 하는 메커니즘을 통해 논의될 수 있다. 또 다른 양태에서, 본 문제는 각각에 대한 값이 적절하게 수치화될 수 있도록 발견할 수 있게 하고 또한 해석할 수 있게 하는 데이터형의 키워드와 데이터형의 각각의 필드의 유닛과 같은, 설명/속성들을 복잡한 데이터형의 필드 및 데이터형의 명칭으로 내장시킴으로써 논의될 수 있다.

본 요약은 이하의 상세한 설명에서 더 기술되는 개념 중에서 선택된 것을 간략화된 형태로 소개하기 위해 제공된다. 본 요약은 청구 대상의 주요 특징이나 본질적인 특징을 식별하도록 의도된 것은 아니며, 청구 대상의 범주를 제한하려고 사용된 것도 아니다. 또한, 청구 대상은 본 개시내용의 모든 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한사항으로 한정되지 않는다.

첨부 도면들과 관련하여 예시적으로 제공되는 아래의 설명으로부터 더 상세한 이해를 얻을 수 있으며, 여기서:
도 1은 환자 모니터링 애플리케이션을 예시하고;
도 2a는 oneM2M 아키텍처를 예시하고;
도 2b는 oneM2M 상용 서비스 기능을 예시하고;
도 3은 시멘틱 노드를 갖는 M2M 아키텍처를 예시하고;
도 4는 M2M 시멘틱 노드 아키텍처를 예시하고;
도 5a는 시멘틱 노드 계층을 구축하기 위한 방법의 일 양태를 예시하는 흐름도이고;
도 5b는 도 5a의 단계들을 더 구체적으로 예시하고;
도 6은 시멘틱 노드 등록의 메시지 흐름을 예시하고;
도 7은 자식에 의해 개시되는 부모-자식 관계(parent-child relationship)의 업데이트를 예시하고;
도 8은 시멘틱 자원 탐색을 처리하는 흐름도를 예시하고;
도 9는 RESTful 시멘틱 노드 동작의 메시지 흐름을 예시하고;
도 10은 시멘틱 관련 자원 탐색, 검색, 및 검증 프로세스의 메시지 흐름을 예시하고;
도 11은 형제/부모/자식 시멘틱 노드(sibling/parent/child semantics node)에 의해 저장 및 관리되는 시멘틱 관련 자원으로 업데이트될 수 있는 시멘틱 노드의 흐름도를 예시하고;
도 12는 동일한 시멘틱을 갖는 자원들을 그룹화하는 흐름도를 예시하고;
도 13은 시멘틱 관련 자원 푸싱을 예시하고;
도 14는 어떤 장치가 하나의 지역 네트워크에서 다른 지역 네트워크로 이동하는 시나리오를 예시하고;
도 15는 데이터/시멘틱 관련 자원 이동의 메시지 흐름을 예시하고;
도 16은 독립형 시멘틱 노드를 갖는 ETSI M2M 아키텍처를 예시하고;
도 17은 시멘틱 노드 자원 구조를 예시하고;
도 18은 SSs 자원 구조를 예시하고;
도 19는 통합된 시멘틱 노드들을 갖는 ETSI M2M 아키텍처를 예시하고;
도 20은 xSCL 자원 구조를 예시하고;
도 21은 <scl1>의 시멘틱 관련 자원 구조를 예시하고;
도 22는 contentInstance 시멘틱을 예시하고;
도 23은 자원 및 시멘틱 검색의 메시지 흐름을 예시하고;
도 24는 독립형 시멘틱 노드들을 갖는 3GPP MTC 아키텍처를 예시하고;
도 25는 독립형 시멘틱 노드들을 갖는 3GPP MTC 아키텍처를 예시하고;
도 26은 본 명세서에서 설명되는 바와 같은 시멘틱 노드들의 사용의 일례의 예시를 제공하고;
도 27은 시멘틱 예를 예시하고;
도 28은 체육관 사용 예에 연관되는 엔티티 구성을 예시하고;
도 29는 <class> 자원의 구조를 예시하고;
도 30은 <relationship> 자원의 구조를 예시하고;
도 31은 <term> 자원의 구조를 예시하고;
도 32는 시멘틱을 가능하게 하는 <AE> 자원을 예시하고;
도 33은 시멘틱을 가능하게 하는 <container> 자원을 예시하고;
도 34는 새로운 <container>를 생성하고 그것에 대한 시멘틱을 가능하게 하는 메시지 흐름을 예시하고;
도 35는 <contentInstance> 자원 및 시멘틱 검색의 메시지 흐름을 예시하고;
도 36은 체육관 사용 예에 대해 정의된 시멘틱 관련 자원들을 예시하고;
도 37은 전화기 CSE 자원 구조를 예시하고;
도 38은 체육관 CSE 자원 구조를 예시하고;
도 39a는 개시된 과제가 구현될 수 있는 예시적인 기기간(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 시스템도이고;
도 39b는 도 39a에 예시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이고;
도 39c는 도 39a에 예시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말기 또는 게이트웨이 장치의 시스템도이며;
도 39d는 도 39a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

현재의 M2M 시스템에서, (백엔드 네트워크 서버뿐 아니라 엔드 장치에서 호스트되는) M2M 애플리케이션은 교환된 데이터의 일반적인 정의에 미리 동의할 필요가 있다. 이것은 주로 애플리케이션을 대신하여 자동적으로 M2M 데이터를 분석, 해석, 또는 처리할 수 있는 시멘틱 인식 M2M 서비스 계층의 부족에 기인한다. 현재의 M2M 시스템에서, M2M 서비스 계층은 시멘틱 인식 능력이 부족하고 따라서 M2M 서비스 계층을 통해 흐르거나 그 내에 저장된 데이터는 불투명한 정보로 취급된다.

이와 같은 시멘틱 인식의 부족은 M2M 애플리케이션에 의해 생성된 데이터가 M2M 장치 계층에 의해 효율적으로 추상화되거나 가상화되도록 하여 서로 다른 애플리케이션이 그 데이터가 발생한 애플리케이션의 어떠한 사전 지식을 갖지 않더라도 이들에 의해 그 데이터를 탐색, 액세스, 해석, 및 공유할 수 있도록 하는 서비스를 M2M 서비스 계층에서 제공하는 것을 막는다. 그 결과, 감지 및 작동되는 물리 엔티티(예를 들어, 가전제품, 사람, 자동차, 건물의 객실 등)는 M2M 서비스 계층에 의해 효율적으로 가상화/추상화되지 않을 수 있고, 그 물리 엔티티는 환경에 내재된 일반 엔티티로 취급되고, 특정 M2M 애플리케이션과 연관되지 않는다.

이러한 제한사항을 극복하기 위해, M2M 시스템에서 전송된 데이터는 시멘틱 인식 M2M 서비스 계층이 M2M 애플리케이션과 동일한 데이터 지식을 가질 수 있도록 시멘틱 정보와 연관 및 통합될 수 있다. 그렇게 함으로써, M2M 서비스 계층은 애플리케이션에 걸쳐 데이터의 공유를 한층 더 용이하게 하고 M2M 애플리케이션에 부가가치 시멘틱 인식 서비스(예를 들어, 서로 다른 애플리케이션 간의 데이터 통합, 데이터 공유 등)를 제공할 수 있다.

예를 들면, 도 1에 예시된 환자 모니터링 애플리케이션에서는, 환자의 생체 신호(예를 들어, 혈압, 체온, 산소, 심박수 등)를 모니터하는 각 무선 센서 장치에 호스트된 별도의 애플리케이션이 있을 수 있다. 마찬가지로, 이러한 정보를 이용할 수 있는 네트워크 내에 호스트된 별도의 애플리케이션(예를 들어, 환자의 의사, 개인 트레이너, 가족 구성원, 앰뷸런스 응급 의료원 등과 관련된 애플리케이션)이 있을 수 있다. 그러나, 각 무선 센서 장치로부터의 M2M 시멘틱 인식 서비스 데이터가 없다면, 네트워크 애플리케이션은 네트워크 애플리케이션이 무선 센서 장치에 호스트된 애플리케이션 및 이들이 생성하는 정보의 유형(예를 들어, 위치/주소, 데이터의 단위, 데이터의 문맥 등)에 대한 사전 지식을 갖지 않는다면 장치 애플리케이션으로부터의 정보를 탐색, 공유, 및 이해하는데 어려움이 있을 수 있다.

본 출원은 M2M 시스템에서 M2M 서비스 계층의 시멘틱 인식 및 데이터 추상화를 지원하기 위해 다음과 같은 기능, 즉 (i) 시멘틱 정보를 저장하기 위한 지원, 및/또는 시멘틱 정보를 저장하는 서버와의 인터페이스 지원; (ii) 시멘틱 정보를 생성, 검색, 업데이트, 및 삭제하는 메커니즘 지원; (iii) 로컬 및 원격 자원에 대한 시멘틱 정보 업데이트를 위한 메커니즘 지원; (iv) 시멘틱 정보를 로컬 또는 원격으로 저장될 수 있는 대응하는 자원과 연관/링크시키기 위한 지원; 및 (v) 시멘틱 기술을 게시 및 탐색하기 위한 능력을 제공할 수 있다.

상술한 하나 이상의 기능들을 제공하기 위해, 본 출원은 시멘틱 노드의 개념을 개시한다. 본 명세서에 설명된 바와 같이, 시멘틱 노드는 M2M 게이트웨이, M2M 장치, 또는 M2M 서버 등과 같은 네트워크 내의 독립형 컴퓨팅 장치(예를 들어, 서버)에 호스트되거나 네트워크 내의 기존의 엔티티에 호스트될 수 있는 논리 엔티티이다. 시멘틱 노드는 데이터를 기술하는 저장소로 볼 수도 있다. 예를 들면, 혈압 센서 장치는 그의 데이터를 기술하는 방법을 이해하고자 할 수 있으므로, 그 혈압 센서 장치는 이미 정의된 혈압 클래스가 존재하는지 알기 위해 주변 시멘틱 노드를 쿼리한다. 그렇다면, 시멘틱 노드는 센서 장치에 그것이 국지적으로 찾은 혈압 클래스로 응답한다. 그렇지 않다면, 시멘틱 노드는 다른 시멘틱 노드(예를 들어, 형제 또는 부모)에게 쿼리할 수 있다. 시멘틱 노드의 사용은 최종 장치가 데이터의 설명을 저장시킬 필요성을 감소시킬 수 있다.

시멘틱 노드는 시멘틱 노드가 저장되는, 시멘틱 관련 자원을 저장 및 관리한다. 시멘틱 관련 자원은 일반적으로, 예를 들어, 이들의 시멘틱의 이해를 가능하게 하기 위해 시멘틱 관련 자원을 이들과 연관시킬 필요가 있는 자원 트리 하에 저장된 ETSI M2M 자원인 <SCL>, <application>, <container>, <contentInstance>와 같은 다른 자원들을 기술한다. 일 실시예에서, 시멘틱 관련 자원은 세 개의 유형, 즉 클래스, 관계, 및 용어 중 하나를 가질 수 있다. 이러한 분류는 시멘틱 웹의 현재 기술과의 호환성을 제공하고 M2M 시스템이 기존의 시멘틱 관련 자원을 활용 가능하도록 한다.

본 명세서에 언급된 바와 같이, 시멘틱 노드들은 M2M 시스템에서 서로 다른 레벨이 계층 구조로 형성되도록 M2M 지역 네트워크, M2M 액세스 네트워크, 및 M2M 코어 네트워크와 같은 서로 다른 레벨에 배치될 수 있다. 동일한 레벨의 시멘틱 노드들은 분산되고 형제 관계를 가질 수 있다. 서로 다른 레벨의 추상화 및 호환성의 이익을 기존의 네트워크 계층에 제공하는 그러한 하이브리드 아키텍처의 시멘틱 노드를 구축 및 유지하는 것과 관련된 메커니즘이 개시된다.

또한, 시멘틱 노드의 기능, 참조 포인트, 메시지, 및 절차가 개시된다. 다양한 실시예들에서, 다음과 같은 기능이 시멘틱 노드에서 이용 가능할 수 있다: (i) 시멘틱 노드에 의해 관리되는 시멘틱 관련 자원은 탐색, 검색, 및 검증될 수 있고; (ii) 시멘틱 노드는 다른 노드들에 의해 탐색될 수 있고 시멘틱 관련 자원은 가입 메커니즘으로도 탐색될 수 있으며; (ⅲ) 시멘틱 관련 자원은 시멘틱 관련 자원이 시멘틱 정보를 제공받고 보편적으로 이해되도록 M2M 시스템 내의 자원과 링크 및 연관될 수 있으며; (ⅳ) 시멘틱 관련 자원은 효율적인 탐색 및 용이한 액세스를 위해 계층 내의 다른 시멘틱 노드로 푸시될 수 있고; (v) 시멘틱 관련 자원의 연관 및 링킹은 기술되는 시멘틱 관련 자원의 시멘틱 유사성 및 그룹화에 따라 최적화될 수 있으며; (ⅵ) 시멘틱 관련 자원은 데이터 이동과 함께, 하나의 시멘틱 노드에서 다른 시멘틱 노드로 이동될 수 있다.

이하에 설명되는 일 실시예에서, 시멘틱 노드는 ETSI M2M/oneM2M 아키텍처의 서비스 기능 계층(xSCL)들에서 구현된다. 다른 예에서, 시멘틱 노드는 3GPP 기계형 통신(MTC; Machine Type Communication) 아키텍처의 서비스 기능 서버(SCS)에서 구현된다.

I. 시멘틱 노드를 갖는 M2M 아키텍처

시멘틱 노드를 포함하는 M2M 시스템의 일 실시예가 도 3에 예시되어 있다. M2M 시스템(150)에 도시된 바와 같이, 시멘틱 노드는 세 가지 레벨에 배치된다. 지역 네트워크(154), 지역 네트워크(155), 지역 네트워크(156), 및 지역 네트워크(157)와 같은 네트워크를 포함할 수 있는 지역 레벨이 있을 수 있다. 액세스 네트워크(152) 및 액세스 네트워크(153)와 같은 네트워크를 포함할 수 있는 액세스 레벨이 있을 수 있다. 그리고 코어 네트워크(151)와 같은 네트워크를 포함하는 코어 레벨이 있을 수 있다.

시스템(150)에 도시된 바와 같이, 애플리케이션(158)은 sIc 참조 포인트(159)를 통해 지역 네트워크(157) 내에 배치된 M2M 시멘틱 노드(160)와 통신적으로 접속될 수 있다. sIc 참조 포인트는 일반적으로 애플리케이션, 지역 네트워크, 액세스 네트워크 내의 다른 비시멘틱 노드 엔티티, 및 코어 네트워크 엔티티에 의해 시멘틱 노드와 대화하기 위해 사용된다. M2M 시멘틱 노드(160)는 sIe 참조 포인트(162)를 통해 외부 시멘틱 노드(163)와 통신적으로 접속된다. M2M 시스템 내의 시멘틱 노드는 sIe 참조 포인트를 통해 외부 시멘틱 노드와 인터페이스할 수 있다. 외부 시멘틱 노드는 시멘틱 웹에 대해 RDFS에 의해 정의된 것들과 같은 다른 기존의 시멘틱 관련 자원을 관리할 수 있다. M2M 시멘틱 노드(160)는 또한 sIs 참조 포인트(161)를 통해 액세스 네트워크(153) 내에 배치된 M2M 시멘틱 노드(164)와 통신적으로 접속된다. M2M 시멘틱 노드(164)는 sIc 참조 포인트(166)를 통해 M2M 게이트웨이(165)와 통신적으로 접속되고 sIs 참조 포인트를 통해 코어 네트워크(151) 내에 배치된 M2M 시멘틱 노드(168)와 통신적으로 접속된다. 본 예에서, M2M 게이트웨이(165) 자체는 시멘틱 노드가 아니지만, 다른 예에서, M2M 게이트웨이(165)는 시멘틱 노드의 기능을 포함할 수 있다.

시멘틱 노드(들)는 오프로딩, 로드 밸런싱, 용이한 액세스 등의 목적으로 지역 레벨에 배치될 수 있다. 지역 레벨에서, 로컬 지역 네트워크(local area network) 내의 모든 장치가 연결형 액세스 또는 코어 네트워크 내의 시멘틱 노드와 통신하는 경우 어떠한 시멘틱 노드도 배치되지 않는 것이 가능하다. 지역 레벨의 시멘틱 노드는 액세스 레벨에서 대응하는 부모 시멘틱 노드(예를 들어, M2M 시멘틱 노드(164)와 접속된 M2M 시멘틱 노드(160)) 또는 코어 레벨에서 대응하는 부모 시멘틱 노드(예를 들어, 시멘틱 노드를 포함하는 M2M 서버(170)와 접속된 M2M 시멘틱 노드(169))를 가질 수 있다. 시멘틱 노드들은 sIs 참조 포인트를 통해 서로 대화한다. 참조 포인트의 상세에 대해서는 이하에서 더 정의된다. 또한 액세스 레벨의 시멘틱 노드는 그것이 sIs 참조 포인트를 통해 통신하는 코어 레벨의 부모를 가질 수도 있다. 마찬가지로, 액세스 레벨의 시멘틱 노드는 그것이 sIs 참조 포인트를 통해 통신하는 지역 레벨의 자식 시멘틱 노드를 가질 수 있다. 코어 레벨의 시멘틱 노드는 액세스 또는 지역 레벨의 자식 시멘틱 노드를 가질 수 있다.

도 3에 예시된 부모-자식 관계 외에, 시멘틱 노드는 또한 시멘틱 노드 레벨들 중 어느 것(예를 들어, 액세스, 지역, 또는 코어)에서도 형제의 개념을 지원한다. 형제 시멘틱 노드는 계층 내에서 동일 레벨에 있는 노드이며 시멘틱 노드의 부하를 분산시키는데 사용될 수 있다. 예를 들면, 코어 네트워크(151)에서, M2M 시멘틱 노드(168)는 시멘틱 노드를 포함하는 M2M 서버(170)와 접속된다. 수직적 관점에서, 하나보다 많은 시멘틱 노드로 된 계층이 구축된 경우, 그 노드들은 sIs 참조 포인트를 통해 통지, 방송, 탐색 등을 이용하여 서로 대화하고 시멘틱 정보를 공유할 수 있다.

제한된 장치의 경우, 기능 제한으로 인해, 시멘틱은 원격 시멘틱 노드에 저장된 시멘틱을 가리키는 특정 시멘틱 또는 링크를 참조하는 코드일 수 있다. 이러한 시멘틱 정보는 데이터를 생성한 애플리케이션에 의해 또는 서비스 계층에 의해 제공될 수 있다.

액세스 레벨에는, 하나의 액세스 네트워크 내에 배치된 하나 이상의 시멘틱 노드가 있을 수 있다. 그렇다면, 형제는 sIs 참조 포인트를 통해 시멘틱 정보의 통지, 방송 및 탐색을 위해 서로 통신할 수 있다. 액세스 레벨의 시멘틱 노드는 또한 그것이 sIs 참조 포인트를 통해 통신하는 코어 레벨의 부모를 가질 수 있다. 마찬가지로, 액세스 레벨의 시멘틱 노드는 그것이 sIs 참조 포인트를 통해 통신하는 지역 레벨의 자식 시멘틱 노드를 가질 수 있다.

코어 레벨에는, 코어 네트워크 내에 배치된 하나 이상의 시멘틱 노드가 있을 수 있다. 이들 노드는 형제일 수 있으며, 통지, 방송 및 탐색을 이용하여 시멘틱 정보를 공유하기 위해 sIs 참조 포인트를 통해 서로 통신할 수 있다. 코어 레벨의 시멘틱 노드는 또한 액세스 또는 지역 레벨의 자식 시멘틱 노드를 가질 수 있다. 지역 네트워크, 액세스 네트워크 및 코어 네트워크 내의 애플리케이션, 다른 비시멘틱 노드 엔티티는 sIc 참조 포인트를 통해 시멘틱 노드와 대화한다.

전술한 바와 같이, 시멘틱 노드는 네트워크 내의 독립형 물리 노드(예를 들어, 독립형 M2M 시멘틱 노드(160))일 수 있거나 그것은 도 3의 시스템(150)에 도시된 바와 같이 M2M 장치(171), M2M 게이트웨이(172), 또는 M2M 서버(170)와 같은 네트워크 내의 다른 물리 노드에 호스트된 논리 엔티티일 수 있다. 다시 말하면, M2M 장치, M2M 게이트웨이, 및 M2M 서버는 시멘틱 노드 기능을 지원할 수 있다.

도 3에 예시된 다중 계층 시멘틱 노드 계층의 특징은 그것이 서로 다른 레벨의 추상화를 제공할 수 있다는 것이다. 시멘틱 노드는 지역 네트워크 특정 시멘틱 관련 자원을 국지적으로 찾을 수 있도록 M2M 지역 네트워크에서와 같은 로컬 지역에서 시멘틱 관련 자원의 관리만 담당할 수 있다. 로컬 지역에서 전형적이지 않는 모든 시멘틱 관련 자원은 상위 레벨의 부모 또는 평행한 형제 시멘틱 노드에 저장되고 그 노드에서 발견될 수 있다. 또 다른 특징은 시멘틱 관련 자원이 인터넷 계층, 위치 계층 등으로 인해 그들 스스로 계층을 가질 수 있다는 것이다. 그 결과, 다중 시멘틱 계층은 기존의 네트워크 아키텍처와 일관성이 있게 된다. 또한, 시멘틱 노드들은 각 레벨에 분산될 수 있으며, 이것은 중앙 집중식 시멘틱 노드가 코어 네트워크에만 배치된 경우에 단일 고장점(failure point)을 막는다.

II. 시멘틱 노드 아키텍처

이제 시멘틱 노드의 아키텍처에 관하여 좀 더 상세한 내용이 설명될 것이다. 언급된 바와 같이, 시멘틱 노드는 시멘틱 관련 자원을 저장 및 관리한다. 본 명세서에 정의된 바와 같이, 시멘틱 관련 자원은 M2M 장치 또는 애플리케이션에 의해 생성된 데이터의 의미 또는 그 M2M 장치 또는 애플리케이션 자체와 같은 사물의 시멘틱 정보를 기술하는데 사용될 수 있는 정보를 포함한다. 일 예에서, 시멘틱 관련 자원은 확장 가능한 마크업 언어(XML) 스키마 정의(XSD), 또는 RDF 스키마/웹 온톨로지 언어(RDFS/OWL; RDF Schema/Web Ontology Language) 등과 같은 기존의 스키마를 이용하여 XML로 표현될 수 있다. 일 예에서는, 세 가지 유형의 시멘틱 관련 자원, 즉 클래스, 관계, 및 용어가 시멘틱 노드에 저장될 수 있으며, 그 각각에 대해서는 이하에서 더 충분히 설명된다. 이러한 방식으로 시멘틱 관련 자원을 분류하면 시멘틱 웹의 현재 기술과의 호환성을 제공한다. 이러한 호환성은 M2M 시스템이 예를 들어 W3C에 의해 정의된 그 핵심 클래스 및 핵심 속성과 같은 기존의 시멘틱 관련 자원을 활용 가능하도록 한다. M2M 시스템의 외부 애플리케이션 및 엔티티는 시멘틱 호환성을 위해 필요한 포맷 변환 또는 수정으로 인한 어떠한 추가의 오버헤드도 발생시키지 않고 시멘틱 노드에 의해 호스트된 시멘틱 관련 자원을 이용할 수 있다.

클래스들(Classes). 본 명세서에서는 M2M 도메인에서 객체/사물의 클래스의 개념이 설명된다. 도 1의 예시적인 건강 모니터링 시스템에서, 예를 들어, 그 시스템과 관련된 객체의 클래스는 환자, 의사, 앰뷸런스 디스패처, 혈압, 심부 체온, 산소 포화도, 및 모션 가속도계 등을 포함한다. 클래스는 통합 자원 식별자(URI; uniform resource identifier) 또는 통합 자원 로케이터(URL; uniform resource locator)에 의해 식별될 수 있다. 클래스는 그 클래스를 정의하는 정보를 포함하는 필드 설명을 포함한다. 예를 들면, 온도 데이터를 섭씨 단위의 정수로 나타내며, 예를 들어 그 시멘틱을 온도 센서에 의해 생성된 데이터에 제공하는데 사용될 수 있는 temperatureReading 클래스가 다음과 같이 XSD 스키마로 XML로 정의될 수 있다:

여기서, 클래스는 필드 "description", "unit", 및 "base"를 포함하며, 그 필드에서 정보는 각각 "temperature in Celsius", "Celsius", 및 "integer"이다. 다른 예로, BloodPressure 클래스는 두 개의 필드를 포함할 수 있으며, 하나는 수축기 혈압 그리고 다른 하나는 확장기 혈압에 대한 것이다. 이와 같은 BloodPressure 클래스의 클래스 설명은 두 필드의 설명을 포함할 것이며 다음과 같이 XML/ 를 이용하여 표현될 수 있다.

그러나, 다시, 클래스(및 다른 유형의 시멘틱 관련 자원 - 관계 및 용어)는 XML/XSD를 이용하는 표현으로 제한되지 않고, 오히려 예를 들어 RDFS/OWL 등을 포함하여 다양한 적절한 기술 언어 중 어떠한 것으로도 표현될 수 있음이 이해된다. 클래스도 서로 관련될 수 있다. 예를 들면, "혈압"은 "생체"의 하위 클래스일 수 있거나, 또는 동등하게 "생체"는 "혈압"의 상위 클래스일 수 있다. 하위 클래스/상위 클래스 관계는 클래스의 계층을 정의한다. 일반적으로, A는 A의 모든 인스턴스가 B의 인스턴스이기도 한 경우 B의 하위 클래스이다. A 클래스는 다수의 상위 클래스를 가질 수도 있다.

관계들(Relationships). 관계는 특별한 종류의 시멘틱 관련 자원이다. 관계는 시멘틱 관련 자원들 간의 관계, 예를 들어 "에 의해 생성된", "수명", "에 의해 가입된" 등을 기술한다. 관계는 또한 M2M 도메인의 관계에 전역적 및 고유 네이밍 방식을 부여하는 URI/URL에 의해 식별될 수 있다. 클래스 및 상속은 다른 컴퓨팅 분야에서, 예를 들어 객체 지향 프로그래밍에서 알려져 있다. 그러나, 유사성이 있지만, 차이점도 존재한다. 객체 지향 프로그래밍에서, 객체 클래스는 그것에 적용되는 관계 또는 속성을 정의한다. 클래스에 새로운 관계 또는 속성을 추가하는 것은 그 클래스를 수정하는 것을 의미한다. 그러나, 여기서, 관계는 전역적으로 정의되며, 즉 이들은 클래스 정의에서 속성으로 캡슐화(encapsulate)되지 않는다. 클래스 자체의 정의를 변경하지 않고 기존의 클래스에 적용되는 새로운 관계가 정의될 수 있다. 클래스와 같이, 관계도 서로 관련될 수 있다. 예를 들면, "에너지 모드" 및 "사용 모드"는 "모드"의 하위 관계이다. 어떤 장치가 전기의 "에너지 모드" 및 수동의 "사용 모드"를 갖는 경우, 그 장치는 전기 및 수동의 "모드"를 갖는다.

용어들(Terms). 용어는 M2M 도메인에서 흔히 사용되는 개념이다. 본 명세서에 정의된 바와 같이, 용어는 많은 관계자에 의해 자원의 시멘틱을 기술하는데 사용될 수 있는 값이다. 용어의 정의는 그것이 게시된 특정 도메인에서 일반적으로 인식될 수 있다. 예를 들면, 수동, 사용자 지향(user-directed), 및 자동은 각각, 예를 들어, 가전제품의 사용 모드를 기술하는데 사용될 수 있는 용어의 예이다. 일반적으로, 시멘틱 관련 자원의 생성자는 그 시멘틱 관련 자원이 클래스, 관계, 또는 용어인지를 결정할 것이다. 그런 다음, 시멘틱 노드는 이들의 생성자에 의해 정의되거나 결정된 카테고리 하에서 시멘틱 관련 자원을 저장할 것이다. 예를 들면, 도 1의 환자 모니터링 예에서, 시멘틱 관련 자원 클래스, 관계, 및 용어는 혈압 모니터 제조자에 의해, 의사에 의해, 또는 다른 가전제품 제조자에 의해 생성될 수 있다. 다른 예에서, 시멘틱 관련 자원 클래스, 자원, 및 용어는 수직 애플리케이션(vertical application)에 의해 정의되거나 생성될 수 있다.

(데이터, 사물 등 포함하는) 자원의 시멘틱은 자원, 관계 및 값으로 이루어지는 삼중 자원-관계-값에 의해 기술될 수 있다. 값은 클래스, 용어, 또는 다른 자원일 수 있다. 다음은 몇 가지 예이다.

·A content instance (자원) hasType (관계) temperatureReading (클래스)

·An appliance (자원) hasUsageMode (관계) user-directed (용어)

·A content instance (자원) generatedBySameApplicationAs (관계) another content instance (자원)

제안된 sIc, sIs, 및 sIe 참조 포인트를 통해, 시멘틱 노드의 클래스, 관계 및 용어 자원에 대한 요청이 이루어질 수 있다. 도 4는 M2M 시멘틱 노드의 클래스, 관계 및 용어 자원의 전형적인 예시이다. 본 예에 예시된 바와 같이, 시멘틱 노드(420)는 서로 다른 애플리케이션 및 도메인으로부터의 다양한 클래스(422), 관계(424) 및 용어(426)를 저장하도록 구성될 수 있다. 대안으로, 시멘틱 노드 (420)는 가전제품 시멘틱, 차량 시멘틱, 또는 건강 관리 애플리케이션 시멘틱 등과 같은 고유 애플리케이션 또는 도메인에 대한 클래스, 관계, 및 용어 자원을 저장하도록 구성될 수 있다.

III. M2M 시멘틱 노드 기능 및 참조 포인트

본 섹션에서는, 시멘틱 노드의 기능 및 참조 포인트에 관한 추가적인 상세 내용이 제공된다. 일 예에서, 시멘틱 노드는 다음과 같은 기능, 즉 시멘틱 노드 계층에서의 하위 레벨 자식 또는 평행한 형제 시멘틱 노드가 시멘틱 노드의 자원을 등록하고 그에 대한 요청을 하도록 이들 노드를 인증하는 것을 포함하여 다른 시멘틱 노드를 인증하는 것; 이들 노드가 시멘틱 관련 클래스, 관계 및 용어 자원을 게시, 생성, 삭제, 업데이트, 및 검색하도록 애플리케이션, 장치, 및/또는 사용자를 인증하는 것; 시멘틱 관련 클래스, 관계 및 용어 자원을 저장 및 관리하는 것; 시멘틱 관련 자원의 탐색 지원을 제공하는 것; 그리고 탐색 쿼리에 대해 협력하고 시멘틱 관련 자원 정보를 공유하기 위해 시멘틱 노드가 (부모-자식, 형제 간에서) 서로 통신하도록 지원을 제공하는 것을 수행할 수 있다.

시멘틱 노드는 하나 이상의 참조 포인트 또는 인터페이스를 통해 네트워크 내의 다른 엔티티와 통신할 수 있다. 일 예에서, 세 가지 참조 포인트, 즉 sIs 참조 포인트, sIc 참조 포인트, 및 sIe 참조 포인트가 정의된다. sIs 참조 포인트는 시멘틱 노드들 간의 통신에 사용된다. sIs 참조 포인트는 또한 부모-자식 또는 형제 관계를 형성하기 위해 어떤 시멘틱 노드에 의해 다른 시멘틱 노드에 등록하고, 다른 시멘틱 노드를 탐색하고, 그의 상태(예를 들어, 온라인, 오프라인, 과부하 등)에 대해 다른 노드에 통지하고, 특정 동작(예를 들어, 등록 취소, 등록)을 수행하도록 다른 시멘틱 노드를 트리거하고, 다른 시멘틱 노드에서 시멘틱 관련 자원을 게시, 생성, 삭제, 업데이트, 및 검색하는데 사용될 수 있다. 또한, 시멘틱 노드는 이하에서 도 20, 도 21, 및 도 22과 관련하여 더 설명되는 바와 같이, sIs 참조 포인트를 이용하여 다른 시멘틱 노드의 시멘틱 관련 자원에 가입하고 대응하는 통지를 수신하고, 그의 계층에서 형제 및 부모 시멘틱 노드에 대한 시멘틱 관련 자원을 탐색하고, 시멘틱 관련 자원 그룹을 하나의 시멘틱 노드에서 다른 시멘틱 노드로 이동하고, 그리고 그 시멘틱을 자원에 제공하기 위해 다른 시멘틱 노드에 저장된 시멘틱 관련 자원이 그 자원과 링크 및 연관되도록 할 수 있다.

본 실시예에서, sIc 참조 포인트는 애플리케이션 또는 비시멘틱 노드에 의해 다양한 네트워크 도메인(예를 들어, 지역 네트워크, 액세스 네트워크, 또는 코어 네트워크)에서 시멘틱 노드와 통신하는데 사용될 수 있다. sIc 참조 포인트는 또한 애플리케이션 또는 비시멘틱 노드가 시멘틱 노드의 시멘틱 관련 자원을 게시, 생성, 삭제, 업데이트, 검색, 가입, 또는 탐색하고 시멘틱 노드로부터 통지를 수신하도록 한다. 또한, sIc 참조 포인트는 시멘틱을 자원에 제공하기 위해 시멘틱 노드에 저장된 시멘틱 관련 자원이 그 자원과 링크 및 연관되도록 한다.

sIe 참조 포인트는 M2M 시스템 내에 있는 기존의 노드 계층의 일부인 시멘틱 노드와 외부 시멘틱 노드 간의 통신에 사용될 수 있다. 외부 시멘틱 노드는 M2M 도메인의 외부에 있는 시멘틱 관련 자원을 저장한다. 외부 시멘틱 노드의 일례는 http://www.w3.org/2005/Incubator/ssn에 기술된 바와 같은, W2C 시멘틱 센서 네트워크 인큐베이터 그룹에 의해 정의된 시멘틱 센서 네트워크 온톨로지에 대한 시멘틱 관련 자원을 저장하는 서버일 수 있다. sIe 참조 포인트는 시멘틱 노드가 외부 시멘틱 노드의 시멘틱 관련 자원을 검색, 탐색, 및 가입하도록 하며, 그 반대의 경우도 가능하다. 또한, sIe 참조 포인트를 통해, 외부 시멘틱 노드는 M2M 시스템 내의 시멘틱 노드를 탐색하고 통지를 수신할 수 있다.

sIs, sIe, 및 sIc 참조 포인트를 효율적으로 정의하는, 그 참조 포인트들과 연관된 메시지의 일 실시예가 아래의 표 1에 제시되어 있다.

표 1은 시멘틱 노드 관련 메시지, 대응하는 의미, 및 사용되는 참조 포인트를 열거한다.

하이퍼텍스트 전송 프로토콜(HTTP) 또는 제한된 애플리케이션 프로토콜(CoAP; constrained application protocol)과 같은 프로토콜은 서로 다른 유형의 메시지를 운반하기 위한 기본적인 전송 프로토콜로 사용될 수 있다. 이들 메시지를 이용하여 전술한 다양한 시멘틱 노드 기능을 수행하는 것의 예들이 이하에 제시된다.

IV. M2M 시멘틱 노드 절차

A. 시멘틱 노드 계층 구축

본 섹션에서는, 일 실시예에 따른 시멘틱 노드의 계층(이하 "시멘틱 노드 계층(semantics node hierarchy)")의 구축 방법에 관한 추가적인 상세 내용이 제공된다. 본 예에서, 시멘틱 노드 계층은 네트워크 내 서로 다른 지역, 액세스, 및 코어 레벨에 배치된 시멘틱 노드들 간의 부모-자식 및 형제 관계를 결정함으로써 구축된다.

도 5a는 시멘틱 노드 계층을 구축하기 위한 방법의 일 실시예를 예시하는 흐름도이다. 시멘틱 노드가 네트워크에 가입하면(단계 504), 즉 온라인이 되면, 그 시멘틱 노드는 네트워크 내에서 동작 가능한 시멘틱 노드가 될 수 있기 전에, 먼저 자식-부모 및 형제 관계를 확립할 필요가 있다. 이를 위해, 단계 506에서, 시멘틱 노드는 동일한 레벨에 있는 형제 시멘틱 노드의 탐색을 수행할 수 있다.

형제 시멘틱 노드의 탐색은 시멘틱 노드 탐색 요청을 송신(예를 들어, 멀티캐스트, 브로드캐스트, 애니캐스트)하는 것에 기초할 수 있으며, 이 경우 탐색 요청은 형제 시멘틱 노드를 탐색하려고 시도할 때 발행될 수 있다. 그러한 요청은 네트워크를 혼잡하게 할 수 있는 탐색 요청 및 응답 메시지의 범람을 제한하는 정의된 홉 제한을 가질 수 있다. 대안으로, 탐색은 이용 가능한 도메인 이름 시스템(DNS), DNS 서비스 탐색(DNS-SD), 서비스 로케이션 프로토콜(SLP) 등과 같은 네트워크 내에서 이용 가능한 기존의 탐색 메커니즘을 활용할 수 있다. 시멘틱 노드는 관리되는 시멘틱 정보의 IP 주소 또는 유형(들)과 같은 이웃하는 형제 시멘틱 노드의 반송된 정보를 저장할 수 있다. 이하에서 더 언급된 바와 같이, 형제 시멘틱 노드 탐색 응답 메시지는 또한 상위 레벨 시멘틱 노드 탐색 서버의 주소, 형제의 부모 시멘틱 노드의 주소, 또는 양자를 피기백할 수 있다.

계속 도 5a를 참조하면, 형제 시멘틱 노드를 탐색한 다음, 시멘틱 노드는 이어서 단계 508, 단계 510, 및 단계 512에서 상위 레벨 시멘틱 노드를 탐색 및/또는 그 상위 레벨 시멘틱 노드에 등록을 시도할 수 있다. 시멘틱 노드에 등록할 필요가 있는 상위 레벨 노드가 프로비저닝된 경우, 그 시멘틱 노드는 단순히 이러한 프로비저닝된 시멘틱 노드에 등록하고 부모-자식 관계를 확립할 수 있다(단계 508, 단계 512). 그렇지 않으면, 시멘틱 노드는 기존의 상위 레벨 시멘틱 노드를 탐색하고, 그 중 등록할 하나를 선택할 필요가 있다(단계 510). 이러한 선택은 동일한 유형(들)의 시멘틱 관련 자원 등을 지원하는, 인접한 상위 레벨에서 가장 가까운 것과 같은 기준에 기초할 수 있다. 도 5b는 이들 단계 508, 510, 및 512를 더 상세히 예시한다.

본 예에서, 각 레벨에는, 디폴트로 상위 레벨 시멘틱 노드 탐색 요청을 수락하는 하나의 시멘틱 노드 탐색 서버가 있을 수 있다. 시멘틱 노드 탐색 서버의 주소는 하위 레벨 시멘틱 노드에게 잘 알려져 있을 수 있다. 도 5b에 도시된 바와 같이, 새로운 시멘틱 노드에 상위 레벨의 부모 시멘틱 노드 주소가 프로비저닝되지 않은 경우(단계 602), 그리고 새로운 시멘틱 노드에 상위 레벨에 있는 시멘틱 노드 탐색 서버가 프로비저닝되지 않은 경우(단계 604), 그 새로운 시멘틱 노드는 먼저 형제 시멘틱 노드 탐색을 수행할 수 있다(단계 606). 형제 탐색의 일환으로, 시멘틱 노드 탐색 서버의 주소가 공유(예를 들어, 탐색된 형제 시멘틱 노드로부터 수신된 형제 탐색 응답에서 피기백)될 수 있다(단계 608). 한편, 그 새로운 시멘틱 노드는 또한 등록할 하나를 그 자신의 부모로 선택할 수 있도록 형제의 부모 시멘틱 노드 정보(주소)를 명시적으로 요청할 수 있다(단계 610, 618).

새로운 시멘틱 노드에 상위 레벨 시멘틱 노드 탐색 서버의 주소가 프로비저닝된 경우, 그 새로운 시멘틱 노드는 시멘틱 노드 탐색을 직접 수행할 수 있다(제어는 단계 604에서 단계 614로 진행한다). 그렇지 않으면, 그 새로운 시멘틱 노드가 형제의 부모 목록에서 선택하고자 하는지 여부와 그것이 형제로부터 디폴트 시멘틱 노드 탐색 서버의 주소를 검색하고자 하는지 여부를 결정한다(단계 608 및 610). 새로운 시멘틱 노드가 형제의 부모로부터 상위 레벨 시멘틱 노드를 선택하면(단계 618), 그것은 시멘틱 노드 탐색을 더 이상 수행하지 않도록 선택할 수 있다. 그렇지 않으면, 그 새로운 시멘틱 노드는 (동일한 유형(들)의 시멘틱 관련 자원 등을 지원하는, 홉 수에서 가장 가까운) 부모를 선택하는 기준을 결정한다(단계 614). 그 기준에 기초하여, 그 새로운 시멘틱 노드는 시멘틱 노드의 주소 외에 상위 레벨에서 탐색하고자 하는 정보(시멘틱 자원의 거리, 지원 유형(들) 등)를 설정한다(단계 616).

단계 620에서, 새로운 시멘틱 노드는 그것이 탐색했거나 그렇지 않고 선택한 상위 레벨 부모 시멘틱 노드에 등록할 수 있다. 새로운 시멘틱 노드가 상위 레벨 시멘틱 노드 탐색 서버의 주소를 알지도 못하고 그것이 등록할 수 있는 그의 형제의 어떠한 상위 레벨 부모 시멘틱 노드도 식별할 수 없는 경우, 그것은 어떠한 상위 레벨 부모 시멘틱 노드도 이용 가능하지 않다고 결정하고 단계 612에서 프로세스를 종료할 수 있다.

다시 도 5a를 참조하면, 일단 형제의 탐색과 부모 노드의 탐색 및 그 부모 노드에 등록이 완료되면, 새로운 시멘틱 노드의 형제 및 부모에 대한 정보가 저장된다(단계 514). 도 5a에 더 예시된 바와 같이, 새로운 형제가 네트워크에 가입하거나 기존의 형제가 오프라인이 되는 경우, 시멘틱 노드는 그의 시멘틱 노드 관계를 업데이트할 수 있다(단계 516, 518). 단계 520에서, 새로운 시멘틱 노드는 이제 동작 가능하다. 도 5a에 더 예시된 바와 같이, 동작 가능한 시멘틱 노드는 조금 나중에 그것이 네트워크에서 탈퇴할 수 있는(단계 526) 다른 상위 레벨 노드에 등록하도록 트리거될 수 있다(단계 522). 후자의 경우에, 시멘틱 노드는 그의 현재의 부모에의 등록을 취소하고 새로운 것에 등록할 수 있다(단계 524). 전자의 경우, 시멘틱 노드는 단순히 그의 현재의 부모에의 등록을 취소할 수 있다(단계 528).

도 6은 전술하고 도 5a 및 도 5b에 예시된 시멘틱 노드 탐색 및 등록 프로세스를 더 예시하는 메시지 흐름도이다. 단계 185에서, 새로운 시멘틱 노드(181)는 시멘틱 노드 탐색 요청을 형제 시멘틱 노드(182)에 송신한다. 형제 시멘틱 노드(182)는 새로운 시멘틱 노드(181)와 동일한 네트워크 레벨에 있다. 단계 185의 시멘틱 노드 탐색 요청은 시멘틱 노드 탐색 서버(183)와 관련된 정보(예를 들어, 주소)의 요청 또는 형제 시멘틱 노드(182)의 부모(예를 들어, 상위 레벨) 시멘틱 노드(184)인 시멘틱 노드에 대한 정보를 포함할 수 있다. 부모 시멘틱 노드에 대한 요청은 새로운 시멘틱 노드(181)가 등록할 그 자신의 부모를 선택하도록 할 수 있다.

시멘틱 노드 탐색 서버(183)는 동일한 레벨에 분산된 시멘틱 노드들의 정보를 저장하기 위한 중앙 집중 포인트 또는 동일 레벨의 네트워크에서 탐색 요청을 범람시키고 시멘틱 노드들의 반송된 응답을 수집하는 랑데부 포인트(rendezvous point)로 간주될 수 있다. 시멘틱 노드 탐색 서버(183)는 새로운 시멘틱 노드(181)의 네트워크 레벨보다 상위, 동일, 또는 하위 레벨의 네트워크 레벨에 있는 네트워크에 상주하는 서버일 수 있다. 본 예는 시멘틱 노드 탐색 서버(183)가 새로운 시멘틱 노드(181)의 네트워크 레벨과 관련하여 상위 레벨에 있다고 가정한다. 시멘틱 노드 탐색 서버(183)의 주소는 하위 레벨 시멘틱 노드(예를 들어, 형제 시멘틱 노드(182))에게 잘 알려져 있을 수 있다. 새로운 시멘틱 노드(181)에 시멘틱 노드 탐색 서버(183)가 프로비저닝되지 않은 경우, 새로운 시멘틱 노드(181)는 형제 시멘틱 노드 탐색을 수행할 수 있다. 새로운 시멘틱 노드(181)에 시멘틱 노드 탐색 서버(183)의 주소가 프로비저닝된 경우, 그 새로운 시멘틱 노드는 시멘틱 노드 탐색을 직접 수행할 수 있다.

도 6의 단계 186에서, 형제 시멘틱 노드(182)는 시멘틱 노드 탐색 응답을 송신한다. 시멘틱 노드 탐색 응답은 시멘틱 노드 탐색 서버(183)에 대한 정보(예를 들어, 주소 정보) 또는 형제 시멘틱 노드(182)의 부모인 시멘틱 노드에 대한 정보를 포함할 수 있다. 네트워크 레벨에 있는 각 형제 노드는 형제 시멘틱 노드(182)에 의해 제공되는 정보와 다를 수 있는 부모 시멘틱 노드 정보 및 시멘틱 노드 탐색 서버 정보로 응답할 수 있다.

단계 187에서, 새로운 시멘틱 노드(181)는 시멘틱 노드 탐색 서버(183)의 수신된 주소를 추출한다. 단계 188에서, 새로운 시멘틱 노드(181)는 시멘틱 노드 탐색 요청을 시멘틱 노드 탐색 서버(183)에 송신한다. 단계 188에서의 요청은 새로운 시멘틱 노드(181)가 접속할 수 있는 하나 이상의 부모 시멘틱 노드에 대한 쿼리일 수 있다. 단계 189에서, 시멘틱 노드 탐색 서버(183)는 시멘틱 노드 탐색 응답을 새로운 시멘틱 노드(181)에 송신한다. 단계 189에서의 응답은 하나 이상의 부모 시멘틱 노드를 포함할 수 있다. 단계 190에서, 새로운 시멘틱 노드(181)는 등록할 하나의 부모 시멘틱 노드를 선택한다. 단계 191에서, 시멘틱 노드(181)는 그의 선택된 부모 시멘틱 노드(184)에 등록하기 위한 요청을 송신한다. 단계 192에서, 부모 시멘틱 노드(184)는 단계 191에서의 등록 요청에 대한 응답을 송신한다.

일반적으로, 새로운 시멘틱 노드(181)에 시멘틱 노드 탐색 서버(183)의 주소가 프로비저닝된 경우, 그 새로운 시멘틱 노드는 시멘틱 노드 탐색을 직접 수행할 수 있다. 그렇지 않으면, 새로운 시멘틱 노드(181)는 그것이 하나 이상의 형제로부터 수신된 부모 시멘틱 노드의 목록에서 선택하고자 하는지 여부와 형제로부터 시멘틱 노드 탐색 서버(183)의 디폴트 주소를 검색하고자 하는지 여부를 결정한다. 각 레벨에는, 디폴트로 상위 레벨의 시멘틱 노드 탐색 요청을 수락하는 하나 이상의 시멘틱 노드 탐색 서버가 있을 수 있다. 새로운 시멘틱 노드(181)가 형제의 부모로부터 상위 레벨 시멘틱 노드를 선택하면, 새로운 시멘틱 노드(181)는 시멘틱 노드 탐색을 더 이상 수행하지 않도록 선택할 수 있다. 새로운 시멘틱 노드(181)는 부모를 선택하는(예를 들어, 동일한 유형(들)의 시멘틱 관련 자원 등을 지원하는, 홉 수에 가장 가까운 것과 같은 옵션들 중에서 선택하는) 기준을 결정하는 옵션을 가질 수 있다. 그 기준에 기초하여, 새로운 시멘틱 노드(181)는 상위 레벨의 시멘틱 노드의 주소 외에 그것이 탐색하고자 하는 정보(예를 들어, 시멘틱 관련 자원의 거리, 지원 유형(들) 등)를 설정한다.

도 7은 일 실시예에 따라, 부모-자식 관계의 업데이트 프로세스(예를 들어, 도 5a의 단계 522 및 524의 추가적인 상세 내용을 제공하는 메시지 흐름을 제공한다. 업데이트는 자식 또는 부모 시멘틱 노드에 의해 개시될 수 있다. 단계 205에서, 시멘틱 노드(201)는 통지에 기초하여 현재의 부모 시멘틱 노드(203)로부터 등록 취소하기로 결정한다. 통지는 특히 현재의 부모 시멘틱 노드(203)로부터의 등록 취소를 개시하기 위한 메시지, 현재의 부모 시멘틱 노드(203)가 (예를 들어, 오프라인, 접속해제, 또는 다른 통신 문제)에 도달할 수 없다는 판단, 또는 부모 시멘틱 노드(203)와 관련된 수신 상태 업데이트(예를 들어, 네트워크 트래픽 혼잡, 장치 또는 라인 오류, 메모리 용량 문제 등)일 수 있다.

단계 206에서, 시멘틱 노드(201)는 부모-자식 관계를 종료하기 위한 요청을 포함하는 등록 취소 요청을 현재의 부모 시멘틱 노드(203)에 송신한다. 단계 207에서, 시멘틱 노드(201)는 현재의 부모 시멘틱 노드(203) 또는 현재의 부모 시멘틱 노드(203)의 인식 상태를 전달할 수 있는 다른 장치로부터 단계 206에서 송신된 등록 취소 요청에 대한 응답을 수신할 수 있다. 도 6과 관련하여 예시된 단계들과 마찬가지로, 시멘틱 노드(201)는 새로운 부모 시멘틱 노드에 등록하려고 시도한다. 단계 208에서, 시멘틱 노드(201)는 시멘틱 노드 탐색 요청을 시멘틱 노드 탐색 서버(202)에 송신한다. 단계 209에서, 시멘틱 노드 탐색 서버(202)는 시멘틱 노드 탐색 응답을 시멘틱 노드(201)에 송신한다. 단계 210에서, 시멘틱 노드(201)는 등록할 하나의 상위 레벨 시멘틱 노드를 선택한다. 단계 211에서, 시멘틱 노드(201)는 선택된 그의 새로운 부모 시멘틱 노드(204)에 등록하기 위한 요청을 송신한다. 단계 212에서, 새로운 부모 시멘틱 노드(204)는 부모-자식 관계의 업데이트를 확인하는, 단계 211에서의 등록 요청에 대한 응답을 송신한다.

일 실시예에서 (도시되지는 않지만, 도 7의 구성 요소를 참조하면), 부모 시멘틱 노드는 자식의 등록 취소를 트리거하고 자식이 등록할 새로운 부모 시멘틱 노드를 제공할 수 있다. 이에 대한 새로운 부모 정보는 등록 취소 트리거 메시지에 또는 대안으로 별도의 트리거 메시지에 포함될 수 있다. 시멘틱 노드(201)는 현재의 부모 시멘틱 노드(203)가 등록 요청을 새로운 부모 시멘틱 노드(204)에 송신하게 함으로써 새로운 부모 시멘틱 노드(204)에 등록할 수 있다. 현재의 부모 시멘틱 노드(203)는 등록 목적을 위해 시멘틱 노드(201)의 정보를 새로운 부모 시멘틱 노드(204)에 전송하기 위한 옵션을 갖는다. 현재의 부모 시멘틱 노드(203) 또는 시멘틱 노드(201)는 현재의 부모 시멘틱 노드(203)를 새로운 부모 시멘틱 노드(204)로 전환하기 전에 부모-자식 관계를 종료할 수 있다.

일반적으로, 시멘틱 노드의 부모-자식 관계는 자식 시멘틱 노드가 오프라인 될 때 또는 자식 시멘틱 노드가 다른 상위 레벨 부모 시멘틱 노드에 등록할 때 현재의 부모 시멘틱 노드에의 등록을 취소함으로써 종료된다.

이웃하는 형제 시멘틱 노드가 네트워크에 가입하는 경우, 대응하는 형제 정보는 새로운 시멘틱 노드를 추가함으로써 갱신된다. 이웃하는 형제 시멘틱 노드가 네트워크에서 탈퇴한 경우, 대응하는 형제 정보는 시멘틱 노드를 삭제하거나 그렇지 않고 네트워크에서 탈퇴한 형제 시멘틱 노드의 상태(예를 들어, 상태=오프라인)를 나타내는 표를 업데이트함으로써 업데이트된다. 시멘틱 노드는 방송 또는 그렇지 않고, 예를 들어, 위의 표 1에 제시된 SEMANTICS_NODE_STATUS_NOTIFY() 메시지를 이용하여 그의 상태를 형제 시멘틱 노드로 전달할 수 있다. 상태 업데이트는 형제 및 부모-자식 관계를 유지하는 방법에 영향을 미칠 수 있다.

B. 시멘틱 관련 자원 탐색, 검색, 및 검증

애플리케이션, 장치, 사용자, 피어 시멘틱 노드, 외부 시멘틱 노드, 또는 비시멘틱 노드는 sIc, sIs, 및 sIe 참조 포인트를 통해 시멘틱 관련 자원 탐색 요청을 시멘틱 노드에 송신할 수 있다. 탐색 요청 메시지는 시멘틱 관련 자원(클래스, 관계, 또는 용어) 및 검색 문자열(들)의 유형을 포함할 수 있다. 예를 들면, M2M 시스템에서 섭씨 단위의 정수로서 그의 온도 판독 데이터를 그의 M2M 게이트웨이에 보고해야 하는 온도 감지 애플리케이션(App1)을 가정하자. 게이트웨이 서비스 기능 계층(GSCL)이 그 데이터를 이해할 수 있도록 하기 위해, App1은 그 데이터를 적절한 시멘틱 정보와 연관시킬 필요가 있다. 본 명세서에 기술된 절차에 따라, App1은 온도 데이터를 섭씨 단위의 정수로서 표현하는 시멘틱 관련 자원 클래스인 temperatureReading 클래스를 저장하는 시멘틱 노드를 탐색할 수 있다. 탐색 후, App1은 temperatureReading 클래스의 표현을 검색하고, 그것이 그의 온도 데이터에 대한 시멘틱을 제공하기 위해 사용하고자 하는 것이라는 것을 검증할 것이다. 그런 다음, App1은 그 데이터를 그의 속성(시멘틱 속성)의 하나로서 temperatureReading 클래스와 링크한다. GSCL에서, 그 데이터는 App1의 <tempData> 컨테이너 하에 저장될 수 있으며, 이것은 도 26의 예에 예시된 바와 같이 hasType 관계를 이용하여 temperatureReading 클래스에 링크되는 시멘틱 속성을 가질 것이다. 그 결과, GSCL에서 <tempData> 컨테이너 하에 저장된 App1은 데이터의 각 항목이 정수이고 섭씨 단위를 갖는 동일한 시멘틱을 가질 것이다. 다른 예로, App1은 NSCL에서 자원을 검색하는 애플리케이션일 수 있다. 그 자원은 (위의 예와 유사한) temperatureReading 클래스에 링크되는 시멘틱 속성을 가질 수 있다. 자원의 컨테이너 내의 데이터를 이해 및 해석하기 위해, App1은 자원의 시멘틱 속성이 링크된 시멘틱 관련 자원, 이 경우 temperatureReading 클래스를 검색해야 할 것이다. App1이 temperatureReading 클래스 시멘틱 관련 자원의 표현을 검색한 후, 그것은 이제 그것이 정수이고 섭씨 단위를 갖는다는 것을 알고 있는 자원 데이터를 해석할 수 있을 것이다.

도 8은 일 실시예에 따라, 시멘틱 노드에서의 시멘틱 관련 자원 탐색 요청의 처리를 예시하는 흐름도이다. 블록(221)에서, 시멘틱 노드는 요청된 시멘틱 관련 자원 및 잠재적인 검색 문자열(들)의 유형을 포함하는 시멘틱 관련 자원 탐색 요청을 수신한다. 블록(222)에서, 시멘틱 노드는 탐색 요청을 확인한다. 요청이 불충분하거나 조작된(예를 들어, 요청된 자원의 누락 유형) 경우, 탐색 요청이 유효하지 않은 것으로 간주되고 유효하지 않는 탐색 응답은 블록(233)에 나타낸 바와 같이 (예를 들어, 클라이언트 장치에게 요청한) 발행자에게 반송된다. 요청이 유효한 경우, 블록(223)에 나타낸 바와 같이 검색 문자열은 국지적으로 저장된 시멘틱 관련 자원과 비교된다. 특히, 요청된 시멘틱 관련 자원의 유형에 따라, 시멘틱 노드는 그것이 검색할 시멘틱 관련 자원의 유형(즉, 클래스, 관계, 또는 용어)을 결정할 수 있다. 블록(224)에 나타낸 바와 같이, 검색 문자열(들)을 키워드(들)로 이용하여, 시멘틱 노드는 그의 로컬 시멘틱 데이터베이스를 검색하여 하나 이상의 일치하는 시멘틱 관련 자원을 찾는다. 일치하는 시멘틱 관련 자원이 국지적으로 발견되면, 블록(225)에 나타낸 바와 같이, 탐색 응답시 시멘틱 관련 자원의 주소(예를 들어, URL/URI)가 발행자에게 반송된다.

일치하는 시멘틱 관련 자원이 국지적으로 발견되지 않는 경우, 시멘틱 노드는 그의 형제 시멘틱 노드에서 일치하는 시멘틱 관련 자원을 찾으려고 시도할 것이다. 블록(226) 및 블록(227)에 나타낸 바와 같이, 시멘틱 노드는 탐색 요청을 형제에게 전송하고 돌아올 응답을 기다리는 시간 윈도우를 설정한다. 블록(228)에서, 일치하는 시멘틱 관련 자원이 접촉한 형제에서 발견되는지 여부가 판단된다. 일치하는 시멘틱 관련 자원이 그의 형제로부터 반송된 경우, 시멘틱 관련 자원(들)의 대응하는 주소(예를 들어, URI/URL)는 성공적인 탐색 응답과 함께 발행자에게 재송신된다(블록 225).

시멘틱 노드의 형제로부터 어떠한 일치하는 시멘틱 관련 자원도 반송되지 않는 경우, 블록(229)에 나타낸 바와 같이, 부모 시멘틱 노드가 접촉될 수 있는지 여부가 판단된다. 어떠한 부모 시멘틱 노드도 없는 경우, 부정적인 결과를 나타내는 탐색 응답이 발행자에게 반송될 것이다(블록 233). 부모 시멘틱 노드가 있는 경우, 시멘틱 노드는 그의 부모 시멘틱 노드에서 일치하는 시멘틱 관련 자원을 찾으려고 시도할 것이다. 각각 블록(230) 및 블록(231)에 나타낸 바와 같이, 시멘틱 노드는 탐색 요청을 부모 시멘틱 노드에 전송하고 그것이 돌아올 응답을 기다리는 시간 윈도우를 설정한다. 블록(232)에서, 접촉한 부모로부터 일치하는 시멘틱 관련 자원이 발견되는지 판단된다. 접촉한 부모로부터 일치하는 시멘틱 관련 자원이 반송된 경우, 시멘틱 관련 자원의 대응하는 주소(예를 들어, URI/URL)는 성공적인 탐색 응답과 함께 발행자에게 재송신된다(블록 225). 시멘틱 노드의 부모로부터 어떠한 일치하는 시멘틱 관련 자원도 반송되지 않는 경우, 부정적인 결과를 나타내는 탐색 응답이 발행자에게 반송될 것이다(블록 233).

발행자가 일치하는 시멘틱 관련 자원의 주소(예를 들어, URL/URI)를 포함하는 성공적인 탐색 응답을 수신한 후, 발행자는 시멘틱 관련 자원의 표현을 검색할 수 있다.

일 실시예에서, 시멘틱 노드는 클라이언트 및 서버로 이루어지는 RESTful 아키텍처 스타일(표현 상태 전송)을 지원할 수 있다. 클라이언트(예를 들어, 발행자)는 서버(예를 들어, 시멘틱 노드)로의 시멘틱 요청을 개시한다. 본 실시예에서, 서버(예를 들어, 시멘틱 노드)는 시멘틱에 대한 요청을 처리하고 적절한 시멘틱 응답을 반송한다. 요청 및 응답은 시멘틱 관련 자원의 표현의 전송을 중심으로 만들어진다. 클라이언트는 시멘틱 관련 자원(예를 들어, 클래스, 관계, 또는 용어)에 대한 RESTful 동작을 시멘틱 노드에 요청할 수 있는 애플리케이션, 사용자, 장치, 시멘틱 노드 등일 수 있다.

RESTful 아키텍처에서 자원을 처리할 때, 시멘틱 관련 자원에 적용될 수 있는 다음과 같은 네 가지 기본적인 방법이 있다:

·CREATE: 클래스, 관계, 또는 용어 자원을 생성하기.

·RETRIEVE: 클래스, 관계, 또는 용어 자원의 내용을 판독하기.

·UPDATE: 클래스, 관계, 또는 용어 자원의 내용을 기록하기.

·DELETE: 클래스, 관계, 또는 용어 자원을 삭제하기.

RESTful 서버로 작용하는 시멘틱 노드는 수신된 요청을 검증할 수 있다. 그 동작은 발행자가 적절한 액세스 권한을 허가받은 경우에 허용된다.

도 9는 본 RESTful 실시예에 따라 이러한 RESTful 시멘틱 노드 동작을 더 예시하는 메시지 흐름도이다. 단계 243에서, 발행자(241)는 시멘틱 관련 자원(클래스, 관계, 또는 용어)을 그에 대응하여 RESTful CREATE, UPDATE, RETRIEVE, 또는 DELETE 동사를 이용하여 생성, 업데이트, 검색, 또는 삭제하도록 요청한다. 발행자(241)는 애플리케이션, 다른 시멘틱 노드, 장치, 또는 사용자 등일 수 있다. 단계 243에서 시멘틱 관련 자원을 생성하기 위해, 발행자(241)는 시멘틱 관련 자원의 유형 및 표현을 제공하는 CREATE 요청을 발행한다. 단계 243에서 시멘틱 관련 자원을 업데이트하기 위해, 발행자(241)는 시멘틱 관련 자원의 고유 식별 및 주소 및 업데이트된 또는 부분적으로 업데이트된 표현을 제공하는 UPDATE 요청을 발행한다. 단계 243에서 시멘틱 관련 자원을 검색하기 위해, 발행자(241)는 시멘틱 관련 자원의 고유 식별 또는 주소 및 임의로 searchString 파라미터(들)를 제공하는 RETRIEVE 요청을 발행한다. 단계 243에서 시멘틱 관련 자원을 삭제하기 위해, 발행자(241)는 시멘틱 관련 자원의 고유 식별 또는 주소를 제공하는 DELETE 요청을 발행한다.

단계 244에서, 시멘틱 노드(242)는 서버로 작용하고 수신된 요청을 검증 및 그렇지 않고 처리한다. 수신된 요청은 발행자(241)가 적절한 액세스 권한을 허가받은 경우에 허용된다. 시멘틱 노드(242)에 의해 생성 동작이 허용된 경우, 새로운 시멘틱 관련 자원이 클래스, 관계, 또는 용어인지에 따라 적절한 자원 풀 하에서 그 자원이 생성된다. 그리고 시멘틱 관련 자원에는 시멘틱 노드(242)에 의해 고유 식별 또는 주소가 부여된다. 시멘틱 노드(242)에 의해 업데이트 동작이 허용된 경우, 시멘틱 관련 자원의 표현이 업데이트된다. 시멘틱 노드(242)에 의해 검색 동작이 허용된 경우, 시멘틱 관련 자원의 표현이 발행자(241)가 요청한 포맷으로 작성된다. 시멘틱 노드(242)에 의해 삭제 동작이 허용된 경우, 요청된 시멘틱 관련 자원이 삭제된다.

단계 245에서, 시멘틱 노드(242)는 발행자(241)에게 응답을 반송한다. 생성 동작을 위해, 새로 생성된 시멘틱 관련 자원의 식별 또는 주소가 발행자에게 반송된다. 업데이트 동작을 위해, 그 동작이 성공적인지 여부에 대한 응답 코드가 발행자(241)에게 반송된다. 검색 동작을 위해, 발행자(241)가 요청한 포맷의 시멘틱 관련 자원의 표현이 발행자(241)에게 반송된다. 삭제 동작을 위해, 그 동작이 성공적인지 여부를 나타내는 응답 코드가 발행자(241)에게 반송된다.

도 10은 본 명세서에 기술된 시멘틱 관련 자원의 탐색, 검색, 및 검증 프로세스를 더 예시하는 메시지 흐름(250)이다. 본 예에서, 네트워크는 발행자(251), 시멘틱 노드(252), 시멘틱 노드(252)의 형제인 형제 시멘틱 노드(253), 및 시멘틱 노드(252)의 부모인 부모 시멘틱 노드(254)를 포함할 수 있다. 단계 256에서, 발행자(251)는 시멘틱 관련 자원 탐색 요청을 시멘틱 노드(252)에 송신한다. 메시지 흐름(250)에 도시된 바와 같이, 시멘틱 노드(252)는 단계 256에서의 요청과 일치하는 시멘틱 관련 자원(들)을 찾기 위해 (도 8의 프로세스와 유사한) 여러 단계를 거친다. 예시된 바와 같이, 먼저 시멘틱 노드(252)는 그의 로컬 디렉토리를 검색할 것이다. 그 시멘틱 노드가 어떠한 일치하는 자원도 찾지 못하는 경우, 그것은 시간 윈도우를 설정하고 탐색 요청을 형제(253)와 같은 그의 형제들에게 전송할 것이다. 그의 형제들로부터 어떠한 응답도 수신되지 않는 경우, 시멘틱 노드(252)는 그의 요청을 부모 시멘틱 노드(254)로 전송할 수 있다. 본 예에서는, 부모 시멘틱 노드(254)가 일치하는 자원을 찾은 것으로 가정하고, 그 부모 시멘틱 노드는 그것이 찾은 시멘틱 관련 자원(들)의 주소(예를 들어, URI/URL)를 나타내는 응답을 시멘틱 노드(252)에 송신할 것이다.

단계 257에서, 시멘틱 노드(252)는 발행자의 요청(251)과 일치한 부모 시멘틱 노드(254)로부터의 시멘틱 관련 자원(들)의 주소(예를 들어, URI/URL)를 포함하는 시멘틱 관련 자원 탐색 응답을 발행자(251)에게 송신한다. 단계 259에서, 발행자(251)는 수신된 URL에 따라 시멘틱 관련 자원 검색 요청을 송신한다. 단계 260에서, 부모 시멘틱 노드(254)는 클래스, 관계, 또는 용어를 포함할 수 있는 요청된 시멘틱 정보를 포함하는 시멘틱 관련 자원 탐색 응답을 송신한다.

단계 261에서, 발행자(251)는 단계 260에서 수신된 시멘틱 정보 표현을 확인(검증)한다. 단계 260에서 송신되어 수신된 시멘틱 관련 자원은 발행자(251)가 정확히 원하는 것이 아닐 가능성이 있다. 예를 들면, 발행자(251)가 온도 클래스를 요청하였고 반송된 일치하는 자원이 연관된 단위가 화씨인 temperatureReading이라는 클래스이지만, 발행자(251)가 섭씨 단위를 갖는 온도 클래스를 원하는 경우, 발행자(251)는 부모 시멘틱 노드(254)가 시멘틱을 수정할 것을 요청할 수 있다. 이것은 단계 262에서 시멘틱 관련 자원을 수정하기 위한 시멘틱 관련 자원 수정 요청을 부모 시멘틱 노드(254)에 송신함으로써 지원될 수 있다. 단계 263에서, 새로 추가되거나 수정된 시멘틱 관련 자원의 주소(예를 들어, URL/URI)가 발행자(251)에게 반송될 것이다.

시멘틱 관련 자원의 수정과 관련하여, 일반적으로, 시멘틱 노드가 수정을 자체적으로 지원하지 않는 경우, 시멘틱 노드는 수정을 수행하기 위해 그의 형제 또는 부모와 협력할 수 있다. 시멘틱 노드가 수정을 지원하는 경우, 시멘틱 노드는 새로운 클래스를 추가하거나 현재의 것을 확장함으로써 국지적으로 클래스를 수정할 수 있다.

C. 시멘틱 관련 자원에의 가입

일 예에서, 시멘틱 노드는 그것에 가입하는 클라이언트(예를 들어, 애플리케이션, 다른 시멘틱 노드, 장치, 또는 사용자 등)를 지원할 수 있다. 일례로, 클라이언트는 시멘틱 노드에 가입하여 가입된 시멘틱 관련 자윈에 대한 업데이트가 있을 때 통지받을 수 있다. 업데이트 발생시, 가입 클라이언트는 자원의 새로운 표현을 통지받을 것이다. 클라이언트가 시멘틱 노드 자체인 경우, 가입된 시멘틱 관련 자원은 가입자 시멘틱 노드와 관련이 없는(예를 들어, 부모-자식 또는 형제가 아닌) 다른 시멘틱 노드에 저장될 수 있다. 본 예에서, 클라이언트는 SEMANTICS_RESOURCE_SUBSCRIBE_REQ 메시지를 시멘틱 노드에 발행할 수 있다. 이 메시지는 클라이언트가 자원의 업데이트시 통지를 받고자 하는 시멘틱 관련 자원을 식별한다. 시멘틱 노드는 가입을 확인응답하는 SEMANTICS_RESOURCE_SUBSCRIBE_RESP 메시지로 요청에 응답할 것이다. 클라이언트가 가입한 시멘틱 관련 자원이 업데이트된 경우, 시멘틱 노드는 SEMANTICS_RESOURCE_SUBSCRIBER_NOTIFY 메시지를 송신하여 그 업데이트를 클라이언트에게 통지할 것이다.

또 다른 예로, 시멘틱 노드는 그의 형제, 부모, 또는 자식 시멘틱 노드 중 하나에 의해 저장 및 관리되는 시멘틱 관련 자원으로 업데이트되는데 관심이 있을 수 있다. 도 11은 일 예에 따라 이러한 상황에 대한 가입/통지 처리의 예시적인 흐름(270)이다. 본 예에서, 시멘틱 노드(271)는 가입 시멘틱 노드(subscribed-to semantics node)(272)에 의해 저장 및 관리되는 시멘틱 관련 자원으로 업데이트된다. 가입 시멘틱 노드(272)는 시멘틱 노드(271)의 형제, 부모, 또는 자식일 수 있다. 단계 273에서, 시멘틱 노드(271)는 가입 대상을 식별하고 그것이 트리거 기준과 관련된 시멘틱 관련 자원 통지만 수신하도록 통지 트리거 기준을 설정할 수 있다. 예를 들면, 가입자는 새로운 통지가 송신되기 전에 특정 시멘틱 관련 자원 또는 시멘틱 관련 자원에 대한 특정 업데이트 횟수를 지정하기 위해 통지 트리거 기준을 구성할 수 있다. 시멘틱 노드(271)는 또한 통지를 송신해야 할 시간 케줄링 정보를 설정할 수 있다.

단계 274에서, 시멘틱 노드(271)는 시멘틱 노드 자원 가입 요청을 타겟 시멘틱 노드(272)에 송신한다. 단계 275에서, 타겟 시멘틱 노드(272)는 단계 274의 시멘틱 가입 요청을 수락할지 여부를 판단한다. 타겟 시멘틱 노드(272)는 기존 가입자, 가입 처리 로드(예를 들어, 업데이트 정보의 수집과 관련된 로드 또는 통지를 송신하는데 사용되는 대역폭) 등에 기초하여, 가입 요청을 수락할지 여부를 결정할 수 있다. 단계 276에서, 타겟 시멘틱 노드(272)는 시멘틱 노드 가입 응답을 시멘틱 노드(271)에 송신한다. 단계 276에서의 응답은 가입의 확인 및 가입을 처리하는데 사용될 파라미터를 포함할 수 있다. 단계 277에서, 단계 276 후 어느 시점에, 타겟 시멘틱 노드(272)는 단계 274에서 수신된 요청된 트리거와 일치하는 시멘틱 통지 트리거의 상태를 검출한다. 단계 278에서, 타겟 시멘틱 노드(272)는 특정 시멘틱 관련 자원과 관련하여 시멘틱 노드(271)를 업데이트하기 위해 시멘틱 노드 자원 가입 통지 메시지를 송신한다.

일반적으로, 시멘틱 관련 자원 가입은 피어 시멘틱 노드 또는 부모 시멘틱 노드에서 시멘틱 관련 자원 탐색을 용이하게 할 수 있다. 예를 들면, (시멘틱 노드에 저장된 새로 생성되거나 업데이트된 시멘틱 관련 자원의 URI를 포함하는) 통지 메시지에 기초하여, 시멘틱 노드는 탐색 요청을 송신하지 않고도 다른 노드들의 시멘틱 관련 자원에 대해 탐색을 수행할 수 있다.

D. 시멘틱 관련 자원과의 링킹 및 연관성

시멘틱 노드의 시멘틱 관련 자원은 다양한 방식으로 이용될 수 있다. 예를 들면, 시멘틱 관련 자원 표현들은 시멘틱 노드에서 검색될 수 있고 데이터가 (예를 들어, 네트워크 서버에, 장치에, 게이트웨이 등에) 저장된 네트워크 장소에 공동 배치된 방식으로 저장될 수 있다. 대안으로, 자원의 시멘틱은 시멘틱 노드에 저장될 수 있고 시멘틱과의 링크는 데이터와 함께 공동 배치 및 저장될 수 있다. 이러한 시멘틱 링크는 데이터 내에 인라인으로 저장(즉, 삽입)될 수 있거나 데이터와 함께 별도로(예를 들어, 별도의 자원 또는 속성으로) 저장될 수 있다. 따라서, 이와 같은 시멘틱 관련 자원과의 링크를 통해, 시멘틱은 M2M 시스템에서 일반 자원(예를 들어, <SCL>, <application>, <container> 등)에 적용될 수 있다. 전형적으로, 이러한 링킹은 자원 생성시 자원 생성기/발생기에 의해 생성될 것이다.

도 1의 환자 건강 모니터링 애플리케이션의 이전의 예를 계속하면, 시멘틱 노드에 대해 정의된 시멘틱 클래스가 있으며 이들 클래스의 URL은 환자 건강 모니터링 애플리케이션에 의해 탐색될 수 있다. 표 2는 환자 건강 모니터링 애플리케이션과 관련된 "클래스" 유형의 시멘틱 관련 자원의 예를 제시한다. 데이터는 hasType으로 불리는 시멘틱 관계를 이용하여 이러한 시멘틱 클래스에 링크될 수 있다. 그 결과, example/healthmonitoring/data1의 URI를 갖는 각 데이터 자원에 대해, 자원의 시멘틱은 다음의 연관성에 의해 알려질 것이다:

또한 hasType 관계는 시멘틱 노드에 저장된 hasType 관계의 시멘틱 설명을 참조하는 URL/URI에 의해 식별될 수 있다.

E. 그룹화 최적화

한 그룹의 자원이 일부 유사한 시멘틱을 갖는 경우(예를 들어, 동일한 애플리케이션의 모든 자원이 동일한 시멘틱을 갖는 경우), 유사한 시멘틱은 그 애플리케이션 하에 있는 각 개별 자원 대신 그 애플리케이션에 적용될 수 있다. 도 12는 그의 일 예에 따라, 동일한 시멘틱을 갖는 자원을 그룹화하는 방법(281)을 예시한다. 단계 281에서, 동일한 애플리케이션의 기존 데이터의 일부는 동일한 시멘틱 연관성을 공유하기로 결정된다. 단계 282에서, 동일한 시멘틱을 공유하는 동일한 애플리케이션에서 결정된 데이터는 그룹으로 분류된다. 단계 283에서, 단계 282의 각 그룹은 적절한 시멘틱과 연관된다. 단계 284에서, 동일한 애플리케이션에서 새로 수신된 데이터는 동일한 시멘틱을 공유하는 그룹에 넣는다. 동일한 애플리케이션의 기존 데이터는 그룹으로 분류될 수 있으며, 그 각각은 동일한 시멘틱 링킹 및 연관성을 공유한다. 새로운 데이터가 동일한 애플리케이션에서 생성되는 경우, 그 데이터는 동일한 시멘틱을 공유하는 그룹에 넣는다.

예를 들면, 혈압 모니터링 데이터의 다수의 인스턴스는 동일한 시멘틱을 갖는다. 따라서, 각 인스턴스는 아래에 제시된 바와 같이 동일한 시멘틱(semanticsNode1/class/bloodpressure)과 연관될 수 있다 :

이와 같은 그룹화 최적화를 지원함으로써, 다음과 같은 연관성도 유효할 수 있다.

F. 시멘틱 관련 자원 푸싱

전술한 바와 같이, 시멘틱 노드에 호스트된 클래스, 관계, 및 용어는 다른 시멘틱 노드들에 의해 탐색 및 사용될 수 있다. 요청 빈도에 따라, 시멘틱 관련 자원의 일부는 좀 더 용이한 탐색 및 액세스를 위해 다른 시멘틱 노드로 푸시되거나 미러링(mirror)될 수 있다. 예를 들면, 하나의 시멘틱 노드가 다른 시멘틱 노드로부터 전송된 동일한 탐색 요청을 소정 횟수(예를 들어, 정책 정의 임계치(policy defined threshold)를 초과하여) 검출한 후, 그것은 시멘틱 관련 자원의 미러링된 사본(mirrored copy)을 그 시멘틱 노드로 푸시하기로 결정할 수 있다.

시멘틱 관련 자원 푸싱은 도 13에 도시된 바와 같이 형제간, 또는 부모와 자식 노드 간에서 일어날 수 있다. 예를 들면, 코어 네트워크(295)에서 도 13의 시멘틱 노드(291)는 시멘틱 노드(292), 시멘틱 노드(293), 및 시멘틱 노드(294)로부터 동일한 시멘틱 관련 자원(예를 들어, 온도)에 대한 많은 탐색 및 검색 요청을 수신할 수 있다. 탐색 요청이 정의된 임계치에 도달하면, 시멘틱 노드(291)는 시멘틱 노드(293) 및 시멘틱 노드(294)가 더 빠른 응답 시간을 갖고 시멘틱 관련 자원을 액세스할 수 있도록 시멘틱 노드(292) 상에 동일한 시멘틱 관련 자원을 생성(즉, 그 자원을 미러링)하기로 결정할 수 있다. 시멘틱 노드(291)는 나중에 적절한 SEMANTICS_RESOURCE_CREATE_RESP 메시지로 응답할 다른 시멘틱 노드들에 SEMANTICS_RESOURCE_CREATE_REQ 메시지를 발행함으로써 시멘틱 노드(들) 상에 미러링된 자원을 생성할 수 있다.

시멘틱 관련 자원을 최신으로 유지하기 위해 다음과 같은 옵션이 사용될 수 있다. 도 13을 참조하면, 시멘틱 노드(291)는 시멘틱 관련 자원의 원래 표현에 대해 임의의 업데이트가 있는(예를 들어, 가입이 필요하지 않는) 경우 시멘틱 노드(292) 상의 시멘틱 관련 자원을 자동으로 업데이트할 수 있다. 대안으로, 시멘틱 노드(292)는 원래 시멘틱 관련 자원에 가입할 수 있다. 시멘틱 노드(292)가 시멘틱 관련 자원에 가입하는 것에 기초하여, 시멘틱 노드(292)는 시멘틱 관련 자원에 가입된 세부 사항에 대한 모든 변경을 통보받을 것이다. 또한 전술한 시나리오의 조합도 있을 수 있다. 예를 들면, 시멘틱 노드(292)가 시멘틱 관련 자원에 가입된 세부 사항에 대해 더 즉각적인 업데이트를 원하는 동안, 시멘틱 노드(291) 상의 모든 시멘틱 관련 자원에 대해 시멘틱 노드(291)의 자동 업데이트가 주기적으로 일어나는 상황이 있을 수 있다.

시멘틱 관련 자원 푸싱은 형제 간에, 또는 부모와 자식 간에 어느 방향으로든 일어날 수 있다. 예를 들면, 도 13을 참조하면, 시멘틱 노드(296)는 어떤 로컬 시멘틱 관련 자원을 그의 부모 시멘틱 노드(297)로 푸시할 수 있다. 다른 예에서, 시멘틱 노드(291)는 어떤 상위 레벨 시멘틱 관련 자원을 그의 자식 시멘틱 노드(298)로 푸시할 수 있다.

G. 데이터/시멘틱 관련 자원 이동

도 14는 어떤 장치가 하나의 네트워크에서 다른 네트워크로 이동하는 시나리오를 예시한다. 이 시나리오에서는, 장치와 관련된 시멘틱 자원 및 그 장치에 의해 생성된 데이터 역시 시멘틱 자원 검색으로 인한 보안, 오버헤드 및/또는 로딩을 위해 새로운 위치로 이동될 필요가 있을 수 있다.

도 14를 참조하면, 장치는 처음에 지역 네트워크(301)에 배치되었을 수 있지만, 이제 지역 네트워크(302)로 이동하였다. 처음에, 장치(309)는 시멘틱 노드(306)와 통신한다. 장치(309)가 지역(302)에 도달한 후, 장치(309)는 처음에 라인(303)에 나타낸 바와 같이, 시멘틱 노드(306)와 지속적으로 통신할 수 있다. 이는 결과적으로 액세스 네트워크(304), 액세스 네트워크(308), 및 코어 네트워크(300)에서 불필요한 오버헤드를 초래할 수 있다. 이와 같은 문제 및 다른 문제를 해결하기 위해, 시멘틱 노드(306)의 시멘틱 관련 자원은 지역 네트워크(302) 내의 시멘틱 노드(307)로 이동될 수 있다. 시멘틱 관련 자원을 시멘틱 노드(307)로 이동한 후, 장치(309)는 시멘틱 관련 자원에 대해 코어 네트워크(300)를 횡단할 필요가 없고, 대신에 이제 라인(305)에 나타낸 바와 같이 시멘틱 노드(307)와 통신할 수 있다.

도 15는 도 14에 도시된 바와 같은 데이터 또는 시멘틱 관련 자원의 이동을 더 예시하는 일례의 메시지 흐름(310)이다. 단계 315에서, 제1 지역 네트워크 내의 시멘틱 노드(311)는 지역 네트워크(2)에 배치된 장치 애플리케이션(314)과 메시지를 교환한다. 단계 315에서 교환된 메시지는, 예를 들어, 시멘틱 관련 자원 검색 요청 및 시멘틱 관련 자원 탐색 응답을 포함할 수 있다. 단계 316에서, 시멘틱 노드(311)는 장치 애플리케이션(214)과 연관된 시멘틱 관련 자원을 제2 지역 네트워크에 배치된 시멘틱 노드(313)로 이동하기로 결정한다. 시멘틱 노드(313)는 제1 지역 네트워크보다 통신적으로 더 근접할 수 있거나(도달 시간이 덜 걸리거나) 논리적으로 더 근접할(예를 들어, 홉(hop)이 더 적을) 수 있다. 단계 316을 참조하면, 다른 장치는 시멘틱 노드 탐색 서버(312), 장치 애플리케이션(314), 또는 다른 컴퓨팅 장치(미도시)와 같은 시멘틱 관련 자원을 이동하기로 결정할 수 있다.

단계 317에서, 형제 관계뿐 아니라, 시멘틱 노드의 계층을 구축하기 위해 시멘틱 노드(311)와 시멘틱 노드 탐색 서버(312) 간에는 시멘틱 노드 탐색 요청 및 응답이 교환된다. 단계 318에서, 시멘틱 노드(311)는 시멘틱 노드(313)의 주소를 결정한다. 단계 320에서, 장치 애플리케이션(314)에 의해 사용되는 시멘틱 관련 자원(및 다른 데이터)을 복사하기 위해 시멘틱 관련 자원 생성 요청 메시지가 시멘틱 노드(313)에 송신된다. 시멘틱 노드(313)는 시멘틱 관련 자원 및 다른 데이터가 성공적으로 복사되었다는 확인응답을 포함할 수 있는 시멘틱 관련 자원 생성 응답 메시지로 응답한다. 단계 321에서, 시멘틱 링크 업데이트 요청 메시지가 장치 애플리케이션(314)에 송신된다. 단계 321에서의 메시지는 장치 애플리케이션(314)이 시멘틱 노드(313)에서 시멘틱 관련 자원을 검색하기 위한 명령을 포함할 수 있다. 단계 322에서, 시멘틱 링크 업데이트 응답 메시지는 시멘틱 노드 링크가 업데이트되었다는 확인응답을 포함할 수 있다. 단계 323에서, 장치 애플리케이션(314)은 시멘틱 노드(313)에서 시멘틱 관련 자원을 클래스, 관계, 및 용어의 유형별로 검색한다.

V. ETSI M2M/oneM2M 예들

A. 시멘틱 노드를 갖는 ETSI M2M 아키텍처

전술한 바와 같이, 본 명세서에 기술된 시멘틱 노드 개념은 ETSI M2M 아키텍처를 향상시키는데 사용될 수 있다. 일 예에서, 도 16에 도시된 바와 같이 M2M 시멘틱 노드로 불릴 수 있는 독립형 네트워크 엔티티인 하나 이상의 시멘틱 노드가 액세스/코어 네트워크에 배치될 수 있다. 도 16에서, M2M 시멘틱 노드(331) 및 M2M 시멘틱 노드(332)는 동일한 액세스/코어 네트워크(330)에 배치된다. 지역/코어 네트워크(330) 내의 M2M 시멘틱 노드 M2M(331) 및 M2M 시멘틱 노드(332)는 전술한 sIc 참조 포인트를 통해 DSCL, GSCL, NSCL, 및 애플리케이션과 인터페이스할 수 있다. 또한, M2M 시멘틱 노드(331) 및 M2M 시멘틱 노드(332)는 sIs 참조 포인트(334)를 통해 서로 인터페이스할 수 있다. M2M 시멘틱 노드(331) 및 M2M 시멘틱 노드(332)는 또한 sIe 참조 포인트를 통해 다른 형태의 외부 시멘틱 노드(333)를 참조할 수 있다. 본 예에서, 액세스/코어 네트워크(330)에 배치된 M2M 시멘틱 노드들은 또한 형제 및/또는 부모-자식 관계를 형성할 수 있다.

시멘틱 노드는 현재의 ETSI M2M 아키텍처의 서비스 기능 계층(xSCL)에 사용된 바와 같은 상보적 자원 구조를 지원할 수 있으며, 이러한 자원 구조는 도 17에 예시된 방식으로 본 명세서에 기술된 시멘틱 노드에 적용될 수 있다. 본 예에서, <ssBase> 자원(341)은 호스팅 시멘틱 노드에 상주하는 자원 트리의 루트(root)이다. <ssBase> 자원(341)은 호스팅 시멘틱 노드를 기술하는 속성들을 포함할 수 있다. <ssBase> 자원(341)은 특히 SS 자원(343), 클래스 자원(344), 관계 자원(346), 용어 자원(348), 액세스권한(accessRights) 자원(349), 및 가입 자원(350)의 집합을 나타내는 집합 자원을 포함한다. 클래스 자원(344) 하에는, 클래스 자원(344)의 하위 클래스인 다른 <class> 자원(345)이 있을 수 있다. 관계 자원(346) 하에는, 관계 자원(346)의 하위 관계인 다른 <relationship> 자원(347)이 있을 수 있다. SS들 자원 집합(343)은 원격 시멘틱 노드가 로컬 시멘틱 노드에 등록하거나 등록 취소할 때 생성되거나 삭제되는 시멘틱 노드 자원을 포함한다.

도 18에 도시된 바와 같이, SS들 자원(343)의 집합 내의 각각의 시멘틱 노드 자원은 대응하는 자원 구조를 가질 수 있다. 이러한 자원은 로컬 시멘틱 노드에 등록된 원격 시멘틱 노드의 상태를 유지한다. 예를 들면, 연락처 주소 정보, 탐색 정보(예를 들어, 알려진 시멘틱 클래스, 표현, 및 용어 자원), 및 보안 정보(예를 들어, 대응하는 원격 시멘틱 노드와 통신하는데 사용되는 자격증명)와 같은 상태.

다시 도 17을 참조하면, <ssBase> 자원(341) 하의 클래스(344), 관계(346), 및 용어(348) 집합은 각각 로컬 시멘틱 노드에 호스트된 시멘틱 관련 자원의 각 인스턴스를 포함할 수 있다. 각 인스턴스는 시멘틱 표현을 포함할 뿐 아니라 태그와 같은 탐색 관련 정보와 같은, 그와 연관된 다른 속성을 가질 수 있다. 이러한 시멘틱 관련 자원의 집합은 그렇게 하기에 적절한 액세스 권한을 갖는 클라이언트에 의해 액세스될 수 있다. <ssBase> 자원(341) 하의 액세스권한 자원(349)은 액세스권한 자원들의 인스턴스들(instances of accessRight resources)을 포함할 수 있다. 이러한 액세스권한 자원(349)은 시멘틱 노드에 의해 지원되는 시멘틱 관련 자원 및 동작에 대한 액세스 권한을 부여받은 클라이언트를 제어하는 액세스권한의 인스턴스를 정의할 수 있다. 대안으로, (도 17에 도시되지 않은) 미세 액세스 제어(finer grain access controls)를 제공하기 위해 액세스권한 집합의 다른 인스턴스가 자원 구조에서 지원될 수 있다. 가입 자원(350)의 집합은 가입 자원의 인스턴스를 포함할 수 있다. 가입 자원의 인스턴스는 지정된 통지 트리거 기준 이벤트가 발생할 때 시멘틱 노드에서 시멘틱 통지를 수신하고자 하는 클라이언트에 의해 생성될 수 있다. 탐색 자원(342)은 클라이언트 시멘틱 탐색 요청을 지원한다. 이러한 탐색 요청은 검색 기준(예를 들어, 특정 유형의 속성을 갖는 시멘틱 관련 자원)을 지원할 수 있다. 시멘틱 노드는 (만일 있다면) 검색 기준과 일치하는 자원 주소(예를 들어, URI)의 목록으로 탐색 요청에 응답할 수 있다. 시멘틱 노드는 또한 다른 시멘틱 노드로의 요청 전송(예를 들어, 자식, 형제, 또는 부모 시멘틱 노드로의 탐색 요청 전송)을 지원할 수 있다.

B. 시멘틱 기능을 갖는 xSCL

도 19에 예시된 또 다른 예에서, M2M 시멘틱 노드는 별도의 독립형 시멘틱 노드로라기보다 ETSI M2M 아키텍처의 DSCL, GSCL, 및/또는 NSCL 내에 내장된 기능으로 배치될 수 있다. 이러한 내장된 예에서, sIs 참조 포인트는 별도로 유지되거나 ETSI M2M mId 참조 포인트는 sIs 기능을 지원하도록 향상될 수 있다. 마찬가지로, sIc 참조 포인트는 별도로 유지되거나, ETSI M2M mIa 및 dIa 참조 포인트는 sIc 기능을 지원하도록 향상될 수 있다. 본 예에서, GSCL 또는 DSCL에 배치된 M2M 시멘틱 노드들은 이들이 등록된 NSCL(들)과 부모-자식 관계를 확립할 수 있다. 또한, GSCL 또는 DSCL에 배치된 시멘틱 노드들은 또한 서로 형제 관계를 확립할 수 있다.

도 19의 예를 지원하기 위해, xSCL은 도 20에 도시된 자원 구조를 가질 수 있다. 시멘틱 노드의 자원 집합은 시멘틱 노드 기능을 갖는 원격 SCL이 로컬 SCL에 등록 또는 등록 취소할 때 생성되거나 삭제되는 시멘틱 노드 자원을 포함한다. 이러한 집합에서 각각의 시멘틱 노드 자원은 도 20에 도시된 바와 같이 대응하는 자원 구조를 가질 수 있다. 이러한 자원은 로컬 SCL에 등록된 원격 시멘틱 노드의 상태를 유지한다. 예를 들면, 시멘틱 탐색 정보(예를 들어, 알려진 시멘틱 클래스, 표현, 및 용어 자원) 등과 같은 상태.

<sclBase> 자원(361) 하의 클래스, 관계, 및 용어 집합은 각각 로컬 SCL에 호스트된 시멘틱 관련 자원의 각 인스턴스를 포함할 수 있다. <Sscl>은 본 명세서에 기술된 바와 같이 시멘틱 관련 자원들의 루트의 이름으로서 이용된다. 루트들을 예시적인 명명이고 본 명세서에 기술된 바와 같이 명명되지 않아도 된다. 각각의 인스턴스는 시멘틱 표현을 포함할 뿐 아니라, 태그와 같은 탐색 관련 정보와 같은 그와 연관된 다른 속성을 가질 수 있다. 이러한 시멘틱 관련 자원 집합은 그렇게 하기에 적절한 액세스 권한을 갖는 클라이언트에 의해 액세스될 수 있다.

C. ETSI M2M 시멘틱 구현의 사용 사례예

시멘틱 노드에 의해 관리되는 시멘틱 관련 자원은 <sclBase>, <application>, <container>, 및 <contentInstance> 등과 같은, ETSI M2M 자원 구조의 자원과 연관 및 링크될 수 있다. 다음의 설명은 시멘틱 관련 자원이 <contentInstance>에 대한 시멘틱 정보를 제공하는데 사용될 수 있는 방법을 예시한다.

본 예에서는, scl1에 대해 temperatureReading 클래스가 정의 및 저장되고, scl1/classes/temperatureReading의 URI를 갖는다고 가정한다. scl1에 대해 관계 hasLocation 역시 정의 및 저장되고, scl1 /relationships/ hasLocation의 URI를 갖는다. 또한, scl1에 대해 용어 'northeast China'도 정의 및 저장되고, scl1/terms/northeastChina의 URI를 갖는다. 도 21은 도 20에 도시된 xSCL 자원 구조의 일례인 <scl1>에 대한 시멘틱 관련 자원 구조를 도시한다. 이러한 자원 구조는 시멘틱 관련 자원의 URI를 결정한다. contentInstance는 gscl2/applications/app1/containers/<temperature>/contentInstances/<inst1>의 URI를 갖는다. 도 22의 xSCL 자원 구조에 도시된 바와 같은 시멘틱으로 contentInstance을 향상시킴으로써, contentInstance의 내용은 모호함이 없이 효율적으로 기술 및 해석될 수 있다.

도 23은 자원 및 시멘틱 검색의 일례를 예시하는 메시지 흐름이다. 단계 393에서, NA(390)는 데이터 자원에 대한 검색 요청(RETRIEVE request)을 GSCL2(391)에 송신한다. 데이터 자원은 특히, 예를 들어, 혈압 센서 판독, 심부 체온 센서 판독, 산소 포화도 센서 판독, 또는 모션 가속도계 센서 판독일 수 있다. 단계 394에서, GSCL2(391)는 데이터 자원의 표현을 반송한다. 데이터 자원을 이해하기 위해, NA는 데이터 자원의 시멘틱을 검색할 필요가 있다. 따라서, 단계 395에서, NA(390)는 검색 요청을 GSCL(391)에 송신한다. 단계 396에서, GSCL2(391)는 SCL1(392)에 저장된 데이터 자원에 대해 관련된 시멘틱 관련 자원의 URI 목록을 반송한다. 단계 397 내지 399에서, NA(390)는 각각 시멘틱 관련 자원들 temperatureReading, hasLocation 및 northeastChina에 대한 검색 메시지들을 SCL1(392)와 교환한다. 이러한 시멘틱 관련 자원을 이용하여, NA(390)는 데이터 자원을 이해할 수 있고, 따라서 데이터 자원을 이용 및 조작할 수 있다.

VI. 3GPP MTC 아키텍처 예들

앞에서 더 언급된 바와 같이, 3GPP MTC 아키텍처는 또한 본 명세서에 기술된 시멘틱 노드에 의해 제공된 시멘틱 지원으로 향상될 수 있다. 도 24에 도시된 바와 같이, 일 예에서, M2M 시멘틱 노드(401)는 3GPP 코어 네트워크 경계 외부에 배치될 수 있다. 더 도시된 바와 같이, SCS(404)는 시멘틱 기능을 지원하도록 향상될 수 있으며, sIs 참조 포인트(미도시)를 통해 M2M 시멘틱 노드(401)와 인터페이스 할 수 있다. M2M 시멘틱 노드(401)는 또한 sIc 참조 포인트(403)를 통해 3GPP 기계형 통신 상호연동 기능(MTC-IWF)(402)과 인터페이스할 수 있다. 애플리케이션 서버(AS)(406) 및 AS(407)는 sIc 참조 포인트(400)를 통해 M2M 시멘틱 노드(401)와 통신할 수 있다. 도 25는 시멘틱 노드를 갖는 3GPP MTC 아키텍처에 대한 또 다른 예를 예시한다. 본 예에서, 시멘틱 노드는 SCS(408)에 통합되었다. 도 25에서 409로 더 도시된 바와 같이, 본 예에서, sIc 참조 포인트는 3GPP MTC Tsp의 일부일 수 있다.

온톨로지 언어

시멘틱 웹은 용어 모음(vocabulary)들, 분류(taxonomy)들, 및 온톨로지들의 기능들을 제공하기 위해 스키마 언어 및 온톨로지 언어의 조합을 이용한다고 말할 수 있다. 용어 모음은 통신에서 사용되는 명료하게 정의된 용어들의 집합으로 간주될 수 있다. 분류는 용어들이 계층적 방식으로 조직되는 용어 모음으로 간주될 수 있다. 각각의 용어는 분류에서 하나 이상의 다른 요소와 부모-자식 관계를 공유할 수 있다. 온톨로지는 사전 정의된, 예약된 용어 모음의 용어들을 사용하여 특정 관심 지역, 또는 그 이상에 대해 그들 사이의 관계들 및 개념들을 정의한다. 온톨로지는 실제로는 용어 모음, 분류, 또는 그 이상의 어떤 것을 지칭할 수 있다. 전형적으로 그 용어는 지식 도메인을 기술하기 위한 풍부한, 형식적 논리 기반 모델을 지칭한다. 온톨로지들을 이용하여, 용어 모음 용어들 배후의 시멘틱, 그들의 상호 작용들, 및 사용의 컨텍스트를 표현할 수 있다.

RDF 스키마(RDFS)는 클래스들 및 속성들의 분류들 및 속성들에 대한 단순 도메인 및 범위 명세들을 정의하기 위해 이용될 수 있는 RDF에 대한 특정 용어 모음을 제공한다. 웹 온톨로지 언어(OWL)는 도메인 지식의 시멘틱을 캡처하는 온톨로지들을 정의하기 위한 표현 언어를 제공한다.

요약하면, 전술한 바와 같이, RDF는 웹에서 정보를 표현하기 위한 프레임워크이다. RDF는 본질적으로 데이터-모델이다. 그것의 기본적인 빌딩 블록은 문(statement)이라고 불리는, 자원-속성-값 트리플이다. RDF에는 XML의 구문이 주어졌다. 도 27에 도시된 예에서, 문은 John Smith의 직위(title)가 교수(Professor)라는 것이고, 이는 아래 나타낸 바와 같이 RDF로 표현될 수 있다. xmlns:uni는 자체-정의된 도메인 이름이고, 여기서는 속성들(이름 및 직위)이 RDFS의 일부로서 정의된다.

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:xsd ="http://www.w3.org/2001/XLMSchema#"

xmlns:uni="http://www.mydomain.org/uni-ns">

<rdf:Description rdf:about="949352">

<uni:name>John Smith</uni:name>

<uni:title>Professor</uni:title>

</rdf:Description>

</rdf:RDF>

RDF는 도메인-독립적이고, 여기서는 사용중인 특정 도메인에 관한 어떤 가정도 이루어지지 않는다. RDFS라고 불리는 스키마 언어로 그들 자신의 용어를 정의하는 것은 사용자들에 달려 있다. RDFS는 RDF 데이터 모델들에서 사용되는 용어 모음을 정의한다. RDFS에서는 용어 모음을 정의하고, 어떤 속성들이 어떤 종류의 객체들에 적용되는지 그리고 그것들이 어떤 값들을 가질 수 있는지를 특정하고, 객체들 사이의 관계들을 기술할 수 있다.

OWL은 웹에 대한 더 많은 표현 온톨로지들을 구축하기 위해 이용될 수 있는 추가적인 자원들로 RDFS 용어 모음을 확장한다. OWL은 처리를 더 계산적으로 결정 가능하게 만들기 위하여 RDF 문서들의 구조 및 콘텐츠에 관한 추가적인 제약들을 도입한다. OWL은 RDF 및 RDFS, XML 스키마 데이터 형식들(datatypes), 및 OWL 네임스페이스들(namespaces)을 이용한다. OWL 용어 모음 자체는 네임스페이스 http://www.w3.org/2002/07/owl#에서 정의되고 통상적으로 프리픽스 owl에 의해 참조된다. OWL 2는 원래 OWL 용어 모음을 확장하고 동일한 네임스페이스를 재사용한다.

데이터 형식들은 URI들을 이용하여 식별되는 데이터 값들의 범위들을 나타낸다. OWL은 다수의 사전 정의된 데이터 형식들을 이용할 수 있게 하고, 그것들의 대부분은 XML 스키마 정의(XSD) 네임스페이스에서 정의된다.

OWL은 클래스 rdfs:Datatype의 인스턴스들을 생성하고 하나 이상의 패싯(facet) 제약을 그 인스턴스와 연관시키는 것에 의해 자신의 데이터 형식들을 정의할 수 있게 한다. 패싯 제약은 유효 값들의 범위를 구성하는 특정 데이터 형식에 대한 값들의 세트를 기술하는 방법이다. 표 3은 OWL에 의해 지원되는 패싯들을 포함한다.

패싯	설명
xsd:length	허용되는 항목들(문자들)의 정확한 수.
xsd:minLength	허용되는 항목들(문자들)의 최소 수.
xsd: maxLength	허용되는 항목들(문자들)의 최대 수.
xsd:pattern	허용되는 문자열들을 정의하는 정규 표현.
xsd:minInclusive	값들이 지정된 수 이상이어야 한다.
xsd:minExclusive	값들이 지정된 수보다 엄격히 커야 한다.
xsd:maxInclusive	값들이 지정된 수 이하이어야 한다.
xsd:maxExclusive	값들이 지정된 수보다 엄격히 작아야 한다.
xsd:totalDigits	숫자들의 수가 지정된 수와 같아야 한다.
xsd:fractionDigits	허용되는 소수 자리의 최소 수.

복합 형식(complex type)들은 그것의 요소 및 텍스트 자식 및 그것의 속성들을 포함하여, 요소의 허용된 콘텐츠를 기술한다. 복합 형식 정의는 콘텐츠 모델 및 속성 사용들의 세트로 이루어진다. 복합 형식은 (기본 형식이 허용하는 일부 요소들, 속성들, 또는 값들을 불허하는) 제약에 의해 또는 (추가적인 속성들 및 요소들이 나타나도록 허용하는) 확장에 의해 또 다른 복합 형식으로부터 유도될 수 있다. 단순 형식들(데이터 형식들이라고도 불림)은 요소 또는 속성에 나타날 수 있는 텍스트 값들을 제한한다.

W3C XML 스키마 정의 언어(XSD)는 19개의 프리미티브 데이터 형식들(anyURI, base64Binary, boolean, date, dateTime, decimal, double, duration, float, hexBinary, gDay, gMonth, gMonthDay, gYear, gYearMonth, NOTATION, QName, string, 및 time)의 세트를 제공한다. 그것은 다음과 같은 3개의 메커니즘에 의해 이들 프리미티브들로부터 새로운 데이터 형식들이 구성될 수 있게 한다:

o 제약(restriction)(허용되는 값들의 세트를 감소시킴),

o 목록(list)(값들의 시퀀스를 허용함), 및

o 통합(union)(여러 형식들로부터 값들의 선택을 허용함).

다음은 XSD로 데이터 형식들을 정의하는 2개의 예이다:

예 1:

</restriction>

</simpleType>

예 2:

</sequence>

</complexType>

시멘틱-관련 자원들에 대한 구조 및 속성들이 더 상세히 설명된다. 또한, M2M 시스템들에서 통상의 자원들에 대한 시멘틱을 가능하게 하기 위해 그 자원들을 사용하는 방법에 관한 메커니즘들 및 절차들이 명시된다.

M2M 시스템들에서 자원들의 콘텐츠는 통상적으로 XSD 표준에서 정의된 바와 같은 기존 프리미티브 데이터 형식들과는 다른 복합 데이터 형식이다. 따라서 각각의 개별 자원의 시멘틱을 정의하지 않고, 동일한 형식의 자원들이 동일한 시멘틱을 따를 수 있고 해석될 수 있도록, 복합 데이터 형식들의 시멘틱을 정의하는 것은 당연하다(예를 들어, 시멘틱 그룹화 최적화). 비록 OWL은 클래스 rdfs: Datatype의 인스턴스들을 생성하고 하나 이상의 패싯 제약을 그 인스턴스와 연관시키는 것에 의해 자신의 데이터 형식들을 정의하는 것을 허용하지만, 그것은 새로운 복합 데이터 형식을 정의하는 수단을 제공하지는 않는다. 다시 말해, 새로이 정의된 데이터 형식들은 프리미티브 형식들로부터 확장되는 것으로 한정될 수 있다. 비록 XSD는 새로운 데이터 형식들이 제약, 목록 및 통합에 의해 19개 프리미티브들로부터 구성되는 것을 허용하지만, 그것은 자원들의 콘텐츠를 이해하기에 충분한 제약들을 제공하지는 못한다. 따라서 XSD에 의해 복합 데이터 형식의 필드들에 제공되는 시멘틱은 매우 한정된다. 다음은 2개의 예를 나타내는데, 하나는 단순 데이터 형식이고 또 하나는 XSD에 의해 정의된 복합 데이터 형식이다.

XSD에 관하여 본 명세서에 기술된 바와 같이, 예 1은 단순 온도(Temperature) 데이터 형식이고, 그러한 데이터 형식의 값들이 모두 정수인 것을 정의하기 위해 표준 제약들 중 하나를 이용한다. 그러나, 기존의 제약 패싯들은 값들의 단위를 제약할 수 없고, 따라서 온도 판독치들이 섭씨인지, 화씨인지, 또는 어떤 다른 것인지가 여전히 모호하다.

예 2는 복합 혈압(BloodPressure) 데이터 형식이고, 그 각각이 정수의 값을 갖는, 2개의 필드 's' 및 'd'를 순서대로 가지고 있는 것을 정의하기 위해 목록 메커니즘을 이용한다. 그러나, 기존의 제약 패싯들은 각각의 필드의 단위를 제약할 수 없다. 그리고 시퀀스 내의 요소들의 이름으로부터, 복합 데이터에 포함된 2개의 필드가 무엇인지를 알 수 없다. 따라서, 상이한 애플리케이션들이 콘텐츠 인스턴스들 내의 콘텐츠를 이해하고 해석하는 것이 불가능할 수 있다.

요약하면, 전술한 문제들은 시멘틱-관련 자원들의 구조들 및 표현들 및 자원들을 시멘틱-관련 자원들과 링킹 및 연관시킴으로써 자원들에 대한 시멘틱을 가능하게 하는 방법들에 의해 본 명세서에서 해결될 수 있다. 또한, 그 문제들은 복합 데이터 형식 내의 필드들이 추출 및 해석될 수 있도록, 제약들/패싯들 단위 및 설명으로 XSD의 확장을 가능하게 하는 메커니즘들을 통해 해결될 수 있다. 마지막으로, 그 문제들은 데이터 형식들의 이름 및 복합 데이터 형식들 내의 필드들에, 그것을 발견 가능하고 해석 가능하게 하는 데이터 형식의 키워드들 및 각각에 대한 값이 적절히 정량화될 수 있도록 데이터 형식 내의 각 필드의 단위와 같은, 설명/속성들을 내장하는 것에 의해 해결될 수 있다.

이하에서는 자원 구조를 더 상세히 설명한다. 예에서, 시멘틱 노드는 현재의 ETSI M2M 아키텍처의 xSCL에서 이용되는 바와 같은 상보적인 자원 구조를 지원할 수 있다. 시멘틱 노드에 대한 자원 구조의 예가 도 17에 도시되어 있다. 자원 <Sscl>은 호스팅 시멘틱 노드에 상주하는 자원 트리의 루트이다. <Sscl>은 본 명세서에 기술된 바와 같은 시멘틱-관련 자원들의 루트의 이름으로서 이용된다. 루트들은 예시적인 명명이고 본 명세서에 기술된 바와 같이 명명되지 않아도 된다. <Sscl> 자원은 호스팅 시멘틱 노드를 기술하는 속성들을 포함할 수 있다. <Sscl> 자원은 <SS> 자원들(다른 시멘틱 노드로부터의 통지된 시멘틱-관련 자원들), <class> 자원들, <relationship> 자원들, <term> 자원들, <accessRight> 자원들, 및 <subscription> 자원들의 집합들을 나타내는 집합 자원들을 포함한다.

M2M 시스템들 내에는 다수의 유형의 자원들이 존재할 수 있다. 다음의 것들 중 일부를 포함할 수 있는 시멘틱-관련 자원들이 있을 수 있다: 클래스들, <class>, 관계들, <relationship>, 용어들 및 <term>. 시멘틱-관련 자원들은 시멘틱 노드에 저장된 자원들을 지칭한다. 다르게는, 자원은 통상의 자원들을 지칭하기 위해 이용될 수 있다. 통상의 자원들은 CSEBase, 애플리케이션 엔티티(AE), 컨테이너, 및 oneM2M 아키텍처에 정의된 contentInstance와 같은 것들 중 일부를 포함할 수 있다. 그리고 유사한 자원들이 ETSI M2M 아키텍처에서도 채택될 수 있다.

이하에서는, 이 개시 내용에서 제안된 메커니즘들 및 절차들을 예시할 수 있는 도 28에 도시된 바와 같은 체육관(gym) 사용 사례를 설명한다. 용어들, 예를 들어, 애플리케이션, 서비스 계층(SL)의 사용은 oneM2M에서의 AE, CSE 또는 ETSI M2M에서의 DA/GA/NA, DSCL/GSCL/NSCL에 각각 매핑될 수 있다. 도 28은 동일한 용어를 갖는 사용 사례에 관련된 엔티티 구성을 예시한다.

체육관 사용 사례에서, 사용자는 시계 애플리케이션(711)을 갖는, 시계(watch)(710)를 가지고 있다. 시계(710)는 사용자의 폰(phone) SL(713)을 발견하고, 그것에 등록한다. 런닝머신(Treadmill) 애플리케이션들(714)은 체육관 내의 하나 이상의 런닝머신들(715)상에 있을 수 있다. 주변 센서들(Ambient sensors)(716)은 런닝머신(715)상에 그리고 체육관 전체에 걸쳐 있을 수 있다. 주변 센서들(716)은 체육관 SL(718)을 발견하고 그것에 등록할 수 있다. 그리고 사용자가 체육관에 있을 때, 폰 SL(713)은 체육관 SL(718)을 발견하고 그것에 등록할 수 있다. 폰(712)상의 체육관 애플리케이션(721)은 런닝머신들(715)을 발견할 수 있고 런닝머신들(715) 중 체육관 SL(718)을 사용할 하나의 런닝머신을 선택할 수 있다. 폰(712)상의 체육관 애플리케이션(721)은 런닝머신들(715)을 발견할 수 있고 런닝머신 애플리케이션(714)의 시멘틱을 아는 것에 의해 런닝머신들(715) 중 사용할 하나의 런닝머신을 선택할 수 있다.

폰(712)상의 건강 보험 애플리케이션(722)은 주변 센서들(716)로부터의 데이터(예를 들어, 체육관 내의 온도 또는 습도), 시계(710)로부터의 측정(예를 들어, 사용자의 심박수, 혈압), 또는 런닝머신(714)으로부터 사용자에 의해 완수된 체육관 훈련 프로그램을 수집한다. 건강 보험 애플리케이션(722)은 수집된 데이터에 기초하여 사용자의 건강 점수를 계산하고 그 건강 점수를 건강 보험 회사 애플리케이션(724)에 공유할 수 있다. 폰(712)상의 건강 보험 애플리케이션(722)은 또한 사용자의 완수된 체육관 훈련 프로그램을 건강 보험 회사 애플리케이션(724)에 송신할 수 있고, 건강 보험 회사 애플리케이션은 그 데이터(예를 들어, 건강 점수, 운동 결과)에 기초하여 사용자의 보험료를 결정 및 조정할 수 있다. 건강 보험 애플리케이션들(722) 및 건강 보험 회사 애플리케이션(724)은 데이터의 적절히 추가된 그리고 가능하게 된 시멘틱을 이용하여 데이터의 동일한 해석을 가질 수 있다.

본 명세서에서는 통상의 자원들에 대한 시멘틱을 가능하게 하는 시멘틱 기능들의 서비스 계층(SL) 지원이 기술된다. 시멘틱-관련 자원들의 상세한 구조들 및 시멘틱-관련 자원들이 통상의 자원들에 대한 시멘틱을 가능하게 하는 방법이 개시된다.

<class>의 자원 트리 구조가 도 29에 도시되어 있다. <class> 자원은 자원-관계-값 트리플(Value)의 일부로서 자원의 시멘틱을 정의하기 위해 이용된다. 표 4는 <class>의 자식 자원들을 나타낸다. 표 5는 <class>의 속성들을 나타낸다.

<class> 자원의 자식 자원들

자식 자원 유형	다중도	설명
<subscription>	0..n	oneM2M-TS-0001 oneM2M Functional Architecture-V0.3.2의 9.6.8절 참조

<class> 자원의 속성들

속성 이름	다중성	RW/ RO/ WO	설명
resourceType	1	RO	이 공통 속성이 설명되어 있는 See clause 9.6.1 in oneM2M-TS-0001 oneM2M Functional Architecture-V1.2.0(이하 [1])의 9.6.1절 참조.
parentID	1	RO	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
expirationTime	1	RW	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
accessControlPolicyIDs	0..n	RW	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
creationTime	1	RW	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
lastModifiedTime	1	RO	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
Labels	0..n	RO	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
announceTo	1	RW	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
announcedAttribute	1	RW	이 공통 속성이 설명되어 있는 [1]의 9.6.1절 참조.
description	1	RW	전체 온톨로지에 대해 지정된 포맷을 따르는 클래스의 표현.
syntax	1	RW	설명 속성에서 사용되는 구문, 예를 들어, XML, RDFS in XML, String.
properties	1	RW	<relationship> 자원들의 URI들의 값을 갖는, 클래스의 속성들의 목록.
nOfProperties	1	RW	클래스와 연관된 속성들의 총수.
type	1	RW	그것이 dataType인지에 대한 표시. 1은 그것이 dataType인 것을 의미하고, 0은 그것이 dataType이 아닌 것을 의미한다.

복합 데이터 형식은 <container> 자원 하에 저장된 콘텐츠 인스턴스들을 파싱하기 위해 필요한 데이터 구조를 정의하는 특수 클래스이다. < class> 자원의 type 속성은 그것이 dataType인지 여부를 지시하기 위해 이용된다. 그것이 dataType이라면, description 속성은 소정 구문을 이용하여 데이터 구조를 기술하기 위해 이용되며; XSD가 옵션들 중 하나이다. 그것이 dataType이 아니라면, description 속성은 소정 언어로 클래스를 정의하기 위해 이용되며, RDF가 옵션들 중 하나이다. RDF는 또한 XML 구문을 가질 수 있다. 이 구문(syntax) 속성은 사용될 수 있는 가능한 구문을 지시하기 위해 이용된다. 예를 들어, XML은 그것이 단순 및 복합 데이터 형식들을 기술하기 위해 XSD에서 사용되는 패턴들을 따른다는 것을 의미할 수 있다. XML 내의 RDF는 클래스가 XML 구문을 갖는 RDF 언어로 기술되는 것을 의미할 수 있다(XML에 기초하지 않는, RDF의 다른 구문 표현도 가능하다). 문자열(string)은 설명(description) 속성이 단지 클래스를 기술하는 어떤 단어들을 제공하는 것을 의미할 수 있다.

properties 속성은 옵션이고, 그것은 <relationship> 자원들의 URI들의 값을 가질 것이다. 클래스와 연관된 속성들은 복합 데이터 형식 또는 비-복합 데이터 형식일 수 있다.

설명 패싯(description facet) 및 단위 패싯(unit facet)인 복합 데이터 형식에서 각각의 요소를 해석하기 위해 제약들/패싯들을 이용해 XSD의 확장이 가능하게 될 수 있다. 설명 패싯은 요소의 간단한 설명을 제공하기 위해 사용될 수 있고, 이것은 애플리케이션이 요소를 인식하고 그 요소가 무엇에 관한 것인지를 이해하는 데에 도움을 주는 가능한 키 워드들을 포함한다. 단위 패싯은 요소의 단위를 특정하기 위해 사용된다. 이전의 예 1 및 예 2의 업데이트된 버전들이 아래에 제시된다:

예 1A - 설명 및 단위 패싯:

description ="temperature in Celsius" unit="Celsius" base="integer"

</restriction>

</simpleType>

예 2A - 설명 및 단위 패싯:

</sequence>

</complexType>

데이터 형식들 및 그것의 요소들의 이름에 설명/속성이 내장될 수 있다. dataType 이름 및 dataType의 요소들의 이름들은 애플리케이션이 데이터 형식들 및 그것의 요소들을 해석하는 데 도움을 주는 정보를 포함할 수 있다. dataType 및 그것의 요소들의 이름의 포맷은 표 6처럼 보일 수 있다. 그 결과, 이전의 예 1 및 예 2의 업데이트된 버전들은 다음과 같다:

예 1B - 데이터 형식들 및 그것의 요소들의 이름에 설명/속성을 내장:

</restriction>

</simpleType>

Example 2B - 데이터 형식들 및 그것의 요소들의 이름에 설명/속성을 내장:

</sequence>

</complexType>

데이터 형식 및 요소 이름 포맷

키 워드 1

...키 워드 n

IN

단위

<relationship>의 자원 트리 구조가 도 30에 도시되어 있다. <relationship> 자원은 클래스들에 연관될 수 있는 속성들을 정의하기 위해 이용될 수 있다. 다시 말해, <class> 자원의 properties 속성은 <relationship> 자원들의 링크들을 포함할 수 있다. <relationship> 자원은 또한 자원-관계-값 트리플(Relationship)의 일부로서 자원의 시멘틱을 정의하기 위해 이용된다. 표 7은 <relationship>의 자식 자원들을 나타낸다. 표 8은 <relationship>의 속성들을 나타낸다.

<relationship> 자원의 자식 자원들

자식 자원 유형	다중성	설명
<subscription>	0..n	oneM2M-TS-0001 oneM2M Functional Architecture-V 1.2.0의 9.6.8절 참조

<relationship> 자원의 속성들

속성 이름	다중성	RW/ RO/ WO	설명
resourceType	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
parentID	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
expirationTime	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조
accessControlPolicyIDs	0..n	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조
creationTime	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
lastModifiedTime	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
labels	0..n	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
announceTo	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
announcedAttribute	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
format	1	RW	이것은 관계의 설명의 포맷을 나타낸다.
description	1	RW	지정된 포맷을 따르는 관계의 표현.

<term>의 자원 트리 구조가 도 31에 도시되어 있다. <term> 자원은 자원-관계-값 트리플(Value)의 일부로서 자원의 시멘틱을 정의하기 위해 이용될 수 있다. 표 9는 <term>의 자식 자원들을 나타낸다. 표 10은 <term>의 속성들을 나타낸다.

<term> 자원의 자식 자원들

<term> 자원의 속성들

속성 이름	다중성	RW/ RO/ WO	설명
resourceType	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
parentID	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
expirationTime	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
accessControlPolicyIDs	0..n	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
creationTime	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
lastModifiedTime	1	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
labels	0..n	RO	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
announceTo	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
announcedAttribute	1	RW	이 공통 속성이 설명되어 있는 [2]의 9.6.1절 참조.
format	1	RW	이것은 용어의 설명의 포맷을 나타낸다.
term	1	RW	지정된 포맷을 따르는 용어의 표현.

시멘틱-관련 자원들 기능은 M2M 시스템들 내의, 예를 들어, oneM2M 자원 구조 내의 통상의 자원들, <CSEBase>, <AE>, <container>, <contentInstance>, 등등과 연관되고 그에 링킹되어 그 자원들에 대한 시멘틱 설명을 제공할 수 있다. 통상의 자원은 자원, 관계, 및 값으로 이루어지는, 자원-관계-값 트리플들의 집합에 의해 기술될 수 있다. 값들은 클래스들, 용어들, 또는 다른 자원들일 수 있다. 그 트리플들에서, 자원 자체는 고정되고 알려져 있으므로, 추가될 수 있는 것은 관계-값 더블들의 집합, 또는 다른 유사한 것이다. 시멘틱을 가능하게 하기 위해 기존의 searchStrings 속성을 보완하기 위해 또 다른 semantics 속성이 이용(즉, 추가)될 수 있다. oneM2M 자원 구조에서 <AE> 및 <container> 자원에 대해 시멘틱이 가능하게 되는 방법이 본 명세서에 기술된다.

<AE> 자원에 대한 시멘틱을 가능하게 하기 위하여, rdf: type은 identifier 및 producedData의 속성들을 가진, 본 명세서에 정의된 바와 같은 <DeviceApp > 클래스에 <AE> 자원을 관련시킨다. W3C RDFS는 코어 속성 rdf: type을 이미 정의하였으므로, 프리픽스들 중 하나에 http://www.w3.org/1999/02/22-rdf-syntax-ns#을 포함한다면 그것을 외부 관계들 중 하나로서 이용할 수 있다. 한편, 시멘틱 노드에서 그러한 유사한 관계를 정의하는 데 제한이 없다. semantics 속성은 <AE> 자원의 시멘틱 설명을 저장하는 데 이용된다. 이 예에서, 도 32에 도시된 바와 같이, 애플리케이션은 watchOfJohnSmith의 식별자 및 혈압의 producedData를 갖는, 시계이다. 그 결과, 시멘틱 속성에는, 다수의 항목이 있다. 제1 항목은 <watchAE> 431이 <DeviceApp>의 형식을 가진다는 것을 지시한다. 그리고 <DeviceApp> 클래스 설명으로부터, 그것과 연관된 다수의 속성들이 있다. 따라서 제2 및 제3 항목들은 그 속성들에 값들을 할당하는 것이다.

@prefix relationship: <Sscl>/relationships/

@prefix class: <Sscl>/classes/

와 같은 프리픽스들이 정의될 수 있고

이에 따라, 시멘틱 속성이 제공되어 다음과 같이 될 수 있다.

rdf: type class/DeviceApp 433

relationship/identifier "watchOfJohnSmith" 434

relationship/producedData "blood pressure" 435

<container> 자원의 시멘틱은 그 컨테이너 하의 개별 <contentInstance> 자원에 적용될 수 있다. 이것은 유사한 자원들의 그룹의 시멘틱을 설명함에 있어서 그룹화 최적화로 간주된다.

예로서, 혈압 모니터링 데이터의 다수의 인스턴스는 동일한 시멘틱을 가질 수 있다. 따라서, 각각의 콘텐츠 인스턴스는 아래에 나타나는 바와 같이 동일 시멘틱과 관련될 수 있다(BloodPressure 클래스는 본 명세서에서 URI Sscl/classes/BloodPressure를 이용하여 정의되었다). Sscl은 본 명세서에서 설명되는 바와 같은 루트의 다른 이름일 뿐이며, 도 17에서 ssBase와 또한 동일하다는 점에 유의한다.

그룹핑 최적화를 지원함으로써, 아래의 연관성도 유효하다.

<BloodPressure> 클래스는 본 명세서에서 정의되는 바와 같은 데이터 타입인 특수 <class> 자원이다. 구체적으로, 콘텐츠 인스턴스는 그의 콘텐츠 속성 내에 2개의 필드, 즉 systolicINmmHG 및 diastolicINmmHG를 갖는 BloodPressure 데이터 타입을 갖는다. 이 예에서, 도 33에 도시된 바와 같이, 시멘틱 속성은 컨테이너가 <BloodPressure>의 타입을 갖는다는 정보를 저장하는 데 사용된다.

일례로서, <contentInstance>는 <CSEBase1>/bpAE/<bpContainer>/<contentInstance1>의 URI를 갖는다. 우리는 <BloodPressure> 클래스가 정의되고 Sscl 상에 저장되며 Sscl/classes/BloodPressure의 URI를 갖는 것으로 가정한다. 도 34는 AE(731)(예로서, 시계(710) 내의 혈압 모니터 앱(도시되지 않음))에 의해 <bpContainer> 컨테이너를 생성하는 예시적인 메시지 흐름 및 시멘틱이 AE(731)에 의해 어떻게 인에이블되는지를 나타낸다. 단계 733에서, AE(731)는 통상적인 자원(예로서, 도 33에 도시된 바와 같은 <bpContainer>(437))을 생성하기 위한 요청을 CSE(732)로 전송한다. 단계 734에서, CSE(732)는 <bpContainer>(437)를 생성하고, 단계 735에서, CSE(732)는 <bpContainer>(437)의 생성과 관련된 확인을 AE(731)로 전송한다. 단계 736에서, AE(731)는 <bpContainer>와 관련된 시멘틱 정보를 제공한다. 이 상황에서, AE(731)는 컨테이너(<bpContainer>(437))가 혈압 타입을 갖는 데이터를 포함한다는 시멘틱 정보를 제공한다. 단계 737에서, CSE(732)는 도 33에 도시된 바와 같이 시멘틱 정보를 <bpContainer>(437)의 속성(시멘틱 속성(438)) 내에 유지할 수 있다. 단계 738에서, CSE(732)는 단계 736의 시멘틱 정보의 수신과 관련된 확인을 AE(731)로 전송할 수 있다. AE(731)는 <bpContainer>(437) 컨테이너 자원의 시멘틱 속성(438)에 대한 값을 더한다. 도 35는 컨테이너에 포함된 데이터에 관심 있는 다른 애플리케이션(예로서, 의사)의 사용을 나타낸다.

도 35는 혈압 정보를 원할 수 있는 의사의 사무실과 관련될 수 있는 다른 AE(741)에 의한 <contentInstance> 자원 및 시멘틱 검색 프로세스의 예시적인 메시지 흐름을 나타낸다. 단계 743에서, AE(741)는 콘텐츠 인스턴스(예로서, .../<bpContainer>/<contentInstance1>)에 대한 요청을 CSE(732)로 전송한다. 단계 744에서, CSE(732)는 <contentInstance> 자원을 AE(741)에 제공한다. 데이터를 이해하고 해석하기 위해, 애플리케이션(AE(741))은 시멘틱 정보를 원할 것이다. 이 경우, 단계 745에서, AE(741)는 데이터(예로서, .../< bpContainer>/<contentInstance1>)와 함께 저장된 시멘틱 정보를 검색하기 위한 후속 요청을 CSE(742)로 전송한다. 단계 746에서, CSE(732)는 시멘틱 정보를 제공한다. 단계 746의 시멘틱 정보는 데이터가 이 경우에 클래스 자원으로서 정의되는 소정의 타입(예로서, 타입 클래스/혈압(439))을 갖는다는 정보를 포함한다. 단계 747에서, AE(741)는 이러한 타입(클래스 자원)을 이해하기 위해 Sscl(742)(시멘틱 노드)과 통신한다. AE(741)는 시멘틱 노드로부터 클래스 자원의 정의를 검색한다.

본 명세서에서 개시되는 바와 같이 체육관 사용 예를 위해 사용될 수 있는 시멘틱 관련 자원들의 예들이 도 36에 도시된다. 식별자 관계는 객체/엔티티, 예로서, 애플리케이션, 데이터 등에 대한 식별자를 지정한다. <identifier>(751) 관계 자원의 속성들(syntax, searchStrings, description)은 표 11에 표시되며, 그의 설명은 XML 내의 RDFS 내에 작성된다.

XML 내의 RDFS 내의 <identifier>의 설명

신택스	XML 내의 RDF
searchStrings	"identifier"
설명	<rdf:Property rdf:about ="coap:// <Sscl>/relationships/identifier " > <rdfs:label>identifier</rdfs:label> <rdfs:comment> Relation from an object to its unique identifier. </rdfs:comment> < rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/> <rdfs:isDefinedBy rdf:resource="coap://<Sscl>/"/> </rdf:Property>

생성된 데이터 관계는 애플리케이션의 생성된 데이터를 지정한다. <producedData>(752) 관계 자원의 속성들(syntax, searchStrings, description)은 표 12에 표시되며, 그의 설명은 XML 내의 RDFS 내에 작성된다.

XML 내의 RDFS 내의 <producedData>의 설명

신택스	XML 내의 RDF
searchStrings	"producedData"
설명	<rdf:Property rdf:about ="coap:// <Sscl>/relationships/measurement " > <rdfs:label> measurement </rdfs:label> <rdfs:comment> Relation from an application to its produced data (measured data or data analyzed from the measurements. </rdfs:comment> <rdfs:domain rdf:resource=" coap:// <Sscl>/classes/ DeviceApp"/> < rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/> <rdfs:isDefinedBy rdf:resource=" coap:// <Sscl>/ " /> </rdf:Property>

위에서 정의된 식별자(751) 및 생성된 데이터(752) 관계들은 하나의 클래스를 다른 클래스에, 하나의 클래스를 그의 특성들에 관련시키는 데 사용될 수 있다. <DeviceApp>(753) 클래스는 사용 예들 내에 포함되는 애플리케이션들의 클래스이다. <DeviceApp>(753)은 여기서 지정되는 것들로 제한되지 않고 확장 가능한 속성들을 가질 수 있다. 시계 애플리케이션(711), 트레드밀 애플리케이션(714) 및 주변 센서 애플리케이션(717)은 <DeviceApp>(753) 클래스의 인스턴스들이다. <DeviceApp>(753)은 본 명세서에서 정의되는 다음의 특성들을 가지며, 이들은 식별자 및 생성된 데이터이다. <DeviceApp>(753) 클래스 자원의 속성들(syntax, searchStrings, properties, nOfProperties, type 및 description)은 설명이 XML 내의 스트링 또는 RDFS 내에 작성될 때 표 13 및 표 14에 각각 표시된다.

스트링 내의 <DeviceApp>의 설명

신택스	스트링
searchStrings	"application"
특성	../../relationship/identifier ../../relationship/producedData
nOfProperties	2
타입	0
설명	"An application"

XML 내의 RDFS 내의 <DeviceApp>의 설명

신택스	XML 내의 RDF
searchStrings	"application"
특성	../../relationship/identifier ../../relationship/producedData
nOfProperties	2
설명	<rdf:Class rdf:about="coap://<Sscl>/class/DeviceApp"> <rdfs:label>=DeviceAppL</rdfs:label> <rdfs:comment> An application. </rdfs:comment> <rdfs:isDefinedBy rdf:resource=" coap:// <Sscl> / " /> </rdf:Class>

시계 애플리케이션(711)(예로서, 도 37의 <watch>(761)과 관련됨)은 <DeviceApp>(753) 클래스에 대해 정의된 특성들을 갖는 <DeviceApp>(753) 클래스의 인스턴스이다. 시계 애플리케이션(711)은 혈압 데이터를 생성할 수 있다.

주변 센서 애플리케이션(717)(예로서, 도 38의 <sensor>(771)과 관련됨)은 <DeviceApp>(753) 클래스에 대해 정의된 특성들을 갖는 <DeviceApp>(753) 클래스의 인스턴스이다. 주변 센서 애플리케이션(717)은 온도 데이터를 생성할 수 있다.

트레드밀 애플리케이션(714)(예로서, 도 38의 <treadmill>(775)과 관련됨)은 <DeviceApp> 클래스에 대해 정의된 특성들을 갖는 <DeviceApp> 클래스의 인스턴스이다. 트레드밀 애플리케이션(714)은 사용자가 마무리하는 체육관 훈련 프로그램 데이터를 생성할 수 있다.

전화기(712)상의 건강 보험 애플리케이션(722)(예로서, 도 37의 <healthInsurance>(765)과 관련됨)은 <DeviceApp> 클래스에 대해 정의된 특성들을 갖는 <DeviceApp> 클래스의 인스턴스이다. 건강 보험 애플리케이션(722)은 건강 점수 데이터를 생성할 수 있다.

<BloodPressure>(754) 클래스는 데이터 타입이다. 이것은 필드 systolicINmmHG 및 diastolicINmmHG를 갖는다. <BloodPressure> 클래스 자원의 속성들(syntax, searchStrings, type 및 description)은 설명이 XML로 작성될 때 표 15에 표시된다.

XML 내의 <BloodPressure>의 설명

신택스	XML
searchStrings	"blood pressure"
타입	1
설명	<complexType name="BloodPressure"> <sequence> <element name=" systolicINmmHG " type="integer"/> <element name="diastolicINmmHG" type="integer"/> </sequence> </complexType>

도 36의 <TemperatureInCelsius >(755) 클래스는 데이터 타입이다. <TemperatureInCelsius>(755) 클래스 자원의 속성들(syntax, searchStrings, type 및 description)은 설명이 XML로 작성될 때 표 16에 표시된다.

XML 내의 <TemperatureInCelsius>의 설명

신택스	XML
searchStrings	"temperature", "celsius"
타입	1
설명	<simpleType name="TemperatureINCelsius"> <restriction base="integer"> </restriction> </simpleType>

<GymTrainingProgram>(756) 클래스는 데이터 타입이다. 이것은 usedEquipmentType, usedEquipmentLevel, durationINMinute, targetHeartRateINPerMinute 및 calorieBurnINPerHour의 필드들을 갖는다. usedEquipmentType은 훈련을 위해 사용되고 있는 장비의 타입을 나타낸다. usedEquipmentLevel은 훈련을 위해 장비의 어떤 레벨이 설정되었는지를 나타낸다. durationINMinute는 훈련을 몇 분 동안 했는지를 나타낸다. heartRateINPerMinute는 훈련 동안의 분당 평균 심박수를 나타낸다. calorieBurnINPerHour는 훈련 동안 연소된 시간당 총 칼로리를 나타낸다. <GymTrainingProgram>(756) 클래스 자원의 속성들(syntax, searchStrings, type 및 description)은 설명이 XML로 작성될 때 표 17에 표시된다.

XML 내의 <GymTrainingProgram>의 설명

신택스	XML
searchStrings	"gym training program"
타입	1
설명	<complexType name="GymTrainingProgram"> <sequence> <element name="usedEquipmentType" type="string"/> <element name="usedEquipmentLevel" type="integer"/> <element name="durationINMinute" type="integer"/> <element name="heartRateINPerMinute" type="integer"/> <element name="calorieBurnINPerHour" type="integer"/> </sequence> </complexType>

<HealthScore>(757) 클래스는 데이터 타입이다. 그의 값들은 이 예에서 0과 100 사이의 범위를 갖는다. <HealthScore>(757) 클래스 자원의 속성들(syntax, searchStrings, type 및 description)은 설명이 XML로 작성될 때 표 18에 표시된다.

XML 내의 <HealthScore>의 설명

신택스	XML
searchStrings	"health score"
타입	1
설명	<simpleType name="HealthScore"> <restriction base="integer"> <minInclusive value="0"/> <maxInclusive value="100"/> </restriction> </simpleType>

여기서, 도 37 및 도 38을 참조하면, 예시의 목적을 위해 oneM2M 자원 구조가 사용된다. 그러나, ETSI M2M과 같은 다른 M2M 아키텍처들에서 정의되는 자원들의 예는 매우 유사하며, oneM2M 예들에도 적용될 수 있다. 도 37 및 도 38과 관련된 아래의 설명은 도 34 및 도 35와 관련하여 도시된 바와 같은 방법들과 관련하여 고찰될 수 있다.

일례에서, 시계 애플리케이션(711)이 전화 서비스 계층(713)(예로서, 공통 서비스 엔티티 - CSE 또는 서비스 계층 - SL)에 등록할 때, 그는 그의 시멘틱을 등록 메시지 내에 첨부한다. 시계는 DeviceApp(753)의 타입을 갖는다. DeviceApp(753) 클래스의 스키마를 따름으로써, 시계 애플리케이션(711)은 그가 혈압 데이터를 생성할 수 있다는 것을 전화 서비스 계층(713)에 지시한다. 전화 SL(713)은 도 37에 도시된 바와 같이 시계(710)에 대한 애플리케이션 자원(예로서, <watch>(761))을 생성할 수 있다. 시계 애플리케이션(711)은 그가 측정하는 데이터를 업로드하기 위해 전화 SL(713) 상에 컨테이너를 생성한다. 시계 애플리케이션(711)은 콘텐츠 인스턴스가 BloodPressure(754)의 타입을 갖는다는 것을 지시한다. 이 <bloodP>(762) 컨테이너 아래의 모든 콘텐츠 인스턴스는 동일한 시멘틱을 가지므로, 시멘틱은 도 37에 도시된 바와 같이 각각의 콘텐츠 인스턴스 대신에 <bloodP>(762) 컨테이너와 관련된다.

유사하게, 건강 보험 애플리케이션(722)이 전화 SL(713)에 등록할 때, 그는 그의 시멘틱을 등록 메시지 내에 첨부한다. 건강 보험 애플리케이션(722)은 DeviceApp(753)의 타입을 갖는다. DeviceApp(753) 클래스의 스키마를 따름으로써, 건강 보험 애플리케이션(722)은 그가 건강 점수 데이터를 생성할 수 있다는 것을 전화 SL(713)에 지시한다. 전화 SL(713)은 도 37에 도시된 바와 같이 건강 보험 애플리케이션(722)에 대한 애플리케이션 자원(예로서, <healthInsurance>(765))을 생성할 수 있다. 건강 보험 애플리케이션(722)은 그가 계산하는 데이터를 업로드하기 위해 전화 SL(713) 상에 컨테이너를 생성한다. 건강 보험 애플리케이션(722)은 콘텐츠 인스턴스가 HealthScore(757)의 타입을 갖는다는 것을 지시한다. 이 <healthS>(767) 컨테이너 아래의 모든 콘텐츠 인스턴스는 동일한 시멘틱을 가지므로, 시멘틱은 도 37에 도시된 바와 같이 각각의 콘텐츠 인스턴스 대신에 <healthS>(767) 컨테이너와 관련된다.

주변 센서 애플리케이션(717)이 체육관 SL(718)에 등록할 때, 그는 그의 시멘틱을 등록 메시지 내에 첨부한다. 주변 센서(716)는 DeviceApp(753)의 타입을 갖는다. DeviceApp(753) 클래스의 스키마를 따름으로써, 주변 센서(716)는 그가 온도 데이터를 생성할 수 있다는 것을 체육관 SL(718)에 지시한다. 체육관 SL(718)은 도 38에 도시된 바와 같이 주변 센서(716)에 대한 애플리케이션 자원(예로서, <sensor>(771))을 생성할 수 있다. 주변 센서 애플리케이션(717)은 그가 측정하는 데이터를 업로드하기 위해 체육관 SL(718) 상에 컨테이너를 생성한다. 주변 센서 애플리케이션(717)은 콘텐츠 인스턴스가 temperatureINCelsius(755)의 타입을 갖는다는 것을 지시한다. 이 <tempReading>(774) 컨테이너 아래의 모든 콘텐츠 인스턴스는 동일한 시멘틱을 가지므로, 시멘틱은 도 38에 도시된 바와 같이 각각의 콘텐츠 인스턴스 대신에 <tempReading>(774) 컨테이너와 관련된다.

유사하게, 트레드밀 애플리케이션(714)이 체육관 SL(718)에 등록할 때, 그는 그의 시멘틱을 등록 메시지 내에 첨부한다. 트레드밀(715)는 DeviceApp(753)의 타입을 갖는다. DeviceApp(753) 클래스의 스키마를 따름으로써, 트레드밀(715)는 그가 체육관 훈련 프로그램 데이터를 생성할 수 있다는 것을 체육관 SL(718)에 지시한다. 체육관 SL(718)은 도 38에 도시된 바와 같이 트레드밀(715)에 대한 애플리케이션 자원(예로서, <treadmill>(775))을 생성할 수 있다. 트레드밀 애플리케이션(714)은 그가 측정하는 데이터를 업로드하기 위해 체육관 SL(718) 상에 컨테이너를 생성한다. 트레드밀 애플리케이션(714)은 콘텐츠 인스턴스가 GymTrainingProgram(756)의 타입을 갖는다는 것을 지시한다. 이 <gymTraining>(777) 컨테이너 아래의 모든 콘텐츠 인스턴스는 동일한 시멘틱을 가지므로, 시멘틱은 도 38에 도시된 바와 같이 각각의 콘텐츠 인스턴스 대신에 <gymTraining>(777) 컨테이너와 관련된다.

흐름도들, 예로서 도 34-도 35에 도시된 단계들을 수행하는 엔티티들은 도 39c 또는 도 39d에 도시된 것들과 같은 장치, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(예로서, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것을 이해한다. 즉, 본 명세서, 예로서 도 34-도 35 등에서 예시되는 방법(들)은 도 39c 또는 도 39d에 도시된 장치 또는 컴퓨터 시스템과 같은 컴퓨팅 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능 명령어들은 컴퓨팅 장치의 프로세서에 의해 실행될 때 도 34-도 35 또는 다른 도면들에 도시된 단계들을 수행한다. 일례에서, M2M 장치들의 상호작용과 관련된 아래의 추가 상세와 관련하여, 도 35의 AE(741)는 도 39a의 M2M 단말기 장치(18) 상에 존재할 수 있고, 도 35의 CSE(732) 및 Sscl(742)은 도 39a의 M2M 게이트웨이 장치(14) 상에 존재할 수 있다.

본 명세서에 나오는 청구항들의 범위, 해석 또는 응용을 전혀 제한하지 않고서, 본 명세서에서 개시되는 예들 중 하나 이상의 예의 기술적 효과는 시멘틱이 관리되는 방식에 대한 조정을 제공하는 것이다. 시멘틱 정보(및 관련 지능)는 특수 엔티티(예로서, 시멘틱 노드)에 의해 처리 또는 저장될 수 있다. 본 명세서에서 개시되는 개념들 중 하나 이상의 개념의 기술적 효과는 통상적인 구현들에 비해, CSE가 본 명세서에서 설명되는 바와 같은 시멘틱 노드 또는 시멘틱 계층구조를 지원할 경우, 자원 계층구조가 더 유연한 방식으로 조직될 수 있어서, 시멘틱 정보가 더 효율적으로 액세스, 배포 또는 저장될 수 있다는 것이다.

본 명세서에서는 3GPP 및 ETSI M2M 아키텍처들이 배경을 통해 설명되고, 본 명세서에서 설명되는 발명을 예시하는 데 사용될 수 있지만, 본 명세서에서 설명되는 발명의 구현들은 본 개시 내용의 범위 내에서 유지되면서 변경될 수 있다는 것을 이해한다. 이 분야의 기술자는 개시되는 발명이 전술한 3GPP 또는 ETSI M2M 아키텍처들을 이용하는 구현들로 한정되는 것이 아니라, oneM2M, MQTT(message queuing telemetry transport) 및 다른 M2M 시스템들 및 아키텍처들과 같은 다른 아키텍처들 및 시스템들에서 구현될 수 있다는 것도 인식할 것이다.

도 39a는 시멘틱과 같은 하나 이상의 개시된 개념이 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술은 IoT/WoT에 대한 빌딩 블록을 제공하며, 임의의 M2M 장치, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트는 물론 IoT/WoT 서비스 계층 등일 수 있다.

도 39a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예로서, 이더넷, 광섬유, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 또는 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들면, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 또는 방송 등과 같은 콘텐츠를 다중 사용자에게 제공하는 다중 액세스 네트워크를 포함할 수 있다. 예를 들면, 통신 네트워크(12)는 코드 분할 다중 접속(CDMA), 시분할 다중 접속(TDMA), 주파수 분할 다중 접속(FDMA), 직교 FDMA(OFDMA), 및 단일 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 지역 네트워크, 융합 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크를 포함할 수 있다.

도 39a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 기반구조 도메인 및 필드 도메인을 포함할 수 있다. 기반구조 도메인은 말단 대 말단 M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 통상적으로 M2M 게이트웨이 뒤의 지역 네트워크들을 지칭한다. 필드 도메인은 M2M 게이트웨이(14) 및 단말기 장치(18)를 포함할 수 있다. M2M/IoT/WoT 통신 시스템(10)에는 몇 개의 M2M 게이트웨이 장치(14) 및 M2M 단말기 장치(18)라도 원하는 대로 포함될 수 있음이 인식될 것이다. M2M 게이트웨이 장치(14) 및 M2M 단말기 장치(18)는 각각 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호를 송신 및 수신하도록 구성된다. M2M 게이트웨이 장치(14)는 고정 네트워크 M2M 장치(예를 들어, PLC)는 물론 무선 M2M 장치(예를 들어, 셀룰러 및 비셀룰러)가 통신 네트워크(12) 또는 직접 무선 링크과 같은 운영자 네트워크를 통해 통신할 수 있게 한다. 예를 들면, M2M 장치들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집하고 그 데이터를 M2M 애플리케이션(20) 또는 M2M 장치들(18)에 송신할 수 있다. M2M 장치 (18)는 또한 M2M 애플리케이션(20) 또는 M2M 장치(18)에서 데이터를 수신할 수 있다. 또한, 후술하는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 및 그로부터 데이터 및 신호가 송신 및 수신될 수 있다. M2M 장치(18) 및 게이트웨이(14)는 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 유선을 포함하여 다양한 네트워크를 통해 통신할 수 있다.

도 39b를 참조하면, 필드 도메인 내의 예시된 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')은 하나 이상의 서버, 컴퓨터, 가상 기계(예로서, 클라우드/컴퓨트/저장 팜 등) 등에 의해 구현될 수 있다.

또한 도 39b를 참조하면, M2M 서비스 계층(22, 22')은 다양한 애플리케이션 및 수직이 활용할 수 있는 핵심 집합의 서비스 전달 기능을 제공한다. 이들 서비스 기능은 M2M 애플리케이션(20, 20')이 장치들과 상호작용하고 데이터 수집, 데이터 분석, 장치 관리, 보안, 과금, 서비스/장치 탐색 등과 같은 기능을 수행 가능하도록 한다. 본질적으로, 이들 서비스 기능은 이들 기능을 구현하는 애플리케이션의 부담을 제거하여, 애플리케이션 개발을 간략화하고 시판 비용 및 시간을 감소시킬 수 있다. 서비스 계층(22, 22')은 또한 서비스 계층(22, 22')이 제공하는 서비스와 관련하여 M2M 애플리케이션(20, 20')이 다양한 네트워크(12, 12')를 통해 통신 가능하도록 한다.

일부 예들에서, M2M 애플리케이션(20, 20')은 본 명세서에서 설명되는 바와 같이 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들을 이용하여 통신하는 원하는 애플리케이션을 포함할 수 있다. M2M 애플리케이션(20, 20')은 제한 없이, 운송, 건강 및 웰니스, 접속형 홈(connected home), 에너지 관리, 자산 추적, 보안 및 감시와 같은 다양한 산업에서의 애플리케이션들을 포함할 수 있다. 전술한 바와 같이, 시스템의 장치, 게이트웨이, 및 다른 서버에서 실행하는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 장치 관리, 보안, 과금, 위치 추적/지오펜싱(location tracking/geofencing), 장치/서비스 탐색, 및 레거시 시스템 통합과 같은 기능을 지원하고, 이러한 기능을 서비스로서 M2M 애플리케이션(20, 20')에 제공한다.

본원의 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층(예로서, 전화 SL(713) 또는 체육관 게이트웨이 서비스 계층(179))은 한 세트의 애플리케이션 프로그래밍 인터페이스(API) 및 기본 네트워킹 인터페이스를 통해 부가 가치 서비스 기능을 지원하는 소어 미들웨어 계층이다. M2M 엔티티(예로서, 하어와 소어의 결합에 의해 구현될 수 있는 장치, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M 및 oneM2M 양자는 본원의 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들을 포함할 수 있는 서비스 계층을 이용한다. ETSI M2M의 서비스 계층은 서비스 기능 계층(SCL)으로 지칭된다. SCL은 (장치 SCL(DSCL)로 지칭되는) M2M 장치, (게이트웨이 SCL(GSCL)로 지칭되는) 게이트웨이 및/또는 (네트워크 SCL(NSCL)로 지칭되는) 네트워크 노드 내에서 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능(CSF)(즉, 서비스 능력)을 지원한다. 하나 이상의 특정 유형의 CSF의 세트의 인스턴스화는 상이한 유형의 네트워크 노드들(예로서, 기반구조 노드, 중간 노드, 애플리케이션 고유 노드) 상에서 호스트될 수 있는 공통 서비스 엔티티(CSE)로 지칭된다. 또한, 본원의 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들은 서비스 지향 아키텍처(SOA) 및/또는 자원 지향 아키텍처(ROA)를 이용하여 본원의 시멘틱 구현들과 같은 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 39c는 M2M 단말기 장치(18)와 같은 일례의 M2M 장치(30)의 시스템도이다. 도 39c에 도시된 바와 같이, M2M 장치(30)는 프로세서(32), 송수신기(34), 송신/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비-이동식 메모리(non-removable memory)(44), 이동식 메모리(46), 전원(48), 위성 위치 확인 시스템(GPS; global positioning system) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 장치(30)가 개시되는 발명과 일관성을 유지하면서 전술한 구성 요소의 어떠한 세부 조합이라도 포함할 수 있음이 인식될 것이다. (시계(710), 전화(712), 주변 센서(716), M2M 장치(171), M2M 서버(170), M2M 게이트웨이(172), Sscl(742), AE(741), CSE(732) 등과 일관된) M2M 장치(30)는 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들을 위한 개시되는 시스템들 및 방법들을 이용하는 장치일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적의 프로세서, 통상의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연동된 하나 이상의 마이크로프로세서, 제어기, 마이크로컨트롤러, 주문형 집적 회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA) 회로, 어떤 다른 형태의 집적 회로(IC), 및 상태 기계(state machine) 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리, 및/또는 M2M 장치(30)가 무선 환경에서 동작 가능하도록 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 송신/수신 요소(36)에 결합될 수 있는 송수신기(34)에 결합될 수 있다. 도 39c가 프로세서(32)와 송수신기(34)를 별도의 구성 요소로 도시하지만, 프로세서(32)와 송수신기(34)가 전자 패키지 또는 칩에 함께 통합될 수 있음이 인식될 것이다. 프로세서(32)는 애플리케이션 계층의 프로그램(예를 들어, 브라우저) 및/또는 무선 액세스 계층(RAN) 프로그램 및/또는 통신을 수행할 수 있다. 프로세서(32)는 인증, 보안 키 합의 및/또는 예를 들어 액세스 계층 및/또는 애플리케이션 계층에서와 같은 암호화 동작과 같은 보안 동작을 수행할 수 있다.

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

또한, 도 39c에는 송신/수신 요소(36)가 단일 소자로 도시되어 있지만, M2M 장치(30)는 몇 개의 송신/수신 요소(36)라도 포함할 수 있다. 더 구체적으로, M2M 장치(30)는 MIMO 기술을 채용할 수 있다. 따라서, 일례에서, M2M 장치(30)는 무선 신호를 송신 및 수신하는 두 개 이상의 송신/수신 요소(36)(예를 들어, 다중 안테나)를 포함할 수 있다.

송수신기(34)는 송신/수신 요소(36)에 의해 전송되는 신호를 변조하고 송신/수신 요소(36)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 전술한 바와 같이, M2M 장치(30)는 다중 모드 기능을 가질 수 있다. 따라서, 송수신기(34)는 M2M 장치(30)가 예를 들어 UTRA 및 IEEE 802.11과 같은 다중 RAT를 통해 통신 가능하도록 하는 다중 송수신기를 포함할 수 있다.

프로세서(32)는 비-이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 어떠한 형태의 적절한 메모리에서도 정보를 액세스하고, 데이터를 그 내에 저장할 수 있다. 비-이동식 메모리(44)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 어떤 다른 형태의 메모리 저장 장치를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(SIM) 카드, 메모리 스틱, 및 보안 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 예에서, 프로세서(32)는 서버 또는 홈 컴퓨터와 같은 M2M 장치(30)에 물리적으로 배치되지 않은 메모리에서 정보를 액세스하거나 그 안에 데이터를 저장할 수 있다. 프로세서(32)는 본 명세서에서 설명되는 일부 예들에서의 시멘틱 관련 방법들이 성공적인지 또는 비성공적인지(예로서, 데이터 타입이 시멘틱에 적합한지, 시멘틱 정보, 또는 시멘틱의 표시를 수집하기 위해 다른 애플리케이션이 조회되었는지 또는 조회되어야 하는지)에 응답하여 디스플레이 또는 지시기(42) 상의 조명 패턴, 이미지 또는 컬러를 제어하거나, 시멘틱 노드들, 시멘틱 관련 자원들, 또는 시멘틱에 관한 관련 구현들의 상태를 지시하도록 구성될 수 있다. 디스플레이 또는 지시기(42) 상의 제어 조명 패턴, 이미지 또는 컬러는 본 명세서에서 예시되거나 설명되는 도면들(예로서, 도 1-도 38) 내의 임의의 방법 흐름 또는 컴포넌트의 상태를 반영할 수 있다. 본 명세서에서는 시멘틱 관련 자원 관리는 물론, 자원 시멘틱 정보 관리의 메시지들 및 절차들이 개시된다. 메시지들 및 절차들은 사용자들이 입력 소스(예로서, 스피커/마이크(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 자원 관련 자원들을 요청하거나, 디스플레이(42) 상에 표시될 수 있는 많은 것 가운데 특히 자원들의 시멘틱 정보를 요청, 구성 또는 질의하기 위한 인터페이스/API를 제공하도록 확장될 수 있다.

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

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

프로세서(32)는 추가 특징, 기능 및/또는 유선 또는 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변 장치(52)에 더 결합될 수 있다. 예를 들면, 주변 장치(52)는, 가속도계, 전자 나침반(e-compass), 위성 송수신기, 센서, 디지털 카메라(사진 또는 비디오용), 범용 직렬 버스(USB) 포트, 진동 장치, 텔레비전 송수신기, 핸즈프리 헤드셋, Bluetooth® 모듈, 주파수 변조(FM) 라디오 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 및 인터넷 브라우저 등을 포함할 수 있다.

도 39d는 예를 들어 도 39a 및 도 39b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예로서, M2M 단말기 장치(18) 또는 M2M 게이트웨이 장치(14))은 컴퓨터 또는 서버를 포함할 수 있고 소프트웨어가 어디서든, 또는 무슨 수단에 의하든 저장되거나 액세스되는 그러한 소프트웨어의 형태일 수 있는 컴퓨터 판독가능 명령에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능 명령은 컴퓨팅 시스템(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)(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)을 도 39a 및 도 39b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

본 개시의 발명의 바람직한 방법들, 시스템들 또는 장치들을 설명함에 있어서, 도면에 예시된 바와 같이, 명확성을 기하기 위해 특정 용어가 사용된다. 그러나, 청구된 발명은 그와 같이 선정된 특정 용어로 한정되는 것으로 의도되지 않고, 각각의 특정 구성 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물을 포함하는 것으로 이해되어야 할 것이다. 예로서, 시멘틱 관련 자원 공표 및 탐색의 타겟이 형제 및 자식인 것으로 예시되지만, 시멘틱 노드는 그러한 관계를 갖지 않을 수 있는 공표 및 탐색을 위한 다른 시멘틱 노드들을 선택할 수 있다.

본 서면의 설명은 최선의 방식을 포함하여 본 발명을 개시하고, 또한 통상의 기술자가 어떠한 장치 또는 시스템이라도 제조 및 이용하고 그리고 어떠한 통합 방법이라도 수행하는 것을 포함하여 본 발명을 실시 가능하도록 하는 예를 이용한다. 본 발명의 특허 범위는 청구항에 의해 정의되며, 통상의 기술자에게 가능한 다른 예들을 포함할 수 있다. 이러한 다른 예들은 이들이 청구항의 문어(literal language)와 다르지 않은 구조적 구성 요소를 갖는 경우나 이들이 청구항의 문어와 적은(insubstantial) 차이를 갖는 동등한 구조적 구성 요소를 포함하는 경우에 청구항의 범주 내에 있는 것으로 의도된다.

본 명세서에서 설명되는 바와 같은 방법들, 시스템들 및 장치들은 기기간(M2M) 시스템들에서 시멘틱 지원을 제공하는 시멘틱 노드 기능들을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 데이터에 대한 시멘틱 정보를 요청하기 위한 수단; 시멘틱 정보의 요청에 기초하여 데이터와 관련된 (시멘틱 정보의 일례인) 타입을 수신하기 위한 수단; 및 시멘틱 노드로부터 타입의 정의를 요청하기 위한 수단을 갖는다. 타입은 데이터와 관련된 유닛을 설명하는 키워드를 포함하는 이름을 갖는다. 데이터와 관련된 유닛은 온도에 대한 유닛 또는 혈압에 대한 유닛을 포함한다. 시멘틱 정보는 클래스 자원을 포함한다. 데이터는 시멘틱 정보와 함께 자원 계층 구조 내에 저장된다. 시멘틱 정보는 클래스 자원을 포함한다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 데이터와 관련된 타입이 제1 애플리케이션 엔티티에 적합한지를 결정하기 위한 수단을 가지며, 데이터는 제2 애플리케이션 엔티티로부터 유래된다. (단계들의 제거 또는 추가를 포함하는) 이 단락에서의 모든 조합들은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

본 명세서에서 설명되는 바와 같은, 특히 방법들, 시스템들 및 장치들은 기기간(M2M) 시스템들에서 시멘틱 지원을 제공하는 시멘틱 노드 기능들을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 애플리케이션 엔티티에 의해, 제2 애플리케이션 엔티티와 관련된 데이터를 수신하기 위한 수단; 제1 애플리케이션 엔티티에 의해, 데이터에 대한 시멘틱 정보를 요청하기 위한 수단; 제1 애플리케이션 엔티티에 의해, 시멘틱 정보의 요청에 기초하여 데이터와 관련된 타입을 수신하기 위한 수단; 제1 애플리케이션 엔티티에 의해, 데이터와 관련된 타입이 제1 애플리케이션 엔티티에 적합한지를 결정하기 위한 수단; 및 제1 애플리케이션 엔티티에 대한 적합성에 기초하여 시멘틱 노드로부터 타입의 정의를 요청하기 위한 수단을 갖는다. 타입은 데이터와 관련된 유닛을 설명하는 키워드를 포함하는 이름을 갖는다. 데이터와 관련된 유닛은 온도에 대한 유닛 또는 혈압에 대한 유닛을 포함한다. 시멘틱 정보는 클래스 자원을 포함한다. 데이터는 시멘틱 정보와 함께 자원 계층 구조 내에 저장된다. 시멘틱 정보는 클래스 자원을 포함한다. 제1 애플리케이션 엔티티는 센서와 관련된 애플리케이션을 포함한다. (단계들의 제거 또는 추가를 포함하는) 이 단락에서의 모든 조합들은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

본 명세서에서 설명되는 바와 같은, 특히 방법들, 시스템들 및 장치들은 기기간(M2M) 시스템들에서 시멘틱 지원을 제공하는 시멘틱 노드 기능들을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 데이터에 대한 시멘틱 정보를 요청하기 위한 수단; 시멘틱 정보의 요청에 기초하여 데이터와 관련된 타입을 수신하기 위한 수단; 제1 애플리케이션 엔티티에 의해, 데이터와 관련된 타입이 제1 애플리케이션 엔티티에 적합한지를 결정하기 위한 수단; 및 제1 애플리케이션 엔티티에 대한 적합성에 기초하여 시멘틱 노드로부터 타입의 정의를 요청하기 위한 수단을 갖는다. 타입은 데이터와 관련된 유닛을 설명하는 키워드를 포함하는 이름을 갖는다. 데이터와 관련된 유닛은 온도에 대한 유닛 또는 혈압에 대한 유닛을 포함한다. 시멘틱 정보는 클래스 자원을 포함한다. 데이터는 시멘틱 정보와 함께 자원 계층 구조 내에 저장된다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 데이터와 관련된 타입이 제1 애플리케이션 엔티티에 적합한지를 결정하기 위한 수단을 가지며, 데이터는 제2 애플리케이션 엔티티로부터 유래된다. (단계들의 제거 또는 추가를 포함하는) 이 단락에서의 모든 조합들은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims

기기간 환경에서 시멘틱을 제공하기 위한 장치로서,
프로세서; 및
상기 프로세서와 결합된 메모리
를 포함하고,
상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금,
제1 자원의 시멘틱 설명을 요청하는 동작 - 상기 시멘틱 설명은 상기 제1 자원의 시멘틱을 저장하고, 상기 시멘틱 설명은 제2 자원임 - ;
상기 시멘틱 설명의 요청에 응답하여, 공통 서비스 엔티티로부터 상기 시멘틱 설명을 수신하는 동작; 및
상기 시멘틱 설명의 수신에 응답하여, 시멘틱 노드로부터 상기 시멘틱 설명과 연관된 정의를 요청하는 동작
을 포함하는 동작들을 유발하게 하는 실행가능 명령어들을 포함하고,
상기 시멘틱 노드는 데이터를 기술하는 저장소인 장치.
삭제
제1항에 있어서,
상기 시멘틱 설명과 연관된 정의에 대한 요청은 상기 시멘틱 설명 내의 타입에 대한 표시에 기초하는 장치.
제1항에 있어서,
상기 제1 자원은 3중 저장소(triple store)에 기초하는 장치.
제1항에 있어서,
상기 시멘틱 노드는 3중 저장소를 포함하는 장치.
제1항에 있어서,
상기 제1 자원은 콘텐츠 인스턴스이고, 상기 콘텐츠 인스턴스는 콘테이너 자원의 자식 자원인 장치.
삭제
제1항에 있어서,
상기 제2 자원은 자식 가입 자원을 포함하는 장치.
기기간 환경에서 시멘틱을 제공하기 위해 장치 내에서 수행되는 방법으로서,
제1 자원의 시멘틱 설명을 요청하는 단계 - 상기 시멘틱 설명은 상기 제1 자원의 시멘틱을 저장하고, 상기 시멘틱 설명은 제2 자원임 - ;
상기 시멘틱 설명의 요청에 응답하여, 공통 서비스 엔티티로부터 상기 시멘틱 설명을 수신하는 단계; 및
상기 시멘틱 설명의 수신에 응답하여, 시멘틱 노드로부터 상기 시멘틱 설명과 연관된 정의를 요청하는 단계
를 포함하고,
상기 시멘틱 노드는 데이터를 기술하는 저장소인 방법.
제9항에 있어서,
상기 시멘틱 설명과 연관된 정의에 대한 요청은 상기 시멘틱 설명 내의 타입에 대한 표시에 기초하는 방법.
제9항에 있어서,
상기 제1 자원은 애플리케이션 엔티티 자원인 방법.
제9항에 있어서,
상기 제1 자원은 콘텐츠 인스턴스이고, 상기 콘텐츠 인스턴스는 콘테이너 자원의 자식 자원인 방법.
제9항에 있어서,
상기 시멘틱 설명은 제2 자원인 방법.
제9항에 있어서,
상기 제2 자원은 자식 가입 자원을 포함하는 방법.
삭제
삭제
삭제
삭제
삭제
삭제