KR101975291B1 - 서비스 레이어에서의 리소스 링크 관리 - Google Patents

Abstract

링크 관리 서비스는 링크 프로파일에 기초하여 하나 이상의 링크 인에블링 속성들을 동적으로 구성할 수 있다. 독립 링크 관리 및 통합 링크 관리와 같은 링크 관리 서비스를 지원하는 다수 타입들의 아키텍처가 존재할 수 있다.

Description

서비스 레이어에서의 리소스 링크 관리

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

본 출원은 2014년 12월 29일자로 출원된 "RESOURCE LINK MANAGEMENT AT SERVICE LAYER"라는 명칭의 미국 임시 출원 제62/097326호의 혜택을 주장하며, 그 내용들은 본 명세서에 참조로 원용된다.

배경기술

도 1은 서비스 레이어(104)를 지원하는 예시적인 프로토콜 스택을 도시한다. 도 1에 도시되는 바와 같이, 프로토콜 스택의 관점에서, 서비스 레이어는 애플리케이션 프로토콜 레이어 위에 놓일 수 있고 애플리케이션들 또는 다른 서비스 레이어에 부가 가치 서비스들을 제공할 수 있다.

M2M/IoT 서비스 레이어는 M2M/IoT 타입 디바이스들 및 애플리케이션들을 타겟으로 하는 예시적인 서비스 레이어이다. 도 2는 네트워크 내의 예시적인 M2M/IoT 서비스 레이어 배치를 도시한다. 본 예에서, 서비스 레이어 인스턴스는 서비스 레이어의 실현이고, 네트워크 애플리케이션들, 디바이스 애플리케이션들에 뿐만 아니라 네트워크 노드들 자체에 부가 가치 서비스들을 제공하기 위해 다수의 서비스 레이어 인스턴스들이 다양한 네트워크 노드들(예를 들어, 게이트웨이들 및 서버들) 상에 배치된다. 업계 표준 기관들(예를 들어, oneM2M-TS-0001 oneM2M Functional Architecture-V-0.8.0)은 M2M/IoT 타입들의 디바이스들 및 및 애플리케이션들을 인터넷, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M/IoT 서비스 레이어들을 개발해 왔다. M2M 서비스 레이어는 애플리케이션들 및 디바이스들에게 서비스 레이어에 의해 지원되는 M2M 지향 능력들의 수집(collection)에 대한 액세스를 제공할 수 있다. 이러한 능력들의 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급, 및 접속성 관리를 포함한다. 이러한 능력들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 사용하는 API들(application program interfaces)을 통해 애플리케이션들에 이용가능하게 될 수 있다.

oneM2M의 목표는 하드웨어 장치 및 소프트웨어 모듈들 내에 용이하게 내장될 수 있는 공통 서비스 레이어가 전 세계의 M2M 애플리케이션 서버들과 그 분야에서의 다양한 디바이스들을 지원할 필요성에 대처하는 기술 사양들을 개발하는 것이다. oneM2M 공통 서비스 레이어는, 도 3에 도시되는 바와 같이, 등록(101) 및 위치(103)과 같은, CSF들(common service functions)(예를 들어, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화는 상이한 타입들의 네트워크 노드들(예를 들어, IN(Infrastructure Node), MN(Middle Node), 및 ASN(Application-Specific Node)) 상에서 호스팅될 수 있는 CSE(common services entity)로서 참조된다. CSE들은 IN-CSE, MN-CSE, 또는 ASN-CSE라고 불릴 수 있다. 도 4의 AE, CSE, 및 NSE 엔티티들은, 시스템에서 그들 각각의 기능들을 수행하도록, 기본 디바이스 또는 플랫폼 상에 실행되는, 소프트웨어의 형태로 구현되는 논리 엔티티들이다. AE, CSE 및 NSE 엔티티들은 네트워크에서의 독립형 컴퓨팅 디바이스(예를 들어, 서버) 상에 호스팅될 수 있거나 또는 M2M 게이트웨이, M2M 디바이스, M2M 서버 등과 같이 네트워크 내의 기존 엔티티 상에 호스팅될 수 있는 논리 엔티티들이다.

도 4는 oneM2M 서비스 레이어 ROA(resource-oriented architecture)를 도시한다. 리소스는 CRUD(Create, Retrieve, Update, and Delete)와 같이 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처에서의 고유하게 어드레스 지정가능한 엘리먼트이다. 이러한 리소스들은 URI들(universal resource identifiers)을 사용하여 어드레스 지정가능하게 될 수 있다. 리소스는 자식 리소스 및 속성을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)가 있는 리소스이다. 부모 리소스 표현은 그 자식 리소스들에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 " 속성들(attributes)"의 세트를 지원한다. 속성들은 다른 리소스를 참조하는 하나 이상의 URI들을 저장할 수 있다.

최근에, 도 5에 도시되는 바와 같이, M2M 서비스 컴포넌트 아키텍처는, RESTful 기반이 아닌 레거시 배치를 고려하도록 개발되고 있으며, 이는 CSE가 서비스 컴포넌트들의 세트로서 간주되는 인프라스트럭처 도메인에 주로 적합하다. 이것은 도 4에 도시되는 서비스 레이어 아키텍처를 주로 재사용하지만, 서비스 레이어 내에서, 이것은 다양한 M2M 서비스들을 포함하고, 다수의 서비스들이 서비스 컴포넌트들로 그룹화할 수 있다. 기존의 참조 포인트들에 추가적으로, 도 5에서의 CSE는 서비스간 참조 포인트 Msc를 포함한다. (Msc 참조 포인트를 통과하는) M2M 서비스 컴포넌트들 사이의 통신은 웹 서비스 접근방식을 사용할 수 있으며, 이는 SoA(service-oriented architecture) 기반 시스템들을 구축하기 위한 통상적인 기술이다.

본 명세서에는 링크 프로파일에 기초하여 하나 이상의 링크 인에이블링 속성들을 동적으로 구성할 수 있는 LMS(link management service)가 개시된다. 독립 링크 관리 및 통합 링크 관리와 같이 LMS를 지원하는 다수 타입들의 아키텍처들이 존재할 수 있다.

예에서, 디바이스는 프로세서 및 이러한 프로세서와 연결되는 메모리를 포함할 수 있다. 메모리는 프로세서에 의해 실행될 때 프로세서로 하여금 제1 프로파일을 수신하는 단계- 제1 프로파일은 속성의 링크를 구성하는 것을 정의하는 명령어들을 포함하고, 속성의 링크는 제1 리소스로 향함 -; 속성을 관리하라는 표시를 수신하는 단계; 및 제1 프로파일에 기초하여 속성의 구성을 자동으로 결정하는 단계를 포함하는 동작들을 시행하게 하는 실행가능 명령어들을 포함한다.

다른 예에서, 방법은 제1 링크 프로파일을 수신하는 단계- 제1 링크 프로파일은 제1 리소스의 링크의 사용을 구성하는 것을 정의하는 명령어들을 포함하고, 제1 리소스의 링크는 제2 리소스로 향함 -; 링크를 관리하라는 표시를 수신하는 단계; 및 제1 링크 프로파일에 기초하여 링크의 사용을 자동으로 관리하는 단계를 포함한다.

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

첨부 도면들과 함께 예에 의해 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 서비스 레이어를 지원하는 예시적인 프로토콜 스택을 도시한다.
도 2는 네트워크 내의 예시적인 M2M/IoT 서비스 레이어 배치를 도시한다.
도 3은 oneM2M 서비스 레이어에서의 예시적인 CSF들(common services functions)을 도시한다.
도 4는 예시적인 oneM2M 서비스 레이어 리소스 지향 아키텍처를 도시한다.
도 5는 예시적인 oneM2M 서비스 컴포넌트 아키텍처를 도시한다.
도 6은 속성을 통해 2개의 리소스들 사이에 구축되는 예시적인 링크를 도시한다.
도 7a는 <subscription1> 리소스로부터 <AE1> 및 <accessControlPolicy1> 리소스들로 유래하는 다수 링크들의 예시적인 도면이다.
도 7b는 <subscription1> 리소스로부터 <AE1> 및 <AE2>로 유래하는 다수 링크들의 예시적인 도면이다.
도 8은 LMS를 구현하는 예시적인 시스템을 도시한다.
도 9는 독립 링크 관리의 예시적인 아키텍처 프레임워크를 도시한다.
도 10은 통합 링크 관리의 예시적인 아키텍처 프레임워크를 도시한다.
도 11은 단일 M2M/IoT 노드 상의 통합 링크 관리의 예시적인 아키텍처 프레임워크를 도시한다.
도 12는 링크 관리 태스크를 생성하기 위한 예시적인 메시지 흐름을 도시한다.
도 13은 스케줄-기반 링크 프로파일에 기초하여 링크 관리를 수행하기 위한 예시적인 메시지 흐름을 도시한다.
도 14는 비-스케줄-기반 링크 프로파일에 기초하여 링크 관리를 수행하기 위한 예시적인 메시지 흐름을 도시한다.
도 15는 링크 관리 태스크를 삭제하기 위한 예시적인 메시지 흐름을 도시한다.
도 16은 LMS로 링크 출처 리소스를 삭제하기 위한 예시적인 메시지 흐름을 도시한다.
도 17은 SLMP를 제출, 업데이트, 또는 삭제하기 위한 요청을 수신할 때 LMS의 관련 액션들에 대한 예시적인 방법을 도시한다.
도 18은 링크 프로파일, SLMP, 및 EHR 사이의 예시적인 상호작용들을 도시한다.
도 19는 oneM2M 서비스 레이어에서의 예시적인 (LMS) CSF를 도시한다.
도 20은 <linkProfile>의 예시적인 RESTful 리소스 기반 인터페이스를 도시한다.
도 21은 <SLMP>의 예시적인 RESTful 리소스-기반 인터페이스를 도시한다.
도 22는 <EHR>의 예시적인 RESTful 리소스 기반 인터페이스를 도시한다.
도 23은 예시적인 oneM2M 서비스 컴포넌트 아키텍처를 도시한다.
도 24는 LMS-SLMP에 의해 인에이블되는 부가 가치 서비스에 대한 예시적인 메시지 흐름을 도시한다.
도 25는 LMS-링크 프로파일에 의해 인에이블되는 부가 가치 서비스에 대한 예시적인 메시지 흐름을 도시한다.
도 26은 <group> 리소스의 "memberList"에 대한 LMS의 예시적인 동작을 도시한다.
도 27은 리소스 링크 관리를 이용하기 위한 예시적인 사용자 인터페이스를 도시한다.
도 28a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to-machine) 또는 IoT(Internet of Things) 통신 시스템의 시스템 도면이다.
도 28b는 도 28a에 도시되는 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 28c는 도 28a에 도시되는 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도면이다.
도 28d는 도 28a의 통신 시스템의 양상들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

