KR20200009153A

KR20200009153A - 서비스 계층 등록

Info

Publication number: KR20200009153A
Application number: KR1020207001863A
Authority: KR
Inventors: 리쥔 동; 로꼬 디 지롤라모; 총강 왕; 홍군 리; 칭 리; 카탈리나 엠. 믈라딘
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2015-09-01
Filing date: 2016-09-01
Publication date: 2020-01-29
Also published as: CN108141447B; JP6612437B2; EP3345367A1; CN108141447A; CN113596165A; US20210195548A1; KR20180048845A; JP2018529161A; WO2017040749A8; EP3913889A1; US10667229B2; US20200245285A1; WO2017040749A1; EP3345367B1; US10972995B2; US20190253994A1; KR102355746B1; US11696248B2

Abstract

서비스 계층 엔티티(예를 들어, oneM2M의 애플리케이션 엔티티, 공통 서비스 엔티티로서, 레지스트리 엔티티로도 지칭됨)는 다른 서비스 계층 엔티티(예를 들어, oneM2M의 공통 서비스 엔티티로서, 레지스트라 엔티티로도 지칭됨)에 등록할 수 있고, 레지스트라 엔티티에 의해 호스팅되는 로컬 서비스들에 대한 액세스를 획득하기 위한 요청을 프로액티브하게 할 수 있다. 레지스트라 엔티티는 레지스트리 엔티티의 등록 요청을 수락할 수 있지만, 레지스트리 엔티티에게 그 부분적인 서비스들에 대한 액세스만을 허가할 수 있다. 레지스트리 엔티티가 그 등록 요청 메시지 내에서 서비스들을 프로액티브하게 요청할 필요가 없는 경우, 레지스트라 엔티티는 어떤 서비스들이 레지스트리 엔티티에 의해 필요할 수 있는지를 결정하고, 레지스트리 엔티티에게 그 서비스들에 대한 액세스를 허가한다.

Description

서비스 계층 등록{SERVICE LAYER REGISTRATION}

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

본 출원은 2015년 9월 1일자로 출원되고, 발명의 명칭이 "Service Layer Registration"인 미국 가특허 출원 제62/212,903호의 이익을 주장하며, 그 내용은 본 명세서에 참조로 포함된다.

oneM2M 아키텍처

개발 중인 oneM2M 표준(neM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0에서 제공되며, 전체적으로 참조로 포함됨)은 "Common Service Entity(CSE)"라 불리는 서비스 계층을 정의한다. 도 1은 서비스 계층을 정의하는 예시적인 oneM2M 아키텍처를 예시한다. 서비스 계층(Service Layer)은 스마트헬스(e-Health), 차량군 관리(fleet management) 및 스마트 홈들과 같이 상이한 "수직형" 머신-투-머신(machine-to-machine)(M2M) 시스템들 및 애플리케이션들에 의해 활용될 수 있는 "수평형" 서비스들을 제공한다. Mca 참조 포인트(111)는 애플리케이션 엔티티(AE)(112)와 인터페이스한다. Mcc 참조 포인트(113)는 동일한 서비스 제공자 도메인 내의 다른 CSE(115)와 인터페이스하고, Mcc' 참조 포인트(116)는 상이한 서비스 제공자 도메인(117) 내의 다른 CSE(도시 생략)와 인터페이스한다. Mcn 참조 포인트(118)는 기반 네트워크 서비스 엔티티(network service entity)(NSE)(119)와 인터페이스한다. NSE(119)는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기반 네트워크 서비스들을 CSE들에 제공한다. CSE는 "발견(Discovery)"또는 "데이터 관리 및 레포지토리(Data Management & Repository)"와 같은 "공통 서비스 기능(Common Service Function)(CSF)들"이라고 하는 다수의 논리 기능들을 포함한다.

oneM2M RESTful 아키텍처(리소스 지향 아키텍처(resource oriented Architecture) 또는 RoA라고도 알려짐) 내에서, CSE는 도 2에 도시된 바와 같이 공통 서비스 기능(CSF)들의 세트의 인스턴스화를 지원한다. CSF 기능은 생성(Create), 리트리브(Retrieve), 업데이트(Update) 및 삭제(Delete)와 같이 RESTful 메소드들을 통해 조작될 수 있는 표현을 갖는 고유하게 어드레스 가능한 엔티티들인 리소스들을 통해 구현된다. 이들 리소스들은 범용 리소스 식별자(universal resource identifier)(URI)들을 사용하여 어드레스 가능하다. 리소스는 리소스에 대한 관련 정보를 저장하는 어트리뷰트들의 세트를 지원하고, 차일드 리소스(들)(child resources(s))이라고 하는 다른 리소스들에 대한 참조들을 포함할 수 있다. 차일드 리소스는 패런트 리소스(parent resource)와 포함 관계를 갖고, 그 수명이 패런트 리소스의 수명에 의해 제한되는 리소스이다.

전개의 관점에서, 도 3은 oneM2M 아키텍처에 의해 지원되는 구성들을 도시한다. oneM2M 아키텍처는 애플리케이션 서비스 노드(application service node)(ASN), 애플리케이션 전용 노드(application dedicated node)(ADN), 중간 노드(middle node)(MN) 및 인프라스트럭처 노드(infrastructure node)(IN)를 인에이블한다. ASN은 하나의 CSE를 포함하고 적어도 하나의 AE를 포함하는 노드이다. 물리적 매핑의 예는 M2M 디바이스에 상주하는 ASN이다. ADN은 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. 물리적 매핑의 예는 제약된 M2M 디바이스에 상주하는 ADN이다. MN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. MN에 대한 물리적 매핑의 예는 M2M 게이트웨이에 상주하는 MN이다. IN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. IN에 대한 물리적 매핑의 예는 M2M 서비스 인프라스트력쳐에 상주하는 IN이다. oneM2M 엔티티들(AE들이나 CSE들이 아님)을 포함하지 않는 노드인 비-oneM2M 노드가 있을 수도 있다. 이러한 노드들은 관리를 포함하여 상호 연동 목적을 위해 oneM2M 시스템에 부착된 디바이스들을 나타낸다.

등록

통상적으로, ASN, MN 또는 IN 상의 AE는 해당 CSE에 의해 제공되는 M2M 서비스들을 사용하기 위해 대응하는 CSE에 국부적으로 등록을 수행한다. ADN 상의 AE는 해당 CSE에 의해 제공되는 M2M 서비스들을 사용하기 위해 MN 또는 IN 상의 CSE에 등록을 수행한다. IN-AE는 해당 IN CSE에 의해 제공되는 M2M 서비스들을 사용하기 위해 IN 상의 대응하는 CSE에 등록을 수행한다.

ASN 상의 CSE는 MN의 CSE에 의해 제공되는 M2M 서비스들을 사용할 수 있도록 MN의 CSE에 등록을 수행한다. MN-CSE에 성공적으로 ASN-CSE를 등록한 결과, ASN 및 MN 상의 CSE들은 이들이 정보를 교환할 수 있는 관계를 확립한다.

MN 상의 CSE는 다른 MN의 CSE에 의해 제공되는 M2M 서비스들을 사용할 수 있도록 다른 MN의 CSE에 등록을 수행한다. 다른 MN-CSE에 성공적으로 MN-CSE를 등록한 결과, MN들 상의 CSE들은 이들이 정보를 교환할 수 있는 관계를 확립한다.

ASN 또는 MN상의 CSE는 IN의 CSE에 의해 제공되는 M2M 서비스들을 사용할 수 있도록 IN의 CSE에 등록을 수행한다. IN-CSE에 성공적으로 ASN/MN을 등록한 결과, ASN/MN 및 IN 상의 CSE들은 이들이 정보를 교환할 수 있는 관계를 확립한다.

위에서 설명된 경우들에서, 등록을 수행하는 AE 또는 CSE는 레지스트리(Registree) AE 또는 레지스트리 CSE로 지칭된다. AE 또는 CSE가 등록하는 CSE는 레지스트라(Registrar) CSE로 지칭된다.

AE를 CSE에 성공적으로 등록한 후, AE에 액세스 권한이 허가되었다고 가정하면, AE는 레지스트라 CSE로부터 요청의 잠재적 타겟들인 모든 CSE들의 리소스들에 액세스할 수 있다.

일부 종래의 등록 규정들은 다음과 같다.

·AE는 둘 이상의 CSE(ASN-CSE, MN-CSE 또는 IN-CSE)에 등록되지 않아야 한다.

·ASN-CSE는 많아야 하나의 다른 CSE(MN-CSE 또는 IN-CSE)에 등록될 수 있어야 한다.

·MN-CSE는 많아야 하나의 다른 CSE(MN-CSE 또는 IN-CSE)에 등록될 수 있어야 한다.

·다수의 단방향성 등록들의 연결(concatenation)(등록 체인)이 루프를 형성해서는 안된다. 예를 들어, 2개의 MN-CSE A와 B는 서로 등록할 수 없다. 3개의 MN-CSE A, B 및 C에서, A가 B에 등록하고, B가 C에 등록하고 나면, C는 A에 등록할 수 없다.

통상적으로, CSE 등록 절차는 2개의 리소스(수신자(Receiver) CSE 상의 <remoteCSE> 및 발신자(Originator) CSE 상의 <remoteCSE>)의 생성을 필요로 한다. 발신자는 레지스트리 CSE이어야 한다. 수신자는 초기에 <remoteCSE> 리소스를 생성하는 레지스트라 CSE이어야 한다. 도 4는 <remoteCSE> 리소스를 생성하기 위한 예시적인 절차를 예시한다. 단계(131)에서, 발신자(121)는 CREATE 요청 메시지를 전송한다. 단계(132)에서, 수신자(121)는 등록 요청 메시지를 프로세싱한다. 단계(133)에서, 수신자(121)는 등록된 CSE의 어드레스/URI를 포함하는 등록 응답 메시지로 응답한다. 단계(134)에서, 발신자는, CREATE 응답 메시지를 수신하면, 그 <CSEBase> 리소스 아래에 <remoteCSE> 리소스를 국부적으로 생성한다. 이 리소스는 수신자(121) CSE를 표현한다. 발신자(120)는 모든 필수 파라미터들에 적절한 값들을 제공한다. 단계(135)에서, 발신자(120)는 단계(134)에서와 같이 수신자(121)에서 생성된 <remoteCSE> 리소스의 임의적인 파라미터들(예를 들어, labels, accessControlPolicyIDs 어트리뷰트들)을 획득하기 위하여 수신자를 향해 (CREATE 요청 메시지에 대한 것과 동일한 To 로) RETRIEVE 요청을 발행할 수 있다. 단계(136)에서, 수신자(121)는 발신자(120)가 정보에 액세스하기 위한 적절한 권한들을 갖는 것을 검증한다. 단계(137)에서, 수신자(121)는 RETRIEVE 응답 메시지를 전송한다. 단계(138)에서, 발신자(120)는 단계(137)에서 획득된 정보로 수신자(121)에 대해 생성된 <remoteCSE> 리소스를 업데이트한다.

