KR20200055106A - 서비스 능력 요건들 및 선호도들에 기반한 서비스 등록 - Google Patents

Abstract

서비스 계층 게이트웨이와 같은 레지스트라 엔티티는 애플리케이션과 같은 새로운 레지스트리 엔티티의 서비스 능력 요건들 또는 선호도들을 획득하고, 레지스트리가 기존의 레지스트리 엔티티들에의 지원의 제공이 영향을 받지 않는 것을 보장하면서 레지스트리 엔티티의 서비스 능력 요건들 또는 선호도들을 충족시키기에 충분한 잔여 서비스 용량들을 갖는 경우에만 레지스트리의 등록을 수락한다. 레지스트라는 요건들 또는 선호도들을 만족시키는 능력들이 부족하면, 그 능력들을 갖는 다른 레지스트라를 식별하기 위해 서버에 접촉할 수 있다. 요건들 또는 선호도에 대한 업데이트들은 임의의 노드, 예컨대 사용자 장비 디바이스 또는 서비스에서 비롯될 수 있다.

Description

서비스 능력 요건들 및 선호도들에 기반한 서비스 등록

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

본 출원은 "서비스 능력 요건들 및 선호도들에 기반한 서비스 등록"(첸(Chen) 등)이라는 명칭으로 2017년 9월 29일자로 출원된 미국 가출원 제62/565,750호의 이익을 주장하며, 그 내용은 그 전체가 본 명세서에 참조로 포함된다.

기기간(M2M), 사물 인터넷(IoT), 및 사물 웹(WoT) 네트워크 배치들은 M2M/IoT/WoT 애플리케이션들 및 서비스들을 호스팅하는 M2M/IoT/WoT 서버들, 게이트웨이들, 및 디바이스들과 같은 노드들 사이의 유니캐스트 및 멀티캐스트 통신들을 이용할 수 있다. 이러한 네트워크 배치들은, 예를 들어, 제약된 네트워크들, 무선 센서 네트워크들, 무선 메시 네트워크들, 모바일 애드혹 네트워크들, 및 무선 센서 및 액추에이터 네트워크들을 포함할 수 있다.

서비스 계층들에 대한 등록은 서비스 능력 요건들 및 선호도들을 추적함으로써 개선될 수 있다. 예를 들어, 게이트웨이와 같은 서비스 계층 레지스트라는 서비스 계층 레지스트리 엔티티의 서비스 능력 선호도를 획득할 수 있다. 레지스트리는, 예를 들어, 사용자 장비 디바이스 또는 사용자 장비 디바이스 상에 존재하는 애플리케이션일 수 있다. 그 다음, 레지스트라는, 적어도 부분적으로, 레지스트라에 이용가능한 서비스 능력 선호도 및 용량들에 기반하여, 서비스 계층 레지스트리 엔티티를 등록할지 여부를 결정할 수 있다.

예를 들어, 엔티티를 등록하기 전에, 레지스트라는 레지스트라가 지원하기를 레지스트리가 바라고 있는 다른 동작들 및 트랜잭션들의 빈도 및 복잡도에 대해 레지스트라에 이용가능한 중앙 처리 대역폭 및 컴퓨터 메모리의 양을 검토하기를 원할 수 있다. 이로부터, 레지스트라는 다른 등록된 엔티티들의 레지스트라의 지원에 대한 잠재적인 영향을 평가하고, 이에 의해 서비스 계층 레지스트리 엔티티를 등록할지 여부를 결정할 수 있다.

레지스터가 요청된 서비스 능력들을 제공할 수 있다고 신뢰되면, 레지스트라는 요청 엔티티를 등록하고, 임의적으로, 서비스 능력 선호도 또는 요건들에 기반하여, 레지스트리를 서비스하기에 충분한 동작 리소스들을 예비할 수 있다.

레지스트라는 요청된 동작 레벨을 지원할 능력들이 부족하다고 느끼는 경우, 등록을 새로운 레지스트라로 전송하도록 부탁하는 요청을 서버에 전송할 수 있다. 이어서, 초기 레지스트라는 요청 레지스트리에 의한 이용을 위해 레지스트라 게이트웨이를 식별하는 응답을 서버로부터 수신할 수 있다.

레지스트라는 임의의 엔티티로부터 서비스 능력 선호도 또는 요건을 포함하는 등록 요청을 수신할 수 있다. 예를 들어, 이 요청은 사용자 장비 또는 서버로부터 올 수 있다. 유사하게, 레지스트라는 업데이트된 서비스 능력 선호도 또는 요건을 포함하는 등록 요청을 임의의 엔티티로부터 수신할 수 있다. 업데이트된 요청들은 새로운 요청들의 처리와 유사한 방식으로 처리될 수 있다.

레지스트라들과 마찬가지로, 레지스트리들 및 서버들은 등록 요청들 및 대안적인 레지스트라들을 찾는 통신들에서 서비스 능력 선호도들 및 요건들을 처리하도록 특별히 적응될 수 있다.

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

첨부 도면들과 관련하여 예로서 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 oneM2M 아키텍처를 예시하는 블록도이다.
도 2는 oneM2M 공통 서비스 기능들을 예시하는 블록도이다.
도 3은 oneM2M 아키텍처에 의해 지원되는 예시적인 구성들을 예시하는 블록도이다.
도 4는 M2M/IoT 시스템의 성능을 저하시키는 서비스 과부하의 예를 예시하는 블록도이다.
도 5는 다른 서비스 계층(SL) 엔티티가 디바이스에 의해 요구되는 지원 레벨을 이행할 수 있을 때 서비스 계층(SL)에 등록하는데 실패한 디바이스들의 예를 예시하는 블록도이다.
도 6은 기존의 레지스트리 엔티티들의 서비스 능력 요건을 보장하기 위해 향상된 서비스 계층 등록을 위한 예시적인 방법의 호 흐름을 도시한다.
도 7 및 도 8은 새로운 레지스트리 엔티티들의 서비스 능력 요건을 이행하기 위해 향상된 서비스 계층 등록을 위한 예시적인 방법의 호 흐름을 도시한다.
도 9는 서비스 능력 요건 프로파일(SCRP)이 레지스트리에 의해 업데이트될 때 서비스 계층 등록 관리를 위한 예시적인 절차의 호 흐름을 도시한다.
도 10은 SCRP가 서버에 의해 업데이트될 때 서비스 계층 등록 관리를 위한 예시적인 절차의 호 흐름을 도시한다.
도 11은 oneM2M 공통 서비스 기능들을 예시하는 블록도이다.
도 12 및 도 13은 서비스 능력 요건을 이행하기 위해 향상된 등록을 위한 예시적인 절차의 호 흐름을 도시한다.
도 14는 애플리케이션들의 서비스 요건 프로파일을 구성 및/또는 표시하기 위해, oneM2M IN-CSE와 같은 M2M/IoT 서버를 위한 예시적인 그래픽 사용자 인터페이스를 도시한다.
도 15는 서비스 용량 정보를 표시하기 위해 M2M/IoT 서버들 및 게이트웨이들을 위한 예시적인 그래픽 사용자 인터페이스를 도시한다.
도 16은 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M, IoT, 또는 WoT 통신 시스템의 시스템도이다.
도 17은 도 16에 예시된 M2M/IoT/WoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 18은 도 16 및 도 17에 예시된 통신 시스템 내에서 이용될 수 있는 M2M/IoT/WoT 디바이스, 게이트웨이, 또는 서버와 같은, 예시적인 통신 네트워크 노드의 시스템도이다.
도 19는 도 16 및 도 17의 통신 시스템의 노드가 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

M2M/IoT 서비스 계층(SL)에서, SL 게이트웨이들, 예컨대 oneM2M에서의 MN-CSE는 일반적으로 낮은 레이턴시 서비스를 제공하기 위해 로컬로 또는 네트워크의 에지에 배치된다. 디바이스는 서비스들을 제공 및/또는 이용하기 위해 SL 게이트웨이에 등록한다. 그러나, 이러한 SL 게이트웨이들은 일반적으로 제한된 서비스 용량들을 갖는다. SL 게이트웨이 상에 호스팅되는 서비스들을 등록하고 이용하는 디바이스들을 적절하게 관리하지 않으면, SL 게이트웨이는 그 디바이스들 모두에게 그 서비스 선호도들 또는 요건들을 충족시키는 방식으로 요구되는 서비스들을 제공할 수 없는 식으로 과부하될 수 있다. 본 개시내용에서, SL 등록들을 관리하기 위한 방법들이 제안되며, 따라서 SL 게이트웨이들은 등록된 디바이스들에 대해 이용가능한 서비스들의 요구된 레벨을 계속 제공할 뿐만 아니라, 서비스 용량이 존재할 때 새로운 디바이스들에 대해 서비스를 제공할 수 있다.

기존의 레지스트리의 지원 레벨이 시스템에 등록하는 새로운 레지스트리에 의해 영향을 받지 않는 향상된 SL 등록 절차가 제안된다. 제안된 절차에서, 레지스트라 엔티티(예컨대, SL 게이트웨이)는 새로운 레지스트리 엔티티(예컨대, 애플리케이션)의 서비스 능력 요건을 획득하고, 레지스트리 엔티티의 서비스 선호도들 또는 요건들을 충족시키고 기존의 레지스트리 엔티티들의 지원 레벨이 영향을 받지 않는 것을 보장하는 충분한 잔여 서비스 용량들을 갖는 경우에만 등록을 수락한다.

새로운 등록 애플리케이션들의 서비스 능력 요건 또는 선호도를 이행하기 위한 향상된 SL 등록 절차가 제안된다. 제안된 절차에서, SL 엔티티들은 새로운 레지스트리 엔티티의 서비스 능력 요건들 및 선호도들을 획득하고, 서비스 능력 요건을 이행할 뿐만 아니라 레지스트리 엔티티의 서비스 선호도를 충족시키는 레지스트라 엔티티를 선택한다.

등록 이후에 레지스트리 엔티티와 연관된 서비스 선호도들 또는 요건들이 업데이트될 때의 향상된 SL 등록 관리 절차들이 제안된다.

<표 1>

용어 "M2M/IoT SL"은 일반적으로 한 세트의 API들(Application Programming Interfaces) 및 기본 네트워킹 인터페이스들을 통해 M2M/IoT 애플리케이션들 및 디바이스들에 대한 부가 가치 서비스들을 지원하는 소프트웨어 미들웨어 계층을 지칭한다.

용어 "M2M/IoT 애플리케이션"은 일반적으로 특정 M2M/IoT 이용 사례(예컨대, e헬스(eHealth), 스마트 에너지, 또는 홈 자동화)를 타겟으로 하는 애플리케이션을 지칭한다.

용어 "레지스트라"는 일반적으로 다른 SL 엔티티가 등록한 SL 엔티티를 지칭한다.

용어 "레지스트리"는 일반적으로 다른 SL 엔티티에 등록하는 SL 엔티티를 지칭한다. 예를 들어, 애플리케이션(예컨대, oneM2M 컨텍스트에서의 AE)은 M2M 서버(예컨대, oneM2M 컨텍스트에서의 CSE)에 등록한다. 애플리케이션은 레지스트리 엔티티이고, 서버는 레지스트라 엔티티이다.

용어 "SL 엔티티"는 일반적으로 M2M/IoT 영역 네트워크 또는 M2M/IoT 애플리케이션 계층 또는 M2M/IoT 서비스 계층 소프트웨어 구성요소들에서의 M2M/IoT 서버, M2M/IoT 게이트웨이 또는 M2M/IoT 디바이스를 지칭한다.