oneM2M-TS-0001 oneM2M Functional Architecture-V-0.8.0에서, 이것은 리소스들 사이에 링크들이 구축될 수 있고, 리소스는 다른 리소스를 향해 하나 이상의 링크들을 가질 수 있다는 점을 나타낸다. 본 명세서에서 고려되는 링크는 다른 리소스로 향하는 하나의 리소스의 속성에 URI를 저장할 때 2개 리소스들 사이에 구축될 수 있다. 예를 들어, 리소스-A의 속성(예를 들어, 속성-1)에 리소스-B의 URI를 할당하는 것에 의해 리소스-A로부터 리소스-B로 링크가 구축될 수 있다. LMS에 링크 프로파일을 제출하는 것을 통해 링크 관리 태스크가 엔티티에 의해 구축될 수 있다. 링크 관리 태스크는 LMS가 하나 이상의 속성들에 대해 그 (그들의 공유된) 링크 프로파일에 기초하여 구성들을 수행하는 것을 참조할 수 있다. (엔티티에 의해) LMS로부터 대응 링크 프로파일이 삭제되면 LMS로부터 태스크가 삭제될 수 있다. 도 6은 2개의 리소스들 사이의 예시적인 링크를 도시한다. 도 6에 도시되는 바와 같이, 리소스-A(111)의 속성(속성-1(115))에 리소스-B(113)의 URI를 할당하는 것에 의해 리소스-A(111)로부터 리소스-B(113)로 논리 링크(112)가 구축된다. 본 명세서에서 리소스-A(111)는 링크 출처 리소스이고, 리소스-B(113)는 링크 목적지 리소스이며, 속성-1(115)은 논리 링크(112)의 링크 인에블링 리소스(속성-1(115)에서의 URI의 표현)이다. 도 6에 관한 예에 의해 뒷받침되는 바와 같이, 링크 출처 리소스는 다른 리소스(예를 들어, 리소스-B(113))로 향하는 URI를 포함하는 속성 등(예를 들어, 속성-1(115))을 저장하는 리소스(예를 들어, 리소스-A(111))이다. 링크 인에블링 속성은 리소스(예를 들어, 리소스-B(113))에 링크하고 다른 리소스(예를 들어, 리소스-A(111)) 내에 위치되는 URI를 저장하는 속성 등(예를 들어, 속성-1(115))이다. 마지막으로, 링크 목적지 리소스는 리소스(예를 들어, 리소스-A(111)) 내에 위치되는 URI의 목적지인 리소스(예를 들어, 리소스-B(113))이다.

표 1은 링크들을 구축하는데 사용될 수 있는 oneM2M 사양으로부터의 예시적인 속성들을 제공한다. 도 7a는 표 1로부터 취해지는 링크 인에블링 속성들이 있는 예를 도시한다. 도 7a에 도시되는 바와 같이, <subscription1> 리소스의 2개 속성들(예를 들어, "parentID" 및 "accessControlPolicyID")은 <AE1> 및 <accessControlPolicy1> 리소스들의 URI들로 각각 설정되었다. 이에 따라 2개 링크들이 <subscription1>과 2개의 리소스들(예를 들어, <AE1> 및 <accessControlPolicy1>) 사이에 구축된다. 도 7b는 도 7a와 유사하며, 비-스케줄-기반 링크 프로파일 링크 프로파일들에 관하여 이하 보다 상세히 논의될 것이다.

링크 프로파일에 기초하여 하나 이상의 링크 인에블링 속성들을 동적으로 구성할 수 있는 LMS(link management service)가 개시된다. 독립 링크 관리 및 통합 링크 관리와 같이 LMS를 지원하는 다수 타입들의 아키텍처들이 존재할 수 있다. 독립 링크 관리 및 통합 링크 관리는 본 명세서에서 보다 상세히 논의된다.

도 8은 LMS를 구현하는 예시적인 시스템을 도시한다. M2M 서버(124)는 링크 관리와 관련된 발신자(123)를 포함할 수 있다. 발신자(123)는 M2M 서버(124) 내에 위치될 수 있고, 다른 디바이스들 중에서, M2M 게이트웨이(122), M2M 디바이스(125), M2M 디바이스(126), 및 M2M 디바이스(127)에 통신 가능하게 접속될 수 있다. 발신자(123)는 서비스를 위한 애플리케이션(예를 들어, 애플리케이션 엔티티-AE)일 수 있다. 발신자(123)는, 1) LMS(121)에 링크 프로파일(예를 들어, 링크 프로파일(128))을 제출하거나, 2) 링크 프로파일을 업데이트하거나, 또는 3) LMS(121)로부터 링크 프로파일을 삭제 또는 등록 해제하기 위한 요청들을 착수할 수 있다. 요약하면, 발신자(123)는 링크 관리 관련 요청을 초기화한다. 발신자(123)는 링크 관리 관련 요청을 착수하기 위한 권한을 가질 것이다. 대안적으로, 발신자(123)는 이 리소스의 소유자이기 때문에 링크 인에블링 속성(예를 들어, 속성-1(115))이 속하는 링크 출처 리소스(예를 들어, 리소스-A(111))를 생성하는 엔티티일 수 있다. 발신자(123)는 속성에 대한 링크 관리를 착수할 수 있는 임의의 수의 엔티티들 또는 디바이스들(예를 들어, AE, 공통 서비스 엔티티-CSE, 네트워크 서비스 엔티티-NSE, M2M 서버, M2M 게이트웨이, M2M 디바이스 등)일 수 있다.

M2M 게이트웨이(122)는 LMS(121)를 포함할 수 있다. LMS(121)는 링크 프로파일(128)을 포함할 수 있고, 다른 디바이스들 중에서, 발신자(123) 및 M2M 디바이스(125), M2M 디바이스(126), 및 M2M 디바이스(127)와 통신 가능하게 접속될 수 있다. LMS(121)는 발신자(123)에 의해 제출된 링크 프로파일(128)에 기초하여 속성-1(115)에 대한 링크 관리를 수행하는 것을 담당한다. LMS(121)는 링크 호스팅 CSE 또는 다른 CSE 상에 존재할 수 있다. 링크 호스팅 CSE는 링크 출처 리소스(예를 들어, 리소스-A(111)) 뿐만 아니라 그 링크 인에블링 속성(예를 들어, 속성-1(115))이 호스팅되는 곳이다. LMS(121)는 링크 프로파일(128)에 포함되는 명령어들에 기초하여 링크 구성들을 수행하는 실행기로서의 역할을 하며, 이는 본 명세서에 정의되는 바와 같은 특정 프로시저들을 통해 업데이트/삭제될 수 있다. M2M 디바이스(125), M2M 디바이스(126), 및 M2M 디바이스(127)는 M2M 게이트웨이(122) 및 그 서브컴포넌트들과 통신 가능하게 접속되며, 또한 M2M 서버(124) 및 그 서브컴포넌트들과 통신 가능하게 접속될 수 있다. 각각의 M2M 디바이스는 M2M 디바이스(125)에서 발견되는 바와 같은 링크 인에이블링 속성(예를 들어, 속성-1(115))이 있는 링크 출처 리소스(예를 들어, 리소스-A(111))를 가질 수 있다.

계속해서 도 8을 참조하면, 이하는 잔디 관리 서비스에 관하여 LMS를 사용하는 예이다. 예를 들어, M2M 디바이스(126), M2M 디바이스(127), 및 M2M 디바이스(125)는 바람 센서, 습도 센서, 또는 온도 센서와 같은 센서들일 수 있다. 센서 데이터에 관한 통지를 전송하기 위해 각각의 M2M 디바이스(125, 126, 및 127)에 의해 호스팅되는 <subscription> 리소스(예를 들어, 리소스-A(111))이 존재할 수 있다. 링크 프로파일들(예를 들어, 링크 프로파일(128))은 M2M 디바이스들(125, 126, 및 127) 상에 호스트팅되는 <subscription> 리소스들의 "통지 URI" 속성(예를 들어, 속성-1(115))에 대해 생성될 수 있다. 링크 프로파일들은 잔디 관리 서비스(예를 들어, 발신자(123))에 의해 행해진 잔디 관리 일정에 필요한 시기, 방법, 또는 통지들을 커스터마이징하는데 도움이 될 수 있는 정보가 존재할 수 있다. 이러한 링크 프로파일들은 LMS(121)에 제출되고, LMS(121)는 링크 프로파일들에 기초하여 링크를 관리한다.

도 9 및 도 10은 링크 관리의 아키텍처 프레임워크들을 도시한다. 도 9는 독립 링크 관리를 도시한다. 요약하면, 독립 링크 관리는 링크 프로파일들(예를 들어, 링크 프로파일(128))에 기초하여 링크 관리를 실행하지만, 링크 프로파일들 사의 충돌들을 고려하지 않는다. 도 9에 도시되는 바와 같이, 링크 프로파일(128)이 LMS(121)에 제출된다. 또한, 링크 프로파일(128)은 리소스-A(111)의 속성-1(115)을 정의한다. LMS(121)는 제출된 링크 프로파일(128)에 기초하여 속성-1(115)을 구성한다.

LMS는 또한 상이한 리소스들의 다수의 링크 인에이블링 속성들에 대해 통합 링크 구성들을 수행하는 능력을 갖는다. 통합 링크 관리(도 10)는, 이러한 다수의 링크 인에블링 속성들 상의 구성들이 영향을 받을 수 있고, 서로 상호 관련될 수 있으며, 따라서 링크 인에이블링 속성들 상의 구성들은 그들의 관련된 링크 프로파일들을 참조할 뿐만 아니라, 존재한다면, 시스템 전반의 특정 정책들에 또한 호환될 수 있을 것이다. 예를 들어, LMS는 모든 리소스들이 다른 CSE에 마이그레이션될 때 그들의 parentID 속성을 업데이트하는 것을 담당할 수 있다. 또한, LMS는 자신에게 제출된 커스터마이징된 정책, 또는 기존의 또는 미래의 표준 사양에 호환되는 정책을 따를 수 있다는 점을 주목할 가치가 있다.