통상적으로, AE 등록을 위한 절차는 도 5에 도시된 메시지 흐름 설명을 따른다. 발신자는 레지스트리 AE이다. 수신자(레지스트라 CSE)는 액세스 제어 정책 및 적용 가능한 가입 프로파일의 정보에 따라 <AE> 리소스의 생성을 허용한다. 수신자는 레지스트라 CSE의 CSE-ID로부터 적용 가능한 M2M-Service-Profile-ID를 도출한다. 단, 도 5에서, 정보 중 일부가 잘리긴 했지만, 이는 oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0에서 찾을 수 있다는 것에 유의하도록 한다.

도 5를 참조하면, 단계(141)에서, 레지스트리 AE(123)가 등록을 수행하기 위해 보안 연관을 사용하려고 의도하는 경우, 우선 보안 연관 확립 절차가 수행된다. 단계(142)에서, 레지스트리 AE(123)는 CREATE 요청 메시지 내에서 다음의 특정 정보를 갖고 등록 CREATE 절차에 대한 정보를 전송한다.

From : AE-ID-Stem 또는 NULL.

- 레지스트리 AE(123)가 이미 이전에 성공적으로 등록한 후, 등록을 해제하였고, 이전과 동일한 AE-ID-Stem 값으로 다시 등록하려고 의도하는 경우, 레지스트리 AE(123)는 해당 AE-ID-Stem 값을 From 파라미터에 포함하도록 한다.

- 레지스트리 AE(123)가 이전에 성공적으로 등록하지 않았고, 자신에게 할당된 'S' 문자로 시작하는 M2M-SP-할당된 AE-ID-Stem을 획득하려고 의도하지만 제안할 임의의 특정 값을 갖지 않는 경우, From 파라미터를 문자 'S'로 설정하도록 한다.

- 레지스트리 AE(123)가 새로운 등록을 개시하려고 의도하고 AE-ID-Stem 값에 대한 선호도가 없는 경우, From 파라미터는 NULL로 설정되도록 한다.

단계(143)에서, 수신자(예를 들어, 레지스트라 CSE(124))는 레지스트리 AE(123)를 등록하기 위한 요청이 다음의 조건들 중 임의의 조건을 충족시키는지 여부를 결정하여야 한다. 적용 가능한 서비스 가입 프로파일이 요청의 Content 파라미터의 App-ID 어트리뷰트와 요청의 From 파라미터의 AE-ID-Stem과 매칭되는 Credential-ID 및 레지스트라 CSE-ID에 대한 (허용된 AE-ID-Stem 값과 허용된 App-ID 값의) 조합을 열거하는지를 체크한다. 이 체크에 적용 가능한 규칙들은 레지스트라 CSE와 연관된 <m2mServiceSubscribedNode> 리소스(들)의 ruleLinks 어트리뷰트에 의해 링크되는 <serviceSubscribedAppRule> 리소스(들)에 포함된다. 단계(144)에서, 요청의 From 파라미터가 AE-ID-Stem 값을 제공하는 경우, 레지스트라 CSE는 요청의 From 파라미터에서 제공된 AE-ID-Stem 값과 동일한 Unstructured-CSE-relative-Resource-ID를 갖는 <AE> 리소스가 이미 존재하는지를 체크한다. 존재하는 경우, 레지스트라 CSE 상에 동일한 AE-ID-Stem을 사용하는 활성 등록이 여전히 존재하며, 레지스트라 CSE는 에러로 응답해야 한다.

계속해서 도 5를 참조하면, 절차는 다음과 같은 경우 a)-d)에 대한 것으로 계속되며(세부 사항들은 oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0에서 찾을 수 있음), 이들 모두 단계(149)의 응답으로 종료된다.

·경우 a) AE-ID-Stem은 'S'로 시작하고, AE는 AE-ID-Stem을 포함하지 않는다(초기 등록) - 단계 145a 내지 148a.

·경우 b) AE-ID-Stem은 'S'로 시작하고, AE는 AE-ID-Stem을 포함한다(재-등록) - 단계 145b 내지 148b.

·경우 c) AE-ID-Stem은 'C'로 시작하고, AE는 AE-ID-Stem을 포함하지 않는다(초기 등록) - 단계 145c.

·경우 d) AE-ID-Stem은 'C'로 시작하고, AE는 AE-ID-Stem을 포함한다(재-등록) - 단계 145d.

리소스 타입(Resource Type) m2mServiceSubscriptionProfile

통상적으로, <m2mServiceSubscriptionProfile> 리소스는 M2M 서비스 가입(Service Subscription)을 표현한다. 이것은 M2M 서비스 가입과 관련된 모든 데이터, 즉, M2M 애플리케이션 서비스 제공자와 M2M 서비스 제공자 간의 계약의 기술적 부분을 표현하는 데 사용된다. <m2mServiceSubscriptionProfile> 리소스의 serviceRoles 어트리뷰트가 이 서비스 가입에 가입된 Service Role ID(S-RoleID)들의 리스트를 포함한다.

서비스 오케스트레이션 프로파일(Service Orchestration Profile)

통상적으로, 서비스 오케스트레이션 프로파일들의 역할은 서비스 오케스트레이션뿐만 아니라 서비스 발견과 같은 다른 기능들에 사용될 수 있는 서비스 관련 어트리뷰트들(즉, 메타 데이터)의 교환을 위한 메커니즘을 제공하는 것이다. 다음의 어트리뷰트들은 서비스 오케스트레이션 프로파일의 일부 예들이다. 프로파일 식별자는 프로파일의 식별자를 특정한다. 프로파일 시맨틱스(Profile Semantics)는 프로파일 내에 포함된 서비스 오케스트레이션 어트리뷰트들을 설명하는 시맨틱 설명 또는 시맨틱 설명에 대한 어드레스/링크를 특정한다. 프로파일 타입(Profile Type)은 프로파일의 타입을 특정한다. 서비스 오케스트레이션 타겟들(Service Orchestration Targets)은 서비스 오케스트레이션이 수행될 타겟들(예를 들어, 서비스 노드들, 서비스 계층 또는 서비스 능력 인스턴스)의 임의적인 리스트를 특정한다. 서비스 오케스트레이션 스케줄(Service Orchestration Schedule)은 서비스 오케스트레이션이 언제 수행되는지에 대한 스케줄링 정보 및/또는 프로파일이 유효한 시간의 지속기간을 특정한다. 서비스 오케스트레이션 정책들(Service Orchestration Policies)은 서비스 오케스트레이션을 수행할 자격이 있는 정책들을 특정한다. 서비스 오케스트레이션 컨텍스트(Service Orchestration Context)는 서비스 오케스트레이션에 적용 가능한 컨텍스트 정보를 특정한다. 원하는 서비스들(Desired Services)은 오케스트레이션 클라이언트가 특정된 타겟(들)으로 오케스트레이션되도록 요청하는 서비스 구성을 특정한다. 지원되는 서비스들(Supported Services)은 오케스트레이션 타겟이 지원하는 지원되는 서비스들의 세트를 특정한다.

서비스 계층 메시지 라우팅 서비스(Service Layer Message Routing Service)

메시지 라우팅 서비스(Message Routing Service)는 CSE가 자신의 레지스트리 AE 또는 CSE로부터의 메시지들(메시지는 레지스트리 AE 또는 CSE로부터 발신될 수도 있고, 또는 메시지는 레지스트리 CSE에 의해 포워딩될 수도 있음)을 타겟으로 라우팅하고 포워딩할 수 있게 하는 서비스이다. 일반적으로, 메시지 라우팅 서비스는 레지스트라 엔티티가 레지스트리 엔티티에 제공할 수 있는 서비스이거나, 그 반대의 서비스이다. 메시지 라우팅 서비스는 특별한 서비스로서 간주될 수 있는데, 왜냐하면 기본적으로 메시지 라우팅 서비스는 상호적이고 양방향성이기 때문이다. 이것은, 레지스트라 엔티티가 자신의 레지스트리 엔티티에 이 메시지 라우팅 서비스의 액세스 퍼미션을 허가하면, 레지스트리 엔티티도 자동적으로 레지스트라 엔티티에 메시지 라우팅 서비스를 제공한다는 것을 의미한다. 단, 이것은 메시지 라우팅 서비스의 디폴트 설정이지만, 서비스는 단방향으로 설정될 수 있다는 것에 유의하도록 한다. SL 엔티티에 의해 호스팅되는 로컬 서비스들 각각은 모든 로컬 서비스들 간에 고유한 식별자를 가져야 한다.

통상적으로, 하나의 CSE에 등록할 때, 하나의 CSE 상의 모든 리소스들에 대한 대응하는 예약(필수적이지 않을 수 있음)이 있을 수 있다. 단지 필요하게 될 서비스들에 대한 리소스들만을 예약하는 것이 유리할 수 있다. 이것은 CSE와 접속되는 용량(예를 들어, 디바이스들/AE들의 수)에 대한 임의의 제약사항들 내에서 사용을 규제하는 데 도움이 될 수 있다.

본 명세서에는 다음과 같은 특성들을 갖는 유연한 서비스 계층 등록(flexible service layer registration)이 개시되어 있다. SL 엔티티(예를 들어, oneM2M의 AE, CSE로서, 레지스트리 엔티티로도 지칭됨)는 SL 엔티티(예를 들어, oneM2M의 CSE로서, 레지스트라 엔티티로도 지칭됨)에 등록하고, 레지스트라 엔티티에 의해 호스팅되는 로컬 서비스들에 대한 액세스를 획득하기 위한 요청을 프로액티브하게 할 수 있다. 레지스트라 엔티티는 레지스트리 엔티티의 등록 요청을 수락할 수 있지만, 레지스트리 엔티티에 대해 그 부분적인 서비스들에 대한 액세스만을 허가할 수 있다. 레지스트리 엔티티가 그 등록 요청 메시지 내에서 서비스들을 프로액티브하게 요청할 필요가 없는 경우, 레지스트라 엔티티는 어떤 서비스들이 레지스트리 엔티티에 의해 필요할 수 있을지를 결정하고, 레지스트리 엔티티에 그 서비스들에 대한 액세스를 허가한다.

레지스트리 엔티티는 둘 이상의 레지스트라 엔티티에 등록할 수 있다. 예를 들어, 하나의 레지스트라 엔티티가 레지스트리 엔티티에 요청된 서비스에 대한 액세스를 허가하지 않는 경우, 이것은 동일한 서비스에 대해 다른 엔티티에 등록할 수 있다. 다수의 단방향성 등록들의 연결(등록 체인)이 루프를 형성할 수 있다.

