KR101723322B1

KR101723322B1 - 기기간 서비스 계층과 전송 네트워크 간 통신

Info

Publication number: KR101723322B1
Application number: KR1020157022750A
Authority: KR
Inventors: 라지 발라
Original assignee: 제트티이 (유에스에이) 인코포레이티드
Priority date: 2013-01-24
Filing date: 2014-01-24
Publication date: 2017-04-18
Also published as: KR20150110715A; WO2014117039A1; JP6453242B2; CN105052179A; JP6695832B2; EP2949136A1; US20150373124A1; CN105052179B; EP2949136A4; EP2949136B1; US10574760B2; JP2016513381A; JP2018014720A

Abstract

기기간(M2M) 통신을 용이하게 하기 위한 기술들은 하나 이상의 소정의 M2M 어플리케이션 프로그래밍 인터페이스(API) 프로파일들을 구현하는 M2M 시스템을 제공하는 것, 상기 M2M 시스템을 위한 네트워크 인터페이스를 제공하는 것, 상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신하는 것, 및 상기 구현된 하나 이상의 소정의 M2M API 프로파일들에 관한 정보로 응답하는 것을 포함한다.

Description

기기간 서비스 계층과 전송 네트워크 간 통신{COMMUNICATION BETWEEN MACHINE-TO-MACHINE SERVICE LAYERS AND TRANSPORT NETWORK}

이 특허 문서는 2013년 1월 24일 출원된 U.S. 가출원 번호 61/756,397 및 2013년 2월 14일에 출원된 U.S. 가출원 번호 61/764,953 에 대해 우선권을 주장한다. 상기 특허 출원들의 전 내용이 본원에서 참조로 원용된다.

이 문서는 기기간 (M2M) 통신에 관련된다.

M2M 통신은 명시적으로 사용자에 의해 트리거되지 않는, 두 상이한 디바이스들 간 통신을 포함한다. 디바이스들은 유선 또는 무선 연결을 사용하여 M2M 통신을 수행할 수 있다. 상기 통신은 정보를 수집하거나 다른 기계의 대응 어플리케이션으로 보내기 위해 기계 중 하나에 상주하는 어플리케이션에 의해 일반적으로 개시된다. 오늘날 M2M 통신 기술은 전형적인 M2M 솔루션 구현에서 프로토콜 스택의 상이한 계층들의 수직 통합(vertical integration)에서 직면한 과제들때문에 이 기술이 제공하는 모든 혜택을 얻을 수 없다.

본 발명은 기기간(M2M) 통신을 용이하게 하기 위한 방법, 기기간(M2M) 통신을 용이하게 하기 위한 장치 및 기기간(M2M) 통신을 용이하게 하기 위한 시스템을 제공하기 위한 것이다.

본 문서는 다른 것들 중에서, M2M 디바이스들 간 유비쿼터스 통신을 용이하게 하기 위한 기술들을 설명한다. 상호 운용성을 촉진하기 위해, 어플리케이션 프로그래밍 인터페이스(API) 프로파일들이 정의된다. 상기 API 프로파일들은 디바이스가 ON 또는 OFF 인지 여부를 발견하는 것 같은 공통 작업들, 및 특정 변수들을 쿼리(query)할 수 있는 것(예를 들어, 현재 배터리 전력이나 온도 판독, 등) 같은 특수한 작업들을 포함한다.

일 측면에서, M2M 통신을 용이하게 하기 위한 방법들, 시스템들 및 장치는 하나 이상의 소정의 기기간(M2M) 어플리케이션 프로그래밍 인터페이스(API) 프로파일들을 구현하는 M2M 시스템을 제공하는 것, 상기 M2M 시스템을 위한 네트워크 인터페이스를 제공하는 것, 상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신하는 것과 구현된 하나 이상의 소정의 M2M API 프로파일들에 관한 정보로 응답하는 것을 포함한다.

이들 및 다른 측면들, 그리고 그들의 구현 및 변경은 도면, 상세한 설명 및 청구범위에 기재되어 있다.

본 발명은 M2M 서비스 스택을 개시하고, 여기서 상이한 "계층들(layers)"은 M2M 에코시스템에서 상이한 회사들(players)의 특성을 나타낸다. 상기 서비스 스택 및 관련된 프레임워크는 M2M 서비스 스택에서 상이한 계층들(layers)에 의해 제공되는 능력들(capabilities)을 통합하기 위한 "글루(glue)"의 본질을 제안한다. 상기 M2M 서비스 스택의 M2M 서비스 계층 컴포넌트들을 가지는 전송 네트워크 계층을 통합하기 위한 솔루션들을 개발하는 접근법 또한 개시된다.

도 1은 예시 무선 네트워크 아키텍처를 도시한다.
도 2는 무선 네트워크에서 작동가능한 무선 디바이스(radio device)의 블록 다이어그램이다.
도 3은 e2e M2M 서비스들의 계층적 뷰(layered view)의 예를 도시한다.
도 4a, 4b, 4c 및 4d는 M2M 서비스 스택들(stacks)의 예를 도시한다.
도 5는 M2M SDOs에 의해 지원되는 인터페이스와 APIs를 도시한다.
도 6은 M2M 통신을 용이하게 하는 프로세스의 흐름도 표현이다.
도 7은 M2M 시스템의 일부의 블록 다이어그램 표현을 도시한다.
다양한 도면에서 동일한 도면 부호는 동일한 요소들을 나타낸다.

oneM2M, ETSI TC M2M, TIA TR-50 등 (M2M SDOs) 같은 단체들에 의해 개발된 서비스 계층 사양들은 광범위한 시장-중심(수직적) 단체들에 의한 M2M 솔루션들의 효율적 디플로이먼트(deployment)를 지원해야 한다. 서비스 계층에 초점을 맞춘, 이러한 단체들은 엔드-투-엔드 서비스(end-to-end services)의 전송 네트워크-독립적 뷰를 취하고 있다. 그러나, 그들은 그들의 서비스 계층 사양들이 다양한 종류의 전송 네트워크들과 인터페이스를 위해 효율적으로 사용될 수 있는지 확인해야 한다. 이러한 전송 네트워크들은 3GPP, 3GPP2, IEEE, IETF 및 BBF에 의해 정의되는 무선 및 유선 네트워크를 포함하나 이에 제한되지 않는다.