도 10은 링크 관리를 위한 예시적인 강화된 또는 통합된 프레임워크를 도시한다. 본 예에서, 통합 프레임워크는 예외 처리 규칙들(EHR)(131), 서비스 레이어 전반 링크 관리 정책(SLMP)(133), 다수의 링크 프로파일들(예를 들어, 링크 프로파일(128) 및 링크 프로파일(136)), LMS(121), 속성-1(135)이 있는 리소스-Z(134), 및 속성-1(115)이 있는 리소스-A(111)를 포함한다. 도 11은 도 10에 도시되는 개념들을 M2M 또는 IoT 노드(예를 들어, M2M 게이트웨이(122))의 서비스 레이어 내에 한정되는 것으로서 도시한다. 링크 관리 프레임워크의 상이한 컴포넌트들이 이하 보다 상세히 설명된다. LMS(121)에 관하여, LMS(121)는 상이한 링크 인에블링 속성들을 그들의 링크 프로파일들에 따라 관리하는 것을 담당한다. 예를 들어, LMS(121)에서, 링크 프로파일들이 제출된 후, 제출된 링크 프로파일들 각각에 대응하는 구체적인 링크 관리 태스크들이 구축될 수 있다. 예를 들어, LMS(121)에서 링크 관리 태스크를 구축하는 것에 관하여, 프로파일은 상이한 앱들에게 최신 온도에 관해 통보하기 위해 <subscription> 리소스의 notificationURI 속성과 같은 속성을 구성하는 방법을 포함할 수 있다. 뒤따르게 될 구성 명령어는 notificationURI가 오전 9시부터 오후 3시까지 WeatherReport App의 URI로 설정되는 것을 포함할 수 있고, 오후 3시부터 오후 11시까지 TripPlanning App의 URI로 설정될 것이다. LMS는 그 링크 프로파일에서 명시되는 위에 언급된 명령어들을 따르는 것에 의해 이전에 언급된 구성들의 링크를 수행하는 동작들을 실행하도록 대응하는 디바이스를 초기화할 수 있다.

통상적으로, 리소스-A(111) 및 속성-1(115)이 이미 생성되었으면, 리소스-A(111)의 속성-1(115)에 대한 링크 프로파일(128)이 생성되어 LMS(121)에 제출될 수 있다. 이후에, 생성된 링크 인에블링 속성들(예를 들어, 속성-1(115))의 값들을 다른 엔티티들이 스스로 구성할 것을 요구하는 대신에, LMS(121)는 생성된 링크 인에블링 속성들을, 전술된 바와 같이 그들의 필요에 기초하여 특정 엔티티들에 의해 생성될 수 있는 링크 프로파일들(예를 들어, 링크 프로파일(128) 및 링크 프로파일(136))에 포함되는 사양에 기초하여 이러한 엔티티들 대신 구성할 수 있다. 다른 엔티티들은 그들의 필요에 기초하여 동적 링크 관리 동작들에 대해 LMS를 사용하는 애플리케이션 관련 소프트웨어 인스턴스 또는 CSE들 중 임의의 것일 수 있다. 예를 들어, 위 WeatherReport App 예를 여전히 사용하면, 온도 디바이스들을 관리하는 것을 담당하는 소프트웨어 인스턴스(다른 엔티티)는, 상이한 앱들(예를 들어, WeatherReport App 또는 TripPlanning App)에게 온도 센서로부터의 최신 업데이트들에 관하여 통보하기 위해, 구체적인 <subscription> 리소스의 "notificationURI 속성에 대한 링크 프로파일을 구축할 수 있다. LMS(121) 및 속성-1(115) (관리될 링크 인에블링 속성)이 동일 위치에 있으면(예를 들어, 리소스-A(111)가 LMS를 고유하게 지원하는 CSE 상에 있으면), 속성-1(115)이 CSE 내에 구성될 수 있고, 이는 통신 오버헤드를 줄여 준다. 또한, 컴퓨팅 리소스들이 존재하는 한, LMS(121)는 임의의 노드들(예를 들어, ASN-CSE, MN-CSE, 또는 IN-CSE) 상에 배치될 수 있다. 속성-1(115)은 현재 유효 값을 저장하며, 이는 그 링크 프로파일(128)에 따라 LMS(121)에 의해 동적으로 구성된다. LMS(121)에 의해 링크가 어떻게 구성되는지는 속성-1(115)의 값을 검색하기 위한 권한이 없는 한 숨겨질 수 있다.

SLMP(133)는 관련 속성들(예를 들어, 속성-1(115) 및 속성-1(135))에 대한 링크 구성들이 그들의 링크 프로파일들 외에도 또한 호환될 필요가 있는 규칙들 또는 제약들의 세트이다. SLMP는 이러한 속성들에 대해 독립적인 구성들을 수행하는데 사용되는 링크 프로파일들 외에도, 상이한 속성들에 대한 링크 구성들이 어떻게 서로 영향을 받을 수 있는지에 관한 글로벌 규칙들 및 제약들의 세트이다. 링크 프로파일(128)과 유사하게, SLMP(133)는 그렇게 하도록 허용되는 엔티티에 의해 LMS(121)에 또한 제출될 수 있다. SLMP(133)에 관한 예는 oneM2M의 "parentID"에 관련될 수 있다. SLMP(133)는 일부 애플리케이션 특정적 보안 이유로 인해 특정 세트의 리소스들(예를 들어, 리소스-Z(134))이 동일한 부모들을 다른 세트의 리소스들(예를 들어, 리소스-A(111))와 공유하는 것이 허용되지 않는다는 규칙을 포함할 수 있다.

계속해서 도 11 및 통합 링크 관리를 참조하면, EHR(131)은 링크 구성들에서의 예외들을 취급하는데 사용되는 규칙들을 갖는다. 주어진 SLMP에 대해, 대응하는 세트의 예외 처리 규칙들이 존재할 수 있으며, 이는 그렇게 하는 것이 허용되는 엔티티에 의해 LMS(121)에 또한 제출될 수 있다. LMS(121)가 특정 링크 인에블링 속성들(예를 들어, 속성-1(115) 또는 속성-1(135))을 구성할 때, LMS(121)는 관련 링크 프로파일들(예를 들어, 링크 프로파일(128) 및 링크 프로파일(136)) 뿐만 아니라 연관 SLMP들을 고려하고, 임의의 충돌이 존재하면 EHR들을 적용한다. EHR은 링크 프로파일들에 포함되는 독립적인 구성들이 SLMP와 충돌할 때 사용되는 규칙들의 세트이다.

때때로 바람직한 구현은 CSE에 의해 호스팅되는 모든 또는 대부분의 리소스들의 링크 인에블링 속성들의 링크 프로파일들을 동일한 LMS(예를 들어, LMS(121))에 제출되게 할 수 있고, 이러한 LMS 또한 관련 SLMP들 및 EHR들의 세트를 보유할 수 있다.

논의된 바와 같이, 링크 프로파일은 이 링크 인에블링 속성이 속하는 링크 출처 리소스를 생성하는 엔티티에 의해 생성되어, 링크 관리 태스크를 초기화하기 위해 LMS에 제출될 수 있다. 대안적으로, 링크 프로파일이 다수의 속성들과 관련될 수 있다는 의미에서 하나보다 많은 링크 인에블링 속성들을 구성하는데 링크 프로파일이 또한 사용할 수 있으며, 이러한 속성들에 대한 모든 링크 구성들(링크 프로파일에 의해 명시됨)은 같은 그룹 동작들일 것이다. 프레젠테이션을 단순화하기 위해, 본 명세서서 섹션들에서의 상세사항들을 소개할 때 기본 사례에 중점을 둔다.

스케줄 기반 링크 프로파일들 및 비 스케줄 기반 링크 프로파일들이 이하 논의된다. 이하 논의되는 2개 타입들의 링크 프로파일들은 예들이다. 상이한 애플리케이션 시나리오들에 따라 다양한 링크 프로파일들이 생성될 수 있다(예를 들어, 이벤트 또는 조건 기반 링크 프로파일들). 표 2는 상이한 타입들의 링크 프로파일들에 대한 공통 항목들을 나열한다. 표 2에서 더욱 설명되는 바와 같이, profileType(예를 들어, 1=스케줄 기반 프로파일, 2=비 스케줄 기반 프로파일), link OriginURI(예를 들어, 속성-1(115)에 대한 URI), 및 각각의 링크 프로파일 타입에 대한 attributeName이 존재할 수 있다.

스케줄-기반 링크 프로파일들에 관하여, 링크 인에이블링 속성이 스케줄-기반 링크 프로파일과 관련되면, 이러한 속성을 통해 구축되는 링크들은 구체적인 시간 간격들 동안 유효할 수 있다. 스케줄-기반 링크 프로파일들은 휴면 노드들(예를 들어, 휴면 타입 모드로 정기적으로 들어갈 수 있는 디바이스들)이 존재하는 시나리오들을 지원하는데 유용할 수 있다. 표 3은 스케줄-기반 링크 프로파일들에 대한 destURIList 및 validTimeIntervals를 포함하는 예시적 항목들을 제공한다.

비-스케줄-기반 링크 프로파일들에 관하여, 링크 인에블링 속성이 비-스케줄-기반 링크 프로파일과 관련되면, 이러한 속성을 통해 구축되는 링크들은 시스템에서의 실시간 콘텍스트 및 그 링크 프로파일에 정의되는 관련 규칙들에 기초하여 구성될 수 있다.

콘텍스트 정보를 고려할 수 있는 비-스케줄-기반 링크 프로파일들에 관한 추가의 관점에서, 도 7b를 참조하는 시나리오가 논의된다. 이러한 사용 사례에 대한 시나리오들 중 하나가 도 7b에 도시된다: MN-CSE 노드 상에 호스팅되는 <CSEBase1>의 자식 리소스인 <subscription> 리소스(예를 들어, <subscription1>). 특히, notificationURI 속성은 (ASN-CSE1에서 호스팅되는) <AE2>의 URI 또는 (ASN-CSE2에서 호스팅되는) <AE3>의 URI를 보유할 수 있으며 그 이유는 이들 양자 모두가 <CSEBase1>에 관심이 있기 때문이다. 그러나, notificationURI를 설정하는 방법은 콘텍스트 정보(예를 들어, 거의 실시간 조건들) 또는 임의의 사용자 정의 또는 애플리케이션 특정적 규칙들에 기초할 수 있다. 예를 들어, <AE1>은 (예를 들어, notificationURI 속성에 <AE1>의 URI를 할당하는) 주 통지 수신자일 수 있으며, notificationURI는 <AE1>이 도달할 수 없게 될 때마다 <AE2>의 URI로 동적으로 설정될 수 있다.