본 명세서에는 remoteCSE 리소스 강화뿐만 아니라, 새로운 리소스들을 갖는 oneM2M 예가 개시되어 있다. 이 예는 CSE의 로컬 서비스들뿐만 아니라, 등록된 AE 및 CSE의 허가된 서비스들, 거절된 서비스들 및 계류 중인 서비스들을 관리하는 방법들을 제공한다.

첨부된 도면들과 관련하여 예로서 주어지는 다음의 설명으로부터 보다 상세한 이해가 이루어질 수 있다.
도 1은 예시적인 oneM2M 아키텍처를 예시한다.
도 2는 예시적인 oneM2M 공통 서비스 기능들을 예시한다.
도 3은 oneM2M 아키텍처에 의해 지원되는 예시적인 구성들을 예시한다.
도 4는 <remoteCSE> 리소스를 생성하기 위한 예시적인 절차를 예시한다.
도 5는 <AE> 리소스를 생성하기 위한 예시적인 절차를 예시한다.
도 6은 예시적인 사용 경우의 서비스 계층 등록을 예시한다.
도 7은 예시적인 사용 경우의 서비스 계층 등록을 예시한다.
도 8은 유연한 서비스 계층 등록을 위한 예시적인 메시지 흐름을 예시한다.
도 9는 유연한 서비스 계층 등록을 위한 예시적인 메시지 흐름을 예시한다.
도 10은 다수의 레지스트라 엔티티들에 대한 예시적인 등록을 예시한다.
도 11은 <CSEBase>에 추가된 예시적인 차일드 리소스들을 예시한다.
도 12는 <remoteCSE>에 추가된 예시적인 차일드 리소스들 및 어트리뷰트를 예시한다.
도 13은 <AE>에 추가된 예시적인 차일드 리소스들 및 어트리뷰트를 예시한다.
도 14는 예시적인 <localService> 리소스를 예시한다.
도 15는 예시적인 <grantedServiceTo> 리소스를 예시한다.
도 16은 예시적인 <rejectedServiceTo> 리소스를 예시한다.
도 17은 예시적인 <pendingServiceTo> 리소스를 예시한다.
도 18은 예시적인 <grantedServiceFrom> 리소스를 예시한다.
도 19는 oneM2M에서의 유연한 등록의 예시적인 메시지 흐름을 예시한다.
도 20은 유연한 서비스 계층 등록에 기초한 사용자 인터페이스에 대한 예시적인 아키텍처를 예시한다.
도 21은 유연한 서비스 계층 등록에 기초하여 생성될 수 있는 예시적인 디스플레이를 예시한다.
도 22a는 개시된 대상이 구현될 수 있는 예시적인 머신-투-머신(M2M) 또는 사물 인터넷(Internet of Things)(IoT) 통신 시스템의 시스템도이다.
도 22b는 도 22a에 예시된 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 22c는 도 22a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다.
도 22d는 도 22a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

종래의 서비스 계층 등록은 단지 레지스트리가 하나의 유일한 레지스트라에만 등록할 수 있게 한다. 예를 들어, AE는 단지 하나의 CSE에만 등록하고, CSE도 단지 하나의 CSE에만 등록한다. 따라서, AE 또는 CSE는 단일의 등록된 CSE 상에서만 서비스들을 사용할 수 있다.

현재, 등록 관계는 적절한 액세스 권한들에 의해 기본적으로 레지스트리가 레지스트라에 의해 제공되는 모든 서비스들을 사용할 수 있게 한다. 그러나, 레지스트리는 레지스트라에 의해 제공되는 서비스들 중 일부만을 사용하고 싶을 수도 있고, 또는 레지스트라는 자신의 서비스들 중 일부만을 레지스트리에 제공하고 싶을 수도 있다.

통상적으로, AE와 M2M 서비스 제공자 간의 계약의 기술적 부분에 기초하여 레지스트리 AE의 가입 프로파일이 설정될 수 있다. 연관된 serviceRoles 어트리뷰트는 레지스트리 AE에 의해 액세스될 수 있는 서비스들 및 리소스들을 제어하는 데 사용될 수 있다. 그러나, oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0에서 제공되는 종래의 메커니즘들은 다음의 이슈들을 갖는다. 첫 번째 이슈는 서비스 프로파일이 CSE가 아니라 레지스트리 AE에만 적용 가능하다는 것이다. 두 번째 이슈는, 서비스 프로파일이 단지 현재 정의된 리소스들과 연관된 서비스들만을 고려하기 때문에, CSE에 의해 제공되는 모든 로컬 서비스들(예를 들어, 메시지 포워딩 서비스)의 액세스 가능성을 관리하기에 충분히 포괄적이지 않다는 것이다. 세 번째 이슈는, 가입 프로파일이 계약 기반(즉, 사전-구성되고 정적)이기 때문에, 레지스트리 AE 또는 CSE가 등록 프로세스 동안에 레지스트라 CSE에 의해 제공되는 서비스들을 유연하게 요청하도록 허용되지 않는다는 것이다. 네 번째 이슈는, 모든 가입 프로파일들이 IN-CSE에 의해 관리되고, MN-CSE들은 그 자체 서비스들의 사용자들을 결정할 때 독립성을 갖지 못한다는 것이다. 다섯 번째 이슈는, 각각의 CSE가 레지스트리 AE 또는 CSE에 대해 이들에 의해 어떤 서비스들이 필요할 수 있는지에 대한 결정을 내릴 수 있는 지능이 없다는 것이다.

따라서, 종래의 서비스 계층 등록은 등록 프로세스 동안에 레지스트리가 레지스트라로부터 유연하게 서비스들을 요청할 수 있게 하고, 레지스트라가 레지스트리에게 자신의 서비스들 중 일부를 사용하도록 퍼미션을 선택적으로 허가할 수 있게 하는 능력들이 부족하다. 본 명세서에는 레지스트리가 다수의 CSE들에 등록할 수 있게 하는 방법들이 개시되어 있다. 예에서, CSE는 다수의 트랜짓 CSE들에 의해 제공되는 서비스 계층 메시지 라우팅 서비스를 사용할 수 있다.

도 6은 전화(예를 들어, 전화/ASN-CSE(161))가 다수의 다른 서비스 계층(service layer)(SL) 엔티티들과 접속할 수 있는 다수의 서비스 계층 엔티티들의 사용을 위한 제1 예시적인 환경을 예시한다. 도 6에는, 홈 Wi-Fi 액세스 포인트(163)(MN-CSE), LTE eNB(162)(MN-CSE) 및 데이터 서버(164)(IN-CSE)와 같은 다수의 SL 엔티티들이 있다. 전화(161)는 Wi-Fi 액세스 포인트(163) 또는 LTE eNB(162)의 커버리지 영역 내에 있을 수 있다. 전화 SL(161)은 클라우드(165)(예를 들어, Amazon® Cloud 또는 Facebook®)를 통해 데이터 서버(164)와 통신 가능하게 접속될 수 있다. 전화(161)는 저렴한 비용으로 인해 통신 관리 및 전달 핸들링 서비스(Communication Management and Delivery Handling Service)에 대해 Wi-Fi 액세스 포인트(163)에 등록할 수 있다. 셀룰러 네트워크는 양호한 인증 메커니즘들 및 위치 정보 등을 제공하기 때문에, 다른 더 저렴한 인터넷 액세스, 보안 서비스 및 위치 서비스가 없으면, 전화(161)는 특정 서비스들, 예를 들어, 통신 관리 및 전달 핸들링을 위해 LTE eNB(162)에 등록할 수도 있다. 전화 SL(161)은 그것 상에서 실행되는 많은 애플리케이션들뿐만 아니라 통합 센서들을 가질 수 있다. 클라우드(165)에서 호스팅되는 데이터 서버(164) 내의 SL은 자연 현상과 관련된 데이터(온도, 습도, 노이즈 등), 사회 생활과 관련된 데이터(소셜 애플리케이션들, 광고 등) 등을 관리하고 저장할 수 있다. 전화(161)의 SL은 상이한 타입들의 데이터 및 애플리케이션들에 대한 데이터 관리 및 레포지토리(Data Management and Repository), 가입 및 통지(Subscription and Notification), 위치(Location), 발견(Discovery) 등과 같은 서비스들을 위해 클라우드(165)에서 호스팅되는 데이터 서버(164)의 SL에 등록한다.

도 6의 맥락에서의 다수의 SL 엔티티들의 사용에 대한 예시적인 시나리오가 이하에서 논의된다. 전화(161)는 아침에 커피를 위해 커피 머신을 턴온시키는 데 사용될 수 있다. 전화(161)는 Wi-Fi 액세스 포인트(163)에 의해 제공되는 디바이스 관리 서비스를 사용할 수 있고, 또한 인증을 위해 LTE eNB(162)에 의해 제공되는 보안 서비스를 사용할 수도 있다. 마지막으로, 전화(161)는 데이터 서버(164)에 의해 제공되는 데이터 관리 서비스 및 가입 서비스를 사용하여 커피가 준비되었다는 통지를 수신할 수 있다.

도 7은 온 보드 유닛이 다수의 SL 엔티티들과 접속할 수 있는 다수의 서비스 계층 엔티티들의 사용을 위한 제1 예시적인 환경을 예시한다. 전자 요금 징수(electronic toll collection)(ETC)는 지능형 교통 시스템(Intelligent Transportation System)의 일부이다. ETC는 통행료를 전자적으로 징수하여 유료 도로의 지연을 감소시키는 데 도움이 된다. ETC 시스템들은 통과하는 차량들이 프로그램에 등록되어 있는지 여부를 결정하고, 등록되어 있지 않은 차량들에 대해서는 집행자들에게 경보를 알리고, 등록된 차량 소유자들에 대해서는 정지할 것을 요청할 필요 없이 그들의 계정들에서 전자적으로 돈을 인출한다. 온 보드 유닛(On board unit)(OBU)(171)은 노변 CSE(175) 또는 노변 CSE(176)를 통해 ETC 서비스 플랫폼(173) 또는 ETC 서비스 제공자(174)와 통신 가능하게 접속될 수 있는 차량(171)에 위치된 디바이스이다. OBU(171)는 ETC 서비스들을 제공하기 위해, 예를 들어, 차량(171)의 OBU(172)를 인가하거나 또는 통행료를 지불하도록 차량(171)의 OBU(172)와 연관된 계정에서 돈을 인출하는 등을 위해 ETC 서비스 제공자(174)에 등록할 수 있다. OBU(172)는 통신 서비스들을 제공하기 위해 로컬 노변 CSE(175) 및 노변 CSE(176)에 등록할 수 있다. OBU(172)는 또한 차량이 하나의 CSE의 커버리지로부터 다른 CSE의 커버리지로 이동하는 것과 동시에 노변 CSE(175) 및 노변 CSE(176)에 등록할 수 있다.