전송 네트워크 사양들을 개발하는 단체들은 M2M 서비스를 지원하기 위해 그들의 네트워크 강화(enhancement) 및 최적화를 제공해 오고 있다. 3GPP 및 3GPP2 같은, 일부 전송 네트워크 표준 개발 의회들은 M2M 서비스들을 지원하기 위한 아키텍처 강화(enhancement)를 정의하는 한편 서비스 계층 독립적 접근법을 취하고 있다. 3GPP와 3GPP2는 또한 다른 비즈니스 모델들을 가능하게 하기 위해 M2M 디플로이먼트(deployment) 시나리오 세트를 정의하고 있다. 이러한 디플로이먼트(deployment) 시나리오들은 제공되는 서비스들의 유형들로부터 및 M2M 에코시스템(ehcosystem)에서 다른 "회사들(players)" 간의 상호작용의 본질로부터 진화해왔다.

E2E M2M 에코시스템에서 다른 "회사들(players)"의 역할을 인식하는 동안, M2M SDOs(standards developing organizations)가 이러한 M2M 산업 회사들(players)이 개발 플랫폼에 독립적이고 상호작용하는 회사들(players)에 독립적인, 그들의 시스템들과 서비스들을 원활하게 통합할 수 있게 하는 능력(capability)을 제공하는 것이 중요하다. 이러한 회사들(players)이 그들의 상호작용하는 동료들(peers)의 기술적 뉘앙스(nuance) 및 프로토콜 상세정보를 알 필요는 없다. 또한 M2M 에코시스템에서 이러한 회사들(players)이 관련 산업 표준을 향해 그들의 시스템을 이전할 때 그들의 기존 디플로이먼트(deployment)들을 지속적으로 지원할 수 있도록 하는 것도 가능할 것이다.

본 문서는 M2M 서비스 스택을 개시하고, 여기서 상이한 "계층들(layers)"은 M2M 에코시스템에서 상이한 회사들(players)의 특성을 나타낸다. 상기 서비스 스택 및 관련된 프레임워크는 M2M 서비스 스택에서 상이한 계층들(layers)에 의해 제공되는 능력들(capabilities)을 통합하기 위한 "글루(glue)"의 본질을 제안한다. 상기 M2M 서비스 스택의 M2M 서비스 계층 컴포넌트들과 전송 네트워크 계층을 통합하기 위한 솔루션들을 개발하는 접근법 또한 개시된다.

도 1은 무선 통신 네트워크 또는 시스템의 예를 도시한다. 이러한 무선 통신 네트워크는 하나 이상의 기지국(BSs)(105, 107) 및 하나 이상의 무선 디바이스(110)를 포함할 수 있다. 기지국(105, 107)은 하향 링크(DL) 신호로 알려진, 순방향 링크(FL) 상의 신호를 하나 이상의 무선 디바이스(110)로 전송할 수 있다. 무선 디바이스(110)는 상향 링크(UL) 신호로 알려진, 역방향 링크(RL) 상의 신호를 하나 이상의 기지국(105, 107)으로 전송할 수 있다. 무선 통신 시스템은 하나 이상의 기지국(105, 107)을 제어하기 위해 하나 이상의 코어 네트워크(125)를 포함할 수 있다. 하나 이상의 기지국들은 무선 액세스 네트워크(radio access network)를 형성한다. 기지국은, 무선 디바이스에 대해 무선 액세스를 제공하는 그 본질에 기인하여, 홀로 또는 하나 이상의 다른 기지국들과 결합하여, 액세스 포인트(AP), 액세스 네트워크(AN) 또는 eNodeB로 언급될 수 있다. 본 기법들 및 시스템들을 구현할 수 있는 무선 통신 시스템의 예들은 다른 것들 중에서, CDMA2000 1x, High Rate Packet Data (HRPD), Long-Term Evolution (LTE), Universal Terrestrial Radio Access Network (UTRAN), 및 Worldwide Interoperability for Microwave Access (WiMAX) 같은 코드 분할 다중 접속(CDMA)에 기반한 무선 통신 시스템들을 포함한다.

도 2는 무선 디바이스, 기지국 또는 다른 무선 통신 모듈들을 구현하기 위한 무선 송수신국(radio transceiver station)의 예를 도시한다. 무선국들(radio stations)의 다양한 예들은 도 1의 기지국들 및 무선 디바이스들을 포함한다. 기지국 또는 무선 디바이스 같은 무선국(205)은 본 문서에 제시된 기법들 중 하나 이상의 것과 같은 방법들을 구현하는 마이크로프로세서 같은 프로세서 전자기기(210)들을 포함할 수 있다. 무선국(205)은 하나 이상의 안테나들(220) 같은 하나 이상의 통신 인터페이스들을 통해 무선 신호들을 전송 및/또는 수신하기 위한 송수신 전자기기(215)를 포함할 수 있다. 무선국(205)은 데이터를 전송 또는 수신하기 위한 다른 통신 인터페이스들을 포함할 수 있다. 일부 실시예들에서, 무선국(205)은 유선 네트워크로 통신하기 위해 하나 이상의 유선 통신 인터페이스들을 포함할 수 있다. 무선국(205)은 데이터 및/또는 명령들 같은 정보를 저장하도록 구성된 하나 이상의 메모리들(225)을 포함할 수 있다. 일부 실시예들에서, 프로세서 전자기기(210)는 메모리(225)와 송수신 전자기기(215)의 적어도 일부를 포함할 수 있다.

일부 실시예들에서, 무선국들(205)은 CDMA 또는 GSM 기반 무선 인터페이스에 기초하여 서로 통신할 수 있다. 일부 실시예들에서, 무선국들(205)은 직교 주파수 분할 다중 접속(OFDMA)을 포함할 수 있는 직교 주파수-분할 다중화(OFDM) 무선 인터페이스에 기초하여 서로 통신할 수 있다. 일부 실시예들에서, 무선국들(205)은 CDMA2000 1x, HRPD, WiMAX, GSM, LTE, 및 Universal Mobile Telecommunications System (UMTS) 같은 하나 이상의 무선 기술들을 사용하여 통신할 수 있다.

일부 실시예들에서, 무선국(205)은 부가적으로 802.11 (a/b/g/n) 인터페이스 같은 로컬 영역 네트워크 연결로 구성될 수 있다. 이러한 인터페이스의 유용성은 로컬 영역 연결을 통해 인터넷에 상기 무선국(205)을 통신적으로 연결하는 것을 가능하게 할 수 있다. 예를 들어, 사용자는 케이블 모뎀 네트워크 또는 DSL 네트워크 같은 고정 브로드밴드 네트워크를 통해 무선 로컬 영역 네트워크 연결을 경유하여 서비스에 연결함으로써 사용자 단말(UE)을 통해 서비스에 접속할 수 있다.