종래의 서비스 레이어 구현들은, 명시적 업데이트 동작들을 통하는 것 이외에, 전술된 링크 인에이블링 속성들(예를 들어, 도 7b에서의 notificationURI 속성)을 통해 동적으로 구성하기 위한 메커니즘들을 제공하지 않는다. 특히 종래의 구현들에서, 이러한 업데이트 동작들의 착수자가 관리될 리소스 및 대응하는 속성들을 호스팅하는 CSE(예를 들어, 도 7b에서의 MN-CSE)로부터 멀면, 이러한 빈번한 업데이트 동작들은 상당한 통신 오버헤드를 야기할 수 있다 .

oneM2M에 관하여, <subscription>의 종래의 구현들은 진보된 특징들을 지원하려는 시도에 있어서 "무겁다(heavy)". 예를 들어, notificationSchedule 자식 리소스 및 pendingNotification 속성은 통지들에 대한 일부 지능을 갖도록 <subscription>을 인에이블하는데 사용된다. (먼저 언급된 바와 같이 notificationURI를 동적으로 구성하는 것과 같이) 새로운 특징들에 대해 종래의 방식으로 점점 더 많은 새로운 속성들을 정의하면, 리소스가 훨씬 더 무거워질 수 있다. 개시된 링크 관리 서비스는 일반적으로 보다 확장될 수 있는 구현을 허용한다.

표 4는 비-스케줄-기판 링크 프로파일들에 대한 destURICandidateList, contextInfoURI, 및 linkSelectionRules를 포함하는 예시적 항목들을 제공한다.

도 12 내지 도 16과 같이, 본 명세서에 도시되는 단계들을 수행하는 엔티티들은, 도 28c 또는 도 28d에 도시되는 것들과 같은 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 점이 이해될 것이다. 일 예에서, M2M 디바이스들의 상호작용에 관해 이하의 보다 상세한 사항과 함께, 도 12의 발신자(123)(예를 들어, AE)는 도 28a의 M2M 단말 디바이스(18) 상에 존재할 수 있고, 한편 도 12의 CSE(109)는 도 28a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다.

링크 관리를 위한 프로시저들이 이하 도 12 내지 도 17과 함께 논의된다. 도 12는 LMS에 의해 속성의 URI를 관리하기 위한 링크 관리 태스크를 생성하기 위한 예시적인 흐름을 도시한다. 단계 203에서, 발신자(123)는 속성-1(115)에 대한 링크 관리 태스크를 생성하는데 사용될 수 있는 요청을 CSE(109)에 전송한다. 메시지는 링크 프로파일(128) 및 관련 데이터(예를 들어, 링크 프로파일 타입에 관한 관련 데이터)를 포함한다. 단계 203의 메시지는 발신자(123) 상의 애플리케이션 로직에 의해 트리거될 수 있다. 다른 예에서, LMS(121)는 링크 프로파일들을 사전에 수집할 수 있다. LMS(121)는 상이한 엔티티들로부터의 링크 프로파일들을 능동적으로 요청하거나 공개 또는 가입 메커니즘을 사용할 수 있다. 또 다른 경우에서, LMS(121)는 시스템 상태를 관찰하는 것에 의해 링크 프로파일(128)을 사전에 생성할 수 있다. 예를 들어, 발신자(123)(예를 들어, 애플리케이션 엔티티)가 때때로 오프라인이라는 점을 LMS(121)가 관찰하면, LMS(121)는 발신자(123)가 속하는 <group> 리소스의 "멤버 리스트"에 대한 링크 프로파일(128)을 셋업할 수 있어, 링크 프로파일(128)은 발신자(123)가 이용 가능하지 않을 때 발신자(123)의 URI(예를 들어, 속성-1(115))가 "멤버 리스트"에 존재하지 않을 구성들을 초래한다. 오프-라인 시간 동안 그룹 동작들이 발신자(123)에게 펼쳐지지 않을 것이라는 점이 결과일 수 있으며, 따라서 불필요한 통신이 감소된다.

단계 204에서, CSE(109)는 단계 203의 요청을 검증한다. 예를 들어, CSE(109)는 리소스-A(111) 및 속성-1(115)가 존재하는지, 발신자(123)가 이러한 동작에 대한 권한을 갖는지 등을 결정할 수 있다. 이들 중 어느 것도 참이 아니면, LMS(121)를 접촉하지 않고 CSE(109)에 의해 이러한 요청이 거절될 수 있다. 단계 205에서, CSE(109)는 링크 프로파일(128)을 LMS(121)에 전송한다. 단계 206에서, LMS는 링크 프로파일(128)을 검증한다. 예를 들어, LMS(121)는 링크 프로파일 속성-1(115)이 이미 이전에 제출된 다른 링크 프로파일과 관련하여 이미 관리되었는지 결정한다. 그렇다면, 이러한 새로운 제출된 프로파일(링크 프로파일(128))이 기존의 링크 프로파일을 대체하지 않으면, 단계 205의 요청은 LMS에 의해 거절될 수 있다. 그렇지 않으면, LMS(121)는, 1) 특정 규칙들/조건이 충족될 때, LMS(121)가 대응하는 링크 구성 동작들을 실행할 수 있도록, 링크 프로파일(128)에 따라 새로운 트리거들을 정의할 수 있고; 2) 속성-1(115)를 "관리형"(또는 다른 용어 또는 마킹)으로서 표시하여, 미래에 속성-1(115)에 관련된 임의의 다른 링크 프로파일들이 제출되면, LMS는 예전 링크 프로파일(128)을 대체하거나 또는 업데이트하는 것, 또는 새로운 것을 거절하는 것 등과 같은 동작들을 수행할 수 있고; 3) 이러한 링크 관리 태스크 대한 글로벌 참조로서 링크 관리 ID(이러한 값은 임의의 명명 스킴에 기초할 수 있음)를 생성할 수 있다(예를 들어, 엔티티는 링크 관리 ID를 명시하는 것에 의해 기존의 링크 관리 태스크를 삭제하라는 요청을 전송할 수 있음). 이하의 설명들은 링크 관리 ID를 언제 또는 어디서 사용할지에 관한 추가의 논의를 제공한다.

단계 207에서, LMS(121)는 링크 관리 태스크가 성공적으로 수립되었다는 점을 나타내는 확인을 링크 관리 ID와 함께 CSE(109)에 전송한다. 단계 208에서, CSE(109)는 속성-1(115)에 대해 구체적인 별도의 액세스 정책을 생성할 수 있거나, CSE(109)는 LMS(121)가 속성을 조작하기 위한 액세스를 가지며, 필요하다면, 다른 엔티티들에 대한 액세스를 제한하도록 기존의 액세스 제어 정책들을 수정할 수 있다. 이러한 구체적인 액세스 제어 정책들은 링크 관리 ID와 또한 관련될 수 있으며, 이는 증명 검증에 또한 사용될 수 있어, 그 요청에서 링크 관리 ID를 명시할 수 있는 것만 속성-1(115)의 구성들을 수행하는 것이 허용될 것이다. 단계 209에서, CSE(109)는 또한 속성-1(115)의 상태를 알기 위해 링크 관리 ID와 함께 확인을 발신자(123)에 되돌려 전송할 수 있다.

도 13은 스케줄-기반 링크 프로파일을 사용하여 링크 관리를 수행하기 위한 예시적인 방법을 도시한다. 단계 211에서, LMS(121)는 스케줄-기반 링크 프로파일(예를 들어, 링크 프로파일(128))에 기초하여 트리거된다. 예를 들어, LMS(121)는 속성-1(115)의 값을 업데이트하도록 타이머에 의해 트리거될 수 있다. 단계 212에서, LMS(121)는 속성-1(115)의 링크 프로파일(128)에 따라 속성-1(115)의 URI를 업데이트하라는 요청을 CSE(109)에 전송한다. 링크 관리 태스크 수립동안 생성되는 링크 관리 ID가 이러한 요청에 포함될 수 있어, CSE(109)가 속성-1(115) 상의 동작 권한을 점검할 수 있다. 단계 213에서, CSE(109)는 단계 212에서 제안된 동작이 허용되는지 결정한다. 그렇다면, 속성-1(115)의 값은 단계 212의 요청에서의 값으로 업데이트될 수 있다. 단계 214에서, CSE(109)는 요청된 동작의 성공 또는 실패에 관한 메시지를 LMS(121)에 되돌려 전송한다.

도 14는 비-스케줄-기반 링크 프로파일을 사용하여 링크 관리를 수행하기 위한 예시적인 방법을 도시한다. 단계 221에서, LMS(121)는 비-스케줄-기반 링크 프로파일(예를 들어, 링크 프로파일(128))에 기초하여 어느 콘텍스트 정보가 수집될 필요가 있는지 결정한다. 단계 223에서, LMS(121)는 (실시간으로 있을 수 있는) 콘텍스트 정보에 대한 쿼리를 전송한다. 콘텍스트 정보는, 다른 것들 중에서, 디바이스에 할당되는 대역폭, 통신 세션의 레이턴시(예를 들어, 애플리케이션의 지연 공차와 관련됨), 디바이스의 위치 또는 실행 상태, 디바이스의 전력 제어 요건들의 분류, 또는 비즈니스 로직에 영향을 줄 수 있는 관련 정보를 포함할 수 있다. LMS(121)는, 대안적으로, 요청된 실시간 정보의 제공자와 가입 관계를 수립할 수 있다. 본 명세서에서는 콘텍스트 정보를 수집하는 일부 엔티티들이 존재한다고 가정된다. 단계 225에서, 콘텍스트 제공자(105)는 단계 223의 요청에 기초하여 관련 콘텍스트 정보를 반환한다. 단계 226에서, LMS(121)는 콘텍스트 정보와, 속성-1(115)을 재구성하도록 LMS(121)를 트리거하는 비 스케줄 링크 프로파일에 명시되는 관련 규칙들을 비교한다. 단계 227에서, LMS(121)는 속성-1(115)의 값을 업데이트하라는 요청을 CSE(109)에 전송한다. 단계 228에서, CSE(109)는 단계 227의 수신된 요청을 점검하고, 요구되는 대로 속성-1(115)에 대한 업데이트 동작을 실행한다. 단계 229에서, CSE(109)는 단계 228과 관련된 동작들의 상태를 중계하라는 메시지를 전송할 수 있다.