도 8 및 도 9에 예시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 예시된 것과 같은 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 이들의 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해될 것이다. 즉, 도 8 및 도 9에 예시된 방법(들)은 도 22c 또는 도 22d에 예시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있으며, 이 컴퓨터 실행 가능 명령어들은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 8, 도 9 및 도 19에 예시된 단계들을 수행한다. 예에서, M2M 디바이스들의 상호 작용에 관해 이하에서 더 상세하게 설명하자면, 도 8의 레지스트리(101)는 도 22a의 M2M 단말 디바이스(18) 상에 상주할 수 있고, 도 8의 레지스트라(102)는 도 22a의 M2M 게이트웨이 디바이스(14) 상에 상주할 수 있다.

도 8은 제1 시나리오에 대한 예시적인 메시지 흐름을 예시한다. 요약하면, 이 제1 시나리오에 있어서, 레지스트리 엔티티(101)는 등록 요청 메시지 내에서 레지스트라 엔티티(102)가 액세스를 허가하기를 원하는 서비스들을 특정한다. 이 개시내용에서는, SL 발견 기능들(본 명세서에서 상세히 논의되지 않음)을 통해, 레지스트리 엔티티(101)가 자신이 등록할 수 있는 엔티티들뿐만 아니라 엔티티들 각각에 의해 제공되는 서비스들을 찾을 수 있다고 가정한다. oneM2M 아키텍처에서, CSE에 의해 제공되는 서비스들은 발견(Discovery), 위치(Location), 통신 관리 및 전달 핸들링(Communication Management and Delivery Handling) 등과 같은 CSF들일 수 있다. CSE에 의해 제공되는 서비스들은 메시지 라우팅 서비스(Message Routing Service)와 같은 CSF들 중 하나로서 열거되지 않은 서비스들일 수 있다.

도 8에 예시된 제1 시나리오와 관련된 세부사항들은 이하에서 설명된다. 여기서, 레지스트리 엔티티(101)는 등록 동안에 레지스트라 엔티티(102)에 의해 호스팅되는 서비스들을 프로액티브하게 요청한다. 단계(181)에서, 레지스트리 엔티티(101)는 레지스트라 엔티티(102)에 등록 요청을 포함하는 메시지를 전송한다. 단계(181)의 메시지는 레지스트라 엔티티(102) 상에서 사용 가능하고 레지스트리 엔티티(101)에 의해 요청된 서비스(들)의 식별자(들)를 포함할 수 있다. 단계(182)에서, 단계(181)의 메시지를 수신하면, 레지스트라 엔티티(102)는 특히 (팩터들에 기초하여) 레지스트리 엔티티(101)의 등록을 수락할지 여부, 레지스트리 엔티티(101)에게 요청된 서비스들의 액세스를 허가할지 여부 또는 레지스트리 엔티티(101)에게 어떤 서비스들이 허가될지를 결정한다.

도 8의 단계(182)를 계속 참조하면, 레지스트리 엔티티(101)의 서비스 가입 프로파일 및 액세스 제어 정책에 추가하여, 레지스트라 엔티티(102)가 고려할 수 있는 팩터들 중 일부 예들은 다음과 같다. 팩터들은 특히 최대 사용자들의 수, 가용 용량, 서비스 요금, 레지스트리(101)의 우선순위, 또는 서비스들을 핸들링하기 위한 레지스트리(101)의 능력(예를 들어, 프로세싱 전력, 메모리, 인터페이스-그래픽 등)을 포함할 수 있다. 최대 사용자들의 수의 경우, 요청된 서비스는 최대로 지원되는 사용자들의 수가 제한될 수 있다. 현재의 활성 사용자들이 이 숫자보다 적은 경우, 레지스트리 엔티티(101)는 서비스에 대한 액세스를 허가받을 수 있다. 그렇지 않으면, 레지스트리 엔티티(101)는 이 요청된 서비스에 대해 거절될 수 있다. 가용 용량과 관련하여, 레지스트라 엔티티(102)는 요청된 서비스에 대해 레지스트리 엔티티(101)를 지원하는 데 필요한 용량을 추정할 수 있다. 용량은 컴퓨팅 용량, 배터리, 스토리지, 부하 및 스케줄 등일 수 있다. 레지스트라 엔티티(102)의 가용 용량이 낮은 경우, 레지스트리 엔티티(101)는 이 요청된 서비스에 대해 거절될 수 있다. 그렇지 않고, 레지스트라 엔티티(102)가 충분한 용량을 갖는 경우, 레지스트리 엔티티(101)는 이 서비스에 대한 액세스를 허가받을 수 있다. 서비스 요금 및 레지스트리(101)의 계정 잔액의 경우, 요청된 서비스는 서비스를 사용하기 전에 지불되어야 하는 서비스와 연관된 서비스 요금을 부과받을 수 있다. 레지스트리(101)의 계정 잔액에 따라, 서비스가 허가될 수도 있고 허가되지 않을 수도 있다. 레지스트라 엔티티(102)는 과금 및 빌링을 담당하는 엔티티와 통신할 필요가 있을 수 있다. 레지스트리(101)의 우선순위의 경우, 각각의 레지스트리 엔티티는 상이한 클래스들에 있을 수도 있고 또는 상이한 우선순위, 예를 들어, 플래티넘, 골드, 실버 등을 가질 수도 있다. 동일한 서비스를 대기하는 다른 레지스트리들도 있는 경우, 클래스 레벨은 요청된 서비스에 대한 액세스를 획득하는 데에 있어서 레지스트리 엔티티(101)의 우선순위를 구별한다.

도 8의 단계(182)를 계속 참조하면, 레지스트라 엔티티(102)는 레지스트리 엔티티(101)에 대해 요청된 서비스들에 대한 결정들을 할 수 있다. 결정은 다음의 리스트들, 즉, 허가된 서비스 리스트, 거절된 서비스 리스트 또는 계류 중인 서비스 리스트에 속할 수 있다. 허가된 서비스 리스트는 레지스트라 엔티티(102)에 의해 레지스트리 엔티티(101)에 허가되는 요청된 서비스들의 리스트이다. 허가된 서비스들 각각은 레지스트리 엔티티(101)가 서비스를 사용할 자격이 있는 시간 기간(또는 시간 인터벌들 또는 최대 허용 가능한 사용량/액세스 시간의 리스트)과 연관될 수 있다. 이 필드가 비어 있으면, 기본적으로 서비스는 레지스트리 엔티티(101)가 등록 해제할 때 종료된다. 허가된 서비스들 각각은 또한 상호성(mutuality) 어트리뷰트와 연관될 수 있으며, 이는 서비스가 양방향성인지 단방향성인지를 나타낸다. 상호성이 양방향성인 경우, 이는 레지스트리 엔티티(101)도 또한 레지스트라 엔티티(102)에 이 서비스를 제공함을 의미한다. 예를 들어, 메시지 라우팅 서비스는 기본적으로 양방향성이다. 상호성이 단방향성인 경우, 서비스는 레지스트라 엔티티(102)로부터 레지스트리 엔티티(101)로만 제공된다. 거절된 서비스 리스트는 레지스트라 엔티티(102)에 의해 거절된 요청된 서비스들의 리스트이다. 거절된 서비스 각각은 레지스트라 엔티티(102)가 레지스트리 엔티티(101)로부터의 서비스 요청을 거절하는 이유와 연관될 수 있다. 충분하지 못한 용량, 서비스 요금에 대한 충분하지 못한 잔액 등과 같은 다수의 이유들이 있을 수 있다. 거절된 서비스 각각은 recommendedRegistrar와 연관될 수 있으며, 여기서 레지스트리가 서비스를 획득할 수 있다. 거절된 서비스 리스트는 동일한 타입의 레지스트리 엔티티들에게 동일한 서비스들을 허가할지 여부를 결정하기 위한 팩터로서 나중에 사용될 수 있다. 거절된 서비스 리스트 정보는 현재의 레지스트리 엔티티와 유사한 타입을 갖는 다른 엔티티들에 의해 리트리브될 수 있으며, 예를 들어, 이들 모두는 리소스 제약형 디바이스들(예를 들어, 최소한의 메모리, 최소한의 프로세싱, 전력/에너지에 대한 액세스, 불충분한 무선 대역폭 및 통신 능력 등을 갖는 센서들)이다. 계류 중인 서비스 리스트는 계류 중인 요청된 서비스들의 리스트이며, 나중에 레지스트리 엔티티(101)에 대한 액세스가 허가될 수 있다. 계류 중인 서비스들 각각은 레지스트리 엔티티(101)의 순서(이 순서는 현재의 레지스트리 엔티티 앞에 얼마나 많은 다른 레지스트리 엔티티들이 대기하고 있는지를 나타냄), 및 레지스트리 엔티티(101)가 대기할 필요가 있는 추정된 시간 기간과 연관될 수 있다.

계속해서 도 8을 참조하면, 단계(183)에서, 레지스트라 엔티티(102)는 응답 메시지에서 결정들을 리턴한다. 표 1은 응답 메시지에서의 새로운 필드들뿐만 아니라, 이들 필드들 각각과 연관된 파라미터들(이탤릭체)을 나타낸다.

레지스트라 엔티티(102)는 표 2에 나타낸 바와 같이 자신에게 등록한 레지스트리 엔티티들의 레코드를 국부적으로 유지한다. 레코드는 다음의 필드들을 갖는다. "Registree ID"는 동일한 SP 도메인 내의 레지스트리 엔티티(101)의 고유한 식별자이다. "Requested Service From"은 등록 메시지에서 레지스트리 엔티티(101)로부터 요청된 서비스들의 식별자들의 리스트이다. "Granted Service To"는 레지스트라 엔티티(102)에 의해 레지스트리 엔티티(101)에 허가된 서비스들의 식별자들의 리스트이다. 단계(182)에서 논의된 바와 같이, 각각의 허가된 서비스는 validTime이라고 불리는 어트리뷰트와 연관될 수 있으며, 이는 레지스트라 엔티티(102)가 레지스트리 엔티티(101)에게 제공하는 서비스의 유효 시간 기간을 나타낸다. 각각의 허가된 서비스는 또한 상호성이라고 불리는 어트리뷰트와 연관될 수 있으며, 이는 서비스가 양방향성인지 또는 단방향성인지를 나타낸다. "Rejected Service To"는 레지스트라 엔티티(102)에 의해 레지스트리 엔티티(101)에 대해 거절된 서비스들의 식별자들의 리스트이다. 단계(182)에서 논의된 바와 같이, 각각의 거절된 서비스는 reason이라고 불리는 어트리뷰트와 연관될 수 있으며, 이는 레지스트라 엔티티(102)가 레지스트리 엔티티(101)로부터의 서비스 요청을 거절한 이유를 설명한다. 그리고, 각각의 거절된 서비스는 또한 recommendedRegistrar라고 불리는 어트리뷰트와 연관될 수 있으며, 이는 현재의 레지스트라 엔티티가 레지스트리 엔티티(101)에게 추천하는 다른 엔티티들을 나타내고, 이 다른 엔티티들로부터 레지스트리 엔티티(101)가 서비스를 요청할 수 있다.