용어 "SL 리소스"는 일반적으로 M2M/IoT SL에서의 고유하게 어드레싱가능한 가상 엔티티를 지칭한다.

용어 "절차"는 일반적으로 특정한 종료들을 달성하기 위해 동작들을 수행하는 방법들을 지칭한다. 용어 "절차"는 M2M 및 IoT 애플리케이션들과 관련하여 용어 "방법"의 특별한 의미들과의 혼란을 피하기 위해 "방법" 대신에 사용된다. 절차들에 대해 설명된 단계들은 종종 임의적이고, 잠재적으로 다양한 방식들 및 다양한 시퀀스들로 수행될 수 있다. 따라서, 본 명세서에서 용어 "절차"는 엄격한 단계들의 세트 및 시퀀스를 지칭하는 것으로 해석되어서는 안 되며, 오히려 다양한 방식들로 적응될 수 있는 결과들을 달성하기 위한 일반적인 방법론으로 해석되어야 한다.

본 명세서에서, 용어 "서비스 능력 요건" 및 "서비스 능력 선호도"는 일반적으로 엔티티의 필요를 서빙하는데 전용될 능력의 양에 대한 엔티티의 요건 또는 선호도를 지칭한다. 서비스 능력 요건들 및 선호도들은 작업에 전용될 메모리 또는 CPU 전력, 또는 수행될 동작들 또는 트랜잭션들의 수 또는 빈도의 면에서 표현될 수 있다. 서비스 능력은 서비스 레벨, 즉 통신 대역폭 또는 품질의 레벨을 포함할 수 있고, 추가적으로 또는 대안적으로, 작업들, 트래픽, 트랜잭션들의 처리 요구를 충족시키거나 다른 기능들을 수행하기 위해 제공자 엔티티 또는 엔티티들의 시스템에 의한 이용가능성을 포함할 수 있다. 용어들 "선호도들" 및 "요건들"은 종종 본 명세서에서 교환가능하게 사용되며, 그 이유는 그 둘의 처리가 매우 유사하기 때문이다. 엔티티의 "선호도들"은 엔티티가 선호하는 서비스의 양태들, 예컨대 24시간 주기에서 1000개의 트랜잭션의 처리, 및 최소 요건들, 예컨대 24시간 주기에서 적어도 200개의 트랜잭션의 처리와 함께, 2MB의 서버 저장소를 포함할 수 있다.

M2M/IoT 서비스 계층(SL)은 M2M/IoT 디바이스들 및 애플리케이션들을 위한 부가 가치 서비스들을 제공하는 것을 특별히 타겟으로 하는 기술이다. 최근, 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크와 함께 배치되도록 M2M/IoT 디바이스들 및 애플리케이션들을 통합하는 것과 연관된 문제들을 해결하기 위해, 수 개의 산업 표준 기관들, 예컨대 oneM2M, ETSI 및 OCF가 M2M/IoT SL들을 개발해 왔다. 예를 들어, oneM2M-TS-0001, oneM2M 기능적 아키텍처, V-3.3.0; ETSI TS 102 690 기기간 통신(M2M/IoT) 기능적 아키텍처, V2.0.13; 및 개방형 접속성 재단(OCF)에 의한 OIC 핵심 사양, v1.1.1을 참조한다.

M2M/IoT SL은 M2M/IoT 지향 능력들의 컬렉션에 대한 액세스를 애플리케이션들 및 디바이스들에게 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속성 관리를 포함한다. 이러한 능력들이 M2M/IoT SL에 의해 지원되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 이용하는 애플리케이션들에게 API들을 통해 이용가능하게 된다.

프로토콜 스택 관점에서, SL들은 전형적으로 애플리케이션 프로토콜 계층 위에 위치하고 그들이 지원하는 애플리케이션들에게 부가 가치 서비스들을 제공한다. 따라서, SL들은 종종 '미들웨어' 서비스들로서 카테고리화된다. 서비스 계층을 지원하는 프로토콜 스택은, 예를 들어, 6개의 계층: (1) 애플리케이션 계층; (2) 서비스 계층(SL); (3) 애플리케이션 프로토콜들(예컨대, HTTP, COAP, 및 MQTT); (4) (TCP 및 UDP와 같은) 전송 프로토콜들; (5) (IPv4/IPv6과 같은) 네트워크 프로토콜들; 및 (6) 액세스 네트워크 프로토콜들(예컨대, 이더넷, 셀룰러, Wi-Fi)을 포함할 수 있다.

oneM2M TS-0001 표준이 M2M/IoT SL을 정의한다. SL의 목적은, 예를 들어, e-헬스, 차량군 관리, 및 스마트 홈들과 같은, 상이한 "수직형(vertical)" M2M/IoT 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평형" 서비스들을 제공하는 것이다. oneM2M SL의 아키텍처는, 도 1에 도시된 바와 같이, 4개의 참조 포인트를 지원하는 공통 서비스 엔티티(CSE)를 정의한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 인터페이싱한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내에서 다른 CSE와 인터페이싱하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서 다른 CSE와 인터페이싱한다. Mcn 참조 포인트는 기본 네트워크 서비스 엔티티(NSE)와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기본 네트워크 서비스들을 CSE들에 제공한다. CSE는, "발견" 및 "데이터 관리 및 저장소"와 같은, "공통 서비스 기능들(CSF들)"이라고 불리는 복수의 논리 기능들을 포함한다. 도 2는 oneM2M에 의해 지원되는 CSF들을 도시한다.

oneM2M 아키텍처는 분산형 아키텍처이고, 애플리케이션 서비스 노드(ASN); 애플리케이션 전용 노드(ADN); 중간 노드(MN); 인프라스트럭처 노드(IN); 및 비-oneM2M 노드(NoDN)와 같은 여러 유형들의 노드들에 걸쳐 분산형 방식으로 M2M/IoT 서비스들을 배치하는 것을 지원한다. ASN은 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함하는 노드이다. 예시적인 물리적 매핑은 M2M/IoT 디바이스 내에 존재하는 ASN이다. ADN은 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. 예시적인 물리적 매핑은 제약된 M2M/IoT 디바이스 내에 존재하는 애플리케이션 전용 노드이다. MN은 CSE를 포함하는 노드이다. MN은 하나 이상의 AE를 추가로 포함할 수 있다. 예시적인 물리적 매핑은 M2M/IoT 게이트웨이 내에 존재하는 MN이다. IN은 CSE를 포함하는 노드이다. IN은 하나 이상의 AE를 추가로 포함할 수 있다. IN의 CSE는 다른 노드 유형들에 적용가능하지 않은 CSE 기능들을 포함할 수 있다. 예시적인 물리적 매핑은 M2M/IoT 서비스 인프라스트럭처 내에 존재하는 IN이다. 비-oneM2M 노드는 oneM2M 엔티티들(예를 들어, AE들이나 CSE들이 아님)을 포함하지 않는 노드이다. 이러한 노드들은, 예를 들어, 관리를 포함하는, 연동 목적들을 위해 oneM2M 시스템에 부착된 디바이스들일 수 있다.

도 3은 oneM2M 시스템 내에서 지원되는 다양한 엔티티들을 상호접속하는 일부 예시적인 구성들을 도시한다.

도 4 및 도 5는 스마트 도시를 위해 서비스 제공자에 의해 배치되는 M2M/IoT 네트워크의 이용 사례들을 도시한다. 이러한 종류의 네트워크들에서, SL 게이트웨이들, 예컨대 oneM2M에서의 MN-CSE들은 일반적으로 낮은 레이턴시 서비스를 제공하기 위해 로컬로 또는 네트워크의 에지에 배치된다. 배치되는 SL 게이트웨이는 통상적으로 제한된 서비스 용량들을 갖는다. 디바이스는 SL 게이트웨이 상에서 이용가능한 하나 이상의 서비스를 제공 및/또는 이용하기 위해 SL 게이트웨이에 등록한다. 초기 배치 후에, SL 게이트웨이에서의 서비스 부하는 동적으로 변경될 수 있다. 구체적으로, SL 게이트웨이에 등록하고 게이트웨이에 의해 제공되는 서비스들을 이용하는 디바이스들의 수는 시간의 경과에 따라 동적으로 변경될 수 있다. 예를 들어, 더 많은 디바이스들이 낮 동안에 서비스들을 등록하고 이들을 이용하며, 더 적은 디바이스들이 밤에 서비스들을 등록하고 이들을 이용한다. 다른 예에서, 더 많은 디바이스들이 소셜 이벤트 동안에 서비스들을 등록하고 이들을 이용한다.

도 4 및 도 5에 도시된 시나리오들에서 적어도 두 가지 문제가 공통으로 보여진다. 첫 번째 문제는 배치되는 게이트웨이가 일반적으로 제한된 서비스 용량들을 갖는다는 것이다. 하위 계층 프로토콜, 예컨대 지그비 프로토콜은 로컬 네트워크에서 1500만개의 "논리" 디바이스를 지원할 수 있다. 그러나, 제한된 서비스 용량들을 갖는 SL 게이트웨이는, 1500만개의 디바이스에 대한 서비스를 제공하는데 있어서 어려움을 가질 수 있다. 현재의 서비스 계층 기술들은 디바이스들(또는 그 소유자들)이 서비스 제공자의 플랫폼에 대한 그 서비스 요건들의 레벨을 지정할 수 있게 하는 능력을 지원하지 않는다. 그 결과, 서비스 제공자의 플랫폼은 디바이스가 일정 기간에 플랫폼에 발행할 수 있는 요청들의 수를 미리 알지 못한다. 그 결과, 서비스 제공자의 플랫폼은 디바이스에 의해 요구되는 서비스를 이행하기 위해 플랫폼 또는 플랫폼의 특정 노드(예컨대, 게이트웨이 또는 서버) 상에서 용량을 예비하기 위한 사전적 조치들을 취할 수 없다. 더욱이, 이것은 또한, 도 4에 도시된 바와 같이, 서비스 제공자의 플랫폼 또는 플랫폼 내의 특정 노드들이 과부하되게 하고, 차례로 디바이스들이 그들이 요구하는 지원 레벨을 수신하지 않게 한다.

두 번째 문제는, 시스템 내에 하나보다 많은 SL 게이트웨이가 있을 때, 도 5에 도시된 바와 같이, 새로운 디바이스가 일반적으로 동일한 로컬 네트워크에 있는 SL 엔티티, 예컨대 게이트웨이 1에 등록하려고 시도한다는 것이다. 그러나, 게이트웨이 1은 제한된 서비스 용량들로 인해 디바이스에 의해 요구되는 지원 레벨을 충족시키지 못할 수 있다. 예를 들어, 디바이스는 요청을 전송한 후 특정 기간 내에 응답이 수신될 것을 요구할 수 있으며, 이는 게이트웨이 1에 의해 제공되는 서비스 용량을 초과할 수 있다. 따라서, 디바이스는 그 디바이스에 의해 요구되는 지원 레벨을 이행할 수 있는 다른 SL 엔티티, 예컨대 게이트웨이 2가 있더라도 SL에 등록하는데 실패한다.