엔드-투-엔드(end-to-end) 서비스들의 계층적 뷰

도 3은 다른 회사들(players)을 바라보는 예는 M2M 에코시스템이 엔드-투-엔드(e2e) M2M 서비스의 "계층적 뷰"가 될 것이라는 것을 도시한다. 이러한 계층적 e2e 뷰는 일반적으로 M2M 디바이스들/게이트웨이들 및 M2M 어플리케이션 서버(AS) 에 의해 호스팅되는 M2M 어플리케이션들을 포함한다. 이러한 계층적 뷰에서, M2M 서비스 플랫폼(M2M SP)은 M2M 데이터 관리 및/또는 M2M 서비스 인에이블먼트 능력들(Enablement capabilities)을 제공한다. 기본 전송 네트워크는 어플리케이션 서버(들) 및 M2M 디바이스들/게이트웨이들에 의해 호스팅되는 M2M 어플리케이션들 간 데이터 흐름에 대한 전송 및 통신 서비스들을 제공한다.

M2M 서비스들의 이러한 계층적 뷰로, M2M 어플리케이션 서버, M2M 디바이스/게이트웨이, M2M 서비스 플랫폼 및 전송 네트워크는 e2e M2M 서비스 스택에서 상이한 "계층들"로 간주될 수 있다. 이러한 "계층들"의 각각은 또한 상이한 비즈니스 엔티티들(business entities)의 표현으로 간주될 수 있다. 각 계층은 능력들(capabilities)의 세트, 그리고 다른 계층들과 통신하기 위한 인터페이스들 및/또는 API들의 세트를 제공한다. 상기 "계층들"은 상이한 서비스들 및 상이한 비즈니스 모델들을 지원하기 위해 다르게 스택(stack)될 수 있다. 이러한 "계층들"의 상이한 스태킹(stacking)은 상이한 디플로이먼트(deployment) 시나리오들, 및 통신하는 계층들 간 상이한 유형의 인터페이스들 및/또는 API들을 지원하기 위한 관련된 요구사항들을 나타낸다.

도 4a는 "직접" 통신 모델을 나타내는 M2M 서비스들 스택(stack)의 예이고, 여기서 AS는 어떤 M2M 서비스 플랫폼도 이용하지 않고 직접 전송 네트워크와 통신한다. AS에서 어플리케이션들은 상기 전송 네트워크에 의해 제공되는 서비스들을 이용한다. 상기 전송 네트워크에 의해 제공되는 서비스들은 상기 전송 네트워크에 특정한 API들의 세트를 통해 추상화될(abstracted) 수 있다. 이러한 API들은 상기 전송 네트워크 사업자에 의해 정의되고 어플리케이션 개발자들에게 유용하게 될 수 있거나, 일부 단체, 예를 들어, M2M SDOs, OMA 등에 의해 특정된 오픈 API들의 세트 및/또는 네트워크-사업자-정의 및 오픈 API들의 조합일 수 있다.

도 4b, 도 4c 및 도 4d는 "간접" 통신 모델의 예들이고, 여기서 AS의 어플리케이션들은 M2M 서비스 플랫폼에 의해 제공되는 서비스들을 통해 전송 네트워크와 통신한다. 능력들(capabilities) 및 서비스들이 제공되는 이러한 M2M 서비스 플랫폼은 어플리케이션 데이터 관리, 디바이스 관리, 연결 관리 등과 같은 서비스들을 포함한다. 이 예시 도면처럼, 이러한 능력들(capabilities) 및 서비스들은 데이터 관리 부계층(Data Management sub-layer) 및 서비스 인에이블먼트 부계층(Services Enablement sub-layer) 각각에 의해 노출되는 인터페이스들 및/또는 API들의 세트를 통해 추상화될(abstracted) 수 있다. M2M SDOs 및 그 파트너 단체는 이러한 인터페이스들 및/또는 API들을 식별하고 구체화하는데 앞장설 것으로 예견된다.

"하이브리드" 통신 모델 또한 도 4a 내지 4d에 도시되진 않았지만, 지원될 수 있다. "하이브리드" 통신 모델에서, AS는 사용자 데이터 트래픽의 전송을 위한 전송 네트워크와 통신하기 위해 "직접" 모델을 사용한다. 동시에, 상기 AS는 또한 디바이스 관리, 디바이스 트리거링 등에 관련된 서비스들 같은, 부가가치 서비스들을 위해 M2M 서비스 플랫폼에 의해 제공되는 서비스들을 이용한다. "직접" 및 "간접" 통신 모델들에 유사한, "하이브리드" 통신 모델들에서 상이한 "계층들" 간 통신은 동등 통신 계층들(peer communicating layers)에 의해 지원되는 인터페이스들 및/또는 API들을 이용한다.

M2M SDOs의 역할

서비스 계층에 초점을 맞춘, M2M SDOs가 엔드-투-엔드(end-to-end) 서비스들의 전송-네트워크-독립 뷰(transport-network-independent view)를 취하는 것이 예상된다. 그러나, M2M SDOs는 그들의 서비스 계층 사양들이 다른 유형의 전송 네트워크들과의 인터페이스를 위해 효과적으로 사용될 수 있는지를 확인해야 한다.

이러한 전송-네트워크-독립 접근법으로, M2M 서비스들 스택(stack)은 능력들(capabilities)의 두 독립적 세트: 전송 네트워크 계층에 의해 제공되는 능력들(capabilities) 및 M2M 서비스 계층에 의해 제공되는 능력들(capabilities)로 크게 설명될 수 있다. 이러한 두 계층들이 효과적인 통신을 위해 동등 개체(peer entity)에 의한 사용을 위한 그 능력들(capabilities) 및 자원들을 노출하는 인터페이스들 및/또는 API들의 세트를 제공하는 것이 예견된다.

이러한 두 "계층들"에 의해 제공되는 능력들(capabilities)의 세트는 동일한 비즈니스 엔티티에 의해 또는 상이한 비즈니스 엔티티들에 의해 제공될 수 있다. 한 비즈니스 엔티티가 두 능력들(capabilities)의 세트 모두를 제공하는 시나리오에서, 연관된 인터페이스들 및/또는 API들이 이러한 비즈니스 엔티티 내부에 있을 수 있다. 이러한 시나리오는 여기서 논의 대상이 아니다. 이러한 두 계층들에 의해 제공되는 능력들(capabilities)이 상이한 비즈니스 엔티티들에 의해 제공될 때, 효과적으로 통신하기 위해 동등 계층들(peer layers)에 의해 사용될 수 있는 인터페이스들 및/또는 API들의 표준화된 세트를 정의하는 것이 바람직하다.