도 8의 단계(183)를 계속 참조하면, "Pending Service To"는 레지스트라 엔티티(102)가 레지스트리 엔티티(101)에 대해 액세스를 허가하기 위해 계류 중인 서비스들의 식별자들의 리스트이다. 단계(182)에서 논의된 바와 같이, 각각의 계류 중인 서비스는 다음의 어트리뷰트들을 갖는다. estimatedWaitTime은 레지스트라 엔티티(102)가 레지스트리 엔티티(101)에게 서비스의 액세스를 허가하는 데 추정되는 대기 시간을 나타낸다. allowedWaitTime은 레지스트리 엔티티(101)로부터의 허용 대기 시간을 나타내며, 이는 단계(184)에서 논의될 것이다. priorityOrder는 동일한 서비스를 또한 요청하고 있는 다른 레지스트리 엔티티들 중 레지스트리 엔티티(101)의 우선순위를 나타낸다. Status는 계류 중인 서비스의 상태를 나타내며, 처음에는 "대기 중"으로 설정된다. 허용 대기 시간 전에 서비스가 허가되는 경우, 상태는 "허가됨"으로 변경된다. 허용 대기 시간 전에 서비스가 거절되는 경우, 상태는 "거절됨"으로 변경된다. 허용 대기 시간이 만료될 때에도 서비스가 여전히 대기 중인 경우, 상태는 "만료 및 거절됨"으로 변경된다. 임의적으로, 레지스트라 엔티티(102)는 허가된 계류 중인 서비스 리스트 내의 서비스들을 허가된 서비스 리스트로 이동시키고, 거절된 계류 중인 서비스 리스트 내의 서비스들을 거절된 서비스 리스트로 이동시킬 수 있다.

계속해서 도 8을 참조하면, 단계(184)에서, 레지스트리 엔티티(101)는 응답 메시지를 프로세싱한다. 레지스트리 엔티티(101)가 양방향성 타입을 갖는 허가된 서비스가 있음을 발견하는 경우, 이 서비스가 자체적으로 지원되고 레지스트라 엔티티(102)에게 허가될 수 있는지를 확인한다. 레지스트리 엔티티(101)가 거절된 서비스가 있음을 발견하는 경우, 임의적으로, 거절된 서비스에 등록하고 이를 요청하기 위해 다른 SL 엔티티를 선택할 수 있다. 레지스트리 엔티티(101)가 계류 중인 서비스가 있음을 발견하는 경우, 레지스트리 엔티티(101)는 다음의 액션들 중 하나의 액션을 취할 수 있다. 제1 액션은 레지스트리 엔티티(101)가 계류 중인 서비스에 등록하고 이를 요청하기 위해 다른 SL 엔티티를 선택할 수 있는 것일 수 있다. 그리고, 이는 허용 대기 시간을 0으로 설정함으로써 서비스 요청을 종료하도록 단계(185)에서 등록 확인 메시지를 전송할 것이다. 제2 액션은 레지스트리 엔티티(101)가 계류 중인 서비스가 허가되기를 기다릴 수 있다는 것일 수 있다. 이는 허용 대기 시간을 설정함으로써 대기할 수 있는 시간을 나타내도록 단계(185)에서 등록 확인 메시지를 전송할 수 있다.

계속해서 도 8을 참조하면, 단계(185)에서, 레지스트리 엔티티(101)는 등록 확인 메시지를 전송할 수 있다. 표 3은 확인 메시지에서의 새로운 필드들뿐만 아니라, 이들 필드들 각각과 연관된 파라미터들(이탤릭체)을 나타낸다.

계속해서 도 8을 참조하면, 단계(186)에서, 레지스트라 엔티티(102)는 등록 확인 메시지를 핸들링하고, 레지스트리 엔티티(101)의 각각의 계류 중인 서비스에 대한 허용 대기 시간을 설정한다. allowedWaitTime이 0 또는 0 미만인 경우, 계류 중인 서비스 요청은 취소된다. 계류 중인 서비스는 레지스트리 엔티티(101) 레코드에 대해 삭제된다. allowedWaitTime이 비어 있지 않고 0보다 큰 경우, 계류 중인 서비스의 allowedWaitTime이 레지스트리 엔티티(101) 레코드에 대해 업데이트된다. allowedWaitTime이 비어 있는 경우, 계류 중인 서비스의 allowedWaitTime은 레지스트리 엔티티(101)에 대해 제한되지 않는 것으로 가정된다. 즉, 레지스트리 엔티티(101)는 항상 계류 중인 서비스의 리스트에 있을 것이고, 그 차례를 대기한다. 단계(187)에서, 레지스트라 엔티티(102)는 계류 중인 서비스의 상태를 모니터링한다. 계류 중인 서비스가 일정 시간 후에 레지스트리 엔티티(101)에 허가될 수 있음을 발견하는 경우, 여전히 레지스트리 엔티티(101)의 허용 대기 시간 내인지를 체크할 것이다. 허용 대기 시간 내인 경우, 단계(188)에서와 같은 계류 중인 서비스 업데이트 메시지를 레지스트리 엔티티(101)에 전송할 것이다. 허용 대기 시간이 만료되는 경우, 계류 중인 서비스는 레지스트라 엔티티(102)에 의해 거절된다. 한편, 레지스트라 엔티티(102)는 국부적으로 유지되는 계류 중인 서비스의 상태를 업데이트한다. 계류 중인 서비스가 허가된 경우, 레지스트라 엔티티(102)는 허가된 서비스 ID 필드에 서비스 ID를 추가한다. 계류 중인 서비스가 거절된 경우, 레지스트라 엔티티(102)는 거절된 서비스 ID 필드에 서비스 ID를 추가한다.

계속해서 도 8을 참조하면, 단계(188)에서, 계류 중인 서비스의 상태가 업데이트되면, 레지스트라 엔티티(102)는 계류 중인 서비스 업데이트 메시지를 레지스트리 엔티티(101)에 전송한다. 표 4는 확인 메시지에서의 새로운 필드들뿐만 아니라, 이들 필드들 각각과 연관된 파라미터들(이탤릭체)을 나타낸다. 상태는 허가된 것일 수도 있고 또는 거절된 것일 수도 있다. 상태가 허가된 경우, 단계(182)에서 설명된 바와 같이 서비스의 타입이 표시된다.

서비스 요청에 대한 초기 등록 후에, 다음의 액션들이 레지스트리 엔티티(101)와 레지스트라 엔티티(102) 사이에서 발생할 수 있다. 레지스트리 엔티티(101)는 서비스 식별자를 포함하는 서비스 취소 요청(Service Cancellation Request)을 전송함으로써 레지스트라 엔티티(102)로부터 허가된 서비스를 취소할 권리가 있다. 레지스트라 엔티티(102)는 레지스트리 엔티티(101)에 대한 서비스를 종료하고, 서비스의 허가된 사용자 리스트로부터 레지스트리 엔티티(101)를 제거할 것이다. 레지스트리 엔티티(101)는 또한 서비스의 식별자를 포함하는 서비스 요청(Service Request)을 전송함으로써 레지스트라 엔티티(102)로부터의 새로운 서비스 또는 서비스들을 요청할 권리가 있다(단, 서비스 발견 절차는 사전에 발생할 수 있으며, 필터 기준 기반 발견 또는 보다 고급의 발견 메커니즘들, 예를 들어, 시맨틱스 기반 쿼리에 의해 수행될 수 있다). 레지스트라 엔티티(102)는 요청 서비스를 허가/거절하기 위해 위에서 설명된 것과 유사한 절차들을 따를 것이다. 레지스트라 엔티티(102)는 레지스트리 엔티티(101)에게 허가된 서비스를 종료하도록 선택할 수 있다. 레지스트라 엔티티(102)는 서비스의 식별자를 포함하는 서비스 종료 통지(Service Termination Notification)에 대한 메시지를 레지스트리 엔티티(101)에 전송할 수 있다. 서비스 종료 통지를 위한 메시지는 또한 서비스 종료의 유예 기간을 포함할 수 있다.

도 9는 제2 시나리오에 대한 예시적인 메시지 흐름을 예시한다. 요약하면, 이 제2 시나리오의 경우, 레지스트리 엔티티(101)는 등록 메시지 내에서 레지스트라 엔티티(102)에서 호스팅되는 서비스들을 프로액티브하게 요청하지 않는다. 따라서, 이 시나리오에서는 기존 등록 메시지가 수정될 필요가 없다. 단계(191)에서, 레지스트리 엔티티(101)는 레지스트라 엔티티(102)에 등록 메시지(기존의 등록 메시지에 필요한 수정이 없음)를 전송한다.

계속해서 도 9를 참조하면, 단계(192)에서, 레지스트라 엔티티(102)는 어떤 서비스들이 레지스트리 엔티티(101)에 허가되어야 하는지를 결정하기 위해 팩터들을 체크한다. 도 8과 관련하여 단계(182)에서 열거된 팩터들이 적용 가능하다. 레지스트라 엔티티(102)는 레지스트리 엔티티(101) 타입을 고려할 수 있다(단, 이하의 팩터들에 관한 정보는 레지스트리의 시맨틱스 정보, 예를 들어, 레지스트리의 타입으로서 등록 메시지에 포함될 수 있다). 레지스트리 엔티티(101)는 단지 데이터를 감지하고 보고하는 리소스 제약형 디바이스일 수 있으므로, 레지스트리 엔티티(101)는 데이터 관리 및 레포지토리 서비스(Data Management and Repository Service), 디바이스 관리 서비스(Device Management Service), 위치 서비스(Location Service) 등과 같은 특정 서비스들만을 필요로 할 수 있다. 레지스트리 엔티티(101)는 발견 서비스(Discovery Service), 서비스 과금 및 어카운팅 서비스(Service Charging and Accounting Service) 등을 필요로 하지 않는 타입일 수 있다. 레지스트리 엔티티(101)는 레지스트라 엔티티(102)에 의해 저장된 데이터를 리트리브하고 사용하기 위한 애플리케이션들을 호스팅하는 디바이스의 타입일 수 있다. 따라서, 레지스트리 엔티티(101)는 데이터 관리 및 레포지토리 서비스(Data Management and Repository Service), 발견 서비스(Discovery Service), 가입 및 통지 서비스(Subscription and Notification Service) 등과 같은 특정 서비스만을 필요로 할 수 있다. 레지스트리 엔티티(101)는 디바이스 관리(Device Management), 네트워크 서비스 노출 서비스(Network Service Exposure Service) 등을 필요로 하지 않을 수 있다. 레지스트리 엔티티(101)는 주로 자신으로부터 발신되지 않은 메시지들을 포워딩하는 게이트웨이 타입 디바이스일 수 있다. 따라서, 레지스트리 엔티티(101)는 통신 관리 및 전달 핸들링 서비스(Communication Management and Delivery Handling Service), 메시지 라우팅 서비스(Message Routing Service) 등과 같은 특정 서비스들만을 필요로 할 수 있다. 레지스트리 엔티티(101)는 데이터 관리 및 레포지토리 서비스(Data Management and Repository Service), 디바이스 관리 서비스(Device Management Service) 등을 필요로 하지 않을 수 있다. 단계(193)에서, 레지스트라 엔티티(102)는 허가된 서비스 리스트를 갖는 등록 응답을 레지스트리 엔티티(101)에 리턴한다.