이들 및 다른 문제들을 해결하기 위해, SL 등록들은 SL 게이트웨이들이 등록된 디바이스들에 대해 요구되는 지원 레벨을 제공할 뿐만 아니라, 새로운 디바이스들에 대해 적절한 지원 레벨이 존재하는지에 기반하여 이러한 새로운 디바이스들이 등록하는 것을 허용할지 여부를 결정하는 식으로 향상될 수 있다. 레지스트라 엔티티는 새로운 레지스트리 엔티티의 서비스 능력 요건들 또는 선호도들을 획득할 수 있고, 그것이 기존의 레지스트리 엔티티들의 서비스 선호도들 또는 요건들을 계속 이행하면서 새로운 레지스트리 엔티티의 서비스 선호도들 또는 요건들을 충족시키는 이용가능한 서비스 용량들을 갖는 경우에만 등록을 수락할 수 있다.

복수의 SL 게이트웨이들이 있는 시나리오에서, 예를 들어, 향상된 분산형 등록 절차가 이용될 수 있고, 이에 의해 레지스트리 엔티티는 그 서비스 선호도들 또는 요건들을 이행할 뿐만 아니라, 그 서비스 선호도를 충족시키는 SL 게이트웨이들 중 하나에 등록하도록 허용된다. 등록 후에, 레지스트리 엔티티와 연관된 서비스 능력 선호도들 또는 요건들은 레지스트리 엔티티 또는 다른 당사자에 의해 업데이트될 수 있다.

향상된 SL 등록 절차는 레지스트라 엔티티가 서비스 능력 요건 프로파일(SCRP)로부터 새로운 레지스트리 엔티티의 서비스 능력 요건을 획득하는 것을 포함할 수 있고, 이에 의해 레지스트라 엔티티는 그것이 기존의 레지스트리 엔티티들의 서비스 능력 요건을 여전히 이행하면서 레지스트리 엔티티의 서비스 능력 요건을 충족시키는 적절한 서비스 능력을 갖는 경우에만 등록을 수락한다. SCRP는 레지스트리 또는 그 소유자에 의해 요구되는 각각의 개별 서비스에 기반하여 조직화된 서비스 선호도들 또는 요건들의 리스트를 포함한다. 예를 들어, 각각의 요구되는 서비스에 대해, 서비스 ID, 이름이 포함될 수 있다.

일반 서비스 선호도들 또는 요건들은, 예를 들어, 서비스 요청 레이트 요건들; 서비스 데이터 저장 요건들; 서비스 응답 지연 요건들; 서비스 이용가능성들; 및 적합한 가격을 포함할 수 있다.

서비스 요청 레이트 요건은, 예를 들어, SL 레지스트리 엔티티가 초당 생성할 수 있거나 수신하기를 원하는 요청들의 최소 및/또는 최대 수를 지정하는데 이용될 수 있다. 더욱이, 상이한 유형들의 요청들은 상이한 서비스 레이트 요건을 가질 수 있다. 예를 들어, SL 레지스트리 엔티티는 매분마다 리소스를 생성하도록 요청할 수 있다. 다른 예에서, SL 레지스트리 엔티티는 매초마다 리소스를 검색하도록 요청할 수 있다. 다른 예에서, SL 레지스트리 엔티티는 매초마다 다른 SL 엔티티들로부터 요청을 수신하도록 요청할 수 있다.

서비스 데이터 저장 요건은, 예를 들어, SL 레지스트라에 의해 저장될, SL 레지스트리 엔티티에 의해 요구되는 바이트들의 최소 및/또는 최대 수를 지정하는데 이용될 수 있다.

서비스 응답 지연 요건은, 예를 들어, 서비스를 이용하는 것을 요청할 때 SL 레지스트리 엔티티가 허용할 수 있는 최대 지연을 지정하는데 이용될 수 있다. 예를 들어, 이 지연은 초 단위로 표현될 수 있다. 더욱이, 상이한 유형들의 요청들은 상이한 서비스 응답 지연 요건을 가질 수 있다. 예를 들어, 리소스를 검색하기 위한 응답 지연 요건은 리소스를 생성하기 위한 지연보다 작을 수 있다.

서비스 이용가능성 요건은, 예를 들어, SL 레지스트리 엔티티가 수락할 수 있는 최대 서비스 다운 기간을 지정하는데 이용될 수 있다. 예를 들어, 서비스는 SL 레지스트리 엔티티가 SL 레지스트라 엔티티에 대해 행하는 요청들의 99.5%에 대해 이용가능해야 한다.

적합한 가격 요건은, 예를 들어, 레지스트리 엔티티가 서비스에 대해 지불할 의사가 있는 예산을 지정하는데 이용될 수 있다. 예를 들어, SL 레지스트라 엔티티에 의해 제공되는 서비스들에 액세스하는 비용은 이러한 비용을 초과하는 것이 허용되지 않을 수 있다.

서비스 특정 요건들은, 예를 들어, 액세스 윈도우; 서비스 가입 요건; 통지 요건; 및 디바이스 트리거링 요건과 같은 항목들을 포함할 수 있다.

액세스 윈도우 값은 SL 레지스트리 엔티티가 SL 리소스들에 액세스하는 시간 윈도우, 예컨대 이른 아침(6am-9am), 아침(9am-12pm), 오후(12pm-4pm), 저녁(4pm-7pm), 황금 시간대(7pm-11pm), 오프 시간들(11pm-6am) 등을 지정하는데 이용될 수 있다.

서비스 가입 요건은, 예를 들어, SL 레지스트리 엔티티에서 특정 이벤트들을 모니터링하기 위해 가입할 수 있는 엔티티들의 최소 및/또는 최대 수를 지정하는데 이용될 수 있다.

통지 요건은, 예를 들어, 초당 SL 레지스트리 엔티티에 의해 수신될 수 있는 통지들의 최소 및/또는 최대 수를 지정하는데 이용될 수 있다.

디바이스 트리거링 요건은, 예를 들어, 초당 SL 레지스트리 엔티티에 의해 수신될 수 있는 트리거링 메시지들의 최소 및/또는 최대 수를 지정하는데 이용될 수 있다.

일 예에서, 센서 디바이스는 분당 10 바이트의 감지 데이터를 생성할 수 있고, 게이트웨이가 감지 데이터를 적어도 한 달까지 저장하는 것을 요구할 수 있다. 따라서, 게이트웨이는 이 카테고리의 디바이스, 예컨대 카테고리 1 센서에 대한 서비스 선호도들 또는 요건들을 이행하는데 이용가능한 적어도 500KB 데이터 저장소를 가져야 한다. 다른 예에서, 저품질 비디오 카메라는 초당 100KB의 스트리밍 데이터를 생성할 수 있고, 7일까지 비디오 데이터를 저장하도록 게이트웨이에 요구할 수 있다. 따라서, 게이트웨이는 이 카테고리의 디바이스들, 예컨대 카테고리 2 카메라에 대한 서비스 요건들을 이행하기 위해 적어도 58GB의 저장소를 가져야 한다. 다른 예에서, 고품질 비디오 카메라는 초당 1MB의 스트리밍 데이터를 생성할 수 있고, 게이트웨이가 3일까지 비디오 데이터를 저장할 것을 요구할 수 있다. 따라서, 게이트웨이는 이 카테고리의 디바이스들, 예컨대 카테고리 3 카메라에 대한 서비스 요건들을 이행하기 위해 적어도 254GB의 저장소를 가져야 한다. SCRP는 디바이스들의 상이한 유형들 및 카테고리들에 대해 미리 정의될 수 있거나, 디바이스가 본 개시내용의 범위 밖에 있는 서비스 제공자에게 등록하거나 이에 가입하는 경우에 정의될 수 있다.

게이트웨이와 같은 레지스트라 엔티티는 기존의 서비스 레지스트리들에 의해 소비되는 시스템 리소스들 및 이용가능한 잔여 시스템 리소스들의 양의 기록을 유지할 수 있다. 예를 들어, 레지스트라 엔티티는 기존의 서비스 레지스트리들에 대해 예비되는 데이터 저장소, 및 새로운 레지스트리들에 대해 예비될 수 있는 데이터 저장소의 양을 추정할 수 있다. 유사하게, 레지스트라 엔티티는 분당 처리할 수 있는 서비스 요청들의 최대 레이트 및 분당 수신하는 현재 서비스 요청들의 정도를 추정할 수 있다.

레지스트라 엔티티는 기존의 서비스 레지스트리들에 의해 소비되는 시스템 리소스들에 관한 정보를 저장하기 위해 다양한 필드들을 이용할 수 있다. 예를 들어, 시스템 용량 필드는 SL에 할당된 시스템 리소스들을 표시하는데 이용될 수 있다. 이것은 레지스트리 엔티티들에 서비스를 제공하는데 이용될 수 있는 최대 시스템 리소스들이다. 예를 들어, 메모리, 저장소 및 CPU이다. 잔여 시스템 용량 필드는 새로운 레지스트리 엔티티에 할당될 수 있는 시스템 리소스들을 표시하는데 이용될 수 있다. 예를 들어, 메모리, 저장소 및 CPU이다. 시스템 용량 이용 필드는 기존의 SL 레지스트리 엔티티들에 대해 서비스를 제공하는데 이용되는 시스템 리소스들을 표시하는데 이용될 수 있다. 예를 들어, 메모리, 저장소 및 CPU이다. 서비스 요청 레이트 필드는 레지스트라 엔티티의 현재 서비스 요청 레이트를 표시하는데 이용될 수 있다. 일 예에서, 이것은 초당 수신하는 요청들의 수이다.

유사하게, 서비스 요청 레이트 제한 필드는 레지스트라 엔티티가 처리할 수 있는 최대 서비스 요청 레이트를 표시하는데 이용될 수 있다. 예를 들어, 이것은 초당 수신할 수 있는 요청들의 최대 수이다. 발신 통지 레이트 필드는 레지스트라 엔티티의 현재 발신 서비스 통지 레이트를 표시하는데 이용될 수 있다. 발신 통지 레이트 제한 필드는 레지스트라 엔티티가 처리할 수 있는 최대 발신 서비스 통지 레이트를 표시하는데 이용될 수 있다.

서비스 처리 시간 필드는 레지스트라 엔티티가 서비스 요청을 수신하는 시간과 그 요청에 대한 응답을 전송하는 시간 사이의 평균 시간을 표시하는데 이용될 수 있다. 일 예에서, 레지스트라 엔티티는 평균 서비스 처리 시간을 초 단위로 표시할 수 있다. 서비스 처리 시간 제한 필드는 레지스트라 엔티티가 서비스 요청을 수신하는 시간과 그 요청에 대한 응답을 전송하는 시간 사이의 최소 시간을 표시하는데 이용될 수 있다. 일 예에서, 레지스트라 엔티티는 최소 서비스 처리 시간을 초 단위로 표시할 수 있다.

또한, SL 레지스트리 필드의 최대 수는 레지스트라가 지원할 수 있는 SL 레지스트리의 최대 수를 표시하는데 이용될 수 있다. 이 값은 레지스트리의 유형 및 카테고리에 의존한다. 예를 들어, 레지스트라는 10개의 카테고리 1 카메라 디바이스에 대해 서비스를 제공할 수 있지만, 5개의 카테고리 2 카메라 디바이스에 대해서만 서비스를 제공할 수 있다. 레지스트라가 현재 갖고 있는 SL 레지스트리들의 수를 표시하는데 SL 레지스트리 필드의 수가 이용될 수 있다. 예를 들어, 레지스트라는 현재 5개의 카테고리 1 카메라 디바이스 및 1개의 카테고리 2 카메라 디바이스에 대해 서비스를 제공한다.