M2M 서비스들 계층에 의해 제공되는 능력들(capabilities)(예를 들어, M2M 서비스 플랫폼)이 전송-네트워크-독립적일지라도, M2M 서비스들 계층은 기본 전송 네트워크의 뉘앙스(nuance) 및 프로토콜의 지식이 있어야만 한다. 그러므로, M2M 서비스 계층 및 전송 네트워크 계층 간 인터페이스들 및/또는 API들의 세트는 기본 전송 네트워크에 의해 지원되는 기술에 특정해야 한다. 논의 목적을 위해 그리고 즉석 참조(ready reference) 편의성을 위해; 전송 네트워크 특정 인터페이스들 및/또는 API들의 각 세트가 여기서 전송 네트워크 특정 컨버전스 계층(Transport Network specific Convergence Layer)으로 언급된다.

컨버전스 계층

전송 네트워크 특정 컨버전스 계층(Transport Network specific Convergence Layer)의 정의는 인터페이스들의 세트 및/또는 API들의 세트를 명시하는 것을 포함한다. 이러한 전송 네트워크 특정 컨버전스 계층(Transport Network specific Convergence Layer)은 연관된 전송 네트워크 기술을 명시하는 데 책임 있는 단체 및 M2M SDOs 간 공동 노력을 통해 정의되어야 한다. 예를 들어, 3GPP 및 3GPP2는 Tsp 및 M2Msp를 M2M 서비스 플랫폼과 각각의 3GPP 및 3GPP2 네트워크들 간 인터페이스로 식별해 왔다. 이러한 인터페이스들(Tsp와 M2Msp)은 M2M SDOs와 3GPP/3GPP2 간 공동 노력을 통해 정의되어야 하고, 본 문서의 논의 주제는 아니다. 여기서 논의 주제는 M2M SDOs가 M2M 서비스 플랫폼(M2M 서비스 계층으로 추상화됨(abstracted))과 기본 전송 네트워크들 간에 사용될 수 있는 API들의 세트를 정의하는 데 취하는 접근법이다.

오픈 네트워크 API들

M2M SDOs는 광범위한 시장 중심(수직적) 단체들에 의한 M2M 솔루션들의 효율적 디플로이먼트(deployment)를 지원하기 위해 능력들(capabilities)의 세트를 제공할 수 있다. 독점적 API들의 확산 및 그에 따른 업계 분열을 피하기 위해, M2M 어플리케이션들 및 M2M 서비스 플랫폼의 개발자들이 이러한 네트워크(들)의 기술 뉘앙스(technological nuances) 및 프로토콜의 지식을 가질 필요없이, 표준화된 방법으로 기본 전송 네트워크들의 능력들(capabilities)의 공지의 세트에 액세스하는 것이 바람직하다.

예를 들면, OMA(오픈 모바일 얼라이언스) 네트워크 API들은 전송 네트워크들이 오픈 및 프로그램가능한 방식으로 그들의 네트워크에서 능력들(capabilities) 및 자원들의 요약 뷰(abstract view)를 제공하는 것을 허용한다. 이것은 개발 플랫폼에 독립적이고 OMA API들을 지원하는 서비스 제공자들 및 사업자들에 독립적인 - 컨텐츠 및 어플리케이션을 생성하기 위해 필요로 되는 개발 비용 및 시간을 감소시킨다.

유사하게, GSMA OneAPI 프로젝트는 Parlay X Web API들을 단순화하기 위해 OMA와 협력하고 있고, RESTful 바인딩들을 제공하여 그리고 더 간단한 JSON/XML 응답들의 선택을 제공하여 그들을 개선하고 있다. 결과로 초래되는 GSMA OneAPI 프로파일들은 웹 어플리케이션들을 통해 모바일 네트워크 능력들(capabilities) 및 자원들에 관한 정보를 어플리케이션 개발자들에게 노출하는 API들의 세트이다. 예를 들어, 어플리케이션 개발자들은 모바일 네트워크에서 디바이스의 위치를 얻고 음성 통화를 개시하기 위해 단일 웹 서비스 요청(single Web Service request)을 호출할 수 있다. 이러한 어플리케이션들은 네트워크 유형들 및 네트워크 기술들 전반에 걸쳐 포팅될(ported) 수 있다. 어플리케이션 개발을 단순화하는 것에 부가하여, OneAPI 프로파일의 일부 다른 혜택들은 다음을 포함한다:

OneAPI 프로파일들은 그것들이 이미 제공하고 있는 API들을 폐기하기 위해 네트워크 사업자들을 필요로 하지 않는다. OneAPI들은 다른 API 서비스들과 공존할 수 있다.

OneAPI 프로파일들은 네트워크 사업자들이 서로의 API 요청을 서비스하기 위한, 예를 들어 또다른 사업자를 위한 로밍 방문자에 대한 위치 요청을 이행하기 위한 기초를 제공한다.

OneAPI 프로파일들로 사업자들은 개발자들이 사용할 API들을 디자인하는데 그들 자신의 시간과 노력을 투자할 필요가 없다.

OneAPI 프로파일들의 일반 공급업체 구현들로부터의 혜택으로 획득된 규모의 경제가 존재한다.

여기서의 제안은 M2M SDOs가 OneAPI 이니셔티브(initiative) 유사한 접근법을 취하는 것이다. M2M 어플리케이션 개발자들 및 M2M 서비스 플랫폼의 개발자들에 의해 사용될 수 있는 M2M API 프로파일들의 세트를 개발하기 위해 M2M SDOs는 파트너들 및 단체들(예를 들어, OMA)과 작업한다. M2M API 프로파일들의 이러한 세트는 개발자들이 M2M 어플리케이션들 및 컨텐츠를 생성하기 위한 감소된 노력 및 시간을 초래할 것이다. 이러한 어플리케이션들은 또한 다른 시장-중심(수직적) 단체들 및 전송 네트워크 사업자들 전반에 걸쳐 이식가능(portable)할 것이다. M2M API 프로파일들의 이러한 세트는 또한 전송 네트워크 사업자들이 다수의 장비 공급업체들로부터의 M2M 플랫폼과 그들의 네트워크들을 완벽하게 통합할 수 있게 한다.