도 15는 LMS에 의해 속성의 URI의 관리를 위해 링크 관리 태스크를 삭제하기 위한 예시적인 흐름을 도시한다. 단계 231에서, 발신자(123)는 속성-1(115)에 대한 링크 관리 태스크를 삭제하라는 요청을 CSE(109)에 전송한다. 단계 233에서, CSE(109)는 단계 231의 요청을 검증한다. 예를 들어, CSE(109)는 발신자(123)가 이러한 동작에 대한 권한을 갖는지 결정할 수 있다. 단계 235에서, CSE(109)는 LMS(121)에 링크 관리 태스크를 삭제하라는 요청을 전송한다. 단계 236에서, LMS(121)는 링크 프로파일(128) 및 관련 트리거들을 삭제한다. 단계 237에서, LMS(121)는 링크 관리 태스크가 성공적으로 삭제되었다는 점을 나타내는 확인을 CSE(109)에 전송하며, 이는 링크 관리 ID를 포함할 수 있다. 단계 238에서, CSE(109)는 속성-1(115)에 대해 구체적인 별도의 액세스 정책을 삭제할 수 있다. 속성-1(115)은 리소스-A(111)가 삭제되지 않는 한 여전히 존재할 수 있다. 단계 239에서, CSE(109)는 속성-1(115)의 상태를 알기 위해 링크 관리 ID와 함께 확인을 발신자(123)에게 되돌려 전송할 수 있다.

도 16은 링크 출처 리소스를 삭제하기 위한 예시적인 흐름을 도시한다. 단계 241에서, 발신자(123)는 링크 출처 리소스(예를 들어, 리소스-A(111))를 삭제하라는 요청을 CSE(109)에 전송한다. 단계 242에서, CSE(109)는 단계 241의 요청을 검증한다. 예를 들어, CSE(109)는 발신자(123)가 이러한 동작에 대한 권한을 갖는지 결정할 수 있다. 예를 들어, CSE(109)는 또한 삭제될 리소스-A(111)의 어떤 속성들이 LMS(121)에 의해 현재 관리되는지 점검할 수 있으며, 이는 이러한 속성들(예를 들어, 속성-1(115))에 대한 링크 관리 동작들에 대해 특수한 모든 액세스 제어 정책들(및 그들의 관련된 linkManagementID)을 검사하는 것에 의해 행해질 수 있다. 다음으로 이러한 linkManagementID(s)가 LMS(121)에 전송될 수 있다.

단계 243에서, CSE(109)는 리소스-A(111)를 삭제하라는 요청을 LMS(121)에 전송한다. 단계 244에서, LMS(121)는 수신된 linkManagementID(s)에 대응하여 관련 트리거들 및 관련 링크 프로파일들(예를 들어, 링크 프로파일(128))을 삭제한다. 또한, 리소스 삭제 동작은 다른 리소스들 및 링크들에 마찬가지로 영향을 줄 수 있으므로, 일부 서비스 레이어 전반 링크 관리 동작들이 또한 트리거될 수 있다. 단계 245에서, LMS(121)는 리소스-A(111)에 관련된 링크 관리 태스크들이 성공적으로 삭제되었음을 나타내는 확인을 CSE(109)에 전송한다. 단계 246에서, CSE(109)는 리소스-A(111)의 속성들의 링크 관리 동작들에 관련된 리소스-A(111)를 삭제한다. 단계 247에서, CSE(109)는 리소스-A(111)를 삭제하는 것에 관한 상태 메시지를 되돌려 전송할 수 있다.

주어진 링크 프로파일 P에 관련된 기존의 링크 관리 태스크에 대해, 업데이트 프로시저는 도 12에 관하여 제공되는 바와 같은 생성 프로시저와 유사하다는 점에 주목하자. 또한, 검색 동작은 그 대응하는 linkManagementID를 명시하는 것에 의해 LMS(121)로부터 링크 프로파일(128)을 검색 할 수 있다. LMS(121)로의/로부터의 SLMP(133) 또는 EHR(131)을 제출, 업데이트, 및 삭제하는 방법에 관련된 프로시저들은 링크 프로파일(128)에 대해 개시된 것들과 유사하다.

이하는 LMS에 의해 사용되는 SLMP, EHR 및 링크 프로파일들 사이의 상호작용들에 관한 추가의 논의이다. 도 17은 SLMP를 제출, 업데이트, 또는 삭제하기 위한 요청을 수신할 때 LMS(121)와의 관련 상호작용을 도시하는 예시적인 흐름도를 도시하며, 이는 또한 일부 간단한 수정들 이후 EHR에 적용될 수 있다.

단계 250에서, LMS(121)는 새로운/업데이트된 SLMP(133)를 수신하거나, 또는 LMS(121)에 저장된 기존의 SLMP(133)에 대한 삭제 요청을 수신한다. 단계 251에서, LMS(121)는 요청의 타입을 검사하며(예를 들어, 요청이 "CREATE"또는 "UPDATE"인지 보기 위함), 이는 새로운 SLMP(133)를 제출/생성하는 것(그렇다면, 단계 255로 진행함), 기존의 SLMP(133)를 업데이트하는 것(그렇다면, 단계 254 단계로 진행함), 또는 LMS(121)에 이미 저장된 SLMP(133)를 삭제하는 것(그렇다면, 단계 252로 진행함)일 수 있다.

단계 252에서, LMS(121)는 등록된 링크 프로파일들(예를 들어, 링크 프로파일(128) 및 링크 프로파일(136))을 검사하며, 이들은 SLMP(133)에 관련된다. 그렇게 하기 위해, SLMP(133)의 적용 범위가 이용될 수 있으며, 이는 SLMP(133)가 어느 속성에 적용될 수 있는지 표시한다. 예를 들어, 삭제될 SLMP(133)가 각각 리소스-A(111) 및 리소스-Z(134)의 속성-1(115) 및 속성-1(135)에 적용될 수 있으면, 상이한 리소스들의 속성-1의 링크 프로파일들이 검사되고 정리된다. 단계 253에서, LMS(121)는 SLMP(133)를 삭제할 뿐만 아니라, 단계 252에서 정렬되는 링크 프로파일들(예를 들어, 링크 프로파일(128) 및 링크 프로파일(136))에 기초하여 연관 링크 인에블링 속성들(속성-1(115) 및 속성-1(135))를 재구성하기도 한다. 특히, 이제 SLMP(133)가 존재하지 않으므로, 이러한 속성들의 값들은 그들의 링크 프로파일들에 기초하여 재설정될 것이다. 다음으로, 단계 251로 진행한다.

단계 254에서, LMS(121)는 기존의 SLMP(133)를 새롭게 수신되는 SLMP로 대체한다. 대안적으로, 기존의 SLMP(133)가 마찬가지로 단지 부분적으로 업데이트될 수 있다. 단계 255에서, LMS(121)는 이러한 새롭게 수신되는 SLMP에 관련되는 모든 링크 프로파일들을 정리하며, 그 상세한 프로세스는 단계 252에서 설명된 것과 유사하다.

단계 256에서, LMS(121)는 현재 링크 구성들이 이러한 SLMP(133)에 호환되는지 평가한다. 예를 들어, LMS(121)는 이러한 링크 프로파일들의 관련 속성들에 할당될 값들이 이러한 SLMP(133)에 의해 명시되는 정책들을 충족시키는지 평가할 수 있다. 예이면, 단계 260으로 진행한다. 그렇지 않으면, 일부 리소스들의 관련 속성들의 값들이 이러한 SLMP(133)에 의해 명시되는 정책들과 정렬되지 않거나 충돌된다는 것을 나타낸다. 따라서, 예외 취급 프로세스가 트리거된다(예를 들어, 단계 257로 진행함). 단계 257에서, LMS(121)는 EHR(131)이 존재하는지 점검한다(통상적으로, 특정 SLMP(133)가 EHR(131)과 관련될 수 있음). 예이면, 단계 258로 진행한다. 그렇지 않으면, 단계 259로 진행한다.

단계 258에서, LMS(121)는, 관련 속성들의 값들을 재구성하는데 뿐만 아니라, 이러한 수신된 SLMP(133)에 호환되지 않는 링크 프로파일들에 의해 명시되는 특정 구성들을 지원하기 위해 사용되는 일부 트리거들을 일시적으로 디스에이블하는데, 디폴트 예외 취급 규칙들을 사용할 수 있다. 단계 259에서, LMS(121)는 대응하는 EHR(131)을 직접 참조할 수 있고, 관련 동작들은 단계 258과 유사하다.

단계 260에서, LMS(121)는, 필요에 따라, 최신 SLMP(133)의 시스템에서의 다른 엔티티들에게, 미래에 SLMP(133)에 관련된 속성들에 대해 새로운 링크 프로파일들이 정의될 때, 이들이 더 이상의 충돌들을 회피하기 위해 최신 SLMP(133)를 따를 수 있도록 통보한다. 이전 단계들은 SLMP(133) 상의 관련 동작들(CREATE, UPDATE 또는 DELETE)에 의해 영향을 받을 수 있는 기존의 리소스들에 대한 링크 인에블링 속성들에 필요한 재구성들을 실행하는 것에 주로 중점을 두었다.

도 18은 링크 프로파일, SLMP, 및 EHR 사이의 상호작용들의 예시적인 도해이다. 본 예에서는, 시스템에 리소스-A(111) 및 리소스-Z(134)와 같은 2개의 <group> 리소스들이 존재한다. 속성-1(115) 및 속성-1(135)(예를 들어, <group> 리소스의 memberList 속성)은 각각 링크 프로파일(128) 및 링크 프로파일(136)에 기초하여 LMS(121)에 의해 실행된다. (예를 들어) 애플리케이션 특정 요건에 기초하여, 링크 프로파일(128)에서의 구성 사양들 중 하나는 도 8의 발신자(123)의 URI(예를 들어, AE 리소스-<AE>)가 오전 8시에서 오전 8시 30분까지 속성-1(115)에 포함된다는 점이다. 또한 발신자(123)를 가리키는 URI는 오전 8시 20분에서 오전 9시 30분까지 속성-1(135)에 포함된다. 따라서 발신자(123)를 가리키는 URI는 오전 8시 20분에서 오후 8시 30분까지 2개의 리소스들(<group> 리소스들)에서 활성화될 것이다. 또한, 나중에 있을 수도 있고, LMS(121)는 발신자(123)를 가리키는 URI가 하나보다 많은 그룹의 속성에 포함될 수 없다는 점이 정책인 SLMP(133)를 수신할 수 있다. 본 예에 대해, 이러한 정책은 링크 프로파일(128) 및 링크 프로파일(136)에 포함되는 이전에 언급된 구성 사양들에 영향을 주고 이들과 충돌할 것이다. 결과적으로, EHR(131)은 본 명세서에서 이러한 충돌을 해결하는데 이용될 것이며, 따라서 오전 8시 20분에서 오전 8시 30까지, LMS(121)는 발신자(123)를 가리키는 URI를 리소스-A(134)의 속성-1(115)에만 할당할 것이다. 여기서, 속성-1(115)은 속성-1(135)보다 높은 우선 순위를 갖는다고 가정된다. 이러한 우선 순위는 URI 사용의 빈도 또는 시간 길이에 관하여 수동으로 할당되는 우선 순위들 또는 자동으로 할당되는 우선 순위들과 같은 인자들에 기초할 수 있다. 예를 들어, 시간 길이에 관하여, 속성-1(115)은 30분(오전 8시-오전 8시 30분)으로 할당되고, 한편 속성-1(135)은 총 50 분(오전 8시 20분-오전 9시 30분)으로 할당되기 때문에 속성-1(115)우선 순위를 가질 수 있다. 속성-1(135)은 우선 순위의 결과에 기초하여 그렇게 하는 것이 제한된 후에도 URI를 사용하는데 더 긴 시간 프레임을 갖는다.