물론, 레지스트라 엔티티에 의해 유지되는 서비스 용량 정보는 이러한 예시적인 필드들로 제한되지 않는다.

도 6은 예를 들어 도 4의 예에 도시된 디바이스들에 의해 이용될 수 있는 예시적인 절차의 호 흐름도이다. 위에서 논의된 바와 같이, 도 4는 M2M/IoT 시스템의 성능을 저하시키는 서비스 과부하의 예를 도시하는 블록도이다. 도 4는 SL 레지스트라 엔티티들(게이트웨이들 및 서버) 및 SL 레지스트리 엔티티(디바이스)를 포함한다. 도 4에서, 게이트웨이 1은 M2M/IoT 서버 1에 등록되어 있다. 도 6에서, 새로운 디바이스 1이 게이트웨이 1에 등록된다.

도 6의 단계 1에서, 레지스트리 엔티티, 디바이스 1은 등록 요청 메시지를 레지스트라 엔티티, 게이트웨이 1로 전송한다. 등록 요청 메시지는 SCRP 식별자 및/또는 SCRP에 열거된 것과 같은 임의의 서비스 선호도 또는 요건을 포함할 수 있다. 일 예에서, 디바이스 1은 자신이 카테고리 1 카메라라는 것을 표시하고/하거나 게이트웨이가 적어도 58GB의 데이터 저장소를 갖는 것을 요구할 수 있다. 다른 예에서, 디바이스 1은 자신이 매초마다 100KB의 스트리밍 데이터를 생성한다는 것을 표시할 수 있고, 데이터는 적어도 7일 동안 저장될 것이 요구된다.

다양한 서비스 선호도들 또는 요건들이 등록 요청 메시지에 포함될 수 있다. 예를 들어, 서비스 능력 요건 프로파일 식별자는, 예를 들어, 레지스트리 엔티티가 "카테고리 1 카메라"라는 것을 표시하는 것과 같이 서비스 능력 요건 프로파일 식별자를 표시하는데 이용될 수 있다. 유사하게, 다른 서비스 능력 요건은 SCRP에 열거된 것과 같은 서비스 선호도들 또는 요건들 중 임의의 것을 표시하는데 이용될 수 있다.

단계 2에서, 등록 요청 메시지를 수신한 후에, 게이트웨이 1은 등록 요청을 평가한다. 서비스 선호도들 또는 요건들이 요청에 포함되지 않거나 게이트웨이 1이 SCRP의 특정 요건들을 알지 못하는 경우, 게이트웨이 1은 단계 3에 도시된 바와 같이 M2M/IoT 서버 1로부터 디바이스 1과 연관된 요건 SCRP를 검색하라는 요청을 표시할 수 있다. 게이트웨이 1이 서비스 선호도들 또는 요건들을 알고 있는 경우, 게이트웨이 1은 예를 들어 기존의 서비스 레지스트리들에 의해 소비되는 시스템 리소스들의 그 기록 내의 다양한 필드들을 체크함으로써 총 시스템 용량에 대한 그 잔여 서비스 용량을 체크하고, 새로운 디바이스들에 대해 서비스를 제공하고 기존의 등록된 디바이스들의 서비스 능력 요건을 계속 충족시킬 수 있는지 여부를 결정할 수 있다. 그렇다면, 게이트웨이 1은 디바이스 1에 대한 등록을 생성하고 디바이스의 SCRP로부터의 정보를 이용하여 디바이스의 서비스 요건들을 이행할 시스템 용량을 예비한다. 일 예에서, 디바이스 1이 매분마다 10 바이트의 감지 데이터를 생성하는 카테고리 1 센서이고, 게이트웨이가 최대 한 달 동안 감지 데이터를 저장할 것을 요구하는 경우, 게이트웨이는 이 카테고리의 디바이스들에 대해 서비스를 제공하기 위해 이용가능한 적어도 500KB의 자유로운 저장소를 갖는지를 체크할 수 있다. 등록이 생성된 후에, 게이트웨이 1의 자유로운 저장소는 500KB만큼 감소되는데, 그 이유는 저장 공간이 디바이스 1에 대해 서비스를 제공하도록 예비되기 때문이다. 다른 예에서, 게이트웨이 1이 분당 처리할 수 있는 요청들의 최대 수는 1000이고, 게이트웨이 1의 현재 요청 레이트는 분당 600개의 요청이다. 디바이스 1이 등록 요청에 지정된 바와 같이 분당 500개의 요청을 생성하면, 게이트웨이 1은 디바이스 1로부터의 등록 요청을 거부한다.

단계 3에서, 게이트웨이 1은 서비스 선호도들 또는 요건들이 요청에 포함되지 않거나 또는 게이트웨이 1이 SCRP의 특정 요건들을 알지 못할 때 등록 요청에 표시된 SCRP를 검색하라는 요청을 M2M/IoT 서버 1에 전송한다.

단계 4에서, M2M/IoT 서버 1은 디바이스 1과 연관된 SCRP를 포함하는 게이트웨이 1에 응답을 전송할 준비를 한다. SCRP는 디바이스 1과 연관된 서비스 프로파일들로부터 획득될 수 있다.

단계 5에서, M2M/IoT 서버 1은 디바이스 1과 연관된 SCRP를 포함하는 응답 메시지를 게이트웨이 1에 전송한다.

단계 6에서, 응답 메시지를 수신한 후, 게이트웨이 1은 메시지를 처리하고, 등록 응답 메시지를 디바이스 1에 전송할 준비를 한다. SCRP가 응답에 포함되어 있는 경우, 게이트웨이 1은 단계 2에서 설명된 바와 같이, 그 잔여 서비스 용량을 체크하고, 새로운 디바이스들에 대해 서비스를 제공하고 기존의 등록된 디바이스들의 서비스 능력 요건을 계속 충족시킬 수 있는지 여부를 결정할 수 있다.

단계 7에서, 게이트웨이 1은 등록 응답 메시지를 디바이스 1에 전송한다.

SL 등록 절차는 새로운 레지스트리 엔티티들의 서비스 요건 및 선호도를 이행하도록 추가로 향상될 수 있다. 예를 들어, 이러한 절차에서, SL 엔티티들은 SCRP 또는 서비스 능력 선호도 프로파일(SCPP)로부터 새로운 레지스트리 엔티티의 서비스 능력 요건들 및 선호도를 획득할 수 있고, 서비스 선호도들 또는 요건들을 이행할 뿐만 아니라 레지스트리 엔티티의 서비스 선호도를 충족시키는 레지스트라 엔티티를 선택할 수 있다. SCRP와 유사하게, SCPP는 각각의 개별 레지스트리 또는 그 소유자에 기반하여 조직화된 서비스 선호도의 리스트를 포함한다. 예를 들어, 각각의 서비스 선호도의 경우, 서비스 ID, 이름, 또는 유형, 및 효용 함수 및 서비스 선호도 기준이 포함될 수 있다. 효용 함수는, 예를 들어, 선호도를 측정하기 위한 변수로서 서비스 선호도 기준을 갖는 가중 함수일 수 있다. 서비스 선호도 기준은 예를 들어 서비스 요청 레이트 선호도; 서비스 데이터 저장 선호도; 서비스 응답 지연 선호도; 서비스 이용가능성 선호도; 서비스 가격 선호도; 또는 액세스 윈도우 선호도일 수 있다.

서비스 선호도는 단일 기준일 수 있다. 예를 들어, 레지스트리 엔티티는 가장 강력한 CPU를 갖는 레지스트라 엔티티를 선호한다. 다른 예에서, 레지스트리 엔티티는 더 낮은 가격을 부과하는 레지스트라 엔티티를 선호한다. 서비스 선호도는 또한 복수의 기준의 조합일 수 있다. 예를 들어, 효용 함수는 복수의 기준을 포함하고, 각각의 기준은 이와 연관된 가중 파라미터를 갖는다.

SL 엔티티들(게이트웨이들 및 서버) 및 SL 레지스트리 엔티티(디바이스)를 포함하는 예시적인 향상된 SL 등록 절차가 도 5에 도시되어 있다. 도 5에서, 게이트웨이 1 및 2는 M2M/IoT 서버 1에 등록되었고, 새로운 디바이스 1은 도 7 및 도 8에 도시된 바와 같은 제안된 절차를 이용하여 게이트웨이 1에 등록한다.

도 5의 단계 0에서, 게이트웨이 1 및 게이트웨이 2는 그 서비스 용량 정보를 M2M/IoT 서버 1과 교환한다. 일 예에서, 게이트웨이 1 및 게이트웨이 2는 그 서비스 용량 정보를 M2M/IoT 서버 1에 주기적으로 보고한다. 다른 예에서, M2M/IoT 서버 1은 게이트웨이 1 및 게이트웨이 2로부터 주기적으로 또는 요구에 따라 서비스 용량 정보를 질의할 수 있다.

단계 1에서, 레지스트리 엔티티, 예컨대 디바이스 1은 등록 요청 메시지를 레지스트라 엔티티, 예컨대 게이트웨이 1에 전송한다. 등록 요청 메시지는 SCRP 및/또는 서비스 선호도들 또는 요건들을 포함할 수 있다.

등록 요청 메시지는 또한 SCPP 및/또는 서비스 선호도 정보를 포함할 수 있다. 예를 들어, 서비스 능력 선호도 프로파일 식별자는 서비스 능력 선호도 프로파일 식별자, 예컨대 레지스트리 엔티티가 "카테고리 2 카메라"라는 것을 표시하는데 이용될 수 있다. 서비스 선호도는 SCPP에 열거된 바와 같이 임의의 서비스 능력 선호도를 표시하는데 이용될 수 있다.

단계 2에서, 등록 요청 메시지를 수신한 후에, 게이트웨이 1은 그 메시지를 처리하고, 등록 요청 내의 서비스 능력 요건들 및 서비스 능력 선호도 정보를 포함하는 이 등록 보고 요청을 M2M/IoT 서버 1에 전송할 준비를 한다. 예를 들어, 서비스 선호도들 또는 요건들이 요청에 포함되지 않거나 게이트웨이 1이 SCRP의 특정 요건들을 알지 못한다면, 게이트웨이 1은 M2M/IoT 서버 1로부터 디바이스 1과 연관된 SCRP를 검색하라는 요청을 개시한다. 서비스 선호도들 또는 요건들이 요청에 포함되는 경우, 게이트웨이 1은 그 잔여 서비스 용량을 체크하고, 기존의 등록된 디바이스들의 서비스 선호도들 또는 요건들을 충족시키면서 새로운 디바이스에 대해 서비스를 제공할 수 있는지를 결정할 수 있다. 서비스 선호도들이 요청에 포함되는 경우, 게이트웨이 1은 이 정보를 M2M/IoT 서버에 또한 전달할 수 있다.

단계 3에서, 게이트웨이 1은 이 등록 보고 요청을 M2M/IoT 서버 1에 전송한다.