즉, M2M SDOs가 GSMA OneAPI 이니셔티브(initiative)에 의해 수행될 작업으로부터 본을 받아 OneAPI 프로파일을 검토할 수 있음이 예견된다. GSMA OneAPI 프로파일들은 M2M 서비스들을 위해 요구되는 전송 네트워크 능력들(capabilities)을 추상화하는(abstract) M2M 특정 API 프로파일들을 정의함으로써 증강될 수 있다. 섹션 에러! 참조 원본을 찾을 수 없습니다. 는 GSMA OneAPI 프로파일들의 상태(status) 및 스냅샷을 나타낸다. OneAPI 프로파일들의 유용한 세트에 의해 제공되는 능력들(capabilities), 및 M2M SDO 특정된 서비스 계층의 포괄적 구현을 위해 필요로 되는 능력들(capabilities) 간 갭(gaps)의 분석이 집중이 필요한 분야가 될 것이다. 이러한 식별된 집중 분야들 및 갭들(gaps)은 M2M API 프로파일들의 보다 완전한 스위트(suite)를 개발하여 독립적으로 M2M SDOs에 의해 및/또는 파트너들 및 산업 조직들(예를 들어, OMA, BBF 등)과 공동 노력을 통해 해결될 수 있다.

부록(Annex) - GSMA OneAPI 프로파일들의 상태(status)

GSMA OneAPI 프로젝트는 Parlay X Web API들을 단순화하기 위해 OMA와 협력해 왔고 대응하는 RESTful 바인딩들을 제공함으로써 그들을 개선해 왔다. 지불, 위치 및 메시징과 같은 네트워크 능력들(capabilities)에 초점을 맞춘 OneAPI들의 버전 1로 시작하여; GSMA OneAPI의 버전 2는 디바이스 능력들(capabilities), 베어러 식별(Bearer Identification) 및 음성/통화 서비스를 결정하기 위한 능력들(capabilities)이 추가했다. 버전 3은 QoS, 화상 통화, 아이덴티티(Identity), 펨토셀(Femtocell) 지원 등과 같은, 더 향상된 능력들(capabilities)을 고려하고 있다.

다음은 OneAPI 프로파일들 내 API들의 목록이다. API들 중 임의의 것을 위한 실제 모바일 사업자의 지원은 사업자 네트워크 능력(capability)에 종속적이다.

지불:

사용자에게 청구

사용자에게 환불

이후 청구에 대한 자금 비축

비축 증가

비축에 대한 청구

비축 해제

SMS:

SMS 전송

SMS 전달 상태 쿼리(query)

SMS 전달 상태의 서브스크립션(subscription) 시작

SMS 전달 상태의 서브스크립션(subscription) 중단

SMS 수신

SMS 수신의 서브스크립션(subscription) 시작

SMS 수신의 서브스크립션(subscription) 중단

MMS:

MMS 전송

MMS 전달 상태 쿼리(query)

MMS 전달 상태의 서브스크립션(subscription) 시작

MMS 전달 상태의 서브스크립션(subscription) 중단

MMS 메시지 목록 수신

전체 MMS 메시지(컨텐츠) 수신

MMS 수신의 서브스크립션(subscription) 시작

MMS 수신의 서브스크립션(subscription) 중단

위치:

모바일 단말(들)의 위치 쿼리(query)

음성 통화 제어:

둘 이상 가입자 간 통화 생성

상기 통화로부터 참가자들을 추가하거나 제거

상기 참가자들에 관한 정보 획득

기존 통화에 관한 정보 획득

통화 종료

통화 내에서 특정 이벤트 통지에 동의

통지 기준 보기

통지 수신 중지

오디오 메시지(audio message) 재생

오디오 메시지(audio message) 중단

오디오 메시지(audio message) 상태(누구에게 재생되었는지) 획득

참가자를 호출하고 그들의 키패드 상호작용을 수집하기 위해 오디오 파일(audio file) 재생

오디오 메시지(audio message)/키패드 상호작용 종료

오디오 메시지(audio message)에 참가자로부터 임의의 키패드 상호작용 통지받음

키패드 통지 수신 중단

데이터 연결 프로파일:

단말의 연결 종류(3G, GPRS 등) 요청

상기 단말의 로밍 상태 검색

디바이스 능력(capability):

모바일 계정의 디바이스 능력(capability) 획득

OMA 문서 "OMA-TS-REST_NetAPI_OneAPIProfile-V3_0-20120327-C"는 RESTful 네트워크 APIs의 OneAPI 프로파일의 후보 버전 3.0 이다. 상기 언급한 바와 같이, GSMA OneAPI 프로젝트는 서드 파티(3rd party) 어플리케이션들을 위해 운영 고려사항들 및 를 해결해 왔고 RESTful 네트워크 API들의 OneAPI 프로파일을 추상화(abstract)하기 위해 OMA RESTful 네트워크 API들과 Parlay X의 서브세트를 사용해 오고 있다.

RESTful 네트워크 API들의 OneAPI 프로파일의 버전 3.0은 다음 API들의 서브세트들을 정의한다:

짧은 메세징 V 1.0에 대한 RESTful 네트워크 API

메세징 V 1.0에 대한 RESTful 네트워크 API

단말 위치 V 1.0에 대한 RESTful 네트워크 API

지불 V 1.0에 대한 RESTful 네트워크 API

디바이스 능력들(capabilities) V 1.0에 대한 RESTful 네트워크 API

단말 상태 V 1.0에 대한 RESTful 네트워크 API

제삼자 호(Third Party Call) V 1.0, 호 알림(Call Notification) V 1.0 및 음성 호(audio call) V 1.0에 대한 RESTful 네트워크 API (공동으로 통화 제어 API들이라 함)

도 6은 기기간(M2M) 통신을 용이하게 하기 위한 프로세스(300)의 흐름도 표현이다.

302 에서, M2M 시스템이 제공된다. 상기 M2M 시스템은 예를 들어, 유선 또는 무선 네트워크에서 디플로이먼트(deployment) 및 사용을 위해 개발자, 제조업자, 서비스 공급자 또는 네트워크 사업자에 의해 제공될 수 있다. 상기 M2M 시스템은 하나 이상의 소정의 기기간(M2M) 어플리케이션 프로그래밍 인터페이스(API)프로파일들을 구현한다. 이러한 프로파일들은 예를 들어, 부록 A(Appendix A)에 기술된 바와 같은, 이니셔티브들(initiatives) 또는 산업 표준 중 하나 이상에 의해 정의될 수 있다.