링크 관리가 oneM2M에서 어떻게 더 통합될 수 있는지에 관하여 논의하는 예들이 이하 논의된다. oneM2M은 CSF(Capability Service Functions)으로서 참조되는 능력들을 정의한다. oneM2M 서비스 레이어는 CSE(Capability Services Entity)로서 참조된다. 따라서, 도 19에 도시되는 바와 같이, 개시된 LMS(121)는 CSE에 의해 구현되는 CSF로서 고려될 수 있다.

바람직한 시나리오에서는, 각각의 CSE가 리소스 링크 관리 동작들이 LMS에 의해 취급될 수 있도록 동일한 디바이스 상에 자신의 LMS를 구현한다는 점이 제안된다. 그러나, CSE(예를 들어, CSE(109))가 능력이 매우 제한된 리소스-제약 노드 상에 배치되면, 이것은 다른 CSE에 의해 구현되는 LMS(예를 들어, LMS(121))에 또한 의존할 수 있다. 이러한 경우에도, 이것은 원격 발신자(예를 들어, 발신자(123))에 의해 링크가 구성되어야 하는 경우에 비하여 더 적은 통신 오버헤드를 여전히 초래한다. 개시되는 LMS는 다음과 같은 방식들로 oneM2M 서비스 레이어에서 참조 포인트에 영향을 줄 수 있다:

. AE가 CSE(예를 들어, 링크 호스팅 CSE)에 의해 호스팅되는 리소스의 속성에 대한 링크 관리 태스크를 착수하라는 요청을 (링크 프로파일과 함께) CSE에 전송할 때, 이것은 mca 인터페이스를 통과할 수 있음.

. CSE-1이 CSE-2(예를 들어, 링크 호스팅 CSE)에 의해 호스팅되는 리소스의 속성에 대한 링크 관리 태스크를 착수하라는 요청을 (링크 프로파일과 함께) 다른 CSE-2에 전송할 때, 이것은 mcc 인터페이스를 통과할 수 있음.

. 링크 호스팅 CSE가 LMS에 추가로 접촉할 필요가 있을 때:

이러한 CSE가 자체로 구현되는 LMS를 이용할 때, 이것은 하나의 M2M 디바이스 또는 관련 M2M 디바이스들 그룹 상의 내부 처리를 포함할 수 있음.

CSE가 다른 CSE에 의해 구현되는 LMS를 이용할 때, 이것은 mcc 인터페이스를 통과할 수 있음.

도 20 내지 도 22는 개시되는 LMS에 대한 예시적인 RESTful 리소스-기반 인터페이스를 도시한다. 이하의 규약들이 도 20 내지 도 22에 대해 사용된다:

, 사각형 박스들은 리소스들 및 자식 리소스들에 대해 사용됨

, 모서리들이 둥근 사각형 박스들은 속성에 대해 사용됨

, 각각의 속성 및 자식 리소스의 다양성이 정의됨

, "<" 및 ">"로 구분되는 리소스 명칭들은 리소스의 생성 동안 할당되는 명칭들을 표시함

본 명세서에서 <linkProfile>(263), <SLMP>(264) 및 <EHR>(267)에 관한 리소스들은 도 20 내지 도 22에 도시되는 바와 같이 정의되었고, 이러한 리소스들 각각은 다수의 속성들을 갖는 것으로 개시된다. 예를 들어, <linkProfile>(263)에서의 속성들은, 표 2 내지 표 4에 정의되는 바와 같이, profileType, linkOriginURI, attributeName, destURI, validTimeIntervals, destURICandidateList, contextInfoURI, linkSelectionRules와 같은, 링크 파일에 정의되는 상이한 데이터 항목들에 대응한다. 유사하게, <SLMP>(264) 및 <EHR>(267)에서의 속성들은, 각각, <SLMP>(264)에 대한 associatedEHR 및 <EHR>(267)에 대한 associatedSLMP, <SLMP>(264)에 대한 affectedAttributeList (SLMP(264)가 어느 속성들에 영향을 줄지) 및 policyList, <EHR>(267)에 대한 ruleList에 관련된 정보를 포함한다.

도 23은 oneM2M 서비스 컴포넌트 아키텍쳐(예를 들어, oneM2M-TS-0007 oneM2M Functional Architecture-V-0.3.0)에서의 LMS(121)의 구현 아키텍처의 예시적인 도면이다. 도 23에 도시되는 바와 같이, LMS(121)는 '링크 관리 서비스 컴포넌트'(271)라 불리는 개별 서비스 컴포넌트를 삽입하는 것에 의해 구현될 수 있고, 이는 'Msc' 참조 포인트(273)를 통해 다른 컴포넌트들과 상호작용할 수 있다.

이하, "parentID" 속성, <subscription> 리소스, 및 <group> 리소스와 같은, oneM2M 속성들을 고려하여 링크 관리 상세사항들이 논의된다.

LMS(121)의 사용으로, 필요하다면, 리소스-A(111)는 동적으로 상이한 리소스들의 자식 리소스일 수 있다. 그렇게 하기 위해, 리소스-A(111)의 parentID는 본 명세서에 개시되는 바와 같이 2개 타입들의 링크 프로파일들에 의해 구성될 수 있다. CSE(109) 상의 다수의 리소스들의 parentID는, 임의의 애플리케이션 여건을 지원하기 위해 마찬가지로 LMS(121)에 의해 또한 관리될 수 있다. 예를 들어, 어느 리소스 계층이 (허용된다면) 당신이 원하는 방식으로 동적으로 재조직화되거나 재구성될 수 있는지에 기초하여, SLMP(133)는 "parentID" 속성에 대해 정의될 수 있다. 임의의 기존의, 또는 미래의 oneM2M 사양들(또는 임의의 다른 표준들)에 의해 새로운 특징들이 허용되게 할 수 있도록, 임의의 애플리케이션 특정적 정책들이 SLMP(133)으로서 정의될 수 있다는 점에 주목하자. 예를 들어, "parentID" 속성에 대해 다음 이하의 예시적인 정책들이 SLMP(133)에 또한 포함될 수 있다:

1. 예를 들어, 보안 쟁점으로 인해 2개의 리소스 세트들이 동일한 부모를 공유 할 수 없다는 정책(하나의 세트에서의 리소스들의 parentID를 구성하는 방법이 다른 세트 상의 리소스들에 대한 구성들에 영향을 줄 것임).

2. 리소스가 하나보다 많은 부모를 가질 수 있도록 parentID 속성이 다수의 URI들을 동시에 할당받을 수 있다는 정책. 특히, 도 24는 이러한 정책이 <subscription> 리소스의 "parentID" 속성에 적용될 때의 부가 가치 서비스를 도시한다.

도 24 내지 도 26과 같이, 본 명세서에 도시되는 단계들을 수행하는 엔티티들은, 논리 엔티티들이라는 점이 이해된다. 이러한 단계들은 도 28c 또는 도 28d에 도시되는 것들과 같은 디바이스, 서버, 또는 컴퓨터 시스템의 메모리에 저장될 수 있고, 그 프로세서 상에 실행될 수 있다. 일예에서, M2M 디바이스들의 상호작용에 관한 이하의 추가의 상세사항에 의하면, 도 26의 발신자(123)는 도 28a의 M2M 단말 디바이스(18) 상에 존재할 수 있고, 도 26의 CSE(109)는 도 28a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다.

도 24는 LMS를 사용하는 parentID 속성에 대한 방법의 예시적인 도해이다. 도 24에 도시되는 바와 같이, 처음에는, 하나의 리소스가 기존의 oneM2M 사양에 의해 정의되는 바와 같이 하나의 부모를 가질 수 있다. 단계 281에서, IN-CSE(107)는 새로운 SLMP(133)를 LMS(121)에 제출할 수 있다. 이러한 요청은 애플리케이션에 의해 트리거될 수 있어, 하나의 리소스가 하나보다 많은 부모를 가질 수 있게 한다. 단계 282에서, LMS(121)는 대응하는 SLMP를 업데이트하여 리소스의 "parentID"는 하나보다 많은 URI를 유지하는 것이 허용된다. 단계 284에서, LMS(121)는 이러한 SLMP(133)에 대해 시스템에서의 엔티티들(예를 들어, 발신자(123) 및 CSE(109))에 통보한다. 단계 285에서, 발신자(123)(예를 들어, AE-1)는 <subscription> 리소스를 생성하라는 요청을 CSE(109)에 전송할 수 있으며 그 이유는 이것(발신자(123))가 리소스들 CSE(109)의 <AE-2> 및 CSE(109)의 <AE-3>에 관심이 있기 때문이다. 그러나, <AE-2> 및 <AE-3>에 대해 2개의 별도 <subscription> 리소스들을 생성하는 대신에, 새로운 정책으로, AE-1은 하나의 <subscription>을 생성하여 < AE-2> 및 <AE-3> 양자 모두의 URI들로 그 parentID를 설정하기만 하면 된다. 단계 286에서, CSE(109)는 단계 285의 요청을 검증한다. 단계 287에서, CSE(109)는 단계 286에서 요청된 가입의 상태에 관한 통지를 발신자(123)에게 전송할 수 있다. 단계 288 및 단계 289에서, CSE(109)는, 각각, <AE-2> 및 <AE-3>에 대한 임의의 변경들에 관한 통지를 전송할 수 있다. 따라서, 발신자(123)는 <AE-2> 리소스에 대한 변경 뿐만 아니라 <AE-3> 리소스에 대한 변경에 관한 통지들을 수신할 수 있다.