다양한 필드들이 등록 보고 요청 메시지에 포함될 수 있다. 예를 들어, 레지스트리 정보 필드는 SL 레지스트리 엔티티에 관한 정보, 예컨대 "디바이스 1"의 IP 어드레스를 표시하는데 이용될 수 있다. 등록 의도 필드는 레지스트라 엔티티가 레지스트리 엔티티에 대해 서비스를 제공하고자 하는지를 표시하는데 이용될 수 있다. 예를 들어, 그 결정은, 레지스트라 엔티티가 그 기존의 레지스트리 엔티티들의 서비스 능력 요건을 충족시키면서 새로운 레지스트리 엔티티에 대해 서비스를 제공할 수 있는 경우에는 "수락 의도" 또는 그렇지 않다면 "거부 의도"일 수 있다. 서비스 능력 요건 프로파일 식별자 필드는 레지스트리와 연관된 SCRP 식별자를 표시하는데 이용될 수 있다. 서비스 능력 요건 필드는 등록 요청에서 서비스 능력 요건을 표시하는데 이용될 수 있다. 서비스 능력 선호도 프로파일 식별자 필드는 레지스트리와 연관된 SCPP 식별자를 표시하는데 이용될 수 있다. 서비스 능력 선호도 필드는 등록 요청에서 서비스 능력 선호도를 표시하는데 이용될 수 있다.

단계 4에서, M2M/IoT 서버 1은 요청을 처리하고, SL 식별자를 디바이스 1에 할당하고, 레지스트리 엔티티 ID, 레지스트라 엔티티 ID, 및 SCRP 필드들을 포함하는 응답을 게이트웨이 1에 전송할 준비를 한다. 디바이스 1과 연관된 요청 또는 서비스 등록 프로파일로부터 서비스 능력 요건 및 서비스 선호도를 획득한 후, M2M/IoT 서버 1은 단계 0에서 획득된 서비스 용량 정보에 기반하여 서비스 능력 요건 및 서비스 선호도를 이행하는 SL 게이트웨이를 선택한다. 일 예에서, M2M/IoT 서버 1은 디바이스 1과 연관된 서비스 능력 요건들을 충족시키는 모든 SL 게이트웨이들을 먼저 선택할 수 있고, 이어서 M2M/IoT 서버 1은 디바이스 1과 연관된 서비스 선호도들에 기반하여 이들 중에서 SL 레지스트라로서 하나의 게이트웨이를 선택한다. 예를 들어, SL 레지스터 엔티티의 선호도가 잔여 시스템 용량인 경우, M2M/IoT 서버 1은 최대 잔여 시스템 용량을 갖는 게이트웨이를 선택한다. 게이트웨이 1이 SL 레지스트라로서 선택되는 시나리오에서, M2M/IoT 서버는 단계 5에 도시된 바와 같이 응답 메시지에서 게이트웨이 1의 SL 식별을 표시한다. 다른 게이트웨이, 예컨대 게이트웨이 2가 레지스트라로서 선택되는 시나리오에서, M2M/IoT 서버 1은 레지스트리 엔티티에 대한 등록을 생성하기 위해 위임 등록 요청 메시지를 게이트웨이 2에 전송한다. 위임 등록 요청 메시지는 레지스트리 엔티티 ID, 레지스트리 정보, 및 SCRP 필드들과 같은 정보를 포함한다. 예를 들어, M2M/IoT 서버 1은 디바이스 1과 연관된 SCRP를 포함한다.

이어서, 도 7의 방법이 수행된 후에, 등록 관리가 M2M/IoT 서버에 저장된 SCRP 및 SCPP로 달성될 수 있다. 예를 들어, M2M/IoT 서버 1은 기록을 포함할 수 있으며, 레지스트리 엔티티 ID는 디바이스 1을 지정하고, 레지스트라 엔티티 ID는 게이트웨이 1을 지정하고, SCRP는 카테고리 1 센서이고, SCPP는 또한 카테고리 1 센서이다.

등록 보고 응답 메시지에서, 레지스트리 엔티티 ID 필드는 레지스트리 엔티티, 예컨대 디바이스 1의 SL ID를 표시하는데 이용될 수 있다. 레지스트라 엔티티 ID 필드는 레지스트리 엔티티가 등록되는 레지스트라 엔티티의 SL ID를 표시하는데 이용될 수 있다. 서비스 능력 요건 프로파일 필드는 레지스트리 엔티티와 연관된 서비스 능력 요건 프로파일을 표시하는데 이용될 수 있다.

위임 등록 요청 메시지에서, 레지스트리 엔티티 ID 필드는 레지스트리 엔티티, 예컨대 디바이스 1의 SL ID를 표시하는데 이용될 수 있다. 레지스트리 정보 필드는 디바이스 1의 IP 어드레스와 같은 레지스트리 정보를 표시하는데 이용될 수 있다. 서비스 능력 요건 프로파일 필드는 레지스트리 엔티티와 연관된 서비스 능력 요건 프로파일을 표시하는데 이용될 수 있다.

게이트웨이 1이 SL 레지스트라로서 선택되는 경우, 도 7의 단계들 5 내지 7이 실행된다. 게이트웨이 2가 SL 레지스트라로서 선택되면, 도 8의 단계들 8 내지 12가 실행된다.

도 7의 메시지 5에서, M2M/IoT 서버 1은 예를 들어 레지스트리 엔티티 ID, 레지스트라 엔티티 ID, 및 SCRP 필드들을 포함하는 응답 메시지를 게이트웨이 1에 전송한다. 서버 1은 또한 디바이스 1이 게이트웨이 1에 등록한다는 정보 및 디바이스 1과 연관된 SCRP 및 SCPP를 저장한다.

단계 6에서, 응답 메시지를 수신한 후에, 게이트웨이 1은 디바이스 1에 대한 등록을 생성하고 디바이스 1과 연관된 서비스 능력 요건을 저장한다.

메시지 7에서, 게이트웨이 1은 M2M/IoT 서버 1에 의해 할당된 SL 식별을 포함하는 응답을 디바이스 1에 전송한다.

도 7의 호 흐름은 도 8에서 계속되며, 여기에는 제2 사례가 도시되어 있다. 도 8의 메시지 8에서, M2M/IoT 서버는, 예를 들어 레지스트리 엔티티 ID, 레지스트리 정보, 및 SCRP 필드들을 포함하는 필드들을 포함하는 위임 등록 요청 메시지를 게이트웨이 2에 전송한다.

단계 9에서, 게이트웨이 2는 디바이스 1에 대한 등록을 생성하고 디바이스 1과 연관된 서비스 능력 요건을 저장한다.

단계 10에서, 게이트웨이 2는 등록의 결과를 표시하기 위한 응답을 전송한다. 게이트웨이 2가 등록을 생성하는데 실패하면, 서버 1은 단계 4에서와 같이 다른 게이트웨이를 선택하고 위임 등록을 선택된 게이트웨이에 전송한다.

단계 11에서, 서버 1은 M2M/IoT 서버 1에 의해 할당된 SL 식별 및 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 게이트웨이 1에 전송한다.

단계 12에서, 게이트웨이 1은 M2M/IoT 서버 1에 의해 할당된 SL 식별 및 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 디바이스 1에 전송한다. 디바이스 1은 이 응답을 수신할 때, 추후에 게이트웨이 2와 직접 통신할 수 있다.

대안적으로, 서버 1은 단계 9를 스킵하고, M2M/IoT 서버 1에 의해 할당된 SL 식별 및 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 게이트웨이 1에 전송할 수 있다. 그 후, 게이트웨이 1은 레지스트리 엔티티 ID, 레지스트리 정보, 및 SCRP 필드들을 포함하는 위임 등록 요청 메시지를 게이트웨이 2에 전송하여, 디바이스 1을 대신하여 게이트웨이 2에 대한 등록을 생성할 수 있다. 다른 대안에서, 게이트웨이 1은 M2M/IoT 서버 1에 의해 할당된 SL 식별 및 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 디바이스 1에 전송하고, 이후 디바이스 1은 게이트웨이 2에 대한 등록을 자체 생성하기 위해 새로운 등록 생성 프로세스를 시작할 수 있다.

향상된 SL 등록 관리 절차들은 SCRP가 레지스트리 엔티티 또는 다른 당사자에 의해 업데이트된 후에 이용될 수 있다. 도 9에 도시된 절차는 레지스트리 엔티티가 SCRP를 업데이트하라고 요청하는 시나리오를 기술한다. 도 10에 도시된 절차는 레지스트리 엔티티와 연관된 SCRP가 다른 당사자에 의해 서버에서 업데이트되는 시나리오를 기술하며, 예를 들어 SL 등록 업데이트 절차는 레지스트리 엔티티와 연관된 SL 프로파일을 업데이트할 수 있다. 제안된 절차를 설명하기 위해, 도 6에서의 SL 엔티티들(게이트웨이들 및 서버) 및 애플리케이션 엔티티(디바이스)가 예로서 이용된다. 도 6에서, 게이트웨이 1 및 2는 M2M/IoT 서버 1에 등록되었고, 게이트웨이 1은 도 7 및 도 8에 도시된 바와 같은 제안된 절차를 이용하는 디바이스 1에 대한 레지스트라 엔티티이다.

도 9는 SCRP가 레지스트리에 의해 업데이트될 때 서비스 계층 등록 관리를 위한 예시적인 절차를 도시한다. 도 9의 예에서, 레지스트리 엔티티는 SCRP 13 절차의 업데이트를 요청한다.

단계 1에서, 레지스트리 엔티티, 예컨대 디바이스 1은 SCRP를 업데이트하라는 요청들을 전송하거나 레지스트라 엔티티, 예컨대 게이트웨이 1에 대한 새로운 서비스 선호도들 또는 요건들을 제안한다. 이 요청 메시지는 새로운 SCRP 및/또는 서비스 선호도들 또는 요건들을 포함할 수 있다.

단계 2에서, SCRP 업데이트 요청 메시지를 수신한 후에, 게이트웨이 1은 디바이스 1과 연관된 SCRP를 업데이트한다. 게이트웨이 1은 그 잔여 서비스 용량을 체크하고, 기존의 레지스트리 엔티티들의 서비스 선호도들 또는 요건들을 충족시키면서 디바이스 1에 대한 업데이트된 서비스 요청을 이행할 수 있는지를 결정할 수 있다. 그렇다면, 게이트웨이 1은 디바이스 1에 대해 예비된 서비스 용량을 업데이트하고 서버 1에 저장된 SCRP를 업데이트하라는 요청을 전송한다. 그렇지 않다면, 게이트웨이 1은 새로운 요건들을 이행할 수 없다는 것을 보고하기 위한 요청을 서버 1에 전송하고 SCRP를 업데이트하고 새로운 서비스 선호도들 또는 요건들을 이행할 수 있는 새로운 게이트웨이를 선택하도록 서버 1에 요청한다.

단계 3에서, 게이트웨이 1은 업데이트된 SCRP를 보고하라는 요청을 M2M/IoT 서버 1에 전송한다.

단계 4에서, M2M/IoT 서버 1은 디바이스와 연관된 SCRP를 업데이트한다. 게이트웨이 1이 새로운 게이트웨이를 선택하도록 요청하는 경우, M2M/IoT 서버 1은 도 7의 단계 4와 관련하여 설명된 동일한 방법을 이용하여 새로운 서비스 능력 요건을 이행하는 새로운 레지스트라 엔티티를 선택한다.

단계 5에서, M2M/IoT 서버 1은 새로운 레지스트라, 예컨대 게이트웨이 2의 정보를 포함하는 응답 메시지를 게이트웨이 1에 전송한다. 임의적으로, 서버 1은 게이트웨이 2가 새로운 레지스트라로서 선택된다는 것을 통지하기 위해 게이트웨이 2에 요청 메시지를 전송할 수 있다.

단계 6에서, 응답 메시지를 수신한 후에, 게이트웨이 1은 디바이스 1과 연관된 등록을 전송하라는 요청을 게이트웨이 2에 전송한다. 등록을 어떻게 전송할지에 대한 상세한 절차는 본 개시내용의 범위를 벗어나 있다.