304에서, M2M 시스템의 공급자는 상기 M2M 시스템을 위한 네트워크 인터페이스를 제공할 수 있다. 상기 네트워크 인터페이스는 상기 네트워크 인터페이스를 디자인, 제조, 설치하여 제공된다. 부가적으로, 상기 네트워크 인터페이스는 M2M 시스템이 주어진 네트워크에서 작동하도록 허가하여 제공될 수 있다(예를 들어, 구성, 가입, 서비스 계약등).

306에서, 상기 M2M 시스템은 상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신할 수 있다. 상기 쿼리(query)는 예를 들어, 상기 네트워크 내 또다른 M2M 시스템으로부터 수신된다.

308에서, 상기 M2M 시스템은 구현된 하나 이상 소정의 M2M API 프로파일들에 관한 정보로 응답한다.

일부 실시예에서, 상기 하나 이상의 M2M API 프로파일들이 상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜에 무관한 제1 모듈 및 상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜을 사용하여 신호들을 전송하고 수신하는 제2 모듈을 포함하도록 구현된다.

일부 실시예에서, 상기 프로세스(300)는 관리 정보 데이터베이스(MIB)에, 상기 하나 이상의 소정의 M2M API 프로파일들 중 하나에 대응하는 정보를 저장하는 것을 더 포함한다. 상기 MIB는 로컬 메모리에 개별적으로 주소 지정 가능한 메모리 위치들(addressable memory locations)의 그룹 형태로 구현될 수 있다. 상기 MIB 항목들은 트랜잭션 내역(transaction history), 하드웨어 식별 파라미터들, 경보 조건들(alarm conditions), 에러들이 마스크 가능한지(maskable) 여부, 슬립 모드 동작(sleep mode behavior)(예를 들어, 얼마나 자주 그리고 얼마나 오랫동안 디바이스가 슬립일 수 있는지) 등과 같은 항목들을 포함한다.

일부 실시예에서, 상기 하나 이상의 소정의 M2M API 프로파일들에서 특정된 규칙들에 기반하여, 상기 정보는 또 다른 시스템에 의해 판독가능/기록가능할 수 있다.

도 7은 기기간(M2M) 통신을 용이하게 하기 위한 장치(400)의 블록 다이어그램 표현이다. 모듈(402)은 하나 이상의 소정의 기기간(M2M) 어플리케이션 프로그래밍 인터페이스(API) 프로파일들을 구현하는 M2M 시스템을 제공하기 위한 것이다. 모듈(404)은 M2M 시스템을 위한 네트워크 인터페이스를 제공하기 위한 것이다. 모듈(406)은 상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신하기 위한 것이다. 모듈(406)은 구현된 하나 이상의 소정의 M2M API 프로파일들에 관한 정보로 응답하기 위한 것이다.

일부 실시예에서, M2M 통신을 위한 시스템은 본 문서에 개시된 기술들에 기반하여 동작될 수 있다. 상기 시스템은 네트워크를 통해 제2 M2M 시스템에 통신적으로 결합되는 제1 M2M 시스템을 포함한다. 상기 제1 M2M 시스템은 상기 제2 M2M 시스템의 M2M API 능력들(capabilities)을 수신하기 위해 M2M 어플리케이션 프로그래밍 인터페이스(API) 쿼리(query)를 전송하도록 구성된다. 상기 제2 M2M 시스템은 상기 네트워크를 통해 M2M API 능력들(capabilities)을 통신하도록 구성된다.

일부 실시예에서, 서비스 계층들은 서비스 계층 업데이트 정보를 제공하는 능력을 더 포함할 수 있다. 예를 들어, 한 동작 시나리오에서, 일부 작업을 수행하기 위해 기계(1)는 기계(2)와 교신한다(예를 들어, 기계(2)에 의해 제어되는 등(light)에 변화를 요청하기 위해). 기계(2)에 의해 제공되는 서비스 계층 API 프로파일에 기반하여, 기계(1)는 기계(2)가 등(light)을 켜거나 끌 수 있으나, 등(light)의 밝기를 낮출 수 없는 것을 안다. 그런 다음 기계(1)는 기계(2)가 그 기능을 강화하기 위해 코드 업데이트를 얻을 수 있는 곳에 대한 정보를 표시하는 자원 정보를 기계(2)에 제공할 수 있다. 상기 코드 업데이트는 기계가 가져야만 하는 저장 메모리 및 실행의 양을 지정할 수 있다. M2M API 프로파일 제공 서버는 기계(2)에 의해 컨택트(contact)될 수 있고, 그런 다음 상기 기계(2)는 상기 서버로부터 새로운 기능을 획득한다. 새로운 기능을 수신하면, 기계(2)는 등의 밝기를 낮추는 요청 작업을 완료하기 위해 기계(1)과 컨택트(contact)할 수 있다. 일부 실시예에서, 이 전체 절차가 M2M 통신에 의해, 예를 들어, 어떠한 사람의 개입 없이 구현된다.

상이한 어플리케이션 분야에서 이러한 디바이스들의 쉬운 디플로이먼트(deployment)를 가능하게 하는 API 서비스 프로파일들을 구현하여 M2M 시스템들을 동작하기 위한 기술들이 개시되는 것을 알 수 있을 것이다.

개시된 실시예 및 다른 실시예들과 본 문서에서 기술된 모듈들 및 기능 동작들이 디지털 전자 회로로, 또는 본 문서에 개시된 구조들 및 그것들의 구조적 균등물들을 포함하는 컴퓨터 소프트웨어, 펌웨어 또는 하드웨어로, 또는 그것들 중 하나 이상의 조합들로 구현될 수 있다. 개시된 실시예들 및 다른 실시예들은 하나 이상의 컴퓨터 프로그램 제품들, 예를 들어, 데이터 처리 장치에 의한 또는 그 동작 제어를 하도록, 실행을 위한 컴퓨터 판독가능한 매체에 인코딩된 컴퓨터 프로그램 명령들의 하나 이상의 모듈들로 구현될 수 있다. 상기 컴퓨터 판독가능한 매체는 기계-판독가능한 저장 디바이스, 기계-판독가능한 저장 기판(substrate), 메모리 디바이스, 기계-판독가능한 전파 신호에 영향을 주는 물질의 조성물, 또는 그것들의 하나 이상의 조합일 수 있다. "데이터 처리 장치"라는 용어는 예로 프로그래머블 프로세서, 컴퓨터, 또는 다중 프로세서들 또는 컴퓨터들을 포함하는, 데이터를 처리하기 위한 모든 장치, 디바이스들 및 기계들을 망라한다. 상기 장치는 하드웨어에 부가하여, 논의가 되는 컴퓨터 프로그램을 위한 실행 환경을 생성하는 코드, 예를 들어, 프로세서 펌웨어, 프로토콜 스택, 데이터베이스 관리 시스템, 운영 시스템, 또는 그것들 중 하나 이상의 조합을 구성하는 코드를 포함할 수 있다. 전파 신호는 적합한 수신 장치로의 전송을 위한 정보를 인코딩하기 위해 생성되는 인공적으로 생성된 신호, 예를 들어, 기계-생성 전기, 광학, 또는 전자기 신호이다.