도 10은 다수의 레지스트라 엔티티들에 대한 예시적인 등록을 예시한다. 다수의 단방향성 등록들의 연결(등록 체인)이 루프를 형성할 수 있다. 예를 들어, oneM2M에서, 두 개의 MN-CSE A와 B는 서로 등록할 수 있다. 세 개의 MN-CSE A, B 및 C에서는, A가 B에 등록하고, B가 C에 등록하고, C는 또한 A에 등록할 수 있다. 도 10은 하나의 레지스트리 엔티티(레지스트리 엔티티(101))로부터 다수의 레지스트라 엔티티들(레지스트라 엔티티(102), 레지스트라 엔티티(103) 및 레지스트라 엔티티(104))로의 예를 예시한다. 레지스트라 엔티티(102), 레지스트라 엔티티(103) 및 레지스트라 엔티티(104)는 이미 그들 사이에 등록 루프를 형성했다. 레지스트라 엔티티(103)와 레지스트라 엔티티(104)는 서로 등록되어 있다. 이것은 종래의 SL 등록과 반대이다.

도 10을 참조하면, 임의의 레지스트리와 레지스트라 엔티티 쌍 사이의 등록은 제1 시나리오(예를 들어, 도 8 및 연관된 논의) 또는 제2 시나리오(예를 들어, 도 9 및 연관된 논의)를 따를 수 있다. 바꾸어 말하면, 레지스트리 엔티티는 제1 시나리오에서 설명된 바와 같이 레지스트라 엔티티에 등록할 수 있고, 제2 시나리오에서 설명된 바와 같이 다른 레지스트라 엔티티에 등록할 수 있다. 제1 시나리오 및 제2 시나리오를 포함하는 상황을 가정하면, 예에서, 다수의 레지스트라 엔티티들에 대한 등록은 동일한 레지스트리 엔티티로부터 발신된 멀티캐스트 등록 메시지에서 수행될 수 있다.

SL 엔티티의 경우, SL 엔티티가 다른 SL 엔티티로부터 특정 서비스에 대한 액세스를 허가받을 수 있는 다수의 방식들이 있다. 제1 방식에서, SL 엔티티는 제1 시나리오 또는 제2 시나리오에서 논의된 바와 같이 다른 SL 엔티티에 등록한다. 따라서, SL 엔티티는 레지스트리 엔티티로서 서비스의 액세스를 허가받는다. 제2 방식에서, SL 엔티티는 특정 서비스에 대해 다른 SL 엔티티에 의해 등록되어 있다. 그러나, 서비스는 양방향성 타입을 갖는다. 레지스트라 엔티티로서의 SL 엔티티는 또한 레지스트리 엔티티로부터 서비스의 액세스를 허가받는다.

각각의 SL 엔티티는 또한 표 5에 나타낸 바와 같이 그 자신이 서비스들을 수신하는 SL 엔티티들의 레코드를 유지한다. SL 엔티티 ID는 로컬 SL 엔티티에게 특정 서비스들을 제공하는 SL 엔티티의 고유한 식별자를 나타낸다. "Granted Service From"은 SL 엔티티로부터 로컬 SL 엔티티에 허가되는 서비스들의 식별자들의 리스트이다. 각각의 허가된 서비스는 validTime이라고 불리는 어트리뷰트와 연관될 수 있으며, 이는 SL 엔티티가 로컬 SL 엔티티에 제공하는 서비스의 유효 시간 기간을 나타낸다.

oneM2M 예들이 이하에서 보다 상세하게 논의된다. AE는 둘 이상의 CSE(예를 들어, ASN-CSE(161), MN-CSE(162) 또는 IN-CSE(164))에 등록될 수 있다. ASN-CSE(161)는 둘 이상의 다른 CSE(예를 들어, MN-CSE(163) 또는 IN-CSE(164))에 등록될 수 있다. MN-CSE(163)는 둘 이상의 다른 CSE(MN-CSE(162) 또는 IN-CSE(164))에 등록될 수 있다. IN-CSE는 둘 이상의 다른 CSE(IN-CSE)에 등록될 수 있다. 다수의 단방향성 등록들의 연결(등록 체인)이 루프를 형성할 수 있다. 예를 들어, 두 개의 MN-CSE A와 B(예를 들어, 레지스트라(103)와 레지스트라(104))는 서로 등록할 수 있다. 세 개의 MN-CSE A, B 및 C(예를 들어, 각각 레지스트라(103), 레지스트라(102) 및 레지스트라(104))가 있을 수 있으며, 여기서 A는 B에 등록하고, B는 C에 등록하고, C는 A에 등록할 수 있다.

AE 또는 CSE는 CSE에 등록하고, 레지스트라 CSE에 의해 호스팅되는 로컬 서비스들에 대한 액세스 획득을 위한 요청을 프로액티브하게 할 수 있다. 레지스트라 CSE는 레지스트리 AE 또는 CSE의 등록 요청을 수락할 수 있지만, 모든 자신의 서비스들 대신에 레지스트리 AE 또는 CSE에게 서비스들의 부분적인 세트에 대한 액세스만을 허가할 수 있다.

레지스트리 AE 또는 CSE는 자신의 등록 요청 메시지 내에서 서비스들을 프로액티브하게 요청할 필요가 없을 수 있다. 레지스트라 CSE는 어떤 서비스들이 레지스트리 AE 또는 CSE에 의해 필요할 수 있는지를 결정하고, 레지스트리 AE 또는 CSE에 해당 서비스들에 대한 액세스를 허가할 수 있다.

여기에 요약된 유연한 서비스 계층 등록을 지원하기 위해, 이하에서 논의되는 새로운 어트리뷰트들 및 새로운 차일드 리소스들이 remoteCSE 및 AE 리소스에 추가되어야 한다.

<CSEBase> 리소스 강화

도 11은 <CSEBase>에 추가된 예시적인 새로운 차일드 리소스들을 예시한다. <CSEBase>(220)는 새로운 차일드 리소스들, 즉, 표 6에 나타낸 바와 같이 <localService>(221) 및 <grantedServiceFrom>(222)를 포함할 수 있다.

<remoteCSE> 리소스 강화

도 12는 <remoteCSE>(224)에 추가된 예시적인 새로운 차일드 리소스들 및 어트리뷰트를 예시한다. <remoteCSE>(224)는 새로운 차일드 리소스들, 즉, 표 7에 나타낸 바와 같이 <grantedServiceTo>(226), <rejectedServiceTo>(227), <pendingServiceTo>(228)를 포함할 수 있다. <remoteCSE>(224)는 새로운 어트리뷰트, 즉, 표 8에 나타낸 바와 같은 requestedServiceFrom(225)를 포함할 수 있다.

<AE> 리소스 강화

도 13은 <AE>(230)에 추가된 예시적인 새로운 차일드 리소스들 및 어트리뷰트를 예시한다. <AE>(230)는 새로운 차일드 리소스들, 즉, 표 9에 나타낸 바와 같이, <grantedServiceTo>(226), <rejectedServiceTo>(227) 및 <pendingServiceTo>(228)를 포함할 수 있다. <AE>는 새로운 어트리뷰트, 즉, 표 10에 나타낸 바와 같이, requestedServiceFrom(225)를 포함할 수 있다.

<localService> 리소스

도 14는 호스팅 CSE에 의해 제공되는 서비스들을 보유하는 예시적인 <localService>(221) 리소스를 예시하며, 이 서비스들은 발견(Discovery), 위치(Location), 통신 관리 및 전달 핸들링(Communication Management and Delivery Handling) 등과 같은 CSF들일 수 있다. 로컬 서비스는 또한 본 명세서에서 설명된 메시지 포워딩 서비스와 같이 CSF들 이외의 서비스들일 수 있으며, 이는 중간 노드가 있을 때에는 각각의 CSE에 의해 또는 CSE에 보유된 데이터에 의해 인에이블되는 서비스들(예를 들어, 온도 서비스, 트래픽 모니터링 서비스 등)에 의해 암시적으로 제공된다. 표 11은 <localService>(221)의 어트리뷰트들을 나타낸다. 공통 어트리뷰트들은 표에 표시되지 않는다. 단, <localService>(221) 리소스의 accessControlPolicyIDs 어트리뷰트는 서비스에 대한 액세스가 허가된 AE들 또는 CSE들을 나타내는 액세스 권한 정책들의 식별자들의 리스트를 포함한다.

<localService>(221) 리소스는 <CSEBase>(220)의 패런트를 갖는다.

<grantedServiceTo> 리소스

도 15는 호스팅 CSE에 의해 remoteCSE 또는 AE에 허가된 서비스들을 보유하는 예시적인 <grantedServiceTo>(226) 리소스를 예시한다. 표 12는 <grantedServiceTo>(226)의 어트리뷰트들을 나타낸다.

<grantedServiceTo>(226) 리소스는 <AE>(230) 또는 <remoteCSE>(224)의 패런트를 갖는다. 이 리소스는 다른 CSE가 서비스들을 제공할 때 로컬 CSE와 협력할 수 있도록 동일한 AE 또는 remoteCSE에 허가된 서비스들을 알고 싶을 때 타겟으로 될 것이다.

<rejectedServiceTo> 리소스

도 16은 호스팅 CSE가 CSE 또는 AE에 대한 액세스 허가를 거절한 서비스들을 보유하는 예시적인 <rejectedServiceTo>(227) 리소스를 예시한다. 표 13은 <rejectedServiceTo>(227)의 어트리뷰트들을 나타낸다.

<rejectedServiceTo>(227) 리소스는 <AE>(230) 또는 <remoteCSE>(224)의 패런트를 갖는다. AE/CSE는, 거절될 수 있는 전체 리스트를 포함하지 않고도, 어떤 서비스들이 레지스트라 CSE에 의해 허가될 수 있는지를 이해하기 위하여 유사한 타입의 AE/CSE의 이 정보를 리트리브할 수 있다.

<pendingServiceTo> 리소스

도 17은 AE 또는 CSE가 호스팅 CSE에 의해 허가되기를 대기하는 계류 중인 서비스들을 보유하는 예시적인 <pendingServiceTo>(228) 리소스를 예시한다. 표 14는 <pendingServiceTo>(228)의 어트리뷰트들을 나타낸다.

<pendingServiceTo>(228) 리소스는 <AE>(230) 또는 <remoteCSE>(224)의 패런트를 갖는다.

<grantedServiceFrom> 리소스