단계 7에서, 게이트웨이 2는 디바이스 1에 대한 등록을 생성하고, 디바이스 1과 연관된 서비스 능력 요건을 저장한다.

단계 8에서, 게이트웨이 2는 등록의 결과를 표시하기 위한 응답을 전송한다.

단계 9에서, 게이트웨이 1은 등록이 성공적으로 게이트웨이 2에 전송되면 그 등록을 제거하고 디바이스 1과 연관된 예비된 리소스들을 해제할 수 있다. 게이트웨이 2가 등록을 생성하는데 실패하면, 게이트웨이 1은 단계 3에서와 같이 다른 게이트웨이를 선택하라고 서버 1에 요청한다.

단계 10에서, 게이트웨이 1은 응답을 디바이스 1에 전송한다. 이 응답은 또한, 서버에 의해 선택되는 경우, 새로운 레지스트라 엔티티, 예컨대 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함한다. 이것이 발생할 때, 디바이스 1은 추후에 게이트웨이 2와 직접 통신할 수 있다.

도 10은 SCRP가 서버에서 업데이트될 때 서비스 계층 등록 관리를 위한 예시적인 절차를 도시한다. 도 10의 예에서, 레지스트리 엔티티와 연관된 SCRP는 다른 당사자에 의해 서버에서 업데이트되며, 예를 들어 SL 등록 업데이트 절차는 레지스트리 엔티티와 연관된 SL 프로파일을 업데이트할 수 있다.

단계 1에서, SCRP가 업데이트된 후에, M2M/IoT 서버 1은 SCRP와 연관된 모든 SL 엔티티들, 예컨대 디바이스 1을 검색하고, 디바이스 1의 레지스트라 엔티티들, 예컨대 게이트웨이 1을 찾는다. 그 다음, 서버 1은 게이트웨이 1의 서비스 용량 정보를 체크하고, 게이트웨이 1이 게이트웨이 1의 기존의 레지스트리 엔티티들의 서비스 능력 요건을 충족시키면서 디바이스 1에 대한 업데이트된 서비스 요청을 이행할 수 있는지를 결정한다. 그렇다면, 서버 1은 게이트웨이 1에 저장된 SCRP를 업데이트하라는 요청을 게이트웨이 1에 전송한다. 그렇지 않다면, 서버 1은 도 7 및 도 8에 도시된 바와 같은 단계 4와 동일한 서비스 용량 정보에 기반하여 서비스 능력 요건 및 서비스 선호도를 이행할 레지스트라 엔티티, 예컨대 게이트웨이 2를 선택한다. 다음으로, 서버 1은 게이트웨이 1이 새로운 서비스 선호도들 또는 요건들을 이행할 수 없다는 것을 표시하라는 요청을 게이트웨이 1에 전송한다. 서버 1은 SCRP를 업데이트하라고 게이트웨이 1에 요청하고, 새로운 서비스 선호도들 또는 요건들을 이행할 수 있는 등록을 게이트웨이 2에 전송한다.

단계 2에서, 게이트웨이 1은 디바이스 1과 연관된 SCRP를 업데이트한다. 게이트웨이 1이 디바이스 1과 연관된 등록을 게이트웨이 2에 전송하도록 지시받는 경우, 단계 3 내지 단계 7이 실행된다.

단계 3에서, 응답 메시지를 수신한 후, 게이트웨이 1은 디바이스 1과 연관된 등록을 전송하라는 요청을 게이트웨이 2에 전송한다. 등록을 어떻게 전송할지에 대한 상세한 절차는 본 개시내용의 범위를 벗어나 있다.

단계 4에서, 게이트웨이 2는 디바이스 1에 대한 등록을 생성하고, 디바이스 1과 연관된 서비스 능력 요건을 저장한다.

단계 5에서, 게이트웨이 2는 등록의 결과를 표시하기 위한 응답을 전송한다.

단계 6에서, 게이트웨이 1은 등록이 성공적으로 게이트웨이 2에 전송되면 그 등록을 제거하고 디바이스 1과 연관된 예비된 리소스들을 해제할 수 있다. 게이트웨이 2가 등록을 생성하는데 실패하면, 게이트웨이 1은 단계 10에서의 응답 메시지에서 다른 게이트웨이를 선택하라고 서버 1에 요청한다. 게이트웨이 1은 그 후 디바이스 1에 통지를 전송한다. 이 통지는 새로운 레지스트라 엔티티, 예컨대 게이트웨이 2의 SL 식별 및/또는 어드레스(예컨대, IP 어드레스)를 포함한다.

단계 7에서, 디바이스 1은 등록 전송을 확인하기 위한 응답을 전송하고, 추후에 게이트웨이 2와 직접 통신할 수 있다.

단계 8에서, 게이트웨이 1은 SCRP 업데이트 및 등록 전송에 관한 요청을 확인하기 위한 응답을 전송한다.

oneM2M은 oneM2M 서비스 계층에 의해 지원되는 능력들을 정의한다. oneM2M 서비스 계층은 능력 서비스 기능(CSF)들의 세트를 포함하는 능력 서비스 엔티티(CSE)로서 인스턴스화된다. 예를 들어, 본 명세서에 제안된 다양한 방법들은 도 11에 도시된 것들과 같은 향상된 등록 CSF의 일부 및/또는 애플리케이션 및 서비스 계층 관리 CSF의 일부로서 구현될 수 있다. CSE들은 등록을 관리하기 위해 Mcc 및 Mcc' 참조 포인트를 통해 통신할 수 있다. 애플리케이션 엔티티(AE)는 등록을 관리하기 위해 Mca 참조 포인트를 통해 통신할 수 있다.

SL 레지스트리 엔티티들의 모니터링 및 관리를 지원하기 위해, 새로운 서비스 용량들, 리소스들, 및 속성들이 본 명세서에서 제안된다. 예를 들어, 이러한 구조들은 oneM2M 리소스 지향 아키텍처에서 이용될 수 있다.

새로운 공통 속성들, 예컨대 serviceRequirement 및 servicePreference는 <AE>, <CSEBase>, <remoteCSE> 및 <m2mServiceSubscriptionProfile>에서 이용하기 위해 제안된다.

serviceRequirement 속성은 레지스트리 또는 그 소유자에 의해 요구되는 각각의 개별 서비스에 기반하여 조직화되는 서비스 선호도들 또는 요건들의 리스트를 포함할 수 있다. 예를 들어, 각각의 요구되는 서비스에 대해, 다음의 정보의 일반 및 특정 서비스 요건들이 포함될 수 있다.

일반 서비스 요건들은, 예를 들어, 서비스 요청 레이트 요건; 서비스 데이터 저장 요건; 서비스 응답 지연 요건; 서비스 이용가능성; 또는 적합한 가격 요건을 포함할 수 있다.

서비스 요청 레이트 요건은, 예를 들어, SL 레지스트리 엔티티가 초당 생성할 수 있거나 수신하기를 원하는 요청들의 최소 및/또는 최대 수를 지정할 수 있다. 더욱이, 상이한 유형들의 요청들은 상이한 서비스 레이트 요건들을 가질 수 있다. 예를 들어, SL 레지스트리 엔티티는 매분마다 리소스를 생성하도록 요청할 수 있다. 다른 예에서, SL 레지스트리 엔티티는 매초마다 리소스를 검색하도록 요청할 수 있다. 다른 예에서, SL 레지스트리 엔티티는 매초마다 다른 SL 엔티티들로부터 요청을 수신하도록 요청할 수 있다.

서비스 데이터 저장 요건은, 예를 들어, SL 레지스트라에 의해 저장될, SL 레지스트리 엔티티에 의해 요구되는 바이트들의 최소 및/또는 최대 수를 지정할 수 있다. 이 필드는 임의적일 수 있다.

서비스 응답 지연 요건은, 예를 들어, 서비스를 이용하는 것을 요청할 때 SL 레지스트리 엔티티가 허용할 수 있는 최대 지연을 지정할 수 있다. 예를 들어, 이 지연은 초 단위로 표현될 수 있다. 더욱이, 상이한 유형들의 요청들은 상이한 서비스 응답 지연 요건들을 가질 수 있다. 예를 들어, 리소스를 검색하기 위한 응답 지연 요건은 리소스를 생성하기 위한 지연보다 작을 수 있다.

서비스 이용가능성 요건은, 예를 들어, SL 레지스트리 엔티티가 수락할 수 있는 최대 서비스 다운 기간을 지정할 수 있다. 예를 들어, 서비스는 SL 레지스트리 엔티티가 SL 레지스트라 엔티티에 대해 행하는 요청들의 99.5%에 대해 이용가능해야 한다.

적합한 가격 요건이 있다. 일 예에서, 이 값은 레지스트리 엔티티가 서비스에 대해 지불할 의사가 있는 예산을 지정한다. 예를 들어, SL 레지스트라 엔티티에 의해 제공되는 서비스들에 액세스하는 비용은 이러한 비용을 초과할 수 없다.

특정 서비스 요건들은, 예를 들어, 액세스 윈도우; 서비스 가입 요건; 통지 요건; 또는 디바이스 트리거 요건을 포함할 수 있다.

액세스 윈도우 요건은, 예를 들어, SL 레지스트리 엔티티가 SL 리소스들에 액세스하는 시간 윈도우(예컨대, 이른 아침(6am-9am), 아침(9am-12pm), 오후(12pm-4pm), 저녁(4pm-7pm), 황금 시간대(7pm-11pm), 오프 시간들(11pm-6am) 등)를 지정할 수 있다.

서비스 가입 요건은, 예를 들어, SL 레지스트리 엔티티에서 특정 이벤트들을 모니터링하기 위해 가입할 수 있는 엔티티들의 최소 및/또는 최대 수를 지정할 수 있다.

통지 요건은, 예를 들어, 초당 SL 레지스트리 엔티티에 의해 수신될 수 있는 통지들의 최소 및/또는 최대 수를 지정할 수 있다.

디바이스 트리거 요건은, 예를 들어, 초당 SL 레지스트리 엔티티에 의해 수신될 수 있는 트리거링 메시지들의 최소 및/또는 최대 수를 지정할 수 있다.

servicePreference 속성은 레지스트리 또는 그 소유자에 의해 요구되는 각각의 개별 서비스에 기반하여 조직화되는 서비스 능력 선호도들의 리스트를 포함할 수 있다. 예를 들어, 각각의 요구되는 서비스에 대해, servicePreference 속성은 서비스 요청 레이트 선호도; 서비스 데이터 저장 선호도; 서비스 응답 지연 선호도; 서비스 이용가능성 선호도; 서비스 가격 선호도; 및 액세스 윈도우 선호도와 같은 서비스 선호도 기준과 함께, 서비스 ID, 이름 또는 유형을 포함할 수 있다.

CSE와 연관된 서비스 용량 정보를 저장하기 위해 <CSEBase> 및 <remoteCSE>에 대해 새로운 리소스, 예컨대 <serviceCapacity>가 이용될 수 있다. <serviceCapacity> 리소스는 다수의 속성을 가질 수 있다. systemCapacity 속성은 SL에 할당된 시스템 리소스들을 표시하는데 이용될 수 있다. 이것은 메모리, 저장소 및 CPU와 같은 CSE에 서비스를 제공하는데 이용될 수 있는 최대 시스템 리소스들이다. residualCapacity 속성은 메모리, 저장소 및 CPU와 같은 기존의 등록된 디바이스들에 의해 이미 고려되지 않은 새로운 디바이스들에 할당될 수 있는 시스템 리소스들을 표시하는데 이용될 수 있다.