컴퓨터 프로그램(또한 프로그램, 소프트웨어, 소프트웨어 어플리케이션, 스크립트 또는 코드로 알려진)은 컴파일 또는 해석 언어들을 포함하는, 프로그래밍 언어의 임의의 형태로 기록될 수 있고, 독립형 프로그램(stand alone program)으로 또는 모듈, 컴포넌트, 서브루틴, 또는 컴퓨팅 환경에서 사용하기에 적합한 다른 유닛으로 포함하는, 임의의 형태로 디플로이(deploy)될 수 있다. 컴퓨터 프로그램은 반드시 파일 시스템의 파일에 대응하지 않는다. 프로그램은 논의 대상인 프로그램에 전념하는 단일 파일에서, 또는 다수 조직화된 파일들(예를 들어, 하나 이상의 모듈들, 서브프로그램들 또는 코드의 부분들을 저장하는 파일들)에서, 다른 프로그램들 또는 데이터(예를 들어 마크업 언어 문서에 저장된 하나 이상의 스크립트들)를 보유하는 파일의 일부에 저장될 수 있다. 컴퓨터 프로그램은 한 컴퓨터 상에서 또는 한 사이트에 위치된 또는 다수 사이트들에 걸쳐 분산된 다수 컴퓨터상에서 실행되기 위해 디플로이(deploy)될 수 있고 통신 네트워크에 의해 상호연결될 수 있다.

본 문서에 기술된 프로세스들 및 논리 흐름들은 입력 데이터에 대해 동작하고 출력을 생성함으로써 기능들을 수행하기 위해 하나 이상의 컴퓨터 프로그램들을 실행하는 하나 이상의 프로그래머블 프로세서들에 의해 수행될 수 있다. 프로세스들 및 논리 흐름들은 또한 특별 목적 논리 회로, 예를 들어 FPGA (field programmable gate array) 또는 ASIC(application specific integrated circuit)에 의해 수행될 수 있다. 그리고 장치들은 또한 특별 목적 논리 회로, 예를 들어 FPGA (field programmable gate array) 또는 ASIC(application specific integrated circuit)으로 구현될 수 있다.

컴퓨터 프로그램의 실행에 적합한 프로세서들은 예로서, 일반 및 특별 목적 마이크로프로세서들 모두, 그리고 임의의 종류의 디지털 컴퓨터의 임의의 하나 이상의 프로세서들을 포함한다. 일반적으로, 프로세서는 판독 전용 메모리 또는 랜덤 액세스 메모리 또는 둘 모두로부터 데이터 및 명령들을 수신할 것이다. 컴퓨터의 본질적 요소들은 명령들을 수행하기 위한 프로세서 및 명령들과 데이터를 저장하기 위한 하나 이상의 메모리 디바이스들이다. 일반적으로, 컴퓨터는 또한 데이터를 저장하기 위한 하나 이상의 대용량 저장 디바이스들, 예를 들어, 자기, 광 자기 디스크, 또는 광 디스크들을 포함하거나 그것들로부터 데이터를 수신하기 위해 또는 그것들로 데이터를 전송하기 위해, 또는 둘 다를 위해, 작동적으로 결합될 것이다. 그러나, 컴퓨터는 이러한 디바이스들을 가질 필요가 없다. 컴퓨터 프로그램 명령들 및 데이터를 저장하기에 적합한 컴퓨터 판독가능한 매체는 모든 형태의 비 휘발성 메모리, 매체 및 메모리 디바이스들을 포함하고, 예로서 반도체 메모리 디바이스, 예를 들어, EPROM, EEPROM, 및 플래쉬 메모리 디바이스; 자기 디스크, 예를 들어, 내장 하드 디스크 또는 탈착가능한 디스크; 광 자기 디스크; 및 CD ROM 과 DVD-ROM 디스크를 포함한다. 프로세서 및 메모리는 특수 목적 논리 회로에 의해 보충되거나 그것에 통합될 수 있다.

본 문서가 많은 세부 사항들을 포함하지만, 이러한 것들은 청구된 발명 또는 청구될 수 있는 발명의 범위에 대한 제한으로 해석되어서는 안되며, 오히려 특정 실시예에 특정한 특징들의 설명으로 해석되어야 한다. 별도 실시예들의 맥락에서 본 문서에 기술된 특정 특징들은 또한 단일 실시예에서 조합하여 구현될 수 있다. 역으로, 단일 실시예의 맥락에서 기술된 다양한 특징들은 또한 개별적으로 다수 실시예에서 또는 임의의 적합한 서브 조합에서 구현될 수 있다. 또한, 특징들이 특정 조합으로 작용하는 것으로 상기 기술되고 심지어 그러한 것처럼 초기에 청구될 수 있지만, 청구된 조합으로부터 하나 이상의 특징들은 일부 경우들에 상기 조합으로부터 발휘될 수 있고, 상기 청구된 조합은 서브 조합 또는 서브 조합의 변형으로 지향될 수 있다. 유사하게, 동작들이 특정 순서로 도면에 도시되어 있지만, 이는 바람직한 결과를 달성하기 위해 이러한 동작들이 도시된 특정 순서 또는 순차적으로 수행될 것, 또는 모든 도시된 동작들이 수행될 것을 필요로 하는 것으로 이해되어서는 안된다.

단지 몇몇 예들 및 실시예들이 개시된다. 설명된 예들 및 실시예들에 변형, 수정 및 개선과 다른 실시예들이 개시된 것에 기반하여 이루어질 수 있다.

Claims