도 18은 CSE로부터 호스팅 CSE에 허가된 서비스들을 보유하는 예시적인 <grantedServiceFrom>(222) 리소스를 예시한다. 표 15는 <grantedServiceFrom>의 어트리뷰트들을 나타낸다.

<grantedServiceFrom>(222) 리소스는 <CSEBase>(220)의 패런트를 갖는다.

도 19는 유연한 등록을 위한 예시적인 메시지 흐름을 예시한다. 단계(211)에서, 발신자(Originator)(201)는 CREATE 요청 메시지를 수신자(202)에 전송한다. requestedService 파라미터가 단계(211)의 메시지에 포함될 수 있다. 발신자(201)는 requestedService 파라미터로 remoteCSE 리소스의 생성을 요청한다. 단계(212)에서, 수신자(202)는 <remoteCSE> 리소스의 생성을 수행한다. 수신자(202)는 요청된 서비스들의 액세스를 허가하고 remoteCSE 리소스를 생성할지 여부를 결정하기 위해 팩터들을 체크한다. 계류 중인 서비스가 있는 경우, 발신자(201)가 계류 중인 서비스의 상태 변경에 대한 통지들을 수신하도록, 수신자(202)는 발신자(201)에 대해 pendingServiceTo 리소스에 대한 가입을 생성한다. 단계(213)에서, 수신자(202)는 응답 메시지로 응답한다. 단계(213)의 응답 메시지는 grantedServiceTo, rejectedServiceTo 및 pendingServiceTo를 포함할 수 있다. 단계(214)에서, 발신자(201)는 CREATE 응답 메시지의 수신 시에 자신의 <CSEBase> 리소스 아래에 <remoteCSE> 리소스를 국부적으로 생성한다. 이 리소스는 수신자(202)(호스팅 CSE)를 나타내고 있다. 발신자(201)는 grantedServiceTo, pendingServiceTo를 프로세싱하고, 본 명세서에서 논의된 바와 같이 그에 따라 액션을 취한다(예를 들어, 도 8). 단계(215)에서, 발신자(201)는 pendingService의 allowedWaitTime 어트리뷰트를 업데이트하기 위해 수신자(202)(CREATE 요청 메시지에서와 동일한 To)를 향해 UPDATE 요청을 발행할 수 있다. 단계(216)에서, 수신자(202)는 대응하는 pendingService의 allowedWaitTime 어트리뷰트를 업데이트한다. 단계(217)에서, 수신자(202)는 발신자(201)가 사용 가능한 pendingService를 찾고, 이에 따라 pendingService 상태를 업데이트한다. 단계(218)에서, 수신자(202)는 서비스들의 상태 변경에 대해 통지하기 위해 발신자(201)를 향해 NOTIFY 요청을 발행한다. 단계(219)에서, 발신자(201)는 통지를 프로세싱하고, grantedService 리소스를 업데이트한다.

도 20은 본 명세서의 방법들, 디바이스들 및 시스템들에 사용될 수 있는 예시적인 그래픽 사용자 인터페이스를 예시한다. 사용자 인터페이스는 등록 메시지(321)에 포함될 서비스들 또는 메시지(322)에서와 같이 레지스트라 엔티티(205)로부터 허가된 서비스들, 레지스트라 엔티티(205)로부터 거절된 서비스들, 또는 레지스트라 엔티티(205)로부터의 계류 중인 서비스들과 같이, 등록과 관련된 정보를 디스플레이하고 구성하기 위해 (예를 들어, AE 또는 CSE의 포맷으로) 레지스트리 엔티티(204)로서 사용자 단말에 추가될 수 있다. 사용자 인터페이스는 또한, 특히, 레지스트라 엔티티에 등록된 모든 레지스트리 엔티티들, 각각의 레지스트리 엔티티에 허가된 서비스들, 각각의 레지스트리 엔티티에 대해 거절된 서비스들 또는 각각의 레지스트리 엔티티에 대한 계류 중인 서비스들과 같이, 레지스트리 엔티티들과 관련된 정보를 디스플레이하기 위해 (예를 들어, CSE의 포맷으로) 레지스트라 엔티티(205)에 추가될 수 있다. 레지스트라 엔티티(205)에서, 요청된 서비스들의 퍼미션을 허가하고 등록을 수락할지 여부를 결정할 수 있다.

도 21은 본 명세서에서 논의된 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이를 예시한다. 디스플레이 인터페이스(231)(예를 들어, 터치 스크린 디스플레이)는 표 1 내지 표 15의 파라미터들과 같이 서비스 계층 등록과 연관된 텍스트를 블록(232)에 제공할 수 있다. 다른 예에서, 본 명세서에서 논의된 단계들 중 임의의 단계의 프로그레스(예를 들어, 전송된 메시지들 또는 단계들의 성공)가 블록(232)에서 디스플레이될 수 있다. 또한, 그래픽 출력(233)이 디스플레이 인터페이스(231) 상에 디스플레이될 수 있다. 그래픽 출력(233)은 다수의 서비스 계층 등록들을 갖는 디바이스들의 토폴로지, 본 명세서에서 논의된 임의의 방법 또는 시스템들의 프로그레스의 그래픽 출력 등일 수 있다.

도 22a는 유연한 서비스 계층 등록과 연관된 하나 이상의 개시된 개념(예를 들어, 도 6 내지 도 21 및 연관된 논의)이 구현될 수 있는 예시적인 머신-투-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT뿐만 아니라 IoT/WoT 서비스 계층 등의 컴포넌트일 수 있다.

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

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

도 22b를 참조하면, 필드 도메인에 예시된 M2M 서비스 계층(22)(예를 들어, 레지스트라 엔티티(205))은 M2M 애플리케이션(20)(예를 들어, 사용자(204)), M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 대한 서비스들을 제공한다. 예를 들어, 레지스트라 CSE(124)는 도 22b의 M2M 서비스 계층(22)에 있는 것으로 간주될 수 있다. 예를 들어, 레지스트리 AE(123)는 종종 도 22b의 서비스 계층(22)에서의 CSE 또는 애플리케이션 계층(20)에서의 AE이다. 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')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/컴퓨팅/스토리지 팜 등) 등에 의해 구현될 수 있다.

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

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

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

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

도 22c는, 예를 들어, M2M 단말 디바이스(18)(레지스트리 엔티티(204)를 포함할 수 있음) 또는 M2M 게이트웨이 디바이스(14)(레지스트라 엔티티(205)를 포함할 수 있음)와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 22c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 대상과 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, 전화(161), Wi-Fi 액세스 포인트(163), LTE eNB(162), 데이터 서버(164), 레지스트리 엔티티(101), 레지스트라 엔티티(102), 발신자(201), 수신자(202) 등)는 유연한 서비스 계층 등록을 위한 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

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

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

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

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

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적절한 메모리로부터의 정보에 액세스할 수 있고, 그러한 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 랜덤 액세스 메모리(random-access memory)(RAM), 판독 전용 메모리(read-only memory)(ROM), 하드 디스크, 또는 임의의 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(subscriber identity module)(SIM) 카드, 메모리 스틱, 보안 디지털(secure digital)(SD) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터와 같은 M2M 디바이스(30) 상에 물리적으로 위치하지 않은 메모리로부터의 정보에 액세스하고, 그러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는, 본 명세서에 설명된 예들 중 일부 예들에서의 유연한 서비스 계층 등록이 성공했는지 또는 실패했는지 여부(예를 들어, 계류 중인 서비스 ID, 허가된 서비스 ID 등)에 응답하여, 디스플레이 또는 지시자들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하거나, 또는 유연한 서비스 계층 등록 및 연관된 컴포넌트들의 상태를 다른 방식으로 나타내도록 구성될 수 있다. 디스플레이 또는 지시자들(42) 상의 제어 조명 패턴들, 이미지들 또는 컬러들은 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 6 내지 도 21 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는 유연한 서비스 계층 등록의 메시지들 및 절차들이 개시되어 있다. 메시지들 및 절차들은 사용자들이 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 유연한 서비스 계층 등록 리소스들을 요청하고, 특히 디스플레이(42) 상에 디스플레이될 수 있는 유연한 서비스 계층 등록의 리소스들을 요청, 구성 또는 질의하는 인터페이스/API를 제공하도록 확장될 수 있다.

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

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

프로세서(32)는 다른 주변 장치들(52)에 추가로 결합될 수 있으며, 이들은 추가적인 피쳐들, 기능 또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 또는 하드웨어 모듈을 포함할 수 있다. 예를 들어, 주변 장치들(52)은 가속도계, 생체 인식(예를 들어, 피규어 프린트) 센서들, 전자 나침반, 위성 송수신기, 센서, 디지털 카메라(사진 또는 비디오용), 범용 직렬 버스(USB) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비젼 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, 주파수 변조(frequency modulated)(FM) 무선 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등과 같은 다양한 센서들을 포함할 수 있다.

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

도 ZZD는, 예를 들어, 도 ZZA 및 도 ZZB의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있으며, 주로 컴퓨터 판독 가능 명령어들에 의해 그러한 명령어들이 저장되거나 액세스되는 수단이 무엇이든 간에 제어될 수 있다. 이러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하기 위해 중앙 처리 장치(CPU)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들 및 퍼스널 컴퓨터들에서, 중앙 처리 장치(91)는 마이크로프로세서라고 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 장치(91)는 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가 기능들을 수행하거나 또는 CPU(91)를 보조하는 임의적인 프로세서로서, 메인 CPU(91)와 구별된다. CPU(91) 또는 코프로세서(81)는 서비스 요구사항을 갖는 등록 요청과 같이 유연한 서비스 계층 등록을 위한 개시된 시스템들 및 방법들과 관련된 데이터를 수신, 생성 및 프로세싱할 수 있다.

동작 시에, CPU(91)는 명령어들을 인출(fetch), 디코딩 및 실행하고, 컴퓨터의 메인 데이터-전달 경로인 시스템 버스(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)을 도 22a 및 도 22b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는 데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

도면들에 예시된 바와 같이, 본 개시내용의 대상 - 유연한 서비스 계층 등록 - 의 바람직한 방법들, 시스템들 또는 장치들을 설명함에 있어서, 명확함을 위해 구체적인 용어가 사용된다. 그러나, 청구 대상은 그렇게 선택된 특정 용어에 제한되는 것으로 의도되지 않고, 각각의 특정 엘리먼트는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 점이 이해되어야 한다.

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

이 기술된 설명은 예들을 사용하여 최상의 모드를 포함한 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 한다. 본 발명의 특허 가능한 범위는 청구 범위에 의해 규정되며, 본 기술분야의 통상의 기술자에게 가능한 다른 예들(예를 들어, 단계들을 건너뛰거나, 단계들을 결합하거나, 본 명세서에 개시된 예시적인 방법들 사이에 단계들을 추가하는 것)을 포함할 수 있다. 그러한 다른 예들은, 청구 범위의 문자 언어와 상이하지 않은 구조적 엘리먼트들을 갖는 경우, 또는 청구 범위의 문자 언어와 비실질적인 차이들을 갖는 등가의 구조적 엘리먼트들을 포함하는 경우, 청구 범위의 범주 내에 있는 것으로 의도된다.