systemUtilization 속성은 메모리, 저장소 및 CPU와 같은 기존의 등록된 디바이스들에 대해 서비스를 제공하는데 이용되는 시스템 리소스들을 표시하는데 이용될 수 있다.

serviceRequest Rate 속성은 CSE의 현재 서비스 요청 레이트, 예를 들어, 초당 수신하는 요청들의 수를 표시하는데 이용될 수 있다.

또한, serviceRequestRateLimit 속성은 CSE가 처리할 수 있는 최대 서비스 요청 레이트, 예컨대 초당 수신할 수 있는 요청들의 최대 수를 표시하는데 이용될 수 있다. outgoingRateofNotifications 속성은 CSE의 현재 발신 서비스 통지 레이트를 표시하는데 이용될 수 있다. outgoingRateofNotificationsLimit 속성은 CSE가 처리할 수 있는 최대 발신 서비스 통지 레이트를 표시하는데 이용될 수 있다. serviceProcessingTime 속성은, CSE가 서비스 요청을 수신하는 시간과 그 요청에 대한 응답을 전송하는 시간 사이의 평균 시간을 표시하는데 이용될 수 있다. 일 예에서, CSE는 평균 서비스 처리 시간을 초 단위로 표시할 수 있다.

또한, serviceProcessingTimeLimit 속성은 CSE가 서비스 요청을 수신하는 시간과 그 요청에 대한 응답을 전송하는 시간 사이의 최소 시간을 표시하는데 이용될 수 있다. 일 예에서, CSE는 최소 서비스 처리 시간을 초 단위로 표시할 수 있다. maximumNumberofSLRegistree 속성은 CSE가 지원할 수 있는 디바이스들의 최대 수를 표시하는데 이용될 수 있다. 이 값은 레지스트리들의 유형 및 카테고리에 의존한다. 예를 들어, CSE는 10개의 카테고리 2 카메라 디바이스에 대해 서비스를 제공할 수 있지만, 5개의 카테고리 3 카메라 디바이스에 대해서만 서비스를 제공할 수 있다. CSE에 등록된 디바이스들의 수를 표시하는데 number of SLRegistree 속성이 이용될 수 있다. 예를 들어, CSE는 현재 5개의 카테고리 2 카메라 디바이스 및 1개의 카테고리 3 카메라 디바이스에 대해 서비스를 제공한다.

서비스 요건들을 이행하기 위한 예시적인 등록 절차가 도 12 및 도 13에 도시되어 있다.

도 12를 참조하면, 단계 1에서, 레지스트리 AE는 등록 요청 메시지를 MN-CSE 1에 전송한다. 등록 요청 메시지는 9에 열거된 바와 같은 콘텐츠 파라미터 내의 속성들로서 서비스 요건들 및 선호도들을 포함할 수 있다. 등록 요청 메시지는 서비스 선호도를 포함할 수 있다.

단계 2에서, 등록 요청 메시지를 수신한 후에, MN-CSE 1은 메시지를 처리하고 이 등록을 IN-CSE에 보고하라는 요청을 전송할 준비를 한다. 예를 들어, 서비스 요건들이 요청에 포함되지 않으면, MN-CSE 1은 IN-CSE로부터의 <m2mServiceSubscriptionProfile>로부터 디바이스와 연관된 서비스 요건 프로파일들을 검색하라는 요청을 전송한다. 서비스 요건들이 요청에 포함되는 경우, MN-CSE 1은 그 잔여 서비스 용량을 체크하고, 기존의 레지스트리 엔티티들의 서비스 요건을 충족시키면서 레지스트리 AE에 대해 서비스를 제공할 수 있는지를 결정할 수 있다. 서비스 선호도가 요청에 포함되는 경우, MN-CSE 1은 디바이스와 연관된 서비스 선호도 속성들을 포함하는 요청을 IN-CSE에 전송할 수 있다.

단계 3에서, MN-CSE 1은 이 등록을 보고하라는 요청을 M2M/IoT 서버 1에 전송하고, 이는 단계 2에서 준비된다.

단계 4에서, IN-CSE는 요청을 처리하고, S-AE-ID를 레지스트리 AE에 할당하고, 콘텐츠 파라미터 내의 속성들로서 레지스트라 CSE의 CSE-ID를 포함하는 응답을 MN-CSE 1에 전송할 준비를 한다. 레지스트리 AE와 연관된 <serviceSubscribedNode> 또는 요청으로부터 서비스 요건 및 서비스 선호도를 획득한 후에, IN-CSE는 MN-CSE와 연관된 <serviceCapacity>에 기반하여 서비스 요건 및 서비스 선호도를 이행하는 MN-CSE를 선택한다. 레지스트라 CSE를 선택하기 위한 IN-CSE의 상세한 알고리즘은 본 개시내용의 범위를 벗어난다. 일 예에서, IN-CSE는 먼저 레지스트리 AE와 연관된 서비스 선호도들 또는 요건들을 충족시키는 모든 MN-CSE들을 선택할 수 있고, 이어서 IN-CSE는 레지스트리 AE와 연관된 서비스 선호도들에 기반하여 하나의 CSE를 레지스트라 CSE로서 선택한다. 예를 들어, 레지스트리 AE의 선호도들이 데이터 처리 용량이면, IN-CSE는 최대 데이터 처리 용량을 갖는 게이트웨이를 선택한다. MN-CSE 1이 레지스트라 CSE로서 선택되는 시나리오에서, IN-CSE는 단계 5에서와 같이 응답 메시지에서 MN-CSE 1의 CSE-ID를 표시한다. 다른 CSE, 예컨대 MN-CSE 2가 레지스트라 CSE로서 선택되는 시나리오에서, IN-CSE는 단계 8에서와 같이 레지스트리 AE에 대한 등록을 생성하기 위해 위임 등록 요청을 MN-CSE 2에 전송한다. 위임 등록 요청 메시지는 콘텐츠 파라미터 내의 속성들로서 레지스트리 엔티티 ID, 레지스트리 정보, 및 SCRP 필드들과 같은 정보를 포함한다. 예를 들어, IN-CSE는 AE-ID, PoA(Point of Access) 및 레지스트리 AE와 연관된 서비스 등록 프로파일들로부터 획득하는 서비스 요건 프로파일을 포함한다.

MN-CSE 1이 IN-CSE로서 선택되는 경우, 단계 5 내지 단계 7이 실행된다.

단계 5에서, IN-CSE는 레지스트리 엔티티 ID, 레지스트라 엔티티 ID, 및 SCRP 필드들을 포함하는 응답 메시지를 MN-CSE 1에 전송한다.

단계 6에서, 응답 메시지를 수신한 후에, MN-CSE 1은 AE 1에 대한 등록을 생성하고 AE 1과 연관된 서비스 요건을 저장한다. 구체적으로, MN-CSE 1은 응답 메시지 내의 콘텐츠 파라미터에서 제공된 AE-ID 및 서비스 요건들을 이용하여 <AE> 리소스를 생성한다.

단계 7에서, MN-CSE 1은 IN-CSE에 의해 할당된 S-AE-ID를 포함하는 응답을 AE 1에 전송한다.

MN-CSE 2가 IN-CSE로서 선택되는 경우, 단계 8 내지 단계 12가 실행된다.

도 12의 절차는 도 13에서 계속된다. 도 13을 참조하면, 단계 8에서, IN-CSE는 레지스트리 엔티티 ID, 레지스트리 정보, 및 SCRP 필드들을 포함하는 위임 등록 요청 메시지를 (NOTIFY 요청을 통해) MN-CSE 2에 전송한다. 구체적으로, 이 요청은 AE-ID, PoA 및 콘텐츠 파라미터 내의 속성들로서 AE와 연관된 서비스 요건들을 포함한다.

단계 9에서, MN-CSE 2는 AE 1에 대한 등록을 생성하고 AE 1과 연관된 서비스 요건을 저장한다. 구체적으로, MN-CSE 2는 AE-ID, PoA 및 위임 등록 요청 메시지에서 제공되는 서비스 요건들을 이용하여 <AE> 리소스를 생성한다.

단계 10에서, MN-CSE 2는 등록 생성의 결과를 표시하기 위한 응답을 전송한다. MN-CSE 2가 등록을 생성하는데 실패한 경우, IN-CSE는 단계 4에서 설명된 바와 같이 다른 게이트웨이들을 선택하고, 위임 등록을 선택된 CSE에 전송한다.

단계 11에서, IN-CSE는 콘텐츠 파라미터 내의 속성들로서, IN-CSE에 의해 할당된 S-AE-ID 및 레지스트라 엔티티, 예컨대 MN-CSE 2의 CSE-ID 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 MN-CSE 1에 전송한다.

단계 12에서, MN-CSE 1은 콘텐츠 파라미터 내의 속성들로서, IN-CSE에 의해 할당된 S-AE-ID 및 레지스트라 엔티티, 예컨대 MN-CSE 2의 CSE-ID 및/또는 어드레스(예컨대, IP 어드레스)를 포함하는 응답을 AE 1에 전송한다. AE 1은 응답을 수신할 때, 추후에 MN-CSE 2와 직접 통신할 수 있다.

도 14는 예를 들어, AE들 또는 CSE들의 서비스 요건 프로파일을 구성 및/또는 표시하기 위해, oneM2M IN-CSE와 같은 M2M/IoT 서버 상에서 이용하기 위한 예시적인 사용자 인터페이스를 도시한다. 도 15는 서비스 제공자에 등록된 CSE들의 서비스 용량 정보를 표시하기 위한 사용자 인터페이스의 예를 도시한다.

도 16은 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 구성요소 또는 노드는 물론 IoT/WoT 서비스 계층 등일 수 있다. 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 19 중 임의의 것에 도시된 클라이언트, 프록시, 또는 서버 디바이스들 중 임의의 것은, 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 17에 도시된 것들과 같은, 통신 시스템의 노드를 포함할 수 있다.

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

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

도 16에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 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 애플리케이션(20)으로부터 수신될 수 있다. M2M 디바이스들(18) 및 M2M 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예컨대, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카들, 스마트 계측기들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 조명들, 서모스탯들, 가전기기들, 차고 문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 콘센트들을 포함하지만, 이들로 제한되지는 않는다.

도 17을 참조하면, 필드 도메인에서의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이들(14), 및 M2M 디바이스들(18) 및 통신 네트워크(12)에게 서비스들을 제공한다. M2M 서비스 계층(22)이 원하는 바에 따라 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들(14), M2M 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 것을 잘 알 것이다. M2M 서비스 계층(22)은, 서버들, 컴퓨터들, 디바이스들 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 디바이스들(18), M2M 게이트웨이들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은, 예를 들어 웹 서버로서, 셀룰러 코어 네트워크, 클라우드 등에서 다양한 방식들로 구현될 수 있다.