기기간(M2M) 통신을 용이하게 하기 위한 방법에 있어서, 상기 방법은:
적어도 하나의 소정의 기기간(M2M) 어플리케이션 프로그래밍 인터페이스(API) 프로파일들을 구현하는 M2M 시스템을 제공하는 단계-상기 적어도 하나의 소정의 M2M API 프로파일들은 복수의 비즈니스 엔티티들(multiple business entities)에 의해 제공되는 기능들을 기술함-;
상기 M2M 시스템을 위한 네트워크 인터페이스를 제공하는 단계;
상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신하는 단계; 및
상기 복수의 비즈니스 엔티티들 중 어느 것이 상기 기능들을 제공하는지에 관계없이 상기 M2M 시스템을 통해 어플리케이션 서버와 전송 네트워크 사이의 통신을 용이하게 하도록 상기 적어도 하나의 소정의 M2M API 프로파일들에 기술된 상기 기능들의 사용을 허용하기 위해 상기 구현된 적어도 하나의 소정의 M2M API 프로파일들에 관한 정보로 응답하는 단계를 포함하고, 상기 방법은, 어떠한 인간의 개입없이:
현재 구현되지 않은 기능에 대한 소프트웨어 업데이트를 획득하기 위한 곳에 대한 정보를 수신하는 단계;
상기 현재 구현되지 않은 새로운 기능을 수신하는 단계; 및
상기 수신된 새로운 기능에 기초하여 요청 작업을 완료하는 단계를 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 방법.
제1항에 있어서,
상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜에 무관한 제1 모듈 및 상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜을 사용하여 신호들을 전송하고 수신하는 제2 모듈을 포함하도록 상기 적어도 하나의 M2M API 프로파일들을 구현하는 단계를 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 방법.
제1항에 있어서,
관리 정보 데이터베이스(MIB)에, 상기 적어도 하나의 소정의 M2M API 프로파일들 중 하나에 대응하는 정보를 저장하는 단계를 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 방법.
제3항에 있어서,
상기 적어도 하나의 소정의 M2M API 프로파일들에서 지정된 규칙들에 기초하여, 또 다른 시스템에 의해 판독가능한/기록가능한 정보를 만드는 단계를 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 방법.
기기간(M2M) 통신을 용이하게 하기 위한 장치에 있어서, 상기 장치는:
적어도 하나의 소정의 기기간(M2M) 어플리케이션 프로그래밍 인터페이스(API) 프로파일들을 구현하는 M2M 시스템을 제공하기 위한 수단-상기 적어도 하나의 소정의 M2M API 프로파일들은 복수의 비즈니스 엔티티들(multiple business entities)에 의해 제공되는 기능들을 기술함-;
상기 M2M 시스템을 위한 네트워크 인터페이스를 제공하기 위한 수단;
상기 네트워크 인터페이스를 통해 프로파일 쿼리(query)를 수신하기 위한 수단; 및
상기 복수의 비즈니스 엔티티들 중 어느 것이 상기 기능들을 제공하는지에 관계없이 상기 M2M 시스템을 통해 어플리케이션 서버와 전송 네트워크 사이의 통신을 용이하게 하도록 상기 적어도 하나의 소정의 M2M API 프로파일들에 기술된 상기 기능들의 사용을 허용하기 위해 상기 구현된 적어도 하나의 소정의 M2M API 프로파일들에 관한 정보로 응답하기 위한 수단을 포함하고, 상기 장치는:
현재 구현되지 않은 기능에 대한 소프트웨어 업데이트를 획득하기 위한 곳에 대한 정보를 수신하기 위한 수단;
상기 현재 구현되지 않은 새로운 기능을 수신하기 위한 수단; 및
상기 수신된 새로운 기능에 기초하여 요청 작업을 완료하기 위한 수단을 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 장치.
제5항에 있어서,
상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜에 무관한 제1 모듈 및 상기 네트워크 인터페이스를 위해 사용되는 전송 프로토콜을 사용하여 신호들을 전송하고 수신하는 제2 모듈을 포함하도록 상기 적어도 하나의 M2M API 프로파일들을 구현하기 위한 수단을 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 장치.
제5항에 있어서,
관리 정보 데이터베이스(MIB)에, 상기 적어도 하나의 소정의 M2M API 프로파일들 중 하나에 대응하는 정보를 저장하기 위한 수단을 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 장치.
제7항에 있어서,
상기 적어도 하나의 소정의 M2M API 프로파일들에서 지정된 규칙들에 기초하여, 또 다른 시스템에 의해 판독가능한/기록가능한 정보를 만들기 위한 수단을 더 포함하는 기기간(M2M) 통신을 용이하게 하기 위한 장치.
컴퓨터 판독가능한 저장 매체 상에 저장된 프로그램 코드를 가지는 컴퓨터 프로그램을 기록하기 위한 컴퓨터 판독가능한 저장 매체로서, 상기 코드는 프로세서에 의해 실행될 때 상기 프로세서가 제1항 내지 제4항 중 어느 한 항에 기재된 방법을 구현하도록 하는 컴퓨터 판독가능한 저장 매체.
기기간(M2M) 통신을 위한 시스템에 있어서, 상기 시스템은:
네트워크를 통해 제2 M2M 시스템에 통신적으로 결합되는 제1 M2M 시스템을 포함하되,
상기 제1 M2M 시스템은 상기 제2 M2M 시스템의 M2M API 능력들(capabilities)을 수신하기 위해 M2M 어플리케이션 프로그래밍 인터페이스(API) 쿼리(query)를 전송하도록 구성되고-상기 M2M API 능력들(capabilities)은 복수의 비즈니스 엔티티들(multiple business entities)에 의해 제공되는 기능들을 기술함-; 및
상기 제2 M2M 시스템은 상기 복수의 비즈니스 엔티티들 중 어느 것이 상기 기능들을 제공하는지에 관계없이 상기 제2 M2M 시스템을 통해 어플리케이션 서버와 전송 네트워크 사이의 통신을 용이하게 하도록 상기 M2M API 능력들(capabilities)에 기술된 상기 기능들의 사용을 허용하기 위해 상기 네트워크를 통해 M2M API 능력들(capabilities)을 통신하도록 구성되고, 상기 제2 M2M 시스템은, 어떠한 인간의 개입없이:
현재 구현되지 않은 기능에 대한 소프트웨어 업데이트를 획득하기 위한 곳에 대한 정보를 수신하는 것;
상기 현재 구현되지 않은 새로운 기능을 수신하는 것; 및
상기 수신된 새로운 기능에 기초하여 요청 작업을 완료하는 것을 수행하는 기기간(M2M) 통신을 위한 시스템.