도 25는 <subscription> 리소스의 부모 ID에 대해 링크 프로파일에 의해 인에이블되는 부가 가치 서비스를 위한 방법의 예시적인 도면이다. 본 예에서, 하나의 리소스는 동적으로 다른 리소스들의 자식 리소스일 수 있다. 도 25에서, 하나의 리소스는 오직 하나의 부모만을 가질 수 있다고 가정된다. 그러나, 발신자(123)(예를 들어, <AE-1>)는 자신의 parentID 속성에 대한 링크 프로파일(128)과 함께 <subscription> 리소스를 생성하라는 요청을 CSE(109)에 전송할 수 있다. 이전의 경우(도 24)에서와 같이, 발신자(123)는 리소스 <AE-2> 및 <AE-3> 양자 모두에 관심이 있지만, 대안적인 방식으로이다. CSE(109)에서, 발신자(123)로부터 수신되는 요청에 기초하여, 이것은 <subscription> 리소스를 생성하고, 대응하는 링크 프로파일 P에서 정의되는 사양에 기초하여 자신의 parentID를 <AE-2>의 URI로 설정한다. 따라서, 발신자(123)는 <AE-2>에 대한 변경에 관한 통지들을 수신할 수 있다. 다른 시간에, 일부 조건들이 충족될 때, LMS는 <subscription> 리소스의 parentID를 <AE-3>의 URI로 자동 업데이트하도록 트리거될 것이고, 발신자(123)는 <AE-3>으로 변경되는 것에 관한 통지들을 수신할 것이다.

LMS는 시스템 전반 링크 관리를 위한 엔티티일 수 있기 때문에, 이것은 또한 동작 효율성 면에서 이점을 갖는다. 예를 들어, LMS는 또한 (얼마나 많은 그룹들에 리소스가 속하는가와 같은) 질문들에 답변할 수 있으며, 이는 즉각 명확하지 않거나 리소스의 속성을 액세스하는 것에 의해 직접 답변할 수 없다. 이러한 속성들에 대한 개시된 속성들 및 링크 구축 동작들은 엄격하게 대칭이 아니다. 예를 들어, memberListID가 <group> 리소스에 대해 정의되었지만 리소스는 이것이 속하는 그룹을 보유할 수 있는 groupList 속성을 갖지 않는다. 이러한 새로운 속성은 기존의 oneM2M 사양을 강화하는 것에 의해 정의될 수 있다. 대안적으로, 링크들이 LMS에 의해 관리되면 다른 방식은 LMS에 도움을 요청하는 것이며, 이로부터 예를 들어 링크 프로파일들을 검사하는 것에 의해 용이하게 답변이 획득될 수 있다.

계속해서 도 25를 참조하면, 단계 140에서, 발신자(123)는 CSE(109) 상에 <subscription> 리소스를 생성하기로 결정하며 그 이유는 <AE-2> 및 <AE-3> 리소스에 관심이 있기 때문이다. 단계 141에서, 발신자(123)(<AE1>)는, 자신의 "parentID" 속성에 대한 링크 프로파일과 함께, CSE(109) 상에 <subscription> 리소스를 생성하라는 요청을 전송한다. 단계 142에서, CSE(109)는 발신자(123)로부터의 요청에 대한 동작 정확성을 점검하고, <subscription> 리소스를 생성하며, 여기서 parentID는 <AE-2>의 URI 값을 갖는 것이 디폴트이다. 단계 143에서, CSE(109)는 링크 프로파일을 LMS(121)에 등록하라는 메시지를 전송한다. 단계 144에서, LMS(121)는 내부 처리를 수행한다(예를 들어, 수신된 링크 프로파일에 따라 새로운 트리거들을 정의함). 단계 145에서, LMS(121)는 <subscription> 리소스에 관련된 링크 관리 태스크에 대해 성공적인 등록에 관하여 CSE(109)와 확인하라는 메시지를 전송한다. 단계 146에서, CSE(109)는 <subscription> 리소스의 성공적인 생성에 대해 발신자(123)와 확인한다. 147에서 CSE 109의 <AE-2>가 변경되었다. 단계 148에서, CSE(109)는 <AE-2>의 변경에 관해 발신자(123)에게 통지한다. 단계 149에서, LMS(121)에 의해 조건이 검사되며, 이는 링크 프로파일에 명시되는 바와 같이 <subscription> 리소스의 "parentID" 속성의 값을 업데이트하는 것에 관한 액션을 트리거한다. 단계 150에서, LMS(121)는 parentID의 값을 <AE-3>의 URI로 업데이트하라는 요청을 CSE(109)에 전송한다. 단계 151에서, CSE(109)는 단계 150의 요청을 점검하고, <subscription>의 parentID가 <AE-3>의 URI 값을 갖도록 업데이트 동작을 실행한다. 단계 152에서 <AE-3>이 변경되었다. 단계 153에서, CSE(109)는 이전 링크 관리 동작으로 인해 parentID의 현재 값이 <AE-3>의 URI로 설정된 이후 <AE-3>의 변경에 관해 AE-1에 통지한다.

도 26은 초기에 <AE-1> 리소스가 CSE(109) 상에 생성되고 이것이 다수의 그룹들에 추가되었다는 점을 도시한다. 나중에, 애플리케이션 요건으로 인해, 예를 들어, 발신자(123)는 어느 그룹의 멤버도 되기를 원하지 않지만, 이것이 현재 어느 그룹들에 속하는지 못한다. 따라서, LMS에게 이러한 문제에 대한 요청을 전송할 수 있다. 시스템에서의 모든 링크들이 LMS에 의해 구성된다고 가정하면, LMS는 모든 <group> 리소스들의 "memberList" 속성에 관련된 모든 링크 프로파일들을 신속하게 통과하고 나서, 다음으로 이러한 그룹들로부터 <AE-1>의 URI를 제거할 수 있다 . 예를 들어, "memberList" 속성의 값에 이러한 URI를 포함시키는 것에 관련된 임의의 링크 구성은 관련 링크 프로파일들로부터 삭제된다. 그렇게 하는 것에 의해, <AE-1>은 더 이상 어떤 그룹에도 속하지 않을 것이다. 이것은 개시되는 LMS에 의해 인에이블되는 부가 가치 서비스일 수 있다. 특히, AE는 LMS에 쿼리 요청을 전송할 수 있어서, LMS는 이러한 AE가 현재 속하는 그룹에 답변할 수 있다.

계속해서 도 26을 참조하면, 단계 161에서, 발신자(123)는 CSE(109) 상에 <AE-1> 리소스를 생성하기로 결정한다. 단계 162에서, 발신자(123) (AE-1)는 CSE(109) 상에 <AE-1> 리소스를 생성하라는 요청을 전송한다. 단계 단계 163에서, CSE(109)는 발신자(123)로부터의 요청의 동작을 점검하고, <AE-1> 리소스를 생성한다. 단계(164)에서, <AE-1>은 (AE-1에 통보하지 않고) 필요한 비즈니스 로직에 기초하여 다른 엔티티들에 의해 여러 <group> 리소스의 "memberList"에 추가되었다. 단계 165에서, 발신자(123)는 (예를 들어, 애플리케이션 요건에 기초하여) 임의의 그룹의 멤버가 되기를 원하지 않는다고 결정하지만, 이것(발신자(123))은 자신이 현재 어느 그룹에 속하는지 알지 못한다. 단계 166에서, 발신자(123)는 발신자(123)와 관련된 <AE-1>을 그룹들로부터 제거하는데 도움을 달라는 요청을 LMS(121)에 전송한다. 단계 167에서, LMS(121)는 <AE-1>의 URI가 포함되는 "memberList" 속성에 관련된 링크 프로파일들을 통과하고, 이러한 관련된 "memberList" 속성들 모두로부터 <AE-1>의 URI를 삭제한다. 단계 168에서, LMS(121)는 어떤 그룹에도 있지 않다는 점을 발신자(123) (AE-1)에게 표시하는 메시지를 발신자(123)에게 전송할 수 있다. 본 명세서에서 "발신자" 및 "AE"라는 용어들은 상호 교환가능하게 사용될 수 있다는 점에 주목하자. 발신자는 애플리케이션이 로드되는 디바이스(예를 들어, AE-1)일 수 있거나 또는 이것이 AE-1일 수 있다.

도 27은 본 명세서에 논의되는 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(901)(예를 들어, 터치 스크린 디스플레이)는, 표 1 내지 표 4에 보여지는 바와 같이, 파라미터들을 디스플레이하거나 쿼리하는데 사용될 수 있는, 리소스 링크 관리(예를 들어, LMS)와 관련된 블록 902에서 텍스트를 제공할 수 있다. 도 12 내지 도 16 또는 도 24 내지 도 26에 도시되는 바와 같이, 본 명세서에서 논의되는 단계들 중 임의의 것의 진행(예를 들어, 단계들의 전송된 메시지 또는 성공)이 디스플레이될 수 있다. 또한, 그래픽 출력(903)이 디스플레이 인터페이스(901) 상에 디스플레이될 수 있다. 그래픽 출력(903)은 리소스 링크 관리(예를 들어, LMS)에 관한 디바이스들의 토폴로지, 본 명세서에 논의되는 임의의 방법 또는 시스템들의 진행의 그래픽 출력 등일 수 있다.

계속해서 도 27을 참조하면, 블록 902의 GUI(graphical user interface)는 LMS에서 실행중인 태스크들의 실시간 상태를 점검하는 것을 허용한다. 통상적으로, LMS에서 실행중인 태스크들 중 다수가 다양한 링크 프로파일들, SLMP들, 또는 EHR들에 정의되는 사양들에 기초하기 때문에, 블록 902의 GUI는 링크 관리 태스크들에서 이러한 파일들이 사용되는 방법을 모니터링하는 것을 허용할 것이다. 링크 프로파일을 예로 들면, 점검할 링크 프로파일의 선택이 존재할 수 있다(예를 들어, 이것은 모든 링크 관리 태스크들에서 가장 빈번히 사용된 것, 또는 링크 관리 태스크에서 가장 덜 빈번히 사용된 것일 수 있음). 대안적으로, 구체적인 링크 프로파일을 점검하고자 하면, 구체적인 링크 프로파일 ID가 입력될 수 있다. 링크 프로파일들에 대한 이러한 GUI 용도들은 LMS에서 저장하는 다른 타입들의 엔티티들(예를 들어, SLMP 및 EHR)에 또한 적용될 수 있다.