도시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인 내의 M2M 애플리케이션(20') 및 기본 통신 네트워크(12)에게 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인 내의 M2M 게이트웨이들(14) 및 M2M 디바이스들(18)에게 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들 및 M2M 디바이스들과 통신할 수 있다는 것이 이해될 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의해 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은, 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/저장소 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.

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

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

일반적으로, 도 17에 도시된 서비스 계층들(22 및 22') 등의 서비스 계층은, 애플리케이션 프로그래밍 인터페이스들(API들) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양하고 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(여기서 디바이스 SCL(DSCL)이라고 지칭됨), 게이트웨이(여기서 게이트웨이 SCL(GSCL)이라고 지칭됨), 및/또는 네트워크 노드(여기서 네트워크 SCL(NSCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처도 정의하였다. 그 아키텍처에서, 서비스 계층, 및 이것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 SCS에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함한, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 구성요소의 인스턴스는 아래에 설명되는 도 18 또는 도 19에 도시되는 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

게다가, 본 명세서에서 설명되는 방법들 및 기능들은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 18은 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 17에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드로서 동작할 수 있는, 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 19에 도시된 클라이언트들, 서버들, 또는 프록시들 중 하나와 같은 네트워크의 노드의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 18에 도시된 바와 같이, 노드(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 위성 위치확인 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 또한 트랜시버(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 노드(30)는, 실시예와 일관되면서 전술된 요소들의 임의의 하위조합을 포함할 수 있다는 것을 이해할 것이다. 이 노드는 예를 들어 도 6 내지 도 10 및 도 12 내지 도 13을 참조하여 또는 청구항에서 설명된 방법들과 관련하여 서비스 능력 요건들 및 선호도들을 통신하고 관리하기 위한 프로세스들을 구현하는 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로들(ASIC들), 필드 프로그래머블 게이트 어레이(FPGA) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 머신 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 요청된 기능들을 수행하기 위해 노드의 메모리(예를 들어, 메모리(44) 및/또는 메모리(46))에 저장되는 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예컨대, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한 예를 들어 액세스 계층 및/또는 애플리케이션 계층 등에서의 인증, 보안 키 일치, 및/또는 암호화 동작들 등의 보안 동작들을 수행할 수 있다.

도 18에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 트랜시버(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)가 접속되는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서에서 예를 들어 도 6 내지 도 10 및 도 12 내지 도 13과 관련하여 서비스 능력 요건들 및 선호도들을 통신하고 관리하도록 본 명세서에서 또는 청구항에서 설명된 방법들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 18이 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.

전송/수신 요소(36)는, M2M 서버들, 게이트웨이들, 디바이스 등을 포함한 다른 노드들에 신호들을 전송하거나 이들로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 실시예에서, 전송/수신 요소(36)는 RF 신호들을 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는 다양한 네트워크들 및 무선 인터페이스들(air interfaces), 예컨대 WLAN, WPAN, 셀룰러 등을 지원할 수 있다. 실시예에서, 전송/수신 요소(36)는, 예를 들어 IR, UV, 또는 가시광 신호들을 전송 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 전송/수신 요소(36)는 RF 신호 및 광 신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것을 이해할 것이다.

또한, 전송/수신 요소(36)가 도 18에 단일 요소로서 도시되지만, 노드(30)는 임의의 수의 전송/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로는, 노드(30)는 MIMO 기술을 이용할 수 있다. 따라서, 실시예에서, 노드(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 요소들(36)(예컨대, 복수의 안테나들)을 포함할 수 있다.

트랜시버(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고, 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, 노드(30)는 다중 모드 능력들을 가질 수 있다. 그러므로, 트랜시버(34)는 노드(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 복수의 RAT들을 통해 통신하게 하는 복수의 트랜시버들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터의 정보에 액세스하고 이에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 전술한 바와 같이, 그 메모리에 세션 컨텍스트를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 이에 데이터를 저장할 수 있다. 프로세서(32)는 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 이미지들 또는 색상들을 제어하여 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하거나 또는 사용자로부터 입력을 획득하거나 또는 노드의 세션 마이그레이션 또는 공유 능력들 또는 설정들에 관한 정보를 사용자에게 표시하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 보여줄 수 있다.

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

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

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

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

도 19는 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 17에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드로서 동작할 수 있는, 도 1, 도 3 내지 도 10, 도 12, 도 13, 및 도 16 내지 도 19에 도시된 클라이언트들, 서버들, 또는 프록시들과 같은 네트워크의 하나 이상의 노드를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다.

컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능한 명령어들에 의해 제어될 수 있으며, 컴퓨터 판독가능한 명령어들은 소프트웨어의 형태로 어느 곳에나 있을 수 있거나, 어떤 수단에 의해서든 이러한 소프트웨어가 저장되거나 액세스된다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업하게 하기 위해, 중앙 처리 유닛(CPU)(91)과 같은, 프로세서 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서로 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개인 임의적인 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 세션 자격증명들을 수신하거나 세션 자격증명들을 기반으로 인증하는 것과 같이, E2E M2M 서비스 계층 세션들에 대해 개시되는 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

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

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

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

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

또한, 컴퓨팅 시스템(90)은 도 1 내지 도 4의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하여, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.

Claims (20)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
   상기 장치는 그 통신 회로를 통해 네트워크에 접속되고, 상기 장치는 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금 동작들을 수행하게 하는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 동작들은,
   a. 서비스 능력 선호도를 획득하는 것 - 상기 서비스 능력 선호도는 서비스 계층 레지스트리 엔티티에 관련됨 -;
   b. 레지스트라에 이용가능한 상기 서비스 능력 선호도 및 용량들에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록하는 방법을 결정하는 것;
   c. 상기 서비스 계층 레지스트리 엔티티를 등록하는 것; 및
   d. 상기 서비스 능력 선호도에 기반하여 서비스 능력을 예비하는 것
   을 포함하는, 장치.
2. 제1항에 있어서,
   상기 명령어들은 또한 상기 장치로 하여금,
   a. 상기 서비스 계층 레지스트리 엔티티로부터 상기 서비스 능력 선호도를 수신하는 것; 및
   b. 하나 이상의 다른 등록된 엔티티의 지원에 대한 잠재적 영향에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록할지 여부를 결정하는 것
   을 포함하는 동작들을 수행하게 하는, 장치.
3. 제2항에 있어서,
   상기 서비스 능력 선호도는 컴퓨터 메모리의 양, 중앙 처리 유닛 전력의 대역폭, 또는 수행될 동작들의 빈도를 포함하는, 장치.
4. 제3항에 있어서,
   상기 서비스 계층 레지스트리 엔티티는 새로운 레지스트리인, 장치.
5. 제3항에 있어서,
   상기 서비스 계층 레지스트리 엔티티는 기존의 레지스트리인, 장치.
6. 제5항에 있어서,
   상기 서비스 능력 선호도는 업데이트된 선호도인, 장치.
7. 제3항에 있어서,
   상기 명령어들은 또한 상기 장치로 하여금,
   a. 상기 레지스트라에 이용가능한 상기 서비스 능력 선호도 및 용량들에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록하지 않기로 결정하는 것;
   b. 서버에, 새로운 레지스트라 게이트웨이에 등록을 전송하라는 요청을 전송하는 것; 및
   c. 상기 서버로부터, 응답을 수신하는 것 - 상기 응답은 상기 새로운 레지스트라 게이트웨이를 식별함 -
   을 포함하는 동작들을 수행하게 하는, 장치.
8. 제7항에 있어서,
   상기 명령어들은 또한 상기 장치로 하여금, 상기 응답에 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록하라는 요청을 상기 새로운 레지스트라 게이트웨이에 전송하는 것을 포함하는 동작들을 수행하게 하는, 장치.
9. 제4항에 있어서,
   상기 명령어들은 또한 상기 장치로 하여금,
   a. 서버로부터 상기 서비스 능력 선호도를 수신하는 것; 및
   b. 하나 이상의 다른 등록된 엔티티의 지원에 대한 잠재적 영향에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록할지 여부를 결정하는 것을 포함하는 동작들을 수행하게 하는, 장치.
10. 제9항에 있어서,
    상기 명령어들은 또한 상기 장치로 하여금,
    a. 상기 레지스트라에 이용가능한 상기 서비스 능력 선호도 및 용량들에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티를 등록하지 않기로 결정하는 것;
    b. 상기 서버에, 새로운 레지스트라 게이트웨이에 등록을 전송하라는 요청을 전송하는 것; 및
    c. 상기 서버로부터, 응답을 수신하는 것 - 상기 응답은 상기 새로운 레지스트라 게이트웨이를 식별함 -
    을 포함하는 동작들을 수행하게 하는, 장치.
11. 제1항에 있어서,
    a. 상기 서비스 능력 선호도는 서비스 능력 요건을 포함하고;
    b. 상기 명령어들은 또한 상기 장치로 하여금, 상기 서비스 능력 요건에 적어도 부분적으로 기반하여, 상기 서비스 계층 레지스트리 엔티티의 등록을 거절하도록 결정하게 하는, 장치.
12. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
    상기 장치는 그 통신 회로를 통해 네트워크에 접속되고, 상기 장치는 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금 동작들을 수행하게 하는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 동작들은,
    a. 제1 서비스 계층 레지스트라로부터, 레지스트리 엔티티에 관련된 서비스 능력 선호도, 및 제2 서비스 계층 레지스트라의 식별에 대한 요청을 포함하는 메시지를 수신하는 것;
    b. 상기 제1 서비스 계층 레지스트라에, 상기 제2 서비스 계층 레지스트라의 식별을 전송하는 것
    을 포함하는, 장치.
13. 제12항에 있어서,
    상기 명령어들은 또한 상기 장치로 하여금,
    a. 상기 제2 서비스 계층 레지스트라에, 요청을 전송하는 것 - 상기 요청은 상기 서비스 능력 선호도를 포함함 -; 및
    b. 상기 제2 서비스 계층 레지스트라로부터, 상기 요청에 대한 긍정 응답을 수신하는 것
    을 포함하는 동작들을 수행하게 하는, 장치.
14. 제12항에 있어서,
    상기 명령어들은 또한 상기 장치로 하여금, 제2 서비스 계층 레지스트라로의 변경의 통지를 상기 제1 서비스 계층 레지스트라로부터 수신하는 것을 포함하는 동작들을 수행하게 하는, 장치.
15. 제12항에 있어서,
    상기 서비스 능력 선호도는 서비스 능력 요건을 포함하는, 장치.
16. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
    상기 장치는 그 통신 회로를 통해 네트워크에 접속되고, 상기 장치는 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금 동작들을 수행하게 하는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 동작들은,
    a. 제1 서비스 계층 레지스트라에, 서비스 능력 선호도를 전송하는 것 - 상기 서비스 능력 선호도는 레지스트리 엔티티에 관련되고, 상기 레지스트리 엔티티는 상기 장치 상에 존재함 -; 및
    b. 상기 제1 서비스 계층 레지스트라로부터, 등록의 확인을 수신하는 것
    을 포함하는, 장치.
17. 제16항에 있어서,
    상기 서비스 능력 선호도는 컴퓨터 메모리의 양, 중앙 처리 유닛 전력의 대역폭, 또는 수행될 동작들의 빈도를 포함하는, 장치.
18. 제17항에 있어서,
    상기 명령어들은 또한 상기 장치로 하여금, 서비스 계층 레지스트리 엔티티로부터 상기 서비스 능력 선호도에 대한 업데이트를 상기 제1 서비스 계층 레지스트라에 전송하는 것을 포함하는 동작들을 수행하게 하는, 장치.
19. 제18항에 있어서,
    상기 명령어들은 또한 상기 장치로 하여금, 제2 서비스 계층 레지스트라로의 변경의 통지를 상기 제1 서비스 계층 레지스트라로부터 수신하는 것을 포함하는 동작들을 수행하게 하는, 장치.
20. 제16항에 있어서,
    상기 서비스 능력 선호도는 서비스 능력 요건을 포함하는, 장치.

Images