특히, 본 명세서에서 설명된 바와 같은 방법들, 시스템들 및 장치들은 본 명세서에서 논의된 바와 같은 유연한 서비스 계층 등록을 위한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 스토리지 매체 또는 장치는, 디바이스의 제1 애플리케이션에 의해, 서비스 계층의 제1 서비스에 대한 등록 요청을 포함하는 제1 메시지를 제1 레지스트라 엔티티에 전송하기 위한 수단; 제1 메시지에 응답하는 제2 메시지를 수신하기 위한 수단 - 제2 메시지는 제1 애플리케이션에 대해 제1 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제1 리스트를 포함함 -; 제2 메시지에 응답하여, 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제1 리스트에 대한 제1 레지스트라 엔티티에서의 등록을 확인하는 제3 메시지를 전송하기 위한 수단 -; 제1 애플리케이션에 의해, 서비스 계층의 제2 서비스에 대한 등록 요청을 포함하는 제4 메시지를 제2 레지스트라 엔티티에 전송하기 위한 수단; 제4 메시지에 응답하는 제5 메시지를 수신하기 위한 수단 - 제5 메시지는 제1 애플리케이션에 대해 제2 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제2 리스트를 포함함 -; 및 제5 메시지에 응답하여, 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제2 리스트에 대한 제2 레지스트라 엔티티에서의 등록을 확인하는 제6 메시지를 전송하기 위한 수단 - 제1 애플리케이션은 제1 레지스트라 엔티티 및 제2 레지스트라에 동시에 등록됨 - 을 갖는다. 제2 메시지는 유효 시간을 포함할 수 있고, 유효 시간은 제1 서비스의 유효 시간 기간을 나타낸다. 제2 메시지는 최대 사용량을 포함할 수 있고, 최대 사용량은 제1 애플리케이션에 대한 제1 서비스의 최대 사용 횟수를 나타낸다. 제2 메시지는 상호성을 포함할 수 있고, 상호성은 제1 서비스가 양방향성인지 또는 단방향성인지를 나타낸다. 제2 메시지는 추천 레지스트라를 추가로 포함하고, 추천 레지스트라는 제1 레지스트라 엔티티가 거절된 제3 서비스에 대해 추천하는 제3 레지스트라 엔티티를 나타내고, 제3 서비스는 제1 메시지에서 요청된다. 제2 메시지는 허용 대기 시간을 포함할 수 있고, 허용 대기 시간은 디바이스가 계류 중인 서비스가 허가되기를 대기할 수 있는 시간을 나타낸다. 제2 메시지는 우선순위 순서를 추가로 포함하고, 우선순위 순서는 디바이스의 우선순위를 나타낸다. 방법, 시스템, 컴퓨터 판독 가능 스토리지 매체 또는 장치는 제2 메시지에 기초하여 디스플레이 상에 그래픽을 디스플레이하기 위한 수단을 갖는다. 그래픽은 유효 시간, 최대 사용량, 상호성 또는 추천 레지스트라와 연관된 텍스트를 포함할 수 있다. 이 단락의 모든 조합들(단계들의 제거 또는 추가 포함)은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims

서비스 계층 등록을 위한 디바이스로서,
프로세서; 및
상기 프로세서와 결합된 메모리
를 포함하고,
상기 메모리는 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하고,
상기 동작들은,
상기 디바이스의 제1 애플리케이션에 의해, 서비스 계층의 제1 서비스에 대한 등록 요청을 포함하는 제1 메시지를 제1 레지스트라 엔티티(registrar entity)에 전송하는 동작;
상기 제1 메시지에 응답하는 제2 메시지를 수신하는 동작 - 상기 제2 메시지는 상기 제1 애플리케이션에 대해 상기 제1 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제1 리스트를 포함함 -;
상기 제1 애플리케이션에 의해, 상기 서비스 계층의 제2 서비스에 대한 등록 요청을 포함하는 제4 메시지를 제2 레지스트라 엔티티에 전송하는 동작; 및
상기 제4 메시지에 응답하는 제5 메시지를 수신하는 동작 - 상기 제5 메시지는 상기 제1 애플리케이션에 대해 상기 제2 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제2 리스트를 포함함 -;
을 포함하고,
상기 제1 애플리케이션은 상기 제1 레지스트라 엔티티 및 상기 제2 레지스트라 엔티티에 동시에 등록되는, 디바이스.
제1항에 있어서, 상기 제2 메시지는 유효 시간을 추가로 포함하고, 상기 유효 시간은 상기 제1 서비스의 유효 시간 기간을 나타내는 디바이스.
제1항에 있어서, 상기 제2 메시지는 최대 사용량(maximum usage)을 추가로 포함하고, 상기 최대 사용량은 상기 제1 애플리케이션에 대한 상기 제1 서비스의 최대 사용 횟수를 나타내는 디바이스.
제1항에 있어서, 상기 제2 메시지는 상호성(mutuality)을 추가로 포함하고, 상기 상호성은 상기 제1 서비스가 양방향성인지 또는 단방향성인지를 나타내는 디바이스.
제1항에 있어서, 상기 제2 메시지는 추천 레지스트라를 추가로 포함하고, 상기 추천 레지스트라는 상기 제1 레지스트라 엔티티가 거절된 제3 서비스에 대해 추천하는 제3 레지스트라 엔티티를 나타내고, 상기 제3 서비스는 상기 제1 메시지에서 요청되는 디바이스.
제1항에 있어서, 상기 제2 메시지는 허용 대기 시간을 추가로 포함하고, 상기 허용 대기 시간은 상기 디바이스가 계류 중인 서비스가 허가되기를 대기할 수 있는 시간을 나타내는 디바이스.
제1항에 있어서, 상기 제2 메시지는 우선순위 순서를 추가로 포함하고, 상기 우선순위 순서는 상기 디바이스의 우선순위를 나타내는 디바이스.
서비스 계층 등록을 위한 방법으로서,
디바이스의 제1 애플리케이션에 의해, 서비스 계층의 제1 서비스에 대한 등록 요청을 포함하는 제1 메시지를 제1 레지스트라 엔티티에 전송하는 단계;
상기 제1 메시지에 응답하는 제2 메시지를 수신하는 단계 - 상기 제2 메시지는 상기 제1 애플리케이션에 대해 상기 제1 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제1 리스트를 포함함 -;
상기 제1 애플리케이션에 의해, 상기 서비스 계층의 제2 서비스에 대한 등록 요청을 포함하는 제4 메시지를 제2 레지스트라 엔티티에 전송하는 단계; 및
상기 제4 메시지에 응답하는 제5 메시지를 수신하는 단계 - 상기 제5 메시지는 상기 제1 애플리케이션에 대해 상기 제2 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제2 리스트를 포함함 -;
를 포함하고,
상기 제1 애플리케이션은 상기 제1 레지스트라 엔티티 및 상기 제2 레지스트라 엔티티에 동시에 등록되는 방법.
제8항에 있어서, 상기 제2 메시지는 유효 시간을 추가로 포함하고, 상기 유효 시간은 상기 제1 서비스의 유효 시간 기간을 나타내는 방법.
제8항에 있어서, 상기 제2 메시지는 최대 사용량을 추가로 포함하고, 상기 최대 사용량은 상기 제1 애플리케이션에 대한 상기 제1 서비스의 최대 사용 횟수를 나타내는 방법.
제8항에 있어서, 상기 제2 메시지는 상호성을 추가로 포함하고, 상기 상호성은 상기 제1 서비스가 양방향성인지 또는 단방향성인지를 나타내는 방법.
제8항에 있어서, 상기 제2 메시지는 추천 레지스트라를 추가로 포함하고, 상기 추천 레지스트라는 상기 제1 레지스트라 엔티티가 거절된 제3 서비스에 대해 추천하는 제3 레지스트라 엔티티를 나타내고, 상기 제3 서비스는 상기 제1 메시지에서 요청되는 방법.
제8항에 있어서, 상기 제2 메시지는 허용 대기 시간을 추가로 포함하고, 상기 허용 대기 시간은 상기 디바이스가 계류 중인 서비스가 허가되기를 대기할 수 있는 시간을 나타내는 방법.
제8항에 있어서, 상기 제2 메시지는 우선순위 순서를 추가로 포함하고, 상기 우선순위 순서는 상기 디바이스의 우선순위를 나타내는 방법.
서비스 계층 등록을 위한 시스템으로서,
제1 레지스트리 엔티티(registree entity), 제1 레지스트라 엔티티, 및 제2 레지스트라 엔티티를 포함하고,
상기 제1 레지스트리 엔티티는,
제1 애플리케이션에 의해, 서비스 계층의 제1 서비스에 대한 등록 요청을 포함하는 제1 메시지를 제1 레지스트라 엔티티에 전송하는 단계;
상기 제1 메시지에 응답하는 제2 메시지를 수신하는 단계 - 상기 제2 메시지는 상기 제1 애플리케이션에 대해 상기 제1 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제1 리스트를 포함함 -;
상기 제1 애플리케이션에 의해, 상기 서비스 계층의 제2 서비스에 대한 등록 요청을 포함하는 제4 메시지를 제2 레지스트라 엔티티에 전송하는 단계; 및
상기 제4 메시지에 응답하는 제5 메시지를 수신하는 단계 - 상기 제5 메시지는 상기 제1 애플리케이션에 대해 상기 제2 레지스트라 엔티티에 의해 허가된 하나 이상의 서비스의 하나 이상의 식별자의 제2 리스트를 포함함 -;
를 수행하고,
상기 제1 애플리케이션은 상기 제1 레지스트라 엔티티 및 상기 제2 레지스트라 엔티티에 동시에 등록되는, 시스템.
제15항에 있어서, 상기 제2 메시지는 유효 시간을 추가로 포함하고, 상기 유효 시간은 상기 제1 서비스의 유효 시간 기간을 나타내는 시스템.
제15항에 있어서, 상기 제2 메시지는 최대 사용량을 추가로 포함하고, 상기 최대 사용량은 상기 제1 애플리케이션에 대한 상기 제1 서비스의 최대 사용 횟수를 나타내는 시스템.
제15항에 있어서, 상기 제2 메시지는 상호성을 추가로 포함하고, 상기 상호성은 상기 제1 서비스가 양방향성인지 또는 단방향성인지를 나타내는 시스템.
제15항에 있어서, 상기 제2 메시지는 추천 레지스트라를 추가로 포함하고, 상기 추천 레지스트라는 상기 제1 레지스트라 엔티티가 거절된 제3 서비스에 대해 추천하는 제3 레지스트라 엔티티를 나타내고, 상기 제3 서비스는 상기 제1 메시지에서 요청되는 시스템.