본 명세서에 나타나는 청구항들의 범위, 해석, 또는 적용을 전혀 제한하지 않고, 본 명세서에 개시되는 예들 중 하나 이상의 기술적 효과는, 링크들이 어떻게 관리되는지에 대한 조정들을 제공하는 것이다. 링크 구성들 (및 관련 지능)은 특수한 엔티티에 의해 취급되거나 저장될 수 있다. 본 명세서에 개시되는 개념들 중 하나 이상의 다른 기술적 효과는, 종래의 구현들에 비해, CSE가 부모 ID 속성에 대한 링크 관리를 지원하면, 이러한 CSE 상의 리소스들이 리소스 트리에 걸쳐 이동될 수 있어(예를 들어, 상이한 URI 값들을 parentID 속성에 할당함) 리소스 계층이 보다 유연한 방식으로 조직될 수 있다는 점이다. 단지 예로서, <container> 리소스의 "parentID"는 상이한 AE들의 하나 이상의 URI들과 동적으로 할당될 수 있어서, 필요하다면 이러한 AE들이 데이터를 용이하게 공유하고 교환할 수 있다. 본 명세서에 개시되는 LMS의 다른 기술적 효과는, 리소스(예를 들어, <subscription> 리소스)가, 정의된 요건에 기초하여, 하나보다 많은 수신기에 통지를 동적으로 그리고 선택적으로 전송할 수 있고, 따라서 새로운 부가 가치 서비스들을 인에이블하는 것이다.

oneM2M 아키텍처는 본 명세서에서 배경을 통해 설명되고, 이하 설명되는 다양한 개념들 예시하는데 사용될 수 있지만, 이하 설명되는 개념들의 구현들은 본 개시내용의 범위 내에서 유지되면서 변경될 수 있다는 점이 이해된다. 본 분야에서 숙련된 자는, 개시된 개념들이 위에서 논의된 oneM2M 아키텍처를 사용하는 구현들에 제한되는 것은 아니며, 오히려 ETSI M2M과 다른 M2M 시스템들 및 아키텍처들과 같은 다른 아키텍처들 및 시스템들에서 구현될 수 있다는 점을 또한 인식할 것이다.

도 28a는 도 8과 같은 하나 이상의 개시된 개념들이 구현될 수 있는 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구축 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT의 컴포넌트 뿐만 아니라 IoT/WoT 서비스 레이어일 수 있다.

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

도 28a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 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(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 28b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)(예를 들어, 서비스 레이어(104))는 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')는 하나 이상의 서버들, 컴퓨터들, 가상 머신들(예를 들어, 클라우드/계산/스토리지 팜들 등) 등에 의해 구현될 수 있다.

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

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

본 출원의 리소스 링크 관리(예를 들어, LMS)는 서비스 레이어의 일부로서 구현될 수 있다. 서비스 레이어(예를 들어, 서비스 레이어(104))는 일련의 API들(application programming interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M 및 oneM2M 양자 모두 본 출원의 리소스 링크 관리(예를 들어, LMS)를 포함할 수 있는 서비스 레이어를 사용한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)로서 참조된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(Device SCL)로서 참조됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)로서 참조됨) 및/또는 네트워크 노드(여기서 이것은 NSCL(network SCL)로서 참조됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 한 세트의 CSF들(Common Service Functions)(즉, 서비스 능력들)을 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화는 CSE(Common Services Entity)로서 참조되며, 이는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정적 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 리소스 링크 관리(예를 들어, LMS)는 본 출원의 리소스 링크 관리(예를 들어, LMS)와 같은 서비스들에 액세스하는데 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 28c는 예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14) 등과 같은 예시적 M2M 디바이스(30)의 시스템 다이어그램이다. 도 28c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치 패드(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스((30)(예를 들어, M2M 게이트웨이(122), M2M 디바이스(125), M2M 디바이스(126), M2M 디바이스(127), M2M 서버(124) 등)는 리소스 링크 관리(예를 들어, LMS)를 위해 개시되는 시스템들 및 방법들을 수행하는 예시적인 구현의 일부일 수 있다.

프로세서(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)에 연결될 수 있다. 도 28c는 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 점이 이해될 것이다. 프로세서(32)는 애플리케이션 레이어 프로그램들(예를 들어, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신 프로그램들을 수행할 수 있다. 프로세서(32)는 예를 들어 액세스-레이어 및/또는 애플리케이션 레이어에서와 같이, 인증, 보안 키 합의, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

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

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

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

프로세서(32)는 비-이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적합한 메모리로부터 정보를 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 비-이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터 정보를 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 프로세서(32)는 본 명세서에 설명되는 일부 예들에서의 LMS가 성공적인지 또는 성공적이지 않은지에 응답하여 디스플레이 또는 표시자들(42) 상에서 조명 패턴들, 이미지들 또는 컬러들을 제어하도록(예를 들어, 예외 취급(EHR), SLMP 링크 프로파일 제출등 등), 또는 다른 방식으로 LMS(resource link management) 및 관련 컴포넌트들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시자들(42) 상의 제어 조명 패턴들, 이미지들, 또는 컬러들은 본 명세서에서 도시되거나 또는 논의되는 도면들(예를 들어, 도 12 내지 도 16 및 도 24 내지 도 26 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다.

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. 리소스 링크들을 관리하는 디바이스로서,
   프로세서; 및
   상기 프로세서와 연결된 메모리
   를 포함하고,
   상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 시행하게 하는 실행가능 명령어들을 포함하고,
   상기 동작들은,
   제1 링크 프로파일을 수신하는 것 - 상기 제1 링크 프로파일은 제1 리소스의 링크의 사용을 구성하는 것을 정의하는 명령어들을 포함하고, 상기 제1 리소스의 링크는 제2 리소스로 지향됨 -;
   상기 링크를 관리하라는 요청을 수신하는 것; 및
   상기 요청에 응답하여, 상기 제1 링크 프로파일에 기초하여 상기 링크의 사용을 관리하는 것 - 상기 관리하는 것은 상기 제1 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용과 제2 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용 사이의 충돌들을 해결하는 것을 포함함 -
   을 포함하는 디바이스.
2. 제1항에 있어서,
   상기 링크의 사용을 관리하는 것은 시간에 기초하여 트리거되는 디바이스.
3. 제1항 또는 제2항에 있어서,
   상기 링크의 사용을 관리하는 것은 상기 제1 리소스와 관련된 모바일 디바이스의 콘텍스트 정보에 기초하는 디바이스.
4. 제1항 또는 제2항에 있어서,
   상기 링크를 관리하는 것은 상기 링크를 삭제하는 것을 포함하는 디바이스.
5. 제1항 또는 제2항에 있어서,
   상기 링크를 관리하는 것은 상기 링크를 업데이트하는 것을 포함하는 디바이스.
6. 제1항 또는 제2항에 있어서,
   상기 링크는 URI(uniform resource identifier)인 디바이스.
7. 제1항 또는 제2항에 있어서,
   상기 링크의 사용을 관리하는 것은 상기 제1 리소스와 관련된 모바일 디바이스의 콘텍스트 정보에 기초하고, 상기 콘텍스트 정보는 대역폭을 포함하는 디바이스.
8. 리소스 링크 관리를 위한 방법으로서,
   제1 링크 프로파일을 수신하는 단계 - 상기 제1 링크 프로파일은 제1 리소스의 링크의 사용을 구성하는 것을 정의하는 명령어들을 포함함 -;
   상기 링크를 관리하라는 요청을 수신하는 단계; 및
   상기 요청에 응답하여, 상기 제1 링크 프로파일에 기초하여 상기 링크의 사용을 관리하는 단계 - 상기 관리하는 단계는 상기 제1 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용과 제2 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용 사이의 충돌들을 해결하는 단계를 포함함 -
   를 포함하는 방법.
9. 제8항에 있어서,
   상기 제1 리소스의 링크는 제2 리소스로 지향되는 방법.
10. 제8항 또는 제9항에 있어서,
    상기 링크의 사용을 관리하는 단계는 상기 제1 리소스와 관련된 모바일 디바이스의 콘텍스트 정보에 기초하는 방법.
11. 제8항 또는 제9항에 있어서,
    상기 링크를 관리하는 것은 상기 링크를 삭제하는 것을 포함하는 방법.
12. 제8항 또는 제9항에 있어서,
    상기 링크를 관리하는 것은 상기 링크를 업데이트하는 것을 포함하는 방법.
13. 제8항 또는 제9항에 있어서,
    상기 링크는 URI(uniform resource identifier)인 방법.
14. 제8항 또는 제9항에 있어서,
    상기 링크의 사용을 관리하는 단계는 상기 제1 리소스와 관련된 디바이스의 콘텍스트 정보에 기초하고, 상기 콘텍스트 정보는 대역폭을 포함하는 방법.
15. 컴퓨팅 디바이스에 의해 실행될 때, 상기 컴퓨팅 디바이스로 하여금 동작들을 시행하게 하는 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서,
    상기 동작들은,
    제1 링크 프로파일을 수신하는 것 - 상기 제1 링크 프로파일은 제1 리소스의 링크의 사용을 구성하는 것을 정의하는 명령어들을 포함함 -;
    상기 링크를 관리하라는 요청을 수신하는 것; 및
    상기 요청에 응답하여, 상기 제1 링크 프로파일에 기초하여 상기 링크의 사용을 관리하는 것 - 상기 관리하는 것은 상기 제1 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용과 제2 링크 프로파일과 관련된 상기 제1 리소스의 링크의 사용 사이의 충돌들을 해결하는 것을 포함함 -
    을 포함하는 컴퓨터 판독가능 저장 매체.
16. 제15항에 있어서,
    상기 링크의 사용을 관리하는 것은 상기 제1 리소스와 관련된 모바일 디바이스의 콘텍스트 정보에 기초하는 컴퓨터 판독가능 저장 매체.
17. 제15항 또는 제16항에 있어서,
    상기 링크를 관리하는 것은 상기 링크를 삭제하는 것을 포함하는 컴퓨터 판독가능 저장 매체.
18. 제15항 또는 제16항에 있어서,
    상기 링크를 관리하는 것은 상기 링크를 업데이트하는 것을 포함하는 컴퓨터 판독가능 저장 매체.
19. 제15항 또는 제16항에 있어서,
    상기 링크의 사용을 관리하는 것은 상기 제1 리소스와 관련된 디바이스의 콘텍스트 정보에 기초하고, 상기 콘텍스트 정보는 대역폭을 포함하는 컴퓨터 판독가능 저장 매체.
20. 제15항 또는 제16항에 있어서,
    상기 제1 리소스의 링크는 제2 리소스로 지향되는 컴퓨터 판독가능 저장 매체.

Images